[要約] RFC 4204は、光ネットワークの隣接するノード間で、データリンクの状態監視や障害検出を行うためのプロトコル「LMP（Link Management Protocol）」の仕様を定義しています。コントロールプレーンとデータプレーンが分離されたネットワークにおいて、光ファイバーの接続確認や属性の交渉、障害箇所の特定を標準的な方法で実現します。
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).
Copyright（c）The Internet Society（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リンクの管理は帯域内のメッセージに限定されませんが、代わりに帯域外の手法を使用して実行できます。このドキュメントは、ノードのペア間で実行され、TEリンクの管理に使用されるリンク管理プロトコル（LMP）を指定します。具体的には、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 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、タイムディビジョンマルチプレックス（TDM）スロットまたはレイヤー1での波長除算（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インターフェイスのペアが必要です。このようなインターフェイスのペアをコントロールチャネルと呼びます。「相互に到達可能」は、これらの2つのインターフェイスが（直接）IPリンクによって接続されていることを意味しないことに注意してください。2つの間にIPネットワークがある場合があります。さらに、コントロールメッセージが送信/受信されるインターフェイスは、データが流れるのと同じインターフェイスではない場合があります。このドキュメントは、ノードのペア間で実行され、TEリンクを管理し、制御チャネルの範囲を検証するために使用されるリンク管理プロトコル（LMP）を指定します。このドキュメントの目的のために、そのようなノードは「LMP Neighbors」または単に「隣接ノード」と見なされます。
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では、2つの隣接するノード間の制御チャネルは、それらのノード間のデータリンクと同じ物理媒体を使用するためにもはや必要ありません。たとえば、制御チャネルは、個別の仮想回路、波長、ファイバー、イーサネットリンク、別の管理ネットワーク上にルーティングされたIPトンネル、またはマルチホップIPネットワークを使用できます。2つのノード間の制御チャネルが関連するデータリンクから論理的または物理的に多様であることを許可した結果、コントロールチャネルの健康が必ずしもデータリンクの健康と相関するわけではなく、逆も同様です。したがって、制御チャネルの運命とデータリンクの間にきれいな分離を行う必要があります。リンクのプロビジョニングと障害管理の両方の観点から、データリンクを管理するために新しいメカニズムを開発する必要があります。
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 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が達成したタスクの中には、リンクへのリンクのグループ化とそれらのリンクのプロパティがリンクの両方のエンドポイントで同じであることを確認することが確認されています。これは「リンクプロパティ相関」と呼ばれます。また、LMPはこれらのリンクプロパティをIGPモジュールに通知し、ネットワーク内の他のノードに発表できます。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.
通信を有効にするには、制御ネットワーク（シングルまたはマルチホップ）の存在が必要ですが、決して十分ではないことに注意してください。たとえば、2つのインターフェイスがIPネットワークによって分離されている場合、IPネットワークの障害により、あるインターフェイスから別のインターフェイスへのIPパスがないため、2つのインターフェイス間の通信が中断される場合があります。一方、制御ネットワーク内のすべての障害が特定の制御チャネルに影響を与えるわけではないため、制御チャネルを確立および管理する必要があります。
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).
このドキュメントの目的のために、そのリンクのエンドポイントの多重化機能に応じて、「ポート」または「コンポーネントリンク」のいずれかとして終了する各ノードでデータリンクを考慮することができます。コンポーネントリンクはマルチプレックス対応ですが、ポートはマルチプレックス対応ではありません。この区別は、そのようなリンクの管理（たとえば、リソース割り当て、ラベルの割り当て、およびその物理的検証を含む）が多重化機能に基づいて異なるため、重要です。たとえば、フレームリレースイッチは、DLCISに基づいてインターフェイスを仮想回路に反映することができます。同様に、OC-192インターフェイスを備えたSONET CrossConnectは、OC-192ストリームを4つのOC-48ストリームに反映できる可能性があります。複数のインターフェイスがリンクバンドリング[RFC4201]を使用して単一のTEリンクにグループ化されている場合、リンクリソースを3つのレベルを使用して識別する必要があります：リンク_ID、コンポーネントインターフェイスID、および仮想回路の識別ラベル、タイムスロットなど。リソース割り当ては、最低レベル（ラベル）ですが、物理的な接続性はコンポーネントリンクレベルで発生します。別の例として、光スイッチ（PXCなど）がOC-192ライトパスを透過的に切り替える場合を検討してください。複数のインターフェイスが再び単一のTEリンクにグループ化された場合、リンクバンドリング[RFC4201]は必要ありません。2つのレベルの識別のみが必要です：Link_IdとPort_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対応デバイスは、コンポーネントリンクのサブチャネルを（論理）データリンクとしてローカルに構成できるようにすべきです (SHOULD)。たとえば、4つのOC-48インターフェイスを持つルーターが4：1 MUXを介してOC-192インターフェイスを使用したクロスコネクトに接続されている場合、クロスコネクトは各サブチャネルを構成できるはずです（例：STS-48CC4：1 MuxがデータリンクとしてSONET MUX）の場合。
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は、1つ以上のデータリンクのTEリンクへの集約をサポートするように設計されています（TEリンクへのポート、またはTEリンクへのコンポーネントリンクのいずれか）。TEリンクを形成する目的は、特定の物理リソース（およびそのプロパティ）に関する情報を、PATH計算を目的として制約された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].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、[RFC2119] で説明されているように解釈されるものとします。
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]で定義されているように、バンドルされたリンクは、GMPLSシグナリングの目的のために、<リンク識別子、ラベル>の組み合わせで、LSPが使用する適切なリソースを明確に識別するのに十分ではないようなリンクです。バンドルされたリンクは、2つ以上のコンポーネントリンクで構成されています。
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]で定義されているように、コンポーネントリンクは、（a）パーティションが最小限であり、各サブセットAラベル内でLSPで使用される適切なリソースを明確に識別するのに十分なようなTEリンクのリソースのサブセットです。。
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では、2つの隣接するノード間の制御チャネルは、それらのノード間のデータリンクと同じ物理媒体を使用するためにもはや必要ではないことに注意してください。
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:
Node_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を宣伝するノードの場合、Node_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リンクは、PATHの目的で制約付きSPFが使用する情報にLSRを相互接続する特定の物理リソース（およびそのプロパティ）に関する情報をグループ化/マップする方法を表す論理的な構成要素です。計算、および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-Transparentと呼ばれます。たとえば、フレームリレースイッチはネットワーク層透明です。すべての光学スイッチは電気的に透明です。
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の2つのコアプロシージャは、制御チャネル管理とリンクプロパティ相関です。制御チャネル管理は、隣接するノード間の制御チャネルを確立および維持するために使用されます。これは、構成メッセージ交換とノード間の高速キープアライブメカニズムを使用して行われます。コントロールチャネルの障害を検出するために低レベルのメカニズムが利用できない場合、後者が必要です。リンクプロパティ相関は、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 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では、一対のノードに、それらの間に少なくとも1つのアクティブな双方向制御チャネルがあることが必要です。制御チャネルの各方向は、コントロールチャネルID（CC_Id）によって識別され、LMP構成メッセージ交換を使用して2つの方向が結合されます。インバンドメッセージングのトランスポートメカニズムによって制限される可能性のあるテストメッセージを除き、すべての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.
少なくとも1つの双方向制御チャネルが2つのノード間に確立されると、それらの間に「LMP隣接」が形成されます。各隣接に対して、複数の制御チャネルが同時にアクティブになる場合があります。ただし、制御チャネルのパラメーターは、各制御チャネルについて個別にネゴシエートされなければなりません (MUST)。LMP高速Keep-Aliveが制御チャネルで使用される場合、LMP Helloメッセージはその制御チャネルを介して交換されなければなりません (MUST)。その他のLMPメッセージは、隣接するノードのペア間のアクティブな制御チャネルのいずれかで送信されてもよいです (MAY)。1つ以上のアクティブな制御チャネルは、シグナリング、ルーティング、およびリンクプロパティ相関の目的のために、論理制御チャネルにグループ化できます。
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リンクのプロパティを同期するように設計されています。Linkプロパティ相関関数の一部として、LinkSummaryメッセージ交換が定義されています。LinkSummaryメッセージには、TEリンクを構成するすべてのデータリンクのリスト、およびさまざまなリンクプロパティが含まれています。LinkSummaryAckまたはLinkSummaryNackメッセージは、リンクプロパティに関する合意または不一致を示すLinkSummaryメッセージの受信に応じて送信しなければなりません (MUST)。
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.
LMPメッセージは、Message_Idsと再送信を使用して確実に送信されます。Message_IdsはMESSAGE_IDオブジェクトに携帯されています。LMPメッセージに含まれることはできません。コントロールチャネル固有のメッセージの場合、Message_IDは、メッセージが送信されるコントロールチャネルの範囲内にあります。TE-Link固有のメッセージの場合、Message_IDはLMP隣接の範囲内にあります。Message_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.
このドキュメントでは、2つの追加のLMP手順が定義されています。リンク接続検証と障害管理。これらの手順は、制御チャネルがデータリンクから物理的に多様である場合に特に役立ちます。リンク接続の検証は、データプレーンの発見、Interface_Id Exchange（Interface_Idsが、構成に応じて、ポートラベルまたはコンポーネントリンク識別子としてGMPLSシグナリングで使用されます）、および物理的な接続の検証に使用されます。これは、データリンクとTestStatusメッセージを介してテストメッセージをコントロールチャネル上で送信することによって行われます。テストメッセージは、データリンクを介して送信する必要がある唯一の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-Transparentデバイスの場合、信号のXアスペクトを調べて変更する必要があります。LMPリンク接続検証手順は、コントロールチャネルを介したBeginVerifyメッセージ交換を使用して調整されます。透明性のさまざまな側面をサポートするために、検証輸送メカニズムがBeginVerifyおよびBeginVerifyAckメッセージに含まれています。すべてのデータリンクが同時に透明性を失う必要があるという要件はないことに注意してください。しかし、少なくとも、それらを一度に1つずつ終了することが可能である必要があります。また、コントロールチャネルとTEリンクが同じ物理媒体を使用するという要件もありません。ただし、制御チャネルは、TEリンクを制御するのと同じ2つの制御要素によって終端されなければなりません (MUST)。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メッセージは未承諾で送信され、TEリンクの1つ以上のデータチャネルのステータスについてLMPの近隣に通知するために使用されます。ChannelStatusAckメッセージは、ChannelStatusメッセージの受信を確認するために使用されます。ChannelStatusRequestメッセージは、TEリンクの1つ以上のデータチャネルのステータスについてLMPネイバーを照会するために使用されます。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]).
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 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.
LMPの目的のために、制御チャネルの正確な実装は指定されていません。たとえば、別の波長または繊維、イーサネットリンク、別の管理ネットワークを介したIPトンネル、またはデータリンクのオーバーヘッドバイトである可能性があります。各ノードは、ノード全体の一意の32ビット、非ゼロ整数制御チャネル識別子（CC_Id）を割り当てます。この識別子は、非仮定されたインターフェイス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メッセージは、受信したConfigメッセージのIPヘッダーにある送信元IPアドレスに送信しなければなりません (MUST)。
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リンクとは独立して存在し、複数の制御チャネルがノードのペア間で同時にアクティブになる場合があります。個々の制御チャネルはさまざまな方法で実現できます。たとえば、1つはファイバー内で実装され、別の1つはファイバー外で実装される場合があります。そのため、制御チャネルのパラメーターは個々の制御チャネルごとにネゴシエートされなければならず (MUST)、他のメカニズムが利用できない場合にLMP接続を維持するために、LMP Helloパケットは各制御チャネルで交換されなければなりません (MUST)。制御チャネルは各ノードで電気的に終端されるため、下位層（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.
個々の制御チャネルを管理するために使用される4つのLMPメッセージがあります。それらは、config、ConfigAck、condignack、およびhelloメッセージです。これらのメッセージは、参照するチャネルに送信しなければなりません (MUST)。他のすべての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の隣接性を維持するには、隣接するノードのペア間に少なくとも1つのアクティブ制御チャネルを持つ必要があります（複数の制御チャネルが同時に同時にアクティブになることを思い出してください）。制御チャネル障害が発生した場合、代替のアクティブ制御チャネルを使用でき、以下に説明するように追加の制御チャネルをアクティブにすることが可能です。
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 agree on certain values. Non-negotiable objects are used for the announcement of specific values that do not need, or do not allow, negotiation.
コントロールチャネルのアクティベーションは、config、ConfigAck、およびcondignackメッセージを使用したパラメーターネゴシエーション交換から始まります。これらのメッセージの内容は、LMPオブジェクトを使用して構築されています。LMPオブジェクトは、交渉可能または交渉不可能です（オブジェクトヘッダーのnビットで識別されます）。交渉可能なオブジェクトを使用して、LMPピアに特定の値に同意させることができます。交渉不可能なオブジェクトは、交渉を必要としない、または許可しない特定の値の発表に使用されます。
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.
制御チャネルをアクティブにするには、Configメッセージをリモートノードに送信しなければならず (MUST)、それに応じて、ローカルノードでConfigAckメッセージを受信しなければなりません (MUST)。Configメッセージには、ローカル制御チャネルID（CC_Id）、送信者のNode_Id、信頼できるメッセージング用のMessage_Id、およびCONFIGオブジェクトが含まれます。ローカルノードとリモートノードの両方が同時に構成手順を開始する可能性があります。あいまいさを避けるため、Node_Idが大きいほうのノードが競合に勝ちます。Node_Idが小さいほうのノードは、Configメッセージの送信を停止し、受信したConfigメッセージに応答しなければなりません (MUST)。Node_Idが等しい場合、一方（または両方）のノードの設定が誤っています。ノードは、誤った設定が修正されることを期待して、Configメッセージを再送信し続けてもよいです (MAY)。この問題は、オペレーターが一方または両方のノードでNode_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メッセージは、構成メッセージの受信を確認し、すべての設定されたパラメーター（交渉可能で交渉不可）で契約を明確にするために使用されます。
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.
condignackメッセージは、構成メッセージの受信を確認し、どの（もしあれば）交渉不可能な構成オブジェクトが受け入れられないことを示し、交渉可能なパラメーターの代替値を提案するために使用されます。
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.
ノードが交渉可能なパラメーターの許容可能な代替値を持つcondignackメッセージを受信する場合、ノードはこれらのパラメーターのこれらの値を使用して構成メッセージを送信すべきです (SHOULD)。
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.
ノードが容認できない代替値を持つcondignackメッセージを受信した場合、ノードは、誤った構成が修正されることを期待して構成メッセージを再送信し続けることがあります (MAY)。問題は、一方または両方のノードでパラメーターを変更するオペレーターによって解決される可能性があることに注意してください。
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_Ids）によって対応する制御チャネルに関連付けられています。
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 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.
コントロールチャネルが2つの隣接するノード間でアクティブになると、LMP Helloプロトコルを使用して、ノード間の制御チャネル接続を維持し、制御チャネル障害を検出できます。LMP Helloプロトコルは、IGP Hellosが失われず、関連するリンク状態の隣接が不必要に除去されないように、チャネル障害を迅速に反応する軽量のキープアライブメカニズムであることを目的としています。
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およびHellodeadeadIntervalパラメーターは、ローカルおよびリモートノードによって合意しなければなりません (MUST)。これらのパラメーターは、構成メッセージで交換されます。HelloIntervalは、LMP Helloメッセージが送信される頻度を示し、ミリ秒（MS）で測定されます。たとえば、値が150の場合、送信ノードは少なくとも150ミリ秒ごとにHelloメッセージを送信します。HelloDeadIntervalは、コントロールチャネルが死亡すると宣言する前に、デバイスがハローメッセージを受信するのを待つ時間を示し、ミリ秒（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よりも大きくなければならず (MUST)、HelloIntervalの値の少なくとも3倍であるべきです (SHOULD)。LMPの高速Keep-Aliveメカニズムを使用しない場合、HelloIntervalおよびHelloDeadIntervalパラメーターはゼロに設定されなければなりません (MUST)。
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とHellodeadeadIntervalの値は、輻輳を引き起こすことなくチャネル障害を制御するための迅速な応答時間を提供するために慎重に選択する必要があります。そのため、異なる制御チャネルの実装に対して異なる値が構成される可能性があります。コントロールチャネルが直接接続されたリンクに実装されると、HelloWintervalの推奨されるデフォルト値は150ミリ秒で、HelloDeadIntervalの場合は500ミリ秒です。
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を参照）を受信したら、制御チャネルはup状態に移行します。（双方向の制御チャネル接続を示すために他の方法が使用される場合は、Helloを送信せずにup状態に移行することも可能です。たとえば、双方向接続の兆候がトランスポート層から得られる場合があります。）ただし、ノードがConfigAckメッセージの代わりにConfigNackメッセージを受信した場合、ノードはHelloメッセージを送信してはならず (MUST NOT)、制御チャネルはup状態に移行すべきではありません (SHOULD NOT)。制御チャネル全体の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メッセージには2つのシーケンス番号が含まれています。最初のシーケンス番号（TxSeqNum）は送信されるハローメッセージのシーケンス番号であり、2番目のシーケンス番号（RcvSeqNum）は、このコントロール上の隣接ノードから受信した最後のハローメッセージのシーケンス番号です。チャネル。
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.
2つの特別なシーケンス番号があります。TxSeqNum は決して 0 であってはなりません (MUST NOT)。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.
通常の操作では、受信されるハローメッセージのRcvSeqNumと生成されるローカルTxSeqNumの違いは、最大1です。この違いは、コントロールチャネルが再起動したときまたは値が包むときにのみ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;
}
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 Packetsに含めることにより、ローカルノードは、リモートノードが受信したハローパケットを把握します。
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つのノードでの操作のみが表示され、代替シナリオが可能であることに注意してください。
1) After completing the configuration stage, Node A sends Hello messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
1) 構成段階を完了した後、ノードAは{TxSeqNum=1; RcvSeqNum=0}でノードBにハローメッセージを送信します。
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は、{TxSeqNum=1; RcvSeqNum=1}でノードBからHelloを受信します。HelloIntervalがノードAで有効期限が切れると、{TxSeqNum=2; RcvSeqNum=1}でhellosをノードBに送信します。
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は、{TxSeqNum=2; RcvSeqNum=2}でノードBからHelloを受信します。HelloIntervalがノードAで有効期限が切れると、{TxSeqNum=3; RcvSeqNum=2}でhellosをノードBに送信します。
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フラグを利用できます。ノードのペア間でデータリンクがまだ使用されている場合、データリンクの管理に使用できる他のアクティブな制御チャネルがある場合にのみ、制御チャネルを管理して削除すべきです (SHOULD)。
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フラグを設定しなければなりません (MUST)。コントロールチャネルダウンプロシージャを開始したノードは、HellodeadeadeadInterval秒が渡された後、または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フラグセットでハローメッセージを送信し、コントロールチャネルをダウン状態に移動すべきです (SHOULD)。
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リンクは縮退（Degraded）状態になります。
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リンクが予約されていないリソースなしで宣伝されるように、ルーティングと信号を通知すべきです (SHOULD)。
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リンクに対してLinkプロパティ相関交換が定義されています。これらのメッセージの内容は、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リンクには、リンクの各端に割り当てられる識別子（Link_Id）があります。これらの識別子は、両端で同じタイプ（つまり、IPv4、IPv6、非番号なし）でなければなりません (MUST)。LinkSummaryメッセージが異なるローカルおよびリモートTEリンクタイプで受信される場合、エラーコード「悪いTEリンクオブジェクト」でLinkSummaryNackメッセージを送信しなければなりません (MUST)。同様に、各データリンクには、両端に識別子（Interface_Id）が割り当てられます。これらの識別子は、両端でも同じタイプでなければなりません (MUST)。LinkSummaryメッセージが異なるローカルおよびリモートインターフェイス_IDタイプで受信された場合、LinkSummaryNackメッセージをエラーコード「悪いデータリンクオブジェクト」で送信しなければなりません (MUST)。
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.
リンクプロパティの相関は、リンクが発生する前に実行すべきであり (SHOULD)、検証プロセスではなくリンクが起きているときにいつでも実行できます (MAY)。
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）交換、相関（矛盾を決定するために）、またはインターフェイス_ID（Port_Idsまたはコンポーネントリンク識別子のいずれか）を変更する。
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_LINKオブジェクトに続いて1つ以上のDATA_LINKオブジェクトが含まれます。TE_LINKオブジェクトは、TE LinkのローカルおよびリモートLink_Idを識別し、そのTEリンクの障害管理およびリンク検証手順のサポートを示しています。DATA_LINKオブジェクトは、TEリンクを構成するデータリンクを特徴付けるために使用されます。これらのオブジェクトには、ローカルおよびリモートのインターフェイス_IDが含まれ、データリンクのプロパティをさらに説明する1つ以上のサブオブジェクトが含まれる場合があります。
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メッセージがリモートノードから受信され、Interface_Idマッピングがローカルに保存されているマッピングと一致する場合、2つのノードは検証手順（セクション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 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.
LinkSummaryAckメッセージは、Interface_Idマッピングの合意とリンクプロパティの定義を信号にするために使用されます。それ以外の場合、LinkSummaryNackメッセージを送信しなければならず (MUST)、どのインターフェイスマッピングが正しくないか、および/またはどのリンクプロパティが受け入れられないかを示します。LinkSummaryNackメッセージがInterface_Idマッピングが正しくなく、リンク検証手順が有効であることを示している場合、すべての不一致の無料データリンクについてリンク検証プロセスを繰り返すべきです (SHOULD)。割り当てられたデータリンクにマッピングの不一致がある場合、無料になったときにフラグを立てて確認すべきです (SHOULD)。LinkSummaryNackメッセージに交渉可能なパラメーターが含まれている場合、それらのパラメーターの許容値を含めなければなりません (MUST)。LinkSummaryNackメッセージが受信され、交渉可能なパラメーターが含まれている場合、LinkSummaryメッセージのイニシエーターは新しいLinkSummaryメッセージを送信すべきです (SHOULD)。新しいLinkSummaryメッセージには、交渉可能なパラメーターの新しい値を含めるべきです (SHOULD)。これらの値は、LinkSummaryNackメッセージで受信される許容値を考慮に入れるべきです (SHOULD)。
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メッセージを送信するときに断片化できるべきであり (SHOULD)、LMPメッセージを受信するときにIPフラグメントを再組み立てることができなければなりません (MUST)。
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リンクとInterface_Idアソシエーションを動的に学習する（つまり、発見）するために使用できるオプションの手順を説明します。この手順は、TEリンクを確立するときと、その後、TEリンクのすべての未割り当て（空き）データリンクについて定期的に行うべきです (SHOULD)。
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メッセージを「このリンクにサポートされていないリンク検証手順」を示すエラーコードで送信しなければなりません (MUST)。
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ペイロードの終了など）、したがって、テストメッセージを輸送するさまざまなメカニズムをサポートするために、検証輸送メカニズムフィールドがBeginifyifyおよびbegverifaickメッセージに含まれています。
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.
すべてのデータリンクを同時に終了するという要件はありません。ただし、少なくとも、データリンクを一度に1つずつ終端できなければなりません (MUST)。さらに、リンク検証手順では、Nodalアーキテクチャがデータを送信してデータリンクで送信して受信できるように設計されていると想定されています。各データリンクは、次の不透明なデバイスに転送される前に電気的に終了および処理されるため、この要件は不透明デバイスにとって簡単であることに注意してください。しかし、透明なデバイスでは、これは追加の要件です。
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.
2つのノードを相互接続するには、それらの間にTEリンクが定義され、最低限、ノード間に少なくとも1つのアクティブな制御チャネルがなければなりません (MUST)。リンク検証のために、TEリンクは少なくとも1つのデータリンクを含まなければなりません (MUST)。
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.
2つのノード間に制御チャネルが確立されると、TEリンクで指定された各データリンクでテストメッセージを交換することにより、データリンク接続を検証できます。テストメッセージを除くすべてのLMPメッセージは、コントロールチャネルを介して交換され、データリンク検証プロセス中に各コントロールチャネルでハローメッセージが引き続き交換されることに注意してください。テストメッセージは、検証されているデータリンクを介して送信されます。データリンクは、単方向であるため、送信方向でテストされます。したがって、両方のノードが（独立して）テストメッセージを同時に交換できる可能性があります。
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.
リンク検証手順を開始するには、ローカルノードは制御チャネルを介してbeginifyメッセージを送信しなければなりません (MUST)。リンク検証の範囲を特定のTEリンクに制限するには、ローカルLink_Idはゼロ以外でなければなりません (MUST)。このフィールドがゼロの場合、データリンクは複数のTEリンクにまたがる可能性があります。ローカルLink_Idフィールドがゼロである場合、BEGIN_VERIFYオブジェクトの「すべてのリンク」フラグを使用して、複数のTEリンクにまたがるデータリンクとTEリンクにまだ割り当てられていないデータリンクを区別します。具体的には、複数のTEリンクにまたがるデータリンクの検証は、ローカルLink_Idフィールドをゼロに設定し、「すべてのリンクを検証する」フラグを設定することにより示されます。TEリンクにまだ割り当てられていないデータリンクの検証は、ローカルLink_Idフィールドをゼロに設定し、「すべてのリンクを検証する」フラグをクリアすることにより示されます。
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 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).
リモートノードがBeginVerifyメッセージを受信し、Testメッセージを処理する準備ができている場合、TESTメッセージに望ましいトランスポートメカニズムを指定したBeginVerifyAckメッセージを、ローカルノードに返送しなければなりません (MUST)。リモートノードは、BeginVerifyAckメッセージに32ビットのノード固有のVerify_Idを含めます。Verify_Idはランダムに選択されてもよいです (MAY)。ただし、それを選択するノードが現在使用している他のVerify_Idと重複してはなりません (MUST NOT)。Verify_Idは、対応するすべての検証メッセージで使用され、異なるLMPピアや並列のTest手順からそれらを区別します。ローカルノードがリモートノードからBeginVerifyAckメッセージを受信すると、各データリンクで定期的にTestメッセージを送信することにより、データリンクのテストを開始する場合があります。Testメッセージには、Verify_Idと、関連するデータリンクのローカルInterface_Idが含まれます。リモートノードは、各データリンクに対する応答として、TestStatusSuccessまたはTestStatusFailureメッセージのいずれかを送信しなければなりません (MUST)。TestStatusSuccessおよびTestStatusFailureメッセージの受信を確認するために、TestStatusAckメッセージを送信しなければなりません (MUST)。確認応答されていないTestStatusSuccessおよびTestStatusFailureメッセージは、メッセージが確認応答されるか、再試行の上限に達するまで再送信されるべきです (SHOULD)（セクション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メッセージを送信すべきです (SHOULD)。
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.
メッセージ相関は、メッセージ識別子とVerify_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.
テストメッセージを受信すると、受信したInterface_Id（構成に応じてポートラベルまたはコンポーネントリンク識別子のいずれかとしてgmplsで使用）が記録され、そのデータリンクのローカルInterface_Idにマッピングされ、TestStatusSuccessメッセージを送信しなければなりません (MUST)。TestStatusSuccessメッセージには、テストメッセージで受信したInterface_IdおよびVerify_IdとともにローカルInterface_Idが含まれます。TestStatusSuccessメッセージの受信は、リモートノードでテストメッセージが検出され、データリンクの物理的な接続性が検証されたことを示しています。TestStatusSuccessメッセージが受信されると、ローカルノードはデータリンクを上にマークし、TestStatusAckメッセージをリモートノードに送信すべきです (SHOULD)。ただし、テストメッセージが観測期間内にリモートノードで検出されない場合（VerifyDeadIntervalで指定）、リモートノードはコントロールチャネル上にtestStatusefailureメッセージを送信しなければなりません (MUST)。リンクは失敗しました。ローカルノードがTestStatusFailureメッセージを受信すると、データリンクが故障したようにマークを付け、TestStatusAckメッセージをリモートノードに送信すべきです (SHOULD)。リスト上のすべてのデータリンクがテストされている場合、ローカルノードはこのリンクでテストが完了したことを示すためにEndVerifyメッセージを送信すべきです (SHOULD)。
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.
ローカルノードとリモートノードの両方は、相関目的でInterface_Idマッピングの完全なリストを維持すべきです (SHOULD)。
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リンクは3つのフリーポート（それぞれが個別のファイバーに沿って送信）で構成され、双方向制御チャネル（「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
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 +
+ + + +
+---------------------+ +---------------------+
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.
このセクションでは、TEリンクの1つ以上のデータチャネルのステータスを迅速に通知することにより、障害を管理するために使用されるオプションのLMP手順を説明します。この手順の範囲はTEリンク内であるため、この手順の使用はLinkSummary Exchangeの一部として交渉されます。この手順は、データリンクと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.
2つのノードを接続するTEリンクは、多数のデータリンクで構成されている可能性があることを思い出してください。1つ以上のデータリンクが2つのノード間で失敗した場合、適切な保護/修復メカニズムを開始できるように、迅速な障害通知にメカニズムを使用する必要があります。障害がその後クリアされた場合、メカニズムを使用して、障害が明確であり、チャネルステータスが問題ないことを通知する必要があります。
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.
障害検出は、障害に最も近いレイヤーで処理する必要があります。光ネットワークの場合、これは物理的な（光学的）層です。物理層での障害検出の1つの尺度は、光の損失を検出することです（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.
状況によっては、2つのノード間のデータリンク障害が下流に伝播され、すべての下流ノードが障害をローカライズすることなく障害を検出します。同じ障害に起因する複数のアラームを回避するために、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 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.
隣接するノード間の特定のリンクに障害をローカライズするために、データリンクの障害を検出する下流ノード（データフローの点で下流）が、障害が検出されたことを示す上流の隣人にチャンネルStatusメッセージを送信します（障害が検出されたことを示す（失敗したすべてのデータリンク）。ChannelStatusメッセージを受信するアップストリームノードは、ChannelStatusメッセージを受信したことを示す下流ノードにChannelStatusAckメッセージを送信しなければなりません (MUST)。アップストリームノードは、対応するLSPに対して故障が局所的に検出されているかどうかを確認できないことを相関させる必要があります。たとえば、上流ノードの入力または内部的に障害が明らかになった場合、アップストリームノードは障害をローカライズします。障害が相関すると、上流のノードは、チャネルが故障しているか大丈夫であることを示す下流ノードにチャネルStatusメッセージを送信すべきです (SHOULD)。ChannelStatusメッセージがダウンストリームノードによって受信されない場合、問題のチャネルにChannelStatusRequestメッセージを送信すべきです (SHOULD)。障害がローカライズされると、シグナリングプロトコルを使用して、スパンまたはパスの保護および復元手順を開始することができます。
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リンク障害を通知する場合があります (MAY)。これは、CHANNEL_STATUSオブジェクトにInterface_Idsを含めることなく、TEリンクを識別するChannelStatusメッセージに障害通知を送信することによって行われます。
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では、4つのノードが線形配列構成で接続されているサンプルネットワークが表示されます。制御チャネルは双方向であり、「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は障害を検出し、対応するアップストリームノードへの障害（lol）を示すチャネルスタッタスメッセージをノード3に送信します。ノード3がノード4からChannelStatusメッセージを受信すると、ChannelStatusAckメッセージをノード4に戻し、局所的に障害を相関させます。ノード3が障害を相関させ、障害が明確であることを確認すると、ノード3とノード4の間のデータリンクへの障害をローカライズしました。ローカライズ。
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番目の例[図2（b）を参照]では、単一の障害（ファイバーカットなど）が双方向LSPの両方向に影響します。ノード2（ノード3）は、上流（下流）方向の障害を検出し、障害を示す（LOL）を示す上流の（データフローの観点から）上流（LOL）にChannelStatusメッセージを送信します。同時に（伝播遅延を無視）、ノード1（ノード4）は、上流（下流）方向の障害を検出し、障害を示す対応するアップストリーム（データフローの観点から）ノードにチャネルスタッタスメッセージを送信します。ノード2とノード3には、障害の2つの方向がローカライズされます。
+-------+ +-------+ +-------+ +-------+
+ 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：2種類のデータリンク障害が示されています（図の##で示されています）：（a）双方向LSPの下流方向に対応するデータリンクは失敗します。（b）両方方向に対応する2つのデータリンク双方向LSPの失敗の。2つのノードを接続する制御チャネルは、「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メッセージを受信するときに送信しなければなりません (MUST)。ChannelStatusメッセージが受信されると、対応するデータリンクをアクティブ状態に配置しなければなりません (MUST)。それらをアクティブな状態に配置すると、障害が検出された場合、セクション6.2で説明されているように、チャネルStatusメッセージを送信すべきです (SHOULD)。
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メッセージがチャネル非アクティブな表示で受信される場合、対応するデータリンクはアクティブ状態から取り出さなければなりません (MUST)。
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.
MESSAGE_IDおよびMESSAGE_ID_ACKオブジェクトは、信頼できるメッセージ配信をサポートするためにLMPメッセージに含まれています。このセクションでは、これらのオブジェクトの使用について説明します。MESSAGE_IDおよびMESSAGE_ID_ACKオブジェクトには、MESSAGE_IDフィールドが含まれています。
Only one MESSAGE_ID/MESSAGE_ID_ACK object may be included in any LMP message.
任意のLMPメッセージに含めることができるメッセージ_ID/MESSAGE_ID_ACKオブジェクトは1つだけです。
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.
コントロールチャネル固有のメッセージの場合、Message_IdフィールドはCC_Idの範囲内にあります。TEリンク固有のメッセージの場合、Message_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フィールドには、ジェネレーター選択値が含まれています。この値は単調に増加しなければなりません (MUST)。値は、同じ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オブジェクトで送信された未承認のメッセージは、メッセージが確認されるまで、または再試行制限に達するまで再送信すべきです (SHOULD)（セクション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値がラップする場合があることに注意してください。次の式を使用して、新しく受信したMessage_Id値が以前に受信された値よりも少ないかどうかをテストできます。
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.
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.
メッセージが構成メッセージであり、メッセージ_ID値がCC_Idの送信者から以前に受信した最大のメッセージ_ID値よりも小さい場合、メッセージはオーダーの秩序であると扱われるべきです (SHOULD)。
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メッセージであり、メッセージ_ID値がTEリンクの送信者から以前に受信された最大のメッセージ_ID値よりも小さい場合、メッセージはオーダーの順序であると扱われるべきです (SHOULD)。
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メッセージであり、Message_Id値が指定されたTEリンクの送信者から以前に受信した最大のメッセージ_ID値よりも小さい場合、受信者は、ChannelStatusに含まれる各データチャネルの状態について以前に受信したメッセージ_ID値を確認すべきです (SHOULD)メッセージ。Message_Id値が、メッセージに含まれるデータチャネルの少なくとも1つに関連付けられている最近の受信したMessage_Id値よりも大きい場合、メッセージは順番に扱われてはなりません (MUST NOT)。それ以外の場合、メッセージは故障していると扱われるべきです (SHOULD)。ただし、Message_Id値がデータチャネルに関連付けられている最近の受信したMessage_Id値よりも少ない場合、データチャネルの状態を更新してはなりません (MUST NOT)。
All other messages MUST NOT be treated as out-of-order.
他のすべてのメッセージは、オーダーの外れとして扱われてはなりません (MUST NOT)。
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 RestArt」ビットを設定することで検出されます。制御チャネルの損失により制御プレーンが故障した場合、LMPリンク情報を保持する必要があります。ノードがノード障害全体にLMPリンク情報を保持できる可能性があります。ただし、どちらの場合も、データチャネルのステータスは同期されなければなりません (MUST)。
It is assumed the Node_Id and Local Interface_Ids remain stable across a control plane restart.
Node_IdとローカルInterface_Idsは、コントロールプレーンの再起動全体で安定したままであると想定されています。
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の送信元アドレスと宛先アドレスを使用してConfigメッセージを送信すべきです (SHOULD)。
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メッセージに設定しなければなりません (MUST)。これは、制御チャネルがアップしており、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リンクの一端でのみ発生することを前提としています。TEリンクの両端でLMPコンポーネントの再起動が発生した場合、セクション4で説明されているように、LinkSummaryの通常の手順を使用する必要があります。
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.
制御チャネルがupになると、LMPネイバーは、隣接関係をまたぐ各TEリンクに対してLinkSummaryメッセージを送信しなければなりません (MUST)。LinkSummaryメッセージのすべてのオブジェクトは、パラメーターがネゴシエート不可であることを示すため、Nビットを0に設定しなければなりません (MUST)。これにより、ローカル/リモートのLink_IdおよびInterface_Idのマッピング、関連するデータリンクのパラメーター、および現在ユーザートラフィックに割り当てられているデータリンクの表示が提供されます。ノードはLinkSummaryメッセージを受信すると、ローカルの構成を確認します。ノードが再起動をまたいでLMPリンク情報を保持できる場合、LinkSummaryメッセージで受信したDATA_LINKオブジェクトの割り当て済み/割り当て解除済みフラグがローカルの値よりも優先されなければなりません (MUST) 点を除き、セクション4で説明されているとおりにLinkSummaryメッセージを処理する必要があります。ただし、ノードが再起動をまたいでLMPリンク情報を保持できなかった場合、ノードは受信したLinkSummaryメッセージのデータリンクパラメーターを受け入れ、LinkSummaryAckメッセージで応答しなければなりません (MUST)。
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メッセージを送信すべきです (SHOULD)。また、ノードは、割り当てられていないすべてのデータチャネルの接続性を検証すべきです (SHOULD)。
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 received Config message), an IP address configured on the remote node, or the Node_Id. The Config message is an exception as described below.
すべてのLMPメッセージは、LMPポート番号を使用してUDP上で実行されます（場合によっては、インバンドメッセージングのトランスポートメカニズムによって制限されることがあるTestメッセージを除きます）。IPパケットの宛先アドレスは、構成手順で学習したアドレス（つまり、受信したConfigメッセージのIPヘッダーにある送信元IPアドレス）、リモートノードに構成されたIPアドレス、またはNode_Idのいずれかであってもよいです (MAY)。Configメッセージは、以下に説明するように例外です。
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）に送信すべきです (SHOULD)。それ以外の場合、構成メッセージは、隣接するノードのIPアドレスに送信しなければなりません (MUST)。これは、制御チャネルの両端で構成されるか、自動的に検出される場合があります。
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]に基づいており、メッセージの再送信のための指数関数的なバックオフ手順を提供します。実装は、説明されている手順または同等の手順を使用しなければなりません (MUST)。
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メッセージの指数バックオフ再送信のための1つの可能なメカニズムです。送信ノードは、確認メッセージが受信されるまで、または再試行制限に達するまでメッセージを再送信します。送信ノードが確認を受信すると、メッセージの再送信が停止されます。メッセージの再送信間の間隔は、迅速な再送信タイマーによって支配されます。迅速な再送信タイマーは小さな間隔から始まり、しきい値に達するまで指数関数的に増加します。
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:
Rapid Retry Limit RL：
Rl is the maximum number of times a message will be transmitted without being acknowledged.
RLは、メッセージが認められずに送信される最大回数です。
Increment value Delta:
増分値Delta：
Delta governs the speed with which the sender increases the retransmission interval. The ratio of two successive retransmission intervals is (1 + Delta).
デルタは、送信者が再送信間隔を増加させる速度を支配します。2つの連続した再送信間隔の比率は（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ミリ秒の初期再送信間隔（RI）の提案されたデフォルト値は、2指数バックオフ（Delta = 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秒が経過する前に対応する確認応答メッセージを受信した場合、メッセージの再送信はキャンセルすべきです (SHOULD)。そうでない場合は、(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;
Asynchronously, when a sending node receives a corresponding acknowledgment message, it will change the retry count, Rn, to Rl.
非同期的に、送信ノードが対応する確認メッセージを受信すると、RETRYカウント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.
送信ノードは、構成メッセージまたは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.
制御チャネルは、以下に説明する州の1つにあります。すべての状態は、制御チャネルの特定の条件に対応し、通常、定期的に遠端に送信される特定のタイプの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メッセージまたはcondignackメッセージを使用して返信することを期待しています。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.
frrcv：制御チャネルはパラメーターネゴシエーション状態にあります。この状態では、ノードはリモート側からの許容可能な構成パラメーターを待っています。そのようなパラメーターが受信され、認められると、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.
アクティブ：この状態では、ノードは定期的にハローメッセージを送信し、有効なハローメッセージを受信するのを待っています。有効なハローメッセージが受信されると、UP状態に移行できます。
Up: The CC is in an operational state. The node receives valid Hello messages and sends Hello messages.
UP：CCは運用状態です。ノードは有効なハローメッセージを受信し、ハローメッセージを送信します。
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.
LMP制御チャネルの動作は、FSM状態とイベントの観点から説明されています。コントロールチャネルイベントは、基礎となるプロトコルとソフトウェアモジュール、および関連する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：evBringUp：これは、コントロールチャネルのネゴシエーションが開始されることを示す外部からトリガーされたイベントです。たとえば、このイベントは、オペレーターコマンド、コントロールチャネルブートストラップ手順が正常に完了すること、または構成によってトリガーされる場合があります。構成に応じて、これにより、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メッセージが受信され、configパラメーターが認められていることを示しています。
4 : evConfErr: This event indicates a ConfigNack message has been received, rejecting the Config parameters.
4：evConfErr：このイベントは、confingのメッセージが受信され、構成パラメーターが拒否されたことを示しています。
5 : evNewConfOK: New Config message was received from neighbor and positively acknowledged.
5：evNewConfOK：新しい構成メッセージが隣人から受信され、積極的に認められました。
6 : evNewConfErr: New Config message was received from neighbor and rejected with a ConfigNack message.
6：evNewConfErr：新しい構成メッセージがNeighborから受信され、condinackメッセージで拒否されました。
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：新しい構成メッセージが隣人からneighborに送信されたと同時に、隣人から受信されました。ローカルノードが競合に勝ちます。その結果、受信した構成メッセージは無視されます。
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を備えたハローパケットが受信されました。
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：HellodeadeadIntervalタイマーの有効期限が切れ、Hello Packetが受信されていないことを示しています。これにより、コントロールチャネルがネゴシエーション状態に戻り、ローカル構成によっては、12a）のいずれかの12a）のいずれかをトリガーします。定期的な構成メッセージの送信、12b）リモートノードから構成メッセージを受信するのを待っています。
13: evSeqNumErr: A Hello with unexpected SeqNum received and discarded.
13：evSeqNumErr：予期しないSeqNumが受け取って廃棄されたこんにちは。
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：再送信タイマーの有効期限が切れ、構成メッセージがresしています。
16: evHelloRet: The HelloInterval timer has expired and a Hello packet is sent.
16：evHelloRet：HelloIntervalタイマーの有効期限が切れ、ハローパケットが送信されます。
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
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リンクは、以下に説明する州の1つにあります。すべての状態はTEリンクの特定の条件に対応し、通常、関連するコントロールチャネルまたはデータリンクを介してインバンドを介して遠端に定期的に送信される特定のタイプの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リンクの通常の動作状態です。少なくとも1つのLMP制御チャネルが、TEリンクを共有するノード間で動作する必要があります。通常の操作の一環として、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.
LMP TEリンクの操作は、FSM状態とイベントの観点から説明されています。TEリンクイベントは、パケット処理ルーチンと、関連する制御チャネルのFSMおよびデータリンクによって生成されます。すべてのイベントには、その番号と象徴的な名前があります。可能なイベントの説明を以下に示します。
1 : evDCUp: One or more data channels have been enabled and assigned to the TE Link.
1：evDCUp：1つ以上のデータチャネルが有効になり、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：再送信タイマーの有効期限が切れ、LinkSummaryメッセージがresしています。
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：EVDEダウン：リンクの最後のデータチャネルが削除されました。
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
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.
データリンクは、以下に説明する州の1つにあります。すべての状態は、データリンクの特定の条件に対応しています。
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.
PASテスト：データリンクは、受信テキストメッセージがチェックされています。
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リンクのFSMSによって生成されます。
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 Neighbor Connectivityが失われます。これは、最後の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を参照）が成功し、テストスタッサクセスメッセージがコントロールチャネルを介して受信されたことを示しています。
(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：テストメッセージはデータポートを介して受信され、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）データリンクのテストスタッセスまたは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：再送信タイマーの有効期限が切れ、テストメッセージがresしています。
12:evSummaryFail: The LinkSummary did not match for this data port.
12：evSummaryFail：LinkSummaryはこのデータポートと一致しませんでした。
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 |------+
| |
+---------+
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 |-----+
| |
+---------+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Reserved field should be sent as zero and ignored on receipt.
Reservedフィールドはゼロとして送信すべきであり、受信時には無視すべきです。
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コントロール状態が失われたことを示すように設定されています。このフラグは、ローカルTxSeqNumに等しいRcvSeqNumでハローメッセージが受信されると、0にリセットされる場合があります。
Msg Type: 8 bits
MSGタイプ：8ビット
The following values are defined. All other values are reserved
次の値が定義されています。他のすべての値は予約されています
1 = Config
2 = ConfigAck
3 = ConfigNack 4 = Hello
3 = confing 4 =こんにちは
5 = BeginVerify
6 = BeginVerifyAck
7 = BeginVerifyNack
8 = EndVerify
9 = EndVerifyAck
10 = Test
11 = TestStatusSuccess
12 = TestStatusFailure
13 = TestStatusAck
14 = LinkSummary
15 = LinkSummaryAck
16 = LinkSummaryNack
17 = ChannelStatus
18 = ChannelStatusAck
19 = ChannelStatusRequest
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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
The MESSAGE_ID object is within the scope of the LOCAL_CCID object.
MESSAGE_IDオブジェクトは、LOCAL_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.
Configメッセージは、（1）ConfigAckまたはConfigNackメッセージを受信するか、（2）再試行の上限に達してもConfigAckまたはConfigNackメッセージを受信していないか、（3）リモートノードからConfigメッセージを受信して競合に負ける（たとえば、リモートノードのNode_IdがローカルノードのNode_Idよりも大きい）まで、定期的に送信しなければなりません (MUST)。再送信間隔と再試行の上限は、どちらもローカルな設定パラメーターです。
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>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being acknowledged.
REMOTE_CCID、MESSAGE_ID_ACK、およびREMOTE_NODE_IDオブジェクトの内容は、確認されている構成メッセージから取得しなければなりません (MUST)。
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:
condignackメッセージは、構成メッセージの受信を確認し、交渉不可能なパラメーターに関する意見の相違を示すために使用されるか、交渉可能なパラメーターの他の値を提案します。合意に達したパラメーターは、condignackメッセージに含めてはなりません (MUST NOT)。condignackメッセージの形式は次のとおりです。
<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.
上記の送信順序に従うべきです (SHOULD)。
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being negatively acknowledged.
REMOTE_CCID、MESSAGE_ID_ACK、およびREMOTE_NODE_IDオブジェクトの内容は、否定的に確認されている構成メッセージから取得しなければなりません (MUST)。
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.
交渉可能なconfigオブジェクトがcondignackメッセージに含まれている場合、パラメーターの許容値を含めなければなりません (MUST)。
If the ConfigNack message includes CONFIG objects for non-negotiable parameters, they MUST be copied from the CONFIG objects received in the Config message.
condignackメッセージに交渉不可能なパラメーターの構成オブジェクトが含まれている場合、それらは構成メッセージで受信された構成オブジェクトからコピーしなければなりません (MUST)。
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.
condignackメッセージが受信され、交渉可能な構成オブジェクトのみが含まれている場合は、新しい構成メッセージを送信すべきです (SHOULD)。新しい構成メッセージの構成オブジェクト内の値は、confingackメッセージに含まれる許容値を考慮に入れるべきです (SHOULD)。
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タイプを認識しない場合、不明な構成オブジェクトを含むcondignackメッセージを送信しなければなりません (MUST)。
The format of the Hello message is as follows:
Helloメッセージの形式は次のとおりです。
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
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 msecを定期的に送信しなければなりません (MUST)。HellodeadeadInterval内で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>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
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リンクに制限するには、LOCAL_LINK_IDオブジェクトのLink_Idフィールドはゼロ以外でなければなりません (MUST)。このフィールドがゼロの場合、データリンクは複数のTEリンクにまたがる可能性があり、また、まだ設定されていないTEリンクを構成する可能性もあります。ローカルLink_Idフィールドがゼロである特別な場合、BEGIN_VERIFYオブジェクトの「すべてのリンク」フラグを使用して、複数のTEリンクにまたがるデータリンクとまだTEリンクに割り当てられていないデータリンクを区別するために使用されます（セクションを参照5）。
The REMOTE_LINK_ID object may be included if the local/remote Link_Id mapping is known.
local/remote Link_Idマッピングが既知である場合、REMOTE_LINK_IDオブジェクトが含まれる場合があります。
The Link_Id field of the REMOTE_LINK_ID object MUST be non-zero if included.
REMOTE_LINK_IDオブジェクトのLink_Idフィールドは、含まれている場合はゼロ以外でなければなりません (MUST)。
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）NodeがBeginVerifyAckまたはBeginVerifyNackメッセージを受信して検証プロセスを受け入れるか拒否するまで定期的に送信しなければなりません (MUST)。再送信間隔と再試行制限の両方は、ローカル構成パラメーターです。
When a BeginVerify message is received and Test messages are ready to be processed, a BeginVerifyAck message MUST be transmitted.
BeginVerifyメッセージが受信され、テストメッセージを処理する準備ができたら、BeginVerifyAckメッセージを送信しなければなりません (MUST)。
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
The LOCAL_LINK_ID object may be included if the local/remote Link_Id mapping is known or learned through the BeginVerify message.
LOCAL_LINK_IDオブジェクトは、BeginVerifyメッセージを介してnecledまたは習得されている場合、local/remote Link_Idマッピングが既知または学習されている場合に含めることができます。
The Link_Id field of the LOCAL_LINK_ID MUST be non-zero if included.
LOCAL_LINK_IDのLink_Idフィールドは、含まれている場合はゼロ以外でなければなりません (MUST)。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being acknowledged.
MESSAGE_ID_ACKオブジェクトの内容は、確認されているBeginVerifyメッセージから取得しなければなりません (MUST)。
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オブジェクトには、beginifyackメッセージのジェネレーターによって割り当てられるノードユニーク値が含まれています。この値は、複数の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メッセージを送信しなければなりません (MUST)。
<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <ERROR_CODE>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being negatively acknowledged.
MESSAGE_ID_ACKオブジェクトの内容は、否定的に認められているBeginVerifyメッセージから取得しなければなりません (MUST)。
If the Verification process is not supported, the ERROR_CODE MUST indicate "Link Verification Procedure not supported".
検証プロセスがサポートされていない場合、ERROR_CODEは「サポートされていないリンク検証手順」を示さなければなりません (MUST)。
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.
検証がサポートされているが、ノードが手順を開始できない場合、ERROR_CODEは「検証したくない」ことを示さなければなりません (MUST)。このようなERROR_CODEでBeginVerifyNackメッセージが受信された場合、BeginVerifyを発信したノードは、RFがローカルに定義されたパラメーターであるRF秒後にBeginifyの再送信をスケジュールすべきです (SHOULD)。
If the Verification Transport mechanism is not supported, the ERROR_CODE MUST indicate "Unsupported verification transport mechanism".
検証輸送メカニズムがサポートされていない場合、ERROR_CODEは「サポートされていない検証輸送メカニズム」を示さなければなりません (MUST)。
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".
Link_Idのリモート構成がサポートされておらず、REMOTE_LINK_IDオブジェクトのコンテンツ（BeginVerifyメッセージに含まれる）が構成された値と一致しない場合、ERROR_CODEは「Link_Id configurationエラー」を示さなければなりません (MUST)。
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_VERIFYオブジェクトを認識し、c型を認識していない場合、ERROR_CODEは「不明なオブジェクトcタイプ」を示さなければなりません (MUST)。
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>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
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>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the EndVerify message being acknowledged.
MESSAGE_ID_ACKオブジェクトの内容は、確認されているEndVerifyメッセージから取得しなければなりません (MUST)。
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を介して送信しなければなりません (MUST)。テストメッセージの形式は次のとおりです。
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
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オブジェクトの検証輸送メカニズムフィールドとBEGIN_VERIFY_ACKオブジェクトの検証輸送応答フィールドを使用してネゴシエートされます（セクション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.
ローカル（送信）ノードは、特定のテストメッセージを、対応するデータリンクに定期的に（少なくとも1回は、少なくとも1回は、少なくとも1回は、少なくとも1回は、少なくとも1回はすべて）、（1）リモート（受信）ノードからコントロールチャネル上の相関テストスタッセスまたはTestStatusFailureメッセージを受信するまで送信します。2）2つのノード間のすべてのアクティブ制御チャネルは失敗しました。リモートノードは、相関するTestStatusAckメッセージまたはEndVerifyメッセージのいずれかを受信するまで、制御チャネル上で定期的に特定のTestStatusメッセージを送信します。
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>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
The contents of the REMOTE_INTERFACE_ID object MUST be obtained from the corresponding Test message being positively acknowledged.
REMOTE_INTERFACE_IDオブジェクトの内容は、積極的に確認されている対応するテストメッセージから取得しなければなりません (MUST)。
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>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
The TestStatusAck message is used to acknowledge receipt of the TestStatusSuccess or TestStatusFailure messages.
TestStatusAckメッセージは、TestStatusSuccessまたはtestStatusefailureメッセージの受信を確認するために使用されます。
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the TestStatusSuccess or TestStatusFailure message being acknowledged.
MESSAGE_ID_ACKオブジェクトの内容は、確認されているTestStatusSuccessまたはTestStatusFailureメッセージから取得しなければなりません (MUST)。
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メッセージは、Interface_Idsを同期し、TEリンクのプロパティを相関させるために使用されます。LinkSummaryメッセージの形式は次のとおりです。
<LinkSummary Message> ::= <Common Header> <MESSAGE_ID> <TE_LINK>
<DATA_LINK> [<DATA_LINK>...]
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
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メッセージが受信されないまで定期的に送信しなければなりません (MUST)。再送信間隔と再試行制限の両方は、ローカル構成パラメーターです。
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メッセージは、Interface_Idの同期とすべてのリンクパラメーターの受け入れ/合意に関する一致を示すために使用されます。ローカルノードがLink_Idアソシエーションを作成するのは、このメッセージの受信です。
<LinkSummaryAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
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メッセージに含まれてはなりません (MUST NOT)。
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...]
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
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.
DATA_LINKオブジェクトには、すべての交渉可能なパラメーターに許容可能な値を含めなければなりません (MUST)。LinkSummaryNackに交渉不可能なパラメーターのDATA_LINKオブジェクトが含まれている場合、それらはLinkSummaryメッセージで受信したDATA_LINKオブジェクトからコピーしなければなりません (MUST)。
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メッセージを送信すべきです (SHOULD)。新しいLinkSummaryメッセージで受信された値は、LinkSummaryNackメッセージに含まれる許容可能なパラメーターを考慮すべきです (SHOULD)。
If the LinkSummary message is received with unacceptable, non-negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable non-negotiable LINK_SUMMARY parameters." If the LinkSummary message is received with unacceptable negotiable parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY parameters."
LinkSummaryメッセージが受け入れられない交渉不可能なパラメーターで受信される場合、ERROR_CODEは「容認できない交渉不可能なLINK_SUMMARYパラメーター」を示さなければなりません (MUST)。LinkSummaryメッセージが受け入れられない交渉可能なパラメーターで受信された場合、ERROR_CODEは「RENEGOTIATE LINK_SUMMARYパラメーター」を示さなければなりません (MUST)。
If the LinkSummary message is received with an invalid TE_LINK object, the ERROR_CODE MUST indicate "Invalid TE_LINK object."
LinkSummaryメッセージが無効なTE_LINKオブジェクトで受信された場合、ERROR_CODEは「無効なTE_LINKオブジェクト」を示さなければなりません (MUST)。
If the LinkSummary message is received with an invalid DATA_LINK object, the ERROR_CODE MUST indicate "Invalid DATA_LINK object."
LinkSummaryメッセージが無効なDATA_LINKオブジェクトで受信された場合、ERROR_CODEは「無効なDATA_LINKオブジェクト」を示さなければなりません (MUST)。
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."
LinkSummaryメッセージがTE_LINKオブジェクトで受信されているが、Cタイプが不明な場合、ERROR_CODEは「不明なTE_LINKオブジェクトCタイプ」を示さなければなりません (MUST)。
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メッセージがDATA_LINKオブジェクトで受信されているが、cタイプが不明な場合、ERROR_CODEは「不明なDATA_LINKオブジェクトCタイプ」を示さなければなりません (MUST)。
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メッセージで応答しなければなりません (MUST)。フォーマットは次のとおりです。
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
If the CHANNEL_STATUS object does not include any Interface_Ids, then this indicates the entire TE Link has failed.
CHANNEL_STATUSオブジェクトにInterface_Idsが含まれていない場合、これは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>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the ChannelStatus message being acknowledged.
MESSAGE_ID_ACKオブジェクトの内容は、確認されているChannelStatusメッセージから取得しなければなりません (MUST)。
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メッセージはコントロールチャネルを介して送信され、1つ以上のデータリンクのステータスを要求するために使用されます。ChannelStatusRequestメッセージを受信するノードは、ChannelStatusResponseメッセージで応答しなければなりません (MUST)。フォーマットは次のとおりです。
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>]
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
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オブジェクトが含まれていない場合、ChannelStatusRequestを使用して、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>
The above transmission order SHOULD be followed.
上記の送信順序に従うべきです (SHOULD)。
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ChannelStatusRequest message being acknowledged.
MESSAGE_ID_ACKオブジェクトの内容は、確認されているChannelStatusRequestメッセージから取得しなければなりません (MUST)。
Class = 1
o C-Type = 1, LOCAL_CCID
o c-type = 1、LOCAL_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits
This MUST be node-wide unique and non-zero. The CC_Id identifies the control channel of the sender associated with the message.
これは、ノード全体のユニークでゼロ以外でなければなりません (MUST)。CC_Idは、メッセージに関連付けられた送信者の制御チャネルを識別します。
This object is non-negotiable.
このオブジェクトは交渉できません。
o C-Type = 2, REMOTE_CCID
o c-type = 2、REMOTE_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC_Id: 32 bits
CC_Id：32ビット
This identifies the remote node's CC_Id and MUST be non-zero.
これは、リモートノードのCC_Idを識別し、ゼロ以外でなければなりません (MUST)。
This object is non-negotiable.
このオブジェクトは交渉できません。
Class = 2
o C-Type = 1, LOCAL_NODE_ID
o c-type = 1、LOCAL_NODE_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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id:
Node_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、REMOTE_NODE_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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node_Id:
This identities the remote node.
このアイデンティティはリモートノードです。
This object is non-negotiable.
このオブジェクトは交渉できません。
Class = 3
o C-Type = 1, IPv4 LOCAL_LINK_ID
o c-type = 1、ipv4 LOCAL_LINK_ID
o C-Type = 2, IPv4 REMOTE_LINK_ID
o c-type = 2、ipv4 REMOTE_LINK_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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, IPv6 LOCAL_LINK_ID
o c-type = 3、ipv6 LOCAL_LINK_ID
o C-Type = 4, IPv6 REMOTE_LINK_ID
o c-type = 4、ipv6 REMOTE_LINK_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) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 5, Unnumbered LOCAL_LINK_ID
o c-type = 5、LOCAL_LINK_IDの数はありません
o C-Type = 6, Unnumbered REMOTE_LINK_ID
o c-type = 6、数のREMOTE_LINK_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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link_Id:
For LOCAL_LINK_ID, this identifies the sender's Link associated with the message. This value MUST be non-zero.
LOCAL_LINK_IDの場合、これはメッセージに関連付けられた送信者のリンクを識別します。この値はゼロ以外でなければなりません (MUST)。
For REMOTE_LINK_ID, this identifies the remote node's Link_Id and MUST be non-zero.
REMOTE_LINK_IDの場合、これはリモートノードのLink_Idを識別し、ゼロ以外でなければなりません (MUST)。
This object is non-negotiable.
このオブジェクトは交渉できません。
Class = 4
o C-Type = 1, IPv4 LOCAL_INTERFACE_ID
o c-type = 1、ipv4 LOCAL_INTERFACE_ID
o C-Type = 2, IPv4 REMOTE_INTERFACE_ID
o c-type = 2、ipv4 REMOTE_INTERFACE_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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, IPv6 LOCAL_INTERFACE_ID
o c-type = 3、ipv6 LOCAL_INTERFACE_ID
o C-Type = 4, IPv6 REMOTE_INTERFACE_ID
o c-type = 4、ipv6 REMOTE_INTERFACE_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) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 5, Unnumbered LOCAL_INTERFACE_ID
o c-type = 5、LOCAL_INTERFACE_IDの数はありません
o C-Type = 6, Unnumbered REMOTE_INTERFACE_ID
o c-type = 6、数のREMOTE_INTERFACE_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:
Interface_Id：
For the LOCAL_INTERFACE_ID, this identifies the data link. This value MUST be node-wide unique and non-zero.
LOCAL_INTERFACE_IDの場合、これはデータリンクを識別します。この値は、ノード全体の一意でゼロでなければなりません (MUST)。
For the REMOTE_INTERFACE_ID, this identifies the remote node's data link. The Interface_Id MUST be non-zero.
REMOTE_INTERFACE_IDの場合、これはリモートノードのデータリンクを識別します。Interface_Idはゼロ以外でなければなりません (MUST)。
This object is non-negotiable.
このオブジェクトは交渉できません。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_Id:
Message_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message_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フィールドは、確認されているメッセージを識別するために使用されます。この値は、承認されているメッセージのmessage_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
HelloInterval: 16 bits.
HelloInterval：16ビット。
Indicates how frequently the Hello packets will be sent and is measured in milliseconds (ms).
ハローパケットが送信され、ミリ秒（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内でハローパケットが受信されない場合、制御チャネルが失敗したと想定されます。HelloDeadIntervalは、ミリ秒（ms）で測定されます。HelloDeadIntervalはHelloIntervalよりも大きくなければなりません (MUST)。また、HelloIntervalの値の少なくとも3倍であるべきです (SHOULD)。
If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero.
LMPの高速キープアライブメカニズムが使用されない場合、HelloIntervalとhellodeadeadintervalをゼロに設定しなければなりません (MUST)。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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メッセージの現在のシーケンス番号です。このシーケンス番号は、コントロールチャネルで受信されるハローパケットの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は、これがコントロールチャネル上で送信された最初のハローメッセージであることを示すために使用されます。
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.
これは、コントロールチャネルで受信した最後のハローメッセージのシーケンス番号です。RcvSeqNum=0は、ハローメッセージがまだ受信されていないことを示すために使用されます。
This object is non-negotiable.
このオブジェクトは交渉できません。
Class = 8
o C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
このビットが設定されている場合、検証プロセスはすべての未割り当てリンクをチェックします。それ以外の場合は、このリンクに追加される新しいポートまたはコンポーネントリンクのみを検証します。
0x0002 Data Link Type
0x0002データリンクタイプ
If set, the data links to be verified are ports, otherwise they are component links
設定すると、検証するデータリンクはポートです。それ以外の場合はコンポーネントリンクです
VerifyInterval: 16 bits
VerifyInterval：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
EncType：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.
これは、テストメッセージが送信されるデータリンクの送信速度です。これは1秒あたりバイトで表され、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に設定すべきです (SHOULD)。
Class = 9
o C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | Verify_Transport_Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyDeadInterval: 16 bits
If a Test message is not detected within the VerifyDeadInterval, then a node will send the TestStatusFailure message for that data link.
verifydeadedInterval内でテストメッセージが検出されない場合、ノードはそのデータリンクのTestStatusFailureメッセージを送信します。
Verify_Transport_Response: 16 bits
Verify_Transport_Response：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メッセージの受信者（およびテストメッセージの将来の受信者）は、テストメッセージの送信機によって提供されるさまざまなタイプからトランスポートメカニズムを選択します。検証輸送応答で1ビットを設定しなければなりません (MUST)。
This object is non-negotiable.
このオブジェクトは交渉できません。
Class = 10
o C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verify_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Verify_Id: 32 bits
Verify_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
o C-Type = 1, IPv4 TE_LINK
o c-type = 1、ipv4 TE_LINK
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_LINK
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-type = 3、数のTE_LINK
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:
Local_Link_Id：
This identifies the node's local Link_Id and MUST be non-zero.
これは、ノードのローカルLink_Idを識別し、ゼロ以外でなければなりません (MUST)。
Remote_Link_Id:
Remote_Link_Id：
This identifies the remote node's Link_Id and MUST be non-zero.
これは、リモートノードのLink_Idを識別し、ゼロ以外でなければなりません (MUST)。
Class = 12
o C-Type = 1, IPv4 DATA_LINK
o c-type = 1、ipv4 DATA_LINK
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
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、数のデータDATA_LINK
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割り当てリンク：設定されている場合、データリンクは現在ユーザートラフィックに割り当てられています。単一のInterface_Idが送信および受信データリンクの両方に使用されている場合、このビットは送信インターフェイスにのみ適用されます。
0x04 Failed Link: If set, the data link is failed and not suitable for user traffic.
0x04失敗リンク：設定されている場合、データリンクが故障し、ユーザートラフィックには適していません。
Local_Interface_Id:
Local_Interface_Id：
This is the local identifier of the data link. This MUST be node-wide unique and non-zero.
これは、データリンクのローカル識別子です。これは、ノード全体のユニークでゼロ以外でなければなりません (MUST)。
Remote_Interface_Id:
Remote_Interface_Id：
This is the remote identifier of the data link. This MUST be non-zero.
これは、データリンクのリモート識別子です。これはゼロ以外でなければなりません (MUST)。
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.
DATA_LINKオブジェクトの内容は、サブオブジェクトと呼ばれる一連の可変長データ項目で構成されています。サブオブジェクトは、以下のセクション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.
DATA_LINKオブジェクトには、複数のサブオブジェクトが含まれる場合があります。データリンク上で複数の機能がサポートされている場合、同じタイプの複数のサブオブジェクトが表示される場合があります。
The contents of the DATA_LINK object include a series of variable-length data items called subobjects. Each subobject has the form:
DATA_LINKオブジェクトの内容には、Subobjectsと呼ばれる一連の変数長データ項目が含まれます。各サブオブジェクトにはフォームがあります。
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でなければならず (MUST)、4の倍数でなければなりません (MUST)。
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
EncType：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.
これは、1秒あたりバイトで測定され、IEEEフローティングポイント形式で表されます。
Maximum Reservable Bandwidth: 32 bits
最大予約可能帯域幅：32ビット
This is measured in bytes per second and represented in IEEE floating point format.
これは、1秒あたりバイトで測定され、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
この値は、ポートを介して運ばれる波長を示します。この分野で使用される値は、2つの隣人間でのみ重要です。
Class = 13 o C-Type = 1, IPv4 INTERFACE_ID
class = 13 o c-type = 1、ipv4 INTERFACE_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 2, IPv6 INTERFACE_ID
o c-type = 2、ipv6 INTERFACE_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o C-Type = 3, Unnumbered INTERFACE_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Channel_Status：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.
This object contains one or more Interface_Ids followed by a Channel_Status field.
このオブジェクトには、1つ以上のInterface_Idsに続いてChannel_Statusフィールドが含まれます。
To indicate the status of the entire TE Link, there MUST be only one Interface_Id, and it MUST be zero.
TEリンク全体のステータスを示すには、Interface_Idは1つだけでなければならず (MUST)、それはゼロでなければなりません (MUST)。
This object is non-negotiable.
このオブジェクトは交渉できません。
Class = 14
o C-Type = 1, IPv4 INTERFACE_ID
o c-type = 1、ipv4 INTERFACE_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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
このオブジェクトには、1つ以上のInterface_Idsが含まれています。
The Length of this object is 4 + 4N in bytes, where N is the number of Interface_Ids.
このオブジェクトの長さはバイトが4 4nで、nはInterface_Idsの数です。
o C-Type = 2, IPv6 INTERFACE_ID
o c-type = 2、ipv6 INTERFACE_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) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
このオブジェクトには、1つ以上のInterface_Idsが含まれています。
The Length of this object is 4 + 16N in bytes, where N is the number of Interface_Ids.
このオブジェクトの長さはバイトで4 16nで、nはInterface_Idsの数です。
o C-Type = 3, Unnumbered INTERFACE_ID
o c-type = 3、非numbered INTERFACE_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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This object contains one or more Interface_Ids.
The Length of this object is 4 + 4N in bytes, where N is the number of Interface_Ids.
このオブジェクトの長さはバイトが4 4nで、nはInterface_Idsの数です。
This object is non-negotiable.
このオブジェクトは交渉できません。
Class = 20
o C-Type = 1, BEGIN_VERIFY_ERROR
o c-type = 1、BEGIN_VERIFY_ERROR
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 = Link_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.
Error Code 2を使用してBeginVerifyNackメッセージが受信された場合、BeginVerifyを発信したノードは、RFがローカルに定義されたパラメーターであるRF秒後にBeginVerifyの再送信をスケジュールすべきです (SHOULD)。
o C-Type = 2, LINK_SUMMARY_ERROR
o c-type = 2、LINK_SUMMARY_ERROR
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 =容認できない交渉不可能なLINK_SUMMARYパラメーター。0x02 =再交渉LINK_SUMMARYパラメーター。0x04 =無効なTE_LINKオブジェクト。0x08 =無効なDATA_LINKオブジェクト。0x10 =不明なTE_LINKオブジェクトCタイプ。0x20 =不明なDATA_LINKオブジェクト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., and L. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年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. and 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., and S. Molendini、「RSVP Refrend Overhead Recotion Extensions」、RFC 2961、2001年4月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402] Kent, S. and 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. and R. Atkinson、「IP Cankupsing Security Payload（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. and D. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC3471] Berger, L., Ed., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger, L., Ed.、「Generalized 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., and D. Yeung、「Traffic Engineering（TE）Extensions to OSPFバージョン2」、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. and T. Li、「トラフィックエンジニアリングの中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent, S. and 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. and 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., and G. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
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セキュリティは、認証、整合性、およびリプレイ保護を提供できなければなりません (MUST)。
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 認証に使用されるアルゴリズムは、暗号化的に健全でなければなりません (MUST)。また、セキュリティプロトコルは、異なる認証アルゴリズムの交渉と使用を許可しなければなりません (MUST)。
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.
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の実装は、マニュアルキーイングモードをサポートすべきです (SHOULD)。
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をサポートしなければなりません (MUST)。
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. 実装は、認証されたキー交換プロトコルをサポートしなければなりません (MUST)。キーがピア間で動的にネゴシエートされる場合、IKE [RFC2409]はキー交換プロトコルとして使用しなければなりません (MUST)。
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プロトコルの場合、クイックモードでネゴシエートされたSASのアイデンティティは、ピアが保護することに同意し、アドレス空間、プロトコル、およびポート情報で構成されているトラフィックを表しています。
For LMP over IPsec, it is recommended that the identity payload for Quick mode contain the following information:
IPSECを介したLMPの場合、クイックモードのIDペイロードには次の情報が含まれることをお勧めします。
The identities MUST be of type IP addresses and the value of the identities SHOULD be the IP addresses of the communicating peers.
IDはタイプIPアドレスでなければならず (MUST)、IDの値は通信ピアのIPアドレスであるべきです (SHOULD)。
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でなければなりません (MUST)。ポートフィールドは、ポートフィールドを無視することを示すためにゼロに設定すべきです (SHOULD)。これは、ピア間のすべてのUDPトラフィックをIPsecトンネル経由で送信する必要があることを意味します。実装がポートベースのセレクターをサポートする場合、ポートフィールドをLMPポートに指定することにより、より細かい粒度のセレクターを選択できます。ただし、ピアがポートベースのセレクターを使用しない場合、実装はポートセレクター値0を使用する方式にフォールバックしなければなりません (MUST)。
6. Aggressive mode of IKE negotiation MUST be supported.
6. IKE交渉の積極的なモードをサポートしなければなりません (MUST)。
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トンネル（Crypto Channel）を介して送信されると予想されます。同様に、ピアで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.
Cryptoチャネルは、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が制御チャネルのステータスを監視するために使用される場合、コントロールチャネルの維持障害は、暗号チャネルの障害によるものである可能性があることに留意することが重要です。2人のピア間の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 Helloを用いて制御チャネルの健全性を確認します。すべての制御チャネルが障害を示し、新しい制御チャネルを立ち上げることができない場合は、既存のすべての制御チャネルを切断します。また、暗号チャネル（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のメインモードでは、ピアのIDペイロードを受信する前に、使用する事前に共有されるキーを特定する必要があります。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.
デジタル署名ベースの認証は、そのような問題を起こしにくいものです。可能であれば、デジタル署名ベースの認証メカニズムを使用することが推奨されます (RECOMMENDED)。
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.
事前共有鍵ベースの認証が必要な場合は、アグレッシブモードを使用すべきです (SHOULD)。IKEの事前共有認証鍵の値は、ユーザーのアカウントパスワードと同様の方法で保護すべきです (SHOULD)。
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.
Expert Reviewによって割り当てられるLMP番号空間からの割り当ては、IESGによって指定された専門家によってレビューされます。本文書の意図は、これらの範囲のコードポイントを実験的拡張に使用することです。そのため、割り当てには実験的RFCを伴わなければなりません (MUST)。展開によってこれらの拡張が有用であることが示唆される場合、それらは標準化過程のRFCで記述されるべきであり、Standards Actionの範囲から新しいコードポイントを割り当てなければなりません (MUST)。
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番号スペースからの割り当ては、標準訴訟によって割り当てられるものは、通常はIETFワーキンググループに提出される標準トラックRFCによって文書化しなければなりません (MUST) が、いずれにせよ、提案された標準の通常の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
o Config message (Message type = 1)
o 構成メッセージ（メッセージタイプ= 1）
o ConfigAck message (Message type = 2)
o ConfigAckメッセージ（メッセージタイプ= 2）
o ConfigNack message (Message type = 3)
o メッセージメッセージ（メッセージタイプ= 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 LinkSummaryメッセージ（メッセージタイプ= 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 ChannelStatusメッセージ（メッセージタイプ= 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)
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)
o NODE_ID Class name (2)
o NODE_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)
o LINK_ID Class name (3)
o LINK_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.
LINK_IDオブジェクトクラスタイプ名のスペースは次のように割り当てる必要があります。[RFC2434]で概説されているポリシーに従って、0〜111の範囲の数値は標準訴訟によって割り当てられ、112-119は専門家のレビューを通じて割り当てられます。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)
o INTERFACE_ID Class name (4)
o INTERFACE_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.
INTERFACE_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)
o MESSAGE_ID Class name (5)
o MESSAGE_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.
MESSAGE_ID Objectクラスタイプ名容量は次のように割り当てる必要があります。[RFC2434]で概説されているポリシーに従って、0〜111の範囲の数値は標準訴訟によって割り当てられ、112-119は専門家レビューを通じて割り当てられます。127は私的使用のために予約されています。
- MESSAGE_ID (C-Type = 1)
- MESSAGE_ID_ACK (C-Type = 2)
o CONFIG Class name (6)
o config class名（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_CONFIG（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 Object classタイプの名前のスペースは次のように割り当てる必要があります。[RFC2434]で概説されているポリシーに従って、0〜111の範囲の数値は標準アクションによって割り当てられ、112-119は専門家のレビュー、および120-を通じて割り当てられます。127は私的使用のために予約されています。
- HELLO (C-Type = 1)
- こんにちは（c-type = 1）
o BEGIN_VERIFY Class name (8)
o BEGIN_VERIFYクラス名（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-type = 1）
o BEGIN_VERIFY_ACK Class name (9)
o BEGIN_VERIFY_ACKクラス名（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は専門家レビューを通じて割り当てられます。127は私的使用のために予約されています。
- Type 1 (C-Type = 1)
- タイプ1（c-type = 1）
o VERIFY_ID Class name (10)
o VERIFY_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.
検証_IDオブジェクトクラスタイプ名のスペースは次のように割り当てる必要があります。[RFC2434]で概説されているポリシーに従って、0〜111の範囲の数値は標準訴訟によって割り当てられ、112-119は専門家レビュー、および120-を通じて割り当てられます - 127は私的使用のために予約されています。
- Type 1 (C-Type = 1)
- タイプ1（c-type = 1）
o TE_LINK Class name (11)
o TE_LINKクラス名（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は専門家レビューを通じて割り当てられます。127は私的使用のために予約されています。
- IPv4 TE_LINK (C-Type = 1)
- IPv6 TE_LINK (C-Type = 2)
- Unnumbered TE_LINK (C-Type = 3)
o DATA_LINK Class name (12)
o DATA_LINKクラス名（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.
DATA_LINKオブジェクトクラスタイプ名容量は次のように割り当てる必要があります。[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)
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.
DATA_LINKサブオブジェクトクラス名のスペースは次のように割り当てる必要があります。[RFC2434]で概説されているポリシーに従って、0〜127の範囲の数字は標準訴訟によって割り当てられ、128-247は専門家のレビューを通じて割り当てられ、248-255は私的使用のために予約されています。
- Interface Switching Type (sub-object Type = 1)
- Wavelength (sub-object Type = 2)
o CHANNEL_STATUS Class name (13)
o CHANNEL_STATUSクラス名（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.
CHANNEL_STATUSオブジェクトクラスタイプ名容量は次のように割り当てる必要があります。[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)
o CHANNEL_STATUS_REQUESTClass name (14)
o CHANNEL_STATUS_REQUESTClass名（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.
CHANNEL_STATUS_REQUESTオブジェクトクラスタイプの名前スペースは次のように割り当てる必要があります。[RFC2434]で概説されているポリシーに従って、0〜111の範囲の数字は標準アクションによって割り当てられ、112-119は専門家レビューを通じて割り当てられます。127は私的使用のために予約されています。
- IPv4 INTERFACE_ID (C-Type = 1)
- IPv6 INTERFACE_ID (C-Type = 2)
- Unnumbered INTERFACE_ID (C-Type = 3)
o ERROR_CODE Class name (20)
o ERROR_CODEクラス名（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.
ERROR_CODEオブジェクトクラスタイプ名容量は次のように割り当てる必要があります。[RFC2434]で概説されているポリシーに従って、0〜111の範囲の数値は標準訴訟によって割り当てられ、112-119は専門家レビュー、および120-を通じて割り当てられます - 127は私的使用のために予約されています。
- BEGIN_VERIFY_ERROR (C-Type = 1)
- LINK_SUMMARY_ERROR (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の洞察に満ちたコメントと提案にも感謝します。また、インバンド制御チャネルの適用性に関する有益な提案について、ジョンユ、スレシュカトゥカム、グレッグバーンスタインに感謝します。
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101
Jonathan P. Lang Sonos、Inc。223 E. de la Guerra St. Santa Barbara、CA 93101
EMail: jplang@ieee.org
Krishna Mitra Independent Consultant
クリシュナミトラ独立コンサルタント
EMail: kmitra@earthlink.net
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
John Drake Calient Networks 5853 Rue Ferrari San Jose、CA 95138
EMail: jdrake@calient.net
Kireeti Kompella Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks、Inc。1194 North Mathilda Avenue Sunnyvale、CA 94089
EMail: kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
Yakov Rekhter Juniper Networks、Inc。1194 North Mathilda Avenue Sunnyvale、CA 94089
EMail: yakov@juniper.net
Lou Berger
Movaz Networks
EMail: lberger@movaz.com
Debanjan Saha IBM Watson Research Center
Debanjan Saha Ibm Watson Research Center
EMail: dsaha@us.ibm.com
Debashis Basak Accelight Networks 70 Abele Road, Suite 1201 Bridgeville, PA 15017-3470
Debashis Basak Accelight Networks 70 Abele Road、Suite 1201 Bridgeville、PA 15017-3470
EMail: dbasak@accelight.com
Hal Sandick Shepard M.S. 2401 Dakota Street Durham, NC 27705
ハル・サンディック・シェパードM.S.2401ダコタストリートダーラム、ノースカロライナ州27705
EMail: sandick@nc.rr.com
Alex Zinin Alcatel
アレックス・ジニン・アルカテル
EMail: alex.zinin@alcatel.com
Bala Rajagopalan Intel Corp. 2111 NE 25th Ave Hillsboro, OR 97123
Bala Rajagopalan Intel Corp. 2111 Ne 25th Ave Hillsboro、または97123
EMail: bala.rajagopalan@intel.com
Sankar Ramamoorthi Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
Sankar Ramamoorthi Juniper Networks、Inc。1194 North Mathilda Avenue Sunnyvale、CA 94089
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 De La Vina、Suite 220 Santa Barbara、CA 93101
EMail: jplang@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。