Internet Engineering Task Force (IETF) H. Zheng
Request for Comments: 9730 Y. Lin
Category: Informational Huawei Technologies
ISSN: 2070-1721 Y. Zhao
China Mobile
Y. Xu
CAICT
D. Beller
Nokia
March 2025
Generalized Multiprotocol Label Switching (GMPLS) control allows each network element (NE) to perform local resource discovery, routing, and signaling in a distributed manner.
一般化されたマルチプロトコルラベルスイッチング（GMPLS）制御により、各ネットワーク要素（NE）は、分散方法でローカルリソースの発見、ルーティング、シグナリングを実行できます。
The advancement of software-defined transport networking technology enables a group of NEs to be managed through centralized controller hierarchies. This helps to tackle challenges arising from multiple domains, vendors, and technologies. An example of such a centralized architecture is the Abstraction and Control of Traffic-Engineered Networks (ACTN) controller hierarchy, as described in RFC 8453.
ソフトウェア定義の輸送ネットワーキングテクノロジーの進歩により、NESグループを集中コントローラー階層を介して管理できるようになります。これは、複数のドメイン、ベンダー、テクノロジーから生じる課題に取り組むのに役立ちます。このような集中アーキテクチャの例は、RFC 8453で説明されているように、トラフィックエンジニアリングネットワーク（ACTN）コントローラー階層の抽象化と制御です。
Both the distributed and centralized control planes have their respective advantages and should complement each other in the system, rather than compete. This document outlines how the GMPLS distributed control plane can work together with a centralized controller system in a transport network.
分散型および集中化されたコントロールプレーンの両方には、それぞれの利点があり、競合するのではなく、システムで互いに補完する必要があります。このドキュメントでは、GMPLS分散コントロールプレーンが輸送ネットワーク内の集中コントローラーシステムと連携する方法を概説しています。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9730.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9730で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Abbreviations
3. Overview
3.1. Overview of GMPLS Control Plane
3.2. Overview of Centralized Controller System
3.3. GMPLS Control Interworking with a Centralized Controller
System
4. Discovery Options
4.1. LMP
5. Routing Options
5.1. OSPF-TE
5.2. IS-IS-TE
5.3. NETCONF/RESTCONF
6. Path Computation
6.1. Controller-Based Path Computation
6.2. Constraint-Based Path Computing in GMPLS Control
6.3. Path Computation Element (PCE)
7. Signaling Options
7.1. RSVP-TE
8. Interworking Scenarios
8.1. Topology Collection and Synchronization
8.2. Multi-Domain Service Provisioning
8.3. Multi-Layer Service Provisioning
8.3.1. Multi-Layer Path Computation
8.3.2. Cross-Layer Path Creation
8.3.3. Link Discovery
8.4. Recovery
8.4.1. Span Protection
8.4.2. LSP Protection
8.4.3. Single-Domain LSP Restoration
8.4.4. Multi-Domain LSP Restoration
8.4.5. Fast Reroute
8.5. Controller Reliability
9. Manageability Considerations
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] extends MPLS to support different classes of interfaces and switching capabilities such as Time-Division Multiplex Capable (TDM), Lambda Switch Capable (LSC), and Fiber-Switch Capable (FSC). Each network element (NE) running a GMPLS control plane collects network information from other NEs and supports service provisioning through signaling in a distributed manner. A more generic description of traffic-engineering networking information exchange can be found in [RFC7926].
一般化されたマルチプロトコルラベルスイッチング（GMPLS）[RFC3945]は、MPLSを拡張して、さまざまなクラスのインターフェイスとスイッチング機能をサポートし、時間帯マルチプレックス対応（TDM）、ラムダスイッチ対応（LSC）、繊維スイッチ能力（FSC）などのスイッチング機能をサポートします。GMPLSコントロールプレーンを実行する各ネットワーク要素（NE）は、他のNESからネットワーク情報を収集し、分散方法でシグナリングを通じてサービスプロビジョニングをサポートします。トラフィックエンジニアリングネットワーキング情報交換のより一般的な説明は、[RFC7926]にあります。
On the other hand, Software-Defined Networking (SDN) technologies have been introduced to control the transport network centrally. Centralized controllers can collect network information from each node and provision services on corresponding nodes. One example is the Abstraction and Control of Traffic-Engineered Networks (ACTN) [RFC8453], which defines a hierarchical architecture with the Provisioning Network Controller (PNC), Multi-Domain Service Coordinator (MDSC), and Customer Network Controller (CNC) as centralized controllers for different network abstraction levels. A PCE-based approach has been proposed in [RFC7491]: Application-Based Network Operations (ABNO).
一方、輸送ネットワークを中央に制御するために、ソフトウェア定義ネットワーク（SDN）テクノロジーが導入されています。集中コントローラーは、各ノードからネットワーク情報を収集し、対応するノードでサービスを提供できます。1つの例は、プロビジョニングネットワークコントローラー（PNC）、マルチドメインサービスコーディネーター（MDSC）、およびカスタマーネットワークコントローラー（CNC）を使用して、異なるネットワーク抽象化レベルの顧客ネットワークコントローラー（CNC）を備えた階層アーキテクチャを定義するトラフィックエンジニアリングネットワーク（ACTN）[RFC8453]の抽象化と制御です。[RFC7491]：アプリケーションベースのネットワーク操作（ABNO）でPCEベースのアプローチが提案されています。
GMPLS can be used to control network elements (NEs) in such centralized controller architectures. A centralized controller may support GMPLS-enabled domains and communicate with a GMPLS-enabled domain where the GMPLS control plane handles service provisioning from ingress to egress. In this scenario, the centralized controller sends a request to the entry node and does not need to configure all NEs along the path within the domain from ingress to egress, thus leveraging the GMPLS control plane. This document describes how the GMPLS control plane interworks with a centralized controller system in a transport network.
GMPLは、このような集中コントローラーアーキテクチャでネットワーク要素（NE）を制御するために使用できます。集中コントローラーは、GMPLS対応ドメインをサポートし、GMPLS対応ドメインと通信する場合があります。GMPLSコントロールプレーンは、イングレスから出口へのサービスプロビジョニングを処理します。このシナリオでは、集中コントローラーがエントリノードにリクエストを送信し、ドメイン内のパスに沿ってすべてのNEをイングレスから出口まで構成する必要はないため、GMPLSコントロールプレーンを活用します。このドキュメントでは、GMPLSがトランスポートネットワーク内の集中コントローラーシステムを制御する方法をコントロールする方法について説明します。
The following abbreviations are used in this document.
このドキュメントでは、次の略語が使用されています。
ACTN:
Actn：
Abstraction and Control of Traffic-Engineered Networks [RFC8453]
トラフィックエンジニアリングネットワークの抽象化と制御[RFC8453]
APS:
APS:
Automatic Protection Switching [G.808.1]
自動保護スイッチング[G.808.1]
BRPC:
BRPC：
Backward Recursive PCE-Based Computation [RFC5441]
後方再帰PCEベースの計算[RFC5441]
CSPF:
CSPF：
Constrained Shortest Path First
最初に最短パスを制約します
DoS:
DoS:
Denial of Service
サービス拒否
E2E:
E2E：
end to end
エンドツーエンド
ERO:
ERO:
Explicit Route Object
明示的なルートオブジェクト
FA:
FA:
Forwarding Adjacency
隣接する転送
FRR:
FRR:
Fast Reroute
速いルーウト
GMPLS:
GMPLS：
Generalized Multiprotocol Label Switching [RFC3945]
一般化されたマルチプロトコルラベルスイッチング[RFC3945]
H-PCE:
h-pce：
Hierarchical PCE [RFC8685]
階層PCE [RFC8685]
IDS:
IDS:
Intrusion Detection System
侵入検知システム
IGP:
IGP:
Interior Gateway Protocol
インテリアゲートウェイプロトコル
IoCs:
IOCS：
Indicators of Compromise [RFC9424]
妥協の指標[RFC9424]
IPS:
IPS:
Intrusion Prevention System
侵入防止システム
IS-IS:
is-is：
Intermediate System to Intermediate System
中間システムから中間システム
LMP:
LMP:
Link Management Protocol [RFC4204]
リンク管理プロトコル[RFC4204]
LSP:
LSP:
Label Switched Path
ラベルスイッチ付きパス
LSP-DB:
LSP-DB：
LSP Database
LSPデータベース
MD:
MD:
multi-domain
マルチドメイン
MDSC:
MDSC：
Multi-Domain Service Coordinator [RFC8453]
マルチドメインサービスコーディネーター[RFC8453]
MITM:
MITM：
Man in the Middle
真ん中の男
ML:
ML:
multi-layer
多層
MPI:
MPI:
MDSC to PNC Interface [RFC8453]
MDSCからPNCインターフェイス[RFC8453]
NE:
NE:
network element
ネットワーク要素
NETCONF:
NetConf：
Network Configuration Protocol [RFC6241]
ネットワーク構成プロトコル[RFC6241]
NMS:
NMS:
Network Management System
ネットワーク管理システム
OSPF:
OSPF：
Open Shortest Path First
最初に最短パスを開きます
PCC:
PCC:
Path Computation Client [RFC4655]
パス計算クライアント[RFC4655]
PCE:
PCE:
Path Computation Element [RFC4655]
パス計算要素[RFC4655]
PCEP:
PCEP：
PCE Communication Protocol [RFC5440]
PCE通信プロトコル[RFC5440]
PCEP-LS:
pcep-ls：
Link State PCEP [PCEP-LS]
リンク状態pcep [pcep-ls]
PLR:
PLR:
Point of Local Repair
ローカル修理のポイント
PNC:
PNC:
Provisioning Network Controller [RFC8453]
プロビジョニングネットワークコントローラー[RFC8453]
RSVP:
お返事お願いします：
Resource Reservation Protocol
リソース予約プロトコル
SBI:
SBI:
Southbound Interface
南行きのインターフェース
SDN:
SDN:
Software-Defined Networking
ソフトウェア定義のネットワーク
TE:
TE:
Traffic Engineering
交通工学
TED:
TED:
Traffic Engineering Database
トラフィックエンジニアリングデータベース
TLS:
TLS:
Transport Layer Security [RFC8446]
輸送層のセキュリティ[RFC8446]
VNTM:
Vntm：
Virtual Network Topology Manager [RFC5623]
仮想ネットワークトポロジマネージャー[RFC5623]
This section provides an overview of the GMPLS control plane, centralized controller systems, and their interactions in transport networks.
このセクションでは、GMPLSコントロールプレーン、集中コントローラーシステム、および輸送ネットワークでの相互作用の概要を説明します。
A transport network [RFC5654] is a server-layer network designed to provide connectivity services for client-layer connectivity. This setup allows client traffic to be carried seamlessly across the server-layer network resources.
Transport Network [RFC5654]は、クライアント層の接続に接続サービスを提供するように設計されたサーバー層ネットワークです。このセットアップにより、クライアントトラフィックをサーバーレイヤーネットワークリソース全体にシームレスに運ぶことができます。
GMPLS separates the control plane and the data plane to support time-division, wavelength, and spatial switching, which are significant in transport networks. For the NE level control in GMPLS, each node runs a GMPLS control plane instance. Functionalities such as service provisioning, protection, and restoration can be performed via GMPLS communication among multiple NEs. At the same time, the GMPLS control plane instance can also collect information about node and link resources in the network to construct the network topology and compute routing paths for serving service requests.
GMPLSは、制御プレーンとデータプレーンを分離して、輸送ネットワークで重要な時間帯、波長、空間スイッチングをサポートします。GMPLSのNEレベル制御の場合、各ノードはGMPLSコントロールプレーンインスタンスを実行します。サービスの提供、保護、修復などの機能は、複数のNE間のGMPLS通信を介して実行できます。同時に、GMPLSコントロールプレーンインスタンスは、ネットワーク内のノードに関する情報とリンクリソースを収集して、ネットワークトポロジを構築し、サービスリクエストを提供するためのルーティングパスを計算することもできます。
Several protocols have been designed for the GMPLS control plane [RFC3945], including link management [RFC4204], signaling [RFC3471], and routing [RFC4202] protocols. The GMPLS control plane instances applying these protocols communicate with each other to exchange resource information and establish LSPs. In this way, GMPLS control plane instances in different nodes in the network have the same view of the network topology and provision services based on local policies.
リンク管理[RFC4204]、シグナル伝達[RFC3471]、ルーティング[RFC4202]プロトコルなど、GMPLS制御プレーン[RFC3945]用にいくつかのプロトコルが設計されています。これらのプロトコルを適用するGMPLS制御プレーンインスタンスは、互いに通信してリソース情報を交換し、LSPを確立します。このようにして、ネットワーク内のさまざまなノードのGMPLS制御プレーンインスタンスは、ローカルポリシーに基づいてネットワークトポロジとプロビジョニングサービスについて同じビューを持っています。
With the development of SDN technologies, a centralized controller architecture has been introduced to transport networks. One example architecture can be found in ACTN [RFC8453]. In such systems, a controller is aware of the network topology and is responsible for provisioning incoming service requests.
SDN Technologiesの開発により、輸送ネットワークに集中コントローラーアーキテクチャが導入されました。1つの例アーキテクチャは、Actn [RFC8453]にあります。このようなシステムでは、コントローラーはネットワークトポロジを認識しており、着信サービスリクエストのプロビジョニングを担当しています。
Multiple hierarchies of controllers are designed at different levels to implement different functions. This kind of architecture enables multi-vendor, multi-domain, and multi-technology control. For example, a higher-level controller coordinates several lower-level controllers controlling different domains for topology collection and service provisioning. Vendor-specific features can be abstracted between controllers, and a standard API (e.g., generated from RESTCONF [RFC8040] / YANG [RFC7950]) may be used.
コントローラーの複数の階層は、さまざまな機能を実装するためにさまざまなレベルで設計されています。この種のアーキテクチャにより、マルチベンダー、マルチドメイン、マルチテクノロジー制御が可能になります。たとえば、高レベルのコントローラーは、トポロジコレクションとサービスのプロビジョニングのために異なるドメインを制御するいくつかの低レベルのコントローラーを調整します。ベンダー固有の機能はコントローラー間で抽象化でき、標準API（例えば、retsconf [rfc8040] / yang [rfc7950]から生成された）を使用できます。
Besides GMPLS and the interactions among the controller hierarchies, it is also necessary for the controllers to communicate with the network elements. Within each domain, GMPLS control can be applied to each NE. The bottom-level centralized controller can act as an NE to collect network information and initiate LSPs. Figure 1 shows an example of GMPLS interworking with centralized controllers (ACTN terminologies are used in the figure).
GMPLSとコントローラー階層間の相互作用に加えて、コントローラーがネットワーク要素と通信することも必要です。各ドメイン内で、GMPLSコントロールを各NEに適用できます。ボトムレベルの中央コントローラーは、ネットワーク情報を収集してLSPを開始するためのNEとして機能します。図1は、集中コントローラーとの相互作用のGMPLSの例を示しています（図ではACTN用語が使用されています）。
+-------------------+
| Orchestrator |
| (MDSC) |
+-------------------+
^ ^ ^
| | |
+-------------+ | +--------------+
| |RESTCONF/YANG modules |
V V V
+-------------+ +-------------+ +-------------+
|Controller(N)| |Controller(G)| |Controller(G)|
| (PNC) | | (PNC) | | (PNC) |
+-------------+ +-------------+ +-------------+
^ ^ ^ ^ ^ ^
| | | | | |
NETCONF| |PCEP NETCONF| |PCEP NETCONF| |PCEP
/YANG | | /YANG | | /YANG | |
V V V V V V
.----------. Inter- .----------. Inter- .----------.
/ \ domain / \ domain / \
| | link | LMP | link | LMP |
| |======| OSPF-TE |======| OSPF-TE |
| | | RSVP-TE | | RSVP-TE |
\ / \ / \ /
`----------` `----------` `----------`
Non-GMPLS domain 1 GMPLS domain 2 GMPLS domain 3
Figure 1: Example of GMPLS/non-GMPLS Interworking with Controllers
図1：コントローラーとの互換性のあるGMPLS/非GMPLSの例
Controller(N):
コントローラー（n）：
A domain controller controlling a non-GMPLS domain
非GMPLSドメインを制御するドメインコントローラー
Controller(G):
コントローラー（g）：
A domain controller controlling a GMPLS domain
GMPLSドメインを制御するドメインコントローラー
Figure 1 shows the scenario with two GMPLS domains and one non-GMPLS domain. This system supports the interworking among non-GMPLS domains, GMPLS domains, and the controller hierarchies.
図1は、2つのGMPLSドメインと1つの非GMPLSドメインを備えたシナリオを示しています。このシステムは、非GMPLSドメイン、GMPLSドメイン、およびコントローラー階層間の相互作用をサポートします。
For domain 1, the network elements were not enabled with GMPLS, so the control is purely from the controller, via Network Configuration Protocol (NETCONF) [RFC6241] with a YANG data model [RFC7950] and/or PCE Communication Protocol (PCEP) [RFC5440].
ドメイン1の場合、ネットワーク要素はGMPLで有効にされていなかったため、コントロールは純粋にコントローラーからのものであり、Yangデータモデル[RFC7950]および/またはPCE通信プロトコル（PCEP）[RFC5440]を使用して、ネットワーク構成プロトコル（netConf）[RFC6241]を介してです。
For domains 2 and 3:
ドメイン2および3の場合：
* Each domain has the GMPLS control plane enabled at the physical network level. The Provisioning Network Controller (PNC) can exploit GMPLS capabilities implemented in the domain to listen to the IGP routing protocol messages (for example, OSPF Link State Advertisements (LSAs)) that the GMPLS control plane instances are disseminating into the network and thus learn the network topology. For path computation in the domain with the PNC implementing a PCE, Path Computation Clients (PCCs) (e.g., NEs, other controllers/PCEs) use PCEP to ask the PNC for a path and get replies. The Multi-Domain Service Coordinator (MDSC) communicates with PNCs using, for example, Representational State Transfer (REST) / RESTCONF based on YANG data models. As a PNC has learned its domain topology, it can report the topology to the MDSC. When a service arrives, the MDSC computes the path and coordinates PNCs to establish the corresponding LSP segment.
* 各ドメインには、物理ネットワークレベルで有効になっているGMPLSコントロールプレーンがあります。プロビジョニングネットワークコントローラー（PNC）は、ドメインに実装されたGMPLS機能を活用して、IGPルーティングプロトコルメッセージ（たとえば、OSPFリンク状態広告（LSA））をリッキングすることができます。PNCがPCEを実装するドメインでのパス計算の場合、PATH計算クライアント（PCCS）（NES、その他のコントローラー/PCESなど）を使用してPCEPを使用してPNCにパスを要求し、返信を取得します。マルチドメインサービスコーディネーター（MDSC）は、たとえば、Yangデータモデルに基づいた表現状態転送（REST） / RESTCONFを使用してPNCと通信します。PNCがドメイントポロジを学んだため、トポロジーをMDSCに報告できます。サービスが到着すると、MDSCはパスを計算し、PNCを調整して対応するLSPセグメントを確立します。
* Alternatively, the NETCONF protocol can be used to retrieve topology information utilizing the YANG module in [RFC8795] and the technology-specific YANG module augmentations required for the specific network technology. The PNC can retrieve topology information from any NE (the GMPLS control plane instance of each NE in the domain has the same topological view), construct the topology of the domain, and export an abstract view to the MDSC. Based on the topology retrieved from multiple PNCs, the MDSC can create a topology graph of the multi-domain network and can use it for path computation. To set up a service, the MDSC can exploit the YANG module in [YANG-TE] together with the technology-specific YANG module augmentations.
* あるいは、NetConfプロトコルを使用して、[RFC8795]のYangモジュールを利用したトポロジ情報と、特定のネットワークテクノロジーに必要な技術固有のYangモジュールの増強を取得できます。PNCは、任意のNE（ドメイン内の各NEのGMPLSコントロールプレーンインスタンスが同じトポロジビューを持っている）からトポロジー情報を取得し、ドメインのトポロジーを構築し、MDSCに抽象ビューをエクスポートできます。複数のPNCから取得されたトポロジに基づいて、MDSCはマルチドメインネットワークのトポロジグラフを作成し、パス計算に使用できます。サービスをセットアップするには、MDSCは技術固有のYangモジュールの増強とともに[Yang-Te]のYangモジュールを悪用できます。
This document focuses on the interworking between GMPLS and the centralized controller system, including:
このドキュメントでは、GMPLSと中央コントローラーシステム間の相互作用に焦点を当てています。
* the interworking between the GMPLS domains and the centralized controllers (including the orchestrator, if it exists) controlling the GMPLS domains and
* GMPLSドメインとGMPLSドメインを制御する集中コントローラー（オーケストレーターを含む）と集中コントローラー（オーケストレーターを含む）との間の相互作用と
* the interworking between a non-GMPLS domain (which is controlled by a centralized controller system) and a GMPLS domain, through the controller hierarchy architecture.
* コントローラー階層アーキテクチャを介して、非GMPLSドメイン（集中コントローラーシステムによって制御されている）とGMPLSドメインとの相互作用。
For convenience, this document uses the following terminologies for the controller and the orchestrator:
便利なため、このドキュメントでは、コントローラーとオーケストレーターに次の用語を使用しています。
Controller(G):
コントローラー（g）：
A domain controller controlling a GMPLS domain (the Controller(G) of the GMPLS domains 2 and 3 in Figure 1)
GMPLSドメインを制御するドメインコントローラー（図1のGMPLSドメイン2および3のコントローラー（g））
Controller(N):
コントローラー（n）：
A domain controller controlling a non-GMPLS domain (the Controller(N) of the non-GMPLS domain 1 in Figure 1)
非GMPLSドメインを制御するドメインコントローラー（図1の非GMPLSドメイン1のコントローラー（n））
H-Controller(G):
Hコントローラー（g）：
A domain controller controlling the higher-layer GMPLS domain, in the context of multi-layer networks
マルチ層ネットワークのコンテキストで、高層GMPLSドメインを制御するドメインコントローラー
L-Controller(G):
L-Controller（g）：
A domain controller controlling the lower-layer GMPLS domain, in the context of multi-layer networks
多層ネットワークのコンテキストで、低層GMPLSドメインを制御するドメインコントローラー
H-Controller(N):
Hコントローラー（n）：
A domain controller controlling the higher-layer non-GMPLS domain, in the context of multi-layer networks
多層ネットワークのコンテキストで、高層の非GMPLSドメインを制御するドメインコントローラー
L-Controller(N):
L-Controller（n）：
A domain controller controlling the lower-layer non-GMPLS domain, in the context of multi-layer networks
マルチ層ネットワークのコンテキストで、低層の非GMPLSドメインを制御するドメインコントローラー
Orchestrator(MD):
オーケストレーター（MD）：
An orchestrator used to orchestrate the multi-domain networks
マルチドメインネットワークを調整するために使用されるオーケストレーター
Orchestrator(ML):
オーケストレーター（ML）：
An orchestrator used to orchestrate the multi-layer networks
マルチレイヤーネットワークを調整するために使用されるオーケストレーター
In GMPLS control, the link connectivity must be verified between each pair of nodes. In this way, link resources, which are fundamental resources in the network, are discovered by both ends of the link.
GMPLS制御では、ノードの各ペア間でリンク接続を検証する必要があります。このようにして、ネットワーク内の基本的なリソースであるリンクリソースは、リンクの両端によって発見されます。
The Link Management Protocol (LMP) [RFC4204] runs between nodes and manages TE links. In addition to the setup and maintenance of control channels, LMP can be used to verify the data link connectivity and correlate the link properties.
リンク管理プロトコル（LMP）[RFC4204]は、ノードの間を実行し、TEリンクを管理します。制御チャネルのセットアップとメンテナンスに加えて、LMPを使用してデータリンク接続を検証し、リンクプロパティを相関させることができます。
In GMPLS control, link state information is flooded within the network as defined in [RFC4202]. Each node in the network can build the network topology according to the flooded link state information. Routing protocols such as OSPF-TE [RFC4203] and IS-IS-TE [RFC5307] have been extended to support different interfaces in GMPLS.
GMPLS制御では、[RFC4202]で定義されているように、リンク状態情報がネットワーク内であふれています。ネットワーク内の各ノードは、浸水したリンク状態情報に従ってネットワークトポロジを構築できます。OSPF-TE [RFC4203]やIS-IS-TE [RFC5307]などのルーティングプロトコルは、GMPLのさまざまなインターフェイスをサポートするために拡張されています。
In a centralized controller system, the centralized controller can be placed in the GMPLS network and passively receives the IGP information flooded in the network. In this way, the centralized controller can construct and update the network topology.
集中コントローラーシステムでは、集中コントローラーをGMPLSネットワークに配置し、ネットワークに浸水したIGP情報を受動的に受信できます。このようにして、集中コントローラーはネットワークトポロジを構築および更新できます。
OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions have been defined in [RFC4203] to enable the capability of link state information for the GMPLS network. Based on this work, OSPF has been extended to support technology-specific routing. The routing protocols for the Optical Transport Network (OTN), Wavelength Switched Optical Network (WSON), and optical flexi-grid networks are defined in [RFC7138], [RFC7688], and [RFC8363], respectively.
OSPF-TEは、[RFC3630]のTEネットワーク用に導入されています。OSPF拡張機能は[RFC4203]で定義されており、GMPLSネットワークのリンク状態情報の機能を有効にしています。この作業に基づいて、OSPFは技術固有のルーティングをサポートするために拡張されました。光輸送ネットワーク（OTN）、波長切り替え光ネットワーク（WSON）、および光学柔軟性ネットワークのルーティングプロトコルは、それぞれ[RFC7138]、[RFC7688]、および[RFC8363]で定義されています。
IS-IS-TE is introduced for TE networks in [RFC5305], is extended to support GMPLS routing functions [RFC5307], and has been updated [RFC7074] to support the latest GMPLS switching capability and Types fields.
IS-IS-TEは、[RFC5305]のTEネットワークに導入され、GMPLSルーティング関数[RFC5307]をサポートするために拡張され、最新のGMPLSスイッチング機能とタイプフィールドをサポートするために[RFC7074]を更新しました。
NETCONF [RFC6241] and RESTCONF [RFC8040] protocols are originally used for network configuration. These protocols can also utilize topology-related YANG modules, such as those in [RFC8345] and [RFC8795]. These protocols provide a powerful mechanism for the notification (in addition to the provisioning and monitoring) of topology changes to the client.
NetConf [RFC6241]およびRESTCONF [RFC8040]プロトコルは、元々ネットワーク構成に使用されます。これらのプロトコルは、[RFC8345]や[RFC8795]のようなトポロジ関連のYangモジュールを利用することもできます。これらのプロトコルは、クライアントへのトポロジの変更の通知（プロビジョニングと監視に加えて）の強力なメカニズムを提供します。
Once a controller learns the network topology, it can utilize the available resources to serve service requests by performing path computation. Due to abstraction, the controllers may not have sufficient information to compute the optimal path. In this case, the controller can interact with other controllers by sending, for example, YANG-based path computation requests [PATH-COMP] or PCEP to compute a set of potential optimal paths; and then, based on its constraints, policy, and specific knowledge (e.g., cost of access link), the controller can choose the more feasible path for end-to-end (E2E) service path setup.
コントローラーがネットワークトポロジを学習すると、パス計算を実行することにより、利用可能なリソースを利用してサービスリクエストを提供できます。抽象化により、コントローラーは最適なパスを計算するのに十分な情報を持っていない場合があります。この場合、コントローラーは、たとえばYangベースのパス計算要求[Path-Comp]またはPCEPを送信して、潜在的な最適パスのセットを計算することにより、他のコントローラーと対話できます。そして、その制約、ポリシー、および特定の知識（アクセスリンクのコストなど）に基づいて、コントローラーはエンドツーエンド（E2E）サービスパスのセットアップのためのより実現可能なパスを選択できます。
Path computation is one of the key objectives in various types of controllers. In the given architecture, it is possible for different components that have the capability to compute the path.
パス計算は、さまざまなタイプのコントローラーの重要な目的の1つです。指定されたアーキテクチャでは、パスを計算する機能を持つさまざまなコンポーネントが可能です。
In GMPLS control, a routing path may be computed by the ingress node [RFC3473] based on the ingress node Traffic Engineering Database (TED). In this case, constraint-based path computation is performed according to the local policy of the ingress node.
GMPLSコントロールでは、イングレスノードトラフィックエンジニアリングデータベース（TED）に基づいて、ルーティングパスをイングレスノード[RFC3473]によって計算できます。この場合、制約ベースのパス計算は、イングレスノードのローカルポリシーに従って実行されます。
The PCE was first introduced in [RFC4655] as a functional component that offers services for computing paths within a network. In [RFC5440], path computation is achieved using the TED, which maintains a view of the link resources in the network. The introduction of the PCE has significantly improved the quality of network planning and offline computation. However, there is a potential risk that the computed path may be infeasible when there is a diversity requirement, as a stateless PCE lacks knowledge about previously computed paths.
PCEは、ネットワーク内のコンピューティングパスのためのサービスを提供する機能コンポーネントとして[RFC4655]で最初に導入されました。[RFC5440]では、ネットワーク内のリンクリソースのビューを維持するTEDを使用してパス計算が達成されます。PCEの導入により、ネットワーク計画とオフライン計算の品質が大幅に向上しました。ただし、ステートレスPCEには以前に計算されたパスに関する知識がないため、多様性要件がある場合、計算されたパスが実行不可能である可能性がある潜在的なリスクがあります。
To address this issue, a stateful PCE has been proposed in [RFC8231]. Besides the TED, an additional LSP Database (LSP-DB) is introduced to archive each LSP computed by the PCE. This way, the PCE can easily determine the relationship between the computing path and former computed paths. In this approach, the PCE provides computed paths to the PCC, and then the PCC decides which path is deployed and when it is to be established.
この問題に対処するために、ステートフルPCEが[RFC8231]で提案されています。TEDに加えて、追加のLSPデータベース（LSP-DB）が導入され、PCEによって計算された各LSPがアーカイブされます。このようにして、PCEはコンピューティングパスと以前の計算パスとの関係を簡単に決定できます。このアプローチでは、PCEはPCCへの計算パスを提供し、PCCはどのパスが展開され、いつ確立されるかを決定します。
With PCE-initiated LSPs [RFC8281], the PCE can trigger the PCC to perform setup, maintenance, and teardown of the PCE-initiated LSP under the stateful PCE model. This would allow a dynamic network that is centrally controlled and deployed.
PCE開始LSP [RFC8281]を使用すると、PCEはPCCをトリガーして、Stateful PCEモデルの下でPCE開始LSPのセットアップ、メンテナンス、および分解を実行できます。これにより、中央に制御および展開される動的ネットワークが可能になります。
In a centralized controller system, the PCE can be implemented within the centralized controller. The centralized controller then calculates paths based on its local policies. Alternatively, the PCE can be located outside of the centralized controller. In this scenario, the centralized controller functions as a PCC and sends a path computation request to the PCE using the PCEP. A reference architecture for this can be found in [RFC7491].
集中コントローラーシステムでは、PCEを中央コントローラー内で実装できます。次に、集中コントローラーは、ローカルポリシーに基づいてパスを計算します。または、PCEは中央コントローラーの外側に配置できます。このシナリオでは、集中コントローラーはPCCとして機能し、PCEPを使用してPCEにパス計算要求を送信します。このための参照アーキテクチャは[RFC7491]にあります。
Signaling mechanisms are used to set up LSPs in GMPLS control. Messages are sent hop by hop between the ingress node and the egress node of the LSP to allocate labels. Once the labels are allocated along the path, the LSP setup is accomplished. Signaling protocols such as Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3473] have been extended to support different interfaces in GMPLS.
シグナル伝達メカニズムは、GMPLSコントロールでLSPをセットアップするために使用されます。メッセージは、イングレスノードとLSPの出口ノードの間のホップでホップが送信され、ラベルを割り当てます。パスに沿ってラベルが割り当てられると、LSPセットアップが達成されます。リソース予約プロトコルなどのシグナル伝達プロトコル - トラフィックエンジニアリング（RSVP -TE）[RFC3473]は、GMPLのさまざまなインターフェイスをサポートするために拡張されています。
RSVP-TE is introduced in [RFC3209] and extended to support GMPLS signaling in [RFC3473]. Several label formats are defined for a generalized label request, a generalized label, a suggested label, and label sets. Based on [RFC3473], RSVP-TE has been extended to support technology-specific signaling. The RSVP-TE extensions for the OTN, WSON, and optical flexi-grid network are defined in [RFC7139], [RFC7689], and [RFC7792], respectively.
RSVP-TEは[RFC3209]で導入され、[RFC3473]のGMPLSシグナル伝達をサポートするように拡張されました。一般化されたラベルリクエスト、一般化されたラベル、提案されたラベル、およびラベルセットに対して、いくつかのラベル形式が定義されています。[RFC3473]に基づいて、RSVP-TEは技術固有のシグナル伝達をサポートするために拡張されました。OTN、WSON、および光学柔軟性ネットワークのRSVP-TE拡張機能は、それぞれ[RFC7139]、[RFC7689]、および[RFC7792]で定義されています。
Topology information is necessary on both network elements and controllers. The topology on a network element is usually raw information, while the topology used by the controller can be either raw, reduced, or abstracted. Three different abstraction methods have been described in [RFC8453], and different controllers can select the corresponding method depending on the application.
ネットワーク要素とコントローラーの両方でトポロジ情報が必要です。ネットワーク要素のトポロジーは通常生の情報であり、コントローラーが使用するトポロジーは、生、削減、または抽象化される可能性があります。[RFC8453]で3つの異なる抽象化方法が説明されており、異なるコントローラーがアプリケーションに応じて対応する方法を選択できます。
When there are changes in the network topology, the impacted network elements need to report changes to all the other network elements, together with the controller, to sync up the topology information. The inter-NE synchronization can be achieved via protocols mentioned in Sections 4 and 5. The topology synchronization between NEs and controllers can either be achieved by routing protocols OSPF-TE/PCEP-LS in [PCEP-LS] or NETCONF protocol notifications with a YANG module.
ネットワークトポロジに変更がある場合、影響を受けたネットワーク要素は、トポロジ情報を同期するために、コントローラーとともに他のすべてのネットワーク要素に変更を報告する必要があります。NES間の同期は、セクション4および5で言及されたプロトコルを介して達成できます。NESとコントローラー間のトポロジー同期は、[PCEP-LS]のOSPF-TE/PCEP-LSをルーティングすることで達成できます。
Service provisioning can be deployed based on the topology information on controllers and network elements. Many methods have been specified for single-domain service provisioning, such as the PCEP and RSVP-TE methods.
サービスプロビジョニングは、コントローラーとネットワーク要素に関するトポロジー情報に基づいて展開できます。PCEPやRSVP-TEメソッドなど、単一ドメインサービスプロビジョニングには多くの方法が指定されています。
Multi-domain service provisioning would require coordination among the controller hierarchies. Given the service request, the end-to-end delivery procedure may include interactions at any level (i.e., interface) in the hierarchy of the controllers (e.g., MPI and SBI for ACTN). The computation for a cross-domain path is usually completed by controllers who have a global view of the topologies. Then the configuration is decomposed into lower-level controllers to configure the network elements to set up the path.
マルチドメインサービスプロビジョニングには、コントローラー階層間の調整が必要です。サービスリクエストを考えると、エンドツーエンドの配信手順には、コントローラーの階層（ACTNのMPIとSBIなど）の任意のレベル（つまり、インターフェイス）での相互作用が含まれる場合があります。クロスドメインパスの計算は、通常、トポロジーのグローバルビューを持つコントローラーによって完了します。次に、構成が低レベルのコントローラーに分解され、パスを設定するようにネットワーク要素を構成します。
A combination of centralized and distributed protocols may be necessary to interact between network elements and controllers. Several methods can be used to create the inter-domain path:
ネットワーク要素とコントローラーの間で相互作用するには、集中化されたプロトコルと分散プロトコルの組み合わせが必要になる場合があります。いくつかの方法を使用して、ドメイン間パスを作成できます。
1) With an end-to-end RSVP-TE session:
1) エンドツーエンドのRSVP-TEセッションで：
In this method, all the domains need to support the RSVP-TE protocol and thus need to be GMPLS domains. The Controller(G) of the source domain triggers the source node to create the end-to-end RSVP-TE session; and the assignment and distribution of the labels on the inter-domain links are done by the border nodes of each domain, using RSVP-TE protocol. Therefore, this method requires the interworking of RSVP-TE protocols between different domains.
この方法では、すべてのドメインがRSVP-TEプロトコルをサポートする必要があるため、GMPLSドメインである必要があります。ソースドメインのコントローラー（g）がソースノードをトリガーして、エンドツーエンドのRSVP-TEセッションを作成します。ドメイン間リンク上のラベルの割り当てと分布は、RSVP-TEプロトコルを使用して、各ドメインの境界ノードによって行われます。したがって、この方法では、異なるドメイン間のRSVP-TEプロトコルの相互作用が必要です。
There are two possible methods:
可能な方法は2つあります。
1.1) One single end-to-end RSVP-TE session:
1.1）1つのエンドツーエンドのRSVP-TEセッション：
In this method, an end-to-end RSVP-TE session from the source node to the destination node will be used to create the inter-domain path. A typical example would be the PCE initiation scenario, in which a PCE message (PCInitiate) is sent from the Controller(G) to the source node, triggering an RSVP procedure along the path. Similarly, the interaction between the controller and the source node of the source domain can be achieved by using the NETCONF protocol with corresponding YANG modules, and then it can be completed by running RSVP among the network elements.
この方法では、ソースノードから宛先ノードへのエンドツーエンドのRSVP-TEセッションを使用して、ドメイン間パスを作成します。典型的な例は、PCE開始シナリオであり、PCEメッセージ（PCInitiate）がコントローラー（g）からソースノードに送信され、パスに沿ってRSVP手順をトリガーします。同様に、ソースドメインのコントローラーとソースノード間の相互作用は、NetConfプロトコルを対応するYangモジュールを使用して実現でき、ネットワーク要素間でRSVPを実行することで完了できます。
1.2) LSP Stitching:
1.2）LSPステッチ：
The LSP stitching method defined in [RFC5150] can also create the E2E LSP. That is, when the source node receives an end-to-end path creation request (e.g., using PCEP or NETCONF protocol), the source node starts an end-to-end RSVP-TE session along the endpoints of each LSP segment (S-LSP) (refers to S-LSP in [RFC5150]) of each domain, to assign the labels on the inter-domain links between each pair of neighbor S-LSPs and to stitch the end-to-end LSP to each S-LSP. See Figure 2 as an example.
[RFC5150]で定義されているLSPステッチ方法は、E2E LSPも作成できます。つまり、ソースノードがエンドツーエンドのパス作成要求（PCEPまたはNetConfプロトコルを使用するなど）を受信すると、ソースノードは各LSPセグメント（S-LSP）のエンドポイントに沿ってエンドツーエンドのRSVP-TEセッションを開始します（各ドメインの各ドメインのラベルを獲得するために、各ドメインの隣接する隣接するペアのペアの隣接するドメアの範囲内のs-lspを参照します）各S-LSPへのエンドツーエンドLSP。例として図2を参照してください。
Note that the S-LSP in each domain can be either created by its Controller(G) in advance or created dynamically triggered by the end-to-end RSVP-TE session.
各ドメインのS-LSPは、コントローラー（g）によって事前に作成されるか、エンドツーエンドのRSVP-TEセッションによって動的にトリガーされるかのいずれかであることに注意してください。
+------------------------+
| Orchestrator(MD) |
+-----------+------------+
|
+---------------+ +------V-------+ +---------------+
| Controller(G) | | Controller(G)| | Controller(G) |
+-------+-------+ +------+-------+ +-------+-------+
| | |
+--------V--------+ +-------V--------+ +--------V--------+
|Client | | | | Client|
|Signal Domain 1| | Domain 2 | |Domain 3 Signal|
| | | | | | | |
|+-+-+ | | | | +-+-+|
|| | | +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ | | ||
|| | | | | | || || | | | | || || | | | | | ||
|| ******************************************************** ||
|| | | | | || || | | | | || || | | | | ||
|+---+ +--+ +--+| |+--+ +--+ +--+| |+--+ +--+ +---+|
+-----------------+ +----------------+ +-----------------+
| . . . . . . |
| .<-S-LSP 1->. .<- S-LSP 2 -->. .<-S-LSP 3->. |
| . . . . |
|-------------->.---->.------------->.---->.-------------->|
|<--------------.<----.<-------------.<----.<--------------|
| End-to-end RSVP-TE session for LSP stitching |
Figure 2: LSP Stitching
図2：LSPステッチ
2) Without an end-to-end RSVP-TE session:
2) エンドツーエンドのRSVP-TEセッションなし：
In this method, each domain can be a GMPLS domain or a non-GMPLS domain. Each controller (which may be a Controller(G) or a Controller(N)) is responsible for creating the path segment within its domain. The border node does not need to communicate with other border nodes in other domains for the distribution of labels on inter-domain links, so an end-to-end RSVP-TE session through multiple domains is not required, and the interworking of the RSVP-TE protocol between different domains is not needed.
この方法では、各ドメインはGMPLSドメインまたは非GMPLSドメインになります。各コントローラー（コントローラー（g）またはコントローラー（n））は、ドメイン内のパスセグメントを作成する責任があります。ボーダーノードは、ドメイン間リンク上のラベルの分布のために他のドメインの他の境界ノードと通信する必要がないため、複数のドメインを介したエンドツーエンドのRSVP-TEセッションは必要ありません。
Note that path segments in the source domain and the destination domain are "asymmetrical" segments, because the configuration of client signal mapping into the server-layer tunnel is needed at only one end of the segment, while configuration of the server-layer cross-connect is needed at the other end of the segment. See the example in Figure 3.
ソースドメインと宛先ドメインのパスセグメントは「非対称」セグメントであることに注意してください。なぜなら、セグメントの一方の端でサーバー層トンネルへのクライアント信号マッピングの構成が必要であり、セグメントのもう一方の端でサーバー層のクロスコネクトの構成が必要であるためです。図3の例を参照してください。
+------------------------+
| Orchestrator(MD) |
+-----------+------------+
|
+---------------+ +------V-------+ +---------------+
| Controller | | Controller | | Controller |
+-------+-------+ +------+-------+ +-------+-------+
| | |
+--------V--------+ +-------V--------+ +--------V--------+
|Client Domain 1| | Domain 2 | | Domain 3 Client|
|Signal | | | | Signal|
| | Server layer| | | | | |
| | tunnel | | | | | |
|+-+-+ ^ | | | | +-+-+|
|| | | +--+ |+--+| |+--+ +--+ +--+| |+--+ +--+ | | ||
|| | | | | || || || | | | | || || | | | | | ||
|| ******************************************************** ||
|| | | | | || . || | | | | || . || | | | | ||
|+---+ +--+ +--+| . |+--+ +--+ +--+| . |+--+ +--+ +---+|
+-----------------+ . +----------------+ . +-----------------+
. . . .
.<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->.
Figure 3: Example of an Asymmetrical Path Segment
図3：非対称パスセグメントの例
The PCEP / GMPLS protocols should support the creation of such asymmetrical segments.
PCEP / GMPLSプロトコルは、このような非対称セグメントの作成をサポートする必要があります。
Note also that mechanisms to assign the labels in the inter-domain links also need to be considered. There are two possible methods:
また、ドメイン間リンクにラベルを割り当てるメカニズムも考慮する必要があることに注意してください。可能な方法は2つあります。
2.1) Inter-domain labels assigned by NEs:
2.1）NESによって割り当てられたドメイン間ラベル：
The concept of a stitching label that allows stitching local path segments was introduced in [RFC5150] and [SPCE-ID], in order to form the inter-domain path crossing several different domains. It also describes the Backward Recursive PCE-Based Computation (BRPC) [RFC5441] and Hierarchical PCE (H-PCE) [RFC8685] PCInitiate procedure, i.e., the ingress node of each downstream domain assigns the stitching label for the inter-domain link between the downstream domain and its upstream neighbor domain; and this stitching label will be passed to the upstream neighbor domain by PCE protocol, which will be used for the path segment creation in the upstream neighbor domain.
ローカルパスセグメントをステッチするステッチラベルの概念は、[RFC5150]および[SPCE-ID]で導入され、いくつかの異なるドメインを横切るドメイン間パスを形成しました。また、後方再帰PCEベースの計算（BRPC）[RFC5441]および階層PCE（H-PCE）[RFC8685] PCINITIATEプロシージャ、つまり、各ダウンストリームドメインのイングレスノードは、下流ドメイン間のドメイン間のリンクにステッチラベルを割り当てます。また、このステッチラベルは、PCEプロトコルによって上流の近隣ドメインに渡されます。PCEプロトコルは、上流の隣接ドメインのパスセグメント作成に使用されます。
2.2) Inter-domain labels assigned by the controller:
2.2）コントローラーによって割り当てられたドメイン間ラベル：
If the resources of inter-domain links are managed by the Orchestrator(MD), each domain controller can provide to the Orchestrator(MD) the list of available labels (e.g., time slots if the OTN is the scenario) using topology-related YANG modules and specific technology-related extensions. Once the orchestrator(MD) has computed the E2E path, RSVP-TE or PCEP can be used in the different domains to set up the related segment tunnel consisting of information about inter-domain labels; for example, for PCEP, the label Explicit Route Object (ERO) can be included in the PCInitiate message to indicate the inter-domain labels so that each border node of each domain can configure the correct cross-connect within itself.
ドメイン間リンクのリソースがオーケストレーター（MD）によって管理されている場合、各ドメインコントローラーはオーケストレーター（MD）に利用可能なラベルのリストを提供できます（たとえば、OTNがシナリオである場合、時間スロット）トポロジー関連のYangモジュールと特定の技術関連の拡張を提供します。オーケストレーター（MD）がE2Eパスを計算すると、RSVP-TEまたはPCEPをさまざまなドメインで使用して、ドメイン間ラベルに関する情報からなる関連セグメントトンネルを設定できます。たとえば、PCEPの場合、ラベル明示的ルートオブジェクト（ERO）をPCInitiateメッセージに含めて、各ドメインの各ボーダーノードがそれ自体内で正しいクロスコネクトを構成できるように、ドメイン間ラベルを示すことができます。
GMPLS can interwork with centralized controller systems in multi-layer networks.
GMPLSは、マルチレイヤーネットワークの中央コントローラーシステムとインターワークできます。
+----------------+
|Orchestrator(ML)|
+------+--+------+
| | Higher-layer Network
| | .--------------------.
| | / \
| | +--------------+ | +--+ Link +--+ |
| +-->| H-Controller +----->| | |**********| | |
| +--------------+ | +--+ +--+ |
| \ . . /
| `--.------------.---`
| . .
| .---.------------.---.
| / . . \
| +--------------+ | +--+ +--+ +--+ |
+----->| L-Controller +----->| | ============== | |
+--------------+ | +--+ +--+ +--+ |
\ H-LSP /
`-------------------`
Lower-layer Network
Figure 4: GMPLS-controller Interworking in Multi-Layer Networks
図4：マルチ層ネットワークでのGMPLS-Controllerインターワーキング
An example with two layers of network is shown in Figure 4. In this example, the GMPLS control plane is enabled in at least one layer network (otherwise, it is out of the scope of this document) and interworks with the controller of its domain (H-Controller and L-Controller, respectively). The Orchestrator(ML) is used to coordinate the control of the multi-layer network.
ネットワークの2つのレイヤーを備えた例を図4に示します。この例では、GMPLSコントロールプレーンは、少なくとも1つのレイヤーネットワーク（そうでなければ、このドキュメントの範囲外です）で有効になり、ドメインのコントローラー（それぞれHコントローラーとLコントローラー）と相互作用します。オーケストレーター（ML）は、マルチレイヤーネットワークの制御を調整するために使用されます。
[RFC5623] describes three inter-layer path computation models and four inter-layer path control models:
[RFC5623]は、3つの層間パス計算モデルと4つの層間パス制御モデルについて説明します。
* 3 path computation models:
* 3パス計算モデル：
- Single PCE path computation model
- 単一のPCEパス計算モデル
- Multiple PCE path computation with inter-PCE communication model
- PCE間通信モデルを使用した複数のPCEパス計算
- Multiple PCE path computation without inter-PCE communication model
- PCE間通信モデルなしの複数のPCEパス計算
* 4 path control models:
* 4パス制御モデル：
- PCE Virtual Network Topology Manager (PCE-VNTM) cooperation model
- PCE仮想ネットワークトポロジマネージャー（PCE-VNTM）協力モデル
- Higher-layer signaling trigger model
- 高層シグナルトリガーモデル
- Network Management System VNTM (NMS-VNTM) cooperation model (integrated flavor)
- ネットワーク管理システムVNTM（NMS-VNTM）協力モデル（統合フレーバー）
- NMS-VNTM cooperation model (separate flavor)
- NMS-VNTM協力モデル（個別のフレーバー）
Section 4.2.4 of [RFC5623] also provides all the possible combinations of inter-layer path computation and inter-layer path control models.
[RFC5623]のセクション4.2.4は、層間パス計算と層間パス制御モデルのすべての可能な組み合わせも提供します。
To apply [RFC5623] in a multi-layer network with GMPLS-controller interworking, the H-Controller and the L-Controller can act as the PCE Hi and PCE Lo, respectively; and typically, the Orchestrator(ML) can act as a VNTM because it has the abstracted view of both the higher-layer and lower-layer networks.
[RFC5623]をGMPLS-Controllerインターワーキングを備えたマルチレイヤーネットワークに適用するには、H-ControllerとL-ControllerがそれぞれPCE HIおよびPCE LOとして機能します。通常、オーケストレーター（ML）は、高層ネットワークと低層ネットワークの両方の抽象化されたビューを持っているため、VNTMとして機能する可能性があります。
Table 1 shows all possible combinations of path computation and path control models in multi-layer network with GMPLS-controller interworking:
表1は、GMPLS-Controllerインターワーキングを備えたマルチレイヤーネットワークのパス計算モデルとパス制御モデルのすべての可能な組み合わせを示しています。
+======================+========+================+===============+
| Path computation / | Single | Multiple PCE | Multiple PCE |
| Path control | PCE | with inter-PCE | w/o inter-PCE |
+======================+========+================+===============+
| PCE-VNTM cooperation | N/A | Yes | Yes |
+----------------------+--------+----------------+---------------+
| Higher-layer | N/A | Yes | Yes |
| signaling trigger | | | |
+----------------------+--------+----------------+---------------+
| NMS-VNTM cooperation | N/A | Yes (1) | No (1) |
| (integrated flavor) | | | |
+----------------------+--------+----------------+---------------+
| NMS-VNTM cooperation | N/A | No (1) | Yes (1) |
| (separate flavor) | | | |
+----------------------+--------+----------------+---------------+
Table 1: Combinations of Path Computation and Path Control Models
表1：パス計算とパス制御モデルの組み合わせ
Note that:
ご了承ください：
* Since there is one PCE in each layer network, the path computation model "Single PCE path computation" is not applicable (N/A).
* 各レイヤーネットワークに1つのPCEがあるため、パス計算モデル「単一PCEパス計算」は適用されません（n/a）。
* For the other two path computation models "Multiple PCE with inter-PCE" and "Multiple PCE w/o inter-PCE", the possible combinations are the same as defined in [RFC5623]. More specifically:
* 他の2つのパス計算モデル「InterPCEを使用した複数のPCE」と「PCE w/o inter pceをw/oで複数のPCE」では、可能な組み合わせは[RFC5623]で定義されていると同じです。より具体的に：
- (1) The path control models "NMS-VNTM cooperation (integrated flavor)" and "NMS-VNTM cooperation (separate flavor)" are the typical models to be used in a multi-layer network with GMPLS-controller interworking. This is because, in these two models, the path computation is triggered by the NMS or VNTM. And in the centralized controller system, the path computation requests are typically from the Orchestrator(ML) (acts as VNTM).
- （1）パス制御モデル「NMS-VNTM協力（統合フレーバー）」および「NMS-VNTM協力（個別のフレーバー）」は、GMPLSコントローラーインターワーキングを備えたマルチレイヤーネットワークで使用される典型的なモデルです。これは、これら2つのモデルでは、パス計算がNMSまたはVNTMによってトリガーされるためです。中央コントローラーシステムでは、パス計算要求は通常、オーケストレーター（ML）からのものです（VNTMとして機能します）。
- For the other two path control models "PCE-VNTM cooperation" and "Higher-layer signaling trigger", the path computation is triggered by the NEs, i.e., the NE performs PCC functions. It is still possible to use these two models, although they are not the main methods.
- 他の2つのパス制御モデル「PCE-VNTM協力」および「高層シグナル伝達トリガー」の場合、PATH計算はNESによってトリガーされます。つまり、NEはPCC関数を実行します。これらの2つのモデルを使用することはまだ可能ですが、それらは主な方法ではありません。
In a multi-layer network, a lower-layer LSP in the lower-layer network can be created, which will construct a new link in the higher-layer network. Such a lower-layer LSP is called Hierarchical LSP, or H-LSP for short; see [RFC6107].
多層ネットワークでは、低層ネットワークの低層LSPを作成でき、これにより、高層ネットワークに新しいリンクが構築されます。このような低層LSPは、階層LSP、または略してH-LSPと呼ばれます。[RFC6107]を参照してください。
The new link constructed by the H-LSP can then be used by the higher-layer network to create new LSPs.
H-LSPによって構築された新しいリンクは、高層ネットワークによって使用されて新しいLSPを作成できます。
As described in [RFC5212], two methods are introduced to create the H-LSP: the static (pre-provisioned) method and the dynamic (triggered) method.
[RFC5212]で説明されているように、2つの方法が導入されており、H-LSP：静的（事前に分割された）メソッドと動的（トリガー）メソッドを作成します。
1) Static (pre-provisioned) method:
1) 静的（前処理）メソッド：
In this method, the H-LSP in the lower-layer network is created in advance. After that, the higher-layer network can create LSPs using the resource of the link constructed by the H-LSP.
この方法では、下層ネットワークのH-LSPが事前に作成されます。その後、高層ネットワークは、H-LSPによって構築されたリンクのリソースを使用してLSPを作成できます。
The Orchestrator(ML) is responsible to decide the creation of H-LSP in the lower-layer network if it acts as a VNTM. Then it requests the L-Controller to create the H-LSP via, for example, an MPI under the ACTN architecture.
オーケストレーター（ML）は、VNTMとして機能する場合、下層ネットワークでH-LSPの作成を決定する責任があります。次に、L-Controllerに、たとえばActnアーキテクチャの下でMPIを介してH-LSPを作成するように要求します。
If the lower-layer network is a GMPLS domain, the L-Controller(G) can trigger the GMPLS control plane to create the H-LSP. As a typical example, the PCInitiate message can be used for the communication between the L-Controller and the source node of the H-LSP. And the source node of the H-LSP can trigger the RSVP-TE signaling procedure to create the H-LSP, as described in [RFC6107].
低層ネットワークがGMPLSドメインである場合、L-Controller（G）はGMPLSコントロールプレーンをトリガーしてH-LSPを作成できます。典型的な例として、PCINITIATEメッセージは、l-lspのl-controllerとh-lspのソースノード間の通信に使用できます。また、H-LSPのソースノードは、[RFC6107]で説明されているように、RSVP-TEシグナル伝達手順をトリガーしてH-LSPを作成できます。
If the lower-layer network is a non-GMPLS domain, other methods may be used by the L-Controller(N) to create the H-LSP, which is out of scope of this document.
低層ネットワークが非GMPLSドメインである場合、L-controller（n）が他の方法を使用して、このドキュメントの範囲外のH-LSPを作成することができます。
2) Dynamic (triggered) method:
2) 動的（トリガー）メソッド：
In this method, the signaling of LSP creation in the higher-layer network will trigger the creation of H-LSP in the lower-layer network dynamically, if it is necessary. Therefore, both the higher-layer and lower-layer networks need to support the RSVP-TE protocol and thus need to be GMPLS domains.
この方法では、高層ネットワークでのLSP作成のシグナル伝達により、必要に応じて下層ネットワークでのH-LSPの作成が動的にトリガーされます。したがって、高層ネットワークと低層ネットワークの両方がRSVP-TEプロトコルをサポートする必要があるため、GMPLSドメインである必要があります。
In this case, after the cross-layer path is computed, the Orchestrator(ML) requests the H-Controller(G) for the cross-layer LSP creation. As a typical example, the MPI under the ACTN architecture could be used.
この場合、クロスレイヤーパスが計算された後、オーケストレーター（ML）は、クロスレイヤーLSP作成のHコントローラー（g）を要求します。典型的な例として、ACTNアーキテクチャのMPIを使用できます。
The H-Controller(G) can trigger the GMPLS control plane to create the LSP in the higher-layer network. As a typical example, the PCInitiate message can be used for the communication between the H-Controller(G) and the source node of the higher-layer LSP, as described in Section 4.3 of [RFC8282]. At least two sets of ERO information should be included to indicate the routes of higher-layer LSP and lower-layer H-LSP.
H-Controller（G）は、GMPLSコントロールプレーンをトリガーして、高層ネットワークにLSPを作成できます。典型的な例として、[RFC8282]のセクション4.3で説明されているように、PCINITIATEメッセージは、H-Controller（G）と高層LSPのソースノード間の通信に使用できます。高層LSPと低層H-LSPのルートを示すために、少なくとも2セットのERO情報を含める必要があります。
The source node of the higher-layer LSP follows the procedure defined in Section 4 of [RFC6001] to trigger the GMPLS control plane in both the higher-layer network and the lower-layer network to create the higher-layer LSP and the lower-layer H-LSP.
高層LSPのソースノードは、[RFC6001]のセクション4で定義されている手順に従って、高層ネットワークと低層ネットワークの両方でGMPLSコントロールプレーンをトリガーし、高層LSPと低層H-LSPを作成します。
On success, the source node of the H-LSP should report the information of the H-LSP to the L-Controller(G) via, for example, the PCRpt message.
成功すると、H-LSPのソースノードは、たとえばPCRPTメッセージを介してH-LSPの情報をLコントローラー（g）に報告する必要があります。
If the higher-layer network and the lower-layer network are under the same GMPLS control plane instance, the H-LSP can be a Forwarding Adjacency LSP (FA-LSP). Then the information of the link constructed by this FA-LSP can be advertised in the routing instance, so that the H-Controller can be aware of this new FA. [RFC4206] and the following updates to it (including [RFC6001] and [RFC6107]) describe the detailed extensions to support advertisement of an FA.
高層ネットワークと低層ネットワークが同じGMPLS制御プレーンインスタンスの下にある場合、H-LSPは転送隣接LSP（FA-LSP）になります。次に、このFA-LSPによって構築されたリンクの情報は、ルーティングインスタンスで宣伝することができ、H-Controllerがこの新しいFAを認識できるようにします。[RFC4206]およびそれへの次の更新（[RFC6001]および[RFC6107]を含む）は、FAの広告をサポートする詳細な拡張機能を説明しています。
If the higher-layer network and the lower-layer network are under separate GMPLS control plane instances or if one of the layer networks is a non-GMPLS domain, after an H-LSP is created in the lower-layer network, the link discovery procedure will be triggered in the higher-layer network to discover the information of the link constructed by the H-LSP. The LMP defined in [RFC4204] can be used if the higher-layer network supports GMPLS. The information of this new link will be advertised to the H-Controller.
高層ネットワークと低層ネットワークが個別のGMPLSコントロールプレーンインスタンスの下にある場合、またはレイヤーネットワークのいずれかが非GMPLSドメインである場合、H-LSPが低レイヤーネットワークで作成された後、リンク発見手順は高層ネットワークでトリガーされ、H-LSPによって構築されたリンクの情報を発見します。[RFC4204]で定義されたLMPは、高層ネットワークがGMPLをサポートしている場合に使用できます。この新しいリンクの情報は、H-Controllerに宣伝されます。
The GMPLS recovery functions are described in [RFC4426]. Span protection and end-to-end protection and restoration are discussed with different protection schemes and message exchange requirements. Related RSVP-TE extensions to support end-to-end recovery are described in [RFC4872]. The extensions in [RFC4872] include protection, restoration, preemption, and rerouting mechanisms for an end-to-end LSP. Besides end-to-end recovery, a GMPLS segment recovery mechanism is defined in [RFC4873], which also intends to be compatible with Fast Reroute (FRR) (see [RFC4090], which defines RSVP-TE extensions for the FRR mechanism, and [RFC8271], which describes the updates of the GMPLS RSVP-TE protocol for FRR of GMPLS TE-LSPs).
GMPLS回復関数は[RFC4426]で説明されています。スパンの保護とエンドツーエンドの保護と修復については、さまざまな保護スキームとメッセージ交換要件で説明されています。エンドツーエンドの回復をサポートするための関連RSVP-TE拡張は[RFC4872]で説明されています。[RFC4872]の拡張には、エンドツーエンドLSPの保護、回復、先制、および再ルーティングメカニズムが含まれます。エンドツーエンドの回復に加えて、GMPLSセグメントの回復メカニズムは[RFC4873]で定義されています。これは、FAST Reroute（FRR）と互換性があることも意図しています（FRRメカニズムのRSVP-TE拡張を定義する[RFC4090]を参照してください。gmpls te-lsps）。
Span protection refers to the protection of the link between two neighboring switches. The main protocol requirements include:
スパン保護とは、2つの隣接するスイッチ間のリンクの保護を指します。主なプロトコル要件には次のものが含まれます。
* Link management: Link property correlation on the link protection type
* リンク管理：リンクプロパティ相関リンク保護タイプの相関
* Routing: Announcement of the link protection type
* ルーティング：リンク保護タイプの発表
* Signaling: Indication of link protection requirement for that LSP
* シグナル伝達：そのLSPのリンク保護要件の兆候
GMPLS already supports the above requirements, and there are no new requirements in the scenario of interworking between GMPLS and a centralized controller system.
GMPLSはすでに上記の要件をサポートしており、GMPLSと集中コントローラーシステムの間のインターワーキングのシナリオには新しい要件はありません。
The LSP protection includes end-to-end and segment LSP protection. For both cases:
LSP保護には、エンドツーエンドおよびセグメントLSP保護が含まれます。どちらの場合も：
* In the provisioning phase:
* プロビジョニングフェーズ：
In both single-domain and multi-domain scenarios, the disjoint path computation can be done by the centralized controller system, as it has the global topology and resource view. And the path creation can be done by the procedure described in Section 8.2.
単一ドメインとマルチドメインの両方のシナリオで、グローバルなトポロジとリソースビューがあるため、中央コントローラーシステムでは、分離パス計算を行うことができます。また、パス作成は、セクション8.2で説明した手順によって実行できます。
* In the protection switchover phase:
* 保護スイッチオーバーフェーズ：
In both single-domain and multi-domain scenarios, the existing standards provide the distributed way to trigger the protection switchover, for example, the data plane Automatic Protection Switching (APS) mechanism described in [G.808.1], [RFC7271], and [RFC8234] or the GMPLS Notify mechanism described in [RFC4872] and [RFC4873]. In the scenario of interworking between GMPLS and a centralized controller system, using these distributed mechanisms rather than a centralized mechanism (i.e., the controller triggers the protection switchover) can significantly shorten the protection switching time.
単一ドメインとマルチドメインの両方のシナリオで、既存の標準は、[G.808.1]、[RFC7271]、[RFC8234]、[RFC8234]、または[RFC4872]に記載されている[RFC4872]に記載されている[G.808.1]、[RFC8234]に記載されているデータプレーン自動保護スイッチング（APS）メカニズムなど、保護スイッチオーバーをトリガーするための分散方法を提供します。GMPLSと集中コントローラーシステム間の相互作用のシナリオでは、集中メカニズム（つまり、コントローラーが保護スイッチオーバーをトリガーする）ではなく、これらの分散メカニズムを使用して保護スイッチング時間を大幅に短縮する可能性があります。
* Pre-planned LSP protection (including shared-mesh restoration):
* 事前に計画されたLSP保護（共有メッシュの復元を含む）：
In pre-planned protection, the protecting LSP is established only in the control plane in the provisioning phase and will be activated in the data plane once failure occurs.
事前に計画された保護では、保護LSPはプロビジョニングフェーズの制御面でのみ確立され、障害が発生するとデータプレーンでアクティブ化されます。
In the scenario of interworking between GMPLS and a centralized controller system, the route of protecting LSP can be computed by the centralized controller system. This takes the advantage of making better use of network resources, especially for the resource-sharing in shared-mesh restoration.
GMPLSと集中コントローラーシステム間のインターワーキングのシナリオでは、LSPを保護するルートは、集中コントローラーシステムによって計算できます。これには、特に共有メッシュの修復におけるリソース共有のために、ネットワークリソースをより適切に使用することができます。
* Full LSP rerouting:
* フルLSPルーティング：
In full LSP rerouting, the normal traffic will be switched to an alternate LSP that is fully established only after a failure occurrence.
完全なLSPルーティングでは、通常のトラフィックは、故障が発生した後にのみ完全に確立される代替LSPに切り替えられます。
As described in [RFC4872] and [RFC4873], the alternate route can be computed on demand when there is a failure occurrence or can be pre-computed and stored before a failure occurrence.
[RFC4872]および[RFC4873]で説明されているように、障害が発生している場合、または障害が発生する前に事前計算および保存される場合、代替ルートはオンデマンドで計算できます。
In a fully distributed scenario, the pre-computation method offers a faster restoration time but has the risk that the pre-computed alternate route may become out-of-date due to the changes of the network.
完全に分散されたシナリオでは、コンピューティング前の方法はより速い修復時間を提供しますが、ネットワークの変更により、事前に計算された代替ルートが時代遅れになるリスクがあります。
In the scenario of interworking between GMPLS and a centralized controller system, the pre-computation of the alternate route could take place in the centralized controller (and may be stored in the controller or the head-end node of the LSP). In this way, any changes in the network can trigger the refreshment of the alternate route by the centralized controller. This makes sure that the alternate route will not become out-of-date.
In the scenario of interworking between GMPLS and a centralized controller system, the pre-computation of the alternate route could take place in the centralized controller (and may be stored in the controller or the head-end node of the LSP).このようにして、ネットワークの変更は、集中コントローラーによる代替ルートのリフレッシュをトリガーできます。これにより、代替ルートが時代遅れにならないようにします。
A working LSP may traverse multiple domains, each of which may or may not support a GMPLS distributed control plane.
作業LSPは複数のドメインを通過する場合があり、それぞれがGMPLS分散コントロールプレーンをサポートする場合とサポートしていない場合があります。
If all the domains support GMPLS, both the end-to-end rerouting method and the domain segment rerouting method could be used.
すべてのドメインがGMPLをサポートする場合、エンドツーエンドの再ルーティング方法とドメインセグメントルーティング方法の両方を使用できます。
If only some domains support GMPLS, the domain segment rerouting method could be used in those GMPLS domains. For other domains that do not support GMPLS, other mechanisms may be used to protect the LSP segments, which are out of scope of this document.
一部のドメインのみがGMPLSをサポートする場合、これらのGMPLSドメインでドメインセグメントルーティング方法を使用できます。GMPLSをサポートしていない他のドメインの場合、他のメカニズムを使用して、このドキュメントの範囲外のLSPセグメントを保護することができます。
1) End-to-end rerouting:
1) エンドツーエンドの再ルーティング：
In this scenario, a failure on the working LSP inside any domain or on the inter-domain links will trigger the end-to-end restoration.
このシナリオでは、任意のドメイン内またはドメイン間リンク内の動作LSPの障害がエンドツーエンドの復元をトリガーします。
In both pre-planned and full LSP rerouting, the end-to-end protecting LSP could be computed by the centralized controller system and could be created by the procedure described in Section 8.2. Note that the end-to-end protecting LSP may traverse different domains from the working LSP, depending on the result of multi-domain path computation for the protecting LSP.
事前に計画されたLSPリルアウトと完全なLSPの両方の再ルーティングで、エンドツーエンドの保護LSPは、集中コントローラーシステムによって計算され、セクション8.2で説明されている手順によって作成できます。LSPを保護するためのマルチドメインパス計算の結果に応じて、エンドツーエンドの保護LSPは、動作中のLSPから異なるドメインを通過する可能性があることに注意してください。
+----------------+
|Orchestrator(MD)|
+-------.--------+
............................................
. . . .
+----V-----+ +----V-----+ +----V-----+ +----V-----+
|Controller| |Controller| |Controller| |Controller|
| (G) 1 | | (G) 2 | | (G) 3 | | (G) 4 |
+----.-----+ +-------.--+ +-------.--+ +----.-----+
. . . .
+----V--------+ +-V-----------+ . +-------V-----+
| Domain 1 | | Domain 2 | . | Domain 4 |
|+---+ +---+| |+---+ +---+| . |+---+ +---+|
|| ===/~/======/~~~/================================ ||
|+-*-+ +---+| |+---+ +---+| . |+---+ +-*-+|
| * | +-------------+ . | * |
| * | . | * |
| * | +-------------+ . | * |
| * | | Domain 3 <... | * |
|+-*-+ +---+| |+---+ +---+| |+---+ +-*-+|
|| ************************************************* ||
|+---+ +---+| |+---+ +---+| |+---+ +---+|
+-------------+ +-------------+ +-------------+
====: Working LSP ****: Protecting LSP /~/: Failure
Figure 5: End-to-End Restoration
図5：エンドツーエンドの修復
2) Domain segment rerouting:
2) ドメインセグメントルーティング：
2.1) Intra-domain rerouting:
2.1）ドメイン内再ルーティング：
If failure occurs on the working LSP segment in a GMPLS domain, the segment rerouting [RFC4873] could be used for the working LSP segment in that GMPLS domain. Figure 6 shows an example of intra-domain rerouting.
GMPLSドメインの動作LSPセグメントで障害が発生した場合、そのGMPLSドメインの動作LSPセグメントに再ルーティング[RFC4873]を使用できます。図6は、ドメイン内の再ルーティングの例を示しています。
The intra-domain rerouting of a non-GMPLS domain is out of scope of this document.
非GMPLSドメインのドメイン内再ルーティングは、このドキュメントの範囲外です。
+----------------+
|Orchestrator(MD)|
+-------.--------+
............................................
. . . .
+----V-----+ +----V-----+ +----V-----+ +----V-----+
|Controller| |Controller| |Controller| |Controller|
| (G) 1 | |(G)/(N) 2 | |(G)/(N) 3 | |(G)/(N) 4 |
+----.-----+ +-------.--+ +-------.--+ +----.-----+
. . . .
+----V--------+ +-V-----------+ . +-------V-----+
| Domain 1 | | Domain 2 | . | Domain 4 |
|+---+ +---+| |+---+ +---+| . |+---+ +---+|
|| ===/~/=========================================== ||
|+-*-+ +-*-+| |+---+ +---+| . |+---+ +---+|
| * * | +-------------+ . | |
| * * | . | |
| * * | +-------------+ . | |
| * * | | Domain 3 <... | |
|+-*-+ +-*-+| |+---+ +---+| |+---+ +---+|
|| ********* || || | | || || | | ||
|+---+ +---+| |+---+ +---+| |+---+ +---+|
+-------------+ +-------------+ +-------------+
====: Working LSP ****: Rerouting LSP segment /~/: Failure
Figure 6: Intra-Domain Segment Rerouting
図6：ドメイン内セグメントの再ルーティング
2.2) Inter-domain rerouting:
2.2）ドメイン間ルーティング：
If intra-domain segment rerouting failed (e.g., due to lack of resource in that domain), or if failure occurs on the working LSP on an inter-domain link, the centralized controller system may coordinate with other domain(s) to find an alternative path or path segment to bypass the failure and then trigger the inter-domain rerouting procedure. Note that the rerouting path or path segment may traverse different domains from the working LSP.
ドメイン内セグメントの再ルーティングが失敗した場合（たとえば、そのドメインのリソースの不足により）、またはドメイン間リンクの動作LSPで障害が発生した場合、中央コントローラーシステムは他のドメインと調整して、障害をバイパスしてからドメイン間のレルアウト手順をトリガーするための代替パスまたはパスセグメントを見つけることができます。再ルーティングパスまたはパスセグメントは、動作するLSPから異なるドメインを横断する可能性があることに注意してください。
The domains involved in the inter-domain rerouting procedure need to be GMPLS domains, which support the RSVP-TE signaling for the creation of a rerouting LSP segment.
ドメイン間再ルーティング手順に関与するドメインは、再ルーティングLSPセグメントの作成のためのRSVP-TEシグナル伝達をサポートするGMPLSドメインである必要があります。
For inter-domain rerouting, the interaction between GMPLS and a centralized controller system is needed:
ドメイン間再ルーティングの場合、GMPLSと集中コントローラーシステム間の相互作用が必要です。
* A report of the result of intra-domain segment rerouting to its Controller(G) and then to the Orchestrator(MD). The former could be supported by the PCRpt message in [RFC8231], while the latter could be supported by the MPI of ACTN.
* ドメイン内セグメントの結果のレポートは、コントローラー（g）、そしてオーケストレーター（MD）に再ルーティングします。前者は[RFC8231]のPCRPTメッセージによってサポートされる可能性がありますが、後者はACTNのMPIによってサポートされる可能性があります。
* A report of inter-domain link failure to the two Controllers (e.g., Controller(G) 1 and Controller(G) 2 in Figure 7) by which the two ends of the inter-domain link are controlled, respectively, and then to the Orchestrator(MD). The former could be done as described in Section 8.1, while the latter could be supported by the MPI of ACTN.
* ドメイン間リンクの障害の2つのコントローラーへの障害（例：コントローラー（g）1およびコントローラー（g）2の図7）のレポート。これにより、ドメイン間リンクの2つの端がそれぞれコントロールされ、次にオーケストレーター（MD）に制御されます。前者はセクション8.1で説明されているように、後者はActnのMPIによってサポートされる可能性があります。
* The computation of a rerouting path or path segment crossing multi-domains by the centralized controller system (see [PATH-COMP]);
* 集中コントローラーシステムによるマルチドメインを横切る再ルーティングパスまたはパスセグメントの計算（[Path-Comp]を参照）;
* The creation of a rerouting LSP segment in each related domain. The Orchestrator(MD) can send the LSP segment rerouting request to the source Controller(G) (e.g., Controller(G) 1 in Figure 7) via MPI interface, and then the Controller(G) can trigger the creation of a rerouting LSP segment through multiple GMPLS domains using GMPLS rerouting signaling. Note that the rerouting LSP segment may traverse a new domain that the working LSP does not traverse (e.g., Domain 3 in Figure 7).
* 各関連ドメインに再ルーティングLSPセグメントの作成。オーケストレーター（MD）は、MPIインターフェイスを介してLSPセグメントリルートリクエストをソースコントローラー（g）（図7のコントローラー（g）1）に送信でき、コントローラー（g）は、gmpls Reroutingシグナリングを使用して複数のGMPLSドメインを介してLSPセグメントの作成をトリガーできます。再ルーティングLSPセグメントは、作業LSPが横断しないという新しいドメインを横断する可能性があることに注意してください（例：図7のドメイン3）。
+----------------+
|Orchestrator(MD)|
+-------.--------+
..................................................
. . . .
+-----V------+ +-----V------+ +-----V------+ +-----V------+
| Controller | | Controller | | Controller | | Controller |
| (G) 1 | | (G) 2 | | (G) 3 | | (G)/(N) 4 |
+-----.------+ +------.-----+ +-----.------+ +-----.------+
. . . .
+-----V-------+ +----V--------+ . +------V------+
| Domain 1 | | Domain 2 | . | Domain 4 |
|+---+ +---+| |+---+ +---+| . |+---+ +---+|
|| | | || || | | || . || | | ||
|| ============/~/========================================== ||
|| * | | || || | | * || . || | | ||
|+-*-+ +---+| |+---+ +-*-+| . |+---+ +---+|
| * | +----------*--+ . | |
| * | ***** . | |
| * | +----------*-----V----+ | |
| * | | *Domain 3 | | |
|+-*-+ +---+| |+---+ +-*-+ +---+| |+---+ +---+|
|| * | | || || | | * | | || || | | ||
|| ******************************* | | || || | | ||
|| | | || || | | | | || || | | ||
|+---+ +---+| |+---+ +---+ +---+| |+---+ +---+|
+-------------+ +---------------------+ +-------------+
====: Working LSP ****: Rerouting LSP segment /~/: Failure
Figure 7: Inter-Domain Segment Rerouting
図7：ドメイン間セグメントの再ルーティング
[RFC4090] defines two methods of fast reroute: the one-to-one backup method and the facility backup method. For both methods:
[RFC4090]は、1対1のバックアップ方法と施設のバックアップ方法の2つの方法を定義します。両方の方法について：
1) Path computation of protecting LSP:
1) LSPの保護のパス計算：
In Section 6.2 of [RFC4090], the protecting LSP (detour LSP in one-to-one backup or bypass tunnel in facility backup) could be computed by the Point of Local Repair (PLR) using, for example, a Constrained Shortest Path First (CSPF) computation. In the scenario of interworking between GMPLS and a centralized controller system, the protecting LSP could also be computed by the centralized controller system, as it has the global view of the network topology, resources, and information of LSPs.
[RFC4090]のセクション6.2では、たとえば制約された最短パス（CSPF）コンピューターを使用して、ローカル修理（PLR）のポイント（PLR）によって保護されているLSP（施設バックアップの1対1のバックアップまたはバイパストンネル）を計算できます。GMPLSと集中コントローラーシステム間のインターワーキングのシナリオでは、LSPの保護LSPは、LSPのネットワークトポロジ、リソース、および情報のグローバルビューを持っているため、集中コントローラーシステムによって計算される可能性もあります。
2) Protecting LSP creation:
2) LSP作成の保護：
In the scenario of interworking between GMPLS and a centralized controller system, the protecting LSP could still be created by the RSVP-TE signaling protocol as described in [RFC4090] and [RFC8271].
GMPLSと集中コントローラーシステム間のインターワーキングのシナリオでは、[RFC4090]および[RFC8271]で説明されているように、RSVP-TEシグナル伝達プロトコルによってLSPを保護することができます。
In addition, if the protecting LSP is computed by the centralized controller system, the Secondary Explicit Route Object defined in [RFC4873] could be used to explicitly indicate the route of the protecting LSP.
さらに、保護LSPが集中コントローラーシステムによって計算された場合、[RFC4873]で定義されている二次的な明示的ルートオブジェクトを使用して、保護LSPのルートを明示的に示すことができます。
3) Failure detection and traffic switchover:
3) 障害検出とトラフィックスイッチオーバー：
If a PLR detects that failure occurs, it may significantly shorten the protection switching time by using the distributed mechanisms described in [RFC4090] to switch the traffic to the related detour LSP or bypass tunnel rather than doing so in a centralized way.
PLRが障害が発生することを検出すると、[RFC4090]に記載されている分散メカニズムを使用して、集中的な方法で行うのではなく、関連する迂回LSPまたはバイパストンネルにトラフィックを切り替えることにより、保護スイッチング時間を大幅に短縮する可能性があります。
The reliability of the controller is crucial due to its important role in the network. It is essential that if the controller is shut down or disconnected from the network, all currently provisioned services in the network continue to function and carry traffic. In addition, protection switching to pre-established paths should also work. It is desirable to have protection mechanisms, such as redundancy, to maintain full operational control even if one instance of the controller fails. This can be achieved through controller backup or functionality backup. There are several controller backup or federation mechanisms in the literature. It is also more reliable to have function backup in the network element to guarantee performance in the network.
ネットワークでの重要な役割により、コントローラーの信頼性が重要です。コントローラーがネットワークからシャットダウンまたは切断されている場合、ネットワーク内のすべてのプロビジョニングサービスが機能し続け、トラフィックを運ぶことが不可欠です。さらに、事前に確立されたパスへの保護の切り替えも機能するはずです。コントローラーの1つのインスタンスが失敗した場合でも、冗長性などの保護メカニズムが完全な運用制御を維持することが望ましいです。これは、コントローラーのバックアップまたは機能バックアップを通じて実現できます。文献には、いくつかのコントローラーバックアップまたはフェデレーションメカニズムがあります。また、ネットワークのパフォーマンスを保証するために、ネットワーク要素に機能バックアップを持つことも信頼できます。
Each network entity, including controllers and network elements, should be managed properly and with the relevant trust and security policies applied (see Section 10), as they will interact with other entities. The manageability considerations in controller hierarchies and network elements still apply, respectively. The overall manageability of the protocols applied in the network should also be a key consideration.
コントローラーやネットワーク要素を含む各ネットワークエンティティは、他のエンティティと対話するため、適切に適用され、適用される関連性とセキュリティポリシー（セクション10を参照）で管理する必要があります。コントローラーの階層とネットワーク要素の管理可能性の考慮事項は、それぞれ適用されます。ネットワークに適用されるプロトコルの全体的な管理性も重要な考慮事項である必要があります。
The responsibility of each entity should be clarified. The control of function and policy among different controllers should be consistent via a proper negotiation process.
各エンティティの責任を明確にする必要があります。異なるコントローラー間の機能とポリシーの制御は、適切な交渉プロセスを介して一貫している必要があります。
This document outlines the interworking between GMPLS and controller hierarchies. The security requirements specific to both systems remain applicable. Protocols referenced herein possess security considerations, which must be adhered to, with their core specifications and identified risks detailed earlier in this document.
このドキュメントでは、GMPLSとコントローラーの階層との間の相互作用の概要を説明しています。両方のシステムに固有のセキュリティ要件は、適用されたままです。本明細書で参照されるプロトコルには、セキュリティに関する考慮事項があり、このドキュメントの前半で詳細に詳細なリスクを備えて、遵守する必要があります。
Security is a critical aspect in both GMPLS and controller-based networks. Ensuring robust security mechanisms in these environments is paramount to safeguard against potential threats and vulnerabilities. Below are expanded security considerations and some relevant IETF RFC references.
セキュリティは、GMPLSとコントローラーベースのネットワークの両方で重要な側面です。これらの環境で堅牢なセキュリティメカニズムを確保することは、潜在的な脅威や脆弱性を守るために最も重要です。以下は、拡張されたセキュリティに関する考慮事項と、関連するIETF RFC参照です。
* Authentication and Authorization: It is essential to implement strong authentication and authorization mechanisms to control access to the controller from multiple network elements. This ensures that only authorized devices and users can interact with the controller, preventing unauthorized access that could lead to network disruptions or data breaches. "The Transport Layer Security (TLS) Protocol Version 1.3" [RFC8446] and "Enrollment over Secure Transport" [RFC7030] provide guidelines on secure communication and certificate-based authentication that can be leveraged for these purposes.
* 認証と承認：複数のネットワーク要素からコントローラーへのアクセスを制御するための強力な認証と承認メカニズムを実装することが不可欠です。これにより、認定されたデバイスとユーザーのみがコントローラーと対話できるようになり、ネットワークの破壊やデータ侵害につながる可能性のある不正アクセスを防ぎます。「トランスポートレイヤーセキュリティ（TLS）プロトコルバージョン1.3」[RFC8446]および「セキュアな輸送の登録」[RFC7030]は、これらの目的に活用できる安全な通信と証明書ベースの認証に関するガイドラインを提供します。
* Controller Security: The controller's security is crucial as it serves as the central control point for the network elements. The controller must be protected against various attacks, such as Denial of Service (DoS), Man in the Middle (MITM), and unauthorized access. Security mechanisms should include regular security audits, application of security patches, firewalls, and Intrusion Detection Systems (IDSs) / Intrusion Prevention Systems (IPSs).
* コントローラーセキュリティ：コントローラーのセキュリティは、ネットワーク要素の中心的な制御ポイントとして機能するため、重要です。コントローラーは、サービス拒否（DOS）、Man in the Middle（MITM）、不正アクセスなど、さまざまな攻撃から保護する必要があります。セキュリティメカニズムには、定期的なセキュリティ監査、セキュリティパッチの適用、ファイアウォール、侵入検知システム（IDS） /侵入予防システム（IPSS）を含める必要があります。
* Data Transport Security: Security mechanisms on the controller should also safeguard the underlying network elements against unauthorized usage of data transport resources. This includes encryption of data in transit to prevent eavesdropping and tampering as well as ensuring data integrity and confidentiality.
* データ輸送セキュリティ：コントローラーのセキュリティメカニズムは、データ輸送リソースの不正使用に対する基礎となるネットワーク要素を保護する必要があります。これには、盗聴や改ざんを防ぐための輸送中のデータの暗号化、およびデータの整合性と機密性の確保が含まれます。
* Secure Protocol Implementation: Protocols used within the GMPLS and controller frameworks must be implemented with security in mind. Known vulnerabilities should be addressed, and secure versions of protocols should be used wherever possible.
* 安全なプロトコル実装：GMPLSおよびコントローラーフレームワーク内で使用されるプロトコルは、セキュリティを念頭に置いて実装する必要があります。既知の脆弱性に対処する必要があり、プロトコルの安全なバージョンを可能な限り使用する必要があります。
Finally, robust network security often depends on Indicators of Compromise (IoCs) to detect, trace, and prevent malicious activities in networks or endpoints. These are described in [RFC9424] along with the fundamentals, opportunities, operational limitations, and recommendations for IoC use.
最後に、堅牢なネットワークセキュリティは、ネットワークまたはエンドポイントで悪意のあるアクティビティを検出、トレース、および防止するための妥協（IOC）の指標に依存することがよくあります。これらは[RFC9424]で説明されており、IOCの使用に関する基本、機会、運用上の制限、および推奨事項とともに説明されています。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<https://www.rfc-editor.org/info/rfc3473>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945,
DOI 10.17487/RFC3945, October 2004,
<https://www.rfc-editor.org/info/rfc3945>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<https://www.rfc-editor.org/info/rfc4203>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206,
DOI 10.17487/RFC4206, October 2005,
<https://www.rfc-editor.org/info/rfc4206>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
<https://www.rfc-editor.org/info/rfc4872>.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
May 2007, <https://www.rfc-editor.org/info/rfc4873>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<https://www.rfc-editor.org/info/rfc5307>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[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, DOI 10.17487/RFC6001, October 2010,
<https://www.rfc-editor.org/info/rfc6001>.
[RFC6107] Shiomoto, K., Ed. and A. Farrel, Ed., "Procedures for
Dynamically Signaled Hierarchical Label Switched Paths",
RFC 6107, DOI 10.17487/RFC6107, February 2011,
<https://www.rfc-editor.org/info/rfc6107>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[RFC7074] Berger, L. and J. Meuric, "Revised Definition of the GMPLS
Switching Capability and Type Fields", RFC 7074,
DOI 10.17487/RFC7074, November 2013,
<https://www.rfc-editor.org/info/rfc7074>.
[RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for
Application-Based Network Operations", RFC 7491,
DOI 10.17487/RFC7491, March 2015,
<https://www.rfc-editor.org/info/rfc7491>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G.,
Ceccarelli, D., and X. Zhang, "Problem Statement and
Architecture for Information Exchange between
Interconnected Traffic-Engineered Networks", BCP 206,
RFC 7926, DOI 10.17487/RFC7926, July 2016,
<https://www.rfc-editor.org/info/rfc7926>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8271] Taillon, M., Saad, T., Ed., Gandhi, R., Ed., Ali, Z., and
M. Bhatia, "Updates to the Resource Reservation Protocol
for Fast Reroute of Traffic Engineering GMPLS Label
Switched Paths (LSPs)", RFC 8271, DOI 10.17487/RFC8271,
October 2017, <https://www.rfc-editor.org/info/rfc8271>.
[RFC8282] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions
to the Path Computation Element Communication Protocol
(PCEP) for Inter-Layer MPLS and GMPLS Traffic
Engineering", RFC 8282, DOI 10.17487/RFC8282, December
2017, <https://www.rfc-editor.org/info/rfc8282>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
Abstraction and Control of TE Networks (ACTN)", RFC 8453,
DOI 10.17487/RFC8453, August 2018,
<https://www.rfc-editor.org/info/rfc8453>.
[RFC8685] Zhang, F., Zhao, Q., Gonzalez de Dios, O., Casellas, R.,
and D. King, "Path Computation Element Communication
Protocol (PCEP) Extensions for the Hierarchical Path
Computation Element (H-PCE) Architecture", RFC 8685,
DOI 10.17487/RFC8685, December 2019,
<https://www.rfc-editor.org/info/rfc8685>.
[RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and
O. Gonzalez de Dios, "YANG Data Model for Traffic
Engineering (TE) Topologies", RFC 8795,
DOI 10.17487/RFC8795, August 2020,
<https://www.rfc-editor.org/info/rfc8795>.
[RFC9424] Paine, K., Whitehouse, O., Sellwood, J., and A. Shaw,
"Indicators of Compromise (IoCs) and Their Role in Attack
Defence", RFC 9424, DOI 10.17487/RFC9424, August 2023,
<https://www.rfc-editor.org/info/rfc9424>.
[G.808.1] ITU-T, "Generic protection switching - Linear trail and
subnetwork protection", ITU-T Recommendation G.808.1, May
2014, <https://www.itu.int/rec/T-REC-G.808.1-201405-I/en>.
[PATH-COMP]
Busi, I., Belotti, S., de Dios, O. G., Sharma, A., and Y.
Shi, "A YANG Data Model for requesting path computation",
Work in Progress, Internet-Draft, draft-ietf-teas-yang-
path-computation-24, 13 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
yang-path-computation-24>.
[PCEP-LS] Dhody, D., Peng, S., Lee, Y., Ceccarelli, D., Wang, A.,
and G. S. Mishra, "PCEP extensions for Distribution of
Link-State and TE Information", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-ls-02, 20 October
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-ls-02>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description",
RFC 3471, DOI 10.17487/RFC3471, January 2003,
<https://www.rfc-editor.org/info/rfc3471>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<https://www.rfc-editor.org/info/rfc4202>.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
DOI 10.17487/RFC4204, October 2005,
<https://www.rfc-editor.org/info/rfc4204>.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426,
DOI 10.17487/RFC4426, March 2006,
<https://www.rfc-editor.org/info/rfc4426>.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,
<https://www.rfc-editor.org/info/rfc5150>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
DOI 10.17487/RFC5212, July 2008,
<https://www.rfc-editor.org/info/rfc5212>.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441,
DOI 10.17487/RFC5441, April 2009,
<https://www.rfc-editor.org/info/rfc5441>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC7138] Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
J. Drake, "Traffic Engineering Extensions to OSPF for
GMPLS Control of Evolving G.709 Optical Transport
Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
<https://www.rfc-editor.org/info/rfc7138>.
[RFC7139] Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
and K. Pithewan, "GMPLS Signaling Extensions for Control
of Evolving G.709 Optical Transport Networks", RFC 7139,
DOI 10.17487/RFC7139, March 2014,
<https://www.rfc-editor.org/info/rfc7139>.
[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
Transport Profile (MPLS-TP) Linear Protection to Match the
Operational Expectations of Synchronous Digital Hierarchy,
Optical Transport Network, and Ethernet Transport Network
Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014,
<https://www.rfc-editor.org/info/rfc7271>.
[RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF
Enhancement for Signal and Network Element Compatibility
for Wavelength Switched Optical Networks", RFC 7688,
DOI 10.17487/RFC7688, November 2015,
<https://www.rfc-editor.org/info/rfc7688>.
[RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
and H. Harai, "Signaling Extensions for Wavelength
Switched Optical Networks", RFC 7689,
DOI 10.17487/RFC7689, November 2015,
<https://www.rfc-editor.org/info/rfc7689>.
[RFC7792] Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
and D. Ceccarelli, "RSVP-TE Signaling Extensions in
Support of Flexi-Grid Dense Wavelength Division
Multiplexing (DWDM) Networks", RFC 7792,
DOI 10.17487/RFC7792, March 2016,
<https://www.rfc-editor.org/info/rfc7792>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8234] Ryoo, J., Cheung, T., van Helvoort, H., Busi, I., and G.
Wen, "Updates to MPLS Transport Profile (MPLS-TP) Linear
Protection in Automatic Protection Switching (APS) Mode",
RFC 8234, DOI 10.17487/RFC8234, August 2017,
<https://www.rfc-editor.org/info/rfc8234>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8363] Zhang, X., Zheng, H., Casellas, R., Gonzalez de Dios, O.,
and D. Ceccarelli, "GMPLS OSPF-TE Extensions in Support of
Flexi-Grid Dense Wavelength Division Multiplexing (DWDM)
Networks", RFC 8363, DOI 10.17487/RFC8363, May 2018,
<https://www.rfc-editor.org/info/rfc8363>.
[SPCE-ID] Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
Extension for Stateful Inter-Domain Tunnels", Work in
Progress, Internet-Draft, draft-ietf-pce-stateful-
interdomain-07, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
stateful-interdomain-07>.
[YANG-TE] Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
Bryskin, "A YANG Data Model for Traffic Engineering
Tunnels, Label Switched Paths and Interfaces", Work in
Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-yang-te-37>.
The authors would like to thank Jim Guichard, Area Director of IETF Routing Area; Vishnu Pavan Beeram, Chair of TEAS WG; Jia He and Stewart Bryant, RTGDIR reviewers; Thomas Fossati, Gen-ART reviewer; Yingzhen Qu, OPSDIR reviewer; David Mandelberg, SECDIR reviewer; David Dong, IANA Services Sr. Specialist; and Éric Vyncke and Murray Kucherawy, IESG reviewers for their reviews and comments on this document.
著者は、IETFルーティングエリアのエリアディレクターであるJim Guichardに感謝します。ヴィシュヌ・パバン・ビアラム、茶wgの議長。Jia HeとStewart Bryant、Rtgdirレビュアー。トーマス・フォッサティ、gen-artレビュアー。Yingzhen QU、Opsdirレビューア;David Mandelberg、Secdir Reviewer;David Dong、Iana Services Sr.スペシャリスト。このドキュメントに関するレビューとコメントについては、Eric VynckeとMurray Kuherawy、IESGレビュアー。
Xianlong Luo
Huawei Technologies
G1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: luoxianlong@huawei.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Haomian Zheng
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: zhenghaomian@huawei.com
Yi Lin
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: yi.lin@huawei.com
Yang Zhao
China Mobile
Email: zhaoyangyjy@chinamobile.com
Yunbin Xu
CAICT
Email: xuyunbin@caict.ac.cn
Dieter Beller
Nokia
Email: Dieter.Beller@nokia.com