基于ODMRP的可靠多播路由协议

合集下载

Ad Hoc网络中群组播路由协议的研究和改进

Ad Hoc网络中群组播路由协议的研究和改进移动ad hoc网络(MANET)是一种新兴的自组织、不需要铺设任何基础设施的多跳无线网络。

由于这些特点,MANET在许多领域都有大规模的应用,如:协同计算、危机应对(如灾难恢复)等。

MANET中的节点可以自由地移动,彼此间直接或是通过多跳路由进行通信,所以路由协议是自组网中不可缺少的一部分。

自组网路由协议的主要设计目标是:满足应用需求的同时尽量降低网络开销,取得资源利用的整体有效性,扩大网络吞吐量。

本文研究了在使用定向天线进行数据传输的群移动场景之下,几种具有代表性的路由协议ODMRP、M-LANMAR及本文提出的Ripple路由协议的关键技术问题、主要工作机制和协议的优点等。

其中的Ripple路由协议是本文提出的一种对无线ad hoc网络中M-LANMAR组播路由协议的改进机制,是基于“涟漪”机制的群组播路由协议。

这是针对群移动场景下,需要将组播消息在一个组内传播至每个成员节点的需要提出的。

原M-LANMAR组播路由协议的主要问题在于:在现阶段使用的定向天线的条件下,组播消息在组内利用洪泛传送带来天线发送次数的增加和大量冗余消息的发送,从而使得节点能量和网络的性能都有所下降,而利用本文提出的通过在组内使用逐圈向外扩散发送组播消息的机制,改善了原M-LANMAR组播路由协议的性能。

最后,本文分别通过在构建的网格场景中进行数学模型推导和在自己开发的路由协议仿真平台上进行仿真实验,深入比较和分析研究了ODMRP、M-LANMAR和Ripple这三种组播路由协议在当前研究场景下的相关性能。

本文的主要工作如下:讨论了Ad Hoc网络的相关特性和路由协议分类,重点研究了两种代表性的组播路由协议:平面的按需组播路由协议ODMRP和分层的先应式组播路由协议M-LANMAR,并针对M-LANMAR组播路由协议的不足提出了一种改进的路由协议Ripple,扩充了原算法消息结构的域,详细描述了Ripple路由协议的操作流程,并且从数学模型推导和仿真实验验证上分别评估了此研究场景之下上述三种组播路由协议的性能。

组播路由协议

组播路由协议组播路由协议（Multicast Routing Protocol）是一种网络协议，用于支持组播传输，将数据从一个源节点传输到多个目的节点。

组播路由协议通过建立一棵组播树来实现数据的传输，其中源节点作为根节点，目的节点作为叶子节点。

组播路由协议有多种类型，常见的包括DVMRP、IGMP、PIM和MOSPF等。

每种协议都有各自的特点和适用场景。

其中，Distance Vector Multicast Routing Protocol（DVMRP）是一种基于距离向量的组播路由协议。

它使用了类似于BGP的距离矩阵来选择最佳的路径，并通过向邻居节点广播消息来更新路由表。

DVMRP适用于小型网络，但在大型网络中可能产生大量的控制消息。

Internet Group Management Protocol（IGMP）是一种用于在主机和组播路由器之间交换组播组信息的协议。

它允许主机加入和离开组播组，并向路由器报告组播组成员。

IGMP采用了查询-报告机制，通过查询消息和报告消息来维护组播组的成员关系。

Protocol Independent Multicast（PIM）是一种独立于底层网络的组播路由协议。

它可以与各种底层网络协议一起使用，如IP、ATM和Frame Relay等。

PIM使用了两种模式：稠密模式（Dense Mode）和稀疏模式（Sparse Mode）。

稠密模式适用于具有大量组播组成员的网络，而稀疏模式适用于成员分布较不密集的网络。

Multicast Open Shortest Path First（MOSPF）是一种基于OSPF协议的组播路由协议。

