Network Working Group S. Bhattacharyya, Ed.
Request for Comments: 3569 Sprint
Category: Informational July 2003
Network Working Group S. Bhattacharyya, Ed.
Request for Comments: 3569 Sprint
Category: Informational July 2003
An Overview of Source-Specific Multicast (SSM)
源特定多播（SSM）概述
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models.
本文档旨在概述源特定多播（SSM）及其部署相关问题。它讨论了SSM服务模型如何解决域间多播部署中面临的挑战、部署SSM所需的路由协议和应用程序的更改以及当前多播服务模型的互操作性问题。
This document provides an overview of the Source-Specific Multicast (SSM) service and its deployment using the PIM-SM and IGMP/MLD protocols. The network layer service provided by SSM is a "channel", identified by an SSM destination IP address (G) and a source IP address S. An IPv4 address range has been reserved by IANA for use by the SSM service. An SSM destination address range already exists for IPv6. A source S transmits IP datagrams to an SSM destination address G. A receiver can receive these datagrams by subscribing to the channel (Source, Group) or (S,G). Channel subscription is supported by version 3 of the IGMP protocol for IPv4 and version2 of the MLD protocol for IPv6. The interdomain tree for forwarding IP multicast datagrams is rooted at the source S, and is constructed using the PIM Sparse Mode [9] protocol.
本文档概述了源特定多播（SSM）服务及其使用PIM-SM和IGMP/MLD协议的部署。SSM提供的网络层服务是一个“通道”，由SSM目标IP地址（G）和源IP地址S标识。IANA已保留IPv4地址范围供SSM服务使用。IPv6的SSM目标地址范围已存在。源S向SSM目标地址G发送IP数据报。接收器可以通过订阅信道（源、组）或（S、G）来接收这些数据报。IPv4的IGMP协议版本3和IPv6的MLD协议版本2支持通道订阅。转发IP多播数据报的域间树以源S为根，并使用PIM稀疏模式[9]协议构建。
This document is not intended to be a standard for Source-Specific Multicast (SSM). Instead, its goal is to serve as an introduction to SSM and its benefits for anyone interested in deploying SSM services. It provides an overview of SSM and how it solves a number of problems faced in the deployment of inter-domain multicast. It outlines changes to protocols and applications both at end-hosts and routers
本文档不打算成为源特定多播（SSM）的标准。相反，它的目标是为任何有兴趣部署SSM服务的人介绍SSM及其好处。本文概述了SSM以及它如何解决域间多播部署中面临的许多问题。它概述了在终端主机和路由器上对协议和应用程序的更改
for supporting SSM, with pointers to more detailed documents where appropriate. Issues of interoperability with the multicast service model defined by RFC 1112 are also discussed.
用于支持SSM，并在适当情况下提供指向更详细文档的指针。还讨论了与RFC1112定义的多播服务模型的互操作性问题。
This memo is a product of the Source-Specific Multicast (SSM) Working Group of the Internet Engineering Task Force.
本备忘录是互联网工程任务组源特定多播（SSM）工作组的产品。
The keywords "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as defined in BCP 14, RFC 2119 [28].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[28]中的定义进行解释。
This section defines some terms that are used in the rest of this document:
本节定义了本文件其余部分中使用的一些术语：
Any-Source Multicast (ASM): This is the IP multicast service model defined in RFC 1112 [25]. An IP datagram is transmitted to a "host group", a set of zero or more end-hosts (or routers) identified by a single IP destination address (224.0.0.0 through 239.255.255.255 for IPv4). End-hosts may join and leave the group any time, and there is no restriction on their location or number. Moreover, this model supports multicast groups with arbitrarily many senders - any end-host (or router) may transmit to a host group, even if it is not a member of that group.
任意源多播（ASM）：这是RFC 1112[25]中定义的IP多播服务模型。IP数据报被传输到“主机组”，即一组由单个IP目标地址（IPv4为224.0.0.0至239.255.255.255）标识的零台或多台终端主机（或路由器）。终端主机可以随时加入和离开组，并且对其位置或数量没有限制。此外，该模型支持具有任意多个发送方的多播组-任何终端主机（或路由器）都可以向主机组发送数据，即使它不是该组的成员。
Source-Specific Multicast (SSM): This is the multicast service model defined in [5]. An IP datagram is transmitted by a source S to an SSM destination address G, and receivers can receive this datagram by subscribing to channel (S,G). SSM provides host applications with a "channel" abstraction, in which each channel has exactly one source and any number of receivers. SSM is derived from earlier work in EXPRESS [1]. The address range 232/8 has been assigned by IANA for SSM service in IPv4. For IPv6, the range FF3x::/96 is defined for SSM services [21].
源特定多播（SSM）：这是[5]中定义的多播服务模型。IP数据报由源S发送到SSM目标地址G，并且接收机可以通过订阅信道（S，G）来接收该数据报。SSM为主机应用程序提供了“通道”抽象，其中每个通道正好有一个源和任意数量的接收器。SSM源自EXPRESS[1]中的早期工作。IANA已为IPv4中的SSM服务分配了地址范围232/8。对于IPv6，范围FF3x:：/96是为SSM服务定义的[21]。
Source-Filtered Multicast (SFM): This is a variant of the ASM service model, and uses the same address range as ASM (224.0.0.0-239.255.255.255). It extends the ASM service model as follows. Each "upper layer protocol module" can now request data sent to a host group G by only a specific set of sources, or can request data sent to host group G from all BUT a specific set of sources. Support for source filtering is provided by version 3 of the Internet Group Management Protocol (or IGMPv3) [3] for IPv4, and version 2 of the Multicast Listener Discovery (or MLDv2) [22] protocol for IPv6. We shall henceforth refer to these two protocols as "SFM-capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and MLDv1 - do not provide support for
源过滤多播（SFM）：这是ASM服务模型的一个变体，使用与ASM相同的地址范围（224.0.0.0-239.255.255.255）。它扩展了ASM服务模型，如下所示。每个“上层协议模块”现在可以请求仅由一组特定源发送到主机组G的数据，或者可以请求除一组特定源以外的所有源发送到主机组G的数据。IPv4的Internet组管理协议（或IGMPv3）[3]版本和IPv6的多播侦听器发现（或MLDv2）[22]协议版本2提供了对源筛选的支持。此后，我们将这两个协议称为“支持SFM”。这些协议的早期版本（IGMPv1/IGMPv2和MLDv1）不支持
source-filtering, and are referred to as "non-SFM-capable". Note that while SFM is a different model than ASM from a receiver standpoint, there is no distinction between the two for a sender.
源过滤，被称为“不支持SFM”。请注意，虽然从接收方的角度来看，SFM与ASM是不同的模型，但对于发送方而言，两者之间没有区别。
For the purpose of this document, we treat the scoped multicast model of [12] to be a variant of ASM since it does not explicitly restrict the number of sources, but only requires that they be located within the scope zone of the group.
在本文档中，我们将[12]的作用域多播模型视为ASM的一个变体，因为它没有明确限制源的数量，只要求它们位于组的作用域区域内。
As of this writing, all multicast-capable networks support the ASM service model. One of the most common multicast protocol suites for supporting ASM consists of IGMP version 2 [2], PIM-SM [8,9], MSDP [13] and MBGP [26]. IGMPv2 is the most commonly used protocol for hosts to specify membership in a multicast group, and nearly all multicast routers support (at least) IGMPv2. In case of IPv6, MLDv1 [21] is the commonly used protocol.
在撰写本文时，所有支持多播的网络都支持ASM服务模型。支持ASM的最常见的多播协议套件包括IGMP版本2[2]、PIM-SM[8,9]、MSDP[13]和MBGP[26]。IGMPv2是主机指定多播组成员身份最常用的协议，几乎所有多播路由器都支持（至少）IGMPv2。在IPv6的情况下，MLDv1[21]是常用的协议。
Although a number of protocols such as PIM-DM [10], CBT [24,11], DVMRP [6], etc. exist for building multicast tree among all receivers and sources in the same administrative domain, PIM-SM [8,9] is the most widely used protocol. PIM-SM builds a spanning multicast tree rooted at a core rendezvous point or RP for all group members within a single administrative domain. A 'first-hop' router adjacent to a multicast source sends the source's traffic to the RP for its domain. The RP forwards the data down the shared spanning tree to all interested receivers within the domain. PIM-SM also allows receivers to switch to a source-based shortest path tree.
尽管存在许多协议，如PIM-DM[10]、CBT[24,11]、DVMRP[6]等，用于在同一管理域中的所有接收器和源之间建立多播树，但PIM-SM[8,9]是使用最广泛的协议。PIM-SM为单个管理域内的所有组成员构建一个根于核心集合点或RP的生成多播树。与多播源相邻的“第一跳”路由器将源的流量发送到其域的RP。RP沿着共享生成树将数据转发给域内所有感兴趣的接收器。PIM-SM还允许接收机切换到基于源的最短路径树。
As of this writing, multicast end-hosts with SFM capabilities are not widely available. Hence a client can only specify interest in an entire host group and receives data sent from any source to this group.
在撰写本文时，具有SFM功能的多播终端主机尚未广泛可用。因此，客户端只能指定对整个主机组的兴趣，并接收从任何源发送到此组的数据。
Inter-domain multicast service (i.e., where sources and receivers are located in different domains) requires additional protocols - MSDP [13] and MBGP [26] are the most commonly used ones. An RP uses the MSDP protocol to announce multicast sources to RPs in other domains. When an RP discovers a source in a different domain transmitting data to a multicast group for which there are interested receivers in its own domain, it joins the shortest-path source based tree rooted at that source. It then redistributes the data received to all interested receivers via the intra-domain shared tree rooted at itself.
域间多播服务（即，源和接收器位于不同的域中）需要附加协议-MSDP[13]和MBGP[26]是最常用的协议。RP使用MSDP协议向其他域中的RPs宣布多播源。当RP发现另一个域中的源向多播组传输数据时，该多播组在其自己的域中有感兴趣的接收器，RP将加入根在该源上的基于源的最短路径树。然后，它通过以自身为根的域内共享树将接收到的数据重新分发给所有感兴趣的接收者。
MBGP defines extensions to the BGP protocol to support the advertisement of reachability information for multicast routes. This allows an autonomous system (AS) to support incongruent unicast and multicast routing topologies, and thus implement separate routing policies for each.
MBGP定义了BGP协议的扩展，以支持多播路由可达性信息的公布。这允许自治系统（AS）支持不一致的单播和多播路由拓扑，从而为每个拓扑实现单独的路由策略。
However, the last-hop routers of interested receivers may eventually switch to a shortest-path tree rooted at the source that is transmitting the data.
然而，感兴趣的接收器的最后一跳路由器可能最终切换到以传输数据的源为根的最短路径树。
There are several deployment problems associated with current multicast architecture:
当前多播体系结构存在多个部署问题：
A) Address Allocation:
A） 地址分配：
Address allocation is one of core deployment challenges posed by the ASM service model. The current multicast architecture does not provide a deployable solution to prevent address collisions among multiple applications. The problem is much less serious for IPv6 than for IPv4 since the size of the multicast address space is much larger. A static address allocation scheme, GLOP [17] has been proposed as an interim solution for IPv4; however, GLOP addresses are allocated per registered AS, which is inadequate in cases where the number of sources exceeds the AS numbers available for mapping. RFC 3138 expands on RFC 2770 to allow routing registries to assign multicast addresses from the GLOP space corresponding to the RFC 1930 private AS space [27]. This space is referred to as the EGLOP (Extended GLOP) address space. Proposed longer-term solutions such as the Multicast Address Allocation Architecture [14] are generally perceived as being too complex (with respect to the dynamic nature of multicast address allocation) for widespread deployment.
地址分配是ASM服务模型带来的核心部署挑战之一。当前的多播体系结构没有提供可部署的解决方案来防止多个应用程序之间的地址冲突。与IPv4相比，IPv6的问题要严重得多，因为多播地址空间的大小要大得多。提出了一种静态地址分配方案GLOP[17]作为IPv4的临时解决方案；但是，GLOP地址是按照注册的AS分配的，这在源数量超过可用于映射的AS数量的情况下是不够的。RFC 3138对RFC 2770进行了扩展，以允许路由注册中心从对应于RFC 1930专用AS空间的GLOP空间分配多播地址[27]。该空间称为EGLOP（扩展GLOP）地址空间。建议的长期解决方案，如多播地址分配体系结构[14]，通常被认为过于复杂（就多播地址分配的动态性质而言），无法广泛部署。
B) Lack of Access control:
B） 缺乏访问控制：
In the ASM service model, a receiver cannot specify which specific sources it would like to receive when it joins a given group. A receiver will be forwarded data sent to a host group by any source. Moreover, even when a source is allocated a multicast group address to transmit on, it has no way of enforcing that no other source will use the same address. This is true even in the case of IPv6, where address collisions are less likely due to the much larger size of the address space.
在ASM服务模型中，接收方无法指定加入给定组时希望接收哪些特定源。任何来源都会将数据转发到主机组。此外，即使为一个源分配了一个多播组地址进行传输，它也无法强制其他源不会使用相同的地址。即使在IPv6的情况下也是如此，由于地址空间大得多，因此地址冲突的可能性较小。
C) Inefficient handling of well-known sources:
C） 知名来源处理效率低下：
In cases where the address of the source is well known in advance of the receiver joining the group, and when the shortest forwarding path is the preferred forwarding mode, then shared tree mechanisms are not necessary.
如果在接收器加入组之前已知源地址，并且当最短转发路径是首选转发模式时，则不需要共享树机制。
As mentioned before, the Source Specific Multicast (SSM) service model defines a "channel" identified by an (S,G) pair, where S is a source address and G is an SSM destination address. Channel subscriptions are described using an SFM-capable group management protocol such as IGMPv3 or MLDv2. Only source-based forwarding trees are needed to implement this model.
如前所述，源特定多播（SSM）服务模型定义了由（S，G）对标识的“信道”，其中S是源地址，G是SSM目的地地址。使用支持SFM的组管理协议（如IGMPv3或MLDv2）描述信道订阅。实现此模型只需要基于源的转发树。
The SSM service model alleviates all of the deployment problems described earlier:
SSM服务模型缓解了前面描述的所有部署问题：
A) Address Allocation: SSM defines channels on a per-source basis, i.e., the channel (S1,G) is distinct from the channel (S2,G), where S1 and S2 are source addresses, and G is an SSM destination address. This averts the problem of global allocation of SSM destination addresses, and makes each source independently responsible for resolving address collisions for the various channels that it creates.
A） 地址分配：SSM基于每个源定义通道，即通道（S1，G）不同于通道（S2，G），其中S1和S2是源地址，G是SSM目标地址。这避免了SSM目标地址的全局分配问题，并使每个源独立负责解决其创建的各种通道的地址冲突。
B) Access Control: SSM lends itself to an elegant solution to the access control problem. When a receiver subscribes to an (S,G) channel, it receives data sent only by the source S. In contrast, any host can transmit to an ASM host group. At the same time, when a sender picks a channel (S,G) to transmit on, it is automatically ensured that no other sender will be transmitting on the same channel (except in the case of malicious acts such as address spoofing). This makes it much harder to "spam" an SSM channel than an ASM multicast group.
B） 访问控制：SSM为访问控制问题提供了一个优雅的解决方案。当接收器订阅（S，G）通道时，它只接收源S发送的数据。相反，任何主机都可以发送到ASM主机组。同时，当发送方选择一个信道（S，G）进行传输时，将自动确保没有其他发送方在同一信道上进行传输（除非发生地址欺骗等恶意行为）。这使得“垃圾邮件”SSM通道比ASM多播组困难得多。
C) Handling of well-known sources: SSM requires only source-based forwarding trees; this eliminates the need for a shared tree infrastructure. This implies that neither the RP-based shared tree infrastructure of PIM-SM nor the MSDP protocol is required. Thus the complexity of the multicast routing infrastructure for SSM is low, making it viable for immediate deployment. Note that there is no difference in how MBGP is used for ASM and SSM.
C） 处理已知源：SSM只需要基于源的转发树；这消除了对共享树基础结构的需要。这意味着既不需要基于RP的PIM-SM共享树基础设施，也不需要MSDP协议。因此，SSM多播路由基础设施的复杂性较低，可以立即部署。请注意，MBGP用于ASM和SSM的方式没有区别。
Figure 1 illustrates the elements in an end-to-end implementation framework for SSM:
图1说明了SSM端到端实施框架中的要素：
--------------------------------------------------------------
IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION
FF3x::/96 for IPv6
--------------------------------------------------------------
|
v
+--------------+ session directory/web page
| source,group | SESSION DESCRIPTION
--------------------------------------------------------------
^ |
Query | | (S,G)
| v
+-----------------+ host
| SSM-aware app | CHANNEL DISCOVERY
--------------------------------------------------------------
| SSM-aware app | SSM-AWARE APPLICATION
--------------------------------------------------------------
| IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING
+-----------------+
|(source specific host report)
--------------------------------------------------------------
v
+-----------------+ Querier Router
| IGMPv3/MLDv2 | QUERIER
--------------------------------------------------------------
| PIM-SSM | PIM-SSM ROUTING
+------------+ Designated Router
|
| (S,G) Join only
v
+-----------+ Backbone Router
| PIM-SSM |
+-----------+
|
| (S,G) Join only
V
--------------------------------------------------------------
IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION
FF3x::/96 for IPv6
--------------------------------------------------------------
|
v
+--------------+ session directory/web page
| source,group | SESSION DESCRIPTION
--------------------------------------------------------------
^ |
Query | | (S,G)
| v
+-----------------+ host
| SSM-aware app | CHANNEL DISCOVERY
--------------------------------------------------------------
| SSM-aware app | SSM-AWARE APPLICATION
--------------------------------------------------------------
| IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING
+-----------------+
|(source specific host report)
--------------------------------------------------------------
v
+-----------------+ Querier Router
| IGMPv3/MLDv2 | QUERIER
--------------------------------------------------------------
| PIM-SSM | PIM-SSM ROUTING
+------------+ Designated Router
|
| (S,G) Join only
v
+-----------+ Backbone Router
| PIM-SSM |
+-----------+
|
| (S,G) Join only
V
Figure 1: SSM Framework: elements in end-to-end model
图1:SSM框架：端到端模型中的元素
We now discuss the framework elements in detail:
我们现在详细讨论框架元素：
For IPv4, the address range of 232/8 has been assigned by IANA for SSM. To ensure global SSM functionality in 232/8, including in networks where routers run non-SFM-capable protocols, operational policies are being proposed [9] which recommend that routers should not send SSM traffic to parts of the network that do not have channel subscribers.
对于IPv4，IANA为SSM分配了232/8的地址范围。为了确保232/8中的全局SSM功能，包括在路由器运行不支持SFM的协议的网络中，正在提出操作策略[9]，建议路由器不应将SSM通信发送到没有信道订户的网络部分。
Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8 range. However, SSM service, as defined in [5], is available only in this address range for IPv4.
请注意，IGMPv3/MLDv2并没有将（S，G）连接仅限制在232/8范围内。但[5]中定义的SSM服务仅在此地址范围内可用于IPv4。
In case of IPv6, [23] has defined an extension to the addressing architecture to allow for unicast prefix-based multicast addresses. See RFC 3306 for details.
在IPv6的情况下，[23]定义了寻址体系结构的扩展，以允许基于单播前缀的多播地址。详见RFC 3306。
An SSM receiver application must know both the SSM destination address G and the source address S before subscribing to a channel. Channel discovery is the responsibility of applications. This information can be made available in a number of ways, including via web pages, sessions announcement applications, etc. This is similar to what is used for ASM applications where a multicast session needs to be announced so that potential subscribers can know of the multicast group address, encoding schemes used, etc. In fact, the only additional piece of information that needs to be announced is the source address for the channel being advertised. However, the exact mechanisms for doing this is outside the scope of this framework document.
SSM接收器应用程序在订阅信道之前必须知道SSM目标地址G和源地址S。通道发现是应用程序的责任。这些信息可以通过多种方式提供，包括通过网页、会话公告应用程序等。这与ASM应用程序使用的类似，ASM应用程序需要公告多播会话，以便潜在订户可以知道多播组地址、使用的编码方案等。事实上，唯一需要宣布的附加信息是正在广告的频道的源地址。然而，实现这一点的确切机制不在本框架文件的范围之内。
There are two main issues in making multicast applications "SSM-aware":
使多播应用程序“支持SSM”有两个主要问题：
- An application that wants to receive an SSM session must first discover the channel address in use.
- 想要接收SSM会话的应用程序必须首先发现正在使用的通道地址。
- A receiving application must be able to specify both a source address and a destination address to the network layer protocol module on the end-host.
- 接收应用程序必须能够为终端主机上的网络层协议模块指定源地址和目标地址。
Specific API requirements are identified in [16]. [16] describes a recommended application programming interface for a host operating system to support the SFM service model. Although it is intended for SFM, a subset of this interface is sufficient for supporting SSM.
具体的API要求见[16]。[16] 描述主机操作系统的推荐应用程序编程接口，以支持SFM服务模型。尽管它是为SFM设计的，但该接口的一个子集足以支持SSM。
In order to use SSM service, an end-host must be able to specify a channel address, consisting of a source's unicast address and an SSM destination address. IGMP version 2 [3] and MLD version 1 [19] allows an end-host to specify only a destination multicast address. The ability to specify an SSM channel address c is provided by IGMP version 3 [3] and MLD version 2 [20]. These protocols support "source filtering", i.e., the ability of an end-system to express interest in receiving data packets sent only by SPECIFIC sources, or from ALL BUT some specific sources. In fact, IGMPv3 provides a superset of the capabilities required to realize the SSM service model.
为了使用SSM服务，终端主机必须能够指定通道地址，该地址由源单播地址和SSM目标地址组成。IGMP版本2[3]和MLD版本1[19]允许终端主机仅指定目标多播地址。IGMP版本3[3]和MLD版本2[20]提供了指定SSM信道地址c的能力。这些协议支持“源过滤”，即终端系统表示有兴趣接收仅由特定源或从除某些特定源以外的所有源发送的数据包的能力。事实上，IGMPv3提供了实现SSM服务模型所需的功能的超集。
A detailed discussion of the use of IGMPv3 in the SSM destination address range is provided in [4].
A detailed discussion of the use of IGMPv3 in the SSM destination address range is provided in [4].translate error, please retry
The Multicast Listener Discovery (MLD) protocol used by an IPv6 router to discover the presence of multicast listeners on its directly attached links, and to discover the multicast addresses that are of interest to those neighboring nodes. MLD version 1 is derived from IGMPv2 and does not provide the source filtering capability required for the SSM service model. MLD version 2 is derived from, and provides the same support for source-filtering as, IGMPv3. Thus IGMPv3 (or MLDv2 for IPv6) provides a host with the ability to request the network for an SSM channel subscription.
IPv6路由器使用的多播侦听器发现（MLD）协议，用于发现其直接连接的链路上是否存在多播侦听器，并发现那些相邻节点感兴趣的多播地址。MLD版本1源自IGMPv2，不提供SSM服务模型所需的源筛选功能。MLD版本2源自IGMPv3，并提供与IGMPv3相同的源代码过滤支持。因此，IGMPv3（或用于IPv6的MLDv2）为主机提供了向网络请求SSM信道订阅的能力。
[9] provides guidelines for how a PIM-SM implementation should handle source-specific host reports as required by SSM. Earlier versions of the PIM protocol specifications did not describe how to do this.
[9] 提供PIM-SM实施应如何按照SSM要求处理源特定主机报告的指南。PIM协议规范的早期版本没有描述如何做到这一点。
The router requirements for operation in the SSM range are detailed in [5]. These rules are primarily concerned with preventing ASM-style behaviour in the SSM address range. In order to comply with [5] several changes to the PIM-SM protocol are required, as described in [9]. The most important changes in PIM-SM required for compliance with [5] are:
在SSM范围内运行的路由器要求详见[5]。这些规则主要涉及防止SSM地址范围内的ASM样式行为。为了符合[5]的要求，需要对PIM-SM协议进行几处更改，如[9]所述。为符合[5]的要求，PIM-SM中最重要的变化是：
- When a DR receives an (S,G) join request with the address G in the SSM address range, it MUST initiate a (S,G) join, and NEVER a (*,G) join.
- 当DR接收到地址G在SSM地址范围内的（S，G）加入请求时，它必须启动（S，G）加入，而不能（*，G）加入。
- Backbone routers (i.e., routers that do not have directly attached hosts) MUST NOT propagate (*,G) joins for group addresses in the SSM address range.
- 主干路由器（即，没有直接连接主机的路由器）不得为SSM地址范围内的组地址传播（*，G）连接。
- Rendezvous Points (RPs) MUST NOT accept PIM Register messages or (*,G) Join messages in the SSM address range.
- 集合点（RP）不得接受SSM地址范围内的PIM注册消息或（*，G）连接消息。
Note that only a small subset of the full PIM-SM protocol functionality is needed to support the SSM service model. This subset is explicitly documented in [9].
请注意，支持SSM服务模型只需要完整PIM-SM协议功能的一小部分。[9]中明确记录了该子集。
Interoperability with ASM is one of the most important issues in moving to SSM deployment, since both models are expected to be used at least in the foreseeable future. SSM is the ONLY service model for the SSM address range - the correct protocol behaviour for this range is specified in [5]. The ASM service model will be offered for the non-SSM address range, where receivers can issue (*,G) join requests to receive multicast data. A receiver is also allowed to issue an (S,G) join request in the non-SSM address range; however, in that case there is no guarantee that it will receive service according to the SSM model.
与ASM的互操作性是转向SSM部署过程中最重要的问题之一，因为这两种模型预计至少在可预见的将来都会使用。SSM是SSM地址范围的唯一服务模型-此范围的正确协议行为在[5]中指定。ASM服务模型将针对非SSM地址范围提供，在该地址范围内，接收器可以发出（*，G）加入请求以接收多播数据。还允许接收方在非SSM地址范围内发出（S，G）加入请求；但是，在这种情况下，不能保证它将根据SSM模型接收服务。
Another interoperability issue concerns the MSDP protocol, which is used between PIM-SM rendezvous points (RPs) to discover multicast sources across multiple domains. MSDP is not needed for SSM, but is needed if ASM is supported. [9] specifies operational recommendations to help ensure that MSDP does not interfere with the ability of a network to support the SSM service model. Specifically, [9] states that RPs must not accept, originate or forward MSDP SA messages for the SSM address range.
另一个互操作性问题涉及MSDP协议，该协议在PIM-SM集合点（RPs）之间用于发现跨多个域的多播源。SSM不需要MSDP，但如果支持ASM，则需要MSDP。[9] 指定操作建议，以帮助确保MSDP不会干扰网络支持SSM服务模型的能力。具体而言，[9]规定RPs不得接受、发起或转发SSM地址范围内的MSDP SA消息。
SSM does not introduce new security considerations for IP multicast. It can help in preventing denial-of-service attacks resulting from unwanted sources transmitting data to a multicast channel (S, G). However no guarantee is provided.
SSM没有为IP多播引入新的安全注意事项。它有助于防止由于不需要的源向多播信道（S、G）传输数据而导致的拒绝服务攻击。但是，没有提供任何保证。
We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Timothy Roscoe, Hugh Holbrook, Isidor Kouvelas, Tony Speakman and Nidhi Bhaskar for participating in lengthy discussions and design work on SSM, and providing feedback on this document. Thanks are also due to Mujahid Khan, Ted Seely, Tom Pusateri, Bill Fenner, Kevin Almeroth, Brian Levine, Brad Cain, Hugh LaMaster and Pekka Savola for their valuable insights and continuing support.
我们要感谢Gene Bowen、Ed Kress、Bryan Lyles、Timothy Roscoe、Hugh Holbrook、Isidor Kouvelas、Tony Speakman和Nidhi Bhaskar参与了有关SSM的长期讨论和设计工作，并就本文件提供了反馈。感谢穆贾希德·汗、特德·希利、汤姆·普萨特里、比尔·芬纳、凯文·阿尔梅罗斯、布莱恩·莱文、布拉德·凯恩、休·拉马斯特和佩卡·萨沃拉，感谢他们的宝贵见解和持续支持。
[1] Holbrook, H. and D.R. Cheriton, "IP Multicast Channels: EXPRESS Support for Large-scale Single-Source Applications", In Proceedings of SIGCOMM 1999.
[1] Holbrook，H.和D.R.Cheriton，“IP多播信道：对大规模单源应用程序的快速支持”，发表于SIGCOMM 1999年论文集。
[2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[2] Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan, "Internet Group Management Protocol, Version 3.", RFC 3376, October 2002.
[3] Cain，B.，Deering，S.，Kouvelas，I.和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[4] Holbrook, H. and B. Cain, "Using IGMPv3 and MLDv2 for Source-Specific Multicast", Work In Progress.
[4] Holbrook，H.和B.Cain，“将IGMPv3和MLDv2用于源特定多播”，工作正在进行中。
[5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work in Progress.
[5] Holbrook，H.和B.Cain，“IP的源特定多播”，工作正在进行中。
[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.
[6] Deering，S.和D.Cheriton，“数据报网络和扩展LAN中的多播路由”，计算机系统上的ACM事务，8（2）：85-110，1990年5月。
[7] Deering, S. et al., "PIM Architecture for Wide-Area Multicast Routing", IEEE/ACM Transaction on Networking, pages 153-162, April 1996.
[7] Deering，S.等人，“广域多播路由的PIM架构”，IEEE/ACM网络事务，第153-162页，1996年4月。
[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.
[8] Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.和L.Wei，“协议独立多播-稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[9] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Work In Progress.
[9] Fenner，B.，Handley，M.，Holbrook，H.和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，正在进行的工作。
[10] Adams, A., Nicholas, J. and W. Siadek, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", Work In Progress.
[10] Adams，A.，Nicholas，J.和W.Siadek，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，正在进行的工作。
[11] Ballardie, A., "Core-Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[11] Ballardie，A.，“基于核心的树（CBT）多播路由架构”，RFC2201，1997年9月。
[12] Meyer, D., "Adminstratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[12] Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[13] Farinacci, D. et al., "Multicast Source Discovery Protocol", Work In Progress.
[13] Farinaci，D.等人，“多播源发现协议”，正在进行中。
[14] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[14] Thaler，D.，Handley，M.和D.Estrin，“互联网多播地址分配架构”，RFC 2908，2000年9月。
[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.
[15] Diot，C.，Levine，B.，Lyles，B.，Kassem，H.和D.Balensiefen，“IP多播服务和体系结构的部署问题”，载于IEEE网络杂志关于多播的特刊，2000年1月。
[16] Thaler, D., Fenner B. and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", Work in Progress.
[16] Thaler，D.，Fenner B.和B.Quinn，“多播源过滤器的套接字接口扩展”，正在进行中。
[17] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[17] Meyer，D.和P.Lothberg，“233/8中的GLOP寻址”，BCP 53，RFC 31802001年9月。
[18] Levine, B. et al., "Consideration of Receiver Interest for IP Multicast Delivery", In Proceedings of IEEE Infocom, March 2000.
[18] Levine，B.等人，“考虑IP多播传送的接收器利益”，IEEE信息通信会议录，2000年3月。
[19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery for IPv6", RFC 2710, October 1999.
[19] Deering，S.，Fenner，W.和B.Haberman，“IPv6多播侦听器发现”，RFC 2710，1999年10月。
[20] Vida, R. et. al., "Multicast Listener Discovery Version 2(MLDv2) for IPv6", Work In Progress.
[20] Vida，R.等人，“IPv6多播侦听器发现版本2（MLDv2）”，正在进行中。
[21] Haberman, B. and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast Addresses", RFC 3306, August 1992.
[21] Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC33061992年8月。
[22] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[22] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[23] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[23] Haberman，B.，“IPv6多播地址分配指南”，RFC33072002年8月。
[24] Ballardie, A., "Core-Based Trees (CBT Version 2) Multicast Routing -- Protocol Specification", RFC 2189, September 2001.
[24] Ballardie，A.，“基于核心的树（CBT版本2）多播路由——协议规范”，RFC2189，2001年9月。
[25] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[25] Deering，S.，“IP多播的主机扩展”，STD 5，RFC 1112，1989年8月。
[26] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[26] Bates，T.，Rekhter，Y.，Chandra，R.和D.Katz，“BGP-4的多协议扩展”，RFC 28582000年6月。
[27] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.
[27] Meyer，D.，“233/8年的延长任务”，RFC 3138，2001年6月。
[28] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[28] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Christophe Diot Intel EMail: christophe.diot@intel.com
克里斯托夫·迪奥英特尔电子邮件：克里斯托夫。diot@intel.com
Leonard Giuliano Juniper Networks EMail: lenny@juniper.net
Leonard Giuliano Juniper Networks电子邮件：lenny@juniper.net
Greg Shepherd Procket Networks EMail: shep@procket.com
Greg Shepherd Procket Networks电子邮件：shep@procket.com
Robert Rockell Sprint EMail: rrockell@sprint.net
Robert Rockell Sprint电子邮件：rrockell@sprint.net
David Meyer Sprint EMail: dmm@1-4-5.net
David Meyer Sprint电子邮件：dmm@1-4-5.net
John Meylor Cisco Systems EMail: jmeylor@cisco.com
John Meylor Cisco Systems电子邮件：jmeylor@cisco.com
Brian Haberman Caspian Networks EMail: bkhabs@nc.rr.com
Brian Haberman里海网络电子邮件：bkhabs@nc.rr.com
Supratik Bhattacharyya Sprint
超短跑
EMail: supratik@sprintlabs.com
EMail: supratik@sprintlabs.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。