Network Working Group B. Thomas
Request for Comments: 5561 K. Raza
Updates: 5036 Cisco Systems, Inc.
Category: Standards Track S. Aggarwal
R. Aggarwal
Juniper Networks
JL. Le Roux
France Telecom
July 2009
Network Working Group B. Thomas
Request for Comments: 5561 K. Raza
Updates: 5036 Cisco Systems, Inc.
Category: Standards Track S. Aggarwal
R. Aggarwal
Juniper Networks
JL. Le Roux
France Telecom
July 2009
LDP Capabilities
自民党能力
Abstract
摘要
A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. This document defines a mechanism for advertising LDP enhancements at session initialization time, as well as a mechanism to enable and disable enhancements after LDP session establishment.
已经提出了对标签分发协议（LDP）的一些增强。有些已经实施，有些正在向标准化迈进。将来可能会提出更多的改进建议。本文档定义了在会话初始化时公布LDP增强功能的机制，以及在LDP会话建立后启用和禁用增强功能的机制。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。未从控制人处获得足够的许可证
the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
此类材料、本文件的版权不得在IETF标准流程之外进行修改，其衍生作品不得在IETF标准流程之外创建，除非将其格式化为RFC或将其翻译为英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. The LDP Capability Mechanism ....................................3
2.1. Capability Document ........................................4
3. Specifying Capabilities in LDP Messages .........................4
3.1. Backward Compatibility TLVs ................................6
4. Capability Message ..............................................6
5. Note on Terminology .............................................7
6. Procedures for Capability Parameters in Initialization
Messages ........................................................7
7. Procedures for Capability Parameters in Capability Messages .....8
8. Extensions to Error Handling ....................................9
9. Dynamic Capability Announcement TLV .............................9
10. Backward Compatibility ........................................10
11. Security Considerations .......................................10
12. IANA Considerations ...........................................11
13. Acknowledgments ...............................................11
14. References ....................................................11
14.1. Normative References .....................................11
14.2. Informative References ...................................11
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. The LDP Capability Mechanism ....................................3
2.1. Capability Document ........................................4
3. Specifying Capabilities in LDP Messages .........................4
3.1. Backward Compatibility TLVs ................................6
4. Capability Message ..............................................6
5. Note on Terminology .............................................7
6. Procedures for Capability Parameters in Initialization
Messages ........................................................7
7. Procedures for Capability Parameters in Capability Messages .....8
8. Extensions to Error Handling ....................................9
9. Dynamic Capability Announcement TLV .............................9
10. Backward Compatibility ........................................10
11. Security Considerations .......................................10
12. IANA Considerations ...........................................11
13. Acknowledgments ...............................................11
14. References ....................................................11
14.1. Normative References .....................................11
14.2. Informative References ...................................11
A number of enhancements to LDP as specified in [RFC5036] have been proposed. These include LDP Graceful Restart [RFC3478], Fault Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for Layer 2 circuits [RFC4447], a method for learning labels advertised by next-next-hop routers in support of fast reroute node protection [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for signaling inter-area Label Switched Paths (LSPs) [RFC5283]. Some have been implemented, and some are advancing toward standardization. It is also likely that additional enhancements will be implemented and deployed in the future.
已经提出了[RFC5036]中规定的对LDP的一些增强。其中包括LDP优雅重启[RFC3478]、容错LDP[RFC3479]、多播扩展[MLDP]、第二层电路信令[RFC4447]、学习下一跳路由器宣传的标签以支持快速重路由节点保护[NNHOP]的方法、上行标签分配[upstream_LDP]，和区域间标签交换路径（LSP）信令扩展[RFC5283]。有些已经实施，有些正在向标准化迈进。将来还可能实施和部署其他增强功能。
This document proposes and defines a mechanism for advertising LDP enhancements at session initialization time. It also defines a mechanism to enable and disable these enhancements after LDP session establishment.
本文档提出并定义了一种在会话初始化时公布LDP增强功能的机制。它还定义了在LDP会话建立后启用和禁用这些增强功能的机制。
LDP capability advertisement provides means for an LDP speaker to announce what it can receive and process. It also provides means for a speaker to inform peers of deviations from behavior specified by [RFC5036]. An example of such a deviation is LDP Graceful Restart, where a speaker retains MPLS forwarding state for LDP-signaled LSPs when its LDP control plane goes down. It is important to point out that not all LDP enhancements require capability advertisement. For example, upstream label allocation requires capability advertisement, but inbound label filtering, where a speaker installs forwarding state for only certain Forwarding Equivalence Classes (FECs), does not.
自民党能力广告为自民党演讲者提供了宣布其能够接收和处理的内容的手段。它还为演讲者提供了告知同龄人与[RFC5036]规定的行为偏差的方法。这种偏差的一个例子是LDP优雅重启，其中当其LDP控制平面下降时，扬声器为LDP发信号的lsp保持MPLS转发状态。需要指出的是，并非所有LDP增强都需要性能广告。例如，上行标签分配需要功能广告，但入站标签过滤（其中说话人仅为某些转发等价类（FEC）安装转发状态）不需要。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the terms "LDP speaker" and "speaker" interchangeably.
本文件交替使用术语“自民党发言人”和“发言人”。
Enhancements are likely to be announced during LDP session establishment as each LDP speaker advertises capabilities corresponding to the enhancements it desires.
增强功能可能会在LDP会议建立期间宣布，因为每个LDP发言人都会宣传与其所需增强功能相对应的功能。
Beyond that, capability advertisements may be used to dynamically modify the characteristics of the session to suit the changing conditions. For example, an LSR capable of a particular enhancement in support of some "feature" may not have advertised the corresponding capability to its peers at session establishment time because the feature was disabled at that time. Later, an operator may enable the feature, at which time the LSR would react by advertising the corresponding capability to its peers. Similarly, when an operator disables a feature associated with a capability, the LSR reacts by withdrawing the capability advertisement from its peers.
除此之外，还可以使用能力公告来动态修改会话的特征，以适应不断变化的条件。例如，能够支持某些“特征”的特定增强的LSR可能在会话建立时没有向其对等方通告相应的能力，因为该特征当时被禁用。随后，运营商可启用该特性，此时LSR将通过向其对等方公布相应的能力来作出反应。类似地，当操作员禁用与功能相关联的功能时，LSR通过从其对等方撤回功能公告作出反应。
The LDP capability advertisement mechanism operates as follows:
LDP能力公告机制的操作如下：
- Each LDP speaker is assumed to implement a set of enhancements, each of which has an associated capability. At any time, a speaker may have none, one, or more of those enhancements "enabled". When an enhancement is enabled, the speaker advertises the associated capability to its peers. By advertising the capability to a peer, the speaker asserts that it shall perform the protocol actions specified for the associated enhancement. For example, the actions
- 假设每个LDP扬声器实现一组增强功能，每个增强功能都具有相关的功能。在任何时候，扬声器都可能没有、一个或多个这些增强功能处于“启用”状态。启用增强功能后，演讲者会向其对等方宣传相关功能。通过向对等方公布该能力，演讲者断言其应执行为相关增强指定的协议动作。例如，操作
may require the LDP speaker to receive and process enhancement-specific messages from its peer. Unless the capability has been advertised, the speaker will not perform protocol actions specified for the corresponding enhancement.
可能要求LDP演讲者接收和处理来自其对等方的增强特定消息。除非该功能已公布，否则扬声器将不会执行为相应增强指定的协议操作。
- At session establishment time, an LDP speaker MAY advertise a particular capability by including an optional parameter associated with the capability in its Initialization message.
- 在会话建立时，LDP说话者可以通过在其初始化消息中包括与该能力相关联的可选参数来通告特定能力。
- There is a well-known capability called Dynamic Capability Announcement that an LDP speaker MAY advertise in its Initialization message to indicate that it is capable of processing capability announcements following a session establishment.
- 有一种称为动态能力通告的众所周知的能力，LDP说话人可以在其初始化消息中通告，以指示其能够在会话建立之后处理能力通告。
If a peer had advertised the Dynamic Capability Announcement capability in its Initialization message, then at any time following session establishment, an LDP speaker MAY announce changes in its advertised capabilities to that peer. To do this, the LDP speaker sends the peer a Capability message that specifies the capabilities being advertised or withdrawn.
如果对等方已在其初始化消息中通告了动态能力通告能力，则在会话建立之后的任何时间，LDP演讲者可向该对等方通告其通告能力的变化。为此，LDP演讲者向对等方发送一条能力消息，该消息指定正在公布或撤销的能力。
When the capability advertisement mechanism is in place, an LDP enhancement requiring LDP capability advertisement will be specified by a document that:
当能力公告机制到位时，需要LDP能力公告的LDP增强将通过以下文件指定：
- Describes the motivation for the enhancement;
- 描述增强的动机；
- Specifies the behavior of LDP when the enhancement is enabled. This includes the procedures, parameters, messages, and TLVs required by the enhancement;
- 指定启用增强时LDP的行为。这包括增强所需的程序、参数、消息和TLV；
- Includes an IANA considerations section that requests IANA assignment of a code point (from TLV Type namespace) for the optional capability parameter corresponding to the enhancement.
- 包括一个IANA注意事项部分，该部分请求为与增强相对应的可选功能参数分配代码点（来自TLV类型命名空间）。
The capability document MUST also describe the interpretation and processing of associated capability data, if present.
能力文件还必须描述相关能力数据（如有）的解释和处理。
This document uses the term "Capability Parameter" to refer to an optional parameter that may be included in Initialization and Capability messages to advertise a capability.
本文档使用术语“能力参数”指的是可选参数，该参数可能包含在初始化和能力消息中，用于公布能力。
The format of a "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| 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 |
| +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
哪里：
U-bit: Unknown TLV bit, as described in [RFC5036]. The value could be either 0 or 1 as specified in the Capability document associated with the given capability.
U位：未知TLV位，如[RFC5036]中所述。根据与给定功能关联的功能文档中的指定，该值可以是0或1。
F-bit: Forward unknown TLV bit, as described in [RFC5036]. The value of this bit MUST be 0 since a Capability Parameter TLV is sent only in Initialization and Capability messages, which are not forwarded.
F位：转发未知TLV位，如[RFC5036]中所述。此位的值必须为0，因为功能参数TLV仅在初始化和功能消息中发送，而不会转发。
TLV Code Point: The TLV type that identifies a specific capability. This is an IANA-assigned code point (from TLV Type namespace) for a given capability as requested in the associated capability document.
TLV代码点：标识特定功能的TLV类型。这是IANA为给定功能分配的代码点（来自TLV类型命名空间），如相关功能文档中所请求。
S-bit: The State Bit. It indicates whether the sender is advertising or withdrawing the capability corresponding to the TLV code point. The State Bit value is used as follows:
S位：状态位。它指示发送方是在公布还是撤销与TLV代码点对应的功能。状态位值的使用如下所示：
1 - The TLV is advertising the capability specified by the TLV code point.
1-TLV正在宣传TLV代码点指定的能力。
0 - The TLV is withdrawing the capability specified by the TLV code point.
0-TLV正在撤回TLV代码点指定的功能。
Capability Data: Information, if any, about the capability in addition to the TLV code point required to fully specify the capability.
能力数据：除完全指定能力所需的TLV代码点外，有关能力的信息（如有）。
The method for interpreting and processing this data is specific to the TLV code point and MUST be described in the document specifying the capability.
解释和处理该数据的方法特定于TLV代码点，必须在指定能力的文件中说明。
An LDP speaker MUST NOT include more than one instance of a Capability Parameter (as identified by the same TLV code point) in an Initialization or Capability message. If an LDP speaker receives more than one instance of the same Capability Parameter type in a message, it SHOULD send a Notification message to the peer before terminating the session with the peer. The Status Code in the Status TLV of the Notification message MUST be Malformed TLV value, and the message SHOULD contain the second Capability Parameter TLV of the same type (code point) that is received in the message.
LDP扬声器在初始化或能力消息中不得包含一个以上的能力参数实例（由同一TLV码点标识）。如果LDP演讲者在消息中接收到多个相同能力参数类型的实例，则在终止与对等方的会话之前，应向对等方发送通知消息。通知消息的状态TLV中的状态代码必须是格式错误的TLV值，并且消息应包含与消息中接收到的相同类型（代码点）的第二个功能参数TLV。
LDP extensions that require advertisement or negotiation of some capability at session establishment time typically use TLVs that are included in an Initialization message. To ensure backward compatibility with existing implementations, such TLVs continue to be supported in an Initialization message and are known in this document as "Backward Compatibility TLVs". A Backward Compatibility TLV plays the role of a "Capability Parameter" TLV; that is, the presence of a Backward Compatibility TLV has the same meaning as a Capability Parameter TLV with the S-bit set for the same capability.
需要在会话建立时公布或协商某些功能的LDP扩展通常使用包含在初始化消息中的TLV。为确保与现有实现的向后兼容性，此类TLV将继续在初始化消息中得到支持，在本文档中称为“向后兼容性TLV”。向后兼容性TLV扮演“能力参数”TLV的角色；也就是说，向后兼容性TLV的存在与为相同能力设置S位的能力参数TLV具有相同的含义。
One example of a Backward Capability TLV is the "FT Session TLV" that is exchanged in an Initialization message between peers to announce LDP Fault Tolerance [RFC3479] capability.
向后能力TLV的一个示例是“FT会话TLV”，它在对等方之间的初始化消息中交换，以宣布LDP容错[RFC3479]能力。
The LDP Capability message is used by an LDP speaker to announce changes in the state of one or more of its capabilities subsequent to session establishment.
LDP能力消息由LDP演讲者用于在会话建立之后宣布其一个或多个能力的状态变化。
The format of the Capability message is as follows:
能力信息的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Capability (0x0202) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV_N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Capability (0x0202) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV_1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV_N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where TLV_1 through TLV_N are Capability Parameter TLVs. The S-bit of each of the TLVs specifies the new state for the corresponding capability.
其中，TLV_1到TLV_N是能力参数TLV。每个TLV的S位指定相应能力的新状态。
Note that Backward Compatibility TLVs (see Section 3.1) MUST NOT be included in Capability messages. An LDP speaker that receives a Capability message from a peer that includes Backward Compatibility TLVs SHOULD silently ignore these Backward Compatibility TLVs and continue processing the rest of the message.
请注意，向后兼容性TLV（见第3.1节）不得包含在功能消息中。从包含向后兼容TLV的对等方接收能力消息的LDP说话人应默默忽略这些向后兼容TLV，并继续处理消息的其余部分。
The following sections in this document talk about enabling and disabling capabilities. The terminology "enabling (or disabling) a capability" is short hand for "advertising (or withdrawing) a capability associated with an enhancement". Bear in mind that it is an LDP enhancement that is being enabled or disabled, and that it is the corresponding capability that is being advertised or withdrawn.
本文档中的以下部分讨论启用和禁用功能。术语“启用（或禁用）能力”是“宣传（或撤销）与增强相关的能力”的简称。请记住，正在启用或禁用的是LDP增强功能，正在公布或撤销的是相应的功能。
The S-bit of a Capability Parameter in an Initialization message MUST be 1 and SHOULD be ignored on receipt. This ensures that any Capability Parameter in an Initialization message enables the corresponding capability.
初始化消息中能力参数的S位必须为1，在收到时应忽略。这可确保初始化消息中的任何功能参数启用相应的功能。
An LDP speaker determines the capabilities of a peer by examining the set of Capability Parameters present in the Initialization message received from the peer.
LDP说话人通过检查从对等方接收的初始化消息中存在的一组能力参数来确定对等方的能力。
An LDP speaker MAY use a particular capability with its peer after the speaker determines that the peer has enabled that capability.
LDP演讲者可以在其对等方确定该对等方已启用该能力之后，对其对等方使用特定能力。
These procedures enable an LDP speaker S1, that advertises a specific LDP capability C, to establish an LDP session with speaker S2 that does not advertise C. In this situation, whether or not capability C may be used for the session depends on the semantics of the enhancement associated with C. If the semantics do not require both S1 and S2, advertise C to one another, then S2 could use it; i.e., S1's advertisement of C permits S2 to send messages to S1 used by the enhancement.
这些过程使播发特定LDP能力C的LDP演讲者S1能够与不播发C的演讲者S2建立LDP会话。在这种情况下，能力C是否可用于会话取决于与C相关联的增强的语义。如果语义不需要S1和S2，相互宣传C，然后S2可以使用它；i、 例如，S1的C的广告允许S2向增强所使用的S1发送消息。
It is the responsibility of the capability designer to specify the behavior of an LDP speaker that has enabled a certain enhancement, advertised its capability and determines that its peer has not advertised the corresponding capability. The document specifying procedures for the capability MUST describe the behavior in this situation. If the specified procedure is to terminate the session, then the LDP speaker SHOULD send a Notification message to the peer before terminating the session. The Status Code in the Status TLV of the Notification message MUST be Unsupported Capability, and the message SHOULD contain the unsupported capability (see Section 8 for more details).
能力设计者有责任指定LDP说话人的行为，该说话人已启用某种增强功能，宣传其能力，并确定其对等方未宣传相应的能力。指定能力程序的文件必须描述这种情况下的行为。如果指定的过程是终止会话，则LDP演讲者应在终止会话之前向对等方发送通知消息。通知消息的状态TLV中的状态代码必须是不受支持的功能，并且消息应包含不受支持的功能（有关更多详细信息，请参阅第8节）。
An LDP speaker that supports capability advertisement and includes a Capability Parameter in its Initialization message MUST set the TLV U-bit to 0 or 1, as specified by Capability document. The LDP speaker should set the U-bit to 1 if the capability document allows it to continue with a peer that does not understand the enhancement, and set the U-bit to 0 otherwise. If a speaker receives a message containing unsupported capability, it responds according to the U-bit setting in the TLV. If the U-bit is 1, then the speaker MUST silently ignore the Capability Parameter and allow the session to be established. However, if the U-bit is 0, then speaker SHOULD send a Notification message to the peer before terminating the session. The Status Code in the Status TLV of the Notification message MUST be Unsupported Capability, and the message SHOULD contain the unsupported capability (see Section 8 for more details).
根据能力文档的规定，支持能力公告并在其初始化消息中包含能力参数的LDP扬声器必须将TLV U位设置为0或1。如果能力文档允许LDP演讲者与不理解增强的对等方继续，则LDP演讲者应将U位设置为1，否则应将U位设置为0。如果扬声器接收到包含不支持功能的消息，它将根据TLV中的U位设置进行响应。如果U位为1，则演讲者必须无声地忽略Capability参数并允许建立会话。但是，如果U位为0，则演讲者应在终止会话之前向对等方发送通知消息。通知消息的状态TLV中的状态代码必须是不受支持的功能，并且消息应包含不受支持的功能（有关更多详细信息，请参阅第8节）。
An LDP speaker MUST NOT send a Capability message to a peer unless its peer advertised the Dynamic Capability Announcement capability in its session Initialization message. An LDP speaker MAY send a Capability message to a peer if its peer advertised the Dynamic Capability Announcement capability in its session Initialization message (see Section 9).
LDP演讲者不得向对等方发送能力消息，除非其对等方在其会话初始化消息中公布了动态能力公告能力。如果LDP演讲者的对等方在其会话初始化消息中公布了动态能力公告能力，则LDP演讲者可以向对等方发送能力消息（参见第9节）。
An LDP speaker determines the capabilities enabled by a peer by determining the set of capabilities enabled at session initialization (as specified in Section 6) and tracking changes to that set made by Capability messages from the peer.
LDP演讲者通过确定会话初始化时启用的能力集（如第6节所述）并跟踪来自对等方的能力消息对该能力集所做的更改来确定对等方启用的能力。
An LDP speaker that has enabled a particular capability MAY use the enhancement corresponding to the capability with a peer after the speaker determines that the peer has enabled the capability.
已启用特定能力的LDP演讲者可在演讲者确定对等者已启用该能力之后使用对应于对等者的能力的增强。
This document defines a new LDP status code named Unsupported Capability. The E-bit of the Status TLV carried in a Notification message that includes this status code MUST be set to 0.
本文档定义了一个名为Unsupported Capability的新LDP状态代码。包含此状态代码的通知消息中携带的状态TLV的E位必须设置为0。
In addition, this document defines a new LDP TLV, named Returned TLVs, that MAY be carried in a Notification message as an Optional Parameter. The U-bit setting for a Returned TLVs TLV in a Notification message SHOULD be 1, and the F-bit setting SHOULD be 0.
此外，本文档还定义了一个名为Returned TLV的新LDP TLV，它可以作为可选参数在通知消息中携带。通知消息中返回的TLVs TLV的U位设置应为1，F位设置应为0。
When the Status Code in a Notification message is Unsupported Capability, the message SHOULD specify the capabilities that are unsupported. When the Notification message specifies the unsupported capabilities, it MUST include a Returned TLVs TLV. The Returned TLVs TLV MUST include only the Capability Parameters for unsupported capabilities, and the Capability Parameter for each such capability SHOULD be encoded as received from the peer.
当通知消息中的状态代码为不受支持的功能时，该消息应指定不受支持的功能。当通知消息指定不支持的功能时，它必须包含返回的TLVs TLV。返回的TLV TLV必须仅包括不受支持功能的功能参数，并且每个此类功能的功能参数应按照从对等方接收的方式进行编码。
When the Status Code in a Notification Message is Unknown TLV, the message SHOULD specify the TLV that was unknown. When the Notification message specifies the TLV that was unknown, it MUST include the unknown TLV in a Returned TLVs TLV.
当通知消息中的状态代码为未知TLV时，消息应指定未知的TLV。当通知消息指定未知的TLV时，它必须在返回的TLV TLV中包含未知的TLV。
The Dynamic Capability Announcement TLV is a Capability Parameter defined by this document with following format:
动态能力公告TLV是本文件定义的能力参数，格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| DynCap Ann. (0x0506) | Length (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| DynCap Ann. (0x0506) | Length (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+
The value of the U-bit for the Dynamic Capability Announcement Parameter TLV MUST be set to 1 so that a receiver MUST silently ignore this TLV if unknown to it, and continue processing the rest of the message. There is no "Capability Data" associated with this TLV and hence the TLV length MUST be set to 1.
动态能力公告参数TLV的U位值必须设置为1，以便接收器在未知时必须默默忽略此TLV，并继续处理消息的其余部分。没有与此TLV关联的“能力数据”，因此TLV长度必须设置为1。
The Dynamic Capability Announcement Parameter MAY be included by an LDP speaker in an Initialization message to signal its peer that the speaker is capable of processing Capability messages.
动态能力公告参数可由LDP扬声器包括在初始化消息中，以向其对等方发送信号，表明该扬声器能够处理能力消息。
An LDP speaker MUST NOT include the Dynamic Capability Announcement Parameter in Capability messages sent to its peers. Once enabled during session initialization, the Dynamic Capability Announcement capability cannot be disabled. This implies that the S-bit is always 1 for the Dynamic Capability Announcement.
LDP演讲者不得在发送给其对等方的能力消息中包含动态能力公告参数。一旦在会话初始化期间启用，则无法禁用动态功能公告功能。这意味着动态能力公告的S位始终为1。
An LDP speaker that receives a Capability message from a peer that includes the Dynamic Capability Announcement Parameter SHOULD silently ignore the parameter and process any other Capability Parameters in the message.
从包含动态能力公告参数的对等方接收能力消息的LDP说话人应默默忽略该参数，并处理消息中的任何其他能力参数。
From the point of view of the LDP capability advertisement mechanism, an [RFC5036]-compliant peer has label distribution for IPv4 enabled by default. To ensure compatibility with an [RFC5036]-compliant peer, LDP implementations that support capability advertisement have label distribution for IPv4 enabled until it is explicitly disabled and MUST assume that their peers do as well.
从LDP能力公布机制的角度来看，[RFC5036]兼容对等机默认启用IPv4标签分发。为了确保与[RFC5036]兼容的对等方兼容，支持功能广告的LDP实现启用了IPv4的标签分发，直到它被显式禁用，并且必须假设它们的对等方也这样做。
Section 3.1 introduces the concept of Backward Compatibility TLVs that may appear in an Initialization message in the role of a Capability Parameter. This permits existing LDP enhancements that use an ad hoc mechanism for enabling capabilities at session initialization time to continue to do so.
第3.1节介绍了后向兼容性TLV的概念，该TLV可能以能力参数的角色出现在初始化消息中。这就允许现有的LDP增强功能继续这样做，这些增强功能使用一种特殊机制来在会话初始化时启用功能。
[MPLS_SEC] describes the security framework for MPLS networks, whereas [RFC5036] describes the security considerations that apply to the base LDP specification. The same security framework and considerations apply to the capability mechanism described in this document.
[MPLS_SEC]描述了MPLS网络的安全框架，而[RFC5036]描述了适用于基本LDP规范的安全注意事项。同样的安全框架和注意事项也适用于本文档中描述的能力机制。
This document specifies the following code points assigned by IANA:
本文件规定了IANA分配的以下代码点：
- LDP message code point for the Capability message (0x0202).
- 功能消息的LDP消息代码点（0x0202）。
- LDP TLV code point for the Dynamic Capability Announcement TLV (0x0506).
- 动态能力公告TLV（0x0506）的LDP TLV码点。
- LDP TLV code point for the Returned TLVs TLV (0x0304).
- 返回的TLV TLV的LDP TLV代码点（0x0304）。
- LDP Status Code code point for the Unsupported Capability Status Code (0x0000002E).
- 不受支持的能力状态代码（0x0000002E）的LDP状态代码点。
The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, Yakov Rekhter, and Eric Rosen for their comments.
作者希望感谢陈恩科、林万森、伊娜·米尼、莫彬、亚科夫·雷克特和埃里克·罗森的评论。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]Andersson，L.，Ed.，Minei，I.，Ed.，和B.Thomas，Ed.，“LDP规范”，RFC 5036，2007年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3479] Farrel, A., Ed., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479]Farrel，A.，Ed.“标签分发协议（LDP）的容错”，RFC 3479，2003年2月。
[RFC5283] Decraene, B., Le Roux, JL., and I. Minei, "LDP Extension for Inter-Area Label Switched Paths (LSPs)", RFC 5283, July 2008.
[RFC5283]DeClaene，B.，Le Roux，JL.，和I.Minei，“区域间标签交换路径（LSP）的LDP扩展”，RFC 5283，2008年7月。
[MLDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, April 2009.
[MLDP]Minei，I.，Ed.，Kompella，K.，Wijnands，I.，Ed.，和B.Thomas，“点对多点和多点对多点标签交换路径的标签分发协议扩展”，正在进行的工作，2009年4月。
[NNHOP] Shen, N., Chen, E., and A. Tian, "Discovery LDP Next-Nexthop Labels", Work in Progress, May 2005.
[NNHOP]Shen，N.，Chen，E.，和A.Tian，“发现LDP下一代标签”，正在进行的工作，2005年5月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447]Martini，L.，Ed.，Rosen，E.，El Aawar，N.，Smith，T.，和G.Heron，“使用标签分发协议（LDP）的伪线设置和维护”，RFC 4447，2006年4月。
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
[RFC3478]Leelanivas，M.，Rekhter，Y.，和R.Aggarwal，“标签分发协议的优雅重启机制”，RFC 3478，2003年2月。
[UPSTREAM_LDP] Aggarwal R., and J.L. Le Roux, "MPLS Upstream Label Assignment for LDP" Work in Progress, July 2008.
[UPSTREAM_LDP]Aggarwal R.和J.L.Le Roux，“LDP的MPLS上游标签分配”正在进行的工作，2008年7月。
[MPLS_SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, March 2009.
[MPLS_SEC]Fang，L.，Ed.，“MPLS和GMPLS网络的安全框架”，正在进行的工作，2009年3月。
Authors' Addresses
作者地址
Bob Thomas Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 EMail: bobthomas@alum.mit.edu
Bob Thomas Cisco Systems，Inc.马萨诸塞州Boxborough大道1414号邮编01719电子邮件：bobthomas@alum.mit.edu
Shivani Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: shivani@juniper.net
Shivani Aggarwal Juniper Networks 1194 North Mathilda Ave.Sunnyvale，CA 94089电子邮件：shivani@juniper.net
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 EMail: rahul@juniper.net
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave.Sunnyvale，CA 94089电子邮件：rahul@juniper.net
Jean-Louis Le Roux France Telecom 2, Avenue Pierre-Marzin 22307 Lannion Cedex, France EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux法国电信2号，Pierre Marzin大街22307兰尼昂塞德斯，法国电子邮件：jeanlouis。leroux@orange-ftgroup.com
Kamran Raza Cisco Systems, Inc. 2000 Innovation Dr. Kanata, ON K2K 3E8, Canada EMail: skraza@cisco.com
Kamran Raza Cisco Systems，Inc.2000创新Kanata博士，加拿大K2K 3E8电子邮件：skraza@cisco.com