Internet Engineering Task Force (IETF) L. Jin
Request for Comments: 7140
Category: Standards Track F. Jounay
ISSN: 2070-1721 Orange CH
IJ. Wijnands
Cisco Systems, Inc
N. Leymann
Deutsche Telekom AG
March 2014
Internet Engineering Task Force (IETF) L. Jin
Request for Comments: 7140
Category: Standards Track F. Jounay
ISSN: 2070-1721 Orange CH
IJ. Wijnands
Cisco Systems, Inc
N. Leymann
Deutsche Telekom AG
March 2014
LDP Extensions for Hub and Spoke Multipoint Label Switched Path
中心辐射多点标签交换路径的LDP扩展
Abstract
摘要
This document introduces a hub and spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed.
本文档介绍了一种中心辐射多点（HSMP）标签交换路径（LSP），它允许通过点对多点（P2MP）LSP从根到叶的通信，也允许沿反向路径从叶到根的通信。这意味着从根节点处的应用程序/客户进入HSMP LSP的流量向下移动到每个叶节点，就像它沿着P2MP LSP向下移动到每个叶节点一样。在任何叶节点处进入HSMP 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/rfc7140.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7140.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Setting Up HSMP LSP with LDP . . . . . . . . . . . . . . . . 4
3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 4
3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5
3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 5
3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . 6
3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . 7
3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 7
3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . 8
3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 9
3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 9
3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 9
3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . 10
3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . 10
3.7. Determining Forwarding Interface . . . . . . . . . . . . 10
4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 11
5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11
6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. New LDP FEC Element Types . . . . . . . . . . . . . . . . 12
8.2. HSMP LSP Capability TLV . . . . . . . . . . . . . . . . . 13
8.3. New Sub-TLVs for the Target Stack TLV . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Setting Up HSMP LSP with LDP . . . . . . . . . . . . . . . . 4
3.1. Support for HSMP LSP Setup with LDP . . . . . . . . . . . 4
3.2. HSMP FEC Elements . . . . . . . . . . . . . . . . . . . . 5
3.3. Using the HSMP FEC Elements . . . . . . . . . . . . . . . 5
3.4. HSMP LSP Label Map . . . . . . . . . . . . . . . . . . . 6
3.4.1. HSMP LSP Leaf Node Operation . . . . . . . . . . . . 7
3.4.2. HSMP LSP Transit Node Operation . . . . . . . . . . . 7
3.4.3. HSMP LSP Root Node Operation . . . . . . . . . . . . 8
3.5. HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 9
3.5.1. HSMP Leaf Operation . . . . . . . . . . . . . . . . . 9
3.5.2. HSMP Transit Node Operation . . . . . . . . . . . . . 9
3.5.3. HSMP Root Node Operation . . . . . . . . . . . . . . 10
3.6. HSMP LSP Upstream LSR Change . . . . . . . . . . . . . . 10
3.7. Determining Forwarding Interface . . . . . . . . . . . . 10
4. HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . . 11
5. Redundancy Considerations . . . . . . . . . . . . . . . . . . 11
6. Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. New LDP FEC Element Types . . . . . . . . . . . . . . . . 12
8.2. HSMP LSP Capability TLV . . . . . . . . . . . . . . . . . 13
8.3. New Sub-TLVs for the Target Stack TLV . . . . . . . . . . 13
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14
The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in [RFC6388] allows traffic to transmit from root to several leaf nodes, and multipoint-to-multipoint (MP2MP) LSP allows traffic from every node to transmit to every other node. This document introduces a hub and spoke multipoint (HSMP) LSP, which has one root node and one or more leaf nodes. An HSMP LSP allows traffic from root to leaf through downstream LSP and also leaf to root along the upstream LSP. That means traffic entering the HSMP LSP at the root node travels along the downstream LSP, exactly as if it were traveling along a P2MP LSP, and traffic entering the HSMP LSP at any other leaf nodes travels along the upstream LSP toward only the root node. The upstream LSP should be thought of as a unicast LSP to the root node, except that it follows the reverse direction of the downstream LSP, rather than the unicast path based on the routing protocol. The combination of upstream LSPs initiated from all leaf nodes forms a multipoint-to-point LSP.
[RFC6388]中定义的点对多点（P2MP）标签交换路径（LSP）允许流量从根节点传输到多个叶节点，而多点对多点（MP2MP）LSP允许流量从每个节点传输到其他节点。本文档介绍了一个中心辐射多点（HSMP）LSP，它有一个根节点和一个或多个叶节点。HSMP LSP允许从根到叶的流量通过下游LSP，也允许沿上游LSP从叶到根的流量。这意味着在根节点处进入HSMP LSP的流量沿着下游LSP移动，就像它沿着P2MP LSP移动一样，并且在任何其他叶节点处进入HSMP LSP的流量沿着上游LSP仅向根节点移动。上游LSP应该被认为是到根节点的单播LSP，除了它遵循下游LSP的相反方向，而不是基于路由协议的单播路径。从所有叶节点发起的上游LSP的组合形成多点对点LSP。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the following terms and acronyms:
本文件使用以下术语和首字母缩略词：
mLDP: Multipoint extensions for Label Distribution Protocol (LDP) defined in [RFC6388].
mLDP:RFC6388中定义的标签分发协议（LDP）的多点扩展。
P2MP LSP: point-to-multipoint Label Switched Path. An LSP that has one Ingress Label Switching Router (LSR) and one or more Egress LSRs.
P2MP LSP：点对多点标签交换路径。具有一个入口标签交换路由器（LSR）和一个或多个出口LSR的LSP。
MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP 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中的任何节点发送的通信量都传递给所有其他节点。
HSMP LSP: hub and spoke multipoint Label Switched Path. An LSP that has one root node and one or more leaf nodes, allows traffic from the root to all leaf nodes along the downstream P2MP LSP and also leaf to root node along the upstream unicast LSP.
HSMP LSP：中心辐射多点标签交换路径。具有一个根节点和一个或多个叶节点的LSP允许沿下游P2MP LSP从根节点到所有叶节点的通信量，以及沿上游单播LSP从叶到根节点的通信量。
FEC: Forwarding Equivalence Class
转发等价类
An HSMP LSP is similar to MP2MP LSP described in [RFC6388], with the difference being that, when the leaf LSRs send traffic on the LSP, the traffic is first delivered only to the root node and follows the upstream path from the leaf node to the root node. The root node then distributes the traffic on the P2MP tree to all of the leaf nodes.
HSMP LSP类似于[RFC6388]中描述的MP2MP LSP，不同之处在于，当叶LSR在LSP上发送流量时，流量首先仅发送到根节点，并遵循从叶节点到根节点的上游路径。然后，根节点将P2MP树上的流量分配给所有叶节点。
An HSMP LSP consists of a downstream path and upstream path. The downstream path is the same as P2MP LSP, while the upstream path is only from leaf to root node, without communication between the leaf nodes themselves. The transmission of packets from the root node of an HSMP LSP to the receivers (the leaf nodes) is identical to that of a P2MP LSP. Traffic from a leaf node to the root follows the upstream path that is the reverse of the path from the root to the leaf. Unlike an MP2MP LSP, traffic from a leaf node does not branch toward other leaf nodes, but it is sent direct to the root where it is placed on the P2MP path and distributed to all leaf nodes including the original sender.
HSMP LSP由下游路径和上游路径组成。下游路径与P2MP LSP相同，而上游路径仅从叶节点到根节点，叶节点之间没有通信。从HSMP LSP的根节点到接收器（叶节点）的分组传输与P2MP LSP的相同。从叶节点到根节点的流量遵循上游路径，该路径与从根节点到叶节点的路径相反。与MP2MP LSP不同，来自叶节点的流量不会分支到其他叶节点，而是直接发送到根节点，在根节点上它位于P2MP路径上，并分布到包括原始发送方在内的所有叶节点。
To set up the upstream path of an HSMP LSP, ordered mode MUST be used. Ordered mode can guarantee that a leaf will start sending packets to the root immediately after the upstream path is installed, without being dropped due to an incomplete LSP.
要设置HSMP LSP的上游路径，必须使用有序模式。有序模式可以保证在安装上行路径后，叶将立即开始向根发送数据包，而不会因为LSP不完整而被丢弃。
An HSMP LSP requires the LDP capabilities [RFC5561] for nodes to indicate that they support setup of HSMP LSPs. An implementation supporting the HSMP LSP procedures specified in this document MUST implement the procedures for Capability Parameters in Initialization messages. Advertisement of the HSMP LSP Capability indicates support of the procedures for HSMP LSP setup.
HSMP LSP要求节点具有LDP功能[RFC5561]，以表明它们支持HSMP LSP的设置。支持本文件中规定的HSMP LSP程序的实施必须实施初始化消息中的能力参数程序。HSMP LSP功能的公告表示支持HSMP LSP设置程序。
A new Capability Parameter TLV is defined, the HSMP LSP Capability Parameter. Below is the format of the HSMP LSP Capability Parameter.
定义了一个新的能力参数TLV，即HSMP LSP能力参数。以下是HSMP LSP能力参数的格式。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| HSMP LSP Cap (0x0902) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| HSMP LSP Cap (0x0902) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
Figure 1: HSMP LSP Capability Parameter Encoding
图1:HSMP LSP能力参数编码
U-bit: Unknown TLV bit, as described in [RFC5036]. The value MUST be 1. The unknown TLV MUST be silently ignored and the rest of the message processed as if the unknown TLV did not exist.
U位：未知TLV位，如[RFC5036]中所述。该值必须为1。必须以静默方式忽略未知TLV，并像未知TLV不存在一样处理消息的其余部分。
F-bit: Forward unknown TLV bit, as described in [RFC5036]. The value of this bit MUST be 0 since a Capability Parameter TLV is sent only in Initialization and Capability messages, which are not forwarded.
F位：转发未知TLV位，如[RFC5036]中所述。此位的值必须为0，因为功能参数TLV仅在初始化和功能消息中发送，而不会转发。
Length: SHOULD be 1.
长度：应为1。
S-bit: As defined in Section 3 of [RFC5561].
S位：如[RFC5561]第3节所定义。
Reserved: As defined in Section 3 of [RFC5561].
保留：如[RFC5561]第3节所定义。
HSMP LSP Capability Parameter type: 0x0902.
HSMP LSP能力参数类型：0x0902。
If the peer has not advertised the corresponding capability, then label messages using the HSMP Forwarding Equivalence Class (FEC) Element SHOULD NOT be sent to the peer (as described in Section 2.1 of [RFC6388]). Since ordered mode is applied for HSMP LSP signaling, the label message break would ensure that the initiating leaf node is unable to establish the upstream path to root node.
如果对等方未公布相应的能力，则不应将使用HSMP转发等价类（FEC）元素的标签消息发送给对等方（如[RFC6388]第2.1节所述）。由于HSMP LSP信令采用有序模式，标签消息中断将确保发起的叶节点无法建立到根节点的上行路径。
We define two new protocol entities: the HSMP Downstream FEC Element and Upstream FEC Element. If a FEC TLV contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be the only FEC Element in the FEC TLV. The structure, encoding, and error handling for the HSMP-downstream FEC Element and HSMP-upstream FEC Element are the same as for the P2MP FEC Element described in Section 2.2 of [RFC6388]. The difference is that two additional new FEC types are defined: HSMP-downstream FEC (10) and HSMP-upstream FEC (9).
我们定义了两个新的协议实体：HSMP下游FEC元素和上游FEC元素。如果FEC TLV包含一个HSMP FEC元素，则HSMP FEC元素必须是FEC TLV中唯一的FEC元素。HSMP下游FEC元素和HSMP上游FEC元素的结构、编码和错误处理与[RFC6388]第2.2节中描述的P2MP FEC元素相同。区别在于定义了另外两种新的FEC类型：HSMP下游FEC（10）和HSMP上游FEC（9）。
The entries in the list below describe the processing of the HSMP FEC Elements. Additionally, the entries defined in Section 3.3 of [RFC6388] are also reused in the following sections.
下面列表中的条目描述了HSMP FEC元素的处理。此外，[RFC6388]第3.3节中定义的条目也在以下章节中重复使用。
1. HSMP downstream LSP <X, Y> (or simply downstream <X, Y>): an HSMP LSP downstream path with root node address X and opaque value Y.
1. HSMP下游LSP<X，Y>（或简称下游<X，Y>）：具有根节点地址X和不透明值Y的HSMP LSP下游路径。
2. HSMP upstream LSP <X, Y> (or simply upstream <X, Y>): an HSMP LSP upstream path for root node address X and opaque value Y that will be used by any downstream node to send traffic upstream to root node.
2. HSMP上游LSP<X，Y>（或简称上游<X，Y>）：根节点地址X和不透明值Y的HSMP LSP上游路径，任何下游节点将使用该路径向根节点上游发送流量。
3. HSMP-downstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y used for a downstream HSMP LSP.
3. HSMP下游FEC元素<X，Y>：具有根节点地址X和不透明值Y的FEC元素，用于下游HSMP LSP。
4. HSMP-upstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y used for an upstream HSMP LSP.
4. HSMP上游FEC元素<X，Y>：具有根节点地址X和不透明值Y的FEC元素，用于上游HSMP LSP。
5. HSMP-D Label Mapping <X, Y, L>: A Label Mapping message with a single HSMP-downstream FEC Element <X, Y> and label TLV with label L. Label L MUST be allocated from the per-platform label space of the LSR sending the Label Mapping Message.
5. HSMP-D标签映射<X，Y，L>：带有单个HSMP下游FEC元素<X，Y>的标签映射消息和带有标签L的标签TLV。必须从发送标签映射消息的LSR的每个平台标签空间分配标签L。
6. HSMP-U Label Mapping <X, Y, Lu>: A Label Mapping message with a single HSMP upstream FEC Element <X, Y> and label TLV with label Lu. Label Lu MUST be allocated from the per-platform label space of the LSR sending the Label Mapping Message.
6. HSMP-U标签映射<X，Y，Lu>：带有单个HSMP上游FEC元素<X，Y>和带有标签Lu的标签TLV的标签映射消息。必须从发送标签映射消息的LSR的每个平台标签空间分配标签Lu。
7. HSMP-D Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC TLV with a single HSMP-downstream FEC Element <X, Y> and label TLV with label L.
7. HSMP-D标签撤销<X，Y，L>：带有FEC TLV的标签撤销消息，带有单个HSMP下游FEC元素<X，Y>，以及带有标签L的标签TLV。
8. HSMP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with a FEC TLV with a single HSMP-upstream FEC Element <X, Y> and label TLV with label Lu.
8. HSMP-U标签撤销<X，Y，Lu>：带有FEC TLV的标签撤销消息，带有单个HSMP上游FEC元素<X，Y>，以及带有标签Lu的标签TLV。
9. HSMP-D Label Release <X, Y, L>: a Label Release message with a FEC TLV with a single HSMP-downstream FEC Element <X, Y> and Label TLV with label L.
9. HSMP-D标签释放<X，Y，L>：带有FEC TLV的标签释放消息，带有单个HSMP下游FEC元素<X，Y>，以及带有标签L的标签TLV。
10. HSMP-U Label Release <X, Y, Lu>: a Label Release message with a FEC TLV with a single HSMP-upstream FEC Element <X, Y> and label TLV with label Lu.
10. HSMP-U标签发布<X，Y，Lu>：带有FEC TLV的标签发布消息，带有单个HSMP上游FEC元素<X，Y>，以及带有标签Lu的标签TLV。
This section specifies the procedures for originating HSMP Label Mapping messages and processing received HSMP Label Mapping messages for a particular HSMP LSP. The procedure of a downstream HSMP LSP is similar to that of a downstream MP2MP LSP described in [RFC6388]. When LDP operates in Ordered Label Distribution Control mode [RFC5036], the upstream LSP will be set up by sending an HSMP LSP LDP Label Mapping message with a label that is allocated by the upstream LSR to its downstream LSR hop-by-hop from root to leaf node, installing the upstream forwarding table by every node along the LSP.
本节规定了针对特定HSMP LSP发起HSMP标签映射消息和处理接收到的HSMP标签映射消息的过程。下游HSMP LSP的程序类似于[RFC6388]中所述的下游MP2MP LSP的程序。当LDP在有序标签分发控制模式[RFC5036]下运行时，将通过发送HSMP LSP LDP标签映射消息来建立上游LSP，该消息具有由上游LSR从根节点到叶节点逐跳分配到其下游LSR的标签，并通过LSP上的每个节点安装上游转发表。
The detailed procedure of setting up upstream HSMP LSP is different than that of upstream MP2MP LSP, and it is specified in the remainder of this section.
设置上游HSMP LSP的详细程序不同于上游MP2MP LSP的详细程序，在本节剩余部分中有详细说明。
All labels discussed here are downstream-assigned [RFC5332] except those that are assigned using the procedures described in Section 4.
此处讨论的所有标签均为下游分配[RFC5332]，使用第4节所述程序分配的标签除外。
Determining the upstream LSR for the HSMP LSP <X, Y> follows the procedure for a P2MP LSP described in Section 2.4.1.1 of [RFC6388]. That is, a node Z that wants to join an HSMP 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 are multiple upstream LSRs, a local algorithm should be applied to ensure that there is exactly one upstream LSR for a particular LSP.
按照[RFC6388]第2.4.1.1节中描述的P2MP LSP程序确定HSMP LSP<X，Y>的上游LSR。也就是说，想要加入HSMP LSP<X，Y>的节点Z确定LDP对等方U，该LDP对等方U是Z在从Z到根节点X的最佳路径上的下一跳。如果存在多个上游LSR，则应应用本地算法以确保特定LSP恰好存在一个上游LSR。
To determine one's HSMP downstream LSR, an upstream LDP peer that receives a Label Mapping with the HSMP-downstream FEC Element from an LDP peer D will treat D as HSMP downstream LDP peer.
为了确定一个人的HSMP下游LSR，从LDP对等方D接收带有HSMP下游FEC元素的标签映射的上游LDP对等方将把D视为HSMP下游LDP对等方。
The leaf node operation is much the same as the operation of MP2MP LSP defined in Section 3.3.1.4 of [RFC6388]. The only difference is the FEC elements as specified below.
叶节点操作与[RFC6388]第3.3.1.4节中定义的MP2MP LSP的操作基本相同。唯一的区别是下面指定的FEC元素。
A leaf node Z of an HSMP LSP <X, Y> determines its upstream LSR U for <X, Y> as per Section 3.3, allocates a label L, and sends an HSMP-D Label Mapping <X, Y, L> to U. Leaf node Z expects an HSMP-U Label Mapping <X, Y, Lu> from node U and 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 HSMP LSP. How it determines what traffic to forward on this HSMP LSP is outside the scope of this document.
HSMP LSP<X，Y>的叶节点Z根据第3.3节确定其<X，Y>的上游LSR U，分配标签L，并向U发送HSMP-D标签映射<X，Y，L>。叶节点Z期望节点U发送HSMP-U标签映射<X，Y，Lu>，并检查其是否已经具有上游<X，Y>的转发状态。如果不是，Z创建转发状态，将标签Lu推送到Z希望通过HSMP LSP转发的流量上。它如何确定要在此HSMP LSP上转发的流量超出了本文档的范围。
The procedure for processing an HSMP-D Label Mapping message is much the same as that for an MP2MP-D Label Mapping message defined in Section 3.3.1.5 of [RFC6388]. The processing of an HSMP-U Label Mapping message is different from that of an MP2MP-U Label Mapping message as specified below.
处理HSMP-D标签映射消息的程序与[RFC6388]第3.3.1.5节中定义的MP2MP-D标签映射消息的程序大致相同。HSMP-U标签映射消息的处理与MP2MP-U标签映射消息的处理不同，如下所述。
Suppose node Z receives an HSMP-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. 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
假设节点Z从lsrd接收到HSMP-D标签映射<X，Y，L>。Z检查其是否具有下游<X，Y>的转发状态。如果不是，则Z根据第3.3节确定其上游LSR U的<X，Y>。只要LSR D等于LSR U，就不能使用此标签映射更新标签转发表。如果LSR U不同于LSR D，Z将分配标签L'并安装
downstream forwarding state to swap label L' with label L over interface I associated with LSR D and send an HSMP-D Label Mapping <X, Y, L'> to U. Interface I is determined via the procedures in Section 3.7.
下游转发状态，通过与LSR D相关联的接口I交换标签L'和标签L，并向U接口I发送HSMP-D标签映射<X，Y，L'>。通过第3.7节中的程序确定。
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 the upstream LSR U already has assigned a label Lu to upstream <X, Y>. If not, transit node Z waits until it receives an HSMP-U Label Mapping <X, Y, Lu> from LSR U. Once the HSMP-U Label Mapping is received from LSR U, node Z checks whether it already has forwarding state upstream <X, Y> with incoming label Lu' and outgoing label Lu. 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 3.7. Node Z determines the downstream HSMP LSR as per Section 3.4 and sends an HSMP-U Label Mapping <X, Y, Lu'> to node D.
节点Z检查上游LSR U是否已经将标签Lu分配给上游<X，Y>。如果没有，中转节点Z将等待，直到它从LSR U接收到HSMP-U标签映射<X，Y，Lu>。一旦从LSR U接收到HSMP-U标签映射，节点Z将检查它是否已经具有上游转发状态<X，Y>，以及传入标签Lu'和传出标签Lu。如果没有，它将分配一个标签Lu'并在接口Iu上为带有标签Lu的Lu'创建一个新的标签交换。接口Iu通过第3.7节中的程序确定。节点Z根据第3.4节确定下游HSMP LSR，并向节点D发送HSMP-U标签映射<X，Y，Lu'>。
Since a packet from any downstream node is forwarded only to the upstream node, the same label (representing the upstream path) SHOULD be distributed to all downstream nodes. This differs from the procedures for MP2MP LSPs [RFC6388], where a distinct label must be distributed to each downstream node. The forwarding state upstream <X, Y> on node Z will be like this: {<Lu'>, <Iu Lu>}. Iu means the upstream interface over which Z receives HSMP-U Label Map <X, Y, Lu> from LSR U. Packets from any downstream interface over which Z sends HSMP-U Label Map <X, Y, Lu'> with label Lu' will be forwarded to Iu with label Lu' swapped to Lu.
由于来自任何下游节点的数据包仅转发到上游节点，因此相同的标签（表示上游路径）应分发到所有下游节点。这与MP2MP LSP[RFC6388]的程序不同，后者必须向每个下游节点分发不同的标签。节点Z上上游<X，Y>的转发状态如下：{<Lu'>，<Iu Lu>}。Iu是指Z通过其从LSR U接收HSMP-U标签映射<X，Y，Lu>的上游接口。Z通过其发送HSMP-U标签映射<X，Y，Lu'>且标签为“Lu”的任何下游接口的数据包将转发至Iu，标签为“Lu”并交换至“Lu”。
The procedure for an HSMP-D Label Mapping message is much the same as processing an MP2MP-D Label Mapping message defined in Section 3.3.1.6 of [RFC6388]. The processing of an HSMP-U Label Mapping message is different from that of an MP2MP-U Label Mapping message as specified below.
HSMP-D标签映射消息的处理过程与[RFC6388]第3.3.1.6节中定义的MP2MP-D标签映射消息的处理过程大致相同。HSMP-U标签映射消息的处理与MP2MP-U标签映射消息的处理不同，如下所述。
Suppose the root node Z receives an HSMP-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 an outgoing label L over interface I. Interface I is
假设根节点Z从节点D接收到HSMP-D标签映射<X，Y，L>。Z检查它是否已经具有下游<X，Y>的转发状态。如果不是，Z将创建下游转发状态，并在接口I上安装传出标签L。接口I为
determined via the procedures in Section 3.7. If Z already has forwarding state for downstream <X, Y>, then Z will add label L over interface I to the existing state.
通过第3.7节中的程序确定。如果Z已经具有下游<X，Y>的转发状态，则Z将在接口I上向现有状态添加标签L。
Node Z checks if it has forwarding state for upstream <X, Y>. If not, Z creates a forwarding state for incoming label Lu' that indicates that Z is the HSMP LSP egress Label Edge Router (LER). For example, the forwarding state might specify that the label stack is popped and the packet passed to some specific application. Node Z determines the downstream HSMP LSR as per Section 3.3 and sends an HSMP-U Label Map <X, Y, Lu'> to node D.
节点Z检查其是否具有上游<X，Y>的转发状态。如果不是，Z为传入标签Lu'创建转发状态，该状态指示Z是HSMP LSP出口标签边缘路由器（LER）。例如，转发状态可能指定弹出标签堆栈，并将数据包传递给某个特定的应用程序。节点Z根据第3.3节确定下游HSMP LSR，并向节点D发送HSMP-U标签图<X，Y，Lu'>。
Since Z is the root of the tree, Z will not send an HSMP-D Label Map and will not receive an HSMP-U Label Mapping.
因为Z是树的根，所以Z不会发送HSMP-D标签映射，也不会接收HSMP-U标签映射。
The root node could also be a leaf node, and it is able to determine what traffic to forward on this HSMP LSP; that determination is outside the scope of this document.
根节点也可以是叶节点，它能够确定在这个HSMP LSP上转发什么流量；该决定超出了本文件的范围。
If a leaf node Z discovers 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 HSMP-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 HSMP-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.
如果叶节点Z发现它不需要成为该LSP的出口LSR（通过本文档范围之外的方式），那么它应该向其上游LSR U发送一个HSMP-D标签RECUN<X，Y，L>，用于<X，Y>，其中L是它之前为<X，Y>向U发布的标签。叶节点Z还将向U发送一个未经请求的HSMP-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 HSMP-D Label Withdraw message <X, Y, L> from node D, it deletes label L from its forwarding state downstream <X, Y>. Node Z sends an HSMP-D Label Release message with label L to D. There is no need to send an HSMP-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接收到HSMP-D标签撤回消息<X，Y，L>，则它将标签L从其下游的转发状态<X，Y>中删除。节点Z发送带有标签L到D的HSMP-D标签释放消息。不需要向D发送HSMP-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 HSMP-D Label
Withdraw <X, Y, L> to its upstream node U for <X, Y>. Z should also
check if there are any incoming interfaces in forwarding state
upstream <X, Y>. If all downstream nodes are released and there is
If deleting L from Z's forwarding state for downstream <X, Y> results
in no state remaining for <X, Y>, then Z propagates the HSMP-D Label
Withdraw <X, Y, L> to its upstream node U for <X, Y>. Z should also
check if there are any incoming interfaces in forwarding state
upstream <X, Y>. If all downstream nodes are released and there is
no incoming interface, Z should delete the forwarding state upstream <X, Y> and send an HSMP-U Label Release message to its upstream node. Otherwise, no HSMP-U Label Release message will be sent to the upstream node.
没有传入接口，Z应删除上游的转发状态<X，Y>，并向其上游节点发送HSMP-U标签释放消息。否则，不会向上游节点发送HSMP-U标签释放消息。
When the root node of an HSMP LSP receives an HSMP-D Label Withdraw message and an HSMP-U Label Release message, the procedure is the same as that for transit nodes, except that the root node will not propagate the Label Withdraw and Label Release upstream (as it has no upstream).
当HSMP LSP的根节点接收到HSMP-D标签撤回消息和HSMP-U标签释放消息时，该过程与中转节点相同，只是根节点不会向上游传播标签撤回和标签释放（因为它没有上游）。
The procedure for changing the upstream LSR is the same as defined in Section 2.4.3 of [RFC6388], only with different processing of the FEC Element.
更改上游LSR的程序与[RFC6388]第2.4.3节中的定义相同，只是FEC元件的处理不同。
When the upstream LSR changes from U to U', node Z should set up the HSMP LSP <X, Y> to U' by applying the procedures in Section 3.4. Z will also remove the HSMP LSP <X, Y> to U by applying the procedure in Section 3.5.
当上游LSR从U变为U'时，节点Z应通过应用第3.4节中的程序将HSMP LSP<X，Y>设置为U'。Z还将通过应用第3.5节中的程序，将HSMP LSP<X，Y>移除至U。
To set up an HSMP LSP to U' before/after removing the HSMP LSP to U is a local matter. The recommended default behavior is to remove before adding.
在将HSMP LSP移到U'之前/之后，将HSMP LSP设置到U'是本地事务。建议的默认行为是在添加之前删除。
The upstream and downstream LSPs can be co-routed by applying the procedures below. Both LSR U and LSR D would ensure that the same interface sends traffic by applying some procedures. For a network with symmetric IGP cost configuration, the following procedure MAY be used. To determine the downstream interface, LSR U MUST 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 should be used to transmit the packet to LSR D. The mechanism to determine the upstream interface is the same as that used to determine the downstream interface except the roles of LSR U and LSR D are switched. If symmetric IGP cost could not be ensured, static route configuration on LSR U and D could also be a way to ensure a co-routed path.
上游和下游LSP可通过应用以下程序共同路由。LSRU和LSRD都将通过应用一些过程来确保同一接口发送通信量。对于具有对称IGP成本配置的网络，可以使用以下步骤。为了确定下游接口，LSR U必须在单播路由表中进行查找，以找到到达LSR D的最佳接口和下一跳。如果下一跳和接口也由LSR D通过LDP会话进行广告，应使用它将数据包传输到LSR D。确定上游接口的机制与确定下游接口的机制相同，但LSR U和LSR D的角色是交换的。如果无法确保对称IGP成本，LSR U和D上的静态路由配置也可以是确保共路由路径的一种方法。
If a co-routed path is not required for the HSMP LSP, the procedure defined in Section 2.4.1.2 of [RFC6388] could be applied. LSR U is free to transmit the packet on any of the interfaces to LSR D. The algorithm it uses to choose a particular interface is a local matter.
如果HSMP LSP不需要共路由路径，可采用[RFC6388]第2.4.1.2节中规定的程序。LSR U可以在任何接口上自由地将数据包传输到LSR D。它用于选择特定接口的算法是本地问题。
The mechanism to determine the upstream interface is the same as that used to determine the downstream interface.
确定上游界面的机制与确定下游界面的机制相同。
The procedure to process the downstream HSMP LSP on a LAN is much the same as for a downstream MP2MP LSP as described in Section 6.1.1 of [RFC6388].
LAN上下游HSMP LSP的处理程序与[RFC6388]第6.1.1节中所述的下游MP2MP LSP的处理程序大致相同。
When establishing the downstream path of an HSMP LSP, as defined in [RFC6389], a Label Request message for an LSP label is sent to the upstream LSR. The upstream LSR should send a Label Mapping message that contains the LSP label for the downstream HSMP FEC and the upstream LSR context label defined in [RFC5331]. When the LSR forwards a packet downstream on one of those LSPs, the packet's top label must be the "upstream LSR context label" and the packet's second label is the "LSP label". The HSMP downstream path will be installed in the context-specific forwarding table corresponding to the upstream LSR label. Packets sent by the upstream LSR can be forwarded downstream using this forwarding state based on a two-label lookup.
当建立HSMP LSP的下游路径时，如[RFC6389]中所定义，LSP标签的标签请求消息被发送到上游LSR。上游LSR应发送标签映射消息，其中包含下游HSMP FEC的LSP标签和[RFC5331]中定义的上游LSR上下文标签。当LSR在其中一个LSP上向下游转发数据包时，数据包的顶部标签必须是“上游LSR上下文标签”，数据包的第二个标签是“LSP标签”。HSMP下游路径将安装在与上游LSR标签对应的上下文特定转发表中。上游LSR发送的数据包可以使用这种基于双标签查找的转发状态向下游转发。
The upstream path of an HSMP LSP on a LAN is the same as the one on other kinds of links. That is, the upstream LSR must send a Label Mapping message that contains the LSP label for the upstream HSMP FEC to the downstream node. Packets traveling upstream need to be forwarded in the direction of the root by using the label allocated for the upstream HSMP FEC.
局域网上HSMP LSP的上行路径与其他类型链路上的路径相同。也就是说，上游LSR必须向下游节点发送包含上游HSMP FEC的LSP标签的标签映射消息。上行的数据包需要使用为上行HSMP-FEC分配的标签在根的方向上转发。
In some scenarios, it is necessary to provide two root nodes for redundancy purposes. One way to implement this is to use two independent HSMP LSPs acting as active and standby. At a given time, only one HSMP LSP will be active; the other will be standby. After detecting the failure of the active HSMP LSP, the root and leaf nodes will switch the traffic to the standby HSMP LSP, which takes on the role as active HSMP LSP. The details of the redundancy mechanism are out of the scope of this document.
在某些情况下，出于冗余目的，需要提供两个根节点。实现这一点的一种方法是使用两个独立的HSMP LSP作为活动和备用。在给定时间，只有一个HSMP LSP将处于活动状态；另一个将待命。在检测到活动HSMP LSP的故障后，根节点和叶节点将流量切换到备用HSMP LSP，备用HSMP LSP承担活动HSMP LSP的角色。冗余机制的详细信息不在本文档的范围内。
The idea of LSP ping for HSMP LSPs could be expressed as an intention to test the LSP Ping Echo Request packets that enter at the root along a particular downstream path of HSMP LSP and that end their MPLS path on the leaf. The leaf node then sends the LSP Ping Echo Reply along the upstream path of HSMP LSP, and it ends on the root that is the (intended) root node.
针对HSMP LSP的LSP ping的思想可以表示为测试LSP ping回波请求分组的意图，这些分组沿着HSMP LSP的特定下游路径在根处进入，并且在叶上结束其MPLS路径。然后，叶节点沿着HSMP LSP的上游路径发送LSP Ping Echo应答，并在根节点（预期的）上结束。
New sub-TLVs have been assigned by IANA in Target FEC Stack TLV and Reverse-path Target FEC Stack TLV to define the corresponding HSMP-downstream FEC type and HSMP-upstream FEC type. In order to ensure that the leaf node sends the LSP Ping Echo Reply along the HSMP upstream path, the R flag (Validate Reverse Path) in the Global Flags field defined in [RFC6426] is reused here.
IANA在目标FEC堆栈TLV和反向路径目标FEC堆栈TLV中分配了新的子TLV，以定义相应的HSMP下游FEC类型和HSMP上游FEC类型。为了确保叶节点沿HSMP上游路径发送LSP Ping Echo应答，此处重用[RFC6426]中定义的全局标志字段中的R标志（验证反向路径）。
The node-processing mechanism of LSP Ping Echo Request and Echo Reply for the HSMP LSP is inherited from [RFC6425] and Section 3.4 of [RFC6426], except for the following:
HSMP LSP的LSP Ping Echo Request和Echo Reply的节点处理机制继承自[RFC6425]和[RFC6426]的第3.4节，但以下情况除外：
1. The root node sending the LSP Ping Echo Request message for the HSMP LSP MUST attach the Target FEC Stack TLV with the HSMP-downstream FEC type, and set the R flag to '1' in the Global Flags field.
1. 发送HSMP LSP的LSP Ping Echo请求消息的根节点必须将目标FEC堆栈TLV附加到HSMP下游FEC类型，并在全局标志字段中将R标志设置为“1”。
2. When the leaf node receives the LSP Ping Echo Request, it MUST send the LSP Ping Echo Reply to the associated HSMP upstream path. The Reverse-path Target FEC Stack TLV attached by the leaf node in the Echo Reply message SHOULD contain the sub-TLV of the associated HSMP-upstream FEC.
2. 当叶节点接收到LSP Ping Echo请求时，它必须将LSP Ping Echo回复发送到相关的HSMP上游路径。回波应答消息中的叶节点连接的反向路径目标FEC堆栈TLV应包含相关HSMP上游FEC的子TLV。
The same security considerations apply as for the MP2MP LSP described in [RFC6388] and [RFC6425].
与[RFC6388]和[RFC6425]中所述的MP2MP LSP相同的安全注意事项也适用。
Although this document introduces new FEC Elements and corresponding procedures, the protocol does not bring any new security issues beyond those in [RFC6388] and [RFC6425].
尽管本文件介绍了新的FEC元素和相应的程序，但该协议并未带来[RFC6388]和[RFC6425]中所述之外的任何新的安全问题。
Two new LDP FEC Element types have been allocated from the "Label Distribution Protocol (LDP) Parameters" registry, under "Forwarding Equivalence Class (FEC) Type Name Space":
在“转发等价类（FEC）类型名称空间”下，从“标签分发协议（LDP）参数”注册表分配了两种新的LDP FEC元素类型：
1. the HSMP-upstream FEC type - 9
1. HSMP上游FEC类型-9
2. the HSMP-downstream FEC type - 10
2. HSMP下游FEC类型-10
The values have been allocated from the "IETF Consensus" [RFC5226] range (0-127).
这些值已从“IETF共识”[RFC5226]范围（0-127）中分配。
One new code point has been allocated for the HSMP LSP capability TLV from "Label Distribution Protocol (LDP) Parameters" registry, under "TLV Type Name Space":
已从“标签分发协议（LDP）参数”注册表的“TLV类型名称空间”下为HSMP LSP功能TLV分配了一个新的代码点：
HSMP LSP Capability Parameter - 0x0902
HSMP LSP能力参数-0x0902
The value has been allocated from the"IETF Consensus" range (0x0901-0x3DFF).
该值已从“IETF共识”范围（0x0901-0x3DFF）中分配。
Two new sub-TLV types have been allocated for inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV type 1), Reverse-path Target FEC Stack TLV (TLV type 16), and Reply Path TLV (TLV type 21).
已分配两种新的子TLV类型，以包含在LSP ping[RFC4379]目标FEC堆栈TLV（TLV类型1）、反向路径目标FEC堆栈TLV（TLV类型16）和应答路径TLV（TLV类型21）中。
o the HSMP-upstream LDP FEC Stack - 29
o HSMP上游LDP FEC堆栈-29
o the HSMP-downstream LDP FEC Stack - 30
o HSMP下游LDP FEC堆栈-30
The value has been allocated from the "IETF Standards Action" range (0-16383) that is used for mandatory and optional sub-TLVs that requires a response if not understood.
该值已从“IETF标准行动”范围（0-16383）中分配，该范围用于要求响应（如果不理解）的强制性和可选子TLV。
The author would like to thank Eric Rosen, Sebastien Jobert, Fei Su, Edward, Mach Chen, Thomas Morin, and Loa Andersson for their valuable comments.
作者要感谢Eric Rosen、Sebastien Jobert、Fei Su、Edward、Mach Chen、Thomas Morin和Loa Andersson的宝贵评论。
[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月。
[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月。
[RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[RFC5332]Eckert，T.，Rosen，E.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，2008年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月。
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November 2011.
[RFC6388]Wijnands，IJ.，Minei，I.，Kompella，K.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，2011年11月。
[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, November 2011.
[RFC6389]阿加瓦尔，R.和JL。Le Roux，“LDP的MPLS上游标签分配”，RFC 6389，2011年11月。
[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.
[RFC6425]Saxena，S.，Swallow，G.，Ali，Z.，Farrel，A.，Yasukawa，S.，和T.Nadeau，“检测点对多点MPLS中的数据平面故障-LSP Ping扩展”，RFC 64252011年11月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]Gray，E.，Bahadur，N.，Boutros，S.，和R.Aggarwal，“MPLS按需连接验证和路由跟踪”，RFC 6426，2011年11月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379]Kompella，K.和G.Swallow，“检测多协议标签交换（MPLS）数据平面故障”，RFC 4379，2006年2月。
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Minei，I.，和B.Thomas，“LDP规范”，RFC 5036，2007年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Addresses
作者地址
Lizhong Jin Shanghai China
中国上海理中金
EMail: lizho.jin@gmail.com
EMail: lizho.jin@gmail.com
Frederic Jounay Orange CH 4 rue du Caudray 1007 Lausanne Switzerland
Frederic Jounay Orange CH 4 rue du Caudray 1007瑞士洛桑
EMail: frederic.jounay@orange.ch
EMail: frederic.jounay@orange.ch
IJsbrand Wijnands Cisco Systems, Inc De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijlands Cisco Systems，Inc.De kleetlaan 6a Diegem 1831比利时
EMail: ice@cisco.com
EMail: ice@cisco.com
Nicolai Leymann Deutsche Telekom AG Winterfeldtstrasse 21 Berlin 10781 Germany
Nicolai Leymann德国电信公司Winterfeldtstrasse 21柏林10781德国
EMail: N.Leymann@telekom.de
EMail: N.Leymann@telekom.de