[要約] 要約：RFC 7138は、G.709光トランスポートネットワークの進化に対するGMPLS制御のためのOSPFのトラフィックエンジニアリング拡張について説明しています。目的：このRFCの目的は、OSPFを使用してG.709光トランスポートネットワークのGMPLS制御を拡張し、トラフィックエンジニアリングの機能を向上させることです。
Internet Engineering Task Force (IETF) D. Ceccarelli, Ed.
Request for Comments: 7138 Ericsson
Category: Standards Track F. Zhang
ISSN: 2070-1721 Huawei Technologies
S. Belotti
Alcatel-Lucent
R. Rao
Infinera Corporation
J. Drake
Juniper
March 2014
Traffic Engineering Extensions to OSPF for GMPLS Control of Evolving G.709 Optical Transport Networks
進化するG.709光トランスポートネットワークのGMPLS制御のためのOSPFへのトラフィックエンジニアリング拡張
Abstract
概要
This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support GMPLS control of Optical Transport Networks (OTNs) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC 4203.
このドキュメントでは、Open Shortest Path First-トラフィックエンジニアリング（OSPF-TE）ルーティングプロトコル拡張について説明し、2012年に公開されたITU-T勧告G.709で指定された光トランスポートネットワーク（OTN）のGMPLS制御をサポートします。RFC4203で定義されたメカニズムを拡張します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7138.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7138で入手できます。
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 ....................................................4
1.1. Terminology ................................................4
2. OSPF-TE Extensions ..............................................4
3. TE-Link Representation ..........................................6
4. ISCD Format Extensions ..........................................6
4.1. Switching Capability Specific Information ..................8
4.1.1. Switching Capability Specific Information
for Fixed Containers ................................9
4.1.2. Switching Capability Specific Information
for Variable Containers ............................10
4.1.3. Switching Capability Specific Information --
Field Values and Explanation .......................10
5. Examples .......................................................13
5.1. MAX LSP Bandwidth Fields in the ISCD ......................13
5.2. Example of T, S, and TS Granularity Utilization ...........17
5.2.1. Example of Different TS Granularities ..............18
5.3. Example of ODUflex Advertisement ..........................20
5.4. Example of Single-Stage Muxing ............................22
5.5. Example of Multi-Stage Muxing -- Unbundled Link ...........23
5.6. Example of Multi-Stage Muxing -- Bundled Links ............25
5.7. Example of Component Links with Non-Homogeneous
Hierarchies ...............................................27
6. OSPFv2 Scalability .............................................29
7. Compatibility ..................................................30
8. Security Considerations ........................................30
9. IANA Considerations ............................................31
9.1. Switching Types ...........................................31
9.2. New Sub-TLVs ..............................................31
10. Contributors ..................................................32
11. Acknowledgements ..............................................33
12. References ....................................................33
12.1. Normative References .....................................33
12.2. Informative References ...................................34
G.709 ("Interfaces for the Optical Transport Network (OTN)") [G.709-2012] includes new fixed and flexible ODU (Optical channel Data Unit) containers, includes two types of tributary slots (i.e., 1.25 Gbps and 2.5 Gbps), and supports various multiplexing relationships (e.g., ODUj multiplexed into ODUk (j<k)), two different tributary slots for ODUk (K=1, 2, 3), and the ODUflex service type. In order to advertise this information in routing, this document provides encoding specific to OTN technology for use in GMPLS OSPF-TE as defined in [RFC4203].
G.709（「光トランスポートネットワーク（OTN）のインターフェース」）[G.709-2012]には、2つのタイプのトリビュタリスロット（つまり、1.25 Gbpsと2.5）を含む、固定された柔軟なODU（光チャネルデータユニット）コンテナが含まれています。 Gbps）、およびさまざまな多重化関係（ODUkに多重化されたODUj（j <k）など）、ODUk用の2つの異なる支流スロット（K = 1、2、3）、およびODUflexサービスタイプをサポートします。ルーティングでこの情報をアドバタイズするために、このドキュメントでは、[RFC4203]で定義されているGMPLS OSPF-TEで使用するOTNテクノロジー固有のエンコーディングを提供します。
For a short overview of OTN evolution and implications of OTN requirements on GMPLS routing, please refer to [RFC7062]. The information model and an evaluation against the current solution are provided in [RFC7096]. The reader is supposed to be familiar with both of these documents.
OTNの進化の概要とGMPLSルーティングに対するOTN要件の影響については、[RFC7062]を参照してください。情報モデルと現在のソリューションに対する評価は、[RFC7096]で提供されています。読者はこれらのドキュメントの両方に精通しているはずです。
Routing information for Optical Channel (OCh) layer (i.e., wavelength) is beyond the scope of this document. Please refer to [RFC6163] and [RFC6566] for further information.
光チャネル（OCh）レイヤー（つまり、波長）のルーティング情報は、このドキュメントの範囲外です。詳細については、[RFC6163]および[RFC6566]を参照してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In terms of GMPLS-based OTN networks, each Optical channel Transport Unit-k (OTUk) can be viewed as a component link, and each component link can carry one or more types of ODUj (j<k).
GMPLSベースのOTNネットワークの観点から、各光チャネルトランスポートユニットk（OTUk）はコンポーネントリンクと見なすことができ、各コンポーネントリンクは1つ以上のタイプのODUj（j <k）を伝送できます。
Each TE-Link State Advertisement (LSA) can carry a top-level link TLV with several nested sub-TLVs to describe different attributes of a TE-Link. Two top-level TLVs are defined in [RFC3630]: (1) The Router Address TLV (referred to as the Node TLV) and (2) the TE-Link TLV. One or more sub-TLVs can be nested into the two top-level TLVs. The sub-TLV set for the two top-level TLVs are also defined in [RFC3630] and [RFC4203].
各TE-Linkステートアドバタイズメント（LSA）は、TE-Linkのさまざまな属性を記述するために、いくつかのネストされたサブTLVを持つトップレベルリンクTLVを運ぶことができます。 [RFC3630]では、2つのトップレベルTLVが定義されています：（1）ルーターアドレスTLV（ノードTLVと呼ばれる）および（2）TE-Link TLV。 1つ以上のサブTLVを2つの最上位TLVにネストできます。 2つのトップレベルTLVのサブTLVセットは、[RFC3630]と[RFC4203]でも定義されています。
As discussed in [RFC7062] and [RFC7096], OSPF-TE must be extended to be able to advertise the termination and Switching Capabilities of each different ODUj and ODUk/OTUk (Optical Transport Unit) and the advertisement of related multiplexing capabilities. These capabilities are carried in the Switching Capability specific information field of the Interface Switching Capability Descriptor (ISCD) using formats defined in this document. As discussed in [RFC7062], the use of a technology-specific Switching Capability specific information field necessitates the definition of a new Switching Capability value and associated new Switching Capability.
[RFC7062]と[RFC7096]で説明されているように、OSPF-TEは、それぞれの異なるODUjおよびODUk / OTUk（Optical Transport Unit）の終端とスイッチング機能、および関連する多重化機能のアドバタイズをアドバタイズできるように拡張する必要があります。これらの機能は、このドキュメントで定義されている形式を使用して、Interface Switching Capability Descriptor（ISCD）のスイッチング機能固有の情報フィールドで伝達されます。 [RFC7062]で説明されているように、テクノロジー固有のスイッチング機能固有の情報フィールドを使用するには、新しいスイッチング機能の値と関連する新しいスイッチング機能の定義が必要です。
In the following, we will use ODUj to indicate a service type that is multiplexed into a higher-order (HO) ODU, ODUk to indicate a higher-order ODU including an ODUj, and ODUk/OTUk to indicate the layer mapped into the OTUk. Moreover, ODUj(S) and ODUk(S) are used to indicate the ODUj and ODUk supporting Switching Capability only, and the ODUj->ODUk format is used to indicate the ODUj-into-ODUk multiplexing capability.
以下では、ODUjを使用して、高次（HO）ODUに多重化されたサービスタイプを示し、ODUkはODUjを含む高次ODUを示し、ODUk / OTUkはOTUkにマップされたレイヤーを示します。 。さらに、ODUj（S）およびODUk（S）は、ODUjおよびODUkがサポートするスイッチング機能のみを示すために使用され、ODUj-> ODUk形式は、ODUj-to-ODUk多重化機能を示すために使用されます。
This notation can be repeated as needed depending on the number of multiplexing levels. In the following, the term "multiplexing tree" is used to identify a multiplexing hierarchy where the root is always a server ODUk/OTUk and any other supported multiplexed container is represented with increasing granularity until reaching the leaf of the tree. The tree can be structured with more than one branch if the server ODUk/OTUk supports more than one hierarchy.
この表記は、多重化レベルの数に応じて、必要に応じて繰り返すことができます。以下では、「多重化ツリー」という用語を使用して、ルートが常にサーバーODUk / OTUkであり、サポートされている他の多重化コンテナーがツリーのリーフに到達するまで細分度を増して表される多重化階層を識別します。サーバーODUk / OTUkが複数の階層をサポートしている場合、ツリーは複数のブランチで構成できます。
For example, if a multiplexing hierarchy like the following one is considered:
たとえば、次のような多重化階層が考慮される場合：
ODU2 ODU0 ODUflex ODU0
\ / \ /
| |
ODU3 ODU2
\ /
\ /
\ /
\ /
ODU4
the ODU4 is the root of the muxing tree; ODU3 and ODU2 are containers directly multiplexed into the server; and ODU2 and ODU0 are the leaves of the ODU3 branch, while ODUflex and ODU0 are the leaves of the ODU2 one. This means that it is possible to have the following multiplexing capabilities:
ODU4は多重化ツリーのルートです。 ODU3およびODU2は、サーバーに直接多重化されたコンテナーです。 ODU2とODU0はODU3ブランチのリーフであり、ODUflexとODU0はODU2ブランチのリーフです。これは、次の多重化機能を持つことが可能であることを意味します。
ODU2->ODU3->ODU4
ODU0->ODU3->ODU4
ODUflex->ODU2->ODU4
ODU0->ODU2->ODU4
G.709 ODUk/OTUk links are represented as TE-Links in GMPLS Traffic Engineering Topology for supporting ODUj layer switching. These TE-Links can be modeled in multiple ways.
G.709 ODUk / OTUkリンクは、ODUjレイヤスイッチングをサポートするためのGMPLSトラフィックエンジニアリングトポロジではTEリンクとして表されます。これらのTE-Linksは、複数の方法でモデル化できます。
OTUk physical link(s) can be modeled as a TE-Link(s). Figure 1 below provides an illustration of one-hop OTUk TE-Links.
OTUk物理リンクは、TE-Linkとしてモデル化できます。下の図1は、1ホップのOTUk TE-Linkを示しています。
+-------+ +-------+ +-------+
| OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C |
+-------+ +-------+ +-------+
|<-- TE-Link -->| |<-- TE-Link -->|
Figure 1: OTUk TE-Links
図1：TE-Linksです
It is possible to create TE-Links that span more than one hop by creating forwarding adjacencies (FAs) between non-adjacent nodes (see Figure 2). As in the one-hop case, multiple-hop TE-Links advertise the ODU Switching Capability.
非隣接ノード間で転送隣接（FA）を作成することにより、複数のホップにまたがるTE-Linkを作成できます（図2を参照）。 1ホップの場合と同様に、マルチホップTEリンクはODUスイッチング機能をアドバタイズします。
+-------+ +-------+ +-------+
| OTN | | OTN | | OTN |
|Switch |<- OTUk Link ->|Switch |<- OTUk Link ->|Switch |
| A | | B | | C |
+-------+ +-------+ +-------+
ODUk Switched
|<------------- ODUk Link ------------->|
|<-------------- TE-Link--------------->|
Figure 2: Multiple-Hop TE-Link
図2：マルチホップTE-Link
The ISCD describes the Switching Capability of an interface and is defined in [RFC4203]. This document defines a new Switching Capability value for OTN [G.709-2012] as follows:
ISCDはインターフェイスのスイッチング機能を記述し、[RFC4203]で定義されています。このドキュメントでは、OTN [G.709-2012]の新しいスイッチング機能の値を次のように定義しています。
Value Type
----- ----
110 OTN-TDM capable
When supporting the extensions defined in this document, for both
fixed and flexible ODUs, the Switching Capability and Encoding values
MUST be used as follows:
o Switching Capability = OTN-TDM
o スイッチング機能= OTN-TDM
o Encoding Type = G.709 ODUk (Digital Path) as defined in [RFC4328]
o エンコーディングタイプ= [RFC4328]で定義されているG.709 ODUk（デジタルパス）
The same Switching Type and encoding values must be used for both fixed and flexible ODUs. When Switching Capability and Encoding fields are set to values as stated above, the Interface Switching Capability Descriptor MUST be interpreted as defined in [RFC4203].
固定ODUとフレキシブルODUの両方に同じスイッチングタイプとエンコーディング値を使用する必要があります。上記のように、Switching CapabilityおよびEncodingフィールドが値に設定されている場合、Interface Switching Capability Descriptorは、[RFC4203]で定義されているように解釈する必要があります。
The MAX LSP Bandwidth field is used according to [RFC4203], i.e., 0 <= MAX LSP Bandwidth <= ODUk/OTUk, and intermediate values are those on the branch of the OTN switching hierarchy supported by the interface. For example, in the OTU4 link it could be possible to have ODU4 as MAX LSP Bandwidth for some priorities, ODU3 for others, ODU2 for some others, etc. The bandwidth unit is in bytes/second and the encoding MUST be in IEEE floating point format. The discrete values for various ODUs are shown in the table below (please note that there are 1000 bits in a kilobit according to normal practices in telecommunications).
MAX LSP帯域幅フィールドは、[RFC4203]に従って使用されます。つまり、0 <= MAX LSP帯域幅<= ODUk / OTUkであり、中間値は、インターフェイスによってサポートされるOTNスイッチング階層のブランチ上の値です。たとえば、OTU4リンクでは、一部の優先度ではODU4をMAX LSP帯域幅、他の優先度ではODU3、その他の優先度ではODU2にすることができます。帯域幅の単位はバイト/秒で、エンコーディングはIEEE浮動小数点でなければなりません。フォーマット。さまざまなODUの離散値を以下の表に示します（電気通信の通常の慣行に従って、キロビットには1000ビットがあることに注意してください）。
+-------------------+-----------------------------+-----------------+
| ODU Type | ODU nominal bit rate |Value in Byte/Sec|
| | |(floating p. val)|
+-------------------+-----------------------------+-----------------+
| ODU0 | 1,244,160 kbps | 0x4D1450C0 |
| ODU1 | 239/238 x 2,488,320 kbps | 0x4D94F048 |
| ODU2 | 239/237 x 9,953,280 kbps | 0x4E959129 |
| ODU3 | 239/236 x 39,813,120 kbps | 0x4F963367 |
| ODU4 | 239/227 x 99,532,800 kbps | 0x504331E3 |
| ODU2e | 239/237 x 10,312,500 kbps | 0x4E9AF70A |
| | | |
| ODUflex for CBR | 239/238 x client signal | MAX LSP |
| Client signals | bit rate | Bandwidth |
| | | |
| ODUflex for GFP-F | | MAX LSP |
| Mapped client | Configured bit rate | Bandwidth |
| signal | | |
| | | |
| ODUflex | Configured bit rate | MAX LSP |
| resizable | | Bandwidth |
+-------------------+-----------------------------+-----------------+
A single ISCD MAY be used for the advertisement of unbundled or
bundled links supporting homogeneous multiplexing hierarchies and the
same TS (tributary slot) granularity. A different ISCD MUST be used
for each different muxing hierarchy (muxing tree in the following
examples) and different TS granularity supported within the TE-Link.
When a received LSA includes a sub-TLV not formatted accordingly to the precise specifications in this document, the problem SHOULD be logged and the wrongly formatted sub-TLV MUST NOT be used for path computation.
受信したLSAに、このドキュメントの正確な仕様に従ってフォーマットされていないサブTLVが含まれている場合、問題をログに記録し、誤ってフォーマットされたサブTLVをパス計算に使用してはなりません（MUST NOT）。
The technology-specific part of the OTN-TDM ISCD may include a variable number of sub-TLVs called Bandwidth sub-TLVs. Each sub-TLV is encoded with the sub-TLV header as defined in [RFC3630], Section 2.3.2. The muxing hierarchy tree MUST be encoded as an order-independent list. Two types of Bandwidth sub-TLVs are defined (TBA by IANA). Note that type values are defined in this document and not in [RFC3630].
OTN-TDM ISCDのテクノロジー固有の部分には、帯域幅サブTLVと呼ばれる可変数のサブTLVが含まれる場合があります。各サブTLVは、[RFC3630]のセクション2.3.2で定義されているサブTLVヘッダーでエンコードされます。多重化階層ツリーは、順序に依存しないリストとしてエンコードする必要があります。 2種類の帯域幅サブTLVが定義されています（IANAによるTBA）。タイプの値はこのドキュメントで定義されており、[RFC3630]では定義されていないことに注意してください。
o Type 1 - Unreserved Bandwidth for fixed containers
o タイプ1-固定コンテナーの予約されていない帯域幅
o Type 2 - Unreserved/MAX LSP Bandwidth for flexible containers
o タイプ2-フレキシブルコンテナーの予約なし/最大LSP帯域幅
The Switching Capability specific information (SCSI) MUST include one Type 1 sub-TLV for each fixed container and one Type 2 sub-TLV for each variable container. Each container type is identified by a Signal Type. Signal Type values are defined in [RFC7139].
スイッチング機能固有の情報（SCSI）には、固定コンテナーごとに1つのタイプ1サブTLVと、可変コンテナーごとに1つのタイプ2サブTLVを含める必要があります。各コンテナタイプは、信号タイプによって識別されます。信号タイプの値は[RFC7139]で定義されています。
With respect to ODUflex, three different Signal Types are allowed:
ODUflexに関しては、3つの異なる信号タイプが許可されています。
o 20 - ODUflex(CBR) (i.e., 1.25*N Gbps)
o 21 - ODUflex(GFP-F), resizable (i.e., 1.25*N Gbps)
o 22 - ODUflex(GFP-F), non-resizable (i.e., 1.25*N Gbps)
where CBR stands for Constant Bit Rate, and GFP-F stands for Generic Framing Procedure - Framed.
ここで、CBRは固定ビットレートを表し、GFP-FはGeneric Framing Procedure-Framedを表します。
Each MUST always be advertised in separate Type 2 sub-TLVs as each uses different adaptation functions [G.805]. In the case that both GFP-F resizable and non-resizable (i.e., 21 and 22) are supported, only Signal Type 21 SHALL be advertised as this type also implies support for Type 22 adaptation.
それぞれが異なる適応機能[G.805]を使用するため、それぞれを常に別々のタイプ2サブTLVでアドバタイズする必要があります。 GFP-Fのサイズ変更可能とサイズ変更不可の両方（つまり、21と22）がサポートされている場合、シグナルタイプ21のみがアドバタイズされる必要があります。
The format of the Bandwidth sub-TLV for fixed containers is depicted in the following figure:
固定コンテナの帯域幅サブTLVのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Num of stages |T|S| TSG | Res | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1 | ... | Stage#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved ODUj at Prio 0 | ..... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved ODUj at Prio 7 | Unreserved Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Bandwidth Sub-TLV -- Type 1
図3：帯域幅サブTLV-タイプ1
The values of the fields shown in Figure 3 are explained in Section 4.1.3.
図3に示すフィールドの値については、4.1.3項で説明します。
4.1.2. Switching Capability Specific Information for Variable Containers
4.1.2. 可変コンテナーの機能固有の切り替え情報
The format of the Bandwidth sub-TLV for variable containers is depicted in the following figure:
可変コンテナーの帯域幅サブTLVのフォーマットを次の図に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Num of stages |T|S| TSG | Res | Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1 | ... | Stage#N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Bandwidth Sub-TLV -- Type 2
図4：帯域幅サブTLV-タイプ2
The values of the fields shown in figure 4 are explained in Section 4.1.3.
図4に示すフィールドの値については、4.1.3項で説明します。
4.1.3. Switching Capability Specific Information -- Field Values and Explanation
4.1.3. スイッチング機能固有の情報-フィールド値と説明
The fields in the Bandwidth sub-TLV MUST be filled as follows:
BandwidthサブTLVのフィールドには、次のように入力する必要があります。
o Signal Type (8 bits): Indicates the ODU type being advertised. Values are defined in [RFC7139].
o 信号タイプ（8ビット）：アドバタイズされているODUタイプを示します。値は[RFC7139]で定義されています。
o Num of stages (8 bits): This field indicates the number of multiplexing stages used to transport the indicated Signal Type. It MUST be set to the number of stages represented in the sub-TLV.
o ステージ数（8ビット）：このフィールドは、指定された信号タイプの転送に使用される多重化ステージの数を示します。サブTLVで表されるステージの数に設定する必要があります。
o Flags (8 bits):
o フラグ（8ビット）：
* T Flag (bit 17): Indicates whether the advertised bandwidth can be terminated. When the Signal Type can be terminated T MUST be set, while when the Signal Type cannot be terminated T MUST be cleared.
* Tフラグ（ビット17）：通知された帯域幅を終了できるかどうかを示します。信号タイプを終了できる場合はTを設定する必要がありますが、信号タイプを終了できない場合はTをクリアする必要があります。
* S Flag (bit 18): Indicates whether the advertised bandwidth can be switched. When the Signal Type can be switched, S MUST be set; when the Signal Type cannot be switched, S MUST be cleared.
* Sフラグ（ビット18）：アドバタイズされた帯域幅を切り替えることができるかどうかを示します。信号タイプを切り替えることができる場合、Sを設定する必要があります。信号タイプを切り替えることができない場合、Sをクリアする必要があります。
* The value 0 in both the T bit and S bit MUST NOT be used.
* TビットとSビットの両方で値0を使用してはなりません（MUST NOT）。
o TSG (3 bits): Tributary Slot Granularity. Used for the advertisement of the supported tributary slot granularity. The following values MUST be used:
o TSG（3ビット）：支流スロット粒度。サポートされるトリビュタリスロットの粒度のアドバタイズに使用されます。次の値を使用する必要があります。
* 0 - Ignored
* 0-無視
* 1 - 1.25 Gbps / 2.5 Gbps
* 2 - 2.5 Gbps only
* 2-2.5 Gbpsのみ
* 3 - 1.25 Gbps only
* 3-1.25 Gbpsのみ
* 4-7 - Reserved
* 4-7-予約済み
A value of 1 MUST be used on interfaces that are configured to support the fallback procedures defined in [G.798]. A value of 2 MUST be used on interfaces that only support 2.5 Gbps tributary slots, such as [RFC4328] interfaces. A value of 3 MUST be used on interfaces that are configured to only support 1.25 Gbps tributary slots. A value of 0 MUST be used for non-multiplexed Signal Types (i.e., a non-OTN client).
[G.798]で定義されているフォールバック手順をサポートするように構成されているインターフェースでは、値1を使用する必要があります。 [RFC4328]インターフェイスなど、2.5 Gbps支流スロットのみをサポートするインターフェイスでは、値2を使用する必要があります。 1.25 Gbpsのトリビュタリスロットのみをサポートするように構成されているインターフェイスでは、値3を使用する必要があります。値が0の場合は、多重化されていない信号タイプ（つまり、OTN以外のクライアント）を使用する必要があります。
o Res (3 bits): Reserved bits. MUST be set to 0 and ignored on receipt.
o Res（3ビット）：予約ビット。 0に設定し、受信時に無視する必要があります。
o Priority (8 bits): A bitmap used to indicate which priorities are being advertised. The bitmap is in ascending order, with the leftmost bit representing priority level 0 (i.e., the highest) and the rightmost bit representing priority level 7 (i.e., the lowest). A bit MUST be set (1) corresponding to each priority represented in the sub-TLV and MUST NOT be set (0) when the corresponding priority is not represented. At least one priority level MUST be advertised that, unless overridden by local policy, SHALL be at priority level 0.
o 優先度（8ビット）：アドバタイズされている優先度を示すために使用されるビットマップ。ビットマップは昇順で、左端のビットが優先度レベル0（つまり最高）を表し、右端のビットが優先度レベル7（つまり最低）を表します。ビットは、サブTLVで表される各優先度に対応して設定（1）されなければならず（MUST NOT）、対応する優先度が表されていない場合は設定（0）されてはなりません。ローカルポリシーによってオーバーライドされない限り、優先レベル0でなければならないことを少なくとも1つの優先レベルで通知する必要があります。
o Stage (8 bits): Each Stage field indicates a Signal Type in the multiplexing hierarchy used to transport the signal indicated in the Signal Type field. The number of Stage fields included in a sub-TLV MUST equal the value of the Num of stages field. The Stage fields MUST be ordered to match the data plane in ascending order (from the lowest order ODU to the highest order ODU). The values of the Stage field are the same as those defined for the Signal Type field. When the Num of stages field carries a 0, then the Stage and Padding fields MUST be omitted.
o ステージ（8ビット）：各ステージフィールドは、信号タイプフィールドで示された信号を転送するために使用される多重化階層の信号タイプを示します。サブTLVに含まれるステージフィールドの数は、ステージ数フィールドの値と等しくなければなりません。 Stageフィールドは、データプレーンと昇順で一致するように順序付けする必要があります（最低次のODUから最高次のODUまで）。 Stageフィールドの値は、Signal Typeフィールドに定義されている値と同じです。ステージ数フィールドが0の場合、ステージフィールドとパディングフィールドは省略しなければなりません。
* Example: For the ODU1->ODU2->OD3 hierarchy, the Signal Type field is set to ODU1 and two Stage fields are present, the first indicating ODU2 and the second ODU3 (server layer).
* 例：ODU1-> ODU2-> OD3階層の場合、Signal TypeフィールドはODU1に設定され、2つのStageフィールドが存在します。最初のフィールドはODU2を示し、2番目はODU3（サーバーレイヤー）を示します。
o Padding (variable): The Padding field is used to ensure the 32-bit alignment of stage fields. The length of the Padding field is always a multiple of 8 bits (1 byte). Its length can be calculated, in bytes, as: 4 - ( "value of Num of stages field" % 4). The Padding field MUST be set to a zero (0) value on transmission and MUST be ignored on receipt.
o パディング（変数）：パディングフィールドは、ステージフィールドの32ビットアラインメントを確保するために使用されます。 Paddingフィールドの長さは常に8ビット（1バイト）の倍数です。その長さは、バイト単位で次のように計算できます：4-（「ステージフィールド数」％4）。パディングフィールドは、送信時にゼロ（0）値に設定する必要があり、受信時には無視する必要があります。
o Unreserved ODUj (16 bits): This field indicates the Unreserved Bandwidth at a particular priority level. This field MUST be set to the number of ODUs at the indicated the Signal Type for a particular priority level. One field MUST be present for each bit set in the Priority field, and the fields are ordered to match the Priority field. Fields MUST NOT be present for priority levels that are not indicated in the Priority field.
o 予約されていないODUj（16ビット）：このフィールドは、特定の優先度レベルで予約されていない帯域幅を示します。このフィールドは、特定の優先度レベルの指定された信号タイプのODUの数に設定する必要があります。優先度フィールドで設定されたビットごとに1つのフィールドが存在する必要があり、フィールドは優先度フィールドと一致するように順序付けられます。優先度フィールドに示されていない優先度レベルのフィールドは存在してはなりません（MUST NOT）。
o Unreserved Padding (16 bits): The Padding field is used to ensure the 32-bit alignment of the Unreserved ODUj fields. When present, the Unreserved Padding field is 16 bits (2 bytes) long. When the number of priorities is odd, the Unreserved Padding field MUST be included. When the number of priorities is even, the Unreserved Padding MUST be omitted.
o Unreserved Padding（16 bits）：Paddingフィールドは、Unreserved ODUjフィールドの32ビットアライメントを保証するために使用されます。 Unreserved Paddingフィールドが存在する場合、その長さは16ビット（2バイト）です。優先順位の数が奇数の場合、Unreserved Paddingフィールドを含める必要があります。優先順位の数が偶数の場合、Unreserved Paddingは省略されなければなりません（MUST）。
o Unreserved Bandwidth (32 bits): This field indicates the Unreserved Bandwidth at a particular priority level. This field MUST be set to the bandwidth, in bytes/second in IEEE floating point format, available at the indicated Signal Type for a particular priority level. One field MUST be present for each bit set in the Priority field, and the fields are ordered to match the Priority field. Fields MUST NOT be present for priority levels that are not indicated in the Priority field.
o 予約されていない帯域幅（32ビット）：このフィールドは、特定の優先度レベルで予約されていない帯域幅を示します。このフィールドは、特定の優先度レベルの指定された信号タイプで利用可能なIEEE浮動小数点形式のバイト/秒の帯域幅に設定する必要があります。優先度フィールドで設定されたビットごとに1つのフィールドが存在する必要があり、フィールドは優先度フィールドと一致するように順序付けられます。優先度フィールドに示されていない優先度レベルのフィールドは存在してはなりません（MUST NOT）。
o Maximum LSP Bandwidth (32 bits): This field indicates the maximum bandwidth that can be allocated for a single LSP at a particular priority level. This field MUST be set to the maximum bandwidth, in bytes/second in IEEE floating point format, available to a single LSP at the indicated Signal Type for a particular priority level. One field MUST be present for each bit set in the Priority field, and the fields are ordered to match the Priority field. Fields MUST NOT be present for priority levels that are not indicated in the Priority field. The advertisement of the MAX LSP Bandwidth MUST take into account HO OPUk bit rate tolerance and be calculated according to the following formula:
o 最大LSP帯域幅（32ビット）：このフィールドは、特定の優先度レベルで単一のLSPに割り当てることができる最大帯域幅を示します。このフィールドは、特定の優先度レベルの指定された信号タイプで単一のLSPが使用できる最大帯域幅（IEEE浮動小数点形式のバイト/秒）に設定する必要があります。優先度フィールドで設定されたビットごとに1つのフィールドが存在する必要があり、フィールドは優先度フィールドと一致するように順序付けられます。優先度フィールドに示されていない優先度レベルのフィールドは存在してはなりません（MUST NOT）。 MAX LSP帯域幅の通知では、HO OPUkビットレートの許容値を考慮し、次の式に従って計算する必要があります。
* Max LSP BW = (# available TSs) * (ODTUk.ts nominal bit rate) * (1-HO OPUk bit rate tolerance)
* 最大LSP BW =（使用可能なTS数）*（ODTUk.ts公称ビットレート）*（1-HO OPUkビットレート許容値）
The examples in the following pages are not normative and are not intended to imply or mandate any specific implementation.
次のページの例は規範的ではなく、特定の実装を示唆または強制することを意図したものではありません。
This example shows how the MAX LSP Bandwidth fields of the ISCD are filled according to the evolving of the TE-Link bandwidth occupancy. In this example, an OTU4 link is considered, with supported priorities 0,2,4,7 and muxing hierarchy ODU1->ODU2->ODU3->ODU4.
この例は、TE-Link帯域幅占有率の変化に応じて、ISCDのMAX LSP帯域幅フィールドがどのように入力されるかを示しています。この例では、サポートされている優先度0、2、4、7、および多重化階層ODU1-> ODU2-> ODU3-> ODU4のOTU4リンクが検討されます。
At time T0, with the link completely free, the advertisement would be:
時間T0では、リンクが完全に解放されているため、広告は次のようになります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: MAX LSP Bandwidth Fields in the ISCD at T0
図5：T0におけるISCDのMAX LSP帯域幅フィールド
At time T1, an ODU3 at priority 2 is set up, so for priority 0, the MAX LSP Bandwidth is still equal to the ODU4 bandwidth, while for priorities from 2 to 7 (excluding the non-supported ones), the MAX LSP Bandwidth is equal to ODU3, as no more ODU4s are available and the next supported ODUj in the hierarchy is ODU3. The advertisement is updated as follows:
時間T1では、優先度2のODU3が設定されているため、優先度0の場合、最大LSP帯域幅はODU4帯域幅と同じですが、優先度2〜7（サポートされていないものを除く）の場合、最大LSP帯域幅これ以上ODU4は使用できず、階層で次にサポートされるODUjはODU3であるため、ODU3と同じです。広告は次のように更新されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: MAX LSP Bandwidth Fields in the ISCD at T1
図6：T1におけるISCDのMAX LSP帯域幅フィールド
At time T2, an ODU2 at priority 4 is set up. The first ODU3 has not been available since T1 as it was kept by the ODU3 LSP, while the second is no longer available and just 3 ODU2s are left in it. ODU2 is now the MAX LSP Bandwidth for priorities higher than 4. The advertisement is updated as follows:
時間Ｔ２で、優先度４のＯＤＵ２がセットアップされる。最初のODU3はODU3 LSPによって保持されていたため、T1以降使用できませんでしたが、2番目のODU3は使用できなくなり、3つのODU2が残っています。 ODU2は、4より高い優先度の最大LSP帯域幅になりました。広告は次のように更新されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SwCap=OTN_TDM | Encoding = 12 | Reserved (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 = 100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 = 40 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 = 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 = 10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Capability Specific Information |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: MAX LSP Bandwidth Fields in the ISCD at T2
図7：T2におけるISCDのMAX LSP帯域幅フィールド
In this example, an interface with tributary slot type 1.25 Gbps and fallback procedure enabled is considered (TS granularity=1). It supports the simple ODU1->ODU2->ODU3 hierarchy and priorities 0 and 3. Suppose that in this interface, the ODU3 Signal Type can be both switched or terminated, the ODU2 can only be terminated, and the ODU1 can only be switched. Please note that since the ODU1 is not being advertised to support ODU0, the value of its TSG field is "ignored" (TS granularity=0). For the advertisement of the capabilities of such an interface, a single ISCD is used. Its format is as follows:
この例では、トリビュタリスロットタイプが1.25 Gbpsで、フォールバック手順が有効になっているインターフェイスが検討されています（TS粒度= 1）。これは、単純なODU1-> ODU2-> ODU3階層と優先度0および3をサポートします。このインターフェースで、ODU3信号タイプは両方とも切り替えまたは終了でき、ODU2は終了のみ、ODU1は切り替えのみが可能であるとします。 ODU1はODU0をサポートするようにアドバタイズされていないため、そのTSGフィールドの値は「無視される」（TS粒度= 0）ことに注意してください。このようなインターフェースの機能の広告には、単一のISCDが使用されます。その形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |0|1| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |1|0| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 0 |1|1| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: T, S, and TS Granularity Utilization
図8：T、S、およびTSの粒度使用率
In this example, two interfaces with homogeneous hierarchies but different tributary slot types are considered. The first one supports an [RFC4328] interface (TS granularity=2) while the second one supports a G.709-2012 interface with fallback procedure disabled (TS granularity=3). Both support the ODU1->ODU2->ODU3 hierarchy and priorities 0 and 3. Suppose that in this interface, the ODU3 Signal Type can be both switched or terminated, the ODU2 can only be terminated, and the ODU1 can only be switched. For the advertisement of the capabilities of such interfaces, two different ISCDs are used. The format of their SCSIs is as follows:
この例では、階層が同種であるが、支流スロットタイプが異なる2つのインターフェイスが検討されます。 1つ目は[RFC4328]インターフェイス（TS粒度= 2）をサポートし、2つ目はフォールバック手順が無効（TS粒度= 3）のG.709-2012インターフェイスをサポートします。どちらもODU1-> ODU2-> ODU3階層と優先度0および3をサポートします。このインターフェースでは、ODU3信号タイプは両方とも切り替えまたは終端でき、ODU2は終端のみ、ODU1は切り替えのみが可能であるとします。このようなインターフェースの機能のアドバタイズには、2つの異なるISCDが使用されます。 SCSIのフォーマットは次のとおりです。
SCSI of ISCD 1 -- TS granularity=2
ISCD 1のSCSI-TS粒度= 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |0|1| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |1|0| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 0 |1|1| 2 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Utilization of Different TS Granularities -- ISCD 1
図9：さまざまなTS粒度の利用-ISCD 1
SCSI of ISCD 2 -- TS granularity=3
ISCD 2のSCSI-TS粒度= 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |0|1| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 | Unres ODU1 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |1|0| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 | Unres ODU2 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 0 |1|1| 3 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 | Unres ODU3 at Prio 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Utilization of Different TS Granularities -- ISCD 2
図10：さまざまなTS粒度の利用-ISCD 2
Hierarchies with the same muxing tree but with different exported TS granularity MUST be considered as non-homogenous hierarchies. This is the case in which an H-LSP and the client LSP are terminated on the same egress node. What can happen is that a loose Explicit Route Object (ERO) is used at the hop where the signaled LSP is nested into the Hierarchical-LSP (H-LSP) (penultimate hop of the LSP).
多重化ツリーが同じであるが、エクスポートされたTS粒度が異なる階層は、不均一な階層と見なされなければなりません（MUST）。これは、H-LSPとクライアントLSPが同じ出口ノードで終端している場合です。発生する可能性があるのは、シグナリングされたLSPがHierarchical-LSP（H-LSP）（LSPの最後から2番目のホップ）にネストされるホップでルーズエクスプリシットルートオブジェクト（ERO）が使用されることです。
In the following figure, node C receives a loose ERO from A; the ERO goes towards node E, and node C must choose between the ODU2 H-LSP on if1 or the one on if2. In this case, the H-LSP on if1 exports a TS=1.25 Gbps, and the H-LSP on if2 exports a TS=2.5 Gbps; because the service LSP being signaled needs a 1.25 Gbps tributary slot, only the H-LSP on if1 can be used to reach node E. For further details, please see Section 3.2 of [RFC7096].
次の図では、ノードCがAから緩いEROを受信しています。 EROはノードEに向かい、ノードCはif1のODU2 H-LSPまたはif2のO-LSPのどちらかを選択する必要があります。この場合、if1のH-LSPはTS = 1.25 Gbpsをエクスポートし、if2のH-LSPはTS = 2.5 Gbpsをエクスポートします。シグナリングされるサービスLSPには1.25 Gbpsのトリビュタリスロットが必要であるため、ノードEに到達するために使用できるのはif1のH-LSPだけです。詳細については、[RFC7096]のセクション3.2をご覧ください。
ODU0-LSP
..........................................................+
| |
| ODU2-H-LSP |
| +-------------------------------+
| | |
+--+--+ +-----+ +-----+ if1 +-----+ +-----+
| | OTU3 | | OTU3 | |---------| |---------| |
| A +------+ B +------+ C | if2 | D | | E |
| | | | | |---------| |---------| |
+-----+ +-----+ +-----+ +-----+ +-----+
... Service LSP
--- H-LSP
Figure 11: Example of Service LSP and H-LSP Terminating on the Same Node
図11：同じノードで終了するサービスLSPとH-LSPの例
In this example, the advertisement of an ODUflex->ODU3 hierarchy is shown. In the case of ODUflex advertisement, the MAX LSP Bandwidth needs to be advertised, and in some cases, information about the Unreserved Bandwidth could also be useful. The amount of Unreserved Bandwidth does not give a clear indication of how many ODUflex LSPs can be set up either at the MAX LSP Bandwidth or at different rates, as it gives no information about the spatial allocation of the free TSs.
この例では、ODUflex-> ODU3階層の通知が表示されます。 ODUflexアドバタイズメントの場合、MAX LSP帯域幅をアドバタイズする必要があり、場合によっては、予約されていない帯域幅に関する情報も役立つことがあります。予約されていない帯域幅の量は、無料のTSの空間割り当てに関する情報を提供しないため、最大LSP帯域幅または異なるレートで設定できるODUflex LSPの数を明確に示しません。
An indication of the amount of Unreserved Bandwidth could be useful during the path computation process, as shown in the following example. Suppose there are two TE-Links (A and B) with MAX LSP Bandwidth equal to 10 Gbps each. In the case where 50 Gbps of Unreserved Bandwidth are available on Link A, 10 Gbps on Link B, and 3 ODUflex LSPs of 10 Gbps each have to be restored, for sure only one can be restored along Link B, and it is probable, but not certain, that two of them can be restored along Link A. The T, S, and TSG fields are not relevant to this example (filled with Xs).
次の例に示すように、予約されていない帯域幅の量の表示は、パス計算プロセス中に役立ちます。 MAX LSP帯域幅がそれぞれ10 Gbpsに等しい2つのTEリンク（AおよびB）があるとします。リンクAで50 Gbpsの予約されていない帯域幅、リンクBで10 Gbps、およびそれぞれ10 Gbpsの3つのODUflex LSPを復元する必要がある場合、リンクBに沿って復元できるのは1つだけであり、その可能性が高いです。確かではありませんが、2つはリンクAに沿って復元できます。T、S、およびTSGフィールドは、この例（Xで埋められています）には関係ありません。
In the case of ODUflex advertisement, the Type 2 Bandwidth sub-TLV is used.
ODUflexアドバタイズメントの場合、タイプ2帯域幅サブTLVが使用されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 72 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S. type=ODUflex| #stages= 1 |X|X|X X X|0 0 0| Priority(8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: ODUflex Advertisement
図12：ODUflexアドバタイズメント
Suppose there is 1 OTU4 component link supporting single-stage muxing of ODU1, ODU2, ODU3, and ODUflex, the supported hierarchy can be summarized in a tree as in the following figure. For the sake of simplicity, we also assume that only priorities 0 and 3 are supported. The T, S, and TSG fields are not relevant to this example (filled with Xs).
ODU1、ODU2、ODU3、およびODUflexの単一ステージの多重化をサポートする1つのOTU4コンポーネントリンクがあるとすると、サポートされる階層は、次の図のようにツリーに要約できます。簡単にするために、優先度0と3のみがサポートされていると仮定します。 T、S、およびTSGフィールドは、この例には関係ありません（Xで埋められています）。
ODU1 ODU2 ODU3 ODUflex
\ \ / /
\ \ / /
\ \/ /
ODU4
The related SCSIs are as follows:
関連するSCSIは次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 =40 | Unres ODU1 at Prio 3 =40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =10 | Unres ODU2 at Prio 3 =10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S. type=ODUflex| #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Single-Stage Muxing
図13：シングルステージMUタイプ
Suppose there is 1 OTU4 component link with muxing capabilities as shown in the following figure:
次の図に示すように、多重化機能を持つ1つのOTU4コンポーネントリンクがあるとします。
ODU2 ODU0 ODUflex ODU0
\ / \ /
| |
ODU3 ODU2
\ /
\ /
\ /
\ /
ODU4
Considering only supported priorities 0 and 3, the advertisement is composed by the following Bandwidth sub-TLVs (T and S fields are not relevant to this example and filled with Xs):
サポートされる優先度0と3のみを考慮すると、アドバタイズは次の帯域幅サブTLVで構成されます（TおよびSフィールドはこの例には関係なく、Xで埋められます）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |X|X| 1 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =10 | Unres ODU2 at Prio 3 =10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =8 | Unres ODU2 at Prio 3 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =64 | Unres ODU0 at Prio 3 =64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 (Unres/MAX-var) | Length = 24 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S.type=ODUflex | #stages= 2 |X|X| 0 |0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 0 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth at priority 3 =100 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 0 =10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAX LSP Bandwidth at priority 3 =10 Gbps |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Multi-Stage Muxing -- Unbundled Link
図14：マルチステージマルチプレクサ-バンドルされていないリンク
In this example, 2 OTU4 component links with the same supported TS granularity and homogeneous muxing hierarchies are considered. The following muxing capabilities trees are supported:
この例では、サポートされている同じTS粒度と均一な多重化階層を持つ2つのOTU4コンポーネントリンクが検討されます。次の多重化機能ツリーがサポートされています。
Component Link#1 Component Link#2
ODU2 ODU0 ODU2 ODU0
\ / \ /
| |
ODU3 ODU3
| |
ODU4 ODU4
Considering only supported priorities 0 and 3, the advertisement is as follows (the T, S, and TSG fields are not relevant to this example and filled with Xs):
サポートされる優先度0と3のみを考慮すると、アドバタイズは次のようになります（T、S、およびTSGフィールドはこの例には関係なく、Xで埋められます）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =2 | Unres ODU4 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =4 | Unres ODU3 at Prio 3 =4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =16 | Unres ODU2 at Prio 3 =16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =128 | Unres ODU0 at Prio 3 =128 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Multi-Stage Muxing -- Bundled Links
図15：マルチステージの多重化-バンドルされたリンク
In this example, 2 OTU4 component links with the same supported TS granularity and non-homogeneous muxing hierarchies are considered. The following muxing capabilities trees are supported:
この例では、サポートされている同じTS細分性と不均一な多重化階層を持つ2つのOTU4コンポーネントリンクが考慮されます。次の多重化機能ツリーがサポートされています。
Component Link#1 Component Link#2
ODU2 ODU0 ODU1 ODU0
\ / \ /
| |
ODU3 ODU2
| |
ODU4 ODU4
Considering only supported priorities 0 and 3, the advertisement uses two different ISCDs, one for each hierarchy (the T, S, and TSG fields are not relevant to this example and filled with Xs). In the following figure, the SCSI of each ISCD is shown:
サポートされている優先度0と3のみを考慮して、アドバタイズメントは2つの異なるISCDを使用します。1つは階層ごとに1つです（T、S、およびTSGフィールドはこの例には関係なく、Xで埋められます）。次の図に、各ISCDのSCSIを示します。
SCSI of ISCD 1 -- Component Link#1
ISCD 1のSCSI-コンポーネントリンク＃1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU3 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU3 at Prio 0 =2 | Unres ODU3 at Prio 3 =2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =8 | Unres ODU2 at Prio 3 =8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU3 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =64 | Unres ODU0 at Prio 3 =64 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Multi-Stage Muxing -- Non-Homogeneous Hierarchies -- ISCD 1
図16：マルチステージの多重化-非均質階層-ISCD 1
SCSI of ISCD 2 -- Component Link#2
ISCD 2のSCSI-Component Link＃2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU4 | #stages= 0 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU4 at Prio 0 =1 | Unres ODU4 at Prio 3 =1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU2 | #stages= 1 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU2 at Prio 0 =10 | Unres ODU2 at Prio 3 =10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU1 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU1 at Prio 0 =40 | Unres ODU1 at Prio 3 =40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 (Unres-fix) | Length = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sig type=ODU0 | #stages= 2 |X|X|X X X|0 0 0|1|0|0|1|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stage#1=ODU2 | Stage#2=ODU4 | Padding (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unres ODU0 at Prio 0 =80 | Unres ODU0 at Prio 3 =80 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Multi-Stage Muxing -- Non-Homogeneous Hierarchies -- ISCD 2
図17：マルチステージの多重化-非均質階層-ISCD 2
This document does not introduce OSPF scalability issues with respect to existing GMPLS encoding and does not require any modification to flooding frequency. Moreover, the design of the encoding has been carried out taking into account bandwidth optimization, in particular: o Only unreserved and MAX LSP Bandwidth related to supported priorities are advertised.
このドキュメントでは、既存のGMPLSエンコーディングに関するOSPFスケーラビリティの問題は紹介されておらず、フラッディング頻度を変更する必要はありません。さらに、エンコーディングの設計は、特に帯域幅の最適化を考慮して行われました。oサポートされている優先順位に関連する予約されていない最大LSP帯域幅のみがアドバタイズされます。
o For fixed containers, only the number of available containers is advertised instead of the available bandwidth in order to use only 16 bits per container instead of 32 (as per former GMPLS encoding).
o 固定コンテナーの場合、32の代わりにコンテナーごとに16ビットのみを使用するために、利用可能な帯域幅の代わりに利用可能なコンテナーの数のみがアドバタイズされます（以前のGMPLSエンコーディングに従って）。
In order to further reduce the amount of data advertised it is RECOMMENDED to bundle component links with homogeneous hierarchies as described in [RFC4201] and illustrated in Section 5.6.
アドバタイズされるデータの量をさらに削減するために、[RFC4201]で説明され、セクション5.6で示されているように、コンポーネントリンクを同種の階層にバンドルすることをお勧めします。
All implementations of this document MAY also support advertisement as defined in [RFC4203]. When nodes support both the advertisement method in [RFC4203] and the one in this document, implementations MUST support the configuration of which advertisement method is followed. The choice of which is used is based on policy and beyond the scope of this document. This enables nodes following each method to identify similar supporting nodes and compute paths using only the appropriate nodes.
このドキュメントのすべての実装は、[RFC4203]で定義されている広告もサポートする場合があります。ノードが[RFC4203]のアドバタイズメントメソッドとこのドキュメントのアドバタイズメントメソッドの両方をサポートする場合、実装は、どのアドバタイズメントメソッドに従うかの設定をサポートする必要があります。どちらを使用するかは、ポリシーに基づいており、このドキュメントの範囲外です。これにより、各メソッドに従うノードは、適切なノードのみを使用して、同様のサポートノードを識別し、パスを計算できます。
This document extends [RFC4203]. As with [RFC4203], it specifies the contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for Shortest Path First (SPF) computation or normal routing, the extensions specified here have no direct effect on IP routing. Tampering with GMPLS TE LSAs may have an effect on the underlying transport (optical and/or Synchronous Optical Network - Synchronous Digital Hierarchy (SONET-SDH) network. [RFC3630] notes that the security mechanisms described in [RFC2328] apply to Opaque LSAs carried in OSPFv2. An analysis of the security of OSPF is provided in [RFC6863] and applies to the extensions to OSPF as described in this document. Any new mechanisms developed to protect the transmission of information carried in Opaque LSAs will also automatically protect the extensions defined in this document.
このドキュメントは[RFC4203]を拡張します。 [RFC4203]と同様に、OSPFv2の不透明LSAの内容を指定します。 Opaque LSAはShortest Path First（SPF）の計算や通常のルーティングには使用されないため、ここで指定された拡張はIPルーティングに直接影響しません。 GMPLS TE LSAの改ざんは、基盤となるトランスポート（光および/または同期光ネットワーク-同期デジタル階層（SONET-SDH）ネットワーク）に影響を与える可能性があります。[RFC2630]で説明されているセキュリティメカニズムは、運ばれる不透明LSA OSPFのセキュリティの分析は[RFC6863]で提供されており、このドキュメントで説明されているように、OSPFの拡張機能に適用されます。OpaqueLSAで伝送される情報の送信を保護するために開発された新しいメカニズムは、定義された拡張機能も自動的に保護しますこのドキュメントで。
Please refer to [RFC5920] for details on security threats; defensive techniques; monitoring, detection, and reporting of security attacks; and requirements.
セキュリティの脅威の詳細については、[RFC5920]を参照してください。防御技術;セキュリティ攻撃の監視、検出、報告。と要件。
IANA has made the following assignment in the "Switching Types" section of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters" registry located at <http://www.iana.org/assignments/gmpls-sig-parameters>:
IANAは、<http://www.iana.org/assignments/gmpls-sig-parameters>にある「Generalized Multi-Protocol Label Switching（GMPLS）Signaling Parameters」レジストリの「Switching Types」セクションで次の割り当てを行いました：
Value Name Reference
--------- -------------------------- ----------
110 OTN-TDM capable [RFC7138]
The same type of modification has been applied to the IANA-GMPLS-TC-MIB at <https://www.iana.org/assignments/ianagmplstc-mib>, where the value:
同じタイプの変更が、<https://www.iana.org/assignments/ianagmplstc-mib>のIANA-GMPLS-TC-MIBに適用されています。
OTN-TDM (110), -- Time-Division-Multiplex OTN-TDM capable
OTN-TDM（110）、-時分割多重OTN-TDM対応
has been added to the IANAGmplsSwitchingTypeTC ::= TEXTUAL-CONVENTION
syntax list.
This document defines 2 new sub-TLVs that are carried in Interface Switching Capability Descriptors [RFC4203] with the Signal Type OTN-TDM. Each sub-TLV includes a 16-bit type identifier (the T-field). The same T-field values are applicable to the new sub-TLV.
このドキュメントでは、信号タイプOTN-TDMのインターフェイススイッチング機能記述子[RFC4203]で伝送される2つの新しいサブTLVを定義します。各サブTLVには、16ビットのタイプ識別子（Tフィールド）が含まれています。同じTフィールド値が新しいサブTLVに適用されます。
IANA has created and will maintain a new sub-registry, the "Types for sub-TLVs of OTN-TDM SCSI (Switching Capability Specific Information)" registry under the "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry, see <http://www.iana.org/assignments/ospf-traffic-eng-tlvs>, with the sub-TLV types as follows:
IANAは、「Open Shortest Path First（OSPF）Traffic Engineering TLVs」レジストリの下の「OTN-TDM SCSI（Switching Capability Specific Information）のサブTLVのタイプ」レジストリを作成し、維持します。<を参照してください。 http://www.iana.org/assignments/ospf-traffic-eng-tlvs>、サブTLVタイプは次のとおりです。
Value Sub-TLV Reference
--------- -------------------------- ----------
0 Reserved [RFC7138]
1 Unreserved Bandwidth for [RFC7138]
fixed containers
2 Unreserved/MAX Bandwidth for [RFC7138]
flexible containers
3-65535 Unassigned
Types are to be assigned via Standards Action as defined in [RFC5226].
タイプは、[RFC5226]で定義されている標準アクションを介して割り当てられます。
Diego Caviglia Ericsson Via E. Melen, 77 Genova Italy EMail: diego.caviglia@ericsson.com
ディエゴカビリアエリクソンVia E. Melen、77 Genova Italyメール：diego.caviglia@ericsson.com
Dan Li Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China EMail: danli@huawei.com
Dan l IH UAは技術禁止の日であり、ギャングの長い地区は非常に現実的です。518129P.R.中国のメール：Shan Li@Huawei.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
Khuzema Pithewan Infinera Corporation 140 Caspian CT. Sunnyvale, CA USA EMail: kpithewan@infinera.com
Khuzema Pithewan Infinera Corporation 140カスピ海CT。米国カリフォルニア州サニーベールEメール：kpithewan@infinera.com
Xiaobing Zi Huawei Technologies EMail: zixiaobing@huawei.com
ξAoBing Z IH UAはテクノロジーメールです：子供の頃から、@ Huawei.com
Francesco Fondelli Ericsson EMail: francesco.fondelli@ericsson.com
Francesco Fondelli Ericsson Eメール：francesco.fondelli@ericsson.com
Marco Corsi EMail: corsi.marco@gmail.com
マルココルシメール：Corsi.marco@gmail.com
Eve Varma Alcatel-Lucent EMail: eve.varma@alcatel-lucent.com
Eve Varma Alcatel-Lucentメール：eve.varma@alcatel-lucent.com
Jonathan Sadler Tellabs EMail: jonathan.sadler@tellabs.com Lyndon Ong Ciena EMail: lyong@ciena.com
ジョナサンサドラーテラブスメール：jonathan.sadler@tellabs.comリンドンオンシエナメール：lyong@ciena.com
Ashok Kunjidhapatham EMail: akunjidhapatham@infinera.com
Ashok Kunjidhapatham Eメール：akunjidhapatham@infinera.com
Snigdho Bardalai EMail: sbardalai@infinera.com
穏やかな吟遊詩人へのメール：shvardalaiinfinera.com
Steve Balls EMail: Steve.Balls@metaswitch.com
Steve Balls EMail：Steve.Balls@metaswitch.com
Jonathan Hardwick EMail: Jonathan.Hardwick@metaswitch.com
ジョナサンハードウィックメール：Jonathan.Hardwick@metaswitch.com
Xihua Fu EMail: fu.xihua@zte.com.cn
ξ画f uメール：Vice。Refine @中特.com。Talent
Cyril Margaria EMail: cyril.margaria@nsn.com
Cyril Margaria Eメール：cyril.margaria@nsn.com
Malcolm Betts EMail: Malcolm.betts@zte.com.cn
Malcolm Betts Eメール：Malcolm.betts@zte.com.cn
The authors would like to thank Fred Gruman and Lou Berger for their valuable comments and suggestions.
著者は、貴重なコメントと提案をしてくれたFred GrumanとLou Bergerに感謝します。
[G.709-2012] ITU-T, "Interface for the optical transport network", Recommendation G.709/Y.1331, February 2012.
[G.709-2012] ITU-T、「光トランスポートネットワークのインターフェイス」、勧告G.709 / Y.1331、2012年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630] Katz、D.、Kompella、K。、およびD. Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、2003年9月。
[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月。
[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月。
[G.798] ITU-T, "Characteristics of optical transport network hierarchy equipment functional blocks", Recommendation G.798, December 2012.
[G.798] ITU-T、「Characteristics of Optical Transport Network Hierarchical Equipment Functional Blocks」、勧告G.798、2012年12月。
[G.805] ITU-T, "Generic functional architecture of transport networks", Recommendation G.805, March 2000.
[G.805] ITU-T、「トランスポートネットワークの汎用機能アーキテクチャ」、勧告G.805、2000年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[RFC6163] Lee, Y., Bernstein, G., 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.、Bernstein、G。、およびW. Imajuku、「GMPLSおよびパス計算要素（PCE）の波長切り替え光ネットワーク（WSON）の制御のフレームワーク」、RFC 6163、2011年4月。
[RFC6566] Lee, Y., Bernstein, G., Li, D., and G. Martinelli, "A Framework for the Control of Wavelength Switched Optical Networks (WSONs) with Impairments", RFC 6566, March 2012.
[RFC6566] Lee、Y.、Bernstein、G.、Li、D。、およびG. Martinelli、「障害のある波長スイッチ光ネットワーク（WSON）の制御のフレームワーク」、RFC 6566、2012年3月。
[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6863, March 2013.
[RFC6863] Hartman、S。、およびD. Zhang、「Analysis of OSPF Security Using the Keying and Authentication for Routing Protocols（KARP）Design Guide」、RFC 6863、2013年3月。
[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月。
[RFC7096] Belotti, S., Grandi, P., Ceccarelli, D., Ed., Caviglia, D., and F. Zhang, "Evaluation of Existing GMPLS Encoding against G.709v3 Optical Transport Networks (OTNs)", RFC 7096, January 2014.
[RFC7096] Belotti、S.、Grandi、P.、Ceccarelli、D.、Ed。、Caviglia、D。、およびF. Zhang、「G.709v3光トランスポートネットワーク（OTN）に対する既存のGMPLSエンコーディングの評価」、RFC 7096、2014年1月。
[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, March 2014.
[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、 2014年3月。
Authors' Addresses
著者のアドレス
Daniele Ceccarelli (editor) Ericsson Via E.Melen 77 Genova - Erzelli Italy
Daniele Ceccarelli（編集者）エリクソンVia E.Melen 77ジェノア-Erzelliイタリア
EMail: daniele.ceccarelli@ericsson.com
Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China
fa too Zhang hu AはテクノロジーF3-5-br＆Dセンターであり、hu Aは基本禁止日であり、地区は非常に現実的です518129 P.R. China
Phone: +86-755-28972912
EMail: zhangfatai@huawei.com
Sergio Belotti Alcatel-Lucent Via Trento, 30 Vimercate Italy
セルジオベロッティアルカテルルーセントVia Trento、30ヴィメルカーテイタリア
EMail: sergio.belotti@alcatel-lucent.com
Rajan Rao Infinera Corporation 140, Caspian CT. Sunnyvale, CA-94089 USA
Rajan Rao Infinera Corporation 140、カスピ海CT。サニーベール、CA-94089米国
EMail: rrao@infinera.com
John E. Drake Juniper
じょｈん え。 Ｄらけ じゅにぺｒ
EMail: jdrake@juniper.net