[要約] RFC 9376は、GMPLSを使用してODUk LSPsをODUCnリンク上に設定する適用性を検討しています。この文書の目的は、ITU-T勧告G.709の2020年版で定義されたODUCnリンクにおけるGMPLSの適用性を評価することです。
Internet Engineering Task Force (IETF) Q. Wang, Ed.
Request for Comments: 9376 ZTE Corporation
Category: Informational R. Valiveti, Ed.
ISSN: 2070-1721 Infinera Corp
H. Zheng, Ed.
Huawei
H. van Helvoort
Hai Gaoming BV
S. Belotti
Nokia
March 2023
This document examines the applicability of using existing GMPLS routing and signaling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of ITU-T Recommendation G.709.
このドキュメントでは、既存のGMPLSルーティングとシグナル伝達メカニズムを使用して、光データデータユニットユニット（ODP）ラベルスイッチドパス（LSP）をセットアップして、ITU-Tの2020バージョンで定義されている光データデータUnit-CN（ODUCN）リンクをセットアップすることを検証します。推奨G.709。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9376.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9376で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. OTN Terminology Used in This Document
3. Overview of OTUCn/ODUCn in G.709
3.1. OTUCn
3.1.1. OTUCn-M
3.2. ODUCn
3.3. Tributary Slot Granularity
3.4. Structure of OPUCn MSI with Payload Type 0x22
3.5. Client Signal Mappings
4. GMPLS Implications and Applicability
4.1. TE Link Representation
4.2. GMPLS Signaling
4.3. GMPLS Routing
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Possible Future Work
Contributors
Authors' Addresses
The current GMPLS routing [RFC7138] and signaling [RFC7139] extensions support the control of the Optical Transport Network (OTN) signals and capabilities that were defined in the 2012 version of ITU-T Recommendation G.709 [ITU-T_G709_2012].
現在のGMPLSルーティング[RFC7138]およびシグナリング[RFC7139]拡張は、ITU-T推奨G.709 [ITU-T_G709_2012]の2012バージョンで定義された光輸送ネットワーク（OTN）信号と機能の制御をサポートします。
In 2016, a new version of ITU-T Recommendation G.709 was published: [ITU-T_G709_2016]. This version introduced higher-rate Optical Transport Unit (OTU) and Optical Data Unit (ODU) signals, termed "OTUCn" and "ODUCn", respectively, which have a nominal rate of n*100 Gbit/s. According to the definition in [ITU-T_G709_2016], OTUCn and ODUCn perform only the digital section-layer role, and ODUCn supports only ODUk clients. This document focuses on the use of existing GMPLS mechanisms to set up ODUk (e.g., ODUflex) Label Switched Paths (LSPs) over ODUCn links, independently from how these links have been set up.
2016年、ITU-T推奨G.709の新しいバージョンが公開されました：[ITU-T_G709_2016]。このバージョンでは、それぞれ「OTUCN」と「ODUCN」と呼ばれる高レート光輸送ユニット（OTU）と光学データユニット（ODU）信号を導入しました。[ITU-T_G709_2016]の定義によれば、OTUCNとODUCNはデジタルセクションレイヤーの役割のみを実行し、ODUCNはODUKクライアントのみをサポートします。このドキュメントでは、既存のGMPLSメカニズムの使用に焦点を当てて、ODUCNリンク上のODUK（OduFlexなど）スイッチ付きパス（LSP）をセットアップし、これらのリンクのセットアップとは独立しています。
Because [ITU-T_G709_2020] does not introduce any new features to OTUCn and ODUCn compared to [ITU-T_G709_2016], this document first presents an overview of the OTUCn and ODUCn signals in [ITU-T_G709_2020] and then analyzes how the current GMPLS routing and signaling mechanisms can be utilized to set up ODUk (e.g., ODUflex) LSPs over ODUCn links.
[ITU-T_G709_2020]は[ITU-T_G709_2016]と比較してOTUCNとODUCNに新機能を導入していないため、このドキュメントは最初に[ITU-T_G709_2020]のOTUCNとODUCNシグナルの概要を示し、次に現在のGMPLSをどのように分析するかを分析します。また、シグナル伝達メカニズムを利用して、ODUCNリンク上でODUK（たとえば、Oduflex）LSPをセットアップできます。
This document assumes that readers are familiar with OTN, GMPLS, and how GMPLS is applied in OTN. As such, this document doesn't provide any background pertaining to OTN that include links with capacities of 100 Gbit/s or less; this background could be found in documents such as [RFC7062] and [RFC7096]. This document provides an overview of the data plane primitives that enable links with capacities greater than 100 Gbit/s and analyzes the extensions that would be required in the current GMPLS routing and signaling mechanisms to support evolution in OTN.
このドキュメントは、読者がOTN、GMPLS、およびGMPLSがOTNでどのように適用されるかに精通していることを前提としています。そのため、このドキュメントは、100 gbit/s以下の容量を持つリンクを含むOTNに関する背景を提供しません。この背景は、[RFC7062]や[RFC7096]などの文書に記載されています。このドキュメントは、100 Gbit/sを超える容量とのリンクを有効にするデータプライミティブの概要を提供し、OTNの進化をサポートするために現在のGMPLSルーティングおよびシグナル伝達メカニズムで必要とされる拡張を分析します。
FlexO:
Flexo：
Flexible OTN information structure. This information structure usually has a specific bitrate and frame format that consists of overhead and payload, which are used as a group for the transport of an OTUCn signal.
柔軟なOTN情報構造。この情報構造には通常、OTUCN信号の輸送のためのグループとして使用されるオーバーヘッドとペイロードで構成される特定のビットレートおよびフレーム形式があります。
LSP:
LSP：
Label Switched Path
ラベルスイッチ付きパス
MSI:
MSI：
Multiplex Structure Indicator. This structure indicates the grouping of the tributary slots in an OPU payload area that realizes a client signal, which is multiplexed into an OPU. The individual clients multiplexed into the OPU payload area are distinguished by the Tributary Port Number (TPN).
マルチプレックス構造インジケーター。この構造は、OPUに多重化されたクライアント信号を実現するOPUペイロード領域の支流スロットのグループ化を示しています。OPUペイロードエリアに多重化された個々のクライアントは、支流ポート番号（TPN）によって区別されます。
ODU:
ODU：
Optical Data Unit. An ODU has the frame structure and overhead, as defined in Figure 12-1 of [ITU-T_G709_2020]. ODUs can be formed in two ways: a) by encapsulating a single non-OTN client, such as SONET/SDH (Synchronous Optical Network / Synchronous Digital Hierarchy) or Ethernet, or b) by multiplexing lower-rate ODUs. In general, the ODU layer represents the path layer in OTN. The only exception is the ODUCn signal (defined below), which is defined to be a section-layer signal. In the classification based on bitrates of the ODU signals, ODUs are of two types: fixed rate and flexible rate. Flexible-rate ODUs, called "ODUflex", have a rate that is 239/238 times the bitrate of the client signal they encapsulate.
光データユニット。ODUには、[ITU-T_G709_2020]の図12-1に定義されているように、フレーム構造とオーバーヘッドがあります。ODUは、a）SONET / SDH（同期光ネットワーク /同期デジタル階層）またはイーサネット、またはB）低レートODUを多重化することにより、単一の非OTNクライアントをカプセル化することにより、2つの方法で形成できます。一般に、ODU層はOTNのパス層を表します。唯一の例外は、ODUCN信号（以下に定義）です。これは、セクション層信号であると定義されています。ODU信号のビットレートに基づく分類では、ODUは固定レートと柔軟なレートの2つのタイプです。「Oduflex」と呼ばれる柔軟なレートODUSは、カプセル化するクライアント信号のビットレートの239/238倍のレートを持っています。
ODUC:
ODUC：
Optical Data Unit-C. This signal has a bandwidth of approximately 100 Gbit/s and is of a slightly higher bitrate than the fixed rate ODU4 signal. This signal has the format defined in Figure 12-1 of [ITU-T_G709_2020]. This signal represents the building block for constructing a higher-rate signal called "ODUCn" (defined below).
光データユニットc。この信号の帯域幅は約100 gbit/sで、固定速度ODU4信号よりもわずかに高いビットレートです。この信号には、[ITU-T_G709_2020]の図12-1に定義された形式があります。この信号は、「ODUCN」と呼ばれるより高いレート信号を構築するための構成要素を表します（以下に定義）。
ODUCn:
oducn：
Optical Data Unit-Cn, where Cn indicates the bitrate of approximately n*100 Gbit/s. This frame structure consists of "n" interleaved frame and multiframe synchronous instances of the ODUC signal, each of which has the format defined in Figure 12-1 of [ITU-T_G709_2020].
光データユニットCN。ここで、CNは約n*100 gbit/sのビットレートを示します。このフレーム構造は、ODUC信号の「n」インターリーブフレームと多面的な同期インスタンスで構成されており、それぞれに[ITU-T_G709_2020]の図12-1に形式が定義されています。
ODUflex:
oduflex：
Optical Data Unit - flexible rate. An ODUflex has the same frame structure as a "generic" ODU but with a rate that is a fixed multiple of the bitrate of the client signal it encapsulates. [ITU-T_G709_2020] defines specific ODUflex containers that are required to transport specific clients such as 50GE, 200GE, 400GE, etc.
光データユニット - 柔軟なレート。OduFlexは、「一般的な」ODUと同じフレーム構造を持っていますが、カプセル化するクライアント信号のビットレートの固定倍数であるレートがあります。[ITU-T_G709_2020]は、50GE、200GE、400GEなどの特定のクライアントを輸送するために必要な特定のOduFlexコンテナを定義します。
ODUk:
Oduk：
Optical Data Unit-k, where k is one of {0, 1, 2, 2e, 3, 4}. The term "ODUk" refers to an ODU whose bitrate is fully specified by the index k. The bitrates of the ODUk signal for k = {0, 1, 2, 2e, 3, 4} are approximately 1.25 Gbit/s, 2.5 Gbit/s, 10 Gbit/s, 10.3 Gbit/s, 40 Gbit/s, and 100 Gbit/s, respectively.
光データUnit-K、ここで、kは{0、1、2、2e、3、4}の1つです。「Oduk」という用語は、Bitrateがインデックスkによって完全に指定されているODUを指します。k = {0、1、2、2e、3、4}のoduk信号のビットレートは、約1.25 gbit/s、2.5 gbit/s、10 gbit/s、10.3 gbit/s、40 gbit/s、およびs、およびand、および40 gbit/sです。それぞれ100 gbit/s。
OPUC:
OPUC：
Optical Payload Unit-C. This signal has a payload of approximately 100 Gbit/s. This structure represents the payload area of the ODUC signal.
光学ペイロードユニットc。この信号には、約100 gbit/sのペイロードがあります。この構造は、ODUC信号のペイロード領域を表します。
OPUCn:
Opucn：
Optical Payload Unit-Cn, where Cn indicates that the bitrate is approximately n*100 Gbit/s. This structure represents the payload area of the ODUCn signal.
光学ペイロードユニットCN。ここで、CNはビットレートが約N*100 gBit/sであることを示します。この構造は、ODUCN信号のペイロード領域を表します。
OTN:
OTN：
Optical Transport Network
光学輸送ネットワーク
OTUC:
OTUC：
Optical Transport Unit-C. This signal has a bandwidth of approximately 100 Gbit/s. This signal forms the building block of the OTUCn signal defined below, which has a bandwidth of approximately n*100 Gbit/s.
光輸送ユニットC。この信号の帯域幅は約100 gbit/sです。この信号は、以下に定義されているOTUCN信号の構成要素を形成します。これは、帯域幅が約n*100 gbit/sです。
OTUCn:
otucn：
Fully standardized Optical Transport Unit-Cn. This frame structure is realized by extending the ODUCn signal with the OTU layer overhead. The structure of this signal is illustrated in Figure 11-4 of [ITU-T_G709_2020]. Note that the term "fully standardized" is defined by ITU-T in Section 6.1.1 of [ITU-T_G709_2020].
完全に標準化された光学輸送ユニットCN。このフレーム構造は、OTU層のオーバーヘッドでODUCN信号を拡張することにより実現されます。この信号の構造は、[ITU-T_G709_2020]の図11-4に示されています。「完全に標準化された」という用語は、[ITU-T_G709_2020]のセクション6.1.1のITU-Tで定義されていることに注意してください。
OTUCn-M:
otucn-m：
This signal is an extension of the OTUCn signal introduced above. This signal contains the same amount of overhead as the OTUCn signal but contains a reduced amount of payload area. Specifically, the payload area consists of M tributary slots (each 5 Gbit/s), where M is less than 20*n, which is the number of tributary slots in the OTUCn signal.
この信号は、上記で紹介したOTUCN信号の拡張です。この信号には、OTUCN信号と同じ量のオーバーヘッドが含まれていますが、ペイロード領域の量が減少します。具体的には、ペイロード領域はm支流スロット（それぞれ5 gbit/s）で構成され、mは20*n未満であり、これはOTUCN信号の支流スロットの数です。
PSI:
psi：
Payload Structure Indicator. This is a 256-byte signal that describes the composition of the OPU signal. This field is a concatenation of the payload type (PT) and the Multiplex Structure Indicator (MSI) defined below.
ペイロード構造インジケーター。これは、OPU信号の組成を記述する256バイト信号です。このフィールドは、ペイロードタイプ（PT）と以下に定義されているマルチプレックス構造インジケーター（MSI）の連結です。
TPN:
TPN：
Tributary Port Number. The tributary port number is used to indicate the port number of the client signal that is being transported in one specific tributary slot.
支流港番号。支流ポート番号は、1つの特定の支流スロットで輸送されているクライアント信号のポート番号を示すために使用されます。
Detailed descriptions for some of these terms can be found in [ITU-T_G709_2020].
これらの用語のいくつかの詳細な説明は、[ITU-T_G709_2020]に記載されています。
This section provides an overview of the OTUCn/ODUCn signals defined in [ITU-T_G709_2020]. The text in this section is purely descriptive and is not normative. For a full description of OTUCn/ODUCn signals, please refer to [ITU-T_G709_2020]. In the event of any discrepancy between this text and [ITU-T_G709_2020], that other document is definitive.
このセクションでは、[ITU-T_G709_2020]で定義されているOTUCN/ODUCN信号の概要を説明します。このセクションのテキストは純粋に記述的であり、規範的ではありません。OTUCN/ODUCN信号の完全な説明については、[ITU-T_G709_2020]を参照してください。このテキストと[ITU-T_G709_2020]の間に矛盾がある場合、その他の文書は決定的です。
In order to carry client signals with rates greater than 100 Gbit/s, [ITU-T_G709_2020] takes a general and scalable approach that decouples the rates of OTU signals from the client rate. The new OTU signal is called "OTUCn", and this signal is defined to have a rate of (approximately) n*100 Gbit/s. The following are the key characteristics of the OTUCn signal:
100 gbit/sを超えるレートでクライアント信号を携帯するために、[ITU-T_G709_2020]は、クライアントレートからOTU信号のレートを切り離す一般的でスケーラブルなアプローチを採用します。新しいOTU信号は「OTUCN」と呼ばれ、この信号は（約）n*100 gbit/sの速度を持つように定義されています。以下は、OTUCN信号の重要な特性です。
* The OTUCn signal contains one ODUCn. The OTUCn and ODUCn signals perform digital section-layer roles only (see Section 6.1.1 of [ITU-T_G709_2020])
* OTUCN信号には1つのODUCNが含まれています。OTUCNとODUCN信号は、デジタルセクション層の役割のみを実行します（[ITU-T_G709_2020]のセクション6.1.1を参照）
* The OTUCn signals are formed by interleaving n synchronous OTUC signals (which are labeled 1, 2, ..., n).
* OTUCN信号は、n同期OTUCシグナルをインターリーブすることによって形成されます（1、2、...、nとラベル付けされています）。
* Each of the OTUC instances has the same overhead as the standard OTUk signal in [ITU-T_G709_2020]. Note that the OTUC signal doesn't include the Forward Error Correction (FEC) columns illustrated in Figure 11-1 of [ITU-T_G709_2020]. The OTUC signal includes an ODUC.
* OTUCインスタンスのそれぞれは、[ITU-T_G709_2020]の標準OTUK信号と同じオーバーヘッドを持っています。OTUC信号には、[ITU-T_G709_2020]の図11-1に示されている前方エラー補正（FEC）列は含まれていないことに注意してください。OTUC信号にはODUCが含まれています。
* The OTUC signal has a slightly higher rate compared to the OTU4 signal (without FEC); this is to ensure that the OPUC payload area can carry an ODU4 signal.
* OTUC信号は、OTU4信号（FECなし）と比較してわずかに高い速度を持っています。これは、OPUCペイロード領域がODU4信号を運ぶことができるようにするためです。
* The combined signal OTUCn has n instances of OTUC overhead and n instances of ODUC overhead.
* 結合された信号OTUCNには、OTUCオーバーヘッドのnインスタンスとODUCオーバーヘッドのnインスタンスがあります。
The OTUCn, ODUCn, and OPUCn signal structures are presented in a (physical) interface-independent manner, by means of n OTUC, ODUC, and OPUC instances that are marked #1 to #n.
OTUCN、ODUCN、およびOPUCN信号構造は、＃1から#NとマークされているN OTUC、ODUC、およびOPUCインスタンスを使用して、（物理的な）インターフェイスに依存しない方法で提示されます。
OTUCn interfaces can be categorized as follows, based on the type of peer network element:
OTUCNインターフェイスは、ピアネットワーク要素のタイプに基づいて、次のように分類できます。
inter-domain interfaces:
ドメイン間インターフェイス：
These types of interfaces are used for connecting OTN edge nodes to (a) client equipment (e.g., routers) or (b) hand-off points from other OTN. ITU-T Recommendation G709.1 [ITU-T_G709.1] specifies a flexible interoperable short-reach OTN interface over which an OTUCn (n >=1) is transferred, using bonded Flexible OTN information structure (FlexO) interfaces, which belong to a FlexO group.
これらのタイプのインターフェイスは、OTNエッジノードを（a）クライアント機器（例：ルーター）または（b）他のOTNからのハンドオフポイントに接続するために使用されます。ITU-Tの推奨G709.1 [ITU-T_G709.1]は、結合された柔軟なOTN情報構造（FLEXO）インターフェイスを使用して、OTUCN（n> = 1）が転送される柔軟な相互運用可能な短リーチOTNインターフェイスを指定します。フレキソグループ。
intra-domain interfaces:
ドメイン内インターフェイス：
In these cases, the OTUCn is transported using a proprietary (vendor-specific) encapsulation, FEC, etc. It is also possible to transport OTUCn for intra-domain links using FlexO.
これらの場合、OTUCNは、独自の（ベンダー固有の）カプセル化、FECなどを使用して輸送されます。Flexoを使用してドメイン内リンク用にOTUCNを輸送することもできます。
The standard OTUCn signal has the same rate as the ODUCn signal. This implies that the OTUCn signal can only be transported over wavelength groups that have a total capacity of multiples of (approximately) 100 Gbit/s. Modern optical interfaces support a variety of bitrates per wavelength, depending on the reach requirements for the optical path. If the total rate of the ODUk LSPs planned to be carried over an ODUCn link is smaller than n*100 Gbit/s, it is possible to "crunch" the OTUCn, and the unused tributary slots are thus not transmitted. [ITU-T_G709_2020] supports the notion of a reduced-rate OTUCn signal, termed "OTUCn-M". The OTUCn-M signal is derived from the OTUCn signal by retaining all the n instances of overhead (one per OTUC instance) but with only M (M is less than 20*n) OPUCn tributary slots available to carry ODUk LSPs.
標準のOTUCN信号は、ODUCN信号と同じ速度を持っています。これは、OTUCN信号が、（約）100 gbit/sの倍数の総容量を持つ波長基でのみ輸送できることを意味します。最新の光学インターフェイスは、光パスのリーチ要件に応じて、波長あたりのさまざまなビットレートをサポートします。ODUCNリンクの上に運ばれる予定のODUK LSPの総レートがN*100 gBit/sよりも小さい場合、OTUCNを「クランチ」することができ、したがって未使用の支流スロットは送信されません。[ITU-T_G709_2020]は、「OTUCN-M」と呼ばれるレートレートOTUCN信号の概念をサポートしています。OTUCN-M信号は、オーバーヘッドのすべてのnインスタンス（OTUCインスタンスごとに1つ）を保持することにより、OTUCN信号から導出されますが、M（Mは20*n未満）OPUCN支流スロットのみがODUK LSPを運ぶために利用可能です。
The ODUCn signal defined in [ITU-T_G709_2020] can be viewed as being formed by the appropriate interleaving of content from n ODUC signal instances. The ODUC frames have the same structure as a standard ODU in the sense that the frames have the same overhead and payload areas but have a higher rate since their payload area can embed an ODU4 signal.
[ITU-T_G709_2020]で定義されているODUCN信号は、n ODUC信号インスタンスからのコンテンツの適切なインターリービングによって形成されていると見なすことができます。ODUCフレームは、フレームが同じオーバーヘッドとペイロード領域を持っているが、ペイロード領域がODU4信号を埋め込むことができるため、より高いレートを持っているという意味で、標準ODUと同じ構造を持っています。
The ODUCn is a multiplex section ODU signal and is mapped into an OTUCn signal, which provides the regenerator section layer. In some scenarios, the ODUCn and OTUCn signals will be coterminated, i.e., they will have identical source/sink locations (see Figure 1). In Figure 1, the term "OTN Switch" has the same meaning as that used in Section 3 of [RFC7138]. [ITU-T_G709_2020] allows for the ODUCn signal to pass through one or more digital regenerator nodes (shown as nodes B and C in Figure 2), which will terminate the OTUCn layer but will pass the regenerated (but otherwise untouched) ODUCn towards a different OTUCn interface where a fresh OTUCn layer will be initiated. This process is termed as "ODUCn regeneration" in Section 7.1 of [ITU-T_G872]. In this example, the ODUCn is carried by three OTUCn segments.
ODUCNは多重セクションODU信号であり、OTUCN信号にマッピングされ、再生器セクション層を提供します。いくつかのシナリオでは、ODUCNとOTUCN信号は共有されます。つまり、同一のソース/シンクの位置があります（図1を参照）。図1では、「OTNスイッチ」という用語は、[RFC7138]のセクション3で使用されているものと同じ意味を持っています。[ITU-T_G709_2020]により、ODUCN信号は1つまたは複数のデジタル再生器ノード（図2でノードBおよびCとして表示）を通過できます。新鮮なOTUCN層が開始される異なるOTUCNインターフェイス。このプロセスは、[ITU-T_G872]のセクション7.1で「ODUCN再生」と呼ばれます。この例では、ODUCNは3つのOTUCNセグメントによって運ばれます。
Specifically, the OPUCn signal flows through these regenerators unchanged. That is, the set of client signals, their TPNs, and tributary-slot allocations remains unchanged.
具体的には、OPUCN信号はこれらの再生器を介して変化しません。つまり、クライアント信号、TPN、および支流のスロット割り当てのセットは、変更されていません。
+--------+ +--------+
| +-----------+ |
| OTN |-----------| OTN |
| Switch +-----------+ Switch |
| A | | B |
| +-----------+ |
+--------+ +--------+
<--------ODUCn------->
<-------OTUCn------>
Figure 1: ODUCn Signal
図1：ODUCN信号
+---------+ +--------+ +--------+ +--------+
| +--------+ | | +----------+ |
| OTN |--------| OTN | | OTN |----------| OTN |
| Switch +--------+ Regen +--------+ Regen +----------+ Switch |
| A | | B | | C | | D |
| +--------+ | | +----------+ |
+---------+ +--------+ +--------+ +--------+
<-------------------------ODUCn-------------------------->
<---------------><-----------------><------------------>
OTUCn OTUCn OTUCn
Figure 2: ODUCn Signal - Multi-Hop
図2：ODUCN信号 - マルチホップ
[ITU-T_G709_2012] introduced the support for 1.25 Gbit/s granular tributary slots in OPU2, OPU3, and OPU4 signals. [ITU-T_G709_2020] defined the OPUC with a 5 Gbit/s tributary slot granularity. This means that the ODUCn signal has 20*n tributary slots (of 5 Gbit/s capacity). The range of tributary port number (TPN) is 10*n instead of 20*n, which restricts the maximum client signals that could be carried over one single ODUC1.
[ITU-T_G709_2012]は、OPU2、OPU3、およびOPU4シグナルに1.25 GBIT/S粒状支流スロットのサポートを導入しました。[ITU-T_G709_2020]は、5 gbit/sの支流スロット粒度でOPUCを定義しました。これは、ODUCN信号に20*nの支流スロット（5 gbit/s容量）があることを意味します。支流ポート番号（TPN）の範囲は20*nの代わりに10*nです。これは、1つのODUC1に搭載できる最大クライアント信号を制限します。
As mentioned above, the OPUCn signal has 20*n tributary slots (TSs) (each 5 Gbit/s). The OPUCn MSI field has a fixed length of 40*n bytes and indicates the availability and occupation of each TS. Two bytes are used for each of the 20*n tributary slots, and each such information structure has the following format (see Section 20.4.1 of [ITU-T_G709_2020]):
上記のように、OPUCN信号には20*n支流スロット（TSS）（それぞれ5 gbit/s）があります。OPUCN MSIフィールドの固定長は40*nバイトで、各TSの可用性と占有率を示します。20*nの支流スロットのそれぞれに2つのバイトが使用され、そのような情報構造には次の形式があります（[ITU-T_G709_2020]のセクション20.4.1を参照）：
* The TS availability bit indicates if the tributary slot is available or unavailable.
* TSの可用性ビットは、支流スロットが利用可能かどうかを示します。
* The TS occupation bit indicates if the tributary slot is allocated or unallocated.
* TSの職業ビットは、支流スロットが割り当てられているのか未割り当てされているかを示します。
* The tributary port number (14 bits) indicates the port number of the client signal that is being carried in this specific TS. A flexible assignment of tributary port to tributary slots is possible. Numbering of tributary ports is from 1 to 10*n.
* 支流ポート番号（14ビット）は、この特定のTSで運ばれているクライアント信号のポート番号を示します。支流港の支流スロットへの柔軟な割り当てが可能です。支流ポートの番号付けは1〜10*nです。
The concatenation of the OPUCn payload type (PT) and the MSI field is carried over the overhead byte designated as PSI in Figure 15-6 of [ITU-T_G709_2020].
OPUCNペイロードタイプ（PT）とMSIフィールドの連結は、[ITU-T_G709_2020]の図15-6でPSIとして指定されたオーバーヘッドバイトの上に運ばれます。
The approach taken by the ITU-T to map non-OTN client signals to the appropriate ODU containers is as follows:
ITU-Tが取ったアプローチは、非OTNクライアント信号を適切なODUコンテナにマッピングすることです。
* All client signals are mapped into an ODUj or ODUk (e.g., ODUflex) as specified in Section 17 of [ITU-T_G709_2020].
* すべてのクライアント信号は、[ITU-T_G709_2020]のセクション17で指定されているように、ODUJまたはODUK（例：OduFlex）にマッピングされます。
* The terms "ODUj" and "ODUk" are used in a multiplexing scenario, with ODUj being a low-order ODU that is multiplexed into ODUk, a high-order ODU. As Figure 3 illustrates, the ODUCn is also a high-order ODU into which other ODUs can be multiplexed. The ODUCn itself cannot be multiplexed into any higher-rate ODU signal; it is defined to be a section-level signal.
* 「Oduj」と「Oduk」という用語は、多重化シナリオで使用され、Odujは高次のODUであるOdukに多重化されたODUです。図3が示すように、ODUCNは他のODUを多重化できる高次ODUでもあります。ODUCN自体は、高レートのODU信号に多重化することはできません。セクションレベルの信号であると定義されています。
* ODUflex signals are low-order signals only. If the ODUflex entities have rates of 100 Gbit/s or less, they can be transported over either an ODUk (k=1..4) or an ODUCn. For ODUflex connections with rates greater than 100 Gbit/s, ODUCn is required.
* oduflex信号は、低次信号のみです。Oduflexエンティティのレートが100 gbit/s以下の場合、Oduk（k = 1..4）またはOducnのいずれかで輸送できます。100 gbit/sを超えるレートのOduFlex接続の場合、ODUCNが必要です。
* ODU Virtual Concatenation (VCAT) has been deprecated. This simplifies the network and the supporting hardware since multiple different mappings for the same client are no longer necessary. Note that legacy implementations that transported sub-100 Gbit/s clients using ODU VCAT shall continue to be supported.
* ODU仮想連結（VCAT）は非推奨されています。これにより、同じクライアントの複数の異なるマッピングが必要ないため、ネットワークとサポートハードウェアが簡素化されます。ODU VCATを使用してサブ100 GBIT/Sクライアントを輸送したレガシーの実装は引き続きサポートされていることに注意してください。
Clients (e.g., SONET/SDH and Ethernet)
| | | | | |
| | | | | |
| | | | | |
+---+---+---+----+ | | |
| OPUj | | | |
+----------------+ | | |
| ODUj | | | |
+----------------+----------------------+---+---+----------+
| |
| OPUk |
+----------------------------------------------------------+
| |
| ODUk k in {0,1,2,2e,3,4,flex}|
+-------------------------+-----+--------------------------+
| | | |
| OTUk, OTUk-SC, OTUk-V | | OPUCn |
+-------------------------+ +--------------------------+
| |
| ODUCn |
+--------------------------+
| |
| OTUCn |
+--------------------------+
Figure 3: Digital Structure of OTN Interfaces (from Figure 6-1 of [ITU-T_G709_2020])
図3：OTNインターフェイスのデジタル構造（[ITU-T_G709_2020]の図6-1から）
Section 3 of [RFC7138] describes how to represent G.709 OTUk/ODUk with TE links in GMPLS. In the same manner, OTUCn links can also be represented as TE links. Figure 4 provides an illustration of a one-hop OTUCn TE link.
[RFC7138]のセクション3では、G.709 OTUK/ODUKをGMPLSのTEリンクを使用して表現する方法について説明します。同様に、OTUCNリンクをTEリンクとして表すこともできます。図4に、1ホップのOTUCN TEリンクのイラストを示します。
+----------+ +---------+
| OTN | | OTN |
| Switch +-------------------+ Switch |
| A | | B |
+----------+ +---------+
|<---------OTUCn Link---------->|
|<---------TE Link------------->|
Figure 4: One-Hop OTUCn TE Link
図4：One-Hop Otucn Teリンク
It is possible to create TE links that span more than one hop by creating forward adjacencies (FAs) between non-adjacent nodes (see Figure 5). In Figure 5, nodes B and C are performing the ODUCn regeneration function described in Section 7.1 of [ITU-T_G872] and are not electrically switching the ODUCn signal from one interface to another. As in the one-hop case, multi-hop TE links advertise the ODU switching capability.
非隣接ノード間でフォワード隣接（FA）を作成することにより、複数のホップにまたがるTEリンクを作成することができます（図5を参照）。図5では、ノードBとCは[ITU-T_G872]のセクション7.1で説明されているODUCN再生関数を実行しており、ODUCN信号をあるインターフェイスから別のインターフェースに電気的に切り替えていません。ワンホップの場合と同様に、マルチホップTEリンクはODUスイッチング機能を宣伝しています。
+--------+ +--------+ +--------+ +---------+
| OTN | | OTN | | OTN | | OTN |
| Switch |<------->| Regen |<-------->| Regen |<------->| Switch |
| A | OTUCn | B | OTUCn | C | OTUCn | D |
+--------+ Link +--------+ Link +--------+ Link +---------+
|<-------------------- ODUCn Link -------------------->|
|<---------------------- TE Link --------------------->|
Figure 5: Multi-Hop ODUCn TE Link
図5：マルチホップODUCN TEリンク
The two endpoints of a TE link are configured with the supported resource information (which may include whether the TE link is supported by an ODUCn, ODUk, or OTUk), as well as the link attribute information (e.g., slot granularity and list of available tributary slot).
TEリンクの2つのエンドポイントは、サポートされているリソース情報（TEリンクがODUCN、ODUK、またはOTUKによってサポートされているかどうかが含まれる場合があります）とリンク属性情報（スロット粒度と利用可能なリストのリストで構成されています。支流スロット）。
Once the ODUCn TE link is configured, the GMPLS mechanisms defined in [RFC7139] can be reused to set up ODUk/ODUflex LSPs with no changes. As the resource on the ODUCn link that can be seen by the ODUk/ ODUflex client signal is a set of 5 Gbit/s slots, the label defined in [RFC7139] is able to accommodate the requirement of the setup of an ODUk/ODUflex client signal over an ODUCn link. In [RFC7139], the OTN-TDM GENERALIZED_LABEL object is used to indicate how the lower-order (LO) ODUj signal is multiplexed into the higher-order (HO) ODUk link. In a similar manner, the OTN-TDM GENERALIZED_LABEL object is used to indicate how the ODUk signal is multiplexed into the ODUCn link. The ODUk signal type is indicated by Traffic Parameters. The IF_ID RSVP_HOP object provides a pointer to the interface associated with TE link; therefore, the two nodes terminating the TE link know (by internal/local configuration) the attributes of the ODUCn TE Link.
ODUCN TEリンクが構成されると、[RFC7139]で定義されているGMPLSメカニズムを再利用して、変更なしでOduk/Oduflex LSPをセットアップできます。ODUK/ODUFLEXクライアント信号で見ることができるODUCNリンクのリソースは5 GBIT/Sスロットのセットであるため、[RFC7139]で定義されたラベルはODUK/Oduflexクライアントのセットアップの要件に対応できます。ODUCNリンク上の信号。[RFC7139]では、OTN-TDM Generalized_Labelオブジェクトを使用して、低次（LO）ODUJ信号が高次（HO）ODUKリンクにどのように多重化されるかを示します。同様に、OTN-TDM Generalized_Labelオブジェクトを使用して、ODUK信号がODUCNリンクにどのように多重化されているかを示します。ODUK信号タイプは、トラフィックパラメーターで示されています。IF_ID RSVP_HOPオブジェクトは、TEリンクに関連付けられたインターフェイスへのポインターを提供します。したがって、TEリンクを終了する2つのノードは、（内部/ローカル構成によって）ODUCN TEリンクの属性を知っています。
The TPN defined in [ITU-T_G709_2020] (where it is referred to as "tributary port #") for an ODUCn link has 14 bits while this field in [RFC7139] only has 12 bits, so some extension work will eventually be needed. Given that a 12-bit TPN field can support ODUCn links with up to n=400 (i.e., 40 Tbit/s links), this need is not urgent.
ODUCNリンクの[ITU-T_G709_2020]（「支流ポート＃」と呼ばれる）で定義されているTPNには14ビットがありますが、[RFC7139]のこのフィールドには12ビットしかないため、最終的には拡張作業が必要になります。12ビットTPNフィールドがn = 400までのODUCNリンク（つまり、40 Tbit/sリンク）をサポートできることを考えると、このニーズは緊急ではありません。
The example in Figure 6 illustrates the label format defined in [RFC7139] for multiplexing ODU4 onto ODUC10. One ODUC10 has 200 slots (each 5 Gbit/s), and twenty of them are allocated to the ODU4. With this label encoding, only 20 out of the 200 bits mask are non-zero, which is very inefficient. The inefficiency grows for larger values of "n", and an optimized label format may be desirable.
図6の例は、ODU4をODUC10に多重化するために[RFC7139]で定義されているラベル形式を示しています。1つのODUC10には200のスロット（それぞれ5 gbit/s）があり、そのうち20個がODU4に割り当てられています。このラベルエンコードでは、200ビットマスクのうち20個のみがゼロではなく、非常に非効率的です。非効率性は「n」の値が大きくなり、最適化されたラベル形式が望ましい場合があります。
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 = 3 | Reserved | Length = 200 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Padding Bits(0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Label Format
図6：ラベル形式
For routing, it is deemed that no extension to the current mechanisms defined in [RFC7138] is needed.
ルーティングには、[RFC7138]で定義されている現在のメカニズムの拡張は必要ないと考えられています。
The ODUCn link, which is the lowest layer of the ODU multiplexing hierarchy involving multiple ODU layers, is assumed to have been already configured when GMPLS is used to set up ODUk over ODUCn; therefore, the resources that need to be advertised are the resources that are exposed by this ODUCn link and the ODUk multiplexing hierarchy on it. The 5 Gbit/s OPUCn time slots do not need to be advertised, while the 1.25 Gbit/s and 2.5 Gbit/s OPUk time slots need to be advertised using the mechanisms already defined in [RFC7138].
複数のODU層を含むODU多重階層の最低層であるODUCNリンクは、GMPLSを使用してODUCN上にODUKをセットアップするときにすでに構成されていると想定されています。したがって、宣伝する必要があるリソースは、このODUCNリンクとその上のODUK多重階層によって公開されるリソースです。5 gbit/s opucnタイムスロットを宣伝する必要はありませんが、1.25 gbit/sおよび2.5 gbit/s opukタイムスロットは、[RFC7138]で既に定義されているメカニズムを使用して宣伝する必要があります。
Since there is a 1:1 correspondence between the ODUCn and the OTUCn signal, there is no need to explicitly define a new value to represent the ODUCn signal type in the OSPF-TE routing protocol.
ODUCNとOTUCN信号の間には1：1の対応があるため、OSPF-TEルーティングプロトコルのODUCN信号タイプを表す新しい値を明示的に定義する必要はありません。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document analyzes the applicability of protocol extensions in [RFC7138] and [RFC7139] for use in the 2020 version of ITU-T Recommendation G.709 [ITU-T_G709_2020] and finds that no new extensions are needed. Therefore, this document introduces no new security considerations to the existing signaling and routing protocols beyond those already described in [RFC7138] and [RFC7139]. Please refer to [RFC7138] and [RFC7139] for further details of the specific security measures. Additionally, [RFC5920] addresses the security aspects that are relevant in the context of GMPLS.
このドキュメントは、2020バージョンのITU-T推奨G.709 [ITU-T_G709_2020]で使用するための[RFC7138]および[RFC7139]のプロトコル拡張の適用性を分析し、新しい拡張機能が必要ないことがわかります。したがって、このドキュメントでは、[RFC7138]および[RFC7139]で既に説明されているものを超えて、既存のシグナリングおよびルーティングプロトコルに新しいセキュリティ上の考慮事項を導入しません。特定のセキュリティ対策の詳細については、[RFC7138]および[RFC7139]を参照してください。さらに、[RFC5920]は、GMPLSのコンテキストに関連するセキュリティの側面に対処します。
[ITU-T_G709_2020]
ITU-T, "Interfaces for the optical transport network",
ITU-T Recommendation G.709, June 2020.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>.
[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, DOI 10.17487/RFC7138, March 2014,
<https://www.rfc-editor.org/info/rfc7138>.
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and K. Pithewan, "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139,
DOI 10.17487/RFC7139, March 2014,
<https://www.rfc-editor.org/info/rfc7139>.
[ITU-T_G709.1]
ITU-T, "Flexible OTN short-reach interfaces", ITU-T
Recommendation G.709.1, June 2018.
[ITU-T_G709_2012]
ITU-T, "Interfaces for the optical transport network",
ITU-T Recommendation G.709, February 2012.
[ITU-T_G709_2016]
ITU-T, "Interfaces for the optical transport network",
ITU-T Recommendation G.709, June 2016.
[ITU-T_G872]
ITU-T, "Architecture of optical transport networks", ITU-T
Recommendation G.872, December 2019.
[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,
DOI 10.17487/RFC7062, November 2013,
<https://www.rfc-editor.org/info/rfc7062>.
[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, DOI 10.17487/RFC7096, January
2014, <https://www.rfc-editor.org/info/rfc7096>.
As noted in Section 4.2, the GMPLS TPN field defined in Section 6.1 of [RFC7139] is only 12 bits, whereas an ODUCn link could require up to 14 bits. Although the need is not urgent, future work could extend the TPN field in GMPLS to use the Reserved bits immediately adjacent. This would need to be done in a backward-compatible way.
セクション4.2で述べたように、[RFC7139]のセクション6.1で定義されているGMPLS TPNフィールドは12ビットのみですが、ODUCNリンクは最大14ビットを必要とする可能性があります。ニーズは緊急ではありませんが、将来の作業はGMPLSのTPNフィールドを拡張して、すぐに隣接する予約ビットを使用することができます。これは、後方互換性のある方法で行う必要があります。
Section 4.2 further notes that the current encoding of GMPLS labels can be inefficient for larger values of n in ODUCn. Future work might examine a more compact, yet generalized, label encoding to address this issue should it be felt, after analysis of the operational aspects, that the current encoding is causing problems. Introduction of a new label encoding would need to be done using a new pairing of LSP encoding type and Generalized Payload Identifier (G-PID) to ensure correct interoperability.
セクション4.2さらに、GMPLSラベルの現在のエンコードは、ODUCNのnのより大きな値に対して非効率的である可能性があることを指摘しています。将来の作業では、運用上の側面の分析後、現在のエンコードが問題を引き起こしていると感じた場合、この問題に対処するために、よりコンパクトでありながら一般化されたラベルエンコードを調べることができます。正しい相互運用性を確保するには、新しいラベルエンコーディングの導入を行う必要があります。
Iftekhar Hussain
Infinera Corp
Sunnyvale, CA
United States of America
Email: IHussain@infinera.com
Daniele Ceccarelli
Ericsson
Email: daniele.ceccarelli@ericsson.com
Rajan Rao
Infinera Corp
Sunnyvale,
United States of America
Email: rrao@infinera.com
Fatai Zhang
Huawei
Email: zhangfatai@huawei.com
Italo Busi
Huawei
Email: italo.busi@huawei.com
Dieter Beller
Nokia
Email: Dieter.Beller@nokia.com
Yuanbin Zhang
ZTE
Beijing
Email: zhang.yuanbin@zte.com.cn
Zafar Ali
Cisco Systems
Email: zali@cisco.com
Daniel King
Email: d.king@lancaster.ac.uk
Manoj Kumar
Cisco Systems
Email: manojk2@cisco.com
Antonello Bonfanti
Cisco Systems
Email: abonfant@cisco.com
Yuji Tochio
Fujitsu
Email: tochio@fujitsu.com
Qilei Wang (editor)
ZTE Corporation
Nanjing
China
Email: wang.qilei@zte.com.cn
Radha Valiveti (editor)
Infinera Corp
Sunnyvale, CA
United States of America
Email: rvaliveti@infinera.com
Haomian Zheng (editor)
Huawei
China
Email: zhenghaomian@huawei.com
Huub van Helvoort
Hai Gaoming BV
Almere
Netherlands
Email: huubatwork@gmail.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com