RFC4207 日本語訳

Network Working Group                                            J. Lang
Request for Comments: 4207                                   Sonos, Inc.
Category: Standards Track                               D. Papadimitriou
                                                                 Alcatel
                                                            October 2005

コメントを求めるワーキンググループJ.ラング要求をネットワークでつないでください: 4207年のSonos Inc.カテゴリ: 標準化過程D.Papadimitriouアルカテル2005年10月

Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH)
       Encoding for Link Management Protocol (LMP) Test Messages

リンク管理プロトコル(LMP)のためにテストメッセージをコード化する同期式光通信網(Sonet)/同期デジタルハイアラーキ(SDH)

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはLink Managementプロトコル(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.

スケーラビリティ目的において、経路計算とシグナリングの目的のためにただ一つの交通工学(TE)リンクを形成するためにLabel Switching Routers(LSRs)とインタコネクトする複数の物理資源は結合できます。 これらのリソースがLSRsを接続する1個以上の物理的なリンクを表すかもしれませんか、またはLSP階層構造[RFC4206]が使用されているなら、彼らはLabel Switched Path(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:

TEリンクを管理するためにGeneralized MPLS(GMPLS)プロトコル群の一部としてLink Managementプロトコル(LMP)[RFC4204]を開発してあります。 LMPは現在、4つの主手続きから成ります:(そこでは、最初の2が義務的であり、最後の2は任意です)。

Lang & Papadimitriou        Standards Track                     [Page 1]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[1ページ]RFC4207Sonet/SDH

      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 Linkへの複数のデータ・リンクに集めて、リンクの特性を同期させるのに使用されます。 リンク検証は、データ・リンクの物理的な接続性について確かめて、データ・リンクの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のためのSDH技術Sonet/特殊情報は定義されます。 明確に、リンク検証とリンク特性の相関関係に用いられた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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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: 高次な仮想のコンテナ。 さん: セクションを多重送信してください。 MSOH: セクションオーバーヘッドを多重送信してください。 POH: 経路オーバーヘッド。 RS: 再生器部。 RSOH: 再生器セクションオーバーヘッド。 SDH: 同期デジタル階層構造。 SOH: セクションオーバーヘッド。

Lang & Papadimitriou        Standards Track                     [Page 2]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[2ページ]RFC4207Sonet/SDH

   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)。 通り(-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]では、Testメッセージが伝えられたデータの上のバンドのリンクであるリンク検証手続は定義されます。 これはデータ飛行機発見、Interface_Id交換(インタフェース_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交換処理は、Test手順のためのパラメタに同意するのに使用されます。 制御チャンネルの上にBeginVerifyメッセージを送ることによって、これを開始できます。 このメッセージは特に指定する多くの分野を含むBEGIN_VERIFYオブジェクトを含んでいます、トランスミッション(噛み付かれる)率、Test Messagesのためにタイプ、および移送機構をコード化して。 遠隔ノードがBeginVerifyメッセージを受け取って、手順を始める準備ができているなら、それで、BeginVerifyAckメッセージはTestメッセージに必要な移送機構を指定します。 遠隔ノードは、また、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.

Test Messagesが伝えられるデータ・リンクの通信速度は、IEEEの浮動小数点の形式で32ビットのナンバーフィールドを使用することで表されて、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 Encoding Typeと一致しています。 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.

移送機構は、Verify Transport Mechanismビットマスクを使用することで定義されます。 この噛み付いているマスクの範囲はタイプをコード化するリンクに制限されます。 この分野がBeginVerifyメッセージに含まれているとき、複数のビットが設定されるかもしれません。 しかしながら、それがBeginVerifyAckメッセージに含まれているとき、1ビットだけを設定してもよいです。

Lang & Papadimitriou        Standards Track                     [Page 3]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[3ページ]RFC4207Sonet/SDH

   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であるときに、Verify Transport Mechanismに、様々なオプションは定義されます。 跡の相関関係移送機構(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

0×0001: 予約されます。

        0x0002 DCCS: Test Message over the Section/RS DCC

0×0002DCCS: セクション/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].

ビット指向のHigh-レベルData Link Control(HDLC)が形式[RFC1662]を縁どっていて、DCCセクション/RS Overheadバイトを使用することでTest Messagesを伝えることができます。

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

[RFC4204]で定義されるようにTest Messageを送ります。

        0x0004 DCCL: Test Message over the Line/MS DCC

0×0004DCCL: 線/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 Overheadバイトを使用することでTest Messagesを伝えることができます。

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

[RFC4204]で定義されるようにTest Messageを送ります。

        0x0008 J0-trace: J0 Section Trace Correlation

0×0008 J0-跡: 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]で定義されるようにSonet/SDHセクション/RS跡をJ0セクション/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.

Test Messageは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 Test Messageが送られるInterface_Idと送られたJ0パターンの間のマッピングをバンドに得るために、伝えるノードはこのパターンとJ0 Test Messageの間に相関関係を供給しなければなりません。 この相関関係はセクション4で定義されるようにTRACEオブジェクトを使用し終わっています。

Lang & Papadimitriou        Standards Track                     [Page 4]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[4ページ]RFC4207Sonet/SDH

                The format of the Test Message is as follows:

Test Messageの形式は以下の通りです:

                <Test Message> ::=<Common Header> <LOCAL_INTERFACE_ID>
                <VERIFY_ID> <TRACE>

<テストメッセージ>:、:=一般的な<のヘッダー><ローカルの_インタフェース_ID><は_ID><跡の>について確かめます。

        0x0010:  Reserved

0×0010: 予約されます。

        0x0020:  Reserved

0×0020: 予約されます。

        0x0040 J1-trace: J1 Path Trace Correlation

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

[T1.105]と[G.707]で定義されるようにSonet/SDH STS SPE/HOVC Path跡をJ1 Pathオーバーヘッドバイトの上に伝えることができます。

                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.

Test Messageは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 Test Messageが送られるInterface_Idと送られたJ1パターンの間のマッピングをバンドに得るために、伝えるノードはこのパターンとJ1 Test Messageの間に相関関係を供給しなければなりません。 この相関関係はセクション4で定義されるようにTRACEオブジェクトを使用し終わっています。

                The Test Message format is identical to that defined
                above in J0-trace.

Test Message形式はJ0-跡で上で定義されたそれと同じです。

        0x0080 J2-trace: J2 Path Trace Correlation

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

[T1.105]と[G.707]で定義されるようにSonet/SDH VT SPE/LOVC Path跡をJ2 Pathオーバーヘッドバイトの上に伝えることができます。

                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.

Test Messageは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 Test Messageが送られるInterface_Idと送られたJ2パターンの間のマッピングをバンドに得るために、伝えるノードはこのパターンとJ2 Test Messageの間に相関関係を供給しなければなりません。 この相関関係はセクション4で定義されるようにTRACEオブジェクトを使用し終わっています。

Lang & Papadimitriou        Standards Track                     [Page 5]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[5ページ]RFC4207Sonet/SDH

                The Test Message format is identical to that defined
                above in J0-trace.

Test Message形式は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 Messageを使用することでリンクをモニターするよう隣人(遠隔ノード)に要求するかもしれません。 このオーバーヘッドに関する例はJ0バイトで送られたSonetセクションTraceメッセージです。 実際の跡のメッセージが予想された跡のメッセージに合っていないなら、遠隔ノードはミスマッチ状態を報告しなければなりません。

     o   A node may request the value of the current trace message on a
         given data link using the TraceReq Message.

o ノードは、TraceReq Messageを使用することで与えられたデータ・リンクに関する現在の跡のメッセージの値を要求するかもしれません。

     o   A node may request a remote node to send a specific trace
         message over a data link using the InsertTrace Message.

o ノードは、InsertTrace Messageを使用することで特定の跡のメッセージをデータ・リンクの上に送るよう遠隔ノードに要求するかもしれません。

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メッセージ(メッセージType21)は、制御チャンネルの上に送られて、特定の跡の値のためにデータ・リンクをモニターするよう遠隔ノードに要求するのに使用されます。 この値は<TRACE>オブジェクトに挿入されます。 TraceMonitorメッセージの形式は以下の通りです:

   <TraceMonitor Message> ::= <Common Header> <MESSAGE_ID>
                              <LOCAL_INTERFACE_ID> <TRACE>

<TraceMonitorメッセージ>:、:= 一般的な<の地方の_インタフェース_ID><ヘッダー><メッセージ_ID><跡の>。

   The above transmission order SHOULD be followed.

上のトランスミッションはSHOULDを注文します。続かれています。

   The remote node MUST respond to a TraceMonitor message with either a
   TraceMonitorAck or TraceMonitorNack Message.

遠隔ノードはTraceMonitorAckかTraceMonitorNack Messageのどちらかと共にTraceMonitorメッセージに応じなければなりません。

Lang & Papadimitriou        Standards Track                     [Page 6]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[6ページ]RFC4207Sonet/SDH

4.1.1.1.  TRACE Object Class

4.1.1.1. 跡のオブジェクトのクラス

   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                       //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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-タイプ| クラス| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 跡のタイプ| 跡の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //跡のメッセージ//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 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ビットの境界にメッセージを水増ししなければなりません。 跡のLengthは、ゼロを水増しするのを含んでいません。

   This object is nonnegotiable.

このオブジェクトは譲渡不能です。

Lang & Papadimitriou        Standards Track                     [Page 7]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[7ページ]RFC4207Sonet/SDH

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メッセージ(メッセージType22)は、TraceMonitorメッセージの領収書を受け取ったことを知らせて、正しさ(すなわち、Trace Mismatchがない)にTraceMonitorメッセージのTRACE Objectsのすべてを受け取られて、処理してあるのを示すのに使用されます。

   The format is as follows:

形式は以下の通りです:

   <TraceMonitorAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

<TraceMonitorAckメッセージ>:、:= _<の一般的なヘッダー><メッセージ_ID ACK>。

   The above transmission order SHOULD be followed.

上のトランスミッションはSHOULDを注文します。続かれています。

   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]で定義されます。 承認されていて、TraceMonitorメッセージからMESSAGE_ID_ACKオブジェクトのコンテンツを得なければなりません。

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メッセージ(メッセージType23)は、TraceMonitorメッセージの領収書を受け取ったことを知らせて、TraceMonitorメッセージのTRACE Objectが正しく処理されなかったのを示すのに使用されます。 これはモニターが要求した跡がサポートされなかったか、またはTRACEオブジェクト価値には誤りがあったからであるかもしれません。

   The format is as follows:

