AODV路由協(xié)議的應(yīng)用案例分析
對于網(wǎng)絡(luò)當(dāng)中,我們所使用的路由協(xié)議來進(jìn)行有效的網(wǎng)絡(luò)優(yōu)化。那么下面我們將詳細(xì)闡述一下有關(guān)于AODV路由協(xié)議的應(yīng)用方案。那么希望大家從下面的文章中,能得到參考。AODV路由協(xié)議決定本地連接,為了避免浪費(fèi)帶寬和能量,去確定下一跳在它的傳輸范圍內(nèi)并且下一跳希望接收這個包對于一個數(shù)據(jù)包的發(fā)送者來說是非常有益的。為了校驗下一跳正在接收數(shù)據(jù),本地連接必須被監(jiān)控。沒有能力發(fā)送數(shù)據(jù)給鄰居的通告需要立即通告源節(jié)點路由路徑截斷了;否則節(jié)點繼續(xù)發(fā)送數(shù)據(jù)包,浪費(fèi)資源。AODV路由協(xié)議用RERR去通告源節(jié)點和斷開鏈路上的去源的所有節(jié)點。因為其他的解決方法并不是立即是有效的,所以現(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]。每一個應(yīng)用方案都獨(dú)立地被改進(jìn)和設(shè)計,但是,它們完成同樣的操作和許多內(nèi)部操作。
最早公開的有效的AODV應(yīng)用是Mad-hoc。Mad-hoc應(yīng)用方案完全依賴于用戶層并用探聽策略來決定AODV事件。不幸的是,它有很多缺陷(bugs),它導(dǎo)致協(xié)議被不正確的執(zhí)行。這些問題與它對ARP的使用想關(guān)聯(lián)。Mad-hoc應(yīng)用的另外一個特征缺陷是在路由尋找過程中對數(shù)據(jù)包進(jìn)行適當(dāng)?shù)呐抨?#65377;Mad-hoc不再被積極的研究,支持或則有效。
AODV-UCSB的第一次釋放是利用內(nèi)核修改策略。AODV-UCSB應(yīng)用在Netfiler被發(fā)展前得到了發(fā)展。我們發(fā)現(xiàn)它遭遇到了很多斷斷續(xù)續(xù)的問題。這些是起源于依賴于我們特定修改后的內(nèi)核的一些無法預(yù)知的問題。在Netfilter成熟以后,AODV-UCSB用Nerfilter進(jìn)行了更新。AODV-UCSB利用了AODV-UUv0.4的Netfilter的內(nèi)核模塊。利用這些內(nèi)核模塊,所有感興趣的包都可以通過用戶層守護(hù)進(jìn)程的處理,就象section2.3所描述的那樣。此外基本AODV的描述,大量Hello消息選擇是可用的。這些包括了在鄰居連通前對多種Hello消息的接收。這個避免了建立在單個虛假的信息接收基礎(chǔ)上的到鄰居的路由。
AODV-UU采用了類似AODV-UCSB的設(shè)計。它也是利用內(nèi)核模塊來利用netfilter的掛接功能。主要的協(xié)議邏輯建立在用戶層的守護(hù)進(jìn)程。AODV-UU也用于了NS-2仿真。這個允許所有的真實的應(yīng)用代碼在這個仿真環(huán)境中運(yùn)行。作者也加了很多追加的特征,并不是部分AODV路由協(xié)議的草案,而是增加了Hello消息的性能[10](例如:單向鏈路的支持和接收包的首端的信號質(zhì)量)。另外,AODV-UU也包括Internet網(wǎng)關(guān)和多種網(wǎng)絡(luò)接口支持。自從AODV-UU被很好的證明其優(yōu)勢,并且能在仿真機(jī)上運(yùn)行,大量的修改是對于以后的功能拓展有效的(例如組播和子網(wǎng)絡(luò))。
Kernel-AODV利用了Netfilter和所有的路由協(xié)議邏輯都是處于內(nèi)核模塊中的;所以,沒有用到用戶層的守護(hù)進(jìn)程。這個增強(qiáng)了它的應(yīng)用性能,在包的處理期間,沒有包需要從內(nèi)核中傳遞到用戶層。這種應(yīng)用方案同樣支持Internet網(wǎng)關(guān),多種網(wǎng)絡(luò)接口和一個基礎(chǔ)的多播協(xié)議。在特定的無線硬件被用到時,這里同樣有proc文件為用戶去監(jiān)控到鄰居的信號強(qiáng)度。
AODV-UIUC應(yīng)用通過AdhocSupportLibrary(ASL)[6]利用了Netfilter的包裝。這種設(shè)計跟AODV-USCB和AODV-UU是非常相似的,除了它嚴(yán)格區(qū)分了路由和轉(zhuǎn)發(fā)功能。路由協(xié)議邏輯代替了用戶層守護(hù)進(jìn)程,而路由轉(zhuǎn)發(fā)是在內(nèi)核中進(jìn)行處理的。這是非常有效的,因為轉(zhuǎn)發(fā)包是被立即處理的并且?guī)缀鯖]有包穿過內(nèi)核去用戶層。
所有被討論的應(yīng)用都是利用Hello小時去決定本地的連通和檢測鏈路的斷開。另外,所有的應(yīng)用(出了Mad-hoc)支持?jǐn)U展的路由環(huán)搜索和最優(yōu)化的本地修復(fù)[11]。
結(jié)論
在這篇文章中,我們分析了一個AODV路由協(xié)議應(yīng)用的可能設(shè)計。我們首先定義了在實現(xiàn)路由功能時AODV所不支持的幾個事件。我們檢查了決定這些消息的三種策略的優(yōu)點和缺點。這個分析支持我們的包含小的內(nèi)核模塊的用戶層守護(hù)進(jìn)程的結(jié)論。最后,我列舉了現(xiàn)在公布的有效的AODV應(yīng)用的設(shè)計。我們希望文章中的消息能幫助研究者理解在adhoc路由協(xié)議應(yīng)用發(fā)展中的過時現(xiàn)象?(trade-offs)。再者,設(shè)計結(jié)構(gòu)的描述和另外的每個應(yīng)用的特征能幫助擁護(hù)決定哪個應(yīng)用方案適合他們的需要。