对于网络当中，我们所使用的路由协议来进行有效的网络优化。那么下面我们将详细阐述一下有关于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)｡再者,设计结构的描述和另外的每个应用的特征能帮助拥护决定哪个应用方案适合他们的需要｡
