Internet Engineering Task Force (IETF) P. Tarapore, Ed.
Request for Comments: 8313 R. Sayko
BCP: 213 AT&T
Category: Best Current Practice G. Shepherd
ISSN: 2070-1721 Cisco
T. Eckert, Ed.
Huawei
R. Krishnan
SupportVectors
January 2018
Internet Engineering Task Force (IETF) P. Tarapore, Ed.
Request for Comments: 8313 R. Sayko
BCP: 213 AT&T
Category: Best Current Practice G. Shepherd
ISSN: 2070-1721 Cisco
T. Eckert, Ed.
Huawei
R. Krishnan
SupportVectors
January 2018
Use of Multicast across Inter-domain Peering Points
跨域间对等点使用多播
Abstract
摘要
This document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process.
本文档研究在指定的一组部署场景中跨域间对等点使用源特定多播（SSM）。目标是：（1）描述这些场景中跨管理域的基于多播的交付的设置过程；（2）记录支持此过程的功能。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8313.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8313.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Overview of Inter-domain Multicast Application Transport ........6
3. Inter-domain Peering Point Requirements for Multicast ...........7
3.1. Native Multicast ...........................................8
3.2. Peering Point Enabled with GRE Tunnel .....................10
3.3. Peering Point Enabled with AMT - Both Domains
Multicast Enabled .........................................12
3.4. Peering Point Enabled with AMT - AD-2 Not
Multicast Enabled .........................................14
3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels
through AD-2 ..............................................16
4. Functional Guidelines ..........................................18
4.1. Network Interconnection Transport Guidelines ..............18
4.1.1. Bandwidth Management ...............................19
4.2. Routing Aspects and Related Guidelines ....................20
4.2.1. Native Multicast Routing Aspects ...................21
4.2.2. GRE Tunnel over Interconnecting Peering Point ......22
4.2.3. Routing Aspects with AMT Tunnels ...................22
4.2.4. Public Peering Routing Aspects .....................24
4.3. Back-Office Functions - Provisioning and Logging
Guidelines ................................................26
4.3.1. Provisioning Guidelines ............................26
4.3.2. Inter-domain Authentication Guidelines .............28
4.3.3. Log-Management Guidelines ..........................28
4.4. Operations - Service Performance and Monitoring
Guidelines ................................................30
4.5. Client Reliability Models / Service Assurance Guidelines ..32
4.6. Application Accounting Guidelines .........................32
5. Troubleshooting and Diagnostics ................................32
6. Security Considerations ........................................33
6.1. DoS Attacks (against State and Bandwidth) .................33
6.2. Content Security ..........................................35
6.3. Peering Encryption ........................................37
6.4. Operational Aspects .......................................37
7. Privacy Considerations .........................................39
8. IANA Considerations ............................................40
9. References .....................................................40
9.1. Normative References ......................................40
9.2. Informative References ....................................42
Acknowledgments ...................................................43
Authors' Addresses ................................................44
1. Introduction ....................................................4
2. Overview of Inter-domain Multicast Application Transport ........6
3. Inter-domain Peering Point Requirements for Multicast ...........7
3.1. Native Multicast ...........................................8
3.2. Peering Point Enabled with GRE Tunnel .....................10
3.3. Peering Point Enabled with AMT - Both Domains
Multicast Enabled .........................................12
3.4. Peering Point Enabled with AMT - AD-2 Not
Multicast Enabled .........................................14
3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels
through AD-2 ..............................................16
4. Functional Guidelines ..........................................18
4.1. Network Interconnection Transport Guidelines ..............18
4.1.1. Bandwidth Management ...............................19
4.2. Routing Aspects and Related Guidelines ....................20
4.2.1. Native Multicast Routing Aspects ...................21
4.2.2. GRE Tunnel over Interconnecting Peering Point ......22
4.2.3. Routing Aspects with AMT Tunnels ...................22
4.2.4. Public Peering Routing Aspects .....................24
4.3. Back-Office Functions - Provisioning and Logging
Guidelines ................................................26
4.3.1. Provisioning Guidelines ............................26
4.3.2. Inter-domain Authentication Guidelines .............28
4.3.3. Log-Management Guidelines ..........................28
4.4. Operations - Service Performance and Monitoring
Guidelines ................................................30
4.5. Client Reliability Models / Service Assurance Guidelines ..32
4.6. Application Accounting Guidelines .........................32
5. Troubleshooting and Diagnostics ................................32
6. Security Considerations ........................................33
6.1. DoS Attacks (against State and Bandwidth) .................33
6.2. Content Security ..........................................35
6.3. Peering Encryption ........................................37
6.4. Operational Aspects .......................................37
7. Privacy Considerations .........................................39
8. IANA Considerations ............................................40
9. References .....................................................40
9.1. Normative References ......................................40
9.2. Informative References ....................................42
Acknowledgments ...................................................43
Authors' Addresses ................................................44
Content and data from several types of applications (e.g., live video streaming, software downloads) are well suited for delivery via multicast means. The use of multicast for delivering such content or other data offers significant savings in terms of utilization of resources in any given administrative domain. End User (EU) demand for such content or other data is growing. Often, this requires transporting the content or other data across administrative domains via inter-domain peering points.
来自多种类型应用程序（例如，实时视频流、软件下载）的内容和数据非常适合通过多播方式交付。使用多播传送此类内容或其他数据在任何给定管理域中的资源利用率方面提供了显著的节约。最终用户（EU）对此类内容或其他数据的需求正在增长。通常，这需要通过域间对等点跨管理域传输内容或其他数据。
The objectives of this document are twofold:
本文件的目标有两个：
o Describe the technical process and establish guidelines for setting up multicast-based delivery of application content or other data across inter-domain peering points via a set of use cases (where "Use Case 3.1" corresponds to Section 3.1, "Use Case 3.2" corresponds to Section 3.2, etc.).
o 描述通过一组用例（其中“用例3.1”对应于第3.1节，“用例3.2”对应于第3.2节等）跨域间对等点设置基于多播的应用程序内容或其他数据交付的技术过程并制定指导方针。
o Catalog all required exchanges of information between the administrative domains to support multicast-based delivery. This enables operators to initiate necessary processes to support inter-domain peering with multicast.
o 编目管理域之间所有必需的信息交换，以支持基于多播的交付。这使运营商能够启动必要的进程，以支持域间多播对等。
The scope and assumptions for this document are as follows:
本文件的范围和假设如下：
o Administrative Domain 1 (AD-1) sources content to one or more EUs in one or more Administrative Domain 2 (AD-2) entities. AD-1 and AD-2 want to use IP multicast to allow support for large and growing EU populations, with a minimum amount of duplicated traffic to send across network links.
o 管理域1（AD-1）向一个或多个管理域2（AD-2）实体中的一个或多个EU发送内容。AD-1和AD-2希望使用IP多播来支持大量且不断增长的欧盟人口，并通过网络链路发送最小数量的重复流量。
* This document does not detail the case where EUs are originating content. To support that additional service, it is recommended that some method (outside the scope of this document) be used by which the content from EUs is transmitted to the application in AD-1 and AD-1 can send out the traffic as IP multicast. From that point on, the descriptions in this document apply, except that they are not complete because they do not cover the transport or operational aspects of the leg from the EU to AD-1.
* 本文档未详细说明EU是原始内容的情况。为了支持该附加服务，建议使用某种方法（不在本文档范围内），将EUs中的内容传输到AD-1中的应用程序，并且AD-1可以将流量作为IP多播发送出去。从那时起，本文件中的描述适用，但不完整，因为它们没有涵盖从欧盟到AD-1的航段的运输或运营方面。
* This document does not detail the case where AD-1 and AD-2 are not directly connected to each other and are instead connected via one or more other ADs (as opposed to a peering point) that serve as transit providers. The cases described in this document where tunnels are used between AD-1 and AD-2 can be applied to such scenarios, but SLA ("Service Level Agreement")
* 本文件未详细说明AD-1和AD-2不直接相互连接，而是通过一个或多个用作传输提供商的其他ADs（与对等点相反）连接的情况。本文件中描述的AD-1和AD-2之间使用隧道的情况可适用于此类场景，但SLA（“服务水平协议”）
control, for example, would be different. Additional issues will likely exist as well in such scenarios. This topic is left for further study.
例如，控件将是不同的。在这种情况下，还可能存在其他问题。这一主题有待进一步研究。
o For the purposes of this document, the term "peering point" refers to a network connection ("link") between two administrative network domains over which traffic is exchanged between them. This is also referred to as a Network-to-Network Interface (NNI). Unless otherwise noted, it is assumed that the peering point is a private peering point, where the network connection is a physically or virtually isolated network connection solely between AD-1 and AD-2. The other case is that of a broadcast peering point, which is a common option in public Internet Exchange Points (IXPs). See Section 4.2.4 for more details.
o 在本文件中，术语“对等点”是指两个管理网络域之间的网络连接（“链路”），在这两个管理网络域之间交换流量。这也称为网络对网络接口（NNI）。除非另有说明，否则假定对等点是专用对等点，其中网络连接是仅在AD-1和AD-2之间的物理或虚拟隔离的网络连接。另一种情况是广播对等点，这是公共Internet交换点（IXP）中的常见选项。详见第4.2.4节。
o AD-1 is enabled with native multicast. A peering point exists between AD-1 and AD-2.
o AD-1通过本机多播启用。AD-1和AD-2之间存在对等点。
o It is understood that several protocols are available for this purpose, including Protocol-Independent Multicast - Sparse Mode (PIM-SM) and Protocol-Independent Multicast - Source-Specific Multicast (PIM-SSM) [RFC7761], the Internet Group Management Protocol (IGMP) [RFC3376], and Multicast Listener Discovery (MLD) [RFC3810].
o 据了解，有几种协议可用于此目的，包括协议独立多播稀疏模式（PIM-SM）和协议独立多播源特定多播（PIM-SSM）[RFC7761]、互联网组管理协议（IGMP）[RFC3376]和多播侦听器发现（MLD）[RFC3810]。
o As described in Section 2, the source IP address of the (so-called "(S,G)") multicast stream in the originating AD (AD-1) is known. Under this condition, using PIM-SSM is beneficial, as it allows the receiver's upstream router to send a join message directly to the source without the need to invoke an intermediate Rendezvous Point (RP). The use of SSM also presents an improved threat mitigation profile against attack, as described in [RFC4609]. Hence, in the case of inter-domain peering, it is recommended that only SSM protocols be used; the setup of inter-domain peering for ASM (Any-Source Multicast) is out of scope for this document.
o 如第2节所述，原始AD（AD-1）中的（所谓的“（S，G）”）多播流的源IP地址是已知的。在这种情况下，使用PIM-SSM是有益的，因为它允许接收器的上游路由器直接向源发送连接消息，而无需调用中间集合点（RP）。如[RFC4609]所述，SSM的使用还提供了针对攻击的改进的威胁缓解配置文件。因此，在域间对等的情况下，建议仅使用SSM协议；ASM（任何源多播）的域间对等设置超出了本文档的范围。
o The rest of this document assumes that PIM-SSM and BGP are used across the peering point, plus Automatic Multicast Tunneling (AMT) [RFC7450] and/or Generic Routing Encapsulation (GRE), according to the scenario in question. The use of other protocols is beyond the scope of this document.
o 本文档的其余部分假设PIM-SSM和BGP在对等点上使用，加上自动多播隧道（AMT）[RFC7450]和/或通用路由封装（GRE），根据所讨论的场景。其他协议的使用超出了本文件的范围。
o AMT is set up at the peering point if either the peering point or AD-2 is not multicast enabled. It is assumed that an AMT relay will be available to a client for multicast delivery. The selection of an optimal AMT relay by a client is out of scope for
o 如果对等点或AD-2未启用多播，则在对等点设置AMT。假设客户端可以使用AMT中继进行多播传送。客户选择最佳AMT继电器超出了我们的范围
this document. Note that using AMT is necessary only when native multicast is unavailable in the peering point (Use Case 3.3) or in the downstream administrative domain (Use Cases 3.4 and 3.5).
这份文件。请注意，只有当对等点（用例3.3）或下游管理域（用例3.4和3.5）中的本机多播不可用时，才需要使用AMT。
o It is assumed that the collection of billing data is done at the application level and is not considered to be a networking issue. The settlements process for EU billing and/or inter-provider billing is out of scope for this document.
o 假设计费数据的收集是在应用程序级别完成的，不被视为网络问题。欧盟账单和/或供应商间账单的结算流程不在本文件范围内。
o Inter-domain network connectivity troubleshooting is only considered within the context of a cooperative process between the two domains.
o 域间网络连接故障排除仅在两个域之间的协作过程中考虑。
This document also attempts to identify ways by which the peering process can be improved. Development of new methods for improvement is beyond the scope of this document.
本文档还试图确定改进对等过程的方法。开发新的改进方法超出了本文件的范围。
A multicast-based application delivery scenario is as follows:
基于多播的应用程序交付场景如下所示：
o Two independent administrative domains are interconnected via a peering point.
o 两个独立的管理域通过对等点互连。
o The peering point is either multicast enabled (end-to-end native multicast across the two domains) or connected by one of two possible tunnel types:
o 对等点要么启用多播（跨两个域的端到端本机多播），要么通过两种可能的隧道类型之一连接：
* A GRE tunnel [RFC2784] allowing multicast tunneling across the peering point, or
* 允许跨对等点的多播隧道的GRE隧道[RFC2784]，或
* AMT [RFC7450].
* 金额[RFC7450]。
o A service provider controls one or more application sources in AD-1 that will send multicast IP packets via one or more (S,G)s (multicast traffic flows; see Section 4.2.1 if you are unfamiliar with IP multicast). It is assumed that the service being provided is suitable for delivery via multicast (e.g., live video streaming of popular events, software downloads to many devices) and that the packet streams will be carried by a suitable multicast transport protocol.
o 服务提供商控制AD-1中的一个或多个应用程序源，该应用程序源将通过一个或多个（S，G）发送多播IP数据包（多播通信流；如果您不熟悉IP多播，请参阅第4.2.1节）。假设所提供的服务适合于通过多播（例如，流行事件的实时视频流、到许多设备的软件下载）进行交付，并且分组流将由合适的多播传输协议承载。
o An EU controls a device connected to AD-2, which runs an application client compatible with the service provider's application source.
o EU控制连接到AD-2的设备，AD-2运行与服务提供商的应用程序源兼容的应用程序客户端。
o The application client joins appropriate (S,G)s in order to receive the data necessary to provide the service to the EU. The mechanisms by which the application client learns the appropriate (S,G)s are an implementation detail of the application and are out of scope for this document.
o 应用程序客户端加入适当的（S，G）以接收向EU提供服务所需的数据。应用程序客户端学习适当（S，G）的机制是应用程序的实现细节，不在本文档的范围内。
The assumption here is that AD-1 has ultimate responsibility for delivering the multicast-based service on behalf of the content source(s). All relevant interactions between the two domains described in this document are based on this assumption.
这里的假设是AD-1对代表内容源交付基于多播的服务负有最终责任。本文档中描述的两个域之间的所有相关交互都基于此假设。
Note that AD-2 may be an independent network domain (e.g., a Tier 1 network operator domain). Alternately, AD-2 could also be an enterprise network domain operated by a single customer of AD-1. The peering point architecture and requirements may have some unique aspects associated with enterprise networks; see Section 3.
注意，AD-2可以是独立的网络域（例如，第1层网络运营商域）。或者，AD-2也可以是由AD-1的单个客户操作的企业网络域。对等点架构和需求可能有一些与企业网络相关的独特方面；见第3节。
The use cases describing various architectural configurations for multicast distribution, along with associated requirements, are described in Section 3. Section 4 contains a comprehensive list of pertinent information that needs to be exchanged between the two domains in order to support functions to enable application transport.
第3节描述了描述多播分发的各种体系结构配置的用例以及相关需求。第4节包含两个域之间需要交换的相关信息的综合列表，以支持启用应用程序传输的功能。
The transport of applications using multicast requires that the inter-domain peering point be enabled to support such a process. This section presents five use cases for consideration.
使用多播传输应用程序需要启用域间对等点以支持这种过程。本节介绍了五个需要考虑的用例。
This use case involves end-to-end native multicast between the two administrative domains, and the peering point is also native multicast enabled. See Figure 1.
此用例涉及两个管理域之间的端到端本机多播，并且对等点也启用了本机多播。参见图1。
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ | | |
| | | +------+ | | +------+ | +----+
| | AS |------>| BR |-|---------|->| BR |-------------|-->| EU |
| | | +------+ | I1 | +------+ |I2 +----+
\ +----+ / \ /
\ / \ /
\ / \ /
------------------- -------------------
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ | | |
| | | +------+ | | +------+ | +----+
| | AS |------>| BR |-|---------|->| BR |-------------|-->| EU |
| | | +------+ | I1 | +------+ |I2 +----+
\ +----+ / \ /
\ / \ /
\ / \ /
------------------- -------------------
AD = Administrative Domain (independent autonomous system) AS = multicast (e.g., content) Application Source BR = Border Router I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP) I2 = AD-2 and EU multicast connection
AD=管理域（独立自治系统）AS=多播（如内容）应用程序源BR=边界路由器I1=AD-1和AD-2多播互连（如MP-BGP）I2=AD-2和EU多播连接
Figure 1: Content Distribution via End-to-End Native Multicast
图1：通过端到端本机多播的内容分发
Advantages of this configuration:
此配置的优点：
o Most efficient use of bandwidth in both domains.
o 在两个域中最有效地利用带宽。
o Fewer devices in the path traversed by the multicast stream when compared to an AMT-enabled peering point.
o 与启用AMT的对等点相比，多播流通过的路径中的设备更少。
From the perspective of AD-1, the one disadvantage associated with native multicast to AD-2 instead of individual unicast to every EU in AD-2 is that it does not have the ability to count the number of EUs as well as the transmitted bytes delivered to them. This information is relevant from the perspective of customer billing and operational logs. It is assumed that such data will be collected by the application layer. The application-layer mechanisms for generating this information need to be robust enough so that all pertinent requirements for the source provider and the AD operator are satisfactorily met. The specifics of these methods are beyond the scope of this document.
从AD-1的角度来看，与AD-2的本机多播而不是AD-2中的每个EU的单独单播相关联的一个缺点是，它不能计算EU的数量以及发送给它们的传输字节。从客户账单和运营日志的角度来看，这些信息是相关的。假设这些数据将由应用层收集。用于生成此信息的应用层机制需要足够健壮，以便满意地满足源提供者和AD运营商的所有相关要求。这些方法的细节超出了本文件的范围。
Architectural guidelines for this configuration are as follows:
此配置的体系结构指南如下所示：
a. Dual homing for peering points between domains is recommended as a way to ensure reliability with full BGP table visibility.
a. 建议对域之间的对等点进行双重归巢，以确保可靠性和完整的BGP表可见性。
b. If the peering point between AD-1 and AD-2 is a controlled network environment, then bandwidth can be allocated accordingly by the two domains to permit the transit of non-rate-adaptive multicast traffic. If this is not the case, then the multicast traffic must support congestion control via any of the mechanisms described in Section 4.1 of [BCP145].
b. 如果AD-1和AD-2之间的对等点是受控网络环境，则两个域可以相应地分配带宽，以允许非速率自适应多播流量的传输。如果情况并非如此，则多播流量必须通过[BCP145]第4.1节所述的任何机制支持拥塞控制。
c. The sending and receiving of multicast traffic between two domains is typically determined by local policies associated with each domain. For example, if AD-1 is a service provider and AD-2 is an enterprise, then AD-1 may support local policies for traffic delivery to, but not traffic reception from, AD-2. Another example is the use of a policy by which AD-1 delivers specified content to AD-2 only if such delivery has been accepted by contract.
c. 两个域之间多播流量的发送和接收通常由与每个域关联的本地策略确定。例如，如果AD-1是服务提供商，AD-2是企业，则AD-1可以支持本地策略，用于向AD-2发送流量，但不支持从AD-2接收流量。另一个例子是使用一种策略，根据该策略，AD-1仅在合同接受指定内容的情况下才向AD-2交付该内容。
d. It is assumed that relevant information on multicast streams delivered to EUs in AD-2 is collected by available capabilities in the application layer. The precise nature and formats of the collected information will be determined by directives from the source owner and the domain operators.
d. 假定通过应用层中的可用功能收集关于在AD-2中传送到EUs的多播流的相关信息。所收集信息的确切性质和格式将由源所有者和域操作员的指令确定。
The peering point is not native multicast enabled in this use case. There is a GRE tunnel provisioned over the peering point. See Figure 2.
对等点在此用例中未启用本机多播。在对等点上设置了GRE隧道。参见图2。
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ +---+ | (I1) | +---+ |
| | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+
| | AS |-->|BR| +---+-| | +---+ |BR| -------->|-->| EU |
| | | +--+<........|........|........>+--+ |I2 +----+
\ +----+ / I1 \ /
\ / GRE \ /
\ / Tunnel \ /
------------------- -------------------
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ +---+ | (I1) | +---+ |
| | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+
| | AS |-->|BR| +---+-| | +---+ |BR| -------->|-->| EU |
| | | +--+<........|........|........>+--+ |I2 +----+
\ +----+ / I1 \ /
\ / GRE \ /
\ / Tunnel \ /
------------------- -------------------
AD = Administrative Domain (independent autonomous system)
AS = multicast (e.g., content) Application Source
uBR = unicast Border Router - not necessarily multicast enabled;
may be the same router as BR
BR = Border Router - for multicast
I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP)
I2 = AD-2 and EU multicast connection
AD = Administrative Domain (independent autonomous system)
AS = multicast (e.g., content) Application Source
uBR = unicast Border Router - not necessarily multicast enabled;
may be the same router as BR
BR = Border Router - for multicast
I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP)
I2 = AD-2 and EU multicast connection
Figure 2: Content Distribution via GRE Tunnel
图2：通过GRE隧道的内容分布
In this case, interconnection I1 between AD-1 and AD-2 in Figure 2 is multicast enabled via a GRE tunnel [RFC2784] between the two BRs and encapsulating the multicast protocols across it.
在这种情况下，图2中AD-1和AD-2之间的互连I1通过两个BR之间的GRE隧道[RFC2784]启用多播，并封装多播协议。
Normally, this approach is chosen if the uBR physically connected to the peering link cannot or should not be enabled for IP multicast. This approach may also be beneficial if the BR and uBR are the same device but the peering link is a broadcast domain (IXP); see Section 4.2.4.
通常，如果物理连接到对等链路的uBR不能或不应启用IP多播，则选择此方法。如果BR和uBR是相同的设备，但是对等链路是广播域（IXP），则该方法也可能是有益的；见第4.2.4节。
The routing configuration is basically unchanged: instead of running BGP (SAFI-2) ("SAFI" stands for "Subsequent Address Family Identifier") across the native IP multicast link between AD-1 and AD-2, BGP (SAFI-2) is now run across the GRE tunnel.
路由配置基本上没有改变：BGP（SAFI-2）（“SAFI”代表“后续地址族标识符”）不再在AD-1和AD-2之间的本机IP多播链路上运行，而是在GRE隧道上运行。
Advantages of this configuration:
此配置的优点：
o Highly efficient use of bandwidth in both domains, although not as efficient as the fully native multicast use case (Section 3.1).
o 在两个域中高效地使用带宽，尽管不如完全本机多播用例（第3.1节）那样高效。
o Fewer devices in the path traversed by the multicast stream when compared to an AMT-enabled peering point.
o 与启用AMT的对等点相比，多播流通过的路径中的设备更少。
o Ability to support partial and/or incremental IP multicast deployments in AD-1 and/or AD-2: only the path or paths between the AS/BR (AD-1) and the BR/EU (AD-2) need to be multicast enabled. The uBRs may not support IP multicast or enabling it could be seen as operationally risky on that important edge node, whereas dedicated BR nodes for IP multicast may (at least initially) be more acceptable. The BR can also be located such that only parts of the domain may need to support native IP multicast (e.g., only the core in AD-1 but not edge networks towards the uBR).
o 在AD-1和/或AD-2中支持部分和/或增量IP多播部署的能力：只有AS/BR（AD-1）和BR/EU（AD-2）之间的路径需要启用多播。UBR可能不支持IP多播，或者在该重要边缘节点上启用IP多播可能被视为操作风险，而用于IP多播的专用BR节点可能（至少在最初）更为可接受。BR还可以被定位为仅域的一部分可能需要支持本机IP多播（例如，仅AD-1中的核心，而不是朝向uBR的边缘网络）。
o GRE is an existing technology and is relatively simple to implement.
o GRE是一种现有技术，实现起来相对简单。
Disadvantages of this configuration:
这种配置的缺点：
o Per Use Case 3.1, current router technology cannot count the number of EUs or the number of bytes transmitted.
o 根据用例3.1，当前路由器技术无法计算EUs的数量或传输的字节数。
o The GRE tunnel requires manual configuration.
o GRE隧道需要手动配置。
o The GRE tunnel must be established prior to starting the stream.
o GRE隧道必须在启动河流之前建立。
o The GRE tunnel is often left pinned up.
o GRE隧道经常被钉死。
Architectural guidelines for this configuration include the following:
此配置的体系结构指南包括以下内容：
Guidelines (a) through (d) are the same as those described in Use Case 3.1. Two additional guidelines are as follows:
指南（a）至（d）与用例3.1中描述的指南相同。另外两项准则如下：
e. GRE tunnels are typically configured manually between peering points to support multicast delivery between domains.
e. GRE隧道通常在对等点之间手动配置，以支持域之间的多播交付。
f. It is recommended that the GRE tunnel (tunnel server) configuration in the source network be such that it only advertises the routes to the application sources and not to the entire network. This practice will prevent unauthorized delivery
f. 建议源网络中的GRE tunnel（隧道服务器）配置仅播发到应用程序源而不是整个网络的路由。这种做法将防止未经授权的交付
of applications through the tunnel (for example, if the application (e.g., content) is not part of an agreed-upon inter-domain partnership).
通过隧道的应用程序数量（例如，如果应用程序（例如，内容）不是商定的域间合作关系的一部分）。
It is assumed that both administrative domains in this use case are native multicast enabled here; however, the peering point is not.
假设本用例中的两个管理域都在这里启用了本机多播；但是，对等点不是。
The peering point is enabled with AMT. The basic configuration is depicted in Figure 3.
对等点已启用AMT。基本配置如图3所示。
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ +---+ | I1 | +---+ |
| | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+
| | AS |-->|AR| +---+-| | +---+ |AG| -------->|-->| EU |
| | | +--+<........|........|........>+--+ |I2 +----+
\ +----+ / AMT \ /
\ / Tunnel \ /
\ / \ /
------------------- -------------------
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \
| +----+ +---+ | I1 | +---+ |
| | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+
| | AS |-->|AR| +---+-| | +---+ |AG| -------->|-->| EU |
| | | +--+<........|........|........>+--+ |I2 +----+
\ +----+ / AMT \ /
\ / Tunnel \ /
\ / \ /
------------------- -------------------
AD = Administrative Domain (independent autonomous system)
AS = multicast (e.g., content) Application Source
AR = AMT Relay
AG = AMT Gateway
uBR = unicast Border Router - not multicast enabled;
also, either AR = uBR (AD-1) or uBR = AG (AD-2)
I1 = AMT interconnection between AD-1 and AD-2
I2 = AD-2 and EU multicast connection
AD = Administrative Domain (independent autonomous system)
AS = multicast (e.g., content) Application Source
AR = AMT Relay
AG = AMT Gateway
uBR = unicast Border Router - not multicast enabled;
also, either AR = uBR (AD-1) or uBR = AG (AD-2)
I1 = AMT interconnection between AD-1 and AD-2
I2 = AD-2 and EU multicast connection
Figure 3: AMT Interconnection between AD-1 and AD-2
图3:AD-1和AD-2之间的AMT互连
Advantages of this configuration:
此配置的优点：
o Highly efficient use of bandwidth in AD-1.
o 在AD-1中高效利用带宽。
o AMT is an existing technology and is relatively simple to implement. Attractive properties of AMT include the following:
o AMT是一种现有技术，实施相对简单。AMT的吸引人的特性包括：
* Dynamic interconnection between the gateway-relay pair across the peering point.
* 跨对等点的网关中继对之间的动态互连。
* Ability to serve clients and servers with differing policies.
* 能够使用不同的策略为客户机和服务器提供服务。
Disadvantages of this configuration:
这种配置的缺点：
o Per Use Case 3.1 (AD-2 is native multicast), current router technology cannot count the number of EUs or the number of bytes transmitted to all EUs.
o 根据用例3.1（AD-2是本机多播），当前路由器技术无法计算EU的数量或传输到所有EU的字节数。
o Additional devices (AMT gateway and relay pairs) may be introduced into the path if these services are not incorporated into the existing routing nodes.
o 如果这些服务未合并到现有路由节点中，则可将其他设备（AMT网关和中继对）引入路径中。
o Currently undefined mechanisms for the AG to automatically select the optimal AR.
o 目前AG自动选择最佳AR的未定义机制。
Architectural guidelines for this configuration are as follows:
此配置的体系结构指南如下所示：
Guidelines (a) through (d) are the same as those described in Use Case 3.1. In addition,
指南（a）至（d）与用例3.1中描述的指南相同。此外
e. It is recommended that AMT relay and gateway pairs be configured at the peering points to support multicast delivery between domains. AMT tunnels will then configure dynamically across the peering points once the gateway in AD-2 receives the (S,G) information from the EU.
e. 建议在对等点配置AMT中继和网关对，以支持域之间的多播传递。一旦AD-2中的网关从欧盟接收到（S，G）信息，AMT隧道将在对等点上动态配置。
In this AMT use case, AD-2 is not multicast enabled. Hence, the interconnection between AD-2 and the EU is also not multicast enabled. This use case is depicted in Figure 4.
在此AMT用例中，AD-2未启用多播。因此，AD-2和EU之间的互连也不支持多播。该用例如图4所示。
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Not Multicast \
/ \ / Enabled) \ N(large)
| +----+ +---+ | | +---+ | # EUs
| | | +--+ |uBR|-|--------|-|uBR| | +----+
| | AS |-->|AR| +---+-| | +---+ ................>|EU/G|
| | | +--+<........|........|........... |I2 +----+
\ +----+ / N x AMT\ /
\ / Tunnel \ /
\ / \ /
------------------- -------------------
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Not Multicast \
/ \ / Enabled) \ N(large)
| +----+ +---+ | | +---+ | # EUs
| | | +--+ |uBR|-|--------|-|uBR| | +----+
| | AS |-->|AR| +---+-| | +---+ ................>|EU/G|
| | | +--+<........|........|........... |I2 +----+
\ +----+ / N x AMT\ /
\ / Tunnel \ /
\ / \ /
------------------- -------------------
AS = multicast (e.g., content) Application Source
uBR = unicast Border Router - not multicast enabled;
otherwise, AR = uBR (in AD-1)
AR = AMT Relay
EU/G = Gateway client embedded in EU device
I2 = AMT tunnel connecting EU/G to AR in AD-1 through
non-multicast-enabled AD-2
AS = multicast (e.g., content) Application Source
uBR = unicast Border Router - not multicast enabled;
otherwise, AR = uBR (in AD-1)
AR = AMT Relay
EU/G = Gateway client embedded in EU device
I2 = AMT tunnel connecting EU/G to AR in AD-1 through
non-multicast-enabled AD-2
Figure 4: AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway
图4：连接AD-1 AMT继电器和EU网关的AMT隧道
This use case is equivalent to having unicast distribution of the application through AD-2. The total number of AMT tunnels would be equal to the total number of EUs requesting the application. The peering point thus needs to accommodate the total number of AMT tunnels between the two domains. Each AMT tunnel can provide the data usage associated with each EU.
此用例相当于通过AD-2进行应用程序的单播分发。AMT隧道总数将等于请求申请的EU总数。因此，对等点需要容纳两个域之间的AMT隧道总数。每个AMT隧道可以提供与每个EU相关的数据使用情况。
Advantages of this configuration:
此配置的优点：
o Efficient use of bandwidth in AD-1 (the closer the AR is to the uBR, the more efficient).
o AD-1中带宽的有效利用（AR越靠近uBR，效率越高）。
o Ability of AD-1 to introduce content delivery based on IP multicast, without any support by network devices in AD-2: only the application side in the EU device needs to perform AMT gateway library functionality to receive traffic from the AMT relay.
o AD-1能够引入基于IP多播的内容交付，而不受AD-2中网络设备的任何支持：只有EU设备中的应用程序端需要执行AMT网关库功能以接收来自AMT中继的流量。
o Allows AD-2 to "upgrade" to Use Case 3.5 (see Section 3.5) at a later time, without any change in AD-1 at that time.
o 允许AD-2在以后“升级”到用例3.5（参见第3.5节），而不需要对AD-1进行任何更改。
o AMT is an existing technology and is relatively simple to implement. Attractive properties of AMT include the following:
o AMT是一种现有技术，实施相对简单。AMT的吸引人的特性包括：
* Dynamic interconnection between the AMT gateway-relay pair across the peering point.
* 跨对等点的AMT网关中继对之间的动态互连。
* Ability to serve clients and servers with differing policies.
* 能够使用不同的策略为客户机和服务器提供服务。
o Each AMT tunnel serves as a count for each EU and is also able to track data usage (bytes) delivered to the EU.
o 每个AMT隧道用作每个EU的计数，并且还能够跟踪交付到EU的数据使用情况（字节）。
Disadvantages of this configuration:
这种配置的缺点：
o Additional devices (AMT gateway and relay pairs) are introduced into the transport path.
o 传输路径中引入了其他设备（AMT网关和中继对）。
o Assuming multiple peering points between the domains, the EU gateway needs to be able to find the "correct" AMT relay in AD-1.
o 假设域之间有多个对等点，EU网关需要能够在AD-1中找到“正确”的AMT中继。
Architectural guidelines for this configuration are as follows:
此配置的体系结构指南如下所示：
Guidelines (a) through (c) are the same as those described in Use Case 3.1. In addition,
指南（a）到（c）与用例3.1中描述的指南相同。此外
d. It is necessary that proper procedures be implemented such that the AMT gateway at the EU device is able to find the correct AMT relay for each (S,G) content stream. Standard mechanisms for that selection are still subject to ongoing work. This includes the use of anycast gateway addresses, anycast DNS names, or explicit configuration that maps (S,G) to a relay address; or letting the application in the EU/G provide the relay address to the embedded AMT gateway function.
d. 必须执行适当的程序，以便EU设备上的AMT网关能够为每个（S，G）内容流找到正确的AMT中继。这一选择的标准机制仍有待于不断的工作。这包括使用选播网关地址、选播DNS名称或映射（S、G）到中继地址的显式配置；或者让EU/G中的应用程序向嵌入式AMT网关功能提供中继地址。
e. The AMT tunnel's capabilities are expected to be sufficient for the purpose of collecting relevant information on the multicast streams delivered to EUs in AD-2.
e. AMT隧道的能力预计足以收集AD-2中交付给EUs的多播流的相关信息。
Figure 5 illustrates a variation of Use Case 3.4:
图5说明了用例3.4的变化：
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Not Multicast \
/ +---+ \ (I1) / +---+ Enabled) \
| +----+ |uBR|-|--------|-|uBR| |
| | | +--+ +---+ | | +---+ +---+ | +----+
| | AS |-->|AR|<........|.... | +---+ |AG/|....>|EU/G|
| | | +--+ | ......|.|AG/|..........>|AR2| |I3 +----+
\ +----+ / I1 \ |AR1| I2 +---+ /
\ / Single \+---+ /
\ / AMT Tunnel \ /
------------------- -------------------
------------------- -------------------
/ AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Not Multicast \
/ +---+ \ (I1) / +---+ Enabled) \
| +----+ |uBR|-|--------|-|uBR| |
| | | +--+ +---+ | | +---+ +---+ | +----+
| | AS |-->|AR|<........|.... | +---+ |AG/|....>|EU/G|
| | | +--+ | ......|.|AG/|..........>|AR2| |I3 +----+
\ +----+ / I1 \ |AR1| I2 +---+ /
\ / Single \+---+ /
\ / AMT Tunnel \ /
------------------- -------------------
uBR = unicast Border Router - not multicast enabled;
also, either AR = uBR (AD-1) or uBR = AGAR1 (AD-2)
AS = multicast (e.g., content) Application Source
AR = AMT Relay in AD-1
AGAR1 = AMT Gateway/Relay node in AD-2 across peering point
I1 = AMT tunnel connecting AR in AD-1 to gateway in AGAR1 in AD-2
AGAR2 = AMT Gateway/Relay node at AD-2 network edge
I2 = AMT tunnel connecting relay in AGAR1 to gateway in AGAR2
EU/G = Gateway client embedded in EU device
I3 = AMT tunnel connecting EU/G to AR in AGAR2
uBR = unicast Border Router - not multicast enabled;
also, either AR = uBR (AD-1) or uBR = AGAR1 (AD-2)
AS = multicast (e.g., content) Application Source
AR = AMT Relay in AD-1
AGAR1 = AMT Gateway/Relay node in AD-2 across peering point
I1 = AMT tunnel connecting AR in AD-1 to gateway in AGAR1 in AD-2
AGAR2 = AMT Gateway/Relay node at AD-2 network edge
I2 = AMT tunnel connecting relay in AGAR1 to gateway in AGAR2
EU/G = Gateway client embedded in EU device
I3 = AMT tunnel connecting EU/G to AR in AGAR2
Figure 5: AMT Tunnel Connecting AMT Gateways and Relays
图5：连接AMT网关和继电器的AMT隧道
Use Case 3.4 results in several long AMT tunnels crossing the entire network of AD-2 linking the EU device and the AMT relay in AD-1 through the peering point. Depending on the number of EUs, there is a likelihood of an unacceptably high amount of traffic due to the large number of AMT tunnels -- and unicast streams -- through the peering point. This situation can be alleviated as follows:
用例3.4导致几个长的AMT隧道穿过AD-2的整个网络，通过对等点连接EU设备和AD-1中的AMT继电器。根据EU的数量，由于通过对等点的大量AMT隧道和单播流，可能会出现不可接受的高流量。这种情况可以通过以下方式得到缓解：
o Provisioning of strategically located AMT nodes in AD-2. An AMT node comprises co-location of an AMT gateway and an AMT relay. No change is required by AD-1, as compared to Use Case 3.4. This can be done whenever AD-2 sees fit (e.g., too much traffic across the peering point).
o 在AD-2中提供战略位置的AMT节点。AMT节点包括AMT网关和AMT中继的同址。与用例3.4相比，AD-1不需要更改。只要AD-2认为合适，就可以这样做（例如，通过对等点的流量过大）。
o One such node is on the AD-2 side of the peering point (AMT node AGAR1 in Figure 5).
o 一个这样的节点位于对等点的AD-2侧（图5中的AMT节点1）。
o A single AMT tunnel established across the peering point linking the AMT relay in AD-1 to the AMT gateway in AMT node AGAR1 in AD-2.
o 通过对等点建立的单个AMT隧道将AD-1中的AMT中继连接到AD-2中AMT节点AGAR1中的AMT网关。
o AMT tunnels linking AMT node AGAR1 at the peering point in AD-2 to other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2 linking the AMT relay in AGAR1 to the AMT gateway in AMT node AGAR2 (Figure 5).
o 将AD-2中对等点处的AMT节点AGAR1连接到AD-2边缘处其他AMT节点的AMT隧道：例如，将AGAR1中的AMT继电器连接到AMT节点AGAR2中的AMT网关的AMT隧道I2（图5）。
o AMT tunnels linking an EU device (via a gateway client embedded in the device) and an AMT relay in an appropriate AMT node at the edge of AD-2: e.g., I3 linking the EU gateway in the device to the AMT relay in AMT node AGAR2.
o AMT隧道连接EU设备（通过嵌入设备中的网关客户端）和AD-2边缘适当AMT节点中的AMT中继：例如，I3将设备中的EU网关连接到AMT节点2中的AMT中继。
o In the simplest option (not shown), AD-2 only deploys a single AGAR1 node and lets the EU/G build AMT tunnels directly to it. This setup already solves the problem of replicated traffic across the peering point. As soon as there is a need to support more AMT tunnels to the EU/G, then additional AGAR2 nodes can be deployed by AD-2.
o 在最简单的选项（未显示）中，AD-2仅部署一个AGAR1节点，并允许EU/G直接构建AMT隧道。此设置已经解决了跨对等点复制流量的问题。一旦需要支持更多通向EU/G的AMT隧道，AD-2就可以部署更多的AGAR2节点。
The advantage of such a chained set of AMT tunnels is that the total number of unicast streams across AD-2 is significantly reduced, thus freeing up bandwidth. Additionally, there will be a single unicast stream across the peering point instead of, possibly, an unacceptably large number of such streams per Use Case 3.4. However, this implies that several AMT tunnels will need to be dynamically configured by the various AMT gateways, based solely on the (S,G) information received from the application client at the EU device. A suitable mechanism for such dynamic configurations is therefore critical.
这种链式AMT隧道组的优点是，通过AD-2的单播流的总数显著减少，从而释放了带宽。此外，在每个用例3.4中，将有一个单一的单播流穿过对等点，而不是不可接受的大量这样的流。然而，这意味着几个AMT隧道将需要由各种AMT网关仅基于从EU设备上的应用程序客户端接收的（S，G）信息来动态配置。因此，这种动态配置的合适机制至关重要。
Architectural guidelines for this configuration are as follows:
此配置的体系结构指南如下所示：
Guidelines (a) through (c) are the same as those described in Use Case 3.1. In addition,
指南（a）到（c）与用例3.1中描述的指南相同。此外
d. It is necessary that proper procedures be implemented such that the various AMT gateways (at the EU devices and the AMT nodes in AD-2) are able to find the correct AMT relay in other AMT nodes as appropriate. Standard mechanisms for that selection are still subject to ongoing work. This includes the use of anycast gateway addresses, anycast DNS names, or explicit configuration that maps (S,G) to a relay address. On the EU/G, this mapping information may come from the application.
d. 有必要实施适当的程序，以便各种AMT网关（在欧盟设备和AD-2中的AMT节点处）能够在其他AMT节点中找到正确的AMT中继（视情况而定）。这一选择的标准机制仍有待于不断的工作。这包括使用选播网关地址、选播DNS名称或将（S、G）映射到中继地址的显式配置。在EU/G上，此映射信息可能来自应用程序。
e. The AMT tunnel's capabilities are expected to be sufficient for the purpose of collecting relevant information on the multicast streams delivered to EUs in AD-2.
e. AMT隧道的能力预计足以收集AD-2中交付给EUs的多播流的相关信息。
Supporting functions and related interfaces over the peering point that enable the multicast transport of the application are listed in this section. Critical information parameters that need to be exchanged in support of these functions are enumerated, along with guidelines as appropriate. Specific interface functions for consideration are as follows.
本节列出了对等点上支持应用程序多播传输的功能和相关接口。列举了为支持这些功能而需要交换的关键信息参数以及相应的指南。需要考虑的具体接口功能如下。
The term "network interconnection transport" refers to the interconnection points between the two administrative domains. The following is a representative set of attributes that the two administrative domains will need to agree on to support multicast delivery.
术语“网络互连传输”指两个管理域之间的互连点。以下是两个管理域需要商定的一组代表性属性，以支持多播交付。
o Number of peering points.
o 对等点的数量。
o Peering point addresses and locations.
o 对等点地址和位置。
o Connection type - Dedicated for multicast delivery or shared with other services.
o 连接类型-专用于多播传送或与其他服务共享。
o Connection mode - Direct connectivity between the two ADs or via another ISP.
o 连接模式-两个ADs之间或通过另一个ISP直接连接。
o Peering point protocol support - Multicast protocols that will be used for multicast delivery will need to be supported at these points. Examples of such protocols include External BGP (EBGP) [RFC4760] peering via MP-BGP (Multiprotocol BGP) SAFI-2 [RFC4760].
o 对等点协议支持-将用于多播传送的多播协议需要在这些点上得到支持。此类协议的示例包括通过MP-BGP（多协议BGP）SAFI-2[RFC4760]的外部BGP（EBGP）[RFC4760]对等。
o Bandwidth allocation - If shared with other services, then there needs to be a determination of the share of bandwidth reserved for multicast delivery. See Section 4.1.1 below for more details.
o 带宽分配-如果与其他服务共享，则需要确定为多播交付保留的带宽份额。更多详情见下文第4.1.1节。
o QoS requirements - Delay and/or latency specifications that need to be specified in an SLA.
o QoS要求-需要在SLA中指定的延迟和/或延迟规范。
o AD roles and responsibilities - The role played by each AD for provisioning and maintaining the set of peering points to support multicast delivery.
o AD角色和职责—每个AD在提供和维护对等点集以支持多播交付方面所扮演的角色。
Like IP unicast traffic, IP multicast traffic carried across non-controlled networks must comply with congestion control principles as described in [BCP41] and as explained in detail for UDP IP multicast in [BCP145].
与IP单播流量一样，通过非受控网络传输的IP多播流量必须符合[BCP41]中所述的拥塞控制原则以及[BCP145]中UDP IP多播的详细说明。
Non-controlled networks (such as the Internet) are networks where there is no policy for managing bandwidth other than best effort with a fair share of bandwidth under congestion. As a simplified rule of thumb, complying with congestion control principles means reducing bandwidth under congestion in a way that is fair to competing (typically TCP) flows ("rate adaptive").
非受控网络（如互联网）是指在拥塞情况下，除了尽最大努力和公平的带宽份额外，没有管理带宽的策略的网络。作为一个简化的经验法则，遵守拥塞控制原则意味着以对竞争（通常是TCP）流公平的方式减少拥塞下的带宽（“速率自适应”）。
In many instances, multicast content delivery evolves from intra-domain deployments where it is handled as a controlled network service and does not comply with congestion control principles. It was given a reserved amount of bandwidth and admitted to the network so that congestion never occurs. Therefore, the congestion control issue should be given specific attention when evolving to an inter-domain peering deployment.
在许多情况下，多播内容交付是从域内部署演变而来的，在域内部署中，多播内容作为受控网络服务处理，不符合拥塞控制原则。它被给予保留的带宽并允许进入网络，这样就不会发生拥塞。因此，当发展到域间对等部署时，应该特别注意拥塞控制问题。
In the case where end-to-end IP multicast traffic passes across the network of two ADs (and their subsidiaries/customers), both ADs must agree on a consistent traffic-management policy. If, for example, AD-1 sources non-congestion-aware IP multicast traffic and AD-2 carries it as best-effort traffic across links shared with other Internet traffic (subject to congestion), this will not work: under congestion, some amount of that traffic will be dropped, often rendering the remaining packets as undecodable garbage clogging up the network in AD-2; because this traffic is not congestion aware, the loss does not reduce this rate. Competing traffic will not get their fair share under congestion, and EUs will be frustrated by the extremely bad quality of both their IP multicast traffic and other (e.g., TCP) traffic. Note that this is not an IP multicast technology issue but is solely a transport-layer / application-layer issue: the problem would just as likely happen if AD-1 were to send non-rate-adaptive unicast traffic -- for example, legacy IPTV video-on-demand traffic, which is typically also non-congestion aware. Note that because rate adaptation in IP unicast video is commonplace today due to the availability of ABR (Adaptive Bitrate) video, it is very unlikely that this will happen in reality with IP unicast.
如果端到端IP多播流量通过两个ADs（及其子公司/客户）的网络，则两个ADs必须就一致的流量管理策略达成一致。例如，如果AD-1产生无拥塞感知的IP多播流量，而AD-2将其作为尽力而为的流量通过与其他Internet流量共享的链路（受拥塞影响）进行传输，这将不起作用：在拥塞情况下，一定数量的该流量将被丢弃，在AD-2中，经常将剩余的数据包作为不可编码的垃圾阻塞网络；由于该流量不知道拥塞情况，因此损失不会降低该速率。在拥塞情况下，竞争流量将无法获得公平份额，EUs将因其IP多播流量和其他（如TCP）流量的质量极差而受挫。请注意，这不是IP多播技术问题，而仅仅是传输层/应用层问题：如果AD-1发送非速率自适应单播流量（例如，传统IPTV视频点播流量，通常也是无拥塞感知的），则该问题同样可能发生。请注意，由于ABR（自适应比特率）视频的可用性，IP单播视频中的速率自适应如今已司空见惯，因此IP单播视频中的这种情况在现实中不太可能发生。
While the rules for traffic management apply whether IP multicast is tunneled or not, the one feature that can make AMT tunnels more difficult is the unpredictability of bandwidth requirements across underlying links because of the way they can be used: with native IP
尽管流量管理规则适用于IP多播是否隧道化，但可能使AMT隧道更加困难的一个特性是，由于使用方式的不同，底层链路的带宽需求不可预测：使用本机IP
multicast or GRE tunnels, the amount of bandwidth depends on the amount of content -- not the number of EUs -- and is therefore easier to plan for. AMT tunnels terminating in the EU/G, on the other hand, scale with the number of EUs. In the vicinity of the AMT relay, they can introduce a very large amount of replicated traffic, and it is not always feasible to provision enough bandwidth for all possible EUs to get the highest quality for all their content during peak utilization in such setups -- unless the AMT relays are very close to the EU edge. Therefore, it is also recommended that IP multicast rate adaptation be used, even inside controlled networks, when using AMT tunnels directly to the EU/G.
多播或GRE隧道，带宽的大小取决于内容的数量，而不是EU的数量，因此更容易计划。另一方面，终止于EU/G的AMT隧道随着EU的数量而扩展。在AMT中继附近，它们可以引入大量的复制流量，并且在这种设置中，为所有可能的EU提供足够的带宽以在峰值利用率期间为其所有内容获得最高质量并不总是可行的，除非AMT中继非常接近EU边缘。因此，当直接使用AMT隧道到EU/G时，也建议使用IP多播速率自适应，即使在受控网络内也是如此。
Note that rate-adaptive IP multicast traffic in general does not mean that the sender is reducing the bitrate but rather that the EUs that experience congestion are joining to a lower-bitrate (S,G) stream of the content, similar to ABR streaming over TCP. Therefore, migration from a non-rate-adaptive bitrate to a rate-adaptive bitrate in IP multicast will also change the dynamic (S,G) join behavior in the network, resulting in potentially higher performance requirements for IP multicast protocols (IGMP/PIM), especially on the last hops where dynamic changes occur (including AMT gateways/relays): in non-rate-adaptive IP multicast, only "channel change" causes state change, but in rate-adaptive multicast, congestion also causes state change.
注意，速率自适应IP多播流量通常并不意味着发送方正在降低比特率，而是意味着经历拥塞的EUs正在加入到较低比特率（S，G）的内容流，类似于TCP上的ABR流。因此，在IP多播中，从非速率自适应比特率迁移到速率自适应比特率也将改变网络中的动态（S，G）连接行为，从而导致对IP多播协议（IGMP/PIM）的潜在更高性能要求，特别是在发生动态变化的最后一跳（包括AMT网关/中继）上：在非速率自适应IP组播中，只有“信道改变”引起状态改变，而在速率自适应组播中，拥塞也引起状态改变。
Even though not fully specified in this document, peerings that rely on GRE/AMT tunnels may be across one or more transit ADs instead of an exclusive (non-shared, L1/L2) path. Unless those transit ADs are explicitly contracted to provide other than "best effort" transit for the tunneled traffic, the tunneled IP multicast traffic must be rate adaptive in order to not violate BCP 41 across those transit ADs.
即使本文档中未完全规定，依赖GRE/AMT隧道的对等可能跨越一个或多个公交广告，而不是独占（非共享，L1/L2）路径。除非这些传输广告明确约定为隧道传输提供除“尽力”传输以外的传输，否则隧道IP多播传输必须是速率自适应的，以便在这些传输广告中不违反BCP 41。
The main objective for multicast delivery routing is to ensure that the EU receives the multicast stream from the "most optimal" source [INF_ATIS_10], which typically:
多播传送路由的主要目标是确保EU从“最佳”源[INF_ATIS_10]接收多播流，通常：
o Maximizes the multicast portion of the transport and minimizes any unicast portion of the delivery, and
o 最大化传输的多播部分并最小化传送的任何单播部分，以及
o Minimizes the overall combined route distance of the network(s).
o 最小化网络的总组合路由距离。
This routing objective applies to both native multicast and AMT; the actual methodology of the solution will be different for each. Regardless, the routing solution is expected to:
该路由目标同时适用于本地多播和AMT；每个解决方案的实际方法都会有所不同。无论如何，路由解决方案应：
o Be scalable,
o 可扩展，
o Avoid or minimize new protocol development or modifications, and
o 避免或尽量减少新协议的开发或修改，以及
o Be robust enough to achieve high reliability and to automatically adjust to changes and problems in the multicast infrastructure.
o 足够健壮，以实现高可靠性，并自动调整以适应多播基础结构中的变化和问题。
For both native and AMT environments, having a source as close as possible to the EU network is most desirable; therefore, in some cases, an AD may prefer to have multiple sources near different peering points. However, that is entirely an implementation issue.
对于本机和AMT环境，最理想的情况是使源尽可能靠近欧盟网络；因此，在某些情况下，AD可能更喜欢在不同的对等点附近具有多个源。然而，这完全是一个执行问题。
Native multicast simply requires that the administrative domains coordinate and advertise the correct source address(es) at their network interconnection peering points (i.e., BRs). An example of multicast delivery via a native multicast process across two administrative domains is as follows, assuming that the interconnecting peering points are also multicast enabled:
本机多播只需要管理域在其网络互连对等点（即BRs）协调并公布正确的源地址。假设互连对等点也启用了多播，则通过跨两个管理域的本机多播进程进行多播交付的示例如下：
o Appropriate information is obtained by the EU client, who is a subscriber to AD-2 (see Use Case 3.1). This information is in the form of metadata, and it contains instructions directing the EU client to launch an appropriate application if necessary, as well as additional information for the application about the source location and the group (or stream) ID in the form of (S,G) data. The "S" portion provides the name or IP address of the source of the multicast stream. The metadata may also contain alternate delivery information, such as specifying the unicast address of the stream.
o 适当的信息由作为AD-2订户的EU客户获得（参见用例3.1）。此信息以元数据的形式存在，其中包含指示EU客户端在必要时启动适当应用程序的说明，以及（S，G）数据形式的应用程序源位置和组（或流）ID的附加信息。“S”部分提供多播流的源的名称或IP地址。元数据还可以包含替代传递信息，例如指定流的单播地址。
o The client uses the join message with (S,G) to join the multicast stream [RFC4604]. To facilitate this process, the two ADs need to do the following:
o 客户端使用带有（S，G）的加入消息加入多播流[RFC4604]。为促进此过程，两个广告需要执行以下操作：
* Advertise the source ID(s) over the peering points.
* 在对等点上公布源ID。
* Exchange such relevant peering point information as capacity and utilization.
* 交换容量和利用率等相关对等点信息。
* Implement compatible multicast protocols to ensure proper multicast delivery across the peering points.
* 实现兼容的多播协议，以确保跨对等点的正确多播交付。
If the interconnecting peering point is not multicast enabled and both ADs are multicast enabled, then a simple solution is to provision a GRE tunnel between the two ADs; see Use Case 3.2 (Section 3.2). The termination points of the tunnel will usually be a network engineering decision but generally will be between the BRs or even between the AD-2 BR and the AD-1 source (or source access router). The GRE tunnel would allow end-to-end native multicast or AMT multicast to traverse the interface. Coordination and advertisement of the source IP are still required.
如果互连对等点未启用多播且两个ADs均启用多播，则简单的解决方案是在两个ADs之间提供GRE隧道；参见用例3.2（第3.2节）。隧道的终止点通常是网络工程决策，但通常在BRs之间，甚至在AD-2 BR和AD-1源（或源访问路由器）之间。GRE隧道将允许端到端本地多播或AMT多播穿越接口。仍然需要协调和公布源IP。
The two ADs need to follow the same process as the process described in Section 4.2.1 to facilitate multicast delivery across the peering points.
这两个ADs需要遵循与第4.2.1节中描述的过程相同的过程，以促进跨对等点的多播交付。
Unlike native multicast (with or without GRE), an AMT multicast environment is more complex. It presents a two-layered problem in that there are two criteria that should be simultaneously met:
与本机多播（带或不带GRE）不同，AMT多播环境更复杂。它提出了一个两层问题，即应同时满足两个标准：
o Find the closest AMT relay to the EU that also has multicast connectivity to the content source, and
o 查找与EU最近的AMT中继，该中继还具有与内容源的多播连接，以及
o Minimize the AMT unicast tunnel distance.
o 最小化AMT单播隧道距离。
There are essentially two components in the AMT specification:
AMT规范中基本上有两个部分：
AMT relays: These serve the purpose of tunneling UDP multicast traffic to the receivers (i.e., endpoints). The AMT relay will receive the traffic natively from the multicast media source and will replicate the stream on behalf of the downstream AMT gateways, encapsulating the multicast packets into unicast packets and sending them over the tunnel toward the AMT gateways. In addition, the AMT relay may collect various usage and activity statistics. This results in moving the replication point closer to the EU and cuts down on traffic across the network. Thus, the linear costs of adding unicast subscribers can be avoided. However, unicast replication is still required for each requesting endpoint within the unicast-only network.
AMT中继：这些中继用于将UDP多播流量隧道传输到接收器（即端点）。AMT中继将从多播媒体源本地接收流量，并代表下游AMT网关复制流，将多播数据包封装为单播数据包，并通过隧道将其发送到AMT网关。此外，AMT继电器可以收集各种使用和活动统计信息。这将使复制点更靠近EU，并减少网络上的通信量。因此，可以避免添加单播订户的线性成本。但是，对于仅单播网络中的每个请求端点，仍然需要单播复制。
AMT gateway: The gateway will reside on an endpoint; this could be any type of IP host, such as a Personal Computer (PC), mobile phone, Set-Top Box (STB), or appliances. The AMT gateway receives join and leave requests from the application via an Application Programming Interface (API). In this manner, the gateway allows the endpoint to conduct itself as a true multicast endpoint. The
AMT网关：网关将驻留在端点上；这可以是任何类型的IP主机，例如个人计算机（PC）、移动电话、机顶盒（STB）或设备。AMT网关通过应用程序编程接口（API）接收来自应用程序的加入和离开请求。通过这种方式，网关允许端点作为真正的多播端点进行自身行为。这个
AMT gateway will encapsulate AMT messages into UDP packets and send them through a tunnel (across the unicast-only infrastructure) to the AMT relay.
AMT网关将AMT消息封装到UDP数据包中，并通过隧道（仅通过单播基础设施）将其发送到AMT中继。
The simplest AMT use case (Section 3.3) involves peering points that are not multicast enabled between two multicast-enabled ADs. An AMT tunnel is deployed between an AMT relay on the AD-1 side of the peering point and an AMT gateway on the AD-2 side of the peering point. One advantage of this arrangement is that the tunnel is established on an as-needed basis and need not be a provisioned element. The two ADs can coordinate and advertise special AMT relay anycast addresses with, and to, each other. Alternately, they may decide to simply provision relay addresses, though this would not be an optimal solution in terms of scalability.
最简单的AMT用例（第3.3节）涉及两个启用多播的ADs之间未启用多播的对等点。AMT隧道部署在对等点AD-1侧的AMT中继和对等点AD-2侧的AMT网关之间。这种安排的一个优点是，隧道是在需要的基础上建立的，并且不需要是供应的元素。这两个ADs可以相互协调和发布特殊AMT中继选播地址。或者，他们可能决定只提供中继地址，尽管这在可伸缩性方面不是最佳解决方案。
Use Cases 3.4 and 3.5 describe AMT situations that are more complicated, as AD-2 is not multicast enabled in these two cases. For these cases, the EU device needs to be able to set up an AMT tunnel in the most optimal manner. There are many methods by which relay selection can be done, including the use of DNS-based queries and static lookup tables [RFC7450]. The choice of the method is implementation dependent and is up to the network operators. Comparison of various methods is out of scope for this document and is left for further study.
用例3.4和3.5描述了更复杂的AMT情况，因为在这两种情况下AD-2没有启用多播。对于这些情况，欧盟设备需要能够以最佳方式设置AMT隧道。有许多方法可以进行中继选择，包括使用基于DNS的查询和静态查找表[RFC7450]。方法的选择取决于实现，由网络运营商决定。各种方法的比较超出了本文件的范围，有待进一步研究。
An illustrative example of a relay selection based on DNS queries as part of an anycast IP address process is described here for Use Cases 3.4 and 3.5 (Sections 3.4 and 3.5). Using an anycast IP address for AMT relays allows all AMT gateways to find the "closest" AMT relay -- the nearest edge of the multicast topology of the source. Note that this is strictly illustrative; the choice of the method is up to the network operators. The basic process is as follows:
对于用例3.4和3.5（第3.4和3.5节），这里描述了基于DNS查询的中继选择的示例，作为选播IP地址过程的一部分。对AMT中继使用选播IP地址允许所有AMT网关找到“最近的”AMT中继——源的多播拓扑的最近边缘。请注意，这是严格的说明；该方法的选择取决于网络运营商。基本流程如下：
o Appropriate metadata is obtained by the EU client application. The metadata contains instructions directing the EU client to an ordered list of particular destinations to seek the requested stream and, for multicast, specifies the source location and the group (or stream) ID in the form of (S,G) data. The "S" portion provides the URI (name or IP address) of the source of the multicast stream, and the "G" identifies the particular stream originated by that source. The metadata may also contain alternate delivery information such as the address of the unicast form of the content to be used -- for example, if the multicast stream becomes unavailable.
o 适当的元数据由EU客户端应用程序获取。元数据包含指示EU客户端到特定目的地的有序列表以查找请求流的指令，对于多播，以（S，G）数据的形式指定源位置和组（或流）ID。“S”部分提供多播流的源的URI（名称或IP地址），“G”标识由该源发起的特定流。元数据还可以包含备用传递信息，例如要使用的内容的单播形式的地址——例如，如果多播流变得不可用。
o Using the information from the metadata and, possibly, information provisioned directly in the EU client, a DNS query is initiated in order to connect the EU client / AMT gateway to an AMT relay.
o 使用元数据中的信息以及直接在EU客户端中提供的信息（可能），启动DNS查询，以便将EU客户端/AMT网关连接到AMT中继。
o Query results are obtained and may return an anycast address or a specific unicast address of a relay. Multiple relays will typically exist. The anycast address is a routable "pseudo-address" shared among the relays that can gain multicast access to the source.
o 获得查询结果，并可返回选播地址或中继器的特定单播地址。通常会存在多个继电器。选播地址是中继之间共享的可路由“伪地址”，可以获得对源的多播访问。
o If a specific IP address unique to a relay was not obtained, the AMT gateway then sends a message (e.g., the discovery message) to the anycast address such that the network is making the routing choice of a particular relay, e.g., the relay that is closest to the EU. Details are outside the scope of this document. See [RFC4786].
o 如果未获得中继器特有的特定IP地址，则AMT网关随后向选播地址发送消息（例如，发现消息），使得网络正在对特定中继器（例如，最靠近EU的中继器）进行路由选择。详细信息不在本文件范围内。见[RFC4786]。
o The contacted AMT relay then returns its specific unicast IP address (after which the anycast address is no longer required). Variations may exist as well.
o 然后，所联系的AMT中继返回其特定的单播IP地址（之后不再需要选播地址）。变化也可能存在。
o The AMT gateway uses that unicast IP address to initiate a three-way handshake with the AMT relay.
o AMT网关使用该单播IP地址启动与AMT中继的三方握手。
o The AMT gateway provides the (S,G) information to the AMT relay (embedded in AMT protocol messages).
o AMT网关向AMT中继（嵌入在AMT协议消息中）提供（S，G）信息。
o The AMT relay receives the (S,G) information and uses it to join the appropriate multicast stream, if it has not already subscribed to that stream.
o AMT中继接收（S，G）信息并使用它加入适当的多播流（如果它尚未订阅该流）。
o The AMT relay encapsulates the multicast stream into the tunnel between the relay and the gateway, providing the requested content to the EU.
o AMT中继将多播流封装到中继和网关之间的隧道中，向EU提供请求的内容。
Figure 6 shows an example of a broadcast peering point.
图6显示了广播对等点的示例。
AD-1a AD-1b
BR BR
| |
--+-+---------------+-+-- broadcast peering point LAN
| |
BR BR
AD-2a AD-2b
AD-1a AD-1b
BR BR
| |
--+-+---------------+-+-- broadcast peering point LAN
| |
BR BR
AD-2a AD-2b
Figure 6: Broadcast Peering Point
图6：广播对等点
A broadcast peering point is an L2 subnet connecting three or more ADs. It is common in IXPs and usually consists of Ethernet switch(es) operated by the IXP connecting to BRs operated by the ADs.
广播对等点是连接三个或更多ADs的L2子网。它在IXPs中很常见，通常由IXP操作的以太网交换机组成，连接到ADs操作的BRs。
In an example setup domain, AD-2a peers with AD-1a and wants to receive IP multicast from it. Likewise, AD-2b peers with AD-1b and wants to receive IP multicast from it.
在示例设置域中，AD-2a与AD-1a对等，并希望从AD-1a接收IP多播。同样，AD-2b与AD-1b对等，并希望从AD-1b接收IP多播。
Assume that one or more IP multicast (S,G) traffic streams can be served by both AD-1a and AD-1b -- for example, because both AD-1a and AD-1b contact this content from the same content source.
假设一个或多个IP多播（S，G）业务流可以由AD-1a和AD-1b提供服务——例如，因为AD-1a和AD-1b都从同一内容源联系该内容。
In this case, AD-2a and AD-2b can no longer control which upstream domain -- AD-1a or AD-1b -- will forward this (S,G) into the LAN. The AD-2a BR requests the (S,G) from the AD-1a BR, and the AD-2b BR requests the same (S,G) from the AD-1b BR. To avoid duplicate packets, an (S,G) can be forwarded by only one router onto the LAN; PIM-SM / PIM-SSM detects requests for duplicate transmissions and resolves them via the so-called "assert" protocol operation, which results in only one BR forwarding the traffic. Assume that this is the AD-1a BR. AD-2b will then receive unexpected multicast traffic from a provider with whom it does not have a mutual agreement for that traffic. Quality issues in EUs behind AD-2b caused by AD-1a will cause a lot of issues related to responsibility and troubleshooting.
在这种情况下，AD-2a和AD-2b不能再控制哪个上游域——AD-1a或AD-1b——将该（S，G）转发到LAN。AD-2a BR从AD-1a BR请求（S，G），AD-2b BR从AD-1b BR请求相同的（S，G）。为了避免重复数据包，一个（S，G）只能由一个路由器转发到局域网上；PIM-SM/PIM-SSM检测重复传输的请求，并通过所谓的“断言”协议操作解决这些请求，这只会导致一个BR转发流量。假设这是AD-1a BR。然后，AD-2b将接收来自提供商的意外多播流量，而该提供商与AD-2b没有关于该流量的共同协议。AD-1a引起的AD-2b后面的EUs中的质量问题将导致许多与责任和故障排除相关的问题。
In light of these technical issues, we describe, via the following options, how IP multicast can be carried across broadcast peering point LANs:
鉴于这些技术问题，我们将通过以下选项描述如何跨广播对等点LAN进行IP多播：
1. IP multicast is tunneled across the LAN. Any of the GRE/AMT tunneling solutions mentioned in this document are applicable. This is the one case where a GRE tunnel between the upstream BR (e.g., AD-1a) and downstream BR (e.g., AD-2a) is specifically recommended, as opposed to tunneling across uBRs (which are not the actual BRs).
1. IP多播通过局域网进行隧道传输。本文件中提及的任何GRE/AMT隧道解决方案均适用。这是一种特别建议在上游BR（如AD-1a）和下游BR（如AD-2a）之间修建GRE隧道的情况，而不是穿过UBR（不是实际的BRs）的隧道。
2. The LAN has only one upstream AD that is sourcing IP multicast, and native IP multicast is used. This is an efficient way to distribute the same IP multicast content to multiple downstream ADs. Misbehaving downstream BRs can still disrupt the delivery of IP multicast from the upstream BR to other downstream BRs; therefore, strict rules must be followed to prohibit such a case. The downstream BRs must ensure that they will always consider only the upstream BR as a source for multicast traffic: e.g., no BGP SAFI-2 peerings between the downstream ADs across the peering point LAN, so that the upstream BR is the only possible next hop reachable across this LAN. Also, routing policies can be
2. LAN只有一个上游AD是源IP多播，并且使用本机IP多播。这是将同一IP多播内容分发给多个下游广告的有效方法。行为不端的下游BR仍会中断从上游BR到其他下游BR的IP多播传送；因此，必须遵守严格的规则来禁止这种情况。下游的BRS必须确保它们总是只考虑上游BR作为多播业务的来源：例如，在对等点LAN之间的下游广告之间没有BGP SAFI-2 Pees，因此上游BR是在整个LAN上唯一可到达的下一跳。此外，路由策略也可以是
configured to avoid falling back to using SAFI-1 (unicast) routes for IP multicast if unicast BGP peering is not limited in the same way.
配置为在单播BGP对等不受相同限制的情况下，避免退回使用SAFI-1（单播）路由进行IP多播。
3. The LAN has multiple upstream ADs, but they are federated and agree on a consistent policy for IP multicast traffic across the LAN. One policy is that each possible source is only announced by one upstream BR. Another policy is that sources are redundantly announced (the problematic case mentioned in the example in Figure 6 above), but the upstream domains also provide mutual operational insight to help with troubleshooting (outside the scope of this document).
3. LAN有多个上游ADs，但它们是联合的，并就跨LAN的IP多播流量的一致策略达成一致。一项政策是，每个可能的来源仅由一个上游BR宣布。另一个策略是冗余地宣布源（上图6中的示例中提到的问题案例），但上游域也提供相互操作洞察力以帮助进行故障排除（不在本文档的范围内）。
"Back office" refers to the following:
“后台”指以下各项：
o Servers and content-management systems that support the delivery of applications via multicast and interactions between ADs.
o 支持通过多播和ADs之间的交互交付应用程序的服务器和内容管理系统。
o Functionality associated with logging, reporting, ordering, provisioning, maintenance, service assurance, settlement, etc.
o 与日志记录、报告、订购、供应、维护、服务保证、结算等相关的功能。
Resources for basic connectivity between ADs' providers need to be provisioned as follows:
ADs提供商之间的基本连接资源需要按如下方式配置：
o Sufficient capacity must be provisioned to support multicast-based delivery across ADs.
o 必须提供足够的容量，以支持跨ADs的基于多播的交付。
o Sufficient capacity must be provisioned for connectivity between all supporting back offices of the ADs as appropriate. This includes activating proper security treatment for these back-office connections (gateways, firewalls, etc.) as appropriate.
o 必须为ADs的所有支持后台办公室之间的连接提供足够的容量（视情况而定）。这包括根据需要为这些后台连接（网关、防火墙等）激活适当的安全处理。
Provisioning aspects related to multicast-based inter-domain delivery are as follows.
与基于多播的域间交付相关的供应方面如下所示。
The ability to receive a requested application via multicast is triggered via receipt of the necessary metadata. Hence, this metadata must be provided to the EU regarding the multicast URL -- and unicast fallback if applicable. AD-2 must enable the delivery of this metadata to the EU and provision appropriate resources for this purpose.
通过多播接收请求的应用程序的能力是通过接收必要的元数据触发的。因此，必须向欧盟提供有关多播URL的元数据——以及单播回退（如果适用）。AD-2必须能够向欧盟交付此元数据，并为此目的提供适当的资源。
It is assumed that native multicast functionality is available across many ISP backbones, peering points, and access networks. If, however, native multicast is not an option (Use Cases 3.4 and 3.5), then:
假定本机多播功能可跨许多ISP主干网、对等点和接入网络使用。但是，如果本机多播不是一个选项（用例3.4和3.5），则：
o The EU must have a multicast client to use AMT multicast obtained from either (1) the application source (per agreement with AD-1) or (2) AD-1 or AD-2 (if delegated by the application source).
o 欧盟必须有一个多播客户端，才能使用从（1）应用程序源（根据与AD-1的协议）或（2）AD-1或AD-2（如果由应用程序源授权）获得的AMT多播。
o If provided by AD-1 or AD-2, then the EU could be redirected to a client download site. (Note: This could be an application source site.) If provided by the application source, then this source would have to coordinate with AD-1 to ensure that the proper client is provided (assuming multiple possible clients).
o 如果由AD-1或AD-2提供，则可以将EU重定向到客户端下载站点。（注意：这可能是一个应用程序源站点。）如果由应用程序源提供，则该源必须与AD-1协调，以确保提供正确的客户端（假设有多个可能的客户端）。
o Where AMT gateways support different application sets, all AD-2 AMT relays need to be provisioned with all source and group addresses for streams it is allowed to join.
o 如果AMT网关支持不同的应用程序集，则所有AD-2 AMT中继都需要为允许加入的流提供所有源地址和组地址。
o DNS across each AD must be provisioned to enable a client gateway to locate the optimal AMT relay (i.e., longest multicast path and shortest unicast tunnel) with connectivity to the content's multicast source.
o 必须设置每个AD上的DNS，以使客户端网关能够找到与内容的多播源连接的最佳AMT中继（即最长多播路径和最短单播隧道）。
Provisioning aspects related to operations and customer care are as follows.
与运营和客户服务相关的资源调配方面如下所示。
It is assumed that each AD provider will provision operations and customer care access to their own systems.
假设每个广告提供商将提供对其自身系统的运营和客户服务访问。
AD-1's operations and customer care functions must be able to see enough of what is happening in AD-2's network or in the service provided by AD-2 to verify their mutual goals and operations, e.g., to know how the EUs are being served. This can be done in two ways:
AD-1的运营和客户服务职能部门必须能够充分了解AD-2网络或AD-2提供的服务中发生的情况，以验证其共同目标和运营，例如，了解EUs的服务方式。这可以通过两种方式实现：
o Automated interfaces are built between AD-1 and AD-2 such that operations and customer care continue using their own systems. This requires coordination between the two ADs, with appropriate provisioning of necessary resources.
o AD-1和AD-2之间建立了自动化接口，以便运营和客户服务继续使用自己的系统。这需要两个ADs之间进行协调，并适当提供必要的资源。
o AD-1's operations and customer care personnel are provided direct access to AD-2's systems. In this scenario, additional provisioning in these systems will be needed to provide necessary access. The two ADs must agree on additional provisioning to support this option.
o AD-1的运营和客户服务人员可直接访问AD-2的系统。在这种情况下，需要在这些系统中进行额外的资源调配，以提供必要的访问。两个ADs必须就支持此选项的附加资源调配达成一致。
All interactions between pairs of ADs can be discovered and/or associated with the account(s) utilized for delivered applications. Supporting guidelines are as follows:
可以发现广告对之间的所有交互和/或与交付应用程序所使用的帐户相关联。支持准则如下：
o A unique identifier is recommended to designate each master account.
o 建议使用唯一标识符来指定每个主帐户。
o AD-2 is expected to set up "accounts" (a logical facility generally protected by credentials such as login passwords) for use by AD-1. Multiple accounts, and multiple types or partitions of accounts, can apply, e.g., customer accounts, security accounts.
o AD-2预计将设置“帐户”（通常由登录密码等凭据保护的逻辑设施）供AD-1使用。可以应用多个帐户以及多种类型或分区的帐户，例如客户帐户、安全帐户。
The reason to specifically mention the need for AD-1 to initiate interactions with AD-2 (and use some account for that), as opposed to the opposite, is based on the recommended workflow initiated by customers (see Section 4.4): the customer contacts the content source, which is part of AD-1. Consequently, if AD-1 sees the need to escalate the issue to AD-2, it will interact with AD-2 using the aforementioned guidelines.
特别提到AD-1需要启动与AD-2的交互（并为此使用一些帐户）的原因是基于客户启动的推荐工作流（参见第4.4节）：客户联系内容源，这是AD-1的一部分。因此，如果AD-1认为需要将问题升级到AD-2，它将使用上述指南与AD-2互动。
Successful delivery (in terms of user experience) of applications or content via multicast between pairs of interconnecting ADs can be improved through the ability to exchange appropriate logs for various workflows -- troubleshooting, accounting and billing, optimization of traffic and content transmission, optimization of content and application development, and so on.
通过在相互连接的广告对之间通过多播成功交付（就用户体验而言）应用程序或内容，可以通过为各种工作流交换适当日志的能力来改进——故障排除、记帐和计费、流量优化和内容传输，内容优化和应用程序开发等。
Specifically, AD-1 take over primary responsibility for customer experience on behalf of the content source, with support from AD-2 as needed. The application/content owner is the only participant who has, and needs, full insight into the application level and can map the customer application experience to the network traffic flows -- which, with the help of AD-2 or logs from AD-2, it can then analyze and interpret.
具体而言，AD-1代表内容源承担客户体验的主要责任，并根据需要提供AD-2的支持。应用程序/内容所有者是唯一一个对应用程序级别有全面了解并且需要全面了解应用程序级别的参与者，可以将客户应用程序体验映射到网络流量——在AD-2或AD-2日志的帮助下，它可以分析和解释网络流量。
The main difference between unicast delivery and multicast delivery is that the content source can infer a lot more about downstream network problems from a unicast stream than from a multicast stream: the multicast stream is not per EU, except after the last replication, which is in most cases not in AD-1. Logs from the application, including the receiver side at the EU, can provide insight but cannot help to fully isolate network problems because of
单播传送和多播传送之间的主要区别在于，内容源可以从单播流而不是从多播流中推断出更多关于下游网络问题的信息：多播流不是每EU的，除非在最后一次复制之后，这在大多数情况下不是在AD-1中。来自应用程序（包括EU的接收方）的日志可以提供洞察力，但无法帮助完全隔离网络问题，因为
the IP multicast per-application operational state built across AD-1 and AD-2 (aka the (S,G) state and any other operational-state features, such as Diffserv QoS).
跨AD-1和AD-2构建的每个应用程序的IP多播操作状态（也称为（S，G）状态和任何其他操作状态功能，如Diffserv QoS）。
See Section 7 for more discussion regarding the privacy considerations of the model described here.
有关此处所述模型的隐私注意事项的更多讨论，请参见第7节。
Different types of logs are known to help support operations in AD-1 when provided by AD-2. This could be done as part of AD-1/AD-2 contracts. Note that except for implied multicast-specific elements, the options listed here are not unique or novel for IP multicast, but they are more important for services novel to the operators than for operationally well-established services (such as unicast). We therefore detail them as follows:
当AD-2提供时，已知不同类型的日志有助于支持AD-1中的操作。这可以作为AD-1/AD-2合同的一部分。请注意，除了隐含的多播特定元素外，此处列出的选项对于IP多播来说不是唯一的或新颖的，但是对于运营商来说是新颖的服务，它们比对于运营良好的服务（例如单播）更重要。因此，我们将其详述如下：
o Usage information logs at an aggregate level.
o 聚合级别的使用信息日志。
o Usage failure instances at an aggregate level.
o 聚合级别上的使用失败实例。
o Grouped or sequenced application access: performance, behavior, and failure at an aggregate level to support potential application-provider-driven strategies. Examples of aggregate levels include grouped video clips, web pages, and software-download sets.
o 分组或顺序应用程序访问：聚合级别的性能、行为和故障，以支持潜在的应用程序提供商驱动的策略。聚合级别的示例包括分组视频剪辑、网页和软件下载集。
o Security logs, aggregated or summarized according to agreement (with additional detail potentially provided during security events, by agreement).
o 根据协议汇总或汇总的安全日志（根据协议，在安全事件期间可能提供其他详细信息）。
o Access logs (EU), when needed for troubleshooting.
o 当需要进行故障排除时，访问日志（EU）。
o Application logs ("What is the application doing?"), when needed for shared troubleshooting.
o 当需要共享故障排除时，应用程序日志（“应用程序在做什么？”）。
o Syslogs (network management), when needed for shared troubleshooting.
o 系统日志（网络管理），用于共享故障排除。
The two ADs may supply additional security logs to each other, as agreed upon in contract(s). Examples include the following:
根据合同约定，两个ADs可相互提供额外的安全日志。例子包括：
o Information related to general security-relevant activity, which may be of use from a protection or response perspective: types and counts of attacks detected, related source information, related target information, etc.
o 与一般安全相关活动相关的信息，从保护或响应角度来看可能有用：检测到的攻击类型和计数、相关源信息、相关目标信息等。
o Aggregated or summarized logs according to agreement (with additional detail potentially provided during security events, by agreement).
o 根据协议汇总或汇总日志（根据协议，在安全事件期间可能提供额外的详细信息）。
"Service performance" refers to monitoring metrics related to multicast delivery via probes. The focus is on the service provided by AD-2 to AD-1 on behalf of all multicast application sources (metrics may be specified for SLA use or otherwise). Associated guidelines are as follows:
“服务性能”是指通过探测监控与多播交付相关的指标。重点是AD-2向AD-1代表所有多播应用程序源提供的服务（可以为SLA使用或其他方式指定指标）。有关指引如下：
o Both ADs are expected to monitor, collect, and analyze service performance metrics for multicast applications. AD-2 provides relevant performance information to AD-1; this enables AD-1 to create an end-to-end performance view on behalf of the multicast application source.
o 这两个ADs都需要监控、收集和分析多播应用程序的服务性能指标。AD-2向AD-1提供相关性能信息；这使AD-1能够代表多播应用程序源创建端到端性能视图。
o Both ADs are expected to agree on the types of probes to be used to monitor multicast delivery performance. For example, AD-2 may permit AD-1's probes to be utilized in the AD-2 multicast service footprint. Alternately, AD-2 may deploy its own probes and relay performance information back to AD-1.
o 两个ADs预计将在用于监控多播交付性能的探测类型上达成一致。例如，AD-2可以允许在AD-2多播服务足迹中使用AD-1的探测。或者，AD-2可以部署自己的探测器，并将性能信息中继回AD-1。
"Service monitoring" generally refers to a service (as a whole) provided on behalf of a particular multicast application source provider. It thus involves complaints from EUs when service problems occur. EUs direct their complaints to the source provider; the source provider in turn submits these complaints to AD-1. The responsibility for service delivery lies with AD-1; as such, AD-1 will need to determine where the service problem is occurring -- in its own network or in AD-2. It is expected that each AD will have tools to monitor multicast service status in its own network.
“服务监控”通常是指代表特定多播应用程序源提供商提供的服务（作为一个整体）。因此，当服务出现问题时，EUs会提出投诉。EUs将其投诉直接提交给源供应商；源供应商将这些投诉提交给AD-1。AD-1负责提供服务；因此，AD-1需要确定服务问题发生在何处——在它自己的网络中还是在AD-2中。预计每个AD将有工具来监控其自身网络中的多播服务状态。
o Both ADs will determine how best to deploy multicast service monitoring tools. Typically, each AD will deploy its own set of monitoring tools, in which case both ADs are expected to inform each other when multicast delivery problems are detected.
o 这两个ADs将决定如何最好地部署多播服务监控工具。通常，每个广告都会部署自己的一组监控工具，在这种情况下，当检测到多播交付问题时，两个广告都会相互通知。
o AD-2 may experience some problems in its network. For example, for the AMT use cases (Sections 3.3, 3.4, and 3.5), one or more AMT relays may be experiencing difficulties. AD-2 may be able to fix the problem by rerouting the multicast streams via alternate AMT relays. If the fix is not successful and multicast service delivery degrades, then AD-2 needs to report the issue to AD-1.
o AD-2可能在其网络中遇到一些问题。例如，对于AMT用例（第3.3、3.4和3.5节），一个或多个AMT继电器可能遇到困难。AD-2可以通过通过交替AMT中继重新路由多播流来解决该问题。如果修复不成功且多播服务交付降级，则AD-2需要向AD-1报告该问题。
o When a problem notification is received from a multicast application source, AD-1 determines whether the cause of the problem is within its own network or within AD-2. If the cause is within AD-2, then AD-1 supplies all necessary information to AD-2. Examples of supporting information include the following:
o 当从多播应用程序源接收到问题通知时，AD-1确定问题的原因是在其自己的网络内还是在AD-2内。如果原因在AD-2范围内，则AD-1向AD-2提供所有必要的信息。支持信息的示例包括：
* Kind(s) of problem(s).
* 问题的种类。
* Starting point and duration of problem(s).
* 问题的起点和持续时间。
* Conditions in which one or more problems occur.
* 出现一个或多个问题的情况。
* IP address blocks of affected users.
* 受影响用户的IP地址块。
* ISPs of affected users.
* 受影响用户的ISP。
* Type of access, e.g., mobile versus desktop.
* 访问类型，例如，移动与桌面。
* Network locations of affected EUs.
* 受影响EUs的网络位置。
o Both ADs conduct some form of root-cause analysis for multicast service delivery problems. Examples of various factors for consideration include:
o 两个ADs都对多播服务交付问题进行某种形式的根本原因分析。需要考虑的各种因素包括：
* Verification that the service configuration matches the product features.
* 验证服务配置是否与产品功能匹配。
* Correlation and consolidation of the various customer problems and resource troubles into a single root-service problem.
* 将各种客户问题和资源问题关联并整合为单个根服务问题。
* Prioritization of currently open service problems, giving consideration to problem impacts, SLAs, etc.
* 优先处理当前未解决的服务问题，考虑问题影响、SLA等。
* Conducting service tests, including tests performed once or a series of tests over a period of time.
* 进行服务测试，包括在一段时间内进行一次或一系列测试。
* Analysis of test results.
* 测试结果分析。
* Analysis of relevant network fault or performance data.
* 分析相关网络故障或性能数据。
* Analysis of the problem information provided by the customer.
* 分析客户提供的问题信息。
o Once the cause of the problem has been determined and the problem has been fixed, both ADs need to work jointly to verify and validate the success of the fix.
o 一旦确定了问题的原因并修复了问题，两个ADs需要共同工作以验证和验证修复是否成功。
There are multiple options for instituting reliability architectures. Most are at the application level. Both ADs should work these options out per their contract or agreement and also with the multicast application source providers.
建立可靠性体系结构有多种选择。大多数都在应用程序级别。两个ADs都应该根据他们的合同或协议以及多播应用程序源提供商制定这些选项。
Network reliability can also be enhanced by the two ADs if they provision alternate delivery mechanisms via unicast means.
如果两个ADs通过单播方式提供备用的传送机制，则它们也可以增强网络可靠性。
Application-level accounting needs to be handled differently in the application than in IP unicast, because the source side does not directly deliver packets to individual receivers. Instead, this needs to be signaled back by the receiver to the source.
应用程序级计费需要在应用程序中以与IP单播不同的方式进行处理，因为源端不直接将数据包传递给各个接收器。相反，这需要由接收器向信号源发回信号。
For network transport diagnostics, AD-1 and AD-2 should have mechanisms in place to ensure proper accounting for the volume of bytes delivered through the peering point and, separately, the number of bytes delivered to EUs.
对于网络传输诊断，AD-1和AD-2应具有适当的机制，以确保正确计算通过对等点传输的字节量，以及单独计算传输到EUs的字节数。
Any service provider supporting multicast delivery of content should be able to collect diagnostics as part of multicast troubleshooting practices and resolve network issues accordingly. Issues may become apparent or identifiable through either (1) network monitoring functions or (2) problems reported by customers, as described in Section 4.4.
任何支持多播内容交付的服务提供商都应该能够收集诊断信息，作为多播故障排除实践的一部分，并相应地解决网络问题。问题可能通过（1）网络监控功能或（2）客户报告的问题变得明显或可识别，如第4.4节所述。
It is recommended that multicast diagnostics be performed, leveraging established operational practices such as those documented in [MDH-05]. However, given that inter-domain multicast creates a significant interdependence of proper networking functionality between providers, there exists a need for providers to be able to signal (or otherwise alert) each other if there are any issues noted by either one.
建议利用[MDH-05]中记录的既定操作实践，执行多播诊断。然而，鉴于域间多播在提供商之间建立了适当网络功能的重要相互依赖关系，因此，如果其中一个提供商发现任何问题，则需要提供商能够相互发出信号（或以其他方式发出警报）。
For troubleshooting purposes, service providers may also wish to allow limited read-only administrative access to their routers to their AD peers. Access to active troubleshooting tools -- especially [Traceroute] and the tools discussed in [Mtrace-v2] -- is of specific interest.
出于故障排除目的，服务提供商还可能希望允许其AD对等方对其路由器进行有限的只读管理访问。访问活动的故障排除工具——特别是[Traceroute]和[Mtrace-v2]中讨论的工具——具有特殊的意义。
Another option is to include this functionality in the IP multicast receiver application on the EU device and allow these diagnostics to be remotely used by support operations. Note, though, that AMT does not allow the passing of traceroute or mtrace requests; therefore, troubleshooting in the presence of AMT does not work as well end to end as it can with native (or even GRE-encapsulated) IP multicast, especially with regard to traceroute and mtrace. Instead, troubleshooting directly on the actual network devices is then more likely necessary.
另一个选项是在EU设备上的IP多播接收器应用程序中包含此功能，并允许支持操作远程使用这些诊断。但是请注意，AMT不允许传递跟踪路由或mtrace请求；因此，在存在AMT的情况下进行故障排除并不像在本机（甚至GRE封装的）IP多播上那样能够很好地进行端到端的工作，特别是在跟踪路由和mtrace方面。相反，更可能需要直接在实际网络设备上进行故障排除。
The specifics of notifications and alerts are beyond the scope of this document, but general guidelines are similar to those described in Section 4.4. Some general communications issues are as follows.
通知和警报的具体内容超出了本文件的范围，但一般指南与第4.4节所述的指南类似。一些一般通信问题如下。
o Appropriate communications channels will be established between the customer service and operations groups from both ADs to facilitate information-sharing related to diagnostic troubleshooting.
o 将在两个ADs的客户服务组和运营组之间建立适当的沟通渠道，以促进与诊断故障排除相关的信息共享。
o A default resolution period may be considered to resolve open issues. Alternately, mutually acceptable resolution periods could be established, depending on the severity of the identified trouble.
o 可以考虑使用默认的解决期来解决未决问题。或者，根据已识别故障的严重程度，可以建立双方都可以接受的解决周期。
Reliable IP multicast operations require some basic protection against DoS (Denial of Service) attacks.
可靠的IP多播操作需要一些针对DoS（拒绝服务）攻击的基本保护。
SSM IP multicast is self-protecting against attacks from illicit sources; such traffic will not be forwarded beyond the first-hop router, because that would require (S,G) membership reports from the receiver. Only valid traffic from sources will be forwarded, because RPF ("Reverse Path Forwarding") is part of the protocols. One can say that protection against spoofed source traffic performed in the style of [BCP38] is therefore built into PIM-SM / PIM-SSM.
SSM IP多播能够自我保护，防止来自非法来源的攻击；这样的流量将不会转发到第一跳路由器之外，因为这需要来自接收器的（S，G）成员报告。由于RPF（“反向路径转发”）是协议的一部分，因此只转发来自源的有效流量。可以说，PIM-SM/PIM-SSM中内置了对以[BCP38]方式执行的伪造源流量的保护。
Receivers can attack SSM IP multicast by originating such (S,G) membership reports. This can result in a DoS attack against state through the creation of a large number of (S,G) states that create high control-plane load or even inhibit the later creation of a valid (S,G). In conjunction with collaborating illicit sources, it can also result in the forwarding of traffic from illicit sources.
接收方可以通过发起此类（S，G）成员报告来攻击SSM IP多播。这可能会通过创建大量（S，G）状态来导致针对状态的DoS攻击，这些状态会创建高控制平面负载，甚至会禁止以后创建有效（S，G）状态。与合作的非法来源一起，它还可能导致来自非法来源的流量转运。
Today, these types of attacks are usually mitigated by explicitly defining the set of permissible (S,G) on, for example, the last-hop routers in replicating IP multicast to EUs (e.g., via (S,G) access control lists applied to IGMP/MLD membership state creation). Each AD (say, "ADi") is expected to know what sources located in ADi are permitted to send and what their valid (S,G)s are. ADi can therefore also filter invalid (S,G)s for any "S" located inside ADi, but not sources located in another AD.
如今，这些类型的攻击通常通过明确定义在将IP多播复制到EUs（例如，通过应用于IGMP/MLD成员状态创建的（S，G）访问控制列表）的最后一跳路由器上的允许（S，G）集来缓解。每个广告（比如“ADi”）都应该知道位于ADi的哪些来源被允许发送，以及它们的有效（S，G）是什么。因此，ADi还可以过滤位于ADi内部的任何“S”的无效（S，G）S，但不能过滤位于另一个AD中的源。
In the peering case, without further information, AD-2 is not aware of the set of valid (S,G) from AD-1, so this set needs to be communicated via operational procedures from AD-1 to AD-2 to provide protection against this type of DoS attack. Future work could signal this information in an automated way: BGP extensions, DNS resource records, or backend automation between AD-1 and AD-2. Backend automation is, in the short term, the most viable solution: unlike BGP extensions or DNS resource records, backend automation does not require router software extensions. Observation of traffic flowing via (S,G) state could also be used to automate the recognition of invalid (S,G) state created by receivers in the absence of explicit information from AD-1.
在对等情况下，在没有进一步信息的情况下，AD-2不知道来自AD-1的有效（S，G）集合，因此需要通过从AD-1到AD-2的操作过程来通信该集合，以提供针对此类DoS攻击的保护。未来的工作可能会以一种自动化的方式发送此信息：BGP扩展、DNS资源记录或AD-1和AD-2之间的后端自动化。从短期来看，后端自动化是最可行的解决方案：与BGP扩展或DNS资源记录不同，后端自动化不需要路由器软件扩展。通过（S，G）状态观察流量也可用于自动识别接收器在没有来自AD-1的明确信息的情况下创建的无效（S，G）状态。
The second type of DoS attack through (S,G) membership reports exists when the attacking receiver creates too much valid (S,G) state and the traffic carried by these (S,G)s congests bandwidth on links shared with other EUs. Consider the uplink to a last-hop router connecting to 100 EUs. If one EU joins to more multicast content than what fits into this link, then this would also impact the quality of the same content for the other 99 EUs. If traffic is not rate adaptive, the effects are even worse.
通过（S，G）成员身份报告的第二种DoS攻击存在于攻击接收方创建过多的有效（S，G）状态，并且这些（S，G）状态所承载的流量会阻塞与其他EU共享的链路上的带宽时。考虑上行链路到连接到100个EUS的最后一跳路由器。如果一个EU加入的多播内容多于此链接中的内容，那么这也会影响其他99个EU相同内容的质量。如果流量不是速率自适应的，则影响更大。
The mitigation technique is the same as what is often employed for unicast: policing of the per-EU total amount of traffic. Unlike unicast, though, this cannot be done anywhere along the path (e.g., on an arbitrary bottleneck link); it has to happen at the point of last replication to the different EU. Simple solutions such as limiting the maximum number of joined (S,G)s per EU are readily available; solutions that take consumed bandwidth into account are available as vendor-specific features in routers. Note that this is primarily a non-peering issue in AD-2; it only becomes a peering issue if the peering link itself is not big enough to carry all possible content from AD-1 or, as in Use Case 3.4, when the AMT relay in AD-1 is that last replication point.
缓解技术与通常用于单播的技术相同：监控每欧盟的总流量。但是，与单播不同，这不能在路径上的任何位置（例如，在任意瓶颈链路上）进行；它必须在最后一次复制到不同的欧盟时发生。简单的解决方案，例如限制每个EU的最大连接（S，G）S数量是现成的；考虑到消耗带宽的解决方案可以作为路由器中特定于供应商的功能提供。注意，这主要是AD-2中的非对等问题；只有当对等链路本身不够大，无法承载AD-1中所有可能的内容时，或者如用例3.4所示，当AD-1中的AMT中继是最后一个复制点时，才成为对等问题。
Limiting the amount of (S,G) state per EU is also a good first measure to prohibit too much undesired "empty" state from being built (state not carrying traffic), but it would not suffice in the case of DDoS attacks, e.g., viruses that impact a large number of EU devices.
限制每个EU的（S，G）状态数量也是禁止构建太多不希望的“空”状态（不承载流量的状态）的一个很好的首要措施，但这在DDoS攻击的情况下是不够的，例如，影响大量EU设备的病毒。
Content confidentiality, DRM (Digital Rights Management), authentication, and authorization are optional, based on the content delivered. For content that is "FTA" (Free To Air), the following considerations can be ignored, and content can be sent unencrypted and without EU authentication and authorization. Note, though, that the mechanisms described here may also be desirable for the application source to better track users even if the content itself would not require it.
根据交付的内容，内容机密性、DRM（数字版权管理）、身份验证和授权是可选的。对于“FTA”（免费播放）的内容，可以忽略以下注意事项，内容可以不加密发送，无需欧盟认证和授权。但是，请注意，这里描述的机制对于应用程序源来说也是可取的，以便更好地跟踪用户，即使内容本身不需要它。
For inter-domain content, there are at least two models for content confidentiality, including (1) DRM authentication and authorization and (2) EU authentication and authorization:
对于域间内容，至少有两种内容机密性模型，包括（1）DRM身份验证和授权和（2）EU身份验证和授权：
o In the classical (IP)TV model, responsibility is per domain, and content is and can be passed on unencrypted. AD-1 delivers content to AD-2; AD-2 can further process the content, including features like ad insertion, and AD-2 is the sole point of contact regarding the contact for its EUs. In this document, we do not consider this case because it typically involves service aspects operated by AD-2 that are higher than the network layer; this document focuses on the network-layer AD-1/AD-2 peering case but not the application-layer peering case. Nevertheless, this model can be derived through additional work beyond what is described here.
o 在经典的（IP）TV模型中，责任是每个域，内容是并且可以在未加密的情况下传递。AD-1向AD-2交付内容；AD-2可以进一步处理内容，包括广告插入等功能，并且AD-2是其EUs联系人的唯一联系点。在本文中，我们不考虑这种情况，因为它通常涉及由AD-2操作的服务方面，该服务方面高于网络层；本文档重点介绍网络层AD-1/AD-2对等情况，而不是应用层对等情况。然而，这个模型可以通过本文描述之外的额外工作得到。
o The other model is the one in which content confidentiality, DRM, EU authentication, and EU authorization are end to end: responsibilities of the multicast application source provider and receiver application. This is the model assumed here. It is also the model used in Internet "Over the Top" (OTT) video delivery. Below, we discuss the threats incurred in this model due to the use of IP multicast in AD-1 or AD-2 and across the peering point.
o 另一个模型是内容机密性、DRM、EU认证和EU授权端到端的模型：多播应用程序源提供商和接收方应用程序的责任。这是这里假设的模型。它也是互联网“超顶级”（OTT）视频传输中使用的模式。下面，我们将讨论此模型中由于在AD-1或AD-2中以及在对等点上使用IP多播而产生的威胁。
End-to-end encryption enables end-to-end EU authentication and authorization: the EU may be able to join (via IGMP/MLD) and receive the content, but it can only decrypt it when it receives the decryption key from the content source in AD-1. The key is the authorization. Keeping that key to itself and prohibiting playout of the decrypted content to non-copy-protected interfaces are typical DRM features in that receiver application or EU device operating system.
端到端加密支持端到端EU身份验证和授权：EU可能能够加入（通过IGMP/MLD）并接收内容，但它只能在从AD-1中的内容源接收解密密钥时对其进行解密。关键是授权。保留该密钥并禁止将解密内容播放到不受复制保护的接口是该接收器应用程序或EU设备操作系统中的典型DRM功能。
End-to-end encryption is continuously attacked. Keys may be subject to brute-force attacks so that content can potentially be decrypted later, or keys are extracted from the EU application/device and shared with other unauthenticated receivers. One important class of
端到端加密不断受到攻击。密钥可能会受到暴力攻击，以便稍后可能解密内容，或者从EU应用程序/设备提取密钥并与其他未经验证的接收者共享。一类重要的
content is where the value is in live consumption, such as sports or other event (e.g., concert) streaming. Extraction of keying material from compromised authenticated EUs and sharing with unauthenticated EUs are not sufficient. It is also necessary for those unauthenticated EUs to get a streaming copy of the content itself. In unicast streaming, they cannot get such a copy from the content source (because they cannot authenticate), and, because of asymmetric bandwidths, it is often impossible to get the content from compromised EUs to a large number of unauthenticated EUs. EUs behind classical "16 Mbps down, 1 Mbps up" ADSL links are the best example. With increasing broadband access speeds, unicast peer-to-peer copying of content becomes easier, but it likely will always be easily detectable by the ADs because of its traffic patterns and volume.
内容是指现场消费的价值所在，如体育或其他活动（如音乐会）流媒体。从受损的认证EUs中提取密钥材料并与未经认证的EUs共享是不够的。对于那些未经认证的EUs来说，获得内容本身的流媒体副本也是必要的。在单播流媒体中，他们无法从内容源获取这样的副本（因为他们无法进行身份验证），并且，由于带宽不对称，通常无法将内容从受损EU获取到大量未经身份验证的EU。经典的“16 Mbps下行，1 Mbps上行”ADSL链路背后的EUs就是最好的例子。随着宽带接入速度的提高，内容的单播点对点复制变得更加容易，但由于其流量模式和容量，它可能总是很容易被广告检测到。
When IP multicast is being used without additional security, AD-2 is not aware of which EU is authenticated for which content. Any unauthenticated EU in AD-2 could therefore get a copy of the encrypted content without triggering suspicion on the part of AD-2 or AD-1 and then either (1) live-decode it, in the presence of the compromised authenticated EU and key-sharing or (2) decrypt it later, in the presence of federated brute-force key-cracking.
当IP多播在没有额外安全性的情况下使用时，AD-2不知道哪个EU针对哪个内容进行了身份验证。因此，AD-2中任何未经认证的EU都可以获得加密内容的副本，而不会引起AD-2或AD-1的怀疑，然后（1）在受损的认证EU和密钥共享的情况下对其进行实时解码，或者（2）在联邦暴力破解密钥的情况下对其进行解密。
To mitigate this issue, the last replication point that is creating (S,G) copies to EUs would need to permit those copies only after authentication of the EUs. This would establish the same authenticated "EU only" copy that is used in unicast.
为了缓解此问题，正在创建（S，G）拷贝到EUs的最后一个复制点需要仅在EUs验证后才允许这些拷贝。这将建立在单播中使用的同一个经过认证的“仅限欧盟”副本。
Schemes for per-EU IP multicast authentication/authorization (and, as a result, non-delivery or copying of per-content IP multicast traffic) have been built in the past and are deployed in service providers for intra-domain IPTV services, but no standards exist for this. For example, there is no standardized RADIUS attribute for authenticating the IGMP/MLD filter set, but such implementations exist. The authors of this document are specifically also not aware of schemes where the same authentication credentials used to get the encryption key from the content source could also be used to authenticate and authorize the network-layer IP multicast replication for the content. Such schemes are technically not difficult to build and would avoid creating and maintaining a separate network traffic-forwarding authentication/authorization scheme decoupled from the end-to-end authentication/authorization system of the application.
每EU IP多播认证/授权方案（以及因此，每内容IP多播流量的非交付或复制）已在过去建立，并部署在域内IPTV服务的服务提供商中，但没有相关标准。例如，没有用于验证IGMP/MLD过滤器集的标准化RADIUS属性，但存在这样的实现。本文档的作者还特别不了解用于从内容源获取加密密钥的相同身份验证凭据也可用于对内容的网络层IP多播复制进行身份验证和授权的方案。此类方案在技术上不难构建，并且可以避免创建和维护与应用程序的端到端认证/授权系统分离的单独网络流量转发认证/授权方案。
If delivery of such high-value content in conjunction with the peering described here is desired, the short-term recommendations are for sources to clearly isolate the source and group addresses used for different content bundles, communicate those (S,G) patterns from AD-1 to AD-2, and let AD-2 leverage existing per-EU authentication/ authorization mechanisms in network devices to establish filters for (S,G) sets to each EU.
如果希望结合此处所述的对等来交付此类高价值内容，则短期建议源明确隔离用于不同内容包的源地址和组地址，将这些（S，G）模式从AD-1传送到AD-2，让AD-2利用网络设备中现有的每欧盟身份验证/授权机制，为每个欧盟的（S，G）集建立过滤器。
Encryption at peering points for multicast delivery may be used per agreement between AD-1 and AD-2.
根据AD-1和AD-2之间的协议，可以在对等点使用多播传输的加密。
In the case of a private peering link, IP multicast does not have attack vectors on a peering link different from those of IP unicast, but the content owner may have defined strict constraints against unauthenticated copying of even the end-to-end encrypted content; in this case, AD-1 and AD-2 can agree on additional transport encryption across that peering link. In the case of a broadcast peering connection (e.g., IXP), transport encryption is again the easiest way to prohibit unauthenticated copies by other ADs on the same peering point.
在私有对等链路的情况下，IP多播在对等链路上没有不同于IP单播的攻击向量，但内容所有者可能已经定义了严格的限制，以防止未经认证的复制甚至端到端加密内容；在这种情况下，AD-1和AD-2可以在该对等链路上商定额外的传输加密。在广播对等连接（例如，IXP）的情况下，传输加密再次是禁止其他广告在同一对等点上的未经验证副本的最简单方法。
If peering is across a tunnel that spans intermittent transit ADs (not discussed in detail in this document), then encryption of that tunnel traffic is recommended. It not only prohibits possible "leakage" of content but also protects the information regarding what content is being consumed in AD-2 (aggregated privacy protection).
如果对等是通过跨越间歇传输广告的隧道进行的（本文档中未详细讨论），则建议对该隧道流量进行加密。它不仅禁止可能的内容“泄露”，而且还保护与AD-2（聚合隐私保护）中正在使用的内容相关的信息。
See Section 6.4 for reasons why the peering point may also need to be encrypted for operational reasons.
请参阅第6.4节，了解出于操作原因，对等点可能也需要加密的原因。
Section 4.3.3 discusses the exchange of log information, and Section 7 discusses the exchange of program information. All these operational pieces of data should by default be exchanged via authenticated and encrypted peer-to-peer communication protocols between AD-1 and AD-2 so that only the intended recipients in the peers' AD have access to it. Even exposure of the least sensitive information to third parties opens up attack vectors. Putting valid (S,G) information, for example, into DNS (as opposed to passing it via secured channels from AD-1 to AD-2) to allow easier filtering of invalid (S,G) information would also allow attackers to more easily identify valid (S,G) information and change their attack vector.
第4.3.3节讨论了日志信息的交换，第7节讨论了程序信息的交换。默认情况下，所有这些操作数据段都应通过AD-1和AD-2之间经过身份验证和加密的点对点通信协议进行交换，以便只有对等AD中的预期接收者可以访问它。即使将最不敏感的信息暴露给第三方也会造成攻击。将有效的（S，G）信息，例如，输入DNS（与通过从AD-1到AD-2的安全信道传递）相反，以允许更容易地过滤无效（S，G）信息，也将允许攻击者更容易地识别有效的（S，G）信息并改变其攻击向量。
From the perspective of the ADs, security is most critical for log information, as it provides operational insight into the originating AD but also contains sensitive user data.
从ADs的角度来看，日志信息的安全性是最关键的，因为它提供了对原始AD的操作洞察力，但也包含敏感的用户数据。
Sensitive user data exported from AD-2 to AD-1 as part of logs could be as much as the equivalent of 5-tuple unicast traffic flow accounting (but not more, e.g., no application-level information). As mentioned in Section 7, in unicast, AD-1 could capture these traffic statistics itself because this is all about traffic flows (originated by AD-1) to EU receivers in AD-2, and operationally passing it from AD-2 to AD-1 may be necessary when IP multicast is used because of the replication taking place in AD-2.
作为日志的一部分，从AD-2导出到AD-1的敏感用户数据可能相当于5元组单播流量计费（但不能超过5元组，例如，没有应用程序级信息）。如第7节所述，在单播中，AD-1本身可以捕获这些流量统计数据，因为这都是关于到AD-2中EU接收器的流量（由AD-1发起），并且在操作上，当使用IP多播时，可能需要将其从AD-2传递到AD-1，因为在AD-2中发生了复制。
Nevertheless, passing such traffic statistics inside AD-1 from a capturing router to a backend system is likely less subject to third-party attacks than passing it "inter-domain" from AD-2 to AD-1, so more diligence needs to be applied to secure it.
尽管如此，将AD-1内部的此类流量统计数据从捕获路由器传递到后端系统比将其从AD-2传递到AD-1的“域间”更容易受到第三方攻击，因此需要更加谨慎地保护它。
If any protocols used for the operational exchange of information are not easily secured at the transport layer or higher (because of the use of legacy products or protocols in the network), then AD-1 and AD-2 can also consider ensuring that all operational data exchanges go across the same peering point as the traffic and use network-layer encryption of the peering point (as discussed previously) to protect it.
如果用于操作性信息交换的任何协议在传输层或更高层不容易得到保护（因为在网络中使用了遗留产品或协议），然后，AD-1和AD-2还可以考虑确保所有操作数据交换与对等点（如前面所讨论的）的流量和使用网络层加密进行相同的对等点，以保护它。
End-to-end authentication and authorization of EUs may involve some kind of token authentication and are done at the application layer, independently of the two ADs. If there are problems related to the failure of token authentication when EUs are supported by AD-2, then some means of validating proper operation of the token authentication process (e.g., validating that backend servers querying the multicast application source provider's token authentication server are communicating properly) should be considered. Implementation details are beyond the scope of this document.
EUs的端到端身份验证和授权可能涉及某种令牌身份验证，并在应用层独立于两个ADs进行。如果存在与AD-2支持EUs时令牌身份验证失败相关的问题，然后，应考虑验证令牌认证过程的正确操作的一些方法（例如，验证查询多播应用程序源提供商的令牌认证服务器的后端服务器是否正确通信）。实施细节超出了本文件的范围。
In the event of a security breach, the two ADs are expected to have a mitigation plan for shutting down the peering point and directing multicast traffic over alternative peering points. It is also expected that appropriate information will be shared for the purpose of securing the identified breach.
在出现安全漏洞的情况下，这两个ADs预计将有一个缓解计划，用于关闭对等点，并在备用对等点上引导多播流量。此外，为了确保已识别的违规行为的安全，还应共享适当的信息。
The described flow of information about content and EUs as described in this document aims to maintain privacy:
本文档中描述的内容和EUs信息流旨在维护隐私：
AD-1 is operating on behalf of (or owns) the content source and is therefore part of the content-consumption relationship with the EU. The privacy considerations between the EU and AD-1 are therefore generally the same (with one exception; see below) as they would be if no IP multicast was used, especially because end-to-end encryption can and should be used for any privacy-conscious content.
AD-1代表（或拥有）内容源运营，因此是与欧盟内容消费关系的一部分。因此，EU和AD-1之间的隐私考虑通常与未使用IP多播时相同（只有一个例外；见下文），特别是因为端到端加密可以而且应该用于任何隐私意识内容。
Information related to inter-domain multicast transport service is provided to AD-1 by the AD-2 operators. AD-2 is not required to gain additional insight into the user's behavior through this process other than what it would already have without service collaboration with AD-1, unless AD-1 and AD-2 agree on it and get approval from the EU.
域间多播传输服务的相关信息由AD-2运营商提供给AD-1。除非AD-1和AD-2同意并获得欧盟的批准，否则AD-2不需要通过该流程获得对用户行为的额外洞察，除非没有与AD-1的服务合作。
For example, if it is deemed beneficial for the EU to get support directly from AD-2, then it would generally be necessary for AD-2 to be aware of the mapping between content and network (S,G) state so that AD-2 knows which (S,G) to troubleshoot when the EU complains about problems with specific content. The degree to which this dissemination is done by AD-1 explicitly to meet privacy expectations of EUs is typically easy to assess by AD-1. Two simple examples are as follows:
例如，如果认为直接从AD-2获得支持对欧盟有利，则AD-2通常有必要了解内容和网络（S，G）状态之间的映射，以便AD-2知道在欧盟投诉特定内容的问题时要解决哪些（S，G）问题。AD-1明确完成该传播以满足EUs隐私期望的程度通常很容易通过AD-1进行评估。以下是两个简单的例子：
o For a sports content bundle, every EU will happily click on the "I approve that the content program information is shared with your service provider" button, to ensure best service reliability, because service-conscious AD-2 would likely also try to ensure that high-value content, such as the (S,G) for the Super Bowl, would be the first to receive care in the case of network issues.
o 对于体育内容捆绑包，每个欧盟成员国都会高兴地点击“我批准与您的服务提供商共享内容计划信息”按钮，以确保最佳服务可靠性，因为服务意识强的AD-2可能也会尝试确保高价值内容，如超级碗的（S，G），将是第一个在网络问题的情况下接受护理的人。
o If the content in question was content for which the EU expected more privacy, the EU should prefer a content bundle that included this content in a large variety of other content, have all content end-to-end encrypted, and not share programming information with AD-2, to maximize privacy. Nevertheless, the privacy of the EU against AD-2 observing traffic would still be lower than in the equivalent setup using unicast, because in unicast, AD-2 could not correlate which EUs are watching the same content and use that to deduce the content. Note that even the setup in Section 3.4, where AD-2 is not involved in IP multicast at all, does not provide privacy against this level of analysis by AD-2, because there is no transport-layer encryption in AMT; therefore, AD-2 can correlate by on-path traffic analysis who is consuming the same
o 如果所讨论的内容是欧盟希望获得更多隐私的内容，欧盟应该选择将该内容包含在大量其他内容中的内容包，对所有内容进行端到端加密，并且不与AD-2共享节目信息，以最大限度地提高隐私。尽管如此，欧盟对AD-2观测流量的保密性仍低于使用单播的等效设置，因为在单播中，AD-2无法关联哪些EU正在观看相同的内容并使用该内容推断内容。请注意，即使是第3.4节中的设置（其中AD-2根本不涉及IP多播），也不会针对AD-2的这种分析级别提供隐私，因为AMT中没有传输层加密；因此，AD-2可以通过对使用相同数据的用户进行路径流量分析来进行关联
content from an AMT relay from both the (S,G) join messages in AMT and the identical content segments (that were replicated at the AMT relay).
来自AMT中继的内容来自AMT中的（S，G）联接消息和相同的内容段（在AMT中继处复制）。
In summary, because only content to be consumed by multiple EUs is carried via IP multicast here and all of that content can be end-to-end encrypted, the only privacy consideration specific to IP multicast is for AD-2 to know or reconstruct what content an EU is consuming. For content for which this is undesirable, some form of protections as explained above are possible, but ideally, the model described in Section 3.4 could be used in conjunction with future work, e.g., adding Datagram Transport Layer Security (DTLS) encryption [RFC6347] between the AMT relay and the EU.
总之，由于此处仅通过IP多播携带多个EU消费的内容，并且所有内容都可以端到端加密，因此IP多播唯一的隐私考虑是AD-2了解或重构EU消费的内容。对于不希望出现这种情况的内容，可以使用上述某种形式的保护，但理想情况下，第3.4节中描述的模型可以与未来的工作结合使用，例如，在AMT中继和EU之间添加数据报传输层安全（DTLS）加密[RFC6347]。
Note that IP multicast by nature would permit the EU's privacy against the content source operator because, unlike unicast, the content source does not natively know which EU is consuming which content: in all cases where AD-2 provides replication, only AD-2 knows this directly. This document does not attempt to describe a model that maintains such a level of privacy against the content source; rather, we describe a model that only protects against exposure to intermediate parties -- in this case, AD-2.
请注意，IP多播本质上允许EU针对内容源运营商的隐私，因为与单播不同，内容源不知道哪个EU在使用哪个内容：在AD-2提供复制的所有情况下，只有AD-2直接知道这一点。本文档不试图描述针对内容源维护此类隐私级别的模型；相反，我们描述了一个模型，该模型只保护中间方的风险——在本例中为AD-2。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 2784，DOI 10.17487/RFC27842000年3月<https://www.rfc-editor.org/info/rfc2784>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，版本3”，RFC 3376，DOI 10.17487/RFC3376，2002年10月<https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.
[RFC3810]Vida，R.，Ed.，和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 3810，DOI 10.17487/RFC3810，2004年6月<https://www.rfc-editor.org/info/rfc3810>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，DOI 10.17487/RFC4760，2007年1月<https://www.rfc-editor.org/info/rfc4760>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, August 2006, <https://www.rfc-editor.org/info/rfc4604>.
[RFC4604]Holbrook，H.，Cain，B.，和B.Haberman，“为源特定多播使用Internet组管理协议版本3（IGMPv3）和多播侦听器发现协议版本2（MLDv2）”，RFC 4604，DOI 10.17487/RFC4604，2006年8月<https://www.rfc-editor.org/info/rfc4604>.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, DOI 10.17487/RFC4609, October 2006, <https://www.rfc-editor.org/info/rfc4609>.
[RFC4609]Savola，P.，Lehtonen，R.，和D.Meyer，“协议独立多播-稀疏模式（PIM-SM）多播路由安全问题和增强”，RFC 4609，DOI 10.17487/RFC4609，2006年10月<https://www.rfc-editor.org/info/rfc4609>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, DOI 10.17487/RFC7450, February 2015, <https://www.rfc-editor.org/info/rfc7450>.
[RFC7450]Bumgardner，G.，“自动多播隧道”，RFC 7450，DOI 10.17487/RFC7450，2015年2月<https://www.rfc-editor.org/info/rfc7450>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <https://www.rfc-editor.org/info/rfc7761>.
[RFC7761]Fenner，B.，Handley，M.，Holbrook，H.，Kouvelas，I.，Parekh，R.，Zhang，Z.，和L.Zheng，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，STD 83，RFC 7761，DOI 10.17487/RFC7761，2016年3月<https://www.rfc-editor.org/info/rfc7761>.
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[BCP38]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月<https://www.rfc-editor.org/info/rfc2827>.
[BCP41] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[BCP41]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 29142000年9月<https://www.rfc-editor.org/info/rfc2914>.
[BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", BCP 145, RFC 8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[BCP145]Eggert，L.，Fairhurst，G.和G.Shepherd，“UDP使用指南”，BCP 145，RFC 8085，2017年3月<https://www.rfc-editor.org/info/rfc8085>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC4786]Abley，J.和K.Lindqvist，“任意广播服务的运营”，BCP 126，RFC 4786，DOI 10.17487/RFC4786，2006年12月<https://www.rfc-editor.org/info/rfc4786>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[INF_ATIS_10] "CDN Interconnection Use Cases and Requirements in a Multi-Party Federation Environment", ATIS Standard A-0200010, December 2012.
[INF_ATIS_10]“多方联盟环境中的CDN互连用例和要求”，ATIS标准a-0200010，2012年12月。
[MDH-05] Thaler, D. and B. Aboba, "Multicast Debugging Handbook", Work in Progress, draft-ietf-mboned-mdh-05, November 2000.
[MDH-05]Thaler，D.和B.Aboba，“多播调试手册”，正在进行的工作，草案-ietf-mboned-MDH-05，2000年11月。
[Traceroute] "traceroute.org", <http://traceroute.org/#source%20code>.
[Traceroute]“Traceroute.org”<http://traceroute.org/#source%20code>.
[Mtrace-v2] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2: Traceroute Facility for IP Multicast", Work in Progress, draft-ietf-mboned-mtrace-v2-22, December 2017.
[Mtrace-v2]Asaeda，H.，Meyer，K.，和W.Lee，Ed.，“Mtrace版本2：IP多播跟踪路由设施”，正在进行的工作，草稿-ietf-mboned-Mtrace-v2-22，2017年12月。
Acknowledgments
致谢
The authors would like to thank the following individuals for their suggestions, comments, and corrections:
作者感谢以下个人的建议、评论和更正：
Mikael Abrahamsson
米凯尔·阿布拉罕松
Hitoshi Asaeda
浅田仁
Dale Carder
戴尔卡德
Tim Chown
蒂姆·周
Leonard Giuliano
伦纳德·朱利亚诺
Jake Holland
杰克·霍兰德
Joel Jaeggli
乔尔贾格利
Henrik Levkowetz
亨里克·列夫科维茨
Albert Manfredi
阿尔伯特·曼弗雷迪
Stig Venaas
斯蒂格静脉
Authors' Addresses
作者地址
Percy S. Tarapore (editor) AT&T
珀西·S·塔拉波尔（编辑）美国电话电报公司
Phone: 1-732-420-4172 Email: tarapore@att.com
电话：1-732-420-4172电子邮件：tarapore@att.com
Robert Sayko AT&T
罗伯特·赛科AT&T
Phone: 1-732-420-3292 Email: rs1983@att.com
电话：1-732-420-3292电子邮件：rs1983@att.com
Greg Shepherd Cisco
格雷格·谢泼德·思科
Email: shep@cisco.com
Email: shep@cisco.com
Toerless Eckert (editor) Huawei USA - Futurewei Technologies Inc.
无托勒埃克特（编辑）华为美国-未来威科技有限公司。
Email: tte+ietf@cs.fau.de, toerless.eckert@huawei.com
Email: tte+ietf@cs.fau.de, toerless.eckert@huawei.com
Ram Krishnan SupportVectors
拉姆·克里希南
Email: ramkri123@gmail.com
Email: ramkri123@gmail.com