我翻译的RFC3569

culife

特定源组播（SSM）概述
摘要：本文的目的是对SSM做一个概述， 并指出一些关于部署SSM的问题。本文讨论了SSM服务模型如何解决域间组播部署中的挑战，路由协议和应用软件需要作的改变，以及与现存的组播服务模型的互操作问题。
1介绍
本文对SSM组播服务以及使用PIM-SM和IGMP/MLD协议部署SSM做了概要介绍。SSM提供给网络层的服务是一个“通道”，它用SSM目的IP地址G和源IP地址S进行标示。IANA已经为SSM服务预留了IPv4的地址范围。SSM目的地址范围在IPv6中也早已存在。源S将它的IP数据报发送到SSM目的地址G。接受者只要加入该（S，G）通道可以收到这些数据报。IPv4中的IGMPv3和IPv6中的MLDv2已经支持这种通道加入。用来转发IP组播数据的域间组播树以源S为根，使用PIM-SM协议建立。
本文并非要成为SSM的标准，相反，本文的目的是对SSM和它的益处给那些对部署SSM服务感兴趣的人作一些介绍。它提供了对SSM的一个概述和解决SSM在域间部署时遇到的一些问题的方法。他概要介绍了终端主机和路由器上的协议和应用程序需要作的一些改变以支持SSM，并指出了更详尽的文档。与RFC1112所定义的组播模型的互操作性在本文中也作了讨论。
本文是IETF SSM工作组所作。
2 术语
本节定义了一些本文其他部分要用到的一些术语。
任意源组播（ASM）：这是RFC1112所定义的组播模型。一个IP报文被传送到一个“主机组”，这组零个或多个终端主机（或路由器）被一个IP目的地址（IPv4地址从224.0.0.0到239.255.255.255）所指定。终端主机可以在任何时间加入或离开该组，并且对他们的所在地和数量也没有限制。这个模型支持任意多个发送者的组播组，即任意一个终端主机（或路由器）都可以发送数据给一个主机组，即使它可能不是那个组的成员。
特定源组播（SSM）：这是文献[5]所定义的组播服务模型。组播源可以发送一个IP报文给SSM目的地址G，接受者可以加入通道（S，G）来接收该报文。SSM提供给主机应用程序一个“通道”抽象，每个通道拥有一个源和多个接收者。SSM起源于EXPRESS（文献[1]）早期的工作。IPv4地址范围232/8已经被IANA分配给SSM服务，而IPv6中则是FF3x：：/96（参考文献[21]）。
源过滤组播（SFM）：这是ASM服务模型的一个变种，使用与ASM相同的地址空间（224.0.0.0-239.255.255.255）。它对ASM服务模型作了如下修改：每一个上层协议模块现在都可以请求某些组播源发送给组G的数据，或者可以请求除了某些组播源之外的所有组播源发送给组播组G的数据。IGMPv3（为IPv4）、MLDv2（为IPv6）都已经提供支持源过滤。今后我们将这两个协议成为“支持SFM的”。这两个协议的早期版本，即IGMPv1/IGMPv2和MLDv1都不提供对源过滤的支持，因此称为“非支持SFM的”。值得注意的是虽然从接收者的角度而言SFM和ASM是两个不同的模型，但对于发送者来说二者之间没有任何差别。
       本文将文献[12]提出的区域组播模型看作是ASM的一种变形，因为它不显式地限制组播源的数量，而只需限定他们位于该组的一定区域内。
