Internet Engineering Task Force (IETF) Z. Li
Request for Comments: 9689 D. Dhody
Category: Informational Huawei Technologies
ISSN: 2070-1721 Q. Zhao
Etheric Networks
K. He
Tencent Holdings Ltd.
B. Khasanov
MTS Web Services (MWS)
December 2024
The PCE is a core component of a Software-Defined Networking (SDN) system. It can be used to compute optimal paths for network traffic and update existing paths to reflect changes in the network or traffic demands. The PCE was developed to derive Traffic Engineering (TE) paths in MPLS networks, which are supplied to the headend of the paths using the Path Computation Element Communication Protocol (PCEP).
PCEは、ソフトウェア定義ネットワーク（SDN）システムのコアコンポーネントです。ネットワークトラフィックの最適なパスを計算し、既存のパスを更新して、ネットワークまたはトラフィックの需要の変更を反映するために使用できます。PCEは、MPLSネットワークのトラフィックエンジニアリング（TE）パスを導出するために開発されました。MPLSネットワークは、パス計算要素通信プロトコル（PCEP）を使用してパスのヘッドエンドに供給されます。
SDN has much broader applicability than signalled MPLS TE networks, and the PCE may be used to determine paths in a range of use cases including static Label-Switched Paths (LSPs), Segment Routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network. Therefore, it is 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）、セグメントルーティング（SR）、サービス関数チェーン（SFC）、、および範囲のユースケースのパスを決定することができます。ルーティングまたはスイッチネットワークのほとんどの形式。したがって、PCEPをこれらの環境で使用するためのコントロールプロトコルとして考慮して、PCEを中央コントローラーとして完全に有効にすることを可能にすることが合理的です。
A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions, which are required for the PCECC use cases, are covered in separate documents.
セントラルコントローラー（PCECC）としてのPCEは、必ずしも完全に置き換えることなく、SDNの要素とブレンドすることにより、分散コントロールプレーンの処理を簡素化できます。このドキュメントは、PCECCの展開に関する一般的な考慮事項について説明し、多くのユースケースを通じて、その適用性と利点、およびその課題と制限を調べます。PCECCユースケースに必要なPCEP拡張機能は、個別のドキュメントでカバーされています。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9689.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9689で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. Use Cases
3.1. PCECC for Label Management
3.2. PCECC and SR
3.2.1. PCECC SID Allocation for SR-MPLS
3.2.2. PCECC for SR-MPLS Best Effort (BE) Paths
3.2.3. PCECC for SR-MPLS TE Paths
3.2.4. PCECC for SRv6
3.3. PCECC for Static TE LSPs
3.4. PCECC for Load Balancing (LB)
3.5. PCECC and Inter-AS TE
3.6. PCECC for Multicast LSPs
3.6.1. PCECC for the Setup of P2MP/MP2MP LSPs
3.6.2. PCECC for the End-to-End Protection of P2MP/MP2MP LSPs
3.6.3. PCECC for the Local Protection of P2MP/MP2MP LSPs
3.7. PCECC for Traffic Classification
3.8. PCECC for SFC
3.9. PCECC for Native IP
3.10. PCECC for BIER
4. IANA Considerations
5. Security Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Other Use Cases of the PCECC
A.1. PCECC for Network Migration
A.2. PCECC for L3VPN and PWE3
A.3. PCECC for Local Protection (RSVP-TE)
A.4. Using Reliable P2MP TE-Based Multicast Delivery for
Distributed Computations (MapReduce-Hadoop)
Acknowledgments
Contributors
Authors' Addresses
The PCE [RFC4655] was developed to offload the path computation function from routers in an MPLS Traffic Engineering (TE) network. 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. The role and function of the PCE have grown to cover several other uses (such as GMPLS [RFC7025] or Multicast) and to allow delegated stateful control [RFC8231] and PCE-initiated use of network resources [RFC8281].
PCE [RFC4655]は、MPLSトラフィックエンジニアリング（TE）ネットワークのルーターからパス計算関数をオフロードするために開発されました。ネットワーク間のトラフィックに最適なパスを計算でき、ネットワークまたはトラフィックの要求の変更を反映するパスを更新することもできます。PCEの役割と機能は、他のいくつかの用途（GMPLS [RFC7025]やマルチキャストなど）をカバーし、委任されたステートフルコントロール[RFC8231]およびネットワークリソースの使用[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 the 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]に表示されます。
[RFC8283] outlines the architecture for the PCE as a central controller, extending the framework described in [RFC4655], and demonstrates how PCEP can serve as a general southbound control protocol between the PCE and Path Computation Client (PCC). [RFC8283] further examines the motivations and applicability of PCEP as a Southbound Interface (SBI) and introduces the implications for the protocol.
[RFC8283]は、[RFC4655]で説明されているフレームワークを拡張し、PCEがPCEとPATH計算クライアント（PCC）の間の一般的な南行きのコントロールプロトコルとして機能する方法を示し、中央コントローラーとしてのPCEのアーキテクチャの概要を示しています。[RFC8283]は、南行きの界面（SBI）としてのPCEPの動機と適用性をさらに調べ、プロトコルへの影響を導入します。
[RFC9050] introduces the procedures and extensions for PCEP to support the PCECC architecture [RFC8283].
[RFC9050]は、PCEPアーキテクチャをサポートするためにPCEPの手順と拡張機能を導入します[RFC8283]。
This document describes the various use cases for the PCECC architecture.
このドキュメントでは、PCECCアーキテクチャのさまざまなユースケースについて説明しています。
The following terminology is used in this document.
このドキュメントでは、次の用語が使用されています。
AS:
AS:
Autonomous System
自律システム
ASBR:
ASBR：
Autonomous System Border Router
自律システムボーダールーター
BGP-LS:
BGP-LS：
Border Gateway Protocol - Link State [RFC9552]
Border Gatewayプロトコル - リンク状態[RFC9552]
IGP:
IGP:
Interior Gateway Protocol (in this document, we assume IGP as either Open Shortest Path First (OSPF) [RFC2328] [RFC5340] or Intermediate System to Intermediate System (IS-IS) [RFC1195])
インテリアゲートウェイプロトコル（このドキュメントでは、IGPは最初に最短パスを開く（OSPF）[RFC2328] [RFC5340]または中間システムから中間システム（IS-IS）[RFC1195]のいずれかと仮定します）
LSP:
LSP:
Label-Switched Path
ラベルスイッチパス
PCC:
PCC:
Path Computation Client (as per [RFC4655], any client application requesting a path computation to be performed by a PCE)
パス計算クライアント（[RFC4655]によると、PCEによって実行されるパス計算を要求するクライアントアプリケーション）
PCE:
PCE:
Path Computation Element (as per [RFC4655], an entity such as 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)
パス計算要素（[RFC4655]によると、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるコンポーネント、アプリケーション、またはネットワークノードなどのエンティティ）
PCECC:
PCECC：
PCE as a Central Controller (an extension of a PCE to support SDN functions as per [RFC8283])
中央コントローラーとしてのPCE（[RFC8283]に従ってSDN関数をサポートするPCEの拡張）
PST:
PST:
Path Setup Type [RFC8408]
パスセットアップタイプ[RFC8408]
RR:
RR:
Route Reflector [RFC4456]
ルートリフレクター[RFC4456]
SID:
SID:
Segment Identifier [RFC8402]
セグメント識別子[RFC8402]
SR:
SR:
Segment Routing [RFC8402]
セグメントルーティング[RFC8402]
SRGB:
SRGB：
Segment Routing Global Block [RFC8402]
セグメントルーティンググローバルブロック[RFC8402]
SRLB:
SRLB：
Segment Routing Local Block [RFC8402]
セグメントルーティングローカルブロック[RFC8402]
TE:
TE:
Traffic Engineering [RFC9522]
交通工学[RFC9522]
[RFC8283] describes various use cases for a PCECC such as:
[RFC8283]は、次のようなPCECCのさまざまなユースケースを説明しています。
* use of a PCECC to set up static TE LSPs (the PCEP extension for this use case is in [RFC9050])
* PCECCを使用して静的TE LSPをセットアップします（このユースケースのPCEP拡張は[RFC9050]にあります）
* use of a PCECC in SR [RFC8402]
* SR [RFC8402]でのPCECCの使用
* use of a PCECC to set up Multicast Point-to-Multipoint (P2MP) LSPs
* PCECCを使用してマルチキャストポイントツーマルチポイント（P2MP）LSP
* use of a PCECC to set up Service Function Chaining (SFC) [RFC7665]
* PCECCを使用してサービス関数チェーン（SFC）[RFC7665]をセットアップします
* use of a PCECC in optical networks
* 光ネットワークでのPCECCの使用
Section 3.1 describes the general case of a PCECC being in charge of managing MPLS label space, which is a prerequisite for further use cases. Further, various use cases (SR, Multicast, etc.) are described in the following sections to showcase scenarios that can benefit from the use of a PCECC.
セクション3.1では、MPLSラベルスペースの管理を担当するPCECCの一般的なケースについて説明します。これは、さらなるユースケースの前提条件です。さらに、PCECCの使用から利益を得ることができるシナリオを紹介するために、以下のセクションでさまざまなユースケース（SR、マルチキャストなど）について説明します。
It is interesting to note that some of the use cases listed can also be supported via BGP instead of PCEP. However, within the scope of this document, the focus is on the use of PCEP.
リストされているユースケースの一部は、PCEPの代わりにBGPを介してサポートできることに注意するのは興味深いことです。ただし、このドキュメントの範囲内では、PCEPの使用に焦点が当てられています。
As per [RFC8283], in some cases, the PCECC can take responsibility for managing some part of the MPLS label space for each of the routers that it controls, and it may take 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.
[RFC8283]によると、場合によっては、PCECCは、制御する各ルーターのMPLSラベルスペースの一部を管理する責任を負う可能性があり、各ルーターのラベルスペースを分割し、異なる異なるものを割り当てる責任を負う可能性があります。さまざまな用途の部品、PCEPを使用してルーターに範囲を伝えます。
[RFC9050] describes a mode where LSPs are provisioned as explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label forwarding instructions to program and what resources to reserve. The controller uses PCEP to communicate with each router along the path of the end-to-end LSP. For this to work, the PCECC will take responsibility for managing some part of the MPLS label space for each of the routers that it controls. An extension to PCEP could be done to allow a PCC to inform the PCE of such a label space to control (see [PCE-ID] for a possible PCEP extension to support the advertisement of the MPLS label space for the PCE to control).
[RFC9050]は、LSPがエンドツーエンドパスの各ホップで明示的なラベル命令としてプロビジョニングされるモードを記述します。パスに沿った各ルーターは、プログラムするラベル転送指示と予約するリソースを伝える必要があります。コントローラーは、PCEPを使用して、エンドツーエンドLSPのパスに沿って各ルーターと通信します。これが機能するためには、PCECCは、制御する各ルーターのMPLSラベルスペースの一部を管理する責任を負います。PCCPの拡張機能は、PCCがこのようなラベルスペースのPCEに制御するための通知を許可するために実行できます（PCEを制御するためのMPLSラベルスペースの広告をサポートするために、可能なPCEP拡張について[PCE-ID]を参照）。
[RFC8664] specifies extensions to PCEP that allow a stateful PCE to compute, update, or initiate SR-TE paths. [PCECC-SR] describes the mechanism for a PCECC to allocate and provision the node/prefix/ adjacency label (Segment Routing Identifier (SID)) via PCEP. To make such an allocation, the PCE needs to be aware of the label space from the Segment Routing Global Block (SRGB) or Segment Routing Local Block (SRLB) [RFC8402] of the node that it controls. A mechanism for a PCC to inform the PCE of such a label space to control is needed within the PCEP. The full SRGB/SRLB of a node could be learned via existing IGP or BGP-LS [RFC9552] mechanisms.
[RFC8664]は、ステートフルPCEがSR-TEパスを計算、更新、または開始できるようにするPCEPへの拡張機能を指定します。[PCECC-SR]は、PCECCがPCEPを介してノード/プレフィックス/隣接ラベル（セグメントルーティング識別子（SID））を割り当ててプロビジョニングするメカニズムを説明しています。このような割り当てを行うには、PCEが、それが制御するノードのローカルブロック（SRLB）[RFC8402]をルーティングするセグメントルーティンググローバルブロック（SRGB）またはセグメントルーティングのラベルスペースを認識する必要があります。PCCがPCEを制御するためにPCEに通知するメカニズムがPCEP内で必要です。ノードの完全なSRGB/SRLBは、既存のIGPまたはBGP-LS [RFC9552]メカニズムを介して学習できます。
Further, there have been proposals for a global label range in MPLS as well as the use of PCECC architecture to learn the label space of each node to determine and provision the global label range.
さらに、MPLSのグローバルラベル範囲と、各ノードのラベルスペースを学習してグローバルラベル範囲を決定および提供するためのPCECCアーキテクチャの使用についての提案がありました。
+------------------------------+ +------------------------------+
| PCE DOMAIN 1 | | PCE DOMAIN 2 |
| +--------+ | | +--------+ |
| | | | | | | |
| | PCECC1 | ---------PCEP---------- | PCECC2 | |
| | | | | | | |
| | | | | | | |
| +--------+ | | +--------+ |
| ^ ^ | | ^ ^ |
| / \ PCEP | | PCEP / \ |
| V V | | V V |
| +--------+ +--------+ | | +--------+ +--------+ |
| | Node11 | | Node1n | | | | Node21 | | Node2n | |
| | | ...... | | | | | | ...... | | |
| | PCECC | | PCECC | | | | PCECC | |PCECC | |
| |Enabled | | Enabled| | | |Enabled | |Enabled | |
| +--------+ +--------+ | | +--------+ +--------+ |
| | | |
+------------------------------+ +------------------------------+
Figure 1: PCECC for MPLS Label Management
図1：MPLSラベル管理用PCECC
As shown in Figure 1:
図1に示すように：
* The PCC will advertise the PCECC capability to the PCECC [RFC9050].
* PCCは、PCECC機能をPCECC [RFC9050]に宣伝します。
* The PCECC could also learn the label range set aside by the PCC (via [PCE-ID]).
* PCECCは、PCC（[PCE-ID]を介して）によって確保されたラベル範囲を学習することもできます。
* Optionally, the PCECC could determine the shared MPLS global label range for the network.
* オプションで、PCECCはネットワークの共有MPLSグローバルラベル範囲を決定できます。
- In the case that the shared global label range needs to be negotiated across multiple domains, the central controllers of these domains will also need to negotiate a common global label range across domains.
- 共有されたグローバルラベル範囲を複数のドメインでネゴシエートする必要がある場合、これらのドメインの中央コントローラーは、ドメイン全体で共通のグローバルラベル範囲をネゴシエートする必要があります。
- The PCECC will need to set the shared global label range to all PCC nodes in the network.
- PCECCは、ネットワーク内のすべてのPCCノードに共有グローバルラベル範囲を設定する必要があります。
As per [RFC9050], the PCECC could also rely on the PCC to make label allocations initially and use PCEP to distribute it to where it is needed.
[RFC9050]によると、PCECCはPCCに依存してラベル割り当てを最初に行い、PCEPを使用して必要な場所に配布することもできます。
SR [RFC8402] leverages the source routing paradigm. Using SR, a source node steers a packet through a path without relying on hop-by-hop signalling protocols such as LDP [RFC5036] or RSVP-TE [RFC3209]. Each path is specified as an ordered list of instructions called "segments". Each segment is an instruction to route the packet to a specific place in the network or to perform a specific service on the packet. A database of segments can be distributed through the network using an intra-domain routing protocol (such as IS-IS or OSPF), an inter-domain protocol (such as BGP), or by any other means. PCEP could also be one of other protocols.
SR [RFC8402]は、ソースルーティングパラダイムを活用します。SRを使用して、ソースノードは、LDP [RFC5036]やRSVP-TE [RFC3209]などのホップバイホップシグナリングプロトコルに依存せずにパスをパケットに導きます。各パスは、「セグメント」と呼ばれる命令の順序付けリストとして指定されています。各セグメントは、パケットをネットワーク内の特定の場所にルーティングしたり、パケットで特定のサービスを実行する命令です。セグメントのデータベースは、ドメイン内ルーティングプロトコル（IS-ISやOSPFなど）、ドメイン間プロトコル（BGPなど）、またはその他の手段でネットワークを介して配布できます。PCEPは、他のプロトコルの1つでもあります。
[RFC8664] specifies the PCEP extension specific to SR for SR over MPLS (SR-MPLS). The PCECC may further use the PCEP for distributing SR Segment Identifiers (SIDs) to the SR nodes (PCC) with some benefits. If the PCECC allocates and maintains the SIDs in the network for the nodes and adjacencies, and further distributes them to the SR nodes directly via the PCEP session, then it is more advantageous over the configurations on each SR node and flooding them via IGP, especially in an SDN environment.
[RFC8664]は、MPLS（SR-MPLS）のSRのSRに固有のPCEP拡張を指定します。PCECCはさらに、SRセグメント識別子（SIDS）をSRノード（PCC）に分配するためにPCEPを使用して、いくつかの利点があります。PCECCがノードと隣接のネットワーク内のSIDを割り当てて維持し、PCEPセッションを介してSRノードにさらに配布する場合、各SRノードの構成よりも有利であり、特にIGPを介してそれらをあふれさせることはより有利です。SDN環境で。
When the PCECC is used for the distribution of the Node-SID and Adj-SID for SR-MPLS, the Node-SID is allocated from the SRGB of the node and the Adj-SID is allocated from the SRLB of the node as described in [PCECC-SR].
PCECCがSR-MPLS用のノードSIDおよびadj-SIDの分布に使用される場合、ノードSIDはノードのSRGBから割り当てられ、adj-SIDはノードのSRLBから割り当てられます。[PCECC-SR]。
[RFC8355] identifies various protection and resiliency use cases for SR. Path protection lets the ingress node be in charge of the failure recovery (used for SR-TE [RFC8664]). Also, protection can be performed by the node adjacent to the failed component, commonly referred to as "local protection techniques" or "fast-reroute (FRR) techniques". In the case of the PCECC, the protection paths can be precomputed and set up by the PCE.
[RFC8355]は、SRのさまざまな保護および回復力のユースケースを特定します。パス保護により、イングレスノードが障害回復を担当することができます（SR-TE [RFC8664]に使用）。また、保護は、一般に「ローカル保護技術」または「Fast-Reroute（FRR）技術」と呼ばれる故障コンポーネントに隣接するノードによって実行できます。PCECCの場合、PCEによって保護パスを事前計算して設定できます。
Figure 2 illustrates the use case where the Node-SID and Adj-SID are allocated by the PCECC for SR-MPLS.
図2は、SR-MPLSのためにPCECCによってノードSIDおよびadj-SIDが割り当てられるユースケースを示しています。
192.0.2.1/32
+----------+
| R1(1001) |
+----------+
|
+----------+
| R2(1002) | 192.0.2.2/32
+----------+
* | * *
* | * *
*link1| * *
192.0.2.4/32 * | *link2 * 192.0.2.5/32
+-----------+ 9001| * +-----------+
| R4(1004) | | * | R5(1005) |
+-----------+ | * +-----------+
* | *9003 * +
* | * * +
* | * * +
+-----------+ +-----------+
192.0.2.3/32 | R3(1003) | |R6(1006) |192.0.2.6/32
+-----------+ +-----------+
|
+-----------+
| R8(1008) | 192.0.2.8/32
+-----------+
Figure 2: SR Topology
図2：SRトポロジー
Each node (PCC) is allocated a Node-SID by the PCECC. The PCECC needs to update the label mapping of each node to all the other nodes in the domain. After receiving the label mapping, each node (PCC) uses the local routing information to determine the next hop and download the label forwarding instructions accordingly. The forwarding behavior and the end result are the same as IGP shortest-path SR forwarding based on Node-SIDs. Thus, from anywhere in the domain, it enforces the ECMP-aware shortest-path forwarding of the packet towards the related node.
各ノード（PCC）は、PCECCによってノードSIDを割り当てられます。PCECCは、各ノードのラベルマッピングをドメイン内の他のすべてのノードに更新する必要があります。ラベルマッピングを受信した後、各ノード（PCC）はローカルルーティング情報を使用して次のホップを決定し、それに応じてラベル転送手順をダウンロードします。転送の動作と最終結果は、ノードSIDに基づくIGP最短パスSR転送と同じです。したがって、ドメインのどこからでも、関連するノードに向けてパケットのECMPを認識している最短パス転送を実施します。
The PCECC can allocate an Adj-SID for each adjacency in the network. The PCECC sends a PCInitiate message to update the label mapping of each adjacency to the corresponding nodes in the domain. Each node (PCC) downloads the label forwarding instructions accordingly. The forwarding behavior and the end result are similar to IGP-based Adj-SID allocation and usage in SR.
PCECCは、ネットワーク内の各隣接にadj-SIDを割り当てることができます。PCECCはPCINITIATEメッセージを送信して、各隣接のラベルマッピングをドメイン内の対応するノードに更新します。各ノード（PCC）は、それに応じてラベル転送手順をダウンロードします。転送挙動と最終結果は、SRのIGPベースのADJ-SID割り当てと使用に似ています。
These mechanisms are described in [PCECC-SR].
これらのメカニズムは[PCECC-SR]で説明されています。
When using PCECC for SR-MPLS Best Effort (BE) Paths, the PCECC needs to allocate the Node-SID (without calculating the explicit path for the SR path). The ingress router of the forwarding path needs to encapsulate the destination Node-SID on top of the packet. All the intermediate nodes will forward the packet based on the destination Node-SID. It is similar to the LDP LSP.
SR-MPLSの最善の努力（BE）パスにPCECCを使用する場合、PCECCはノードSIDを割り当てる必要があります（SRパスの明示的なパスを計算せずに）。転送パスのイングレスルーターは、パケットの上に宛先ノードSIDをカプセル化する必要があります。すべての中間ノードは、宛先ノードSIDに基づいてパケットを転送します。LDP LSPに似ています。
R1 may send a packet to R8 simply by pushing an SR label with segment {1008} (Node-SID for R8). The path will be based on the routing / next hop calculation on the routers.
R1は、SRラベルをセグメント{1008}（R8用のノードSID）でプッシュするだけで、R8にパケットを送信できます。パスは、ルーターのルーティング /次のホップ計算に基づいています。
SR-TE paths may not follow an IGP shortest path tree (SPT). Such paths may be chosen by a PCECC and provisioned on the ingress node of the SR-TE path. The SR header consists of a list of SIDs (or MPLS labels). The header has all necessary information so that the packets can be guided from the ingress node to the egress node of the path. Hence, there is no need for any signalling protocol. For the case where a strict traffic engineering path is needed, all the Adj-SIDs are stacked; otherwise, a combination of Node-SIDs or Adj-SIDs can be used for the SR-TE paths.
SR-TEパスは、IGP最短パスツリー（SPT）をたどることはできません。このようなパスは、PCECCによって選択され、SR-TEパスのイングレスノードにプロビジョニングされる場合があります。SRヘッダーは、SIDS（またはMPLSラベル）のリストで構成されています。ヘッダーにはすべての必要な情報があるため、パケットをイングレスノードからパスの出力ノードに誘導できます。したがって、シグナル伝達プロトコルは必要ありません。厳格な交通工学パスが必要な場合、すべてのadj-SIDが積み重ねられます。それ以外の場合、SR-TEパスにノードSIDまたはADJ-SIDの組み合わせを使用できます。
As shown in Figure 3, R1 may send a packet to R8 by pushing an SR header with segment list {1002, 9001, 1008}, where 1002 and 1008 are the Node-SIDs of R2 and R8, respectively. 9001 is the Adj-SID for link1. The path should be: "R1-R2-link1-R3-R8".
図3に示すように、R1は、セグメントリスト{1002、9001、1008}でSRヘッダーをプッシュすることによりR8にパケットを送信する場合があります。1002と1008はそれぞれR2とR8のノードシドです。9001は、link1のadj-sidです。パスは次のとおりです。「R1-R2-Link1-R3-R8」。
To achieve this, the PCECC first allocates and distributes SIDs as described in Section 3.2.1. [RFC8664] describes the mechanism for a PCE to compute, update, or initiate SR-MPLS TE paths.
これを達成するために、PCECCは、セクション3.2.1で説明されているように、最初にSIDを割り当てて配布します。[RFC8664]は、PCEがSR-MPLS TEパスを計算、更新、または開始するメカニズムを説明しています。
192.0.2.1/32
+----------+
| R1 (1001)|
+----------+
| |
90011 | |90012
link1 | |link2
+----------+
| R2 (1002)| 192.0.2.2/32
+----------+
link3 * | * * link4
90023 * | * * 90024
*link5| * *
192.0.2.4/32 *90025 | *link6 * 192.0.2.5/32
+-----------+ | *90026+-----------+
| R4 (1004) | | * | R5 (1005) |
+-----------+ | * +-----------+
* | * +
link10 * | * link7 +
* | * +
+-----------+ +-----------+
192.0.2.3/32 | R3 (1003) | |R6 (1006) |192.0.2.6/32
+-----------+ +-----------+
| |
|link8 |
| |----------|link9
+-----------+
| R8 (1008) | 192.0.2.8/32
+-----------+
Figure 3: PCECC TE LSP Setup Example
図3：PCECC TE LSPセットアップの例
Refer to Figure 3 for an example of TE topology, where 100x are Node-SIDs and 900xx are Adj-SIDs.
TEトポロジの例については、図3を参照してください。100xはノードシドで、900xxはadj-sidsです。
* The SID allocation and distribution are done by the PCECC with all Node-SIDs (100x) and all Adj-SIDs (900xx).
* SIDの割り当てと分布は、すべてのノードSID（100x）およびすべてのadj-SID（900xx）を備えたPCECCによって行われます。
* Based on path computation request/delegation or PCE initiation, the PCECC receives a request with constraints and optimization criteria from a PCC.
* PATH計算要求/委任またはPCEの開始に基づいて、PCECCはPCCから制約と最適化基準を備えた要求を受け取ります。
* The PCECC will calculate the optimal path according to the given constraints (e.g., bandwidth (BW)).
* PCECCは、指定された制約（例：帯域幅（BW））に従って最適なパスを計算します。
* The PCECC will provision the SR-MPLS TE LSP path ("R1-link1-R2-link6-R3-R8") at the ingress node: {90011, 1002, 90026, 1003, 1008}
* PCECCは、SR-MPLS TE LSPパス（ "R1-Link1-R2-Link6-R3-R8"）をIngressノードにプロビジョニングします：{90011、1002、90026、1003、1008}
* For the end-to-end protection, the PCECC can provision the secondary path ("R1-link2-R2-link4-R5-R8"): {90012, 1002, 90024, 1005, 1008}.
* エンドツーエンドの保護のために、PCECCはセカンダリパス（ "R1-Link2-R2-Link4-R5-R8"）をプロビジョニングできます：{90012、1002、90024、1005、1008}。
[RFC8402] defines SR architecture, which uses an SR Policy to steer packets from a node through an ordered list of segments. The SR Policy could be configured on the headend or instantiated by an SR controller. The SR architecture does not restrict how the controller programs the network. In this case, the focus is on PCEP as the protocol for SR Policy delivery from the PCE to PCC.
[RFC8402]は、SRアーキテクチャを定義します。SRアーキテクチャは、SRポリシーを使用して、順序付けられたセグメントリストを介してノードからパケットを操縦します。SRポリシーは、ヘッドエンドで構成するか、SRコントローラーによってインスタンス化される可能性があります。SRアーキテクチャは、コントローラーがネットワークをどのようにプログラムするかを制限していません。この場合、PCCからPCCへのSRポリシー提供のプロトコルとしてのPCEPに焦点が当てられています。
An SR Policy architecture is described in [RFC9256]. An SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing policy for the steering of traffic for a specific purpose (e.g., for a specific Service Level Agreement (SLA)) from that node.
SRポリシーアーキテクチャは[RFC9256]で説明されています。SRポリシーは、特定の目的のためのトラフィックのステアリング（例：特定のサービスレベル契約（SLA）など）のソースルーティングポリシーを実装するためのノード上の順序付けられたセグメントリストのインスタンス化を可能にするフレームワークです。。
An SR Policy is identified through the tuple <headend, color, endpoint>.
SRポリシーは、tuple <headend、color、endpoint>を通じて識別されます。
Figure 3 is used as an example of PCECC application for SR Policy instantiation for SR-MPLS, where the Node-SIDs are 100x and the Adj-SIDs are 900xx.
図3は、SR-MPLSのSRポリシーインスタンス化のためのPCECCアプリケーションの例として使用されます。ここで、ノードSIDは100倍で、Adj-SIDは900XXです。
Let's assume that R1 needs to have two disjoint SR Policies towards R8 based on different BWs. This means the possible paths are:
R1は、異なるBWSに基づいてR8に対して2つのばらばらのSRポリシーを持つ必要があると仮定しましょう。これは、可能なパスが次のことを意味します。
* POL1: {Headend R1, color 100, Endpoint R8; Candidate Path1: Segment List 1: {90011, 1002, 90023, 1004, 1003, 1008}}
* pol1：{headend R1、Color 100、Endpoint R8;候補PATH1：セグメントリスト1：{90011、1002、90023、1004、1003、1008}}
* POL2: {Headend R1, color 200, Endpoint R8; Candidate Path1: Segment List 1: {90012, 1002, 90024, 1005, 1006, 1008}}
* POL2：{HeadEnd R1、Color 200、Endpoint R8;候補PATH1：セグメントリスト1：{90012、1002、90024、1005、1006、1008}}}
Each SR Policy (including the candidate path and segment list) will be signalled to a headend (R1) via PCEP [PCEP-POLICY] with the addition of an ASSOCIATION object. A Binding SID (BSID) [RFC8402] can be used for traffic steering of labelled traffic into an SR Policy; a BSID can be provisioned from the PCECC also via PCEP [RFC9604]. For non-labelled traffic steering into the SR Policy POL1 or POL2, a per-destination traffic steering will be used by means of the BGP Color Extended Community [RFC9012].
各SRポリシー（候補パスとセグメントリストを含む）は、Associationオブジェクトを追加して、PCEP [PCEP-Policy]を介してヘッドエンド（R1）に通知されます。バインディングSID（BSID）[RFC8402]は、SRポリシーへのラベル付きトラフィックのトラフィックステアリングに使用できます。BSIDは、PCEP [RFC9604]を介してPCECCからプロビジョニングできます。SRポリシーPOL1またはPOL2への非標識トラフィックステアリングの場合、BGPカラーの拡張コミュニティ[RFC9012]によって、設定ごとのトラフィックステアリングが使用されます。
The procedure is as follows:
手順は次のとおりです。
* The PCECC allocates Node-SIDs and Adj-SIDs using the mechanism described in Section 3.2.1 for all nodes and links.
* PCECCは、すべてのノードとリンクについてセクション3.2.1で説明したメカニズムを使用して、ノードSIDとadj-SIDを割り当てます。
* The PCECC calculates disjoint paths for POL1 and POL2 and create segment lists for them: {90011, 1002, 90023, 1004, 1003, 1008};{90012, 1002, 90024, 1005, 1006, 1008}.
* PCECCは、POL1およびPOL2の分離パスを計算し、それらのセグメントリストを作成します：{90011、1002、90023、1004、1003、1008}; {90012、1002、90024、1005、1006、1008}。
* The PCECC forms both SR Policies POL1 and POL2.
* PCECCは、SRポリシーPOL1とPOL2の両方を形成します。
* The PCECC sends both POL1 and POL2 to R1 via PCEP.
* PCECCは、PCEPを介してPOL1とPOL2の両方をR1に送信します。
* The PCECC optionally allocates BSIDs for the SR Policies.
* PCECCはオプションで、SRポリシーにBSIDを割り当てます。
* The traffic from R1 to R8, which fits to color 100, will be steered to POL1 and follows the path: "R1-link1-R2-link3-R4-R3-R8". The traffic from R1 to R8, which fits color 200, will be steered to POL2 and follows the path: "R1-link2-R2-link4-R5-R6-R8". Due to the possibility of having many segment lists in the same candidate path of each POL1/POL2, the PCECC could provision more paths towards R8 and traffic will be balanced either as ECMP or as weighted-ECMP (W-ECMP). This is the advantage of SR Policy architecture.
* R1からR8へのトラフィックは、100色に収まり、POL1に操縦され、パス「R1-Link1-R2-Link3-R4-R3-R8」に従います。Color 200に適合するR1からR8へのトラフィックはPOL2に操縦され、パス「R1-Link2-R2-Link4-R5-R6-R8」に従います。各POL1/POL2の同じ候補パスに多くのセグメントリストを持つ可能性があるため、PCECCはR8へのより多くのパスを提供することができ、トラフィックはECMPまたは加重ECMP（W-ECMP）としてバランスが取れます。これがSRポリシーアーキテクチャの利点です。
Note that an SR Policy can be associated with multiple candidate paths. A candidate path is selected when it is valid and it is determined to be the best path of the SR Policy as described in [RFC9256].
SRポリシーは、複数の候補パスに関連付けられる可能性があることに注意してください。[RFC9256]で説明されているように、候補パスが有効である場合に選択され、SRポリシーの最良のパスであると判断されます。
As per [RFC8402], with SR, a node steers a packet through an ordered list of instructions, called segments. SR can be applied to the IPv6 architecture with the Segment Routing Header (SRH) [RFC8754]. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the destination address of the packet. Upon completion of a segment, a pointer in the new routing header is incremented and indicates the next segment.
[RFC8402]によると、SRを使用して、ノードは、セグメントと呼ばれる順序付けられた命令リストを介してパケットを操縦します。SRは、セグメントルーティングヘッダー（SRH）[RFC8754]を使用してIPv6アーキテクチャに適用できます。セグメントはIPv6アドレスとしてエンコードされます。セグメントの順序付けられたリストは、ルーティングヘッダーのIPv6アドレスの順序付けリストとしてエンコードされています。アクティブセグメントは、パケットの宛先アドレスで示されています。セグメントが完了すると、新しいルーティングヘッダーのポインターが増加し、次のセグメントを示します。
As per [RFC8754], an SR over IPv6 (SRv6) Segment is a 128-bit value. "SRv6 SID" or simply "SID" are often used as a shorter reference for "SRv6 Segment". [RFC8986] defines the SRv6 SID as consisting of LOC:FUNCT:ARG.
[RFC8754]によると、IPv6（SRV6）セグメント上のSRは128ビット値です。「SRV6 SID」または単に「SID」は、「SRV6セグメント」のより短い参照としてよく使用されます。[RFC8986]は、SRV6 SIDをloc：funct：argで構成されるものとして定義します。
[RFC9603] extends [RFC8664] to support SR for the IPv6 data plane. Further, a PCECC could be extended to support SRv6 SID allocation and distribution. An example of how PCEP extensions could be extended for SRv6 for a PCECC is described in [PCECC-SRv6].
[RFC9603]は[RFC8664]を拡張して、IPv6データプレーンのSRをサポートします。さらに、SRV6 SIDの割り当てと分布をサポートするためにPCECCを拡張できます。PCECCのSRV6のPCEP拡張機能をどのように拡張できるかの例は、[PCECC-SRV6]で説明されています。
2001:db8::1
+----------+
| R1 |
+----------+
|
+----------+
| R2 | 2001:db8::2
+----------+
* | * *
* | * *
*link1| * *
2001:db8::4 * | *link2 * 2001:db8::5
+-----------+ | * +-----------+
| R4 | | * | R5 |
+-----------+ | * +-----------+
* | * * +
* | * * +
* | * * +
+-----------+ +-----------+
2001:db8::3 | R3 | |R6 |2001:db8::6
+-----------+ +-----------+
|
+-----------+
| R8 | 2001:db8::8
+-----------+
Figure 4: PCECC for SRv6
図4：SRV6のPCECC
In this case, as shown in Figure 4, the PCECC could assign the SRv6 SID (in the form of an IPv6 address) to be used for node and adjacency. Later, the SRv6 path in the form of a list of SRv6 SIDs could be used at the ingress. Some examples:
この場合、図4に示すように、PCECCはSRV6 SID（IPv6アドレスの形で）を割り当てて、ノードと隣接に使用できます。その後、SRV6 SIDのリストの形のSRV6パスをイングレスで使用できます。いくつかの例：
* The best path towards R8: SRv6 SID-List={2001:db8::8}
* R8への最適なパス：SRV6 SID-LIST = {2001：DB8 :: 8}
* The path towards R8 via R5: SRv6 SID-List={2001:db8::5, 2001:db8::8}
* R5を介したR8へのパス：SRV6 SID-LIST = {2001：DB8 :: 5、2001：DB8 :: 8}
The rest of the procedures and mechanisms remain the same as SR-MPLS.
残りの手順とメカニズムは、SR-MPLと同じままです。
As described in Section 3.1.2 of [RFC8283], the PCECC architecture supports the provisioning of static TE LSPs. To achieve this, the existing PCEP can be used to communicate between the PCECC and nodes along the path to provision explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label-forwarding instructions to program and what resources to reserve. The PCECC keeps a view of the network and determines the paths of the end-to-end LSPs, and the controller uses PCEP to communicate with each router along the path of the end-to-end LSP.
[RFC8283]のセクション3.1.2で説明されているように、PCECCアーキテクチャは静的TE LSPのプロビジョニングをサポートしています。これを達成するために、既存のPCEPを使用して、パスに沿ってPCECCとノード間を通信して、エンドツーエンドパスの各ホップで明示的なラベル命令を提供します。パスに沿った各ルーターは、プログラムするためのラベルフォード指示と予約するリソースを伝える必要があります。PCECCはネットワークのビューを保持し、エンドツーエンドLSPのパスを決定し、コントローラーはPCEPを使用して、エンドツーエンドLSPのパスに沿って各ルーターと通信します。
192.0.2.1/32
+----------+
| R1 |
+----------+
| |
|link1 |
| |link2
+----------+
| R2 | 192.0.2.2/32
+----------+
link3 * | * * link4
* | * *
*link5| * *
192.0.2.4/32 * | *link6 * 192.0.2.5/32
+-----------+ | * +-----------+
| R4 | | * | R5 |
+-----------+ | * +-----------+
* | * * +
link10 * | * *link7 +
* | * * +
+-----------+ +-----------+
192.0.2.3/32 | R3 | |R6 |192.0.2.6/32
+-----------+ +-----------+
| |
|link8 |
| |link9
+-----------+
| R8 | 192.0.2.8/32
+-----------+
Figure 5: PCECC TE LSP Setup Example
図5：PCECC TE LSPセットアップの例
Refer to Figure 5 for an example TE topology.
TEトポロジの例については、図5を参照してください。
* Based on path computation request/delegation or PCE initiation, the PCECC receives a request with constraints and optimization criteria.
* PATH計算要求/委任またはPCEの開始に基づいて、PCECCは制約と最適化基準を備えた要求を受け取ります。
* The PCECC will calculate the optimal path according to the given constraints (e.g., BW).
* PCECCは、指定された制約（例：BW）に従って最適なパスを計算します。
* The PCECC will provision each node along the path and assign incoming and outgoing labels from R1 to R8 with the path as "R1-link1-R2-link3-R4-link10-R3-link8-R8":
* PCECCは、パスに沿って各ノードをプロビジョニングし、パスを「R1-LINK1-R2-LINK3-RINK10-RINK8-R8」とともにR1からR8に割り当てます：
- R1: Outgoing label 1001 on link 1
- R1：リンク1の発信ラベル1001
- R2: Incoming label 1001 on link 1
- R2：リンク1の着信ラベル1001
- R2: Outgoing label 2003 on link 3
- R2：リンク3の発信ラベル2003
- R4: Incoming label 2003 on link 3
- R4：リンク3の着信ラベル2003
- R4: Outgoing label 4010 on link 10
- R4：リンク10の発信ラベル4010
- R3: Incoming label 4010 on link 10
- R3：リンク10の着信ラベル4010
- R3: Outgoing label 3008 on link 8
- R3：リンク8の発信ラベル3008
- R8: Incoming label 3008 on link 8
- R8：リンク8の着信ラベル3008
* This can also be represented as: {R1, link1, 1001}, {1001, R2, link3, 2003}, {2003, R4, link10, 4010}, {4010, R3, link8, 3008}, {3008, R8}.
* これは、{r1、link1、1001}、{1001、r2、link3、2003}、{2003、r4、link10、4010}、{4010、r3、link8、3008}、{3008、r8}として次のように表現できます。。
* For the end-to-end protection, the PCECC programs each node along the path from R1 to R8 with the secondary path: {R1, link2, 1002}, {1002, R2, link4, 2004}, {2004, R5, link7, 5007}, {5007, R3, link9, 3009}, {3009, R8}.
* エンドツーエンドの保護のために、PCECCは各ノードをR1からR8へのパスに沿ったセカンダリパスでプログラムします：{r1、link2、1002}、{1002、r2、link4、2004}、{2004、r5、link7、5007}、{5007、r3、link9、3009}、{3009、r8}。
* It is also possible to have a bypass path for the local protection set up by the PCECC. For example, use the primary path as above, then to protect the node R4 locally, the PCECC can program the bypass path like this: {R2, link5, 2005}, {2005, R3}. By doing this, the node R4 is locally protected at R2.
* PCECCによって設定されたローカル保護のバイパスパスを持つこともできます。たとえば、上記のプライマリパスを使用してから、ノードR4をローカルで保護するために、PCECCは次のようなバイパスパスをプログラムできます：{r2、link5、2005}、{2005、r3}。これを行うことにより、ノードR4はR2でローカルで保護されています。
Very often, many service providers use TE tunnels for solving issues with non-deterministic paths in their networks. One example of such applications is the usage of TEs in the mobile backhaul (MBH). Consider the topology as shown in Figure 6 (where AGG 1...AGG N are Aggregation routers, and Core 1...Core N are Core routers).
多くの場合、多くのサービスプロバイダーは、ネットワーク内の非決定的なパスの問題を解決するためにTEトンネルを使用しています。このようなアプリケーションの1つの例は、モバイルバックホール（MBH）でのTEの使用です。図6に示すようにトポロジーを考えてみましょう（Agg 1 ... Agg nは集約ルーター、コア1 ...コアnはコアルーターです）。
TE1 ----------->
+--------+ +------+ +-----+ +-------+ +------+ +---+
|Access |----|Access|----|AGG 1|----|AGG N-1|----|Core 1|--|SR1|
|SubNode1| |Node1 | +-----+ +-------+ +------+ +---+
+--------+ +------+ | | | ^ |
| Access | Access | AGG Ring 1| | |
| SubRing 1 | Ring 1 | | | | |
+--------+ +------+ +-----+ | | |
|Access | |Access| |AGG 2| | | |
|SubNode2| |Node2 | +-----+ | | |
+--------+ +------+ | | | | |
| | | | | | |
| | | +---TE2---|-+ |
+--------+ +------+ +-----+ +-------+ +------+ +---+
|Access | |Access|----|AGG 3|----| AGG N |----|Core N|--|SRn|
|SubNodeN|----|NodeN | +-----+ +-------+ +------+ +---+
+--------+ +------+
Figure 6: PCECC LB Use Case
図6：PCECC LBユースケース
This MBH architecture uses L2 access rings and sub-rings. L3 starts at the aggregation layer. For the sake of simplicity, the figure shows only one access sub-ring. The access ring and aggregation ring are connected by Nx10GE interfaces. The aggregation domain runs its own IGP. There are two egress routers (AGG N-1 and AGG N) that are connected to the Core domain (Core 1...Core N) via L2 interfaces. The Core also has connections to service routers; RSVP-TE or SR-TE is used for MPLS transport inside the ring. There could be at least two tunnels (one way) from each AGG router to egress AGG routers. There are also many L2 access rings connected to AGG routers.
このMBHアーキテクチャは、L2アクセスリングとサブリングを使用しています。L3は集約層から始まります。簡単にするために、この図は1つのアクセスサブリングのみを示しています。アクセスリングと集約リングは、NX10GEインターフェイスで接続されています。集約ドメインは独自のIGPを実行します。L2インターフェイスを介してコアドメイン（コア1 ...コアN）に接続されている2つの出力ルーター（AGG N-1とAGG N）があります。コアには、サービスルーターへの接続もあります。RSVP-TEまたはSR-TEは、リング内のMPLS輸送に使用されます。各AGGルーターから少なくとも2つのトンネル（1つの方法）がある可能性があります。AGGルーターに接続された多くのL2アクセスリングもあります。
Service deployment is made by means of Layer 2 Virtual Private Networks (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 Virtual Private Networks (L3VPNs), or Ethernet VPNs (EVPNs). Those services use MPLS TE (or SR-TE) as transport towards egress AGG routers. TE tunnels could be used as transport towards service routers in case of architecture based on seamless MPLS [MPLS-SEAMLESS].
サービスの展開は、レイヤー2仮想プライベートネットワーク（L2VPNS）、仮想プライベートLANサービス（VPLSS）、レイヤー3仮想プライベートネットワーク（L3VPNS）、またはイーサネットVPN（EVPN）によって行われます。これらのサービスは、MPLS TE（またはSR-TE）を出力アグルーターへの輸送として使用します。TEトンネルは、シームレスMPL [MPLSシームレス]に基づいたアーキテクチャの場合、サービスルーターへの輸送として使用できます。
Load Balancing (LB) between TE tunnels involves distributing network traffic across multiple TE tunnels to optimize the use of available network resources, enhance performance, and ensure reliability. Some common techniques include Equal-Cost Multipath (ECMP) and Unequal-Cost Multipath (UCMP) based on the BW of the TE tunnels.
TEトンネル間の負荷分散（LB）には、利用可能なネットワークリソースの使用を最適化し、パフォーマンスを向上させ、信頼性を確保するために、複数のTEトンネルにネットワークトラフィックを配布することが含まれます。いくつかの一般的な手法には、TEトンネルのBWに基づく等しいマルチパス（ECMP）および不平等なコストマルチパス（UCMP）が含まれます。
There is a need to solve the following tasks:
次のタスクを解決する必要があります。
* Perform automatic LB amongst TE tunnels according to current traffic loads.
* 現在のトラフィック負荷に応じて、トンネル間で自動LBを実行します。
* Manage TE BW by guaranteeing BW for specific services (such as High-Speed Internet (HSI), IPTV, etc.) and enabling time-based BW reservation (such as Bandwidth on Demand (BoD)).
* 特定のサービス（高速インターネット（HSI）、IPTVなど）のBWを保証し、時間ベースのBW予約（帯域幅オンデマンド（BOD）など）を保証することにより、TE BWを管理します。
* Simplify the development of TE tunnels by automation without any manual intervention.
* 手動で介入することなく、自動化によりTEトンネルの開発を簡素化します。
* Provide flexibility for service router placement (anywhere in the network by the creation of transport LSPs to them).
* サービスルーターの配置に柔軟性を提供します（輸送LSPを作成することにより、ネットワーク内のどこでも）。
In this section, the focus is on LB tasks. LB tasks could be solved by means of the PCECC in the following ways:
このセクションでは、LBタスクに焦点を当てています。LBタスクは、次の方法でPCECCによって解決できます。
* Applications, network services, or operators can ask the SDN controller (PCECC) for LSP-based LB between AGG X and AGG N/AGG N-1 (egress AGG routers that have connections to the core). Each of these will have associated constraints (such as BW, inclusion or exclusion of specific links or nodes, number of paths, Objective Function (OF), need for disjoint LSP paths, etc.).
* アプリケーション、ネットワークサービス、またはオペレーターは、AGG XとAGG N/AGG N-1（コアに接続する出力AGGルーター）の間のLSPベースのLBについて、SDNコントローラー（PCECC）に尋ねることができます。これらのそれぞれには、関連する制約（BW、包含または特定のリンクまたはノードの除外、パス数、目的関数（）、馬鹿げたLSPパスの必要性など）があります。
* The PCECC could calculate multiple (say N) LSPs according to given constraints. The calculation is based on the results of the OF [RFC5541], constraints, endpoints, same or different BW, different links (in case of disjoint paths), and other constraints.
* PCECCは、与えられた制約に従って複数の（たとえばn）LSPを計算できます。計算は、[RFC5541]の結果、制約、エンドポイント、同じまたは異なるBW、異なるリンク（不利な経路の場合）、およびその他の制約の結果に基づいています。
* Depending on the given LSP PST, the PCECC will download instructions to the PCC. At this stage, it is assumed the PCECC is aware of the label space it controls and SID allocation and distribution is already done in the case of SR.
* 指定されたLSP PSTに応じて、PCECCはPCCに手順をダウンロードします。この段階では、PCECCが制御するラベル空間を認識しており、SIDの割り当てと分布はSRの場合にすでに行われています。
* The PCECC will send a PCInitiate message [RFC8281] towards the ingress AGG X router (PCC) for each of N LSPs and receive a PCRpt message [RFC8231] back from PCCs. If the PST is a PCECC-SR, the PCECC will include a SID stack as per [RFC8664]. If the PST is set to "PCECC" type, then the PCECC will assign labels along the calculated path and set up the path by sending central controller instructions in a PCEP message to each node along the path of the LSP as per [RFC9050]. Then, the PCECC will send a PCUpd message to the ingress AGG X router with information about the new LSP. AGG X (PCC) will respond with a PCRpt with LSP status.
* PCECCは、N LSPのそれぞれのIngress Agg Xルーター（PCC）にPCInitiateメッセージ[RFC8281]を送信し、PCCSからPCRPTメッセージ[RFC8231]を受け取ります。PSTがPCECC-SRの場合、PCECCには[RFC8664]に従ってSIDスタックが含まれます。PSTが「PCECC」タイプに設定されている場合、PCECCは計算されたパスに沿ってラベルを割り当て、[RFC9050]に従ってLSPのパスに沿ってPCEPメッセージの中央コントローラー命令を送信してパスをセットアップします。次に、PCECCは、新しいLSPに関する情報を使用して、Ingress Agg XルーターにPCUPDメッセージを送信します。AGG X（PCC）は、LSPステータスのPCRPTで応答します。
* AGG X as an ingress router now has N LSPs towards AGG N and AGG N-1, which are available for installation to the router's forwarding table and for LB traffic between them. Traffic distribution between those LSPs depends on the particular realization of the hash function on that router.
* IngressルーターとしてのAGG Xは、Agg NおよびAgg N-1に向かってn LSPを搭載しています。これは、ルーターの転送テーブルへの取り付けとそれらの間のLBトラフィックに使用できます。これらのLSP間のトラフィック分布は、そのルーター上のハッシュ関数の特定の実現に依存します。
* Since the PCECC is aware of the Traffic Engineering Database (TED) (TE state) and the LSP Database (LSP-DB), it can manage and prevent possible over-subscriptions and limit the number of available load-balance states. Via a PCECC mechanism, the control can take quick actions into the network by directly provisioning the central control instructions.
* PCECCはトラフィックエンジニアリングデータベース（TED）（TEステート）とLSPデータベース（LSP-DB）を認識しているため、可能な過剰なサブスクリプションを管理および防止し、利用可能な負荷分散状態の数を制限できます。PCECCメカニズムを介して、コントロールは中央の制御命令を直接プロビジョニングすることにより、ネットワークに迅速なアクションを実行できます。
There are various signalling options for establishing Inter-AS TE LSPs: contiguous TE LSPs [RFC5151], stitched TE LSPs [RFC5150], and nested TE LSPs [RFC4206].
LSPSを確立するためのさまざまなシグナル伝達オプションがあります：連続したTe LSP [RFC5151]、ステッチされたTe LSP [RFC5150]、およびネストされたTe LSP [RFC4206]。
The requirements for PCE-based Inter-AS setup [RFC5376] describe the approach and PCEP functionality that is needed for establishing Inter-AS TE LSPs.
PCEベースのASセットアップ[RFC5376]の要件は、テープ間の確立に必要なアプローチとPCEP機能を説明しています。
[RFC5376] also gives an Inter-AS and Intra-AS PCE Reference Model (as shown in Figure 7) that is provided below in shortened form for the sake of simplicity.
[RFC5376]は、単純さのために以下に短縮された形式で提供されるPCE Inter-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-Asの参照モデル（図7を参照）も提供します。
Inter-AS Inter-AS
PCC <-->PCE1<--------->PCE2
:: :: ::
:: :: ::
R1----ASBR1====ASBR3---R3---ASBR5
| AS1 | | PCC |
| | | AS2 |
R2----ASBR2====ASBR4---R4---ASBR6
:: ::
:: ::
Intra-AS Intra-AS
PCE3 PCE4
Figure 7: Shortened Form of the Inter-AS and Intra-AS PCE Reference Model
図7：AS間およびAS Intra-AS PCEリファレンスモデルの短縮形式
The PCECC belonging to the different domains can cooperate to set up Inter-AS TE LSPs. The stateful Hierarchical PCE (H-PCE) mechanism [RFC8751] could also be used to establish a per-domain PCECC LSP first. These could be stitched together to form an Inter-AS TE LSP as described in [PCE-INTERDOMAIN].
さまざまなドメインに属するPCECCは、協力してlspsとしてのセットアップを行うことができます。ステートフルな階層PCE（H-PCE）メカニズム[RFC8751]を使用して、最初にドメインごとのPCECC LSPを確立することもできます。これらを一緒に縫い合わせて、[PCE-interdomain]に記載されているように、lspとしています。
For the sake of simplicity, here the focus is on a simplified Inter-AS case when both AS1 and AS2 belong to the same service provider administration. In that case, Inter-AS and Intra-AS PCEs could be combined in one single PCE if such combined PCE performance is enough to handle the load. The PCE will require interfaces (PCEP and BGP-LS) to both domains. PCECC redundancy mechanisms are described in [RFC8283]. Thus, routers (PCCs) in AS1 and AS2 can send PCEP messages towards the same PCECC. In Figure 8, the PCECC maintains a BGP-LS session with Route Reflectors (RRs) in each AS. This allows the RRs to redistribute routes to other BGP routers (clients) without requiring a full mesh. The RRs act as a BGP-LS Propagator, and the PCECC acts as a BGP-LS Consumer [RFC9552].
簡単にするために、ここでは、AS1とAS2の両方が同じサービスプロバイダー管理に属している場合、単純化されたasの場合に焦点を当てています。その場合、そのような組み合わせたPCEパフォーマンスが負荷を処理するのに十分である場合、AS間およびAS Intra-AS PCEを1つのPCEで結合することができます。PCEには、両方のドメインにインターフェイス（PCEPおよびBGP-LS）が必要です。PCECC冗長性メカニズムは[RFC8283]で説明されています。したがって、AS1およびAS2のルーター（PCC）は、同じPCECCにPCEPメッセージを送信できます。図8では、PCECCはそれぞれのASにルートリフレクター（RRS）を使用したBGP-LSセッションを維持しています。これにより、RRSは完全なメッシュを必要とせずに他のBGPルーター（クライアント）にルートを再分配できます。RRSはBGP-LSプロパゲーターとして機能し、PCECCはBGP-LS消費者[RFC9552]として機能します。
+----BGP-LS------+ +------BGP-LS-----+
| | | |
+-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+
+-:------|----::-:-+ +--::-:-|-------:---+
| : | :: : | | :: : | : |
| : RR1 :: : | | :: : RR2 : |
| v v: : | LSP1 | :: v v |
| R1---------ASBR1=======================ASBR3--------R3 |
| | v : | | :v | |
| +----------ASBR2=======================ASBR4---------+ |
| | Region 1 : | | : Region 1 | |
|----------------:-| |--:-------------|--|
| | v | LSP2 | v | |
| +----------ASBR5=======================ASBR6---------+ |
| Region 2 | | Region 2 |
+------------------+ <--------------> +-------------------+
MPLS Domain 1 Inter-AS MPLS Domain 2
<=======AS1=======> <========AS2=======>
Figure 8: Particular Case of Inter-AS PCE
図8：PCE間の特定のケース
In the case of the PCECC Inter-AS TE scenario (as shown in Figure 8), where the service provider controls both domains (AS1 and AS2), each of them has its own IGP and MPLS transport. There is a need to set up Inter-AS LSPs for transporting different services on top of them (such as Voice, L3VPN, etc.). Inter-AS links with different capacities exist in several regions. The task is not only to provision those Inter-AS LSPs with given constraints but also to calculate the path and pre-setup the backup Inter-AS LSPs that will be used if the primary LSP fails.
PCECC Inter-AS TEシナリオ（図8に示すように）の場合、サービスプロバイダーは両方のドメイン（AS1とAS2）を制御します。それぞれが独自のIGPおよびMPLSトランスポートを備えています。それらの上にさまざまなサービスを輸送するために、LSP間（音声、L3VPNなど）を設定する必要があります。さまざまな容量を持つリンクをいくつかの地域に存在します。タスクは、それらのLSPを指定された制約で提供するだけでなく、パスを計算して、プライマリLSPが故障した場合に使用されるLSPとしてのバックアップ間局を事前に設定することでもあります。
As per Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it is the primary Inter-AS LSP. LSP2 from R1 to R3 that goes via ASBR5 and ASBR6 is the backup one. In addition, there could also be a bypass LSP setup to protect against ASBR or Inter-AS link failures.
図8によると、R1からR3へのLSP1はASBR1およびASBR3を介して進み、LSPとしての主要なものです。R1からR3へのLSP2はASBR5を介してasbr6を介してバックアップされています。さらに、ASBRまたはAS間のリンク障害から保護するためのバイパスLSPセットアップもある可能性があります。
After the addition of PCECC functionality to the PCE (SDN controller), the PCECC-based Inter-AS TE model should follow the PCECC use case for TE LSP including the requirements described in [RFC5376] with the following details:
PCE（SDNコントローラー）にPCECC機能を追加した後、PCECCベースのTE TEモデルは、[RFC5376]に記載されている要件を含むTE LSPのPCECCユースケースに次の詳細を含めて従う必要があります。
* Since the PCECC needs to know the topology of both domains AS1 and AS2, the PCECC can utilize the BGP-LS peering with BGP routers (or RRs) in both domains.
* PCECCは両方のドメインAS1とAS2のトポロジーを知る必要があるため、PCECCは両方のドメインでBGPルーター（またはRRS）を使用してBGP-LSピアリングを利用できます。
* The PCECC needs to establish PCEP connectivity with all routers in both domains (see also Section 4 of [RFC5376]).
* PCECCは、両方のドメインのすべてのルーターでPCEP接続を確立する必要があります（[RFC5376]のセクション4も参照）。
* After the operator's application or service orchestrator creates a request for tunnel creation of a specific service, the PCECC will receive that request via the Northbound Interface (NBI) (note that the NBI type is implementation-dependent; it could be NETCONF/ YANG, REST, etc.). Then, the PCECC will calculate the optimal path based on the OF and given constraints (i.e., PST, BW, etc.). These constraints include those from [RFC5376], such as priority, AS sequence, preferred ASBR, disjoint paths, and protection type. In this step, we will have two paths: "R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3".
* オペレーターのアプリケーションまたはサービスオーケストレーターが特定のサービスのトンネル作成のリクエストを作成した後、PCECCはノースバウンドインターフェイス（NBI）を介してそのリクエストを受け取ります（NBIタイプは実装依存であることに注意してください。、など）。次に、PCECCは、ofおよび与えられた制約に基づいて最適なパスを計算します（つまり、PST、BWなど）。これらの制約には、優先度など、[RFC5376]の[RFC5376]の制約、優先ASBR、馬鹿げたパス、保護タイプなどが含まれます。このステップでは、「R1-ASBR1-ASBR3-R3、R1-ASBR5-ASBR6-R3」という2つのパスがあります。
* The PCECC will use central control download instructions to the PCC based on the PST. At this stage, it is assumed the PCECC is aware of the label space it controls, and in the case of SR, the SID allocation and distribution is already done.
* PCECCは、PSTに基づいてPCCにCentral Controlのダウンロード命令を使用します。この段階では、PCECCが制御するラベル空間を認識していると想定されており、SRの場合、SIDの割り当てと分布はすでに行われています。
* The PCECC will send a PCInitiate message [RFC8281] towards the ingress router R1 (PCC) in AS1 and receive the PCRpt message [RFC8231] back from it.
* PCECCは、AS1のIngressルーターR1（PCC）にPCInitiateメッセージ[RFC8281]を送信し、PCRPTメッセージ[RFC8231]を受け取ります。
- If the PST is SR-MPLS, the PCECC will include the SID stack as per [RFC8664]. Optionally, a BSID or BGP Peering-SID [RFC9087] can also be included on the AS boundary. The backup SID stack can be installed at ingress R1, but more importantly, each node along the SR path could also do the local protection just based on the top segment.
- PSTがSR-MPLSの場合、PCECCには[RFC8664]に従ってSIDスタックが含まれます。オプションで、BSIDまたはBGP Peering-SID [RFC9087]もAS境界に含めることができます。バックアップSIDスタックはIngress R1にインストールできますが、さらに重要なことに、SRパスに沿った各ノードは、上部セグメントだけに基づいてローカル保護を行うこともできます。
- If the PST is a PCECC, the PCECC will assign labels along the calculated paths ("R1-ASBR1-ASBR3-R3", "R1-ASBR5-ASBR6-R3") and sets up the path by sending central controller instructions in a PCEP message to each node along the path of the LSPs as per [RFC9050]. After these steps, the PCECC will send a PCUpd message to the ingress R1 router with information about new LSPs and R1 will respond by a PCRpt with LSP(s) status.
- PSTがPCECCの場合、PCECCは計算されたパスに沿ってラベルを割り当てます（ "R1-ASBR1-ASBR3-R3"、 "R1-ASBR5-ASBR6-R3"）。[RFC9050]に従って、LSPのパスに沿った各ノードへのメッセージ。これらの手順の後、PCECCは新しいLSPに関する情報を使用してPCUPDメッセージをIngress R1ルーターに送信し、R1はLSP（S）ステータスのPCRPTで応答します。
* After that step, R1 now has primary and backup TEs (LSP1 and LSP2) towards R3. It is up to the router implementation for how to switchover to backup LSP2 if LSP1 fails.
* そのステップの後、R1にはR3に向かってプライマリおよびバックアップTE（LSP1およびLSP2）があります。LSP1が失敗した場合、LSP2をバックアップする方法のルーターの実装次第です。
The multicast LSPs can be set up via the RSVP-TE P2MP or Multipoint LDP (mLDP) protocols. The setup of these LSPs may require manual configurations and complex signalling when the protection is considered. By using the PCECC solution, the multicast LSP can be computed and set up through a centralized controller that has the full picture of the topology and BW usage for each link. It not only reduces the complex configurations comparing the distributed RSVP-TE P2MP or mLDP signalling, but also it can compute the disjoint primary path and secondary P2MP path efficiently.
マルチキャストLSPは、RSVP-TE P2MPまたはマルチポイントLDP（MLDP）プロトコルを介してセットアップできます。これらのLSPのセットアップでは、保護を考慮した場合、手動構成と複雑なシグナル伝達が必要になる場合があります。PCECCソリューションを使用することにより、マルチキャストLSPを計算して、各リンクのトポロジとBW使用の全体像を備えた集中コントローラーを介してセットアップできます。分散型RSVP-TE P2MPまたはMLDPシグナルを比較する複雑な構成を減らすだけでなく、馬鹿げたプライマリパスとセカンダリP2MPパスを効率的に計算することもできます。
It is assumed the PCECC is aware of the label space it controls for all nodes and makes allocations accordingly.
PCECCは、すべてのノードに対して制御するラベルスペースを認識しており、それに応じて割り当てを行うと想定されています。
+----------+
| R1 | Root Node of the multicast LSP
+----------+
|9000 (link0)
+----------+
Transit Node | R2 |
branch +----------+
* | * *
9001* | * *9002
link1 * | * *link2
+-----------+ | * +-----------+
| R4 | | * | R5 | Transit Nodes
+-----------+ | * +-----------+
* | * * +
9003* | * * +9004
link3 * | * * +link4
+-----------+ +-----------+
| R3 | | R6 | Leaf Node
+-----------+ +-----------+
9005| link5
+-----------+
| R8 | Leaf Node
+-----------+
Figure 9: Using a PCECC for the Setup of P2MP/MP2MP LSPs
図9：P2MP/MP2MP LSPのセットアップにPCECCを使用する
The P2MP examples (based on Figure 9) are explained here, where R1 is the root and the routers R8 and R6 are the leaves.
P2MPの例（図9に基づく）はここで説明されています。ここで、R1はルートであり、ルーターR8とR6は葉です。
* Based on the P2MP path computation request/delegation or PCE initiation, the PCECC receives the request with constraints and optimization criteria.
* P2MPパス計算要求/委任またはPCEの開始に基づいて、PCECCは制約と最適化基準でリクエストを受信します。
* The PCECC will calculate the optimal P2MP path according to given constraints (i.e., BW).
* PCECCは、指定された制約（つまり、BW）に従って最適なP2MPパスを計算します。
* The PCECC will provision each node along the path and assign incoming and outgoing labels from R1 to {R6, R8} with the path as "R1-link0-R2-link2-R5-link4-R6" and "R1-link0-R2-link1-R4-link3-R3-link5-R8":
* PCECCは、パスに沿って各ノードをプロビジョニングし、R1から{R6、R8}に着信ラベルと発信ラベルを「R1-Link0-R2-Link2-Link4-R6」および「R1-Link0-R2-を割り当てます。Link1-R4-Link3-R3-Link5-R8 "：
- R1: Outgoing label 9000 on link0
- R1：Link0の発信ラベル9000
- R2: Incoming label 9000 on link0
- R2：Link0の着信ラベル9000
- R2: Outgoing label 9001 on link1 (*)
- R2：link1の発信ラベル9001（*）
- R2: Outgoing label 9002 on link2 (*)
- R2：link2の発信ラベル9002（*）
- R5: Incoming label 9002 on link2
- R5：リンク2の着信ラベル9002
- R5: Outgoing label 9004 on link4
- R5：リンク4の発信ラベル9004
- R6: Incoming label 9004 on link4
- R6：リンク4の着信ラベル9004
- R4: Incoming label 9001 on link1
- R4：リンク1の着信ラベル9001
- R4: Outgoing label 9003 on link3
- R4：リンク3の発信ラベル9003
- R3: Incoming label 9003 on link3
- R3：リンク3の着信ラベル9003
- R3: Outgoing label 9005 on link5
- R3：リンク5の発信ラベル9005
- R8: Incoming label 9005 on link5
- R8：リンク5の着信ラベル9005
* This can also be represented as: {R1, 6000}, {6000, R2, {9001, 9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3, 9005}, {9004, R6}, {9005, R8}. The main difference (*) is in the branch node instruction at R2, where two copies of a packet are sent towards R4 and R5 with 9001 and 9002 labels, respectively.
* これは、{r1、6000}、{6000、r2、{9001、9002}}、{9001、r4、9003}、{9002、r5、9004} {9003、r3、9005}、{9004、r6}、{9005、r8}。主な違い（*）は、R2のブランチノード命令で、パケットの2つのコピーがそれぞれ9001と9002のラベルでR4とR5に送られます。
The packet forwarding involves the following:
パケット転送には次のものが含まれます。
Step 1. R1 sends a packet to R2 simply by pushing the label of 9000 to the packet.
ステップ1。R19000のラベルをパケットに押し込むだけで、パケットをR2に送信します。
Step 2. When R2 receives the packet with label 9000, it will forward it to R4 by swapping label 9000 to 9001. At the same time, it will replicate the packet and swap the label 9000 to 9002 and forward it to R5.
ステップ2。R2がラベル9000でパケットを受信すると、ラベル9000から9001を交換してR4に転送します。同時に、パケットを複製し、ラベル9000から9002に交換し、R5に転送します。
Step 3. When R4 receives the packet with label 9001, it will forward it to R3 by swapping 9001 to 9003. When R5 receives the packet with the label 9002, it will forward it to R6 by swapping 9002 to 9004.
ステップ3。R4がラベル9001でパケットを受信すると、9001を交換してR3に転送します。R5がラベル9002でパケットを受信すると、9002を交換してR6に転送します。
Step 4. When R3 receives the packet with label 9003, it will forward it to R8 by swapping it to 9005. When R5 receives the packet with label 9002, it will be swapped to 9004 and sent to R6.
ステップ4。R3がラベル9003でパケットを受信すると、R8を9005に交換してR8に転送します。R5がラベル9002でパケットを受信すると、9004に交換され、R6に送信されます。
Step 5. When R8 receives the packet with label 9005, it will pop the label. When R6 receives the packet with label 9004, it will pop the label.
ステップ5。R8がラベル9005でパケットを受信すると、ラベルがポップされます。R6がラベル9004でパケットを受信すると、ラベルがポップされます。
This section describes the end-to-end managed path protection service as well as the local protection with the operation management in the PCECC network for the P2MP/MP2MP LSP.
このセクションでは、エンドツーエンドのマネージドパス保護サービスと、P2MP/MP2MP LSPのPCECCネットワークの操作管理を伴うローカル保護について説明します。
An end-to-end protection principle can be applied for computing backup P2MP or MP2MP LSPs. During the computation of the primary multicast trees, the PCECC could also take the computation of a secondary tree into consideration. A PCECC could compute the primary and backup P2MP (or MP2MP) LSPs together or sequentially.
バックアップP2MPまたはMP2MP LSPを計算するために、エンドツーエンドの保護原理を適用できます。プライマリマルチキャストツリーの計算中、PCECCは二次ツリーの計算を考慮に入れることもできます。PCECCは、プライマリおよびバックアップP2MP（またはMP2MP）LSPを一緒にまたは順次計算できます。
+----+ +----+
Root Node of LSP | R1 |--| R11|
+----+ +----+
/ +
10/ +20
/ +
+----------+ +-----------+
Transit Node | R2 | | R3 |
+----------+ +-----------+
| \ + +
| \ + +
10| 10\ +20 20+
| \ + +
| \ +
| + \ +
+-----------+ +-----------+ Leaf Nodes
| R4 | | R5 | (Downstream LSR)
+-----------+ +-----------+
Figure 10: PCECC for the End-to-End Protection of P2MP/MP2MP LSPs
図10：P2MP/MP2MP LSPのエンドツーエンド保護のためのPCECC
In Figure 10, when the PCECC sets up the primary multicast tree from the root node R1 to the leaves, which is R1->R2->{R4, R5}, it can set up the backup tree at the same time, which is R1->R11->R3->{R4, R5}. Both of them (the primary forwarding tree and secondary forwarding tree) will be downloaded to each router along the primary path and the secondary path. The traffic will be forwarded through the R1->R2->{R4, R5} path normally, but when a node in the primary tree fails (say R2), the root node R1 will switch the flow to the backup tree, which is R1->R11->R3->{R4, R5}. By using the PCECC, path computation, label downloading, and finally forwarding can be done without the complex signalling used in the P2MP RSVP-TE or mLDP.
図10では、PCECCがルートノードR1から葉、つまりR1-> {r4、R5}のプライマリマルチキャストツリーをセットアップすると、バックアップツリーを同時にセットアップできます。r1-> r11-> r3-> {r4、r5}。両方（主要な転送ツリーとセカンダリ転送ツリー）は、プライマリパスとセカンダリパスに沿って各ルーターにダウンロードされます。トラフィックはR1-> R2-> {r4、R5}パスを介して正常に転送されますが、プライマリツリーのノードが失敗すると（たとえばR2）、ルートノードR1はフローをバックアップツリーに切り替えます。r1-> r11-> r3-> {r4、r5}。PCECC、PATH計算、ラベルのダウンロード、および最終的に転送を使用することにより、P2MP RSVP-TEまたはMLDPで使用される複雑なシグナルを使用せずに実行できます。
In this section, we describe the local protection service in the PCECC network for the P2MP/MP2MP LSP.
このセクションでは、P2MP/MP2MP LSPのPCECCネットワークのローカル保護サービスについて説明します。
While the PCECC sets up the primary multicast tree, it can also build the backup LSP between the Point of Local Repair (PLR), protected node, and Merge Points (MPs) (the downstream nodes of the protected node). In the cases where the amount of downstream nodes is huge, this mechanism can avoid unnecessary packet duplication on the PLR and protect the network from traffic congestion risks.
PCECCはプライマリマルチキャストツリーをセットアップしますが、ローカル修理ポイント（PLR）、保護ノード、マージポイント（MPS）（保護ノードの下流ノード）の間にバックアップLSPを構築することもできます。ダウンストリームノードの量が膨大な場合、このメカニズムはPLRの不必要なパケットの複製を回避し、交通渋滞のリスクからネットワークを保護することができます。
+------------+
| R1 | Root Node
+------------+
.
.
.
+------------+ Point of Local Repair /
| R10 | Switchover Point
+------------+ (Upstream LSR)
/ +
10/ +20
/ +
+----------+ +-----------+
Protected Node | R20 | | R30 |
+----------+ +-----------+
| \ + +
| \ + +
10| 10\ +20 20+
| \ + +
| \ +
| + \ +
+-----------+ +-----------+ Merge Point
| R40 | | R50 | (Downstream LSR)
+-----------+ +-----------+
. .
. .
Figure 11: PCECC for the Local Protection of P2MP/MP2MP LSPs
図11：P2MP/MP2MP LSPの局所保護のためのPCECC
In Figure 11, when the PCECC sets up the primary multicast path around the PLR node R10 to protect node R20, which is R10->R20->{R40, R50}, it can set up the backup path R10->R30->{R40, R50} at the same time. Both the primary forwarding path and the secondary bypass forwarding path will be downloaded to each router along the primary path and the secondary bypass path. The traffic will be forwarded through the R10->R20->{R40, R50} path normally, and when there is a node failure for node R20, the PLR node R10 will switch the flow to the backup path, which is R10->R30->{R40, R50}. By using the PCECC, path computation, label downloading, and finally forwarding can be done without the complex signalling used in the P2MP RSVP-TE or mLDP.
図11では、PCECCがPLRノードR10の周りのプライマリマルチキャストパスを設定して、r10-> r20-> {r40、r50}です。バックアップパスr10-> r30->{r40、r50}同時に。一次転送パスとセカンダリバイパス転送パスの両方が、プライマリパスとセカンダリバイパスパスに沿った各ルーターにダウンロードされます。トラフィックはR10-> R20-> {R40、R50}パスを介して正常に転送され、ノードR20にノード障害がある場合、PLRノードR10はフローをバックアップパスに切り替えます。r30-> {r40、r50}。PCECC、PATH計算、ラベルのダウンロード、および最終的に転送を使用することにより、P2MP RSVP-TEまたはMLDPで使用される複雑なシグナルを使用せずに実行できます。
As described in [RFC8283], traffic classification is an important part of traffic engineering. It is the process of looking into a packet to determine how it should be treated while it is forwarded through the network. It applies in many scenarios, including the following:
[RFC8283]で説明されているように、トラフィック分類はトラフィックエンジニアリングの重要な部分です。これは、ネットワークを介して転送されたときにどのように処理するかを決定するためにパケットを調べるプロセスです。以下を含む多くのシナリオに適用されます。
* MPLS traffic engineering (where it determines what traffic is forwarded into which LSPs),
* MPLSトラフィックエンジニアリング（LSPにどのトラフィックが転送されるかを決定する場所）、
* SR (where it is used to select which set of forwarding instructions (SIDs) to add to a packet), and
* SR（パケットに追加する転送命令のセット（SIDS）を選択するために使用される場合）、および
* SFC (where it indicates how a packet should be forwarded across which service function path).
* SFC（ここで、パケットがどのサービス機能パスを越えて転送するかを示します）。
In conjunction with traffic engineering, traffic classification is an important enabler for LB. Traffic classification is closely linked to the computational elements of planning for the network functions because it determines how traffic is balanced and distributed through the network. Therefore, selecting what traffic classification mechanism should be performed by a router is an important part of the work done by a PCECC.
交通工学と併せて、トラフィック分類はLBにとって重要なイネーブラーです。トラフィックの分類は、ネットワークを介してトラフィックのバランスと分布の方法を決定するため、ネットワーク機能の計画の計算要素に密接にリンクしています。したがって、ルーターによって実行されるトラフィック分類メカニズムを選択することは、PCECCによって行われた作業の重要な部分です。
The description of traffic flows by the combination of multiple Flow Specification components and their dissemination as traffic Flow Specifications is described for BGP in [RFC8955]. When a PCECC is used to initiate tunnels (such as TE LSPs or SR paths) using PCEP, it is important that the headend of the tunnels understands what traffic to place on each tunnel. [RFC9168] specifies a set of extensions to PCEP to support the dissemination of Flow Specification components where the instructions are passed from the PCECC to the routers using PCEP.
複数のフロー仕様コンポーネントの組み合わせと交通流の仕様としての普及によるトラフィックフローの説明は、[RFC8955]のBGPについて説明されています。PCEPを使用してPCECCを使用してトンネル（TE LSPやSRパスなど）を開始する場合、トンネルのヘッドエンドが各トンネルに配置するトラフィックを理解することが重要です。[RFC9168]は、PCEPを使用してPCECCからルーターに命令が渡されるフロー仕様コンポーネントの普及をサポートするために、PCEPの拡張セットを指定します。
Along with traffic classification, there are a few more questions about the tunnels set up by the PCECC that need to be considered:
トラフィック分類に加えて、PCECCによって設定されたトンネルについて、考慮する必要があるトンネルについてさらにいくつかの質問があります。
* how to use it,
* それを使用する方法、
* whether it is a virtual link,
* 仮想リンクかどうか、
* whether to advertise it in the IGP as a virtual link, and
* IGPで仮想リンクとして宣伝するかどうか、そして
* what bits of this information to signal to the tail end.
* この情報のビットは、テールエンドに合図します。
These are out of the scope of this document.
これらはこのドキュメントの範囲外です。
Service Function Chaining (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. 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. Planning an SFC network requires LB between service function nodes and traffic engineering across the network that connects them. As per [RFC8283], these are operations that can be performed by a PCECC, and that controller can use PCEP to program the network and install the service function chains and any required tunnels.
サービス関数チェーン（SFC）は[RFC7665]で説明されています。これは、トラフィックで特定の目的の機能を実行できる特定のハードウェアデバイスまたは仮想マシン（サービス関数ノードとして知られている）を通過するように、ネットワーク内のトラフィックを向けるプロセスです。実行される関数のセットとそれらが実行される順序は、サービス関数チェーンとして知られています。チェーンは、サービス関数パス（SFP）を導出するためにサービス機能を実行する場所で強化されます。各パケットは特定のSFPに属するものとしてマークされており、そのマーキングにより、各連続するサービス機能ノードが実行する機能と、次にパケットを送信するサービス機能ノードを知ることができます。SFCネットワークを操作するには、パケットマークを理解するようにサービス関数ノードを構成する必要があり、エッジノードにネットワークに入るパケットをマークする方法を指定する必要があります。さらに、トラフィックを運ぶためにサービス関数ノード間にトンネルを確立する必要がある場合があります。SFCネットワークの計画には、サービス機能ノードとそれらを接続するネットワーク全体のトラフィックエンジニアリングの間のLBが必要です。[RFC8283]によると、これらはPCECCで実行できる操作であり、コントローラーはPCEPを使用してネットワークをプログラムし、サービス関数チェーンと必要なトンネルをインストールできます。
A possible mechanism could add support for SFC-based central control instructions. The PCECC will be able to instruct each Service Function Forwarder (SFF) along the SFP.
考えられるメカニズムは、SFCベースの中央制御命令のサポートを追加できます。PCECCは、SFPに沿って各Service Function Forwarder（SFF）を指示することができます。
* Service Path Identifier (SPI): Uniquely identifies an SFP.
* サービスパス識別子（SPI）：SFPを一意に識別します。
* Service Index (SI): Provides location within the SFP.
* サービスインデックス（SI）：SFP内の場所を提供します。
* Provide SFC Proxy handling instruction.
* SFCプロキシ処理命令を提供します。
The PCECC can play the role of setting the traffic classification rules (as per Section 3.7) at the classifier to impose the Network Service Header (NSH) [RFC8300]. It can also download the forwarding instructions to each SFF along the way so that they could process the NSH and forward accordingly. This includes instructions for the service classifier that handles the context header, metadata, etc. This metadata/context is shared amongst SFs and classifiers, between SFs, and between external systems (such as a PCECC) and SFs. As described in [RFC7665], the SFC encapsulation enables the sharing of metadata/context information along the SFP.
PCECCは、ネットワークサービスヘッダー（NSH）[RFC8300]を課すために、分類器にトラフィック分類ルール（セクション3.7に従って）を設定する役割を果たすことができます。また、途中で各SFFへの転送命令をダウンロードして、NSHを処理してそれに応じて転送できるようにすることもできます。これには、コンテキストヘッダー、メタデータなどを処理するサービス分類器の指示が含まれます。このメタデータ/コンテキストは、SFSおよび分類器間、SFS間、および外部システム（PCECCなど）およびSFS間で共有されます。[RFC7665]で説明されているように、SFCカプセル化により、SFPに沿ったメタデータ/コンテキスト情報の共有が可能になります。
It is also possible to support SFC with SR in conjunction with or without an NSH such as described in [RFC9491] and [SR-SERVICE]. PCECC techniques can also be used for service-function-related segments and SR service policies.
また、[RFC9491]および[SR-Service]に記載されているようなNSHの有無にかかわらず、SRをSRでサポートすることも可能です。PCECCテクニックは、サービス機能関連のセグメントやSRサービスポリシーにも使用できます。
[RFC8735] describes the scenarios and simulation results for the "Centralized Control Dynamic Routing (CCDR)" solution, which integrates the advantage of using distributed protocols (IGP/BGP) and the power of a centralized control technology (PCE/SDN), providing traffic engineering for native IP networks. [RFC8821] defines the framework for CCDR traffic engineering within a native IP network, using multiple BGP sessions and a PCE as the centralized controller. It requires the PCECC to send the instructions to the PCCs to build multiple BGP sessions, distribute different prefixes on the established BGP sessions, and assign the different paths to the BGP next hops. The PCEP is used to transfer the key parameters between the PCE and the underlying network devices (PCC) using the PCECC technique. The central control instructions from the PCECC to PCC will identify which prefix should be advertised on which BGP session. There are PCEP extensions defined in [PCEP-NATIVE] for it.
[RFC8735]は、分布プロトコル（IGP/BGP）を使用する利点と集中制御技術（PCE/SDN）の能力を統合し、提供し、提供する、「集中制御動的ルーティング（CCDR）」ソリューションのシナリオとシミュレーション結果を説明します。ネイティブIPネットワークのトラフィックエンジニアリング。[RFC8821]は、複数のBGPセッションとPCEを中央コントローラーとして使用して、ネイティブIPネットワーク内のCCDRトラフィックエンジニアリングのフレームワークを定義します。PCECCは、複数のBGPセッションを構築し、確立されたBGPセッションで異なるプレフィックスを配布し、BGPの次のホップに異なるパスを割り当てるために、PCCSに指示を送信する必要があります。PCEPは、PCECC技術を使用して、PCEと基礎となるネットワークデバイス（PCC）の間に重要なパラメーターを転送するために使用されます。PCECCからPCCへの中央制御命令は、どのBGPセッションでどのプレフィックスを宣伝するかを特定します。[pcep-native]で定義されているPCEP拡張機能があります。
+------+
+----------+ PCECC+-------+
| +------+ |
| |
PCEP | BGP Session 1(lo11/lo21)| PCEP
+-------------------------+
| |
| BGP Session 2(lo12/lo22)|
+-------------------------+
PF12 | | PF22
PF11 | | PF21
+---+ +-----+-----+ +-----+-----+ +---+
|SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+-----------+SW2|
+---+ | R1 +-------------+ R2 | +---+
+-----------+ +-----------+
Figure 12: PCECC for Native IP
図12：ネイティブIPのPCECC
In the case as shown in Figure 12, the PCECC will instruct both R1 and R2 how to form BGP sessions with each other via PCEP and which IP prefixes need to be advertised via which BGP session.
図12に示すように、PCECCはR1とR2の両方に、PCEPを介してBGPセッションを互いに形成する方法と、どのBGPセッションを介して宣伝する必要があるかを指示します。
Bit Index Explicit Replication (BIER) [RFC8279] defines an architecture where all intended multicast receivers are encoded as a BitMask in the multicast packet header within different encapsulations. A router that receives such a packet will forward that packet based on the bit position in the packet header towards the receiver(s) following a precomputed tree for each of the bits in the packet. Each receiver is represented by a unique bit in the BitMask.
ビットインデックス明示的複製（BIER）[RFC8279]は、さまざまなカプセル内のマルチキャストパケットヘッダーのビットマスクとしてエンコードされるすべてのマルチキャストレシーバーがエンコードされるアーキテクチャを定義します。このようなパケットを受信するルーターは、パケットヘッダー内のビット位置に基づいてパケットを転送し、パケット内の各ビットの事前計算ツリーに続いてレシーバーに向かって進みます。各レシーバーは、ビットマスクのユニークなビットで表されます。
BIER-TE [RFC9262] shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BIER-TE paths can be derived from a PCE and used at the ingress (a possible mechanism is described in [PCEP-BIER]).
Bier-TE [RFC9262]は、Bierとアーキテクチャとパケット形式を共有しています。パケットヘッダーのビットストリングに基づいて、ビアテをフォワードして再現しますが、ビアテパケットのビットストリングのすべてのビットポジションは、1つ以上の隣接を示します。Bier-TEパスはPCEから導出され、イングレスで使用できます（可能なメカニズムは[PCEP-Bier]で説明されています）。
The PCECC mechanism could be used for the allocation of bits for the BIER router for BIER as well as for the adjacencies for BIER-TE. PCECC-based controllers can use PCEP to instruct the BIER-capable routers on the meaning of the bits as well as other fields needed for BIER encapsulation. The PCECC could be used to program the BIER router with various parameters used in the BIER encapsulation (such as BIER sub-domain-id, BFR-id, etc.) for both node and adjacency.
PCECCメカニズムは、ビアーのビアルーターのビットの割り当てと、ビアテの隣接に使用できます。PCECCベースのコントローラーは、PCEPを使用して、ビットの意味とビアカプセル化に必要な他のフィールドについて、ビア対応ルーターに指示することができます。PCECCを使用して、ノードと隣接の両方について、Bierカプセル化（Bier Sub-Domain-ID、BFR-IDなど）で使用されるさまざまなパラメーターを使用してBierルーターをプログラムできます。
A possible way to use the PCECC and PCEP extension is described in [PCECC-BIER].
PCECCおよびPCEP拡張機能を使用する可能性のある方法は、[PCECC-Bier]で説明されています。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC8283] describes how the security considerations for a PCECC are a little different from those for any other PCE system. PCECC operations rely heavily on the use and security of PCEP, so due consideration should be given to the security features discussed in [RFC5440] and the additional mechanisms described in [RFC8253]. It further lists the vulnerability of a central controller architecture, such as a central point of failure, denial of service, and a focus on interception and modification of messages sent to individual Network Elements (NEs).
[RFC8283]は、PCECCのセキュリティ上の考慮事項が他のPCEシステムのセキュリティに関する考慮事項とは少し異なる方法を説明しています。PCECCの操作は、PCEPの使用とセキュリティに大きく依存しているため、[RFC5440]で説明されているセキュリティ機能と[RFC8253]で説明されている追加のメカニズムに十分な考慮を払う必要があります。さらに、障害の中央点、サービス拒否、個々のネットワーク要素（NES）に送信されるメッセージの傍受と変更に焦点を当てるなど、中央コントローラーアーキテクチャの脆弱性をリストします。
As per [RFC9050], the use of Transport Layer Security (TLS) in PCEP is recommended, as it provides support for peer authentication, message encryption, and integrity. It further provides mechanisms for associating peer identities with different levels of access and/ or authoritativeness via an attribute in X.509 certificates or a local policy with a specific accept-list of X.509 certificates. This can be used to check the authority for the PCECC operations.
[RFC9050]によると、PCEPでの輸送層セキュリティ（TLS）の使用が推奨されます。これは、ピア認証、メッセージ暗号化、および完全性をサポートするためです。さらに、X.509証明書の属性またはX.509証明書の特定の受け入れリストを持つ属性を介して、異なるレベルのアクセスおよび/または権威性を持つピアアイデンティティを関連付けるためのメカニズムを提供します。これは、PCECC操作の権限を確認するために使用できます。
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 PCECC on the network type and services being managed.
特定のユースケース用に作成された各新しいドキュメントには、管理対象のネットワークタイプとサービスに対するPCECCの使用のセキュリティへの影響に関する考慮事項も含まれることが期待されています。
[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>.
[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>.
[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>.
[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>.
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[MAP-REDUCE]
Lee, K., Choi, T., Ganguly, A., Wolinsky, D., Boykin, P.,
and R. Figueiredo, "Parallel Processing Framework on a P2P
System Using Map and Reduce Primitives",
DOI 10.1109/IPDPS.2011.315, May 2011,
<https://leeky.me/publications/mapreduce_p2p.pdf>.
[MPLS-DC] Afanasiev, D. and D. Ginsburg, "MPLS in DC and inter-DC
networks: the unified forwarding mechanism for network
programmability at scale", March 2014,
<https://www.slideshare.net/DmitryAfanasiev1/yandex-
nag201320131031>.
[MPLS-SEAMLESS]
Leymann, N., Ed., Decraene, B., Filsfils, C.,
Konstantynowicz, M., Ed., and D. Steinberg, "Seamless MPLS
Architecture", Work in Progress, Internet-Draft, draft-
ietf-mpls-seamless-mpls-07, 28 June 2014,
<https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
seamless-mpls-07>.
[PCE-ID] Li, C., Shi, H., Ed., Wang, A., Cheng, W., and C. Zhou,
"Path Computation Element Communication Protocol (PCEP)
extension to advertise the PCE Controlled Identifier
Space", Work in Progress, Internet-Draft, draft-ietf-pce-
controlled-id-space-01, 21 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
controlled-id-space-01>.
[PCE-INTERDOMAIN]
Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
Extension for Stateful Inter-Domain Tunnels", Work in
Progress, Internet-Draft, draft-ietf-pce-stateful-
interdomain-05, 5 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
stateful-interdomain-05>.
[PCE-PROTECTION]
Barth, C. and R. Torvi, "PCEP Extensions for RSVP-TE
Local-Protection with PCE-Stateful", Work in Progress,
Internet-Draft, draft-cbrt-pce-stateful-local-protection-
01, 29 June 2018, <https://datatracker.ietf.org/doc/html/
draft-cbrt-pce-stateful-local-protection-01>.
[PCECC-BIER]
Chen, R., Zhu, C., Xu, B., Chen, H., and A. Wang, "PCEP
Procedures and Protocol Extensions for Using PCE as a
Central Controller (PCECC) of BIER", Work in Progress,
Internet-Draft, draft-chen-pce-pcep-extension-pce-
controller-bier-06, 8 July 2024,
<https://datatracker.ietf.org/doc/html/draft-chen-pce-
pcep-extension-pce-controller-bier-06>.
[PCECC-SR] Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, "PCE
Communication Protocol (PCEP) Extensions for Using PCE as
a Central Controller (PCECC) for Segment Routing (SR) MPLS
Segment Identifier (SID) Allocation and Distribution.",
Work in Progress, Internet-Draft, draft-ietf-pce-pcep-
extension-pce-controller-sr-09, 4 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-extension-pce-controller-sr-09>.
[PCECC-SRv6]
Li, Z., Peng, S., Geng, X., and M. S. Negi, "PCE
Communication Protocol (PCEP) Extensions for Using the PCE
as a Central Controller (PCECC) for Segment Routing over
IPv6 (SRv6) Segment Identifier (SID) Allocation and
Distribution.", Work in Progress, Internet-Draft, draft-
ietf-pce-pcep-extension-pce-controller-srv6-03, 18 August
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-pcep-extension-pce-controller-srv6-03>.
[PCEP-BIER]
Chen, R., Zhang, Z., Chen, H., Dhanaraj, S., Qin, F., and
A. Wang, "PCEP Extensions for Tree Engineering for Bit
Index Explicit Replication (BIER-TE)", Work in Progress,
Internet-Draft, draft-ietf-pce-bier-te-01, 10 October
2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
pce-bier-te-01>.
[PCEP-NATIVE]
Wang, A., Khasanov, B., Fang, S., Tan, R., and C. Zhu,
"Path Computation Element Communication Protocol (PCEP)
Extensions for Native IP Networks", Work in Progress,
Internet-Draft, draft-ietf-pce-pcep-extension-native-ip-
40, 10 September 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
pcep-extension-native-ip-40>.
[PCEP-POLICY]
Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
Bidgoli, "Path Computation Element Communication Protocol
(PCEP) Extensions for Segment Routing (SR) Policy
Candidate Paths", Work in Progress, Internet-Draft, draft-
ietf-pce-segment-routing-policy-cp-18, 14 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
segment-routing-policy-cp-18>.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>.
[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>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206,
DOI 10.17487/RFC4206, October 2005,
<https://www.rfc-editor.org/info/rfc4206>.
[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>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<https://www.rfc-editor.org/info/rfc4655>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,
<https://www.rfc-editor.org/info/rfc5150>.
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
Domain MPLS and GMPLS Traffic Engineering -- Resource
Reservation Protocol-Traffic Engineering (RSVP-TE)
Extensions", RFC 5151, DOI 10.17487/RFC5151, February
2008, <https://www.rfc-editor.org/info/rfc5151>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", RFC 5376,
DOI 10.17487/RFC5376, November 2008,
<https://www.rfc-editor.org/info/rfc5376>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541,
DOI 10.17487/RFC5541, June 2009,
<https://www.rfc-editor.org/info/rfc5541>.
[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>.
[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>.
[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>.
[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>.
[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
Explicit Replication (BIER)", RFC 8279,
DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R.
Shakir, "Resiliency Use Cases in Source Packet Routing in
Networking (SPRING) Networks", RFC 8355,
DOI 10.17487/RFC8355, March 2018,
<https://www.rfc-editor.org/info/rfc8355>.
[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying Path Setup Type in PCE Communication
Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
July 2018, <https://www.rfc-editor.org/info/rfc8408>.
[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "Path Computation Element Communication
Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
DOI 10.17487/RFC8664, December 2019,
<https://www.rfc-editor.org/info/rfc8664>.
[RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,
"Scenarios and Simulation Results of PCE in a Native IP
Network", RFC 8735, DOI 10.17487/RFC8735, February 2020,
<https://www.rfc-editor.org/info/rfc8735>.
[RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
"Hierarchical Stateful Path Computation Element (PCE)",
RFC 8751, DOI 10.17487/RFC8751, March 2020,
<https://www.rfc-editor.org/info/rfc8751>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8821] Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based
Traffic Engineering (TE) in Native IP Networks", RFC 8821,
DOI 10.17487/RFC8821, April 2021,
<https://www.rfc-editor.org/info/rfc8821>.
[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules",
RFC 8955, DOI 10.17487/RFC8955, December 2020,
<https://www.rfc-editor.org/info/rfc8955>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>.
[RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,
and D. Afanasiev, "Segment Routing Centralized BGP Egress
Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August
2021, <https://www.rfc-editor.org/info/rfc9087>.
[RFC9168] Dhody, D., Farrel, A., and Z. Li, "Path Computation
Element Communication Protocol (PCEP) Extension for Flow
Specification", RFC 9168, DOI 10.17487/RFC9168, January
2022, <https://www.rfc-editor.org/info/rfc9168>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree
Engineering for Bit Index Explicit Replication (BIER-TE)",
RFC 9262, DOI 10.17487/RFC9262, October 2022,
<https://www.rfc-editor.org/info/rfc9262>.
[RFC9491] Guichard, J., Ed. and J. Tantsura, Ed., "Integration of
the Network Service Header (NSH) and Segment Routing for
Service Function Chaining (SFC)", RFC 9491,
DOI 10.17487/RFC9491, November 2023,
<https://www.rfc-editor.org/info/rfc9491>.
[RFC9522] Farrel, A., Ed., "Overview and Principles of Internet
Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
January 2024, <https://www.rfc-editor.org/info/rfc9522>.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and
Traffic Engineering Information Using BGP", RFC 9552,
DOI 10.17487/RFC9552, December 2023,
<https://www.rfc-editor.org/info/rfc9552>.
[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
and Y. Zhu, "Path Computation Element Communication
Protocol (PCEP) Extensions for IPv6 Segment Routing",
RFC 9603, DOI 10.17487/RFC9603, July 2024,
<https://www.rfc-editor.org/info/rfc9603>.
[RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based
Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024,
<https://www.rfc-editor.org/info/rfc9604>.
[SR-SERVICE]
Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li,
C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W.,
and S. Salsano, "Service Programming with Segment
Routing", Work in Progress, Internet-Draft, draft-ietf-
spring-sr-service-programming-10, 23 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-10>.
This section lists some more use cases of the PCECC that were proposed by operators and discussed within the working group but are not in active development at the time of publication. They are listed here for future consideration.
このセクションでは、オペレーターによって提案され、ワーキンググループ内で議論されたが、出版時には積極的な開発にはないPCECCのいくつかの使用ケースをリストします。将来の検討のためにここにリストされています。
One of the main advantages of the PCECC solution is its backward compatibility. The PCE server can function as a proxy node of the MPLS network for all the new nodes that no longer support the signalling protocols.
PCECCソリューションの主な利点の1つは、後方互換性です。PCEサーバーは、シグナリングプロトコルをサポートしなくなったすべての新しいノードのMPLSネットワークのプロキシノードとして機能することができます。
As illustrated in the following example, the current network could migrate to a total PCECC-controlled network gradually by replacing the legacy nodes. During the migration, the legacy nodes still need to use the existing MPLS signalling protocols such as LDP and RSVP-TE, and the new nodes will set up their portion of the forwarding path through the PCECC directly. With the PCECC function as the proxy of these new nodes, MPLS signalling can populate through the network for both old and new nodes.
次の例に示されているように、現在のネットワークは、レガシーノードを置き換えることにより、PCECC制御ネットワーク全体に徐々に移行する可能性があります。移行中、レガシーノードは依然としてLDPやRSVP-TEなどの既存のMPLSシグナリングプロトコルを使用する必要があり、新しいノードはPCECCを介して転送パスの部分を直接設定します。これらの新しいノードのプロキシとしてPCECC機能を使用すると、MPLSシグナル伝達は、古いノードと新しいノードの両方でネットワークを介して入力できます。
The example described in this section is based on network configurations illustrated in Figure 13:
このセクションで説明する例は、図13に示すネットワーク構成に基づいています。
+------------------------------------------------------------------+
| PCE DOMAIN |
| +-----------------------------------------------------+ |
| | PCECC | |
| +-----------------------------------------------------+ |
| ^ ^ ^ ^ |
| | PCEP | | PCEP | |
| V V V V |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| | Node1 | | Node2 | | Node3 | | Node4 | | Node5 | |
| | |...| |...| |...| |...| | |
| | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | |
| | Node | | Node | |Enabled | |Enabled | | Enabled| |
| +--------+ +--------+ +--------+ +--------+ +--------+ |
| |
+------------------------------------------------------------------+
Figure 13: PCECC-Initiated LSP Setup in the Network Migration
図13：ネットワーク移行におけるPCECCによって開始されたLSPセットアップ
In this example, there are five nodes for the TE LSP from the headend (Node1) to the tail end (Node5), where Node4 and Node5 are centrally controlled and other nodes are legacy nodes.
この例では、ヘッドエンド（node1）からテールエンド（node5）までのte lspの5つのノードがあり、node4とnode5は中心に制御され、他のノードはレガシーノードです。
* Node1 sends a path request message for the setup of the LSP with the destination as Node5.
* node1は、LSPのセットアップのパス要求メッセージをNode5として宛先とともに送信します。
* The PCECC sends a reply message to Node1 for LSP setup with the path: (Node1, if1), (Node2, if2), (Node3, if3), (Node4, if4), Node5.
* PCECCは、パス：（node1、if1）、（node2、if2）、（node3、if3）、（node4、if4）、node5を使用して、lspセットアップに対してnode1に返信メッセージを送信します。
* Node1, Node2, and Node3 will set up the LSP to Node5 using the local labels as usual. With the help of the PCECC, Node3 could proxy the signalling.
* node1、node2、およびnode3は、通常どおりローカルラベルを使用してLSPをnode5に設定します。PCECCの助けを借りて、node3はシグナリングをプロキシできます。
* Then, the PCECC will program the out-segment of Node3, the in-segment/out-segment of Node4, and the in-segment for Node5.
* 次に、PCECCは、node3のアウトセグメント、node4のインセグメント/アウトセグメント、およびnode5のセグメントをプログラムします。
As described in [RFC8283], various network services may be offered over a network. These include protection services (including Virtual Private Network (VPN) services such as L3VPN [RFC4364] or EVPNs [RFC7432]) or pseudowires [RFC3985]. Delivering services over a network in an optimal way requires coordination in the way where network resources are allocated to support the services. A PCECC 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.
[RFC8283]で説明されているように、さまざまなネットワークサービスがネットワークを介して提供される場合があります。これらには、保護サービス（L3VPN [RFC4364]やEVPNS [RFC7432]などの仮想プライベートネットワーク（VPN）サービスを含む）またはプソイドワイヤ[RFC3985]が含まれます。ネットワーク上でサービスを最適な方法で提供するには、サービスをサポートするためにネットワークリソースが割り当てられる方法で調整が必要です。PCECCは、サービスの提供方法を計画する際に、ネットワーク全体とサービスのすべてのコンポーネントを一度に考慮することができます。その後、PCEPを使用してネットワークリソースを管理し、それらのリソース間に必要な関連付けをインストールできます。
In the case of L3VPN, VPN labels could also be assigned and distributed through PCEP among the Provider Edge (PE) router instead of using the BGP protocols.
L3VPNの場合、VPNラベルは、BGPプロトコルを使用する代わりに、プロバイダーエッジ（PE）ルーターの間でPCEPを介して割り当てて分布することもできます。
The example described in this section is based on network configurations illustrated in Figure 14:
このセクションで説明する例は、図14に示すネットワーク構成に基づいています。
+-------------------------------------------+
| PCE DOMAIN |
| +-----------------------------------+ |
| | PCECC | |
| +-----------------------------------+ |
| ^ ^ ^ |
| PWE3/L3VPN|PCEP PCEP|LSP PWE3/L3VPN|PCEP |
| V V V |
+--------+ | +--------+ +--------+ +--------+ | +--------+
| CE | | | PE1 | | Node x | | PE2 | | | CE |
| |...... | |...| |...| |.....| |
| Legacy | |if1 | PCECC |if2|PCECC |if3| PCECC |if4 | Legacy |
| Node | | | Enabled| |Enabled | |Enabled | | | Node |
+--------+ | +--------+ +--------+ +--------+ | +--------+
| |
+-------------------------------------------+
Figure 14: PCECC for L3VPN and PWE3
図14：L3VPNおよびPWE3のPCECC
In the case of PWE3, instead of using the LDP signalling protocols, the label and port pairs assigned to each pseudowire can be assigned through the PCECC among the PE routers and the corresponding forwarding entries will be distributed into each PE router through the extended PCEP and PCECC mechanism.
PWE3の場合、LDPシグナル伝達プロトコルを使用する代わりに、各擬似ワイヤに割り当てられたラベルとポートペアは、PEルーターの間でPCECCを介して割り当てることができ、対応する転送エントリは拡張されたPCEPを介して各PEルーターに配布されます。PCECCメカニズム。
[PCE-PROTECTION] claims that there is a need for the PCE to maintain and associate the local protection paths for the RSVP-TE LSP. Local protection requires the setup of a bypass at the PLR. This bypass can be PCC-initiated and delegated or PCE-initiated. In either case, the PLR needs to maintain a PCEP session with the PCE. The bypass LSPs need to be mapped to the primary LSP. This could be done locally at the PLR based on a local policy, but there is a need for a PCE to do the mapping as well to exert greater control.
[PCE保護]は、PCEがRSVP-TE LSPのローカル保護パスを維持および関連付ける必要があると主張しています。ローカル保護には、PLRでのバイパスのセットアップが必要です。このバイパスは、PCC開始および委任またはPCE開始を行うことができます。どちらの場合でも、PLRはPCEとのPCEPセッションを維持する必要があります。バイパスLSPをプライマリLSPにマッピングする必要があります。これは、ローカルポリシーに基づいてPLRでローカルに行うことができますが、PCEがマッピングを行う必要があります。
This mapping can be done via PCECC procedures where the PCE could instruct the PLR to the mapping and identify the primary LSP for which bypass should be used.
このマッピングは、PCEがPLRにマッピングを指示し、バイパスを使用する主要なLSPを識別できるPCECC手順を介して実行できます。
The MapReduce model of distributed computations in computing clusters is widely deployed. In Hadoop (https://hadoop.apache.org/) 1.0 architecture, MapReduce operations occur on big data in the Hadoop Distributed File System (HDFS), where NameNode knows about resources of the cluster and where actual data (chunks) for a particular task are located (which DataNode). Each chunk of data (64 MB or more) should have three saved copies in different DataNodes based on their proximity.
コンピューティングクラスターの分散計算のMapReduceモデルは広く展開されています。Hadoop（https://hadoop.apache.org/）1.0アーキテクチャでは、MapReduce操作はHadoop分散ファイルシステム（HDFS）のビッグデータで発生します。特定のタスクが配置されています（このデータノード）。データの各チャンク（64 MB以上）には、近接に基づいて異なるデータノードに3つの保存されたコピーが必要です。
The proximity level currently has a semi-manual allocation and is based on Rack IDs (the assumption is that closer data is better because of access speed / smaller latency).
近接レベルには現在、セミマニュアル割り当てがあり、ラックIDに基づいています（アクセス速度 /レイテンシーが小さいため、より近いデータが優れていると仮定しています）。
The JobTracker node is responsible for computation tasks and scheduling across DataNodes and also has Rack awareness. Currently, transport protocols between NameNode/JobTracker and DataNodes are based on IP unicast. It has simplicity as an advantage but has numerous drawbacks related to its flat approach.
JobTrackerノードは、DataNodes全体の計算タスクとスケジューリングを担当し、ラック認識もあります。現在、NameNode/JobTrackerとDatanodesの間の輸送プロトコルは、IPユニキャストに基づいています。それは利点としてシンプルさを持っていますが、そのフラットなアプローチに関連する多くの欠点があります。
There is a need to go beyond one data center (DC) for Hadoop cluster creation and move towards distributed clusters. In that case, one needs to handle performance and latency issues. Latency depends on the speed of light in the fiber links and on the latency introduced by intermediate devices in between. The latter is closely correlated with network device architecture and performance. The current performance of routers based on Network Processing Unit (NPU) should be enough for creating distributed Hadoop clusters with predicted latency. The performance of software-based routers (mainly Virtual Network Functions (VNFs)) with additional hardware features such as the Data Plane Development Kit (DPDK) is promising but requires additional research and testing.
Hadoopクラスターの作成には、1つのデータセンター（DC）を超えて、分散クラスターに向かって移動する必要があります。その場合、パフォーマンスとレイテンシの問題を処理する必要があります。遅延は、ファイバーリンクの光の速度と、その間の中間デバイスによって導入されたレイテンシに依存します。後者は、ネットワークデバイスのアーキテクチャとパフォーマンスと密接に相関しています。ネットワーク処理ユニット（NPU）に基づくルーターの現在のパフォーマンスは、予測された遅延を備えた分散Hadoopクラスターを作成するのに十分でなければなりません。データプレーン開発キット（DPDK）などの追加のハードウェア機能を備えたソフトウェアベースのルーター（主に仮想ネットワーク関数（VNFS））のパフォーマンスは有望ですが、追加の研究とテストが必要です。
The main question is how to create a simple but effective architecture for a distributed Hadoop cluster.
主な問題は、分散型Hadoopクラスターのシンプルだが効果的なアーキテクチャをどのように作成するかです。
There is research [MAP-REDUCE] that shows how usage of the multicast tree could improve the speed of resource or cluster members' discovery inside the cluster as well as increased redundancy in communications between cluster nodes.
マルチキャストツリーの使用がクラスター内のリソースまたはクラスターメンバーの発見の速度をどのように改善し、クラスターノード間の通信の冗長性を高めることができるかを示す研究[Map-Reduce]があります。
The conventional IP-based multicast may not be appropriate because it requires an additional control plane (IGMP, PIM) and a lot of signalling, which is not suitable for high-performance computations that are very sensitive to latency.
従来のIPベースのマルチキャストは、追加のコントロールプレーン（IGMP、PIM）と多くのシグナル伝達が必要であるため、適切ではない場合があります。
P2MP TE tunnels are more suitable as a potential solution for the creation of multicast-based communications between NameNode as the root and DataNodes as leaves inside the cluster. These P2MP tunnels could be dynamically created and turned down (with no manual intervention). Here, the PCECC comes into play with the main objective of creating an optimal topology for each particular request for MapReduce computation and creating P2MP tunnels with needed parameters such as BW and delay.
P2MP TEトンネルは、クラスター内の葉としてのルートとしてのナメノーデとデータノードの間のマルチキャストベースの通信を作成するための潜在的なソリューションとしてより適しています。これらのP2MPトンネルは、動的に作成されて倒すことができます（手動介入なし）。ここで、PCECCは、MapReduce計算の特定の要求に対して最適なトポロジを作成し、BWや遅延などの必要なパラメーターを備えたP2MPトンネルを作成するという主な目的で作用します。
This solution will require the use of MPLS label-based forwarding inside the cluster. The usage of label-based forwarding inside DC was proposed by Yandex [MPLS-DC]. Technically, it is already possible because MPLS on switches is already supported by some vendors, and MPLS also exists on Linux and Open vSwitch (OVS).
このソリューションでは、クラスター内のMPLSラベルベースの転送を使用する必要があります。DC内のラベルベースの転送の使用は、Yandex [MPLS-DC]によって提案されました。技術的には、スイッチ上のMPLSは一部のベンダーによってすでにサポートされており、MPLSはLinuxおよびOpen Vswitch（OVS）にも存在するため、すでに可能です。
A possible framework for this task is shown in Figure 15:
このタスクの可能なフレームワークを図15に示します。
+--------+
| APP |
+--------+
| NBI (REST API,...)
|
PCEP +----------+ REST API
+---------+ +---| PCECC |----------+
| Client |---|---| | |
+---------+ | +----------+ |
| | | | | |
+-----|---+ |PCEP| |
+--------+ | | | | |
| | | | | |
| REST API | | | | |
| | | | | |
+-------------+ | | | | +----------+
| Job Tracker | | | | | | NameNode |
| | | | | | | |
+-------------+ | | | | +----------+
+------------------+ | +-----------+
| | | |
|---+-----P2MP TE--+-----|-----------| |
+-----------+ +-----------+ +-----------+
| DataNode1 | | DataNode2 | | DataNodeN |
|TaskTracker| |TaskTracker| .... |TaskTracker|
+-----------+ +-----------+ +-----------+
Figure 15: Using Reliable P2MP TE-Based Multicast Delivery for Distributed Computations (MapReduce-Hadoop)
図15：分散計算に信頼できるP2MP TEベースのマルチキャスト配信の使用（MapReduce-Hadoop）
Communication between the JobTracker, NameNode, and PCECC can be done via REST API directly or via a cluster manager such as Mesos.
JobTracker、Namenode、およびPCECC間の通信は、REST APIを直接またはMESOなどのクラスターマネージャーを介して実行できます。
* Phase 1: Distributed cluster resource discovery occurs during this phase. JobTracker and NameNode should identify and find available DataNodes according to computing requests from the application (APP). NameNode should query the PCECC about available DataNodes, and NameNode may provide additional constraints to the PCECC such as topological proximity and redundancy level.
* フェーズ1：分散クラスターリソースの発見は、このフェーズで発生します。JobTrackerとNameNodeは、アプリケーション（APP）からのコンピューティング要求に従って、利用可能なデータノードを識別して見つけて見つける必要があります。NameNodeは、利用可能なデータノードについてPCECCを照会する必要があり、NameNodeはトポロジーの近接性や冗長性レベルなどのPCECCに追加の制約を提供する場合があります。
The PCECC should analyze the topology of the distributed cluster and perform a constraint-based path calculation from the client towards the most suitable NameNodes. The PCECC should reply to NameNode with the list of the most suitable DataNodes and their resource capabilities. The topology discovery mechanism for the PCECC will be added later to that framework.
PCECCは、分散クラスターのトポロジを分析し、クライアントから最も適切なナメノードへの制約ベースのパス計算を実行する必要があります。PCECCは、最も適切なデータノードとそのリソース機能のリストを使用してNamenodeに返信する必要があります。PCECCのトポロジ発見メカニズムは、後でそのフレームワークに追加されます。
* Phase 2: The PCECC should create P2MP LSPs from the client towards those DataNodes by means of PCEP messages following the previously calculated path.
* フェーズ2：PCECCは、以前に計算されたパスに続いてPCEPメッセージを使用して、クライアントからそれらのデータロードに向かってP2MP LSPを作成する必要があります。
* Phase 3: NameNode should send this information to the client, and the PCECC should inform the client about the optimal P2MP path towards DataNodes via a PCEP message.
* フェーズ3：NAMENODEはこの情報をクライアントに送信する必要があり、PCECCはPCEPメッセージを介してDatanodesへの最適なP2MPパスについてクライアントに通知する必要があります。
* Phase 4: The client sends data blocks to those DataNodes for writing via the created P2MP tunnel.
* フェーズ4：クライアントは、作成されたP2MPトンネルを介して書き込むために、これらのデータロードにデータブロックを送信します。
When this task is finished, the P2MP tunnel could be turned down.
このタスクが終了すると、P2MPトンネルを倒すことができます。
Thanks to Adrian Farrel, Aijun Wang, Robert Tao, Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Elperin, and Evgeniy Brodskiy for their useful comments and suggestions.
エイドリアン・ファレル、アイジュン・ワン、ロバート・タオ、チャンジャン・ヤン、ティーイング・ファン、セルジオ・ベロッティ、ディーター・ベラー、アンドレイ・エルペリン、エヴゲニー・ブロズキーの有用なコメントと提案のおかげで。
Thanks to Mach Chen and Carlos Pignataro for the RTGDIR review. Thanks to Derrell Piper for the SECDIR review. Thanks to Sue Hares for GENART review.
RTGDIRレビューをしてくれたMach ChenとCarlos Pignataroに感謝します。SecdirレビューをしてくれたDerrell Piperに感謝します。GenArt ReviewのSue Haresに感謝します。
Thanks to Vishnu Pavan Beeram for being the document shepherd and Jim Guichard for being the responsible AD.
Vishnu Pavan Bearamが羊飼いであることを担当してくれたJim Guichardに感謝します。
Thanks to Roman Danyliw for the IESG review comments.
IESGレビューのコメントをしてくれたRoman Danyliwに感謝します。
Luyuan Fang
United States of America
Email: luyuanf@gmail.com
Chao Zhou
HPE
Email: chaozhou_us@yahoo.com
Boris Zhang
Amazon
Email: zhangyud@amazon.com
Artsiom Rachytski
AWS
Germany
Email: arachyts@gmail.com
Anton Hulida
AWS
Australia
Email: hulidant@amazon.com
Zhenbin (Robin) Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing
100095
China
Email: lizhenbin@huawei.com
Dhruv Dhody
Huawei Technologies
India
Email: dhruv.ietf@gmail.com
Quintin Zhao
Etheric Networks
1009 S Claremont St.
San Mateo, CA 94402
United States of America
Email: quintinzhao@gmail.com
King He
Tencent Holdings Ltd.
Shenzhen
China
Email: kinghe@tencent.com
Boris Khasanov
MTS Web Services (MWS)
Andropova Ave. 18, building 9
Moscow
Russian Federation
Email: bhassanov@yahoo.com