IP组播技术综述 （2）

四、组播路由协议

要想在一个实际网络中实现组播数据包的转发，必须在各个互连设备上运行可互操作的组播路由协议。组播路由协议可分为三类：密集模式协议（如DVMRP，PIM-DM）、稀疏模式协议（如PIM-SM，CBT）和链路状态协议（MOSPF），下面分别介绍各个协议的工作原理。

4.1 距离向量组播路由协议（Distance Vector Multicast Routing Protocol：DVMRP）

DVMRP 由单播路由协议RIP扩展而来，两者都使用距离向量算法得到网络的拓扑信息，不同之处在于RIP根据路由表前向转发数据，而DVMRP则是基于RPF。为了使新加入的组播成员能及时收到组播数据，DVMPR采用定时发送数据包给所有的LAN的方法，然而这种方法导致大量路由控制数据包的扩散，这部分开销限制了网络规模的扩大。另一方面，DVMRP使用跳数作为计量尺度，其上限为32跳，这对网络规模也是一个限制。目前提出了分层DVMRP，即对组播网络划分区域，在区域内的组播可以按照任何协议进行，而对于跨区域的组播则由边界路由器在DVMRP协议下进行，这样可大大减少路由开销。

4.2 开放式组播最短路径优先协议（Multicast Open Shortest Path First：MOSPF）

MOSPF是一种基于链路状态的路由协议，是对单播OSPF协议的扩展。
同OSPF类似，MOSPF定义了三种级别的路由：
●MOSPF区域内组播路由：用于了解各网段中的组播成员，构造（源网络S，组G）对的SPT；
●MOSPF区域间组播路由：用于汇总区域内成员关系，并在自治系统（AS）主干网（区域0）上发布组成员关系记录通告，实现区域间组播包的转发。
●MOSPF AS 间组播路由：用于跨AS的组播包转发。
区域内MOFPF利用了链路状态数据库，对单播OSPF数据格式进行扩充，定义了新的链路状态通告（Link State Advertisement：LSA），使得MOSPF路由器了解哪些组播组在哪些网络上。路由器使用Dijkstra算法构造（源网络S，组G）对的 SPT。MOSPF与DVMRP相比，路由开销较小，链路利用率高，然而Dijkstra算法计算量很大，为了减少路由器的计算量，MOSPF执行一种按需计算方案，即只有当路由器收到组播源的第一个组播数据包后，才对（S，G）SPT计算，否则利用转发缓存（cache）中的（S，G）SPT。
MOSPF 继承了OSPF对网络拓扑的变化响应速度快的优点，但拓扑变动使所有路由器的缓存失效重新计算SPT，因而消耗大量路由器CPU资源。这就决定了 MOSPF不适合高动态性网络（组成员关系变化大、链路不稳定），而适用于网络连接状态比较稳定的环境。另外，对于有大量组播源子网络的网络而言，MOSPF的扩展性问题引起了人们的关注，有待于进一步研究。

4.3 协议无关组播（Protocol Independent Multicast：PIM）

PIM 由IDMR（域间组播路由）工作组设计，顾名思义，PIM不依赖于某一特定单播路由协议，它可利用各种单播路由协议建立的单播路由表完成RPF检查功能，而不是维护一个分离的组播路由表实现组播转发。由于PIM无需收发组播路由更新，所以与其它组播协议相比，PIM开销降低了许多。PIM的设计出发点是在 Internet范围内同时支持SPT和共享树，并使两者之间灵活转换，因而集中了它们的优点提高了组播效率。PIM定义了两种模式：密集模式 (Dense-Mode)和稀疏模式（Sparse-Mode）
4.3.1 PIM-DM 
PIM-DM与DVMRP很相似，都属于密集模式协议，都采用了“扩散/剪枝”机制。同时，假定带宽不受限制，每个路由器都想接收组播数据包。主要不同之处在于DVMRP使用内建的组播路由协议，而PIM-DM采用RPF动态建立SPT。
 
 该模式适合于下述几种情况：高速网络；组播源和接收者比较靠近，发送者少，接收者多；组播数据流比较大且比较稳定。

4.3.2 PIM-SM
PIM-SM与基于“扩散/剪枝”模型的根本差别在于PIM-SM是基于显式加入模型，即接收者向RP发送加入消息，而路由器只在已加入某个组播组输出接口上转发那个组播组的数据包。
PIM- SM采用共享树进行组播数据包转发。每一个组有一个汇合点（Rendezvous Point: RP），组播源沿最短路径向RP发送数据，再由RP 沿最短路径将数据发送到各个接收端。这一点类似于CBT，但PIM-SM不使用核的概念。PIM-SM主要优势之一是它不局限于通过共享树接收组播信息，还提供从共享树向SPT转换的机制。
尽管从共享树向SPT转换减少了网络延迟以及在RP上可能出现的阻塞，但这种转换耗费了相当的路由器资源，所以它适用于有多对组播数据源和网络组数目较少的环境。
 

 4.4 有核树组播路由协议（Core-Based Trees: CBT）