3 IGMP/PIM-SM/MSDP/MBGP 协议栈
       作此文时，所有的支持组播的网络都支持ASM服务模型。最常见的支持ASM的协议栈有IGMPv2，PIM-SM，MSDP和MBGP。IGMPv2是一个主机所最广泛使用的协议，用来指定组播组里的组播成员，几乎所有的组播路由器都支持IGMPv2。如果是IPv6的话，MLDv1是常用的协议。
       尽管大量的组播协议可以用来在同一域内的所有的接收者和源之间建立组播树，例如PIM-DM，CBT，DVMRP等，只有PIM-SM是应用的最为广泛的。PIM-SM在一个域内为所有组成员建立一棵以会聚点（RP）为根的组播生成树。与组播源邻接的“第一跳”路由器将源的组播数据发送到RP。RP再将数据沿着共享的生成树发送到该域内所有有兴趣的接收者。PIM-SM也允许接收者从共享树切换到基于源的最短路径树。
       作此文时，支持SFM的终端主机并没有大量应用。因此一个客户仅仅可以指定在整个组播组中的接收兴趣，并接受任意源发送到该组上的数据。
       域间组播服务（例如源和接收者位于不同的域）需要其他的一些协议进行支持---MSDP和MBGP是最常使用的。一个RP可以使用MSDP来将组播源通告给其他域里的RP。当一个RP发现其他域里面的一个组播源向一个组播组发送数据，而且在他自己所在的域内又有对改组播组感兴趣的接收者时，他就会加入到以这个组播源为根的最短路径树，并通过域内的以自己为根共享树转发该组播数据。
       MBGP定义了一些对BGP协议的扩展以支持为组播路由通告可达性信息。这是的一个自治系统（AS）可以支持不同的单播和组播路由拓扑，因此可以为两者分别实现路由策略。
       然而，感兴趣的接收者的最后一跳路由器可能最终会切换到以发送组播数据的组播源为根的最短路径树上。
4 现存体系中的问题
       现存组播体系的部署有很多问题：
1）  地址分配：
地址分配是部署SSM所面临的核心问题之一，这种挑战是ASM服务模型所造成的。现有的组播体系并没有提供一种可部署的解决方案来防止多个应用之间地址冲突。这个问题在IPv6中显得不如在IPv4种那么严重，因为IPv6 中的组播地址空间要比IPv4中大的多。IPv4中有一种静态的地址分配机制---GLOP（文献[17]）被提出作为一种过渡的解决方案。然而GLOP地址是在每个注册的AS内进行分配的，这对于组播源数量超过了可用于映射的AS数量时这种地址是不够的。RFC 3138扩展了RFC 1930，允许路由注册以给GLOP空间（对应于FRC1930 中的私有AS空间）分配组播地址。这个空间被称作EGLOP（扩展的GLOP）地址空间。而现有的长期的建议解决方案，例如组播地址分配体系[14]，一般都认为太复杂（由于组播地址分配的动态性）难于广泛实施。
2）  缺乏访问控制：
ASM服务模型中，接受者加入一个组播组后不能够指定他要接受信息特定组播源。接收者将会转发任意源发送到组播组的数据。进而，即使当一个组播源获得了一个组播组地址来发送数据，它也不能保证没有其他源会使用这个地址。这种情况即使在由于地址空间较大，冲突不易发生的IPv6中也是存在的。
3）  不能有效地控制众所周知的地址：
如果接收者加入组播组之前就已知道源的组播地址是众所周知的，当采用最短路径树作为首选转发模型时，共享树机制就不需要了。
5 SSM：益处和需求
       正如前面提到的，SSM服务模型定义了一个“通道”，它由一个（S，G）对来表示，S表示一个组播源耳G表示一个SSM目的组播地址。通道的加入使用支持SFM的组管理协议例如：IGMPv3或MLDv2 。只有基于原的转发树需要在SSM模型中来实现。
       SSM服务模型缓解了前面提到的部署问题：
1）  地址分配：SSM基于组播源定义了一些通道，例如通道（S1，G）区别于通道（S2，G），S1，S2是不同的源地址，而G是一个SSM目的组播地址。这样就避开了全局分配SSM目的组播地址的问题，使得每一个组播源单独处理它所创建的多个通道之间的地址冲突问题。
2）  访问控制：利用SSM可以实现一个解决访问控制问题的完美方案。当接收者加入到一个（S，G）通道，它只能接收到源S发送的数据。相反，任何主机都可以向一个ASM主机组播组发送数据。在一个发送者选择了一个（S，G）通道来发送数据的同时，SSM自动地保证不会有其他发送者在同一个通道上发送数据（恶意地址哄骗的情况除外）。这使得在SSM通道上发送垃圾信息比在ASM组播组上发送要困难得多。
3）  处理众所周知的源：SSM只需要一棵基于源的转发树，这就去掉了对共享树体系的需求。这意味着不论是PIM-SM里的基于RP的共享树体系，还是MSDP协议都已经不再需要。因此组播路由基础结构的复杂性将得到降低，使直接部署成为可能。需要注意的是MBGP的使用对于ASM和SSM并没有不同。
6 SSM框架
       图1说明了一个端到端的SSM实现框架的原理：
      