它通过向OSPF协议添加组播扩展来支持组播传输。

MOSPF使用与OSPF相同的链路状态数据库（LSDB）和最短路径树（SPF）算法来计算最优的组播路径。

无论是哪种组播路由协议，其基本目标是找到一条最佳的路径，以最小的开销实现数据的组播传输。

基于节点相对移动性的自适应按需组播路由协议

基于节点相对移动性的自适应按需组播路由协议夏利;田东渭;刘宗奇【期刊名称】《计算机科学》【年(卷),期】2012(039)009【摘要】This paper presented a kind of relative mobility of nodes based adaptive demand-driven multicast routing protocol RMNAM. RMNAM protocol inherits the on-demand features of ADMR protocol , and introduces the concept of relative mobility of nodes. On the one hand, the protocol uses the relative mobility of nodes as an important factor in multicast forwarding tree , which improves the robustness of the multicast paths; on the other hand , the protocol optimi-zes the transmission switching strategy of source node by consulting the global repair frequency and the average relative mobility of nodes to promote adaptability. The simulation results show that RMNAM protocols improve ADMR protocol in the packet delivery ratio and transmission delay, and it keeps the advantages of effectiveness and scalability compared with ODMRP.%提出一种基于节点相对移动性的自适应按需组播路由协议RMNAM.RMNAM协议继承了ADMR协议的按需特性,并引入了节点相对移动性的概念.一方面,协议使用节点相对移动性作为组播转发树路径选择的重要依据,以提高组播转发树的健壮性；另一方面,协议将接收节点执行全局修复的频率与组播树各路径平均节点相对移动性信息相结合,对源节点的传输方式切换策略进行优化,使其具有更好的适应性.仿真实验结果表明,RMNAM在分组递交率和传输时延方面较ADMR有所改进,同时在有效性和扩展性方面保持了对ODMRP的优势.【总页数】4页(P94-96,100)【作者】夏利;田东渭;刘宗奇【作者单位】东北大学信息科学与工程学院沈阳110004;东北大学信息科学与工程学院沈阳110004;东北大学信息科学与工程学院沈阳110004【正文语种】中文【中图分类】TP393.03【相关文献】1.基于树的按需Ad Hoc组播路由协议性能比较和分析 [J], 徐瑞;李伟华;陈华胜2.基于自适应能量阈值的按需节能组播路由协议 [J], 段国建;郝洁;姚郑;张宝贤;3.基于自适应能量阈值的按需节能组播路由协议 [J], 段国建;郝洁;姚郑;张宝贤4.基于泛洪约束的MANET按需组播路由协议 [J], 江国星;梅锐5.基于OPNET的按需组播路由协议仿真 [J], 刘宴涛;秦娜因版权原因，仅展示原文概要，查看原文内容请购买。

自组网下基于多信道和组播的MAC协议(MCMAC)1

自组网下基于多信道和组播的MAC协议（MCMAC）1赵耀、向勇、徐雷鸣、史美林（北京清华大学计算机科学与技术系 100084）zyao@摘要:多信道技术是利用多个信道在同一区域并行传输从而提高无线网络传输能力的MAC层技术，目前主要针对单播通信。

在无线网中，组播数据的发送一般采用广播的方式，这使得它无法利用多信道带来的吞吐量提高的好处。

本文提出一种基于多信道针对组播的MAC层算法MCMAC，能与绝大部分已有的组播路由算法既协同工作而又互相独立，并且提高了组播通信的吞吐量和传输效率。

同时，为了在MAC层提供一定的可靠性保证，在MCMAC的基础上又扩展出了RMCMAC协议。

我们以ODMRP协议为上层组播协议示例，通过模拟仿真实验比较，验证了MCMAC协议和RMCMAC协议在组播通信的吞吐量和可靠性方面相比传统单信道MAC协议的优势。

