Internet Engineering Task Force (IETF) T. Morin, Ed.
Request for Comments: 6517 France Telecom - Orange
Category: Informational B. Niven-Jenkins, Ed.
ISSN: 2070-1721 BT
Y. Kamite
NTT Communications
R. Zhang
Alcatel-Lucent
N. Leymann
Deutsche Telekom
N. Bitar
Verizon
February 2012
Internet Engineering Task Force (IETF) T. Morin, Ed.
Request for Comments: 6517 France Telecom - Orange
Category: Informational B. Niven-Jenkins, Ed.
ISSN: 2070-1721 BT
Y. Kamite
NTT Communications
R. Zhang
Alcatel-Lucent
N. Leymann
Deutsche Telekom
N. Bitar
Verizon
February 2012
Mandatory Features in a Layer 3 Multicast BGP/MPLS VPN Solution
第3层多播BGP/MPLS VPN解决方案中的强制功能
Abstract
摘要
More that one set of mechanisms to support multicast in a layer 3 BGP/MPLS VPN has been defined. These are presented in the documents that define them as optional building blocks.
在第3层BGP/MPLS VPN中定义了一组以上支持多播的机制。这些在将它们定义为可选构建块的文档中提供。
To enable interoperability between implementations, this document defines a subset of features that is considered mandatory for a multicast BGP/MPLS VPN implementation. This will help implementers and deployers understand which L3VPN multicast requirements are best satisfied by each option.
为了实现实施之间的互操作性，本文档定义了多播BGP/MPLS VPN实施所必需的功能子集。这将帮助实施者和部署者了解每个选项最能满足哪些L3VPN多播需求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6517.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6517.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Examining Alternative Mechanisms for MVPN Functions . . . . . 4
3.1. MVPN Auto-Discovery . . . . . . . . . . . . . . . . . . . 4
3.2. S-PMSI Signaling . . . . . . . . . . . . . . . . . . . . . 5
3.3. PE-PE Exchange of C-Multicast Routing . . . . . . . . . . 7
3.3.1. PE-PE C-Multicast Routing Scalability . . . . . . . . 7
3.3.2. PE-CE Multicast Routing Exchange Scalability . . . . . 10
3.3.3. Scalability of P Routers . . . . . . . . . . . . . . . 10
3.3.4. Impact of C-Multicast Routing on Inter-AS Deployments 10
3.3.5. Security and Robustness . . . . . . . . . . . . . . . 11
3.3.6. C-Multicast VPN Join Latency . . . . . . . . . . . . . 12
3.3.7. Conclusion on C-Multicast Routing . . . . . . . . . . 14
3.4. Encapsulation Techniques for P-Multicast Trees . . . . . . 15
3.5. Inter-AS Deployments Options . . . . . . . . . . . . . . . 16
3.6. BIDIR-PIM Support . . . . . . . . . . . . . . . . . . . . 19
4. Co-Located RPs . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Avoiding Duplicates . . . . . . . . . . . . . . . . . . . . . 21
6. Existing Deployments . . . . . . . . . . . . . . . . . . . . . 21
7. Summary of Recommendations . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Scalability of C-Multicast Routing Processing Load . 25
A.1. Scalability with an Increased Number of PEs . . . . . . . 26
A.1.1. SSM Scalability . . . . . . . . . . . . . . . . . . . 26
A.1.2. ASM Scalability . . . . . . . . . . . . . . . . . . . 35
A.2. Cost of PEs Leaving and Joining . . . . . . . . . . . . . 37
Appendix B. Switching to S-PMSI . . . . . . . . . . . . . . . . . 40
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Examining Alternative Mechanisms for MVPN Functions . . . . . 4
3.1. MVPN Auto-Discovery . . . . . . . . . . . . . . . . . . . 4
3.2. S-PMSI Signaling . . . . . . . . . . . . . . . . . . . . . 5
3.3. PE-PE Exchange of C-Multicast Routing . . . . . . . . . . 7
3.3.1. PE-PE C-Multicast Routing Scalability . . . . . . . . 7
3.3.2. PE-CE Multicast Routing Exchange Scalability . . . . . 10
3.3.3. Scalability of P Routers . . . . . . . . . . . . . . . 10
3.3.4. Impact of C-Multicast Routing on Inter-AS Deployments 10
3.3.5. Security and Robustness . . . . . . . . . . . . . . . 11
3.3.6. C-Multicast VPN Join Latency . . . . . . . . . . . . . 12
3.3.7. Conclusion on C-Multicast Routing . . . . . . . . . . 14
3.4. Encapsulation Techniques for P-Multicast Trees . . . . . . 15
3.5. Inter-AS Deployments Options . . . . . . . . . . . . . . . 16
3.6. BIDIR-PIM Support . . . . . . . . . . . . . . . . . . . . 19
4. Co-Located RPs . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Avoiding Duplicates . . . . . . . . . . . . . . . . . . . . . 21
6. Existing Deployments . . . . . . . . . . . . . . . . . . . . . 21
7. Summary of Recommendations . . . . . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Scalability of C-Multicast Routing Processing Load . 25
A.1. Scalability with an Increased Number of PEs . . . . . . . 26
A.1.1. SSM Scalability . . . . . . . . . . . . . . . . . . . 26
A.1.2. ASM Scalability . . . . . . . . . . . . . . . . . . . 35
A.2. Cost of PEs Leaving and Joining . . . . . . . . . . . . . 37
Appendix B. Switching to S-PMSI . . . . . . . . . . . . . . . . . 40
Specifications for multicast in BGP/MPLS [RFC6513] include multiple alternative mechanisms for some of the required building blocks of the solution. However, they do not identify which of these mechanisms are mandatory to implement in order to ensure interoperability. Not defining a set of mandatory-to-implement mechanisms leads to a situation where implementations may support different subsets of the available optional mechanisms that do not interoperate, which is a problem for the numerous operators having multi-vendor backbones.
BGP/MPLS[RFC6513]中的多播规范包括解决方案所需构建块的多种替代机制。但是，它们没有确定为了确保互操作性，哪些机制是必须实现的。不定义一组强制实现机制会导致实现可能支持不互操作的可用可选机制的不同子集的情况，这对于拥有多供应商主干网的众多运营商来说是一个问题。
The aim of this document is to leverage the already expressed requirements [RFC4834] and study the properties of each approach to identify mechanisms that are good candidates for being part of a core set of mandatory mechanisms that can be used to provide a base for interoperable solutions.
本文件的目的是利用已经表达的需求[RFC4834]，并研究每种方法的特性，以确定作为可用于提供互操作解决方案基础的强制机制核心集一部分的良好候选机制。
This document goes through the different building blocks of the solution and concludes which mechanisms an implementation is required to implement. Section 7 summarizes these requirements.
本文档介绍了解决方案的不同构建块，并总结了需要实现哪些机制。第7节总结了这些要求。
Considering the history of the multicast VPN proposals and implementations, it is also useful to discuss how existing deployments of early implementations [RFC6037] [MVPN] can be accommodated and provide suggestions in this respect.
考虑到多播VPN提案和实施的历史，讨论如何适应早期实施[RFC6037][MVPN]的现有部署并提供这方面的建议也很有用。
Please refer to [RFC6513] and [RFC4834]. As a reminder, in Section 3.1 of [RFC6513], the "C-" and "P-" notations are used to disambiguate between the provider scope and the scope of a specific VPN customer; for instance, "C-PIM" designates a PIM protocol instance in a VPN or VRF, while "P-PIM" would designate the instance of PIM eventually deployed by the provider across its core between P and PE routers.
请参考[RFC6513]和[RFC4834]。作为提醒，在[RFC6513]第3.1节中，“C-”和“P-”符号用于消除提供商范围和特定VPN客户范围之间的歧义；例如，“C-PIM”指定VPN或VRF中的PIM协议实例，而“P-PIM”将指定提供商最终通过其核心在P和PE路由器之间部署的PIM实例。
Other acronyms used in this document include the following:
本文件中使用的其他首字母缩略词包括：
o LSP: Label Switched Path
o 标签交换路径
o P2MP: Point to Multipoint
o P2MP：点对多点
o MP2MP: Multipoint to Multipoint
o MP2MP：多点对多点
o GRE: Generic Routing Encapsulation
o GRE：通用路由封装
o mLDP: Multicast LDP
o 多播LDP
o I-PMSI: Inclusive Provider Multiservice Interface
o I-PMSI：包容性提供者多服务接口
o MI-PMSI: Multidirectional Inclusive Provider Multiservice Interface
o MI-PMSI：多向包容性提供者多服务接口
o S-PMSI: Selective Provider Multiservice Interface
o S-PMSI：选择性提供者多服务接口
o SSM: Source-Specific Multicast
o SSM：源特定多播
o ASM: Any-Source Multicast
o ASM：任何源多播
o PIM-SM: PIM Sparse Mode
o PIM-SM:PIM稀疏模式
o PIM-SSM: PIM Sparse Mode in SSM Mode
o PIM-SSM:SSM模式下的PIM稀疏模式
o BIDIR-PIM: Bidirectional PIM
o BIDIR-PIM：双向PIM
o AS: Autonomous System
o AS：自治系统
o ASBR: Autonomous System Border Router
o 自治系统边界路由器
o VRF: VPN Routing and Forwarding
o VRF:VPN路由和转发
o PE: Provider Edge
o PE：提供程序边缘
o CE: Customer Edge
o 行政长官：顾客优势
o RPA: Rendezvous Point Address
o 交会点地址
o RPL: Rendezvous Point Link
o 交会点链路
Additionally, 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]中所述进行解释。
The current solution document [RFC6513] proposes two different mechanisms for Multicast VPN (MVPN) auto-discovery:
当前的解决方案文档[RFC6513]提出了两种不同的多播VPN（MVPN）自动发现机制：
1. BGP-based auto-discovery
1. 基于BGP的自动发现
2. "PIM/shared P-tunnel": discovery done through the exchange of PIM Hellos by C-PIM instances, across an MI-PMSI implemented with one shared P-tunnel per VPN (using ASM or MP2MP LDP)
2. “PIM/共享P-tunnel”：通过C-PIM实例交换PIM hello，在每VPN一个共享P-tunnel（使用ASM或MP2MP LDP）实现的MI-PMSI上进行发现
Both solutions address Section 5.2.10 of [RFC4834], which states that "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".
这两种解决方案都涉及[RFC4834]第5.2.10节，其中规定“多播VPN解决方案的操作应尽可能轻，在设计多播VPN解决方案时，应优先考虑提供自动配置和发现。特别是，在PE或VR/VRF上设置多播的操作负担应尽可能低”。
The key consideration is that PIM-based discovery is only applicable to deployments using a shared P-tunnel to instantiate an MI-PMSI (it is not applicable if only P2P, PIM-SSM, and P2MP LDP/RSVP-TE P-tunnels are used, because contrary to ASM and MP2MP LDP, building these types of P-tunnels cannot happen before the auto-discovery has been done). In contrast, the BGP-based auto-discovery does not place any constraint on the type of P-tunnel that would have to be used. BGP-based auto-discovery is independent of the type of P-tunnel used, thus satisfying the requirement in Section 5.2.4.1 of [RFC4834] that "a multicast VPN solution SHOULD be designed so that control and forwarding planes are not interdependent".
关键考虑事项是，基于PIM的发现仅适用于使用共享P隧道实例化MI-PMSI的部署（如果仅使用P2P、PIM-SSM和P2MP LDP/RSVP-TE P隧道，则不适用，因为与ASM和MP2MP LDP相反，在完成自动发现之前无法构建这些类型的P隧道）。相比之下，基于BGP的自动发现不会对必须使用的P隧道类型施加任何限制。基于BGP的自动发现与所使用的P隧道类型无关，因此满足[RFC4834]第5.2.4.1节中的要求，即“多播VPN解决方案的设计应确保控制和转发平面不相互依赖”。
Additionally, it is to be noted that a number of service providers have chosen to use SSM-based P-tunnels for the default multicast distribution trees within their current deployments, therefore relying already on some BGP-based auto-discovery.
此外，需要注意的是，许多服务提供商已经选择在其当前部署中使用基于SSM的P隧道作为默认多播分发树，因此已经依赖于一些基于BGP的自动发现。
Moreover, when shared P-tunnels are used, the use of BGP auto-discovery would allow inconsistencies in the addresses/identifiers used for the shared P-tunnel to be detected (e.g., the same shared P-tunnel identifier being used for different VPNs with distinct BGP route targets). This is particularly attractive in the context of inter-AS VPNs where the impact of any misconfiguration could be magnified and where a single service provider may not operate all the ASes. Note that this technique to detect some misconfiguration cases may not be usable during a transition period from a shared-P-tunnel auto-discovery to a BGP-based auto-discovery.
此外，当使用共享P隧道时，使用BGP自动发现将允许检测用于共享P隧道的地址/标识符中的不一致性（例如，相同的共享P隧道标识符用于具有不同BGP路由目标的不同vpn）。这在内部AS VPN环境中尤其具有吸引力，因为任何错误配置的影响都可能被放大，并且单个服务提供商可能无法运行所有ASE。请注意，在从共享P隧道自动发现到基于BGP的自动发现的过渡期间，这种检测某些错误配置情况的技术可能不可用。
Thus, the recommendation is that implementation of the BGP-based auto-discovery is mandated and should be supported by all MVPN implementations.
因此，建议强制实施基于BGP的自动发现，并应得到所有MVPN实施的支持。
The current solution document [RFC6513] proposes two mechanisms for signaling that multicast flows will be switched to a Selective PMSI (S-PMSI):
当前的解决方案文档[RFC6513]提出了两种机制，用于发送多播流将切换到选择性PMSI（S-PMSI）的信号：
1. a UDP-based TLV protocol specifically for S-PMSI signaling (described in Section 7.4.2)
1. 专门用于S-PMSI信令的基于UDP的TLV协议（如第7.4.2节所述）
2. a BGP-based mechanism for S-PMSI signaling (described in Section 7.4.1)
2. 基于BGP的S-PMSI信令机制（如第7.4.1节所述）
Section 5.2.10 of [RFC4834] states that "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". The UDP-based mechanism would be an additional protocol in the MVPN stack, which isn't the case for the BGP-based S-PMSI switching signaling, since (a) BGP is identified as a requirement for auto-discovery and (b) the BGP-based S-PMSI switching signaling procedures are very similar to the auto-discovery procedures.
[RCFC434 ]的第5.2.10节指出：“尽可能地，解决方案的设计应仔细考虑核心网络中的协议数目：如果与单播VPN服务相比引入任何附加协议，则应充分检查它们的优点和操作负担之间的平衡”。基于UDP的机制将是MVPN堆栈中的附加协议，而基于BGP的S-PMSI交换信令则不是这种情况，因为（a）BGP被确定为自动发现的要求，（b）基于BGP的S-PMSI交换信令过程与自动发现过程非常相似。
Furthermore, the UDP-based S-PMSI switching signaling mechanism requires an MI-PMSI, while the BGP-based protocol does not. In practice, this mean that with the UDP-based protocol, a PE will have to join to all P-tunnels of all PEs in an MVPN, while in the alternative where BGP-based S-PMSI switching signaling is used, it could delay joining a P-tunnel rooted at a PE until traffic from that PE is needed, thus reducing the amount of state maintained on P routers.
此外，基于UDP的S-PMSI交换信令机制需要MI-PMSI，而基于BGP的协议则不需要。在实践中，这意味着使用基于UDP的协议，PE必须加入MVPN中所有PE的所有P隧道，而在使用基于BGP的S-PMSI交换信令的替代方案中，它可以延迟加入以PE为根的P隧道，直到需要来自该PE的流量，从而减少在P路由器上维护的状态量。
S-PMSI switching signaling approaches can also be compared in an inter-AS context (see Section 3.5). The proposed BGP-based approach for S-PMSI switching signaling provides a good fit with both the segmented and non-segmented inter-AS approaches (see Section 3.5). By contrast, while the UDP-based approach for S-PMSI switching signaling appears to be usable with segmented inter-AS tunnels, key advantages of the segmented approach are lost:
S-PMSI交换信令方法也可在AS间上下文中进行比较（见第3.5节）。提出的基于BGP的S-PMSI交换信令方法非常适合分段和非分段AS间方法（见第3.5节）。相比之下，虽然基于UDP的S-PMSI交换信令方法似乎可用于分段AS间隧道，但分段方法的关键优势已丧失：
o ASes are no longer independent in their ability to choose when S-PMSIs tunnels will be triggered in their AS (and thus control the amount of state created on their P routers).
o ASE不再能够独立选择何时在其AS中触发S-PMSIs隧道（从而控制在其P路由器上创建的状态量）。
o ASes are no longer independent in their ability to choose the tunneling technique for the P-tunnels used for an S-PMSI.
o ASE在选择S-PMSI所用P隧道的隧道技术方面不再独立。
o In an inter-AS option B context, an isolation of ASes is obtained as PEs in one AS don't have (direct) exchange of routing information with PEs of other ASes. This property is not preserved if UDP-based S-PMSI switching signaling is used. By contrast, BGP-based C-multicast switching signaling does preserve this property.
o 在AS间选项B上下文中，ASE的隔离作为一个AS中的PE获得，因为没有（直接）与其他ASE的PE交换路由信息。如果使用基于UDP的S-PMSI交换信令，则不会保留此属性。相比之下，基于BGP的C多播交换信令确实保留了这一特性。
Given all the above, it is the recommendation of the authors that BGP is the preferred solution for S-PMSI switching signaling and should be supported by all implementations.
鉴于上述所有情况，作者建议BGP是S-PMSI交换信令的首选解决方案，并且应得到所有实现的支持。
If nothing prevents a fast-paced creation of S-PMSI, then S-PMSI switching signaling with BGP would possibly impact the route reflectors (RRs) used for MVPN routes. However, such a fast-paced behavior would have an impact on P and PE routers resulting from S-PMSI tunnels signaling, which will be the same independent of the S-PMSI signaling approach that is used and which is certainly best to avoid by setting up proper mechanisms.
如果没有任何东西阻止S-PMSI的快速创建，则使用BGP的S-PMSI交换信令可能会影响用于MVPN路由的路由反射器（RRs）。然而，这种快节奏的行为会对S-PMSI隧道信令产生的P和PE路由器产生影响，这与所使用的S-PMSI信令方法是相同的，当然最好通过设置适当的机制来避免。
The UDP-based S-PMSI switching signaling protocol can also be considered, as an option, given that this protocol has been in deployment for some time. Implementations supporting both protocols would be expected to provide a per-VRF (VPN Routing and Forwarding) configuration knob to allow an implementation to use the UDP-based TLV protocol for S-PMSI switching signaling for specific VRFs in order to support the co-existence of both protocols (for example, during migration scenarios). Apart from such migration-facilitating mechanisms, the authors specifically do not recommend extending the already proposed UDP-based TLV protocol to new types of P-tunnels.
基于UDP的S-PMSI交换信令协议也可以作为一种选择，因为该协议已经部署了一段时间。支持这两种协议的实现预计将提供每VRF（VPN路由和转发）配置旋钮，以允许实现使用基于UDP的TLV协议来为特定VRF的S-PMSI交换信令，以支持这两种协议的共存（例如，在迁移场景期间）。除了这些迁移促进机制外，作者特别不建议将已经提出的基于UDP的TLV协议扩展到新类型的P隧道。
The current solution document [RFC6513] proposes multiple mechanisms for PE-PE exchange of customer multicast routing information (C-multicast routing):
当前的解决方案文档[RFC6513]提出了客户多播路由信息（C多播路由）的PE-PE交换的多种机制：
1. Full per-MVPN PIM peering across an MI-PMSI (described in Section 3.4.1.1)
1. 跨MI-PMSI的全每MVPN PIM对等（如第3.4.1.1节所述）
2. Lightweight PIM peering across an MI-PMSI (described in Section 3.4.1.2)
2. 跨MI-PMSI的轻型PIM对等（如第3.4.1.2节所述）
3. The unicasting of PIM C-Join/Prune messages (described in Section 3.4.1.3)
3. PIM C-Join/Prune消息的单播（如第3.4.1.3节所述）
4. The use of BGP for carrying C-multicast routing (described in Section 3.4.2)
4. 使用BGP承载C多播路由（如第3.4.2节所述）
Scalability being one of the core requirements for multicast VPN, it is useful to compare the proposed C-multicast routing mechanisms from this perspective: Section 4.2.4 of [RFC4834] recommends that "a multicast VPN solution SHOULD support several hundreds of PEs per multicast VPN, and MAY usefully scale up to thousands" and Section 4.2.5 states that "a solution SHOULD scale up to thousands of PEs having multicast service enabled".
可扩展性是多播VPN的核心要求之一，从这个角度比较拟议的C多播路由机制是有用的：[RFC4834]第4.2.4节建议“多播VPN解决方案应支持每个多播VPN数百个PE，并可有效扩展到数千个”第4.2.5节指出“一个解决方案应扩展到数千个启用多播服务的PE”。
Scalability with an increased number of VPNs per PE, or with an increased amount of multicast state per VPN, are also important but are not focused on in this section since we didn't identify differences between the various approaches for these matters: all others things equal, the load on PE due to C-multicast routing increases roughly linearly with the number of VPNs per PE and with the amount of multicast state per VPN.
每个PE增加VPN数量或每个VPN增加多播状态数量的可扩展性也很重要，但本节不重点讨论，因为我们没有确定这些问题的各种方法之间的差异：所有其他方法都相同，由于C多播路由，PE上的负载随着每个PE的VPN数量和每个VPN的多播状态量大致呈线性增加。
This section presents conclusions related to PE-PE C-multicast routing scalability. Appendix A provides more detailed explanations on the differences in ways PIM-based approaches and the BGP-based approach handle the C-multicast routing load, along with quantified evaluations of the amount of state and messages with the different approaches. Many points made in this section are detailed in Appendix A.1.
本节介绍与PE-PE C多播路由可伸缩性相关的结论。附录A更详细地解释了基于PIM的方法和基于BGP的方法处理C-多播路由负载的方式的差异，以及使用不同方法对状态量和消息量的量化评估。附录A.1详述了本节中提出的许多要点。
At high scales of multicast deployment, the first and third mechanisms require the PEs to maintain a large number of PIM adjacencies with other PEs of the same multicast VPN (which implies the regular exchange of PIM Hellos with each other) and to periodically refresh C-Join/Prune states, resulting in an increased processing cost when the number of PEs increases (as detailed in Appendix A.1). The second approach is less subject to this, and the fourth approach is not subject to this.
在高规模的多播部署中，第一和第三种机制要求PEs与同一多播VPN的其他PE保持大量PIM邻接（这意味着PIM hello彼此定期交换），并定期刷新C-Join/Prune状态，当PEs数量增加时，导致处理成本增加（详见附录A.1）。第二种方法受此影响较小，第四种方法不受此影响。
The third mechanism would reduce the amount of C-Join/Prune processing for a given multicast flow for PEs that are not the upstream neighbor for this flow but would require "explicit tracking" state to be maintained by the upstream PE. It also isn't compatible with the "Join suppression" mechanism. A possible way to reduce the amount of signaling with this approach would be the use of a PIM refresh-reduction mechanism. Such a mechanism, based on TCP, is being specified by the PIM IETF Working Group ([PIM-PORT]); its use in a multicast VPN context is not described in [RFC6513], but it is expected that this approach will provide a scalability similar to the BGP-based approach without RRs.
第三种机制将减少对于不是该流的上游邻居但需要由上游PE维护“显式跟踪”状态的PE的给定多播流的C-Join/Prune处理量。它也与“连接抑制”机制不兼容。使用这种方法减少信令量的一种可能方法是使用PIM刷新减少机制。PIM IETF工作组（[PIM-PORT]）正在指定这种基于TCP的机制；[RFC6513]中未描述其在多播VPN上下文中的使用，但预计该方法将提供类似于无RRs的基于BGP的方法的可伸缩性。
The second mechanism would operate in a similar manner to full per-MVPN PIM peering except that PIM Hello messages are not transmitted and PIM C-Join/Prune refresh-reduction would be used, thereby improving scalability, but this approach has yet to be fully described. In any case, it seems that it only improves one thing among the things that will impact scalability when the number of PEs increases.
第二种机制的操作方式与完全每MVPN PIM对等类似，只是不传输PIM Hello消息，并且将使用PIM C-Join/Prune refresh reduction，从而提高可伸缩性，但该方法尚未完全描述。在任何情况下，当PEs数量增加时，它似乎只改善了影响可伸缩性的一个方面。
The first and second mechanisms can leverage the "Join suppression" behavior and thus improve the processing burden of an upstream PE, sparing the processing of a Join refresh message for each remote PE
第一和第二机制可以利用“连接抑制”行为，从而改善上游PE的处理负担，从而节省对每个远程PE的连接刷新消息的处理
joined to a multicast stream. This improvement requires all PEs of a multicast VPN to process all PIM Join and Prune messages sent by any other PE participating in the same multicast VPN whether they are the upstream PE or not.
加入到多播流。这一改进要求多播VPN的所有PE处理所有PIM加入和删减由参与同一多播VPN的任何其他PE发送的消息，无论它们是否为上游PE。
The fourth mechanism (the use of BGP for carrying C-multicast routing) would have a comparable drawback of requiring all PEs to process a BGP C-multicast route only interesting a specific upstream PE. For this reason, Section 16 of [RFC6514] recommends the use of the Route Target constrained BGP distribution [RFC4684] mechanisms, which eliminate this drawback by having only the interested upstream PE receive a BGP C-multicast route. Specifically, when Route Target constrained BGP distribution is used, the fourth mechanism reduces the total amount of the C-multicast routing processing load put on the PEs by avoiding any processing of customer multicast routing information on the "unrelated" PEs that are neither the joining PE nor the upstream PE.
第四种机制（使用BGP承载C-多播路由）将有一个类似的缺点，即要求所有PE只处理特定上游PE感兴趣的BGP C-多播路由。因此，[RFC6514]第16节建议使用路由目标约束的BGP分发[RFC4684]机制，该机制通过仅让感兴趣的上游PE接收BGP C多播路由来消除此缺点。具体地说，当使用路由目标约束的BGP分布时，第四种机制通过避免对既不是加入PE也不是上游PE的“不相关”PE上的客户多播路由信息进行任何处理来减少施加在PE上的C多播路由处理负载的总量。
Moreover, the fourth mechanism further reduces the total amount of message processing load by avoiding the use of periodic refreshes and by inheriting BGP features that are expected to improve scalability (for instance, providing a means to offload some of the processing burden associated with customer multicast routing onto one or many BGP route reflectors). The advantages of the fourth mechanism come at a cost of maintaining an amount of state linear with the number of PEs joined to a stream. However, the use of route reflectors allows this cost to be spread among multiple route reflectors, thus eliminating the need for a single route reflector to maintain all this state.
此外，第四种机制通过避免使用定期刷新和继承有望提高可伸缩性的BGP特性，进一步减少了消息处理负载总量（例如，提供一种方法，将与客户多播路由相关的一些处理负担转移到一个或多个BGP路由反射器上）。第四种机制的优点在于，其代价是保持一定数量的状态与加入到流中的PE的数量成线性关系。然而，使用路由反射器可将此成本分摊到多个路由反射器中，从而无需使用单个路由反射器来维持所有此状态。
However, the fourth mechanism is specific in that it offers the possibility of offloading customer multicast routing processing onto one or more BGP route reflector(s). When this is used, there is a drawback of increasing the processing load placed on the route reflector infrastructure. In the higher scale scenarios, it may be required to adapt the route reflector infrastructure to the MVPN routing load by using, for example:
然而，第四种机制是特定的，因为它提供了将客户多播路由处理卸载到一个或多个BGP路由反射器上的可能性。使用此选项时，会增加路由反射器基础结构上的处理负载。在更高规模的场景中，可能需要通过使用，例如，使路由反射器基础设施适应MVPN路由负载：
o a separation of resources for unicast and multicast VPN routing: using dedicated MVPN route reflector(s) (or using dedicated MVPN BGP sessions or dedicated MVPN BGP instances), and
o 单播和多播VPN路由的资源分离：使用专用MVPN路由反射器（或使用专用MVPN BGP会话或专用MVPN BGP实例），以及
o the deployment of additional route reflector resources, for example, increasing the processing resources on existing route reflectors or deployment of additional route reflectors.
o 部署额外的路由反射器资源，例如，增加现有路由反射器上的处理资源或部署额外的路由反射器。
The most straightforward approach is to consider the introduction of route reflectors dedicated to the MVPN service and dimension them
最简单的方法是考虑引入专用于MVPN服务的路由反射器并对其进行尺寸标注。
according to the need of that service (but doing so is not required and is left as an operator engineering decision).
根据该服务的需要（但这样做不是必需的，由运营商工程决策决定）。
The overhead associated with the PE-CE exchange of C-multicast routing is independent of the choice of the mechanism used for the PE-PE C-multicast routing. Therefore, the impact of the PE-CE C-multicast routing overhead on the overall system scalability is independent of the protocol used for PE-PE signaling and is therefore not relevant when comparing the different approaches proposed for the PE-PE C-multicast routing. This is true even if in some operational contexts, the PE-CE C-multicast routing overhead is a significant factor in the overall system overhead.
与C多播路由的PE-CE交换相关联的开销与PE-PE C多播路由所用机制的选择无关。因此，PE-CE C多播路由开销对整个系统可伸缩性的影响独立于用于PE-PE信令的协议，因此在比较针对PE-PE C多播路由提出的不同方法时并不相关。即使在某些操作环境中，PE-CE C多播路由开销是整个系统开销中的一个重要因素，也是如此。
The first and second mechanisms are restricted to use within multicast VPNs that use an MI-PMSI, thereby necessitating:
第一和第二机制仅限于在使用MI-PMSI的多播VPN内使用，因此需要：
o the use of a P-tunnel technique that allows shared P-tunnels (for example, PIM-SM in ASM mode or MP2MP LDP), or
o 使用允许共享P通道的P通道技术（例如，ASM模式下的PIM-SM或MP2MP LDP），或
o the use of one P-tunnel per PE per VPN, even for PEs that do not have sources in their directly attached sites for that VPN.
o 每个VPN每个PE使用一个P隧道，即使对于在其直接连接的VPN站点中没有源的PE也是如此。
By comparison, the fourth mechanism doesn't impose either of these restrictions and, when P2MP P-tunnels are used, only necessitates the use of one P-tunnel per VPN per PE attached to a site with a multicast source or Rendezvous Point (RP) (or with a candidate Bootstrap Router (BSR), if BSR is used).
相比之下，第四种机制没有施加上述任何一种限制，并且当使用P2MP P隧道时，每个PE只需要在连接到具有多播源或集合点（RP）的站点的每个VPN上使用一个P隧道（如果使用BSR，则使用候选引导路由器（BSR））。
In cases where there are fewer PEs connected with sources than the total number of PEs, the fourth mechanism improves the amount of state maintained by P routers compared to the amount required to build an MI-PMSI with P2MP P-tunnels. Such cases are expected to be frequent for multicast VPN deployments (see Section 4.2.4.1 of [RFC4834]).
在与源连接的PE少于PE总数的情况下，与使用P2MP P隧道构建MI-PMSI所需的数量相比，第四种机制提高了P路由器维护的状态数量。对于多播VPN部署，此类情况预计会很常见（见[RFC4834]第4.2.4.1节）。
Co-existence with unicast inter-AS VPN options, and an equal level of security for multicast and unicast including in an inter-AS context, are specifically mentioned in Sections 5.2.6 and 5.2.8 of [RFC4834].
[RFC4834]第5.2.6节和第5.2.8节特别提到了与单播内部AS VPN选项共存，以及包括内部AS上下文在内的多播和单播的同等安全级别。
In an inter-AS option B context, an isolation of ASes is obtained as PEs in one AS don't have (direct) exchange of routing information with PEs of other ASes. This property is not preserved if PIM-based
在AS间选项B上下文中，ASE的隔离作为一个AS中的PE获得，因为没有（直接）与其他ASE的PE交换路由信息。如果基于PIM，则不保留此属性
PE-PE C-multicast routing is used. By contrast, the fourth option (BGP-based C-multicast routing) does preserve this property.
使用PE-PE C多播路由。相比之下，第四个选项（基于BGP的C多播路由）确实保留了此属性。
Additionally, the authors note that the proposed BGP-based approach for C-multicast routing provides a good fit with both the segmented and non-segmented inter-AS approaches. By contrast, though the PIM-based C-multicast routing is usable with segmented inter-AS tunnels, the inter-AS scalability advantage of the approach is lost, since PEs in an AS will see the C-multicast routing activity of all other PEs of all other ASes.
此外，作者指出，所提出的基于BGP的C-组播路由方法非常适合分段和非分段的AS间路由方法。相比之下，尽管基于PIM的C多播路由可用于分段的AS间隧道，但该方法的AS间可伸缩性优势已丧失，因为AS中的PE将看到所有其他AS的所有其他PE的C多播路由活动。
BGP supports MD5 authentication of its peers for additional security, thereby possibly directly benefiting multicast VPN customer multicast routing, whether for intra-AS or inter-AS communications. By contrast, with a PIM-based approach, no mechanism providing a comparable level of security to authenticate communications between remote PEs has yet been fully described [RFC5796] and, in any case, would require significant additional operations for the provider to be usable in a multicast VPN context.
BGP支持对其对等方进行MD5身份验证以实现额外的安全性，从而可能直接受益于多播VPN客户多播路由，无论是用于AS内还是AS间通信。相比之下，对于基于PIM的方法，尚未完全描述提供可比级别的安全性以认证远程PE之间通信的机制[RFC5796]，并且在任何情况下，都需要大量额外操作才能使提供商在多播VPN上下文中可用。
The robustness of the infrastructure, especially the existing infrastructure providing unicast VPN connectivity, is key. The C-multicast routing function, especially under load, will compete with the unicast routing infrastructure. With the PIM-based approaches, the unicast and multicast VPN routing functions are expected to only compete in the PE, for control plane processing resources. In the case of the BGP-based approach, they will compete on the PE for processing resources and in the route reflectors (supposing they are used for MVPN routing). In both cases, mechanisms will be required to arbitrate resources (e.g., processing priorities). In the case of PIM-based procedures, this arbitration occurs between the different control plane routing instances in the PE. In the case of the BGP-based approach, this is likely to require using distinct BGP sessions for multicast and unicast (e.g., through the use of dedicated MVPN BGP route reflectors or the use of a distinct session with an existing route reflector).
基础设施的健壮性是关键，尤其是提供单播VPN连接的现有基础设施。C多播路由功能，特别是在负载下，将与单播路由基础设施竞争。使用基于PIM的方法，单播和多播VPN路由功能预计仅在PE中竞争控制平面处理资源。在基于BGP的方法中，它们将在PE上竞争处理资源和路由反射器（假设它们用于MVPN路由）。在这两种情况下，都需要机制来仲裁资源（例如，处理优先级）。在基于PIM的过程中，该仲裁发生在PE中的不同控制平面路由实例之间。在基于BGP的方法的情况下，这可能需要为多播和单播使用不同的BGP会话（例如，通过使用专用MVPN BGP路由反射器或使用具有现有路由反射器的不同会话）。
Multicast routing is dynamic by nature, and multicast VPN routing has to follow the VPN customers' multicast routing events. The different approaches can be compared on how they are expected to behave in scenarios where multicast routing in the VPNs is subject to an intense activity. Scalability of each approach under such a load is detailed in Appendix A.2, and the fourth approach (BGP-based) used in conjunction with the Route Target Constraint mechanisms [RFC4684] is the only one having a cost for join/leave operations independent of the number of PEs in the VPN (with one exception detailed in
组播路由本质上是动态的，组播VPN路由必须遵循VPN客户的组播路由事件。在VPN中的多播路由受到密集活动影响的场景中，可以比较不同的方法，了解它们的预期行为。附录a.2详细说明了这种负载下每种方法的可扩展性，与路由目标约束机制[RFC4684]结合使用的第四种方法（基于BGP）是唯一一种独立于VPN中PE数量而具有加入/离开操作成本的方法（一种例外情况在附录a.2中详细说明）
Appendix A.2) and state maintenance not concentrated on the upstream PE.
附录A.2）和状态维护不集中于上游PE。
On the other hand, while the BGP-based approach is likely to suffer a slowdown under a load that is greater than the available processing resources (because of possibly congested TCP sockets), the PIM-based approaches would react to such a load by dropping messages, with failure-recovery obtained through message refreshes. Thus, the BGP-based approach could result in a degradation of join/leave latency performance typically spread evenly across all multicast streams being joined in that period, while the PIM-based approach could result in increased join/leave latency, for some random streams, by a multiple of the time between refreshes (e.g., tens of seconds), and possibly in some states, the adjacency may timeout, resulting in disruption of multicast streams.
另一方面，虽然基于BGP的方法在负载大于可用处理资源的情况下（由于TCP套接字可能拥塞）可能会出现减速，但基于PIM的方法会通过丢弃消息来响应这种负载，并通过消息刷新获得故障恢复。因此，基于BGP的方法可能导致加入/离开延迟性能的降低，该性能通常均匀地分布在该时间段内加入的所有多播流上，而对于一些随机流，基于PIM的方法可能导致加入/离开延迟增加刷新间隔时间的倍数（例如，几十秒），并且可能在某些状态下，邻接可能超时，导致多播流中断。
The behavior of the PIM-based approach under such a load is also harder to predict, given that the performance of the "Join suppression" mechanism (an important mechanism for this approach to scale) will itself be impeded by delays in Join processing. For these reasons, the BGP-based approach would be able to provide a smoother degradation and more predictable behavior under a highly dynamic load.
基于PIM的方法在这种负载下的行为也很难预测，因为“连接抑制”机制（这种方法的重要机制）本身的性能将受到连接处理延迟的阻碍。基于这些原因，基于BGP的方法将能够在高动态负载下提供更平滑的降级和更可预测的行为。
In fact, both an "evenly spread degradation" and an "unevenly spread larger degradation" can be problematic, and what seems important is the ability for the VPN backbone operator to (a) limit the amount of multicast routing activity that can be triggered by a multicast VPN customer and (b) provide the best possible independence between distinct VPNs. It seems that both of these can be addressed through local implementation improvements and that both the BGP-based and PIM-based approaches could be engineered to provide (a) and (b). It can be noted though that the BGP approach proposes ways to dampen C-multicast route withdrawals and/or advertisements and thus already describes a way to provide (a), while nothing comparable has yet been described for the PIM-based approaches (even though it doesn't appear difficult). The PIM-based approaches rely on a per-VPN data plane to carry the MVPN control plane and thus may benefit from this first level of separation to solve (b).
事实上，“均匀分布的降级”和“不均匀分布的较大降级”都可能存在问题，而VPN骨干网运营商（a）限制多播VPN客户可以触发的多播路由活动量和（b）的能力似乎很重要在不同的VPN之间提供尽可能好的独立性。似乎可以通过本地实施改进来解决这两个问题，并且基于BGP和基于PIM的方法都可以设计为提供（a）和（b）。但是可以注意到，BGP方法提出了抑制C-多播路由撤回和/或广告的方法，因此已经描述了提供（a）的方法，而对于基于PIM的方法还没有描述任何可比较的方法（尽管它看起来并不困难）。基于PIM的方法依赖于每个VPN数据平面来承载MVPN控制平面，因此可能受益于解决（b）的第一级分离。
Section 5.1.3 of [RFC4834] states that the "group join delay [...] is also considered one important QoS parameter. It is thus RECOMMENDED that a multicast VPN solution be designed appropriately in this regard". In a multicast VPN context, the "group join delay" of interest is the time between a CE sending a PIM Join to its PE and
[RFC4834]第5.1.3节指出，“组加入延迟[…]也被视为一个重要的QoS参数。因此，建议在这方面适当设计多播VPN解决方案”。在多播VPN上下文中，感兴趣的“组加入延迟”是CE向其PE发送PIM加入和
the first packet of the corresponding multicast stream being received by the CE.
由CE接收的对应多播流的第一分组。
It is to be noted that the C-multicast routing procedures will only impact the group join latency of a said multicast stream for the first receiver that is located across the provider backbone from the multicast source-connected PE (or the first <n> receivers in the specific case where a specific Upstream Multicast Hop selection algorithm is used, which allows <n> distinct PEs to be selected as the Upstream Multicast Hop by distinct downstream PEs).
要注意的是，C-多播路由过程将仅影响所述多播流对于第一接收机的组加入延迟，该第一接收机位于多播源连接的PE的提供商主干上（或在使用特定上游多播跳选择算法的特定情况下的第一个<n>接收器，其允许不同的下游PEs选择<n>不同的PEs作为上游多播跳）。
The different approaches proposed seem to have different characteristics in how they are expected to impact join latency:
提出的不同方法在如何影响连接延迟方面似乎具有不同的特点：
o The PIM-based approaches minimize the number of control plane processing hops between a new receiver-connected PE and the source-connected PE and, being datagram-based, introduce minimal delay, thereby possibly having a join latency as good as possible depending on implementation efficiency.
o 基于PIM的方法最小化新的接收器连接的PE和源连接的PE之间的控制平面处理跳数，并且基于数据报，引入最小延迟，因此可能具有尽可能好的连接延迟，这取决于实现效率。
o Under degraded conditions (packet loss, congestion, or high control plane load) the PIM-based approach may impact the latency for a given multicast stream in an all-or-nothing manner: if a C-multicast routing PIM Join packet is lost, latency can reach a high time (a multiple of the periodicity of PIM Join refreshes).
o 在降级条件下（数据包丢失、拥塞或高控制平面负载），基于PIM的方法可能会以全有或全无的方式影响给定多播流的延迟：如果C-多播路由PIM连接数据包丢失，延迟可能达到很高的时间（PIM连接刷新周期的倍数）。
o The BGP-based approach uses TCP exchanges, which may introduce an additional delay depending on BGP and TCP implementation but which would typically result, under degraded conditions (such packet loss, congestion, or high control plane load), in a comparably lower increase of latency spread more evenly across the streams.
o 基于BGP的方法使用TCP交换，这可能会根据BGP和TCP实现引入额外的延迟，但这通常会导致在降级条件下（如数据包丢失、拥塞或高控制平面负载），延迟的增加相对较低，且更均匀地分布在流中。
o As shown in Appendix A, the BGP-based approach is particular in that it removes load from all the PEs (without putting this load on the upstream PE for a stream); this improvement of background load can bring improved performance when a PE acts as the upstream PE for a stream and thus benefits join latency.
o 如附录A所示，基于BGP的方法的特殊之处在于，它从所有PE中移除负载（不将该负载施加在流的上游PE上）；当PE充当流的上游PE时，后台负载的这种改进可以带来性能的改进，从而有利于连接延迟。
This qualitative comparison of approaches shows that the BGP-based approach is designed for a smoother degradation of latency under degraded conditions such as packet loss, congestion, or high control plane load. On the other hand, the PIM-based approaches seem to structurally be able to reach the shorter "best-case" group join latency (especially compared to deployment of the BGP-based approach where route reflectors are used).
这些方法的定性比较表明，基于BGP的方法设计用于在诸如丢包、拥塞或高控制平面负载等降级条件下更平滑地降低延迟。另一方面，基于PIM的方法在结构上似乎能够达到更短的“最佳情况”组加入延迟（特别是与使用路由反射器的基于BGP的方法的部署相比）。
Doing a quantitative comparison of latencies is not possible without referring to specific implementations and benchmarking procedures and
如果不参考具体的实现和基准测试程序，就不可能对延迟进行定量比较
would possibly expose different conclusions, especially for best-case group join latency for which performance is expected to vary with PIM and BGP implementations. We can also note that improving a BGP implementation for reduced latency of route processing would not only benefit multicast VPN group join latency but the whole BGP-based routing, which means that the need for good BGP/RR performance is not specific to multicast VPN routing.
可能会得出不同的结论，特别是对于最佳情况下的组加入延迟，预期其性能会随PIM和BGP实现而变化。我们还可以注意到，改进BGP实现以减少路由处理的延迟不仅有利于多播VPN组加入延迟，而且有利于整个基于BGP的路由，这意味着对良好BGP/RR性能的需求并不特定于多播VPN路由。
Last, C-multicast join latency will be impacted by the overall load put on the control plane, and the scalability of the C-multicast routing approach is thus to be taken into account. As explained in Section 3.3.1 and Appendix A, the BGP-based approach will provide the best scalability with an increased number of PEs per VPN, thereby benefiting group join latency in such higher-scale scenarios.
最后，C-multicast连接延迟将受到控制平面上总负载的影响，因此需要考虑C-multicast路由方法的可伸缩性。如第3.3.1节和附录A所述，基于BGP的方法将提供最佳的可扩展性，每个VPN的PE数量将增加，从而有利于此类更高规模场景中的组加入延迟。
The first and fourth approaches are relevant contenders for C-multicast routing. Comparisons from a theoretical standpoint lead to identification of some advantages as well as possible drawbacks in the fourth approach. Comparisons from a practical standpoint are harder to make: since only reduced deployment and implementation information is available for the fourth approach, advantages would be seen in the first approach that has been applied through multiple deployments and shown to be operationally viable.
第一种和第四种方法是C多播路由的相关竞争者。从理论角度进行比较，可以确定第四种方法的一些优点以及可能的缺点。从实际角度进行比较比较比较困难：因为第四种方法只提供了较少的部署和实施信息，因此在通过多次部署应用并证明在操作上可行的第一种方法中可以看到优势。
Moreover, the first mechanism (full per-MVPN PIM peering across an MI-PMSI) is the mechanism used by [RFC6037]; therefore, it is deployed and operating in MVPNs today. The fourth approach may or may not end up being preferred for a said deployment, but because the first approach has been in deployment for some time, the support for this mechanism will in any case be helpful to facilitate an eventual migration from a deployment using mechanism close to the first approach.
此外，第一种机制（跨MI-PMSI的每MVPN PIM完全对等）是[RFC6037]使用的机制；因此，它今天在MVPN中部署和运行。对于所述部署，第四种方法可能是首选的，也可能不是首选的，但由于第一种方法已经部署了一段时间，因此对该机制的支持在任何情况下都将有助于最终从使用接近第一种方法的机制的部署迁移。
Consequently, at the present time, implementations are recommended to support both the fourth (BGP-based) and first (full per-MVPN PIM peering) mechanisms. Further experience on deployments of the fourth approach is needed before some best practices can be defined. In the meantime, this recommendation would enable a service provider to choose between the first and the fourth mechanisms, without this choice being constrained by vendor implementation choices. A service provider can also take into account the peculiarities of its own deployment context by pondering the weight of the different factors into account.
因此，目前建议实现同时支持第四种（基于BGP）和第一种（完全每MVPN PIM对等）机制。在定义一些最佳实践之前，需要更多关于第四种方法部署的经验。同时，这项建议将使服务提供者能够在第一种和第四种机制之间进行选择，而不受供应商实施选择的限制。服务提供者还可以通过考虑不同因素的权重来考虑其自身部署上下文的特性。
In this section, the authors will not make any restricting recommendations since the appropriateness of a specific provider core data plane technology will depend on a large number of factors, for example, the service provider's currently deployed unicast data plane, many of which are service provider specific.
在本节中，作者将不会提出任何限制性建议，因为特定提供商核心数据平面技术的适当性将取决于大量因素，例如，服务提供商当前部署的单播数据平面，其中许多是特定于服务提供商的。
However, implementations should not unreasonably restrict the data plane technology that can be used and should not force the use of the same technology for different VPNs attached to a single PE. Initial implementations may only support a reduced set of encapsulation techniques and data plane technologies, but this should not be a limiting factor that hinders future support for other encapsulation techniques, data plane technologies, or interoperability.
但是，实施不应不合理地限制可使用的数据平面技术，也不应强制将同一技术用于连接到单个PE的不同VPN。最初的实现可能只支持一组简化的封装技术和数据平面技术，但这不应成为阻碍将来支持其他封装技术、数据平面技术或互操作性的限制因素。
Section 5.2.4.1 of [RFC4834] states, "In a multicast VPN solution extending a unicast layer 3 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".
[RFC4834]第5.2.4.1节规定，“在扩展单播第3层PPVPN解决方案的多播VPN解决方案中，必须支持隧道技术的一致性：这样的解决方案应允许对多播使用与单播相同的隧道技术。部署一致性、易操作性和潜在的迁移是这一需求背后的主要动机”。
Current unicast VPN deployments use a variety of LDP, RSVP-TE, and GRE/IP-Multicast for encapsulating customer packets for transport across the provider core of VPN services. In order to allow the same encapsulations to be used for unicast and multicast VPN traffic, it is recommended that multicast VPN standards should recommend that implementations support multicast VPNs and all the P2MP variants of the encapsulations and signaling protocols that they support for unicast and for which some multipoint extension is defined, such as mLDP, P2MP RSVP-TE, and GRE/IP-multicast.
当前的单播VPN部署使用各种LDP、RSVP-TE和GRE/IP多播来封装客户数据包，以便跨VPN服务的提供商核心进行传输。为了允许对单播和多播VPN流量使用相同的封装，建议多播VPN标准应建议实现支持多播VPN以及它们支持单播的封装和信令协议的所有P2MP变体，并为其定义了一些多点扩展，如mLDP、P2MP RSVP-TE和GRE/IP多播。
All three of the above encapsulation techniques support the building of P2MP multicast P-tunnels. In addition, mLDP and GRE/ IP-ASM-Multicast implementations may also support the building of MP2MP multicast P-tunnels. The use of MP2MP P-tunnels may provide some scaling benefits to the service provider as only a single MP2MP P-tunnel need be deployed per VPN, thus reducing by an order of magnitude the amount of multicast state that needs to be maintained by P routers. This gain in state is at the expense of bandwidth optimization, since sites that do not have multicast receivers for multicast streams sourced behind a said PE group will still receive packets of such streams, leading to non-optimal bandwidth utilization across the VPN core. One thing to consider is that the use of MP2MP multicast P-tunnel will require additional configuration to define the same P-tunnel identifier or multicast ASM group address in all PEs (it has been noted that some auto-configuration could be possible
以上三种封装技术都支持P2MP多播P隧道的构建。此外，mLDP和GRE/IP ASM多播实现还可以支持MP2MP多播P隧道的构建。使用MP2MP P隧道可能会为服务提供商提供一些扩展优势，因为每个VPN只需要部署一个MP2MP隧道，从而将需要由P路由器维护的多播状态量减少一个数量级。这种状态增益是以带宽优化为代价的，因为在所述PE组后面没有多播流的多播接收器的站点仍将接收此类流的分组，从而导致VPN核心上的非最佳带宽利用率。需要考虑的是，使用MP2MP组播p隧道将需要额外的配置来定义所有PES中相同的p隧道标识符或多播ASM组地址（已经注意到一些自动配置是可能的）。
for MP2MP P-tunnels, but this is not currently supported by the auto-discovery procedures). (It has been noted that C-multicast routing schemes not covered in [RFC6513] could expose different advantages of MP2MP multicast P-tunnels; this is out of the scope of this document.)
对于MP2MP P P-tunnels，但自动发现程序目前不支持此功能）。（注意，[RFC6513]中未涉及的C-多播路由方案可能会暴露MP2MP多播P-隧道的不同优点；这超出了本文档的范围。）
MVPN services can also be supported over a unicast VPN core through the use of ingress PE replication whereby the ingress PE replicates any multicast traffic over the P2P tunnels used to support unicast traffic. While this option does not require the service provider to modify their existing P routers (in terms of protocol support) and does not require maintaining multicast-specific state on the P routers in order for the service provider to be able deploy a multicast VPN service, the use of ingress PE replication obviously leads to non-optimal bandwidth utilization, and it is therefore unlikely to be the long-term solution chosen by service providers. However, ingress PE replication may be useful during some migration scenarios or where a service provider considers the level of multicast traffic on their network to be too low to justify deploying multicast-specific support within their VPN core.
还可以通过使用入口PE复制在单播VPN核心上支持MVPN服务，入口PE通过用于支持单播流量的P2P隧道复制任何多播流量。虽然此选项不要求服务提供商修改其现有的P路由器（在协议支持方面），也不要求维护P路由器上的多播特定状态，以便服务提供商能够部署多播VPN服务，使用入口PE复制显然会导致非最佳带宽利用率，因此不太可能是服务提供商选择的长期解决方案。但是，在某些迁移场景中，或者服务提供商认为其网络上的多播通信量水平太低，无法在其VPN核心内部署多播特定支持时，入口PE复制可能很有用。
All proposed approaches for control plane and data plane can be used to provide aggregation amongst multicast groups within a VPN and amongst different multicast VPNs, and potentially reduce the amount of state to be maintained by P routers. However, the latter (the aggregation amongst different multicast VPNs) will require support for upstream-assigned labels on the PEs. Support for upstream-assigned labels may require changes to the data plane processing of the PEs, and this should be taken into consideration by service providers considering the use of aggregate PMSI tunnels for the specific platforms that the service provider has deployed.
所有针对控制平面和数据平面提出的方法都可用于在VPN内的多播组之间和不同多播VPN之间提供聚合，并可能减少由P路由器维护的状态量。但是，后者（不同多播VPN之间的聚合）需要支持PEs上的上游分配标签。支持上游分配的标签可能需要更改PEs的数据平面处理，服务提供商应考虑将聚合PMSI隧道用于服务提供商已部署的特定平台。
There are a number of scenarios that lead to the requirement for inter-AS multicast VPNs, including:
有许多场景导致了对跨AS多播VPN的需求，包括：
1. A service provider may have a large network that it has segmented into a number of ASes.
1. 服务提供商可能拥有一个大型网络，该网络已细分为多个ASE。
2. A service provider's multicast VPN may consist of a number of ASes due to acquisitions and mergers with other service providers.
2. 由于与其他服务提供商的收购和合并，服务提供商的多播VPN可能由多个ASE组成。
3. A service provider may wish to interconnect its multicast VPN platform with that of another service provider.
3. 服务提供商可能希望将其多播VPN平台与另一服务提供商的多播VPN平台互连。
The first scenario can be considered the "simplest" because the network is wholly managed by a single service provider under a single strategy and is therefore likely to use a consistent set of technologies across each AS.
第一种场景可以被认为是“最简单的”，因为网络完全由单一服务提供商在单一策略下管理，因此可能在每个AS中使用一组一致的技术。
The second scenario may be more complex than the first because the strategy and technology choices made for each AS may have been different due to their differing histories, and the service provider may not have unified (or may be unwilling to unify) the strategy and technology choices for each AS.
第二种情况可能比第一种情况更复杂，因为每个AS的战略和技术选择可能因其不同的历史而不同，并且服务提供商可能没有统一（或不愿意统一）每个AS的战略和技术选择。
The third scenario is the most complex because in addition to the complexity of the second scenario, the ASes are managed by different service providers and therefore may be subject to a different trust model than the other scenarios.
第三个场景是最复杂的，因为除了第二个场景的复杂性之外，ASE由不同的服务提供商管理，因此可能受到不同于其他场景的信任模型的约束。
Section 5.2.6 of [RFC4834] states that "a solution MUST support inter-AS multicast VPNs, and SHOULD support inter-provider multicast VPNs", "considerations about co-existence with unicast inter-AS VPN Options A, B, and C (as described in Section 10 of [RFC4364]) are strongly encouraged", and "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".
[RFC4834]第5.2.6节规定，“解决方案必须支持AS间多播VPN，并应支持提供商间多播VPN”，“强烈鼓励考虑与单播AS间VPN选项a、B和C共存（如[RFC4364]第10节所述）”，以及“多播VPN解决方案应提供要求提供商之间尽可能少的协调的AS间机制，并将对提供商网络的详细信息的需求保持在最低限度——所有这些都与相应的单播VPN选项相比较”。
Section 8 of [RFC6513] addresses these requirements by proposing two approaches for MVPN inter-AS deployments:
[RFC6513]第8节提出了两种MVPN AS间部署方法，以满足这些要求：
1. Non-segmented inter-AS tunnels where the multicast tunnels are end-to-end across ASes, so even though the PEs belonging to a given MVPN may be in different ASes, the ASBRs play no special role and function merely as P routers (described in Section 8.1).
1. 非分段AS间隧道，其中多播隧道跨ASE端到端，因此，即使属于给定MVPN的PE可能位于不同的ASE中，ASBR仅作为P路由器（在第8.1节中描述）发挥特殊作用和功能。
2. Segmented inter-AS tunnels where each AS constructs its own separate multicast tunnels that are then 'stitched' together by the ASBRs (described in Section 8.2).
2. 分段的AS间隧道，其中每个AS构建自己的独立多播隧道，然后由ASBR“缝合”在一起（如第8.2节所述）。
(Note that an inter-AS deployment can alternatively rely on Option A -- so-called "back-to-back" VRFs -- that option is not considered in this section given that it can be used without any inter-AS-specific mechanism.)
（请注意，AS间部署也可以依赖于选项A——所谓的“背靠背”VRF——本节不考虑该选项，因为它可以在没有任何AS间特定机制的情况下使用。）
Section 5.2.6 of [RFC4834] also states, "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)". The segmented approach is the only one capable of meeting this requirement.
[RFC4834]的第5.2.6节还指出，“在每个服务提供商内部，服务提供商应能够自行选择最合适的隧道机制，以在PEs之间传输（多播）流量（就像今天单播所做的那样）”。分段方法是唯一能够满足这一要求的方法。
The segmented inter-AS solution would appear to offer the largest degree of deployment flexibility to operators. However, the non-segmented inter-AS solution can simplify deployment in a restricted number of scenarios. [RFC6037] only supports the non-segmented inter-AS solution; therefore, the non-segmented inter-AS solution is likely to be useful to some operators for backward compatibility and during migration from [RFC6037] to [RFC6513].
分段式AS解决方案似乎为运营商提供了最大程度的部署灵活性。但是，非分段的内部AS解决方案可以在数量有限的场景中简化部署。[RFC6037]仅支持非分段的内部AS解决方案；因此，在从[RFC6037]迁移到[RFC6513]的过程中，非分段AS间解决方案对于某些运营商的向后兼容性可能非常有用。
The following is a comparison matrix between the "segmented inter-AS P-tunnels" and "non-segmented inter-AS P-tunnels" approaches:
以下是“分段式AS P隧道”和“非分段式AS P隧道”方法之间的比较矩阵：
o Scalability for I-PMSIs: The "segmented inter-AS P-tunnels" approach is more scalable, because of the ability of an ASBR to aggregate multiple intra-AS P-tunnels used for I-PMSI within its own AS into one inter-AS P-tunnel to be used by other ASes. Note that the I-PMSI scalability improvement brought by the "segmented inter-AS P-tunnels" approach is higher when segmented P-tunnels have a granularity of source AS (see item below).
o I-PMSI的可扩展性：“分段AS间P隧道”方法更具可扩展性，因为ASBR能够将其自身AS内用于I-PMSI的多个AS内P隧道聚合为一个AS间P隧道，供其他AS使用。请注意，当分段P-隧道具有源AS粒度时，“分段内部AS P-隧道”方法带来的I-PMSI可扩展性改进更高（见下文）。
o Scalability for S-PMSIs: The "segmented inter-AS P-tunnels" approach, when used with the BGP-based C-multicast routing approach, provides flexibility in how the bandwidth/state trade-off is handled, to help with scalability. Indeed, in that case, the trade-off made for a said (C-S,C-G) in a downstream AS can be made more in favor of scalability than the trade-off made by the neighbor upstream AS, thanks to the ability to aggregate one or more S-PMSIs of the upstream AS in one I-PMSI tunnel in a downstream AS.
o S-PMSIs的可伸缩性：“分段的内部作为P-隧道”方法，当与基于BGP的C-多播路由方法一起使用时，在如何处理带宽/状态权衡方面提供了灵活性，以帮助实现可伸缩性。事实上，在这种情况下，由于能够在下游AS的一个I-PMSI隧道中聚合上游AS的一个或多个S-PMSI，因此在下游AS中为所述（C-S，C-G）进行的权衡比相邻上游AS进行的权衡更有利于可伸缩性。
o Configuration at ASBRs: Depending on whether segmented P-tunnels have a granularity of source ASBR or source AS, the "segmented inter-AS P-tunnels" approach would require respectively the same or additional configuration on ASBRs as the "non-segmented inter-AS P-tunnels" approach.
o ASBR处的配置：根据分段P隧道是否具有源ASBR或源AS的粒度，“分段内部AS P隧道”方法将分别要求ASBR上与“非分段内部AS P隧道”方法相同或额外的配置。
o Independence of tunneling technology from one AS to another: The "segmented inter-AS P-tunnels" approach provides this; the "non-segmented inter-AS P-tunnels" approach does not.
o 隧道技术从一个AS到另一个AS的独立性：“分段式AS P隧道”方法提供了这一点；“非分段式内部AS P隧道”方法不适用。
o Facilitated coexistence with, and migration from, existing deployments and lighter engineering in some scenarios: The "non-segmented inter-AS P-tunnels" approach provides this; the "segmented inter-AS P-tunnels" approach does not.
o 在某些场景中，促进了与现有部署和轻型工程的共存和迁移：“非分段内部AS P隧道”方法提供了这一点；“分段式跨P隧道”方法不适用。
The applicability of segmented or non-segmented inter-AS tunnels to a given deployment or inter-provider interconnect will depend on a number of factors specific to each service provider. However, given the different elements reminded above, it is the recommendation of
分段或非分段AS间隧道对给定部署或提供商间互连的适用性将取决于每个服务提供商特定的许多因素。然而，鉴于上文提到的不同因素，这是委员会的建议
the authors that all implementations should support the segmented inter-AS model. Additionally, the authors recommend that implementations should consider supporting the non-segmented inter-AS model in order to facilitate coexistence with, and migration from, existing deployments, and to provide a lighter engineering in a restricted set of scenarios, although it is recognized that initial implementations may only support one or the other.
作者建议所有的实现都应该支持分段的内部AS模型。此外，作者建议，实现应该考虑支持非分段的AS间模型，以便于与现有部署共存，并迁移现有的部署，并在受限的场景集合中提供较轻的工程。尽管人们认识到初始实现可能只支持其中一种。
In BIDIR-PIM, the packet-forwarding rules have been improved over PIM-SM, allowing traffic to be passed up the shared tree toward the RPA. To avoid multicast packet looping, BIDIR-PIM uses a mechanism called the designated forwarder (DF) election, which establishes a loop-free tree rooted at the RPA. Use of this method ensures that only one copy of every packet will be sent to an RPA, even if there are parallel equal cost paths to the RPA. To avoid loops, the DF election process enforces a consistent view of the DF on all routers on network segment, and during periods of ambiguity or routing convergence, the traffic forwarding is suspended.
在BIDIR-PIM中，数据包转发规则比PIM-SM有所改进，允许通信量沿着共享树向RPA传递。为了避免多播数据包循环，BIDIR-PIM使用了一种称为指定转发器（DF）选择的机制，该机制在RPA上建立了一个无循环树。使用此方法可确保每个数据包只有一个副本发送到RPA，即使存在到RPA的并行等成本路径。为了避免循环，DF选择过程在网段上的所有路由器上强制DF的一致视图，并且在模糊或路由收敛期间，流量转发被暂停。
In the context of a multicast VPN solution, a solution for BIDIR-PIM support must preserve this property of similarly avoiding packet loops, including in the case where multicast VRFs in a given MVPN don't have a consistent view of the routing to C-RPL/C-RPA (Customer-RPL/Customer-RPA, i.e., RPL/RPA of a Bidir customer PIM instance).
在多播VPN解决方案的上下文中，BIDIR-PIM支持的解决方案必须保留类似地避免分组循环的这一属性，包括在给定MVPN中的多播VRF没有到C-RPL/C-RPA（客户RPL/客户RPA，即BIDIR客户PIM实例的RPL/RPA）的路由的一致视图的情况下。
Section 11 of the current MVPN specification [RFC6513] defines three methods to support BIDIR-PIM, as RECOMMENDED in [RFC4834]:
按照[RFC4834]中的建议，当前MVPN规范[RFC6513]第11节定义了三种支持BIDIR-PIM的方法：
1. Standard DF election procedure over an MI-PMSI
1. MI-PMSI上的标准DF选举程序
2. VPN Backbone as the RPL (Section 11.1)
2. 作为RPL的VPN主干（第11.1节）
3. Partitioned Sets of PEs (Section 11.2)
3. PEs的分区集（第11.2节）
Method (1) is naturally applied to deployments using "Full per-MVPN PIM peering across an MI-PMSI" for C-multicast routing, but as indicated in [RFC6513], Section 11, the DF election may not work well in an MVPN environment, and an alternative to DF election would be desirable.
方法（1）自然适用于使用“跨MI-PMSI的完整每MVPN PIM对等”进行C-多播路由的部署，但如[RFC6513]第11节所述，DF选择在MVPN环境中可能无法正常工作，需要DF选择的替代方案。
The advantage of methods (2) and (3) is that they do not require running the DF election procedure among PEs.
方法（2）和（3）的优点是它们不需要在PEs之间运行DF选举程序。
Method (2) leverages the fact that in BIDIR-PIM, running the DF election procedure is not needed on the RPL. This approach thus has the benefit of simplicity of implementation, especially in a context
方法（2）利用了以下事实：在BIDIR-PIM中，RPL上不需要运行DF选举过程。因此，这种方法具有实现简单的优点，特别是在特定环境中
where BGP-based C-multicast routing is used. However, it has the drawback of putting constraints on how BIDIR-PIM is deployed, which may not always match the requirements of MVPN customers.
其中使用基于BGP的C多播路由。然而，它的缺点是对BIDIR-PIM的部署方式有限制，这可能并不总是符合MVPN客户的要求。
Method (3) treats an MVPN as a collection of sets of multicast VRFs, all PEs in a set having the same reachability information towards C-RPA but distinct from PEs in other sets. Hence, with this method, C-Bidir packet loops in MVPN are resolved by the ability to partition a VPN into disjoint sets of VRFs, each having a distinct view of the converged network. The partitioning approach to BIDIR-PIM requires either upstream-assigned MPLS labels (to denote the partition) or a unique MP2MP LSP per partition. The former is based on PE Distinguisher Labels that have to be distributed using auto-discovery BGP routes, and their handling requires the support for upstream assigned labels and context label lookups [RFC5331]. The latter, using MP2MP LSP per partition, does not have these constraints but is restricted to P-tunnel types supporting MP2MP connectivity (such as mLDP [RFC6388]).
方法（3）将MVPN视为多播VRF集合，集合中的所有PE对C-RPA具有相同的可达性信息，但不同于其他集合中的PE。因此，通过这种方法，MVPN中的C-Bidir数据包循环可以通过将VPN划分为不相交的VRF集来解决，每个VRF都具有聚合网络的不同视图。BIDIR-PIM的分区方法需要上游分配的MPLS标签（表示分区）或每个分区唯一的MP2MP LSP。前者基于必须使用自动发现BGP路由分发的PE识别器标签，其处理需要支持上游分配的标签和上下文标签查找[RFC5331]。后者，每个分区使用MP2MP LSP，没有这些限制，但仅限于支持MP2MP连接的P隧道类型（如mLDP[RFC6388]）。
This approach to C-Bidir can work with PIM-based or BGP-based C-multicast routing procedures and is also generic in the sense that it does not impose any requirements on the BIDIR-PIM service offering.
这种C-Bidir方法可以与基于PIM或基于BGP的C-multicast路由过程一起使用，并且在不对Bidir-PIM服务提供施加任何要求的意义上也是通用的。
Given the above considerations, method (3) "Partitioned Sets of PEs" is the RECOMMENDED approach.
鉴于上述考虑，建议采用方法（3）“PEs分区集”。
In the event where method (3) is not applicable (lack of support for upstream assigned labels or for a P-tunnel type providing MP2MP connectivity), then method (1) "Standard DF election procedure over an MI-PMSI" and (2) "VPN Backbone as the RPL" are RECOMMENDED as interim solutions, (1) having the advantage over (2) of not putting constraints on how BIDIR-PIM is deployed and the drawbacks of only being applicable when PIM-based C-multicast is used and of possibly not working well in an MVPN environment.
如果方法（3）不适用（缺乏对上游指定标签或提供MP2MP连接的P隧道类型的支持），则建议将方法（1）“MI-PMSI上的标准DF选择程序”和（2）“作为RPL的VPN主干网”作为临时解决方案，（1）具有（2）的优势不限制BIDIR-PIM的部署方式，以及仅在使用基于PIM的C-multicast时适用的缺点，以及在MVPN环境中可能无法正常工作的缺点。
Section 5.1.10.1 of [RFC4834] states, "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".
[RFC4834]第5.1.10.1节规定，“对于ASM模式下的PIM-SM，RP功能的工程设计需要部署特定协议和相关配置。服务提供商可以代表客户管理其多播协议操作。这意味着有必要考虑客户的RPS外包的情况（例如，在PES上）。因此，VPN解决方案可支持在VR或VRF中托管RP功能”。
However, customers who have already deployed multicast within their networks and have therefore already deployed their own internal RPs
但是，已经在其网络中部署了多播的客户，因此已经部署了自己的内部RPs
are often reluctant to hand over the control of their RPs to their service provider and make use of a co-located RP model, and providing RP-collocation on a PE will require the activation of Multicast Source Discovery Protocol (MSDP) or the processing of PIM Registers on the PE. Securing the PE routers for such activity requires special care and additional work and will likely rely on specific features to be provided by the routers themselves.
通常不愿意将其RPs的控制权移交给其服务提供商，并使用同一位置的RP模型，并且在PE上提供RP配置将需要激活多播源发现协议（MSDP）或处理PE上的PIM寄存器。为此类活动保护PE路由器需要特别小心和额外工作，并可能依赖路由器自身提供的特定功能。
The applicability of the co-located RP model to a given MVPN will thus depend on a number of factors specific to each customer and service provider.
因此，共同定位RP模型对给定MVPN的适用性将取决于每个客户和服务提供商特定的许多因素。
It is therefore the recommendation that implementations should support a co-located RP model but that support for a co-located RP model within an implementation should not restrict deployments to using a co-located RP model: implementations MUST support deployments when activation of a PIM RP function (PIM Register processing and RP-specific PIM procedures) or a VRF MSDP instance is not required on any PE router and where all the RPs are deployed within the customers' networks or CEs.
因此，建议实施应支持同一位置的RP模型，但实施中对同一位置的RP模型的支持不应限制部署使用同一位置的RP模型：激活PIM RP功能时，实施必须支持部署（PIM注册处理和RP特定PIM程序）或VRF MSDP实例在任何PE路由器上都不需要，并且所有RPs都部署在客户网络或CE中。
It is recommended that implementations support the procedures described in Section 9.1.1 of [RFC6513] "Discarding Packets from Wrong PE", allowing fully avoiding duplicates.
建议实施支持[RFC6513]第9.1.1节“从错误PE丢弃数据包”中描述的程序，从而完全避免重复。
Some suggestions provided in this document can be used to incrementally modify currently deployed implementations without hindering these deployments and without hindering the consistency of the standardized solution by providing optional per-VRF configuration knobs to support modes of operation compatible with currently deployed implementations, while at the same time using the recommended approach on implementations supporting the standard.
本文件中提供的一些建议可用于增量修改当前部署的实施，而不妨碍这些部署，也不妨碍标准化解决方案的一致性，方法是提供可选的每VRF配置旋钮，以支持与当前部署的实施兼容的操作模式，同时在支持标准的实现上使用推荐的方法。
In cases where this may not be easily achieved, a recommended approach would be to provide a per-VRF configuration knob that allows incremental per-VPN migration of the mechanisms used by a PE device, which would allow migration with some per-VPN interruption of service (e.g., during a maintenance window).
在不容易实现的情况下，建议的方法是提供每VRF配置旋钮，允许PE设备使用的机制的每VPN增量迁移，这将允许在每VPN服务中断的情况下进行迁移（例如，在维护窗口期间）。
Mechanisms allowing "live" migration by providing concurrent use of multiple alternatives for a given PE and a given VPN are not seen as a priority considering the expected implementation complexity
考虑到预期的实现复杂性，允许通过为给定PE和给定VPN同时使用多个备选方案进行“实时”迁移的机制不被视为优先考虑的问题
associated with such mechanisms. However, if there happen to be cases where they could be viably implemented relatively simply, such mechanisms may help improve migration management.
与这种机制有关。然而，如果在某些情况下可以相对简单地实施这些机制，这些机制可能有助于改进迁移管理。
The following list summarizes conclusions on the mechanisms that define the set of mandatory-to-implement mechanisms in the context of [RFC6513].
下表总结了关于在[RFC6513]上下文中定义强制执行机制集的机制的结论。
Note well that the implementation of the non-mandatory alternative mechanisms is not precluded.
请注意，不排除实施非强制性替代机制。
Recommendations are:
建议如下：
o that BGP-based auto-discovery be the mandated solution for auto-discovery;
o 基于BGP的自动发现是自动发现的强制解决方案；
o that BGP be the mandated solution for S-PMSI switching signaling;
o BGP是S-PMSI交换信令的强制解决方案；
o that implementations support both the BGP-based and the full per-MVPN PIM peering solutions for PE-PE exchange of customer multicast routing until further operational experience is gained with both solutions;
o 实现支持基于BGP和完整的每MVPN PIM对等解决方案，用于客户多播路由的PE-PE交换，直到获得这两种解决方案的进一步操作经验；
o that implementations use the "Partitioned Sets of PEs" approach for BIDIR-PIM support;
o 实现使用“PEs分区集”方法支持BIDIR-PIM；
o that implementations implement the P2MP variants of the P2P protocols that they already implement, such as mLDP, P2MP RSVP-TE, and GRE/IP-Multicast;
o 实现已经实现的P2P协议的P2MP变体，如mLDP、P2MP-RSVP-TE和GRE/IP多播；
o that implementations support segmented inter-AS tunnels and consider supporting non-segmented inter-AS tunnels (in order to maintain backward compatibility and for migration);
o 该实现支持分段的AS AS隧道，并考虑支持非分段的AS AS隧道（以保持向后兼容性和迁移）；
o that implementations MUST support deployments when the activation of a PIM RP function (PIM Register processing and RP-specific PIM procedures) or VRF MSDP instance is not required on any PE router; and
o 在任何PE路由器上不需要激活PIM RP功能（PIM寄存器处理和RP特定PIM过程）或VRF MSDP实例时，实施必须支持部署；和
o that implementations support the procedures described in Section 9.1.1 of [RFC6513].
o 实施支持[RFC6513]第9.1.1节所述的程序。
This document does not by itself raise any particular security considerations.
本文件本身没有提出任何特定的安全考虑。
We would like to thank Adrian Farrel, Eric Rosen, Yakov Rekhter, and Maria Napierala for their feedback that helped shape this document.
我们要感谢Adrian Farrel、Eric Rosen、Yakov Rekhter和Maria Napierala的反馈，他们的反馈帮助形成了本文件。
Additional credit is due to Maria Napierala for co-authoring Section 3.6 on BIDIR-PIM Support.
Maria Napierala共同编写了关于BIDIR-PIM支持的第3.6节，这是额外的功劳。
[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月。
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, February 2012.
[RFC6513]Rosen，E.，Ed.和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，2012年2月。
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，2012年2月。
[MVPN] Aggarwal, R., "Base Specification for Multicast in BGP/ MPLS VPNs", Work in Progress, June 2004.
[MVPN]Aggarwal，R.，“BGP/MPLS VPN中多播的基本规范”，正在进行的工作，2004年6月。
[PIM-PORT] Farinacci, D., Wijnands, I., Venaas, S., and M. Napierala, "A Reliable Transport Mechanism for PIM", Work in Progress, October 2011.
[PIM-PORT]Farinaci，D.，Wijnands，I.，Venaas，S.，和M.Napierala，“PIM的可靠运输机制”，正在进行的工作，2011年10月。
[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月。
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, November 2006.
[RFC4684]Marques，P.，Bonica，R.，Fang，L.，Martini，L.，Raszuk，R.，Patel，K.，和J.Guichard，“边界网关协议/多协议标签交换（BGP/MPLS）互联网协议（IP）虚拟专用网络（VPN）的受限路由分布”，RFC 46842006年11月。
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[RFC4834]Morin，T.，Ed.“第3层提供商提供的虚拟专用网络（PPVPN）中的多播要求”，RFC 4834，2007年4月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 53312008年8月。
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.
[RFC5796]Atwood，W.，Islam，S.，和M.Siami，“协议独立多播稀疏模式（PIM-SM）链路本地消息中的身份验证和机密性”，RFC 57962010年3月。
[RFC6037] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs", RFC 6037, October 2010.
[RFC6037]Rosen，E.，Cai，Y.，和IJ。Wijnands，“思科系统在BGP/MPLS IP VPN中的多播解决方案”，RFC 6037，2010年10月。
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[RFC6388]Wijnands，IJ.，Minei，I.，Kompella，K.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月。
The main role of multicast routing is to let routers determine that they should start or stop forwarding a said multicast stream on a said link. In an MVPN context, this has to be done for each MVPN, and the associated function is thus named "customer-multicast routing" or "C-multicast routing", and its role is to let PE routers determine that they should start or stop forwarding the traffic of a said multicast stream toward the remote PEs, on some PMSI tunnel.
多播路由的主要作用是让路由器确定它们应该开始或停止在所述链路上转发所述多播流。在MVPN上下文中，这必须针对每个MVPN进行，并且相关联的功能因此被命名为“客户多播路由”或“C多播路由”，其作用是让PE路由器确定它们应该在一些PMSI隧道上开始或停止将所述多播流的流量转发到远程PEs。
When a Join message is received by a PE, this PE knows that it should be sending traffic for the corresponding multicast group of the corresponding MVPN. However, the reception of a Prune message from a remote PE is not enough by itself for a PE to know that it should stop forwarding the corresponding multicast traffic: it has to make sure that there aren't any other PEs that still have receivers for this traffic.
当PE接收到加入消息时，该PE知道它应该为相应MVPN的相应多播组发送通信量。然而，从远程PE接收到的删减消息本身并不足以让PE知道它应该停止转发相应的多播通信量：它必须确保没有任何其他PE仍然有此通信量的接收器。
There are many ways that the "C-multicast routing" building block can be designed, and they differ, among other things, in how a PE determines when it can stop forwarding a said multicast stream toward other PEs:
设计“C-多播路由”构建块的方法有很多种，其中不同之处在于PE如何确定何时可以停止向其他PE转发所述多播流：
PIM LAN Procedures, by default By default, when PIM LAN procedures are used when a PE on a LAN Prunes itself from a multicast tree, all other PEs on that LAN check their own state to known if they are on the tree, in which case they send a PIM Join message on that LAN to override the Prune. Thus, for each PIM Prune message, all PE routers on the LAN work to let the upstream PE determine the answer to the "did the last receiver leave?" question.
PIM LAN过程，默认情况下，当使用PIM LAN过程时，当LAN上的PE从多播树上修剪自身时，该LAN上的所有其他PE检查自己的状态，以了解它们是否在树上，在这种情况下，它们在该LAN上发送PIM Join消息以覆盖修剪。因此，对于每个PIM删减消息，LAN上的所有PE路由器都会让上游PE确定“最后一个接收器离开了吗？”问题的答案。
BGP-based C-multicast routing When BGP-based procedures are used for C-multicast routing, if no BGP route reflector is used, the "did the last receiver leave?" question is answered by having the upstream PE maintain an up-to-date list of the PEs that are joined to the tree, thus making it possible to instantly know the answer to the "did the last receiver leave?" question whenever a PE leaves the said multicast tree.
基于BGP的C-多播路由当基于BGP的过程用于C-多播路由时，如果没有使用BGP路由反射器，则通过让上游PE维护加入到树的PE的最新列表来回答“最后一个接收方离开了吗？”问题，从而使其能够立即知道问题的答案每当PE离开所述多播树时，“最后一个接收者离开了吗？”问题。
However, when a BGP route reflector is used (which is expected to be the recommended approach), the role of maintaining an updated list of the PEs that are part of a said multicast tree is taken care of by the route reflector(s). Using BGP procedures, a route reflector that had advertised a C-multicast Source Tree Join route for a said (C-S,C-G) to other route reflectors before will withdraw this route when there is no of its clients PEs
然而，当使用BGP路由反射器时（这预计是推荐的方法），维护作为所述多播树的一部分的pe的更新列表的角色由路由反射器负责。使用BGP过程，之前向其他路由反射器通告所述（C-S，C-G）的C-多播源树加入路由的路由反射器将在没有其客户端PE时撤回该路由
advertising this route anymore. Similarly, a route reflector that had advertised this route to its client PEs before will withdraw this route when its (other) client PEs and its route reflectors peers are no longer advertising this route. In this context, the "did the last receiver leave?" question can be said to be answered by the route reflector(s).
这条路线不再做广告了。类似地，当其（其他）客户端PE及其路由反射器对等方不再宣传此路由时，之前向其客户端PE宣传此路由的路由反射器将撤回此路由。在这种情况下，“最后一个接收者离开了吗？”问题可以说是由路线反射器回答的。
Furthermore, the BGP route distribution can leverage more than one route reflector: if multiple route reflectors are used with PEs being distributed (as clients) among these route reflectors, the "did the last receiver leave?" question is partly answered by each of these route reflectors.
此外，BGP路由分发可以利用多个路由反射器：如果多个路由反射器与这些路由反射器之间分发的PE（作为客户端）一起使用，则每个路由反射器都会部分回答“最后一个接收器离开了吗？”。
We can see that the "last receiver leaves" question is a part of the work that the C-multicast routing building block has to address, and the different approaches significantly differ. The different approaches for handling C-multicast routing can indeed result in a different amount of processing and how this processing is spread among the different functions. These differences can be better estimated by quantifying the amount of message processing and state maintenance.
我们可以看到，“最后一个接收者离开”问题是C-多播路由构建块必须解决的工作的一部分，不同的方法有很大不同。处理C多播路由的不同方法确实会导致不同的处理量，以及该处理如何在不同功能之间传播。通过量化消息处理和状态维护的数量，可以更好地估计这些差异。
Though the type of processing, messages, and states may vary with the different approaches, we propose here a rough estimation of the load of PEs, in terms of number of messages processed and number of control plane states maintained. A "message processed" is a message being parsed, a lookup being done, and some action being taken (such as, for instance, updating a control plane or data plane state or discarding the information in the message). A "state maintained" is a multicast state kept in the control plane memory of a PE, related to an interface or a PE being subscribed to a multicast stream (note that a state will be counted on an equipment as many times as the number of protocols in which it is present, e.g., two times when present both as a PIM state and a BGP route). Note that here we don't compare the data plane states on PE routers, which wouldn't vary between the different options chosen.
尽管处理类型、消息和状态可能因不同的方法而不同，但我们在此提出了PEs负载的粗略估计，即处理的消息数量和保持的控制平面状态数量。“消息已处理”是正在解析的消息、正在执行的查找以及正在执行的某些操作（例如，更新控制平面或数据平面状态或丢弃消息中的信息）。“状态保持”是保存在PE的控制平面存储器中的多播状态，与订阅多播流的接口或PE有关（注意，设备上的状态将被计数为其存在的协议数量的两倍，例如，当同时作为PIM状态和BGP路由存在时是两倍）。请注意，这里我们不比较PE路由器上的数据平面状态，这在所选的不同选项之间不会有所不同。
The following sections evaluate the processing and state maintenance load for an increasingly high number of PEs in a VPN.
以下各节评估VPN中越来越多的PE的处理和状态维护负载。
The following subsections do such an estimation for each proposed approach for C-multicast routing, for different phases of the following scenario:
以下小节针对以下场景的不同阶段，对C-多播路由的每种拟议方法进行了此类评估：
o One SSM multicast stream is considered.
o 考虑一个SSM多播流。
o Only the intra-AS case is concerned (with the segmented inter-AS tunnels and BGP-based C-multicast routing, #mvpn_PE and #R_PE should refer to the PEs of the MVPN in the AS, not to all PEs of the MVPN).
o 仅涉及内部AS情况（对于分段的内部AS隧道和基于BGP的C多播路由，#mvpn_PE和#R_PE应指AS中mvpn的PE，而不是mvpn的所有PE）。
o The scenario is as follows:
o 情况如下：
* One PE joins the multicast stream (because of a new receiver-connected site has sent a Join on the PE-CE link), followed by a number of additional PEs that also join the same multicast stream, one after the other; we evaluate the processing required for the addition of each PE.
* 一个PE加入多播流（因为一个新的接收器连接站点已在PE-CE链路上发送了一个加入），然后是一个接一个地加入相同多播流的多个附加PE；我们评估添加每种PE所需的处理。
* A period of time T passes, without any PE joining or leaving (baseline).
* 一段时间T过去，没有任何PE加入或离开（基线）。
* All PEs leave, one after the other, until the last one leaves; we evaluate the processing required for the leave of each PE.
* 所有PE一个接一个地离开，直到最后一个离开；我们评估每个PE休假所需的处理。
o The parameters used are:
o 使用的参数包括：
* #mvpn_PE: the number of PEs in the MVPN
* #mvpn_PE: the number of PEs in the MVPN
* #R_PE: the number of PEs joining the multicast stream
* #R_PE: the number of PEs joining the multicast stream
* #RR: the number of route reflectors
* #RR: the number of route reflectors
* T_PIM_r: the time between two refreshes of a PIM Join (default is 60s)
* T_PIM_r：PIM联接两次刷新之间的时间（默认值为60秒）
The estimation unit used is the "message.equipment" (or "m.e"): one "message.equipment" corresponds to "one equipment processing one message" (10 m.e being "10 equipments processing each one message", "5 messages each processed by 2 equipments", or "1 message processed by 10 equipment", etc.). Similarly, for the amount of control plane state, the unit used is "state.equipment" or "s.e". This accounts for the fact that a message (or a state) can be processed (or maintained) by more than one node.
使用的估算单位为“消息设备”（或“m.e”）：一个“消息设备”对应于“一个设备处理一条消息”（10个m.e表示“10个设备处理一条消息”，“2个设备处理5条消息”，或“10个设备处理1条消息”，等等）。同样，对于控制平面状态量，使用的单位为“状态设备”或“s.e”。这说明了一个消息（或状态）可以由多个节点处理（或维护）的事实。
We distinguish three different types of equipments: the upstream PE for the considered multicast stream, the RR (if any), and the other PEs (which are not the upstream PE).
我们区分三种不同类型的设备：所考虑的多播流的上游PE、RR（如果有）和其他PE（不是上游PE）。
The numbers or orders of magnitude given in the tables in the following subsections are totals across all equipments of a same type, for each type of equipment, in the "m.e" and "s.e" units defined above.
以下各小节表格中给出的数量或数量级是同一类型所有设备的总数，对于每种类型的设备，以上述定义的“m.e”和“s.e”单位表示。
Additionally:
此外：
o For PIM, only Join and Prune messages are counted:
o 对于PIM，仅计算加入和删除消息：
* The load due to PIM Hellos can be easily computed separately and only depends on the number of PEs in the VPN.
* PIM Hellos导致的负载可以很容易地单独计算，并且仅取决于VPN中PE的数量。
* Message processing related to the PIM Assert mechanism is also not taken into account, for the sake of simplicity.
* 为了简单起见，也没有考虑与PIM断言机制相关的消息处理。
o For BGP, all advertisements and withdrawals of C-multicast Source Tree Join routes are considered (Source-Active auto-discovery routes are not used in an SSM context); following the recommendation in Section 16 of [RFC6514], the case where the Route Target Constraint mechanisms [RFC4684] is not used is not covered.
o 对于BGP，考虑C-多播源树加入路由的所有播发和撤回（在SSM上下文中不使用源活动自动发现路由）；根据[RFC6514]第16节中的建议，不包括未使用路由目标约束机制[RFC4684]的情况。
(Note that for all options provided for C-multicast routing, the procedures to set up and maintain a shortest path tree toward the source of an SSM group are the same as the procedures used to set up and maintain a shortest path tree toward an RP or a non-SSM source; the results of this section are thus re-used in Appendix A.1.2.)
（注意，对于为C-多播路由提供的所有选项，设置和维护指向SSM组源的最短路径树的程序与设置和维护指向RP或非SSM源的最短路径树的程序相同；因此，本节的结果在附录a.1.2中重复使用。）
+------------+------------+---------------+----------+--------------+
| | upstream | other PEs | RR | total across |
| | PE (1) | (total across | (none) | all |
| | | (#mvpn_PE-1) | | equipments |
| | | PEs) | | |
+------------+------------+---------------+----------+--------------+
| first PE | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e |
| joins | | m.e | | |
+------------+------------+---------------+----------+--------------+
| for *each* | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e |
| additional | | m.e | | |
| PE joining | | | | |
+------------+------------+---------------+----------+--------------+
| baseline | T/T_PIM_r | (T/T_PIM_r) . | / | (T/T_PIM_r) |
| processing | m.e | (#mvpn_PE-1) | | x #mvpn_PE |
| over a | | m.e | | m.e |
| period T | | | | |
+------------+------------+---------------+----------+--------------+
| for *each* | 2 m.e | 2(#mvpn_PE-1) | / | 2 x #mvpn_PE |
| PE leaving | | m.e | | m.e |
+------------+------------+---------------+----------+--------------+
| the last | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e |
| PE leaves | | m.e | | |
+------------+------------+---------------+----------+--------------+
| total for | #R_PE x 2 | (#mvpn_PE-1) | 0 | #mvpn_PE x ( |
| #R_PE PEs | + | x (#R_PE) x 2 | | 3 x #R_PE + |
| | T/T_PIM_r | + T/T_PIM_r) | | T/T_PIM_r ) |
| | m.e | . | | m.e |
| | | (#mvpn_PE-1) | | |
| | | m.e | | |
+------------+------------+---------------+----------+--------------+
| total | 1 s.e | #R_PE s.e | 0 | #R_PE+1 s.e |
| state | | | | |
| maintained | | | | |
+------------+------------+---------------+----------+--------------+
+------------+------------+---------------+----------+--------------+
| | upstream | other PEs | RR | total across |
| | PE (1) | (total across | (none) | all |
| | | (#mvpn_PE-1) | | equipments |
| | | PEs) | | |
+------------+------------+---------------+----------+--------------+
| first PE | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e |
| joins | | m.e | | |
+------------+------------+---------------+----------+--------------+
| for *each* | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e |
| additional | | m.e | | |
| PE joining | | | | |
+------------+------------+---------------+----------+--------------+
| baseline | T/T_PIM_r | (T/T_PIM_r) . | / | (T/T_PIM_r) |
| processing | m.e | (#mvpn_PE-1) | | x #mvpn_PE |
| over a | | m.e | | m.e |
| period T | | | | |
+------------+------------+---------------+----------+--------------+
| for *each* | 2 m.e | 2(#mvpn_PE-1) | / | 2 x #mvpn_PE |
| PE leaving | | m.e | | m.e |
+------------+------------+---------------+----------+--------------+
| the last | 1 m.e | #mvpn_PE-1 | / | #mvpn_PE m.e |
| PE leaves | | m.e | | |
+------------+------------+---------------+----------+--------------+
| total for | #R_PE x 2 | (#mvpn_PE-1) | 0 | #mvpn_PE x ( |
| #R_PE PEs | + | x (#R_PE) x 2 | | 3 x #R_PE + |
| | T/T_PIM_r | + T/T_PIM_r) | | T/T_PIM_r ) |
| | m.e | . | | m.e |
| | | (#mvpn_PE-1) | | |
| | | m.e | | |
+------------+------------+---------------+----------+--------------+
| total | 1 s.e | #R_PE s.e | 0 | #R_PE+1 s.e |
| state | | | | |
| maintained | | | | |
+------------+------------+---------------+----------+--------------+
Messages Processing and State Maintenance - PIM LAN Procedures, by Default
消息处理和状态维护-默认情况下，PIM LAN程序
We suppose here that the PIM Join suppression and Prune Override mechanisms are fully effective, i.e., that a Join or Prune message sent by a PE is instantly seen by other PEs. Strictly speaking, this is not true, and depending on network delays and timing, there could be cases where more messages are exchanged, and the number given in this table is a lower bound to the number of PIM messages exchanged.
这里我们假设PIM连接抑制和剪枝覆盖机制是完全有效的，即PE发送的连接或剪枝消息立即被其他PE看到。严格地说，这是不正确的，并且根据网络延迟和定时，可能存在交换更多消息的情况，并且此表中给出的数字是交换的PIM消息数量的下限。
The following analysis assumes that BGP route reflectors (RRs) are used, and no hierarchy of RRs (note that the analysis also assumes that Route Target Constraint mechanisms are used).
以下分析假设使用了BGP路由反射器（RRs），并且没有RRs的层次结构（注意，分析还假设使用了路由目标约束机制）。
Given these assumptions, a message carrying a C-multicast route from a downstream PE would need to be processed by the RRs that have that PE as their client. Due to the use of Route Target Constraint mechanisms [RFC4684], these RRs would then send this message to only the RRs that have the upstream PE as a client. None of the other RRs and none of the other PEs will receive this message. Thus, for a message associated with a given MVPN, the total number of RRs that would need to process this message only depends on the number of RRs that maintain C-multicast routes for that MVPN and that have either the receiver-connected PE or the source-connected PE as their clients and is independent of the total number of RRs or the total number of PEs.
鉴于这些假设，携带来自下游PE的C-多播路由的消息将需要由将该PE作为其客户端的RRs进行处理。由于使用路由目标约束机制[RFC4684]，这些RRs随后将仅将此消息发送给将上游PE作为客户端的RRs。其他RRs和PEs都不会收到此消息。因此，对于与给定MVPN关联的消息，需要处理此消息的RRs总数仅取决于为该MVPN维护C-多播路由的RRs的数量，以及将接收器连接的PE或源连接的PE作为其客户端的RRs的数量，并且与RRs的总数或PE的总数无关。
In practice, for a given MVPN, a PE would be a client of just 2 RRs (for redundancy, an RR cluster would typically have 2 RRs). Therefore, in practice the message would need to be processed by at most 4 RRs (2 RRs if both the downstream PE and the upstream PE are the clients of the same RRs). Thus, the number of RRs that have to process a given message is at most 4. Since RRs in different RR clusters have a full Internal BGP (iBGP) mesh among themselves, each RR in the RR cluster that contains the upstream PE would receive the message from each of the RRs in the RR cluster that contains the downstream PE. Given 2 RRs per cluster, the total number of messages processed by all the RRs is 6.
实际上，对于给定的MVPN，PE将是只有2个RRs的客户机（对于冗余，一个RR集群通常有2个RRs）。因此，在实践中，消息最多需要4个RRs处理（如果下游PE和上游PE都是相同RRs的客户端，则需要2个RRs）。因此，必须处理给定消息的RRs的数量最多为4。由于不同RR集群中的RRs之间具有完整的内部BGP（iBGP）网格，因此包含上游PE的RR集群中的每个RR将从包含下游PE的RR集群中的每个RRs接收消息。如果每个集群有2个RRs，则所有RRs处理的消息总数为6。
Additionally, as soon as there is a receiver-connected PE in each RR cluster, the number of RRs processing a C-multicast route tends quickly toward 2 (taking into account that a PE peering to RRs will be made redundant).
此外，只要每个RR集群中有一个与接收器连接的PE，处理C-多播路由的RR的数量就会迅速趋向于2（考虑到对等到RRs的PE将成为冗余）。
+------------+----------+--------------+-----------+----------------+
| | upstream | other PEs | RRs (#RR) | total across |
| | PE (1) | (total | | all equipments |
| | | across | | |
| | | (#mvpn_PE-1) | | |
| | | PEs) | | |
+------------+----------+--------------+-----------+----------------+
| first PE | 2 m.e | 2 m.e | 6 m.e | 10 m.e |
| joins | | | | |
+------------+----------+--------------+-----------+----------------+
| for *each* | between | 2 m.e | (at most) | (at most) 10 |
| additional | 0 and 2 | | 6 m.e | m.e tending |
| PE joining | m.e | | tending | toward 4 m.e |
| | | | toward 2 | |
| | | | m.e | |
+------------+----------+--------------+-----------+----------------+
| baseline | 0 | 0 | 0 | 0 |
| processing | | | | |
| over a | | | | |
| period T | | | | |
+------------+----------+--------------+-----------+----------------+
| for *each* | between | 2 m.e | (at most) | (at most) 10 |
| PE leaving | 0 and 2 | | 6 m.e | m.e tending |
| | m.e | | tending | toward 4 m.e |
| | | | toward 2 | |
+------------+----------+--------------+-----------+----------------+
| the last | 2 m.e | 2 m.e | 6 m.e | 10 m.e |
| PE leaves | | | | |
+------------+----------+--------------+-----------+----------------+
| total for | at most | #R_PE x 4 | (at most) | at most 10 x |
| #R_PE PEs | 2 x #RRs | m.e | 6 x #R_PE | #R_PE + 2 x |
| | m.e (see | | m.e | #RRs m.e |
| | note | | (tending | (tending |
| | below) | | toward 2 | toward 6 x |
| | | | x #R_PE | #R_PE + #RRs |
| | | | m.e) | m.e ) |
+------------+----------+--------------+-----------+----------------+
| total | 4 s.e | 2 x #R_PE | approx. 2 | approx. 4 |
| state | | s.e | #R_PE + | #R_PE + #RRx |
| maintained | | | #RR x | #clusters + 4 |
| | | | #clusters | m.e |
| | | | s.e | |
+------------+----------+--------------+-----------+----------------+
+------------+----------+--------------+-----------+----------------+
| | upstream | other PEs | RRs (#RR) | total across |
| | PE (1) | (total | | all equipments |
| | | across | | |
| | | (#mvpn_PE-1) | | |
| | | PEs) | | |
+------------+----------+--------------+-----------+----------------+
| first PE | 2 m.e | 2 m.e | 6 m.e | 10 m.e |
| joins | | | | |
+------------+----------+--------------+-----------+----------------+
| for *each* | between | 2 m.e | (at most) | (at most) 10 |
| additional | 0 and 2 | | 6 m.e | m.e tending |
| PE joining | m.e | | tending | toward 4 m.e |
| | | | toward 2 | |
| | | | m.e | |
+------------+----------+--------------+-----------+----------------+
| baseline | 0 | 0 | 0 | 0 |
| processing | | | | |
| over a | | | | |
| period T | | | | |
+------------+----------+--------------+-----------+----------------+
| for *each* | between | 2 m.e | (at most) | (at most) 10 |
| PE leaving | 0 and 2 | | 6 m.e | m.e tending |
| | m.e | | tending | toward 4 m.e |
| | | | toward 2 | |
+------------+----------+--------------+-----------+----------------+
| the last | 2 m.e | 2 m.e | 6 m.e | 10 m.e |
| PE leaves | | | | |
+------------+----------+--------------+-----------+----------------+
| total for | at most | #R_PE x 4 | (at most) | at most 10 x |
| #R_PE PEs | 2 x #RRs | m.e | 6 x #R_PE | #R_PE + 2 x |
| | m.e (see | | m.e | #RRs m.e |
| | note | | (tending | (tending |
| | below) | | toward 2 | toward 6 x |
| | | | x #R_PE | #R_PE + #RRs |
| | | | m.e) | m.e ) |
+------------+----------+--------------+-----------+----------------+
| total | 4 s.e | 2 x #R_PE | approx. 2 | approx. 4 |
| state | | s.e | #R_PE + | #R_PE + #RRx |
| maintained | | | #RR x | #clusters + 4 |
| | | | #clusters | m.e |
| | | | s.e | |
+------------+----------+--------------+-----------+----------------+
Message Processing and State Maintenance - BGP-Based Procedures
消息处理和状态维护-基于BGP的过程
Note on the total of m.e on the upstream PE:
注：上游PE上的m.e总计：
o There are as many "message.equipment"s on the upstream PE as the number of times the RRs of the cluster of the upstream PE need to re-advertise the C-multicast (C-S,C-G) route; such a re-advertisement is not useful for the upstream PE, because the behavior of the upstream PE for a said (VPN associated to the Route Target, C-S,C-G) will not depend on the precise attributes carried by the route (other than the Route Target, of course) but will happen in some cases due to how BGP processes these routes. Indeed, a BGP peer will possibly re-advertise a route when its current best path changes for the said NLRI if the set of attributes to advertise also changes.
o 上游PE上的“message.equipment”数量与上游PE集群的RRs需要重新公布C多播（C-s，C-G）路由的次数相同；这样的重新公布对于上游PE不有用，因为所述VPN（与路由目标相关联的VPN，C-S，C-G）的上游PE的行为将不取决于路由所携带的精确属性（当然，路由目标除外），而是在某些情况下由于BGP如何处理这些路由而发生。实际上，如果要公布的属性集也发生变化，则当所述NLRI的当前最佳路径发生变化时，BGP对等方可能会重新公布路由。
o Let's look at the different relevant attributes and when they can influence when a re-advertisement of a C-multicast route will happen:
o 让我们看看不同的相关属性以及它们何时会影响C多播路由的重新公布：
* next-hop and originator-id: A new PE joining will not mechanically result in a need to re-advertise a C-multicast route because as the RR aggregates C-multicast routes with the same NLRI received from PEs in its own cluster (Section 11.4 of [RFC6514]), the RR rewrites the values of these attributes; however, the advertisements made by different RRs peering with the RRs in the cluster of the upstream PE may lead to updates of the value of these attributes.
* 下一跳和发起者id：新PE加入不会机械地导致需要重新公布C-多播路由，因为RR将C-多播路由与从其自己集群中的PE接收到的相同NLRI聚合（RFC6514的第11.4节），RR重写这些属性的值；然而，由与上游PE的集群中的RRs对等的不同RRs所做的广告可能导致这些属性的值的更新。
* cluster-list: The value of this attribute only varies between clusters, changes of the value of this attributes does not "follow" PE advertisements, and only advertisements made by different RRs may possibly lead to updates of the value of this attribute.
* 群集列表：此属性的值仅在群集之间变化，此属性值的变化不会“跟随”PE播发，并且只有不同RRs发出的播发可能会导致此属性值的更新。
* local-pref: The value of this attribute is determined locally; this is true both for the routes advertised by each PE (which could all be configured to use the same value) and for a route that results from the aggregation by an RR of the route with the same NLRI advertised by the PEs of his cluster (the RRs could also be configured to use a local pref independent of the local_pref of the routes advertised to him). Thus, this attribute can be considered to result in a need to re-advertise a C-multicast route.
* local pref：该属性的值在本地确定；对于每个PE播发的路由（可以全部配置为使用相同的值），以及通过路由的RR与其集群的PE播发的相同NLRI进行聚合而产生的路由，都是如此（RRs也可以配置为使用本地pref，独立于向其通告的路由的本地pref）。因此，可以认为此属性导致需要重新通告C多播路由。
* Other BGP attributes do not have a particular reason to be set for C-multicast routes in intra-AS, and if they were, an RR (or, for attributes relevant for inter-AS, an ASBR) would also overwrite these values when aggregating these routes.
* 其他BGP属性没有为内部AS中的C多播路由设置的特定原因，如果是，RR（或者，对于与内部AS相关的属性，ASBR）也会在聚合这些路由时覆盖这些值。
o Given the above, for a said C-multicast Source Tree Join (S,G) NLRI, what may force an RR to re-advertise the route with different attributes to the upstream PE would be the case of an RR of another cluster advertising a route better than its current best route, because of the values of attributes specific to that RR (next-hop, originator-id, cluster-list) but not because of anything specific to the PEs behind that RR. If we consider our (#R_PE -1) joining a said (C-S,C-G), one after the other after the first PE joining, some of these events may thus lead to a re-advertisement to the upstream PE, but the number of times this can happen is at worse the number of RRs in clusters having receivers (plus one because of the possible advertisement of the same route by a PE of the local cluster).
o 鉴于上述情况，对于所述C-多播源树加入（S，G）NLRI，由于特定于该RR的属性值，可能迫使RR向上游PE重新通告具有不同属性的路由的情况将是另一集群的RR通告比其当前最佳路由更好的路由的情况（下一跳，发起者ID，簇列表），但不是因为RR后面的PES所特有的。如果我们考虑我们（αRSPE - 1）加入一个所说的（C-S，C-G），在第一个PE加入之后，一个接一个地，这些事件中的一些可能因此导致向上游PE重新播发，但是这可能发生的次数更糟糕，是具有接收器的集群中的rr的数量（加上一个，因为本地集群的PE可能播发相同路由）。
o Given that we look at scalability with an increased number of PEs in this section, we need to consider the possibility that all clusters may have a client PE with a receiver. We also need to consider that the two RRs of the cluster of the upstream PE may need to re-advertise the route. With this in mind, we know that 2x#RRs is an upper bound to the number of updates made by RRs to the upstream PE, for the considered C-multicast route.
o 考虑到本节中PES数量的增加，我们需要考虑所有集群可能有客户端PE和接收器的可能性。我们还需要考虑，上游PE的集群的两个RRS可能需要重新路由该路由。考虑到这一点，我们知道2x#RRs是RRs对上游PE所做更新数量的上限，用于考虑的C-多播路由。
This section concludes the previous section by considering the orders of magnitude when the number of PEs in a VPN increases.
本节通过考虑VPN中PE数量增加时的数量级来结束上一节。
+------------+--------------------------------+---------------------+
| | PIM LAN Procedures | BGP-based |
+------------+--------------------------------+---------------------+
| first PE | O(#mvpn_PE) | O(1) |
| joins (in | | |
| m.e) | | |
+------------+--------------------------------+---------------------+
| for *each* | O(#mvpn_PE) | O(1) |
| additional | | |
| PE joining | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| baseline | (T/T_PIM_r) x O(#mvpn_PE) | 0 |
| processing | | |
| over a | | |
| period T | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| for *each* | O(#mvpn_PE) | O(1) |
| PE leaving | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| the last | O(#mvpn_PE) | O(1) |
| PE leaves | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| total for | O(#mvpn_PE x #R_PE) + | O(#R_PE) |
| #R_PE PEs | O(#mvpn_PE x T/T_PIM_r) | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| states (in | O(#R_PE) | O(#R_PE) |
| s.e) | | |
| notes | (processing and state | (processing and |
| | maintenance are essentially | state maintenance |
| | done by, and spread amongst, | is essentially done |
| | the PEs of the MVPN; | by, and spread |
| | non-upstream PEs have | amongst, the RRs) |
| | processing to do) | |
+------------+--------------------------------+---------------------+
+------------+--------------------------------+---------------------+
| | PIM LAN Procedures | BGP-based |
+------------+--------------------------------+---------------------+
| first PE | O(#mvpn_PE) | O(1) |
| joins (in | | |
| m.e) | | |
+------------+--------------------------------+---------------------+
| for *each* | O(#mvpn_PE) | O(1) |
| additional | | |
| PE joining | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| baseline | (T/T_PIM_r) x O(#mvpn_PE) | 0 |
| processing | | |
| over a | | |
| period T | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| for *each* | O(#mvpn_PE) | O(1) |
| PE leaving | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| the last | O(#mvpn_PE) | O(1) |
| PE leaves | | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| total for | O(#mvpn_PE x #R_PE) + | O(#R_PE) |
| #R_PE PEs | O(#mvpn_PE x T/T_PIM_r) | |
| (in m.e) | | |
+------------+--------------------------------+---------------------+
| states (in | O(#R_PE) | O(#R_PE) |
| s.e) | | |
| notes | (processing and state | (processing and |
| | maintenance are essentially | state maintenance |
| | done by, and spread amongst, | is essentially done |
| | the PEs of the MVPN; | by, and spread |
| | non-upstream PEs have | amongst, the RRs) |
| | processing to do) | |
+------------+--------------------------------+---------------------+
Comparison of Orders of Magnitude for Message Processing and State Maintenance (Totals across All Equipments)
信息处理和状态维护的数量级比较（所有设备的总数）
The conclusions that can be drawn from the above are as follows:
从上面可以得出如下结论：
o In the PIM-based approach, any message will be processed by all PEs, including those that are neither upstream nor downstream for the message; as a result, the total number of messages to process is in O(#mvpn_PE x #R_PE), i.e., O(#mvpn_PE ^ 2) if the proportion of receiver PEs is considered constant when the number of PEs increases. The refreshes of Join messages introduce a linear factor not changing the order of magnitude, but which can be significant for long-lived streams;
o 在基于PIM的方法中，任何消息都将由所有PE处理，包括那些既不是消息上游也不是消息下游的PE；因此，如果当PE数量增加时，接收器PE的比例被认为是恒定的，则要处理的消息总数为O（#mvpn_PE x#R#PE），即O（#mvpn_PE^2）。连接消息的刷新引入了一个线性因子，该因子不会改变数量级，但对于长寿命流来说可能非常重要；
o The BGP-based approach requires an amount of message processing in O(#R_PE) lower than the PIM-based approach. The amount is independent of the duration of streams.
o 基于BGP的方法需要的消息处理量比基于PIM的方法低。数量与流的持续时间无关。
o State maintenance is of the same order of magnitude for all approaches: O(#R_PE), but the repartition is different:
o 所有方法的状态维护都具有相同的数量级：O（#R#PE），但重新划分不同：
* The PIM-based approach fully spreads, and minimizes, the amount of state (one state per PE).
* 基于PIM的方法完全扩展并最小化状态量（每个PE一个状态）。
* The BGP-based procedures spread all the state on the set of route reflectors.
* 基于BGP的程序将所有状态分布在一组路由反射器上。
The conclusions in Appendix A.1.1 are reused in this section, for the parts that are common to the setup and maintenance of states related to a source tree or a shared tree.
附录A.1.1中的结论在本节中重复使用，用于与源树或共享树相关的状态设置和维护通用的部件。
When PIM-SM is used in a VPN and an ASM multicast group is joined by some PEs (#R_PEs) with some sources sending toward this multicast group address, we can note the following:
当在VPN中使用PIM-SM，并且ASM多播组由一些PE（#R#PEs）加入，并且一些源向该多播组地址发送时，我们可以注意到以下几点：
PEs will generally have to maintain one shared tree, plus one source tree for each source sending toward G; each tree resulting in an amount of processing and state maintenance similar to what is described in the scenario in Appendix A.1.1, with the same differences in order of magnitudes between the different approaches when the number of PEs is high.
PEs通常必须维护一个共享树，每个向G发送的源加上一个源树；每个树产生的处理量和状态维护量与附录A.1.1中描述的情况类似，当PEs数量较多时，不同方法之间的大小顺序存在相同差异。
An exception to this is when, for a said group in a VPN among the PIM instances in the customer routers and VRFs, none would switch to the shortest path tree (SPT) (SwitchToSptDesired always false): in that case, the processing and state maintenance load is the one required for maintenance of the shared tree only. It has to be noted that this scenario is dependent on customer policy. To compare the resulting load in that case, between PIM-based approaches and the
例外情况是，对于客户路由器和VRF中的PIM实例中的VPN中的所述组，没有一个将切换到最短路径树（SPT）（SwitchToSptDesired总是false）：在这种情况下，处理和状态维护负载仅是维护共享树所需的负载。必须注意的是，这种情况取决于客户政策。在这种情况下，比较基于PIM的方法和
BGP-based approach configured to use inter-site shared trees, the scenario in Appendix A.1.1 can be used with #R_PEs joining a (C-*, C-G) ASM group instead of an SSM group, and the same differences in order of magnitude remain true. In the case of the BGP-based approach used without inter-site shared trees, we must take into account the load resulting from the fact that to build the C-PIM shared tree, each PE has to join the source tree to each source; using the notations of Appendix A.1.1, this adds an amount of load (total load across all equipments) that is proportional to #R_PEs and the number of sources. The order of magnitude with an increasing number of PEs is thus unchanged, and the differences in order of magnitude also remain the same.
基于BGP的方法配置为使用站点间共享树，附录A.1.1中的场景可用于#R#PE加入（C-*，C-G）ASM组而不是SSM组，并且在数量级上的相同差异仍然存在。在没有站点间共享树的情况下使用基于BGP的方法的情况下，我们必须考虑由于要构建C-PIM共享树，每个PE必须将源树连接到每个源而产生的负载；使用附录A.1.1中的符号，这增加了与#R#PEs和电源数量成比例的负载量（所有设备的总负载）。因此，随着PEs数量的增加，数量级保持不变，数量级差异也保持不变。
Additionally, to the maintenance of trees, PEs have to ensure some processing and state maintenance related to individual sources sending to a multicast group; the related procedures and behaviors largely may differ depending on which C-multicast routing protocol is used, how it is configured, how the multicast source discovery mechanism is used in the customer VPN, and which SwitchToSptDesired policy is used. However, the following can be observed:
此外，对于树的维护，PEs必须确保与发送到多播组的单个源相关的一些处理和状态维护；根据使用的C-多播路由协议、其配置方式、多播源发现机制在客户VPN中的使用方式以及使用的SwitchToSptDesired策略，相关过程和行为可能会有很大不同。但是，可以观察到以下情况：
o When BGP-based C-multicast routing is used:
o 使用基于BGP的C多播路由时：
* Each PE will possibly have to process and maintain a BGP Source-Active auto-discovery route for (some or all) sources of an ASM group. The number of Source-Active auto-discovery routes will typically be one but may be related to the number of upstream PEs in the following cases: when inter-site shared trees are used and simultaneously more than one PE is used as the upstream PE for SPT (C-S,C-G) trees and when inter-site shared trees are used and there are multiple PEs that are possible upstream for this (S,G).
* 每个PE可能必须处理和维护ASM组（部分或全部）源的BGP源活动自动发现路由。源活动自动发现路由的数量通常为一条，但在以下情况下可能与上游PE的数量有关：当使用站点间共享树且同时使用多个PE作为SPT（C-S、C-G）的上游PE时树，并且当使用站点间共享树时，上游可能存在多个PE（S、G）。
* This results in message processing and state maintenance (total across all the equipments) linearly dependent on the number of PEs in the VPN (#mvpn_PE) for each source, independent of the number of PEs joined to the group.
* 这导致消息处理和状态维护（所有设备的总数）与每个源的VPN中的PE数量（#mvpn_PE）呈线性关系，与加入组的PE数量无关。
* Depending on whether or not inter-site shared trees are used, on the SwitchToSptDesired policy in the PIM instances in the customer routers and VRFs, and on the relative locations of sources and RPs, this will happen for all (S,G) of an ASM group or only for some of them and will be done in parallel to the maintenance of shared and/or source trees or at the first join of a PE on a source tree.
* 根据是否使用站点间共享树、客户路由器和VRF中PIM实例中的SwitchToSptDesired策略以及源和RPs的相对位置，所有（S、G）都会发生这种情况对ASM组进行维护或仅对其中一些组进行维护，并将与维护共享和/或源树并行进行，或在PE首次加入源树时进行。
o When PIM-based C-multicast routing is used, depending on the SwitchToSptDesired policy in the PIM instances in the customer routers and VRFs and depending on the relative locations of sources and RPs, there are:
o 使用基于PIM的C-多播路由时，根据客户路由器和VRF中PIM实例中的SwitchToSptDesired策略以及源和RPs的相对位置，有：
* Possible control plane state transitions triggered by the reception of (S,G) packets. Such events would induce processing on all PEs joined to G.
* 接收（S，G）数据包触发的可能控制平面状态转换。这类事件将导致所有加入G的PE的处理。
* Possible PIM Assert messages specific to (S,G). This would induce a message processing on each PE of the VPN for each PIM Assert message.
* 特定于（S，G）的可能PIM断言消息。这将在VPN的每个PE上对每个PIM断言消息进行消息处理。
Given the above, the additional processing that may happen for each individual source sending to the group, beyond the maintenance of source and shared trees, does not change the order of magnitude identified above.
鉴于上述情况，除了源和共享树的维护之外，发送到组的每个单独源可能发生的附加处理不会改变上述确定的数量级。
The quantification of message processing in Appendix A.1.1 is done based on a use case where each PE with receivers has joined and left once. Drawing scalability-related conclusions for other patterns of changes of the set of receiver-connected PEs can be done by considering the cost of each approach for "a new PE joining" and "a PE leaving".
附录A.1.1中的消息处理量化是基于一个用例完成的，在该用例中，每个带有接收器的PE连接和离开一次。通过考虑“新PE加入”和“PE离开”的每种方法的成本，可以得出与接收器连接的PE组的其他变化模式的可伸缩性相关的结论。
For the "PIM LAN Procedure" approach, in the case of a single SSM or SPT tree, the total amount of message processing across all nodes depends linearly on the number of PEs in the VPN when a PE joins such a tree.
对于“PIM LAN过程”方法，在单个SSM或SPT树的情况下，当PE加入此类树时，所有节点上的消息处理总量线性取决于VPN中PE的数量。
For the "BGP-based" approach:
对于“基于BGP”的方法：
o In the case of a single SSM tree, the total amount of message processing across all nodes is independent of the number of PEs, for "a new PE" joining and "a PE leaving"; it also depends on how route reflectors are meshed, but not on linear dependency.
o 对于单个SSM树，“新PE”加入和“PE离开”，所有节点的消息处理总量与PE数量无关；它还取决于路线反射器的网格划分方式，但不取决于线性相关性。
o In the case of an SPT tree for an ASM group, BGP has additional processing due to possible Source-Active auto-discovery routes:
o 对于ASM组的SPT树，由于可能的源活动自动发现路由，BGP具有额外的处理：
* When BGP-based C-multicast routing is used with inter-site shared trees, for the first PE joining (and the last PE leaving) a said SPT, the processing of the corresponding Source-Active auto-discovery routes results in a processing cost linearly dependent on the number of PEs in the VPN. For
* 当基于BGP的C-多播路由与站点间共享树一起使用时，对于第一个PE加入（和最后一个PE离开）所述SPT，对相应的源活动自动发现路由的处理导致处理成本线性依赖于VPN中PE的数量。对于
subsequent PEs joining (and non-last PE leaving), there is no processing due to advertisement or withdrawal of Source-Active auto-discovery routes.
后续PE加入（和非最后一个PE离开），由于源活动自动发现路由的播发或撤回，没有处理。
* When BGP-based C-multicast routing is used without inter-site shared trees, the processing of Source-Active auto-discovery routes for an (S,G) happens independently of PEs joining and leaving the SPT for (S,G).
* 当在没有站点间共享树的情况下使用基于BGP的C多播路由时，an（S，G）的源活动自动发现路由的处理独立于PE加入和离开（S，G）的SPT。
In the case of a new PE having to join a shared tree for an ASM group G, we see the following:
在新PE必须加入ASM组G的共享树的情况下，我们看到以下内容：
o The processing due to the PE joining the shared tree itself is the same as the processing required to set up an SSM tree, as described before (note that this does not happen when BGP-based C-multicast routing is used without inter-site shared trees).
o 由于PE加入共享树本身而导致的处理与建立SSM树所需的处理相同，如前所述（注意，在没有站点间共享树的情况下使用基于BGP的C多播路由时，不会发生这种情况）。
o For each source for which the PE joins the SPT, the resulting processing cost is the same as one SPT tree, as described before.
o 对于PE加入SPT的每个源，产生的处理成本与一个SPT树相同，如前所述。
* The conditions under which a PE will join the SPT for a said (C-S,C-G) are the same between the BGP-based with inter-site shared tree approach and the PIM-based approach, and depend solely on the SwitchToSptDesired policy in the PIM instances in the customer routers in the sites connected to the PE and/or in the VRF.
* PE将为所述（C-S，C-G）加入SPT的条件在基于BGP的站点间共享树方法和基于PIM的方法之间是相同的，并且仅取决于连接到PE和/或VRF的站点中的客户路由器中的PIM实例中的SwitchToSptDesired策略。
* The conditions under which a PE will join the SPT for a said (C-S,C-G) differ between the BGP-based without inter-site shared trees approach and the PIM-based approach.
* PE为上述（C-S，C-G）加入SPT的条件在基于BGP的无站点间共享树方法和基于PIM的方法之间有所不同。
* The SPT for a said (S,G) can be joined by the PE in the following cases:
* 在以下情况下，所述（S，G）的SPT可由PE连接：
+ as soon as one router, or the VPN VRF on the PE, has SwitchToSptDesired(S,G) being true
+ 只要一个路由器或PE上的VPN VRF的SwitchToSptDesired（S，G）为真
+ when BGP-based routing is used and configured to not use inter-site shared trees
+ 使用基于BGP的路由并将其配置为不使用站点间共享树时
* Said differently, the only case where the PE will not join the SPT for (S,G) is when all routers in the sites of the VPN connected to the PE, or the VPN VRF itself, will never have SwitchToSptDesired(S,G) being true, with the additional condition that inter-site shared trees are used when BGP-based C-multicast routing is used.
* 换言之，PE不会加入（S，G）的SPT的唯一情况是，连接到PE的VPN站点中的所有路由器，或VPN VRF本身，永远不会使SwitchToSptDesired（S，G）为真，并且在使用基于BGP的C多播路由时使用站点间共享树。
Thus, when one PE joins a group G to which n sources are sending traffic, we note the following with regards to the dependency of the cost (in total amount of processing across all equipments) to the number of PEs:
因此，当一个PE加入n个源向其发送流量的G组时，我们注意到以下关于成本（所有设备的处理总量）与PE数量的依赖关系：
o In the general case (where any router in the site of the VPN connected to the PE, or the VRF itself, may have SwitchToSptDesired(S,G) being true):
o 在一般情况下（连接到PE的VPN站点中的任何路由器或VRF本身可能具有SwitchToSptDesired（S，G）为真）：
* For the "PIM LAN Procedure" approach, the cost is linearly dependent on the number of PEs in the VPN and linearly dependent on the number of sources.
* 对于“PIM LAN过程”方法，成本与VPN中PE的数量成线性关系，与源的数量成线性关系。
* For the "BGP-based" approach, the cost is linearly dependent on the number of sources, and, in the sub-case of the BGP-based approach used with inter-site shared trees, is also dependent on the number of PEs in the VPN only if the PE is the first to join the group or the SPT for some source sending to the group.
* 对于“基于BGP”的方法，成本线性依赖于源的数量，并且，在基于BGP的方法与站点间共享树一起使用的子情况下，仅当PE是第一个加入组的PE或发送到组的某些源的SPT时，成本也依赖于VPN中的PE数量。
o Else, under the assumption that routers in the sites of the VPN connected to the PE, and the VPN VRF itself, will never have the policy function SwitchToSptDesired(S,G) being possibly true, then:
o 否则，假设连接到PE的VPN站点中的路由器以及VPN VRF本身永远不会具有可能为真的策略功能SwitchToSptDesired（S，G），则：
* In the case of the PIM-based approach, the cost is linearly dependent on the number of PEs in the VPN, and there is no dependency on the number of sources.
* 在基于PIM的方法的情况下，成本与VPN中PE的数量成线性关系，与源的数量无关。
* In the case of the BGP-based approach with inter-site shared trees, the cost is linearly dependent on the number of RRs, and there is no dependency on the number of sources.
* 对于基于BGP的站点间共享树方法，成本与RRs的数量成线性关系，与源的数量无关。
* In the case of the BGP-based approach without inter-site shared trees, the cost is linearly dependent on the number of RRs and on the number of sources.
* 在没有站点间共享树的基于BGP的方法的情况下，成本与RRs的数量和源的数量成线性关系。
Hence, with the PIM-based approach, the overall cost across all equipments of any PE joining an ASM group G is always dependent on the number of PEs (same for a PE that leaves), while the BGP-based approach has a cost independent of the number of PEs. An exception is the first PE joining the ASM group for the BGP-based approach used without inter-site shared trees; in that case, there is a dependency with the number of PEs.
因此，对于基于PIM的方法，加入ASM组G的任何PE的所有设备的总成本始终取决于PE的数量（对于离开的PE相同），而基于BGP的方法的成本与PE的数量无关。例外情况是，第一个PE加入ASM组，使用基于BGP的方法，但不使用站点间共享树；在这种情况下，存在与PE数量的依赖关系。
On the dependency with the number of sources, without making any assumption on the SwitchToSptDesired policy on PIM routers and VRFs of a VPN, we see that a PE joining an ASM group may induce a processing cost linearly dependent on the number of sources. Apart from this general case, under the condition where the
关于源数量的依赖性，在不对VPN的PIM路由器和VRF上的SwitchToSptDesired策略进行任何假设的情况下，我们发现PE加入ASM组可能会导致处理成本与源数量成线性关系。除此一般情况外，在
SwitchToSptDesired is always false on all PIM routers and VRFs of the VPN, then with the PIM-based approach, and with the BGP-based approach used with inter-site shared trees, the cost in amount of messages processed will be independent of the number of sources (it has to be noted that this condition depends on customer policy).
SwitchToSptDesired在VPN的所有PIM路由器和VRF上始终为false，然后使用基于PIM的方法，并使用基于BGP的方法与站点间共享树一起使用，处理的消息量成本将独立于源的数量（必须注意，此情况取决于客户策略）。
(The following point was fixed in a draft version of the document that became [RFC6513] and is here for reference only.)
（以下一点在成为[RFC6513]的文件草稿中已确定，此处仅供参考。）
In early versions of the document that became [RFC6513], two approaches were proposed for how a source PE can decide when to start transmitting customer multicast traffic on a S-PMSI:
在成为[RFC6513]的早期版本中，针对源PE如何决定何时开始在S-PMSI上传输客户多播流量，提出了两种方法：
1. The source PE sends multicast packets for the (C-S,C-G) on both the I-PMSI P-multicast tree and the S-PMSI P-multicast tree simultaneously for a pre-configured period of time, letting the receiver PEs select the new tree for reception before switching to only the S-PMSI.
1. 源PE在预先配置的时间段内同时在I-PMSI P-多播树和S-PMSI P-多播树上为（C-S，C-G）发送多播分组，让接收方PE在切换到仅S-PMSI之前选择新树进行接收。
2. The source PE waits for a pre-configured period of time after advertising the (C-S,C-G) entry bound to the S-PMSI before fully switching the traffic onto the S-PMSI-bound P-multicast tree.
2. 源PE在播发绑定到S-PMSI的（C-S，C-G）条目之后等待一段预先配置的时间，然后将流量完全切换到绑定到S-PMSI的P多播树上。
The first alternative had essentially two drawbacks:
第一种选择基本上有两个缺点：
o (C-S,C-G) traffic is sent twice for some period of time, which would appear to be at odds with the motivation for switching to an S-PMSI in order to optimize the bandwidth used by the multicast tree for that stream.
o （C-S，C-G）在一段时间内发送两次通信量，这似乎与切换到S-PMSI以优化多播树对该流使用的带宽的动机不一致。
o It is unlikely that the switchover can occur without packet loss or duplication if the transit delays of the I-PMSI P-multicast tree and the S-PMSI P-multicast tree differ.
o 如果I-PMSI P-多播树和S-PMSI P-多播树的传输延迟不同，则不可能在没有分组丢失或重复的情况下发生切换。
By contrast, the second alternative has none of these drawbacks and satisfies the requirement in Section 5.1.3 of [RFC4834], which states that "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". The second alternative also happens to be the one used in existing deployments.
相比之下，第二个备选方案没有这些缺点，并且满足[RFC4834]第5.1.3节的要求，该节规定“多播VPN解决方案应尽可能确保客户端多播流量数据包不会丢失或重复，即使在提供商网络上承载客户端多播数据流的方式发生变化时也是如此。”第二种替代方案也恰好是现有部署中使用的方案。
Consistent with this analysis, only the second alternative is discussed in [RFC6513].
与此分析一致，[RFC6513]中只讨论了第二种备选方案。
Authors' Addresses
作者地址
Thomas Morin (editor) France Telecom - Orange 2 rue Pierre Marzin Lannion 22307 France EMail: thomas.morin@orange.com
托马斯·莫林（编辑）法国电信-皮埃尔·马津·拉尼翁街橙色2号22307法国电子邮件：托马斯。morin@orange.com
Ben Niven-Jenkins (editor) BT 208 Callisto House, Adastral Park Ipswich, Suffolk IP5 3RE UK EMail: ben@niven-jenkins.co.uk
Ben Niven Jenkins（编辑）英国电信208号卡利斯托大厦，萨福克州伊普斯维奇阿达斯特拉尔公园IP5 3RE英国电子邮件：ben@niven-jenkins.co.uk
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: y.kamite@ntt.com
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura，Minato ku东京108-8118日本电子邮件：y。kamite@ntt.com
Raymond Zhang Alcatel-Lucent 777 Middlefield Rd. Mountain View, CA 94043 USA EMail: raymond.zhang@alcatel-lucent.com
美国加利福尼亚州山景城米德菲尔德路777号阿尔卡特朗讯公司，邮编94043电子邮件：Raymond。zhang@alcatel-朗讯网
Nicolai Leymann Deutsche Telekom Winterfeldtstrasse 21-27 10781 Berlin Germany EMail: n.leymann@telekom.de
Nicolai Leymann德国电信Winterfeldtstrasse 21-27 10781柏林德国电子邮件：n。leymann@telekom.de
Nabil Bitar Verizon 60 Sylvan Road Waltham, MA 02451 USA EMail: nabil.n.bitar@verizon.com
Nabil Bitar Verizon 60 Sylvan Road Waltham，马萨诸塞州02451美国电子邮件：Nabil.n。bitar@verizon.com