Network Working Group P. Savola
Request for Comments: 5110 CSC/FUNET
Category: Informational January 2008
Network Working Group P. Savola
Request for Comments: 5110 CSC/FUNET
Category: Informational January 2008
Overview of the Internet Multicast Routing Architecture
Internet组播路由体系结构综述
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.
本文档描述了当前部署在Internet上的多播路由体系结构。本文档简要描述了这些协议并参考了它们的规范。
This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse.
该备忘录还将几个旧RFC重新分类为历史RFC。这些RFC描述了从未广泛部署或废弃的多播路由协议。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Multicast-Related Abbreviations ............................4
2. Multicast Routing ...............................................4
2.1. Setting up Multicast Forwarding State ......................5
2.1.1. PIM-SM ..............................................5
2.1.2. PIM-DM ..............................................5
2.1.3. Bidirectional PIM ...................................6
2.1.4. DVMRP ...............................................6
2.1.5. MOSPF ...............................................7
2.1.6. BGMP ................................................7
2.1.7. CBT .................................................7
2.1.8. Interactions and Summary ............................7
2.2. Distributing Topology Information ..........................8
2.2.1. Multiprotocol BGP ...................................8
2.2.2. OSPF/IS-IS Multi-Topology Extensions ................9
2.2.3. Issue: Overlapping Unicast/Multicast Topology .......9
2.2.4. Summary ............................................10
2.3. Learning (Active) Sources .................................10
2.3.1. SSM ................................................11
2.3.2. MSDP ...............................................11
2.3.3. Embedded-RP ........................................11
2.3.4. Summary ............................................12
1. Introduction ....................................................3
1.1. Multicast-Related Abbreviations ............................4
2. Multicast Routing ...............................................4
2.1. Setting up Multicast Forwarding State ......................5
2.1.1. PIM-SM ..............................................5
2.1.2. PIM-DM ..............................................5
2.1.3. Bidirectional PIM ...................................6
2.1.4. DVMRP ...............................................6
2.1.5. MOSPF ...............................................7
2.1.6. BGMP ................................................7
2.1.7. CBT .................................................7
2.1.8. Interactions and Summary ............................7
2.2. Distributing Topology Information ..........................8
2.2.1. Multiprotocol BGP ...................................8
2.2.2. OSPF/IS-IS Multi-Topology Extensions ................9
2.2.3. Issue: Overlapping Unicast/Multicast Topology .......9
2.2.4. Summary ............................................10
2.3. Learning (Active) Sources .................................10
2.3.1. SSM ................................................11
2.3.2. MSDP ...............................................11
2.3.3. Embedded-RP ........................................11
2.3.4. Summary ............................................12
2.4. Configuring and Distributing PIM RP Information ...........12
2.4.1. Manual RP Configuration ............................12
2.4.2. Embedded-RP ........................................13
2.4.3. BSR and Auto-RP ....................................13
2.4.4. Summary ............................................14
2.5. Mechanisms for Enhanced Redundancy ........................14
2.5.1. Anycast RP .........................................14
2.5.2. Stateless RP Failover ..............................14
2.5.3. Bidirectional PIM ..................................15
2.5.4. Summary ............................................15
2.6. Interactions with Hosts ...................................15
2.6.1. Hosts Sending Multicast ............................15
2.6.2. Hosts Receiving Multicast ..........................15
2.6.3. Summary ............................................16
2.7. Restricting Multicast Flooding in the Link Layer ..........16
2.7.1. Router-to-Router Flooding Reduction ................16
2.7.2. Host/Router Flooding Reduction .....................17
2.7.3. Summary ............................................18
3. Acknowledgements ...............................................18
4. IANA Considerations ............................................18
5. Security Considerations ........................................19
6. References .....................................................19
6.1. Normative References ......................................19
6.2. Informative References ....................................20
Appendix A. Multicast Payload Transport Extensions.................24
A.1. Reliable Multicast.........................................24
A.2. Multicast Group Security...................................24
2.4. Configuring and Distributing PIM RP Information ...........12
2.4.1. Manual RP Configuration ............................12
2.4.2. Embedded-RP ........................................13
2.4.3. BSR and Auto-RP ....................................13
2.4.4. Summary ............................................14
2.5. Mechanisms for Enhanced Redundancy ........................14
2.5.1. Anycast RP .........................................14
2.5.2. Stateless RP Failover ..............................14
2.5.3. Bidirectional PIM ..................................15
2.5.4. Summary ............................................15
2.6. Interactions with Hosts ...................................15
2.6.1. Hosts Sending Multicast ............................15
2.6.2. Hosts Receiving Multicast ..........................15
2.6.3. Summary ............................................16
2.7. Restricting Multicast Flooding in the Link Layer ..........16
2.7.1. Router-to-Router Flooding Reduction ................16
2.7.2. Host/Router Flooding Reduction .....................17
2.7.3. Summary ............................................18
3. Acknowledgements ...............................................18
4. IANA Considerations ............................................18
5. Security Considerations ........................................19
6. References .....................................................19
6.1. Normative References ......................................19
6.2. Informative References ....................................20
Appendix A. Multicast Payload Transport Extensions.................24
A.1. Reliable Multicast.........................................24
A.2. Multicast Group Security...................................24
This document provides a brief overview of multicast routing architectures that are currently deployed on the Internet and how those protocols fit together. It also describes those multicast routing protocols that were never widely deployed or have fallen into disuse. A companion document [ADDRARCH] describes multicast addressing architectures.
本文档简要概述了当前部署在Internet上的多播路由体系结构，以及这些协议是如何结合在一起的。它还描述了那些从未被广泛部署或废弃的多播路由协议。附带文档[ADDRARCH]描述了多播寻址体系结构。
Specifically, this memo deals with:
具体而言，本备忘录涉及：
o setting up multicast forwarding state (Section 2.1),
o 设置多播转发状态（第2.1节），
o distributing multicast topology information (Section 2.2),
o 分发多播拓扑信息（第2.2节），
o learning active sources (Section 2.3),
o 学习活动来源（第2.3节），
o configuring and distributing the rendezvous point (RP) information (Section 2.4),
o 配置和分发交会点（RP）信息（第2.4节），
o mechanisms for enhanced redundancy (Section 2.5),
o 增强冗余的机制（第2.5节），
o interacting with hosts (Section 2.6), and
o 与主机交互（第2.6节），以及
o restricting the multicast flooding in the link layer (Section 2.7).
o 限制链路层中的多播泛洪（第2.7节）。
Section 2 starts by describing a simplistic example how these classes of mechanisms fit together. Some multicast data transport issues are also introduced in Appendix A.
第2节首先描述了一个简单的示例，说明了这些机制类是如何组合在一起的。附录A中还介绍了一些多播数据传输问题。
This memo reclassifies to Historic [RFC2026] the following RFCs:
本备忘录将以下RFC重新分类为历史[RFC2026]：
o Border Gateway Multicast Protocol (BGMP) [RFC3913],
o 边界网关多播协议（BGMP）[RFC3913]，
o Core Based Trees (CBT) [RFC2189] [RFC2201],
o 基于核心的树（CBT）[RFC2189][RFC2201]，
o Multicast OSPF (MOSPF) [RFC1584].
o 多播OSPF（MOSPF）[RFC1584]。
For the most part, these protocols have fallen into disuse. There may be legacy deployments of some of these protocols, which are not affected by this reclassification. See Section 2.1 for more on each protocol.
在大多数情况下，这些协议已被废弃。其中一些协议可能存在遗留部署，不受此重新分类的影响。有关每个协议的更多信息，请参见第2.1节。
Further historical perspective may be found in, for example, [RFC1458], [IMRP-ISSUES], and [IM-GAPS].
例如，可以在[RFC1458]、[IMRP-ISSUES]和[IM-GAPS]中找到进一步的历史观点。
ASM Any Source Multicast BGMP Border Gateway Multicast Protocol BSR Bootstrap Router CBT Core Based Trees CGMP Cisco Group Management Protocol DR Designated Router DVMRP Distance Vector Multicast Routing Protocol GARP (IEEE 802.1D-2004) Generic Attribute Registration Protocol GMRP GARP Multicast Registration Protocol IGMP Internet Group Management Protocol MBGP Multiprotocol BGP (*not* "Multicast BGP") MLD Multicast Listener Discovery MRP (IEEE 802.1ak) Multiple Registration Protocol MMRP (IEEE 802.1ak) Multicast Multiple Registration Protocol MOSPF Multicast OSPF MSDP Multicast Source Discovery Protocol PGM Pragmatic General Multicast PIM Protocol Independent Multicast PIM-DM PIM - Dense Mode PIM-SM PIM - Sparse Mode PIM-SSM PIM - Source-Specific Multicast RGMP (Cisco's) Router Group Management Protocol RP Rendezvous Point RPF Reverse Path Forwarding SAFI Subsequent Address Family Identifier SDP Session Description Protocol SSM Source-Specific Multicast
ASM任意源多播BGMP边界网关多播协议BSR引导路由器CBT基于核心的树CGMP Cisco组管理协议DR指定路由器DVMRP距离向量多播路由协议GARP（IEEE 802.1D-2004）通用属性注册协议GMRP GARP多播注册协议IGMP Internet组管理协议MBGP多协议BGP（*非*“多播BGP”）MLD多播侦听器发现MRP（IEEE 802.1ak）多注册协议MMRP（IEEE 802.1ak）多播多重注册协议MOSPF多播OSPF MSDP多播源发现协议PGM实用通用多播PIM协议独立多播PIM-DM PIM-密集模式PIM-SM PIM-稀疏模式PIM-SSM PIM-源特定多播RGMP（Cisco's）路由器组管理协议RP集合点RPF反向路径转发SAFI后续地址族标识符SDP会话描述协议SSM源特定多播
In order to give a simplified summary how each of these class of mechanisms fits together, consider the following multicast receiver scenario.
为了简单地总结这些类的机制是如何组合在一起的，考虑下面的多播接收器场景。
Certain protocols and configurations need to be in place before multicast routing can work. Specifically, when ASM is employed, a router will need to know its RP address(es) (Section 2.4, Section 2.5). With IPv4, RPs need to be connected to other RPs using MSDP so information about sources connected to other RPs can be distributed (Section 2.3). Further, routers need to know if or how multicast topology differs from unicast topology, and routing protocol extensions can provide that information (Section 2.2).
在多播路由可以工作之前，某些协议和配置需要到位。具体来说，当使用ASM时，路由器需要知道其RP地址（第2.4节和第2.5节）。对于IPv4，RPs需要使用MSDP连接到其他RPs，以便可以分发有关连接到其他RPs的源的信息（第2.3节）。此外，路由器需要知道多播拓扑与单播拓扑是否或如何不同，路由协议扩展可以提供这些信息（第2.2节）。
When a host wants to receive a transmission, it first needs to find out the multicast group address (and with SSM, source address) using various means (e.g., SDP description file [RFC4566] or manually). Then it will signal its interest to its first-hop router using IGMP (IPv4) or MLD (IPv6) (Section 2.6). The router initiates setting up hop-by-hop multicast forwarding state (Section 2.1) to the source (in SSM) or first through the RP (in ASM). Routers use an RP to find out all the sources for a group (Section 2.3). When multicast transmission arrives at the receiver's LAN, it is flooded to every Ethernet switch port unless flooding reduction such as IGMP snooping is employed (Section 2.7).
当主机想要接收传输时，它首先需要使用各种手段（例如SDP描述文件[RFC4566]或手动）找出多播组地址（以及SSM、源地址）。然后，它将使用IGMP（IPv4）或MLD（IPv6）向其第一跳路由器发出感兴趣的信号（第2.6节）。路由器开始设置逐跳多播转发状态（第2.1节）到源（在SSM中）或首先通过RP（在ASM中）。路由器使用RP查找组的所有源（第2.3节）。当多播传输到达接收器的LAN时，它被淹没到每个以太网交换机端口，除非采用诸如IGMP窥探之类的淹没减少（第2.7节）。
The most important part of multicast routing is setting up the multicast forwarding state. State maintenance requires periodic messaging because forwarding state has a timeout. This section describes the protocols commonly used for this purpose.
组播路由最重要的部分是建立组播转发状态。状态维护需要定期发送消息，因为转发状态有超时。本节介绍了用于此目的的常用协议。
By far, the most common multicast routing protocol is PIM-SM [RFC4601]. The PIM-SM protocol includes both Any Source Multicast (ASM) and Source-Specific Multicast (SSM) functionality. PIM-SSM is a subset of PIM-SM that does not use the RPs but instead requires that receivers know the (source,group) pair and signal that explicitly. Most current routing platforms support PIM-SM.
到目前为止，最常见的多播路由协议是PIM-SM[RFC4601]。PIM-SM协议包括任意源多播（ASM）和源特定多播（SSM）功能。PIM-SSM是PIM-SM的一个子集，它不使用RPs，而是要求接收机明确知道（源、组）对和信号。目前大多数路由平台都支持PIM-SM。
PIM routers elect a designated router on each LAN and the DR is responsible for PIM messaging and source registration on behalf of the hosts. The DR encapsulates multicast packets sourced from the LAN in a unicast tunnel to the RP. PIM-SM builds a unidirectional, group-specific distribution tree consisting of the interested receivers of a group. Initially, the multicast distribution tree is rooted at the RP but later the DRs have the option of optimizing the delivery by building (source,group)-specific trees.
PIM路由器在每个LAN上选择一个指定的路由器，DR代表主机负责PIM消息传递和源注册。DR通过单播隧道将来自LAN的多播数据包封装到RP。PIM-SM构建一个单向的、特定于组的分发树，由组中感兴趣的接收器组成。最初，多播分发树植根于RP，但后来DRs可以选择通过构建（源、组）特定的树来优化交付。
A more lengthy introduction to PIM-SM can be found in Section 3 of [RFC4601].
关于PIM-SM的更详细介绍，请参见[RFC4601]第3节。
Whereas PIM-SM has been designed to avoid unnecessary flooding of multicast data, PIM-DM [RFC3973] assumed that almost every subnet at a site had at least one receiver for a group. PIM-DM floods multicast transmissions throughout the network ("flood and prune") unless the leaf parts of the network periodically indicate that they are not interested in that particular group.
PIM-SM旨在避免不必要的多播数据泛滥，而PIM-DM[RFC3973]则假设一个站点的几乎每个子网都有一个组的至少一个接收器。PIM-DM在整个网络中泛滥多播传输（“泛滥和修剪”），除非网络的叶子部分周期性地表示它们对该特定组不感兴趣。
PIM-DM may be an acceptable fit in small and/or simple networks, where setting up an RP would be unnecessary, and possibly in cases where a large percentage of users are expected to want to receive the transmission so that the amount of state the network has to keep is minimal.
在小型和/或简单网络中，PIM-DM可能是一种可接受的配合，在这种情况下，设置RP是不必要的，并且可能在很大比例的用户希望接收传输的情况下，这样网络必须保持的状态量是最小的。
PIM-DM was used as a first step in transitioning away from DVMRP. It also became apparent that most networks would not have receivers for most groups, and to avoid the bandwidth and state overhead, the flooding paradigm was gradually abandoned. Transitioning from PIM-DM to PIM-SM was easy as PIM-SM was designed to use compatible packet formats and dense-mode operation could also be satisfied by a sparse protocol. PIM-DM is no longer in widespread use.
PIM-DM被用作从DVMRP过渡的第一步。很明显，大多数网络的大多数组都没有接收器，为了避免带宽和状态开销，洪泛模式逐渐被放弃。从PIM-DM到PIM-SM的转换很容易，因为PIM-SM被设计为使用兼容的数据包格式，并且密集模式操作也可以通过稀疏协议来满足。PIM-DM不再广泛使用。
Many implementations also support so-called "sparse-dense" configuration, where Sparse mode is used by default, but Dense is used for configured multicast group ranges (such as Auto-RP in Section 2.4.3) only. Lately, many networks have transitioned away from sparse-dense to only sparse mode.
许多实现还支持所谓的“稀疏密集”配置，默认情况下使用稀疏模式，但密集仅用于配置的多播组范围（如第2.4.3节中的自动RP）。最近，许多网络已经从稀疏密集模式转变为仅稀疏模式。
Bidirectional PIM [RFC5015] is a multicast forwarding protocol that establishes a common shared-path for all sources with a single root. It can be used as an alternative to PIM-SM inside a single domain. It doesn't have data-driven events or data-encapsulation. As it doesn't keep source-specific state, it may be an appealing approach especially in sites with a large number of sources.
双向PIM[RFC5015]是一种多播转发协议，它为具有单个根的所有源建立公共共享路径。它可以在单个域内用作PIM-SM的替代方案。它没有数据驱动的事件或数据封装。由于它不保持特定于源的状态，因此它可能是一种吸引人的方法，尤其是在具有大量源的站点中。
As of this writing, there is no inter-domain solution to configure a group range to use bidirectional PIM.
在撰写本文时，还没有域间解决方案可以将组范围配置为使用双向PIM。
Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] [DVMRPv3] [DVMRPv3-AS] was the first protocol designed for multicasting. To get around initial deployment hurdles, it also included tunneling capabilities, which were part of its multicast topology functions.
距离向量多播路由协议（DVMRP）[RFC1075][DVMRPv3][DVMRPv3 AS]是为多播设计的第一个协议。为了绕过最初的部署障碍，它还包括隧道功能，这是其多播拓扑功能的一部分。
Currently, DVMRP is used only very rarely in operator networks, having been replaced with PIM-SM. The most typical deployment of DVMRP is at a leaf network, to run from a legacy firewall only supporting DVMRP to the internal network. However, Generic Routing Encapsulation (GRE) tunneling [RFC2784] seems to have overtaken DVMRP in this functionality, and there is relatively little use for DVMRP except in legacy deployments.
目前，DVMRP在运营商网络中很少使用，已被PIM-SM取代。DVMRP最典型的部署是在叶子网络上，从只支持DVMRP的传统防火墙运行到内部网络。然而，通用路由封装（GRE）隧道[RFC2784]在这一功能上似乎已经超过了DVMRP，并且DVMRP除了在传统部署中的使用相对较少。
MOSPF [RFC1584] was implemented by several vendors and has seen some deployment in intra-domain networks. However, since it is based on intra-domain Open Shortest Path First (OSPF) it does not scale to the inter-domain case, operators have found it is easier to deploy a single protocol for use in both intra-domain and inter-domain networks and so it is no longer being actively deployed.
MOSPF[RFC1584]由多家供应商实施，并在域内网络中进行了一些部署。然而，由于它基于域内开放最短路径优先（OSPF），因此无法扩展到域间情况，运营商发现在域内和域间网络中部署单一协议更容易，因此不再积极部署。
BGMP [RFC3913] did not get sufficient support within the service provider community to get adopted and moved forward in the IETF standards process. There were no reported production implementations and no production deployments.
BGMP[RFC3913]在服务提供商社区中没有得到足够的支持，无法在IETF标准过程中得到采纳和推进。没有报告生产实施，也没有生产部署。
CBT [RFC2201][RFC2189] was an academic project that provided the basis for PIM sparse mode shared trees. Once the shared tree functionality was incorporated into PIM implementations, there was no longer a need for a production CBT implementation. Therefore, CBT never saw production deployment.
CBT[RFC2201][RFC2189]是一个学术项目，为PIM稀疏模式共享树提供了基础。一旦共享树功能被合并到PIM实现中，就不再需要生产CBT实现。因此，CBT从未见过生产部署。
It is worth noting that it is possible to run different protocols with different multicast group ranges. For example, treat some groups as dense or bidirectional in an otherwise PIM-SM network; this typically requires manual configuration of the groups or a mechanism like BSR (Section 2.4.3). It is also possible to interact between different protocols; for example, use DVMRP in the leaf network, but PIM-SM upstream. The basics for interactions among different protocols have been outlined in [RFC2715].
值得注意的是，可以使用不同的多播组范围运行不同的协议。例如，在其他PIM-SM网络中，将一些组视为密集或双向的；这通常需要手动配置组或类似BSR的机制（第2.4.3节）。也可以在不同协议之间进行交互；例如，在叶网络中使用DVMRP，但在上游使用PIM-SM。[RFC2715]概述了不同协议之间交互的基础。
The following figure gives a concise summary of the deployment status of different protocols as of this writing.
下图简要总结了撰写本文时不同协议的部署状态。
+--------------+--------------+----------------+
| Inter-domain | Intra-domain | Status |
+------------+--------------+--------------+----------------+
| PIM-SM | Yes | Yes | Active |
| PIM-DM | Not anymore | Not anymore | Little use |
| BIDIR-PIM | No | Yes | Some uptake |
| DVMRP | Not anymore | Stub only | Going out |
| MOSPF | No | Not anymore | Inactive |
| CBT | No | No | Never deployed |
| BGMP | No | No | Never deployed |
+------------+--------------+--------------+----------------+
+--------------+--------------+----------------+
| Inter-domain | Intra-domain | Status |
+------------+--------------+--------------+----------------+
| PIM-SM | Yes | Yes | Active |
| PIM-DM | Not anymore | Not anymore | Little use |
| BIDIR-PIM | No | Yes | Some uptake |
| DVMRP | Not anymore | Stub only | Going out |
| MOSPF | No | Not anymore | Inactive |
| CBT | No | No | Never deployed |
| BGMP | No | No | Never deployed |
+------------+--------------+--------------+----------------+
From this table, it is clear that PIM-Sparse Mode is the only multicast routing protocol that is deployed inter-domain and, therefore, is most frequently used within multicast domains as well.
从这个表中可以清楚地看出，PIM稀疏模式是唯一部署在域间的多播路由协议，因此在多播域内也最常用。
PIM has become the de-facto multicast forwarding protocol, but as its name implies, it is independent of the underlying unicast routing protocol. When unicast and multicast topologies are the same ("congruent"), i.e., use the same routing tables (routing information base, RIB), it has been considered sufficient just to distribute one set of reachability information to be used in conjunction with a protocol that sets up multicast forwarding state (e.g., PIM-SM).
PIM已经成为事实上的多播转发协议，但顾名思义，它独立于底层的单播路由协议。当单播和多播拓扑相同（“一致”）时，即使用相同的路由表（路由信息库，RIB），仅分发一组可达性信息就足以与设置多播转发状态的协议（例如PIM-SM）一起使用。
However, when PIM which by default built multicast topology based on the unicast topology gained popularity, it became apparent that it would be necessary to be able to distribute also non-congruent multicast reachability information in the regular unicast protocols. This was previously not an issue, because DVMRP built its own reachability information.
然而，当默认基于单播拓扑构建多播拓扑的PIM获得普及时，很明显，在常规单播协议中也需要能够分发非一致多播可达性信息。这以前不是问题，因为DVMRP构建了自己的可达性信息。
The topology information is needed to perform efficient distribution of multicast transmissions and to prevent transmission loops by applying it to the Reverse Path Forwarding (RPF) check.
需要拓扑信息来执行多播传输的有效分发，并通过将其应用于反向路径转发（RPF）检查来防止传输循环。
This subsection introduces these protocols.
本小节介绍这些协议。
Multiprotocol Extensions for BGP-4 [RFC4760] (often referred to as "MBGP"; however, it is worth noting that "MBGP" does *not* stand for "Multicast BGP") specifies a mechanism by which BGP can be used to distribute different reachability information for unicast (SAFI=1) and multicast traffic (SAFI=2). Multiprotocol BGP has been widely
BGP-4的多协议扩展[RFC4760]（通常称为“MBGP”；然而，值得注意的是，“MBGP”不*代表“多播BGP”）指定了一种机制，通过该机制，BGP可以用于为单播（SAFI=1）和多播流量（SAFI=2）分发不同的可达性信息。多协议BGP已得到广泛应用
deployed for years, and is also needed to route IPv6. Note that SAFI=3 was originally specified for "both unicast and multicast" but has since then been deprecated.
部署多年，路由IPv6也需要它。请注意，SAFI=3最初是为“单播和多播”指定的，但后来被弃用。
These extensions are in widespread use wherever BGP is used to distribute unicast topology information. Multicast-enabled networks that use BGP should use Multiprotocol BGP to distribute multicast reachability information explicitly even if the topologies are congruent to make an explicit statement about multicast reachability. A number of significant multicast transit providers even require this, by doing the RPF lookups solely based on explicitly advertised multicast address family.
在使用BGP分发单播拓扑信息的任何地方，这些扩展都被广泛使用。使用BGP的支持多播的网络应该使用多协议BGP来显式地分发多播可达性信息，即使拓扑是一致的，可以对多播可达性做出显式的声明。许多重要的多播传输提供商甚至要求这样做，只根据显式公布的多播地址族进行RPF查找。
Similar to BGP, some Interior Gateway Protocols (IGPs) also provide the capability for signalling differing topologies, for example IS-IS multi-topology extensions [M-ISIS]. These can be used for a multicast topology that differs from unicast. Similar but not so widely implemented work exists for OSPF [RFC4915].
与BGP类似，一些内部网关协议（IGP）也提供发送不同拓扑的能力，例如IS-IS多拓扑扩展[M-ISIS]。这些可用于不同于单播的多播拓扑。OSPF[RFC4915]也有类似但未广泛实施的工作。
It is worth noting that inter-domain incongruence and intra-domain incongruence are orthogonal, so one doesn't require the other. Specifically, inter-domain incongruence is quite common, while intra-domain incongruence isn't, so you see much more deployment of MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well without protocols handling intra-domain incongruence. However, the availability of multi-topology mechanisms may in part replace the typically used workarounds such as tunnels.
值得注意的是，域间不一致和域内不一致是正交的，因此一个不需要另一个。具体来说，域间不一致非常常见，而域内不一致则不常见，因此您可以看到MBGP的部署比MT-ISIS/OSPF多得多。通常部署的网络管理良好，没有处理域内不一致的协议。然而，多拓扑机制的可用性可能会部分取代通常使用的变通方法，如隧道。
An interesting case occurs when some routers do not distribute multicast topology information explicitly while others do. In particular, this happens when some multicast sites in the Internet are using plain BGP while some use MBGP.
当一些路由器不显式分发多播拓扑信息，而另一些路由器则显式分发多播拓扑信息时，就会出现一个有趣的情况。特别是，当Internet上的一些多播站点使用普通BGP，而一些使用MBGP时，就会发生这种情况。
Different implementations deal with this in different ways. Sometimes, multicast RPF mechanisms first look up the multicast routing table, or M-RIB ("topology database") with a longest prefix match algorithm, and if they find any entry (including a default route), that is used; if no match is found, the unicast routing table is used instead.
不同的实现以不同的方式处理这个问题。有时，多播RPF机制首先使用最长前缀匹配算法查找多播路由表或M-RIB（“拓扑数据库”），如果它们找到任何使用的条目（包括默认路由）；如果未找到匹配项，则改用单播路由表。
An alternative approach is to use longest prefix match on the union of multicast and unicast routing tables; an implementation technique here is to copy the whole unicast routing table over to the multicast routing table. The important point to remember here, though, is to
另一种方法是在多播和单播路由表的并集上使用最长前缀匹配；这里的一种实现技术是将整个单播路由表复制到多播路由表。不过，这里要记住的重要一点是
not override the multicast-only routes; if the longest prefix match would find both a (copied) unicast route and a multicast-only route, the latter should be treated as preferable.
不覆盖仅多播路由；如果最长前缀匹配将同时找到（复制的）单播路由和仅多播路由，则后者应视为首选。
Another implemented approach is to just look up the information in the unicast routing table, and provide the user capabilities to change that as appropriate, using for example copying functions discussed above.
另一种实现的方法是只在单播路由表中查找信息，并提供用户根据需要更改信息的能力，例如使用上面讨论的复制功能。
A congruent topology can be deployed using unicast routing protocols that provide no support for a separate multicast topology. In intra-domain that approach is often adequate. However, it is recommended that if inter-domain routing uses BGP, multicast-enabled sites should use MP-BGP SAFI=2 for multicast and SAFI=1 for unicast even if the topology was congruent to explicitly signal "yes, we use multicast".
一致拓扑可以使用单播路由协议进行部署，单播路由协议不支持单独的多播拓扑。在域内，这种方法通常是足够的。但是，建议如果域间路由使用BGP，则启用多播的站点应使用MP-BGP SAFI=2进行多播，SAFI=1进行单播，即使拓扑一致，以明确表示“是，我们使用多播”。
The following table summarizes the approaches that can be used to distribute multicast topology information.
下表总结了可用于分发多播拓扑信息的方法。
+----------------+--------------+
| Inter-domain | Intra-domain |
+--------------------- +----------------+--------------+
| MP-BGP SAFI=2 | Yes | Yes |
| MP-BGP SAFI=3 | Doesn't work | Doesn't work |
| IS-IS multi-topology | Not applicable | Yes |
| OSPF multi-topology | Not applicable | Few implem. |
+----------------------+----------------+--------------+
+----------------+--------------+
| Inter-domain | Intra-domain |
+--------------------- +----------------+--------------+
| MP-BGP SAFI=2 | Yes | Yes |
| MP-BGP SAFI=3 | Doesn't work | Doesn't work |
| IS-IS multi-topology | Not applicable | Yes |
| OSPF multi-topology | Not applicable | Few implem. |
+----------------------+----------------+--------------+
"Not applicable" refers to the fact that IGP protocols can't be used in inter-domain routing. "Doesn't work" means that while MP-BGP SAFI=3 was defined and could apply, that part of the specification has not been implemented and can't be used in practice. "Yes" lists the mechanisms which are generally applicable and known to work. "Few implem." means that the approach could work but is not commonly available.
“不适用”是指IGP协议不能用于域间路由。“不起作用”意味着虽然定义了MP-BGP SAFI=3并可以应用，但规范的这一部分尚未实现，无法在实践中使用。“是”列出了通常适用且已知有效的机制。“很少implem”意味着该方法可以工作，但并不普遍可用。
To build a multicast distribution tree, the routing protocol needs to find out where the sources for the group are. In case of SSM, the user specifies the source IP address or it is otherwise learned out of band.
要构建多播分发树，路由协议需要找出组的源所在的位置。在SSM的情况下，用户指定源IP地址或以其他方式在带外学习。
In ASM, the RPs know about all the active sources in a local PIM domain. As a result, when PIM-SM or BIDIR-PIM is used in intra-domain the sources are learned as a feature of the protocol itself.
在ASM中，RPs知道本地PIM域中的所有活动源。因此，当PIM-SM或BIDIR-PIM在域内使用时，源作为协议本身的一个特征被学习。
Having a single PIM-SM domain for the whole Internet is an insufficient model for many reasons, including scalability, administrative boundaries, and different technical tradeoffs. Therefore, it is required to be able to split up the multicast routing infrastructures to smaller domains, and there must be a way to share information about active sources using some mechanism if the ASM model is to be supported.
由于许多原因，包括可伸缩性、管理边界和不同的技术权衡，为整个互联网提供一个单一的PIM-SM域是不够的。因此，需要能够将多播路由基础设施拆分为更小的域，并且如果要支持ASM模型，必须有一种方法使用某种机制共享有关活动源的信息。
This section discusses the options of learning active sources that apply in an inter-domain environment.
本节讨论在域间环境中学习活动源的选项。
Source-specific Multicast [RFC4607] (sometimes also referred to as "single-source Multicast") does not count on learning active sources in the network. Recipients need to know the source IP addresses using an out of band mechanism which are used to subscribe to the (source, group) channel. The multicast routing uses the source address to set up the state and no further source discovery is needed.
源特定多播[RFC4607]（有时也称为“单源多播”）不依赖于学习网络中的活动源。收件人需要使用带外机制知道源IP地址，该机制用于订阅（源、组）通道。多播路由使用源地址设置状态，不需要进一步的源发现。
As of this writing, there are attempts to analyze and/or define out-of-band source discovery functions which would help SSM in particular [DYNSSM-REQ].
在撰写本文时，有人试图分析和/或定义带外源发现函数，这将特别有助于SSM[DYNSSM-REQ]。
Multicast Source Discovery Protocol [RFC3618] was invented as a stop-gap mechanism, when it became apparent that multiple PIM-SM domains (and RPs) were needed in the network, and information about the active sources needed to be propagated between the PIM-SM domains using some other protocol.
多播源发现协议[RFC3618]是作为一种权宜之计而发明的，当时网络中显然需要多个PIM-SM域（和RP），并且需要使用一些其他协议在PIM-SM域之间传播有关活动源的信息。
MSDP is also used to share the state about sources between multiple RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The same can be achieved using PIM extensions [RFC4610]. See Section 2.5 for more information.
MSDP还用于在单个域中的多个RP之间共享有关源的状态，例如，出于冗余目的[RFC3446]。使用PIM扩展[RFC4610]也可以实现这一点。更多信息请参见第2.5节。
There is no intent to define MSDP for IPv6, but instead use only SSM and Embedded-RP [MCAST-ISSUES].
我们无意为IPv6定义MSDP，而是只使用SSM和嵌入式RP[MCAST-ISSUES]。
Embedded-RP [RFC3956] is an IPv6-only technique to map the address of the RP to the multicast group address. Using this method, it is possible to avoid the use of MSDP while still allowing multiple multicast domains (in the traditional sense).
嵌入式RP[RFC3956]是一种仅用于IPv6的技术，用于将RP地址映射到多播组地址。使用此方法，可以避免使用MSDP，同时仍然允许多个多播域（传统意义上）。
The model works by defining a single RP address for a particular group for all of the Internet, so there is no need to share state about that with any other RPs. If necessary, RP redundancy can still be achieved with Anycast-RP using PIM [RFC4610].
该模型的工作原理是为整个Internet的特定组定义一个RP地址，因此不需要与任何其他RP共享该地址的状态。如有必要，仍然可以使用PIM[RFC4610]通过Anycast RP实现RP冗余。
The following table summarizes the source discovery approaches and their status.
下表总结了源代码发现方法及其状态。
+------+------+------------------------------+
| IPv4 | IPv6 | Status |
+----------------------+------+------+------------------------------+
| Bidir single domain | Yes | Yes | OK but for intra-domain only |
| PIM-SM single domain | Yes | Yes | OK |
| PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM |
| PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option |
| SSM | Yes | Yes | No major uptake yet |
+----------------------+------+------+------------------------------+
+------+------+------------------------------+
| IPv4 | IPv6 | Status |
+----------------------+------+------+------------------------------+
| Bidir single domain | Yes | Yes | OK but for intra-domain only |
| PIM-SM single domain | Yes | Yes | OK |
| PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM |
| PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option |
| SSM | Yes | Yes | No major uptake yet |
+----------------------+------+------+------------------------------+
PIM-SM and BIDIR-PIM configuration mechanisms exist, which are used to configure the RP addresses and the groups that are to use those RPs in the routers. This section outlines the approaches.
存在PIM-SM和BIDIR-PIM配置机制，用于配置路由器中使用这些RP的RP地址和组。本节概述了这些方法。
It is often easiest just to manually configure the RP information on the routers when PIM-SM is used.
当使用PIM-SM时，通常只需在路由器上手动配置RP信息是最简单的。
Originally, static RP mapping was considered suboptimal since it required explicit configuration changes every time the RP address changed. However, with the advent of anycast RP addressing, the RP address is unlikely to ever change. Therefore, the administrative burden is generally limited to initial configuration. Since there is usually a fair amount of multicast configuration required on all routers anyway (e.g., PIM on all interfaces), adding the RP address statically isn't really an issue. Further, static anycast RP mapping provides the benefits of RP load sharing and redundancy (see Section 2.5) without the complexity found in dynamic mechanisms like Auto-RP and Bootstrap Router (BSR).
最初，静态RP映射被认为是次优的，因为每次RP地址更改时都需要显式的配置更改。然而，随着任意广播RP地址的出现，RP地址不太可能改变。因此，管理负担通常仅限于初始配置。由于所有路由器上通常都需要相当数量的多播配置（例如，所有接口上的PIM），因此静态添加RP地址并不是一个真正的问题。此外，静态选播RP映射提供了RP负载共享和冗余的好处（见第2.5节），而不存在自动RP和引导路由器（BSR）等动态机制中的复杂性。
With such design, an anycast RP uses an address that is configured on a loopback interface of the routers currently acting as RPs, and state is distributed using PIM [RFC4610] or MSDP [RFC3446].
通过这种设计，选播RP使用在当前充当RP的路由器的环回接口上配置的地址，并且使用PIM[RFC4610]或MSDP[RFC3446]分布状态。
Using this technique, each router might only need to be configured with one, portable RP address.
使用这种技术，每个路由器可能只需要配置一个可移植的RP地址。
Embedded-RP provides the information about the RP's address in the group addresses that are delegated to those who use the RP, so unless no other ASM than Embedded-RP is used, the network administrator only needs to configure the RP routers.
嵌入式RP在委派给使用RP的人的组地址中提供有关RP地址的信息，因此，除非使用嵌入式RP以外的ASM，否则网络管理员只需配置RP路由器。
While Embedded-RP in many cases is sufficient for IPv6, other methods of RP configuration are needed if one needs to provide ASM service for other than Embedded-RP group addresses. In particular, service discovery type of applications may need hard-coded addresses that are not dependent on local RP addresses.
虽然嵌入式RP在许多情况下足以用于IPv6，但如果需要为嵌入式RP组地址以外的地址提供ASM服务，则需要其他RP配置方法。特别是，服务发现类型的应用程序可能需要不依赖于本地RP地址的硬编码地址。
As the RP's address is exposed to the users and applications, it is very important to ensure it does not change often, e.g., by using manual configuration of an anycast address.
由于RP的地址向用户和应用程序公开，因此确保其不会经常更改非常重要，例如，通过使用选播地址的手动配置。
BSR [RFC5059] is a mechanism for configuring the RP address for groups. It may no longer be in as wide use with IPv4 as it was earlier, and for IPv6, Embedded-RP will in many cases be sufficient.
BSR[RFC5059]是一种为组配置RP地址的机制。它可能不再像以前那样在IPv4中广泛使用，而对于IPv6，嵌入式RP在许多情况下就足够了。
Cisco's Auto-RP is an older, proprietary method for distributing group to RP mappings, similar to BSR. Auto-RP has little use today.
Cisco的Auto RP是一种较旧的专有方法，用于分发组到RP的映射，类似于BSR。自动RP在今天几乎没有什么用处。
Both Auto-RP and BSR require some form of control at the routers to ensure that only valid routers are able to advertise themselves as RPs. Further, flooding of BSR and Auto-RP messages must be prevented at PIM borders. Additionally, routers require monitoring that they are actually using the RP(s) the administrators think they should be using, for example, if a router (maybe in customer's control) is advertising itself inappropriately. All in all, while BSR and Auto-RP provide easy configuration, they also provide very significant configuration and management complexity.
自动RP和BSR都需要在路由器上进行某种形式的控制，以确保只有有效的路由器才能将自己作为RPs进行宣传。此外，必须在PIM边界防止BSR和自动RP消息泛滥。此外，路由器需要监控它们是否实际使用了管理员认为它们应该使用的RP，例如，如果路由器（可能在客户控制下）不适当地宣传自己。总而言之，虽然BSR和Auto RP提供了简单的配置，但它们也提供了非常重要的配置和管理复杂性。
It is worth noting that both Auto-RP and BSR were deployed before the use of a manually configured anycast-RP address became relatively commonplace, and there is actually relatively little need for them today unless there is a need to configure different properties (e.g., sparse, dense, bidirectional) in a dynamic fashion.
值得注意的是，Auto RP和BSR都是在使用手动配置的选播RP地址变得相对普遍之前部署的，并且今天实际上对它们的需求相对较少，除非需要以动态方式配置不同的属性（例如，稀疏、密集、双向）。
The following table summarizes the RP discovery mechanisms and their status. With the exception of Embedded-RP, each mechanism operates within a PIM domain.
下表总结了RP发现机制及其状态。除了嵌入式RP，每个机制都在PIM域内运行。
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Static RP | Yes | Yes | Especially in ISPs |
| Auto-RP | Yes | No | Legacy deployment |
| BSR | Yes | Yes | Some, anycast simpler |
| Embedded-RP | No | Yes | Growing |
+--------------------+------+------+-----------------------+
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Static RP | Yes | Yes | Especially in ISPs |
| Auto-RP | Yes | No | Legacy deployment |
| BSR | Yes | Yes | Some, anycast simpler |
| Embedded-RP | No | Yes | Growing |
+--------------------+------+------+-----------------------+
Having only one RP in a PIM-SM domain would be a single point of failure for the whole multicast domain. As a result, a number of mechanisms have been developed to either eliminate the RP functionality or to enhance RPs' redundancy, resilience against failures, and to recover from failures quickly. This section summarizes these techniques explicitly.
在PIM-SM域中只有一个RP将是整个多播域的单点故障。因此，已经开发了许多机制来消除RP功能或增强RPs的冗余性、故障恢复能力以及快速从故障中恢复。本节明确总结了这些技术。
As mentioned in Section 2.3.2, MSDP is also used to share the state about sources between multiple RPs in a single domain, e.g., for redundancy purposes [RFC3446]. The purpose of MSDP in this context is to share the same state information on multiple RPs for the same groups to enhance the robustness of the service.
如第2.3.2节所述，MSDP还用于在单个域中的多个RP之间共享有关源的状态，例如，出于冗余目的[RFC3446]。在此上下文中，MSDP的目的是为相同的组共享多个RP上的相同状态信息，以增强服务的健壮性。
Recent PIM extensions [RFC4610] also provide this functionality. In contrast to MSDP, this approach works for both IPv4 and IPv6.
最近的PIM扩展[RFC4610]也提供了此功能。与MSDP不同，这种方法适用于IPv4和IPv6。
While Anycast RP shares state between RPs so that RP failure causes only small disturbance, stateless approaches are also possible with a more limited resiliency. A traditional mechanism has been to use Auto-RP or BSR (see Section 2.4.3) to select another RP when the active one failed. However, the same functionality could be achieved using a shared-unicast RP address ("anycast RP without state sharing") without the complexity of a dynamic mechanism. Further, Anycast RP offers a significantly more extensive failure mitigation strategy, so today there is actually very little need to use stateless failover mechanisms, especially dynamic ones, for redundancy purposes.
虽然Anycast RP在RPs之间共享状态，因此RP故障只会造成较小的干扰，但无状态方法也可能具有更有限的恢复能力。传统的机制是，当激活的RP失效时，使用自动RP或BSR（见第2.4.3节）选择另一个RP。然而，使用共享单播RP地址（“无状态共享的选播RP”）可以实现相同的功能，而不需要复杂的动态机制。此外，Anycast RP提供了一种更广泛的故障缓解策略，因此今天实际上几乎不需要为了冗余目的使用无状态故障切换机制，尤其是动态故障切换机制。
Because bidirectional PIM (see Section 2.1.3) does not switch to shortest path tree (SPT), the final multicast tree may be established faster. On the other hand, PIM-SM or SSM may converge more quickly especially in scenarios (e.g., unicast routing change) where bidirectional needs to re-do the Designated Forwarder election.
由于双向PIM（见第2.1.3节）不会切换到最短路径树（SPT），因此最终的多播树可能会更快地建立。另一方面，PIM-SM或SSM可能会更快地收敛，尤其是在双向需要重新进行指定转发器选择的场景中（例如，单播路由改变）。
The following table summarizes the techniques for enhanced redundancy.
下表总结了增强冗余的技术。
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Anycast RP w/ MSDP | Yes | No | De-facto approach |
| Anycast RP w/ PIM | Yes | Yes | Newer approach |
| Stateless RP fail. | Yes | Yes | Causes disturbance |
| BIDIR-PIM | Yes | Yes | Deployed at some sites|
+--------------------+------+------------------------------+
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Anycast RP w/ MSDP | Yes | No | De-facto approach |
| Anycast RP w/ PIM | Yes | Yes | Newer approach |
| Stateless RP fail. | Yes | Yes | Causes disturbance |
| BIDIR-PIM | Yes | Yes | Deployed at some sites|
+--------------------+------+------------------------------+
Previous sections have dealt with the components required by routers to be able to do multicast routing. Obviously, the real users of multicast are the hosts: either sending or receiving multicast. This section describes the required interactions with hosts.
前几节讨论了路由器能够进行多播路由所需的组件。显然，组播的真正用户是主机：发送或接收组播。本节描述了与主机的必要交互。
After choosing a multicast group through a variety of means, hosts just send the packets to the link-layer multicast address, and the designated router will receive all the multicast packets and start forwarding them as appropriate. A host does not need to be a member of the group in order to send to it [RFC1112].
在通过各种方式选择组播组后，主机只需将数据包发送到链路层组播地址，指定的路由器就会接收到所有的组播数据包，并根据需要开始转发。主机不需要是组的成员才能向其发送[RFC1112]。
In intra-domain or Embedded-RP scenarios, ASM senders may move to a new IP address without significant impact on the delivery of their transmission. SSM senders cannot change the IP address unless receivers join the new channel or the sender uses an IP mobility technique that is transparent to the receivers.
在域内或嵌入式RP场景中，ASM发送方可能会移动到新的IP地址，而不会对其传输的交付产生重大影响。SSM发送方无法更改IP地址，除非接收方加入新信道，或者发送方使用对接收方透明的IP移动技术。
Hosts signal their interest in receiving a multicast group or channel by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are still commonplace, but are also often used in new deployments. Some
主机通过使用IGMP[RFC3376]和MLD[RFC3810]来表示其对接收多播组或信道的兴趣。IGMPv2和MLDv1仍然很常见，但也经常用于新的部署。一些
vendors also support SSM mapping techniques for receivers which use an older IGMP/MLD version where the router maps the join request to an SSM channel based on various, usually complex means of configuration.
供应商还为使用较旧IGMP/MLD版本的接收机支持SSM映射技术，其中路由器基于各种通常复杂的配置方式将加入请求映射到SSM信道。
The following table summarizes the techniques host interaction.
下表总结了主机交互技术。
+-------+------+----------------------------+
| IPv4 | IPv6 | Notes |
+--------------------+-------+------+----------------------------+
| Host sending | Yes | Yes | No support needed |
| Host receiving ASM | IGMP | MLD | Any IGMP/MLD version |
| Host receiving SSM | IGMPv3| MLDv2| Any version w/ SSM-mapping |
+--------------------+-------+------+----------------------------+
+-------+------+----------------------------+
| IPv4 | IPv6 | Notes |
+--------------------+-------+------+----------------------------+
| Host sending | Yes | Yes | No support needed |
| Host receiving ASM | IGMP | MLD | Any IGMP/MLD version |
| Host receiving SSM | IGMPv3| MLDv2| Any version w/ SSM-mapping |
+--------------------+-------+------+----------------------------+
Multicast transmission in the link layer, for example Ethernet, typically includes some form of flooding the packets through a LAN. This causes unnecessary bandwidth usage and discarding unwanted frames on those nodes which did not want to receive the multicast transmission.
链路层（例如以太网）中的多播传输通常包括某种形式的通过LAN泛洪数据包。这会导致不必要的带宽使用，并在那些不希望接收多播传输的节点上丢弃不需要的帧。
Therefore a number of techniques have been developed, to be used in Ethernet switches between routers, or between routers and hosts, to limit the flooding.
因此，已经开发了许多技术，用于路由器之间或路由器与主机之间的以太网交换机，以限制泛洪。
Some mechanisms operate with IP addresses, others with MAC addresses. If filtering is done based on MAC addresses, hosts may receive unnecessary multicast traffic (filtered out in the hosts' IP layer) if more than one IP multicast group addresses maps into the same MAC address, or if IGMPv3/MLDv2 source filters are used. Filtering based on IP destination addresses, or destination and sources addresses, will help avoid these but requires parsing of the Ethernet frame payload.
一些机制使用IP地址，其他机制使用MAC地址。如果根据MAC地址进行过滤，则如果多个IP多播组地址映射到同一MAC地址，或者如果使用IGMPv3/MLDv2源过滤器，主机可能会收到不必要的多播流量（在主机的IP层中过滤掉）。基于IP目标地址或目标和源地址的过滤将有助于避免这些问题，但需要对以太网帧有效负载进行解析。
These options are discussed in this section.
本节将讨论这些选项。
A proprietary solution, Cisco's RGMP [RFC3488] has been developed to reduce the amount of flooding between routers in a switched networks. This is typically only considered a problem in some Ethernet-based Internet Exchange points or VPNs.
Cisco的RGMP[RFC3488]是一种专有解决方案，旨在减少交换网络中路由器之间的洪泛量。这通常仅在一些基于以太网的Internet交换点或VPN中被视为问题。
There have been proposals to observe and possibly react ("snoop") PIM messages [PIM-SNOOP].
有人建议观察并可能作出反应（“窥探”）PIM消息[PIM-snoop]。
There are a number of techniques to help reduce flooding both from a router to hosts, and from a host to the routers (and other hosts).
有许多技术可以帮助减少从路由器到主机以及从主机到路由器（和其他主机）的洪泛。
Cisco's proprietary CGMP [CGMP] provides a solution where the routers notify the switches, but also allows the switches to snoop IGMP packets to enable faster notification of hosts no longer wishing to receive a group. Implementations of CGMP do not support fast leave behaviour with IGMPv3. Due to IGMP report suppression in IGMPv1 and IGMPv2, multicast is still flooded to ports which were once members of a group as long as there is at least one receiver on the link. Flooding restrictions are done based on multicast MAC addresses. Implementations of CGMP do not support IPv6.
Cisco专有的CGMP[CGMP]提供了一种解决方案，路由器在其中通知交换机，但也允许交换机嗅探IGMP数据包，以便更快地通知不再希望接收组的主机。CGMP的实现不支持IGMPv3的快速离开行为。由于IGMPv1和IGMPv2中的IGMP报告抑制，只要链路上至少有一个接收器，多播仍然被淹没到曾经是组成员的端口。泛洪限制基于多播MAC地址进行。CGMP的实现不支持IPv6。
IEEE 802.1D-2004 specification describes Generic Attribute Registration Protocol (GARP), and GARP Multicast Registration Protocol (GMRP) [GMRP] is a link-layer multicast group application of GARP that notifies switches about MAC multicast group memberships. If GMRP is used in conjunction with IP multicast, then the GMRP registration function would become associated with an IGMP "join". However, this GMRP-IGMP association is beyond the scope of GMRP. GMRP requires support at the host stack and it has not been widely implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete being replaced by Multiple Registration Protocol (MRP) and Multicast Multiple Registration Protocol (MMRP) that are being specified in IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between bridges. Some further information about GARP/GMRP is also available in Appendix B of [RFC3488].
IEEE 802.1D-2004规范描述了通用属性注册协议（GARP），GARP多播注册协议（GMRP）[GMRP]是GARP的链路层多播组应用程序，用于通知交换机MAC多播组成员身份。如果GMRP与IP多播结合使用，则GMRP注册功能将与IGMP“连接”关联。然而，这种GMRP-IGMP相关性超出了GMRP的范围。GMRP需要主机堆栈的支持，但尚未得到广泛实施。此外，IEEE 802.1认为GARP和GMRP已被IEEE 802.1ak[802.1ak]中规定的多重注册协议（MRP）和多播多重注册协议（MMRP）所取代。MMRP预计主要用于桥梁之间。[RFC3488]附录B中还提供了有关GARP/GMRP的更多信息。
IGMP snooping [RFC4541] appears to be the most widely implemented technique. IGMP snooping requires that the switches implement a significant amount of IP-level packet inspection; this appears to be something that is difficult to get right, and often the upgrades are also a challenge. Snooping support is commonplace for IGMPv1 and IGMPv2, but fewer switches support IGMPv3 or MLD (any version) snooping. In the worst case, enabling IGMP snooping on a switch that does not support IGMPv3 snooping breaks multicast capabilities of nodes using IGMPv3.
IGMP监听[RFC4541]似乎是应用最广泛的技术。IGMP侦听要求交换机执行大量IP级别的数据包检查；这似乎是很难做到的，而且升级通常也是一个挑战。对IGMPv1和IGMPv2的监听支持很常见，但支持IGMPv3或MLD（任何版本）监听的交换机较少。在最坏的情况下，在不支持IGMPv3侦听的交换机上启用IGMP侦听会中断使用IGMPv3的节点的多播功能。
Snooping switches also need to identify the ports where routers reside and therefore where to flood the packets. This can be accomplished using Multicast Router Discovery protocol [RFC4286], looking at certain IGMP queries [RFC4541], looking at PIM Hello and possibly other messages, or by manual configuration. An issue with
窥探交换机还需要识别路由器所在的端口，从而确定数据包的泛滥位置。这可以通过使用多播路由器发现协议[RFC4286]、查看某些IGMP查询[RFC4541]、查看PIM Hello和可能的其他消息，或者通过手动配置来实现。问题
PIM snooping at LANs is that PIM messages can't be turned off or encrypted, leading to security issues [PIM-THREATS].
局域网上的PIM窥探是指无法关闭或加密PIM消息，从而导致安全问题[PIM-THREATS]。
IGMP proxying [RFC4605] is sometimes used either as a replacement of a multicast routing protocol on a small router, or to aggregate IGMP/ MLD reports when used with IGMP snooping.
IGMP代理[RFC4605]有时用于替代小型路由器上的多播路由协议，或者在与IGMP侦听一起使用时用于聚合IGMP/MLD报告。
The following table summarizes the techniques for multicast flooding reduction inside a single link for router-to-router and last-hop LANs.
下表总结了路由器到路由器和最后一跳LAN在单个链路内减少多播泛洪的技术。
+--------+-----+----------------------------+
| R-to-R | LAN | Notes |
+-----------------------+--------+-----+----------------------------+
| Cisco's RGMP | Yes | No | Replaced by PIM snooping |
| PIM snooping | Yes | No | Security issues in LANs |
| IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD rare |
| Multicast Router Disc | No | Yes | Few if any implem. yet |
| IEEE GMRP and MMRP | No | No | No host/router deployment |
| Cisco's CGMP | No | Yes | Replaced by other snooping |
+-----------------------+--------+-----+----------------------------+
+--------+-----+----------------------------+
| R-to-R | LAN | Notes |
+-----------------------+--------+-----+----------------------------+
| Cisco's RGMP | Yes | No | Replaced by PIM snooping |
| PIM snooping | Yes | No | Security issues in LANs |
| IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD rare |
| Multicast Router Disc | No | Yes | Few if any implem. yet |
| IEEE GMRP and MMRP | No | No | No host/router deployment |
| Cisco's CGMP | No | Yes | Replaced by other snooping |
+-----------------------+--------+-----+----------------------------+
Tutoring a couple multicast-related papers, the latest by Kaarle Ritvanen [RITVANEN] convinced the author that up-to-date multicast routing and address assignment/allocation documentation is necessary.
Kaarle Ritvanen[Ritvanen]的最新一篇文章指导了几篇与多播相关的论文，使作者确信最新的多播路由和地址分配/分配文档是必要的。
Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica, Prashant Jhingran, and Tim Polk provided good comments, helping in improving this document.
伦纳德·朱利亚诺、詹姆斯·林加德、让·雅克·潘西奥特、戴夫·迈耶、斯蒂格·维纳斯、汤姆·普萨特里、马歇尔·尤班克斯、迪诺·法里纳奇、巴拉特·乔希、阿尔伯特·曼弗雷迪、让·雅克·潘西奥特、斯宾塞·道金斯、沙龙·奇肖姆、约翰·兹维贝尔、丹·罗马斯库、托马斯·莫林、罗恩·博尼卡、普拉尚·杰金兰和蒂姆·波尔克发表了很好的评论，帮助改进此文档。
IANA has updated the following registries by adding a reference to this document:
IANA通过添加对本文件的引用更新了以下注册：
o OSPFv2 Options Registry: MC-bit
o OSPFv2选项注册表：MC位
o OSPFv2 Link State (LS) Type: Group-membership-LSA
o OSPFv2链路状态（LS）类型：组成员身份LSA
o OSPFv2 Router Properties Registry: W-bit
o OSPFv2路由器属性注册表：W位
o OSPFv3 Options Registry: MC-bit
o OSPFv3选项注册表：MC位
o OSPFv3 LSA Function Code Registry: Group-membership-LSA
o OSPFv3 LSA功能代码注册表：组成员资格LSA
o OSPFv3 Prefix Options Registry: MC-bit
o OSPFv3前缀选项注册表：MC位
This memo only describes different approaches to multicast routing, and this has no security considerations; the security analysis of the mentioned protocols is out of scope of this memo.
本备忘录仅描述了多播路由的不同方法，没有安全考虑；上述协议的安全性分析超出本备忘录的范围。
However, there has been analysis of the security of multicast routing infrastructures [RFC4609], IGMP/MLD [MLD-SEC], and PIM last-hop issues [PIM-THREATS].
然而，对多播路由基础设施[RFC4609]、IGMP/MLD[MLD-SEC]和PIM最后一跳问题[PIM-THREATS]的安全性进行了分析。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Fenner，B.和D.Meyer，“多播源发现协议（MSDP）”，RFC3618，2003年10月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 3956，2004年11月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[RFC4915]Psenak，P.，Mirtorabi，S.，Roy，A.，Nguyen，L.，和P.Pillay Esnault，“OSPF中的多拓扑（MT）路由”，RFC 4915，2007年6月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[802.1ak] "IEEE 802.1ak - Multiple Registration Protocol", <http://www.ieee802.org/1/pages/802.1ak.html>.
[802.1ak]“IEEE 802.1ak-多重注册协议”<http://www.ieee802.org/1/pages/802.1ak.html>.
[ADDRARCH] Savola, P., "Overview of the Internet Multicast Addressing Architecture", Work in Progress, October 2006.
[ADDRARCH]Savola，P.，“互联网多播寻址体系结构概述”，进展中的工作，2006年10月。
[CGMP] "Cisco Group Management Protocol", <http://www.javvin.com/protocolCGMP.html>.
[CGMP]“思科集团管理协议”<http://www.javvin.com/protocolCGMP.html>.
[DVMRPv3] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress, December 2003.
[DVMRPv3]Pusateri，T.，“距离向量多播路由协议”，正在进行的工作，2003年12月。
[DVMRPv3-AS] Pusateri, T., "Distance Vector Multicast Routing Protocol Applicability Statement", Work in Progress, May 2004.
[DVMRPv3 AS]Pusateri，T.，“距离向量多播路由协议适用性声明”，正在进行的工作，2004年5月。
[DYNSSM-REQ] Lehtonen, R., Venaas, S., and M. Hoerdt, "Requirements for discovery of dynamic SSM sources", Work in Progress, February 2005.
[DYNSSM-REQ]Lehtonen，R.，Venaas，S.，和M.Hoerdt，“发现动态SSM源的要求”，正在进行的工作，2005年2月。
[GMRP] "GARP Multicast Registration Protocol", <http://www.javvin.com/protocolGMRP.html>.
[GMRP]“GARP多播注册协议”<http://www.javvin.com/protocolGMRP.html>.
[IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap Analysis from the MBONED Working Group for the IESG [Expired]", Work in Progress, July 2002.
[IM-GAPS]Meyer，D.和B.Nickless，“IESG的MBOED工作组的互联网多播差距分析[Expired]”，正在进行的工作，2002年7月。
[IMRP-ISSUES] Meyer, D., "Some Issues for an Inter-domain Multicast Routing Protocol", Work in Progress, November 1997.
[IMRP-ISSUES]Meyer，D.，“域间多播路由协议的一些问题”，正在进行的工作，1997年11月。
[M-ISIS] Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in IS-IS", Work in Progress, November 2007.
[M-ISIS]Przygienda，T.，“M-ISIS:IS-IS中的多拓扑（MT）路由”，正在进行的工作，2007年11月。
[MCAST-ISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work in Progress, February 2005.
[MCAST-ISSUES]Savola，P.，“IPv6多播部署问题”，正在进行的工作，2005年2月。
[MLD-SEC] Daley, G. and G. Kurup, "Trust Models and Security in Multicast Listener Discovery", Work in Progress, July 2004.
[MLD-SEC]Daley，G.和G.Kurup，“多播侦听器发现中的信任模型和安全”，正在进行的工作，2004年7月。
[PIM-SNOOP] Hemige, V., "PIM Snooping over VPLS", Work in Progress, March 2007.
[PIM-SNOOP]Hemige，V.，“PIM对VPL的窥探”，正在进行的工作，2007年3月。
[PIM-THREATS] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", Work in Progress, October 2007.
[PIM-THREATS]Savola，P.和J.Lingard，“协议独立多播（PIM）的主机威胁”，正在进行的工作，2007年10月。
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[RFC1075]Waitzman，D.，Partridge，C.，和S.Deering，“距离向量多播路由协议”，RFC 1075，1988年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993.
[RFC1458]Braudes，B.和S.Zabele，“多播协议的要求”，RFC 1458，1993年5月。
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[RFC1584]Moy，J.，“OSPF的多播扩展”，RFC1584，1994年3月。
[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --", RFC 2189, September 1997.
[RFC2189]Ballardie，T.，“基于核心的树（CBT版本2）多播路由——协议规范——”，RFC2189，1997年9月。
[RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[RFC2201]Ballardie，T.，“基于核心的树（CBT）多播路由架构”，RFC2201，1997年9月。
[RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
[RFC2715]Thaler，D.，“多播路由协议的互操作性规则”，RFC 27151999年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, December 2001.
[RFC3208]Speakman，T.，Crowcroft，J.，Gemmell，J.，Farinaci，D.，Lin，S.，Leshchiner，D.，Luby，M.，Montgomery，T.，Rizzo，L.，Tweedy，A.，Bhaskar，N.，Edmonstone，R.，Sumanasekera，R.，和L.Vicisano，“PGM可靠传输协议规范”，RFC 32082001年12月。
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003.
[RFC3446]Kim，D.，Meyer，D.，Kilmer，H.，和D.Farinaci，“使用协议独立多播（PIM）和多播源发现协议（MSDP）的任意广播呈现点（RP）机制”，RFC 3446，2003年1月。
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3488]Wu，I.和T.Eckert，“思科系统路由器端口组管理协议（RGMP）”，RFC 3488，2003年2月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740]Hardjono，T.和B.Weis，“多播组安全架构”，RFC 3740，2004年3月。
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): Protocol Specification", RFC 3913, September 2004.
[RFC3913]Thaler，D.，“边界网关多播协议（BGMP）：协议规范”，RFC 3913，2004年9月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，2005年1月。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286]Haberman，B.和J.Martin，“多播路由器发现”，RFC 4286，2005年12月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541]Christensen，M.，Kimball，K.，和F.Solensky，“互联网组管理协议（IGMP）和多播侦听器发现（MLD）窥探交换机的注意事项”，RFC 4541，2006年5月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4605]Fenner，B.，He，H.，Haberman，B.，和H.Sandick，“基于Internet组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）”，RFC 4605，2006年8月。
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006.
[RFC4609]Savola，P.，Lehtonen，R.，和D.Meyer，“协议独立多播-稀疏模式（PIM-SM）多播路由安全问题和增强”，RFC 4609，2006年10月。
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006.
[RFC4610]Farinaci，D.和Y.Cai，“使用协议独立多播（PIM）的任意广播RP”，RFC 46102006年8月。
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008.
[RFC5059]Bhaskar，N.，Gall，A.，Lingard，J.，和S.Venaas，“用于协议独立多播（PIM）的引导路由器（BSR）机制”，RFC 5059，2008年1月。
[RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT Report, Seminar on Internetworking, May 2004, <http://www.tml.hut.fi/Studies/T-110.551/2004/ papers/>.
[RITVANEN]RITVANEN，K.，“多播路由和寻址”，HUT报告，互联网研讨会，2004年5月<http://www.tml.hut.fi/Studies/T-110.551/2004/ 论文/>。
A couple of mechanisms have been specified to improve the characteristics of the data that can be transported over multicast.
已经指定了两种机制来改善可以通过多播传输的数据的特性。
We describe those mechanisms that have impact on the multicast routing infrastructure, e.g., require or specify router assistance or involvement in some form. Purely end-to-end or host-based protocols are out of scope.
我们描述了那些对多播路由基础设施有影响的机制，例如，要求或指定路由器以某种形式提供协助或参与。纯粹的端到端或基于主机的协议已超出范围。
There has been some work on reliable multicast delivery so that applications with reliability requirements could use multicast instead of simple unreliable UDP.
已经有一些关于可靠多播交付的工作，因此具有可靠性要求的应用程序可以使用多播而不是简单的不可靠UDP。
Most of the mechanisms are host-based and as such out of scope of this document, but one relevant from multicast routing perspective is Pragmatic Generic Multicast (PGM) [RFC3208]. It does not require support from the routers, bur PGM-aware routers may act in router assistance role in the initial delivery and potential retransmission of missing data.
大多数机制都是基于主机的，因此超出了本文的范围，但从多播路由的角度来看，一个相关的机制是实用通用多播（PGM）[RFC3208]。它不需要路由器的支持，bur PGM感知路由器可在丢失数据的初始传送和潜在重传中充当路由器协助角色。
Multicast Security Working Group has been working on methods how the integrity, confidentiality, and authentication of data sent to multicast groups can be ensured using cryptographic techniques [RFC3740].
多播安全工作组一直在研究如何使用加密技术确保发送到多播组的数据的完整性、机密性和身份验证的方法[RFC3740]。
Author's Address
作者地址
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
Pekka Savola CSC-科学计算有限公司，芬兰埃斯波
EMail: psavola@funet.fi
EMail: psavola@funet.fi
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.