Internet Engineering Task Force (IETF) E. Rosen, Ed.
Request for Comments: 7988 Juniper Networks, Inc.
Updates: 6513, 6514 K. Subramanian
Category: Standards Track Sproute Networks
ISSN: 2070-1721 Z. Zhang
Juniper Networks, Inc.
October 2016
Internet Engineering Task Force (IETF) E. Rosen, Ed.
Request for Comments: 7988 Juniper Networks, Inc.
Updates: 6513, 6514 K. Subramanian
Category: Standards Track Sproute Networks
ISSN: 2070-1721 Z. Zhang
Juniper Networks, Inc.
October 2016
Ingress Replication Tunnels in Multicast VPN
多播VPN中的入口复制隧道
Abstract
摘要
RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) trees across the Service Provider's backbone. One type of P2MP tree that may be used is known as an "Ingress Replication (IR) tunnel". In an IR tunnel, a parent node need not be directly connected to its child nodes. When a parent node has to send a multicast data packet to its n child nodes, it does not use Layer 2 multicast, IP multicast, or MPLS multicast to do so. Rather, it makes n individual copies, and then unicasts each copy, through an IP or MPLS unicast tunnel, to exactly one child node. While the prior MVPN specifications allow the use of IR tunnels, those specifications are not always very clear or explicit about how the MVPN protocol elements and procedures are applied to IR tunnels. This document updates RFCs 6513 and 6514 by adding additional details that are specific to the use of IR tunnels.
RFC 6513、6514和其他RFC描述了服务提供商向其客户提供多播VPN（MVPN）服务的过程。这些过程在服务提供商的主干上创建点对多点（P2MP）或多点对多点（MP2MP）树。可以使用的一种P2MP树称为“入口复制（IR）隧道”。在IR隧道中，父节点不需要直接连接到其子节点。当父节点必须向其n个子节点发送多播数据包时，它不使用第2层多播、IP多播或MPLS多播来执行此操作。相反，它制作n个单独的副本，然后通过IP或MPLS单播隧道将每个副本单播到一个子节点。虽然先前的MVPN规范允许使用IR隧道，但这些规范并不总是非常清楚或明确地说明MVPN协议元素和过程如何应用于IR隧道。本文档通过添加特定于IR隧道使用的其他详细信息来更新RFCs 6513和6514。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7988.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7988.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. What is an IR P-tunnel? . . . . . . . . . . . . . . . . . . . 5
3. How are IR P-tunnels identified? . . . . . . . . . . . . . . 7
4. How to Join an IR P-Tunnel . . . . . . . . . . . . . . . . . 9
4.1. Advertised IR P-Tunnels . . . . . . . . . . . . . . . . . 9
4.1.1. If the Leaf Information Required Bit Is Set . . . . . 10
4.1.2. If the Leaf Information Required Bit Is Not Set . . . 10
4.2. Unadvertised IR P-Tunnels . . . . . . . . . . . . . . . . 11
5. The PTA's Tunnel Identifier Field . . . . . . . . . . . . . . 11
6. A Note on IR P-Tunnels and Discarding Packets from the Wrong
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. The PTA's MPLS Label Field . . . . . . . . . . . . . . . . . 14
7.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 14
7.2. Leaf A-D Route Originated by an Intermediate Node . . . . 16
7.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 17
8. How A Child Node Prunes Itself from an IR P-Tunnel . . . . . 17
9. Parent Node Actions upon Receiving Leaf A-D Route . . . . . . 18
10. Use of Timers When Switching UMH . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. What is an IR P-tunnel? . . . . . . . . . . . . . . . . . . . 5
3. How are IR P-tunnels identified? . . . . . . . . . . . . . . 7
4. How to Join an IR P-Tunnel . . . . . . . . . . . . . . . . . 9
4.1. Advertised IR P-Tunnels . . . . . . . . . . . . . . . . . 9
4.1.1. If the Leaf Information Required Bit Is Set . . . . . 10
4.1.2. If the Leaf Information Required Bit Is Not Set . . . 10
4.2. Unadvertised IR P-Tunnels . . . . . . . . . . . . . . . . 11
5. The PTA's Tunnel Identifier Field . . . . . . . . . . . . . . 11
6. A Note on IR P-Tunnels and Discarding Packets from the Wrong
PE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. The PTA's MPLS Label Field . . . . . . . . . . . . . . . . . 14
7.1. Leaf A-D Route Originated by an Egress PE . . . . . . . . 14
7.2. Leaf A-D Route Originated by an Intermediate Node . . . . 16
7.3. Intra-AS I-PMSI A-D Route . . . . . . . . . . . . . . . . 17
8. How A Child Node Prunes Itself from an IR P-Tunnel . . . . . 17
9. Parent Node Actions upon Receiving Leaf A-D Route . . . . . . 18
10. Use of Timers When Switching UMH . . . . . . . . . . . . . . 19
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
RFCs 6513, 6514, and other RFCs describe procedures by which a Service Provider (SP) may offer Multicast VPN (MVPN) service to its customers. These procedures create point-to-multipoint (P2MP) or multipoint-to-multipoint (MP2MP) tunnels, called "P-tunnels" (provider tunnels), across the SP's backbone network. Customer multicast traffic is carried through the P-tunnels.
RFC 6513、6514和其他RFC描述了服务提供商（SP）向其客户提供多播VPN（MVPN）服务的过程。这些过程创建跨SP主干网的点对多点（P2MP）或多点对多点（MP2MP）隧道，称为“P隧道”（提供商隧道）。客户多播流量通过P隧道传输。
A number of different P-tunnel technologies are supported. One of the supported P-tunnel technologies is known as "ingress replication" or "unicast replication". We will use the acronym "IR" to refer to this P-tunnel technology.
支持多种不同的P隧道技术。受支持的P隧道技术之一称为“入口复制”或“单播复制”。我们将使用首字母缩略词“IR”来指代这种P-tunnel技术。
An IR P-tunnel is a P2MP tree, but a given node on the tree is not necessarily directly attached to its parent node or to its child nodes. To send a multicast data packet from a parent node to one of its child nodes, the parent node encapsulates the packet and then unicasts it through a tunnel to the child node. The tunnel may be a P2P or MP2P MPLS LSP (Label Switched Path) or a unicast IP tunnel. If a node on an IR tree has n child nodes, and has a multicast data packet that must be sent along the tree, the parent node makes n individual copies of the data packet, and then sends each copy, through a unicast tunnel, to exactly one child node. No lower-layer multicast technology is used when sending traffic from a parent node to a child node; therefore, multiple copies of the packet may be sent out a single interface.
IR P隧道是P2MP树，但树上的给定节点不一定直接连接到其父节点或其子节点。要将多播数据包从父节点发送到其子节点之一，父节点封装该数据包，然后通过隧道将其单播到子节点。隧道可以是P2P或MP2P MPLS LSP（标签交换路径）或单播IP隧道。如果IR树上的节点有n个子节点，并且具有必须沿该树发送的多播数据包，则父节点制作数据包的n个单独副本，然后通过单播隧道将每个副本发送到恰好一个子节点。当从父节点向子节点发送流量时，不使用低层多播技术；因此，包的多个副本可以通过单个接口发送出去。
With the single exception of IR, the P-tunnel technologies supported by the MVPN specifications are preexisting IP multicast or MPLS multicast technologies. Each such technology has its own set of specifications, its own setup and maintenance protocols, its own syntax for identifying specific multicast trees, and its own procedures for enabling a router to be added to or removed from a particular multicast tree. For IR P-tunnels, on the other hand, there is no prior specification for setting up and maintaining the P2MP trees; the procedures and protocol elements used for setting up and maintaining the P2MP trees are specified in the MVPN specifications themselves, and all the signaling/setup is done by using the BGP Auto-Discovery (A-D) routes that are defined in [RFC6514]. (The unicast tunnels used to transmit multicast data from one node to another in an IR P-tunnel may of course have their own setup and maintenance protocols, e.g., [RFC5036], [RFC3209].)
除了IR之外，MVPN规范支持的P隧道技术是先前存在的IP多播或MPLS多播技术。每一种这样的技术都有自己的一组规范、自己的设置和维护协议、自己的用于识别特定多播树的语法，以及自己的用于使路由器能够添加到特定多播树或从特定多播树中移除的过程。另一方面，对于IR P-隧道，没有关于设置和维护P2MP树的事先规范；MVPN规范中规定了用于设置和维护P2MP树的程序和协议元素，所有信令/设置均通过使用[RFC6514]中定义的BGP自动发现（A-D）路由完成。（用于在IR P-隧道中从一个节点向另一个节点发送多播数据的单播隧道当然可以具有它们自己的设置和维护协议，例如，[RFC5036]、[RFC3209]。）
Since the transmission of a multicast data packet along an IR P-tunnel is done by transmitting the packet through a unicast tunnel, previous RFCs sometimes describe an IR P-tunnel as "consisting of" a set of unicast tunnels. However, that description is not quite
由于沿IR P隧道的多播数据分组的传输是通过通过单播隧道传输分组来完成的，因此先前的rfc有时将IR P隧道描述为“由”一组单播隧道组成。然而，这种描述并不完全正确
accurate. For one thing, it obscures the fact that an IR P-tunnel is really a P2MP tree, whose nodes must maintain multicast state in both the control and data planes. For another, it obscures the fact the unicast tunnels used by a particular IR P-tunnel need not be specific to that P-tunnel; a single unicast tunnel can carry the multicast traffic of many different IR P-tunnels (and can also carry unicast traffic as well).
精确的一方面，它掩盖了一个事实，即irp-tunnel实际上是一个P2MP树，其节点必须在控制平面和数据平面上保持多播状态。另一方面，它掩盖了特定IR P-隧道使用的单播隧道不需要特定于该P-隧道的事实；单个单播隧道可以承载许多不同IR P隧道的多播流量（也可以承载单播流量）。
In this document, we provide a clearer and more explicit conceptual model for IR P-tunnels, clarifying the relationship between an IR P-tunnel and the unicast tunnels that are used for data transmission along the IR P-tunnel.
在本文中，我们为IR P隧道提供了一个更清晰、更明确的概念模型，澄清了IR P隧道和用于沿IR P隧道进行数据传输的单播隧道之间的关系。
Section 5 of [RFC6514] defines a BGP Path Attribute known as the "PMSI (Provider Multicast Service Interface) Tunnel attribute" (PTA). This attribute contains a field known as the "Tunnel Identifier" field. For most P-tunnel technologies, the PTA's "Tunnel Identifier" field is used to identify a P-tunnel (i.e., to identify a P2MP or MP2MP tree). However, when IR P-tunnels are used, the PTA "Tunnel Identifier" field does not actually identify an IR P-tunnel. In some cases, it identifies one of the P-tunnel's constituent unicast tunnels; in other cases, it is not used to identify a tunnel at all. In this document, we provide an explicit specification for how IR P-tunnels are actually identified.
[RFC6514]的第5节定义了BGP路径属性，称为“PMSI（提供商多播服务接口）隧道属性”（PTA）。此属性包含一个称为“隧道标识符”字段的字段。对于大多数P隧道技术，PTA的“隧道标识符”字段用于识别P隧道（即，识别P2MP或MP2MP树）。然而，当使用IR P隧道时，PTA“隧道标识符”字段实际上并不识别IR P隧道。在某些情况下，它识别P隧道的一个组成单播隧道；在其他情况下，它根本不用于识别隧道。在本文档中，我们提供了一个关于如何实际识别IR P隧道的明确规范。
Some of the MVPN specifications specify procedures that require a PE router to join the P-tunnel that has been identified in a particular MVPN route. However, up to now, there has not been an explicit specification of how to identify an IR P-tunnel, of how a router joins such a P-tunnel, or of how a router prunes itself from such a P-tunnel. In this document, we make these procedures more explicit.
一些MVPN规范规定了要求PE路由器加入已在特定MVPN路由中识别的P隧道的过程。然而，到目前为止，还没有关于如何识别IR P隧道、路由器如何加入这样的P隧道或路由器如何从这样的P隧道修剪自身的明确规范。在本文件中，我们将使这些程序更加明确。
[RFC6514] does provide a method for binding an MPLS label to a P-tunnel, but does not discuss the label allocation policies that are needed for correct operation when the P-tunnel is an IR P-tunnel. Those policies are discussed in this document.
[RFC6514]确实提供了将MPLS标签绑定到P隧道的方法，但没有讨论当P隧道是IR P隧道时正确操作所需的标签分配策略。本文件将讨论这些政策。
This document does not provide any new protocol elements or any fundamentally new procedures; its purpose is to make explicit just how a router is to use the protocol elements and procedures of [RFC6513] and [RFC6514] to identify an IR P-tunnel, to join an IR P-tunnel, and to prune itself from an IR P-tunnel.
本文件未提供任何新的协议要素或任何全新的程序；其目的是明确说明路由器如何使用[RFC6513]和[RFC6514]中的协议元素和过程来识别IR P隧道、加入IR P隧道以及从IR P隧道中删除自身。
This document also discusses the MPLS label allocation policies that need to be supported when binding MPLS labels to IR P-tunnels, and the timer policies that need to be supported when switching a customer multicast flow from one IR P-tunnel to another. These are procedures that are not clearly specified in [RFC6513] or [RFC6514].
本文档还讨论了将MPLS标签绑定到IR P隧道时需要支持的MPLS标签分配策略，以及将客户多播流从一个IR P隧道切换到另一个IR P隧道时需要支持的计时器策略。这些程序在[RFC6513]或[RFC6514]中没有明确规定。
As the material in this document must be understood in order to properly implement IR P-tunnels, this document updates [RFC6513] and [RFC6514].
为了正确实施IR P-tunnels，必须理解本文件中的材料，因此本文件更新了[RFC6513]和[RFC6514]。
This document also discusses the application of "seamless multicast" [RFC7524] and "extranet" [RFC7900] procedures to IR P-tunnels.
本文档还讨论了“无缝多播”[RFC7524]和“外联网”[RFC7900]过程在IR P-tunnels中的应用。
This document does not discuss the use of IR P-tunnels to support a VPN customer's use of Bidirectional Protocol Independent Multicast (BIDIR-PIM). [RFC7740] explains how to adapt the procedures of [RFC6513], [RFC6514], and [RFC7582] so that a customer's use of BIDIR-PIM can be supported by IR P-tunnels.
本文档不讨论如何使用IR P隧道来支持VPN客户使用双向协议独立多播（BIDIR-PIM）。[RFC7740]解释了如何调整[RFC6513]、[RFC6514]和[RFC7582]的程序，以便IR P-tunnels支持客户使用BIDIR-PIM。
In the event of any conflict between this document and either [RFC6513] or [RFC6514], this document takes precedence.
如果本文件与[RFC6513]或[RFC6514]之间存在任何冲突，则以本文件为准。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when and only when appearing in all capital letters, are to be interpreted as described in [RFC2119].
当且仅当出现在所有大写字母中时，关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An IR P-tunnel is a P2MP tree. Its nodes are BGP speakers that support the MVPN procedures of [RFC6514] and related RFCs. In general, the nodes of an IR P-tunnel are either Provider Edge (PE) routers, Autonomous System Border Routers (ASBRs), or (if [RFC7524] is supported) Area Border Routers (ABRs). (MVPN procedures are sometimes used to support non-MVPN, or "global table" multicast; one way of doing this is defined in [RFC7524]. Another way is defined in [RFC7716]. In such cases, IR P-tunnels can be used outside the context of MVPN.)
IR P-隧道是P2MP树。其节点为BGP扬声器，支持[RFC6514]和相关RFC的MVPN程序。通常，IR P隧道的节点是提供商边缘（PE）路由器、自治系统边界路由器（asbr）或（如果支持[RFC7524]）区域边界路由器（abr）。（MVPN过程有时用于支持非MVPN或“全局表”多播；一种方法在[RFC7524]中定义。另一种方法在[RFC7716]中定义。在这种情况下，可以在MVPN上下文之外使用IR P隧道。）
MVPN P-tunnels may be either "segmented" or "non-segmented" (as these terms are defined in [RFC6513] and [RFC6514]).
MVPN P-隧道可以是“分段”或“非分段”（这些术语在[RFC6513]和[RFC6514]中定义）。
A "non-segmented" IR P-tunnel is a two-level P2MP tree, consisting only of a root node and a set of nodes that are children of the root node. When used in an MVPN context, the root is an ingress PE, and the child nodes of the root are the egress PEs.
“非分段”IR P-tunnel是一个两级P2MP树，仅由一个根节点和一组作为根节点子节点的节点组成。在MVPN上下文中使用时，根节点是入口PE，根节点的子节点是出口PE。
In a segmented P-tunnel, IR may be used for some or all of the segments. If a particular segment of a segmented P-tunnel uses IR, then the root of that segment may have child nodes that are ABRs or ASBRs, rather than egress PEs.
在分段P型隧道中，IR可用于部分或全部管段。如果分段P隧道的特定段使用IR，则该段的根可能具有子节点，即abr或asbr，而不是出口PEs。
As with any type of P2MP tree, each node of an IR P-tunnel holds "multicast state" for the P-tunnel. That is, each node knows the identity of its parent node on the tree, and each node knows the identities of its child nodes on the tree. In the MVPN specs, the "parent" node is also known as the "Upstream Multicast Hop" or "UMH". Note that the UMH may be a PE, an ASBR, or (if procedures from [RFC7524] are being used) an ABR. (In [RFC7524], the term "upstream node" is used instead of "UMH".)
与任何类型的P2MP树一样，IR P-tunnel的每个节点都保持P-tunnel的“多播状态”。也就是说，每个节点知道其在树上的父节点的标识，每个节点知道其在树上的子节点的标识。在MVPN规范中，“父”节点也称为“上游多播跃点”或“UMH”。注意，UMH可以是PE、ASBR或（如果使用[RFC7524]中的程序）ABR。（在[RFC7524]中，使用术语“上游节点”代替“UMH”。）
What distinguishes an IR P-tunnel from any other kind of P2MP tree is the method by which a data packet is transmitted from a parent node to a child node. To transmit a multicast data packet from a parent node to a child node along a particular IR P-tunnel, the parent node does the following:
IR P-tunnel与任何其他类型的P2MP树的区别在于数据包从父节点传输到子节点的方法。要沿特定IR P隧道将组播数据包从父节点发送到子节点，父节点执行以下操作：
o It labels the packet with a label (call it a "P-tunnel label") that the child node has assigned to that P-tunnel.
o 它使用子节点分配给该P隧道的标签（称之为“P隧道标签”）标记数据包。
o It then places the packet in a unicast encapsulation and unicasts the packet to the child node. That is, the parent node sends the packet through a unicast tunnel to a particular child node. This unicast tunnel need not be specially created to be part of the IR P-tunnel; it can be any P2P or MP2P unicast tunnel that will get the packets from the parent node to the child node. A single such unicast tunnel may be carrying multicast data packets of several different P2MP trees and may also be carrying unicast data packets.
o 然后，它将数据包放入单播封装中，并将数据包单播到子节点。也就是说，父节点通过单播隧道将分组发送到特定的子节点。该单播隧道不需要专门创建为IR P隧道的一部分；它可以是任何P2P或MP2P单播隧道，将数据包从父节点传输到子节点。单个这样的单播隧道可以承载多个不同P2MP树的多播数据分组，并且还可以承载单播数据分组。
The parent node repeats this process for each child node, creating one copy for each child node, and sending each copy through a unicast tunnel to corresponding child node. It does not use Layer 2 multicast, IP multicast, or MPLS multicast to transmit packets to its child nodes. As a result, multiple copies of each packet may be sent out a single interface; this may happen, e.g., if that interface is the next-hop interface, according to unicast routing, from the parent node to several of the child nodes.
父节点对每个子节点重复此过程，为每个子节点创建一个副本，并通过单播隧道将每个副本发送到相应的子节点。它不使用第2层多播、IP多播或MPLS多播将数据包传输到其子节点。结果，每个分组的多个副本可以通过单个接口发送出去；这可能发生，例如，如果该接口是下一跳接口，则根据单播路由，从父节点到多个子节点。
Since data traveling along an IR P-tunnel is always unicast from parent node to child node, it can be convenient to think of an IR P-tunnel as a P2MP tree whose arcs are unicast tunnels. However, it is important to understand that the unicast tunnels need not be specific to any particular IR P-tunnel. If R1 is the parent node of R2 on two different IR P-tunnels, a single unicast tunnel from R1 to R2 may be used to carry data along both IR P-tunnels. All that is required is that when the data packets arrive at R2, R2 will see the "P-tunnel label" at the top of the packets' label stack; R2's further
由于沿IR P隧道传输的数据始终是从父节点到子节点的单播数据，因此可以方便地将IR P隧道视为其弧为单播隧道的P2MP树。然而，重要的是要理解单播隧道不需要特定于任何特定的IR P隧道。如果R1是两个不同IR P隧道上R2的父节点，则可以使用从R1到R2的单个单播隧道沿两个IR P隧道传送数据。所需要的是，当数据包到达R2时，R2将在包的标签堆栈顶部看到“P隧道标签”；R2的进一步
processing of the packets will depend upon that label. Note that the same unicast tunnel between R1 and R2 may also be carrying unicast data packets.
数据包的处理将取决于该标签。注意，R1和R2之间的相同单播隧道也可能承载单播数据分组。
Typically, the unicast tunnels are the LSPs that already exist to carry unicast traffic; either MP2P LSPs created by the Label Distribution Protocol (LDP) [RFC5036] or P2P LSPs created by Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3209]. However, any other kind of unicast tunnel may be used. A unicast tunnel may have an arbitrary number of intermediate routers; those routers do not maintain any multicast state for the IR P-tunnel and, in general, are not even aware of its existence.
通常，单播隧道是已经存在以承载单播业务的lsp；由标签分发协议（LDP）[RFC5036]创建的MP2P LSP或由资源预留协议-流量工程（RSVP-TE）[RFC3209]创建的P2P LSP。然而，可以使用任何其他类型的单播隧道。单播隧道可以具有任意数量的中间路由器；这些路由器不维护IR P隧道的任何多播状态，并且通常甚至不知道它的存在。
As with all other P-tunnel types, an IR P-tunnel may be used to instantiate either an Inclusive PMSI (I-PMSI) or a Selective PMSI (S-PMSI). See Section 3.2 of [RFC6513] for an explanation of those concepts.
与所有其他P隧道类型一样，IR P隧道可用于实例化包含性PMSI（I-PMSI）或选择性PMSI（S-PMSI）。有关这些概念的解释，请参见[RFC6513]第3.2节。
There are four MVPN BGP route types in which P-tunnels can be identified: Intra-AS I-PMSI A-D routes, Inter-AS I-PMSI A-D routes, S-PMSI A-D routes, and Leaf A-D routes. (These route types are all defined in [RFC6514]).
有四种MVPN BGP路由类型可以识别P隧道：内部AS I-PMSI A-D路由、内部AS I-PMSI A-D路由、S-PMSI A-D路由和叶A-D路由。（这些路线类型均在[RFC6514]中定义）。
Whenever it is necessary to identify a P-tunnel in a route of one of these types, a "PMSI Tunnel Attribute" (PTA) is added to the route. As defined in Section 5 of [RFC6514], the PTA contains four fields: Tunnel Type, MPLS Label, Tunnel Identifier, and Flags. [RFC6514] defines only one bit in the Flags field, the Leaf Information Required bit.
当需要在这些类型之一的路线中识别P隧道时，将向路线添加“PMSI隧道属性”（PTA）。如[RFC6514]第5节所定义，PTA包含四个字段：隧道类型、MPLS标签、隧道标识符和标志。[RFC6514]在标志字段中仅定义一位，即所需的叶信息位。
If a route identifies an IR P-tunnel, the Tunnel Type field of its PTA is set to the value 6, meaning "Ingress Replication".
如果路由识别IR P隧道，则其PTA的隧道类型字段设置为值6，表示“入口复制”。
Most types of P-tunnel are associated with specific protocols that are used to set up and maintain tunnels of that type. For example, if the Tunnel Type field is set to 2, meaning "mLDP P2MP LSP", the associated setup protocol is Multipoint LDP (mLDP) [RFC6388]. The associated setup protocol always has a method of identifying the tunnels that it sets up. For example, mLDP uses an FEC element (Forwarding Equivalence Class element) to identify a tree. If the Tunnel Type field is set to 3, meaning "PIM-SSM Tree", where "SSM" stands for Source-Specific Multicast, the associated setup protocol is PIM, and "(S,G)" is used to identify the tree. In these cases, the Tunnel Identifier field of the PTA carries a tree identifier as defined by the setup protocol used for the particular tunnel type.
大多数类型的P-tunnel都与用于设置和维护该类型隧道的特定协议相关联。例如，如果隧道类型字段设置为2，表示“mLDP P2MP LSP”，则相关的设置协议为多点LDP（mLDP）[RFC6388]。关联的设置协议始终具有一种识别其设置的隧道的方法。例如，mLDP使用FEC元素（转发等价类元素）来标识树。如果隧道类型字段设置为3，表示“PIM-SSM树”，其中“SSM”表示特定于源的多播，则相关的设置协议为PIM，“S，G”用于标识树。在这些情况下，PTA的隧道标识符字段携带由用于特定隧道类型的设置协议定义的树标识符。
IR P-tunnels, on the other hand, are entirely setup and maintained by the use of BGP A-D routes and are not associated with any other setup protocol. (The unicast tunnels used to transmit multicast data along an IR P-tunnel may have their own setup and maintenance protocols, of course.) The means of identifying a P-tunnel is very different for IR P-tunnels than for other types of P-tunnel:
另一方面，IR P隧道完全通过使用BGP A-D路由进行设置和维护，并且不与任何其他设置协议相关联。（当然，用于沿IR P-隧道传输多播数据的单播隧道可能有其自己的设置和维护协议。）对于IR P-隧道，识别P-隧道的方法与其他类型的P-隧道非常不同：
When an IR P-tunnel is identified in an S-PMSI A-D route, an Intra-AS I-PMSI A-D route, or an Inter-AS I-PMSI A-D route (we will refer to these three route types as "advertising A-D routes"), its identifier is hereby defined to be the NLRI (Network Layer Reachability Information) of that route. See Sections 4.1, 4.2, and 4.3 of [RFC6514] for the specification of these NLRIs. Note that the IR P-tunnel identifier includes the Route Type and Length fields (see Section 4 of [RFC6514]) of the NLRI.
当在S-PMSI A-D路由、内部AS I-PMSI A-D路由或内部AS I-PMSI A-D路由（我们将这三种路由类型称为“广告A-D路由”）中识别IR P隧道时，其标识符在此定义为该路由的NLRI（网络层可达性信息）。有关这些NLRI的规范，请参见[RFC6514]第4.1、4.2和4.3节。注意，IR P隧道标识符包括NLRI的路由类型和长度字段（见[RFC6514]第4节）。
To reiterate:
重申：
The identifier of the IR P-tunnel does not appear in the PTA at all; the Tunnel Identifier field of the PTA does not contain the identifier of the IR P-tunnel.
红外P隧道的标识符根本不出现在PTA中；PTA的隧道标识符字段不包含IR P隧道的标识符。
Rather, the identifier of the IR P-tunnel appears in the Network Layer Reachability Information (NLRI) field of the A-D routes that are used to advertise and to setup the IR P-tunnel.
相反，IR P隧道的标识符出现在用于广告和设置IR P隧道的A-D路由的网络层可达性信息（NLRI）字段中。
Note that an advertising A-D route is considered to identify an IR P-tunnel only if it carries a PTA whose Tunnel Type field is set to "IR".
请注意，仅当广告A-D路线承载的PTA的隧道类型字段设置为“IR”时，才会将其视为识别IR P隧道。
When an IR P-tunnel is identified in an S-PMSI A-D route or in an Inter-AS I-PMSI A-D route, the Leaf Information Required bit of the Flags field of the PTA MUST be set.
当在S-PMSI A-D路由或在Inter-AS I-PMSI A-D路由中识别IR P隧道时，必须设置PTA的Flags字段的Leaf Information Required位。
In an advertising A-D route:
在广告A-D路线中：
o If the Leaf Information Required bit of the Flags field of the PTA is set, then the Tunnel Identifier field of the PTA has no significance whatsoever and MUST be ignored upon reception.
o 如果设置了PTA的Flags字段的Leaf Information Required位，则PTA的Tunnel Identifier字段没有任何意义，必须在接收时忽略。
Note that, per RFC 6514, the length of the Tunnel Identifier field of the PTA is variable and is inferred from the length of the PTA. Even when this field is of no significance, its length MUST be the length of an IP address in the address space of the SP's backbone, as specified in Section 4.2 of [RFC6515]. In this case, it is RECOMMENDED that it be set to a routable address of the router that constructed the PTA. (While it might make more sense to
注意，根据RFC 6514，PTA的隧道标识符字段的长度是可变的，并且是从PTA的长度推断出来的。即使该字段不重要，其长度也必须是SP主干地址空间中IP地址的长度，如[RFC6515]第4.2节所述。在这种情况下，建议将其设置为构成PTA的路由器的可路由地址。（虽然
allow or even require the field to be omitted entirely, that might raise issues of backwards compatibility with implementations that were designed prior to the publication of this document.)
允许甚至要求完全省略该字段，这可能会引起与本文档发布之前设计的实现的向后兼容性问题。）
o If the Leaf Information Required bit is not set, the Tunnel Identifier field of the PTA does have significance, but it does not identify the IR P-tunnel. The use of the PTA's Tunnel Identifier field in this case is discussed in Section 5 of this document.
o 如果未设置所需叶信息位，则PTA的隧道标识符字段具有重要意义，但它不标识IR P-隧道。本文件第5节讨论了在这种情况下PTA隧道标识符字段的使用。
Note that according to the above definition, there is no way for two different advertising A-D routes (i.e., two advertising A-D routes with different NLRIs) to advertise the same IR P-tunnel. In the terminology of [RFC6513], an IR P-tunnel can instantiate only a single PMSI. If an ingress PE, for example, wants to bind two customer multicast flows to a single IR P-tunnel, it must advertise that IR P-tunnel either in an I-PMSI A-D route or in an S-PMSI A-D route whose NLRI contains wildcards [RFC6625].
注意，根据上述定义，两个不同的广告A-D路由（即，具有不同nlri的两个广告A-D路由）无法广告相同的IR P-tunnel。在[RFC6513]的术语中，IR P隧道只能实例化单个PMSI。例如，如果入口PE想要将两个客户多播流绑定到单个IR P隧道，则它必须在I-PMSI a-D路由或NLRI包含通配符的S-PMSI a-D路由中通告该IR P隧道[RFC6625]。
When an IR P-tunnel is identified in a Leaf A-D route, its identifier is the Route Key field of the route's NLRI. See Section 4.4 of [RFC6514].
当在叶a-D路由中标识IR P隧道时，其标识符是该路由的NLRI的路由密钥字段。见[RFC6514]第4.4节。
A Leaf A-D route is considered to identify an IR P-tunnel only if it carries a PTA whose Tunnel Type field is set to "IR". In this type of route, the Tunnel Identifier field of the PTA does have significance, but it does not identify the IR P-tunnel. The use of the PTA's Tunnel Identifier field in this case is discussed in Section 5.
只有当叶A-D路由携带隧道类型字段设置为“IR”的PTA时，才认为叶A-D路由识别IR P隧道。在这种类型的路线中，PTA的隧道标识符字段具有重要意义，但它不能识别IR P隧道。第5节讨论了在这种情况下PTA隧道标识符字段的使用。
The procedures for joining an IR P-tunnel depend upon whether the P-tunnel has been previously advertised, and, if so, upon how the P-tunnel was advertised. Note that joining an unadvertised IR P-tunnel is only possible when using the "global table multicast" procedures of [RFC7524].
加入IR P-隧道的程序取决于P-隧道之前是否已公布，如果已公布，则取决于P-隧道如何公布。请注意，只有在使用[RFC7524]的“全局表多播”过程时，才能加入未经广告的IR P隧道。
The procedures in this section apply when the IR P-tunnel to be joined has been advertised in an S-PMSI A-D route, an Inter-AS I-PMSI A-D route, or an Intra-AS I-PMSI A-D route.
当在S-PMSI A-D路由、内部AS-PMSI A-D路由或内部AS-PMSI A-D路由中公布要加入的IR P隧道时，本节中的程序适用。
The procedures for joining an advertised IR P-tunnel depend upon whether the A-D route that advertises the IR P-tunnel has the Leaf Information Required bit set in its PTA.
加入播发的IR P隧道的过程取决于播发IR P隧道的A-D路由是否在其PTA中设置了所需的叶信息比特。
The procedures in this section apply when the P-tunnel to be joined has been advertised in a route whose PTA has the Leaf Information Required bit set.
本节中的程序适用于在PTA具有所需叶信息位设置的路由中通告要连接的P隧道的情况。
The router joining a particular IR P-tunnel must determine its UMH for that P-tunnel. If the route that advertised the IR P-tunnel contains a P2MP Segmented Next Hop Extended Community, the UMH is determined from the value of this community (see [RFC7524]). Otherwise, the UMH is determined from the route's next hop (see [RFC6514]).
加入特定IR P隧道的路由器必须确定该P隧道的UMH。如果公布IR P隧道的路由包含P2MP分段下一跳扩展社区，则UMH由该社区的值确定（参见[RFC7524]）。否则，UMH由路由的下一跳决定（参见[RFC6514]）。
Once the UMH is determined, the router joining the IR P-tunnel originates a Leaf A-D route. The NLRI of the Leaf A-D route is formed following the procedures of [RFC6514]. As a result, the NLRI of the Leaf A-D route will contain the IR P-tunnel identifier defined in Section 3 above as its "route key". The UMH MUST be identified by attaching an "IP-address-specific Route Target" (or an "IPv6-address-specific Route Target") to the Leaf A-D route. The IP address of the UMH appears in the Global Administrator field of the Route Target (RT). Details can be found in [RFC6514] and [RFC7524].
一旦UMH被确定，加入IR P隧道的路由器发起叶a-D路由。叶A-D路线的NLRI按照[RFC6514]的程序形成。因此，叶a-D路由的NLRI将包含上文第3节中定义的IR P隧道标识符作为其“路由密钥”。必须通过将“IP地址特定的路由目标”（或“IPv6地址特定的路由目标”）附加到叶A-D路由来识别UMH。UMH的IP地址出现在路由目标（RT）的全局管理员字段中。有关详细信息，请参见[RFC6514]和[RFC7524]。
The Leaf A-D route MUST also contain a PTA whose fields are set as follows:
叶A-D路线还必须包含PTA，其字段设置如下：
o The Tunnel Type field is set to "IR".
o 隧道类型字段设置为“IR”。
o The Tunnel Identifier field is set as described in Section 5 of this document. (Note that this field does not contain the IR P-tunnel Identifier that is defined in Section 3.)
o 隧道标识符字段的设置如本文件第5节所述。（请注意，此字段不包含第3节中定义的IR P隧道标识符。）
o The MPLS Label field is set to a non-zero value. This is the "P-tunnel label". The value must be chosen so as to satisfy various constraints, as discussed in Section 7 this document.
o MPLS标签字段设置为非零值。这是“P-隧道标签”。如本文件第7节所述，必须选择该值以满足各种约束条件。
The procedures in this section apply when the IR P-tunnel to be joined has been advertised in a route whose PTA does not have the Leaf Information Required bit set. This can only be the case if the IR P-tunnel was advertised in an Intra-AS I-PMSI A-D route.
本节中的程序适用于在PTA未设置所需叶信息位的路由中公布要加入的IR P隧道的情况。仅当IR P隧道在内部AS I-PMSI A-D路由中进行广告时，才会出现这种情况。
If an IR P-tunnel is advertised in the Intra-AS I-PMSI A-D routes originated by the PE routers of a given MVPN, the Intra-AS I-PMSI can be thought of as being instantiated by a set of IR P-tunnels. Each PE is the root of one such IR P-tunnel, and the other PEs are
如果在由给定MVPN的PE路由器发起的内部AS I-PMSI A-D路由中通告IR P隧道，则可以认为内部AS I-PMSI由一组IR P隧道实例化。每个PE是一个这样的IR P隧道的根，其他PE是
children of the root. A PE simultaneously joins all these P-tunnels by originating (if it hasn't already done so) an Intra-AS I-PMSI A-D route with a PTA whose fields are set as follows:
根的孩子。PE通过发起（如果尚未这样做）AS内I-PMSI A-D路由和PTA（其字段设置如下）同时加入所有这些P隧道：
o The Tunnel Type field is set to "IR".
o 隧道类型字段设置为“IR”。
o The Tunnel Identifier field is set as described in Section 5 of this document. (Note that this field does not contain the IR P-tunnel identifier that is defined in Section 3.)
o 隧道标识符字段的设置如本文件第5节所述。（请注意，此字段不包含第3节中定义的IR P隧道标识符。）
o The MPLS Label field MUST be set to a non-zero value. This label value will be used by the child node to associate a received packet with the I-PMSI of a particular MVPN. The MPLS label allocation policy must be such as to ensure that the binding from label to I-PMSI is one to one.
o MPLS标签字段必须设置为非零值。子节点将使用该标签值将接收到的数据包与特定MVPN的I-PMSI相关联。MPLS标签分配策略必须确保从标签到I-PMSI的绑定是一对一的。
The NLRI and the RTs of the originated I-PMSI A-D route are set as specified in [RFC6514].
原始I-PMSI A-D路由的NLRI和RTs按照[RFC6514]中的规定进行设置。
In [RFC7524], a procedure is defined for "global table multicast", in which a P-tunnel can be joined even if the P-tunnel has not been previously advertised. See Sections 6.2.2 and 6.2.3 of [RFC7524]: "Leaf A-D Route for Global Table Multicast" and "Constructing the Rest of the Leaf A-D Route". The route key of the Leaf A-D route has the form of the "S-PMSI Route-Type Specific NLRI" (see Section 4.3 of [RFC6514]) in this case, and that should be considered to be the IR P-tunnel identifier. Note that the procedure for finding the UMH is different in this case; the UMH is the next hop of the best UMH-eligible route towards the "ingress PE". See Section 6.1 of [RFC7524], entitled "Determining the Upstream ABR/PE/ASBR (Upstream Node)".
在[RFC7524]中，为“全局表多播”定义了一个过程，在该过程中，即使P-tunnel之前没有广告，也可以加入P-tunnel。参见[RFC7524]第6.2.2节和第6.2.3节：“用于全局表多播的叶A-D路由”和“构建叶A-D路由的其余部分”。在这种情况下，叶A-D路由的路由密钥具有“S-PMSI路由类型特定NLRI”（见[RFC6514]第4.3节）的形式，应将其视为IR P隧道标识符。注意，在这种情况下，查找UMH的程序不同；UMH是朝向“入口PE”的最佳UMH合格路由的下一跳。参见[RFC7524]第6.1节，标题为“确定上游ABR/PE/ASBR（上游节点）”。
As discussed in Section 1, when the Tunnel Type field of a PTA is set to "IR", the Tunnel Identifier field of that PTA does not contain the IR P-tunnel identifier. This section specifies the procedures for setting the Tunnel Identifier field of the PTA when the Tunnel Type field of the PTA is set to "IR".
如第1节所述，当PTA的隧道类型字段设置为“IR”时，该PTA的隧道标识符字段不包含IR P隧道标识符。本节规定了当PTA的隧道类型字段设置为“IR”时，设置PTA隧道标识符字段的程序。
If the Tunnel Type field of a PTA is set to "IR", its Tunnel Identifier field is significant only when one of the following two conditions holds:
如果PTA的隧道类型字段设置为“IR”，则其隧道标识符字段仅在以下两个条件之一成立时有效：
o The PTA is carried by a Leaf A-D route, or
o PTA通过叶片a-D路线运输，或
o The Leaf Information Required bit of the Flags field of the PTA is not set.
o 未设置PTA标志字段的叶信息所需位。
If one of these conditions holds, then the Tunnel Identifier field must contain a routable IP address of the originator of the route. (See Sections 9.2.3.2.1 and 9.2.3.4.1 of [RFC6514] for the detailed specification of the contents of this field.) This address is used by the UMH to determine the unicast tunnel that it will use in order to send data, along the IR P-tunnel identified by the route key, to the originator of the Leaf A-D route.
如果其中一个条件成立，则隧道标识符字段必须包含路由发起者的可路由IP地址。（参见[RFC6514]第9.2.3.2.1节和第9.2.3.4.1节了解该字段内容的详细说明。）UMH使用该地址确定其将使用的单播隧道，以便沿着路由密钥标识的IR P隧道向叶A-D路由的发起人发送数据。
The means by which the unicast tunnel is determined from this IP address is outside the scope of this document. The means by which the unicast tunnel is set up and maintained is also outside the scope of this document.
根据该IP地址确定单播隧道的方法不在本文档的范围内。单播隧道的设置和维护方法也不在本文件的范围内。
Section 4 of [RFC6515] MUST be applied when a PTA is carried in a Leaf A-D route. It describes how to determine whether the Tunnel Identifier field carries an IPv4 or an IPv6 address.
当PTA通过Leaf a-D路线运输时，必须适用[RFC6515]第4节。它描述了如何确定隧道标识符字段是否携带IPv4或IPv6地址。
If neither of the above conditions hold, then the Tunnel Identifier field is of no significance and MUST be ignored upon reception.
如果上述两种情况均不成立，则隧道标识符字段不重要，必须在接收时忽略。
Section 9.1.1 of [RFC6513] specifies a procedure known as "Discarding Packets from the Wrong PE". When an egress PE receives a multicast data packet, this procedure requires it to determine the packet's ingress PE.
[RFC6513]第9.1.1节规定了一种称为“从错误PE丢弃数据包”的程序。当出口PE接收到多播数据包时，此过程要求它确定该包的入口PE。
In this document, we assume that when a packet has reached an egress PE via an IR P-tunnel, the egress PE will infer the identity of the packet's ingress PE by examining the packet's P-tunnel label.
在本文中，我们假设当分组通过IR P隧道到达出口PE时，出口PE将通过检查分组的P隧道标签来推断分组的入口PE的身份。
Section 7 specifies certain constraints on the way in which the P-tunnel label is allocated for a given P-tunnel. In general, if these constraints are followed, an egress PE will be able to infer the identity of a packet's ingress PE from the P-tunnel label, and hence will be able to apply the procedures of Section 9.1.1 of [RFC6513]. This method of identifying a packet's ingress PE works exactly the same when the unicast tunnels are IP tunnels as it does when the unicast tunnels are MPLS LSPs.
第7节规定了为给定P隧道分配P隧道标签的方式的某些限制。通常，如果遵循这些约束，出口PE将能够从P隧道标签推断数据包入口PE的身份，因此将能够应用[RFC6513]第9.1.1节的程序。当单播隧道为IP隧道时，这种识别数据包入口PE的方法与当单播隧道为MPLS LSP时的工作原理完全相同。
However, if the egress PE joined a particular IR P-tunnel using the procedures of Section 4.1.2, then when the egress PE receives a packet through that P-tunnel, it will not be able to infer the identity of the packet's ingress PE from the P-tunnel label, and thus will not be able to apply the procedures of Section 9.1.1 of [RFC6513].
然而，如果出口PE使用第4.1.2节中的程序加入特定IR P隧道，则当出口PE通过该P隧道接收到数据包时，它将无法从P隧道标签推断数据包入口PE的身份，因此将无法应用[RFC6513]第9.1.1节中的程序。
One might think that if a particular IR P-tunnel uses IP unicast tunnels rather than MPLS LSPs, an egress PE could identify the ingress PE by inspecting the IP source address field of the encapsulating IP header. However, there are several reasons why this procedure is not desirable:
人们可能认为，如果特定IR P隧道使用IP单播隧道而不是MPLS lsp，则出口PE可以通过检查封装IP报头的IP源地址字段来识别入口PE。然而，该程序不可取的原因有几个：
o When segmented P-tunnels are being used, the IP source address field of the encapsulating IP header might not contain the address of the ingress PE.
o 当使用分段P隧道时，封装IP头的IP源地址字段可能不包含入口PE的地址。
o Even if the IP source address field of the encapsulating IP header does identify the ingress PE, there is no guarantee that the IP source address in that header is the same as the IP address used by the ingress PE for the MVPN signaling procedures.
o 即使封装IP报头的IP源地址字段确实标识入口PE，也不能保证该报头中的IP源地址与入口PE用于MVPN信令过程的IP地址相同。
o To apply the procedures of Section 9.1.1 of [RFC6513] when extranet functionality [RFC7900] is supported, it is necessary to infer a packet's ingress VRF (Virtual Routing and Forwarding table), not merely its ingress PE. This can be inferred from the P-tunnel label (assuming that the label is allocated following the procedures of Section 7), but it cannot be inferred from the IP source address of the encapsulating IP header.
o 当支持外部网功能[RFC7900]时，为了应用[RFC6513]第9.1.1节的程序，有必要推断数据包的入口VRF（虚拟路由和转发表），而不仅仅是入口PE。这可以从P-tunnel标签推断（假设按照第7节的程序分配标签），但不能从封装IP报头的IP源地址推断。
We therefore assume in this document that if the procedures of Section 9.1.1 of [RFC6513] are to be applied to packets traveling through IR P-tunnels, those procedures will be based on the P-tunnel label, even if the IR P-tunnel is using IP unicast tunnels.
因此，我们在本文件中假设，如果[RFC6513]第9.1.1节的程序适用于通过IR P隧道的数据包，则这些程序将基于P隧道标签，即使IR P隧道使用IP单播隧道。
This means that if an egress PE joined a particular IR P-tunnel using the procedures of Section 4.1.2, duplicate prevention on that IR P-tunnel requires the use of either Single Forwarder Selection (Section 9.1.2 of [RFC6513]) or native PIM procedures (Section 9.1.3 of [RFC6513]).
这意味着，如果出口PE使用第4.1.2节中的程序连接特定IR P-隧道，则该IR P-隧道上的重复预防要求使用单一转发器选择（RFC6513第9.1.2节）或本机PIM程序（RFC6513第9.1.3节）。
When the Tunnel Type field of a PTA is set to "IR", the MPLS Label field is not always significant. It is significant only under the following conditions:
当PTA的隧道类型字段设置为“IR”时，MPLS标签字段并不总是有效的。只有在以下情况下才有意义：
1. Either the PTA is being carried in a Leaf A-D route, or
1. PTA以叶片a-D路线运输，或
2. the Leaf Information Required flag of the PTA is NOT set.
2. 未设置PTA的“需要叶信息”标志。
Note that the Leaf Information Required flag of the PTA is always set when a PTA specifying an IR P-tunnel is carried in an S-PMSI A-D route or in an Inter-AS I-PMSI A-D route; thus, the MPLS Label field of the PTA is never significant when the PTA is carried by one of these route types. The MPLS Label field is significant only when the PTA appears either in a Leaf A-D route or in an Intra-AS I-PMSI A-D route that does not have the Leaf Information Required bit set. In these cases, the MPLS label is the label that the originator of the route is assigning to the IR P-tunnel(s) identified by the route's NLRI. (That is, the MPLS label assigned in the PTA is what we have called the "P-tunnel label".)
注意，当在S-PMSI a-D路由或作为I-PMSI a-D路由的内部传送指定IR P隧道的PTA时，始终设置PTA的叶信息所需标志；因此，当PTA由这些路由类型之一承载时，PTA的MPLS标签字段永远不重要。MPLS标签字段仅当PTA出现在未设置叶信息所需位的叶a-D路由或内部AS I-PMSI a-D路由中时才有效。在这些情况下，MPLS标签是路由的发起人分配给路由的NLRI标识的IR P隧道的标签。（也就是说，在PTA中分配的MPLS标签就是我们所说的“P隧道标签”。）
In those cases where the MPLS Label field is not significant, it SHOULD be set to zero upon transmission and MUST be ignored upon reception.
在MPLS标签字段不重要的情况下，传输时应将其设置为零，接收时必须忽略。
As previously stated, when a Leaf A-D route is used to join an IR P-tunnel, the "route key" of the Leaf A-D route is the P-tunnel identifier.
如前所述，当使用叶a-D路由加入IR P隧道时，叶a-D路由的“路由密钥”是P隧道标识符。
We now define the notion of the "root of an IR P-tunnel".
现在，我们定义“IR P隧道的根”的概念。
o If the identifier of an IR P-tunnel is of the form of an S-PMSI NLRI, the "root" of the IR P-tunnel is the router identified in the Originating Router's IP Address field of that NLRI.
o 如果IR P隧道的标识符是S-PMSI NLRI的形式，则IR P隧道的“根”是在该NLRI的发起路由器的IP地址字段中标识的路由器。
o If the identifier of an IR P-tunnel is of the form specified in Section 6.2.2 of [RFC7524] ("Leaf A-D Route for Global Table Multicast"), the "root" of the IR P-tunnel is the router identified in the Ingress PE's IP Address field of that NLRI.
o 如果IR P隧道的标识符采用[RFC7524]第6.2.2节（“用于全局表多播的叶A-D路由”）中规定的形式，则IR P隧道的“根”是该NLRI入口PE的IP地址字段中标识的路由器。
o If the identifier of an IR P-tunnel is of the form of an Intra-AS I-PMSI NLRI, the "root" of the IR P-tunnel is the router identified in the Originating Router's IP Address field of that NLRI.
o 如果IR P隧道的标识符是内部AS I-PMSI NLRI的形式，则IR P隧道的“根”是在该NLRI的发起路由器的IP地址字段中标识的路由器。
o If the identifier of an IR P-tunnel is of the form of an Inter-AS I-PMSI NLRI, the "root" of the IR P-tunnel is same as the identifier of the IR P-tunnel, i.e., the combination of a Route Distinguisher (RD) and an AS.
o 如果IR P隧道的标识符是Inter-AS I-PMSI-NLRI的形式，则IR P隧道的“根”与IR P隧道的标识符相同，即路由标识符（RD）和AS的组合。
Note that if an IR P-tunnel is segmented, the root of the IR P-tunnel, by this definition, is actually the root of the entire P-tunnel, not the root of the local segment. In this case, there may be segments upstream that are not IR P-tunnels themselves. However, the egress PE is aware only of the final segment of the P-tunnel, and hence considers the P-tunnel to be an IR P-tunnel.
请注意，如果对IR P隧道进行分段，则根据此定义，IR P隧道的根实际上是整个P隧道的根，而不是局部段的根。在这种情况下，可能有上游段本身不是IR P隧道。然而，出口PE只知道P隧道的最后一段，因此认为P隧道是IR P隧道。
In order to apply the procedures of Section 9.1.1 of RFC 6513 ("Discarding Packets from Wrong PE"), the following condition MUST be met by the MPLS label allocation policy:
为了应用RFC 6513第9.1.1节（“从错误PE丢弃数据包”）的程序，MPLS标签分配策略必须满足以下条件：
Suppose an egress PE originates two Leaf A-D routes, each with a different route key in its NLRI, and each with a PTA specifying a Tunnel Type field of "IR". Thus, each of the Leaf A-D routes identifies a different IR P-tunnel. Suppose further that each of those IR P-tunnels has a different root. Then, the egress PE MUST NOT specify the same MPLS label in both PMSI Tunnel attributes.
假设出口PE发起两个叶A-D路由，每个路由在其NLRI中具有不同的路由密钥，并且每个路由具有指定隧道类型字段“IR”的PTA。因此，每个叶A-D路由识别不同的IR P隧道。进一步假设这些IR P隧道中的每一个都有不同的根。然后，出口PE不得在两个PMSI隧道属性中指定相同的MPLS标签。
That is, to apply the duplicate prevention procedures (in "Discarding Packets from Wrong PE", Section 9.1.1 of [RFC6513]), the same MPLS label MUST NOT be assigned to two IR P-tunnels that have different roots.
也就是说，为了应用重复预防程序（在[RFC6513]第9.1.1节“从错误的PE丢弃数据包”中），不得将相同的MPLS标签分配给具有不同根的两个IR P隧道。
If segmented P-tunnels are in use, the above rule is necessary but not sufficient to prevent a PE from forwarding duplicate data to the CEs. For various reasons, a given egress PE or egress ABR or egress ASBR may decide to change its parent node, on a given segmented P-tunnel, from one router to another. It does this by changing the RT of the Leaf A-D route that it originated in order to join that P-tunnel. Once the RT is changed, there may be a period of time during which the old parent node and the new parent node are both sending data of the same multicast flow. To ensure that the egress node not forward duplicate data, whenever the egress node changes the RT that it attaches to a Leaf A-D route, it MUST also change the "MPLS Label" specified in the Leaf A-D route's PTA. This allows the egress router to distinguish between packets arriving on a given P-tunnel from the old parent and packets arriving on that same P-tunnel from the new parent. At any given time, a router MUST consider itself to have only a single parent node on a given P-tunnel and MUST discard traffic that arrives on that P-tunnel from a different parent node.
如果使用分段P隧道，则上述规则是必要的，但不足以防止PE向CEs转发重复数据。出于各种原因，给定出口PE或出口ABR或出口ASBR可以决定在给定分段P隧道上将其父节点从一个路由器更改为另一个路由器。它通过改变它发起的叶A-D路径的RT来实现这一点，以便加入该P隧道。一旦RT被改变，可能存在一段时间，在此期间旧的父节点和新的父节点都在发送相同多播流的数据。为了确保出口节点不转发重复数据，每当出口节点更改其连接到叶a-D路由的RT时，它还必须更改叶a-D路由的PTA中指定的“MPLS标签”。这允许出口路由器区分从旧父级到达给定P隧道的包和从新父级到达相同P隧道的包。在任何给定的时间，路由器必须考虑自身在给定的P隧道上只有一个父节点，并且必须丢弃从不同父节点到达该P隧道的流量。
If extranet functionality [RFC7900] is not implemented in a particular egress PE, or if an egress PE is provisioned with the knowledge that extranet functionality is not needed, the PE may adopt the policy of assigning a label that is unique for the ordered triple <root, parent node, egress VRF>. This will enable the egress PE to apply the duplicate prevention procedures discussed above and to determine the VRF to which an arriving packet must be directed.
如果外部网功能[RFC7900]未在特定出口PE中实现，或者如果出口PE是在知道不需要外部网功能的情况下提供的，则PE可以采用为有序三元组<root，parent node，express VRF>分配唯一标签的策略。这将使得出口PE能够应用上面讨论的重复预防程序，并确定到达分组必须指向的VRF。
However, this policy is not sufficient to support the "Do Not Deliver Packets from the Wrong P-tunnel" procedures that are specified in Section 2.3.1 of [RFC7900]. To support those procedures, the labels specified in the PTA of Leaf A-D routes originated by a given egress PE MUST be unique for the ordered triple <root, root RD, parent node>, where the "root RD" is taken from the RD field of the IR P-tunnel identifier. (All forms of IR P-tunnel identifier contain an embedded RD field.) This policy is also sufficient for supporting non-extranet cases, but, in some cases, may result in the use of more labels than the policy of the preceding paragraph.
但是，该政策不足以支持[RFC7900]第2.3.1节中规定的“不从错误的P隧道传送数据包”程序。为了支持这些程序，由给定出口PE发起的叶A-D路由的PTA中指定的标签对于有序三元组<根，根RD，父节点>，必须是唯一的，其中“根RD”取自IR P隧道标识符的RD字段。（所有形式的IR P-tunnel标识符都包含嵌入的RD字段。）此策略也足以支持非外联网情况，但在某些情况下，可能会导致使用比上一段策略更多的标签。
When a P-tunnel is segmented, there will be "intermediate nodes", i.e., nodes that have a parent and also have children on the P-tunnel. Each intermediate node is a leaf node of an "upstream segment" and a root node of one or more "downstream segments". The intermediate node needs to set up its forwarding state so that data it receives on the upstream segment gets transmitted on the proper downstream segments.
当P-隧道分段时，将有“中间节点”，即在P-隧道上有父节点也有子节点的节点。每个中间节点是“上游段”的叶节点和一个或多个“下游段”的根节点。中间节点需要设置其转发状态，以便它在上游段上接收的数据在适当的下游段上传输。
If the upstream segment is instantiated by IR, the intermediate node will need to originate a Leaf A-D route to join that segment, and will need to allocate a downstream-assigned MPLS label to advertise in the MPLS Label field of the Leaf A-D route's PTA. Section 7.1 specifies constraints on the label allocation policy for egress PEs; this section specifies constraints on the label allocation policy for intermediate nodes.
如果上游段由IR实例化，则中间节点将需要发起叶a-D路由以加入该段，并且将需要分配下游分配的MPLS标签以在叶a-D路由的PTA的MPLS标签字段中播发。第7.1节规定了出口PEs标签分配政策的约束条件；本节指定对中间节点的标签分配策略的约束。
Suppose intermediate node N originates two Leaf A-D routes, one whose route key is K1, and one whose route key is K2, where K1 != K2. The respective PTAs of these Leaf A-D routes MUST specify distinct non-zero MPLS labels, UNLESS the following conditions all hold:
假设中间节点N发起两条叶A-D路由，一条路由密钥为K1，另一条路由密钥为K2，其中K1！=K2。这些叶A-D路由的各自PTA必须指定不同的非零MPLS标签，除非以下条件均成立：
1. N's parent node for P-tunnel K1 is the same as N's parent node for P-tunnel K2.
1. P隧道K1的N父节点与P隧道K2的N父节点相同。
2. N's forwarding state is such that any packet it receives from P-tunnel K1 is forwarded to the exact same set of downstream neighbors as any packet it receives from P-tunnel K2.
2. N的转发状态使得它从P隧道K1接收的任何分组被转发到与它从P隧道K2接收的任何分组完全相同的下游邻居集。
3. For each downstream neighbor D to which N sends the packets it receives from P-tunnels K1 and K2, N's forwarding state is such that it applies the exact same encapsulation to packets it forwards from either tunnel to D. (For example, if N uses MPLS to forward the packets to D, it pushes the exact same set of labels on packets from P-tunnel K1 as it pushes on packets from P-tunnel K2.)
3. 对于N向其发送其从P隧道K1和K2接收的分组的每个下游邻居D，N的转发状态使得其对其从任一隧道转发到D的分组应用完全相同的封装。（例如，如果N使用MPLS将数据包转发给D，则它在来自P隧道K1的数据包上推送的标签集与在来自P隧道K2的数据包上推送的标签集完全相同。）
Of course, N MAY always specify distinct non-zero labels in each of the Leaf A-D routes that it originates.
当然，N可能总是在其发起的每个叶A-D路由中指定不同的非零标签。
Note that the rules of this section apply whenever the upstream P-tunnel segment is an IR P-tunnel. These rules hold whether or not some or all of the downstream segments are other types of P-tunnels.
请注意，只要上游P型隧道段为IR P型隧道，则本节的规则适用。这些规则适用于部分或所有下游段是否为其他类型的P型隧洞。
If the P-tunnels from N to a particular downstream neighbor D are IR P-tunnels, then condition 3 above will hold with respect to D only if the following conditions all hold as well:
如果从N到特定下游邻居D的P-隧道为IR P-隧道，则仅当以下条件均成立时，上述条件3才会适用于D：
o N has received and installed a Leaf A-D route from D, whose route key is K1, and which carries an IP-address-specific RT identifying N,
o N已从D接收并安装了一个叶a-D路由，其路由密钥为K1，并带有标识N的IP地址特定RT，
o N has received and installed a Leaf A-D route from D, whose route key is K2, and which carries an IP-address-specific RT identifying N,
o N已从D接收并安装了一条叶子a-D路由，其路由密钥为K2，并携带识别N的IP地址特定RT，
o Those two Leaf A-D routes specify the same MPLS label in their respective PTAs.
o 这两个叶A-D路由在各自的PTA中指定相同的MPLS标签。
When a router joins a set of IR P-tunnels using the procedures of Section 4.1.2 of this document, the procedures of Section 9.1.1 of [RFC6513] cannot be applied, no matter what the label allocation policy is. In this case, the ingress PE is the same as the UMH, but it is not possible to assign a label uniquely to a particular ingress PE or UMH. However, the label in the MPLS Label field of the PTA MUST NOT appear in the MPLS Label field of the PTA carried by any other route originated by the same router.
当路由器使用本文件第4.1.2节中的程序加入一组IR P隧道时，无论标签分配策略是什么，都不能应用[RFC6513]第9.1.1节中的程序。在这种情况下，入口PE与UMH相同，但不可能将标签唯一地分配给特定入口PE或UMH。但是，PTA的MPLS标签字段中的标签不得出现在由同一路由器发起的任何其他路由所承载的PTA的MPLS标签字段中。
If a particular IR P-tunnel was joined via the procedures of Section 4.1.2, a router can prune itself from the P-tunnel by withdrawing the Intra-AS I-PMSI A-D route it used to join the P-tunnel. This is not usually done unless the router is removing itself entirely from a particular MVPN.
如果通过第4.1.2节的程序连接了特定的IR P隧道，路由器可以通过撤回其用于连接P隧道的内部AS I-PMSI a-D路由，从P隧道中删除自身。除非路由器完全从特定MVPN中移除自身，否则通常不会执行此操作。
The procedures in the remainder of this section apply when a router joined a particular IR P-tunnel by originating a Leaf A-D route (as described in Sections 4.1.1 or 4.2).
当路由器通过发起叶a-D路由（如第4.1.1或4.2节所述）加入特定IR P隧道时，本节剩余部分中的程序适用。
If a router no longer has a need to receive any multicast data from a given IR P-tunnel, it may prune itself from the P-tunnel by withdrawing the Leaf A-D route it used to join the tunnel. This is done, e.g., if the router no longer needs any of the flows traveling over the P-tunnel, or if all the flows the router does need are being received over other P-tunnels.
如果路由器不再需要从给定的IR P隧道接收任何多播数据，那么它可以通过撤回用于加入隧道的叶子a-D路由来从P隧道中修剪自己。例如，如果路由器不再需要通过P隧道传输的任何流，或者如果路由器确实需要的所有流都通过其他P隧道接收，则执行此操作。
A router that is attached to a particular IR P-tunnel via a particular parent node may determine that it needs to stay joined to that IR P-tunnel but via a different parent node. This can happen, for example, if there is a change in the Next Hop or the P2MP Segmented Next-Hop Extended Community of the S-PMSI A-D route in which that P-tunnel was advertised. In this case, the router changes the Route Target of the Leaf A-D route it used to join the IR P-tunnel, so that the Route Target now identifies the new parent node.
经由特定父节点连接到特定IR P-隧道的路由器可以确定它需要保持与该IR P-隧道的连接，但需要经由不同的父节点。这可能发生，例如，如果下一跳或S-PMSI a-D路由的P2MP分段下一跳扩展社区（P-tunnel在其中进行广告）发生变化。在这种情况下，路由器更改其用于加入IR P隧道的叶A-D路由的路由目标，以便路由目标现在识别新的父节点。
A parent node must notice when a child node has been pruned from a particular tree, as this will affect the parent node's multicast data state. Note that the pruning of a child node may appear to the parent node as the explicit withdrawal of a Leaf A-D route, or it may appear as a change in the Route Target of a Leaf A-D route. If the Route Target of a particular Leaf A-D route previously identified a particular parent node, but changes so that it no longer does so, the effect on the multicast state of the parent node is the same as if the Leaf A-D route had been explicitly withdrawn.
父节点必须注意何时从特定树中删除了子节点，因为这将影响父节点的多播数据状态。注意，在父节点看来，子节点的修剪可能表现为叶a-D路由的显式撤回，也可能表现为叶a-D路由的路由目标的更改。如果特定叶a-D路由的路由目标先前标识了特定父节点，但发生了更改，使其不再这样做，则对父节点的多播状态的影响与叶a-D路由已显式撤回的情况相同。
These actions are detailed in [RFC6514] and [RFC7524]. Two points of clarification are made:
这些操作在[RFC6514]和[RFC7524]中有详细说明。有两点需要澄清：
o If a router R1 receives and installs a Leaf A-D route originated by router R2, R1's multicast state is affected only if the Leaf A-D route carries an "IP-address-specific RT" (or "IPv6-address-specific RT") whose Global Administrator field identifies R1.
o 如果路由器R1接收并安装由路由器R2发起的叶a-D路由，则只有当叶a-D路由携带全局管理员字段标识R1的“IP地址特定RT”（或“IPv6地址特定RT”）时，R1的多播状态才会受到影响。
(This is as specified in [RFC6514] and [RFC7524].) If a Leaf A-D route's RT does not identify R1, but then changes so that it does identify R1, R1 must take the same actions it would take if the Leaf A-D route were newly received.
（这在[RFC6514]和[RFC7524]中有规定）如果叶a-D路由的RT没有识别R1，但随后发生了变化，从而识别R1，则R1必须采取与新收到叶a-D路由时相同的操作。
o It is possible that router R1 will receive and install a Leaf A-D route originated by router R2, where:
o 路由器R1可能会接收并安装由路由器R2发起的叶a-D路由，其中：
* the route's RT identifies R1,
* 路线的RT标识R1，
* the route's NLRI contains a route key whose first octet indicates that it is identifying a P-tunnel advertised in an S-PMSI A-D route,
* 该路由的NLRI包含一个路由密钥，其第一个八位组表示它正在识别s-PMSI a-D路由中公布的P隧道，
* R1 has neither originated nor installed any such S-PMSI A-D route.
* R1既没有发起也没有安装任何此类S-PMSI A-D路由。
If at some later time, R1 installs the corresponding S-PMSI A-D route, and the Leaf A-D route is still installed, and the Leaf A-D route's RT still identifies R1, then R1 MUST follow the same procedures it would have followed if the S-PMSI A-D route had been installed before the Leaf A-D route was installed. Implementers must not assume that events occur in the "usual" or "expected" order.
如果在稍后的某个时间，R1安装了相应的S-PMSI A-D路由，而叶A-D路由仍然安装，并且叶A-D路由的RT仍然标识R1，则R1必须遵循与安装叶A-D路由之前安装S-PMSI A-D路由相同的步骤。实现者不能假设事件以“通常”或“预期”的顺序发生。
Consider a child node that has joined a particular IR P-tunnel via a particular UMH. To do so, it will have originated a Leaf A-D route with an RT that identifies the UMH. Suppose the child node now determines (for whatever reason) that it needs to change its UMH for that P-tunnel. It does this by:
考虑通过特定UMH加入特定的IR P隧道的子节点。要做到这一点，它将发起一个具有识别UMH的RT的叶a-D路由。假设子节点现在确定（出于任何原因）需要更改该P隧道的UMH。它通过以下方式做到这一点：
o modifying the RT of the Leaf A-D route, so that the RT now identifies the new parent rather than the old one, and by
o 修改叶A-D路由的RT，以便RT现在标识新的父级而不是旧的父级，并且
o modifying the PTA of the Leaf A-D route, changing the MPLS Label field as discussed in Section 7.
o 修改叶A-D路由的PTA，如第7节所述更改MPLS标签字段。
Note that, in accordance with the procedures of [RFC6514] and of Section 4 of this document, the NLRI of the Leaf A-D route is not modified; only the RT and the PTA are changed.
注意，根据[RFC6514]和本文件第4节的程序，未修改Leaf A-D路线的NLRI；只更改RT和PTA。
It is desirable for such a "switch of UMH" to be done using a "make before break" technique, so that the old UMH does not stop transmitting packets of the given P-tunnel to the child until the new UMH has a chance to start transmitting packets of the given P-tunnel to the child. However, the control-plane operation (i.e., modifying the RT and PTA of the Leaf A-D route) does not permit the child node to first join the IR P-tunnel via the new UMH, and then later prune itself from the old UMH. Rather, a single control-plane operation has both effects.
希望使用“先通后断”技术来完成这种“UMH的切换”，以便旧的UMH不会停止向孩子发送给定P隧道的分组，直到新的UMH有机会开始向孩子发送给定P隧道的分组。然而，控制平面操作（即，修改叶A-D路由的RT和PTA）不允许子节点首先通过新的UMH加入IR P隧道，然后再从旧的UMH修剪自身。相反，单个控制平面操作具有两种效果。
Therefore, the old UMH MUST continue transmitting to the child node for a period of time after it sees the child's Leaf A-D route being withdrawn (or its RT changing to identify a different UMH). This timer (the "parent-continues" timer) SHOULD have a default value of 60 seconds and SHOULD be configurable.
因此，旧的UMH必须在看到子节点的叶a-D路由被撤回（或其RT改变以识别不同的UMH）之后的一段时间内继续向子节点发送。此计时器（“父级继续”计时器）的默认值应为60秒，并且应可配置。
By the procedures of Section 7, the child node will have advertised a different label for the IR P-tunnel to the new UMH than it had advertised to the old UMH. This allows it to distinguish the packets of that IR P-tunnel transmitted by the new UMH from packets of that IR P-tunnel transmitted by the old UMH. At any given time, the child node will accept packets of that IR P-tunnel from only one parent node and will discard packets of that IR P-tunnel that are received from the other. To achieve "make before break" functionality, the child node needs to continue to accept packets from the old UMH for a period of time. After this period, it will discard any packets from the given IR P-tunnel that it receives from the old UMH and will only accept such packets from the new UMH.
通过第7节的过程，子节点将为新UMH的IR P隧道通告不同于其向旧UMH通告的标签。这允许它区分由新UMH发送的IR P隧道的分组与由旧UMH发送的IR P隧道的分组。在任何给定时间，子节点将仅从一个父节点接受该IR P隧道的分组，并将丢弃从另一个父节点接收的该IR P隧道的分组。为了实现“先通后断”功能，子节点需要在一段时间内继续接受来自旧UMH的数据包。在此期间之后，它将丢弃从旧UMH接收的来自给定IR P隧道的任何分组，并且将仅接受来自新UMH的此类分组。
Once the child node modifies the RT of its Leaf A-D route, it MUST run a timer (the "switch-parents-delay" timer). This timer SHOULD default to 30 seconds and SHOULD be configurable. The child node MUST continue to accept packets of the given IR P-tunnel from the old UMH until the timer expires. However, once the child node receives a packet of the given IR P-tunnel from the new UMH, it MAY consider the "switch-parents-delay" timer to have expired.
一旦子节点修改了其叶A-D路由的RT，它必须运行一个计时器（“切换父节点延迟”计时器）。此计时器应默认为30秒，并且应可配置。子节点必须继续接受来自旧UMH的给定IR P隧道的数据包，直到计时器过期。然而，一旦子节点从新的UMH接收到给定的IR P隧道的分组，它可能会考虑“切换父延迟”计时器已经过期。
The "parent-continues" timer MUST be longer than the "switch-parents-delay" timer. Note that both timers are specific to a given IR P-tunnel.
“父级继续”计时器必须长于“切换父级延迟”计时器。请注意，这两个计时器都特定于给定的IR P通道。
No security considerations are raised by this document beyond those already discussed in [RFC6513] and [RFC6514].
除了[RFC6513]和[RFC6514]中已经讨论的安全注意事项外，本文件未提出其他安全注意事项。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]Rosen，E.，Ed.，和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，DOI 10.17487/RFC6513，2012年2月<http://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.
[RFC6514]Aggarwal，R.，Rosen，E.，Morin，T.，和Y.Rekhter，“MPLS/BGP IP VPN中的BGP编码和多播过程”，RFC 6514，DOI 10.17487/RFC6514，2012年2月<http://www.rfc-editor.org/info/rfc6514>.
[RFC6515] Aggarwal, R. and E. Rosen, "IPv4 and IPv6 Infrastructure Addresses in BGP Updates for Multicast VPN", RFC 6515, DOI 10.17487/RFC6515, February 2012, <http://www.rfc-editor.org/info/rfc6515>.
[RFC6515]Aggarwal，R.和E.Rosen，“多播VPN BGP更新中的IPv4和IPv6基础设施地址”，RFC 6515，DOI 10.17487/RFC6515，2012年2月<http://www.rfc-editor.org/info/rfc6515>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.“LDP规范”，RFC 5036，DOI 10.17487/RFC5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC6388] 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, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，DOI 10.17487/RFC6388，2011年11月<http://www.rfc-editor.org/info/rfc6388>.
[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, <http://www.rfc-editor.org/info/rfc6625>.
[RFC6625]Rosen，E.，Ed.，Rekhter，Y.，Ed.，Hendrickx，W.，和R.Qiu，“多播VPN自动发现路由中的通配符”，RFC 6625，DOI 10.17487/RFC6625，2012年5月<http://www.rfc-editor.org/info/rfc6625>.
[RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area Point-to-Multipoint (P2MP) Segmented Label Switched Paths (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, <http://www.rfc-editor.org/info/rfc7524>.
[RFC7524]Rekhter，Y.，Rosen，E.，Aggarwal，R.，Morin，T.，Grosclaude，I.，Leymann，N.，和S.Saad，“区域间点对多点（P2MP）分段标签交换路径（LSP）”，RFC 7524，DOI 10.17487/RFC7524，2015年5月<http://www.rfc-editor.org/info/rfc7524>.
[RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, "Multicast Virtual Private Network (MVPN): Using Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, July 2015, <http://www.rfc-editor.org/info/rfc7582>.
[RFC7582]Rosen，E.，Wijnands，IJ.，Cai，Y.，和A.Boers，“多播虚拟专用网络（MVPN）：使用双向P隧道”，RFC 7582，DOI 10.17487/RFC7582，2015年7月<http://www.rfc-editor.org/info/rfc7582>.
[RFC7716] Zhang, J., Giuliano, L., Rosen, E., Ed., Subramanian, K., and D. Pacella, "Global Table Multicast with BGP Multicast VPN (BGP-MVPN) Procedures", RFC 7716, DOI 10.17487/RFC7716, December 2015, <http://www.rfc-editor.org/info/rfc7716>.
[RFC7716]Zhang，J.，Giuliano，L.，Rosen，E.，Ed.，Subramanian，K.，和D.Pacella，“使用BGP多播VPN（BGP-MVPN）的全局表多播程序”，RFC 7716，DOI 10.17487/RFC7716，2015年12月<http://www.rfc-editor.org/info/rfc7716>.
[RFC7740] Zhang, Z., Rekhter, Y., and A. Dolganow, "Simulating Partial Mesh of Multipoint-to-Multipoint (MP2MP) Provider Tunnels with Ingress Replication", RFC 7740, DOI 10.17487/RFC7740, January 2016, <http://www.rfc-editor.org/info/rfc7740>.
[RFC7740]Zhang，Z.，Rekhter，Y.，和A.Dolganow，“使用入口复制模拟多点对多点（MP2MP）提供程序隧道的部分网格”，RFC 7740，DOI 10.17487/RFC7740，2016年1月<http://www.rfc-editor.org/info/rfc7740>.
[RFC7900] Rekhter, Y., Ed., Rosen, E., Ed., Aggarwal, R., Cai, Y., and T. Morin, "Extranet Multicast in BGP/IP MPLS VPNs", RFC 7900, DOI 10.17487/RFC7900, June 2016, <http://www.rfc-editor.org/info/rfc7900>.
[RFC7900]Rekhter，Y.，Ed.，Rosen，E.，Ed.，Aggarwal，R.，Cai，Y.，和T.Morin，“BGP/IP MPLS VPN中的外联网多播”，RFC 7900，DOI 10.17487/RFC7900，2016年6月<http://www.rfc-editor.org/info/rfc7900>.
Acknowledgments
致谢
The authors wish to thank Yakov Rekhter for his contributions to this work. We also wish to thank Huajin Jeng and Samir Saad for their contributions, and to thank Thomas Morin for pointing out (both before and after the document was written) some of the issues that needed further elaboration. We also thank Lucy Yong for her review and comments.
作者希望感谢亚科夫·雷克特对这项工作的贡献。我们还要感谢郑华津和萨阿德的贡献，并感谢托马斯·莫林（在文件编写之前和之后）指出了一些需要进一步阐述的问题。我们也感谢Lucy Yong的评论和评论。
Section 7.1 discusses the importance of having an MPLS label allocation policy that, when ingress replication is used, allows an egress PE to infer the identity of a received packet's ingress PE. This issue was first raised in earlier work by Xu Xiaohu.
第7.1节讨论了具有MPLS标签分配策略的重要性，当使用入口复制时，该策略允许出口PE推断接收到的数据包的入口PE的身份。这个问题是徐小虎在早期作品中首次提出的。
Authors' Addresses
作者地址
Eric C. Rosen (editor) Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
Eric C.Rosen（编辑）Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886
Email: erosen@juniper.net
Email: erosen@juniper.net
Karthik Subramanian Sproute Networks
Karthik-Subramanian萌芽网络
Email: karthik@sproute.com
Email: karthik@sproute.com
Zhaohui Zhang Juniper Networks, Inc. 10 Technology Park Drive Westford, Massachusetts 01886 United States of America
美国马萨诸塞州韦斯特福德科技园大道10号张昭辉Juniper Networks，Inc.01886
Email: zzhang@juniper.net
Email: zzhang@juniper.net