[要約] RFC 4328は、G.709光トランスポートネットワーク制御のための一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング拡張に関するものです。このRFCの目的は、G.709ネットワークでのGMPLSシグナリングの拡張を提供し、効率的な制御プレーンの実現を支援することです。
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
G.709光学輸送ネットワークのコントロール用の一般化マルチプロトコルラベルスイッチング（GMPLS）シグナル伝達拡張機能
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).
Copyright（c）The Internet Society（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シグナリングを拡張するために必要な技術固有の情報を説明します。また、いわゆるPre-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.
一般化されたマルチプロトコルラベルスイッチング（GMPLS）[RFC3945]は、MPLSをサポートパケットスイッチング対応（PSC）インターフェイスから拡張し、4つの新しいクラスのインターフェイスとスイッチングのサポートを含むように：レイヤー2スイッチング（L2SC）、時間分割多重（TDM）、Lambda Switch（LSC）、およびFiber-Switch（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.
このドキュメントでは、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 Pre-OTN開発により、G.709に完全に準拠していない光チャネル、デジタルラッパー、フォワードエラー補正（FEC）ソリューションを指します。Pre-OTN同期光ネットワーク（SONET）/同期デジタル階層（SDH）ベースのソリューションに関する詳細は、セクション/再生器セクションオーバーヘッド（SOH/RSOH）およびライン/マルチプレックスセクションオーバーヘッド（LOH/MSOH）の透明度を[RFC3946]でカバーしています。
*** Note on ITU-T G.709 Recommendation ***
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
さらに、読者は、[RFC3471]および[RFC3473]だけでなく、ITU-T [ITUT-G709]で使用されている用語に精通していると想定されています。このドキュメントで使用されている略語については、付録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（k = 1、2、3）へのOdukマッピングのサポートに加えて、G.709はOdukマルチプレックスをサポートしています。特に、Oduj（J = 1、2）のOduk（K> J）信号への多重化を指します。
- ODU1 into ODU2 multiplexing - ODU1 into ODU3 multiplexing - ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing
- ODU1からODU2多重化 - ODU1へのODU3マルチプレックス - ODU2へのODU3マルチプレックス - ODU1およびODU2へのODU3マルチプレックスへ
Adapting GMPLS to control G.709 OTN can be achieved by creating:
G.709 OTNを制御するためにGMPLを適応することは、作成することで実現できます。
- 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]で以前に定義された「デジタルラッパー」を拡張することにより、デジタルパスレイヤー。 - 「lambda」コンセプト（[rfc3471]で定義）をoch（光）パス層に拡張することにより、光パス層。 - ルートが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月）の修正バージョンで指定されているため、このドキュメントは、その目的に適したラベル空間定義も提案しています。また、対応するラベルスペースを定義するために、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]で定義されている一般化されたラベル要求には、共通部品（つまり、スイッチングテクノロジーに使用される）とテクノロジーに依存する部分（つまり、トラフィックパラメーター）が含まれます。このセクションでは、両方の部品を拡張して、G.709トランスポートプレーンの推奨に合わせてGMPLSを収容します（[ITUT-G709]を参照）。
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の推奨に対応するために、LSPエンコーディングタイプ、スイッチングタイプ、およびG-PID（一般化されたPID）値を拡張します[ITUT-G709]。
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で定義されているこれらの2つのレイヤーを「デジタルラッパー」および「ラムダ」コードとして反映できます。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準拠のデジタルラッパーレイヤーエンコーディングにのみ使用する必要があります。トランジットまたは出口ノード（Generalized_Label_Requestオブジェクトを含むパスメッセージの受信）は、「ルーティングの問題/サポートされていないエンコード」を備えた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準拠のラムダ層エンコーディングにのみ使用する必要があります。トランジットまたは出口ノード（一般化された_label_requestオブジェクトを含むパスメッセージの受信）は、「ルーティングの問題/サポートされていないエンコード」表示を持つ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非関連オーバーヘッド（NAOH）、つまりOTMオーバーヘッド信号（OOS）を使用する最終システムの要求された機能を示します。OTM-N.Mインターフェイス信号に多重化されました。
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).
ODUKスイッチング（したがってLSP）がTDMクラスに属し、OCHスイッチング（したがって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.
[RFC3471]で定義されているG-PID（16ビットフィールド）は、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：Octetタイミングを備えた非固有のクライアントビットストリーム（すなわち、マッピングのマッピング2.5、10、および40 Gbpsビットストリーム）-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でのデジタルパスの輸送 - エスコン：エンタープライズシステム接続-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で説明されているように、イーサニックフレーミング手順（GFP）を介してイーサネットMAC/PHYやIP/PPPなどのクライアントペイロードがカプセル化されると、専用の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:
Pre-OTN開発を含めるために、G-PIDフィールドは、以下のクライアントペイロードがいわゆるLambda LSPで輸送される場合、値の1つ（現在[RFC3471]で定義されています）を取得できます。
- Ethernet PHY (1 Gbps and 10 Gbps) - Fiber Channel
- Ethernet 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エンコードタイプフィールドで指定されている場合、テクノロジーに依存する（または単にトラフィックパラメーター）と呼ばれる情報は、一般化されたラベル要求に含まれるものに加えて運ばれます。
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)
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エンコーディングタイプが「lambda」（pre-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フェーズから得られた実質的に連結された信号について。結果の信号は最終信号と呼ばれます。
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.
特にODU2接続に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逆多重化）に捧げられています。これは、ODU1、ODU2、またはODU3の基本信号の数を示しており、ODUK-XV信号を形成するために事実上連結するように要求されています。定義上、これらの信号は同じタイプでなければなりません。
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信号タイプでのみ許容されます。したがって、G.709 OCH LSPが要求された場合、ゼロ（nvc = 0）に設定する必要があり、受信した場合は無視する必要があります。
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.
乗数フィールド（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が確立されるインターフェイスが要求された乗数値をサポートできることを確認する必要があります。要求された値をサポートできない場合、受信者ノードはPatherRメッセージを生成する必要があります（セクション6を参照）。
Zero is an invalid value for the MT field. If received, the node MUST generate a PathErr message (see Section 6).
ゼロは、MTフィールドの無効な値です。受信した場合、ノードはPatherrメッセージを生成する必要があります（セクション6を参照）。
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とは、ビットレートKでのフレームを指します。ここで、k = 1（2.5 gbpsの場合）、2（10 gbpsの場合）、または3（40 gbpsの場合）です。
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多重化とは、特にODUJ（J = 1、2）のOduj（k> j）への多重化を指します。
- ODU1 into ODU2 multiplexing - ODU1 into ODU3 multiplexing - ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing
- ODU1からODU2多重化 - ODU1へのODU3マルチプレックス - ODU2へのODU3マルチプレックス - ODU1およびODU2へのODU3マルチプレックスへ
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がOPUKにマッピングされたODUK支流ユニットグループ（つまり、ODU支流スロットで構成されたODTUG）に多重化されたときに、ODUKマルチプレックス（K> J）へのODUJが定義されます。結果の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ビット）：-T1 = 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]は、ODU1がODU2にマッピングしたODU1で使用される支流スロット（T2th-2）を示します（OPU2を介して）。-ODU3ではT2は有意ではありません（つまり、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ビット）：-T3 = 1は、さらに細分化されていないODU3信号を示します。-T3 = [2..17]は、ODU1がODU3にマッピングしたODU1で使用される支流スロット（T3th-1）を示します（OPU3を介して）。-T3 = [18..33]は、ODU2がODU3にマッピングされたODU2（OPU3を介して）で使用される支流スロット（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.
注：ODU2のODU3マルチプレックスへの場合、ODU2が使用する4つの支流スロットを識別するために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 = i）。これは、ODUK信号のマッピングと同じ順序のotukと呼ばれます。したがって、番号付けは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 -T3 = 0、T2 = 1、T1 = 0にマッピングされたODU1を示します。OTU2 -T3 = 1、T2 = 0、T1 = 0にマッピングされたODU2を示します。OTU3 -T3 = 0、T2 = 3、T1 = 0にマッピングされたODU3は、OTU2 -T3 = 5、T2 = 0にマッピングされたODU2（OPU2を介して）にマッピングされたODU2の2番目の支流スロットのODU1を示します。T1 = 0は、OTU3にマッピングされたODU3にマッピングされたODTUG3の4番目の支流スロットの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オブジェクトの単一の32ビットラベル値（セクション4.1で定義されている）としてエンコードされています（class-num = 16、c-type = 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の場合、1つのラベルのみに制限できます）。各ラベルは、多重化信号のコンポーネント（ODUJ支流スロット）を示します。ラベルの順序は、ODUJの順序をマルチプレックスに反映する必要があります（支流スロットの物理的順序ではありません）。この順序付けられたラベルのリストは、Generalized_Labelオブジェクト（Class-Num = 16、C-Type = 2）の32ビットラベル値のシーケンス（セクション4.1で定義）としてエンコードされます。
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が連結する順序を反映する必要があります（タイムスロットの物理的順序ではありません）。この表現は、仮想連結を制限して、単一の（コンポーネント）リンク内にとどまります。実質的に連結された信号が多重化された場合、最初のラベルのセットは、最初の実質的に連結された信号のコンポーネント（ODUJ支流スロット）を示します。ラベルの2番目のセットは、2番目の確実に吸収された信号のコンポーネント（ODUJ支流スロット）を示します。の上。この順序付けられたラベルのリストは、Generalized_Labelオブジェクト（Class-Num = 16、C-Type = 2）の32ビットラベル値のシーケンス（セクション4.1で定義）としてエンコードされます。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フィールドを使用する場合）、構成された信号に参加するすべてのラベルの明示的な順序付けリストが与えられます。上記の表現は、乗算を制限して、単一の（コンポーネント）リンク内にとどまります。多重化された事実上連結信号の乗算の場合、最初のラベルセットは、最初の多重化された実質的に連結された信号のコンポーネントを示します。ラベルの2番目のセットは、2番目の多重化された実質的に連結された信号のコンポーネントを示します。この順序付けられたラベルのリストは、Generalized_Labelオブジェクト（Class-Num = 16、C-Type = 2）の32ビットラベル値のシーケンス（セクション4.1で定義）としてエンコードされます。（等しい）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、波長識別子とも呼ばれるチャネルID）または相対値（チャネル間隔、波長間隔とも呼ばれるチャネル間隔）によって定義されます。後者は、ポートごとのラベルスペースに厳密に限定されていますが、前者はローカルまたはグローバル（ノードあたり）ラベルスペースとして定義できます。このようなOCHラベルスペースは、OTN光学チャネル層とPre-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.
1. OTUKマッピングのODUK：1つの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
- T3 = 0、T2 = 0、T1 = 1 OTU1 -T3 = 0、T2 = 1、T1 = 0にマッピングされた単一ODU1を示すOTU2 -T3 = 1、T2 = 0、T1 = 0にマッピングされた単一ODU2を示します。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.
2. ODU1へのODUK多重化（K> 1）：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 -t3 = 2、t2 = 0の3番目のtsのodu1を示します。0、t1 = 0は、odtug3の6番目の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.
3. ODU2へのODU3マルチプレックスへ：1つの非構造化された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が1つのODTUG3に多重化されるため、下流ノードは4つのラベルを返す必要があります。後者はODU3（OPU3経由）にマッピングされ、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の5番目のtsのODU2の第2部）-T3 = 23、T2 = 0、T1 = 0（ODTUG3の6番目のtsのODU2の第3部）-T3 = 26、T2 = 0、T1 = 0（ODTUG3の9番目のTSのODU2の4番目の部分）
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.
5. 複数のODUK LSP（つまり、乗数（MT）値> 1を含む）を要求すると、ラベルの明示的なリストがリクエスターノードに返されます。
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 x ODU1信号（信号タイプ= 1、NMC = 1、およびMT = 4）のリクエストを受信すると、ODU3に多重化された場合、上流ノードに4つのラベルの順序付きリストを返します：最初のODU1ラベルは対応しますLSPの最初の信号に対して、2番目のODU1ラベルはLSPなどの2番目の信号に対応します。たとえば、対応するラベルは次の値を取ることができます。
- 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） - 2番目のODU1：T3 = 10、T2 = 0、T1 = 0（ODTUG3の9番目のTS） - 3番目のODU1：T3 = 7、T2 = 0、T1 = 0（ODTUG3の6番目のts）-4番目のODU1：T3 = 6、T2 = 0、T1 = 0（ODTUG3の5番目のts）
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オブジェクト：class = 12、c-type = 5-g.709 flowspecオブジェクト：class = 9、c-type = 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オブジェクトの内容は、対応するパスメッセージで受信されたSender_TSPECオブジェクトの内容と同一である必要があります。オブジェクトが一致しない場合、「トラフィックコントロールエラー/不良FlowsPec値」エラーを備えた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]).
中間ノードと出口ノードは、ノード自体、およびLSPが確立されるインターフェイスが、要求された信号タイプ、NMC、およびNVC値をサポートできることを確認する必要があります（セクション3.2で定義）。要求された値をサポートできない場合、レシーバーノードは「トラフィックコントロールエラー/サービスのサポートされていない」表示を使用してPatherRメッセージを生成する必要があります（[RFC2205]を参照）。
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:
このドキュメントについては、IANAによって2つの値が定義されています。
Two RSVP C-Types in registry:
レジストリ内の2つの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オブジェクト：class = 12、c -type = 5-セクション6を参照してください。
- A G.709 FLOWSPEC object: Class = 9, C-Type = 5 - see Section 6.
- g.709 flowspecオブジェクト：class = 9、c -type = 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] [RFC3471]で定義されています。] IETF標準を介してIANAによって割り当てられたRFCアクションを追跡します。[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標準を介してIANAによって割り当てられたRFCアクションを追跡します。
- 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のセクション3.3の割り当てポリシー：[0..31743]で定義されているIETF標準を介してIETF標準を介して割り当てられたRFCアクション。[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.
[32768..65535]割り当てられていない。この範囲で割り当てを行う前に、割り当てられている範囲をカバーするIANAの考慮事項を指定する標準トラックRFCが必要です。
Note: per [RFC3471], Section 3.1.1, standard Ethertype values are used as G-PIDs for packet and Ethernet LSPs.
注：[RFC3471]、セクション3.1.1、標準倫理値は、パケットおよびイーサネット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.
著者は、Jean-Loup Ferrant、Mathieu Garnot、Massimo Canali、Germeno Gasparini、およびFong Liawの建設的なコメントと入力、James Fu、Siva Sankaranarayanan、Yangguang Xuについて有用なフィードバックについて感謝したいと思います。この文書を徹底的にレビューしてくれたAdrian Farrelに感謝します。
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.
このドキュメントには、Zhi Linによる「自動スイッチドトランスポートネットワークの共通ラベルおよびラベルリクエスト仕様」、進行中の作業からの資料とアイデアが組み込まれています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「IETF統合サービスでのRSVPの使用」、RFC 2210、1997年9月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、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] Berger、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] Mannie、E。およびD. Papadimitriou、「同期光学ネットワーク（SONET）および同期デジタル階層（SDH）コントロール用の一般化マルチプロトコルラベルスイッチング（GMPLS）拡張」、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.、ed。and Y. Rekhter、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年9月。
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、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] ITU-T、「光輸送ネットワークのインターフェイス（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] ITU-T、「光輸送ネットワーク階層装置の機能ブロックの特性」、G.798推奨、2001年10月。
Alberto Bellato (Alcatel) Via Trento 30, I-20059 Vimercate, Italy EMail: alberto.bellato@alcatel.it
トレント30経由のアルベルトベラート（アルカテル）、I-20059イタリアのVimercate Email：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
Michele Fontana（Alcatel）Trento 30、I-20059 Vimercate、Italy Email：michele.fontana@alcatel.it
Nasir Ghani (Sorrento Networks) 9990 Mesa Rim Road, San Diego, CA 92121, USA EMail: nghani@sorrentonet.com
Nasir Ghani（Sorrento Networks）9990 Mesa Rim Road、サンディエゴ、CA 92121、USAメール：nghani@sorrentonet.com
Gert Grammel (Alcatel) Lorenzstrasse, 10, 70435 Stuttgart, Germany EMail: gert.grammel@alcatel.de Dan Guo (Turin Networks) 1415 N. McDowell Blvd, Petaluma, CA 94954, USA EMail: dguo@turinnetworks.com
Gert Grammel（Alcatel）Lorenzstrasse、10、70435 Stuttgart、ドイツの電子メール：gert.grammel@alcatel.de dan guo（トリンネットワーク）1415 N. McDowell Blvd、CA 94954、USAメール：dguo@turinnetworks.com
Juergen Heiles (Siemens) Hofmannstr. 51, D-81379 Munich, Germany EMail: juergen.heiles@siemens.com
Juergen Heiles（Siemens）Hofmannstr。51、D-81379ミュンヘン、ドイツメール：juergen.heiles@siemens.com
Jim Jones (Alcatel) 3400 W. Plano Parkway, Plano, TX 75075, USA EMail: jim.d.jones@alcatel.com
Jim Jones（Alcatel）3400 W. Plano Parkway、Plano、TX 75075、USAメール：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
Zhi-Wei Lin（Lucent）101 Crawfords Corner Rd、RM 3C-512 Holmdel、ニュージャージー07733-3030、米国メール：zwlin@lucent.com
Eric Mannie (Consult) EMail: eric_mannie@hotmail.com
Eric Mannie（相談）メール：eric_mannie@hotmail.com
Maarten Vissers (Alcatel) Lorenzstrasse, 10, 70435 Stuttgart, Germany EMail: maarten.vissers@alcalel.de
Maarten Vissers（Alcatel）Lorenzstrasse、10、70435 Stuttgart、ドイツメール：maarten.vissers@alcalel.de
Yong Xue (WorldCom) 22001 Loudoun County Parkway, Ashburn, VA 20147, USA EMail: yong.xue@wcom.com
Yong Xue（Worldcom）22001 Loudoun County Parkway、Ashburn、VA 20147、USAメール：Yong.xue@wcom.com
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
- 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 gbit/sのおおよそのビットレートを表し、k = 2は10 gbit/sのおおよそのビットレート、k = 3 40 gbit/sのおおよそのビットレート、k = 4の約160のk = 4を表しますgbit/s（定義の下）。正確なビットレート値はkbits/sにあります：
. 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
. OTU: k=1: 2 666 057.143, k=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」は、インターフェイスでサポートされるビットレートのビットレートまたはセットを表すために使用されます。これは1桁以上の「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
Dimitri Papadimitriou（Alcatel）Francis Wellesplein 1、B-2018 Antwerpen、ベルギー
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。