Network Working Group D. Papadimitriou, Ed.
Request for Comments: 4328 Alcatel
Updates: 3471 January 2006
Category: Standards Track
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control
一般マルチプロトコルラベルスイッチング（GMPLS）G.709光伝送ネットワークの制御のためのシグナリング拡張
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology-specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments.
この文書は、文書のシグナル汎用マルチプロトコルラベルスイッチング（GMPLS）の仲間です。これは、光伝送ネットワーク（OTN）を制御するGMPLSシグナリングを拡張するために必要な技術固有の情報を記述し、それは、いわゆるプレOTN開発を含んでいます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. GMPLS Extensions for G.709 - Overview ...........................3
3. Generalized Label Request .......................................4
3.1. Common Part ................................................5
3.1.1. LSP Encoding Type ...................................5
3.1.2. Switching Type ......................................6
3.1.3. Generalized-PID (G-PID) .............................6
3.2. G.709 Traffic Parameters ...................................8
3.2.1. Signal Type (ST) ....................................8
3.2.2. Number of Multiplexed Components (NMC) ..............9
3.2.3. Number of Virtual Components (NVC) .................10
3.2.4. Multiplier (MT) ....................................10
3.2.5. Reserved Fields ....................................10
4. Generalized Label ..............................................10
4.1. ODUk Label Space ..........................................11
4.2. Label Distribution Rules ..................................13
4.3. Optical Channel Label Space ...............................14
5. Examples .......................................................14
6. RSVP-TE Signaling Protocol Extensions ..........................16
7. Security Considerations ........................................16
8. IANA Considerations ............................................16
9. Acknowledgements ...............................................18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................19
11. Contributors ..................................................19
Appendix A. Abbreviations .........................................21
Appendix B. G.709 Indexes .........................................22
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends MPLS from supporting Packet Switching Capable (PSC) interfaces and switching to include support of four new classes of interfaces and switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM), Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional description of the extensions to MPLS signaling that are needed to support these new classes of interfaces and switching is provided in [RFC3471]. [RFC3473] describes the RSVP-TE-specific formats and mechanisms needed to support all four classes of interfaces.
レイヤ2スイッチング（L2SC）、時分割多重（：一般化されたマルチプロトコルラベルスイッチング（GMPLS）[RFC3945]はできる（PSC）インタフェースをパケット交換をサポートし、インターフェースとスイッチング4つの新しいクラスのサポートを含むように切り替えからMPLSを拡張しますTDM）、ラムダ・スイッチ（LSC）、およびファイバ・スイッチ（FSC）が可能。インターフェイスと切り替えのこれらの新しいクラスをサポートするために必要とされるMPLSシグナリングの拡張機能の機能説明は、[RFC3471]に提供されます。 [RFC3473]はインターフェイスのすべての4つのクラスをサポートするために必要なRSVP-TE固有フォーマットとメカニズムを説明しています。
This document presents the technology details that are specific to G.709 Optical Transport Networks (OTN) as specified in the ITU-T G.709 recommendation [ITUT-G709] (and referenced documents), including pre-OTN developments. Per [RFC3471], G.709 technology-specific parameters are carried through the signaling protocol in dedicated traffic parameter objects.
この文書では、事前OTNの開発など、ITU-T G.709勧告[ITUT-G709]（および参照文書）に指定されているようG.709光伝送ネットワーク（OTN）に固有の技術の詳細を提示します。 [RFC3471]あたり、G.709技術固有のパラメータは、専用トラフィックパラメータオブジェクト内シグナリングプロトコルを介して運ばれます。
The G.709 traffic parameters defined hereafter (see Section 3.2) MUST be used when the label is encoded as defined in this document. Moreover, the label MUST be encoded as defined in Section 4 when these G.709 traffic parameters are used.
この文書で定義されているラベルがエンコードされたときに、以下に定義G.709トラフィックパラメータは、（3.2節を参照）を使用する必要があります。これらG.709トラフィックパラメータが使用される場合、セクション4で定義されるようにまた、ラベルは、符号化されなければなりません。
In the context of this memo, by pre-OTN developments, one refers to Optical Channel, Digital Wrapper and Forward Error Correction (FEC) solutions that are not fully G.709 compliant. Details concerning pre-OTN Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) based solutions including Section/Regenerator Section overhead (SOH/RSOH) and Line/Multiplex Section overhead (LOH/MSOH) transparency are covered in [RFC3946].
このメモの文脈では、前OTNの開発により、1は光チャネル、デジタルラッパーおよび前方誤り訂正（FEC）に完全にG.709準拠していないソリューションを指します。前OTN同期光ネットワーク（SONET）に関する詳細は、/セクション/再生セクションオーバヘッド（SOH / RSOH）とライン/多重化セクションオーバーヘッド（LOH / MSOH）透明度を含む同期デジタル階層（SDH）ベースのソリューションは、[RFC3946]でカバーされています。
*** Note on ITU-T G.709 Recommendation ***
*** ITU-T G.709勧告に注意してください***
The views on the ITU-T G.709 OTN Recommendation presented in this document are intentionally restricted to the GMPLS perspective within the IETF CCAMP WG context. Hence, the objective of this document is not to replicate the content of the ITU-T OTN recommendations. Therefore, readers interested in more details concerning the corresponding technologies are strongly invited to consult the corresponding ITU-T documents (also referenced in this memo).
この文書のITU-T G.709 OTN勧告について意見を意図的にIETF CCAMP WGのコンテキスト内GMPLSの視点に制限されています。したがって、このドキュメントの目的は、ITU-TのOTN勧告の内容を複製することはありません。したがって、対応する技術について詳細に興味がある読者は強く対応するITU-Tのドキュメント（また、このメモで参照）を参照するために招待されています。
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]に記載されているように解釈されます。
In addition, the reader is assumed to be familiar with the terminology used in ITU-T [ITUT-G709], as well as [RFC3471] and [RFC3473]. Abbreviations used in this document are detailed in Appendix 1.
また、読者は、ITUT [ITUT-G709]で使用される用語、ならびに[RFC3471]及び[RFC3473]に精通しているものとします。この文書で使用されている略語は、付録1に詳述されています。
[ITUT-G709] defines several networking layers constituting the optical transport hierarchy:
[ITUT-G709は、光学トランスポート階層を構成するいくつかのネットワーク層を定義します。
- with full functionality: . Optical Transmission Section (OTS) . Optical Multiplex Section (OMS) . Optical Channel (OCh) - with reduced functionality: . Optical Physical Section (OPS) . Optical Channel with reduced functionality (OChr)
- すべての機能を持ちます：。光送信部（OTS）。光多重セクション（OMS）。光チャネル（OCH） - 減少した機能を持ちます：。光物理セクション（OPS）。減少した機能を備えた光チャネル（OChr）
It also defines two layers constituting the digital transport hierarchy:
それはまた、デジタルトランスポート階層を構成する2つの層を定義します。
- Optical Channel Transport Unit (OTUk) - Optical Channel Data Unit (ODUk)
- 光チャネルトランスポート・ユニット（のOTUk） - 光チャネルデータユニット（ODUkの）
However, only the OCh and the ODUk layers are defined as switching layers. Both OCh (but not OChr) and ODUk layers include the overhead for supervision and management. The OCh overhead is transported in a non-associated manner (also referred to as the non-associated overhead naOH) in the Optical Transport Module (OTM) Overhead Signal (OOS), together with the OTS and OMS non-associated overhead. The OOS is transported via a dedicated wavelength, referred to as the Optical Supervisory Channel (OSC). It should be noticed that the naOH is only functionally specified and as such, it is open to vendor-specific solutions. The ODUk overhead is transported in an associated manner as part of the digital ODUk frame.
しかし、唯一のOChとのODUk層は、層を切り替えるように定義されます。両方OCH（なくOChr）とをODUk層は、監督および管理のためのオーバーヘッドを含みます。 OChオーバーヘッドを一緒OTS及びOMS非関連するオーバーヘッドとの光伝送モジュール（OTM）オーバーヘッド信号（OOS）における非関連方法（非関連オーバーヘッドのNaOHと称する）に搬送されます。 OOSは、光監視チャネル（OSC）と呼ばれる専用の波長を介して搬送されます。それを、NaOHのみが機能的に指定されていることに注意すべきであるとのような、それはベンダー固有のソリューションに開放されています。 ODUkオーバヘッドは、デジタルのODUkフレームの一部として対応付けて搬送されます。
As described in [ITUT-G709], in addition to the support of ODUk mapping into OTUk (k = 1, 2, 3), G.709 supports ODUk multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into an ODUk (k > j) signal, in particular:
[ITUT-G709]に記載されているように、のOTUkへのODUkマッピングのサポートに加えて、（K = 1、2、3）、G.709はのODUk多重化をサポートします。それは、特に、のODUk（k> j）の信号に（2、J = 1）がODUjの多重化を指します。
- ODU1 into ODU2 multiplexing - ODU1 into ODU3 multiplexing - ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing
- ODU2多重にODU1 - ODU3多重にODU1 - ODU3多重にODU2 - ODU3多重にODU1とODU2
Adapting GMPLS to control G.709 OTN can be achieved by creating:
G.709 OTNを制御する適応GMPLSを作成することによって達成することができます。
- a Digital Path layer, by extending the previously defined "Digital Wrapper" in [RFC3471] corresponding to the ODUk (digital) path layer. - an Optical Path layer, by extending the "Lambda" concept (defined in [RFC3471]) to the OCh (optical) path layer. - a label space structure, by considering a tree whose root is an OTUk signal and leaves the ODUj signals (k >= j); enabling the identification of the exact position of a particular ODUj signal in an ODUk multiplexing structure.
- デジタルパス層、のODUk（デジタル）パス層に対応するで以前に定義された「デジタルラッパー」[RFC3471]を拡張することによって。 - OCH（光）パス層に（[RFC3471]で定義された）「ラムダ」の概念を拡張することにより光路層、。 - そのルートのOTUk信号とがODUj信号（K> = j）を残す木を考慮してラベル空間構造。 ODUk多重構造の特定がODUj信号の正確な位置の同定を可能にします。
Thus, the GMPLS signaling extensions for G.709 need to cover the Generalized Label Request, the Generalized Label as well as the specific technology dependent objects included in the so-called traffic parameters as specified in [RFC3946] for SONET/SDH networks. Moreover, because multiplexing in the digital domain (such as ODUk multiplexing) has been specified in the amended version of the G.709 ITU-T recommendation (October 2001), this document also proposes a label space definition suitable for that purpose. Notice also that one uses the G.709 ODUk (i.e., Digital Path) and OCh (i.e., Optical Path) layers directly in order to define the corresponding label spaces.
したがって、G.709のための拡張機能をGMPLSシグナリングは、一般ラベル要求、一般ラベルだけでなく、SONET / SDHネットワークのために[RFC3946]で指定された依存オブジェクトは、いわゆるトラフィックパラメータに含まれる特定の技術をカバーする必要があります。 （例えばのODUk多重化のような）デジタル領域で多重化はG.709 ITU-T勧告（2001年10月）の修正バージョンで指定されているので、また、この文書は、その目的に適したラベルスペースの定義を提案しています。通知はまた、1つは、対応するラベルスペースを定義するために直接G.709のODUk（すなわち、デジタルパス）およびOCH（すなわち光路）層を使用します。
The Generalized Label Request, as defined in [RFC3471], includes a common part (i.e., used for any switching technology) and a technology dependent part (i.e., the traffic parameters). In this section, both parts are extended to accommodate GMPLS Signaling to the G.709 transport plane recommendation (see [ITUT-G709]).
一般化ラベル要求は、[RFC3471]で定義されるように、共通部分（すなわち、任意のスイッチング技術のために使用される）と技術に依存する部分（すなわち、トラフィックパラメータ）を含みます。このセクションでは、両方の部分は（[ITUT-G709]を参照）G.709輸送面勧告にGMPLSシグナリングを収容するように拡張されます。
As defined in [RFC3471], the LSP Encoding Type, the Switching Type and the Generalized Protocol Identifier (Generalized-PID) constitute the common part of the Generalized Label Request. The encoding of the RSVP-TE GENERALIZED_LABEL_REQUEST object is specified in [RFC3473] Section 2.1.
[RFC3471]で定義されるように、LSP符号化タイプ、スイッチングタイプと一般プロトコル識別子（一般化-PID）を一般化ラベル要求の共通部分を構成しています。 RSVP-TE GENERALIZED_LABEL_REQUESTオブジェクトの符号化は[RFC3473]セクション2.1で指定されています。
As mentioned above, this document extends the LSP Encoding Type, the Switching Type, and G-PID (Generalized-PID) values to accommodate G.709 Recommendation [ITUT-G709].
上述したように、このドキュメントは、G.709勧告[ITUT-G709]を収容するLSP符号化タイプ、スイッチングタイプ、およびG-PID（一般化-PID）値を延びています。
Because G.709 Recommendation defines two networking layers (ODUk layers and OCh layer), the LSP Encoding Type code-points can reflect these two layers defined in [RFC3471] Section 3.1 as "Digital Wrapper" and "Lambda" code. The LSP Encoding Type is specified per networking layer or, more precisely, per group of functional networking layers: the ODUk layers and the OCh layer.
G.709勧告は、2つのネットワーク層（のODUk層及びOCHレイヤ）を定義しているので、LSP符号化タイプのコードポイントは、「デジタルラッパー」と「ラムダ」コードとして[RFC3471]セクション3.1で定義され、これらの二つの層を反映することができます。 LSP符号化タイプは、ネットワーク層ごとに指定されるか、または、より正確には、機能的なネットワーク層の群あたり：のODUk層およびOCHレイヤ。
Therefore, an additional LSP Encoding Type code-point for the G.709 Digital Path layer is defined; it enlarges the existing "Digital Wrapper" code-point defined in [RFC3471]. The former MUST be generated when the interface or tunnel on which the traffic will be transmitted supports G.709 compliant Digital Path layer encoding. The latter MUST only be used for non-G.709 compliant Digital Wrapper layer(s) encoding. A transit or an egress node (receiving a Path message containing a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication, if the requested LSP Encoding Type cannot be supported on the corresponding incoming interface.
したがって、G.709デジタルパス層のための追加のLSP符号化タイプコードポイントが定義されます。それは[RFC3471]で定義された既存の「デジタルラッパー」コードポイントを拡大します。トラフィックが送信されるインターフェイスまたはトンネルがG.709準拠のデジタルパスレイヤ符号化をサポートしている場合、前者が生成されなければなりません。後者は、非G.709準拠のデジタルラッパー層（単数または複数）をコードするために使用しなければなりません。要求されたLSP符号化タイプは、対応する着信インターフェイス上でサポートすることができない場合、トランジットまたは（GENERALIZED_LABEL_REQUESTオブジェクトを含むPathメッセージを受信する）出口ノードは、「ルーティング問題/サポートされていないエンコーディング」表示と、のPathErrメッセージを生成しなければなりません。
In the same way, an additional LSP Encoding Type code-point for the G.709 Optical Channel layer is defined; it enlarges the existing "Lambda" code-point defined in [RFC3471]. The former MUST be generated when the interface or tunnel on which the traffic will be transmitted supports G.709-compliant Optical Channel layer encoding. The latter MUST only be used for non-G.709 compliant Lambda layer(s) encoding. A transit or an egress node (receiving a Path message that contains a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr message with a "Routing problem/Unsupported Encoding" indication, if the requested LSP Encoding Type cannot be supported on the corresponding incoming interface.
同様に、G.709光チャネル層のための追加のLSP符号化タイプコードポイントが定義されています。それは[RFC3471]で定義された既存の「ラムダ」のコードポイントを拡大します。トラフィックが送信されるインターフェイスまたはトンネルがG.709に準拠した光チャネル層の符号化をサポートしている場合、前者が生成されなければなりません。後者は、非G.709に準拠ラムダ層（単数または複数）をコードするために使用しなければなりません。要求されたLSP符号化タイプは、対応する着信インターフェイス上でサポートすることができない場合、トランジットまたは（GENERALIZED_LABEL_REQUESTオブジェクトを含むPathメッセージを受信する）出口ノードは、「ルーティング問題/サポートされていないエンコーディング」表示とのPathErrメッセージを生成しなければなりません。
Consequently, the following additional code-points for the LSP Encoding Type are defined:
したがって、LSP符号化タイプのために次の追加のコード・ポイントが定義されています。
Value Type
----- ----
12 G.709 ODUk (Digital Path)
13 G.709 Optical Channel
Moreover, the code-point for the G.709 Optical Channel (OCh) layer will indicate the requested capability of an end-system to use the G.709 non-associated overhead (naOH), i.e., the OTM Overhead Signal (OOS) multiplexed into the OTM-n.m interface signal.
また、コード・ポイントG.709光チャネル（OCH）層はG.709非関連オーバーヘッド（水酸化ナトリウム）、すなわち、OTMオーバーヘッド信号（OOS）を使用するエンドシステムの要求された能力を示すことになるためOTM-nmのインターフェース信号に多重化。
The Switching Type indicates the type of switching that should be performed at the termination of a particular link (see [RFC4202]).
スイッチングタイプは、特定のリンク（[RFC4202]を参照）の終了時に実行されるべきスイッチングの種類を示します。
No additional Switching Type values are to be considered in order to accommodate G.709 switching types, because an ODUk switching (and thus LSPs) belongs to the TDM class, while an OCh switching (and thus LSPs) belong to the Lambda class (i.e., LSC).
OChを切り替えながらのODUkスイッチング（ひいてはのLSP）は、TDMクラスに属しているため、追加のスイッチング・タイプの値は、G.709スイッチングタイプに対応するために考慮されないことになっている（したがってたLSP）はラムダクラスに属している（すなわち、LSC）。
Intermediate and egress nodes MUST verify that the value indicated in the Switching Type field is supported on the corresponding incoming interface. If the requested value can not be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication.
中間と出口ノードは、スイッチングタイプフィールドに示される値は、対応する着信インターフェイス上でサポートされていることを確認しなければなりません。要求された値がサポートできない場合、ノードは、「ルーティング問題/切換タイプ」表示とのPathErrメッセージを発生させなければなりません。
The G-PID (16 bits field), as defined in [RFC3471], identifies the payload carried by an LSP, i.e., an identifier of the client layer of that LSP. This identifier is used by the endpoints of the G.709 LSP.
G-PID（16ビットのフィールド）、[RFC3471]で定義されるように、LSPによって運ばれるペイロード、すなわち、そのLSPのクライアント層の識別子を識別する。この識別子は、G.709 LSPの終点によって使用されます。
The G-PID can take one of the following values when the client payload is transported over the Digital Path layer, in addition to the payload identifiers defined in [RFC3471]:
G-PIDは、[RFC3471]で定義されたペイロード識別子に加えて、クライアントのペイロードはデジタルパス層の上に搬送され、次のいずれかの値を取ることができます。
- CBRa: asynchronous Constant Bit Rate (i.e., mapping of STM-16/OC-48, STM-64/OC-192 and STM-256/OC-768) - CBRb: bit synchronous Constant Bit Rate (i.e., mapping of STM-16/OC-48, STM-64/OC-192 and STM-256/OC-768) - ATM: mapping at 2.5, 10 and 40 Gbps - BSOT: non-specific client Bit Stream with Octet Timing (i.e., Mapping of 2.5, 10 and 40 Gbps Bit Stream) - BSNT: non-specific client Bit Stream without Octet Timing (i.e., Mapping of 2.5, 10 and 40 Gbps Bit Stream)
- CBRa：非同期固定ビットレート（すなわち、STM-16 / OC-48、STM-64 / OC-192及びSTM-256 / OC-768のマッピング） - CBRb：ビット同期固定ビットレート（すなわち、STMのマッピング-16 / OC-48、STM-64 / OC-192及びSTM-256 / OC-768） - ATM：マッピング2.5、10および40 Gbpsで - BSOT：オクテットタイミングと非特定のクライアントビットストリーム（すなわち、マッピング2.5、10および40 Gbpsのは、ストリームをBIT）の - BSNT：オクテットタイミング（すなわち、2.5のマッピングせずに非固有のクライアントビットストリーム、10および40 Gbpsのは）ストリームのビット
- ODUk: transport of Digital Paths at 2.5, 10 and 40 Gbps - ESCON: Enterprise Systems Connection - FICON: Fiber Connection
- のODUk：2.5、10および40 Gbpsでのデジタルパスの輸送 - ESCON：エンタープライズシステム接続 - FICON：ファイバ接続
The G-PID can take one of the following values when the client payload is transported over the Optical Channel layer, in addition to the payload identifiers defined in [RFC3471]:
G-PIDは、[RFC3471]で定義されたペイロード識別子に加えて、クライアントペイロードが光チャネル層の上に搬送され、次のいずれかの値を取ることができます。
- CBR: Constant Bit Rate (i.e., mapping of STM-16/OC-48, STM-64/OC-192 and STM-256/OC-768) - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps
- CBR：固定ビットレート（STM-16 / OC-48、STM-64 / OC-192及びSTM-256 / OC-768の、即ち、マッピング） - のOTUk / OTUkV：2.5、10及び40でデジタルセクションの輸送Gbpsの
Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are encapsulated through the Generic Framing Procedure (GFP), as described in ITU-T G.7041, dedicated G-PID values are defined.
ITU-T G.7041に記載されているように、イーサネットMAC / PHY及びIP / PPPのクライアントペイロードが、ジェネリックフレーミングプロシージャ（GFP）を介してカプセル化されている場合にも、専用のG-PIDの値が定義されています。
In order to include pre-OTN developments, the G-PID field can take one of the values (currently defined in [RFC3471]) when the following client payloads are transported over a so-called lambda LSP:
次のクライアントペイロードは、いわゆるラムダLSP上を搬送される際に、プリOTN開発を含めるために、G-PIDフィールドは、（現在[RFC3471]で定義される）のいずれかの値を取ることができます。
- Ethernet PHY (1 Gbps and 10 Gbps) - Fiber Channel
- イーサネットPHY（1 Gbpsおよび10 Gbpsの） - ファイバチャネル
The following table summarizes the G-PID with respect to the LSP Encoding Type:
次の表は、LSP符号化タイプに対してG-PIDを要約したものです。
Value G-PID Type LSP Encoding Type
----- ---------- -----------------
47 G.709 ODUj G.709 ODUk (with k > j)
48 G.709 OTUk(v) G.709 OCh
ODUk mapped into OTUk(v)
49 CBR/CBRa G.709 ODUk, G.709 OCh
50 CBRb G.709 ODUk
51 BSOT G.709 ODUk
52 BSNT G.709 ODUk
53 IP/PPP (GFP) G.709 ODUk (and SDH)
54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH)
55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH)
56 ESCON G.709 ODUk, Lambda, Fiber
57 FICON G.709 ODUk, Lambda, Fiber
58 Fiber Channel G.709 ODUk, Lambda, Fiber
Note: Values 49 and 50 include mapping of SDH.
注意：49と50は、SDHのマッピングを含む値。
The following table summarizes the update of the G-PID values defined in [RFC3471]:
以下の表は、[RFC3471]で定義されたG-PID値の更新を要約したものです。
Value G-PID Type LSP Encoding Type
----- ---------- -----------------
32 ATM Mapping SDH, G.709 ODUk
33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber
34 Sonet/SDH G.709 OCh, Lambda, Fiber
35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber
When G.709 Digital Path Layer or G.709 Optical Channel Layer is specified in the LSP Encoding Type field, the information referred to as technology dependent (or simply traffic parameters) is carried additionally to the one included in the Generalized Label Request.
G.709デジタルパス層またはG.709光チャネル層はLSPエンコーディングタイプ]フィールドで指定された場合、技術依存（または単にトラフィックパラメータ）と呼ばれる情報は、一般ラベル要求に含まれる1つに加えて実施されます。
The G.709 traffic parameters are defined as follows:
次のようにG.709トラフィックパラメータが定義されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Reserved | NMC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this frame, NMC stands for Number of Multiplexed Components, NVC for Number of Virtual Components, and MT for Multiplier. Each of these fields is tailored to support G.709 LSP requests.
このフレームでは、NMCは、乗数のための多重化コンポーネント、仮想コンポーネントの数のためのNVC、およびMTの数を表します。これらの各フィールドは、G.709 LSP要求をサポートするために調整されます。
The RSVP-TE encoding of the G.709 traffic-parameters is detailed in Section 6.
G.709トラフィックパラメータのRSVP-TE符号化は第6節に詳述されています。
This field (8 bits) indicates the type of G.709 Elementary Signal that comprises the requested LSP. The permitted values are:
このフィールド（8ビット）は、要求されたLSPを含むG.709基本信号の種類を示しています。許可される値は以下のとおりです。
Value Type
----- ----
0 Not significant
1 ODU1 (i.e., 2.5 Gbps)
2 ODU2 (i.e., 10 Gbps)
3 ODU3 (i.e., 40 Gbps)
4 Reserved (for future use)
5 Reserved (for future use) 6 OCh at 2.5 Gbps 7 OCh at 10 Gbps 8 OCh at 40 Gbps 9-255 Reserved (for future use)
5予約（将来の使用のために）40 Gbpsの9から255予約で10 Gbpsの8のOChで2.5 Gbpsの7のOChで6 OCH（将来の使用のために）
The value of the Signal Type field depends on LSP Encoding Type value defined in Section 3.1.1 and [RFC3471]:
信号タイプフィールドの値は、セクション3.1.1と[RFC3471]で定義されたLSP符号化タイプの値に依存します。
- if the LSP Encoding Type value is the G.709 Digital Path layer, then the valid values are the ODUk signals (k = 1, 2 or 3). - if the LSP Encoding Type value is the G.709 Optical Channel layer, then the valid values are the OCh at 2.5, 10, or 40 Gbps. - if the LSP Encoding Type is "Lambda" (which includes the pre-OTN Optical Channel layer) then the valid value is irrelevant (Signal Type = 0). - if the LSP Encoding Type is "Digital Wrapper", then the valid value is irrelevant (Signal Type = 0).
- LSP符号化タイプ値はG.709デジタルパス層である場合、有効な値はのODUk信号（k = 1、2または3）です。 - LSP符号化タイプ値はG.709光チャネル層である場合、有効な値は2.5、10、または40 GbpsでのOChあります。 - LSP符号化タイプが「ラムダ」（プレOTN光チャネル層を含む）である場合、有効な値は、（信号タイプ= 0）は無関係です。 - LSP符号化タイプが「デジタルラッパー」である場合、有効な値は、（信号タイプ= 0）は無関係です。
Several transforms can be sequentially applied on the Elementary Signal to build the Final Signal that is actually requested for the LSP. Each transform application is optional and must be ignored if zero; this does not include the Multiplier (MT), which cannot be zero and must be ignored if equal to one. Transforms must be applied strictly in the following order:
いくつかの変換は、順次、実際にLSPのために要求される最終的な信号を構築するために基本信号に適用することができます。それぞれのアプリケーションはオプションであり、ゼロの場合は無視されなければならない変換します。これは、ゼロにすることはできず、1に等しい場合は無視されなければならない乗数（MT）が、含まれていません。変換は、次の順序で厳密に適用する必要があります。
- First, virtual concatenation (by using the NVC field) can be optionally applied directly on the Elementary Signal to form a Composed Signal - Second, a multiplication (by using the Multiplier field) can be optionally applied, either directly on the Elementary Signal, or on the virtually concatenated signal obtained from the first phase. The resulting signal is referred to as Final Signal.
（NVCフィールドを使用して）仮想連結は、必要に応じてなる信号を形成するために、基本信号に直接適用可能な第1、 - - 第二に、（Multiplierフィールドを使用して）乗算は必要に応じて、直接基本信号に適用することができますまたは仮想連結信号に第一段階から得られました。結果として得られる信号は、最終的な信号と呼ばれます。
The NMC field (16 bits) indicates the number of ODU tributary slots used by an ODUj when multiplexed into an ODUk (k > j) for the requested LSP. This field is not applicable when an ODUk is mapped into an OTUk and irrelevant at the Optical Channel layer. In both cases, it MUST be set to zero (NMC = 0) when sent and should be ignored when received.
NMCフィールド（16ビット）は、要求されたLSPのためのODUk（k> j）の中に多重化するときがODUjで使用ODUのトリビュタリスロットの数を示します。 ODUkのは、光チャネル層でのOTUkとは無関係にマッピングされている場合、このフィールドは適用されません。両方の場合において、送信され、受信時に無視されるべきである場合にゼロ（NMC = 0）に設定しなければなりません。
When applied at the Digital Path layer, in particular for ODU2 connections multiplexed into one ODU3 payload, the NMC field specifies the number of individual tributary slots (NMC = 4) that constitute the requested connection. These components are still processed within the context of a single connection entity. For all other currently defined multiplexing cases (see Section 2), the NMC field is set to 1.
1つのODU3ペイロードに多重化ODU2接続のため、特に、デジタルパス層に適用した場合、NMCフィールドは、要求された接続を構成する個々のトリビュタリスロット（NMC = 4）の数を指定します。これらのコンポーネントは、まだ単一の接続エンティティのコンテキスト内で処理されます。他のすべての現在定義されている多重の場合（セクション2を参照）、NMCフィールドが1に設定されています。
The NVC field (16 bits) is dedicated to ODUk virtual concatenation (i.e., ODUk Inverse Multiplexing) purposes. It indicates the number of ODU1, ODU2, or ODU3 Elementary Signals that are requested to be virtually concatenated to form an ODUk-Xv signal. By definition, these signals MUST be of the same type.
NVCフィールド（16ビット）のODUkバーチャルコンカチネーション（すなわち、ODUkの逆多重化）目的専用です。これは事実上のODUk-XV信号を形成するために連結されるように要求されODU1、ODU2、又はODU3基本信号の数を示しています。定義によると、これらの信号は同じタイプでなければなりません。
This field is set to 0 (default value) to indicate that no virtual concatenation is requested.
このフィールドは、何の仮想連結が要求されていないことを示すために0（デフォルト値）に設定されています。
Note that the current usage of this field only applies for G.709 ODUk LSPs, i.e., values greater than zero, are only acceptable for ODUk Signal Types. Therefore, it MUST be set to zero (NVC = 0), and should be ignored when received, when a G.709 OCh LSP is requested.
このフィールドの現在の使用だけG.709のODUkのLSPのために適用されます、すなわち、ゼロより大きい値のODUk信号タイプのためにのみ許容されます。したがって、それはゼロ（NVC = 0）に設定しなければならなくて、受信した場合にG.709のOCh LSPが要求された場合、無視されるべきです。
The Multiplier field (16 bits) indicates the number of identical Elementary Signals or Composed Signals that are requested for the LSP, i.e., that form the Final Signal. A Composed Signal is the resulting signal from the application of the NMC and NVC fields to an elementary Signal Type. GMPLS signaling currently implies that all the Composed Signals must be part of the same LSP.
Multiplierフィールド（16ビット）は、最終的な信号を形成するLSPのために要求される同じ基本信号または構成信号、即ち、の数を示しています。なる信号は、基本信号タイプにNMCとNVC分野のアプリケーションから得られた信号です。現在GMPLSシグナリングは、すべての構成信号が同じLSPの一部でなければならないことを意味します。
This field is set to one (default value) to indicate that exactly one instance of a signal is being requested. Intermediate and egress nodes MUST verify that the node itself and the interfaces on which the LSP will be established can support the requested multiplier value. If the requested values cannot be supported, the receiver node MUST generate a PathErr message (see Section 6).
このフィールドは、信号のうちの正確に1つのインスタンスが要求されていることを示すために1（デフォルト値）に設定されています。中間及び出口ノードがLSPが確立されているノード自体とインタフェースが要求された乗算値をサポートできることを確認しなければなりません。要求された値がサポートできない場合、受信ノードは、（セクション6を参照）のPathErrメッセージを生成しなければなりません。
Zero is an invalid value for the MT field. If received, the node MUST generate a PathErr message (see Section 6).
ゼロはMTフィールドに無効な値です。受信された場合、ノードは（セクション6を参照）のPathErrメッセージを生成しなければなりません。
The reserved fields (8 bits in row 1 and 32 bits in row 3) are dedicated for future use. Reserved bits SHOULD be set to zero when sent and MUST be ignored when received.
予約フィールド（列1における8ビットと行3の32ビット）は今後の使用のために特化されています。送受信時に無視されなければならない場合の予約ビットはゼロに設定されるべきです。
This section describes the Generalized Label value space for Digital Paths and Optical Channels. The Generalized Label is defined in
このセクションでは、デジタルパスと光チャネルのための汎用ラベル値空間を記述する。一般ラベルは、で定義されています
[RFC3471]. The format of the corresponding RSVP-TE GENERALIZED_LABEL object is specified in [RFC3473] Section 2.3.
[RFC3471]。対応するRSVP-TE GENERALIZED_LABELオブジェクトのフォーマットは、[RFC3473]セクション2.3で指定されています。
The label distribution rules detailed in Section 4.2 follow (when applicable) the ones defined in [RFC3946].
セクション4.2以下に詳述ラベル配布ルール（該当する場合）[RFC3946]で定義されたもの。
At the Digital Path layer (i.e., ODUk layers), G.709 defines three different client payload bit rates. An Optical Data Unit (ODU) frame has been defined for each of these bit rates. ODUk refers to the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps), or 3 (for 40 Gbps).
デジタルパス層（すなわち、層のODUk）で、G.709は、3つの異なるクライアントペイロードビットレートを定義します。光データユニット（ODU）フレームは、これらのビットレートごとに定義されています。 ODUkは（40 Gbpsのための）（10 Gbpsのため）= 1（2.5 Gbpsのための）は、k、2、又は3ビット率k、でフレームを指します。
In addition to the support of ODUk mapping into OTUk, the G.709 label space supports the sub-levels of ODUk multiplexing. ODUk multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk (k > j), in particular:
OTUkへのODUkマッピングのサポートに加え、G.709のラベルスペースは、ODUkの多重化のサブレベルをサポートしています。 ODUk多重化は、特に、のODUk（K> J）に（2、J = 1）がODUjの多重化を指します。
- ODU1 into ODU2 multiplexing - ODU1 into ODU3 multiplexing - ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing
- ODU2多重にODU1 - ODU3多重にODU1 - ODU3多重にODU2 - ODU3多重にODU1とODU2
More precisely, ODUj into ODUk multiplexing (k > j) is defined when an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e., an ODTUG constituted by ODU tributary slots) that is mapped into an OPUk. The resulting OPUk is mapped into an ODUk, and the ODUk is mapped into an OTUk.
がODUjをODUkのトリビュタリユニットグループに多重化されたときに、より正確には、のODUk多重（K> J）に変換がODUjが定義されている（すなわち、ODUのトリビュタリスロットで構成ODTUG）OPUkペイロードにマッピングされます。得られたOPUkペイロードはのODUk内にマッピングされ、そしてのODUkはのOTUkにマッピングされます。
Therefore, the label space structure is a tree whose root is an OTUk signal and whose leaves are the ODUj signals (k >= j) that can be transported via the tributary slots and switched between these slots. A G.709 Digital Path layer label identifies the exact position of a particular ODUj signal in an ODUk multiplexing structure.
したがって、ラベルスペース構造は、そのルートのOTUk信号であり、その葉トリビュタリスロットを介して輸送され、これらのスロットの間で切り替えることができるがODUj信号（K> = j）があるツリーです。 G.709デジタルパス層ラベルはのODUk多重構造の特定がODUj信号の正確な位置を特定します。
The G.709 Digital Path Layer label or ODUk label has the following format:
G.709デジタルパス層ラベルまたはのODUkラベルの形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | t3 | t2 |t1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits MUST be set to zero when sent and SHOULD be ignored when received.
予約ビットは、送信されたときにゼロに設定しなければならなくて、受信されたときに無視されるべきです。
The specification of the fields t1, t2, and t3 self-consistently characterizes the ODUk label space. The value space for the t1, t2, and t3 fields is defined as follows:
フィールドT1、T2、およびT3の仕様自己一貫のODUkラベル空間を特徴付けます。次のようにT1、T2、およびT3フィールドの値空間が定義されます。
1. t1 (1-bit): - t1=1 indicates an ODU1 signal. - t1 is not significant for the other ODUk signal types (i.e., t1 value MUST be set to 0 and ignored).
1. T1（1ビット）： - T 1 = 1は、ODU1信号を示しています。 - t1は、他のODUk信号の種類（すなわち、T1の値が0に設定され、無視されなければならない）のために重要ではありません。
2. t2 (3-bit): - t2=1 indicates an ODU2 signal that is not further sub-divided. - t2=[2..5] indicates the tributary slot (t2th-2) used by the ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). - t2 is not significant for an ODU3 (i.e., t2 value MUST be set to 0 and ignored).
2. T2（3ビット）： - T2 = 1は、さらにサブ分割されていないODU2信号を示しています。 - T2 = [2..5]（OPU2を介して）ODU2にマッピングODTUG2にODU1で使用トリビュタリスロット（t2th-2）を示しています。 - t2はODU3（即ち、T2の値が0に設定され、無視されなければならない）のために重要ではありません。
3. t3 (6-bit): - t3=1 indicates an ODU3 signal that is not further sub-divided. - t3=[2..17] indicates the tributary slot (t3th-1) used by the ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). - t3=[18..33] indicates the tributary slot (t3th-17) used by the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3).
3. T3（6ビット）： - T 3 = 1は、さらにサブ分割されていないODU3信号を示しています。 - T3 = [2..17]（OPU3を介して）ODU3にマッピングODTUG3にODU1で使用トリビュタリスロット（t3th-1）を示しています。 - T3 = [18..33]（OPU3を介して）ODU3にマッピングODTUG3にODU2で使用トリビュタリスロット（t3th-17）を示しています。
Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required to identify the 4 tributary slots used by the ODU2; these tributary time slots have to be allocated in ascending order.
注：ODU3多重にODU2の場合には、4つのラベルはODU2で使用される4つのトリビュタリスロットを識別するために必要とされます。これらの支流のタイムスロットは、昇順に割り当てられる必要があります。
If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j > i), the corresponding ODUk signal ODU[i] is directly mapped into the corresponding OTUk signal (k=i). This is referred to as the mapping of an ODUk signal into an OTUk of the same order. Therefore, the numbering starts at 1; zero is used to indicate a non-significant field. A label field equal to zero is an invalid value.
もしラベルサブフィールド値t [I] = 1（I、J = 1、2または3）とt [j] = 0（jは> I）、対応のODUk信号ODUは、[i]は直接にマッピングされます対応のOTUk信号（K = 1）。これは、同じ順序ののOTUkへのODUk信号のマッピングと呼ばれます。そのため、番号は1から始まります。ゼロは非有意フィールドを示すために使用されます。ゼロに等しいラベルフィールドが無効な値です。
Examples:
例：
- t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1 - t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 - t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3 - t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 - t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3
- T3 = 0、T2 = 0、T1 = 1はOTU1にマッピングODU1を示す - T3 = 0、T2 = 1、T1 = 0 OTU2にマッピングODU2を示す - T3 = 1、T2 = 0、T1 = 0 OTU3にマッピングODU3を示す - T3 = 0、T2 = 3、T 1 = 0（OPU2を介して）ODU2にマッピングODTUG2の第二支流スロットでODU1を示しOTU2にマッピング - T3 = 5、T2 = 0 、T1 = 0は、OTU3にマッピング（OPU3を介して）ODU3にマッピングODTUG3の第四のトリビュタリスロットでODU1を示し
In case of ODUk in OTUk mapping, only one label can appear in the Generalized Label. The unique label is encoded as a single 32-bit label value (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2).
OTUkマッピング中のODUkの場合は、1つのラベルだけは一般ラベルに表示されます。 GENERALIZED_LABELオブジェクトの（セクション4.1で定義されるような）一意のラベルが単一の32ビット・ラベル値として符号化される（クラス民= 16、C-タイプ= 2）。
In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered list of the labels in the multiplex is given (this list can be restricted to only one label when NMC = 1). Each label indicates a component (ODUj tributary slot) of the multiplexed signal. The order of the labels must reflect the order of the ODUj into the multiplex (not the physical order of tributary slots). This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2).
ODUk（k> j）を多重にがODUjの場合には、マルチプレックスのラベルの明示的な順序付けられたリストが与えられる（このリストは、唯一つのラベルに制限することができる場合NMC = 1）。各ラベルは、多重化信号の成分（がODUjトリビュタリスロット）を示しています。ラベルの順序は、多重（トリビュタリスロットのない物理的順序）がODUjへの順序を反映しなければなりません。 GENERALIZED_LABELオブジェクトの（クラス民= 16、C-タイプ= 2）（セクション4.1で定義されるように）ラベルのこの順序付けられたリストは、32ビットのラベル値のシーケンスとして符号化されます。
In case of ODUk virtual concatenation, the explicit ordered list of all labels in the concatenation is given. Each label indicates a component of the virtually concatenated signal. The order of the labels must reflect the order of the ODUk to concatenate (not the physical order of time-slots). This representation limits virtual concatenation to remain within a single (component) link. In case of multiplexed virtually concatenated signals, the first set of labels indicates the components (ODUj tributary slots) of the first virtually concatenated signal, the second set of labels indicates the components (ODUj tributary slots) of the second virtually concatenated signal, and so on. This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of ODUk virtual concatenation, the number of label values is determined by the NVC value. Multiplexed ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size).
ODUkの仮想連結の場合、連結のすべてのラベルの明示的な順序付きリストが与えられています。各ラベルは、仮想連結信号の成分を示します。ラベルの順序は、連結するのODUkの順序（ないタイムスロットの物理的な順序）を反映しなければなりません。この表現は、単一の（コンポーネント）リンク内に留まるためにバーチャルコンカチネーションを制限します。多重仮想連結信号の場合には、ラベルの第1のセットは第一の仮想連結信号の成分（がODUjトリビュタリスロット）を示し、ラベルの第2のセットは第二の仮想連結信号の成分（がODUjトリビュタリスロット）を示し、そのためオン。 GENERALIZED_LABELオブジェクトの（クラス民= 16、C-タイプ= 2）（セクション4.1で定義されるように）ラベルのこの順序付けられたリストは、32ビットのラベル値のシーケンスとして符号化されます。 ODUkのバーチャルコンカチネーションの場合に、ラベル値の数がNVC値によって決定されます。多重のODUk仮想連結は、さらに（サイズが等しい）セット当たりのラベルの数を決定するために、NMC値を使用します。
In case of multiplication (i.e., when using the MT field), the explicit ordered list of all labels taking part in the composed signal is given. The above representation limits multiplication to remain within a single (component) link. In case of multiplication of multiplexed virtually concatenated signals, the first set of labels indicates the components of the first multiplexed virtually concatenated signal, the second set of labels indicates components of the second multiplexed virtually concatenated signal, and so on. This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of multiplication of (equal) ODUk virtual concatenated signals, the number of label values per signal is determined by the NVC value. Multiplication of multiplexed (equal) ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size).
（MTのフィールドを使用する場合、すなわち、）乗算の場合には、合成信号に参加するすべてのラベルの明示的な順序付けられたリストが与えられます。上記の表現は、単一の（コンポーネント）リンク内に留まるために乗算を制限します。多重仮想連結信号の乗算の場合には、ラベルの第1のセットは最初の多重仮想連結信号の成分を示し、ラベルの第二のセットは2番目の多重化された仮想連結信号の成分を示し、そして。 GENERALIZED_LABELオブジェクトの（クラス民= 16、C-タイプ= 2）（セクション4.1で定義されるように）ラベルのこの順序付けられたリストは、32ビットのラベル値のシーケンスとして符号化されます。 （等しい）のODUk仮想連結信号の乗算の場合には、信号ごとのラベル値の数がNVC値によって決定されます。多重化（等しい）の乗算のODUk仮想連結は、さらに（サイズが等しい）セット当たりのラベルの数を決定するために、NMC値を使用します。
At the Optical Channel layer, the label space must be consistently defined as a flat space whose values reflect the local assignment of OCh identifiers that correspond to the OTM-n.m sub-interface signals (m = 1, 2 or 3). Note that these identifiers do not cover OChr because the corresponding Connection Function (OChr-CF) between OTM-nr.m/OTM-0r.m is not defined in [ITUT-G798].
光チャネル層に、ラベルスペースは、一貫し、その値OTM-n.mサブインターフェース信号（M = 1、2または3）に対応するのOCh識別子のローカル割り当てを反映フラット空間として定義されなければなりません。 OTM-nr.m / OTM-0r.m間の対応する接続機能（OChr-CF）を[ITUT-G798]で定義されていないため、これらの識別子はOChrをカバーしていないことに留意されたいです。
The OCh label space values are defined by either absolute values (i.e., channel identifiers or Channel ID, also referred to as wavelength identifiers) or relative values (channel spacing, also referred to as inter-wavelength spacing). The latter is strictly confined to a per-port label space, whereas the former could be defined as a local or a global (per node) label space. Such an OCh label space is applicable to both OTN Optical Channel layer and pre-OTN Optical Channel layer.
OChラベルスペース値は、絶対値によって定義される（すなわち、チャネル識別子またはチャンネルID、また、波長識別子と呼ぶ）、または相対値（また、インター波長間隔と呼ばれるチャネル間隔）。前者は、ローカルまたはグローバル（ノードごとに）ラベルスペースとして定義することができたのに対し、後者は厳密に、ポートごとのラベル空間に閉じ込められます。このようなのOChラベルスペースは、OTN光チャネル層とプレOTN光チャネル層の両方に適用可能です。
Optical Channel label encoding (and distribution) rules are defined in [RFC3471]. They MUST be used for the Upstream Label, the Suggested Label, and the Generalized Label.
光チャネルラベル符号化（及び分布）規則は[RFC3471]で定義されています。彼らは、上流ラベル、推奨ラベル、および一般ラベルを使用しなければなりません。
The following examples are given in order to illustrate the processing described in the previous sections of this document.
以下の実施例は、この文書の前のセクションで説明した処理を説明するために与えられています。
1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is directly transported in an OTU1 (OTU2 or OTU3), the upstream node requests results simply in an ODU1 (ODU2 or ODU3) signal request.
OTUkマッピング1.のODUk一ODU1（ODU2又はODU3）信号を直接OTU1（OTU2又はOTU3）に搬送され、上流ノード要求の結果を単にODU1（ODU2又はODU3）における信号要求。
In such conditions, the downstream node has to return a unique label because the ODU1 (ODU2 or ODU3) is directly mapped into the corresponding OTU1 (OTU2 or OTU3). Because a single ODUk signal is requested (Signal Type = 1, 2 or 3), the downstream node has to return a single ODUk label, which can be, for instance, one of the following when the Signal Type = 1:
このような条件では、下流ノードは、ODU1（ODU2又はODU3）を直接対応OTU1（OTU2又はOTU3）にマッピングされているため、一意のラベルを返すことがあります。単一のODUk信号（信号タイプ= 1、2または3）が要求されるため、下流ノードは、例えば、以下のいずれかとすることができる単一のODUkラベルを返す必要があるとき信号タイプ= 1：
- t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 - t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2 - t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3
- 単一のODU1を示すT3 = 0、T2 = 0、T1 = 1はOTU1にマッピング - OTU2にマッピング単一ODU2を示すT3 = 0、T2 = 1、T1 = 0 - T3 = 1、T2 = 0、T1 = 0 OTU3にマッピング単一ODU3を示します
2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed into the payload of a structured ODU2 (or ODU3), the upstream node requests results simply in an ODU1 signal request.
ODUk多重に2 ODU1（K> 1）一のODU1が構造ODU2（又はODU3）のペイロードに多重化され、上流ノード要求は、ODU1信号要求に単に生じます。
In such conditions, the downstream node has to return a unique label because the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or OPU3) and then mapped into the corresponding OTU2 (or OTU3). Because a single ODU1 multiplexed signal is requested (Signal Type = 1 and NMC = 1), the downstream node has to return a single ODU1 label, which can take, for instance, one of the following values:
このような条件では、下流ノードは、ODU1が1 ODTUG2（又はODTUG3）に多重化されているため、一意のラベルを返すことがあります。後者は、次いで、OPU2（またはOPU3）を介してODU2（又はODU3）にマッピングされ、対応するOTU2（又はOTU3）にマッピングされます。単一ODU1多重信号（信号タイプ= 1、NMC = 1）要求されるため、下流ノードは、例えば、以下のいずれかの値を取ることができ、単一のODU1ラベルを返すことがあります。
- t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2 - t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3 - t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3
- T3 = 0、T2 = 4、T1 = 0 ODTUG2の第三のTSでODU1を示し、 - T3 = 2、T2 = 0、T1 = 0 ODTUG3の最初のTSでODU1を示し、 - T3 = 7、T2 = 0、T1 = 0 ODTUG3の第六のTSでODU1を示し
3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is multiplexed into the payload of a structured ODU3, the upstream node requests results simply in an ODU2 signal request.
ODU3多重に3 ODU2一の非構造化ODU2が構造ODU3のペイロードに多重化された場合、上流ノード要求は、ODU2信号要求に単に生じます。
In such conditions, the downstream node has to return four labels since the ODU2 is multiplexed into one ODTUG3. The latter is mapped into an ODU3 (via OPU3) and then mapped into an OTU3. Since an ODU2 multiplexed signal is requested (Signal Type = 2, and NMC = 4), the downstream node has to return four ODU labels which can take for instance the following values:
このような条件では、下流ノードはODU2一ODTUG3に多重化されているので、4つのラベルを返すことがあります。後者は、（OPU3を介して）ODU3にマッピングした後、OTU3にマッピングされます。 ODU2多重信号（信号タイプ= 2、及びNMC = 4）が要求されるので、下流ノードは、例えば、以下の値を取ることができる4つのODUラベルを返すことがあります。
- t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3) - t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3) - t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3) - t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3)
- T3 = 18、T2 = 0、T1 = 0（ODTUG3の最初のTSでODU2の最初の部分） - T3 = 22、T2 = 0、T1 = 0（ODTUG3の第五のTSにおけるODU2の第二の部分） - T3 = 23 、T2 = 0、T1 = 0（ODTUG3の第六のTSにおけるODU2の3番目の部分） - T3 = 26、T2 = 0、T1 = 0（ODTUG3の第九のTSにおけるODU2の第四の部分）
4. When a single OCh signal of 40 Gbps is requested (Signal Type = 8), the downstream node must return a single wavelength label as specified in [RFC3471].
4. 40 Gbpsの単一のOCh信号が要求される（信号タイプ= 8）[RFC3471]で指定されるように、下流ノードは、単一波長ラベルを返さなければなりません。
5. When requesting multiple ODUk LSP (i.e., with a multiplier (MT) value > 1), an explicit list of labels is returned to the requestor node.
（乗算器（MT）値> 1、すなわち、）複数のODUk LSPを要求する場合5.ラベルの明示的なリストは、要求元ノードに返されます。
When the downstream node receives a request for a 4 x ODU1 signal (Signal Type = 1, NMC = 1 and MT = 4) multiplexed into an ODU3, it returns an ordered list of four labels to the upstream node: the first ODU1 label corresponds to the first signal of the LSP, the second ODU1 label corresponds to the second signal of the LSP, etc. For instance, the corresponding labels can take the following values:
下流ノードが4×ODU1信号の要求受信すると（信号タイプ= 1、NMC = 1、MT = 4）ODU3に多重化は、それが上流のノードに4つのラベルの順序付きリストを返す：最初のODU1ラベル対応しますLSPの第1の信号に、第二のODU1ラベルは、例えば、対応するラベルは、以下の値をとることができる等、LSPの第二の信号に対応します。
- First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3) - Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3) - Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3) - Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3)
- 最初ODU1：T3 = 2、T2 = 0、T1 = 0（ODTUG3の最初のTSにおける） - 第ODU1：T3 = 10、T2 = 0、T1 = 0（第ODTUG3のTSにおける） - 第三ODU1：T3 = 7、T2 = 0、= 0（ODTUG3の第六のTSで）T1 - 第四ODU1：T3 = 6、T2 = 0、= 0（ODTUG3の第五のTSで）T1
This section specifies the [RFC3473] protocol extensions needed to accommodate G.709 traffic parameters.
このセクションでは、G.709トラフィックパラメータに対応するために必要な[RFC3473]プロトコルの拡張を指定します。
The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC and FLOWSPEC objects. The same format is used both for SENDER_TSPEC object and FLOWSPEC objects. The content of the objects is defined above in Section 3.2. The objects have the following class and type for G.709:
G.709トラフィックパラメータは、G.709 SENDER_TSPECとFLOWSPECオブジェクトで運ばれます。同じフォーマットは、SENDER_TSPECオブジェクトとFLOWSPECオブジェクトの両方に使用されます。オブジェクトの内容はセクション3.2で上記に定義されています。オブジェクトは、G.709のために、次のクラスとタイプを持っています：
- G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5 - G.709 FLOWSPEC Object: Class = 9, C-Type = 5
- G.709 SENDER_TSPECオブジェクト：クラス= 12、C-タイプ= 5 - G.709 FLOWSPECオブジェクト：クラス= 9、Cタイプ= 5
There is no Adspec associated with the G.709 SENDER_TSPEC. Either the Adspec is omitted or an Int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment is used, see [RFC2210].
G.709 SENDER_TSPECに関連付けられADSPECはありません。どちらのADSPECが省略されているか、デフォルトの一般的な特性評価パラメータと保証サービスフラグメントとINT-SERV ADSPECが使用されて、[RFC2210]を参照してください。
For a particular sender in a session, the contents of the FLOWSPEC object received in a Resv message SHOULD be identical to the contents of the SENDER_TSPEC object received in the corresponding Path message. If the objects do not match, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error SHOULD be generated.
セッション中に特定の送信者のために、Resvメッセージで受信FLOWSPECオブジェクトの内容は、対応するPathメッセージで受信SENDER_TSPECオブジェクトの内容と同一であるべきです。オブジェクトが一致しない場合は、「トラフィック制御誤差/バート・フロースペック値」エラーでResvErrメッセージが生成されるべきです。
Intermediate and egress nodes MUST verify that the node itself, and the interfaces on which the LSP will be established, can support the requested Signal Type, NMC, and NVC values (as defined in Section 3.2). If the requested value(s) cannot be supported, the receiver node MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]).
中間及び出口ノード（セクション3.2で定義されるように）ノード自体、およびLSPが確立されたインタフェースは、要求された信号タイプ、NMC、およびNVC値をサポートできることを確認しなければなりません。要求された値（S）をサポートすることができない場合、受信ノードは、「トラフィック制御誤差/サービスサポートされていない」表示（[RFC2205]を参照）とのPathErrメッセージを生成しなければなりません。
In addition, if the MT field is received with a zero value, the node MUST generate a PathErr message with a "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]).
MTフィールドがゼロ値と受信した場合に加えて、ノードは、表示を「トラフィック制御誤差/不良のTSPEC値」とのPathErrメッセージを発生させなければなりません（[RFC2205]を参照）。
This document introduces no new security considerations to [RFC3473].
この文書では、[RFC3473]への新しいセキュリティ問題も紹介しません。
Two values have been defined by IANA for this document:
2つの値は、このドキュメントのためにIANAによって定義されています。
Two RSVP C-Types in registry:
レジストリ内の二つのRSVP-Cタイプ：
http://www.iana.org/assignments/rsvp-parameters
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／ｒｓｖｐーぱらめてｒｓ
- A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 - see Section 6.
- G.709 SENDER_TSPECオブジェクト：クラス= 12、C-タイプ= 5 - セクション6を参照。
- A G.709 FLOWSPEC object: Class = 9, C-Type = 5 - see Section 6.
- G.709 FLOWSPECオブジェクト：クラス= 9、Cタイプ= 5 - セクション6を参照。
IANA will also track the code-point spaces extended and/or updated by this document. For this purpose, the following new registry entries have been added in the newly requested registry entry: http://www.iana.org/assignments/gmpls-sig-parameters
IANAはまた、拡張および/または本文書によって更新されたコードポイントのスペースを追跡します。このためには、次の新しいレジストリエントリが新たに要求されたレジストリエントリに追加されました。http://www.iana.org/assignments/gmpls-sig-parameters
- LSP Encoding Type: Name: LSP Encoding Type Format: 8-bit number Values: [1..11] defined in [RFC3471] 12 defined in Section 3.1.1 13 defined in Section 3.1.1 Allocation Policy: [0..239] Assigned by IANA via IETF Standards Track RFC Action. [240..255] Assigned temporarily for Experimental Usage. These will not be registered with IANA
- LSP符号化タイプ：名：LSPエンコードタイプ形式：8ビットの数値：[1..11]のセクション3.1.1割り当てポリシーに定義され3.1.1 13で定義された[RFC3471] 12で定義される：[0 .. IETF標準化過程RFCアクションを経由して、IANAによって割り当てられた239]。 [240..255]実験用途のために一時的に割り当てられました。これらは、IANAに登録されることはありません
- Switching Type: Name: Switching Type Format: 8-bit number Values: defined in [RFC3471] Allocation Policy: [0..255] Assigned by IANA via IETF Standards Track RFC Action.
- 切換タイプ：名前：スイッチングタイプのフォーマット：8ビットの数値：[RFC3471]割り当てポリシーに定義されている：[0..255] IETF標準化過程RFCアクションを経由してIANAによって割り当てられます。
- Generalized PID (G-PID): Name: G-PID Format: 16-bit number Values: [0..31] defined in [RFC3471] [32..35] defined in [RFC3471] and updated by Section 3.1.3 [36..46] defined in [RFC3471] [47..58] defined in Section 3.1.3 Allocation Policy: [0..31743] Assigned by IANA via IETF Standards Track RFC Action. [31744..32767] Assigned temporarily for Experimental Usage
- 一般PID（G-PID）は、名前：G-PIDフォーマット：16ビットの数値：[0..31] [RFC3471] [32..35] [RFC3471]で定義されており、セクション3.1により更新で定義されています。 3 [36..46] [RFC3471]で定義された[47..58]セクション3.1.3割り当てポリシーに定義されている：[0..31743] IETF標準化過程RFCアクションを経由してIANAによって割り当てられます。 [31744..32767]実験用途のために一時的に割り当てられました
[32768..65535] Not assigned. Before any assignments can be
made in this range, there MUST be a Standards
Track RFC that specifies IANA Considerations
that covers the range being assigned.
Note: per [RFC3471], Section 3.1.1, standard Ethertype values are used as G-PIDs for packet and Ethernet LSPs.
注：3.1.1項、[RFC3471]あたり、標準イーサタイプ値はパケットとイーサネットのLSPのためのG-のPIDとして使用されます。
The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, Massimo Canali, Germano Gasparini, and Fong Liaw for their constructive comments and inputs as well as James Fu, Siva Sankaranarayanan, and Yangguang Xu for their useful feedback. Many thanks to Adrian Farrel for having thoroughly reviewed this document.
著者は、彼らの有用なフィードバックのために彼らの建設的なコメントや入力だけでなく、ジェームズ・フー、シヴァSankaranarayanan、そして陽光徐ためにジャン=ルーFerrant、マチューGarnot、マッシモカナリ、ジェルマーノガスパリーニ、およびフォンLiawに感謝したいと思います。徹底的にこの文書を見直したためエードリアンファレルに感謝します。
This document incorporates (upon agreement) material and ideas from a work in progress, "Common Label and Label Request Specification for Automatic Switched Transport Network", by Zhi Lin.
この文書は進行中の作業から（契約時に）材料やアイデアを取り入れ、志林で、「自動のための一般的なラベルとラベルの要求仕様は、トランスポートネットワークの交換しました」。
[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月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J.、RFC 2210、1997年9月 "IETF統合サービスとRSVPの使用"。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC3946] Mannie, E. and D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004.
[RFC3946]マニー、E.およびD. Papadimitriou、 "一般化マルチプロトコルラベルスイッチング（GMPLS）同期光ネットワーク（SONET）および同期デジタル階層（SDH）コントロールのための拡張機能"、RFC 3946、2004年10月。
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, September 2005.
[RFC4202] Kompella、K.、エド。そして、Y. Rekhter、エド。、RFC 4202「一般化マルチプロトコルラベルスイッチング（GMPLS）の支援でルーティング拡張機能」、2005年9月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]マニー、E.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）アーキテクチャ"、RFC 3945、2004年10月。
For information on the availability of the following documents, please see http://www.itu.int
次の書類の入手については、http://www.itu.intを参照してください。
[ITUT-G709] ITU-T, "Interface for the Optical Transport Network (OTN)," G.709 Recommendation (and Amendment 1), February 2001 (October 2001).
[ITUT-G709] ITUT、 "オプティカルトランスポートネットワーク（OTN）のためのインタフェース、" G.709勧告（および修正1）、2001年2月（2001年10月）。
[ITUT-G798] ITU-T, "Characteristics of Optical Transport Network Hierarchy Equipment Functional Blocks," G.798 Recommendation, October 2001.
[ITUT-G798] ITUT、 "オプティカルトランスポートネットワークの階層構造設備機能ブロックの特性、" G.798勧告、2001年10月。
Alberto Bellato (Alcatel) Via Trento 30, I-20059 Vimercate, Italy EMail: alberto.bellato@alcatel.it
トレント30経由アルベルトBellato（アルカテル）、I-20059ヴィメルカーテ、イタリアメール：alberto.bellato@alcatel.it
Sudheer Dharanikota (Consult) EMail: sudheer@ieee.org
Sudheer Dharanikota（ご相談ください）メール：sudheer@ieee.org
Michele Fontana (Alcatel) Via Trento 30, I-20059 Vimercate, Italy EMail: michele.fontana@alcatel.it
トレント30、I-20059ヴィメルカーテ、イタリアの電子メールを介してミケーレフォンタナ（アルカテル）：michele.fontana@alcatel.it
Nasir Ghani (Sorrento Networks) 9990 Mesa Rim Road, San Diego, CA 92121, USA EMail: nghani@sorrentonet.com
ナシルGhani（ソレントネットワークス）9990メサアナル道路、サンディエゴ、CA 92121、USA Eメール：nghani@sorrentonet.com
Gert Grammel (Alcatel) Lorenzstrasse, 10, 70435 Stuttgart, Germany EMail: gert.grammel@alcatel.de
ゲルトGrammel（アルカテル）ローレンツシュトラーセ10、70435シュトゥットガルト、ドイツEメール：gert.grammel@alcatel.de
Dan Guo (Turin Networks) 1415 N. McDowell Blvd, Petaluma, CA 94954, USA EMail: dguo@turinnetworks.com
ダン・郭（トリノネットワークス）1415 N.マクダウェルブルバード、ペタルマ、CA 94954、USA Eメール：dguo@turinnetworks.com
Juergen Heiles (Siemens) Hofmannstr. 51, D-81379 Munich, Germany EMail: juergen.heiles@siemens.com
ユルゲンハイレス（シーメンス）Hofmannstr。 51、D-81379ミュンヘン、ドイツEメール：juergen.heiles@siemens.com
Jim Jones (Alcatel) 3400 W. Plano Parkway, Plano, TX 75075, USA EMail: jim.d.jones@alcatel.com
ジム・ジョーンズ（アルカテル）3400 W.プラノパークウェイ、プラノ、TX 75075、USA Eメール：jim.d.jones@alcatel.com
Zhi-Wei Lin (Lucent) 101 Crawfords Corner Rd, Rm 3C-512 Holmdel, New Jersey 07733-3030, USA EMail: zwlin@lucent.com
志偉林（ルーセント）101 CrawfordsコーナーRdを、Rmの3C-512ホルムデル、ニュージャージー州07733から3030、USA Eメール：zwlin@lucent.com
Eric Mannie (Consult) EMail: eric_mannie@hotmail.com
エリック・マニー（ご相談ください）メール：eric_mannie@hotmail.com
Maarten Vissers (Alcatel) Lorenzstrasse, 10, 70435 Stuttgart, Germany EMail: maarten.vissers@alcalel.de
マールテンVissers（アルカテル）ローレンツシュトラーセ10、70435シュトゥットガルト、ドイツEメール：maarten.vissers@alcalel.de
Yong Xue (WorldCom) 22001 Loudoun County Parkway, Ashburn, VA 20147, USA EMail: yong.xue@wcom.com
ヨンジュン雪（ワールドコム）22001ラウドン郡パークウェイ、アッシュバーン、VA 20147、USA Eメール：yong.xue@wcom.com
Appendix A. Abbreviations
付録A.略語
BSNT Bit Stream without Octet Timing BSOT Bit Stream with Octet Timing CBR Constant Bit Rate ESCON Enterprise Systems Connection FC Fiber Channel FEC Forward Error Correction FICON Fiber Connection FSC Fiber Switch Capable GCC General Communication Channel GFP Generic Framing Procedure LSC Lambda Switch Capable LSP Label Switched Path MS Multiplex Section naOH non-associated Overhead NMC Number of Multiplexed Components NVC Number of Virtual Components OCC Optical Channel Carrier OCG Optical Carrier Group OCh Optical Channel (with full functionality) OChr Optical Channel (with reduced functionality) ODTUG Optical Date Tributary Unit Group ODU Optical Channel Data Unit OH Overhead OMS Optical Multiplex Section OMU Optical Multiplex Unit OOS OTM Overhead Signal OPS Optical Physical Section OPU Optical Channel Payload Unit OSC Optical Supervisory Channel OTH Optical Transport Hierarchy OTM Optical Transport Module OTN Optical Transport Network OTS Optical Transmission Section OTU Optical Channel Transport Unit OTUkV Functionally Standardized OTUk PPP Point to Point Protocol PSC Packet Switch Capable RES Reserved RS Regenerator Section TTI Trail Trace Identifier TDM Time Division Multiplex
オクテットタイミングでオクテットタイミングBSOTビットストリームなしBSNTビットストリームは、CBR固定ビットレートESCONエンタープライズシステムの接続FCファイバーチャネルFEC前方誤り訂正FICONのファイバ接続FSCファイバーができるGCC一般的な通信チャネルのGFPジェネリックフレーミング手順LSCラムダの切り替えはできるLSPラベルスイッチパスを切り替えます仮想コンポーネントOCC光チャネルキャリアOCG光キャリアグループのOCh光チャネル（フル機能を備えた）OChr光チャネル（縮小機能付き）ODTUGオプティカル日トリビュタリユニットグループODU光の多重コンポーネントNVC数のMS多重化セクションのNaOH非関連したオーバーヘッドNMC数チャネル・データ・ユニットOHオーバーヘッドOMS光多重化セクションOMUオプティカルマルチプレックスユニットOOS OTMオーバーヘッド信号OPS光物理セクションOPU光チャネルペイロードユニットOSC光監視チャネルOTH光トランスポート階層OTM光伝送モジュールOTNオプティカルトランスポートネットワークOTS光伝送セクションOTU光チャンネル交通ユニットOTUkV機能的に標準化されたのOTUk PPPポイントが可能RES予約RSリジェネレータセクションTTIの後続トレースID TDM時分割多重スイッチプロトコルPSCパケットをポイントします
Appendix B. G.709 Indexes
付録B. G.709インデックス
- Index k: The index "k" is used to represent a supported bit rate and the different versions of OPUk, ODUk and OTUk. k=1 represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s and k = 4 an approximate bit rate of 160 Gbit/s (under definition). The exact bit-rate values are in kbits/s:
- インデックスk：インデックス「k」はサポートされているビットレートとOPUkペイロード、のODUkとのOTUkの異なるバージョンを表すために使用されます。 K = 1は、2.5ギガビット/秒のおおよそのビットレートを表し、K = 2は、10ギガビット/秒、K 160 = 3近似ビット40ギガビット/秒の速度であり、k = 4近似ビットレートのおおよそのビットレートを表します（定義下）ギガビット/秒。正確なビットレート値はキロビット/秒です。
. OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322
。 OPU：K = 1：2 488 320.000、K = 2：9 995 276.962、K = 3：40 150 519.322
. ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983
。 TAC：K = 1：2 498 775 126、K = 2：10 037 273 924、K = 3：40 319 218 983
. OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559
。 OTU：= 1：2666 057 143 = 2：10 709 225 316、K = 3：43 018 413 559
- Index m: The index "m" is used to represent the bit rate or set of bit rates supported on the interface. This is a one or more digit "k", where each "k" represents a particular bit rate. The valid values for m are (1, 2, 3, 12, 23, 123).
- 指数m：インデックス「m」は、ビットレートを表すために使用されるか、またはインターフェイス上でサポートビットレートの集合です。これは、各「k」は、特定のビットレートを表す一つ以上の桁の「K」、です。 M個の有効な値は（1、2、3、12、23、123）です。
- Index n: The index "n" is used to represent the order of the OTM, OTS, OMS, OPS, OCG and OMU. This index represents the maximum number of wavelengths that can be supported at the lowest bit rate supported on the wavelength. It is possible that a reduced number of higher bit rate wavelengths are supported. The case n=0 represents a single channel without a specific wavelength assigned to the channel.
- 率n：屈折率 "n" はOTM、OTS、OMS、OPS、OCGとOMUの順序を表すために使用されます。このインデックスは、波長にサポートされる最低ビットレートでサポートすることができる波長の最大数を表します。より高いビットレートの波長の減少数がサポートされていることが可能です。場合はn = 0は、チャネルに割り当てられた特定の波長なく、単一のチャネルを表します。
- Index r: The index "r", if present, is used to indicate a reduced functionality OTM, OCG, OCC and OCh (non-associated overhead is not supported). Note that for n=0 the index r is not required as it implies always reduced functionality.
- インデックスr：インデックス「r」は、存在する場合、機能制限OTM、OCG、OCCとのOChを（非関連するオーバーヘッドがサポートされていない）を示すために使用されます。それは常に縮小機能を意味するように、N = 0のインデックスrが必要とされないことに留意されたいです。
Editor's Address
編集者の住所
Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium
ディミトリPapadimitriou（アルカテル）フランシスVellesplein 1 B-2018アントワープ、Velgiom
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
電話：+32 3 240-8491 Eメール：dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。