RFC 4207 - Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) Encoding for Link Management Protocol (LMP) Test Messages 日本語訳

URL : https://tools.ietf.org/html/rfc4207
タイトル : RFC 4207 - 同期光ネットワーク（SONET）/同期デジタル階層（SDH）リンク管理プロトコル（LMP）のエンコードテストメッセージ
翻訳編集 : 自動生成

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（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）技術固有の情報を詳しく説明しています。

1. Introduction

1. はじめに

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つの主要な手順で構成されています。

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.

制御チャネル管理は、隣接ノード間の制御チャネル接続を確立し、維持するために使用されます。これは、軽量のキープアライブメッセージ交換に続いてConfigメッセージ交換を使用して行われます。リンクプロパティの相関は、単一の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リンクを形成するためにグループ化することができます。

2. Terminology

2.用語

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 [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：仮想トリビュタリ-N（SONET）。

3. Verifying Link Connectivity

3.確認リンク接続

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交換に使用される（Interface_IdsはGMPLSシグナリングに使用される、いずれかのポートラベル[RFC3471]またはコンポーネントリンク識別子[RFC4201]として、構成に応じて）、および物理的な接続性検証。複数のデータリンクは、単一の検証手順を使用して検証することができます。相関は手続きに割り当てられているVerify_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.

リンク検証手順の一部として、BeginVerifyメッセージ交換は、試験手順のパラメータに合意するために使用されます。これは、制御チャネルを介してBeginVerifyメッセージを送信することにより開始することができます。このメッセージは、とりわけ、特定のフィールドの数、テストメッセージの送信（ビット）レート、符号化タイプ、およびトランスポート機構を含んBEGIN_VERIFYオブジェクトを含みます。リモートノードがBeginVerifyメッセージを受信し、手順を開始する準備ができている場合には、テストメッセージのための所望のトランスポート機構を指定BeginVerifyAckメッセージを送信します。リモートノードはまた、プロシージャにVerify_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浮動小数点形式で表現し、秒あたりのバイト数で表現されます。 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である場合、以下のサブセクションでは、トランスポート機構を確認するためのさまざまなオプションが定義されています。（J0、J1、J2に対して定義された）トレース相関搬送機構は、搬送および制御プレーン識別子の分離をサポートします。

3.1. Verify Transport Mechanism

3.1. トランスポート機構を確認してください

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

0×0002 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].

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].

The Test Message is sent as defined in [RFC4204].

[RFC4204]で定義されるようにテストメッセージが送信されます。

0x0008 J0-trace: J0 Section Trace Correlation

0x0008でJ0トレース：J0セクショントレースの相関関係

                Capable of transmitting SONET/SDH Section/RS trace over
                J0 Section/RS overhead byte as defined in [T1.105] and
                [G.707].

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トレース：J1パストレースの相関関係

                Capable of transmitting SONET/SDH STS SPE/HOVC Path
                trace over J1 Path overhead byte as defined in [T1.105]
                and [G.707].

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トレースに上記で定義されたものと同一です。

0x0080 J2-trace: J2 Path Trace Correlation

0x0080 J2-トレース：J2パストレースの相関関係

                Capable of transmitting SONET/SDH VT SPE/LOVC Path trace
                over J2 Path overhead byte as defined in [T1.105] and
                [G.707].

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トレースに上記で定義されたものと同一です。

4. Trace Monitoring

4.トレースモニタリング

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メッセージを使用して、データリンクを介して特定のトレース・メッセージを送信するリモートノードに要求することができます。

4.1.1. TraceMonitor Message

4.1.1. TraceMonitorメッセージ

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メッセージに応答しなければなりません。

4.1.1.1. TRACE Object Class

4.1.1.1。 TRACEオブジェクトクラス

Class = 21

クラス= 21

o C-Type = 1, Trace

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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |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 = SONETパストレース（J1バイト）3 = SONETパストレース（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.

This object is nonnegotiable.

このオブジェクトは譲れないです。

4.1.2. TraceMonitorAck Message

4.1.2. TraceMonitorAckメッセージ

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メッセージから得なければなりません。

4.1.3. TraceMonitorNack Message

4.1.3. TraceMonitorNackメッセージ

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メッセージでTRACEオブジェクトが正しく処理されなかったことを示しています。トレースモニタリングがサポートされていない要求またはTRACEオブジェクトの値（複数可）に誤りがあったので、これは可能性があります。

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と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.

TRACEオブジェクトがトレースに見られる値に等しくなかった場合、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型を使用しています。

4.1.3.1. ERROR_CODE Class

4.1.3.1。 ERROR_CODEクラス

C-Type = 3, TRACE_ERROR

