對(duì)于AODV路由協(xié)議，有很多的優(yōu)點(diǎn)，不少運(yùn)營(yíng)商都會(huì)使用這個(gè)協(xié)議來(lái)進(jìn)行網(wǎng)絡(luò)管理。相信想要成為網(wǎng)管的你也一定高度重視這個(gè)協(xié)議。那么，在之前我們已經(jīng)對(duì)AODV路由協(xié)議的基本概況進(jìn)行了講解，現(xiàn)在我們?cè)賮?lái)了解一下更深一步的內(nèi)容。介紹AODV-UCSB,它是脫離內(nèi)核,在用戶層面的守護(hù)進(jìn)程來(lái)實(shí)現(xiàn)盡可能多的邏輯功能｡這是路由協(xié)議的普遍設(shè)計(jì)方法,因?yàn)樵趦?nèi)核中的代碼具有不同的優(yōu)先級(jí),在內(nèi)核空間一個(gè)單一的錯(cuò)誤能導(dǎo)致整個(gè)操作操作系統(tǒng)的崩潰｡

對(duì)于AODV路由協(xié)議守護(hù)進(jìn)程功能的實(shí)現(xiàn),它必須決定什么時(shí)候去激發(fā)AODV路由事件｡自從在鏈路中斷很少發(fā)生和分組丟失不被報(bào)道的固定網(wǎng)中使用IP分組以來(lái),絕大部分觸發(fā)不是穩(wěn)定有效的｡所以,這些觸發(fā)時(shí)間必須被推斷和經(jīng)過(guò)其他途徑與路由守護(hù)進(jìn)程進(jìn)行通信｡

必須被決定的事件

(1)什么時(shí)候發(fā)起路由請(qǐng)求

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

(3)如果一個(gè)有效路由不存在時(shí)什么時(shí)候產(chǎn)生RERR

(4)在守護(hù)進(jìn)程重起期間什么時(shí)候產(chǎn)生RERR｡

接著討論不同的設(shè)計(jì)方法｡首先,我們應(yīng)該知道怎么去決定這些時(shí)間和在哪里實(shí)現(xiàn)AODV路由協(xié)議的邏輯｡我們描述了各種解決方法的優(yōu)缺點(diǎn),和我們證明為什么我們選擇一個(gè)帶有一個(gè)小的內(nèi)核模塊的用戶層的守護(hù)進(jìn)程｡此外,我們討論監(jiān)視鄰居連同性的重要性和它怎么來(lái)實(shí)現(xiàn)｡

設(shè)計(jì)的可能性

這里有很多方法來(lái)實(shí)現(xiàn)AODV路由協(xié)議去推斷所需要的AODV事件｡獲得事件的可能機(jī)會(huì)有:

(1)snooping探聽(tīng)

(2)kernel modification內(nèi)核修改

(3)Nerfilter

在下面,每個(gè)可能性都被描述,并給出他們的優(yōu)點(diǎn)和缺點(diǎn)｡#p#

snooping

決定所需要的事件的一個(gè)可能性就是去雜亂的探聽(tīng)所有的輸入和輸出的分組[8]｡執(zhí)行探聽(tīng)的代碼設(shè)計(jì)在內(nèi)核中和對(duì)用戶層程序是有效的。這個(gè)探聽(tīng)的特征可以用來(lái)決定在第3部分檢測(cè)到的事件｡例如,當(dāng)一個(gè)節(jié)點(diǎn)不知道在一跳的MAC層地址時(shí)一個(gè)ARP包被創(chuàng)建｡由這個(gè)推論,如果一個(gè)ARP包被一個(gè)未知目的地接收到并且由本地主機(jī)發(fā)起的,那么一個(gè)路由尋找將被發(fā)起｡一個(gè)類似的行為,通過(guò)監(jiān)視進(jìn)出的所有包,來(lái)決定所有其他的AODV路由協(xié)議事件｡