　关键词：MAC; 组播; 路由; 自组网; 多信道1. 简介无线自组网是最近涌现出的无线网络，其特点就是没有固定的基站，其中所有的节点都能任意地移动，并且可以采用任意的方式进行动态的连接，除了无线网络天生的广播特性外最显著的特点就是网络拓扑结构变化频繁和不可预测。

此外，有限的电源储备、相对较低的带宽、高出错率也是自组网中重要的限制条件，因此有线网络的那一套协议体系不能够只做点细枝末节的修改就能适应自组网的要求，而必须做大的修改，从而在自组网的研究中引发了许多新的概念和新的思想。

随着网络技术的发展和各种新应用的产生，组播已经成为Internet中一个重要的应用，例如视频会议、数据分发等应用都要求下层组播路由的支持。

在无线自组网中，组播同样有着许多重要的应用，如灾难恢复、搜索和救援以及自动化战争应用等。

常见的组播协议有MAODV、ADMRP、AMRIS、 AMRoute、ODMRP（On-Demand Multicast Routing Protocol）[2]、FGMP、CAMP等。

PIMSM协议稳定多播传输的关键协议

PIMSM协议稳定多播传输的关键协议在计算机网络中，多播传输是一种将数据同时发送给多个接收者的通信方式。

然而，多播传输面临着诸多挑战，例如网络拓扑的复杂性、带宽利用率的问题以及数据可靠性的保证。

为了解决这些问题，PIM-SM（Protocol Independent Multicast-Sparse Mode）协议应运而生，成为了稳定多播传输的关键协议之一。

PIM-SM协议采用了一种分布式的多播传输路由选择机制，称为源特定树（Source Specific Tree）。

其核心思想是，对于每个多播组，只有一棵树负责从源节点向所有接收者传输数据。

这种树的构建通过源节点发送特殊的数据包来完成，数据包经过网络中的路由器，根据PIM-SM协议规定的转发逻辑来建立具体的传输路径。

这种树的构建方式灵活且高效，能够适应网络拓扑的变化，并降低了传输路径上的冗余。

另外，PIM-SM协议还引入了Rendezvous Point（RP）的概念，用于协调多播组源节点和接收者之间的数据传输。

RP相当于多播组的管理员，它的任务是确定合适的路径，将源节点的数据传输给接收者。

RP的选择可以基于静态配置，也可以通过自动选择算法来确定。

无论是静态配置还是自动选择，RP的选取都需要保证网络性能和传输效率。

在PIM-SM协议中，数据的可靠性主要依靠网络层的转发机制。

当接收者加入一个多播组时，它将发送Join请求给到RP，并加入特定的源树。

源节点根据接收者的Join请求，将数据传输到RP，然后RP再将数据发送给接收者。

这种机制保证了数据从源节点到接收者的可靠传输，同时也减少了网络中的冗余传输。

PIM-SM协议不仅仅只支持单播网络，也可以支持多种类型的网络，例如广播网络、点对点网络以及混合网络。

它的灵活性使得它成为了广泛应用于Internet和互联网服务提供商（ISP）等基础设施中的多播传输协议。

总结起来，PIM-SM协议是一种分布式的稳定多播传输协议，通过源特定树的构建机制和Rendezvous Point的协调选择策略，保障了多播数据的可靠传输。

组播路由协议

组播路由协议组播路由协议是用于支持组播传输的网络协议，它们允许网络中的多个主机共享相同的数据流。

组播路由协议通常用于视频会议、流媒体和在线游戏等应用中，能够有效地减少网络流量和提高数据传输效率。

在组播通信中，数据包只需在网络上传输一次，然后被路由器复制并发送到所有的接收者。

这种方式与单播和广播通信相比，能够显著减少网络带宽的占用，因此在大规模数据传输和多播会话中非常有用。

常见的组播路由协议包括IGMP（Internet Group Management Protocol）、PIM （Protocol Independent Multicast）和MSDP（Multicast Source Discovery Protocol）等。

