[转]载linux中AODV的实现方案

文章翻译的一般般

但是原文AODVRoutingProtocolImplementationDesign很好，很有参考价值

对嵌入式实现AODV路由很有帮助

转自：http://blog.chinaunix.net/u1/47073/showart_1357983.html

主要有AODV的设计思路和现有的各种解决方案的优缺点:

同行多指教!

下面的文章的英文原文来自:

AODVRoutingProtocolImplementationDesign

IanD.Chakeres，Dept.ofElectrical&ComputerEngineering，UniversityofCalifornia,SantaBarbara，idc@engineering.ucsb.edu。

ElizabethM.Belding-Royer，Dept.ofComputerScience，UniversityofCalifornia,SantaBarbara，ebelding@cs.ucsb.edu

此文章介绍AODV-UCSB，它是脱离内核，在用户层面的守护进程来实现尽可能多的逻辑功能。这是路由协议的普遍设计方法，因为在内核中的代码具有不同的优先级，在内核空间一个单一的错误能导致整个操作操作系统的崩溃。

对于AODV路由守护进程功能的实现，它必须决定什么时候去激发AODV路由事件。自从在链路中断很少发生和分组丢失不被报道的固定网中使用IP分组以来，绝大部分触发不是稳定有效的。所以，这些触发时间必须被推断和经过其他途径与路由守护进程进行通信。必须被决定是事件有：（1）什么时候发起路由请求（2）在路由寻路期间什么时候怎么缓存数据分组（3）如果一个有效路由不存在时什么时候产生RERR（4）在守护进程重起期间什么时候产生RERR。

接着讨论不同的设计方法。首先，我们应该知道怎么去决定这些时间和在哪里实现AODV协议的逻辑。我们描述了各种解决方法的优缺点，和我们证明为什么我们选择一个带有一个小的内核模块的用户层的守护进程。此外，我们讨论监视邻居连同性的重要性和它怎么来实现。

3.1设计的可能性

这里有很多方法来实现AODV路由协议去推断所需要的AODV事件。获得事件的可能机会有：（1）snooping探听（2）kernelmodification内核修改（3）Nerfilter

在下面，每个可能性都被描述，并给出他们的优点和缺点。

3.1.1snooping

决定所需要的事件的一个可能性就是去杂乱的探听所有的输入和输出的分组[8]。执行探听的代码设计在内核中和对用户层程序是有效的，由图4描述的一样。这个探听的特征可以用来决定在第3部分检测到的事件。例如，当一个节点不知道在一跳的MAC层地址时一个ARP包被创建。由这个推论，如果一个ARP包被一个未知目的地接收到并且由本地主机发起的，那么一个路由寻找将被发起。一个类似的行为，通过监视进出的所有包，来决定所有其他的AODV事件。

这个解决方案的最重要的优点是它不需要任何代码运行在内核空间中。所以这个解决方案需要简单的安装和执行。它的两个主要的缺点是加了不必要的头部（overhead）和依赖于ARP。例如某个路由发现的需要是有ARP请求来指出的。自从路由寻找被出去的ARP包发起，这些出去的包被加了不必须的头部，并且浪费了带宽。依赖于ARP也带来了很多问题。如果路由表和ARP缓存变的不同步了，那么路由协议不能实现正确的实现功能是可能发生的。例如，如果一个ARP缓存包含一个到特殊的未知的目的地的入口，因为它没有被路由守护进程所知道，所以这个ARP包没有为这个目的地而创建。结果是，路由寻找没有被发起。对于正确的操作，这个路由协议必须在IP路由表的外部监听和控制ARP缓存，因为它们两的不同可能导致路由协议的不正确执行。

3．1．2kernelmodification内核修改

另外一种决定AODV事件的可能性是去修改内核。代码可以放置在内核中去沟通在section3中所列举的事件与用户层的AODV守护进程。例如，为了发起一个路由寻找，代码加到内核中的路由寻找失败发生的地方。由内核中的这个代码设定，如果一个路由查找失败发生，那么在用户层的守护进程中一个方法被呼叫。图5描述了AODV守护进程的结构和必需的支持逻辑。

这种解决方法的优点是这些事件可以被明确的决定并且没有任何浪费的加在头部前的数据。它主要的缺点是用户的安装和通用性。必要的内核修改的安装需要一个完整的内核重编辑。这个对于需用用户来说是非常难的过程。并且，内核的修改经常是不兼容的在一个修改的版本和另外一个内核之间。最后，理解linux内核和网络协议组要求检查重要的很多的为申明的复杂的代码。

3.1.3Netfilter

Netfilter是在linux协议组中在许多挂钩点的一组过滤子系统，section2.3所描述的一样。Netfilter通过用户自定义的代码来重定向包流，这些代码能为用户层守护进程检测，遗失，丢弃，修改或者排队这些包。用Netfilter和在section3.1.1中描述的探听的方法是很相似的；然而，它没有不必要的加在头前面的数据或则依赖ARP的缺点。

比较其他的可能性，这个解决方法有很多优点。这些优点包括没有不必要的通信，具有很高的通用性，很方便的安装和用户层的守护进程能决定在section3中要求的事件。

在另外一方面，这个解决方法的缺点是它需要一个内核模块。然而，一个内核模块相比内核修改而言是很简单的。仅仅只要编辑一个内核模块，而不需要去编辑整个内核。并且内核模块能在任何时候装载和卸载。最后，一个内核模块比内核修改具有更高的通用性，因为它依赖Netfilter接口。这种接口不随内核的更改而改变。

