[要約] RFC 7062は、G.709光トランスポートネットワークのGMPLSとPCE制御のためのフレームワークを提供しています。このRFCの目的は、G.709ネットワークの制御と管理を効果的に行うためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 7062 D. Li
Category: Informational Huawei
ISSN: 2070-1721 H. Li
CMCC
S. Belotti
Alcatel-Lucent
D. Ceccarelli
Ericsson
November 2013
Framework for GMPLS and PCE Control of G.709 Optical Transport Networks
G.709光トランスポートネットワークのGMPLSおよびPCE制御のフレームワーク
Abstract
概要
This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012.
このドキュメントは、公開されているITU-T勧告G.709で指定されている、光トランスポートネットワーク（OTN）の汎用マルチプロトコルラベルスイッチング（GMPLS）およびパス計算要素（PCE）制御をサポートするプロトコル拡張の開発を可能にするフレームワークを提供します2012年に。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7062.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7062で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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. G.709 Optical Transport Network .................................4
3.1. OTN Layer Network ..........................................5
3.1.1. Client Signal Mapping ...............................6
3.1.2. Multiplexing ODUj onto Links ........................7
3.1.2.1. Structure of MSI Information ...............9
4. Connection Management in OTN ...................................10
4.1. Connection Management of the ODU ..........................11
5. GMPLS/PCE Implications .........................................13
5.1. Implications for Label Switched Path (LSP) Hierarchy ......13
5.2. Implications for GMPLS Signaling ..........................14
5.3. Implications for GMPLS Routing ............................16
5.4. Implications for Link Management Protocol .................18
5.5. Implications for Control-Plane Backward Compatibility .....19
5.6. Implications for Path Computation Elements ................20
5.7. Implications for Management of GMPLS Networks .............20
6. Data-Plane Backward Compatibility Considerations ...............21
7. Security Considerations ........................................21
8. Acknowledgments ................................................22
9. Contributors ...................................................22
10. References ....................................................23
10.1. Normative References .....................................23
10.2. Informative References ...................................24
Optical Transport Networks (OTNs) have become a mainstream layer 1 technology for the transport network. Operators want to introduce control-plane capabilities based on GMPLS to OTN to realize the benefits associated with a high-function control plane (e.g., improved network resiliency, resource usage efficiency, etc.).
光トランスポートネットワーク（OTN）は、トランスポートネットワークの主流のレイヤー1テクノロジーになっています。オペレーターは、GMPLSに基づくコントロールプレーン機能をOTNに導入して、高機能のコントロールプレーンに関連する利点（ネットワークの復元力、リソース使用効率などの向上）を実現したいと考えています。
GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass Time Division Multiplexing (TDM) networks (e.g., Synchronous Optical NETwork (SONET) / Synchronous Digital Hierarchy (SDH), Plesiochronous Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching optical networks, and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The GMPLS architecture is provided in [RFC3945], signaling function and Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC3473], routing and Open Shortest Path First (OSPF) extensions are described in [RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is described in [RFC4204].
GMPLSは、マルチプロトコルラベルスイッチング（MPLS）を拡張して、時分割多重（TDM）ネットワーク（同期光ネットワーク（SONET）/同期デジタル階層（SDH）、プレシオクロナスデジタル階層（PDH）、G.709サブラムダなど）を包含します。 ）、ラムダスイッチング光ネットワーク、および空間スイッチング（たとえば、入力ポートまたはファイバーから出力ポートまたはファイバーへ）。 GMPLSアーキテクチャは[RFC3945]で提供され、シグナリング機能とリソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）拡張は[RFC3471]と[RFC3473]で説明されています。ルーティングとOpen Shortest Path First（OSPF）拡張は[ RFC4202]と[RFC4203]、およびリンク管理プロトコル（LMP）については[RFC4204]で説明されています。
The GMPLS signaling extensions defined in [RFC4328] provide the mechanisms for basic GMPLS control of OTN based on the 2001 revision of the G.709 specification. The 2012 revision of the G.709 specification, [G709-2012], includes new features, for example, various multiplexing structures, two types of Tributary Slots (TSs) (i.e., 1.25 Gbps and 2.5G bps), and extension of the Optical channel Data Unit-j (ODUj) definition to include the ODUflex function.
[RFC4328]で定義されているGMPLSシグナリング拡張は、G.709仕様の2001年改訂に基づいたOTNの基本的なGMPLS制御のメカニズムを提供します。 G.709仕様の2012年改訂版[G709-2012]には、さまざまな多重化構造、2種類のトリビュタリスロット（TS）（つまり、1.25 Gbpsと2.5G bps）、およびODUflex関数を含めるための光チャネルデータユニットj（ODUj）定義。
This document reviews relevant aspects of OTN technology evolution that affect the GMPLS control-plane protocols and examines why and how to update the mechanisms described in [RFC4328]. This document additionally provides a framework for GMPLS control of OTN and includes a discussion of the implications for the use of the PCE [RFC4655].
このドキュメントは、GMPLSコントロールプレーンプロトコルに影響を与えるOTNテクノロジーの進化の関連する側面をレビューし、[RFC4328]で説明されているメカニズムを更新する理由と方法を検証します。このドキュメントはさらに、OTNのGMPLS制御のフレームワークを提供し、PCE [RFC4655]の使用に関する影響の議論を含みます。
For the purposes of the control plane, the OTN can be considered to be comprised of ODU and wavelength (Optical Channel (OCh)) layers. This document focuses on the control of the ODU layer, with control of the wavelength layer considered out of the scope. Please refer to [RFC6163] for further information about the wavelength layer.
コントロールプレーンの目的では、OTNはODU層と波長（光チャネル（OCh））層で構成されると考えることができます。このドキュメントでは、ODU層の制御に焦点を当て、波長層の制御は範囲外と見なされます。波長層の詳細については、[RFC6163]を参照してください。
OTN: Optical Transport Network
OTN：光伝送ネットワーク
OPU: Optical Channel Payload Unit
OPU：光チャネルペイロードユニット
ODU: Optical Channel Data Unit OTU: Optical Channel Transport Unit
ODU：光チャネルデータユニットOTU：光チャネルトランスポートユニット
OMS: Optical Multiplex Section
OMS：光多重化セクション
MSI: Multiplex Structure Identifier
MSI：マルチプレックス構造識別子
TPN: Tributary Port Number
TPN：トリビュタリポート番号
LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, or flex) represents the container transporting a client of the OTN that is either directly mapped into an OTUk (k = j) or multiplexed into a server HO ODUk (k > j) container.
LO ODU：低次ODU。 LO ODUj（jは0、1、2、2e、3、4、またはflexのいずれか）は、OTNk（k = j）に直接マッピングされるか、サーバーHOに多重化されるOTNのクライアントを転送するコンテナーを表しますODUk（k> j）コンテナー。
HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, or 4) represents the entity transporting a multiplex of LO ODUj tributary signals in its OPUk area.
HO ODU：高次ODU。 HO ODUk（kは1、2、2e、3、または4のいずれか）は、そのOPUkエリアでLO ODUj支流信号の多重信号を転送するエンティティを表します。
ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a bit rate tolerance of +/-100 ppm (parts per million).
ODUflex：柔軟なODU。柔軟なODUkは、任意のビットレートと+/- 100 ppm（100万分の1）のビットレート許容値を持つことができます。
In general, throughout this document, "ODUj" is used to refer to ODU entities acting as an LO ODU, and "ODUk" is used to refer to ODU entities being used as an HO ODU.
一般に、このドキュメント全体で、「ODUj」はLO ODUとして機能するODUエンティティを指すために使用され、「ODUk」はHO ODUとして使用されるODUエンティティを指すために使用されます。
This section provides an informative overview of the aspects of the OTN impacting control-plane protocols. This overview is based on the ITU-T Recommendations that contain the normative definition of the OTN. Technical details regarding OTN architecture and interfaces are provided in the relevant ITU-T Recommendations.
このセクションでは、OTNに影響を与えるコントロールプレーンプロトコルの側面について、有益な概要を説明します。この概要は、OTNの規範的な定義を含むITU-T勧告に基づいています。 OTNアーキテクチャとインターフェイスに関する技術的な詳細は、関連するITU-T勧告に記載されています。
Specifically, [G872-2012] describes the functional architecture of optical transport networks providing optical signal transmission, multiplexing, routing, supervision, performance assessment, and network survivability. The legacy OTN referenced by [RFC4328] defines the interfaces of the optical transport network to be used within and between subnetworks of the optical network. With the evolution and deployment of OTN technology, many new features have been specified in ITU-T recommendations, including, for example, new ODU0, ODU2e, ODU4, and ODUflex containers as described in [G709-2012].
具体的には、[G872-2012]は、光信号伝送、多重化、ルーティング、監視、パフォーマンス評価、およびネットワークの存続可能性を提供する光トランスポートネットワークの機能アーキテクチャについて説明しています。 [RFC4328]によって参照されるレガシーOTNは、光ネットワークのサブネットワーク内およびサブネットワーク間で使用される光トランスポートネットワークのインターフェースを定義します。 [G709-2012]で説明されているODU0、ODU2e、ODU4、ODUflexコンテナーなど、OTNテクノロジーの進化と導入に伴い、ITU-T勧告で多くの新機能が指定されています。
The simplified signal hierarchy of OTN is shown in Figure 1, which illustrates the layers that are of interest to the control plane. Other layers below OCh (e.g., Optical Transmission Section (OTS)) are not included in this figure. The full signal hierarchy is provided in [G709-2012].
図1に、OTNの簡略化された信号階層を示します。図1は、コントロールプレーンにとって重要なレイヤーを示しています。 OChの下のその他の層（たとえば、光伝送セクション（OTS））は、この図には含まれていません。完全な信号階層は[G709-2012]で提供されています。
Client signal | ODUj | OTU/OCh OMS
クライアント信号| ODUj | OTU / OCh OMS
Figure 1: Basic OTN Signal Hierarchy
図1：基本的なOTN信号階層
Client signals are mapped into ODUj containers. These ODUj containers are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are combined in the OMS using Wavelength Division Multiplexing (WDM), and this aggregated signal provides the link between the nodes.
クライアント信号はODUjコンテナーにマップされます。これらのODUjコンテナはOTU / OChに多重化されます。個々のOTU / OCh信号は、波長分割多重（WDM）を使用してOMSで結合され、この集約された信号がノード間のリンクを提供します。
The client signals are mapped into an LO ODUj. The current values of j defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, and flex. The approximate bit rates of these signals are defined in [G709-2012] and are reproduced in Tables 1 and 2.
クライアント信号はLO ODUjにマッピングされます。 [G709-2012]で定義されているjの現在の値は、0、1、2、2e、3、4、およびflexです。これらの信号のおおよそのビットレートは[G709-2012]で定義されており、表1および2に再現されています。
+-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate |
+-----------------------+-----------------------------------+
| ODU0 | 1,244,160 Kbps |
| ODU1 | 239/238 x 2,488,320 Kbps |
| ODU2 | 239/237 x 9,953,280 Kbps |
| ODU3 | 239/236 x 39,813,120 Kbps |
| ODU4 | 239/227 x 99,532,800 Kbps |
| ODU2e | 239/237 x 10,312,500 Kbps |
| | |
| ODUflex for | |
|Constant Bit Rate (CBR)| 239/238 x client signal bit rate |
| Client signals | |
| | |
| ODUflex for Generic | |
| Framing Procedure | Configured bit rate |
| - Framed (GFP-F) | |
| Mapped client signal | |
+-----------------------+-----------------------------------+
Table 1: ODU Types and Bit Rates
表1：ODUタイプとビットレート
NOTE: The nominal ODUk rates are approximately: 2,498,775.126 Kbps (ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3), 104,794,445.815 Kbps (ODU4), and 10,399,525.316 Kbps (ODU2e).
注：公称ODUkレートは約2,498,775.126 Kbps（ODU1）、10,037,273.924 Kbps（ODU2）、40,319,218.983 Kbps（ODU3）、104,794,445.815 Kbps（ODU4）、および10,399,525.316 Kbps（ODU2e）です。
+-----------------------+-----------------------------------+
| ODU Type | ODU bit rate tolerance |
+-----------------------+-----------------------------------+
| ODU0 | +/-20 ppm |
| ODU1 | +/-20 ppm |
| ODU2 | +/-20 ppm |
| ODU3 | +/-20 ppm |
| ODU4 | +/-20 ppm |
| ODU2e | +/-100 ppm |
| | |
| ODUflex for CBR | |
| Client signals | +/-100 ppm |
| | |
| ODUflex for GFP-F | |
| Mapped client signal | +/-100 ppm |
+-----------------------+-----------------------------------+
Table 2: ODU Types and Tolerance
表2：ODUのタイプと許容値
One of two options is for mapping client signals into ODUflex depending on the client signal type:
2つのオプションの1つは、クライアント信号のタイプに応じて、クライアント信号をODUflexにマッピングするためのものです。
- Circuit clients are proportionally wrapped. Thus, the bit rate is defined by the client signal, and the tolerance is fixed to +/-100 ppm.
- 回線クライアントは比例的にラップされます。したがって、ビットレートはクライアント信号によって定義され、許容誤差は+/- 100 ppmに固定されます。
- Packet clients are mapped using the Generic Framing Procedure (GFP). [G709-2012] recommends that the ODUflex(GFP) will fill an integral number of tributary slots of the smallest HO ODUk path over which the ODUflex(GFP) may be carried, and the tolerance should be +/-100 ppm.
- パケットクライアントは、Generic Framing Procedure（GFP）を使用してマッピングされます。 [G709-2012]は、ODUflex（GFP）がODUflex（GFP）が伝送される最小のHO ODUkパスの支流スロットの整数個を埋めることを推奨し、許容誤差は+/- 100 ppmにする必要があります。
Note that additional information on G.709 client mapping can be found in [G7041].
G.709クライアントマッピングの詳細については、[G7041]を参照してください。
The links between the switching nodes are provided by one or more wavelengths. Each wavelength carries one OCh, which carries one OTU, which carries one ODU. Since all of these signals have a 1:1:1 relationship, we only refer to the OTU for clarity. The ODUjs are mapped into the TSs (Tributary Slots) of the OPUk. Note that in the case where j=k, the ODUj is mapped into the OTU/OCh without multiplexing.
スイッチングノード間のリンクは、1つ以上の波長によって提供されます。各波長は、1つのODUを伝送する1つのOTUを伝送する1つのOChを伝送します。これらの信号はすべて1：1：1の関係にあるため、わかりやすくするためにOTUのみを参照しています。 ODUjsは、OPUkのTS（トリビュタリースロット）にマッピングされます。 j = kの場合、ODUjは多重化されずにOTU / OChにマッピングされることに注意してください。
The initial versions of G.709 referenced by [RFC4328] only provided a single TS granularity, nominally 2.5 Gbps. [G709-2012] added an additional TS granularity, nominally 1.25 Gbps. The number and type of TS provided by each of the currently identified OTUk are provided below:
[RFC4328]が参照するG.709の初期バージョンは、名目上2.5 Gbpsの単一のTS粒度のみを提供していました。 [G709-2012]は、追加のTS細分性、名目上1.25 Gbpsを追加しました。現在識別されている各OTUkによって提供されるTSの数とタイプを以下に示します。
Tributary Slot Granularity 2.5 Gbps 1.25 Gbps Nominal Bit Rate OTU1 1 2 2.5 Gbps OTU2 4 8 10 Gbps OTU3 16 32 40 Gbps OTU4 -- 80 100 Gbps
トリビュタリスロットの粒度2.5 Gbps 1.25 Gbps公称ビットレートOTU1 1 2 2.5 Gbps OTU2 4 8 10 Gbps OTU3 16 32 40 Gbps OTU4-80100 Gbps
To maintain backward compatibility while providing the ability to interconnect nodes that support a 1.25 Gbps TS at one end of a link and a 2.5 Gbps TS at the other, [G709-2012] requires 'new' equipment to fall back to the use of a 2.5 Gbps TS when connected to legacy equipment. This information is carried in band by the payload type.
リンクの一方の端で1.25 Gbps TSをサポートし、もう一方の端で2.5 Gbps TSをサポートするノードを相互接続する機能を提供しながら、下位互換性を維持するには、[G709-2012]が「新しい」機器を使用してレガシー機器に接続した場合の2.5 Gbps TS。この情報は、ペイロードタイプによって帯域内で運ばれます。
The actual bit rate of the TS in an OTUk depends on the value of k. Thus, the number of TSs occupied by an ODUj may vary depending on the values of j and k. For example, an ODU2e uses 9 TSs in an OTU3 but only 8 in an OTU4. Examples of the number of TSs used for various cases are provided below (referring to Tables 7-9 of [G709-2012]):
OTUk内のTSの実際のビットレートは、kの値によって異なります。したがって、ODUjによって占有されるTSの数は、jおよびkの値に応じて変わる可能性があります。たとえば、ODU2eはOTU3で9つのTSを使用しますが、OTU4では8つだけを使用します。さまざまなケースで使用されるTSの数の例を以下に示します（[G709-2012]の表7-9を参照）。
- ODU0 into ODU1, ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS granularity o ODU0 occupies 1 of the 2, 8, 32, or 80 TSs for ODU1, ODU2, ODU3, or ODU4
- ODU0からODU1、ODU2、ODU3、またはODU4への多重化（1.25 GbpsのTS細分度を使用）o ODU0は、ODU1、ODU2、ODU3、またはODU4の2、8、32、または80 TSのうちの1つを占有します
- ODU1 into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS granularity o ODU1 occupies 2 of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4
- ODU1からODU2、ODU3、またはODU4への多重化、1.25 GbpsのTS粒度での多重化o ODU1は、ODU2、ODU3、またはODU4の8、32、または80 TSのうち2つを占有
- ODU1 into ODU2 or ODU3 multiplexing with 2.5 Gbps TS granularity o ODU1 occupies 1 of the 4 or 16 TSs for ODU2 or ODU3
- ODU1からODU2またはODU3への多重化、2.5 GbpsのTS粒度での多重化o ODU1は、ODU2またはODU3の4または16 TSのうちの1つを占有します。
- ODU2 into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity o ODU2 occupies 8 of the 32 or 80 TSs for ODU3 or ODU4
- ODU2からODU3またはODU4への多重化（1.25 GbpsのTS細分度を使用）o ODU2は、ODU3またはODU4の32または80 TSのうち8つを占有します。
- ODU2 into ODU3 multiplexing with 2.5 Gbps TS granularity o ODU2 occupies 4 of the 16 TSs for ODU3
- ODU2からODU3への多重化（2.5 Gbps TS粒度）o ODU2はODU3の16 TSのうち4つを占有
- ODU3 into ODU4 multiplexing with 1.25 Gbps TS granularity o ODU3 occupies 31 of the 80 TSs for ODU4
- ODU3からODU4への多重化（1.25 Gbps TS粒度）o ODU3は、ODU4の80 TSのうち31を占有
- ODUflex into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS granularity o ODUflex occupies n of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4 (n <= Total TS number of ODUk)
- TS粒度が1.25 GbpsのODU2、ODU3、またはODU4多重化へのODUflex o ODUflexは、ODU2、ODU3、またはODU4の8、32、または80 TSのうちnを占有します（n <= ODUkの合計TS数）
- ODU2e into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity o ODU2e occupies 9 of the 32 TSs for ODU3 or 8 of the 80 TSs for ODU4
- ODU2eからODU3またはODU4への多重化（1.25 GbpsのTS粒度での多重化）o ODU2eは、32個のTSのうち9個がODU3の場合、または8個が80 TSのうちの8個のODU4を占有
In general, the mapping of an ODUj (including ODUflex) into a specific OTUk TS is determined locally, and it can also be explicitly controlled by a specific entity (e.g., head end or Network Management System (NMS)) through Explicit Label Control [RFC3473].
一般に、特定のOTUk TSへのODUj（ODUflexを含む）のマッピングはローカルで決定され、明示的なラベル制御を介して特定のエンティティ（ヘッドエンドまたはネットワーク管理システム（NMS）など）によって明示的に制御することもできます[ RFC3473]。
When multiplexing an ODUj into an HO ODUk (k>j), G.709 specifies the information that has to be transported in-band in order to allow for correct demultiplexing. This information, known as MSI, is transported in the OPUk overhead and is local to each link. In case of bidirectional paths, the association between the TPN and TS must be the same in both directions.
ODUjをHO ODUk（k> j）に多重化する場合、G.709は、正しい逆多重化を可能にするために帯域内で転送する必要がある情報を指定します。 MSIと呼ばれるこの情報は、OPUkオーバーヘッドで転送され、各リンクに対してローカルです。双方向パスの場合、TPNとTS間の関連付けは両方向で同じでなければなりません。
The MSI information is organized as a set of entries, with one entry for each HO ODUj TS. The information carried by each entry is:
MSI情報は、HO ODUj TSごとに1つのエントリを持つ、一連のエントリとして編成されます。各エントリに含まれる情報は次のとおりです。
- Payload Type: the type of the transported payload.
- ペイロードタイプ：転送されたペイロードのタイプ。
- TPN: the port number of the ODUj transported by the HO ODUk. The TPN is the same for all the TSs assigned to the transport of the same ODUj instance.
- TPN：HO ODUkによって転送されたODUjのポート番号。 TPNは、同じODUjインスタンスのトランスポートに割り当てられたすべてのTSで同じです。
For example, an ODU2 carried by an HO ODU3 is described by 4 entries in the OPU3 overhead when the TS granularity is 2.5 Gbps, and by 8 entries when the TS granularity is 1.25 Gbps.
たとえば、HO ODU3によって伝送されるODU2は、TS粒度が2.5 Gbpsの場合はOPU3オーバーヘッドの4エントリで記述され、TS粒度が1.25 Gbpsの場合は8エントリで記述されます。
On each node and on every link, two MSI values have to be provisioned (referring to [G798]):
各ノードとすべてのリンクで、2つのMSI値をプロビジョニングする必要があります（[G798]を参照）。
- The Transmitted MSI (TxMSI) information inserted in OPU (e.g., OPU3) overhead by the source of the HO ODUk trail.
- HO ODUkトレイルのソースによってOPU（OPU3など）オーバーヘッドに挿入された送信MSI（TxMSI）情報。
- The Expected MSI (ExMSI) information that is used to check the Accepted MSI (AcMSI) information. The AcMSI information is the MSI valued received in-band, after a three-frame integration.
- Accepted MSI（AcMSI）情報の確認に使用されるExpected MSI（ExMSI）情報。 AcMSI情報は、3フレーム統合後、インバンドで受信したMSI値です。
As described in [G798], the sink of the HO ODU trail checks the complete content of the AcMSI information against the ExMSI. If the AcMSI is different from the ExMSI, then the traffic is dropped, and a payload mismatch alarm is generated.
[G798]で説明されているように、HO ODUトレイルのシンクは、ExMSIに対してAcMSI情報の完全なコンテンツをチェックします。 AcMSIがExMSIと異なる場合、トラフィックはドロップされ、ペイロードミスマッチアラームが生成されます。
Provisioning of TPN can be performed by either a network management system or control plane. In the last case, the control plane is also responsible for negotiating the provisioned values on a link-by-link basis.
TPNのプロビジョニングは、ネットワーク管理システムまたはコントロールプレーンのいずれかで実行できます。最後のケースでは、コントロールプレーンは、リンクごとにプロビジョニングされた値のネゴシエーションも行います。
OTN-based connection management is concerned with controlling the connectivity of ODU paths and OCh. This document focuses on the connection management of ODU paths. The management of OCh paths is described in [RFC6163].
OTNベースの接続管理は、ODUパスとOChの接続の制御に関係しています。このドキュメントでは、ODUパスの接続管理に焦点を当てています。 OChパスの管理については、[RFC6163]で説明されています。
While [G872-2001] considered the ODU to be a set of layers in the same way as SDH has been modeled, recent ITU-T OTN architecture progress [G872-2012] includes an agreement to model the ODU as a single-layer network with the bit rate as a parameter of links and connections. This allows the links and nodes to be viewed in a single topology as a common set of resources that are available to provide ODUj connections independent of the value of j. Note that when the bit rate of ODUj is less than the server bit rate, ODUj connections are supported by HO ODU (which has a one-to-one relationship with the OTU).
[G872-2001]は、SDHがモデル化されているのと同じ方法でODUをレイヤーのセットであると見なしていましたが、最近のITU-T OTNアーキテクチャの進歩[G872-2012]には、ODUをシングルレイヤーネットワークとしてモデル化するという合意が含まれていますリンクと接続のパラメータとしてビットレートを使用します。これにより、リンクとノードを単一のトポロジで、jの値に関係なくODUj接続を提供するために使用できる共通のリソースセットとして表示できます。 ODUjのビットレートがサーバーのビットレートより低い場合、ODUj接続はHO ODU（OTUと1対1の関係）でサポートされます。
From an ITU-T perspective, the ODU connection topology is represented by that of the OTU link layer, which has the same topology as that of the OCh layer (independent of whether the OTU supports an HO ODU, where multiplexing is utilized, or an LO ODU in the case of direct mapping).
ITU-Tの観点から、ODU接続トポロジはOTUリンクレイヤーのトポロジによって表されます。これはOChレイヤーと同じトポロジを持ちます（OTUが多重化が利用されるHO ODUをサポートするかどうかに関係なく、または直接マッピングの場合はLO ODU）。
Thus, the OTU and OCh layers should be visible in a single topological representation of the network, and from a logical perspective, the OTU and OCh may be considered as the same logical, switchable entity.
したがって、OTUレイヤーとOChレイヤーはネットワークの単一のトポロジー表現で表示される必要があり、論理的な観点から、OTUとOChは同じ論理的で切り替え可能なエンティティと見なすことができます。
Note that the OTU link-layer topology may be provided via various infrastructure alternatives, including point-to-point optical connections, optical connections fully in the optical domain, and optical connections involving hybrid sub-lambda/lambda nodes involving 3R, etc. See [RFC6163] for additional information.
OTUリンク層トポロジは、ポイントツーポイントの光接続、完全に光ドメイン内の光接続、3Rを含むハイブリッドサブラムダ/ラムダノードを含む光接続など、さまざまなインフラストラクチャの代替手段を介して提供できることに注意してください。 [RFC6163]追加情報。
An LO ODUj can be either mapped into the OTUk signal (j = k) or multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is mapped into an OCh.
LO ODUjは、OTUk信号（j = k）にマッピングするか、他のLO ODUjsと多重化してOTUk（j <k）にすることができ、OTUkはOChにマッピングされます。
From the perspective of the control plane, there are two kinds of network topology to be considered.
コントロールプレーンの観点からは、2種類のネットワークトポロジを考慮する必要があります。
(1) ODU layer
（1）ODUレイヤー
In this case, the ODU links are presented between adjacent OTN nodes, as illustrated in Figure 2. In this layer, there are ODU links with a variety of TSs available, and nodes that are Optical Digital Cross Connects (ODXCs). LO ODU connections can be set up based on the network topology.
この場合、ODUリンクは、図2に示すように、隣接するOTNノード間に提示されます。このレイヤーには、さまざまなTSを使用できるODUリンクと、光デジタルクロスコネクト（ODXC）であるノードがあります。 LO ODU接続は、ネットワークトポロジに基づいて設定できます。
Link #5 +--+---+--+ Link #4
+--------------------------| |--------------------------+
| | ODXC | |
| +---------+ |
| Node E |
| |
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
| |Link #1 | |Link #2 | |Link #3 | |
| |--------| |--------| |--------| |
| ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node D
Figure 2: Example Topology for LO ODU Connection Management
図2：LO ODU接続管理のトポロジ例
If an ODUj connection is requested between Node C and Node E, routing/path computation must select a path that has the required number of TSs available and that offers the lowest cost. Signaling is then invoked to set up the path and to provide the information (e.g., selected TSs) required by each transit node to allow the configuration of the ODUj-to-OTUk mapping (j = k) or multiplexing (j < k) and demapping (j = k) or demultiplexing (j < k).
ノードCとノードEの間でODUj接続が要求された場合、ルーティング/パス計算は、必要な数のTSが利用可能で、コストが最も低いパスを選択する必要があります。次に、シグナリングが呼び出されて、パスをセットアップし、ODUjからOTUkへのマッピング（j = k）または多重化（j <k）の構成を可能にするために各トランジットノードで必要な情報（たとえば、選択されたTS）を提供します。デマッピング（j = k）または逆多重化（j <k）。
(2) ODU layer with OCh switching capability
（2）OChスイッチング機能を備えたODUレイヤー
In this case, the OTN nodes interconnect with wavelength switched nodes (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM) or Optical Cross-Connect (OXC)) that are capable of OCh switching; this is illustrated in Figures 3 and 4. There are the ODU layer and the OCh layer, so it is simply a Multi-Layer Network (MLN) (see
この場合、OTNノードは、OChスイッチングが可能な波長スイッチドノード（例：Reconfiguration Optical Add / Drop Multiplexer（ROADM）またはOptical Cross-Connect（OXC））と相互接続します。これを図3と図4に示します。ODUレイヤーとOChレイヤーがあるため、これは単にマルチレイヤーネットワーク（MLN）です（
[RFC6001]). OCh connections may be created on demand, which is described in Section 5.1.
[RFC6001]）。 OCh接続は、必要に応じて作成できます。これについては、セクション5.1で説明します。
In this case, an operator may choose to allow the underlying OCh layer to be visible to the ODU routing/path computation process, in which case the topology would be as shown in Figure 4. In Figure 3, however, a cloud representing OCh-capable switching nodes is represented. In Figure 3, the operator choice is to hide the real OCh-layer network topology.
この場合、オペレーターは、基になるOChレイヤーをODUルーティング/パス計算プロセスに表示できるようにすることを選択できます。この場合、トポロジは図4のようになります。ただし、図3では、OCh-を表すクラウド可能なスイッチングノードが示されています。図3では、オペレーターの選択は、実際のOChレイヤーネットワークトポロジを非表示にすることです。
Node E
Link #5 +--------+ Link #4
+------------------------| |------------------------+
| ------ |
| // \\ |
| || || |
| | OCh domain | |
+-+-----+ +------ || || ------+ +-----+-+
| | | \\ // | | |
| |Link #1 | -------- |Link #3 | |
| +--------+ | | +--------+ +
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+Link #2 +---------+ +-------+
Node A Node B Node C Node D
Figure 3: OCh Hidden Topology for LO ODU Connection Management
図3：LO ODU接続管理のOCh非表示トポロジ
Link #5 +---------+ Link #4
+------------------------| |-----------------------+
| +----| ODXC |----+ |
| +-++ +---------+ ++-+ |
| Node f | | Node E | | Node g |
| +-++ ++-+ |
| | +--+ | |
+-+-----+ +----+----+--| |--+-----+---+ +-----+-+
| |Link #1 | | +--+ | |Link #3 | |
| +--------+ | Node h | +--------+ |
| ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+ Link #2+---------+ +-------+
Node A Node B Node C Node D
Figure 4: OCh Visible Topology for LO ODUj Connection Management
図4：LO ODUj接続管理のOCh可視トポロジ
In Figure 4, the cloud in the previous figure is substituted by the real topology. The nodes f, g, and h are nodes with OCh switching capability.
図4では、前の図のクラウドが実際のトポロジーに置き換えられています。ノードf、g、hはOChスイッチング機能を持つノードです。
In the examples (i.e., Figures 3 and 4), we have considered the case in which LO ODUj connections are supported by an OCh connection and the case in which the supporting underlying connection can also be made by a combination of HO ODU/OCh connections.
例（つまり、図3および4）では、LO ODUj接続がOCh接続によってサポートされる場合と、基になる接続をHO ODU / OCh接続の組み合わせによって行うこともできる場合について検討しました。 。
In this case, the ODU routing/path selection process will request an HO ODU/OCh connection between node C and node E from the OCh domain. The connection will appear at the ODU level as a Forwarding Adjacency, which will be used to create the ODU connection.
この場合、ODUルーティング/パス選択プロセスは、ノードCとノードE間のHO ODU / OCh接続をOChドメインから要求します。接続はODUレベルで転送隣接として表示され、ODU接続の作成に使用されます。
The purpose of this section is to provide a set of requirements to be evaluated for extensions of the current GMPLS protocol suite and the PCE applications and protocols to encompass OTN enhancements and connection management.
このセクションの目的は、現在のGMPLSプロトコルスイートの拡張と、OTN拡張と接続管理を含むPCEアプリケーションとプロトコルについて評価する必要がある一連の要件を提供することです。
The path computation for an ODU connection request is based on the topology of the ODU layer.
ODU接続要求のパス計算は、ODUレイヤーのトポロジーに基づいています。
The OTN path computation can be divided into two layers. One layer is OCh/OTUk; the other is ODUj. [RFC4206] and [RFC6107] define the mechanisms to accomplish creating the hierarchy of LSPs. The LSP management of multiple layers in OTN can follow the procedures defined in [RFC4206], [RFC6001], and [RFC6107].
OTNパスの計算は2つの層に分けることができます。 1つの層はOCh / OTUkです。もう1つはODUjです。 [RFC4206]と[RFC6107]は、LSPの階層を作成するためのメカニズムを定義しています。 OTNでの複数層のLSP管理は、[RFC4206]、[RFC6001]、および[RFC6107]で定義された手順に従うことができます。
As discussed in Section 4, the route path computation for OCh is in the scope of the Wavelength Switched Optical Network (WSON) [RFC6163]. Therefore, this document only considers the ODU layer for an ODU connection request.
セクション4で説明したように、OChのルートパス計算は、波長スイッチ光ネットワーク（WSON）[RFC6163]の範囲内です。したがって、このドキュメントでは、ODU接続要求のODUレイヤーのみを考慮しています。
The LSP hierarchy can also be applied within the ODU layers. One of the typical scenarios for ODU layer hierarchy is to maintain compatibility with introducing new [G709-2012] services (e.g., ODU0 and ODUflex) into a legacy network configuration (i.e., the legacy OTN referenced by [RFC4328]). In this scenario, it may be necessary to consider introducing hierarchical multiplexing capability in specific network transition scenarios. One method for enabling multiplexing hierarchy is by introducing dedicated boards in a few specific places in the network and tunneling these new services through the legacy containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade every network element to [G709-2012] capabilities.
LSP階層は、ODUレイヤー内にも適用できます。 ODUレイヤー階層の一般的なシナリオの1つは、新しい[G709-2012]サービス（ODU0やODUflexなど）をレガシーネットワーク構成（つまり、[RFC4328]によって参照されるレガシーOTN）に導入することとの互換性を維持することです。このシナリオでは、特定のネットワーク移行シナリオで階層型多重化機能の導入を検討する必要がある場合があります。多重化階層を有効にする1つの方法は、ネットワークのいくつかの特定の場所に専用ボードを導入し、レガシーコンテナー（ODU1、ODU2、ODU3）を介してこれらの新しいサービスをトンネリングすることにより、すべてのネットワーク要素を[G709-2012 ]機能。
In such cases, one ODUj connection can be nested into another ODUk (j<k) connection, which forms the LSP hierarchy in the ODU layer. The creation of the outer ODUk connection can be triggered via network planning or by the signaling of the inner ODUj connection. For the former case, the outer ODUk connection can be created in advance based on network planning. For the latter case, the multi-layer network signaling described in [RFC4206], [RFC6107], and [RFC6001] (including related modifications, if needed) is relevant to create the ODU connections with multiplexing hierarchy. In both cases, the outer ODUk connection is advertised as a Forwarding Adjacency (FA).
このような場合、ODUj接続の1つを別のODUk（j <k）接続にネストして、ODUレイヤーのLSP階層を形成できます。外部ODUk接続の作成は、ネットワーク計画を介して、または内部ODUj接続のシグナリングによってトリガーできます。前者の場合、外部ODUk接続は、ネットワーク計画に基づいて事前に作成できます。後者の場合、[RFC4206]、[RFC6107]、および[RFC6001]（必要に応じて関連する変更を含む）で説明されているマルチレイヤネットワークシグナリングは、多重化階層を持つODU接続の作成に関連しています。どちらの場合も、外部ODUk接続は転送隣接（FA）としてアドバタイズされます。
The signaling function and RSVP-TE extensions are described in [RFC3471] and [RFC3473]. For OTN-specific control, [RFC4328] defines signaling extensions to support control for the legacy G.709 Optical Transport Networks.
シグナリング機能とRSVP-TE拡張は、[RFC3471]と[RFC3473]で説明されています。 OTN固有の制御の場合、[RFC4328]は、レガシーG.709光トランスポートネットワークの制御をサポートするためのシグナリング拡張を定義します。
As described in Section 3, [G709-2012] introduced some new features that include the ODU0, ODU2e, ODU4, and ODUflex containers. The mechanisms defined in [RFC4328] do not support such new OTN features, and protocol extensions will be necessary to allow them to be controlled by a GMPLS control plane.
セクション3で説明したように、[G709-2012]は、ODU0、ODU2e、ODU4、およびODUflexコンテナーを含むいくつかの新機能を導入しました。 [RFC4328]で定義されているメカニズムは、このような新しいOTN機能をサポートしていません。GMPLSコントロールプレーンで制御できるようにするには、プロトコル拡張が必要です。
[RFC4328] defines the LSP Encoding Type, the Switching Type, and the Generalized Protocol Identifier (Generalized-PID) constituting the common part of the Generalized Label Request. The G.709 traffic parameters are also defined in [RFC4328]. In addition, the following signaling aspects not included in [RFC4328] should be considered:
[RFC4328]は、LSPエンコーディングタイプ、スイッチングタイプ、およびGeneralized Label Requestの共通部分を構成するGeneralized Protocol Identifier（Generalized-PID）を定義しています。 G.709トラフィックパラメータも[RFC4328]で定義されています。さらに、[RFC4328]に含まれていない以下のシグナリングの側面を考慮する必要があります。
- Support for specifying new signal types and related traffic information
- 新しい信号タイプと関連する交通情報を指定するためのサポート
The traffic parameters should be extended in a signaling message to support the new ODUj, including:
トラフィックパラメータは、次のような新しいODUjをサポートするために、シグナリングメッセージで拡張する必要があります。
- ODU0 - ODU2e - ODU4 - ODUflex
- ODU0-ODU2e-ODU4-ODUflex
For the ODUflex signal type, the bit rate must be carried additionally in the traffic parameter to set up an ODUflex connection.
ODUflex信号タイプの場合、ODUflex接続を設定するには、ビットレートをトラフィックパラメータで追加で伝送する必要があります。
For other ODU signal types, the bit rates and tolerances are fixed and can be deduced from the signal types.
他のODU信号タイプの場合、ビットレートと許容誤差は固定されており、信号タイプから推定できます。
- Support for LSP setup using different TS granularity
- 異なるTS粒度を使用したLSPセットアップのサポート
The signaling protocol should be able to identify the TS granularity (i.e., the 2.5 Gbps TS granularity and the new 1.25 Gbps TS granularity) to be used for establishing a Hierarchical LSP that will be used to carry service LSP(s) requiring a specific TS granularity.
シグナリングプロトコルは、特定のTSを必要とするサービスLSPを運ぶために使用される階層型LSPを確立するために使用されるTS粒度（つまり、2.5 Gbps TS粒度と新しい1.25 Gbps TS粒度）を識別できる必要があります。粒度。
- Support for LSP setup of new ODUk/ODUflex containers with related mapping and multiplexing capabilities
- 関連するマッピングおよび多重化機能を備えた新しいODUk / ODUflexコンテナーのLSPセットアップのサポート
A new label format must be defined to carry the exact TS's allocation information related to the extended mapping and multiplexing hierarchy (for example, ODU0 into ODU2 multiplexing (with 1.25 Gbps TS granularity)), in order to set up the ODU connection.
ODU接続をセットアップするには、拡張マッピングと多重化階層に関連する正確なTSの割り当て情報（たとえば、ODU0からODU2への多重化（1.25 Gbps TS粒度））に正確なTSの割り当て情報を伝えるために、新しいラベル形式を定義する必要があります。
- Support for TPN allocation and negotiation
- TPNの割り当てと交渉のサポート
TPN needs to be configured as part of the MSI information (see more information in Section 3.1.2.1). A signaling mechanism must be identified to carry TPN information if the control plane is used to configure MSI information.
TPNはMSI情報の一部として構成する必要があります（詳細については、セクション3.1.2.1を参照してください）。コントロールプレーンを使用してMSI情報を構成する場合は、TPN情報を伝達するシグナリングメカニズムを識別する必要があります。
- Support for ODU Virtual Concatenation (VCAT) and Link Capacity Adjustment Scheme (LCAS)
- ODU Virtual Concatenation（VCAT）およびLink Capacity Adjustment Scheme（LCAS）のサポート
GMPLS signaling should support the creation of Virtual Concatenation of an ODUk signal with k=1, 2, 3. The signaling should also support the control of dynamic capacity changing of a VCAT container using LCAS ([G7042]). [RFC6344] has a clear description of VCAT and LCAS control in SONET/SDH and OTN.
GMPLSシグナリングは、k = 1、2、3のODUk信号の仮想連結の作成をサポートする必要があります。シグナリングは、LCASを使用したVCATコンテナの動的容量変更の制御もサポートする必要があります（[G7042]）。 [RFC6344]には、SONET / SDHおよびOTNにおけるVCATおよびLCAS制御の明確な説明があります。
- Support for Control of Hitless Adjustment of ODUflex (GFP)
- ODUflex（GFP）のヒットレス調整の制御のサポート
[G7044] has been created in ITU-T to specify hitless adjustment of ODUflex (GFP) (HAO) that is used to increase or decrease the bandwidth of an ODUflex (GFP) that is transported in an OTN.
[G7044]はITU-Tで作成され、OTNで転送されるODUflex（GFP）の帯域幅を増減するために使用されるODUflex（GFP）（HAO）のヒットレス調整を指定します。
The procedure of ODUflex (GFP) adjustment requires the participation of every node along the path. Therefore, it is recommended to use control-plane signaling to initiate the adjustment procedure in order to avoid manual configuration at each node along the path.
ODUflex（GFP）調整の手順には、パスに沿ったすべてのノードの参加が必要です。そのため、パスに沿った各ノードでの手動構成を回避するために、コントロールプレーンシグナリングを使用して調整手順を開始することをお勧めします。
From the perspective of the control plane, control of ODUflex resizing is similar to control of bandwidth increasing and decreasing as described in [RFC3209]. Therefore, the Shared Explicit (SE) style can be used for control of HAO.
コントロールプレーンの観点から見ると、ODFflexのサイズ変更の制御は、[RFC3209]で説明されている帯域幅の増減の制御と似ています。したがって、HAOの制御にはShared Explicit（SE）スタイルを使用できます。
All the extensions above should consider the extensibility to match future evolvement of OTN.
上記のすべての拡張機能は、OTNの将来の進化に合わせて拡張性を考慮する必要があります。
The path computation process needs to select a suitable route for an ODUj connection request. In order to perform the path computation, it needs to evaluate the available bandwidth on each candidate link. The routing protocol should be extended to convey sufficient information to represent ODU Traffic Engineering (TE) topology.
パス計算プロセスでは、ODUj接続要求に適したルートを選択する必要があります。パス計算を実行するには、各候補リンクで使用可能な帯域幅を評価する必要があります。ルーティングプロトコルを拡張して、ODUトラフィックエンジニアリング（TE）トポロジを表すのに十分な情報を伝える必要があります。
The Interface Switching Capability Descriptors defined in [RFC4202] present a new constraint for LSP path computation. [RFC4203] defines the Switching Capability, related Maximum LSP Bandwidth, and Switching Capability specific information. When the Switching Capability field is TDM, the Switching Capability specific information field includes Minimum LSP Bandwidth, an indication whether the interface supports Standard or Arbitrary SONET/SDH, and padding. Hence, a new Switching Capability value needs to be defined for [G709-2012] ODU switching in order to allow the definition of a new Switching Capability specific information field. The following requirements should be considered:
[RFC4202]で定義されたインターフェイススイッチング機能記述子は、LSPパス計算に新しい制約を提供します。 [RFC4203]は、スイッチング機能、関連する最大LSP帯域幅、およびスイッチング機能固有の情報を定義します。スイッチング機能フィールドがTDMの場合、スイッチング機能固有の情報フィールドには、最小LSP帯域幅、インターフェイスが標準または任意のSONET / SDHをサポートするかどうかの表示、およびパディングが含まれます。したがって、新しいスイッチング機能固有の情報フィールドを定義できるようにするには、[G709-2012] ODUスイッチングに新しいスイッチング機能値を定義する必要があります。次の要件を考慮する必要があります。
- Support for carrying the link multiplexing capability
- リンク多重化機能のサポート
As discussed in Section 3.1.2, many different types of ODUj can be multiplexed into the same OTUk. For example, both ODU0 and ODU1 may be multiplexed into ODU2. An OTU link may support one or more types of ODUj signals. The routing protocol should be capable of carrying this multiplexing capability.
セクション3.1.2で説明したように、多くの異なるタイプのODUjを同じOTUkに多重化できます。たとえば、ODU0とODU1の両方を多重化してODU2にすることができます。 OTUリンクは、1つ以上のタイプのODUj信号をサポートできます。ルーティングプロトコルは、この多重化機能を実行できる必要があります。
- Support any ODU and ODUflex
- ODUおよびODUflexをサポート
The bit rate (i.e., bandwidth) of each TS is dependent on the TS granularity and the signal type of the link. For example, the bandwidth of a 1.25 Gbps TS in an OTU2 is about 1.249409620 Gbps, while the bandwidth of a 1.25 Gbps TS in an OTU3 is about 1.254703729 Gbps.
各TSのビットレート（帯域幅）は、TSの粒度とリンクの信号タイプに依存します。たとえば、OTU2の1.25 Gbps TSの帯域幅は約1.249409620 Gbpsですが、OTU3の1.25 Gbps TSの帯域幅は約1.254703729 Gbpsです。
One LO ODU may need a different number of TSs when multiplexed into different HO ODUs. For example, for ODU2e, 9 TSs are needed when multiplexed into an ODU3, while only 8 TSs are needed when multiplexed into an ODU4. For ODUflex, the total number of TSs to be reserved in an HO ODU equals the maximum of [bandwidth of ODUflex / bandwidth of TS of the HO ODU].
1つのLO ODUは、異なるHO ODUに多重化されるときに、異なる数のTSを必要とする場合があります。たとえば、ODU2eの場合、ODU3に多重化する場合は9つのTSが必要ですが、ODU4に多重化する場合は8つのTSだけが必要です。 ODUflexの場合、HO ODUで予約されるTSの総数は、[ODUflexの帯域幅/ HO ODUのTSの帯域幅]の最大値に等しくなります。
Therefore, the routing protocol should be capable of carrying the necessary link bandwidth information for performing accurate route computation for any of the fixed rate ODUs as well as ODUflex.
したがって、ルーティングプロトコルは、固定レートODUおよびODUflexのいずれかに対して正確なルート計算を実行するために必要なリンク帯域幅情報を伝送できる必要があります。
- Support for differentiating between terminating and switching capability
- 終端機能とスイッチング機能の区別のサポート
Due to internal constraints and/or limitations, the type of signal being advertised by an interface could be restricted to switched (i.e., forwarded to switching matrix without multiplexing/demultiplexing actions), restricted to terminated (demuxed), or both. The capability advertised by an interface needs further distinction in order to separate termination and switching capabilities.
内部の制約や制限により、インターフェイスによってアドバタイズされる信号のタイプは、スイッチド（つまり、多重化/逆多重化アクションなしでスイッチングマトリックスに転送される）に制限されるか、終端（デマルチプレクサー）に制限されるか、またはその両方になります。インターフェースによって通知される機能は、終端機能とスイッチング機能を分離するために、さらに区別する必要があります。
Therefore, to allow the required flexibility, the routing protocol should clearly distinguish the terminating and switching capability.
したがって、必要な柔軟性を可能にするために、ルーティングプロトコルは終端機能とスイッチング機能を明確に区別する必要があります。
- Support for Tributary Slot Granularity advertisement
- 支流スロット粒度広告のサポート
[G709-2012] defines two types of TSs, but each link can only support a single type at a given time. In order to perform a correct path computation (i.e., the LSP endpoints have matching Tributary Slot Granularity values) the Tributary Slot Granularity needs to be advertised.
[G709-2012]は2つのタイプのTSを定義していますが、各リンクは一度に1つのタイプしかサポートできません。正しいパス計算を実行するには（つまり、LSPエンドポイントに一致するTributary Slot Granularity値がある）、Tributary Slot Granularityをアドバタイズする必要があります。
- Support different priorities for resource reservation
- リソース予約のさまざまな優先度をサポートする
How many priority levels should be supported depends on the operator's policy. Therefore, the routing protocol should be capable of supporting up to 8 priority levels as defined in [RFC4202].
サポートする必要のある優先レベルの数は、オペレーターのポリシーによって異なります。したがって、ルーティングプロトコルは、[RFC4202]で定義されている最大8つの優先度レベルをサポートできる必要があります。
- Support link bundling
- サポートリンクバンドル
As described in [RFC4201], link bundling can improve routing scalability by reducing the number of TE links that have to be handled by the routing protocol. The routing protocol should be capable of supporting the bundling of multiple OTU links, at the same line rate and muxing hierarchy, between a pair of nodes that a TE link does. Note that link bundling is optional and is implementation dependent.
[RFC4201]で説明されているように、リンクバンドリングは、ルーティングプロトコルで処理する必要があるTEリンクの数を減らすことにより、ルーティングのスケーラビリティを向上させることができます。ルーティングプロトコルは、TEリンクが行うノードのペア間で、同じラインレートと多重化階層で、複数のOTUリンクのバンドルをサポートできる必要があります。リンクバンドルはオプションであり、実装に依存することに注意してください。
- Support for Control of Hitless Adjustment of ODUflex (GFP)
- ODUflex（GFP）のヒットレス調整の制御のサポート
The control plane should support hitless adjustment of ODUflex, so the routing protocol should be capable of differentiating whether or not an ODU link can support hitless adjustment of ODUflex (GFP) and how many resources can be used for resizing. This can be achieved by introducing a new signal type "ODUflex(GFP-F), resizable" that implies the support for hitless adjustment of ODUflex (GFP) by that link.
コントロールプレーンは、ODUflexのヒットレス調整をサポートする必要があるため、ルーティングプロトコルは、ODUflexがODUflex（GFP）のヒットレス調整をサポートできるかどうか、およびサイズ変更に使用できるリソースの数を区別できる必要があります。これは、そのリンクによるODUflex（GFP）のヒットレス調整のサポートを意味する新しい信号タイプ「ODUflex（GFP-F）、サイズ変更可能」を導入することによって実現できます。
As mentioned in Section 5.1, one method of enabling multiplexing hierarchy is via usage of dedicated boards to allow tunneling of new services through legacy ODU1, ODU2, and ODU3 containers. Such dedicated boards may have some constraints with respect to switching matrix access; detection and representation of such constraints is for further study.
セクション5.1で説明したように、多重化階層を有効にする1つの方法は、専用ボードを使用して、レガシーODU1、ODU2、およびODU3コンテナーを通じて新しいサービスのトンネリングを可能にすることです。このような専用ボードには、マトリックスアクセスの切り替えに関していくつかの制約がある場合があります。このような制約の検出と表現は、今後の検討課題です。
As discussed in Section 5.3, path computation needs to know the interface switching capability of links. The switching capability of two ends of the link may be different, so the link capability of two ends should be correlated.
セクション5.3で説明したように、パス計算はリンクのインターフェース切り替え機能を知る必要があります。リンクの両端のスイッチング機能は異なる可能性があるため、両端のリンク機能は相関させる必要があります。
LMP [RFC4204] provides a control-plane protocol for exchanging and correlating link capabilities.
LMP [RFC4204]は、リンク機能を交換および相互に関連付けるためのコントロールプレーンプロトコルを提供します。
Note that LO ODU type information can be, in principle, discovered by routing. Since in certain cases, routing is not present (e.g., in the case of a User-Network Interface (UNI)), we need to extend link management protocol capabilities to cover this aspect. If routing is present, discovery via LMP could also be optional.
LO ODUタイプの情報は、原則としてルーティングによって検出できることに注意してください。場合によってはルーティングが存在しないため（たとえば、ユーザーネットワークインターフェイス（UNI）の場合）、リンク管理プロトコル機能を拡張してこの側面をカバーする必要があります。ルーティングが存在する場合、LMPによる検出もオプションになる可能性があります。
- Correlating the granularity of the TS
- TSの粒度の相関
As discussed in Section 3.1.2, the two ends of a link may support different TS granularity. In order to allow interconnection, the node with 1.25 Gbps granularity should fall back to 2.5 Gbps granularity.
セクション3.1.2で説明したように、リンクの両端は異なるTS細分性をサポートする場合があります。相互接続を許可するには、粒度が1.25 Gbpsのノードを粒度が2.5 Gbpsにフォールバックする必要があります。
Therefore, it is necessary for the two ends of a link to correlate the granularity of the TS. This ensures the correct use of the TE link.
したがって、リンクの両端でTSの粒度を関連付ける必要があります。これにより、TEリンクが正しく使用されます。
- Correlating the supported LO ODU signal types and multiplexing hierarchy capability
- サポートされているLO ODU信号タイプと多重化階層機能の関連付け
Many new ODU signal types have been introduced in [G709-2012], such as ODU0, ODU4, ODU2e, and ODUflex. It is possible that equipment does not support all the LO ODU signal types introduced by new standards or documents. Furthermore, since multiplexing hierarchy may not be supported by the legacy OTNs, it is possible that only one end of an ODU link can support multiplexing hierarchy capability or that the two ends of the link support different multiplexing hierarchy capabilities (e.g., one end of the link supports ODU0 into ODU1 into ODU3 multiplexing while the other end supports ODU0 into ODU2 into ODU3 multiplexing).
ODU0、ODU4、ODU2e、ODUflexなど、多くの新しいODU信号タイプが[G709-2012]で導入されました。機器が、新しい標準またはドキュメントによって導入されたすべてのLO ODU信号タイプをサポートしていない可能性があります。さらに、多重化階層はレガシーOTNでサポートされていない可能性があるため、ODUリンクの一方の端のみが多重化階層機能をサポートできるか、リンクの両端が異なる多重化階層機能をサポートしている可能性があります（たとえば、リンクはODU0からODU1からODU3への多重化をサポートし、もう一方の端はODU0からODU2からODU3への多重化をサポートします。
For control and management consideration, it is necessary for the two ends of an HO ODU link to correlate the types of LO ODU that can be supported and the multiplexing hierarchy capabilities that can be provided by the other end.
制御と管理を考慮して、HO ODUリンクの両端で、サポートできるLO ODUのタイプと、もう一方の端で提供できる多重化階層機能を関連付ける必要があります。
With the introduction of [G709-2012], there may be OTN composed of a mixture of nodes, some of which support the legacy OTN and run the control-plane protocols defined in [RFC4328], while others support [G709-2012] and the new OTN control plane characterized in this document. Note that a third case, for the sake of completeness, consists of nodes supporting the legacy OTN referenced by [RFC4328] with a new OTN control plane, but such nodes can be considered new nodes with limited capabilities.
[G709-2012]の導入により、いくつかのノードがレガシーOTNをサポートし、[RFC4328]で定義されているコントロールプレーンプロトコルを実行するノードと、[G709-2012]およびこのドキュメントで特徴付けられる新しいOTNコントロールプレーン。 3番目のケースは、完全を期すために、[RFC4328]が参照するレガシーOTNをサポートするノードと新しいOTNコントロールプレーンで構成されていますが、そのようなノードは機能が制限された新しいノードと見なすことができます。
This section discusses the compatibility of nodes implementing the control-plane procedures defined in [RFC4328] in support of the legacy OTN and the control-plane procedures defined to support [G709-2012] as outlined by this document.
このセクションでは、従来のOTNをサポートするために[RFC4328]で定義されたコントロールプレーンプロシージャを実装するノードの互換性と、このドキュメントで概説されている[G709-2012]をサポートするために定義されたコントロールプレーンプロシージャについて説明します。
Compatibility needs to be considered only when controlling an ODU1, ODU2, or ODU3 connection because the legacy OTN only supports these three ODU signal types. In such cases, there are several possible options, including:
レガシーOTNはこれら3つのODU信号タイプのみをサポートするため、ODU1、ODU2、またはODU3接続を制御する場合にのみ互換性を考慮する必要があります。このような場合、次のようないくつかの可能なオプションがあります。
- A node supporting [G709-2012] could support only the control-plane procedures related to [G709-2012], in which case both types of nodes would be unable to jointly control an LSP for an ODU type that both nodes support in the data plane.
- [G709-2012]をサポートするノードは、[G709-2012]に関連するコントロールプレーン手順のみをサポートできます。その場合、両方のタイプのノードは、両方のノードがデータでサポートするODUタイプのLSPを共同で制御できません。飛行機。
- A node supporting [G709-2012] could support both the control plane related to [G709-2012] and the control plane defined in [RFC4328].
- [G709-2012]をサポートするノードは、[G709-2012]に関連するコントロールプレーンと[RFC4328]で定義されたコントロールプレーンの両方をサポートできます。
o Such a node could identify which set of procedures to follow when initiating an LSP based on the Switching Capability value advertised in routing.
o このようなノードは、ルーティングでアドバタイズされたスイッチング機能の値に基づいて、LSPを開始するときに従うべき一連の手順を識別できます。
o Such a node could follow the set of procedures based on the Switching Type received in signaling messages from an upstream node.
o このようなノードは、上流ノードからのシグナリングメッセージで受信されたスイッチングタイプに基づいて、一連の手順に従うことができます。
o Such a node, when processing a transit LSP, could select which signaling procedures to follow based on the Switching Capability value advertised in routing by the next-hop node.
o そのようなノードは、トランジットLSPを処理するときに、ネクストホップノードによってルーティングでアドバタイズされたスイッチング機能値に基づいて、どのシグナリング手順に従うかを選択できます。
[RFC7025] describes the requirements for GMPLS applications of PCE in order to establish GMPLS LSP. PCE needs to consider the GMPLS TE attributes appropriately once a Path Computation Client (PCC) or another PCE requests a path computation. The TE attributes that can be contained in the path calculation request message from the PCC or the PCE defined in [RFC5440] include switching capability, encoding type, signal type, etc.
[RFC7025]は、GMPLS LSPを確立するためのPCEのGMPLSアプリケーションの要件を説明しています。 PCEは、パス計算クライアント（PCC）または別のPCEがパス計算を要求すると、GMPLS TE属性を適切に考慮する必要があります。 [RFC5440]で定義されているPCCまたはPCEからのパス計算要求メッセージに含めることができるTE属性には、スイッチング機能、エンコーディングタイプ、信号タイプなどがあります。
As described in Section 5.2, new signal types and new signals with variable bandwidth information need to be carried in the extended signaling message of path setup. For the same consideration, the PCE Communication Protocol (PCECP) also has a desire to be extended to carry the new signal type and related variable bandwidth information when a PCC requests a path computation.
セクション5.2で説明したように、新しい信号タイプと可変帯域幅情報を持つ新しい信号は、パスセットアップの拡張シグナリングメッセージで伝送する必要があります。同じ考慮事項について、PCE通信プロトコル（PCECP）も、PCCがパス計算を要求したときに、新しい信号タイプと関連する可変帯域幅情報を伝送するように拡張する必要があります。
From the management perspective, the management function should be capable of managing not only the legacy OTN referenced by [RFC4328], but also new management functions introduced by the new features as specified in [G709-2012] (for more information, see Sections 3 and 4). OTN Operations, Administration, and Maintenance (OAM) configuration could be done through either Network Management Systems (NMS) or the GMPLS control plane as defined in [TDM-OAM]. For further details on management aspects for GMPLS networks, refer to [RFC3945].
管理の観点から、管理機能は、[RFC4328]によって参照されるレガシーOTNだけでなく、[G709-2012]で指定された新機能によって導入される新しい管理機能も管理できる必要があります（詳細については、セクション3を参照してください）および4）。 OTN運用、管理、および保守（OAM）の構成は、[TDM-OAM]で定義されているように、ネットワーク管理システム（NMS）またはGMPLSコントロールプレーンのいずれかを介して行うことができます。 GMPLSネットワークの管理側面の詳細については、[RFC3945]を参照してください。
In case PCE is used to perform path computation in OTN, the PCE manageability should be considered (for more information, see Section 8 of [RFC5440]).
PCEを使用してOTNでパス計算を実行する場合は、PCEの管理性を検討する必要があります（詳細については、[RFC5440]のセクション8を参照してください）。
If MI AUTOpayloadtype is activated (see [G798]), a node supporting 1.25 Gbps TS can interwork with the other nodes that support 2.5 Gbps TS by combining specific TSs together in the data plane. The control plane must support this TS combination.
MI AUTOpayloadtypeがアクティブ化されている場合（[G798]を参照）、1.25 Gbps TSをサポートするノードは、特定のTSをデータプレーンで結合することにより、2.5 Gbps TSをサポートする他のノードと相互作用できます。コントロールプレーンは、このTSの組み合わせをサポートする必要があります。
Path
+----------+ ------------> +----------+
| TS1==|===========\--------+--TS1 |
| TS2==|=========\--\-------+--TS2 |
| TS3==|=======\--\--\------+--TS3 |
| TS4==|=====\--\--\--\-----+--TS4 |
| | \ \ \ \----+--TS5 |
| | \ \ \------+--TS6 |
| | \ \--------+--TS7 |
| | \----------+--TS8 |
+----------+ <------------ +----------+
node A Resv node B
Figure 5: Interworking between 1.25 Gbps TS and 2.5 Gbps TS
図5：1.25 Gbps TSと2.5 Gbps TS間のインターワーキング
Take Figure 5 as an example. Assume that there is an ODU2 link between node A and B, where node A only supports the 2.5 Gbps TS while node B supports the 1.25 Gbps TS. In this case, the TS#i and TS#i+4 (where i<=4) of node B are combined together. When creating an ODU1 service in this ODU2 link, node B reserves the TS#i and TS#i+4 with the granularity of 1.25 Gbps. But in the label sent from B to A, it is indicated that the TS#i with the granularity of 2.5 Gbps is reserved.
例として図5を見てください。ノードAとBの間にODU2リンクがあると想定します。ノードAは2.5 Gbps TSのみをサポートし、ノードBは1.25 Gbps TSをサポートします。この場合、ノードBのTS＃iとTS＃i + 4（i <= 4）が結合されます。このODU2リンクでODU1サービスを作成する場合、ノードBは1.25 Gbpsの粒度でTS＃iおよびTS＃i + 4を予約します。ただし、BからAに送信されたラベルでは、粒度が2.5 GbpsのTS＃iが予約されていることが示されています。
In the opposite direction, when receiving a label from node A indicating that the TS#i with the granularity of 2.5 Gbps is reserved, node B will reserve the TS#i and TS#i+4 with the granularity of 1.25 Gbps in its data plane.
反対方向では、ノードAから、2.5 Gbpsの粒度を持つTS＃iが予約されていることを示すラベルを受信すると、ノードBは、データ内に1.25 Gbpsの粒度を持つTS＃iおよびTS＃i + 4を予約します。飛行機。
The use of control-plane protocols for signaling, routing, and path computation opens an OTN to security threats through attacks on those protocols. However, this is not greater than the risks presented by the existing OTN control plane as defined by [RFC4203] and [RFC4328]. Meanwhile, the Data Communication Network (DCN) for OTN GMPLS control-plane protocols is likely to be in the in-fiber overhead, which, together with access lists at the network edges, provides a significant security feature. For further details of specific security measures, refer to the documents that define the protocols ([RFC3473], [RFC4203], [RFC5307], [RFC4204], and [RFC5440]). [RFC5920] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane.
シグナリング、ルーティング、およびパス計算にコントロールプレーンプロトコルを使用すると、OTNがこれらのプロトコルへの攻撃を通じてセキュリティの脅威にさらされます。ただし、これは、[RFC4203]と[RFC4328]で定義されている既存のOTNコントロールプレーンによって提示されるリスクを超えません。一方、OTN GMPLSコントロールプレーンプロトコルのデータ通信ネットワーク（DCN）は、ファイバーオーバーヘッドに含まれている可能性が高く、ネットワークエッジのアクセスリストとともに重要なセキュリティ機能を提供します。特定のセキュリティ対策の詳細については、プロトコルを定義するドキュメント（[RFC3473]、[RFC4203]、[RFC5307]、[RFC4204]、および[RFC5440]）を参照してください。 [RFC5920]は、GMPLSコントロールプレーンのセキュリティの脆弱性と保護メカニズムの概要を提供します。
We would like to thank Maarten Vissers and Lou Berger for their reviews and useful comments.
Maarten VissersとLou Bergerのレビューと有益なコメントに感謝します。
Jianrui Han Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28972913 EMail: hanjianrui@huawei.com
Jianrui Han Huawei Technologies Co.、Ltd. F3-5-B R＆D Center、Huawei Base Bantian、Longgang District Shenzhen 518129 P.R. China電話：+ 86-755-28972913メール：hanjianrui@huawei.com
Malcolm Betts EMail: malcolm.betts@rogers.com
Malcolm Betts Eメール：malcolm.betts@rogers.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
Pietro Grandi Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate（Milan）Italy電話：+39039 6864930メール：pietro_vittorio.grandi@alcatel-lucent.it
Eve Varma Alcatel-Lucent 1A-261, 600-700 Mountain Av PO Box 636 Murray Hill, NJ 07974-0636 USA EMail: eve.varma@alcatel-lucent.com
Eve Varma Alcatel-Lucent 1A-261、600-700 Mountain Av PO Box 636 Murray Hill、NJ 07974-0636 USAメール：eve.varma@alcatel-lucent.com
[G709-2012] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709/Y.1331 Recommendation, February 2012.
[G709-2012] ITU-T、「Interface for the Optical Transport Network（OTN）」、G.709 / Y.1331勧告、2012年2月。
[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月。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201] Kompella、K.、Rekhter、Y。、およびL. Berger、「MPLSトラフィックエンジニアリング（TE）におけるリンクバンドリング」、RFC 4201、2005年10月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202] Kompella、K。、編、およびY. Rekhter、編、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）をサポートするルーティング拡張機能」、RFC 4202、2005年10月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K.、Ed。、and Y. Rekhter、Ed。、 "OSPF Extensions Support in Supported Generalized Multi-Protocol Label Switching（GMPLS）"、RFC 4203、October 2005。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J。、編、「リンク管理プロトコル（LMP）」、RFC 4204、2005年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。、およびY. Rekhter、「Label Switched Paths（LSP）Hierarchy with Generalized Multi-Protocol Label Switching（GMPLS）Traffic Engineering（TE）」、RFC 4206、2005年10月。
[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月。
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307] Kompella、K。、編、およびY. Rekhter、編、「IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching（GMPLS）」、RFC 5307、2008年10月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、Ed。、and JL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、2009年3月。
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010.
[RFC6001] Papadimitriou、D.、Vigoureux、M.、Siomoto、K.、Brungard、D。、およびJL。 Le Roux、「Multilayer- Multi-Region Networks（MLN / MRN）用のGeneralized MPLS（GMPLS）Protocol Extensions」、RFC 6001、2010年10月。
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011.
[RFC6107] Shiomoto、K.、Ed。、and A. Farrel、Ed。、 "Procedures for Dynamicly Signaled Hierarchical Label Switched Paths"、RFC 6107、February 2011。
[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月。
[G798] ITU-T, "Characteristics of optical transport network hierarchy equipment functional blocks", G.798 Recommendation, December 2012.
[G798] ITU-T、「光トランスポートネットワーク階層機器の機能ブロックの特性」、G.798勧告、2012年12月。
[G872-2001] ITU-T, "Architecture of optical transport networks", G.872 Recommendation, November 2001.
[G872-2001] ITU-T、「Architecture of Optical Transport Networks」、G.872勧告、2001年11月。
[G872-2012] ITU-T, "Architecture of optical transport networks", G.872 Recommendation, October 2012.
[G872-2012] ITU-T、「Architecture of Optical Transport Networks」、G.872勧告、2012年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月。
[G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for virtual concatenated signals", G.7042/Y.1305, March 2006.
[G7042] ITU-T、「仮想連結信号のリンク容量調整スキーム（LCAS）」、G.7042 / Y.1305、2006年3月。
[G7044] ITU-T, "Hitless adjustment of ODUflex (HAO)", G.7044/Y.1347, October 2011.
[G7044] ITU-T、「HITless Adjustment of ODUflex（HAO）」、G.7044 / Y.1347、2011年10月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] Mannie、E。、編、「Generalized Multi-Protocol Label Switching（GMPLS）Architecture」、RFC 3945、2004年10月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、2006年8月。
[RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, April 2011.
[RFC6163] Lee、Y.、Ed。、Bernstein、G.、Ed。、およびW. Imajuku、「GMPLSおよびPath Computation Element（PCE）Control for Wavelength Switched Optical Networks（WSONs）」、RFC 6163、4月2011。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. Margaria, "Requirements for GMPLS Applications of PCE", RFC 7025, September 2013.
[RFC7025] Otani、T.、Ogaki、K.、Caviglia、D.、Zhang、F.、and C. Margaria、 "Requirements for GMPLS Applications of PCE"、RFC 7025、September 2013。
[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月。
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
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28973237 EMail: huawei.danli@huawei.com
Dan Li Huawei Technologies F3-5-B R＆D Center、Huawei Base Bantian、Longgang District Shenzhen 518129 P.R. China電話：+ 86-755-28973237メール：huawei.danli@huawei.com
Han Li China Mobile Communications Corporation 53 A Xibianmennei Ave. Xuanwu District Beijing 100053 P.R. China Phone: +86-10-66006688 EMail: lihan@chinamobile.com
Han Li China Mobile Communications Corporation 53 A Xibianmennei Ave. Xuanwu District Beijing 100053 P.R. China電話：+ 86-10-66006688メール：lihan@chinamobile.com
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