Network Working Group T. Morin, Ed.
Request for Comments: 4834 France Telecom R&D
Category: Informational April 2007
Network Working Group T. Morin, Ed.
Request for Comments: 4834 France Telecom R&D
Category: Informational April 2007
Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)
第3层提供商提供的虚拟专用网络（PPVPN）中的多播要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document presents a set of functional requirements for network solutions that allow the deployment of IP multicast within Layer 3 (L3) Provider-Provisioned Virtual Private Networks (PPVPNs). It specifies requirements both from the end user and service provider standpoints. It is intended that potential solutions specifying the support of IP multicast within such VPNs will use these requirements as guidelines.
本文档介绍了一组网络解决方案的功能需求，这些网络解决方案允许在第3层（L3）提供商提供的虚拟专用网络（PPVPN）中部署IP多播。它从最终用户和服务提供商的角度规定了要求。预期指定此类VPN内IP多播支持的潜在解决方案将使用这些要求作为指导原则。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. General Requirements . . . . . . . . . . . . . . . . . . . 7
3.3. Scaling vs. Optimizing Resource Utilization . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Live Content Broadcast . . . . . . . . . . . . . . . . 9
4.1.2. Symmetric Applications . . . . . . . . . . . . . . . . 10
4.1.3. Data Distribution . . . . . . . . . . . . . . . . . . 10
4.1.4. Generic Multicast VPN Offer . . . . . . . . . . . . . 11
4.2. Scalability Orders of Magnitude . . . . . . . . . . . . . 11
4.2.1. Number of VPNs with Multicast Enabled . . . . . . . . 11
4.2.2. Number of Multicast VPNs per PE . . . . . . . . . . . 12
4.2.3. Number of CEs per Multicast VPN per PE . . . . . . . . 12
4.2.4. PEs per Multicast VPN . . . . . . . . . . . . . . . . 12
4.2.5. PEs with Multicast VRFs . . . . . . . . . . . . . . . 13
4.2.6. Number of Streams Sourced . . . . . . . . . . . . . . 13
5. Requirements for Supporting IP Multicast within L3 PPVPNs . . 13
5.1. End User/Customer Standpoint . . . . . . . . . . . . . . . 13
5.1.1. Service Definition . . . . . . . . . . . . . . . . . . 13
5.1.2. CE-PE Multicast Routing and Group Management
Protocols . . . . . . . . . . . . . . . . . . . . . . 14
5.1.3. Quality of Service (QoS) . . . . . . . . . . . . . . . 14
5.1.4. Operations and Management . . . . . . . . . . . . . . 15
5.1.5. Security Requirements . . . . . . . . . . . . . . . . 16
5.1.6. Extranet . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.7. Internet Multicast . . . . . . . . . . . . . . . . . . 18
5.1.8. Carrier's Carrier . . . . . . . . . . . . . . . . . . 18
5.1.9. Multi-Homing, Load Balancing, and Resiliency . . . . . 19
5.1.10. RP Engineering . . . . . . . . . . . . . . . . . . . . 19
5.1.11. Addressing . . . . . . . . . . . . . . . . . . . . . . 20
5.1.12. Minimum MTU . . . . . . . . . . . . . . . . . . . . . 20
5.2. Service Provider Standpoint . . . . . . . . . . . . . . . 21
5.2.1. General Requirement . . . . . . . . . . . . . . . . . 21
5.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 21
5.2.3. Resource Optimization . . . . . . . . . . . . . . . . 23
5.2.4. Tunneling Requirements . . . . . . . . . . . . . . . . 24
5.2.5. Control Mechanisms . . . . . . . . . . . . . . . . . . 26
5.2.6. Support of Inter-AS, Inter-Provider Deployments . . . 26
5.2.7. Quality-of-Service Differentiation . . . . . . . . . . 27
5.2.8. Infrastructure security . . . . . . . . . . . . . . . 27
5.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. General Requirements . . . . . . . . . . . . . . . . . . . 7
3.3. Scaling vs. Optimizing Resource Utilization . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Live Content Broadcast . . . . . . . . . . . . . . . . 9
4.1.2. Symmetric Applications . . . . . . . . . . . . . . . . 10
4.1.3. Data Distribution . . . . . . . . . . . . . . . . . . 10
4.1.4. Generic Multicast VPN Offer . . . . . . . . . . . . . 11
4.2. Scalability Orders of Magnitude . . . . . . . . . . . . . 11
4.2.1. Number of VPNs with Multicast Enabled . . . . . . . . 11
4.2.2. Number of Multicast VPNs per PE . . . . . . . . . . . 12
4.2.3. Number of CEs per Multicast VPN per PE . . . . . . . . 12
4.2.4. PEs per Multicast VPN . . . . . . . . . . . . . . . . 12
4.2.5. PEs with Multicast VRFs . . . . . . . . . . . . . . . 13
4.2.6. Number of Streams Sourced . . . . . . . . . . . . . . 13
5. Requirements for Supporting IP Multicast within L3 PPVPNs . . 13
5.1. End User/Customer Standpoint . . . . . . . . . . . . . . . 13
5.1.1. Service Definition . . . . . . . . . . . . . . . . . . 13
5.1.2. CE-PE Multicast Routing and Group Management
Protocols . . . . . . . . . . . . . . . . . . . . . . 14
5.1.3. Quality of Service (QoS) . . . . . . . . . . . . . . . 14
5.1.4. Operations and Management . . . . . . . . . . . . . . 15
5.1.5. Security Requirements . . . . . . . . . . . . . . . . 16
5.1.6. Extranet . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.7. Internet Multicast . . . . . . . . . . . . . . . . . . 18
5.1.8. Carrier's Carrier . . . . . . . . . . . . . . . . . . 18
5.1.9. Multi-Homing, Load Balancing, and Resiliency . . . . . 19
5.1.10. RP Engineering . . . . . . . . . . . . . . . . . . . . 19
5.1.11. Addressing . . . . . . . . . . . . . . . . . . . . . . 20
5.1.12. Minimum MTU . . . . . . . . . . . . . . . . . . . . . 20
5.2. Service Provider Standpoint . . . . . . . . . . . . . . . 21
5.2.1. General Requirement . . . . . . . . . . . . . . . . . 21
5.2.2. Scalability . . . . . . . . . . . . . . . . . . . . . 21
5.2.3. Resource Optimization . . . . . . . . . . . . . . . . 23
5.2.4. Tunneling Requirements . . . . . . . . . . . . . . . . 24
5.2.5. Control Mechanisms . . . . . . . . . . . . . . . . . . 26
5.2.6. Support of Inter-AS, Inter-Provider Deployments . . . 26
5.2.7. Quality-of-Service Differentiation . . . . . . . . . . 27
5.2.8. Infrastructure security . . . . . . . . . . . . . . . 27
5.2.9. Robustness . . . . . . . . . . . . . . . . . . . . . . 28
5.2.10. Operation, Administration, and Maintenance . . . . . . 28
5.2.11. Compatibility and Migration Issues . . . . . . . . . . 29
5.2.12. Troubleshooting . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
5.2.10. Operation, Administration, and Maintenance . . . . . . 28
5.2.11. Compatibility and Migration Issues . . . . . . . . . . 29
5.2.12. Troubleshooting . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 33
Virtual Private Network (VPN) services satisfying the requirements defined in [RFC4031] are now being offered by many service providers throughout the world. VPN services are popular because customers need not be aware of the VPN technologies deployed in the provider network. They scale well for the following reasons:
满足[RFC4031]中定义的要求的虚拟专用网络（VPN）服务现在由世界各地的许多服务提供商提供。VPN服务很受欢迎，因为客户不需要知道提供商网络中部署的VPN技术。由于以下原因，它们可以很好地扩展：
o because P routers (Provider Routers) need not be aware of VPN service details
o 因为P路由器（提供商路由器）不需要知道VPN服务的详细信息
o because the addition of a new VPN member requires only limited configuration effort
o 因为添加新的VPN成员只需要有限的配置工作
There is also a growing need for support of IP multicast-based services. Efforts to provide efficient IP multicast routing protocols and multicast group management have been made in standardization bodies which has led, in particular, to the definition of Protocol Independent Multicast (PIM) and Internet Group Management Protocol (IGMP).
支持基于IP多播的服务的需求也越来越大。标准化机构一直致力于提供高效的IP多播路由协议和多播组管理，这导致了协议独立多播（PIM）和互联网组管理协议（IGMP）的定义。
However, multicast traffic is not natively supported within existing L3 PPVPN solutions. Deploying multicast over an L3VPN today, with only currently standardized solutions, requires designing customized solutions which will be inherently limited in terms of scalability, operational efficiency, and bandwidth usage.
但是，现有L3 PPVPN解决方案不支持本地多播通信。在目前只有标准化解决方案的L3VPN上部署多播需要设计定制的解决方案，而定制的解决方案在可扩展性、操作效率和带宽使用方面都会受到固有的限制。
This document complements the generic L3VPN requirements [RFC4031] document, by specifying additional requirements specific to the deployment within PPVPNs of services based on IP multicast. It clarifies the needs of both VPN clients and providers and formulates the problems that should be addressed by technical solutions with the key objective being to remain solution agnostic. There is no intent in this document to specify either solution-specific details or application-specific requirements. Also, this document does NOT aim at expressing multicast-related requirements that are not specific to L3 PPVPNs.
本文件补充了通用L3VPN要求[RFC4031]文件，具体规定了PPVPN内基于IP多播的服务部署的额外要求。它阐明了VPN客户端和提供商的需求，并阐述了技术解决方案应解决的问题，其主要目标是保持解决方案不可知性。本文档无意指定特定于解决方案的详细信息或特定于应用程序的要求。此外，本文档的目的并不是表达与多播相关的要求，这些要求并非特定于L3 PPVPN。
It is expected that solutions that specify procedures and protocol extensions for multicast in L3 PPVPNs SHOULD satisfy these requirements.
预计在L3 PPVPN中指定多播过程和协议扩展的解决方案应满足这些要求。
Although the reader is assumed to be familiar with the terminology defined in [RFC4031], [RFC4364], [RFC4601], and [RFC4607], the following glossary of terms may be worthwhile.
尽管假定读者熟悉[RFC4031]、[RFC4364]、[RFC4601]和[RFC4607]中定义的术语，但以下术语表可能值得一读。
We also propose here generic terms for concepts that naturally appear when multicast in VPNs is discussed.
在这里，我们还为讨论VPN中的多播时自然出现的概念提出了通用术语。
ASM: Any Source Multicast. One of the two multicast service models, in which a terminal subscribes to a multicast group to receive data sent to the group by any source.
ASM：任何源多播。两种多播服务模型中的一种，其中终端订阅一个多播组以接收由任何源发送给该组的数据。
Multicast-enabled VPN, multicast VPN, or mVPN: A VPN that supports IP multicast capabilities, i.e., for which some PE devices (if not all) are multicast-enabled and whose core architecture supports multicast VPN routing and forwarding.
支持多播的VPN、多播VPN或mVPN：支持IP多播功能的VPN，即某些PE设备（如果不是全部）支持多播，其核心架构支持多播VPN路由和转发。
PPVPN: Provider-Provisioned Virtual Private Network.
PPVPN：提供商提供的虚拟专用网络。
PE, CE: "Provider Edge", "Customer Edge" (as defined in [RFC4026]). As suggested in [RFC4026], we will use these notations to refer to the equipments/routers/devices themselves. Thus, "PE" will refer to the router on the provider's edge, which faces the "CE", the router on the customer's edge.
PE、CE：“供应商优势”、“客户优势”（定义见[RFC4026]）。如[RFC4026]所述，我们将使用这些符号来表示设备/路由器/设备本身。因此，“PE”将指提供商边缘上的路由器，它面对“CE”，即客户边缘上的路由器。
VRF or VR: By these terms, we refer to the entity defined in a PE dedicated to a specific VPN instance. "VRF" refers to "VPN Routing and Forwarding table" as defined in [RFC4364], and "VR" to "Virtual Router" as defined in [VRs] terminology.
VRF或VR：根据这些术语，我们指的是专用于特定VPN实例的PE中定义的实体。“VRF”是指[RFC4364]中定义的“VPN路由和转发表”，以及[VRs]术语中定义的“VR”到“虚拟路由器”。
MDTunnel: Multicast Distribution Tunnel. The means by which the customer's multicast traffic will be transported across the SP network. This is meant in a generic way: such tunnels can be either point-to-point or point-to-multipoint. Although this definition may seem to assume that distribution tunnels are unidirectional, the wording also encompasses bidirectional tunnels.
MDTunnel：多播分发隧道。通过SP网络传输客户多播流量的方式。这是一种通用方式：此类隧道可以是点对点或点对多点。尽管该定义似乎假定配电隧道是单向的，但该措辞也包括双向隧道。
S: Denotes a multicast source.
S：表示多播源。
G: Denotes a multicast group.
G：表示多播组。
Multicast channel: In the multicast SSM model [RFC4607], a "multicast channel" designates traffic from a specific source S to a multicast group G. Also denominated as "(S,G)".
多播信道：在多播SSM模型[RFC4607]中，“多播信道”指定从特定源S到多播组G的通信量。也称为“（S，G）”。
SP: Service provider.
SP：服务提供商。
SSM: Source Specific Multicast. One of the two multicast service models, where a terminal subscribes to a multicast group to receive data sent to the group by a specific source.
SSM：特定于源的多播。两种多播服务模型中的一种，其中终端订阅一个多播组以接收由特定源发送给该组的数据。
RP: Rendezvous Point (Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]).
RP：集合点（协议无关多播-稀疏模式（PIM-SM）[RFC4601]）。
P2MP, MP2MP: Designate "Point-to-Multipoint" and "Multipoint-to-Multipoint" replication trees.
P2MP、MP2MP：指定“点对多点”和“多点对多点”复制树。
L3VPN, VPN: Throughout this document, "L3VPN" or even just "VPN" will refer to "Provider-Provisioned Layer 3 Virtual Private Network" (PP L3VPNs), and will be preferred for readability.
L3VPN、VPN：在本文档中，“L3VPN”甚至只是“VPN”将指的是“提供商提供的第3层虚拟专用网络”（PP L3VPN），并且出于可读性考虑，将优先考虑。
Please refer to [RFC4026] for details about terminology specifically relevant to VPN aspects, and to [RFC2432] for multicast performance or quality of service (QoS)-related terms.
请参考[RFC4026]了解与VPN方面特别相关的术语的详细信息，并参考[RFC2432]了解与多播性能或服务质量（QoS）相关的术语。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
More and more L3VPN customers use IP multicast services within their private infrastructures. Naturally, they want to extend these multicast services to remote sites that are connected via a VPN.
越来越多的L3VPN客户在其私有基础设施中使用IP多播服务。当然，他们希望将这些多播服务扩展到通过VPN连接的远程站点。
For instance, the customer could be a national TV channel with several geographical locations that wants to broadcast a TV program from a central point to several regional locations within its VPN.
例如，客户可能是具有多个地理位置的国家电视频道，希望在其VPN内从中心点向多个区域位置广播电视节目。
A solution to support multicast traffic could consist of point-to-point tunnels across the provider network and requires the PEs (Provider Edge routers) to replicate traffic. This would obviously be sub-optimal as it would place the replication burden on the PE and hence would have very poor scaling characteristics. It would also probably waste bandwidth and control plane resources in the provider's network.
支持多播流量的解决方案可以包括跨提供商网络的点对点隧道，并要求PEs（提供商边缘路由器）复制流量。这显然是次优的，因为它会给PE带来复制负担，因此具有非常差的扩展特性。它还可能浪费带宽和提供商网络中的控制平面资源。
Thus, to provide multicast services for L3VPN networks in an efficient manner (that is, with a scalable impact on signaling and protocol state as well as bandwidth usage), in a large-scale environment, new mechanisms are required to enhance existing L3VPN solutions for proper support of multicast-based services.
因此，为了在大规模环境中高效地为L3VPN网络提供多播服务（即，对信令和协议状态以及带宽使用具有可扩展的影响），需要新的机制来增强现有L3VPN解决方案，以适当支持基于多播的服务。
This document sets out requirements for L3 provider-provisioned VPN solutions designed to carry customers' multicast traffic. The main requirement is that a solution SHOULD first satisfy the requirements documented in [RFC4031]: as far as possible, a multicast service should have the same characteristics as the unicast equivalent, including the same simplicity (technology unaware), the same quality of service (if any), the same management (e.g., performance monitoring), etc.
本文档规定了L3提供商提供的VPN解决方案的要求，这些解决方案旨在承载客户的多播流量。主要要求是，解决方案应首先满足[RFC4031]中记录的要求：多播服务应尽可能具有与单播等效服务相同的特性，包括相同的简单性（不了解技术）、相同的服务质量（如有）、相同的管理（如性能监控），等
Moreover, it also has to be clear that a multicast VPN solution MUST interoperate seamlessly with current unicast VPN solutions. It would also make sense that multicast VPN solutions define themselves as extensions to existing L3 provider-provisioned VPN solutions (such as for instance, [RFC4364] or [VRs]) and retain consistency with those, although this is not a core requirement.
此外，还必须明确的是，多播VPN解决方案必须与当前的单播VPN解决方案无缝互操作。多播VPN解决方案将自己定义为现有L3提供商提供的VPN解决方案（例如，[RFC4364]或[VRs]）的扩展，并保持与这些解决方案的一致性也是有意义的，尽管这不是核心要求。
The requirements in this document are equally applicable to IPv4 and IPv6, for both customer- and provider-related matters.
本文档中的要求同样适用于IPv4和IPv6，适用于客户和提供商相关事宜。
When transporting multicast VPN traffic over a service provider network, there intrinsically is tension between scalability and resource optimization, since the latter is likely to require the maintenance of control plane states related to replication trees in the core network [RFC3353].
当通过服务提供商网络传输多播VPN流量时，可伸缩性和资源优化之间存在内在的紧张关系，因为后者可能需要维护与核心网络中复制树相关的控制平面状态[RFC3353]。
Consequently, any deployment will require a trade-off to be made. This document will express some requirements related to this trade-off.
因此，任何部署都需要权衡。本文件将阐述与此权衡相关的一些要求。
The goal of this section is to highlight how different applications and network contexts may have a different impact on how a multicast VPN solution is designed, deployed, and tuned. For this purpose, we describe some typical use case scenarios and express expectations in terms of deployment orders of magnitude.
本节的目标是强调不同的应用程序和网络环境如何对多播VPN解决方案的设计、部署和优化产生不同的影响。为此，我们描述了一些典型的用例场景，并根据部署数量级表达了期望。
Most of the content of these sections originates from a survey done in summer 2005, among institutions and providers that expect to deploy such solutions. The full survey text and raw results (13 responses) were published separately, and we only present here the most relevant facts and expectations that the survey exposed.
这些章节的大部分内容来源于2005年夏季对预期部署此类解决方案的机构和提供商进行的调查。完整的调查文本和原始结果（13份回复）分别公布，我们在此仅介绍调查所揭示的最相关的事实和期望。
For scalability figures, we considered that it was relevant to highlight the highest expectations, those that are expected to have the greatest impact on solution design. For balance, we do also mention cases where such high expectations were expressed in only a few answers.
对于可伸缩性数据，我们认为突出最高期望值是相关的，这些期望值对解决方案设计的影响最大。为了平衡起见，我们还提到了一些案例，其中只有少数几个答案表达了如此高的期望。
We don't provide here an exhaustive set of scenarios that a multicast VPN solution is expected to support -- no solution should restrict the scope of multicast applications and deployments that can be done over a multicast VPN.
在这里，我们不提供多播VPN解决方案预期支持的一组详尽的场景——任何解决方案都不应限制多播VPN上可以完成的多播应用程序和部署的范围。
Hence, we only give here a short list of scenarios that are expected to have a large impact on the design of a multicast VPN solution.
因此，我们在这里只给出一个简短的场景列表，这些场景预计会对多播VPN解决方案的设计产生重大影响。
Under this label, we group all applications that distribute content (audio, video, or other content) with the property that this content is expected to be consulted at once ("live") by the receiver. Typical applications are broadcast TV, production studio connectivity, and distribution of market data feeds.
在该标签下，我们将所有分发内容（音频、视频或其他内容）的应用程序分组，其属性是接收者希望立即查阅该内容（“实时”）。典型应用包括广播电视、制作工作室连接和市场数据源分发。
The characteristics of such applications are the following:
此类应用的特点如下：
o one or few sources to many receivers
o 从一个或几个源到多个接收器
o sources are often in known locations; receivers are in less predictable locations (this latter point may depend on applications)
o 来源通常位于已知位置；接收器位于不太可预测的位置（后一点可能取决于应用程序）
o in some cases, it is expected that the regularity of audience patterns may help improve how the bandwidth/state trade-off is handled
o 在某些情况下，预期受众模式的规律性可能有助于改进带宽/状态权衡的处理方式
o the number of streams can be as high as hundreds, or even thousands, of streams
o 流的数量可以高达数百条，甚至数千条
o bandwidth will depend on the application, but may vary between a few tens/hundreds of Kb/s (e.g., audio or low-quality video media) and tens of Mb/s (high-quality video), with some demanding professional applications requiring as much as hundreds of Mb/s.
o 带宽将取决于应用程序，但可能在几十/数百Kb/s（例如音频或低质量视频媒体）和几十Mb/s（高质量视频）之间变化，一些要求苛刻的专业应用程序需要数百Mb/s。
o QoS requirements include, in many cases, a low multicast group join delay
o 在许多情况下，QoS要求包括较低的多播组加入延迟
o QoS of these applications is likely to be impacted by packet loss (some applications may be robust to low packet loss) and to have low robustness against jitter
o 这些应用程序的QoS可能会受到数据包丢失的影响（一些应用程序可能对低数据包丢失具有鲁棒性），并且对抖动具有较低的鲁棒性
o delay sensitivity will depend on the application: some applications are not so delay sensitive (e.g., broadcast TV), whereas others may require very low delay (professional studio applications)
o 延迟敏感度取决于应用：一些应用程序对延迟不敏感（例如广播电视），而其他应用程序可能需要非常低的延迟（专业演播室应用程序）
o some of these applications may involve rapid changes in customer multicast memberships as seen by the PE, but this will depend on audience patterns and on the amount of provider equipments deployed close to VPN customers
o 这些应用中的一些可能涉及到PE所看到的客户多播成员身份的快速变化，但这将取决于受众模式和部署在VPN客户附近的提供商设备的数量
Some use cases exposed by the survey can be grouped under this label, and include many-to-many applications such as conferencing and server cluster monitoring.
调查中暴露的一些用例可以在这个标签下分组，并包括多对多应用程序，如会议和服务器集群监控。
They are characterized by the relatively high number of streams that they can produce, which has a direct impact on scalability expectations.
它们的特点是可以产生相对较多的流，这对可伸缩性预期有直接影响。
A sub-case of this scenario is the case of symmetric applications with small groups, when the number of receivers is low compared to the number of sites in the VPNs (e.g., video conferencing and e-learning applications).
此场景的一个子场景是具有小组的对称应用程序的情况，与VPN中的站点数量相比，接收器数量较少（例如，视频会议和电子学习应用程序）。
This latter case is expected to be an important input to solution design, since it may significantly impact how the bandwidth/state is managed.
后一种情况预计将成为解决方案设计的重要输入，因为它可能会显著影响带宽/状态的管理方式。
Optimizing bandwidth may require introducing dedicated states in the core network (typically as much as the number of groups) for the following reasons:
优化带宽可能需要在核心网络中引入专用状态（通常与组数相同），原因如下：
o small groups, and low predictability of the location of participants ("sparse groups")
o 小群体，参与者位置的可预测性低（“稀疏群体”）
o possibly significantly high bandwidth (a few Mb/s per participant)
o 带宽可能非常高（每个参与者几Mb/s）
Lastly, some of these applications may involve real-time interactions and will be highly sensitive to packet loss, jitter, and delay.
最后，其中一些应用程序可能涉及实时交互，并且对数据包丢失、抖动和延迟高度敏感。
Some applications that are expected to be deployed on multicast VPNs are non-real-time applications aimed at distributing data from few sources to many receivers.
一些预期部署在多播VPN上的应用程序是非实时应用程序，旨在将数据从少数来源分发到多个接收器。
Such applications may be considered to have lower expectations than their counterparts proposed in this document, since they would not necessarily involve more data streams and are more likely to adapt to the available bandwidth and to be robust to packet loss, jitter, and delay.
此类应用可能被认为比本文中提出的对应应用具有更低的期望，因为它们不一定涉及更多的数据流，并且更有可能适应可用带宽，并且对分组丢失、抖动和延迟具有鲁棒性。
One important property is that such applications may involve higher bandwidths (hundreds of Mb/s).
一个重要特性是，此类应用程序可能涉及更高的带宽（数百Mb/s）。
This ISP scenario is a deployment scenario where IP-multicast connectivity is proposed for every VPN: if a customer requests a VPN, then this VPN will support IP multicast by default. In this case, the number of multicast VPNs equals the number of VPNs. This implies a quite important scalability requirement (e.g., hundreds of PEs, hundreds of VPNs per PE, with a potential increase by one order of magnitude in the future).
此ISP场景是一种部署场景，其中建议为每个VPN提供IP多播连接：如果客户请求VPN，则默认情况下此VPN将支持IP多播。在这种情况下，多播VPN的数量等于VPN的数量。这意味着一个非常重要的可扩展性需求（例如，数百个PE，每个PE数百个VPN，未来可能增加一个数量级）。
The per-mVPN traffic behavior is not predictable because how the service is used is completely up to the customer. This results in a traffic mix of the scenarios mentioned in Section 4.1. QoS requirements are similar to typical unicast scenarios, with the need for different classes. Also, in such a context, a reasonably large range of protocols should be made available to the customer for use at the PE-CE level.
mVPN的使用方式是完全不可预测的，因为mVPN服务的使用方式是不可预测的。这导致了第4.1节中提到的交通混合情况。QoS需求类似于典型的单播场景，需要不同的类。此外，在这种情况下，应向客户提供相当大范围的协议，以便在PE-CE级别使用。
Also, in such a scenario, customers may want to deploy multicast connectivity between two or more multicast VPNs as well as access to Internet Multicast.
此外，在这种情况下，客户可能希望在两个或多个多播VPN之间部署多播连接以及对Internet多播的访问。
This section proposes orders of magnitude for different scalability metrics relevant for multicast VPN issues. It should be noted that the scalability figures proposed here relate to scalability expectations of future deployments of multicast VPN solutions, as the authors chose to not restrict the scope to only currently known deployments.
本节提出了与多播VPN问题相关的不同可伸缩性度量的数量级。应该注意的是，这里提出的可伸缩性数字与未来多播VPN解决方案部署的可伸缩性预期有关，因为作者选择不将范围限制在当前已知的部署。
From the survey results, we see a broad range of expectations. There are extreme answers: from 5 VPNs (1 answer) to 10k VPNs (1 answer), but more typical answers are split between the low range of tens of VPNs (7 answers) and the higher range of hundreds or thousands of VPNs (2 + 4 answers).
从调查结果中，我们看到了广泛的期望。有一些极端的答案：从5个VPN（1个答案）到10k VPN（1个答案），但更典型的答案分为低范围的数十个VPN（7个答案）和高范围的数百或数千个VPN（2+4个答案）。
A solution SHOULD support a number of multicast VPNs ranging from one to several thousands.
解决方案应支持从一个到数千个不等的多播VPN。
A solution SHOULD NOT limit the proportion of multicast VPNs among all (unicast) VPNs.
解决方案不应限制所有（单播）VPN中多播VPN的比例。
The majority of survey answers express a number of multicast VPNs per PE of around tens (8 responses between 5 and 50); a significant number of them (4) expect deployments with hundreds or thousands (1 response) of multicast VPNs per PE.
大多数调查答案表示，每个PE的多播VPN数量约为10个（8个响应介于5和50之间）；其中相当一部分（4）预期部署时每个PE有数百或数千（1个响应）多播VPN。
A solution SHOULD support a number of multicast VPNs per PE of several hundreds, and may have to scale up to thousands of VPNs per PE.
一个解决方案应该支持每个PE数百个多播VPN，并且可能必须扩展到每个PE数千个VPN。
Survey responses span from 1 to 2000 CEs per multicast VPN per PE. Most typical responses are between tens (6 answers) and hundreds (4 responses).
调查响应范围为每个多播VPN每个PE 1到2000个CE。最典型的回答介于十（6个答案）和数百（4个答案）之间。
A solution SHOULD support a number of CEs per multicast VPN per PE going up to several hundreds (and may target the support of thousands of CEs).
一个解决方案应该支持每个多播VPN每个PE的CE数量，最多可达数百个（并且可能支持数千个CE）。
People who answered the survey typically expect deployments with the number of PEs per multicast VPN in the range of hundreds of PEs (6 responses) or tens of PEs (4 responses). Two responses were in the range of thousands (one mentioned a 10k figure).
回答调查的人通常期望部署的每个多播VPN的PE数量在数百个PE（6个响应）或数十个PE（4个响应）之间。两个回答的范围为数千（其中一个提到了10公里的数字）。
A multicast VPN solution SHOULD support several hundreds of PEs per multicast VPN, and MAY usefully scale up to thousands.
多播VPN解决方案应该支持每个多播VPN数百个PE，并且可以有效地扩展到数千个。
The number of PEs (per VPN) that would be connected to sources seems to be significantly lower than the number of PEs per VPN. This is obviously related to the fact that many respondents mentioned deployments related to content broadcast applications (one to many).
连接到源的PE（每个VPN）数量似乎明显低于每个VPN的PE数量。这显然与以下事实有关：许多受访者提到与内容广播应用程序相关的部署（一对多）。
Typical numbers are tens (6 responses) or hundreds (4 responses) of source-connected PEs. One respondent expected a higher number of several thousands.
典型的数字是数十（6个响应）或数百（4个响应）的源连接PE。一位受访者预计会有数千人。
A solution SHOULD support hundreds of source-connected PEs per VPN, and some deployment scenarios involving many-to-many applications may require supporting a number of source-connected PEs equal to the number of PEs (hundreds or thousands).
一个解决方案应该支持每个VPN数百个源连接的PE，一些涉及多对多应用程序的部署场景可能需要支持与PE数量相等的源连接的PE数量（数百或数千）。
The survey showed that the number of PEs with receivers is expected to be of the same order of magnitude as the number of PEs in a multicast VPN. This is consistent with the intrinsic nature of most multicast applications, which have few source-only participants.
调查显示，具有接收器的PE数量预计与多播VPN中的PE数量具有相同的数量级。这与大多数多播应用程序的固有特性是一致的，这些应用程序只有很少的源参与者。
A solution SHOULD scale up to thousands of PEs having multicast service enabled.
一个解决方案应该扩展到数千个启用了多播服务的PE。
Survey responses led us to retain the following orders of magnitude for the number of streams that a solution SHOULD support:
调查结果使我们保留了解决方案应支持的流数量的以下数量级：
per VPN: hundreds or thousands of streams
每VPN：数百或数千条流
per PE: hundreds of streams
每个PE：数百条流
Again, the aim of this document is not to specify solutions but to give requirements for supporting IP multicast within L3 PPVPNs.
同样，本文档的目的不是指定解决方案，而是给出在L3 PPVPN中支持IP多播的要求。
In order to list these requirements, we have taken the standpoint of two different important entities: the end user (the customer using the VPN) and the service provider.
为了列出这些要求，我们从两个不同的重要实体出发：最终用户（使用VPN的客户）和服务提供商。
In the rest of the document, by "a solution" or "a multicast VPN solution", we mean a solution that allows multicast in an L3 provider-provisioned VPN, and which addresses the requirements listed in this document.
在本文档的其余部分中，我们所说的“解决方案”或“多播VPN解决方案”是指允许在L3提供商提供的VPN中多播并满足本文档中列出的要求的解决方案。
As for unicast, the multicast service MUST be provider provisioned and SHALL NOT require customer devices (CEs) to support any extra features compared to those required for multicast in a non-VPN context. Enabling a VPN for multicast support SHOULD be possible with no impact (or very limited impact) on existing multicast protocols possibly already deployed on the CE devices.
对于单播，多播服务必须由提供商提供，并且与非VPN上下文中多播所需的功能相比，不应要求客户设备（CE）支持任何额外功能。为多播支持启用VPN应该是可能的，对CE设备上可能已经部署的现有多播协议没有影响（或影响非常有限）。
Consequently to Section 5.1.1, multicast-related protocol exchanges between a CE and its directly connected PE SHOULD happen via existing multicast protocols.
因此，根据第5.1.1节，CE与其直接连接的PE之间的多播相关协议交换应通过现有多播协议进行。
Such protocols include: PIM-SM [RFC4601], bidirectional-PIM [BIDIR-PIM], PIM - Dense Mode (DM) [RFC3973], and IGMPv3 [RFC3376] (this version implicitly supports hosts that only implement IGMPv1 [RFC1112] or IGMPv2 [RFC2236]).
此类协议包括：PIM-SM[RFC4601]、双向PIM[BIDIR-PIM]、PIM-密集模式（DM）[RFC3973]和IGMPv3[RFC3376]（此版本隐式支持仅实现IGMPv1[RFC1112]或IGMPv2[RFC2236]的主机）。
Among those protocols, the support of PIM-SM (which includes the SSM model) and either IGMPv3 (for IPv4 solutions) and/or Multicast Listener Discovery Version 2 (MLDv2) [RFC3810] (for IPv6 solutions) is REQUIRED. Bidir-PIM support at the PE-CE interface is RECOMMENDED. And considering deployments, PIM-DM is considered OPTIONAL.
在这些协议中，需要PIM-SM（包括SSM模型）和IGMPv3（用于IPv4解决方案）和/或多播侦听器发现版本2（MLDv2）[RFC3810]（用于IPv6解决方案）的支持。建议在PE-CE接口上支持Bidir PIM。考虑到部署，PIM-DM被认为是可选的。
When a multicast VPN solution is built on a VPN solution supporting IPv6 unicast, it MUST also support v6 variants of the above protocols, including MLDv2, and PIM-SM IPv6-specific procedures. For a multicast VPN solution built on a unicast VPN solution supporting only IPv4, it is RECOMMENDED that the design favors the definition of procedures and encodings that will provide an easy adaptation to IPv6.
当多播VPN解决方案构建在支持IPv6单播的VPN解决方案上时，它还必须支持上述协议的v6变体，包括MLDv2和PIM-SM IPv6特定过程。对于基于仅支持IPv4的单播VPN解决方案构建的多播VPN解决方案，建议该设计有利于定义可轻松适应IPv6的过程和编码。
Firstly, general considerations regarding QoS in L3VPNs expressed in Section 5.5 of [RFC4031] are also relevant to this section.
首先，[RFC4031]第5.5节中表示的L3VPN中有关QoS的一般注意事项也与本节相关。
QoS is measured in terms of delay, jitter, packet loss, and availability. These metrics are already defined for the current unicast PPVPN services and are included in Service Level Agreements (SLAs). In some cases, the agreed SLA may be different between unicast and multicast, and that will require differentiation mechanisms in order to monitor both SLAs.
QoS是根据延迟、抖动、数据包丢失和可用性来衡量的。这些指标已经为当前的单播PPVPN服务定义，并包含在服务级别协议（SLA）中。在某些情况下，单播和多播之间约定的SLA可能不同，这将需要区分机制来监控这两个SLA。
The level of availability for the multicast service SHOULD be on par with what exists for unicast traffic. For instance, comparable traffic protection mechanisms SHOULD be available for customer multicast traffic when it is carried over the service provider's network.
多播服务的可用性水平应该与单播业务存在的水平一致。例如，当客户多播流量通过服务提供商的网络传输时，应为其提供类似的流量保护机制。
A multicast VPN solution SHALL allow a service provider to define at least the same level of quality of service as exists for unicast, and as exists for multicast in a non-VPN context. From this perspective, the deployment of multicast-based services within an L3VPN
多播VPN解决方案应允许服务提供商定义至少与单播和非VPN上下文中多播相同的服务质量级别。从这个角度来看，在L3VPN中部署基于多播的服务
environment SHALL benefit from Diffserv [RFC2475] mechanisms that include multicast traffic identification, classification, and marking capabilities, as well as multicast traffic policing, scheduling, and conditioning capabilities. Such capabilities MUST therefore be supported by any participating device in the establishment and the maintenance of the multicast distribution tunnel within the VPN.
环境应受益于Diffserv[RFC2475]机制，该机制包括多播流量识别、分类和标记功能，以及多播流量监控、调度和调节功能。因此，在VPN内建立和维护多播分发隧道的任何参与设备都必须支持这种能力。
As multicast is often used to deliver high-quality services such as TV broadcast, a multicast VPN solution MAY provide additional features to support high QoS such as bandwidth reservation and admission control.
由于多播通常用于提供诸如电视广播之类的高质量服务，因此多播VPN解决方案可以提供额外的功能来支持诸如带宽预留和接纳控制之类的高QoS。
Also, considering that multicast reception is receiver-triggered, group join delay (as defined in [RFC2432]) is also considered one important QoS parameter. It is thus RECOMMENDED that a multicast VPN solution be designed appropriately in this regard.
此外，考虑到多播接收是由接收机触发的，组加入延迟（如[RFC2432]中所定义）也被认为是一个重要的QoS参数。因此，建议在这方面适当设计多播VPN解决方案。
The group leave delay (as defined in [RFC2432]) may also be important on the CE-PE link for some usage scenarios: in cases where the typical bandwidth of multicast streams is close to the bandwidth of a PE-CE link, it will be important to have the ability to stop the emission of a stream on the PE-CE link as soon as it stops being requested by the CE, to allow for fast switching between two different high-throughput multicast streams. This implies that it SHOULD be possible to tune the multicast routing or group management protocols (e.g., IGMP/MLD or PIM) used on the PE-CE adjacency to reduce the group leave delay to the minimum.
对于某些使用场景，组离开延迟（如[RFC2432]中所定义）在CE-PE链路上也可能很重要：在多播流的典型带宽接近PE-CE链路带宽的情况下，一旦PE-CE链路上的流停止被CE请求，就必须能够停止该流的发射，以允许在两个不同的高吞吐量多播流之间快速切换。这意味着应该可以调整PE-CE邻接上使用的多播路由或组管理协议（例如，IGMP/MLD或PIM），以将组离开延迟降至最低。
Lastly, a multicast VPN solution SHOULD as much as possible ensure that client multicast traffic packets are neither lost nor duplicated, even when changes occur in the way a client multicast data stream is carried over the provider network. Packet loss issues also have to be considered when a new source starts to send traffic to a group: any receiver interested in receiving such traffic SHOULD be serviced accordingly.
最后，多播VPN解决方案应尽可能确保客户端多播流量数据包不会丢失或重复，即使在提供商网络上承载客户端多播数据流的方式发生变化时也是如此。当一个新的信源开始向一个组发送流量时，还必须考虑丢包问题：任何有兴趣接收这种流量的接收器都应该得到相应的服务。
The requirements and definitions for operations and management (OAM) of L3VPNs that are defined in [RFC4176] equally apply to multicast, and are not extensively repeated in this document. This sub-section mentions the most important guidelines and details points of particular relevance in the context of multicast in L3VPNs.
[RFC4176]中定义的L3VPN的操作和管理（OAM）要求和定义同样适用于多播，本文档中没有大量重复。本小节介绍了L3VPN中多播上下文中最重要的指导原则和特别相关的细节点。
A multicast VPN solution SHOULD allow a multicast VPN customer to manage the capabilities and characteristics of their multicast VPN services.
多播VPN解决方案应允许多播VPN客户管理其多播VPN服务的功能和特征。
A multicast VPN solution MUST support SLA monitoring capabilities, which SHOULD rely upon techniques similar to those used for the unicast service for the same monitoring purposes. Multicast SLA-related metrics SHOULD be available through means similar to the ones already used for unicast-related monitoring, such as Simple Network Management Protocol (SNMP) [RFC3411] or IPFIX [IPFIX-PROT].
多播VPN解决方案必须支持SLA监控功能，该功能应依赖于与用于相同监控目的的单播服务类似的技术。多播SLA相关指标应通过类似于已用于单播相关监控的手段提供，如简单网络管理协议（SNMP）[RFC3411]或IPFIX[IPFIX-PROT]。
Multicast-specific characteristics that may be monitored include: multicast statistics per stream, end-to-end delay, and group join/ leave delay (time to start/stop receiving a multicast group's traffic across the VPN, as defined in [RFC2432], Section 3).
可监控的多播特定特性包括：每个流的多播统计数据、端到端延迟和组加入/离开延迟（开始/停止通过VPN接收多播组流量的时间，如[RFC2432]第3节中所定义）。
The monitoring of multicast-specific parameters and statistics MUST include multicast traffic statistics: total/incoming/outgoing/dropped traffic, by period of time. It MAY include IP Performance Metrics related information (IPPM, [RFC2330]) that is relevant to the multicast traffic usage: such information includes the one-way packet delay, the inter-packet delay variation, etc. See [MULTIMETRICS].
多播特定参数和统计信息的监控必须包括多播流量统计信息：按时间段划分的总/传入/传出/丢弃流量。它可以包括与多播通信量使用相关的IP性能度量相关信息（IPPM，[RFC2330]）：此类信息包括单向分组延迟、分组间延迟变化等。请参阅[多度量]。
A generic discussion of SLAs is provided in [RFC3809].
[RFC3809]中提供了对SLA的一般讨论。
Apart from statistics on multicast traffic, customers of a multicast VPN will need information concerning the status of their multicast resource usage (multicast routing states and bandwidth). Indeed, as mentioned in Section 5.2.5, for scalability purposes, a service provider may limit the number (and/or throughput) of multicast streams that are received/sent to/from a client site. In such a case, a multicast VPN solution SHOULD allow customers to find out their current resource usage (multicast routing states and throughput), and to receive some kind of feedback if their usage exceeds the agreed bounds. Whether this issue will be better handled at the protocol level at the PE-CE interface or at the Service Management Level interface [RFC4176] is left for further discussion.
除了多播流量的统计数据外，多播VPN的客户还需要有关其多播资源使用状态（多播路由状态和带宽）的信息。实际上，如第5.2.5节所述，出于可伸缩性的目的，服务提供商可以限制接收/发送到/来自客户端站点的多播流的数量（和/或吞吐量）。在这种情况下，多播VPN解决方案应允许客户了解其当前资源使用情况（多播路由状态和吞吐量），并在其使用情况超过约定的界限时接收某种反馈。这个问题是在PE-CE接口的协议级还是在服务管理级接口[RFC4176]上得到更好的处理还有待进一步讨论。
It is RECOMMENDED that any OAM mechanism designed to trigger alarms in relation to performance or resource usage metrics integrate the ability to limit the rate at which such alarms are generated (e.g., some form of a hysteresis mechanism based on low/high thresholds defined for the metrics).
建议设计用于触发与性能或资源使用指标相关的警报的任何OAM机制集成限制此类警报生成速率的能力（例如，基于为指标定义的低/高阈值的某种形式的滞后机制）。
Security is a key point for a customer who uses a VPN service. For instance, the [RFC4364] model offers some guarantees concerning the security level of data transmission within the VPN.
对于使用VPN服务的客户来说，安全性是一个关键点。例如，[RFC4364]模型就VPN内数据传输的安全级别提供了一些保证。
A multicast VPN solution MUST provide an architecture with the same level of security for both unicast and multicast traffic.
多播VPN解决方案必须为单播和多播流量提供具有相同安全级别的体系结构。
Moreover, the activation of multicast features SHOULD be possible:
此外，应该可以激活多播功能：
o per VRF / per VR
o 每VRF/每VR
o per CE interface (when multiple CEs of a VPN are connected to a common VRF/VR)
o 每个CE接口（当VPN的多个CE连接到公共VRF/VR时）
o per multicast group and/or per channel
o 每个多播组和/或每个通道
o with a distinction between multicast reception and emission
o 区分多播接收和发射
A multicast VPN solution may choose to make the optimality/ scalability trade-off stated in Section 3.3 by sometimes distributing multicast traffic of a client group to a larger set of PE routers that may include PEs that are not part of the VPN. From a security standpoint, this may be a problem for some VPN customers; thus, a multicast VPN solution using such a scheme MAY offer ways to avoid this for specific customers (and/or specific customer multicast streams).
多播VPN解决方案可选择通过有时将客户端组的多播流量分配给可能包括不属于VPN的PE的更大PE路由器集，来实现第3.3节中所述的最佳性/可伸缩性权衡。从安全角度来看，这可能是一些VPN客户的问题；因此，使用这种方案的多播VPN解决方案可以为特定客户（和/或特定客户多播流）提供避免这种情况的方法。
In current PP L3VPN models, a customer site may be set up to be part of multiple VPNs, and this should still be possible when a VPN is multicast-enabled. In practice, it means that a VRF or VR can be part of more than one VPN.
在当前的PP L3VPN模型中，可以将客户站点设置为多个VPN的一部分，并且当VPN启用多播时，这仍然是可能的。实际上，这意味着VRF或VR可以是多个VPN的一部分。
A multicast VPN solution MUST support such deployments.
多播VPN解决方案必须支持此类部署。
For instance, it must be possible to configure a VRF so that an enterprise site participating in a BGP/MPLS multicast-enabled VPN and connected to that VRF can receive a multicast stream from (or originate a multicast stream towards) another VPN that would be associated to that VRF.
例如，必须能够配置VRF，以便参与启用BGP/MPLS多播的VPN并连接到该VRF的企业站点能够从（或发起指向）将与该VRF关联的另一VPN的多播流接收多播流。
This means that a multicast VPN solution MUST offer means for a VRF to be configured so that multicast connectivity can be set up for a chosen set of extranet VPNs. More precisely, it MUST be possible to configure a VRF so that:
这意味着多播VPN解决方案必须提供配置VRF的方法，以便可以为选定的一组外联网VPN设置多播连接。更准确地说，必须能够配置VRF，以便：
o receivers behind attached CEs can receive multicast traffic sourced in the configured set of extranet VPNs
o 连接的CEs后面的接收器可以接收源于配置的外部网络VPN集中的多播流量
o sources behind attached CEs can reach multicast traffic receivers located in the configured set of extranet VPNs
o 连接的CEs后面的源可以到达位于配置的外部网VPN集中的多播流量接收器
o multicast reception and emission can be independently enabled for each of the extranet VPNs
o 可以为每个外部网VPN独立启用多播接收和发射
Moreover, a solution MUST allow service providers to control an extranet's multicast connectivity independently from the extranet's unicast connectivity. More specifically:
此外，解决方案必须允许服务提供商独立于外联网的单播连接控制外联网的多播连接。更具体地说：
o enabling unicast connectivity to another VPN MUST be possible without activating multicast connectivity with that VPN
o 必须能够启用到另一个VPN的单播连接，而无需激活与该VPN的多播连接
o enabling multicast connectivity with another VPN SHOULD NOT require more than the strict minimal unicast routing. Sending multicast to a VPN SHOULD NOT require having unicast routes to that VPN; receiving multicast from a VPN SHOULD be possible with nothing more than unicast routes to the relevant multicast sources of that VPN
o 启用与另一个VPN的多播连接不应要求严格的最小单播路由。向VPN发送多播不应要求具有到该VPN的单播路由；从VPN接收多播应该只需要单播路由就可以到达该VPN的相关多播源
o when unicast routes from another VPN are imported into a VR/VRF, for multicast Reverse Path Forwarding (RPF) resolution, this SHOULD be possible without making those routes available for unicast routing
o 当来自另一个VPN的单播路由导入到VR/VRF中时，对于多播反向路径转发（RPF）解决方案，这应该是可能的，而无需使这些路由可用于单播路由
Proper support for this feature SHOULD NOT require replicating multicast traffic on a PE-CE link, whether it is a physical or logical link.
对此功能的适当支持不应要求在PE-CE链路上复制多播流量，无论是物理链路还是逻辑链路。
Connectivity with Internet Multicast is a particular case of the previous section, where sites attached to a VR/VRF would need to receive/send multicast traffic from/to the Internet.
与Internet多播的连接是上一节的一个特例，其中连接到VR/VRF的站点需要从Internet接收/发送多播流量。
This should be considered OPTIONAL given the additional considerations, such as security, needed to fulfill the requirements for providing Internet Multicast.
考虑到满足提供Internet多播的要求所需的其他考虑因素（如安全性），这应该被视为可选的。
Many L3 PPVPN solutions, such as [RFC4364] and [VRs], define the "Carrier's Carrier" model, where a "carrier's carrier" service provider supports one or more customer ISPs, or "sub-carriers". A multicast VPN solution SHOULD support the carrier's carrier model in a scalable and efficient manner.
许多L3 PPVPN解决方案，如[RFC4364]和[VRs]，定义了“运营商运营商”模式，其中“运营商运营商”服务提供商支持一个或多个客户ISP或“子运营商”。多播VPN解决方案应以可扩展和高效的方式支持运营商的运营商模型。
Ideally, the range of tunneling protocols available for the sub-carrier ISP should be the same as those available for the carrier's carrier ISP. This implies that the protocols that may be used at the PE-CE level SHOULD NOT be restricted to protocols required as per Section 5.1.2 and SHOULD include some of the protocols listed in Section 5.2.4, such as for instance P2MP MPLS signaling protocols.
理想情况下，子载波ISP可用的隧道协议范围应与载波ISP可用的隧道协议范围相同。这意味着可在PE-CE级别使用的协议不应限于第5.1.2节要求的协议，并且应包括第5.2.4节中列出的一些协议，例如P2MP MPLS信令协议。
In the context of MPLS-based L3VPN deployments, such as BGP/MPLS VPNs [RFC4364], this means that MPLS label distribution SHOULD happen at the PE-CE level, giving the ability to the sub-carrier to use multipoint LSPs as a tunneling mechanism.
在基于MPLS的L3VPN部署环境中，如BGP/MPLS VPN[RFC4364]，这意味着MPLS标签分发应在PE-CE级别进行，使子载波能够使用多点LSP作为隧道机制。
A multicast VPN solution SHOULD be compatible with current solutions that aim at improving the service robustness for customers such as multi-homing, CE-PE link load balancing, and fail-over. A multicast VPN solution SHOULD also be able to offer those same features for multicast traffic.
多播VPN解决方案应与旨在提高客户服务健壮性的当前解决方案兼容，如多归属、CE-PE链路负载平衡和故障转移。多播VPN解决方案还应该能够为多播流量提供相同的功能。
Any solution SHOULD support redundant topology of CE-PE links. It SHOULD minimize multicast traffic disruption and fail-over.
任何解决方案都应支持CE-PE链路的冗余拓扑。它应该最小化多播通信中断和故障转移。
When PIM-SM (or bidir-PIM) is used in ASM mode on the VPN customer side, the RP function (or RP-address in the case of bidir-PIM) has to be associated to a node running PIM, and configured on this node.
当在VPN客户端的ASM模式下使用PIM-SM（或bidir PIM）时，RP功能（或bidir PIM情况下的RP地址）必须与运行PIM的节点相关联，并在此节点上进行配置。
In the case of PIM-SM in ASM mode, engineering of the RP function requires the deployment of specific protocols and associated configurations. A service provider may offer to manage customers' multicast protocol operation on their behalf. This implies that it is necessary to consider cases where a customer's RPs are outsourced (e.g., on PEs). Consequently, a VPN solution MAY support the hosting of the RP function in a VR or VRF.
对于ASM模式下的PIM-SM，RP功能的工程设计需要部署特定协议和相关配置。服务提供商可以代表客户管理其多播协议操作。这意味着有必要考虑客户的RPS外包的情况（例如，在PES上）。因此，VPN解决方案可支持在VR或VRF中托管RP功能。
Availability of the RP function (or address) is required for proper operation of PIM-SM (ASM mode) and bidir-PIM. Loss of connectivity to the RP from a receiver or source will impact the multicast service. For this reason, different mechanisms exist, such as BSR [PIM-BSR] or anycast-RP (Multicast Source Discovery Protocol (MSDP)- based [RFC3446] or PIM-based [RFC4610]).
正确操作PIM-SM（ASM模式）和bidir PIM需要RP功能（或地址）的可用性。接收器或源与RP的连接中断将影响多播服务。因此，存在不同的机制，例如BSR[PIM-BSR]或基于多播源发现协议（MSDP）的[RFC3446]或基于PIM的[RFC4610]）。
These protocols and procedures SHOULD work transparently through a multicast VPN, and MAY if relevant, be implemented in a VRF/VR.
这些协议和过程应该通过多播VPN透明地工作，如果相关，可以在VRF/VR中实现。
Moreover, a multicast VPN solution MAY improve the robustness of the ASM multicast service regarding loss of connectivity to the RP, by providing specific features that help:
此外，多播VPN解决方案可通过提供有助于以下各项的特定功能来提高ASM多播服务在与RP的连接丢失方面的健壮性：
a) maintain ASM multicast service among all the sites within an MVPN that maintain connectivity among themselves, even when the site(s) hosting the RP lose their connectivity to the MVPN
a) 在MVPN内所有站点之间维护ASM多播服务，这些站点之间保持连接，即使承载RP的站点失去与MVPN的连接
b) maintain ASM multicast service within any site that loses connectivity to the service provider
b) 在与服务提供商失去连接的任何站点内维护ASM多播服务
In the case of PIM-SM, when a source starts to emit traffic toward a group (in ASM mode), if sources and receivers are located in VPN sites that are different than that of the RP, then traffic may transiently flow twice through the SP network and the CE-PE link of the RP (from source to RP, and then from RP to receivers). This traffic peak, even short, may not be convenient depending on the traffic and link bandwidth.
在PIM-SM的情况下，当源开始向组发送流量时（在ASM模式下），如果源和接收器位于不同于RP的VPN站点中，则流量可能会暂时流经SP网络和RP的CE-PE链路两次（从源到RP，然后从RP到接收器）。此流量峰值即使很短，也可能不方便，具体取决于流量和链路带宽。
Thus, a VPN solution MAY provide features that solve or help mitigate this potential issue.
因此，VPN解决方案可以提供解决或帮助缓解此潜在问题的功能。
A multicast provider-provisioned L3VPN SHOULD NOT impose restrictions on multicast group addresses used by VPN customers.
多播提供商提供的L3VPN不应对VPN客户使用的多播组地址施加限制。
In particular, like unicast traffic, an overlap of multicast group address sets used by different VPN customers MUST be supported.
特别是，与单播通信一样，必须支持不同VPN客户使用的多播组地址集的重叠。
The use of globally unique means of multicast-based service identification at the scale of the domain where such services are provided SHOULD be recommended. For IPv4 multicast, this implies the use of the multicast administratively scoped range (239/8 as defined by [RFC2365]) for services that are to be used only inside the VPN, and of either SSM-range addresses (232/8 as defined by [RFC4607]) or globally assigned group addresses (e.g., GLOP [RFC3180], 233/8) for services for which traffic may be transmitted outside the VPN.
应建议在提供此类服务的域范围内使用全球唯一的基于多播的服务识别方法。对于IPv4多播，这意味着对仅在VPN内部使用的服务使用多播管理范围（由[RFC2365]定义的239/8）以及SSM范围地址（由[RFC4607]定义的232/8）或全局分配的组地址（例如，GLOP[RFC3180]，233/8）用于可在VPN外部传输流量的服务。
For customers, it is often a serious issue whether or not transmitted packets will be fragmented. In particular, some multicast applications might have different requirements than those that make use of unicast, and they may expect services that guarantee available packet length not to be fragmented.
对于客户来说，传输的数据包是否会被碎片化通常是一个严重的问题。特别是，一些多播应用程序可能与使用单播的应用程序有不同的要求，并且它们可能期望保证可用数据包长度不被分段的服务。
Therefore, a multicast VPN solution SHOULD be designed with these considerations in mind. In practice:
因此，设计多播VPN解决方案时应考虑这些因素。实际上：
o the encapsulation overhead of a multicast VPN solution SHOULD be minimized, so that customer devices can be free of fragmentation and reassembly activity as much as possible
o 应尽量减少多播VPN解决方案的封装开销，以便客户设备尽可能避免碎片和重组活动
o a multicast VPN solution SHOULD enable the service provider to commit to a minimum path MTU usable by multicast VPN customers
o 多播VPN解决方案应使服务提供商能够提交多播VPN客户可用的最小路径MTU
o a multicast VPN solution SHOULD be compatible with path MTU discovery mechanisms (see [RFC1191] and [RFC4459]), and particular care SHOULD be given to means to help troubleshoot MTU issues
o 多播VPN解决方案应与路径MTU发现机制兼容（请参阅[RFC1191]和[RFC4459]），并且应特别注意帮助解决MTU问题的方法
Moreover, since Ethernet LAN segments are often located at first and last hops, a multicast VPN solution SHOULD be designed to allow for a minimum 1500-byte IP MTU for VPN customers multicast packet, when the provider backbone design allows it.
此外，由于以太网LAN段通常位于第一个和最后一个跃点，因此应设计多播VPN解决方案，以便在提供商主干网设计允许的情况下，为VPN客户多播数据包提供至少1500字节的IP MTU。
Note: To avoid repetition and confusion with terms used in solution specifications, we introduced in Section 2.1 the term MDTunnel (for Multicast Distribution Tunnel), which designates the data plane means used by the service provider to forward customer multicast traffic over the core network.
注：为了避免与解决方案规范中使用的术语重复和混淆，我们在第2.1节中引入了术语MDTunnel（用于多播分发隧道），它指定了服务提供商用于通过核心网络转发客户多播流量的数据平面方式。
The deployment of a multicast VPN solution SHOULD be possible with no (or very limited) impact on existing deployments of standardized multicast-related protocols on P and PE routers.
多播VPN解决方案的部署应该可以对P和PE路由器上标准化多播相关协议的现有部署没有（或非常有限）影响。
Some currently standardized and deployed L3VPN solutions have the major advantage of being scalable in the core regarding the number of customers and the number of customer routes. For instance, in the [RFC4364] and Virtual Router [VRs] models, a P router sees a number of MPLS tunnels that is only linked to the number of PEs and not to the number of VPNs, or customer sites.
一些目前已标准化和部署的L3VPN解决方案的主要优势是，在客户数量和客户路由数量方面，其核心具有可扩展性。例如，在[RFC4364]和虚拟路由器[VRs]模型中，P路由器可以看到许多MPLS隧道，这些隧道只与PE的数量相链接，而不与VPN或客户站点的数量相链接。
As far as possible, this independence in the core, with respect to the number of customers and to customer activity, is recommended. Yet, it is recognized that in our context scalability and resource usage optimality are competing goals, so this requirement may be reduced to giving the possibility of bounding the quantity of states that the service provider needs to maintain in the core for MDTunnels, with a bound being independent of the multicast activity of VPN customers.
建议尽可能做到与客户数量和客户活动相关的核心独立性。然而，我们认识到，在我们的环境中，可伸缩性和资源使用优化是相互竞争的目标，因此，这一要求可能会降低为服务提供商在MDTunnels核心中需要维护的状态数量提供边界，边界独立于VPN客户的多播活动。
It is expected that multicast VPN solutions will use some kind of point-to-multipoint technology to efficiently carry multicast VPN traffic, and because such technologies require maintaining state information, this will use resources in the control plane of P and PE routers (memory and processing, and possibly address space).
预计多播VPN解决方案将使用某种点对多点技术来高效承载多播VPN流量，并且由于此类技术需要维护状态信息，因此将使用P和PE路由器控制平面中的资源（内存和处理，以及可能的地址空间）。
Scalability is a key requirement for multicast VPN solutions. Solutions MUST be designed to scale well with an increase in any of the following:
可扩展性是多播VPN解决方案的关键要求。解决方案的设计必须能够随着以下任何一项的增加而很好地扩展：
o the number of PEs
o PEs的数量
o the number of customer VPNs (total and per PE)
o 客户VPN的数量（总数和每个PE）
o the number of PEs and sites in any VPN
o 任何VPN中的PE和站点数
o the number of client multicast channels (groups or source-groups)
o 客户端多播通道数（组或源组）
Please consult Section 4.2 for typical orders of magnitude up to which a multicast VPN solution is expected to scale.
请参阅第4.2节，了解多播VPN解决方案预计可扩展到的典型数量级。
Scalability of both performance and operation MUST be considered.
必须考虑性能和操作的可伸缩性。
Key considerations SHOULD include:
主要考虑因素应包括：
o the processing resources required by the control plane (neighborhood or session maintenance messages, keep-alives, timers, etc.)
o 控制平面所需的处理资源（邻居或会话维护消息、保持生命、计时器等）
o the memory resources needed for the control plane
o 控制平面所需的内存资源
o the amount of protocol information transmitted to manage a multicast VPN (e.g., signaling throughput)
o 为管理多播VPN而传输的协议信息量（例如，信令吞吐量）
o the amount of control plane processing required on PE and P routers to add or remove a customer site (or a customer from a multicast session)
o 在PE和P路由器上添加或删除客户站点（或从多播会话中删除客户）所需的控制平面处理量
o the number of multicast IP addresses used (if IP multicast in ASM mode is proposed as a multicast distribution tunnel)
o 使用的多播IP地址数（如果ASM模式下的IP多播被建议作为多播分发隧道）
o other particular elements inherent to each solution that impact scalability (e.g., if a solution uses some distribution tree inside the core, topology of the tree and number of leaf nodes may be some of them)
o 每个解决方案固有的影响可伸缩性的其他特定元素（例如，如果解决方案在核心内使用某个分发树，则树的拓扑和叶节点的数量可能是其中的一部分）
It is expected that the applicability of each solution will be evaluated with regards to the aforementioned scalability criteria.
预计将根据上述可扩展性标准评估每个解决方案的适用性。
These considerations naturally lead us to believe that proposed solutions SHOULD offer the possibility of sharing such resources between different multicast streams (between different VPNs, between different multicast streams of the same or of different VPNs). This means, for instance, if MDTunnels are trees, being able to share an MDTunnel between several customers.
这些考虑因素自然使我们相信，建议的解决方案应提供在不同多播流之间（不同VPN之间，相同或不同VPN的不同多播流之间）共享此类资源的可能性。这意味着，例如，如果MDTunnel是树，则可以在多个客户之间共享MDTunnel。
Those scalability issues are expected to be more significant on P routers, but a multicast VPN solution SHOULD address both P and PE routers as far as scalability is concerned.
这些可伸缩性问题在P路由器上更为重要，但就可伸缩性而言，多播VPN解决方案应该同时解决P和PE路由器。
One of the aims of the use of multicast instead of unicast is resource optimization in the network.
使用多播代替单播的目的之一是优化网络中的资源。
The two obvious suboptimal behaviors that a multicast VPN solution would want to avoid are needless duplication (when the same data travels twice or more on a link, e.g., when doing ingress PE replication) and needless reception (e.g., a PE receiving traffic that it does not need because there are no downstream receivers).
多播VPN解决方案想要避免的两个明显的次优行为是不必要的复制（当相同的数据在链路上传输两次或两次以上时，例如，在进行入口PE复制时）和不必要的接收（例如，PE接收由于没有下游接收器而不需要的流量）。
As previously stated in this document, designing a scalable solution that makes an optimal use of resources is considered difficult. Thus, what is expected from a multicast VPN solution is that it addresses the resource optimization issue while taking into account the fact that some trade-off has to be made.
如前所述，设计一个可扩展的解决方案，使资源得到最佳利用被认为是困难的。因此，多播VPN解决方案的期望是，它解决了资源优化问题，同时考虑到必须进行一些权衡的事实。
Moreover, it seems that a "one size fits all" trade-off probably does not exist either. Thus, a multicast VPN solution SHOULD offer service providers appropriate configuration settings that let them tune the trade-off according to their particular constraints (network topology, platforms, customer applications, level of service offered etc.).
此外，似乎也不存在“一刀切”的权衡。因此，多播VPN解决方案应为服务提供商提供适当的配置设置，使其能够根据特定约束（网络拓扑、平台、客户应用程序、提供的服务级别等）调整权衡。
As an illustration, here are some example bounds of the trade-off space:
作为说明，以下是一些权衡空间的示例边界：
Bandwidth optimization: setting up optimized core MDTunnels whose topology (PIM or P2MP LSP trees, etc.) precisely follows a customer's multicast routing changes. This requires managing a large amount of state in the core, and also quick reactions of the core to customer multicast routing changes. This approach can be advantageous in terms of bandwidth, but it is poor in terms of state management.
带宽优化：设置优化的核心MDT隧道，其拓扑结构（PIM或P2MP LSP树等）精确跟踪客户的多播路由更改。这需要管理内核中的大量状态，还需要内核对客户多播路由更改做出快速反应。这种方法在带宽方面是有利的，但在状态管理方面却很差。
State optimization: setting up MDTunnels that aggregate multiple customer multicast streams (all or some of them, across different VPNs or not). This will have better scalability properties, but at the expense of bandwidth since some MDTunnel leaves will very likely receive traffic they don't need, and because increased constraints will make it harder to find optimal MDTunnels.
状态优化：设置聚合多个客户多播流的MDTunnel（所有或部分，是否跨不同的VPN）。这将具有更好的可伸缩性属性，但会以带宽为代价，因为一些MDTunnel叶子很可能会接收到它们不需要的流量，并且因为约束的增加会使找到最佳MDTunnel变得更加困难。
If the VPN service provides traffic engineering (TE) features for the connection used between PEs for unicast traffic in the VPN service, the solution SHOULD provide equivalent features for multicast traffic.
如果VPN服务为VPN服务中用于单播流量的PEs之间的连接提供流量工程（TE）功能，则解决方案应为多播流量提供等效功能。
A solution SHOULD offer means to support key TE objectives as defined in [RFC3272], for the multicast service.
解决方案应提供支持[RFC3272]中定义的多播服务关键TE目标的方法。
A solution MAY also usefully support means to address multicast-specific traffic engineering issues: it is known that bandwidth resource optimization in the point-to-multipoint case is an NP-hard problem, and that techniques used for unicast TE may not be applicable to multicast traffic.
解决方案还可以有效地支持解决多播特定流量工程问题的方法：众所周知，点对多点情况下的带宽资源优化是一个NP难问题，用于单播TE的技术可能不适用于多播流量。
Also, it has been identified that managing the trade-off between resource usage and scalability may incur uselessly sending traffic to some PEs participating in a multicast VPN. For this reason, a multicast VPN solution MAY permit that the bandwidth/state tuning take into account the relative cost or availability of bandwidth toward each PE.
此外，已经确定，管理资源使用和可伸缩性之间的权衡可能会导致向参与多播VPN的一些PEs无用地发送流量。因此，多播VPN解决方案可以允许带宽/状态调整考虑每个PE的带宽的相对成本或可用性。
Following the principle of separation between the control plane and the forwarding plane, a multicast VPN solution SHOULD be designed so that control and forwarding planes are not interdependent: the control plane SHALL NOT depend on which forwarding plane is used (and vice versa), and the choice of forwarding plane SHOULD NOT be limited
遵循控制平面和转发平面分离的原则，应设计多播VPN解决方案，使控制平面和转发平面不相互依赖：控制平面不应取决于使用哪个转发平面（反之亦然），并且转发平面的选择不应受到限制
by the design of the solution. Also, the solution SHOULD NOT be tied to a specific tunneling technology.
通过设计解决方案。此外，解决方案不应与特定的隧道技术相关联。
In a multicast VPN solution extending a unicast L3 PPVPN solution, consistency in the tunneling technology has to be favored: such a solution SHOULD allow the use of the same tunneling technology for multicast as for unicast. Deployment consistency, ease of operation, and potential migrations are the main motivations behind this requirement.
在扩展单播L3 PPVPN解决方案的多播VPN解决方案中，必须有利于隧道技术的一致性：这种解决方案应允许对多播使用与单播相同的隧道技术。部署一致性、易操作性和潜在的迁移是这一需求背后的主要动机。
For MDTunnels, a solution SHOULD be able to use a range of tunneling technologies, including point-to-point and point-to-multipoint, such as:
对于MDTunnels，解决方案应能够使用一系列隧道技术，包括点对点和点对多点，例如：
o Generic Routing Encapsulation (GRE) [RFC2784] (including GRE in multicast IP trees),
o 通用路由封装（GRE）[RFC2784]（包括多播IP树中的GRE），
o MPLS [RFC3031] (including P2P or MP2P tunnels, and multipoint tunnels signaled with MPLS P2MP extensions to the Resource Reservation Protocol (RSVP) [P2MP-RSVP-TE] or Label Distribution Protocol (LDP) [P2MP-LDP-REQS] [P2MP-LDP]),
o MPLS[RFC3031]（包括P2P或MP2P隧道，以及通过资源预留协议（RSVP）[P2MP-RSVP-TE]或标签分发协议（LDP）[P2MP-LDP-REQS][P2MP-LDP]的MPLS P2MP扩展发送信号的多点隧道），
o Layer-2 Tunneling Protocol (L2TP) (including L2TP for multicast [RFC4045]),
o 第二层隧道协议（L2TP）（包括用于多播的L2TP[RFC4045]），
o IPsec [RFC4031]
o IPsec[RFC4031]
o IP-in-IP [RFC2003], etc.
o IP[RFC2003]中的IP等。
Naturally, it is RECOMMENDED that a solution is built so that it can leverage the point-to-multipoint variants of these techniques. These variants allow for packet replications to happen along a tree in the provider core network, and they may help improve bandwidth efficiency in a multicast VPN context.
当然，建议构建一个解决方案，以便能够利用这些技术的点对多点变体。这些变体允许沿提供商核心网络中的树进行数据包复制，并且它们可能有助于提高多播VPN上下文中的带宽效率。
A solution SHOULD support a method that provides the minimum MTU of the MDTunnel (e.g., to discover MTU, to communicate MTU via signaling, etc.) so that:
解决方案应支持提供MDTunnel最小MTU的方法（例如，发现MTU、通过信令与MTU通信等），以便：
o fragmentation inside the MDTunnel does not happen, even when allowed by the underlying tunneling technology
o MDTunnel内部不会发生碎片，即使底层隧道技术允许
o proper troubleshooting can be performed if packets that are too big for the MDTunnel happen to be encapsulated in the MDTunnel
o 如果对MDTunnel来说太大的数据包恰好被封装在MDTunnel中，则可以执行适当的故障排除
The solution MUST provide some mechanisms to control the sources within a VPN. This control includes the number of sources that are entitled to send traffic on the VPN, and/or the total bit rate of all the sources.
解决方案必须提供一些机制来控制VPN内的源。此控制包括有权在VPN上发送流量的源的数量和/或所有源的总比特率。
At the reception level, the solution MUST also provide mechanisms to control the number of multicast groups or channels VPN users are entitled to subscribe to and/or the total bit rate represented by the corresponding multicast traffic.
在接收级别，解决方案还必须提供机制来控制VPN用户有权订阅的多播组或频道的数量和/或由相应多播流量表示的总比特率。
All these mechanisms MUST be configurable by the service provider in order to control the amount of multicast traffic and state within a VPN.
服务提供商必须配置所有这些机制，以便控制VPN内的多播流量和状态。
Moreover, it MAY be desirable to be able to impose some bound on the quantity of state used by a VPN in the core network for its multicast traffic, whether on each P or PE router, or globally. The motivation is that it may be needed to avoid out-of-resources situations (e.g., out of memory to maintain PIM state if IP multicast is used in the core for multicast VPN traffic, or out of memory to maintain RSVP state if MPLS P2MP is used, etc.).
此外，可能希望能够对核心网络中VPN用于其多播业务的状态量施加某种限制，无论是在每个P或PE路由器上，还是在全球范围内。其动机是，可能需要避免资源不足的情况（例如，如果在多播VPN流量的核心中使用IP多播，则内存不足以保持PIM状态；如果使用MPLS P2MP，则内存不足以保持RSVP状态，等等）。
A solution MUST support inter-AS (Autonomous System) multicast VPNs, and SHOULD support inter-provider multicast VPNs. Considerations about coexistence with unicast inter-AS VPN Options A, B, and C (as described in Section 10 of [RFC4364]) are strongly encouraged.
解决方案必须支持跨AS（自治系统）多播VPN，并应支持跨提供商多播VPN。强烈鼓励考虑与单播inter AS VPN选项A、B和C共存（如[RFC4364]第10节所述）。
A multicast VPN solution SHOULD provide inter-AS mechanisms requiring the least possible coordination between providers, and keep the need for detailed knowledge of providers' networks to a minimum -- all this being in comparison with corresponding unicast VPN options.
多播VPN解决方案应提供要求提供商之间尽可能少的协调的AS间机制，并将对提供商网络的详细信息的需求保持在最低程度——所有这些都与相应的单播VPN选项相比较。
o Within each service provider, the service provider SHOULD be able on its own to pick the most appropriate tunneling mechanism to carry (multicast) traffic among PEs (just like what is done today for unicast)
o 在每个服务提供商内部，服务提供商应能够自行选择最合适的隧道机制，以在PEs之间传输（多播）流量（就像现在单播所做的那样）
o If a solution does require a single tunnel to span P routers in multiple ASs, the solution SHOULD provide mechanisms to ensure that the inter-provider coordination to set up such a tunnel is minimized
o 如果一个解决方案确实需要一个隧道来跨越多个ASs中的P个路由器，那么该解决方案应该提供机制，以确保设置这样一个隧道的提供商间协调最小化
Moreover, such support SHOULD be possible without compromising other requirements expressed in this requirement document, and SHALL NOT incur penalties on scalability and bandwidth-related efficiency.
此外，此类支持应在不影响本需求文件中表达的其他需求的情况下可行，并且不会对可伸缩性和带宽相关效率造成处罚。
A multicast VPN solution SHOULD give a VPN service provider the ability to offer, guarantee and enforce differentiated levels of QoS for its different customers.
多播VPN解决方案应使VPN服务提供商能够为其不同的客户提供、保证和实施不同级别的QoS。
The solution SHOULD provide the same level of security for the service provider as what currently exists for unicast VPNs (for instance, as developed in the Security sections of [RFC4364] and [VRs]). For instance, traffic segregation and intrinsic protection against DoS (Denial of Service) and DDoS (Distributed Denial of Service) attacks of the BGP/MPLS VPN solution must be supported by the multicast solution.
该解决方案应为服务提供商提供与当前单播VPN相同的安全级别（例如，在[RFC4364]和[VRs]的安全部分中开发）。例如，多播解决方案必须支持流量隔离和针对BGP/MPLS VPN解决方案的DoS（拒绝服务）和DDoS（分布式拒绝服务）攻击的内在保护。
Moreover, since multicast traffic and routing are intrinsically dynamic (receiver-initiated), some mechanism SHOULD be proposed so that the frequency of changes in the way client traffic is carried over the core can be bounded and not tightly coupled to dynamic changes of multicast traffic in the customer network. For example, multicast route dampening functions would be one possible mechanism.
此外，由于多播通信量和路由本质上是动态的（由接收器发起），因此应提出一些机制，以便客户端通信量通过核心的方式的变化频率可以是有界的，而不是与客户网络中多播通信量的动态变化紧密耦合。例如，多播路由抑制功能将是一种可能的机制。
Network devices that participate in the deployment and the maintenance of a given L3VPN MAY represent a superset of the participating devices that are also involved in the establishment and maintenance of the multicast distribution tunnels. As such, the activation of IP multicast capabilities within a VPN SHOULD be device-specific, not only to make sure that only the relevant devices will be multicast-enabled, but also to make sure that multicast (routing) information will be disseminated to the multicast-enabled devices only, hence limiting the risk of multicast-inferred DOS attacks.
参与给定L3VPN的部署和维护的网络设备可以表示也参与多播分发隧道的建立和维护的参与设备的超集。因此，VPN内IP多播功能的激活应是特定于设备的，不仅要确保只有相关设备将启用多播，而且还要确保多播（路由）信息将仅传播到启用多播的设备，因此限制了多播推断DOS攻击的风险。
Traffic of a multicast channel for which there are no members in a given multicast VPN MUST NOT be propagated within the multicast VPN, most particularly if the traffic comes from another VPN or from the Internet.
给定多播VPN中没有成员的多播信道的流量不得在多播VPN内传播，尤其是当流量来自另一个VPN或Internet时。
Security considerations are particularly important for inter-AS and inter-provider deployments. In such cases, it is RECOMMENDED that a multicast VPN solution support means to ensure the integrity and authenticity of multicast-related exchanges across inter-AS or inter-provider borders. It is RECOMMENDED that corresponding procedures
安全考虑对于AS间和提供商间部署尤为重要。在这种情况下，建议多播VPN解决方案支持确保跨AS间或提供商间边界的多播相关交换的完整性和真实性。建议采用相应的程序
require the least possible coordination between providers; more precisely, when specific configurations or cryptographic keys have to be deployed, this shall be limited to ASBRs (Autonomous System Border Routers) or a subset of them, and optionally BGP Route Reflectors (or a subset of them).
要求供应商之间尽可能少的协调；更准确地说，当必须部署特定配置或加密密钥时，这应限于ASBR（自治系统边界路由器）或其子集，以及可选的BGP路由反射器（或其子集）。
Lastly, control mechanisms described in Section 5.2.5 are also to be considered from this infrastructure security point of view.
最后，第5.2.5节中描述的控制机制也应从基础设施安全的角度考虑。
Resiliency is also crucial to infrastructure security; thus, a multicast VPN solution SHOULD either avoid single points of failures or propose some technical solution making it possible to implement a fail-over mechanism.
恢复能力对基础设施安全也至关重要；因此，多播VPN解决方案应该避免单点故障，或者提出一些技术解决方案，使实现故障转移机制成为可能。
As an illustration, one can consider the case of a solution that would use PIM-SM as a means to set up MDTunnels. In such a case, the PIM RP might be a single point of failure. Such a solution SHOULD be compatible with a solution implementing RP resiliency, such as anycast-RP [RFC4610] or BSR [PIM-BSR].
作为一个例子，可以考虑使用PIM-SM作为设置MDTunnels的方法的解决方案的情况。在这种情况下，PIM RP可能是单点故障。此类解决方案应与实现RP弹性的解决方案兼容，如选播RP[RFC4610]或BSR[PIM-BSR]。
The operation of a multicast VPN solution SHALL be as light as possible, and providing automatic configuration and discovery SHOULD be a priority when designing a multicast VPN solution. Particularly, the operational burden of setting up multicast on a PE or for a VR/ VRF SHOULD be as low as possible.
多播VPN解决方案的操作应尽可能轻，在设计多播VPN解决方案时，应优先考虑提供自动配置和发现。特别是，在PE或VR/VRF上设置多播的操作负担应尽可能低。
Also, as far as possible, the design of a solution SHOULD carefully consider the number of protocols within the core network: if any additional protocols are introduced compared with the unicast VPN service, the balance between their advantage and operational burden SHOULD be examined thoroughly.
此外，尽可能地设计解决方案应仔细考虑核心网络中的协议数量：如果与单播VPN服务相比引入任何附加协议，则应充分检查它们的优点和操作负担之间的平衡。
Moreover, monitoring of multicast-specific parameters and statistics SHOULD be offered to the service provider, following the requirements expressed in [RFC4176].
此外，应按照[RFC4176]中的要求，向服务提供商提供多播特定参数和统计数据的监控。
Most notably, the provider SHOULD have access to:
最值得注意的是，供应商应能够访问：
o Multicast traffic statistics (incoming/outgoing/dropped/total traffic conveyed, by period of time)
o 多播流量统计（传入/传出/丢弃/传输的总流量，按时间段）
o Information about client multicast resource usage (multicast routing state and bandwidth usage)
o 有关客户端多播资源使用情况（多播路由状态和带宽使用情况）的信息
o Alarms when limits are reached on such resources
o 达到此类资源限制时发出警报
o The IPPM (IP Performance Metrics [RFC2330])-related information that is relevant to the multicast traffic usage: such information includes the one-way packet delay, the inter-packet delay variation, etc.
o IPPM（IP性能度量[RFC2330]）与多播通信量使用相关的信息：此类信息包括单向分组延迟、分组间延迟变化等。
o Statistics on decisions related to how client traffic is carried on distribution tunnels (e.g., "traffic switched onto a multicast tree dedicated to such groups or channels")
o 有关如何在分发隧道中承载客户端流量的决策的统计信息（例如，“切换到专用于此类组或通道的多播树上的流量”）
o Statistics on parameters that could help the provider to evaluate its optimality/state trade-off
o 有助于供应商评估其最佳性/状态权衡的参数统计数据
This information SHOULD be made available through standardized SMIv2 [RFC2578] Management Information Base (MIB) modules to be used with SNMP [RFC3411], or through IPFIX [IPFIX-PROT]. For instance, in the context of BGP/MPLS VPNs [RFC4364], multicast extensions to MIBs defined in [RFC4382] SHOULD be proposed, with proper integration with [RFC3811], [RFC3812], [RFC3813], and [RFC3814] when applicable.
该信息应通过与SNMP[RFC3411]一起使用的标准化SMIv2[RFC2578]管理信息库（MIB）模块或IPFIX[IPFIX-PROT]提供。例如，在BGP/MPLS VPN[RFC4364]的上下文中，应建议对[RFC4382]中定义的MIB进行多播扩展，并在适用时与[RFC3811]、[RFC3812]、[RFC3813]和[RFC3814]进行适当集成。
Mechanisms similar to those described in Section 5.2.12 SHOULD also exist for proactive monitoring of the MDTunnels.
还应存在与第5.2.12节所述机制类似的机制，以便对MDS隧道进行主动监测。
Proposed OAM mechanisms and procedures for multicast VPNs SHOULD be scalable with respect to the parameters mentioned in Section 5.2.2. In particular, it is RECOMMENDED that particular attention is given to the impact of monitoring mechanisms on performances and QoS.
针对多播VPN的拟议OAM机制和程序应可根据第5.2.2节中提到的参数进行扩展。特别是，建议特别注意监视机制对性能和QoS的影响。
Moreover, it is RECOMMENDED that any OAM mechanism designed to trigger alarms in relation to performance or resource usage metrics integrate the ability to limit the rate at which such alarms are generated (e.g., some form of a hysteresis mechanism based on low/ high thresholds defined for the metrics).
此外，建议设计用于触发与性能或资源使用指标相关的警报的任何OAM机制集成限制此类警报生成速率的能力（例如，基于为指标定义的低/高阈值的某种形式的滞后机制）。
It is a requirement that unicast and multicast services MUST be able to coexist within the same VPN.
要求单播和多播服务必须能够在同一VPN内共存。
Likewise, a multicast VPN solution SHOULD be designed so that its activation in devices that participate in the deployment and maintenance of a multicast VPN SHOULD be as smooth as possible, i.e., without affecting the overall quality of the services that are already supported by the underlying infrastructure.
同样，多播VPN解决方案的设计应确保其在参与多播VPN部署和维护的设备中的激活应尽可能平滑，即，不影响基础设施已支持的服务的总体质量。
A multicast VPN solution SHOULD prevent compatibility and migration issues, for instance, by focusing on providing mechanisms
多播VPN解决方案应该防止兼容性和迁移问题，例如，通过重点提供机制
facilitating forward compatibility. Most notably, a solution supporting only a subset of the requirements expressed in this document SHOULD be designed to allow compatibility to be introduced in further revisions.
促进向前兼容性。最值得注意的是，仅支持本文档中所述需求子集的解决方案应设计为允许在进一步修订中引入兼容性。
It SHOULD be an aim of any multicast VPN solution to offer as much backward compatibility as possible. Ideally, a solution would have the ability to offer multicast VPN services across a network containing some legacy routers that do not support any multicast VPN-specific features.
任何多播VPN解决方案的目标都应该是提供尽可能多的向后兼容性。理想情况下，解决方案能够跨包含一些不支持任何组播VPN特定功能的传统路由器的网络提供组播VPN服务。
In any case, a solution SHOULD state a migration policy from possibly existing deployments.
在任何情况下，解决方案都应该声明来自可能现有部署的迁移策略。
A multicast VPN solution that dynamically adapts the way some client multicast traffic is carried over the provider's network may incur the disadvantage of being hard to troubleshoot. In such a case, to help diagnose multicast network issues, a multicast VPN solution SHOULD provide monitoring information describing how client traffic is carried over the network (e.g., if a solution uses multicast-based MDTunnels, which provider multicast group is used for a given client multicast stream). A solution MAY also provide configuration options to avoid any dynamic changes, for multicast traffic of a particular VPN or a particular multicast stream.
多播VPN解决方案动态调整某些客户端多播流量在提供商网络上传输的方式，可能会导致难以排除故障的缺点。在这种情况下，为了帮助诊断多播网络问题，多播VPN解决方案应提供监控信息，描述如何在网络上传输客户端流量（例如，如果解决方案使用基于多播的MDTunnels，则给定客户端多播流使用哪个提供商多播组）。解决方案还可以为特定VPN或特定多播流的多播流量提供配置选项以避免任何动态更改。
Moreover, a solution MAY provide mechanisms that allow network operators to check that all VPN sites that advertised interest in a particular customer multicast stream are properly associated with the corresponding MDTunnel. Providing operators with means to check the proper setup and operation of MDTunnels MAY also be provided (e.g., when P2MP MPLS is used for MDTunnels, troubleshooting functionalities SHOULD integrate mechanisms compliant with [RFC4687], such as LSP Ping [RFC4379][LSP-PING]). Depending on the implementation, such verification could be initiated by a source-PE or a receiver-PE.
此外，解决方案可以提供允许网络运营商检查在特定客户多播流中广告感兴趣的所有VPN站点是否与相应的MDTunnel正确关联的机制。还可向操作员提供检查MDTunnel正确设置和操作的方法（例如，当P2MP MPLS用于MDTunnel时，故障排除功能应集成符合[RFC4687]的机制，如LSP Ping[RFC4379][LSP-Ping]）。根据实现，此类验证可由源PE或接收器PE发起。
This document does not by itself raise any particular security issue.
本文件本身没有提出任何特定的安全问题。
A set of security issues has been identified that MUST be addressed when considering the design and deployment of multicast-enabled L3 PPVPNs. Such issues have been described in Section 5.1.5 and Section 5.2.8.
在考虑设计和部署支持多播的L3 PPVPN时，已经确定了一组必须解决的安全问题。此类问题已在第5.1.5节和第5.2.8节中描述。
The main contributors to this document are listed below, in alphabetical order:
以下按字母顺序列出了本文件的主要贡献者：
o Christian Jacquenet France Telecom 3, avenue Francois Chateau CS 36901 35069 RENNES Cedex, France Email: christian.jacquenet@orange-ftgroup.com
o Christian Jacquenet法国电信3号，法国弗朗索瓦城堡大道CS 36901 35069雷恩塞德斯，法国电子邮件：Christian。jacquenet@orange-ftgroup.com
o Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan Email: y.kamite@ntt.com
o Yuji Kamite NTT通信公司东京歌剧城3-20-2号楼，新宿，新宿东京163-1421电子邮件：y。kamite@ntt.com
o Jean-Louis Le Roux France Telecom R&D 2, avenue Pierre-Marzin 22307 Lannion Cedex, France Email: jeanlouis.leroux@orange-ftgroup.com
o Jean-Louis Le Roux法国电信研发2号，Pierre Marzin大街22307号，法国Lannion Cedex电子邮件：jeanlouis。leroux@orange-ftgroup.com
o Nicolai Leymann Deutsch Telecom Engineering Networks, Products & Services Goslarer Ufer 3510589 Berlin, Germany Email: nicolai.leymann@t-systems.com
o Nicolai Leymann Deutsch电信工程网络、产品和服务德国柏林Goslarer Ufer 3510589电子邮件：Nicolai。leymann@t-系统网
o Renaud Moignard France Telecom R&D 2, avenue Pierre-Marzin 22307 Lannion Cedex, France Email: renaud.moignard@orange-ftgroup.com
o 雷诺·莫格纳德法国电信研发2号，皮埃尔·马津大街22307，法国拉尼翁·塞德克斯，电子邮件：雷诺。moignard@orange-ftgroup.com
o Thomas Morin France Telecom R&D 2, avenue Pierre-Marzin 22307 Lannion Cedex, France Email: thomas.morin@orange-ftgroup.com
o Thomas Morin法国电信研发2号，Pierre Marzin大街22307，法国Lannion Cedex电子邮件：Thomas。morin@orange-ftgroup.com
The authors would like to thank, in rough chronological order, Vincent Parfait, Zubair Ahmad, Elodie Hemon-Larreur, Sebastien Loye, Rahul Aggarwal, Hitoshi Fukuda, Luyuan Fang, Adrian Farrel, Daniel King, Yiqun Cai, Ronald Bonica, Len Nieman, Satoru Matsushima, Netzahualcoyotl Ornelas, Yakov Rekhter, Marshall Eubanks, Pekka
作者希望按照大致的时间顺序感谢文森特·帕菲、祖拜尔·艾哈迈德、埃洛迪·赫蒙·拉鲁尔、塞巴斯蒂安·洛耶、拉胡尔·阿加瓦尔、福田仁、方卢元、阿德里安·法雷尔、丹尼尔·金、蔡依群、罗纳德·博尼卡、莱恩·尼曼、松岛佐托鲁、内扎瓦·奥尔乔托·奥涅拉斯、雅科夫·雷克特、马歇尔·尤班克斯、佩卡
Savola, Benjamin Niven-Jenkins, and Thomas Nadeau, for their review, valuable input, and feedback.
萨沃拉、本杰明·尼文·詹金斯和托马斯·纳多，感谢他们的评论、宝贵的意见和反馈。
We also thank the people who kindly answered the survey, and Daniel King, who took care of gathering and anonymizing its results.
我们还感谢善意地回答调查的人，以及负责收集和匿名调查结果的丹尼尔·金。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4031] Carugi, M. and D. McDysan, "Service Requirements for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4031, April 2005.
[RFC4031]Carugi，M.和D.McDysan，“第3层提供商提供的虚拟专用网络（PPVPN）的服务要求”，RFC 4031，2005年4月。
[RFC4026] Andersson, L. and T. Madsen, "Provider-Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4026]Andersson，L.和T.Madsen，“提供商提供的虚拟专用网络（VPN）术语”，RFC 4026，2005年3月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC4176] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, October 2005.
[RFC4176]El Mghazli，Y.，Nadeau，T.，Boucadair，M.，Chan，K.，和A.Gonguet，“第三层虚拟专用网络（L3VPN）运营和管理框架”，RFC 41762005年10月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]Adams，A.，Nicholas，J.，和W.Siadak，“协议独立多播-密集模式（PIM-DM）：协议规范（修订版）”，RFC 3973，2005年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[VRs] Ould-Brahim, H., "Network based IP VPN Architecture Using Virtual Routers", Work in Progress, March 2006.
[VRs]Ould Brahim，H.，“使用虚拟路由器的基于网络的IP VPN架构”，正在进行的工作，2006年3月。
[RFC2432] Dubray, K., "Terminology for IP Multicast Benchmarking", RFC 2432, October 1998.
[RFC2432]Dubrey，K.，“IP多播基准测试术语”，RFC 2432，1998年10月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[RFC2236]Fenner，W.，“互联网组管理协议，第2版”，RFC 2236，1997年11月。
[P2MP-RSVP-TE] Aggarwal, R., "Extensions to RSVP-TE for Point-to-Multipoint TE LSPs", Work in Progress, August 2006.
[P2MP-RSVP-TE]Aggarwal，R.，“点对多点TE LSP的RSVP-TE扩展”，正在进行的工作，2006年8月。
[PIM-BSR] Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", Work in Progress, June 2006.
[PIM-BSR]Bhaskar，N.，“PIM的引导路由器（BSR）机制”，正在进行的工作，2006年6月。
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006.
[RFC4610]Farinaci，D.和Y.Cai，“使用协议独立多播（PIM）的任意广播RP”，RFC 46102006年8月。
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003.
[RFC3446]Kim，D.，Meyer，D.，Kilmer，H.，和D.Farinaci，“使用协议独立多播（PIM）和多播源发现协议（MSDP）的任意广播呈现点（RP）机制”，RFC 3446，2003年1月。
[P2MP-LDP] Minei, I., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, October 2006.
[P2MP-LDP]Minei，I.，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，正在进行的工作，2006年10月。
[P2MP-LDP-REQS] Roux, J., "Requirements for point-to-multipoint extensions to the Label Distribution Protocol", Work in Progress, June 2006.
[P2MP-LDP-REQS]Roux，J.，“标签分发协议的点对多点扩展要求”，正在进行的工作，2006年6月。
[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, "Operations and Management (OAM) Requirements for Point-to-Multipoint MPLS Networks", RFC 4687, September 2006.
[RFC4687]Yasukawa，S.，Farrel，A.，King，D.，和T.Nadeau，“点对多点MPLS网络的运营和管理（OAM）要求”，RFC 4687，2006年9月。
[BIDIR-PIM] Handley, M., "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", Work in Progress, October 2005.
[BIDIR-PIM]Handley，M.，“双向协议独立多播（BIDIR-PIM）”，正在进行的工作，2005年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC3353] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, F., and F. Ansari, "Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment", RFC 3353, August 2002.
[RFC3353]Ooms，D.，Sales，B.，Livens，W.，Acharya，A.，Griffoul，F.，和F.Ansari，“多协议标签交换（MPLS）环境中的IP多播概述”，RFC 33532002年8月。
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[RFC3272]Awduche，D.，Chiu，A.，Elwalid，A.，Widjaja，I.，和X.Xiao，“互联网流量工程概述和原则”，RFC 3272，2002年5月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[IPFIX-PROT] Claise, B., "Specification of the IPFIX Protocol for the Exchange", Work in Progress, November 2006.
[IPFIX-PROT]Claise，B.，“交换的IPFIX协议规范”，正在进行的工作，2006年11月。
[RFC4045] Bourdon, G., "Extensions to Support Efficient Carrying of Multicast Traffic in Layer-2 Tunneling Protocol (L2TP)", RFC 4045, April 2005.
[RFC4045]Bourdon，G.“支持在第二层隧道协议（L2TP）中高效承载多播流量的扩展”，RFC 4045，2005年4月。
[RFC3809] Nagarajan, A., "Generic Requirements for Provider-Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.
[RFC3809]Nagarajan，A.，“提供商提供的虚拟专用网络（PPVPN）的一般要求”，RFC 3809，2004年6月。
[RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management", RFC 3811, June 2004.
[RFC3811]Nadeau，T.和J.Cucchiara，“多协议标签交换（MPLS）管理的文本约定（TC）定义”，RFC 3811，2004年6月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）流量工程（TE）管理信息库（MIB）”，RFC 3812，2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[RFC3813]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）标签交换路由器（LSR）管理信息库（MIB）”，RFC 38132004年6月。
[RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)", RFC 3814, June 2004.
[RFC3814]Nadeau，T.，Srinivasan，C.，和A.Viswanathan，“多协议标签交换（MPLS）转发等价类到下一跳标签转发条目（FEC到NHLFE）管理信息库（MIB）”，RFC 3814，2004年6月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998.
[RFC2330]Paxson，V.，Almes，G.，Mahdavi，J.，和M.Mathis，“IP性能度量框架”，RFC 2330，1998年5月。
[MULTIMETRICS] Stephan, E., "IP Performance Metrics (IPPM) for spatial and multicast", Work in Progress, October 2006.
[MULTIMETRICS]Stephan，E.，“空间和多播的IP性能指标（IPPM）”，进展中的工作，2006年10月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[RFC3180]Meyer，D.和P.Lothberg，“233/8中的GLOP寻址”，BCP 53，RFC 31802001年9月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC4382] Nadeau, T. and H. van der Linde, "MPLS/BGP Layer 3 Virtual Private Network (VPN) Management Information Base", RFC 4382, February 2006.
[RFC4382]Nadeau，T.和H.van der Linde，“MPLS/BGP第3层虚拟专用网络（VPN）管理信息库”，RFC 4382，2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[LSP-PING] Farrel, A. and S. Yasukawa, "Detecting Data Plane Failures in Point-to-Multipoint Multiprotocol", Work in Progress, September 2006.
[LSP-PING]Farrel，A.和S.Yasukawa，“在点对多点多协议中检测数据平面故障”，正在进行的工作，2006年9月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]Savola，P.，“网络隧道中的MTU和碎片问题”，RFC 4459，2006年4月。
Author's Address
作者地址
Thomas Morin (editor) France Telecom R&D 2, avenue Pierre Marzin Lannion 22307 France
托马斯·莫林（编辑）法国电信研发2号，皮埃尔·马津·拉尼翁大街22307号，法国
EMail: thomas.morin@orange-ftgroup.com
EMail: thomas.morin@orange-ftgroup.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。