DIY编程器网

标题: 基于组播代理的移动组播实现机制研究 [打印本页]

作者: admin 时间: 2014-10-13 14:57
标题: 基于组播代理的移动组播实现机制研究
一、前言
随着移动通信3G时代的来临以及手机功能的日趋强大，人们对移动通信的需求已不再满足于原有的语音话务和短信业务，大量基于视频和音频的多媒体业务涌现出来，如视频点播、电视广播、视频会议、网上教育、互动游戏等。此类业务的共同特点是：多个用户同时接收相同数据，对数据传输的实时性要求较高，对少量数据包的传输错误和丢失可以容忍。移动多媒体业务和一般数据业务相比，还有数据量大、持续时间长、时延敏感等特点。

图1 单播、广播和组播的传输方式

目前此类业务在IP网上几乎都是采用IP组播的方式来实现的。IP网通信包括三种通信方式（如图1所示）：单播（Unicast）、广播（Broadcast）和组播（Multicast）。单播是指源主机向指定单个目标主机发送数据信息，单播连接是一一对应的，即一个发送者只能对应一个接收者；广播指源主机向一个网络段中的所有主机发送数据信息，即该网段所有主机都可以接收这个数据信息；组播介于单播、广播之间，源主机向网络中特定的一组主机发送数据信息，这些主机是靠组播地址来指定的。
相对于单播，组播技术可以实现一对多，或者是多对多的数据传输，极大地减轻了网络和源主机的负载，提高了传输效率；相对于广播来说，组播技术能灵活地将信息发给指定的组成员，而不是网段中所有的主机，同时通常广播仅限制在本网段内，不能通过路由器进行转发。
二、移动组播的研究现状
2.1 移动组播面临的问题
在IP网络中，每个组播成员的IP地址在一个组播会话中是固定不变的，因此，IP网络组播对组播组成员的管理、建立和维护组播树相对比较简单；在移动网络中，即使在会话过程中组播组成员没有增减，但是由于每个成员的地址在不断变化，也会导致整个组播树的不稳定。这将使移动网络组播组的维护和管理变得较为复杂。
由于组成员的移动性，移动组播在实现过程中主要存在以下几个问题：
   (1) 组播树的维护管理
   现有组播路由协议，如DVMRP（距离矢量组播路由选择协议）、MOSPF（Multicast-Open Shortest Path First）、CBT（核心树）等都是基于组成员地址是固定的这样一个前提，如果组成员发生移动，这些协议处理机制采用对原有组成员进行“剪枝”，而后新增一个组成员的方式进行管理。这种方式对于IP网络组成员几乎不移动的情况是实用的，但是对于移动网络，由于组成员频繁移动，会导致组播树频繁地进行“剪枝”和新增组成员。因此，移动网络中组播树非常不稳定，同时组播树的管理和维护会产生大量开销。
   (2) 组成员的切换延时
   IETF的移动IP协议定义了家乡代理(home Agent，简称HA)、外地链路、外地代理(foreign Agent，简称FA)、通信对端等概念，一个移动节点拥有两个IP地址：家乡地址和转交地址。节点在移动过程中，家乡地址不改变，发送到该节点的数据都通过家乡地址与转交地址之间的隧道转发给移动节点。当组成员切换时，包括网络链路间切换的固有时延，以及重新加入组播组以及建立组播转发树的时延，都将导致组播成员丢包。
   这是移动组播相对于IP组播最突出的两个问题，在设计移动组播协议过程中需要重点加以考虑。