下面我们来详细讨论这个框架的原理。
6.1 地址分配
       对于IPv4，IANA已经将232/8地址段分配给了SSM。为了保证该地址段内全局SSM的功能，包括在一个路由器不支持SFM协议的网络中，文献[9]提出了一些对操作性策略的一些建议。这些建议推荐路由器不应向不含有通道预订者的网络发送SSM数据。
       虽然IGMPv3/MLDv2并不将（S，G）加入限制在232/8范围内，但像文献[5]所定义的那样，SSM服务对IPv4而言只在这个地址段内有效。
       对于IPv6，文献[23]定义了一种对地址分配体系的扩展，允许单播传送基于前缀的组播地址。详见RFC3306。
6.2会话描述和通道发现
       一个SSM接收应用在预定一个通道前必须知道SSM目的地址G和源地址S。通道发现就是用来为该应用完成这个任务的。这个信息可以通过多种方式得到，包括通过网页，会话通告程序等等。这和使用ASM的应用相似，组播会话需要进行通告以使得预定者得到组播组地址，编码机制等等。事实上，通告唯一需要增加的部分就是该通道的源地址。然而完成该功能的准确机制已超出本文的范围之内。
6.3 知悉SSM的应用
       要使组播应用知悉SSM需要两个主要方面的工作：
       1）想要接收SSM会话的应用必须首先发现正在使用的通道地址。
       2）接收应用必须能够为终端主机的网络层协议模块指出源地址和目的地址。
       所需要的标准API在文献[16]中已经指出。文献[16]描述了对主机OS的用以支持SFM服务模型一个推荐应用程序接口。尽管它是针对SFM的，但这个接口的一个子集对于支持SSM来说已经足够了。
6.4 IGMPv3/MLDv2 主机报告和查询
       为了使用SSM服务，一个终端主机必须能够制定一个通道地址，包括源的单播地址和SSM目的地址。IGMP版本2（文献[3]）和MLD版本1（文献[19]）都允许一个终端主机只指定一个目的组播地址。能够指定通道地址c的功能在IGMP版本3和MLD版本2中已经提供。这些协议都支持“源过滤”，例如终端系统能够表达他们只希望接收某些特定源发送的数据包，或者希望接收某些特定源除外的所有源的数据包。事实上，IGMPv3提供了能够实现SSM服务的超集。
       关于在SSM目的地址范围内使用IGMPv3在文献[4]中有详细的讨论。
       组播侦听者发现协议（MLD）被IPv6路由器用来在它直接相连的链路上发现组播侦听者，发现邻接点感兴趣的组播地址。MLD版本1原自IGMPv2，没有提供SSM服务模型需要的源过滤功能。MLD版本2原自IGMPv3，提供了像IGMPv3一样的源过滤支持。因此IGMPv3（或者MLDv2对于IPv6来说）就使得主机具有了从网络上请求预定一个SSM通道的能力。
6.5 PIM-SSM 路由
       文献[9]提供了关于一个PIM-SM实现如何处理SSM所需要的特定源的主机报告的大纲。PIM协议早期的版本却没有对此给出规范。
       文献[5]则详细陈述了路由器要在SSM范围内操作的需求。这些规则主要是关于在SSM地址范围内禁止ASM样式的行为。为了遵守文献[5]的规定，需要对PIM-SM协议做一些修改，正如文献[9]所描述的那样。最重要的几个改变是：