IGMP协议用于主机和路由器之间的通信，以便路由器知道哪些主机对特定组播组感兴趣。

PIM协议则用于路由器之间的通信，以便它们能够有效地转发组播数据包。

而MSDP协议则用于在不同的组播域之间传递源信息。

IGMP协议是组播路由协议中最基本的一环，它允许主机向所在的局域网路由器表明自己对哪些组播组感兴趣。

一旦路由器收到主机的加入请求，它就会向其他路由器发送消息，以便它们也能够知道这个组播组的存在。

PIM协议则负责在不同的路由器之间传递组播数据包，确保它们能够有效地到达所有的接收者。

MSDP协议则用于在不同的组播域之间传递源信息，以便它们能够相互通信和传输数据。

在实际网络中，组播路由协议的选择和配置非常重要。

不同的协议有不同的特点和适用场景，需要根据网络的实际情况进行选择。

同时，正确的配置和管理也能够提高网络的性能和稳定性，减少网络故障和安全风险。

总的来说，组播路由协议在网络通信中起着非常重要的作用。

它们能够有效地减少网络流量，提高数据传输效率，同时也能够支持大规模的数据传输和多播会话。

因此，在构建和管理网络时，需要充分考虑组播路由协议的选择和配置，以便实现更高效、更稳定的网络通信。

多媒体通信中基于可靠性检验的可靠多播路由算法

多媒体通信中基于可靠性检验的可靠多播路由算法
李怡
【期刊名称】《飞行器测控学报》
【年(卷),期】2006(025)006
【摘要】针对多媒体通信中的可靠性问题,提出了一种基于可靠性检验的可靠多播路由算法,使得用于可靠多播通信的网络资源最小.该算法针对一棵给定的、未考虑可靠性的初始多播树,分别计算源节点到每个多播节点路径上的可靠性,如果该可靠性不能满足相应的可靠性要求,则修改或改变多播树中源节点到此多播节点的路径,使其满足相应的可靠性要求.
【总页数】5页(P59-63)
【作者】李怡
【作者单位】西安卫星测控中心·陕西渭南·714000
【正文语种】中文
【中图分类】TN919.8
【相关文献】
1.多媒体通信的多播路由算法 [J], 刘莹;刘三阳;吴建平
2.BPSK信号盲处理结果的可靠性检验算法 [J], 胡国兵;刘渝
3.多媒体通信中带度约束的多播路由算法 [J], 刘莹;刘三阳
4.异质性网络多媒体通信的多播路由算法 [J], 廖敬一;裘正定
5.地图合并中基于叠置方法的特征点匹配可靠性检验 [J], 臧德彦;陶本藻;周世健
因版权原因，仅展示原文概要，查看原文内容请购买。

Linux下IGMP以及多播路由分析

