Internet Engineering Task Force (IETF) D. Li
Request for Comments: 6898 Huawei
Updates: 4204, 4207, 4209, 5818 D. Ceccarelli
Category: Standards Track Ericsson
ISSN: 2070-1721 L. Berger
LabN
March 2013
Internet Engineering Task Force (IETF) D. Li
Request for Comments: 6898 Huawei
Updates: 4204, 4207, 4209, 5818 D. Ceccarelli
Category: Standards Track Ericsson
ISSN: 2070-1721 L. Berger
LabN
March 2013
Link Management Protocol Behavior Negotiation and Configuration Modifications
链路管理协议行为协商和配置修改
Abstract
摘要
The Link Management Protocol (LMP) is used to coordinate the properties, use, and faults of data links in networks controlled by Generalized Multiprotocol Label Switching (GMPLS). This document defines an extension to LMP to negotiate capabilities and indicate support for LMP extensions. The defined extension is compatible with non-supporting implementations.
链路管理协议（LMP）用于协调由通用多协议标签交换（GMPLS）控制的网络中数据链路的属性、使用和故障。本文档定义了LMP的一个扩展，以协商功能并表示对LMP扩展的支持。定义的扩展与不支持的实现兼容。
This document updates RFC 4204, RFC 4207, RFC 4209, and RFC 5818.
本文档更新了RFC 4204、RFC 4207、RFC 4209和RFC 5818。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6898.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6898.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. LMP Message Modifications .......................................4
2.1. Modified Message Formats ...................................4
2.2. Processing .................................................5
3. LMP Behavior Negotiation ........................................6
3.1. BehaviorConfig C-Type Format ...............................6
3.2. Processing .................................................7
4. Backward Compatibility ..........................................7
5. Security Considerations .........................................8
6. IANA Considerations .............................................9
6.1. New LMP Class Type .........................................9
6.2. New Capabilities Registry ..................................9
7. Normative References ...........................................10
8. Acknowledgments ................................................10
9. Contributors ...................................................10
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. LMP Message Modifications .......................................4
2.1. Modified Message Formats ...................................4
2.2. Processing .................................................5
3. LMP Behavior Negotiation ........................................6
3.1. BehaviorConfig C-Type Format ...............................6
3.2. Processing .................................................7
4. Backward Compatibility ..........................................7
5. Security Considerations .........................................8
6. IANA Considerations .............................................9
6.1. New LMP Class Type .........................................9
6.2. New Capabilities Registry ..................................9
7. Normative References ...........................................10
8. Acknowledgments ................................................10
9. Contributors ...................................................10
The Link Management Protocol (LMP) [RFC4204] has been successfully deployed in networks controlled by Generalized Multiprotocol Label Switching (GMPLS).
链路管理协议（LMP）[RFC4204]已成功部署在由通用多协议标签交换（GMPLS）控制的网络中。
New LMP behaviors and protocol extensions have been introduced in a number of IETF documents, as set out later in this section. It is likely that future extensions will be made to support additional functions.
许多IETF文件中引入了新的LMP行为和协议扩展，如本节后面所述。未来可能会进行扩展以支持其他功能。
In a network, if one LMP-capable node supports a new behavior or protocol extension but its adjacent node does not, it is beneficial to have a protocol mechanism to discover the capabilities of peer nodes so that the right protocol extensions can be selected and the correct features can be enabled. There are no such procedures defined in the base LMP specification [RFC4204]. [RFC4209] defined a specific mechanism to identify support for the functions specified in that document. This document defines an LMP extension to support the identification of supported LMP functions in a generic fashion, as well as how a node supporting these extensions would communicate with legacy nodes.
在网络中，如果一个支持LMP的节点支持新的行为或协议扩展，但其相邻节点不支持，则使用协议机制来发现对等节点的能力是有益的，这样可以选择正确的协议扩展并启用正确的功能。基本LMP规范[RFC4204]中未定义此类程序。[RFC4209]定义了一种特定的机制，以确定对该文档中指定功能的支持。本文档定义了LMP扩展，以支持以通用方式识别受支持的LMP功能，以及支持这些扩展的节点如何与遗留节点通信。
In [RFC4204], the basic behaviors have been defined around the use of the standard LMP messages, which include Config, Hello, Verify, Test, LinkSummary, and ChannelStatus. Per [RFC4204], these behaviors MUST be supported when LMP is implemented, and the message types from 1 to 20 have been assigned by IANA for these messages. Support for all functions required by [RFC4204] is assumed by this document.
在[RFC4204]中，围绕标准LMP消息的使用定义了基本行为，包括配置、Hello、验证、测试、链接摘要和ChannelStatus。根据[RFC4204]，在实施LMP时必须支持这些行为，IANA已为这些消息分配了1到20的消息类型。本文件假定支持[RFC4204]要求的所有功能。
In [RFC4207], the SONET/SDH technology-specific behavior and information for LMP is defined. The Trace behavior is added to LMP, and the message types from 21 to 31 have been assigned by IANA for the messages that provide the Trace function.
在[RFC4207]中，定义了LMP的SONET/SDH技术特定行为和信息。跟踪行为被添加到LMP中，IANA为提供跟踪功能的消息分配了从21到31的消息类型。
In [RFC4209], extensions to LMP are defined to allow it to be used between a peer node and an adjacent Optical Line System (OLS). The LMP object class type and subobject class name have been extended to support Dense Wavelength Division Multiplexing (DWDM) behavior.
在[RFC4209]中，LMP的扩展被定义为允许在对等节点和相邻光线路系统（OLS）之间使用。LMP对象类类型和子对象类名称已扩展为支持密集波分复用（DWDM）行为。
In [RFC5818], the data channel consistency check behavior is defined, and the message types from 32 to 34 have been assigned by IANA for messages that provide this behavior.
在[RFC5818]中，定义了数据通道一致性检查行为，IANA为提供此行为的消息分配了32到34的消息类型。
It is likely that future extensions to LMP for other functions or technologies will require the definition of further LMP messages.
很可能，未来对LMP的其他功能或技术的扩展将需要进一步定义LMP消息。
This document describes an LMP extension, referred to as behavior negotiation, that enables the nodes at the ends of a link to identify the LMP messages and functions supported by the adjacent node. The extension makes use of a new CONFIG object. The use of this new object does not preclude the use of existing or yet to be defined CONFIG objects.
本文档描述了LMP扩展，称为行为协商，它使链路末端的节点能够识别相邻节点支持的LMP消息和功能。扩展使用了一个新的配置对象。使用此新对象并不排除使用现有或尚未定义的配置对象。
This document also modifies the format of messages that carry the CONFIG object to allow for multiple objects. Multiple CONFIG objects allow behavior negotiation concurrent with existing usage of the CONFIG object, i.e., HelloConfig C-Type defined in [RFC4204] and LMP-WDM_CONFIG C-Type defined in [RFC4209]. This document modifies the ConfigAck message to include CONFIG objects so that acceptable parameters are explicitly identified. It also describes how a node that supports the extensions defined in this document interacts with a legacy LMP-capable node.
本文档还修改了携带CONFIG对象的消息的格式，以允许多个对象。多个配置对象允许行为协商与配置对象的现有使用并发，即[RFC4204]中定义的HelloConfig C-Type和[RFC4209]中定义的LMP-WDM_配置C-Type。本文档修改ConfigAck消息以包含配置对象，以便明确标识可接受的参数。它还描述了支持本文档中定义的扩展的节点如何与支持遗留LMP的节点交互。
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]中所述进行解释。
LMP Config, ConfigNack, and ConfigAck messages are modified by this document to allow for the inclusion of multiple CONFIG objects. The Config and ConfigNack messages were only defined to carry one CONFIG object in [RFC4204]. The ConfigAck message, which was defined without carrying any CONFIG objects in [RFC4204], is modified to enable explicit identification of negotiated configuration parameters. The inclusion of CONFIG objects in ConfigAck messages is triggered by the use of the BehaviorConfig object (defined below) in a received Config message.
此文档修改了LMP Config、ConfigNack和ConfigAck消息，以允许包含多个配置对象。Config和ConfigNack消息在[RFC4204]中仅定义为携带一个配置对象。ConfigAck消息（在[RFC4204]中未携带任何配置对象而定义）经过修改，以允许显式标识协商的配置参数。ConfigAck消息中包含的配置对象是通过在收到的配置消息中使用BehaviorConfig对象（定义如下）触发的。
The message formats in the sections that follow use Backus-Naur Form (BNF) encoding as defined in [RFC5511].
以下章节中的消息格式使用[RFC5511]中定义的Backus Naur Form（BNF）编码。
The format of the Config message as updated by this document is as
follows:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]
The format of the Config message as updated by this document is as
follows:
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG> [ <CONFIG> ... ]
The format of the ConfigAck message as updated by this document is as follows:
本文档更新的ConfigAck消息格式如下：
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID>[ <CONFIG> ... ]
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID>[ <CONFIG> ... ]
The format of the ConfigNack message as updated by this document is as follows:
本文档更新的ConfigNack消息格式如下：
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID>
<CONFIG> [ <CONFIG> ... ]
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID>
<CONFIG> [ <CONFIG> ... ]
Nodes that support the extensions defined in this document MAY include multiple CONFIG objects when sending a Config, ConfigAck, and ConfigNack message. A maximum of a single object of any particular C-type SHALL be included. A node that receives a message with multiple CONFIG objects of the same C-type SHALL process the first object of a particular C-type and ignore any subsequent CONFIG objects of the same C-type. Unless specified as part of the CONFIG object definition, ordering of CONFIG objects with different C-type values is not significant.
在发送CONFIG、ConfigAck和ConfigNack消息时，支持本文档中定义的扩展的节点可能包括多个CONFIG对象。应包括任何特定C型的最大单个物体。接收具有相同C类型的多个配置对象的消息的节点应处理特定C类型的第一个对象，并忽略相同C类型的任何后续配置对象。除非作为配置对象定义的一部分指定，否则具有不同C类型值的配置对象的顺序并不重要。
Nodes that support the extensions defined in this document MUST include a BehaviorConfig type object when sending a Config message to a neighbor whose support for the extensions is either known or unknown. When the neighbor is known to not support the extensions, the object MUST NOT be sent. Inclusion of other CONFIG objects in a Config message is at the discretion of the message sender and is based on the rules defined as part of CONFIG object definition. Nodes MAY include HelloConfig, LMP-WDM_CONFIG, BehaviorConfig object types in a single message.
当向对扩展的支持已知或未知的邻居发送配置消息时，支持此文档中定义的扩展的节点必须包含BehaviorConfig类型对象。当知道邻居不支持扩展时，不得发送该对象。在配置消息中包含其他配置对象由消息发送者自行决定，并基于作为配置对象定义一部分的规则。节点可以在单个消息中包括HelloConfig、LMP-WDM_CONFIG、BehaviorConfig对象类型。
Inclusion of multiple CONFIG objects in a ConfigNack message is based on the processing of a received Config message. Per [RFC4204], "Parameters where agreement was reached MUST NOT be included in the ConfigNack Message." As such, a ConfigNack message MUST NOT include CONFIG objects that are acceptable and MUST include any CONFIG objects which are not acceptable. When a CONFIG object is included in a ConfigNack message, per [RFC4204], the object is to include "acceptable alternate values for negotiable parameters".
在ConfigNack消息中包含多个配置对象是基于对接收到的配置消息的处理。根据[RFC4204]，“达成协议的参数不得包含在ConfigNack消息中。”因此，ConfigNack消息不得包含可接受的配置对象，并且必须包含任何不可接受的配置对象。当ConfigNack消息中包含配置对象时，根据[RFC4204]，该对象将包含“可协商参数的可接受替代值”。
When sending a ConfigAck message, nodes supporting the extensions defined in this document MUST include all CONFIG objects received in the corresponding Config message when that message includes a CONFIG object of type BehaviorConfig.
发送ConfigAck消息时，支持本文档中定义的扩展的节点必须包括相应配置消息中接收到的所有配置对象（如果该消息包含BehaviorConfig类型的配置对象）。
The Config message is used in the control channel negotiation phase of LMP [RFC4204]. The LMP behavior negotiation procedure is defined in this document as an addition to this phase.
配置消息用于LMP[RFC4204]的控制信道协商阶段。本文件将LMP行为协商程序定义为本阶段的补充。
The Config message is defined in Section 12.3.1 of [RFC4204] and carries the CONFIG object (class name 6) as defined in Section 13.6 of [RFC4204].
配置消息在[RFC4204]第12.3.1节中定义，并携带[RFC4204]第13.6节中定义的配置对象（类名6）。
Two class types have been defined:
定义了两种类类型：
- C-Type = 1, HelloConfig, defined in [RFC4204]
- C-Type=1，HelloConfig，在[RFC4204]中定义
- C-Type = 2, LMP-WDM_CONFIG, defined in [RFC4209]
- C-Type=2，LMP-WDM_配置，在[RFC4209]中定义
This document defines a third C-Type to report and negotiate LMP mechanisms and behaviors. Its usage indicates support for the extensions defined in this document.
本文档定义了第三个C-Type来报告和协商LMP机制和行为。它的用法表示支持本文档中定义的扩展。
Class = 6
Class = 6
- C-Type = 3, BehaviorConfig
- 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|D|C| Must Be Zero (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|D|C| Must Be Zero (MBZ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags:
旗帜：
S: 1 bit
S:1位
This bit indicates support for the Trace behavior of SONET/SDH technology-specific defined in [RFC4207].
该位表示支持[RFC4207]中定义的SONET/SDH技术的跟踪行为。
D: 1 bit
D:1位
This bit indicates support for the DWDM behavior defined in [RFC4209].
此位表示支持[RFC4209]中定义的DWDM行为。
C: 1 bit
C:1位
This bit indicates support for the data channel consistency check behavior defined in [RFC5818].
此位表示支持[RFC5818]中定义的数据通道一致性检查行为。
Must Be Zero (MBZ): Variable length
必须为零（MBZ）：可变长度
The remaining bits in the flags field MUST be set to zero (0). This field MUST be sized to ensure 32-bit alignment of the object.
标志字段中的剩余位必须设置为零（0）。此字段的大小必须确保对象的32位对齐。
Other bits may be defined in future documents, in which case the number of bits in the MBZ field is expected to change.
其他位可以在将来的文档中定义，在这种情况下，MBZ字段中的位数预计会改变。
The inclusion of a BehaviorConfig type object in a message is discussed above in Section 2.2.
上文第2.2节讨论了在消息中包含BehaviorConfig类型对象的问题。
When sending a BehaviorConfig type object, the N-bit (negotiable) in the LMP object header MUST be set (N=1) in the LMP object header.
发送BehaviorConfig类型对象时，必须在LMP对象标头中设置LMP对象标头中的N位（可协商）（N=1）。
When sending a BehaviorConfig type object in Config and ConfigNack messages, the flags field SHOULD be set based on the supported capabilities of the sending node. When sending a ConfigAck message, the flags field MUST be set to the value received in the corresponding Config message.
在Config和ConfigNack消息中发送BehaviorConfig类型对象时，应根据发送节点支持的功能设置flags字段。发送ConfigAck消息时，必须将flags字段设置为相应配置消息中接收到的值。
When receiving a BehaviorConfig type object, the node compares the flags field against its capacities. Any bit set in the MBZ portion of the flags field MUST be interpreted as unacceptable. Processing related to unacceptable values in CONFIG objects is defined in [RFC4204] and is not modified by this document.
接收BehaviorConfig类型对象时，节点会将flags字段与其容量进行比较。必须将标志字段的MBZ部分中设置的任何位解释为不可接受。[RFC4204]中定义了与配置对象中不可接受值相关的处理，本文档未对其进行修改。
The required use of the BehaviorConfig type CONFIG object enables nodes that support the extensions defined in this document to explicitly identify when a neighboring node does not. When a non-supporting node receives a Config message with the BehaviorConfig type CONFIG object or multiple CONFIG objects, its behavior is to be one of the following behaviors:
如果需要使用BehaviorConfig类型CONFIG对象，则支持本文档中定义的扩展的节点可以显式标识相邻节点何时不支持。当非支持节点接收到带有BehaviorConfig类型配置对象或多个配置对象的配置消息时，其行为将是以下行为之一：
a) Reject the Config message because of the unknown BehaviorConfig object type and send a ConfigNack message which includes the unsupported C-type.
a) 由于未知的BehaviorConfig对象类型而拒绝配置消息，并发送包含不支持的C类型的ConfigNack消息。
b) Reject the message because of multiple CONFIG objects and send a ConfigNack message which includes all but one of the CONFIG objects.
b) 由于存在多个配置对象而拒绝该消息，并发送一条包含除一个配置对象以外的所有配置对象的ConfigNack消息。
c) Silently ignore the one or more of the CONFIG object, and respond with a ConfigAck message that does not include any CONFIG objects.
c) 以静默方式忽略一个或多个配置对象，并使用不包含任何配置对象的ConfigAck消息进行响应。
d) Treat the message as malformed, and discard it without any response.
d) 将消息视为格式错误，并在没有任何响应的情况下丢弃它。
Behaviors (a) and (b) result in ConfigNack messages with a BehaviorConfig type object whose contents are identical to what was sent in the Config message. Behavior (c) results in a ConfigAck message without a BehaviorConfig type CONFIG object. In each of these cases, the node SHOULD explicitly identify that the LMP neighbor does not support the extensions defined in this document.
行为（a）和（b）会导致ConfigNack消息具有BehaviorConfig类型对象，其内容与Config消息中发送的内容相同。行为（c）导致ConfigAck消息中没有BehaviorConfig类型的CONFIG对象。在每种情况下，节点都应明确标识LMP邻居不支持本文档中定义的扩展。
Behavior (d) results in no response at all. When the node reaches the "retry limit", defined in [RFC4204], the node SHOULD infer that the LMP neighbor does not support the extensions defined in this document.
行为（d）导致根本没有反应。当节点达到[RFC4204]中定义的“重试限制”时，节点应推断LMP邻居不支持本文档中定义的扩展。
Once a node identifies a neighbor as not supporting the extensions defined in this document, the node SHOULD follow previously defined Config message usage.
一旦节点将邻居标识为不支持本文档中定义的扩展，则该节点应遵循先前定义的配置消息用法。
[RFC4204] describes how LMP messages between peers can be secured, and these measures are equally applicable to messages carrying the new CONFIG object defined in this document.
[RFC4204]描述了如何保护对等方之间的LMP消息，这些措施同样适用于承载本文档中定义的新配置对象的消息。
Alone, the procedures described in this document do not constitute a security risk, since they do not cause any change in network state. It would be possible, if the messages were intercepted or spoofed to cause bogus alerts in the management plane, or to cause LMP peers to consider that they could or could not operate protocol extensions, and so the use of the LMP security measures are RECOMMENDED.
仅此一项，本文件中描述的程序不构成安全风险，因为它们不会导致网络状态发生任何变化。如果消息被截获或欺骗，导致管理平面中的虚假警报，或导致LMP对等者认为它们能够或不能操作协议扩展，则建议使用LMP安全措施。
Note, however, that [RFC4204] references for security have been updated with [RFC4301], and the current reference for IKEv2 is [RFC5996].
但是，请注意，安全性的[RFC4204]参考已更新为[RFC4301]，IKEv2的当前参考为[RFC5996]。
IANA maintains the "Link Management Protocol (LMP) Parameters" registry, which has a subregistry called "LMP Object Class name space and Class type (C-Type)".
IANA维护“链路管理协议（LMP）参数”注册表，该注册表有一个子区，名为“LMP对象类名称空间和类类型（C-type）”。
IANA has made an assignment from this registry as follows:
IANA已从该注册处进行了如下转让：
6 CONFIG [RFC4204]
6配置[RFC4204]
CONFIG Object Class type name space:
配置对象类类型名称空间：
C-Type Description Reference
------------ --------------------- ---------
3 BehaviorConfig RFC 6898
C-Type Description Reference
------------ --------------------- ---------
3 BehaviorConfig RFC 6898
IANA has created a new subregistry of the "Link Management Protocol (LMP) Parameters" registry to track the Behavior Configuration bits defined in Section 2 of this document. This registry is called "LMP Behavior Configuration Flags".
IANA已经创建了一个新的“链路管理协议（LMP）参数”注册表子区，以跟踪本文件第2节中定义的行为配置位。此注册表称为“LMP行为配置标志”。
Allocations from this registry are by Standards Action.
此注册表中的分配是按标准操作进行的。
Bits in this registry are numbered from zero as the most significant bit (transmitted first). The number of bits that can be present is limited by the length field of the CONFIG object, which gives rise to (255 x 32)-8 = 8152. IANA is strongly recommended to allocate new bits with the lowest available unused number.
此注册表中的位从零开始编号为最高有效位（首先传输）。可存在的位数受配置对象的长度字段限制，这会导致（255 x 32）-8=8152。强烈建议IANA分配具有最低可用未使用数的新位。
The registry is initially populated as follows:
注册表的初始填充方式如下所示：
Bit | Bit | Meaning | Reference
Number | Name | |
-------+------+----------------------------------------+----------
0 | S | SONET/SDH Test support | RFC 6898
1 | D | DWDM support | RFC 6898
2 | C | Data Channel consistency check support | RFC 6898
Bit | Bit | Meaning | Reference
Number | Name | |
-------+------+----------------------------------------+----------
0 | S | SONET/SDH Test support | RFC 6898
1 | D | DWDM support | RFC 6898
2 | C | Data Channel consistency check support | RFC 6898
[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月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]Lang，J.，Ed.，“链路管理协议（LMP）”，RFC4204，2005年10月。
[RFC4207] Lang, J. and D. Papadimitriou, "Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages", RFC 4207, October 2005.
[RFC4207]Lang，J.和D.Papadimitriou，“链路管理协议（LMP）测试消息的同步光网络（SONET）/同步数字体系（SDH）编码”，RFC 4207，2005年10月。
[RFC4209] Fredette, A., Ed., and J. Lang, Ed., "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", RFC 4209, October 2005.
[RFC4209]Fredette，A.，Ed.，和J.Lang，Ed.，“密集波分复用（DWDM）光纤线路系统的链路管理协议（LMP）”，RFC 4209，2005年10月。
[RFC5818] Li, D., Xu, H., Bardalai, S., Meuric, J., and D. Caviglia, "Data Channel Status Confirmation Extensions for the Link Management Protocol", RFC 5818, April 2010.
[RFC5818]Li，D.，Xu，H.，Bardalai，S.，Meuria，J.，和D.Caviglia，“链路管理协议的数据信道状态确认扩展”，RFC 5818，2010年4月。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511]Farrel，A.，“路由Backus-Naur形式（RBNF）：用于在各种路由协议规范中形成编码规则的语法”，RFC 5511，2009年4月。
Thanks to Adrian Farrel and Richard Graveman for their useful comments.
感谢Adrian Farrel和Richard Graveman的有用评论。
Diego Caviglia Ericsson Via E. Melen, 77 Genova - Erzelli Italy Phone: +39 010 600 3736 EMail: diego.caviglia@ericsson.com
Diego Caviglia Ericsson通过E.Melen，77 Genova-Erzelli意大利电话：+39 010 600 3736电子邮件：Diego。caviglia@ericsson.com
Authors' Addresses
作者地址
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Industrial Base, Shenzhen 518129 China Phone: +86 755-289-70230 EMail: huawei.danli@huawei.com
Dan Li华为技术F3-5-B研发中心，华为工业基地，深圳518129中国电话：+86 755-289-70230电子邮件：华为。danli@huawei.com
Daniele Ceccarelli Ericsson Via E. Melen, 77 Genova - Erzelli Italy EMail: daniele.ceccarelli@ericsson.com
Daniele Ceccarelli Ericsson通过E.Melen，77 Genova-Erzelli意大利电子邮件：Daniele。ceccarelli@ericsson.com
Lou Berger LabN Consulting, L.L.C. EMail: lberger@labn.net
Lou Berger LabN Consulting，L.L.C.电子邮件：lberger@labn.net