1）当一个DR收到一个（S,G）加入请求，并且G在SSM范围内，它必须发起一个（S，G）加入，而绝对不能发送（*，G）加入。
2）主干路由器（例如，不直接与主机相连的路由器）一定不要传播组地址在SSM地址范围内的（*，G）加入。
3）汇聚点（RP）一定不要接受组地址在SSM地址范围内的PIM注册报文或（*，G）加入报文。
要支持SSM服务模型，只需要全部PIM-SM协议中的一个小子集。这个子集在文献[9]作了明确的陈述。
7 与现存组播模型的互操作性
       与ASM的互操作性是部署SSM最重要的问题之一，因为人们希望这两个模型能同时使用，至少是在可以预见的将来。SSM是SSM地址范围内的唯一模型，正确的协议行为在文献[5]中有定义。ASM服务模型可以使用在非SSM地址范围内的组播地址内，在该地址范围内接收者可以发起（*，G）的加入请求以请求组播数据。一个接收者也可以在非SSM地址范围内发起（S，G）加入请求，然而这种情况下却不能保证它会根据SSM模型接收服务。
       另一个互操作性问题时关于MSDP协议，该协议用在RP之间，用于发现跨多个域的组播源。SSM不需要MSDP，但是ASM需要。文献[9]给出了一些操作性建议来保证MSDP不会干扰网络支持SSM模型的功能。特别地，文献[9]指出RP一定不要接受，发起或转发组播地址在SSM地址范围内的MSDP SA报文。
8 安全性考虑
SSM没有对IP组播提供新的安全考虑。它可以帮助进行防止DoS攻击以免不希望的组播源发送数据给一个组播通道（S，G）。然而并没有提供任何保证。
9 致谢
我们要感谢Gene Bowen, Ed Kress, Bryan Lyles, Timothy Roscoe, Hugh Holbrook, Isidor Kouvelas, Tony Speakman and Nidhi Bhaskar 参与关于SSM的冗长的讨论和设计工作，并对本文提供反馈。也要感谢Mujahid Khan, Ted Seely, Tom Pusateri, Bill Fenner, Kevin Almeroth,Brian Levine, Brad Cain, Hugh LaMaster and Pekka Savola等人可贵的观点和不断的支持。
10参考
[1] Holbrook, H. and D.R. Cheriton, "IP Multicast Channels: EXPRESS
Support for Large-scale Single-Source Applications", In
Proceedings of SIGCOMM 1999.
[2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC
2236, November 1997.
[3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan,
"Internet Group Management Protocol, Version 3.", RFC 3376,
October 2002.
[4] Holbrook, H. and B. Cain, "Using IGMPv3 and MLDv2 for
Source-Specific Multicast", Work In Progress.
[5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
Work in Progress.
[6] Deering, S. and D. Cheriton,"Multicast Routing in Datagram
Networks and Extended LANs", ACM Transactions on Computer
Systems, 8(2):85-110, May 1990.
[7] Deering, S. et al., "PIM Architecture for Wide-Area Multicast
Routing", IEEE/ACM Transaction on Networking, pages 153-162,
April 1996.
[8] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June 1998.
[9] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Work In Progress.
[10] Adams, A., Nicholas, J. and W. Siadek, "Protocol Independent
Multicast - Dense Mode (PIM-DM): Protocol Specification
(Revised)", Work In Progress.
[11] Ballardie, A., "Core-Based Trees (CBT) Multicast Routing
Architecture", RFC 2201, September 1997.
[12] Meyer, D., "Adminstratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[13] Farinacci, D. et al., "Multicast Source Discovery Protocol",
Work In Progress.
[14] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast
Address Allocation Architecture", RFC 2908, September 2000.
[15] Diot, C., Levine, B., Lyles, B., Kassem, H. and D. Balensiefen,
"Deployment Issues for the IP Multicast Service and
Architecture", In IEEE Networks Magazine’s Special Issue on
Multicast, January, 2000.
[16] Thaler, D., Fenner B. and B. Quinn, "Socket Interface Extensions
for Multicast Source Filters", Work in Progress.
[17] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53,
RFC 3180, September 2001.
[18] Levine, B. et al., "Consideration of Receiver Interest for IP
Multicast Delivery", In Proceedings of IEEE Infocom, March 2000.
[19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener
Discovery for IPv6", RFC 2710, October 1999.
[20] Vida, R. et. al., "Multicast Listener Discovery Version 2(MLDv2)
for IPv6", Work In Progress.
[21] Haberman, B. and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast
Addresses", RFC 3306, August 1992.
[22] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[23] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[24] Ballardie, A., "Core-Based Trees (CBT Version 2) Multicast
Routing -- Protocol Specification", RFC 2189, September 2001.
[25] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989.
[26] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol
Extensions for BGP-4", RFC 2858, June 2000.
[27] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.
[28] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/12602/showart_69112.html