Cタイプ= 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.

このオブジェクトは譲れないです。

4.1.4. TraceMismatch Message

4.1.4. TraceMismatchメッセージ

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のトレースの不一致が同じメッセージで報告することができます。

4.1.5. TraceMismatchAck Message

4.1.5. TraceMismatchAckメッセージ

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メッセージから得なければなりません。

4.1.6. TraceReq Message

4.1.6. TraceReqメッセージ

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

クラス= 22

O C-Type = 1, TraceReq

O Cタイプ= 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

4.1.7. TraceReport Message

4.1.7. TraceReportメッセージ

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.

（セクション4.1.1.1に記載されているように）TraceReportメッセージは、要求されたデータリンクのトレースオブジェクトを含まなければなりません。

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メッセージから得なければなりません。

4.1.8. TraceReqNack Message

4.1.8. TraceReqNackメッセージ

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メッセージは、要求されたデータリンクのために（セクション4.1.3.1で定義されるように）ERROR_CODEオブジェクトを含まなければなりません。

4.1.9. InsertTrace Message

4.1.9. InsertTraceメッセージ

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）は、制御チャネルを介して送信され、データリンクを介して特定のトレース・メッセージを送信するリモートノードを要求するために使用される（これは、リモートような果たす前に、ローカルおよびリモートinterface_Ids間のマッピングを知っていることを前提としてい要求）。

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]で定義されています。

4.1.10. InsertTraceAck Message

4.1.10. InsertTraceAckメッセージ

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:

InsertTraceAckメッセージ（メッセージタイプ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メッセージから得なければなりません。

4.1.11. InsertTraceNack Message

4.1.11. InsertTraceNackメッセージ

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メッセージは、要求されたデータリンクのために（セクション4.1.3.1で定義されるように）ERROR_CODEオブジェクトを含まなければなりません。

5. Security Considerations

5.セキュリティについての考慮事項

LMP message security uses IPsec as described in [RFC4204]. This document introduces no other new security considerations not covered in [RFC4204].

[RFC4204]に記載されているようにLMPメッセージのセキュリティは、IPsecを使用します。この文書では、[RFC4204]に記載されていない他の新しいセキュリティ問題も紹介しません。

6. IANA Considerations

6. IANAの考慮事項

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メッセージ（メッセージタイプ= 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 InsertTraceメッセージ（メッセージタイプ= 29）O InsertTraceAckメッセージ（メッセージタイプ= 30）O InsertTraceNackメッセージ（メッセージタイプ= 31）

LMP Object Class name space and Class type (C-Type):

LMPオブジェクトクラスの名前空間とクラスタイプ（Cタイプ）：

o TRACE Class name (21) - Type 1 (C-Type = 1)

O TRACEクラス名（21） - タイプ1（C-タイプ= 1）

o TRACE REQ Class name (22) - Type 1 (C-Type = 1)

OトレースREQクラス名（22） - タイプ1（C-タイプ= 1）

7. References

7.参考

7.1. Normative References

7.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.バーガー、 "MPLSでのリンクバンドルトラフィックエンジニアリング（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]ラング、J.、エド。、 "リンク管理プロトコル（LMP）"、RFC 4204、2005年10月。

[RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.

"HDLC様のフレーミングにおけるPPP" [RFC1662]シンプソン、W.、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.

[RFC3471]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。

[T1.105] T1.105, "Revised Draft T105 SONET Base Standard," January 2001.

[T1.105] T1.105、 "改正案T105 SONETベース規格、" 2001年1月。

7.2. Informative References

7.2. 参考文献

[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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。

8. Acknowledgements

8.謝辞

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.

作者はこのドキュメントへの多くの貢献のためにバーナード・販売、エマニュエルDesmet、ゲルトGrammel、ジム・ジョーンズ、ステファンAnsorge、ジョン・ドレイク、とジェームズ・スコットに感謝したいと思います。

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.

我々はまた、彼らの洞察に満ちたコメントをし、靭性、プロフェッショナリズム、および礼儀の強力な組み合わせで作用するグレッグ・バーンスタインとミシェルバンEverdingenに感謝したいと思います。

Authors' Addresses

著者のアドレス

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

Dimitri Papadimitriou Alcatel Francis Wellesplein 1 B-2018 Antwerpen, Belgium

ディミトリスPapadimitriouアルカテルフランシスVellesplein 1 B-2018アントワープ、Velgiom

EMail: dimitri.papadimitriou@alcatel.be

メールアドレス：dimitri.papadimitriou@alcatel.be

Full Copyright Statement

完全な著作権声明

著作権（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機能のための基金は現在、インターネット協会によって提供されます。