2.2 现有的移动组播协议
移动IP协议中提出了两种组播方案：“双向隧道”和“远程加入”，以下对这两种协议进行说明和简单比较。
   2.2.1 双向隧道
   双向隧道(bi-directional tunnel，简称MIP-BT)是指在移动节点与家乡代理之间建立双向隧道，移动节点通过双向隧道加入/退出组播组，并且通过该隧道发送和接收组播包。移动节点通过隧道向家乡代理发送IGMP（组管理协议）报文，请求加入组播组。而后家乡代理加入组播树中，并将组播包通过隧道以单播的方式发送给移动节点；移动节点向组播组发送数据时，也是首先通过隧道将组播包发送给家乡代理，然后由家乡代理以组播的形式发送该组播包。
   双向隧道方式有效地解决了因组成员切换给组播树造成频繁调整的问题，减少了计算量和通信负担。但是，双向隧道也存在三角路由以及“隧道聚集”问题。三角路由不是最佳路由，会给链路带来很大的开销；外地代理有可能通过隧道从不同的家乡代理收到多个重复的组播数据包从而产生“隧道聚集”问题，导致链路带宽资源的严重浪费。
   2.2.2 远程加入
   远程加入(remote subscription,简称MIP-RS)是指移动节点改变地址后重新加入到组播组中，并由组播协议重新计算组播树。远程加入方式最大的优点在于无须建立外地代理和家乡代理之间的隧道，因此也就不存在隧道聚集问题。同时，组播数据包能够沿着最优路径进行转发，避免了三角路由问题。
   远程加入存在的问题是：首先，节点每次移动都需要重新计算并建立整个组播树，这会影响组播树的稳定性，给组播树的管理和维护带来较大的开销；其次，在频繁切换过程中，退出和重新加入组播组都会产生较大的切换时延，从而导致播包丢失，影响组播应用的可靠性，尤其是在节点快速移动、频繁切换的情况下这个问题尤为突出。
三、基于代理的移动组播协议ABMoM
针对双向隧道和远程加入存在的问题，本文提出了一个基于区域代理的移动组播的实现机制——ABMoM（Agent-based mobile multicast ）。
3.1 ABMoM的基本原理
ABMoM中引入了组播代理（multicast agent，简称MA）的概念，MA可以代替移动节点加入某个组播组，接收该组播组的数据。移动节点（mobile host，简称MH）在一个子网中，如果要加入某个组播组，就向当地子网的MA发送一个加入请求，在MA向组播路由器发送加入组播组的请求后，通过组播路由协议建立到该MA的组播树。
MA接收到组播组的数据包后，通过单播的方式发送给MH，而MH发往组播组的数据也通过MA来转发。整个ABMoM的原理如图2所示。

图2 ABMoM网络结构

3.2 ABMoM组播组加入机制
在ABMoM协议中，子网的组播代理MA担任了重要角色，MA负责子网中所有组播组成员管理。
移动节点MH加入某个组播组，首先向MA发送一个组播组加入请求，该请求包含该组的组播地址以及MH的地址。MA将首先查阅本地维护的活跃组播组列表，如果发现MH要加入的组播组在本地活跃的组播组列表中，就将MH的地址添加入该组播组成员列表中，一旦接收到该组播组的数据即可通过单播的方式转发给MH。
如果MA查阅到MH请求加入的组播地址并不在本地活跃的组播组中，将向上游的组播路由器发送IGMP报文，请求加入该组播组。加入成功后，MA在本地的活跃组播组列表中添加该组播地址，并将MH加为该组播组的成员。当后续还有MH要加入该组播组时，MA无须再向上游路由器发送报文，而是直接将该MH加入到该组播组的成员列表中，进行单播数据转发即可。
在ABMoM机制中，MA不仅担当了部分组播路由器的角色，同时负责组播子树的管理。而在区域内发生组播成员的加入和退出时，一般情况下都不会影响整个组播树，只有当该区域第一个组播组成员加入和最后一个组播组成员离开时，才需要重建整个组播树，因此ABMoM可以保证组播树的相对稳定。
3.3 ABMoM组播组退出机制
在IGMP协议中，IGMPv1通过组播路由器发送查询报文来查询某一个端口下是否还有组播组成员；IGMPv2则由组播组成员主动向组播路由器发送退出组的消息。当一个MH要退出某个组播组时，ABMoM也有两种机制进行处理： MH主动向MA发送退出组播组的请求；MA主动发现MH已经退出组播组。
如图3所示，当MH要退出某个组播组时，主动向MA发送退出请求，MA接收到该请求，查询该组播组的成员列表并将该成员从列表中删除。如果该MH非该组播组的最后一个成员，MA只是简单地停止向该MH转发数据包；如果该MH是该组播组的最后一个成员，则当它退出后，该区域中无该组的其他成员，为了节省带宽资源，MA需要向上游路由器发送退出请求，或者是由上游路由器进行自动“剪枝”。MA并非在该组最后一个成员离开后就立即发送退出请求，而是要滞后一段时间查看该区域是否有新的MH加入。这种机制对于移动组播是非常必要的，可避免MA因MH的移动而频繁加入退出组播组，导致组播树的不稳定。
在另一种机制中，MH不向MA发送退出请求而直接拒收自MA转发的组播数据包，因此MA必须有主动发现MH退出组的机制。在ABMoM机制种，MA定期向组播组成员发送查询报文，MH如果仍然在组播组活跃，则在接收查询报文后立刻响应一个活跃报文告知MA，否则MH对MA发送过来的查询报文不做任何响应。MA在发送完查询报文后，在本地启动一个计时器，如果计时器超时还没收到响应的活跃报文，MA将向该MH再次发送查询报文，如果连续三次都未收到MH的活跃报文，则MA认为该MH已经退组，将把MH从组播组成员列表中删除。

