依赖源汇聚点的组播协议

基金项目：国家发改委CNGI示范工程项目(CNGI-04-13-2T)

      稀疏模式独立组播协议(PIM-SM)[1]是一个轻便的，性能良好的域内组播协议，整个组播域内有一个被称为汇聚点(RP)的组播路由器作为源与接收者的会合地点。但是由于每个因特网业务提供商(ISP)都有自己的RP，且RP只知道本域内的组播源和接收者信息，不具备域间交互的能力。为使PIM-SM支持域间组播，通常可以采用两种方法：一种是让接收者RP知道组播源的位置，另一种是让接收域的路由器知道源RP的位置，其中源RP是源所在域的RP，接收者RP是接收者所在域的RP。本文用第二种方法构建一种域间组播方案。接收者的指定路由器(DR)使用Chord[2]协议获得源RP地址，并加入源RP树。为了叙述方便，本文将该方案称为依赖源RP组播，因为所有的接收者都必须加入源RP树。

1 相关工作

1.1 多播源发现协议
      多播源发现协议(MSDP)[3]使用的是第一种方法。在MSDP中，每个源RP把它了解的源活动(SA)信息通过传输控制协议(TCP)转发给其他域里的所有接收者RP。该协议的主要缺点是不易扩展，因为每个域的RP都需要掌握其他RP的信息，在组播域较多时，配置和维护会非常困难；所有SA消息在整个Internet上扩散，给拒绝服务(DoS)攻击带来了便利。因此，MSDP一直被看作一种权宜方案，在IPv6中也没有相应的实现。

1.2 特定源组播
      特定源组播(SSM)[4]并不需要RP，因为它假定接收者知道源的信息。接收者通过指定被称为信道的(S，G)组，直接加入组播源的最短路径树(SPT)，其中S是源地址，G是组地址。SSM的主要缺点是：
      (1)对多源组播应用支持不好，尤其在发送者的数量和位置不断变化时，而这类应用非常普遍又很重要。

      (2)需要修改现有的组播应用软件，使其支持RFC3678中描述的组播源过滤应用编程接口(API)，代价太高。

      (3)对源移动组播支持不佳。

      因为要使组播信道保持不变，源移动后必须将数据包单播给家乡代理，让家乡代理将数据包组播出去，这会造成路由三角问题，处理大量的移动源信息也会使家乡代理不堪重负。

1.3 嵌入式汇聚点
      有人根据IPv6地址的特点提出了一种被称为“在组播地址中嵌入RP地址”[5]的解决方案，简称为嵌入式RP。它采用的是第二种方法，其做法是将源RP地址嵌入到组播地址中，组播路由器直接从组播地址中提取源RP地址，并加入源RP树。其主要缺点是：

      (1)这种组播地址对源RP地址的依赖性比较高，源RP一旦出现故障，组播就会出现问题。虽然可以通过泛播(Anycast)RP[6]技术让多个RP共享一个地址，但配置和维护工作比较复杂。

      (2)可以从组播地址提取源RP地址，并反推出与该RP相关的其他组播会话，不太安全。

      (3)在多源组播应用中，如果组播源处在不同域，RP的选择将成为问题。

      (4)多源组播应用会产生路由三角问题。

      Chord协议是一种分布式资源查找协议，具有良好的健壮性和可扩展性。它利用一致性散列算法将关键信息随机分散到一组被组织成Chord环的主机中，并能从环中的任何一台主机上查找存储的信息。Chord协议的查找速度很快，在n台主机的环中，平均只需查找log2n次。

2 依赖源汇聚点组播
      依赖源汇聚点的组播用Chord协议查找源RP信息，要求与组播源对应的DR首先将源RP信息三元组(S，G，RP)存储到Chord环中，其中S是源地址，G是组地址，RP是源RP地址。每个组播域至少需要配置一台Chord主机，所有Chord主机构成一个Chord环，如图1所示。

      Chord主机要加入Chord环需要知道环中某台主机的IP地址，第一台主机构建一个指向自己的自旋环。为了方便环的形成，需要配置几台永久的Chord主机，类似于域名服务器(DNS)中的根节点。

      组播源或接收主机的DR需要知道本地Chord主机的地址，以便于向Chord环存储或查询源RP信息。

