Network Working Group L. Andersson
Request for Comments: 3036 Nortel Networks Inc.
Category: Standards Track P. Doolan
Ennovate Networks
N. Feldman
IBM Corp
A. Fredette
PhotonEx Corp
B. Thomas
Cisco Systems, Inc.
January 2001
Network Working Group L. Andersson
Request for Comments: 3036 Nortel Networks Inc.
Category: Standards Track P. Doolan
Ennovate Networks
N. Feldman
IBM Corp
A. Fredette
PhotonEx Corp
B. Thomas
Cisco Systems, Inc.
January 2001
LDP Specification
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) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The architecture for Multi Protocol Label Switching (MPLS) is described in RFC 3031. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths.
RFC 3031中描述了多协议标签交换（MPLS）的体系结构。MPLS中的一个基本概念是，两个标签交换路由器（LSR）必须就用于在它们之间转发流量的标签的含义达成一致。这一共识是通过使用一组称为标签分发协议的过程实现的，通过该协议，一个LSR通知另一个LSR它已进行的标签绑定。本文档定义了一组称为LDP（标签分发协议）的过程，LSR通过该过程分发标签，以支持MPLS沿正常路由路径转发。
Table of Contents
目录
1 LDP Overview ....................................... 5
1.1 LDP Peers .......................................... 6
1.2 LDP Message Exchange ............................... 6
1.3 LDP Message Structure .............................. 7
1.4 LDP Error Handling ................................. 7
1.5 LDP Extensibility and Future Compatibility ......... 7
1.6 Specification Language ............................. 7
2 LDP Operation ...................................... 8
2.1 FECs ............................................... 8
2.2 Label Spaces, Identifiers, Sessions and Transport .. 9
2.2.1 Label Spaces ....................................... 9
2.2.2 LDP Identifiers .................................... 10
2.2.3 LDP Sessions ....................................... 10
2.2.4 LDP Transport ...................................... 11
2.3 LDP Sessions between non-Directly Connected LSRs ... 11
2.4 LDP Discovery ..................................... 11
2.4.1 Basic Discovery Mechanism .......................... 12
2.4.2 Extended Discovery Mechanism ....................... 12
2.5 Establishing and Maintaining LDP Sessions .......... 13
2.5.1 LDP Session Establishment .......................... 13
2.5.2 Transport Connection Establishment ................. 13
2.5.3 Session Initialization ............................. 14
2.5.4 Initialization State Machine ....................... 17
2.5.5 Maintaining Hello Adjacencies ...................... 20
2.5.6 Maintaining LDP Sessions ........................... 20
2.6 Label Distribution and Management .................. 21
2.6.1 Label Distribution Control Mode .................... 21
2.6.1.1 Independent Label Distribution Control ............. 21
2.6.1.2 Ordered Label Distribution Control ................. 21
2.6.2 Label Retention Mode ............................... 22
2.6.2.1 Conservative Label Retention Mode .................. 22
2.6.2.2 Liberal Label Retention Mode ....................... 22
2.6.3 Label Advertisement Mode ........................... 23
2.7 LDP Identifiers and Next Hop Addresses ............. 23
2.8 Loop Detection ..................................... 24
2.8.1 Label Request Message .............................. 24
2.8.2 Label Mapping Message .............................. 26
2.8.3 Discussion ......................................... 27
2.9 Authenticity and Integrity of LDP Messages ......... 28
2.9.1 TCP MD5 Signature Option ........................... 28
2.9.2 LDP Use of TCP MD5 Signature Option ................ 30
2.10 Label Distribution for Explicitly Routed LSPs ...... 30
3 Protocol Specification ............................. 31
3.1 LDP PDUs ........................................... 31
3.2 LDP Procedures ..................................... 32
3.3 Type-Length-Value Encoding ......................... 32
1 LDP Overview ....................................... 5
1.1 LDP Peers .......................................... 6
1.2 LDP Message Exchange ............................... 6
1.3 LDP Message Structure .............................. 7
1.4 LDP Error Handling ................................. 7
1.5 LDP Extensibility and Future Compatibility ......... 7
1.6 Specification Language ............................. 7
2 LDP Operation ...................................... 8
2.1 FECs ............................................... 8
2.2 Label Spaces, Identifiers, Sessions and Transport .. 9
2.2.1 Label Spaces ....................................... 9
2.2.2 LDP Identifiers .................................... 10
2.2.3 LDP Sessions ....................................... 10
2.2.4 LDP Transport ...................................... 11
2.3 LDP Sessions between non-Directly Connected LSRs ... 11
2.4 LDP Discovery ..................................... 11
2.4.1 Basic Discovery Mechanism .......................... 12
2.4.2 Extended Discovery Mechanism ....................... 12
2.5 Establishing and Maintaining LDP Sessions .......... 13
2.5.1 LDP Session Establishment .......................... 13
2.5.2 Transport Connection Establishment ................. 13
2.5.3 Session Initialization ............................. 14
2.5.4 Initialization State Machine ....................... 17
2.5.5 Maintaining Hello Adjacencies ...................... 20
2.5.6 Maintaining LDP Sessions ........................... 20
2.6 Label Distribution and Management .................. 21
2.6.1 Label Distribution Control Mode .................... 21
2.6.1.1 Independent Label Distribution Control ............. 21
2.6.1.2 Ordered Label Distribution Control ................. 21
2.6.2 Label Retention Mode ............................... 22
2.6.2.1 Conservative Label Retention Mode .................. 22
2.6.2.2 Liberal Label Retention Mode ....................... 22
2.6.3 Label Advertisement Mode ........................... 23
2.7 LDP Identifiers and Next Hop Addresses ............. 23
2.8 Loop Detection ..................................... 24
2.8.1 Label Request Message .............................. 24
2.8.2 Label Mapping Message .............................. 26
2.8.3 Discussion ......................................... 27
2.9 Authenticity and Integrity of LDP Messages ......... 28
2.9.1 TCP MD5 Signature Option ........................... 28
2.9.2 LDP Use of TCP MD5 Signature Option ................ 30
2.10 Label Distribution for Explicitly Routed LSPs ...... 30
3 Protocol Specification ............................. 31
3.1 LDP PDUs ........................................... 31
3.2 LDP Procedures ..................................... 32
3.3 Type-Length-Value Encoding ......................... 32
3.4 TLV Encodings for Commonly Used Parameters ......... 34
3.4.1 FEC TLV ............................................ 34
3.4.1.1 FEC Procedures ..................................... 37
3.4.2 Label TLVs ......................................... 37
3.4.2.1 Generic Label TLV .................................. 37
3.4.2.2 ATM Label TLV ...................................... 38
3.4.2.3 Frame Relay Label TLV .............................. 38
3.4.3 Address List TLV ................................... 39
3.4.4 Hop Count TLV ...................................... 40
3.4.4.1 Hop Count Procedures ............................... 40
3.4.5 Path Vector TLV .................................... 41
3.4.5.1 Path Vector Procedures ............................. 42
3.4.5.1.1 Label Request Path Vector .......................... 42
3.4.5.1.2 Label Mapping Path Vector .......................... 43
3.4.6 Status TLV ......................................... 43
3.5 LDP Messages ....................................... 45
3.5.1 Notification Message ............................... 47
3.5.1.1 Notification Message Procedures .................... 48
3.5.1.2 Events Signaled by Notification Messages ........... 49
3.5.1.2.1 Malformed PDU or Message ........................... 49
3.5.1.2.2 Unknown or Malformed TLV ........................... 50
3.5.1.2.3 Session KeepAlive Timer Expiration ................. 50
3.5.1.2.4 Unilateral Session Shutdown ........................ 51
3.5.1.2.5 Initialization Message Events ...................... 51
3.5.1.2.6 Events Resulting From Other Messages ............... 51
3.5.1.2.7 Internal Errors .................................... 51
3.5.1.2.8 Miscellaneous Events ............................... 51
3.5.2 Hello Message ...................................... 51
3.5.2.1 Hello Message Procedures ........................... 54
3.5.3 Initialization Message ............................. 55
3.5.3.1 Initialization Message Procedures .................. 63
3.5.4 KeepAlive Message .................................. 63
3.5.4.1 KeepAlive Message Procedures ....................... 63
3.5.5 Address Message .................................... 64
3.5.5.1 Address Message Procedures ......................... 64
3.5.6 Address Withdraw Message ........................... 65
3.5.6.1 Address Withdraw Message Procedures ................ 66
3.5.7 Label Mapping Message .............................. 66
3.5.7.1 Label Mapping Message Procedures ................... 67
3.5.7.1.1 Independent Control Mapping ........................ 67
3.5.7.1.2 Ordered Control Mapping ............................ 68
3.5.7.1.3 Downstream on Demand Label Advertisement ........... 68
3.5.7.1.4 Downstream Unsolicited Label Advertisement ......... 69
3.5.8 Label Request Message .............................. 69
3.5.8.1 Label Request Message Procedures ................... 70
3.5.9 Label Abort Request Message ........................ 72
3.5.9.1 Label Abort Request Message Procedures ............. 73
3.5.10 Label Withdraw Message ............................. 74
3.4 TLV Encodings for Commonly Used Parameters ......... 34
3.4.1 FEC TLV ............................................ 34
3.4.1.1 FEC Procedures ..................................... 37
3.4.2 Label TLVs ......................................... 37
3.4.2.1 Generic Label TLV .................................. 37
3.4.2.2 ATM Label TLV ...................................... 38
3.4.2.3 Frame Relay Label TLV .............................. 38
3.4.3 Address List TLV ................................... 39
3.4.4 Hop Count TLV ...................................... 40
3.4.4.1 Hop Count Procedures ............................... 40
3.4.5 Path Vector TLV .................................... 41
3.4.5.1 Path Vector Procedures ............................. 42
3.4.5.1.1 Label Request Path Vector .......................... 42
3.4.5.1.2 Label Mapping Path Vector .......................... 43
3.4.6 Status TLV ......................................... 43
3.5 LDP Messages ....................................... 45
3.5.1 Notification Message ............................... 47
3.5.1.1 Notification Message Procedures .................... 48
3.5.1.2 Events Signaled by Notification Messages ........... 49
3.5.1.2.1 Malformed PDU or Message ........................... 49
3.5.1.2.2 Unknown or Malformed TLV ........................... 50
3.5.1.2.3 Session KeepAlive Timer Expiration ................. 50
3.5.1.2.4 Unilateral Session Shutdown ........................ 51
3.5.1.2.5 Initialization Message Events ...................... 51
3.5.1.2.6 Events Resulting From Other Messages ............... 51
3.5.1.2.7 Internal Errors .................................... 51
3.5.1.2.8 Miscellaneous Events ............................... 51
3.5.2 Hello Message ...................................... 51
3.5.2.1 Hello Message Procedures ........................... 54
3.5.3 Initialization Message ............................. 55
3.5.3.1 Initialization Message Procedures .................. 63
3.5.4 KeepAlive Message .................................. 63
3.5.4.1 KeepAlive Message Procedures ....................... 63
3.5.5 Address Message .................................... 64
3.5.5.1 Address Message Procedures ......................... 64
3.5.6 Address Withdraw Message ........................... 65
3.5.6.1 Address Withdraw Message Procedures ................ 66
3.5.7 Label Mapping Message .............................. 66
3.5.7.1 Label Mapping Message Procedures ................... 67
3.5.7.1.1 Independent Control Mapping ........................ 67
3.5.7.1.2 Ordered Control Mapping ............................ 68
3.5.7.1.3 Downstream on Demand Label Advertisement ........... 68
3.5.7.1.4 Downstream Unsolicited Label Advertisement ......... 69
3.5.8 Label Request Message .............................. 69
3.5.8.1 Label Request Message Procedures ................... 70
3.5.9 Label Abort Request Message ........................ 72
3.5.9.1 Label Abort Request Message Procedures ............. 73
3.5.10 Label Withdraw Message ............................. 74
3.5.10.1 Label Withdraw Message Procedures .................. 75
3.5.11 Label Release Message .............................. 76
3.5.11.1 Label Release Message Procedures ................... 77
3.6 Messages and TLVs for Extensibility ................ 78
3.6.1 LDP Vendor-private Extensions ...................... 78
3.6.1.1 LDP Vendor-private TLVs ............................ 78
3.6.1.2 LDP Vendor-private Messages ........................ 80
3.6.2 LDP Experimental Extensions ........................ 81
3.7 Message Summary .................................... 81
3.8 TLV Summary ........................................ 82
3.9 Status Code Summary ................................ 83
3.10 Well-known Numbers ................................. 84
3.10.1 UDP and TCP Ports .................................. 84
3.10.2 Implicit NULL Label ................................ 84
4 IANA Considerations ................................ 84
4.1 Message Type Name Space ............................ 84
4.2 TLV Type Name Space ................................ 85
4.3 FEC Type Name Space ................................ 85
4.4 Status Code Name Space ............................. 86
4.5 Experiment ID Name Space ........................... 86
5 Security Considerations ............................ 86
5.1 Spoofing ........................................... 86
5.2 Privacy ............................................ 87
5.3 Denial of Service .................................. 87
6 Areas for Future Study ............................. 89
7 Intellectual Property Considerations ............... 89
8 Acknowledgments .................................... 89
9 References ......................................... 89
10 Authors' Addresses ................................. 92
Appendix A LDP Label Distribution Procedures .................. 93
A.1 Handling Label Distribution Events ................. 95
A.1.1 Receive Label Request .............................. 96
A.1.2 Receive Label Mapping .............................. 99
A.1.3 Receive Label Abort Request ........................ 105
A.1.4 Receive Label Release .............................. 107
A.1.5 Receive Label Withdraw ............................. 109
A.1.6 Recognize New FEC .................................. 110
A.1.7 Detect Change in FEC Next Hop ...................... 113
A.1.8 Receive Notification / Label Request Aborted ....... 116
A.1.9 Receive Notification / No Label Resources .......... 116
A.1.10 Receive Notification / No Route .................... 117
A.1.11 Receive Notification / Loop Detected ............... 118
A.1.12 Receive Notification / Label Resources Available ... 118
A.1.13 Detect local label resources have become available . 119
A.1.14 LSR decides to no longer label switch a FEC ........ 120
A.1.15 Timeout of deferred label request .................. 121
A.2 Common Label Distribution Procedures ............... 121
A.2.1 Send_Label ......................................... 121
3.5.10.1 Label Withdraw Message Procedures .................. 75
3.5.11 Label Release Message .............................. 76
3.5.11.1 Label Release Message Procedures ................... 77
3.6 Messages and TLVs for Extensibility ................ 78
3.6.1 LDP Vendor-private Extensions ...................... 78
3.6.1.1 LDP Vendor-private TLVs ............................ 78
3.6.1.2 LDP Vendor-private Messages ........................ 80
3.6.2 LDP Experimental Extensions ........................ 81
3.7 Message Summary .................................... 81
3.8 TLV Summary ........................................ 82
3.9 Status Code Summary ................................ 83
3.10 Well-known Numbers ................................. 84
3.10.1 UDP and TCP Ports .................................. 84
3.10.2 Implicit NULL Label ................................ 84
4 IANA Considerations ................................ 84
4.1 Message Type Name Space ............................ 84
4.2 TLV Type Name Space ................................ 85
4.3 FEC Type Name Space ................................ 85
4.4 Status Code Name Space ............................. 86
4.5 Experiment ID Name Space ........................... 86
5 Security Considerations ............................ 86
5.1 Spoofing ........................................... 86
5.2 Privacy ............................................ 87
5.3 Denial of Service .................................. 87
6 Areas for Future Study ............................. 89
7 Intellectual Property Considerations ............... 89
8 Acknowledgments .................................... 89
9 References ......................................... 89
10 Authors' Addresses ................................. 92
Appendix A LDP Label Distribution Procedures .................. 93
A.1 Handling Label Distribution Events ................. 95
A.1.1 Receive Label Request .............................. 96
A.1.2 Receive Label Mapping .............................. 99
A.1.3 Receive Label Abort Request ........................ 105
A.1.4 Receive Label Release .............................. 107
A.1.5 Receive Label Withdraw ............................. 109
A.1.6 Recognize New FEC .................................. 110
A.1.7 Detect Change in FEC Next Hop ...................... 113
A.1.8 Receive Notification / Label Request Aborted ....... 116
A.1.9 Receive Notification / No Label Resources .......... 116
A.1.10 Receive Notification / No Route .................... 117
A.1.11 Receive Notification / Loop Detected ............... 118
A.1.12 Receive Notification / Label Resources Available ... 118
A.1.13 Detect local label resources have become available . 119
A.1.14 LSR decides to no longer label switch a FEC ........ 120
A.1.15 Timeout of deferred label request .................. 121
A.2 Common Label Distribution Procedures ............... 121
A.2.1 Send_Label ......................................... 121
A.2.2 Send_Label_Request ................................. 123
A.2.3 Send_Label_Withdraw ................................ 124
A.2.4 Send_Notification .................................. 125
A.2.5 Send_Message ....................................... 125
A.2.6 Check_Received_Attributes .......................... 126
A.2.7 Prepare_Label_Request_Attributes ................... 127
A.2.8 Prepare_Label_Mapping_Attributes ................... 129
Full Copyright Statement ...................................... 132
A.2.2 Send_Label_Request ................................. 123
A.2.3 Send_Label_Withdraw ................................ 124
A.2.4 Send_Notification .................................. 125
A.2.5 Send_Message ....................................... 125
A.2.6 Check_Received_Attributes .......................... 126
A.2.7 Prepare_Label_Request_Attributes ................... 127
A.2.8 Prepare_Label_Mapping_Attributes ................... 129
Full Copyright Statement ...................................... 132
The MPLS architecture [RFC3031] defines a label distribution protocol as a set of procedures by which one Label Switched Router (LSR) informs another of the meaning of labels used to forward traffic between and through them.
MPLS体系结构[RFC3031]将标签分发协议定义为一组过程，通过这些过程，一个标签交换路由器（LSR）向另一个通知用于在它们之间转发通信的标签的含义。
The MPLS architecture does not assume a single label distribution protocol. In fact, a number of different label distribution protocols are being standardized. Existing protocols have been extended so that label distribution can be piggybacked on them. New protocols have also been defined for the explicit purpose of distributing labels. The MPLS architecture discusses some of the considerations when choosing a label distribution protocol for use in particular MPLS applications such as Traffic Engineering [RFC2702].
MPLS体系结构不采用单标签分发协议。事实上，许多不同的标签分发协议正在标准化。现有的协议已被扩展，以便标签分发可以在其上进行。为了明确分发标签的目的，还定义了新的协议。MPLS体系结构讨论了在选择标签分发协议以用于特定MPLS应用（如流量工程[RFC2702]）时的一些注意事项。
The Label Distribution Protocol (LDP) defined in this document is a new protocol defined for distributing labels. It is the set of procedures and messages by which Label Switched Routers (LSRs) establish Label Switched Paths (LSPs) through a network by mapping network-layer routing information directly to data-link layer switched paths. These LSPs may have an endpoint at a directly attached neighbor (comparable to IP hop-by-hop forwarding), or may have an endpoint at a network egress node, enabling switching via all intermediary nodes.
本文档中定义的标签分发协议（LDP）是为分发标签而定义的新协议。它是一组过程和消息，通过将网络层路由信息直接映射到数据链路层交换路径，标签交换路由器（LSR）通过网络建立标签交换路径（LSP）。这些lsp可以在直接连接的邻居处具有端点（类似于IP逐跳转发），或者可以在网络出口节点处具有端点，从而能够通过所有中间节点进行切换。
LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with each LSP it creates. The FEC associated with an LSP specifies which packets are "mapped" to that LSP. LSPs are extended through a network as each LSR "splices" incoming labels for a FEC to the outgoing label assigned to the next hop for the given FEC.
LDP将转发等价类（FEC）[RFC3031]与其创建的每个LSP相关联。与LSP相关联的FEC指定哪些分组被“映射”到该LSP。LSP通过网络扩展，因为每个LSR将FEC的传入标签“拼接”到指定给给定FEC的下一跳的传出标签。
More information about the applicability of LDP can be found in [RFC3037].
有关LDP适用性的更多信息，请参见[RFC3037]。
This document assumes familiarity with the MPLS architecture [RFC3031]. Note that [RFC3031] includes a glossary of MPLS terminology, such as ingress, label switched path, etc.
本文档假设您熟悉MPLS体系结构[RFC3031]。注意，[RFC3031]包括MPLS术语表，如入口、标签交换路径等。
Two LSRs which use LDP to exchange label/FEC mapping information are known as "LDP Peers" with respect to that information and we speak of there being an "LDP Session" between them. A single LDP session allows each peer to learn the other's label mappings; i.e., the protocol is bi-directional.
使用LDP交换标签/FEC映射信息的两个LSR被称为关于该信息的“LDP对等点”，我们称之为它们之间的“LDP会话”。单个LDP会话允许每个对等方学习另一方的标签映射；i、 例如，该协议是双向的。
There are four categories of LDP messages:
LDP消息分为四类：
1. Discovery messages, used to announce and maintain the presence of an LSR in a network.
1. 发现消息，用于宣布和维护网络中存在LSR。
2. Session messages, used to establish, maintain, and terminate sessions between LDP peers.
2. 会话消息，用于在LDP对等方之间建立、维护和终止会话。
3. Advertisement messages, used to create, change, and delete label mappings for FECs.
3. 广告消息，用于创建、更改和删除FEC的标签映射。
4. Notification messages, used to provide advisory information and to signal error information.
4. 通知消息，用于提供建议信息和发出错误信息的信号。
Discovery messages provide a mechanism whereby LSRs indicate their presence in a network by sending a Hello message periodically. This is transmitted as a UDP packet to the LDP port at the `all routers on this subnet' group multicast address. When an LSR chooses to establish a session with another LSR learned via the Hello message, it uses the LDP initialization procedure over TCP transport. Upon successful completion of the initialization procedure, the two LSRs are LDP peers, and may exchange advertisement messages.
发现消息提供了一种机制，LSR通过定期发送Hello消息来指示其在网络中的存在。这将作为UDP数据包传输到“此子网上的所有路由器”组多播地址的LDP端口。当一个LSR选择与另一个通过Hello消息学习的LSR建立会话时，它使用TCP传输上的LDP初始化过程。在成功完成初始化过程后，两个lsr是LDP对等方，并且可以交换广告消息。
When to request a label or advertise a label mapping to a peer is largely a local decision made by an LSR. In general, the LSR requests a label mapping from a neighboring LSR when it needs one, and advertises a label mapping to a neighboring LSR when it wishes the neighbor to use a label.
何时请求标签或向对等方发布标签映射在很大程度上是由LSR做出的本地决定。通常，LSR在需要时从相邻LSR请求标签映射，并在希望相邻LSR使用标签时播发到相邻LSR的标签映射。
Correct operation of LDP requires reliable and in order delivery of messages. To satisfy these requirements LDP uses the TCP transport for session, advertisement and notification messages; i.e., for everything but the UDP-based discovery mechanism.
LDP的正确运行需要可靠且有序地传递消息。为了满足这些要求，LDP使用TCP传输会话、广告和通知消息；i、 例如，除了基于UDP的发现机制之外，其他一切都适用。
All LDP messages have a common structure that uses a Type-Length-Value (TLV) encoding scheme; see Section "Type-Length-Value" encoding. The Value part of a TLV-encoded object, or TLV for short, may itself contain one or more TLVs.
所有LDP消息具有使用类型长度值（TLV）编码方案的公共结构；请参阅“类型长度值”编码一节。TLV编码对象的值部分（简称TLV）本身可能包含一个或多个TLV。
LDP errors and other events of interest are signaled to an LDP peer by notification messages.
LDP错误和其他感兴趣的事件通过通知消息通知LDP对等方。
There are two kinds of LDP notification messages:
LDP通知消息有两种：
1. Error notifications, used to signal fatal errors. If an LSR receives an error notification from a peer for an LDP session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all label mappings learned via the session.
1. 错误通知，用于发出致命错误的信号。如果LSR从对等方接收到LDP会话的错误通知，它将通过关闭会话的TCP传输连接并丢弃通过会话学习到的所有标签映射来终止LDP会话。
2. Advisory notifications, used to pass an LSR information about the LDP session or the status of some previous message received from the peer.
2. 咨询通知，用于向LSR传递有关LDP会话的信息或从对等方接收到的某些先前消息的状态。
Functionality may be added to LDP in the future. It is likely that future functionality will utilize new messages and object types (TLVs). It may be desirable to employ such new messages and TLVs within a network using older implementations that do not recognize them. While it is not possible to make every future enhancement backwards compatible, some prior planning can ease the introduction of new capabilities. This specification defines rules for handling unknown message types and unknown TLVs for this purpose.
将来可能会向LDP添加功能。未来的功能可能会利用新的消息和对象类型（TLV）。可能希望在网络中使用不识别这些新消息和TLV的旧实现来使用这些新消息和TLV。虽然不可能使未来的每个增强都向后兼容，但一些事先的规划可以简化新功能的引入。本规范定义了为此目的处理未知消息类型和未知TLV的规则。
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]中所述进行解释。
It is necessary to precisely specify which packets may be mapped to each LSP. This is done by providing a FEC specification for each LSP. The FEC identifies the set of IP packets which may be mapped to that LSP.
有必要精确地指定哪些包可以映射到每个LSP。这是通过为每个LSP提供FEC规范来实现的。FEC识别可映射到该LSP的IP分组的集合。
Each FEC is specified as a set of one or more FEC elements. Each FEC element identifies a set of packets which may be mapped to the corresponding LSP. When an LSP is shared by multiple FEC elements, that LSP is terminated at (or before) the node where the FEC elements can no longer share the same path.
每个FEC被指定为一个或多个FEC元素的集合。每个FEC元素标识可映射到对应LSP的一组分组。当一个LSP被多个FEC元素共享时，该LSP在FEC元素不再共享同一路径的节点处（或之前）终止。
Following are the currently defined types of FEC elements. New element types may be added as needed:
以下是当前定义的FEC元素类型。可根据需要添加新的图元类型：
1. Address Prefix. This element is an address prefix of any length from 0 to a full address, inclusive.
1. 地址前缀。此元素是从0到完整地址（包括）的任意长度的地址前缀。
2. Host Address. This element is a full host address.
2. 主机地址。此元素是完整的主机地址。
(We will see below that an Address Prefix FEC element which is a full address has a different effect than a Host Address FEC element which has the same address.)
（我们将在下面看到，作为完整地址的地址前缀FEC元素与具有相同地址的主机地址FEC元素具有不同的效果。）
We say that a particular address "matches" a particular address prefix if and only if that address begins with that prefix. We also say that a particular packet matches a particular LSP if and only if that LSP has an Address Prefix FEC element which matches the packet's destination address. With respect to a particular packet and a particular LSP, we refer to any Address Prefix FEC element which matches the packet as the "matching prefix".
我们说，一个特定的地址“匹配”一个特定的地址前缀，当且仅当该地址以该前缀开头时。我们还说，一个特定的数据包与一个特定的LSP匹配，当且仅当该LSP具有一个地址前缀FEC元素，该元素与数据包的目的地地址匹配。对于特定分组和特定LSP，我们将与分组匹配的任何地址前缀FEC元素称为“匹配前缀”。
The procedure for mapping a particular packet to a particular LSP uses the following rules. Each rule is applied in turn until the packet can be mapped to an LSP.
将特定数据包映射到特定LSP的过程使用以下规则。每个规则依次应用，直到数据包可以映射到LSP。
- If there is exactly one LSP which has a Host Address FEC element that is identical to the packet's destination address, then the packet is mapped to that LSP.
- 如果只有一个LSP的主机地址FEC元素与数据包的目的地地址相同，则该数据包被映射到该LSP。
- If there are multiple LSPs, each containing a Host Address FEC element that is identical to the packet's destination address, then the packet is mapped to one of those LSPs. The procedure for selecting one of those LSPs is beyond the scope of this document.
- 如果存在多个LSP，每个LSP都包含与数据包的目的地地址相同的主机地址FEC元素，则数据包被映射到这些LSP中的一个。选择其中一个LSP的程序超出了本文件的范围。
- If a packet matches exactly one LSP, the packet is mapped to that LSP.
- 如果数据包恰好匹配一个LSP，则该数据包将映射到该LSP。
- If a packet matches multiple LSPs, it is mapped to the LSP whose matching prefix is the longest. If there is no one LSP whose matching prefix is longest, the packet is mapped to one from the set of LSPs whose matching prefix is longer than the others. The procedure for selecting one of those LSPs is beyond the scope of this document.
- 如果一个数据包匹配多个LSP，它将映射到匹配前缀最长的LSP。如果没有一个LSP的匹配前缀最长，则将该数据包映射到匹配前缀比其他LSP长的LSP集中的一个。选择其中一个LSP的程序超出了本文件的范围。
- If it is known that a packet must traverse a particular egress router, and there is an LSP which has an Address Prefix FEC element which is an address of that router, then the packet is mapped to that LSP. The procedure for obtaining this knowledge is beyond the scope of this document.
- 如果已知分组必须穿过特定出口路由器，并且存在具有地址前缀FEC元素的LSP，该地址前缀FEC元素是该路由器的地址，则该分组被映射到该LSP。获取这些知识的程序超出了本文件的范围。
The procedure for determining that a packet must traverse a particular egress router is beyond the scope of this document. (As an example, if one is running a link state routing algorithm, it may be possible to obtain this information from the link state data base. As another example, if one is running BGP, it may be possible to obtain this information from the BGP next hop attribute of the packet's route.)
确定数据包必须穿过特定出口路由器的过程超出了本文档的范围。（例如，如果正在运行链路状态路由算法，则可以从链路状态数据库获取此信息。另一个示例是，如果正在运行BGP，则可以从数据包路由的BGP下一跳属性获取此信息。）
It is worth pointing out a few consequences of these rules:
值得指出的是这些规则的一些后果：
- A packet may be sent on the LSP whose Address Prefix FEC element is the address of the packet's egress router ONLY if there is no LSP matching the packet's destination address.
- 仅当没有与分组的目的地地址匹配的LSP时，才可以在其地址前缀FEC元素是分组的出口路由器的地址的LSP上发送分组。
- A packet may match two LSPs, one with a Host Address FEC element and one with an Address Prefix FEC element. In this case, the packet is always assigned to the former.
- 一个数据包可以匹配两个LSP，一个具有主机地址FEC元素，另一个具有地址前缀FEC元素。在这种情况下，数据包总是分配给前者。
- A packet which does not match a particular Host Address FEC element may not be sent on the corresponding LSP, even if the Host Address FEC element identifies the packet's egress router.
- 与特定主机地址FEC元素不匹配的分组可能不会在相应LSP上发送，即使主机地址FEC元素识别分组的出口路由器。
The notion of "label space" is useful for discussing the assignment and distribution of labels. There are two types of label spaces:
“标签空间”的概念有助于讨论标签的分配和分布。标签空间有两种类型：
- Per interface label space. Interface-specific incoming labels are used for interfaces that use interface resources for labels. An example of such an interface is a label-controlled ATM interface that uses VCIs as labels, or a Frame Relay interface that uses DLCIs as labels.
- 每个接口标签空间。特定于接口的传入标签用于将接口资源用于标签的接口。此类接口的一个示例是使用VCI作为标签的标签控制ATM接口，或使用DLCI作为标签的帧中继接口。
Note that the use of a per interface label space only makes sense when the LDP peers are "directly connected" over an interface, and the label is only going to be used for traffic sent over that interface.
请注意，仅当LDP对等点通过接口“直接连接”时，使用每个接口标签空间才有意义，并且标签仅用于通过该接口发送的流量。
- Per platform label space. Platform-wide incoming labels are used for interfaces that can share the same labels.
- 每个平台标签空间。平台范围的传入标签用于可以共享相同标签的接口。
An LDP identifier is a six octet quantity used to identify an LSR label space. The first four octets identify the LSR and must be a globally unique value, such as a 32-bit router Id assigned to the LSR. The last two octets identify a specific label space within the LSR. The last two octets of LDP Identifiers for platform-wide label spaces are always both zero. This document uses the following print representation for LDP Identifiers:
LDP标识符是用于标识LSR标签空间的六个八位组数量。前四个八位字节标识LSR，并且必须是全局唯一的值，例如分配给LSR的32位路由器Id。最后两个八位组标识LSR中的特定标签空间。平台范围标签空间的LDP标识符的最后两个八位字节始终都为零。本文件对LDP标识符使用以下打印表示：
<LSR Id> : <label space id>
<LSR Id> : <label space id>
e.g., lsr171:0, lsr19:2.
e、 g.，lsr171:0，lsr19:2。
Note that an LSR that manages and advertises multiple label spaces uses a different LDP Identifier for each such label space.
注意，管理和播发多个标签空间的LSR对每个这样的标签空间使用不同的LDP标识符。
A situation where an LSR would need to advertise more than one label space to a peer and hence use more than one LDP Identifier occurs when the LSR has two links to the peer and both are ATM (and use per interface labels). Another situation would be where the LSR had two links to the peer, one of which is ethernet (and uses per platform labels) and the other of which is ATM.
当LSR有两个到对等方的链路且两者都是ATM（并且使用每个接口标签）时，LSR需要向对等方通告多个标签空间并因此使用多个LDP标识符的情况发生。另一种情况是，LSR有两条到对等方的链路，一条是以太网（使用每个平台的标签），另一条是ATM。
LDP sessions exist between LSRs to support label exchange between them.
LSR之间存在LDP会话，以支持它们之间的标签交换。
When an LSR uses LDP to advertise more than one label space to another LSR it uses a separate LDP session for each label space.
当一个LSR使用LDP向另一个LSR播发多个标签空间时，它为每个标签空间使用单独的LDP会话。
LDP uses TCP as a reliable transport for sessions.
LDP使用TCP作为会话的可靠传输。
When multiple LDP sessions are required between two LSRs there is one TCP session for each LDP session.
当两个LSR之间需要多个LDP会话时，每个LDP会话有一个TCP会话。
LDP sessions between LSRs that are not directly connected at the link level may be desirable in some situations.
在某些情况下，可能需要在链路级别不直接连接的lsr之间的LDP会话。
For example, consider a "traffic engineering" application where LSRa sends traffic matching some criteria via an LSP to non-directly connected LSRb rather than forwarding the traffic along its normally routed path.
例如，考虑一个“流量工程”应用，其中LSRA通过LSP向非直接连接LSRB发送一些匹配的流量，而不是沿着其正常路由的路径转发业务。
The path between LSRa and LSRb would include one or more intermediate LSRs (LSR1,...LSRn). An LDP session between LSRa and LSRb would enable LSRb to label switch traffic arriving on the LSP from LSRa by providing LSRb means to advertise labels for this purpose to LSRa.
LSRa和LSRb之间的路径将包括一个或多个中间LSR（LSR1，…LSRn）。LSRa和LSRb之间的LDP会话将使LSRb能够通过向LSRa提供LSRb方式来标记从LSRa到达LSP的交换机通信量。
In this situation LSRa would apply two labels to traffic it forwards on the LSP to LSRb: a label learned from LSR1 to forward traffic along the LSP path from LSRa to LSRb; and a label learned from LSRb to enable LSRb to label switch traffic arriving on the LSP.
在这种情况下，LSRa将对其在LSP上转发到LSRb的流量应用两个标签：一个从LSR1学习的标签，用于沿着LSP路径将流量从LSRa转发到LSRb；以及从LSRb学习的标签，以使LSRb能够标记到达LSP的交换机业务。
LSRa first adds the label learned via its LDP session with LSRb to the packet label stack (either by replacing the label on top of the packet label stack with it if the packet arrives labeled or by pushing it if the packet arrives unlabeled). Next, it pushes the label for the LSP learned from LSR1 onto the label stack.
LSRa首先将通过其与LSRb的LDP会话学习到的标签添加到数据包标签堆栈（如果数据包带标签到达，则用标签替换数据包标签堆栈顶部的标签；如果数据包未带标签到达，则推送标签）。接下来，它将从LSR1读入的LSP的标签推送到标签堆栈上。
LDP discovery is a mechanism that enables an LSR to discover potential LDP peers. Discovery makes it unnecessary to explicitly configure an LSR's label switching peers.
LDP发现是一种使LSR能够发现潜在LDP对等点的机制。发现使得无需显式配置LSR的标签交换对等点。
There are two variants of the discovery mechanism:
发现机制有两种变体：
- A basic discovery mechanism used to discover LSR neighbors that are directly connected at the link level.
- 一种基本的发现机制，用于发现在链路级别直接连接的LSR邻居。
- An extended discovery mechanism used to locate LSRs that are not directly connected at the link level.
- 一种扩展的发现机制，用于定位未在链路级别直接连接的LSR。
To engage in LDP Basic Discovery on an interface an LSR periodically sends LDP Link Hellos out the interface. LDP Link Hellos are sent as UDP packets addressed to the well-known LDP discovery port for the "all routers on this subnet" group multicast address.
为了在接口上进行LDP基本发现，LSR会定期向接口发送LDP链路。LDP链路hello作为UDP数据包发送到“此子网上的所有路由器”组多播地址的著名LDP发现端口。
An LDP Link Hello sent by an LSR carries the LDP Identifier for the label space the LSR intends to use for the interface and possibly additional information.
由LSR发送的LDP链路Hello携带LSR打算用于接口的标签空间的LDP标识符以及可能的附加信息。
Receipt of an LDP Link Hello on an interface identifies a "Hello adjacency" with a potential LDP peer reachable at the link level on the interface as well as the label space the peer intends to use for the interface.
在接口上接收到LDP链路Hello可识别“Hello邻接”，该“Hello邻接”具有在接口上的链路级别可到达的潜在LDP对等点以及对等点打算用于接口的标签空间。
LDP sessions between non-directly connected LSRs are supported by LDP Extended Discovery.
LDP扩展发现支持非直接连接的LSR之间的LDP会话。
To engage in LDP Extended Discovery an LSR periodically sends LDP Targeted Hellos to a specific address. LDP Targeted Hellos are sent as UDP packets addressed to the well-known LDP discovery port at the specific address.
为了进行LDP扩展发现，LSR定期向特定地址发送LDP目标Hello。以LDP为目标的HELLO作为UDP数据包发送到特定地址的著名LDP发现端口。
An LDP Targeted Hello sent by an LSR carries the LDP Identifier for the label space the LSR intends to use and possibly additional optional information.
由LSR发送的以LDP为目标的Hello携带LSR打算使用的标签空间的LDP标识符以及可能的附加可选信息。
Extended Discovery differs from Basic Discovery in the following ways:
扩展发现在以下方面与基本发现不同：
- A Targeted Hello is sent to a specific address rather than to the "all routers" group multicast address for the outgoing interface.
- 目标Hello发送到特定地址，而不是发送到传出接口的“所有路由器”组多播地址。
- Unlike Basic Discovery, which is symmetric, Extended Discovery is asymmetric.
- 与对称的基本发现不同，扩展发现是不对称的。
One LSR initiates Extended Discovery with another targeted LSR, and the targeted LSR decides whether to respond to or ignore the Targeted Hello. A targeted LSR that chooses to respond does so by periodically sending Targeted Hellos to the initiating LSR.
一个LSR使用另一个目标LSR启动扩展发现，目标LSR决定是响应还是忽略目标Hello。选择响应的目标LSR通过定期向发起LSR发送目标Hello来进行响应。
Receipt of an LDP Targeted Hello identifies a "Hello adjacency" with a potential LDP peer reachable at the network level and the label space the peer intends to use.
接收到以LDP为目标的Hello标识了一个“Hello邻接”，该邻接具有在网络级别可到达的潜在LDP对等点以及对等点打算使用的标签空间。
The exchange of LDP Discovery Hellos between two LSRs triggers LDP session establishment. Session establishment is a two step process:
两个LSR之间的LDP发现Hello的交换触发LDP会话建立。会话建立过程分为两步：
- Transport connection establishment. - Session initialization
- 传输连接建立会话初始化
The following describes establishment of an LDP session between LSRs LSR1 and LSR2 from LSR1's point of view. It assumes the exchange of Hellos specifying label space LSR1:a for LSR1 and label space LSR2:b for LSR2.
以下从LSR1的角度描述在LSRs LSR1和LSR2之间建立LDP会话。它假设交换hello，为LSR1指定标签空间LSR1:a，为LSR2指定标签空间LSR2:b。
The exchange of Hellos results in the creation of a Hello adjacency at LSR1 that serves to bind the link (L) and the label spaces LSR1:a and LSR2:b.
Hello的交换导致在LSR1处创建Hello邻接，用于绑定链接（L）和标签空间LSR1:a和LSR2:b。
1. If LSR1 does not already have an LDP session for the exchange of label spaces LSR1:a and LSR2:b it attempts to open a TCP connection for a new LDP session with LSR2.
1. 如果LSR1还没有用于交换标签空间LSR1:a和LSR2:b的LDP会话，它将尝试为与LSR2的新LDP会话打开TCP连接。
LSR1 determines the transport addresses to be used at its end (A1) and LSR2's end (A2) of the LDP TCP connection. Address A1 is determined as follows:
LSR1确定LDP TCP连接在其端（A1）和LSR2端（A2）使用的传输地址。地址A1的确定如下：
a. If LSR1 uses the Transport Address optional object (TLV) in Hello's it sends to LSR2 to advertise an address, A1 is the address LSR1 advertises via the optional object;
a. 如果LSR1在发送给LSR2的Hello中使用传输地址可选对象（TLV）播发地址，A1是LSR1通过可选对象播发的地址；
b. If LSR1 does not use the Transport Address optional object, A1 is the source address used in Hellos it sends to LSR2.
b. 如果LSR1不使用传输地址可选对象，A1是它发送给LSR2的Hellos中使用的源地址。
Similarly, address A2 is determined as follows:
类似地，地址A2确定如下：
a. If LSR2 uses the Transport Address optional object, A2 is the address LSR2 advertises via the optional object;
a. 如果LSR2使用传输地址可选对象，A2是LSR2通过可选对象播发的地址；
b. If LSR2 does not use the Transport Address optional object, A2 is the source address in Hellos received from LSR2.
b. 如果LSR2不使用传输地址可选对象，则A2是从LSR2接收的Hellos中的源地址。
2. LSR1 determines whether it will play the active or passive role in session establishment by comparing addresses A1 and A2 as unsigned integers. If A1 > A2, LSR1 plays the active role; otherwise it is passive.
2. LSR1通过将地址A1和A2作为无符号整数进行比较，确定它在会话建立中是扮演主动角色还是被动角色。如果A1>A2，则LSR1起积极作用；否则它是被动的。
The procedure for comparing A1 and A2 as unsigned integers is:
将A1和A2作为无符号整数进行比较的过程如下：
- If A1 and A2 are not in the same address family, they are incomparable, and no session can be established.
- 如果A1和A2不在同一地址族中，则它们是不可比较的，并且无法建立会话。
- Let U1 be the abstract unsigned integer obtained by treating A1 as a sequence of bytes, where the byte which appears earliest in the message is the most significant byte of the integer and the byte which appears latest in the message is the least significant byte of the integer.
- 设U1是通过将A1视为字节序列而获得的抽象无符号整数，其中消息中最早出现的字节是整数的最高有效字节，消息中最晚出现的字节是整数的最低有效字节。
Let U2 be the abstract unsigned integer obtained from A2 in a similar manner.
设U2为从A2以类似方式获得的抽象无符号整数。
- Compare U1 with U2. If U1 > U2, then A1 > A2; if U1 < U2, then A1 < A2.
- 比较U1和U2。如果U1>U2，则A1>A2；如果U1<U2，则A1<A2。
3. If LSR1 is active, it attempts to establish the LDP TCP connection by connecting to the well-known LDP port at address A2. If LSR1 is passive, it waits for LSR2 to establish the LDP TCP connection to its well-known LDP port.
3. 如果LSR1处于活动状态，它将尝试通过连接到地址A2处的已知LDP端口来建立LDP TCP连接。如果LSR1是被动的，它将等待LSR2建立到其已知LDP端口的LDP-TCP连接。
Note that when an LSR sends a Hello it selects the transport address for its end of the session connection and uses the Hello to advertise the address, either explicitly by including it in an optional Transport Address TLV or implicitly by omitting the TLV and using it as the Hello source address.
请注意，当LSR发送Hello时，它会为其会话连接的结束选择传输地址，并使用Hello来播发地址，或者显式地将其包含在可选传输地址TLV中，或者隐式地忽略TLV并将其用作Hello源地址。
An LSR MUST advertise the same transport address in all Hellos that advertise the same label space. This requirement ensures that two LSRs linked by multiple Hello adjacencies using the same label spaces play the same connection establishment role for each adjacency.
LSR必须在所有播发相同标签空间的hello中播发相同的传输地址。此要求确保由多个使用相同标签空间的Hello邻接链接的两个LSR对每个邻接起相同的连接建立作用。
After LSR1 and LSR2 establish a transport connection they negotiate session parameters by exchanging LDP Initialization messages. The parameters negotiated include LDP protocol version, label distribution method, timer values, VPI/VCI ranges for label controlled ATM, DLCI ranges for label controlled Frame Relay, etc.
LSR1和LSR2建立传输连接后，它们通过交换LDP初始化消息协商会话参数。协商的参数包括LDP协议版本、标签分配方法、定时器值、标签控制ATM的VPI/VCI范围、标签控制帧中继的DLCI范围等。
Successful negotiation completes establishment of an LDP session between LSR1 and LSR2 for the advertisement of label spaces LSR1:a and LSR2:b.
成功协商完成了LSR1和LSR2之间LDP会话的建立，用于标签空间LSR1:a和LSR2:b的广告。
The following describes the session initialization from LSR1's point of view.
下面从LSR1的角度描述会话初始化。
After the connection is established, if LSR1 is playing the active role, it initiates negotiation of session parameters by sending an Initialization message to LSR2. If LSR1 is passive, it waits for LSR2 to initiate the parameter negotiation.
建立连接后，如果LSR1正在扮演活动角色，它将通过向LSR2发送初始化消息来启动会话参数协商。如果LSR1是被动的，它将等待LSR2启动参数协商。
In general when there are multiple links between LSR1 and LSR2 and multiple label spaces to be advertised by each, the passive LSR cannot know which label space to advertise over a newly established TCP connection until it receives the LDP Initialization message on the connection. The Initialization message carries both the LDP Identifier for the sender's (active LSR's) label space and the LDP Identifier for the receiver's (passive LSR's) label space.
通常，当LSR1和LSR2之间存在多个链路以及每个链路要通告的多个标签空间时，被动LSR在收到连接上的LDP初始化消息之前，无法知道通过新建立的TCP连接通告哪个标签空间。初始化消息携带发送方（主动LSR）标签空间的LDP标识符和接收方（被动LSR）标签空间的LDP标识符。
By waiting for the Initialization message from its peer the passive LSR can match the label space to be advertised by the peer (as determined from the LDP Identifier in the PDU header for the Initialization message) with a Hello adjacency previously created when Hellos were exchanged.
通过等待来自其对等方的初始化消息，被动LSR可以将对等方要通告的标签空间（根据用于初始化消息的PDU报头中的LDP标识符确定）与先前在交换Hello时创建的Hello邻接相匹配。
1. When LSR1 plays the passive role:
1. 当LSR1扮演被动角色时：
a. If LSR1 receives an Initialization message it attempts to match the LDP Identifier carried by the message PDU with a Hello adjacency.
a. 如果LSR1接收到初始化消息，它将尝试将消息PDU携带的LDP标识符与Hello邻接匹配。
b. If there is a matching Hello adjacency, the adjacency specifies the local label space for the session.
b. 如果存在匹配的Hello邻接，则该邻接指定会话的本地标签空间。
Next LSR1 checks whether the session parameters proposed in the message are acceptable. If they are, LSR1 replies with an Initialization message of its own to propose the parameters it wishes to use and a KeepAlive message to signal acceptance of LSR2's parameters. If the parameters are not acceptable, LSR1 responds by sending a Session Rejected/Parameters Error Notification message and closing the TCP connection.
接下来，LSR1检查消息中建议的会话参数是否可接受。如果是，LSR1会回复一条自己的初始化消息，提出它希望使用的参数，并回复一条KeepAlive消息，表示接受LSR2的参数。如果参数不可接受，LSR1将通过发送会话拒绝/参数错误通知消息并关闭TCP连接来响应。
c. If LSR1 cannot find a matching Hello adjacency it sends a Session Rejected/No Hello Error Notification message and closes the TCP connection.
c. 如果LSR1找不到匹配的Hello邻接，它将发送会话拒绝/无Hello错误通知消息并关闭TCP连接。
d. If LSR1 receives a KeepAlive in response to its Initialization message, the session is operational from LSR1's point of view.
d. 如果LSR1收到一个KeepAlive以响应其初始化消息，则从LSR1的角度来看，会话是可操作的。
e. If LSR1 receives an Error Notification message, LSR2 has rejected its proposed session and LSR1 closes the TCP connection.
e. 如果LSR1收到错误通知消息，则LSR2已拒绝其建议的会话，并且LSR1关闭TCP连接。
2. When LSR1 plays the active role:
2. 当LSR1扮演主动角色时：
a. If LSR1 receives an Error Notification message, LSR2 has rejected its proposed session and LSR1 closes the TCP connection.
a. 如果LSR1收到错误通知消息，则LSR2已拒绝其建议的会话，并且LSR1关闭TCP连接。
b. If LSR1 receives an Initialization message, it checks whether the session parameters are acceptable. If so, it replies with a KeepAlive message. If the session parameters are unacceptable, LSR1 sends a Session Rejected/Parameters Error Notification message and closes the connection.
b. 如果LSR1收到初始化消息，它将检查会话参数是否可接受。如果是的话，它会回复一条KeepAlive消息。如果会话参数不可接受，LSR1将发送会话拒绝/参数错误通知消息并关闭连接。
c. If LSR1 receives a KeepAlive message, LSR2 has accepted its proposed session parameters.
c. 如果LSR1收到KeepAlive消息，则LSR2已接受其建议的会话参数。
d. When LSR1 has received both an acceptable Initialization message and a KeepAlive message the session is operational from LSR1's point of view.
d. 当LSR1同时收到可接受的初始化消息和KeepAlive消息时，从LSR1的角度来看，会话是可操作的。
It is possible for a pair of incompatibly configured LSRs that disagree on session parameters to engage in an endless sequence of messages as each NAKs the other's Initialization messages with Error Notification messages.
一对配置不兼容、在会话参数上不一致的LSR可能会参与无休止的消息序列，因为每一个LSR都会使用错误通知消息来NAK另一个LSR的初始化消息。
An LSR must throttle its session setup retry attempts with an exponential backoff in situations where Initialization messages are being NAK'd. It is also recommended that an LSR detecting such a situation take action to notify an operator.
在初始化消息被NAK'd的情况下，LSR必须通过指数退避来限制其会话设置重试尝试。还建议检测到这种情况的LSR采取行动通知操作员。
The session establishment setup attempt following a NAK'd Initialization message must be delayed no less than 15 seconds, and subsequent delays must grow to a maximum delay of no less than 2 minutes. The specific session establishment action that must be delayed is the attempt to open the session transport connection by the LSR playing the active role.
NAK初始化消息之后的会话建立设置尝试必须延迟不少于15秒，随后的延迟必须增加到不少于2分钟的最大延迟。必须延迟的特定会话建立操作是扮演活动角色的LSR尝试打开会话传输连接。
The throttled sequence of Initialization NAKs is unlikely to cease until operator intervention reconfigures one of the LSRs. After such a configuration action there is no further need to throttle subsequent session establishment attempts (until their initialization messages are NAK'd).
在操作员干预重新配置其中一个LSR之前，受限制的初始化NAK序列不太可能停止。在这样的配置操作之后，不再需要限制后续会话建立尝试（直到它们的初始化消息被NAK'd）。
Due to the asymmetric nature of session establishment, reconfiguration of the passive LSR will go unnoticed by the active LSR without some further action. Section "Hello Message" describes an optional mechanism an LSR can use to signal potential LDP peers that it has been reconfigured.
由于会话建立的不对称性，主动LSR不会注意到被动LSR的重新配置，而无需采取进一步的行动。“Hello Message”部分描述了一种可选机制，LSR可以使用该机制向潜在的LDP对等方发出信号，表明它已被重新配置。
It is convenient to describe LDP session negotiation behavior in terms of a state machine. We define the LDP state machine to have five possible states and present the behavior as a state transition table and as a state transition diagram.
用状态机描述LDP会话协商行为很方便。我们将LDP状态机定义为五种可能的状态，并将其行为表示为状态转换表和状态转换图。
Session Initialization State Transition Table
会话初始化状态转换表
STATE EVENT NEW STATE
状态事件新状态
NON EXISTENT Session TCP connection established INITIALIZED established
已建立不存在的会话TCP连接已初始化
INITIALIZED Transmit Initialization msg OPENSENT (Active Role)
已初始化传输初始化消息OPENSENT（活动角色）
Receive acceptable OPENREC Initialization msg (Passive Role ) Action: Transmit Initialization msg and KeepAlive msg
接收可接受的OPENREC初始化消息（被动角色）操作：发送初始化消息和保持激活消息
Receive Any other LDP msg NON EXISTENT Action: Transmit Error Notification msg (NAK) and close transport connection
接收任何其他LDP消息不存在操作：发送错误通知消息（NAK）并关闭传输连接
OPENREC Receive KeepAlive msg OPERATIONAL
OPENREC接收KeepAlive消息操作
Receive Any other LDP msg NON EXISTENT Action: Transmit Error Notification msg (NAK) and close transport connection
接收任何其他LDP消息不存在操作：发送错误通知消息（NAK）并关闭传输连接
OPENSENT Receive acceptable OPENREC Initialization msg Action: Transmit KeepAlive msg
OPENSENT接收可接受的OPENREC初始化消息操作：发送KeepAlive消息
Receive Any other LDP msg NON EXISTENT Action: Transmit Error Notification msg (NAK) and close transport connection
接收任何其他LDP消息不存在操作：发送错误通知消息（NAK）并关闭传输连接
OPERATIONAL Receive Shutdown msg NON EXISTENT Action: Transmit Shutdown msg and close transport connection
操作接收关机消息不存在操作：发送关机消息并关闭传输连接
Receive other LDP msgs OPERATIONAL
接收其他LDP MSG运行
Timeout NON EXISTENT Action: Transmit Shutdown msg and close transport connection
超时不存在操作：传输关机消息并关闭传输连接
Session Initialization State Transition Diagram
会话初始化状态转换图
+------------+
| |
+------------>|NON EXISTENT|<--------------------+
| | | |
| +------------+ |
| Session | ^ |
| connection | | |
| established | | Rx any LDP msg except |
| V | Init msg or Timeout |
| +-----------+ |
Rx Any other | | | |
msg or | |INITIALIZED| |
Timeout / | +---| |-+ |
Tx NAK msg | | +-----------+ | |
| | (Passive Role) | (Active Role) |
| | Rx Acceptable | Tx Init msg |
| | Init msg / | |
| | Tx Init msg | |
| | Tx KeepAlive | |
| V msg V |
| +-------+ +--------+ |
| | | | | |
+---|OPENREC| |OPENSENT|----------------->|
+---| | | | Rx Any other msg |
| +-------+ +--------+ or Timeout |
Rx KeepAlive | ^ | Tx NAK msg |
msg | | | |
| | | Rx Acceptable |
| | | Init msg / |
| +----------------+ Tx KeepAlive msg |
| |
| +-----------+ |
+----->| | |
|OPERATIONAL| |
| |---------------------------->+
+-----------+ Rx Shutdown msg
All other | ^ or Timeout /
LDP msgs | | Tx Shutdown msg
| |
+---+
+------------+
| |
+------------>|NON EXISTENT|<--------------------+
| | | |
| +------------+ |
| Session | ^ |
| connection | | |
| established | | Rx any LDP msg except |
| V | Init msg or Timeout |
| +-----------+ |
Rx Any other | | | |
msg or | |INITIALIZED| |
Timeout / | +---| |-+ |
Tx NAK msg | | +-----------+ | |
| | (Passive Role) | (Active Role) |
| | Rx Acceptable | Tx Init msg |
| | Init msg / | |
| | Tx Init msg | |
| | Tx KeepAlive | |
| V msg V |
| +-------+ +--------+ |
| | | | | |
+---|OPENREC| |OPENSENT|----------------->|
+---| | | | Rx Any other msg |
| +-------+ +--------+ or Timeout |
Rx KeepAlive | ^ | Tx NAK msg |
msg | | | |
| | | Rx Acceptable |
| | | Init msg / |
| +----------------+ Tx KeepAlive msg |
| |
| +-----------+ |
+----->| | |
|OPERATIONAL| |
| |---------------------------->+
+-----------+ Rx Shutdown msg
All other | ^ or Timeout /
LDP msgs | | Tx Shutdown msg
| |
+---+
An LDP session with a peer has one or more Hello adjacencies.
与对等方的LDP会话具有一个或多个Hello邻接。
An LDP session has multiple Hello adjacencies when a pair of LSRs is connected by multiple links that share the same label space; for example, multiple PPP links between a pair of routers. In this situation the Hellos an LSR sends on each such link carry the same LDP Identifier.
当一对lsr由共享相同标签空间的多个链路连接时，LDP会话具有多个Hello邻接；例如，一对路由器之间的多个PPP链路。在这种情况下，LSR在每个这样的链路上发送的hello携带相同的LDP标识符。
LDP includes mechanisms to monitor the necessity of an LDP session and its Hello adjacencies.
LDP包括监控LDP会话必要性及其Hello邻接的机制。
LDP uses the regular receipt of LDP Discovery Hellos to indicate a peer's intent to use the label space identified by the Hello. An LSR maintains a hold timer with each Hello adjacency which it restarts when it receives a Hello that matches the adjacency. If the timer expires without receipt of a matching Hello from the peer, LDP concludes that the peer no longer wishes to label switch using that label space for that link (or target, in the case of Targeted Hellos) or that the peer has failed. The LSR then deletes the Hello adjacency. When the last Hello adjacency for a LDP session is deleted, the LSR terminates the LDP session by sending a Notification message and closing the transport connection.
LDP使用LDP发现Hellos的常规接收来指示对等方使用Hello标识的标签空间的意图。LSR为每个Hello邻接维护一个保持计时器，当接收到与该邻接匹配的Hello时，该计时器将重新启动。如果计时器在没有收到对等方的匹配Hello的情况下过期，则LDP认为对等方不再希望使用该链接的标签空间（或目标，在目标Hello的情况下）标记交换机，或者对等方失败。然后，LSR删除Hello邻接。当LDP会话的最后一个Hello邻接被删除时，LSR通过发送通知消息并关闭传输连接来终止LDP会话。
LDP includes mechanisms to monitor the integrity of the LDP session.
LDP包括监控LDP会话完整性的机制。
LDP uses the regular receipt of LDP PDUs on the session transport connection to monitor the integrity of the session. An LSR maintains a KeepAlive timer for each peer session which it resets whenever it receives an LDP PDU from the session peer. If the KeepAlive timer expires without receipt of an LDP PDU from the peer the LSR concludes that the transport connection is bad or that the peer has failed, and it terminates the LDP session by closing the transport connection.
LDP使用会话传输连接上的LDP PDU的定期接收来监视会话的完整性。LSR为每个对等会话维护一个KeepAlive计时器，每当它从会话对等方接收到LDP PDU时，该计时器就会重置。如果KeepAlive计时器在没有从对等方收到LDP PDU的情况下过期，则LSR得出结论，认为传输连接已损坏或对等方已失败，并通过关闭传输连接终止LDP会话。
After an LDP session has been established, an LSR must arrange that its peer receive an LDP PDU from it at least every KeepAlive time period to ensure the peer restarts the session KeepAlive timer. The LSR may send any protocol message to meet this requirement. In circumstances where an LSR has no other information to communicate to its peer, it sends a KeepAlive message.
LDP会话建立后，LSR必须安排其对等方至少在每个KeepAlive时间段从其接收LDP PDU，以确保对等方重新启动会话KeepAlive计时器。LSR可以发送任何协议消息以满足此要求。在LSR没有其他信息与对等方通信的情况下，它会发送一条KeepAlive消息。
An LSR may choose to terminate an LDP session with a peer at any time. Should it choose to do so, it informs the peer with a Shutdown message.
LSR可以选择随时终止与对等方的LDP会话。如果它选择这样做，它会向对等方发送关闭消息。
The MPLS architecture [RF3031] allows an LSR to distribute a FEC label binding in response to an explicit request from another LSR. This is known as Downstream On Demand label distribution. It also allows an LSR to distribute label bindings to LSRs that have not explicitly requested them. [RFC3031] calls this method of label distribution Unsolicited Downstream; this document uses the term Downstream Unsolicited.
MPLS体系结构[RF3031]允许LSR分发FEC标签绑定，以响应来自另一个LSR的显式请求。这称为下游按需标签分发。它还允许LSR将标签绑定分发给未明确请求它们的LSR。[RFC3031]调用这种未经请求的下游标签分发方法；本文件使用“未经请求的下游”一词。
Both of these label distribution techniques may be used in the same network at the same time. However, for any given LDP session, each LSR must be aware of the label distribution method used by its peer in order to avoid situations where one peer using Downstream Unsolicited label distribution assumes its peer is also. See Section "Downstream on Demand label Advertisement".
这两种标签分发技术可以同时在同一网络中使用。然而，对于任何给定的LDP会话，每个LSR必须知道其对等方所使用的标签分发方法，以避免使用下游未经请求的标签分发的一个对等方假设其对等方也是。见“下游按需标签广告”一节。
The behavior of the initial setup of LSPs is determined by whether the LSR is operating with independent or ordered LSP control. An LSR may support both types of control as a configurable option.
LSP初始设置的行为取决于LSR是以独立还是有序LSP控制运行。LSR可以作为可配置选项支持这两种类型的控制。
When using independent LSP control, each LSR may advertise label mappings to its neighbors at any time it desires. For example, when operating in independent Downstream on Demand mode, an LSR may answer requests for label mappings immediately, without waiting for a label mapping from the next hop. When operating in independent Downstream Unsolicited mode, an LSR may advertise a label mapping for a FEC to its neighbors whenever it is prepared to label-switch that FEC.
当使用独立的LSP控制时，每个LSR可以在其希望的任何时间向其邻居公布标签映射。例如，在独立下游按需模式下运行时，LSR可以立即响应标签映射请求，而无需等待来自下一跳的标签映射。当在独立下游未经请求的模式下操作时，LSR可在其准备标记该FEC的交换机时向其邻居通告该FEC的标签映射。
A consequence of using independent mode is that an upstream label can be advertised before a downstream label is received.
使用独立模式的结果是，可以在接收到下游标签之前通告上游标签。
When using LSP ordered control, an LSR may initiate the transmission of a label mapping only for a FEC for which it has a label mapping for the FEC next hop, or for which the LSR is the egress. For each FEC for which the LSR is not the egress and no mapping exists, the LSR MUST wait until a label from a downstream LSR is received before mapping the FEC and passing corresponding labels to upstream LSRs. An LSR may be an egress for some FECs and a non-egress for others. An LSR may act as an egress LSR, with respect to a particular FEC, under any of the following conditions:
当使用LSP顺序控制时，LSR可以仅针对其具有FEC下一跳的标签映射的FEC，或者对于其LSR是出口的FEC，发起标签映射的传输。对于LSR不是出口且不存在映射的每个FEC，LSR必须等到收到来自下游LSR的标签后，才能映射FEC并将相应的标签传递给上游LSR。LSR可以是一些fec的出口，而其他fec的非出口。在以下任何条件下，LSR可作为特定FEC的出口LSR：
1. The FEC refers to the LSR itself (including one of its directly attached interfaces).
1. FEC指的是LSR本身（包括其一个直接连接的接口）。
2. The next hop router for the FEC is outside of the Label Switching Network.
2. FEC的下一跳路由器位于标签交换网络之外。
3. FEC elements are reachable by crossing a routing domain boundary, such as another area for OSPF summary networks, or another autonomous system for OSPF AS externals and BGP routes [RFC2328] [RFC1771].
3. FEC元素可以通过跨越路由域边界来访问，例如OSPF摘要网络的另一个区域，或者OSPF作为外部和BGP路由的另一个自治系统[RFC2328][RFC1771]。
Note that whether an LSR is an egress for a given FEC may change over time, depending on the state of the network and LSR configuration settings.
注意，LSR是否是给定FEC的出口可以随时间而改变，这取决于网络的状态和LSR配置设置。
The MPLS architecture [RFC3031] introduces the notion of label retention mode which specifies whether an LSR maintains a label binding for a FEC learned from a neighbor that is not its next hop for the FEC.
MPLS体系结构[RFC3031]引入了标签保留模式的概念，该模式指定LSR是否为从不是FEC下一跳的邻居处学习的FEC维护标签绑定。
In Downstream Unsolicited advertisement mode, label mapping advertisements for all routes may be received from all peer LSRs. When using conservative label retention, advertised label mappings are retained only if they will be used to forward packets (i.e., if they are received from a valid next hop according to routing). If operating in Downstream on Demand mode, an LSR will request label mappings only from the next hop LSR according to routing. Since Downstream on Demand mode is primarily used when label conservation is desired (e.g., an ATM switch with limited cross connect space), it is typically used with the conservative label retention mode.
在下游未经请求的广告模式中，可从所有对等lsr接收所有路由的标签映射广告。使用保守标签保留时，仅当广告标签映射将用于转发数据包时（即，如果根据路由从有效的下一跳接收到它们），才会保留广告标签映射。如果在下游按需模式下运行，LSR将根据路由仅从下一跳LSR请求标签映射。由于下游按需模式主要在需要标签保留时使用（例如，交叉连接空间有限的ATM交换机），因此它通常与保守的标签保留模式一起使用。
The main advantage of the conservative mode is that only the labels that are required for the forwarding of data are allocated and maintained. This is particularly important in LSRs where the label space is inherently limited, such as in an ATM switch. A disadvantage of the conservative mode is that if routing changes the next hop for a given destination, a new label must be obtained from the new next hop before labeled packets can be forwarded.
保守模式的主要优点是只分配和维护数据转发所需的标签。这在标签空间固有受限的LSR中尤其重要，例如在ATM交换机中。保守模式的缺点是，如果路由更改给定目的地的下一跳，则必须从新的下一跳获取新标签，然后才能转发标记的数据包。
In Downstream Unsolicited advertisement mode, label mapping advertisements for all routes may be received from all LDP peers. When using liberal label retention, every label mappings received
在下游未经请求的广告模式中，所有路由的标签映射广告可从所有LDP对等方接收。使用自由标签保留时，收到的每个标签映射
from a peer LSR is retained regardless of whether the LSR is the next hop for the advertised mapping. When operating in Downstream on Demand mode with liberal label retention, an LSR might choose to request label mappings for all known prefixes from all peer LSRs. Note, however, that Downstream on Demand mode is typically used by devices such as ATM switch-based LSRs for which the conservative approach is recommended.
无论LSR是否是播发映射的下一个跃点，对等LSR都将保留。当以自由标签保留的下游按需模式运行时，LSR可能会选择从所有对等LSR请求所有已知前缀的标签映射。然而，请注意，下游按需模式通常由基于ATM交换机的LSR等设备使用，建议采用保守方法。
The main advantage of the liberal label retention mode is that reaction to routing changes can be quick because labels already exist. The main disadvantage of the liberal mode is that unneeded label mappings are distributed and maintained.
自由标签保留模式的主要优点是，对路由更改的反应可以很快，因为标签已经存在。自由模式的主要缺点是分布和维护不需要的标签映射。
Each interface on an LSR is configured to operate in either Downstream Unsolicited or Downstream on Demand advertisement mode. LSRs exchange advertisement modes during initialization. The major difference between Downstream Unsolicited and Downstream on Demand modes is in which LSR takes responsibility for initiating mapping requests and mapping advertisements.
LSR上的每个接口配置为在下游未经请求或下游按需广告模式下运行。LSR在初始化期间交换播发模式。下游未经请求和下游按需模式之间的主要区别在于，LSR负责发起映射请求和映射广告。
An LSR maintains learned labels in a Label Information Base (LIB). When operating in Downstream Unsolicited mode, the LIB entry for an address prefix associates a collection of (LDP Identifier, label) pairs with the prefix, one such pair for each peer advertising a label for the prefix.
LSR在标签信息库（LIB）中维护学习的标签。当在下游非请求模式下操作时，地址前缀的LIB条目将（LDP标识符、标签）对的集合与前缀相关联，每个对等方一个这样的对为前缀宣传标签。
When the next hop for a prefix changes the LSR must retrieve the label advertised by the new next hop from the LIB for use in forwarding. To retrieve the label the LSR must be able to map the next hop address for the prefix to an LDP Identifier.
当前缀的下一个跃点更改时，LSR必须从库中检索新的下一个跃点播发的标签，以用于转发。要检索标签，LSR必须能够将前缀的下一跳地址映射到LDP标识符。
Similarly, when the LSR learns a label for a prefix from an LDP peer, it must be able to determine whether that peer is currently a next hop for the prefix to determine whether it needs to start using the newly learned label when forwarding packets that match the prefix. To make that decision the LSR must be able to map an LDP Identifier to the peer's addresses to check whether any are a next hop for the prefix.
类似地，当LSR从LDP对等方学习前缀的标签时，它必须能够确定该对等方当前是否是前缀的下一跳，以确定在转发与前缀匹配的分组时是否需要开始使用新学习的标签。为了做出这个决定，LSR必须能够将LDP标识符映射到对等方的地址，以检查是否有任何LDP标识符是前缀的下一跳。
To enable LSRs to map between a peer LDP identifier and the peer's addresses, LSRs advertise their addresses using LDP Address and Withdraw Address messages.
为了使LSR能够在对等LDP标识符和对等地址之间映射，LSR使用LDP地址和收回地址消息来公布其地址。
An LSR sends an Address message to advertise its addresses to a peer. An LSR sends a Withdraw Address message to withdraw previously advertised addresses from a peer
LSR发送地址消息以向对等方公布其地址。LSR发送撤销地址消息，以从对等方撤销先前公布的地址
Loop detection is a configurable option which provides a mechanism for finding looping LSPs and for preventing Label Request messages from looping in the presence of non-merge capable LSRs.
循环检测是一个可配置的选项，它提供了一种机制，用于查找循环LSP，并防止标签请求消息在存在不支持合并的LSR时循环。
The mechanism makes use of Path Vector and Hop Count TLVs carried by Label Request and Label Mapping messages. It builds on the following basic properties of these TLVs:
该机制利用标签请求和标签映射消息携带的路径向量和跳数TLV。它基于这些TLV的以下基本属性：
- A Path Vector TLV contains a list of the LSRs that its containing message has traversed. An LSR is identified in a Path Vector list by its unique LSR Identifier (Id), which is the first four octets of its LDP Identifier. When an LSR propagates a message containing a Path Vector TLV it adds its LSR Id to the Path Vector list. An LSR that receives a message with a Path Vector that contains its LSR Id detects that the message has traversed a loop. LDP supports the notion of a maximum allowable Path Vector length; an LSR that detects a Path Vector has reached the maximum length behaves as if the containing message has traversed a loop.
- 路径向量TLV包含其包含消息所遍历的LSR列表。LSR在路径向量列表中由其唯一的LSR标识符（Id）标识，该标识符是其LDP标识符的前四个八位字节。当LSR传播包含路径向量TLV的消息时，它会将其LSR Id添加到路径向量列表中。接收带有包含其LSR Id的路径向量的消息的LSR检测到该消息已穿过循环。LDP支持最大允许路径向量长度的概念；检测路径向量已达到最大长度的LSR的行为就好像包含的消息已穿过循环一样。
- A Hop Count TLV contains a count of the LSRS that the containing message has traversed. When an LSR propagates a message containing a Hop Count TLV it increments the count. An LSR that detects a Hop Count has reached a configured maximum value behaves as if the containing message has traversed a loop. By convention a count of 0 is interpreted to mean the hop count is unknown. Incrementing an unknown hop count value results in an unknown hop count value (0).
- 跃点计数TLV包含包含消息已遍历的LSR的计数。当LSR传播包含跃点计数TLV的消息时，它会增加计数。检测跃点计数已达到配置的最大值的LSR的行为就像包含消息的消息已遍历循环一样。按照惯例，计数为0表示跳数未知。递增未知跃点计数值将导致未知跃点计数值（0）。
The following paragraphs describes LDP loop detection procedures. For these paragraphs, and only these paragraphs, "MUST" is redefined to mean "MUST if configured for loop detection". The paragraphs specify messages that must carry Path Vector and Hop Count TLVs. Note that the Hop Count TLV and its procedures are used without the Path Vector TLV in situations when loop detection is not configured (see [RFC3035] and [RFC3034]).
以下段落描述LDP环路检测程序。对于这些段落，并且只有这些段落，“必须”重新定义为“如果配置为循环检测，则必须”。这些段落指定必须携带路径向量和跃点计数TLV的消息。请注意，在未配置环路检测的情况下（请参阅[RFC3035]和[RFC3034]），在不使用路径向量TLV的情况下使用跃点计数TLV及其过程。
The use of the Path Vector TLV and Hop Count TLV prevent Label Request messages from looping in environments that include non-merge capable LSRs.
使用路径向量TLV和跃点计数TLV可以防止标签请求消息在包含不支持合并的LSR的环境中循环。
The rules that govern use of the Hop Count TLV in Label Request messages by LSR R when Loop Detection is enabled are the following:
启用循环检测时，LSR在标签请求消息中使用跃点计数TLV的规则如下：
- The Label Request message MUST include a Hop Count TLV.
- 标签请求消息必须包含跃点计数TLV。
- If R is sending the Label Request because it is a FEC ingress, it MUST include a Hop Count TLV with hop count value 1.
- 如果R发送标签请求是因为它是FEC入口，那么它必须包含一个跃点计数TLV，跃点计数值为1。
- If R is sending the Label Request as a result of having received a Label Request from an upstream LSR, and if the received Label Request contains a Hop Count TLV, R MUST increment the received hop count value by 1 and MUST pass the resulting value in a Hop Count TLV to its next hop along with the Label Request message;
- 如果R由于从上游LSR接收到标签请求而发送标签请求，并且如果接收到的标签请求包含跃点计数TLV，则R必须将接收到的跃点计数值增加1，并且必须将跃点计数TLV中的结果值与标签请求消息一起传递到其下一个跃点；
The rules that govern use of the Path Vector TLV in Label Request messages by LSR R when Loop Detection is enabled are the following:
启用循环检测时，LSR在标签请求消息中使用路径向量TLV的规则如下：
- If R is sending the Label Request because it is a FEC ingress, then if R is non-merge capable, it MUST include a Path Vector TLV of length 1 containing its own LSR Id.
- 如果R发送标签请求是因为它是FEC入口，那么如果R不支持合并，它必须包括长度为1的路径向量TLV，该路径向量TLV包含它自己的LSR Id。
- If R is sending the Label Request as a result of having received a Label Request from an upstream LSR, then if the received Label Request contains a Path Vector TLV or if R is non-merge capable:
- 如果R由于从上游LSR接收到标签请求而发送标签请求，则如果接收到的标签请求包含路径向量TLV或如果R不支持合并：
R MUST add its own LSR Id to the Path Vector, and MUST pass the resulting Path Vector to its next hop along with the Label Request message. If the Label Request contains no Path Vector TLV, R MUST include a Path Vector TLV of length 1 containing its own LSR Id.
R必须将自己的LSR Id添加到路径向量，并且必须将生成的路径向量与标签请求消息一起传递到下一个跃点。如果标签请求不包含路径向量TLV，则R必须包含长度为1的路径向量TLV，该路径向量TLV包含其自己的LSR Id。
Note that if R receives a Label Request message for a particular FEC, and R has previously sent a Label Request message for that FEC to its next hop and has not yet received a reply, and if R intends to merge the newly received Label Request with the existing outstanding Label Request, then R does not propagate the Label Request to the next hop.
注意，如果R接收到特定FEC的标签请求消息，并且R先前已将该FEC的标签请求消息发送到其下一跳，并且尚未收到回复，并且如果R打算将新接收到的标签请求与现有未完成的标签请求合并，则R不会将标签请求传播到下一跳。
If R receives a Label Request message from its next hop with a Hop Count TLV which exceeds the configured maximum value, or with a Path Vector TLV containing its own LSR Id or which exceeds the maximum allowable length, then R detects that the Label Request message has traveled in a loop.
如果R从其下一个跃点接收到标签请求消息，其跃点计数TLV超过配置的最大值，或路径向量TLV包含其自己的LSR Id或超过最大允许长度，则R检测到标签请求消息已在循环中移动。
When R detects a loop, it MUST send a Loop Detected Notification message to the source of the Label Request message and drop the Label Request message.
当R检测到循环时，它必须向标签请求消息的源发送一条检测到循环的通知消息，并删除标签请求消息。
The use of the Path Vector TLV and Hop Count TLV in the Label Mapping message provide a mechanism to find and terminate looping LSPs. When an LSR receives a Label Mapping message from a next hop, the message is propagated upstream as specified below until an ingress LSR is reached or a loop is found.
在标签映射消息中使用路径向量TLV和跃点计数TLV提供了一种查找和终止循环LSP的机制。当LSR从下一跳接收到标签映射消息时，该消息将按照下面的规定向上游传播，直到到达入口LSR或找到循环为止。
The rules that govern the use of the Hop Count TLV in Label Mapping messages sent by an LSR R when Loop Detection is enabled are the following:
启用循环检测时，控制LSR发送的标签映射消息中跃点计数TLV的使用的规则如下：
- R MUST include a Hop Count TLV.
- R必须包含跃点计数TLV。
- If R is the egress, the hop count value MUST be 1.
- 如果R是出口，则跃点计数值必须为1。
- If the Label Mapping message is being sent to propagate a Label Mapping message received from the next hop to an upstream peer, the hop count value MUST be determined as follows:
- 如果发送标签映射消息是为了将从下一个跃点接收到的标签映射消息传播到上游对等点，则必须按如下方式确定跃点计数值：
o If R is a member of the edge set of an LSR domain whose LSRs do not perform 'TTL-decrement' (e.g., an ATM LSR domain or a Frame Relay LSR domain) and the upstream peer is within that domain, R MUST reset the hop count to 1 before propagating the message.
o 如果R是其LSR不执行“TTL递减”（例如，ATM LSR域或帧中继LSR域）的LSR域的边缘集的成员，且上游对等方在该域内，则R必须在传播消息之前将跳数重置为1。
o Otherwise, R MUST increment the hop count received from the next hop before propagating the message.
o 否则，R必须在传播消息之前增加从下一个跃点接收的跃点计数。
- If the Label Mapping message is not being sent to propagate a Label Mapping message, the hop count value MUST be the result of incrementing R's current knowledge of the hop count learned from previous Label Mapping messages. Note that this hop count value will be unknown if R has not received a Label Mapping message from the next hop.
- 如果不发送标签映射消息来传播标签映射消息，则跃点计数值必须是递增R从以前的标签映射消息中学习到的跃点计数的当前知识的结果。请注意，如果R没有从下一个跃点接收到标签映射消息，则该跃点计数值将是未知的。
Any Label Mapping message MAY contain a Path Vector TLV. The rules that govern the mandatory use of the Path Vector TLV in Label Mapping messages sent by LSR R when Loop Detection is enabled are the following:
任何标签映射消息都可能包含路径向量TLV。当启用循环检测时，控制LSR发送的标签映射消息中路径向量TLV的强制使用的规则如下：
- If R is the egress, the Label Mapping message need not include a Path Vector TLV.
- 如果R是出口，则标签映射消息不需要包括路径向量TLV。
- If R is sending the Label Mapping message to propagate a Label Mapping message received from the next hop to an upstream peer, then:
- 如果R正在发送标签映射消息以将从下一跳接收到的标签映射消息传播到上游对等方，则：
o If R is merge capable and if R has not previously sent a Label Mapping message to the upstream peer, then it MUST include a Path Vector TLV.
o 如果R具有合并功能，并且R以前没有向上游对等方发送标签映射消息，那么它必须包含路径向量TLV。
o If the received message contains an unknown hop count, then R MUST include a Path Vector TLV.
o 如果接收到的消息包含未知的跃点计数，则R必须包含路径向量TLV。
o If R has previously sent a Label Mapping message to the upstream peer, then it MUST include a Path Vector TLV if the received message reports an LSP hop count increase, a change in hop count from unknown to known, or a change from known to unknown.
o 如果R先前向上游对等方发送了标签映射消息，那么如果接收到的消息报告LSP跳数增加、跳数从未知变为已知或从已知变为未知，则它必须包括路径向量TLV。
If the above rules require R include a Path Vector TLV in the Label Mapping message, R computes it as follows:
如果上述规则要求R在标签映射消息中包含路径向量TLV，R将按如下方式计算：
o If the received Label Mapping message included a Path Vector, the Path Vector sent upstream MUST be the result of adding R's LSR Id to the received Path Vector.
o 如果接收到的标签映射消息包含路径向量，则向上游发送的路径向量必须是将R的LSR Id添加到接收到的路径向量的结果。
o If the received message had no Path Vector, the Path Vector sent upstream MUST be a path vector of length 1 containing R's LSR Id.
o 如果接收到的消息没有路径向量，则向上游发送的路径向量必须是长度为1且包含R的LSR Id的路径向量。
- If the Label Mapping message is not being sent to propagate a received message upstream, the Label Mapping message MUST include a Path Vector of length 1 containing R's LSR Id.
- 如果发送标签映射消息不是为了向上游传播接收到的消息，则标签映射消息必须包括长度为1的路径向量，该路径向量包含R的LSR Id。
If R receives a Label Mapping message from its next hop with a Hop Count TLV which exceeds the configured maximum value, or with a Path Vector TLV containing its own LSR Id or which exceeds the maximum allowable length, then R detects that the corresponding LSP contains a loop.
如果R从其下一个跃点接收到标签映射消息，其跃点计数TLV超过配置的最大值，或路径向量TLV包含其自身的LSR Id或超过最大允许长度，则R检测到相应的LSP包含循环。
When R detects a loop, it MUST stop using the label for forwarding, drop the Label Mapping message, and signal Loop Detected status to the source of the Label Mapping message.
当R检测到循环时，它必须停止使用标签进行转发，删除标签映射消息，并向标签映射消息的源发送循环检测状态信号。
If loop detection is desired in an MPLS domain, then it should be turned on in ALL LSRs within that MPLS domain, else loop detection will not operate properly and may result in undetected loops or in falsely detected loops.
如果需要在MPLS域中进行循环检测，则应在该MPLS域内的所有LSR中启用循环检测，否则循环检测将无法正常工作，并可能导致未检测到的循环或错误检测到的循环。
LSRs which are configured for loop detection are NOT expected to store the path vectors as part of the LSP state.
配置为环路检测的LSR不希望将路径向量存储为LSP状态的一部分。
Note that in a network where only non-merge capable LSRs are present, Path Vectors are passed downstream from ingress to egress, and are not passed upstream. Even when merge is supported, Path Vectors need not be passed upstream along an LSP which is known to reach the egress. When an LSR experiences a change of next hop, it need pass Path Vectors upstream only when it cannot tell from the hop count that the change of next hop does not result in a loop.
注意，在仅存在不支持合并的lsr的网络中，路径向量从入口向下传递到出口，而不是向上游传递。即使支持合并，路径向量也不需要沿着已知到达出口的LSP向上游传递。当LSR经历下一跳的变化时，只有当它不能从跳数判断下一跳的变化不会导致循环时，它才需要向上游传递路径向量。
In the case of ordered label distribution, Label Mapping messages are propagated from egress toward ingress, naturally creating the Path Vector along the way. In the case of independent label distribution, an LSR may originate a Label Mapping message for an FEC before receiving a Label Mapping message from its downstream peer for that FEC. In this case, the subsequent Label Mapping message for the FEC received from the downstream peer is treated as an update to LSP attributes, and the Label Mapping message must be propagated upstream. Thus, it is recommended that loop detection be configured in conjunction with ordered label distribution, to minimize the number of Label Mapping update messages.
在有序标签分布的情况下，标签映射消息从出口传播到入口，自然地沿途创建路径向量。在独立标签分发的情况下，LSR可以在从其下游对等方接收用于FEC的标签映射消息之前，为该FEC发起标签映射消息。在这种情况下，从下游对等方接收的FEC的后续标签映射消息被视为对LSP属性的更新，并且标签映射消息必须向上游传播。因此，建议结合有序标签分布配置循环检测，以尽量减少标签映射更新消息的数量。
This section specifies a mechanism to protect against the introduction of spoofed TCP segments into LDP session connection streams. The use of this mechanism MUST be supported as a configurable option.
本节指定了一种机制，以防止将伪造的TCP段引入LDP会话连接流。必须作为可配置选项支持使用此机制。
The mechanism is based on use of the TCP MD5 Signature Option specified in [RFC2385] for use by BGP. See [RFC1321] for a specification of the MD5 hash function.
该机制基于[RFC2385]中指定的供BGP使用的TCP MD5签名选项。有关MD5哈希函数的规范，请参见[RFC1321]。
The following quotes from [RFC2385] outline the security properties achieved by using the TCP MD5 Signature Option and summarizes its operation:
[RFC2385]中的以下引用概述了通过使用TCP MD5签名选项实现的安全属性，并总结了其操作：
"IESG Note
“IESG注释
This document describes current existing practice for securing BGP against certain simple attacks. It is understood to have security weaknesses against concerted attacks."
本文档描述了针对某些简单攻击保护BGP的现行做法。据了解，它在防范协同攻击方面存在安全弱点。”
"Abstract
“摘要
This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP."
本备忘录描述了一个TCP扩展，以增强BGP的安全性。它定义了一个新的TCP选项，用于在TCP段中携带MD5[RFC1321]摘要。此摘要的作用类似于该段的签名，包含仅对连接端点已知的信息。由于BGP使用TCP作为其传输，因此以本文所述的方式使用此选项可显著降低BGP受到某些安全攻击的危险。”
"Introduction
“导言
The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets.
此选项的主要动机是允许BGP保护自己，防止将伪造的TCP段引入连接流。特别值得关注的是TCP重置。
To spoof a connection using the scheme described in this paper, an attacker would not only have to guess TCP sequence numbers, but would also have had to obtain the password included in the MD5 digest. This password never appears in the connection stream, and the actual form of the password is up to the application. It could even change during the lifetime of a particular connection so long as this change was synchronized on both ends (although retransmission can become problematical in some TCP implementations with changing passwords).
要使用本文描述的方案欺骗连接，攻击者不仅必须猜测TCP序列号，还必须获得MD5摘要中包含的密码。此密码从未出现在连接流中，密码的实际形式取决于应用程序。它甚至可以在特定连接的生命周期内更改，只要此更改在两端同步（尽管在某些更改密码的TCP实现中重新传输可能会出现问题）。
Finally, there is no negotiation for the use of this option in a connection, rather it is purely a matter of site policy whether or not its connections use the option."
最后，对于在连接中使用此选项，没有进行任何协商，而是其连接是否使用此选项纯粹取决于站点策略。”
"MD5 as a Hashing Algorithm
“MD5作为哈希算法
Since this memo was first issued (under a different title), the MD5 algorithm has been found to be vulnerable to collision search attacks [Dobb], and is considered by some to be insufficiently strong for this type of application.
自本备忘录首次发布（标题不同）以来，MD5算法已被发现容易受到碰撞搜索攻击[Dobb]，一些人认为该算法对于此类应用而言不够强大。
This memo still specifies the MD5 algorithm, however, since the option has already been deployed operationally, and there was no "algorithm type" field defined to allow an upgrade using the same option number. The original document did not specify a type field since this would require at least one more byte, and it was felt at the time that taking 19 bytes for the complete option (which would probably be padded to 20 bytes in TCP implementations) would be too much of a waste of the already limited option space.
但是，此备忘录仍然指定了MD5算法，因为该选项已经在操作上部署，并且没有定义“算法类型”字段以允许使用相同的选项编号进行升级。原始文档没有指定类型字段，因为这将需要至少多一个字节，并且当时认为完整选项占用19个字节（在TCP实现中可能会填充为20个字节）会浪费已经有限的选项空间。
This does not prevent the deployment of another similar option which uses another hashing algorithm (like SHA-1). Also, if most implementations pad the 18 byte option as defined to 20 bytes anyway, it would be just as well to define a new option which contains an algorithm type field.
这并不妨碍部署另一个使用另一个散列算法（如SHA-1）的类似选项。此外，如果大多数实现都将定义的18字节选项填充为20字节，那么最好定义一个包含算法类型字段的新选项。
This would need to be addressed in another document, however."
然而，这需要在另一份文件中加以说明。”
End of quotes from [RFC2385].
[RFC2385]的报价结束。
LDP uses the TCP MD5 Signature Option as follows:
LDP使用TCP MD5签名选项，如下所示：
- Use of the MD5 Signature Option for LDP TCP connections is a configurable LSR option.
- LDP TCP连接使用MD5签名选项是一个可配置的LSR选项。
- An LSR that uses the MD5 Signature Option is configured with a password (shared secret) for each potential LDP peer.
- 使用MD5签名选项的LSR为每个潜在LDP对等方配置密码（共享秘密）。
- The LSR applies the MD5 algorithm as specified in [RFC2385] to compute the MD5 digest for a TCP segment to be sent to a peer. This computation makes use of the peer password as well as the TCP segment.
- LSR应用[RFC2385]中指定的MD5算法来计算发送给对等方的TCP段的MD5摘要。此计算使用对等密码以及TCP段。
- When the LSR receives a TCP segment with an MD5 digest, it validates the segment by calculating the MD5 digest (using its own record of the password) and compares the computed digest with the received digest. If the comparison fails, the segment is dropped without any response to the sender.
- 当LSR接收到带有MD5摘要的TCP段时，它通过计算MD5摘要（使用自己的密码记录）来验证该段，并将计算的摘要与接收到的摘要进行比较。如果比较失败，则删除该段而不向发送方作出任何响应。
- The LSR ignores LDP Hellos from any LSR for which a password has not been configured. This ensures that the LSR establishes LDP TCP connections only with LSRs for which a password has been configured.
- LSR忽略未配置密码的任何LSR中的LDP Hellos。这确保LSR仅与已配置密码的LSR建立LDP TCP连接。
Traffic Engineering [RFC2702] is expected to be an important MPLS application. MPLS support for Traffic Engineering uses explicitly routed LSPs, which need not follow normally-routed (hop-by-hop) paths as determined by destination-based routing protocols. CR-LDP [CRLDP] defines extensions to LDP to use LDP to set up explicitly routed LSPs.
流量工程[RFC2702]有望成为MPLS的一个重要应用。MPLS对流量工程的支持使用显式路由LSP，它不需要遵循由基于目的地的路由协议确定的正常路由（逐跳）路径。CR-LDP[CRLDP]定义了LDP的扩展，以使用LDP建立显式路由LSP。
Previous sections that describe LDP operation have discussed scenarios that involve the exchange of messages among LDP peers. This section specifies the message encodings and procedures for processing the messages.
前面描述LDP操作的部分讨论了涉及LDP对等点之间消息交换的场景。本节指定消息编码和处理消息的过程。
LDP message exchanges are accomplished by sending LDP protocol data units (PDUs) over LDP session TCP connections.
LDP消息交换是通过LDP会话TCP连接发送LDP协议数据单元（PDU）来完成的。
Each LDP PDU can carry one or more LDP messages. Note that the messages in an LDP PDU need not be related to one another. For example, a single PDU could carry a message advertising FEC-label bindings for several FECs, another message requesting label bindings for several other FECs, and a third notification message signaling some event.
每个LDP PDU可以承载一个或多个LDP消息。注意，LDP PDU中的消息不需要彼此相关。例如，单个PDU可以携带一条消息，该消息宣传多个FEC的FEC标签绑定，另一条消息请求多个其他FEC的标签绑定，以及一条第三条通知消息，通知一些事件。
Each LDP PDU is an LDP header followed by one or more LDP messages. The LDP header is:
每个LDP PDU是一个LDP报头，后跟一个或多个LDP消息。LDP报头是：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Two octet unsigned integer containing the version number of the protocol. This version of the specification specifies LDP protocol version 1.
版本2包含协议版本号的八位无符号整数。本规范版本规定了LDP协议版本1。
PDU Length Two octet integer specifying the total length of this PDU in octets, excluding the Version and PDU Length fields.
PDU长度两个八位整数，指定此PDU的总长度（以八位字节为单位），不包括版本和PDU长度字段。
The maximum allowable PDU Length is negotiable when an LDP session is initialized. Prior to completion of the negotiation the maximum allowable length is 4096 bytes.
初始化LDP会话时，可协商允许的最大PDU长度。在协商完成之前，最大允许长度为4096字节。
LDP Identifier Six octet field that uniquely identifies the label space of the sending LSR for which this PDU applies. The first four octets identify the LSR and must be a globally unique value. It should be a 32-bit router Id assigned to the LSR and also used to identify it in loop detection Path Vectors. The last two octets identify a label space within the LSR. For a platform-wide label space, these should both be zero.
LDP标识符六个八位组字段，唯一标识此PDU应用的发送LSR的标签空间。前四个八位组标识LSR，并且必须是全局唯一的值。它应该是分配给LSR的32位路由器Id，还用于在循环检测路径向量中识别它。最后两个八位组标识LSR中的标签空间。对于平台范围的标签空间，两者都应为零。
Note that there is no alignment requirement for the first octet of an LDP PDU.
请注意，LDP PDU的第一个八位组没有对齐要求。
LDP defines messages, TLVs and procedures in the following areas:
LDP在以下方面定义了消息、TLV和程序：
- Peer discovery; - Session management; - Label distribution; - Notification of errors and advisory information.
- 对等发现；-会话管理；-标签分发；-错误通知和咨询信息。
The sections that follow describe the message and TLV encodings for these areas and the procedures that apply to them.
以下各节描述了这些区域的消息和TLV编码以及适用于它们的过程。
The label distribution procedures are complex and are difficult to describe fully, coherently and unambiguously as a collection of separate message and TLV specifications.
标签分发过程非常复杂，很难作为单独的消息和TLV规范的集合进行完整、连贯和明确的描述。
Appendix A, "LDP Label Distribution Procedures", describes the label distribution procedures in terms of label distribution events that may occur at an LSR and how the LSR must respond. Appendix A is the specification of LDP label distribution procedures. If a procedure described elsewhere in this document conflicts with Appendix A, Appendix A specifies LDP behavior.
附录A“LDP标签分发程序”描述了LSR可能发生的标签分发事件以及LSR必须如何响应的标签分发程序。附录A是LDP标签分发程序的规范。如果本文件其他地方描述的程序与附录a冲突，附录a规定了LDP行为。
LDP uses a Type-Length-Value (TLV) encoding scheme to encode much of the information carried in LDP messages.
LDP使用类型长度值（TLV）编码方案对LDP消息中携带的大部分信息进行编码。
An LDP TLV is encoded as a 2 octet field that uses 14 bits to specify a Type and 2 bits to specify behavior when an LSR doesn't recognize the Type, followed by a 2 octet Length Field, followed by a variable length Value field.
LDP TLV编码为2个八位字段，当LSR不识别类型时，使用14位指定类型，使用2位指定行为，后跟2个八位长度字段，后跟可变长度值字段。
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Value |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear (=0), a notification must be returned to the message originator and the entire message must be ignored; if U is set (=1), the unknown TLV is silently ignored and the rest of the message is processed as if the unknown TLV did not exist. The sections following that define TLVs specify a value for the U-bit.
U位未知TLV位。收到未知TLV后，如果U为清除（=0），则必须向消息发起人返回通知，并且必须忽略整个消息；如果U设置为（=1），未知TLV将被静默忽略，消息的其余部分将被处理，就像未知TLV不存在一样。下面定义TLV的部分指定U位的值。
F bit Forward unknown TLV bit. This bit applies only when the U bit is set and the LDP message containing the unknown TLV is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the containing message; if F is set (=1), the unknown TLV is forwarded with the containing message. The sections following that define TLVs specify a value for the F-bit.
F位转发未知TLV位。该位仅在设置了U位且包含未知TLV的LDP消息要转发时适用。如果F为清除（=0），则未知TLV不会与包含的消息一起转发；如果F设置为（=1），则未知TLV将与包含的消息一起转发。下面定义TLV的部分指定F位的值。
Type Encodes how the Value field is to be interpreted.
类型编码如何解释值字段。
Length Specifies the length of the Value field in octets.
长度以八位字节为单位指定值字段的长度。
Value Octet string of Length octets that encodes information to be interpreted as specified by the Type field.
值八位字节长度八位字节的字符串，该字符串对类型字段指定的要解释的信息进行编码。
Note that there is no alignment requirement for the first octet of a TLV.
请注意，TLV的第一个八位组没有对齐要求。
Note that the Value field itself may contain TLV encodings. That is, TLVs may be nested.
请注意，值字段本身可能包含TLV编码。也就是说，TLV可以嵌套。
The TLV encoding scheme is very general. In principle, everything appearing in an LDP PDU could be encoded as a TLV. This specification does not use the TLV scheme to its full generality. It
TLV编码方案非常通用。原则上，LDP PDU中出现的所有内容都可以编码为TLV。本规范未充分利用TLV方案的通用性。信息技术
is not used where its generality is unnecessary and its use would waste space unnecessarily. These are usually places where the type of a value to be encoded is known, for example by its position in a message or an enclosing TLV, and the length of the value is fixed or readily derivable from the value encoding itself.
在其通用性不必要且使用会不必要地浪费空间的情况下，不使用。这些通常是已知要编码的值类型的地方，例如通过其在消息或封闭TLV中的位置，并且值的长度是固定的或容易从值编码本身派生。
Some of the TLVs defined for LDP are similar to one another. For example, there is a Generic Label TLV, an ATM Label TLV, and a Frame Relay TLV; see Sections "Generic Label TLV", "ATM Label TLV", and "Frame Relay TLV".
为LDP定义的一些TLV彼此相似。例如，存在通用标签TLV、ATM标签TLV和帧中继TLV；请参阅“通用标签TLV”、“ATM标签TLV”和“帧中继TLV”部分。
While it is possible to think about TLVs related in this way in terms of a TLV type that specifies a TLV class and a TLV subtype that specifies a particular kind of TLV within that class, this specification does not formalize the notion of a TLV subtype.
虽然可以根据指定TLV类的TLV类型和指定该类中特定类型TLV的TLV子类型来考虑以这种方式相关的TLV，但本规范并未将TLV子类型的概念形式化。
The specification assigns type values for related TLVs, such as the label TLVs, from a contiguous block in the 16-bit TLV type number space.
该规范从16位TLV类型号空间中的连续块为相关TLV（如标签TLV）分配类型值。
Section "TLV Summary" lists the TLVs defined in this version of the protocol and the section in this document that describes each.
“TLV摘要”部分列出了本版本协议中定义的TLV，以及本文档中描述每个TLV的部分。
There are several parameters used by more than one LDP message. The TLV encodings for these commonly used parameters are specified in this section.
多个LDP消息使用多个参数。本节规定了这些常用参数的TLV编码。
Labels are bound to Forwarding Equivalence Classes (FECs). A FEC is a list of one or more FEC elements. The FEC TLV encodes FEC items.
标签绑定到转发等价类（FEC）。FEC是一个或多个FEC元素的列表。FEC TLV对FEC项目进行编码。
Its encoding is:
其编码为：
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|0| FEC (0x0100) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element 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|0| FEC (0x0100) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Element n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FEC Element 1 to FEC Element n There are several types of FEC elements; see Section "FECs". The FEC element encoding depends on the type of FEC element.
FEC元素1到FEC元素n有几种类型的FEC元素；见“FECs”一节。FEC元素编码取决于FEC元素的类型。
A FEC Element value is encoded as a 1 octet field that specifies the element type, and a variable length field that is the type-dependent element value. Note that while the representation of the FEC element value is type-dependent, the FEC element encoding itself is one where standard LDP TLV encoding is not used.
FEC元素值编码为指定元素类型的1个八位组字段，以及作为类型相关元素值的可变长度字段。注意，虽然FEC元素值的表示依赖于类型，但是FEC元素编码本身是不使用标准LDP TLV编码的编码。
The FEC Element value encoding is:
FEC元素值编码为：
FEC Element Type Value type name
FEC元素类型值类型名称
Wildcard 0x01 No value; i.e., 0 value octets; see below. Prefix 0x02 See below. Host Address 0x03 Full host address; see below.
通配符0x01无值；i、 e，0值八位组；见下文。前缀0x02见下文。主机地址0x03完整主机地址；见下文。
Note that this version of LDP supports the use of multiple FEC Elements per FEC for the Label Mapping message only. The use of multiple FEC Elements in other messages is not permitted in this version, and is a subject for future study.
请注意，此版本的LDP仅支持在标签映射消息中为每个FEC使用多个FEC元素。本版本不允许在其他消息中使用多个FEC元素，这是未来研究的主题。
Wildcard FEC Element To be used only in the Label Withdraw and Label Release Messages. Indicates the withdraw/release is to be applied to all FECs associated with the label within the following label TLV. Must be the only FEC Element in the FEC TLV.
通配符FEC元素仅用于标签撤消和标签释放消息。指示撤回/释放将应用于以下标签TLV中与标签相关的所有FEC。必须是FEC TLV中唯一的FEC元素。
Prefix FEC Element value encoding:
前缀FEC元素值编码：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (2) | Address Family | PreLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field.
地址族两个八位字节数量，包含[RFC1700]中地址族编号的值，该值为前缀字段中的地址前缀编码地址族。
PreLen One octet unsigned integer containing the length in bits of the address prefix that follows. A length of zero indicates a prefix that matches all addresses (the default destination); in this case the Prefix itself is zero octets).
前置一个八位无符号整数，包含后面地址前缀的长度（以位为单位）。长度为零表示与所有地址匹配的前缀（默认目的地）；在这种情况下，前缀本身是零个八位字节）。
Prefix An address prefix encoded according to the Address Family field, whose length, in bits, was specified in the PreLen field, padded to a byte boundary.
前缀根据地址族字段编码的地址前缀，其长度（以位为单位）在PreLen字段中指定，并填充到字节边界。
Host Address FEC Element encoding:
主机地址FEC元素编码：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Addr (3) | Address Family | Host Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Host Addr |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Addr (3) | Address Family | Host Addr Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Host Addr |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the address family for the address prefix in the Prefix field.
地址族两个八位字节数量，包含[RFC1700]中地址族编号的值，该值为前缀字段中的地址前缀编码地址族。
Host Addr Len Length of the Host address in octets.
主机地址长度主机地址的长度，以八位字节为单位。
Host Addr An address encoded according to the Address Family field.
主机地址根据地址族字段编码的地址。
If in decoding a FEC TLV an LSR encounters a FEC Element with an Address Family it does not support, it should stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unsupported Address Family" Notification message to its LDP peer signaling an error.
如果在解码FEC TLV时，LSR遇到具有其不支持的地址族的FEC元素，则应停止解码FEC TLV，中止处理包含TLV的消息，并向其LDP对等方发送“不支持的地址族”通知消息，以指示错误。
If it encounters a FEC Element type it cannot decode, it should stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error.
如果遇到无法解码的FEC元素类型，则应停止解码FEC TLV，中止处理包含TLV的消息，并向其LDP对等方发送“未知FEC”通知消息，发出错误信号。
Label TLVs encode labels. Label TLVs are carried by the messages used to advertise, request, release and withdraw label mappings.
标签TLV编码标签。标签TLV由用于发布、请求、发布和撤销标签映射的消息携带。
There are several different kinds of Label TLVs which can appear in situations that require a Label TLV.
在需要标签TLV的情况下，可能会出现几种不同类型的标签TLV。
An LSR uses Generic Label TLVs to encode labels for use on links for which label values are independent of the underlying link technology. Examples of such links are PPP and Ethernet.
LSR使用通用标签TLV对标签进行编码，以便在标签值独立于基础链接技术的链接上使用。这种链路的例子有PPP和以太网。
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|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0| Generic Label (0x0200) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label This is a 20-bit label value as specified in [RFC3032] represented as a 20-bit number in a 4 octet field.
标签这是[RFC3032]中指定的20位标签值，表示为4个八位字节字段中的20位数字。
An LSR uses ATM Label TLVs to encode labels for use on ATM links.
LSR使用ATM标签TLV对标签进行编码，以便在ATM链路上使用。
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|0| ATM Label (0x0201) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| V | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0| ATM Label (0x0201) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Res| V | VPI | VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
Res此字段是保留的。传输时必须将其设置为零，接收时必须忽略。
V-bits Two-bit switching indicator. If V-bits is 00, both the VPI and VCI are significant. If V-bits is 01, only the VPI field is significant. If V-bit is 10, only the VCI is significant.
V位两位开关指示器。如果V位为00，则VPI和VCI都有效。如果V位为01，则只有VPI字段有效。如果V位为10，则只有VCI有效。
VPI Virtual Path Identifier. If VPI is less than 12-bits it should be right justified in this field and preceding bits should be set to 0.
虚拟路径标识符。如果VPI小于12位，则应在该字段中右对齐，前面的位应设置为0。
VCI Virtual Channel Identifier. If the VCI is less than 16- bits, it should be right justified in the field and the preceding bits must be set to 0. If Virtual Path switching is indicated in the V-bits field, then this field must be ignored by the receiver and set to 0 by the sender.
虚拟通道标识符。如果VCI小于16位，则应在字段中右对齐，并且前面的位必须设置为0。如果在V位字段中指示虚拟路径切换，则接收器必须忽略该字段，发送器必须将其设置为0。
An LSR uses Frame Relay Label TLVs to encode labels for use on Frame Relay links.
LSR使用帧中继标签TLV对用于帧中继链路的标签进行编码。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0| Frame Relay Label (0x0202)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
Res此字段是保留的。传输时必须将其设置为零，接收时必须忽略。
Len This field specifies the number of bits of the DLCI. The following values are supported:
Len此字段指定DLCI的位数。支持以下值：
0 = 10 bits DLCI 2 = 23 bits DLCI
0=10位DLCI 2=23位DLCI
Len values 1 and 3 are reserved.
保留Len值1和3。
DLCI The Data Link Connection Identifier. Refer to [RFC3034] for the label values and formats.
DLCI数据链路连接标识符。有关标签值和格式，请参阅[RFC3034]。
The Address List TLV appears in Address and Address Withdraw messages.
地址列表TLV显示在地址和地址撤消消息中。
Its encoding is:
其编码为：
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|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Addresses |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Addresses |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Family Two octet quantity containing a value from ADDRESS FAMILY NUMBERS in [RFC1700] that encodes the addresses contained in the Addresses field.
地址族两个八位字节数量，包含[RFC1700]中地址族编号的值，该值对地址字段中包含的地址进行编码。
Addresses A list of addresses from the specified Address Family. The encoding of the individual addresses depends on the Address Family.
地址指定地址系列中的地址列表。各个地址的编码取决于地址族。
The following address encodings are defined by this version of the protocol:
此版本的协议定义了以下地址编码：
Address Family Address Encoding
地址族地址编码
IPv4 4 octet full IPv4 address IPv6 16 octet full IPv6 address
IPv4 4八位组完整IPv4地址IPv6 16八位组完整IPv6地址
The Hop Count TLV appears as an optional field in messages that set up LSPs. It calculates the number of LSR hops along an LSP as the LSP is being setup.
跃点计数TLV在设置LSP的消息中显示为可选字段。在设置LSP时，它计算LSP上的LSR跳数。
Note that setup procedures for LSPs that traverse ATM and Frame Relay links require use of the Hop Count TLV (see [RFC3035] and [RFC3034]).
请注意，穿越ATM和帧中继链路的LSP的设置程序需要使用跳数TLV（请参阅[RFC3035]和[RFC3034]）。
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|0| Hop Count (0x0103) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC Value |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Hop Count (0x0103) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC Value |
+-+-+-+-+-+-+-+-+
HC Value 1 octet unsigned integer hop count value.
HC值1八位无符号整数跃点计数值。
During setup of an LSP an LSR R may receive a Label Mapping or Label Request message for the LSP that contains the Hop Count TLV. If it does, it should record the hop count value.
在LSP的设置期间，LSR可以接收包含跃点计数TLV的LSP的标签映射或标签请求消息。如果有，则应记录跃点计数值。
If LSR R then propagates the Label Mapping message for the LSP to an upstream peer or the Label Request message to a downstream peer to continue the LSP setup, it must must determine a hop count to include in the propagated message as follows:
如果LSR随后将LSP的标签映射消息传播到上游对等方或将标签请求消息传播到下游对等方以继续LSP设置，则必须确定要包含在传播消息中的跃点计数，如下所示：
- If the message is a Label Request message, R must increment the received hop count;
- 如果消息是标签请求消息，R必须增加接收到的跃点计数；
- If the message is a Label Mapping message, R determines the hop count as follows:
- 如果该消息是标签映射消息，则R确定跳数，如下所示：
o If R is a member of the edge set of an LSR domain whose LSRs do not perform 'TTL-decrement' and the upstream peer is within that domain, R must reset the hop count to 1 before propagating the message.
o 如果R是其LSR不执行“TTL递减”的LSR域的边缘集的成员，且上游对等方位于该域内，则R必须在传播消息之前将跃点计数重置为1。
o Otherwise, R must increment the received hop count.
o 否则，R必须增加接收到的跃点计数。
The first LSR in the LSP (ingress for a Label Request message, egress for a Label Mapping message) should set the hop count value to 1.
LSP中的第一个LSR（标签请求消息的入口，标签映射消息的出口）应将跃点计数值设置为1。
By convention a value of 0 indicates an unknown hop count. The result of incrementing an unknown hop count is itself an unknown hop count (0).
按照惯例，值0表示未知的跃点计数。递增未知跃点计数的结果本身就是未知跃点计数（0）。
Use of the unknown hop count value greatly reduces the signaling overhead when independent control is used. When a new LSP is established, each LSR starts with unknown hop count. Addition of a new LSR whose hop count is also unknown does not cause a hop count update to be propagated upstream since the hop count remains unknown. When the egress is finally added to the LSP, then the LSRs propagate hop count updates upstream via Label Mapping messages.
当使用独立控制时，使用未知跃点计数值大大减少了信令开销。当建立新的LSP时，每个LSR以未知的跃点计数开始。添加跳数未知的新LSR不会导致跳数更新向上游传播，因为跳数仍然未知。当出口最终添加到LSP时，LSR将通过标签映射消息向上游传播跳数更新。
Without use of the unknown hop count, each time a new LSR is added to the LSP a hop count update would need to be propagated upstream if the new LSR is closer to the egress than any of the other LSRs. These updates are useless overhead since they don't reflect the hop count to the egress.
在不使用未知跳数的情况下，每次向LSP添加新LSR时，如果新LSR比任何其他LSR更接近出口，则跳数更新将需要向上游传播。这些更新是无用的开销，因为它们不会将跃点计数反映到出口。
From the perspective of the ingress node, the fact that the hop count is unknown implies nothing about whether a packet sent on the LSP will actually make it to the egress. All it implies is that the hop count update from the egress has not yet reached the ingress.
从入口节点的角度来看，跳数未知的事实并不意味着在LSP上发送的分组是否将实际到达出口。这意味着出口的跃点计数更新尚未到达入口。
If an LSR receives a message containing a Hop Count TLV, it must check the hop count value to determine whether the hop count has exceeded its configured maximum allowable value. If so, it must behave as if the containing message has traversed a loop by sending a Notification message signaling Loop Detected in reply to the sender of the message.
如果LSR接收到包含跃点计数TLV的消息，则必须检查跃点计数值，以确定跃点计数是否已超过其配置的最大允许值。如果是这样，它必须通过向消息的发送者发送在应答中检测到的通知消息信令循环来表现为包含消息的消息已经穿过了一个循环。
If Loop Detection is configured, the LSR must follow the procedures specified in Section "Loop Detection".
如果配置了环路检测，则LSR必须遵循“环路检测”一节中规定的程序。
The Path Vector TLV is used with the Hop Count TLV in Label Request and Label Mapping messages to implement the optional LDP loop detection mechanism. See Section "Loop Detection". Its use in the
路径向量TLV与标签请求和标签映射消息中的跳数TLV一起使用，以实现可选的LDP循环检测机制。参见“回路检测”一节。它在计算机中的应用
Label Request message records the path of LSRs the request has traversed. Its use in the Label Mapping message records the path of LSRs a label advertisement has traversed to setup an LSP.
标签请求消息记录请求所经过的LSR路径。它在标签映射消息中的使用记录了标签广告为设置LSP而穿过的LSR路径。
Its encoding is:
其编码为：
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|0| Path Vector (0x0104) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id 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|0| Path Vector (0x0104) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSR Id n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
One or more LSR Ids A list of router-ids indicating the path of LSRs the message has traversed. Each LSR Id is the first four octets (router-id) of the LDP identifier for the corresponding LSR. This ensures it is unique within the LSR network.
一个或多个LSR ID路由器ID列表，指示消息所经过的LSR路径。每个LSR Id是对应LSR的LDP标识符的前四个八位字节（路由器Id）。这确保了它在LSR网络中是唯一的。
The Path Vector TLV is carried in Label Mapping and Label Request messages when loop detection is configured.
配置循环检测时，路径向量TLV在标签映射和标签请求消息中携带。
Section "Loop Detection" specifies situations when an LSR must include a Path Vector TLV in a Label Request message.
“循环检测”部分指定LSR必须在标签请求消息中包含路径向量TLV的情况。
An LSR that receives a Path Vector in a Label Request message must perform the procedures described in Section "Loop Detection".
在标签请求消息中接收路径向量的LSR必须执行“循环检测”部分中描述的过程。
If the LSR detects a loop, it must reject the Label Request message.
如果LSR检测到循环，它必须拒绝标签请求消息。
The LSR must:
LSR必须：
1. Transmit a Notification message to the sending LSR signaling "Loop Detected".
1. 向发送LSR信令“检测到环路”发送通知消息。
2. Not propagate the Label Request message further.
2. 不进一步传播标签请求消息。
Note that a Label Request message with Path Vector TLV is forwarded until:
请注意，带有路径向量TLV的标签请求消息将被转发，直到：
1. A loop is found,
1. 找到一个循环，
2. The LSP egress is reached,
2. 到达LSP出口，
3. The maximum Path Vector limit or maximum Hop Count limit is reached. This is treated as if a loop had been detected.
3. 已达到最大路径向量限制或最大跃点计数限制。这被视为检测到循环。
Section "Loop Detection" specifies the situations when an LSR must include a Path Vector TLV in a Label Mapping message.
“循环检测”部分指定了LSR必须在标签映射消息中包含路径向量TLV的情况。
An LSR that receives a Path Vector in a Label Mapping message must perform the procedures described in Section "Loop Detection".
在标签映射消息中接收路径向量的LSR必须执行“循环检测”部分中描述的步骤。
If the LSR detects a loop, it must reject the Label Mapping message in order to prevent a forwarding loop. The LSR must:
如果LSR检测到循环，它必须拒绝标签映射消息以防止转发循环。LSR必须：
1. Transmit a Label Release message carrying a Status TLV to the sending LSR to signal "Loop Detected".
1. 向发送LSR发送带有状态TLV的标签释放消息，以发出“检测到环路”信号。
2. Not propagate the message further.
2. 不要进一步传播消息。
3. Check whether the Label Mapping message is for an existing LSP. If so, the LSR must unsplice any upstream labels which are spliced to the downstream label for the FEC.
3. 检查标签映射消息是否用于现有LSP。如果是这样，LSR必须解开拼接到FEC下游标签的任何上游标签。
Note that a Label Mapping message with a Path Vector TLV is forwarded until:
请注意，带有路径向量TLV的标签映射消息将被转发，直到：
1. A loop is found,
1. 找到一个循环，
2. An LSP ingress is reached, or
2. 达到LSP入口，或
3. The maximum Path Vector or maximum Hop Count limit is reached. This is treated as if a loop had been detected.
3. 已达到最大路径向量或最大跃点计数限制。这被视为检测到循环。
Notification messages carry Status TLVs to specify events being signaled.
通知消息携带状态TLV，以指定发出信号的事件。
The encoding for the Status TLV is:
状态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| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| Status (0x0300) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit Should be 0 when the Status TLV is sent in a Notification message. Should be 1 when the Status TLV is sent in some other message.
在通知消息中发送状态TLV时，U位应为0。在其他消息中发送状态TLV时，应为1。
F bit Should be the same as the setting of the F-bit in the Status Code field.
F位应与状态代码字段中的F位设置相同。
Status Code 32-bit unsigned integer encoding the event being signaled. The structure of a Status Code is:
状态代码32位无符号整数，对发出信号的事件进行编码。状态代码的结构是：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|F| Status 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E|F| Status Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E bit Fatal error bit. If set (=1), this is a fatal error notification. If clear (=0), this is an advisory notification.
E位致命错误位。如果设置为（=1），则这是一个致命错误通知。如果清除（=0），这是一个建议通知。
F bit Forward bit. If set (=1), the notification should be forwarded to the LSR for the next-hop or previous-hop for the LSP, if any, associated with the event being signaled. If clear (=0), the notification should not be forwarded.
F位前向位。如果设置为（=1），则应将通知转发给LSR，用于与所发信号的事件相关联的LSP的下一跳或上一跳（如果有）。如果清除（=0），则不应转发通知。
Status Data 30-bit unsigned integer which specifies the status information.
状态数据30位无符号整数，指定状态信息。
This specification defines Status Codes (32-bit unsigned integers with the above encoding).
本规范定义状态代码（采用上述编码的32位无符号整数）。
A Status Code of 0 signals success.
状态代码为0表示成功。
Message ID If non-zero, 32-bit value that identifies the peer message to which the Status TLV refers. If zero, no specific peer message is being identified.
消息ID（如果为非零）32位值，用于标识状态TLV所指的对等消息。如果为零，则未识别特定的对等消息。
Message Type If non-zero, the type of the peer message to which the Status TLV refers. If zero, the Status TLV does not refer to any specific message type.
消息类型如果非零，则为状态TLV所指的对等消息的类型。如果为零，则状态TLV不引用任何特定的消息类型。
Note that use of the Status TLV is not limited to Notification messages. A message other than a Notification message may carry a Status TLV as an Optional Parameter. When a message other than a Notification carries a Status TLV the U-bit of the Status TLV should be set to 1 to indicate that the receiver should silently discard the TLV if unprepared to handle it.
注意，状态TLV的使用不限于通知消息。通知消息以外的消息可以携带状态TLV作为可选参数。当通知以外的消息包含状态TLV时，状态TLV的U位应设置为1，以指示如果未准备好处理TLV，则接收方应自动放弃该TLV。
All LDP messages have the following format:
所有LDP消息的格式如下：
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| Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mandatory Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Mandatory Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit Unknown message bit. Upon receipt of an unknown message, if U is clear (=0), a notification is returned to the message originator; if U is set (=1), the unknown message is silently ignored. The sections following that define messages specify a value for the U-bit.
U位未知消息位。收到未知消息后，如果U为清除（=0），则向消息发起人返回通知；如果U设置为（=1），未知消息将被静默忽略。下面定义消息的部分指定U位的值。
Message Type Identifies the type of message
消息类型标识消息的类型
Message Length Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters.
消息长度指定消息ID、强制参数和可选参数的累积长度（以八位字节为单位）。
Message ID 32-bit value used to identify this message. Used by the sending LSR to facilitate identifying notification messages that may apply to this message. An LSR sending a notification message in response to this message should include this Message Id in the Status TLV carried by the notification message; see Section "Notification Message".
消息ID 32位值，用于标识此消息。发送LSR用于帮助识别可能适用于此消息的通知消息。为响应此消息而发送通知消息的LSR应将此消息Id包含在通知消息携带的状态TLV中；请参阅“通知消息”一节。
Mandatory Parameters Variable length set of required message parameters. Some messages have no required parameters.
必需参数所需消息参数的可变长度集。有些消息没有必需的参数。
For messages that have required parameters, the required parameters MUST appear in the order specified by the individual message specifications in the sections that follow.
对于具有所需参数的消息，所需参数必须按照以下各节中各个消息规范指定的顺序显示。
Optional Parameters Variable length set of optional message parameters. Many messages have no optional parameters.
可选参数可选消息参数的可变长度集。许多消息没有可选参数。
For messages that have optional parameters, the optional parameters may appear in any order.
对于具有可选参数的消息，可选参数可以按任意顺序显示。
Note that there is no alignment requirement for the first octet of an LDP message.
注意，LDP消息的第一个八位组没有对齐要求。
The following message types are defined in this version of LDP:
此版本的LDP中定义了以下消息类型：
Message Name Section Title
消息名称部分标题
Notification "Notification Message" Hello "Hello Message" Initialization "Initialization Message" KeepAlive "KeepAlive Message"
通知“通知消息”Hello“Hello消息”初始化“初始化消息”KeepAlive“KeepAlive消息”
Address "Address Message" Address Withdraw "Address Withdraw Message" Label Mapping "Label Mapping Message" Label Request "Label Request Message" Label Abort Request "Label Abort Request Message" Label Withdraw "Label Withdraw Message" Label Release "Label Release Message"
地址“地址消息”地址“撤回”地址“撤回”消息“标签映射”标签映射消息“标签请求”标签请求消息“标签中止请求”标签中止请求消息“标签撤回”标签撤回消息“标签释放”标签释放消息
The sections that follow specify the encodings and procedures for these messages.
下面的部分指定了这些消息的编码和过程。
Some of the above messages are related to one another, for example the Label Mapping, Label Request, Label Withdraw, and Label Release messages.
上面的一些消息彼此相关，例如标签映射、标签请求、标签撤消和标签释放消息。
While it is possible to think about messages related in this way in terms of a message type that specifies a message class and a message subtype that specifies a particular kind of message within that class, this specification does not formalize the notion of a message subtype.
虽然可以根据指定消息类的消息类型和指定该类中特定消息类型的消息子类型来考虑以这种方式相关的消息，但本规范并未将消息子类型的概念形式化。
The specification assigns type values for related messages, such as the label messages, from of a contiguous block in the 16-bit message type number space.
该规范为相关消息（如标签消息）分配类型值，这些消息来自16位消息类型编号空间中的连续块的类型。
An LSR sends a Notification message to inform an LDP peer of a significant event. A Notification message signals a fatal error or provides advisory information such as the outcome of processing an LDP message or the state of the LDP session.
LSR发送通知消息，通知LDP对等方重大事件。通知消息表示致命错误，或提供诸如处理LDP消息的结果或LDP会话的状态等建议信息。
The encoding for the Notification Message is:
通知消息的编码为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
Status TLV Indicates the event being signaled. The encoding for the Status TLV is specified in Section "Status TLV".
状态TLV表示发出信号的事件。状态TLV的编码在“状态TLV”部分中指定。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The following Optional Parameters are generic and may appear in any Notification Message:
可选参数此可变长度字段包含0个或多个参数，每个参数编码为TLV。以下可选参数为通用参数，可能出现在任何通知消息中：
Optional Parameter Type Length Value
可选参数类型长度值
Extended Status 0x0301 4 See below Returned PDU 0x0302 var See below Returned Message 0x0303 var See below
扩展状态0x0301 4见下文返回的PDU 0x0302变量见下文返回的消息0x0303变量见下文
Other Optional Parameters, specific to the particular event being signaled by the Notification Messages may appear. These are described elsewhere.
可能会出现其他可选参数，特定于通知消息发出信号的特定事件。这些都在别处描述。
Extended Status The 4 octet value is an Extended Status Code that encodes additional information that supplements the status information contained in the Notification Status Code.
扩展状态4八位字节值是一个扩展状态代码，它编码补充通知状态代码中包含的状态信息的附加信息。
Returned PDU An LSR uses this parameter to return part of an LDP PDU to the LSR that sent it. The value of this TLV is the PDU header and as much PDU data following the header as appropriate for the condition being signaled by the Notification message.
返回的PDU LSR使用此参数将LDP PDU的一部分返回给发送它的LSR。此TLV的值是PDU头，以及根据通知消息发出信号的条件，在头之后添加尽可能多的PDU数据。
Returned Message An LSR uses this parameter to return part of an LDP message to the LSR that sent it. The value of this TLV is the message type and length fields and as much message data following the type and length fields as appropriate for the condition being signaled by the Notification message.
返回消息LSR使用此参数将LDP消息的一部分返回给发送它的LSR。此TLV的值是消息类型和长度字段，以及类型和长度字段后面的消息数据，这些数据与通知消息发出信号的条件相符。
If an LSR encounters a condition requiring it to notify its peer with advisory or error information it sends the peer a Notification message containing a Status TLV that encodes the information and optionally additional TLVs that provide more information about the condition.
如果LSR遇到要求其向其对等方通知咨询或错误信息的情况，则会向对等方发送一条通知消息，其中包含对信息进行编码的状态TLV，以及可选的提供有关该情况的更多信息的附加TLV。
If the condition is one that is a fatal error the Status Code carried in the notification will indicate that. In this case, after sending the Notification message the LSR should terminate the LDP session by
如果情况是致命错误，通知中携带的状态代码将指示该情况。在这种情况下，在发送通知消息后，LSR应通过以下方式终止LDP会话：
closing the session TCP connection and discard all state associated with the session, including all label-FEC bindings learned via the session.
关闭会话TCP连接并放弃与会话关联的所有状态，包括通过会话学习的所有标签FEC绑定。
When an LSR receives a Notification message that carries a Status Code that indicates a fatal error, it should terminate the LDP session immediately by closing the session TCP connection and discard all state associated with the session, including all label-FEC bindings learned via the session.
当LSR接收到带有指示致命错误的状态代码的通知消息时，它应通过关闭会话TCP连接立即终止LDP会话，并放弃与会话相关的所有状态，包括通过会话学习的所有标签FEC绑定。
It is useful for descriptive purpose to classify events signaled by Notification Messages into the following categories.
为了便于描述，将通知消息发出信号的事件分类为以下类别非常有用。
Malformed LDP PDUs or Messages that are part of the LDP Discovery mechanism are handled by silently discarding them.
格式错误的LDP PDU或作为LDP发现机制一部分的消息通过静默丢弃来处理。
An LDP PDU received on a TCP connection for an LDP session is malformed if:
在TCP连接上为LDP会话接收的LDP PDU格式不正确，如果：
- The LDP Identifier in the PDU header is unknown to the receiver, or it is known but is not the LDP Identifier associated by the receiver with the LDP peer for this LDP session. This is a fatal error signaled by the Bad LDP Identifier Status Code.
- 接收机不知道PDU报头中的LDP标识符，或者它是已知的，但不是接收机与该LDP会话的LDP对等方关联的LDP标识符。这是一个致命错误，由错误的LDP标识符状态码发出信号。
- The LDP protocol version is not supported by the receiver, or it is supported but is not the version negotiated for the session during session establishment. This is a fatal error signaled by the Bad Protocol Version Status Code.
- 接收方不支持LDP协议版本，或者支持LDP协议版本，但它不是会话建立期间为会话协商的版本。这是由错误的协议版本状态代码发出的致命错误。
- The PDU Length field is too small (< 14) or too large (> maximum PDU length). This is a fatal error signaled by the Bad PDU Length Status Code. Section "Initialization Message" describes how the maximum PDU length for a session is determined.
- PDU长度字段太小（<14）或太大（>最大PDU长度）。这是一个致命错误，由错误的PDU长度状态代码发出信号。“初始化消息”部分描述如何确定会话的最大PDU长度。
An LDP Message is malformed if:
LDP消息的格式不正确，如果：
- The Message Type is unknown.
- 消息类型未知。
If the Message Type is < 0x8000 (high order bit = 0) it is an error signaled by the Unknown Message Type Status Code.
如果消息类型<0x8000（高位=0），则是未知消息类型状态代码发出的错误信号。
If the Message Type is >= 0x8000 (high order bit = 1) it is silently discarded.
如果消息类型>=0x8000（高位=1），则会自动丢弃该消息。
- The Message Length is too large, that is, indicates that the message extends beyond the end of the containing LDP PDU. This is a fatal error signaled by the Bad Message Length Status Code.
- 消息长度太大，即表示消息超出包含LDP PDU的端部。这是一个由错误消息长度状态代码指示的致命错误。
- The message is missing one or more Mandatory Parameters. This is a non-fatal error signalled by the Missing Message Parameters Status Code.
- 消息缺少一个或多个必需参数。这是一个非致命错误，由丢失的消息参数状态代码发出信号。
Malformed TLVs contained in LDP messages that are part of the LDP Discovery mechanism are handled by silently discarding the containing message.
LDP消息中包含的格式不正确的TLV是LDP发现机制的一部分，通过静默丢弃包含该消息来处理。
A TLV contained in an LDP message received on a TCP connection of an LDP is malformed if:
在LDP的TCP连接上接收的LDP消息中包含的TLV格式不正确，如果：
- The TLV Length is too large, that is, indicates that the TLV extends beyond the end of the containing message. This is a fatal error signaled by the Bad TLV Length Status Code.
- TLV长度太大，即表示TLV超出了包含消息的末尾。这是一个致命错误，由错误的TLV长度状态代码发出信号。
- The TLV type is unknown.
- TLV类型未知。
If the TLV type is < 0x8000 (high order bit 0) it is an error signaled by the Unknown TLV Status Code.
如果TLV类型<0x8000（高位0），则是未知TLV状态代码发出的错误信号。
If the TLV type is >= 0x8000 (high order bit 1) the TLV is silently dropped. Section "Unknown TLV in Known Message Type" elaborates on this behavior.
如果TLV类型>=0x8000（高位1），则TLV将自动丢弃。“已知消息类型中的未知TLV”部分详细说明了此行为。
- The TLV Value is malformed. This occurs when the receiver handles the TLV but cannot decode the TLV Value. This is interpreted as indicative of a bug in either the sending or receiving LSR. It is a fatal error signaled by the Malformed TLV Value Status Code.
- TLV值的格式不正确。当接收器处理TLV但无法解码TLV值时，会发生这种情况。这被解释为表明发送或接收LSR中存在错误。这是一个致命错误，由格式错误的TLV值状态代码发出信号。
This is a fatal error signaled by the KeepAlive Timer Expired Status Code.
这是一个致命错误，由KeepAlive计时器过期状态代码发出信号。
This is a fatal event signaled by the Shutdown Status Code. The Notification Message may optionally include an Extended Status TLV to provide a reason for the Shutdown. The sending LSR terminates the session immediately after sending the Notification.
这是一个由停机状态代码发出信号的致命事件。通知消息可选择性地包括扩展状态TLV，以提供关机原因。发送通知后，发送LSR立即终止会话。
The session initialization negotiation (see Section "Session Initialization") may fail if the session parameters received in the Initialization Message are unacceptable. This is a fatal error. The specific Status Code depends on the parameter deemed unacceptable, and is defined in Sections "Initialization Message".
如果初始化消息中接收到的会话参数不可接受，会话初始化协商（请参阅“会话初始化”一节）可能会失败。这是一个致命的错误。具体状态代码取决于被视为不可接受的参数，并在“初始化消息”部分中定义。
Messages other than the Initialization message may result in events that must be signaled to LDP peers via Notification Messages. These events and the Status Codes used in the Notification Messages to signal them are described in the sections that describe these messages.
初始化消息以外的消息可能导致必须通过通知消息向LDP对等方发送信号的事件。这些事件以及通知消息中用于向其发送信号的状态代码在描述这些消息的章节中进行了描述。
An LDP implementation may be capable of detecting problem conditions specific to its implementation. When such a condition prevents an implementation from interacting correctly with a peer, the implementation should, when capable of doing so, use the Internal Error Status Code to signal the peer. This is a fatal error.
LDP实现可以能够检测特定于其实现的问题条件。当这种情况阻止实现与对等方正确交互时，实现应在能够这样做时，使用内部错误状态代码向对等方发出信号。这是一个致命的错误。
These are events that fall into none of the categories above. There are no miscellaneous events defined in this version of the protocol.
这些事件不属于上述类别。此版本的协议中未定义其他事件。
LDP Hello Messages are exchanged as part of the LDP Discovery Mechanism; see Section "LDP Discovery".
LDP Hello消息作为LDP发现机制的一部分进行交换；请参阅“LDP发现”一节。
The encoding for the Hello Message is:
Hello消息的编码为：
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| Hello (0x0100) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Hello Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Hello (0x0100) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Hello Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
Common Hello Parameters TLV Specifies parameters common to all Hello messages. The encoding for the Common Hello Parameters TLV is:
公共Hello参数TLV指定所有Hello消息的公共参数。通用Hello参数TLV的编码为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Hello Parms(0x0400)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |T|R| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Hello Parms(0x0400)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Time |T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hold Time, Hello hold time in seconds. An LSR maintains a record of Hellos received from potential peers (see Section "Hello Message Procedures"). Hello Hold Time specifies the time the sending LSR will maintain its record of Hellos from the receiving LSR without receipt of another Hello.
等待时间，您好等待时间以秒为单位。LSR维护从潜在对等方接收的Hello的记录（参见“Hello消息过程”一节）。Hello Hold Time指定发送LSR在不接收另一个Hello的情况下保持其来自接收LSR的Hello记录的时间。
A pair of LSRs negotiates the hold times they use for Hellos from each other. Each proposes a hold time. The hold time used is the minimum of the hold times proposed in their Hellos.
一对LSR相互协商他们为他使用的等待时间。每个人都提出了一个等待时间。所使用的等待时间是其Hello中建议的等待时间的最小值。
A value of 0 means use the default, which is 15 seconds for Link Hellos and 45 seconds for Targeted Hellos. A value of 0xffff means infinite.
值为0表示使用默认值，链接hello为15秒，目标hello为45秒。0xffff的值表示无限。
T, Targeted Hello A value of 1 specifies that this Hello is a Targeted Hello. A value of 0 specifies that this Hello is a Link Hello.
T、 目标Hello值为1指定此Hello为目标Hello。值0指定此Hello是链接Hello。
R, Request Send Targeted Hellos A value of 1 requests the receiver to send periodic Targeted Hellos to the source of this Hello. A value of 0 makes no request.
R、 Request Send Targeted Hello值为1时，请求接收方定期向此Hello的源发送目标Hello。值为0时不发出请求。
An LSR initiating Extended Discovery sets R to 1. If R is 1, the receiving LSR checks whether it has been configured to send Targeted Hellos to the Hello source in response to Hellos with this request. If not, it ignores the request. If so, it initiates periodic transmission of Targeted Hellos to the Hello source.
启动扩展发现的LSR将R设置为1。如果R为1，则接收LSR检查其是否已配置为向Hello源发送目标Hello，以响应Hello请求。如果不是，它将忽略该请求。如果是这样，它将定期向Hello源发送目标Hello。
Reserved This field is reserved. It must be set to zero on transmission and ignored on receipt.
保留此字段为保留字段。必须在传输时将其设置为零，在接收时将其忽略。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters defined by this version of the protocol are
可选参数此可变长度字段包含0个或多个参数，每个参数编码为TLV。此版本协议定义的可选参数为
Optional Parameter Type Length Value
可选参数类型长度值
IPv4 Transport Address 0x0401 4 See below Configuration 0x0402 4 See below Sequence Number IPv6 Transport Address 0x0403 16 See below
IPv4传输地址0x0401 4见下文配置0x0402 4见下文序列号IPv6传输地址0x0403 16见下文
IPv4 Transport Address Specifies the IPv4 address to be used for the sending LSR when opening the LDP session TCP connection. If this optional TLV is not present the IPv4 source address for the UDP packet carrying the Hello should be used.
IPv4传输地址指定在打开LDP会话TCP连接时用于发送LSR的IPv4地址。如果此可选TLV不存在，则应使用承载Hello的UDP数据包的IPv4源地址。
Configuration Sequence Number Specifies a 4 octet unsigned configuration sequence number that identifies the configuration state of the sending LSR. Used by the receiving LSR to detect configuration changes on the sending LSR.
配置序列号指定4个八位字节的无符号配置序列号，用于标识发送LSR的配置状态。接收LSR用于检测发送LSR上的配置更改。
IPv6 Transport Address Specifies the IPv6 address to be used for the sending LSR when opening the LDP session TCP connection. If this optional TLV is not present the IPv6 source address for the UDP packet carrying the Hello should be used.
IPv6传输地址指定在打开LDP会话TCP连接时用于发送LSR的IPv6地址。如果此可选TLV不存在，则应使用承载Hello的UDP数据包的IPv6源地址。
An LSR receiving Hellos from another LSR maintains a Hello adjacency corresponding to the Hellos. The LSR maintains a hold timer with the Hello adjacency which it restarts whenever it receives a Hello that matches the Hello adjacency. If the hold timer for a Hello adjacency expires the LSR discards the Hello adjacency: see sections "Maintaining Hello Adjacencies" and "Maintaining LDP Sessions".
从另一个LSR接收Hello的LSR保持与Hello对应的Hello邻接。LSR维护一个带有Hello邻接的保持计时器，每当收到与Hello邻接相匹配的Hello时，它就会重新启动该计时器。如果Hello邻接的保持计时器过期，LSR将丢弃Hello邻接：请参阅“维护Hello邻接”和“维护LDP会话”部分。
We recommend that the interval between Hello transmissions be at most one third of the Hello hold time.
我们建议Hello传输之间的间隔最多为Hello保持时间的三分之一。
An LSR processes a received LDP Hello as follows:
LSR按如下方式处理接收到的LDP Hello：
1. The LSR checks whether the Hello is acceptable. The criteria for determining whether a Hello is acceptable are implementation dependent (see below for example criteria).
1. LSR检查Hello是否可接受。确定Hello是否可接受的标准取决于实现（参见下面的标准示例）。
2. If the Hello is not acceptable, the LSR ignores it.
2. 如果Hello不可接受，LSR将忽略它。
3. If the Hello is acceptable, the LSR checks whether it has a Hello adjacency for the Hello source. If so, it restarts the hold timer for the Hello adjacency. If not it creates a Hello adjacency for the Hello source and starts its hold timer.
3. 如果Hello是可接受的，LSR将检查它是否具有Hello源的Hello邻接。如果是这样，它将重新启动Hello邻接的保持计时器。如果没有，它将为Hello源创建Hello邻接并启动其保持计时器。
4. If the Hello carries any optional TLVs the LSR processes them (see below).
4. 如果Hello携带任何可选TLV，LSR将处理它们（见下文）。
5. Finally, if the LSR has no LDP session for the label space specified by the LDP identifier in the PDU header for the Hello, it follows the procedures of Section "LDP Session Establishment".
5. 最后，如果LSR对于由用于Hello的PDU报头中的LDP标识符指定的标签空间没有LDP会话，则遵循“LDP会话建立”部分的过程。
The following are examples of acceptability criteria for Link and Targeted Hellos:
以下是链接和目标Hello的可接受性标准示例：
A Link Hello is acceptable if the interface on which it was received has been configured for label switching.
如果接收链接的接口已配置为标签切换，则可以接受链接Hello。
A Targeted Hello from source address A is acceptable if either:
如果满足以下任一条件，则可接受来自源地址A的目标Hello：
- The LSR has been configured to accept Targeted Hellos, or
- LSR已配置为接受目标Hello，或
- The LSR has been configured to send Targeted Hellos to A.
- LSR已配置为将目标Hello发送到。
The following describes how an LSR processes Hello optional TLVs:
以下描述了LSR如何处理可选TLV：
Transport Address The LSR associates the specified transport address with the Hello adjacency.
传输地址LSR将指定的传输地址与Hello邻接相关联。
Configuration Sequence Number The Configuration Sequence Number optional parameter is used by the sending LSR to signal configuration changes to the receiving LSR. When a receiving LSR playing the active role in LDP session establishment detects a change in the sending LSR configuration, it may clear the session setup backoff delay, if any, associated with the sending LSR (see Section "Session Initialization").
配置序列号发送LSR使用配置序列号可选参数向接收LSR发送配置更改信号。当在LDP会话建立中扮演主动角色的接收LSR检测到发送LSR配置中的变化时，它可以清除与发送LSR相关联的会话设置退避延迟（如果有的话）（参见“会话初始化”一节）。
A sending LSR using this optional parameter is responsible for maintaining the configuration sequence number it transmits in Hello messages. Whenever there is a configuration change on the sending LSR, it increments the configuration sequence number.
使用此可选参数的发送LSR负责维护其在Hello消息中传输的配置序列号。只要发送LSR上有配置更改，它就会增加配置序列号。
The LDP Initialization Message is exchanged as part of the LDP session establishment procedure; see Section "LDP Session Establishment".
LDP初始化消息作为LDP会话建立过程的一部分进行交换；见“自民党会议建立”一节。
The encoding for the Initialization Message is:
初始化消息的编码为：
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| Initialization (0x0200) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Session Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Initialization (0x0200) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Session Parameters TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
Common Session Parameters TLV Specifies values proposed by the sending LSR for parameters that must be negotiated for every LDP session.
公共会话参数TLV指定发送LSR为每个LDP会话必须协商的参数建议的值。
The encoding for the Common Session Parameters TLV is:
公共会话参数TLV的编码为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Common Sess Parms (0x0500)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | KeepAlive Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Reserved | PVLim | Max PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
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|0| Common Sess Parms (0x0500)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Version | KeepAlive Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Reserved | PVLim | Max PDU Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver LDP Identifier |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++
Protocol Version Two octet unsigned integer containing the version number of the protocol. This version of the specification specifies LDP protocol version 1.
协议版本2包含协议版本号的八位无符号整数。本规范版本规定了LDP协议版本1。
KeepAlive Time Two octet unsigned non zero integer that indicates the number of seconds that the sending LSR proposes for the value of the KeepAlive Time. The receiving LSR MUST calculate the value of the KeepAlive Timer by using the smaller of its proposed KeepAlive Time and the KeepAlive Time received in the PDU. The value chosen for KeepAlive Time indicates the maximum number of seconds that may elapse between the receipt of successive PDUs from the LDP peer on the session TCP connection. The KeepAlive Timer is reset each time a PDU arrives.
保留时间两个八位无符号非零整数，指示发送LSR为保留时间值建议的秒数。接收LSR必须使用其建议的保持时间和PDU中接收的保持时间中的较小者来计算保持计时器的值。为KeepAlive Time选择的值表示在会话TCP连接上从LDP对等方接收连续PDU之间可能经过的最大秒数。每次PDU到达时，都会重置KeepAlive计时器。
A, Label Advertisement Discipline Indicates the type of Label advertisement. A value of 0 means Downstream Unsolicited advertisement; a value of 1 means Downstream On Demand.
A、 标签广告规程指示标签广告的类型。值为0表示下游未经请求的广告；值为1表示按需下游。
If one LSR proposes Downstream Unsolicited and the other proposes Downstream on Demand, the rules for resolving this difference is:
如果一个LSR提出下游未经请求，而另一个提出下游按需，则解决此差异的规则为：
- If the session is for a label-controlled ATM link or a label-controlled Frame Relay link, then Downstream on Demand must be used.
- 如果会话用于标签控制的ATM链路或标签控制的帧中继链路，则必须使用下行按需。
- Otherwise, Downstream Unsolicited must be used.
- 否则，必须使用未经请求的下游。
If the label advertisement discipline determined in this way is unacceptable to an LSR, it must send a Session Rejected/Parameters Advertisement Mode Notification message in
如果以这种方式确定的标签广告规程对于LSR来说是不可接受的，则它必须在中发送会话拒绝/参数广告模式通知消息
response to the Initialization message and not establish the session.
响应初始化消息，但不建立会话。
D, Loop Detection Indicates whether loop detection based on path vectors is enabled. A value of 0 means loop detection is disabled; a value of 1 means that loop detection is enabled.
D、 循环检测指示是否启用基于路径向量的循环检测。值为0表示禁用循环检测；值为1表示启用循环检测。
PVLim, Path Vector Limit The configured maximum path vector length. Must be 0 if loop detection is disabled (D = 0). If the loop detection procedures would require the LSR to send a path vector that exceeds this limit, the LSR will behave as if a loop had been detected for the FEC in question.
PVLim，路径向量限制配置的最大路径向量长度。如果禁用循环检测（D=0），则必须为0。如果环路检测程序要求LSR发送超过此限制的路径向量，则LSR的行为将如同已检测到有关FEC的环路一样。
When Loop Detection is enabled in a portion of a network, it is recommended that all LSRs in that portion of the network be configured with the same path vector limit. Although knowledge of a peer's path vector limit will not change an LSR's behavior, it does enable the LSR to alert an operator to a possible misconfiguration.
当在一部分网络中启用环路检测时，建议该部分网络中的所有LSR配置相同的路径向量限制。虽然知道对等点的路径向量限制不会改变LSR的行为，但它确实可以使LSR向操作员发出可能的错误配置警报。
Reserved This field is reserved. It must be set to zero on transmission and ignored on receipt.
保留此字段为保留字段。必须在传输时将其设置为零，在接收时将其忽略。
Max PDU Length Two octet unsigned integer that proposes the maximum allowable length for LDP PDUs for the session. A value of 255 or less specifies the default maximum length of 4096 octets.
最大PDU长度两个八位无符号整数，用于建议会话LDP PDU的最大允许长度。255或更小的值指定默认最大长度4096个八位字节。
The receiving LSR MUST calculate the maximum PDU length for the session by using the smaller of its and its peer's proposals for Max PDU Length. The default maximum PDU length applies before session initialization completes.
接收LSR必须使用其和对等方的建议中较小的最大PDU长度来计算会话的最大PDU长度。在会话初始化完成之前应用默认的最大PDU长度。
If the maximum PDU length determined this way is unacceptable to an LSR, it must send a Session Rejected/Parameters Max PDU Length Notification message in response to the Initialization message and not establish the session.
如果LSR不能接受以这种方式确定的最大PDU长度，则它必须发送会话拒绝/参数最大PDU长度通知消息以响应初始化消息，而不是建立会话。
Receiver LDP Identifier Identifies the receiver's label space. This LDP Identifier, together with the sender's LDP Identifier in the PDU header enables the receiver to match the Initialization message with one of its Hello adjacencies; see Section "Hello Message Procedures".
接收机LDP标识符标识接收机的标签空间。该LDP标识符以及PDU报头中发送方的LDP标识符使得接收方能够将初始化消息与其Hello邻接之一相匹配；请参阅“Hello消息过程”一节。
If there is no matching Hello adjacency, the LSR must send a Session Rejected/No Hello Notification message in response to the Initialization message and not establish the session.
如果没有匹配的Hello邻接，LSR必须发送会话拒绝/无Hello通知消息以响应初始化消息，并且不建立会话。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
可选参数此可变长度字段包含0个或多个参数，每个参数编码为TLV。可选参数包括：
Optional Parameter Type Length Value
可选参数类型长度值
ATM Session Parameters 0x0501 var See below Frame Relay Session 0x0502 var See below Parameters
ATM会话参数0x0501 var见下文帧中继会话0x0502 var见下文参数
ATM Session Parameters Used when an LDP session manages label exchange for an ATM link to specify ATM-specific session parameters.
LDP会话管理ATM链路的标签交换以指定特定于ATM的会话参数时使用的ATM会话参数。
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|0| ATM Sess Parms (0x0501) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Label Range Component 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|0| ATM Sess Parms (0x0501) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM Label Range Component N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M, ATM Merge Capabilities Specifies the merge capabilities of an ATM switch. The following values are supported in this version of the specification:
M、 ATM合并功能指定ATM交换机的合并功能。此版本的规范支持以下值：
Value Meaning
价值意义
0 Merge not supported 1 VP Merge supported 2 VC Merge supported 3 VP & VC Merge supported
不支持0合并1支持VP合并2支持VC合并3支持VP和VC合并
If the merge capabilities of the LSRs differ, then:
如果LSR的合并功能不同，则：
- Non-merge and VC-merge LSRs may freely interoperate.
- 非合并和VC合并LSR可以自由互操作。
- The interoperability of VP-merge-capable switches with non-VP-merge-capable switches is a subject for future study. When the LSRs differ on the use of VP-merge, the session is established, but VP merge is not used.
- 支持VP合并的交换机与不支持VP合并的交换机的互操作性是未来研究的主题。当LSR在VP merge的使用上存在差异时，将建立会话，但不使用VP merge。
Note that if VP merge is used, it is the responsibility of the ingress node to ensure that the chosen VCI is unique within the LSR domain (see [ATM-VP]).
请注意，如果使用VP合并，则入口节点有责任确保所选VCI在LSR域内是唯一的（请参阅[ATM-VP]）。
N, Number of label range components Specifies the number of ATM Label Range Components included in the TLV.
N、 标签范围组件的数量指定TLV中包含的ATM标签范围组件的数量。
D, VC Directionality A value of 0 specifies bidirectional VC capability, meaning the LSR can (within a given VPI) support the use of a given VCI as a label for both link directions independently. A value of 1 specifies unidirectional VC capability, meaning (within a given VPI) a given VCI may appear in a label mapping for one direction on the link only. When either or both of the peers specifies unidirectional VC capability, both LSRs use unidirectional VC label assignment for the link as follows. The LSRs compare their LDP Identifiers as unsigned integers. The LSR with the larger LDP Identifier may assign only odd-numbered VCIs in the VPI/VCI range as labels. The system with the smaller LDP Identifier may assign only even-numbered VCIs in the VPI/VCI range as labels.
D、 VC方向性值0指定双向VC能力，这意味着LSR可以（在给定VPI内）支持将给定VCI用作两个链路方向的标签。值1指定单向VC能力，这意味着（在给定的VPI内）给定的VCI可能仅出现在链接上一个方向的标签映射中。当其中一个或两个对等点指定单向VC功能时，两个LSR对链路使用单向VC标签分配，如下所示。LSR将其LDP标识符作为无符号整数进行比较。具有较大LDP标识符的LSR可仅将VPI/VCI范围内的奇数编号VCI分配为标签。具有较小LDP标识符的系统可仅将VPI/VCI范围内的偶数编号VCI分配为标签。
Reserved This field is reserved. It must be set to zero on transmission and ignored on receipt.
保留此字段为保留字段。必须在传输时将其设置为零，在接收时将其忽略。
One or more ATM Label Range Components A list of ATM Label Range Components which together specify the Label range supported by the transmitting LSR.
一个或多个ATM标签范围组件ATM标签范围组件列表，这些组件共同指定传输LSR支持的标签范围。
A receiving LSR MUST calculate the intersection between the received range and its own supported label range. The intersection is the range in which the LSR may allocate and accept labels. LSRs MUST NOT establish a session with neighbors for which the intersection of ranges is NULL. In this case, the LSR must send a Session Rejected/Parameters Label Range Notification message in response to the Initialization message and not establish the session.
接收LSR必须计算接收范围与其自身支持的标签范围之间的交集。交叉点是LSR可以分配和接受标签的范围。LSR不得与范围交集为空的邻居建立会话。在这种情况下，LSR必须发送会话拒绝/参数标签范围通知消息以响应初始化消息，而不是建立会话。
The encoding for an ATM Label Range Component is:
ATM标签范围组件的编码为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
Res此字段是保留的。传输时必须将其设置为零，接收时必须忽略。
Minimum VPI (12 bits) This 12 bit field specifies the lower bound of a block of Virtual Path Identifiers that is supported on the originating switch. If the VPI is less than 12-bits it should be right justified in this field and preceding bits should be set to 0.
最小VPI（12位）此12位字段指定发起交换机支持的虚拟路径标识符块的下限。如果VPI小于12位，则应在该字段中右对齐，前面的位应设置为0。
Minimum VCI (16 bits) This 16 bit field specifies the lower bound of a block of Virtual Connection Identifiers that is supported on the originating switch. If the VCI is less than 16-bits it should be right justified in this field and preceding bits should be set to 0.
最小VCI（16位）此16位字段指定发起交换机上支持的虚拟连接标识符块的下限。如果VCI小于16位，则应在此字段中右对齐，且前面的位应设置为0。
Maximum VPI (12 bits) This 12 bit field specifies the upper bound of a block of Virtual Path Identifiers that is supported on the originating switch. If the VPI is less than 12-bits it should be right justified in this field and preceding bits should be set to 0.
最大VPI（12位）此12位字段指定发起交换机上支持的虚拟路径标识符块的上限。如果VPI小于12位，则应在该字段中右对齐，前面的位应设置为0。
Maximum VCI (16 bits) This 16 bit field specifies the upper bound of a block of Virtual Connection Identifiers that is supported on the originating switch. If the VCI is less than 16-bits it should be right justified in this field and preceding bits should be set to 0.
最大VCI（16位）此16位字段指定发起交换机上支持的虚拟连接标识符块的上限。如果VCI小于16位，则应在此字段中右对齐，且前面的位应设置为0。
When peer LSRs are connected indirectly by means of an ATM VP, the sending LSR should set the Minimum and Maximum VPI fields to 0, and the receiving LSR must ignore the Minimum and Maximum VPI fields.
当对等LSR通过ATM VP间接连接时，发送LSR应将最小和最大VPI字段设置为0，接收LSR必须忽略最小和最大VPI字段。
See [ATM-VP] for specification of the fields for ATM Label Range Components to be used with VP merge LSRs.
请参阅[ATM-VP]，了解与VP合并LSR一起使用的ATM标签范围组件的字段规范。
Frame Relay Session Parameters Used when an LDP session manages label exchange for a Frame Relay link to specify Frame Relay-specific session parameters.
LDP会话管理帧中继链路的标签交换以指定特定于帧中继的会话参数时使用的帧中继会话参数。
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|0| FR Sess Parms (0x0502) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay Label Range Component 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|0| FR Sess Parms (0x0502) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M | N |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay Label Range Component 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Relay Label Range Component N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M, Frame Relay Merge Capabilities Specifies the merge capabilities of a Frame Relay switch. The following values are supported in this version of the specification:
M、 帧中继合并功能指定帧中继交换机的合并功能。此版本的规范支持以下值：
Value Meaning
价值意义
0 Merge not supported 1 Merge supported
不支持0合并不支持1合并
Non-merge and merge Frame Relay LSRs may freely interoperate.
非合并和合并帧中继LSR可以自由互操作。
N, Number of label range components Specifies the number of Frame Relay Label Range Components included in the TLV.
N、 标签范围组件数指定TLV中包含的帧中继标签范围组件数。
D, VC Directionality A value of 0 specifies bidirectional VC capability, meaning the LSR can support the use of a given DLCI as a label for both link directions independently. A value of 1 specifies unidirectional VC capability, meaning a given DLCI may appear in a label mapping for one direction on the link only. When either or both of the peers specifies unidirectional VC capability, both LSRs use unidirectional VC label assignment for the link as follows. The LSRs compare their LDP Identifiers as unsigned integers. The LSR with the larger LDP
D、 VC方向性值0指定双向VC功能，这意味着LSR可以支持将给定的DLCI用作两个链路方向的标签。值1指定单向VC功能，这意味着给定的DLCI可能仅出现在链接上一个方向的标签映射中。当其中一个或两个对等点指定单向VC功能时，两个LSR对链路使用单向VC标签分配，如下所示。LSR将其LDP标识符作为无符号整数进行比较。LDP较大的LSR
Identifier may assign only odd-numbered DLCIs in the range as labels. The system with the smaller LDP Identifier may assign only even-numbered DLCIs in the range as labels.
标识符只能将范围内奇数编号的DLCI指定为标签。具有较小LDP标识符的系统可仅将范围内的偶数编号DLCI分配为标签。
Reserved This field is reserved. It must be set to zero on transmission and ignored on receipt.
保留此字段为保留字段。必须在传输时将其设置为零，在接收时将其忽略。
One or more Frame Relay Label Range Components A list of Frame Relay Label Range Components which together specify the Label range supported by the transmitting LSR.
一个或多个帧中继标签范围组件帧中继标签范围组件列表，这些组件一起指定传输LSR支持的标签范围。
A receiving LSR MUST calculate the intersection between the received range and its own supported label range. The intersection is the range in which the LSR may allocate and accept labels. LSRs MUST NOT establish a session with neighbors for which the intersection of ranges is NULL. In this case, the LSR must send a Session Rejected/Parameters Label Range Notification message in response to the Initialization message and not establish the session.
接收LSR必须计算接收范围与其自身支持的标签范围之间的交集。交叉点是LSR可以分配和接受标签的范围。LSR不得与范围交集为空的邻居建立会话。在这种情况下，LSR必须发送会话拒绝/参数标签范围通知消息以响应初始化消息，而不是建立会话。
The encoding for a Frame Relay Label Range Component is:
帧中继标签范围组件的编码为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved This field is reserved. It must be set to zero on transmission and ignored on receipt.
保留此字段为保留字段。必须在传输时将其设置为零，在接收时将其忽略。
Len This field specifies the number of bits of the DLCI. The following values are supported:
Len此字段指定DLCI的位数。支持以下值：
Len DLCI bits
Len-DLCI位
0 10 2 23
0 10 2 23
Len values 1 and 3 are reserved.
保留Len值1和3。
Minimum DLCI This 23-bit field specifies the lower bound of a block of Data Link Connection Identifiers (DLCIs) that is supported on the originating switch. The DLCI should be right justified in this field and unused bits should be set to 0.
最小DLCI此23位字段指定原始交换机上支持的数据链路连接标识符（DLCI）块的下限。DLCI应在此字段中右对齐，未使用的位应设置为0。
Maximum DLCI This 23-bit field specifies the upper bound of a block of Data Link Connection Identifiers (DLCIs) that is supported on the originating switch. The DLCI should be right justified in this field and unused bits should be set to 0.
最大DLCI此23位字段指定原始交换机上支持的数据链路连接标识符（DLCI）块的上限。DLCI应在此字段中右对齐，未使用的位应设置为0。
Note that there is no Generic Session Parameters TLV for sessions which advertise Generic Labels.
请注意，对于播发通用标签的会话，没有通用会话参数TLV。
See Section "LDP Session Establishment" and particularly Section "Session Initialization" for general procedures for handling the Initialization Message.
有关处理初始化消息的一般程序，请参阅“LDP会话建立”一节，特别是“会话初始化”一节。
An LSR sends KeepAlive Messages as part of a mechanism that monitors the integrity of the LDP session transport connection.
LSR发送KeepAlive消息，作为监控LDP会话传输连接完整性的机制的一部分。
The encoding for the KeepAlive Message is:
KeepAlive消息的编码为：
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| KeepAlive (0x0201) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| KeepAlive (0x0201) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
Optional Parameters No optional parameters are defined for the KeepAlive message.
可选参数没有为KeepAlive消息定义可选参数。
The KeepAlive Timer mechanism described in Section "Maintaining LDP Sessions" resets a session KeepAlive timer every time an LDP PDU is
“维护LDP会话”一节中描述的KeepAlive Timer机制在每次启动LDP PDU时重置会话KeepAlive Timer
received on the session TCP connection. The KeepAlive Message is provided to allow reset of the KeepAlive Timer in circumstances where an LSR has no other information to communicate to an LDP peer.
在会话TCP连接上收到。提供KeepAlive消息以允许在LSR没有其他信息与LDP对等方通信的情况下重置KeepAlive定时器。
An LSR must arrange that its peer receive an LDP Message from it at least every KeepAlive Time period. Any LDP protocol message will do but, in circumstances where no other LDP protocol messages have been sent within the period, a KeepAlive message must be sent.
LSR必须安排其对等方至少在每个保持时间段从其接收LDP消息。任何LDP协议消息都可以，但如果在此期间没有发送其他LDP协议消息，则必须发送KeepAlive消息。
An LSR sends the Address Message to an LDP peer to advertise its interface addresses.
LSR向LDP对等方发送地址消息，以公布其接口地址。
The encoding for the Address Message is:
地址信息的编码为：
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| Address (0x0300) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address List TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Address (0x0300) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address List TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
Address List TLV The list of interface addresses being advertised by the sending LSR. The encoding for the Address List TLV is specified in Section "Address List TLV".
地址列表TLV发送LSR播发的接口地址列表。地址列表TLV的编码在“地址列表TLV”部分中指定。
Optional Parameters No optional parameters are defined for the Address message.
可选参数没有为地址消息定义可选参数。
An LSR that receives an Address Message message uses the addresses it learns to maintain a database for mapping between peer LDP Identifiers and next hop addresses; see Section "LDP Identifiers and Next Hop Addresses".
接收地址消息的LSR使用其学习到的地址来维护用于对等LDP标识符和下一跳地址之间映射的数据库；请参阅“LDP标识符和下一跳地址”一节。
When a new LDP session is initialized and before sending Label Mapping or Label Request messages an LSR should advertise its interface addresses with one or more Address messages.
初始化新LDP会话时，在发送标签映射或标签请求消息之前，LSR应使用一个或多个地址消息公布其接口地址。
Whenever an LSR "activates" a new interface address, it should advertise the new address with an Address message.
每当LSR“激活”一个新的接口地址时，它都应该用地址消息通知新地址。
Whenever an LSR "de-activates" a previously advertised address, it should withdraw the address with an Address Withdraw message; see Section "Address Withdraw Message".
每当LSR“停用”先前公布的地址时，它应使用地址撤销消息撤销该地址；请参阅“地址撤回消息”一节。
If an LSR does not support the Address Family specified in the Address List TLV, it should send an "Unsupported Address Family" Notification to its LDP signalling an error and abort processing the message.
如果LSR不支持地址列表TLV中指定的地址系列，则应向其LDP发送“不支持的地址系列”通知，以发出错误信号并中止处理消息。
An LSR sends the Address Withdraw Message to an LDP peer to withdraw previously advertised interface addresses.
LSR向LDP对等方发送地址撤回消息，以撤回先前公布的接口地址。
The encoding for the Address Withdraw Message is:
地址撤消消息的编码为：
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| Address Withdraw (0x0301) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address List TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Address Withdraw (0x0301) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address List TLV |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
Address list TLV The list of interface addresses being withdrawn by the sending LSR. The encoding for the Address list TLV is specified in Section "Address List TLV".
地址列表TLV发送LSR撤回的接口地址列表。地址列表TLV的编码在“地址列表TLV”部分中指定。
Optional Parameters No optional parameters are defined for the Address Withdraw message.
可选参数没有为地址撤消消息定义可选参数。
See Section "Address Message Procedures"
请参阅“地址信息程序”一节
An LSR sends a Label Mapping message to an LDP peer to advertise FEC-label bindings to the peer.
LSR向LDP对等方发送标签映射消息，以向该对等方公布FEC标签绑定。
The encoding for the Label Mapping Message is:
标签映射消息的编码为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
FEC TLV Specifies the FEC component of the FEC-Label mapping being advertised. See Section "FEC TLV" for encoding.
FEC TLV指定正在播发的FEC标签映射的FEC组件。有关编码，请参见“FEC TLV”一节。
Label TLV Specifies the Label component of the FEC-Label mapping. See Section "Label TLV" for encoding.
标签TLV指定FEC标签映射的标签组件。有关编码，请参见“标签TLV”一节。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
可选参数此可变长度字段包含0个或多个参数，每个参数编码为TLV。可选参数包括：
Optional Parameter Length Value
可选参数长度值
Label Request 4 See below Message ID TLV Hop Count TLV 1 See below Path Vector TLV variable See below
标签请求4见下文消息ID TLV跃点计数TLV 1见下文路径向量TLV变量见下文
The encodings for the Hop Count, and Path Vector TLVs can be found in Section "TLV Encodings for Commonly Used Parameters".
跳数和路径向量TLV的编码可在“常用参数的TLV编码”一节中找到。
Label Request Message ID If this Label Mapping message is a response to a Label Request message it must include the Request Message Id optional parameter. The value of this optional parameter is the Message Id of the corresponding Label Request Message.
标签请求消息ID如果此标签映射消息是对标签请求消息的响应，则必须包含请求消息ID可选参数。此可选参数的值是相应标签请求消息的消息Id。
Hop Count Specifies the running total of the number of LSR hops along the LSP being setup by the Label Message. Section "Hop Count Procedures" describes how to handle this TLV.
跃点计数指定标签消息设置的LSP上LSR跃点的运行总数。“跃点计数过程”部分描述了如何处理此TLV。
Path Vector Specifies the LSRs along the LSP being setup by the Label Message. Section "Path Vector Procedures" describes how to handle this TLV.
路径向量指定标签消息设置的LSP沿线的LSR。“路径向量过程”一节描述了如何处理此TLV。
The Mapping message is used by an LSR to distribute a label mapping for a FEC to an LDP peer. If an LSR distributes a mapping for a FEC to multiple LDP peers, it is a local matter whether it maps a single label to the FEC, and distributes that mapping to all its peers, or whether it uses a different mapping for each of its peers.
映射消息由LSR用于将FEC的标签映射分发到LDP对等方。如果LSR将FEC的映射分发到多个LDP对等点，那么它是否将单个标签映射到FEC并将该映射分发到其所有对等点，或者它是否为其每个对等点使用不同的映射，都是本地问题。
An LSR is responsible for the consistency of the label mappings it has distributed, and that its peers have these mappings.
LSR负责其已分发的标签映射的一致性，并且其对等方具有这些映射。
An LSR receiving a Label Mapping message from a downstream LSR for a Prefix or Host Address FEC Element should not use the label for forwarding unless its routing table contains an entry that exactly matches the FEC Element.
从下游LSR接收前缀或主机地址FEC元素的标签映射消息的LSR不应使用标签进行转发，除非其路由表包含与FEC元素完全匹配的条目。
See Appendix A "LDP Label Distribution Procedures" for more details.
详见附录A“LDP标签分发程序”。
If an LSR is configured for independent control, a mapping message is transmitted by the LSR upon any of the following conditions:
如果LSR配置为独立控制，则LSR将在以下任一条件下发送映射消息：
1. The LSR recognizes a new FEC via the forwarding table, and the label advertisement mode is Downstream Unsolicited advertisement.
1. LSR通过转发表识别新的FEC，标签广告模式为下游非请求广告。
2. The LSR receives a Request message from an upstream peer for a FEC present in the LSR's forwarding table.
2. LSR从上游对等方接收针对LSR的转发表中存在的FEC的请求消息。
3. The next hop for a FEC changes to another LDP peer, and loop detection is configured.
3. FEC的下一跳变为另一个LDP对等，并配置环路检测。
4. The attributes of a mapping change.
4. 映射的属性将更改。
5. The receipt of a mapping from the downstream next hop AND a) no upstream mapping has been created OR b) loop detection is configured OR c) the attributes of the mapping have changed.
5. 接收到来自下游下一跳的映射，a）未创建上游映射，或b）配置了循环检测，或c）映射的属性已更改。
If an LSR is doing ordered control, a Mapping message is transmitted by downstream LSRs upon any of the following conditions:
如果LSR正在进行有序控制，则下游LSR将在以下任一条件下发送映射消息：
1. The LSR recognizes a new FEC via the forwarding table, and is the egress for that FEC.
1. LSR通过转发表识别新的FEC，并且是该FEC的出口。
2. The LSR receives a Request message from an upstream peer for a FEC present in the LSR's forwarding table, and the LSR is the egress for that FEC OR has a downstream mapping for that FEC.
2. LSR从上游对等方接收针对LSR的转发表中存在的FEC的请求消息，并且LSR是该FEC的出口或具有该FEC的下游映射。
3. The next hop for a FEC changes to another LDP peer, and loop detection is configured.
3. FEC的下一跳变为另一个LDP对等，并配置环路检测。
4. The attributes of a mapping change.
4. 映射的属性将更改。
5. The receipt of a mapping from the downstream next hop AND a) no upstream mapping has been created OR b) loop detection is configured OR c) the attributes of the mapping have changed.
5. 接收到来自下游下一跳的映射，a）未创建上游映射，或b）配置了循环检测，或c）映射的属性已更改。
In general, the upstream LSR is responsible for requesting label mappings when operating in Downstream on Demand mode. However, unless some rules are followed, it is possible for neighboring LSRs with different advertisement modes to get into a livelock situation where everything is functioning properly, but no labels are distributed. For example, consider two LSRs Ru and Rd where Ru is the upstream LSR and Rd is the downstream LSR for a particular FEC. In this example, Ru is using Downstream Unsolicited advertisement mode and Rd is using Downstream on Demand mode. In this case, Rd may assume that Ru will request a label mapping when it wants one and Ru may assume that Rd will advertise a label if it wants Ru to use one. If Rd and Ru operate as suggested, no labels will be distributed from Rd to Ru.
通常，上游LSR负责在下游按需模式下运行时请求标签映射。但是，除非遵循某些规则，否则具有不同广告模式的相邻LSR可能会进入活锁状态，即所有内容都正常运行，但没有分发标签。例如，考虑两个LSR RU和RD，其中RU是上游LSR，RD是特定FEC的下游LSR。在此示例中，Ru使用下游未经请求的广告模式，Rd使用下游随需应变模式。在这种情况下，Rd可能假设Ru在需要标签映射时会请求标签映射，而Ru可能假设Rd在需要Ru使用标签时会发布标签。如果Rd和Ru按照建议运行，则不会将标签从Rd分发到Ru。
This livelock situation can be avoided if the following rule is observed: an LSR operating in Downstream on Demand mode should not be expected to send unsolicited mapping advertisements. Therefore, if the downstream LSR is operating in Downstream on Demand mode, the upstream LSR is responsible for requesting label mappings as needed.
如果遵守以下规则，则可以避免这种活锁情况：在下游按需模式下运行的LSR不应发送未经请求的映射广告。因此，如果下游LSR在下游按需模式下运行，则上游LSR负责根据需要请求标签映射。
In general, the downstream LSR is responsible for advertising a label mapping when it wants an upstream LSR to use the label. An upstream LSR may issue a mapping request if it so desires.
通常，当下游LSR希望上游LSR使用标签时，下游LSR负责公布标签映射。如果上游LSR愿意，它可以发出映射请求。
The combination of Downstream Unsolicited mode and conservative label retention can lead to a situation where an LSR releases the label for a FEC that it later needs. For example, if LSR Rd advertises to LSR Ru the label for a FEC for which it is not Ru's next hop, Ru will release the label. If Ru's next hop for the FEC later changes to Rd, it needs the previously released label.
下游非请求模式和保守标签保留的组合可能导致LSR为其稍后需要的FEC释放标签的情况。例如，如果LSR Rd向LSR Ru播发FEC的标签，而该标签不是Ru的下一跳，Ru将释放该标签。如果Ru的FEC下一个跃点后来更改为Rd，则需要先前发布的标签。
To deal with this situation either Ru can explicitly request the label when it needs it, or Rd can periodically readvertise it to Ru. In many situations Ru will know when it needs the label from Rd. For example, when its next hop for the FEC changes to Rd. However, there could be situations when Ru does not. For example, Rd may be attempting to establish an LSP with non-standard properties. Forcing Ru to explicitly request the label in this situation would require it to maintain state about a potential LSP with non-standard properties.
为了处理这种情况，Ru可以在需要标签时显式地请求它，或者Rd可以定期地将它读给Ru。在许多情况下，Ru将知道何时需要来自Rd的标签。例如，当FEC的下一个跃点更改为Rd时。但是，可能存在Ru不需要的情况。例如，Rd可能试图建立具有非标准属性的LSP。在这种情况下，强制Ru显式请求标签将要求它维护关于具有非标准属性的潜在LSP的状态。
In situations where Ru knows it needs the label, it is responsible for explicitly requesting the label by means of a Label Request message. In situations where Ru may not know that it needs the label, Rd is responsible for periodically readvertising the label to Ru.
在Ru知道需要标签的情况下，它负责通过标签请求消息显式请求标签。在Ru可能不知道需要标签的情况下，Rd负责定期向Ru读取标签。
For this version of LDP, the only situation where Ru knows it needs a label for a FEC from Rd is when Rd is its next hop for the FEC, Ru does not have a label from Rd, and the LSP for the FEC is one that can be established with TLVs defined in this document.
对于这个版本的LDP，Ru知道它需要来自Rd的FEC标签的唯一情况是当Rd是FEC的下一个跃点时，Ru没有来自Rd的标签，并且FEC的LSP可以通过本文档中定义的TLV建立。
An LSR sends the Label Request Message to an LDP peer to request a binding (mapping) for a FEC.
LSR向LDP对等方发送标签请求消息，以请求FEC的绑定（映射）。
The encoding for the Label Request Message is:
标签请求消息的编码为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
FEC TLV The FEC for which a label is being requested. See Section "FEC TLV" for encoding.
FEC TLV正在请求标签的FEC。有关编码，请参见“FEC TLV”一节。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
可选参数此可变长度字段包含0个或多个参数，每个参数编码为TLV。可选参数包括：
Optional Parameter Length Value
可选参数长度值
Hop Count TLV 1 See below Path Vector TLV variable See below
跳数TLV 1见下文路径向量TLV变量见下文
The encodings for the Hop Count, and Path Vector TLVs can be found in Section "TLV Encodings for Commonly Used Parameters".
跳数和路径向量TLV的编码可在“常用参数的TLV编码”一节中找到。
Hop Count Specifies the running total of the number of LSR hops along the LSP being setup by the Label Request Message. Section "Hop Count Procedures" describes how to handle this TLV.
跃点计数指定标签请求消息设置的LSP上LSR跃点的运行总数。“跃点计数过程”部分描述了如何处理此TLV。
Path Vector Specifies the LSRs along the LSR being setup by the Label Request Message. Section "Path Vector Procedures" describes how to handle this TLV.
路径向量指定标签请求消息设置的LSR沿线的LSR。“路径向量过程”一节描述了如何处理此TLV。
The Request message is used by an upstream LSR to explicitly request that the downstream LSR assign and advertise a label for a FEC.
请求消息由上游LSR用于显式请求下游LSR为FEC分配和公布标签。
An LSR may transmit a Request message under any of the following conditions:
LSR可在以下任何条件下发送请求消息：
1. The LSR recognizes a new FEC via the forwarding table, and the next hop is an LDP peer, and the LSR doesn't already have a mapping from the next hop for the given FEC.
1. LSR通过转发表识别一个新的FEC，下一跳是一个LDP对等点，并且LSR还没有从下一跳到给定FEC的映射。
2. The next hop to the FEC changes, and the LSR doesn't already have a mapping from that next hop for the given FEC.
2. FEC的下一个跃点发生变化，并且LSR还没有给定FEC的下一个跃点的映射。
Note that if the LSR already has a pending Label Request message for the new next hop it should not issue an additional Label Request in response to the next hop change.
注意，如果LSR已经为新的下一个跃点发出了挂起的标签请求消息，那么它不应该发出额外的标签请求来响应下一个跃点的更改。
3. The LSR receives a Label Request for a FEC from an upstream LDP peer, the FEC next hop is an LDP peer, and the LSR doesn't already have a mapping from the next hop.
3. LSR从上游LDP对等方接收FEC的标签请求，FEC下一跳是LDP对等方，并且LSR还没有来自下一跳的映射。
Note that since a non-merge LSR must setup a separate LSP for each upstream peer requesting a label, it must send a separate Label Request for each such peer. A consequence of this is that a non-merge LSR may have multiple Label Request messages for a given FEC outstanding at the same time.
请注意，由于非合并LSR必须为每个请求标签的上游对等方设置单独的LSP，因此它必须为每个这样的对等方发送单独的标签请求。其结果是，对于给定的FEC，非合并LSR可能同时具有多个未完成的标签请求消息。
The receiving LSR should respond to a Label Request message with a Label Mapping for the requested label or with a Notification message indicating why it cannot satisfy the request.
接收LSR应使用所请求标签的标签映射或指示其无法满足请求原因的通知消息来响应标签请求消息。
When the FEC for which a label is requested is a Prefix FEC Element or a Host Address FEC Element, the receiving LSR uses its routing table to determine its response. Unless its routing table includes an entry that exactly matches the requested Prefix or Host Address, the LSR must respond with a No Route Notification message.
当请求标签的FEC是前缀FEC元素或主机地址FEC元素时，接收LSR使用其路由表来确定其响应。除非其路由表包含与请求的前缀或主机地址完全匹配的条目，否则LSR必须以无路由通知消息进行响应。
The message ID of the Label Request message serves as an identifier for the Label Request transaction. When the receiving LSR responds with a Label Mapping message, the mapping message must include a Label Request/Returned Message ID TLV optional parameter which includes the message ID of the Label Request message. Note that since LSRs use Label Request message IDs as transaction identifiers an LSR should not reuse the message ID of a Label Request message until the corresponding transaction completes.
标签请求消息的消息ID用作标签请求事务的标识符。当接收LSR响应标签映射消息时，映射消息必须包括标签请求/返回消息ID TLV可选参数，该参数包括标签请求消息的消息ID。请注意，由于LSR使用标签请求消息ID作为事务标识符，因此在相应的事务完成之前，LSR不应重用标签请求消息的消息ID。
This version of the protocol defines the following Status Codes for the Notification message that signals a request cannot be satisfied:
此版本的协议为表示无法满足请求的通知消息定义了以下状态代码：
No Route The FEC for which a label was requested includes a FEC Element for which the LSR does not have a route.
无路由请求标签的FEC包含LSR没有路由的FEC元素。
No Label Resources The LSR cannot provide a label because of resource limitations. When resources become available the LSR must notify the requesting LSR by sending a Notification message with the Label Resources Available Status Code.
无标签资源由于资源限制，LSR无法提供标签。当资源可用时，LSR必须通过发送带有标签资源可用状态代码的通知消息来通知请求LSR。
An LSR that receives a No Label Resources response to a Label Request message must not issue further Label Request messages until it receives a Notification message with the Label Resources Available Status code.
接收到对标签请求消息的无标签资源响应的LSR在收到带有标签资源可用状态代码的通知消息之前，不得发出进一步的标签请求消息。
Loop Detected The LSR has detected a looping Label Request message.
检测到循环LSR检测到循环标签请求消息。
See Appendix A "LDP Label Distribution Procedures" for more details.
详见附录A“LDP标签分发程序”。
The Label Abort Request message may be used to abort an outstanding Label Request message.
标签中止请求消息可用于中止未完成的标签请求消息。
The encoding for the Label Abort Request Message is:
标签中止请求消息的编码为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Abort Req (0x0404) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Abort Req (0x0404) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Request Message ID TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
FEC TLV Identifies the FEC for which the Label Request is being aborted.
FEC TLV标识正在中止标签请求的FEC。
Label Request Message ID TLV Specifies the message ID of the Label Request message to be aborted.
标签请求消息ID TLV指定要中止的标签请求消息的消息ID。
Optional Parameters No optional parameters are defined for the Label Abort Req message.
可选参数没有为Label Abort Req消息定义可选参数。
An LSR Ru may send a Label Abort Request message to abort an outstanding Label Request message for FEC sent to LSR Rd in the following circumstances:
在以下情况下，LSR Ru可发送标签中止请求消息，以中止发送给LSR Rd的FEC的未完成标签请求消息：
1. Ru's next hop for FEC has changed from LSR Rd to LSR X; or
1. Ru的FEC下一跳已从LSR Rd更改为LSR X；或
2. Ru is a non-merge, non-ingress LSR and has received a Label Abort Request for FEC from an upstream peer Y.
2. Ru是非合并、非进入LSR，并且已从上游对等方Y接收到FEC的标签中止请求。
3. Ru is a merge, non-ingress LSR and has received a Label Abort Request for FEC from an upstream peer Y and Y is the only (last) upstream LSR requesting a label for FEC.
3. Ru是一个合并、非进入LSR，并且已经从上游对等方Y接收到FEC标签中止请求，Y是唯一（最后）请求FEC标签的上游LSR。
There may be other situations where an LSR may choose to abort an outstanding Label Request message in order to reclaim resource associated with the pending LSP. However, specification of general strategies for using the abort mechanism is beyond the scope of LDP.
在其他情况下，LSR可能会选择中止未完成的标签请求消息，以便回收与挂起的LSP相关联的资源。然而，使用中止机制的一般策略的规范超出了LDP的范围。
When an LSR receives a Label Abort Request message, if it has not previously responded to the Label Request being aborted with a Label Mapping message or some other Notification message, it must acknowledge the abort by responding with a Label Request Aborted Notification message. The Notification must include a Label Request Message ID TLV that carries the message ID of the aborted Label Request message.
当LSR收到标签中止请求消息时，如果它以前没有使用标签映射消息或其他通知消息响应要中止的标签请求，则它必须通过使用标签请求中止通知消息响应来确认中止。通知必须包括标签请求消息ID TLV，该TLV携带中止的标签请求消息的消息ID。
If an LSR receives a Label Abort Request Message after it has responded to the Label Request in question with a Label Mapping message or a Notification message, it ignores the abort request.
如果LSR在使用标签映射消息或通知消息响应相关标签请求后收到标签中止请求消息，则会忽略中止请求。
If an LSR receives a Label Mapping message in response to a Label Request message after it has sent a Label Abort Request message to abort the Label Request, the label in the Label Mapping message is valid. The LSR may choose to use the label or to release it with a Label Release message.
如果LSR在发送标签中止请求消息以中止标签请求后，收到标签映射消息以响应标签请求消息，则标签映射消息中的标签有效。LSR可选择使用标签或通过标签发布消息发布标签。
An LSR aborting a Label Request message may not reuse the Message ID for the Label Request message until it receives one of the following from its peer:
中止标签请求消息的LSR在从其对等方接收到以下信息之一之前，不得重新使用标签请求消息的消息ID：
- A Label Request Aborted Notification message acknowledging the abort;
- 确认中止的标签请求中止通知消息；
- A Label Mapping message in response to the Label Request message being aborted;
- 响应于被中止的标签请求消息的标签映射消息；
- A Notification message in response to the Label Request message being aborted (e.g., Loop Detected, No Label Resources, etc.).
- 响应被中止的标签请求消息的通知消息（例如，检测到循环、没有标签资源等）。
To protect itself against tardy peers or faulty peer implementations an LSR may choose to time out receipt of the above. The time out period should be relatively long (several minutes). If the time out period elapses with no reply from the peer the LSR may reuse the Message Id of the Label Request message; if it does so, it should also discard any record of the outstanding Label Request and Label Abort messages.
为了保护自己不受延迟对等点或错误对等点实现的影响，LSR可以选择超时接收上述信息。超时时间应相对较长（几分钟）。如果超时时间已经过去，并且对等方没有回复，则LSR可以重用标签请求消息的消息Id；如果这样做，它还应该丢弃未完成的标签请求和标签中止消息的任何记录。
Note that the response to a Label Abort Request message is never "ordered". That is, the response does not depend on the downstream state of the LSP setup being aborted. An LSR receiving a Label Abort Request message must process it immediately, regardless of the downstream state of the LSP, responding with a Label Request Aborted Notification or ignoring it, as appropriate.
请注意，对标签中止请求消息的响应从不“有序”。也就是说，响应不取决于正在中止的LSP设置的下游状态。接收标签中止请求消息的LSR必须立即处理该消息，而不管LSP的下游状态如何，以标签请求中止通知响应或忽略该通知（视情况而定）。
An LSR sends a Label Withdraw Message to an LDP peer to signal the peer that the peer may not continue to use specific FEC-label mappings the LSR had previously advertised. This breaks the mapping between the FECs and the labels.
LSR向LDP对等方发送标签撤回消息，以向该对等方发出信号，表明该对等方可能不会继续使用LSR先前公布的特定FEC标签映射。这会破坏FEC和标签之间的映射。
The encoding for the Label Withdraw Message is:
标签撤消消息的编码为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Withdraw (0x0402) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Withdraw (0x0402) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
FEC TLV Identifies the FEC for which the FEC-label mapping is being withdrawn.
FEC TLV标识要为其撤消FEC标签映射的FEC。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
可选参数此可变长度字段包含0个或多个参数，每个参数编码为TLV。可选参数包括：
Optional Parameter Length Value
可选参数长度值
Label TLV variable See below
标签TLV变量见下文
The encoding for Label TLVs are found in Section "Label TLVs".
标签TLV的编码见“标签TLV”部分。
Label If present, specifies the label being withdrawn (see procedures below).
标签（如果存在）指定要撤销的标签（参见以下步骤）。
An LSR transmits a Label Withdraw message under the following conditions:
LSR在以下条件下发送标签撤回消息：
1. The LSR no longer recognizes a previously known FEC for which it has advertised a label.
1. LSR不再识别先前已知的FEC，因为它已经为该FEC发布了标签。
2. The LSR has decided unilaterally (e.g., via configuration) to no longer label switch a FEC (or FECs) with the label mapping being withdrawn.
2. LSR已单方面（例如，通过配置）决定不再在标签映射被撤销的情况下标记FEC（或FEC）。
The FEC TLV specifies the FEC for which labels are to be withdrawn. If no Label TLV follows the FEC, all labels associated with the FEC are to be withdrawn; otherwise only the label specified in the optional Label TLV is to be withdrawn.
FEC TLV指定要撤销标签的FEC。如果FEC后没有标签TLV，则应撤销与FEC相关的所有标签；否则，只能撤销可选标签TLV中指定的标签。
The FEC TLV may contain the Wildcard FEC Element; if so, it may contain no other FEC Elements. In this case, if the Label Withdraw message contains an optional Label TLV, then the label is to be withdrawn from all FECs to which it is bound. If there is not an optional Label TLV in the Label Withdraw message, then the sending LSR is withdrawing all label mappings previously advertised to the receiving LSR.
FEC TLV可以包含通配符FEC元素；如果是，它可能不包含其他FEC元素。在这种情况下，如果标签撤销消息包含可选标签TLV，则标签将从其绑定到的所有FEC中撤销。如果标签撤销消息中没有可选的标签TLV，则发送LSR将撤销先前通告给接收LSR的所有标签映射。
An LSR that receives a Label Withdraw message must respond with a Label Release message.
接收标签撤销消息的LSR必须以标签释放消息响应。
See Appendix A "LDP Label Distribution Procedures" for more details.
详见附录A“LDP标签分发程序”。
An LSR sends a Label Release message to an LDP peer to signal the peer that the LSR no longer needs specific FEC-label mappings previously requested of and/or advertised by the peer.
LSR向LDP对等方发送标签释放消息，以向该对等方发出信号，表示LSR不再需要先前由该对等方请求和/或通告的特定FEC标签映射。
The encoding for the Label Release Message is:
标签发布消息的编码为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID 32-bit value used to identify this message.
消息ID 32位值，用于标识此消息。
FEC TLV Identifies the FEC for which the FEC-label mapping is being released.
FEC TLV标识正在为其发布FEC标签映射的FEC。
Optional Parameters This variable length field contains 0 or more parameters, each encoded as a TLV. The optional parameters are:
可选参数此可变长度字段包含0个或多个参数，每个参数编码为TLV。可选参数包括：
Optional Parameter Length Value
可选参数长度值
Label TLV variable See below
标签TLV变量见下文
The encodings for Label TLVs are found in Section "Label TLVs".
标签TLV的编码见“标签TLV”部分。
Label If present, the label being released (see procedures below).
标签（如有），释放标签（见以下步骤）。
An LSR transmits a Label Release message to a peer when it is no longer needs a label previously received from or requested of that peer.
当不再需要先前从对等方接收或请求的标签时，LSR向对等方发送标签释放消息。
An LSR must transmit a Label Release message under any of the following conditions:
LSR必须在以下任何条件下发送标签释放消息：
1. The LSR which sent the label mapping is no longer the next hop for the mapped FEC, and the LSR is configured for conservative operation.
1. 发送标签映射的LSR不再是映射FEC的下一个跃点，并且LSR配置为保守操作。
2. The LSR receives a label mapping from an LSR which is not the next hop for the FEC, and the LSR is configured for conservative operation.
2. LSR从不是FEC的下一跳的LSR接收标签映射，并且LSR被配置为保守操作。
3. The LSR receives a Label Withdraw message.
3. LSR接收标签撤销消息。
Note that if an LSR is configured for "liberal mode", a release message will never be transmitted in the case of conditions (1) and (2) as specified above. In this case, the upstream LSR keeps each unused label, so that it can immediately be used later if the downstream peer becomes the next hop for the FEC.
注意，如果LSR配置为“自由模式”，则在上述条件（1）和（2）的情况下，将永远不会发送释放消息。在这种情况下，上游LSR保留每个未使用的标签，以便在下游对等方成为FEC的下一跳时可以立即使用它。
The FEC TLV specifies the FEC for which labels are to be released. If no Label TLV follows the FEC, all labels associated with the FEC are to be released; otherwise only the label specified in the optional Label TLV is to be released.
FEC TLV指定要发布标签的FEC。如果FEC之后没有标签TLV，则与FEC相关的所有标签将被释放；否则，仅释放可选标签TLV中指定的标签。
The FEC TLV may contain the Wildcard FEC Element; if so, it may contain no other FEC Elements. In this case, if the Label Release message contains an optional Label TLV, then the label is to be released for all FECs to which it is bound. If there is not an
FEC TLV可以包含通配符FEC元素；如果是，它可能不包含其他FEC元素。在这种情况下，如果标签释放消息包含可选的标签TLV，则将为其绑定到的所有FEC释放标签。如果没有
optional Label TLV in the Label Release message, then the sending LSR is releasing all label mappings previously learned from the receiving LSR.
标签释放消息中的可选标签TLV，则发送LSR将释放先前从接收LSR学习到的所有标签映射。
See Appendix A "LDP Label Distribution Procedures" for more details.
详见附录A“LDP标签分发程序”。
Support for LDP extensibility includes the rules for the U and F bits that specify how an LSR should handle unknown TLVs and messages.
对LDP可扩展性的支持包括U和F位规则，这些规则指定LSR应如何处理未知TLV和消息。
This section specifies TLVs and messages for vendor-private and experimental use.
本节规定了供供应商私人和实验使用的TLV和消息。
Vendor-private TLVs and messages are used to convey vendor-private information between LSRs.
供应商专用TLV和消息用于在LSR之间传递供应商专用信息。
The Type range 0x3E00 through 0x3EFF is reserved for vendor-private TLVs.
类型范围0x3E00到0x3EFF为供应商专用TLV保留。
The encoding for a vendor-private TLV is:
供应商专用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 (0x3E00-0x3EFF) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 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| Type (0x3E00-0x3EFF) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Data.... |
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit Unknown TLV bit. Upon receipt of an unknown TLV, if U is clear (=0), a notification must be returned to the message originator and the entire message must be ignored; if U is set (=1), the unknown TLV is silently ignored and the rest of the message is processed as if the unknown TLV did not exist.
U位未知TLV位。收到未知TLV后，如果U为清除（=0），则必须向消息发起人返回通知，并且必须忽略整个消息；如果U设置为（=1），未知TLV将被静默忽略，消息的其余部分将被处理，就像未知TLV不存在一样。
The determination as to whether a vendor-private message is understood is based on the Type and the mandatory Vendor ID field.
是否理解供应商私有消息的确定基于类型和强制供应商ID字段。
F bit Forward unknown TLV bit. This bit only applies when the U bit is set and the LDP message containing the unknown TLV is is to be forwarded. If F is clear (=0), the unknown TLV is not forwarded with the containing message; if F is set (=1), the unknown TLV is forwarded with the containing message.
F位转发未知TLV位。此位仅在设置了U位且包含未知TLV的LDP消息要转发时适用。如果F为清除（=0），则未知TLV不会与包含的消息一起转发；如果F设置为（=1），则未知TLV将与包含的消息一起转发。
Type Type value in the range 0x3E00 through 0x3EFF. Together, the Type and Vendor Id field specify how the Data field is to be interpreted.
键入范围为0x3E00到0x3EFF的类型值。类型和供应商Id字段一起指定如何解释数据字段。
Length Specifies the cumulative length in octets of the Vendor ID and Data fields.
长度指定供应商ID和数据字段的累积长度（以八位字节为单位）。
Vendor Id 802 Vendor ID as assigned by the IEEE.
供应商Id 802由IEEE分配的供应商Id。
Data The remaining octets after the Vendor ID in the Value field are optional vendor-dependent data.
数据值字段中供应商ID之后的剩余八位字节是可选的供应商相关数据。
The Message Type range 0x3E00 through 0x3EFF is reserved for vendor-private Messages.
消息类型范围0x3E00到0x3EFF为供应商专用消息保留。
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| Msg Type (0x3E00-0x3EFF) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
| Remaining Mandatory Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Msg Type (0x3E00-0x3EFF) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
| Remaining Mandatory Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Optional Parameters |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U bit Unknown message bit. Upon receipt of an unknown message, if U is clear (=0), a notification is returned to the message originator; if U is set (=1), the unknown message is silently ignored.
U位未知消息位。收到未知消息后，如果U为清除（=0），则向消息发起人返回通知；如果U设置为（=1），未知消息将被静默忽略。
The determination as to whether a vendor-private message is understood is based on the Msg Type and the Vendor ID parameter.
是否理解供应商私有消息的确定基于消息类型和供应商ID参数。
Msg Type Message type value in the range 0x3E00 through 0x3EFF. Together, the Msg Type and the Vendor ID specify how the message is to be interpreted.
消息类型消息类型值，范围为0x3E00到0x3EFF。消息类型和供应商ID一起指定如何解释消息。
Message Length Specifies the cumulative length in octets of the Message ID, Vendor ID, Remaining Mandatory Parameters and Optional Parameters.
Message Length指定消息ID、供应商ID、剩余强制参数和可选参数的累积长度（以八位字节为单位）。
Message ID 32-bit integer used to identify this message. Used by the sending LSR to facilitate identifying notification messages that may apply to this message. An LSR sending a notification message in response to this message will include this Message Id in the notification message; see Section "Notification Message".
消息ID 32位整数，用于标识此消息。发送LSR用于帮助识别可能适用于此消息的通知消息。响应于该消息而发送通知消息的LSR将在通知消息中包括该消息Id；请参阅“通知消息”一节。
Vendor ID 802 Vendor ID as assigned by the IEEE.
供应商ID 802由IEEE分配的供应商ID。
Remaining Mandatory Parameters Variable length set of remaining required message parameters.
剩余必需参数剩余必需消息参数的可变长度集。
Optional Parameters Variable length set of optional message parameters.
可选参数可选消息参数的可变长度集。
LDP support for experimentation is similar to support for vendor-private extensions with the following differences:
LDP对实验的支持类似于对供应商私有扩展的支持，但有以下区别：
- The Type range 0x3F00 through 0x3FFF is reserved for experimental TLVs.
- 类型范围0x3F00到0x3FFF为实验TLV保留。
- The Message Type range 0x3F00 through 0x3FFF is reserved for experimental messages.
- 消息类型范围0x3F00到0x3FFF为实验消息保留。
- The encodings for experimental TLVs and messages are similar to the vendor-private encodings with the following difference.
- 实验TLV和消息的编码与供应商私有编码类似，但有以下区别。
Experimental TLVs and messages use an Experiment ID field in place of a Vendor ID field. The Experiment ID field is used with the Type or Message Type field to specify the interpretation of the experimental TLV or Message.
实验TLV和消息使用实验ID字段代替供应商ID字段。“实验ID”字段与“类型”或“消息类型”字段一起用于指定实验TLV或消息的解释。
Administration of Experiment IDs is the responsibility of the experimenters.
实验ID的管理是实验者的责任。
The following are the LDP messages defined in this version of the protocol.
以下是本版本协议中定义的LDP消息。
Message Name Type Section Title
消息名称类型节标题
Notification 0x0001 "Notification Message" Hello 0x0100 "Hello Message" Initialization 0x0200 "Initialization Message"
通知0x0001“通知消息”你好0x0100“你好消息”初始化0x0200“初始化消息”
KeepAlive 0x0201 "KeepAlive Message" Address 0x0300 "Address Message" Address Withdraw 0x0301 "Address Withdraw Message" Label Mapping 0x0400 "Label Mapping Message" Label Request 0x0401 "Label Request Message" Label Withdraw 0x0402 "Label Withdraw Message" Label Release 0x0403 "Label Release Message" Label Abort Request 0x0404 "Label Abort Request Message" Vendor-Private 0x3E00- "LDP Vendor-private Extensions" 0x3EFF Experimental 0x3F00- "LDP Experimental Extensions" 0x3FFF
KeepAlive 0x0201“KeepAlive Message”Address 0x0300“Address draw 0x0301”Address draw Message“Label Mapping 0x0400”Label Mapping Message“Label Request 0x0401”Label Request Message“Label draw 0x0402”Label draw Message“Label Release 0x0403”Label Release Message“Label Abort Request 0x0404”“标签中止请求消息”供应商专用0x3E00-“LDP供应商专用扩展”0x3EFF实验0x3F00-“LDP实验扩展”0x3FFF
The following are the TLVs defined in this version of the protocol.
以下是本版本协议中定义的TLV。
TLV Type Section Title
TLV类型章节标题
FEC 0x0100 "FEC TLV" Address List 0x0101 "Address List TLV" Hop Count 0x0103 "Hop Count TLV" Path Vector 0x0104 "Path Vector TLV" Generic Label 0x0200 "Generic Label TLV" ATM Label 0x0201 "ATM Label TLV" Frame Relay Label 0x0202 "Frame Relay Label TLV" Status 0x0300 "Status TLV" Extended Status 0x0301 "Notification Message" Returned PDU 0x0302 "Notification Message" Returned Message 0x0303 "Notification Message" Common Hello 0x0400 "Hello Message" Parameters IPv4 Transport Address 0x0401 "Hello Message" Configuration 0x0402 "Hello Message" Sequence Number IPv6 Transport Address 0x0403 "Hello Message" Common Session 0x0500 "Initialization Message" Parameters ATM Session Parameters 0x0501 "Initialization Message" Frame Relay Session 0x0502 "Initialization Message" Parameters Label Request 0x0600 "Label Mapping Message" Message ID Vendor-Private 0x3E00- "LDP Vendor-private Extensions" 0x3EFF Experimental 0x3F00- "LDP Experimental Extensions" 0x3FFF
FEC 0x0100“FEC TLV”地址列表0x0101“地址列表TLV”跃点计数0x0103“跃点计数TLV”路径向量0x0104“路径向量TLV”通用标签0x0200“通用标签TLV”ATM标签0x0201“ATM标签TLV”帧中继标签0x0202“帧中继标签TLV”状态0x0300“状态TLV”扩展状态0x0301“通知消息”返回PDU 0x0302“通知消息”返回消息0x0303“通知消息”公共Hello 0x0400“Hello Message”参数IPv4传输地址0x0401“Hello Message”配置0x0402“Hello Message”序列号IPv6传输地址0x0403“Hello Message”公共会话0x0500“初始化消息”“参数ATM会话参数0x0501”初始化消息“帧中继会话0x0502”初始化消息“参数标签请求0x0600”标签映射消息“消息ID供应商专用0x3E00—“LDP供应商专用扩展”0x3EFF实验0x3F00—“LDP实验扩展”0x3FFF
The following are the Status Codes defined in this version of the protocol.
以下是本版本协议中定义的状态代码。
The "E" column is the required setting of the Status Code E-bit; the "Status Data" column is the value of the 30-bit Status Data field in the Status Code TLV.
“E”列是状态代码E位的必要设置；“状态数据”列是状态代码TLV中30位状态数据字段的值。
Note that the setting of the Status Code F-bit is at the discretion of the LSR originating the Status TLV.
注意，状态代码F位的设置由发起状态TLV的LSR决定。
Status Code E Status Data Section Title
状态代码E状态数据部分标题
Success 0 0x00000000 "Status TLV" Bad LDP Identifier 1 0x00000001 "Events Signaled by ..." Bad Protocol Version 1 0x00000002 "Events Signaled by ..." Bad PDU Length 1 0x00000003 "Events Signaled by ..." Unknown Message Type 0 0x00000004 "Events Signaled by ..." Bad Message Length 1 0x00000005 "Events Signaled by ..." Unknown TLV 0 0x00000006 "Events Signaled by ..." Bad TLV length 1 0x00000007 "Events Signaled by ..." Malformed TLV Value 1 0x00000008 "Events Signaled by ..." Hold Timer Expired 1 0x00000009 "Events Signaled by ..." Shutdown 1 0x0000000A "Events Signaled by ..." Loop Detected 0 0x0000000B "Loop Detection" Unknown FEC 0 0x0000000C "FEC Procedures" No Route 0 0x0000000D "Label Request Mess ..." No Label Resources 0 0x0000000E "Label Request Mess ..." Label Resources / 0 0x0000000F "Label Request Mess ..." Available Session Rejected/ 1 0x00000010 "Session Initialization" No Hello Session Rejected/ 1 0x00000011 "Session Initialization" Parameters Advertisement Mode Session Rejected/ 1 0x00000012 "Session Initialization" Parameters Max PDU Length Session Rejected/ 1 0x00000013 "Session Initialization" Parameters Label Range KeepAlive Timer 1 0x00000014 "Events Signaled by ..." Expired Label Request Aborted 0 0x00000015 "Label Request Abort ..." Missing Message 0 0x00000016 "Events Signaled by ..." Parameters Unsupported Address 0 0x00000017 "FEC Procedures" Family "Address Message Proc ..."
成功0 0x00000000“状态TLV“坏LDP标识符1 0x00000001”事件由…发出信号“坏协议版本1 0x00000002”事件由…发出信号“坏PDU长度1 0x00000003”事件由…发出信号“未知消息类型0 0x00000004”事件由…发出信号“坏消息长度1 0x00000005”事件由…发出信号“未知TLV 0 0x00000006”“事件由…发出信号”“错误TLV长度1 0x00000007”“事件由…发出信号”“格式错误TLV值1 0x00000008”“事件由…发出信号”“保持计时器过期1 0x00000009”“事件由…发出信号”“关机1 0x0000000A”“事件由…发出信号”“循环检测到0 0x0000000B”“循环检测到未知FEC 0 0x0000000C”“FEC过程”“无路由0 0x0000000D”标签请求混乱…“无标签资源0 0x0000000E”标签请求混乱…“标签资源/0 0x0000000F”标签请求混乱…“可用会话被拒绝/1 0x00000010”会话初始化“无Hello会话被拒绝/1 0x00000011”会话初始化“参数播发模式会话被拒绝/1 0x00000012”会话初始化“参数最大PDU长度会话被拒绝/1 0x00000013”会话初始化“参数标签范围保持计时器1 0x00000014”由…发出信号的事件“过期标签请求中止0 0x00000015”标签请求中止…“丢失消息0 0x00000016”由…发出信号的事件。。。“参数不支持的地址0 0x00000017”FEC过程“系列”地址消息过程
Session Rejected/ 1 0x00000018 "Session Initialization" Bad KeepAlive Time Internal Error 1 0x00000019 "Events Signaled by ..."
会话被拒绝/1 0x00000018“会话初始化”保留时间错误内部错误1 0x00000019“事件由…发出信号”
The UDP port for LDP Hello messages is 646.
LDP Hello消息的UDP端口为646。
The TCP port for establishing LDP session connections is 646.
用于建立LDP会话连接的TCP端口为646。
The Implicit NULL label (see [RFC3031]) is represented as a Generic Label TLV with a Label field value as specified by [RFC3032].
隐式空标签（请参见[RFC3031]）表示为通用标签TLV，标签字段值由[RFC3032]指定。
LDP defines the following name spaces which require management:
LDP定义了以下需要管理的名称空间：
- Message Type Name Space. - TLV Type Name Space. - FEC Type Name Space. - Status Code Name Space. - Experiment ID Name Space.
- 消息类型名称空间。-TLV类型名称空间。-FEC类型名称空间。-状态代码名称空间。-实验ID名称空间。
The following sections provide guidelines for managing these name spaces.
以下各节提供了管理这些名称空间的指导原则。
LDP divides the name space for message types into three ranges. The following are the guidelines for managing these ranges:
LDP将消息类型的名称空间划分为三个范围。以下是管理这些范围的指南：
- Message Types 0x0000 - 0x3DFF. Message types in this range are part of the LDP base protocol. Following the policies outlined in [IANA], Message types in this range are allocated through an IETF Consensus action.
- 消息类型0x0000-0x3DFF。此范围内的消息类型是LDP基本协议的一部分。按照[IANA]中概述的策略，此范围内的消息类型通过IETF一致行动进行分配。
- Message Types 0x3E00 - 0x3EFF. Message types in this range are reserved for Vendor Private extensions and are the responsibility of the individual vendors (see Section "LDP Vendor-private Messages"). IANA management of this range of the Message Type Name Space is unnecessary.
- 消息类型0x3E00-0x3EFF。此范围内的消息类型为供应商专用扩展保留，由各个供应商负责（请参阅“LDP供应商专用消息”一节）。IANA不需要管理此范围的消息类型名称空间。
- Message Types 0x3F00 - 0x3FFF. Message types in this range are reserved for Experimental extensions and are the responsibility of the individual experimenters (see Sections "LDP Experimental Extensions" and "Experiment ID Name Space"). IANA management of this range of the Message Type Name Space is unnecessary; however, IANA is responsible for managing part of the Experiment ID Name Space (see below).
- 消息类型0x3F00-0x3FFF。此范围内的消息类型保留给实验扩展，由各个实验人员负责（请参阅“LDP实验扩展”和“实验ID名称空间”部分）。IANA不需要管理此范围内的消息类型名称空间；但是，IANA负责管理部分实验ID名称空间（见下文）。
LDP divides the name space for TLV types into three ranges. The following are the guidelines for managing these ranges:
LDP将TLV类型的名称空间划分为三个范围。以下是管理这些范围的指南：
- TLV Types 0x0000 - 0x3DFF. TLV types in this range are part of the LDP base protocol. Following the policies outlined in [IANA], TLV types in this range are allocated through an IETF Consensus action.
- TLV类型0x0000-0x3DFF。此范围内的TLV类型是LDP基本协议的一部分。按照[IANA]中概述的政策，通过IETF共识行动分配此范围内的TLV类型。
- TLV Types 0x3E00 - 0x3EFF. TLV types in this range are reserved for Vendor Private extensions and are the responsibility of the individual vendors (see Section "LDP Vendor-private TLVs"). IANA management of this range of the TLV Type Name Space is unnecessary.
- TLV类型0x3E00-0x3EFF。此范围内的TLV类型为供应商专用扩展保留，由各供应商负责（见“LDP供应商专用TLV”一节）。IANA不需要管理此范围的TLV类型名称空间。
- TLV Types 0x3F00 - 0x3FFF. TLV types in this range are reserved for Experimental extensions and are the responsibility of the individual experimenters (see Sections "LDP Experimental Extensions" and "Experiment ID Name Space"). IANA management of this range of the TLV Name Space is unnecessary; however, IANA is responsible for managing part of the Experiment ID Name Space (see below).
- TLV类型0x3F00-0x3FFF。此范围内的TLV类型保留用于实验扩展，由各个实验者负责（请参阅“LDP实验扩展”和“实验ID名称空间”部分）。IANA不需要管理此范围的TLV名称空间；但是，IANA负责管理部分实验ID名称空间（见下文）。
The range for FEC types is 0 - 255.
FEC类型的范围为0-255。
Following the policies outlined in [IANA], FEC types in the range 0 - 127 are allocated through an IETF Consensus action, types in the range 128 - 191 are allocated as First Come First Served, and types in the range 192 - 255 are reserved for Private Use.
按照[IANA]中概述的策略，通过IETF一致行动分配0-127范围内的FEC类型，分配128-191范围内的类型为先到先得，保留192-255范围内的类型供私人使用。
The range for Status Codes is 0x00000000 - 0x3FFFFFFF.
状态代码的范围为0x00000000-0x3FFFFFFF。
Following the policies outlined in [IANA], Status Codes in the range 0x00000000 - 0x1FFFFFFF are allocated through an IETF Consensus action, codes in the range 0x20000000 - 0x3EFFFFFF are allocated as First Come First Served, and codes in the range 0x3F000000 - 0x3FFFFFFF are reserved for Private Use.
按照[IANA]中概述的政策，0x00000000-0x1FFFFFF范围内的状态代码通过IETF一致行动分配，0x20000000-0x3FFFFFF范围内的代码分配为先到先得，0x3F000000-0x3FFFFFFFF范围内的代码保留供私人使用。
The range for Experiment Ids is 0x00000000 - 0xffffffff.
实验ID的范围为0x00000000-0xffffffff。
Following the policies outlined in [IANA], Experiment Ids in the range 0x00000000 - 0xefffffff are allocated as First Come First Served and Experiment Ids in the range 0xf0000000 - 0xffffffff are reserved for Private Use.
按照[IANA]中概述的策略，0x00000000-0xEFFFFFF范围内的实验ID分配为先到先得，0xf0000000-0xFFFFFF范围内的实验ID保留供私人使用。
This section identifies threats to which LDP may be vulnerable and discusses means by which those threats might be mitigated.
本节确定了LDP可能容易受到的威胁，并讨论了缓解这些威胁的方法。
There are two types of LDP communication that could be the target of a spoofing attack.
有两种类型的LDP通信可能成为欺骗攻击的目标。
1. Discovery exchanges carried by UDP.
1. UDP承载的发现交换。
LSRs directly connected at the link level exchange Basic Hello messages over the link. The threat of spoofed Basic Hellos can be reduced by:
在链路级别直接连接的LSR通过链路交换基本Hello消息。欺骗性基本问候的威胁可以通过以下方式降低：
o Accepting Basic Hellos only on interfaces to which LSRs that can be trusted are directly connected.
o 仅在可信任的LSR直接连接的接口上接受基本Hello。
o Ignoring Basic Hellos not addressed to the All Routers on this Subnet multicast group.
o 忽略未寻址到此子网多播组上的所有路由器的基本hello。
LSRs not directly connected at the link level may use Extended Hello messages to indicate willingness to establish an LDP session. An LSR can reduce the threat of spoofed Extended Hellos by filtering them and accepting only those originating at sources permitted by an access list.
在链路级别未直接连接的lsr可以使用扩展的Hello消息来表示建立LDP会话的意愿。LSR可以通过过滤扩展Hello并只接受来自访问列表允许的源的扩展Hello来减少欺骗扩展Hello的威胁。
2. Session communication carried by TCP.
2. TCP承载的会话通信。
LDP specifies use of the TCP MD5 Signature Option to provide for the authenticity and integrity of session messages.
LDP指定使用TCP MD5签名选项来提供会话消息的真实性和完整性。
[RFC2385] asserts that MD5 authentication is now considered by some to be too weak for this application. It also points out that a similar TCP option with a stronger hashing algorithm (it cites SHA-1 as an example) could be deployed. To our knowledge no such TCP option has been defined and deployed. However, we note that LDP can use whatever TCP message digest techniques are available, and when one stronger than MD5 is specified and implemented, upgrading LDP to use it would be relatively straightforward.
[RFC2385]断言，有些人认为MD5身份验证对于此应用程序来说太弱。它还指出，可以部署一个具有更强散列算法的类似TCP选项（以SHA-1为例）。据我们所知，尚未定义和部署此类TCP选项。然而，我们注意到，LDP可以使用任何可用的TCP消息摘要技术，当指定并实现一种比MD5更强的技术时，将LDP升级为使用它将相对简单。
LDP provides no mechanism for protecting the privacy of label distribution.
LDP没有提供保护标签分发隐私的机制。
The security requirements of label distribution protocols are essentially identical to those of the protocols which distribute routing information. By providing a mechanism to ensure the authenticity and integrity of its messages LDP provides a level of security which is at least as good as, though no better than, that which can be provided by the routing protocols themselves. The more general issue of whether privacy should be required for routing protocols is beyond the scope of this document.
标签分发协议的安全要求与分发路由信息的协议的安全要求基本相同。通过提供一种机制来确保其消息的真实性和完整性，LDP提供的安全级别至少与路由协议本身所能提供的安全级别相同，但并不优于路由协议本身所能提供的安全级别。路由协议是否需要隐私的更一般性问题超出了本文档的范围。
One might argue that label distribution requires privacy to address the threat of label spoofing. However, that privacy would not protect against label spoofing attacks since data packets carry labels in the clear. Furthermore, label spoofing attacks can be made without knowledge of the FEC bound to a label.
有人可能会说，标签分发需要隐私来应对标签欺骗的威胁。然而，这种隐私并不能防止标签欺骗攻击，因为数据包中的标签是透明的。此外，可以在不知道绑定到标签的FEC的情况下进行标签欺骗攻击。
To avoid label spoofing attacks, it is necessary to ensure that labeled data packets are labeled by trusted LSRs and that the labels placed on the packets are properly learned by the labeling LSRs.
为了避免标签欺骗攻击，有必要确保标记的数据包由可信的LSR标记，并且标记的LSR正确地识别了放置在数据包上的标签。
LDP provides two potential targets for denial of service (DoS) attacks:
LDP为拒绝服务（DoS）攻击提供了两个潜在目标：
1. Well known UDP Port for LDP Discovery
1. 用于LDP发现的著名UDP端口
An LSR administrator can address the threat of DoS attacks via Basic Hellos by ensuring that the LSR is directly connected only to peers which can be trusted to not initiate such an attack.
LSR管理员可以通过基本Hellos解决DoS攻击的威胁，方法是确保LSR仅直接连接到可以信任不会发起此类攻击的对等方。
Interfaces to peers interior to the administrator's domain should not represent a threat since interior peers are under the administrator's control. Interfaces to peers exterior to the domain represent a potential threat since exterior peers are not. An administrator can reduce that threat by connecting the LSR only to exterior peers that can be trusted to not initiate a Basic Hello attack.
与管理员域内部对等点的接口不应构成威胁，因为内部对等点受管理员控制。与域外部对等点的接口表示潜在威胁，因为外部对等点不是。管理员可以通过仅将LSR连接到可以信任不会发起基本Hello攻击的外部对等方来减少这种威胁。
DoS attacks via Extended Hellos are potentially a more serious threat. This threat can be addressed by filtering Extended Hellos using access lists that define addresses with which extended discovery is permitted. However, performing the filtering requires LSR resource.
通过扩展Hellos的DoS攻击可能是更严重的威胁。通过使用定义允许扩展发现的地址的访问列表过滤扩展Hello，可以解决此威胁。但是，执行筛选需要LSR资源。
In an environment where a trusted MPLS cloud can be identified, LSRs at the edge of the cloud can be used to protect interior LSRs against DoS attacks via Extended Hellos by filtering out Extended Hellos originating outside of the trusted MPLS cloud, accepting only those originating at addresses permitted by access lists. This filtering protects LSRs in the interior of the cloud but consumes resources at the edges.
在可识别受信任MPLS云的环境中，云边缘的LSR可用于通过过滤出源自受信任MPLS云外部的扩展HELOS，从而保护内部LSR免受扩展HELOS的DoS攻击，只接受源自访问列表允许的地址的LSR。这种过滤可以保护云内部的LSR，但会消耗边缘的资源。
2. Well known TCP port for LDP Session Establishment
2. 用于LDP会话建立的著名TCP端口
Like other control plane protocols that use TCP, LDP may be the target of DoS attacks, such a SYN attacks. LDP is no more or less vulnerable to such attacks than other control plane protocols that use TCP.
与使用TCP的其他控制平面协议一样，LDP可能是DoS攻击的目标，例如SYN攻击。与使用TCP的其他控制平面协议相比，LDP不易受到此类攻击。
The threat of such attacks can be mitigated somewhat by the following:
此类攻击的威胁可通过以下方式有所缓解：
o An LSR should avoid promiscuous TCP listens for LDP session establishment. It should use only listens that are specific to discovered peers. This enables it to drop attack packets early in their processing since they are less likely to match existing or in-progress connections.
o LSR应避免在建立LDP会话时进行杂乱的TCP侦听。它应该只使用特定于已发现对等点的侦听。这使得它能够在处理攻击数据包的早期丢弃攻击数据包，因为它们不太可能匹配现有或正在进行的连接。
o The use of the MD5 option helps somewhat since it prevents a SYN from being accepted unless the MD5 segment checksum is valid. However, the receiver must compute the checksum before it can decide to discard an otherwise acceptable SYN segment.
o 使用MD5选项会有所帮助，因为它可以防止SYN被接受，除非MD5段校验和有效。但是，接收器必须先计算校验和，然后才能决定放弃其他可接受的SYN段。
o The use of access list mechanisms applied at the boundary of the MPLS cloud in a manner similar to that suggested above for Extended Hellos can protect the interior against attacks originating from outside the cloud.
o 在MPLS云的边界使用访问列表机制，其方式类似于上文建议的扩展Hellos，可以保护内部免受来自云外部的攻击。
The following topics not addressed in this version of LDP are possible areas for future study:
本版本LDP中未涉及的以下主题是未来可能研究的领域：
- Section 2.16 of the MPLS architecture [RFC3031] requires that the initial label distribution protocol negotiation between peer LSRs enable each LSR to determine whether its peer is capable of popping the label stack. This version of LDP assumes that LSRs support label popping for all link types except ATM and Frame Relay. A future version may specify means to make this determination part of the session initiation negotiation.
- MPLS体系结构[RFC3031]第2.16节要求对等LSR之间的初始标签分发协议协商使每个LSR能够确定其对等方是否能够弹出标签堆栈。此版本的LDP假设LSR支持除ATM和帧中继之外的所有链路类型的标签弹出。未来版本可指定使该确定成为会话发起协商一部分的方法。
- LDP support for CoS is not specified in this version. CoS support may be addressed in a future version.
- 此版本中未指定对CoS的LDP支持。CoS支持可在未来版本中解决。
- LDP support for multicast is not specified in this version. Multicast support may be addressed in a future version.
- 此版本中未指定对多播的LDP支持。多播支持可在未来版本中解决。
- LDP support for multipath label switching is not specified in this version. Multipath support may be addressed in a future version.
- 此版本中未指定对多路径标签交换的LDP支持。多路径支持可能在将来的版本中解决。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
The ideas and text in this document have been collected from a number of sources. We would like to thank Rick Boivie, Ross Callon, Alex Conta, Eric Gray, Yoshihiro Ohba, Eric Rosen, Bernard Suter, Yakov Rekhter, and Arun Viswanathan.
本文件中的想法和文本来自多个来源。我们要感谢Rick Boivie、Ross Callon、Alex Conta、Eric Gray、大叶吉弘、Eric Rosen、Bernard Suter、Yakov Rekhter和Arun Viswanathan。
[ATM-VP] N. Feldman, B. Jamoussi, S. Komandur, A, Viswanathan, T Worster, "MPLS using ATM VP Switching", Work in Progress.
[ATM-VP]N.Feldman，B.Jamoussi，S.Komandur，A，Viswanathan，T Worster，“使用ATM VP交换的MPLS”，正在进行中。
[CRLDP] L. Andersson, A. Fredette, B. Jamoussi, R. Callon, P. Doolan, N. Feldman, E. Gray, J. Halpern, J. Heinanen T. E. Kilty, A. G. Malis, M. Girish, K. Sundell, P. Vaananen, T. Worster, L. Wu, R. Dantu, "Constraint-Based LSP Setup using LDP", Work in Progress.
[CRLDP]L.Andersson、A.Fredette、B.Jamoussi、R.Callon、P.Doolan、N.Feldman、E.Gray、J.Halpern、J.Heinanen T.E.Kilty、A.G.Malish、M.Girish、K.Sundell、P.Vaananen、T.Worster、L.Wu、R.Dantu，“使用LDP的基于约束的LSP设置”，正在进行中。
[DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[DIFFSERV]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“区分服务的架构”，RFC 24751998年12月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1483] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993.
[RFC1483]Heinanen，J.，“ATM适配层5上的多协议封装”，RFC 1483，1993年7月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC1700] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771]Rekhter，Y.和T.Li，“边境网关协议4（BGP-4）”，RFC 17711995年3月。
[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月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999.
[RFC2702]Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell，M.和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Rekhter，Y.，Tappan，D.，Farinaci，D.，Fedorkow，G.，Li，T.和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3034] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[RFC3034]Conta，A.，Doolan，P.和A.Malis，“帧中继网络上标签切换的使用规范”，RFC 3034，2001年1月。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3035]Davie，B.，Lawrence，J.，McCloghrie，K.，Rekhter，Y.，Rosen，E.，Swallow，G.和P.Doolan，“使用LDP和ATM VC交换的MPLS”，RFC 3035，2001年1月。
[RFC3037] Thomas, B. and E. Gray, "LDP Applicability", RFC 3037, January 2001.
[RFC3037]Thomas，B.和E.Gray，“LDP适用性”，RFC 3037，2001年1月。
Loa Andersson Nortel Networks Inc St Eriksgatan 115, PO Box 6701 113 85 Stockholm Sweden
Loa Andersson Nortel Networks Inc.St Eriksgatan 115，邮政信箱6701 113 85瑞典斯德哥尔摩
Phone: +46 8 5088 36 34
Mobile: +46 70 522 78 34
EMail: loa.andersson@nortelnetworks.com
Phone: +46 8 5088 36 34
Mobile: +46 70 522 78 34
EMail: loa.andersson@nortelnetworks.com
Paul Doolan Ennovate Networks 60 Codman Hill Rd Marlborough MA 01719
马萨诸塞州马尔伯勒市科德曼山路60号保罗·杜兰·恩诺瓦特网络公司01719
Phone: 978-263-2002 EMail: pdoolan@ennovatenetworks.com
电话：978-263-2002电子邮件：pdoolan@ennovatenetworks.com
Nancy Feldman IBM Research 30 Saw Mill River Road Hawthorne, NY 10532
Nancy Feldman IBM Research 30 Saw Mill River Road霍桑，纽约州10532
Phone: 914-784-3254 EMail: nkf@us.ibm.com
电话：914-784-3254电子邮件：nkf@us.ibm.com
Andre Fredette PhotonEx Corporation 8C Preston Court Bedford, MA 01730
马里兰州贝德福德普雷斯顿法院8C号安德烈·弗雷迪特摄影公司01730
Phone: 781-301-4655 EMail: fredette@photonex.com
电话：781-301-4655电子邮件：fredette@photonex.com
Bob Thomas Cisco Systems, Inc. 250 Apollo Dr. Chelmsford, MA 01824
鲍勃·托马斯·思科系统公司250阿波罗·切姆斯福德博士，马萨诸塞州01824
Phone: 978-244-8078 EMail: rhthomas@cisco.com
电话：978-244-8078电子邮件：rhthomas@cisco.com
This section specifies label distribution behavior in terms of LSR response to the following events:
本节根据LSR对以下事件的响应指定标签分发行为：
- Receive Label Request Message; - Receive Label Mapping Message; - Receive Label Abort Request Message; - Receive Label Release Message; - Receive Label Withdraw Message; - Recognize new FEC; - Detect change in FEC next hop; - Receive Notification Message / Label Request Aborted; - Receive Notification Message / No Label Resources; - Receive Notification Message / No Route; - Receive Notification Message / Loop Detected; - Receive Notification Message / Label Resources Available; - Detect local label resources have become available; - LSR decides to no longer label switch a FEC; - Timeout of deferred label request.
- 接收标签请求消息；-接收标签映射消息；-接收标签中止请求消息；-接收标签释放消息；-接收标签撤消消息；-识别新的FEC；-检测FEC下一跳的变化；-接收通知消息/标签请求已中止；-接收通知消息/无标签资源；-接收通知消息/无路由；-检测到接收通知消息/循环；-接收可用的通知消息/标签资源；-检测本地标签资源已可用；-LSR决定不再将交换机标记为FEC；-延迟的标签请求超时。
The specification of LSR behavior in response to an event has three parts:
响应事件的LSR行为规范包括三个部分：
1. Summary. Prose that describes LSR response to the event in overview.
1. 总结概述中描述LSR对事件的响应的散文。
2. Context. A list of elements referred to by the Algorithm part of the specification. (See 3.)
2. 上下文规范中算法部分引用的元素列表。（见第3条。）
3. Algorithm. An algorithm for LSR response to the event.
3. 算法。LSR响应事件的算法。
The Summary may omit details of the LSR response, such as bookkeeping action or behavior dependent on the LSR label advertisement mode, control mode, or label retention mode in use. The intent is that the Algorithm fully and unambiguously specify the LSR response.
摘要可以省略LSR响应的细节，例如依赖于使用中的LSR标签广告模式、控制模式或标签保留模式的簿记操作或行为。其目的是算法完全明确地指定LSR响应。
The algorithms in this section use procedures defined in the MPLS architecture specification [RFC3031] for hop-by-hop routed traffic. These procedures are:
本节中的算法使用MPLS体系结构规范[RFC3031]中为逐跳路由流量定义的过程。这些程序是：
- Label Distribution procedure, which is performed by a downstream LSR to determine when to distribute a label for a FEC to LDP peers. The architecture defines four Label Distribution procedures:
- 标签分发过程，由下游LSR执行，以确定何时将FEC的标签分发给LDP对等方。该体系结构定义了四个标签分发过程：
. Downstream Unsolicited Independent Control, called PushUnconditional in [RFC3031].
. 下游未经请求的独立控制，称为PUSHIN[RFC3031]。
. Downstream Unsolicited Ordered Control, called PushConditional in [RFC3031].
. 下游未经请求的有序控制，称为PushConditional in[RFC3031]。
. Downstream On Demand Independent Control, called PulledUnconditional in [RFC3031].
. 下游按需独立控制，在[RFC3031]中称为条件控制。
. Downstream On Demand Ordered Control, called PulledConditional in [RFC3031].
. 下游按需有序控制，在[RFC3031]中称为拉动条件。
- Label Withdrawal procedure, which is performed by a downstream LSR to determine when to withdraw a FEC label mapping previously distributed to LDP peers. The architecture defines a single Label Withdrawal procedure. Whenever an LSR breaks the binding between a label and a FEC, it must withdraw the FEC label mapping from all LDP peers to which it has previously sent the mapping.
- 标签提取过程，由下游LSR执行，以确定何时提取先前分发给LDP对等方的FEC标签映射。该体系结构定义了单个标签提取过程。每当LSR断开标签和FEC之间的绑定时，它必须从它先前发送映射到的所有LDP对等方撤回FEC标签映射。
- Label Request procedure, which is performed by an upstream LSR to determine when to explicitly request that a downstream LSR bind a label to a FEC and send it the corresponding label mapping. The architecture defines three Label Request procedures:
- 标签请求过程，由上游LSR执行，以确定何时明确请求下游LSR将标签绑定到FEC并向其发送相应的标签映射。该体系结构定义了三个标签请求过程：
. Request Never. The LSR never requests a label.
. 从不要求。LSR从不要求标签。
. Request When Needed. The LSR requests a label whenever it needs one.
. 需要时请求。LSR在需要标签时请求标签。
. Request On Request. This procedure is used by non-label merging LSRs. The LSR requests a label when it receives a request for one, in addition to whenever it needs one.
. 一个接一个的请求。此过程由非标签合并LSR使用。LSR在收到标签请求时以及需要标签时都会请求标签。
- Label Release procedure, which is performed by an upstream LSR to determine when to release a previously received label mapping for a FEC. The architecture defines two Label Release procedures:
- 标签释放过程，由上游LSR执行，以确定何时释放先前接收到的FEC标签映射。该体系结构定义了两个标签发布程序：
. Conservative label retention, called Release On Change in [RFC3031].
. 保守的标签保留，称为[RFC3031]中更改时的发布。
. Liberal label retention, called No Release On Change in [RFC3031].
. 自由的标签保留，称为[RFC3031]更改时不发布。
- Label Use procedure, which is performed by an LSR to determine when to start using a FEC label for forwarding/switching. The architecture defines three Label Use procedures:
- 标签使用过程，由LSR执行，以确定何时开始使用FEC标签进行转发/交换。该体系结构定义了三个标签使用过程：
. Use Immediate. The LSR immediately uses a label received from a FEC next hop for forwarding/switching.
. 立即使用。LSR立即使用从FEC下一跳接收的标签进行转发/交换。
. Use If Loop Free. The LSR uses a FEC label received from a FEC next hop for forwarding/switching only if it has determined that by doing so it will not cause a forwarding loop.
. 如果没有循环，则使用。仅当LSR已经确定通过这样做它不会导致转发循环时，它才使用从FEC下一跳接收的FEC标签进行转发/切换。
. Use If Loop Not Detected. This procedure is the same as Use Immediate unless the LSR has detected a loop in the FEC LSP. Use of the FEC label for forwarding/switching will continue until the next hop for the FEC changes or the loop is no longer detected.
. 如果未检测到循环，则使用。除非LSR在FEC LSP中检测到环路，否则此过程与使用立即数相同。将FEC标签用于转发/切换将继续，直到FEC的下一跳发生变化或不再检测到循环。
This version of LDP does not include a loop prevention mechanism; therefore, the procedures below do not make use of the Use If Loop Free procedure.
此版本的LDP不包括环路预防机制；因此，下面的过程不使用use If无循环过程。
- Label No Route procedure (called Label Not Available procedure in [RFC3031]), which is performed by an upstream LSR to determine how to respond to a No Route notification from a downstream LSR in response to a request for a FEC label mapping. The architecture specification defines two Label No Route procedures:
- 标签无路由程序（在[RFC3031]中称为标签不可用程序），由上游LSR执行，以确定如何响应来自下游LSR的无路由通知，以响应FEC标签映射请求。架构（architecture）规范定义了两个无标签布线程序：
. Request Retry. The LSR should issue the label request at a later time.
. 请求重试。LSR应在以后发出标签请求。
. No Request Retry. The LSR should assume the downstream LSR will provide a label mapping when the downstream LSR has a next hop and it should not reissue the request.
. 没有请求重试。LSR应假设下游LSR在下游LSR有下一跳且不应重新发出请求时将提供标签映射。
This section defines LDP label distribution procedures by specifying an algorithm for each label distribution event. The requirement on an LDP implementation is that its event handling must have the effect specified by the algorithms. That is, an implementation need not follow exactly the steps specified by the algorithms as long as the effect is identical.
本节通过为每个标签分发事件指定算法来定义LDP标签分发过程。LDP实现的要求是其事件处理必须具有算法指定的效果。也就是说，只要效果相同，实现不需要完全遵循算法指定的步骤。
The algorithms for handling label distribution events share common actions. The specifications below package these common actions into procedure units. Specifications for these common procedures are in their own section "Common Label Distribution Procedures", which follows this.
处理标签分发事件的算法共享公共操作。以下规范将这些常见操作打包成程序单元。这些通用程序的规范在其自己的章节“通用标签分发程序”中，如下所示。
An implementation would use data structures to store information about protocol activity. This appendix specifies the information to be stored in sufficient detail to describe the algorithms, and assumes the ability to retrieve the information as needed. It does not specify the details of the data structures.
实现将使用数据结构来存储有关协议活动的信息。本附录详细说明了要存储的信息，以描述算法，并假设能够根据需要检索信息。它没有指定数据结构的详细信息。
Summary:
总结：
The response by an LSR to receipt of a FEC label request from an LDP peer may involve one or more of the following actions:
LSR对从LDP对等方接收FEC标签请求的响应可涉及以下一个或多个动作：
- Transmission of a notification message to the requesting LSR indicating why a label mapping for the FEC cannot be provided;
- 向请求LSR发送通知消息，指示为什么不能提供FEC的标签映射；
- Transmission of a FEC label mapping to the requesting LSR;
- 向请求LSR发送FEC标签映射；
- Transmission of a FEC label request to the FEC next hop;
- 向FEC下一跳发送FEC标签请求；
- Installation of labels for forwarding/switching use by the LSR.
- 安装标签，供LSR转发/交换使用。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- MsgSource. The LDP peer that sent the message.
- MsgSource。发送消息的LDP对等方。
- FEC. The FEC specified in the message.
- 联邦选举委员会。消息中指定的FEC。
- RAttributes. Attributes received with the message. E.g., Hop Count, Path Vector.
- 陈词滥调。随消息一起接收的属性。例如，跳数、路径向量。
- SAttributes. Attributes to be included in Label Request message, if any, propagated to FEC Next Hop.
- 赞词。要包含在标签请求消息中的属性（如果有）将传播到FEC下一跳。
- StoredHopCount. The hop count, if any, previously recorded for the FEC.
- 商店老板。先前为FEC记录的跃点计数（如果有）。
Algorithm:
算法：
LRq.1 Execute procedure Check_Received_Attributes (MsgSource, LabelRequest, RAttributes). If Loop Detected, goto LRq.13.
LRq.1执行过程检查收到的属性（MsgSource、LabelRequest、RAttributes）。如果检测到环路，转到LRq.13。
LRq.2 Is there a Next Hop for FEC? If not, goto LRq.5.
LRq.2 FEC有下一跳吗？如果没有，转到LRq.5。
LRq.3 Is MsgSource the Next Hop? Ifnot, goto LRq.6.
LRq.3 MsgSource是下一跳吗？如果没有，转到LRq.6。
LRq.4 Execute procedure Send_Notification (MsgSource, Loop Detected). Goto LRq.13
LRq.4执行过程发送通知（MsgSource，检测到循环）。转到LRq.13
LRq.5 Execute procedure Send_Notification (MsgSource, No Route). Goto LRq.13.
LRq.5执行过程发送通知（MsgSource，无路由）。转到LRq.13。
LRq.6 Has LSR previously received a label request for FEC from MsgSource? If not, goto LRq.8. (See Note 1.)
LRq.6 LSR以前是否从MsgSource收到FEC的标签请求？如果没有，转到LRq.8。（见注1。）
LRq.7 Is the label request a duplicate request? If so, Goto LRq.13. (See Note 2.)
LRq.7标签请求是否为重复请求？如果是，转到LRq.13。（见注2。）
LRq.8 Record label request for FEC received from MsgSource and mark it pending.
LRq.8记录从MsgSource收到的FEC标签请求，并将其标记为挂起。
LRq.9 Perform LSR Label Distribution procedure:
LRq.9执行LSR标签分发程序：
For Downstream Unsolicited Independent Control OR For Downstream On Demand Independent Control
用于下游主动独立控制或下游按需独立控制
1. Has LSR previously received and retained a label mapping for FEC from Next Hop?. Is so, set Propagating to IsPropagating. If not, set Propagating to NotPropagating.
1. LSR以前是否从下一跳接收并保留了FEC的标签映射？。如果是这样，请将“传播”设置为“IsPropagating”。如果不是，请将“传播”设置为“不传播”。
2. Execute procedure Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, Propagating, StoredHopCount).
2. 执行过程准备\u标签\u映射\u属性（MsgSource、FEC、RAttributes、SAttributes、传播、StoredHopCount）。
3. Execute procedure Send_Label (MsgSource, FEC, SAttributes).
3. 执行程序Send_Label（MsgSource、FEC、SAttributes）。
4. Is LSR egress for FEC? OR Has LSR previously received and retained a label mapping for FEC from Next Hop? If so, goto LRq.11. If not, goto LRq.10.
4. 是FEC的LSR出口吗？或者LSR以前是否从下一跳接收并保留了FEC的标签映射？如果是，转到LRq.11。如果没有，转到LRq.10。
For Downstream Unsolicited Ordered Control OR For Downstream On Demand Ordered Control
用于下游未经请求的订购控制或下游按需订购控制
1. Is LSR egress for FEC? OR Has LSR previously received and retained a label mapping for FEC from Next Hop? (See Note 3.) If not, goto LRq.10.
1. 是FEC的LSR出口吗？或者LSR以前是否从下一跳接收并保留了FEC的标签映射？（见注3。）如果没有，转到LRq.10。
2. Execute procedure Prepare_Label_Mapping_Attributes(MsgSource, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount)
2. 执行过程准备\u标签\u映射\u属性（MsgSource、FEC、RAttributes、SAttributes、IsPropagating、StoredHopCount）
3. Execute procedure Send_Label (MsgSource, FEC, SAttributes). Goto LRq.11.
3. 执行程序Send_Label（MsgSource、FEC、SAttributes）。转到LRq.11。
LRq.10 Perform LSR Label Request procedure:
LRq.10执行LSR标签申请程序：
For Request Never
永不索取
1. Goto LRq.13.
1. 转到LRq.13。
For Request When Needed OR For Request On Request
在需要时提出请求或根据请求提出请求
1. Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, RAttributes, SAttributes);
1. 执行程序准备\u标签\u请求\u属性（下一跳、FEC、RAttributes、SAttributes）；
2. Execute procedure Send_Label_Request (Next Hop, FEC, SAttributes). Goto LRq.13.
2. 执行过程发送标签请求（下一跳、FEC、SAT属性）。转到LRq.13。
LRq.11 Has LSR successfully sent a label for FEC to MsgSource? If not, goto LRq.13. (See Note 4.)
LRq.11 LSR是否已成功向MsgSource发送FEC标签？如果没有，转到LRq.13。（见注4。）
LRq.12 Perform LSR Label Use procedure.
LRq.12执行LSR标签使用程序。
For Use Immediate OR For Use If Loop Not Detected
用于立即使用或在未检测到循环时使用
1. Install label sent to MsgSource and label from Next Hop (if LSR is not egress) for forwarding/switching use.
1. 安装发送到MsgSource的标签和来自下一跳的标签（如果LSR不是出口），以供转发/交换使用。
LRq.13 DONE
LRq.13完成
Notes:
笔记：
1. In the case where MsgSource is a non-label merging LSR it will send a label request for each upstream LDP peer that has requested a label for FEC from it. The LSR must be able to distinguish such requests from a non-label merging MsgSource from duplicate label requests.
1. 如果MsgSource是非标签合并LSR，则它将向向其请求FEC标签的每个上游LDP对等方发送标签请求。LSR必须能够区分此类请求、非标签合并MsgSource和重复标签请求。
The LSR uses the message ID of received Label Request messages to detect duplicate requests. This means that an LSR (the upstream peer) may not reuse the message ID used for a Label Request until the Label Request transaction has completed.
LSR使用接收到的标签请求消息的消息ID来检测重复请求。这意味着在标签请求事务完成之前，LSR（上游对等方）可能不会重用用于标签请求的消息ID。
2. When an LSR sends a label request to a peer it records that the request has been sent and marks it as outstanding. As long as the request is marked outstanding the LSR should not send another request for the same label to the peer. Such a second request would be a duplicate. The Send_Label_Request procedure described below obeys this rule.
2. 当LSR向对等方发送标签请求时，它会记录该请求已发送并将其标记为未完成。只要请求被标记为未完成，LSR就不应向对等方发送另一个相同标签的请求。这样的第二个请求将是重复的。下面描述的发送标签请求过程遵循此规则。
A duplicate label request is considered a protocol error and should be dropped by the receiving LSR (perhaps with a suitable notification returned to MsgSource).
重复标签请求被视为协议错误，应由接收LSR删除（可能会向MsgSource返回适当的通知）。
3. If LSR is not merge-capable, this test will fail.
3. 如果LSR不支持合并，则此测试将失败。
4. The Send_Label procedure may fail due to lack of label resources, in which case the LSR should not perform the Label Use procedure.
4. 由于缺少标签资源，发送标签程序可能会失败，在这种情况下，LSR不应执行标签使用程序。
Summary:
总结：
The response by an LSR to receipt of a FEC label mapping from an LDP peer may involve one or more of the following actions:
LSR对从LDP对等方接收FEC标签映射的响应可涉及以下一个或多个动作：
- Transmission of a label release message for the FEC label to the LDP peer;
- 将用于FEC标签的标签释放消息传输到LDP对等方；
- Transmission of label mapping messages for the FEC to one or more LDP peers,
- 将FEC的标签映射消息传输到一个或多个LDP对等点，
- Installation of the newly learned label for forwarding/switching use by the LSR.
- 安装新学习的标签，供LSR转发/交换使用。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- MsgSource. The LDP peer that sent the message.
- MsgSource。发送消息的LDP对等方。
- FEC. The FEC specified in the message.
- 联邦选举委员会。消息中指定的FEC。
- Label. The label specified in the message.
- 标签消息中指定的标签。
- PrevAdvLabel. The label for FEC, if any, previously advertised to an upstream peer.
- PrevAdvLabel。FEC的标签（如果有的话），先前向上游对等方发布。
- StoredHopCount. The hop count previously recorded for the FEC.
- 商店老板。先前为FEC记录的跃点计数。
- RAttributes. Attributes received with the message. E.g., Hop Count, Path Vector.
- 陈词滥调。随消息一起接收的属性。例如，跳数、路径向量。
- SAttributes to be included in Label Mapping message, if any, propagated to upstream peers.
- 要包含在标签映射消息中的属性（如果有），传播到上游对等方。
Algorithm:
算法：
LMp.1 Does the received label mapping match an outstanding label request for FEC previously sent to MsgSource. If not, goto LMp.3.
LMp.1收到的标签映射是否与先前发送到MsgSource的FEC的未完成标签请求匹配。如果没有，转到LMp.3。
LMp.2 Delete record of outstanding FEC label request.
LMp.2删除未完成的FEC标签请求记录。
LMp.3 Execute procedure Check_Received_Attributes (MsgSource, LabelMapping, RAttributes). If No Loop Detected, goto LMp.9.
LMp.3执行过程检查收到的属性（MsgSource、LabelMapping、RAttributes）。如果未检测到环路，则转到LMp.9。
LMp.4 Does the LSR have a previously received label mapping for FEC from MsgSource? (See Note 1.) If not, goto LMp.8. (See Note 2.)
LMp.4 LSR是否有以前从MsgSource收到的FEC标签映射？（见注1。）如果没有，转到LMp.8。（见注2。）
LMp.5 Does the label previously received from MsgSource match Label (i.e., the label received in the message)? (See Note 3.) If not, goto LMp.8. (See Note 4.)
LMp.5以前从MsgSource接收到的标签是否与标签匹配（即消息中接收到的标签）？（见注3。）如果没有，转到LMp.8。（见注4。）
LMp.6 Delete matching label mapping for FEC previously received from MsgSource.
LMp.6删除先前从MsgSource收到的FEC的匹配标签映射。
LMp.7 Remove Label from forwarding/switching use. (See Note 5.) Goto LMp.33.
LMp.7从转发/交换使用中移除标签。（见注5）转到LMp.33。
LMp.8 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label, Loop Detected Status code). Goto LMp.33.
LMp.8执行程序发送消息（MsgSource、标签释放、FEC、标签、循环检测状态代码）。转到LMp.33。
LMp.9 Does LSR have a previously received label mapping for FEC from MsgSource for the LSP in question? (See Note 6.) If not, goto LMp.11.
LMp.9 LSR是否有之前从MsgSource收到的有关LSP的FEC标签映射？（见注6。）如果没有，转到LMp.11。
LMp.10 Does the label previously received from MsgSource match Label (i.e., the label received in the message)? (See Note 3.) If not, goto LMp.32. (See Note 4.)
LMp.10以前从MsgSource接收到的标签是否与标签匹配（即消息中接收到的标签）？（见注3。）如果没有，转到LMp.32。（见注4。）
LMp.11 Determine the Next Hop for FEC.
LMp.11确定FEC的下一跳。
LMp.12 Is MsgSource the Next Hop for FEC? If so, goto LMp.14.
LMp.12 MsgSource是FEC的下一个跃点吗？如果是，请转到LMp.14。
LMp.13 Perform LSR Label Release procedure:
LMp.13执行LSR标签发布程序：
For Conservative Label retention:
对于保守的标签保留：
1. Goto LMp.32.
1. 转到LMp.32。
For Liberal Label retention:
对于自由标签保留：
1. Record label mapping for FEC with Label and RAttributes has been received from MsgSource. Goto LMp.33.
1. 已从MsgSource收到带有标签和RAttributes的FEC的记录标签映射。转到LMp.33。
LMp.14 Is LSR an ingress for FEC? If not, goto LMp.16.
LMp.14 LSR是FEC的入口吗？如果没有，转到LMp.16。
LMp.15 Install Label for forwarding/switching use.
LMp.15安装转发/交换用标签。
LMp.16 Record label mapping for FEC with Label and RAttributes has been received from MsgSource.
LMp.16已从MsgSource收到带有标签和RAttributes的FEC记录标签映射。
LMp.17 Iterate through LMp.31 for each Peer. (See Note 7).
LMp.17针对每个对等点迭代LMp.31。（见注7）。
LMp.18 Has LSR previously sent a label mapping for FEC to Peer for the LSP in question? (See Note 8.) If so, goto LMp.22.
LMp.18 LSR之前是否发送了FEC到相关LSP对等方的标签映射？（见注8。）如果是，转到LMp.22。
LMp.19 Is the Downstream Unsolicited Ordered Control Label Distribution procedure being used by LSR? If not, goto LMp.28.
LMp.19 LSR是否正在使用下游未经请求的订购控制标签分发程序？如果没有，转到LMp.28。
LMp.20 Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).
LMp.20执行程序准备标签映射属性（对等、FEC、RAttributes、SAttributes、IsPropagating、StoredHopCount）。
LMp.21 Execute procedure Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). Goto LMp.28
LMp.21执行程序发送消息（对等、标签映射、FEC、PrevAdvLabel、SATAttribute）。转到LMp.28
LMp.22 Iterate through LMp.27 for each label mapping for FEC previously sent to Peer.
LMp.22针对先前发送给对等方的FEC的每个标签映射，迭代LMp.27。
LMp.23 Are RAttributes in the received label mapping consistent with those previously sent to Peer? If so, continue iteration from LMp.22 for next label mapping. (See Note 9.)
LMp.23收到的标签映射中的RAttributes是否与之前发送给对等方的一致？如果是这样，继续LMp.22中的迭代以进行下一个标签映射。（见注9。）
LMp.24 Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, StoredHopCount).
LMp.24执行程序准备标签映射属性（对等、FEC、RAttributes、SAttributes、IsPropagating、StoredHopCount）。
LMp.25 Execute procedure Send_Message (Peer, Label Mapping, FEC, PrevAdvLabel, SAttributes). (See Note 10.)
LMp.25执行程序发送消息（对等、标签映射、FEC、PrevAdvLabel、SAttributes）。（见注10。）
LMp.26 Update record of label mapping for FEC previously sent to Peer to include the new attributes sent.
LMp.26更新先前发送给对等方的FEC标签映射记录，以包括发送的新属性。
LMp.27 End iteration from LMp.22.
LMp.27结束LMp.22的迭代。
LMp.28 Does LSR have any label requests for FEC from Peer marked as pending? If not, goto LMp.30.
LMp.28 LSR是否有来自对等方的FEC标签请求标记为待定？如果没有，转到LMp.30。
LMp.29 Perform LSR Label Distribution procedure:
LMp.29执行LSR标签分发程序：
For Downstream Unsolicited Independent Control OR For Downstream Unsolicited Ordered Control
用于下游非请求独立控制或下游非请求有序控制
1. Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount).
1. 执行过程准备标签映射属性（对等、FEC、RAttributes、SAttributes、IsPropagating、UnknownHopCount）。
2. Execute procedure Send_Label (Peer, FEC, SAttributes). If the procedure fails, continue iteration for next Peer at LMp.17.
2. 执行程序发送标签（对等、FEC、SAT属性）。如果该过程失败，则在LMp.17继续下一个对等方的迭代。
3. If no pending requests exist for Peer goto LMp.30. (See Note 11.)
3. 如果不存在对等转到LMp.30的未决请求。（见注11。）
For Downstream On Demand Independent Control OR For Downstream On Demand Ordered Control
用于下游按需独立控制或下游按需有序控制
1. Iterate through Step 5 for each pending label request for FEC from Peer marked as pending.
1. 对于来自标记为挂起的对等方的FEC的每个挂起标签请求，重复步骤5。
2. Execute procedure Prepare_Label_Mapping_Attributes(Peer, FEC, RAttributes, SAttributes, IsPropagating, UnknownHopCount)
2. 执行过程准备\u标签\u映射\u属性（对等、FEC、RAttributes、SAttributes、IsPropagating、UnknownHopCount）
3. Execute procedure Send_Label (Peer, FEC, SAttributes). If the procedure fails, continue iteration for next Peer at LMp.17.
3. 执行程序发送标签（对等、FEC、SAT属性）。如果该过程失败，则在LMp.17继续下一个对等方的迭代。
4. Delete record of pending request.
4. 删除挂起请求的记录。
5. End iteration from Step 1.
5. 从步骤1结束迭代。
6. Goto LMp.30.
6. 转到LMp.30。
LMp.30 Perform LSR Label Use procedure:
LMp.30执行LSR标签使用程序：
For Use Immediate OR For Use If Loop Not Detected
用于立即使用或在未检测到循环时使用
1. Iterate through Step 3 for each label mapping for FEC previously sent to Peer.
1. 对于先前发送给对等方的FEC的每个标签映射，重复执行步骤3。
2. Install label received and label sent to Peer for forwarding/switching use.
2. 安装接收到的标签，并将标签发送给对等方以供转发/切换使用。
3. End iteration from Step 1.
3. 从步骤1结束迭代。
4. Goto LMp.31.
4. 转到LMp.31。
LMp.31 End iteration from LMp.17. Go to LMp.33.
LMp.31结束LMp.17的迭代。转到LMp.33。
LMp.32 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label).
LMp.32执行程序发送消息（MsgSource、标签发布、FEC、标签）。
LMp.33 DONE.
LMp.33完成。
Notes:
笔记：
1. If the LSR is merging there should be at most 1 received mapping for the FEC for the LSP in question. In the non-merging case there could be multiple received mappings for the FEC for the LSP in question.
1. 如果LSR正在合并，则对于所讨论的LSP，FEC最多应该有1个接收到的映射。在非合并情况下，可能存在多个接收到的有关LSP的FEC映射。
2. If LSR has detected a loop and it has not previously received a label mapping from MsgSource for the FEC, it simply releases the label.
2. 如果LSR检测到一个循环，并且它以前没有从MsgSource接收FEC的标签映射，那么它只是释放标签。
3. Does the Label received in the message match any of the 1 or more label mappings identified in the previous step (LMp.4 or LMp.9)?
3. 消息中接收到的标签是否与上一步（LMp.4或LMp.9）中标识的1个或多个标签映射中的任何一个匹配？
4. An unsolicited mapping with a different label from the same peer would be an attempt to establish multipath label switching, which is not supported in this version of LDP.
4. 使用来自同一对等方的不同标签进行未经请求的映射将试图建立多路径标签交换，这在本版本的LDP中不受支持。
5. If Label is not in forwarding/switching use, LMp.7 has no effect.
5. 如果标签未在转发/交换中使用，LMp.7不起作用。
6. If the received label mapping message matched an outstanding label request in LMp.1, then (by definition) LSR has not previously received a label mapping for FEC for the LSP in question. If the LSR is merging upstream labels for the LSP in question, there should be at most 1 received mapping. In the non-merging case, there could be multiple received label mappings for the same FEC, one for each resulting LSP.
6. 如果收到的标签映射消息与LMp.1中未完成的标签请求相匹配，那么（根据定义）LSR之前没有收到所述LSP的FEC标签映射。如果LSR正在合并相关LSP的上游标签，则最多应该有1个接收到的映射。在非合并情况下，同一FEC可能有多个接收到的标签映射，每个结果LSP对应一个。
7. The LMp.17 iteration includes MsgSource in order to handle the case where LSR is operating in Downstream Unsolicited ordered control mode. Ordered control prevents LSR from advertising a label for FEC until it has received a label mapping from its next hop (MsgSource) for FEC.
7. LMp.17迭代包括MsgSource，以便处理LSR在下游未经请求的顺序控制模式下运行的情况。有序控制防止LSR在从FEC的下一跳（MsgSource）接收到标签映射之前为FEC播发标签。
8. If LSR is merging the LSP it may have previously sent label mappings for the FEC LSP to one or more peers. If LSR is not merging, it may have sent a label mapping for the LSP in question to at most one LSR.
8. 如果LSR正在合并LSP，则它可能先前已将FEC LSP的标签映射发送到一个或多个对等方。如果LSR未合并，它可能已将相关LSP的标签映射发送到最多一个LSR。
9. The loop detection Path Vector attribute is considered in this check. If the received RAttributes include a Path Vector and no Path Vector had been previously sent to the Peer, or if the received Path Vector is inconsistent with the Path Vector previously sent to the Peer, then the attributes are considered to be inconsistent. Note that an LSR is not required to store a received Path Vector after it propagates the Path Vector in a mapping message. If an LSR does not store the Path Vector, it has no way to check the consistency of a newly received Path Vector. This means that whenever such an LSR receives a mapping message carrying a Path Vector it must always propagate the Path Vector.
9. 此检查中考虑了循环检测路径向量属性。如果接收到的RAttributes包含路径向量，并且之前没有向对等方发送路径向量，或者如果接收到的路径向量与之前发送给对等方的路径向量不一致，则认为属性不一致。请注意，LSR在映射消息中传播路径向量后，不需要存储接收到的路径向量。如果LSR不存储路径向量，则无法检查新接收到的路径向量的一致性。这意味着，每当这样的LSR接收到带有路径向量的映射消息时，它必须始终传播路径向量。
10. LMp.22 through LMp.27 deal with a situation that can arise when the LSR is using independent control and it receives a mapping from the downstream peer after it has sent a mapping to an upstream peer. In this situation the LSR needs to propagate any changed attributes, such as Hop Count, upstream. If Loop Detection is configured on, the propagated attributes must include the Path Vector
10. LMp.22至LMp.27处理当LSR使用独立控制并且在向上游对等方发送映射后从下游对等方接收映射时可能出现的情况。在这种情况下，LSR需要向上游传播任何更改的属性，例如跳数。如果启用循环检测，则传播的属性必须包括路径向量
11. An LSR operating in Downstream Unsolicited mode must process any Label Request messages it receives. If there are pending label requests, fall through into the Downstream on Demand procedures in order to satisfy the pending requests.
11. 在下游非请求模式下运行的LSR必须处理其收到的任何标签请求消息。如果存在未决标签请求，则进入下游随需应变程序，以满足未决请求。
Summary:
总结：
When an LSR receives a label abort request message from a peer, it checks whether it has already responded to the label request in question. If it has, it silently ignores the message. If it has not, it sends the peer a Label Request Aborted Notification. In addition, if it has a label request outstanding for the LSP in question to a downstream peer, it sends a Label Abort Request to the downstream peer to abort the LSP.
当LSR收到来自对等方的标签中止请求消息时，它会检查它是否已经响应了相关的标签请求。如果有，它会自动忽略该消息。如果没有，则向对等方发送标签请求中止通知。此外，如果它向下游对等方发送了有关LSP的未决标签请求，则它向下游对等方发送标签中止请求以中止LSP。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- MsgSource. The LDP peer that sent the message.
- MsgSource。发送消息的LDP对等方。
- FEC. The FEC specified in the message.
- 联邦选举委员会。消息中指定的FEC。
- RequestMessageID. The message ID of the label request message to be aborted.
- 请求消息ID。要中止的标签请求消息的消息ID。
- Next Hop. The next hop for the FEC.
- 下一跳。FEC的下一跳。
Algorithm:
算法：
LAbR.1 Does the message match a previously received label request message from MsgSource? (See Note 1.) If not, goto LAbR.12.
LAbR.1消息是否与以前从MsgSource收到的标签请求消息匹配？（见注1。）如果没有，转到LAbR.12。
LAbR.2 Has LSR responded to the previously received label request? If so, goto LAbR.12.
LAbR.2 LSR是否响应了之前收到的标签请求？如果是，转到LAbR.12。
LAbR.3 Execute procedure Send_Message(MsgSource, Notification, Label Request Aborted, TLV), where TLV is the Label Request Message ID TLV received in the label abort request message.
LAbR.3 Execute procedure Send_Message（MsgSource，Notification，Label Request Aborted，TLV），其中TLV是在Label abort请求消息中接收到的标签请求消息ID TLV。
LAbR.4 Does LSR have a label request message outstanding for FEC? If so, goto LAbR.7
LAbR.4 LSR是否有未完成的FEC标签请求消息？如果是，转到第7实验室
LAbR.5 Does LSR have a label mapping for FEC? If not, goto LAbR.11
LAbR.5 LSR是否有FEC的标签映射？如果没有，转到LAbR.11
LAbR.6 Generate Event: Received Label Release Message for FEC from MsgSource. (See Note 2.) Goto LAbR.11.
LAbR.6生成事件：从MsgSource收到FEC的标签释放消息。（见注2）转到LAbR.11。
LAbR.7 Is LSR merging the LSP for FEC? If not, goto LAbR.9.
LAbR.7 LSR是否合并FEC的LSP？如果没有，转到LAbR.9。
LAbR.8 Are there upstream peers other than MsgSource that have requested a label for FEC? If so, goto LAbR.11.
LAbR.8是否有MsgSource以外的上游对等方请求FEC标签？如果是，转到LAbR.11。
LAbR.9 Execute procedure Send_Message (Next Hop, Label Abort Request, FEC, TLV), where TLV is a Label Request Message ID TLV containing the Message ID used by the LSR in the outstanding Label Request message.
LAbR.9执行过程Send_Message（下一跳，标签中止请求，FEC，TLV），其中TLV是标签请求消息ID TLV，包含LSR在未完成标签请求消息中使用的消息ID。
LAbR.10 Record that a label abort request for FEC is pending.
LAbR.10记录FEC的标签中止请求处于挂起状态。
LAbR.11 Delete record of label request for FEC from MsgSource.
LAbR.11从MsgSource删除FEC标签请求记录。
LAbR.12 DONE
LAbR.12完成
Notes:
笔记：
1. LSR uses FEC and the Label Request Message ID TLV carried by the label abort request to locate its record (if any) for the previously received label request from MsgSource.
1. LSR使用FEC和标签中止请求携带的标签请求消息ID TLV来定位先前从MsgSource收到的标签请求的记录（如果有）。
2. If LSR has received a label mapping from NextHop, it should behave as if it had advertised a label mapping to MsgSource and MsgSource has released it.
2. 如果LSR已从NextHop接收到标签映射，则其行为应类似于已向MsgSource播发标签映射，并且MsgSource已将其发布。
Summary:
总结：
When an LSR receives a label release message for a FEC from a peer, it checks whether other peers hold the released label. If none do, the LSR removes the label from forwarding/switching use, if it has not already done so, and if the LSR holds a label mapping from the FEC next hop, it releases the label mapping.
当LSR从对等方收到FEC的标签释放消息时，它会检查其他对等方是否持有已释放的标签。如果没有，LSR将从转发/交换使用中删除标签；如果LSR尚未这样做，并且如果LSR持有来自FEC下一跳的标签映射，则它将释放标签映射。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- MsgSource. The LDP peer that sent the message.
- MsgSource。发送消息的LDP对等方。
- Label. The label specified in the message.
- 标签消息中指定的标签。
- FEC. The FEC specified in the message.
- 联邦选举委员会。消息中指定的FEC。
Algorithm:
算法：
LRl.1 Remove MsgSource from record of peers that hold Label for FEC. (See Note 1.)
LRl.1从持有FEC标签的对等方记录中删除MsgSource。（见注1。）
LRl.2 Does message match an outstanding label withdraw for FEC previously sent to MsgSource? If not, goto LRl.4
LRl.2消息是否与先前发送到MsgSource的FEC的未完成标签撤回匹配？如果没有，转到LRl.4
LRl.3 Delete record of outstanding label withdraw for FEC previously sent to MsgSource.
LRl.3删除先前发送给MsgSource的FEC的未完成标签提取记录。
LRl.4 Is LSR merging labels for this FEC? If not, goto LRl.6. (See Note 2.)
LRl.4是LSR合并此FEC的标签吗？如果没有，转到LRl.6。（见注2。）
LRl.5 Has LSR previously advertised a label for this FEC to other peers? If so, goto LRl.10.
LRl.5 LSR之前是否向其他同行宣传过该FEC的标签？如果是，转到LRl.10。
LRl.6 Is LSR egress for the FEC? If so, goto LRl.10
LRl.6是FEC的LSR出口吗？如果是，转到LRl.10
LRl.7 Is there a Next Hop for FEC? AND Does LSR have a previously received label mapping for FEC from Next Hop? If not, goto LRl.10.
LRl.7有FEC的下一跳吗？LSR是否有以前从下一跳接收到的FEC标签映射？如果没有，转到LRl.10。
LRl.8 Is LSR configured to propagate releases? If not, goto LRl.10. (See Note 3.)
LRl.8是否将LSR配置为传播版本？如果没有，转到LRl.10。（见注3。）
LRl.9 Execute procedure Send_Message (Next Hop, Label Release, FEC, Label from Next Hop).
LRl.9执行过程发送消息（下一跳、标签释放、FEC、下一跳标签）。
LRl.10 Remove Label from forwarding/switching use for traffic from MsgSource.
LRl.10将标签从MsgSource的流量转发/交换使用中移除。
LRl.11 Do any peers still hold Label for FEC? If so, goto LRl.13.
LRl.11是否有任何对等方仍然持有FEC的标签？如果是，转到LRl.13。
LRl.12 Free the Label.
LRl.12释放标签。
LRl.13 DONE.
LRl.13完成。
Notes:
笔记：
1. If LSR is using Downstream Unsolicited label distribution, it should not re-advertise a label mapping for FEC to MsgSource until MsgSource requests it.
1. 如果LSR使用下游未经请求的标签分发，则在MsgSource请求之前，它不应重新公布FEC到MsgSource的标签映射。
2. LRl.4 through LRl.8 deal with determining whether where the LSR should propagate the label release to a downstream peer (LRl.9).
2. LRl.4到LRl.8处理确定LSR是否应该将标签发布传播到下游对等方的位置（LRl.9）。
3. If LRl.8 is reached, no upstream LSR holds a label for the FEC, and the LSR holds a label for the FEC from the FEC Next Hop. The LSR could propagate the Label Release to the Next Hop. By propagating the Label Release the LSR releases a potentially scarce label resource. In doing so, it also increases the latency for re-establishing the LSP should MsgSource or some other upstream LSR send it a new Label Request for FEC.
3. 如果达到LRl.8，则没有上游LSR持有FEC的标签，并且LSR持有来自FEC下一跳的FEC的标签。LSR可以将标签发布传播到下一个跃点。通过传播标签释放，LSR释放了潜在的稀缺标签资源。在这样做的过程中，如果MsgSource或其他一些上游LSR向其发送FEC的新标签请求，它也会增加重新建立LSP的延迟。
Whether or not to propagate the release is not a protocol issue. Label distribution will operate properly whether or not the release is propagated. The decision to propagate or not should take into consideration factors such as: whether labels are a scarce resource in the operating environment; the importance of keeping LSP setup latency low by keeping the
是否传播该版本不是协议问题。无论发布是否传播，标签分发都将正常运行。宣传与否的决定应考虑以下因素：标签是否是运营环境中的稀缺资源；通过保持
amount of signaling required small; whether LSP setup is ingress-controlled or egress-controlled in the operating environment.
所需信号量小；LSP设置在操作环境中是入口控制还是出口控制。
Summary:
总结：
When an LSR receives a label withdraw message for a FEC from an LDP peer, it responds with a label release message and it removes the label from any forwarding/switching use. If ordered control is in use, the LSR sends a label withdraw message to each LDP peer to which it had previously sent a label mapping for the FEC. If the LSR is using Downstream on Demand label advertisement with independent control, it then acts as if it had just recognized the FEC.
当LSR从LDP对等方接收到FEC的标签撤销消息时，它用标签释放消息进行响应，并从任何转发/交换使用中移除标签。如果使用了有序控制，则LSR向其先前向其发送FEC标签映射的每个LDP对等方发送标签撤销消息。如果LSR使用具有独立控制的下游按需标签广告，则其行为就好像它刚刚识别FEC一样。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- MsgSource. The LDP peer that sent the message.
- MsgSource。发送消息的LDP对等方。
- Label. The label specified in the message.
- 标签消息中指定的标签。
- FEC. The FEC specified in the message.
- 联邦选举委员会。消息中指定的FEC。
Algorithm:
算法：
LWd.1 Remove Label from forwarding/switching use. (See Note 1.)
LWd.1从转发/切换使用中移除标签。（见注1。）
LWd.2 Execute procedure Send_Message (MsgSource, Label Release, FEC, Label)
LWd.2执行程序发送消息（MsgSource、标签发布、FEC、标签）
LWd.3 Has LSR previously received and retained a matching label mapping for FEC from MsgSource? If not, goto LWd.13.
LWd.3 LSR以前是否从MsgSource接收并保留了FEC的匹配标签映射？如果没有，转到LWd.13。
LWd.4 Delete matching label mapping for FEC previously received from MsgSource.
LWd.4删除先前从MsgSource接收的FEC的匹配标签映射。
LWd.5 Is LSR using ordered control? If so, goto LWd.8.
LWd.5 LSR是否使用有序控制？如果是，转到LWd.8。
LWd.6 Is MsgSource using Downstream On Demand label advertisement? If not, goto LWd.13.
LWd.6 MsgSource是否使用下游按需标签广告？如果没有，转到LWd.13。
LWd.7 Generate Event: Recognize New FEC for FEC. Goto LWd.13. (See Note 2.)
LWd.7生成事件：为FEC识别新FEC。转到LWd.13。（见注2。）
LWd.8 Iterate through LWd.12 for each Peer, other than MsgSource.
LWd.8对每个对等点（MsgSource除外）迭代LWd.12。
LWd.9 Has LSR previously sent a label mapping for FEC to Peer? If not, continue iteration for next Peer at LWd.8.
LWd.9 LSR以前是否向对等方发送FEC的标签映射？若并没有，在LWd.8继续下一个对等的迭代。
LWd.10 Does the label previously sent to Peer "map" to the withdrawn Label? If not, continue iteration for next Peer at LWd.8. (See Note 3.)
LWd.10先前发送给对等方的标签是否与撤回的标签“对应”？若并没有，在LWd.8继续下一个对等的迭代。（见注3。）
LWd.11 Execute procedure Send_Label_Withdraw (Peer, FEC, Label previously sent to Peer).
LWd.11执行程序Send_Label_Retrach（对等方、FEC、先前发送给对等方的标签）。
LWd.12 End iteration from LWd.8.
LWd.12结束LWd.8的迭代。
LWd.13 DONE
LWd.13完成
Notes:
笔记：
1. If Label is not in forwarding/switching use, LWd.1 has no effect.
1. 如果标签未在转发/切换中使用，LWd.1将不起作用。
2. LWd.7 handles the case where the LSR is using Downstream On Demand label distribution with independent control. In this situation the LSR should send a label request to the FEC next hop as if it had just recognized the FEC.
2. LWd.7处理LSR使用独立控制的下游按需标签分发的情况。在这种情况下，LSR应该向FEC下一跳发送一个标签请求，就好像它刚刚识别了FEC一样。
3. LWd.10 handles both label merging (one or more incoming labels map to the same outgoing label) and no label merging (one label maps to the outgoing label) cases.
3. LWd.10处理标签合并（一个或多个传入标签映射到同一个传出标签）和无标签合并（一个标签映射到传出标签）情况。
Summary:
总结：
The response by an LSR to learning a new FEC via the routing table may involve one or more of the following actions:
LSR对经由路由表学习新FEC的响应可涉及以下一个或多个动作：
- Transmission of label mappings for the FEC to one or more LDP peers;
- 将FEC的标签映射传输到一个或多个LDP对等点；
- Transmission of a label request for the FEC to the FEC next hop;
- 将针对FEC的标签请求传输到FEC下一跳；
- Any of the actions that can occur when the LSR receives a label mapping for the FEC from the FEC next hop.
- LSR从FEC下一跳接收FEC的标签映射时可能发生的任何动作。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- FEC. The newly recognized FEC.
- 联邦选举委员会。新确认的FEC。
- Next Hop. The next hop for the FEC.
- 下一跳。FEC的下一跳。
- InitAttributes. Attributes to be associated with the new FEC. (See Note 1.)
- 初始化属性。要与新FEC关联的属性。（见注1。）
- SAttributes. Attributes to be included in Label Mapping or Label Request messages, if any, sent to peers.
- 赞词。要包含在标签映射或标签请求消息（如果有）中的属性发送给对等方。
- StoredHopCount. Hop count associated with FEC label mapping, if any, previously received from Next Hop.
- 商店老板。与先前从下一个跃点接收的FEC标签映射（如果有）关联的跃点计数。
Algorithm:
算法：
FEC.1 Perform LSR Label Distribution procedure:
FEC.1执行LSR标签分发程序：
For Downstream Unsolicited Independent Control
对于下游主动独立控制
1. Iterate through 5 for each Peer.
1. 对每个对等点迭代5次。
2. Has LSR previously received and retained a label mapping for FEC from Next Hop? If so, set Propagating to IsPropagating. If not, set Propagating to NotPropagating.
2. LSR以前是否从下一跳接收并保留了FEC的标签映射？如果是，请将“传播”设置为“IsPropagating”。如果不是，请将“传播”设置为“不传播”。
3. Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, Unknown hop count(0)).
3. 执行过程Prepare_Label_Mapping_属性（对等、FEC、InitAttributes、SAttributes、传播、未知跃点计数（0））。
4. Execute procedure Send_Label (Peer, FEC, SAttributes)
4. 执行程序发送标签（对等、FEC、SAT属性）
5. End iteration from 1. Goto FEC.2.
5. 从1结束迭代。转到FEC.2。
For Downstream Unsolicited Ordered Control
对于下游未经请求的有序控制
1. Iterate through 5 for each Peer.
1. 对每个对等点迭代5次。
2. Is LSR egress for the FEC? OR Has LSR previously received and retained a label mapping for FEC from Next Hop? If not, continue iteration for next Peer.
2. FEC是否有LSR出口？或者LSR以前是否从下一跳接收并保留了FEC的标签映射？若并没有，则继续下一个对等方的迭代。
3. Execute procedure Prepare_Label_Mapping_Attributes (Peer, FEC, InitAttributes, SAttributes, Propagating, StoredHopCount).
3. 执行过程Prepare_Label_Mapping_Attributes（对等、FEC、InitAttributes、SAttributes、传播、StoredHopCount）。
4. Execute procedure Send_Label (Peer, FEC, SAttributes)
4. 执行程序发送标签（对等、FEC、SAT属性）
5. End iteration from 1. Goto FEC.2.
5. 从1结束迭代。转到FEC.2。
For Downstream On Demand Independent Control OR For Downstream On Demand Ordered Control
用于下游按需独立控制或下游按需有序控制
1. Goto FEC.2. (See Note 2.)
1. 转到FEC.2。（见注2。）
FEC.2 Has LSR previously received and retained a label mapping for FEC from Next Hop? If so, goto FEC.5
FEC.2 LSR以前是否从下一跳接收并保留了FEC的标签映射？如果是，转到FEC.5
FEC.3 Is Next Hop an LDP peer? If not, Goto FEC.6
FEC.3下一跳是LDP对等吗？如果没有，转到FEC.6
FEC.4 Perform LSR Label Request procedure:
FEC.4执行LSR标签请求程序：
For Request Never
永不索取
1. Goto FEC.6
1. 转到FEC.6
For Request When Needed OR For Request On Request
在需要时提出请求或根据请求提出请求
1. Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, InitAttributes, SAttributes);
1. 执行程序Prepare_Label_Request_Attributes（下一跳、FEC、InitAttributes、SAttributes）；
2. Execute procedure Send_Label_Request (Next Hop, FEC, SAttributes). Goto FEC.6.
2. 执行过程发送标签请求（下一跳、FEC、SAT属性）。转到FEC.6。
FEC.5 Generate Event: Received Label Mapping from Next Hop. (See Note 3.)
FEC.5生成事件：从下一跳接收到标签映射。（见注3。）
FEC.6 DONE.
FEC.6完成。
Notes:
笔记：
1. An example of an attribute that might be part of InitAttributes is one which specifies desired LSP characteristics, such as class of service (CoS). (Note that while the current version of LDP does not specify a CoS attribute, LDP extensions may.)
1. 可能是InitAttributes一部分的属性的一个示例是指定所需LSP特性的属性，例如服务类（CoS）。（请注意，虽然LDP的当前版本没有指定CoS属性，但LDP扩展可能会指定。）
The means by which FEC InitAttributes, if any, are specified is beyond the scope of LDP. Note that the InitAttributes will not include a known Hop Count or a Path Vector.
指定FEC InitAttributes（如果有）的方法超出了LDP的范围。请注意，InitAttributes将不包括已知的跃点计数或路径向量。
2. An LSR using Downstream On Demand label distribution would send a label only if it had a previously received label request marked as pending. The LSR would have no such pending requests because it responds to any label request for an unknown FEC by sending the requesting LSR a No Route notification and discarding the label request; see LRq.3
2. 使用下游按需标签分发的LSR只有在其先前收到的标签请求标记为挂起时才会发送标签。LSR将不会有此类未决请求，因为它通过向请求LSR发送无路由通知并丢弃标签请求来响应未知FEC的任何标签请求；见LRq.3
3. If the LSR has a label for the FEC from the Next Hop, it should behave as if it had just received the label from the Next Hop. This occurs in the case of Liberal label retention mode.
3. 如果LSR具有来自下一跳的FEC标签，则其行为应与刚刚从下一跳接收到标签一样。这发生在自由标签保留模式的情况下。
Summary:
总结：
The response by an LSR to a change in the next hop for a FEC may involve one or more of the following actions:
LSR对FEC的下一跳中的改变的响应可涉及以下一个或多个动作：
- Removal of the label from the FEC's old next hop from forwarding/switching use;
- 从FEC的旧下一跳中移除标签，以避免转发/交换使用；
- Transmission of label mapping messages for the FEC to one or more LDP peers;
- 将用于FEC的标签映射消息传输到一个或多个LDP对等方；
- Transmission of a label request to the FEC's new next hop;
- 向FEC的新下一跳发送标签请求；
- Any of the actions that can occur when the LSR receives a label mapping from the FEC's new next hop.
- LSR从FEC的新下一跳接收标签映射时可能发生的任何操作。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- FEC. The FEC whose next hop changed.
- 联邦选举委员会。下一跳发生变化的FEC。
- New Next Hop. The current next hop for the FEC.
- 新的下一跳。FEC的当前下一个跃点。
- Old Next Hop. The previous next hop for the FEC.
- 老下一跳。FEC的上一个下一跳。
- OldLabel. Label, if any, previously received from Old Next Hop.
- 旧标签。以前从旧下一跳接收的标签（如果有）。
- CurAttributes. The attributes, if any, currently associated with the FEC.
- 馆藏。当前与FEC关联的属性（如果有）。
- SAttributes. Attributes to be included in Label Label Request message, if any, sent to New Next Hop.
- 赞词。要包含在标签请求消息中的属性（如果有），发送到新的下一个跃点。
Algorithm:
算法：
NH.1 Has LSR previously received and retained a label mapping for FEC from Old Next Hop? If not, goto NH.6.
NH.1 LSR以前是否从旧的下一跳接收并保留FEC的标签映射？如果没有，转到NH.6。
NH.2 Remove label from forwarding/switching use. (See Note 1.)
NH.2从转发/交换使用中移除标签。（见注1。）
NH.3 Is LSR using Liberal label retention? If so, goto NH.6.
NH.3 LSR是否使用自由标签保留？如果是，转到NH.6。
NH.4 Execute procedure Send_Message (Old Next Hop, Label Release, OldLabel).
NH.4执行过程Send_Message（旧下一跳、标签释放、旧标签）。
NH.5 Delete label mapping for FEC previously received from Old Next Hop.
NH.5删除先前从旧下一跳接收的FEC的标签映射。
NH.6 Does LSR have a label request pending with Old Next Hop? If not, goto NH.10.
NH.6 LSR是否有标签请求与旧的下一跳挂起？如果没有，转到NH.10。
NH.7 Is LSR using Conservative label retention? If not, goto NH.10.
NH.7 LSR是否使用保守的标签保留？如果没有，转到NH.10。
NH.8 Execute procedure Send_Message (Old Next Hop, Label Abort Request, FEC, TLV), where TLV is a Label Request Message ID TLV that carries the message ID of the pending label request.
NH.8执行过程Send_Message（旧下一跳，标签中止请求，FEC，TLV），其中TLV是一个标签请求消息ID TLV，它携带挂起标签请求的消息ID。
NH.9 Record a label abort request is pending for FEC with Old Next Hop.
NH.9记录下一跳旧的FEC的标签中止请求挂起。
NH.10 Is there a New Next Hop for the FEC? If not, goto NH.16.
NH.10 FEC是否有新的下一跳？如果没有，转到NH.16。
NH.11 Has LSR previously received and retained a label mapping for FEC from New Next Hop? If not, goto NH.13.
NH.11 LSR以前是否从新的下一跳接收并保留FEC的标签映射？如果没有，转到NH.13。
NH.12 Generate Event: Received Label Mapping from New Next Hop. Goto NH.20. (See Note 2.)
NH.12生成事件：收到来自新下一跳的标签映射。转到新罕布什尔州20号。（见注2。）
NH.13 Is LSR using Downstream on Demand advertisement? OR Is Next Hop using Downstream on Demand advertisement? OR Is LSR using Conservative label retention? (See Note 3.) If so, goto NH.14. If not, goto NH.20.
NH.13 LSR是否使用下游点播广告？或者下一跳是使用下游点播广告？还是LSR使用保守的标签保留？（见注3。）如果是，转到NH.14。如果没有，转到NH.20。
NH.14 Execute procedure Prepare_Label_Request_Attributes (Next Hop, FEC, CurAttributes, SAttributes)
NH.14执行程序准备\u标签\u请求\u属性（下一跳、FEC、策展属性、SAT属性）
NH.15 Execute procedure Send_Label_Request (New Next Hop, FEC, SAttributes). (See Note 4.) Goto NH.20.
NH.15执行程序发送标签请求（新的下一跳、FEC、SAT属性）。（见注4）转到NH.20。
NH.16 Iterate through NH.19 for each Peer.
NH.16对每个对等点迭代NH.19。
NH.17 Has LSR previously sent a label mapping for FEC to Peer? If not, continue iteration for next Peer at NH.16.
NH.17 LSR之前是否向对等方发送FEC的标签映射？如果没有，则在NH.16继续下一个对等点的迭代。
NH.18 Execute procedure Send_Label_Withdraw (Peer, FEC, Label previously sent to Peer).
NH.18执行程序Send_Label_Retrach（对等方、FEC、先前发送给对等方的标签）。
NH.19 End iteration from NH.16.
NH.19结束NH.16的迭代。
NH.20 DONE.
NH.20完成。
Notes:
笔记：
1. If Label is not in forwarding/switching use, NH.2 has no effect.
1. 如果标签未在转发/切换中使用，NH.2不起作用。
2. If the LSR has a label for the FEC from the New Next Hop, it should behave as if it had just received the label from the New Next Hop.
2. 如果LSR具有来自新下一跳的FEC标签，则其行为应与刚从新下一跳接收到标签一样。
3. The purpose of the check on label retention mode is to avoid a race with steps LMp.12-LMp.13 of the procedure for handling a Label Mapping message where the LSR operating in Conservative Label retention mode may have released a label mapping received from the New Next Hop before it detected the FEC next hop had changed.
3. 标签保留模式检查的目的是避免与处理标签映射消息的程序步骤LMp.12-LMp.13的竞争，其中在保守标签保留模式下运行的LSR可能在检测到FEC下一跳已更改之前已释放从新下一跳接收的标签映射。
4. Regardless of the Label Request procedure in use by the LSR, it must send a label request if the conditions in NH.8 hold. Therefore it executes the Send_Label_Request procedure directly rather than perform LSR Label Request procedure.
4. 无论LSR使用何种标签请求程序，如果NH.8中的条件成立，它必须发送标签请求。因此，它直接执行Send_Label_请求过程，而不是执行LSR Label请求过程。
Summary:
总结：
When an LSR receives a Label Request Aborted notification from an LDP peer it records that the corresponding label request transaction, if any, has completed.
当LSR收到来自LDP对等方的标签请求中止通知时，它会记录相应的标签请求事务（如果有）已完成。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- FEC. The FEC for which a label was requested.
- 联邦选举委员会。请求标签的FEC。
- RequestMessageID. The message ID of the label request message to be aborted.
- 请求消息ID。要中止的标签请求消息的消息ID。
- MsgSource. The LDP peer that sent the Notification message.
- MsgSource。发送通知消息的LDP对等方。
Algorithm:
算法：
LRqA.1 Does the notification correspond to an outstanding label request abort for FEC? (See Note 1). If not, goto LRqA.3.
LRqA.1通知是否对应于FEC的未完成标签请求中止？（见注1）。如果没有，转到LRqA.3。
LRqA.2 Record that the label request for FEC has been aborted.
LRqA.2记录FEC的标签请求已中止。
LRqA.3 DONE
LRqA.3完成
Notes:
笔记：
1. The LSR uses the FEC and RequestMessageID to locate its record, if any, of the outstanding label request abort.
1. LSR使用FEC和RequestMessageID来定位未完成标签请求中止的记录（如果有）。
Summary:
总结：
When an LSR receives a No Label Resources notification from an LDP peer, it stops sending label request messages to the peer until it receives a Label Resources Available Notification from the peer.
当LSR从LDP对等方接收到无标签资源通知时，它停止向对等方发送标签请求消息，直到它从对等方接收到标签资源可用通知为止。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- FEC. The FEC for which a label was requested.
- 联邦选举委员会。请求标签的FEC。
- MsgSource. The LDP peer that sent the Notification message.
- MsgSource。发送通知消息的LDP对等方。
Algorithm:
算法：
NoRes.1 Delete record of outstanding label request for FEC sent to MsgSource.
NoRes.1删除发送到MsgSource的FEC未完成标签请求的记录。
NoRes.2 Record label mapping for FEC from MsgSource is needed but that no label resources are available.
需要MsgSource中FEC的NoRes.2记录标签映射，但没有可用的标签资源。
NoRes.3 Set status record indicating it is not OK to send label requests to MsgSource.
NoRes.3设置状态记录，指示无法向MsgSource发送标签请求。
NoRes.4 DONE.
诺里斯4号完成。
Summary:
总结：
When an LSR receives a No Route notification from an LDP peer in response to a Label Request message, the Label No Route procedure in use dictates its response. The LSR either will take no further action, or it will defer the label request by starting a timer and send another Label Request message to the peer when the timer later expires.
当LSR收到来自LDP对等方的No Route通知以响应标签请求消息时，正在使用的标签No Route过程指示其响应。LSR要么不采取进一步的行动，要么通过启动计时器延迟标签请求，并在计时器稍后到期时向对等方发送另一条标签请求消息。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- FEC. The FEC for which a label was requested.
- 联邦选举委员会。请求标签的FEC。
- Attributes. The attributes associated with the label request.
- 属性。与标签请求关联的属性。
- MsgSource. The LDP peer that sent the Notification message.
- MsgSource。发送通知消息的LDP对等方。
Algorithm:
算法：
NoNH.1 Delete record of outstanding label request for FEC sent to MsgSource.
NoNH.1删除发送到MsgSource的FEC未完成标签请求的记录。
NoNH.2 Perform LSR Label No Route procedure.
非H.2执行LSR标签无路线程序。
For Request No Retry
对于请求，请不要重试
1. Goto NoNH.3.
1. 后藤农。
For Request Retry
请求重试
1. Record deferred label request for FEC and Attributes to be sent to MsgSource.
1. 记录要发送到MsgSource的FEC和属性的延迟标签请求。
2. Start timeout. Goto NoNH.3.
2. 启动超时。后藤农。
NoNH.3 DONE.
非H.3完成。
Summary:
总结：
When an LSR receives a Loop Detected Status Code from an LDP peer in response to a Label Request message or a Label Mapping message, it behaves as if it had received a No Route notification.
当LSR响应标签请求消息或标签映射消息从LDP对等方接收到环路检测到的状态码时，它的行为就好像收到了无路由通知一样。
Context:
背景：
See "Receive Notification / No Route".
请参阅“接收通知/无路由”。
Algorithm:
算法：
See "Receive Notification / No Route"
请参阅“接收通知/无路由”
Notes:
笔记：
1. When the Loop Detected notification is in response to a Label Request message, it arrives in a Status Code TLV in a Notification message. When it is in response to a Label Mapping message, it arrives in a Status Code TLV in a Label Release message.
1. 当循环检测到的通知响应标签请求消息时，它在通知消息中以状态代码TLV到达。当它响应标签映射消息时，它在标签发布消息中以状态代码TLV到达。
Summary:
总结：
When an LSR receives a Label Resources Available notification from an LDP peer, it resumes sending label requests to the peer.
当LSR从LDP对等方接收到标签资源可用通知时，它将继续向该对等方发送标签请求。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- MsgSource. The LDP peer that sent the Notification message.
- MsgSource。发送通知消息的LDP对等方。
- SAttributes. Attributes stored with postponed Label Request message.
- 赞词。与延迟标签请求消息一起存储的属性。
Algorithm:
算法：
Res.1 Set status record indicating it is OK to send label requests to MsgSource.
Res.1设置状态记录，指示可以向MsgSource发送标签请求。
Res.2 Iterate through Res.6 for each record of a FEC label mapping needed from MsgSource for which no label resources are available.
Res.2在Res.6中对MsgSource中没有可用标签资源的FEC标签映射的每个记录进行迭代。
Res.3 Is MsgSource the next hop for FEC? If not, goto Res.5.
Res.3 MsgSource是FEC的下一个跃点吗？如果没有，转到第5项。
Res.4 Execute procedure Send_Label_Request (MsgSource, FEC, SAttributes). If the procedure fails, terminate iteration.
Res.4执行程序发送标签请求（MsgSource、FEC、SAT属性）。如果过程失败，终止迭代。
Res.5 Delete record that no resources are available for a label mapping for FEC needed from MsgSource.
Res.5删除没有资源可用于MsgSource所需FEC标签映射的记录。
Res.6 End iteration from Res.2
第6项结束第2项的迭代
Res.7 DONE.
第7项决议完成。
Summary:
总结：
After an LSR has sent a No Label Resources notification to an LDP peer, when label resources later become available it sends a Label Resources Available notification to each such peer.
LSR向LDP对等方发送无标签资源通知后，当标签资源稍后变为可用时，它向每个这样的对等方发送标签资源可用通知。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- Attributes. Attributes stored with postponed Label Mapping message.
- 属性。与延迟标签映射消息一起存储的属性。
Algorithm:
算法：
ResA.1 Iterate through ResA.4 for each Peer to which LSR has previously sent a No Label Resources notification.
对于LSR以前向其发送无标签资源通知的每个对等方，ResA.1迭代ResA.4。
ResA.2 Execute procedure Send_Notification (Peer, Label Resources Available)
ResA.2执行程序发送通知（对等、标签资源可用）
ResA.3 Delete record that No Label Resources notification was previously sent to Peer.
ResA.3删除以前未向对等方发送标签资源通知的记录。
ResA.4 End iteration from ResA.1
ResA.4从ResA.1结束迭代
ResA.5 Iterate through ResA.8 for each record of a label mapping needed for FEC for Peer but no-label-resources. (See Note 1.)
ResA.5针对FEC需要的标签映射的每个记录，在ResA.8中迭代对等但无标签资源。（见注1。）
ResA.6 Execute procedure Send_Label (Peer, FEC, Attributes). If the procedure fails, terminate iteration.
ResA.6执行程序发送标签（对等、FEC、属性）。如果过程失败，终止迭代。
ResA.7 Clear record of FEC label mapping needed for peer but no-label-resources.
ResA.7对等方需要的FEC标签映射的清晰记录，但没有标签资源。
ResA.8 End iteration from ResA.5
ResA.8从ResA.5结束迭代
ResA.9 DONE.
ResA.9完成。
Notes:
笔记：
1. Iteration ResA.5 through ResA.8 handles the situation where the LSR is using Downstream Unsolicited label distribution and was previously unable to allocate a label for a FEC.
1. 迭代ResA.5到ResA.8处理LSR使用下游未经请求的标签分发，并且以前无法为FEC分配标签的情况。
Summary:
总结：
An LSR may unilaterally decide to no longer label switch a FEC for an LDP peer. An LSR that does so must send a label withdraw message for the FEC to the peer.
LSR可以单方面决定不再为LDP对等机标记FEC。这样做的LSR必须向对等方发送FEC的标签撤销消息。
Context:
背景：
- Peer. The peer.
- 同龄人同伴。
- FEC. The FEC.
- 联邦选举委员会。联邦选举委员会。
- PrevAdvLabel. The label for FEC previously advertised to Peer.
- PrevAdvLabel。先前向对等方发布的FEC标签。
Algorithm:
算法：
NoLS.1 Execute procedure Send_Label_Withdraw (Peer, FEC, PrevAdvLabel). (See Note 1.)
NoLS.1执行程序Send\U Label\U RECUN（对等、FEC、PrevAdvLabel）。（见注1。）
NoLS.2 DONE.
NoLS.2完成。
Notes:
笔记：
1. The LSR may remove the label from forwarding/switching use as part of this event or as part of processing the label release from the peer in response to the label withdraw.
1. LSR可将标签从转发/切换使用中移除，作为此事件的一部分，或作为响应标签撤回处理对等方的标签释放的一部分。
Summary:
总结：
Label requests are deferred in response to No Route and Loop Detected notifications. When a deferred FEC label request for a peer times out, the LSR sends the label request.
标签请求延迟，以响应未检测到路由和循环的通知。当对等机的延迟FEC标签请求超时时，LSR发送标签请求。
Context:
背景：
- LSR. The LSR handling the event.
- LSR。处理事件的LSR。
- FEC. The FEC associated with the timeout event.
- 联邦选举委员会。与超时事件关联的FEC。
- Peer. The LDP peer associated with the timeout event.
- 同龄人与超时事件关联的LDP对等方。
- Attributes. Attributes stored with deferred Label Request message.
- 属性。与延迟标签请求消息一起存储的属性。
Algorithm:
算法：
TO.1 Retrieve the record of the deferred label request.
1检索延迟标签请求的记录。
TO.2 Is Peer the next hop for FEC? If not, goto TO.4.
到.2是FEC的下一跳吗？如果没有，转到。4。
TO.3 Execute procedure Send_Label_Request (Peer, FEC).
执行程序发送标签请求（对等，FEC）。
TO.4 DONE.
到。4完成。
This section specifies utility procedures used by the algorithms that handle label distribution events.
本节指定处理标签分发事件的算法所使用的实用程序过程。
Summary:
总结：
The Send_Label procedure allocates a label for a FEC for an LDP peer, if possible, and sends a label mapping for the FEC to the peer. If the LSR is unable to allocate the label and if it has a
如果可能，Send_Label过程为LDP对等方的FEC分配标签，并向对等方发送FEC的标签映射。如果LSR无法分配标签，并且
pending label request from the peer, it sends the LDP peer a No Label Resources notification.
等待来自对等方的标签请求，它向LDP对等方发送无标签资源通知。
Parameters:
参数：
- Peer. The LDP peer to which the label mapping is to be sent.
- 同龄人要向其发送标签映射的LDP对等方。
- FEC. The FEC for which a label mapping is to be sent.
- 联邦选举委员会。要为其发送标签映射的FEC。
- Attributes. The attributes to be included with the label mapping.
- 属性。要包含在标签映射中的属性。
Additional Context:
其他背景：
- LSR. The LSR executing the procedure.
- LSR。执行该过程的LSR。
- Label. The label allocated and sent to Peer.
- 标签已分配并发送给对等方的标签。
Algorithm:
算法：
SL.1 Does LSR have a label to allocate? If not, goto SL.9.
SL.1 LSR是否有要分配的标签？如果没有，转到SL.9。
SL.2 Allocate Label and bind it to the FEC.
SL.2分配标签并将其绑定到FEC。
SL.3 Install Label for forwarding/switching use.
SL.3安装转发/交换用标签。
SL.4 Execute procedure Send_Message (Peer, Label Mapping, FEC, Label, Attributes).
SL.4执行程序发送消息（对等、标签映射、FEC、标签、属性）。
SL.5 Record label mapping for FEC with Label and Attributes has been sent to Peer.
SL.5已将带有标签和属性的FEC的记录标签映射发送给对等方。
SL.6 Does LSR have a record of a FEC label request from Peer marked as pending? If not, goto SL.8.
SL.6 LSR是否有来自被标记为待定的对等方的FEC标签请求记录？如果没有，转到SL.8。
SL.7 Delete record of pending label request for FEC from Peer.
SL.7从对等方删除待处理的FEC标签请求记录。
SL.8 Return success.
SL.8返回成功。
SL.9 Does LSR have a label request for FEC from Peer marked as pending? If not, goto SL.13.
SL.9 LSR是否有来自对等方的FEC标签请求标记为待定？如果没有，转到SL.13。
SL.10 Execute procedure Send_Notification (Peer, No Label Resources).
SL.10执行程序发送通知（对等，无标签资源）。
SL.11 Delete record of pending label request for FEC from Peer.
SL.11从对等方删除待处理的FEC标签请求记录。
SL.12 Record No Label Resources notification has been sent to Peer. Goto SL.14.
SL.12记录未向对等方发送标签资源通知。转到SL.14。
SL.13 Record label mapping needed for FEC and Attributes for Peer, but no-label-resources. (See Note 1.)
SL.13记录FEC需要的标签映射和对等的属性，但没有标签资源。（见注1。）
SL.14 Return failure.
SL.14返回故障。
Notes:
笔记：
1. SL.13 handles the case of Downstream Unsolicited label distribution when the LSR is unable to allocate a label for a FEC to send to a Peer.
1. SL.13处理LSR无法为FEC分配标签以发送给对等方时下游未经请求的标签分发情况。
Summary:
总结：
An LSR uses the Send_Label_Request procedure to send a request for a label for a FEC to an LDP peer if currently permitted to do so.
如果当前允许，LSR使用Send_Label_Request过程向LDP对等方发送FEC标签请求。
Parameters:
参数：
- Peer. The LDP peer to which the label request is to be sent.
- 同龄人要向其发送标签请求的LDP对等方。
- FEC. The FEC for which a label request is to be sent.
- 联邦选举委员会。要为其发送标签请求的FEC。
- Attributes. Attributes to be included in the label request. E.g., Hop Count, Path Vector.
- 属性。要包含在标签请求中的属性。例如，跳数、路径向量。
Additional Context:
其他背景：
- LSR. The LSR executing the procedure.
- LSR。执行该过程的LSR。
Algorithm:
算法：
SLRq.1 Has a label request for FEC previously been sent to Peer and is it marked as outstanding? If so, Return success. (See Note 1.)
SLRq.1之前是否向对等方发送了FEC的标签请求，是否标记为未完成？如果是，返回成功。（见注1。）
SLRq.2 Is status record indicating it is OK to send label requests to Peer set? If not, goto SLRq.6
SLRq.2状态记录是否表明可以向对等集发送标签请求？如果没有，转到SLRq.6
SLRq.3 Execute procedure Send_Message (Peer, Label Request, FEC, Attributes).
SLRq.3执行过程发送消息（对等、标签请求、FEC、属性）。
SLRq.4 Record label request for FEC has been sent to Peer and mark it as outstanding.
SLRq.4 FEC的记录标签请求已发送给对等方，并将其标记为未完成。
SLRq.5 Return success.
SLRq.5返回成功。
SLRq.6 Postpone the label request by recording label mapping for FEC and Attributes from Peer is needed but that no label resources are available.
SLRq.6通过记录FEC的标签映射来推迟标签请求，并且需要来自对等方的属性，但没有可用的标签资源。
SLRq.7 Return failure.
SLRq.7返回失败。
Notes:
笔记：
1. If the LSR is a non-merging LSR it must distinguish between attempts to send label requests for a FEC triggered by different upstream LDP peers from duplicate requests. This procedure will not send a duplicate label request.
1. 如果LSR是非合并LSR，则必须区分由不同上游LDP对等点触发的FEC标签请求发送尝试与重复请求。此过程不会发送重复的标签请求。
Summary:
总结：
An LSR uses the Send_Label_Withdraw procedure to withdraw a label for a FEC from an LDP peer. To do this the LSR sends a Label Withdraw message to the peer.
LSR使用Send_Label_draw过程从LDP对等方提取FEC的标签。为此，LSR向对等方发送标签撤销消息。
Parameters:
参数：
- Peer. The LDP peer to which the label withdraw is to be sent.
- 同龄人要向其发送标签撤销的LDP对等方。
- FEC. The FEC for which a label is being withdrawn.
- 联邦选举委员会。正在撤销标签的FEC。
- Label. The label being withdrawn
- 标签正在撤回的标签
Additional Context:
其他背景：
- LSR. The LSR executing the procedure.
- LSR。执行该过程的LSR。
Algorithm:
算法：
SWd.1 Execute procedure Send_Message (Peer, Label Withdraw, FEC, Label)
SWd.1执行程序发送消息（对等、标签撤销、FEC、标签）
SWd.2 Record label withdraw for FEC has been sent to Peer and mark it as outstanding.
SWd.2已将FEC的记录标签撤回发送给同行，并将其标记为未完成。
Summary:
总结：
An LSR uses the Send_Notification procedure to send an LDP peer a notification message.
LSR使用发送通知过程向LDP对等方发送通知消息。
Parameters:
参数：
- Peer. The LDP peer to which the Notification message is to be sent.
- 同龄人要向其发送通知消息的LDP对等方。
- Status. Status code to be included in the Notification message.
- 地位要包含在通知消息中的状态代码。
Additional Context:
其他背景：
None.
没有一个
Algorithm:
算法：
SNt.1 Execute procedure Send_Message (Peer, Notification, Status)
SNt.1执行过程发送消息（对等、通知、状态）
Summary:
总结：
An LSR uses the Send_Message procedure to send an LDP peer an LDP message.
LSR使用Send_消息过程向LDP对等方发送LDP消息。
Parameters:
参数：
- Peer. The LDP peer to which the message is to be sent.
- 同龄人要向其发送消息的LDP对等方。
- Message Type. The type of message to be sent.
- 消息类型。要发送的消息的类型。
- Additional message contents . . . .
- 其他消息内容。
Additional Context:
其他背景：
None.
没有一个
Algorithm:
算法：
This procedure is the means by which an LSR sends an LDP message of the specified type to the specified LDP peer.
此过程是LSR向指定LDP对等方发送指定类型的LDP消息的方法。
Summary:
总结：
Check the attributes received in a Label Mapping or Label Request message. If the attributes include a Hop Count or Path Vector, perform a loop detection check. If a loop is detected, cause a Loop Detected Notification message to be sent to MsgSource.
检查标签映射或标签请求消息中接收到的属性。如果属性包括跳数或路径向量，则执行循环检测检查。如果检测到循环，则将循环检测到的通知消息发送到MsgSource。
Parameters:
参数：
- MsgSource. The LDP peer that sent the message.
- MsgSource。发送消息的LDP对等方。
- MsgType. The type of message received.
- MsgType。接收到的消息的类型。
- RAttributes. The attributes in the message.
- 陈词滥调。消息中的属性。
Additional Context:
其他背景：
- LSR Id. The unique LSR Id of this LSR.
- LSR Id。此LSR的唯一LSR Id。
- Hop Count. The Hop Count, if any, in the received attributes.
- 跳数。接收属性中的跃点计数（如果有）。
- Path Vector. The Path Vector, if any in the received attributes.
- 路径向量。路径向量（如果接收到的属性中有）。
Algorithm:
算法：
CRa.1 Do RAttributes include Hop Count? If not, goto CRa.5.
CRa.1 RAttributes是否包含跃点计数？如果没有，转到CRa.5。
CRa.2 Does Hop Count exceed Max allowable hop count? If so, goto CRa.6.
CRa.2跃点计数是否超过允许的最大跃点计数？如果是，转到CRa。
CRa.3 Do RAttributes include Path Vector? If not, goto CRa.5.
CRa.3分布是否包含路径向量？如果没有，转到CRa.5。
CRa.4 Does Path Vector Include LSR Id? OR Does length of Path Vector exceed Max allowable length? If so, goto CRa.6
CRa.4路径向量是否包含LSR Id？或者路径向量的长度是否超过最大允许长度？如果是，转到CRa
CRa.5 Return No Loop Detected.
CRa.5未检测到回路返回。
CRa.6 Is MsgType LabelMapping? If so, goto CRa.8. (See Note 1.)
CRa.6是否有MsgType标签映射？如果是，请转到CRa.8。（见注1。）
CRa.7 Execute procedure Send_Notification (MsgSource, Loop Detected)
CRa.7执行程序发送通知（MsgSource，检测到循环）
CRa.8 Return Loop Detected.
检测到CRa.8回路。
CRa.9 DONE
CRa.9完成
Notes:
笔记：
1. When the attributes being checked were received in a Label Mapping message, the LSR sends the Loop Detected notification in a Status Code TLV in a Label Release message. (See Section "Receive Label Mapping").
1. 当在标签映射消息中接收到要检查的属性时，LSR在标签释放消息中以状态代码TLV发送循环检测通知。（请参阅“接收标签映射”一节）。
Summary:
总结：
This procedure is used whenever a Label Request is to be sent to a Peer to compute the Hop Count and Path Vector, if any, to include in the message.
每当要向对等方发送标签请求以计算要包含在消息中的跃点计数和路径向量（如果有）时，都会使用此过程。
Parameters:
参数：
- Peer. The LDP peer to which the message is to be sent.
- 同龄人要向其发送消息的LDP对等方。
- FEC. The FEC for which a label request is to be sent.
- 联邦选举委员会。要为其发送标签请求的FEC。
- RAttributes. The attributes this LSR associates with the LSP for FEC.
- 陈词滥调。此LSR与FEC的LSP关联的属性。
- SAttributes. The attributes to be included in the Label Request message.
- 赞词。要包含在标签请求消息中的属性。
Additional Context:
其他背景：
- LSR Id. The unique LSR Id of this LSR.
- LSR Id。此LSR的唯一LSR Id。
Algorithm:
算法：
PRqA.1 Is Hop Count required for this Peer (see Note 1.) ? OR Do RAttributes include a Hop Count? OR Is Loop Detection configured on LSR? If not, goto PRqA.14.
PRqA.1该对等机是否需要跃点计数（见注1）？或者RAttributes是否包含跃点计数？还是在LSR上配置了环路检测？如果没有，请转到PRqA.14。
PRqA.2 Is LSR ingress for FEC? If not, goto PRqA.6.
PRqA.2是FEC的LSR入口吗？如果没有，请转到PRqA.6。
PRqA.3 Include Hop Count of 1 in SAttributes.
PRqA.3在SAT属性中包含1的跃点计数。
PRqA.4 Is Loop Detection configured on LSR? If not, goto PRqA.14.
PRqA.4是否在LSR上配置了环路检测？如果没有，请转到PRqA.14。
PRqA.5 Is LSR merge-capable? If so, goto PRqA.14. If not, goto PRqA.13.
PRqA.5是否具有LSR合并功能？如果是，请转到PRqA.14。如果没有，请转到PRqA.13。
PRqA.6 Do RAttributes include a Hop Count? If not, goto PRqA.8.
PRqA.6 RAttributes是否包含跃点计数？如果没有，请转到PRqA.8。
PRqA.7 Increment RAttributes Hop Count and copy the resulting Hop Count to SAttributes. (See Note 2.) Goto PRqA.9.
PRqA.7递增RAttributes跃点计数，并将结果跃点计数复制到SAttributes。（见注2）转到PRqA.9。
PRqA.8 Include Hop Count of unknown (0) in SAttributes.
PRqA.8包括SAT属性中未知（0）的跃点计数。
PRqA.9 Is Loop Detection configured on LSR? If not, goto PRqA.14.
PRqA.9是否在LSR上配置了环路检测？如果没有，请转到PRqA.14。
PRqA.10 Do RAttributes have a Path Vector? If so, goto PRqA.12.
PRqA.10 RAttributes是否有路径向量？如果是，请转到PRqA.12。
PRqA.11 Is LSR merge-capable? If so, goto PRqA.14. If not, goto PRqA.13.
PRqA.11是否具有LSR合并功能？如果是，请转到PRqA.14。如果没有，请转到PRqA.13。
PRqA.12 Add LSR Id to beginning of Path Vector from RAttributes and copy the resulting Path Vector into SAttributes. Goto PRqA.14.
PRqA.12将LSR Id添加到RAttributes路径向量的开头，并将生成的路径向量复制到SAttributes中。转到PRqA.14。
PRqA.13 Include Path Vector of length 1 containing LSR Id in SAttributes.
PRqA.13包括长度为1的路径向量，包含SAT属性中的LSR Id。
PRqA.14 DONE.
PRqA.14完成。
Notes:
笔记：
1. The link with Peer may require that Hop Count be included in Label Request messages; for example, see [RFC3035] and [RFC3034].
1. 与对等方的链路可能要求在标签请求消息中包括跳数；例如，请参见[RFC3035]和[RFC3034]。
2. For hop count arithmetic, unknown + 1 = unknown.
2. 对于跃点计数算法，未知+1=未知。
Summary:
总结：
This procedure is used whenever a Label Mapping is to be sent to a Peer to compute the Hop Count and Path Vector, if any, to include in the message.
每当要将标签映射发送给对等方以计算要包含在消息中的跃点计数和路径向量（如果有）时，都会使用此过程。
Parameters:
参数：
- Peer. The LDP peer to which the message is to be sent.
- 同龄人要向其发送消息的LDP对等方。
- FEC. The FEC for which a label request is to be sent.
- 联邦选举委员会。要为其发送标签请求的FEC。
- RAttributes. The attributes this LSR associates with the LSP for FEC.
- 陈词滥调。此LSR与FEC的LSP关联的属性。
- SAttributes. The attributes to be included in the Label Mapping message.
- 赞词。要包含在标签映射消息中的属性。
- IsPropagating. The LSR is sending the Label Mapping message to propagate one received from the FEC next hop.
- 我正在广播。LSR正在发送标签映射消息，以传播从FEC下一跳接收到的标签映射消息。
- PrevHopCount. The Hop Count, if any, this LSR associates with the LSP for the FEC.
- 普雷霍普伯爵。该LSR与FEC的LSP关联的跃点计数（如果有）。
Additional Context:
其他背景：
- LSR Id. The unique LSR Id of this LSR.
- LSR Id。此LSR的唯一LSR Id。
Algorithm:
算法：
PMpA.1 Is Hop Count required for this Peer (see Note 1.) ? OR Do RAttributes include a Hop Count? OR Is Loop Detection configured on LSR? If not, goto PMpA.21.
PMpA.1该对等机是否需要跃点计数（见注1）？或者RAttributes是否包含跃点计数？还是在LSR上配置了环路检测？如果没有，转到PMpA.21。
PMpA.2 Is LSR egress for FEC? If not, goto PMpA.4.
PMpA.2是FEC的LSR出口吗？如果没有，转到PMpA.4。
PMpA.3 Include Hop Count of 1 in SAttributes. Goto PMpA.21.
PMpA.3包括SAT属性中1的跃点计数。转到PMpA.21。
PMpA.4 Do RAttributes have a Hop Count? If not, goto PMpA.8.
PMpA.4 RAttributes是否有跃点计数？如果没有，请转到PMpA.8。
PMpA.5 Is LSR member of edge set for an LSR domain whose LSRs do not perform TTL decrement AND Is Peer in that domain (See Note 2.). If not, goto PMpA.7.
PMpA.5是LSR域的边集的LSR成员，该域的LSR不执行TTL减量，并且是该域中的对等方（见注2）。如果没有，请转到PMpA.7。
PMpA.6 Include Hop Count of 1 in SAttributes. Goto PMpA.9.
PMpA.6包括SAT属性中1的跃点计数。转到PMpA.9。
PMpA.7 Increment RAttributes Hop Count and copy the resulting Hop Count to SAttributes. See Note 2. Goto PMpA.9.
PMpA.7增加RAttributes跃点计数，并将结果跃点计数复制到SAttributes。见注2。转到PMpA.9。
PMpA.8 Include Hop Count of unknown (0) in SAttributes.
PMpA.8包括SAT属性中未知（0）的跃点计数。
PMpA.9 Is Loop Detection configured on LSR? If not, goto PMpA.21.
PMpA.9是否在LSR上配置了环路检测？如果没有，转到PMpA.21。
PMpA.10 Do RAttributes have a Path Vector? If so, goto PMpA.19.
PMpA.10 RAttributes是否有路径向量？如果是，请转到PMpA.19。
PMpA.11 Is LSR propagating a received Label Mapping? If not, goto PMpA.20.
PMpA.11 LSR是否传播接收到的标签映射？如果没有，请转到PMpA.20。
PMpA.12 Does LSR support merging? If not, goto PMpA.14.
PMpA.12 LSR是否支持合并？如果没有，请转到PMpA.14。
PMpA.13 Has LSR previously sent a Label Mapping for FEC to Peer? If not, goto PMpA.20.
PMpA.13 LSR之前是否向对等方发送FEC的标签映射？如果没有，请转到PMpA.20。
PMpA.14 Do RAttributes include a Hop Count? If not, goto PMpA.21.
PMpA.14 RAttributes是否包含跃点计数？如果没有，转到PMpA.21。
PMpA.15 Is Hop Count in Rattributes unknown(0)? If so, goto PMpA.20.
PMpA.15 Rattributes中的跃点计数未知（0）？如果是，请转到PMpA.20。
PMpA.16 Has LSR previously sent a Label Mapping for FEC to Peer? If not goto PMpA.21.
PMpA.16 LSR之前是否向对等方发送FEC的标签映射？如果没有，请转到PMpA.21。
PMpA.17 Is Hop Count in RAttributes different from PrevHopCount ? If not goto PMpA.21.
PMpA.17 RAttributes中的跃点计数是否与PrevHopCount不同？如果没有，请转到PMpA.21。
PMpA.18 Is the Hop Count in RAttributes > PrevHopCount? OR Is PrevHopCount unknown(0) If not, goto PMpA.21.
PMpA.18 RAttributes>PrevHopCount中的跃点计数是多少？或者PrevHopCount未知（0），如果不未知，转到PMpA.21。
PMpA.19 Add LSR Id to beginning of Path Vector from RAttributes and copy the resulting Path Vector into SAttributes. Goto PMpA.21.
PMpA.19将LSR Id添加到RAttributes路径向量的开头，并将生成的路径向量复制到SAttributes中。转到PMpA.21。
PMpA.20 Include Path Vector of length 1 containing LSR Id in SAttributes.
PMpA.20包括长度为1的路径向量，其中包含SAT属性中的LSR Id。
PMpA.21 DONE.
PMpA.21完成。
Notes:
笔记：
1. The link with Peer may require that Hop Count be included in Label Mapping messages; for example, see [RFC3035] and [RFC3034].
1. 与对等方的链路可能要求在标签映射消息中包括跳数；例如，请参见[RFC3035]和[RFC3034]。
2. If the LSR is at the edge of a cloud of LSRs that do not perform TTL-decrement and it is propagating the Label Mapping message upstream into the cloud, it sets the Hop Count to 1 so that Hop Count across the cloud is calculated properly. This ensures proper TTL management for packets forwarded across the part of the LSP that passes through the cloud.
2. 如果LSR位于不执行TTL递减的LSR云的边缘，并且它正在向上游向云中传播标签映射消息，则它将跃点计数设置为1，以便正确计算整个云中的跃点计数。这确保对通过云的LSP部分转发的数据包进行适当的TTL管理。
3. For hop count arithmetic, unknown + 1 = unknown.
3. 对于跃点计数算法，未知+1=未知。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。