[要約] RFC 7139は、進化するG.709光トランスポートネットワークの制御のためのGMPLSシグナリング拡張に関するものです。このRFCの目的は、G.709ネットワークの制御におけるGMPLSシグナリングの拡張を提案し、ネットワークの効率性と柔軟性を向上させることです。
Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 7139 Huawei
Updates: 4328 G. Zhang
Category: Standards Track CATR
ISSN: 2070-1721 S. Belotti
Alcatel-Lucent
D. Ceccarelli
Ericsson
K. Pithewan
Infinera
March 2014
GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks
進化するG.709光トランスポートネットワークを制御するためのGMPLSシグナリング拡張
Abstract
概要
ITU-T Recommendation G.709 [G709-2012] introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e, and ODUflex) and enhanced Optical Transport Network (OTN) flexibility.
ITU-T勧告G.709 [G709-2012]では、新しい光チャネルデータユニット（ODU）コンテナー（ODU0、ODU4、ODU2e、およびODUflex）が導入され、光トランスポートネットワーク（OTN）の柔軟性が強化されました。
This document updates the ODU-related portions of RFC 4328 to provide extensions to GMPLS signaling to control the full set of OTN features, including ODU0, ODU4, ODU2e, and ODUflex.
このドキュメントは、RFC 4328のODU関連部分を更新して、ODMP0、ODU4、ODU2e、ODUflexなどのOTN機能のフルセットを制御するGMPLSシグナリングへの拡張を提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7139.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7139で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. GMPLS Extensions for the Evolving G.709 -- Overview .............3
4. Generalized Label Request .......................................4
5. Extensions for Traffic Parameters for Evolving G.709 OTNs .......7
5.1. Usage of ODUflex(CBR) Traffic Parameters ...................8
5.2. Usage of ODUflex(GFP) Traffic Parameters ..................10
5.3. Notification on Errors of OTN-TDM Traffic Parameters ......11
6. Generalized Label ..............................................12
6.1. OTN-TDM Switching Type Generalized Label ..................12
6.2. Procedures ................................................14
6.2.1. Notification on Label Error ........................16
6.3. Supporting Virtual Concatenation and Multiplication .......17
6.4. Examples ..................................................17
7. Supporting Hitless Adjustment of ODUflex(GFP) ..................19
8. Operations, Administration, and Maintenance (OAM)
Considerations .................................................20
9. Control-Plane Backward-Compatibility Considerations ............20
10. Security Considerations .......................................21
11. IANA Considerations ...........................................21
12. References ....................................................23
12.1. Normative References .....................................23
12.2. Informative References ...................................24
13. Contributors ..................................................25
14. Acknowledgments ...............................................26
With the evolution and deployment of Optical Transport Network (OTN) technology, it is necessary that appropriate enhanced control technology support be provided for [G709-2012].
光トランスポートネットワーク（OTN）テクノロジの進化と展開に伴い、[G709-2012]には適切な拡張制御テクノロジサポートを提供する必要があります。
[RFC7062] provides a framework to allow the development of protocol extensions to support GMPLS and Path Computation Element (PCE) control of OTN as specified in [G709-2012]. Based on this framework, [RFC7096] evaluates the information needed by the routing and signaling process in OTNs to support GMPLS control of OTN.
[RFC7062]は、GMPLSおよび[G709-2012]で指定されているOTNのパス計算エレメント（PCE）制御をサポートするプロトコル拡張の開発を可能にするフレームワークを提供します。このフレームワークに基づいて、[RFC7096]は、OTNのルーティングおよびシグナリングプロセスがOTNのGMPLS制御をサポートするために必要な情報を評価します。
[RFC4328] describes the control technology details that are specific to the 2001 revision of the G.709 specification. This document updates the ODU-related portions of [RFC4328] to provide Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions to support control for [G709-2012].
[RFC4328]は、G.709仕様の2001年改訂に固有の制御技術の詳細を説明しています。このドキュメントでは、[RFC4328]のODU関連部分を更新して、[G709-2012]の制御をサポートするためのリソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）拡張機能を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
New features for the evolving OTN, for example, new ODU0, ODU2e, ODU4, and ODUflex containers, are specified in [G709-2012]. The corresponding new Signal Types are summarized below:
新しいODU0、ODU2e、ODU4、ODUflexコンテナなど、進化するOTNの新機能は、[G709-2012]で指定されています。対応する新しい信号タイプを以下にまとめます。
- Optical channel Transport Unit (OTUk): o OTU4
- 光チャネル転送ユニット（OTUk）：o OTU4
- Optical channel Data Unit (ODUk): o ODU0 o ODU2e o ODU4 o ODUflex
- おｐちかｌ ちゃんえｌ だた うにｔ （おづｋ）： お おづ０ お おづ２え お おづ４ お おづｆぇｘ
A new tributary slot granularity (i.e., 1.25 Gbps) is also described in [G709-2012]. Thus, there are now two tributary slot (TS) granularities for the foundation OTN ODU1, ODU2, and ODU3 containers. The TS granularity at 2.5 Gbps is used on the legacy interfaces while the new 1.25 Gbps is used on the new interfaces.
新しい支流スロットの粒度（つまり、1.25 Gbps）も[G709-2012]で説明されています。したがって、現在、基礎OTN ODU1、ODU2、およびODU3コンテナーには2つの支流スロット（TS）細分性があります。 2.5 GbpsのTS細分性はレガシーインターフェイスで使用され、新しい1.25 Gbpsは新しいインターフェイスで使用されます。
In addition to the support of ODUk mapping into OTUk (k = 1, 2, 3, 4), [G709-2012] encompasses the multiplexing of ODUj (j = 0, 1, 2, 2e, 3, flex) into an ODUk (k > j), as described in Section 3.1.2 of [RFC7062].
OTUk（k = 1、2、3、4）へのODUkマッピングのサポートに加えて、[G709-2012]はODUj（j = 0、1、2、2e、3、flex）のODUkへの多重化を包含します（k> j）、[RFC7062]のセクション3.1.2に記載。
Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk) (OPUk-Xv, k = 1/2/3, X = 1...256) is also supported by [G709-2012]. Note that VCAT of OPU0 / OPU2e / OPU4 / OPUflex is not supported per [G709-2012].
光チャネルペイロードユニットk（OPUk）の仮想連結（VCAT）（OPUk-Xv、k = 1/2/3、X = 1 ... 256）も[G709-2012]でサポートされています。 [G709-2012]では、OPU0 / OPU2e / OPU4 / OPUflexのVCATはサポートされていないことに注意してください。
[RFC4328] describes GMPLS signaling extensions to support the control for the 2001 revision of the G.709 specification. However, [RFC7096] does not provide the means to signal all the new Signal Types and related mapping and multiplexing functionalities. Moreover, it supports only the deprecated auto-MSI (Multiframe Structure Identifier) mode, which assumes that the Tributary Port Number (TPN) is automatically assigned in the transmit direction and not checked in the receive direction.
[RFC4328]は、G.709仕様の2001年リビジョンの制御をサポートするGMPLSシグナリング拡張について説明しています。ただし、[RFC7096]は、すべての新しい信号タイプと関連するマッピングおよび多重化機能を通知する手段を提供しません。さらに、サポートされていない自動MSI（Multiframe Structure Identifier）モードのみをサポートします。これは、トリビュタリポート番号（TPN）が送信方向に自動的に割り当てられ、受信方向ではチェックされないことを前提としています。
This document extends the G.709 Traffic Parameters described in [RFC4328] and presents a new flexible and scalable OTN-TDM Generalized Label format. (Here, TDM refers to Time-Division Multiplexing.) Additionally, procedures about Tributary Port Number assignment through the control plane are also provided in this document.
このドキュメントは、[RFC4328]で説明されているG.709トラフィックパラメータを拡張し、新しい柔軟でスケーラブルなOTN-TDM Generalized Label形式を提示します。 （ここでは、TDMは時分割多重化を指します。）さらに、コントロールプレーンを介したトリビュタリポート番号の割り当てに関する手順もこのドキュメントに記載されています。
The GENERALIZED_LABEL_REQUEST object, as described in [RFC3471], carries the Label Switched Path (LSP) Encoding Type, the Switching Type, and the Generalized Protocol Identifier (G-PID).
[RFC3471]で説明されているように、GENERALIZED_LABEL_REQUESTオブジェクトは、Label Switched Path（LSP）エンコーディングタイプ、スイッチングタイプ、およびGeneralized Protocol Identifier（G-PID）を伝送します。
[RFC4328] extends the GENERALIZED_LABEL_REQUEST object, introducing two new code-points for the LSP Encoding Type (i.e., G.709 ODUk (Digital Path) and G.709 Optical Channel) and adding a list of G-PID values in order to accommodate the 2001 revision of the G.709 specification.
[RFC4328]はGENERALIZED_LABEL_REQUESTオブジェクトを拡張し、LSPエンコーディングタイプ（G.709 ODUk（デジタルパス）とG.709光チャネル）に2つの新しいコードポイントを導入し、対応するためにG-PID値のリストを追加しますG.709仕様の2001年改訂。
This document follows these extensions and introduces a new Switching Type to indicate the ODUk Switching Capability [G709-2012] in order to support backward compatibility with [RFC4328], as described in [RFC7062]. The new Switching Type (OTN-TDM Switching Type) is defined in [RFC7138].
このドキュメントはこれらの拡張に従い、[RFC7062]で説明されている[RFC4328]との下位互換性をサポートするために、ODUkスイッチング機能[G709-2012]を示す新しいスイッチングタイプを紹介します。新しいスイッチングタイプ（OTN-TDMスイッチングタイプ）は、[RFC7138]で定義されています。
This document also updates the G-PID values defined in [RFC4328]:
このドキュメントは、[RFC4328]で定義されているG-PID値も更新します。
Value G-PID Type
----- ----------
47 Type field updated from "G.709 ODUj" to "ODU-2.5G" to indicate transport of Digital Paths (e.g., at 2.5, 10, and 40 Gbps) via 2.5 Gbps TS granularity.
47タイプフィールドが「G.709 ODUj」から「ODU-2.5G」に更新され、2.5 Gbps TSの細分性によるデジタルパスの転送を示します（例：2.5、10、40 Gbps）。
56 Type field updated from "ESCON" to "SBCON/ESCON" to align with [G709-2012] payload type 0x1A.
[G709-2012]ペイロードタイプ0x1Aに合わせて、タイプフィールドが「ESCON」から「SBCON / ESCON」に更新されました。
Note: Value 47 includes mapping of Synchronous Digital Hierarchy (SDH).
注：値47には、同期デジタル階層（SDH）のマッピングが含まれます。
In the case of ODU multiplexing, the Lower Order ODU (LO ODU) (i.e., the client signal) may be multiplexed into a Higher Order ODU (HO ODU) via 1.25G TS granularity, 2.5G TS granularity, or ODU-any. Since the G-PID type "ODUk" defined in [RFC4328] is only used for 2.5 Gbps TS granularity, two new G-PID types are defined as follows:
ODU多重化の場合、低次ODU（LO ODU）（つまり、クライアント信号）は、1.25G TS細分性、2.5G TS細分性、またはODU-anyを介して高次ODU（HO ODU）に多重化されます。 [RFC4328]で定義されているG-PIDタイプ「ODUk」は、2.5 Gbps TSの粒度にのみ使用されるため、2つの新しいG-PIDタイプが次のように定義されています。
- ODU-1.25G: Transport of Digital Paths at 1.25, 2.5, 10, 40, and 100 Gbps via 1.25 Gbps TS granularity.
- ODU-1.25G：1.25 GbpsのTS細分性による1.25、2.5、10、40、および100 Gbpsのデジタルパスの転送。
- ODU-any: Transport of Digital Paths at 1.25, 2.5, 10, 40, and 100 Gbps via 1.25 or 2.5 Gbps TS granularity (i.e., the fallback procedure is enabled and the default value of 1.25 Gbps TS granularity can fall back to 2.5 Gbps if needed).
- ODU-any：1.25、2.5、10、40、および100 Gbpsでのデジタルパスの転送（1.25または2.5 Gbps TS粒度による）（つまり、フォールバック手順が有効になり、デフォルト値の1.25 Gbps TS粒度は2.5 Gbpsにフォールバックできます）必要に応じて）。
The full list of payload types defined in [G709-2012] and their mapping to existing and new G-PID types are as follows:
[G709-2012]で定義されているペイロードタイプの完全なリストと、既存および新しいG-PIDタイプへのマッピングは次のとおりです。
G.709
Payload
Type G-PID Type/Comment LSP Encoding
==== ===== ===================== ===================
0x01 No standard value
0x02 49 CBRa G.709 ODUk
0x03 50 CBRb G.709 ODUk
0x04 32 ATM G.709 ODUk
0x05 59 Framed GFP G.709 ODUk
54 Ethernet MAC (framed GFP) G.709 ODUk
70 64B/66B GFP-F Ethernet G.709 ODUk (k=2)
0x06 Not signaled
0x07 55 Ethernet PHY G.709 ODUk (k=0,3,4)
(transparent GFP)
0x08 58 Fiber Channel G.709 ODUk (k=2e)
0x09 59 Framed GFP G.709 ODUk (k=2)
70 64B/66B GFP-F Ethernet G.709 ODUk (k=2)
0x0A 60 STM-1 G.709 ODUk (k=0)
0x0B 61 STM-4 G.709 ODUk (k=0)
0x0C 58 Fiber Channel G.709 ODUk (k=0)
0x0D 58 Fiber Channel G.709 ODUk (k=1)
0x0E 58 Fiber Channel G.709 ODUflex
0x0F 58 Fiber Channel G.709 ODUflex
0x10 51 BSOT G.709 ODUk
0x11 52 BSNT G.709 ODUk
0x12 62 InfiniBand G.709 ODUflex
0x13 62 InfiniBand G.709 ODUflex
0x14 62 InfiniBand G.709 ODUflex
0x15 63 Serial Digital Interface G.709 ODUk (k=0)
0x16 64 SDI/1.001 G.709 ODUk (k=1)
0x17 63 Serial Digital Interface G.709 ODUk (k=1)
0x18 64 SDI/1.001 G.709 ODUflex
0x19 63 Serial Digital Interface G.709 ODUflex
0x1A 56 SBCON/ESCON G.709 ODUk (k=0)
0x1B 65 DVB_ASI G.709 ODUk (k=0)
0x1C 58 Fiber Channel G.709 ODUk
0x20 47 G.709 ODU-2.5G G.709 ODUk (k=2,3)
66 G.709 ODU-1.25G G.709 ODUk (k=1)
0x21 66 G.709 ODU-1.25G G.709 ODUk (k=2,3,4)
67 G.709 ODU-any G.709 ODUk (k=2,3)
0x55 No standard value
0x66 No standard value
0x80-0x8F No standard value
0xFD 68 Null Test G.709 ODUk
0xFE 69 Random Test G.709 ODUk
0xFF No standard value
Note: Values 59 and 70 include mapping of SDH.
注：値59および70には、SDHのマッピングが含まれます。
Note that the mapping types for ODUj into OPUk are unambiguously per Table 7-10 of [G709-2012], so there is no need to carry mapping type information in the signaling.
ODUjからOPUkへのマッピングタイプは、[G709-2012]の表7-10に従って明確であるため、シグナリングでマッピングタイプ情報を伝送する必要がないことに注意してください。
Note also that additional information on G.709 client mapping can be found in [G7041].
G.709クライアントマッピングに関する追加情報は、[G7041]に記載されていることにも注意してください。
The Traffic Parameters for the OTN-TDM-capable Switching Type are carried in the OTN-TDM SENDER_TSPEC object in the Path message and the OTN-TDM FLOWSPEC object in the Resv message. The objects have the following class and type:
OTN-TDM対応のスイッチングタイプのトラフィックパラメータは、PathメッセージのOTN-TDM SENDER_TSPECオブジェクトとResvメッセージのOTN-TDM FLOWSPECオブジェクトで伝達されます。オブジェクトには次のクラスとタイプがあります。
- OTN-TDM SENDER_TSPEC object: Class = 12, C-Type = 7 - OTN-TDM FLOWSPEC object: Class = 9, C-Type = 7
- OTN-TDM SENDER_TSPECオブジェクト：クラス= 12、Cタイプ= 7-OTN-TDM FLOWSPECオブジェクト：クラス= 9、Cタイプ= 7
The format of Traffic Parameters in these two objects is defined as follows:
これら2つのオブジェクトのトラフィックパラメータの形式は、次のように定義されています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit_Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signal Type: 8 bits
信号タイプ：8ビット
As defined in Section 3.2.1 of [RFC4328], with the following additional values:
[RFC4328]のセクション3.2.1で定義されているとおり、次の追加の値が含まれます。
Value Type
----- ----
4 ODU4 (i.e., 100 Gbps)
9 OCh at 100 Gbps
10 ODU0 (i.e., 1.25 Gbps)
11 ODU2e (i.e., 10 Gbps for FC1200 and GE LAN)
12-19 Reserved (for future use)
20 ODUflex(CBR) (i.e., 1.25*N Gbps)
21 ODUflex(GFP-F), resizable (i.e., 1.25*N Gbps)
22 ODUflex(GFP-F), non-resizable (i.e., 1.25*N Gbps)
23-255 Reserved (for future use)
Note: Above, CBR stands for Constant Bit Rate, and GFP-F stands for Generic Framing Procedure - Framed.
注：上記では、CBRは固定ビットレートを表し、GFP-FはGeneric Framing Procedure-Framedを表します。
NVC (Number of Virtual Components): 16 bits
NVC（仮想コンポーネントの数）：16ビット
As defined in Section 3.2.3 of [RFC4328]. This field MUST be set to 0 for ODUflex Signal Types.
[RFC4328]のセクション3.2.3で定義されています。 ODUflex信号タイプの場合、このフィールドは0に設定する必要があります。
Multiplier (MT): 16 bits
乗算器（MT）：16ビット
As defined in Section 3.2.4 of [RFC4328]. This field MUST be set to 1 for ODUflex Signal Types.
[RFC4328]のセクション3.2.4で定義されています。 ODUflex信号タイプでは、このフィールドを1に設定する必要があります。
Bit_Rate: 32 bits
Bit_Rate：32ビット
In the case of ODUflex, including ODUflex(CBR) and ODUflex(GFP) Signal Types, this field indicates the nominal bit rate of ODUflex expressed in bytes per second, encoded as a 32-bit IEEE single-precision floating-point number (referring to [RFC4506] and [IEEE]). For other Signal Types, this field MUST be set to zero on transmission, MUST be ignored on receipt, and SHOULD be passed unmodified by transit nodes.
ODUflex（CBR）およびODUflex（GFP）信号タイプを含むODUflexの場合、このフィールドは、32ビットIEEE単精度浮動小数点数として符号化された、毎秒のバイト数で表されるODUflexの公称ビットレートを示します（参照[RFC4506]および[IEEE]に）。他のシグナルタイプの場合、このフィールドは送信時にゼロに設定する必要があり、受信時に無視する必要があり、中継ノードによって変更されずに渡される必要があります。
In the case of ODUflex(CBR), the Bit_Rate information carried in the ODUflex Traffic Parameters MUST be used to determine the actual bandwidth of ODUflex(CBR) (i.e., Bit_Rate * (1 +/- Tolerance)). Therefore, the total number of tributary slots N in the HO ODUk link can be reserved correctly. Where:
ODUflex（CBR）の場合、ODUflexトラフィックパラメーターで伝達されるBit_Rate情報を使用して、ODUflex（CBR）の実際の帯域幅を決定する必要があります（つまり、Bit_Rate *（1 +/- Tolerance））。したがって、HO ODUkリンクの支流スロットの総数Nを正しく予約できます。どこ：
N = Ceiling of
ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance)
---------------------------------------------------------------------
ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
In this formula, the ODUflex(CBR) nominal bit rate is the bit rate of the ODUflex(CBR) on the line side, i.e., the client signal bit rate after applying the 239/238 factor (according to Clause 7.3, Table 7-2 of [G709-2012]) and the transcoding factor T (if needed) on the CBR client. According to Clauses 17.7.3, 17.7.4, and 17.7.5 of [G709-2012]:
この式では、ODUflex（CBR）の公称ビットレートは、回線側のODUflex（CBR）のビットレート、つまり、239/238係数を適用した後のクライアント信号のビットレートです（7.3の表7に従って、表7- [G709-2012]の2）およびCBRクライアントのトランスコーディング係数T（必要な場合）。 [G709-2012]の17.7.3、17.7.4、17.7.5節によると、
ODUflex(CBR) nominal bit rate = CBR client bit rate * (239/238) / T
The ODTUk.ts (Optical channel Data Tributary Unit k with ts tributary slots) nominal bit rate is the nominal bit rate of the tributary slot of ODUk, as shown in Table 1 (referring to Table 7-7 of [G709-2012]).
ODTUk.ts（tsトリビュタリスロットを持つ光チャネルデータトリビュタリユニットk）の公称ビットレートは、表1に示すように、ODUkのトリビュタリスロットの公称ビットレートです（[G709-2012]の表7-7を参照）。 。
ODUk.ts Minimum Nominal Maximum
-----------------------------------------------------------
ODU2.ts 1,249,384.632 1,249,409.620 1,249,434.608
ODU3.ts 1,254,678.635 1,254,703.729 1,254,728.823
ODU4.ts 1,301,683.217 1,301,709.251 1,301,735.285
Table 1: Actual TS Bit Rate of ODUk (in Kbps)
表1：ODUkの実際のTSビットレート（Kbps）
Note that:
ご了承ください：
Minimum bit rate of ODUTk.ts = ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
ODUTk.tsの最小ビットレート= ODTUk.ts公称ビットレート*（1-HO OPUkビットレート許容値）
Maximum bit rate of ODTUk.ts = ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance)
ODTUk.tsの最大ビットレート= ODTUk.ts公称ビットレート*（1 + HO OPUkビットレート許容値）
Where: HO OPUk bit rate tolerance = 20 ppm (parts per million)
HO OPUkビットレートの許容値= 20 ppm（100万分の1）
Note that the bit rate tolerance is implicit in Signal Type and the ODUflex(CBR) bit rate tolerance is fixed and it is equal to 100 ppm as described in Table 7-2 of [G709-2012].
[G709-2012]の表7-2で説明されているように、ビットレートの許容値は信号タイプで暗黙的であり、ODUflex（CBR）ビットレートの許容値は固定され、100 ppmに等しいことに注意してください。
Therefore, a node receiving a Path message containing an ODUflex(CBR) nominal bit rate can allocate a precise number of tributary slots and set up the cross-connection for the ODUflex service.
したがって、ODUflex（CBR）公称ビットレートを含むPathメッセージを受信するノードは、正確な数のトリビュタリスロットを割り当て、ODUflexサービスのクロス接続をセットアップできます。
Note that for different ODUk, the bit rates of the tributary slots are different, so the total number of tributary slots to be reserved for the ODUflex(CBR) may not be the same on different HO ODUk links.
ODUkが異なると、トリビュタリスロットのビットレートが異なるため、ODUflex（CBR）に予約されるトリビュタリスロットの総数は、異なるHO ODUkリンクで同じにならない場合があります。
An example is given below to illustrate the usage of ODUflex(CBR) Traffic Parameters.
ODUflex（CBR）トラフィックパラメータの使用法を示すために、例を以下に示します。
+-----+ +---------+ +-----+
| +-------------+ +-----+ +-------------+ |
| +=============+\| ODU |/+=============+ |
| +=============+/| flex+-+=============+ |
| +-------------+ | |\+=============+ |
| +-------------+ +-----+ +-------------+ |
| | | | | |
| | ....... | | ....... | |
| A +-------------+ B +-------------+ C |
+-----+ HO ODU4 +---------+ HO ODU2 +-----+
=========: TSs occupied by ODUflex
---------: available TSs
Figure 1: Example of ODUflex(CBR) Traffic Parameters
図1：ODUflex（CBR）トラフィックパラメータの例
As shown in Figure 1, assume there is an ODUflex(CBR) service requesting a bandwidth of 2.5 Gbps from node A to node C.
図1に示すように、ノードAからノードCに2.5 Gbpsの帯域幅を要求するODUflex（CBR）サービスがあるとします。
In other words, the ODUflex Traffic Parameters indicate that Signal Type is 20 (ODUflex(CBR)) and Bit_Rate is 2.5 Gbps (note that the tolerance is not signaled as explained above).
言い換えると、ODUflexトラフィックパラメータは、信号タイプが20（ODUflex（CBR））であり、Bit_Rateが2.5 Gbpsであることを示しています（上で説明したように、許容値は通知されないことに注意してください）。
- On the HO ODU4 link between node A and B:
- ノードAとノードBの間のHO ODU4リンク：
The maximum bit rate of the ODUflex(CBR) equals 2.5 Gbps * (1 + 100 ppm), and the minimum bit rate of the tributary slot of ODU4 equals 1,301,683.217 Kbps, so the total number of tributary slots N1 to be reserved on this link is:
ODUflex（CBR）の最大ビットレートは2.5 Gbps *（1 + 100 ppm）に等しく、ODU4のトリビュタリスロットの最小ビットレートは1,301,683.217 Kbpsに等しいため、トリビュタリスロットの総数N1はこのリンクで予約されますです：
N1 = ceiling (2.5 Gbps * (1 + 100 ppm) / 1,301,683.217 Kbps) = 2
- On the HO ODU2 link between node B and C:
- ノードBとCの間のHO ODU2リンク：
The maximum bit rate of the ODUflex equals 2.5 Gbps * (1 + 100 ppm), and the minimum bit rate of the tributary slot of ODU2 equals 1,249,384.632 Kbps, so the total number of tributary slots N2 to be reserved on this link is:
ODUflexの最大ビットレートは2.5 Gbps *（1 + 100 ppm）に等しく、ODU2のトリビュタリスロットの最小ビットレートは1,249,384.632 Kbpsに等しいため、このリンクで予約されるトリビュタリスロットN2の総数は次のとおりです。
N2 = ceiling (2.5 Gbps * (1 + 100 ppm) / 1,249,384.632 Kbps) = 3
[G709-2012] recommends that the ODUflex(GFP) fill an integral number of tributary slots of the smallest HO ODUk path over which the ODUflex(GFP) may be carried, as shown in Table 2.
[G709-2012]は、表2に示すように、ODUflex（GFP）がODUflex（GFP）を伝送できる最小のHO ODUkパスの支流スロットの整数個を埋めることを推奨しています。
ODU Type | Nominal Bit Rate | Tolerance
---------------------------------+------------------+-----------
ODUflex(GFP) of n TSs, 1<=n<=8 | n * ODU2.ts | +/-100 ppm
ODUflex(GFP) of n TSs, 9<=n<=32 | n * ODU3.ts | +/-100 ppm
ODUflex(GFP) of n TSs, 33<=n<=80 | n * ODU4.ts | +/-100 ppm
Table 2: Recommended ODUflex(GFP) Bit Rates and Tolerance
表2：推奨されるODUflex（GFP）ビットレートと許容値
According to this table, the Bit_Rate field for ODUflex(GFP) MUST be equal to one of the 80 values listed below:
この表によると、ODUflex（GFP）のBit_Rateフィールドは、以下にリストされている80個の値のいずれかに等しい必要があります。
1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts;
9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts;
33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts.
In this way, the number of required tributary slots for the ODUflex(GFP) (i.e., the value of "n" in Table 2) can be deduced from the Bit_Rate field.
このようにして、ODUflex（GFP）に必要なトリビュタリスロットの数（つまり、表2の「n」の値）は、Bit_Rateフィールドから推定できます。
There is no Adspec associated with the OTN-TDM SENDER_TSPEC object. Either the Adspec is omitted or an Int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment is used (see [RFC2210]).
OTN-TDM SENDER_TSPECオブジェクトに関連付けられたAdspecはありません。 Adspecが省略されるか、デフォルトの一般的な特性化パラメーターと保証されたサービスフラグメントを持つInt-serv Adspecが使用されます（[RFC2210]を参照）。
For a particular sender in a session, the contents of the OTN-TDM FLOWSPEC object received in a Resv message SHOULD be identical to the contents of the OTN-TDM 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 MUST be generated.
セッションの特定の送信者の場合、Resvメッセージで受信したOTN-TDM FLOWSPECオブジェクトの内容は、対応するPathメッセージで受信したOTN-TDM SENDER_TSPECオブジェクトの内容と同じである必要があります。オブジェクトが一致しない場合、「Traffic Control Error / Bad Flowspec value」エラーを含む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, NVC, and Bit_Rate values. 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が確立されるインターフェイスが、要求された信号タイプ、NVC、およびBit_Rate値をサポートできることを確認する必要があります。要求された値をサポートできない場合、受信ノードは、「トラフィック制御エラー/サービスがサポートされていません」という表示のある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]を参照）。
Further, if the Signal Type is not ODU1, ODU2, or ODU3, and the NVC field is not 0, the node MUST generate a PathErr message with a "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]).
さらに、Signal TypeがODU1、ODU2、またはODU3でなく、NVCフィールドが0でない場合、ノードは「Traffic Control Error / Bad Tspec value」を示すPathErrメッセージを生成する必要があります（[RFC2205]を参照）。
This section defines the format of the OTN-TDM Generalized Label.
このセクションでは、OTN-TDM一般化ラベルの形式を定義します。
The following is the GENERALIZED_LABEL object format that MUST be used with the OTN-TDM Switching Type:
以下は、OTN-TDMスイッチングタイプで使用する必要があるGENERALIZED_LABELオブジェクト形式です。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bit Map ...... ~
~ ...... | Padding Bits ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OTN-TDM GENERALIZED_LABEL object is used to indicate how the LO ODUj signal is multiplexed into the HO ODUk link. Note that the LO OUDj Signal Type is indicated by Traffic Parameters, while the type of HO ODUk link is identified by the selected interface carried in the IF_ID RSVP_HOP object.
OTN-TDM GENERALIZED_LABELオブジェクトは、LO ODUj信号がどのようにHO ODUkリンクに多重化されるかを示すために使用されます。 LO OUDj信号タイプはトラフィックパラメータで示され、HO ODUkリンクのタイプはIF_ID RSVP_HOPオブジェクトで伝送される選択されたインターフェースで識別されることに注意してください。
TPN: 12 bits
TPN：12ビット
Indicates the TPN for the assigned tributary slot(s).
割り当てられたトリビュタリスロットのTPNを示します。
- In the case of an LO ODUj multiplexed into an HO ODU1/ODU2/ODU3, only the lower 6 bits of the TPN field are significant; the other bits of the TPN field MUST be set to 0.
- HO ODU1 / ODU2 / ODU3に多重化されたLO ODUjの場合、TPNフィールドの下位6ビットのみが重要です。 TPNフィールドの他のビットは0に設定する必要があります。
- In the case of an LO ODUj multiplexed into an HO ODU4, only the lower 7 bits of the TPN field are significant; the other bits of the TPN field MUST be set to 0.
- HO ODU4に多重化されたLO ODUjの場合、TPNフィールドの下位7ビットのみが重要です。 TPNフィールドの他のビットは0に設定する必要があります。
- In the case of ODUj mapped into OTUk (j=k), the TPN is not needed, and this field MUST be set to 0.
- OTUk（j = k）にマップされたODUjの場合、TPNは不要であり、このフィールドは0に設定する必要があります。
Per [G709-2012], the TPN is used to allow for correct demultiplexing in the data plane. When an LO ODUj is multiplexed into an HO ODUk occupying one or more TSs, a new TPN value is configured at the two ends of the HO ODUk link and is put into the related MSI byte(s) in the OPUk overhead at the (traffic) ingress end of the link, so that the other end of the link can learn which TS(s) is/are used by the LO ODUj in the data plane.
[G709-2012]に従い、TPNはデータプレーンでの正しい逆多重化を可能にするために使用されます。 LO ODUjが1つ以上のTSを占有するHO ODUkに多重化されると、新しいTPN値がHO ODUkリンクの両端で構成され、（トラフィック）のOPUkオーバーヘッド内の関連するMSIバイトに配置されます。 ）リンクの入口側。これにより、リンクのもう一方の端は、データプレーンのLO ODUjで使用されているTSを学習できます。
According to [G709-2012], the TPN field MUST be set according to the following tables:
[G709-2012]によると、TPNフィールドは次の表に従って設定する必要があります：
+-------+-------+----+-------------------------------------------+
|HO ODUk|LO ODUj|TPN | TPN Assignment Rules |
+-------+-------+----+-------------------------------------------+
| ODU2 | ODU1 |1-4 |Fixed, = TS# occupied by ODU1 |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-16|Fixed, = TS# occupied by ODU1 |
| ODU3 +-------+----+-------------------------------------------+
| | ODU2 |1-4 |Flexible, != other existing LO ODU2s' TPNs |
+-------+-------+----+-------------------------------------------+
Table 3: TPN Assignment Rules (2.5 Gbps TS Granularity)
表3：TPN割り当てルール（2.5 Gbps TS粒度）
+-------+-------+----+-------------------------------------------+
|HO ODUk|LO ODUj|TPN | TPN Assignment Rules |
+-------+-------+----+-------------------------------------------+
| ODU1 | ODU0 |1-2 |Fixed, = TS# occupied by ODU0 |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-4 |Flexible, != other existing LO ODU1s' TPNs |
| ODU2 +-------+----+-------------------------------------------+
| |ODU0 & |1-8 |Flexible, != other existing LO ODU0s and |
| |ODUflex| |ODUflexes' TPNs |
+-------+-------+----+-------------------------------------------+
| | ODU1 |1-16|Flexible, != other existing LO ODU1s' TPNs |
| +-------+----+-------------------------------------------+
| | ODU2 |1-4 |Flexible, != other existing LO ODU2s' TPNs |
| ODU3 +-------+----+-------------------------------------------+
| |ODU0 & | |Flexible, != other existing LO ODU0s and |
| |ODU2e &|1-32|ODU2s and ODUflexes' TPNs |
| |ODUflex| | |
+-------+-------+----+-------------------------------------------+
| ODU4 |Any ODU|1-80|Flexible, != ANY other existing LO ODUs' |
| | | |TPNs |
+-------+-------+----+-------------------------------------------+
Table 4: TPN Assignment Rules (1.25 Gbps TS Granularity)
表4：TPN割り当てルール（1.25 Gbps TS粒度）
Note that in the case of "Flexible", the value of TPN MAY not correspond to the TS number as per [G709-2012].
[フレキシブル]の場合、TPNの値は[G709-2012]に従ってTS番号に対応しない場合があることに注意してください。
Length: 12 bits
長さ：12ビット
Indicates the number of bits of the Bit Map field, i.e., the total number of TSs in the HO ODUk link. The TS granularity, 1.25 Gbps or 2.5 Gbps, may be derived by dividing the HO ODUk link's rate by the value of the Length field. In the context of [G709-2012], the values of 4 and 16 indicate a TS granularity of 2.5 Gbps, and the values 2, 8, 32, and 80 indicate a TS granularity of 1.25 Gbps.
ビットマップフィールドのビット数、つまりHO ODUkリンク内のTSの総数を示します。 TS粒度（1.25 Gbpsまたは2.5 Gbps）は、HO ODUkリンクのレートを長さフィールドの値で除算することによって導出できます。 [G709-2012]のコンテキストでは、4および16の値は2.5 GbpsのTS粒度を示し、2、8、32、および80の値は1.25 GbpsのTS粒度を示します。
In the case of an ODUk mapped into OTUk, there is no need to indicate which tributary slots will be used, so the Length field MUST be set to 0.
OTUkにマップされたODUkの場合、どのトリビュタリスロットを使用するかを示す必要がないため、Lengthフィールドは0に設定する必要があります。
Bit Map: variable
ビットマップ：変数
Indicates which tributary slots in the HO ODUk that the LO ODUj will be multiplexed into. The sequence of the Bit Map is consistent with the sequence of the tributary slots in the HO ODUk. Each bit in the bit map represents the corresponding tributary slot in the HO ODUk with a value of 1 or 0 indicating whether the tributary slot will be used by the LO ODUj or not.
LO ODUjが多重化されるHO ODUkのどの支流スロットを示す。ビットマップのシーケンスは、HO ODUkの支流スロットのシーケンスと一致しています。ビットマップの各ビットは、HO ODUkの対応する支流スロットを表し、1または0の値は、支流スロットがLO ODUjによって使用されるかどうかを示します。
Padding Bits
パディングビット
Are added after the Bit Map to make the whole label a multiple of four bytes if necessary. Padding bits MUST be set to 0 and MUST be ignored on receipt.
必要に応じて、ビットマップの後に追加して、ラベル全体を4バイトの倍数にします。パディングビットは0に設定する必要があり、受信時に無視する必要があります。
The ingress node MUST generate a Path message and specify the OTN-TDM Switching Type and corresponding G-PID in the GENERALIZED_LABEL_REQUEST object, which MUST be processed as defined in [RFC3473].
入力ノードはパスメッセージを生成し、OTN-TDMスイッチングタイプと対応するG-PIDをGENERALIZED_LABEL_REQUESTオブジェクトで指定する必要があります。これらは[RFC3473]で定義されているように処理する必要があります。
The ingress node of an LSP MAY include a Label ERO (Explicit Route Object) subobject to indicate the label in each hop along the path. Note that the TPN in the Label ERO subobject need not be assigned by the ingress node. When the TPN is assigned by a node, the node MUST assign a valid TPN value and then put this value into the TPN field of the GENERALIZED_LABEL object when receiving a Path message.
LSPの入口ノードには、パスに沿った各ホップのラベルを示すラベルERO（明示的ルートオブジェクト）サブオブジェクトが含まれる場合があります。ラベルEROサブオブジェクトのTPNは、入口ノードによって割り当てられる必要がないことに注意してください。 TPNがノードによって割り当てられている場合、ノードは有効なTPN値を割り当て、パスメッセージを受信したときにこの値をGENERALIZED_LABELオブジェクトのTPNフィールドに入力する必要があります。
In order to create bidirectional LSP, the ingress node and upstream node MUST generate an UPSTREAM_LABEL object on the outgoing interface to indicate the reserved TSs of ODUk and the assigned TPN value in the upstream direction. This UPSTREAM_LABEL object is sent to the downstream node via a Path massage for upstream resource reservation.
双方向LSPを作成するために、入力ノードと上流ノードは、ODUkの予約済みTSと割り当てられたTPN値を上流方向に示すために、発信インターフェースでUPSTREAM_LABELオブジェクトを生成する必要があります。このUPSTREAM_LABELオブジェクトは、アップストリームリソース予約のためのパスマッサージを介してダウンストリームノードに送信されます。
The ingress node or upstream node MAY generate a LABEL_SET object to indicate which labels on the outgoing interface in the downstream direction are acceptable. The downstream node will restrict its choice of labels, i.e., TS resource and TPN value, to one that is in the LABEL_SET object.
入口ノードまたは上流ノードはLABEL_SETオブジェクトを生成して、下流方向の発信インターフェースのどのラベルが許容できるかを示すことができます（MAY）。ダウンストリームノードは、ラベル、つまりTSリソースとTPN値の選択を、LABEL_SETオブジェクトにあるものに制限します。
The ingress node or upstream node MAY also generate a SUGGESTED_LABEL object to indicate the preference of TS resource and TPN value on the outgoing interface in the downstream direction. The downstream node is not required to use the suggested labels; it may use another label based on local decision and send it to the upstream node, as described in [RFC3473].
イングレスノードまたはアップストリームノードは、ダウンストリーム方向のアウトゴーイングインターフェイスのTSリソースとTPN値の優先順位を示すSUGGESTED_LABELオブジェクトを生成する場合もあります。推奨されるラベルを使用するためにダウンストリームノードは必要ありません。 [RFC3473]で説明されているように、ローカルの決定に基づいて別のラベルを使用し、上流のノードに送信する場合があります。
When an upstream node receives a Resv message containing a GENERALIZED_LABEL object with an OTN-TDM label, it MUST first identify which ODU Signal Type is multiplexed or mapped into which ODU Signal Type according to the Traffic Parameters and the IF_ID RSVP_HOP object in the received message.
上流ノードは、OTN-TDMラベル付きのGENERALIZED_LABELオブジェクトを含むResvメッセージを受信すると、最初に、受信したメッセージのトラフィックパラメータとIF_ID RSVP_HOPオブジェクトに従って、どのODU信号タイプが多重化されているか、どのODU信号タイプにマッピングされているかを識別しなければなりません。 。
- In the case of ODUj-to-ODUk multiplexing, the node MUST retrieve the reserved tributary slots in the ODUk by its downstream neighbor node according to the position of the bits that are set to 1 in the Bit Map field. The node determines the TS granularity (according to the total TS number of the ODUk or pre-configured TS granularity), so that the node can multiplex the ODUj into the ODUk based on the TS granularity. The node MUST also retrieve the TPN value assigned by its downstream neighbor node from the label and fill the TPN into the related MSI byte(s) in the OPUk overhead in the data plane, so that the downstream neighbor node can check whether the TPN received from the data plane is consistent with the Expected MSI (ExMSI) and determine whether there is any mismatch defect.
- ODUjからODUkへの多重化の場合、ノードは、ビットマップフィールドで1に設定されているビットの位置に従って、ダウンストリームの隣接ノードによってODUkの予約された支流スロットを取得する必要があります。ノードは、TS粒度を（ODUkの合計TS番号または事前構成されたTS粒度に従って）決定するため、ノードは、TS粒度に基づいてODUjをODUkに多重化できます。ノードはまた、下流の隣接ノードによって割り当てられたTPN値をラベルから取得し、TPNをデータプレーンのOPUkオーバーヘッド内の関連するMSIバイトに埋め込む必要があるため、下流の隣接ノードは受信したTPNを確認できますデータプレーンからのデータはExpected MSI（ExMSI）と一致しており、不一致の欠陥がないかどうかを判断します。
- In the case of ODUk-to-OTUk mapping, the size of the Bit Map field MUST be 0, and no additional procedure is needed.
- ODUkからOTUkへのマッピングの場合、ビットマップフィールドのサイズは0でなければならず、追加の手順は必要ありません。
When a downstream node or egress node receives a Path message containing a GENERALIZED_LABEL_REQUEST object for setting up an ODUj LSP from its upstream neighbor node, the node MUST generate an OTN-TDM label according to the Signal Type of the requested LSP and the available resources (i.e., available tributary slots of ODUk) that will be reserved for the LSP and send the label to its upstream neighbor node.
ダウンストリームノードまたは出口ノードが、上流の隣接ノードからODUj LSPを設定するためのGENERALIZED_LABEL_REQUESTオブジェクトを含むPathメッセージを受信すると、ノードは、要求されたLSPの信号タイプと使用可能なリソースに従ってOTN-TDMラベルを生成する必要があります（つまり、LSP用に予約され、上流の隣接ノードにラベルを送信する、ODUkの利用可能な支流スロット）。
- In the case of ODUj-to-ODUk multiplexing, the node MUST first determine the size of the Bit Map field according to the Signal Type and the tributary slot type of ODUk and then set the bits to 1 in the Bit Map field corresponding to the reserved tributary slots. The node MUST also assign a valid TPN, which MUST NOT collide with other TPN values used by existing LO ODU connections in the selected HO ODU link, and configure the Expected MSI (ExMSI) using this TPN. Then, the assigned TPN MUST be filled into the label.
- ODUj-to-ODUk多重化の場合、ノードは最初にODUkのシグナルタイプとトリビュタリスロットタイプに従ってビットマップフィールドのサイズを決定し、次に対応するビットマップフィールドのビットを1に設定する必要があります。予約された支流スロット。ノードはまた、選択されたHO ODUリンクの既存のLO ODU接続で使用される他のTPN値と衝突してはならない有効なTPNを割り当て、このTPNを使用してExpected MSI（ExMSI）を構成する必要があります。次に、割り当てられたTPNをラベルに記入する必要があります。
- In the case of ODUk-to-OTUk mapping, the TPN field MUST be set to 0. Bit Map information is not required and MUST NOT be included, so the Length field MUST be set to 0 as well.
- ODUkからOTUkへのマッピングの場合、TPNフィールドは0に設定する必要があります。ビットマップ情報は必須ではなく、含めることはできません。そのため、長さフィールドも0に設定する必要があります。
When an upstream node receives a Resv message containing a GENERALIZED_LABEL object with an OTN-TDM label, the node MUST verify if the label is acceptable. If the label is not acceptable, the node MUST generate a ResvErr message with a "Routing problem/Unacceptable label value" indication. Per [RFC3473], the generated ResvErr message MAY include an ACCEPTABLE_LABEL_SET object. With the exception of label semantics, a downstream node processing a received ResvErr message and ACCEPTABLE_LABEL_SET object is not modified by this document.
上流ノードがOTN-TDMラベルを持つGENERALIZED_LABELオブジェクトを含むResvメッセージを受信するとき、ノードはラベルが受け入れ可能かどうかを検証しなければなりません（MUST）。ラベルが受け入れられない場合、ノードは「ルーティングの問題/受け入れられないラベルの値」を示すResvErrメッセージを生成する必要があります。 [RFC3473]により、生成されたResvErrメッセージにはACCEPTABLE_LABEL_SETオブジェクトが含まれる場合があります。ラベルのセマンティクスを除いて、受信したResvErrメッセージとACCEPTABLE_LABEL_SETオブジェクトを処理するダウンストリームノードは、このドキュメントによって変更されません。
Similarly, when a downstream node receives a Path message containing an UPSTREAM_LABEL object with an OTN-TDM label, the node MUST verify if the label is acceptable. If the label is not acceptable, the node MUST generate a PathErr message with a "Routing problem/Unacceptable label value" indication. Per [RFC3473], the generated PathErr message MAY include an ACCEPTABLE_LABEL_SET object. With the exception of label semantics, the upstream nodes processing a received PathErr message and ACCEPTABLE_LABEL_SET object are not modified by this document.
同様に、ダウンストリームノードがOTN-TDMラベルを持つUPSTREAM_LABELオブジェクトを含むPathメッセージを受信した場合、ノードはラベルが受け入れ可能かどうかを確認する必要があります。ラベルが受け入れられない場合、ノードは、「ルーティングの問題/受け入れられないラベル値」を示すPathErrメッセージを生成する必要があります。 [RFC3473]により、生成されたPathErrメッセージにはACCEPTABLE_LABEL_SETオブジェクトが含まれる場合があります。ラベルのセマンティクスを除いて、受信したPathErrメッセージとACCEPTABLE_LABEL_SETオブジェクトを処理する上流ノードは、このドキュメントでは変更されません。
A received label SHALL be considered unacceptable when one of the following cases occurs:
受け取ったラベルは、次のいずれかの場合に受け入れ不可と見なされます。
- The received label doesn't conform to local policy;
- 受け取ったラベルはローカルポリシーに準拠していません。
- An invalid value appears in the Length field;
- 長さフィールドに無効な値が表示されます。
- The selected link only supports 2.5 Gbps TS granularity while the Length field in the label along with ODUk Signal Type indicates the 1.25 Gbps TS granularity;
- 選択したリンクは2.5 Gbps TSの粒度のみをサポートしますが、ラベル内の長さフィールドとODUk信号タイプは1.25 Gbps TSの粒度を示します。
- The label includes an invalid TPN value that breaks the TPN assignment rules; and
- ラベルには、TPN割り当てルールに違反する無効なTPN値が含まれています。そして
- The indicated resources (i.e., the number of "1"s in the Bit Map field) are inconsistent with the Traffic Parameters.
- 示されたリソース（つまり、ビットマップフィールドの「1」の数）は、トラフィックパラメータと矛盾しています。
Per [RFC6344], the Virtual Concatenation Groups (VCGs) can be created using the One LSP approach or the Multiple LSPs approach.
[RFC6344]に従って、仮想連結グループ（VCG）は1つのLSPアプローチまたは複数のLSPアプローチを使用して作成できます。
In the case of the One LSP approach, the explicit ordered list of all labels MUST reflect the order of VCG members, which is similar to [RFC4328]. In the case of multiplexed virtually concatenated signals (NVC > 1), the first label MUST indicate the components of the first virtually concatenated signal; the second label MUST indicate the components of the second virtually concatenated signal; and so on. In the case of multiplication of multiplexed virtually concatenated signals (MT > 1), the first label MUST indicate the components of the first multiplexed virtually concatenated signal; the second label MUST indicate components of the second multiplexed virtually concatenated signal; and so on.
One LSPアプローチの場合、すべてのラベルの明示的な順序付きリストは、[RFC4328]と同様に、VCGメンバーの順序を反映する必要があります。多重化された仮想連結信号（NVC> 1）の場合、最初のラベルは最初の仮想連結信号のコンポーネントを示さなければなりません（MUST）。 2番目のラベルは、2番目の仮想的に連結された信号のコンポーネントを示さなければなりません。等々。多重化された仮想連結信号の乗算の場合（MT> 1）、最初のラベルは、最初の多重化された仮想連結信号のコンポーネントを示さなければなりません（MUST）。 2番目のラベルは、2番目に多重化された仮想連結信号のコンポーネントを示さなければなりません（MUST）。等々。
Support for Virtual Concatenation of ODU1, ODU2, and ODU3 Signal Types, as defined by [RFC6344], is not modified by this document. Virtual Concatenation of other Signal Types is not supported by [G709-2012].
[RFC6344]で定義されているODU1、ODU2、およびODU3信号タイプの仮想連結のサポートは、このドキュメントでは変更されていません。他の信号タイプの仮想連結は、[G709-2012]ではサポートされていません。
Multiplier (MT) usage is as defined in [RFC6344] and [RFC4328].
乗数（MT）の使用法は、[RFC6344]および[RFC4328]で定義されています。
The following examples are given in order to illustrate the label format described in Section 6.1 of this document.
次の例は、このドキュメントのセクション6.1で説明されているラベル形式を説明するために提供されています。
(1) ODUk-to-OTUk Mapping:
（1）ODUkからOTUkへのマッピング：
In this scenario, the downstream node along an LSP returns a label indicating that the ODUk (k=1, 2, 3, 4) is directly mapped into the corresponding OTUk. The following example label indicates an ODU1 mapped into OTU1.
このシナリオでは、LSPに沿ったダウンストリームノードは、ODUk（k = 1、2、3、4）が対応するOTUkに直接マッピングされていることを示すラベルを返します。次のラベル例は、ODU1がOTU1にマッピングされていることを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 0 | Reserved | Length = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(2) ODUj-to-ODUk Multiplexing: In this scenario, this label indicates that an ODUj is multiplexed into several tributary slots of OPUk and then mapped into OTUk. Some instances are shown as follows:
（2）ODUjからODUkへの多重化：このシナリオでは、このラベルは、ODUjがOPUkのいくつかの支流スロットに多重化され、OTUkにマッピングされることを示します。一部のインスタンスは次のように表示されます。
- ODU0-to-ODU2 Multiplexing:
- ODU0-to-ODU2多重化：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 2 | Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 0 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The label above indicates an ODU0 multiplexed into the second tributary slot of ODU2, wherein there are 8 TSs in ODU2 (i.e., the type of the tributary slot is 1.25 Gbps), and the TPN value is 2.
上記のラベルは、ODU2の2番目のトリビュタリスロットに多重化されたODU0を示しています。ODU2には8つのTSがあり（つまり、トリビュタリスロットのタイプは1.25 Gbps）、TPN値は2です。
- ODU1-to-ODU2 Multiplexing with 1.25 Gbps TS Granularity:
- 粒度が1.25 GbpsのODU1-to-ODU2多重化：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 1 | Reserved | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0 1 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The label above indicates an ODU1 multiplexed into the 2nd and the 4th tributary slots of ODU2, wherein there are 8 TSs in ODU2 (i.e., the type of the tributary slot is 1.25 Gbps), and the TPN value is 1.
上記のラベルは、ODU2の2番目と4番目の支流スロットに多重化されたODU1を示しています。ODU2には8つのTSがあり（つまり、支流スロットのタイプは1.25 Gbps）、TPN値は1です。
- ODU2 into ODU3 Multiplexing with 2.5 Gbps TS Granularity:
- 2.5 Gbps TS粒度でのODU2からODU3への多重化：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 1 | Reserved | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| Padding Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The label above indicates an ODU2 multiplexed into the 2nd, 3rd, 5th, and 7th tributary slots of ODU3, wherein there are 16 TSs in ODU3 (i.e., the type of the tributary slot is 2.5 Gbps), and the TPN value is 1.
上記のラベルは、ODU3の2番目、3番目、5番目、および7番目の支流スロットに多重化されたODU2を示しています。ODU3には16のTSがあり（つまり、支流スロットのタイプは2.5 Gbps）、TPN値は1です。
[G7044] describes the procedure of ODUflex(GFP) hitless resizing using the Link Connection Resize (LCR) and Bandwidth Resize (BWR) protocols in the OTN data plane.
[G7044]は、OTNデータプレーンでLink Connection Resize（LCR）およびBandwidth Resize（BWR）プロトコルを使用したODUflex（GFP）ヒットレスサイズ変更の手順を説明しています。
For the control plane, signaling messages are REQUIRED to initiate the adjustment procedure. Sections 2.5 and 4.6.4 of [RFC3209] describe how the Shared Explicit (SE) style is used in the Traffic Engineering (TE) network for bandwidth increasing and decreasing, which is still applicable for triggering the ODUflex(GFP) adjustment procedure in the data plane.
コントロールプレーンの場合、調整手順を開始するにはシグナリングメッセージが必要です。 [RFC3209]のセクション2.5および4.6.4は、帯域幅の増加と減少のためにトラフィックエンジニアリング（TE）ネットワークで共有明示（SE）スタイルがどのように使用されるかを説明しています。データプレーン。
Note that the SE style MUST be used at the beginning when creating a resizable ODUflex connection (Signal Type = 21). Otherwise an error with Error Code "Conflicting reservation style" MUST be generated when performing bandwidth adjustment.
サイズ変更可能なODUflex接続（信号タイプ= 21）を作成するときは、最初にSEスタイルを使用する必要があることに注意してください。それ以外の場合は、帯域幅調整を実行するときに、エラーコード「競合する予約スタイル」のエラーを生成する必要があります。
- Bandwidth Increasing
- 帯域幅の増加
For the ingress node, in order to increase the bandwidth of an ODUflex(GFP) connection, a Path message with SE style (keeping Tunnel ID unchanged and assigning a new LSP ID) MUST be sent along the path.
入力ノードでは、ODUflex（GFP）接続の帯域幅を増やすために、SEスタイルのパスメッセージ（トンネルIDを変更せず、新しいLSP IDを割り当てる）をパスに沿って送信する必要があります。
The ingress node will trigger the BWR protocol when successful completion of LCR protocols on every hop after the Resv message is processed. On success of BWR, the ingress node SHOULD send a PathTear message to delete the old control state (i.e., the control state of the ODUflex(GFP) before resizing) on the control plane.
入力ノードは、Resvメッセージが処理された後、すべてのホップでLCRプロトコルが正常に完了すると、BWRプロトコルをトリガーします。 BWRが成功すると、入力ノードはPathTearメッセージを送信して、コントロールプレーン上の古い制御状態（つまり、サイズ変更前のODUflex（GFP）の制御状態）を削除する必要があります（SHOULD）。
A downstream node receiving a Path message with SE style compares the old Traffic Parameters (stored locally) with the new one carried in the Path message to determine the number of TSs to be added. After choosing and reserving new available TS(s), the downstream node MUST send back a Resv message carrying both the old and new GENERALIZED_LABEL objects in the SE flow descriptor.
SEスタイルのパスメッセージを受信するダウンストリームノードは、（ローカルに格納された）古いトラフィックパラメータを、パスメッセージに含まれる新しいトラフィックパラメータと比較して、追加するTSの数を決定します。新しい利用可能なTSを選択して予約した後、ダウンストリームノードは、SEフロー記述子内の新旧両方のGENERALIZED_LABELオブジェクトを運ぶResvメッセージを返信する必要があります。
An upstream neighbor receiving a Resv message with an SE flow descriptor MUST determine which TS(s) is/are added and trigger the LCR protocol between itself and its downstream neighbor node.
SEフロー記述子を含むResvメッセージを受信するアップストリームネイバーは、どのTSが追加されるかを決定し、それ自体とそのダウンストリームネイバーノード間のLCRプロトコルをトリガーする必要があります。
- Bandwidth Decreasing
- 帯域幅の減少
For the ingress node, a Path message with SE style SHOULD also be sent for decreasing the ODUflex bandwidth.
入力ノードの場合、ODUflex帯域幅を減らすために、SEスタイルのパスメッセージも送信する必要があります（SHOULD）。
The ingress node will trigger the BWR protocol when successful completion of LCR handshake on every hop after Resv message is processed. On success of BWR, the second step of LCR, i.e., link connection decrease procedure will be started on every hop of the connection. After decreasing the bandwidth, the ingress node SHOULD send a ResvErr message to tear down the old control state.
入力ノードは、Resvメッセージが処理された後、すべてのホップでLCRハンドシェイクが正常に完了すると、BWRプロトコルをトリガーします。 BWRが成功すると、LCRの2番目のステップ、つまりリンク接続の減少手順が接続のすべてのホップで開始されます。帯域幅を減らした後、入力ノードは古い制御状態を破棄するためにResvErrメッセージを送信する必要があります（SHOULD）。
A downstream node receiving a Path message with SE style compares the old Traffic Parameters with the new one carried in the Path message to determine the number of TSs to be decreased. After choosing TSs to be decreased, the downstream node MUST send back a Resv message carrying both the old and new GENERALIZED_LABEL objects in the SE flow descriptor.
SEスタイルのPathメッセージを受信するダウンストリームノードは、古いトラフィックパラメータをPathメッセージで伝送された新しいトラフィックパラメータと比較して、削減するTSの数を決定します。削減するTSを選択した後、ダウンストリームノードは、SEフロー記述子の新旧両方のGENERALIZED_LABELオブジェクトを運ぶResvメッセージを返送する必要があります。
An upstream neighbor receiving a Resv message with an SE flow descriptor MUST determine which TS(s) is/are decreased and trigger the first step of the LCR protocol (i.e., LCR handshake) between itself and its downstream neighbor node.
SEフロー記述子を含むResvメッセージを受信する上流のネイバーは、どのTSが減少するかを決定し、自身とそのダウンストリームネイバーノード間のLCRプロトコルの最初のステップ（つまり、LCRハンドシェイク）をトリガーする必要があります。
OTN OAM configuration could be done through either Network Management Systems (NMSs) or the GMPLS control plane as defined in [TDM-OAM]. [RFC4783] SHOULD be used for communication of alarm information in GMPLS-based OTN.
OTN OAM構成は、[TDM-OAM]で定義されているように、ネットワーク管理システム（NMS）またはGMPLSコントロールプレーンのいずれかを介して行うことができます。 [RFC4783] GMPLSベースのOTNでのアラーム情報の通信に使用する必要があります（SHOULD）。
Management Information Bases (MIBs) may need be extended to read new information (e.g., OTN-TDM Generalized Label and OTN-TDM SENDER_TSPEC / FLOWSPEC) from the OTN devices. This is outside the scope of this document.
OTNデバイスから新しい情報（OTN-TDM Generalized LabelやOTN-TDM SENDER_TSPEC / FLOWSPECなど）を読み取るには、管理情報ベース（MIB）を拡張する必要がある場合があります。これはこのドキュメントの範囲外です。
More information about the management aspects for GMPLS-based OTN, refer to Section 5.7 of [RFC7062].
GMPLSベースのOTNの管理に関する詳細については、[RFC7062]のセクション5.7を参照してください。
As described in [RFC7062], since [RFC4328] has been deployed in the network for the nodes that support the 2001 revision of the G.709 specification, control-plane backward compatibility SHOULD be taken into consideration. More specifically:
[RFC7062]で説明されているように、[RFC4328]はG.709仕様の2001リビジョンをサポートするノードのネットワークに展開されているため、コントロールプレーンの下位互換性を考慮する必要があります（SHOULD）。すなわち：
o Nodes supporting this document SHOULD support [RFC7138].
o このドキュメントをサポートするノードはサポート[SHOULD] [RFC7138]。
o Nodes supporting this document MAY support [RFC4328] signaling.
o このドキュメントをサポートするノードは[RFC4328]シグナリングをサポートするかもしれません。
o A node supporting both sets of procedures (i.e., [RFC4328] and this document) is not required to signal an LSP using both procedures, i.e., to act as a signaling version translator.
o 両方の手順のセット（つまり、[RFC4328]とこのドキュメント）をサポートするノードは、両方の手順を使用してLSPをシグナリングする必要はありません。つまり、シグナリングバージョントランスレータとして機能します。
o Ingress nodes that support both sets of procedures MAY select which set of procedures to follow based on routing information or local policy.
o 手順の両方のセットをサポートする入力ノードは、ルーティング情報またはローカルポリシーに基づいて、従う手順のセットを選択できます（MAY）。
o Per [RFC3473], nodes that do not support this document will generate a PathErr message, with a "Routing problem/Switching Type" indication.
o [RFC3473]に従い、このドキュメントをサポートしていないノードは、「ルーティングの問題/切り替えの種類」を示すPathErrメッセージを生成します。
This document is a modification to [RFC3473] and [RFC4328]; it only differs in specific information communicated. As such, this document introduces no new security considerations to the existing GMPLS signaling protocols. Refer to [RFC3473] and [RFC4328] for further details of the specific security measures. Additionally, [RFC5920] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane.
このドキュメントは[RFC3473]と[RFC4328]の修正版です。伝達される特定の情報のみが異なります。そのため、このドキュメントでは、既存のGMPLSシグナリングプロトコルに新しいセキュリティ上の考慮事項を紹介していません。特定のセキュリティ対策の詳細については、[RFC3473]および[RFC4328]を参照してください。さらに、[RFC5920]は、GMPLSコントロールプレーンのセキュリティの脆弱性と保護メカニズムの概要を提供します。
IANA has made the following assignments in the "Class Types or C-Types - 9 FLOWSPEC" and "Class Types or C-Types - 12 SENDER_TSPEC" section of the "Resource Reservation Protocol (RSVP) Parameters" registry located at <http://www.iana.org/assignments/ rsvp-parameters>.
IANAは、<http：/にある「リソース予約プロトコル（RSVP）パラメータ」レジストリの「クラスタイプまたはCタイプ-9 FLOWSPEC」および「クラスタイプまたはCタイプ-12 SENDER_TSPEC」セクションで次の割り当てを行いました。 /www.iana.org/assignments/ rsvp-parameters>。
Value Description Reference 7 OTN-TDM [RFC7139]
値説明参照7 OTN-TDM [RFC7139]
IANA maintains the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry (see <http://www.iana.org/assignments/gmpls-sig-parameters>). The "Generalized PIDs (G-PID)" subregistry is included in this registry, which is extended and updated by this document as detailed below.
IANAは「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Parameters」レジストリ（<http://www.iana.org/assignments/gmpls-sig-parameters>を参照）を維持しています。 「一般化されたPID（G-PID）」サブレジストリはこのレジストリに含まれています。このレジストリは、以下で詳細に説明するように、このドキュメントによって拡張および更新されます。
Value Type Technology Reference
===== ====================== ========== =========
47 G.709 ODU-2.5G G.709 ODUk [RFC4328]
(IANA updated the Type field) [RFC7139]
56 SBCON/ESCON G.709 ODUk, [RFC4328]
(IANA updated the Type field) Lambda, Fiber [RFC7139]
59 Framed GFP G.709 ODUk [RFC7139]
60 STM-1 G.709 ODUk [RFC7139]
61 STM-4 G.709 ODUk [RFC7139]
62 InfiniBand G.709 ODUflex [RFC7139]
63 SDI (Serial Digital Interface) G.709 ODUk [RFC7139]
64 SDI/1.001 G.709 ODUk [RFC7139]
65 DVB_ASI G.709 ODUk [RFC7139]
66 G.709 ODU-1.25G G.709 ODUk [RFC7139]
67 G.709 ODU-any G.709 ODUk [RFC7139]
68 Null Test G.709 ODUk [RFC7139]
69 Random Test G.709 ODUk [RFC7139]
70 64B/66B GFP-F Ethernet G.709 ODUk [RFC7139]
The new G-PIDs are shown in the TC MIB managed by IANA at <https://www.iana.org/assignments/ianagmplstc-mib> as follows:
新しいG-PIDは、<https://www.iana.org/assignments/ianagmplstc-mib>のIANAによって管理されるTC MIBに次のように表示されます。
g709FramedGFP(59), g709STM1(60), g709STM4(61), g709InfiniBand(62), g709SDI(63), g709SDI1point001(64), g709DVBASI(65), g709ODU1point25G(66), g709ODUAny(67), g709NullTest(68), g709RandomTest(69), g709GFPFEthernet(70)
g709FramedGFP（59）、g709STM1（60）、g709STM4（61）、g709InfiniBand（62）、g709SDI（63）、g709SDI1point001（64）、g709DVBASI（65）、g709ODU1point25G（66）、g709ODUAny（67）、g709NullTest（68）、 g709RandomTest（69）、g709GFPFEthernet（70）
Note that IANA has not changed the names of the objects in this MIB module with the values 47 and 56.
IANAは、このMIBモジュールのオブジェクトの名前を値47および56で変更していないことに注意してください。
IANA has defined an "OTN Signal Type" subregistry to the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry:
IANAは、「一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリングパラメータ」レジストリに「OTNシグナルタイプ」サブレジストリを定義しています。
Value Signal Type Reference
----- ----------- ---------
0 Not significant [RFC4328]
1 ODU1 (i.e., 2.5 Gbps) [RFC4328]
2 ODU2 (i.e., 10 Gbps) [RFC4328]
3 ODU3 (i.e., 40 Gbps) [RFC4328]
4 ODU4 (i.e., 100 Gbps) [RFC7139]
5 Unassigned [RFC4328]
6 Och at 2.5 Gbps [RFC4328]
7 OCh at 10 Gbps [RFC4328]
8 OCh at 40 Gbps [RFC4328]
9 OCh at 100 Gbps [RFC7139]
10 ODU0 (i.e., 1.25 Gbps) [RFC7139]
11 ODU2e (i.e., 10 Gbps for FC1200 [RFC7139]
and GE LAN)
12-19 Unassigned [RFC7139]
20 ODUflex(CBR) (i.e., 1.25*N Gbps) [RFC7139]
21 ODUflex(GFP-F), resizable [RFC7139]
(i.e., 1.25*N Gbps)
22 ODUflex(GFP-F), non-resizable [RFC7139]
(i.e., 1.25*N Gbps)
23-255 Unassigned [RFC7139]
New values are to be assigned via Standards Action as defined in [RFC5226].
[RFC5226]で定義されているように、新しい値は標準アクションを介して割り当てられます。
[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., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、and S. Jamin、 "Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification"、RFC 2205、September 1997年
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[RFC2210] Wroclawski、J。、「The Use of RSVP with IETF Integrated Services」、RFC 2210、1997年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、12月2001年。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、Ed。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、2003年1月。
[RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006.
[RFC4328] Papadimitriou、D。、編、「G.709光トランスポートネットワーク制御用の一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング拡張機能」、RFC 4328、2006年1月。
[RFC4506] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[RFC4506] Eisler、M。、編、「XDR：外部データ表現標準」、STD 67、RFC 4506、2006年5月。
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006.
[RFC4783] Berger、L.、Ed。、「GMPLS-Communication of Alarm Information」、RFC 4783、2006年12月。
[RFC6344] Bernstein, G., Ed., Caviglia, D., Rabbat, R., and H. van Helvoort, "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", RFC 6344, August 2011.
[RFC6344] Bernstein、G.、Ed。、Caviglia、D.、Rabbat、R.、and H. van Helvoort、 "Operating Virtual Concatenation（VCAT）and Link Capacity Adjustment Scheme（LCAS）with Generalized Multi-Protocol Label Switching （GMPLS）」、RFC 6344、2011年8月。
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and J. Drake, "Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks", RFC 7138, March 2014.
[RFC7138] Ceccarelli、D.、Ed。、Zhang、F.、Belotti、S.、Rao、R。、およびJ. Drake、「OSPFへのトラフィックエンジニアリング拡張機能による、進化するG.709光トランスポートネットワークのGMPLS制御」 RFC 7138、2014年3月。
[G709-2012] ITU-T, "Interfaces for the Optical Transport Network (OTN)", G.709/Y.1331 Recommendation, February 2012.
[G709-2012] ITU-T、「Interfaces for the Optical Transport Network（OTN）」、G.709 / Y.1331 Recommendation、February 2012。
[G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347, October 2011.
[G7044] ITU-T、「ヒットレスODUflexの調整」、G.7044 / Y.1347、2011年10月。
[G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April 2011.
[G7041] ITU-T、「Generic framing procedure」、G.7041 / Y.1303、2011年4月。
[IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, Institute of Electrical and Electronics Engineers, August 1985.
[IEEE]「2進浮動小数点演算のIEEE標準」、ANSI / IEEE標準754-1985、電気電子学会、1985年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC7062] Zhang, F., Ed., Li, D., Li, H., Belotti, S., and D. Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", RFC 7062, November 2013.
[RFC7062] Zhang、F.、Ed。、Li、D.、Li、H.、Belotti、S.、and D. Ceccarelli、 "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks"、RFC 7062、 2013年11月。
[RFC7096] Belotti, S., Ed., Grandi, P., Ceccarelli, D., Ed., Caviglia, D., Zhang, F., and D. Li, "Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)", RFC 7096, January 2014.
[RFC7096] Belotti、S.、Ed。、Grandi、P.、Ceccarelli、D.、Ed。、Caviglia、D.、Zhang、F.、D. Li、 "Evaluation of Existing GMPLS Encoding for G.709v3 Optical Transport Networks（OTNs）」、RFC 7096、2014年1月。
[TDM-OAM] Kern, A., and A. Takacs, "GMPLS RSVP-TE Extensions for SONET/SDH and OTN OAM Configuration", Work in Progress, November 2013.
[TDM-OAM] Kern、A。、およびA. Takacs、「GMPLS RSVP-TE Extensions for SONET / SDH and OTN OAM Configuration」、Work in Progress、2013年11月。
Yi Lin Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28972914 EMail: yi.lin@huawei.com
Y i Lin hu AはテクノロジーF3-5-br＆Dセンターであり、hu Aは基本禁止日であり、ロングギャングの地区は非常に現実的です。
Yunbin Xu China Academy of Telecommunication Research of MII 11 Yue Tan Nan Jie Beijing P.R. China Phone: +86-10-68094134 EMail: xuyunbin@mail.ritt.com.cn
Y UNビンX u中国電気通信研究アカデミーo FM II 11 Y u ETアンナNJ IE北京P.R.中国電話：+ 86-10-68094134電子メール：许采丙@买了。日天天.com。
Pietro Grandi Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate Milano Italy Phone: +39 039 6864930 EMail: pietro_vittorio.grandi@alcatel-lucent.it Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy EMail: diego.caviglia@ericsson.com
Pietro Grandi Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate Milan Italy電話：+39 039 6864930メール：pietro_vittorio.grandi@alcatel-lucent.it Diego Caviglia Ericsson Via A. Negrone 1 / A Genoa-Sestri Ponente Italyメール：diego。 caviglia@ericsson.com
Rajan Rao Infinera Corporation 169, Java Drive Sunnyvale, CA 94089 USA EMail: rrao@infinera.com
Rajan Rao Infinera Corporation 169、Java Drive Sunnyvale、CA 94089米国Eメール：rrao@infinera.com
John E Drake Juniper EMail: jdrake@juniper.net
ジョンEドレイクジュニパーメール：jdrake@juniper.net
Igor Bryskin Adva Optical EMail: IBryskin@advaoptical.com
Igor Bryskin Adva Optical EMail：IBryskin@adegaoptical.com
Jonathan Sadler, Tellabs EMail: jonathan.sadler@tellabs.com
Jonathan Sadler、Tellabs EMail：jonathan.sadler@tellabs.com
Kam LAM, Alcatel-Lucent EMail: kam.lam@alcatel-lucent.com
サテライトアクセントメールの件数：Km.mm@satelknone.com
Francesco Fondelli, Ericsson EMail: francesco.fondelli@ericsson.com
Francesco Fondelli、Ericsson EMail：francesco.fondelli@ericsson.com
Lyndon Ong, Ciena EMail: lyong@ciena.com
Lyndon Ong、Ciena EMail：lyong@ciena.com
Biao Lu, infinera EMail: blu@infinera.com
BI AOL U、inf in era email：Expose @in fineer A.com
The authors would like to thank Lou Berger, Deborah Brungard, and Xiaobing Zi for their useful comments regarding this document.
このドキュメントに関する有益なコメントを提供してくれたLou Berger、Deborah Brungard、およびXiaobing Ziに感謝します。
Authors' Addresses
著者のアドレス
Fatai Zhang (editor) Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28972912 EMail: zhangfatai@huawei.com
Fatai Zhang（編集者）Huawei Technologies F3-5-B R＆D Center、Huawei Base Bantian、Longgang District Shenzhen 518129 P.R. China電話：+ 86-755-28972912メール：zhangfatai@huawei.com
Guoying Zhang China Academy of Telecommunication Research of MII 11 Yue Tan Nan Jie Beijing P.R. China Phone: +86-10-68094272 EMail: zhangguoying@mail.ritt.com.cn
Guoying Zhang China Academy of Telecommunication Research of MII 11 Yue Tan Nan Jie Beijing P.R. China電話：+ 86-10-68094272メール：zhangguoying@mail.ritt.com.cn
Sergio Belotti Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate Milano Italy Phone: +39 039 6863033 EMail: sergio.belotti@alcatel-lucent.it
Sergio Belotti Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate Milan Italy電話：+39039 6863033メール：sergio.belotti@alcatel-lucent.it
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy EMail: daniele.ceccarelli@ericsson.com
Daniele Ceccarelli Ericsson Via A. Negrone 1 / A Genoa-セストリポネンテイタリアEメール：daniele.ceccarelli@ericsson.com
Khuzema Pithewan Infinera Corporation 169, Java Drive Sunnyvale, CA 94089 USA EMail: kpithewan@infinera.com
Khuzema Pithewan Infinera Corporation 169、Java Drive Sunnyvale、CA 94089米国Eメール：kpithewan@infinera.com