形式は以下の通りです:

   <TraceMonitorNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
                                  <ERROR_CODE>

<TraceMonitorNackメッセージ>:、:= _<の一般的なヘッダー><メッセージ_ID ACK><誤り_コード>。

   The above transmission order SHOULD be followed.

上のトランスミッションはSHOULDを注文します。続かれています。

   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]で定義されます。 承認されていて、TraceMonitorメッセージからMESSAGE_ID_ACKオブジェクトのコンテンツを得なければなりません。

   If the Trace type is not supported, the ERROR_CODE MUST indicate
   "Unsupported Trace Type" defined in Section 4.1.3.1.

Traceタイプがサポートされないなら、ERROR_CODE MUSTはセクション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)SHOULD NOTがミスマッチの結果、送られるのを見てください。

   The TraceMonitorNack message uses a new ERROR_CODE C-Type defined in
   Section 4.1.3.1.

TraceMonitorNackメッセージはセクション4.1.3で定義された新しいERROR_CODE C-タイプ.1を使用します。

Lang & Papadimitriou        Standards Track                     [Page 8]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[8ページ]RFC4207Sonet/SDH

4.1.3.1.  ERROR_CODE Class

4.1.3.1. 誤り_コードのクラス

   C-Type = 3, TRACE_ERROR