CBT 的基本目标是减少网络中路由器组播状态，以提供组播的可扩展性。为此，CBT被设计成稀疏模式（与PIM-SM相似）。CBT使用双向共享树，双向共享树以某个核心路由器为根，允许组播信息在两个方向流动。这一点与PIM-SM不同（PIM-SM中共享树是单向的，在RP与组播源之间使用SPT将组播数据转发到RP），所以CBT不能使用RPF检查，而使用IP包头的目标组地址作检查转发缓存。这就要求对CBT共享树的维护就需非常小心，以确保不会产生组播路由循环。
从路由器创建的组播状态的数量来看， CBT比支持SPT的协议效率高，在具有大量组播源和组的网络中，CBT能把组播状态优化到组的数量级。
CBT为每个组播组建立一个生成树，所有组播源使用同一棵组播树。CBT工作过程大体如下：
●首先选择一个核，即网络中组播组的固定中心，来构造一棵CBT； 
●主机向这个核发送join命令；
●所有中间路由器都接收到该命令，并把接收该命令的接口标记为属于这个组的树；
●如果接收到命令的路由器已是树中一个成员，那么只要再标记一次该接口属于该组；如果路由器第一次收到join命令，那么它就向核的方向进一步转发该命令，路由器就需要为每个组保留一份状态信息；
●当组播数据到达一个在CBT树上的组播路由器时，路由器组播数据到树的核。以保证数据能够发送到组的所有成员。
CBT将组播扩张限制在接收者范围内，即使第一个数据包也无需在全网扩散，但CBT导致核周围的流量集中，网络性能下降。所以某些版本的CBT支持多个核心以平衡负载。
目前CBTv3草案已公布。该方案通过使用CBT边界路由器（BR）更好地处理域间组播的转发。CBTv3还引入新的状态及单向分支CBT概念。尽管CBT很有代表性，但至今却几乎没有已实现的CBT网络。

五、组播应用与编程

组播技术被认为是WWW技术推广之后出现的最激动人心的网络技术之一。 1992年出现支持IP组播的Mbone(组播主干网)和Mbone桌面工具；1993-1996年IP Multicast成为业界关注的焦点，然而因发展条件不成熟使得IP组播只为业界所关注；进入1999年以来，IP组播具备了发展的三个关键条件：支持组播的路由协议；基于开放标准的可测试管理协议；因商业发展机遇而进入高速发展阶段。又一次掀起了组播实践的高潮，下面将有关组播应用作简单讨论：

5.1 组播主干网(Multicast Backbone：Mbone)
Mbone是一个由IETF开发的运行在Internet上的虚拟重叠网络。Mbone的初衷是创建一个半永久的IP组播测试床而不需要等到整个Internet都采用支持组播的路由器。
Mbone跨越几个洲，用户数大约在10000-30000之间。在IETF会议期间，大约有1000个不同的接收主机接入。它成为Internet上传送声音和视频信息的一个重要组成部分。
1992年，组播技术还处于实验阶段。当时提出以IP遂道（Tunneling）联结组播岛，组播岛是支持组播服务的区域，最小的组播岛是一个支持组播的LAN。
Mbone 使用DVMRP协议，而DVMRP在UNIX下是由标准守护进程mrouted得以实现，所以许多用户使用UNIX主机接入Mbone。由于UNIX主机上的I/O处理能力、对IP遂道的处理能力、网络接口数量等方面都不及商用路由器，这都无形制约了Mbone的发展。
Mbone自从出现就不断发展。今天，从基于mrouted的UNIX主机到商用路由器的迁移已超过了50%；Mbone也采用剪枝、封装等技术。新的域间组播路由协议和转发算法、流量控制与管理、可靠组播也将对Mbone产生影响。

5.2 组播应用程序接口与编程
RFC1112推荐了一些支持组播的应用程序接口：
●加入一个组播组；
●离开一个组播组；
●为调整范围对一个组播数据的IP TTL值进行设定；
●为组播传输和接收设定本地的接口；
●禁止输出的组播数据回送。
现在，许多TCP/IP实现都支持RFC1112所提到的要求，下面简要介绍UNIX(Berkeley Socket)和Windows(Winsock) API。
5.2.1 Berkeley Socket组播API
所有Berkeley Socket API都采用setsockopt()的“套接字选项”功能来设置（对于某些选项，getsockopt()功能可用来获得当前的设置）。表3描述了 Berkeley BSD的set sockopt()/getsockopt()组播命令。
表3 BSD setsockopt()/getsockopt()组播命令的说明