2.1 地址分类
      为方便组播的控制和管理，通常将组播地址分为两类：全局地址和局部地址。

      Chord环上只存储与全局地址对应的源RP信息，也就是说只能使用全局地址进行域间组播通信。可以使用以下方法区分这两种地址：

      (1)配置组播源和接收主机的DR。譬如，只配置局部地址，非局部地址便是全局地址。

      (2)利用IPv6组播地址的范围管理特性。

2.2 组播的发送
      在依赖源汇聚点的组播中，组播源的发送过程如下：
      (1)组播源将组播信息发送到它的DR。

      (2)DR检测组播地址，判断该组播是否已注册，如果是则转到过程(6)，否继续到过程(3)。

      (3)建立一个(S，G)项，如果组播地址是局部的，则继续到(4)，否则转到过程(5)。

      (4)用组地址G匹配并获得接收者RP的地址，向该RP注册，然后转到过程(6)。

      (5)将源RP信息发送给本地Chord主机，让它把源RP信息存放到Chord环上。

      (6)过程结束。

      组播源的整个发送过程如图2所示。另外，为保证Chord中源RP信息的正确性，Chord主机需要定时删除源RP信息，DR也需定时注册源RP信息，这一过程被称为刷新。

2.3 组播的接收
      在依赖源汇聚点的组播中，接收主机加入RP树的过程如下：
      (1)接收主机向DR发送互联网组管理协议/组播监听协议(IGMP/MLD)报告。

      (2)接到报告后DR判断该组播组是否已存在，若是转到过程(7)，否则继续到过程(3)。

      (3)建立组播转发项，如果是局部地址，则继续到过程(4)，否则转到过程(5)。

      (4)加入接收者RP树，然后转到过程(7)。

      (5)以G为参数查询本地Chord主机，获得源RP信息，DR从中提取源RP地址。

      (6)加入源RP树。

      (7)过程结束。

      整个过程如图3所示。

      DR应定时地查询Chord，以防止G所对应的S的改变。

2.4 DR的改变
      依赖源汇聚点的组播方案无需改变PIM-SM协议和客户端程序，但需要为DR增加一些功能，主要包括以下3个模块：注册模块、刷新模块和查询模块。

      注册模块的主要功能为向Chord注册源RP信息。如果是全局组播地址，注册模块会向本地Chord主机发送源RP信息。本地Chord主机上的守护进程监听进程接收到注册信息后会将源RP信息存储在Chord环上。

      查询模块的主要功能为从Chord查询源RP信息。如果是全局组播地址，查询模块会向本地Chord主机发送查询消息，本地Chord主机上的守护进程接到查询消息后会查找源RP信息并返回给查询模块。

      如前所述，为保证源RP信息的正确性，Chord主机定期删除源RP信息，因此组播源的DR应定期地向Chord注册。Chord主机在接到源DR的注册后，需匹配(S，G，RP)信息，如果匹配成功，则将(S，G，RP)的定时器重置为注册消息中的保持时间；如果只有(S，G)匹配成功，则更新(S，G，RP)项的RP信息，同时重置定时器；否则，新建(S，G，RP)项。因为DR会为每个源创建一个(S，G)项，因此可以用该信息控制DR向Chord主机的刷新，譬如，用(S，G)项的定时器值初始化注册消息的保持时间。

      接收者DR也应定期地向Chord查询，获得消息的保持时间由查询返回消息中的保持时间决定。

2.5 路由器的其他配置
      与MSDP和SSM协议一样，依赖源汇聚点的组播需要用多协议边界网关协议(MBGP)配置自治域间的边界路由器，也需要配置与其他ISP交界的路由器，以允许Chord协议存储和查找源RP信息。

3 特点分析
      相对于其他的域间组播协议，依赖源汇聚点的组播方案除了简单之外还有可扩展、播范围可控制、负载平衡、稳定等特点。

