對于網絡當中，我們所使用的路由協議來進行有效的網絡優化。那么下面我們將詳細闡述一下有關于AODV路由協議的應用方案。那么希望大家從下面的文章中，能得到參考。AODV路由協議決定本地連接，為了避免浪費帶寬和能量,去確定下一跳在它的傳輸范圍內并且下一跳希望接收這個包對于一個數據包的發送者來說是非常有益的｡為了校驗下一跳正在接收數據,本地連接必須被監控｡沒有能力發送數據給鄰居的通告需要立即通告源節點路由路徑截斷了;否則節點繼續發送數據包,浪費資源｡AODV路由協議用RERR去通告源節點和斷開鏈路上的去源的所有節點｡因為其他的解決方法并不是立即是有效的,所以現在所有的應用方案都是利用Hello消息｡不幸的是,Hello消息在許多普遍的關節[3,10]表現是很差的｡

AODV路由協議應用方案的比較

現在這里存在很多AODV路由協議應用方案,包括Mad-hoc[8],AODV-UCSB[2],AODV-UU[9],Kernel-AODV[7],和AODV-UIUC[6]｡每一個應用方案都獨立地被改進和設計,但是,它們完成同樣的操作和許多內部操作｡

最早公開的有效的AODV應用是Mad-hoc｡Mad-hoc應用方案完全依賴于用戶層并用探聽策略來決定AODV事件｡不幸的是,它有很多缺陷(bugs),它導致協議被不正確的執行｡這些問題與它對ARP的使用想關聯｡Mad-hoc應用的另外一個特征缺陷是在路由尋找過程中對數據包進行適當的排隊｡Mad-hoc不再被積極的研究,支持或則有效｡

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

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

Kernel-AODV利用了Netfilter和所有的路由協議邏輯都是處于內核模塊中的;所以,沒有用到用戶層的守護進程｡這個增強了它的應用性能,在包的處理期間,沒有包需要從內核中傳遞到用戶層｡這種應用方案同樣支持Internet網關,多種網絡接口和一個基礎的多播協議｡在特定的無線硬件被用到時,這里同樣有proc文件為用戶去監控到鄰居的信號強度｡

AODV-UIUC應用通過AdhocSupportLibrary(ASL)[6]利用了Netfilter的包裝｡這種設計跟AODV-USCB和AODV-UU是非常相似的,除了它嚴格區分了路由和轉發功能｡路由協議邏輯代替了用戶層守護進程,而路由轉發是在內核中進行處理的｡這是非常有效的,因為轉發包是被立即處理的并且幾乎沒有包穿過內核去用戶層｡

所有被討論的應用都是利用Hello小時去決定本地的連通和檢測鏈路的斷開｡另外,所有的應用(出了Mad-hoc)支持擴展的路由環搜索和最優化的本地修復[11]｡

結論

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