图3 ABMoM中MH退出组播组

3.4 ABMoM的切换机制
移动组播协议关键是在节点移动状态下要保证组播数据能及时地传送到节点。
当一个组播组成员改变网络中位置的时候，ABMoM协议的处理机制是：该节点在原有的网络中退出该组播组，然后在新的网络中又加入组播组。
如图4所示，B为一个移动节点，在网络A中加入了组播组224.2.0.1，并通过C（C为网络A中的MA）进行组播代理。当B移动到网络A′后，B向网络A′中的组播代理C′发送加入组播组224.2.0.1的请求。
在极端的情况下，网络A中组播组224.2.0.1只有C一个组播成员且网络A中后来也无其他MH加入组播组224.2.0.1，C将通知上游路由器退出组播组224.2.0.1，这时候需要重新构建组播树；而在网络A′中，原来也没有组播组224.2.0.1的组成员，当B要求加入组播组224.2.0.1时，网络A′中的组播代理C′需要向上游网络路由器发送加入组播组224.2.0.1的请求，然后向B转发该组的组播数据包，这时的切换有可能因为切换时延而导致组播数据包丢失。
在组播组成员相对集中的情况下，ABMoM性能将会好很多。B不是网络A中组播组224.2.0.1中最后一个成员，在离开网络A时仅需要组播代理C将B从组播组成员列表中删除，而对整个组播树没有任何影响；而B在移动到网络A′中后，如果A′中已经有组播组224.2.0.1的组成员，B向C′申请加入该组播组，那么C′只需将B加入本地的组播成员列表中即可，这样B在网络中移动时可不影响组播树而退出、进入组播组。同时，ABMoM要求区域组播代理MA具有一定的数据包缓冲能力，可以在一定程度上处理因移动切换时延带来的丢包问题。

图4 ABMoM中MH在网络中移动

四、结论
ABMoM引入了组播代理MA的概念，在组播组成员相对集中的环境中，可以很好地解决移动网络中组播面临的问题。
与双向隧道的移动组播机制相比，ABMoM不需要在家乡代理和外地代理之间建立双向隧道，可以较好地避免“隧道聚集”和三角路由问题；与远程加入方式相比，ABMOM无须为移动节点每次加入和退出重新计算组播树，避免了组播树的频繁重建，减少了网络资源消耗，同时ABMoM中MA采用了数据包缓冲机制，在一定程度上可以解决因网络切换造成的丢包问题。
参考文献
[1] “Internet Protocol (IP) Multicast Technology Overview”, Cisco Systems,2000
[2] Beau Williamson, “Developing IP Multicast Networks, Volume1,” Cisco Press, Jan.2000.
[3] Perkins C. IP mobility support for IPv4. RFC 3344, Internet Engineering Task Force, 2002.
[4] Johnson D, Perkins C, Arkko J. Mobility support in IPv6. Internet Draft, draft ietf mobileip ipv6 21.txt, Internet Engineering Task Force, 2003.
[5] 吴茜,吴建平,徐恪,刘莹, 移动Internet中的IP组播研究综述,软件学报，/2003/14(07)
[6] Johnson D, Perkins C, Arkko J. Mobility support in IPv6. RFC 3775, 2004.
[7] Chikarmane V, Williamson C, Bunt R, Mackrell W. Multicast support for mobile hosts using mobile IP: Design issues and proposed architecture. Mobile Networks and Applications, ACM/Baltzer Mobile Networks and Applications, 1998,3(4):365~379.

欢迎光临 DIY编程器网 (http://diybcq.com/)