對于AODV路由協議，有很多的優點，不少運營商都會使用這個協議來進行網絡管理。相信想要成為網管的你也一定高度重視這個協議。那么，在之前我們已經對AODV路由協議的基本概況進行了講解，現在我們再來了解一下更深一步的內容。介紹AODV-UCSB,它是脫離內核,在用戶層面的守護進程來實現盡可能多的邏輯功能｡這是路由協議的普遍設計方法,因為在內核中的代碼具有不同的優先級,在內核空間一個單一的錯誤能導致整個操作操作系統的崩潰｡

對于AODV路由協議守護進程功能的實現,它必須決定什么時候去激發AODV路由事件｡自從在鏈路中斷很少發生和分組丟失不被報道的固定網中使用IP分組以來,絕大部分觸發不是穩定有效的｡所以,這些觸發時間必須被推斷和經過其他途徑與路由守護進程進行通信｡

必須被決定的事件

(1)什么時候發起路由請求

(2)在路由尋路期間什么時候怎么緩存數據分組

(3)如果一個有效路由不存在時什么時候產生RERR

(4)在守護進程重起期間什么時候產生RERR｡

接著討論不同的設計方法｡首先,我們應該知道怎么去決定這些時間和在哪里實現AODV路由協議的邏輯｡我們描述了各種解決方法的優缺點,和我們證明為什么我們選擇一個帶有一個小的內核模塊的用戶層的守護進程｡此外,我們討論監視鄰居連同性的重要性和它怎么來實現｡

設計的可能性

這里有很多方法來實現AODV路由協議去推斷所需要的AODV事件｡獲得事件的可能機會有:

(1)snooping探聽

(2)kernel modification內核修改

(3)Nerfilter

在下面,每個可能性都被描述,并給出他們的優點和缺點｡#p#

snooping

決定所需要的事件的一個可能性就是去雜亂的探聽所有的輸入和輸出的分組[8]｡執行探聽的代碼設計在內核中和對用戶層程序是有效的。這個探聽的特征可以用來決定在第3部分檢測到的事件｡例如,當一個節點不知道在一跳的MAC層地址時一個ARP包被創建｡由這個推論,如果一個ARP包被一個未知目的地接收到并且由本地主機發起的,那么一個路由尋找將被發起｡一個類似的行為,通過監視進出的所有包,來決定所有其他的AODV路由協議事件｡

這個解決方案的最重要的優點是它不需要任何代碼運行在內核空間中｡所以這個解決方案需要簡單的安裝和執行｡它的兩個主要的缺點是加了不必要的頭部(overhead)和依賴于ARP｡例如某個路由發現的需要是有ARP請求來指出的｡自從路由尋找被出去的ARP包發起,這些出去的包被加了不必須的頭部,并且浪費了帶寬｡依賴于ARP也帶來了很多問題｡如果路由表和ARP緩存變的不同步了,那么路由協議不能實現正確的實現功能是可能發生的｡例如,如果一個ARP緩存包含一個到特殊的未知的目的地的入口,因為它沒有被路由守護進程所知道,所以這個ARP包沒有為這個目的地而創建｡結果是,路由尋找沒有被發起｡對于正確的操作,這個路由協議必須在IP路由表的外部監聽和控制ARP緩存,因為它們兩的不同可能導致路由協議的不正確執行｡

kernel modification內核修改

另外一種決定AODV事件的可能性是去修改內核｡代碼可以放置在內核中去溝通在section3中所列舉的事件與用戶層的AODV守護進程｡例如,為了發起一個路由尋找,代碼加到內核中的路由尋找失敗發生的地方｡由內核中的這個代碼設定,如果一個路由查找失敗發生,那么在用戶層的守護進程中一個方法被呼叫｡AODV路由協議守護進程的結構和必需的支持邏輯｡

這種解決方法的優點是這些事件可以被明確的決定并且沒有任何浪費的加在頭部前的數據｡它主要的缺點是用戶的安裝和通用性｡必要的內核修改的安裝需要一個完整的內核重編輯｡這個對于需用用戶來說是非常難的過程｡并且,內核的修改經常是不兼容的在一個修改的版本和另外一個內核之間｡最后,理解linux內核和網絡協議組要求檢查重要的很多的為申明的復雜的代碼｡

Netfilter

Netfilter是在linux協議組中在許多掛鉤點的一組過濾子系統,section2.3所描述的一樣｡Netfilter通過用戶自定義的代碼來重定向包流,這些代碼能為用戶層守護進程檢測,遺失,丟棄,修改或者排隊這些包｡用Netfilter和在section3.1.1中描述的探聽的方法是很相似的;然而,它沒有不必要的加在頭前面的數據或則依賴ARP的缺點｡

比較其他的可能性,這個解決方法有很多優點｡這些優點包括沒有不必要的通信,具有很高的通用性,很方便的安裝和用戶層的守護進程能決定在section3中要求的事件｡

在另外一方面,這個解決方法的缺點是它需要一個內核模塊｡然而,一個內核模塊相比內核修改而言是很簡單的｡僅僅只要編輯一個內核模塊,而不需要去編輯整個內核｡并且內核模塊能在任何時候裝載和卸載｡最后,一個內核模塊比內核修改具有更高的通用性,因為它依賴Netfilter接口｡這種接口不隨內核的更改而改變｡

自從Netfilter通過檢查策略使其具有最少和最小的重要性缺陷,我們在我們最后的應用結構中利用了它｡我們的應用利用了Netfilter的掛接來重定向了包,接受從本機(NF_IP_LOCAL_OUT),從別的機器(NF_IP_PRE_ROUTING),還有所有的被發送到其他機器(NF_IN_POST_ROUTING)的包｡這些掛接函數被kAODV內核模塊使用｡Ip_queue模塊是用來在用戶層守護進程中對這些包進行排隊｡這些AODV路由協議守護進程用libipq來對每個包做控制決定｡