Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 6388 Cisco Systems, Inc.
Category: Standards Track I. Minei, Ed.
ISSN: 2070-1721 K. Kompella
Juniper Networks
B. Thomas
November 2011
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 6388 Cisco Systems, Inc.
Category: Standards Track I. Minei, Ed.
ISSN: 2070-1721 K. Kompella
Juniper Networks
B. Thomas
November 2011
Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
点对多点和多点对多点标签交换路径的标签分发协议扩展
Abstract
摘要
This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also referred to as multipoint LDP. Multipoint LDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for multipoint LSPs, for example IP multicast or support for multicast in BGP/MPLS Layer 3 Virtual Private Networks (L3VPNs). Specification of how such applications can use an LDP signaled multipoint LSP is outside the scope of this document.
本文档描述了标签分发协议（LDP）的扩展，用于在MPLS网络中设置点对多点（P2MP）和多点对多点（MP2MP）标签交换路径（LSP）。这些扩展也称为多点LDP。多点LDP构造P2MP或MP2MP LSP，无需与任何其他多播树构造协议交互或依赖任何其他多播树构造协议。描述了该解决方案的协议元素和程序，用于以接收器启动的方式构建此类lsp。多点LSP可以有多种应用，例如IP多播或支持BGP/MPLS第3层虚拟专用网络（L3VPN）中的多播。此类应用程序如何使用LDP信号多点LSP的规范不在本文件范围内。
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/rfc6388.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6388.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Terminology ................................................4
1.3. Manageability ..............................................5
2. Setting Up P2MP LSPs with LDP ...................................6
2.1. Support for P2MP LSP Setup with LDP ........................6
2.2. The P2MP FEC Element .......................................6
2.3. The LDP MP Opaque Value Element ............................8
2.3.1. The Generic LSP Identifier ..........................9
2.4. Using the P2MP FEC Element .................................9
2.4.1. Label Mapping ......................................10
2.4.2. Label Withdraw .....................................12
2.4.3. Upstream LSR Change ................................13
3. Setting up MP2MP LSPs with LDP .................................14
3.1. Support for MP2MP LSP Setup with LDP ......................14
3.2. The MP2MP Downstream and Upstream FEC Elements ............15
3.3. Using the MP2MP FEC Elements ..............................15
3.3.1. MP2MP Label Mapping ................................17
3.3.2. MP2MP Label Withdraw ...............................20
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Terminology ................................................4
1.3. Manageability ..............................................5
2. Setting Up P2MP LSPs with LDP ...................................6
2.1. Support for P2MP LSP Setup with LDP ........................6
2.2. The P2MP FEC Element .......................................6
2.3. The LDP MP Opaque Value Element ............................8
2.3.1. The Generic LSP Identifier ..........................9
2.4. Using the P2MP FEC Element .................................9
2.4.1. Label Mapping ......................................10
2.4.2. Label Withdraw .....................................12
2.4.3. Upstream LSR Change ................................13
3. Setting up MP2MP LSPs with LDP .................................14
3.1. Support for MP2MP LSP Setup with LDP ......................14
3.2. The MP2MP Downstream and Upstream FEC Elements ............15
3.3. Using the MP2MP FEC Elements ..............................15
3.3.1. MP2MP Label Mapping ................................17
3.3.2. MP2MP Label Withdraw ...............................20
3.3.3. MP2MP Upstream LSR Change ..........................21
4. Micro-Loops in MP LSPs .........................................21
5. The LDP MP Status TLV ..........................................21
5.1. The LDP MP Status Value Element ...........................22
5.2. LDP Messages Containing LDP MP Status Messages ............22
5.2.1. LDP MP Status Sent in LDP Notification Messages ....23
5.2.2. LDP MP Status TLV in Label Mapping Message .........24
6. Upstream Label Allocation on a LAN .............................24
6.1. LDP Multipoint-to-Multipoint on a LAN .....................24
6.1.1. MP2MP Downstream Forwarding ........................25
6.1.2. MP2MP Upstream Forwarding ..........................25
7. Root Node Redundancy ...........................................25
7.1. Root Node Redundancy - Procedures for P2MP LSPs ...........26
7.2. Root Node Redundancy - Procedures for MP2MP LSPs ..........26
8. Make Before Break (MBB) ........................................27
8.1. MBB Overview .............................................27
8.2. The MBB Status Code .......................................28
8.3. The MBB Capability ........................................29
8.4. The MBB Procedures ........................................29
8.4.1. Terminology ........................................29
8.4.2. Accepting Elements .................................30
8.4.3. Procedures for Upstream LSR Change .................30
8.4.4. Receiving a Label Mapping with MBB Status Code .....31
8.4.5. Receiving a Notification with MBB Status Code ......31
8.4.6. Node Operation for MP2MP LSPs ......................32
9. Typed Wildcard for mLDP FEC Element ............................32
10. Security Considerations .......................................32
11. IANA Considerations ...........................................33
12. Acknowledgments ...............................................34
13. Contributing Authors ..........................................35
14. References ....................................................37
14.1. Normative References .....................................37
14.2. Informative References ...................................37
3.3.3. MP2MP Upstream LSR Change ..........................21
4. Micro-Loops in MP LSPs .........................................21
5. The LDP MP Status TLV ..........................................21
5.1. The LDP MP Status Value Element ...........................22
5.2. LDP Messages Containing LDP MP Status Messages ............22
5.2.1. LDP MP Status Sent in LDP Notification Messages ....23
5.2.2. LDP MP Status TLV in Label Mapping Message .........24
6. Upstream Label Allocation on a LAN .............................24
6.1. LDP Multipoint-to-Multipoint on a LAN .....................24
6.1.1. MP2MP Downstream Forwarding ........................25
6.1.2. MP2MP Upstream Forwarding ..........................25
7. Root Node Redundancy ...........................................25
7.1. Root Node Redundancy - Procedures for P2MP LSPs ...........26
7.2. Root Node Redundancy - Procedures for MP2MP LSPs ..........26
8. Make Before Break (MBB) ........................................27
8.1. MBB Overview .............................................27
8.2. The MBB Status Code .......................................28
8.3. The MBB Capability ........................................29
8.4. The MBB Procedures ........................................29
8.4.1. Terminology ........................................29
8.4.2. Accepting Elements .................................30
8.4.3. Procedures for Upstream LSR Change .................30
8.4.4. Receiving a Label Mapping with MBB Status Code .....31
8.4.5. Receiving a Notification with MBB Status Code ......31
8.4.6. Node Operation for MP2MP LSPs ......................32
9. Typed Wildcard for mLDP FEC Element ............................32
10. Security Considerations .......................................32
11. IANA Considerations ...........................................33
12. Acknowledgments ...............................................34
13. Contributing Authors ..........................................35
14. References ....................................................37
14.1. Normative References .....................................37
14.2. Informative References ...................................37
The LDP protocol is described in [RFC5036]. It defines mechanisms for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs in the network. This document describes extensions to LDP for setting up point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) LSPs. These are collectively referred to as multipoint LSPs (MP LSPs). A P2MP LSP allows traffic from a single root (or ingress) node to be delivered to a number of leaf (or egress) nodes. An MP2MP LSP allows traffic from multiple ingress nodes to be delivered to multiple egress nodes. Only a single copy of the packet will be sent to an LDP neighbor traversed by the MP LSP. This is accomplished without the use of a multicast protocol in the network. There can be
[RFC5036]中描述了LDP协议。它定义了在网络中设置点对点（P2P）和多点对点（MP2P）LSP的机制。本文档描述了LDP的扩展，用于设置点对多点（P2MP）和多点对多点（MP2MP）LSP。这些统称为多点LSP（MP LSP）。P2MP LSP允许将来自单个根（或入口）节点的流量传送到多个叶（或出口）节点。MP2MP LSP允许将来自多个入口节点的流量传送到多个出口节点。只有一个数据包副本将被发送到MP LSP所穿越的LDP邻居。这是在网络中不使用多播协议的情况下实现的。可能有
several MP LSPs rooted at a given ingress node, each with its own identifier.
多个MP LSP以给定入口节点为根，每个都有自己的标识符。
The solution assumes that the leaf nodes of the MP LSP know the root node and identifier of the MP LSP to which they belong. The mechanisms for the distribution of this information are outside the scope of this document. The specification of how an application can use an MP LSP signaled by LDP is also outside the scope of this document.
该解决方案假定MP LSP的叶节点知道它们所属的MP LSP的根节点和标识符。分发这些信息的机制不在本文件的范围之内。应用程序如何使用LDP发出信号的MP LSP的规范也不在本文档的范围之内。
Related documents that may be of interest include [RFC6348], [L3VPN-MCAST], and [RFC4875].
可能感兴趣的相关文件包括[RFC6348]、[L3VPN-MCAST]和[RFC4875]。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
All new fields shown as "reserved" in this document MUST be set to zero on transmission and MUST be ignored on receipt.
此文档中显示为“保留”的所有新字段在传输时必须设置为零，并且在接收时必须忽略。
Some of the following terminology is taken from [RFC6348].
以下一些术语摘自[RFC6348]。
mLDP: Multipoint extensions for LDP.
mLDP：LDP的多点扩展。
P2P LSP: An LSP that has one Ingress LSR and one Egress LSR.
P2P LSP：具有一个入口LSR和一个出口LSR的LSP。
P2MP LSP: An LSP that has one Ingress LSR and one or more Egress LSRs.
P2MP LSP：具有一个入口LSR和一个或多个出口LSR的LSP。
MP2P LSP: An LSP that has one or more Ingress LSRs and one unique Egress LSR.
MP2P LSP：具有一个或多个入口LSR和一个唯一出口LSR的LSP。
MP2MP LSP: An LSP with a distinguished root node that connects a set of nodes, such that traffic sent by any node in the LSP is delivered to all others.
MP2MP LSP：具有可分辨根节点的LSP，它连接一组节点，这样LSP中任何节点发送的流量都会传递给所有其他节点。
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
MP LSP：多点LSP，P2MP或MP2MP LSP。
Ingress LSR: An Ingress LSR for a particular LSP is an LSR that can send a data packet along the LSP. MP2MP LSPs can have multiple Ingress LSRs, P2MP LSPs have just one, and that node is often referred to as the "root node".
入口LSR：特定LSP的入口LSR是可以沿LSP发送数据包的LSR。MP2MP LSP可以有多个入口LSR，P2MP LSP只有一个入口LSR，该节点通常被称为“根节点”。
Egress LSR: An Egress LSR for a particular LSP is an LSR that can remove a data packet from that LSP for further processing. P2P and MP2P LSPs have only a single egress node, but P2MP and MP2MP LSPs can have multiple egress nodes.
出口LSR：特定LSP的出口LSR是可以从该LSP移除数据包以进行进一步处理的LSR。P2P和MP2P LSP只有一个出口节点，但P2MP和MP2MP LSP可以有多个出口节点。
Transit LSR: An LSR that has reachability to the root of the MP LSP via a directly connected upstream LSR and one or more directly connected downstream LSRs.
传输LSR：通过直接连接的上游LSR和一个或多个直接连接的下游LSR可到达MP LSP根的LSR。
Bud LSR: An LSR that is an egress but also has one or more directly connected downstream LSRs.
Bud LSR：作为出口的LSR，但也有一个或多个直接连接的下游LSR。
Leaf node: A leaf node can be either an Egress or Bud LSR when referred to in the context of a P2MP LSP. In the context of an MP2MP LSP, a leaf is both Ingress and Egress for the same MP2MP LSP and can also be a Bud LSR.
叶节点：当在P2MP LSP上下文中引用时，叶节点可以是出口或芽LSR。在MP2MP LSP的上下文中，叶既是同一MP2MP LSP的入口又是出口，也可以是芽LSR。
CRC32: This contains a Cyclic Redundancy Check value of the uncompressed data in network byte order computed according to CRC-32 algorithm used in the ISO 3309 standard [ISO3309] and in Section 8.1.1.6.2 of ITU-T recommendation V.42 [ITU.V42.1994].
CRC32：包含根据ISO 3309标准[ISO3309]和ITU-T建议V.42[ITU.V42.1994]第8.1.1.6.2节中使用的CRC-32算法计算的网络字节顺序的未压缩数据的循环冗余校验值。
FEC: Forwarding Equivalence Class
转发等价类
MPLS LSRs can be modeled and managed using the MIB module defined in [RFC3813]. That MIB module is fully capable of handling the one-to-many in-segment to out-segment relationships needed to support P2MP LSPs, and no further changes are required.
可以使用[RFC3813]中定义的MIB模块对MPLS LSR进行建模和管理。该MIB模块完全能够处理支持P2MP LSP所需的一对多段内段外关系，无需进一步更改。
[RFC3815] defines managed objects for LDP. The MIB module allows the modeling and management of LDP and LDP speakers for the protocol as defined in [RFC5036]. The protocol extensions defined in this document to support P2MP in LDP may require an additional MIB module or extensions to the modules defined in [RFC3815]. This is for future study, and at the time of this writing, no interest has been expressed in this work.
[RFC3815]定义LDP的托管对象。MIB模块允许对[RFC5036]中定义的协议的LDP和LDP扬声器进行建模和管理。本文件中定义的支持LDP中P2MP的协议扩展可能需要额外的MIB模块或对[RFC3815]中定义的模块的扩展。这是为了将来的研究，在撰写本文时，还没有人对这项工作表示兴趣。
Future manageability work should pay attention to the protocol extensions defined in this document, and specifically the configurable and variable elements, along with reporting the new protocol fields that identify individual P2MP LSPs.
未来的可管理性工作应注意本文档中定义的协议扩展，特别是可配置和可变元素，以及报告标识单个P2MP LSP的新协议字段。
A P2MP LSP consists of a single root node, zero or more transit nodes, and one or more leaf nodes. Leaf nodes initiate P2MP LSP setup and tear-down. Leaf nodes also install forwarding state to deliver the traffic received on a P2MP LSP to wherever it needs to go; how this is done is outside the scope of this document. Transit nodes install MPLS forwarding state and propagate the P2MP LSP setup (and tear-down) toward the root. The root node installs forwarding state to map traffic into the P2MP LSP; how the root node determines which traffic should go over the P2MP LSP is outside the scope of this document.
P2MP LSP由单个根节点、零个或多个传输节点以及一个或多个叶节点组成。叶节点启动P2MP LSP设置并拆除。叶节点还安装转发状态，以将P2MP LSP上接收到的通信量传送到它需要去的任何地方；如何做到这一点超出了本文件的范围。传输节点安装MPLS转发状态，并将P2MP LSP设置（和拆除）传播到根节点。根节点安装转发状态，将流量映射到P2MP LSP；根节点如何确定应通过P2MP LSP的通信量超出了本文档的范围。
Support for the setup of P2MP LSPs is advertised using LDP capabilities as defined in [RFC5561]. An implementation supporting the P2MP procedures specified in this document MUST implement the procedures for Capability Parameters in Initialization messages.
使用[RFC5561]中定义的LDP功能公布对P2MP LSP设置的支持。支持本文件中规定的P2MP程序的实现必须实现初始化消息中的功能参数程序。
A new Capability Parameter TLV is defined, the P2MP Capability. Following is the format of the P2MP Capability Parameter.
定义了一个新的能力参数TLV，即P2MP能力。以下是P2MP能力参数的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| P2MP Capability (0x0508) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| P2MP Capability (0x0508) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
S: As specified in [RFC5561]
S：按照[RFC5561]中的规定
The P2MP Capability TLV MUST be advertised in the LDP Initialization message. Advertisement of the P2MP Capability indicates support of the procedures for P2MP LSP setup detailed in this document. If the peer has not advertised the corresponding capability, then label messages using the P2MP FEC Element SHOULD NOT be sent to the peer.
P2MP能力TLV必须在LDP初始化消息中公布。P2MP功能的公布表明支持本文档中详述的P2MP LSP设置程序。如果对等方未公布相应的功能，则不应向对等方发送使用P2MP FEC元素的标签消息。
For the setup of a P2MP LSP with LDP, we define one new protocol entity, the P2MP FEC Element, to be used as a FEC Element in the FEC TLV. Note that the P2MP FEC Element does not necessarily identify the traffic that must be mapped to the LSP, so from that point of view, the use of the term FEC is a misnomer. The description of the P2MP FEC Element follows.
为了使用LDP设置P2MP LSP，我们定义了一个新的协议实体，P2MP FEC元素，用作FEC TLV中的FEC元素。注意，P2MP FEC元素不一定识别必须映射到LSP的业务，因此从该角度来看，术语FEC的使用是一个误称。P2MP FEC元素的描述如下。
The P2MP FEC Element consists of the address of the root of the P2MP LSP and an opaque value. The opaque value consists of one or more LDP MP opaque value elements. The opaque value is unique within the context of the root node. The combination of (Root Node Address type, Root Node Address, Opaque Value) uniquely identifies a P2MP LSP within the MPLS network.
P2MP FEC元素由P2MP LSP根的地址和不透明值组成。不透明值由一个或多个LDP MP不透明值元素组成。不透明值在根节点的上下文中是唯一的。（根节点地址类型、根节点地址、不透明值）的组合唯一地标识MPLS网络中的P2MP LSP。
The P2MP FEC Element is encoded as follows:
P2MP FEC元素编码如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2MP Type(0x06)| Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2MP Type(0x06)| Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The type of the P2MP FEC Element is 0x06.
类型：P2MP FEC元素的类型为0x06。
Address Family: Two octet quantity containing a value from IANA's "Address Family Numbers" registry that encodes the address family for the Root LSR Address.
地址族：两个八位组数量，包含IANA“地址族编号”注册表中的一个值，该注册表对根LSR地址的地址族进行编码。
Address Length: Length of the Root LSR Address in octets.
地址长度：根LSR地址的长度（以八位字节为单位）。
Root Node Address: A host address encoded according to the Address Family field.
根节点地址：根据地址族字段编码的主机地址。
Opaque Length: The length of the opaque value, in octets.
不透明长度：不透明值的长度，以八位字节为单位。
Opaque Value: One or more MP opaque value elements, uniquely identifying the P2MP LSP in the context of the root node. This is described in the next section.
不透明值：一个或多个MP不透明值元素，在根节点的上下文中唯一标识P2MP LSP。下一节将对此进行描述。
If the Address Family is IPv4, the Address Length MUST be 4; if the Address Family is IPv6, the Address Length MUST be 16. No other Address Lengths are defined at present.
如果地址族为IPv4，则地址长度必须为4；如果地址族为IPv6，则地址长度必须为16。目前没有定义其他地址长度。
If the Address Length doesn't match the defined length for the Address Family, the receiver SHOULD abort processing the message containing the FEC Element, and send an "Unknown FEC" Notification message to its LDP peer signaling an error.
如果地址长度与为地址族定义的长度不匹配，则接收方应中止处理包含FEC元素的消息，并向其LDP对等方发送“未知FEC”通知消息，以发出错误信号。
If a FEC TLV contains a P2MP FEC Element, the P2MP FEC Element MUST be the only FEC Element in the FEC TLV.
如果FEC TLV包含P2MP FEC元素，则P2MP FEC元素必须是FEC TLV中唯一的FEC元素。
The LDP MP opaque value element is used in the P2MP and MP2MP FEC Elements defined in subsequent sections. It carries information that is meaningful to Ingress LSRs and Leaf LSRs, but need not be interpreted by Transit LSRs.
LDP MP不透明值元素用于后续章节中定义的P2MP和MP2MP FEC元素。它携带对入口LSR和叶LSR有意义的信息，但不需要由传输LSR解释。
The LDP MP opaque value element basic type is encoded as follows:
LDP MP不透明值元素基本类型编码如下：
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 < 255 | 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 < 255 | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: The Type of the LDP MP opaque value element. IANA maintains a registry of basic types (see Section 11).
类型：LDP MP不透明值元素的类型。IANA维护一个基本类型的注册表（见第11节）。
Length: The length of the Value field, in octets.
长度：值字段的长度，以八位字节为单位。
Value: String of Length octets, to be interpreted as specified by the Type field.
值：长度为八位字节的字符串，将按照类型字段的指定进行解释。
The LDP MP opaque value element extended type is encoded as follows:
LDP MP不透明值元素扩展类型编码如下：
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 = 255 | Extended Type | Length (high) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Length (low) | 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 = 255 | Extended Type | Length (high) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Length (low) | Value |
+-+-+-+-+-+-+-+-+ |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Type = 255.
类型：Type=255。
Extended Type: The Extended Type of the LDP MP opaque value element. IANA maintains a registry of extended types (see Section 11).
扩展类型：LDP MP不透明值元素的扩展类型。IANA维护一个扩展类型的注册表（见第11节）。
Length: The length of the Value field, in octets.
长度：值字段的长度，以八位字节为单位。
Value: String of Length octets, to be interpreted as specified by the Type field.
值：长度为八位字节的字符串，将按照类型字段的指定进行解释。
The generic LSP identifier is a type of opaque value element basic type encoded as follows:
通用LSP标识符是一种不透明值元素基本类型，编码如下：
Type: 1
类型：1
Length: 4
长度：4
Value: A 32-bit integer, unique in the context of the root, as identified by the root's address.
值：一个32位整数，在根的上下文中是唯一的，由根的地址标识。
This type of opaque value element is recommended when mapping of traffic to LSPs is non-algorithmic and is done by means outside LDP.
当流量到LSP的映射是非算法性的，并且是通过LDP之外的方式完成时，建议使用这种类型的不透明值元素。
This section defines the rules for the processing and propagation of the P2MP FEC Element. The following notation is used in the processing rules:
本节定义了P2MP FEC元素的处理和传播规则。处理规则中使用了以下符号：
1. P2MP FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y.
1. P2MP FEC元素<X，Y>：具有根节点地址X和不透明值Y的FEC元素。
2. P2MP Label Mapping <X, Y, L>: a Label Mapping message with a FEC TLV with a single P2MP FEC Element <X, Y> and Label TLV with label L. Label L MUST be allocated from the per-platform label space (see [RFC3031], Section 3.14) of the LSR sending the Label Mapping message. The use of the interface label space is outside the scope of this document.
2. P2MP标签映射<X，Y，L>：带有FEC TLV和单个P2MP FEC元素的标签映射消息<X，Y>，以及带有标签L的标签TLV。必须从发送标签映射消息的LSR的每个平台标签空间（参见[RFC3031]，第3.14节）分配标签L。接口标签空间的使用不在本文档的范围内。
3. P2MP Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC TLV with a single P2MP FEC Element <X, Y> and Label TLV with label L.
3. P2MP标签撤销<X，Y，L>：带有FEC TLV和单个P2MP FEC元素的标签撤销消息<X，Y>，以及带有标签L的标签TLV。
4. P2MP LSP <X, Y> (or simply <X, Y>): a P2MP LSP with root node address X and opaque value Y.
4. P2MP LSP<X，Y>（或简称为<X，Y>）：根节点地址为X，不透明值为Y的P2MP LSP。
5. The notation L' -> {<I1, L1> <I2, L2> ..., <In, Ln>} on LSR X means that on receiving a packet with label L', X makes n copies of the packet. For copy i of the packet, X swaps L' with Li and sends it out over interface Ii.
5. LSR X上的符号L'->{<I1，L1><I2，L2>..，<In，Ln>}意味着在接收到带有标签L'的数据包时，X生成该数据包的n个副本。对于数据包的副本i，X将L'与Li交换，并通过接口Ii将其发送出去。
The procedures below are organized by the role that the node plays in the P2MP LSP. Node Z knows that it is a leaf node by a discovery process that is outside the scope of this document. During the course of protocol operation, the root node recognizes its role because it owns the root node address. A transit node is any node (other than the root node) that receives a P2MP Label Mapping message (i.e., one that has leaf nodes downstream of it).
以下步骤是根据节点在P2MP LSP中扮演的角色组织的。节点Z通过发现过程知道它是一个叶节点，该发现过程超出了本文的范围。在协议操作过程中，根节点识别其角色，因为它拥有根节点地址。传输节点是接收P2MP标签映射消息的任何节点（根节点除外）（即，在其下游具有叶节点的节点）。
Note that a transit node (and indeed the root node) may also be a leaf node.
请注意，传输节点（实际上是根节点）也可以是叶节点。
The remainder of this section specifies the procedures for originating P2MP Label Mapping messages and for processing received P2MP Label Mapping messages for a particular LSP. The procedures for a particular LSR depend upon the role that LSR plays in the LSP (Ingress, Transit, or Egress).
本节的其余部分指定了针对特定LSP发起P2MP标签映射消息和处理接收到的P2MP标签映射消息的过程。特定LSR的程序取决于LSR在LSP中扮演的角色（入口、运输或出口）。
All labels discussed here are downstream-assigned [RFC5332] except those that are assigned using the procedures of Section 6.
此处讨论的所有标签均为下游分配[RFC5332]，使用第6节程序分配的标签除外。
Each node that is either an Leaf or Transit LSR of MP LSP needs to use the procedures below to select an upstream LSR. A node Z that wants to join an MP LSP <X, Y> determines the LDP peer U that is Z's next-hop on the best path from Z to the root node X. If there is
作为MP LSP的叶LSR或传输LSR的每个节点都需要使用以下步骤来选择上游LSR。想要加入MP LSP<X，Y>的节点Z确定LDP对等方U，该对等方U是Z在从Z到根节点X的最佳路径上的下一跳
more than one such LDP peer, only one of them is picked. U is Z's "upstream LSR" for <X, Y>.
不止一个这样的自民党同僚，只有一个被选中。U是Z的“上游LSR”，表示<X，Y>。
When there are several candidate upstream LSRs, the LSR MUST select one upstream LSR. The algorithm used for the LSR selection is a local matter. If the LSR selection is done over a LAN interface and the Section 6 procedures are applied, the following procedure SHOULD be applied to ensure that the same upstream LSR is elected among a set of candidate receivers on that LAN.
当存在多个候选上游LSR时，LSR必须选择一个上游LSR。用于LSR选择的算法是局部问题。如果通过LAN接口进行LSR选择，并应用第6节程序，则应应用以下程序，以确保在该LAN上的一组候选接收器中选择相同的上游LSR。
1. The candidate upstream LSRs are numbered from lower to higher IP address.
1. 候选上游LSR的IP地址从低到高依次编号。
2. The following hash is performed: H = (CRC32(Opaque Value)) modulo N, where N is the number of upstream LSRs. The 'Opaque Value' is the field identified in the FEC Element right after 'Opaque Length'. The 'Opaque Length' indicates the size of the opaque value used in this calculation.
2. 执行以下散列：H=（CRC32（不透明值））模N，其中N是上游lsr的数量。“不透明值”是在“不透明长度”之后的FEC元素中标识的字段。“不透明长度”表示此计算中使用的不透明值的大小。
3. The selected upstream LSR U is the LSR that has the number H.
3. 所选上游LSR U是具有数字H的LSR。
This procedure will ensure that there is a single forwarder over the LAN for a particular LSP.
此过程将确保特定LSP在LAN上有一个转发器。
Suppose LSR U receives an MP Label Mapping message from a downstream LSR D, specifying label L. Suppose further that U is connected to D over several LDP enabled interfaces or RSVP-TE Tunnel interfaces. If U needs to transmit to D a data packet whose top label is L, U is free to transmit the packet on any of those interfaces. The algorithm it uses to choose a particular interface and next-hop for a particular such packet is a local matter. For completeness, the following procedure MAY be used. LSR U may do a lookup in the unicast routing table to find the best interface and next-hop to reach LSR D. If the next-hop and interface are also advertised by LSR D via the LDP session, it can be used to transmit the packet to LSR D.
假设LSR U从下游LSR D接收MP标签映射消息，指定标签L。进一步假设U通过几个支持LDP的接口或RSVP-TE隧道接口连接到D。如果U需要向D发送顶部标签为L的数据包，则U可以在这些接口中的任何一个上自由地发送该数据包。它用于选择特定接口和特定数据包的下一跳的算法是局部问题。为完整起见，可使用以下程序。LSR U可以在单播路由表中进行查找，以找到到达LSR D的最佳接口和下一跃点。如果下一跃点和接口也由LSR D通过LDP会话播发，则可以使用它将数据包传输到LSR D。
A leaf node Z of P2MP LSP <X, Y> determines its upstream LSR U for <X, Y> as per Section 2.4.1.1, allocates a label L, and sends a P2MP Label Mapping <X, Y, L> to U.
P2MP LSP<X，Y>的叶节点Z根据第2.4.1.1节确定其上游LSR U的<X，Y>，分配标签L，并向U发送P2MP标签映射<X，Y，L>。
Suppose a transit node Z receives a P2MP Label Mapping <X, Y, L> from LSR T. Z checks whether it already has state for <X, Y>. If not, Z determines its upstream LSR U for <X, Y> as per Section 2.4.1.1. Using this Label Mapping to update the label forwarding table MUST NOT be done as long as LSR T is equal to LSR U. If LSR U is different from LSR T, Z will allocate a label L', and install state to swap L' with L over interface I associated with LSR T and send a P2MP Label Mapping <X, Y, L'> to LSR U. Interface I is determined via the procedures in Section 2.4.1.2.
假设中转节点Z从LSR T接收到一个P2MP标签映射<X，Y，L>。Z检查它是否已经具有<X，Y>的状态。如果不是，Z根据第2.4.1.1节确定其上游LSR U的<X，Y>。只要LSR T等于LSR U，就不能使用此标签映射更新标签转发表。如果LSR U不同于LSR T，Z将分配标签L'，并安装状态，通过与LSR T关联的接口I将L'与L交换，并发送P2MP标签映射<X，Y，到LSR U的接口I通过第2.4.1.2节中的程序确定。
If Z already has state for <X, Y>, then Z does not send a Label Mapping message for P2MP LSP <X, Y>. If LSR T is not equal to the upstream LSR of <X, Y> and <I, L> does not already exist as forwarding state, the forwarding state is updated. Assuming its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. If LSR T is equal to the installed upstream LSR, the Label Mapping from LSR T MUST be retained and MUST NOT update the label forwarding table.
如果Z已具有<X，Y>的状态，则Z不会为P2MP LSP<X，Y>发送标签映射消息。如果LSR T不等于<X，Y>的上游LSR并且<I，L>作为转发状态不存在，则转发状态被更新。假设它的旧转发状态是L'->{<I1，L1><I2，L2>..，<In，Ln>}，它的新转发状态变成L'->{<I1，L1><I2，L2>..，<In，Ln>，<I，L>}。如果LSR T等于安装的上游LSR，则必须保留来自LSR T的标签映射，并且不得更新标签转发表。
Suppose the root node Z receives a P2MP Label Mapping <X, Y, L> from LSR T. Z checks whether it already has forwarding state for <X, Y>. If not, Z creates forwarding state to push label L onto the traffic that Z wants to forward over the P2MP LSP (how this traffic is determined is outside the scope of this document).
假设根节点Z从LSR T接收到一个P2MP标签映射<X，Y，L>。Z检查它是否已经具有<X，Y>的转发状态。如果不是，Z将创建转发状态，将标签L推送到Z希望通过P2MP LSP转发的流量上（如何确定该流量超出了本文档的范围）。
If Z already has forwarding state for <X, Y>, then Z adds "push label L, send over interface I" to the next hop, where I is the interface associated with LSR T and determined via the procedures in Section 2.4.1.2.
如果Z已经具有<X，Y>的转发状态，则Z将“推标签L，通过接口I发送”添加到下一跳，其中I是与LSR T相关联的接口，并通过第2.4.1.2节中的程序确定。
The following section lists procedures for generating and processing P2MP Label Withdraw messages for nodes that participate in a P2MP LSP. An LSR should apply those procedures that apply to it, based on its role in the P2MP LSP.
下一节列出了为参与P2MP LSP的节点生成和处理P2MP Label REQUE消息的过程。LSR应根据其在P2MP LSP中的角色应用适用于其的程序。
If a leaf node Z discovers that it has no downstream neighbors in that LSP, and that it has no need to be an Egress LSR for that LSP (by means outside the scope of this document), then it SHOULD send a Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is the label it had previously advertised to U for <X, Y>.
如果叶节点Z发现它在该LSP中没有下游邻居，并且它不需要是该LSP的出口LSR（通过本文档范围之外的方式），那么它应该向其上游LSR U发送标签retrach<X，Y，L>，用于<X，Y>，其中L是它之前为<X，Y>向U发布的标签。
If a transit node Z receives a Label Withdraw message <X, Y, L> from a node W, it deletes label L from its forwarding state and sends a Label Release message with label L to W.
如果中转节点Z从节点W接收到标签撤销消息<X，Y，L>，则它将标签L从其转发状态中删除，并发送带有标签L到W的标签释放消息。
If deleting L from Z's forwarding state for P2MP LSP <X, Y> results in no state remaining for <X, Y>, then Z propagates the Label Withdraw for <X, Y> to its upstream T, by sending a Label Withdraw <X, Y, L1> where L1 is the label Z had previously advertised to T for <X, Y>.
如果从Z的转发状态中为P2MP LSP<X，Y>删除L导致<X，Y>没有剩余状态，则Z通过发送标签收回<X，Y，L1>将标签收回<X，Y>传播到其上游T，其中L1是Z先前为<X，Y>向T播发的标签。
When the root node of a P2MP LSP receives a Label Withdraw message, the procedures are the same as those for transit nodes, except that it would not propagate the Label Withdraw upstream (as it has no upstream).
当P2MP LSP的根节点接收到标签撤回消息时，程序与中转节点相同，只是它不会向上游传播标签撤回（因为它没有上游）。
Suppose that for a given node Z participating in a P2MP LSP <X, Y>, the upstream LSR changes from U to U' as per Section 2.4.1.1. Z MUST update its forwarding state as follows. It allocates a new label, L', for <X, Y>. The forwarding state for L' is copied from the forwarding state for L, with one exception: if U' was present in the forwarding state of L, it MUST NOT be installed in the forwarding state of L'. Then the forwarding state for L is deleted and the forwarding state for L' is installed. In addition, Z MUST send a Label Mapping <X, Y, L'> to U' and send a Label Withdraw <X, Y, L> to U. Note, if there was a downstream mapping from U that was not installed in the forwarding due to the procedures defined in Section 2.4.1.4, it can now be installed.
假设对于参与P2MP LSP<X，Y>的给定节点Z，上游LSR根据第2.4.1.1节从U变为U'。Z必须更新其转发状态，如下所示。它为<X，Y>分配了一个新的标签L'。L'的转发状态是从L'的转发状态复制而来的，但有一个例外：如果U'在L'的转发状态中存在，则不得在L'的转发状态下安装。然后删除L的转发状态并安装L'的转发状态。此外，Z必须将标签映射<X，Y，L'>发送至U'，并将标签撤回<X，Y，L>发送至U。注意，如果由于第2.4.1.4节中规定的程序，转发中未安装来自U的下游映射，则现在可以安装该映射。
While changing the upstream LSR, the following must be taken into consideration. If L' is added before L is removed, there is a potential risk of packet duplication and/or the creation of a transient data-plane forwarding loop. If L is removed before L' is added, packet loss may result. Ideally the change from L to L' is done atomically such that no packet loss or duplication occurs. If
更改上游LSR时，必须考虑以下因素。如果在删除L之前添加L’，则存在数据包复制和/或创建瞬态数据平面转发循环的潜在风险。如果在添加L'之前删除L，则可能会导致数据包丢失。理想情况下，从L到L'的更改是以原子方式完成的，这样就不会发生数据包丢失或重复。如果
that is not possible, the RECOMMENDED default behavior is to remove L before adding L'.
这是不可能的，建议的默认行为是在添加L'之前删除L。
An MP2MP LSP is much like a P2MP LSP in that it consists of a single root node, zero or more transit nodes, and one or more Leaf LSRs acting equally an as Ingress or Egress LSR. A leaf node participates in the setup of an MP2MP LSP by establishing both a downstream LSP, which is much like a P2MP LSP from the root, and an upstream LSP, which is used to send traffic toward the root and other leaf nodes. Transit nodes support the setup by propagating the upstream and downstream LSP setup toward the root and installing the necessary MPLS forwarding state. The transmission of packets from the root node of an MP2MP LSP to the receivers is identical to that for a P2MP LSP. Traffic from a downstream node follows the upstream LSP toward the root node and branches downward along the downstream LSP as required to reach other leaf nodes. A packet that is received from a downstream node MUST never be forwarded back out to that same node. Mapping traffic to the MP2MP LSP may happen at any leaf node. How that mapping is established is outside the scope of this document.
MP2MP LSP非常类似于P2MP LSP，因为它由单个根节点、零个或多个传输节点以及一个或多个与入口或出口LSR同等作用的叶LSR组成。叶节点通过建立下游LSP（非常类似于根节点的P2MP LSP）和上游LSP（用于向根节点和其他叶节点发送流量）来参与MP2MP LSP的设置。传输节点通过向根节点传播上游和下游LSP设置并安装必要的MPLS转发状态来支持设置。从MP2MP LSP的根节点到接收器的数据包传输与P2MP LSP相同。来自下游节点的流量沿着上游LSP流向根节点，并根据需要沿着下游LSP向下分支以到达其他叶节点。从下游节点接收的数据包决不能转发回同一节点。将流量映射到MP2MP LSP可能发生在任何叶节点。如何建立映射超出了本文档的范围。
Due to how an MP2MP LSP is built, a Leaf LSR that is sending packets on the MP2MP LSP does not receive its own packets. There is also no additional mechanism needed on the root or Transit LSR to match upstream traffic to the downstream forwarding state. Packets that are forwarded over an MP2MP LSP will not traverse a link more than once, with the possible exception of LAN links (see Section 3.3.1), if the procedures of [RFC5331] are not provided.
由于MP2MP LSP是如何构建的，在MP2MP LSP上发送数据包的叶LSR不会接收自己的数据包。根或传输LSR上也不需要额外的机制来匹配上游流量和下游转发状态。如果未提供[RFC5331]中的程序，则通过MP2MP LSP转发的数据包将不会在链路上穿越一次以上，LAN链路可能除外（见第3.3.1节）。
Support for the setup of MP2MP LSPs is advertised using LDP capabilities as defined in [RFC5561]. An implementation supporting the MP2MP procedures specified in this document MUST implement the procedures for Capability Parameters in Initialization messages.
使用[RFC5561]中定义的LDP功能公布对MP2MP LSP设置的支持。支持本文件中规定的MP2MP程序的实现必须实现初始化消息中的功能参数程序。
A new Capability Parameter TLV is defined, the MP2MP Capability. Following is the format of the MP2MP Capability Parameter.
定义了一个新的性能参数TLV，即MP2MP性能。以下是MP2MP性能参数的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| MP2MP Capability (0x0509) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| MP2MP Capability (0x0509) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
S: As specified in [RFC5561]
S：按照[RFC5561]中的规定
The MP2MP Capability TLV MUST be advertised in the LDP Initialization message. Advertisement of the MP2MP Capability indicates support of the procedures for MP2MP LSP setup detailed in this document. If the peer has not advertised the corresponding capability, then label messages using the MP2MP upstream and downstream FEC Elements SHOULD NOT be sent to the peer.
MP2MP能力TLV必须在LDP初始化消息中公布。MP2MP功能的公告表示支持本文档中详述的MP2MP LSP设置程序。如果对等方未公布相应的能力，则不应向对等方发送使用MP2MP上游和下游FEC元素的标签消息。
For the setup of an MP2MP LSP with LDP, we define 2 new protocol entities, the MP2MP downstream FEC and upstream FEC Element. Both elements will be used as FEC Elements in the FEC TLV. Note that the MP2MP FEC Elements do not necessarily identify the traffic that must be mapped to the LSP, so from that point of view, the use of the term FEC is a misnomer. The description of the MP2MP FEC Elements follow.
为了使用LDP建立MP2MP LSP，我们定义了两个新的协议实体，MP2MP下游FEC和上游FEC元素。这两个元件将用作FEC TLV中的FEC元件。注意，MP2MP FEC元素不一定识别必须映射到LSP的业务，因此从这个角度来看，术语FEC的使用是一个误称。MP2MP FEC元件的说明如下。
The structure, encoding, and error handling for the MP2MP downstream and upstream FEC Elements are the same as for the P2MP FEC Element described in Section 2.2. The difference is that two new FEC types are used: MP2MP downstream type (0x08) and MP2MP upstream type (0x07).
MP2MP下游和上游FEC元件的结构、编码和错误处理与第2.2节中描述的P2MP FEC元件相同。区别在于使用了两种新的FEC类型：MP2MP下游类型（0x08）和MP2MP上游类型（0x07）。
If a FEC TLV contains an MP2MP FEC Element, the MP2MP FEC Element MUST be the only FEC Element in the FEC TLV.
如果FEC TLV包含MP2MP FEC元素，则MP2MP FEC元素必须是FEC TLV中唯一的FEC元素。
Note, except when using the procedures of [RFC5331], the MPLS labels used are "downstream-assigned" [RFC5332], even if they are bound to the "upstream FEC Element".
注意，除了使用[RFC5331]的过程外，所使用的MPLS标签是“下游分配的”[RFC5332]，即使它们绑定到“上游FEC元素”。
This section defines the rules for the processing and propagation of the MP2MP FEC Elements. The following notation is used in the processing rules:
本节定义了MP2MP FEC元素的处理和传播规则。处理规则中使用了以下符号：
1. MP2MP downstream LSP <X, Y> (or simply downstream <X, Y>): an MP2MP LSP downstream path with root node address X and opaque value Y.
1. MP2MP下游LSP<X，Y>（或简称下游<X，Y>）：具有根节点地址X和不透明值Y的MP2MP LSP下游路径。
2. MP2MP upstream LSP <X, Y, D> (or simply upstream <X, Y, D>): an MP2MP LSP upstream path for downstream node D with root node address X and opaque value Y.
2. MP2MP上游LSP<X，Y，D>（或者简单地说上游<X，Y，D>）：用于下游节点D的MP2MP LSP上游路径，具有根节点地址X和不透明值Y。
3. MP2MP downstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y used for a downstream MP2MP LSP.
3. MP2MP下游FEC元素<X，Y>：具有根节点地址X和不透明值Y的FEC元素，用于下游MP2MP LSP。
4. MP2MP upstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y used for an upstream MP2MP LSP.
4. MP2MP上游FEC元素<X，Y>：具有根节点地址X和不透明值Y的FEC元素，用于上游MP2MP LSP。
5. MP2MP-D Label Mapping <X, Y, L>: a Label Mapping message with a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and label TLV with label L. Label L MUST be allocated from the per-platform label space (see [RFC3031], Section 3.14) of the LSR sending the Label Mapping message. The use of the interface label space is outside the scope of this document.
5. MP2MP-D标签映射<X，Y，L>：带有FEC TLV的标签映射消息，带有单个MP2MP下游FEC元素<X，Y>，以及带有标签L的标签TLV。必须从发送标签映射消息的LSR的每个平台标签空间（参见[RFC3031]，第3.14节）分配标签L。接口标签空间的使用不在本文档的范围内。
6. MP2MP-U Label Mapping <X, Y, Lu>: a Label Mapping message with a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and label TLV with label Lu. Label Lu MUST be allocated from the per-platform label space (see [RFC3031], Section 3.14) of the LSR sending the Label Mapping message. The use of the interface label space is outside the scope of this document.
6. MP2MP-U标签映射<X，Y，Lu>：带有FEC TLV和单个MP2MP上游FEC元素的标签映射消息<X，Y>，以及带有标签Lu的标签TLV。必须从发送标签映射消息的LSR的每个平台标签空间（参见[RFC3031]，第3.14节）分配标签Lu。接口标签空间的使用不在本文档的范围内。
7. MP2MP-D Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and label TLV with label L.
7. MP2MP-D标签撤销<X，Y，L>：带有FEC TLV的标签撤销消息，带有单个MP2MP下游FEC元素<X，Y>，以及带有标签L的标签TLV。
8. MP2MP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and label TLV with label Lu.
8. MP2MP-U标签撤销<X，Y，Lu>：带有FEC TLV的标签撤销消息，带有单个MP2MP上游FEC元素<X，Y>，并带有标签Lu的标签TLV。
9. MP2MP-D Label Release <X, Y, L>: a Label Release message with a FEC TLV with a single MP2MP downstream FEC Element <X, Y> and Label TLV with label L.
9. MP2MP-D标签释放<X，Y，L>：带有FEC TLV的标签释放消息，带有单个MP2MP下游FEC元素<X，Y>，以及带有标签L的标签TLV。
10. MP2MP-U Label Release <X, Y, Lu>: a Label Release message with a FEC TLV with a single MP2MP upstream FEC Element <X, Y> and label TLV with label Lu.
10. MP2MP-U标签释放<X，Y，Lu>：带有FEC TLV和单个MP2MP上游FEC元素的标签释放消息<X，Y>，以及带有标签Lu的标签TLV。
The procedures below are organized by the role which the node plays in the MP2MP LSP. Node Z knows that it is a leaf node by a discovery process that is outside the scope of this document. During the course of the protocol operation, the root node recognizes its role because it owns the root node address. A transit node is any node (other then the root node) that receives an MP2MP Label Mapping message (i.e., one that has leaf nodes downstream of it).
下面的过程是根据节点在MP2MP LSP中扮演的角色组织的。节点Z通过发现过程知道它是一个叶节点，该发现过程超出了本文的范围。在协议操作过程中，根节点识别其角色，因为它拥有根节点地址。传输节点是接收MP2MP标签映射消息的任何节点（根节点除外）（即，在其下游具有叶节点的节点）。
Note that a transit node (and indeed the root node) may also be a leaf node and the root node does not have to be an Ingress LSR or a leaf of the MP2MP LSP.
注意，传输节点（实际上是根节点）也可以是叶节点，并且根节点不必是入口LSR或MP2MP LSP的叶。
The remainder of this section specifies the procedures for originating MP2MP Label Mapping messages and for processing received MP2MP Label Mapping messages for a particular LSP. The procedures for a particular LSR depend upon the role that the LSR plays in the LSP (Ingress, Transit, or Egress).
本节的其余部分指定了针对特定LSP发起MP2MP标签映射消息和处理接收到的MP2MP标签映射消息的过程。特定LSR的程序取决于LSR在LSP中扮演的角色（入口、运输或出口）。
All labels discussed here are downstream-assigned [RFC5332] except those that are assigned using the procedures of Section 6.
此处讨论的所有标签均为下游分配[RFC5332]，使用第6节程序分配的标签除外。
Determining the upstream LDP peer U for an MP2MP LSP <X, Y> follows the procedure for a P2MP LSP described in Section 2.4.1.1.
按照第2.4.1.1节中描述的P2MP LSP程序确定MP2MP LSP<X，Y>的上游LDP对等点U。
An LDP peer U that receives an MP2MP-D Label Mapping from an LDP peer D will treat D as downstream MP2MP LSR.
从LDP对等方D接收MP2MP-D标签映射的LDP对等方U将把D视为下游MP2MP LSR。
There are two methods for installing the upstream path of an MP2MP LSP to a downstream neighbor.
有两种方法可以将MP2MP LSP的上游路径安装到下游邻居。
1. We can install the upstream MP2MP path (to a downstream neighbor) based on receiving an MP2MP-D Label Mapping from the downstream neighbor. This will install the upstream path on a hop-by-hop basis.
1. 我们可以基于从下游邻居接收MP2MP-D标签映射来安装上游MP2MP路径（到下游邻居）。这将在逐跳的基础上安装上游路径。
2. We install the upstream MP2MP path (to a downstream neighbor) based on receiving an MP2MP-U Label Mapping from the upstream neighbor. An LSR does not need to wait for the MP2MP-U Label Mapping if it is the root of the MP2MP LSP or if it already received an MP2MP-U Label Mapping from the upstream neighbor. We call this method ordered mode. The typical result of this mode is that the downstream path of the MP2MP is built hop by hop towards the root. Once the root is reached, the root node will trigger an MP2MP-U Label Mapping to the downstream neighbor(s).
2. 我们基于从上游邻居接收MP2MP-U标签映射来安装上游MP2MP路径（到下游邻居）。如果LSR是MP2MP LSP的根，或者已经从上游邻居接收到MP2MP-U标签映射，则LSR不需要等待MP2MP-U标签映射。我们称这种方法为有序模式。这种模式的典型结果是，MP2MP的下游路径是朝着根一跳一跳地构建的。一旦到达根节点，根节点将触发到下游邻居的MP2MP-U标签映射。
For setting up the upstream path of an MP2MP LSP, ordered mode SHOULD be used. Due to ordered mode, the upstream path of the MP2MP LSP is installed at the leaf node once the path to the root has completed. The advantage is that when a leaf starts sending immediately after the upstream path is installed, packets are able to reach the root
为设置MP2MP LSP的上游路径，应使用有序模式。由于顺序模式，MP2MP LSP的上游路径在根节点的路径完成后安装在叶节点上。这样做的好处是，当安装了上行路径之后，一个叶立即开始发送数据包时，数据包就能够到达根
node without being dropped due to an incomplete LSP. Method 1 is not able to guarantee that the upstream path has completed before the leaf starts sending.
由于LSP不完整而未删除的节点。方法1无法保证在叶开始发送之前上游路径已经完成。
A leaf node Z of an MP2MP LSP <X, Y> determines its upstream LSR U for <X, Y> as per Section 3.3.1.1, allocates a label L, and sends an MP2MP-D Label Mapping <X, Y, L> to U.
MP2MP LSP<X，Y>的叶节点Z根据第3.3.1.1节确定其<X，Y>的上游LSR U，分配标签L，并向U发送MP2MP-D标签映射<X，Y，L>。
Leaf node Z expects an MP2MP-U Label Mapping <X, Y, Lu> from node U in response to the MP2MP-D Label Mapping it sent to node U. Z checks whether it already has forwarding state for upstream <X, Y>. If not, Z creates forwarding state to push label Lu onto the traffic that Z wants to forward over the MP2MP LSP. How it determines what traffic to forward on this MP2MP LSP is outside the scope of this document.
叶节点Z需要来自节点U的MP2MP-U标签映射<X，Y，Lu>，以响应它发送给节点U的MP2MP-D标签映射。Z检查它是否已经具有上游<X，Y>的转发状态。如果不是，Z创建转发状态，将标签Lu推送到Z希望通过MP2MP LSP转发的流量上。它如何确定在此MP2MP LSP上转发的通信量超出了本文档的范围。
Suppose node Z receives an MP2MP-D Label Mapping <X, Y, L> from LSR D. Z checks whether it has forwarding state for downstream <X, Y>. If not, Z determines its upstream LSR U for <X, Y> as per Section 3.3.1.1. Using this Label Mapping to update the label forwarding table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U is different from LSR D, Z will allocate a label L' and install downstream forwarding state to swap label L' with label L over interface I associated with LSR D and send an MP2MP-D Label Mapping <X, Y, L'> to U. Interface I is determined via the procedures in Section 2.4.1.2.
假设节点Z从lsrd接收到一个MP2MP-D标签映射<X，Y，L>。Z检查它是否具有下游<X，Y>的转发状态。如果不是，则Z根据第3.3.1.1节确定其上游LSR U的<X，Y>。只要LSR D等于LSR U，就不能使用此标签映射更新标签转发表。如果LSR U不同于LSR D，Z将分配标签L'并安装下游转发状态，以便通过与LSR D相关联的接口I将标签L'与标签L交换，并发送MP2MP-D标签映射<X，Y，接口I通过第2.4.1.2节中的程序确定。
If Z already has forwarding state for downstream <X, Y>, all that Z needs to do in this case is check that LSR D is not equal to the upstream LSR of <X, Y> and update its forwarding state. Assuming its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. If the LSR D is equal to the installed upstream LSR, the Label Mapping from LSR D MUST be retained and MUST NOT update the label forwarding table.
如果Z已经具有下游<X，Y>的转发状态，那么在这种情况下Z需要做的就是检查LSR D是否不等于<X，Y>的上游LSR，并更新其转发状态。假设它的旧转发状态是L'->{<I1，L1><I2，L2>..，<In，Ln>}，它的新转发状态变成L'->{<I1，L1><I2，L2>..，<In，Ln>，<I，L>}。如果LSR D等于安装的上游LSR，则必须保留来自LSR D的标签映射，并且不得更新标签转发表。
Node Z checks if upstream LSR U already assigned a label Lu to <X, Y>. If not, transit node Z waits until it receives an MP2MP-U Label Mapping <X, Y, Lu> from LSR U (see Section 3.3.1.3). Once the MP2MP-U Label Mapping is received from LSR U, node Z checks whether it already has forwarding state upstream <X, Y, D>. If it does, then no further action needs to happen. If it does not, it allocates a label Lu' and creates a new label swap for Lu' with label Lu over interface Iu. Interface Iu is determined via the procedures in Section 2.4.1.2. In addition, it also adds the label swap(s) from
节点Z检查上游LSR U是否已将标签Lu分配给<X，Y>。否则，中转节点Z将等待，直到它从LSR U接收到MP2MP-U标签映射<X，Y，Lu>（参见第3.3.1.3节）。一旦从LSR U接收到MP2MP-U标签映射，节点Z就会检查它是否已经具有上游的转发状态<X，Y，D>。如果是这样，那么就不需要采取进一步的行动。如果没有，它将分配一个标签Lu'并在接口Iu上为带有标签Lu的Lu'创建一个新的标签交换。接口Iu通过第2.4.1.2节中的程序确定。此外，它还添加了来自的标签交换
the forwarding state downstream <X, Y>, omitting the swap on interface I for node D. The swap on interface I for node D is omitted to prevent a packet originated by D to be forwarded back to D.
下游的转发状态<X，Y>，省略了节点D在接口I上的交换。省略了节点D在接口I上的交换，以防止由D发起的数据包被转发回D。
Node Z determines the downstream MP2MP LSR as per Section 3.3.1.2, and sends an MP2MP-U Label Mapping <X, Y, Lu'> to node D.
节点Z根据第3.3.1.2节确定下游MP2MP LSR，并向节点D发送MP2MP-U标签映射<X，Y，Lu'>。
Suppose root/leaf node Z receives an MP2MP-D Label Mapping <X, Y, L> from node D. Z checks whether it already has forwarding state downstream <X, Y>. If not, Z creates downstream forwarding state to push label L on traffic that Z wants to forward down the MP2MP LSP. How it determines what traffic to forward on this MP2MP LSP is outside the scope of this document. If Z already has forwarding state for downstream <X, Y>, then Z will add the label push for L over interface I to it. Interface I is determined via the procedures in Section 2.4.1.2.
假设根/叶节点Z从节点D接收到一个MP2MP-D标签映射<X，Y，L>。Z检查它是否已经具有下游的转发状态<X，Y>。如果不是，Z将创建下行转发状态，以将Z希望转发的流量上的标签L推送到MP2MP LSP。它如何确定在此MP2MP LSP上转发的通信量超出了本文档的范围。如果Z已经具有下游<X，Y>的转发状态，那么Z将在接口I上添加标签push for L。接口I通过第2.4.1.2节中的程序确定。
Node Z checks if it has forwarding state for upstream <X, Y, D>. If not, Z allocates a label Lu' and creates upstream forwarding state to swap Lu' with the label swap(s) from the forwarding state downstream <X, Y>, except the swap on interface I for node D. This allows upstream traffic to go down the MP2MP to other node(s), except the node from which the traffic was received. Node Z determines the downstream MP2MP LSR as per section Section 3.3.1.2, and sends an MP2MP-U Label Mapping <X, Y, Lu'> to node D. Since Z is the root of the tree, Z will not send an MP2MP-D Label Mapping and will not receive an MP2MP-U Label Mapping.
节点Z检查其是否具有上游<X，Y，D>的转发状态。如果不是，Z将分配标签Lu'并创建上游转发状态，以便从转发状态下游<X，Y>与标签交换Lu'进行交换，节点D的接口I上的交换除外。这允许上游流量沿着MP2MP向下移动到其他节点，但接收到流量的节点除外。节点Z根据第3.3.1.2节确定下游MP2MP LSR，并向节点D发送一个MP2MP-U标签映射<X，Y，Lu'>。因为Z是树的根，所以Z不会发送MP2MP-D标签映射，也不会接收MP2MP-U标签映射。
Suppose the root node Z receives an MP2MP-D Label Mapping <X, Y, L> from node D. Z checks whether it already has forwarding state for downstream <X, Y>. If not, Z creates downstream forwarding state and installs a outgoing label L over interface I. Interface I is determined via the procedures in Section 2.4.1.2. If Z already has forwarding state for downstream <X, Y>, then Z will add label L over interface I to the existing state.
假设根节点Z从节点D接收到一个MP2MP-D标签映射<X，Y，L>。Z检查它是否已经具有下游<X，Y>的转发状态。如果没有，Z将创建下游转发状态并在接口I上安装传出标签L。接口I通过第2.4.1.2节中的程序确定。如果Z已经具有下游<X，Y>的转发状态，则Z将在接口I上向现有状态添加标签L。
Node Z checks if it has forwarding state for upstream <X, Y, D>. If not, Z allocates a label Lu' and creates forwarding state to swap Lu' with the label swap(s) from the forwarding state downstream <X, Y>, except the swap for node D. This allows upstream traffic to go down the MP2MP to other node(s), except the node from which it was
节点Z检查其是否具有上游<X，Y，D>的转发状态。如果不是，Z将分配一个标签Lu'并创建转发状态，以将Lu'与转发状态下游<X，Y>的标签交换进行交换，但节点D的交换除外。这允许上游流量沿MP2MP向下传输到其他节点，但从其发送的节点除外
received. Root node Z determines the downstream MP2MP LSR D as per Section 3.3.1.2, and sends an MP2MP-U Label Mapping <X, Y, Lu'> to it. Since Z is the root of the tree, Z will not send an MP2MP-D Label Mapping and will not receive an MP2MP-U Label Mapping.
收到。根节点Z根据第3.3.1.2节确定下游MP2MP LSR D，并向其发送MP2MP-U标签映射<X，Y，Lu'>。因为Z是树的根，所以Z不会发送MP2MP-D标签映射，也不会接收MP2MP-U标签映射。
The following section lists procedures for generating and processing MP2MP Label Withdraw messages for nodes that participate in an MP2MP LSP. An LSR should apply those procedures that apply to it, based on its role in the MP2MP LSP.
以下部分列出了为参与MP2MP LSP的节点生成和处理MP2MP标签撤销消息的过程。LSR应根据其在MP2MP LSP中的角色应用适用于其的程序。
If a leaf node Z discovers (by means outside the scope of this document) that it has no downstream neighbors in that LSP and that it has no need to be an Egress LSR for that LSP (by means outside the scope of this document), then it SHOULD send an MP2MP-D Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is the label it had previously advertised to U for <X,Y>. Leaf node Z will also send an unsolicited label release <X, Y, Lu> to U to indicate that the upstream path is no longer used and that label Lu can be removed.
如果叶节点Z发现（通过本文档范围之外的方式）它在该LSP中没有下游邻居，并且它不需要成为该LSP的出口LSR（通过本文档范围之外的方式），那么它应该向其上游LSR U发送一个MP2MP-D标签RECUN<X，Y，L>，以便<X，Y>，其中，L是它之前为<X，Y>向U广告的标签。叶节点Z还将向U发送一个未经请求的标签释放<X，Y，Lu>，以指示上游路径不再使用，并且可以删除标签Lu。
Leaf node Z expects the upstream router U to respond by sending a downstream label release for L.
叶节点Z期望上游路由器U通过发送L的下游标签释放来响应。
If a transit node Z receives an MP2MP-D Label Withdraw message <X, Y, L> from node D, it deletes label L from its forwarding state downstream <X, Y> and from all its upstream states for <X, Y>. Node Z sends an MP2MP-D Label Release message with label L to D. Since node D is no longer part of the downstream forwarding state, Z cleans up the forwarding state upstream <X, Y, D>. There is no need to send an MP2MP-U Label Withdraw <X, Y, Lu> to D because node D already removed Lu and sent a label release for Lu to Z.
如果中转节点Z从节点D接收到MP2MP-D标签撤销消息<X，Y，L>，它将从其下游的转发状态<X，Y>和所有上游状态<X，Y>中删除标签L。节点Z发送一个带有标签L到D的MP2MP-D标签释放消息。由于节点D不再是下游转发状态的一部分，因此Z清除上游<X，Y，D>的转发状态。不需要向D发送MP2MP-U标签撤销<X，Y，Lu>，因为节点D已经删除了Lu，并向Z发送了Lu的标签释放。
If deleting L from Z's forwarding state for downstream <X, Y> results in no state remaining for <X, Y>, then Z propagates the MP2MP-D Label Withdraw <X, Y, L> to its upstream node U for <X, Y> and will also send an unsolicited MP2MP-U Label Release <X, Y, Lu> to U to indicate that the upstream path is no longer used and that label Lu can be removed.
如果为下游<X，Y>从Z的转发状态中删除L导致<X，Y>没有剩余状态，则Z将MP2MP-D标签撤回<X，Y，L>传播到其上游节点U以<X，Y>，并且还将发送未经请求的MP2MP-U标签释放<X，Y，Lu>到U，表示上游路径不再使用，并且可以删除标签Lu。
When the root node of an MP2MP LSP receives an MP2MP-D Label Withdraw message, the procedure is the same as that for transit nodes, except that the root node will not propagate the Label Withdraw upstream (as it has no upstream).
当MP2MP LSP的根节点接收到MP2MP-D标签撤回消息时，该过程与中转节点相同，只是根节点不会向上游传播标签撤回（因为它没有上游）。
The procedure for changing the upstream LSR is the same as documented in Section 2.4.3, except it is applied to MP2MP FECs, using the procedures described in Section 3.3.1 through Section 3.3.2.3.
更改上游LSR的程序与第2.4.3节中记录的程序相同，但适用于MP2MP FEC，使用第3.3.1节至第3.3.2.3节中描述的程序。
Micro-loops created by the unicast routing protocol during convergence may also effect mLDP MP LSPs. Since the tree building logic in mLDP is based on unicast routing, a unicast routing loop may also result in a micro-loop in the MP LSPs. Micro-loops that involve 2 directly connected routers don't create a loop in mLDP. mLDP is able to prevent this inconsistency by never allowing an upstream LDP neighbor to be added as a downstream LDP neighbor into the Label Forwarding Table (LFT) for the same FEC. Micro-loops that involve more than 2 LSRs are not prevented.
在聚合期间，单播路由协议创建的微环也可能影响mLDP MP LSP。由于mLDP中的树构建逻辑基于单播路由，单播路由循环也可能导致MP LSP中的微循环。涉及2个直接连接路由器的微环路不会在mLDP中创建环路。mLDP能够通过从不允许上游LDP邻居作为下游LDP邻居添加到同一FEC的标签转发表（LFT）中来防止这种不一致性。不阻止涉及2个以上LSR的微回路。
Micro-loops that involve more than 2 LSRs may create a micro-loop in the downstream path of either an MP2MP LSP or P2MP LSP and the upstream path of the MP2MP LSP. The loops are transient and will disappear as soon as the unicast routing protocol converges and mLDP has updated the forwarding state accordingly. Micro-loops that occur in the upstream path of an MP2MP LSP may be detected by including LDP path vector in the MP2MP-U Label Mapping messages. These procedures are currently under investigation and are subjected to further study.
涉及2个以上LSR的微环可在MP2MP LSP或P2MP LSP的下游路径和MP2MP LSP的上游路径中创建微环。循环是暂时的，一旦单播路由协议收敛，mLDP相应地更新了转发状态，循环就会消失。可以通过在MP2MP-U标签映射消息中包括LDP路径向量来检测发生在MP2MP LSP的上游路径中的微环路。这些程序目前正在调查中，有待进一步研究。
An LDP MP capable router MAY use an LDP MP Status TLV to indicate additional status for an MP LSP to its remote peers. This includes signaling to peers that are either upstream or downstream of the LDP MP capable router. The value of the LDP MP Status TLV will remain opaque to LDP and MAY encode one or more status elements.
支持LDP MP的路由器可以使用LDP MP Status TLV向其远程对等方指示MP LSP的附加状态。这包括向支持LDP MP的路由器的上游或下游的对等方发送信令。LDP MP Status TLV的值将对LDP保持不透明，并且可以对一个或多个状态元素进行编码。
The LDP MP Status TLV is encoded as follows:
LDP MP状态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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| LDP MP Status Type(0x096F)| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| LDP MP Status Type(0x096F)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
~ ~
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LDP MP Status Type: The LDP MP Status (0x096F).
LDP MP状态类型：LDP MP状态（0x096F）。
Length: Length of the LDP MP Status Value in octets.
长度：LDP MP状态值的长度，以八位字节为单位。
Value: One or more LDP MP Status Value elements.
值：一个或多个LDP MP状态值元素。
The LDP MP Status Value Element that is included in the LDP MP Status TLV Value has the following encoding.
LDP MP Status TLV值中包含的LDP MP Status 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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: The type of the LDP MP Status Value Element. IANA maintains a registry of status value types (see Section 11).
类型：LDP MP状态值元素的类型。IANA维护状态值类型的注册表（参见第11节）。
Length: The length of the Value field, in octets.
长度：值字段的长度，以八位字节为单位。
Value: String of Length octets, to be interpreted as specified by the Type field.
值：长度为八位字节的字符串，将按照类型字段的指定进行解释。
The LDP MP Status TLV may appear either in a Label Mapping message or an LDP Notification message.
LDP MP Status TLV可以出现在标签映射消息或LDP通知消息中。
An LDP MP Status TLV sent in a notification message must be accompanied with a Status TLV, as described in [RFC5036]. The general format of the Notification message with an LDP MP Status TLV is:
通知消息中发送的LDP MP状态TLV必须附带状态TLV，如[RFC5036]所述。具有LDP MP状态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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP MP Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional LDP MP FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Label 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP MP Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional LDP MP FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV status code is used to indicate that LDP MP Status TLV and any additional information follows in the Notification message's "optional parameter" section. Depending on the actual contents of the LDP MP Status TLV, an LDP P2MP or MP2MP FEC TLV and a Label TLV may also be present to provide context to the LDP MP Status TLV.
状态TLV状态代码用于指示LDP MP状态TLV和通知消息的“可选参数”部分中的任何附加信息。根据LDP MP状态TLV的实际内容，还可以存在LDP P2MP或MP2MP FEC TLV和标签TLV以向LDP MP状态TLV提供上下文。
Since the notification does not refer to any particular message, the Message ID and Message Type fields are set to 0.
由于通知未引用任何特定消息，因此消息ID和消息类型字段设置为0。
An example of the Label Mapping message defined in [RFC5036] is shown below to illustrate the message with an Optional LDP MP Status TLV present.
[RFC5036]中定义的标签映射消息示例如下所示，以说明存在可选LDP MP状态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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional LDP MP Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional LDP MP Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
On a LAN, the procedures so far discussed would require the upstream LSR to send a copy of the packet to each receiver individually. If there is more than one receiver on the LAN, we don't take full benefit of the multi-access capability of the network. We may optimize the bandwidth consumption on the LAN and replication overhead on the upstream LSR by using upstream label allocation [RFC5331]. Procedures on how to distribute upstream labels using LDP is documented in [RFC6389].
在局域网上，目前讨论的程序将要求上游LSR分别向每个接收器发送数据包的副本。如果局域网上有多个接收器，我们就不能充分利用网络的多址接入能力。通过使用上行标签分配[RFC5331]，我们可以优化LAN上的带宽消耗和上行LSR上的复制开销。[RFC6389]中记录了如何使用LDP分发上游标签的程序。
The procedure to allocate a context label on a LAN is defined in [RFC5331]. That procedure results in each LSR on a given LAN having a context label which, on that LAN, can be used to identify itself uniquely. Each LSR advertises its context label as an upstream-assigned label, following the procedures of [RFC6389]. Any LSR for which the LAN is a downstream link on some P2MP or MP2MP LSP will allocate an upstream-assigned label identifying that LSP. When the LSR forwards a packet downstream on one of those LSPs, the packet's top label must be the LSR's context label, and the packet's second label is the label identifying the LSP. We will call the top label the "upstream LSR label" and the second label the "LSP label".
在LAN上分配上下文标签的过程在[RFC5331]中定义。该过程导致给定LAN上的每个LSR都有一个上下文标签，该标签在该LAN上可用于唯一地标识自身。按照[RFC6389]的程序，每个LSR将其上下文标签作为上游分配的标签播发。LAN是某些P2MP或MP2MP LSP上的下游链路的任何LSR都将分配一个上游分配的标识该LSP的标签。当LSR在其中一个LSP上向下游转发数据包时，数据包的顶部标签必须是LSR的上下文标签，数据包的第二个标签是标识LSP的标签。我们将顶部标签称为“上游LSR标签”，第二个标签称为“LSP标签”。
The downstream path of an MP2MP LSP is much like a normal P2MP LSP, so we will use the same procedures as those defined in [RFC6389]. A label request for an LSP label is sent to the upstream LSR. The Label Mapping that is received from the upstream LSR contains the LSP label for the MP2MP FEC and the upstream LSR context label. The MP2MP downstream path (corresponding to the LSP label) will be installed in the context-specific forwarding table corresponding to the upstream LSR label. Packets sent by the upstream router can be forwarded downstream using this forwarding state based on a two-label lookup.
MP2MP LSP的下游路径与普通P2MP LSP非常相似，因此我们将使用与[RFC6389]中定义的程序相同的程序。向上游LSR发送LSP标签的标签请求。从上游LSR接收的标签映射包含MP2MP FEC的LSP标签和上游LSR上下文标签。MP2MP下游路径（对应于LSP标签）将安装在对应于上游LSR标签的上下文特定转发表中。上游路由器发送的数据包可以使用这种基于双标签查找的转发状态向下游转发。
An MP2MP LSP also has an upstream forwarding path. Upstream packets need to be forwarded in the direction of the root and downstream on any node on the LAN that has a downstream interface for the LSP. For a given MP2MP LSP on a given LAN, exactly one LSR is considered to be the upstream LSR. If an LSR on the LAN receives a packet from one of its downstream interfaces for the LSP, and if it needs to forward the packet onto the LAN, it ensures that the packet's top label is the context label of the upstream LSR, and that its second label is the LSP label that was assigned by the upstream LSR.
MP2MP LSP还具有上行转发路径。上游数据包需要在具有LSP下游接口的LAN上的任何节点上沿根和下游方向转发。对于给定LAN上的给定MP2MP LSP，正好有一个LSR被视为上游LSR。如果LAN上的LSR从其用于LSP的下游接口之一接收到数据包，并且如果需要将数据包转发到LAN上，则确保数据包的顶部标签是上游LSR的上下文标签，并且其第二个标签是由上游LSR分配的LSP标签。
Other LSRs receiving the packet will not be able to tell whether the packet really came from the upstream router, but that makes no difference in the processing of the packet. The upstream LSR will see its own upstream LSR in the label, and this will enable it to determine that the packet is traveling upstream.
接收数据包的其他LSR将无法判断数据包是否真的来自上游路由器，但这对数据包的处理没有影响。上游LSR将在标签中看到自己的上游LSR，这将使其能够确定数据包正在向上游移动。
The root node is a single point of failure for an MP LSP, whether the MP LSP is P2MP or MP2MP. The problem is particularly severe for MP2MP LSPs. In the case of MP2MP LSPs, all leaf nodes must use the same root node to set up the MP2MP LSP, because otherwise the traffic sourced by some leafs is not received by others. Because the root node is the single point of failure for an MP LSP, we need a fast and efficient mechanism to recover from a root node failure.
无论MP LSP是P2MP还是MP2MP，根节点都是MP LSP的单点故障。这个问题对于MP2MP LSP来说尤其严重。在MP2MP LSP的情况下，所有叶节点必须使用同一根节点来设置MP2MP LSP，因为其他叶节点无法接收来自某些叶节点的流量。因为根节点是MP LSP的单点故障，所以我们需要一种快速有效的机制来从根节点故障中恢复。
An MP LSP is uniquely identified in the network by the opaque value and the root node address. It is likely that the root node for an MP LSP will be defined statically. The root node address may be configured on each leaf statically or learned using a dynamic protocol. How leafs learn about the root node is out of the scope of this document.
MP LSP在网络中由不透明值和根节点地址唯一标识。MP LSP的根节点很可能是静态定义的。根节点地址可以静态地配置在每个叶上，或者使用动态协议学习。Leaf如何了解根节点超出了本文档的范围。
Suppose that for the same opaque value we define two (or more) root node addresses, and we build a tree to each root using the same opaque value. Effectively these will be treated as different MP LSPs in the network. Once the trees are built, the procedures differ for P2MP and MP2MP LSPs. The different procedures are explained in the sections below.
假设对于相同的不透明值，我们定义两个（或更多）根节点地址，并使用相同的不透明值为每个根构建一棵树。有效地，这些将被视为网络中的不同MP LSP。一旦树建立起来，P2MP和MP2MP LSP的程序就不同了。以下各节将解释不同的程序。
Since all leafs have set up P2MP LSPs to all the roots, they are prepared to receive packets on either one of these LSPs. However, only one of the roots should be forwarding traffic at any given time, for the following reasons: 1) to achieve bandwidth savings in the network and 2) to ensure that the receiving leafs don't receive duplicate packets (since one cannot assume that the receiving leafs are able to discard duplicates). How the roots determine which one is the active sender is outside the scope of this document.
由于所有leaf都为所有根设置了P2MP lsp，因此它们准备在这些lsp中的任何一个上接收数据包。但是，在任何给定的时间，只有一个根节点应该转发流量，原因如下：1）实现网络带宽节约，2）确保接收叶节点不接收重复数据包（因为不能假设接收叶节点能够丢弃重复数据包）。根如何确定哪一个是活动发件人超出了本文档的范围。
Since all leafs have set up an MP2MP LSP to each one of the root nodes for this opaque value, a sending leaf may pick either of the two (or more) MP2MP LSPs to forward a packet on. The leaf nodes receive the packet on one of the MP2MP LSPs. The client of the MP2MP LSP does not care on which MP2MP LSP the packet is received, as long as they are for the same opaque value. The sending leaf MUST only forward a packet on one MP2MP LSP at a given point in time. The receiving leafs are unable to discard duplicate packets because they accept on all LSPs. Using all the available MP2MP LSPs, we can implement redundancy using the following procedures.
由于所有叶子都为该不透明值向每个根节点设置了一个MP2MP LSP，因此发送叶子可以选择两个（或更多）MP2MP LSP中的任何一个来转发数据包。叶节点在其中一个MP2MP LSP上接收数据包。MP2MP LSP的客户机不关心在哪个MP2MP LSP上接收数据包，只要它们具有相同的不透明值。发送叶在给定时间点只能在一个MP2MP LSP上转发数据包。接收的LEAF无法丢弃重复的数据包，因为它们在所有LSP上都接受。使用所有可用的MP2MP LSP，我们可以使用以下步骤实现冗余。
A sending leaf selects a single root node out of the available roots for a given opaque value. A good strategy MAY be to look at the unicast routing table and select a root that is closest in terms of the unicast metric. As soon as the root address of the active root disappears from the unicast routing table (or becomes less attractive) due to root node or link failure, the leaf can select a new best root address and start forwarding to it directly. If multiple root nodes have the same unicast metric, the highest root node addresses MAY be selected, or per session load balancing MAY be done over the root nodes.
发送叶从给定不透明值的可用根中选择单个根节点。一个好的策略可能是查看单播路由表，并根据单播度量选择最接近的根。一旦活动根的根地址由于根节点或链路故障而从单播路由表中消失（或变得不那么吸引人），叶就可以选择一个新的最佳根地址并开始直接转发给它。如果多个根节点具有相同的单播度量，则可以选择最高的根节点地址，或者可以在根节点上进行每会话负载平衡。
All leafs participating in an MP2MP LSP MUST join all the available root nodes for a given opaque value. Since the sending leaf may pick any MP2MP LSP, it must be prepared to receive on it.
参与MP2MP LSP的所有叶必须为给定的不透明值连接所有可用的根节点。由于发送叶可以拾取任何MP2MP LSP，因此它必须准备在其上接收。
The advantage of pre-building multiple MP2MP LSPs for a single opaque value is that convergence from a root node failure happens as fast as
为单个不透明值预先构建多个MP2MP LSP的优点是，根节点故障导致的收敛速度尽可能快
the unicast routing protocol is able to notify. There is no need for an additional protocol to advertise to the leaf nodes which root node is the active root. The root selection is a local leaf policy that does not need to be coordinated with other leafs. The disadvantage of pre-building multiple MP2MP LSPs is that more label resources are used, depending on how many root nodes are defined.
单播路由协议能够通知。无需附加协议向叶节点播发哪个根节点是活动根。根选择是一种本地叶策略，不需要与其他叶进行协调。预构建多个MP2MP LSP的缺点是使用更多的标签资源，这取决于定义了多少根节点。
An LSR selects the LSR that is its next hop to the root of the LSP as its upstream LSR for an MP LSP. When the best path to reach the root changes, the LSR must choose a new upstream LSR. Sections 2.4.3 and 3.3.3 describe these procedures.
LSR选择LSP根的下一跳LSR作为MP LSP的上游LSR。当到达根的最佳路径发生变化时，LSR必须选择一个新的上游LSR。第2.4.3节和第3.3.3节描述了这些程序。
When the best path to the root changes, the LSP may be broken temporarily resulting in packet loss until the LSP "reconverges" to a new upstream LSR. The goal of MBB when this happens is to keep the duration of packet loss as short as possible. In addition, there are scenarios where the best path from the LSR to the root changes but the LSP continues to forward packets to the previous next hop to the root. That may occur when a link comes up or routing metrics change. In such a case, a new LSP should be established before the old LSP is removed to limit the duration of packet loss. The procedures described below deal with both scenarios in a way that an LSR does not need to know which of the events described above caused its upstream router for an MBB LSP to change.
当到根的最佳路径改变时，LSP可能暂时中断，导致分组丢失，直到LSP“重新聚合”到新的上游LSR。发生这种情况时，MBB的目标是使数据包丢失的持续时间尽可能短。此外，在一些场景中，从LSR到根的最佳路径发生变化，但LSP继续将数据包转发到根的上一个下一跳。当出现链接或路由度量更改时，可能会发生这种情况。在这种情况下，应在移除旧LSP之前建立新LSP以限制分组丢失的持续时间。下面描述的过程以LSR不需要知道上面描述的事件中的哪些导致其MBB LSP的上游路由器改变的方式处理这两种情形。
The MBB procedures are an optional extension to the MP LSP building procedures described in this document. The procedures in this section offer a make-before-break behavior, except in cases where the new path is part of a transient routing loop involving more than 2 LSRs (also see Section 4).
MBB程序是本文件所述MP LSP构建程序的可选扩展。本节中的程序提供先通后断行为，除非新路径是涉及2个以上LSR的瞬态路由循环的一部分（另请参见第4节）。
The MBB procedures use additional LDP signaling.
MBB过程使用额外的LDP信令。
Suppose some event causes a downstream LSR-D to select a new upstream LSR-U for FEC-A. The new LSR-U may already be forwarding packets for FEC-A; that is, to downstream LSRs other than LSR-D. After LSR-U receives a label for FEC-A from LSR-D, it will notify LSR-D when it knows that the LSP for FEC-A has been established from the root to itself. When LSR-D receives this MBB notification, it will change its next hop for the LSP root to LSR-U.
假设某个事件导致下游LSR-D为FEC-a选择新的上游LSR-U。新的LSR-U可能已经在为FEC-a转发分组；也就是说，发送到LSR-D以外的下游LSR。LSR-U从LSR-D接收到FEC-a标签后，当它知道FEC-a的LSP已从根到自身建立时，它将通知LSR-D。当LSR-D收到此MBB通知时，它将LSP根的下一个跃点更改为LSR-U。
The assumption is that if LSR-U has received an MBB notification from its upstream router for the FEC-A LSP and has installed forwarding state, the LSR is capable of forwarding packets on the LSP. At that
假设如果LSR-U已经从其上游路由器接收到针对FEC-A LSP的MBB通知并且已经安装了转发状态，则LSR能够在LSP上转发分组。在那
point LSR-U should signal LSR-D by means of an MBB notification that it has become part of the tree identified by FEC-A and that LSR-D should initiate its switchover to the LSP.
点LSR-U应通过MBB通知向LSR-D发送信号，告知其已成为FEC-A标识的树的一部分，并且LSR-D应启动其到LSP的切换。
At LSR-U, the LSP for FEC-A may be in 1 of 3 states.
在LSR-U处，FEC-A的LSP可以处于3种状态中的1种。
1. There is no state for FEC-A.
1. 没有FEC-A的状态。
2. State for FEC-A exists and LSR-U is waiting for MBB notification that the LSP from the root to it exists.
2. FEC-A的状态存在，并且LSR-U正在等待MBB通知，说明从根到它的LSP存在。
3. State for FEC-A exists and the MBB notification has been received or it is the root node for FEC-A.
3. FEC-A的状态存在，并且已收到MBB通知，或者它是FEC-A的根节点。
After LSR-U receives LSR-D's Label Mapping message for FEC-A, LSR-U MUST NOT reply with an MBB notification to LSR-D until its state for the LSP is state #3 above. If the state of the LSP at LSR-U is state #1 or #2, LSR-U should remember receipt of the Label Mapping message from LSR-D while waiting for an MBB notification from its upstream LSR for the LSP. When LSR-U receives the MBB notification from LSR-U, it transitions to LSP state #3 and sends an MBB notification to LSR-D.
在LSR-U收到LSR-D的FEC-A标签映射消息后，LSR-U不得向LSR-D回复MBB通知，直到其LSP状态为上述状态3。如果LSR-U处LSP的状态为状态#1或#2，则LSR-U在等待来自其上游LSR的针对LSP的MBB通知时，应记住从LSR-D接收到标签映射消息。当LSR-U从LSR-U接收到MBB通知时，它将转换到LSP状态#3并向LSR-D发送MBB通知。
As noted in Section 8.1, the procedures for establishing an MBB MP LSP are different from those for establishing normal MP LSPs.
如第8.1节所述，建立MBB MP LSP的程序与建立正常MP LSP的程序不同。
When a downstream LSR sends a Label Mapping message for MP LSP to its upstream LSR, it MAY include an LDP MP Status TLV that carries an MBB Status Code to indicate that MBB procedures apply to the LSP. This new MBB Status Code MAY also appear in an LDP Notification message used by an upstream LSR to signal LSP state #3 to the downstream LSR; that is, that the upstream LSRs state for the LSP exists and that it has received notification from its upstream LSR that the LSP is in state #3.
当下游LSR将MP-LSP的标签映射消息发送到其上游LSR时，它可以包括携带MBB状态码的LDP-MP-Status TLV，以指示MBB过程应用于LSP。这个新的MBB状态码也可以出现在由上游LSR使用的LDP通知消息中，以向下游LSR发送LSP状态#3的信号；也就是说，LSP的上游LSR状态存在，并且它已收到来自其上游LSR的LSP处于状态#3的通知。
The MBB Status is a type of the LDP MP Status Value Element as described in Section 5.1. It is encoded as follows:
MBB状态是一种LDP MP状态值元素，如第5.1节所述。其编码如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBB Type = 1 | Length = 1 | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBB Type = 1 | Length = 1 | Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBB Type: Type 1
MBB类型：类型1
Length: 1
长度：1
Status Code: 1 = MBB request
状态代码：1=MBB请求
2 = MBB ack
2 = MBB ack
An LSR MAY advertise that it is capable of handling MBB LSPs using the capability advertisement as defined in [RFC5561]. The LDP MP MBB capability has the following format:
LSR可以通告其能够使用[RFC5561]中定义的能力通告来处理MBB LSP。LDP MP MBB能力具有以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| LDP MP MBB Capability | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| LDP MP MBB Capability | Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
LDP MP MBB Capability: The MBB Capability Parameter (0x050A)
LDP MP MBB能力：MBB能力参数（0x050A）
S: As specified in [RFC5561]
S：按照[RFC5561]中的规定
If an LSR has not advertised that it is MBB capable, its LDP peers MUST NOT send it messages that include MBB parameters. If an LSR receives a Label Mapping message with an MBB parameter from downstream LSR-D and its upstream LSR-U has not advertised that it is MBB capable, the LSR MUST send an MBB notification immediately to LSR-U (see Section 8.4). If this happens, an MBB MP LSP will not be established, but a normal MP LSP will be the result.
如果LSR未公布其具有MBB能力，则其LDP对等方不得向其发送包含MBB参数的消息。如果LSR从下游LSR-D接收到带有MBB参数的标签映射消息，且其上游LSR-U未公布其具有MBB能力，则LSR必须立即向LSR-U发送MBB通知（见第8.4节）。如果发生这种情况，将不会建立MBB MP LSP，但结果将是正常的MP LSP。
1. MBB LSP <X, Y>: A P2MP or MP2MP Make Before Break (MBB) LSP entry with root node address X and opaque value Y.
1. MBB LSP<X，Y>：具有根节点地址X和不透明值Y的P2MP或MP2MP先通后断（MBB）LSP条目。
2. A(N, L): An accepting element that consists of an upstream neighbor N and Local label L. This LSR assigned label L to neighbor N for a specific MBB LSP. For an active element, the corresponding label is stored in the label forwarding database.
2. A（N，L）：由上游邻居N和本地标签L组成的接受元素。对于特定MBB LSP，该LSR将标签L分配给邻居N。对于活动元素，相应的标签存储在标签转发数据库中。
3. iA(N, L): An inactive accepting element that consists of an upstream neighbor N and local label L. This LSR assigned label L to neighbor N for a specific MBB LSP. For an inactive element,
3. iA（N，L）：由上游邻居N和本地标签L组成的非活动接受元素。该LSR将标签L分配给特定MBB LSP的邻居N。对于非活动元素，
the corresponding label is not stored in the label forwarding database.
相应的标签未存储在标签转发数据库中。
4. F(N, L): A Forwarding state that consists of downstream neighbor N and label L. This LSR is sending label packets with label L to neighbor N for a specific FEC.
4. F（N，L）：由下游邻居N和标签L组成的转发状态。该LSR将标签L的标签数据包发送到特定FEC的邻居N。
5. F'(N, L): A Forwarding state that has been marked for sending an MBB Notification message to neighbor N with label L.
5. F'（N，L）：一种转发状态，已标记为向标签为L的邻居N发送MBB通知消息。
6. MBB Notification <X, Y, L>: An LDP notification message with an MP LSP <X, Y>, label L, and MBB Status code 2.
6. MBB通知<X，Y，L>：具有MP LSP<X，Y>、标签L和MBB状态代码2的LDP通知消息。
7. MBB Label Mapping <X, Y, L>: A P2MP Label Mapping or MP2MP Label Mapping downstream with a FEC element <X, Y>, label L, and MBB Status code 1.
7. MBB标签映射<X，Y，L>：具有FEC元素<X，Y>、标签L和MBB状态代码1的P2MP标签映射或MP2MP标签映射下游。
An accepting element represents a specific label value L that has been advertised to a neighbor N for an MBB LSP <X, Y> and is a candidate for accepting labels switched packets on. An LSR can have two accepting elements for a specific MBB LSP <X, Y> LSP, only one of them MUST be active. An active element is the element for which the label value has been installed in the label forwarding database. An inactive accepting element is created after a new upstream LSR is chosen and replacement the active element in the label forwarding database is pending. Inactive elements only exist temporarily while switching to a new upstream LSR. Once the switch has been completed, only one active element remains. During network convergence, it is possible that an inactive accepting element is created while another inactive accepting element is pending. If that happens, the older inactive accepting element MUST be replaced with a newer inactive element. If an accepting element is removed, a Label Withdraw has to be sent for label L to neighbor N for <X, Y>.
接受元素表示已针对MBB LSP<X，Y>向邻居N通告的特定标签值L，并且是接受标签交换分组的候选。对于特定MBB LSP<X，Y>LSP，LSR可以有两个接受元件，其中只有一个必须处于活动状态。活动元素是已在标签转发数据库中为其安装标签值的元素。在选择了新的上游LSR并等待替换标签转发数据库中的活动元素后，将创建一个非活动接受元素。非活动元件仅在切换到新的上游LSR时暂时存在。切换完成后，只剩下一个激活元件。在网络融合期间，可能会创建一个非活动接受元素，而另一个非活动接受元素处于挂起状态。如果发生这种情况，则必须将旧的非活动接受元素替换为新的非活动元素。如果删除了接受元素，则必须将标签L的标签撤回发送给<X，Y>的邻居N。
Suppose a node Z has an MBB LSP <X, Y> with an active accepting element A(N1, L1). Due to a routing change, it detects a new best path for root X and selects a new upstream LSR N2. Node Z allocates a new local label L2 and creates an inactive accepting element iA(N2, L2). Node Z sends MBB Label Mapping <X, Y, L2> to N2 and waits for the new upstream LSR N2 to respond with an MBB Notification for <X, Y, L2>. During this transition phase, there are two accepting elements, the element A(N1, L1) still accepting packets from N1 over label L1 and the new inactive element iA(N2, L2).
假设节点Z具有一个MBB LSP<X，Y>，该MBB LSP具有一个活动的接受元素a（N1，L1）。由于路由更改，它检测到根X的新最佳路径，并选择新的上游LSR N2。节点Z分配一个新的本地标签L2，并创建一个非活动的接受元素iA（N2，L2）。节点Z将MBB标签映射<X，Y，L2>发送到N2，并等待新的上游LSR N2响应<X，Y，L2>的MBB通知。在这个转换阶段，有两个接受元素，元素A（N1，L1）仍然通过标签L1接受来自N1的包，而新的非活动元素iA（N2，L2）。
While waiting for the MBB Notification from upstream LSR N2, it is possible that another transition occurs due to a routing change. Suppose the new upstream LSR is N3. An inactive element iA(N3, L3) is created and the old inactive element iA(N2, L2) MUST be removed. A Label Withdraw MUST be sent to N2 for <X, Y, L2>. The MBB Notification for <X, Y, L2> from N2 will be ignored because the inactive element is removed.
在等待来自上游LSR N2的MBB通知时，可能由于路由更改而发生另一个转换。假设新的上游LSR为N3。将创建非活动元素iA（N3，L3），并且必须删除旧的非活动元素iA（N2，L2）。对于<X，Y，L2>，必须向N2发送标签提取。来自N2的<X，Y，L2>的MBB通知将被忽略，因为非活动元素已被删除。
It is possible that the MBB Notification from upstream LSR is never received due to link or node failure. To prevent waiting indefinitely for the MBB Notification, a timeout SHOULD be applied. As soon as the timer expires, the procedures in Section 8.4.5 are applied as if an MBB Notification was received for the inactive element. If a downstream LSR detects that the old upstream LSR went down while waiting for the MBB Notification from the new upstream LSR, the downstream LSR can immediately proceed without waiting for the timer to expire.
由于链路或节点故障，可能从未收到来自上游LSR的MBB通知。为防止无限期地等待MBB通知，应应用超时。计时器一到期，第8.4.5节中的程序即适用，如同收到非活动元件的MBB通知一样。如果下游LSR在等待来自新的上游LSR的MBB通知时检测到旧的上游LSR下降，则下游LSR可以立即继续而不等待计时器过期。
Suppose node Z has state for an MBB LSP <X, Y> and receives an MBB Label Mapping <X, Y, L2> from N2. A new forwarding state F(N2, L2) will be added to the MP LSP if it did not already exist. If this MBB LSP has an active accepting element or if node Z is the root of the MBB LSP, an MBB notification <X, Y, L2)> is sent to node N2. If node Z has an inactive accepting element, it marks the Forwarding state as <X, Y, F'(N2, L2)>. If the router Z upstream LSR for <X, Y> happens to be N2, then Z MUST NOT send an MBB notification to N2 at once. Sending the MBB notification to N2 must be done only after Z upstream for <X, Y> stops being N2.
假设节点Z具有MBB LSP<X，Y>的状态，并从N2接收MBB标签映射<X，Y，L2>。如果MP LSP不存在，将向其添加新的转发状态F（N2，L2）。如果该MBB LSP具有活动接受元素，或者如果节点Z是MBB LSP的根，则将MBB通知<X，Y，L2）>发送到节点N2。如果节点Z具有非活动接受元素，则它将转发状态标记为<X，Y，F'（N2，L2）>。如果<X，Y>的路由器Z上游LSR恰好是N2，那么Z不能立即向N2发送MBB通知。只有在<X，Y>的上游Z停止为N2之后，才能向N2发送MBB通知。
Suppose node Z receives an MBB Notification <X, Y, L> from N. If node Z has state for MBB LSP <X, Y> and an inactive accepting element iA(N, L) that matches with N and L, we activate this accepting element and install label L in the label-forwarding database. If another active accepting element was present, it will be removed from the label-forwarding database.
假设节点Z接收到来自N的MBB通知<X，Y，L>。如果节点Z具有MBB LSP<X，Y>的状态以及与N和L匹配的非活动接受元素iA（N，L），我们将激活该接受元素并在标签转发数据库中安装标签L。如果存在另一个活动的接受元素，则会将其从标签转发数据库中删除。
If this MBB LSP <X, Y> also has Forwarding states marked for sending MBB Notifications, like <X, Y, F'(N2, L2)>, MBB Notifications are sent to these downstream LSRs. If node Z receives an MBB Notification for an accepting element that is not inactive or does not match the label value and neighbor address, the MBB notification is ignored.
如果此MBB LSP<X，Y>还具有标记为发送MBB通知的转发状态，如<X，Y，F'（N2，L2）>，则将MBB通知发送到这些下游lsr。如果节点Z接收到接受元素的MBB通知，该接受元素不是非活动的或与标签值和邻居地址不匹配，则MBB通知将被忽略。
The procedures described above apply to the downstream path of an MP2MP LSP. The upstream path of the MP2MP is set up as normal without including an MBB Status code. If the MBB procedures apply to an MP2MP downstream FEC element, the upstream path to a node N is only installed in the label-forwarding database if node N is part of the active accepting element. If node N is part of an inactive accepting element, the upstream path is installed when this inactive accepting element is activated.
上述程序适用于MP2MP LSP的下游路径。MP2MP的上游路径设置正常，不包括MBB状态代码。如果MBB过程适用于MP2MP下游FEC元件，则只有当节点N是活动接受元件的一部分时，节点N的上游路径才安装在标签转发数据库中。如果节点N是非活动接受元素的一部分，则在激活该非活动接受元素时安装上游路径。
The format of the mLDP FEC Typed Wildcard FEC is as follows:
mLDP FEC类型通配符FEC的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed Wcard | Type | Len = 2 | AFI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Typed Wcard | Type | Len = 2 | AFI ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+
Typed Wcard: As specified in [RFC5918]
键入的Wcard：如[RFC5918]中所述
Type: The type of FEC Element Type. Either the P2MP FEC Element or the MP2MP FEC Element using the values defined for those FEC Elements when carried in the FEC TLV as defined in this document.
类型：FEC元素类型的类型。P2MP FEC元件或MP2MP FEC元件，使用本文件中定义的FEC TLV携带时为这些FEC元件定义的值。
Len: Len FEC Type Info, two octets (=0x02).
Len:Len FEC类型信息，两个八位字节（=0x02）。
AFI: Address Family, two-octet quantity containing a value from IANA's "Address Family Numbers" registry.
AFI：地址族，包含IANA“地址族编号”注册表中值的两个八位组数量。
The same security considerations apply as those for the base LDP specification, as described in [RFC5036].
与[RFC5036]中所述的基本LDP规范的安全注意事项相同。
The protocol specified in this document does not provide any authorization mechanism for controlling the set of LSRs that may join a given MP LSP. If such authorization is desirable, additional mechanisms, outside the scope of this document, are needed. Note that authorization policies cannot be implemented and/or configured solely at the root node of the LSP, because the root node does not learn the identities of all the leaf nodes.
本文档中指定的协议不提供任何授权机制来控制可能加入给定MP LSP的LSR集。如果需要此类授权，则需要本文件范围之外的其他机制。请注意，授权策略不能仅在LSP的根节点上实现和/或配置，因为根节点不会学习所有叶节点的标识。
Per this document, IANA has created 3 new registries.
根据本文件，IANA创建了3个新的注册中心。
1. "LDP MP Opaque Value Element basic type"
1. “LDP MP不透明值元素基本类型”
The range is 0-255, with the following values allocated in this document:
范围为0-255，在此文档中分配了以下值：
0: Reserved
0:保留
1: Generic LSP identifier
1：通用LSP标识符
255: Extended Type field is present in the following two bytes
255:扩展类型字段在以下两个字节中
The allocation policy for this space is 'Standards Action with Early Allocation'.
此空间的分配策略为“提前分配的标准行动”。
2. "LDP MP Opaque Value Element extended type"
2. “LDP MP不透明值元素扩展类型”
The range is 0-65535, with the following allocation policies:
范围为0-65535，具有以下分配策略：
0-32767: Standards Action with Early Allocation
0-32767：具有早期分配的标准操作
32768-65535: First Come, First Served
32768-65535：先到先得
3. "LDP MP Status Value Element type"
3. “LDP MP状态值元素类型”
The range is 0-255, with the following values allocated in this document:
范围为0-255，在此文档中分配了以下值：
0: Reserved
0:保留
1: MBB Status
1:MBB状态
The allocation policy for this space is 'Standards Action with Early Allocation'.
此空间的分配策略为“提前分配的标准行动”。
The code point values listed below have been allocated by IANA through early allocation.
IANA已通过早期分配分配下列代码点值。
IANA allocated three new code points from the LDP registry "Forwarding Equivalence Class (FEC) Type Name Space". The values are:
IANA从LDP注册表“转发等价类（FEC）类型名称空间”中分配了三个新代码点。这些数值是：
P2MP FEC type - requested value 0x06
P2MP FEC类型-请求的值0x06
MP2MP-up FEC type - requested value 0x07
MP2MP up FEC类型-请求的值0x07
MP2MP-down FEC type - requested value 0x08
MP2MP下行FEC类型-请求的值0x08
IANA assigned three new code points for new Capability Parameter TLVs from the LDP registry "TLV Type Name Space", corresponding to the advertisement of the P2MP, MP2MP, and MBB capabilities. The values are:
IANA为LDP注册表“TLV类型名称空间”中的新功能参数TLV分配了三个新代码点，对应于P2MP、MP2MP和MBB功能的公布。这些数值是：
P2MP Capability Parameter - 0x0508
P2MP能力参数-0x0508
MP2MP Capability Parameter - 0x0509
MP2MP能力参数-0x0509
MBB Capability Parameter - 0x050A
MBB能力参数-0x050A
IANA assigned an LDP Status Code to indicate that an LDP MP Status TLV is following in the Notification message. The value assigned in the LDP registry "LDP Status Code Name Space" is:
IANA分配了LDP状态码，以指示通知消息中的LDP MP状态TLV如下。在LDP注册表“LDP状态代码名称空间”中分配的值为：
LDP MP status - requested value 0x00000040
LDP MP状态-请求的值0x00000040
IANA assigned a new code point for an LDP MP Status TLV. The value assigned in the LDP registry "LDP TLV Type Name Space" is:
IANA为LDP MP状态TLV分配了一个新的代码点。在LDP注册表“LDP TLV类型名称空间”中分配的值为：
LDP MP Status TLV Type - requested value 0x096F
LDP MP状态TLV类型-请求值0x096F
The authors would like to thank the following individuals for their review and contribution: Nischal Sheth, Yakov Rekhter, Rahul Aggarwal, Arjen Boers, Eric Rosen, Nidhi Bhaskar, Toerless Eckert, George Swallow, Jin Lizhong, Vanson Lim, Adrian Farrel, Thomas Morin and Ben Niven-Jenkins.
作者感谢以下个人的评论和贡献：Nischal Sheth、Yakov Rekhter、Rahul Aggarwal、Arjen Boers、Eric Rosen、Nidhi Bhaskar、Toerless Eckert、George Swallow、Jin Lizhong、Vanson Lim、Adrian Farrel、Thomas Morin和Ben Niven Jenkins。
Below is a list of the contributing authors in alphabetical order:
以下是按字母顺序排列的投稿作者名单：
Shane Amante Level 3 Communications, LLC 1025 Eldorado Blvd Broomfield, CO 80021 US EMail: Shane.Amante@Level3.com
美国科罗拉多州布鲁姆菲尔德埃尔多拉多大道1025号Shane Amante三级通信有限责任公司80021电子邮件：Shane。Amante@Level3.com
Luyuan Fang Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 US EMail: lufang@cisco.com
卢元芳思科系统美国马萨诸塞州伯斯堡市比弗布鲁克路300号01719电子邮件：lufang@cisco.com
Hitoshi Fukuda NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019, Japan EMail: hitoshi.fukuda@ntt.com
日本东京千代田区内井町福田NTT通信公司1-1-6，邮编：100-8019，电子邮件：Hitoshi。fukuda@ntt.com
Yuji Kamite NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan EMail: y.kamite@ntt.com
Yuji Kamite NTT通信公司东京歌剧城3-20-2号楼，新宿，新宿，东京163-1421，电子邮件：y。kamite@ntt.com
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: kireeti@juniper.net
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，CA 94089美国电子邮件：kireeti@juniper.net
Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin Lannion, Cedex 22307 France EMail: jeanlouis.leroux@francetelecom.com
Jean-Louis Le Roux法国电信2号，皮埃尔·马津·拉尼翁大道，Cedex 22307法国电子邮件：jeanlouis。leroux@francetelecom.com
Ina Minei Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: ina@juniper.net
Ina Minei Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，CA 94089美国电子邮件：ina@juniper.net
Bob Thomas Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA, 01719 EMail: bobthomas@alum.mit.edu
Bob Thomas Cisco Systems，Inc.马萨诸塞州Boxborough市比弗布鲁克路300号01719电子邮件：bobthomas@alum.mit.edu
Lei Wang Telenor Snaroyveien 30 Fornebu 1331 Norway EMail: lei.wang@telenor.com
Lei Wang Telenor Snaroyveien 30 for Nebu 1331挪威电子邮件：Lei。wang@telenor.com
IJsbrand Wijnands Cisco Systems, Inc. De kleetlaan 6a 1831 Diegem Belgium EMail: ice@cisco.com
IJsbrand Wijlands Cisco Systems，Inc.De kleetlaan 6a 1831 Diegem比利时电子邮件：ice@cisco.com
[ITU.V42.1994] International Telecommunications Union, "Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion", ITU-T Recommendation V.42, 1994. http://www.itu.int/rec/T-REC-V.42-200203-I
[ITU.V42.1994]国际电信联盟，“使用异步到同步转换的DCE纠错程序”，ITU-T建议V.421994。http://www.itu.int/rec/T-REC-V.42-200203-I
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008.
[RFC5331]Aggarwal，R.，Rekhter，Y.，和E.Rosen，“MPLS上游标签分配和上下文特定标签空间”，RFC 53312008年8月。
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5561]托马斯，B.，拉扎，K.，阿加瓦尔，S.，阿加瓦尔，R.，和JL。Le Roux，“LDP能力”，RFC 55612009年7月。
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August 2010.
[RFC5918]Asati，R.，Minei，I.，和B.Thomas，“标签分发协议（LDP）“类型通配符”前向等价类（FEC）”，RFC 59182010年8月。
[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, September 2011.
[RFC6389]阿加瓦尔，R.和JL。Le Roux，“LDP的MPLS上游标签分配”，RFC 6389，2011年9月。
[ISO3309] International Organization for Standardization, "ISO Information Processing Systems - Data Communication - High-Level Data Link Control Procedure - Frame Structure", ISO 3309, 3rd Edition, October 1984.
[ISO3309]国际标准化组织，“ISO信息处理系统-数据通信-高级数据链路控制程序-框架结构”，ISO 3309，第3版，1984年10月。
[L3VPN-MCAST] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", Work in Progress, January 2010.
[L3VPN-MCAST]Rosen，E.，Ed.，和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，正在进行的工作，2010年1月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[RFC3813]Srinivasan，C.，Viswanathan，A.，和T.Nadeau，“多协议标签交换（MPLS）标签交换路由器（LSR）管理信息库（MIB）”，RFC 38132004年6月。
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[RFC3815]Cucchiara，J.，Sjostrand，H.，和J.Luciani，“多协议标签交换（MPLS）管理对象的定义，标签分发协议（LDP）”，RFC 3815，2004年6月。
[RFC4875] 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.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332]Eckert，T.，Rosen，E.，Ed.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，2008年8月。
[RFC6348] Le Roux, J., Ed., and T. Morin, Ed., "Requirements for Point-to-Multipoint Extensions to the Label Distribution Protocol", RFC 6348, September 2011.
[RFC6348]Le Roux，J.，Ed.，和T.Morin，Ed.，“标签分发协议的点对多点扩展要求”，RFC 6348，2011年9月。
Authors' Addresses
作者地址
IJsbrand Wijnands (editor) Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium EMail: ice@cisco.com
IJsbrand Wijnands（编辑）Cisco Systems，Inc.De kleetlaan 6a Diegem 1831比利时电子邮件：ice@cisco.com
Ina Minei (editor) Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: ina@juniper.net
Ina Minei（编辑）Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，CA 94089美国电子邮件：ina@juniper.net
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US EMail: kireeti@juniper.net
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，CA 94089美国电子邮件：kireeti@juniper.net
Bob Thomas 300 Beaver Brook Road Boxborough 01719 US EMail: bobthomas@alum.mit.edu
Bob Thomas 300 Beaver Brook Road Boxborough 01719美国电子邮件：bobthomas@alum.mit.edu