這個(gè)解決方案的最重要的優(yōu)點(diǎn)是它不需要任何代碼運(yùn)行在內(nèi)核空間中｡所以這個(gè)解決方案需要簡(jiǎn)單的安裝和執(zhí)行｡它的兩個(gè)主要的缺點(diǎn)是加了不必要的頭部(overhead)和依賴于ARP｡例如某個(gè)路由發(fā)現(xiàn)的需要是有ARP請(qǐng)求來(lái)指出的｡自從路由尋找被出去的ARP包發(fā)起,這些出去的包被加了不必須的頭部,并且浪費(fèi)了帶寬｡依賴于ARP也帶來(lái)了很多問(wèn)題｡如果路由表和ARP緩存變的不同步了,那么路由協(xié)議不能實(shí)現(xiàn)正確的實(shí)現(xiàn)功能是可能發(fā)生的｡例如,如果一個(gè)ARP緩存包含一個(gè)到特殊的未知的目的地的入口,因?yàn)樗鼪](méi)有被路由守護(hù)進(jìn)程所知道,所以這個(gè)ARP包沒(méi)有為這個(gè)目的地而創(chuàng)建｡結(jié)果是,路由尋找沒(méi)有被發(fā)起｡對(duì)于正確的操作,這個(gè)路由協(xié)議必須在IP路由表的外部監(jiān)聽(tīng)和控制ARP緩存,因?yàn)樗鼈儍傻牟煌赡軐?dǎo)致路由協(xié)議的不正確執(zhí)行｡

kernel modification內(nèi)核修改

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

這種解決方法的優(yōu)點(diǎn)是這些事件可以被明確的決定并且沒(méi)有任何浪費(fèi)的加在頭部前的數(shù)據(jù)｡它主要的缺點(diǎn)是用戶的安裝和通用性｡必要的內(nèi)核修改的安裝需要一個(gè)完整的內(nèi)核重編輯｡這個(gè)對(duì)于需用用戶來(lái)說(shuō)是非常難的過(guò)程｡并且,內(nèi)核的修改經(jīng)常是不兼容的在一個(gè)修改的版本和另外一個(gè)內(nèi)核之間｡最后,理解linux內(nèi)核和網(wǎng)絡(luò)協(xié)議組要求檢查重要的很多的為申明的復(fù)雜的代碼｡

Netfilter

Netfilter是在linux協(xié)議組中在許多掛鉤點(diǎn)的一組過(guò)濾子系統(tǒng),section2.3所描述的一樣｡Netfilter通過(guò)用戶自定義的代碼來(lái)重定向包流,這些代碼能為用戶層守護(hù)進(jìn)程檢測(cè),遺失,丟棄,修改或者排隊(duì)這些包｡用Netfilter和在section3.1.1中描述的探聽(tīng)的方法是很相似的;然而,它沒(méi)有不必要的加在頭前面的數(shù)據(jù)或則依賴ARP的缺點(diǎn)｡

比較其他的可能性,這個(gè)解決方法有很多優(yōu)點(diǎn)｡這些優(yōu)點(diǎn)包括沒(méi)有不必要的通信,具有很高的通用性,很方便的安裝和用戶層的守護(hù)進(jìn)程能決定在section3中要求的事件｡

在另外一方面,這個(gè)解決方法的缺點(diǎn)是它需要一個(gè)內(nèi)核模塊｡然而,一個(gè)內(nèi)核模塊相比內(nèi)核修改而言是很簡(jiǎn)單的｡僅僅只要編輯一個(gè)內(nèi)核模塊,而不需要去編輯整個(gè)內(nèi)核｡并且內(nèi)核模塊能在任何時(shí)候裝載和卸載｡最后,一個(gè)內(nèi)核模塊比內(nèi)核修改具有更高的通用性,因?yàn)樗蕾嘚etfilter接口｡這種接口不隨內(nèi)核的更改而改變｡

自從Netfilter通過(guò)檢查策略使其具有最少和最小的重要性缺陷,我們?cè)谖覀冏詈蟮膽?yīng)用結(jié)構(gòu)中利用了它｡我們的應(yīng)用利用了Netfilter的掛接來(lái)重定向了包,接受從本機(jī)(NF_IP_LOCAL_OUT),從別的機(jī)器(NF_IP_PRE_ROUTING),還有所有的被發(fā)送到其他機(jī)器(NF_IN_POST_ROUTING)的包｡這些掛接函數(shù)被kAODV內(nèi)核模塊使用｡Ip_queue模塊是用來(lái)在用戶層守護(hù)進(jìn)程中對(duì)這些包進(jìn)行排隊(duì)｡這些AODV路由協(xié)議守護(hù)進(jìn)程用libipq來(lái)對(duì)每個(gè)包做控制決定｡