[要約] 要約：RFC 8283は、中央制御を持つネットワークでPCE（Path Computation Element）とPCE通信プロトコル（PCEP）を使用するためのアーキテクチャについて説明しています。 目的：このRFCの目的は、PCEとPCEPを使用してネットワークのパス計算を効率化し、中央制御を持つネットワークの設計と運用を向上させることです。
Internet Engineering Task Force (IETF) A. Farrel, Ed.
Request for Comments: 8283 Juniper Networks
Category: Informational Q. Zhao, Ed.
ISSN: 2070-1721 R. Li
Huawei Technologies
C. Zhou
Cisco Systems
December 2017
An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control
中央制御のネットワークでPCEおよびPCE通信プロトコル（PCEP）を使用するためのアーキテクチャ
Abstract
概要
The Path Computation Element (PCE) is a core component of Software-Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.
パス計算要素（PCE）は、ソフトウェア定義ネットワーク（SDN）システムのコアコンポーネントです。ネットワーク全体のトラフィックに最適なパスを計算し、パスを更新してネットワークの変化やトラフィックの需要を反映することもできます。
PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP).
PCEは、パス計算要素通信プロトコル（PCEP）を使用してLSPのヘッドエンドに提供されるMPLSラベルスイッチドパス（LSP）のパスを導出するために開発されました。
SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.
SDNは、シグナリングされたMPLSトラフィックエンジニアリング（TE）ネットワークよりも適用範囲が広く、PCEを使用して、静的LSP、セグメントルーティング、Service Function Chaining（SFC）、およびほとんどの形式のルーティングまたは交換ネットワーク。したがって、PCEPをこれらの環境で使用するための制御プロトコルとして検討し、PCEを中央コントローラーとして完全に有効にすることは妥当です。
This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.
このドキュメントでは、中央コントローラーとしてのPCEのアーキテクチャを簡単に紹介し、この環境での制御プロトコルとしてのPCEPの動機と適用性を検討し、プロトコルへの影響を紹介します。 PCEベースの中央コントローラーは、分散型コントロールプレーンをSDNの要素とブレンドし、必ずしも完全に置き換える必要がないため、分散型コントロールプレーンの処理を簡素化できます。
This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.
このドキュメントでは、ユースケースを詳しく説明せず、プロトコル拡張を定義していません。その作業は他のドキュメントに任されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 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/rfc8283.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8283で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Resilience and Scaling . . . . . . . . . . . . . . . . . 8
2.1.1. Partitioned Network . . . . . . . . . . . . . . . . . 9
2.1.2. Multiple Parallel Controllers . . . . . . . . . . . . 10
2.1.3. Hierarchical Controllers . . . . . . . . . . . . . . 12
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Technology-Oriented Applicability . . . . . . . . . . . . 14
3.1.1. Applicability to Control-Plane Operated Networks . . 14
3.1.2. Static LSPs in MPLS . . . . . . . . . . . . . . . . . 14
3.1.3. MPLS Multicast . . . . . . . . . . . . . . . . . . . 15
3.1.4. Transport SDN . . . . . . . . . . . . . . . . . . . . 15
3.1.5. Segment Routing . . . . . . . . . . . . . . . . . . . 15
3.1.6. Service Function Chaining . . . . . . . . . . . . . . 16
3.2. High-Level Applicability . . . . . . . . . . . . . . . . 16
3.2.1. Traffic Engineering . . . . . . . . . . . . . . . . . 16
3.2.2. Traffic Classification . . . . . . . . . . . . . . . 17
3.2.3. Service Delivery . . . . . . . . . . . . . . . . . . 17
4. Protocol Implications / Guidance for Solution Developers . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Manageability Considerations . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
The Path Computation Element (PCE) [RFC4655] was developed to offload path computation function from routers in an MPLS traffic-engineered network. Since then, the role and function of the PCE has grown to cover a number of other uses (such as GMPLS [RFC7025]) and to allow delegated control [RFC8231] and PCE-initiated use of network resources [RFC8281].
パス計算要素（PCE）[RFC4655]は、MPLSトラフィックエンジニアリングネットワークのルーターからパス計算機能をオフロードするために開発されました。それ以来、PCEの役割と機能は、他の多くの用途（GMPLS [RFC7025]など）に対応し、委任された制御[RFC8231]とPCEによるネットワークリソースの使用[RFC8281]を可能にするまでになりました。
According to [RFC7399], Software-Defined Networking (SDN) 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 traffic 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. This is the function and purpose of a PCE, and the way that a PCE integrates into a wider network control system (including an SDN system) is presented in [RFC7491].
[RFC7399]によると、ソフトウェア定義ネットワーキング（SDN）は、コントローラーと呼ばれる集中型システムで実行されているソフトウェアがネットワーク内のデバイスをプログラムするように動作できるように制御要素と転送コンポーネント間の分離を指します特定の方法。 SDNアーキテクチャで必要な要素は、ネットワークリソースの使用方法とデバイスのプログラミング方法を計画するコンポーネントです。このコンポーネントは、ネットワークリソースの可用性、他の転送デバイスのプログラム方法、および他のフローのルーティング方法についての知識があれば、特定の計算を実行してネットワーク内にトラフィックフローを配置するものと見なすことができます。これはPCEの機能と目的であり、PCEがより広いネットワーク制御システム（SDNシステムを含む）に統合する方法は、[RFC7491]に示されています。
In early PCE implementations, where the PCE was used to derive paths for MPLS Label Switched Paths (LSPs), paths were requested by network elements (known as Path Computation Clients (PCCs)), and the results of the path computations were supplied to network elements using the Path Computation Element Communication Protocol (PCEP) [RFC5440]. This protocol was later extended to allow a PCE to send unsolicited requests to the network for LSP establishment [RFC8281].
初期のPCE実装では、MPLSラベルスイッチドパス（LSP）のパスを取得するためにPCEが使用され、パスはネットワーク要素（パス計算クライアント（PCC）と呼ばれる）によって要求され、パス計算の結果がネットワークに提供されましたパス計算要素通信プロトコル（PCEP）[RFC5440]を使用した要素。このプロトコルは後で拡張され、PCEがLSP確立のために非送信請求リクエストをネットワークに送信できるようになりました[RFC8281]。
SDN has a far broader applicability than just signaled MPLS or GMPLS traffic-engineered networks. The PCE component in an SDN system may be used to determine paths in a wide range of use cases including static LSPs, segment routing [SR-ARCH], SFC [RFC7665], and indeed any form of routed or switched network. It is, therefore, reasonable to consider PCEP as a general southbound control protocol (i.e., a control protocol for communicating from the central controller to network elements) for use in these environments to allow the PCE to be fully enabled as a central controller.
SDNは、シグナリングされたMPLSまたはGMPLSトラフィックエンジニアリングネットワークよりもはるかに広い適用範囲を持っています。 SDNシステムのPCEコンポーネントを使用して、静的LSP、セグメントルーティング[SR-ARCH]、SFC [RFC7665]、および実際にあらゆる形式のルーティングまたはスイッチドネットワークを含む、幅広いユースケースでパスを決定できます。そのため、PCEPをこれらの環境で使用するための一般的なサウスバウンド制御プロトコル（つまり、中央コントローラーからネットワーク要素に通信するための制御プロトコル）と見なして、PCEを中央コントローラーとして完全に有効にすることができます。
This document introduces the architecture for PCE as a central controller as an extension of the architecture described in [RFC4655] and assumes the continued use of PCEP as the protocol used between PCE and PCC. This document also examines the motivations and applicability for PCEP as a Southbound Interface (SBI) and introduces the implications for the protocol used in this way. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.
このドキュメントでは、[RFC4655]で説明されているアーキテクチャの拡張として、中央コントローラーとしてのPCEのアーキテクチャを紹介し、PCEとPCCの間で使用されるプロトコルとしてPCEPの継続的な使用を想定しています。このドキュメントでは、サウスバウンドインターフェイス（SBI）としてのPCEPの動機と適用性についても検討し、この方法で使用されるプロトコルへの影響を紹介します。 PCEベースの中央コントローラーは、分散型コントロールプレーンをSDNの要素とブレンドし、必ずしも完全に置き換える必要がないため、分散型コントロールプレーンの処理を簡素化できます。
This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.
このドキュメントでは、ユースケースを詳しく説明せず、プロトコル拡張を定義していません。その作業は他のドキュメントに任されています。
The architecture for the use of PCE within centralized control of a network is based on the understanding that a PCE can determine how connections should be placed and how resources should be used within the network, and that the PCE can then cause those connections to be established. Figure 1 shows how this control relationship works in a network with an active control plane. This is a familiar view for those who have read and understood [RFC4655] and [RFC8281].
ネットワークの集中管理内でPCEを使用するためのアーキテクチャーは、PCEがネットワーク内での接続の配置方法とリソースの使用方法を決定でき、PCEがこれらの接続を確立できるという理解に基づいています。 。図1は、アクティブなコントロールプレーンを持つネットワークでこの制御関係がどのように機能するかを示しています。これは、[RFC4655]と[RFC8281]を読んで理解した人にはおなじみの見方です。
In this mode of operation, the central controller is asked to create connectivity by a network orchestrator, a service manager, an Operations Support System (OSS), a Network Management Station (NMS), or some other application. The PCE-based controller computes paths with awareness of the network topology, the available resources, and the other services supported in the network. This information is held in the Traffic Engineering Database (TED) and other databases available to the PCE. Then the PCE sends a request using PCEP to one of the Network Elements (NEs), and that NE uses a control plane to establish the requested connections and reserve the network resources.
この操作モードでは、中央コントローラーは、ネットワークオーケストレーター、サービスマネージャー、運用サポートシステム（OSS）、ネットワーク管理ステーション（NMS）、またはその他のアプリケーションによって接続を作成するように求められます。 PCEベースのコントローラーは、ネットワークトポロジ、使用可能なリソース、およびネットワークでサポートされているその他のサービスを認識してパスを計算します。この情報は、トラフィックエンジニアリングデータベース（TED）およびPCEで利用可能なその他のデータベースに保持されています。次に、PCEはPCEPを使用してネットワーク要素（NE）の1つに要求を送信し、そのNEはコントロールプレーンを使用して、要求された接続を確立し、ネットワークリソースを予約します。
Note that other databases (such as an LSP Database (LSP-DB)) might also be used, but for simplicity of illustration, just the TED is shown.
他のデータベース（LSPデータベース（LSP-DB）など）も使用される場合がありますが、説明を簡単にするために、TEDのみが示されていることに注意してください。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
------------
^
PCEP|
v
---- ---- ---- ----
| NE |<--------->| NE |<--->| NE |<--->| NE |
---- Signaling ---- ---- ----
Protocol
Figure 1: Architecture for the Central Controller with a Control Plane
図1：コントロールプレーンを備えたセントラルコントローラのアーキテクチャ
Although the architecture shown in Figure 1 represents a form of SDN, one objective of SDN in some environments is to remove the dependency on a control plane. A transition architecture toward this goal is presented in [RFC7491] and is shown in Figure 2. In this case, services are still requested in the same way, and the PCE-based controller still requests use of the network using PCEP. The main difference is that the consumer of the PCEP messages is a network controller that provisions the resources and instructs the data plane using an SBI that provides an interface to each NE.
図1に示すアーキテクチャはSDNの形式を表していますが、一部の環境でのSDNの目的の1つは、コントロールプレーンへの依存を取り除くことです。この目標に向けた移行アーキテクチャが[RFC7491]に示され、図2に示されています。この場合も、サービスは同じ方法で要求され、PCEベースのコントローラーはPCEPを使用してネットワークの使用を要求します。主な違いは、PCEPメッセージのコンシューマーは、リソースをプロビジョニングし、各NEへのインターフェイスを提供するSBIを使用してデータプレーンに指示するネットワークコントローラーであることです。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
------------
^
| PCEP
v
------------
| Network |
| Controller |
/------------\
SBI / ^ ^ \
/ | | \
/ v v \
----/ ---- ---- \----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
Figure 2: Architecture Including a Network Controller
図2：ネットワークコントローラを含むアーキテクチャ
The approach in Figure 2 delivers the SDN functionality but is overly complicated and insufficiently flexible.
図2のアプローチはSDN機能を提供しますが、過度に複雑で、柔軟性が不十分です。
o The complication is created by the use of two controllers in a hierarchical organization and the resultant use of two protocols in a southbound direction.
o 複雑化は、階層構造で2つのコントローラーを使用し、その結果、南方向に2つのプロトコルを使用することで生じます。
o The lack of flexibility arises from the assumed or required lack of a control plane.
o 柔軟性の欠如は、コントロールプレーンの想定または欠如が原因で発生します。
This document describes an architecture that reduces the number of components and is flexible to a number of deployment models and use cases. In this hybrid approach (shown in Figure 3), the network controller is PCE enabled and can also speak PCEP as the SBI (i.e., it can communicate with each node along the path using PCEP). That means that the controller can communicate with a conventional control-plane-enabled NE using PCEP and can also use the same protocol to program individual NEs. In this way, the PCE-based controller can control a wider range of networks and deliver many different functions as described in Section 3.
このドキュメントでは、コンポーネントの数を減らし、多くの展開モデルとユースケースに柔軟に対応できるアーキテクチャについて説明します。このハイブリッドアプローチ（図3を参照）では、ネットワークコントローラーはPCE対応であり、SBIとしてPCEPを話すこともできます（つまり、PCEPを使用してパスに沿って各ノードと通信できます）。つまり、コントローラはPCEPを使用して従来のコントロールプレーン対応NEと通信でき、同じプロトコルを使用して個々のNEをプログラムできます。このようにして、PCEベースのコントローラーは、より広範囲のネットワークを制御し、セクション3で説明するように多くの異なる機能を提供できます。
There will be a trade-off in different application scenarios. In some cases, the use of a control plane will simplify deployment (for example, by distributing recovery actions), and in other cases, a control plane may add operational complexity.
さまざまなアプリケーションシナリオでトレードオフがあります。場合によっては、コントロールプレーンを使用すると展開が簡単になります（たとえば、回復アクションを分散することによって）。また、コントロールプレーンによって操作が複雑になる場合もあります。
PCEP is essentially already capable of acting as an SBI and only small, use-case-specific modifications to the protocol are needed to support this architecture. The implications for the protocol are discussed further in Section 4.
PCEPは基本的にすでにSBIとして機能することができ、このアーキテクチャをサポートするために必要なのは、プロトコルに対する小さなユースケース固有の変更のみです。プロトコルへの影響については、セクション4で詳しく説明します。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
/------------\
PCEP / ^ ^ \
/ | | \
/ v v \
/ ---- ---- \
/ | NE | | NE | \
----/ ---- ---- \----
| NE | | NE |
---- ----
^ ---- ---- ^
:......>| NE |...| NE |<....:
Signaling Protocol ---- ----
Figure 3: Architecture for Node-by-Node Central Control
図3：ノードごとの中央制御のアーキテクチャ
Systems with central controllers are vulnerable to two problems: failure of the controller or overload of the controller. These concerns are not unique to the use of a PCE-based controller, but they need to be addressed in this document before the PCE-based controller architecture can be considered for use in all but the smallest networks.
セントラルコントローラーを備えたシステムは、コントローラーの障害またはコントローラーの過負荷という2つの問題に対して脆弱です。これらの懸念事項はPCEベースのコントローラーの使用に固有のものではありませんが、PCEベースのコントローラーアーキテクチャを最小ネットワーク以外のすべてでの使用を検討する前に、このドキュメントで対処する必要があります。
There are three architectural mechanisms that can be applied to address these issues. The mechanisms are described separately for clarity, but a deployment may use any combination of the approaches.
これらの問題に対処するために適用できる3つのアーキテクチャメカニズムがあります。メカニズムは明確にするために個別に説明されていますが、デプロイメントではアプローチの任意の組み合わせを使用できます。
For simplicity of illustration, these three approaches are shown in the sections that follow without a control plane. However, the general, hybrid approach of Figure 3 is applicable in each case.
説明を簡単にするために、これらの3つのアプローチは、コントロールプレーンなしで以降のセクションに示されています。ただし、図3の一般的なハイブリッドアプローチは、いずれの場合にも適用できます。
The first and simplest approach to handling controller overload or scalability is to use multiple controllers, each responsible for a part of the network. We can call the resultant areas of control "domains" [RFC4655].
コントローラの過負荷またはスケーラビリティを処理するための最初かつ最も簡単なアプローチは、それぞれがネットワークの一部を担当する複数のコントローラを使用することです。結果として生じる制御の領域を「ドメイン」と呼ぶことができます[RFC4655]。
This approach is shown in Figure 4. It can clearly address some of the scaling and overload concerns since each controller now only has responsibility for a subset of the network elements. But this comes at a cost because end-to-end connections require coordination between the controllers. Furthermore, this technique does not remove the concern about a single point-of-failure even if it does reduce the impact on the network of the failure of a single controller.
このアプローチを図4に示します。各コントローラーはネットワーク要素のサブセットに対してのみ責任を持つようになったため、スケーリングと過負荷の問題のいくつかに明確に対処できます。ただし、エンドツーエンドの接続ではコントローラー間の調整が必要になるため、これにはコストがかかります。さらに、この手法は、単一のコントローラーの障害によるネットワークへの影響を軽減しても、単一の障害点に関する懸念を取り除きません。
Note that PCEP is designed to work as a PCE-to-PCE protocol as well as a PCE-to-PCC protocol, so it should be possible to use it to coordinate between PCE-based controllers in this model.
PCEPはPCEからPCEへのプロトコルおよびPCEからPCCへのプロトコルとして機能するように設計されているため、このモデルでPCEベースのコントローラー間の調整に使用できるはずです。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^ ^
| |
v v
------------ Coordi- ------------
----- | | nation | | -----
| TED |--->| PCE-Based |<-------->| PCE-Based |<---| TED |
----- | Controller | | Controller | -----
| | :: | |
/------------ :: ------------\
/ ^ ^ :: ^ ^ \
/ | | :: | | \
| | | :: | | |
v v v :: v v v
---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ----
::
Domain 1 :: Domain 2
::
Figure 4: Multiple Controllers on a Partitioned Network
図4：パーティション分割されたネットワーク上の複数のコントローラー
Multiple controllers may be deployed where each controller is capable of controlling all of the network elements. Thus, the failure of any one controller will not leave the network unmanageable and, in normal circumstances, the load can be distributed across the controllers.
各コントローラーがすべてのネットワーク要素を制御できる複数のコントローラーを配置できます。したがって、いずれかのコントローラに障害が発生しても、ネットワークが管理不能になることはなく、通常の状況では、負荷がコントローラ全体に分散されます。
Multiple parallel controllers may be deployed as shown in Figure 5. Each controller is capable of controlling all of the network elements; thus, the failure of any one controller will not leave the network unmanageable, and in normal circumstances, the load can be distributed across the controllers. In this model, the orchestrator (or any requester) must select a controller to consume its request.
図5に示すように、複数の並列コントローラーを展開できます。各コントローラーは、すべてのネットワーク要素を制御できます。したがって、1つのコントローラーに障害が発生しても、ネットワークが管理不能になることはなく、通常の状況では、コントローラー間で負荷を分散できます。このモデルでは、オーケストレーター（または任意のリクエスター）は、その要求を使用するコントローラーを選択する必要があります。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^ ^
| ___________________ |
| | Synchronization | |
v v v v
------------ ------------
| | ----- | |
| PCE-Based |<---| TED |--->| PCE-Based |
| Controller | ----- | Controller |
| |__ ...........| |
------------\ \_:__ :------------
^ ^ \___: \ .....: ^ ^
| | .....:\ \_:___ ..: :
| |__:___ \___:_ \_:___ :
| ....: | .....: | ..: | :
| : | : | : | :
v v v v v v v v
---- ---- ---- ----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
Figure 5: Multiple Redundant Controllers
図5：複数の冗長コントローラー
An alternate approach is to present the controllers as a "cluster" that represents itself externally as a single controller as in Figure 3 but that is actually comprised of multiple controllers. The size of the cluster may be varied according to the load in the manner of Network Functions Virtualization (NFV), and the cluster is responsible for sharing load among the members of the cluster. This approach is shown in Figure 6.
別のアプローチは、図3のように外部的にはそれ自体を単一のコントローラーとして表す「クラスター」としてコントローラーを提示することですが、実際には複数のコントローラーで構成されています。クラスターのサイズは、ネットワーク機能仮想化（NFV）の方法で負荷に応じて変化する可能性があり、クラスターは、クラスターのメンバー間で負荷を共有します。このアプローチを図6に示します。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
--------------------------+-------------------------
| Controller ______________|_____________ |
| Cluster | | |
| | ___________________ | |
| | | Synchronization | | |
| v v v v |
| ------------ ----- ------------ |
| | PCE-Based |<---| TED |--->| PCE-Based | |
| | Controller | ----- | Controller | |
| | Instance | | Instance | |
| ------------ ------------ |
| ^ ^ |
| |____________________________| |
| | |
--------------------------+-------------------------
_____________|_____________
| | | |
v v v v
---- ---- ---- ----
| NE | | NE | | NE | | NE |
---- ---- ---- ----
Figure 6: Multiple Controllers Presented as a Cluster
図6：クラスターとして提示された複数のコントローラー
To achieve full redundancy and to be able to continue to provide full function in the event of a controller failure, the controllers must synchronize with each other. This is nominally a simple task if there are just two controllers but can actually be quite complex if state changes in the network are not to be lost. Furthermore, if there are more than two controllers, the synchronization between controllers can become a hard problem.
完全な冗長性を実現し、コントローラーに障害が発生した場合に引き続き完全な機能を提供できるようにするには、コントローラーを互いに同期させる必要があります。コントローラーが2つしかない場合、これは名目上単純なタスクですが、ネットワークの状態変化が失われないようにする場合、実際には非常に複雑になる可能性があります。さらに、コントローラーが3つ以上ある場合、コントローラー間の同期が困難な問題になる可能性があります。
Synchronization issues are often off-loaded as "database synchronization" problems, because distributed database packages have already had to address these challenges, or by using a shared database. In networking, the problem may also be addressed by collecting the state from the network (effectively using the network as a database) using normal routing protocols such as OSPF, IS-IS, and BGP. It should be noted that addressing the synchronization problem through a shared database may be hiding the issues of congestion and of a single point of failure: while the controllers may have been made resilient by allowing redundancy, the shared database is still a problem, so the whole system is still vulnerable.
分散データベースパッケージはすでにこれらの課題に対処する必要があるため、または共有データベースを使用することにより、同期の問題は「データベース同期」の問題としてオフロードされることがよくあります。ネットワーキングでは、OSPF、IS-IS、BGPなどの通常のルーティングプロトコルを使用してネットワークから状態を収集することで（ネットワークをデータベースとして効果的に使用して）、問題に対処することもできます。共有データベースを介して同期の問題に対処することで、輻輳や単一点障害の問題を隠すことができることに注意してください。冗長性を許可することでコントローラーが回復力を備えている場合でも、共有データベースは依然として問題なので、システム全体はまだ脆弱です。
Figure 7 shows an approach with hierarchical controllers. This approach was developed for PCEs in [RFC6805] and appears in various SDN architectures where a "parent PCE", an "orchestrator", or a "super controller" takes responsibility for a high-level view of the network before distributing tasks to lower-level PCEs or controllers.
図7は、階層型コントローラーを使用したアプローチを示しています。このアプローチは、[RFC6805]のPCE用に開発され、さまざまなSDNアーキテクチャで表示されます。ここでは、「親PCE」、「オーケストレーター」、または「スーパーコントローラー」が、タスクを分散する前にネットワークの高レベルのビューを担当します。レベルのPCEまたはコントローラー。
On its own, this approach does little to protect against the failure of a controller, but it can make significant improvements in loading and scaling of the individual controllers. It also offers a good way to support end-to-end connectivity across multiple administrative or technology-specific domains.
このアプローチだけでは、コントローラーの障害から保護することはほとんどありませんが、個々のコントローラーのロードとスケーリングを大幅に改善できます。また、複数の管理ドメインまたはテクノロジー固有のドメインにわたるエンドツーエンドの接続をサポートするための優れた方法も提供します。
Note that this model can be arbitrarily recursive with a PCE-based controller being the child of one parent PCE-based controller while acting as the parent of another set of PCE-based controllers.
このモデルは任意に再帰的であり、PCEベースのコントローラーが1つの親PCEベースのコントローラーの子であり、PCEベースのコントローラーの別のセットの親として機能することに注意してください。
--------------------------------------------
| Orchestrator / Service Manager / OSS / NMS |
--------------------------------------------
^
|
v
------------
| Parent | -----
| PCE-Based |<---| TED |
| Controller | -----
| |
------------
^ ^
| |
v :: v
------------ :: ------------
----- | | :: | | -----
| TED |--->| PCE-Based | :: | PCE-Based |<---| TED |
----- | Controller | :: | Controller | -----
/| | :: | |\
/ ------------ :: ------------ \
/ ^ ^ :: ^ ^ \
/ | | :: | | \
/ | | :: | | \
| | | :: | | |
v v v :: v v v
---- ---- ---- :: ---- ---- ----
| NE | | NE | | NE | :: | NE | | NE | | NE |
---- ---- ---- :: ---- ---- ----
::
Domain 1 :: Domain 2
::
Figure 7: Hierarchical Controllers
図7：階層コントローラー
This section gives a very high-level introduction to the applicability of a PCE-based centralized controller. There is no attempt to explain each use case in detail, and the inclusion of a use case is not intended to suggest that deploying a PCE-based controller is a mandatory or recommended approach. The sections below are provided as a stimulus to the discussion of the applicability of a PCE-based controller, and it is expected that separate documents will be written to develop the use cases in which there is interest for implementation and deployment. As described in
このセクションでは、PCEベースの集中コントローラーの適用性について非常に高レベルの概要を説明します。各ユースケースを詳細に説明する試みはなく、ユースケースを含めることは、PCEベースのコントローラーの展開が必須または推奨されるアプローチであることを示唆するものではありません。以下のセクションは、PCEベースのコントローラーの適用性の議論を刺激するものとして提供されており、実装と展開に関心のあるユースケースを開発するために個別のドキュメントが作成されることが期待されます。で説明されているように
Section 4, specific enhancements to PCEP may be needed for some of these use cases, and it is expected that the documents that develop each use case will also address any extensions to PCEP.
セクション4では、これらのユースケースの一部でPCEPの特定の機能強化が必要になる場合があり、各ユースケースを開発するドキュメントでもPCEPの拡張機能に対処することが期待されています。
The rest of this section is divided into two sub-sections. The first approaches the question of applicability from a consideration of the network technology. The second looks at the high-level functions that can be delivered by using a PCE-based controller.
このセクションの残りの部分は、2つのサブセクションに分かれています。 1つ目は、ネットワークテクノロジーを考慮して、適用性の問題に取り組みます。 2番目のセクションでは、PCEベースのコントローラーを使用して提供できる高レベルの機能について説明します。
As previously mentioned, this section is intended to just make suggestions. Thus, the material supplied is very brief. The omission of a use case is in no way meant to imply some limit on the applicability of PCE-based control.
前述のように、このセクションは提案を行うことのみを目的としています。したがって、提供される資料は非常に簡潔です。ユースケースの省略は、PCEベースの制御の適用性に対する制限を意味するものではありません。
This section provides a list of use cases based on network technology.
このセクションでは、ネットワークテクノロジーに基づく使用例のリストを示します。
This mode of operation is the common approach for an active, stateful PCE to control a traffic-engineered MPLS or GMPLS network [RFC8231]. Note that the PCE-based controller determines what LSPs are needed and where to place them. PCEP is used to instruct the head end of each LSP, and the head end signals in the control plane to set up the LSP.
この動作モードは、アクティブでステートフルなPCEがトラフィックエンジニアリングされたMPLSまたはGMPLSネットワークを制御するための一般的なアプローチです[RFC8231]。 PCEベースのコントローラーが、必要なLSPとそれらを配置する場所を決定することに注意してください。 PCEPは、各LSPのヘッドエンドを指示するために使用され、ヘッドエンドはコントロールプレーンに信号を送り、LSPをセットアップします。
In this mode of operation, the PCE may construct its TED in a number of ways as described in [RFC4655], including (but not limited to) participating in the IGP or receiving information from a network element via BGP-LS [RFC7752].
この操作モードでは、PCEは、[RFC4655]で説明されているように、IGPへの参加やBGP-LS [RFC7752]を介したネットワーク要素からの情報の受信など、さまざまな方法でTEDを構築できます。
Static LSPs are provisioned without the use of a control plane. This means that they are established using a management plane or "manual" configuration.
スタティックLSPは、コントロールプレーンを使用せずにプロビジョニングされます。つまり、管理プレーンまたは「手動」構成を使用して確立されます。
Static LSPs can be provisioned as explicit label instructions at each hop on the end-to-end path LSP. Each router along the path must be told what label-forwarding instructions to program and what resources to reserve. The PCE-based controller keeps a view of the network and determines the paths of the end-to-end LSPs just as it does for the use case described in Section 3.1.1, but the controller uses PCEP to communicate with each router along the path of the end-to-end LSP. In this case, the PCE-based controller will take responsibility for managing some part of the MPLS label space for each of the routers that it controls, and it may taker wider responsibility for partitioning the label space for each router and allocating different parts for different uses, communicating the ranges to the router using PCEP.
スタティックLSPは、エンドツーエンドパスLSPの各ホップで明示的なラベル指示としてプロビジョニングできます。パス上の各ルーターには、プログラムするラベル転送命令と予約するリソースを通知する必要があります。 PCEベースのコントローラーは、セクション3.1.1で説明したユースケースと同じように、ネットワークのビューを維持し、エンドツーエンドLSPのパスを決定しますが、コントローラーはPCEPを使用して、エンドツーエンドLSPのパス。この場合、PCEベースのコントローラーは、制御する各ルーターのMPLSラベルスペースの一部を管理する責任を持ち、各ルーターのラベルスペースを分割し、別のパーツに別のパーツを割り当てる責任をより広く引き受けます。使用し、PCEPを使用してルーターに範囲を通信します。
Multicast LSPs may be provisioned with a control plane or as static LSPs. No extra considerations apply above those described in Sections 3.1.1 and 3.1.2 except, of course, to note that the PCE must also include the instructions about where the LSP branches, i.e., where packets must be copied.
マルチキャストLSPは、コントロールプレーンで、または静的LSPとしてプロビジョニングできます。もちろん、PCEにはLSPが分岐する場所、つまりパケットをコピーする必要がある場所に関する指示も含める必要があることを除いて、セクション3.1.1および3.1.2で説明したもの以外に特別な考慮事項は適用されません。
Transport SDN (T-SDN) is the application of SDN techniques to transport networks. In this respect, a transport network is a network built from any technology below the IP layer and designed to carry traffic transparently in a connection-oriented way. Thus, an MPLS traffic-engineered network is a transport network, although it is more common to consider technologies such as Time Division Multiplexing (TDM) and Optical Transport Networks (OTNs) to be transport networks.
トランスポートSDN（T-SDN）は、SDN技術をトランスポートネットワークに適用したものです。この点で、トランスポートネットワークは、IP層の下の任意のテクノロジーから構築され、接続指向の方法で透過的にトラフィックを伝送するように設計されたネットワークです。したがって、MPLSトラフィックエンジニアリングネットワークはトランスポートネットワークですが、時分割多重（TDM）や光トランスポートネットワーク（OTN）などのテクノロジをトランスポートネットワークと見なすことが一般的です。
Transport networks may be operated with or without a control plane and may have point-to-point or point-to-multipoint connections. Thus, all of the considerations in Sections 3.1.1, 3.1.2, and 3.1.3 apply so that the normal PCEP message allows a PCE-based central controller to provision a transport network. It is usually the case that additional technology-specific parameters are needed to configure the NEs or LSPs in transport networks, such as optical characteristic. Such parameters will need to be carried in the PCEP messages: new protocol extensions may be needed, as described, for example, in [PCEP-WSON-RWA].
トランスポートネットワークは、コントロールプレーンの有無に関係なく動作し、ポイントツーポイントまたはポイントツーマルチポイント接続を備えている場合があります。したがって、セクション3.1.1、3.1.2、および3.1.3のすべての考慮事項が適用され、通常のPCEPメッセージによってPCEベースの中央コントローラーがトランスポートネットワークをプロビジョニングできるようになります。通常、トランスポートネットワークでNEまたはLSPを設定するには、光学特性など、追加のテクノロジー固有のパラメータが必要です。このようなパラメータは、PCEPメッセージで伝達する必要があります。たとえば、[PCEP-WSON-RWA]で説明されているように、新しいプロトコル拡張が必要になる場合があります。
Segment routing is described in [SR-ARCH]. It relies on a series of forwarding instructions being placed in the header of a packet. At each hop in the network, a router looks at the first instruction and may: continue to forward the packet unchanged; strip the top instruction and forward the packet; or strip the top instruction, insert some additional instructions, and forward the packet.
セグメントルーティングは[SR-ARCH]で説明されています。これは、パケットのヘッダーに配置されている一連の転送命令に依存しています。ネットワーク内の各ホップで、ルーターは最初の命令を確認し、次のことを行います。パケットを変更せずに転送し続ける。先頭の命令を取り除き、パケットを転送します。または、先頭の命令を取り除き、いくつかの追加の命令を挿入して、パケットを転送します。
The segment routing architecture supports operations that can be used to steer packet flows in a network, thus providing a form of traffic engineering. A PCE-based controller can be responsible for computing the paths for packet flows in a segment routing network, configuring the forwarding actions on the routers, and telling the edge routers what instructions to attach to packets as they enter the network. These last two operations can be achieved using PCEP, and the PCE-based controller will assume responsibility for managing the space of labels or path identifiers used to determine how packets are forwarded.
セグメントルーティングアーキテクチャは、ネットワーク内のパケットフローを誘導するために使用できる操作をサポートしているため、トラフィックエンジニアリングの形式を提供します。 PCEベースのコントローラーは、セグメントルーティングネットワークでのパケットフローのパスの計算、ルーターでの転送アクションの構成、パケットがネットワークに入るときにパケットに接続する手順をエッジルーターに通知する役割を果たします。これらの最後の2つの操作はPCEPを使用して実現でき、PCEベースのコントローラーは、パケットの転送方法を決定するために使用されるラベルまたはパス識別子のスペースの管理を担当します。
SFC is described in [RFC7665]. It is the process of directing traffic in a network such that it passes through specific hardware devices or virtual machines (known as service function nodes) that can perform particular desired functions on the traffic. The set of functions to be performed and the order in which they are to be performed is known as a service function chain. The chain is enhanced with the locations at which the service functions are to be performed to derive a Service Function Path (SFP). Each packet is marked as belonging to a specific SFP, and that marking lets each successive service function node know which functions to perform and to which service function node to send the packet next.
SFCは[RFC7665]で説明されています。これは、特定のハードウェアデバイスまたは仮想マシン（サービス機能ノードと呼ばれる）を通過するようにネットワーク内のトラフィックを誘導するプロセスであり、トラフィックに対して特定の目的の機能を実行できます。実行される機能のセットと、それらが実行される順序は、サービス機能チェーンと呼ばれます。チェーンは、サービス機能パス（SFP）を導出するためにサービス機能が実行される場所で強化されます。各パケットは特定のSFPに属するものとしてマークされ、そのマーキングにより、後続の各サービス機能ノードは、実行する機能と次にパケットを送信するサービス機能ノードを認識できます。
To operate an SFC network, the service function nodes must be configured to understand the packet markings, and the edge nodes must be told how to mark packets entering the network. Additionally, it may be necessary to establish tunnels between service function nodes to carry the traffic.
SFCネットワークを運用するには、サービス機能ノードがパケットマーキングを理解するように構成されている必要があり、エッジノードはネットワークに入るパケットにマークを付ける方法を指示されている必要があります。さらに、トラフィックを伝送するために、サービス機能ノード間にトンネルを確立する必要がある場合があります。
Planning an SFC network requires load balancing between service function nodes and traffic engineering across the network that connects them. These are operations that can be performed by a PCE-based controller, and that controller can use PCEP to program the network and install the service function chains and any required tunnels.
SFCネットワークを計画するには、サービス機能ノード間の負荷分散と、それらを接続するネットワーク全体のトラフィックエンジニアリングが必要です。これらはPCEベースのコントローラーで実行できる操作であり、そのコントローラーはPCEPを使用してネットワークをプログラムし、サービス機能チェーンと必要なトンネルをインストールできます。
This section provides a list of the high-level functions that can be delivered by using a PCE-based controller.
このセクションでは、PCEベースのコントローラーを使用して提供できる高水準関数のリストを示します。
According to [RFC2702], TE is concerned with performance optimization of operational networks. In general, it encompasses the application of technology and scientific principles to the measurement, modeling, characterization, control of Internet traffic, and application of such knowledge and techniques to achieve specific performance objectives.
[RFC2702]によれば、TEは運用ネットワークのパフォーマンス最適化に関係しています。一般に、測定とモデリングへのテクノロジーと科学原理の適用、インターネットトラフィックの制御、および特定のパフォーマンス目標を達成するためのそのような知識と技術の適用が含まれます。
From a practical point of view, this involves having an understanding of the topology of the network, the characteristics of the nodes and links in the network, and the traffic demands and flows across the network. It also requires that actions can be taken to ensure that traffic follows specific paths through the network.
実用的な観点から見ると、これには、ネットワークのトポロジ、ネットワーク内のノードとリンクの特性、およびネットワーク全体のトラフィックの需要とフローを理解することが含まれます。また、トラフィックがネットワーク内の特定のパスを確実に通過するようにアクションを実行できることも必要です。
PCE was specifically developed to address TE in an MPLS network, so a PCE-based controller is well suited to analyze TE problems and supply answers that can be installed in the network using PCEP. PCEP can be responsible for initiating paths across the network through a control plane or for installing state in the network node by node such as in a segment-routed network (see Section 3.1.5) or by configuring IGP metrics.
PCEはMPLSネットワークのTEに対処するために特別に開発されたため、PCEベースのコントローラーは、TEの問題を分析し、PCEPを使用してネットワークにインストールできる回答を提供するのに適しています。 PCEPは、コントロールプレーンを介してネットワーク全体のパスを開始したり、セグメントルーティングネットワーク（セクション3.1.5を参照）などのノードごとに、またはIGPメトリックを構成することによって、ネットワークノードに状態をインストールしたりできます。
Traffic classification is an important part of traffic engineering. It is the process of looking at a packet to determine how it should be treated as it is forwarded through the network. It applies in many scenarios including MPLS traffic engineering (where it determines what traffic is forwarded onto which LSPs); segment routing (where it is used to select which set of forwarding instructions to add to a packet); and SFC (where it indicates along which service function path a packet should be forwarded). In conjunction with traffic engineering, traffic classification is an important enabler for load balancing.
トラフィックの分類は、トラフィックエンジニアリングの重要な部分です。これは、ネットワークを介して転送されるときにパケットをどのように処理するかを決定するためにパケットを調べるプロセスです。これは、MPLSトラフィックエンジニアリング（どのトラフィックがどのLSPに転送されるかを決定する）を含む多くのシナリオに適用されます。セグメントルーティング（パケットに追加する転送命令のセットを選択するために使用されます）;およびSFC（パケットが転送されるサービス機能パスに沿って示されます）。トラフィックエンジニアリングと併せて、トラフィック分類はロードバランシングを実現する重要な要素です。
Traffic classification is closely linked to the computational elements of planning for the network functions just listed because it determines how traffic load is balanced and distributed through the network. Therefore, selecting what traffic classification should be performed by a router is an important part of the work done by a PCE-based controller.
トラフィックの分類は、リストされているネットワーク機能の計画の計算要素と密接に関連しています。これは、トラフィックの負荷がネットワーク全体でどのように分散および分散されるかを決定するためです。したがって、ルータで実行する必要があるトラフィック分類を選択することは、PCEベースのコントローラが実行する作業の重要な部分です。
Instructions can be passed from the controller to the routers using PCEP. These instructions tell the routers how to map traffic to paths or connections.
PCEPを使用して、コントローラからルーターに命令を渡すことができます。これらの手順は、パスまたは接続にトラフィックをマップする方法をルーターに指示します。
Various network services may be offered over a network. These include protection services (including end-to-end protection [RFC4427], restoration after failure, and fast reroute [RFC4090]); Virtual Private Network (VPN) services (such as Layer 3 VPNs [RFC4364] or Ethernet VPNs [RFC7432]); or Pseudowires [RFC3985].
ネットワーク上でさまざまなネットワークサービスを提供できます。これらには、保護サービス（エンドツーエンド保護[RFC4427]、障害後の復元、高速再ルーティング[RFC4090]を含む）が含まれます。仮想プライベートネットワーク（VPN）サービス（レイヤー3 VPN [RFC4364]やイーサネットVPN [RFC7432]など）。または疑似配線[RFC3985]。
Delivering services over a network in an optimal way requires coordination in the way that network resources are allocated to support the services. A PCE-based central controller can consider the whole network and all components of a service at once when planning how to deliver the service. It can then use PCEP to manage the network resources and to install the necessary associations between those resources.
最適な方法でネットワークを介してサービスを提供するには、サービスをサポートするためにネットワークリソースが割り当てられるように調整する必要があります。 PCEベースの中央コントローラーは、サービスの提供方法を計画するときに、ネットワーク全体とサービスのすべてのコンポーネントを同時に検討できます。次に、PCEPを使用してネットワークリソースを管理し、それらのリソース間に必要な関連付けをインストールできます。
PCEP is a push-pull protocol that is designed to move requests and responses between a server (the PCE) and clients (the PCCs, i.e., the network elements). In particular, it has a message (the LSP Initiate Request (PCInitiate); see [RFC8281]) that can be sent by the PCE to install state or cause actions at the PCC and a response message (Path Computation State Report (PCRpt)) that is used to confirm the request.
PCEPは、サーバー（PCE）とクライアント（PCC、つまりネットワーク要素）の間で要求と応答を移動するように設計されたプッシュプルプロトコルです。特に、PCEが状態をインストールしたり、PCCでアクションを引き起こしたりするためにPCEから送信できるメッセージ（LSP開始要求（PCInitiate）; [RFC8281]を参照）と応答メッセージ（パス計算状態レポート（PCRpt））があります。リクエストの確認に使用されます。
As such, there is an expectation that only relatively minor changes to PCEP are required to support the concept of a PCE-based controller. The only work expected to be needed is extensions to existing PCEP messages to carry additional or specific information elements for the individual use cases, which maintain backward compatibility and do not impact existing PCEP deployments. [RFC5440] already describes how legacy implementations handle unknown protocol extensions and how to use the PCEP Open message to indicate support for PCEP features. Where possible, consistent with the general principles of how protocols are extended, any additions to the protocol should be made in a generic way such that they are open to use in a range of applications.
そのため、PCEベースのコントローラーの概念をサポートするには、PCEPに対する比較的小さな変更のみが必要であると予想されます。必要とされると思われる唯一の作業は、既存のPCEPメッセージを拡張して、個別のユースケースの追加または特定の情報要素を伝達することです。これにより、下位互換性が維持され、既存のPCEP展開に影響を与えません。 [RFC5440]は、レガシー実装が未知のプロトコル拡張をどのように処理するか、およびPCEP Openメッセージを使用してPCEP機能のサポートを示す方法をすでに説明しています。可能な場合、プロトコルの拡張方法の一般原則に従って、プロトコルへの追加は、さまざまなアプリケーションで使用できるように、一般的な方法で行う必要があります。
It is anticipated that new documents (such as [PCEP-CONTROLLER]) will be produced for each use case dependent on support and demand. Such documents will explain the use case and define the necessary protocol extensions.
サポートと需要に応じて、ユースケースごとに新しいドキュメント（[PCEP-CONTROLLER]など）が作成されることが予想されます。そのようなドキュメントは、ユースケースを説明し、必要なプロトコル拡張を定義します。
Protocol extensions could have impact on existing PCEP deployments and the interoperability between different implementations. It is anticipated that changes of the PCEP protocol or addition of information elements could require additional testing to ensure interoperability between different PCEP implementations.
プロトコル拡張は、既存のPCEP展開と、異なる実装間の相互運用性に影響を与える可能性があります。 PCEPプロトコルの変更または情報要素の追加では、異なるPCEP実装間の相互運用性を確認するために追加のテストが必要になる可能性があると予想されます。
It is reasonable to expect that implementations are able to select a subset or profile of the protocol extensions and PCEP features that are relevant for the application scenario in which they will be deployed. Identification of these profiles should form part of the protocol itself so that interoperability can be easily determined and testing can be limited to the specific profiles.
実装は、それらが展開されるアプリケーションシナリオに関連するプロトコル拡張およびPCEP機能のサブセットまたはプロファイルを選択できることを期待するのは妥当です。これらのプロファイルの識別は、プロトコル自体の一部を形成する必要があります。これにより、相互運用性を容易に決定し、テストを特定のプロファイルに限定できます。
Note that protocol mechanisms to handle synchronization of state in parallel PCE-based controllers will also be required if parallel controllers are used as described in Section 2.1.2. In [RFC8231], there is a discussion of mechanisms to achieve PCE state synchronization.
セクション2.1.2で説明されているように並列コントローラーを使用する場合は、並列PCEベースのコントローラーで状態の同期を処理するプロトコルメカニズムも必要になることに注意してください。 [RFC8231]では、PCE状態の同期を実現するメカニズムについての議論があります。
Security considerations for a PCE-based controller are little different from those for any other PCE system. That is, the operation relies heavily on the use and security of PCEP, so consideration should be given to the security features discussed in [RFC5440] and the additional mechanisms described in [RFC8253].
PCEベースのコントローラーのセキュリティに関する考慮事項は、他のPCEシステムの場合とほとんど変わりません。つまり、操作はPCEPの使用とセキュリティに大きく依存するため、[RFC5440]で説明されているセキュリティ機能と[RFC8253]で説明されている追加のメカニズムを考慮する必要があります。
It should be observed that the trust model of a network that operates without a control plane is different from one with a control plane. The conventional "chain of trust" used with a control plane is replaced by individual trust relationships between the controller and each individual NE. This model may be considerably easier to manage, so it is more likely to be operated with a high level of security.
コントロールプレーンなしで動作するネットワークの信頼モデルは、コントロールプレーンがあるものとは異なることに注意してください。コントロールプレーンで使用される従来の「信頼の連鎖」は、コントローラと各NE間の個別の信頼関係に置き換えられます。このモデルは管理がかなり簡単になる可能性があるため、高レベルのセキュリティで運用される可能性が高くなります。
However, an architecture with a central controller has a central point of failure, and this is also a security weakness since the network can be vulnerable to denial-of-service attacks on the controller. Similarly, the central controller provides a focus for interception and modification of messages sent to individual NEs. In short, while the interactions with a PCE-based controller are not substantially different to those in any other SDN architecture, the security implications of SDN have not been fully discussed or described. Therefore, protocol and applicability work-around solutions for this architecture must take proper account of these concerns.
ただし、中央コントローラーを使用するアーキテクチャーには障害の中心点があり、これはネットワークがコントローラーに対するサービス拒否攻撃に対して脆弱になる可能性があるため、セキュリティ上の弱点でもあります。同様に、中央コントローラは、個々のNEに送信されるメッセージの傍受と変更に重点を置いています。要するに、PCEベースのコントローラーとの相互作用は他のどのSDNアーキテクチャーとの相互作用にも実質的に違いはありませんが、SDNのセキュリティへの影響は十分に議論または説明されていません。したがって、このアーキテクチャのプロトコルと適用性の回避策ソリューションでは、これらの懸念を適切に考慮する必要があります。
It is expected that each new document that is produced for a specific use case will also include considerations of the security impacts of the use of a PCE-based central controller on the network type and services being managed.
特定のユースケース用に作成された新しい各ドキュメントには、PCEベースのセントラルコントローラーの使用が管理されているネットワークの種類とサービスに対するセキュリティの影響に関する考慮事項も含まれることが期待されます。
The architecture described in this document is a management architecture: the PCE-based controller is a management component that controls the network through a southbound control protocol (PCEP).
このドキュメントで説明するアーキテクチャは管理アーキテクチャです。PCEベースのコントローラーは、サウスバウンド制御プロトコル（PCEP）を介してネットワークを制御する管理コンポーネントです。
An implementation of a PCE-based controller will require access to information about the state of the network, its nodes, and its links. Some of this will be the TED as is normal for a PCE and can be collected using the mechanisms already in place (such as listening to the IGPs, using BGP-LS [RFC7752], or northbound export of YANG-encoded data [YANG-TE] from the network elements to the controller). More information may be collected in the LSP database for stateful PCEs as described in [RFC7399] and [RFC8231]. Additional information may be needed for other specific use cases and will need to be collected and passed to the controller. This may require protocol extensions for the mechanisms listed in this paragraph.
PCEベースのコントローラーの実装では、ネットワーク、そのノード、およびリンクの状態に関する情報にアクセスする必要があります。これの一部はPCEの通常のTEDであり、すでに配置されているメカニズム（IGPをリッスンする、BGP-LS [RFC7752]を使用する、またはYANGエンコードデータのノースバウンドエクスポート[YANG- TE]からネットワーク要素へ）。 [RFC7399]と[RFC8231]で説明されているように、ステートフルPCEのLSPデータベースでより多くの情報が収集される場合があります。その他の特定の使用例では追加情報が必要になる場合があり、収集してコントローラーに渡す必要があります。これには、この段落に記載されているメカニズムのプロトコル拡張が必要になる場合があります。
The use of different PCEP options and protocol extensions may have an impact on interoperability, which is a management issue. As noted in Section 4, protocol extensions should be done in a way that makes it possible to identify profiles of PCEP to aid interoperability, and this will aid deployment and manageability.
さまざまなPCEPオプションとプロトコル拡張を使用すると、管理の問題である相互運用性に影響を与える可能性があります。セクション4で述べたように、プロトコル拡張は、相互運用性を支援するためにPCEPのプロファイルを識別できるようにする必要があります。これにより、展開と管理性が向上します。
[RFC5440] contains a substantive Manageability Considerations section that examines how a PCE-based system and a PCE-enabled system may be managed. A MIB module for PCEP was published as [RFC7420], and a YANG module for PCEP has also been proposed [YANG-PCEP].
[RFC5440]には、PCEベースのシステムとPCE対応のシステムをどのように管理できるかを調査する、実質的な管理に関する考慮事項のセクションが含まれています。 PCEPのMIBモジュールは[RFC7420]として公開され、PCEPのYANGモジュールも提案されています[YANG-PCEP]。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[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、Ed。、 "Path Computation Element（PCE）Communication Protocol（PCEP）"、RFC 5440、DOI 10.17487 / RFC5440、March 2009、<https://www.rfc-editor.org/info/rfc5440>
[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>。
[PCECC] Zhao, Q., Li, Z., Khasanov, B., Ke, Z., Fang, L., Zhou, C., Communications, T., Rachitskiy, A., and A. Gulida, "The Use Cases for Using PCE as the Central Controller(PCECC) of LSPs", Work in Progress, draft-zhao-teas-pcecc-use-cases-02, October 2016.
[PCECC] Zhao、Q.、Li、Z.、Khasanov、B.、Ke、Z.、Fang、L.、Zhou、C.、Communications、T.、Rachitskiy、A。、およびA. Gulida、「 PCEをLSPのセントラルコントローラ（PCECC）として使用するための使用例」、作業中、draft-zhao-teas-pcecc-use-cases-02、2016年10月。
[PCEP-CONTROLLER] Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", Work in Progress, draft-zhao-pce-pcep-extension-for-pce-controller-06, October 2017.
[PCEP-CONTROLLER] Zhao、Q.、Li、Z.、Dhody、D.、Karunanithi、S.、Farrel、A.、C。Zhou、「PCEをセントラルコントローラとして使用するためのPCEP手順とプロトコル拡張（PCECC ）of LSPs」、Work in Progress、draft-zhao-pce-pcep-extension-for-pce-controller-06、2017年10月。
[PCEP-WSON-RWA] Lee, Y. and R. Casellas, "PCEP Extension for WSON Routing and Wavelength Assignment", Work in Progress, draft-ietf-pce-wson-rwa-ext-07, November 2017.
[PCEP-WSON-RWA] Lee、Y。、およびR. Casellas、「WSONルーティングおよび波長割り当てのためのPCEP拡張機能」、Work in Progress、draft-ietf-pce-wson-rwa-ext-07、2017年11月。
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, <https://www.rfc-editor.org/info/rfc2702>.
[RFC2702] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「MPLSを介したトラフィックエンジニアリングの要件」、RFC 2702、DOI 10.17487 / RFC2702、1999年9月、 <https://www.rfc-editor.org/info/rfc2702>。
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC3985]ブライアント、S。、エド。およびP. Pate、編、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、DOI 10.17487 / RFC3985、2005年3月、<https://www.rfc-editor.org/info/rfc3985 >。
[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>.
[RFC4090] Pan、P。、編、Swallow、G。、編、A。Atlas、編、「LSPトンネル用のRSVP-TEへの高速リルート拡張」、RFC 4090、DOI 10.17487 / RFC4090、2005年5月、<https://www.rfc-editor.org/info/rfc4090>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4364]ローゼン、E。およびY.レクター、「BGP / MPLS IP仮想プライベートネットワーク（VPN）」、RFC 4364、DOI 10.17487 / RFC4364、2006年2月、<https://www.rfc-editor.org/info / rfc4364>。
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <https://www.rfc-editor.org/info/rfc4427>.
[RFC4427]マニー、E、エド。およびD. Papadimitriou、Ed。、「Recovery（Protection and Restoration）Terminology for Generalized Multi-Protocol Label Switching（GMPLS）」、RFC 4427、DOI 10.17487 / RFC4427、2006年3月、<https：//www.rfc-editor。 org / info / rfc4427>。
[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>。
[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. Margaria, "Requirements for GMPLS Applications of PCE", RFC 7025, DOI 10.17487/RFC7025, September 2013, <https://www.rfc-editor.org/info/rfc7025>.
[RFC7025] Otani、T.、Ogaki、K.、Caviglia、D.、Zhang、F。、およびC. Margaria、「PCEのGMPLSアプリケーションの要件」、RFC 7025、DOI 10.17487 / RFC7025、2013年9月、<https ：//www.rfc-editor.org/info/rfc7025>。
[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 >。
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420] Koushik、A.、Stephan、E.、Zhao、Q.、King、D。、およびJ. Hardwick、「Path Computation Element Communication Protocol（PCEP）Management Information Base（MIB）Module」、RFC 7420、DOI 10.17487 / RFC7420、2014年12月、<https://www.rfc-editor.org/info/rfc7420>。
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A.、Ed。、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J.、and W. Henderickx、 "BGP MPLS-Based Ethernet VPN"、 RFC 7432、DOI 10.17487 / RFC7432、2015年2月、<https://www.rfc-editor.org/info/rfc7432>。
[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]キング、D。、およびA.ファレル、「アプリケーションベースのネットワーク操作のためのPCEベースのアーキテクチャ」、RFC 7491、DOI 10.17487 / RFC7491、2015年3月、<https://www.rfc-editor.org/ info / rfc7491>。
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>.
[RFC7665] Halpern、J.、Ed。 C. Pignataro、編、「Service Function Chaining（SFC）Architecture」、RFC 7665、DOI 10.17487 / RFC7665、2015年10月、<https://www.rfc-editor.org/info/rfc7665>。
[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>。
[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>。
[SR-ARCH] Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-13, October 2017.
[SR-ARCH] Filsfils、C.、Previdi、S.、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、Work in Progress、draft-ietf-spring -segment-routing-13、2017年10月。
[YANG-PCEP] Dhody, D., Hardwick, J., Beeram, V., and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, June 2017.
[YANG-PCEP] Dhody、D.、Hardwick、J.、Beeram、V.、j。 jefftant@gmail.com、「パス計算要素通信プロトコル（PCEP）のYANGデータモデル」、作業中、draft-ietf-pce-pcep-yang-05、2017年6月。
[YANG-TE] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", Work in Progress, draft-ietf-teas-yang-te-topo-13, October 2017.
[YANG-TE] Liu、X.、Bryskin、I.、Beeram、V.、Saad、T.、Shah、H.、O。Dios、「YANG Data Model for Traffic Engineering（TE）Topologies」、Work in進捗、draft-ietf-teas-yang-te-topo-13、2017年10月。
Acknowledgments
謝辞
The ideas in this document owe a lot to the work started by the authors of [PCECC] and [PCEP-CONTROLLER]. The authors of this document fully acknowledge the prior work and thank those involved for opening the discussion. The individuals concerned are: King Ke, Luyuan Fang, Chao Zhou, Boris Zhang, and Zhenbin Li.
このドキュメントのアイデアは、[PCECC]と[PCEP-CONTROLLER]の作者によって開始された作業に大きく負っています。このドキュメントの作成者は、以前の作業を完全に認め、ディスカッションを開いてくれた関係者に感謝します。関係者は、Ke Ke、Luyuan Fang、Chao Zhou、Boris Zhang、Zhenbin Liです。
This document has benefited from the discussions within a small ad hoc design team; the members of which are listed as document contributors.
このドキュメントは、小規模なアドホックデザインチーム内での議論の恩恵を受けています。そのメンバーはドキュメントの寄稿者としてリストされています。
Thanks to Michael Scharf and Andy Malis for a lively discussion of this document.
このドキュメントについて活発に議論してくれたMichael ScharfとAndy Malisに感謝します。
Thanks to Phil Bedard, Aijun Wang, and Elwyn Davies for last call comments on this document.
このドキュメントに対する最後の電話のコメントを提供してくれたPhil Bedard、Aijun Wang、およびElwyn Daviesに感謝します。
Spencer Dawkins, Adam Roach, and Ben Campbell provided helpful comments during IESG review.
スペンサードーキンス、アダムローチ、ベンキャンベルは、IESGのレビューで役立つコメントを提供しました。
Contributors
貢献者
The following people contributed to discussions that led to the development of this document:
次の人々は、このドキュメントの開発につながる議論に貢献しました：
Cyril Margaria Email: cmargaria@juniper.net
Cyril Margariaメール：cmargaria@juniper.net
Sudhir Cheruathur Email: scheruathur@juniper.net
Sudhir Cheruathurメール：scheruathur@juniper.net
Dhruv Dhody Email: dhruv.dhody@huawei.com
Dhruv Dhodyメール：dhruv.dhody@huawei.com
Daniel King Email: daniel@olddog.co.uk
ダニエルキングメール：daniel@olddog.co.uk
Iftekhar Hussain Email: IHussain@infinera.com
Iftekhar Hossainメール：ihusain：infinera.com
Anurag Sharma Email: AnSharma@infinera.com
Anurag Sharmaメール：AnSharma@infinera.com
Eric Wu Email: eric.wu@huawei.com
Eric Wu Eメール：eric.wu@huawei.com
Authors' Addresses
著者のアドレス
Adrian Farrel (editor) Juniper Networks
エイドリアン・ファレル（編集者）ジュニパーネットワークス
Email: afarrel@juniper.net
Quintin Zhao (editor) Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 United States of America
Quintin Zhao（編集者）Huawei Technologies 125 Nagog Technology Park Acton、MA 01719アメリカ合衆国
Email: quintin.zhao@huawei.com
Robin Li Huawei Technologies Huawei Bld., No.156 Beiqing Road Beijing 100095 China
Robin l IH UAはテクノロジーhu AはBL。、no.156 be iqing道路北京100095中国
Email: lizhenbin@huawei.com
Chao Zhou Cisco Systems
cha oz後のシスコシステム
Email: chao.zhou@cisco.com