Internet Engineering Task Force (IETF) S. Esale
Request for Comments: 8223 R. Torvi
Updates: 7473 Juniper Networks
Category: Standards Track L. Jalil
ISSN: 2070-1721 Verizon
U. Chunduri
Huawei
K. Raza
Cisco Systems, Inc.
August 2017
Internet Engineering Task Force (IETF) S. Esale
Request for Comments: 8223 R. Torvi
Updates: 7473 Juniper Networks
Category: Standards Track L. Jalil
ISSN: 2070-1721 Verizon
U. Chunduri
Huawei
K. Raza
Cisco Systems, Inc.
August 2017
Application-Aware Targeted LDP
应用感知目标LDP
Abstract
摘要
Recent Targeted Label Distribution Protocol (tLDP) applications, such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires, may automatically establish a tLDP session with any Label Switching Router (LSR) in a network. The initiating LSR has information about the targeted applications to administratively control initiation of the session. However, the responding LSR has no such information to control acceptance of this session. This document defines a mechanism to advertise and negotiate the Targeted Application Capability (TAC) during LDP session initialization. As the responding LSR becomes aware of targeted applications, it may establish a limited number of tLDP sessions for certain applications. In addition, each targeted application is mapped to LDP Forwarding Equivalence Class (FEC) elements to advertise only necessary LDP FEC label bindings over the session. This document updates RFC 7473 for enabling advertisement of LDP FEC label bindings over the session.
最近的目标标签分发协议（tLDP）应用程序，例如远程无环替代（LFA）和BGP自动发现的伪线，可以自动与网络中的任何标签交换路由器（LSR）建立tLDP会话。发起LSR具有关于目标应用程序的信息，以管理性地控制会话的发起。但是，响应的LSR没有此类信息来控制此会话的接受。本文档定义了在LDP会话初始化期间公布和协商目标应用程序能力（TAC）的机制。当响应的LSR意识到目标应用时，它可以为某些应用建立有限数量的tLDP会话。此外，每个目标应用程序都映射到LDP转发等价类（FEC）元素，以便在会话中仅公布必要的LDP FEC标签绑定。本文档更新了RFC 7473，以便在会话期间发布LDP FEC标签绑定。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8223.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8223.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Terminology ................................................4
2. Targeted Application Capability .................................5
2.1. Encoding ...................................................5
2.2. Procedures .................................................5
2.3. LDP Message Procedures .....................................8
2.3.1. Initialization Message ..............................8
2.3.2. Capability Message ..................................8
3. Targeted Application FEC Advertisement Procedures ...............9
4. Interaction of Targeted Application Capabilities and State
Advertisement Control Capabilities .............................10
5. Use Cases ......................................................12
5.1. Remote LFA Automatic Targeted Session .....................12
5.2. FEC 129 Auto-discovery Targeted Session ...................13
5.3. LDP over RSVP and Remote LFA Targeted Session .............13
5.4. mLDP Node Protection Targeted Session .....................13
6. Security Considerations ........................................14
7. IANA Considerations ............................................14
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Acknowledgments ...................................................17
Contributors ......................................................17
Authors' Addresses ................................................18
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
1.2. Terminology ................................................4
2. Targeted Application Capability .................................5
2.1. Encoding ...................................................5
2.2. Procedures .................................................5
2.3. LDP Message Procedures .....................................8
2.3.1. Initialization Message ..............................8
2.3.2. Capability Message ..................................8
3. Targeted Application FEC Advertisement Procedures ...............9
4. Interaction of Targeted Application Capabilities and State
Advertisement Control Capabilities .............................10
5. Use Cases ......................................................12
5.1. Remote LFA Automatic Targeted Session .....................12
5.2. FEC 129 Auto-discovery Targeted Session ...................13
5.3. LDP over RSVP and Remote LFA Targeted Session .............13
5.4. mLDP Node Protection Targeted Session .....................13
6. Security Considerations ........................................14
7. IANA Considerations ............................................14
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Acknowledgments ...................................................17
Contributors ......................................................17
Authors' Addresses ................................................18
LDP uses the Extended Discovery mechanism to establish the Targeted LDP (tLDP) adjacency and subsequent session, as described in [RFC5036]. A Label Switching Router (LSR) initiates Extended Discovery by sending a tLDP Hello to a specific address. The remote LSR decides to either accept or ignore the tLDP Hello based on local configuration only. A tLDP application is an application that uses a tLDP session to exchange information such as FEC label bindings ("FEC" stands for "Forwarding Equivalence Class") with a peer LSR in the network. For an application such as FEC 128 pseudowire, the remote LSR is configured with the source LSR address so that it can use that information to accept or ignore a given tLDP Hello.
LDP使用扩展发现机制建立目标LDP（tLDP）邻接和后续会话，如[RFC5036]所述。标签交换路由器（LSR）通过向特定地址发送tLDP Hello来启动扩展发现。远程LSR仅根据本地配置决定接受或忽略tLDP Hello。tLDP应用程序是使用tLDP会话与网络中的对等LSR交换信息（如FEC标签绑定（“FEC”代表“转发等价类”）的应用程序。对于FEC 128伪线等应用程序，远程LSR配置有源LSR地址，以便它可以使用该信息接受或忽略给定的tLDP Hello。
However, applications such as remote Loop-Free Alternates (LFAs) and BGP auto-discovered pseudowires automatically initiate asymmetric Extended Discovery to any LSR in a network based on local state only. With these applications, the remote LSR is not explicitly configured with the source LSR address. So, the remote LSR either responds to all tLDP Hellos or ignores them.
然而，诸如远程无环替换（LFA）和BGP自动发现伪线等应用程序仅基于本地状态自动启动对网络中任何LSR的非对称扩展发现。对于这些应用程序，远程LSR没有显式配置源LSR地址。因此，远程LSR要么响应所有tLDP hello，要么忽略它们。
In addition, since the session is initiated and established after adjacency formation, the responding LSR has no information on targeted applications available from which it can choose a session with a targeted application that it is configured to support. Also, the initiating LSR may employ a limit per application on locally initiated automatic tLDP sessions; however, the responding LSR has no such information to employ a similar limit on the incoming tLDP sessions. Further, the responding LSR does not know whether the source LSR is establishing a tLDP session for configured applications, automatic applications, or both.
此外，由于会话是在邻接形成之后发起和建立的，因此响应LSR没有关于目标应用程序的可用信息，它可以从中选择具有其配置为支持的目标应用程序的会话。此外，发起LSR可以对本地发起的自动tLDP会话采用每个应用的限制；然而，响应的LSR没有这样的信息来对传入的tLDP会话采用类似的限制。此外，响应LSR不知道源LSR是否正在为配置的应用程序、自动应用程序或两者建立tLDP会话。
This document proposes and describes a solution to advertise the Targeted Application Capability (TAC), consisting of a list of targeted applications, during initialization of a tLDP session. It also defines a mechanism to enable a new application and disable an old application after session establishment. This capability advertisement provides the responding LSR with the necessary information to control the acceptance of tLDP sessions per application. For instance, an LSR may accept all BGP auto-discovered tLDP sessions as described in [RFC6074] but may only accept a limited number of remote LFA tLDP sessions as described in [RFC7490].
本文档提出并描述了一种在tLDP会话初始化期间公布目标应用程序功能（TAC）的解决方案，该功能由目标应用程序列表组成。它还定义了一种机制，用于在会话建立后启用新应用程序和禁用旧应用程序。此功能公告为响应的LSR提供必要的信息，以控制每个应用程序接受tLDP会话。例如，LSR可以接受[RFC6074]中所述的所有BGP自动发现tLDP会话，但只能接受[RFC7490]中所述的有限数量的远程LFA tLDP会话。
Also, the tLDP application is mapped to LDP FEC element types to advertise specific application FECs only, avoiding the advertisement of other unnecessary FECs over a tLDP session.
此外，tLDP应用被映射到LDP FEC元素类型以仅通告特定应用FEC，从而避免在tLDP会话上通告其他不必要的FEC。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
In addition to the terminology defined in [RFC7473], this document uses the following terms:
除[RFC7473]中定义的术语外，本文件还使用以下术语：
tLDP : Targeted LDP TAC : Targeted Application Capability TAE : Targeted Application Element TA-Id : Targeted Application Identifier SAC : State Advertisement Control LSR : Label Switching Router mLDP : Multipoint LDP PQ node : Remote LFA next hops RSVP-TE : RSVP Traffic Engineering P2MP : Point-to-Multipoint PW : Pseudowire P2P-PW : Point-to-Point Pseudowire MP2MP : Multipoint-to-Multipoint HSMP LSP: Hub and Spoke Multipoint Label Switched Path LSP : Label Switched Path MP2P : Multipoint-to-Point MPT : Merge Point
tLDP:目标LDP TAC:目标应用程序能力TAE:目标应用程序元素TA Id:目标应用程序标识符SAC:状态播发控制LSR:标签交换路由器mLDP:多点LDP PQ节点：远程LFA下一跳RSVP-TE:RSVP流量工程P2MP:点对多点PW:伪线P2P-PW:点对点伪线MP2MP:多点对多点HSMP LSP:集线器和辐条多点标签交换路径LSP:标签交换路径MP2P:多点对点MPT:合并点
An LSR MAY advertise that it is capable of negotiating a tLDP application list over a tLDP session by using the capability advertisement as defined in [RFC5561] and encoded as follows:
LSR可通过使用[RFC5561]中定义并编码如下的能力公告，公告其能够在tLDP会话上协商tLDP应用程序列表：
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| TLV Code Point | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ Capability Data |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| TLV Code Point | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | |
+-+-+-+-+-+-+-+-+ Capability Data |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flag "U" MUST be set to 1 to indicate that this capability must be silently ignored if unknown. The TAC's Capability Data field contains the Targeted Application Element (TAE) information, encoded as follows:
必须将标志“U”设置为1，以指示如果未知，必须默默忽略此功能。TAC的能力数据字段包含目标应用程序元素（TAE）信息，编码如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TA-Id |E| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TA-Id |E| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TA-Id: A 16-bit Targeted Application Identifier value.
TA Id：16位目标应用程序标识符值。
E: E-bit (Enable bit). Indicates whether the sender is advertising or withdrawing the TAE. The E-bit value is used as follows:
E:E位（启用位）。指示发件人是在公布还是在撤回TAE。E位值的使用如下所示：
1 - The TAE is advertising the targeted application. 0 - The TAE is withdrawing the targeted application.
1-TAE正在为目标应用程序做广告。0-TAE正在撤回目标应用程序。
At tLDP session establishment time, an LSR MAY include a new capability TLV, the TAC TLV, as an optional TLV in the LDP Initialization message. The TAC TLV's Capability data MAY consist of zero or more TAEs, each pertaining to a unique TA-Id that an LSR supports over the session. If the receiver LSR receives the same TA-Id in more than one TAE, it MUST process the first element and
在tLDP会话建立时，LSR可以包括新能力TLV，即TAC TLV，作为LDP初始化消息中的可选TLV。TAC TLV的能力数据可能由零个或多个TAE组成，每个TAE都属于LSR在会话期间支持的唯一TA Id。如果接收器LSR在多个TAE中接收到相同的TA Id，则它必须处理第一个元素并
ignore the duplicate elements. If the receiver LSR receives an unknown TA-Id in the TAE, it MUST silently ignore such a TAE and continue processing the rest of the TLV.
忽略重复的元素。如果接收器LSR在TAE中接收到未知的TA Id，它必须默默地忽略此类TAE并继续处理TLV的其余部分。
If the receiver LSR does not receive the TAC TLV in the Initialization message or it does not understand the TAC TLV, the TAC negotiation is considered unsuccessful and the session establishment proceeds as per [RFC5036]. On receipt of a valid TAC TLV, an LSR MUST generate its own TAC TLV with TAEs consisting of unique TA-Ids that it supports over the tLDP session. If there is at least one common TAE between the TAC TLV it has received and its own, the session MUST proceed to establishment as per [RFC5036]. If not, an LSR MUST send a 'Session Rejected/Targeted Application Capability Mismatch' Notification message to the peer and close the session. The initiating LSR SHOULD tear down the corresponding tLDP adjacency after sending or receiving a 'Session Rejected/Targeted Application Capability Mismatch' Notification message to or from the responding LSR, respectively.
如果接收器LSR没有在初始化消息中接收到TAC TLV，或者它不理解TAC TLV，则认为TAC协商不成功，会话建立按照[RFC5036]进行。收到有效的TAC TLV后，LSR必须生成自己的TAC TLV，TAE由其在tLDP会话中支持的唯一TA ID组成。如果收到的TAC TLV与其自己的TLV之间至少存在一个公共TAE，则会话必须按照[RFC5036]进行建立。否则，LSR必须向对等方发送“会话被拒绝/目标应用程序功能不匹配”通知消息并关闭会话。发起LSR应在分别向响应LSR发送或从响应LSR接收“会话拒绝/目标应用程序能力不匹配”通知消息后，拆除相应的tLDP邻接。
If both of the peers support the TAC TLV, an LSR decides to establish or close a tLDP session based on the negotiated list of targeted applications. For example, an initiating LSR advertises A, B, and C as TA-Ids, and the responding LSR advertises C, D, and E as TA-Ids. Then, the negotiated TA-Id as per both LSRs is C. In another example, an initiating LSR advertises A, B, and C as TA-Ids, and the responding LSR, which acts as a passive LSR, advertises all of the applications -- A, B, C, D, and E -- as TA-Ids that it supports over this session. The negotiated targeted applications as per both LSRs are then A, B, and C. Finally, if the initiating LSR advertises A, B, and C as TA-Ids and the responding LSR advertises D and E as TA-Ids, then the negotiated targeted applications as per both LSRs are "none". Therefore, if the intersection of the sets of received and sent TA-Ids is null, then the LSR sends a 'Session Rejected/Targeted Application Capability Mismatch' Notification message to the peer LSR and closes the session.
如果两个对等方都支持TAC TLV，则LSR根据协商的目标应用程序列表决定建立或关闭tLDP会话。例如，发起LSR将A、B和C播发为TA id，而响应LSR将C、D和E播发为TA id。然后，根据两个LSR协商的TA Id是C。在另一个示例中，发起LSR将A、B和C作为TA Id播发，而作为被动LSR的响应LSR将所有应用程序（A、B、C、D和E）作为其在该会话中支持的TA Id播发。然后，根据两个LSR协商的目标应用程序为A、B和C。最后，如果发起LSR将A、B和C作为TA ID播发，而响应LSR将D和E作为TA ID播发，则根据两个LSR协商的目标应用程序为“无”。因此，如果接收和发送的TA ID集合的交集为空，则LSR向对等LSR发送“会话拒绝/目标应用程序能力不匹配”通知消息，并关闭会话。
When the responding LSR playing the active role [RFC5036] in LDP session establishment receives a 'Session Rejected/Targeted Application Capability Mismatch' Notification message, it MUST set its session setup retry interval to a maximum value -- that is, 0xFFFF. The session MAY stay in a non-existent state. When it detects a change in the initiating LSR or local LSR configuration pertaining to the TAC TLV, it MUST clear the session setup backoff delay associated with the session to reattempt session establishment. An LSR detects the configuration change on the other LSR upon receipt of a tLDP Hello message that has a higher configuration sequence number than the earlier tLDP Hello message.
当在LDP会话建立中扮演活动角色[RFC5036]的响应LSR收到“会话被拒绝/目标应用程序能力不匹配”通知消息时，它必须将其会话设置重试间隔设置为最大值——即0xFFFF。会话可能处于不存在的状态。当检测到与TAC TLV相关的初始LSR或本地LSR配置发生变化时，必须清除与会话相关的会话设置退避延迟，以重新尝试会话建立。LSR在收到配置序列号高于先前tLDP Hello消息的tLDP Hello消息后，检测到另一个LSR上的配置更改。
When the initiating LSR playing the active role in LDP session establishment receives a 'Session Rejected/Targeted Application Capability Mismatch' Notification message, it MUST either (1) close the session and tear down the corresponding tLDP adjacency or (2) set its session setup retry interval to a maximum value -- that is, 0xFFFF.
当在LDP会话建立中扮演主动角色的发起LSR收到“会话拒绝/目标应用程序能力不匹配”通知消息时，它必须（1）关闭会话并拆除相应的tLDP邻接或（2）将其会话设置重试间隔设置为最大值，即0xFFFF。
If the initiating LSR decides to tear down the associated tLDP adjacency, the session is closed on the initiating LSR as well as the responding LSR. It MAY also take appropriate actions. For instance, if an automatic session intended to support the remote LFA application is rejected by the responding LSR, the initiating LSR may inform the IGP to calculate another PQ node [RFC7490] for the route or set of routes. More specific actions are a local matter and are outside the scope of this document.
如果发起LSR决定拆除相关的tLDP邻接，则在发起LSR和响应LSR上关闭会话。它还可以采取适当的行动。例如，如果打算支持远程LFA应用的自动会话被响应LSR拒绝，则发起LSR可以通知IGP为路由或路由集计算另一个PQ节点[RFC7490]。更具体的行动属于本地事务，不在本文件范围内。
If the initiating LSR sets the session setup retry interval to maximum, the session MAY stay in a non-existent state. When this LSR detects a change in the responding LSR configuration or its own configuration pertaining to the TAC TLV, it MUST clear the session setup backoff delay associated with the session in order to reattempt session establishment.
如果启动LSR将会话设置重试间隔设置为最大值，则会话可能处于不存在状态。当此LSR检测到响应LSR配置或其自身与TAC TLV相关的配置发生变化时，它必须清除与会话相关的会话设置退避延迟，以便重新尝试会话建立。
After a tLDP session using the TAC mechanism has been established, the initiating and responding LSRs MUST distribute FEC label bindings for the negotiated applications only. For instance, if the tLDP session is established for a BGP auto-discovered pseudowire, only FEC 129 label bindings MUST be distributed over the session. Similarly, an LSR operating in downstream on-demand mode MUST request FEC label bindings for the negotiated applications only.
使用TAC机制建立tLDP会话后，发起和响应的LSR必须仅为协商的应用程序分发FEC标签绑定。例如，如果为BGP自动发现的伪线建立tLDP会话，则只有FEC 129标签绑定必须分布在会话上。类似地，在下游按需模式下运行的LSR必须仅为协商的应用程序请求FEC标签绑定。
If the TAC and the Dynamic Capability [RFC5561] are negotiated during session initialization, the TAC MAY be renegotiated after session establishment by sending an updated TAC TLV in the LDP Capability message. The updated TAC TLV carries TA-Ids with an incremental update only. The updated TLV MUST consist of one or more TAEs with the E-bit set (1) or off (0), to advertise or withdraw the new application and the old application, respectively. This may lead to advertisements or withdrawals of certain types of FEC label bindings over the session or to teardown of the tLDP adjacency and, subsequently, the session.
如果在会话初始化期间协商TAC和动态能力[RFC5561]，则可在会话建立后通过在LDP能力消息中发送更新的TAC TLV来重新协商TAC。更新的TAC TLV仅携带增量更新的TA ID。更新的TLV必须由一个或多个E位设置为（1）或关闭（0）的TAE组成，以分别公布或撤回新应用程序和旧应用程序。这可能导致在会话期间播发或撤回某些类型的FEC标签绑定，或导致tLDP邻接和随后会话的断开。
The TAC is advertised on the tLDP session only. If the tLDP session changes to a link session, an LSR SHOULD withdraw it with the S-bit set to 0. Similarly, if the link session changes to tLDP, an LSR SHOULD advertise it via the Capability message. If the capability negotiation fails, this may lead to destruction of the tLDP session.
TAC仅在tLDP会话上发布。如果tLDP会话更改为链路会话，则LSR应在S位设置为0的情况下将其撤回。类似地，如果链路会话更改为tLDP，则LSR应通过能力消息通告该会话。如果能力协商失败，这可能导致tLDP会话的破坏。
By default, an LSR SHOULD accept tLDP Hellos in order to then accept or reject the tLDP session based on the application information.
默认情况下，LSR应接受tLDP Hellos，以便根据应用程序信息接受或拒绝tLDP会话。
In addition, an LSR SHOULD allow the configuration of any TA-Id in order to facilitate the use of private TA-Ids by a network operator.
此外，LSR应允许配置任何TA Id，以便于网络运营商使用专用TA Id。
1. The S-bit of the TAC TLV MUST be set to 1 to advertise the TAC and SHOULD be ignored on receipt, as described in [RFC5561].
1. 如[RFC5561]所述，TAC TLV的S位必须设置为1以公布TAC，并且在收到时应忽略。
2. The E-bit of the TAE MUST be set to 1 to enable the targeted application and SHOULD be ignored on receipt.
2. TAE的E位必须设置为1才能启用目标应用程序，并且在收到时应忽略。
3. An LSR MAY add the State Advertisement Control Capability by mapping the TAE to the State Advertisement Control (SAC) elements as defined in Section 4.
3. LSR可以通过将TAE映射到第4节中定义的状态广告控制（SAC）元素来添加状态广告控制能力。
After a change to local configuration, the initiating or responding LSR may renegotiate the TAC via the Capability message.
更改本地配置后，发起或响应的LSR可通过能力消息重新协商TAC。
1. The S-bit of the TAC is set to 1 or 0 to advertise or withdraw it.
1. TAC的S位设置为1或0，以播发或收回它。
2. After the configuration change, if there is no common TAE between its new TAE list and the peer's TAE list, the LSR MUST send a 'Session Rejected/Targeted Application Capability Mismatch' Notification message and close the session.
2. 配置更改后，如果其新TAE列表和对等TAE列表之间没有公共TAE，则LSR必须发送“会话拒绝/目标应用程序功能不匹配”通知消息并关闭会话。
3. If there is a common TAE, an LSR MAY also update the SAC Capability based on the updated TAC, as described in Section 4, and send the updated TAC and SAC Capability in a Capability message to the peer.
3. 如果存在公共TAE，LSR还可以根据更新的TAC更新SAC能力，如第4节所述，并在能力消息中将更新的TAC和SAC能力发送给对等方。
4. A receiving LSR processes the Capability message with the TAC TLV. If the S-bit is set to 0, the TAC is disabled for the session.
4. 接收LSR使用TAC TLV处理能力消息。如果S位设置为0，则会禁用会话的TAC。
5. If the S-bit is set to 1, the LSR processes a list of TAEs from the TAC's data with the E-bit set to 1 or 0 to update the peer's TAE.
5. 如果S位设置为1，则LSR处理TAC数据中的TAE列表，E位设置为1或0，以更新对等方的TAE。
The tLDP application MUST be mapped to LDP FEC element types as follows to advertise only necessary LDP FEC label bindings over the tLDP session.
tLDP应用程序必须映射到LDP FEC元素类型，如下所示，以便在tLDP会话上仅公布必要的LDP FEC标签绑定。
Targeted Application Description FEC Mappings
+----------------------+------------------------+------------------+
|LDPv4 Tunneling | LDP IPv4 over RSVP-TE | IPv4 prefix |
| | or other MPLS tunnel | |
+----------------------+------------------------+------------------+
| | | |
|LDPv6 Tunneling | LDP IPv6 over RSVP-TE | IPv6 prefix |
| | or other MPLS tunnel | |
+----------------------+------------------------+------------------+
|mLDP Tunneling | mLDP over RSVP-TE or | P2MP |
| | other MPLS tunnel | MP2MP-up |
| | | MP2MP-down |
| | | HSMP-downstream |
| | | HSMP-upstream |
+----------------------+------------------------+------------------+
| | | |
|LDPv4 remote LFA | LDPv4 over LDPv4 or | IPv4 prefix |
| | other MPLS tunnel | |
+----------------------+------------------------+------------------+
|LDPv6 remote LFA | LDPv6 over LDPv6 or | IPv6 prefix |
| | other MPLS tunnel | |
+----------------------+------------------------+------------------+
| | | |
|LDP FEC 128 PW | LDP FEC 128 Pseudowire | PWid FEC element |
+----------------------+------------------------+------------------+
| | | |
|LDP FEC 129 PW | LDP FEC 129 Pseudowire | Generalized PWid |
| | | FEC element |
+----------------------+------------------------+------------------+
| | | FEC types as |
|LDP Session Protection| LDP session protection | per protected |
| | | session |
+----------------------+------------------------+------------------+
|LDP ICCP | LDP Inter-Chassis | |
| | Communication Protocol | None |
+----------------------+------------------------+------------------+
| | | |
|LDP P2MP PW | LDP P2MP Pseudowire | P2MP PW Upstream |
| | | FEC element |
Targeted Application Description FEC Mappings
+----------------------+------------------------+------------------+
|LDPv4 Tunneling | LDP IPv4 over RSVP-TE | IPv4 prefix |
| | or other MPLS tunnel | |
+----------------------+------------------------+------------------+
| | | |
|LDPv6 Tunneling | LDP IPv6 over RSVP-TE | IPv6 prefix |
| | or other MPLS tunnel | |
+----------------------+------------------------+------------------+
|mLDP Tunneling | mLDP over RSVP-TE or | P2MP |
| | other MPLS tunnel | MP2MP-up |
| | | MP2MP-down |
| | | HSMP-downstream |
| | | HSMP-upstream |
+----------------------+------------------------+------------------+
| | | |
|LDPv4 remote LFA | LDPv4 over LDPv4 or | IPv4 prefix |
| | other MPLS tunnel | |
+----------------------+------------------------+------------------+
|LDPv6 remote LFA | LDPv6 over LDPv6 or | IPv6 prefix |
| | other MPLS tunnel | |
+----------------------+------------------------+------------------+
| | | |
|LDP FEC 128 PW | LDP FEC 128 Pseudowire | PWid FEC element |
+----------------------+------------------------+------------------+
| | | |
|LDP FEC 129 PW | LDP FEC 129 Pseudowire | Generalized PWid |
| | | FEC element |
+----------------------+------------------------+------------------+
| | | FEC types as |
|LDP Session Protection| LDP session protection | per protected |
| | | session |
+----------------------+------------------------+------------------+
|LDP ICCP | LDP Inter-Chassis | |
| | Communication Protocol | None |
+----------------------+------------------------+------------------+
| | | |
|LDP P2MP PW | LDP P2MP Pseudowire | P2MP PW Upstream |
| | | FEC element |
+----------------------+------------------------+------------------+
| | | P2MP |
|mLDP Node Protection | mLDP node protection | MP2MP-up |
| | | MP2MP-down |
| | | HSMP-downstream |
| | | HSMP-upstream |
+----------------------+------------------------+------------------+
| | | |
|IPv4 intra-area FECs* | IPv4 intra-area FECs* | IPv4 prefix |
+----------------------+------------------------+------------------+
| | | |
|IPv6 intra-area FECs* | IPv6 intra-area FECs* | IPv6 prefix |
+----------------------+------------------------+------------------+
+----------------------+------------------------+------------------+
| | | P2MP |
|mLDP Node Protection | mLDP node protection | MP2MP-up |
| | | MP2MP-down |
| | | HSMP-downstream |
| | | HSMP-upstream |
+----------------------+------------------------+------------------+
| | | |
|IPv4 intra-area FECs* | IPv4 intra-area FECs* | IPv4 prefix |
+----------------------+------------------------+------------------+
| | | |
|IPv6 intra-area FECs* | IPv6 intra-area FECs* | IPv6 prefix |
+----------------------+------------------------+------------------+
* Intra-area FECs: FECs that are on the shortest-path tree and are not leafs of the shortest-path tree.
* 区域内FEC：位于最短路径树上且不是最短路径树叶子的FEC。
4. Interaction of Targeted Application Capabilities and State Advertisement Control Capabilities
4. 目标应用程序功能和状态播发控制功能的交互
As described in this document, the set of TAEs negotiated between two LDP peers advertising the TAC represents the willingness of both peers to advertise state information for a set of applications. The set of applications negotiated by the TAC mechanism is symmetric between the two LDP peers. In the absence of further mechanisms, two LDP peers will both advertise state information for the same set of applications.
如本文件所述，两个LDP对等方之间协商的TAE集合表示两个对等方愿意为一组应用程序发布状态信息。由TAC机制协商的应用程序集在两个LDP对等方之间是对称的。在缺乏进一步机制的情况下，两个LDP对等方都将为同一组应用程序发布状态信息。
As described in [RFC7473], the SAC TLV can be used by an LDP speaker to communicate its interest or disinterest in receiving state information from a given peer for a particular application. Two LDP peers can use the SAC mechanism to create asymmetric advertisements of state information between the two peers.
如[RFC7473]中所述，LDP演讲者可以使用SAC TLV来传达其对从特定应用的给定对等方接收状态信息的兴趣或不感兴趣。两个LDP对等方可以使用SAC机制在两个对等方之间创建状态信息的不对称广告。
The TAC negotiation facilitates the awareness of targeted applications to both of the peers. It enables them to advertise only necessary LDP FEC label bindings corresponding to negotiated applications. With the SAC, the responding LSR is not aware of targeted applications. Thus, it may be unable to communicate its interest or disinterest in receiving state information from the peer. Therefore, when the responding LSR is not aware of targeted applications such as remote LFAs and BGP auto-discovered pseudowires, the TAC mechanism should be used, and when the responding LSR is aware (with appropriate configuration) of targeted applications such as FEC 128 pseudowire, the SAC mechanism should be used. Also, after the TAC mechanism makes the responding LSR aware of targeted applications, the SAC mechanism may be used to communicate its
TAC协商有助于两个对等方了解目标应用程序。它使他们能够只公布与协商应用程序相对应的必要LDP FEC标签绑定。对于SAC，响应的LSR不知道目标应用程序。因此，它可能无法传达其对从对等方接收状态信息的兴趣或不感兴趣。因此，当响应LSR不知道诸如远程LFA和BGP自动发现伪线之类的目标应用时，应使用TAC机制，并且当响应LSR知道（具有适当配置）诸如FEC 128伪线之类的目标应用时，应使用SAC机制。此外，在TAC机制使响应LSR意识到目标应用之后，SAC机制可用于通信其应用
disinterest in receiving state information from the peer for a particular negotiated application, creating asymmetric advertisements.
对从对等方接收特定协商应用程序的状态信息不感兴趣，从而创建不对称广告。
Thus, the TAC mechanism enables two LDP peers to symmetrically advertise state information for negotiated targeted applications. Further, the SAC mechanism enables both of them to asymmetrically disable receipt of state information for some of the already-negotiated targeted applications. Collectively, the TAC mechanism and the SAC mechanism can both be used to control the FEC label bindings that are advertised over the tLDP session. For instance, suppose that the initiating LSR establishes a tLDP session, using the TAC mechanism, with the responding LSR for remote LFA and FEC 129 PW targeted applications. So, each LSR advertises the corresponding FEC label bindings. Further, suppose that the initiating LSR is not the PQ node for the responding LSR's remote LFA IGP calculations. In such a case, the responding LSR may use the SAC mechanism to convey its disinterest in receiving state information for remote LFA tLDP applications.
因此，TAC机制使得两个LDP对等方能够对称地为协商的目标应用程序发布状态信息。此外，SAC机制使它们都能够不对称地禁止接收某些已协商的目标应用程序的状态信息。总的来说，TAC机制和SAC机制都可用于控制通过tLDP会话播发的FEC标签绑定。例如，假设发起LSR使用TAC机制与响应LSR建立tLDP会话，用于远程LFA和FEC 129 PW目标应用。因此，每个LSR播发相应的FEC标签绑定。此外，假设发起LSR不是响应LSR的远程LFA IGP计算的PQ节点。在这种情况下，响应LSR可使用SAC机制来传达其对接收远程LFA tLDP应用的状态信息的不感兴趣。
For a given tLDP session, the TAC mechanism can be used without the SAC mechanism, and the SAC mechanism can be used without the TAC mechanism. It is useful to discuss the behavior that occurs when the TAC and SAC mechanisms are used on the same tLDP session. The TAC mechanism MUST take precedence over the SAC mechanism with respect to enabling applications for which state information will be advertised. For a tLDP session using the TAC mechanism, the LDP peers MUST NOT advertise state information for an application that has not been negotiated in the most recent TAE list (referred to as a non-negotiated application). This is true even if one of the peers announces its interest in receiving state information that corresponds to the non-negotiated application by sending a SAC TLV. In other words, when the TAC mechanism is being used, the SAC mechanism cannot and should not enable state information advertisements for applications that have not been enabled by the TAC mechanism.
对于给定的tLDP会话，可以在不使用SAC机制的情况下使用TAC机制，也可以在不使用TAC机制的情况下使用SAC机制。讨论在同一tLDP会话上使用TAC和SAC机制时发生的行为非常有用。TAC机制必须优先于SAC机制，以启用将公布状态信息的应用程序。对于使用TAC机制的tLDP会话，LDP对等方不得公布在最近的TAE列表中未协商的应用程序（称为非协商应用程序）的状态信息。即使其中一个对等方通过发送SAC TLV宣布其有兴趣接收与未协商的应用程序相对应的状态信息，也是如此。换句话说，当使用TAC机制时，SAC机制不能也不应该为尚未由TAC机制启用的应用程序启用状态信息广告。
On the other hand, the SAC mechanism MUST take precedence over the TAC mechanism with respect to disabling state information advertisements. If an LDP speaker has announced its disinterest in receiving state information for a given application to a given peer using the SAC mechanism, its peer MUST NOT send state information for that application, even if the two peers have negotiated the corresponding application via the TAC mechanism.
另一方面，在禁用状态信息播发方面，SAC机制必须优先于TAC机制。如果LDP演讲者已宣布其对使用SAC机制向给定对等方接收给定应用程序的状态信息不感兴趣，则其对等方不得发送该应用程序的状态信息，即使两个对等方已通过TAC机制协商了相应的应用程序。
For the purposes of determining the correspondence between targeted applications defined in this document and application state as defined in [RFC7473], an LSR MUST use the following mappings:
为了确定本文档中定义的目标应用程序与[RFC7473]中定义的应用程序状态之间的对应关系，LSR必须使用以下映射：
LDPv4 Tunneling - IPv4 Prefix-LSPs LDPv6 Tunneling - IPv6 Prefix-LSPs LDPv4 Remote LFA - IPv4 Prefix-LSPs LDPv6 Remote LFA - IPv6 Prefix-LSPs LDP FEC 128 PW - FEC 128 P2P-PW LDP FEC 129 PW - FEC 129 P2P-PW
LDPv4隧道-IPv4前缀LSPs LDPv6隧道-IPv6前缀LSPs LDPv4远程LFA-IPv4前缀LSPs LDPv6远程LFA-IPv6前缀LSPs LDP FEC 128 PW-FEC 128 P2P-PW LDP FEC 129 PW-FEC 129 P2P-PW
An LSR MUST map the targeted application to the LDP capability as follows:
LSR必须将目标应用程序映射到LDP能力，如下所示：
mLDP Tunneling - P2MP Capability, MP2MP Capability, and HSMP LSP Capability TLV
mLDP隧道-P2MP能力、MP2MP能力和HSMP LSP能力TLV
mLDP Node Protection - P2MP Capability, MP2MP Capability, and HSMP LSP Capability TLV
mLDP节点保护-P2MP能力、MP2MP能力和HSMP LSP能力TLV
The LSR determines that it needs to form an automatic tLDP session with a remote LSR based on IGP calculation as described in [RFC7490] or some other mechanism outside the scope of this document. The LSR forms the tLDP adjacency and constructs an Initialization message with the TAC TLV consisting of the TAE as the remote LFA during session establishment. The receiver LSR processes the LDP Initialization message and verifies whether it is configured to accept a remote LFA tLDP session. If it is, it may further verify that establishing such a session does not exceed the configured limit for remote LFA sessions. If all of these conditions are met, the receiver LSR may respond back with an Initialization message with the TAC corresponding to the remote LFA, and subsequently the session may be established.
LSR根据[RFC7490]中所述的IGP计算或本文件范围外的其他机制，确定需要与远程LSR形成自动tLDP会话。LSR形成tLDP邻接并构造初始化消息，其中TAC TLV由TAE组成，作为会话建立期间的远程LFA。接收器LSR处理LDP初始化消息并验证其是否被配置为接受远程LFA tLDP会话。如果是，它可以进一步验证建立这样的会话没有超过为远程LFA会话配置的限制。如果满足所有这些条件，则接收机LSR可以使用与远程LFA对应的TAC的初始化消息来响应，并且随后可以建立会话。
After the session using the TAC mechanism has been established, the sender and receiver LSRs distribute IPv4 or IPv6 FEC label bindings over the session. Further, the receiver LSR may determine that it does not need these FEC label bindings. So, it may disable the receipt of these FEC label bindings by mapping the TAE to the State Advertisement Control Capability as described in Section 4.
使用TAC机制建立会话后，发送方和接收方LSR会在会话上分发IPv4或IPv6 FEC标签绑定。此外，接收机LSR可以确定它不需要这些FEC标签绑定。因此，它可以通过将TAE映射到第4节中描述的状态播发控制能力来禁用这些FEC标签绑定的接收。
BGP auto-discovery may determine whether the LSR needs to initiate an auto-discovery tLDP session with a border LSR. Multiple LSRs may try to form an auto-discovered tLDP session with a border LSR. So, a service provider may want to limit the number of auto-discovered tLDP sessions that a border LSR can accept. As described in Section 2, LDP may convey targeted applications with the TAC TLV to a border LSR. A border LSR may establish or reject the tLDP session based on local administrative policy. Also, as the receiver LSR becomes aware of targeted applications, it can also employ an administrative policy for security. For instance, it can employ a policy to accept all auto-discovered sessions from a source addresses list.
BGP自动发现可确定LSR是否需要启动与边界LSR的自动发现tLDP会话。多个LSR可能试图与边界LSR形成自动发现的tLDP会话。因此，服务提供商可能希望限制border LSR可以接受的自动发现tLDP会话的数量。如第2节所述，LDP可将具有TAC TLV的目标应用传送到边界LSR。边境LSR可根据本地管理策略建立或拒绝tLDP会话。此外，当接收器LSR意识到目标应用时，它还可以采用安全管理策略。例如，它可以使用一个策略来接受源地址列表中所有自动发现的会话。
Moreover, the sender and receiver LSRs must exchange FEC 129 label bindings only over the tLDP session.
此外，发送方和接收方LSR必须仅在tLDP会话上交换FEC 129标签绑定。
An LSR may want to establish a tLDP session with a remote LSR for LDP-over-RSVP tunneling and remote LFA applications. The sender LSR may add both of these applications as a unique TAE in the TAC data of a TAC TLV. The receiver LSR may have reached a configured limit for accepting remote LFA automatic tLDP sessions, but it may have been configured to accept LDP-over-RSVP tunneling. In such a case, the tLDP session is formed for both LDP-over-RSVP tunneling and remote LFA applications, as both need the same FECs -- IPv4, IPv6, or both.
LSR可能希望通过RSVP隧道和远程LFA应用程序为LDP建立与远程LSR的tLDP会话。发送方LSR可以将这两个应用作为唯一的TAE添加到TAC TLV的TAC数据中。接收机LSR可能已经达到用于接受远程LFA自动tLDP会话的配置限制，但是它可能已经被配置为通过RSVP隧道接受LDP。在这种情况下，tLDP会话针对RSVP隧道上的LDP和远程LFA应用程序形成，因为两者都需要相同的FEC——IPv4、IPv6或两者。
A Merge Point (MPT) LSR may determine that it needs to form an automatic tLDP session with the upstream point of local repair (PLR) LSR for MP2P and MP2MP LSP [RFC6388] node protection as described in [RFC7715]. The MPT LSR may add a new tLDP application -- mLDP protection -- as a unique TAE in the TAC data of a TAC TLV and send it in the Initialization message to the PLR. If the PLR is configured for mLDP node protection and establishing this session does not exceed the limit of either mLDP node protection sessions or automatic tLDP sessions, the PLR may decide to accept this session. Also, the PLR may respond back with the Initialization message with a TAC TLV that has one of the TAEs as mLDP protection, and the session proceeds to establishment as per [RFC5036].
如[RFC7715]所述，合并点（MPT）LSR可确定其需要与MP2P和MP2MP LSP[RFC6388]节点保护的本地修复上游点（PLR）LSR形成自动tLDP会话。MPT LSR可在TAC TLV的TAC数据中添加新的tLDP应用程序——mLDP保护——作为唯一的TAE，并在初始化消息中将其发送至PLR。如果PLR配置用于mLDP节点保护，并且建立该会话不超过mLDP节点保护会话或自动tLDP会话的限制，则PLR可决定接受该会话。此外，PLR可使用具有作为mLDP保护的一个TAE的TAC TLV以初始化消息响应，并且会话按照[RFC5036]进行建立。
The procedures described in this document do not introduce any changes to LDP security considerations as described in [RFC5036].
本文件中所述的程序不会对[RFC5036]中所述的LDP安全注意事项进行任何更改。
As described in [RFC5036], DoS attacks via Extended Hellos, which are required to establish a tLDP session, can be addressed by filtering Extended Hellos using access lists that define addresses with which Extended Discovery is permitted. Further, as described in Section 5.2 of this document, an LSR can employ a policy to accept all auto-discovered Extended Hellos from the configured source addresses list.
如[RFC5036]所述，建立tLDP会话所需的通过扩展Hello的DoS攻击可以通过使用访问列表过滤扩展Hello来解决，访问列表定义了允许扩展发现的地址。此外，如本文档第5.2节所述，LSR可以使用策略从配置的源地址列表中接受所有自动发现的扩展Hello。
Also, for the two LSRs supporting the TAC, the tLDP session is only established after successful negotiation of the TAC. The initiating and receiving LSRs MUST only advertise TA-Ids that they support -- in other words, what they are configured for over the tLDP session.
此外，对于支持TAC的两个LSR，tLDP会话仅在TAC成功协商后建立。发起和接收LSR必须只公布它们支持的TA ID——换句话说，它们在tLDP会话上的配置。
IANA has assigned the following code point for the new Capability Parameter TLV defined in this document. The code point has been assigned from the "TLV Type Name Space" sub-registry of the "Label Distribution Protocol (LDP) Parameters" registry.
IANA已为本文件中定义的新功能参数TLV分配了以下代码点。代码点已从“标签分发协议（LDP）参数”注册表的“TLV类型名称空间”子注册表分配。
Value Description Reference
------ ------------------------------- ---------
0x050F Targeted Application Capability RFC 8223
Value Description Reference
------ ------------------------------- ---------
0x050F Targeted Application Capability RFC 8223
IANA has assigned a new status code from the "Status Code Name Space" sub-registry of the "Label Distribution Protocol (LDP) Parameters" registry.
IANA已从“标签分发协议（LDP）参数”注册表的“状态代码名称空间”子注册表分配了一个新的状态代码。
Value E Description Reference
---------- --- ----------------------------------- ---------
0x0000004C 1 Session Rejected/Targeted
Application Capability Mismatch RFC 8223
Value E Description Reference
---------- --- ----------------------------------- ---------
0x0000004C 1 Session Rejected/Targeted
Application Capability Mismatch RFC 8223
IANA has created a new registry called "LDP Targeted Application Identifier" in the "Label Distribution Protocol (LDP) Parameters" registry. The range is 0x0001-0xFFFE. Values in the range 0x0001-0x1FFF in this registry shall be allocated according to the "IETF Review" procedure [RFC8126]; values in the range 0x2000-0xF7FF shall be allocated according to the "First Come First Served" procedure [RFC8126]. The initial values are as follows.
IANA在“标签分发协议（LDP）参数”注册表中创建了一个名为“LDP目标应用程序标识符”的新注册表。范围为0x0001-0xFFFE。应根据“IETF审查”程序[RFC8126]分配该注册表中0x0001-0x1FF范围内的值；应根据“先到先得”程序[RFC8126]分配0x2000-0xF7FF范围内的值。初始值如下所示。
Value Description Reference
--------------- ------------------------------- ---------
0x0000 Reserved RFC 8223
0x0001 LDPv4 Tunneling RFC 8223
0x0002 LDPv6 Tunneling RFC 8223
0x0003 mLDP Tunneling RFC 8223
0x0004 LDPv4 Remote LFA RFC 8223
0x0005 LDPv6 Remote LFA RFC 8223
0x0006 LDP FEC 128 PW RFC 8223
0x0007 LDP FEC 129 PW RFC 8223
0x0008 LDP Session Protection RFC 8223
0x0009 LDP ICCP RFC 8223
0x000A LDP P2MP PW RFC 8223
0x000B mLDP Node Protection RFC 8223
0x000C LDPv4 Intra-area FECs RFC 8223
0x000D LDPv6 Intra-area FECs RFC 8223
0x000E-0xF7FF Unassigned
0xF800-0xFBFF Available for Private Use
0xFC00-0xFFFE Available for Experimental Use
0xFFFF Reserved RFC 8223
Value Description Reference
--------------- ------------------------------- ---------
0x0000 Reserved RFC 8223
0x0001 LDPv4 Tunneling RFC 8223
0x0002 LDPv6 Tunneling RFC 8223
0x0003 mLDP Tunneling RFC 8223
0x0004 LDPv4 Remote LFA RFC 8223
0x0005 LDPv6 Remote LFA RFC 8223
0x0006 LDP FEC 128 PW RFC 8223
0x0007 LDP FEC 129 PW RFC 8223
0x0008 LDP Session Protection RFC 8223
0x0009 LDP ICCP RFC 8223
0x000A LDP P2MP PW RFC 8223
0x000B mLDP Node Protection RFC 8223
0x000C LDPv4 Intra-area FECs RFC 8223
0x000D LDPv6 Intra-area FECs RFC 8223
0x000E-0xF7FF Unassigned
0xF800-0xFBFF Available for Private Use
0xFC00-0xFFFE Available for Experimental Use
0xFFFF Reserved RFC 8223
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://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, <https://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月<https://www.rfc-editor.org/info/rfc5036>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. Le Roux, "LDP Capabilities", RFC 5561, DOI 10.17487/RFC5561, July 2009, <https://www.rfc-editor.org/info/rfc5561>.
[RFC5561]托马斯，B.，拉扎，K.，阿加瓦尔，S.，阿加瓦尔，R.，和JL。Le Roux，“LDP能力”，RFC 5561，DOI 10.17487/RFC55611909年7月<https://www.rfc-editor.org/info/rfc5561>.
[RFC7473] Raza, K. and S. Boutros, "Controlling State Advertisements of Non-negotiated LDP Applications", RFC 7473, DOI 10.17487/RFC7473, March 2015, <https://www.rfc-editor.org/info/rfc7473>.
[RFC7473]Raza，K.和S.Boutros，“控制非协商自民党申请的国家广告”，RFC 7473，DOI 10.17487/RFC7473，2015年3月<https://www.rfc-editor.org/info/rfc7473>.
[RFC7715] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and Q. Zhao, "Multipoint LDP (mLDP) Node Protection", RFC 7715, DOI 10.17487/RFC7715, January 2016, <https://www.rfc-editor.org/info/rfc7715>.
[RFC7715]Wijnands，IJ.，Ed.，Raza，K.，Atlas，A.，Tantsura，J.，和Q.Zhao，“多点LDP（mLDP）节点保护”，RFC 7715，DOI 10.17487/RFC7715，2016年1月<https://www.rfc-editor.org/info/rfc7715>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011, <https://www.rfc-editor.org/info/rfc6074>.
[RFC6074]Rosen，E.，Davie，B.，Radoaca，V.，和W.Luo，“第二层虚拟专用网络（L2VPN）中的资源调配、自动发现和信令”，RFC 6074，DOI 10.17487/RFC6074，2011年1月<https://www.rfc-editor.org/info/rfc6074>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc6388>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, <https://www.rfc-editor.org/info/rfc7490>.
[RFC7490]Bryant，S.，Filsfils，C.，Previdi，S.，Shand，M.，和N.So，“远程无环路备用（LFA）快速重路由（FRR）”，RFC 7490，DOI 10.17487/RFC74902015年4月<https://www.rfc-editor.org/info/rfc7490>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgments
致谢
The authors wish to thank Nischal Sheth, Hassan Hosseini, Kishore Tiruveedhula, Loa Andersson, Eric Rosen, Yakov Rekhter, Thomas Beckhaus, Tarek Saad, Lizhong Jin, and Bruno Decraene for their detailed reviews. Thanks to Manish Gupta and Martin Ehlers for their input to this work and many helpful suggestions.
作者感谢Nischal Sheth、Hassan Hosseini、Kishore Tiruveedhula、Loa Andersson、Eric Rosen、Yakov Rekhter、Thomas Beckhaus、Tarek Saad、Lizhong Jin和Bruno Decarene的详细评论。感谢Manish Gupta和Martin Ehlers对这项工作的投入和许多有益的建议。
Contributors
贡献者
The following people contributed substantially to the content of this document and should be considered co-authors:
以下人员对本文件的内容做出了重大贡献，应被视为共同作者：
Chris Bowers Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: cbowers@juniper.net
Chris Bowers Juniper Networks 1133 Innovation Way Sunnyvale，CA 94089美利坚合众国电子邮件：cbowers@juniper.net
Zhenbin Li Huawei Bldg. No. 156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com
北京市北青路156号华为大厦李振斌100095中国电子邮件：lizhenbin@huawei.com
Authors' Addresses
作者地址
Santosh Esale Juniper Networks 1133 Innovation Way Sunnyvale, CA 94089 United States of America
Santosh Esale Juniper Networks 1133 Innovation Way Sunnyvale，加利福尼亚州，美国94089
Email: sesale@juniper.net
Email: sesale@juniper.net
Raveendra Torvi Juniper Networks 10 Technology Park Drive Westford, MA 01886 United States of America
美国马萨诸塞州韦斯特福德科技园大道10号Ravendra Torvi Juniper Networks 01886
Email: rtorvi@juniper.net
Email: rtorvi@juniper.net
Luay Jalil Verizon 1201 East Arapaho Road Richardson, TX 75081 United States of America
美国德克萨斯州理查森市阿拉帕霍东路1201号卢埃·贾利勒Verizon 75081
Email: luay.jalil@verizon.com
Email: luay.jalil@verizon.com
Uma Chunduri Huawei 2330 Central Expressway Santa Clara, CA 95050 United States of America
美国加利福尼亚州圣克拉拉市中心高速公路2330号，邮编95050
Email: uma.chunduri@huawei.com
Email: uma.chunduri@huawei.com
Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Ottawa, ON K2K-3E8 Canada
Kamran Raza Cisco Systems，Inc.位于加拿大渥太华K2K-3E8的创新大道2000号
Email: skraza@cisco.com
Email: skraza@cisco.com