[要約] RFC 7096は、G.709v3光トランスポートネットワーク（OTN）に対する既存のGMPLSエンコーディングの評価に関するものです。このRFCの目的は、既存のエンコーディングがG.709v3 OTNに適しているかどうかを評価することです。
Internet Engineering Task Force (IETF) S. Belotti, Ed.
Request for Comments: 7096 P. Grandi
Category: Informational Alcatel-Lucent
ISSN: 2070-1721 D. Ceccarelli, Ed.
D. Caviglia
Ericsson
F. Zhang
D. Li
Huawei Technologies
January 2014
Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)
G.709v3光トランスポートネットワーク（OTN）に対する既存のGMPLSエンコーディングの評価
Abstract
概要
ITU-T recommendation G.709-2012 has introduced new fixed and flexible Optical channel Data Unit (ODU) containers in Optical Transport Networks (OTNs).
ITU-T勧告G.709-2012では、光トランスポートネットワーク（OTN）に新しい固定された柔軟な光チャネルデータユニット（ODU）コンテナーが導入されました。
This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 OTNs.
このドキュメントでは、G.709 OTNに対する既存の汎用マルチプロトコルラベルスイッチング（GMPLS）ルーティングおよびシグナリングプロトコルの評価について説明します。
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/rfc7096.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7096で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. G.709 Mapping and Multiplexing Capabilities .....................4
3. Tributary Slot Granularity ......................................6
3.1. Data-Plane Considerations ..................................7
3.1.1. Payload Type and TS Granularity Relationship ........7
3.1.2. Fallback Procedure ..................................8
3.2. Control-Plane Considerations ...............................9
4. Tributary Port Number ..........................................13
5. Signal Type ....................................................13
6. Bit Rate and Tolerance .........................................15
7. Unreserved Resources ...........................................15
8. Maximum LSP Bandwidth ..........................................15
9. Distinction between Terminating and Switching Capabilities .....16
10. Priority Support ..............................................18
11. Multi-stage Multiplexing ......................................18
12. Generalized Label .............................................19
13. Security Considerations .......................................19
14. Contributors ..................................................20
15. Acknowledgements ..............................................20
16. References ....................................................20
16.1. Normative References .....................................20
16.2. Informative References ...................................21
GMPLS routing [RFC4203] [RFC5307] and signaling [RFC3473] [RFC4328] provide the mechanisms for basic GMPLS control of Optical Transport Networks (OTNs) based on the 2001 revision of the G.709 specification [G.709-2001]. The 2012 revision of the G.709 specification [G.709-2012] includes new OTN features that are not supported by GMPLS.
GMPLSルーティング[RFC4203] [RFC5307]およびシグナリング[RFC3473] [RFC4328]は、G.709仕様の2001年改訂[G.709-2001]に基づく光トランスポートネットワーク（OTN）の基本GMPLS制御のメカニズムを提供します。 G.709仕様の2012年リビジョン[G.709-2012]には、GMPLSでサポートされていない新しいOTN機能が含まれています。
This document provides an evaluation of exiting GMPLS signaling and routing protocols against G.709 requirements. Background information and a framework for the GMPLS protocol extensions needed to support G.709 is provided in [RFC7062]. Specific routing and signaling extensions defined in [OTN-OSPF] and [OTN-RSVP] specifically address the gaps identified in this document.
このドキュメントでは、G.709要件に対する既存のGMPLSシグナリングおよびルーティングプロトコルの評価について説明します。 G.709をサポートするために必要なGMPLSプロトコル拡張の背景情報とフレームワークは、[RFC7062]で提供されています。 [OTN-OSPF]および[OTN-RSVP]で定義された特定のルーティングおよびシグナリング拡張は、このドキュメントで識別されたギャップに特に対処します。
The digital OTN-layered structure is comprised of the digital path layer (ODU) and the digital section layer (OTU). An OTU (Optical channel Transport Unit) section layer supports one ODU path layer as a client and provides monitoring capability for the Optical Channel (OCh), which is the optical path carrying the digital OTN structure. An ODU path layer may transport a heterogeneous assembly of ODU clients. Some types of ODUs (i.e., ODU1, ODU2, ODU3, and ODU4) may assume either a client or server role within the context of a particular networking domain. The terms ODU1, ODU2, ODU3, ODU4, and flexible ODU (ODUflex) are explained in G.709. G.872 [G.872] provides two tables defining mapping and multiplexing capabilities of OTNs, which are reported below.
デジタルOTN層構造は、デジタルパス層（ODU）とデジタルセクション層（OTU）で構成されます。 OTU（Optical Channel Transport Unit）セクション層は、クライアントとして1つのODUパス層をサポートし、デジタルOTN構造を伝送する光パスである光チャネル（OCh）の監視機能を提供します。 ODUパス層は、ODUクライアントの異種混合アセンブリをトランスポートできます。一部のタイプのODU（つまり、ODU1、ODU2、ODU3、およびODU4）は、特定のネットワークドメインのコンテキスト内でクライアントまたはサーバーの役割を担う場合があります。 ODU1、ODU2、ODU3、ODU4、およびフレキシブルODU（ODUflex）という用語は、G.709で説明されています。 G.872 [G.872]は、OTNのマッピングおよび多重化機能を定義する2つのテーブルを提供します。
+--------------------+--------------------+
| ODU client | OTU server |
+--------------------+--------------------+
| ODU0 | - |
+--------------------+--------------------+
| ODU1 | OTU 1 |
+--------------------+--------------------+
| ODU2 | OTU 2 |
+--------------------+--------------------+
| ODU2e | - |
+--------------------+--------------------+
| ODU3 | OTU 3 |
+--------------------+--------------------+
| ODU4 | OTU 4 |
+--------------------+--------------------+
| ODUflex | - |
+--------------------+--------------------+
Figure 1: OTN Mapping Capability
図1：OTNマッピング機能
+=================================+=========================+
| ODU client | ODU server |
+---------------------------------+-------------------------+
| 1.25 Gbit/s client | |
+---------------------------------+ ODU0 |
| - | |
+=================================+=========================+
| 2.5 Gbit/s client | |
+---------------------------------+ ODU1 |
| ODU0 | |
+=================================+=========================+
| 10 Gbit/s client | |
+---------------------------------+ ODU2 |
| ODU0,ODU1,ODUflex | |
+=================================+=========================+
| 10.3125 Gbit/s client | |
+---------------------------------+ ODU2e |
| - | |
+=================================+=========================+
| 40 Gbit/s client | |
+---------------------------------+ ODU3 |
| ODU0,ODU1,ODU2,ODU2e,ODUflex | |
+=================================+=========================+
| 100 Gbit/s client | |
+---------------------------------+ ODU4 |
|ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| |
+=================================+=========================+
|CBR* clients from greater than | |
|2.5 Gbit/s to 100 Gbit/s: or | |
|GFP-F** mapped packet clients | ODUflex |
|from 1.25 Gbit/s to 100 Gbit/s. | |
+---------------------------------+ |
| - | |
+=================================+=========================+
(*) - Constant Bit Rate
(**) - Generic Framing Procedure - Framed (GFP-F)
Figure 2: OTN Multiplexing Capability
図2：OTN多重化機能
In the following, the terms Optical channel Data Unit-j (ODUj) and Optical channel Data Unit-k (ODUk) are used in a multiplexing scenario to identify the lower order signal (ODUj) and the higher order signal (ODUk). How an ODUk connection service is transported within an operator network is governed by operator policy. For example, the ODUk connection service might be transported over an ODUk path over an Optical channel Transport Unit-k (OTUk) section, with the same path and section rates as that of the connection service (see Figure 1). In this case, an entire lambda of capacity is consumed in transporting the ODUk connection service. On the other hand, the operator might exploit different multiplexing capabilities in the network to improve infrastructure efficiencies within any given networking domain. In this case, ODUk multiplexing may be performed prior to transport over various rate ODU servers (as per Figure 2) over associated OTU sections.
以下では、光チャネルデータユニットj（ODUj）および光チャネルデータユニットk（ODUk）という用語を多重化シナリオで使用して、低次信号（ODUj）および高次信号（ODUk）を識別します。 ODUk接続サービスがオペレーター・ネットワーク内でどのように転送されるかは、オペレーター・ポリシーによって管理されています。たとえば、ODUk接続サービスは、光チャネルトランスポートユニットk（OTUk）セクション上のODUkパスを介して、接続サービスと同じパスおよびセクションレートで転送される場合があります（図1を参照）。この場合、容量のラムダ全体がODUk接続サービスの転送に消費されます。一方、オペレーターはネットワーク内のさまざまな多重化機能を利用して、特定のネットワークドメイン内のインフラストラクチャ効率を向上させることができます。この場合、ODUk多重化は、関連するOTUセクションを介して（図2のように）さまざまなレートのODUサーバーで転送する前に実行できます。
From the perspective of multiplexing relationships, a given ODUk may play different roles as it traverses various networking domains.
多重化の関係の観点から、特定のODUkは、さまざまなネットワークドメインを通過するときに、異なる役割を果たす場合があります。
As detailed in [RFC7062], client ODUk connection services can be transported over:
[RFC7062]で詳述されているように、クライアントODUk接続サービスは以下を介して転送できます。
Case A: one or more wavelength subnetworks connected by optical links, or
ケースA：光リンクで接続された1つ以上の波長サブネットワーク、または
Case B: one or more ODU links (having sub-lambda and/or lambda bandwidth granularity), or
ケースB：1つ以上のODUリンク（サブラムダおよび/またはラムダの帯域幅の粒度を持つ）、または
Case C: a mix of ODU links and wavelength subnetworks.
ケースC：ODUリンクと波長サブネットワークの組み合わせ。
This document considers the Traffic Engineering (TE) information needed for ODU path computation and the parameters needed to be signaled for Label Switched Path (LSP) setup.
このドキュメントでは、ODUパスの計算に必要なトラフィックエンジニアリング（TE）の情報と、ラベルスイッチドパス（LSP）のセットアップで信号を送る必要のあるパラメーターについて検討します。
The following sections list and analyze what GMPLS already has and what it is missing with regard to each type of data that needs to be advertised and signaled.
次のセクションでは、アドバタイズおよびシグナリングする必要があるデータの各タイプに関して、GMPLSにすでにあるものと不足しているものをリストして分析します。
G.709 defines two types of Tributary Slot (TS) granularities. This TS granularity is defined per layer, meaning that both ends of a link can select proper TS granularity differently for each supported layer, based on the rules below:
G.709は、2つのタイプのトリビュタリスロット（TS）粒度を定義しています。このTS細分性はレイヤーごとに定義されます。つまり、リンクの両端は、以下のルールに基づいて、サポートされているレイヤーごとに異なる適切なTS細分性を選択できます。
o If both ends of a link are new cards supporting both 1.25 Gbit/s TS and 2.5 Gbit/s TS, then the link will work with 1.25 Gbit/s TS.
o リンクの両端が1.25 Gbit / s TSと2.5 Gbit / s TSの両方をサポートする新しいカードである場合、リンクは1.25 Gbit / s TSで動作します。
o If one end of a link is a new card supporting both the 1.25 Gbit/s and 2.5 Gbit/s TS granularities, and the other end is an old card supporting just the 2.5 Gbit/s TS granularity, the link will work with 2.5 Gbit/s TS granularity.
o リンクの一方の端が1.25 Gbit / sと2.5 Gbit / sの両方のTS細分性をサポートする新しいカードであり、もう一方の端が2.5 Gbit / s TSの細分性のみをサポートする古いカードである場合、リンクは2.5 Gbitで動作します/ s TSの粒度。
As defined in G.709, an ODUk container consists of an Optical channel Payload Unit-k (OPUk) plus a specific ODUk Overhead (OH). OPUk OH information is added to the OPUk information payload to create an OPUk. It includes information to support the adaptation of client signals. Within the OPUk overhead, there is the payload structure identifier (PSI) that includes the payload type (PT). The PT is used to indicate the composition of the OPUk signal. When an ODUj signal is multiplexed into an ODUk, the ODUj signal is first extended with the frame alignment overhead and then mapped into an Optical channel Data Tributary Unit (ODTU). Two different types of ODTUs are defined:
G.709で定義されているように、ODUkコンテナは、光チャネルペイロードユニットk（OPUk）と特定のODUkオーバーヘッド（OH）で構成されています。 OPUk OH情報がOPUk情報ペイロードに追加され、OPUkが作成されます。クライアント信号の適応をサポートするための情報が含まれています。 OPUkオーバーヘッド内には、ペイロードタイプ（PT）を含むペイロード構造識別子（PSI）があります。 PTは、OPUk信号の構成を示すために使用されます。 ODUj信号がODUkに多重化されると、ODUj信号は最初にフレームアライメントオーバーヘッドで拡張され、次に光チャネルデータトリビュタリユニット（ODTU）にマッピングされます。 2つの異なるタイプのODTUが定義されています。
o ODTUjk ((j,k) = {(0,1), (1,2), (1,3), (2,3)}; ODTU01, ODTU12, ODTU13, and ODTU23) in which an ODUj signal is mapped via the Asynchronous Mapping Procedure (AMP), as defined in Section 19.5 of [G.709-2012].
o ODTUjk（（j、k）= {（0,1）、（1,2）、（1,3）、（2,3）}; ODTU01、ODTU12、ODTU13、ODTU23）ODUj信号がマッピングされている[G.709-2012]のセクション19.5で定義されているように、非同期マッピング手順（AMP）を介して。
o ODTUk.ts ((k,ts) = (2,1..8), (3,1..32), (4,1..80)) in which a lower order ODU (ODU0, ODU1, ODU2, ODU2e, ODU3, and ODUflex) signal is mapped via the Generic Mapping Procedure (GMP), as defined in Section 19.6 of [G.709-2012].
o ODTUk.ts（（k、ts）=（2,1..8）、（3,1..32）、（4,1..80）））より低い次数のODU（ODU0、ODU1、ODU2、 [G.709-2012]のセクション19.6で定義されているように、ODU2e、ODU3、およびODUflex）信号はGeneric Mapping Procedure（GMP）を介してマッピングされます。
G.709 also introduces a logical entity, called Optical channel Data Tributary Unit Group (ODTUGk), characterizing the multiplexing of the various ODTU. The ODTUGk is then mapped into OPUk. Optical channel Data Tributary Unit j into k (ODTUjk) and Optical channel Data Tributary Unit k with ts tributary slots (ODTUk.ts) are directly time-division multiplexed into the tributary slots of an OH OPUk.
G.709では、さまざまなODTUの多重化を特徴付ける、光チャネルデータトリビュタリユニットグループ（ODTUGk）と呼ばれる論理エンティティも導入されています。次に、ODTUGkがOPUkにマッピングされます。光チャネルデータトリビュタリユニットjからk（ODTUjk）と光チャネルデータトリビュタリユニットkとtsトリビュタリスロット（ODTUk.ts）は、OH OPUkのトリビュタリスロットに直接時分割多重化されます。
When PT is assuming values 0x20 or 0x21, together with OPUk type (k=1, 2, 3, 4), it is used to discriminate two different ODU multiplex structures for ODTUGx:
PTが値0x20または0x21とOPUkタイプ（k = 1、2、3、4）を想定している場合、ODTUGxの2つの異なるODU多重化構造を区別するために使用されます。
o Value 0x20: supporting ODTUjk only
o 値0x20：ODTUjkのみをサポート
o Value 0x21: supporting ODTUk.ts or ODTUk.ts and ODTUjk
o 値0x21：ODTUk.tsまたはODTUk.tsおよびODTUjkのサポート
The distinction is needed for OPUk with k=2 or 3 since OPU2 and OPU3 are able to support both the different ODU multiplex structures. For OPU4 and OPU1, only one type of ODTUG is supported: ODTUG4 with PT=0x21 and ODTUG1 with PT=0x20 (see Figure 6). The relationship between PT and TS granularity is due to the fact that the two different ODTUGk types discriminated by PT and OPUk are characterized by two different TS granularities of the related OPUk, the former at 2.5 Gbit/s and the latter at 1.25 Gbit/s.
OPU2とOPU3は異なるODU多重化構造の両方をサポートできるため、k = 2または3のOPUkには区別が必要です。 OPU4およびOPU1の場合、サポートされるODTUGのタイプは、PT = 0x21のODTUG4とPT = 0x20のODTUG1のみです（図6を参照）。 PTとTSの粒度間の関係は、PTとOPUkによって区別される2つの異なるODTUGkタイプが、関連するOPUkの2つの異なるTS粒度によって特徴付けられるという事実によるもので、前者は2.5 Gbit / s、後者は1.25 Gbit / sです。 。
In order to complete the picture, in the PSI OH, there is also the Multiplex Structure Identifier (MSI) that provides the information on which tributary slots of the different ODTUjk or ODTUk.ts are mapped into the related OPUk. The following figure shows how the client traffic is multiplexed till the OPUk layer.
画像を完成させるために、PSI OHには、異なるODTUjkまたはODTUk.tsのどの支流スロットが関連するOPUkにマッピングされているかに関する情報を提供する多重構造識別子（MSI）もあります。次の図は、クライアントトラフィックがOPUkレイヤーまでどのように多重化されるかを示しています。
+--------+ +------------+
+----+ | !------| ODTUjk |-----Client
| | | ODTUGk | +-----.------+
| |-----| PT=0x21| .
| | | | +-----.------+
| | | |------| ODTUk.ts |-----Client
|OPUk| +--------+ +------------+
| |
| | +--------+ +------------+
| | | |------| ODTUjk |-----Client
| |-----| | +-----.------+
+----+ | ODTUGk | .
| PT=0x20| +-----.------+
| |------| ODTUjk |-----Client
+--------+ +------------+
Figure 3: OTN Client Multiplexing
図3：OTNクライアントの多重化
G.798 [G.798] describes the so-called PT=0x21-to-PT=0x20 interworking process that explains how two nodes with interfaces that have different payload types and, hence, different TS granularity (1.25 Gbit/s vs. 2.5 Gbit/s), can be coordinated to permit the equipment with 1.25 Gbit/s TS granularity to adapt the TS allocation according to the different TS granularity (2.5 Gbit/s) of a neighbor.
G.798 [G.798]では、いわゆるPT = 0x21-to-PT = 0x20インターワーキングプロセスについて説明します。このプロセスでは、ペイロードタイプが異なり、したがってTS粒度が異なります（1.25 Gbit / s vs. 2.5 Gbit / s）を調整して、1.25 Gbit / sのTS細分性を持つ機器が、ネイバーの異なるTS細分性（2.5 Gbit / s）に従ってTS割り当てを適応できるようにすることができます。
Therefore, in order to let the Network Element (NE) change TS granularity accordingly to the neighbor requirements, the AUTOpayloadtype [G.798] needs to be set. When both the neighbors (link or trail) have been configured as structured, the payload type received in the overhead is compared to the transmitted PT. If they are different and the transmitted one is PT=0x21, the node must fall back to PT=0x20. In this case, the fallback process makes the system self-consistent, and the only reason for signaling the TS granularity is to provide the correct label (i.e., the label for PT=0x21 has twice the TS number of PT=0x20). On the other side, if the AUTOpayloadtype is not configured, the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) consequent actions need to be defined in case of a TS mismatch.
したがって、ネットワーク要素（NE）がネイバー要件に応じてTS粒度を変更できるようにするには、AUTOpayloadtype [G.798]を設定する必要があります。両方のネイバー（リンクまたはトレイル）が構造化されているように構成されている場合、オーバーヘッドで受信されたペイロードタイプが送信されたPTと比較されます。それらが異なり、送信されたものがPT = 0x21である場合、ノードはPT = 0x20にフォールバックする必要があります。この場合、フォールバックプロセスによってシステムの一貫性が保たれ、TS粒度を通知する唯一の理由は、正しいラベルを提供することです（つまり、PT = 0x21のラベルには、PT = 0x20のTS番号の2倍があります）。一方、AUTOpayloadtypeが構成されていない場合、TSが一致しない場合に、リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE）の結果として生じるアクションを定義する必要があります。
When setting up an ODUj over an ODUk, it is possible to identify two types of TS granularity (TSG): the server and the client. The server TS granularity is used to map an end-to-end ODUj onto a server ODUk LSP or links. This parameter cannot be influenced in any way from the ODUj LSP: the ODUj LSP will be mapped on tributary slots available on the different links / ODUk LSPs. When setting up an ODUj at a given rate, the fact that it is carried over a path composed by links / Forwarding Adjacencies (FAs) structured with 1.25 Gbit/s or 2.5 Gbit/s TS granularity is completely transparent to the end-to-end ODUj.
ODUkを介してODUjをセットアップする場合、サーバーとクライアントの2つのタイプのTS細分性（TSG）を識別することができます。サーバーTS細分性は、エンドツーエンドODUjをサーバーODUk LSPまたはリンクにマップするために使用されます。このパラメーターは、ODUj LSPの影響を受けません。ODUjLSPは、さまざまなリンク/ ODUk LSPで使用可能な支流スロットにマッピングされます。特定のレートでODUjを設定する場合、それが1.25 Gbit / sまたは2.5 Gbit / sのTS粒度で構成されたリンク/転送隣接（FA）で構成されるパスを介して伝送されるという事実は、エンドツーエンドに対して完全に透過的です。 ODUjを終了します。
The client TS granularity information is one of the parameters needed to correctly select the adaptation towards the client layers at the end nodes, and this is the only thing that the ODUj has to guarantee.
クライアントTS粒度情報は、エンドノードのクライアントレイヤーへの適応を正しく選択するために必要なパラメーターの1つであり、ODUjが保証する必要があるのはこれだけです。
In Figure 4, an example of client and server TS granularity utilization in a scenario with mixed OTN [RFC4328] and OTN interfaces [G.709-2012] is shown.
図4に、OTN [RFC4328]とOTNインターフェイス[G.709-2012]が混在するシナリオでのクライアントとサーバーのTS粒度の使用例を示します。
ODU1-LSP
.........................................
TSG-C| |TSG-C
1.25| ODU2-H-LSP |1.25 Gbit/s
Gbit/s+------------X--------------------------+
| TSG-S| |TSG-S
| 2.5| |2.5 Gbit/s
| Gbit/s| ODU3-H-LSP |
| |------------X-------------|
| | |
+--+--+ +--+--+ +---+-+
| | | | +-+ +-+ | |
| A +------+ B +-----+ +***+ +-----+ Z |
| V.3 | OTU2 | V.1 |OTU3 +-+ +-+ OTU3| V.3 |
+-----+ +-----+ +-----+
... Service LSP
--- Hierarchical-LSP (H-LSP)
Figure 4: Client-Server TS Granularity Example
図4：クライアントサーバーTS細分性の例
In this scenario, an ODU3 LSP is set up from nodes B to Z. Node B has an old interface that is able to support 2.5 Gbit/s TS granularity; hence, only client TS granularity equal to 2.5 Gbit/s can be exported to ODU3 H-LSP-possible clients. An ODU2 LSP is set up from nodes A to Z with client TS granularity 1.25 Gbit/s signaled and exported towards clients. The ODU2 LSP is carried by ODU3 H-LSP from nodes B to Z. Due to the limitations of the old node B interface, the ODU2 LSP is mapped with 2.5 Gbit/s TS granularity over the ODU3 H-LSP. Then, an ODU1 LSP is set up from nodes A to Z, which is carried by the ODU2 H-LSP and mapped over it using 1.25 Gbit/s TS granularity.
このシナリオでは、ODU3 LSPがノードBからZに設定されています。ノードBには、2.5ギガビット/秒のTS粒度をサポートできる古いインターフェイスがあります。したがって、2.5 Gbit / sに等しいクライアントTS細分度のみをODU3 H-LSP可能なクライアントにエクスポートできます。 ODU2 LSPはノードAからZにセットアップされ、クライアントTS粒度1.25 Gbit / sがシグナリングされ、クライアントにエクスポートされます。 ODU2 LSPはODU3 H-LSPによってノードBからZに伝送されます。古いノードBインターフェースの制限により、ODU2 LSPはODU3 H-LSPを介して2.5 Gbit / s TSの粒度でマッピングされます。次に、ODU1 LSPがノードAからZにセットアップされます。これは、ODU2 H-LSPによって伝送され、1.25 Gbit / s TS粒度を使用してそれにマッピングされます。
What is shown in the example is that the TS granularity processing is a per-layer issue: even if the ODU3 H-LSP is created with the TS granularity client at 2.5 Gbit/s, the ODU2 H-LSP must guarantee a 1.25 Gbit/s TS granularity client. The ODU3 H-LSP is eligible from an ODU2 LSP perspective since it is known from the routing that this ODU3 interface at node Z supports an ODU2 termination exporting a TS granularity at 1.25 Gbit/s / 2.5 Gbit/s.
この例に示されているのは、TS粒度処理がレイヤーごとの問題であることです。ODU3H-LSPが2.5ギガビット/秒のTS粒度クライアントで作成された場合でも、ODU2 H-LSPは1.25ギガビット/秒を保証する必要があります。 ■TS細分性クライアント。 ODU3 H-LSPは、ルーティングから、ノードZのこのODU3インターフェースが、1.25 Gbit / s / 2.5 Gbit / sでTS粒度をエクスポートするODU2終端をサポートすることがわかっているため、ODU2 LSPの観点から適格です。
The TS granularity information is needed in the routing protocol as the ingress node (A in the previous example) needs to know if the interfaces at the last hop can support the required TS granularity. In case they cannot, A will compute an alternate path from itself to Z (see Figure 4).
入力ノード（前の例ではA）は、最終ホップのインターフェースが必要なTS細分性をサポートできるかどうかを知る必要があるため、ルーティングプロトコルにはTS細分性情報が必要です。それらができない場合、Aはそれ自体からZへの代替パスを計算します（図4を参照）。
Moreover, TS granularity information also needs to be signaled. As an example, consider the setup of an ODU3 forwarding adjacency that is going to carry an ODU0; hence, the support of 1.25 Gbit/s TS is needed. The information related to the TS granularity has to be carried in the signaling to permit node C (see Figure 5) to choose the right one among the different interfaces (with different TS granularities) towards D. In case the full Explicit Route Object (ERO) is provided in the signaling with explicit interface declaration, there is no need for C to choose the right interface towards D as it has been already decided by the ingress node or by the Path Computation Element (PCE).
さらに、TS粒度情報も通知する必要があります。例として、ODU0を伝送するODU3転送隣接のセットアップを考えます。したがって、1.25 Gbit / s TSのサポートが必要です。 TSの粒度に関連する情報は、ノードC（図5を参照）がDに向けて異なるインターフェース（異なるTSの粒度を持つ）から正しいインターフェースを選択できるように、シグナリングで伝達する必要があります。完全な明示ルートオブジェクト（ERO ）明示的なインターフェイス宣言のあるシグナリングで提供されます。入力ノードまたはパス計算要素（PCE）によってすでに決定されているため、CがDに向けて適切なインターフェイスを選択する必要はありません。
ODU3
<---------------------->
ODU0
<-------------------------------------->
| |
+--------+ +--------+ +--------+ +--------+
| | | | | | 1.25 | |
| Node | | Node | | Node +------+ Node |
| A +------+ B +------+ C | ODU3 | D |
| | ODU3 | | ODU3 | +------+ |
+--------+ 1.25 +--------+ 2.5 +--------+ 2.5 +--------+
Figure 5: TS Granularity in Signaling
図5：シグナリングにおけるTSの細分性
In case an ODUk FA_LSP needs to be set up as nesting another ODUj (as depicted in Figure 5), there might be the need to know the hierarchy of nested LSPs in addition to TS granularity to permit the penultimate hop (i.e., C) to choose the correct interface towards the egress node or any intermediate node (i.e., B) to choose the right path when performing the ERO expansion. This is not needed in case we allow bundling only component links with homogeneous hierarchies. In the case in which a specific implementation does not specify the last hop interface in the ERO, crankback can be a solution.
ODUk FA_LSPを別のODUjをネストするように設定する必要がある場合（図5に示すように）、最後から2番目のホップ（つまり、C）を許可するために、TS粒度に加えてネストされたLSPの階層を知る必要があるかもしれません。 ERO拡張を実行するときに正しいパスを選択するために、出力ノードまたは任意の中間ノード（つまり、B）への正しいインターフェイスを選択します。同種の階層を持つコンポーネントリンクのみをバンドルできる場合は、これは必要ありません。特定の実装でEROの最終ホップインターフェイスが指定されていない場合は、クランクバックが解決策になる可能性があります。
In a multi-stage multiplexing environment, any layer can have a different TS granularity structure; for example, in a multiplexing hierarchy such as ODU0->ODU2->ODU3, the ODU3 can be structured at TS granularity = 2.5 Gbit/s in order to support an ODU2 connection, but this ODU2 connection can be a tunnel for ODU0 and, hence, structured with 1.25 Gbit/s TS granularity. Therefore, any multiplexing level has to advertise its TS granularity capabilities in order to allow a correct path computation by the end nodes (both the ODUk trail and the H-LSP/FA).
マルチステージの多重化環境では、どのレイヤーも異なるTS粒度構造を持つことができます。たとえば、ODU0-> ODU2-> ODU3などの多重化階層では、ODU2接続をサポートするために、ODU3をTS粒度= 2.5 Gbit / sで構成できますが、このODU2接続はODU0のトンネルにすることができます。したがって、1.25 Gbit / s TSの粒度で構成されています。したがって、エンドノード（ODUkトレイルとH-LSP / FAの両方）による正しいパス計算を可能にするために、どの多重化レベルでもTS粒度機能を通知する必要があります。
The following table shows the different mapping possibilities depending on the TS granularity types. The client types are shown in the left column, while the different OPUk server and related TS granularities are listed in the top row. The table also shows the relationship between the TS granularity and the payload type.
次の表は、TS粒度タイプに応じたさまざまなマッピングの可能性を示しています。左の列にクライアントの種類が表示され、上の行にはさまざまなOPUkサーバーと関連するTSの粒度が表示されます。この表には、TS粒度とペイロードタイプの関係も示されています。
+------------------------------------------------+
| 2.5 Gbit/s TS || 1.25 Gbit/s TS |
| OPU2 | OPU3 || OPU1 | OPU2 | OPU3 | OPU4 |
+-------+------------------------------------------------+
| | - | - || AMP | GMP | GMP | GMP |
| ODU0 | | ||PT=0x20|PT=0x21|PT=0x21|PT=0x21|
+-------+------------------------------------------------+
| | AMP | AMP || - | AMP | AMP | GMP |
| ODU1 |PT=0x20|PT=0x20|| |PT=0x21|PT=0x21|PT=0x21|
+-------+------------------------------------------------+
| | - | AMP || - | - | AMP | GMP |
| ODU2 | |PT=0x20|| | |PT=0x21|PT=0x21|
+-------+------------------------------------------------+
| | - | - || - | - | GMP | GMP |
| ODU2e | | || | |PT=0x21|PT=0x21|
+-------+------------------------------------------------+
| | - | - || - | - | - | GMP |
| ODU3 | | || | | |PT=0x21|
+-------+------------------------------------------------+
| | - | - || - | GMP | GMP | GMP |
| ODUfl | | || |PT=0x21|PT=0x21|PT=0x21|
+-------+------------------------------------------------+
Figure 6: ODUj into OPUk Mapping Types (Source: [G.709-2012], Tables7-10)
図6：OPUjからOPUkへのマッピングタイプ（出典：[G.709-2012]、Tables7-10）
Specific information could be defined in order to carry the multiplexing hierarchy and adaptation information (i.e., TS granularity / PT and AMP / GMP) to enable precise path selection. That way, when the penultimate node (or the intermediate node performing the ERO expansion) receives such an object, together with the Traffic Parameters Object, it is possible to choose the correct interface towards the egress node.
正確なパス選択を可能にするために、多重化階層と適応情報（つまり、TS粒度/ PTおよびAMP / GMP）を伝送するために、特定の情報を定義できます。このようにして、最後から2番目のノード（またはERO拡張を実行する中間ノード）がそのようなオブジェクトをトラフィックパラメータオブジェクトと共に受信すると、出口ノードに向かう正しいインターフェイスを選択できます。
In conclusion, both routing and signaling need to be extended to appropriately represent the TS granularity/PT information. Routing needs to represent a link's TS granularity and PT capabilities as well as the supported multiplexing hierarchy. Signaling needs to represent the TS granularity/PT and multiplexing hierarchy encoding.
結論として、ルーティングとシグナリングの両方を拡張して、TS粒度/ PT情報を適切に表す必要があります。ルーティングは、リンクのTS粒度とPT機能、およびサポートされている多重化階層を表す必要があります。シグナリングは、TS粒度/ PTおよび多重化階層エンコーディングを表す必要があります。
[RFC4328] supports only the deprecated auto-MSI mode, which assumes that the Tributary Port Number (TPN) is automatically assigned in the transmit direction and is not checked in the receive direction.
[RFC4328]は非推奨の自動MSIモードのみをサポートします。これは、トリビュタリポート番号（TPN）が送信方向に自動的に割り当てられ、受信方向ではチェックされないことを前提としています。
As described in [G.709-2012] and [G.798], the OPUk overhead in an OTUk frame contains n (n = the total number of TSs of the ODUk) MSI bytes (in the form of multiframe), each of which is used to indicate the association between the TPN and TS of the ODUk.
[G.709-2012]および[G.798]で説明されているように、OTUkフレームのOPUkオーバーヘッドには、n（n = ODUkのTSの総数）MSIバイト（マルチフレームの形式）が含まれ、それぞれODUkのTPNとTS間の関連付けを示すために使用されます。
The association between the TPN and TS has to be configured by the control plane and checked by the data plane on each side of the link. (Please refer to [RFC7062] for further details.) As a consequence, the RSVP-TE signaling needs to be extended to support the TPN assignment function.
TPNとTS間の関連付けは、コントロールプレーンによって構成され、リンクの両側のデータプレーンによってチェックされる必要があります。 （詳細については、[RFC7062]を参照してください。）その結果、TPN割り当て機能をサポートするには、RSVP-TEシグナリングを拡張する必要があります。
From a routing perspective, GMPLS OSPF [RFC4203] and GMPLS IS-IS [RFC5307] only allow advertising interfaces [RFC4328] (the single TS type) without the capability of providing precise information about bandwidth-specific allocation. For example, in case of link bundling, when dividing the unreserved bandwidth by the MAX LSP bandwidth, it is not possible to know the exact number of LSPs at MAX LSP bandwidth size that can be set up (see the example in Figure 3).
ルーティングの観点から、GMPLS OSPF [RFC4203]およびGMPLS IS-IS [RFC5307]は、帯域幅固有の割り当てに関する正確な情報を提供する機能なしに、アドバタイズインターフェイス[RFC4328]（単一のTSタイプ）のみを許可します。たとえば、リンクバンドリングの場合、予約されていない帯域幅をMAX LSP帯域幅で割ると、設定可能なMAX LSP帯域幅サイズでのLSPの正確な数を知ることができません（図3の例を参照）。
The lack of spatial allocation heavily impacts the restoration process because the lack of information on free resources highly increases the number of crankbacks affecting network convergence time.
空きリソースに関する情報がないため、ネットワークのコンバージェンス時間に影響を与えるクランクバックの数が大幅に増えるため、空間割り当ての欠如は復元プロセスに大きな影響を与えます。
Moreover, actual tools provided by [RFC4203] and [RFC5307] only allow advertising signal types with fixed bandwidth and implicit hierarchy (e.g., Synchronous Digital Hierarchy (SDH) networks / Synchronous Optical Networks (SONETs)) or variable bandwidth with no hierarchy (e.g., packet switching networks); but, they do not provide the means for advertising networks with a mixed approach (e.g., ODUflex Constant Bit Rate (CBR) and ODUflex packet).
さらに、[RFC4203]と[RFC5307]が提供する実際のツールでは、固定帯域幅と暗黙の階層（例：同期デジタル階層（SDH）ネットワーク/同期光ネットワーク（SONET））または階層のない可変帯域幅（例： 、パケット交換ネットワーク）;しかし、それらは混合アプローチ（例えば、ODUflex固定ビットレート（CBR）とODUflexパケット）でネットワークをアドバタイズする手段を提供しません。
For example, when advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX LSP bandwidth, it is not possible to state whether the advertised link supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0, and ODUflex. Such ambiguity is not present in SDH networks where the hierarchy is implicit and flexible containers like ODUflex do not exist. The issue could be resolved by declaring 1 Interface Switching Capability Descriptor (ISCD) for each signal type actually supported by the link.
たとえば、ODU0をMIN LSP帯域幅としてアドバタイズし、ODU4をMAX LSP帯域幅としてアドバタイズする場合、アドバタイズされたリンクがODU4とODUflex、またはODU4、ODU3、ODU2、ODU1、ODU0、およびODUflexをサポートするかどうかを述べることはできません。このようなあいまいさは、階層が暗黙的であり、ODUflexのような柔軟なコンテナーが存在しないSDHネットワークには存在しません。この問題は、リンクで実際にサポートされている信号タイプごとに1つのインターフェイススイッチング機能記述子（ISCD）を宣言することで解決できます。
Suppose, for example, there is an equivalent ODU2 unreserved bandwidth in a TE link (with bundling capability) distributed on 4 ODU1; it would be advertised via the ISCD in this way:
たとえば、4つのODU1に分散されたTEリンク（バンドリング機能付き）に同等のODU2予約されていない帯域幅があるとします。 ISCDを介して次のように宣伝されます。
MAX LSP Bandwidth: ODU1
最大LSP帯域幅：ODU1
MIN LSP Bandwidth: ODU1
最小LSP帯域幅：ODU1
- Maximum Reservable Bandwidth (of the bundle) set to ODU2
- ODU2に設定された（バンドルの）最大予約可能帯域幅
- Unreserved Bandwidth (of the bundle) set to ODU2
- （バンドルの）予約されていない帯域幅がODU2に設定されている
In conclusion, the routing extensions defined in [RFC4203] and [RFC5307] require a different ISCD per signal type in order to advertise each supported container. This motivates an attempt to look for a more optimized solution without proliferation of the number of ISCDs advertised.
結論として、[RFC4203]と[RFC5307]で定義されているルーティング拡張機能では、サポートされている各コンテナをアドバタイズするために、信号タイプごとに異なるISCDが必要です。これは、宣伝されるISCDの数を増やすことなく、より最適化されたソリューションを探す試みの動機になります。
Per [RFC2328], OSPF messages are directly encapsulated in IP datagrams and depend on IP fragmentation when transmitting packets larger than the network's MTU. [RFC2328] recommends that "IP fragmentation should be avoided whenever possible". This recommendation further constrains solutions since OSPF does not support any generic mechanism to fragment OSPF Link State Advertisements (LSAs). Even when used in IP environments, IS-IS [RFC1195] does not support message sizes larger than a link's maximum frame size.
[RFC2328]によると、OSPFメッセージはIPデータグラムに直接カプセル化され、ネットワークのMTUよりも大きいパケットを送信する場合、IPフラグメンテーションに依存します。 [RFC2328]は、「IPフラグメンテーションは可能な限り回避する必要がある」ことを推奨しています。 OSPFはOSPFリンクステートアドバタイズメント（LSA）をフラグメント化する一般的なメカニズムをサポートしていないため、この推奨事項はソリューションをさらに制約します。 IS-IS [RFC1195]は、IP環境で使用される場合でも、リンクの最大フレームサイズより大きいメッセージサイズをサポートしません。
With respect to link bundling [RFC4201], the utilization of the ISCD as it is would not allow precise advertising of spatial bandwidth allocation information unless using only one component link per TE link.
リンクバンドリング[RFC4201]に関しては、ISCDをそのまま使用しても、TEリンクごとに1つのコンポーネントリンクのみを使用しない限り、空間帯域幅割り当て情報を正確にアドバタイズできません。
On the other hand, from a signaling point of view, [RFC4328] describes GMPLS signaling extensions to support the control of G.709 OTNs defined before 2011 [G.709-2001]. However, [RFC4328] needs to be updated because it does not provide the means to signal all the new signal types and related mapping and multiplexing functionalities.
一方、シグナリングの観点から、[RFC4328]は、2011年以前に定義されたG.709 OTNの制御をサポートするGMPLSシグナリング拡張について説明しています[G.709-2001]。ただし、[RFC4328]は、すべての新しい信号タイプと関連するマッピングおよび多重化機能を通知する手段を提供しないため、更新する必要があります。
In the current traffic parameters signaling, bit rate and tolerance are implicitly defined by the signal type. ODUflex CBR and ODUflex packet can have variable bit rates (please refer to [RFC7062], Table 2); hence, signaling traffic parameters need to be upgraded. With respect to tolerance, there is no need to upgrade GMPLS protocols as a fixed value (+/-100 parts per million (ppm) or +/-20 ppm depending on the signal type) is defined for each signal type.
現在のトラフィックパラメータシグナリングでは、ビットレートと許容度は信号タイプによって暗黙的に定義されます。 ODUflex CBRおよびODUflexパケットは可変ビットレートを持つことができます（[RFC7062]の表2を参照してください）。したがって、シグナリングトラフィックパラメータをアップグレードする必要があります。各信号タイプに対して固定値（信号タイプに応じて+/- 100 ppm（信号タイプに応じて+/- 20 ppm）が定義されているため、許容誤差に関してはGMPLSプロトコルをアップグレードする必要はありません。
Unreserved resources need to be advertised per priority and per signal type in order to allow the correct functioning of the restoration process. [RFC4203] only allows advertising unreserved resources per priority; this leads to uncertainty about how many LSPs of a specific signal type can be restored. As an example, consider the scenario depicted in the following figure.
予約されていないリソースは、復元プロセスを正しく機能させるために、優先度および信号タイプごとにアドバタイズする必要があります。 [RFC4203]は、優先度ごとに予約されていないリソースのアドバタイズのみを許可します。これにより、特定の信号タイプのLSPをいくつ復元できるかが不確実になります。例として、次の図に示すシナリオを考えます。
+------+ component link 1 +------+
| +------------------+ |
| | component link 2 | |
| N1 +------------------+ N2 |
| | component link 3 | |
| +------------------+ |
+------+ +---+--+
Figure 7: Concurrent Path Computation
図7：並行パス計算
Consider the case where a TE link is composed of three ODU3 component links with 32 TSs available on the first one, 24 TSs on the second, and 24 TSs on the third and is supporting ODU2 and ODU3 signal types. The node would advertise a TE link with unreserved bandwidth equal to 80 TSs and a MAX LSP bandwidth equal to 32 TSs. In case of restoration, the network could try to restore two ODU3s (64 TSs) in such a TE link while only a single ODU3 can be set up, and a crankback would be originated. In more complex network scenarios, the number of crankbacks can be much higher.
TEリンクが、最初の32 TS、2番目の24 TS、3番目の24 TSで使用可能な3つのODU3コンポーネントリンクで構成され、ODU2およびODU3信号タイプをサポートしている場合を考えます。ノードは、予約されていない帯域幅が80 TSに等しいTEリンクとMAX LSP帯域幅が32 TSに等しいアドバタイズを行います。復元の場合、ネットワークはそのようなTEリンクで2つのODU3（64 TS）を復元しようとする可能性がありますが、セットアップできるODU3は1つだけであり、クランクバックが発生します。より複雑なネットワークシナリオでは、クランクバックの数がはるかに多くなる可能性があります。
Maximum LSP bandwidth is currently advertised per priority in the common part of the ISCD. Section 5 reviews some of the implications of advertising OTN information using ISCDs and identifies the need for a more optimized solution. While strictly not required, such an optimization effort should also consider the optimization of the per-priority maximum LSP bandwidth advertisement of both fixed and variable ODU types.
ISCDの共通部分では、最大LSP帯域幅が優先度ごとに現在アドバタイズされています。セクション5では、ISCDを使用してOTN情報をアドバタイズすることの影響のいくつかをレビューし、より最適化されたソリューションの必要性を識別します。厳密には必須ではありませんが、そのような最適化の取り組みでは、固定および可変の両方のODUタイプの優先度ごとの最大LSP帯域幅アドバタイズメントの最適化も考慮する必要があります。
The capability advertised by an interface needs further distinction in order to separate terminating and switching capabilities. Due to internal constraints and/or limitations, the type of signal being advertised by an interface could just be switched (i.e., forwarded to the switching matrix without multiplexing/demultiplexing actions), terminated (demultiplexed), or both. The following figures help explain the switching and terminating capabilities.
インターフェイスによってアドバタイズされる機能は、終端機能とスイッチング機能を分離するために、さらに区別する必要があります。内部の制約および/または制限により、インターフェイスによってアドバタイズされる信号のタイプは、単に切り替えられる（つまり、多重化/逆多重化アクションなしでスイッチングマトリックスに転送される）、終了（逆多重化）、またはその両方が可能です。次の図は、スイッチング機能と終端機能を説明するのに役立ちます。
MATRIX LINE INTERFACE
+-----------------+ +-----------------+
| +-------+ | ODU2 | |
----->| ODU2 |----|----------|--------\ |
| +-------+ | | +----+ |
| | | \__/ |
| | | \/ |
| +-------+ | ODU3 | | ODU3 |
----->| ODU3 |----|----------|------\ | |
| +-------+ | | \ | |
| | | \| |
| | | +----+ |
| | | \__/ |
| | | \/ |
| | | ---------> OTU3
+-----------------+ +-----------------+
Figure 8: Switching and Terminating Capabilities
図8：機能の切り替えと終了
The figure in the example shows a line interface that is able to:
例の図は、次のことができるラインインターフェイスを示しています。
o Multiplex an ODU2 coming from the switching matrix into an ODU3 and map it into an OTU3
o スイッチングマトリクスからのODU2をODU3に多重化し、それをOTU3にマッピングする
o Map an ODU3 coming from the switching matrix into an OTU3
o スイッチングマトリックスからのODU3をOTU3にマッピングする
In this case, the interface bandwidth advertised is ODU2 with switching capability and ODU3 with both switching and terminating capabilities.
この場合、アドバタイズされるインターフェイス帯域幅は、スイッチング機能を備えたODU2と、スイッチング機能と終端機能の両方を備えたODU3です。
This piece of information needs to be advertised together with the related unreserved bandwidth and signal type. As a consequence, signaling must have the capability to set up an LSP, allowing the local selection of resources to be consistent with the limitations considered during the path computation.
この情報は、関連する予約されていない帯域幅と信号タイプとともに宣伝する必要があります。結果として、シグナリングにはLSPをセットアップする機能が必要です。これにより、リソースのローカル選択を、パス計算中に考慮される制限と一致させることができます。
In Figure 9 and Figure 10, there are two examples of the terminating/ switching capability differentiation. In both examples, all nodes only support single-stage capability. Figure 9 represents a scenario in which a failure on link B-C forces node A to calculate another ODU2 LSP carrying ODU0 service along the nodes B-E-D. As node D is a single stage capable node, it is able to extract ODU0 service only from the ODU2 interface. Node A has to know that from E to D exists an available OTU2 link from which node D can extract the ODU0 service. This information is required in order to avoid the OTU3 link being considered in the path computation.
図9と図10には、終端/スイッチング機能の違いの2つの例があります。どちらの例でも、すべてのノードが単一ステージ機能のみをサポートしています。図9は、リンクB-Cの障害によりノードAがノードB-E-Dに沿ってODU0サービスを伝送する別のODU2 LSPを計算するように強制するシナリオを表しています。ノードDは単一ステージ対応ノードであるため、ODU2インターフェースからのみODU0サービスを抽出できます。ノードAは、EからDに、ノードDがODU0サービスを抽出できる利用可能なOTU2リンクが存在することを認識している必要があります。この情報は、パス計算でOTU3リンクが考慮されないようにするために必要です。
ODU0 Transparently Transported
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| ODU2 LSP Carrying ODU0 Service |
| |'''''''''''''''''''''''''''''''''''''''''''| |
| | | |
| +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ |
ODU0 | | Link | | Link | | Link | | ODU0
---->| A |_________| B |_________| C |_________| D |---->
| | | | | | | |
+-----+ +--+--+ +-----+ ++--+-+
| | |
OTU3| | |
Link| +-----+__________________| |
| | | OTU3 Link |
|____| E | |
| |_____________________|
+-----+ OTU2 Link
Figure 9: Switching and Terminating Capabilities - Example 1
図9：機能の切り替えと終了-例1
Figure 10 addresses the scenario in which the restoration of the ODU2 LSP (A-B-C-D) is required. The two bundled component links between B and E could be used, but the ODU2 over the OTU2 component link can only be terminated and not switched. This implies that it cannot be used to restore the ODU2 LSP (A-B-C-D). However, such ODU2 unreserved bandwidth must be advertised since it can be used for a different ODU2 LSP terminating on E, e.g., F-B-E. Node A has to know that the ODU2 capability on the OTU2 link can only be terminated, and that the restoration of A-B-C-D can only be performed using the ODU2 bandwidth available on the OTU3 link.
図10は、ODU2 LSP（A-B-C-D）の復元が必要なシナリオを示しています。 BとEの間の2つのバンドルされたコンポーネントリンクを使用できますが、OTU2コンポーネントリンク上のODU2は終端のみが可能で、切り替えはできません。これは、ODU2 LSP（A-B-C-D）の復元には使用できないことを意味します。ただし、そのようなODU2予約されていない帯域幅は、Eで終端する別のODU2 LSP、たとえばF-B-Eに使用できるため、アドバタイズする必要があります。ノードAは、OTU2リンクのODU2機能を終了できるだけであり、A-B-C-Dの復元はOTU3リンクで利用可能なODU2帯域幅を使用してのみ実行できることを知っている必要があります。
ODU0 Transparently Transported
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| ODU2 LSP Carrying ODU0 Service |
| |'''''''''''''''''''''''''''''''''''''''''''| |
| | | |
| +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ |
ODU0 | | Link | | Link | | Link | | ODU0
---->| A |_________| B |_________| C |_________| D |---->
| | | | | | | |
+-----+ ++-+-++ +-----+ +--+--+
| | | |
OTU2| | | |
+-----+ Link| | | OTU3 +-----+ |
| | | | | Link | | |
| F |_______| | |___________| E |___________|
| | |_____________| | OTU2 Link
+-----+ OTU2 Link +-----+
Figure 10: Switching and Terminating Capabilities - Example 2
図10：機能の切り替えと終了-例2
The issue shown above is analyzed in an OTN context, but it is a general technology-independent GMPLS limitation.
上記の問題はOTNのコンテキストで分析されていますが、これは一般的なテクノロジーに依存しないGMPLSの制限です。
[RFC4202] defines eight priorities for resource availability and usage. As defined, each is advertised independent of the number of priorities supported by a network, and even unsupported priorities are included. As is the case in Section 8, addressing any inefficiency with such advertisements is not required to support OTNs. But, any such inefficiency should also be considered as part of the optimization effort identified in Section 5.
[RFC4202]は、リソースの可用性と使用法に関する8つの優先順位を定義しています。定義されているように、それぞれはネットワークでサポートされている優先度の数とは無関係にアドバタイズされ、サポートされていない優先度も含まれます。セクション8の場合と同様に、OTNをサポートするために、このようなアドバタイズメントの非効率性に対処する必要はありません。ただし、そのような非効率性も、セクション5で特定された最適化作業の一部として検討する必要があります。
With reference to [RFC7062], the introduction of multi-stage multiplexing implies the advertisement of cascaded adaptation capabilities together with the matrix access constraints. The structure defined by the IETF for the advertisement of adaptation capabilities is the Interface Adaptation Capability Descriptor (IACD), as defined in [RFC6001].
[RFC7062]を参照すると、多段多重化の導入は、カスケードアクセス適応機能とマトリックスアクセス制約のアドバタイズを意味します。 [RFC6001]で定義されているように、適応機能のアドバタイズのためにIETFによって定義された構造は、Interface Adaptation Capability Descriptor（IACD）です。
With respect to routing, please note that in case of multi-stage multiplexing hierarchy (e.g., ODU1->ODU2->ODU3), not only the ODUk/ OTUk bandwidth (ODU3) and service-layer bandwidth (ODU1) are needed but also the intermediate one (ODU2). This is a typical case of a spatial allocation problem.
ルーティングに関しては、マルチステージ多重化階層（例：ODU1-> ODU2-> ODU3）の場合、ODUk / OTUk帯域幅（ODU3）とサービス層帯域幅（ODU1）だけでなく、中間のもの（ODU2）。これは、空間割り当ての問題の典型的なケースです。
In this scenario, suppose the following advertisement:
このシナリオでは、次の広告を想定します。
Hierarchy: ODU1->ODU2->ODU3
Number of ODU1==5
ODU1 == 5の数
The number of ODU1 suggests that it is possible to have an ODU2 FA, but it depends on the spatial allocation of such ODU1s.
ODU1の数は、ODU2 FAを持つことが可能であることを示していますが、そのようなODU1の空間割り当てに依存します。
It is possible that two links are bundled together and three ODU1->ODU2->ODU3 are available on a component link and two on the other one; in such a case, the ODU2 FA could not be set up. The advertisement of the ODU2 is needed because in case of ODU1 spatial allocation (3+2), the ODU2 available bandwidth would be 0 (ODU2 FA cannot be created), while in case of ODU1 spatial allocation (4+1), the ODU2 available bandwidth would be 1 (1 ODU2 FA can be created).
2つのリンクが一緒にバンドルされ、3つのODU1-> ODU2-> ODU3がコンポーネントリンクで、2つが他のリンクで使用可能である可能性があります。このような場合、ODU2 FAをセットアップできませんでした。 ODU1の空間割り当て（3 + 2）の場合、ODU2の使用可能な帯域幅は0（ODU2 FAを作成できない）となり、ODU1の空間割り当て（4 + 1）の場合、ODU2使用可能な帯域幅は1になります（1つのODU2 FAを作成できます）。
The information stated above implies augmenting both the ISCD and the IACD.
上記の情報は、ISCDとIACDの両方を増強することを意味します。
The ODUk label format defined in [RFC4328] could be updated to support new signal types as defined in [G.709-2012], but it would be difficult to further enhance it to support possible new signal types.
[RFC4328]で定義されたODUkラベル形式は、[G.709-2012]で定義された新しい信号タイプをサポートするように更新できますが、考えられる新しい信号タイプをサポートするようにさらに拡張することは困難です。
Furthermore, such a label format may have scalability issues due to the high number of labels needed when signaling large LSPs. For example, when an ODU3 is mapped into an ODU4 with 1.25 Gbit/s tributary slots, it would require the utilization of 31 labels (31*4*8=992 bits) to be allocated, while an ODUflex into an ODU4 may need up to 80 labels (80*4*8=2560 bits).
さらに、このようなラベル形式では、大きなLSPをシグナリングするときに必要なラベルの数が多いため、スケーラビリティの問題が発生する可能性があります。たとえば、ODU3が1.25 Gbit / sのトリビュタリスロットを持つODU4にマッピングされる場合、31のラベル（31 * 4 * 8 = 992ビット）を割り当てる必要がありますが、ODU4へのODUflexは80ラベルまで（80 * 4 * 8 = 2560ビット）。
A new flexible and scalable ODUk label format needs to be defined.
新しい柔軟でスケーラブルなODUkラベル形式を定義する必要があります。
This document provides an evaluation of OTN requirements against actual routing ([RFC4202], [RFC4203], and [RFC5307]) and signaling mechanisms ([RFC3471], [RFC3473], and [RFC4328]) in GMPLS.
このドキュメントでは、GMPLSの実際のルーティング（[RFC4202]、[RFC4203]、および[RFC5307]）およびシグナリングメカニズム（[RFC3471]、[RFC3473]、および[RFC4328]）に対するOTN要件の評価について説明します。
This document defines new types of information to be carried that describes OTN containers and hierarchies. It does not define any new protocol elements, and from a security standpoint, this memo does not introduce further risks with respect to the information that can be currently conveyed via GMPLS protocols. For a general discussion on MPLS and GMPLS-related security issues, see the MPLS/GMPLS security framework [RFC5920].
このドキュメントは、OTNコンテナと階層を説明する、運ばれる新しいタイプの情報を定義します。新しいプロトコル要素は定義されておらず、セキュリティの観点から、このメモは、GMPLSプロトコルを介して現在伝達できる情報に関して、さらなるリスクをもたらしません。 MPLSおよびGMPLS関連のセキュリティ問題に関する一般的な説明については、MPLS / GMPLSセキュリティフレームワーク[RFC5920]を参照してください。
Jonathan Sadler Tellabs EMail: jonathan.sadler@tellabs.com
Jonathan Sadler Tellabs Eメール：jonathan.sadler@tellabs.com
John Drake Juniper EMail: jdrake@juniper.net
ジョンドレイクジュニパーメール：jdrake@juniper.net
Francesco Fondelli Ericsson Via Moruzzi 1 Pisa - 56100 EMail: francesco.fondelli@ericsson.com
Francesco Fondelli Ericsson Via Moruzzi 1 Pisa-56100 Eメール：francesco.fondelli@ericsson.com
The authors would like to thank Lou Berger, Eve Varma, and Sergio Lanzone for their precious collaboration and review.
著者は、Lou Berger、Eve Varma、およびSergio Lanzoneの貴重なコラボレーションとレビューに感謝します。
[G.709-2001] ITU-T, "Interfaces for the Optical Transport Network (OTN)", G.709/Y.1331 Recommendation, February 2001.
[G.709-2001] ITU-T、「Interfaces for the Optical Transport Network（OTN）」、G.709 / Y.1331 Recommendation、2001年2月。
[G.709-2012] ITU-T, "Interfaces for the Optical Transport Network (OTN)", G.709/Y.1331 Recommendation, February 2012.
[G.709-2012] ITU-T、「Interfaces for the Optical Transport Network（OTN）」、G.709 / Y.1331 Recommendation、February 2012。
[G.798] ITU-T, "Characteristics of Optical Transport Network Hierarchy Equipment Functional Blocks", G.798 Recommendation, December 2012.
[G.798] ITU-T、「Characteristics of Optical Transport Network Hierarchy Equipment Functional Blocks」、G.798勧告、2012年12月。
[G.872] ITU-T, "Architecture of Optical Transport Networks", G.872 Recommendation, October 2012.
[G.872] ITU-T、「Architecture of Optical Transport Networks」、G.872勧告、2012年10月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP / IPおよびデュアル環境でのルーティングのためのOSI IS-ISの使用」、RFC 1195、1990年12月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Functional Description」、RFC 3471、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L。、「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Resource ReserVation Protocol-Traffic Engineering（RSVP-TE）Extensions」、RFC 3473、2003年1月。
[RFC4202] Kompella, K. and Y. Rekhter, "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. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203] Kompella、K。およびY. Rekhter、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、2005年10月。
[RFC4328] Papadimitriou, D., "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. and Y. Rekhter, "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5307] Kompella、K。およびY. Rekhter、「汎用マルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張」、RFC 5307、2008年10月。
[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月。
[OTN-OSPF] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and J. Drake, "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks", Work in Progress, December 2013.
[OTN-OSPF] Ceccarelli、D.、Ed。、Zhang、F.、Belotti、S.、Rao、R。、およびJ. Drake、「OSPFへのトラフィックエンジニアリング拡張：進化するG.のOSPFの汎用MPLS（GMPLS）コントロール。 709 OTN Networks」、Work in Progress、2013年12月。
[OTN-RSVP] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D., and K. Pithewan, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control", Work in Progress, September 2013.
[OTN-RSVP] Zhang、F.、Ed。、Zhang、G.、Belotti、S.、Ceccarelli、D.、K. Pithewan、 "Generalized Multi-Protocol Label Switching（GMPLS）Signaling Extensions for the evolving G. 709 Optical Transport Networks Control」、Work in Progress、2013年9月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[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月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC7062] Zhang, F., Li, D., Li, H., Belotti, S., and D. Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", RFC 7062, November 2013.
[RFC7062] Zhang、F.、Li、D.、Li、H.、Belotti、S。、およびD. Ceccarelli、「GMPLSおよびG.709光トランスポートネットワークのPCE制御のフレームワーク」、RFC 7062、2013年11月。
Authors' Addresses
著者のアドレス
Sergio Belotti (editor) Alcatel-Lucent Via Trento, 30 Vimercate Italy EMail: sergio.belotti@alcatel-lucent.com
Sergio Belotti（編集者）Alcatel-Lucent Via Trento、30 VimercateイタリアEメール：sergio.belotti@alcatel-lucent.com
Pietro Vittorio Grandi Alcatel-Lucent Via Trento, 30 Vimercate Italy EMail: pietro_vittorio.grandi@alcatel-lucent.com
ピエトロヴィットリオグランディアルカテルルーセントVia Trento、30ヴィメルカーテイタリアメール：pietro_vittorio.grandi@alcatel-lucent.com
Daniele Ceccarelli (editor) Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy EMail: daniele.ceccarelli@ericsson.com
Daniele Ceccarelli（編集者）エリクソンVia A. Negrone 1 / Aジェノア-セストリポネンテイタリアメール：daniele.ceccarelli@ericsson.com
Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy EMail: diego.caviglia@ericsson.com
ディエゴカビリアエリクソンVia A. Negrone 1 / Aジェノア-セストリポネンテイタリアEメール：diego.caviglia@ericsson.com
Fatai Zhang 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: danli@huawei.com
Dan l IH UAはテクノロジーF3-5-br＆Dセンター、hu Aは基本禁止日、長いギャング地区は非常にリアルです518129 P.R.中国電話：+ 86-755-28973237メール：Shan Li @ Huawei.com