Linux下IGMP以及多播路由分析(转载)最近在做多播这块,顺带研究了一下Linux Kernel对IGMPv3以及多播路由的支持.先简单介绍IGMPv3,一个网络协议总的说来无非多是"一问,一答",当然也有主动的去"报告",IGMPv3也不例外.1.看过IGMPv2以及v1的人会奇怪为什么要v3,v3能带来些什么?1>.IGMPv2/v1是典型的接受任意源多播(Any-Source Multicast)[ASM],即它只是关注多播组,而不关注是谁发送的,这样会有一些问题,比如说,假如一个局域网存在一个多播视频服务器,其它Host在上面点播视频;假如出现一个伪装者,也向这个多播组发送干扰数据,但Host无法辨别,这样可能引起视频的接受断断续续,影响服务的提供,显然这不是很理想;而IGMPv3的提出,就是为了解决这个问题,它提出了源特定多播(Source-Specific Multicast)[SSM],不仅关注多播组,也关注发送多播组的源.2>.包的类型IGMPv3主要有两种包:Type Number (hex) Message Name----------------- ------------0x11 Membership Query0x22 Version 3 Membership Report基于兼容的原因,还有IGMPv2/v1的几种包:0x12 Version 1 Membership Report [RFC-1112] 0x16 Version 2 Membership Report [RFC-2236] 0x17 Version 2 Leave Group [RFC-2236] 关于协议部分更详尽的细节,参考RFC3376(IGMPv3),RFC2236(IGMPv2),RFC1112(IGMPv1)2.Linux Kernel的IGMPv3以及多播路由的实现仔细看了这部分的代码,主要的文件比较少,分别为:igmp.c 内核实现的对IGMP的实现,可以兼容v2/c.ipmr.c 看文件名自然就可以猜测是多播路由的实现.其中,值得参考的文档是Sprint Labs的两份文档,一份是实现架构,一份是测试计划,不过从我读Code来看,这两份文档只具备参考意义,因为kernel的实现并不是按照其实现架构文档来实现的,看igmp.c/ipmr.c的文件注释可以知道多播部分的实现是其它人来实现的,并不遵循该设计文档(也许该实验室是准备实现的,但最终由于某些其它原因由其它人来实现,并且没有采取其设计文档),不过设计思想值得参考,实际的实现比那份设计文档要简洁一些.下面看看一些具体的数据结构,由于部分成员我也没看懂做什么用处,如果你知道,请告诉我:)net_device{}--------| |<------------------|~~~~~~~~| in_device{} ||--------| --------- || ip_ptr |--->| dev |----|--------| |---------|<------------------| | |~~~~~~~~~| ip_mc_list{} ||~~~~~~~~| |---------| --------- |-------- | mc_list |--->|interface|----|---------| |---------||~~~~~~~~~| |multiaddr|--------- |---------||~~~~~~~~~|---------通过上图可以看到3个结构之间的部分关系,我简单说说这三个结构:net_device:针对每个网络设备的一个抽象,比如你用ifconfig看到的eth0,就对应了一个该结构实例.in_device:针对IPv4的网络部分的描诉,因为Linux支持不仅仅是TCP/IP协议族,还用ATM等等,其底层设备是不同的,而对与网络设备的通用部分,用net_device{}描述,而针对不同协议私有部分,则使用不同结构,支持IPv4的设备,就使用该结构.ip_mc_list:描述的自然是IP设备的多播相关信息,我只花出了一个multiaddr,举例说来,我们说"eth0加入了多播组224.0.0.1",multiaddr就记录了该设备加入的一个多播组:224.0.0.1因此,结合上图,可以基本知道一个网络设备,如何记录它加入的多播组.下面来看igmp的处理流程:--------|ip_rcv()|[IP层的总入口]--------|V------------------|ip_local_deliver()|[本地分发,即目的地为本地]------------------|V----------|igmp_rcv()|[分发到IGMP的处理入口] ----------|V------------------------| [处理查询] |[处理报告]V V------------------ -------------------|igmp_heard_query()| |igmp_heard_report()|------------------ -------------------[开始计时器]| ++++++++++++++ |[停止计时器]----> +ip_mc_list{}+<----++++++++++++++|V------------------|igmp_send_report()|------------------在上面的文档里简要介绍了kernel对IGMP包的处理,其实下面才是重点,kernel 怎么处理多播包呢?即多播包怎么路由呢?这又涉及到UNIX常用的一个哲学"数据路径要分离于控制路径(最常见的说法是策略与机制,上面的说法是我自己理解后表述的,因为我老把这两者弄反,呵呵:))",这实际上是两个分离的问题:1).多播包在内核中怎么样被处理?2).该使用什么方法在应用程序中向内核添加路由?说道这里,我再次强调一下,注意区分在网路中的常见角色"Host"和"Router",时刻记得它们本质的区别是重要的:),它们最重要的区别在于是否能够转发包.好了,我们来依次解决上面的两个问题:我们不去考虑MAC层对多播的处理,只是理解就可以了,记得网络设备在MAC层可以实现一个不完全的过滤就可以了,相关知识,参考<TCP/IP详解>卷一,下面我们从IP层开始考虑(认为网卡支持多播,不过现在不支持多播的网卡很少了,呵呵)1>.多播包在kernel的处理流程自然,还是从ip_rcv()起步:),呵呵.##################################################################### ######--------|ip_rcv()|[IP层的总入口]--------|[单播的路由查找入口] V--------------------- ----------------|ip_route_input_slow()|<--|ip_route_input()|[路由查找总入口]--------------------- ----------------|[本地分发] V------------------- -------------------|ip_local_deliver() |<--|ip_route_input_mc()|[多播路由查找入口] ------------------- -------------------|V ***------------- *K*[在MFC中查找] |ip_mr_input()|[多播路由查找入口] *E*++++++++++++++++++ ------------- *R*+Multicast Forwar+------------->| *N*+ding Cache +<-------------V *E*++++++++++++++++++ --------------- *L*^ | |ip_mr_forward()|[根据找到的多播路由转发] ***| | --------------- || | V===================================================================== ======| V ^------------------- ||iset/getsocketopt()|[在应用层添加/删除多播路由] ***------------------- *A**P**P****##################################################################### ####上面是一个简要的流程,下面来稍微具体的谈谈:首先还是以关键的数据结构为开始:(给我看你的流程图而藏起你的表，我将仍然是莫名其妙。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

