Internet Engineering Task Force (IETF) E. Rosen, Ed.
Request for Comments: 6513 Cisco Systems, Inc.
Category: Standards Track R. Aggarwal, Ed.
ISSN: 2070-1721 Juniper Networks
February 2012
Internet Engineering Task Force (IETF) E. Rosen, Ed.
Request for Comments: 6513 Cisco Systems, Inc.
Category: Standards Track R. Aggarwal, Ed.
ISSN: 2070-1721 Juniper Networks
February 2012
Multicast in MPLS/BGP IP VPNs
MPLS/bgpip-vpn中的组播
Abstract
摘要
In order for IP multicast traffic within a BGP/MPLS IP VPN (Virtual Private Network) to travel from one VPN site to another, special protocols and procedures must be implemented by the VPN Service Provider. These protocols and procedures are specified in this document.
为了使BGP/MPLS IP VPN（虚拟专用网络）内的IP多播通信从一个VPN站点传输到另一个VPN站点，VPN服务提供商必须实施特殊协议和程序。本文件规定了这些协议和程序。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6513.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6513.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................5
2. Overview .......................................................5
2.1. Optimality vs. Scalability .................................5
2.1.1. Multicast Distribution Trees ........................7
2.1.2. Ingress Replication through Unicast Tunnels .........8
2.2. Multicast Routing Adjacencies ..............................8
2.3. MVPN Definition ............................................9
2.4. Auto-Discovery ............................................10
2.5. PE-PE Multicast Routing Information .......................11
2.6. PE-PE Multicast Data Transmission .........................11
2.7. Inter-AS MVPNs ............................................12
2.8. Optionally Eliminating Shared Tree State ..................13
3. Concepts and Framework .........................................13
3.1. PE-CE Multicast Routing ...................................13
3.2. P-Multicast Service Interfaces (PMSIs) ....................14
3.2.1. Inclusive and Selective PMSIs ......................15
3.2.2. P-Tunnels Instantiating PMSIs ......................16
3.3. Use of PMSIs for Carrying Multicast Data ..................18
3.4. PE-PE Transmission of C-Multicast Routing .................20
3.4.1. PIM Peering ........................................20
3.4.1.1. Full per-MVPN PIM Peering across
an MI-PMSI ................................20
3.4.1.2. Lightweight PIM Peering across an MI-PMSI .20
3.4.1.3. Unicasting of PIM C-Join/Prune Messages ...21
3.4.2. Using BGP to Carry C-Multicast Routing .............22
4. BGP-Based Auto-Discovery of MVPN Membership ....................22
5. PE-PE Transmission of C-Multicast Routing ......................25
5.1. Selecting the Upstream Multicast Hop (UMH) ................25
5.1.1. Eligible Routes for UMH Selection ..................26
5.1.2. Information Carried by Eligible UMH Routes .........26
5.1.3. Selecting the Upstream PE ..........................27
5.1.4. Selecting the Upstream Multicast Hop ...............29
5.2. Details of Per-MVPN Full PIM Peering over MI-PMSI .........29
5.2.1. PIM C-Instance Control Packets .....................29
1. Introduction ....................................................5
2. Overview .......................................................5
2.1. Optimality vs. Scalability .................................5
2.1.1. Multicast Distribution Trees ........................7
2.1.2. Ingress Replication through Unicast Tunnels .........8
2.2. Multicast Routing Adjacencies ..............................8
2.3. MVPN Definition ............................................9
2.4. Auto-Discovery ............................................10
2.5. PE-PE Multicast Routing Information .......................11
2.6. PE-PE Multicast Data Transmission .........................11
2.7. Inter-AS MVPNs ............................................12
2.8. Optionally Eliminating Shared Tree State ..................13
3. Concepts and Framework .........................................13
3.1. PE-CE Multicast Routing ...................................13
3.2. P-Multicast Service Interfaces (PMSIs) ....................14
3.2.1. Inclusive and Selective PMSIs ......................15
3.2.2. P-Tunnels Instantiating PMSIs ......................16
3.3. Use of PMSIs for Carrying Multicast Data ..................18
3.4. PE-PE Transmission of C-Multicast Routing .................20
3.4.1. PIM Peering ........................................20
3.4.1.1. Full per-MVPN PIM Peering across
an MI-PMSI ................................20
3.4.1.2. Lightweight PIM Peering across an MI-PMSI .20
3.4.1.3. Unicasting of PIM C-Join/Prune Messages ...21
3.4.2. Using BGP to Carry C-Multicast Routing .............22
4. BGP-Based Auto-Discovery of MVPN Membership ....................22
5. PE-PE Transmission of C-Multicast Routing ......................25
5.1. Selecting the Upstream Multicast Hop (UMH) ................25
5.1.1. Eligible Routes for UMH Selection ..................26
5.1.2. Information Carried by Eligible UMH Routes .........26
5.1.3. Selecting the Upstream PE ..........................27
5.1.4. Selecting the Upstream Multicast Hop ...............29
5.2. Details of Per-MVPN Full PIM Peering over MI-PMSI .........29
5.2.1. PIM C-Instance Control Packets .....................29
5.2.2. PIM C-Instance Reverse Path Forwarding
(RPF) Determination ................................30
5.3. Use of BGP for Carrying C-Multicast Routing ...............31
5.3.1. Sending BGP Updates ................................31
5.3.2. Explicit Tracking ..................................32
5.3.3. Withdrawing BGP Updates ............................32
5.3.4. BSR ................................................33
6. PMSI Instantiation .............................................33
6.1. Use of the Intra-AS I-PMSI A-D Route ......................34
6.1.1. Sending Intra-AS I-PMSI A-D Routes .................34
6.1.2. Receiving Intra-AS I-PMSI A-D Routes ...............35
6.2. When C-flows Are Specifically Bound to P-Tunnels ..........35
6.3. Aggregating Multiple MVPNs on a Single P-Tunnel ...........35
6.3.1. Aggregate Tree Leaf Discovery ......................36
6.3.2. Aggregation Methodology ............................36
6.3.3. Demultiplexing C-Multicast Traffic .................37
6.4. Considerations for Specific Tunnel Technologies ...........38
6.4.1. RSVP-TE P2MP LSPs ..................................39
6.4.2. PIM Trees ..........................................41
6.4.3. mLDP P2MP LSPs .....................................42
6.4.4. mLDP MP2MP LSPs ....................................42
6.4.5. Ingress Replication ................................42
7. Binding Specific C-Flows to Specific P-Tunnels .................44
7.1. General Considerations ....................................45
7.1.1. At the PE Transmitting the C-Flow on the P-Tunnel ..45
7.1.2. At the PE Receiving the C-flow from the P-Tunnel ...46
7.2. Optimizing Multicast Distribution via S-PMSIs .............48
7.3. Announcing the Presence of Unsolicited Flooded Data .......49
7.4. Protocols for Binding C-Flows to P-Tunnels ................50
7.4.1. Using BGP S-PMSI A-D Routes ........................50
7.4.1.1. Advertising C-Flow Binding to P-Tunnel ....50
7.4.1.2. Explicit Tracking .........................51
7.4.2. UDP-Based Protocol .................................52
7.4.2.1. Advertising C-Flow Binding to P-Tunnel ....52
7.4.2.2. Packet Formats and Constants ..............53
7.4.3. Aggregation ........................................55
8. Inter-AS Procedures ............................................55
8.1. Non-Segmented Inter-AS P-Tunnels ..........................56
8.1.1. Inter-AS MVPN Auto-Discovery .......................56
8.1.2. Inter-AS MVPN Routing Information Exchange .........56
8.1.3. Inter-AS P-Tunnels .................................57
8.1.3.1. PIM-Based Inter-AS P-Multicast Trees ......57
8.1.3.2. The PIM MVPN Join Attribute ...............58
8.1.3.2.1. Definition .....................58
8.1.3.2.2. Usage ..........................59
8.2. Segmented Inter-AS P-Tunnels ..............................60
9. Preventing Duplication of Multicast Data Packets ...............60
9.1. Methods for Ensuring Non-Duplication ......................61
5.2.2. PIM C-Instance Reverse Path Forwarding
(RPF) Determination ................................30
5.3. Use of BGP for Carrying C-Multicast Routing ...............31
5.3.1. Sending BGP Updates ................................31
5.3.2. Explicit Tracking ..................................32
5.3.3. Withdrawing BGP Updates ............................32
5.3.4. BSR ................................................33
6. PMSI Instantiation .............................................33
6.1. Use of the Intra-AS I-PMSI A-D Route ......................34
6.1.1. Sending Intra-AS I-PMSI A-D Routes .................34
6.1.2. Receiving Intra-AS I-PMSI A-D Routes ...............35
6.2. When C-flows Are Specifically Bound to P-Tunnels ..........35
6.3. Aggregating Multiple MVPNs on a Single P-Tunnel ...........35
6.3.1. Aggregate Tree Leaf Discovery ......................36
6.3.2. Aggregation Methodology ............................36
6.3.3. Demultiplexing C-Multicast Traffic .................37
6.4. Considerations for Specific Tunnel Technologies ...........38
6.4.1. RSVP-TE P2MP LSPs ..................................39
6.4.2. PIM Trees ..........................................41
6.4.3. mLDP P2MP LSPs .....................................42
6.4.4. mLDP MP2MP LSPs ....................................42
6.4.5. Ingress Replication ................................42
7. Binding Specific C-Flows to Specific P-Tunnels .................44
7.1. General Considerations ....................................45
7.1.1. At the PE Transmitting the C-Flow on the P-Tunnel ..45
7.1.2. At the PE Receiving the C-flow from the P-Tunnel ...46
7.2. Optimizing Multicast Distribution via S-PMSIs .............48
7.3. Announcing the Presence of Unsolicited Flooded Data .......49
7.4. Protocols for Binding C-Flows to P-Tunnels ................50
7.4.1. Using BGP S-PMSI A-D Routes ........................50
7.4.1.1. Advertising C-Flow Binding to P-Tunnel ....50
7.4.1.2. Explicit Tracking .........................51
7.4.2. UDP-Based Protocol .................................52
7.4.2.1. Advertising C-Flow Binding to P-Tunnel ....52
7.4.2.2. Packet Formats and Constants ..............53
7.4.3. Aggregation ........................................55
8. Inter-AS Procedures ............................................55
8.1. Non-Segmented Inter-AS P-Tunnels ..........................56
8.1.1. Inter-AS MVPN Auto-Discovery .......................56
8.1.2. Inter-AS MVPN Routing Information Exchange .........56
8.1.3. Inter-AS P-Tunnels .................................57
8.1.3.1. PIM-Based Inter-AS P-Multicast Trees ......57
8.1.3.2. The PIM MVPN Join Attribute ...............58
8.1.3.2.1. Definition .....................58
8.1.3.2.2. Usage ..........................59
8.2. Segmented Inter-AS P-Tunnels ..............................60
9. Preventing Duplication of Multicast Data Packets ...............60
9.1. Methods for Ensuring Non-Duplication ......................61
9.1.1. Discarding Packets from Wrong PE ...................62
9.1.2. Single Forwarder Selection .........................63
9.1.3. Native PIM Methods .................................63
9.2. Multihomed C-S or C-RP ....................................63
9.3. Switching from the C-RP Tree to the C-S Tree ..............63
9.3.1. How Duplicates Can Occur ...........................63
9.3.2. Solution Using Source Active A-D Routes ............65
10. Eliminating PE-PE Distribution of (C-*,C-G) State .............67
10.1. Co-Locating C-RPs on a PE ................................68
10.1.1. Initial Configuration .............................68
10.1.2. Anycast RP Based on Propagating Active Sources ....68
10.1.2.1. Receiver(s) within a Site ................69
10.1.2.2. Source within a Site .....................69
10.1.2.3. Receiver Switching from Shared to
Source Tree ..............................69
10.2. Using MSDP between a PE and a Local C-RP .................69
11. Support for PIM-BIDIR C-Groups ................................71
11.1. The VPN Backbone Becomes the RPL .........................72
11.1.1. Control Plane .....................................72
11.1.2. Data Plane ........................................73
11.2. Partitioned Sets of PEs ..................................73
11.2.1. Partitions ........................................73
11.2.2. Using PE Distinguisher Labels .....................74
11.2.3. Partial Mesh of MP2MP P-Tunnels ...................75
12. Encapsulations ................................................75
12.1. Encapsulations for Single PMSI per P-Tunnel ..............75
12.1.1. Encapsulation in GRE ..............................75
12.1.2. Encapsulation in IP ...............................76
12.1.3. Encapsulation in MPLS .............................77
12.2. Encapsulations for Multiple PMSIs per P-Tunnel ...........78
12.2.1. Encapsulation in GRE ..............................78
12.2.2. Encapsulation in IP ...............................78
12.3. Encapsulations Identifying a Distinguished PE ............78
12.3.1. For MP2MP LSP P-Tunnels ...........................78
12.3.2. For Support of PIM-BIDIR C-Groups .................79
12.4. General Considerations for IP and GRE Encapsulations .....79
12.4.1. MTU (Maximum Transmission Unit) ...................79
12.4.2. TTL (Time to Live) ................................80
12.4.3. Avoiding Conflict with Internet Multicast .........80
12.5. Differentiated Services ..................................81
13. Security Considerations .......................................81
14. IANA Considerations ...........................................83
15. Acknowledgments ...............................................83
16. References ....................................................84
16.1. Normative References .....................................84
16.2. Informative References ...................................85
9.1.1. Discarding Packets from Wrong PE ...................62
9.1.2. Single Forwarder Selection .........................63
9.1.3. Native PIM Methods .................................63
9.2. Multihomed C-S or C-RP ....................................63
9.3. Switching from the C-RP Tree to the C-S Tree ..............63
9.3.1. How Duplicates Can Occur ...........................63
9.3.2. Solution Using Source Active A-D Routes ............65
10. Eliminating PE-PE Distribution of (C-*,C-G) State .............67
10.1. Co-Locating C-RPs on a PE ................................68
10.1.1. Initial Configuration .............................68
10.1.2. Anycast RP Based on Propagating Active Sources ....68
10.1.2.1. Receiver(s) within a Site ................69
10.1.2.2. Source within a Site .....................69
10.1.2.3. Receiver Switching from Shared to
Source Tree ..............................69
10.2. Using MSDP between a PE and a Local C-RP .................69
11. Support for PIM-BIDIR C-Groups ................................71
11.1. The VPN Backbone Becomes the RPL .........................72
11.1.1. Control Plane .....................................72
11.1.2. Data Plane ........................................73
11.2. Partitioned Sets of PEs ..................................73
11.2.1. Partitions ........................................73
11.2.2. Using PE Distinguisher Labels .....................74
11.2.3. Partial Mesh of MP2MP P-Tunnels ...................75
12. Encapsulations ................................................75
12.1. Encapsulations for Single PMSI per P-Tunnel ..............75
12.1.1. Encapsulation in GRE ..............................75
12.1.2. Encapsulation in IP ...............................76
12.1.3. Encapsulation in MPLS .............................77
12.2. Encapsulations for Multiple PMSIs per P-Tunnel ...........78
12.2.1. Encapsulation in GRE ..............................78
12.2.2. Encapsulation in IP ...............................78
12.3. Encapsulations Identifying a Distinguished PE ............78
12.3.1. For MP2MP LSP P-Tunnels ...........................78
12.3.2. For Support of PIM-BIDIR C-Groups .................79
12.4. General Considerations for IP and GRE Encapsulations .....79
12.4.1. MTU (Maximum Transmission Unit) ...................79
12.4.2. TTL (Time to Live) ................................80
12.4.3. Avoiding Conflict with Internet Multicast .........80
12.5. Differentiated Services ..................................81
13. Security Considerations .......................................81
14. IANA Considerations ...........................................83
15. Acknowledgments ...............................................83
16. References ....................................................84
16.1. Normative References .....................................84
16.2. Informative References ...................................85
[RFC4364] specifies the set of procedures that a Service Provider (SP) must implement in order to provide a particular kind of VPN service ("BGP/MPLS IP VPN") for its customers. The service described therein allows IP unicast packets to travel from one customer site to another, but it does not provide a way for IP multicast traffic to travel from one customer site to another.
[RFC4364]指定了服务提供商（SP）为向其客户提供特定类型的VPN服务（“BGP/MPLS IP VPN”）而必须实施的一组过程。其中描述的服务允许IP单播分组从一个客户站点传输到另一个客户站点，但是它不提供IP多播业务从一个客户站点传输到另一个客户站点的方式。
This document extends the service defined in [RFC4364] so that it also includes the capability of handling IP multicast traffic. This requires a number of different protocols to work together. The document provides a framework describing how the various protocols fit together, and it also provides a detailed specification of some of the protocols. The detailed specification of some of the other protocols is found in preexisting documents or in companion documents.
本文档扩展了[RFC4364]中定义的服务，因此它还包括处理IP多播流量的能力。这需要许多不同的协议协同工作。该文档提供了一个框架，描述了各种协议如何组合在一起，还提供了一些协议的详细规范。其他一些协议的详细规范见先前存在的文件或配套文件。
A BGP/MPLS IP VPN service that supports multicast is known as a "Multicast VPN" or "MVPN".
支持多播的BGP/MPLS IP VPN服务称为“多播VPN”或“MVPN”。
Both this document and its companion document [MVPN-BGP] discuss the use of various BGP messages and procedures to provide MVPN support. While every effort has been made to ensure that the two documents are consistent with each other, it is possible that discrepancies have crept in. In the event of any conflict or other discrepancy with respect to the use of BGP in support of MVPN service, [MVPN-BGP] is to be considered to be the authoritative document.
本文档及其配套文档[MVPN-BGP]讨论了各种BGP消息和程序的使用，以提供MVPN支持。虽然已尽一切努力确保这两份文件相互一致，但有可能出现不一致之处。如果在使用BGP支持MVPN服务方面存在任何冲突或其他差异，[MVPN-BGP]将被视为权威文件。
Throughout this document, we will use the term "VPN-IP route" to mean a route that is either in the VPN-IPv4 address family [RFC4364] or in the VPN-IPv6 address family [RFC4659].
在本文档中，我们将使用术语“VPN-IP路由”来表示VPN-IPv4地址系列[RFC4364]或VPN-IPv6地址系列[RFC4659]中的路由。
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]中所述进行解释。
In a "BGP/MPLS IP VPN" [RFC4364], unicast routing of VPN packets is achieved without the need to keep any per-VPN state in the core of the SP's network (the "P routers"). Routing information from a particular VPN is maintained only by the Provider Edge routers (the "PE routers", or "PEs") that attach directly to sites of that VPN. Customer data travels through the P routers in tunnels from one PE to another (usually MPLS Label Switched Paths, LSPs), so to support the
在“BGP/MPLS IP VPN”[RFC4364]中，实现VPN数据包的单播路由，而无需在SP网络的核心中保持任何每VPN状态（“P路由器”）。来自特定VPN的路由信息仅由直接连接到该VPN站点的提供商边缘路由器（“PE路由器”或“PEs”）维护。客户数据通过隧道中的P路由器从一个PE传输到另一个PE（通常是MPLS标签交换路径，LSP），以支持
VPN service the P routers only need to have routes to the PE routers. The PE-to-PE routing is optimal, but the amount of associated state in the P routers depends only on the number of PEs, not on the number of VPNs.
VPN服务P路由器只需要有到PE路由器的路由。PE-to-PE路由是最优的，但P路由器中关联状态的数量仅取决于PE的数量，而不取决于VPN的数量。
However, in order to provide optimal multicast routing for a particular multicast flow, the P routers through which that flow travels have to hold state that is specific to that flow. A multicast flow is identified by the (source, group) tuple where the source is the IP address of the sender and the group is the IP multicast group address of the destination. Scalability would be poor if the amount of state in the P routers were proportional to the number of multicast flows in the VPNs. Therefore, when supporting multicast service for a BGP/MPLS IP VPN, the optimality of the multicast routing must be traded off against the scalability of the P routers. We explain this below in more detail.
然而，为了为特定多播流提供最佳多播路由，该流通过的P路由器必须保持特定于该流的状态。多播流由（source，group）元组标识，其中source是发送方的IP地址，group是目的地的IP多播组地址。如果P路由器中的状态量与vpn中多播流的数量成比例，那么可伸缩性将很差。因此，在为BGP/MPLS IP VPN支持多播服务时，必须权衡多播路由的最佳性和多播路由器的可伸缩性。下面我们将对此进行更详细的解释。
If a particular VPN is transmitting "native" multicast traffic over the backbone, we refer to it as an "MVPN". By "native" multicast traffic, we mean packets that a Customer Edge router (a "CE router" or "CE") sends to a PE, such that the IP destination address of the packets is a multicast group address, the packets are multicast control packets addressed to the PE router itself, or the packets are IP multicast data packets encapsulated in MPLS.
如果某个特定的VPN在主干网上传输“本机”多播流量，我们将其称为“MVPN”。所谓“本机”多播通信量，我们是指客户边缘路由器（“CE路由器”或“CE”）发送到PE的分组，使得分组的IP目的地地址是多播组地址，分组是寻址到PE路由器本身的多播控制分组，或者分组是封装在MPLS中的IP多播数据分组。
We say that the backbone multicast routing for a particular multicast group in a particular VPN is "optimal" if and only if all of the following conditions hold:
我们认为，当且仅当以下所有条件均成立时，特定VPN中特定多播组的主干多播路由是“最优”的：
- When a PE router receives a multicast data packet of that group from a CE router, it transmits the packet in such a way that the packet is received by every other PE router that is on the path to a receiver of that group;
- 当PE路由器从CE路由器接收到该组的多播数据分组时，它以这样的方式发送该分组，即该分组被路径上到该组的接收器的每个其他PE路由器接收；
- The packet is not received by any other PEs;
- 该数据包未被任何其他PEs接收；
- While in the backbone, no more than one copy of the packet ever traverses any link.
- 在主干网中，只有一个以上的数据包副本通过任何链路。
- While in the backbone, if bandwidth usage is to be optimized, the packet traverses minimum cost trees rather than shortest path trees.
- 而在主干网中，如果要优化带宽使用，则数据包将遍历最小成本树而不是最短路径树。
Optimal routing for a particular multicast group requires that the backbone maintain one or more source trees that are specific to that flow. Each such tree requires that state be maintained in all the P routers that are in the tree.
特定多播组的最佳路由要求主干维护一个或多个特定于该流的源树。每个这样的树都需要在树中的所有P路由器中维护状态。
Potentially, this would require an unbounded amount of state in the P routers, since the SP has no control of the number of multicast groups in the VPNs that it supports. The SP also doesn't have any control over the number of transmitters in each group, nor over the distribution of the receivers.
由于SP无法控制其支持的VPN中的多播组的数量，因此这可能需要P路由器中的状态量不受限制。SP也无法控制每组中发射器的数量，也无法控制接收器的分布。
The procedures defined in this document allow an SP to provide multicast VPN service, without requiring the amount of state maintained by the P routers to be proportional to the number of multicast data flows in the VPNs. The amount of state is traded off against the optimality of the multicast routing. Enough flexibility is provided so that a given SP can make his own trade-offs between scalability and optimality. An SP can even allow some multicast groups in some VPNs to receive optimal routing, while others do not. Of course, the cost of this flexibility is an increase in the number of options provided by the protocols.
本文档中定义的过程允许SP提供多播VPN服务，而不要求P路由器维护的状态量与VPN中多播数据流的数量成比例。状态量与多播路由的最优性进行权衡。提供了足够的灵活性，因此给定的SP可以在可伸缩性和最佳性之间进行权衡。SP甚至可以允许某些VPN中的某些多播组接收最佳路由，而其他组则不能。当然，这种灵活性的代价是协议提供的选项数量增加。
The basic technique for providing scalability is to aggregate a number of customer multicast flows onto a single multicast distribution tree through the P routers. A number of aggregation methods are supported.
提供可伸缩性的基本技术是通过P路由器将多个客户多播流聚合到单个多播分发树上。支持多种聚合方法。
The procedures defined in this document also accommodate the SP that does not want to build multicast distribution trees in his backbone at all; the ingress PE can replicate each multicast data packet and then unicast each replica through a tunnel to each egress PE that needs to receive the data.
本文档中定义的过程也适用于根本不想在主干网中构建多播分发树的SP；入口PE可以复制每个多播数据分组，然后通过隧道将每个副本单播到需要接收数据的每个出口PE。
This document supports the use of a single multicast distribution tree in the backbone to carry all the multicast traffic from a specified set of one or more MVPNs. Such a tree is referred to as an "Inclusive Tree". An Inclusive Tree that carries the traffic of more than one MVPN is an "Aggregate Inclusive Tree". An Inclusive Tree contains, as its members, all the PEs that attach to any of the MVPNs using the tree.
本文档支持在主干中使用单个多播分发树来承载来自一个或多个MVPN的指定集合的所有多播流量。这种树被称为“包含树”。承载多个MVPN流量的包含树是“聚合包含树”。包含树包含使用该树连接到任何MVPN的所有PE作为其成员。
With this option, even if each tree supports only one MVPN, the upper bound on the amount of state maintained by the P routers is proportional to the number of VPNs supported rather than to the number of multicast flows in those VPNs. If the trees are unidirectional, it would be more accurate to say that the state is proportional to the product of the number of VPNs and the average number of PEs per VPN. The amount of state maintained by the P routers can be further reduced by aggregating more MVPNs onto a single tree. If each such tree supports a set of MVPNs, (call it an "MVPN aggregation set"), the state maintained by the P routers is
使用此选项，即使每个树只支持一个MVPN，P路由器维护的状态量上限与支持的VPN数量成正比，而不是与这些VPN中的多播流数量成正比。如果树是单向的，则更准确地说，状态与VPN数量和每个VPN的平均PE数量的乘积成正比。通过将更多MVPN聚合到单个树上，可以进一步减少由P路由器维护的状态量。如果每个这样的树都支持一组MVPN（称之为“MVPN聚合集”），则P路由器维护的状态为
proportional to the product of the number of MVPN aggregation sets and the average number of PEs per MVPN. Thus, the state does not grow linearly with the number of MVPNs.
与MVPN聚合集数量和每个MVPN的平均PE数量的乘积成比例。因此，状态不会随着MVPN的数量线性增长。
However, as data from many multicast groups is aggregated together onto a single Inclusive Tree, it is likely that some PEs will receive multicast data for which they have no need, i.e., some degree of optimality has been sacrificed.
然而，由于来自多个多播组的数据聚合到一个包含树上，因此一些PE可能会接收到它们不需要的多播数据，即牺牲了某种程度的优化。
This document also provides procedures that enable a single multicast distribution tree in the backbone to be used to carry traffic belonging only to a specified set of one or more multicast groups, from one or more MVPNs. Such a tree is referred to as a "Selective Tree" and more specifically as an "Aggregate Selective Tree" when the multicast groups belong to different MVPNs. By default, traffic from most multicast groups could be carried by an Inclusive Tree, while traffic from, e.g., high bandwidth groups could be carried in one of the Selective Trees. When setting up the Selective Trees, one should include only those PEs that need to receive multicast data from one or more of the groups assigned to the tree. This provides more optimal routing than can be obtained by using only Inclusive Trees, though it requires additional state in the P routers.
本文档还提供了使主干中的单个多播分发树能够用于从一个或多个MVPN承载仅属于一个或多个多播组的指定集合的流量的过程。当多播组属于不同的mvpn时，这种树被称为“选择性树”，更具体地说，被称为“聚合选择性树”。默认情况下，来自大多数多播组的流量可由包含树承载，而来自（例如）高带宽组的流量可由选择树之一承载。设置选择性树时，应仅包括需要从分配给树的一个或多个组接收多播数据的PE。这提供了比仅使用包含树更优化的路由，尽管它需要P路由器中的附加状态。
This document also provides procedures for carrying MVPN data traffic through unicast tunnels from the ingress PE to each of the egress PEs. The ingress PE replicates the multicast data packet received from a CE and sends it to each of the egress PEs using the unicast tunnels. This requires no multicast routing state in the P routers at all, but it puts the entire replication load on the ingress PE router and makes no attempt to optimize the multicast routing.
本文档还提供了通过单播隧道将MVPN数据流量从入口PE传输到每个出口PE的过程。入口PE复制从CE接收的多播数据分组，并使用单播隧道将其发送到每个出口PE。这根本不需要P路由器中的多播路由状态，但它将整个复制负载放在入口PE路由器上，并且不尝试优化多播路由。
In BGP/MPLS IP VPNs [RFC4364], each CE (Customer Edge) router is a unicast routing adjacency of a PE router, but CE routers at different sites do not become unicast routing adjacencies of each other. This important characteristic is retained for multicast routing -- a CE router becomes a multicast routing adjacency of a PE router, but CE routers at different sites do not become multicast routing adjacencies of each other.
在BGP/MPLS IP VPN[RFC4364]中，每个CE（客户边缘）路由器是PE路由器的单播路由邻接，但不同站点的CE路由器不会成为彼此的单播路由邻接。多播路由保留了这一重要特征——CE路由器成为PE路由器的多播路由邻接，但不同站点的CE路由器不会成为彼此的多播路由邻接。
We will use the term "C-tree" to refer to a multicast distribution tree whose nodes include CE routers. (See Section 3.1 for further explication of this terminology.)
我们将使用术语“C-树”来指节点包括CE路由器的多播分发树。（有关本术语的进一步解释，请参见第3.1节。）
The multicast routing protocol on the PE-CE link is presumed to be PIM (Protocol Independent Multicast) [PIM-SM]. Both the ASM (Any-Source Multicast) and the SSM (Source-Specific Multicast) service models are supported. Thus, both shared C-trees and source-specific C-trees are supported. Shared C-trees may be unidirectional or bidirectional; in the latter case, the multicast routing protocol is presumed to be the BIDIR-PIM [BIDIR-PIM] "variant" of PIM-SM. A CE router exchanges "ordinary" PIM control messages with the PE router to which it is attached.
PE-CE链路上的多播路由协议被假定为PIM（协议独立多播）[PIM-SM]。支持ASM（任意源多播）和SSM（源特定多播）服务模型。因此，支持共享C树和源特定C树。共享C-树可以是单向的或双向的；在后一种情况下，多播路由协议被假定为PIM-SM的BIDIR-PIM[BIDIR-PIM]“变体”。CE路由器与所连接的PE路由器交换“普通”PIM控制消息。
Support for PIM-DM (Dense Mode) is outside the scope of this document.
对PIM-DM（密集模式）的支持超出了本文档的范围。
The PEs attaching to a particular MVPN then have to exchange the multicast routing information with each other. Two basic methods for doing this are defined: (1) PE-PE PIM and (2) BGP. In the former case, the PEs need to be multicast routing adjacencies of each other. In the latter case, they do not. For example, each PE may be a BGP adjacency of a route reflector (RR) and not of any other PEs.
然后，连接到特定MVPN的PE必须彼此交换多播路由信息。定义了两种基本方法：（1）PE-PE PIM和（2）BGP。在前一种情况下，PEs需要是彼此相邻的多播路由。在后一种情况下，它们没有。例如，每个PE可以是路由反射器（RR）的BGP邻接，而不是任何其他PE的BGP邻接。
In order to support the "Carrier's Carrier" model of [RFC4364], mLDP (Label Distribution Protocol Extensions for Multipoint Label Switched Paths) [MLDP] may also be supported on the PE-CE interface. The use of mLDP on the PE-CE interface is described in [MVPN-BGP]. The use of BGP on the PE-CE interface is not within the scope of this document.
为了支持[RFC4364]的“载波载波”模型，在PE-CE接口上也可以支持mLDP（多点标签交换路径的标签分发协议扩展）[mLDP]。[MVPN-BGP]中描述了在PE-CE接口上使用mLDP。在PE-CE接口上使用BGP不在本文件范围内。
An MVPN is defined by two sets of sites: the Sender Sites set and the Receiver Sites set, with the following properties:
MVPN由两组站点定义：发送方站点集和接收方站点集，具有以下属性：
- Hosts within the Sender Sites set could originate multicast traffic for receivers in the Receiver Sites set.
- 发送方站点集中的主机可以为接收方站点集中的接收方发起多播通信。
- Receivers not in the Receiver Sites set should not be able to receive this traffic.
- 不在接收器站点集中的接收器不应能够接收此流量。
- Hosts within the Receiver Sites set could receive multicast traffic originated by any host in the Sender Sites set.
- 接收方站点集中的主机可以接收由发送方站点集中的任何主机发起的多播流量。
- Hosts within the Receiver Sites set should not be able to receive multicast traffic originated by any host that is not in the Sender Sites set.
- 接收方站点集中的主机不应能够接收由不在发送方站点集中的任何主机发起的多播通信。
A site could be both in the Sender Sites set and Receiver Sites set, which implies that hosts within such a site could both originate and receive multicast traffic. An extreme case is when the Sender Sites set is the same as the Receiver Sites set, in which case all sites could originate and receive multicast traffic from each other.
站点可以同时位于发送方站点集和接收方站点集，这意味着这样一个站点中的主机可以同时发起和接收多播通信。一种极端情况是，发送方站点集与接收方站点集相同，在这种情况下，所有站点都可以彼此发起和接收多播流量。
Sites within a given MVPN may be either within the same organization or in different organizations, which implies that an MVPN can be either an Intranet or an Extranet.
给定MVPN中的站点可以位于同一组织内，也可以位于不同的组织内，这意味着MVPN可以是内联网或外联网。
A given site may be in more than one MVPN, which implies that MVPNs may overlap.
给定站点可能位于多个MVPN中，这意味着MVPN可能重叠。
Not all sites of a given MVPN have to be connected to the same service provider, which implies that an MVPN can span multiple service providers.
并非给定MVPN的所有站点都必须连接到同一个服务提供商，这意味着MVPN可以跨越多个服务提供商。
Another way to look at MVPN is to say that an MVPN is defined by a set of administrative policies. Such policies determine both the Sender Sites set and Receiver Sites set. Such policies are established by MVPN customers, but implemented/realized by MVPN Service Providers using the existing BGP/MPLS VPN mechanisms, such as Route Targets (RTs), with extensions, as necessary.
查看MVPN的另一种方式是，MVPN由一组管理策略定义。此类策略确定发送方站点集和接收方站点集。这些策略由MVPN客户制定，但由MVPN服务提供商使用现有的BGP/MPLS VPN机制（如路由目标（RTs））实施/实现，并根据需要进行扩展。
In order for the PE routers attaching to a given MVPN to exchange MVPN control information with each other, each one needs to discover all the other PEs that attach to the same MVPN. (Strictly speaking, a PE in the Receiver Sites set need only discover the other PEs in the Sender Sites set, and a PE in the Sender Sites set need only discover the other PEs in the Receiver Sites set.) This is referred to as "MVPN Auto-Discovery".
为了使连接到给定MVPN的PE路由器彼此交换MVPN控制信息，每个路由器都需要发现连接到同一MVPN的所有其他PE。（严格来说，接收方站点集中的PE只需发现发送方站点集中的其他PE，而发送方站点集中的PE只需发现接收方站点集中的其他PE。）这称为“MVPN自动发现”。
This document discusses two ways of providing MVPN auto-discovery:
本文档讨论了提供MVPN自动发现的两种方法：
- BGP can be used for discovering and maintaining MVPN membership. The PE routers advertise their MVPN membership to other PE routers using BGP. A PE is considered to be a "member" of a particular MVPN if it contains a VRF (Virtual Routing and Forwarding table, see [RFC4364]) that is configured to contain the multicast routing information of that MVPN. This auto-discovery option does not make any assumptions about the methods used for transmitting MVPN multicast data packets through the backbone.
- BGP可用于发现和维护MVPN成员资格。PE路由器使用BGP向其他PE路由器公布其MVPN成员资格。如果PE包含配置为包含该MVPN的多播路由信息的VRF（虚拟路由和转发表，请参见[RFC4364]），则PE被视为特定MVPN的“成员”。此自动发现选项不对用于通过主干传输MVPN多播数据包的方法进行任何假设。
- If it is known that the PE-PE multicast control packets (i.e., PIM packets) of a particular MVPN are to be transmitted through a non-aggregated Inclusive Tree supporting the ASM service model (e.g., through a tree that is created by non-SSM PIM-SM or by BIDIR-PIM), and if the PEs attaching to that MVPN are configured with the group address corresponding to that tree, then the PEs can auto-discover each other simply by joining the tree and then multicasting PIM Hellos over the tree.
- 如果已知特定MVPN的PE-PE多播控制分组（即，PIM分组）将通过支持ASM服务模型的非聚合包含树（例如，通过非SSM PIM-SM或BIDIR-PIM创建的树）传输，如果附加到该MVPN的PEs配置了与该树对应的组地址，则PEs可以通过加入该树然后在该树上多播PIM hello来自动发现彼此。
The BGP/MPLS IP VPN [RFC4364] specification requires a PE to maintain, at most, one BGP peering with every other PE in the network. This peering is used to exchange VPN routing information. The use of route reflectors further reduces the number of BGP adjacencies maintained by a PE to exchange VPN routing information with other PEs. This document describes various options for exchanging MVPN control information between PE routers based on the use of PIM or BGP. These options have different overheads with respect to the number of routing adjacencies that a PE router needs to maintain to exchange MVPN control information with other PE routers. Some of these options allow the retention of the unicast BGP/MPLS VPN model letting a PE maintain, at most, one BGP routing adjacency with other PE routers to exchange MVPN control information. BGP also provides reliable transport and uses incremental updates. Another option is the use of the currently existing "soft state" PIM standard [PIM-SM] that uses periodic complete updates.
BGP/MPLS IP VPN[RFC4364]规范要求一个PE最多与网络中的每一个PE保持一个BGP对等。此对等用于交换VPN路由信息。路由反射器的使用进一步减少了由PE维护的BGP邻接的数量，以与其他PE交换VPN路由信息。本文档描述了基于PIM或BGP的PE路由器之间交换MVPN控制信息的各种选项。就PE路由器需要维护的路由邻接数而言，这些选项具有不同的开销，以便与其他PE路由器交换MVPN控制信息。其中一些选项允许保留单播BGP/MPLS VPN模型，允许PE最多与其他PE路由器保持一个BGP路由邻接，以交换MVPN控制信息。BGP还提供可靠的传输并使用增量更新。另一种选择是使用当前存在的“软状态”PIM标准[PIM-SM]，该标准使用定期完整更新。
Like [RFC4364], this document decouples the procedures for exchanging routing information from the procedures for transmitting data traffic. Hence, a variety of transport technologies may be used in the backbone. For Inclusive Trees, these transport technologies include unicast PE-PE tunnels, using encapsulation in MPLS, IP, or GRE (Generic Routing Encapsulation), multicast distribution trees created by PIM (either unidirectional in the SSM or ASM service models or bidirectional) using IP/GRE encapsulation, point-to-multipoint LSPs created by RSVP - Traffic Engineering (RSVP-TE) or mLDP, and multipoint-to-multipoint LSPs created by mLDP.
与[RFC4364]类似，本文档将交换路由信息的过程与传输数据流量的过程分离。因此，在主干网中可以使用多种传输技术。对于包含树，这些传输技术包括单播PE-PE隧道，使用MPLS、IP或GRE（通用路由封装）中的封装，由PIM创建的多播分发树（SSM或ASM服务模型中的单向或双向），使用IP/GRE封装，由RSVP-流量工程（RSVP-TE）或mLDP创建的点对多点LSP，以及由mLDP创建的多点对多点LSP。
In order to aggregate traffic from multiple MVPNs onto a single multicast distribution tree, it is necessary to have a mechanism to enable the egresses of the tree to demultiplex the multicast traffic received over the tree and to associate each received packet with a particular MVPN. This document specifies a mechanism whereby upstream label assignment [MPLS-UPSTREAM-LABEL] is used by the root of the tree to assign a label to each flow. This label is used by
为了将来自多个MVPN的业务聚合到单个多播分发树上，需要具有使树的出口能够解复用通过树接收的多播业务并将每个接收的分组与特定MVPN相关联的机制。本文档规定了一种机制，树的根使用上游标签分配[MPLS-上游标签]为每个流分配标签。此标签由用户使用
the receivers to perform the demultiplexing. This document also describes procedures based on BGP that are used by the root of an Aggregate Tree to advertise the Inclusive and/or Selective binding and the demultiplexing information to the leaves of the tree.
接收机执行解复用。本文档还描述了基于BGP的过程，聚合树的根使用BGP将包含和/或选择性绑定以及解复用信息发布到树的叶子上。
This document also describes the data plane encapsulations for supporting the various SP multicast transport options.
本文档还描述了支持各种SP多播传输选项的数据平面封装。
The specification for aggregating traffic of multiple MVPNs onto a single multipoint-to-multipoint LSP or onto a single bidirectional multicast distribution tree is outside the scope of this document.
将多个MVPN的流量聚合到单个多点对多点LSP或单个双向多播分发树上的规范不在本文档的范围内。
The specifications for using, as Selective Trees, multicast distribution trees that support the ASM service model are outside the scope of this document. The specification for using multipoint-to-multipoint LSPs as Selective Trees is outside the scope of this document.
将支持ASM服务模型的多播分发树用作选择性树的规范不在本文档的范围内。将多点对多点LSP用作选择性树的规范不在本文档的范围内。
This document assumes that when SP multicast trees are used, traffic for a particular multicast group is transmitted by a particular PE on only one SP multicast tree. The use of multiple SP multicast trees for transmitting traffic belonging to a particular multicast group is outside the scope of this document.
本文档假设在使用SP多播树时，特定多播组的通信量仅由一个SP多播树上的特定PE传输。使用多个SP多播树传输属于特定多播组的流量不在本文档的范围内。
[RFC4364] describes different options for supporting BGP/MPLS IP unicast VPNs whose provider backbones contain more than one Autonomous System (AS). These are known as "inter-AS VPNs". In an inter-AS VPN, the ASes may belong to the same provider or to different providers. This document describes how inter-AS MVPNs can be supported for each of the unicast BGP/MPLS VPN inter-AS options. This document also specifies a model where inter-AS MVPN service can be offered without requiring a single SP multicast tree to span multiple ASes. In this model, an inter-AS multicast tree consists of a number of "segments", one per AS, that are stitched together at AS boundary points. These are known as "segmented inter-AS trees". Each segment of a segmented inter-AS tree may use a different multicast transport technology.
[RFC4364]描述了支持BGP/MPLS IP单播VPN的不同选项，这些VPN的提供商主干包含多个自治系统（AS）。这些被称为“inter-as-vpn”。在AS间VPN中，ASE可能属于同一提供商或不同的提供商。本文档描述了如何为每个单播BGP/MPLS VPN内部AS选项支持内部AS MVPN。本文档还指定了一种模型，在该模型中，可以提供inter-AS MVPN服务，而不需要单个SP多播树来跨越多个ASE。在该模型中，AS间多播树由多个“段”组成，每个“段”在AS边界点处缝合在一起。这些被称为“分段的中间树”。分段的内部AS树的每个段可以使用不同的多播传输技术。
It is also possible to support inter-AS MVPNs with non-segmented source trees that extend across AS boundaries.
还可以支持跨AS边界扩展的非分段源树的内部AS MVPN。
This document also discusses some options and protocol extensions that can be used to eliminate the need for the PE routers to distribute to each other the (*,G) and (*,G,rpt) states that occur when the VPNs are creating unidirectional C-trees to support the ASM service model.
本文档还讨论了一些选项和协议扩展，这些选项和协议扩展可用于消除PE路由器相互分发（*，G）和（*，G，rpt）状态的需要，这些状态在VPN创建单向C树以支持ASM服务模型时发生。
Support of multicast in BGP/MPLS IP VPNs is modeled closely after the support of unicast in BGP/MPLS IP VPNs. That is, a multicast routing protocol will be run on the PE-CE interfaces, such that PE and CE are multicast routing adjacencies on that interface. CEs at different sites do not become multicast routing adjacencies of each other.
BGP/MPLS IP VPN中对组播的支持与BGP/MPLS IP VPN中对单播的支持相似。也就是说，将在PE-CE接口上运行多播路由协议，以便PE和CE是该接口上的多播路由邻接。不同站点上的CE不会成为彼此的多播路由邻接。
If a PE attaches to n VPNs for which multicast support is provided (i.e., to n "MVPNs"), the PE will run n independent instances of a multicast routing protocol. We will refer to these multicast routing instances as "VPN-specific multicast routing instances", or more briefly as "multicast C-instances". The notion of a "VRF" (VPN Routing and Forwarding Table), defined in [RFC4364], is extended to include multicast routing entries as well as unicast routing entries. Each multicast routing entry is thus associated with a particular VRF.
如果PE连接到为其提供多播支持的n个VPN（即，连接到n个“MVPN”），则PE将运行多播路由协议的n个独立实例。我们将这些多播路由实例称为“特定于VPN的多播路由实例”，或者更简单地称为“多播C实例”。[RFC4364]中定义的“VRF”（VPN路由和转发表）的概念被扩展为包括多播路由条目和单播路由条目。因此，每个多播路由条目都与特定的VRF相关联。
Whether a particular VRF belongs to an MVPN or not is determined by configuration.
特定VRF是否属于MVPN取决于配置。
In this document, we do not attempt to provide support for every possible multicast routing protocol that could possibly run on the PE-CE link. Rather, we consider multicast C-instances only for the following multicast routing protocols:
在本文档中，我们不尝试为可能在PE-CE链路上运行的每个可能的多播路由协议提供支持。相反，我们认为组播C实例仅适用于以下多播路由协议：
- PIM Sparse Mode (PIM-SM), supporting the ASM service model
- PIM稀疏模式（PIM-SM），支持ASM服务模型
- PIM Sparse Mode, supporting the SSM service model
- PIM稀疏模式，支持SSM服务模型
- PIM Bidirectional Mode (BIDIR-PIM), which uses bidirectional C-trees to support the ASM service model.
- PIM双向模式（BIDIR-PIM），它使用双向C树来支持ASM服务模型。
In order to support the "Carrier's Carrier" model of [RFC4364], mLDP may also be supported on the PE-CE interface. The use of mLDP on the PE-CE interface is described in [MVPN-BGP].
为了支持[RFC4364]的“承运商承运商”型号，也可以在PE-CE接口上支持mLDP。[MVPN-BGP]中描述了在PE-CE接口上使用mLDP。
The use of BGP on the PE-CE interface is not within the scope of this document.
在PE-CE接口上使用BGP不在本文件范围内。
As the only multicast C-instances discussed by this document are PIM-based C-instances, we will generally use the term "PIM C-instances" to refer to the multicast C-instances.
由于本文讨论的唯一多播C-实例是基于PIM的C-实例，我们通常使用术语“PIM C-实例”来指代多播C-实例。
A PE router may also be running a "provider-wide" instance of PIM, (a "PIM P-instance"), in which it has a PIM adjacency with, e.g., each of its IGP neighbors (i.e., with P routers), but NOT with any CE routers, and not with other PE routers (unless another PE router happens to be an IGP adjacency). In this case, P routers would also run the P-instance of PIM but NOT a C-instance. If there is a PIM P-instance, it may or may not have a role to play in the support of VPN multicast; this is discussed in later sections. However, in no case will the PIM P-instance contain VPN-specific multicast routing information.
PE路由器也可以运行PIM的“提供商范围”实例（“PIM P实例”），其中它与例如其每个IGP邻居（即，与P路由器）具有PIM邻接，但不与任何CE路由器，也不与其他PE路由器（除非另一个PE路由器恰好是IGP邻接）。在这种情况下，P路由器也会运行PIM的P实例，但不会运行C实例。如果存在PIM P实例，它可能在支持VPN多播方面起作用，也可能不起作用；这将在后面的章节中讨论。但是，PIM P实例在任何情况下都不会包含特定于VPN的多播路由信息。
In order to help clarify when we are speaking of the PIM P-instance and when we are speaking of a PIM C-instance, we will also apply the prefixes "P-" and "C-", respectively, to control messages, addresses, etc. Thus, a P-Join would be a PIM Join that is processed by the PIM P-instance, and a C-Join would be a PIM Join that is processed by a C-instance. A P-group address would be a group address in the SP's address space, and a C-group address would be a group address in a VPN's address space. A C-tree is a multicast distribution tree constructed and maintained by the PIM C-instances. A C-flow is a stream of multicast packets with a common C-source address and a common C-group address. We will use the notation "(C-S,C-G)" to identify specific C-flows. If a particular C-tree is a shared tree (whether unidirectional or bidirectional) rather than a source-specific tree, we will sometimes speak of the entire set of flows traveling that tree, identifying the set as "(C-*,C-G)".
为了有助于澄清我们何时谈论PIM P-instance以及何时谈论PIM C-instance，我们还将分别应用前缀“P-”和“C-”来控制消息、地址等。因此，P-Join将是由PIM P-instance处理的PIM Join，C-Join是由C-instance处理的PIM连接。P组地址是SP地址空间中的组地址，C组地址是VPN地址空间中的组地址。C-树是由PIM C-实例构造和维护的多播分发树。C流是具有公共C源地址和公共C组地址的多播数据包流。我们将使用符号“（C-S，C-G）”来识别特定的C-流。如果一个特定的C-树是一个共享树（无论是单向的还是双向的），而不是一个特定于源的树，那么我们有时会提到在该树上运行的整个流集合，将该集合标识为“（C-*，C-G）”。
A PE must have the ability to forward multicast data packets received from a CE to one or more of the other PEs in the same MVPN for delivery to one or more other CEs.
PE必须能够将从CE接收到的多播数据包转发到同一MVPN中的一个或多个其他PE，以便传送到一个或多个其他CE。
We define the notion of a "P-Multicast Service Interface" (PMSI). If a particular MVPN is supported by a particular set of PE routers, then there will be one or more PMSIs connecting those PE routers and/or subsets thereof. A PMSI is a conceptual "overlay" on the P-network with the following property: a PE in a given MVPN can give a packet to the PMSI, and the packet will be delivered to some or all of the other PEs in the MVPN, such that any PE receiving the packet will be able to determine the MVPN to which the packet belongs.
我们定义了“P多播服务接口”（PMSI）的概念。如果特定的MVPN由一组特定的PE路由器支持，那么将有一个或多个pmsi连接这些PE路由器和/或其子集。PMSI是P网络上具有以下属性的概念性“覆盖”：给定MVPN中的PE可以向PMSI提供数据包，并且数据包将被传送到MVPN中的一些或所有其他PE，这样接收数据包的任何PE都将能够确定数据包所属的MVPN。
As we discuss below, a PMSI may be instantiated by a number of different transport mechanisms, depending on the particular requirements of the MVPN and of the SP. We will refer to these transport mechanisms as "P-tunnels".
正如我们在下面讨论的，根据MVPN和SP的特殊要求，PMSI可以由许多不同的传输机制实例化。我们将这些传输机制称为“P隧道”。
For each MVPN, there are one or more PMSIs that are used for transmitting the MVPN's multicast data from one PE to others. We will use the term "PMSI" such that a single PMSI belongs to a single MVPN. However, the transport mechanism that is used to instantiate a PMSI may allow a single P-tunnel to carry the data of multiple PMSIs.
对于每个MVPN，有一个或多个PMSI用于将MVPN的多播数据从一个PE传输到其他PE。我们将使用术语“PMSI”，以便单个PMSI属于单个MVPN。然而，用于实例化PMSI的传输机制可允许单个P隧道承载多个PMSI的数据。
In this document, we make a clear distinction between the multicast service (the PMSI) and its instantiation. This allows us to separate the discussion of different services from the discussion of different instantiations of each service. The term "P-tunnel" is used to refer to the transport mechanism that instantiates a service.
在本文中，我们明确区分了多播服务（PMSI）及其实例化。这允许我们将不同服务的讨论与每个服务的不同实例化的讨论分开。术语“P-tunnel”用于指实例化服务的传输机制。
PMSIs are used to carry C-multicast data traffic. The C-multicast data traffic travels along a C-tree, but in the SP backbone all C-trees are tunneled through P-tunnels. Thus, we will sometimes talk of a P-tunnel carrying one or more C-trees.
PMSI用于承载C多播数据流量。C-多播数据流量沿C-树传输，但在SP主干中，所有C-树都通过P-隧道进行隧道传输。因此，我们有时会谈到一个P型隧道承载一个或多个C型树。
Some of the options for passing multicast control traffic among the PEs do so by sending the control traffic through a PMSI; other options do not send control traffic through a PMSI.
用于在PEs之间传递多播控制流量的一些选项通过通过PMSI发送控制流量来实现；其他选项不通过PMSI发送控制流量。
We will distinguish between three different kinds of PMSIs:
我们将区分三种不同类型的PMSI：
- "Multidirectional Inclusive" PMSI (MI-PMSI)
- “多向包容性”PMSI（MI-PMSI）
A Multidirectional Inclusive PMSI is one that enables ANY PE attaching to a particular MVPN to transmit a message such that it will be received by EVERY other PE attaching to that MVPN.
多向包容性PMSI是一种使连接到特定MVPN的任何PE都能够传输消息的PMSI，从而使连接到该MVPN的每个其他PE都能接收到该消息。
There is, at most, one MI-PMSI per MVPN. (Though the P-tunnel or P-tunnels that instantiate an MI-PMSI may actually carry the data of more than one PMSI.)
每个MVPN最多有一个MI-PMSI。（尽管实例化MI-PMSI的P隧道或P隧道实际上可能携带多个PMSI的数据。）
An MI-PMSI can be thought of as an overlay broadcast network connecting the set of PEs supporting a particular MVPN.
MI-PMSI可以被认为是连接支持特定MVPN的一组PE的覆盖广播网络。
- "Unidirectional Inclusive" PMSI (UI-PMSI)
- “单向包容性”PMSI（UI-PMSI）
A Unidirectional Inclusive PMSI is one that enables a particular PE, attached to a particular MVPN, to transmit a message such that it will be received by all the other PEs attaching to that
单向包容性PMSI是使连接到特定MVPN的特定PE能够传输消息的PMSI，从而使连接到该MVPN的所有其他PE都能接收到该消息
MVPN. There is, at most, one UI-PMSI per PE per MVPN, though the P-tunnel that instantiates a UI-PMSI may, in fact, carry the data of more than one PMSI.
MVPN。每个MVPN每个PE最多有一个UI-PMSI，尽管实例化UI-PMSI的P隧道实际上可能携带多个PMSI的数据。
- "Selective" PMSI (S-PMSI).
- “选择性”PMSI（S-PMSI）。
A Selective PMSI is one that provides a mechanism wherein a particular PE in an MVPN can multicast messages so that they will be received by a subset of the other PEs of that MVPN. There may be an arbitrary number of S-PMSIs per PE per MVPN. The P-tunnel that instantiates a given S-PMSI may carry data from multiple S-PMSIs.
选择性PMSI是提供一种机制的PMSI，其中MVPN中的特定PE可以多播消息，以便该MVPN的其他PE的子集将接收这些消息。每个PE每个MVPN可能有任意数量的S-PMSI。实例化给定S-PMSI的P隧道可携带来自多个S-PMSI的数据。
In later sections, we describe the role played by these different kinds of PMSIs. We will use the term "I-PMSI" when we are not distinguishing between "MI-PMSIs" and "UI-PMSIs".
在后面的章节中，我们将描述这些不同类型的PMSI所扮演的角色。当我们不区分“MI PMSI”和“UI PMSI”时，我们将使用术语“I-PMSI”。
The P-tunnels that are used to instantiate PMSIs will be referred to as "P-tunnels". A number of different tunnel setup techniques can be used to create the P-tunnels that instantiate the PMSIs. Among these are the following:
用于实例化PMSI的P隧道将被称为“P隧道”。许多不同的隧道设置技术可用于创建实例化PMSI的P隧道。其中包括：
- PIM
- PIM
A PMSI can be instantiated as (a set of) Multicast Distribution trees created by the PIM P-instance ("P-trees").
PMSI可以实例化为PIM P-instance创建的（一组）多播分发树（“P-trees”）。
The multicast distribution trees that instantiate I-PMSIs may be either shared trees or source-specific trees.
实例化I-PMSIs的多播分发树可以是共享树或源特定树。
This document (along with [MVPN-BGP]) specifies procedures for identifying a particular (C-S,C-G) flow and assigning it to a particular S-PMSI. Such an S-PMSI is most naturally instantiated as a source-specific tree.
本文件（以及[MVPN-BGP]）规定了识别特定（C-S、C-G）流并将其分配给特定S-PMSI的程序。这样的S-PMSI最自然地被实例化为特定于源的树。
The use of shared trees (including bidirectional trees) to instantiate S-PMSIs is outside the scope of this document.
使用共享树（包括双向树）实例化S-PMSI不在本文档范围内。
The use of PIM-DM to create P-tunnels is not supported.
不支持使用PIM-DM创建P隧道。
P-tunnels may be shared by multiple MVPNs (i.e., a given P-tunnel may be the instantiation of multiple PMSIs), as long as the tunnel encapsulation provides some means of demultiplexing the data traffic by MVPN.
P隧道可以由多个MVPN共享（即，给定的P隧道可以是多个pmsi的实例），只要隧道封装提供了一些通过MVPN解复用数据通信的方法。
- mLDP
- mLDP
mLDP Point-to-Multipoint (P2MP) LSPs or Multipoint-to-Multipoint (MP2MP) LSPs can be used to instantiate I-PMSIs.
mLDP点对多点（P2MP）LSP或多点对多点（MP2MP）LSP可用于实例化I-PMSI。
An S-PMSI or a UI-PMSI could be instantiated as a single mLDP P2MP LSP, whereas an MI-PMSI would have to be instantiated as a set of such LSPs (each PE in the MVPN being the root of one such LSP) or as a single MP2MP LSP.
S-PMSI或UI-PMSI可以实例化为单个mLDP P2MP LSP，而MI-PMSI必须实例化为一组此类LSP（MVPN中的每个PE是一个此类LSP的根）或单个MP2MP LSP。
Procedures for sharing MP2MP LSPs across multiple MVPNs are outside the scope of this document.
跨多个MVPN共享MP2MP LSP的程序不在本文档的范围内。
The use of MP2MP LSPs to instantiate S-PMSIs is outside the scope of this document.
使用MP2MP LSP实例化S-PMSI不在本文件范围内。
Section 11.2.3 discusses a way of using a partial mesh of MP2MP LSPs to instantiate a PMSI. However, a full specification of the necessary procedures is outside the scope of this document.
第11.2.3节讨论了使用MP2MP LSP部分网格实例化PMSI的方法。但是，必要程序的完整规范不在本文件范围内。
- RSVP-TE
- RSVP-TE
A PMSI may be instantiated as one or more RSVP-TE Point-to-Multipoint (P2MP) LSPs. An S-PMSI or a UI-PMSI would be instantiated as a single RSVP-TE P2MP LSP, whereas a Multidirectional Inclusive PMSI would be instantiated as a set of such LSPs, one for each PE in the MVPN. RSVP-TE P2MP LSPs can be shared across multiple MVPNs.
PMSI可以实例化为一个或多个RSVP-TE点对多点（P2MP）LSP。S-PMSI或UI-PMSI将被实例化为单个RSVP-TE P2MP LSP，而多向包容性PMSI将被实例化为一组此类LSP，MVPN中的每个PE一个LSP。RSVP-TE P2MP LSP可跨多个MVPN共享。
- A Mesh of Unicast P-Tunnels.
- 单播P隧道的网格。
If a PMSI is implemented as a mesh of unicast P-tunnels, a PE wishing to transmit a packet through the PMSI would replicate the packet and send a copy to each of the other PEs.
如果PMSI被实现为单播P隧道的网格，则希望通过PMSI传输分组的PE将复制该分组并向其他每个PE发送副本。
An MI-PMSI for a given MVPN can be instantiated as a full mesh of unicast P-tunnels among that MVPN's PEs. A UI-PMSI or an S-PMSI can be instantiated as a partial mesh.
给定MVPN的MI-PMSI可以实例化为该MVPN的PE之间的单播P隧道的完整网格。UI-PMSI或S-PMSI可以实例化为部分网格。
It can be seen that each method of implementing PMSIs has its own area of applicability. Therefore, this specification allows for the use of any of these methods. At first glance, this may seem like an overabundance of options. However, the history of multicast development and deployment should make it clear that there is no one option that is always acceptable. The use of segmented inter-AS trees does allow each SP to select the option that it finds most applicable in its own environment, without causing any other SP to choose that same option.
可以看出，实施PMSIs的每种方法都有自己的适用范围。因此，本规范允许使用这些方法中的任何一种。乍一看，这似乎有太多的选择。然而，多播开发和部署的历史应该清楚地表明，没有一种选择总是可以接受的。使用分段的内部AS树确实允许每个SP选择在其自身环境中最适用的选项，而不会导致任何其他SP选择相同的选项。
SPECIFYING THE CONDITIONS UNDER WHICH A PARTICULAR TREE-BUILDING METHOD IS APPLICABLE IS OUTSIDE THE SCOPE OF THIS DOCUMENT.
指定特定树木建造方法适用的条件超出了本文件的范围。
The choice of the tunnel technique belongs to the sender router and is a local policy decision of that router. The procedures defined throughout this document do not mandate that the same tunnel technique be used for all P-tunnels going through a given provider backbone. However, it is expected that any tunnel technique that can be used by a PE for a particular MVPN is also supported by all the other PEs having VRFs for the MVPN. Moreover, the use of ingress replication by any PE for an MVPN implies that all other PEs MUST use ingress replication for this MVPN.
隧道技术的选择属于发送方路由器，是该路由器的本地策略决定。本文件中定义的程序并不要求对通过给定提供商主干的所有P-隧道使用相同的隧道技术。然而，可以预期的是，PE可用于特定MVPN的任何隧道技术也会受到具有MVPN VRF的所有其他PE的支持。此外，任何PE对MVPN使用入口复制意味着所有其他PE必须对此MVPN使用入口复制。
Each PE supporting a particular MVPN must have a way of discovering the following information:
支持特定MVPN的每个PE必须有一种发现以下信息的方法：
- The set of other PEs in its AS that are attached to sites of that MVPN, and the set of other ASes that have PEs attached to sites of that MVPN. However, if non-segmented inter-AS trees are used (see Section 8.1), then each PE needs to know the entire set of PEs attached to sites of that MVPN.
- its AS中附加到该MVPN站点的其他PE集，以及具有附加到该MVPN站点的PE的其他AS集。但是，如果使用非分段的内部AS树（见第8.1节），则每个PE需要知道连接到该MVPN站点的整个PE集。
- If segmented inter-AS trees are to be used, the set of border routers in its AS that support inter-AS connectivity for that MVPN.
- 如果要使用分段的内部AS树，则其AS中支持该MVPN的内部AS连接的边界路由器集。
- If the MVPN is configured to use an MI-PMSI, the information needed to set up and to use the P-tunnels instantiating the MI-PMSI.
- 如果MVPN配置为使用MI-PMSI，则需要提供设置和使用实例化MI-PMSI的P隧道所需的信息。
- For each other PE, whether the PE supports Aggregate Trees for the MVPN, and if so, the demultiplexing information that must be provided so that the other PE can determine whether a packet that it received on an Aggregate Tree belongs to this MVPN.
- 对于每个其他PE，PE是否支持MVPN的聚合树，如果支持，则必须提供解复用信息，以便其他PE可以确定其在聚合树上接收的数据包是否属于该MVPN。
In some cases, the information above is provided by means of the BGP-based auto-discovery procedures discussed in Section 4 of this document and in Section 9 of [MVPN-BGP]. In other cases, this information is provided after discovery is complete, by means of procedures discussed in Section 7.4. In either case, the information that is provided must be sufficient to enable the PMSI to be bound to the identified P-tunnel, to enable the P-tunnel to be created if it does not already exist, and to enable the different PMSIs that may travel on the same P-tunnel to be properly demultiplexed.
在某些情况下，上述信息通过本文件第4节和[MVPN-BGP]第9节中讨论的基于BGP的自动发现程序提供。在其他情况下，通过第7.4节讨论的程序，在发现完成后提供该信息。在任何一种情况下，所提供的信息必须足以使PMSI绑定到所识别的P隧道，如果P隧道不存在，则能够创建P隧道，并且能够使可能在同一P隧道上移动的不同PMSI正确解复用。
If an MVPN uses an MI-PMSI, then the information needed to identify the P-tunnels that instantiate the MI-PMSI has to be known to the PEs attached to the MVPN before any data can be transmitted on the MI-PMSI. This information is either statically configured or auto-discovered (see Section 4). The actual process of constructing the P-tunnels (e.g., via PIM, RSVP-TE, or mLDP) SHOULD occur as soon as this information is known.
如果MVPN使用MI-PMSI，则在MI-PMSI上传输任何数据之前，连接到MVPN的PE必须知道识别实例化MI-PMSI的P隧道所需的信息。此信息可以是静态配置的，也可以是自动发现的（参见第4节）。一旦知道该信息，应立即进行P型隧道的实际施工过程（例如，通过PIM、RSVP-TE或mLDP）。
When MI-PMSIs are used, they may serve as the default method of carrying C-multicast data traffic. When we say that an MI-PMSI is the "default" method of carrying C-multicast data traffic for a particular MVPN, we mean that it is not necessary to use any special control procedures to bind a particular C-flow to the MI-PMSI; any C-flows that have not been bound to other PMSIs will be assumed to travel through the MI-PMSI.
当使用MI-PMSIs时，它们可以作为承载C-multicast数据流量的默认方法。当我们说MI-PMSI是承载特定MVPN的C多播数据流量的“默认”方法时，我们的意思是不需要使用任何特殊的控制过程来将特定C流绑定到MI-PMSI；任何未绑定到其他PMSI的C流将假定通过MI-PMSI。
There is no requirement to use MI-PMSIs as the default method of carrying C-flows. It is possible to adopt a policy in which all C-flows are carried on UI-PMSIs or S-PMSIs. In this case, if an MI-PMSI is not used for carrying routing information, it is not needed at all.
无需将MI PMSIs用作承载C流的默认方法。可以采用一种策略，其中所有C流都在UI PMSIs或S-PMSIs上进行。在这种情况下，如果MI-PMSI不用于承载路由信息，则根本不需要它。
Even when an MI-PMSI is used as the default method of carrying an MVPN's C-flows, if a particular C-flow has certain characteristics, it may be desirable to migrate it from the MI-PMSI to an S-PMSI. These characteristics, as well as the procedures for migrating a C-flow from an MI-PMSI to an S-PMSI, are discussed in Section 7.
即使当MI-PMSI用作承载MVPN的C流的默认方法时，如果特定C流具有某些特征，则可能希望将其从MI-PMSI迁移到s-PMSI。第7节讨论了这些特性以及将C流从MI-PMSI迁移到S-PMSI的过程。
Sometimes a set of C-flows are traveling the same, shared, C-tree (e.g., either unidirectional or bidirectional), and it may be desirable to move the whole set of C-flows as a unit to an S-PMSI. Procedures for doing this are outside the scope of this specification.
有时，一组C-流在相同的、共享的C-树上移动（例如，单向或双向），并且可能希望将整个C-流集作为一个单元移动到S-PMSI。执行此操作的程序不在本规范的范围内。
Some of the procedures for transmitting C-multicast routing information among the PEs require that the routing information be sent over an MI-PMSI. Other procedures do not use an MI-PMSI to transmit the C-multicast routing information.
在PEs之间传输C多播路由信息的一些过程要求通过MI-PMSI发送路由信息。其他过程不使用MI-PMSI来传输C多播路由信息。
For a given MVPN, whether an MI-PMSI is used to carry C-multicast routing information is independent from whether an MI-PMSI is used as the default method of carrying the C-multicast data traffic.
对于给定的MVPN，MI-PMSI是否用于承载C多播路由信息与MI-PMSI是否用作承载C多播数据流量的默认方法无关。
As previously stated, it is possible to send all C-flows on a set of S-PMSIs, omitting any usage of I-PMSIs. This prevents PEs from receiving data that they don't need, at the cost of requiring additional P-tunnels, and additional signaling to bind the C-flows to P-tunnels. Cost-effective instantiation of S-PMSIs is likely to
如前所述，可以在一组S-PMSI上发送所有C流，而不使用I-PMSI。这防止PEs接收他们不需要的数据，代价是需要额外的P隧道和额外的信令将C流绑定到P隧道。具有成本效益的S-PMSI实例很可能
require Aggregate P-trees, which, in turn, makes it necessary for the transmitting PE to know which PEs need to receive which multicast streams. This is known as "explicit tracking", and the procedures to enable explicit tracking may themselves impose a cost. This is further discussed in Section 7.4.1.2.
需要聚合P-树，这反过来使得发送PE需要知道哪些PE需要接收哪些多播流。这被称为“显式跟踪”，实现显式跟踪的过程本身可能会带来成本。第7.4.1.2节对此进行了进一步讨论。
As a PE attached to a given MVPN receives C-Join/Prune messages from its CEs in that MVPN, it must convey the information contained in those messages to other PEs that are attached to the same MVPN.
当连接到给定MVPN的PE从该MVPN中的CE接收C-Join/Prune消息时，它必须将这些消息中包含的信息传递给连接到同一MVPN的其他PE。
There are several different methods for doing this. As these methods are not interoperable, the method to be used for a particular MVPN must be either configured or discovered as part of the auto-discovery process.
有几种不同的方法可以做到这一点。由于这些方法不可互操作，用于特定MVPN的方法必须作为自动发现过程的一部分进行配置或发现。
If the set of PEs attached to a given MVPN are connected via an MI-PMSI, the PEs can form "normal" PIM adjacencies with each other. Since the MI-PMSI functions as a broadcast network, the standard PIM procedures for forming and maintaining adjacencies over a LAN can be applied.
如果连接到给定MVPN的一组PE通过MI-PMSI连接，则这些PE可以相互形成“正常”的PIM邻接。由于MI-PMSI起到广播网络的作用，因此可以应用在LAN上形成和维护邻接的标准PIM程序。
As a result, the C-Join/Prune messages that a PE receives from a CE can be multicast to all the other PEs of the MVPN. PIM "Join suppression" can be enabled and the PEs can send Asserts as needed.
因此，PE从CE接收的C-Join/Prune消息可以多播到MVPN的所有其他PE。PIM“加入抑制”可以启用，PEs可以根据需要发送断言。
This procedure is fully specified in Section 5.2.
第5.2节详细说明了该程序。
The procedure of the previous Section has the following disadvantages:
上一节的程序有以下缺点：
- Periodic Hello messages must be sent by all PEs.
- 所有PEs必须定期发送Hello消息。
Standard PIM procedures require that each PE in a particular MVPN periodically multicast a Hello to all the other PEs in that MVPN. If the number of MVPNs becomes very large, sending and receiving these Hellos can become a substantial overhead for the PE routers.
标准的PIM过程要求特定MVPN中的每个PE定期多播一个Hello到该MVPN中的所有其他PE。如果MVPN的数量变得非常大，发送和接收这些HELLO可能会成为PE路由器的一个巨大开销。
- Periodic retransmission of C-Join/Prune messages.
- C-Join/Prune消息的定期重新传输。
PIM is a "soft-state" protocol, in which reliability is assured through frequent retransmissions (refresh) of control messages. This too can begin to impose a large overhead on the PE routers as the number of MVPNs grows.
PIM是一种“软状态”协议，通过控制消息的频繁重传（刷新）来确保可靠性。随着MVPN数量的增加，这也会给PE路由器带来很大的开销。
The first of these disadvantages is easily remedied. The reason for the periodic PIM Hellos is to ensure that each PIM speaker on a LAN knows who all the other PIM speakers on the LAN are. However, in the context of MVPN, PEs in a given MVPN can learn the identities of all the other PEs in the MVPN by means of the BGP-based auto-discovery procedure of Section 4. In that case, the periodic Hellos would serve no function and could simply be eliminated. (Of course, this does imply a change to the standard PIM procedures.)
第一个缺点很容易弥补。定期进行PIM问候的原因是确保LAN上的每个PIM扬声器都知道LAN上所有其他PIM扬声器是谁。然而，在MVPN的上下文中，给定MVPN中的PE可以通过第4节中基于BGP的自动发现程序学习MVPN中所有其他PE的身份。在这种情况下，周期性的Hello没有任何作用，可以简单地消除。（当然，这确实意味着标准PIM程序的改变。）
When Hellos are suppressed, we may speak of "lightweight PIM peering".
当他被抑制时，我们可以说“轻量级PIM对等”。
The periodic refresh of the C-Join/Prune messages is not as simple to eliminate. If and when "refresh reduction" procedures are specified for PIM, it may be useful to incorporate them, so as to make the lightweight PIM peering procedures even more lightweight.
C-Join/Prune消息的定期刷新并不像消除这样简单。如果并且当为PIM指定“刷新减少”过程时，合并它们可能是有用的，以便使轻量级PIM对等过程更加轻量级。
Lightweight PIM peering is not specified in this document.
本文档中未指定轻型PIM对等。
PIM does not require that the C-Join/Prune messages that a PE receives from a CE to be multicast to all the other PEs; it allows them to be unicast to a single PE, the one that is upstream on the path to the root of the multicast tree mentioned in the Join/Prune message. Note that when the C-Join/Prune messages are unicast, there is no such thing as "Join suppression". Therefore, PIM Refresh Reduction may be considered to be a prerequisite for the procedure of unicasting the C-Join/Prune messages.
PIM不要求PE从CE接收的C-Join/Prune消息多播到所有其他PE；它允许它们单播到单个PE，该PE位于连接/修剪消息中提到的多播树根路径的上游。请注意，当C-Join/Prune消息是单播的时，没有“连接抑制”这样的事情。因此，PIM刷新减少可以被认为是单播C-Join/Prune消息的过程的先决条件。
When the C-Join/Prune messages are unicast, they are not transmitted on a PMSI at all. Note that the procedure of unicasting the C-Join/Prune messages is different than the procedure of transmitting the C-Join/Prune messages on an MI-PMSI that is instantiated as a mesh of unicast P-tunnels.
当C-Join/Prune消息是单播的时，它们根本不会在PMSI上传输。注意，单播C-Join/Prune消息的过程不同于在被实例化为单播P-tunnel的网格的MI-PMSI上传输C-Join/Prune消息的过程。
If there are multiple PEs that can be used to reach a given C-source, procedures described in Sections 5.1 and 9 MUST be used to ensure that duplicate packets do not get delivered.
如果有多个PEs可用于到达给定的C源，则必须使用第5.1节和第9节中描述的程序，以确保不会发送重复的数据包。
Procedures for unicasting the PIM control messages are not further specified in this document.
本文件中未进一步规定单播PIM控制消息的程序。
It is possible to use BGP to carry C-multicast routing information from PE to PE, dispensing entirely with the transmission of C-Join/Prune messages from PE to PE. This is discussed in Section 5.3 and fully specified in [MVPN-BGP].
可以使用BGP将C-multicast路由信息从PE传送到PE，完全不需要将C-Join/Prune消息从PE传送到PE。第5.3节对此进行了讨论，并在[MVPN-BGP]中进行了详细说明。
BGP-based auto-discovery is done by means of a new address family, the MCAST-VPN address family. (This address family also has other uses, as will be seen later.) Any PE that attaches to an MVPN must issue a BGP Update message containing an NLRI ("Network Layer Reachability Information" element) in this address family, along with a specific set of attributes. In this document, we specify the information that must be contained in these BGP Updates in order to provide auto-discovery. The encoding details, along with the complete set of detailed procedures, are specified in a separate document [MVPN-BGP].
基于BGP的自动发现是通过一个新的地址系列MCAST-VPN地址系列来完成的。（此地址族还有其他用途，稍后将看到。）任何连接到MVPN的PE都必须发出一条BGP更新消息，其中包含此地址族中的NLRI（“网络层可达性信息”元素）以及一组特定属性。在本文档中，我们指定了这些BGP更新中必须包含的信息，以便提供自动发现。编码细节以及完整的详细程序集在单独的文件[MVPN-BGP]中规定。
This section specifies the intra-AS BGP-based auto-discovery procedures. When segmented inter-AS trees are used, additional procedures are needed, as specified in [MVPN-BGP]. (When segmented inter-AS trees are not used, the inter-AS procedures are almost identical to the intra-AS procedures.)
本节指定基于BGP的内部自动发现过程。如[MVPN-BGP]所述，当使用分段的内部AS树时，需要额外的程序。（不使用分段的内部AS树时，内部AS过程几乎与内部AS过程相同。）
BGP-based auto-discovery uses a particular kind of MCAST-VPN route known as an "auto-discovery route", or "A-D route". In particular, it uses two kinds of "A-D routes": the "Intra-AS I-PMSI A-D route" and the "Inter-AS I-PMSI A-D route". (There are also additional kinds of A-D routes, such as the Source Active A-D routes, which are used for purposes that go beyond auto-discovery. These are discussed in subsequent sections.)
基于BGP的自动发现使用一种特殊的MCAST-VPN路由，称为“自动发现路由”或“a-D路由”。特别地，它使用两种“A-D路由”：内部AS I-PMSI A-D路由和内部AS I-PMSI A-D路由。（还有其他类型的A-D路由，例如源活动A-D路由，用于自动发现以外的目的。这些将在后续章节中讨论。）
The Inter-AS I-PMSI A-D route is used only when segmented inter-AS P-tunnels are used, as specified in [MVPN-BGP].
按照[MVPN-BGP]中的规定，仅当使用分段AS间P隧道时，才使用AS间I-PMSI A-D路由。
The "Intra-AS I-PMSI A-D route" is originated by the PEs that are (directly) connected to the site(s) of an MVPN. It is distributed to other PEs that attach to sites of the MVPN. If segmented inter-AS P-tunnels are used, then the Intra-AS I-PMSI A-D routes are not distributed outside the AS where they originate; if segmented inter-AS P-tunnels are not used, then the Intra-AS I-PMSI A-D routes are, despite their name, distributed to all PEs attached to the VPN, no matter what AS the PEs are in.
“内部AS I-PMSI A-D路由”由（直接）连接到MVPN站点的PE发起。它被分发到附加到MVPN站点的其他PE。如果使用分段的AS间P隧道，则AS内I-PMSI A-D路由不会分布在其起源的AS外；如果不使用分段的AS间P隧道，则AS内I-PMSI A-D路由（无论其名称如何）将分发给连接到VPN的所有PE，无论这些PE处于何种状态。
The NLRI of an Intra-AS I-PMSI A-D route must contain the following information:
内部AS I-PMSI A-D路由的NLRI必须包含以下信息：
- The route type (i.e., Intra-AS I-PMSI A-D route).
- 路由类型（即，内部AS i-PMSI A-D路由）。
- The IP address of the originating PE.
- 发起PE的IP地址。
- An RD ("Route Distinguisher", [RFC4364]) configured locally for the MVPN. This is an RD that can be prepended to that IP address to form a globally unique VPN-IP address of the PE.
- 为MVPN本地配置的RD（“路由识别器”[RFC4364]）。这是一个RD，可以预先添加到该IP地址，以形成PE的全局唯一VPN-IP地址。
Intra-AS I-PMSI A-D routes carry the following attributes:
内部AS I-PMSI A-D路由具有以下属性：
- Route Target Extended Communities attribute.
- 路由目标扩展社区属性。
One or more of these MUST be carried by each Intra-AS I-PMSI A-D route. If any other PE has one of these Route Targets configured for import into a VRF, it treats the advertising PE as a member in the MVPN to which the VRF belongs. This allows each PE to discover the PEs that belong to a given MVPN. More specifically, it allows a PE in the Receiver Sites set to discover the PEs in the Sender Sites set of the MVPN, and the PEs in the Sender Sites set of the MVPN to discover the PEs in the Receiver Sites set of the MVPN. The PEs in the Receiver Sites set would be configured to import the Route Targets advertised in the BGP A-D routes by PEs in the Sender Sites set. The PEs in the Sender Sites set would be configured to import the Route Targets advertised in the BGP A-D routes by PEs in the Receiver Sites set.
每个内部AS I-PMSI A-D路由必须携带其中一个或多个。如果任何其他PE配置了其中一个路由目标以导入VRF，则它将广告PE视为VRF所属MVPN中的成员。这允许每个PE发现属于给定MVPN的PE。更具体地说，它允许接收方站点集中的PE发现MVPN的发送方站点集中的PE，并允许MVPN的发送方站点集中的PE发现MVPN的接收方站点集中的PE。接收方站点集中的PEs将配置为导入发送方站点集中的PEs在BGP A-D路由中公布的路由目标。发送方站点集中的PEs将配置为导入接收方站点集中PEs在BGP A-D路由中公布的路由目标。
- PMSI Tunnel attribute.
- PMSI隧道属性。
This attribute is present whenever the MVPN uses an MI-PMSI or when it uses a UI-PMSI rooted at the originating router. It contains the following information:
每当MVPN使用MI-PMSI或当它使用源路由器上的UI-PMSI时，该属性就会出现。它包含以下信息：
* tunnel technology, which may be one of the following:
* 隧道技术，可能是以下之一：
+ Bidirectional multicast tree created by BIDIR-PIM,
+ BIDIR-PIM创建的双向多播树，
+ Source-specific multicast tree created by PIM-SM, supporting the SSM service model,
+ PIM-SM创建的源特定多播树，支持SSM服务模型，
+ Set of trees (one shared tree and a set of source trees) created by PIM-SM using the ASM service model,
+ PIM-SM使用ASM服务模型创建的一组树（一个共享树和一组源树），
+ Point-to-multipoint LSP created by RSVP-TE,
+ 由RSVP-TE创建的点对多点LSP，
+ Point-to-multipoint LSP created by mLDP,
+ 由mLDP创建的点对多点LSP，
+ multipoint-to-multipoint LSP created by mLDP
+ 由mLDP创建的多点对多点LSP
+ unicast tunnel
+ 单播隧道
* P-tunnel identifier
* P隧道标识符
Before a P-tunnel can be constructed to instantiate the I-PMSI, the PE must be able to create a unique identifier for the tunnel. The syntax of this identifier depends on the tunnel technology used.
在构造P隧道以实例化I-PMSI之前，PE必须能够为隧道创建唯一标识符。此标识符的语法取决于所使用的隧道技术。
Each PE attaching to a given MVPN must be configured with information specifying the allowable encapsulations to use for that MVPN, as well as the particular one of those encapsulations that the PE is to identify in the PMSI Tunnel attribute of the Intra-AS I-PMSI A-D routes that it originates.
附加到给定MVPN的每个PE必须配置有指定用于该MVPN的允许封装的信息，以及PE要在其发起的帧内as I-PMSI a-D路由的PMSI隧道属性中标识的特定封装。
* Multi-VPN aggregation capability and demultiplexor value.
* 多VPN聚合功能和解复用器值。
This specifies whether the P-tunnel is capable of aggregating I-PMSIs from multiple MVPNs. This will affect the encapsulation used. If aggregation is to be used, a demultiplexor value to be carried by packets for this particular MVPN must also be specified. The demultiplexing mechanism and signaling procedures are described in Section 6.
这指定P-tunnel是否能够从多个MVPN聚合I-PMSI。这将影响所使用的封装。如果要使用聚合，则还必须指定此特定MVPN的数据包要携带的解复用器值。解复用机制和信令程序在第6节中描述。
- PE Distinguisher Labels Attribute
- PE区分器标签属性
Sometimes it is necessary for one PE to advertise an upstream-assigned MPLS label that identifies another PE. Under certain circumstances to be discussed later, a PE that is the root of a multicast P-tunnel will bind an MPLS label value to one or more of the PEs that belong to the P-tunnel, and it will distribute these label bindings using Intra-AS I-PMSI A-D routes.
有时，一个PE需要公布上游分配的MPLS标签，该标签标识另一个PE。在稍后讨论的特定情况下，作为多播P隧道的根的PE将MPLS标签值绑定到属于P隧道的一个或多个PE，并且它将使用帧内AS I-PMSI a-D路由分发这些标签绑定。
Specification of when this must be done is provided in Sections 6.4.4 and 11.2.2. We refer to these as "PE Distinguisher Labels".
第6.4.4节和第11.2.2节规定了何时必须进行此操作。我们将其称为“PE识别标签”。
Note that, as specified in [MPLS-UPSTREAM-LABEL], PE Distinguisher Label values are unique only in the context of the IP address identifying the root of the P-tunnel; they are not necessarily unique per tunnel.
注意，如[MPLS-UPSTREAM-LABEL]中所述，PE标识符标签值仅在标识P隧道根的IP地址上下文中是唯一的；它们不一定每个隧道都是唯一的。
As a PE attached to a given MVPN receives C-Join/Prune messages from its CEs in that MVPN, it must convey the information contained in those messages to other PEs that are attached to the same MVPN. This is known as the "PE-PE transmission of C-multicast routing information".
当连接到给定MVPN的PE从该MVPN中的CE接收C-Join/Prune消息时，它必须将这些消息中包含的信息传递给连接到同一MVPN的其他PE。这被称为“C多播路由信息的PE-PE传输”。
This section specifies the procedures used for PE-PE transmission of C-multicast routing information. Not every procedure mentioned in Section 3.4 is specified here. Rather, this section focuses on two particular procedures:
本节规定了C-多播路由信息的PE-PE传输过程。此处并未规定第3.4节中提到的所有程序。相反，本节侧重于两个特定程序：
- Full PIM Peering.
- 全PIM窥视。
This procedure is fully specified herein.
此程序在本文中有详细说明。
- Use of BGP to distribute C-multicast routing
- BGP在分布式C组播路由中的应用
This procedure is described herein, but the full specification appears in [MVPN-BGP].
本文描述了该程序，但完整规范见[MVPN-BGP]。
Those aspects of the procedures that apply to both of the above are also specified fully herein.
适用于上述两个方面的程序的那些方面也在本文中完全规定。
Specification of other procedures is outside the scope of this document.
其他程序的规范不在本文件范围内。
When a PE receives a C-Join/Prune message from a CE, the message identifies a particular multicast flow as belonging either to a source-specific tree (S,G) or to a shared tree (*,G). Throughout this section, we use the term "C-root" to refer to S, in the case of a source-specific tree, or to the Rendezvous Point (RP) for G, in the case of (*,G). If the route to the C-root is across the VPN backbone, then the PE needs to find the "Upstream Multicast Hop" (UMH) for the (S,G) or (*,G) flow. The UMH is either the PE at which (S,G) or (*,G) data packets enter the VPN backbone or the Autonomous System Border Router (ASBR) at which those data packets enter the local AS when traveling through the VPN backbone. The process of finding the upstream multicast hop for a given C-root is known as "upstream multicast hop selection".
当PE从CE接收到C-Join/Prune消息时，该消息将特定多播流标识为属于源特定树（S，G）或共享树（*，G）。在本节中，我们使用术语“C根”来表示源特定树中的S，或（*，G）中的G的集合点（RP）。如果到C根的路由跨越VPN主干，则PE需要为（S，G）或（*，G）流找到“上游多播跃点”（UMH）。UMH是（S，G）或（*，G）数据包进入VPN主干的PE，或者是这些数据包在通过VPN主干时进入本地AS的自治系统边界路由器（ASBR）。查找给定C根的上游多播跳的过程称为“上游多播跳选择”。
In the simplest case, the PE does the upstream hop selection by looking up the C-root in the unicast VRF associated with the PE-CE interface over which the C-Join/Prune message was received. The route that matches the C-root will contain the information needed to select the UMH.
在最简单的情况下，PE通过查找与接收C-Join/Prune消息的PE-CE接口相关联的单播VRF中的C-root来进行上游跳选择。与C根匹配的路由将包含选择UMH所需的信息。
However, in some cases, the CEs may be distributing to the PEs a special set of routes that are to be used exclusively for the purpose of upstream multicast hop selection, and not used for unicast routing at all. For example, when BGP is the CE-PE unicast routing protocol, the CEs may be using Subsequent Address Family Identifier 2 (SAFI 2) to distribute a special set of routes that are to be used for, and only for, upstream multicast hop selection. When OSPF [OSPF] is the CE-PE routing protocol, the CE may use an MT-ID (Multi-Topology Identifier) [OSPF-MT] of 1 to distribute a special set of routes that are to be used for, and only for, upstream multicast hop selection. When a CE uses one of these mechanisms to distribute to a PE a special set of routes to be used exclusively for upstream multicast hop selection, these routes are distributed among the PEs using SAFI 129, as described in [MVPN-BGP]. Whether the routes used for upstream multicast hop selection are (a) the "ordinary" unicast routes or (b) a special set of routes that are used exclusively for upstream multicast hop selection is a matter of policy. How that policy is chosen, deployed, or implemented is outside the scope of this document. In the following, we will simply refer to the set of routes that are used for upstream multicast hop selection, the "Eligible UMH routes", with no presumptions about the policy by which this set of routes was chosen.
然而，在某些情况下，CEs可能正在向PEs分发一组特殊的路由，这些路由专门用于上游多播跳选择，而根本不用于单播路由。例如，当BGP是CE-PE单播路由协议时，CE可以使用后续地址族标识符2（SAFI 2）来分发用于且仅用于上游多播跳选择的一组特殊路由。当OSPF[OSPF]是CE-PE路由协议时，CE可以使用MT-ID（多拓扑标识符）[OSPF-MT]为1来分发用于且仅用于上游多播跳选择的一组特殊路由。当CE使用这些机制中的一种来向PE分发一组专门用于上游多播跳选择的特殊路由时，这些路由使用SAFI 129在PE之间分发，如[MVPN-BGP]中所述。用于上行多播跳选择的路由是（a）“普通”单播路由还是（b）专门用于上行多播跳选择的一组特殊路由，这是一个策略问题。如何选择、部署或实施该策略超出了本文档的范围。在下文中，我们将简单地提及用于上游多播跳选择的路由集，即“合格的UMH路由”，而不假定选择这组路由的策略。
Every route that is eligible for UMH selection SHOULD carry a VRF Route Import Extended Community [MVPN-BGP]. However, if BGP is used to distribute C-multicast routing information, or if the route is from a VRF that belongs to a multi-AS VPN as described in option b of Section 10 of [RFC4364], then the route MUST carry a VRF Route Import Extended Community. This attribute identifies the PE that originated the route.
每个符合UMH选择条件的路由都应携带一个VRF路由导入扩展社区[MVPN-BGP]。但是，如果BGP用于分发C多播路由信息，或者如果该路由来自属于[RFC4364]第10节选项b中所述的多AS VPN的VRF，则该路由必须携带VRF路由导入扩展社区。此属性标识发起路由的PE。
If BGP is used for carrying C-multicast routes, OR if "Segmented inter-AS Tunnels" are used, then every UMH route MUST also carry a Source AS Extended Community [MVPN-BGP].
如果BGP用于承载C-多播路由，或者如果使用“分段的内部AS隧道”，则每个UMH路由还必须承载一个源作为扩展社区[MVPN-BGP]。
These two attributes are used in the upstream multicast hop selection procedures described below.
这两个属性用于下面描述的上行多播跳选择过程。
The first step in selecting the upstream multicast hop for a given C-root is to select the Upstream PE router for that C-root.
为给定C根选择上行多播跃点的第一步是为该C根选择上行PE路由器。
The PE that received the C-Join message from a CE looks in the VRF corresponding to the interfaces over which the C-Join was received. It finds the Eligible UMH route that is the best match for the C-root specified in that C-Join. Call this the "Installed UMH Route".
从CE接收C-Join消息的PE查看与接收C-Join的接口对应的VRF。它查找符合条件的UMH路由，该路由是该C-Join中指定的C-root的最佳匹配。称之为“已安装的UMH路由”。
Note that the outgoing interface of the Installed UMH Route may be one of the interfaces associated with the VRF, in which case the upstream multicast hop is a CE and the route to the C-root is not across the VPN backbone.
注意，已安装的UMH路由的传出接口可以是与VRF相关联的接口之一，在这种情况下，上游多播跳是CE，到C根的路由不跨越VPN主干。
Consider the set of all VPN-IP routes that (a) are eligible to be imported into the VRF (as determined by their Route Targets), (b) are eligible to be used for upstream multicast hop selection, and (c) have exactly the same IP prefix (not necessarily the same RD) as the installed UMH route.
考虑一组所有VPN-IP路由（A）有资格被导入到VRF（由它们的路由目标确定），（B）有资格被用于上游多播跳选，并且（c）具有与安装的UMH路由完全相同的IP前缀（不一定是相同的RD）。
For each route in this set, determine the corresponding Upstream PE and Upstream RD. If a route has a VRF Route Import Extended Community, the route's Upstream PE is determined from it. If a route does not have a VRF Route Import Extended Community, the route's Upstream PE is determined from the route's BGP Next Hop. In either case, the Upstream RD is taken from the route's NLRI.
对于该集合中的每个路由，确定相应的上游PE和上游RD。如果路由具有VRF路由导入扩展社区，则路由的上游PE由其确定。如果路由没有VRF路由导入扩展社区，则路由的上游PE由路由的BGP下一跳确定。在任何一种情况下，上游RD均取自路线的NLRI。
This results in a set of triples of <route, Upstream PE, Upstream RD>.
这导致一组三元组<路由、上游PE、上游RD>。
Call this the "UMH Route Candidate Set". Then, the PE MUST select a single route from the set to be the "Selected UMH Route". The corresponding Upstream PE is known as the "Selected Upstream PE", and the corresponding Upstream RD is known as the "Selected Upstream RD".
称之为“UMH路由候选集”。然后，PE必须从集合中选择一条路由作为“所选UMH路由”。对应的上游PE称为“选定的上游PE”，对应的上游RD称为“选定的上游RD”。
There are several possible procedures that can be used by a PE to select a single route from the candidate set.
PE可以使用几个可能的过程从候选集合中选择单个路由。
The default procedure, which MUST be implemented, is to select the route whose corresponding Upstream PE address is numerically highest, where a 32-bit IP address is treated as a 32-bit unsigned integer. Call this the "default Upstream PE selection". For a given C-root, provided that the routing information used to create the candidate set is stable, all PEs will have the same default Upstream PE selection. (Though different default Upstream PE selections may be chosen during a routing transient.)
必须实现的默认过程是选择其对应的上游PE地址在数字上最高的路由，其中32位IP地址被视为32位无符号整数。称之为“默认上游PE选择”。对于给定的C根，如果用于创建候选集的路由信息是稳定的，则所有PE将具有相同的默认上游PE选择。（尽管在路由过渡期间可能会选择不同的默认上游PE选择。）
An alternative procedure that MUST be implemented, but which is disabled by default, is the following. This procedure ensures that, except during a routing transient, each PE chooses the same Upstream PE for a given combination of C-root and C-G.
必须执行但默认情况下禁用的替代过程如下所示。该程序确保，除了在路由瞬态期间，每个PE为给定的C-root和C-G组合选择相同的上游PE。
1. The PEs in the candidate set are numbered from lowest to highest IP address, starting from 0.
1. 候选集中的PE从最低IP地址到最高IP地址编号，从0开始。
2. The following hash is performed:
2. 执行以下哈希：
- A bytewise exclusive-or of all the bytes in the C-root address and the C-G address is performed.
- 执行C根地址和C-G地址中所有字节的字节异或。
- The result is taken modulo n, where n is the number of PEs in the candidate set. Call this result N.
- 结果取模n，其中n是候选集中PE的数量。把这个结果称为N。
The Selected Upstream PE is then the one that appears in position N in the list of step 1.
然后，所选上游PE是出现在步骤1列表中位置N的PE。
Other hashing algorithms are allowed as well, but not required.
也允许使用其他哈希算法，但不是必需的。
The alternative procedure allows a form of "equal cost load balancing". Suppose, for example, that from egress PEs PE3 and PE4, source C-S can be reached, at equal cost, via ingress PE PE1 or ingress PE PE2. The load balancing procedure makes it possible for PE1 to be the ingress PE for (C-S,C-G1) data traffic while PE2 is the ingress PE for (C-S,C-G2) data traffic.
替代程序允许一种形式的“等成本负载平衡”。例如，假设从出口PEs PE3和PE4，可以通过入口PE PE1或入口PE PE2以相同的成本到达源C-S。负载平衡过程使得PE1可以作为（C-S，C-G1）数据流量的入口PE，而PE2可以作为（C-S，C-G2）数据流量的入口PE。
Another procedure, which SHOULD be implemented, is to use the Installed UMH Route as the Selected UMH Route. If this procedure is used, the result is likely to be that a given PE will choose the Upstream PE that is closest to it, according to the routing in the SP backbone. As a result, for a given C-root, different PEs may choose different Upstream PEs. This is useful if the C-root is an anycast address, and can also be useful if the C-root is in a multihomed site (i.e., a site that is attached to multiple PEs). However, this procedure is more likely to lead to steady state duplication of traffic unless (a) PEs discard data traffic that arrives from the "wrong" Upstream PE or (b) data traffic is carried only in non-aggregated S-PMSIs. This issue is discussed at length in Section 9.
应实施的另一个程序是使用已安装的UMH路由作为选定的UMH路由。如果使用此过程，结果很可能是给定PE将根据SP主干中的路由选择与其最近的上游PE。因此，对于给定的C根，不同的PE可以选择不同的上游PE。如果C-root是选播地址，则此功能非常有用；如果C-root位于多址站点（即，连接到多个PE的站点）中，此功能也非常有用。然而，除非（a）PEs丢弃来自“错误”上游PE的数据流量，或（b）数据流量仅在非聚合S-PMSI中传输，否则此过程更有可能导致流量的稳态复制。第9节详细讨论了这个问题。
General policy-based procedures for selecting the UMH route are allowed but not required, and they are not further discussed in this specification.
允许但不需要选择UMH路由的基于一般策略的程序，本规范中不再进一步讨论这些程序。
In certain cases, the Selected Upstream Multicast Hop is the same as the Selected Upstream PE. In other cases, the Selected Upstream Multicast Hop is the ASBR that is the BGP Next Hop of the Selected UMH Route.
在某些情况下，所选上游多播跃点与所选上游PE相同。在其他情况下，所选上游多播跳是ASBR，它是所选UMH路由的BGP下一跳。
If the Selected Upstream PE is in the local AS, then the Selected Upstream PE is also the Selected Upstream Multicast Hop. This is the case if any of the following conditions holds:
如果选定的上游PE位于本地AS中，则选定的上游PE也是选定的上游多播跃点。如果以下任一条件成立，则为这种情况：
- The Selected UMH Route has a Source AS Extended Community, and the Source AS is the same as the local AS,
- 所选的UMH路由有一个源AS扩展社区，源AS与本地AS相同，
- The Selected UMH Route does not have a Source AS Extended Community, but the route's BGP Next Hop is the same as the Upstream PE.
- 所选UMH路由没有作为扩展社区的源，但该路由的BGP下一跳与上游PE相同。
Otherwise, the Selected Upstream Multicast Hop is an ASBR. The method of determining just which ASBR it is depends on the particular inter-AS signaling method being used (PIM or BGP) and on whether segmented or non-segmented inter-AS tunnels are used. These details are presented in later sections.
否则，所选上行多播跃点是ASBR。确定哪种ASBR的方法取决于所使用的特定AS间信令方法（PIM或BGP），以及是否使用分段或非分段AS间隧道。这些细节将在后面的章节中介绍。
When an MVPN uses an MI-PMSI, the C-instances of that MVPN can treat the MI-PMSI as a LAN interface and form full PIM adjacencies with each other over that LAN interface.
当MVPN使用MI-PMSI时，该MVPN的C实例可以将MI-PMSI视为LAN接口，并通过该LAN接口彼此形成完整的PIM邻接。
The use of PIM when an MI-PMSI is not in use is outside the scope of this document.
未使用MI-PMSI时使用PIM不在本文件范围内。
To form full PIM adjacencies, the PEs execute the standard PIM procedures on the LAN interface, including the generation and processing of PIM Hello, Join/Prune, Assert, DF (Designated Forwarder) election, and other PIM control messages. These are executed independently for each C-instance. PIM "Join suppression" SHOULD be enabled.
为了形成完整的PIM邻接，PEs在LAN接口上执行标准PIM程序，包括生成和处理PIM Hello、Join/Prune、Assert、DF（指定转发器）选择和其他PIM控制消息。这些是为每个C实例独立执行的。应启用PIM“连接抑制”。
All IPv4 PIM C-instance control packets of a particular MVPN are addressed to the ALL-PIM-ROUTERS (224.0.0.13) IP destination address and transmitted over the MI-PMSI of that MVPN. While in transit in the P-network, the packets are encapsulated as required for the particular kind of P-tunnel that is being used to instantiate the
特定MVPN的所有IPv4 PIM C实例控制数据包都发往全PIM路由器（224.0.0.13）IP目标地址，并通过该MVPN的MI-PMSI传输。当在P网络中传输时，根据用于实例化数据包的特定类型的P隧道的需要对数据包进行封装
MI-PMSI. Thus, the C-instance control packets are not processed by the P routers, and MVPN-specific PIM routes can be extended from site to site without appearing in the P routers.
MI-PMSI。因此，P路由器不处理C实例控制分组，并且MVPN特定的PIM路由可以从站点扩展到站点，而不出现在P路由器中。
The handling of IPv6 PIM C-instance control packets will be specified in a follow-on document.
IPv6 PIM C实例控制数据包的处理将在后续文档中指定。
As specified in Section 5.1.2, when PIM is being used to distribute C-multicast routing information, any PE distributing VPN-IP routes that are eligible for use as UMH routes SHOULD include a VRF Route Import Extended Community with each route. For a given VRF, the Global Administrator field of the VRF Route Import Extended Community MUST be set to the same IP address that the PE places in the IP source address field of the PE-PE PIM control messages it originates from that VRF.
如第5.1.2节所述，当PIM被用于分发C-多播路由信息时，任何有资格用作UMH路由的PE分发VPN-IP路由应包括每个路由的VRF路由导入扩展社区。对于给定的VRF，必须将VRF路由导入扩展社区的“全局管理员”字段设置为PE在源自该VRF的PE-PE PIM控制消息的IP源地址字段中放置的相同IP地址。
Note that BSR (Bootstrap Router Mechanism for PIM) [BSR] messages are treated the same as PIM C-instance control packets, and BSR processing is regarded as an integral part of the PIM C-instance processing.
请注意，BSR（PIM引导路由器机制）[BSR]消息被视为与PIM C实例控制包相同，并且BSR处理被视为PIM C实例处理的一个组成部分。
Although the MI-PMSI is treated by PIM as a LAN interface, unicast routing is NOT run over it, and there are no unicast routing adjacencies over it. Therefore, it is necessary to specify special procedures for determining when the MI-PMSI is to be regarded as the "RPF Interface" for a particular C-address.
虽然MI-PMSI被PIM视为LAN接口，但单播路由不会在其上运行，并且在其上没有单播路由邻接。因此，有必要规定确定MI-PMSI何时被视为特定C地址的“RPF接口”的特殊程序。
The PE follows the procedures of Section 5.1 to determine the Selected UMH Route. If that route is NOT a VPN-IP route learned from BGP as described in [RFC4364], or if that route's outgoing interface is one of the interfaces associated with the VRF, then ordinary PIM procedures for determining the RPF interface apply.
PE遵循第5.1节的程序确定所选UMH路线。如果该路由不是[RFC4364]中描述的从BGP学习的VPN-IP路由，或者如果该路由的输出接口是与VRF相关联的接口之一，则用于确定RPF接口的普通PIM程序适用。
However, if the Selected UMH Route is a VPN-IP route whose outgoing interface is not one of the interfaces associated with the VRF, then PIM will consider the RPF interface to be the MI-PMSI associated with the VPN-specific PIM instance.
然而，如果所选择的UMH路由是VPN-IP路由，其输出接口不是与VRF相关联的接口之一，那么PIM将考虑RPF接口是与VPN特定PIM实例相关联的Mi-PMSI。
Once PIM has determined that the RPF interface for a particular C-root is the MI-PMSI, it is necessary for PIM to determine the "RPF neighbor" for that C-root. This will be one of the other PEs that is a PIM adjacency over the MI-PMSI. In particular, it will be the "Selected Upstream PE", as defined in Section 5.1.
一旦PIM确定特定C根的RPF接口是MI-PMSI，PIM就有必要确定该C根的“RPF邻居”。这将是MI-PMSI上PIM邻接的其他PEs之一。具体而言，它将是第5.1节中定义的“选定上游PE”。
It is possible to use BGP to carry C-multicast routing information from PE to PE, dispensing entirely with the transmission of C-Join/Prune messages from PE to PE. This section describes the procedures for carrying intra-AS multicast routing information. Inter-AS procedures are described in Section 8. The complete specification of both sets of procedures and of the encodings can be found in [MVPN-BGP].
可以使用BGP将C-multicast路由信息从PE传送到PE，完全不需要将C-Join/Prune消息从PE传送到PE。本节描述了将帧内路由信息作为多播路由信息进行传输的过程。内部AS程序在第8节中描述。两套程序和编码的完整规范见[MVPN-BGP]。
The MCAST-VPN address family is used for this purpose. MCAST-VPN routes used for the purpose of carrying C-multicast routing information are distinguished from those used for the purpose of carrying auto-discovery information by means of a "route type" field that is encoded into the NLRI. The following information is required in BGP to advertise the MVPN routing information. The NLRI contains the following:
MCAST-VPN地址系列用于此目的。通过编码到NLRI中的“路由类型”字段，将用于承载C多播路由信息的MCAST-VPN路由与用于承载自动发现信息的MCAST-VPN路由区分开来。BGP中需要以下信息来公布MVPN路由信息。NLRI包含以下内容：
- The type of C-multicast route
- C组播路由的类型
There are two types:
有两种类型：
* source tree join
* 源树连接
* shared tree join
* 共享树连接
- The C-group address
- C组地址
- The C-source address (In the case of a shared tree join, this is the address of the C-RP.)
- C源地址（在共享树连接的情况下，这是C-RP的地址。）
- The Selected Upstream RD corresponding to the C-root address (determined by the procedures of Section 5.1).
- 与C根地址对应的所选上游RD（由第5.1节的程序确定）。
Whenever a C-multicast route is sent, it must also carry the Selected Upstream Multicast Hop corresponding to the C-root address (determined by the procedures of Section 5.1). The Selected Upstream Multicast Hop must be encoded as part of a Route Target Extended Community to facilitate the optional use of filters that can prevent the distribution of the update to BGP speakers other than the Upstream Multicast Hop. See Section 10.1.3 of [MVPN-BGP] for the details.
每当发送C-多播路由时，它还必须携带与C-根地址对应的所选上游多播跃点（由第5.1节的程序确定）。所选的上游多播跃点必须作为路由目标扩展社区的一部分进行编码，以便于可选地使用过滤器，防止将更新分发给除上游多播跃点以外的BGP扬声器。详见[MVPN-BGP]第10.1.3节。
There is no C-multicast route corresponding to the PIM function of pruning a source off the shared tree when a PE switches from a (C-*,C-G) tree to a (C-S,C-G) tree. Section 9 of this document
当PE从（C-*，C-G）树切换到（C-S，C-G）树时，没有与PIM功能相对应的C-multicast路由，PIM功能将源从共享树中剪除。本文件第9节
specifies a mandatory procedure that ensures that if any PE joins a (C-S,C-G) source tree, all other PEs that have joined or will join the (C-*,C-G) shared tree will also join the (C-S,C-G) source tree.
指定一个强制过程，以确保如果任何PE加入（C-S，C-G）源树，则已加入或将加入（C-*，C-G）共享树的所有其他PE也将加入（C-S，C-G）源树。
This eliminates the need for a C-multicast route that prunes C-S off the (C-*,C-G) shared tree when switching from (C-*,C-G) to (C-S,C-G) tree.
这消除了在从（C-*，C-G）树切换到（C-S，C-G）树时从（C-*，C-G）共享树修剪C-S的C-multicast路由的需要。
Note that the upstream multicast hop is NOT part of the NLRI in the C-multicast BGP routes. This means that if several PEs join the same C-tree, the BGP routes they distribute to do so are regarded by BGP as comparable routes, and only one will be installed. If a route reflector is being used, this further means that the PE that is used to reach the C-source will know only that one or more of the other PEs have joined the tree, but it won't know which one. That is, this BGP update mechanism does not provide "explicit tracking". Explicit tracking is not provided by default because it increases the amount of state needed and thus decreases scalability. Also, as constructing the C-PIM messages to send "upstream" for a given tree does not depend on knowing all the PEs that are downstream on that tree, there is no reason for the C-multicast route type updates to provide explicit tracking.
注意，在C-多播BGP路由中，上行多播跃点不是NLRI的一部分。这意味着，如果多个PE加入同一个C-树，则BGP会将其分配的BGP路由视为可比较的路由，并且只安装一条。如果正在使用路由反射器，这进一步意味着用于到达C源的PE将只知道一个或多个其他PE已加入树，但不知道是哪一个。也就是说，此BGP更新机制不提供“显式跟踪”。默认情况下不提供显式跟踪，因为它增加了所需的状态量，从而降低了可伸缩性。此外，由于为给定树构造发送“上游”的C-PIM消息并不取决于知道该树上下游的所有pe，因此C-multicast路由类型更新没有理由提供显式跟踪。
There are some cases in which explicit tracking is necessary in order for the PEs to set up certain kinds of P-trees. There are other cases in which explicit tracking is desirable in order to determine how to optimally aggregate multicast flows onto a given aggregate tree. As these functions have to do with the setting up of infrastructure in the P-network, rather than with the dissemination of C-multicast routing information, any explicit tracking that is necessary is handled by sending a particular type of A-D route known as "Leaf A-D routes".
在某些情况下，为了让PEs建立某些类型的P-树，显式跟踪是必要的。在其他情况下，为了确定如何将多播流最优地聚合到给定的聚合树上，需要显式跟踪。由于这些功能必须与P网络中的基础设施的设置有关，而不是与C多播路由信息的传播有关，因此任何必要的显式跟踪都是通过发送称为“叶a-D路由”的特定类型的a-D路由来处理的。
Whenever a PE sends an A-D route with a PMSI Tunnel attribute, it can set a bit in the PMSI Tunnel attribute indicating "Leaf Information Required". A PE that installs such an A-D route MUST respond by generating a Leaf A-D route, indicating that it needs to join (or be joined to) the specified PMSI Tunnel. Details can be found in [MVPN-BGP].
每当PE发送具有PMSI隧道属性的a-D路由时，它可以在PMSI隧道属性中设置一个位，指示“需要叶信息”。安装这种A-D路由的PE必须通过生成叶A-D路由来响应，指示它需要加入（或被加入）指定的PMSI隧道。有关详细信息，请参见[MVPN-BGP]。
A PE removes itself from a C-multicast tree (shared or source) by withdrawing the corresponding BGP Update.
PE通过撤回相应的BGP更新从C-多播树（共享或源）中移除自身。
If a PE has pruned a C-source from a shared C-multicast tree, and it needs to "unprune" that source from that tree, it does so by withdrawing the route that pruned the source from the tree.
如果PE已从共享C-多播树中删除了C-源，并且需要从该树中“取消运行”该源，则PE将通过从该树中撤消删除源的路由来执行此操作。
BGP does not provide a method for carrying the control information of BSR packets received by a PE from a CE. BSR is supported by transmitting the BSR control messages from one PE in an MVPN to all the other PEs in that MVPN.
BGP不提供用于承载由PE从CE接收的BSR分组的控制信息的方法。通过将BSR控制消息从MVPN中的一个PE传输到该MVPN中的所有其他PE来支持BSR。
When a PE needs to transmit a BSR message for a particular MVPN to other PEs, it must put its own IP address into the BSR message as the IP source address. As specified in Section 5.1.2, when a PE distributes VPN-IP routes that are eligible for use as UMH routes, the PE MUST include a VRF Route Import Extended Community with each route. For a given MVPN, a single such IP address MUST be used, and that same IP address MUST be used as the source address in all BSR packets that the PE transmits to other PEs.
当一个PE需要将特定MVPN的BSR消息传输给其他PE时，它必须将自己的IP地址作为IP源地址放入BSR消息中。如第5.1.2节所述，当PE分发有资格用作UMH路由的VPN-IP路由时，PE必须在每条路由中包含一个VRF路由导入扩展社区。对于给定的MVPN，必须使用单个这样的IP地址，并且该IP地址必须用作PE传输到其他PE的所有BSR数据包中的源地址。
The BSR message may be transmitted over any PMSI that will deliver the message to all the other PEs in the MVPN. If no such PMSI has been instantiated yet, then an appropriate P-tunnel must be advertised, and the C-flow whose C-source address is the address of the PE itself, and whose multicast group is ALL-PIM-ROUTERS (224.0.0.13), must be bound to it. This can be done using the procedures described in Sections 7.3 and 7.4. Note that this is NOT meant to imply that the other PIM control packets from the PIM C-instance are to be transmitted to the other PEs.
BSR消息可通过任何PMSI传输，该PMSI将消息传送至MVPN中的所有其他PE。如果尚未实例化此类PMSI，则必须通告适当的P隧道，并且其C源地址为PE本身地址且其多播组为ALL-PIM-ROUTERS（224.0.0.13）的C流必须绑定到它。这可以使用第7.3节和第7.4节中描述的程序完成。注意，这并不意味着来自PIM C实例的其他PIM控制分组将被发送到其他PEs。
When a PE receives a BSR message for a particular MVPN from some other PE, the PE accepts the message only if the IP source address in that message is the Selected Upstream PE (see Section 5.1.3) for the IP address of the Bootstrap router. Otherwise, the PE simply discards the packet. If the PE accepts the packet, it does normal BSR processing on it, and it may forward a BSR message to one or more CEs as a result.
当PE从其他PE接收特定MVPN的BSR消息时，仅当该消息中的IP源地址是引导路由器IP地址的选定上游PE（见第5.1.3节）时，PE才会接受该消息。否则，PE将丢弃该数据包。如果PE接受该数据包，它将对该数据包进行正常的BSR处理，并可能因此将BSR消息转发给一个或多个CE。
This section provides the procedures for using P-tunnels to instantiate a PMSI. It describes the procedures for setting up and maintaining the P-tunnels as well as for sending and receiving C-data and/or C-control messages on the P-tunnels. However, procedures for binding particular C-flows to particular P-tunnels are discussed in Section 7.
本节提供了使用P隧道实例化PMSI的过程。它描述了设置和维护P隧道以及在P隧道上发送和接收C数据和/或C控制消息的程序。然而，第7节讨论了将特定C流绑定到特定P隧道的程序。
PMSIs can be instantiated either by P-multicast trees or by PE-PE unicast tunnels. In the latter case, the PMSI is said to be instantiated by "ingress replication".
PMSI可以通过P-多播树或PE-PE单播隧道实例化。在后一种情况下，PMSI被称为通过“入口复制”实例化。
This specification supports a number of different methods for setting up P-multicast trees: these are detailed below. A P-tunnel may support a single VPN (a non-aggregated P-multicast tree) or multiple VPNs (an aggregated P-multicast tree).
本规范支持许多不同的方法来建立P-多播树：下面详细介绍这些方法。P-隧道可以支持单个VPN（非聚合P-多播树）或多个VPN（聚合P-多播树）。
When a PE is provisioned to have one or more VRFs that provide MVPN support, the PE announces its MVPN membership information using Intra-AS I-PMSI A-D routes, as discussed in Section 4 and detailed in Section 9.1.1 of [MVPN-BGP]. (Under certain conditions, detailed in [MVPN-BGP], the Intra-AS I-PMSI A-D route may be omitted.)
当PE被设置为具有一个或多个提供MVPN支持的VRF时，PE使用内部AS I-PMSI a-D路由宣布其MVPN成员信息，如第4节所述，并在[MVPN-BGP]第9.1.1节中详细说明。（在某些情况下，如[MVPN-BGP]所述，可以省略内部AS I-PMSI A-D路由。）
Generally, the Intra-AS I-PMSI A-D route will have a PMSI Tunnel attribute that identifies a P-tunnel that is being used to instantiate the I-PMSI. Section 9.1.1 of [MVPN-BGP] details certain conditions under which the PMSI Tunnel attribute may be omitted (or in which a PMSI Tunnel attribute with the "no tunnel information present" bit may be sent).
通常，帧内AS I-PMSI A-D路由将具有PMSI隧道属性，该属性标识用于实例化I-PMSI的P隧道。[MVPN-BGP]第9.1.1节详细说明了可省略PMSI隧道属性的某些条件（或可发送具有“无隧道信息存在”位的PMSI隧道属性）。
As a special case, when (a) C-PIM control messages are to be sent through an MI-PMSI and (b) the MI-PMSI is instantiated by a P-tunnel technique for which each PE needs to know only a single P-tunnel identifier per VPN, then the use of the Intra-AS I-PMSI A-D routes MAY be omitted, and static configuration of the tunnel identifier used instead. However, this is not recommended for long-term use, and in all other cases, the Intra-AS I-PMSI A-D routes MUST be used.
作为一种特殊情况，当（a）C-PIM控制消息将通过MI-PMSI发送并且（b）MI-PMSI通过P隧道技术实例化时，对于该P隧道技术，每个PE只需要知道每个VPN的单个P隧道标识符，则可以省略内部As I-PMSI a-D路由的使用，而改为使用隧道标识符的静态配置。但是，这不建议长期使用，在所有其他情况下，必须使用内部AS I-PMSI A-D路由。
The PMSI Tunnel attribute MAY contain an upstream-assigned MPLS label, assigned by the PE originating the Intra-AS I-PMSI A-D route. If this label is present, the P-tunnel can be carrying data from several MVPNs. The label is used on the data packets traveling through the tunnel to identify the MVPN to which those data packets belong. (The specified label identifies the packet as belonging to the MVPN that is identified by the RTs of the Intra-AS I-PMSI A-D route.)
PMSI隧道属性可以包含上游分配的MPLS标签，该标签由发起帧内AS I-PMSI A-D路由的PE分配。如果存在此标签，则P-tunnel可以承载来自多个MVPN的数据。标签用于通过隧道传输的数据包，以标识这些数据包所属的MVPN。（指定的标签将数据包标识为属于由内部as I-PMSI A-D路由的RTs标识的MVPN。）
See Section 12.2 for details on how to place the label in the packet's label stack.
有关如何将标签放置在数据包标签堆栈中的详细信息，请参见第12.2节。
The Intra-AS I-PMSI A-D route may contain a "PE Distinguisher Labels" attribute. This contains a set of bindings between upstream-assigned labels and PE addresses. The PE that originated the route may use this to bind an upstream-assigned label to one or more of the other PEs that belong to the same MVPN. The way in which PE Distinguisher Labels are used is discussed in Sections 6.4.1, 6.4.3, 11.2.2, and 12.3. Other uses of the PE Distinguisher Labels attribute are outside the scope of this document.
帧内AS I-PMSI A-D路由可以包含“PE区分器标签”属性。这包含上游分配的标签和PE地址之间的一组绑定。发起路由的PE可以使用此来将上游分配的标签绑定到属于同一MVPN的一个或多个其他PE。第6.4.1、6.4.3、11.2.2和12.3节讨论了PE识别标签的使用方式。PE Discrimizer Labels属性的其他用途不在本文档的范围内。
The action to be taken when a PE receives an Intra-AS I-PMSI A-D route for a particular MVPN depends on the particular P-tunnel technology that is being used by that MVPN. If the P-tunnel technology requires tunnels to be built by means of receiver-initiated joins, the PE SHOULD join the tunnel immediately.
当PE接收到特定MVPN的内部AS I-PMSI a-D路由时要采取的动作取决于该MVPN正在使用的特定P隧道技术。如果P-tunnel技术要求通过接收器发起连接的方式建造隧道，则PE应立即连接隧道。
This situation is discussed in Section 7.
第7节讨论了这种情况。
When a P-multicast tree is shared across multiple MVPNs, it is termed an "Aggregate Tree". The procedures described in this document allow a single SP multicast tree to be shared across multiple MVPNs. Unless otherwise specified, P-multicast tree technology supports aggregation.
当一个P多播树在多个MVPN之间共享时，它被称为“聚合树”。本文档中描述的过程允许跨多个MVPN共享单个SP多播树。除非另有规定，否则P多播树技术支持聚合。
All procedures that are specific to multi-MVPN aggregation are OPTIONAL and are explicitly pointed out.
所有特定于多MVPN聚合的过程都是可选的，并明确指出。
Aggregate Trees allow a single P-multicast tree to be used across multiple MVPNs so that state in the SP core grows per set of MVPNs and not per MVPN. Depending on the congruence of the aggregated MVPNs, this may result in trading off optimality of multicast routing.
聚合树允许在多个MVPN之间使用单个P多播树，因此SP核心中的状态会随着MVPN集而不是每个MVPN的增长而增长。根据聚合MVPN的一致性，这可能会导致在多播路由的最佳性之间进行权衡。
An Aggregate Tree can be used by a PE to provide a UI-PMSI or MI-PMSI service for more than one MVPN. When this is the case, the Aggregate Tree is said to have an inclusive mapping.
PE可以使用聚合树为多个MVPN提供UI-PMSI或MI-PMSI服务。在这种情况下，聚合树被称为具有包含映射。
BGP MVPN membership discovery (Section 4) allows a PE to determine the different Aggregate Trees that it should create and the MVPNs that should be mapped onto each such tree. The leaves of an Aggregate Tree are determined by the PEs, supporting aggregation, that belong to all the MVPNs that are mapped onto the tree.
BGP MVPN成员身份发现（第4节）允许PE确定应创建的不同聚合树以及应映射到每个此类树上的MVPN。聚合树的叶子由属于映射到树上的所有MVPN的支持聚合的PE确定。
If an Aggregate Tree is used to instantiate one or more S-PMSIs, then it may be desirable for the PE at the root of the tree to know which PEs (in its MVPN) are receivers on that tree. This enables the PE to decide when to aggregate two S-PMSIs, based on congruence (as discussed in the next section). Thus, explicit tracking may be required. Since the procedures for disseminating C-multicast routes do not provide explicit tracking, a type of A-D route known as a "Leaf A-D route" is used. The PE that wants to assign a particular C-multicast flow to a particular Aggregate Tree can send an A-D route, which elicits Leaf A-D routes from the PEs that need to receive that C-multicast flow. This provides the explicit tracking information needed to support the aggregation methodology discussed in the next section. For more details on Leaf A-D routes, please refer to [MVPN-BGP].
如果使用聚合树来实例化一个或多个S-pmsi，则树根的PE可能需要知道哪些PE（在其MVPN中）是该树上的接收器。这使PE能够根据一致性（如下一节所述）决定何时聚合两个S-PMSI。因此，可能需要明确的跟踪。由于传播C-multicast路由的过程不提供显式跟踪，因此使用了一种称为“叶a-D路由”的a-D路由。想要将特定C多播流分配给特定聚合树的PE可以发送a-D路由，该路由从需要接收该C多播流的PE中引出叶a-D路由。这提供了支持下一节讨论的聚合方法所需的显式跟踪信息。有关叶A-D路由的更多详细信息，请参阅[MVPN-BGP]。
This document does not specify the mandatory implementation of any particular set of rules for determining whether or not the PMSIs of two particular MVPNs are to be instantiated by the same Aggregate Tree. This determination can be made by implementation-specific heuristics, by configuration, or even perhaps by the use of offline tools.
本文件未规定任何特定规则集的强制实施，以确定两个特定MVPN的PMSI是否由同一聚合树实例化。可以通过特定于实现的启发式、配置，甚至可能通过使用脱机工具来确定。
It is the intention of this document that the control procedures will always result in all the PEs of an MVPN agreeing on the PMSIs that are to be used and on the tunnels used to instantiate those PMSIs.
本文件的目的是，控制程序将始终导致MVPN的所有PE就将要使用的PMSI和用于实例化这些PMSI的隧道达成一致。
This section discusses potential methodologies with respect to aggregation.
本节讨论与聚合相关的潜在方法。
The "congruence" of aggregation is defined by the amount of overlap in the leaves of the customer trees that are aggregated on an SP tree. For Aggregate Trees with an inclusive mapping, the congruence depends on the overlap in the membership of the MVPNs that are aggregated on the tree. If there is complete overlap, i.e., all MVPNs have exactly the same sites, aggregation is perfectly congruent. As the overlap between the MVPNs that are aggregated reduces, i.e., the number of sites that are common across all the MVPNs reduces, the congruence reduces.
聚合的“一致性”由在SP树上聚合的客户树的叶子中的重叠量定义。对于具有包含映射的聚合树，一致性取决于在树上聚合的MVPN成员的重叠。如果存在完全重叠，即所有MVPN具有完全相同的位点，则聚合是完全一致的。当聚合的MVPN之间的重叠减少时，即，所有MVPN中的公共站点数量减少时，一致性降低。
If aggregation is done such that it is not perfectly congruent, a PE may receive traffic for MVPNs to which it doesn't belong. As the amount of multicast traffic in these unwanted MVPNs increases, aggregation becomes less optimal with respect to delivered traffic. Hence, there is a trade-off between reducing state and delivering unwanted traffic.
如果聚合的完成使得它不是完全一致的，则PE可能会接收它不属于的MVPN的流量。随着这些不需要的mvpn中的多播通信量的增加，聚合相对于交付的通信量变得不那么优化。因此，在减少状态和提供不需要的通信量之间需要权衡。
An implementation should provide knobs to control the congruence of aggregation. These knobs are implementation dependent. Configuring the percentage of sites that MVPNs must have in common to be aggregated is an example of such a knob. This will allow an SP to deploy aggregation depending on the MVPN membership and traffic profiles in its network. If different PEs or servers are setting up Aggregate Trees, this will also allow a service provider to engineer the maximum amount of unwanted MVPNs for which a particular PE may receive traffic.
实现应该提供控制聚合一致性的旋钮。这些旋钮取决于实现。配置MVPN必须具有共同点才能聚合的站点的百分比就是这样一个例子。这将允许SP根据其网络中的MVPN成员资格和流量配置文件部署聚合。如果不同的PE或服务器正在设置聚合树，这也将允许服务提供商设计特定PE可能接收流量的最大不需要的MVPN数量。
If a P-multicast tree is associated with only one MVPN, determining the P-multicast tree on which a packet was received is sufficient to determine the packet's MVPN. All that the egress PE needs to know is the MVPN with which the P-multicast tree is associated.
如果P-多播树仅与一个MVPN相关联，则确定在其上接收分组的P-多播树足以确定分组的MVPN。出口PE只需要知道与P多播树相关联的MVPN。
When multiple MVPNs are aggregated onto one P-multicast tree, determining the tree over which the packet is received is not sufficient to determine the MVPN to which the packet belongs. The packet must also carry some demultiplexing information to allow the egress PEs to determine the MVPN to which the packet belongs. Since the packet has been multicast through the P-network, any given demultiplexing value must have the same meaning to all the egress PEs. The demultiplexing value is a MPLS label that corresponds to the multicast VRF to which the packet belongs. This label is placed by the ingress PE immediately beneath the P-multicast tree header. Each of the egress PEs must be able to associate this MPLS label with the same MVPN. If downstream-assigned labels were used, this would require all the egress PEs in the MVPN to agree on a common label for the MVPN. Instead, the MPLS label is upstream-assigned [MPLS-UPSTREAM-LABEL]. The label bindings are advertised via BGP Updates originated by the ingress PEs.
当多个MVPN聚合到一个P-多播树上时，确定接收数据包的树不足以确定数据包所属的MVPN。分组还必须携带一些解复用信息，以允许出口PEs确定分组所属的MVPN。由于分组已通过P网络进行多播，因此任何给定的解复用值对所有出口pe都必须具有相同的含义。解复用值是与数据包所属的多播VRF相对应的MPLS标签。该标签由入口PE放置在P多播树头的正下方。每个出口PE必须能够将此MPLS标签与相同的MVPN相关联。如果使用下游指定的标签，这将要求MVPN中的所有出口PE就MVPN的通用标签达成一致。相反，MPLS标签是上游分配的[MPLS-upstream-label]。标签绑定通过ingress PEs发起的BGP更新发布。
This procedure requires each egress PE to support a separate label space for every other PE. The egress PEs create a forwarding entry for the upstream-assigned MPLS label, allocated by the ingress PE, in this label space. Hence, when the egress PE receives a packet over an Aggregate Tree, it first determines the tree over which the packet was received. The tree identifier determines the label space in which the upstream-assigned MPLS label lookup has to be performed.
该程序要求每个出口PE为每个其他PE支持单独的标签空间。出口PE在此标签空间中为上游分配的MPLS标签创建转发条目，该标签由入口PE分配。因此，当出口PE通过聚合树接收分组时，它首先确定接收分组的树。树标识符确定必须在其中执行上游分配的MPLS标签查找的标签空间。
The same label space may be used for all P-multicast trees rooted at the same ingress PE or an implementation may decide to use a separate label space for every P-multicast tree.
相同的标签空间可用于根在相同入口PE的所有P-多播树，或者实现可决定对每个P-多播树使用单独的标签空间。
A full specification of the procedures to support aggregation on shared trees or on MP2MP LSPs is outside the scope of this document.
支持在共享树或MP2MP LSP上聚合的完整过程规范不在本文档范围内。
The encapsulation format is either MPLS or MPLS-in-something (e.g., MPLS-in-GRE [MPLS-IP]). When MPLS is used, this label will appear immediately below the label that identifies the P-multicast tree. When MPLS-in-GRE is used, this label will be the top MPLS label that appears when the GRE header is stripped off.
封装格式为MPLS或MPLS格式（例如，GRE[MPLS-IP]中的MPLS）。使用MPLS时，此标签将显示在标识P多播树的标签的正下方。使用GRE中的MPLS时，此标签将是剥离GRE标头时出现的顶部MPLS标签。
When IP encapsulation is used for the P-multicast tree, whatever information that particular encapsulation format uses for identifying a particular tunnel is used to determine the label space in which the MPLS label is looked up.
当IP封装用于P-多播树时，特定封装格式用于标识特定隧道的任何信息都将用于确定查找MPLS标签的标签空间。
If the P-multicast tree uses MPLS encapsulation, the P-multicast tree is itself identified by an MPLS label. The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for that tree. Once the label representing the tree is popped off the MPLS label stack, the next label is the demultiplexing information that allows the proper MVPN to be determined.
如果P多播树使用MPLS封装，则P多播树本身由MPLS标签标识。出口PE不得为该树播发隐式NULL或显式NULL。一旦表示树的标签从MPLS标签堆栈中弹出，下一个标签就是允许确定正确MVPN的解复用信息。
This specification requires that, to support this sort of aggregation, there be at least one upstream-assigned label per MVPN. It does not require that there be only one. For example, an ingress PE could assign a unique label to each (C-S,C-G). (This could be done using the same technique that is used to assign a particular (C-S,C-G) to an S-PMSI, see Section 7.4.)
该规范要求，为了支持这种聚合，每个MVPN至少有一个上游分配的标签。它不要求只有一个。例如，入口PE可以为每个（C-S、C-G）分配一个唯一的标签。（这可以使用与将特定（C-S，C-G）分配给S-PMSI相同的技术来完成，见第7.4节。）
When an egress PE receives a C-multicast data packet over a P-multicast tree, it needs to forward the packet to the CEs that have receivers in the packet's C-multicast group. In order to do this, the egress PE needs to determine the P-tunnel on which the packet was received. The PE can then determine the MVPN that the packet belongs to and, if needed, do any further lookups that are needed to forward the packet.
当出口PE通过P-多播树接收到C-多播数据分组时，它需要将该分组转发到在分组的C-多播组中具有接收器的ce。为了做到这一点，出口PE需要确定在其上接收分组的P隧道。然后，PE可以确定分组所属的MVPN，并且如果需要，执行转发分组所需的任何进一步的查找。
While it is believed that the architecture specified in this document places no limitations on the protocols used for setting up and maintaining P-tunnels, the only protocols that have been explicitly considered are PIM-SM (both the SSM and ASM service models are
虽然本文件中规定的体系结构对用于建立和维护P隧道的协议没有限制，但明确考虑的唯一协议是PIM-SM（SSM和ASM服务模型均为
considered, as are bidirectional trees), RSVP-TE, mLDP, and BGP. (BGP's role in the setup and maintenance of P-tunnels is to "stitch" together the intra-AS segments of a segmented inter-AS P-tunnel.)
考虑双向树）、RSVP-TE、mLDP和BGP。（BGP在P隧道的设置和维护中的作用是“缝合”分段AS间P隧道的AS内段。）
If an I-PMSI is to be instantiated as one or more non-segmented P-tunnels, where the P-tunnels are RSVP-TE P2MP LSPs, then only the PEs that are at the head ends of those LSPs will ever include the PMSI Tunnel attribute in their Intra-AS I-PMSI A-D routes. (These will be the PEs in the "Sender Sites set".)
如果将I-PMSI实例化为一个或多个非分段P隧道，其中P隧道为RSVP-TE P2MP LSP，则只有位于这些LSP前端的PE才会在其内部as I-PMSI A-D路由中包含PMSI隧道属性。（这些将是“发件人站点集”中的PEs。）
If an I-PMSI is to be instantiated as one or more segmented P-tunnels, where some of the intra-AS segments of these tunnels are RSVP-TE P2MP LSPs, then only a PE or ASBR that is at the head end of one of these LSPs will ever include the PMSI Tunnel attribute in its Inter-AS I-PMSI A-D route.
如果I-PMSI将被实例化为一个或多个分段P隧道，其中这些隧道的一些as内段是RSVP-TE P2MP LSP，则只有位于其中一个LSP前端的PE或ASBR将在其as间I-PMSI a-D路由中包含PMSI隧道属性。
Other PEs send Intra-AS I-PMSI A-D routes without PMSI Tunnel attributes. (These will be the PEs that are in the "Receiver Sites set" but not in the "Sender Sites set".) As each "Sender Site" PE receives an Intra-AS I-PMSI A-D route from a PE in the Receiver Sites set, it adds the PE originating that Intra-AS I-PMSI A-D route to the set of receiving PEs for the P2MP LSP. The PE at the head end MUST then use RSVP-TE [RSVP-P2MP] signaling to add the receiver PEs to the P-tunnel.
其他PE发送不带PMSI隧道属性的帧内AS I-PMSI A-D路由。（这些将是“接收方站点集”中但不在“发送方站点集”中的PE。）当每个“发送方站点”PE从接收方站点集中的PE接收到一个内部As I-PMSI A-D路由时，它会将发起该内部As I-PMSI A-D路由的PE添加到P2MP LSP的接收PE集中。然后，前端的PE必须使用RSVP-TE[RSVP-P2MP]信令将接收器PE添加到P隧道。
When RSVP-TE P2MP LSPs are used to instantiate S-PMSIs, and a particular C-flow is to be bound to the LSP, it is necessary to use explicit tracking so that the head end of the LSP knows which PEs need to receive data from the specified C-flow. If the binding is done using S-PMSI A-D routes (see Section 7.4.1), the "Leaf Information Required" bit MUST be set in the PMSI Tunnel attribute.
当RSVP-TE P2MP LSP用于实例化S-PMSI，并且特定的C流将绑定到LSP时，有必要使用显式跟踪，以便LSP的前端知道哪些PE需要从指定的C流接收数据。如果使用S-PMSI A-D路由进行绑定（参见第7.4.1节），则必须在PMSI隧道属性中设置“所需叶信息”位。
RSVP-TE P2MP LSPs can optionally support aggregation of multiple MVPNs.
RSVP-TE P2MP LSP可以选择性地支持多个MVPN的聚合。
If an RSVP-TE P2MP LSP Tunnel is used for only a single MVPN, the mapping between the LSP and the MVPN can either be configured or be deduced from the procedures used to announce the LSP (e.g., from the RTs in the A-D route that announced the LSP). If the LSP is used for multiple MVPNs, the set of MVPNs using it (and the corresponding MPLS labels) is inferred from the PMSI Tunnel attributes that specify the LSP.
如果RSVP-TE P2MP LSP隧道仅用于单个MVPN，则可以配置LSP和MVPN之间的映射，也可以从用于宣布LSP的过程（例如，从宣布LSP的a-D路由中的RTs）中推断LSP和MVPN之间的映射。如果LSP用于多个MVPN，则将从指定LSP的PMSI隧道属性推断使用它的MVPN集（以及相应的MPLS标签）。
If an RSVP-TE P2MP LSP is being used to carry a set of C-flows traveling along a bidirectional C-tree, using the procedures of Section 11.2, the head end MUST include the PE Distinguisher Labels
如果使用第11.2节的程序，RSVP-TE P2MP LSP用于携带一组沿双向C-树移动的C-流，则前端必须包括PE识别器标签
attribute in its Intra-AS I-PMSI A-D route or S-PMSI A-D route, and it MUST provide an upstream-assigned label for each PE that it has selected as the Upstream PE for the C-tree's RPA (Rendezvous Point Address). See Section 11.2 for details.
属性，并且它必须为已选择作为C树RPA（会合点地址）上游PE的每个PE提供上游分配的标签。详见第11.2节。
A PMSI Tunnel attribute specifying an RSVP-TE P2MP LSP contains the following information:
指定RSVP-TE P2MP LSP的PMSI隧道属性包含以下信息：
- The type of the tunnel is set to RSVP-TE P2MP Tunnel
- 隧道类型设置为RSVP-TE P2MP隧道
- The RSVP-TE P2MP Tunnel's SESSION Object.
- RSVP-TE P2MP隧道的会话对象。
- Optionally, the RSVP-TE P2MP LSP's SENDER_TEMPLATE Object. This object is included when it is desired to identify a particular P2MP TE LSP.
- （可选）RSVP-TE P2MP LSP的发送方模板对象。当需要识别特定P2MP TE LSP时，包含此对象。
Demultiplexing the C-multicast data packets at the egress PE follows procedures described in Section 6.3.3. As specified in Section 6.3.3, an egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for an RSVP-TE P2MP LSP that is carrying traffic for one or more MVPNs.
按照第6.3.3节中描述的程序，在出口PE处解复用C多播数据包。如第6.3.3节所述，出口PE不得为承载一个或多个MVPN流量的RSVP-TE P2MP LSP播发隐式NULL或显式NULL。
If (and only if) a particular RSVP-TE P2MP LSP is possibly carrying data from multiple MVPNs, the following special procedures apply:
如果（且仅当）特定RSVP-TE P2MP LSP可能携带来自多个MVPN的数据，则以下特殊程序适用：
- A packet in a particular MVPN, when transmitted into the LSP, must carry the MPLS label specified in the PMSI Tunnel attribute that announced that LSP as a P-tunnel for that for that MVPN.
- 特定MVPN中的数据包在传输到LSP时，必须携带在PMSI隧道属性中指定的MPLS标签，该属性宣布LSP为该MVPN的P隧道。
- Demultiplexing the C-multicast data packets at the egress PE is done by means of the MPLS label that rises to the top of the stack after the label corresponding to the P2MP LSP is popped off.
- 通过在弹出与P2MP LSP对应的标签之后上升到堆栈顶部的MPLS标签，在出口PE处解复用C多播数据分组。
It is possible that at the time a PE learns, via an A-D route with a PMSI Tunnel attribute, that it needs to receive traffic on a particular RSVP-TE P2MP LSP, the signaling to set up the LSP will not have been completed. In this case, the PE needs to wait for the RSVP-TE signaling to take place before it can modify its forwarding tables as directed by the A-D route.
当PE通过具有PMSI隧道属性的a-D路由得知其需要在特定RSVP-TE P2MP LSP上接收业务时，设置LSP的信令可能尚未完成。在这种情况下，PE需要等待RSVP-TE信令发生，然后才能按照A-D路由的指示修改其转发表。
It is also possible that the signaling to set up an RSVP-TE P2MP LSP will be completed before a given PE learns, via a PMSI Tunnel attribute, of the use to which that LSP will be put. The PE MUST discard any traffic received on that LSP until that time.
还可能的是，在给定PE通过PMSI隧道属性学习该LSP将被置于的用途之前，建立RSVP-TE P2MP LSP的信令将被完成。在此之前，PE必须丢弃在该LSP上接收的任何通信量。
In order for the egress PE to be able to discard such traffic, it needs to know that the LSP is associated with an MVPN and that the A-D route that binds the LSP to an MVPN or to a particular a C-flow has not yet been received. This is provided by extending [RSVP-P2MP] with [RSVP-OOB].
为了使出口PE能够丢弃这种业务，它需要知道LSP与MVPN相关联，并且将LSP绑定到MVPN或特定A-C流的A-D路由尚未被接收。这是通过用[RSVP-OOB]扩展[RSVP-P2MP]来实现的。
When the P-tunnels are PIM trees, the PMSI Tunnel attribute contains enough information to allow each other PE in the same MVPN to use P-PIM signaling to join the P-tunnel.
当P-Tunnel是PIM树时，PMSI Tunnel属性包含足够的信息，允许同一MVPN中的每个PE使用P-PIM信令加入P-Tunnel。
If an I-PMSI is to be instantiated as one or more PIM trees, then the PE that is at the root of a given PIM tree sends an Intra-AS I-PMSI A-D route containing a PMSI Tunnel attribute that contains all the information needed for other PEs to join the tree.
如果一个I-PMSI将被实例化为一个或多个PIM树，那么位于给定PIM树根的PE将发送一个内部as I-PMSI a-D路由，该路由包含一个PMSI隧道属性，该属性包含其他PE加入该树所需的所有信息。
If PIM trees are to be used to instantiate an MI-PMSI, each PE in the MVPN must send an Intra-AS I-PMSI A-D route containing such a PMSI Tunnel attribute.
如果要使用PIM树实例化MI-PMSI，则MVPN中的每个PE必须发送一条包含此类PMSI隧道属性的内部AS I-PMSI A-D路由。
If a PMSI is to be instantiated via a shared tree, the PMSI Tunnel attribute identifies the P-group address. The RP or RPA corresponding to the P-group address is not specified. It must, of course, be known to all the PEs. It is presupposed that the PEs use one of the methods for automatically learning the RP-to-group correspondences (e.g., Bootstrap Router Protocol [BSR]), or else that the correspondence is configured.
如果要通过共享树实例化PMSI，则PMSI隧道属性标识P组地址。未指定P组地址对应的RP或RPA。当然，所有PEs都必须知道这一点。假定PEs使用自动学习RP的方法之一来分组通信（例如，引导路由器协议[BSR]），或者配置通信。
If a PMSI is to be instantiated via a source-specific tree, the PMSI Tunnel attribute identifies the PE router that is the root of the tree, as well as a P-group address. The PMSI Tunnel attribute always specifies whether the PIM tree is to be a unidirectional shared tree, a bidirectional shared tree, or a source-specific tree.
如果要通过特定于源的树实例化PMSI，则PMSI隧道属性将标识作为树根的PE路由器以及P组地址。PMSI隧道属性始终指定PIM树是单向共享树、双向共享树还是源特定树。
If PIM trees are being used to instantiate S-PMSIs, the above procedures assume that each PE router has a set of group P-addresses that it can use for setting up the PIM-trees. Each PE must be configured with this set of P-addresses. If the P-tunnels are source-specific trees, then the PEs may be configured with overlapping sets of group P-addresses. If the trees are not source-specific, then each PE must be configured with a unique set of group P-addresses (i.e., having no overlap with the set configured at any other PE router). The management of this set of addresses is thus greatly simplified when source-specific trees are used, so the use of source-specific trees is strongly recommended whenever unidirectional trees are desired.
如果PIM树用于实例化S-PMSI，上述过程假设每个PE路由器都有一组P地址，可用于设置PIM树。每个PE必须配置这组P地址。如果P隧道是源特定的树，则PEs可以配置重叠的组P地址集。如果树不是源特定的，则每个PE必须配置一组唯一的组P地址（即，与在任何其他PE路由器上配置的组P地址没有重叠）。因此，当使用特定于源的树时，这组地址的管理大大简化，因此强烈建议在需要单向树时使用特定于源的树。
Specification of the full set of procedures for using bidirectional PIM trees to instantiate S-PMSIs is outside the scope of this document.
使用双向PIM树实例化S-PMSI的全套程序规范不在本文件范围内。
Details for constructing the PMSI Tunnel attribute identifying a PIM tree can be found in [MVPN-BGP].
有关构造标识PIM树的PMSI隧道属性的详细信息，请参见[MVPN-BGP]。
When the P-tunnels are mLDP P2MP trees, each Intra-AS I-PMSI A-D route has a PMSI Tunnel attribute containing enough information to allow each other PE in the same MVPN to use mLDP signaling to join the P-tunnel. The tunnel identifier consists of a P2MP Forwarding Equivalence Class (FEC) Element [mLDP].
当P隧道是mLDP P2MP树时，每个内部AS I-PMSI A-D路由具有包含足够信息的PMSI隧道属性，以允许相同MVPN中的每个PE使用mLDP信令加入P隧道。隧道标识符由P2MP转发等价类（FEC）元素[mLDP]组成。
An mLDP P2MP LSP may be used to carry the traffic of multiple VPNs, if the PMSI Tunnel attribute specifying it contains a non-zero MPLS label.
如果指定mLDP P2MP LSP的PMSI隧道属性包含非零MPLS标签，则该LSP可用于承载多个VPN的流量。
If an mLDP P2MP LSP is being used to carry the set of flows traveling along a particular bidirectional C-tree, using the procedures of Section 11.2, the root of the LSP MUST include the PE Distinguisher Labels attribute in its Intra-AS I-PMSI A-D route or S-PMSI A-D route, and it MUST provide an upstream-assigned label for the PE that it has selected to be the Upstream PE for the C-tree's RPA. See Section 11.2 for details.
如果使用第11.2节中的程序，mLDP P2MP LSP用于承载沿着特定双向C-树移动的流集，则LSP的根必须在其内部AS I-PMSI a-D路由或S-PMSI a-D路由中包含PE Discrimizer Labels属性，并且它必须为已选择作为C树RPA上游PE的PE提供上游指定标签。详见第11.2节。
The specification of the procedures for assigning C-flows to mLDP MP2MP LSPs that serve as P-tunnels is outside the scope of this document.
将C-流分配给用作P-隧道的mLDP MP2MP LSP的程序规范不在本文件范围内。
As described in Section 3, a PMSI can be instantiated using Unicast Tunnels between the PEs that are participating in the MVPN. In this mechanism, the ingress PE replicates a C-multicast data packet belonging to a particular MVPN and sends a copy to all or a subset of the PEs that belong to the MVPN. A copy of the packet is tunneled to a remote PE over a Unicast Tunnel to the remote PE. IP/GRE Tunnels or MPLS LSPs are examples of unicast tunnels that may be used. The same Unicast Tunnel can be used to transport packets belonging to different MVPNs
如第3节所述，可以使用参与MVPN的PE之间的单播隧道来实例化PMSI。在该机制中，入口PE复制属于特定MVPN的C多播数据分组，并向属于该MVPN的所有PE或其子集发送副本。数据包的副本通过单播隧道传输到远程PE。IP/GRE隧道或MPLS LSP是可以使用的单播隧道的示例。相同的单播隧道可用于传输属于不同MVPN的数据包
In order for a PE to use Unicast P-tunnels to send a C-multicast data packet for a particular MVPN to a set of remote PEs, the remote PEs must be able to correctly decapsulate such packets and to assign each
为了使PE使用单播P隧道将特定MVPN的C多播数据分组发送到一组远程PE，远程PE必须能够正确地解封装这些分组并分配每个分组
one to the proper MVPN. This requires that the encapsulation used for sending packets through the P-tunnel have demultiplexing information that the receiver can associate with a particular MVPN.
一个连接到正确的MVPN。这要求用于通过P隧道发送分组的封装具有接收器可与特定MVPN关联的解复用信息。
If ingress replication is being used to instantiate the PMSIs for an MVPN, the PEs announce this as part of the BGP-based MVPN membership auto-discovery process, described in Section 4. The PMSI Tunnel attribute specifies ingress replication; it also specifies a downstream-assigned MPLS label. This label will be used to identify that a particular packet belongs to the MVPN that the Intra-AS I-PMSI A-D route belongs to (as inferred from its RTs). If PE1 specifies a particular label value for a particular MVPN, then any other PE sending PE1 a packet for that MVPN through a unicast P-tunnel must put that label on the packet's label stack. PE1 then treats that label as the demultiplexor value identifying the MVPN in question.
如果使用入口复制来实例化MVPN的PMSI，PEs会宣布这是基于BGP的MVPN成员身份自动发现过程的一部分，如第4节所述。PMSI隧道属性指定入口复制；它还指定下游分配的MPLS标签。该标签将用于标识特定分组属于内部AS I-PMSI a-D路由所属的MVPN（根据其RTs推断）。如果PE1为特定MVPN指定了特定标签值，则通过单播P隧道向PE1发送该MVPN数据包的任何其他PE必须将该标签放在数据包的标签堆栈上。然后，PE1将该标签视为识别相关MVPN的解复用器值。
Ingress replication may be used to instantiate any kind of PMSI. When ingress replication is done, it is RECOMMENDED, except in the one particular case mentioned in the next paragraph, that explicit tracking be done and that the data packets of a particular C-flow only get sent to those PEs that need to see the packets of that C-flow. There is never any need to use the procedures of Section 7.4 for binding particular C-flows to particular P-tunnels.
入口复制可用于实例化任何类型的PMSI。当入口复制完成时，建议进行显式跟踪，并且只将特定C流的数据包发送给需要查看该C流的数据包的PE，下一段中提到的一种特殊情况除外。无需使用第7.4节中的程序将特定C-流绑定到特定P-隧道。
The particular case in which there is no need for explicit tracking is the case where ingress replication is being used to create a one-hop ASBR-ASBR inter-AS segment of an segmented inter-AS P-tunnel.
不需要显式跟踪的特定情况是使用入口复制来创建分段的inter-AS P隧道的单跳ASBR-ASBR inter-AS段的情况。
Section 9.1 specifies three different methods that can be used to prevent duplication of multicast data packets. Any given deployment must use at least one of those methods. Note that the method described in Section 9.1.1 ("Discarding Packets from Wrong PE") presupposes that the egress PE of a P-tunnel can, upon receiving a packet from the P-tunnel, determine the identity of the PE that transmitted the packet into the P-tunnel. SPs that use ingress replication to instantiate their PMSIs are cautioned against this use for this purpose of unicast P-tunnel technologies that do not allow the egress PE to identify the ingress PE (e.g., MP2P LSPs for which penultimate-hop-popping is done). Deployment of ingress replication with such P-tunnel technology MUST NOT be done unless it is known that the deployment relies entirely on the procedures of Sections 9.1.2 or 9.1.3 for duplicate prevention.
第9.1节规定了可用于防止多播数据包重复的三种不同方法。任何给定的部署都必须至少使用其中一种方法。注意，第9.1.1节中描述的方法（“从错误的PE丢弃数据包”）假定P隧道的出口PE在从P隧道接收数据包时，可以确定将数据包传输到P隧道的PE的身份。对于使用入口复制来实例化其PMSI的SP，应注意不要使用单播P隧道技术，该技术不允许出口PE识别入口PE（例如，进行倒数第二跳弹出的MP2P LSP）。除非已知部署完全依赖于第9.1.2节或第9.1.3节中防止复制的程序，否则不得使用此类P-tunnel技术部署入口复制。
As discussed previously, Intra-AS I-PMSI A-D routes may (or may not) have PMSI Tunnel attributes, identifying P-tunnels that can be used as the default P-tunnels for carrying C-multicast traffic, i.e., for carrying C-multicast traffic that has not been specifically bound to another P-tunnel.
如前所述，As内I-PMSI A-D路由可以（也可以不）具有PMSI隧道属性，识别可被用作承载C多播业务的默认P隧道的P隧道，即，用于承载未特定绑定到另一P隧道的C多播业务。
If none of the Intra-AS I-PMSI A-D routes originated by a particular PE for a particular MVPN carry PMSI Tunnel attributes at all (or if the only PMSI Tunnel attributes they carry have type "No tunnel information present"), then there are no default P-tunnels for that PE to use when transmitting C-multicast traffic in that MVPN to other PEs. In that case, all such C-flows must be assigned to specific P-tunnels using one of the mechanisms specified in Section 7.4. That is, all such C-flows are carried on P-tunnels that instantiate S-PMSIs.
如果由特定PE为特定MVPN发起的内部AS I-PMSI A-D路由中没有任何一个携带PMSI隧道属性（或者如果它们携带的唯一PMSI隧道属性的类型为“无隧道信息存在”），则在将该MVPN中的C多播流量传输到其他PE时，该PE没有默认的P隧道可供使用。在这种情况下，必须使用第7.4节规定的机制之一将所有此类C流分配给特定的P隧道。也就是说，所有此类C流都在实例化S-PMSI的P隧道上进行。
There are other cases where it may be either necessary or desirable to use the mechanisms of Section 7.4 to identify specific C-flows and bind them to or unbind them from specific P-tunnels. Some possible cases are as follows:
在其他情况下，可能需要或希望使用第7.4节中的机制来识别特定的C-流，并将其绑定到特定的P-隧道或从中解除绑定。一些可能的情况如下：
- The policy for a particular MVPN is to send all C-data on S-PMSIs, even if the Intra-AS I-PMSI A-D routes carry PMSI Tunnel attributes. (This is another case where all C-data is carried on S-PMSIs; presumably, the I-PMSIs are used for control information.)
- 特定MVPN的策略是在S-PMSI上发送所有C数据，即使内部AS I-PMSI a-D路由带有PMSI隧道属性。（这是另一种情况，其中所有C数据都携带在S-PMSIs上；据推测，I-PMSIs用于控制信息。）
- It is desired to optimize the routing of the particular C-flow, which may already be traveling on an I-PMSI, by sending it instead on an S-PMSI.
- 期望通过在S-PMSI上发送来优化特定C流的路由，该特定C流可能已经在I-PMSI上移动。
- If a particular C-flow is traveling on an S-PMSI, it may be considered desirable to move it to an I-PMSI (i.e., optimization of the routing for that flow may no longer be considered desirable).
- 如果特定C流在S-PMSI上移动，则可能认为需要将其移动到I-PMSI（即，可能不再认为需要优化该流的路由）。
- It is desired to change the encapsulation used to carry the C-flow, e.g., because one now wants to aggregate it on a P-tunnel with flows from other MVPNs.
- 希望更改用于承载C流的封装，例如，因为现在希望在P通道上将其与来自其他MVPN的流聚合。
Note that if Full PIM Peering over an MI-PMSI (Section 5.2) is being used, then from the perspective of the PIM state machine, the "interface" connecting the PEs to each other is the MI-PMSI, even if some or all of the C-flows are being sent on S-PMSIs. That is, from
请注意，如果使用MI-PMSI上的完整PIM对等（第5.2节），则从PIM状态机的角度来看，将PEs相互连接的“接口”是MI-PMSI，即使部分或全部C流通过S-PMSI发送。就是从
the perspective of the C-PIM state machine, when a C-flow is being sent or received on an S-PMSI, the output or input interface (respectively) is considered to be the MI-PMSI.
从C-PIM状态机的角度来看，当在S-PMSI上发送或接收C流时，输出或输入接口（分别）被视为MI-PMSI。
Section 7.1 discusses certain general considerations that apply whenever a specified C-flow is bound to a specified P-tunnel using the mechanisms of Section 7.4. This includes the case where the C-flow is moved from one P-tunnel to another as well as the case where the C-flow is initially bound to an S-PMSI P-tunnel.
第7.1节讨论了当使用第7.4节中的机制将指定的C流绑定到指定的P隧道时适用的某些一般注意事项。这包括C流从一个P隧道移动到另一个P隧道的情况，以及C流最初绑定到S-PMSI P隧道的情况。
Section 7.2 discusses the specific case of using the mechanisms of Section 7.4 as a way of optimizing multicast routing by switching specific flows from one P-tunnel to another.
第7.2节讨论了使用第7.4节中的机制，通过将特定流从一个P隧道切换到另一个P隧道来优化多播路由的具体情况。
Section 7.3 discusses the case where the mechanisms of Section 7.4 are used to announce the presence of "unsolicited flooded data" and to assign such data to a particular P-tunnel.
第7.3节讨论了使用第7.4节中的机制宣布存在“未经请求的洪水数据”并将此类数据分配给特定P隧道的情况。
Section 7.4 specifies the protocols for assigning specific C-flows to specific P-tunnels. These protocols may be used to assign a C-flow to a P-tunnel initially or to switch a flow from one P-tunnel to another.
第7.4节规定了将特定C-流分配给特定P-隧道的协议。这些协议可用于最初将C流分配给P隧道，或将流从一个P隧道切换到另一个P隧道。
Procedures for binding to a specified P-tunnel the set of C-flows traveling along a specified C-tree (or for so binding a set of C-flows that share some relevant characteristic), without identifying each flow individually, are outside the scope of this document.
将沿着指定C-树移动的一组C-流绑定到指定的P-隧道（或将共享某些相关特征的一组C-流绑定到指定的P-隧道）而不单独标识每个流的程序不在本文件的范围内。
The decision to bind a particular C-flow (designated as (C-S,C-G)) to a particular P-tunnel, or to switch a particular C-flow to a particular P-tunnel, is always made by the PE that is to transmit the C-flow onto the P-tunnel.
将特定C流（指定为（C-S，C-G））绑定到特定P隧道或将特定C流切换到特定P隧道的决定始终由将C流传输到P隧道的PE作出。
Whenever a PE moves a particular C-flow from one P-tunnel, say P1, to another, say P2, care must be taken to ensure that there is no steady state duplication of traffic. At any given time, the PE transmits the C-flow either on P1 or on P2, but not on both.
每当PE将特定的C流从一个P隧道（如P1）移动到另一个P隧道（如P2）时，必须注意确保没有稳态流量重复。在任何给定时间，PE在P1或P2上传输C流，但不在两者上传输。
When a particular PE, say PE1, decides to bind a particular C-flow to a particular P-tunnel, say P2, the following procedures MUST be applied:
当特定PE（如PE1）决定将特定C流绑定到特定P隧道（如P2）时，必须应用以下程序：
- PE1 must issue the required control plane information to signal that the specified C-flow is now bound to P-tunnel P2 (see Section 7.4).
- PE1必须发布所需的控制平面信息，以表明指定的C流现在绑定到P隧道P2（见第7.4节）。
- If P-tunnel P2 needs to be constructed from the root downwards, PE1 must initiate the signaling to construct P2. This is only required if P2 is an RSVP-TE P2MP LSP.
- 如果P隧道P2需要从根向下构造，则PE1必须启动构造P2的信令。仅当P2是RSVP-TE P2MP LSP时才需要此选项。
- If the specified C-flow is currently bound to a different P-tunnel, say P1, then:
- 如果指定的C流当前绑定到不同的P通道，例如P1，则：
* PE1 MUST wait for a "switch-over" delay before sending traffic of the C-flow on P-tunnel P2. It is RECOMMENDED to allow this delay to be configurable.
* PE1必须等待“切换”延迟，然后才能在P隧道P2上发送C流流量。建议允许对该延迟进行配置。
* Once the "switch-over" delay has elapsed, PE1 MUST send traffic for the C-flow on P2 and MUST NOT send it on P1. In no case is any C-flow packet sent on both P-tunnels.
* 一旦“切换”延迟过去，PE1必须在P2上发送C流的通信量，不得在P1上发送。在任何情况下，都不会在两个P通道上发送任何C-flow数据包。
When a C-flow is switched from one P-tunnel to another, the purpose of running a switch-over timer is to minimize packet loss without introducing packet duplication. However, jitter may be introduced due to the difference in transit delays between the old and new P-tunnels.
当C流从一个P隧道切换到另一个P隧道时，运行切换计时器的目的是在不引入数据包复制的情况下最小化数据包丢失。然而，由于新旧P隧道之间传输延迟的差异，可能会引入抖动。
For best effect, the switch-over timer should be configured to a value that is "just long enough" (a) to allow all the PEs to learn about the new binding of C-flow to P-tunnel and (b) to allow the PEs to construct the P-tunnel, if it doesn't already exist.
为了获得最佳效果，应将切换计时器配置为“刚好足够长”的值（a）允许所有PE了解C-flow与P-tunnel的新绑定，以及（b）允许PE构建P-tunnel（如果P-tunnel不存在）。
If, after such a switch, the "old" P-tunnel P1 is no longer needed, it SHOULD be torn down and the resources supporting it freed. The procedures for "tearing down" a P-tunnel are specific to the P-tunnel technology.
如果在这样一次切换之后，“旧”P隧道P1不再需要，则应将其拆除并释放支持它的资源。“拆除”P型隧道的程序特定于P型隧道技术。
Procedures for binding sets of C-flows traveling along specified C-trees (or sets of C-flows sharing any other characteristic) to a specified P-tunnel (or for moving them from one P-tunnel to another) are outside the scope of this document.
将沿着指定C-树移动的C-流集合（或具有任何其他特征的C-流集合）绑定到指定P-隧道（或将其从一个P-隧道移动到另一个P-隧道）的程序不在本文件的范围内。
Suppose that a particular PE, say PE1, learns, via the procedures of Section 7.4, that some other PE, say PE2, has bound a particular C-flow, designated as (C-S,C-G), to a particular P-tunnel, say P2. Then, PE1 must determine whether it needs to receive (C-S,C-G) traffic from PE2.
假设某一特定PE（如PE1）通过第7.4节的程序得知某一其他PE（如PE2）已将指定为（C-S，C-G）的特定C流绑定到特定P隧道（如P2）。然后，PE1必须确定它是否需要从PE2接收（C-S，C-G）流量。
If BGP is being used to distribute C-multicast routing information from PE to PE, the conditions under which PE1 needs to receive (C-S,C-G) traffic from PE2 are specified in Section 12.3 of [MVPN-BGP].
如果使用BGP将C多播路由信息从PE分发到PE，则[MVPN-BGP]第12.3节规定了PE1需要从PE2接收（C-S，C-G）流量的条件。
If PIM over an MI-PMSI is being used to distribute C-multicast routing from PE to PE, PE1 needs to receive (C-S,C-G) traffic from PE2 if one or more of the following conditions holds:
如果MI-PMSI上的PIM用于将C多播路由从PE分发到PE，则如果以下一个或多个条件成立，PE1需要从PE2接收（C-S、C-G）通信量：
- PE1 has (C-S,C-G) state such that PE2 is PE1's Upstream PE for (C-S,C-G), and PE1 has downstream neighbors ("non-null olist") for the (C-S,C-G) state.
- PE1具有（C-S，C-G）状态，因此PE2是PE1的（C-S，C-G）上游PE，而PE1具有（C-S，C-G）状态的下游邻居（“非空olist”）。
- PE1 has (C-*,C-G) state with an Upstream PE (not necessarily PE2) and with downstream neighbors ( "non-null olist"), but PE1 does not have (C-S,C-G) state.
- PE1具有上游PE（不一定为PE2）和下游邻居（“非空olist”）的（C-*，C-G）状态，但PE1不具有（C-S，C-G）状态。
- Native PIM methods are being used to prevent steady-state packet duplication, and PE1 has either (C-*,C-G) or (C-S,C-G) state such that the MI-PMSI is one of the downstream interfaces. Note that this includes the case where PE1 is itself sending (C-S,C-G) traffic on an S-PMSI. (In this case, PE1 needs to receive the (C-S,C-G) traffic from PE2 in order to allow the PIM Assert mechanism to function properly.)
- 本机PIM方法用于防止稳态数据包复制，PE1具有（C-*，C-G）或（C-S，C-G）状态，因此MI-PMSI是下游接口之一。注意，这包括PE1本身在S-PMSI上发送（C-S，C-G）通信量的情况。（在这种情况下，PE1需要从PE2接收（C-S，C-G）通信量，以允许PIM断言机制正常工作。）
Irrespective of whether BGP or PIM is being used to distribute C-multicast routing information, once PE1 determines that it needs to receive (C-S,C-G) traffic from PE2, the following procedures MUST be applied:
无论是BGP还是PIM用于分发C-多播路由信息，一旦PE1确定需要从PE2接收（C-S、C-G）流量，则必须应用以下过程：
- PE1 MUST take all necessary steps to be able to receive the (C-S,C-G) traffic on P2.
- PE1必须采取所有必要步骤，以便能够接收P2上的（C-S、C-G）流量。
* If P2 is a PIM tunnel or an mLDP LSP, PE1 will need to use PIM or mLDP (respectively) to join P2 (unless it is already joined to P2).
* 如果P2是PIM隧道或mLDP LSP，PE1将需要使用PIM或mLDP（分别）来连接P2（除非它已经连接到P2）。
* PE1 may need to modify the forwarding state for (C-S,C-G) to indicate that (C-S,C-G) traffic is to be accepted on P2. If P2 is an Aggregate Tree, this also implies setting up the demultiplexing forwarding entries based on the inner label as described in Section 6.3.3
* PE1可能需要修改（C-S，C-G）的转发状态，以指示（C-S，C-G）流量将在P2上被接受。如果P2是聚合树，这也意味着根据第6.3.3节所述的内部标签设置解复用转发条目
- If PE1 was previously receiving the (C-S,C-G) C-flow on another P-tunnel, say P1, then:
- 如果PE1先前在另一个P通道（如P1）上接收（C-S，C-G）C流，则：
* PE1 MAY run a switch-over timer, and until it expires, SHOULD accept traffic for the given C-flow on both P1 and P2;
* PE1可以运行切换计时器，并且在其到期之前，应接受P1和P2上给定C流的流量；
* If, after such a switch, the "old" P-tunnel P1 is no longer needed, it SHOULD be torn down and the resources supporting it freed. The procedures for "tearing down" a P-tunnel are specific to the P-tunnel technology.
* 如果在这样一次切换之后，“旧”P隧道P1不再需要，则应将其拆除并释放支持它的资源。“拆除”P型隧道的程序特定于P型隧道技术。
- If PE1 later determines that it no longer needs to receive any of the C-multicast data that is being sent on a particular P-tunnel, it may initiate signaling (specific to the P-tunnel technology) to remove itself from that tunnel.
- 如果PE1稍后确定它不再需要接收在特定P隧道上发送的任何C多播数据，那么它可以发起信令（特定于P隧道技术）以将自己从该隧道中移除。
Whenever a particular multicast stream is being sent on an I-PMSI, it is likely that the data of that stream is being sent to PEs that do not require it. If a particular stream has a significant amount of traffic, it may be beneficial to move it to an S-PMSI that includes only those PEs that are transmitters and/or receivers (or at least includes fewer PEs that are neither).
每当在I-PMSI上发送特定的多播流时，该流的数据很可能被发送到不需要它的PEs。如果特定流具有大量业务量，则将其移动到仅包括作为发射机和/或接收机的那些pe（或至少包括较少的既不是发射机又不是接收机的pe）的S-PMSI可能是有益的。
If explicit tracking is being done, S-PMSI creation can also be triggered on other criteria. For instance, there could be a "pseudo-wasted bandwidth" criterion: switching to an S-PMSI would be done if the bandwidth multiplied by the number of uninterested PEs (PE that are receiving the stream but have no receivers) is above a specified threshold. The motivation is that (a) the total bandwidth wasted by many sparsely subscribed low-bandwidth groups may be large and (b) there's no point to moving a high-bandwidth group to an S-PMSI if all the PEs have receivers for it.
如果正在进行显式跟踪，还可以根据其他条件触发S-PMSI创建。例如，可能存在一个“伪浪费带宽”标准：如果带宽乘以不感兴趣的PE（接收流但没有接收器的PE）的数量高于指定阈值，则切换到S-PMSI。其动机是：（a）许多稀疏订阅的低带宽组浪费的总带宽可能很大；（b）如果所有PEs都有接收器，那么将高带宽组移动到s-PMSI是没有意义的。
Switching a (C-S,C-G) stream to an S-PMSI may require the root of the S-PMSI to determine the egress PEs that need to receive the (C-S,C-G) traffic. This is true in the following cases:
将（C-S，C-G）流切换到S-PMSI可能需要S-PMSI的根来确定需要接收（C-S，C-G）业务的出口pe。在以下情况下也是如此：
- If the P-tunnel is a source-initiated tree, such as an RSVP-TE P2MP Tunnel, the PE needs to know the leaves of the tree before it can instantiate the S-PMSI.
- 如果P-tunnel是源启动的树，例如RSVP-TE P2MP隧道，则PE需要知道树的叶子，然后才能实例化S-PMSI。
- If a PE instantiates multiple S-PMSIs, belonging to different MVPNs, using one P-multicast tree, such a tree is termed an Aggregate Tree with a selective mapping. The setting up of such an Aggregate Tree requires the ingress PE to know all the other PEs that have receivers for multicast groups that are mapped onto the tree.
- 如果PE使用一个P多播树实例化属于不同MVPN的多个S-PMSI，则这种树被称为具有选择性映射的聚合树。建立这种聚合树需要入口PE知道所有其他PE，这些PE具有映射到树上的多播组的接收器。
The above two cases require that explicit tracking be done for the (C-S,C-G) stream. The root of the S-PMSI MAY decide to do explicit tracking of this stream only after it has determined to move the stream to an S-PMSI, or it MAY have been doing explicit tracking all along.
上述两种情况要求对（C-S，C-G）流进行显式跟踪。S-PMSI的根可能仅在其已确定将流移动到S-PMSI之后才决定对此流进行显式跟踪，或者其可能一直在进行显式跟踪。
If the S-PMSI is instantiated by a P-multicast tree, the PE at the root of the tree must signal the leaves of the tree that the (C-S,C-G) stream is now bound to the S-PMSI. Note that the PE could create the identity of the P-multicast tree prior to the actual instantiation of the P-tunnel.
如果S-PMSI由P-多播树实例化，则树根的PE必须向树的叶子发出信号，表示（C-S，C-G）流现在绑定到S-PMSI。注意，PE可以在P-tunnel的实际实例化之前创建P-multicast树的标识。
If the S-PMSI is instantiated by a source-initiated P-multicast tree (e.g., an RSVP-TE P2MP tunnel), the PE at the root of the tree must establish the source-initiated P-multicast tree to the leaves. This tree MAY have been established before the leaves receive the S-PMSI binding, or it MAY be established after the leaves receive the binding. The leaves MUST NOT switch to the S-PMSI until they receive both the binding and the tree signaling message.
如果S-PMSI由源启动的P-多播树（例如，RSVP-TE P2MP隧道）实例化，则树根的PE必须在叶子上建立源启动的P-多播树。该树可能在叶接收S-PMSI绑定之前建立，也可能在叶接收绑定之后建立。叶子在收到绑定和树信令消息之前不得切换到S-PMSI。
A PE may receive "unsolicited" data from a CE, where the data is intended to be flooded to the other PEs of the same MVPN and then on to other CEs. By "unsolicited", we mean that the data is to be delivered to all the other PEs of the MVPN, even though those PEs may not have sent any control information indicating that they need to receive that data.
PE可以从CE接收“未经请求的”数据，其中数据将被淹没到同一MVPN的其他PE，然后再传输到其他CE。所谓“未经请求”，我们的意思是将数据交付给MVPN的所有其他PE，即使这些PE可能没有发送任何控制信息，表明他们需要接收该数据。
For example, if the BSR [BSR] is being used within the MVPN, BSR control messages may be received by a PE from a CE. These need to be forwarded to other PEs, even though no PE ever issues any kind of explicit signal saying that it wants to receive BSR messages.
例如，如果BSR[BSR]正在MVPN内使用，则BSR控制消息可由PE从CE接收。这些需要转发到其他PE，即使没有任何PE发出任何明确的信号表示希望接收BSR消息。
If a PE receives a BSR message from a CE, and if the CE's MVPN has an MI-PMSI, then the PE can just send BSR messages on the appropriate P-tunnel. Otherwise, the PE MUST announce the binding of a particular C-flow to a particular P-tunnel, using the procedures of Section 7.4. The particular C-flow in this case would be (C-IPaddress_of_PE, ALL-PIM-ROUTERS). The P-tunnel identified by the procedures of Section 7.4 may or may not be one that was previously identified in the PMSI Tunnel attribute of an I-PMSI A-D route. Further procedures for handling BSR may be found in Sections 5.2.1 and 5.3.4.
如果PE从CE接收到BSR消息，并且CE的MVPN具有MI-PMSI，则PE可以仅在适当的P隧道上发送BSR消息。否则，PE必须使用第7.4节的程序宣布特定C流与特定P隧道的绑定。在这种情况下，特定的C-flow是（C-IPaddress\u of\u PE，ALL-PIM-router）。第7.4节程序确定的P隧道可能是也可能不是先前在I-PMSI A-D路线的PMSI隧道属性中确定的P隧道。处理BSR的进一步程序见第5.2.1节和第5.3.4节。
Analogous procedures may be used for announcing the presence of other sorts of unsolicited flooded data, e.g., dense mode data or data from proprietary protocols that presume messages can be flooded. However, a full specification of the procedures for traffic other than BSR traffic is outside the scope of this document.
类似程序可用于宣布存在其他种类的未经请求的被淹没数据，例如密集模式数据或来自假定消息可以被淹没的专有协议的数据。但是，除BSR流量外的其他流量的完整程序规范不在本文件范围内。
We describe two protocols for binding C-flows to P-tunnels.
我们描述了将C流绑定到P隧道的两个协议。
These protocols can be used for moving C-flows from I-PMSIs to S-PMSIs, as long as the S-PMSI is instantiated by a P-multicast tree. (If the S-PMSI is instantiated by means of ingress replication, the procedures of Section 6.4.5 suffice.)
这些协议可用于将C流从I-PMSI移动到S-PMSI，只要S-PMSI由P-多播树实例化。（如果S-PMSI是通过入口复制进行实例化的，则第6.4.5节中的程序就足够了。）
These protocols can also be used for other cases in which it is necessary to bind specific C-flows to specific P-tunnels.
这些协议也可用于其他需要将特定C流绑定到特定P隧道的情况。
Not withstanding the name of the mechanism "S-PMSI A-D routes", the mechanism to be specified in this section may be used any time it is necessary to advertise a binding of a C-flow to a particular P-tunnel.
尽管机制名称为“S-PMSI A-D routes”，但本节中规定的机制可在有必要将C流绑定到特定P隧道的任何时候使用。
The ingress PE informs all the PEs that are on the path to receivers of the (C-S,C-G) of the binding of the P-tunnel to the (C-S,C-G). The BGP announcement is done by sending an update for the MCAST-VPN address family. An S-PMSI A-D route is used, containing the following information:
入口PE通知（C-S，C-G）接收器路径上的所有PE P隧道与（C-S，C-G）的绑定。BGP公告通过发送MCAST-VPN地址系列的更新来完成。使用S-PMSI A-D路由，包含以下信息：
1. The IP address of the originating PE.
1. 发起PE的IP地址。
2. The RD configured locally for the MVPN. This is required to uniquely identify the (C-S,C-G) as the addresses could overlap between different MVPNs. This is the same RD value used in the auto-discovery process.
2. 本地为MVPN配置的RD。这是唯一标识（C-S，C-G）所必需的，因为地址可能在不同MVPN之间重叠。这与自动发现过程中使用的RD值相同。
3. The C-S address.
3. C-S地址。
4. The C-G address.
4. C-G地址。
5. A PE MAY use a single P-tunnel to aggregate two or more S-PMSIs. If the PE already advertised unaggregated S-PMSI A-D routes for these S-PMSIs, then a decision to aggregate them requires the PE to re-advertise these routes. The re-
5. PE可使用单个P通道聚合两个或多个S-PMSI。如果PE已经为这些S-PMSI发布了未聚合的S-PMSI A-D路由，则聚合这些路由的决定要求PE重新发布这些路由。再-
advertised routes MUST be the same as the original ones, except for the PMSI Tunnel attribute. If the PE has not previously advertised S-PMSI A-D routes for these S-PMSIs, then the aggregation requires the PE to advertise (new) S-PMSI A-D routes for these S-PMSIs. The PMSI Tunnel attribute in the newly advertised/re-advertised routes MUST carry the identity of the P-tunnel that aggregates the S-PMSIs.
播发的路由必须与原始路由相同，但PMSI隧道属性除外。如果PE之前没有为这些S-PMSI播发S-PMSI A-D路由，则聚合要求PE为这些S-PMSI播发（新的）S-PMSI A-D路由。新公布/重新公布的路由中的PMSI隧道属性必须具有聚合S-PMSI的P隧道的标识。
If all these aggregated S-PMSIs belong to the same MVPN, and this MVPN uses PIM as its C-multicast routing protocol, then the corresponding S-PMSI A-D routes MAY carry an MPLS upstream-assigned label [MPLS-UPSTREAM-LABEL]. Moreover, in this case, the labels MUST be distinct on a per-MVPN basis, and MAY be distinct on a per-route basis.
如果所有这些聚合的S-PMSI属于相同的MVPN，并且该MVPN使用PIM作为其C-多播路由协议，则相应的S-PMSI A-D路由可以携带MPLS上游分配的标签[MPLS-上游标签]。此外，在这种情况下，标签必须在每个MVPN的基础上是不同的，并且可能在每个路由的基础上是不同的。
If all these aggregated S-PMSIs belong to the MVPN(s) that use mLDP as its C-multicast routing protocol, then the corresponding S-PMSI A-D routes MUST carry an MPLS upstream-assigned label [MPLS-UPSTREAM-LABEL], and these labels MUST be distinct on a per-route (per-mLDP-FEC) basis, irrespective of whether the aggregated S-PMSIs belong to the same or different MVPNs.
如果所有这些聚合的S-PMSI属于使用mLDP作为其C-多播路由协议的MVPN，则相应的S-PMSI A-D路由必须携带MPLS上游分配的标签[MPLS-上游标签]，并且这些标签必须在每个路由（每个mLDP FEC）的基础上是不同的，无论聚合的S-PMSI是否属于相同或不同的MVPN。
When a PE distributes this information via BGP, it must include the following:
PE通过BGP分发此信息时，必须包括以下内容：
1. An identifier for the particular P-tunnel to which the stream is to be bound. This identifier is a structured field that includes the following information:
1. 流要绑定到的特定P隧道的标识符。此标识符是一个结构化字段，包含以下信息：
* The type of tunnel
* 隧道类型
* An identifier for the tunnel. The form of the identifier will depend upon the tunnel type. The combination of tunnel identifier and tunnel type should contain enough information to enable all the PEs to "join" the tunnel and receive messages from it.
* 隧道的标识符。标识符的形式取决于隧道类型。隧道标识符和隧道类型的组合应包含足够的信息，使所有PE能够“加入”隧道并从中接收消息。
2. Route Target Extended Communities attribute. This is used as described in Section 4.
2. 路由目标扩展社区属性。如第4节所述使用。
If the PE wants to enable explicit tracking for the specified flow, it also indicates this in the A-D route it uses to bind the flow to a particular P-tunnel. Then, any PE that receives the A-D route will
如果PE希望对指定流启用显式跟踪，它还将在用于将流绑定到特定P隧道的A-D路由中指示这一点。然后，接收A-D路由的任何PE将
respond with a "Leaf A-D route" in which it identifies itself as a receiver of the specified flow. The Leaf A-D route will be withdrawn when the PE is no longer a receiver for the flow.
使用“叶a-D路由”进行响应，在该路由中，它将自己标识为指定流的接收者。当PE不再是流的接收器时，叶A-D路由将被撤回。
If the PE needs to enable explicit tracking for a flow without at the same time binding the flow to a specific P-tunnel, it can do so by sending an S-PMSI A-D route whose NLRI identifies the flow and whose PMSI Tunnel attribute has its tunnel type value set to "no tunnel information present" and its "leaf information required" bit set to 1. This will elicit the Leaf A-D routes. This is useful when the PE needs to know the receivers before selecting a P-tunnel.
如果PE需要在不同时将流绑定到特定P隧道的情况下启用流的显式跟踪，则可以通过发送S-PMSI a-D路由来实现，该S-PMSI a-D路由的NLRI标识流，并且其PMSI隧道属性的隧道类型值设置为“无隧道信息存在”，其“所需叶信息”位设置为1。这将引出叶A-D路线。当PE需要在选择P隧道之前了解接收器时，这非常有用。
This procedure carries its control messages in UDP and requires that the MVPN have an MI-PMSI that can be used to carry the control messages.
此过程以UDP传输其控制消息，并要求MVPN具有可用于传输控制消息的MI-PMSI。
In order for a given PE to move a particular C-flow to a particular P-tunnel, an "S-PMSI Join message" is sent periodically on the MI-PMSI. (Notwithstanding the name of the mechanism, the mechanism may be used to bind a flow to any P-tunnel.) The S-PMSI Join message is a UDP-encapsulated message whose destination address is ALL-PIM-ROUTERS (224.0.0.13) and whose destination port is 3232.
为了使给定PE将特定C流移动到特定P隧道，在MI-PMSI上定期发送“S-PMSI连接消息”。（不管机制的名称如何，该机制可用于将流绑定到任何P隧道。）S-PMSI连接消息是UDP封装的消息，其目标地址为ALL-PIM-ROUTERS（224.0.0.13），其目标端口为3232。
The S-PMSI Join message contains the following information:
S-PMSI Join消息包含以下信息：
- An identifier for the particular multicast stream that is to be bound to the P-tunnel. This can be represented as an (S,G) pair.
- 要绑定到P隧道的特定多播流的标识符。这可以表示为（S，G）对。
- An identifier for the particular P-tunnel to which the stream is to be bound. This identifier is a structured field that includes the following information:
- 流要绑定到的特定P隧道的标识符。此标识符是一个结构化字段，包含以下信息：
* The type of tunnel used to instantiate the S-PMSI.
* 用于实例化S-PMSI的隧道类型。
* An identifier for the tunnel. The form of the identifier will depend upon the tunnel type. The combination of tunnel identifier and tunnel type should contain enough information to enable all the PEs to "join" the tunnel and receive messages from it.
* 隧道的标识符。标识符的形式取决于隧道类型。隧道标识符和隧道类型的组合应包含足够的信息，使所有PE能够“加入”隧道并从中接收消息。
* If (and only if) the identified P-tunnel is aggregating several S-PMSIs, any demultiplexing information needed by the tunnel encapsulation protocol to identify a particular S-PMSI.
* 如果（且仅当）所识别的P-隧道正在聚合多个S-PMSI，则隧道封装协议需要的任何解复用信息以识别特定S-PMSI。
If the policy for the MVPN is that traffic is sent/received by default over an MI-PMSI, then traffic for a particular C-flow can be switched back to the MI-PMSI simply by ceasing to send S-PMSI Joins for that C-flow.
如果MVPN的策略是默认情况下通过MI-PMSI发送/接收流量，则只需停止发送该C流的S-PMSI连接，即可将特定C流的流量切换回MI-PMSI。
Note that an S-PMSI Join that is not received over a PMSI (e.g., one that is received directly from a CE) is an illegal packet that MUST be discarded.
请注意，未通过PMSI接收的S-PMSI连接（例如，直接从CE接收的连接）是必须丢弃的非法数据包。
The S-PMSI Join message is encapsulated within UDP and has the following type/length/value (TLV) encoding:
S-PMSI连接消息封装在UDP中，具有以下类型/长度/值（TLV）编码：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits)
类型（8位）
Length (16 bits): the total number of octets in the Type, Length, and Value fields combined
长度（16位）：类型、长度和值字段中的八位字节总数
Value (variable length)
值（可变长度）
In this specification, only one type of S-PMSI Join is defined. A Type 1 S-PMSI Join is used when the S-PMSI tunnel is a PIM tunnel that is used to carry a single multicast stream, where the packets of that stream have IPv4 source and destination IP addresses.
在本规范中，仅定义了一种S-PMSI连接类型。当S-PMSI隧道是用于承载单个多播流的PIM隧道时，使用类型1 S-PMSI连接，其中该流的数据包具有IPv4源和目标IP地址。
The S-PMSI Join format to use when the C-source and C-group are IPv6 addresses will be defined in a follow-on document.
C源和C组为IPv6地址时使用的S-PMSI连接格式将在后续文档中定义。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P-group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits): 1
类型（8位）：1
Length (16 bits): 16
长度（16位）：16
Reserved (8 bits): This field SHOULD be zero when transmitted, and MUST be ignored when received.
保留（8位）：此字段在传输时应为零，在接收时必须忽略。
C-source (32 bits): the IPv4 address of the traffic source in the VPN.
C-source（32位）：VPN中流量源的IPv4地址。
C-group (32 bits): the IPv4 address of the multicast traffic destination address in the VPN.
C组（32位）：VPN中多播通信目标地址的IPv4地址。
P-group (32 bits): the IPv4 group address that the PE router is going to use to encapsulate the flow (C-source, C-group).
P-group（32位）：PE路由器将用于封装流的IPv4组地址（C-source，C-group）。
The P-group identifies the S-PMSI P-tunnel, and the (C-S,C-G) identifies the multicast flow that is carried in the P-tunnel.
P组标识S-PMSI P-tunnel，而（C-S，C-G）标识P-tunnel中承载的多播流。
The protocol uses the following constants.
协议使用以下常量。
[S-PMSI_DELAY]:
[S-PMSI_延迟]：
Once an S-PMSI Join message has been sent, the PE router that is to transmit onto the S-PMSI will delay this amount of time before it begins using the S-PMSI. The default value is 3 seconds.
一旦发送了S-PMSI加入消息，要传输到S-PMSI的PE路由器将在开始使用S-PMSI之前延迟该时间量。默认值为3秒。
[S-PMSI_TIMEOUT]:
[S-PMSI_超时]：
If a PE (other than the transmitter) does not receive any packets over the S-PMSI P-tunnel for this amount of time, the PE will prune itself from the S-PMSI P-tunnel, and will expect (C-S,C-G) packets to arrive on an I-PMSI. The default value is 3 minutes.
如果PE（发送器除外）在这段时间内没有通过S-PMSI P隧道接收到任何数据包，则PE将从S-PMSI P隧道中删除自身，并期望（C-S，C-G）数据包到达I-PMSI。默认值为3分钟。
This value must be consistent among PE routers.
此值在PE路由器之间必须一致。
[S-PMSI_HOLDOWN]:
[S-PMSI_HOLDOWN]：
If the PE that transmits onto the S-PMSI does not see any (C-S,C-G) packets for this amount of time, it will resume sending (C-S,C-G) packets on an I-PMSI.
如果发送到S-PMSI的PE在这段时间内没有看到任何（C-S，C-G）数据包，它将恢复在I-PMSI上发送（C-S，C-G）数据包。
This is used to avoid oscillation when traffic is bursty. The default value is 1 minute.
这用于避免在流量突发时出现振荡。默认值为1分钟。
[S-PMSI_INTERVAL]:
[S-PMSI_间隔]：
The interval the transmitting PE router uses to periodically send the S-PMSI Join message. The default value is 60 seconds.
发送PE路由器用于定期发送S-PMSI连接消息的间隔。默认值为60秒。
S-PMSIs can be aggregated on a P-multicast tree. The S-PMSI to (C-S,C-G) binding advertisement supports aggregation. Furthermore, the aggregation procedures of Section 6.3 apply. It is also possible to aggregate both S-PMSIs and I-PMSIs on the same P-multicast tree.
S-PMSIs可以聚合到P-多播树上。S-PMSI到（C-S，C-G）绑定播发支持聚合。此外，第6.3节的汇总程序适用。也可以在同一个P多播树上聚合S-PMSIs和I-PMSIs。
If an MVPN has sites in more than one AS, it requires one or more PMSIs to be instantiated by inter-AS P-tunnels. This document describes two different types of inter-AS P-tunnel:
如果MVPN在多个AS中有站点，则需要一个或多个PMSI由AS间P隧道实例化。本文件描述了两种不同类型的内部AS P隧道：
1. "Segmented inter-AS P-tunnels"
1. “分段式区间P型隧道”
A segmented inter-AS P-tunnel consists of a number of independent segments that are stitched together at the ASBRs. There are two types of segment: inter-AS segments and intra-AS segments. The segmented inter-AS P-tunnel consists of alternating intra-AS and inter-AS segments.
分段式AS间P隧道由许多在ASBR处缝合在一起的独立段组成。有两种类型的段：内部AS段和内部AS段。分段AS间P隧道由交替的AS内和AS间段组成。
Inter-AS segments connect adjacent ASBRs of different ASes; these "one-hop" segments are instantiated as unicast P-tunnels.
AS间段连接不同ASE的相邻ASBR；这些“一跳”段被实例化为单播P隧道。
Intra-AS segments connect ASBRs and PEs that are in the same AS. An intra-AS segment may be of whatever technology is desired by the SP that administers the that AS. Different intra-AS segments may be of different technologies.
AS内段连接与相同的ASBR和PE。AS内段可以是管理AS的SP所需的任何技术。不同的内部AS段可能具有不同的技术。
Note that the intra-AS segments of inter-AS P-tunnels form a category of P-tunnels that is distinct from simple intra-AS P-tunnels; we will rely on this distinction later (see Section 9).
注意，AS间P隧道的AS内段形成了一类不同于简单AS内P隧道的P隧道；我们将在后面依赖这一区别（见第9节）。
A segmented inter-AS P-tunnel can be thought of as a tree that is rooted at a particular AS, and that has, as its leaves, the other ASes that need to receive multicast data from the root AS.
分段的内部AS P隧道可以被认为是一棵树，它在特定的AS上生根，并且具有需要从根AS接收多播数据的其他AS作为其叶子。
2. "Non-segmented Inter-AS P-tunnels"
2. “非分段式内部AS P隧道”
A non-segmented inter-AS P-tunnel is a single P-tunnel that spans AS boundaries. The tunnel technology cannot change from one point in the tunnel to the next, so all ASes through which the P-tunnel passes must support that technology. In essence, AS boundaries are of no significance to a non-segmented inter-AS P-tunnel.
非分段式AS间P隧道是作为边界跨越的单个P隧道。隧道技术不能从隧道中的一个点改变到下一个点，因此P隧道通过的所有ASE都必须支持该技术。本质上，AS边界对于非分段式AS间P型隧道来说并不重要。
Section 10 of [RFC4364] describes three different options for supporting unicast inter-AS BGP/MPLS IP VPNs, known as options A, B, and C. We describe below how both segmented and non-segmented inter-AS trees can be supported when options B or C are used. (Option A does not pass any routing information through an ASBR at all, so no special inter-AS procedures are needed.)
[RFC4364]的第10节描述了支持单播内部AS BGP/MPLS IP VPN的三种不同选项，称为选项A、B和C。我们将在下面描述使用选项B或C时如何支持分段和非分段内部AS树。（选项A根本不通过ASBR传递任何路由信息，因此不需要特殊的AS间过程。）
In this model, the previously described discovery and tunnel setup mechanisms are used, even though the PEs belonging to a given MVPN may be in different ASes.
在该模型中，使用了前面描述的发现和隧道设置机制，即使属于给定MVPN的PE可能处于不同的ASE中。
The previously described BGP-based auto-discovery mechanisms work "as is" when an MVPN contains PEs that are in different Autonomous Systems. However, please note that, if non-segmented inter-AS P-tunnels are to be used, then the Intra-AS I-PMSI A-D routes MUST be distributed across AS boundaries!
当MVPN包含位于不同自治系统中的PE时，前面描述的基于BGP的自动发现机制“按原样”工作。但是，请注意，如果要使用非分段AS间P隧道，则AS内I-PMSI A-D路线必须分布在AS边界上！
When non-segmented inter-AS P-tunnels are used, MVPN C-multicast routing information may be exchanged by means of PIM peering across an MI-PMSI or by means of BGP carrying C-multicast routes.
当使用非分段的AS间P隧道时，MVPN C多播路由信息可以通过跨MI-PMSI的PIM对等或通过承载C多播路由的BGP进行交换。
When PIM peering is used to distribute the C-multicast routing information, a PE that sends C-PIM Join/Prune messages for a particular (C-S,C-G) must be able to identify the PE that is its PIM adjacency on the path to S. This is the "Selected Upstream PE" described in Section 5.1.3.
当PIM对等用于分发C-多播路由信息时，为特定（C-S，C-G）发送C-PIM加入/删减消息的PE必须能够识别在S路径上与其PIM相邻的PE。这是第5.1.3节中描述的“选定上游PE”。
If BGP (rather than PIM) is used to distribute the C-multicast routing information, and if option b of Section 10 of [RFC4364] is in use, then the C-multicast routes will be installed in the ASBRs along the path from each multicast source in the MVPN to each multicast receiver in the MVPN. If option b is not in use, the C-multicast routes are not installed in the ASBRs. The handling of the C-multicast routes in either case is thus exactly analogous to the handling of unicast VPN-IP routes in the corresponding case.
如果使用BGP（而不是PIM）分发C-多播路由信息，并且如果使用[RFC4364]第10节的选项b，则C-多播路由将沿着从MVPN中的每个多播源到MVPN中的每个多播接收器的路径安装在ASBR中。如果未使用选项b，则ASBR中不会安装C多播路由。因此，在这两种情况下，C多播路由的处理与相应情况下单播VPN-IP路由的处理完全类似。
The procedures described earlier in this document can be used to instantiate either an I-PMSI or an S-PMSI with inter-AS P-tunnels. Specific tunneling techniques require some explanation.
本文档前面描述的过程可用于实例化I-PMSI或S-PMSI以及内部AS P隧道。具体的隧道技术需要一些解释。
If ingress replication is used, the inter-AS PE-PE P-tunnels will use the inter-AS tunneling procedures for the tunneling technology used.
如果使用入口复制，AS间PE-PE P隧道将使用AS间隧道程序来实现所使用的隧道技术。
Procedures in [RSVP-P2MP] are used for inter-AS RSVP-TE P2MP P-tunnels.
[RSVP-P2MP]中的程序用于AS间RSVP-TE P2MP P隧道。
Procedures for using PIM to set up the P-tunnels are discussed in the next section.
下一节将讨论使用PIM设置P型隧道的程序。
When PIM is used to set up a non-segmented inter-AS P-multicast tree, the PIM Join/Prune messages used to join the tree contain the IP address of the Upstream PE. However, there are two special considerations that must be taken into account:
当PIM用于建立非分段的inter-AS P多播树时，用于加入树的PIM Join/Prune消息包含上游PE的IP地址。但是，必须考虑两个特殊因素：
- It is possible that the P routers within one or more of the ASes will not have routes to the Upstream PE. For example, if an AS has a "BGP-free core", the P routers in an AS will not have routes to addresses outside the AS.
- 一个或多个ase内的P路由器可能没有到上游PE的路由。例如，如果AS具有“BGP自由核心”，则AS中的P路由器将不具有到AS外部地址的路由。
- If the PIM Join/Prune message must travel through several ASes, it is possible that the ASBRs will not have routes to he PE routers. For example, in an inter-AS VPN constructed according to "option b" of Section 10 of [RFC4364], the ASBRs do not necessarily have routes to the PE routers.
- 如果PIM Join/Prune消息必须经过多个ASE，则ASBR可能没有到PE路由器的路由。例如，在根据[RFC4364]第10节的“选项b”构造的AS间VPN中，ASBR不一定具有到PE路由器的路由。
In either case, "ordinary" PIM Join/Prune messages cannot be routed to the Upstream PE. Therefore, in that case, the PIM Join/Prune messages MUST contain the "PIM MVPN Join attribute". This allows the multicast distribution tree to be properly constructed, even if routes to PEs in other ASes do not exist in the given AS's IGP and
在任何一种情况下，“普通”PIM加入/删减消息都不能路由到上游PE。因此，在这种情况下，PIM Join/Prune消息必须包含“PIM MVPN Join属性”。这允许正确构造多播分发树，即使在给定AS的IGP和IGP中不存在到其他ASE中PE的路由
even if the routes to those PEs do not exist in BGP. The use of a PIM MVPN Join attribute in the PIM messages allows the inter-AS trees to be built.
即使BGP中不存在到这些PE的路由。在PIM消息中使用PIM MVPN Join属性可以构建内部AS树。
The PIM MVPN Join attribute adds the following information to the PIM Join/Prune messages: a "proxy address", which contains the address of the next ASBR on the path to the Upstream PE. When the PIM Join/Prune arrives at the ASBR that is identified by the "proxy address", that ASBR must change the proxy address to identify the next hop ASBR.
PIM MVPN Join属性将以下信息添加到PIM Join/Prune消息中：“代理地址”，其中包含上游PE路径上下一个ASBR的地址。当PIM加入/删除到达由“代理地址”标识的ASBR时，该ASBR必须更改代理地址以标识下一跳ASBR。
This information allows the PIM Join/Prune to be routed through an AS, even if the P routers of that AS do not have routes to the Upstream PE. However, this information is not sufficient to enable the ASBRs to route the Join/Prune if the ASBRs themselves do not have routes to the Upstream PE.
此信息允许PIM加入/删减通过AS路由，即使该AS的P路由器没有到上游PE的路由。但是，如果ASBR本身没有到上游PE的路由，则此信息不足以使ASBR路由加入/删除。
However, even if the ASBRs do not have routes to the Upstream PE, the procedures of this document ensure that they will have Intra-AS I-PMSI A-D routes that lead to the Upstream PE. (Recall that if non-segmented inter-AS P-tunnels are being used, the ASBRs and PEs will have Intra-AS I-PMSI A-D routes that have been distributed inter-AS.)
然而，即使ASBR没有通向上游PE的路线，本文件的程序也确保它们将有通向上游PE的AS I-PMSI A-D内部路线。（回想一下，如果使用非分段的AS间P隧道，ASBR和PEs将具有已在AS间分配的AS内I-PMSI A-D路由。）
So, rather than having the PIM Join/Prune messages routed by the ASBRs along a route to the Upstream PE, the PIM Join/Prune messages MUST be routed along the path determined by the Intra-AS I-PMSI A-D routes.
因此，与ASBR沿着到上游PE的路由路由路由PIM加入/删减消息不同，PIM加入/删减消息必须沿着由内部AS I-PMSI a-D路由确定的路径路由。
The basic format of a PIM Join attribute is specified in [PIM-ATTRIB]. The details of the PIM MVPN Join attribute are specified in the next section.
PIM连接属性的基本格式在[PIM-ATTRIB]中指定。PIM MVPN Join属性的详细信息将在下一节中指定。
In [PIM-ATTRIB], the notion of a "join attribute" is defined, and a format for included join attributes in PIM Join/Prune messages is specified. We now define a new join attribute, which we call the "MVPN Join attribute".
在[PIM-ATTRIB]中，定义了“连接属性”的概念，并指定了PIM连接/删除消息中包含的连接属性的格式。现在我们定义一个新的连接属性，我们称之为“MVPN连接属性”。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length | Proxy IP address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|E| Attr_Type | Length | Proxy IP address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.......
The Attr_Type field of the MVPN Join attribute is set to 1.
MVPN连接属性的Attr_Type字段设置为1。
The F bit is set to 0.
F位设置为0。
Two information fields are carried in the MVPN Join attribute:
MVPN连接属性中包含两个信息字段：
- Proxy IP address: The IP address of the node towards which the PIM Join/Prune message is to be forwarded. This will be either an IPv4 or an IPv6 address, depending on whether the PIM Join/Prune message itself is IPv4 or IPv6.
- 代理IP地址：PIM加入/删除消息将转发到的节点的IP地址。这将是IPv4或IPv6地址，具体取决于PIM加入/删除消息本身是IPv4还是IPv6。
- RD: An eight-byte RD. This immediately follows the proxy IP address.
- RD：一个八字节的RD。它紧跟在代理IP地址之后。
The PIM message also carries the address of the Upstream PE.
PIM消息还携带上游PE的地址。
In the case of an intra-AS MVPN, the proxy and the Upstream PE are the same. In the case of an inter-AS MVPN, the proxy will be the ASBR that is the exit point from the local AS on the path to the Upstream PE.
在内部AS MVPN的情况下，代理和上游PE是相同的。在内部AS MVPN的情况下，代理将是ASBR，该ASBR是指向上游PE的路径上本地AS的出口点。
When a PE router originates a PIM Join/Prune message in order to set up an inter-AS PMSI, it does so as a result of having received a particular Intra-AS I-PMSI A-D route or S-PMSI A-D route. It includes an MVPN Join attribute whose fields are set as follows:
当PE路由器发起PIM加入/删减消息以建立内部AS PMSI时，它这样做是因为已经接收到特定的内部AS I-PMSI a-D路由或S-PMSI a-D路由。它包括一个MVPN连接属性，其字段设置如下：
- If the Upstream PE is in the same AS as the local PE, then the proxy field contains the address of the Upstream PE. Otherwise, it contains the address of the BGP Next Hop of the route to the Upstream PE.
- 如果上游PE与本地PE相同，则代理字段包含上游PE的地址。否则，它包含到上游PE的路由的BGP下一跳的地址。
- The RD field contains the RD from the NLRI of the Intra-AS A-D route.
- RD字段包含来自内部AS A-D路由NLRI的RD。
- The Upstream PE field contains the address of the PE that originated the Intra-AS I-PMSI A-D route or S-PMSI A-D route (obtained from the NLRI of that route).
- 上游PE字段包含发起内部AS I-PMSI A-D路由或S-PMSI A-D路由（从该路由的NLRI获得）的PE的地址。
When a PIM router processes a PIM Join/Prune message with an MVPN Join attribute, it first checks to see if the proxy field contains one of its own addresses.
当PIM路由器处理具有MVPN Join属性的PIM Join/Prune消息时，它首先检查代理字段是否包含自己的地址之一。
If not, the router uses the proxy IP address in order to determine the RPF interface and neighbor. The MVPN Join attribute must be passed upstream unchanged.
如果不是，路由器使用代理IP地址来确定RPF接口和邻居。MVPN连接属性必须在未更改的情况下向上游传递。
If the proxy address is one of the router's own IP addresses, then the router looks in its BGP routing table for an Intra-AS A-D route whose NLRI consists of the Upstream PE address prepended with the RD from the Join attribute. If there is no match, the PIM message is discarded. If there is a match, the IP address from the BGP next hop field of the matching route is used in order to determine the RPF interface and neighbor. When the PIM Join/Prune is forwarded upstream, the proxy field is replaced with the address of the BGP next hop, and the RD and Upstream PE fields are left unchanged.
如果代理地址是路由器自己的IP地址之一，则路由器在其BGP路由表中查找内部AS A-D路由，该路由的NLRI由上游PE地址组成，该地址前面带有Join属性中的RD。如果不匹配，PIM消息将被丢弃。如果存在匹配，则使用匹配路由的BGP下一跳字段中的IP地址来确定RPF接口和邻居。当PIM加入/删减向上游转发时，代理字段将替换为BGP下一跳的地址，RD和上游PE字段保持不变。
The use of non-segmented inter-AS trees constructed via BIDIR-PIM is outside the scope of this document.
通过BIDIR-PIM构建的非分段内部AS树的使用不在本文件范围内。
The procedures for setting up and maintaining segmented inter-AS Inclusive and Selective P-tunnels may be found in [MVPN-BGP].
[MVPN-BGP]中提供了建立和维护分段AS间包容性和选择性P隧道的程序。
Consider the case of an egress PE that receives packets of a particular C-flow, (C-S,C-G), over a non-aggregated S-PMSI. The procedures described so far will never cause the PE to receive duplicate copies of any packet in that stream. It is possible that the (C-S,C-G) stream is carried in more than one S-PMSI; this may happen when the site that contains C-S is multihomed to more than one PE. However, a PE that needs to receive (C-S,C-G) packets only joins one of these S-PMSIs, and so it only receives one copy of each packet. However, if the data packets of stream (C-S,C-G) are carried in either an I-PMSI or an aggregated S-PMSI, then the procedures specified so far make it possible for an egress PE to receive more than one copy of each data packet. Additional procedures are needed to either make this impossible or ensure that the egress PE does not forward duplicates to the CE routers.
考虑出口PE的情况，它接收一个特定的C流的包，（C-S，C-G），在非聚集的S- PMSI上。到目前为止描述的过程将永远不会导致PE接收该流中任何数据包的重复副本。（C-S，C-G）流可能在多个S-PMSI中承载；当包含C-S的站点多址到多个PE时，可能会发生这种情况。然而，需要接收（C-S，C-G）数据包的PE只加入这些S-PMSI中的一个，因此它只接收每个数据包的一个副本。然而，如果流（C-S，C-G）的数据分组在I-PMSI或聚合S-PMSI中携带，则迄今为止指定的过程使得出口PE能够接收每个数据分组的多个副本。需要额外的程序来实现这一点，或者确保出口PE不会将副本转发给CE路由器。
This section covers only the situation where the C-trees are unidirectional, in either the ASM or SSM service models. The case where the C-trees are bidirectional is considered separately in Section 11.
本节仅介绍ASM或SSM服务模型中C树是单向的情况。第11节单独考虑了C-树是双向的情况。
There are two cases where the procedures specified so far make it possible for an egress PE to receive duplicate copies of a multicast data packet. These are as follows:
有两种情况，其中迄今为止指定的过程使得出口PE能够接收多播数据分组的重复副本。详情如下:
1. The first case occurs when both of the following conditions hold:
1. 第一种情况发生在以下两种情况下：
a. an MVPN site that contains C-S or C-RP is multihomed to more than one PE, and
a. 包含C-S或C-RP的MVPN站点多址到多个PE，并且
b. either an I-PMSI or an aggregated S-PMSI is used for carrying the packets originated by C-S.
b. I-PMSI或聚合S-PMSI用于承载由C-S发起的分组。
In this case, an egress PE may receive one copy of the packet from each PE to which the site is homed. This case is discussed further in Section 9.2.
在这种情况下，出口PE可以从站点所在的每个PE接收分组的一个副本。本案例将在第9.2节中进一步讨论。
2. The second case occurs when all of the following conditions hold:
2. 第二种情况发生在以下所有条件均成立时：
a. the IP destination address of the customer packet, C-G, identifies a multicast group that is operating in ASM mode and whose C-multicast tree is set up using PIM-SM,
a. 客户数据包的IP目的地地址C-G标识在ASM模式下运行的多播组，其C-多播树是使用PIM-SM建立的，
b. an MI-PMSI is used for carrying the data packets, and
b. MI-PMSI用于承载数据分组，并且
c. a router or a CE in a site connected to the egress PE switches from the C-RP tree to the C-S tree.
c. 连接到从C-RP树到C-S树的出口PE交换机的站点中的路由器或CE。
In this case, it is possible to get one copy of a given packet from the ingress PE attached to the C-RP's site and one from the ingress PE attached to the C-S's site. This case is discussed further in Section 9.3.
在这种情况下，可以从连接到C-RP站点的入口PE和连接到C-s站点的入口PE获取给定数据包的一个副本。本案例将在第9.3节中进一步讨论。
Additional procedures are therefore needed to ensure that no MVPN customer sees steady state multicast data packet duplication. There are three procedures that may be used:
因此，需要额外的过程来确保MVPN客户不会看到稳态多播数据包复制。可使用三种程序：
1. Discarding data packets received from the "wrong" PE
1. 丢弃从“错误”PE接收的数据包
2. Single Forwarder Selection
2. 单一货代选择
3. Native PIM methods
3. 本机PIM方法
These methods are described in Section 9.1. Their applicability to the two scenarios where duplication is possible is discussed in Sections 9.2 and 9.3.
第9.1节描述了这些方法。第9.2节和第9.3节讨论了它们对可能重复的两种情况的适用性。
Every MVPN MUST use at least one of the three methods for ensuring non-duplication.
每个MVPN必须至少使用三种方法中的一种来确保不重复。
Per Section 5.1.3, an egress PE, say PE1, chooses a specific Upstream PE, for given (C-S,C-G). When PE1 receives a (C-S,C-G) packet from a PMSI, it may be able to identify the PE that transmitted the packet onto the PMSI. If that transmitter is other than the PE selected by PE1 as the Upstream PE, then PE1 can drop the packet. This means that the PE will see a duplicate, but the duplicate will not get forwarded.
根据第5.1.3节，出口PE（如PE1）为给定（C-S，C-G）选择特定的上游PE。当PE1从PMSI接收（C-S，C-G）分组时，它可能能够识别将分组发送到PMSI的PE。如果该发射机不是PE1选择的作为上游PE的PE，那么PE1可以丢弃该分组。这意味着PE将看到副本，但不会转发副本。
The method used by an egress PE to determine the ingress PE for a particular packet, received over a particular PMSI, depends on the P-tunnel technology that is used to instantiate the PMSI. If the P-tunnel is a P2MP LSP, a PIM-SM or PIM-SSM tree, or a unicast P-tunnel that uses IP encapsulation, then the tunnel encapsulation contains information that can be used (possibly along with other state information in the PE) to determine the ingress PE, as long as the P-tunnel is instantiating an intra-AS PMSI or an inter-AS PMSI which is supported by a non-segmented inter-AS tunnel.
出口PE用于确定通过特定PMSI接收的特定分组的入口PE的方法取决于用于实例化PMSI的P隧道技术。如果P隧道是P2MP LSP、PIM-SM或PIM-SSM树或使用IP封装的单播P隧道，则隧道封装包含可用于确定入口PE的信息（可能与PE中的其他状态信息一起使用），只要P隧道实例化由非分段的内部as隧道支持的内部as PMSI或内部as PMSI。
Even when inter-AS segmented P-tunnels are used, if an aggregated S-PMSI is used for carrying the packets, the tunnel encapsulation must have some information that can be used to identify the PMSI; in turn, that implicitly identifies the ingress PE.
即使在使用AS间分段P-隧道时，如果使用聚合S-PMSI来承载分组，则隧道封装必须具有一些可用于识别PMSI的信息；反过来，它隐式地标识入口PE。
Consider the case of an I-PMSI that spans multiple ASes and that is instantiated by segmented inter-AS P-tunnels. Suppose it is carrying data that is traveling along a particular C-tree. Suppose also that the C-root of that C-tree is multihomed to two or more PEs, and that each such PE is in a different AS than the others. Then, if there is any duplicate traffic, the duplicates will arrive on a different P-tunnel. Specifically, if the PE was expecting the traffic on a particular inter-AS P-tunnel, duplicate traffic will arrive either on an intra-AS P-tunnel (not an intra-AS segment of an inter-AS P-tunnel) or on some other inter-AS P-tunnel. To detect duplicates, the PE has to keep track of which inter-AS A-D route the PE uses for sending MVPN multicast routing information towards the C-S/C-RP. The PE MUST process received (multicast) traffic originated by C-S/C-RP only from the inter-AS P-tunnel that was carried in the best Inter-AS A-D route for the MVPN and that was originated by the AS that contains C-S/C-RP (where "the best" is determined by the PE). The PE MUST discard, as duplicates, all other multicast traffic originated by the C-S/C-RP, but received on any other P-tunnel.
考虑的情况下，i-PMSI跨越多个ASes，并实例化的分段间作为P隧道。假设它携带的数据是沿着特定的C-树传播的。还假设该C-树的C-根是多宿到两个或多个PE的，并且每个这样的PE与其他PE位于不同的AS中。然后，如果有任何重复流量，重复流量将到达不同的P隧道。具体地说，如果PE期望在特定的AS间P隧道上的业务，则重复的业务将到达AS内P隧道（不是AS间P隧道的AS内段）或某个其他AS间P隧道。为了检测重复，PE必须跟踪PE用于向C-S/C-RP发送MVPN多播路由信息的inter-AS A-D路由。PE必须处理接收到的（多播）由C-S/C-RP发起的通信量仅来自MVPN最佳AS-A-D路线中承载的AS间P隧道，且由包含C-S/C-RP的AS发起（其中“最佳”由PE确定）。PE必须作为副本丢弃由C-S/C-RP发起但在任何其他P-tunnel上接收的所有其他多播流量。
If, for a given MVPN, (a) an MI-PMSI is used for carrying multicast data packets, (b) the MI-PMSI is instantiated by a segmented inter-AS P-tunnel, (c) the C-S or C-RP is multihomed to different PEs, and (d) at least two such PEs are in the same AS, then, depending on the
如果，对于给定的MVPN，（a）MI-PMSI用于承载多播数据分组，（b）MI-PMSI由分段的inter-AS P-tunnel实例化，（c）c-S或c-RP被多宿到不同的pe，并且（d）至少两个这样的pe处于相同的位置，则取决于所述情况
tunneling technology used to instantiate the MI-PMSI, it may not always be possible for the egress PE to determine the Upstream PE. In that case, the procedure of Sections 9.1.2 or 9.1.3 must be used.
隧道技术用于实例化MI-PMSI，出口PE可能并不总是能够确定上游PE。在这种情况下，必须使用第9.1.2节或第9.1.3节中的程序。
NB: Section 10 describes an exception case where PE1 has to accept a packet even if it is not from the Selected Upstream PE.
注意：第10节描述了一种例外情况，其中PE1必须接受一个数据包，即使它不是来自所选的上游PE。
Section 5.1 specifies a procedure for choosing a "default Upstream PE selection", such that (except during routing transients) all PEs will choose the same default Upstream PE. To ensure that duplicate packets are not sent through the backbone (except during routing transients), an ingress PE does not forward to the backbone any (C-S,C-G) multicast data packet it receives from a CE, unless the PE is the default Upstream PE selection.
第5.1节规定了选择“默认上游PE选择”的程序，以便所有PE（路由瞬态期间除外）选择相同的默认上游PE。为确保不通过主干发送重复数据包（路由瞬态期间除外），入口PE不会将其从CE接收到的任何（C-S，C-G）多播数据包转发到主干，除非PE是默认的上游PE选择。
One difference in effect between this procedure and the procedure of Section 9.1.1 is that this procedure sends only one copy of each packet to each egress PE, rather than sending multiple copies and forcing the egress PE to discard all but one.
该程序与第9.1.1节程序之间的一个有效区别是，该程序仅向每个出口PE发送每个数据包的一个副本，而不是发送多个副本并强制出口PE丢弃除一个以外的所有副本。
If PE-PE multicast routing information for a given MVPN is being disseminated by running PIM over an MI-PMSI, then native PIM methods will prevent steady state data packet duplication. The PIM Assert mechanism prevents steady state duplication in the scenario of Section 9.2, even if Single Forwarder Selection is not done. The PIM Prune(S,G,rpt) mechanism addresses the scenario of Section 9.3.
如果通过在MI-PMSI上运行PIM来传播给定MVPN的PE-PE多播路由信息，则本机PIM方法将防止稳态数据包复制。PIM断言机制可防止第9.2节场景中的稳态复制，即使未选择单个转发器。PIM修剪（S、G、rpt）机制解决了第9.3节的场景。
Any of the three methods of Section 9.1 will prevent steady state duplicates in the case of a multihomed C-S or C-RP.
第9.1节中的三种方法中的任何一种都可以防止多宿主C-S或C-RP的稳态重复。
If some PEs are on the C-S tree and some are on the C-RP tree, then a PE may also receive duplicate data traffic after a (C-*,C-G) to (C-S,C-G) switch.
如果某些PE位于C-S树上，而某些PE位于C-RP树上，则PE也可能在（C-*，C-G）到（C-S，C-G）切换后接收重复数据通信量。
If PIM is being used on an MI-PMSI to disseminate multicast routing information, native PIM methods (in particular, the use of the Prune(S,G,rpt) message) prevent steady state data duplication in this case.
如果在MI-PMSI上使用PIM来传播多播路由信息，则本机PIM方法（特别是使用Prune（S、G、rpt）消息）在这种情况下可防止稳态数据重复。
If BGP C-multicast routing is being used, then the procedure of Section 9.1.1, if applicable, can be used to prevent duplication. However, if that procedure is not applicable, then the procedure of Section 9.1.2 is not sufficient to prevent steady state data duplication in all scenarios.
如果使用BGP C-多播路由，则可使用第9.1.1节中的程序（如适用）防止重复。但是，如果该程序不适用，则第9.1.2节的程序不足以在所有情况下防止稳态数据重复。
In the scenario in which (a) BGP C-multicast routing is being used, (b) there are inter-site shared C-trees, and (c) there are inter-site source C-trees, additional procedures are needed. To see this, consider the following topology:
在（a）使用BGP C-多播路由，（b）存在站点间共享C-树，以及（C）存在站点间源C-树的场景中，需要额外的过程。要了解这一点，请考虑以下拓扑：
CE1---C-RP
|
|
CE2---PE1-- ... --PE2---CE5---C-S
...
C-R1---CE3---PE3-- ... --PE4---CE4---C-R2
CE1---C-RP
|
|
CE2---PE1-- ... --PE2---CE5---C-S
...
C-R1---CE3---PE3-- ... --PE4---CE4---C-R2
Suppose that C-R1 and C-R2 use PIM to join the (C-*,C-G) tree, where C-RP is the RP corresponding to C-G. As a result, CE3 and CE4 will send PIM Join(*,G) messages to PE3 and PE4, respectively. This will cause PE3 and PE4 to originate C-multicast Shared Tree Join Routes, specifying (C-*,C-G). These routes will identify PE1 as the Upstream PE.
假设C-R1和C-R2使用PIM连接（C-*，C-G）树，其中C-RP是对应于C-G的RP。因此，CE3和CE4将分别向PE3和PE4发送PIM连接（*，G）消息。这将导致PE3和PE4发起C多播共享树连接路由，指定（C-*，C-G）。这些路线将PE1识别为上游PE。
Now suppose that C-S is a transmitter for multicast group C-G, and that C-S sends its multicast data packets to C-RP in PIM Register messages. Then, PE1 will receive (C-S,C-G) data packets from CE1, and will forward them over an I-PMSI to PE3 and PE4, who will forward them, in turn, to CE3 and CE4, respectively.
现在假设C-S是多播组C-G的发送器，并且C-S在PIM寄存器消息中将其多播数据包发送给C-RP。然后，PE1将从CE1接收（C-S，C-G）数据包，并将它们通过I-PMSI转发给PE3和PE4，PE3和PE4将依次转发给CE3和CE4。
When C-R1 receives (C-S,C-G) data packets, it may decide to join the (C-S,C-G) source tree, by sending a PIM Join(S,G) to CE3. This will, in turn, cause CE3 to send a PIM Join(S,G) to PE3, which will, in turn, cause PE3 to originate a C-multicast Source Tree Join Route, specifying (C-S,C-G) and identifying PE2 as the Upstream PE. As a result, when PE2 receives (C-S,C-G) data packets from CE5, it will forward them on a PMSI to PE3.
当C-R1接收到（C-S，C-G）数据包时，它可以通过向CE3发送PIM连接（S，G）来决定加入（C-S，C-G）源树。这将反过来导致CE3向PE3发送PIM连接（S，G），这将反过来导致PE3发起C多播源树连接路由，指定（C-S，C-G）并将PE2标识为上游PE。因此，当PE2从CE5接收（C-S，C-G）数据包时，它将通过PMSI将它们转发给PE3。
At this point, the following situation exists:
此时，存在以下情况：
- If PE1 receives (C-S,C-G) packets from CE1, PE1 must forward them on the I-PMSI, because PE4 is still expecting to receive the (C-S,C-G) packets from PE1.
- 如果PE1从CE1接收（C-S，C-G）数据包，PE1必须在I-PMSI上转发它们，因为PE4仍然期望从PE1接收（C-S，C-G）数据包。
- PE3 must continue to receive packets from the I-PMSI, since there may be other sources transmitting C-G traffic and PE3 currently has no other way to receive that traffic.
- PE3必须继续从I-PMSI接收数据包，因为可能有其他源发送C-G流量，并且PE3目前没有其他方式接收该流量。
- PE3 must also receive (C-S,C-G) traffic from PE2.
- PE3还必须接收来自PE2的（C-S、C-G）流量。
As a result, PE3 may receive two copies of each (C-S,C-G) packet. The procedure of Section 9.1.2 (Single Forwarder Selection) does not prevent PE3 from receiving two copies, because it does not prevent one PE from forwarding (C-S,C-G) traffic along the shared C-tree while another forwards (C-S,C-G) traffic along a source-specific C-tree.
结果，PE3可以接收每个（C-S，C-G）分组的两个副本。第9.1.2节（单个转发器选择）的程序不会阻止PE3接收两份副本，因为它不会阻止一个PE沿着共享C-树转发（C-S，C-G）流量，而另一个PE沿着源特定C-树转发（C-S，C-G）流量。
So if PE3 cannot apply the method of Section 9.1.1 (Discarding Packets from Wrong PE), perhaps because the tunneling technology does not allow the egress PE to identify the ingress PE, then additional procedures are needed.
因此，如果PE3不能应用第9.1.1节的方法（从错误的PE丢弃数据包），可能是因为隧道技术不允许出口PE识别入口PE，那么需要额外的程序。
The issue described in Section 9.3.1 is resolved through the use of Source Active A-D routes. In the remainder this section, we provide an example of how this works, along with an informal description of the procedures.
第9.3.1节中描述的问题通过使用有源A-D路由解决。在本节的其余部分中，我们提供了一个如何工作的示例，以及对程序的非正式描述。
A full and precise specification of the relevant procedures can be found in Section 13 of [MVPN-BGP]. In the event of any conflicts or other discrepancies between the description below and the description in [MVPN-BGP], [MVPN-BGP] is to be considered to be the authoritative document.
[MVPN-BGP]第13节中提供了相关程序的完整和精确规范。如果以下描述与[MVPN-BGP]中的描述之间存在任何冲突或其他差异，[MVPN-BGP]将被视为权威文件。
Please note that the material in this section only applies when inter-site shared trees are being used.
请注意，本节中的材料仅适用于使用站点间共享树的情况。
Whenever a PE creates an (C-S,C-G) state as a result of receiving a C-multicast route for (C-S,C-G) from some other PE, and the C-G group is an ASM group, the PE that creates the state MUST originate a Source Active A-D route (see [MVPN-BGP], Section 4.5). The NLRI of the route includes C-S and C-G. By default, the route carries the same set of Route Targets as the Intra-AS I-PMSI A-D route of the MVPN originated by the PE. Using the normal BGP procedures, the
当PE从其他PE接收（C-S，C-G）的C-多播路由后创建（C-S，C-G）状态，且C-G组为ASM组时，创建该状态的PE必须发起源活动a-D路由（见[MVPN-BGP]，第4.5节）。路由的NLRI包括C-S和C-G。默认情况下，该路由承载与PE发起的MVPN的Intra-as I-PMSI A-D路由相同的路由目标集。使用正常的BGP程序
route is propagated to all the PEs of the MVPN. For more details, see Section 13.1 ("Source within a Site - Source Active Advertisement") of [MVPN-BGP].
路由被传播到MVPN的所有PE。有关更多详细信息，请参见[MVPN-BGP]第13.1节（“站点内的源-源活动广告”）。
When, as a result of receiving a new Source Active A-D route, a PE updates its VRF with the route, the PE MUST check if the newly received route matches any (C-*,C-G) entries. If (a) there is a matching entry, (b) the PE does not have (C-S,C-G) state in its MVPN Tree Information Base (MVPN-TIB) for (C-S,C-G) carried in the route, and (c) the received route is selected as the best (using the BGP route selection procedures), then the PE takes the following action:
当收到新的源活动a-D路由后，PE用该路由更新其VRF时，PE必须检查新收到的路由是否匹配任何（C-*，C-G）条目。如果（a）存在匹配条目，（b）PE在其MVPN树信息库（MVPN-TIB）中没有路由中携带的（C-S，C-G）的（C-S，C-G）状态，并且（C）接收到的路由被选择为最佳（使用BGP路由选择程序），则PE采取以下操作：
- If the PE's (C-*,C-G) state has a PMSI as a downstream interface, the PE acts as if all the other PEs had pruned C-S off the (C-*,C-G) tree. That is:
- 如果PE的（C-*，C-G）状态有一个PMSI作为下游接口，则PE的行为就好像所有其他PE已将C-s从（C-*，C-G）树中剪除一样。即:
* If the PE receives (C-S,C-G) traffic from a CE, it does not transmit it to other PEs.
* 如果PE从CE接收（C-S、C-G）通信量，则不会将其发送给其他PE。
* Depending on the PIM state of the PE's PE-CE interfaces, the PE may or may not need to invoke PIM procedures to prune C-S off the (C-*,C-G) tree by sending a PIM Prune(S,G,rpt) to one or more of the CEs. This is determined by ordinary PIM procedures. If this does need to be done, the PE SHOULD delay sending the Prune until it first runs a timer; this helps ensure that the source is not pruned from the shared tree until all PEs have had time to receive the Source Active A-D route.
* 根据PE的PE-CE接口的PIM状态，PE可能需要也可能不需要调用PIM过程，通过向一个或多个CE发送PIM删减（s，G，rpt）来删减（C-*，C-G）树中的C-s。这是由普通PIM程序确定的。如果确实需要这样做，PE应该延迟发送剪枝，直到它第一次运行计时器；这有助于确保在所有PE有时间接收源活动A-D路由之前，不会从共享树中删除源。
- If the PE's (C-*,C-G) state does not have a PMSI as a downstream interface, the PE sets up its forwarding path to receive (C-S,C-G) traffic from the originator of the selected Source Active A-D route.
- 如果PE的（C-*，C-G）状态没有PMSI作为下游接口，则PE将设置其转发路径以从所选源活动a-D路由的发起方接收（C-s，C-G）流量。
Whenever a PE deletes the (C-S,C-G) state that was previously created as a result of receiving a C-multicast route for (C-S,C-G) from some other PE, the PE that deletes the state also withdraws the Source Active A-D route (if there is one) that was advertised when the state was created.
每当某个PE删除之前由于从其他某个PE接收（C-S，C-G）的C多播路由而创建的（C-S，C-G）状态时，删除该状态的PE也会撤回在创建该状态时播发的源活动a-D路由（如果有）。
In the example topology of Section 9.3.1, this procedure will cause PE2 to generate a Source Active A-D route for (C-S,C-G). When this route is received, PE4 will set up its forwarding state to expect (C-S,C-G) packets from PE2. PE1 will change its forwarding state so that (C-S,C-G) packets that it receives from CE1 are not forwarded to any other PEs. (Note that PE1 may still forward (C-S,C-G) packets received from CE1 to CE2, if CE2 has receivers for C-G and those
在第9.3.1节的示例拓扑中，此程序将导致PE2为（C-S，C-G）生成源激活a-D路由。当收到此路由时，PE4将设置其转发状态，以期望来自PE2的（C-S、C-G）数据包。PE1将更改其转发状态，以便从CE1接收的（C-S、C-G）数据包不会转发到任何其他PEs。（注意，如果CE2具有用于C-G的接收器，则PE1仍然可以将从CE1接收的（C-S，C-G）分组转发到CE2
receivers did not switch from the (C-*,C-G) tree to the (C-S,C-G) tree.) As a result, PE3 and PE4 do not receive duplicate packets of the (C-S,C-G) C-flow.
接收器没有从（C-*，C-G）树切换到（C-S，C-G）树。）因此，PE3和PE4没有接收（C-S，C-G）C流的重复数据包。
With this procedure in place, there is no need to have any kind of C-multicast route that has the semantics of a PIM Prune(S,G,rpt) message.
有了这个过程，就不需要任何一种具有PIM Prune（S、G、rpt）消息语义的C多播路由。
It is worth noting that if, as a result of this procedure, a PE sets up its forwarding state to receive (C-S,C-G) traffic from the source tree, the UMH is not necessarily the same as it would be if the PE had joined the source tree as a result of receiving a PIM Join for the same source tree from a directly attached CE.
值得注意的是，如果作为该过程的结果，PE设置其转发状态以从源树接收（C-S，C-G）流量，则UMH不一定与如果PE由于从直接连接的CE接收到相同源树的PIM连接而加入源树时的情况相同。
Note that the mechanism described in Section 7.4.1 can be leveraged to advertise an S-PMSI binding along with the source active messages. This is accomplished by using the same BGP Update message to carry both the NLRI of the S-PMSI A-D route and the NLRI of the Source Active A-D route. (Though an implementation processing the received routes cannot assume that this will always be the case.)
请注意，第7.4.1节中描述的机制可用于公布S-PMSI绑定以及源活动消息。这是通过使用相同的BGP更新消息来携带S-PMSI A-D路由的NLRI和源活动A-D路由的NLRI来实现的。（尽管处理接收到的路由的实现不能假定总是如此。）
In the ASM service model, a node that wants to become a receiver for a particular multicast group G first joins a shared tree, rooted at a rendezvous point. When the receiver detects traffic from a particular source, it has the option of joining a source tree, rooted at that source. If it does so, it has to prune that source from the shared tree, to ensure that it receives packets from that source on only one tree.
在ASM服务模型中，想要成为特定多播组G的接收者的节点首先加入一个以集合点为根的共享树。当接收器检测到来自特定源的流量时，它可以选择加入源树，根在该源。如果这样做，它必须从共享树中删除该源，以确保它只在一棵树上接收来自该源的数据包。
Maintaining the shared tree can require considerable state, as it is necessary not only to know who the upstream and downstream nodes are, but to know which sources have been pruned off which branches of the share tree.
维护共享树可能需要相当多的状态，因为不仅需要知道谁是上游和下游节点，还需要知道哪些源已从共享树的哪些分支上剪掉。
The BGP-based signaling procedures defined in this document and in [MVPN-BGP] eliminate the need for PEs to distribute to each other any state having to do with which sources have been pruned off a shared C-tree. Those procedures do still allow multicast data traffic to travel on a shared C-tree, but they do not allow a situation in which some CEs receive (S,G) traffic on a shared tree and some on a source tree. This results in a considerable simplification of the PE-PE procedures with minimal change to the multicast service seen within the VPN. However, shared C-trees are still supported across the VPN backbone. That is, (C-*,C-G) state is distributed PE-PE, but (C-*,C-G,rpt) state is not.
本文件和[MVPN-BGP]中定义的基于BGP的信令程序消除了PEs相互分发任何状态的需要，这些状态与已从共享C-树中删除的源有关。这些过程仍然允许多播数据流量在共享C树上传输，但不允许某些CE在共享树上接收（S，G）流量，而某些CE在源树上接收（S，G）流量。这使得PE-PE过程大大简化，VPN中的多播服务变化最小。但是，在VPN主干上仍然支持共享C树。也就是说，（C-*，C-G）状态是分布式PE-PE，但（C-*，C-G，rpt）状态不是。
In this section, we specify a number of optional procedures that go further and that completely eliminate the support for shared C-trees across the VPN backbone. In these procedures, the PEs keep track of the active sources for each C-G. As soon as a CE tries to join the (*,G) tree, the PEs instead join the (S,G) trees for all the active sources. Thus, all distribution of (C-*,C-G) state is eliminated. These procedures are optional because they require some additional support on the part of the VPN customer and because they are not always appropriate. (For example, a VPN customer may have his own policy of always using shared trees for certain multicast groups.) There are several different options, described in the following sub-sections.
在本节中，我们将详细说明一些可选过程，这些过程将更进一步，完全消除对VPN主干上共享C树的支持。在这些过程中，PEs跟踪每个C-G的活动源。一旦CE尝试加入（*，G）树，PEs就会加入所有活动源的（S，G）树。因此，消除了（C-*，C-G）态的所有分布。这些过程是可选的，因为它们需要VPN客户提供一些额外的支持，而且并不总是合适的。（例如，VPN客户可能有自己的策略，总是为某些多播组使用共享树。）有几个不同的选项，在以下小节中描述。
[MVPN-REQ] describes C-RP engineering as an issue when PIM-SM (or BIDIR-PIM) is used in Any-Source Multicast (ASM) mode [RFC4607] on the VPN customer site. To quote from [MVPN-REQ]:
[MVPN-REQ]将C-RP工程描述为当在VPN客户站点的任何源多播（ASM）模式[RFC4607]中使用PIM-SM（或BIDIR-PIM）时的一个问题。引用[MVPN-REQ]：
In the case of PIM-SM, when a source starts to emit traffic toward a group (in ASM mode), if sources and receivers are located in VPN sites that are different than that of the RP, then traffic may transiently flow twice through the SP network and the CE-PE link of the RP (from source to RP, and then from RP to receivers). This traffic peak, even short, may not be convenient depending on the traffic and link bandwidth.
在PIM-SM的情况下，当源开始向组发送流量时（在ASM模式下），如果源和接收器位于不同于RP的VPN站点中，则流量可能会暂时流经SP网络和RP的CE-PE链路两次（从源到RP，然后从RP到接收器）。此流量峰值即使很短，也可能不方便，具体取决于流量和链路带宽。
Thus, a VPN solution MAY provide features that solve or help mitigate this potential issue.
因此，VPN解决方案可以提供解决或帮助缓解此潜在问题的功能。
One of the C-RP deployment models is for the customer to outsource the RP to the provider. In this case, the provider may co-locate the RP on the PE that is connected to the customer site [MVPN-REQ]. This section describes how "anycast-RP" can be used to achieve this. This is described below.
C-RP部署模型之一是客户将RP外包给提供商。在这种情况下，提供商可以在连接到客户站点[MVPN-REQ]的PE上共同定位RP。本节介绍如何使用“anycast RP”来实现这一点。下文对此进行了描述。
For a particular MVPN, at least one or more PEs that have sites in that MVPN, act as an RP for the sites of that MVPN connected to these PEs. Within each MVPN, all of these RPs use the same (anycast) address. All of these RPs use the Anycast RP technique.
对于特定MVPN，至少一个或多个在该MVPN中具有站点的PE充当连接到这些PE的该MVPN站点的RP。在每个MVPN中，所有这些RP都使用相同的（选播）地址。所有这些RP都使用Anycast RP技术。
This mechanism is based on propagating active sources between RPs.
该机制基于在RPs之间传播活动源。
The PE that receives a C-Join message for (*,G) does not send the information that it has receiver(s) for G until it receives information about active sources for G from an Upstream PE.
接收（*，G）的C-Join消息的PE在从上游PE接收到关于G的活动源的信息之前，不会发送其具有G的接收器的信息。
On receiving this (described in the next section), the downstream PE will respond with a Join message for (C-S,C-G). Sending this information could be done using any of the procedures described in Section 5. Only the Upstream PE will process this information.
收到此消息（将在下一节中描述）后，下游PE将响应（C-S，C-G）的连接消息。可以使用第5节中描述的任何程序发送此信息。只有上游PE将处理此信息。
When a PE receives a PIM Register message from a site that belongs to a given VPN, PE follows the normal PIM anycast RP procedures. It then advertises the source and group of the multicast data packet carried in the PIM Register message to other PEs in BGP using the following information elements:
当PE从属于给定VPN的站点接收到PIM注册消息时，PE遵循正常的PIM anycast RP过程。然后，它使用以下信息元素将PIM注册消息中携带的多播数据包的源和组播发给BGP中的其他PE：
- Active source address
- 活动源地址
- Active group address
- 活动组地址
- Route target of the MVPN.
- MVPN的路由目标。
This advertisement goes to all the PEs that belong to that MVPN. When a PE receives this advertisement, it checks whether there are any receivers in the sites attached to the PE for the group carried in the source active advertisement. If there are, then it generates an advertisement for (C-S,C-G) as specified in the previous section.
此广告将发送给属于该MVPN的所有PE。当PE收到此广告时，它会检查是否在附加到PE的站点中存在源活动广告中包含的组的任何接收者。如果存在，则它会为（C-S，C-G）生成上一节中指定的播发。
No additional procedures are required when multicast receivers in customer's site shift from shared tree to source tree.
当客户站点中的多播接收器从共享树转移到源树时，不需要额外的程序。
Section 10.1 describes the case where each PE is a C-RP. This enables the PEs to know the active multicast sources for each MVPN, and they can then use BGP to distribute this information to each other. As a result, the PEs do not have to join any shared C-trees, and this results in a simplification of the PE operation.
第10.1节描述了每个PE是C-RP的情况。这使PE能够知道每个MVPN的活动多播源，然后他们可以使用BGP将此信息分发给彼此。因此，PE不必加入任何共享的C树，从而简化了PE操作。
In another deployment scenario, the PEs are not themselves C-RPs, but use Multicast Source Discovery Protocol (MSDP) [RFC3618] to talk to the C-RPs. In particular, a PE that attaches to a site that contains a C-RP becomes an MSDP peer of that C-RP. That PE then uses BGP to
在另一个部署场景中，PE本身不是C-RPs，而是使用多播源发现协议（MSDP）[RFC3618]与C-RPs通信。特别是，连接到包含C-RP的站点的PE将成为该C-RP的MSDP对等方。该PE然后使用BGP
distribute the information about the active sources to the other PEs. When the PE determines, by MSDP, that a particular source is no longer active, then it withdraws the corresponding BGP Update. Then, the PEs do not have to join any shared C-trees, and they do not have to be C-RPs either.
将有关活动源的信息分发给其他PE。当PE通过MSDP确定某个特定源不再处于活动状态时，它将撤回相应的BGP更新。然后，PE不必加入任何共享的C树，也不必是C-RP。
MSDP provides the capability for a Source Active (SA) message to carry an encapsulated data packet. This capability can be used to allow an MSDP speaker to receive the first (or first several) packet(s) of an (S,G) flow, even though the MSDP speaker hasn't yet joined the (S,G) tree. (Presumably, it will join that tree as a result of receiving the SA message that carries the encapsulated data packet.) If this capability is not used, the first several data packets of an (S,G) stream may be lost.
MSDP提供源活动（SA）消息承载封装数据包的能力。此功能可用于允许MSDP扬声器接收（s，G）流的第一个（或前几个）数据包，即使MSDP扬声器尚未加入（s，G）树。（假定，它将在接收到携带封装数据包的SA消息后加入该树。）如果不使用该功能，则（S，G）流的前几个数据包可能会丢失。
A PE that is talking MSDP to an RP may receive such an encapsulated data packet from the RP. The data packet should be decapsulated and transmitted to the other PEs in the MVPN. If the packet belongs to a particular (S,G) flow, and if the PE is a transmitter for some S-PMSI to which (S,G) has already been bound, the decapsulated data packet should be transmitted on that S-PMSI. Otherwise, if an I-PMSI exists for that MVPN, the decapsulated data packet should be transmitted on it. (If a MI-PMSI exists, this would typically be used.) If neither of these conditions hold, the decapsulated data packet is not transmitted to the other PEs in the MVPN. The decision as to whether and how to transmit the decapsulated data packet does not affect the processing of the SA control message itself.
与RP交谈MSDP的PE可以从RP接收这样一个封装的数据包。该数据包应该被解除封装并传输到MVPN中的其他PE。如果分组属于特定（S，G）流，并且如果PE是（S，G）已经绑定到的某些S-PMSI的发送器，则应在该S-PMSI上传输解除封装的数据分组。否则，如果该MVPN存在I-PMSI，则应在其上传输解除封装的数据包。（如果存在MI-PMSI，则通常使用该方法。）如果这两种情况均不成立，则未封装的数据包不会传输到MVPN中的其他PE。关于是否以及如何发送解除封装的数据分组的决定不影响SA控制消息本身的处理。
Suppose that PE1 transmits a multicast data packet on a PMSI, where that data packet is part of an (S,G) flow, and PE2 receives that packet from that PMSI. According to Section 9, if PE1 is not the PE that PE2 expects to be transmitting (S,G) packets, then PE2 must discard the packet. If an MSDP-encapsulated data packet is transmitted on a PMSI, as specified above, this rule from Section 9 would likely result in the packet being discarded. Therefore, if MSDP-encapsulated data packets being decapsulated and transmitted on a PMSI, we need to modify the rules of Section 9 as follows:
假设PE1在PMSI上发送多播数据分组，其中该数据分组是（S，G）流的一部分，并且PE2从该PMSI接收该分组。根据第9节，如果PE1不是PE2期望发送（S，G）分组的PE，那么PE2必须丢弃该分组。如果如上所述，在PMSI上传输MSDP封装的数据包，则第9节中的此规则可能会导致丢弃该包。因此，如果MSDP封装的数据包被解封并在PMSI上传输，我们需要修改第9节的规则如下：
1. If the receiving PE, PE2, has already joined the (S,G) tree, and has chosen PE1 as the Upstream PE for the (S,G) tree, but this packet does not come from PE1, PE2 must discard the packet.
1. 如果接收PE PE2已加入（S，G）树，并已选择PE1作为（S，G）树的上游PE，但该数据包不是来自PE1，则PE2必须丢弃该数据包。
2. If the receiving PE, PE2, has not already joined the (S,G) tree, but is a PIM adjacency to a CE that is downstream on the (*,G) tree, the packet should be forwarded to the CE.
2. 如果接收PE PE2尚未加入（S，G）树，而是与（*，G）树上下游的CE相邻的PIM，则应将分组转发给CE。
In BIDIR-PIM, each multicast group is associated with a Rendezvous Point Address (RPA). The Rendezvous Point Link (RPL) is the link that attaches to the RPA. Usually, it's a LAN where the RPA is in the IP subnet assigned to the LAN. The root node of a BIDIR-PIM tree is a node that has an interface on the RPL.
在BIDIR-PIM中，每个多播组都与一个集合点地址（RPA）相关联。集合点链接（RPL）是连接到RPA的链接。通常，它是一个局域网，其中RPA位于分配给该局域网的IP子网中。BIDIR-PIM树的根节点是在RPL上具有接口的节点。
On any LAN (other than the RPL) that is a link in a BIDIR-PIM tree, there must be a single node that has been chosen to be the DF. (More precisely, for each RPA there is a single node that is the DF for that RPA.) A node that receives traffic from an upstream interface may forward it on a particular downstream interface only if the node is the DF for that downstream interface. A node that receives traffic from a downstream interface may forward it on an upstream interface only if that node is the DF for the downstream interface.
在作为BIDIR-PIM树中的链路的任何LAN（RPL除外）上，必须选择一个节点作为DF。（更准确地说，对于每个RPA，有一个节点是该RPA的DF。）从上游接口接收流量的节点可以在特定的下游接口上转发流量，前提是该节点是该下游接口的DF。仅当从下游接口接收流量的节点是下游接口的DF时，该节点才可以在上游接口上转发流量。
If, for any period of time, there is a link on which each of two different nodes believes itself to be the DF, data forwarding loops can form. Loops in a bidirectional multicast tree can be very harmful. However, any election procedure will have a convergence period. The BIDIR-PIM DF election procedure is very complicated, because it goes to great pains to ensure that if convergence is not extremely fast, then there is no forwarding at all until convergence has taken place.
如果在任何一段时间内，存在两个不同节点都认为自己是DF的链路，则可以形成数据转发循环。双向多播树中的循环可能非常有害。然而，任何选举程序都有一个衔接期。BIDIR-PIM DF选举程序非常复杂，因为要确保如果收敛速度不是非常快，那么在收敛发生之前根本没有转发。
Other variants of PIM also have a DF election procedure for LANs. However, as long as the multicast tree is unidirectional, disagreement about who the DF is can result only in duplication of packets, not in loops. Therefore, the time taken to converge on a single DF is of much less concern for unidirectional trees and it is for bidirectional trees.
PIM的其他变体也有用于LAN的DF选择程序。然而，只要多播树是单向的，关于DF是谁的分歧只能导致数据包的重复，而不是循环。因此，对于单向树和双向树，在单个DF上收敛所需的时间要少得多。
In the MVPN environment, if PIM signaling is used among the PEs, then the standard LAN-based DF election procedure can be used. However, election procedures that are optimized for a LAN may not work as well in the MVPN environment. So, an alternative to DF election would be desirable.
在MVPN环境中，如果PEs之间使用PIM信令，则可以使用标准的基于LAN的DF选择程序。但是，为LAN优化的选举过程在MVPN环境中可能无法正常工作。因此，一个替代DF选举的方案是可取的。
If BGP signaling is used among the PEs, an alternative to DF election is necessary. One might think that the "Single Forwarder Selection" procedures described in Sections 5 and 9 could be used to choose a single PE "DF" for the backbone (for a given RPA in a given MVPN). However, that is still likely to leave a convergence period of at least several seconds during which loops could form, and there could be a much longer convergence period if there is anything disrupting the smooth flow of BGP Updates. So, a simple procedure like that is not sufficient.
如果在PEs之间使用BGP信令，则需要DF选择的替代方案。人们可能会认为，第5节和第9节中描述的“单个转发器选择”程序可用于为主干选择单个PE“DF”（对于给定MVPN中的给定RPA）。然而，这仍然可能会留下至少几秒钟的收敛期，在此期间可能会形成循环，如果有任何东西干扰BGP更新的顺利进行，收敛期可能会更长。因此，像这样简单的程序是不够的。
The remainder of this section describes two different methods that can be used to support BIDIR-PIM while eliminating the DF election.
本节的其余部分描述了两种不同的方法，可用于支持BIDIR-PIM，同时消除DF选择。
On a per-MVPN basis, this method treats the whole service provider(s) infrastructure as a single RPL. We refer to such an RPL as an "MVPN-RPL". This eliminates the need for the PEs to engage in any "DF election" procedure because BIDIR-PIM does not have a DF on the RPL.
在每个MVPN的基础上，此方法将整个服务提供商基础设施视为单个RPL。我们将这种RPL称为“MVPN-RPL”。这消除了PEs参与任何“DF选举”程序的需要，因为BIDIR-PIM在RPL上没有DF。
However, this method can only be used if the customer is "outsourcing" the RPL/RPA functionality to the SP.
但是，只有当客户将RPL/RPA功能“外包”给SP时，才能使用此方法。
An MVPN-RPL could be realized either via an I-PMSI (this I-PMSI is on a per-MVPN basis and spans all the PEs that have sites of a given MVPN), via a collection of S-PMSIs, or even via a combination of an I-PMSI and one or more S-PMSIs.
MVPN-RPL可以通过I-PMSI（该I-PMSI基于每个MVPN并跨越具有给定MVPN站点的所有PE）通过S-PMSI集合实现，或者甚至通过I-PMSI和一个或多个S-PMSI的组合实现。
Associated with each MVPN-RPL is an address prefix that is unambiguous within the context of the MVPN associated with the MVPN-RPL.
与每个MVPN-RPL关联的是一个地址前缀，该前缀在与MVPN-RPL关联的MVPN上下文中是明确的。
For a given MVPN, each VRF connected to an MVPN-RPL of that MVPN is configured to advertise to all of its connected CEs the address prefix of the MVPN-RPL.
对于给定的MVPN，连接到该MVPN的MVPN-RPL的每个VRF配置为向其所有连接的CE播发MVPN-RPL的地址前缀。
Since, in BIDIR-PIM, there is no Designated Forwarder on an RPL, in the context of MVPN-RPL, there is no need to perform the Designated Forwarder election among the PEs (note it is still necessary to perform the Designated Forwarder election between a PE and its directly attached CEs, but that is done using plain BIDIR-PIM procedures).
由于在BIDIR-PIM中，RPL上没有指定的转发器，因此在MVPN-RPL的上下文中，不需要在PE之间执行指定的转发器选择（注意，仍然需要在PE与其直接连接的CE之间执行指定的转发器选择，但这是使用普通的BIDIR-PIM程序完成的）。
For a given MVPN, a PE connected to an MVPN-RPL of that MVPN should send multicast data (C-S,C-G) on the MVPN-RPL only if at least one other PE connected to the MVPN-RPL has a downstream multicast state for C-G. In the context of MVPN, this is accomplished by requiring a PE that has a downstream state for a particular C-G of a particular VRF present on the PE to originate a C-multicast route for (C-*,C-G). The RD of this route should be the same as the RD associated with the VRF. The RTs carried by the route should be such as to ensure that the route gets distributed to all the PEs of the MVPN.
对于给定的MVPN，连接到该MVPN的MVPN-RPL的PE应在MVPN-RPL上发送多播数据（C-S，C-G），前提是连接到MVPN-RPL的至少一个其他PE具有C-G的下游多播状态。在MVPN的上下文中，这是通过要求对PE上存在的特定VRF的特定C-G具有下游状态的PE为（C-*，C-G）发起C多播路由来实现的。该路线的RD应与VRF相关的RD相同。路由携带的RTs应确保路由分配给MVPN的所有PE。
A PE that receives (C-S,C-G) multicast data from a CE should forward this data on the MVPN-RPL of the MVPN the CE belongs to only if the PE receives at least one C-multicast route for (C-*, C-G). Otherwise, the PE should not forward the data on the RPL/I-PMSI.
从CE接收（C-S，C-G）多播数据的PE应在CE所属的MVPN的MVPN-RPL上转发该数据，前提是PE至少接收到（C-*，C-G）的一条C多播路由。否则，PE不应转发RPL/I-PMSI上的数据。
When a PE receives a multicast packet with (C-S,C-G) on an MVPN-RPL associated with a given MVPN, the PE forwards this packet to every directly connected CE of that MVPN, provided that the CE sends Join (C-*,C-G) to the PE (provided that the PE has the downstream (C-*,C-G) state). The PE does not forward this packet back on the MVPN-RPL. If a PE has no downstream (C-*,C-G) state, the PE does not forward the packet.
当PE在与给定MVPN相关联的MVPN-RPL上接收到具有（C-S，C-G）的多播分组时，PE将该分组转发给该MVPN的每个直接连接的CE，前提是CE向PE发送加入（C-*，C-G）（前提是PE具有下游（C-*，C-G）状态）。PE不会将此数据包转发回MVPN-RPL。如果PE没有下游（C-*，C-G）状态，则PE不会转发数据包。
This method does not require the use of the MVPN-RPL, and it does not require the customer to outsource the RPA/RPL functionality to the SP.
此方法不需要使用MVPN-RPL，也不需要客户将RPA/RPL功能外包给SP。
Consider a particular C-RPA, call it C-R, in a particular MVPN. Consider the set of PEs that attach to sites that have senders or receivers for a BIDIR-PIM group C-G, where C-R is the RPA for C-G. (As always, we use the "C-" prefix to indicate that we are referring to an address in the VPN's address space rather than in the provider's address space.)
在特定的MVPN中考虑一个特定的C-RPA，称之为C-R。考虑连接到具有BiDI-PIM组C-G的发送器或接收器的站点的PES集合，其中C-R是C-G的RPA（一如既往地，我们使用“C”前缀来指示我们指的是VPN的地址空间中的地址而不是提供者的地址空间中的地址）。
Following the procedures of Section 5.1, each PE in the set independently chooses some other PE in the set to be its "Upstream PE" for those BIDIR-PIM groups with RPA C-R. Optionally, they can all choose the "default selection" (described in Section 5.1) to ensure that each PE to choose the same Upstream PE. Note that if a PE has a route to C-R via a VRF interface, then the PE may choose itself as the Upstream PE.
按照第5.1节的程序，集合中的每个PE独立选择集合中的其他PE作为其具有RPA C-R的BIDIR-PIM组的“上游PE”。可选地，他们都可以选择“默认选择”（如第5.1节所述），以确保每个PE选择相同的上游PE。注意，如果PE通过VRF接口有到C-R的路由，则PE可以选择自己作为上游PE。
The set of PEs can now be partitioned into a number of subsets. We'll say that PE1 and PE2 are in the same partition if and only if there is some PE3 such that PE1 and PE2 have each chosen PE3 as the Upstream PE for C-R. Note that each partition has exactly one Upstream PE. So it is possible to identify the partition by identifying its Upstream PE.
PEs集现在可以划分为多个子集。我们会说，PE1和PE2在同一个分区中，当且仅当存在一些PE3，使得PE1和PE2各自选择PE3作为C-R的上游PE。请注意，每个分区正好有一个上游PE。因此，可以通过识别分区的上游PE来识别分区。
Consider packet P, and let PE1 be its ingress PE. PE1 will send the packet on a PMSI so that it reaches the other PEs that need to receive it. This is done by encapsulating the packet and sending it
考虑分组P，并让PE1成为它的入口PE。PE1将在PMSI上发送数据包，以便它到达需要接收数据包的其他PE。这是通过封装数据包并发送它来完成的
on a P-tunnel. If the original packet is part of a PIM-BIDIR group (its ingress PE determines this from the packet's destination address C-G), and if the VPN backbone is not the RPL, then the encapsulation MUST carry information that can be used to identify the partition to which the ingress PE belongs.
在P型隧道上。如果原始数据包是PIM-BIDIR组的一部分（其入口PE根据数据包的目标地址C-G确定），并且如果VPN主干不是RPL，则封装必须携带可用于识别入口PE所属分区的信息。
When PE2 receives a packet from the PMSI, PE2 must determine, by examining the encapsulation, whether the packet's ingress PE belongs to the same partition (relative to the C-RPA of the packet's C-G) to which the PE2 itself belongs. If not, PE2 discards the packet. Otherwise, PE2 performs the normal BIDIR-PIM data packet processing. With this rule in place, harmful loops cannot be introduced by the PEs into the customer's bidirectional tree.
当PE2从PMSI接收到数据包时，PE2必须通过检查封装来确定数据包的入口PE是否属于PE2本身所属的同一分区（相对于数据包的C-G的C-RPA）。否则，PE2将丢弃该数据包。否则，PE2执行正常的BIDIR-PIM数据分组处理。有了这个规则，PEs就不能将有害的循环引入客户的双向树中。
Note that if there is more than one partition, the VPN backbone will not carry a packet from one partition to another. The only way for a packet to get from one partition to another is for it to go up towards the RPA and then down another path to the backbone. If this is not considered desirable, then all PEs should choose the same Upstream PE for a given C-RPA. Then, multiple partitions will only exist during routing transients.
请注意，如果有多个分区，VPN主干将不会将数据包从一个分区传送到另一个分区。数据包从一个分区到另一个分区的唯一方法是向上到达RPA，然后沿着另一条路径到达主干网。如果认为这是不可取的，则所有PE应为给定的C-RPA选择相同的上游PE。然后，多个分区将仅在路由瞬态期间存在。
If a given P-tunnel is to be used to carry packets traveling along a bidirectional C-tree, then, EXCEPT for the case described in Sections 11.1 and 11.2.3, the packets that travel on that P-tunnel MUST carry a PE Distinguisher Label (defined in Section 4), using the encapsulation discussed in Section 12.3.
如果给定的P-隧道用于承载沿双向C-树传输的数据包，则除第11.1节和第11.2.3节中所述的情况外，在该P-隧道上传输的数据包必须使用第12.3节中讨论的封装携带PE识别标签（第4节中定义）。
When a given PE transmits a given packet of a bidirectional C-group to the P-tunnel, the packet will carry the PE Distinguisher Label corresponding to the partition, for the C-group's C-RPA, that contains the transmitting PE. This is the PE Distinguisher Label that has been bound to the Upstream PE of that partition; it is not necessarily the label that has been bound to the transmitting PE.
当给定的PE将双向C组的给定分组发送到P隧道时，该分组将携带与包含发送PE的C组的C-RPA的分区对应的PE识别器标签。这是已绑定到该分区上游PE的PE识别器标签；不一定是已绑定到传输PE的标签。
Recall that the PE Distinguisher Labels are upstream-assigned labels that are assigned and advertised by the node that is at the root of the P-tunnel. The information about PE Distinguisher Labels is distributed with Intra-AS I-PMSI A-D routes and/or S-PMSI A-D routes by encoding it into the PE Distinguisher Labels attribute carried by these routes.
回想一下，PE识别器标签是上游分配的标签，由位于P通道根部的节点分配和公布。有关PE识别器标签的信息通过将其编码到这些路由携带的PE识别器标签属性中，与内部AS I-PMSI A-D路由和/或S-PMSI A-D路由一起分发。
When a PE receives a packet with a PE label that does not identify the partition of the receiving PE, then the receiving PE discards the packet.
当一个PE接收到一个带有PE标签的数据包时，该PE标签不能识别接收PE的分区，则接收PE丢弃该数据包。
Note that this procedure does not necessarily require the root of a P-tunnel to assign a PE Distinguisher Label for every PE that belongs to the tunnel. If the root of the P-tunnel is the only PE that can transmit packets to the P-tunnel, then the root needs to assign PE Distinguisher Labels only for those PEs that the root has selected to be the UMHs for the particular C-RPAs known to the root.
请注意，此程序不一定要求P通道的根为属于通道的每个PE分配PE识别标签。如果P-tunnel的根是唯一可以向P-tunnel发送数据包的PE，则根需要仅为根已选择为根所知的特定C-RPAs的UMHs的那些PE分配PE识别器标签。
There is one case in which support for BIDIR-PIM C-groups does not require the use of a PE Distinguisher Label. For each C-RPA, suppose a distinct MP2MP LSP is used as the P-tunnel serving that C-RPA's partition. Then, for a given packet, a PE receiving the packet from a P-tunnel can infer the partition from the tunnel. So, PE Distinguisher Labels are not needed in this case.
有一种情况下，对BIDIR-PIM C-组的支持不需要使用PE识别标签。对于每个C-RPA，假设使用一个不同的MP2MP LSP作为服务于该C-RPA分区的P隧道。然后，对于给定的分组，从P隧道接收分组的PE可以从隧道推断分区。因此，在这种情况下不需要PE识别标签。
The BGP-based auto-discovery procedures will ensure that the PEs in a single MVPN only use tunnels that they can all support, and for a given kind of tunnel, that they only use encapsulations that they can all support.
基于BGP的自动发现程序将确保单个MVPN中的PE只使用它们都能支持的隧道，并且对于给定类型的隧道，它们只使用它们都能支持的封装。
GRE encapsulation can be used for any PMSI that is instantiated by a mesh of unicast P-tunnels, as well as for any PMSI that is instantiated by one or more PIM P-tunnels of any sort.
GRE封装可用于由单播P隧道的网格实例化的任何PMSI，以及由任何种类的一个或多个PIM P隧道实例化的任何PMSI。
Packets received Packets in transit Packets forwarded at the ingress PE in the service by the egress PEs provider network
数据包在传输过程中接收的数据包由出口PEs提供商网络在服务中的入口PE转发的数据包
+---------------+
| P-IP Header |
+---------------+
| GRE |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
+---------------+
| P-IP Header |
+---------------+
| GRE |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
The IP Protocol Number field in the P-IP header MUST be set to 47. The Protocol Type field of the GRE header is set to either 0x800 or 0x86dd, depending on whether the C-IP header is IPv4 or IPv6, respectively.
P-IP标头中的IP协议编号字段必须设置为47。GRE头的协议类型字段设置为0x800或0x86dd，具体取决于C-IP头是IPv4还是IPv6。
When an encapsulated packet is transmitted by a particular PE, the source IP address in the P-IP header must be the same address that the PE uses to identify itself in the VRF Route Import Extended Communities that it attaches to any of VPN-IP routes eligible for UMH determination that it advertises via BGP (see Section 5.1).
当封装的数据包由特定PE传输时，P-IP报头中的源IP地址必须与PE在VRF路由导入扩展社区中用于标识自身的地址相同，该VRF路由导入扩展社区连接到其通过BGP播发的符合UMH确定条件的任何VPN-IP路由（见第5.1节）。
If the PMSI is instantiated by a PIM tree, the destination IP address in the P-IP header is the group P-address associated with that tree. The GRE key field value is omitted.
如果PMSI由PIM树实例化，则P-IP头中的目标IP地址是与该树关联的组P地址。省略GRE键字段值。
If the PMSI is instantiated by unicast P-tunnels, the destination IP address is the address of the destination PE, and the optional GRE key field is used to identify a particular MVPN. In this case, each PE would have to advertise a key field value for each MVPN; each PE would assign the key field value that it expects to receive.
如果PMSI由单播P隧道实例化，则目标IP地址是目标PE的地址，可选GRE密钥字段用于标识特定MVPN。在这种情况下，每个PE必须为每个MVPN公布一个键字段值；每个PE将分配它期望接收的键字段值。
[RFC2784] specifies an optional GRE checksum and [RFC2890] specifies an optional GRE sequence number fields.
[RFC2784]指定可选的GRE校验和，[RFC2890]指定可选的GRE序列号字段。
The GRE sequence number field is not needed because the transport layer services for the original application will be provided by the C-IP header.
不需要GRE序列号字段，因为原始应用程序的传输层服务将由C-IP报头提供。
The use of the GRE checksum field must follow [RFC2784].
GRE校验和字段的使用必须遵循[RFC2784]。
To facilitate high speed implementation, this document recommends that the ingress PE routers encapsulate VPN packets without setting the checksum or sequence fields.
为了便于高速实施，本文档建议入口PE路由器封装VPN数据包，而不设置校验和或序列字段。
IP-in-IP [RFC2003] is also a viable option. The following diagram shows the progression of the packet as it enters and leaves the service provider network.
IP[RFC2003]中的IP也是一个可行的选择。下图显示了数据包进入和离开服务提供商网络的过程。
Packets received Packets in transit Packets forwarded at the ingress PE in the service by the egress PEs provider network
数据包在传输过程中接收的数据包由出口PEs提供商网络在服务中的入口PE转发的数据包
+---------------+
| P-IP Header |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
+---------------+
| P-IP Header |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
When the P-IP header is an IPv4 header, its Protocol Number field is set to either 4 or 41, depending on whether the C-IP header is an IPv4 header or an IPv6 header, respectively.
当P-IP报头是IPv4报头时，其协议编号字段设置为4或41，具体取决于C-IP报头是IPv4报头还是IPv6报头。
When the P-IP header is an IPv6 header, its Next Header field is set to either 4 or 41, depending on whether the C-IP header is an IPv4 header or an IPv6 header, respectively.
当P-IP报头是IPv6报头时，其下一个报头字段设置为4或41，具体取决于C-IP报头是IPv4报头还是IPv6报头。
When an encapsulated packet is transmitted by a particular PE, the source IP address in the P-IP header must be the same address that the PE uses to identify itself in the VRF Route Import Extended Communities that it attaches to any of VPN-IP routes eligible for UMH determination that it advertises via BGP (see Section 5.1).
当封装的数据包由特定PE传输时，P-IP报头中的源IP地址必须与PE在VRF路由导入扩展社区中用于标识自身的地址相同，该VRF路由导入扩展社区连接到其通过BGP播发的符合UMH确定条件的任何VPN-IP路由（见第5.1节）。
If the PMSI is instantiated as a P2MP MPLS LSP or a MP2MP LSP, MPLS encapsulation is used. Penultimate-hop-popping MUST be disabled for the LSP.
如果PMSI实例化为P2MP MPLS LSP或MP2MP LSP，则使用MPLS封装。必须为LSP禁用倒数第二跳弹出。
If other methods of assigning MPLS labels to multicast distribution trees are in use, these multicast distribution trees may be used as appropriate to instantiate PMSIs, and appropriate additional MPLS encapsulation procedures may be used.
如果正在使用将MPLS标签分配给多播分发树的其他方法，则可以适当地使用这些多播分发树来实例化PMSIs，并且可以使用适当的附加MPLS封装过程。
Packets received Packets in transit Packets forwarded at the ingress PE in the service by the egress PEs provider network
数据包在传输过程中接收的数据包由出口PEs提供商网络在服务中的入口PE转发的数据包
+---------------+
| P-MPLS Header |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
+---------------+
| P-MPLS Header |
++=============++ ++=============++ ++=============++
|| C-IP Header || || C-IP Header || || C-IP Header ||
++=============++ >>>>> ++=============++ >>>>> ++=============++
|| C-Payload || || C-Payload || || C-Payload ||
++=============++ ++=============++ ++=============++
The encapsulations for transmitting multicast data messages when there are multiple PMSIs per P-tunnel are based on the encapsulation for a single PMSI per P-tunnel, but with an MPLS label used for demultiplexing.
当每个P隧道有多个PMSI时，用于传输多播数据消息的封装基于每个P隧道单个PMSI的封装，但具有用于解复用的MPLS标签。
The label is upstream-assigned and distributed via BGP as specified in Section 4. The label must enable the receiver to select the proper VRF and may enable the receiver to select a particular multicast routing entry within that VRF.
按照第4节的规定，标签通过BGP向上游分配和分发。标签必须使接收者能够选择适当的VRF，并且可以使接收者能够选择该VRF内的特定多播路由条目。
Rather than the IP-in-GRE encapsulation discussed in Section 12.1.1, we use the MPLS-in-GRE encapsulation. This is specified in [MPLS-IP]. The GRE protocol type MUST be set to 0x8847. (The reason for using the unicast rather than the multicast value is specified in [MPLS-MCAST-ENCAPS]).
我们使用MPLS in GRE封装，而不是第12.1.1节中讨论的IP in GRE封装。这在[MPLS-IP]中有规定。GRE协议类型必须设置为0x8847。（使用单播而不是多播值的原因在[MPLS-MCAST-ENCAPS]中指定）。
Rather than the IP-in-IP encapsulation discussed in Section 12.1.2, we use the MPLS-in-IP encapsulation. This is specified in [MPLS-IP]. The IP protocol number field MUST be set to the value identifying the payload as an MPLS unicast packet. (There is no "MPLS multicast packet" protocol number.)
与第12.1.2节中讨论的IP-in-IP封装不同，我们使用MPLS-in-IP封装。这在[MPLS-IP]中有规定。IP协议编号字段必须设置为将有效负载标识为MPLS单播数据包的值。（没有“MPLS多播数据包”协议编号。）
As discussed in Section 9, if a multicast data packet is traveling on a unidirectional C-tree, it is highly desirable for the PE that receives the packet from a PMSI to be able to determine the identity of the PE that transmitted the data packet onto the PMSI. The encapsulations of the previous sections all provide this information, except in one case. If a PMSI is being instantiated by an MP2MP LSP, then the encapsulations discussed so far do not allow one to determine the identity of the PE that transmitted the packet onto the PMSI.
如第9节中所讨论的，如果多播数据分组在单向C-树上移动，则从PMSI接收分组的PE非常希望能够确定将数据分组发送到PMSI的PE的身份。除一种情况外，前面部分的封装都提供了此信息。如果PMSI由MP2MP LSP实例化，那么到目前为止讨论的封装不允许确定将数据包传输到PMSI的PE的身份。
Therefore, when a packet traveling on a unidirectional C-tree is traveling on a MP2MP LSP P-tunnel, it MUST carry, as its second label, a label that has been bound to the packet's ingress PE. This label is an upstream-assigned label that the LSP's root node has bound to the ingress PE and has distributed via the PE Distinguisher
因此，当在单向C-树上移动的数据包在MP2MP LSP-隧道上移动时，它必须携带已绑定到数据包入口PE的标签作为其第二标签。此标签是上游分配的标签，LSP的根节点已绑定到入口PE，并已通过PE识别器分发
Labels attribute of a PMSI A-D route (see Section 4). This label will appear immediately beneath the labels that are discussed in Sections 12.1.3 and 12.2.
PMSI a-D路线的标签属性（见第4节）。该标签将直接出现在第12.1.3节和第12.2节讨论的标签下方。
A full specification of the procedures for advertising and for using the PE Distinguisher Labels attribute in this case is outside the scope of this document.
在这种情况下，广告和PE Discriminator Labels属性使用程序的完整规范不在本文档范围内。
As was discussed in Section 11, when a packet belongs to a PIM-BIDIR multicast group, the set of PEs of that packet's VPN can be partitioned into a number of subsets, where exactly one PE in each partition is the Upstream PE for that partition. When such packets are transmitted on a PMSI, unless the procedures of Section 11.2.3 are being used, it is necessary for the packet to carry information identifying a particular partition. This is done by having the packet carry the PE Distinguisher Label corresponding to the Upstream PE of one partition. For a particular P-tunnel, this label will have been advertised by the node that is the root of that P-tunnel. (A full specification of the procedures for advertising PE Distinguisher Labels is out of the scope of this document.)
正如在第11节中所讨论的，当分组属于PIM-BIDIR多播组时，该分组的VPN的PE集可以被划分为若干子集，其中每个分区中正好有一个PE是该分区的上游PE。当此类数据包在PMSI上传输时，除非使用第11.2.3节中的程序，否则数据包必须携带识别特定分区的信息。这是通过使分组携带对应于一个分区的上游PE的PE识别器标签来实现的。对于特定的P隧道，此标签将由作为该P隧道根的节点播发。（PE识别器标签广告程序的完整规范不在本文件范围内。）
This label needs to be used whenever a packet belongs to a PIM-BIDIR C-group, no matter what encapsulation is used by the P-tunnel. Hence, the encapsulations of Section 12.2 MUST be used. If the P-tunnel contains only one PMSI, the PE label replaces the label discussed in Section 12.2. If the P-tunnel contains multiple PMSIs, the PE label follows the label discussed in Section 12.2.
无论P隧道使用何种封装，只要数据包属于PIM-BIDIR C组，就需要使用此标签。因此，必须使用第12.2节的封装。如果P型隧道仅包含一个PMSI，则PE标签将替换第12.2节中讨论的标签。如果P型隧道包含多个PMSI，则PE标签遵循第12.2节中讨论的标签。
In general, PE Distinguisher Labels can be carried if the encapsulation is MPLS, MPLS-in-IP, or MPLS-in-GRE. However, procedures for advertising and using PE Distinguisher Labels when the encapsulation is LDP-based MP2P MPLS is outside the scope of this specification.
通常，如果封装是MPLS、IP中的MPLS或GRE中的MPLS，则可以携带PE识别器标签。然而，当封装是基于LDP的MP2P MPLS时，广告和使用PE识别标签的程序不在本规范的范围内。
These apply also to the MPLS-in-IP and MPLS-in-GRE encapsulations.
这些也适用于IP中的MPLS和GRE封装中的MPLS。
It is the responsibility of the originator of a C-packet to ensure that the packet is small enough to reach all of its destinations, even when it is encapsulated within IP or GRE.
C数据包的发起人负责确保数据包足够小，能够到达其所有目的地，即使它被封装在IP或GRE中。
When a packet is encapsulated in IP or GRE, the router that does the encapsulation MUST set the DF bit in the outer header. This ensures that the decapsulating router will not need to reassemble the encapsulating packets before performing decapsulation.
当数据包被封装在IP或GRE中时，进行封装的路由器必须在外部报头中设置DF位。这确保了去封装路由器在执行去封装之前不需要重新组装封装包。
In some cases, the encapsulating router may know that a particular C-packet is too large to reach its destinations. Procedures by which it may know this are outside the scope of the current document. However, if this is known, then:
在某些情况下，封装路由器可能知道特定的C分组太大而无法到达其目的地。它可能知道这一点的程序不在当前文件的范围内。但是，如果这是已知的，则：
- If the DF bit is set in the IP header of a C-packet that is known to be too large, the router will discard the C-packet as being "too large" and follow normal IP procedures (which may require the return of an ICMP message to the source).
- 如果在已知过大的C数据包的IP报头中设置了DF位，路由器将丢弃“过大”的C数据包，并遵循正常的IP过程（这可能需要向源返回ICMP消息）。
- If the DF bit is not set in the IP header of a C-packet that is known to be too large, the router MAY fragment the packet before encapsulating it and then encapsulate each fragment separately. Alternatively, the router MAY discard the packet.
- 如果在已知过大的C数据包的IP报头中未设置DF位，则路由器可在封装该数据包之前对其进行分段，然后分别封装每个分段。或者，路由器可以丢弃该分组。
If the router discards a packet as too large, it should maintain Operations, Administration, and Maintenance (OAM) information related to this behavior, allowing the operator to properly troubleshoot the issue.
如果路由器丢弃的数据包太大，它应该维护与此行为相关的操作、管理和维护（OAM）信息，以便操作员正确地解决问题。
Note that if the entire path of the P-tunnel does not support an MTU that is large enough to carry the a particular encapsulated C-packet, and if the encapsulating router does not do fragmentation, then the customer will not receive the expected connectivity.
注意，如果P隧道的整个路径不支持足够大的MTU来承载特定封装的C分组，并且如果封装路由器不进行分段，则客户将不会收到预期的连接。
The ingress PE should not copy the TTL field from the payload IP header received from a CE router to the delivery IP or MPLS header. The setting of the TTL of the delivery header is determined by the local policy of the ingress PE router.
入口PE不应将TTL字段从从CE路由器接收的有效负载IP报头复制到传送IP或MPLS报头。传送头的TTL设置由入口PE路由器的本地策略决定。
If the SP is providing Internet multicast, distinct from its VPN multicast services, and using PIM based P-multicast trees, it must ensure that the group P-addresses that it used in support of MVPN services are distinct from any of the group addresses of the Internet multicasts it supports. This is best done by using administratively scoped addresses [ADMIN-ADDR].
如果SP提供不同于其VPN多播服务的Internet多播，并使用基于PIM的P多播树，则必须确保其用于支持MVPN服务的组P地址不同于其支持的Internet多播的任何组地址。这最好通过使用管理作用域地址[ADMIN-ADDR]来实现。
The group C-addresses need not be distinct from either the group P-addresses or the Internet multicast addresses.
组C地址不需要与组P地址或Internet多播地址不同。
The setting of the DS (Differentiated Services) field in the delivery IP header should follow the guidelines outlined in [RFC2983]. Setting the Traffic Class field [RFC5462] in the delivery MPLS header should follow the guidelines in [RFC3270]. An SP may also choose to deploy any of additional Differentiated Services mechanisms that the PE routers support for the encapsulation in use. Note that the type of encapsulation determines the set of Differentiated Services mechanisms that may be deployed.
交付IP报头中DS（区分服务）字段的设置应遵循[RFC2983]中概述的准则。在传送MPLS标头中设置流量类别字段[RFC5462]应遵循[RFC3270]中的指导原则。SP还可以选择部署PE路由器支持的用于所使用封装的任何附加区分服务机制。请注意，封装的类型决定了可以部署的一组差异化服务机制。
This document describes an extension to the procedures of [RFC4364], and hence shares the security considerations described in [RFC4364] and [RFC4365].
本文档描述了[RFC4364]过程的扩展，因此共享[RFC4364]和[RFC4365]中描述的安全注意事项。
When GRE encapsulation is used, the security considerations of [MPLS-IP] are also relevant. Additionally, the security considerations of [RFC4797] are relevant as it discusses implications on packet spoofing in the context of BGP/MPLS IP VPNs.
当使用GRE封装时，[MPLS-IP]的安全注意事项也是相关的。此外，[RFC4797]的安全注意事项是相关的，因为它讨论了BGP/MPLS IP VPN上下文中的数据包欺骗问题。
The security considerations of [MPLS-HDR] apply when MPLS encapsulation is used.
当使用MPLS封装时，[MPLS-HDR]的安全注意事项适用。
This document makes use of a number of control protocols: PIM [PIM-SM], BGP [MVPN-BGP], mLDP [MLDP], and RSVP-TE [RSVP-P2MP]. Security considerations relevant to each protocol are discussed in the respective protocol specifications.
本文件使用了许多控制协议：PIM[PIM-SM]、BGP[MVPN-BGP]、mLDP[mLDP]和RSVP-TE[RSVP-P2MP]。各协议规范中讨论了与各协议相关的安全注意事项。
If one uses the UDP-based protocol for switching to S-PMSI (as specified in Section 7.4.2), then an S-PMSI Join message (i.e., a UDP packet with destination port 3232 and destination address ALL-PIM-ROUTERS) that is not received over a PMSI (e.g., one received directly from a CE router) is an illegal packet and MUST be dropped.
如果使用基于UDP的协议切换到S-PMSI（如第7.4.2节所述），则未通过PMSI接收的S-PMSI加入消息（即，具有目标端口3232和目标地址ALL-PIM-ROUTERS的UDP数据包）（例如，直接从CE路由器接收的数据包）是非法数据包，必须丢弃。
The various procedures for P-tunnel construction have security issues that are specific to the way that the P-tunnels are used in this document. When P-tunnels are constructed via such techniques as PIM, mLDP, or RSVP-TE, each P or PE router receiving a control message MUST ensure that the control message comes from another P or PE router, not from a CE router. (Interpreting an mLDP or PIM or RSVP-TE control message from a CE router as referring to a P-tunnel would be a bug.)
P型隧道施工的各种程序都有安全问题，这些问题与本文件中P型隧道的使用方式有关。当通过PIM、mLDP或RSVP-TE等技术构建P隧道时，每个接收控制消息的P或PE路由器必须确保控制消息来自另一个P或PE路由器，而不是CE路由器。（将来自CE路由器的mLDP或PIM或RSVP-TE控制消息解释为指向P隧道将是一个错误。）
A PE MUST NOT accept BGP routes of the MCAST-VPN address family from a CE.
PE不得从CE接受MCAST-VPN地址系列的BGP路由。
If BGP is used as a CE-PE routing protocol, then when a PE receives an IP route from a CE, if this route carries the VRF Route Import Extended Community, the PE MUST remove this Community from the route before turning it into a VPN-IP route. Routes that a PE advertises to a CE MUST NOT carry the VRF Route Import Extended Community.
如果BGP用作CE-PE路由协议，则当PE从CE接收到IP路由时，如果此路由承载VRF路由导入扩展社区，则PE必须在将其转换为VPN-IP路由之前从路由中删除此社区。PE向CE发布广告的路线不得携带VRF路线导入扩展社区。
An ASBR may receive, from one SP's domain, an mLDP, PIM, or RSVP-TE control message that attempts to extend a P-tunnel from one SP's domain into another SP's domain. This is perfectly valid if there is an agreement between the SPs to jointly provide an MVPN service. In the absence of such an agreement, however, this could be an illegitimate attempt to intercept data packets. By default, an ASBR MUST NOT allow P-tunnels to extend beyond AS boundaries. However, it MUST be possible to configure an ASBR to allow this on a specified set of interfaces.
ASBR可能会从一个SP的域接收mLDP、PIM或RSVP-TE控制消息，该消息试图将P隧道从一个SP的域扩展到另一个SP的域。如果SP之间达成协议共同提供MVPN服务，则该协议完全有效。然而，在没有此类协议的情况下，这可能是拦截数据包的非法企图。默认情况下，ASBR不得允许P隧道延伸到AS边界之外。但是，必须能够将ASBR配置为允许在指定的一组接口上执行此操作。
Many of the procedures in this document cause the SP network to create and maintain an amount of state that is proportional to customer multicast activity. If the amount of customer multicast activity exceeds expectations, this can potentially cause P and PE routers to maintain an unexpectedly large amount of state, which may cause control and/or data plane overload. To protect against this situation, an implementation should provide ways for the SP to bound the amount of state it devotes to the handling of customer multicast activity.
本文档中的许多过程都会导致SP网络创建和维护与客户多播活动成比例的状态量。如果客户多播活动的数量超出预期，这可能会导致P和PE路由器保持意外的大量状态，这可能会导致控制和/或数据平面过载。为了防止出现这种情况，实现应该为SP提供方法来限制其用于处理客户多播活动的状态量。
In particular, an implementation SHOULD provide mechanisms that allow an SP to place limitations on the following:
具体而言，实施应提供允许SP对以下内容进行限制的机制：
- total number of (C-*,C-G) and/or (C-S,C-G) states per VRF
- 每个VRF的（C-*，C-G）和/或（C-S，C-G）状态总数
- total number of P-tunnels per VRF used for S-PMSIs
- 用于S-PMSIs的每个VRF的P-隧道总数
- total number of P-tunnels traversing a given P router
- 穿过给定P路由器的P隧道总数
A PE implementation MAY also provide mechanisms that allow an SP to limit the rate of change of various MVPN-related states on PEs, as well as the rate at which MVPN-related control messages may be received by a PE from the CEs and/or sent from the PE to other PEs.
PE实现还可以提供允许SP限制PE上各种MVPN相关状态的变化率的机制，以及PE从CEs接收和/或从PE发送到其他PE的MVPN相关控制消息的速率。
An implementation that provides the procedures specified in Sections 10.1 or 10.2 MUST provide the capability to impose an upper bound on the number of Source Active A-D routes generated and on how frequently they may be originated. This MUST be provided on a per-PE, per-MVPN granularity.
提供第10.1节或第10.2节中规定的程序的实施必须能够对生成的源活动A-D路由的数量以及它们可能发起的频率施加上限。这必须在每个PE、每个MVPN粒度上提供。
Lack of the mechanisms that allow an SP to limit the rate of change of various MVPN-related states on PEs, as well as the rate at which MVPN-related control messages may be received by a PE from the CEs and/or sent from the PE to other PEs may result in the control plane overload on the PE, which in turn would adversely impact all the customers connected to that PE, as well as to other PEs.
缺乏允许SP限制PE上各种MVPN相关状态变化率的机制，以及PE从CEs接收和/或从PE发送到其他PE的MVPN相关控制消息的速率，可能导致PE上的控制平面过载，这反过来会对与该PE以及其他PE相关的所有客户产生不利影响。
See also the Security Considerations section of [MVPN-BGP].
另请参见[MVPN-BGP]的安全注意事项部分。
Section 7.4.2 defines the "S-PMSI Join message", which is carried in a UDP datagram whose port number is 3232. This port number had already been assigned by IANA to "MDT port". The reference has been updated to this document.
第7.4.2节定义了“S-PMSI连接消息”，该消息在端口号为3232的UDP数据报中传输。IANA已将此端口号分配给“MDT端口”。本文件的参考已更新。
IANA has created a registry for the "S-PMSI Join message Type Field". Assignments are to be made according to the policy "IETF Review" as defined in [RFC5226]. The value 1 has been registered with a reference to this document. The description reads "PIM IPv4 S-PMSI (unaggregated)".
IANA已经为“S-PMSI连接消息类型字段”创建了一个注册表。根据[RFC5226]中定义的“IETF审查”政策进行分配。已通过引用本文件注册了值1。描述内容为“PIM IPv4 S-PMSI（未聚合）”。
[PIM-ATTRIB] establishes a registry for "PIM Join attribute Types". IANA has assigned the value 1 to the "MVPN Join Attribute" with a reference to this document.
[PIM-ATTRIB]为“PIM连接属性类型”建立注册表。IANA已将值1分配给“MVPN连接属性”，并引用了本文档。
IANA has assigned SAFI 129 to "Multicast for BGP/MPLS IP Virtual Private Networks (VPNs)" with a reference to this document and [MVPN-BGP].
IANA参考本文件和[MVPN-BGP]将SAFI 129分配给“BGP/MPLS IP虚拟专用网络（VPN）的多播”。
Significant contributions were made Arjen Boers, Toerless Eckert, Adrian Farrel, Luyuan Fang, Dino Farinacci, Lenny Giuliano, Shankar Karuna, Anil Lohiya, Tom Pusateri, Ted Qian, Robert Raszuk, Tony Speakman, Dan Tappan.
阿尔扬·波尔斯、托利斯·埃克特、阿德里安·法雷尔、卢元芳、迪诺·法里纳奇、莱尼·朱利亚诺、尚卡尔·卡鲁纳、阿尼尔·洛希亚、汤姆·普萨特里、特德·钱、罗伯特·拉祖克、托尼·斯帕克曼和塔潘做出了重大贡献。
[MLDP] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[MLDP]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月。
[MPLS-HDR] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[MPLS-HDR]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[MPLS-IP] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[MPLS-IP]Worster，T.，Rekhter，Y.，和E.Rosen，Ed.，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，2005年3月。
[MPLS-MCAST-ENCAPS] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[MPLS-MCAST-ENCAPS]埃克特，T.，罗森，E.，埃德，阿加瓦尔，R.，和Y.雷克特，“MPLS多播封装”，RFC 53322008年8月。
[MPLS-UPSTREAM-LABEL] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[MPLS-UPSTREAM-LABEL]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 53312008年8月。
[MVPN-BGP] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012.
[MVPN-BGP]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，2012年2月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[OSPF-MT] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[OSPF-MT]Psenak，P.，Mirtorabi，S.，Roy，A.，Nguyen，L.，和P.Pillay Esnault，“OSPF中的多拓扑（MT）路由”，RFC 4915，2007年6月。
[PIM-ATTRIB] Boers, A., Wijnands, I., and E. Rosen, "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, November 2008.
[PIM-ATTRIB]Boers，A.，Wijnands，I.，和E.Rosen，“协议独立多播（PIM）连接属性格式”，RFC 5384，2008年11月。
[PIM-SM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[PIM-SM]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[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月。
[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月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 46592006年9月。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.
[RFC5462]Andersson，L.和R.Asati，“多协议标签交换（MPLS）标签堆栈条目：“EXP”字段重命名为“流量类”字段”，RFC 5462，2009年2月。
[RSVP-OOB] Ali, Z., Swallow, G., and R. Aggarwal, "Non-Penultimate Hop Popping Behavior and Out-of-Band Mapping for RSVP-TE Label Switched Paths", RFC 6511, February 2012.
[RSVP-OOB]Ali，Z.，Swallow，G.，和R.Aggarwal，“RSVP-TE标签交换路径的非倒数第二跳弹出行为和带外映射”，RFC 6511，2012年2月。
[RSVP-P2MP] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RSVP-P2MP]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[ADMIN-ADDR] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[ADMIN-ADDR]Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[BIDIR-PIM] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[BIDIR-PIM]Handley，M.，Kouvelas，I.，Speakman，T.，和L.Vicisano，“双向协议独立多播（BIDIR-PIM）”，RFC 50152007年10月。
[BSR] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008.
[BSR]Bhaskar，N.，Gall，A.，Lingard，J.，和S.Venaas，“用于协议独立多播（PIM）的引导路由器（BSR）机制”，RFC 5059，2008年1月。
[MVPN-REQ] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[MVPN-REQ]Morin，T.，Ed.“第3层提供商提供的虚拟专用网络（PPVPN）中的多播要求”，RFC 4834，2007年4月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890]Dommety，G.“GRE的密钥和序列号扩展”，RFC 28902000年9月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]Fenner，B.，Ed.，和D.Meyer，Ed.，“多播源发现协议（MSDP）”，RFC 3618，2003年10月。
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, February 2006.
[RFC4365]Rosen，E.“BGP/MPLS IP虚拟专用网络（VPN）的适用性声明”，RFC 4365，2006年2月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]Holbrook，H.和B.Cain，“IP的源特定多播”，RFC4607，2006年8月。
[RFC4797] Rekhter, Y., Bonica, R., and E. Rosen, "Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks", RFC 4797, January 2007.
[RFC4797]Rekhter，Y.，Bonica，R.，和E.Rosen，“在BGP/MPLS IP虚拟专用网络中使用提供商边缘到提供商边缘（PE-PE）通用路由封装（GRE）或IP”，RFC 4797，2007年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Contributing Authors
撰稿人
Sarveshwar Bandi Motorola Vanenburg IT park, Madhapur, Hyderabad, India EMail: sarvesh@motorola.com
Sarveshwar Bandi Motorola Vanenburg IT park，Madhapur，Hyderabad，India电子邮件：sarvesh@motorola.com
Yiqun Cai Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: ycai@cisco.com
蔡益群思科系统有限公司，地址：加利福尼亚州圣何塞塔斯曼大道170号，邮编：95134电子邮件：ycai@cisco.com
Thomas Morin France Telecom R & D 2, avenue Pierre-Marzin 22307 Lannion Cedex France EMail: thomas.morin@francetelecom.com
Thomas Morin法国电信研发2号，Pierre Marzin大街22307 Lannion Cedex France电子邮件：Thomas。morin@francetelecom.com
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: yakov@juniper.net
Yakov Rekhter Juniper Networks 1194 North Mathilda Ave.Sunnyvale，CA 94089电子邮件：yakov@juniper.net
IJsbrand Wijnands Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: ice@cisco.com
IJsbrand Wijnands Cisco Systems，Inc.加利福尼亚州圣何塞塔斯曼大道170号，95134电子邮件：ice@cisco.com
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422 59 4769 EMail: yasukawa.seisho@lab.ntt.co.jp
日本东京武藏寺3-Chome Musashino Shi，日本靖川正雄NTT公司9-11，180-8585电话：+81 422 59 4769电子邮件：靖川。seisho@lab.ntt.co.jp
Editors' Addresses
编辑地址
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 EMail: erosen@cisco.com
Eric C.Rosen Cisco Systems，Inc.马萨诸塞州伯斯堡马萨诸塞大道1414号，邮编01719电子邮件：erosen@cisco.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: raggarwa_1@yahoo.com
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave.Sunnyvale，CA 94089电子邮件：raggarwa_1@yahoo.com