3.1 可扩展
      依赖源汇聚点的组播不像MSDP那样将SA信息发送给所有的RP，只需将源RP信息发送给本地Chord主机，由后者将该信息存放到Chord环中适当的主机上。因此源RP信息流动量不会太大，有利于依赖源汇聚点的组播的扩展。

      Chord主机加入或退出时Chord环中绝大多数主机的存储信息无需变动，也利于依赖源汇聚点的组播的扩展。

3.2 组播范围可控制
      因组播地址被分成了全局地址和局部地址，只有全局组播地址可用于域间组播通信，保证了组播范围的可控制性。

3.3 负载平衡
      在多源组播应用中，依赖源汇聚点的组播方案能够做到负载平衡。因为接收主机的DR会从Chord主机上获取多条源RP信息，并分别加入多棵SRP树。多棵SRP树不仅可以使负载平衡，也避免了三角路由问题。

3.4 稳定
      在一台Chord主机出现故障后，其他主机可以迅速恢复成一个Chord环。只要一个组播域内配置多台Chord主机，在其中部分主机出现故障时不会中断现有的组播通信，因为DR可以从没出故障的Chord主机上查询SA信息，这类似于一个域内有多台DNS代理服务器。另外，在Chord主机出现故障后，组播源DR将源RP信息发送给另一台正常的Chord主机，以保证组播通信的正常进行。

3.5 支持ASM
      依赖源汇聚点的组播从逻辑上抛弃了组播域的概念，使源RP为其他组播域所见。

      依赖源汇聚点的组播不要求组播源地址和组播地址绑定在一起，因此依赖源汇聚点的组播就是一种域间ASM方案，无需修改现有的组播软件。

3.6 支持主机移动
      由于源RP信息的存放位置与发送该信息的DR的位置无关，因而组播源可以很自由地更换DR。组播源可以让其外地DR向Chord注册，避免了三角路由问题。

      因为可以从任何一台Chord主机上查询源RP信息，所以接收主机在外地域也能通过远程订阅机制加入组播组。

4 安全因素
      依赖源汇聚点的组播安全方面的措施：
      (1)DoS攻击。人们可以将自己的主机的IP地址伪装成DR的IP地址向Chord发送一些无用的组播组信息，从而造成Chord性能的下降。可以通过限制单位时间内每台DR向Chord发送信息的数量来解决。

      (2)为快速查询，每台Chord主机自身都有一个查找表，通过改变自身的查找表，节点本身可以破坏Chord环的完整性。为此可以采用认证机制，禁止非法的主机加入Chord环。

5 结束语
      本文提出了一种基于Chord的域间组播方案——依赖源汇聚点的组播。该方案利用可以从任意Chord主机上查询Chord上存储的信息的特点，将源RP信息存储到Chord上，供各组播域使用，以便不同的域进行组播通信。该方案是一种域间ASM解决方案，能提供很好的容错性和可扩展性，支持主机移动组播，但不会造成三角路由问题。

6 参考文献
[1] ESTRIN D, FARINACCI D, HELMY A, et al. Protocol independent multicast - sparse mode (PIM-SM): protocol specification (revised) [S]. RFC 2362. 1998.
[2] STOICA I, MORRIS R, LIBEN-NOWELL D, et al. Chord: a scalable peer-to-peer lookup protocol for Internet applications [J]. IEEE/ACM Transactions on Networking, 2003, 11(1):17-32. 
[3] FENNER B, MEYER D. Multicast source discovery protocol[S]. RFC 3618. 2003.
[4] HOLBROOK H, CAIN B. Source-specific multicast for IP [R]. Internet Draft, work in progress. 2005.
[5] SAVOLA P, HABERMAN B. Embedding the rendezvous point (RP) address in an IPv6 multicast address [S]. RFC 3956. 2004.
[6] FARINACCI D, CAI Y. Anycast-RP using PIM [R]. Internet Draft, work in progress. 2005.

收稿日期：2006-05-29