ＡｉＦｒｅＲｄｒａｅ，ｈｎ４０９ＣｉａｒｏｃａａＡｃｄｍｙＷｕａ３０１，ｈｎ）
［ｓｒｃ］ＡｒｖｄｒｌｂｅｍｕｔａｔｏｔｇｐｏｏｏｒｓｎｅａｅｎＯｎｄｍａｄＭｕｔａｔｏｔｇＰｏｃｌＤＭＲＰ．ｈｒｔｃｌＡｂｔａｔｎｉｏｅｉｌｌｃｓｒｕｎｒｔｃｌｓｅｅｔｂｓｄｏ —ｅｎｌｃｓＲｕｎｒｔｏ（ｍｐｅａｉｉｉｐｄｉｉｏＯ）Ｔｅｏｏｏｐ
个非重复的ＪｉＲｑｅｔｏｎｅｕｓ分组时，它保存上游节点ＩＤ并重新
广播该分组。如果该节点同时为组接收者，则节点更新成员列表中的源节点信息，并构造一个ＪｉａｌｏｎＴｂｅ分组并广播给邻居节点。因此，多播组的成员可能同时成为转发组成员。（）２应答阶段：ＪｉａｌｏｎＴｂｅ包含了该节点到各个源节点的反向路径的下一跳的ＩＤ，当邻居节点收到Ｊｉａｌ，如ｏｎＴｂｅ时
１概述
Ａｏｄｈｃ网络作为一种多跳的临时性自治系统，其中的每个无线节点都是对等的，并且均具有路由和报文的转发功能，可以通过无线连接构成任意动态变化的网络拓扑结构。
其网络具有无需架设网络基础设施、可快速展开、抗毁性强
（）求阶段：当多播源节点有数据需要发送时，源节点１请周期性广播扩散一个Ｊｉｅｕｓ分组，当一个节点收到一ｏｎＲｑｅｔ
（．ｐｒｎｆａｕｔＭａａｅｎ；．ｐｒｎｆｒｒｉｇＳｒｅｌｎｅｎｅｌｅｃ，ａＤｅａｔｔｄａｅｎｇｍｅｔｂＤｅａｔｍｅｏＧｒｍｅｔｌＷａｎｎｕｖｉａｃｔｌｇｎｅｏＥａｙｌＩｉ
［ｙｗｒｓＡｏｅｗｏｋｒｌｂｅｍｕｔａｔＯ —ｅｎｌｃｓＲｕｎｒｔｃｌＤＭＲＰ；ｇｔｅｋｏｌｇｍｅｔＫｅｏｄ］ｄｈｃｎｔｒ；ｉｌｌｃｓ；ｎｄｍａｄＭｕｔａｔｏｔｇＰｏｏ（ｅａｉｉｉｏＯ）Ｎｅａｖｎｗｅｅｎ（ｉＡｃｄＮＡＣＫ）ＤｏＩ１．９９．ｓ．００３２．０１１．４：０３６／ｉｎ１０ —４８１．８２ｊｓ２０
第３７卷第１期８
、ｏ．７，１３
・
计
算
机
工
程
２１０１年９月
Ｓｅｅｐｔｍｂｅ０１ｒ２１
Ｎｏ．８１
ＣｏｍｐｔｒＥｎｉｅｒｎｕｅｇｎｅｉｇ
网络与通信・
文章编号ｔｌ０＿３２（ｌ１—ｏ７—０文献标识码ｔ０ｏ－４８０１８０ｌ３２）Ａ
ｕｓｎｉｇＮＡＣＫｇｇｅａｏｓｔｏｎａｎｎｍｂｒｏｏｔｏｒｕｓｐｅｏｄｔｏ．ＴｅｌｓｅｅｔｆｄａａｐｃｅｎａｕｔａｅｃｎａｉｅｎａｒｇｔｎｉｏｃｔｉｕｅｆｃｎｒｌｇｏｐａｒｃｎｉｎｈｏｓｖｎｓｏｔａｋｔｉｍｏｎｅｔｌｄｉｉｉｒｒｚａｌｇｒｇｔｄＮＡＣＫ．ＴｈｇｒｇｔｄＮＡＣＫｓａｄｅｎｏＪｉｂｌｒｕｅｌｅｔｅｒｔａｓｓｉｎｂａｅｏｅｔｅｅｉｂｌｌａｇｅａｅｅａｇｅａｅｉｄｄｉｔｏｎＴａｅｇｏｐｔｒａｉｈｅｎｍｉｓｏｙｆｔｒｎｄｇｔｒｌａｅＯＤＭＲＰｏｚｒｈｏｃｍｍｕｎｃｔｏ．ｉｕａｏｅｕｔｈｗｓｔａｅｐｃｅｅｉｅｙｒｔｏｏｅｉｒｖｄｐｏｏｏｎｎｅｏｔｐｔ５ｏｉａｉｎＳｍｌｔｎｒｓｌｏｔａｋｔｄｌｖｒａｉｆｍｐｏｅｒｔｃｌｈａｃｓｍｓｌｕ２．％．ｉｓｈｔｈｈｔｅｙｏ
ＲｅｉｂｅＭｕｔｃｓｕｉｇＰｒｔｃｌｓｄ０ｌｌｌｉａｔａＲｏｔｎｏｏｏＢａｅｎｏＤＭＲＰ
ＹＡＮＧＳｕｃｕＹｈ．ｈｎ。ＡＮＧＲｕｊｅ
中圈分类号ｚＴ３３Ｐ９
基于ＯＤＭＲＰ的可靠多播路由协议
杨树春ａ９杨璃娟，肖玉芬
（空军雷达学院ａ研究生管理大队；．警监视情报系，武汉４０１）．ｂ预３０９
摘
要：基于按需多播路由协议（ＤＰ，出一种改进的可靠多播路由协议。该协议采用集中报错机制，尽量不增加控制分组数目的ＯＭＲ）提在
前提下，将一定数量的数据分组丢失事件集中在一个聚合的ＮＣＡＫ中，并将该ＮＣＡＫ添加到ＪｉＴｂ分组中，通过上游节点重传实现ｏｎａｌｅＯＭＲＤＰ协议的可靠传输。在ＯＮＴ下进行仿真实验，结果表明，与原协议相比，改进协议的数据包投递率提高了２％。ＰＥ．５关健诃：Ａｃ网络；可靠多播；按需多播路由协议；否定应答ｄｏｈ