自从Netfilter通过检查策略使其具有最少和最小的重要性缺陷，我们在我们最后的应用结构中利用了它。如图6所示。我们的应用利用了Netfilter的挂接来重定向了包，接受从本机（NF_IP_LOCAL_OUT），从别的机器（NF_IP_PRE_ROUTING），还有所有的被发送到其他机器（NF_IN_POST_ROUTING）的包。这些挂接函数被kaodv内核模块使用。Ip_queue模块是用来在用户层守护进程中对这些包进行排队。这些AODV守护进程用libipq来对每个包做控制决定。

3.2决定本地连接

为了避免浪费带宽和能量，去确定下一跳在它的传输范围内并且下一跳希望接收这个包对于一个数据包的发送者来说是非常有益的。为了校验下一跳正在接收数据，本地连接必须被监控。没有能力发送数据给邻居的通告需要立即通告源节点路由路径截断了；否则节点继续发送数据包，浪费资源。AODV路由协议用RERR去通告源节点和断开链路上的去源的所有节点。因为其他的解决方法并不是立即是有效的，所以现在所有的应用方案都是利用Hello消息。不幸的是，Hello消息在许多普遍的关节[3，10]表现是很差的。

4、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]。

5.结论

在这篇文章中，我们分析了一个AODV应用的可能设计。我们首先定义了在实现路由功能时AODV所不支持的几个事件。我们检查了决定这些消息的三种策略的优点和缺点。这个分析支持我们的包含小的内核模块的用户层守护进程的结论。最后，我列举了现在公布的有效的AODV应用的设计。我们希望文章中的消息能帮助研究者理解在adhoc路由协议应用发展中的过时现象？（trade-offs）。再者，设计结构的描述和另外的每个应用的特征能帮助拥护决定哪个应用方案适合他们的需要。

参考文献：

[1]NovaRoam.http://www.novaroam.com/.

[2]I.D.Chakeres.AODV-UCSBImplementationfromUniversityofCaliforniaSantaBarbara.http://moment.cs.ucsb.edu/AODV/aodv.html.

[3]I.D.ChakeresandE.M.Belding-Royer.TheUtilityofHelloMessagesforDeterminingLinkConnectivity.InProceedingsofthe5thInternationalSymposiumonWirelessPersonalMultimediaCommunications(WPMC),pages504–508,Honolulu,Hawaii,October2002.

[4]IEEEComputerSociety.IEEE802.11Standard,IEEEStandardForInformationTechnology,1999.

[5]J.Kadlecsik,H.Welte,J.Morris,M.Boucher,andR.Russell.Netfilter.http://www.netfilter.org/.

[6]V.Kawadia,Y.Zhang,andB.Gupta.SystemServicesforImplementingAd-HocRouting:Architecture,ImplementationandExperiences.InProceedingsofthe1stInternationalConferenceonMobileSystems,Applications,andServices(MobiSys),pages99–112,SanFrancisco,CA,June2003.

[7]L.Klein-Berndt.KernelAODVfromNationalInstituteofStandardsandTechnology(NIST).http://w3.antd.nist.gov/wctg/aodvkernel/.

[8]F.Lilieblad,O.Mattsson,P.Nylund,D.Ouchterlony,andA.Roxenhag.Mad-hocAODVImplementationandDocumentation.http://mad-hoc.flyinglinux.net.

[9]H.Lundgren,D.Lundberg,J.Nielsen,E.Nordstrm,andC.F.Tschudin.ALarge-scaleTestbedforReproducibleAdhocProtocolEvaluations.InIEEEWirelessCommunicationsandNetworkingConference2002(WCNC),March2002.

[10]H.Lundgren,E.Nordstrm,andC.Tschudin.CopingwithCommunicationGrayZonesinIEEE802.11bbasedAdhocNetworks.TechnicalReport2002-022,UppsalaUniversity

DepartmentofInformationTechnology,June2002.

[11]C.E.Perkins,E.M.Belding-Royer,andS.Das.AdhocOn-DemandDistanceVector(AODV)Routing.RFC3561,July2003.

[12]C.E.PerkinsandE.M.Royer.TheAdhocOn-DemandDistanceVectorProtocol.InC.E.Perkins,editor,AdhocNetworking,pages173–219.Addison-Wesley,2000.

各种方案的源码下载：

1、Kernel-AODV，http://w3.antd.nist.gov/wctg/aodv_kernel/

2、AODV-UU，http://www.docs.uu.se/docs/research/projects/scanet/aodv/aodvuu.shtml，

http://linux.softpedia.com/get/System/Networking/AODV-UU-15587.shtml

3、Ad-hocSupportLibrary（ASL），AODV-UIUC，http://sourceforge.net/projects/aslib/

4、AODV-UCSB，http://moment.cs.ucsb.edu/AODV/aodv.html#Implementations

5、Netfilter，http://www.netfilter.org/

6、Mad-hoc，http://csd.ssvl.kth.se/2000/group4/madhoc/docs/ourimplementation.htm

7、AODV-ST，http://www.cs.ucsb.edu/~krishna/aodv-st/

8、NST-AODV，http://www.i2cat.net/i2cat/servlet/I2CAT.MainServlet?seccio=13_6_2