[要約] RFC 4207は、LMPテストメッセージのためのSONET/SDHエンコーディングに関する規格です。このRFCの目的は、LMPを使用してSONET/SDHネットワークでリンクの管理を行うためのエンコーディング方法を提供することです。
Network Working Group J. Lang
Request for Comments: 4207 Sonos, Inc.
Category: Standards Track D. Papadimitriou
Alcatel
October 2005
Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages
同期光学ネットワーク（SONET）/同期デジタル階層（SDH）リンク管理プロトコル（LMP）テストメッセージのエンコード
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document details the Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) technology-specific information needed when sending Link Management Protocol (LMP) test messages.
このドキュメントは、リンク管理プロトコル（LMP）テストメッセージを送信する際に必要な同期光学ネットワーク（SONET）/同期デジタル階層（SDH）技術固有の情報を詳しく説明しています。
For scalability purposes, multiple physical resources that interconnect Label Switching Routers (LSRs) can be combined to form a single traffic engineering (TE) link for the purposes of path computation and signaling. These resources may represent one or more physical links that connect the LSRs, or they may represent a Label Switched Path (LSP) if LSP hierarchy [RFC4206] is used. The management of TE links is not restricted to in-band messaging, but instead can be done using out-of-band techniques.
スケーラビリティのために、パス計算とシグナル伝達を目的として、ラベルスイッチングルーター（LSR）を相互接続する複数の物理リソースを組み合わせて、単一のトラフィックエンジニアリング（TE）リンクを形成できます。これらのリソースは、LSRを接続する1つ以上の物理リンクを表す場合があります。または、LSP階層[RFC4206]が使用される場合、ラベルスイッチドパス（LSP）を表す場合があります。TEリンクの管理は、帯域内のメッセージに限定されていませんが、代わりに帯域外の手法を使用して実行できます。
The Link Management Protocol (LMP) [RFC4204] has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage TE links. LMP currently consists of four main procedures, of which the first two are mandatory and the last two are optional:
リンク管理プロトコル（LMP）[RFC4204]は、TEリンクを管理するための一般化されたMPLS（GMPLS）プロトコルスイートの一部として開発されました。LMPは現在、4つの主要な手順で構成されており、そのうち最初の2つは必須であり、最後の2つはオプションです。
1. Control channel management 2. Link property correlation 3. Link verification 4. Fault management
1. 制御チャネル管理2.リンクプロパティ相関3.リンク検証4.障害管理
Control channel management is used to establish and maintain control channel connectivity between adjacent nodes. This is done using a Config message exchange followed by a lightweight keep-alive message exchange. Link property correlation is used to aggregate multiple data links into a single TE Link and to synchronize the link properties. Link verification is used to verify the physical connectivity of the data links and to exchange the Interface_Ids of the data links. Fault management is primarily used to suppress alarms and to localize failures in both opaque and transparent networks. When LMP is used with SONET/SDH, however, the fault management procedures may not be needed as existing SONET/SDH mechanisms can be used.
制御チャネル管理は、隣接するノード間の制御チャネル接続を確立および維持するために使用されます。これは、構成メッセージ交換に続いて軽量のキープアライブメッセージ交換を使用して行われます。リンクプロパティ相関は、複数のデータリンクを単一のTEリンクに集約し、リンクプロパティを同期するために使用されます。リンク検証は、データリンクの物理的な接続性を検証し、データリンクのinterface_idsを交換するために使用されます。障害管理は、主にアラームを抑制し、不透明なネットワークと透明なネットワークの両方の障害を局在するために使用されます。ただし、LMPをSONET/SDHで使用する場合、既存のSONET/SDHメカニズムを使用できるため、障害管理手順は必要ない場合があります。
In this document, the SONET/SDH technology-specific information for LMP is defined. Specifically, the SONET/SDH test procedures used for link verification and link property correlation are detailed. These procedures include the trace correlation transport mechanism (defined for J0, J1, J2) that supports a separation of the transport and control plane identifiers. The latter procedure requires a new trace monitoring function that is discussed in this document. Once the data links have been verified, they can be grouped to form TE links.
このドキュメントでは、LMPのSONET/SDHテクノロジー固有の情報が定義されています。具体的には、リンク検証とリンクプロパティの相関に使用されるSONET/SDHテスト手順が詳細です。これらの手順には、輸送およびコントロールプレーンの識別子の分離をサポートするトレース相関輸送メカニズム（J0、J1、J2で定義）が含まれます。後者の手順では、このドキュメントで説明する新しいトレース監視機能が必要です。データリンクが検証されると、それらをグループ化してTEリンクを形成できます。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The reader is assumed to be familiar with the terminology in [RFC4204], [G.707], and [T1.105]. The following abbreviations are used in this document:
読者は、[RFC4204]、[G.707]、および[T1.105]の用語に精通していると想定されています。このドキュメントでは、次の略語が使用されています。
CRC-N: Cyclic Redundancy Check-N. DCC: Data communications channel. LOVC: Lower-order virtual container. HOVC: Higher-order virtual container. MS: Multiplex section. MSOH: Multiplex section overhead. POH: Path overhead. RS: Regenerator section. RSOH: Regenerator section overhead. SDH: Synchronous digital hierarchy. SOH: Section overhead.
CRC-N：周期的な冗長性チェック-N。DCC：データ通信チャネル。LOVC：低次の仮想コンテナ。HOVC：高次の仮想コンテナ。MS：マルチプレックスセクション。MSOH：マルチプレックスセクションオーバーヘッド。POH：パスオーバーヘッド。RS：再生者セクション。RSOH：再生器セクションオーバーヘッド。SDH：同期デジタル階層。SOH：セクションオーバーヘッド。
SONET: Synchronous Optical Network. STM(-N): Synchronous Transport Module (-N) (SDH). STS(-N): Synchronous Transport Signal-Level N (SONET). VC-n: Virtual Container-n (SDH). VTn: Virtual Tributary-n (SONET).
SONET：同期光ネットワーク。STM（-N）：同期輸送モジュール（-N）（SDH）。STS（-N）：同期輸送信号レベルN（SONET）。VC-N：仮想コンテナ-N（SDH）。VTN：Virtual Tributary-N（SONET）。
In [RFC4204], a link verification procedure is defined whereby Test messages are transmitted in-band over the data links. This is used for data plane discovery, Interface_Id exchange (Interface_Ids are used in GMPLS signaling, either as port labels [RFC3471] or component link identifiers [RFC4201], depending on the configuration), and physical connectivity verification. Multiple data links can be verified using a single verification procedure; the correlation is done using the Verify_Id that is assigned to the procedure.
[RFC4204]では、テストメッセージがデータリンクを介してバンド内で送信されるリンク検証手順が定義されています。これは、データプレーンの発見、interface_id Exchange（interface_idsは、構成に応じて、ポートラベル[RFC3471]またはコンポーネントリンク識別子[RFC4201]として、GMPLSシグナル伝達で使用されます）および物理接続性の検証です。単一の検証手順を使用して、複数のデータリンクを検証できます。相関は、手順に割り当てられている検証_IDを使用して行われます。
As part of the link verification procedure, a BeginVerify message exchange is used to agree upon parameters for the Test procedure. This can be initiated by sending a BeginVerify message over the control channel. This message includes a BEGIN_VERIFY object that contains a number of fields specifying, among other things, the transmission (bit) rate, encoding type, and transport mechanisms for the Test Messages. If the remote node receives a BeginVerify message and is ready to begin the procedure, it sends a BeginVerifyAck message specifying the desired transport mechanism for the Test messages. The remote node also assigns a Verify_Id to the procedure and includes it in the BeginVerifyAck message.
リンク検証手順の一部として、Test Procedureのパラメーターに合意するために、Begverifyメッセージ交換が使用されます。これは、コントロールチャネルを介してbeginifyメッセージを送信することで開始できます。このメッセージには、テストメッセージの送信（ビット）レート、エンコードタイプ、および輸送メカニズムを指定する多くのフィールドを含むbegin_verifyオブジェクトが含まれます。リモートノードがbeginverifyメッセージを受信し、手順を開始する準備ができている場合、テストメッセージの目的の輸送メカニズムを指定するbeginifyackメッセージを送信します。また、リモートノードは、Perify_idを手順に割り当て、BeginVerifyAckメッセージに含めます。
The transmission rate of the data link over which the Test Messages will be transmitted is represented in IEEE floating-point format using a 32-bit number field and expressed in bytes per second. See [RFC3471] for values defined for SONET/SDH.
テストメッセージが送信されるデータリンクの伝送速度は、32ビット番号フィールドを使用してIEEEフローティングポイント形式で表され、1秒あたりのバイトで表されます。SONET/SDHで定義された値については、[RFC3471]を参照してください。
The encoding type identifies the encoding supported by an interface. The defined encoding is consistent with the LSP Encoding Type as defined in [RFC3471]. For SONET/SDH, this value must equal the value given for "SDH ITU-T G.707/SONET ANSI T1.105".
エンコーディングタイプは、インターフェイスによってサポートされるエンコードを識別します。定義されたエンコードは、[RFC3471]で定義されているLSPエンコードタイプと一致しています。SONET/SDHの場合、この値は「SDH ITU-T G.707/SONET ANSI T1.105」に与えられた値に等しくなければなりません。
The transport mechanism is defined using the Verify Transport Mechanism bit mask. The scope of this bit mask is restricted to the link encoding type. Multiple bits may be set when this field is included in the BeginVerify message; however, only one bit may be set when it is included in the BeginVerifyAck message.
輸送メカニズムは、検証輸送メカニズムビットマスクを使用して定義されます。このビットマスクの範囲は、リンクエンコードタイプに制限されています。このフィールドがBeginVerifyメッセージに含まれている場合、複数のビットが設定される場合があります。ただし、BeginVerifyAckメッセージに含まれている場合、1ビットだけが設定される場合があります。
In the following subsection, the various options for Verify Transport Mechanism are defined when the encoding is SONET/SDH. The trace correlation transport mechanism (defined for J0, J1, J2) supports a separation of the transport and control plane identifiers.
次のサブセクションでは、エンコードがSONET/SDHであるときに、輸送メカニズムを検証するためのさまざまなオプションが定義されます。TRACE相関輸送メカニズム（J0、J1、J2で定義）は、輸送およびコントロールプレーンの識別子の分離をサポートします。
This field is 16 bits in length.
このフィールドの長さは16ビットです。
In this document, the flags for SONET/SDH encoding are defined. Note that all values are defined in network byte order (i.e., big-endian byte order).
このドキュメントでは、SONET/SDHエンコードのフラグが定義されています。すべての値は、ネットワークバイトの順序で定義されていることに注意してください（つまり、ビッグエンディアンバイト順序）。
0x0001: Reserved
0x0001：予約
0x0002 DCCS: Test Message over the Section/RS DCC
0x0002 DCCS：セクションでメッセージをテスト/RS DCC
Capable of transmitting Test Messages using the DCC Section/RS Overhead bytes with bit-oriented High-Level Data Link Control (HDLC) framing format [RFC1662].
ビット指向の高レベルデータリンクコントロール（HDLC）フレーミング形式[RFC1662]を使用して、DCCセクション/RSオーバーヘッドバイトを使用してテストメッセージを送信できます。
The Test Message is sent as defined in [RFC4204].
テストメッセージは、[RFC4204]で定義されているように送信されます。
0x0004 DCCL: Test Message over the Line/MS DCC
0x0004 DCCL：ライン上のテストメッセージ/MS DCC
Capable of transmitting Test Messages using the DCC Line/MS Overhead bytes with bit-oriented HDLC framing format [RFC1662].
ビット指向のHDLCフレーミング形式[RFC1662]を使用して、DCCライン/MSオーバーヘッドバイトを使用してテストメッセージを送信できます。
The Test Message is sent as defined in [RFC4204].
テストメッセージは、[RFC4204]で定義されているように送信されます。
0x0008 J0-trace: J0 Section Trace Correlation
0x0008 J0-Trace：J0セクショントレース相関
Capable of transmitting SONET/SDH Section/RS trace over J0 Section/RS overhead byte as defined in [T1.105] and [G.707].
[T1.105]および[G.707]で定義されているように、J0セクション/RSオーバーヘッドバイトでSONET/SDHセクション/RSトレースを送信できます。
The Test Message is not transmitted using the J0 bytes (i.e., over the data link), but is sent over the control channel and correlated for consistency to the received J0 pattern.
テストメッセージは、J0バイト（つまり、データリンクを介して）を使用して送信されませんが、コントロールチャネルを介して送信され、受信したJ0パターンに一貫性があると相関します。
In order to get the mapping between the Interface_Id over which the J0 Test Message is sent and the J0 pattern sent in-band, the transmitting node must provide the correlation between this pattern and the J0 Test Message. This correlation is done using the TRACE object as defined in Section 4.
J0テストメッセージが送信されるinterface_idとj0パターンがバンド内で送信される間のマッピングを取得するために、送信ノードはこのパターンとJ0テストメッセージとの相関を提供する必要があります。この相関は、セクション4で定義されているトレースオブジェクトを使用して行われます。
The format of the Test Message is as follows:
テストメッセージの形式は次のとおりです。
<Test Message> ::=<Common Header> <LOCAL_INTERFACE_ID>
<VERIFY_ID> <TRACE>
0x0010: Reserved
0x0010：予約
0x0020: Reserved
0x0020：予約済み
0x0040 J1-trace: J1 Path Trace Correlation
0x0040 J1-Trace：J1パストレース相関
Capable of transmitting SONET/SDH STS SPE/HOVC Path trace over J1 Path overhead byte as defined in [T1.105] and [G.707].
[T1.105]および[G.707]で定義されているように、J1パスオーバーヘッドバイトを介してSONET/SDH STS SPE/HOVCパストレースを送信できます。
The Test Message is not transmitted using the J1 bytes (i.e., over the data link), but is sent over the control channel and correlated for consistency to the received J1 pattern.
テストメッセージは、J1バイト（つまり、データリンクを介して）を使用して送信されませんが、コントロールチャネルを介して送信され、受信したJ1パターンに一貫性があると相関します。
In order to get the mapping between the Interface_Id over which the J1 Test Message is sent and the J1 pattern sent in-band, the transmitting node must provide the correlation between this pattern and the J1 Test Message. This correlation is done using the TRACE object as defined in Section 4.
J1テストメッセージが送信されるinterface_idとj1パターンがバンド内で送信される間のマッピングを取得するには、送信ノードはこのパターンとJ1テストメッセージとの相関を提供する必要があります。この相関は、セクション4で定義されているトレースオブジェクトを使用して行われます。
The Test Message format is identical to that defined above in J0-trace.
テストメッセージ形式は、J0-Traceで上記のものと同一です。
0x0080 J2-trace: J2 Path Trace Correlation
0x0080 J2-Trace：J2パストレース相関
Capable of transmitting SONET/SDH VT SPE/LOVC Path trace over J2 Path overhead byte as defined in [T1.105] and [G.707].
[T1.105]および[G.707]で定義されているように、J2パスオーバーヘッドバイトを介してSONET/SDH VT SPE/LOVCパストレースを送信できます。
The Test Message is not transmitted using the J2 bytes (i.e., over the data link), but is sent over the control channel and correlated for consistency to the received J2 pattern.
テストメッセージは、J2バイト（つまり、データリンクを介して）を使用して送信されませんが、コントロールチャネルを介して送信され、受信したJ2パターンに一貫性があると相関します。
In order to get the mapping between the Interface_Id over which the J2 Test Message is sent and the J2 pattern sent in-band, the transmitting node must provide the correlation between this pattern and the J2 Test Message. This correlation is done using the TRACE object as defined in Section 4.
J2テストメッセージが送信されるinterface_idとj2パターンがバンド内で送信される間のマッピングを取得するには、送信ノードはこのパターンとJ2テストメッセージとの相関を提供する必要があります。この相関は、セクション4で定義されているトレースオブジェクトを使用して行われます。
The Test Message format is identical to that defined above in J0-trace.
テストメッセージ形式は、J0-Traceで上記のものと同一です。
The trace monitoring features described in this section allow a node to do trace monitoring by using the SONET/SDH capabilities.
このセクションで説明するトレース監視機能により、ノードはSONET/SDH機能を使用してトレース監視を行うことができます。
o A node may request its neighbor (the remote node) to monitor a link for a specific pattern in the overhead using the TraceMonitor Message. An example of this overhead is the SONET Section Trace message transmitted in the J0 byte. If the actual trace message does not match the expected trace message, the remote node MUST report the mismatch condition.
o ノードは、Tracemonitorメッセージを使用して、オーバーヘッドの特定のパターンのリンクを監視するように近隣（リモートノード）を要求する場合があります。このオーバーヘッドの例は、J0バイトで送信されたSONETセクショントレースメッセージです。実際のトレースメッセージが予想されるトレースメッセージと一致しない場合、リモートノードは不一致条件を報告する必要があります。
o A node may request the value of the current trace message on a given data link using the TraceReq Message.
o ノードは、Tracereqメッセージを使用して、特定のデータリンクに現在のトレースメッセージの値を要求する場合があります。
o A node may request a remote node to send a specific trace message over a data link using the InsertTrace Message.
o ノードは、InsertTraceメッセージを使用して、データリンク上に特定のトレースメッセージを送信するリモートノードを要求する場合があります。
The TraceMonitor message (Message Type 21) is sent over the control channel and is used to request the remote node to monitor a data link for a specific trace value. This value is inserted in the <TRACE> object. The format of the TraceMonitor message is as follows:
Tracemonitorメッセージ（メッセージタイプ21）はコントロールチャネルを介して送信され、特定のトレース値のデータリンクを監視するためにリモートノードを要求するために使用されます。この値は<trace>オブジェクトに挿入されます。tracemonitorメッセージの形式は次のとおりです。
<TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
The above transmission order SHOULD be followed.
上記の送信順序に従う必要があります。
The remote node MUST respond to a TraceMonitor message with either a TraceMonitorAck or TraceMonitorNack Message.
リモートノードは、tracemonitorackまたはtracemonitornackメッセージのいずれかを使用して、tracemonitorメッセージに応答する必要があります。
Class = 21
o C-Type = 1, Trace
o c-type = 1、トレース
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| C-Type | Class | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | Trace Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Trace Message //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trace Type: 16 bits
トレースタイプ：16ビット
The type of the trace message. The following values are defined. All other values are reserved.
トレースメッセージのタイプ。次の値が定義されています。他のすべての値は予約されています。
1 = SONET Section Trace (J0 Byte) 2 = SONET Path Trace (J1 Byte) 3 = SONET Path Trace (J2 Byte) 4 = SDH Section Trace (J0 Byte) 5 = SDH Path Trace (J1 Byte) 6 = SDH Path Trace (J2 Byte)
1 = SONETセクショントレース（J0バイト）2 =ソネットパストレース（J1バイト）3 =ソネットパストレース（J2バイト）4 = SDHセクショントレース（J0バイト）5 = SDHパストレース（J1バイト）6 = SDHパストレース（J2バイト）
Trace Length: 16 bits
トレース長：16ビット
This is the length in bytes of the trace message (as specified by the Trace Type).
これは、トレースメッセージのバイトの長さ（トレースタイプで指定）です。
Trace Message:
トレースメッセージ：
This is the value of the expected message to be received in-band. The valid length and value combinations are determined by the specific technology: for SONET see [T1.105] and for SDH see [G.707]. The message MUST be padded with zeros to a 32-bit boundary, if necessary. Trace Length does not include padding zeroes.
これは、帯域内で受信される予想メッセージの価値です。有効な長さと値の組み合わせは、特定の技術によって決定されます。SONETについては[T1.105]を参照し、SDHについては[G.707]を参照してください。メッセージは、必要に応じて、ゼロを32ビットの境界にパッドで塗布する必要があります。トレースの長さには、パディングゼロが含まれていません。
This object is nonnegotiable.
このオブジェクトは交渉できません。
The TraceMonitorAck message (Message Type 22) is used to acknowledge receipt of the TraceMonitor message and indicate that all of the TRACE Objects in the TraceMonitor message have been received and processed correctly (i.e., no Trace Mismatch).
Tracemonitorackメッセージ（メッセージタイプ22）は、Tracemonitorメッセージの受信を確認するために使用され、Tracemonitorメッセージのすべてのトレースオブジェクトが正しく受信および処理されたことを示します（つまり、トレースミスマッチなし）。
The format is as follows:
フォーマットは次のとおりです。
<TraceMonitorAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The above transmission order SHOULD be followed.
上記の送信順序に従う必要があります。
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TraceMonitor message being acknowledged.
message_id_ackオブジェクトは[rfc4204]で定義されています。Message_id_ackオブジェクトの内容は、確認されているtracemonitorメッセージから取得する必要があります。
The TraceMonitorNack message (Message Type 23) is used to acknowledge receipt of the TraceMonitor message and indicate that the TRACE Object in the TraceMonitor message was not processed correctly. This could be because the trace monitoring requested is not supported or there was an error in the TRACE object value(s).
tracemonitornackメッセージ（メッセージタイプ23）は、tracemonitorメッセージの受信を確認するために使用され、tracemonitorメッセージのトレースオブジェクトが正しく処理されなかったことを示します。これは、要求されたトレース監視がサポートされていないか、トレースオブジェクト値にエラーがあったためかもしれません。
The format is as follows:
フォーマットは次のとおりです。
<TraceMonitorNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The above transmission order SHOULD be followed.
上記の送信順序に従う必要があります。
The MESSAGE_ID_ACK and ERROR_CODE objects are defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TraceMonitor message being acknowledged.
message_id_ack and error_codeオブジェクトは[rfc4204]で定義されています。Message_id_ackオブジェクトの内容は、確認されているtracemonitorメッセージから取得する必要があります。
If the Trace type is not supported, the ERROR_CODE MUST indicate "Unsupported Trace Type" defined in Section 4.1.3.1.
トレースタイプがサポートされていない場合、ERROR_CODEはセクション4.1.3.1で定義されている「サポートされていないトレースタイプ」を示す必要があります。
If the TRACE object was not equal to the value seen in the trace, the TraceMonitorNack message MUST include the ERROR_CODE indicating "Invalid Trace Message". The TraceMismatch message (see Section 4.1.4) SHOULD NOT be sent as a result of the mismatch.
トレースオブジェクトがトレースに表示される値に等しくない場合、Tracemonitornackメッセージには、「無効なトレースメッセージ」を示すERROR_CODEを含める必要があります。TraceMismatchメッセージ（セクション4.1.4を参照）は、不一致の結果として送信されないでください。
The TraceMonitorNack message uses a new ERROR_CODE C-Type defined in Section 4.1.3.1.
Tracemonitornackメッセージは、セクション4.1.3.1で定義された新しいERROR_CODE Cタイプを使用します。
C-Type = 3, TRACE_ERROR
c-type = 3、trace_error
The following new error code bit-values are defined:
次の新しいエラーコードビット値が定義されています。
0x01 = Unsupported Trace Type 0x02 = Invalid Trace Message
0x01 =サポートされていないトレースタイプ0x02 =無効なトレースメッセージ
All other values are Reserved.
他のすべての値は予約されています。
Multiple bits may be set to indicate multiple errors.
複数のビットを設定して、複数のエラーを示すことができます。
This Object is nonnegotiable.
このオブジェクトは交渉できません。
The TraceMismatch message (Message Type 24) is sent over the control channel and is used to report a trace mismatch on a data link for which trace monitoring was requested. The format is as follows:
TraceMismatchメッセージ（メッセージタイプ24）はコントロールチャネルを介して送信され、トレースモニタリングが要求されたデータリンクのトレースミスマッチを報告するために使用されます。フォーマットは次のとおりです。
<TraceMismatch message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID>
[<LOCAL_INTERFACE_ID> ...]
The above transmission order SHOULD be followed.
上記の送信順序に従う必要があります。
A neighboring node that receives a TraceMismatch message MUST respond with a TraceMismatchAck message.
TraceMismatchメッセージを受信する隣接するノードは、tracemismatchackメッセージで応答する必要があります。
The LOCAL_INTERFACE_ID object is defined in [RFC4204]. The LOCAL_INTERFACE_ID in this message is the local Interface Id of the data link that has a trace mismatch. A trace mismatch for multiple LOCAL_INTERFACE_IDs may be reported in the same message.
local_interface_idオブジェクトは[rfc4204]で定義されています。このメッセージのLocal_interface_idは、トレースの不一致を持つデータリンクのローカルインターフェイスIDです。複数のlocal_interface_idsのトレースの不一致は、同じメッセージで報告される場合があります。
The TraceMismatchAck message (Message Type 25) is used to acknowledge receipt of a TraceMismatch message. The format is as follows:
TraceMismatchackメッセージ（メッセージタイプ25）は、TraceMismatchメッセージの受信を確認するために使用されます。フォーマットは次のとおりです。
<TraceMismatchAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TraceMismatch message being acknowledged.
message_id_ackオブジェクトは[rfc4204]で定義されています。Message_id_ackオブジェクトの内容は、確認されているtracemismatchメッセージから取得する必要があります。
The TraceReq message (Message Type 26) is sent over the control channel and is used to request the current trace value of a data link.
Tracereqメッセージ（メッセージタイプ26）はコントロールチャネルを介して送信され、データリンクの現在のトレース値を要求するために使用されます。
<TraceReq Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE_REQ>
The above transmission order SHOULD be followed.
上記の送信順序に従う必要があります。
The format of the TRACE_REQ object is as follows:
TRACE_REQオブジェクトの形式は次のとおりです。
Class = 22
O C-Type = 1, TraceReq
o c-type = 1、tracereq
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Trace Type | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Trace Type: 16 bits
トレースタイプ：16ビット
Defined in Section 4.1.1.1.
セクション4.1.1.1で定義されています。
Reserved: 16 bits
予約済み：16ビット
This field MUST be set to zero when sent and ignored when received
このフィールドは、送信時にゼロに設定し、受け取ったときに無視する必要があります
The TraceReport message (Message Type 27) is sent over the control channel after receiving a TraceReq message.
Tracereportメッセージ（メッセージタイプ27）は、Tracereqメッセージを受信した後、コントロールチャネル上で送信されます。
<TraceReport Message> ::= <Common Header> <MESSAGE_ID_ACK> <TRACE>
The TraceReport message MUST include a TRACE Object (as described in Section 4.1.1.1) for the requested data link.
TRACEREPORTメッセージには、要求されたデータリンクのトレースオブジェクト（セクション4.1.1.1で説明されている）を含める必要があります。
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TraceReq message being acknowledged.
message_id_ackオブジェクトは[rfc4204]で定義されています。Message_id_ackオブジェクトの内容は、確認されているtracereqメッセージから取得する必要があります。
The TraceReqNack message (Message Type 28) is sent over the control channel after receiving a TraceReq message.
tracereqnackメッセージ（メッセージタイプ28）は、tracereqメッセージを受信した後、コントロールチャネル上で送信されます。
<TraceReqNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The above transmission order SHOULD be followed.
上記の送信順序に従う必要があります。
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the TraceReq message being acknowledged.
message_id_ackオブジェクトは[rfc4204]で定義されています。Message_id_ackオブジェクトの内容は、確認されているtracereqメッセージから取得する必要があります。
The TraceReqNack message MUST include an ERROR_CODE Object (as defined in Section 4.1.3.1) for the requested data link.
Tracereqnackメッセージには、要求されたデータリンクのERROR_CODEオブジェクト（セクション4.1.3.1で定義されている）を含める必要があります。
The InsertTrace message (Message Type 29) is sent over the control channel and is used to request a remote node to send a specific trace message over a data link (this assumes that the remote knows the mapping between the local and remote interface_Ids before fulfilling such request).
InsertTraceメッセージ（メッセージタイプ29）はコントロールチャネルを介して送信され、リモートノードを要求してデータリンクを介して特定のトレースメッセージを送信するために使用されます（これは、リモートがそのようなことを満たす前にローカルとリモートのインターフェイス_IDのマッピングを知っていることを前提としていますリクエスト）。
The format is as follows:
フォーマットは次のとおりです。
<InsertTrace Message> ::= <Common Header> <MESSAGE_ID>
<LOCAL_INTERFACE_ID> <TRACE>
The above transmission order SHOULD be followed.
上記の送信順序に従う必要があります。
A node that receives an InsertTrace message MUST respond with either an InsertTraceAck or an InsertTraceNack Message.
InsertTraceメッセージを受信するノードは、InsertTraceAckまたはINSERTTRACENACKメッセージのいずれかで応答する必要があります。
Once the InsertTraceAck message is received, the TraceMismatch message (see Section 4.1.4) is used to indicate a trace mismatch has occurred.
InsertTraceAckメッセージが受信されると、TraceMismatchメッセージ（セクション4.1.4を参照）を使用して、トレースの不一致が発生したことを示します。
The MESSAGE_ID_object is defined in [RFC4204].
message_id_objectは[RFC4204]で定義されています。
The InsertTraceAck message (Message Type 30) is used to acknowledge receipt of the InsertTrace message and indicate that the TRACE Object in the InsertTrace message has been received and processed correctly (i.e., no Trace Mismatch). The format is as follows:
INSTERTRACEACKメッセージ（メッセージタイプ30）は、InsertTraceメッセージの受信を確認するために使用され、InsertTraceメッセージのトレースオブジェクトが正しく受信および処理されたことを示します（つまり、トレースミスマッチなし）。フォーマットは次のとおりです。
<InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK>
The MESSAGE_ID_ACK object is defined in [RFC4204]. The contents of the MESSAGE_ID_ACK object MUST be obtained from the InsertTrace message being acknowledged.
message_id_ackオブジェクトは[rfc4204]で定義されています。Message_id_ackオブジェクトの内容は、確認されているInsertTraceメッセージから取得する必要があります。
The InsertTraceNack message (Message Type 31) is used to acknowledge receipt of the InsertTrace message and to indicate that the TRACE Object in the InsertTrace message was not processed correctly. This could be because the trace monitoring requested is not supported or there was an error in the value.
INSERTTRACENACKメッセージ（メッセージタイプ31）は、InsertTraceメッセージの受信を確認し、InsertTraceメッセージのトレースオブジェクトが正しく処理されていないことを示すために使用されます。これは、要求されたトレースモニタリングがサポートされていないか、値にエラーがあったためかもしれません。
The format is as follows:
フォーマットは次のとおりです。
<InsertTraceNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
<ERROR_CODE>
The above transmission order SHOULD be followed.
上記の送信順序に従う必要があります。
The MESSAGE_ID_ACK object is defined in [RFC4204].
message_id_ackオブジェクトは[rfc4204]で定義されています。
The InsertTraceNack message MUST include an ERROR_CODE Object (as defined in Section 4.1.3.1) for the requested data link.
InsertTraceNackメッセージには、要求されたデータリンクのERROR_CODEオブジェクト（セクション4.1.3.1で定義されている）を含める必要があります。
LMP message security uses IPsec as described in [RFC4204]. This document introduces no other new security considerations not covered in [RFC4204].
LMPメッセージセキュリティは、[RFC4204]で説明されているようにIPSECを使用します。このドキュメントでは、[RFC4204]でカバーされていない他の新しいセキュリティ上の考慮事項は紹介されていません。
LMP [RFC4204] defines the following name spaces and how IANA can make assignments in those namespaces:
LMP [RFC4204]は、次の名前スペースと、IANAがそれらの名前空間で割り当てを行う方法を定義します。
- LMP Message Type. - LMP Object Class. - LMP Object Class type (C-Type) unique within the Object Class. - LMP Sub-object Class type (Type) unique within the Object Class.
- LMPメッセージタイプ。-LMPオブジェクトクラス。-LMPオブジェクトクラスタイプ（Cタイプ）オブジェクトクラス内で一意。-LMPサブオブジェクトクラスタイプ（タイプ）オブジェクトクラス内で一意。
This memo introduces the following new assignments:
このメモでは、次の新しい課題を紹介します。
LMP Message Type:
LMPメッセージタイプ：
o TraceMonitor message (Message type = 21) o TraceMonitorAck message (Message type = 22) o TraceMonitorNack message (Message type = 23) o TraceMismatch message (Message type = 24) o TraceMismatchAck message (Message type = 25)
o tracemonitorメッセージ（メッセージタイプ= 21）o tracemonitorackメッセージ（メッセージタイプ= 22）o tracemonitornackメッセージ（メッセージタイプ= 23）o tracemismatch message（メッセージタイプ= 24）o tracemismatchackメッセージ（メッセージタイプ= 25）
o TraceReq message (Message type = 26) o TraceReport message (Message type = 27) o TraceReqNack message (Message type = 28)
o tracereqメッセージ（メッセージタイプ= 26）o tracereportメッセージ（メッセージタイプ= 27）o tracereqnackメッセージ（メッセージタイプ= 28）
o InsertTrace message (Message type = 29) o InsertTraceAck message (Message type = 30) o InsertTraceNack message (Message type = 31)
o 挿入traceメッセージ（メッセージタイプ= 29）o挿入traceAckメッセージ（メッセージタイプ= 30）o挿入tracenackメッセージ（メッセージタイプ= 31）
LMP Object Class name space and Class type (C-Type):
LMPオブジェクトクラス名スペースとクラスタイプ（Cタイプ）：
o TRACE Class name (21) - Type 1 (C-Type = 1)
o トレースクラス名（21） - タイプ1（Cタイプ= 1）
o TRACE REQ Class name (22) - Type 1 (C-Type = 1)
o TRACE REQクラス名（22） - タイプ1（Cタイプ= 1）
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y.、およびL. Berger、「MPLS Traffic Engineering（TE）のリンクバンドリング」、RFC 4201、2005年10月。
[G.707] ITU-T Recommendation G.707, "Network node interface for the synchronous digital hierarchy (SDH)," October 2000.
[G.707] ITU-T推奨G.707、「同期デジタル階層のネットワークノードインターフェイス（SDH）」、2000年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662]シンプソン、W。、「HDLCのようなフレーミングのPPP」、STD 51、RFC 1662、1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[T1.105] T1.105, "Revised Draft T105 SONET Base Standard," January 2001.
[T1.105] T1.105、「改訂されたDraft T105 Sonet Base Standard」、2001年1月。
[RFC4206] Kompella, K., and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。、およびY. Rekhter、「ラベルスイッチドパス（LSP）階層を備えた一般化マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）」、RFC 4206、2005年10月。
The authors would like to thank Bernard Sales, Emmanuel Desmet, Gert Grammel, Jim Jones, Stefan Ansorge, John Drake, and James Scott for their many contributions to this document.
著者は、この文書への多くの貢献について、バーナードセールス、エマニュエルデスメット、ゲルトグラメル、ジムジョーンズ、ステファンアンソージ、ジョンドレイク、ジェームズスコットに感謝したいと思います。
We would also like to thank Greg Bernstein and Michiel van Everdingen for their insightful comments and for acting with a strong combination of toughness, professionalism, and courtesy.
また、Greg BernsteinとMichiel Van Everdingenの洞察に満ちたコメントと、タフネス、プロフェッショナリズム、礼儀の強力な組み合わせで行動してくれたことにも感謝します。
Authors' Addresses
著者のアドレス
Jonathan P. Lang Sonos, Inc. 223 E. De La Guerra St. Santa Barbara, CA 93101
Jonathan P. Lang Sonos、Inc。223 E. de la Guerra St. Santa Barbara、CA 93101
EMail: jplang@ieee.org
Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen、ベルギー
EMail: dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。