[要約] RFC 6898は、リンク管理プロトコルの動作の交渉と設定変更に関するガイドラインです。その目的は、異なるネットワーク環境でのリンク管理プロトコルの一貫性と互換性を確保することです。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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.
このセクションで後述するように、新しいLMPの動作とプロトコル拡張がいくつかのIETFドキュメントに導入されています。追加機能をサポートするために将来の拡張が行われる可能性があります。
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.
ネットワークで、1つの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]では、Config、Hello、Verify、Test、LinkSummary、ChannelStatusなどの標準LMPメッセージの使用に関する基本的な動作が定義されています。 [RFC4204]によれば、LMPが実装されているときにこれらの動作がサポートされなければならず（MUST）、1から20までのメッセージタイプがIANAによってこれらのメッセージに割り当てられています。 [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に追加され、21から31までのメッセージタイプが、トレース機能を提供するメッセージにIANAによって割り当てられました。
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]では、データチャネルの整合性チェックの動作が定義されており、32から34までのメッセージタイプは、この動作を提供するメッセージに対してIANAによって割り当てられています。
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メッセージと機能を識別できます。拡張機能は、新しいCONFIGオブジェクトを使用します。この新しいオブジェクトの使用は、既存の、またはまだ定義されていないCONFIGオブジェクトの使用を妨げません。
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オブジェクトを含むメッセージのフォーマットも変更して、複数のオブジェクトを許可しています。複数のCONFIGオブジェクトにより、CONFIGオブジェクトの既存の使用と同時の動作ネゴシエーションが可能になります。つまり、[RFC4204]で定義されているHelloConfig C-Typeと[RFC4209]で定義されているLMP-WDM_CONFIG C-Typeです。このドキュメントでは、ConfigAckメッセージを変更してCONFIGオブジェクトを含めることで、受け入れ可能なパラメーターが明示的に識別されるようにします。また、このドキュメントで定義されている拡張機能をサポートするノードがレガシー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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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オブジェクトを含めることができるように、このドキュメントによって変更されています。 ConfigおよびConfigNackメッセージは、[RFC4204]で1つのCONFIGオブジェクトを運ぶようにのみ定義されていました。 [RFC4204]でCONFIGオブジェクトを伝送せずに定義されたConfigAckメッセージは、ネゴシエートされた構成パラメーターを明示的に識別できるように変更されています。 ConfigAckメッセージにCONFIGオブジェクトを含めることは、受信したConfigメッセージでBehaviorConfigオブジェクト（以下で定義）を使用することによってトリガーされます。
The message formats in the sections that follow use Backus-Naur Form (BNF) encoding as defined in [RFC5511].
次のセクションのメッセージ形式では、[RFC5511]で定義されているバッカスナウアフォーム（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 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> ... ]
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> ... ]
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タイプの最大1つのオブジェクトを含める必要があります。同じCタイプの複数のCONFIGオブジェクトを持つメッセージを受信するノードは、特定のCタイプの最初のオブジェクトを処理し、同じCタイプの後続のCONFIGオブジェクトを無視する必要があります（SHALL）。 CONFIGオブジェクト定義の一部として指定されていない限り、異なるCタイプ値を持つCONFIGオブジェクトの順序は重要ではありません。
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.
このドキュメントで定義されている拡張機能をサポートするノードは、拡張機能のサポートが既知または不明のネイバーにConfigメッセージを送信するときに、BehaviorConfigタイプのオブジェクトを含める必要があります。ネイバーが拡張機能をサポートしていないことがわかっている場合、オブジェクトを送信してはなりません（MUST NOT）。構成メッセージに他のCONFIGオブジェクトを含めるかどうかは、メッセージ送信者の裁量であり、CONFIGオブジェクト定義の一部として定義されたルールに基づいています。ノードは、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メッセージに複数のCONFIGオブジェクトを含めることは、受信したConfigメッセージの処理に基づいています。 [RFC4204]に従い、「合意に達したパラメータはConfigNackメッセージに含めてはなりません（MUST NOT）」。そのため、ConfigNackメッセージには、受け入れ可能なCONFIGオブジェクトを含めてはならず（MUST NOT）、受け入れられないCONFIGオブジェクトを含めなければなりません（MUST）。 [RFC4204]によると、CONFIGオブジェクトがConfigNackメッセージに含まれている場合、オブジェクトには「交渉可能なパラメータの許容可能な代替値」が含まれます。
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メッセージを送信する場合、このドキュメントで定義されている拡張機能をサポートするノードには、対応するConfigメッセージで受信したすべてのCONFIGオブジェクトを含める必要があります（そのメッセージにBehaviorConfigタイプのCONFIGオブジェクトが含まれている場合）。
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.
Configメッセージは、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].
Configメッセージは[RFC4204]のセクション12.3.1で定義されており、[RFC4204]のセクション13.6で定義されているCONFIGオブジェクト（クラス名6）を伝達します。
Two class types have been defined:
2つのクラスタイプが定義されています。
- C-Type = 1, HelloConfig, defined in [RFC4204]
- C-Type = 1、HelloConfig、[RFC4204]で定義
- C-Type = 2, LMP-WDM_CONFIG, defined in [RFC4209]
- Cタイプ= 2、LMP-WDM_CONFIG、[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.
このドキュメントでは、LMPメカニズムと動作を報告およびネゴシエートするための3番目のCタイプを定義します。その使用法は、このドキュメントで定義されている拡張機能のサポートを示しています。
Class = 6
- C-Type = 3, BehaviorConfig
- Cタイプ= 3、BehaviorConfig
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.
メッセージにBehaviorConfigタイプのオブジェクトを含めることについては、セクション2.2で説明しています。
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オブジェクトヘッダーのNビット（交渉可能）をLMPオブジェクトヘッダーに設定（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タイプのオブジェクトを送信する場合、フラグフィールドは送信ノードのサポートされている機能に基づいて設定する必要があります（SHOULD）。 ConfigAckメッセージを送信する場合、フラグフィールドは、対応するConfigメッセージで受信した値に設定する必要があります。
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タイプのオブジェクトを受信すると、ノードはフラグフィールドをその容量と比較します。フラグフィールドのMBZ部分に設定されたビットは、受け入れられないものとして解釈する必要があります。 CONFIGオブジェクトの許容できない値に関連する処理は[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タイプのCONFIGオブジェクトまたは複数のCONFIGオブジェクトを含む構成メッセージを受信した場合、その動作は次のいずれかの動作になります。
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オブジェクトタイプが原因でConfigメッセージを拒否し、サポートされていない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) 複数のCONFIGオブジェクトが原因でメッセージを拒否し、CONFIGオブジェクトの1つを除くすべてを含む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) 1つ以上のCONFIGオブジェクトをサイレントに無視し、CONFIGオブジェクトを含まない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メッセージには、Configメッセージで送信されたものと同じ内容のBehaviorConfigタイプのオブジェクトが含まれます。 Behavior（c）は、BehaviorConfigタイプのCONFIGオブジェクトのないConfigAckメッセージになります。これらのケースのそれぞれで、ノードは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.
ノードがこのドキュメントで定義されている拡張機能をサポートしていないとネイバーを特定すると、ノードは以前に定義されたConfigメッセージの使用法に従う必要があります（SHOULD）。
[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メッセージを保護する方法を説明しており、これらの手段は、このドキュメントで定義されている新しいCONFIGオブジェクトを運ぶメッセージにも同様に適用できます。
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タイプ）」と呼ばれるサブレジストリがあります。
IANA has made an assignment from this registry as follows:
IANAは、このレジストリから次のように割り当てを行いました。
6 CONFIG [RFC4204]
6構成[RFC4204]
CONFIG Object Class type name space:
CONFIGオブジェクトクラスタイプの名前空間：
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.
このレジストリのビットには、ゼロから最上位ビット（最初に送信される）として番号が付けられます。存在できるビット数は、CONFIGオブジェクトの長さフィールドによって制限され、（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
[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 4301、2005年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 5996、2010年9月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J。、編、「リンク管理プロトコル（LMP）」、RFC 4204、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、「Synchronous Optical Network（SONET）/ Synchronous Digital Hierarchy（SDH）Encoding for Link Management Protocol（LMP）Test Messages」、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。、編、およびJ. Lang、編、「高密度波長分割多重（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.、Meuric、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。、「Routing Backus-Naur Form（RBNF）：A Syntax Using Forming Encoding Rules in Various Routing Protocol Specifications」、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
ディエゴカビリアエリクソンVia E. Melen、77 Genova-Erzelli Italy電話：+39010 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 Huawei Technologies F3-5-B R＆D Center、Huawei Industrial Base、Shenzhen 518129 China電話：+86 755-289-70230メール：huawei.danli@huawei.com
Daniele Ceccarelli Ericsson Via E. Melen, 77 Genova - Erzelli Italy EMail: daniele.ceccarelli@ericsson.com
Daniele Ceccarelli Ericsson Via E. Melen、77 Genoa-Erzelli Italyメール：daniele.ceccarelli@ericsson.com
Lou Berger LabN Consulting, L.L.C. EMail: lberger@labn.net
Lou Berger LabNコンサルティング、L.L.C。メール：lberger@labn.net