對(duì)于網(wǎng)絡(luò)當(dāng)中，我們所使用的路由協(xié)議來(lái)進(jìn)行有效的網(wǎng)絡(luò)優(yōu)化。那么下面我們將詳細(xì)闡述一下有關(guān)于AODV路由協(xié)議的應(yīng)用方案。那么希望大家從下面的文章中，能得到參考。AODV路由協(xié)議決定本地連接，為了避免浪費(fèi)帶寬和能量,去確定下一跳在它的傳輸范圍內(nèi)并且下一跳希望接收這個(gè)包對(duì)于一個(gè)數(shù)據(jù)包的發(fā)送者來(lái)說(shuō)是非常有益的｡為了校驗(yàn)下一跳正在接收數(shù)據(jù),本地連接必須被監(jiān)控｡沒(méi)有能力發(fā)送數(shù)據(jù)給鄰居的通告需要立即通告源節(jié)點(diǎn)路由路徑截?cái)嗔?否則節(jié)點(diǎn)繼續(xù)發(fā)送數(shù)據(jù)包,浪費(fèi)資源｡AODV路由協(xié)議用RERR去通告源節(jié)點(diǎn)和斷開(kāi)鏈路上的去源的所有節(jié)點(diǎn)｡因?yàn)槠渌慕鉀Q方法并不是立即是有效的,所以現(xiàn)在所有的應(yīng)用方案都是利用Hello消息｡不幸的是,Hello消息在許多普遍的關(guān)節(jié)[3,10]表現(xiàn)是很差的｡

AODV路由協(xié)議應(yīng)用方案的比較

現(xiàn)在這里存在很多AODV路由協(xié)議應(yīng)用方案,包括Mad-hoc[8],AODV-UCSB[2],AODV-UU[9],Kernel-AODV[7],和AODV-UIUC[6]｡每一個(gè)應(yīng)用方案都獨(dú)立地被改進(jìn)和設(shè)計(jì),但是,它們完成同樣的操作和許多內(nèi)部操作｡

最早公開(kāi)的有效的AODV應(yīng)用是Mad-hoc｡Mad-hoc應(yīng)用方案完全依賴于用戶層并用探聽(tīng)策略來(lái)決定AODV事件｡不幸的是,它有很多缺陷(bugs),它導(dǎo)致協(xié)議被不正確的執(zhí)行｡這些問(wèn)題與它對(duì)ARP的使用想關(guān)聯(lián)｡Mad-hoc應(yīng)用的另外一個(gè)特征缺陷是在路由尋找過(guò)程中對(duì)數(shù)據(jù)包進(jìn)行適當(dāng)?shù)呐抨?duì)｡Mad-hoc不再被積極的研究,支持或則有效｡

AODV-UCSB的第一次釋放是利用內(nèi)核修改策略｡AODV-UCSB應(yīng)用在Netfiler被發(fā)展前得到了發(fā)展｡我們發(fā)現(xiàn)它遭遇到了很多斷斷續(xù)續(xù)的問(wèn)題｡這些是起源于依賴于我們特定修改后的內(nèi)核的一些無(wú)法預(yù)知的問(wèn)題｡在Netfilter成熟以后,AODV-UCSB用Nerfilter進(jìn)行了更新｡AODV-UCSB利用了AODV-UUv0.4的Netfilter的內(nèi)核模塊｡利用這些內(nèi)核模塊,所有感興趣的包都可以通過(guò)用戶層守護(hù)進(jìn)程的處理,就象section2.3所描述的那樣｡此外基本AODV的描述,大量Hello消息選擇是可用的｡這些包括了在鄰居連通前對(duì)多種Hello消息的接收｡這個(gè)避免了建立在單個(gè)虛假的信息接收基礎(chǔ)上的到鄰居的路由｡

AODV-UU采用了類似AODV-UCSB的設(shè)計(jì)｡它也是利用內(nèi)核模塊來(lái)利用netfilter的掛接功能｡主要的協(xié)議邏輯建立在用戶層的守護(hù)進(jìn)程｡AODV-UU也用于了NS-2仿真｡這個(gè)允許所有的真實(shí)的應(yīng)用代碼在這個(gè)仿真環(huán)境中運(yùn)行｡作者也加了很多追加的特征,并不是部分AODV路由協(xié)議的草案,而是增加了Hello消息的性能[10](例如:單向鏈路的支持和接收包的首端的信號(hào)質(zhì)量)｡另外,AODV-UU也包括Internet網(wǎng)關(guān)和多種網(wǎng)絡(luò)接口支持｡自從AODV-UU被很好的證明其優(yōu)勢(shì),并且能在仿真機(jī)上運(yùn)行,大量的修改是對(duì)于以后的功能拓展有效的(例如組播和子網(wǎng)絡(luò))｡

Kernel-AODV利用了Netfilter和所有的路由協(xié)議邏輯都是處于內(nèi)核模塊中的;所以,沒(méi)有用到用戶層的守護(hù)進(jìn)程｡這個(gè)增強(qiáng)了它的應(yīng)用性能,在包的處理期間,沒(méi)有包需要從內(nèi)核中傳遞到用戶層｡這種應(yīng)用方案同樣支持Internet網(wǎng)關(guān),多種網(wǎng)絡(luò)接口和一個(gè)基礎(chǔ)的多播協(xié)議｡在特定的無(wú)線硬件被用到時(shí),這里同樣有proc文件為用戶去監(jiān)控到鄰居的信號(hào)強(qiáng)度｡

AODV-UIUC應(yīng)用通過(guò)AdhocSupportLibrary(ASL)[6]利用了Netfilter的包裝｡這種設(shè)計(jì)跟AODV-USCB和AODV-UU是非常相似的,除了它嚴(yán)格區(qū)分了路由和轉(zhuǎn)發(fā)功能｡路由協(xié)議邏輯代替了用戶層守護(hù)進(jìn)程,而路由轉(zhuǎn)發(fā)是在內(nèi)核中進(jìn)行處理的｡這是非常有效的,因?yàn)檗D(zhuǎn)發(fā)包是被立即處理的并且?guī)缀鯖](méi)有包穿過(guò)內(nèi)核去用戶層｡

所有被討論的應(yīng)用都是利用Hello小時(shí)去決定本地的連通和檢測(cè)鏈路的斷開(kāi)｡另外,所有的應(yīng)用(出了Mad-hoc)支持?jǐn)U展的路由環(huán)搜索和最優(yōu)化的本地修復(fù)[11]｡

結(jié)論

在這篇文章中,我們分析了一個(gè)AODV路由協(xié)議應(yīng)用的可能設(shè)計(jì)｡我們首先定義了在實(shí)現(xiàn)路由功能時(shí)AODV所不支持的幾個(gè)事件｡我們檢查了決定這些消息的三種策略的優(yōu)點(diǎn)和缺點(diǎn)｡這個(gè)分析支持我們的包含小的內(nèi)核模塊的用戶層守護(hù)進(jìn)程的結(jié)論｡最后,我列舉了現(xiàn)在公布的有效的AODV應(yīng)用的設(shè)計(jì)｡我們希望文章中的消息能幫助研究者理解在adhoc路由協(xié)議應(yīng)用發(fā)展中的過(guò)時(shí)現(xiàn)象?(trade-offs)｡再者,設(shè)計(jì)結(jié)構(gòu)的描述和另外的每個(gè)應(yīng)用的特征能幫助擁護(hù)決定哪個(gè)應(yīng)用方案適合他們的需要｡