[要約] 要約：RFC 8637は、Path Computation Element（PCE）を使用して、TEネットワークの抽象化と制御（ACTN）に適用する方法について説明しています。 目的：このRFCの目的は、PCEを使用してACTNを実現するためのガイドラインを提供し、ネットワークの効率性と柔軟性を向上させることです。
Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 8637 Huawei Technologies
Category: Informational Y. Lee
ISSN: 2070-1721 Futurewei Technologies
D. Ceccarelli
Ericsson
July 2019
Applicability of the Path Computation Element (PCE) to the Abstraction and Control of TE Networks (ACTN)
TEネットワークの抽象化および制御（ACTN）へのパス計算要素（PCE）の適用性
Abstract
概要
Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.
TEネットワークの抽象化と制御（ACTN）とは、大規模なマルチドメインTEネットワークを調整、制御、および管理して、ネットワークのプログラマビリティ、自動化、効率的なリソース共有、およびエンドを容易にするために必要な一連の仮想ネットワーク（VN）操作を指します。エンドツーエンドの仮想サービス対応接続とネットワーク機能仮想化サービス。
The Path Computation Element (PCE) is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP).
パス計算要素（PCE）は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算の制約を適用できるコンポーネント、アプリケーション、またはネットワークノードです。 PCEは、ローカルAPIを介して、またはパス計算要素通信プロトコル（PCEP）を使用してPCEと通信するパス計算クライアント（PCC）からの要求に対応します。
This document examines the applicability of PCE to the ACTN framework.
このドキュメントでは、PCTNのACTNフレームワークへの適用性について検討します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc8637.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8637で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background Information . . . . . . . . . . . . . . . . . . . 3
2.1. Path Computation Element (PCE) . . . . . . . . . . . . . 3
2.1.1. Role of PCE in SDN . . . . . . . . . . . . . . . . . 4
2.1.2. PCE in Multidomain and Multilayer Deployments . . . . 4
2.1.3. Relationship to PCE-Based Central Control . . . . . . 5
2.2. Abstraction and Control of TE Networks (ACTN) . . . . . . 5
3. Architectural Considerations . . . . . . . . . . . . . . . . 7
3.1. Multidomain Coordination via Hierarchy . . . . . . . . . 7
3.2. Abstraction . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Customer Mapping . . . . . . . . . . . . . . . . . . . . 9
3.4. Virtual Service Coordination . . . . . . . . . . . . . . 10
4. Interface Considerations . . . . . . . . . . . . . . . . . . 10
5. Realizing ACTN with PCE (and PCEP) . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Additional Information . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Abstraction and Control of TE Networks (ACTN) [RFC8453] refers to the set of virtual network (VN) operations needed to orchestrate, control, and manage large-scale multidomain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to-end virtual service-aware connectivity and network function virtualization services.
TEネットワークの抽象化と制御（ACTN）[RFC8453]は、ネットワークのプログラマビリティ、自動化、効率的なリソース共有を容易にするために、大規模マルチドメインTEネットワークを調整、制御、および管理するために必要な一連の仮想ネットワーク（VN）操作を指します。エンドツーエンドの仮想サービス対応接続およびネットワーク機能仮想化サービス。
The Path Computation Element (PCE) [RFC4655] is a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE serves requests from Path Computation Clients (PCCs) that communicate with it over a local API or using the Path Computation Element Communication Protocol (PCEP).
パス計算要素（PCE）[RFC4655]は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるコンポーネント、アプリケーション、またはネットワークノードです。 PCEは、ローカルAPIを介して、またはパス計算要素通信プロトコル（PCEP）を使用してPCEと通信するパス計算クライアント（PCC）からの要求に対応します。
This document examines the PCE and ACTN architecture and describes how PCE architecture is applicable to ACTN. It also lists the PCEP extensions that are needed to use PCEP as an ACTN interface. This document also identifies any gaps in PCEP that exist at the time of publication of this document.
このドキュメントでは、PCEおよびACTNアーキテクチャを検証し、PCEアーキテクチャをACTNに適用する方法について説明します。また、PCEPをACTNインターフェースとして使用するために必要なPCEP拡張機能もリストしています。このドキュメントは、このドキュメントの公開時に存在したPCEPのギャップも識別します。
Further, ACTN, stateful Hierarchical PCE (H-PCE) [PCE-HPCE], and PCE as a central controller (PCECC) [RFC8283] are based on the same basic hierarchy framework and are thus compatible with each other.
さらに、ACTN、ステートフル階層PCE（H-PCE）[PCE-HPCE]、およびセントラルコントローラーとしてのPCE（PCECC）[RFC8283]は、同じ基本階層フレームワークに基づいているため、相互に互換性があります。
The Path Computation Element Communication Protocol (PCEP) [RFC5440] provides mechanisms for Path Computation Clients (PCCs) to request a Path Computation Element (PCE) [RFC4655] to perform path computations.
パス計算要素通信プロトコル（PCEP）[RFC5440]は、パス計算クライアント（PCC）がパス計算要素（PCE）[RFC4655]にパス計算を実行するよう要求するためのメカニズムを提供します。
The ability to compute shortest constrained TE LSPs in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains has been identified as a key motivation for PCE development.
複数のドメインにまたがるマルチプロトコルラベルスイッチング（MPLS）および汎用MPLS（GMPLS）ネットワークで最短の制約付きTE LSPを計算する機能は、PCE開発の主要な動機として特定されています。
A stateful PCE [RFC8231] is capable of considering, for the purposes of path computation, not only the network state in terms of links and nodes (referred to as the Traffic Engineering Database or TED), but also the status of active services (previously computed paths), and currently reserved resources, stored in the Label Switched Paths Database (LSP-DB).
ステートフルPCE [RFC8231]は、パス計算の目的で、リンクおよびノードに関するネットワーク状態（Traffic Engineering DatabaseまたはTEDと呼ばれる）だけでなく、アクティブなサービス（以前は計算パス）、および現在予約されているリソースで、ラベルスイッチドパスデータベース（LSP-DB）に保存されています。
[RFC8051] describes general considerations for a stateful PCE deployment and examines its applicability and benefits as well as its challenges and limitations through a number of use cases.
[RFC8051]は、ステートフルPCE展開の一般的な考慮事項を説明し、その適用性と利点、および多数の使用例を通してその課題と制限を調べます。
[RFC8231] describes a set of extensions to PCEP to provide stateful control. A stateful PCE has access to not only the information carried by the network's Interior Gateway Protocol (IGP), but also the set of active paths and their reserved resources for its computations. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model.
[RFC8231]は、ステートフルコントロールを提供するPCEPの一連の拡張機能について説明しています。ステートフルPCEは、ネットワークのInterior Gateway Protocol（IGP）によって伝達される情報だけでなく、アクティブパスのセットとその計算用に予約されているリソースにもアクセスできます。追加の状態により、PCEは個別のLSPとその相互作用を考慮しながら、制約されたパスを計算できます。 [RFC8281]は、ステートフルPCEモデルでのPCEによって開始されたLSPのセットアップ、メンテナンス、およびティアダウンについて説明しています。
[RFC8231] also describes the active stateful PCE. The active PCE functionality allows a PCE to reroute an existing LSP or make changes to the attributes of an existing LSP, or a PCC to delegate control of specific LSPs to a new PCE.
[RFC8231]はアクティブなステートフルPCEについても説明しています。アクティブなPCE機能により、PCEが既存のLSPを再ルーティングしたり、既存のLSPの属性を変更したり、PCCが特定のLSPの制御を新しいPCEに委任したりできます。
Software-Defined Networking (SDN) [RFC7149] refers to a separation between the control elements and the forwarding components so that software running in a centralized system, called a controller, can act to program the devices in the network to behave in specific ways. A required element in an SDN architecture is a component that plans how the network resources will be used and how the devices will be programmed. It is possible to view this component as performing specific computations to place flows within the network given knowledge of the availability of network resources, how other forwarding devices are programmed, and the way that other flows are routed. It is concluded in [RFC7399] that this is the same function that a PCE might offer in a network operated using a dynamic control plane. This is the function and purpose of a PCE, and the way that a PCE integrates into a wider network control system including SDN is presented in Application-Based Network Operation (ABNO) [RFC7491].
Software-Defined Networking（SDN）[RFC7149]は、コントローラーと呼ばれる集中型システムで実行されるソフトウェアが特定の方法で動作するようにネットワーク内のデバイスをプログラムするように機能できるように、制御要素と転送コンポーネント間の分離を指します。 SDNアーキテクチャで必要な要素は、ネットワークリソースの使用方法とデバイスのプログラミング方法を計画するコンポーネントです。このコンポーネントは、ネットワークリソースの可用性、他の転送デバイスのプログラム方法、および他のフローのルーティング方法についての知識があれば、特定の計算を実行してネットワーク内にフローを配置するものと見なすことができます。 [RFC7399]で、これは、動的制御プレーンを使用して操作されるネットワークでPCEが提供する機能と同じであると結論付けられています。これはPCEの機能と目的であり、PCEがSDNを含むより広範なネットワーク制御システムに統合される方法は、アプリケーションベースのネットワーク操作（ABNO）[RFC7491]に示されています。
Computing paths across large multidomain environments requires special computational components and cooperation between entities in different domains capable of complex path computation. The PCE provides an architecture and a set of functional components to address this problem space. A PCE may be used to compute end-to-end paths across multidomain environments using a per-domain path computation technique [RFC5152]. The Backward-Recursive PCE-based path computation (BRPC) mechanism [RFC5441] defines a PCE-based path computation procedure to compute interdomain-constrained MPLS and GMPLS TE networks. However, per-domain technique assumes that the sequence of domains to be crossed from source to destination is known, either fixed by the network operator or obtained by other means. BRPC can work best with a known domain sequence, and it will also work nicely with a small set of interconnected domains. However, it doesn't work well for a large set of interconnected domains.
大規模なマルチドメイン環境全体でパスを計算するには、特別な計算コンポーネントと、複雑なパス計算が可能な異なるドメイン内のエンティティ間の連携が必要です。 PCEは、この問題空間に対処するためのアーキテクチャと一連の機能コンポーネントを提供します。 PCEは、ドメインごとのパス計算手法[RFC5152]を使用して、マルチドメイン環境全体のエンドツーエンドパスを計算するために使用できます。後方再帰PCEベースのパス計算（BRPC）メカニズム[RFC5441]は、ドメイン間制約のあるMPLSおよびGMPLS TEネットワークを計算するためのPCEベースのパス計算手順を定義します。ただし、ドメインごとの手法では、送信元から宛先に渡るドメインのシーケンスが既知であり、ネットワークオペレーターによって固定されているか、他の手段によって取得されていると想定しています。 BRPCは既知のドメインシーケンスで最適に機能し、相互接続されたドメインの小さなセットでも適切に機能します。ただし、相互接続されたドメインの大規模なセットではうまく機能しません。
[RFC6805] describes a Hierarchical PCE (H-PCE) architecture that can be used for computing end-to-end paths for interdomain MPLS Traffic Engineering (TE) and GMPLS Label Switched Paths (LSPs) when the domain sequence is not known. Within the Hierarchical PCE (H-PCE) architecture, the Parent PCE (P-PCE) is used to compute a multidomain path based on the domain connectivity information. A Child PCE (C-PCE) may be responsible for a single domain or multiple domains; it is used to compute the intradomain path based on its domain topology information.
[RFC6805]は、ドメインシーケンスが不明な場合に、ドメイン間MPLSトラフィックエンジニアリング（TE）およびGMPLSラベルスイッチドパス（LSP）のエンドツーエンドパスの計算に使用できる階層PCE（H-PCE）アーキテクチャについて説明しています。階層PCE（H-PCE）アーキテクチャー内では、親PCE（P-PCE）を使用して、ドメイン接続情報に基づいてマルチドメインパスを計算します。子PCE（C-PCE）は、単一のドメインまたは複数のドメインを担当する場合があります。ドメイントポロジ情報に基づいてドメイン内パスを計算するために使用されます。
[PCE-HPCE] states the considerations for stateful PCEs in Hierarchical PCE architecture. In particular, the behavior changes and adds to the existing stateful PCE mechanisms (including PCE-initiated LSP setup and active PCE usage) in the context of networks using the H-PCE architecture.
[PCE-HPCE]は、階層型PCEアーキテクチャにおけるステートフルPCEの考慮事項を述べています。特に、H-PCEアーキテクチャーを使用するネットワークのコンテキストでは、動作が変更され、既存のステートフルPCEメカニズム（PCEによって開始されるLSPセットアップとアクティブなPCEの使用を含む）に追加されます。
[RFC5623] describes a framework for applying the PCE-based architecture to interlayer (G)MPLS TE. It provides suggestions for the deployment of PCE in support of multilayer networks. It also describes the relationship between PCE and a functional component in charge of the control and management of the Virtual Network Topology (VNT) [RFC5212] called the VNT Manager (VNTM).
[RFC5623]は、PCEベースのアーキテクチャを中間層（G）MPLS TEに適用するためのフレームワークについて説明しています。多層ネットワークをサポートするPCEの展開に関する提案を提供します。また、PCEと、VNT Manager（VNTM）と呼ばれる仮想ネットワークトポロジ（VNT）[RFC5212]の制御と管理を担当する機能コンポーネントとの関係についても説明します。
[RFC8283] introduces the architecture for PCE as a central controller (PCECC); it further examines the motivations and applicability for PCEP as a southbound interface (SBI) and introduces the implications for the protocol. Section 2.1.3 of [RFC8283] describes a hierarchy of PCE-based controllers as per the PCE Hierarchy Framework defined in [RFC6805].
[RFC8283]は、PCEのアーキテクチャを中央コントローラー（PCECC）として紹介しています。さらに、サウスバウンドインターフェイス（SBI）としてのPCEPの動機と適用性を調べ、プロトコルへの影響を紹介します。 [RFC8283]のセクション2.1.3は、[RFC6805]で定義されているPCE階層フレームワークに従って、PCEベースのコントローラーの階層について説明しています。
[RFC8453] describes the high-level ACTN requirements and the architecture model for ACTN, including the entities Customer Network Controller (CNC), Multidomain Service Coordinator (MDSC), and Provisioning Network Controller (PNC) and their interfaces.
[RFC8453]は、エンティティCustomer Network Controller（CNC）、Multidomain Service Coordinator（MDSC）、Provisioning Network Controller（PNC）およびそれらのインターフェイスを含む、ACTNの高レベルACTN要件とアーキテクチャモデルについて説明しています。
The ACTN reference architecture is shown in Figure 1, which is reproduced here from [RFC8453] for convenience. [RFC8453] remains the definitive reference for the ACTN architecture. As depicted in Figure 1, the ACTN architecture identifies a three-tier hierarchy.
ACTNリファレンスアーキテクチャを図1に示します。これは、便宜上[RFC8453]からここに複製されています。 [RFC8453]は、引き続きACTNアーキテクチャの最も信頼できるリファレンスです。図1に示すように、ACTNアーキテクチャは3層の階層を識別します。
+---------+ +---------+ +---------+
| CNC | | CNC | | CNC |
+---------+ +---------+ +---------+
\ | /
\ | /
Boundary =============\==============|==============/============
Between \ | /
Customer & ------- | CMI -------
Network Operator \ | /
+---------------+
| MDSC |
+---------------+
/ | \
------------ | MPI -------------
/ | \
+-------+ +-------+ +-------+
| PNC | | PNC | | PNC |
+-------+ +-------+ +-------+
| SBI / | / \
| / | SBI / \
--------- ----- | / \
( ) ( ) | / \
- Control - ( Phys. ) | / -----
( Plane ) ( Net ) | / ( )
( Physical ) ----- | / ( Phys. )
( Network ) ----- ----- ( Net )
- - ( ) ( ) -----
( ) ( Phys. ) ( Phys. )
--------- ( Net ) ( Net )
----- -----
CMI - (CNC-MDSC Interface) MPI - (MDSC-PNC Interface) SBI - (Southbound Interface)
CMI-（CNC-MDSCインターフェース）MPI-（MDSC-PNCインターフェース）SBI-（サウスバウンドインターフェース）
Figure 1: ACTN Hierarchy
図1：ACTN階層
There are two interfaces with respect to the MDSC: one north of the MDSC (the CNC-MDSC Interface (CMI)), and one south (the MDSC-PNC Interface (MPI)). A hierarchy of MDSCs is possible with a recursive MPI interface.
MDSCに関しては、MDSCの北側（CNC-MDSCインターフェイス（CMI））と南側（MDSC-PNCインターフェイス（MPI））の2つのインターフェイスがあります。 MDSCの階層は、再帰的なMPIインターフェイスで可能です。
[RFC8454] provides an information model for ACTN interfaces.
[RFC8454]は、ACTNインターフェイスの情報モデルを提供します。
The ACTN architecture [RFC8453] is based on the hierarchy and recursiveness of controllers. It defines three types of controllers (depending on the functionalities they implement). The main functionalities are:
ACTNアーキテクチャ[RFC8453]は、コントローラの階層と再帰性に基づいています。 3つのタイプのコントローラーを定義します（コントローラーが実装する機能によって異なります）。主な機能は次のとおりです。
o Multidomain coordination
o マルチドメイン調整
o Abstraction
o 抽象化
o Customer mapping/translation
o カスタマーマッピング/翻訳
o Virtual service coordination
o 仮想サービスの調整
Section 3 of [RFC8453] describes these functions.
[RFC8453]のセクション3では、これらの機能について説明しています。
It should be noted that this document lists all possible ways in which PCE could be used for each of the above functions, but all functions are not required to be implemented via PCE. Similarly, this document presents the ways in which PCEP could be used as the communications medium between functional components. Operators may choose to use the PCEP for multidomain coordination via stateful H-PCE but alternatively use Network Configuration Protocol (NETCONF) [RFC6241], RESTCONF [RFC8040], or BGP - Link State (BGP-LS) [RFC7752] to get access to the topology and support abstraction function.
このドキュメントでは、PCEを上記の各機能に使用できるすべての可能な方法をリストしていますが、すべての機能をPCE経由で実装する必要はありません。同様に、このドキュメントでは、PCEPを機能コンポーネント間の通信媒体として使用する方法を示します。オペレーターは、ステートフルH-PCEを介したマルチドメイン調整にPCEPを使用することを選択できますが、代わりにネットワーク構成プロトコル（NETCONF）[RFC6241]、RESTCONF [RFC8040]、またはBGP-リンク状態（BGP-LS）[RFC7752]を使用して、トポロジおよびサポート抽象化機能。
With the definition of domain being everything that is under the control of the single logical controller, as per [RFC8453], it is needed both to have a control entity that oversees the specific aspects of the different domains and to build a single abstracted end-to-end network topology in order to coordinate end-to-end path computation and path/service provisioning.
[RFC8453]のように、ドメインの定義はすべて単一の論理コントローラーの制御下にあるものであるため、さまざまなドメインの特定の側面を監視する制御エンティティと、単一の抽象化されたエンドを構築することの両方が必要です。エンドツーエンドパス計算とパス/サービスプロビジョニングを調整するためのエンドツーネットワークトポロジ。
The MDSC in ACTN framework realizes this function by coordinating the per-domain PNCs in a hierarchy of controllers. It also needs to detach from the underlying network technology and express customer concerns by business needs.
ACTNフレームワークのMDSCは、コントローラーの階層でドメインごとのPNCを調整することにより、この機能を実現します。また、基盤となるネットワークテクノロジーから切り離し、ビジネスニーズによって顧客の懸念を表明する必要もあります。
[RFC6805] and [PCE-HPCE] describe a hierarchy of PCEs with the Parent PCE coordinating multidomain path computation function between Child PCEs. It is easy to see how these principles align, and thus how the stateful H-PCE architecture can be used to realize ACTN.
[RFC6805]および[PCE-HPCE]は、親PCEが子PCE間のマルチドメインパス計算機能を調整するPCEの階層を記述します。これらの原則がどのように整合しているか、したがってステートフルH-PCEアーキテクチャを使用してACTNを実現する方法を簡単に確認できます。
The per-domain stitched LSP in the Hierarchical stateful PCE architecture, described in Section 3.3.1 of [PCE-HPCE], is well suited for multidomain coordination function. This includes domain sequence selection, End-to-End (E2E) path computation, and controller-initiated (PCE-initiated) path setup and reporting. This is also applicable to multilayer coordination in case of IP+optical networks.
[PCE-HPCE]のセクション3.3.1で説明されている、階層的ステートフルPCEアーキテクチャにおけるドメインごとのステッチLSPは、マルチドメイン調整機能に適しています。これには、ドメインシーケンスの選択、エンドツーエンド（E2E）パス計算、およびコントローラー開始（PCE開始）パスのセットアップとレポートが含まれます。これは、IP +光ネットワークの場合のマルチレイヤ調整にも適用できます。
[PCE-STATE-SYNC] describes the procedures to allow a stateful communication between PCEs for various use cases. The procedures and extensions are also applicable to Child and Parent PCE communication and are thus useful for ACTN as well.
[PCE-STATE-SYNC]は、さまざまなユースケースでPCE間のステートフル通信を可能にする手順を説明しています。手順と拡張は、子と親のPCE通信にも適用できるため、ACTNにも役立ちます。
To realize ACTN, an abstracted view of the underlying network resources needs to be built. This includes global network-wide abstracted topology based on the underlying network resources of each domain. This also includes abstract topology created as per the customer service connectivity requests and represented as a VN slice allocated to each customer.
ACTNを実現するには、基盤となるネットワークリソースの抽象化されたビューを構築する必要があります。これには、各ドメインの基盤となるネットワークリソースに基づく、ネットワーク全体の抽象化されたグローバルトポロジが含まれます。これには、カスタマーサービスの接続要求に従って作成され、各カスタマーに割り当てられたVNスライスとして表される抽象的なトポロジも含まれます。
In order to compute and provide optimal paths, PCEs require an accurate and timely Traffic Engineering Database (TED). Traditionally, this TED has been obtained from a link-state (LS) routing protocol supporting traffic engineering extensions. PCE may construct its TED by participating in the IGP ([RFC3630] and [RFC5305] for MPLS-TE; [RFC4203] and [RFC5307] for GMPLS). An alternative is offered by BGP-LS [RFC7752].
PCEは、最適なパスを計算して提供するために、正確でタイムリーなトラフィックエンジニアリングデータベース（TED）を必要とします。従来、このTEDは、トラフィックエンジニアリング拡張をサポートするリンクステート（LS）ルーティングプロトコルから取得されてきました。 PCEは、IGP（MPLS-TEの場合は[RFC3630]および[RFC5305]、GMPLSの場合は[RFC4203]および[RFC5307]）に参加することにより、TEDを構築できます。 BGP-LS [RFC7752]によって代替案が提供されています。
In case of H-PCE [RFC6805], the Parent PCE needs to build the domain topology map of the child domains and their interconnectivity. [RFC6805] and [PCE-INTER-AREA] suggest that BGP-LS could be used as a "northbound" TE advertisement from the Child PCE to the Parent PCE.
H-PCE [RFC6805]の場合、親PCEは子ドメインとその相互接続のドメイントポロジーマップを作成する必要があります。 [RFC6805]と[PCE-INTER-AREA]は、BGP-LSを子PCEから親PCEへの「ノースバウンド」TEアドバタイズメントとして使用できることを示唆しています。
[PCEP-LS] proposes another approach for learning and maintaining the Link-State and TE information as an alternative to IGPs and BGP flooding, using PCEP itself. The Child PCE can use this mechanism to transport Link-State and TE information from Child PCE to a Parent PCE using PCEP.
[PCEP-LS]は、PCEP自体を使用して、IGPおよびBGPフラッディングの代替としてリンクステートおよびTE情報を学習および維持するための別のアプローチを提案します。子PCEはこのメカニズムを使用して、PCEPを使用して子PCEから親PCEにリンク状態およびTE情報を転送できます。
In ACTN, there is a need to control the level of abstraction based on the deployment scenario and business relationship between the controllers. The mechanism used to disseminate information from the PNC (Child PCE) to the MDSC (Parent PCE) should support abstraction. [RFC8453] describes a few alternative approaches of abstraction. The resulting abstracted topology can be encoded using the PCEP-LS mechanisms [PCEP-LS] and its optical network extension
ACTNでは、展開シナリオとコントローラ間のビジネス関係に基づいて、抽象化のレベルを制御する必要があります。 PNC（子PCE）からMDSC（親PCE）に情報を配布するために使用されるメカニズムは、抽象化をサポートする必要があります。 [RFC8453]は、抽象化のいくつかの代替アプローチについて説明しています。結果の抽象化されたトポロジは、PCEP-LSメカニズム[PCEP-LS]とその光ネットワーク拡張を使用してエンコードできます
[PCEP-OPTICAL]. PCEP-LS is an attractive option when the operator would wish to have a single control-plane protocol (PCEP) to achieve ACTN functions.
[PCEP-OPTICAL]。 PCEP-LSは、オペレーターがACTN機能を実現するために単一のコントロールプレーンプロトコル（PCEP）を必要とする場合に魅力的なオプションです。
[RFC8453] discusses two ways to build abstract topology from an MDSC standpoint with interaction with PNCs. The primary method is called automatic generation of abstract topology by configuration. With this method, automatic generation is based on the abstraction/ summarization of the whole domain by the PNC and its advertisement on the MPI. The secondary method is called on-demand generation of supplementary topology via Path Compute Request/Reply. This method may be needed to obtain further complementary information such as potential connectivity from Child PCEs in order to facilitate an end-to-end path provisioning. PCEP is well suited to support both methods.
[RFC8453]は、MDSCの観点からPNCとの相互作用を使用して抽象的なトポロジを構築する2つの方法について説明しています。主な方法は、構成による抽象的なトポロジの自動生成と呼ばれます。この方法では、自動生成は、PNCによるドメイン全体の抽象化/要約とMPIでのそのアドバタイズに基づいています。 2番目の方法は、Path Compute Request / Replyを介した補足トポロジのオンデマンド生成と呼ばれます。この方法は、エンドツーエンドのパスプロビジョニングを容易にするために、子PCEから接続の可能性などの補足情報を取得するために必要になる場合があります。 PCEPは、両方の方法をサポートするのに適しています。
In ACTN, there is a need to map customer virtual network (VN) requirements into a network provisioning request to the PNC. That is, the customer requests/commands are mapped by the MDSC into network provisioning requests that can be sent to the PNC. Specifically, the MDSC provides mapping and translation of a customer's service request into a set of parameters that are specific to a network type and technology such that the network configuration process is made possible.
ACTNでは、顧客の仮想ネットワーク（VN）要件をPNCへのネットワークプロビジョニング要求にマッピングする必要があります。つまり、顧客の要求/コマンドは、MDSCによって、PNCに送信できるネットワークプロビジョニング要求にマッピングされます。具体的には、MDSCは、ネットワーク構成プロセスが可能になるように、顧客のサービス要求のマッピングと、ネットワークタイプおよびテクノロジーに固有のパラメーターのセットへの変換を提供します。
[RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model, without the need for local configuration on the PCC, thus allowing for a dynamic network that is centrally controlled and deployed. To instantiate or delete an LSP, the PCE sends the Path Computation LSP Initiate Request (PCInitiate) message to the PCC. As described in [PCE-HPCE], for interdomain LSP in Hierarchical PCE architecture, the initiation operations can be carried out at the Parent PCE. In this case, after Parent PCE finishes the E2E path computation, it can send the PCInitiate message to the Child PCE; the Child PCE further propagates the initiate request to the Label Switching Router (LSR). The customer request is received by the MDSC (Parent PCE), and, based on the business logic, global abstracted topology, network conditions, and local policy, the MDSC (Parent PCE) translates this into a per-domain LSP initiation request that a PNC (Child PCE) can understand and act on. This can be done via the PCInitiate message.
[RFC8281]は、PCCでのローカル設定を必要とせず、ステートフルPCEモデルでのPCEによって開始されたLSPのセットアップ、メンテナンス、およびティアダウンについて説明し、中央で制御および展開される動的ネットワークを可能にします。 LSPをインスタンス化または削除するために、PCEはパス計算LSP開始要求（PCInitiate）メッセージをPCCに送信します。 [PCE-HPCE]で説明されているように、階層PCEアーキテクチャのドメイン間LSPの場合、開始操作は親PCEで実行できます。この場合、親PCEがE2Eパスの計算を完了した後、PCInitiateメッセージを子PCEに送信できます。子PCEはさらに、開始要求をラベルスイッチングルーター（LSR）に伝達します。顧客の要求はMDSC（親PCE）によって受信され、ビジネスロジック、グローバル抽象化トポロジ、ネットワーク条件、およびローカルポリシーに基づいて、MDSC（親PCE）はこれをドメインごとのLSP開始要求に変換します。 PNC（Child PCE）は理解して行動することができます。これは、PCInitiateメッセージを介して実行できます。
PCEP extensions for associating opaque policy between PCEP peer [ASSOC-POLICY] can be used.
PCEPピア[ASSOC-POLICY]間の不透明なポリシーを関連付けるためのPCEP拡張機能を使用できます。
Virtual service coordination function in ACTN incorporates customer service-related information into the virtual network service operations in order to seamlessly operate virtual networks while meeting customers' service requirements.
ACTNの仮想サービス調整機能は、顧客のサービス要件を満たしながら仮想ネットワークをシームレスに運用するために、顧客サービス関連の情報を仮想ネットワークサービスの運用に組み込みます。
[PCEP-VN] describes the need for associating a set of LSPs with a VN "construct" to facilitate VN operations in PCE architecture. This association allows the PCEs to identify which LSPs belong to a certain VN.
[PCEP-VN]は、PCEアーキテクチャでのVN操作を容易にするために、LSPのセットをVN "構成"に関連付ける必要性について説明しています。この関連付けにより、PCEは特定のVNに属するLSPを識別できます。
This association based on VN is useful for various optimizations at the VN level, which can be applied to all the LSPs that are part of the VN slice. During path computation, the impact of a path for an LSP is compared against the paths of other LSPs in the VN. This is to ensure optimization and SLA attainment for the VN rather than for a single LSP. Similarly, during reoptimization, advanced path computation algorithms and optimization techniques can be considered for all the LSPs belonging to a VN/customer and optimize them all together.
VNに基づくこの関連付けは、VNレベルでのさまざまな最適化に役立ちます。これは、VNスライスの一部であるすべてのLSPに適用できます。パスの計算中に、LSPのパスの影響が、VN内の他のLSPのパスと比較されます。これは、単一のLSPではなくVNの最適化とSLA達成を確実にするためです。同様に、再最適化中に、VN /顧客に属するすべてのLSPに対して高度なパス計算アルゴリズムと最適化技術を検討し、それらをすべて一緒に最適化できます。
As per [RFC8453], to allow virtualization and multidomain coordination, the network has to provide open, programmable interfaces in which customer applications can create, replace, and modify virtual network resources and services in an interactive, flexible, and dynamic fashion while having no impact on other customers. The two ACTN interfaces are as follows:
[RFC8453]に従って、仮想化とマルチドメイン調整を可能にするために、ネットワークはオープンでプログラム可能なインターフェイスを提供する必要があります。他の顧客への影響。 2つのACTNインターフェイスは次のとおりです。
o The CNC-MDSC Interface (CMI) is an interface between a Customer Network Controller and a Multidomain Service Coordinator. It requests the creation of the network resources, topology, or services for the applications. The MDSC may also report potential network topology availability if queried for current capability from the Customer Network Controller.
o CNC-MDSCインターフェース（CMI）は、カスタマーネットワークコントローラーとマルチドメインサービスコーディネーター間のインターフェースです。アプリケーションのネットワークリソース、トポロジ、またはサービスの作成を要求します。 MDSCは、カスタマーネットワークコントローラーから現在の機能を照会された場合、潜在的なネットワークトポロジの可用性も報告する場合があります。
o The MDSC-PNC Interface (MPI) is an interface between a Multidomain Service Coordinator and a Provisioning Network Controller. It communicates the creation request, if required, of new connectivity of bandwidth changes in the physical network via the PNC. In multidomain environments, the MDSC needs to establish multiple MPIs, one for each PNC, as there are multiple PNCs responsible for its domain control.
o MDSC-PNCインターフェイス（MPI）は、マルチドメインサービスコーディネーターとプロビジョニングネットワークコントローラー間のインターフェイスです。必要に応じて、PNCを介して物理ネットワークの帯域幅変更の新しい接続の作成要求を伝達します。マルチドメイン環境では、MDSCはドメイン制御を担当する複数のPNCがあるため、各PNCに1つずつ、複数のMPIを確立する必要があります。
In the case of a hierarchy of MDSCs, the MPI is applied recursively. From an abstraction point of view, the top-level MDSC, which interfaces the CNC, operates on a higher level of abstraction (i.e., less granular level) than the lower-level MDSCs.
MDSCの階層の場合、MPIは再帰的に適用されます。抽象化の観点から見ると、CNCとインターフェースする最上位のMDSCは、下位のMDSCよりも高い抽象化レベル（つまり、粒度の低いレベル）で動作します。
PCEP is especially suitable on the MPI as it meets the requirement and the functions as set out in the ACTN framework [RFC8453]. Its recursive nature is well suited via the multilevel hierarchy of PCE. PCEP can also be applied to the CMI as the CNC can be a path computation client while the MDSC can be a path computation server. Section 5 describes how PCE and PCEP could help realize ACTN on the MPI.
PCEPは、ACTNフレームワーク[RFC8453]で規定されている要件と機能を満たしているため、MPIに特に適しています。その再帰的な性質は、PCEのマルチレベル階層を介して非常に適しています。 MDSCがパス計算サーバーになることができる一方で、CNCがパス計算クライアントになることができるので、PCEPはCMIに適用することもできます。セクション5では、PCEおよびPCEPがMPIでのACTNの実現にどのように役立つかについて説明します。
As per the example in Figure 2, there are 4 domains, each with their own PNC and MDSC on top. The PNC and MDSC need PCE as an important function. The PNC (or Child PCE) already uses PCEP to communicate to the network device. It can utilize the PCEP as the MPI to communicate between controllers too.
図2の例のように、4つのドメインがあり、それぞれに独自のPNCとMDSCがあります。 PNCとMDSCには、重要な機能としてPCEが必要です。 PNC（または子PCE）はすでにPCEPを使用してネットワークデバイスと通信しています。また、コントローラー間で通信するためのMPIとしてPCEPを利用できます。
******
..........*MDSC*..............................
. ****** .. MPI .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
v v v .
****** ****** ****** .
*PNC1* *PNC2* *PNC4* .
****** ****** ****** .
+---------------+ +---------------+ +---------------+ .
|A |----| |----| C| .
| | | | | | .
|DOMAIN 1 |----|DOMAIN 2 |----|DOMAIN 4 | .
+------------B13+ +---------------+ +B43------------+ .
\ / .
\ ****** / .
\ *PNC3*<............/.....................
\ ****** /
\+---------------+/
B31 B34
| |
|DOMAIN 3 B|
+---------------+
MDSC -> Parent PCE
PNC -> Child PCE
MPI -> PCEP
Figure 2: ACTN with PCE
図2：PCEを使用したACTN
o Building Domain Topology at MDSC: PNC (or Child PCE) needs to have the TED to compute the path in its domain. As described in Section 3.2, it can learn the topology via IGP or BGP-LS. PCEP-LS is also a proposed mechanism to carry link state and traffic engineering information within PCEP. A mechanism to carry abstracted topology while hiding technology-specific information between PNC and MDSC is described in [PCEP-LS]. At the end of this step, the MDSC (or Parent PCE) has the abstracted topology from each of its PNCs (or Child PCE). This could be as simple as a domain topology map as described in [RFC6805], or it can have full topology information of all domains. The latter is not scalable, and thus, an abstracted topology of each domain interconnected by interdomain links is the most common case.
o MDSCでのドメイントポロジの構築：PNC（または子PCE）には、ドメイン内のパスを計算するためのTEDが必要です。セクション3.2で説明したように、IGPまたはBGP-LSを介してトポロジを学習できます。 PCEP-LSは、PCEP内でリンク状態とトラフィックエンジニアリング情報を伝達するために提案されているメカニズムでもあります。 PNCとMDSCの間で技術固有の情報を隠しながら、抽象化されたトポロジーを伝送するメカニズムは、[PCEP-LS]で説明されています。このステップの最後に、MDSC（または親PCE）は、そのPNC（または子PCE）のそれぞれから抽象化されたトポロジーを持ちます。これは、[RFC6805]で説明されているドメイントポロジマップのように単純な場合もあれば、すべてのドメインの完全なトポロジ情報を持つ場合もあります。後者はスケーラブルではないため、ドメイン間リンクによって相互接続された各ドメインの抽象化されたトポロジが最も一般的なケースです。
* Topology Change: When the PNC learns of any topology change, the PNC needs to decide if the change needs to be notified to the MDSC. This is dependent on the level of abstraction between the MDSC and the PNC.
* トポロジーの変更：PNCがトポロジーの変更を認識すると、変更をMDSCに通知する必要があるかどうかをPNCが判断する必要があります。これは、MDSCとPNC間の抽象化のレベルに依存します。
o VN Instantiate: When an MDSC is requested to instantiate a VN, the minimal information that is required would be a VN identifier and a set of end points. Various path computation, setup constraints, and objective functions may also be provided. In PCE terms, a VN Instantiate can be considered as a set of paths belonging to the same VN. As described in Section 3.4 and [PCEP-VN], the VN association can help in identifying the set of paths that belong to a VN. The rest of the information, like the endpoints, constraints, and objective function (OF), is already defined in PCEP in terms of a single path.
o VNインスタンス化：VNをインスタンス化するためにMDSCが要求された場合、必要な最小限の情報は、VN識別子とエンドポイントのセットです。さまざまなパス計算、セットアップ制約、目的関数も提供されます。 PCE用語では、VN Instantiateは同じVNに属するパスのセットと見なすことができます。セクション3.4および[PCEP-VN]で説明されているように、VNアソシエーションは、VNに属するパスのセットを識別するのに役立ちます。エンドポイント、制約、目的関数（OF）などの残りの情報は、単一のパスに関してPCEPで既に定義されています。
* Path Computation: As per the example in Figure 2, the VN instantiate requires two end-to-end paths between (A in Domain 1 to B in Domain 3) and (A in Domain 1 to C in Domain 4). The MDSC (or Parent PCE) triggers the end-to-end path computation for these two paths. MDSC can do path computation based on the abstracted domain topology that it already has, or it may use the H-PCE procedures (Section 3.1) using the PCReq and PCRep messages to get the end-to-end path with the help of the Child PCEs (PNC). Either way, the resultant E2E paths may be broken into per-domain paths.
* パス計算：図2の例のように、VNインスタンス化には（ドメイン1のAからドメイン3のB）と（ドメイン1のAからドメイン4のC）の間に2つのエンドツーエンドパスが必要です。 MDSC（または親PCE）は、これら2つのパスのエンドツーエンドパス計算をトリガーします。 MDSCは、すでに持っている抽象化されたドメイントポロジに基づいてパス計算を実行できます。または、PCReqおよびPCRepメッセージを使用してH-PCE手順（セクション3.1）を使用し、子の助けを借りてエンドツーエンドパスを取得できます。 PCE（PNC）。どちらの方法でも、結果のE2Eパスはドメインごとのパスに分割される可能性があります。
* A-B: (A-B13,B13-B31,B31-B)
* A-B：（A-B13、B13-B31、B31-B）
* A-C: (A-B13,B13-B31,B31-B34,B34-B43,B43-C)
* A-C：（A-B13、B13-B31、B31-B34、B34-B43、B43-C）
* Per-Domain Path Instantiation: Based on the above path computation, MDSC can issue the path instantiation request to each PNC via PCInitiate message (see [PCE-HPCE] and [PCEP-VN]). A suitable stitching mechanism would be used to stitch these per-domain LSPs. One such mechanism is described in [PCE-INTERDOMAIN], where PCEP is extended to support stitching in stateful H-PCE context.
* ドメインごとのパスのインスタンス化：上記のパス計算に基づいて、MDSCはPCInitiateメッセージを介して各PNCにパスのインスタンス化要求を発行できます（[PCE-HPCE]および[PCEP-VN]を参照）。これらのドメインごとのLSPをステッチするには、適切なステッチメカニズムを使用します。そのようなメカニズムの1つが[PCE-INTERDOMAIN]で説明されています。PCEPは、ステートフルH-PCEコンテキストでのスティッチングをサポートするように拡張されています。
* Per-Domain Path Report: Each PNC should report the status of the per-domain LSP to the MDSC via PCRpt message, as per the hierarchy of stateful PCEs ([PCE-HPCE]). The status of the end-to-end LSP (A-B and A-C) is made up when all the per-domain LSPs are reported up by the PNCs.
* ドメインごとのパスレポート：各PNCは、ステートフルPCE（[PCE-HPCE]）の階層に従って、ドメインごとのLSPのステータスをPCRptメッセージを介してMDSCに報告する必要があります。エンドツーエンドLSP（A-BおよびA-C）のステータスは、すべてのドメインごとのLSPがPNCによって報告されたときに構成されます。
* Delegation: It is suggested that the per-domain LSPs are delegated to respective PNCs so that they can control the path and attributes based on the conditions of each domain network.
* 委任：各ドメインネットワークの条件に基づいてパスと属性を制御できるように、ドメインごとのLSPをそれぞれのPNCに委任することをお勧めします。
* State Synchronization: The state needs to be synchronized between the Parent PCE and Child PCE. The mechanism described in [PCE-STATE-SYNC] can be used.
* 状態の同期：状態は、親PCEと子PCEの間で同期する必要があります。 [PCE-STATE-SYNC]で説明されているメカニズムを使用できます。
o VN Modify: MDSC is requested to modify a VN, for example, the bandwidth for VN is increased. This may trigger path computation at MDSC as described in the previous step and can trigger an update to an existing per-intradomain path (via PCUpd message) or the creation (or deletion) of a per-domain path (via PCInitiate message). As described in [PCE-HPCE], this should be done in make-before-break fashion.
o VNの変更：MDSCは、VNを変更するように要求されます。たとえば、VNの帯域幅が増加します。これにより、前のステップで説明したようにMDSCでパス計算がトリガーされ、既存のドメイン内パスへの更新（PCUpdメッセージによる）またはドメインごとのパスの作成（または削除）（PCInitiateメッセージによる）がトリガーされます。 [PCE-HPCE]で説明されているように、これはmake-before-breakの方法で行う必要があります。
o VN Delete: MDSC is requested to delete a VN, in this case, based on the E2E paths, and the resulting per-domain paths need to be removed (via PCInitiate message).
o VN削除：MDSCは、この場合、E2Eパスに基づいてVNを削除するように要求され、結果のドメインごとのパスは（PCInitiateメッセージを介して）削除する必要があります。
o VN Update (based on network changes): Any change in the per-domain LSP is reported to the MDSC (via PCRpt message) as per [PCE-HPCE]. This may result in changes in the E2E path or VN status. This may also trigger a reoptimization leading to a new per-domain path, an update to an existing path, or the deletion of the path.
o VNアップデート（ネットワークの変更に基づく）：ドメインごとのLSPの変更は、[PCE-HPCE]に従って（PCRptメッセージを介して）MDSCに報告されます。これにより、E2EパスまたはVNステータスが変更される可能性があります。これにより、再最適化がトリガーされ、新しいドメインごとのパス、既存のパスの更新、またはパスの削除が発生する場合もあります。
o VN Protection: The VN protection/restoration requirements need to be applied to each E2E path as well as each per-domain path. The MDSC needs to play a crucial role in coordinating the right protection/restoration policy across each PNC. The existing protection/restoration mechanism of PCEP can be applied on each path.
o VN保護：VN保護/復元要件は、各E2Eパスと各ドメインパスに適用する必要があります。 MDSCは、各PNC全体で適切な保護/復元ポリシーを調整する上で重要な役割を果たす必要があります。 PCEPの既存の保護/復元メカニズムは、各パスに適用できます。
o In case a PNC generates an abstract topology towards the MDSC, the PCInitiate/PCUpd messages from the MDSC to a PNC will contain a path with abstract nodes and links. A PNC would need to take that as an input for path computation to get a path with physical nodes and links. Similarly, a PNC would convert the path received from the device (with physical nodes and links) into an abstract path (based on the abstract topology generated before with abstract nodes and links) and report it to the MDSC.
o PNCがMDSCへの抽象的なトポロジを生成する場合、MDSCからPNCへのPCInitiate / PCUpdメッセージには、抽象的なノードとリンクを持つパスが含まれます。 PNCは、物理ノードとリンクを持つパスを取得するために、それをパス計算の入力として受け取る必要があります。同様に、PNCは、デバイスから受信したパス（物理ノードとリンクを含む）を（以前に抽象ノードとリンクを使って生成した抽象トポロジに基づいて）抽象パスに変換し、それをMDSCに報告します。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
Various security considerations for PCEP are described in [RFC5440] and [RFC8253]. Security considerations as stated in Sections 10.1, 10.6, and 10.7 of [RFC5440] continue to apply on PCEP when used as an ACTN interface. Further, this document lists various extensions of PCEP that are applicable; each of them specify various security considerations that continue to apply here.
PCEPのさまざまなセキュリティの考慮事項は、[RFC5440]と[RFC8253]で説明されています。 [RFC5440]のセクション10.1、10.6、および10.7で述べられているセキュリティの考慮事項は、ACTNインターフェイスとして使用される場合、PCEPにも引き続き適用されます。さらに、このドキュメントには、適用可能なPCEPのさまざまな拡張機能がリストされています。それぞれが、ここで引き続き適用されるさまざまなセキュリティの考慮事項を指定します。
The ACTN framework described in [RFC8453] defines key components and interfaces for managed traffic-engineered networks. It also lists various security considerations such as request and control of resources, confidentially of the information, and availability of function, which should be taken into consideration.
[RFC8453]で説明されているACTNフレームワークは、マネージドトラフィックエンジニアリングネットワークの主要なコンポーネントとインターフェイスを定義します。また、リソースの要求と制御、情報の機密保持、考慮すべき機能の可用性など、さまざまなセキュリティの考慮事項も示します。
As per [RFC8453], securing the request and control of resources, confidentiality of the information, and availability of function should all be critical security considerations when deploying and operating ACTN platforms. From a security and reliability perspective, ACTN may encounter many risks such as malicious attack and rogue elements attempting to connect to various ACTN components (with PCE being one of them). Furthermore, some ACTN components represent a single point of failure and threat vector, and must also manage policy conflicts and eavesdropping of communication between different ACTN components. [RFC8453] further states that all protocols used to realize the ACTN framework should have rich security features, and customer, application, and network data should be stored in encrypted data stores. When PCEP is used as an ACTN interface, the security of PCEP provided by Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525] (unless explicitly set aside in [RFC8253]), is used.
[RFC8453]によると、リソースの要求と制御の保護、情報の機密性、および機能の可用性は、ACTNプラットフォームを展開および運用する際のセキュリティに関する重要な考慮事項です。セキュリティと信頼性の観点から、ACTNはさまざまなACTNコンポーネント（PCEがその1つである）に接続しようとする悪意のある攻撃や不正な要素などの多くのリスクに遭遇する可能性があります。さらに、一部のACTNコンポーネントは、単一障害点と脅威ベクトルを表し、ポリシーの競合と異なるACTNコンポーネント間の通信の盗聴を管理する必要もあります。 [RFC8453]はさらに、ACTNフレームワークを実現するために使用されるすべてのプロトコルが豊富なセキュリティ機能を備えている必要があり、顧客、アプリケーション、およびネットワークデータは暗号化されたデータストアに格納する必要があると述べています。 PCEPがACTNインターフェイスとして使用される場合、トランスポート層セキュリティ（TLS）[RFC8253]によって提供されるPCEPのセキュリティが、[RFC7525]の推奨事項と現在のベストプラクティスに従って（[RFC8253]で明示的に設定されていない限り）使用されます。 。
As per [RFC8453], regarding the MPI, a PKI-based mechanism is suggested, such as building a TLS or HTTPS connection between the MDSC and PNCs, to ensure trust between the physical network layer control components and the MDSC. Which MDSC the PNC exports topology information to, and the level of detail (full or abstracted), should also be authenticated, and specific access restrictions and topology views should be configurable and/or policy based. When PCEP is used in MPI, the security functions, as per [RFC8253], are used to fulfill these requirements.
[RFC8453]のとおり、MPIに関しては、物理ネットワークレイヤー制御コンポーネントとMDSC間の信頼を確保するために、MDSCとPNC間のTLSまたはHTTPS接続の構築など、PKIベースのメカニズムが推奨されます。 PNCがトポロジ情報をエクスポートするMDSCと詳細レベル（完全または抽象化）も認証する必要があり、特定のアクセス制限とトポロジビューは構成可能またはポリシーベースである必要があります。 PCEPがMPIで使用される場合、[RFC8253]によるセキュリティ機能がこれらの要件を満たすために使用されます。
As per [RFC8453], regarding the CMI, suitable authentication and authorization of each CNC connecting to the MDSC will be required. If PCEP is used in CMI, the security functions, as per [RFC8253], can be used to support peer authentication, message encryption, and integrity checks.
[RFC8453]に従い、CMIに関しては、MDSCに接続する各CNCの適切な認証と承認が必要になります。 PCEPがCMIで使用されている場合、[RFC8253]のセキュリティ機能を使用して、ピア認証、メッセージ暗号化、および整合性チェックをサポートできます。
[RFC4655] Farrel, A., Vasseur, J., 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>.
[RFC4655] Farrel、A.、Vasseur、J。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：//www.rfc -editor.org/info/rfc4655>。
[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>.
[RFC5440] Vasseur、JP。、Ed。とJL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https://www.rfc-editor.org/info/rfc5440>。
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, DOI 10.17487/RFC6805, November 2012, <https://www.rfc-editor.org/info/rfc6805>.
[RFC6805]キング、D。、エド。およびA.ファレル編、「MPLSおよびGMPLSにおける一連のドメインの決定へのパス計算要素アーキテクチャの適用」、RFC 6805、DOI 10.17487 / RFC6805、2012年11月、<https：//www.rfc -editor.org/info/rfc6805>。
[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>.
[RFC8453] Ceccarelli、D.、Ed。 Y.リー、編、「TEネットワークの抽象化と制御のフレームワーク（ACTN）」、RFC 8453、DOI 10.17487 / RFC8453、2018年8月、<https://www.rfc-editor.org/info/rfc8453> 。
[ASSOC-POLICY] Litkowski, S., Sivabalan, S., Tantsura, J., Hardwick, J., and M. Negi, "Path Computation Element communication Protocol extension for associating Policies and LSPs", Work in Progress, draft-ietf-pce-association-policy-05, February 2019.
[ASSOC-POLICY] Litkowski、S.、Sivabalan、S.、Tantsura、J.、Hardwick、J。、およびM. Negi、「ポリシーとLSPを関連付けるためのパス計算要素通信プロトコル拡張」、作業中、ドラフト- ietf-pce-association-policy-05、2019年2月。
[EXP] Casellas, R., Vilalta, R., Martinez, R., Munoz, R., Zheng, H., and Y. Lee, "Experimental Validation of the ACTN architecture for flexi-grid optical networks using Active Stateful Hierarchical PCEs", 19th International Conference on Transparent Optical Networks (ICTON), DOI 10.5281/zenodo.832904, July 2017, <https://zenodo.org/record/832904>.
[EXP] Casellas、R.、Vilalta、R.、Martinez、R.、Munoz、R.、Zheng、H。、およびY. Lee、「アクティブステートフル階層を使用したフレキシグリッド光ネットワークのACTNアーキテクチャの実験的検証PCE」、第19回透明光ネットワークに関する国際会議（ICTON）、DOI 10.5281 / zenodo.832904、2017年7月、<https://zenodo.org/record/832904>。
[PCE-HPCE] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King, "Hierarchical Stateful Path Computation Element (PCE).", Work in Progress, draft-ietf-pce-stateful-hpce-10, June 2019.
[PCE-HPCE] Dhody、D.、Lee、Y.、Ceccarelli、D.、Shin、J。、およびD. King、「Hierarchical Stateful Path Computation Element（PCE）。」、Work in Progress、draft-ietf- pce-stateful-hpce-10、2019年6月。
[PCE-INTER-AREA] King, D. and H. Zheng, "Applicability of the Path Computation Element to Interarea and Inter-AS MPLS and GMPLS Traffic Engineering", Work in Progress, draft-ietf-pce-inter-area-as-applicability-07, December 2018.
[PCE-INTER-AREA]キング、D.、H。ジェン、「エリア間およびInter-AS MPLSおよびGMPLSトラフィックエンジニアリングへのパス計算要素の適用性」、進行中の作業、draft-ietf-pce-inter-area- as-applicability-07、2018年12月。
[PCE-INTERDOMAIN] Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP Extension for Stateful Interdomain Tunnels", Work in Progress, draft-dugeon-pce-stateful-interdomain-02, March 2019.
[PCE-INTERDOMAIN] Dugeon、O.、Meuric、J.、Lee、Y。、およびD. Ceccarelli、「ステートフルドメイン間トンネルのPCEP拡張機能」、作業中、draft-dugeon-pce-stateful-interdomain-02、 2019年3月。
[PCE-STATE-SYNC] Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter Stateful Path Computation Element (PCE) Communication Procedures.", Work in Progress, draft-litkowski-pce-state-sync-05, March 2019.
[PCE-STATE-SYNC] Litkowski、S.、Sivabalan、S.、Li、C。、およびH. Zheng、「Inter Stateful Path Computation Element（PCE）Communication Procedures。」、Work in Progress、draft-litkowski-pce -state-sync-05、2019年3月。
[PCEP-LS] Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for Distribution of Link-State and TE Information.", Work in Progress, draft-dhodylee-pce-pcep-ls-13, February 2019.
[PCEP-LS] Dhody、D.、Lee、Y。、およびD. Ceccarelli、「リンク状態とTE情報の配布のためのPCEP拡張機能」、作業中、draft-dhodylee-pce-pcep-ls-13 、2019年2月。
[PCEP-OPTICAL] Lee, Y., Zheng, H., Ceccarelli, D., Wang, W., Park, P., and B. Yoon, "PCEP Extension for Distribution of Link-State and TE information for Optical Networks", Work in Progress, draft-lee-pce-pcep-ls-optical-07, March 2019.
[PCEP-OPTICAL] Lee、Y.、Zheng、H.、Ceccarelli、D.、Wang、W.、Park、P。、およびB. Yoon、「光ネットワークのリンク状態およびTE情報の配布のためのPCEP拡張"、作業中、draft-lee-pce-pcep-ls-optical-07、2019年3月。
[PCEP-VN] Lee, Y., Zhang, X., and D. Ceccarelli, "Path Computation Element communication Protocol (PCEP) extensions for Establishing Relationships between sets of LSPs and Virtual Networks", Work in Progress, draft-leedhody-pce-vn-association-08, June 2019.
[PCEP-VN] Lee、Y.、Zhang、X。、およびD. Ceccarelli、「一連のLSPと仮想ネットワーク間の関係を確立するためのPath Computation Element Communication Protocol（PCEP）拡張機能」、Work in Progress、draft-leedhody- pce-vn-association-08、2019年6月。
[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>.
[RFC3630] Katz、D.、Kompella、K.、D。Yeung、「Traffic Engineering（TE）Extensions to OSPF Version 2」、RFC 3630、DOI 10.17487 / RFC3630、2003年9月、<https：//www.rfc -editor.org/info/rfc3630>。
[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>.
[RFC4203] Kompella、K.、Ed。およびY. Rekhter編、「汎用マルチプロトコルラベルスイッチング（GMPLS）をサポートするOSPF拡張機能」、RFC 4203、DOI 10.17487 / RFC4203、2005年10月、<https://www.rfc-editor.org/info / rfc4203>。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <https://www.rfc-editor.org/info/rfc5152>.
[RFC5152] Vasseur、JP。、編、Ayyangar、A。、編、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、 RFC 5152、DOI 10.17487 / RFC5152、2008年2月、<https://www.rfc-editor.org/info/rfc5152>。
[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>.
[RFC5212]塩本K.、パパディミトリウ、D。、ルルー、J。、ヴィグールー、M。、およびD.ブルガード、「GMPLSベースのマルチリージョンおよびマルチレイヤーネットワーク（MRN / MLN）の要件」、 RFC 5212、DOI 10.17487 / RFC5212、2008年7月、<https://www.rfc-editor.org/info/rfc5212>。
[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>.
[RFC5305] Li、T。およびH. Smit、「IS-IS Extensions for Traffic Engineering」、RFC 5305、DOI 10.17487 / RFC5305、2008年10月、<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>.
[RFC5307] Kompella、K.、Ed。およびY. Rekhter編、「一般化マルチプロトコルラベルスイッチング（GMPLS）をサポートするIS-IS拡張機能」、RFC 5307、DOI 10.17487 / RFC5307、2008年10月、<https://www.rfc-editor.org / info / rfc5307>。
[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>.
[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、DOI 10.17487 / RFC5441、2009年4月、<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>.
[RFC5623]沖E.、武田T.、ルルーJL、およびA.ファレル、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、RFC 5623、DOI 10.17487 / RFC5623、2009年9月、<https://www.rfc-editor.org/info/rfc5623>。
[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>.
[RFC6241] Enns、R。、編、Bjorklund、M。、編、Schoenwaelder、J。、編、A。Bierman、編、「Network Configuration Protocol（NETCONF）」、RFC 6241、DOI 10.17487 / RFC6241、2011年6月、<https://www.rfc-editor.org/info/rfc6241>。
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.
[RFC7149] Boucadair、M。およびC. Jacquenet、「ソフトウェア定義ネットワーキング：サービスプロバイダー環境内からの展望」、RFC 7149、DOI 10.17487 / RFC7149、2014年3月、<https：//www.rfc-editor。 org / info / rfc7149>。
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <https://www.rfc-editor.org/info/rfc7399>.
[RFC7399]ファレル、A。およびD.キング、「パス計算要素アーキテクチャにおける未回答の質問」、RFC 7399、DOI 10.17487 / RFC7399、2014年10月、<https://www.rfc-editor.org/info/rfc7399 >。
[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>.
[RFC7491] King、D。、およびA. Farrel、「アプリケーションベースのネットワーク操作のためのPCEベースのアーキテクチャ」、RFC 7491、DOI 10.17487 / RFC7491、2015年3月、<https://www.rfc-editor.org/ info / rfc7491>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, <https://www.rfc-editor.org/info/rfc7752>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、and S. Ray、 "North-bound Distribution of Link-State and Traffic Engineering（TE）Information using BGP" 、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<https://www.rfc-editor.org/info/rfc7752>。
[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>.
[RFC8040] Bierman、A.、Bjorklund、M。、およびK. Watsen、「RESTCONFプロトコル」、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https://www.rfc-editor.org/info/rfc8040 >。
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.
[RFC8051]張、X。、エド。 I. Minei、編、「ステートフルパス計算要素（PCE）の適用性」、RFC 8051、DOI 10.17487 / RFC8051、2017年1月、<https://www.rfc-editor.org/info/rfc8051>。
[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>.
[RFC8231] Crabbe、E.、Minei、I.、Medved、J。、およびR. Varga、「Pathful Computation Element Communication Protocol（PCEP）Extensions for Stateful PCE」、RFC 8231、DOI 10.17487 / RFC8231、2017年9月、< https://www.rfc-editor.org/info/rfc8231>。
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
[RFC8253] Lopez、D.、Gonzalez de Dios、O.、Wu、Q。、およびD. Dhody、「PCEPS：TLSの使用によるパス計算要素通信プロトコル（PCEP）のセキュアなトランスポートの提供」、RFC 8253 、DOI 10.17487 / RFC8253、2017年10月、<https://www.rfc-editor.org/info/rfc8253>。
[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>.
[RFC8281] Crabbe、E.、Minei、I.、Sivabalan、S。、およびR. Varga、「ステートフルPCEモデルでのPCEによって開始されるLSPセットアップのパス計算要素通信プロトコル（PCEP）拡張」、RFC 8281、DOI 10.17487 / RFC8281、2017年12月、<https://www.rfc-editor.org/info/rfc8281>。
[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control", RFC 8283, DOI 10.17487/RFC8283, December 2017, <https://www.rfc-editor.org/info/rfc8283>.
[RFC8283] Farrel、A.、Ed。、Zhao、Q.、Ed。、Li、Z。、およびC. Zhou、「中央制御のあるネットワークでのPCEおよびPCE通信プロトコル（PCEP）の使用のためのアーキテクチャ"、RFC 8283、DOI 10.17487 / RFC8283、2017年12月、<https://www.rfc-editor.org/info/rfc8283>。
[RFC8454] Lee, Y., Belotti, S., Dhody, D., Ceccarelli, D., and B. Yoon, "Information Model for Abstraction and Control of TE Networks (ACTN)", RFC 8454, DOI 10.17487/RFC8454, September 2018, <https://www.rfc-editor.org/info/rfc8454>.
[RFC8454] Lee、Y.、Belotti、S.、Dhody、D.、Ceccarelli、D。、およびB. Yoon、「抽象化およびTEネットワークの制御のための情報モデル（ACTN）」、RFC 8454、DOI 10.17487 / RFC8454 、2018年9月、<https://www.rfc-editor.org/info/rfc8454>。
In the paper [EXP], the application of the ACTN architecture is presented to demonstrate the control of a multidomain flexi-grid optical network by proposing, adopting, and extending:
論文[EXP]では、ACTNアーキテクチャのアプリケーションが提示され、提案、採用、拡張によるマルチドメインフレキシグリッド光ネットワークの制御が示されています。
o the Hierarchical active stateful PCE architectures and protocols
o 階層型アクティブステートフルPCEアーキテクチャとプロトコル
o the PCEP protocol to support efficient and incremental link-state topological reporting, known as PCEP-LS
o PCEP-LSとして知られる、効率的でインクリメンタルなリンクステートトポロジーレポートをサポートするPCEPプロトコル
o the per-link partitioning of the optical spectrum based on variable-sized allocated frequency slots enabling network sharing and virtualization
o 可変サイズの割り当てられた周波数スロットに基づく光スペクトルのリンクごとの分割により、ネットワークの共有と仮想化が可能
o the use of a model-based interface to dynamically request the instantiation of virtual networks for specific clients/tenants.
o 特定のクライアント/テナントの仮想ネットワークのインスタンス化を動的に要求するためのモデルベースのインターフェースの使用。
The design and implementation of the test bed are reported in order to validate the approach.
アプローチを検証するために、テストベッドの設計と実装が報告されます。
Acknowledgments
謝辞
The authors would like to thank Jonathan Hardwick for the inspiration behind this document. Further thanks to Avantika for her comments with suggested text.
著者は、このドキュメントの背後にあるインスピレーションを与えてくれたJonathan Hardwickに感謝します。提案されたテキストを含むコメントを提供してくれたAvantikaにさらに感謝します。
Thanks to Adrian Farrel and Daniel King for their substantial reviews.
エイドリアン・ファレルとダニエル・キングの実質的なレビューに感謝します。
Thanks to Yingzhen Qu for RTGDIR review.
RTGDIRのレビューについてYingzhen Quに感謝します。
Thanks to Rifaat Shekh-Yusef for SECDIR review.
SECDIRのレビューを提供してくれたRifaat Shekh-Yusefに感謝します。
Thanks to Meral Shirazipour for GENART review.
GENARTレビューのMeral Shirazipourに感謝します。
Thanks to Roman Danyliw and Barry Leiba for IESG review comments.
IESGレビューコメントを提供してくれたRoman DanyliwとBarry Leibaに感謝します。
Thanks to Deborah Brungard for being the responsible AD.
責任あるADであるDeborah Brungardに感謝します。
Authors' Addresses
著者のアドレス
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
Dhruv Dhodai Huawei Technologies Divyashari Techno Park、Wheatfished Bangalore、Karnataka 2008インド
Email: dhruv.ietf@gmail.com
Young Lee Futurewei Technologies 5340 Legacy Drive, Suite 173 Plano, TX 75024 United States of America
Young Lee Futurewei Technologies 5340 Legacy Drive、Suite 173 Plano、TX 75024アメリカ合衆国
Email: younglee.tx@gmail.com
Daniele Ceccarelli Ericsson Torshamnsgatan,48 Stockholm Sweden
Daniele Ceccarelli Ericsson Torshamnsgatan、48ストックホルムスウェーデン
Email: daniele.ceccarelli@ericsson.com