setsockopt()/getsockopt()组播命令	命令说明
IP_MULTICAST_TTL	设置输出组播数据的TTL值
IP_ADD_MEMBERSHIP	在指定接口上加入组播组
IP_DROP_MEMBERSHIP	退出组播组（在IGMPv2中实现）
IP_MULTICAST_IF	获取默认接口或设置接口
IP_MULTICAST_LOOP	禁止组播数据回送

 
 
对于套接字编程，首先要使用函数socket()建立一个数据包套接字，然后用bind()函数将套接字与一个地址和端口号连接起来。
为了发送一个组播数据包，需要在sendto()调用中指定一个组播地址作为目的地址（所有IP地址都使用网络字节顺序）。
为了接收一个组播数据包，需要在recvfrom()调用中指定所要接收的组播地址。
IP_MULTICAST_TTL允许将随后的组播数据的TTL设定成从0到255之间的任何值，例如：
u_char ttl;
setsockopt(sock,IPPROTO_IP,IP_MULTICAST_TTL,&ttl,sizeof(ttl));
关于TTL的讨论见上文。
通过IP_MULTICAST_IF,系统管理员可在安装的时候为组播创建默认的接口（为从一个给定的网络接口并发传送，一个网络接口会忽略这个默认值）。例如：
struct in_addr addr;
setsockopt(sock,IPPROTO_IP,IP_MULTICAST_IF,&addr,sizeof(addr));
在这里，addr是希望输出接口的本地IP地址，可使用一个INADDR_ANY地址来回送到默认的接口。
当组播组中的一台主机发送组播数据到输出接口时，默认的IP层将为本地回送数据的拷贝。
IP_MULTICAST_LOOP网络参数控制IP层是否回送所送的数据。例如：
u_char loop;
setsockopt(sock,IPPROTO_IP,IP_MULTICAST_LOOP,&loop,sizeof(loop));
将loop设置为0则禁止回送，设置为1则允许回送。
为了能够接收IP组播数据，主机必须加入某个或多个组播组，程序通过使用IP_ADD_MEMBERSHIP网络接口参数向主机提出加入组播组的申请。例如：
struct ip_mreq
{struct in_addr imn_multiaddr; /* multicast group to join */
struct in_addr imr_interface; /* interface to join on */
}mreq;
setsockopt(sock,IPPROTO_IP,IP_ADD_MEMBERSHIP,&mreq,sizeof(mreq));
一个组的成员是与一个单一的网络接口相联系；主机可在不止一个网络接口上加入相同的组。若选择默认组播接口，要将imr_interface设置为INADDR_ANY;若选择主机其中一个本地地址，要将imr_interface设置为特定的组播接口。
若撤消一个成员资格，使用IP_DROP_MEMBERSHIP
struct ip_mreq mreq;
setsockopt(sock,IPPROTP_IP,IP_DROP_MEMBERSHIP,&mreq,sizeof(sreq));
其中mreq包含了在IP_ADD_MEMBERSHIP命令中相同的值。
5.2.2 Windows Socket组播API
基于Winsock1.1的组播编程与Berkeley Socket类似，这里不再赘述。Winsock2是Winsock1.1的扩展，除兼容Berkeley Sockets组播API外，它还定义了一套支持IP组播的协议独立API，如表4所示：
表4 WinSock 2的协议独立组播API说明

WSAEnum Protocol()	获得协议信息结构(WASPROTOCOL_INFO)
WSASocket()	设置组播类型
WSAJoinLeaf	加入组播组并指定角色(发送者/接收者)
WSAIoctl(…SIO_MULTICAST_SCOPE…)	设置IP TTL
WSAIoctl(…SIO_MULTICAST_LOOPBACK…)	禁止组播数据回送

 
在 Winsock2中，定义了“数据平面”（Data Plane）和“控制平面”(Control Plane)的概念，其中，数据平面决定在不同的网络成员之间数据如何传送；控制平面定义网络成员的组织方式；这两方面的特征既可以是“有根的”（Rooted）,也可以是“无根的”（Nonrooted）。在“有根的”控制平面内，存在一个特殊的组播组成员，称作C_root（根节点），其余的组成员称作C_leaf(叶节点)。对“无根的”控制平面而言，只存在叶节点。
在“有根的”平面中，根节点负责组播的建立，以及同任意数量叶节点的连接。叶节点可申请加入一个特定的组播组。数据传送只能在根节点和叶节点之间进行，根节点将数据组播到每个叶节点。
在“无根的”平面中，只存在叶节点，它们可以任意加入一个组播组。从叶节点发送的数据会组播到每一个叶节点。
由于篇幅所限，有关Winsock API的进一步讨论，请参阅参考文献<3>、<5>和MSDN。

