Network Working Group J. Lang, Ed.
Request for Comments: 4204 Sonos, Inc.
Category: Standards Track October 2005
Network Working Group J. Lang, Ed.
Request for Comments: 4204 Sonos, Inc.
Category: Standards Track October 2005
Link Management Protocol (LMP)
链路管理协议（LMP）
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks.
出于可伸缩性的目的，可以将多个数据链路组合成一个流量工程（TE）链路。此外，TE链路的管理不限于带内消息传递，而是可以使用带外技术来完成。本文档指定了在一对节点之间运行的链路管理协议（LMP），用于管理TE链路。具体而言，LMP将用于维护控制通道连接、验证数据链路的物理连接、关联链路属性信息、抑制下游警报以及定位链路故障，以便在多种网络中进行保护/恢复。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................5
2. LMP Overview ....................................................6
3. Control Channel Management ......................................8
3.1. Parameter Negotiation ......................................9
3.2. Hello Protocol ............................................10
4. Link Property Correlation ......................................13
5. Verifying Link Connectivity ....................................15
5.1. Example of Link Connectivity Verification .................18
6. Fault Management ...............................................19
6.1. Fault Detection ...........................................20
6.2. Fault Localization Procedure ..............................20
6.3. Examples of Fault Localization ............................21
1. Introduction ....................................................3
1.1. Terminology ................................................5
2. LMP Overview ....................................................6
3. Control Channel Management ......................................8
3.1. Parameter Negotiation ......................................9
3.2. Hello Protocol ............................................10
4. Link Property Correlation ......................................13
5. Verifying Link Connectivity ....................................15
5.1. Example of Link Connectivity Verification .................18
6. Fault Management ...............................................19
6.1. Fault Detection ...........................................20
6.2. Fault Localization Procedure ..............................20
6.3. Examples of Fault Localization ............................21
6.4. Channel Activation Indication .............................22
6.5. Channel Deactivation Indication ...........................23
7. Message_Id Usage ...............................................23
8. Graceful Restart ...............................................24
9. Addressing .....................................................25
10. Exponential Back-off Procedures ...............................26
10.1. Operation ...............................................26
10.2. Retransmission Algorithm ................................27
11. LMP Finite State Machines .....................................28
11.1. Control Channel FSM .....................................28
11.2. TE Link FSM .............................................32
11.3. Data Link FSM ...........................................34
12. LMP Message Formats ...........................................38
12.1. Common Header ...........................................39
12.2. LMP Object Format .......................................41
12.3. Parameter Negotiation Messages ..........................42
12.4. Hello Message (Msg Type = 4) ............................43
12.5. Link Verification Messages ..............................43
12.6. Link Summary Messages ...................................47
12.7. Fault Management Messages ...............................49
13. LMP Object Definitions ........................................50
13.1. CCID (Control Channel ID) Class .........................50
13.2. NODE_ID Class ...........................................51
13.3. LINK_ID Class ...........................................52
13.4. INTERFACE_ID Class ......................................53
13.5. MESSAGE_ID Class ........................................54
13.6. CONFIG Class ............................................55
13.7. HELLO Class .............................................56
13.8. BEGIN_VERIFY Class ......................................56
13.9. BEGIN_VERIFY_ACK Class ..................................58
13.10. VERIFY_ID Class ........................................59
13.11. TE_LINK Class ..........................................59
13.12. DATA_LINK Class ........................................61
13.13. CHANNEL_STATUS Class ...................................65
13.14. CHANNEL_STATUS_REQUEST Class ...........................68
13.15. ERROR_CODE Class .......................................70
14. References ....................................................71
14.1. Normative References ....................................71
14.2. Informative References ..................................72
15. Security Considerations .......................................73
15.1. Security Requirements ...................................73
15.2. Security Mechanisms .....................................74
16. IANA Considerations ...........................................76
17. Acknowledgements ..............................................83
18. Contributors ..................................................83
6.4. Channel Activation Indication .............................22
6.5. Channel Deactivation Indication ...........................23
7. Message_Id Usage ...............................................23
8. Graceful Restart ...............................................24
9. Addressing .....................................................25
10. Exponential Back-off Procedures ...............................26
10.1. Operation ...............................................26
10.2. Retransmission Algorithm ................................27
11. LMP Finite State Machines .....................................28
11.1. Control Channel FSM .....................................28
11.2. TE Link FSM .............................................32
11.3. Data Link FSM ...........................................34
12. LMP Message Formats ...........................................38
12.1. Common Header ...........................................39
12.2. LMP Object Format .......................................41
12.3. Parameter Negotiation Messages ..........................42
12.4. Hello Message (Msg Type = 4) ............................43
12.5. Link Verification Messages ..............................43
12.6. Link Summary Messages ...................................47
12.7. Fault Management Messages ...............................49
13. LMP Object Definitions ........................................50
13.1. CCID (Control Channel ID) Class .........................50
13.2. NODE_ID Class ...........................................51
13.3. LINK_ID Class ...........................................52
13.4. INTERFACE_ID Class ......................................53
13.5. MESSAGE_ID Class ........................................54
13.6. CONFIG Class ............................................55
13.7. HELLO Class .............................................56
13.8. BEGIN_VERIFY Class ......................................56
13.9. BEGIN_VERIFY_ACK Class ..................................58
13.10. VERIFY_ID Class ........................................59
13.11. TE_LINK Class ..........................................59
13.12. DATA_LINK Class ........................................61
13.13. CHANNEL_STATUS Class ...................................65
13.14. CHANNEL_STATUS_REQUEST Class ...........................68
13.15. ERROR_CODE Class .......................................70
14. References ....................................................71
14.1. Normative References ....................................71
14.2. Informative References ..................................72
15. Security Considerations .......................................73
15.1. Security Requirements ...................................73
15.2. Security Mechanisms .....................................74
16. IANA Considerations ...........................................76
17. Acknowledgements ..............................................83
18. Contributors ..................................................83
Networks are being developed with routers, switches, crossconnects, dense wavelength division multiplexed (DWDM) systems, and add-drop multiplexors (ADMs) that use a common control plane, e.g., Generalized MPLS (GMPLS), to dynamically allocate resources and to provide network survivability using protection and restoration techniques. A pair of nodes may have thousands of interconnects, where each interconnect may consist of multiple data links when multiplexing (e.g., Frame Relay DLCIs at Layer 2, time division multiplexed (TDM) slots or wavelength division multiplexed (WDM) wavelengths at Layer 1) is used. For scalability purposes, multiple data links may be combined into a single traffic-engineering (TE) link.
目前正在利用路由器、交换机、交叉连接、密集波分复用（DWDM）系统和使用通用控制平面（如通用MPLS（GMPLS））的分插复用器（ADM）开发网络，以动态分配资源，并使用保护和恢复技术提供网络生存能力。一对节点可具有数千个互连，其中当使用多路复用（例如，第2层的帧中继DLCI、第1层的时分多路复用（TDM）时隙或波分多路复用（WDM）波长）时，每个互连可由多个数据链路组成。出于可伸缩性目的，多个数据链路可以组合成单个流量工程（TE）链路。
To enable communication between nodes for routing, signaling, and link management, there must be a pair of IP interfaces that are mutually reachable. We call such a pair of interfaces a control channel. Note that "mutually reachable" does not imply that these two interfaces are (directly) connected by an IP link; there may be an IP network between the two. Furthermore, the interface over which the control messages are sent/received may not be the same interface over which the data flows. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links and verify reachability of the control channel. For the purposes of this document, such nodes are considered "LMP neighbors" or simply "neighboring nodes".
为了实现节点之间的路由、信令和链路管理通信，必须有一对相互可访问的IP接口。我们把这样一对接口称为控制通道。注意，“相互可达”并不意味着这两个接口（直接）通过IP链路连接；两者之间可能有一个IP网络。此外，发送/接收控制消息的接口可能不是数据流通过的相同接口。本文件规定了在一对节点之间运行的链路管理协议（LMP），用于管理TE链路和验证控制信道的可达性。在本文件中，此类节点被视为“LMP邻居”或简称为“邻居节点”。
In GMPLS, the control channels between two adjacent nodes are no longer required to use the same physical medium as the data links between those nodes. For example, a control channel could use a separate virtual circuit, wavelength, fiber, Ethernet link, an IP tunnel routed over a separate management network, or a multi-hop IP network. A consequence of allowing the control channel(s) between two nodes to be logically or physically diverse from the associated data links is that the health of a control channel does not necessarily correlate to the health of the data links, and vice-versa. Therefore, a clean separation between the fate of the control channel and data links must be made. New mechanisms must be developed to manage the data links, both in terms of link provisioning and fault management.
在GMPLS中，两个相邻节点之间的控制信道不再需要使用与这些节点之间的数据链路相同的物理介质。例如，控制通道可以使用单独的虚拟电路、波长、光纤、以太网链路、通过单独的管理网络路由的IP隧道或多跳IP网络。允许两个节点之间的控制信道在逻辑上或物理上与相关联的数据链路不同的结果是，控制信道的健康不一定与数据链路的健康相关，反之亦然。因此，必须在控制通道和数据链路的命运之间进行清晰的分离。必须开发新的机制来管理数据链路，包括链路供应和故障管理。
Among the tasks that LMP accomplishes is checking that the grouping of links into TE links, as well as the properties of those links, are the same at both end points of the links -- this is called "link property correlation". Also, LMP can communicate these link properties to the IGP module, which can then announce them to other
LMP完成的任务之一是检查将链接分组为TE链接以及这些链接的属性在链接的两个端点处是否相同，这称为“链接属性相关性”。此外，LMP可以将这些链路属性传送给IGP模块，然后IGP模块可以将它们通知其他模块
nodes in the network. LMP can also tell the signaling module the mapping between TE links and control channels. Thus, LMP performs a valuable "glue" function in the control plane.
网络中的节点。LMP还可以告诉信令模块TE链路和控制信道之间的映射。因此，LMP在控制平面中执行有价值的“粘合”功能。
Note that while the existence of the control network (single or multi-hop) is necessary for enabling communication, it is by no means sufficient. For example, if the two interfaces are separated by an IP network, faults in the IP network may result in the lack of an IP path from one interface to another, and therefore an interruption of communication between the two interfaces. On the other hand, not every failure in the control network affects a given control channel, hence the need for establishing and managing control channels.
注意，尽管控制网络（单跳或多跳）的存在对于启用通信是必要的，但这绝对不够。例如，如果两个接口由IP网络分隔，则IP网络中的故障可能导致缺少从一个接口到另一个接口的IP路径，因此两个接口之间的通信中断。另一方面，并非控制网络中的所有故障都会影响给定的控制通道，因此需要建立和管理控制通道。
For the purposes of this document, a data link may be considered by each node that it terminates on as either a 'port' or a 'component link', depending on the multiplexing capability of the endpoint on that link; component links are multiplex capable, whereas ports are not multiplex capable. This distinction is important since the management of such links (including, for example, resource allocation, label assignment, and their physical verification) is different based on their multiplexing capability. For example, a Frame Relay switch is able to demultiplex an interface into virtual circuits based on DLCIs; similarly, a SONET crossconnect with OC-192 interfaces may be able to demultiplex the OC-192 stream into four OC-48 streams. If multiple interfaces are grouped together into a single TE link using link bundling [RFC4201], then the link resources must be identified using three levels: Link_Id, component interface Id, and label identifying virtual circuit, timeslot, etc. Resource allocation happens at the lowest level (labels), but physical connectivity happens at the component link level. As another example, consider the case where an optical switch (e.g., PXC) transparently switches OC-192 lightpaths. If multiple interfaces are once again grouped together into a single TE link, then link bundling [RFC4201] is not required and only two levels of identification are required: Link_Id and Port_Id. In this case, both resource allocation and physical connectivity happen at the lowest level (i.e., port level).
就本文件而言，数据链路可被其终止的每个节点视为“端口”或“组件链路”，具体取决于该链路上端点的复用能力；组件链路支持多路复用，而端口不支持多路复用。这种区别很重要，因为此类链路的管理（例如，包括资源分配、标签分配及其物理验证）根据其复用能力而不同。例如，帧中继交换机能够基于DLCI将接口解复用为虚拟电路；类似地，具有OC-192接口的SONET交叉连接可以将OC-192流解复用为四个OC-48流。如果使用链路捆绑[RFC4201]将多个接口组合到一个TE链路中，则必须使用三个级别来标识链路资源：链路Id、组件接口Id和标识虚拟电路、时隙等的标签。资源分配发生在最低级别（标签），但物理连接发生在组件链接级别。作为另一个例子，考虑光开关（例如，PXC）透明地切换OC-192光路的情况。如果多个接口再次组合到一个TE链路中，则不需要链路捆绑[RFC4201]，只需要两个级别的标识：链路Id和端口Id。在这种情况下，资源分配和物理连接都发生在最低级别（即端口级别）。
To ensure interworking between data links with different multiplexing capabilities, LMP-capable devices SHOULD allow sub-channels of a component link to be locally configured as (logical) data links. For example, if a Router with 4 OC-48 interfaces is connected through a 4:1 MUX to a cross-connect with OC-192 interfaces, the cross-connect should be able to configure each sub-channel (e.g., STS-48c SPE if the 4:1 MUX is a SONET MUX) as a data link.
为确保具有不同复用能力的数据链路之间的互通，支持LMP的设备应允许将组件链路的子信道本地配置为（逻辑）数据链路。例如，如果具有4个OC-48接口的路由器通过4:1 MUX连接到具有OC-192接口的交叉连接，则交叉连接应能够将每个子信道（例如，如果4:1 MUX是SONET MUX，则为STS-48c SPE）配置为数据链路。
LMP is designed to support aggregation of one or more data links into a TE link (either ports into TE links, or component links into TE links). The purpose of forming a TE link is to group/map the information about certain physical resources (and their properties) into the information that is used by Constrained SPF for the purpose of path computation, and by GMPLS signaling.
LMP设计用于支持将一个或多个数据链路聚合为TE链路（将端口聚合为TE链路，或将组件链路聚合为TE链路）。形成TE链路的目的是将关于特定物理资源（及其属性）的信息分组/映射到由受限SPF用于路径计算的信息中，以及通过GMPLS信令。
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]中所述进行解释。
The reader is assumed to be familiar with the terminology in [RFC3471], [RFC4202], and [RFC4201].
假定读者熟悉[RFC3471]、[RFC4202]和[RFC4201]中的术语。
Bundled Link:
捆绑链接：
As defined in [RFC4201], a bundled link is a TE link such that, for the purpose of GMPLS signaling, a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resources used by an LSP. A bundled link is composed of two or more component links.
如[RFC4201]中所定义，捆绑链路是TE链路，因此，为了GMPLS信令的目的，<link identifier，label>的组合不足以明确标识LSP使用的适当资源。捆绑链接由两个或多个组件链接组成。
Control Channel:
控制通道：
A control channel is a pair of mutually reachable interfaces that are used to enable communication between nodes for routing, signaling, and link management.
控制信道是一对相互可到达的接口，用于实现节点之间的通信，以进行路由、信令和链路管理。
Component Link:
组件链接：
As defined in [RFC4201], a component link is a subset of resources of a TE Link such that (a) the partition is minimal, and (b) within each subset a label is sufficient to unambiguously identify the appropriate resources used by an LSP.
如[RFC4201]中所定义，组件链路是TE链路的资源子集，因此（a）分区最小，并且（b）在每个子集内，标签足以明确标识LSP使用的适当资源。
Data Link:
数据链路：
A data link is a pair of interfaces that are used to transfer user data. Note that in GMPLS, the control channel(s) between two adjacent nodes are no longer required to use the same physical medium as the data links between those nodes.
数据链路是用于传输用户数据的一对接口。注意，在GMPLS中，两个相邻节点之间的控制信道不再需要使用与这些节点之间的数据链路相同的物理介质。
Link Property Correlation:
链接属性相关性：
This is a procedure to correlate the local and remote properties of a TE link.
这是一个关联TE链路的本地和远程属性的过程。
Multiplex Capability:
多路传输能力：
The ability to multiplex/demultiplex a data stream into sub-rate streams for switching purposes.
为了交换目的，将数据流多路复用/解多路复用为子速率流的能力。
Node_Id:
节点Id:
For a node running OSPF, the LMP Node_Id is the same as the address contained in the OSPF Router Address TLV. For a node running IS-IS and advertising the TE Router ID TLV, the Node_Id is the same as the advertised Router ID.
对于运行OSPF的节点，LMP node_Id与OSPF路由器地址TLV中包含的地址相同。对于运行IS-IS并公布TE路由器ID TLV的节点，节点_ID与公布的路由器ID相同。
Port:
端口：
An interface that terminates a data link.
终止数据链路的接口。
TE Link:
TE链接：
As defined in [RFC4202], a TE link is a logical construct that represents a way to group/map the information about certain physical resources (and their properties) that interconnect LSRs into the information that is used by Constrained SPF for the purpose of path computation, and by GMPLS signaling.
如[RFC4202]中所定义，TE链路是一种逻辑结构，表示将某些物理资源（及其属性）的相关信息分组/映射到受约束SPF用于路径计算和GMPLS信令的信息中的方法。
Transparent:
透明的：
A device is called X-transparent if it forwards incoming signals from input to output without examining or modifying the X aspect of the signal. For example, a Frame Relay switch is network-layer transparent; an all-optical switch is electrically transparent.
如果设备将输入信号从输入转发到输出，而不检查或修改信号的X方向，则称为X透明设备。例如，帧中继交换机是网络层透明的；全光开关是电透明的。
The two core procedures of LMP are control channel management and link property correlation. Control channel management is used to establish and maintain control channels between adjacent nodes. This is done using a Config message exchange and a fast keep-alive mechanism between the nodes. The latter is required if lower-level mechanisms are not available to detect control channel failures. Link property correlation is used to synchronize the TE link properties and verify the TE link configuration.
LMP的两个核心过程是控制信道管理和链路属性关联。控制通道管理用于在相邻节点之间建立和维护控制通道。这是通过在节点之间使用配置消息交换和快速保持活动机制来完成的。如果无法使用较低级别的机制来检测控制通道故障，则需要后者。链接属性关联用于同步TE链接属性和验证TE链接配置。
LMP requires that a pair of nodes have at least one active bi-directional control channel between them. Each direction of the control channel is identified by a Control Channel Id (CC_Id), and the two directions are coupled together using the LMP Config message exchange. Except for Test messages, which may be limited by the
LMP要求一对节点之间至少有一个活动的双向控制信道。控制信道的每个方向由控制信道Id（CC_Id）标识，并且使用LMP Config消息交换将两个方向耦合在一起。测试消息除外，测试消息可能受
transport mechanism for in-band messaging, all LMP packets are run over UDP with an LMP port number. The link level encoding of the control channel is outside the scope of this document.
对于带内消息传递的传输机制，所有LMP数据包都通过具有LMP端口号的UDP运行。控制通道的链路级编码不在本文档范围内。
An "LMP adjacency" is formed between two nodes when at least one bi-directional control channel is established between them. Multiple control channels may be active simultaneously for each adjacency; control channel parameters, however, MUST be individually negotiated for each control channel. If the LMP fast keep-alive is used over a control channel, LMP Hello messages MUST be exchanged over the control channel. Other LMP messages MAY be transmitted over any of the active control channels between a pair of adjacent nodes. One or more active control channels may be grouped into a logical control channel for signaling, routing, and link property correlation purposes.
当在两个节点之间建立至少一个双向控制信道时，在两个节点之间形成“LMP邻接”。对于每个邻接，多个控制信道可以同时激活；但是，必须为每个控制通道单独协商控制通道参数。如果通过控制通道使用LMP fast keep alive，则必须通过控制通道交换LMP Hello消息。其他LMP消息可以在一对相邻节点之间的任何主动控制信道上传输。一个或多个活动控制信道可被分组到逻辑控制信道中，用于信令、路由和链路属性相关目的。
The link property correlation function of LMP is designed to aggregate multiple data links (ports or component links) into a TE link and to synchronize the properties of the TE link. As part of the link property correlation function, a LinkSummary message exchange is defined. The LinkSummary message includes the local and remote Link_Ids, a list of all data links that comprise the TE link, and various link properties. A LinkSummaryAck or LinkSummaryNack message MUST be sent in response to the receipt of a LinkSummary message indicating agreement or disagreement on the link properties.
LMP的链路特性相关函数用于将多个数据链路（端口或组件链路）聚合为TE链路，并同步TE链路的特性。作为链接属性关联函数的一部分，定义了链接摘要消息交换。LinkSummary消息包括本地和远程链路ID、组成TE链路的所有数据链路的列表以及各种链路属性。必须发送LinkSummaryAck或LinkSummaryNack消息以响应接收到的LinkSummary消息，该消息表示对链接属性的同意或不同意。
LMP messages are transmitted reliably using Message_Ids and retransmissions. Message_Ids are carried in MESSAGE_ID objects. No more than one MESSAGE_ID object may be included in an LMP message. For control-channel-specific messages, the Message_Id is within the scope of the control channel over which the message is sent. For TE-link-specific messages, the Message_Id is within the scope of the LMP adjacency. The value of the Message_Id is monotonically increasing and wraps when the maximum value is reached.
使用消息ID和重传可靠地传输LMP消息。消息ID携带在消息ID对象中。LMP消息中不能包含多个消息\u ID对象。对于控制通道特定的消息，消息_Id在发送消息的控制通道的范围内。对于TE链路特定消息，消息_Id在LMP邻接的范围内。消息_Id的值单调递增，并在达到最大值时换行。
In this document, two additional LMP procedures are defined: link connectivity verification and fault management. These procedures are particularly useful when the control channels are physically diverse from the data links. Link connectivity verification is used for data plane discovery, Interface_Id exchange (Interface_Ids are used in GMPLS signaling, either as port labels or component link identifiers, depending on the configuration), and physical connectivity verification. This is done by sending Test messages over the data links and TestStatus messages back over the control channel. Note that the Test message is the only LMP message that must be transmitted over the data link. The ChannelStatus message exchange is used between adjacent nodes for both the suppression of downstream alarms and the localization of faults for protection and restoration.
在本文件中，定义了两个额外的LMP程序：链路连接验证和故障管理。当控制通道与数据链路在物理上不同时，这些程序特别有用。链路连接验证用于数据平面发现、接口Id交换（接口Id在GMPLS信令中用作端口标签或组件链路标识符，具体取决于配置）和物理连接验证。这是通过在数据链路上发送测试消息和在控制通道上返回测试状态消息来完成的。请注意，测试消息是必须通过数据链路传输的唯一LMP消息。相邻节点之间的ChannelStatus消息交换用于抑制下游警报和定位故障以进行保护和恢复。
For LMP link connectivity verification, the Test message is transmitted over the data links. For X-transparent devices, this requires examining and modifying the X aspect of the signal. The LMP link connectivity verification procedure is coordinated using a BeginVerify message exchange over a control channel. To support various aspects of transparency, a Verify Transport Mechanism is included in the BeginVerify and BeginVerifyAck messages. Note that there is no requirement that all data links must lose their transparency simultaneously; but, at a minimum, it must be possible to terminate them one at a time. There is also no requirement that the control channel and TE link use the same physical medium; however, the control channel MUST be terminated by the same two control elements that control the TE link. Since the BeginVerify message exchange coordinates the Test procedure, it also naturally coordinates the transition of the data links in and out of the transparent mode.
对于LMP链路连接验证，测试消息通过数据链路传输。对于X-透明设备，这需要检查和修改信号的X方向。LMP链路连接验证程序通过控制信道上的BeginVerify消息交换进行协调。为了支持透明度的各个方面，在BeginVerify和BeginVerifyAck消息中包含了验证传输机制。请注意，没有要求所有数据链接必须同时失去其透明度；但是，至少，必须能够一次一个地终止它们。也不要求控制信道和TE链路使用相同的物理介质；但是，控制信道必须由控制TE链路的相同两个控制元件终止。由于BeginVerify消息交换协调了测试过程，因此它也自然地协调了透明模式中数据链路的转换。
The LMP fault management procedure is based on a ChannelStatus message exchange that uses the following messages: ChannelStatus, ChannelStatusAck, ChannelStatusRequest, and ChannelStatusResponse. The ChannelStatus message is sent unsolicited and is used to notify an LMP neighbor about the status of one or more data channels of a TE link. The ChannelStatusAck message is used to acknowledge receipt of the ChannelStatus message. The ChannelStatusRequest message is used to query an LMP neighbor for the status of one or more data channels of a TE Link. The ChannelStatusResponse message is used to acknowledge receipt of the ChannelStatusRequest message and indicate the states of the queried data links.
LMP故障管理程序基于使用以下消息的ChannelStatus消息交换：ChannelStatus、ChannelStatusAck、ChannelStatusRequest和ChannelStatusResponse。ChannelStatus消息是非请求发送的，用于通知LMP邻居TE链路的一个或多个数据信道的状态。ChannelStatusAck消息用于确认收到ChannelStatus消息。ChannelStatusRequest消息用于向LMP邻居查询TE链路的一个或多个数据信道的状态。ChannelStatusResponse消息用于确认收到ChannelStatusRequest消息，并指示所查询数据链路的状态。
To initiate an LMP adjacency between two nodes, one or more bi-directional control channels MUST be activated. The control channels can be used to exchange control-plane information such as link provisioning and fault management information (implemented using a messaging protocol such as LMP, proposed in this document), path management and label distribution information (implemented using a signaling protocol such as RSVP-TE [RFC3209]), and network topology and state distribution information (implemented using traffic engineering extensions of protocols such as OSPF [RFC3630] and IS-IS [RFC3784]).
为了在两个节点之间发起LMP邻接，必须激活一个或多个双向控制信道。控制信道可用于交换控制平面信息，例如链路供应和故障管理信息（使用本文件中提出的诸如LMP的消息传递协议实现）、路径管理和标签分发信息（使用诸如RSVP-TE[RFC3209]的信令协议实现），以及网络拓扑和状态分布信息（使用诸如OSPF[RFC3630]和IS-IS[RFC3784]等协议的流量工程扩展实现）。
For the purposes of LMP, the exact implementation of the control channel is not specified; it could be, for example, a separate wavelength or fiber, an Ethernet link, an IP tunnel through a separate management network, or the overhead bytes of a data link. Each node assigns a node-wide, unique, 32-bit, non-zero integer control channel identifier (CC_Id). This identifier comes from the
出于LMP的目的，未规定控制信道的精确实现；例如，它可以是单独的波长或光纤、以太网链路、通过单独的管理网络的IP隧道或数据链路的开销字节。每个节点分配一个节点范围内唯一的32位非零整数控制信道标识符（CC_Id）。此标识符来自
same space as the unnumbered interface Id. Furthermore, LMP packets are run over UDP with an LMP port number. Thus, the link level encoding of the control channel is not part of the LMP specification.
与未编号的接口Id相同的空间。此外，LMP数据包通过具有LMP端口号的UDP运行。因此，控制信道的链路级编码不是LMP规范的一部分。
To establish a control channel, the destination IP address on the far end of the control channel must be known. This knowledge may be manually configured or automatically discovered. Note that for in-band signaling, a control channel could be explicitly configured on a particular data link. In this case, the Config message exchange can be used to dynamically learn the IP address on the far end of the control channel. This is done by sending the Config message with the unicast IP source address and the multicast IP destination address (224.0.0.1 or ff02::1). The ConfigAck and ConfigNack messages MUST be sent to the source IP address found in the IP header of the received Config message.
要建立控制通道，必须知道控制通道远端的目标IP地址。这些知识可以手动配置或自动发现。注意，对于带内信令，可以在特定数据链路上显式配置控制信道。在这种情况下，配置消息交换可用于动态了解控制通道远端的IP地址。这是通过发送带有单播IP源地址和多播IP目标地址（224.0.0.1或ff02:：1）的配置消息来完成的。ConfigAck和ConfigNack消息必须发送到接收到的配置消息的IP头中找到的源IP地址。
Control channels exist independently of TE links and multiple control channels may be active simultaneously between a pair of nodes. Individual control channels can be realized in different ways; one might be implemented in-fiber while another one may be implemented out-of-fiber. As such, control channel parameters MUST be negotiated over each individual control channel, and LMP Hello packets MUST be exchanged over each control channel to maintain LMP connectivity if other mechanisms are not available. Since control channels are electrically terminated at each node, it may be possible to detect control channel failures using lower layers (e.g., SONET/SDH).
控制信道独立于TE链路而存在，并且多个控制信道可以在一对节点之间同时处于活动状态。单独的控制通道可以以不同的方式实现；一个可以在光纤中实现，而另一个可以在光纤外实现。因此，必须在每个单独的控制信道上协商控制信道参数，并且必须在每个控制信道上交换LMP Hello分组，以在其他机制不可用的情况下保持LMP连接性。由于控制信道在每个节点处电端接，因此可以使用较低的层（例如SONET/SDH）检测控制信道故障。
There are four LMP messages that are used to manage individual control channels. They are the Config, ConfigAck, ConfigNack, and Hello messages. These messages MUST be transmitted on the channel to which they refer. All other LMP messages may be transmitted over any of the active control channels between a pair of LMP adjacent nodes.
有四条LMP消息用于管理各个控制通道。它们是Config、ConfigAck、ConfigNack和Hello消息。这些信息必须在它们所指的信道上传输。所有其他LMP消息可以在一对LMP相邻节点之间通过任何主动控制信道传输。
In order to maintain an LMP adjacency, it is necessary to have at least one active control channel between a pair of adjacent nodes (recall that multiple control channels can be active simultaneously between a pair of nodes). In the event of a control channel failure, alternate active control channels can be used and it may be possible to activate additional control channels as described below.
为了保持LMP邻接，必须在一对相邻节点之间具有至少一个活动控制信道（回想一下，在一对节点之间可以同时活动多个控制信道）。在控制通道发生故障的情况下，可以使用备用的主动控制通道，并且可以如下所述激活其他控制通道。
Control channel activation begins with a parameter negotiation exchange using Config, ConfigAck, and ConfigNack messages. The contents of these messages are built using LMP objects, which can be either negotiable or non-negotiable (identified by the N bit in the object header). Negotiable objects can be used to let LMP peers
控制通道激活从使用Config、ConfigAck和ConfigNack消息的参数协商交换开始。这些消息的内容是使用LMP对象构建的，LMP对象可以是可协商的，也可以是不可协商的（由对象头中的N位标识）。可协商对象可用于让LMP对等点
agree on certain values. Non-negotiable objects are used for the announcement of specific values that do not need, or do not allow, negotiation.
就某些价值达成一致。不可转让物品用于宣布不需要或不允许协商的特定价值。
To activate a control channel, a Config message MUST be transmitted to the remote node, and in response, a ConfigAck message MUST be received at the local node. The Config message contains the Local Control Channel Id (CC_Id), the sender's Node_Id, a Message_Id for reliable messaging, and a CONFIG object. It is possible that both the local and remote nodes initiate the configuration procedure at the same time. To avoid ambiguities, the node with the higher Node_Id wins the contention; the node with the lower Node_Id MUST stop transmitting the Config message and respond to the Config message it received. If the Node_Ids are equal, then one (or both) nodes have been misconfigured. The nodes MAY continue to retransmit Config messages in hopes that the misconfiguration is corrected. Note that the problem may be solved by an operator changing the Node_Ids on one or both nodes.
要激活控制通道，必须向远程节点发送配置消息，作为响应，必须在本地节点接收配置确认消息。配置消息包含本地控制通道Id（CC_Id）、发送方的节点Id、用于可靠消息传递的消息Id和配置对象。本地和远程节点可能同时启动配置过程。为避免歧义，具有较高节点_Id的节点赢得争用；具有较低node_Id的节点必须停止传输配置消息，并响应其接收到的配置消息。如果节点ID相等，则一个（或两个）节点配置错误。节点可能会继续重新传输配置消息，希望错误配置得到纠正。请注意，操作员可以通过更改一个或两个节点上的节点ID来解决此问题。
The ConfigAck message is used to acknowledge receipt of the Config message and express agreement on ALL of the configured parameters (both negotiable and non-negotiable).
ConfigAck消息用于确认收到Config消息，并对所有配置参数（可协商和不可协商）表示同意。
The ConfigNack message is used to acknowledge receipt of the Config message, indicate which (if any) non-negotiable CONFIG objects are unacceptable, and to propose alternate values for the negotiable parameters.
ConfigNack消息用于确认收到配置消息，指示哪些（如果有）不可协商的配置对象是不可接受的，并为可协商的参数提出替代值。
If a node receives a ConfigNack message with acceptable alternate values for negotiable parameters, the node SHOULD transmit a Config message using these values for those parameters.
如果节点接收到具有可协商参数的可接受备选值的ConfigNack消息，则该节点应使用这些参数值发送配置消息。
If a node receives a ConfigNack message with unacceptable alternate values, the node MAY continue to retransmit Config messages in hopes that the misconfiguration is corrected. Note that the problem may be solved by an operator changing parameters on one or both nodes.
如果节点接收到具有不可接受的备用值的ConfigNack消息，则该节点可能会继续重新传输配置消息，以期纠正错误配置。请注意，该问题可以通过操作员更改一个或两个节点上的参数来解决。
In the case where multiple control channels use the same physical interface, the parameter negotiation exchange is performed for each control channel. The various LMP parameter negotiation messages are associated with their corresponding control channels by their node-wide unique identifiers (CC_Ids).
在多个控制信道使用相同物理接口的情况下，对每个控制信道执行参数协商交换。各种LMP参数协商消息通过其节点范围的唯一标识符（CC_id）与其对应的控制信道相关联。
Once a control channel is activated between two adjacent nodes, the LMP Hello protocol can be used to maintain control channel connectivity between the nodes and to detect control channel
一旦两个相邻节点之间的控制信道被激活，LMP Hello协议可用于维持节点之间的控制信道连接并检测控制信道
failures. The LMP Hello protocol is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly so that IGP Hellos are not lost and the associated link-state adjacencies are not removed unnecessarily.
失败。LMP Hello协议旨在成为一种轻量级的保持活动机制，该机制将对控制信道故障做出快速反应，以便IGP Hello不会丢失，并且相关的链路状态邻接不会被不必要地删除。
Before sending Hello messages, the HelloInterval and HelloDeadInterval parameters MUST be agreed upon by the local and remote nodes. These parameters are exchanged in the Config message. The HelloInterval indicates how frequently LMP Hello messages will be sent, and is measured in milliseconds (ms). For example, if the value were 150, then the transmitting node would send the Hello message at least every 150 ms. The HelloDeadInterval indicates how long a device should wait to receive a Hello message before declaring a control channel dead, and is measured in milliseconds (ms).
在发送Hello消息之前，本地和远程节点必须同意HelloInterval和HelloDeadInterval参数。这些参数在配置消息中交换。HelloInterval表示发送LMP Hello消息的频率，以毫秒（ms）为单位。例如，如果该值为150，则发送节点将至少每150毫秒发送一次Hello消息。HelloDeadInterval指示设备在宣布控制通道失效之前应等待多长时间接收Hello消息，并以毫秒（ms）为单位进行测量。
The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval parameters MUST be set to zero.
HelloDeadInterval必须大于HelloInterval，并且至少应为HelloInterval值的3倍。如果不使用LMP的快速保持活动机制，则必须将HelloInterval和HelloDeadInterval参数设置为零。
The values for the HelloInterval and HelloDeadInterval should be selected carefully to provide rapid response time to control channel failures without causing congestion. As such, different values will likely be configured for different control channel implementations. When the control channel is implemented over a directly connected link, the suggested default values for the HelloInterval is 150 ms and for the HelloDeadInterval is 500 ms.
应仔细选择HelloInterval和HelloDeadInterval的值，以提供快速响应时间，从而在不造成拥塞的情况下控制信道故障。因此，可能会为不同的控制通道实现配置不同的值。当通过直接连接的链路实现控制信道时，HelloInterval的建议默认值为150 ms，HelloDedInterval的建议默认值为500 ms。
When a node has either sent or received a ConfigAck message, it may begin sending Hello messages. Once it has sent a Hello message and received a valid Hello message (i.e., with expected sequence numbers; see Section 3.2.2), the control channel moves to the up state. (It is also possible to move to the up state without sending Hellos if other methods are used to indicate bi-directional control-channel connectivity. For example, indication of bi-directional connectivity may be learned from the transport layer.) If, however, a node receives a ConfigNack message instead of a ConfigAck message, the node MUST not send Hello messages and the control channel SHOULD NOT move to the up state. See Section 11.1 for the complete control channel FSM.
当节点发送或接收到ConfigAck消息时，它可能会开始发送Hello消息。一旦发送Hello消息并收到有效的Hello消息（即，具有预期的序列号；参见第3.2.2节），控制信道将移动到向上状态。（如果使用其他方法指示双向控制通道连接，也可以在不发送Hello的情况下移动到up状态。例如，可以从传输层了解双向连接指示。）但是，如果节点接收到ConfigNack消息而不是ConfigAck消息，节点不得发送Hello消息，并且控制通道不应移动到up状态。完整的控制通道FSM见第11.1节。
Each Hello message contains two sequence numbers: the first sequence number (TxSeqNum) is the sequence number for the Hello message being sent and the second sequence number (RcvSeqNum) is the sequence number of the last Hello message received from the adjacent node over this control channel.
每个Hello消息包含两个序列号：第一个序列号（TxSeqNum）是正在发送的Hello消息的序列号，第二个序列号（RcvSeqNum）是通过该控制信道从相邻节点接收的最后一个Hello消息的序列号。
There are two special sequence numbers. TxSeqNum MUST NOT ever be 0. TxSeqNum = 1 is used to indicate that the sender has just started or has restarted and has no recollection of the last TxSeqNum that was sent. Thus, the first Hello sent has a TxSeqNum of 1 and an RxSeqNum of 0. When TxSeqNum reaches (2^32)-1, the next sequence number used is 2, not 0 or 1, as these have special meanings.
有两个特殊的序列号。TxSeqNum永远不能为0。TxSeqNum=1用于指示发送方刚刚启动或重新启动，并且不记得上次发送的TxSeqNum。因此，发送的第一个Hello的TxSeqNum为1，RxSeqNum为0。当TxSeqNum达到（2^32）-1时，下一个使用的序列号是2，而不是0或1，因为它们具有特殊的含义。
Under normal operation, the difference between the RcvSeqNum in a Hello message that is received and the local TxSeqNum that is generated will be at most 1. This difference can be more than one only when a control channel restarts or when the values wrap.
在正常操作下，接收到的Hello消息中的RcvSeqNum与生成的本地TxSeqNum之间的差值最多为1。仅当控制通道重新启动或值换行时，此差异可能不止一个。
Since the 32-bit sequence numbers may wrap, the following expression may be used to test if a newly received TxSeqNum value is less than a previously received value:
由于32位序列号可以换行，因此可以使用以下表达式来测试新接收的TxSeqNum值是否小于先前接收的值：
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}
Having sequence numbers in the Hello messages allows each node to verify that its peer is receiving its Hello messages. By including the RcvSeqNum in Hello packets, the local node will know which Hello packets the remote node has received.
在Hello消息中包含序列号允许每个节点验证其对等方是否正在接收Hello消息。通过将RcvSeqNum包含在Hello数据包中，本地节点将知道远程节点接收到了哪些Hello数据包。
The following example illustrates how the sequence numbers operate. Note that only the operation at one node is shown, and alternative scenarios are possible:
以下示例说明了序列号的操作方式。请注意，仅显示一个节点上的操作，并且可以使用其他方案：
1) After completing the configuration stage, Node A sends Hello messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
1) 完成配置阶段后，节点A向节点B发送Hello消息，其中包含{TxSeqNum=1；RcvSeqNum=0}。
2) Node A receives a Hello from Node B with {TxSeqNum=1;RcvSeqNum=1}. When the HelloInterval expires on Node A, it sends Hellos to Node B with {TxSeqNum=2;RcvSeqNum=1}.
2) 节点A接收来自节点B的Hello，其中{TxSeqNum=1；RcvSeqNum=1}。当HelloInterval在节点A上过期时，它将hello发送到节点B，其中包含{TxSeqNum=2；RcvSeqNum=1}。
3) Node A receives a Hello from Node B with {TxSeqNum=2;RcvSeqNum=2}. When the HelloInterval expires on Node A, it sends Hellos to Node B with {TxSeqNum=3;RcvSeqNum=2}.
3) 节点A接收来自节点B的Hello，其中{TxSeqNum=2；RcvSeqNum=2}。当HelloInterval在节点A上过期时，它将hello发送到节点B，其中包含{TxSeqNum=3；RcvSeqNum=2}。
To allow bringing a control channel down gracefully for administration purposes, a ControlChannelDown flag is available in the Common Header of LMP packets. When data links are still in use between a pair of nodes, a control channel SHOULD only be taken down administratively when there are other active control channels that can be used to manage the data links.
为了允许出于管理目的正常关闭控制通道，在LMP数据包的公共报头中提供ControlChannelDown标志。当一对节点之间的数据链路仍在使用时，只有当存在可用于管理数据链路的其他活动控制信道时，才应以管理方式关闭控制信道。
When bringing a control channel down administratively, a node MUST set the ControlChannelDown flag in all LMP messages sent over the control channel. The node that initiated the control channel down procedure may stop sending Hello messages after HelloDeadInterval seconds have passed, or if it receives an LMP message over the same control channel with the ControlChannelDown flag set.
当以管理方式关闭控制通道时，节点必须在通过控制通道发送的所有LMP消息中设置ControlChannelDown标志。启动控制通道关闭过程的节点可能会在HelloDeadInterval秒过后停止发送Hello消息，或者在设置了ControlChannelDown标志的同一控制通道上接收到LMP消息时停止发送Hello消息。
When a node receives an LMP packet with the ControlChannelDown flag set, it SHOULD send a Hello message with the ControlChannelDown flag set and move the control channel to the down state.
当节点接收到设置了ControlChannelDown标志的LMP数据包时，它应该发送设置了ControlChannelDown标志的Hello消息，并将控制通道移动到down状态。
A consequence of allowing the control channels to be physically diverse from the associated data links is that there may not be any active control channels available while the data links are still in use. For many applications, it is unacceptable to tear down a link that is carrying user traffic simply because the control channel is no longer available; however, the traffic that is using the data links may no longer be guaranteed the same level of service. Hence, the TE link is in a Degraded state.
允许控制信道与相关联的数据链路在物理上不同的结果是，当数据链路仍在使用时，可能没有任何可用的活动控制信道。对于许多应用，仅仅因为控制信道不再可用而中断承载用户流量的链路是不可接受的；但是，可能不再保证使用数据链路的通信量具有相同的服务级别。因此，TE链路处于降级状态。
When a TE link is in the Degraded state, routing and signaling SHOULD be notified so that new connections are not accepted and the TE link is advertised with no unreserved resources.
当TE链路处于降级状态时，应通知路由和信令，以便不接受新的连接，并在没有未保留资源的情况下播发TE链路。
As part of LMP, a link property correlation exchange is defined for TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages. The contents of these messages are built using LMP objects, which can be either negotiable or non-negotiable (identified by the N flag in the object header). Negotiable objects can be used to let both sides agree on certain link parameters. Non-negotiable objects are used for announcement of specific values that do not need, or do not allow, negotiation.
作为LMP的一部分，使用LinkSummary、LinkSummaryAck和LinkSummaryNack消息为TE链路定义链路属性相关交换。这些消息的内容是使用LMP对象构建的，LMP对象可以是可协商的，也可以是不可协商的（由对象头中的N标志标识）。可协商对象可用于让双方就某些链接参数达成一致。不可转让对象用于宣布不需要或不允许协商的特定价值。
Each TE link has an identifier (Link_Id) that is assigned at each end of the link. These identifiers MUST be the same type (i.e, IPv4, IPv6, unnumbered) at both ends. If a LinkSummary message is received with different local and remote TE link types, then a LinkSummaryNack message MUST be sent with Error Code "Bad TE Link Object". Similarly, each data link is assigned an identifier (Interface_Id) at each end. These identifiers MUST also be the same type at both ends. If a LinkSummary message is received with different local and remote Interface_Id types, then a LinkSummaryNack message MUST be sent with Error Code "Bad Data Link Object".
每个TE链路都有一个标识符（链路Id），该标识符分配在链路的每一端。这些标识符的两端必须是相同的类型（即IPv4、IPv6、未编号）。如果接收到具有不同本地和远程TE链路类型的LinkSummary消息，则必须发送LinkSummaryNack消息，错误代码为“Bad TE link Object”。类似地，每个数据链路的每一端都分配了一个标识符（接口Id）。这些标识符的两端也必须是相同的类型。如果接收到具有不同本地和远程接口Id类型的LinkSummary消息，则必须发送LinkSummaryNack消息，错误代码为“坏数据链路对象”。
Link property correlation SHOULD be done before the link is brought up and MAY be done any time a link is up and not in the Verification process.
链接属性关联应该在链接启动之前完成，并且可以在链接启动的任何时候完成，而不是在验证过程中。
The LinkSummary message is used to verify for consistency the TE and data link information on both sides. Link Summary messages are also used (1) to aggregate multiple data links (either ports or component links) into a TE link; (2) to exchange, correlate (to determine inconsistencies), or change TE link parameters; and (3) to exchange, correlate (to determine inconsistencies), or change Interface_Ids (either Port_Ids or component link identifiers).
LinkSummary消息用于验证双方TE和数据链路信息的一致性。链路摘要消息还用于（1）将多个数据链路（端口或组件链路）聚合为TE链路；（2） 交换、关联（确定不一致）或更改TE链路参数；以及（3）交换、关联（以确定不一致性）或更改接口标识（端口标识或组件链接标识）。
The LinkSummary message includes a TE_LINK object followed by one or more DATA_LINK objects. The TE_LINK object identifies the TE link's local and remote Link_Id and indicates support for fault management and link verification procedures for that TE link. The DATA_LINK objects are used to characterize the data links that comprise the TE link. These objects include the local and remote Interface_Ids, and may include one or more sub-objects further describing the properties of the data links.
LinkSummary消息包括一个TE_链接对象，后跟一个或多个数据链接对象。TE链接对象标识TE链接的本地和远程链接Id，并表示支持该TE链接的故障管理和链接验证过程。数据链路对象用于表征组成TE链路的数据链路。这些对象包括本地和远程接口id，并且可以包括进一步描述数据链路的属性的一个或多个子对象。
If the LinkSummary message is received from a remote node, and the Interface_Id mappings match those that are stored locally, then the two nodes have agreement on the Verification procedure (see Section 5) and data link identification configuration. If the verification procedure is not used, the LinkSummary message can be used to verify agreement on manual configuration.
如果从远程节点接收到LinkSummary消息，并且接口Id映射与本地存储的映射匹配，则两个节点在验证程序（参见第5节）和数据链路标识配置方面具有一致性。如果未使用验证程序，则LinkSummary消息可用于验证手动配置协议。
The LinkSummaryAck message is used to signal agreement on the Interface_Id mappings and link property definitions. Otherwise, a LinkSummaryNack message MUST be transmitted, indicating which Interface mappings are not correct and/or which link properties are not accepted. If a LinkSummaryNack message indicates that the Interface_Id mappings are not correct and the link verification procedure is enabled, the link verification process SHOULD be repeated for all mismatched, free data links; if an allocated data link has a mapping mismatch, it SHOULD be flagged and verified when
LinkSummaryAck消息用于表示对接口Id映射和链接属性定义的一致性。否则，必须传输LinkSummaryNack消息，指示哪些接口映射不正确和/或哪些链路属性不被接受。如果LinkSummaryNack消息表明接口Id映射不正确，且链路验证程序已启用，则应对所有不匹配的空闲数据链路重复链路验证过程；如果分配的数据链路存在映射不匹配，则应在
it becomes free. If a LinkSummaryNack message includes negotiable parameters, then acceptable values for those parameters MUST be included. If a LinkSummaryNack message is received and includes negotiable parameters, then the initiator of the LinkSummary message SHOULD send a new LinkSummary message. The new LinkSummary message SHOULD include new values for the negotiable parameters. These values SHOULD take into account the acceptable values received in the LinkSummaryNack message.
它变得自由了。如果LinkSummaryNack消息包含可协商的参数，则必须包含这些参数的可接受值。如果收到LinkSummaryNack消息并包含可协商参数，则LinkSummary消息的发起人应发送新的LinkSummary消息。新的LinkSummary消息应包括可协商参数的新值。这些值应考虑LinkSummaryNack消息中接收到的可接受值。
It is possible that the LinkSummary message could grow quite large due to the number of DATA LINK objects. An LMP implementation SHOULD be able to fragment when transmitting LMP messages, and MUST be able to re-assemble IP fragments when receiving LMP messages.
由于数据链接对象的数量，LinkSummary消息可能会变得相当大。LMP实现应该能够在传输LMP消息时分割，并且必须能够在接收LMP消息时重新组装IP片段。
In this section, an optional procedure is described that may be used to verify the physical connectivity of the data links and dynamically learn (i.e., discover) the TE link and Interface_Id associations. The procedure SHOULD be done when establishing a TE link, and subsequently, on a periodic basis for all unallocated (free) data links of the TE link.
在本节中，描述了可用于验证数据链路的物理连接并动态学习（即发现）TE链路和接口Id关联的可选过程。在建立TE链路时，应执行该程序，随后应定期为TE链路的所有未分配（自由）数据链路执行该程序。
Support for this procedure is indicated by setting the "Link Verification Supported" flag in the TE_LINK object of the LinkSummary message.
通过在LinkSummary消息的TE_Link对象中设置“支持链接验证”标志来表示对该过程的支持。
If a BeginVerify message is received and link verification is not supported for the TE link, then a BeginVerifyNack message MUST be transmitted with Error Code indicating, "Link Verification Procedure not supported for this TE Link."
如果收到BeginVerify消息且TE链路不支持链路验证，则必须发送BeginVerifyNack消息，错误代码指示“此TE链路不支持链路验证程序”
A unique characteristic of transparent devices is that the data is not modified or examined during normal operation. This characteristic poses a challenge for validating the connectivity of the data links and establishing the label mappings. Therefore, to ensure proper verification of data link connectivity, it is required that, until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency). To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the IP payload, etc.) and, hence, different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages.
透明设备的一个独特特性是，在正常操作期间，数据不会被修改或检查。该特性对验证数据链路的连接性和建立标签映射提出了挑战。因此，为了确保数据链路连接的正确验证，要求在为用户流量分配数据链路之前，数据链路必须不透明（即失去透明度）。为了支持不同程度的不透明性（例如，检查开销字节、终止IP有效负载等），并因此支持传输测试消息的不同机制，BeginVerify和BeginVerifyAck消息中包含验证传输机制字段。
There is no requirement that all data links be terminated simultaneously; but, at a minimum, the data links MUST be able to be terminated one at a time. Furthermore, for the link verification procedure it is assumed that the nodal architecture is designed so
不要求所有数据链路同时终止；但是，数据链路至少必须能够一次终止一个。此外，对于链路验证程序，假定节点架构设计为
that messages can be sent and received over any data link. Note that this requirement is trivial for opaque devices since each data link is electrically terminated and processed before being forwarded to the next opaque device; but that in transparent devices this is an additional requirement.
消息可以通过任何数据链路发送和接收。请注意，这一要求对于不透明设备来说并不重要，因为每个数据链路在转发到下一个不透明设备之前都经过了电气端接和处理；但在透明设备中，这是一个附加要求。
To interconnect two nodes, a TE link is defined between them, and at a minimum, there MUST be at least one active control channel between the nodes. For link verification, a TE link MUST include at least one data link.
为了互连两个节点，在它们之间定义了TE链路，并且在节点之间至少必须有一个活动控制信道。对于链路验证，TE链路必须至少包括一个数据链路。
Once a control channel has been established between the two nodes, data link connectivity can be verified by exchanging Test messages over each of the data links specified in the TE link. It should be noted that all LMP messages except the Test message are exchanged over the control channels and that Hello messages continue to be exchanged over each control channel during the data link verification process. The Test message is sent over the data link that is being verified. Data links are tested in the transmit direction because they are unidirectional; therefore, it may be possible for both nodes to (independently) exchange the Test messages simultaneously.
一旦在两个节点之间建立了控制信道，就可以通过在TE链路中指定的每个数据链路上交换测试消息来验证数据链路连接。应注意，除测试消息外的所有LMP消息都通过控制信道交换，并且在数据链路验证过程中，Hello消息继续通过每个控制信道交换。测试消息通过正在验证的数据链路发送。数据链路在传输方向上进行测试，因为它们是单向的；因此，两个节点可以（独立地）同时交换测试消息。
To initiate the link verification procedure, the local node MUST send a BeginVerify message over a control channel. To limit the scope of Link Verification to a particular TE Link, the local Link_Id MUST be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. For the case where the local Link_Id field is zero, the "Verify all Links" flag of the BEGIN_VERIFY object is used to distinguish between data links that span multiple TE links and those that have not yet been assigned to a TE link. Specifically, verification of data links that span multiple TE links is indicated by setting the local Link_Id field to zero and setting the "Verify all Links" flag. Verification of data links that have not yet been assigned to a TE link is indicated by setting the local Link_Id field to zero and clearing the "Verify all Links" flag.
要启动链路验证过程，本地节点必须通过控制通道发送BeginVerify消息。要将链路验证的范围限制到特定TE链路，本地链路Id必须为非零。如果该字段为零，则数据链路可以跨越多个TE链路和/或它们可以包括尚未配置的TE链路。对于本地链接Id字段为零的情况，开始验证对象的“验证所有链接”标志用于区分跨越多个TE链接的数据链接和尚未分配给TE链接的数据链接。具体而言，通过将本地链接Id字段设置为零并设置“验证所有链接”标志来指示跨多个TE链接的数据链接的验证。通过将local link_Id字段设置为零并清除“Verify all links”（验证所有链接）标志来指示尚未分配给TE链接的数据链接的验证。
The BeginVerify message also contains the number of data links that are to be verified; the interval (called VerifyInterval) at which the Test messages will be sent; the encoding scheme and transport mechanisms that are supported; the data rate for Test messages; and, when the data links correspond to fibers, the wavelength identifier over which the Test messages will be transmitted.
BeginVerify消息还包含要验证的数据链路的数量；发送测试消息的时间间隔（称为VerifyInterval）；支持的编码方案和传输机制；测试消息的数据速率；以及，当数据链路对应于光纤时，测试消息将通过其传输的波长标识符。
If the remote node receives a BeginVerify message and it is ready to process Test messages, it MUST send a BeginVerifyAck message back to the local node specifying the desired transport mechanism for the TEST messages. The remote node includes a 32-bit, node-unique
如果远程节点收到BeginVerify消息并准备好处理测试消息，则必须将BeginVerifyAck消息发送回本地节点，指定测试消息所需的传输机制。远程节点包括一个32位、唯一的节点
Verify_Id in the BeginVerifyAck message. The Verify_Id MAY be randomly selected; however, it MUST NOT overlap any other Verify_Id currently being used by the node selecting it. The Verify_Id is then used in all corresponding verification messages to differentiate them from different LMP peers and/or parallel Test procedures. When the local node receives a BeginVerifyAck message from the remote node, it may begin testing the data links by transmitting periodic Test messages over each data link. The Test message includes the Verify_Id and the local Interface_Id for the associated data link. The remote node MUST send either a TestStatusSuccess or a TestStatusFailure message in response for each data link. A TestStatusAck message MUST be sent to confirm receipt of the TestStatusSuccess and TestStatusFailure messages. Unacknowledged TestStatusSuccess and TestStatusFailure messages SHOULD be retransmitted until the message is acknowledged or until a retry limit is reached (see also Section 10).
验证BeginVerifyAck消息中的\u Id。验证Id可以随机选择；但是，它不能与选择它的节点当前使用的任何其他Verify_Id重叠。然后在所有相应的验证消息中使用验证Id，以将它们与不同的LMP对等和/或并行测试程序区分开来。当本地节点从远程节点接收到BeginVerifyAck消息时，它可以通过在每个数据链路上发送周期性测试消息来开始测试数据链路。测试消息包括相关数据链路的验证Id和本地接口Id。远程节点必须为每个数据链路发送TestStatusSuccess或TestStatusFailure消息作为响应。必须发送TestStatusAck消息以确认收到TestStatusSuccess和TestStatusFailure消息。未确认的TestStatusSuccess和TestStatusFailure消息应重新传输，直到消息被确认或达到重试限制为止（另请参见第10节）。
It is also permissible for the sender to terminate the Test procedure anytime after sending the BeginVerify message. An EndVerify message SHOULD be sent for this purpose.
也允许发送方在发送BeginVerify消息后随时终止测试过程。为此，应发送EndVerify消息。
Message correlation is done using message identifiers and the Verify_Id; this enables verification of data links, belonging to different link bundles or LMP sessions, in parallel.
使用消息标识符和验证Id进行消息关联；这允许并行验证属于不同链路束或LMP会话的数据链路。
When the Test message is received, the received Interface_Id (used in GMPLS as either a Port label or component link identifier, depending on the configuration) is recorded and mapped to the local Interface_Id for that data link, and a TestStatusSuccess message MUST be sent. The TestStatusSuccess message includes the local Interface_Id along with the Interface_Id and Verify_Id received in the Test message. The receipt of a TestStatusSuccess message indicates that the Test message was detected at the remote node and the physical connectivity of the data link has been verified. When the TestStatusSuccess message is received, the local node SHOULD mark the data link as up and send a TestStatusAck message to the remote node. If, however, the Test message is not detected at the remote node within an observation period (specified by the VerifyDeadInterval), the remote node MUST send a TestStatusFailure message over the control channel, which indicates that the verification of the physical connectivity of the data link has failed. When the local node receives a TestStatusFailure message, it SHOULD mark the data link as FAILED and send a TestStatusAck message to the remote node. When all the data links on the list have been tested, the local node SHOULD send an EndVerify message to indicate that testing is complete on this link.
当接收到测试消息时，将记录接收到的接口Id（在GMPLS中用作端口标签或组件链路标识符，具体取决于配置），并将其映射到该数据链路的本地接口Id，并且必须发送TestStatusSuccess消息。TestStatusSuccess消息包括本地接口Id以及在测试消息中接收到的接口Id和验证Id。收到TestStatusSuccess消息表示已在远程节点检测到测试消息，并且已验证数据链路的物理连接。当收到TestStatusSuccess消息时，本地节点应将数据链路标记为up，并向远程节点发送TestStatusAck消息。但是，如果在观察期（由VerifyDeadInterval指定）内远程节点未检测到测试消息，则远程节点必须通过控制通道发送TestStatusFailure消息，这表明数据链路的物理连接验证失败。当本地节点收到TestStatusFailure消息时，它应该将数据链路标记为FAILED，并向远程节点发送TestStatusAck消息。测试完列表上的所有数据链路后，本地节点应发送EndVerify消息，以指示此链路上的测试已完成。
If the local/remote data link mappings are known, then the link verification procedure can be optimized by testing the data links in a defined order known to both nodes. The suggested criterion for this ordering is by increasing the value of the remote Interface_Id.
如果本地/远程数据链路映射已知，则可以通过按照两个节点已知的定义顺序测试数据链路来优化链路验证过程。这种排序的建议标准是增加远程接口Id的值。
Both the local and remote nodes SHOULD maintain the complete list of Interface_Id mappings for correlation purposes.
本地和远程节点都应维护接口Id映射的完整列表，以便进行关联。
Figure 1 shows an example of the link verification scenario that is executed when a link between Node A and Node B is added. In this example, the TE link consists of three free ports (each transmitted along a separate fiber) and is associated with a bi-directional control channel (indicated by a "c"). The verification process is as follows:
图1显示了添加节点a和节点B之间的链路时执行的链路验证场景的示例。在该示例中，TE链路由三个空闲端口（每个端口沿单独的光纤传输）组成，并且与双向控制信道（由“c”表示）相关联。核查过程如下：
o A sends a BeginVerify message over the control channel to B, indicating it will begin verifying the ports that form the TE link. The LOCAL_LINK_ID object carried in the BeginVerify message carries the identifier (IP address or interface index) that A assigns to the link. o Upon receipt of the BeginVerify message, B creates a Verify_Id and binds it to the TE Link from A. This binding is used later when B receives the Test messages from A, and these messages carry the Verify_Id. B discovers the identifier (IP address or interface index) that A assigns to the TE link by examining the LOCAL_LINK_ID object carried in the received BeginVerify message. (If the data ports are not yet assigned to the TE Link, the binding is limited to the Node_Id of A.) In response to the BeginVerify message, B sends the BeginVerifyAck message to A. The LOCAL_LINK_ID object carried in the BeginVerifyAck message is used to carry the identifier (IP address or interface index) that B assigns to the TE link. The REMOTE_LINK_ID object carried in the BeginVerifyAck message is used to bind the Link_Ids assigned by both A and B. The Verify_Id is returned to A in the BeginVerifyAck message over the control channel. o When A receives the BeginVerifyAck message, it begins transmitting periodic Test messages over the first port (Interface Id=1). The Test message includes the Interface_Id for the port and the Verify_Id that was assigned by B. o When B receives the Test messages, it maps the received Interface_Id to its own local Interface_Id = 10 and transmits a TestStatusSuccess message over the control channel back to Node A. The TestStatusSuccess message includes both the local and received Interface_Ids for the port as well as the Verify_Id. The
o A通过控制通道向B发送BeginVerify消息，指示它将开始验证构成TE链路的端口。BeginVerify消息中包含的本地链接ID对象包含分配给链接的标识符（IP地址或接口索引）。o在收到BeginVerify消息后，B创建一个Verify_Id并将其绑定到来自a的TE链接。稍后当B从a接收测试消息时，使用此绑定，这些消息带有Verify_Id。B发现标识符（IP地址或接口索引）通过检查接收到的BeginVerify消息中携带的本地链接ID对象，A分配给TE链接。（如果数据端口尚未分配给TE链路，则绑定仅限于A的节点_Id。）响应BeginVerify消息，B将BeginVerifyAck消息发送给A。BeginVerifyAck消息中携带的本地_Link_Id对象用于携带B分配给TE链路的标识符（IP地址或接口索引）。BeginVerifyAck消息中携带的远程链接ID对象用于绑定A和B分配的链接ID。验证ID通过控制通道在BeginVerifyAck消息中返回给A。o当A收到BeginVerifyAck消息时，它开始通过第一个端口（接口Id=1）发送定期测试消息。测试消息包括端口的接口Id和B.o在收到测试消息时分配的验证Id，它将接收到的接口标识映射到自己的本地接口标识=10，并通过控制通道将TestStatusSuccess消息传输回节点a。TestStatusSuccess消息包括端口的本地和接收到的接口标识以及验证标识
Verify_Id is used to determine the local/remote TE link
identifiers (IP addresses or interface indices) to which the data
links belong.
o A will send a TestStatusAck message over the control channel back
to B, indicating it received the TestStatusSuccess message.
o The process is repeated until all of the ports are verified.
o At this point, A will send an EndVerify message over the control
channel to B, indicating that testing is complete.
o B will respond by sending an EndVerifyAck message over the control
channel back to A.
Verify_Id is used to determine the local/remote TE link
identifiers (IP addresses or interface indices) to which the data
links belong.
o A will send a TestStatusAck message over the control channel back
to B, indicating it received the TestStatusSuccess message.
o The process is repeated until all of the ports are verified.
o At this point, A will send an EndVerify message over the control
channel to B, indicating that testing is complete.
o B will respond by sending an EndVerifyAck message over the control
channel back to A.
Note that this procedure can be used to "discover" the connectivity of the data ports.
请注意，此过程可用于“发现”数据端口的连接。
+---------------------+ +---------------------+
+ + + +
+ Node A +<-------- c --------->+ Node B +
+ + + +
+ + + +
+ 1 +--------------------->+ 10 +
+ + + +
+ + + +
+ 2 + /---->+ 11 +
+ + /----/ + +
+ + /---/ + +
+ 3 +----/ + 12 +
+ + + +
+ + + +
+ 4 +--------------------->+ 14 +
+ + + +
+---------------------+ +---------------------+
+---------------------+ +---------------------+
+ + + +
+ Node A +<-------- c --------->+ Node B +
+ + + +
+ + + +
+ 1 +--------------------->+ 10 +
+ + + +
+ + + +
+ 2 + /---->+ 11 +
+ + /----/ + +
+ + /---/ + +
+ 3 +----/ + 12 +
+ + + +
+ + + +
+ 4 +--------------------->+ 14 +
+ + + +
+---------------------+ +---------------------+
Figure 1: Example of link connectivity between Node A and Node B.
图1：节点A和节点B之间的链路连接示例。
In this section, an optional LMP procedure is described that is used to manage failures by rapid notification of the status of one or more data channels of a TE Link. The scope of this procedure is within a TE link, and as such, the use of this procedure is negotiated as part of the LinkSummary exchange. The procedure can be used to rapidly isolate data link and TE link failures, and is designed to work for both unidirectional and bi-directional LSPs.
在本节中，描述了可选的LMP程序，该程序用于通过快速通知TE链路的一个或多个数据信道的状态来管理故障。本程序的范围在TE链接内，因此，本程序的使用作为链接摘要交换的一部分进行协商。该程序可用于快速隔离数据链路和TE链路故障，设计用于单向和双向LSP。
An important implication of using transparent devices is that traditional methods that are used to monitor the health of allocated data links may no longer be appropriate. Instead of fault detection being in layer 2 or layer 3, it is delegated to the physical layer (i.e., loss of light or optical monitoring of the data).
使用透明设备的一个重要含义是，用于监视所分配数据链路的健康状况的传统方法可能不再合适。故障检测不在第2层或第3层，而是委托给物理层（即，光线损失或数据的光学监测）。
Recall that a TE link connecting two nodes may consist of a number of data links. If one or more data links fail between two nodes, a mechanism must be used for rapid failure notification so that appropriate protection/restoration mechanisms can be initiated. If the failure is subsequently cleared, then a mechanism must be used to notify that the failure is clear and the channel status is OK.
回想一下，连接两个节点的TE链路可能由多个数据链路组成。如果两个节点之间的一个或多个数据链路发生故障，则必须使用一种机制进行快速故障通知，以便启动适当的保护/恢复机制。如果故障随后被清除，则必须使用一种机制来通知故障已清除且通道状态正常。
Fault detection should be handled at the layer closest to the failure; for optical networks, this is the physical (optical) layer. One measure of fault detection at the physical layer is detecting loss of light (LOL). Other techniques for monitoring optical signals are still being developed and will not be further considered in this document. However, it should be clear that the mechanism used for fault notification in LMP is independent of the mechanism used to detect the failure, and simply relies on the fact that a failure is detected.
故障检测应在离故障最近的一层进行；对于光网络，这是物理（光）层。物理层故障检测的一种方法是检测光损耗（LOL）。其他监测光信号的技术仍在开发中，本文件将不再进一步考虑。然而，应该清楚的是，LMP中用于故障通知的机制独立于用于检测故障的机制，并且仅仅依赖于检测到故障的事实。
In some situations, a data link failure between two nodes is propagated downstream such that all the downstream nodes detect the failure without localizing the failure. To avoid multiple alarms stemming from the same failure, LMP provides failure notification through the ChannelStatus message. This message may be used to indicate that a single data channel has failed, multiple data channels have failed, or an entire TE link has failed. Failure correlation is done locally at each node upon receipt of the failure notification.
在某些情况下，两个节点之间的数据链路故障会向下游传播，这样所有下游节点都会检测到故障，而不会定位故障。为避免同一故障导致多个报警，LMP通过ChannelStatus消息提供故障通知。此消息可用于指示单个数据通道出现故障、多个数据通道出现故障或整个TE链路出现故障。在接收到故障通知后，在每个节点本地进行故障关联。
To localize a fault to a particular link between adjacent nodes, a downstream node (downstream in terms of data flow) that detects data link failures will send a ChannelStatus message to its upstream neighbor indicating that a failure has been detected (bundling together the notification of all the failed data links). An upstream node that receives the ChannelStatus message MUST send a ChannelStatusAck message to the downstream node indicating it has received the ChannelStatus message. The upstream node should correlate the failure to see if the failure is also detected locally for the corresponding LSP(s). If, for example, the failure is clear on the input of the upstream node or internally, then the upstream
为了将故障定位到相邻节点之间的特定链路，检测数据链路故障的下游节点（数据流方面的下游）将向其上游邻居发送ChannelStatus消息，指示已检测到故障（将所有故障数据链路的通知捆绑在一起）。接收ChannelStatus消息的上游节点必须向下游节点发送ChannelStatusAck消息，指示其已接收ChannelStatus消息。上游节点应关联故障，以查看是否也在本地检测到相应LSP的故障。例如，如果故障在上游节点的输入上或在内部是明确的，则上游节点
node will have localized the failure. Once the failure is correlated, the upstream node SHOULD send a ChannelStatus message to the downstream node indicating that the channel is failed or is OK. If a ChannelStatus message is not received by the downstream node, it SHOULD send a ChannelStatusRequest message for the channel in question. Once the failure has been localized, the signaling protocols may be used to initiate span or path protection and restoration procedures.
节点将已本地化故障。一旦故障被关联，上游节点应向下游节点发送一条ChannelStatus消息，指示该信道故障或正常。如果下游节点未接收到ChannelStatus消息，则应为相关信道发送ChannelStatusRequest消息。一旦故障被定位，信令协议可用于启动跨度或路径保护和恢复程序。
If all of the data links of a TE link have failed, then the upstream node MAY be notified of the TE link failure without specifying each data link of the failed TE link. This is done by sending failure notification in a ChannelStatus message identifying the TE Link without including the Interface_Ids in the CHANNEL_STATUS object.
如果TE链路的所有数据链路都发生故障，则可以向上游节点通知TE链路故障，而不指定故障TE链路的每个数据链路。这是通过在ChannelStatus消息中发送故障通知来完成的，该消息标识TE链路，而不在CHANNEL_STATUS对象中包含Interface_ID。
In Figure 2, a sample network is shown where four nodes are connected in a linear array configuration. The control channels are bi-directional and are labeled with a "c". All LSPs are also bi-directional.
图2中显示了一个示例网络，其中四个节点以线性阵列配置连接。控制通道是双向的，并标有“c”。所有LSP也是双向的。
In the first example [see Fig. 2(a)], there is a failure on one direction of the bi-directional LSP. Node 4 will detect the failure and will send a ChannelStatus message to Node 3 indicating the failure (e.g., LOL) to the corresponding upstream node. When Node 3 receives the ChannelStatus message from Node 4, it returns a ChannelStatusAck message back to Node 4 and correlates the failure locally. When Node 3 correlates the failure and verifies that the failure is clear, it has localized the failure to the data link between Node 3 and Node 4. At that time, Node 3 should send a ChannelStatus message to Node 4 indicating that the failure has been localized.
在第一示例中[参见图2（a）]，在双向LSP的一个方向上存在故障。节点4将检测故障，并将向节点3发送指示故障（例如LOL）的ChannelStatus消息到相应的上游节点。当节点3从节点4接收到ChannelStatus消息时，它将ChannelStatusAck消息返回给节点4，并在本地关联故障。当节点3关联故障并验证故障是否清除时，它已将故障定位到节点3和节点4之间的数据链路。此时，节点3应向节点4发送ChannelStatus消息，指示故障已本地化。
In the second example [see Fig. 2(b)], a single failure (e.g., fiber cut) affects both directions of the bi-directional LSP. Node 2 (Node 3) will detect the failure of the upstream (downstream) direction and send a ChannelStatus message to the upstream (in terms of data flow) node indicating the failure (e.g., LOL). Simultaneously (ignoring propagation delays), Node 1 (Node 4) will detect the failure on the upstream (downstream) direction, and will send a ChannelStatus message to the corresponding upstream (in terms of data flow) node indicating the failure. Node 2 and Node 3 will have localized the two directions of the failure.
在第二个示例中[参见图2（b）]，单一故障（例如，光纤切割）影响双向LSP的两个方向。节点2（节点3）将检测上游（下游）方向的故障，并向上游（根据数据流）节点发送指示故障（例如LOL）的ChannelStatus消息。同时（忽略传播延迟），节点1（节点4）将检测上游（下游）方向上的故障，并将向相应的上游（根据数据流）节点发送指示故障的ChannelStatus消息。节点2和节点3将定位故障的两个方向。
+-------+ +-------+ +-------+ +-------+
+ Node1 + + Node2 + + Node3 + + Node4 +
+ +-- c ---+ +-- c ---+ +-- c ---+ +
----+---\ + + + + + + +
<---+---\\--+--------+-------+---\ + + + /--+--->
+ \--+--------+-------+---\\---+-------+---##---+---//--+----
+ + + + \---+-------+--------+---/ +
+ + + + + + (a) + +
----+-------+--------+---\ + + + + +
<---+-------+--------+---\\--+---##---+--\ + + +
+ + + \--+---##---+--\\ + + +
+ + + + (b) + \\--+--------+-------+--->
+ + + + + \--+--------+-------+----
+ + + + + + + +
+-------+ +-------+ +-------+ +-------+
+-------+ +-------+ +-------+ +-------+
+ Node1 + + Node2 + + Node3 + + Node4 +
+ +-- c ---+ +-- c ---+ +-- c ---+ +
----+---\ + + + + + + +
<---+---\\--+--------+-------+---\ + + + /--+--->
+ \--+--------+-------+---\\---+-------+---##---+---//--+----
+ + + + \---+-------+--------+---/ +
+ + + + + + (a) + +
----+-------+--------+---\ + + + + +
<---+-------+--------+---\\--+---##---+--\ + + +
+ + + \--+---##---+--\\ + + +
+ + + + (b) + \\--+--------+-------+--->
+ + + + + \--+--------+-------+----
+ + + + + + + +
+-------+ +-------+ +-------+ +-------+
Figure 2: Two types of data link failures are shown (indicated by ## in the figure): (A) a data link corresponding to the downstream direction of a bi-directional LSP fails, (B) two data links corresponding to both directions of a bi-directional LSP fail. The control channel connecting two nodes is indicated with a "c".
图2：显示了两种类型的数据链路故障（图中用##表示）：（A）对应于双向LSP下游方向的数据链路故障，（B）对应于双向LSP两个方向的两个数据链路故障。连接两个节点的控制通道用“c”表示。
The ChannelStatus message may also be used to notify an LMP neighbor that the data link should be actively monitored. This is called Channel Activation Indication. This is particularly useful in networks with transparent nodes where the status of data links may need to be triggered using control channel messages. For example, if a data link is pre-provisioned and the physical link fails after verification and before inserting user traffic, a mechanism is needed to indicate the data link should be active, otherwise the failure may not be detectable.
ChannelStatus消息还可用于通知LMP邻居应主动监视数据链路。这称为通道激活指示。这在具有透明节点的网络中特别有用，其中可能需要使用控制通道消息来触发数据链路的状态。例如，如果数据链路是预配置的，并且物理链路在验证之后和插入用户通信之前失败，则需要一种机制来指示数据链路应该处于活动状态，否则故障可能无法检测。
The ChannelStatus message is used to indicate that a channel or group of channels are now active. The ChannelStatusAck message MUST be transmitted upon receipt of a ChannelStatus message. When a ChannelStatus message is received, the corresponding data link(s) MUST be put into the Active state. If upon putting them into the Active state, a failure is detected, the ChannelStatus message SHOULD be transmitted as described in Section 6.2.
ChannelStatus消息用于指示一个或一组通道现在处于活动状态。ChannelStatusAck消息必须在收到ChannelStatus消息后发送。当接收到ChannelStatus消息时，必须将相应的数据链路置于活动状态。如果在将其置于激活状态时，检测到故障，则应按照第6.2节所述传输信道状态信息。
The ChannelStatus message may also be used to notify an LMP neighbor that the data link no longer needs to be actively monitored. This is the counterpart to the Channel Active Indication.
ChannelStatus消息还可用于通知LMP邻居不再需要主动监视数据链路。这是信道激活指示的对应项。
When a ChannelStatus message is received with Channel Deactive Indication, the corresponding data link(s) MUST be taken out of the Active state.
当接收到带有通道停用指示的ChannelStatus消息时，相应的数据链路必须退出激活状态。
The MESSAGE_ID and MESSAGE_ID_ACK objects are included in LMP messages to support reliable message delivery. This section describes the usage of these objects. The MESSAGE_ID and MESSAGE_ID_ACK objects contain a Message_Id field.
消息ID和消息ID确认对象包含在LMP消息中，以支持可靠的消息传递。本节介绍这些对象的用法。消息ID和消息ID确认对象包含消息ID字段。
Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message.
任何LMP消息中只能包含一个消息ID/消息ID确认对象。
For control-channel-specific messages, the Message_Id field is within the scope of the CC_Id. For TE link specific messages, the Message_Id field is within the scope of the LMP adjacency.
对于控制信道特定的消息，消息Id字段在CC_Id的范围内。对于TE链路特定的消息，消息Id字段在LMP邻接的范围内。
The Message_Id field of the MESSAGE_ID object contains a generator-selected value. This value MUST be monotonically increasing. A value is considered to be previously used when it has been sent in an LMP message with the same CC_Id (for control channel specific messages) or LMP adjacency (for TE Link specific messages). The Message_Id field of the MESSAGE_ID_ACK object contains the Message_Id field of the message being acknowledged.
Message_Id对象的Message_Id字段包含生成器选择的值。该值必须是单调递增的。当在具有相同CC_Id（用于控制信道特定消息）或LMP邻接（用于TE链路特定消息）的LMP消息中发送该值时，该值被视为以前使用的值。Message_Id_ACK对象的Message_Id字段包含正在确认的消息的Message_Id字段。
Unacknowledged messages sent with the MESSAGE_ID object SHOULD be retransmitted until the message is acknowledged or until a retry limit is reached (see also Section 10).
使用MESSAGE_ID对象发送的未确认消息应重新传输，直到消息被确认或达到重试限制为止（另请参见第10节）。
Note that the 32-bit Message_Id value may wrap. The following expression may be used to test if a newly received Message_Id value is less than a previously received value:
请注意，32位消息_Id值可能会换行。以下表达式可用于测试新接收的消息_Id值是否小于先前接收的值：
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}
If ((int) old_id - (int) new_id > 0) {
New value is less than old value;
}
Nodes processing incoming messages SHOULD check to see if a newly received message is out of order and can be ignored. Out-of-order messages can be identified by examining the value in the Message_Id field. If a message is determined to be out-of-order, that message should be silently dropped.
处理传入消息的节点应该检查新接收的消息是否有问题，是否可以忽略。可以通过检查Message_Id字段中的值来识别无序消息。如果确定某条消息出现故障，则应无声地删除该消息。
If the message is a Config message, and the Message_Id value is less than the largest Message_Id value previously received from the sender for the CC_Id, then the message SHOULD be treated as being out-of-order.
如果消息是配置消息，且消息\u Id值小于先前从发送方收到的CC\u Id的最大消息\u Id值，则该消息应视为无序。
If the message is a LinkSummary message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the TE Link, then the message SHOULD be treated as being out-of-order.
如果该消息是一条LinkSummary消息，并且该消息的\u Id值小于先前从发送方收到的TE链接的最大消息\u Id值，则该消息应被视为无序。
If the message is a ChannelStatus message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the specified TE link, then the receiver SHOULD check the Message_Id value previously received for the state of each data channel included in the ChannelStatus message. If the Message_Id value is greater than the most recently received Message_Id value associated with at least one of the data channels included in the message, the message MUST NOT be treated as out of order; otherwise, the message SHOULD be treated as being out of order. However, the state of any data channel MUST NOT be updated if the Message_Id value is less than the most recently received Message_Id value associated with the data channel.
如果消息是ChannelStatus消息，且消息Id值小于先前从指定TE链路的发送方收到的最大消息Id值，则接收方应检查先前收到的消息Id值，以了解ChannelStatus消息中包含的每个数据通道的状态。如果消息_Id值大于与消息中包括的至少一个数据信道相关联的最近接收的消息_Id值，则消息不得被视为无序；否则，该消息应被视为无序。但是，如果消息Id值小于与数据通道关联的最近接收的消息Id值，则不得更新任何数据通道的状态。
All other messages MUST NOT be treated as out-of-order.
不得将所有其他消息视为无序。
This section describes the mechanism to resynchronize the LMP state after a control plane restart. A control plane restart may occur when bringing up the first control channel after a control communications failure. A control communications failure may be the result of an LMP adjacency failure or a nodal failure wherein the LMP control state is lost, but the data plane is unaffected. The latter is detected by setting the "LMP Restart" bit in the Common Header of the LMP messages. When the control plane fails due to the loss of the control channel, the LMP link information should be retained. It is possible that a node may be capable of retaining the LMP link information across a nodal failure. However, in both cases the status of the data channels MUST be synchronized.
本节描述在控制平面重新启动后重新同步LMP状态的机制。在控制通信故障后启动第一个控制通道时，可能会发生控制平面重启。控制通信故障可能是LMP邻接故障或节点故障的结果，其中LMP控制状态丢失，但数据平面不受影响。后者通过在LMP消息的公共报头中设置“LMP重启”位来检测。当控制平面因控制信道丢失而失效时，应保留LMP链路信息。节点可能能够在节点故障期间保持LMP链路信息。但是，在这两种情况下，数据通道的状态必须同步。
It is assumed the Node_Id and Local Interface_Ids remain stable across a control plane restart.
假设节点Id和本地接口Id在控制平面重启期间保持稳定。
After the control plane of a node restarts, the control channel(s) must be re-established using the procedures of Section 3.1. When re-establishing control channels, the Config message SHOULD be sent using the unicast IP source and destination addresses.
节点的控制平面重新启动后，必须使用第3.1节中的程序重新建立控制信道。重新建立控制通道时，应使用单播IP源地址和目标地址发送配置消息。
If the control plane failure was the result of a nodal failure where the LMP control state is lost, then the "LMP Restart" flag MUST be set in LMP messages until a Hello message is received with the RcvSeqNum equal to the local TxSeqNum. This indicates that the control channel is up and the LMP neighbor has detected the restart.
如果控制平面故障是节点故障的结果，其中LMP控制状态丢失，则必须在LMP消息中设置“LMP重新启动”标志，直到接收到与RcvSeqNum等于本地TxSeqNum的Hello消息。这表示控制信道已启动，并且LMP邻居已检测到重启。
The following assumes that the LMP component restart only occurred on one end of the TE Link. If the LMP component restart occurred on both ends of the TE Link, the normal procedures for LinkSummary should be used, as described in Section 4.
以下假设LMP组件重启仅发生在TE链路的一端。如果LMP组件重启发生在TE链路的两端，则应使用链路汇总的正常程序，如第4节所述。
Once a control channel is up, the LMP neighbor MUST send a LinkSummary message for each TE Link across the adjacency. All the objects of the LinkSummary message MUST have the N-bit set to 0, indicating that the parameters are non-negotiable. This provides the local/remote Link_Id and Interface_Id mappings, the associated data link parameters, and indication of which data links are currently allocated to user traffic. When a node receives the LinkSummary message, it checks its local configuration. If the node is capable of retaining the LMP link information across a restart, it must process the LinkSummary message as described in Section 4 with the exception that the allocated/de-allocated flag of the DATA_LINK object received in the LinkSummary message MUST take precedence over any local value. If, however, the node was not capable of retaining the LMP link information across a restart, the node MUST accept the data link parameters of the received LinkSummary message and respond with a LinkSummaryAck message.
一旦控制信道启动，LMP邻居必须为相邻的每个TE链路发送链路摘要消息。LinkSummary消息的所有对象的N位必须设置为0，这表示参数是不可协商的。这提供了本地/远程链路Id和接口Id映射、相关数据链路参数以及当前分配给用户流量的数据链路的指示。当节点收到LinkSummary消息时，它会检查其本地配置。如果节点能够在重启过程中保留LMP链路信息，则它必须按照第4节所述处理LinkSummary消息，但LinkSummary消息中接收的数据链路对象的分配/取消分配标志必须优先于任何本地值。但是，如果节点无法在重启期间保留LMP链路信息，则节点必须接受接收到的LinkSummary消息的数据链路参数，并使用LinkSummaryAck消息进行响应。
Upon completion of the LinkSummary exchange, the node that has restarted the control plane SHOULD send a ChannelStatusRequest message for that TE link. The node SHOULD also verify the connectivity of all unallocated data channels.
完成LinkSummary交换后，重新启动控制平面的节点应为该TE链路发送ChannelStatusRequest消息。节点还应验证所有未分配数据通道的连接。
All LMP messages are run over UDP with an LMP port number (except, in some cases, the Test messages, which may be limited by the transport mechanism for in-band messaging). The destination address of the IP packet MAY be either the address learned in the Configuration procedure (i.e., the Source IP address found in the IP header of the
所有LMP消息都通过具有LMP端口号的UDP运行（在某些情况下，测试消息除外，测试消息可能受到带内消息传输机制的限制）。IP分组的目的地址可以是在配置过程中学习到的地址（即，在分组的IP报头中找到的源IP地址）
received Config message), an IP address configured on the remote node, or the Node_Id. The Config message is an exception as described below.
已收到配置消息），远程节点上配置的IP地址或节点Id。配置消息是一个例外，如下所述。
The manner in which a Config message is addressed may depend on the signaling transport mechanism. When the transport mechanism is a point-to-point link, Config messages SHOULD be sent to the Multicast address (224.0.0.1 or ff02::1). Otherwise, Config messages MUST be sent to an IP address on the neighboring node. This may be configured at both ends of the control channel or may be automatically discovered.
配置消息的寻址方式可能取决于信令传输机制。当传输机制是点到点链路时，应将配置消息发送到多播地址（224.0.0.1或ff02:：1）。否则，必须将配置消息发送到相邻节点上的IP地址。这可以在控制信道的两端配置，也可以自动发现。
This section is based on [RFC2961] and provides exponential back-off procedures for message retransmission. Implementations MUST use the described procedures or their equivalent.
本节以[RFC2961]为基础，提供了消息重传的指数退避过程。实现必须使用所描述的过程或其等效过程。
The following operation is one possible mechanism for exponential back-off retransmission of unacknowledged LMP messages. The sending node retransmits the message until an acknowledgement message is received or until a retry limit is reached. When the sending node receives the acknowledgement, retransmission of the message is stopped. The interval between message retransmission is governed by a rapid retransmission timer. The rapid retransmission timer starts at a small interval and increases exponentially until it reaches a threshold.
以下操作是未确认LMP消息的指数退避重传的一种可能机制。发送节点重新传输消息，直到收到确认消息或达到重试限制。当发送节点接收到确认时，消息的重新传输停止。消息重传之间的间隔由快速重传计时器控制。快速重传计时器以很小的间隔启动，并以指数方式增加，直到达到阈值。
The following time parameters are useful to characterize the procedures:
以下时间参数有助于描述程序的特征：
Rapid retransmission interval Ri:
快速重传间隔Ri：
Ri is the initial retransmission interval for unacknowledged messages. After sending the message for the first time, the sending node will schedule a retransmission after Ri milliseconds.
Ri是未确认消息的初始重传间隔。在第一次发送消息之后，发送节点将在Ri毫秒后安排重传。
Rapid retry limit Rl:
快速重试限制Rl:
Rl is the maximum number of times a message will be transmitted without being acknowledged.
Rl是消息在未被确认的情况下传输的最大次数。
Increment value Delta:
增量值增量：
Delta governs the speed with which the sender increases the retransmission interval. The ratio of two successive retransmission intervals is (1 + Delta).
增量控制发送方增加重传间隔的速度。两个连续重传间隔的比率为（1+Delta）。
Suggested default values for an initial retransmission interval (Ri) of 500 ms are a power of 2 exponential back-off (Delta = 1) and a retry limit of 3.
500 ms的初始重传间隔（Ri）的建议默认值为2次幂指数退避（增量=1）和3次重试限制。
After a node transmits a message requiring acknowledgement, it should immediately schedule a retransmission after Ri seconds. If a corresponding acknowledgement message is received before Ri seconds, then message retransmission SHOULD be canceled. Otherwise, it will retransmit the message after (1+Delta)*Ri seconds. The retransmission will continue until either an appropriate acknowledgement message is received or the rapid retry limit, Rl, has been reached.
节点发送需要确认的消息后，应立即在Ri秒后安排重传。如果在Ri秒之前收到相应的确认消息，则应取消消息重传。否则，它将在（1+Delta）*Ri秒后重新传输消息。重新传输将继续，直到接收到适当的确认消息或达到快速重试限制Rl为止。
A sending node can use the following algorithm when transmitting a message that requires acknowledgement:
发送节点在发送需要确认的消息时可以使用以下算法：
Prior to initial transmission, initialize Rk = Ri and Rn = 0.
在初始传输之前，初始化Rk=Ri和Rn=0。
while (Rn++ < Rl) {
transmit the message;
wake up after Rk milliseconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged message or no reply from receiver and Rl
reached*/
do any needed clean up;
exit;
while (Rn++ < Rl) {
transmit the message;
wake up after Rk milliseconds;
Rk = Rk * (1 + Delta);
}
/* acknowledged message or no reply from receiver and Rl
reached*/
do any needed clean up;
exit;
Asynchronously, when a sending node receives a corresponding acknowledgment message, it will change the retry count, Rn, to Rl.
异步地，当发送节点接收到相应的确认消息时，它将重试计数Rn更改为Rl。
Note that the transmitting node does not advertise or negotiate the use of the described exponential back-off procedures in the Config or LinkSummary messages.
请注意，传输节点不会在Config或LinkSummary消息中公布或协商所述的指数退避过程的使用。
The control channel FSM defines the states and logics of operation of an LMP control channel.
控制信道FSM定义LMP控制信道的运行状态和逻辑。
A control channel can be in one of the states described below. Every state corresponds to a certain condition of the control channel and is usually associated with a specific type of LMP message that is periodically transmitted to the far end.
控制信道可以处于下述状态之一。每个状态对应于控制信道的特定条件，并且通常与周期性地发送到远端的特定类型的LMP消息相关联。
Down: This is the initial control channel state. In this state, no attempt is being made to bring the control channel up and no LMP messages are sent. The control channel parameters should be set to the initial values.
向下：这是初始控制通道状态。在此状态下，不会尝试启动控制通道，也不会发送LMP消息。控制通道参数应设置为初始值。
ConfSnd: The control channel is in the parameter negotiation state. In this state the node periodically sends a Config message, and is expecting the other side to reply with either a ConfigAck or ConfigNack message. The FSM does not transition into the Active state until the remote side positively acknowledges the parameters.
ConfSnd：控制通道处于参数协商状态。在此状态下，节点定期发送配置消息，并期望另一方使用ConfigAck或ConfigNack消息进行回复。在远程侧确认参数之前，FSM不会转换到激活状态。
ConfRcv: The control channel is in the parameter negotiation state. In this state, the node is waiting for acceptable configuration parameters from the remote side. Once such parameters are received and acknowledged, the FSM can transition to the Active state.
ConfRcv：控制通道处于参数协商状态。在此状态下，节点正在等待来自远程端的可接受配置参数。一旦收到并确认这些参数，FSM就可以转换到激活状态。
Active: In this state the node periodically sends a Hello message and is waiting to receive a valid Hello message. Once a valid Hello message is received, it can transition to the up state.
活动：在此状态下，节点定期发送Hello消息，并等待接收有效的Hello消息。一旦收到有效的Hello消息，它就可以转换到up状态。
Up: The CC is in an operational state. The node receives valid Hello messages and sends Hello messages.
向上：CC处于运行状态。节点接收有效的Hello消息并发送Hello消息。
GoingDown: A CC may go into this state because of administrative action. While a CC is in this state, the node sets the ControlChannelDown bit in all the messages it sends.
下降：CC可能因为行政行为而进入这种状态。当CC处于此状态时，节点在其发送的所有消息中设置ControlChannelDown位。
Operation of the LMP control channel is described in terms of FSM states and events. Control channel events are generated by the underlying protocols and software modules, as well as by the packet processing routines and FSMs of associated TE links. Every event has its number and a symbolic name. Description of possible control channel events is given below.
根据FSM状态和事件描述LMP控制信道的操作。控制通道事件由底层协议和软件模块以及相关TE链路的数据包处理例程和FSM生成。每个事件都有其编号和符号名称。下面给出了可能的控制通道事件的描述。
1 : evBringUp: This is an externally triggered event indicating that the control channel negotiation should begin. This event, for example, may be triggered by an operator command, by the successful completion of a control channel bootstrap procedure, or by configuration. Depending on the configuration, this will trigger either 1a) the sending of a Config message, 1b) a period of waiting to receive a Config message from the remote node.
1:EVBRIGUP：这是一个外部触发的事件，指示应开始控制通道协商。例如，此事件可能由操作员命令、成功完成控制通道引导程序或配置触发。根据配置，这将触发1a）发送配置消息，1b）等待一段时间从远程节点接收配置消息。
2 : evCCDn: This event is generated when there is indication that the control channel is no longer available.
2:evCCDn：当指示控制通道不再可用时，会生成此事件。
3 : evConfDone: This event indicates a ConfigAck message has been received, acknowledging the Config parameters.
3:evConfDone：此事件表示已收到确认配置参数的ConfigAck消息。
4 : evConfErr: This event indicates a ConfigNack message has been received, rejecting the Config parameters.
4:evConfErr:此事件表示已收到ConfigNack消息，拒绝配置参数。
5 : evNewConfOK: New Config message was received from neighbor and positively acknowledged.
5:EVNEWCFOK:New Config消息从邻居处收到并得到肯定确认。
6 : evNewConfErr: New Config message was received from neighbor and rejected with a ConfigNack message.
6:evNewConfErr:从邻居接收到新配置消息，并使用ConfigNack消息拒绝。
7 : evContenWin: New Config message was received from neighbor at the same time a Config message was sent to the neighbor. The local node wins the contention. As a result, the received Config message is ignored.
7:evContenWin:在向邻居发送配置消息的同时，从邻居接收到新的配置消息。本地节点赢得竞争。因此，接收到的配置消息将被忽略。
8 : evContenLost: New Config message was received from neighbor at the same time a Config message was sent to the neighbor. The local node loses the contention. 8a) The Config message is positively acknowledged. 8b) The Config message is negatively acknowledged.
8:evContenLost:在向邻居发送配置消息的同时，从邻居接收到新的配置消息。本地节点丢失争用。8a）确认确认配置消息。8b）配置消息被否定地确认。
9 : evAdminDown: The administrator has requested that the control channel is brought down administratively.
9:evAdminDown：管理员已请求以管理方式关闭控制通道。
10: evNbrGoesDn: A packet with ControlChannelDown flag is received from the neighbor.
10:evNbrGoesDn：从邻居接收到带有ControlChannelDown标志的数据包。
11: evHelloRcvd: A Hello packet with expected SeqNum has been received.
11:evHelloRcvd:已收到预期SeqNum的Hello数据包。
12: evHoldTimer: The HelloDeadInterval timer has expired indicating that no Hello packet has been received. This moves the control channel back into the Negotiation state, and depending on the local configuration, this will trigger either 12a) the sending of periodic Config messages, 12b) a period of waiting to receive Config messages from the remote node.
12:evHoldTimer:HelloDeadInterval计时器已过期，表示未收到Hello数据包。这会将控制通道移回协商状态，并且根据本地配置，这将触发12a）周期性配置消息的发送，12b）从远程节点接收配置消息的等待时间。
13: evSeqNumErr: A Hello with unexpected SeqNum received and discarded.
13:EvSeqNumer：收到并丢弃了具有意外SeqNum的Hello。
14: evReconfig: Control channel parameters have been reconfigured and require renegotiation.
14:evReconfig：控制通道参数已重新配置，需要重新协商。
15: evConfRet: A retransmission timer has expired and a Config message is resent.
15:evConfRet：重新传输计时器已过期，并且重新发送配置消息。
16: evHelloRet: The HelloInterval timer has expired and a Hello packet is sent.
16:evHelloRet:HelloInterval计时器已过期，发送Hello数据包。
17: evDownTimer: A timer has expired and no messages have been received with the ControlChannelDown flag set.
17:evDownTimer:计时器已过期，未收到设置了ControlChannelDown标志的消息。
Figure 3 illustrates operation of the control channel FSM in a form of FSM state transition diagram.
图3以FSM状态转换图的形式说明了控制通道FSM的操作。
+--------+
+----------------->| |<--------------+
| +--------->| Down |<----------+ |
| |+---------| |<-------+ | |
| || +--------+ | | |
| || | ^ 2,9| 2| 2|
| ||1b 1a| | | | |
| || v |2,9 | | |
| || +--------+ | | |
| || +->| |<------+| | |
| || 4,7,| |ConfSnd | || | |
| || 14,15+--| |<----+ || | |
| || +--------+ | || | |
| || 3,8a| | | || | |
| || +---------+ |8b 14,12a| || | |
| || | v | || | |
| |+-|------>+--------+ | || | |
| | | +->| |-----|-|+ | |
| | |6,14| |ConfRcv | | | | |
| | | +--| |<--+ | | | |
| | | +--------+ | | | | |
| | | 5| ^ | | | | |
| | +---------+ | | | | | | |
| | | | | | | | | |
| | v v |6,12b | | | | |
| |10 +--------+ | | | | |
| +----------| | | | | | |
| | +--| Active |---|-+ | | |
10,17| | 5,16| | |-------|---+ |
+-------+ 9 | 13 +->| | | | |
| Going |<--|----------+--------+ | | |
| Down | | 11| ^ | | |
+-------+ | | |5 | | |
^ | v | 6,12b| | |
|9 |10 +--------+ | |12a,14 |
| +----------| |---+ | |
| | Up |-------+ |
+------------------| |---------------+
+--------+
| ^
| |
+---+
11,13,16
+--------+
+----------------->| |<--------------+
| +--------->| Down |<----------+ |
| |+---------| |<-------+ | |
| || +--------+ | | |
| || | ^ 2,9| 2| 2|
| ||1b 1a| | | | |
| || v |2,9 | | |
| || +--------+ | | |
| || +->| |<------+| | |
| || 4,7,| |ConfSnd | || | |
| || 14,15+--| |<----+ || | |
| || +--------+ | || | |
| || 3,8a| | | || | |
| || +---------+ |8b 14,12a| || | |
| || | v | || | |
| |+-|------>+--------+ | || | |
| | | +->| |-----|-|+ | |
| | |6,14| |ConfRcv | | | | |
| | | +--| |<--+ | | | |
| | | +--------+ | | | | |
| | | 5| ^ | | | | |
| | +---------+ | | | | | | |
| | | | | | | | | |
| | v v |6,12b | | | | |
| |10 +--------+ | | | | |
| +----------| | | | | | |
| | +--| Active |---|-+ | | |
10,17| | 5,16| | |-------|---+ |
+-------+ 9 | 13 +->| | | | |
| Going |<--|----------+--------+ | | |
| Down | | 11| ^ | | |
+-------+ | | |5 | | |
^ | v | 6,12b| | |
|9 |10 +--------+ | |12a,14 |
| +----------| |---+ | |
| | Up |-------+ |
+------------------| |---------------+
+--------+
| ^
| |
+---+
11,13,16
Figure 3: Control Channel FSM
图3：控制通道FSM
Event evCCDn always forces the FSM to the down state. Events evHoldTimer and evReconfig always force the FSM to the Negotiation state (either ConfSnd or ConfRcv).
事件evCCDn始终强制FSM处于关闭状态。事件evHoldTimer和evReconfig始终强制FSM进入协商状态（ConfSnd或ConfRcv）。
The TE Link FSM defines the states and logics of operation of the LMP TE Link.
TE链路FSM定义LMP TE链路的运行状态和逻辑。
An LMP TE link can be in one of the states described below. Every state corresponds to a certain condition of the TE link and is usually associated with a specific type of LMP message that is periodically transmitted to the far end via the associated control channel or in-band via the data links.
LMP-TE链路可以处于下述状态之一。每个状态对应于TE链路的特定条件，并且通常与特定类型的LMP消息相关联，该LMP消息经由相关联的控制信道或经由数据链路在带内周期性地发送到远端。
Down: There are no data links allocated to the TE link.
向下：没有分配给TE链路的数据链路。
Init: Data links have been allocated to the TE link, but the configuration has not yet been synchronized with the LMP neighbor. The LinkSummary message is periodically transmitted to the LMP neighbor.
Init：数据链路已分配给TE链路，但配置尚未与LMP邻居同步。LinkSummary消息定期发送到LMP邻居。
Up: This is the normal operational state of the TE link. At least one LMP control channel is required to be operational between the nodes sharing the TE link. As part of normal operation, the LinkSummary message may be periodically transmitted to the LMP neighbor or generated by an external request.
Up：这是TE链路的正常工作状态。共享TE链路的节点之间需要至少一个LMP控制信道可操作。作为正常操作的一部分，LinkSummary消息可以周期性地发送到LMP邻居或由外部请求生成。
Degraded: In this state, all LMP control channels are down, but the TE link still includes some data links that are allocated to user traffic.
降级：在此状态下，所有LMP控制信道都关闭，但TE链路仍包括分配给用户流量的一些数据链路。
Operation of the LMP TE link is described in terms of FSM states and events. TE Link events are generated by the packet processing routines and by the FSMs of the associated control channel(s) and the data links. Every event has its number and a symbolic name. Descriptions of possible events are given below.
根据FSM状态和事件描述LMP TE链路的操作。TE链路事件由分组处理例程以及相关控制信道和数据链路的FSM生成。每个事件都有其编号和符号名称。下面给出了可能事件的描述。
1 : evDCUp: One or more data channels have been enabled and assigned to the TE Link.
1:evDCUp：一个或多个数据通道已启用并分配给TE链路。
2 : evSumAck: LinkSummary message received and positively acknowledged.
2:evSumAck:LinkSummary消息已收到并已确认。
3 : evSumNack: LinkSummary message received and negatively acknowledged.
3:evSumNack:LinkSummary消息已收到并被否定确认。
4 : evRcvAck: LinkSummaryAck message received acknowledging the TE Link Configuration.
4:evRcvAck:LinkSummaryAck消息收到，确认TE链路配置。
5 : evRcvNack: LinkSummaryNack message received.
5:evRcvNack:LinkSummaryNack消息已收到。
6 : evSumRet: Retransmission timer has expired and LinkSummary message is resent.
6:evSumRet:重传计时器已过期，重新发送链接摘要消息。
7 : evCCUp: First active control channel goes up.
7:evCCUp：第一个活动控制通道上升。
8 : evCCDown: Last active control channel goes down.
8:evCCDown：最后一个激活的控制通道下降。
9 : evDCDown: Last data channel of TE Link has been removed.
9:evDCDown:TE链路的最后一个数据通道已被删除。
Figure 4 illustrates operation of the LMP TE Link FSM in a form of FSM state transition diagram.
图4以FSM状态转换图的形式说明了LMP TE链路FSM的操作。
3,7,8
+--+
| |
| v
+--------+
| |
+------------>| Down |<---------+
| | | |
| +--------+ |
| | ^ |
| 1| |9 |
| v | |
| +--------+ |
| | |<-+ |
| | Init | |3,5,6 |9
| | |--+ 7,8 |
9| +--------+ |
| | |
| 2,4| |
| v |
+--------+ 7 +--------+ |
| |------>| |----------+
| Deg | | Up |
| |<------| |
+--------+ 8 +--------+
| ^
| |
+--+
2,3,4,5,6
3,7,8
+--+
| |
| v
+--------+
| |
+------------>| Down |<---------+
| | | |
| +--------+ |
| | ^ |
| 1| |9 |
| v | |
| +--------+ |
| | |<-+ |
| | Init | |3,5,6 |9
| | |--+ 7,8 |
9| +--------+ |
| | |
| 2,4| |
| v |
+--------+ 7 +--------+ |
| |------>| |----------+
| Deg | | Up |
| |<------| |
+--------+ 8 +--------+
| ^
| |
+--+
2,3,4,5,6
Figure 4: LMP TE Link FSM
图4:LMP TE链路FSM
In the above FSM, the sub-states that may be implemented when the link verification procedure is used have been omitted.
在上述FSM中，省略了当使用链路验证过程时可能实现的子状态。
The data link FSM defines the states and logics of operation of a data link within an LMP TE link. Operation of a data link is described in terms of FSM states and events. Data links can either be in the active (transmitting) mode, where Test messages are transmitted from them, or the passive (receiving) mode, where Test messages are received through them. For clarity, separate FSMs are defined for the active/passive data links; however, a single set of data link states and events are defined.
数据链路FSM定义LMP TE链路内数据链路的运行状态和逻辑。根据FSM状态和事件描述数据链路的操作。数据链路可以处于主动（传输）模式，其中测试消息从它们传输，或者处于被动（接收）模式，其中测试消息通过它们接收。为清晰起见，为主动/被动数据链路定义了单独的FSM；但是，只定义了一组数据链路状态和事件。
Any data link can be in one of the states described below. Every state corresponds to a certain condition of the data link.
任何数据链路都可以处于下述状态之一。每个状态对应于数据链路的特定条件。
Down: The data link has not been put in the resource pool (i.e., the link is not 'in service')
停机：数据链路尚未放入资源池（即，链路未处于“服务中”）
Test: The data link is being tested. An LMP Test message is periodically sent through the link.
测试：正在测试数据链路。LMP测试消息通过链路定期发送。
PasvTest: The data link is being checked for incoming test messages.
PasvTest:正在检查数据链路是否有传入的测试消息。
Up/Free: The link has been successfully tested and is now put in the pool of resources (in-service). The link has not yet been allocated to data traffic.
启动/释放：链接已成功测试，现在已放入资源池（在用）。链路尚未分配给数据通信。
Up/Alloc: The link is up and has been allocated for data traffic.
Up/Alloc：链路已启动，并已分配给数据流量。
Data link events are generated by the packet processing routines and by the FSMs of the associated control channel and the TE link.
数据链路事件由分组处理例程以及相关控制信道和TE链路的fsm生成。
Every event has its number and a symbolic name. Description of possible data link events is given below:
每个事件都有其编号和符号名称。可能的数据链路事件描述如下：
1 :evCCUp: First active control channel goes up.
1:evCCUp：第一个主动控制通道上升。
2 :evCCDown: LMP neighbor connectivity is lost. This indicates the last LMP control channel has failed between neighboring nodes.
2:evCCDown:LMP邻居连接丢失。这表示相邻节点之间的最后一个LMP控制信道发生故障。
3 :evStartTst: This is an external event that triggers the sending of Test messages over the data link.
3:evStartTst：这是一个触发通过数据链路发送测试消息的外部事件。
4 :evStartPsv: This is an external event that triggers the listening for Test messages over the data link.
4:evStartPsv：这是一个外部事件，触发通过数据链路侦听测试消息。
5 :evTestOK: Link verification was successful and the link can be used for path establishment. (a) This event indicates the Link Verification procedure (see Section 5) was successful for this data link and a TestStatusSuccess message was received over the control channel.
5:evTestOK：链接验证成功，链接可用于路径建立。（a） 此事件表示此数据链路的链路验证程序（见第5节）成功，并且通过控制通道接收到TestStatusSuccess消息。
(b) This event indicates the link is ready for path establishment, but the Link Verification procedure was not used. For in-band signaling of the control channel, the control channel establishment may be sufficient to verify the link.
(b) 此事件表示链路已准备好建立路径，但未使用链路验证过程。对于控制信道的带内信令，控制信道建立可足以验证链路。
6 :evTestRcv: Test message was received over the data port and a TestStatusSuccess message is transmitted over the control channel.
6:evTestRcv:Test消息通过数据端口接收，TestStatusSuccess消息通过控制通道传输。
7 :evTestFail: Link verification returned negative results. This could be because (a) a TestStatusFailure message was received, or (b) the Verification procedure has ended without receiving a TestStatusSuccess or TestStatusFailure message for the data link.
7:evTestFail:链接验证返回否定结果。这可能是因为（a）收到了TestStatusFailure消息，或者（b）验证过程结束时未收到数据链路的TestStatusSuccess或TestStatusFailure消息。
8 :evPsvTestFail: Link verification returned negative results. This indicates that a Test message was not detected and either (a) the VerifyDeadInterval has expired or (b) the Verification procedure has ended and the VerifyDeadInterval has not yet expired.
8:evPsvTestFail:链路验证返回否定结果。这表示未检测到测试消息，并且（a）VerifyDeadInterval已过期，或者（b）验证过程已结束且VerifyDeadInterval尚未过期。
9 :evLnkAlloc: The data link has been allocated.
9:evLnkAlloc：数据链路已分配。
10:evLnkDealloc: The data link has been de-allocated.
10:evLnkDealloc:数据链路已取消分配。
11:evTestRet: A retransmission timer has expired and the Test message is resent.
11:evTestRet：重新传输计时器已过期，测试消息已重新发送。
12:evSummaryFail: The LinkSummary did not match for this data port.
12:evSummaryFail:链接摘要与此数据端口不匹配。
13:evLocalizeFail: A Failure has been localized to this data link.
13:evLocalizeFail：故障已定位到此数据链路。
14:evdcDown: The data channel is no longer available.
14:evdcDown：数据通道不再可用。
Figure 5 illustrates operation of the LMP active data link FSM in a form of FSM state transition diagram.
图5以FSM状态转换图的形式说明了LMP主动数据链路FSM的操作。
+------+
| |<-------+
+--------->| Down | |
| +----| |<-----+ |
| | +------+ | |
| |5b 3| ^ | |
| | | |7 | |
| | v | | |
| | +------+ | |
| | | |<-+ | |
| | | Test | |11 | |
| | | |--+ | |
| | +------+ | |
| | 5a| 3^ | |
| | | | | |
| | v | | |
|12 | +---------+ | |
| +-->| |14 | |
| | Up/Free |----+ |
+---------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |------+
| |
+---------+
+------+
| |<-------+
+--------->| Down | |
| +----| |<-----+ |
| | +------+ | |
| |5b 3| ^ | |
| | | |7 | |
| | v | | |
| | +------+ | |
| | | |<-+ | |
| | | Test | |11 | |
| | | |--+ | |
| | +------+ | |
| | 5a| 3^ | |
| | | | | |
| | v | | |
|12 | +---------+ | |
| +-->| |14 | |
| | Up/Free |----+ |
+---------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |------+
| |
+---------+
Figure 5: Active LMP Data Link FSM
图5：主动LMP数据链路FSM
Figure 6 illustrates operation of the LMP passive data link FSM in a form of FSM state transition diagram.
图6以FSM状态转换图的形式说明了LMP无源数据链路FSM的操作。
+------+
| |<------+
+---------->| Down | |
| +-----| |<----+ |
| | +------+ | |
| |5b 4| ^ | |
| | | |8 | |
| | v | | |
| | +----------+ | |
| | | PasvTest | | |
| | +----------+ | |
| | 6| 4^ | |
| | | | | |
| | v | | |
|12 | +---------+ | |
| +--->| Up/Free |14 | |
| | |---+ |
+----------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |-----+
| |
+---------+
+------+
| |<------+
+---------->| Down | |
| +-----| |<----+ |
| | +------+ | |
| |5b 4| ^ | |
| | | |8 | |
| | v | | |
| | +----------+ | |
| | | PasvTest | | |
| | +----------+ | |
| | 6| 4^ | |
| | | | | |
| | v | | |
|12 | +---------+ | |
| +--->| Up/Free |14 | |
| | |---+ |
+----------| | |
+---------+ |
9| ^ |
| | |
v |10 |
+---------+ |
| |13 |
|Up/Alloc |-----+
| |
+---------+
Figure 6: Passive LMP Data Link FSM
图6：无源LMP数据链路FSM
All LMP messages (except, in some cases, the Test messages, which are limited by the transport mechanism for in-band messaging) are run over UDP with an LMP port number (701).
所有LMP消息（在某些情况下，受带内消息传输机制限制的测试消息除外）都通过具有LMP端口号（701）的UDP运行。
In addition to the UDP header and standard IP header, all LMP messages (except, in some cases, the Test messages which may be limited by the transport mechanism for in-band messaging) have the following common header:
除UDP报头和标准IP报头外，所有LMP消息（在某些情况下，可能受带内消息传输机制限制的测试消息除外）都具有以下公用报头：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | (Reserved) | Flags | Msg Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMP Length | (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | (Reserved) | Flags | Msg Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LMP Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
保留字段应作为零发送，并在收到时忽略。
All values are defined in network byte order (i.e., big-endian byte order).
所有值均以网络字节顺序（即大端字节顺序）定义。
Vers: 4 bits
版本：4位
Protocol version number. This is version 1.
协议版本号。这是第1版。
Flags: 8 bits
标志：8位
The following bit-values are defined. All other bits are reserved and should be sent as zero and ignored on receipt.
定义了以下位值。所有其他位均保留，应作为零发送，并在收到时忽略。
0x01: ControlChannelDown
0x01:ControlChannelDown
0x02: LMP Restart
0x02:LMP重新启动
This bit is set to indicate that a nodal failure has occurred and the LMP control state has been lost. This flag may be reset to 0 when a Hello message is received with RcvSeqNum equal to the local TxSeqNum.
该位被设置为指示节点故障已经发生，LMP控制状态已经丢失。当接收到RcvSeqNum等于本地TxSeqNum的Hello消息时，此标志可能会重置为0。
Msg Type: 8 bits
消息类型：8位
The following values are defined. All other values are reserved
定义了以下值。所有其他值均保留
1 = Config
1 = Config
2 = ConfigAck
2 = ConfigAck
3 = ConfigNack
3 = ConfigNack
4 = Hello
4 = Hello
5 = BeginVerify
5 = BeginVerify
6 = BeginVerifyAck
6 = BeginVerifyAck
7 = BeginVerifyNack
7 = BeginVerifyNack
8 = EndVerify
8 = EndVerify
9 = EndVerifyAck
9 = EndVerifyAck
10 = Test
10 = Test
11 = TestStatusSuccess
11 = TestStatusSuccess
12 = TestStatusFailure
12 = TestStatusFailure
13 = TestStatusAck
13 = TestStatusAck
14 = LinkSummary
14 = LinkSummary
15 = LinkSummaryAck
15 = LinkSummaryAck
16 = LinkSummaryNack
16 = LinkSummaryNack
17 = ChannelStatus
17 = ChannelStatus
18 = ChannelStatusAck
18 = ChannelStatusAck
19 = ChannelStatusRequest
19 = ChannelStatusRequest
20 = ChannelStatusResponse
20 = ChannelStatusResponse
All of the messages are sent over the control channel EXCEPT the Test message, which is sent over the data link that is being tested.
所有消息均通过控制通道发送，测试消息除外，测试消息通过正在测试的数据链路发送。
LMP Length: 16 bits
LMP长度：16位
The total length of this LMP message in bytes, including the common header and any variable-length objects that follow.
此LMP消息的总长度（以字节为单位），包括公共标头和其后的任何可变长度对象。
LMP messages are built using objects. Each object is identified by its Object Class and Class-type. Each object has a name, which is always capitalized in this document. LMP objects can be either negotiable or non-negotiable (identified by the N bit in the object header). Negotiable objects can be used to let the devices agree on certain values. Non-negotiable objects are used for announcement of specific values that do not need or do not allow negotiation.
LMP消息是使用对象构建的。每个对象都由其对象类和类类型标识。每个对象都有一个名称，该名称在本文档中始终大写。LMP对象可以是可协商的或不可协商的（由对象头中的N位标识）。可协商对象可用于让设备就某些值达成一致。不可协商对象用于声明不需要或不允许协商的特定值。
All values are defined in network byte order (i.e., big-endian byte order).
所有值均以网络字节顺序（即大端字节顺序）定义。
The format of the LMP object is as follows:
LMP对象的格式如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object contents) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object contents) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N: 1 bit
N:1位
The N flag indicates if the object is negotiable (N=1) or non-negotiable (N=0).
N标志表示对象是可协商的（N=1）还是不可协商的（N=0）。
C-Type: 7 bits
C型：7位
Class-type, unique within an Object Class. Values are defined in Section 13.
类类型，在对象类中是唯一的。数值在第13节中定义。
Class: 8 bits
类别：8位
The Class indicates the object type. Each object has a name, which is always capitalized in this document.
该类指示对象类型。每个对象都有一个名称，该名称在本文档中始终大写。
Length: 16 bits
长度：16位
The Length field indicates the length of the object in bytes, including the N, C-Type, Class, and Length fields.
长度字段以字节为单位指示对象的长度，包括N、C类型、类和长度字段。
The Config message is used in the control channel negotiation phase of LMP. The contents of the Config message are built using LMP objects. The format of the Config message is as follows:
配置消息用于LMP的控制信道协商阶段。配置消息的内容是使用LMP对象构建的。配置消息的格式如下所示：
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG>
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The MESSAGE_ID object is within the scope of the LOCAL_CCID object.
消息ID对象在本地CCID对象的范围内。
The Config message MUST be periodically transmitted until (1) it receives a ConfigAck or ConfigNack message, (2) a retry limit has been reached and no ConfigAck or ConfigNack message has been received, or (3) it receives a Config message from the remote node and has lost the contention (e.g., the Node_Id of the remote node is higher than the Node_Id of the local node). Both the retransmission interval and the retry limit are local configuration parameters.
必须定期传输配置消息，直到（1）它接收到ConfigAck或ConfigNack消息，（2）达到重试限制且未接收到ConfigAck或ConfigNack消息，或者（3）它从远程节点接收到配置消息并丢失争用（例如，远程节点的Node_Id高于本地节点的Node_Id）。重传间隔和重试限制都是本地配置参数。
The ConfigAck message is used to acknowledge receipt of the Config message and indicate agreement on all parameters.
ConfigAck消息用于确认收到Config消息，并表示同意所有参数。
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID>
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being acknowledged.
必须从正在确认的配置消息中获取远程\u CCID、消息\u ID\u ACK和远程\u节点\u ID对象的内容。
The ConfigNack message is used to acknowledge receipt of the Config message and indicate disagreement on non-negotiable parameters or propose other values for negotiable parameters. Parameters where agreement was reached MUST NOT be included in the ConfigNack Message. The format of the ConfigNack message is as follows:
ConfigNack消息用于确认收到配置消息，并表示对不可协商参数的异议，或为可协商参数提出其他值。ConfigNack消息中不得包含达成协议的参数。ConfigNack消息的格式如下所示：
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being negatively acknowledged.
远程\u CCID、消息\u ID\u ACK和远程\u节点\u ID对象的内容必须从被否定确认的配置消息中获取。
It is possible that multiple parameters may be invalid in the Config message.
配置消息中可能有多个参数无效。
If a negotiable CONFIG object is included in the ConfigNack message, it MUST include acceptable values for the parameters.
如果ConfigNack消息中包含可协商的配置对象，则它必须包含可接受的参数值。
If the ConfigNack message includes CONFIG objects for non-negotiable parameters, they MUST be copied from the CONFIG objects received in the Config message.
如果ConfigNack消息包含不可协商参数的配置对象，则必须从配置消息中接收的配置对象复制这些对象。
If the ConfigNack message is received and only includes CONFIG objects that are negotiable, then a new Config message SHOULD be sent. The values in the CONFIG object of the new Config message SHOULD take into account the acceptable values included in the ConfigNack message.
如果收到ConfigNack消息，并且只包含可协商的配置对象，则应发送新的配置消息。新配置消息的CONFIG对象中的值应考虑ConfigNack消息中包含的可接受值。
If a node receives a Config message and recognizes the CONFIG object, but does not recognize the C-Type, a ConfigNack message including the unknown CONFIG object MUST be sent.
如果节点接收到配置消息并识别配置对象，但不识别C类型，则必须发送包含未知配置对象的ConfigNack消息。
The format of the Hello message is as follows:
Hello消息的格式如下所示：
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The Hello message MUST be periodically transmitted at least once every HelloInterval msec. If no Hello message is received within the HelloDeadInterval, the control channel is assumed to have failed.
Hello消息必须至少每隔HelloInterval毫秒定期发送一次。如果HelloDeadInterval内未接收到Hello消息，则假定控制通道出现故障。
The BeginVerify message is sent over the control channel and is used to initiate the link verification process. The format is as follows:
BeginVerify消息通过控制通道发送，用于启动链路验证过程。格式如下:
<BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> [<REMOTE_LINK_ID>]
<BEGIN_VERIFY>
<BeginVerify Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> [<REMOTE_LINK_ID>]
<BEGIN_VERIFY>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
To limit the scope of Link Verification to a particular TE Link, the Link_Id field of the LOCAL_LINK_ID object MUST be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. In the special case where the local Link_Id field is zero, the "Verify all Links" flag of the BEGIN_VERIFY object is used to distinguish between data links that span multiple TE links and those that have not yet been assigned to a TE link (see Section 5).
要将链接验证的范围限制为特定TE链接，本地链接Id对象的链接Id字段必须为非零。如果该字段为零，则数据链路可以跨越多个TE链路和/或它们可以包括尚未配置的TE链路。在本地链接Id字段为零的特殊情况下，开始验证对象的“验证所有链接”标志用于区分跨越多个TE链接的数据链接和尚未分配给TE链接的数据链接（参见第5节）。
The REMOTE_LINK_ID object may be included if the local/remote Link_Id mapping is known.
如果本地/远程链接ID映射已知，则可以包括远程链接ID对象。
The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if included.
远程链接Id对象的链接Id字段必须为非零（如果包括）。
The BeginVerify message MUST be periodically transmitted until (1) the node receives either a BeginVerifyAck or BeginVerifyNack message to accept or reject the verify process or (2) a retry limit has been reached and no BeginVerifyAck or BeginVerifyNack message has been received. Both the retransmission interval and the retry limit are local configuration parameters.
必须定期发送BeginVerify消息，直到（1）节点收到BeginVerifyAck或BeginVerifyNack消息以接受或拒绝验证过程，或（2）达到重试限制且未收到BeginVerifyAck或BeginVerifyNack消息。重传间隔和重试限制都是本地配置参数。
When a BeginVerify message is received and Test messages are ready to be processed, a BeginVerifyAck message MUST be transmitted.
当收到BeginVerify消息且测试消息准备好进行处理时，必须发送BeginVerifyAck消息。
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID>
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The LOCAL_LINK_ID object may be included if the local/remote Link_Id mapping is known or learned through the BeginVerify message.
如果本地/远程链接ID映射已知或通过BeginVerify消息获知，则可以包括本地链接ID对象。
The Link_Id field of the LOCAL_LINK_ID MUST be non-zero if included.
本地链接Id的链接Id字段必须为非零（如果包括）。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being acknowledged.
消息\u ID\u ACK对象的内容必须从正在确认的BeginVerify消息中获取。
The VERIFY_ID object contains a node-unique value that is assigned by the generator of the BeginVerifyAck message. This value is used to uniquely identify the Verification process from multiple LMP neighbors and/or parallel Test procedures between the same LMP neighbors.
VERIFY_ID对象包含由BeginVerifyAck消息的生成器分配的节点唯一值。该值用于从多个LMP邻居和/或相同LMP邻居之间的并行测试程序中唯一标识验证过程。
If a BeginVerify message is received and a node is unwilling or unable to begin the Verification procedure, a BeginVerifyNack message MUST be transmitted.
如果收到BeginVerify消息，且节点不愿意或无法开始验证过程，则必须发送BeginVerifyNack消息。
<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <ERROR_CODE>
<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <ERROR_CODE>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being negatively acknowledged.
消息\u ID\u ACK对象的内容必须从被否定确认的BeginVerify消息中获取。
If the Verification process is not supported, the ERROR_CODE MUST indicate "Link Verification Procedure not supported".
如果不支持验证过程，错误代码必须指示“链接验证过程不支持”。
If Verification is supported, but the node is unable to begin the procedure, the ERROR_CODE MUST indicate "Unwilling to verify". If a BeginVerifyNack message is received with such an ERROR_CODE, the node that originated the BeginVerify SHOULD schedule a BeginVerify retransmission after Rf seconds, where Rf is a locally defined parameter.
如果支持验证，但节点无法开始该过程，则错误代码必须指示“不愿意验证”。如果收到带有此类错误代码的BeginVerifyNack消息，则发起BeginVerify的节点应在Rf秒后安排BeginVerify重新传输，其中Rf是本地定义的参数。
If the Verification Transport mechanism is not supported, the ERROR_CODE MUST indicate "Unsupported verification transport mechanism".
如果不支持验证传输机制，则错误代码必须指示“不支持的验证传输机制”。
If remote configuration of the Link_Id is not supported and the content of the REMOTE_LINK_ID object (included in the BeginVerify message) does not match any configured values, the ERROR_CODE MUST indicate "Link_Id configuration error".
如果不支持链接Id的远程配置，并且远程链接Id对象（包括在BeginVerify消息中）的内容与任何配置的值不匹配，则错误代码必须指示“链接Id配置错误”。
If a node receives a BeginVerify message and recognizes the BEGIN_VERIFY object but does not recognize the C-Type, the ERROR_CODE MUST indicate "Unknown object C-Type".
如果节点收到BeginVerify消息并识别BEGIN\u VERIFY对象但不识别C类型，则错误代码必须指示“未知对象C类型”。
The EndVerify message is sent over the control channel and is used to terminate the link verification process. The EndVerify message may be sent any time the initiating node desires to end the Verify procedure. The format is as follows:
EndVerify消息通过控制通道发送，用于终止链路验证过程。可在发起节点希望结束验证过程的任何时候发送EndVerify消息。格式如下:
<EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>
<EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The EndVerify message will be periodically transmitted until (1) an EndVerifyAck message has been received or (2) a retry limit has been reached and no EndVerifyAck message has been received. Both the retransmission interval and the retry limit are local configuration parameters.
EndVerify消息将定期传输，直到（1）收到EndVerifyAck消息或（2）达到重试限制且未收到EndVerifyAck消息。重传间隔和重试限制都是本地配置参数。
The EndVerifyAck message is sent over the control channel and is used to acknowledge the termination of the link verification process. The format is as follows:
EndVerifyAck消息通过控制信道发送，用于确认链路验证过程的终止。格式如下:
<EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
<EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the EndVerify message being acknowledged.
消息\u ID\u ACK对象的内容必须从正在确认的EndVerify消息中获取。
The Test message is transmitted over the data link and is used to verify its physical connectivity. Unless explicitly stated, these messages MUST be transmitted over UDP like all other LMP messages. The format of the Test messages is as follows:
测试消息通过数据链路传输，用于验证其物理连接。除非明确说明，否则这些消息必须像所有其他LMP消息一样通过UDP传输。测试消息的格式如下所示：
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
Note that this message is sent over a data link and NOT over the control channel. The transport mechanism for the Test message is negotiated using the Verify Transport Mechanism field of the BEGIN_VERIFY object and the Verify Transport Response field of the BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).
请注意，此消息通过数据链路而不是控制通道发送。使用BEGIN_Verify对象的Verify transport mechanism字段和BEGIN_Verify_ACK对象的Verify transport Response字段协商测试消息的传输机制（参见第13.8和13.9节）。
The local (transmitting) node sends a given Test message periodically (at least once every VerifyInterval ms) on the corresponding data link until (1) it receives a correlating TestStatusSuccess or TestStatusFailure message on the control channel from the remote (receiving) node or (2) all active control channels between the two nodes have failed. The remote node will send a given TestStatus message periodically over the control channel until it receives either a correlating TestStatusAck message or an EndVerify message.
本地（发送）节点在相应的数据链路上周期性地发送给定的测试消息（至少每VerifyInterval ms发送一次），直到（1）从远程（接收）节点或（2）在控制信道上接收到相关的TestStatusSuccess或TestStatusFailure消息两个节点之间的所有活动控制通道都出现故障。远程节点将通过控制通道定期发送给定的TestStatus消息，直到收到相关TestStatusAck消息或EndVerify消息。
The TestStatusSuccess message is transmitted over the control channel and is used to transmit the mapping between the local Interface_Id and the Interface_Id that was received in the Test message.
TestStatusSuccess消息通过控制通道传输，用于传输本地接口Id和测试消息中接收的接口Id之间的映射。
<TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <LOCAL_INTERFACE_ID>
<REMOTE_INTERFACE_ID> <VERIFY_ID>
<TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <LOCAL_INTERFACE_ID>
<REMOTE_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The contents of the REMOTE_INTERFACE_ID object MUST be obtained from the corresponding Test message being positively acknowledged.
远程接口ID对象的内容必须从确认的相应测试消息中获取。
The TestStatusFailure message is transmitted over the control channel and is used to indicate that the Test message was not received.
TestStatusFailure消息通过控制信道传输，用于指示未收到测试消息。
<TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
<VERIFY_ID>
<TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
<VERIFY_ID>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The TestStatusAck message is used to acknowledge receipt of the TestStatusSuccess or TestStatusFailure messages.
TestStatusAck消息用于确认收到TestStatusSuccess或TestStatusFailure消息。
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the TestStatusSuccess or TestStatusFailure message being acknowledged.
必须从正在确认的TestStatusSuccess或TestStatusFailure消息中获取消息\u ID\u ACK对象的内容。
The LinkSummary message is used to synchronize the Interface_Ids and correlate the properties of the TE link. The format of the LinkSummary message is as follows:
LinkSummary消息用于同步接口ID并关联TE链接的属性。LinkSummary消息的格式如下：
<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...]
<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...]
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The LinkSummary message can be exchanged any time a link is not in the Verification process. The LinkSummary message MUST be periodically transmitted until (1) the node receives a LinkSummaryAck or LinkSummaryNack message or (2) a retry limit has been reached and no LinkSummaryAck or LinkSummaryNack message has been received. Both the retransmission interval and the retry limit are local configuration parameters.
当链接不在验证过程中时，可以随时交换LinkSummary消息。必须定期发送LinkSummary消息，直到（1）节点收到LinkSummaryAck或LinkSummaryNack消息，或（2）达到重试限制且未收到LinkSummaryAck或LinkSummaryNack消息。重传间隔和重试限制都是本地配置参数。
The LinkSummaryAck message is used to indicate agreement on the Interface_Id synchronization and acceptance/agreement on all the link parameters. It is on the reception of this message that the local node makes the Link_Id associations.
LinkSummaryAck消息用于表示对接口Id同步的一致性以及对所有链路参数的接受/一致性。本地节点正是在接收到该消息时进行链接Id关联的。
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The LinkSummaryNack message is used to indicate disagreement on non-negotiated parameters or propose other values for negotiable parameters. Parameters on which agreement was reached MUST NOT be included in the LinkSummaryNack message.
LinkSummaryNack消息用于表示对非协商参数的异议，或为协商参数提出其他值。LinkSummaryNack消息中不得包含已达成协议的参数。
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...]
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...]
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The DATA_LINK objects MUST include acceptable values for all negotiable parameters. If the LinkSummaryNack includes DATA_LINK objects for non-negotiable parameters, they MUST be copied from the DATA_LINK objects received in the LinkSummary message.
数据链接对象必须包括所有可协商参数的可接受值。如果LinkSummaryNack包含不可协商参数的数据链接对象，则必须从LinkSummary消息中接收的数据链接对象复制这些对象。
If the LinkSummaryNack message is received and only includes negotiable parameters, then a new LinkSummary message SHOULD be sent. The values received in the new LinkSummary message SHOULD take into account the acceptable parameters included in the LinkSummaryNack message.
如果接收到LinkSummaryNack消息且仅包含可协商参数，则应发送新的LinkSummary消息。新LinkSummary消息中接收的值应考虑LinkSummaryNack消息中包含的可接受参数。
If the LinkSummary message is received with unacceptable, non-negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable non-negotiable LINK_SUMMARY parameters."
如果接收到的LinkSummary消息包含不可接受的、不可协商的参数，则错误代码必须指示“不可接受的不可协商的LinkSummary参数”
If the LinkSummary message is received with unacceptable negotiable parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY parameters."
如果接收到带有不可接受的可协商参数的LinkSummary消息，则错误代码必须指示“重新协商LinkSummary参数”
If the LinkSummary message is received with an invalid TE_LINK object, the ERROR_CODE MUST indicate "Invalid TE_LINK object."
如果接收到的LinkSummary消息包含无效的TE_链接对象，则错误代码必须指示“无效的TE_链接对象”
If the LinkSummary message is received with an invalid DATA_LINK object, the ERROR_CODE MUST indicate "Invalid DATA_LINK object."
如果接收到的LinkSummary消息包含无效的数据链接对象，则错误代码必须指示“无效的数据链接对象”
If the LinkSummary message is received with a TE_LINK object but the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown TE_LINK object C-Type."
如果使用TE_链接对象接收到LinkSummary消息，但C类型未知，则错误代码必须指示“未知TE_链接对象C类型”
If the LinkSummary message is received with a DATA_LINK object but the C-Type is unknown, the ERROR_CODE MUST indicate, "Unknown DATA_LINK object C-Type."
如果接收到带有数据链接对象的LinkSummary消息，但C-Type未知，则错误代码必须指示“未知数据链接对象C-Type”
The ChannelStatus message is sent over the control channel and is used to notify an LMP neighbor of the status of a data link. A node that receives a ChannelStatus message MUST respond with a ChannelStatusAck message. The format is as follows:
ChannelStatus消息通过控制信道发送，用于通知LMP邻居数据链路的状态。接收ChannelStatus消息的节点必须使用ChannelStatusAck消息进行响应。格式如下:
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS>
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
If the CHANNEL_STATUS object does not include any Interface_Ids, then this indicates the entire TE Link has failed.
如果CHANNEL_STATUS对象不包括任何Interface_ID，则表示整个TE链接已失败。
The ChannelStatusAck message is used to acknowledge receipt of the ChannelStatus Message. The format is as follows:
ChannelStatusAck消息用于确认收到ChannelStatus消息。格式如下:
<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the ChannelStatus message being acknowledged.
消息\u ID\u ACK对象的内容必须从正在确认的ChannelStatus消息中获取。
The ChannelStatusRequest message is sent over the control channel and is used to request the status of one or more data link(s). A node that receives a ChannelStatusRequest message MUST respond with a ChannelStatusResponse message. The format is as follows:
ChannelStatusRequest消息通过控制信道发送，用于请求一个或多个数据链路的状态。接收ChannelStatusRequest消息的节点必须使用ChannelStatusResponse消息进行响应。格式如下:
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>]
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>]
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
If the CHANNEL_STATUS_REQUEST object is not included, then the ChannelStatusRequest is being used to request the status of ALL of the data link(s) of the TE Link.
如果未包括CHANNEL_STATUS_REQUEST对象，则CHANNEL STATUS REQUEST用于请求TE链路的所有数据链路的状态。
The ChannelStatusResponse message is used to acknowledge receipt of the ChannelStatusRequest Message and notify the LMP neighbor of the status of the data channel(s). The format is as follows:
ChannelStatusResponse消息用于确认收到ChannelStatusRequest消息，并将数据信道的状态通知LMP邻居。格式如下:
<ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
<CHANNEL_STATUS>
<ChannelStatusResponse Message> ::= <Common Header> <MESSAGE_ID_ACK>
<CHANNEL_STATUS>
The above transmission order SHOULD be followed.
应遵循上述传输顺序。
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ChannelStatusRequest message being acknowledged.
消息\u ID\u ACK对象的内容必须从正在确认的ChannelStatusRequest消息中获取。
Class = 1
Class = 1
o C-Type = 1, LOCAL_CCID
o C型=1，本地\u CCID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits
CC_Id:32位
This MUST be node-wide unique and non-zero. The CC_Id identifies the control channel of the sender associated with the message.
这必须是节点范围内唯一且非零的。CC_Id标识与消息关联的发送方的控制通道。
This object is non-negotiable.
这个目标是不可谈判的。
o C-Type = 2, REMOTE_CCID
o C-Type=2，远程CCID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits
CC_Id:32位
This identifies the remote node's CC_Id and MUST be non-zero.
这标识远程节点的CC_Id，并且必须为非零。
This object is non-negotiable.
这个目标是不可谈判的。
Class = 2
Class = 2
o C-Type = 1, LOCAL_NODE_ID
o C-Type=1，本地节点ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id:
节点Id:
This identities the node that originated the LMP packet.
这标识了发起LMP数据包的节点。
This object is non-negotiable.
这个目标是不可谈判的。
o C-Type = 2, REMOTE_NODE_ID
o C-Type=2，远程节点ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id:
节点Id:
This identities the remote node.
这将标识远程节点。
This object is non-negotiable.
这个目标是不可谈判的。
Class = 3
Class = 3
o C-Type = 1, IPv4 LOCAL_LINK_ID
o C-Type=1，IPv4本地链路ID
o C-Type = 2, IPv4 REMOTE_LINK_ID
o C-Type=2，IPv4远程链接ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, IPv6 LOCAL_LINK_ID
o C-Type=3，IPv6本地链路ID
o C-Type = 4, IPv6 REMOTE_LINK_ID
o C-Type=4，IPv6远程链接ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 5, Unnumbered LOCAL_LINK_ID
o C-Type=5，未编号的本地链接ID
o C-Type = 6, Unnumbered REMOTE_LINK_ID
o C-Type=6，未编号的远程链接ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link_Id:
链接Id:
For LOCAL_LINK_ID, this identifies the sender's Link associated with the message. This value MUST be non-zero.
对于LOCAL_LINK_ID，它标识与邮件关联的发件人链接。此值必须为非零。
For REMOTE_LINK_ID, this identifies the remote node's Link_Id and MUST be non-zero.
对于远程链接ID，它标识远程节点的链接ID，并且必须为非零。
This object is non-negotiable.
这个目标是不可谈判的。
Class = 4
Class = 4
o C-Type = 1, IPv4 LOCAL_INTERFACE_ID
o C-Type=1，IPv4本地接口ID
o C-Type = 2, IPv4 REMOTE_INTERFACE_ID
o C-Type=2，IPv4远程接口\u ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, IPv6 LOCAL_INTERFACE_ID
o C-Type=3，IPv6本地接口ID
o C-Type = 4, IPv6 REMOTE_INTERFACE_ID
o C-Type=4，IPv6远程接口\u ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 5, Unnumbered LOCAL_INTERFACE_ID
o C-Type=5，未编号的本地接口ID
o C-Type = 6, Unnumbered REMOTE_INTERFACE_ID
o C-Type=6，未编号的远程接口ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface_Id:
接口Id:
For the LOCAL_INTERFACE_ID, this identifies the data link. This value MUST be node-wide unique and non-zero.
对于本地接口ID，它标识数据链路。此值必须在节点范围内唯一且非零。
For the REMOTE_INTERFACE_ID, this identifies the remote node's data link. The Interface_Id MUST be non-zero.
对于远程接口ID，它标识远程节点的数据链路。接口Id必须为非零。
This object is non-negotiable.
这个目标是不可谈判的。
Class = 5
Class = 5
o C-Type=1, MessageId
o C-Type=1，MessageId
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_Id:
消息Id:
The Message_Id field is used to identify a message. This value is incremented and only decreases when the value wraps. This is used for message acknowledgment.
Message_Id字段用于标识消息。此值将递增，仅在值换行时减小。这用于消息确认。
This object is non-negotiable.
这个目标是不可谈判的。
o C-Type = 2, MessageIdAck
o C-Type=2，MessageIdAck
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_Id:
消息Id:
The Message_Id field is used to identify the message being acknowledged. This value is copied from the MESSAGE_ID object of the message being acknowledged.
Message_Id字段用于标识正在确认的消息。此值是从正在确认的消息的消息\u ID对象复制的。
This object is non-negotiable.
这个目标是不可谈判的。
Class = 6.
等级=6。
o C-Type = 1, HelloConfig
o C-Type=1，HelloConfig
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | HelloDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval: 16 bits.
HelloInterval:16位。
Indicates how frequently the Hello packets will be sent and is measured in milliseconds (ms).
指示发送Hello数据包的频率，以毫秒（ms）为单位。
HelloDeadInterval: 16 bits.
HelloDeadInterval:16位。
If no Hello packets are received within the HelloDeadInterval, the control channel is assumed to have failed. The HelloDeadInterval is measured in milliseconds (ms). The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval.
如果HelloDeadInterval内未接收到Hello数据包，则假定控制通道已失败。HelloDeadInterval的测量单位为毫秒（ms）。HelloDeadInterval必须大于HelloInterval，并且至少应为HelloInterval值的3倍。
If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero.
如果未使用LMP的快速保持活动机制，则必须将HelloInterval和HelloDeadInterval设置为零。
Class = 7
Class = 7
o C-Type = 1, Hello
o C-Type=1，您好
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RcvSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RcvSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TxSeqNum: 32 bits
TxSeqNum:32位
This is the current sequence number for this Hello message. This sequence number will be incremented when the sequence number is reflected in the RcvSeqNum of a Hello packet that is received over the control channel.
这是此Hello消息的当前序列号。当序列号反映在通过控制信道接收的Hello数据包的RcvSeqNum中时，该序列号将增加。
TxSeqNum=0 is not allowed. TxSeqNum=1 is used to indicate that this is the first Hello message sent over the control channel.
TxSeqNum=0是不允许的。TxSeqNum=1用于指示这是通过控制通道发送的第一条Hello消息。
RcvSeqNum: 32 bits
RcvSeqNum:32位
This is the sequence number of the last Hello message received over the control channel. RcvSeqNum=0 is used to indicate that a Hello message has not yet been received.
这是通过控制通道接收的最后一条Hello消息的序列号。RcvSeqNum=0用于指示尚未收到Hello消息。
This object is non-negotiable.
这个目标是不可谈判的。
Class = 8
Class = 8
o C-Type = 1
o C型=1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | VerifyInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Data Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | (Reserved) | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TransmissionRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | VerifyInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Data Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | (Reserved) | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TransmissionRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
保留字段应作为零发送，并在收到时忽略。
Flags: 16 bits
标志：16位
The following flags are defined:
定义了以下标志：
0x0001 Verify all Links
0x0001验证所有链接
If this bit is set, the verification process checks all unallocated links; else it only verifies new ports or component links that are to be added to this TE link.
如果设置了该位，验证过程将检查所有未分配的链接；否则，它只验证要添加到此TE链接的新端口或组件链接。
0x0002 Data Link Type
0x0002数据链路类型
If set, the data links to be verified are ports, otherwise they are component links
如果已设置，则要验证的数据链路为端口，否则为组件链路
VerifyInterval: 16 bits
验证间隔：16位
This is the interval between successive Test messages and is measured in milliseconds (ms).
这是连续测试消息之间的间隔，以毫秒（ms）为单位。
Number of Data Links: 32 bits
数据链路数：32位
This is the number of data links that will be verified.
这是将要验证的数据链接数。
EncType: 8 bits
加密类型：8位
This is the encoding type of the data link. The defined EncType values are consistent with the LSP Encoding Type values of [RFC3471].
这是数据链路的编码类型。定义的EncType值与[RFC3471]的LSP编码类型值一致。
Verify Transport Mechanism: 16 bits
验证传输机制：16位
This defines the transport mechanism for the Test Messages. The scope of this bit mask is restricted to each encoding type. The local node will set the bits corresponding to the various mechanisms it can support for transmitting LMP test messages. The receiver chooses the appropriate mechanism in the BeginVerifyAck message.
这定义了测试消息的传输机制。此位掩码的范围仅限于每种编码类型。本地节点将设置对应于其可支持的用于传输LMP测试消息的各种机制的位。接收方在BeginVerifyAck消息中选择适当的机制。
The following flag is defined across all Encoding Types. All other flags are dependent on the Encoding Type.
以下标志是在所有编码类型中定义的。所有其他标志都取决于编码类型。
0x8000 Payload:Test Message transmitted in the payload
0x8000有效负载：在有效负载中传输的测试消息
Capable of transmitting Test messages in the payload. The Test message is sent as an IP packet as defined above.
能够在有效载荷中传输测试消息。测试消息作为上面定义的IP数据包发送。
TransmissionRate: 32 bits
传输速率：32位
This is the transmission rate of the data link over which the Test messages will be transmitted. This is expressed in bytes per second and represented in IEEE floating-point format.
这是将通过其传输测试消息的数据链路的传输速率。这以每秒字节数表示，并以IEEE浮点格式表示。
Wavelength: 32 bits
波长：32位
When a data link is assigned to a port or component link that is capable of transmitting multiple wavelengths (e.g., a fiber or waveband-capable port), it is essential to know which wavelength the test messages will be transmitted over. This value corresponds to the wavelength at which the Test messages will be transmitted over and has local significance. If there is no ambiguity as to the wavelength over which the message will be sent, then this value SHOULD be set to 0.
当数据链路分配给能够传输多个波长的端口或组件链路（例如，光纤或波段端口）时，必须知道测试消息将通过哪个波长传输。该值对应于测试消息将在其上传输的波长，并且具有局部意义。如果发送消息的波长没有歧义，则该值应设置为0。
Class = 9
Class = 9
o C-Type = 1
o C型=1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | Verify_Transport_Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | Verify_Transport_Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyDeadInterval: 16 bits
VerifyDeadInterval:16位
If a Test message is not detected within the VerifyDeadInterval, then a node will send the TestStatusFailure message for that data link.
如果在VerifyDeadInterval内未检测到测试消息，则节点将为该数据链路发送TestStatusFailure消息。
Verify_Transport_Response: 16 bits
验证\u传输\u响应：16位
The recipient of the BeginVerify message (and the future recipient of the TEST messages) chooses the transport mechanism from the various types that are offered by the transmitter of the Test messages. One and only one bit MUST be set in the verification transport response.
BeginVerify消息的接收者（以及测试消息的未来接收者）从测试消息的发送者提供的各种类型中选择传输机制。验证传输响应中必须设置一个且仅设置一个位。
This object is non-negotiable.
这个目标是不可谈判的。
Class = 10
Class = 10
o C-Type = 1
o C型=1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verify_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verify_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Verify_Id: 32 bits
验证\u Id:32位
This is used to differentiate Test messages from different TE links and/or LMP peers. This is a node-unique value that is assigned by the recipient of the BeginVerify message.
这用于区分来自不同TE链路和/或LMP对等方的测试消息。这是由BeginVerify消息的收件人分配的节点唯一值。
This object is non-negotiable.
这个目标是不可谈判的。
Class = 11
Class = 11
o C-Type = 1, IPv4 TE_LINK
o C-Type=1，IPv4 TE_链路
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 2, IPv6 TE_LINK
o C-Type=2，IPv6 TE_链路
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Link_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, Unnumbered TE_LINK
o C型=3，未编号的TE_链接
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Link_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
保留字段应作为零发送，并在收到时忽略。
Flags: 8 bits
标志：8位
The following flags are defined. All other bit-values are reserved and should be sent as zero and ignored on receipt.
定义了以下标志。所有其他位值均保留，应作为零发送，并在收到时忽略。
0x01 Fault Management Supported.
支持0x01故障管理。
0x02 Link Verification Supported.
支持0x02链接验证。
Local_Link_Id:
本地链接Id:
This identifies the node's local Link_Id and MUST be non-zero.
这标识节点的本地链接Id，并且必须为非零。
Remote_Link_Id:
远程链接Id:
This identifies the remote node's Link_Id and MUST be non-zero.
这标识远程节点的链接Id，并且必须为非零。
Class = 12
Class = 12
o C-Type = 1, IPv4 DATA_LINK
o C-Type=1，IPv4数据链路
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 2, IPv6 DATA_LINK
o C-Type=2，IPv6数据链路
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local_Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Local_Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Remote_Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, Unnumbered DATA_LINK
o C-Type=3，未编号的数据链路
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote_Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
保留字段应作为零发送，并在收到时忽略。
Flags: 8 bits
标志：8位
The following flags are defined. All other bit-values are reserved and should be sent as zero and ignored on receipt.
定义了以下标志。所有其他位值均保留，应作为零发送，并在收到时忽略。
0x01 Interface Type: If set, the data link is a port, otherwise it is a component link.
0x01接口类型：如果设置，则数据链路为端口，否则为组件链路。
0x02 Allocated Link: If set, the data link is currently allocated for user traffic. If a single Interface_Id is used for both the transmit and receive data links, then this bit only applies to the transmit interface.
0x02已分配链路：如果已设置，则数据链路当前已分配给用户流量。如果发送和接收数据链路均使用单个接口标识，则该位仅适用于发送接口。
0x04 Failed Link: If set, the data link is failed and not suitable for user traffic.
0x04失败链路：如果设置，则数据链路失败，不适合用户通信。
Local_Interface_Id:
本地接口Id:
This is the local identifier of the data link. This MUST be node-wide unique and non-zero.
这是数据链路的本地标识符。这必须是节点范围内唯一且非零的。
Remote_Interface_Id:
远程接口Id:
This is the remote identifier of the data link. This MUST be non-zero.
这是数据链路的远程标识符。这必须是非零。
Subobjects
子对象
The contents of the DATA_LINK object consist of a series of variable-length data items called subobjects. The subobjects are defined in Section 13.12.1 below.
数据链接对象的内容由一系列称为子对象的可变长度数据项组成。子对象定义见下文第13.12.1节。
A DATA_LINK object may contain more than one subobject. More than one subobject of the same Type may appear if multiple capabilities are supported over the data link.
数据链接对象可能包含多个子对象。如果数据链路上支持多个功能，则可能会出现多个相同类型的子对象。
The contents of the DATA_LINK object include a series of variable-length data items called subobjects. Each subobject has the form:
数据链接对象的内容包括一系列称为子对象的可变长度数据项。每个子对象具有以下形式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
Type: 8 bits
类型：8位
The Type indicates the type of contents of the subobject. Currently defined values are:
类型指示子对象的内容类型。当前定义的值为：
Type = 1, Interface Switching Type
类型=1，接口切换类型
Type = 2, Wavelength
类型=2，波长
Length: 8 bits
长度：8位
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4.
长度包含子对象的总长度（字节），包括类型和长度字段。长度必须至少为4，并且必须是4的倍数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Switching Type| EncType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Switching Type| EncType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Switching Type: 8 bits
开关类型：8位
This is used to identify the local Interface Switching Type of the TE link as defined in [RFC3471].
这用于识别[RFC3471]中定义的TE链路的本地接口切换类型。
EncType: 8 bits
加密类型：8位
This is the encoding type of the data link. The defined EncType values are consistent with the LSP Encoding Type values of [RFC3471].
这是数据链路的编码类型。定义的EncType值与[RFC3471]的LSP编码类型值一致。
Minimum Reservable Bandwidth: 32 bits
最小可保留带宽：32位
This is measured in bytes per second and represented in IEEE floating point format.
这以每秒字节数为单位，并以IEEE浮点格式表示。
Maximum Reservable Bandwidth: 32 bits
最大可保留带宽：32位
This is measured in bytes per second and represented in IEEE floating point format.
这以每秒字节数为单位，并以IEEE浮点格式表示。
If the interface only supports a fixed rate, the minimum and maximum bandwidth fields are set to the same 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
保留字段应作为零发送，并在收到时忽略。
Wavelength: 32 bits
波长：32位
This value indicates the wavelength carried over the port. Values used in this field only have significance between two neighbors.
此值表示端口上携带的波长。此字段中使用的值仅在两个相邻字段之间有意义。
Class = 13
Class = 13
o C-Type = 1, IPv4 INTERFACE_ID
o C-Type=1，IPv4接口\u ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 2, IPv6 INTERFACE_ID
o C-Type=2，IPv6接口\u ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, Unnumbered INTERFACE_ID
o C-Type=3，未编号的接口\u ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel_Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|D| Channel_Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Active bit: 1 bit
活动位：1位
This indicates that the Channel is allocated to user traffic and the data link should be actively monitored.
这表明信道分配给用户通信量，并且应主动监控数据链路。
Direction bit: 1 bit
方向位：1位
This indicates the direction (transmit/receive) of the data channel referred to in the CHANNEL_STATUS object. If set, this indicates the data channel is in the transmit direction.
这表示channel_STATUS对象中引用的数据通道的方向（发送/接收）。如果设置，则表示数据通道位于传输方向。
Channel_Status: 30 bits
通道状态：30位
This indicates the status condition of a data channel. The following values are defined. All other values are reserved.
这表示数据通道的状态条件。定义了以下值。所有其他值均保留。
1 Signal Okay (OK): Channel is operational 2 Signal Degrade (SD): A soft failure caused by a BER exceeding a preselected threshold. The specific BER used to define the threshold is configured. 3 Signal Fail (SF): A hard signal failure including (but not limited to) loss of signal (LOS), loss of frame (LOF), or Line AIS.
1信号正常（OK）：通道工作2信号降级（SD）：误码率超过预选阈值导致的软故障。配置用于定义阈值的特定BER。3信号故障（SF）：硬信号故障，包括（但不限于）信号丢失（LOS）、帧丢失（LOF）或线路AIS。
This object contains one or more Interface_Ids followed by a Channel_Status field.
此对象包含一个或多个接口标识，后跟通道状态字段。
To indicate the status of the entire TE Link, there MUST be only one Interface_Id, and it MUST be zero.
要指示整个TE链路的状态，必须只有一个接口Id，并且必须为零。
This object is non-negotiable.
这个目标是不可谈判的。
Class = 14
Class = 14
o C-Type = 1, IPv4 INTERFACE_ID
o C-Type=1，IPv4接口\u ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
此对象包含一个或多个接口ID。
The Length of this object is 4 + 4N in bytes, where N is the number of Interface_Ids.
该对象的长度为4+4N（字节），其中N是接口ID的数量。
o C-Type = 2, IPv6 INTERFACE_ID
o C-Type=2，IPv6接口\u ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Interface_Id (16 bytes) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
此对象包含一个或多个接口ID。
The Length of this object is 4 + 16N in bytes, where N is the number of Interface_Ids.
该对象的长度为4+16N（字节），其中N是接口ID的数量。
o C-Type = 3, Unnumbered INTERFACE_ID
o C-Type=3，未编号的接口\u ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| : |
// : //
| : |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface_Id (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
此对象包含一个或多个接口ID。
The Length of this object is 4 + 4N in bytes, where N is the number of Interface_Ids.
该对象的长度为4+4N（字节），其中N是接口ID的数量。
This object is non-negotiable.
这个目标是不可谈判的。
Class = 20
Class = 20
o C-Type = 1, BEGIN_VERIFY_ERROR
o C-Type=1，开始\u验证\u错误
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined in network byte order (i.e., big-endian byte order):
以下位值以网络字节顺序（即大端字节顺序）定义：
0x01 = Link Verification Procedure not supported. 0x02 = Unwilling to verify. 0x04 = Unsupported verification transport mechanism. 0x08 = Link_Id configuration error. 0x10 = Unknown object C-Type.
0x01=不支持链接验证过程。0x02=不愿意验证。0x04=不支持的验证传输机制。0x08=链路Id配置错误。0x10=未知对象C类型。
All other bit-values are reserved and should be sent as zero and ignored on receipt.
所有其他位值均保留，应作为零发送，并在收到时忽略。
Multiple bits may be set to indicate multiple errors.
可以设置多个位以指示多个错误。
This object is non-negotiable.
这个目标是不可谈判的。
If a BeginVerifyNack message is received with Error Code 2, the node that originated the BeginVerify SHOULD schedule a BeginVerify retransmission after Rf seconds, where Rf is a locally defined parameter.
如果收到错误代码为2的BeginVerifyNack消息，则发起BeginVerify的节点应在Rf秒后安排BeginVerify重新传输，其中Rf是本地定义的参数。
o C-Type = 2, LINK_SUMMARY_ERROR
o C-Type=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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ERROR CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following bit-values are defined in network byte order (i.e., big-endian byte order):
以下位值以网络字节顺序（即大端字节顺序）定义：
0x01 = Unacceptable non-negotiable LINK_SUMMARY parameters. 0x02 = Renegotiate LINK_SUMMARY parameters. 0x04 = Invalid TE_LINK Object. 0x08 = Invalid DATA_LINK Object. 0x10 = Unknown TE_LINK object C-Type. 0x20 = Unknown DATA_LINK object C-Type.
0x01=不可接受的不可协商链接\u摘要参数。0x02=重新协商链接\u摘要参数。0x04=无效的TE_链接对象。0x08=无效的数据链接对象。0x10=未知的TE_链接对象C类型。0x20=未知数据链接对象C类型。
All other bit-values are reserved and should be sent as zero and ignored on receipt.
所有其他位值均保留，应作为零发送，并在收到时忽略。
Multiple bits may be set to indicate multiple errors.
可以设置多个位以指示多个错误。
This object is non-negotiable.
这个目标是不可谈判的。
[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月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，2005年10月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]Berger，L.，Gan，D.，Swallow，G.，Pan，P.，Tommasi，F.，和S.Molendini，“RSVP刷新开销减少扩展”，RFC 29612001年4月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC3471] Berger, L., Ed., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用MPLS-信令功能描述”，RFC 3471，2003年1月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[RFC3784]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
There are number of attacks that an LMP protocol session can potentially experience. Some examples include:
LMP协议会话可能会遇到许多攻击。一些例子包括：
o an adversary may spoof control packets;
o 对手可以欺骗控制数据包；
o an adversary may modify the control packets in transit;
o 对手可以修改传输中的控制分组；
o an adversary may replay control packets;
o 对手可以重放控制包；
o an adversary may study a number of control packets and try to break the key using cryptographic tools. If the hash/encryption algorithm used has known weaknesses, then it becomes easy for the adversary to discover the key using simple tools.
o 对手可能会研究大量控制数据包，并尝试使用加密工具破解密钥。如果使用的散列/加密算法存在已知的弱点，那么对手就很容易使用简单的工具发现密钥。
This section specifies an IPsec-based security mechanism for LMP.
本节为LMP指定基于IPsec的安全机制。
The following requirements are applied to the mechanism described in this section.
以下要求适用于本节所述的机构。
o LMP security MUST be able to provide authentication, integrity, and replay protection.
o LMP安全必须能够提供身份验证、完整性和重播保护。
o For LMP traffic, confidentiality is not needed. Only authentication is needed to ensure that the control packets (packets sent along the LMP Control Channel) are originating from the right place and have not been modified in transit. LMP Test packets exchanged through the data links do not need to be protected.
o 对于LMP流量，不需要保密。只需验证即可确保控制数据包（沿LMP控制信道发送的数据包）来自正确的位置，并且在传输过程中未被修改。通过数据链路交换的LMP测试数据包不需要保护。
o For LMP traffic, protecting the identity of LMP end-points is not commonly required.
o 对于LMP流量，通常不需要保护LMP端点的身份。
o The security mechanism should provide for well defined key management schemes. The key management schemes should be well analyzed to be cryptographically secure. The key management schemes should be scalable. In addition, the key management system should be automatic.
o 安全机制应提供定义良好的密钥管理方案。密钥管理方案应该经过很好的分析，以确保加密安全。密钥管理方案应该是可伸缩的。此外，密钥管理系统应该是自动的。
o The algorithms used for authentication MUST be cryptographically sound. Also, the security protocol MUST allow for negotiating and using different authentication algorithms.
o 用于身份验证的算法必须是可靠的加密算法。此外，安全协议必须允许协商和使用不同的身份验证算法。
IPsec is a protocol suite that is used to secure communication at the network layer between two peers. This protocol is comprised of IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH [RFC2402], and IPsec ESP [RFC2406]. IKE is the key management protocol for IP networks, while AH and ESP are used to protect IP traffic. IKE is defined specific to IP domain of interpretation.
IPsec是一个协议套件，用于在网络层保护两个对等方之间的通信。该协议由IP安全体系结构文档[RFC2401]、IKE[RFC2409]、IPsec AH[RFC2402]和IPsec ESP[RFC2406]组成。IKE是IP网络的密钥管理协议，而AH和ESP用于保护IP流量。IKE的定义特定于IP解释域。
Considering the requirements described in Section 15.1, it is recommended that, where security is needed for LMP, implementations use IPsec as described below:
考虑到第15.1节中所述的要求，建议在LMP需要安全性的情况下，按照如下所述使用IPsec：
1. Implementations of LMP over IPsec protocol SHOULD support manual keying mode.
1. IPsec协议上LMP的实现应支持手动键控模式。
Manual keying mode provides an easy way to set up and diagnose IPsec functionality.
手动键控模式提供了设置和诊断IPsec功能的简单方法。
However, note that manual keying mode cannot effectively support features such as replay protection and automatic re-keying. An implementer using manual keys must be aware of these limits.
但是，请注意，手动键控模式无法有效支持重播保护和自动重新键控等功能。使用手动键的实现者必须了解这些限制。
It is recommended that an implementer use manual keying only for diagnostic purposes and use dynamic keying protocol to make use of features such as replay protection and automatic re-keying.
建议实施者仅将手动键控用于诊断目的，并使用动态键控协议来利用重播保护和自动重新键控等功能。
2. IPsec ESP with trailer authentication in tunnel mode MUST be supported.
2. 必须支持在隧道模式下具有拖车身份验证的IPsec ESP。
3. Implementations MUST support authenticated key exchange protocols. IKE [RFC2409] MUST be used as the key exchange protocol if keys are dynamically negotiated between peers.
3. 实现必须支持经过身份验证的密钥交换协议。如果在对等方之间动态协商密钥，则必须将IKE[RFC2409]用作密钥交换协议。
4. Implementation MUST use the IPsec DOI [RFC2407].
4. 实现必须使用IPsec DOI[RFC2407]。
5. For IKE protocol, the identities of the SAs negotiated in Quick Mode represent the traffic that the peers agree to protect and are comprised of address space, protocol, and port information.
5. 对于IKE协议，在快速模式下协商的SA标识表示对等方同意保护的通信量，由地址空间、协议和端口信息组成。
For LMP over IPsec, it is recommended that the identity payload for Quick mode contain the following information:
对于IPsec上的LMP，建议快速模式的标识有效负载包含以下信息：
The identities MUST be of type IP addresses and the value of the identities SHOULD be the IP addresses of the communicating peers.
标识的类型必须为IP地址，标识的值应为通信对等方的IP地址。
The protocol field MUST be UDP. The port field SHOULD be set to zero to indicate port fields should be ignored. This implies all UDP traffic between the peers must be sent through the IPsec tunnel. If an implementation supports port-based selectors, it can opt for a more finely grained selector by specifying the port field to the LMP port. If, however, the peer does not use port-based selectors, the implementation MUST fall back to using a port selector value of 0.
协议字段必须是UDP。端口字段应设置为零，以指示应忽略端口字段。这意味着对等方之间的所有UDP通信必须通过IPsec隧道发送。如果一个实现支持基于端口的选择器，它可以通过为LMP端口指定端口字段来选择更细粒度的选择器。但是，如果对等方不使用基于端口的选择器，则实现必须退回到使用端口选择器值0。
6. Aggressive mode of IKE negotiation MUST be supported.
6. 必须支持积极的IKE协商模式。
When IPsec is configured to be used with a peer, all LMP messages are expected to be sent over the IPsec tunnel (crypto channel). Similarly, an LMP receiver configured to use Ipsec with a peer should reject any LMP traffic that does not come through the crypto channel.
当IPsec配置为与对等机一起使用时，所有LMP消息都将通过IPsec隧道（加密通道）发送。类似地，配置为与对等方一起使用Ipsec的LMP接收器应拒绝任何不通过加密通道的LMP通信。
The crypto channel can be pre-setup with the LMP neighbor, or the first LMP message sent to the peer can trigger the creation of the IPsec tunnel.
可以使用LMP邻居预先设置加密通道，或者发送给对等方的第一条LMP消息可以触发IPsec隧道的创建。
A set of control channels can share the same crypto channel. When LMP Hellos are used to monitor the status of the control channel, it is important to keep in mind that the keep-alive failure in a control channel may also be due to a failure in the crypto channel. The following method is recommended to ensure that an LMP communication path between two peers is working properly.
一组控制通道可以共享同一加密通道。当使用LMP Hellos监控控制信道的状态时，务必记住，控制信道中的保持活动故障也可能是由于加密信道中的故障造成的。建议使用以下方法来确保两个对等方之间的LMP通信路径正常工作。
o If LMP Hellos detect a failure on a control channel, switch to an alternate control channel and/or try to establish a new control channel.
o 如果LMP Hellos检测到控制通道故障，则切换到备用控制通道和/或尝试建立新的控制通道。
o Ensure the health of the control channels using LMP Hellos. If all control channels indicate a failure and it is not possible to bring up a new control channel, tear down all existing control channels. Also, tear down the crypto channel (both the IKE SA and IPsec SAs).
o 使用LMP Hellos确保控制通道的运行状况。如果所有控制通道都指示故障，并且无法启动新的控制通道，请拆除所有现有控制通道。此外，拆除加密通道（IKE SA和IPsec SA）。
o Reestablish the crypto channel. Failure to establish a crypto channel indicates a fatal failure for LMP communication.
o 重新建立加密通道。未能建立加密通道表示LMP通信出现致命故障。
o Bring up the control channel. Failure to bring up the control channel indicates a fatal failure for LMP communication.
o 打开控制通道。无法启动控制通道表示LMP通信出现致命故障。
When LMP peers are dynamically discovered (particularly the initiator), the following points should be noted:
动态发现LMP对等点（尤其是启动器）时，应注意以下几点：
When using pre-shared key authentication in identity protection mode (main mode), the pre-shared key is required to compute the value of SKEYID (used for deriving keys to encrypt messages during key exchange). In main mode of IKE, the pre-shared key to be used has to be identified before receiving the peer's identity payload. The pre-shared key is required for calculating SKEYID. The only information available about the peer at this point is its IP address from which the negotiation came from. Keying off the IP address of a peer to get the pre-shared key is not possible since the addresses are dynamic and not known beforehand.
在身份保护模式（主模式）下使用预共享密钥身份验证时，需要预共享密钥来计算SKEYID的值（用于导出密钥以在密钥交换期间加密消息）。在IKE的主模式中，必须在接收对等方的身份有效载荷之前识别要使用的预共享密钥。计算SKEYID时需要预共享密钥。此时，关于对等方的唯一可用信息是其协商来源的IP地址。不可能通过键入对等方的IP地址来获取预共享密钥，因为地址是动态的，并且事先不知道。
Aggressive mode key exchange can be used since identification payloads are sent in the first message.
由于识别有效载荷在第一条消息中发送，因此可以使用主动模式密钥交换。
Note, however, that aggressive mode is prone to passive denial of service attacks. Using a shared secret (group shared secret) among a number of peers is strongly discouraged because this opens up the solution to man-in-the-middle attacks.
但是，请注意，攻击模式容易受到被动拒绝服务攻击。强烈反对在多个对等方之间使用共享秘密（组共享秘密），因为这为中间人攻击打开了解决方案。
Digital-signature-based authentication is not prone to such problems. It is RECOMMENDED that a digital-signature-based authentication mechanism be used where possible.
基于数字签名的身份验证不容易出现此类问题。建议尽可能使用基于数字签名的身份验证机制。
If pre-shared-key-based authentication is required, then aggressive mode SHOULD be used. IKE pre-shared authentication key values SHOULD be protected in a manner similar to the user's account password.
如果需要基于预共享密钥的身份验证，则应使用主动模式。IKE预共享身份验证密钥值应以类似于用户帐户密码的方式进行保护。
The IANA has assigned port number 701 to LMP.
IANA已将端口号701分配给LMP。
In the following, guidelines are given for IANA assignment for each LMP name space. Ranges are specified for Private Use, to be assigned by Expert Review, and to be assigned by Standards Action (as defined in [RFC2434].
下面给出了每个LMP名称空间的IANA分配准则。指定范围供私人使用，由专家评审指定，并由标准行动指定（如[RFC2434]中的定义）。
Assignments made from LMP number spaces set aside for Private Use (i.e., for proprietary extensions) need not be documented. Independent LMP implementations using the same Private Use code points will in general not interoperate, so care should be exercised in using these code points in a multi-vendor network.
不需要记录从专用LMP编号空间（即专用扩展）进行的分配。使用相同专用代码点的独立LMP实现通常不会进行互操作，因此在多供应商网络中使用这些代码点时应小心。
Assignments made from LMP number spaces to be assigned by Expert Review are to be reviewed by an Expert designated by the IESG. The intent in this document is that code points from these ranges are used for Experimental extensions; as such, assignments MUST be accompanied by Experimental RFCs. If deployment suggests that these extensions are useful, then they should be described in Standards Track RFCs, and new code points from the Standards Action ranges MUST be assigned.
由专家评审分配的LMP编号空间的分配应由IESG指定的专家进行评审。本文档的目的是将这些范围中的代码点用于实验扩展；因此，作业必须附有实验性RFC。如果部署表明这些扩展是有用的，那么应该在标准跟踪RFC中描述它们，并且必须分配来自标准操作范围的新代码点。
Assignments from LMP number spaces to be assigned by Standards Action MUST be documented by a Standards Track RFC, typically submitted to an IETF Working Group, but in any case following the usual IETF procedures for Proposed Standards.
由标准行动分配的LMP编号空间的分配必须由标准跟踪RFC记录，通常提交给IETF工作组，但在任何情况下，均应遵循拟定标准的IETF常规程序。
The Reserved bits of the LMP Common Header should be allocated by Standards Action, pursuant to the policies outlined in [RFC2434].
LMP公共报头的保留位应由标准行动根据[RFC2434]中概述的策略进行分配。
LMP defines the following name spaces that require management:
LMP定义了以下需要管理的名称空间：
- LMP Message Type. - LMP Object Class. - LMP Object Class type (C-Type). These are unique within the Object Class. - LMP Sub-object Class type (Type). These are unique within the Object Class.
- LMP消息类型。-LMP对象类LMP对象类类型（C类型）。这些在对象类中是唯一的。-LMP子对象类类型（类型）。这些在对象类中是唯一的。
The LMP Message Type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-127 are allocated by Standards Action, 128-240 are allocated through an Expert Review, and 241-255 are reserved for Private Use.
LMP消息类型名称空间应按如下方式分配：根据[RFC2434]中概述的政策，0-127范围内的数字由标准行动分配，128-240通过专家评审分配，241-255保留供私人使用。
The LMP Object Class name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range of 0-127 are allocated by Standards Action, 128-247 are allocated through an Expert Review, and 248-255 are reserved for Private Use.
LMP对象类名称空间应分配如下：根据[RFC2434]中概述的政策，0-127范围内的数字由标准行动分配，128-247通过专家评审分配，248-255保留供私人使用。
The policy for allocating values out of the LMP Object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which the Object Class names are allocated.
从LMP对象类名称空间中分配值的策略是特定类实例定义的一部分。定义类时，其定义还必须包括分配对象类名所依据的策略的描述。
The policy for allocating values out of the LMP Sub-object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which sub-objects are allocated.
从LMP子对象类名称空间中分配值的策略是特定类实例定义的一部分。定义类时，其定义还必须包括分配子对象所依据的策略的描述。
The following name spaces have been assigned by IANA:
IANA分配了以下名称空间：
------------------------------------------------------------------
LMP Message Type name space
------------------------------------------------------------------
LMP Message Type name space
o Config message (Message type = 1)
o 配置消息（消息类型=1）
o ConfigAck message (Message type = 2)
o 配置确认消息（消息类型=2）
o ConfigNack message (Message type = 3)
o ConfigNack消息（消息类型=3）
o Hello message (Message type = 4)
o 你好消息（消息类型=4）
o BeginVerify message (Message type = 5)
o BeginVerify消息（消息类型=5）
o BeginVerifyAck message (Message type = 6)
o BeginVerifyAck消息（消息类型=6）
o BeginVerifyNack message (Message type = 7)
o BeginVerifyNack消息（消息类型=7）
o EndVerify message (Message type = 8)
o EndVerify消息（消息类型=8）
o EndVerifyAck message (Message type = 9)
o EndVerifyAck消息（消息类型=9）
o Test message (Message type = 10)
o 测试消息（消息类型=10）
o TestStatusSuccess message (Message type = 11)
o TestStatusSuccess消息（消息类型=11）
o TestStatusFailure message (Message type = 12)
o TestStatusFailure消息（消息类型=12）
o TestStatusAck message (Message type = 13)
o TestStatusAck消息（消息类型=13）
o LinkSummary message (Message type = 14)
o 链接摘要消息（消息类型=14）
o LinkSummaryAck message (Message type = 15)
o LinkSummaryAck消息（消息类型=15）
o LinkSummaryNack message (Message type = 16)
o LinkSummaryNack消息（消息类型=16）
o ChannelStatus message (Message type = 17)
o 信道状态消息（消息类型=17）
o ChannelStatusAck message (Message type = 18)
o ChannelStatusAck消息（消息类型=18）
o ChannelStatusRequest message (Message type = 19)
o ChannelStatusRequest消息（消息类型=19）
o ChannelStatusResponse message (Message type = 20)
o ChannelStatusResponse消息（消息类型=20）
------------------------------------------------------------------
------------------------------------------------------------------
LMP Object Class name space and Class type (C-Type)
LMP对象类名称空间和类类型（C类型）
o CCID Class name (1)
o CCID类名（1）
The CCID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
CCID对象类类型名称空间应分配如下：根据[RFC2434]中概述的政策，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- LOCAL_CCID (C-Type = 1) - REMOTE_CCID (C-Type = 2)
- 本地CCID（C-Type=1）-远程CCID（C-Type=2）
o NODE_ID Class name (2)
o 节点ID类名称（2）
The NODE ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
节点ID对象类类型名称空间应按如下方式分配：根据[RFC2434]中概述的策略，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- LOCAL_NODE_ID (C-Type = 1) - REMOTE_NODE_ID (C-Type = 2)
- 本地节点ID（C-Type=1）-远程节点ID（C-Type=2）
o LINK_ID Class name (3)
o 链接ID类名（3）
The LINK_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
链接ID对象类类型名称空间的分配应如下所示：根据[RFC2434]中概述的政策，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- IPv4 LOCAL_LINK_ID (C-Type = 1) - IPv4 REMOTE_LINK_ID (C-Type = 2) - IPv6 LOCAL_LINK_ID (C-Type = 3) - IPv6 REMOTE_LINK_ID (C-Type = 4) - Unnumbered LOCAL_LINK_ID (C-Type = 5) - Unnumbered REMOTE_LINK_ID (C-Type = 6)
- IPv4本地链接ID（C-Type=1）-IPv4远程链接ID（C-Type=2）-IPv6本地链接ID（C-Type=3）-IPv6远程链接ID（C-Type=4）-未编号的本地链接ID（C-Type=5）-未编号的远程链接ID（C-Type=6）
o INTERFACE_ID Class name (4)
o 接口ID类名（4）
The INTERFACE_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
接口ID对象类类型名称空间应按如下方式分配：根据[RFC2434]中概述的政策，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- IPv4 LOCAL_INTERFACE_ID (C-Type = 1) - IPv4 REMOTE_INTERFACE_ID (C-Type = 2) - IPv6 LOCAL_INTERFACE_ID (C-Type = 3) - IPv6 REMOTE_INTERFACE_ID (C-Type = 4) - Unnumbered LOCAL_INTERFACE_ID (C-Type = 5) - Unnumbered REMOTE_INTERFACE_ID (C-Type = 6)
- IPv4本地接口ID（C-Type=1）-IPv4远程接口ID（C-Type=2）-IPv6本地接口ID（C-Type=3）-IPv6远程接口ID（C-Type=4）-未编号的本地接口ID（C-Type=5）-未编号的远程接口ID（C-Type=6）
o MESSAGE_ID Class name (5)
o 消息ID类名（5）
The MESSAGE_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
消息_ID对象类类型名称空间应分配如下：根据[RFC2434]中概述的策略，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- MESSAGE_ID (C-Type = 1) - MESSAGE_ID_ACK (C-Type = 2)
- 消息标识（C-Type=1）-消息标识确认（C-Type=2）
o CONFIG Class name (6)
o 配置类名称（6）
The CONFIG Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
配置对象类类型名称空间应按如下方式分配：根据[RFC2434]中概述的策略，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- HELLO_CONFIG (C-Type = 1)
- HELLO_配置（C-Type=1）
o HELLO Class name (7)
o 你好，类名（7）
The HELLO Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
HELLO对象类类型名称空间应按如下方式分配：根据[RFC2434]中概述的策略，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- HELLO (C-Type = 1)
- 你好（C-Type=1）
o BEGIN_VERIFY Class name (8)
o 开始验证类名（8）
The BEGIN_VERIFY Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
BEGIN_VERIFY对象类类型名称空间应按如下方式分配：根据[RFC2434]中概述的策略，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- Type 1 (C-Type = 1)
- 类型1（C型=1）
o BEGIN_VERIFY_ACK Class name (9)
o 开始验证确认类名（9）
The BEGIN_VERIFY_ACK Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
BEGIN_VERIFY_ACK对象类类型名称空间应分配如下：根据[RFC2434]中概述的策略，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- Type 1 (C-Type = 1)
- 类型1（C型=1）
o VERIFY_ID Class name (10)
o 验证\u ID类名称（10）
The VERIFY_ID Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
VERIFY_ID对象类类型名称空间的分配应如下所示：根据[RFC2434]中概述的政策，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- Type 1 (C-Type = 1)
- 类型1（C型=1）
o TE_LINK Class name (11)
o Teu链接类名称（11）
The TE_LINK Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
TE_LINK对象类类型名称空间应按如下方式分配：根据[RFC2434]中概述的政策，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- IPv4 TE_LINK (C-Type = 1) - IPv6 TE_LINK (C-Type = 2) - Unnumbered TE_LINK (C-Type = 3)
- IPv4 TE_链路（C-Type=1）-IPv6 TE_链路（C-Type=2）-未编号的TE_链路（C-Type=3）
o DATA_LINK Class name (12)
o 数据链路类名（12）
The DATA_LINK Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for private Use.
数据链路对象类类型名称空间的分配应如下所示：根据[RFC2434]中概述的政策，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- IPv4 DATA_LINK (C-Type = 1) - IPv6 DATA_LINK (C-Type = 2) - Unnumbered DATA_LINK (C-Type = 3)
- IPv4数据链路（C-Type=1）-IPv6数据链路（C-Type=2）-未编号的数据链路（C-Type=3）
The DATA_LINK Sub-object Class name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range of 0-127 are allocated by Standards Action, 128-247 are allocated through an Expert Review, and 248-255 are reserved for private Use.
数据链接子对象类名称空间应按如下方式分配：根据[RFC2434]中概述的政策，0-127范围内的数字由标准行动分配，128-247通过专家评审分配，248-255保留供私人使用。
- Interface Switching Type (sub-object Type = 1) - Wavelength (sub-object Type = 2)
- 接口切换类型（子对象类型=1）-波长（子对象类型=2）
o CHANNEL_STATUS Class name (13)
o 通道状态类别名称（13）
The CHANNEL_STATUS Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
通道状态对象类类型名称空间的分配应如下所示：根据[RFC2434]中概述的政策，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- IPv4 INTERFACE_ID (C-Type = 1) - IPv6 INTERFACE_ID (C-Type = 2) - Unnumbered INTERFACE_ID (C-Type = 3)
- IPv4接口ID（C-Type=1）-IPv6接口ID（C-Type=2）-未编号的接口ID（C-Type=3）
o CHANNEL_STATUS_REQUESTClass name (14)
o 通道\状态\请求类名称（14）
The CHANNEL_STATUS_REQUEST Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
通道状态请求对象类别名称空间应按如下方式分配：根据[RFC2434]中概述的政策，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- IPv4 INTERFACE_ID (C-Type = 1) - IPv6 INTERFACE_ID (C-Type = 2) - Unnumbered INTERFACE_ID (C-Type = 3)
- IPv4接口ID（C-Type=1）-IPv6接口ID（C-Type=2）-未编号的接口ID（C-Type=3）
o ERROR_CODE Class name (20)
o 错误代码类名（20）
The ERROR_CODE Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for private Use.
错误代码对象类类型名称空间应分配如下：根据[RFC2434]中概述的政策，0-111范围内的数字由标准行动分配，112-119通过专家评审分配，120-127保留供私人使用。
- BEGIN_VERIFY_ERROR (C-Type = 1) - LINK_SUMMARY_ERROR (C-Type = 2)
- 开始验证错误（C-Type=1）-链接摘要错误（C-Type=2）
The authors would like to thank Andre Fredette for his many contributions to this document. We would also like to thank Ayan Banerjee, George Swallow, Adrian Farrel, Dimitri Papadimitriou, Vinay Ravuri, and David Drysdale for their insightful comments and suggestions. We would also like to thank John Yu, Suresh Katukam, and Greg Bernstein for their helpful suggestions for the in-band control channel applicability.
作者要感谢Andre Fredette对本文件的许多贡献。我们还要感谢Ayan Banerjee、George Swallow、Adrian Farrel、Dimitri Papadimitriou、Vinay Ravuri和David Drysdale提出的见解和建议。我们还要感谢John Yu、Suresh Katukam和Greg Bernstein对带内控制信道适用性提出的有益建议。
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101
Jonathan P.Lang Sonos，Inc.加利福尼亚州圣巴巴拉市东格拉街223号，邮编93101
EMail: jplang@ieee.org
EMail: jplang@ieee.org
Krishna Mitra Independent Consultant
克里希纳米特拉独立顾问
EMail: kmitra@earthlink.net
EMail: kmitra@earthlink.net
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
约翰·德雷克·卡林特网络公司，加利福尼亚州圣何塞法拉利路5853号，邮编95138
EMail: jdrake@calient.net
EMail: jdrake@calient.net
Kireeti Kompella Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks，Inc.加利福尼亚州桑尼维尔北玛蒂尔达大道1194号，邮编94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
雅科夫·雷克特·朱尼珀网络公司，地址：加利福尼亚州桑尼维尔北马蒂尔达大道1194号，邮编：94089
EMail: yakov@juniper.net
EMail: yakov@juniper.net
Lou Berger Movaz Networks
Lou Berger Movaz网络公司
EMail: lberger@movaz.com
EMail: lberger@movaz.com
Debanjan Saha IBM Watson Research Center
德班詹萨哈IBM沃森研究中心
EMail: dsaha@us.ibm.com
EMail: dsaha@us.ibm.com
Debashis Basak Accelight Networks 70 Abele Road, Suite 1201 Bridgeville, PA 15017-3470
宾夕法尼亚州布里奇维尔市阿贝尔路70号1201室Debashis Basak Accelight Networks 15017-3470
EMail: dbasak@accelight.com
EMail: dbasak@accelight.com
Hal Sandick Shepard M.S. 2401 Dakota Street Durham, NC 27705
北卡罗来纳州达勒姆市达科他街2401号哈尔·桑迪克·谢泼德M.S.邮编：27705
EMail: sandick@nc.rr.com
EMail: sandick@nc.rr.com
Alex Zinin Alcatel
亚历克斯·齐宁·阿尔卡特
EMail: alex.zinin@alcatel.com
EMail: alex.zinin@alcatel.com
Bala Rajagopalan Intel Corp. 2111 NE 25th Ave Hillsboro, OR 97123
巴拉·拉贾戈帕兰英特尔公司，地址：希尔斯伯勒25大道东北2111号，邮编：97123
EMail: bala.rajagopalan@intel.com
EMail: bala.rajagopalan@intel.com
Sankar Ramamoorthi Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
加利福尼亚州桑尼维尔市北马蒂尔达大道1194号桑卡拉玛莫尔蒂Juniper Networks，Inc.94089
EMail: sankarr@juniper.net
EMail: sankarr@juniper.net
Contact Address
联系地址
Jonathan P. Lang Sonos, Inc. 829 De La Vina, Suite 220 Santa Barbara, CA 93101
Jonathan P.Lang Sonos，Inc.加利福尼亚州圣巴巴拉市德拉维纳829号220室，邮编93101
EMail: jplang@ieee.org
EMail: jplang@ieee.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。