C-タイプは3、跡_誤りと等しいです。

   The following new error code bit-values are defined:

以下の新しいエラーコードビット値は定義されます:

   0x01 = Unsupported Trace Type
   0x02 = Invalid Trace Message

0×01 = サポートされない跡のタイプ0x02は無効の跡のメッセージと等しいです。

   All other values are Reserved.

他のすべての値がReservedです。

   Multiple bits may be set to indicate multiple errors.

複数のビットが複数の誤りを示すように設定されるかもしれません。

   This Object is nonnegotiable.

このObjectは譲渡不能です。

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メッセージ(メッセージType24)は、制御チャンネルの上に送られて、跡のモニターが要求されたデータ・リンクに関して跡のミスマッチを報告するのに使用されます。 形式は以下の通りです:

   <TraceMismatch message> ::= <Common Header> <MESSAGE_ID>
                               <LOCAL_INTERFACE_ID>
                               [<LOCAL_INTERFACE_ID> ...]

<TraceMismatchメッセージ>:、:= 一般的な<のメッセージ_ID><ローカルの_ヘッダー><インタフェース_ID>。[<のローカルの_インタフェース_ID>]

   The above transmission order SHOULD be followed.

上のトランスミッションはSHOULDを注文します。続かれています。

   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は跡のミスマッチを持っているデータ・リンクの地方のInterface Idです。 複数のLOCAL_INTERFACE_IDのための跡のミスマッチは同じメッセージで報告されるかもしれません。

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メッセージ(メッセージType25)は、TraceMismatchメッセージの領収書を受け取ったことを知らせるのに使用されます。 形式は以下の通りです:

   <TraceMismatchAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

