Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 7715 K. Raza
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 A. Atlas
Juniper Networks, Inc.
J. Tantsura
Ericsson
Q. Zhao
Huawei Technology
January 2016
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 7715 K. Raza
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 A. Atlas
Juniper Networks, Inc.
J. Tantsura
Ericsson
Q. Zhao
Huawei Technology
January 2016
Multipoint LDP (mLDP) Node Protection
多点LDP（mLDP）节点保护
Abstract
摘要
This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (P2MP and MP2MP LSPs) that have been built by the Multipoint Label Distribution Protocol (mLDP). In order to protect a node N, the Point of Local Repair (PLR) Label Switching Router (LSR) of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing Point-to-Point (P2P) Label Switched Paths (LSPs). The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N.
本文档描述了支持多点标签分发协议（mLDP）构建的点对多点和多点对多点标签交换路径（P2MP和MP2MP LSP）的节点保护的过程。为了保护节点N，N的本地修复点（PLR）标签交换路由器（LSR）必须学习节点N的合并点（MPT）LSR，以便在节点N失败时可以将流量重定向到它们。重定向故障节点N周围的流量取决于现有的点对点（P2P）标签交换路径（LSP）。预先建立的LSP源自PLR LSR，并在绕过LSR N的同时终止于MPT LSR。
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/rfc7715.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7715.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. PLR Determination . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Transit Node Procedure . . . . . . . . . . . . . . . . . . 5
2.2. MP2MP Root Node Procedure . . . . . . . . . . . . . . . . 6
2.3. PLR Information Encoding . . . . . . . . . . . . . . . . . 7
3. Using the tLDP Session . . . . . . . . . . . . . . . . . . . . 9
4. Link or Node Failure . . . . . . . . . . . . . . . . . . . . . 10
4.1. Reconvergence after Node or Link Failure . . . . . . . . . 11
4.1.1. Node Failure . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Link Failure . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. Switching to New Primary Path . . . . . . . . . . . . 12
5. mLDP Capabilities for Node Protection . . . . . . . . . . . . 13
5.1. PLR Capability . . . . . . . . . . . . . . . . . . . . . . 13
5.2. MPT Capability . . . . . . . . . . . . . . . . . . . . . . 14
5.3. The Protected LSR . . . . . . . . . . . . . . . . . . . . 14
5.4. The Node Protection Capability . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. PLR Determination . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Transit Node Procedure . . . . . . . . . . . . . . . . . . 5
2.2. MP2MP Root Node Procedure . . . . . . . . . . . . . . . . 6
2.3. PLR Information Encoding . . . . . . . . . . . . . . . . . 7
3. Using the tLDP Session . . . . . . . . . . . . . . . . . . . . 9
4. Link or Node Failure . . . . . . . . . . . . . . . . . . . . . 10
4.1. Reconvergence after Node or Link Failure . . . . . . . . . 11
4.1.1. Node Failure . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. Link Failure . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. Switching to New Primary Path . . . . . . . . . . . . 12
5. mLDP Capabilities for Node Protection . . . . . . . . . . . . 13
5.1. PLR Capability . . . . . . . . . . . . . . . . . . . . . . 13
5.2. MPT Capability . . . . . . . . . . . . . . . . . . . . . . 14
5.3. The Protected LSR . . . . . . . . . . . . . . . . . . . . 14
5.4. The Node Protection Capability . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
This document describes procedures to support node protection for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths (P2MP and MP2MP LSPs) that have been built by the Multipoint Label Distribution Protocol (mLDP) [RFC6388]. In order to protect a node N, the Point of Local Repair (PLR) LSR of N must learn the Merge Point (MPT) LSR(s) of node N such that traffic can be redirected to them in case node N fails. Redirecting the traffic around the failed node N depends on existing P2P LSPs. The pre-established LSPs originate from the PLR LSR and terminate on the MPT LSRs while bypassing LSR N. The procedures to set up these P2P LSPs are outside the scope of this document, but one can imagine using techniques based on the Resource Reservation Protocol for Traffic Engineering (RSVP-TE) [RFC5420] or Label Distribution Protocol (LDP) Loop-Free Alternate (LFA) [RFC5286] to accomplish this.
本文档描述了支持多点标签分发协议（mLDP）[RFC6388]构建的点对多点和多点对多点标签交换路径（P2MP和MP2MP LSP）节点保护的过程。为了保护节点N，N的本地修复点（PLR）LSR必须学习节点N的合并点（MPT）LSR，以便在节点N发生故障时可以将流量重定向到它们。重定向故障节点N周围的流量取决于现有的P2P LSP。预先建立的LSP源自PLR LSR，并在绕过LSR N时终止于MPT LSR。建立这些P2P LSP的过程不在本文档的范围内，但可以想象使用基于流量工程资源预留协议（RSVP-TE）[RFC5420]或标签分发协议（LDP）的技术无回路备用（LFA）[RFC5286]来完成此任务。
The solution described in this document notifies the PLR(s) of the MPT LSR(s) via signaling using a Targeted LDP (tLDP) session [RFC7060]. By having a tLDP session with the PLR, no additional procedures need to be defined in order to support Make-Before-Break (MBB), Graceful Restart (GR), and Typed Wildcard Forwarding Equivalence Class (FEC). All this is achieved at the expense of having additional tLDP sessions between each MPT and PLR LSR.
本文档中描述的解决方案通过使用目标LDP（tLDP）会话[RFC7060]的信令通知PLR MPT LSR。通过使用PLR进行tLDP会话，不需要定义额外的过程来支持先通后断（MBB）、优雅重启（GR）和类型化通配符转发等价类（FEC）。所有这些都是以在每个MPT和PLR LSR之间增加tLDP会话为代价实现的。
In order to allow a node to be protected against failure, the LSRs providing the PLR and the MPT functionality as well as the protected node MUST support the functionality described in this document. LDP capability negotiation [RFC5561] is used to signal the availability of the functionality between the participating nodes; these nodes MUST support capability negotiation.
为了防止节点发生故障，提供PLR和MPT功能以及受保护节点的LSR必须支持本文档中描述的功能。LDP能力协商[RFC5561]用于表示参与节点之间功能的可用性；这些节点必须支持能力协商。
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]中所述进行解释。
The term "node" is used to refer to an LSR; "node" and "LSR" are used interchangeably in this document. The terms "PLR" and "MPT" are used as shorthand to refer to "PLR LSR" and "MPT LSR", respectively.
术语“节点”用于指LSR；“节点”和“LSR”在本文件中互换使用。术语“PLR”和“MPT”分别用作“PLR LSR”和“MPT LSR”的缩写。
mLDP: Multipoint LDP
多点LDP
PLR: Point of Local Repair The LSR that redirects the traffic to one or more Merge Point LSRs.
PLR：本地修复点将流量重定向到一个或多个合并点LSR的LSR。
MPT: Merge Point The LSR that merges the backup LSP with the primary LSP. Note, there can be multiple MPT LSRs for a single MP-LSP node protection.
MPT：合并点将备份LSP与主LSP合并的LSR。注意，对于单个MP-LSP节点保护，可以有多个MPT LSR。
tLDP: Targeted LDP
tLDP：目标自民党
MP LSP: Multi-Point LSP Either a P2MP or MP2MP LSP.
MP LSP：P2MP或MP2MP LSP中的多点LSP。
root node: The root of either a P2MP or MP2MP LSP as defined in [RFC6388].
根节点：在[RFC6388]中定义的P2MP或MP2MP LSP的根。
In order for an MPT to establish a tLDP session with a PLR, it first has to learn the PLR for a particular MP LSP. It is the responsibility of the protected node N to advertise the address of the PLR to the MPT. The PLR address for an MP LSP on node N is the address of the upstream LDP peer, but only when node N is NOT the root node of the MP2MP LSP. If the upstream LDP peer is unable to function as PLR, the procedures in this document do not apply and are out of the scope. If node N is the root node, the procedures are slightly different as described in Section 2.2. The procedures that follow assume that all the participating nodes (N, PLRs, MPTs) are enabled (e.g., by a user configuration) to support and implement the PLR determination feature.
为了使MPT与PLR建立tLDP会话，它首先必须学习特定MP LSP的PLR。受保护节点N负责向MPT通告PLR的地址。节点N上的MP LSP的PLR地址是上游LDP对等方的地址，但仅当节点N不是MP2MP LSP的根节点时。如果上游LDP对等方无法作为PLR运行，则本文件中的程序不适用，并且超出范围。如果节点N是根节点，则程序略有不同，如第2.2节所述。接下来的过程假设所有参与节点（N、PLR、mpt）都被启用（例如，通过用户配置）以支持和实现PLR确定特性。
The procedures as documented in this RFC require the protected node to be directly connected to the PLR and MPT nodes. This is because mLDP depends on unicast routing to determine the upstream LSR and unicast routing (by default) only has information about the next hop and not beyond that. Support for non-directly connected PLR and MPT nodes is outside the scope of this document.
本RFC中记录的程序要求受保护节点直接连接到PLR和MPT节点。这是因为mLDP依赖于单播路由来确定上游LSR，而单播路由（默认情况下）仅包含下一跳的信息，而不包含下一跳的信息。对非直接连接的PLR和MPT节点的支持不在本文档的范围之内。
Below are the procedures for when the protected node is a transit node along the path to the root.
以下是受保护节点是沿根路径的传输节点时的过程。
root
^
|
(LSR1)
. | .
. | .
. (N) .
. / \ .
. / \.
(LSR2) (LSR3)
| |
root
^
|
(LSR1)
. | .
. | .
. (N) .
. / \ .
. / \.
(LSR2) (LSR3)
| |
N: The node being protected. ...: Backup LSPs from LSR1 to LSR2 and LSR3.
N:受保护的节点…：将LSP从LSR1备份到LSR2和LSR3。
Figure 1
图1
Node N uses the root address of the MP LSP to determine the upstream LSR for a given MP LSP following the procedures as documented in Section 2.4.1.1 of [RFC6388]. The upstream LSR in Figure 1 is LSR1 because it is the first hop along the shortest path to reach the root address. After determining the upstream LSR, node N (which has the node protection feature enabled) MUST advertise the address of LSR1 as the PLR address to the downstream members of the MP LSP (i.e., LSR2 and LSR3) if the given downstream member has announced support for node protection (see Section 5 regarding capability negotiation). For the format and encoding of PLR address information, see Section 2.3.
节点N根据[RFC6388]第2.4.1.1节中记录的程序，使用MP LSP的根地址来确定给定MP LSP的上游LSR。图1中的上游LSR是LSR1，因为它是沿着最短路径到达根地址的第一个跃点。在确定上游LSR后，如果给定的下游成员已宣布支持节点保护（参见第5节关于能力协商），则节点N（启用了节点保护功能）必须将LSR1的地址作为PLR地址公布给MP LSP的下游成员（即LSR2和LSR3）。有关PLR地址信息的格式和编码，请参见第2.3节。
Note, in order for the protected traffic to reach nodes LSR2 and LSR3, LSR1 MUST have two unidirectional LSPs to LSR2 and LSR3, bypassing node N. The procedures for setting up these LSPs are outside the scope of this document.
注意，为了使受保护的通信量到达节点LSR2和LSR3，LSR1必须有两个到LSR2和LSR3的单向LSP，绕过节点N。设置这些LSP的过程不在本文档的范围内。
Below are the procedures for when the protected node is the root of an MP2MP LSP. Consider figure 2 below.
以下是当受保护节点是MP2MP LSP的根节点时的步骤。请参阅下面的图2。
|
(LSR1)
. | .
. | .
. (N) . root
. / \ .
. / \.
(LSR2)....(LSR3)
| |
|
(LSR1)
. | .
. | .
. (N) . root
. / \ .
. / \.
(LSR2)....(LSR3)
| |
N: The MP2MP root node being protected. ...: Backup LSPs between LSR1, LSR2, and LSR3.
N:正在保护的MP2MP根节点…：在LSR1、LSR2和LSR3之间备份LSP。
Figure 2
图2
Assume that LSR1, LSR2, and LSR3 are all members of an MP2MP LSP for which N is the root node. Since N is the root of the MP2MP LSP, there is no upstream LSR and no 'single' PLR LSR for protecting node N. In order to protect node N, all the directly connected members of the MP2MP must participate in protecting node N by acting both as PLR and MPT LSR. An LSR will act as MPT for traffic coming from the other LSR(s) and it will act as PLR for traffic it is sending to the other LSR(s). Since node N knows the members of the MP2MP LSP, it will advertise the member list to its directly connected members, excluding the member it is sending to. For example, node N will advertise list {LSR3,LSR1} to LSR2 excluding LSR2 from it. Instead of advertising a single PLR when node N is not the root, a list of PLRs is advertised using the procedures documented in Section 2.3.
假设LSR1、LSR2和LSR3都是MP2MP LSP的成员，其中N是根节点。由于N是MP2MP LSP的根，因此不存在用于保护节点N的上游LSR和“单个”PLR LSR。为了保护节点N，MP2MP的所有直接连接成员必须通过充当PLR和MPT LSR来参与保护节点N。对于来自其他LSR的流量，LSR将充当MPT，对于发送到其他LSR的流量，LSR将充当PLR。由于节点N知道MP2MP LSP的成员，因此它将向其直接连接的成员播发成员列表，不包括它发送到的成员。例如，节点N将把列表{LSR3，LSR1}播发到LSR2，将LSR2从中排除。当节点N不是根节点时，不公布单个PLR，而是使用第2.3节中记录的程序公布PLR列表。
It should be noted that the MP2MP root node protection mechanism doesn't replace the Root Node Redundancy (RNR) procedures as described in Section 7 of [RFC6388]. The node protection procedures in this document will help in restoring traffic for the existing MP2MP LSPs after node failure, but a new root node has to be elected eventually in order to allow new MP2MP LSPs to be created.
需要注意的是，MP2MP根节点保护机制并不能取代[RFC6388]第7节中描述的根节点冗余（RNR）过程。本文档中的节点保护程序将有助于在节点故障后恢复现有MP2MP LSP的通信量，但最终必须选择一个新的根节点，以便创建新的MP2MP LSP。
Note, in order for the protected traffic to be exchanged between nodes LSR1, LSR2, and LSR3, bidirectional LSPs have to exist between the LSRs, bypassing node N. The procedures for setting up these LSPs are outside the scope of this document.
注意，为了在节点LSR1、LSR2和LSR3之间交换受保护的通信量，LSR之间必须存在双向LSP，绕过节点N。设置这些LSP的过程不在本文档的范围内。
The upstream LSR address is conveyed via an LDP Notification message with an MP Status TLV, where the MP Status TLV contains a new "PLR Status Value Element" that specifies the address of the PLR.
上游LSR地址通过具有MP状态TLV的LDP通知消息传送，其中MP状态TLV包含指定PLR地址的新“PLR状态值元素”。
The new "PLR Status Value Element" is encoded as described below.
新的“PLR状态值元素”编码如下所述。
PLR Status Element:
PLR状态元素：
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 = 2 | Length | Addr Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Fam cont | Num PLR entry | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| PLR entry (1 or more) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 2 | Length | Addr Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Fam cont | Num PLR entry | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
| PLR entry (1 or more) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where
哪里
Type: PLR Status Value Element (Type 2).
类型：PLR状态值元素（类型2）。
Length: The Length field is an unsigned integer that encodes the length of the Status Value following the Length field. The encoded Length varies based on the Addr Family and the number of PLR entries.
长度：长度字段是一个无符号整数，它对长度字段后面的状态值的长度进行编码。编码长度根据Addr系列和PLR条目的数量而变化。
Addr Family: Two-octet quantity containing a value from IANA's "Address Family Numbers" registry [AFI] that encodes the address family for the PLR address encoded in the PLR entry.
Addr Family：两个八位组数量，包含IANA“地址系列号”注册表[AFI]中的一个值，该注册表对PLR条目中编码的PLR地址的地址系列进行编码。
Num PLR entry: Element as an unsigned integer followed by the number of "PLR entry" fields in the format specified below.
Num PLR entry：元素为无符号整数，后跟以下指定格式的“PLR entry”字段数。
The format of a "PLR Entry" is as follows:
“PLR条目”的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | PLR address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PLR address (cont) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Reserved | PLR address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PLR address (cont) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where
哪里
A bit: 0 = Withdraw, 1 = Add.
A位：0=撤消，1=添加。
Reserved: 15 bits; MUST be zero on transmit and ignored on receipt.
预留：15位；传输时必须为零，接收时忽略。
PLR address: PLR address encoded according to the Address Family field encoded in the PLR Status Value Element. Note that the length of the PLR address field is specific to the Address Family that is encoded.
PLR地址：根据PLR状态值元素中编码的地址族字段编码的PLR地址。请注意，PLR地址字段的长度特定于编码的地址族。
The size of a "PLR Entry" is the 2 octets ("A bit + Reserved") + PLR address length. The length of the PLR address is dependent on the Address Family as encoded in the PLR Status Value Element. The size of a "PLR entry" is 6 octets and 18 octets, respectively, for an IPv4 PLR address and an IPv6 PLR address.
“PLR条目”的大小为2个八位字节（“位+保留”）+PLR地址长度。PLR地址的长度取决于PLR状态值元素中编码的地址族。对于IPv4 PLR地址和IPv6 PLR地址，“PLR条目”的大小分别为6个八位字节和18个八位字节。
If the PLR address on N changes for a given MP LSP, N needs to trigger a new PLR Status to update the MPT(s). Node N can advertise or withdraw a given PLR from its PLR set by setting the A bit to 1 or 0 respectively in the corresponding PLR entry. Removing a PLR address is likely due to a link failure; see the procedures as documented in Section 4.1. To remove all PLR addresses belonging to the encoded Address Family, an LSR N MUST encode a PLR Status Value Element with no PLR entry and the "Num PLR entry" field MUST be set to zero.
如果N上的PLR地址因给定MP LSP而改变，N需要触发新的PLR状态以更新MPT。节点N可以通过在相应的PLR条目中将a位分别设置为1或0，从其PLR集合中通告或撤回给定的PLR。删除PLR地址可能是由于链路故障；参见第4.1节中记录的程序。要删除属于编码地址系列的所有PLR地址，LSR N必须编码没有PLR条目的PLR状态值元素，并且“Num PLR entry”字段必须设置为零。
Both the PLR Status and an MP FEC TLV [RFC5036] MUST be included in the LDP Notification message so that a receiver is able to associate the PLR Status with the MP LSP.
LDP通知消息中必须包括PLR状态和MP FEC TLV[RFC5036]，以便接收方能够将PLR状态与MP LSP关联。
The receipt of a PLR MP Status (with PLR addresses) for an MP LSP on a receiving LSR makes it an MPT for node protection. If not already established, the MPT LSR MUST establish a tLDP session with all of the learned PLR addresses using the procedures as documented in [RFC7060].
接收LSR上MP LSP的PLR MP状态（带有PLR地址）的接收使其成为节点保护的MPT。如果尚未建立，则MPT LSR必须使用[RFC7060]中记录的程序与所有学习到的PLR地址建立tLDP会话。
Using Figure 1 as the reference topology, let us assume that both LSR2 and LSR3 are MPTs and have established a tLDP session with the PLR being LSR1. Assume that both LSR2 and LSR3 have a FEC <R,X> with an upstream LSR N and label Ln assigned to FEC towards N. The MPTs will create a secondary upstream LSR for the FEC <R,X> (using the received PLR address) and assign label Lpx to it. The MPTs will do that for each PLR address that was learned for the MP LSP. In this example, the MPTs will have a FEC <R,X> with two local labels associated with it. Label Ln that was assigned to N using the normal mLDP procedures, and Label Lpx that was assigned to PLR (LSR1) for the purpose of node protection. Note, when the protected node is an MP2MP root node, there will be an upstream LSR for each PLR address that was advertised along with a unique Label Lpx.
使用图1作为参考拓扑，让我们假设LSR2和LSR3都是MPT，并且已经建立了一个tLDP会话，PLR是LSR1。假设LSR2和LSR3都有一个FEC<R，X>，其中上游LSR N和标签Ln分配给朝N的FEC。MPT将为FEC<R，X>（使用接收到的PLR地址）创建一个二级上游LSR，并将标签Lpx分配给它。MPT将为MP LSP学习的每个PLR地址执行此操作。在本例中，MPT将具有一个FEC<R，X>，其中有两个与之相关联的本地标签。使用正常mLDP程序标记分配给N的Ln，以及为保护节点而标记分配给PLR（LSR1）的Lpx。注意，当受保护的节点是MP2MP根节点时，每个播发的PLR地址都会有一个上游LSR以及一个唯一的标签Lpx。
The receipt of a FEC Label Mapping alone over the tLDP session from MPT on a PLR conveys the label information but does not convey the node being protected. The information about a protected node is known to the MPT LSR and needs to be communicated to the PLR as well. For this reason, the FEC Label Mapping (FEC <R,X> : Lpx) sent by the MPT over the tLDP session to the PLR MUST include a Status TLV with an MP Status and a new LDP MP Status Value Element called the "Protected Node Status Value Element". This new value element is used to specify the address of the node being protected. The "Protected Node Status Value Element" has the following format:
通过tLDP会话从PLR上的MPT单独接收FEC标签映射传递标签信息，但不传递受保护的节点。MPT LSR知道关于受保护节点的信息，并且还需要将该信息传送到PLR。因此，MPT通过tLDP会话发送到PLR的FEC标签映射（FEC<R，X>：Lpx）必须包括具有MP状态的状态TLV和称为“受保护节点状态值元素”的新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 = 3 | Length | Addr Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Fam cont | Node address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 3 | Length | Addr Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Fam cont | Node address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : Protected Node Status Value Element (Type 3).
类型：受保护节点状态值元素（类型3）。
Length: The Length field is an unsigned integer that encodes the length of the Status Value following the Length field. The encoded Length varies based on the Address Family and is 6 octets for Address Family + IPv4 address and 18 octets for Address Family + IPv6 address.
长度：长度字段是一个无符号整数，它对长度字段后面的状态值的长度进行编码。编码长度因地址系列而异，地址系列+IPv4地址为6个八位字节，地址系列+IPv6地址为18个八位字节。
Addr Family: Two-octet quantity containing a value from IANA's "Address Family Numbers" registry [AFI] that encodes the address family for the node address.
Addr Family：两个八位组数量，包含IANA“地址系列号”注册表[AFI]中的一个值，该注册表对节点地址的地址系列进行编码。
Node address: Protected node address encoded according to the Address Family field.
节点地址：根据地址族字段编码的受保护节点地址。
When a PLR receives a Label Mapping for FEC <R,X> that includes a Protected Node Status, it will only use that label binding once the Node advertised in the Status value becomes unreachable. If the LSP is an MP2MP LSP, the PLR would have assigned a Label Mapping for the upstream MP2MP FEC Element to the MPT ([RFC6388], Section 3) for FEC <R,X>. This label binding on the MPT MUST only be used once node N becomes unreachable.
当PLR接收到包含受保护节点状态的FEC<R，X>的标签映射时，它将仅在状态值中公布的节点变得不可访问时使用该标签绑定。如果LSP是MP2MP LSP，则PLR会将上游MP2MP FEC元素的标签映射分配给FEC<R，X>的MPT（[RFC6388]，第3节）。MPT上的此标签绑定只能在节点N无法访问时使用。
The procedures to determine if a node is unreachable is a local decision and not spelled out in this document. Typically, link failure or Bidirectional Forwarding Detection (BFD) can be used to determine and detect node unreachability.
确定节点是否无法访问的过程是一个本地决定，本文档中没有详细说明。通常，链路故障或双向转发检测（BFD）可用于确定和检测节点不可达性。
Consider the following topology:
考虑下面的拓扑结构：
root
^
|
. (LSR1)
. / | .
. (M) | .
. \ | .
. (N) .
. / \ .
. / \.
(LSR2) (LSR3)
| |
root
^
|
. (LSR1)
. / | .
. (M) | .
. \ | .
. (N) .
. / \ .
. / \.
(LSR2) (LSR3)
| |
N: The node being protected. M: The backup node to protect link LSR1 - N. ...: Backup LSPs from LSR1 to LSR2 and LSR3.
N：被保护的节点。M：用于保护链路LSR1的备份节点-N…：将LSR1中的LSP备份到LSR2和LSR3。
Figure 3
图3
Assume that LSR1 is the PLR for protected node N and that LSR2 and LSR3 are MPTs for node N. When LSR1 discovers that node N is unreachable, it cannot immediately determine whether it is the link from LSR1 to N or the actual node N that has failed. In Figure 3,
假设LSR1是受保护节点N的PLR，LSR2和LSR3是节点N的MPT。当LSR1发现节点N不可访问时，它无法立即确定是从LSR1到N的链路还是实际节点N发生故障。在图3中，
the link between LSR1 and N is also protected using Fast Reroute (FRR) [RFC4090] link protection via node M. LSR1 MAY simultaneously invoke both link protection via node M to N using redirection of the traffic and node protection directly to LSR1 and LSR2. If only the link failed, LSR2 and LSR3 will receive the packets twice due to the two protection mechanisms. To prevent duplicate packets being forwarded to the receivers on the tree, LSR2 and LSR3 need to determine from which upstream node they should accept the packets. This can be either from the primary upstream LSR N or from the secondary upstream LSR1, but never both at the same time. The selection between the primary upstream LSR or (one or more) secondary upstream LSRs (on LSR2 and LSR3) is based on the reachability of the protected node N. As long as N is reachable from an MPT, the MPT should accept and forward the MPLS packets from N. Once N becomes unreachable, the LSPs from secondary upstream PLR LSRs (LSR1 in our example) are activated. Note that detecting if N is unreachable is a local decision and not spelled out in this document.
LSR1和N之间的链路也通过通过节点M使用快速重路由（FRR）[RFC4090]链路保护进行保护。LSR1可以通过将通信量重定向到LSR1和LSR2，通过节点M到N同时调用链路保护。如果只有链路发生故障，由于这两种保护机制，LSR2和LSR3将接收两次数据包。为了防止重复的数据包被转发到树上的接收器，LSR2和LSR3需要确定它们应该从哪个上游节点接受数据包。这可以来自主上游LSR N或来自次上游LSR1，但决不能同时来自二者。主要上游LSR或（一个或多个）次要上游LSR（在LSR2和LSR3上）之间的选择基于受保护节点N的可达性。只要N可从MPT访问，MPT应接受并转发来自N的MPLS数据包。一旦N变得不可访问，则来自次要上游PLR LSR（在我们的示例中为LSR1）的LSP被激活。注意，检测N是否不可到达是一个本地决定，本文档中没有详细说明。
Typically, link failure or BFD can be used to determine and detect node unreachability.
通常，链路故障或BFD可用于确定和检测节点不可达性。
Consider the following topology:
考虑下面的拓扑结构：
root
^
_ |
/. (LSR1)
/. /. | .\
/. (M). | .\
(P). \. | .\
\. ( N ) .(Q)
\. / \ ./
\. / \ ./
(LSR2) (LSR3)
| |
root
^
_ |
/. (LSR1)
/. /. | .\
/. (M). | .\
(P). \. | .\
\. ( N ) .(Q)
\. / \ ./
\. / \ ./
(LSR2) (LSR3)
| |
N: The node being protected. M: The backup node to protect link 'LSR1 - N'. P and Q: The nodes on the new primary path after failure of node N. ...: P2P backup LSPs.
N：被保护的节点。M：用于保护链路“LSR1-N”的备份节点。P和Q：节点N故障后新主路径上的节点…：P2P备份LSP。
Figure 4
图4
Assume that LSR1 has detected that node N is unreachable and invoked both the link protection and node protection procedures as described in this example. LSR1 is acting as PLR and sending traffic over both the backup P2P LSP to node N (via M) and the P2P LSPs directly to LSR2 and LSR3, acting as MPT LSRs. The sequence of events is dependent on whether the link from LSR1 to N has failed or node N itself has failed. The nodes downstream from the protected node (and participating in node protection) MUST have the capability to determine that the protected node has become unreachable. Otherwise, the procedures below cannot be applied.
假设LSR1检测到节点N不可访问，并调用了链路保护和节点保护过程，如本例所述。LSR1充当PLR，通过备份P2P LSP向节点N（通过M）发送流量，并通过P2P LSP直接向LSR2和LSR3发送流量，充当MPT LSR。事件顺序取决于从LSR1到N的链路是否发生故障，或者节点N本身是否发生故障。受保护节点下游的节点（以及参与节点保护的节点）必须能够确定受保护节点已无法访问。否则，无法应用以下程序。
If node N failed, both LSR2 and LSR3 will have changed the primary upstream LSR to the secondary upstream LSR (LSR1) due to node N being unreachable. With that, the label bindings previously assigned to LSR1 will be activated on the MPTs (LSR2 and LSR3) and the label binding to N will be disabled. Traffic is now switched over to the label bindings that were installed for node protection.
如果节点N失败，由于节点N不可访问，LSR2和LSR3都将主上游LSR更改为次上游LSR（LSR1）。这样，以前分配给LSR1的标签绑定将在MPT（LSR2和LSR3）上激活，而到N的标签绑定将被禁用。流量现在切换到为保护节点而安装的标签绑定。
If the link 'LSR1 - N' has failed, both LSR2 and LSR3 will not change the primary upstream LSR because node N is still reachable. LSR2 and LSR3 will receive traffic over two different bindings, the primary label binding assigned to node N (due to link protection via node M) as well as over the binding assigned to LSR1 for the node protection. Since the secondary upstream LSRs have not been activated, the traffic received due to node protection will be dropped. Node N will reconverge and update LSR2 and LSR3 (Section 2.3) with the information that the PLR address (LSR1) is no longer applicable and must be removed. In response, LSR2 and LSR3 MUST send a Label Withdraw to LSR1 to withdraw the label binding. This will stop the traffic being forwarded over the backup P2P LSPs for node protection. LSR1 will respond back with a Label Release as soon as the binding has been removed.
如果链路“LSR1-N”失败，则LSR2和LSR3都不会更改主上游LSR，因为节点N仍然是可访问的。LSR2和LSR3将通过两个不同的绑定接收流量，一个是分配给节点N的主标签绑定（由于通过节点M的链路保护），另一个是分配给LSR1的用于节点保护的绑定。由于二级上游LSR尚未激活，因此由于节点保护而接收的流量将被丢弃。节点N将使用PLR地址（LSR1）不再适用且必须删除的信息重新聚合并更新LSR2和LSR3（第2.3节）。作为响应，LSR2和LSR3必须向LSR1发送标签撤回，以撤回标签绑定。这将停止通过备份P2P LSP转发的流量，以保护节点。一旦绑定被移除，LSR1将立即以标签释放的方式进行响应。
The network will eventually reconverge and a new best path to the root will be found by LSR2 and LSR3. LSR2 will find that P is its new primary upstream LSR to reach the root and LSR3 will find Q. Note that although the current active upstream LSR can either be node N or LSR1 (depending on link or node failure), it does not matter for the following procedures. Both LSR2 and LSR3 SHOULD use the Make-Before-Break (MBB) procedures as described in Section 8 of [RFC6388] to switch to the new primary upstream node. As soon as the new primary upstream LSRs P and Q are activated, a Label Withdraw message
网络最终将重新聚合，LSR2和LSR3将找到通向根的新的最佳路径。LSR2将发现P是其到达根的新主上游LSR，LSR3将发现Q。注意，尽管当前活动的上游LSR可以是节点N或LSR1（取决于链路或节点故障），但以下过程并不重要。LSR2和LSR3都应使用[RFC6388]第8节所述的先通后断（MBB）程序切换到新的主上游节点。一旦新的主上游LSR P和Q被激活，标签撤销消息就会出现
MUST be sent to the old upstream LSR. Note that an upstream LSR switchover from a tLDP neighbor to a directly connected LDP neighbor is no different compared to switching between two directly connected neighbors. After the Label Withdraw message has been received by LSR1 or node N, forwarding will stop and a Label Release will be sent.
必须发送到旧的上游LSR。注意，从tLDP邻居到直接连接的LDP邻居的上游LSR切换与在两个直接连接的邻居之间切换没有什么不同。LSR1或节点N收到标签撤回消息后，转发将停止，并发送标签释放。
When it is determined that after reconvergence there is no more interest in the tLDP session between the MPT and the PLR, the tLDP session MAY be taken down. It is possible that having no more interest in the tLDP session is temporarily due to link flapping. In order to avoid the tLDP session from flapping, it is RECOMMENDED to apply a delay before tearing down the session. Determining the delay is a local implementation matter. If the operator is not concerned with the tLDP session flapping and/or other procedures are in place to avoid this altogether, there is no need to apply the delay.
当确定在重新会聚之后，MPT和PLR之间的tLDP会话中不再有兴趣时，tLDP会话可以被取下。可能由于链路抖动而暂时对tLDP会话不感兴趣。为了避免tLDP会话抖动，建议在中断会话之前应用延迟。确定延迟是本地实现问题。如果操作员不关心tLDP会话拍打和/或其他程序，以避免出现这种情况，则无需应用延迟。
In order to describe the capabilities of the participating LSRs, this document is organizing it per role in the network, i.e., Point of Local Repair (PLR), Merge Point (MPT), and protected node (as depicted in Figure 1).
为了描述参与LSR的能力，本文档按照网络中的每个角色进行组织，即本地修复点（PLR）、合并点（MPT）和受保护节点（如图1所示）。
A PLR node should handle the following conditions:
PLR节点应处理以下情况：
1. Accept an incoming tLDP session from the MPT LSR.
1. 接受来自MPT LSR的传入tLDP会话。
2. Support the receipt of a "Protected Node Status Value Element" status in an MP Status TLV over tLDP session.
2. 支持在MP Status TLV over tLDP会话中接收“受保护节点状态值元素”状态。
3. Upon node failure detection, capable of switching traffic towards one or more MPT(s) over a P2P LSP (bypassing N) using the labels previously advertised for MP LSPs over the tLDP session.
3. 在节点故障检测时，能够使用先前在tLDP会话上为MP LSP播发的标签，通过P2P LSP（绕过N）将流量切换到一个或多个MPT。
An LSR capable of performing these actions will advertise itself as PLR capable in the Node Protection Capability (see Section 5.4). This is a unidirectional capability announced from PLR to the protected LSR.
能够执行这些动作的LSR将在节点保护能力中作为PLR进行宣传（见第5.4节）。这是一种从PLR到受保护LSR的单向能力。
An MPT node should handle the following conditions;
MPT节点应处理以下情况：；
1. Support the receipt of "PLR Status Value Element" in an MP Status TLV from a protected node N.
1. 支持从受保护节点N接收MP状态TLV中的“PLR状态值元素”。
2. Support to transmit "Protected Node Status Value Element" in an MP Status TLV to a PLR.
2. 支持将MP状态TLV中的“受保护节点状态值元素”传输至PLR。
An LSR capable of performing these actions will advertise itself as MPT capable in the Node Protection Capability (see Section 5.4). This is a unidirectional capability from MPT to the protected LSR.
能够执行这些操作的LSR将在节点保护功能中将自己宣传为能够执行MPT（见第5.4节）。这是从MPT到受保护LSR的单向能力。
A protected node should handle the following conditions:
受保护节点应处理以下情况：
1. Determine the PLR and MPT capability for directly connected upstream and downstream LSRs for a given MP FEC.
1. 确定给定MP FEC的直接连接上游和下游LSR的PLR和MPT能力。
2. Support transmitting of "PLR Status Value Element" in an MP Status TLV to one or more downstream MPT LSRs.
2. 支持将MP状态TLV中的“PLR状态值元素”传输到一个或多个下游MPT LSR。
The protected LSR does not advertise any capability for mLDP Node Protection because it does not need to receive any of the defined MP Status values as described above. However, the protected node does play an important role in the signaling and setup of the node protection. For a given FEC, the protected node can only send PLR information to a downstream LSR if the PLR has signaled the PLR capability and the downstream LSR has signaled the MPT capability. When the downstream LSR (acting as MPT) receives the PLR Status, it can implicitly infer that the advertised LSR(s) are PLR capable. The MPT LSR can now proceed with setting up a tLDP session with the PLR(s) and MP LSP node protection signaling.
受保护的LSR不公布mLDP节点保护的任何功能，因为它不需要接收上述任何定义的MP状态值。然而，受保护节点在节点保护的信令和设置中起着重要作用。对于给定的FEC，如果PLR已经发出PLR能力的信号并且下游LSR已经发出MPT能力的信号，则受保护节点只能向下游LSR发送PLR信息。当下游LSR（充当MPT）接收到PLR状态时，它可以隐式地推断广告LSR具有PLR能力。MPT LSR现在可以使用PLR和MP LSP节点保护信令设置tLDP会话。
We define a single capability "MP Node Protection Capability" to announce the PLR and MPT capability.
我们定义了单个功能“MP节点保护功能”，以宣布PLR和MPT功能。
The format of the capability parameter TLV is as follows:
能力参数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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = 0x0972 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |P|M| 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| Type = 0x0972 | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |P|M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where
哪里
U/F bits: MUST be set to 1 and 0, respectively (as per [RFC5561]).
U/F位：必须分别设置为1和0（根据[RFC5561]）。
Type: MP Node Protection Capability (Type = 0x0972).
类型：MP节点保护能力（类型=0x0972）。
Length: Unsigned integer; MUST be set to 2.
长度：无符号整数；必须设置为2。
S bit: Set to 1 to announce and 0 to withdraw the capability (as per [RFC5561]).
S位：设置为1表示宣布，设置为0表示撤回能力（根据[RFC5561]）。
P bit: Set to 1 to indicate the PLR is capable of MP LSP node protection.
P位：设置为1表示PLR能够保护MP LSP节点。
M bit: Set to 1 to indicate the MPT is capable of MP LSP node protection.
M位：设置为1表示MPT能够保护MP LSP节点。
Reserved: MUST be zero on transmit and ignored on receipt.
保留：传输时必须为零，接收时忽略。
The above capability can be sent in an LDP Initialization message to announce capability at the session establishment time, or it can be sent in an LDP Capability message to dynamically update (announce or withdraw) its capability towards its peer using procedures specified in [RFC5561].
上述能力可以在LDP初始化消息中发送，以在会话建立时宣布能力，也可以在LDP能力消息中发送，以使用[RFC5561]中规定的过程动态更新（宣布或撤回）其对其对等方的能力。
An LSR that supports the PLR functionality LSR MAY send this capability to its downstream MP peers with P bit set; whereas, an LSR that supports the MPT functionality MAY send this capability to its upstream peer with M bit set. Moreover, an LSR that supports both the PLR and MPT functionality MAY sent this capability to its peers with both P and M bit set.
支持PLR功能LSR的LSR可将该功能发送给其下游MP对等方，并设置P位；然而，支持MPT功能的LSR可以将该功能发送到其上游对等方，并设置M位。此外，同时支持PLR和MPT功能的LSR可以向其具有P和M比特集的对等方发送该功能。
The procedures in this document add two new TLVs to existing LDP messages. Those TLVs can be protected by the mechanisms that are used to protect LDP messages as described in [RFC6388] and [RFC5920]. If it were possible to attack the mechanisms described in this document, an LSR (a PLR or a MPT) could be induced to support a large number of tLDP sessions and set up an even larger number of LSPs. The security mechanisms described in [RFC6388] and [RFC5920] are believed to be adequate, but an implementation could provide additional protection by counting such protection sessions and LSPs and producing a log message to the operator if a threshold is crossed.
本文档中的过程向现有LDP消息添加了两个新的TLV。这些TLV可以通过[RFC6388]和[RFC5920]中所述的用于保护LDP消息的机制进行保护。如果有可能攻击本文档中描述的机制，则可以诱导LSR（PLR或MPT）支持大量tLDP会话，并设置更多LSP。[RFC6388]和[RFC5920]中描述的安全机制被认为是足够的，但是实现可以通过计算此类保护会话和LSP并在超过阈值时向操作员生成日志消息来提供额外的保护。
IANA has allocated the following two new code points from the "LDP MP Status Value Element type" registry within the "Label Distribution Protocol (LDP) Parameters" registry.
IANA已从“标签分发协议（LDP）参数”注册表中的“LDP MP状态值元素类型”注册表中分配了以下两个新代码点。
Value | Name | Reference
------+----------------------------------------+-----------
2 | PLR Status Value Element | this doc
------+----------------------------------------+-----------
3 | Protected Node Status Value Element | this doc
Value | Name | Reference
------+----------------------------------------+-----------
2 | PLR Status Value Element | this doc
------+----------------------------------------+-----------
3 | Protected Node Status Value Element | this doc
IANA has assigned the following new code point for a new Capability Parameter TLV. The code point has been assigned from the IETF Consensus range of the "TLV Type Name Space" registry within the "Label Distribution Protocol (LDP) Parameters" registry.
IANA已为新功能参数TLV分配了以下新代码点。代码点已从“标签分发协议（LDP）参数”注册表中“TLV类型名称空间”注册表的IETF共识范围分配。
Value | Description | Reference | Notes/Reg Date
------+-------------------------------+-----------+---------------
0x0972| MP Node Protection Capability | this doc |
Value | Description | Reference | Notes/Reg Date
------+-------------------------------+-----------+---------------
0x0972| MP Node Protection Capability | this doc |
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.“LDP规范”，RFC 5036，DOI 10.17487/RFC5036，2007年10月<http://www.rfc-editor.org/info/rfc5036>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011, <http://www.rfc-editor.org/info/rfc6388>.
[RFC6388]Wijnands，IJ.，Ed.，Minei，I.，Ed.，Kompella，K.和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，RFC 6388，DOI 10.17487/RFC6388，2011年11月<http://www.rfc-editor.org/info/rfc6388>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, <http://www.rfc-editor.org/info/rfc5561>.
[RFC5561]托马斯，B.，拉扎，K.，阿加瓦尔，S.，阿加瓦尔，R.，和JL。Le Roux，“LDP能力”，RFC 5561，DOI 10.17487/RFC55611909年7月<http://www.rfc-editor.org/info/rfc5561>.
[RFC7060] Napierala, M., Rosen, E., and IJ. Wijnands, "Using LDP Multipoint Extensions on Targeted LDP Sessions", RFC 7060, DOI 10.17487/RFC7060, November 2013, <http://www.rfc-editor.org/info/rfc7060>.
[RFC7060]Napierala，M.，Rosen，E.，和IJ。Wijnands，“在目标LDP会话上使用LDP多点扩展”，RFC 7060，DOI 10.17487/RFC7060，2013年11月<http://www.rfc-editor.org/info/rfc7060>.
[AFI] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[AFI]IANA，“地址家庭编号”<http://www.iana.org/assignments/address-family-numbers>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI 10.17487/RFC4090, May 2005, <http://www.rfc-editor.org/info/rfc4090>.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE的快速重路由扩展”，RFC 4090，DOI 10.17487/RFC4090，2005年5月<http://www.rfc-editor.org/info/rfc4090>.
[RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, DOI 10.17487/RFC5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5286]Atlas，A.，Ed.，和A.Zinin，Ed.，“IP快速重路由的基本规范：无环路交替”，RFC 5286，DOI 10.17487/RFC5286，2008年9月<http://www.rfc-editor.org/info/rfc5286>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayangarps，“使用资源预留协议流量工程（RSVP-TE）对MPLS LSP建立的属性进行编码”，RFC 5420，DOI 10.17487/RFC5420，2009年2月<http://www.rfc-editor.org/info/rfc5420>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<http://www.rfc-editor.org/info/rfc5920>.
Acknowledgments
致谢
The authors thank Nagendra Kumar, Duan Hong, Martin Vigoureux, Kenji Fujihira, Loa Andersson, and Ben Campbell for their comments on this document. Also, many thanks to Elwyn Davies and Adrian Farrel for the detailed review and contribution to this document.
作者感谢Nagendra Kumar、Duan Hong、Martin Vigoureux、Kenji Fujihira、Loa Andersson和Ben Campbell对本文件的评论。另外，非常感谢Elwyn Davies和Adrian Farrel对本文件的详细审查和贡献。
Contributors
贡献者
The following individual contributed to this document:
以下个人对本文件作出了贡献：
Eric Rosen Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States Email: erosen@juniper.net
Eric Rosen Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886电子邮件：erosen@juniper.net
Authors' Addresses
作者地址
IJsbrand Wijnands (editor) Cisco Systems, Inc. De kleetlaan 6a Diegem 1831 Belgium
IJsbrand Wijnands（编辑）思科系统公司De kleetlaan 6a Diegem 1831比利时
Email: ice@cisco.com
Email: ice@cisco.com
Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Ottawa, Ontario K2K-3E8 Canada
Kamran Raza Cisco Systems，Inc.加拿大安大略省渥太华市创新大道2000号K2K-3E8
Email: skraza@cisco.com
Email: skraza@cisco.com
Alia Atlas Juniper Networks, Inc. 10 Technology Park Drive Westford, MA 01886 United States
Alia Atlas Juniper Networks，Inc.美国马萨诸塞州韦斯特福德科技园大道10号01886
Email: akatlas@juniper.net
Email: akatlas@juniper.net
Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 United States
Jeff Tantsura Ericsson美国加利福尼亚州圣何塞霍尔格大道300号，邮编95134
Email: jeff.tantsura@ericsson.com
Email: jeff.tantsura@ericsson.com
Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 United States
Quintin Zhao华为技术125美国马萨诸塞州阿克顿市纳戈科技园01719
Email: quintin.zhao@huawei.com
Email: quintin.zhao@huawei.com