Network Working Group J. Lang, Ed.
Request for Comments: 4204 Sonos, Inc.
Category: Standards Track October 2005
Link Management Protocol (LMP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
For scalability purposes, multiple data links can be combined to form a single traffic engineering (TE) link. Furthermore, the management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links. Specifically, LMP will be used to maintain control channel connectivity, verify the physical connectivity of the data links, correlate the link property information, suppress downstream alarms, and localize link failures for protection/restoration purposes in multiple kinds of networks.
スケーラビリティのために、複数のデータリンクは、単一のトラフィックエンジニアリング（TE）リンクを形成するために組み合わせることができます。さらに、TEリンクの管理はインバンドメッセージングに限定されるものではなく、代わりにアウトオブバンド技術を用いて行うことができます。この文書は、ノードの対の間に実行され、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.
ネットワークは、動的にリソースを割り当てることと提供するために、例えば、汎用MPLS（GMPLS）、ルータ、スイッチ、相互接続、高密度波長分割多重（DWDM）システム、及び共通の制御プレーンを使用するアドインドロップマルチプレクサ（ADM装置）を用いて開発されています保護および復元技術を使用して、ネットワークの存続。ノードのペアが各相互接続は、複数のデータリンクから構成することができる配線の数千を有することができるときに多重化（例えば、フレームリレーのDLCIレイヤ2で、レイヤー1における時分割多重（TDM）スロットまたは波長分割多重（WDM）波長）使用されている。スケーラビリティのために、複数のデータリンクは、単一のトラフィックエンジニアリング（TE）リンクに結合されてもよいです。
To enable communication between nodes for routing, signaling, and link management, there must be a pair of IP interfaces that are mutually reachable. We call such a pair of interfaces a control channel. Note that "mutually reachable" does not imply that these two interfaces are (directly) connected by an IP link; there may be an IP network between the two. Furthermore, the interface over which the control messages are sent/received may not be the same interface over which the data flows. This document specifies a link management protocol (LMP) that runs between a pair of nodes and is used to manage TE links and verify reachability of the control channel. For the purposes of this document, such nodes are considered "LMP neighbors" or simply "neighboring nodes".
ルーティング、シグナリング、およびリンク管理のためのノード間の通信を可能にするために、互いに到達可能なIPインタフェースのペアが存在しなければなりません。我々は、制御チャネルインターフェイスのようなペアを呼び出します。 「互いに到達可能な」は、これらの二つのインタフェースが（直接）IPリンクによって接続されていることを意味しないことに留意されたいです。 2間のIPネットワークがあるかもしれません。また、受信した制御メッセージを送信する上インターフェースは/データが流れるにわたって同じインターフェイスではないかもしれません。この文書は、ノードの対の間に実行され、TEリンクを管理し、制御チャネルの到達可能性を検証するために使用されるリンク管理プロトコル（LMP）を指定します。このドキュメントの目的のために、そのようなノードは「LMP隣人」または単に「隣接ノード」と見なされます。
In GMPLS, the control channels between two adjacent nodes are no longer required to use the same physical medium as the data links between those nodes. For example, a control channel could use a separate virtual circuit, wavelength, fiber, Ethernet link, an IP tunnel routed over a separate management network, or a multi-hop IP network. A consequence of allowing the control channel(s) between two nodes to be logically or physically diverse from the associated data links is that the health of a control channel does not necessarily correlate to the health of the data links, and vice-versa. Therefore, a clean separation between the fate of the control channel and data links must be made. New mechanisms must be developed to manage the data links, both in terms of link provisioning and fault management.
GMPLSでは、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はTEリンクへのリンクをグループ化しただけでなく、それらのリンクの性質は、リンクの両端点で同じであることを確認して達成したタスクの中で - これは、「リンクプロパティ相関」と呼ばれています。また、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.
制御ネットワーク（シングルまたはマルチホップ）の存在は、通信を可能にする必要があるが、それは決して十分ではないことに留意されたいです。二つのインタフェースが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).
本文書の目的のために、データ・リンクは、そのリンク上のエンドポイントの多重化能力に応じて、それが「ポート」または「コンポーネントリンク」のいずれかのように終了する各ノードによって考慮されてもよいです。ポートが可能な多重化されていないのに対し、コンポーネントリンクは、可能な多重化されています。 （例えば、リソース割り当て、ラベルの割り当て、およびそれらの物理的検証を含む）このようなリンクの管理は、それらの多重化能力に基づいて異なるため、この区別は重要です。例えば、フレームリレースイッチのDLCIに基づいて、仮想回路にインターフェイスを分離することが可能です。同様に、OC-192インターフェースを備えたSONET相互接続は、4つのOC-48ストリームにOC-192のストリームを逆多重化することができるかもしれません。リソース割り当てがで行わ等仮想回線、タイムスロットを識別LINK_ID、コンポーネント・インタフェースID、およびラベル：複数のインターフェイスは[RFC4201]を束ねるリンクを使用して単一のTEリンクに一緒にグループ化されている場合は、リンク・リソースの3つのレベルを使用して識別されなければなりません最低レベル（ラベル）が、物理的な接続は、コンポーネント、リンクレベルで起こります。別の例として、光スイッチ（例えば、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-可能なデバイスは、コンポーネントリンクのサブチャネルが局所的（論理的）データリンクとして構成することが可能にすべきです。例えば、4 OC-48インターフェイスとルータ4を介して接続されている場合：クロスコネクトOC-192インターフェイスと、各サブチャネルを構成することができなければならないクロスコネクト（例えばSTS-48Cに1 MUX SPEは4場合：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は（TEリンクにTEリンクへのポート、またはコンポーネントリンクのいずれか）TEリンクへの1つまたは複数のデータリンクの集約をサポートするように設計されています。 TEリンクを形成する目的は、グループに/経路計算の目的のために、およびGMPLSシグナリングによって制約SPFによって使用される情報の中に特定の物理的リソース（およびその特性）に関する情報をマップです。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The reader is assumed to be familiar with the terminology in [RFC3471], [RFC4202], and [RFC4201].
読者は、[RFC3471]、[RFC4202]及び[RFC4201]における用語に精通していると仮定されます。
Bundled Link:
バンドルリンク：
As defined in [RFC4201], a bundled link is a TE link such that, for the purpose of GMPLS signaling, a combination of <link identifier, label> is not sufficient to unambiguously identify the appropriate resources used by an LSP. A bundled link is composed of two or more component links.
[RFC4201]で定義されるように、バンドルリンクは、GMPLSシグナリングの組み合わせのために<リンクID、ラベル>は明白LSPによって使用される適切なリソースを識別するのに十分ではない、ようにTEリンクです。バンドルされたリンクは、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]で定義されるように、コンポーネントリンクは、TEリンクのリソースのサブセットであるように、（a）は、パーティションは最小限であり、（b）は各サブセット内のラベルは明確LSPによって使用される適切なリソースを識別するのに十分です。
Data Link:
データリンク：
A data link is a pair of interfaces that are used to transfer user data. Note that in GMPLS, the control channel(s) between two adjacent nodes are no longer required to use the same physical medium as the data links between those nodes.
データリンクは、ユーザデータを転送するために使用されるインターフェイスのペアです。 GMPLSに、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リンクをグループ化する方法を表す論理構成体である/特定の物理リソース（およびその特性）に関する情報をマッピングすること、相互接続LSRのパスのために制約SPFによって使用される情報に計算、およびGMPLSシグナリングによって。
Transparent:
トランスペアレント：
A device is called X-transparent if it forwards incoming signals from input to output without examining or modifying the X aspect of the signal. For example, a Frame Relay switch is network-layer transparent; an all-optical switch is electrically transparent.
それは検査や信号のX局面を変更することなく、入力から出力への着信信号を転送する場合、デバイスは、X透明と呼ばれています。例えば、フレームリレースイッチは、透明なネットワーク層です。全光スイッチは、電気的に透明です。
The two core procedures of LMP are control channel management and link property correlation. Control channel management is used to establish and maintain control channels between adjacent nodes. This is done using a Config message exchange and a fast keep-alive mechanism between the nodes. The latter is required if lower-level mechanisms are not available to detect control channel failures. Link property correlation is used to synchronize the TE link properties and verify the TE link configuration.
LMPの2つのコア手順は、制御チャネル管理及びリンク特性の相関関係です。制御チャネル管理は、隣接ノード間の制御チャネルを確立し、維持するために使用されます。これは、Configメッセージ交換とノード間の高速キープアライブメカニズムを使用して行われます。下位レベルのメカニズムが制御チャネルの障害を検出するために利用できない場合は後者が必要とされます。リンクプロパティ相関が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）によって識別され、2つの方向は、LMP Configメッセージ交換を使用して一緒に結合されています。帯域内のメッセージングのためのトランスポート・メカニズムによって制限されることがテストメッセージを除き、すべてのLMPパケットはLMPポート番号とUDP上で実行されます。制御チャネルのリンクレベル符号化は、この文書の範囲外です。
An "LMP adjacency" is formed between two nodes when at least one bi-directional control channel is established between them. Multiple control channels may be active simultaneously for each adjacency; control channel parameters, however, MUST be individually negotiated for each control channel. If the LMP fast keep-alive is used over a control channel, LMP Hello messages MUST be exchanged over the control channel. Other LMP messages MAY be transmitted over any of the active control channels between a pair of adjacent nodes. One or more active control channels may be grouped into a logical control channel for signaling, routing, and link property correlation purposes.
少なくとも一つの双方向制御チャネルは、それらの間で確立される場合、「LMP隣接」とは、2つのノード間に形成されます。複数の制御チャネルは、各隣接同時にアクティブであってもよいです。制御チャネルパラメータは、しかし、個々の制御チャネルのために交渉しなければなりません。 LMP速いキープアライブは、制御チャネルを介して使用されている場合は、LMP Helloメッセージは、制御チャネルを介して交換されなければなりません。他のLMPメッセージは、隣接ノードの対の間のアクティブ制御チャネルのいずれかを介して送信することができます。一つ以上のアクティブ制御チャネルは、シグナリング、ルーティング、リンク特性の相関のために論理制御チャネルにグループ化することができます。
The link property correlation function of LMP is designed to aggregate multiple data links (ports or component links) into a TE link and to synchronize the properties of the TE link. As part of the link property correlation function, a LinkSummary message exchange is defined. The LinkSummary message includes the local and remote Link_Ids, a list of all data links that comprise the TE link, and various link properties. A LinkSummaryAck or LinkSummaryNack message MUST be sent in response to the receipt of a LinkSummary message indicating agreement or disagreement on the link properties.
LMPのリンクプロパティ相関関数は、TEリンクに複数のデータリンク（ポートまたはコンポーネントリンク）を集約して、TEリンクのプロパティを同期させるように設計されています。リンクプロパティ相関関数の一部として、LinkSummaryメッセージ交換が定義されます。 LinkSummaryメッセージは、ローカルおよびリモートLink_Ids、TEリンクを含むすべてのデータ・リンクのリスト、および様々なリンク特性を含みます。 LinkSummaryAckまたはLinkSummaryNackメッセージは、リンク特性に一致又は不一致を示すLinkSummaryメッセージの受信に応答して送信されなければなりません。
LMP messages are transmitted reliably using Message_Ids and retransmissions. Message_Ids are carried in MESSAGE_ID objects. No more than one MESSAGE_ID object may be included in an LMP message. For control-channel-specific messages, the Message_Id is within the scope of the control channel over which the message is sent. For TE-link-specific messages, the Message_Id is within the scope of the LMP adjacency. The value of the Message_Id is monotonically increasing and wraps when the maximum value is reached.
LMPメッセージがMessage_Idsおよび再送信を使用して確実に伝達されています。 Message_IdsはMESSAGE_IDオブジェクトに運ばれます。いいえつ以上のMESSAGE_IDオブジェクトがLMPメッセージに含まなくてもよいです。制御チャネル固有のメッセージの場合、MESSAGE_IDは、メッセージが送信される制御チャネルの範囲内です。 TE-リンク固有のメッセージについて、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.
この文書では、二つの追加LMP手順が定義されています。リンクの接続性検証や障害管理。制御チャネルがデータリンクから物理的に多様である場合、これらの手順は、特に有用です。リンク接続性検証は、データプレーンの発見、Interface_Id交換（Interface_Idsは、構成に応じて、いずれかのポートラベルまたはコンポーネントリンク識別子として、GMPLSシグナリングに使用されている）、および物理的な接続性検証のために使用されます。これは、バック制御チャネルを介してデータリンクとTestStatusメッセージの上にテストメッセージを送信することにより行われます。テストメッセージは、データリンクを介して送信されなければならない唯一のLMPメッセージであることに留意されたいです。チャネルステータスメッセージ交換は、下流のアラームの抑制及び保護および回復のための障害の局在化の両方のための隣接ノード間で使用されています。
For LMP link connectivity verification, the Test message is transmitted over the data links. For X-transparent devices, this requires examining and modifying the X aspect of the signal. The LMP link connectivity verification procedure is coordinated using a BeginVerify message exchange over a control channel. To support various aspects of transparency, a Verify Transport Mechanism is included in the BeginVerify and BeginVerifyAck messages. Note that there is no requirement that all data links must lose their transparency simultaneously; but, at a minimum, it must be possible to terminate them one at a time. There is also no requirement that the control channel and TE link use the same physical medium; however, the control channel MUST be terminated by the same two control elements that control the TE link. Since the BeginVerify message exchange coordinates the Test procedure, it also naturally coordinates the transition of the data links in and out of the transparent mode.
LMPリンク接続性検証のために、テストメッセージは、データリンクを介して送信されます。 X透明デバイスの場合、これは信号のX局面を調べ、変更が必要です。 LMPリンク接続検証手順は、制御チャネルを介しBeginVerifyメッセージ交換を使用して調整されます。透明性のさまざまな側面をサポートするために、トランスポートメカニズムがBeginVerifyとBeginVerifyAckメッセージに含まれていることを確認します。すべてのデータリンクが同時にその透明性を失わなければならないという要件が存在しないことに注意してください。しかし、最低でも、1度に1つずつを終了させることが可能でなければなりません。制御チャネルとTEリンクが同じ物理媒体を使用するという要件もありません。しかし、制御チャネルは、TEリンクを制御する同じ2つの制御要素によって終了されなければなりません。 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.
チャネルステータス、ChannelStatusAck、ChannelStatusRequest、およびChannelStatusResponse：LMP障害管理手順は、次のメッセージを使用してチャネルステータスメッセージ交換に基づいています。チャネルステータスメッセージが迷惑送信され、TEリンクの一個の以上のデータ・チャネルの状態についてLMP隣人に通知するのに使用されます。 ChannelStatusAckメッセージはチャネルステータスメッセージの受信を確認するために使用されます。 ChannelStatusRequestメッセージはTEリンクの一個の以上のデータ・チャネルの状態について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]).
2つのノード間のLMP隣接を開始するために、一つ以上の双方向制御チャネルが活性化されなければなりません。制御チャネルは、リンクのプロビジョニングと、パス管理とラベル配布情報（本文書で提案されているようなLMPなどのメッセージングプロトコルを使用して実装）障害管理情報として、コントロールプレーンの情報を交換するために使用することができる（例えば、シグナリングプロトコルを使用して実装RSVP-TE [RFC3209]）、およびOSPFなどのプロトコルのトラフィックエンジニアリングの拡張を使用して実装さネットワークトポロジと状態分布情報（[RFC3630]及び[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アドレスを知らなければなりません。この知識は、手動で設定するか、自動的に検出することができます。帯域内シグナリングのために、制御チャネルは、明示的に特定のデータリンク上で構成することができることに留意されたいです。この場合、Configメッセージ交換を動的に制御チャネルの遠端上のIPアドレスを学習するために使用することができます。これは、ユニキャストIP送信元アドレスと、マルチキャストIP宛先アドレス（224.0.0.1またはFF02 :: 1）でConfigメッセージを送信することによって行われます。 ConfigAckとConfigNackメッセージが受信されたConfigメッセージのIPヘッダで見つかったソースIPアドレスに送信されなければなりません。
Control channels exist independently of TE links and multiple control channels may be active simultaneously between a pair of nodes. Individual control channels can be realized in different ways; one might be implemented in-fiber while another one may be implemented out-of-fiber. As such, control channel parameters MUST be negotiated over each individual control channel, and LMP Hello packets MUST be exchanged over each control channel to maintain LMP connectivity if other mechanisms are not available. Since control channels are electrically terminated at each node, it may be possible to detect control channel failures using lower layers (e.g., SONET/SDH).
制御チャネルは独立TEリンクの存在と複数の制御チャネルは、ノードの対の間で同時にアクティブであってもよいです。個別制御チャネルは、様々な方法で実現することができます。もう一つはアウトオブファイバ実装されてもよい一つにファイバ実装されるかもしれません。このように、制御チャネルパラメータは、個々の制御チャネル上でネゴシエートされなければならない、とLMP Helloパケットは、他のメカニズムが利用できない場合LMP接続性を維持するために、各制御チャネルを介して交換されなければなりません。制御チャネルが電気各ノードで終端されるので、下位層（例えば、SONET / SDH）を用いて、制御チャネルの障害を検出することが可能であってもよいです。
There are four LMP messages that are used to manage individual control channels. They are the Config, ConfigAck, ConfigNack, and Hello messages. These messages MUST be transmitted on the channel to which they refer. All other LMP messages may be transmitted over any of the active control channels between a pair of LMP adjacent nodes.
個別制御チャネルを管理するために使用される4件のLMPメッセージがあります。彼らは、コンフィグレーション、ConfigAck、ConfigNack、およびHelloメッセージです。これらのメッセージは、それらが参照先のチャネルで送信されなければなりません。他のすべてのLMPメッセージは、LMP隣接ノードの対の間のアクティブ制御チャネルのいずれかを介して送信されてもよいです。
In order to maintain an LMP adjacency, it is necessary to have at least one active control channel between a pair of adjacent nodes (recall that multiple control channels can be active simultaneously between a pair of nodes). In the event of a control channel failure, alternate active control channels can be used and it may be possible to activate additional control channels as described below.
LMP隣接関係を維持するために、隣接するノード（複数の制御チャネルは、ノードの対の間で同時にアクティブにすることができることを想起されたい）の対の間に少なくとも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、およびConfigNackメッセージを使用してパラメータネゴシエーション交換から始まります。これらのメッセージの内容は、（オブジェクトヘッダーのNビットによって識別される）交渉または非交渉のいずれかであることができるLMPオブジェクトを使用して構築されています。応相談オブジェクトは、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.
制御チャネルを活性化するために、構成メッセージは、リモート・ノードに送信されなければならない、それに応答して、ConfigAckメッセージがローカルノードで受信されなければなりません。 Configメッセージは、ローカル制御チャネルID（CC_ID）、送信者のNODE_ID、信頼性の高いメッセージングのためのMESSAGE_ID、およびCONFIGオブジェクトが含まれています。ローカルとリモートの両方のノードが同時に設定手順を開始することが可能です。あいまいさを避けるために、高いNODE_IDを持つノードが競合に勝ちました。下部NODE_ID有するノードは、Configメッセージの送信を停止し、受信した構成メッセージに応答しなければなりません。 Node_Idsが等しい場合、1つ（または両方）のノードが誤って設定されています。ノードは、設定ミスが修正されて期待してコンフィグメッセージを再送し続けることができます。問題は、1つのまたは両方のノードでNode_Idsを変えるオペレータによって解決されてもよいことに留意されたいです。
The ConfigAck message is used to acknowledge receipt of the Config message and express agreement on ALL of the configured parameters (both negotiable and non-negotiable).
ConfigAckメッセージは、Configメッセージの受信を確認し、（交渉および非交渉の両方）構成パラメータの全ての合意を発現するために使用されます。
The ConfigNack message is used to acknowledge receipt of the Config message, indicate which (if any) non-negotiable CONFIG objects are unacceptable, and to propose alternate values for the negotiable parameters.
ConfigNackメッセージは、Configメッセージの受信を確認するために使用される非交渉CONFIGオブジェクト許容できない、と交渉パラメータの代替値を提案する（もしあれば）どのを示します。
If a node receives a ConfigNack message with acceptable alternate values for negotiable parameters, the node SHOULD transmit a Config message using these values for those parameters.
ノードは交渉パラメータの許容される代替値とConfigNackメッセージを受信した場合、ノードは、これらのパラメータのためにこれらの値を使用して、構成メッセージを送信しなければなりません。
If a node receives a ConfigNack message with unacceptable alternate values, the node MAY continue to retransmit Config messages in hopes that the misconfiguration is corrected. Note that the problem may be solved by an operator changing parameters on one or both nodes.
ノードは容認できない代替値を持つConfigNackメッセージを受信した場合、ノードは、構成の誤りが修正されることを期待してコンフィグメッセージを再送し続けることができます。問題は、1つのまたは両方のノード上のパラメータを変更するオペレータによって解決されてもよいことに留意されたいです。
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ハロープロトコルは、ノード間の制御チャネルの接続性を維持するために、制御チャネルの障害を検出するために使用することができます。 LMPこんにちはプロトコルはIGPハローズが失われていないと、関連するリンクステート隣接が不必要に除去されないように急速にチャネルの障害を制御するために反応する軽量キープアライブメカニズムであることを意図しています。
Before sending Hello messages, the HelloInterval and HelloDeadInterval parameters MUST be agreed upon by the local and remote nodes. These parameters are exchanged in the Config message. The HelloInterval indicates how frequently LMP Hello messages will be sent, and is measured in milliseconds (ms). For example, if the value were 150, then the transmitting node would send the Hello message at least every 150 ms. The HelloDeadInterval indicates how long a device should wait to receive a Hello message before declaring a control channel dead, and is measured in milliseconds (ms).
helloメッセージを送信する前に、HelloIntervalのとHelloDeadIntervalのパラメータは、ローカルおよびリモートノードによって合意されなければなりません。これらのパラメータは、Configメッセージで交換されています。 HelloIntervalとは、LMP Helloメッセージが送信され、ミリ秒（ms）で測定された頻度を示します。値が150であった場合、例えば、次に送信ノードは、Helloメッセージは、少なくとも150ミリ秒毎に送信することになります。 HelloDeadIntervalのは、デバイスが制御チャネル死者を宣言する前にHelloメッセージを受信するために待機する時間を示しており、ミリ秒（ms）で測定されます。
The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval. If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval parameters MUST be set to zero.
HelloDeadIntervalのはHelloIntervalのより大きくなければならない、とHelloIntervalの少なくとも3倍の値であるべきです。 LMPの速いキープアライブメカニズムが使用されていない場合は、HelloIntervalのとHelloDeadIntervalのパラメータをゼロに設定しなければなりません。
The values for the HelloInterval and HelloDeadInterval should be selected carefully to provide rapid response time to control channel failures without causing congestion. As such, different values will likely be configured for different control channel implementations. When the control channel is implemented over a directly connected link, the suggested default values for the HelloInterval is 150 ms and for the HelloDeadInterval is 500 ms.
HelloIntervalが後援とHelloDeadIntervalのための値は、輻輳を引き起こすことなく、チャネル障害を制御するために迅速な応答時間を提供するように注意深く選択されるべきです。このように、異なる値がおそらく異なる制御チャネルの実装のために設定されます。制御チャネルが直接接続されたリンクを介して実装されている場合、HelloIntervalのための提案されたデフォルト値は150ミリ秒であり、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を参照）。 （他の方法が、双方向制御チャネルの接続性を示すために使用される場合helloを送信せずにアップ状態に移行することも可能である。例えば、双方向接続性の指示は、トランスポート層から学習することができる。）場合には、しかしながら、 、ノードはConfigAckメッセージの代わりにConfigNackメッセージを受信すると、ノードはHelloメッセージを送ってはいけませんし、制御チャネルがアップ状態に動かないようにしてください。完全な制御チャネル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.
各ハローメッセージは、次の2つのシーケンス番号を含んでいる：最初のシーケンス番号（TxSeqNum）がこのコントロール上の隣接ノードから受信した最後のHelloメッセージのシーケンス番号送信されるHelloメッセージのシーケンス番号と第二シーケンス番号（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.
二つの特別なシーケンス番号があります。 TxSeqNumは今まで= 1 0 TxSeqNumは、送信者が開始されたばかりか、再起動しており、送信された最後のTxSeqNumのない思い出を持っていないことを示すために使用されてはなりません。したがって、最初のハローは、これらが特別な意味を持つように1のTxSeqNumと0のRxSeqNum TxSeqNumに到達有する（2 ^ 32）-1、使用される次のシーケンス番号は、ではなく0又は1 2で送りました。
Under normal operation, the difference between the RcvSeqNum in a Hello message that is received and the local TxSeqNum that is generated will be at most 1. This difference can be more than one only when a control channel restarts or when the values wrap.
通常の動作では、受信されたHelloメッセージにRcvSeqNum差され、生成されたローカルTxSeqNumはせいぜい1この違いは、複数の制御チャネルのみが再起動または値がラップをすることができます。
Since the 32-bit sequence numbers may wrap, the following expression may be used to test if a newly received TxSeqNum value is less than a previously received value:
32ビットのシーケンス番号がラップすることがあるので、次式が新たに受信TxSeqNum値が以前に受信された値未満であるかどうかをテストするために使用することができます。
If ((int) old_id - (int) new_id > 0) { New value is less than old value; }
もし（（int型）old_id - （INT）NEW_ID> 0）{新しい値が古い値よりも小さいです。 }
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メッセージを受信していることを確認することを可能にします。 Helloパケット内RcvSeqNumを含めることにより、ローカル・ノードは、こんにちは、リモート・ノードが受信したパケットかを知るでしょう。
The following example illustrates how the sequence numbers operate. Note that only the operation at one node is shown, and alternative scenarios are possible:
次の例では、シーケンス番号がどのように動作するかを示します。一方のノードでのみ動作が示されていることに注意してください、そして別のシナリオが可能です。
1) After completing the configuration stage, Node A sends Hello messages to Node B with {TxSeqNum=1;RcvSeqNum=0}.
1）コンフィギュレーション・ステージを完了した後、ノードAは、{; RcvSeqNum = 0 TxSeqNum = 1}とノードBにHelloメッセージを送信します。
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は、{; RcvSeqNum = 1 TxSeqNum = 1}と、ノードBからのHelloを受信します。 HelloIntervalとは、ノードAに期限切れになると、それが持つノードBにhelloを送信{TxSeqNum = 2; RcvSeqNum = 1}。
3) Node A receives a Hello from Node B with {TxSeqNum=2;RcvSeqNum=2}. When the HelloInterval expires on Node A, it sends Hellos to Node B with {TxSeqNum=3;RcvSeqNum=2}.
3）ノードAは、{; RcvSeqNum = 2 TxSeqNum = 2}と、ノードBからのHelloを受信します。 HelloIntervalとは、ノードAに期限切れになると、それが持つノードBにhelloを送信{TxSeqNum = 3; RcvSeqNum = 2}。
To allow bringing a control channel down gracefully for administration purposes, a ControlChannelDown flag is available in the Common Header of LMP packets. When data links are still in use between a pair of nodes, a control channel SHOULD only be taken down administratively when there are other active control channels that can be used to manage the data links.
投与のために正常に下り制御チャネルをもたらす可能にするために、ControlChannelDownフラグは、LMPパケットの共通ヘッダで利用可能です。データリンクは、ノードの対の間まだ使用中であるときにデータリンクを管理するために使用することができる他のアクティブ制御チャネルがある場合、制御チャネルは、管理上のダウン取られるべきです。
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フラグを設定しなければなりません。手順を制御チャネルをダウン開始したノードは、それがControlChannelDownフラグを設定して、同一の制御チャネルを介してLMPメッセージを受信した場合HelloDeadIntervalの秒が経過し、またはした後のHelloメッセージの送信を停止することがあります。
When a node receives an LMP packet with the ControlChannelDown flag set, it SHOULD send a Hello message with the ControlChannelDown flag set and move the control channel to the down state.
ノードはControlChannelDownフラグがセットされたLMPパケットを受信すると、ControlChannelDownフラグが設定されたHelloメッセージを送信し、ダウン状態に制御チャネルを移動する必要があります。
A consequence of allowing the control channels to be physically diverse from the associated data links is that there may not be any active control channels available while the data links are still in use. For many applications, it is unacceptable to tear down a link that is carrying user traffic simply because the control channel is no longer available; however, the traffic that is using the data links may no longer be guaranteed the same level of service. Hence, the TE link is in a Degraded state.
制御チャネルは、関連するデータリンクから物理的に多様化されることを可能にするの結果は、データリンクがまだ使用中である間、任意のアクティブ制御チャネルが利用可能ではないかもしれないということです。多くのアプリケーションでは、制御チャネルが使用できなくなったという理由だけで、ユーザトラフィックを伝送しているリンクを切断することは受け入れられません。しかし、データリンクを使用しているトラフィックは、もはや同じレベルのサービスを保証することはできません。従って、TEリンクが劣化状態にあります。
When a TE link is in the Degraded state, routing and signaling SHOULD be notified so that new connections are not accepted and the TE link is advertised with no unreserved resources.
TEリンクが劣化状態にあるときに新しい接続を受け付けられませんし、TEリンクが無い予約されていないリソースで宣伝されるように、ルーティングおよびシグナリングを通知する必要があります。
As part of LMP, a link property correlation exchange is defined for TE links using the LinkSummary, LinkSummaryAck, and LinkSummaryNack messages. The contents of these messages are built using LMP objects, which can be either negotiable or non-negotiable (identified by the N flag in the object header). Negotiable objects can be used to let both sides agree on certain link parameters. Non-negotiable objects are used for announcement of specific values that do not need, or do not allow, negotiation.
LMPの一環として、リンクプロパティ相関交換がLinkSummary、LinkSummaryAck、およびLinkSummaryNackメッセージを使用して、TEリンクのために定義されています。これらのメッセージの内容は、（オブジェクトヘッダーのNフラグによって識別される）交渉または非交渉のいずれかであり得るLMPオブジェクトを使用して構築されています。応相談オブジェクトは、両側が特定のリンクパラメータに同意させるために使用することができます。非交渉のオブジェクトは、交渉を必要としない、または許可されていない特定の値の発表のために使用されています。
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の、番号なし）でなければなりません。 LinkSummaryメッセージは異なるローカルおよびリモートTEリンクタイプで受信された場合には、LinkSummaryNackメッセージは、エラーコード「悪いTEリンクオブジェクト」を送らなければなりません。同様に、各データリンクは、各端部に識別子（Interface_Id）が割り当てられます。これらの識別子はまた、両端で同じタイプでなければなりません。 LinkSummaryメッセージは異なるローカルとリモートのInterface_Idタイプで受信された場合には、LinkSummaryNackメッセージは、エラーコード「不良データリンクオブジェクト」を送らなければなりません。
Link property correlation SHOULD be done before the link is brought up and MAY be done any time a link is up and not in the Verification process.
リンクが育っていると、リンクがアップしていない検証プロセスであり、いつでも行うことができる前に、リンクプロパティ相関が行われるべきです。
The LinkSummary message is used to verify for consistency the TE and data link information on both sides. Link Summary messages are also used (1) to aggregate multiple data links (either ports or component links) into a TE link; (2) to exchange, correlate (to determine inconsistencies), or change TE link parameters; and (3) to exchange, correlate (to determine inconsistencies), or change Interface_Ids (either Port_Ids or component link identifiers).
LinkSummaryメッセージは、一貫性のために両側TEとデータリンク情報を検証するために使用されます。リンクの概要メッセージは、（1）TEリンクに複数のデータリンク（ポートまたはコンポーネントリンクのいずれか）を集約するために使用されます。 （2）、交換機（不整合を決定するために）相関、あるいはTEリンクパラメータを変更します。 （3）、交換機（不整合を決定するために）相関、又はInterface_Ids（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メッセージは、一つ以上のDATA_LINKオブジェクト続いTE_LINKオブジェクトを含みます。 TE_LINKオブジェクトは、TEリンクのローカルおよびリモートLINK_IDを識別し、そのTEリンクの障害管理とリンク検証手続きのサポートを示します。 DATA_LINKオブジェクトは、TEリンクを構成するデータリンクを特徴付けるために使用されています。これらのオブジェクトは、ローカルおよびリモートInterface_Idsを含み、さらに、データリンクの特性を記述する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メッセージは、インタフェースマッピングが正しくない、および/またはどのリンクプロパティが受け入れられないかを示す、送信されなければなりません。 LinkSummaryNackメッセージはInterface_Idマッピングが正しくないと、リンク検証手順が有効になっている、リンク検証プロセスは、すべての不一致、無料のデータリンクのために繰り返されるべきであることを示している場合。割り当てられたデータリンクはマッピングの不一致がある場合、それはフラグが付けられ、それが自由になったときに確認する必要があります。 LinkSummaryNackメッセージは交渉パラメータを含む場合、それらのパラメータの許容値を含まなければなりません。 LinkSummaryNackメッセージが受信され、交渉パラメータが含まれている場合、LinkSummaryメッセージのイニシエータは新しいLinkSummaryメッセージを送信すべきです。新しいLinkSummaryメッセージは交渉のパラメータの新しい値を含むべきです。これらの値は、アカウントにLinkSummaryNackメッセージで受信した許容値を取る必要があります。
It is possible that the LinkSummary message could grow quite large due to the number of DATA LINK objects. An LMP implementation SHOULD be able to fragment when transmitting LMP messages, and MUST be able to re-assemble IP fragments when receiving LMP messages.
LinkSummaryメッセージが原因データリンクオブジェクトの数に非常に大きくなる可能性があります。 LMPの実装では、LMPメッセージを送信する際に断片化することができるべきであり、LMPメッセージを受信したときにIPフラグメントを再アセンブルすることができなければなりません。
In this section, an optional procedure is described that may be used to verify the physical connectivity of the data links and dynamically learn (i.e., discover) the TE link and Interface_Id associations. The procedure SHOULD be done when establishing a TE link, and subsequently, on a periodic basis for all unallocated (free) data links of the TE link.
このセクションでは、オプションの手順は、データリンクの物理的な接続を確認し、動的に学習するために使用することができることが記載されている（すなわち、検出）TEリンクとInterface_Idアソシエーション。手順は、TEリンクのすべての未割り当て（無料）データリンクのため定期的に、その後、TEリンクを確立するときに行われなければならず。
Support for this procedure is indicated by setting the "Link Verification Supported" flag in the TE_LINK object of the LinkSummary message.
この手順のサポートは、LinkSummaryメッセージのTE_LINKオブジェクトに「リンクの検証サポートされている」フラグを設定することによって示されます。
If a BeginVerify message is received and link verification is not supported for the TE link, then a BeginVerifyNack message MUST be transmitted with Error Code indicating, "Link Verification Procedure not supported for this TE Link."
BeginVerifyメッセージが受信され、リンク検証がTEリンクにサポートされていない、そしてBeginVerifyNackメッセージが示すエラーコードを送信しなければならない場合は、「リンク検証プロシージャは、このTEリンクのためにサポートされていません。」
A unique characteristic of transparent devices is that the data is not modified or examined during normal operation. This characteristic poses a challenge for validating the connectivity of the data links and establishing the label mappings. Therefore, to ensure proper verification of data link connectivity, it is required that, until the data links are allocated for user traffic, they must be opaque (i.e., lose their transparency). To support various degrees of opaqueness (e.g., examining overhead bytes, terminating the IP payload, etc.) and, hence, different mechanisms to transport the Test messages, a Verify Transport Mechanism field is included in the BeginVerify and BeginVerifyAck messages.
透明デバイスのユニークな特徴は、データが変更または通常の操作中に検査されないことです。この特性は、データリンクの接続性を検証し、ラベルマッピングを確立するための課題を提起します。そのため、データリンク接続の適切な検証を確実にするために、（すなわち、その透明性を失う）データリンクがユーザトラフィックのために割り当てられるまで、彼らは不透明でなければならない、ということが必要です。不透明の様々な程度、従って、異なるメカニズムがテストメッセージを転送するために、（例えば、オーバーヘッドバイトを検査するIPペイロードを終了、等）とをサポートするために、確認搬送機構フィールドはBeginVerifyとBeginVerifyAckメッセージに含まれています。
There is no requirement that all data links be terminated simultaneously; but, at a minimum, the data links MUST be able to be terminated one at a time. Furthermore, for the link verification procedure it is assumed that the nodal architecture is designed so that messages can be sent and received over any data link. Note that this requirement is trivial for opaque devices since each data link is electrically terminated and processed before being forwarded to the next opaque device; but that in transparent devices this is an additional requirement.
すべてのデータリンクが同時に終了する必要はありません。しかし、最低でも、データリンクは、一度に1つを終了させることができなければなりません。また、リンク検証手順のためには、メッセージは、任意のデータ・リンクを介して送信及び受信できるようにノードアーキテクチャが設計されているものとします。各データリンクは、電気的に終了し、次の不透明なデバイスに転送される前に処理されるため、この要件は、不透明なデバイスのために自明であることに留意されたいです。それは透明のデバイスでは、これは追加的な要件です。
To interconnect two nodes, a TE link is defined between them, and at a minimum, there MUST be at least one active control channel between the nodes. For link verification, a TE link MUST include at least one data link.
二つのノードを相互接続するために、TEリンクがそれらの間に定義され、最小で、ノード間の少なくとも1つのアクティブ制御チャネルが存在していなければなりません。リンク検証のために、TEリンクは、少なくとも1つのデータリンクを含まなければなりません。
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メッセージは、制御チャネルを介して交換し、Helloメッセージは、データリンク検証プロセス中に各制御チャネルを介して交換され続けることにしていることに留意すべきです。テストメッセージが検証されているデータリンクを介して送信されます。彼らは一方向性であるため、データリンクが送信方向でテストされています。従って、それは（独立して）同時にテストメッセージを交換するために、両方のノードのために可能です。
To initiate the link verification procedure, the local node MUST send a BeginVerify message over a control channel. To limit the scope of Link Verification to a particular TE Link, the local Link_Id MUST be non-zero. If this field is zero, the data links can span multiple TE links and/or they may comprise a TE link that is yet to be configured. For the case where the local Link_Id field is zero, the "Verify all Links" flag of the BEGIN_VERIFY object is used to distinguish between data links that span multiple TE links and those that have not yet been assigned to a TE link. Specifically, verification of data links that span multiple TE links is indicated by setting the local Link_Id field to zero and setting the "Verify all Links" flag. Verification of data links that have not yet been assigned to a TE link is indicated by setting the local Link_Id field to zero and clearing the "Verify all Links" flag.
リンク検証手順を開始するために、ローカル・ノードは、制御チャネル上BeginVerifyメッセージを送らなければなりません。特定のTEリンクへのリンク検証の範囲を限定することを、ローカルLINK_IDは、非ゼロでなければなりません。このフィールドがゼロの場合、データリンクは、複数のTEリンクにまたがることができ、および/またはそれらを構成する必要がまだある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
リモートノードがBeginVerifyメッセージを受信し、テストメッセージを処理する準備ができている場合、それは、テストメッセージのための所望のトランスポート機構を指定するローカル・ノードに戻すBeginVerifyAckメッセージを送らなければなりません。リモートノードは、32ビット、ノードユニークを含みます
Verify_Id in the BeginVerifyAck message. The Verify_Id MAY be randomly selected; however, it MUST NOT overlap any other Verify_Id currently being used by the node selecting it. The Verify_Id is then used in all corresponding verification messages to differentiate them from different LMP peers and/or parallel Test procedures. When the local node receives a BeginVerifyAck message from the remote node, it may begin testing the data links by transmitting periodic Test messages over each data link. The Test message includes the Verify_Id and the local Interface_Id for the associated data link. The remote node MUST send either a TestStatusSuccess or a TestStatusFailure message in response for each data link. A TestStatusAck message MUST be sent to confirm receipt of the TestStatusSuccess and TestStatusFailure messages. Unacknowledged TestStatusSuccess and TestStatusFailure messages SHOULD be retransmitted until the message is acknowledged or until a retry limit is reached (see also Section 10).
BeginVerifyAckメッセージにVerify_Id。 Verify_Idは、ランダムに選択されてもよいです。しかし、現在、それを選択するノードによって使用される任意の他のVerify_Idを重複してはなりません。 Verify_Idは、異なるLMPピア及び/又は並列テスト手順と区別するために、すべての対応する検証メッセージに使用されます。ローカルノードがリモートノードからBeginVerifyAckメッセージを受信すると、各データリンクを介して定期的なテストメッセージを送信することによってデータ・リンクのテストを開始することができます。テストメッセージはVerify_Idと関連するデータリンクのローカルInterface_Idを含みます。リモートノードは、各データリンクのために応じてTestStatusSuccess又はTestStatusFailureメッセージのいずれかを送信しなければなりません。 TestStatusAckメッセージはTestStatusSuccessとTestStatusFailureメッセージの受信を確認するために送らなければなりません。未確認TestStatusSuccessとTestStatusFailureメッセージは、メッセージが確認されるまで再送信または再試行回数の上限に達するまで（第10節も参照）である必要があります。
It is also permissible for the sender to terminate the Test procedure anytime after sending the BeginVerify message. An EndVerify message SHOULD be sent for this purpose.
送信者がいつでもBeginVerifyメッセージを送信した後、試験手順を終了することも許されています。 EndVerifyメッセージは、この目的のために送ってください。
Message correlation is done using message identifiers and the Verify_Id; this enables verification of data links, belonging to different link bundles or LMP sessions, in parallel.
メッセージ相関は、メッセージ識別子と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.
テストメッセージが受信されると、（ポートラベルまたは構成に応じてコンポーネントリンク識別子のいずれかとGMPLSで使用される）を受信Interface_Idを記録し、そのデータリンクのローカルInterface_Idにマッピングされ、そしてTestStatusSuccessメッセージが送信される必要があります。 TestStatusSuccessメッセージはInterface_IdとVerify_IdとともにローカルInterface_Idは、テストメッセージで受信含みます。 TestStatusSuccessメッセージの受信は、テストメッセージがリモート・ノードで検出されたデータリンクの物理的な接続性が確認されていることを示しています。 TestStatusSuccessメッセージが受信されると、ローカル・ノードは、最大のようなデータリンクをマークし、遠隔ノードにTestStatusAckメッセージを送信すべきです。しかし、テストメッセージが（VerifyDeadIntervalによって指定された）観察期間内のリモートノードで検出されない場合、リモート・ノードを示し、制御チャネルを介しTestStatusFailureメッセージを送信する必要があるデータの物理的な接続性の検証リンクに障害が発生しました。ローカルノードがTestStatusFailureメッセージを受信すると、それが失敗したデータリンクをマークし、遠隔ノードにTestStatusAckメッセージを送信すべきです。リスト上のすべてのデータリンクがテストされている場合は、ローカル・ノードは、テストはこのリンクで完了したことを示すためにEndVerifyメッセージを送るべきです。
If the local/remote data link mappings are known, then the link verification procedure can be optimized by testing the data links in a defined order known to both nodes. The suggested criterion for this ordering is by increasing the value of the remote Interface_Id.
ローカル/リモート・データ・リンク・マッピングが知られている場合、リンク検証手順は、両方のノードに知られて定義された順序でデータリンクをテストすることによって最適化することができます。この順序付けのための提案基準は、リモートInterface_Idの値を増やすことです。
Both the local and remote nodes SHOULD maintain the complete list of Interface_Id mappings for correlation purposes.
ローカルとリモートの両方のノードが相関目的のためにInterface_Idマッピングの完全なリストを維持する必要があります。
Figure 1 shows an example of the link verification scenario that is executed when a link between Node A and Node B is added. In this example, the TE link consists of three free ports (each transmitted along a separate fiber) and is associated with a bi-directional control channel (indicated by a "c"). The verification process is as follows:
図1は、ノードAとノードBとの間のリンクが追加されたときに実行されるリンク検証シナリオの例を示しています。この例では、TEリンクは、三個のフリーポート（それぞれが別々のファイバに沿って送信される）から成り、（「C」で示される）、双方向制御チャネルに関連付けられています。次のように検証プロセスは次のとおりです。
o A sends a BeginVerify message over the control channel to B, indicating it will begin verifying the ports that form the TE link. The LOCAL_LINK_ID object carried in the BeginVerify message carries the identifier (IP address or interface index) that A assigns to the link. o Upon receipt of the BeginVerify message, B creates a Verify_Id and binds it to the TE Link from A. This binding is used later when B receives the Test messages from A, and these messages carry the Verify_Id. B discovers the identifier (IP address or interface index) that A assigns to the TE link by examining the LOCAL_LINK_ID object carried in the received BeginVerify message. (If the data ports are not yet assigned to the TE Link, the binding is limited to the Node_Id of A.) In response to the BeginVerify message, B sends the BeginVerifyAck message to A. The LOCAL_LINK_ID object carried in the BeginVerifyAck message is used to carry the identifier (IP address or interface index) that B assigns to the TE link. The REMOTE_LINK_ID object carried in the BeginVerifyAck message is used to bind the Link_Ids assigned by both A and B. The Verify_Id is returned to A in the BeginVerifyAck message over the control channel. o When A receives the BeginVerifyAck message, it begins transmitting periodic Test messages over the first port (Interface Id=1). The Test message includes the Interface_Id for the port and the Verify_Id that was assigned by B. o When B receives the Test messages, it maps the received Interface_Id to its own local Interface_Id = 10 and transmits a TestStatusSuccess message over the control channel back to Node A. The TestStatusSuccess message includes both the local and received Interface_Ids for the port as well as the Verify_Id. The
O Aは、TEリンクを形成するポートの検証を開始します示し、Bに制御チャネルを介しBeginVerifyメッセージを送信します。 BeginVerifyメッセージで運ばLOCAL_LINK_IDオブジェクトは、Aがリンクに割り当てる識別子（IPアドレスまたはインターフェイスインデックス）を運びます。 O BeginVerifyメッセージを受信すると、BはVerify_Idを作成し、この結合は、BがAからテストメッセージを受信した後ときに使用されるAからTEリンクにバインドし、これらのメッセージはVerify_Idを運びます。 Bは、Aが受信BeginVerifyメッセージで運ばLOCAL_LINK_IDオブジェクトを調べることによって、TEリンクに割り当てる識別子（IPアドレスまたはインターフェイスインデックス）を発見します。 BeginVerifyメッセージに応答して（データポートがまだTEリンクに割り当てられていない場合、結合は、AのNODE_IDに限定される）、BはBeginVerifyAckメッセージで運ばLOCAL_LINK_IDオブジェクトが使用されているAにBeginVerifyAckメッセージを送信します。 Bは、TEリンクに割り当てる識別子（IPアドレスまたはインターフェイスインデックス）を運びます。 BeginVerifyAckメッセージで運ばREMOTE_LINK_IDオブジェクトは、AとBザVerify_Id両方によって割り当てLink_Idsを結合するために使用される制御チャネルを介しBeginVerifyAckメッセージにAに戻されます。 AはBeginVerifyAckメッセージを受信すると、O、それは、第1のポート（インターフェースID = 1）の上に周期的テストメッセージの送信を開始します。テストメッセージはそれ自身のローカルInterface_Id = 10に受信Interface_Idをマッピングし、ノードへのバック制御チャネルを介しTestStatusSuccessメッセージを送信し、ポートとBがテストメッセージを受信するとoをB.によって割り当てられたVerify_IdためInterface_Idを含みますA.ザTestStatusSuccessメッセージは、ローカルおよびポートの受信Interface_IdsならびにVerify_Idの両方を含みます。ザ・
Verify_Id is used to determine the local/remote TE link identifiers (IP addresses or interface indices) to which the data links belong. o A will send a TestStatusAck message over the control channel back to B, indicating it received the TestStatusSuccess message. o The process is repeated until all of the ports are verified. o At this point, A will send an EndVerify message over the control channel to B, indicating that testing is complete. o B will respond by sending an EndVerifyAck message over the control channel back to A.
Verify_Idは、データリンクが属するローカル/リモートTEリンク識別子（IPアドレスまたはインターフェースインデックス）を決定するために使用されます。 O Aは、それがTestStatusSuccessメッセージを受信示し、Bに戻す制御チャネルを介しTestStatusAckメッセージを送信します。すべてのポートが検証されるまで、O処理が繰り返されます。この時点で、Oは、Aは、テストが完了したことを示す、Bに制御チャネル上EndVerifyメッセージを送信します。 O BはAに戻って、制御チャネルを介しEndVerifyAckメッセージを送信することによって応答します
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.
このセクションでは、任意LMP手順は、TEリンクの一つ以上のデータチャネルの状態を迅速に通知することにより障害を管理するために使用されることが記載されています。この手順の範囲は、TEリンク内にある、そのようなものとして、この手順の使用は、LinkSummary交換の一部として交渉されます。手順は、急速に、データリンクとTEリンク障害を単離するために使用することができ、単方向および双方向のLSPの両方のために働くように設計されています。
An important implication of using transparent devices is that traditional methods that are used to monitor the health of allocated data links may no longer be appropriate. Instead of fault detection being in layer 2 or layer 3, it is delegated to the physical layer (i.e., loss of light or optical monitoring of the data).
透明デバイスを使用しての重要な含意は割り当てられたデータリンクの状態を監視するために使用されている伝統的な方法はもはや適切ではないかもしれないということです。代わりに、障害検出は、レイヤ2またはレイヤ3であることの、それが物理層に委譲され（すなわち、光又はデータの光学的監視の損失）。
Recall that a TE link connecting two nodes may consist of a number of data links. If one or more data links fail between two nodes, a mechanism must be used for rapid failure notification so that appropriate protection/restoration mechanisms can be initiated. If the failure is subsequently cleared, then a mechanism must be used to notify that the failure is clear and the channel status is OK.
二つのノードを接続するTEリンクは、データリンクの数から構成されてもよいことを想起されたいです。一の以上のデータリンクが2つのノード間で失敗した場合は、適切な保護/回復メカニズムを開始することができるように、メカニズムは、迅速な障害通知のために使用する必要があります。障害がその後にクリアされている場合、そのメカニズムは、障害がクリアされ、チャンネルのステータスがOKであることを通知するために使用する必要があります。
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は、チャネルステータスメッセージを通じて障害通知を提供します。このメッセージは、単一のデータチャネルが失敗したことを示すために使用されてもよい、複数のデータ・チャネルが失敗した、または全体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.
その上流隣接障害が検出されたことを示すにチャネルステータスメッセージを送信するデータリンク障害を検出し、隣接するノード間の特定のリンク、（データの流れの観点から下流）下流ノードに障害をローカライズする（通知の一緒に束ね失敗したすべてのデータリンク）。チャネルステータスメッセージを受信した上流のノードは、チャネルステータスメッセージを受信したことを示す下流ノードにChannelStatusAckメッセージを送らなければなりません。上流ノードは、障害が、対応するLSP（S）のために局所的に検出されたかどうかを確認するために失敗を相関するはずです。例えば、障害が上流ノード又は内部の入力に明らかである場合には、上流のノードは、障害をローカライズしているであろう。障害が相関されると、上流ノードは、チャネルが失敗したかOKであることを示す下流ノードにチャネルステータスメッセージを送信すべきです。チャネルステータスメッセージが下流ノードによって受信されない場合、それは問題のチャネルのためのChannelStatusRequestメッセージを送るべきです。障害がローカライズされたならば、シグナリングプロトコルは、スパンまたはパス保護と回復手順を開始するために使用されてもよいです。
If all of the data links of a TE link have failed, then the upstream node MAY be notified of the TE link failure without specifying each data link of the failed TE link. This is done by sending failure notification in a ChannelStatus message identifying the TE Link without including the Interface_Ids in the CHANNEL_STATUS object.
TEリンクのデータリンクのすべてが失敗した場合には、上流のノードが失敗したTEリンクの各データリンクを指定せずにTEリンク障害を通知することができます。これはCHANNEL_STATUSオブジェクト内Interface_Ids含まないTEリンクを識別するチャネルステータスメッセージに障害通知を送信することによって行われます。
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.
4つのノードが線形アレイ構成で接続される。図2において、試料ネットワークが示されています。制御チャネルは双方向であり、「C」が付されています。すべてのLSPはまた、双方向です。
In the first example [see Fig. 2(a)], there is a failure on one direction of the bi-directional LSP. Node 4 will detect the failure and will send a ChannelStatus message to Node 3 indicating the failure (e.g., LOL) to the corresponding upstream node. When Node 3 receives the ChannelStatus message from Node 4, it returns a ChannelStatusAck message back to Node 4 and correlates the failure locally. When Node 3 correlates the failure and verifies that the failure is clear, it has localized the failure to the data link between Node 3 and Node 4. At that time, Node 3 should send a ChannelStatus message to Node 4 indicating that the failure has been localized.
最初の例では[図2（a）参照]、双方向LSPの一方向の障害があります。ノード4は、故障を検出し、対応する上流のノードに（例えば、LOL）失敗を示すノード3にチャネルステータスメッセージを送信します。ノード3はノード4からチャネルステータスメッセージを受信すると、それが戻ってノード4へChannelStatusAckメッセージを返し、ローカル障害を対応付けます。ノード3が障害を相関し、障害がクリアされていることを確認すると、その時点で、ノード3とノード4との間のデータリンクに障害が局在化している、ノード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）。同時に（伝搬遅延を無視して）、ノード1（ノード4）は、上流側（下流側）方向に障害を検出し、失敗を示す（データフローに関して）上流の対応するノードへのチャネルステータスメッセージを送信します。ノード2とノード3は、障害の二つの方向にローカライズされているでしょう。
+-------+ +-------+ +-------+ +-------+
+ 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".
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.
チャネルステータスメッセージは、データリンクを積極的に監視する必要があることを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.
チャネルステータスメッセージは、チャネルのチャネルまたはグループが現在アクティブであることを示すために使用されます。 ChannelStatusAckメッセージはチャネルステータスメッセージの受信時に送信されなければなりません。チャネルステータスメッセージを受信した場合、対応するデータリンク（単数または複数）はアクティブ状態に置かなければなりません。アクティブ状態にそれらを置く際に、障害が検出された場合、セクション6.2で説明したように、チャネルステータスメッセージが送信されなければなりません。
The ChannelStatus message may also be used to notify an LMP neighbor that the data link no longer needs to be actively monitored. This is the counterpart to the Channel Active Indication.
データリンクは、もはや積極的に監視する必要があることをチャネルステータスメッセージは、LMP隣人に通知するために使用することはできません。これは、チャンネルのアクティブ表示に対応するものです。
When a ChannelStatus message is received with Channel Deactive Indication, the corresponding data link(s) MUST be taken out of the Active state.
チャネルステータスメッセージがチャネルディアクティブ指示で受信された場合、対応するデータリンク（単数または複数）はアクティブ状態から取り出さなければなりません。
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.
唯一MESSAGE_ID / MESSAGE_ID_ACKオブジェクトは、任意のLMPメッセージに含まれてもよいです。
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フィールドには、発電選択された値を含んでいます。この値は、単調増加でなければなりません。値は、それが同じCC_ID（TEリンクの特定のメッセージのための）（制御チャネルのための特定のメッセージ）、またはLMP隣接してLMPメッセージで送信されたときに、以前に使用されていると考えられます。 MESSAGE_ID_ACKオブジェクトのMESSAGE_IDフィールドには、承認されたメッセージのMESSAGE_IDフィールドが含まれています。
Unacknowledged messages sent with the MESSAGE_ID object SHOULD be retransmitted until the message is acknowledged or until a retry limit is reached (see also Section 10).
MESSAGE_IDオブジェクトに送信された未確認のメッセージはメッセージが確認されるまで再送信または再試行回数の上限に達するまで（第10節も参照）である必要があります。
Note that the 32-bit Message_Id value may wrap. The following expression may be used to test if a newly received Message_Id value is less than a previously received value:
32ビットMESSAGE_ID値がラップしてもよいことに留意されたいです。次の式は、新たに受信したMESSAGE_ID値が以前に受信された値未満であるかどうかをテストするために使用することができます。
If ((int) old_id - (int) new_id > 0) { New value is less than old value; }
もし（（int型）old_id - （INT）NEW_ID> 0）{新しい値が古い値よりも小さいです。 }
Nodes processing incoming messages SHOULD check to see if a newly received message is out of order and can be ignored. Out-of-order messages can be identified by examining the value in the Message_Id field. If a message is determined to be out-of-order, that message should be silently dropped.
着信メッセージを処理するノードは、新たに受信したメッセージが順不同であり、無視することができますかどうかを確認すべきです。アウト・オブ・オーダーメッセージはMESSAGE_IDフィールドの値を調べることによって識別することができます。メッセージは、アウトオブオーダであると判定された場合、そのメッセージは黙って廃棄されるべきです。
If the message is a Config message, and the Message_Id value is less than the largest Message_Id value previously received from the sender for the CC_Id, then the message SHOULD be treated as being out-of-order.
メッセージは、Configメッセージであり、MESSAGE_ID値が予めCC_IDの送信者から受信した最大MESSAGE_ID値未満である場合、メッセージは、アウトオブオーダーであるとして扱われるべきです。
If the message is a LinkSummary message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the TE Link, then the message SHOULD be treated as being out-of-order.
メッセージは、LinkSummaryメッセージであるとMESSAGE_ID値が予めTEリンクの送信者から受信した最大MESSAGE_ID値未満である場合、メッセージは、アウトオブオーダーであるとして扱われるべきです。
If the message is a ChannelStatus message and the Message_Id value is less than the largest Message_Id value previously received from the sender for the specified TE link, then the receiver SHOULD check the Message_Id value previously received for the state of each data channel included in the ChannelStatus message. If the Message_Id value is greater than the most recently received Message_Id value associated with at least one of the data channels included in the message, the message MUST NOT be treated as out of order; otherwise, the message SHOULD be treated as being out of order. However, the state of any data channel MUST NOT be updated if the Message_Id value is less than the most recently received Message_Id value associated with the data channel.
メッセージは、チャネルステータスメッセージであるとMESSAGE_ID値が予め指定されたTEリンクの送信側から受信した最大MESSAGE_ID値未満である場合、受信機はチャネルステータスに含まれる以前に、各データ・チャネルの状態のために受信MESSAGE_ID値を確認してくださいメッセージ。 MESSAGE_ID値はチャネルがメッセージに含まれるデータのうちの少なくとも1つに関連する最も最近に受信されたMESSAGE_ID値よりも大きい場合、メッセージが順序外として扱われてはいけません。そうでない場合、メッセージは順不同であるものとして扱われるべきです。 MESSAGE_ID値は、データチャネルに関連する最も最近受信MESSAGE_ID値未満である場合は、任意のデータチャネルの状態が更新されてはなりません。
All other messages MUST NOT be treated as out-of-order.
他のすべてのメッセージは、アウト・オブ・オーダーとして扱われてはなりません。
This section describes the mechanism to resynchronize the LMP state after a control plane restart. A control plane restart may occur when bringing up the first control channel after a control communications failure. A control communications failure may be the result of an LMP adjacency failure or a nodal failure wherein the LMP control state is lost, but the data plane is unaffected. The latter is detected by setting the "LMP Restart" bit in the Common Header of the LMP messages. When the control plane fails due to the loss of the control channel, the LMP link information should be retained. It is possible that a node may be capable of retaining the LMP link information across a nodal failure. However, in both cases the status of the data channels MUST be synchronized.
このセクションでは、コントロールプレーンの再起動後にLMP状態を再同期するためのメカニズムを説明しています。制御通信障害の後に第1の制御チャネルを立ち上げるときに、制御プレーンの再起動が発生する可能性があります。制御通信障害がLMP隣接障害またはLMP制御状態が失われる請求ノード故障の結果であってもよいが、データプレーンは影響を受けません。後者は、LMPメッセージの共通ヘッダに「LMP再起動」ビットをセットすることによって検出されます。コントロールプレーンは、制御チャネルの損失に起因する障害が発生した場合には、LMPリンク情報が保持されるべきです。ノードがノード障害を横切っLMPリンク情報を保持することが可能であることが可能です。しかし、どちらの場合も、データ・チャネルの状態を同期させる必要があります。
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の手順を使用して再確立されなければなりません。制御チャネルを再確立するとき、Configメッセージは、ユニキャストのIP送信元および宛先アドレスを使用して送信されるべきです。
If the control plane failure was the result of a nodal failure where the LMP control state is lost, then the "LMP Restart" flag MUST be set in LMP messages until a Hello message is received with the RcvSeqNum equal to the local TxSeqNum. This indicates that the control channel is up and the LMP neighbor has detected the restart.
制御プレーン障害がLMP制御状態が失われるノード障害の結果であった場合は、HelloメッセージがローカルTxSeqNumに等しいRcvSeqNumで受信されるまで、「LMP再起動」フラグは、LMPメッセージに設定しなければなりません。これは、制御チャネルがアップしていることを示し、LMP隣人は、再起動を検出しました。
The following assumes that the LMP component restart only occurred on one end of the TE Link. If the LMP component restart occurred on both ends of the TE Link, the normal procedures for LinkSummary should be used, as described in Section 4.
以下は、LMPコンポーネントの再起動が唯一のTEリンクの一方の端部に発生したことを前提としています。 LMPコンポーネント再開がTEリンクの両端に発生した場合、セクション4で説明したように、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.
制御チャネルが起動したら、LMP隣人は隣接関係を挟んTEリンクについてLinkSummaryメッセージを送らなければなりません。 LinkSummaryメッセージのすべてのオブジェクトは、パラメータが非交渉されていることを示し、0にNビットを設定する必要があります。これは、リモート/ローカルLINK_IDとInterface_Idマッピング、関連するデータ・リンク・パラメータ、およびデータ・リンクが現在ユーザトラフィックに割り当てられたの指標を提供します。ノードがLinkSummaryメッセージを受信すると、そのローカル構成をチェックします。ノードが再起動を横切るLMPリンク情報を保持することができる場合DATA_LINKオブジェクトの割り当て/割り当て解除フラグに優先しなければならないLinkSummaryメッセージで受信したことを除いてセクション4で説明したように、それはLinkSummaryメッセージを処理しなければなりません任意のローカル値。しかし、ノードが再起動間でLMPリンク情報を保持することができなかった場合は、ノードが受信LinkSummaryメッセージのデータリンクパラメータを受け入れ、LinkSummaryAckメッセージで応じなければなりません。
Upon completion of the LinkSummary exchange, the node that has restarted the control plane SHOULD send a ChannelStatusRequest message for that TE link. The node SHOULD also verify the connectivity of all unallocated data channels.
LinkSummary交換が完了すると、制御プレーンを再起動したノードは、TEリンクのChannelStatusRequestメッセージを送信すべきです。ノードは、すべての割り当てられていないデータ・チャネルの接続性を確認する必要があります。
All LMP messages are run over UDP with an LMP port number (except, in some cases, the Test messages, which may be limited by the transport mechanism for in-band messaging). The destination address of the IP packet MAY be either the address learned in the Configuration procedure (i.e., the Source IP address found in the IP header of the 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上で実行されている（いくつかのケースでは、以外、インバンド・メッセージングのための搬送機構によって制限され得るテストメッセージ）。 IPパケットの宛先アドレスは、いずれかのアドレスが設定手順（すなわち、受信した構成メッセージのIPヘッダで見つかったソースIPアドレス）、リモート・ノード上で設定されたIPアドレス、またはNODE_IDに知ることができます。後述のように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.
Configメッセージがアドレス指定される方法は、シグナリングトランスポート機構に依存してもよいです。搬送機構は、ポイントツーポイントリンクである場合、構成メッセージは、マルチキャストアドレス（224.0.0.1またはFF02 :: 1）に送信されるべきです。それ以外の場合は、コンフィグメッセージが隣接ノードのIPアドレスに送らなければなりません。これは、制御チャネルの両端に構成してもよいし、自動的に検出することができます。
This section is based on [RFC2961] and provides exponential back-off procedures for message retransmission. Implementations MUST use the described procedures or their equivalent.
このセクションでは、[RFC2961]に基づいて、メッセージを再送信するための指数バックオフの手順を提供します。実装は、記述された手順またはその同等のものを使用しなければなりません。
The following operation is one possible mechanism for exponential back-off retransmission of unacknowledged LMP messages. The sending node retransmits the message until an acknowledgement message is received or until a retry limit is reached. When the sending node receives the acknowledgement, retransmission of the message is stopped. The interval between message retransmission is governed by a rapid retransmission timer. The rapid retransmission timer starts at a small interval and increases exponentially until it reaches a threshold.
以下の動作は未確認のLMPメッセージの指数バックオフの再送信のための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:
迅速な再試行制限のR1：
Rl is the maximum number of times a message will be transmitted without being acknowledged.
RLは、メッセージが肯定応答されずに送信される最大回数です。
Increment value Delta:
インクリメント値デルタ：
Delta governs the speed with which the sender increases the retransmission interval. The ratio of two successive retransmission intervals is (1 + Delta).
デルタは、送信者が再送信間隔を大きくする速度を支配します。二つの連続する再送間隔の比は、（1 +デルタ）です。
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の指数バックオフ（デルタ= 1）及び3の再試行限界の力です。
After a node transmits a message requiring acknowledgement, it should immediately schedule a retransmission after Ri seconds. If a corresponding acknowledgement message is received before Ri seconds, then message retransmission SHOULD be canceled. Otherwise, it will retransmit the message after (1+Delta)*Ri seconds. The retransmission will continue until either an appropriate acknowledgement message is received or the rapid retry limit, Rl, has been reached.
ノードが肯定応答を要求するメッセージを送信した後、直ちにRiを秒後に再送をスケジュールする必要があります。対応する肯定応答メッセージとri秒前に受信された場合、メッセージの再送をキャンセルする必要があります。それ以外の場合は、（1 +デルタ）*のRi秒後にメッセージを再送します。適切な肯定応答メッセージのいずれかが受信され、または急速な再試行限界、R1は、到達されるまで再送信が継続します。
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を= Rおよび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.
送信ノードは、対応する受信確認メッセージを受信したとき、非同期に、それはRLに、再試行回数、Rnのを変更します。
Note that the transmitting node does not advertise or negotiate the use of the described exponential back-off procedures in the Config or LinkSummary messages.
送信ノードは、アドバタイズまたはCONFIGまたはLinkSummaryメッセージに記載指数バックオフ手続きの使用をネゴシエートしないことに注意してください。
The control channel FSM defines the states and logics of operation of an LMP control channel.
制御チャネルFSMは、LMP制御チャネルの動作の状態と論理を定義します。
A control channel can be in one of the states described below. Every state corresponds to a certain condition of the control channel and is usually associated with a specific type of LMP message that is periodically transmitted to the far end.
制御チャネルは、以下に記載のいずれかの状態にすることができます。すべての状態は、制御チャネルの特定の状態に対応しており、通常、定期的に遠端に送信されるLMPメッセージの特定のタイプに関連付けられています。
Down: This is the initial control channel state. In this state, no attempt is being made to bring the control channel up and no LMP messages are sent. The control channel parameters should be set to the initial values.
ダウン：これは、初期制御チャネル状態です。この状態では、何の試みは、制御チャネルのアップをもたらすために行われていないので、何のLMPメッセージは送信されません。制御チャネルパラメータは初期値に設定する必要があります。
ConfSnd: The control channel is in the parameter negotiation state. In this state the node periodically sends a Config message, and is expecting the other side to reply with either a ConfigAck or ConfigNack message. The FSM does not transition into the Active state until the remote side positively acknowledges the parameters.
ConfSnd：制御チャネルは、パラメータネゴシエーション状態にあります。この状態では、ノードは、定期的にConfigメッセージを送り、そしてConfigAck又はConfigNackメッセージのいずれかで応答するために、他の側を期待されています。リモート側が積極的パラメータを認識するまで、FSMは、アクティブ状態に遷移しません。
ConfRcv: The control channel is in the parameter negotiation state. In this state, the node is waiting for acceptable configuration parameters from the remote side. Once such parameters are received and acknowledged, the FSM can transition to the Active state.
ConfRcv：制御チャネルは、パラメータのネゴシエーション状態にあります。この状態では、ノードは、リモート側からの許容される設定パラメータを待っています。そのようなパラメータが受信され、肯定応答されると、FSMは、アクティブ状態に遷移することができます。
Active: In this state the node periodically sends a Hello message and is waiting to receive a valid Hello message. Once a valid Hello message is received, it can transition to the up state.
アクティブ：この状態では、ノードは、定期的にHelloメッセージを送信し、有効なHelloメッセージを受信を待機しています。有効なHelloメッセージを受信すると、それがアップ状態に移行することができます。
Up: The CC is in an operational state. The node receives valid Hello messages and sends Hello messages.
アップ：CCは動作状態にあります。ノードは、有効なHelloメッセージを受信して、Helloメッセージを送信します。
GoingDown: A CC may go into this state because of administrative action. While a CC is in this state, the node sets the ControlChannelDown bit in all the messages it sends.
GoingDown：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：これは制御チャネル交渉を開始すべきことを示す外部トリガしたイベントです。このイベントは、例えば、制御チャネルブートストラップ手順が正常に完了することによって、または構成することにより、オペレータコマンドによってトリガされてもよいです。構成に応じて、これは、リモート・ノードからの構成メッセージを受信するために待機1b）の期間、Configメッセージの送信）のいずれか1Aをトリガします。
2 : evCCDn: This event is generated when there is indication that the control channel is no longer available.
2：evCCDn：制御チャネルはもはや利用可能であるという指示があった場合、このイベントが生成されます。
3 : evConfDone: This event indicates a ConfigAck message has been received, acknowledging the Config parameters.
3：evConfDone：このイベントは、構成パラメータを認め、ConfigAckメッセージが受信されたことを示します。
4 : evConfErr: This event indicates a ConfigNack message has been received, rejecting the Config parameters.
4：evConfErr：このイベントは、構成パラメータを拒否し、ConfigNackメッセージが受信されたことを示します。
5 : evNewConfOK: New Config message was received from neighbor and positively acknowledged.
5：evNewConfOK：新しいConfigメッセージが隣人から受信し、積極的に認められました。
6 : evNewConfErr: New Config message was received from neighbor and rejected with a ConfigNack message.
6：evNewConfErr：新しいConfigメッセージが隣人から受け取ったとConfigNackメッセージで拒否されました。
7 : evContenWin: New Config message was received from neighbor at the same time a Config message was sent to the neighbor. The local node wins the contention. As a result, the received Config message is ignored.
7：evContenWin：新しいConfigメッセージは、Configメッセージが隣人に送られたと同時に、ネイバーから受信されました。ローカル・ノードは、競合に勝ちます。結果として、受信した構成メッセージは無視されます。
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：新しいConfigメッセージは、Configメッセージが隣人に送られたと同時に、ネイバーから受信されました。ローカル・ノードは、競合を失います。 8A）Configメッセージが肯定応答されます。 8b）のConfigメッセージが否定応答されます。
9 : evAdminDown: The administrator has requested that the control channel is brought down administratively.
9：evAdminDown：管理者が制御チャネルが管理上ダウンしていることを要求しました。
10: evNbrGoesDn: A packet with ControlChannelDown flag is received from the neighbor.
10：evNbrGoesDn：ControlChannelDownフラグとパケットがネイバーから受信されます。
11: evHelloRcvd: A Hello packet with expected SeqNum has been received.
11：evHelloRcvd：期待SEQNUMでHelloパケットを受信しました。
12: evHoldTimer: The HelloDeadInterval timer has expired indicating that no Hello packet has been received. This moves the control channel back into the Negotiation state, and depending on the local configuration, this will trigger either 12a) the sending of periodic Config messages, 12b) a period of waiting to receive Config messages from the remote node.
12：evHoldTimer：HelloDeadIntervalのタイマーにはHelloパケットを受信していないことを示す有効期限が切れています。これは、バックネゴシエーション状態に制御チャネルを移動し、ローカル構成に応じて、これは、リモート・ノードからの構成メッセージを受信するために待機12b）の期間、周期的構成メッセージの送信）のいずれか12Aをトリガします。
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：再送タイマが満了したとConfigメッセージを再送します。
16: evHelloRet: The HelloInterval timer has expired and a Hello packet is sent.
16：evHelloRet：HelloIntervalのタイマーが期限切れになったとHelloパケットが送信されます。
17: evDownTimer: A timer has expired and no messages have been received with the ControlChannelDown flag set.
17：evDownTimer：タイマーが満了していると何もメッセージはControlChannelDownフラグを設定して受信されていません。
Figure 3 illustrates operation of the control channel FSM in a form of FSM state transition diagram.
図3は、FSMの状態遷移図の形式で制御チャネルFSMの動作を示します。
+--------+
+----------------->| |<--------------+
| +--------->| Down |<----------+ |
| |+---------| |<-------+ | |
| || +--------+ | | |
| || | ^ 2,9| 2| 2|
| ||1b 1a| | | | |
| || v |2,9 | | |
| || +--------+ | | |
| || +->| |<------+| | |
| || 4,7,| |ConfSnd | || | |
| || 14,15+--| |<----+ || | |
| || +--------+ | || | |
| || 3,8a| | | || | |
| || +---------+ |8b 14,12a| || | |
| || | v | || | |
| |+-|------>+--------+ | || | |
| | | +->| |-----|-|+ | |
| | |6,14| |ConfRcv | | | | |
| | | +--| |<--+ | | | |
| | | +--------+ | | | | |
| | | 5| ^ | | | | |
| | +---------+ | | | | | | |
| | | | | | | | | |
| | v v |6,12b | | | | |
| |10 +--------+ | | | | |
| +----------| | | | | | |
| | +--| Active |---|-+ | | |
10,17| | 5,16| | |-------|---+ |
+-------+ 9 | 13 +->| | | | |
| Going |<--|----------+--------+ | | |
| Down | | 11| ^ | | |
+-------+ | | |5 | | |
^ | v | 6,12b| | |
|9 |10 +--------+ | |12a,14 |
| +----------| |---+ | |
| | Up |-------+ |
+------------------| |---------------+
+--------+
| ^
| |
+---+
11,13,16
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は常に交渉状態（ConfSndまたはConfRcvのいずれか）にFSMを強制します。
The TE Link FSM defines the states and logics of operation of the LMP TE Link.
TEリンクFSMはLMP TEリンクの動作の状態とロジックを定義します。
An LMP TE link can be in one of the states described below. Every state corresponds to a certain condition of the TE link and is usually associated with a specific type of LMP message that is periodically transmitted to the far end via the associated control channel or in-band via the data links.
LMP TEリンクは以下の状態のいずれかになります。すべての状態は、TEリンクの特定の状態に対応しており、通常、定期的にデータリンクを介して関連する制御チャネルを介して、またはインバンド遠端に送信されるLMPメッセージの特定のタイプに関連付けられています。
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.
初期化：データリンクは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.
アップ：これはTEリンクの正常な動作状態です。少なくとも一つの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メッセージを再送します。
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：のvDCダウン：リンクの最後のデータチャネルが削除されました。
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.
任意のデータリンクは下記の状態のいずれかになります。すべての状態は、データリンクの特定の条件に該当します。
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 Testメッセージを定期的にリンクを介して送信されます。
PasvTest: The data link is being checked for incoming test messages.
パ・テスト：データリンクは、着信テキストメッセージをチェックされています。
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.
/のAllocまで：リンクがアップして、データトラフィックに割り当てられています。
Data link events are generated by the packet processing routines and by the FSMs of the associated control channel and the TE link.
データ・リンク・イベントは、パケット処理ルーチンによって、および関連する制御チャネルとTEリンクののFSMによって生成されます。
Every event has its number and a symbolic name. Description of possible data link events is given below:
すべてのイベントは、その数やシンボル名を持っています。可能なデータリンクイベントの説明は以下のとおりであります：
1 :evCCUp: First active control channel goes up.
1：evCCUp：最初のアクティブ制御チャネルが上がります。
2 :evCCDown: LMP neighbor connectivity is lost. This indicates the last LMP control channel has failed between neighboring nodes.
2：evCCDown：LMP隣人の接続が失われます。これは、最後のLMP制御チャネルは、隣接ノードとの間に失敗したことを示します。
3 :evStartTst: This is an external event that triggers the sending of Test messages over the data link.
3：evStartTst：これは、データリンク上でテストメッセージの送信をトリガーする外部イベントです。
4 :evStartPsv: This is an external event that triggers the listening for Test messages over the data link.
4：evStartPsv：これは、データリンクを介してテストメッセージのリスニングをトリガー外部イベントです。
5 :evTestOK: Link verification was successful and the link can be used for path establishment. (a) This event indicates the Link Verification procedure (see Section 5) was successful for this data link and a TestStatusSuccess message was received over the control channel.
5：evTestOK：リンク検証が成功したとのリンクは、パスの確立のために使用することができます。 （a）は、このイベントは（セクション5を参照）、このデータリンクのための成功したとTestStatusSuccessメッセージは制御チャネルを介して受信されたリンクの検証手順を示します。
(b) This event indicates the link is ready for
path establishment, but the Link
Verification procedure was not used. For
in-band signaling of the control channel,
the control channel establishment may be
sufficient to verify the link.
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）の検証手順は、データリンクのTestStatusSuccess又はTestStatusFailureメッセージを受信せずに終了しました。
8 :evPsvTestFail: Link verification returned negative results. This indicates that a Test message was not detected and either (a) the VerifyDeadInterval has expired or (b) the Verification procedure has ended and the VerifyDeadInterval has not yet expired.
8：evPsvTestFail：リンクの検証は否定的な結果を返しました。このテストメッセージは検出されなかったとのいずれか（A）VerifyDeadIntervalが満了した、または（b）の検証手順が終了したとVerifyDeadIntervalがまだ満了していないことを示しています。
9 :evLnkAlloc: The data link has been allocated.
9：evLnkAlloc：データリンクが割り当てられています。
10:evLnkDealloc: The data link has been de-allocated.
10：evLnkDealloc：データリンクが割り当て解除されています。
11:evTestRet: A retransmission timer has expired and the Test message is resent.
11：evTestRet：再送タイマが満了しているとテストメッセージを再送します。
12:evSummaryFail: The LinkSummary did not match for this data port.
12：evSummaryFail：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.
予約フィールドはゼロとして送られて、領収書の上で無視されなければなりません。
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
0×01：ControlChannelDown
0x02: LMP Restart
0×02：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コントロール状態が失われたことを示すために設定されています。 HelloメッセージがローカルTxSeqNumに等しいRcvSeqNumで受信される場合、このフラグは0にリセットされてもよいです。
Msg Type: 8 bits
メッセージの種類：8ビット
The following values are defined. All other values are reserved
次の値が定義されています。その他の値はすべて予約されています
1 = Config
1 =コンフィグ
2 = ConfigAck
2 = ConfigAck
3 = ConfigNack
3 = ConfigNack
4 = Hello
4 =こんにちは
5 = BeginVerify
5 = BeginVerify
6 = BeginVerifyAck
6 = BeginVerifyAck
7 = BeginVerifyNack
7 = BeginVerifyNack
8 = EndVerify
8 = EndVerify
9 = EndVerifyAck
9 = EndVerifyAck
10 = Test
10 =テスト
11 = TestStatusSuccess
11 =テストの成功ステータス
12 = TestStatusFailure
12 =テストステータスの失敗
13 = TestStatusAck
13 = TestStatusAck
14 = LinkSummary
14 = LinkSummary
15 = LinkSummaryAck
15 = LinkSummaryAck
16 = LinkSummaryNack
16 = LinkSummaryNack
17 = ChannelStatus
17 =チャネルステータス
18 = ChannelStatusAck
18 = ChannelStatusAck
19 = ChannelStatusRequest
19 = ChannelStatusRequest
20 = ChannelStatusResponse
20 = ChannelStatusResponse
All of the messages are sent over the control channel EXCEPT the Test message, which is sent over the data link that is being tested.
メッセージのすべてがテストされているデータ・リンクを介して送信されたテストメッセージ以外の制御チャネルを介して送信されます。
LMP Length: 16 bits
LMPの長さ：16ビット
The total length of this LMP message in bytes, including the common header and any variable-length objects that follow.
共通ヘッダおよび以下の任意の可変長オブジェクトを含むバイト単位このLMPメッセージの全長、。
LMP messages are built using objects. Each object is identified by its Object Class and Class-type. Each object has a name, which is always capitalized in this document. LMP objects can be either negotiable or non-negotiable (identified by the N bit in the object header). Negotiable objects can be used to let the devices agree on certain values. Non-negotiable objects are used for announcement of specific values that do not need or do not allow negotiation.
LMPメッセージは、オブジェクトを使用して構築されています。各オブジェクトは、そのオブジェクトクラスとクラスタイプで識別されます。各オブジェクトには、常にこの文書で大文字で名前を持っています。 LMPオブジェクトは交渉または（オブジェクトヘッダーのNビットによって識別される）、非交渉のいずれかであり得ます。応相談オブジェクトは、デバイスが特定の値に合意させるために使用することができます。非交渉のオブジェクトは必要はありませんか交渉を許可しない特定の値の発表のために使用されています。
All values are defined in network byte order (i.e., big-endian byte order).
すべての値は、ネットワークバイトオーダー（すなわち、ビッグエンディアンバイト順）で定義されています。
The format of the LMP object is as follows:
次のようにLMPオブジェクトの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (object contents) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N: 1 bit
N：1ビット
The N flag indicates if the object is negotiable (N=1) or non-negotiable (N=0).
オブジェクトは交渉（N = 1）または非交渉（N = 0）である場合、Nフラグが示しています。
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.
Lengthフィールドは、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:
Configメッセージは、LMPの制御チャネルネゴシエーションフェーズで使用されています。 Configメッセージの内容は、LMPオブジェクトを使用して構築されています。次のようにConfigメッセージの形式は次のとおりです。
<Config Message> ::= <Common Header> <LOCAL_CCID> <MESSAGE_ID>
<LOCAL_NODE_ID> <CONFIG>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The MESSAGE_ID object is within the scope of the LOCAL_CCID object.
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.
（1）それがConfigAck又はConfigNackメッセージを受信するまでConfigメッセージは、定期的に（2）再試行制限に達したとNO ConfigAck又はConfigNackメッセージが受信されていない、または（3）それは遠隔からConfigメッセージを受信し、送信されなければなりませんノードとの競合を失ったが（例えば、リモートノードのNODE_IDは、ローカル・ノードのNODE_IDよりも高くなっています）。再送間隔と再試行限界の両方がローカル設定パラメータです。
The ConfigAck message is used to acknowledge receipt of the Config message and indicate agreement on all parameters.
ConfigAckメッセージは、Configメッセージの受信を確認し、すべてのパラメータに関する合意を示すために使用されます。
<ConfigAck Message> ::= <Common Header> <LOCAL_CCID> <LOCAL_NODE_ID>
<REMOTE_CCID> <MESSAGE_ID_ACK>
<REMOTE_NODE_ID>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being acknowledged.
REMOTE_CCID、MESSAGE_ID_ACK、及びREMOTE_NODE_IDオブジェクトの内容が承認されてConfigメッセージから得なければなりません。
The ConfigNack message is used to acknowledge receipt of the Config message and indicate disagreement on non-negotiable parameters or propose other values for negotiable parameters. Parameters where agreement was reached MUST NOT be included in the ConfigNack Message. The format of the ConfigNack message is as follows:
ConfigNackメッセージは、Configメッセージの受信を確認し、非交渉パラメータの不一致を示すか、交渉パラメータの他の値を提案するために使用されます。合意に達したパラメータはConfigNackメッセージに含まれてはいけません。次のようにConfigNackメッセージの形式は次のとおりです。
<ConfigNack Message> ::= <Common Header> <LOCAL_CCID>
<LOCAL_NODE_ID> <REMOTE_CCID>
<MESSAGE_ID_ACK> <REMOTE_NODE_ID> <CONFIG>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The contents of the REMOTE_CCID, MESSAGE_ID_ACK, and REMOTE_NODE_ID objects MUST be obtained from the Config message being negatively acknowledged.
REMOTE_CCID、MESSAGE_ID_ACK、及びREMOTE_NODE_IDオブジェクトの内容が否定応答される構成メッセージから得なければなりません。
It is possible that multiple parameters may be invalid in the Config message.
複数のパラメータは、Configメッセージで無効である可能性があります。
If a negotiable CONFIG object is included in the ConfigNack message, it MUST include acceptable values for the parameters.
交渉CONFIGオブジェクトがConfigNackメッセージに含まれている場合は、パラメータの許容値を含まなければなりません。
If the ConfigNack message includes CONFIG objects for non-negotiable parameters, they MUST be copied from the CONFIG objects received in the Config message.
ConfigNackメッセージが非交渉パラメータのCONFIGオブジェクトが含まれている場合、それらは、オブジェクトはConfigメッセージで受信CONFIGからコピーされなければなりません。
If the ConfigNack message is received and only includes CONFIG objects that are negotiable, then a new Config message SHOULD be sent. The values in the CONFIG object of the new Config message SHOULD take into account the acceptable values included in the ConfigNack message.
ConfigNackメッセージが受信され、唯一の交渉であるCONFIGオブジェクトが含まれている場合、新しいConfigメッセージを送ってください。新しいConfigメッセージのCONFIGオブジェクトの値を考慮にConfigNackメッセージに含まれる許容値を取る必要があります。
If a node receives a Config message and recognizes the CONFIG object, but does not recognize the C-Type, a ConfigNack message including the unknown CONFIG object MUST be sent.
ノードは、Configメッセージを受信し、CONFIGオブジェクトを認識したが、C型を認識しない場合は、未知のCONFIGオブジェクトを含むConfigNackメッセージが送信されなければなりません。
The format of the Hello message is as follows:
次のようにHelloメッセージの形式は次のとおりです。
<Hello Message> ::= <Common Header> <LOCAL_CCID> <HELLO>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The Hello message MUST be periodically transmitted at least once every HelloInterval msec. If no Hello message is received within the HelloDeadInterval, the control channel is assumed to have failed.
Helloメッセージは、定期的に、少なくとも一回HelloIntervalのミリ秒を送信しなければなりません。何のHelloメッセージがHelloDeadIntervalの内に受信されない場合、制御チャネルは失敗したと想定されます。
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.
上記送信順序に従わされるべきです。
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フィールドが非ゼロでなければなりません。このフィールドがゼロの場合、データリンクは、複数の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.
ローカル/リモート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フィールドが非ゼロでなければなりません。
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.
（1）ノードが検証プロセスを受け入れるか拒否するかBeginVerifyAck又はBeginVerifyNackメッセージを受信するか、（2）再試行制限に達したとNO BeginVerifyAck又はBeginVerifyNackメッセージが受信されていない。までBeginVerifyメッセージが定期的に送信されなければなりません再送間隔と再試行限界の両方がローカル設定パラメータです。
When a BeginVerify message is received and Test messages are ready to be processed, a BeginVerifyAck message MUST be transmitted.
BeginVerifyメッセージが受信され、テスト・メッセージを処理する準備ができている場合、BeginVerifyAckメッセージが送信されなければなりません。
<BeginVerifyAck Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <BEGIN_VERIFY_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The LOCAL_LINK_ID object may be included if the local/remote Link_Id mapping is known or learned through the BeginVerify message.
ローカル/リモートLINK_IDマッピングがBeginVerifyメッセージを介して知られているか、または学習される場合LOCAL_LINK_IDオブジェクトが含まれていてもよいです。
The Link_Id field of the LOCAL_LINK_ID MUST be non-zero if included.
含まれている場合LOCAL_LINK_IDのLINK_IDフィールドが非ゼロでなければなりません。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being acknowledged.
MESSAGE_ID_ACKオブジェクトの内容が承認されてBeginVerifyメッセージから得なければなりません。
The VERIFY_ID object contains a node-unique value that is assigned by the generator of the BeginVerifyAck message. This value is used to uniquely identify the Verification process from multiple LMP neighbors and/or parallel Test procedures between the same LMP neighbors.
VERIFY_IDオブジェクトはBeginVerifyAckメッセージジェネレータによって割り当てられるノード一意の値を含んでいます。この値は一意に複数LMP隣人及び/又は同じLMP隣人との間に並列試験手順から検証処理を識別するために使用されます。
If a BeginVerify message is received and a node is unwilling or unable to begin the Verification procedure, a BeginVerifyNack message MUST be transmitted.
BeginVerifyメッセージが受信され、ノードが不本意又は検証手順を開始することができないされている場合、BeginVerifyNackメッセージが送信されなければなりません。
<BeginVerifyNack Message> ::= <Common Header> [<LOCAL_LINK_ID>]
<MESSAGE_ID_ACK> <ERROR_CODE>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the BeginVerify message being negatively acknowledged.
MESSAGE_ID_ACKオブジェクトの内容は、否定応答されたBeginVerifyメッセージから得なければなりません。
If the Verification process is not supported, the ERROR_CODE MUST indicate "Link Verification Procedure not supported".
検証プロセスがサポートされていない場合、ERROR_CODEは、「サポートされていないリンクの検証プロシージャ」を示す必要があります。
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は「検証したくない」示す必要があります。 BeginVerifyNackメッセージは、Rfは、ローカルに定義されたパラメータであるようERROR_CODE、BeginVerifyは、RF秒後BeginVerify再送をスケジュールする必要があり発信ノードで受信された場合。
If the Verification Transport mechanism is not supported, the ERROR_CODE MUST indicate "Unsupported verification transport mechanism".
検証運輸機構がサポートされていない場合、ERROR_CODEは、「サポートされていない検証移送機構」を示す必要があります。
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のリモート構成がサポートされておらず、（BeginVerifyメッセージに含ま）REMOTE_LINK_IDオブジェクトの内容は、任意の設定された値と一致しない場合、ERROR_CODEは「LINK_ID構成エラー」を示す必要があります。
If a node receives a BeginVerify message and recognizes the BEGIN_VERIFY object but does not recognize the C-Type, the ERROR_CODE MUST indicate "Unknown object C-Type".
ノードがBeginVerifyメッセージを受信し、BEGIN_VERIFYオブジェクトを認識するがC型を認識しない場合、ERROR_CODEは「未知のオブジェクトのC型」を示す必要があります。
The EndVerify message is sent over the control channel and is used to terminate the link verification process. The EndVerify message may be sent any time the initiating node desires to end the Verify procedure. The format is as follows:
EndVerifyメッセージは、制御チャネルを介して送信され、リンク検証プロセスを終了するために使用されます。 EndVerifyメッセージは、開始ノードが確認手続きを終了することを望む任意の時間に送信することができます。形式は次のとおりです。
<EndVerify Message> ::=<Common Header> <MESSAGE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The EndVerify message will be periodically transmitted until (1) an EndVerifyAck message has been received or (2) a retry limit has been reached and no EndVerifyAck message has been received. Both the retransmission interval and the retry limit are local configuration parameters.
EndVerifyメッセージは、定期的に（1）EndVerifyAckメッセージを受信したか、（2）再試行制限に達したと全くEndVerifyAckメッセージが受信されていないまで送信されます。再送間隔と再試行限界の両方がローカル設定パラメータです。
The EndVerifyAck message is sent over the control channel and is used to acknowledge the termination of the link verification process. The format is as follows:
EndVerifyAckメッセージは、制御チャネルを介して送信され、リンク検証プロセスの終了を確認するために使用されます。形式は次のとおりです。
<EndVerifyAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the EndVerify message being acknowledged.
MESSAGE_ID_ACKオブジェクトの内容が承認されてEndVerifyメッセージから得なければなりません。
The Test message is transmitted over the data link and is used to verify its physical connectivity. Unless explicitly stated, these messages MUST be transmitted over UDP like all other LMP messages. The format of the Test messages is as follows:
テストメッセージは、データリンクを介して送信され、その物理的な接続を確認するために使用されます。明示的に述べられない限り、これらのメッセージは、他のすべてのLMPメッセージのようにUDPを介して送信されなければなりません。次のようにテストメッセージの形式は次のとおりです。
<Test Message> ::= <Common Header> <LOCAL_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
Note that this message is sent over a data link and NOT over the control channel. The transport mechanism for the Test message is negotiated using the Verify Transport Mechanism field of the BEGIN_VERIFY object and the Verify Transport Response field of the BEGIN_VERIFY_ACK object (see Sections 13.8 and 13.9).
このメッセージは、データリンク上としない制御チャネルを介して送信されることに注意してください。テストメッセージのトランスポート機構がBEGIN_VERIFYオブジェクトの搬送機構フィールドを確認して使用してネゴシエートされ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）は、リモート（受信）ノードまたは（からの制御チャネル上で相関TestStatusSuccess又はTestStatusFailureメッセージを受信するまで、対応するデータ・リンク上で定期的に（少なくとも一度VerifyIntervalミリ秒）指定されたテストメッセージを送信します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メッセージは、制御チャネルを介して送信され、テストメッセージで受信したローカルInterface_IdとInterface_Idとの間のマッピングを送信するために使用されます。
<TestStatusSuccess Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <LOCAL_INTERFACE_ID>
<REMOTE_INTERFACE_ID> <VERIFY_ID>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The contents of the REMOTE_INTERFACE_ID object MUST be obtained from the corresponding Test message being positively acknowledged.
REMOTE_INTERFACE_IDオブジェクトの内容は、対応するテストメッセージが肯定応答されるのを取得しなければなりません。
The TestStatusFailure message is transmitted over the control channel and is used to indicate that the Test message was not received.
TestStatusFailureメッセージは、制御チャネルを介して送信され、テストメッセージが受信されなかったことを示すために使用されます。
<TestStatusFailure Message> ::= <Common Header> <MESSAGE_ID>
<VERIFY_ID>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The TestStatusAck message is used to acknowledge receipt of the TestStatusSuccess or TestStatusFailure messages.
TestStatusAckメッセージがTestStatusSuccessまたはTestStatusFailureメッセージの受信を確認するために使用されます。
<TestStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
<VERIFY_ID>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the TestStatusSuccess or TestStatusFailure message being acknowledged.
MESSAGE_ID_ACKオブジェクトの内容がTestStatusSuccessから得なければならないか、TestStatusFailureメッセージが肯定応答されます。
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.
上記送信順序に従わされるべきです。
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メッセージは、リンクが検証プロセスではありませんいつでも交換することができます。 （1）ノードがLinkSummaryAck又はLinkSummaryNackメッセージまたは（2）再試行制限に達したとないLinkSummaryAckを受信するまで、またはLinkSummaryNackメッセージが受信されたLinkSummaryメッセージを定期的に送信されなければなりません。再送間隔と再試行限界の両方がローカル設定パラメータです。
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.
上記送信順序に従わされるべきです。
The LinkSummaryNack message is used to indicate disagreement on non-negotiated parameters or propose other values for negotiable parameters. Parameters on which agreement was reached MUST NOT be included in the LinkSummaryNack message.
LinkSummaryNackメッセージは非ネゴシエートパラメータの不一致を示すか、交渉パラメータの他の値を提案するために使用されます。合意がされたパラメータはLinkSummaryNackメッセージに含まれてはなりません。
<LinkSummaryNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE> [<DATA_LINK>...]
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The DATA_LINK objects MUST include acceptable values for all negotiable parameters. If the LinkSummaryNack includes DATA_LINK objects for non-negotiable parameters, they MUST be copied from the DATA_LINK objects received in the LinkSummary message.
DATA_LINKオブジェクトは、すべての交渉パラメータの許容値を含まなければなりません。 LinkSummaryNack非交渉パラメータのDATA_LINKオブジェクトが含まれている場合、それらは、オブジェクトがLinkSummaryメッセージで受信DATA_LINKからコピーされなければなりません。
If the LinkSummaryNack message is received and only includes negotiable parameters, then a new LinkSummary message SHOULD be sent. The values received in the new LinkSummary message SHOULD take into account the acceptable parameters included in the LinkSummaryNack message.
LinkSummaryNackメッセージが受信のみ交渉パラメータが含まれている場合、新しいLinkSummaryメッセージが送信されるべきです。新しいLinkSummaryメッセージで受信した値を考慮にLinkSummaryNackメッセージに含まれる許容可能なパラメータを取る必要があります。
If the LinkSummary message is received with unacceptable, non-negotiable parameters, the ERROR_CODE MUST indicate "Unacceptable non-negotiable LINK_SUMMARY parameters."
LinkSummaryメッセージは受け入れられない、非交渉パラメータを用いて受信された場合、ERROR_CODE「は許可されない非交渉LINK_SUMMARYパラメータ」を示さなければなりません
If the LinkSummary message is received with unacceptable negotiable parameters, the ERROR_CODE MUST indicate "Renegotiate LINK_SUMMARY parameters."
LinkSummaryメッセージが受け入れられない交渉パラメータを用いて受信された場合、ERROR_CODEは「LINK_SUMMARYパラメータの再ネゴシエーション」と表示しなければなりません
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オブジェクト」を示す必要があります
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オブジェクト」を示す必要があります
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-タイプ」と表示しなければなりません
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-タイプ」と表示しなければなりません
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:
チャネルステータスメッセージは、制御チャネルを介して送信され、データリンクのステータスのLMP隣人に通知するのに使用されます。チャネルステータスメッセージを受信したノードは、ChannelStatusAckメッセージで応じなければなりません。形式は次のとおりです。
<ChannelStatus Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID> <CHANNEL_STATUS>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
If the CHANNEL_STATUS object does not include any Interface_Ids, then this indicates the entire TE Link has failed.
CHANNEL_STATUSオブジェクトがどのInterface_Idsが含まれていない場合、これは全体のTEリンクの障害を示しています。
The ChannelStatusAck message is used to acknowledge receipt of the ChannelStatus Message. The format is as follows:
ChannelStatusAckメッセージはチャネルステータスメッセージの受信を確認するために使用されます。形式は次のとおりです。
<ChannelStatusAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
The contents of the MESSAGE_ID_ACK object MUST be obtained from the ChannelStatus message being acknowledged.
MESSAGE_ID_ACKオブジェクトの内容が承認されてチャネルステータスメッセージから得なければなりません。
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メッセージで応じなければなりません。形式は次のとおりです。
<ChannelStatusRequest Message> ::= <Common Header> <LOCAL_LINK_ID>
<MESSAGE_ID>
[<CHANNEL_STATUS_REQUEST>]
The above transmission order SHOULD be followed.
上記送信順序に従わされるべきです。
If the CHANNEL_STATUS_REQUEST object is not included, then the ChannelStatusRequest is being used to request the status of ALL of the data link(s) of the TE Link.
CHANNEL_STATUS_REQUESTオブジェクトが含まれていない場合は、ChannelStatusRequestはTEリンクのデータリンク（S）のALLの状態を要求するために使用されています。
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.
上記送信順序に従わされるべきです。
The contents of the MESSAGE_ID_ACK objects MUST be obtained from the ChannelStatusRequest message being acknowledged.
MESSAGE_ID_ACKオブジェクトの内容が承認されてChannelStatusRequestメッセージから得なければなりません。
Class = 1
クラス= 1
o C-Type = 1, LOCAL_CCID
O Cタイプ= 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
CC_ID：32ビット
This MUST be node-wide unique and non-zero. The CC_Id identifies the control channel of the sender associated with the message.
これは、ノード全体でユニークかつ非ゼロでなければなりません。 CC_IDは、メッセージに関連付けられた送信者の制御チャネルを特定します。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
o C-Type = 2, REMOTE_CCID
O Cタイプ= 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を識別し、非ゼロでなければなりません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
Class = 2
クラス= 2
o C-Type = 1, LOCAL_NODE_ID
O Cタイプ= 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パケットを発信したノードをなIDを。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
o C-Type = 2, REMOTE_NODE_ID
O Cタイプ= 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:
NODE_ID：
This identities the remote node.
これは、リモートノードがなIDを。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
Class = 3
クラス= 3
o C-Type = 1, IPv4 LOCAL_LINK_ID
O Cタイプ= 1、IPv4のLOCAL_LINK_ID
o C-Type = 2, IPv4 REMOTE_LINK_ID
O Cタイプ= 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タイプ= 3、IPv6のLOCAL_LINK_ID
o C-Type = 4, IPv6 REMOTE_LINK_ID
O Cタイプ= 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タイプ= 5、アンナンバードLOCAL_LINK_ID
o C-Type = 6, Unnumbered REMOTE_LINK_ID
O Cタイプ= 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:
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の場合、これは、メッセージに関連付けられている送信者のリンクを識別します。この値は、非ゼロでなければなりません。
For REMOTE_LINK_ID, this identifies the remote node's Link_Id and MUST be non-zero.
REMOTE_LINK_IDため、これは、リモートノードのLINK_IDを識別し、非ゼロでなければなりません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
Class = 4
クラス= 4
o C-Type = 1, IPv4 LOCAL_INTERFACE_ID
O Cタイプ= 1、IPv4のLOCAL_INTERFACE_ID
o C-Type = 2, IPv4 REMOTE_INTERFACE_ID
O Cタイプ= 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タイプ= 3、IPv6のLOCAL_INTERFACE_ID
o C-Type = 4, IPv6 REMOTE_INTERFACE_ID
O Cタイプ= 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タイプ= 5、アンナンバードLOCAL_INTERFACE_ID
o C-Type = 6, Unnumbered REMOTE_INTERFACE_ID
O Cタイプ= 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の場合、これはデータリンクを識別します。この値は、ノード全体でユニークかつ非ゼロでなければなりません。
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は非ゼロでなければなりません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
Class = 5
クラス= 5
o C-Type=1, MessageId
O Cタイプ= 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タイプ= 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:
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タイプ= 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).
Helloパケットが送信され、ミリ秒（ms）で測定された頻度を示します。
HelloDeadInterval: 16 bits.
HelloDeadIntervalの：16ビット。
If no Hello packets are received within the HelloDeadInterval, the control channel is assumed to have failed. The HelloDeadInterval is measured in milliseconds (ms). The HelloDeadInterval MUST be greater than the HelloInterval, and SHOULD be at least 3 times the value of HelloInterval.
何のHelloパケットがHelloDeadIntervalの内に受信されない場合、制御チャネルは失敗したと想定されます。 HelloDeadIntervalのは、ミリ秒（ms）で測定されます。 HelloDeadIntervalのはHelloIntervalのより大きくなければならない、とHelloIntervalの少なくとも3倍の値であるべきです。
If the fast keep-alive mechanism of LMP is not used, the HelloInterval and HelloDeadInterval MUST be set to zero.
LMPの速いキープアライブメカニズムが使用されていない場合は、HelloIntervalのとHelloDeadIntervalのは、ゼロに設定しなければなりません。
Class = 7
クラス= 7
o C-Type = 1, Hello
O Cタイプ= 1、ハロー
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RcvSeqNum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TxSeqNum: 32 bits
TxSeqNum：32ビット
This is the current sequence number for this Hello message. This sequence number will be incremented when the sequence number is reflected in the RcvSeqNum of a Hello packet that is received over the control channel.
これは、このHelloメッセージの現在のシーケンス番号です。シーケンス番号は、制御チャネルを介して受信されたHelloパケットのRcvSeqNumに反映されている場合は、このシーケンス番号をインクリメントします。
TxSeqNum=0 is not allowed. TxSeqNum=1 is used to indicate that this is the first Hello message sent over the control channel.
TxSeqNum = 0が許可されていません。 TxSeqNum = 1は、この制御チャネルを介して送信される最初のHelloメッセージであることを示すために使用されます。
RcvSeqNum: 32 bits
RcvSeqNum：32ビット
This is the sequence number of the last Hello message received over the control channel. RcvSeqNum=0 is used to indicate that a Hello message has not yet been received.
これは、制御チャネルを介して受信した最後のHelloメッセージのシーケンス番号です。 RcvSeqNum = 0は、Helloメッセージを受信していないことを示すために使用されます。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
Class = 8
クラス= 8
o C-Type = 1
O Cタイプ= 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | VerifyInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Data Links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EncType | (Reserved) | Verify Transport Mechanism |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TransmissionRate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
0×0002データリンクタイプ
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.
TransmissionRate: 32 bits
TransmissionRate：32ビット
This is the transmission rate of the data link over which the Test messages will be transmitted. This is expressed in bytes per second and represented in IEEE floating-point format.
これは、テストメッセージが送信される上でデータリンクの伝送速度です。これは、秒あたりのバイト数で発現させ、IEEE浮動小数点形式で表現されます。
Wavelength: 32 bits
波長：32ビット
When a data link is assigned to a port or component link that is capable of transmitting multiple wavelengths (e.g., a fiber or waveband-capable port), it is essential to know which wavelength the test messages will be transmitted over. This value corresponds to the wavelength at which the Test messages will be transmitted over and has local significance. If there is no ambiguity as to the wavelength over which the message will be sent, then this value SHOULD be set to 0.
データリンクは、複数の波長（例えば、繊維又は波長帯可能なポート）を送信することができるポートまたはコンポーネントリンクに割り当てられている場合は、テスト・メッセージを介して送信される波長かを知ることが不可欠です。この値は、テストメッセージを介して送信し、ローカルの意味を有するされる波長に相当します。メッセージが送信されるにわたって波長についての曖昧がない場合、この値は0に設定されるべきです。
Class = 9
クラス= 9
o C-Type = 1
O Cタイプ= 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VerifyDeadInterval | Verify_Transport_Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VerifyDeadInterval: 16 bits
VerifyDeadInterval：16ビット
If a Test message is not detected within the VerifyDeadInterval, then a node will send the TestStatusFailure message for that data link.
テストメッセージがVerifyDeadInterval内に検出されない場合、ノードは、そのデータリンクのためTestStatusFailureメッセージを送信します。
Verify_Transport_Response: 16 bits
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メッセージ（およびテストメッセージの将来のレシピエント）のレシピエントは、テストメッセージの送信機によって提供される様々なタイプの輸送機構を選択します。 Oneと1ビットだけが検証輸送応じて設定しなければなりません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
Class = 10
クラス= 10
o C-Type = 1
O Cタイプ= 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verify_Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
クラス= 11
o C-Type = 1, IPv4 TE_LINK
O Cタイプ= 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タイプ= 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タイプ= 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を識別し、非ゼロでなければなりません。
Remote_Link_Id:
Remote_Link_Id：
This identifies the remote node's Link_Id and MUST be non-zero.
これは、リモート・ノードのLINK_IDを識別し、非ゼロでなければなりません。
Class = 12
クラス= 12
o C-Type = 1, IPv4 DATA_LINK
O Cタイプ= 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タイプ= 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.
これは、データリンクのローカル識別子です。これは、ノード全体でユニークかつ非ゼロでなければなりません。
Remote_Interface_Id:
Remote_Interface_Id：
This is the remote identifier of the data link. This MUST be non-zero.
これは、データリンクのリモート識別子です。これは、非ゼロでなければなりません。
Subobjects
サブオブジェクト
The contents of the DATA_LINK object consist of a series of variable-length data items called subobjects. The subobjects are defined in Section 13.12.1 below.
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オブジェクトの内容は、サブオブジェクトと呼ばれる可変長のデータ項目の系列を含みます。各サブオブジェクトの形式は次のとおりです。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------//--------------+
| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------//---------------+
Type: 8 bits
タイプ：8ビット
The Type indicates the type of contents of the subobject. Currently defined values are:
タイプは、サブオブジェクトの内容の種類を示します。現在、定義された値は次のとおりです。
Type = 1, Interface Switching Type
タイプ= 1、インターフェイスのスイッチングタイプ
Type = 2, Wavelength
タイプ= 2、波長
Length: 8 bits
長さ：8ビット
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4.
長さは、タイプと長さフィールドを含むバイト単位のサブオブジェクトの全長を含んでいます。長さは少なくとも4でなければなりません、及び4の倍数でなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Switching Type| EncType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Reservable Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
これは、秒あたりのバイト数で測定し、IEEE浮動小数点形式で表現されます。
Maximum Reservable Bandwidth: 32 bits
最大予約可能帯域幅：32ビット
This is measured in bytes per second and represented in IEEE floating point format.
これは、秒あたりのバイト数で測定し、IEEE浮動小数点形式で表現されます。
If the interface only supports a fixed rate, the minimum and maximum bandwidth fields are set to the same value.
インタフェースのみ固定レートをサポートしている場合、最小および最大帯域幅フィールドは、同じ値に設定されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
クラス= 13 O Cタイプ= 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タイプ= 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.
1シグナルオーケー（OK）：チャネルが動作している2信号劣化（SD）：事前に選択された閾値を越えるBERによるソフト障害。しきい値を定義するために使用される特定のBERが構成されています。 3信号障害（SF）：信号（LOS）の損失を含む（がこれらに限定されない）ハード信号障害、フレームの損失（LOF）、またはラインAIS。
This object contains one or more Interface_Ids followed by a Channel_Status field.
このオブジェクトは、CHANNEL_STATUSフィールドに続く1以上のInterface_Idsが含まれています。
To indicate the status of the entire TE Link, there MUST be only one Interface_Id, and it MUST be zero.
全体TEリンクの状態を示すために、そこに一つだけInterface_Idでなければならない、そしてそれがゼロでなければなりません。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
Class = 14
クラス= 14
o C-Type = 1, IPv4 INTERFACE_ID
O Cタイプ= 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.
NはInterface_Idsの数である場合、このオブジェクトの長さは、バイト単位で4 + 4Nです。
o C-Type = 2, IPv6 INTERFACE_ID
O Cタイプ= 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.
NはInterface_Idsの数である場合、このオブジェクトの長さは、バイト単位で4 + 16Nです。
o C-Type = 3, Unnumbered INTERFACE_ID
O Cタイプ= 3、アンナンバード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.
NはInterface_Idsの数である場合、このオブジェクトの長さは、バイト単位で4 + 4Nです。
This object is non-negotiable.
このオブジェクトは譲渡禁止です。
Class = 20
クラス= 20
o C-Type = 1, BEGIN_VERIFY_ERROR
O Cタイプ= 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 =不本意。 0×04 =サポートされていない検証移送機構。 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.
BeginVerifyNackメッセージは、Rfは、ローカルに定義されたパラメータであるエラーコード2、BeginVerifyは、RF秒後BeginVerify再送をスケジュールする必要があり発信ノードで受信された場合。
o C-Type = 2, LINK_SUMMARY_ERROR
O Cタイプ= 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パラメータ。 0×02 =再ネゴシエートLINK_SUMMARYパラメータ。 0×04 =無効な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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（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.、エド。 、RFC 4202およびY. Rekhter、エド。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）の支援でルーティング拡張機能」、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]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、RFC 2961、2001年4月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
"ISAKMPのための解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、RFC 2407、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC3471] Berger, L., Ed., "Generalized MPLS - Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、エド、 "一般化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]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）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]スミット、H.、およびT.李、 "中間システムトラフィックエンジニアリング（TE）のための中間システム（IS-IS）への拡張"、RFC 3784、2004年6月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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セキュリティ、認証、整合性、および再生保護を提供できなければなりません。
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.
LMPトラフィックの場合O、機密性が必要とされていません。唯一の認証は、制御パケット（LMP制御チャネルに沿って送信されたパケットが）正しい場所から発信されており、中に変更されていないことを保証するために必要とされます。 LMPテストパケットを保護する必要がないデータリンクを介して交換しました。
o For LMP traffic, protecting the identity of LMP end-points is not commonly required.
LMPエンドポイントのアイデンティティを保護LMPトラフィックのoは、一般的に必要とされません。
o The security mechanism should provide for well defined key management schemes. The key management schemes should be well analyzed to be cryptographically secure. The key management schemes should be scalable. In addition, the key management system should be automatic.
Oセキュリティ・メカニズムは十分に定義されたキー管理方式を提供すべきです。鍵管理スキームがうまく暗号的に安全であると分析されなければなりません。鍵管理方式は、スケーラブルでなければなりません。また、鍵管理システムが自動でなければなりません。
o The algorithms used for authentication MUST be cryptographically sound. Also, the security protocol MUST allow for negotiating and using different authentication algorithms.
O認証に使用されるアルゴリズムは、暗号音でなければなりません。また、セキュリティプロトコルは、交渉と異なる認証アルゴリズムを使用して考慮しなければなりません。
IPsec is a protocol suite that is used to secure communication at the network layer between two peers. This protocol is comprised of IP Security architecture document [RFC2401], IKE [RFC2409], IPsec AH [RFC2402], and IPsec ESP [RFC2406]. IKE is the key management protocol for IP networks, while AH and ESP are used to protect IP traffic. IKE is defined specific to IP domain of interpretation.
IPsecは2つのピア間ネットワーク層での通信を保護するために使用されるプロトコル群です。このプロトコルはIPセキュリティアーキテクチャ文書[RFC2401]、IKE [RFC2409]、IPsecのAH [RFC2402]、およびIPsec ESP [RFC2406]で構成されています。 AHとESPは、IPトラフィックを保護するために使用されるIKEは、IPネットワークのための鍵管理プロトコルです。 IKEは、解釈のIPドメインに固有に定義されています。
Considering the requirements described in Section 15.1, it is recommended that, where security is needed for LMP, implementations use IPsec as described below:
セクション15.1で説明した要件を考慮すると、セキュリティがLMPのために必要とされる場所以下で説明するように、実装はIPsecを使用することをお勧めします。
1. Implementations of LMP over IPsec protocol SHOULD support manual keying mode.
IPsecプロトコル経由LMPの1実装は、手動キー入力モードをサポートする必要があります。
Manual keying mode provides an easy way to set up and diagnose IPsec functionality.
手動キー入力モードを設定し、IPsecの機能を診断するための簡単な方法を提供します。
However, note that manual keying mode cannot effectively support features such as replay protection and automatic re-keying. An implementer using manual keys must be aware of these limits.
しかし、手動キー入力モードが効果的な再生保護と自動再入力などの機能をサポートできないことに注意してください。手動キーを使用して、実装者は、これらの限界を認識する必要があります。
It is recommended that an implementer use manual keying only for diagnostic purposes and use dynamic keying protocol to make use of features such as replay protection and automatic re-keying.
実装の使用説明書は、診断目的のためにのみキーイングならびにリプレイ保護と自動再キーイングなどの機能を利用するために動的キーイングプロトコルを使用することをお勧めします。
2. IPsec ESP with trailer authentication in tunnel mode MUST be supported.
トンネルモードでのトレーラーの認証2. IPsecのESPをサポートしなければなりません。
3. Implementations MUST support authenticated key exchange protocols. IKE [RFC2409] MUST be used as the key exchange protocol if keys are dynamically negotiated between peers.
3.実装は、認証済みの鍵交換プロトコルをサポートしなければなりません。キーが動的にピア間でネゴシエートされた場合に、IKE [RFC2409]は、鍵交換プロトコルとして使用されなければなりません。
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.
IKEプロトコルの場合5.は、クイックモードで交渉SAのアイデンティティは、ピアが保護することに同意するものとし、アドレス空間、プロトコル、およびポート情報で構成され、トラフィックを表します。
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.
アイデンティティはタイプIPアドレスでなければならず、アイデンティティの値は、通信ピアのIPアドレスであるべきです。
The protocol field MUST be UDP. The port field SHOULD be set to zero to indicate port fields should be ignored. This implies all UDP traffic between the peers must be sent through the IPsec tunnel. If an implementation supports port-based selectors, it can opt for a more finely grained selector by specifying the port field to the LMP port. If, however, the peer does not use port-based selectors, the implementation MUST fall back to using a port selector value of 0.
プロトコルフィールドはUDPでなければなりません。ポートフィールドは無視されるべきで、ポートフィールドを示すためにゼロに設定する必要があります。これは、ピア間のすべてのUDPトラフィックがIPsecトンネルを介して送信されなければならない意味します。実装は、ポートベースのセレクタをサポートしている場合、それはLMPポートにポートフィールドを指定することで、より細かく粒状のセレクタを選ぶことができます。しかし、ピアがポートベースのセレクタを使用しない場合、実装は0のポートセレクタ値を使用してフォールバックしなければなりません。
When IPsec is configured to be used with a peer, all LMP messages are expected to be sent over the IPsec tunnel (crypto channel). Similarly, an LMP receiver configured to use Ipsec with a peer should reject any LMP traffic that does not come through the crypto channel.
IPsecは、ピアで使用するように構成されている場合、すべてのLMPメッセージは、IPsecトンネル（暗号化チャネル）を介して送信されることが期待されます。同様に、ピアとIPSecを使用するように構成されたLMP受信機は、暗号チャンネルを介してこない任意LMPトラフィックを拒否すべきです。
The crypto channel can be pre-setup with the LMP neighbor, or the first LMP message sent to the peer can trigger the creation of the IPsec tunnel.
暗号化チャネルがLMP隣人で予め設定することができ、またはピアに送信された最初のLMPメッセージは、IPsecトンネルの作成をトリガすることができます。
A set of control channels can share the same crypto channel. When LMP Hellos are used to monitor the status of the control channel, it is important to keep in mind that the keep-alive failure in a control channel may also be due to a failure in the crypto channel. The following method is recommended to ensure that an LMP communication path between two peers is working properly.
制御チャネルのセットは、同一の暗号チャネルを共有することができます。 LMPハローズは、制御チャネルの状態を監視するために使用されている場合は、制御チャネルでのキープアライブ障害はまた、暗号化チャネルの障害が原因であり得ることを心に留めておくことが重要です。以下の方法は、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.
LMPハローズは、制御チャネル上で障害が検出された場合は、O、代替制御チャネルに切り替え、および/または新しい制御チャネルを確立しよう。
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ハローズを使用して制御チャネルの健全性を確認してください。すべての制御チャネルが障害を示し、新しい制御チャネルを起動することができない場合、すべての既存の制御チャネルを取り壊します。また、暗号チャネル（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.
アグレッシブモードは、サービス攻撃の受動的な拒否の傾向があること、しかし、注意してください。これはのman-in-the-middle攻撃するソリューションを開きますので、ピアの数の間で共有される秘密（グループ共有秘密）を使用することを強くお勧めします。
Digital-signature-based authentication is not prone to such problems. It is RECOMMENDED that a digital-signature-based authentication mechanism be used where possible.
デジタル署名ベースの認証は、このような問題になりやすいではありません。デジタル署名ベースの認証メカニズムを可能な限り使用することを推奨されています。
If pre-shared-key-based authentication is required, then aggressive mode SHOULD be used. IKE pre-shared authentication key values SHOULD be protected in a manner similar to the user's account password.
事前共有キーベースの認証が必要な場合は、アグレッシブモードを使用する必要があります。 IKEの事前共有認証キーの値は、ユーザーのアカウントのパスワードと同様に保護する必要があります。
The IANA has assigned port number 701 to LMP.
IANAは、LMPにポート番号701が割り当てられています。
In the following, guidelines are given for IANA assignment for each LMP name space. Ranges are specified for Private Use, to be assigned by Expert Review, and to be assigned by Standards Action (as defined in [RFC2434].
以下では、ガイドラインは、各LMP名前空間のためのIANAの割り当てのために与えられています。範囲は、専門家レビューによって割り当てられるように、プライベート用に指定されており、標準化アクション（[RFC2434]で定義されているようで割り当てられます。
Assignments made from LMP number spaces set aside for Private Use (i.e., for proprietary extensions) need not be documented. Independent LMP implementations using the same Private Use code points will in general not interoperate, so care should be exercised in using these code points in a multi-vendor network.
（すなわち、独自の拡張用）私的使用のために確保されLMP数のスペースから作られた割り当てを文書化する必要はありません。ケアは、マルチベンダーネットワークでこれらのコード・ポイントを使用して行使されなければならないので、同じプライベート使用のコード・ポイントを使用して独立したLMPの実装は、一般的には、相互運用しません。
Assignments made from LMP number spaces to be assigned by Expert Review are to be reviewed by an Expert designated by the IESG. The intent in this document is that code points from these ranges are used for Experimental extensions; as such, assignments MUST be accompanied by Experimental RFCs. If deployment suggests that these extensions are useful, then they should be described in Standards Track RFCs, and new code points from the Standards Action ranges MUST be assigned.
専門家レビューによって割り当てられるLMP数のスペースから作られた割り当ては、IESGが指定した専門家によって審査されることになります。この文書の目的は、これらの範囲からそのコードポイントは、実験的拡張のために使用されています。など、割り当ては、実験のRFCを添付しなければなりません。展開はこれらの拡張機能が有用であることを示唆している場合、それらは標準化過程RFCで記述する必要があり、標準アクションの範囲から新しいコードポイントが割り当てられなければなりません。
Assignments from LMP number spaces to be assigned by Standards Action MUST be documented by a Standards Track RFC, typically submitted to an IETF Working Group, but in any case following the usual IETF procedures for Proposed Standards.
標準アクションによって割り当てられるLMP数のスペースからの割り当ては、標準化過程RFCで文書化され、通常、IETFワーキンググループに提出しますが、どのような場合に提案された標準のための通常のIETF手順に従ってしなければなりません。
The Reserved bits of the LMP Common Header should be allocated by Standards Action, pursuant to the policies outlined in [RFC2434].
LMP共通ヘッダの予約ビットは、[RFC2434]に概説された方針に基づき、標準アクションによって割り当てなければなりません。
LMP defines the following name spaces that require management:
LMPは、管理を必要とする以下の名前空間を定義します。
- LMP Message Type. - LMP Object Class. - LMP Object Class type (C-Type). These are unique within the Object Class. - LMP Sub-object Class type (Type). These are unique within the Object Class.
- LMPメッセージタイプ。 - LMPオブジェクトクラス。 - LMPオブジェクトクラス型（C型）。これらは、オブジェクトクラス内で一意です。 - LMPサブオブジェクトクラス型（タイプ）。これらは、オブジェクトクラス内で一意です。
The LMP Message Type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-127 are allocated by Standards Action, 128-240 are allocated through an Expert Review, and 241-255 are reserved for Private Use.
次のようにLMPメッセージタイプのネームスペースが割り当てられる必要があります：[RFC2434]に概説された方針に基づきは、0から127の範囲内の数値は標準アクション、128から240によって割り当てられているエキスパートレビューを通じて割り当てられ、241-255されています私的使用のために予約されています。
The LMP Object Class name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range of 0-127 are allocated by Standards Action, 128-247 are allocated through an Expert Review, and 248-255 are reserved for Private Use.
次のようにLMPオブジェクトクラスの名前空間が割り当てられる必要があります：[RFC2434]に概説された方針に基づきは、0〜127の範囲内の数値は標準アクション、128から247によって割り当てられているエキスパートレビューを通じて割り当てられ、248- 255は、私的使用のために予約されています。
The policy for allocating values out of the LMP Object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which the Object Class names are allocated.
LMPオブジェクトクラスの名前空間から値を割り当てるためのポリシーは、特定のクラスインスタンスの定義の一部です。クラスが定義されている場合は、その定義は、オブジェクトのクラス名が割り当てられるの下で政策の説明を含める必要があります。
The policy for allocating values out of the LMP Sub-object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which sub-objects are allocated.
LMPサブオブジェクトクラスの名前空間からの値を割り当てるためのポリシーは、特定のクラスインスタンスの定義の一部です。クラスが定義されている場合、その定義は、サブオブジェクトが割り当てられた下ポリシーの記述を含まなければなりません。
The following name spaces have been assigned by IANA:
次の名前空間はIANAによって割り当てられています：
------------------------------------------------------------------
LMP Message Type name space
o Config message (Message type = 1)
O Configメッセージ（メッセージタイプ= 1）
o ConfigAck message (Message type = 2)
O ConfigAckメッセージ（メッセージタイプ= 2）
o ConfigNack message (Message type = 3)
O ConfigNackメッセージ（メッセージタイプ= 3）
o Hello message (Message type = 4)
Oハローメッセージ（メッセージタイプ= 4）
o BeginVerify message (Message type = 5)
O BeginVerifyメッセージ（メッセージタイプ= 5）
o BeginVerifyAck message (Message type = 6)
O BeginVerifyAckメッセージ（メッセージタイプ= 6）
o BeginVerifyNack message (Message type = 7)
O BeginVerifyNackメッセージ（メッセージタイプ= 7）
o EndVerify message (Message type = 8)
O EndVerifyメッセージ（メッセージタイプ= 8）
o EndVerifyAck message (Message type = 9)
O EndVerifyAckメッセージ（メッセージタイプ= 9）
o Test message (Message type = 10)
O Testメッセージ（メッセージタイプ= 10）
o TestStatusSuccess message (Message type = 11)
Oテスト成功ステータスメッセージ（メッセージタイプ= 11）
o TestStatusFailure message (Message type = 12)
Oテストステータス失敗メッセージ（メッセージタイプ= 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チャネルステータスメッセージ（メッセージタイプ= 17）
o ChannelStatusAck message (Message type = 18)
O ChannelStatusAckメッセージ（メッセージタイプ= 18）
o ChannelStatusRequest message (Message type = 19)
O ChannelStatusRequestメッセージ（メッセージタイプ= 19）
o ChannelStatusResponse message (Message type = 20)
O ChannelStatusResponseメッセージ（メッセージタイプ= 20）
------------------------------------------------------------------
LMP Object Class name space and Class type (C-Type)
LMPオブジェクトクラスの名前空間とクラスタイプ（Cタイプ）
o CCID Class name (1)
CCIDクラス名O（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)
- LOCAL_CCID（Cタイプ= 1） - REMOTE_CCID（Cタイプ= 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)
- LOCAL_NODE_ID（Cタイプ= 1） - REMOTE_NODE_ID（Cタイプ= 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によって割り当てられているエキスパートレビューを通じて割り当てられ、120- 127は、私的使用のために予約されています。
- IPv4 LOCAL_LINK_ID (C-Type = 1) - IPv4 REMOTE_LINK_ID (C-Type = 2) - IPv6 LOCAL_LINK_ID (C-Type = 3) - IPv6 REMOTE_LINK_ID (C-Type = 4) - Unnumbered LOCAL_LINK_ID (C-Type = 5) - Unnumbered REMOTE_LINK_ID (C-Type = 6)
- IPv4のLOCAL_LINK_ID（Cタイプ= 1） - IPv4のREMOTE_LINK_ID（Cタイプ= 2） - IPv6のLOCAL_LINK_ID（Cタイプ= 3） - IPv6のREMOTE_LINK_ID（C-タイプ= 4） - 番号なしLOCAL_LINK_ID（Cタイプ= 5） - 番号なしREMOTE_LINK_ID（Cタイプ= 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)
- IPv4のLOCAL_INTERFACE_ID（Cタイプ= 1） - IPv4のREMOTE_INTERFACE_ID（Cタイプ= 2） - IPv6のLOCAL_INTERFACE_ID（Cタイプ= 3） - IPv6のREMOTE_INTERFACE_ID（C-タイプ= 4） - 番号なしLOCAL_INTERFACE_ID（Cタイプ= 5） - 番号なしREMOTE_INTERFACE_ID（Cタイプ= 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オブジェクトクラス型の名前空間が割り当てられる必要があります：[RFC2434]に概説された方針に基づきは、0から111の範囲内の数値は標準アクション、112-119によって割り当てられているエキスパートレビューを通じて割り当てられ、120- 127は、私的使用のために予約されています。
- MESSAGE_ID (C-Type = 1) - MESSAGE_ID_ACK (C-Type = 2)
- MESSAGE_ID（Cタイプ= 1） - MESSAGE_ID_ACK（Cタイプ= 2）
o CONFIG Class name (6)
O CONFIGクラス名（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.
次のようにCONFIGオブジェクトクラスタイプの名前空間が割り当てられる必要があります：[RFC2434]に概説された方針に基づきは、0から111の範囲内の数値は標準アクション、112-119によって割り当てられているエキスパートレビューを通じて割り当てられ、120- 127は、私的使用のために予約されています。
- HELLO_CONFIG (C-Type = 1)
- HELLO_CONFIG（Cタイプ= 1）
o HELLO Class name (7)
ハローOクラス名（7）
The HELLO Object Class type name space should be allocated as follows: pursuant to the policies outlined in [RFC2434], the numbers in the range 0-111 are allocated by Standards Action, 112-119 are allocated through an Expert Review, and 120-127 are reserved for Private Use.
次のようにHelloオブジェクトクラス型の名前空間が割り当てられる必要があります：[RFC2434]に概説された方針に基づきは、0から111の範囲内の数値は標準アクション、112-119によって割り当てられているエキスパートレビューを通じて割り当てられ、120- 127は、私的使用のために予約されています。
- HELLO (C-Type = 1)
- ハロー（Cタイプ= 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-タイプ= 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によって割り当てられているエキスパートレビューを通じて割り当てられ、120- 127は、私的使用のために予約されています。
- Type 1 (C-Type = 1)
- タイプ1（C-タイプ= 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.
次のようにVERIFY_IDオブジェクトクラスタイプの名前空間が割り当てられる必要があります：[RFC2434]に概説された方針に基づきは、0から111の範囲内の数値は標準アクション、112-119によって割り当てられているエキスパートレビューを通じて割り当てられ、120- 127は、私的使用のために予約されています。
- Type 1 (C-Type = 1)
- タイプ1（C-タイプ= 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によって割り当てられているエキスパートレビューを通じて割り当てられ、120- 127は、私的使用のために予約されています。
- IPv4 TE_LINK (C-Type = 1) - IPv6 TE_LINK (C-Type = 2) - Unnumbered TE_LINK (C-Type = 3)
- IPv4のTE_LINK（Cタイプ= 1） - IPv6のTE_LINK（Cタイプ= 2） - 番号なしTE_LINK（Cタイプ= 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)
- IPv4のDATA_LINK（Cタイプ= 1） - IPv6のDATA_LINK（Cタイプ= 2） - 番号なしDATA_LINK（Cタイプ= 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)
- インタフェース交換型（サブオブジェクトタイプ= 1） - 波長（サブオブジェクトタイプ= 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)
- IPv4のINTERFACE_ID（Cタイプ= 1） - IPv6のINTERFACE_ID（Cタイプ= 2） - 番号なしINTERFACE_ID（Cタイプ= 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によって割り当てられているエキスパートレビューを通じて割り当てられ、120- 127は、私的使用のために予約されています。
- IPv4 INTERFACE_ID (C-Type = 1) - IPv6 INTERFACE_ID (C-Type = 2) - Unnumbered INTERFACE_ID (C-Type = 3)
- IPv4のINTERFACE_ID（Cタイプ= 1） - IPv6のINTERFACE_ID（Cタイプ= 2） - 番号なしINTERFACE_ID（Cタイプ= 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)
- BEGIN_VERIFY_ERROR（Cタイプ= 1） - LINK_SUMMARY_ERROR（Cタイプ= 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.
作者はこのドキュメントへの彼の多くの貢献のためのアンドレFredetteに感謝したいと思います。我々はまた、彼らの洞察に満ちたコメントと提案のためにアヤンバネルジー、ジョージくん、エードリアンファレル、ディミトリPapadimitriou、ビナイRavuri、とDavidドライスデールに感謝したいと思います。また、インバンド制御チャネルの適用のための彼らの役に立つ提案をジョン・ユー、スレシュKatukam、とグレッグバーンスタインに感謝したいと思います。
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101
ジョナサンP.ラングSonosの、株式会社223 E.デ・ラ・ゲラセントサンタバーバラ、CA 93101
EMail: jplang@ieee.org
メールアドレス：jplang@ieee.org
Krishna Mitra Independent Consultant
クリシュナミトラ独立コンサルタント
EMail: kmitra@earthlink.net
メールアドレス：kmitra@earthlink.net
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
ジョン・ドレイクCalientネットワーク5853ルーフェラーリカリフォルニア州サンノゼ95138
EMail: jdrake@calient.net
メールアドレス：jdrake@calient.net
Kireeti Kompella Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
Kireeti Kompellaジュニパーネットワークス株式会社1194北マチルダアベニューサニーベール、CA 94089
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Yakov Rekhter Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
ヤコフ・レックタージュニパーネットワークス株式会社1194北マチルダアベニューサニーベール、CA 94089
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
Lou Berger Movaz Networks
ルー・バーガーMovazネットワーク
EMail: lberger@movaz.com
メールアドレス：lberger@movaz.com
Debanjan Saha IBM Watson Research Center
DebanjanサハIBMワトソン研究所
EMail: dsaha@us.ibm.com
メールアドレス：dsaha@us.ibm.com
Debashis Basak Accelight Networks 70 Abele Road, Suite 1201 Bridgeville, PA 15017-3470
Debashishバスクネットワークesisielaita 70 abele道路、スイート1 1 brijabhilleトウ、足15017から3470
EMail: dbasak@accelight.com
メールアドレス：dbasak@accelight.com
Hal Sandick Shepard M.S. 2401 Dakota Street Durham, NC 27705
ハルSandickシェパードM.S. 2401ダコタ・ストリートダーラム、ノースカロライナ27705
EMail: sandick@nc.rr.com
メールアドレス：sandick@nc.rr.com
Alex Zinin Alcatel
アルカテルアレックス・Z
EMail: alex.zinin@alcatel.com
メールアドレス：alex.zinin@alcatel.com
Bala Rajagopalan Intel Corp. 2111 NE 25th Ave Hillsboro, OR 97123
バラRajagopalanインテル社2111 NE 25日アベニューヒルズボロ、OR 97123
EMail: bala.rajagopalan@intel.com
メールアドレス：bala.rajagopalan@intel.com
Sankar Ramamoorthi Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089
ハイブリッドRammurtiジュニパーネットワークス本。 94089の1194北マチルダAvenuaサニーベール、
EMail: sankarr@juniper.net
メールアドレス：sankarr@juniper.net
Contact Address
連絡先住所
Jonathan P. Lang Sonos, Inc. 829 De La Vina, Suite 220 Santa Barbara, CA 93101
ジョナサンP.ラングSonosの、Inc.の829デ・ラヴィナ、スイート220サンタバーバラ、CA 93101
EMail: jplang@ieee.org
メールアドレス：jplang@ieee.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。