<TraceMismatchAckメッセージ>:、:= _<の一般的なヘッダー><メッセージ_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]で定義されます。 承認されていて、TraceMismatchメッセージからMESSAGE_ID_ACKオブジェクトのコンテンツを得なければなりません。

Lang & Papadimitriou        Standards Track                     [Page 9]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[9ページ]RFC4207Sonet/SDH

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メッセージ(メッセージType26)は、制御チャンネルの上に送られて、データ・リンクの現在の跡の値を要求するのに使用されます。

   <TraceReq Message> ::= <Common Header> <MESSAGE_ID>
                          <LOCAL_INTERFACE_ID> <TRACE_REQ>

<TraceReqメッセージ>:、:= _一般的な<の地方の_インタフェース_ID><ヘッダー><メッセージ_ID><跡のREQ>。

   The above transmission order SHOULD be followed.

上のトランスミッションはSHOULDを注文します。続かれています。

   The format of the TRACE_REQ object is as follows:

TRACE_REQオブジェクトの形式は以下の通りです:

   Class = 22

クラス=22

   O    C-Type = 1, TraceReq

○ 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)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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-タイプ| クラス| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 跡のタイプ| (予約される)です。 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

TraceReqメッセージを受け取った後に、TraceReportメッセージ(メッセージType27)を制御チャンネルの上に送ります。

   <TraceReport Message> ::= <Common Header> <MESSAGE_ID_ACK> <TRACE>

<TraceReportメッセージ>:、:= _<の一般的なヘッダー><メッセージ_ID ACK><跡の>。

   The TraceReport message MUST include a TRACE Object (as described in
   Section 4.1.1.1) for the requested data link.

TraceReportメッセージは要求されたデータ・リンクにTRACE Objectを含まなければなりません(セクション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]で定義されます。 承認されていて、TraceReqメッセージからMESSAGE_ID_ACKオブジェクトのコンテンツを得なければなりません。

Lang & Papadimitriou        Standards Track                    [Page 10]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[10ページ]RFC4207Sonet/SDH

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.

TraceReqメッセージを受け取った後に、TraceReqNackメッセージ(メッセージType28)を制御チャンネルの上に送ります。

   <TraceReqNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
                            <ERROR_CODE>

<TraceReqNackメッセージ>:、:= _<の一般的なヘッダー><メッセージ_ID ACK><誤り_コード>。

   The above transmission order SHOULD be followed.

上のトランスミッションはSHOULDを注文します。続かれています。

   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]で定義されます。 承認されていて、TraceReqメッセージからMESSAGE_ID_ACKオブジェクトのコンテンツを得なければなりません。

   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 Objectを要求されたデータ・リンクに含まなければなりません(セクション4.1.3で.1を定義するので)。

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メッセージ(メッセージType29)は、制御チャンネルの上に送られて、特定の跡のメッセージをデータ・リンクの上に送るよう遠隔ノードに要求するのに使用されます(これは、リモートがそのようなものを実現させる前のIdsが要求する地方の、そして、リモートなインタフェース_の間のマッピングを知っていると仮定します)。

   The format is as follows:

形式は以下の通りです:

   <InsertTrace Message> ::=   <Common Header> <MESSAGE_ID>
                               <LOCAL_INTERFACE_ID> <TRACE>

<InsertTraceメッセージ>:、:= 一般的な<の地方の_インタフェース_ID><ヘッダー><メッセージ_ID><跡の>。

   The above transmission order SHOULD be followed.

上のトランスミッションはSHOULDを注文します。続かれています。

   A node that receives an InsertTrace message MUST respond with either
   an InsertTraceAck or an InsertTraceNack Message.

InsertTraceメッセージを受け取るノードはInsertTraceAckかInsertTraceNack Messageのどちらかと共に応じなければなりません。

   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_オブジェクトは[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メッセージ(メッセージType30)は、InsertTraceメッセージの領収書を受け取ったことを知らせて、InsertTraceメッセージのTRACE Objectが受け取られたのを示すのに使用されて、正しさ(すなわち、Trace Mismatchがない)に処理されます。 形式は以下の通りです:

Lang & Papadimitriou        Standards Track                    [Page 11]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[11ページ]RFC4207Sonet/SDH

   <InsertTraceAck Message> ::= <Common Header> <MESSAGE_ID_ACK>

<InsertTraceAckメッセージ>:、:= _<の一般的なヘッダー><メッセージ_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]で定義されます。 承認されていて、InsertTraceメッセージからMESSAGE_ID_ACKオブジェクトのコンテンツを得なければなりません。

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メッセージ(メッセージType31)は、InsertTraceメッセージの領収書を受け取ったことを知らせて、InsertTraceメッセージのTRACE Objectが正しく処理されなかったのを示すのに使用されます。 これはモニターが要求した跡がサポートされなかったか、または値には誤りがあったからであるかもしれません。

   The format is as follows:

形式は以下の通りです:

   <InsertTraceNack Message> ::= <Common Header> <MESSAGE_ID_ACK>
                                 <ERROR_CODE>

<InsertTraceNackメッセージ>:、:= _<の一般的なヘッダー><メッセージ_ID ACK><誤り_コード>。

   The above transmission order SHOULD be followed.

上のトランスミッションはSHOULDを注文します。続かれています。

   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 Objectを要求されたデータ・リンクに含まなければなりません(セクション4.1.3で.1を定義するので)。

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

LMPメッセージセキュリティは[RFC4204]で説明されるように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 Object ClassはObject Classの中でユニークな(C-タイプ)をタイプします。 - LMP Sub-オブジェクトClassはObject Classの中でユニークな(タイプ)をタイプします。

   This memo introduces the following new assignments:

このメモは以下の新しい課題を紹介します:

   LMP Message Type:

LMPメッセージタイプ:

      o TraceMonitor message      (Message type = 21)
      o TraceMonitorAck message   (Message type = 22)

o TraceMonitorメッセージ(メッセージタイプ=21)o TraceMonitorAckメッセージ(メッセージタイプ=22)

Lang & Papadimitriou        Standards Track                    [Page 12]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[12ページ]RFC4207Sonet/SDH

      o TraceMonitorNack message  (Message type = 23)
      o TraceMismatch message     (Message type = 24)
      o TraceMismatchAck message  (Message type = 25)

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 Object Class名前スペースとClassは(C-タイプ)をタイプします:

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

o TRACE Class名(21)--1をタイプしてください。(C-タイプ=1)

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

o TRACE REQ Class名(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)におけるリンクバンドリング」、RFC4201、2005年10月。

   [G.707]     ITU-T Recommendation G.707, "Network node interface for
               the synchronous digital hierarchy (SDH)," October 2000.

[G.707]ITU-T Recommendation G.707、「同期デジタル階層構造(SDH)のためのネットワーク・ノードインタフェース」、2000年10月。

   [RFC4204]   Lang, J., Ed., "Link Management Protocol (LMP)", RFC
               4204, October 2005.

[RFC4204] ラング、J.、エド、「リンク管理プロトコル(LMP)」、RFC4204、10月2005日

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

[RFC1662] シンプソン、W.、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、1994年7月。

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。

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

[T1.105]T1.105、「改定草案T105Sonet基地の規格」、2001年1月。

Lang & Papadimitriou        Standards Track                    [Page 13]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[13ページ]RFC4207Sonet/SDH

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)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。

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.

作者はこのドキュメントへの彼らの多くの貢献についてバーナードSales、エマニュエルDesmet、ゲルトGrammel、ジム・ジョーンズ、ステファンAnsorge、ジョン・ドレイク、およびJames Scottに感謝したがっています。

   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.

また、彼らの洞察に満ちたコメントと強度、プロフェッショナリズム、および礼儀の強い組み合わせで行動して頂いて、グレッグ・バーンスタインとMichielバンエフェルディンゲンに感謝申し上げます。

Authors' Addresses

作者のアドレス

   Jonathan P. Lang
   Sonos, Inc.
   223 E. De La Guerra St.
   Santa Barbara, CA 93101

サンタバーバラ、ジョナサンP.ラングSonos Inc.223E.De Laグェルラ通りカリフォルニア 93101

   EMail: jplang@ieee.org

メール: jplang@ieee.org

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

ディミトリPapadimitriouアルカテルフランシスWellesplein1B-2018アントウェルペン(ベルギー)

   EMail: dimitri.papadimitriou@alcatel.be

メール: dimitri.papadimitriou@alcatel.be

Lang & Papadimitriou        Standards Track                    [Page 14]

RFC 4207        SONET/SDH Encoding for LMP Test Messages    October 2005

2005年10月にLMPのためにテストメッセージをコード化するラングとPapadimitriou標準化過程[14ページ]RFC4207Sonet/SDH

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

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

Lang & Papadimitriou        Standards Track                    [Page 15]

ラングとPapadimitriou標準化過程[15ページ]