六、IP组播中存在的问题与发展

6.1 组播的可靠性
IP组播数据包典型使用用户数据报协议（UDP），而UDP是一种“尽力而为”（Best-effort）协议。因此，IP组播应用必定会遇到数据包丢失和乱序问题。
从端到端传输延迟和可靠性方面考虑，组播应用可大致分为三类：
1）实时交互应用，如视频会议系统，这类应用对可靠性要求相对较低，但对端到端传输延迟和网络抖动的要求很高。
2）实时非交互型应用，如数据广播，这类应用传输延迟要求相对前一类应用较低，但在一定延迟范围内，却对可靠性提出更高要求。
3）非实时应用，如软件分发，这类应用中，可靠性是最基本的要求，在满足可靠性要求的前提下，必须保证传输延迟在可接受的范围之内。
对于不同类型的应用必须在确认方式（肯定确认ACK和否定确认NACK），集中确认与分布确认、重传机制、重传范围、流量控制、拥塞控制、end-to-end延迟和广播延迟、网络抖动、可伸缩性与网络的异构性等方面做出综合考虑，提出相应的解决办法。
迄今为止，尽管在广域网环境中已经存在许多可靠组播协议，包括可靠组播协议RMP（Reliable Multicast Protocol）、可扩展可靠组播SRM(Scalable Reliable Multicast)、基于日志的可靠组播LBRM（Log-Based Reliable Multicast）和可靠组播传输协议RMTP(Reliable Multicast Transport Protocol)，但组播的可靠性研究仍然是国际上的重点研究课题之一。

6.2 组播的安全性
安全组播就是只有注册的发送者才可以向组发送数据；只有注册的接收者才可以接收组播数据。然而IP组播很难保证这一点。
首先，IP组播使用UDP，任何主机都可以向某个组播地址发送UDP包，并且低层组播机构将传送这些UDP包到所有组成员。其次，Internet缺少对于网络层的访问控制。第三，组成员可以随时加入/退出组播组。这几点使组播安全性问题同组播的可靠性问题一样难以解决。
总的来说，安全组播可分为集中式和分布（分层）式密钥管理体系。目前，对于组播安全性问题已有Naïve密钥管理、Iolus、Nortel框架和SRM（Secure Reliable Multicast）等解决方案。Matthew J. Mayer等人在<29>中提出了安全组播评估标准，回顾并讨论了安全组播体系结构、组密钥管理和信源认证等问题。然而现有的解决方案都不同程度的存在不足，安全组播仍然是一个技术难点。

6.3 网络的异构性导致组播的复杂性
Internet是一个异构网络，这种异构性表现在很多方面。第一，Internet的低层硬件平台千差万别，可以是Ethernet、ATM、FDDI、令牌环网、帧中继、串行链路（PSTN、xDSL）、无线网络、卫星网络、移动网络等等。这些低层网络具有不同的带宽、硬件存取控制方式、时延特征。在多链路情况下，各链路的带宽与代价也可能不同。另外，某些网络平台的数据链路具有非对称性，比如xDSL和卫星网络。第二，主机的硬件处理能力和操作系统各不相同。就操作系统而言，主要的操作系统，如UNIX、Windows、MacOS、OS2有不同的变种和版本，对IP组播的支持程度、进程的调度与管理、TCP/IP的实现方式和 API都有差异。第三，互连设备的差异。路由器、交换机、网络服务器在背板能力、包转发率、支持的路由协议的互操作性。这些异构性都导致在实现IP组播网络中的复杂性。
比如：网络中不同部分的带宽不同、接收者的处理要求和处理能力不同，而所有接收者都要与同一组播源交互，这就要求采取某些方法使得每一个接收者接收到与其接收能力和从组播源到接收者之间带宽相适合的数据流（即公平性）。再比如：ATM面向连接的特点在IP组播传输中带来了新的问题，这使IP组播与ATM组播具有不同特点。
所以，在设计IP组播网络时，必须充分考虑到网络的异构性。
　
七、结束语
本文从组播的产生和发展出发，介绍了组播网络的体系结构、算法和协议，讨论了组播技术的应用，总结了组播技术的难点。随着高宽带多媒体应用的迫切需求、ISP、ICP对IP组播网络的支持、设备提供商的投入、各种专业组织的介入，IP组播技术必然有着广阔的发展前景。