[要約] RFC 7334は、PCE（Path Computation Element）を使用して、制約付きのポイントツーマルチポイント（P2MP）インタードメイントラフィックエンジニアリングの最短経路を計算する手順を提供しています。このRFCの目的は、異なるドメイン間でのトラフィックエンジニアリングにおいて、効率的で信頼性の高い経路計算を実現することです。
Internet Engineering Task Force (IETF) Q. Zhao
Request for Comments: 7334 D. Dhody
Category: Experimental Huawei Technology
ISSN: 2070-1721 D. King
Old Dog Consulting
Z. Ali
Cisco Systems
R. Casellas
CTTC
August 2014
PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths
最短の制約付きポイントツーマルチポイント（P2MP）ドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するPCEベースの計算手順
Abstract
概要
The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs.
複数のドメインにわたる制約付きポイントツーマルチポイント（P2MP）トラフィックエンジニアリングラベルスイッチドパス（TE LSP）のパスを計算する機能は、MPLSおよびGMPLS制御ネットワークでのP2MPサービスの展開の主要な要件として識別されています。 Path Computation Element（PCE）は、P2MP TE LSPのドメイン間パスを決定するための適切なテクノロジーとして認識されています。
This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.
このドキュメントでは、P2MP TE LSPのドメイン間パスを計算するためのPCE通信プロトコル（PCEP）の手順と拡張を提供する実験について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7334.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7334で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Requirements Language ......................................4
2. Terminology .....................................................5
3. Examination of Existing Mechanisms ..............................6
4. Assumptions .....................................................7
5. Requirements ....................................................8
6. Objective Functions and Constraints .............................9
7. P2MP Path Computation Procedures ...............................10
7.1. General ...................................................10
7.2. Core-Trees ................................................10
7.3. Optimal Core-Tree Computation Procedure ...................13
7.4. Sub-tree Computation Procedures ...........................15
7.5. PCEP Protocol Extensions ..................................15
7.5.1. Extension of RP Object .............................15
7.5.2. Domain and PCE Sequence ............................16
7.6. Using H-PCE for Scalability ...............................16
7.7. Parallelism ...............................................17
8. Protection .....................................................17
8.1. End-to-End Protection .....................................17
8.2. Domain Protection .........................................18
9. Manageability Considerations ...................................18
9.1. Control of Function and Policy ............................18
9.2. Information and Data Models ...............................18
9.3. Liveness Detection and Monitoring .........................19
9.4. Verifying Correct Operation ...............................19
9.5. Requirements on Other Protocols and Functional
Components ................................................19
9.6. Impact on Network Operation ...............................19
9.7. Policy Control ............................................20
10. Security Considerations .......................................20
11. IANA Considerations ...........................................21
12. Acknowledgements ..............................................21
13. References ....................................................21
13.1. Normative References .....................................21
13.2. Informative References ...................................22
14. Contributors' Addresses .......................................24
Multicast services are increasingly in demand for high-capacity applications such as multicast VPNs, IPTV (which may be on-demand or streamed), and content-rich media distribution (for example, software distribution, financial streaming, or database replication). The ability to compute constrained Traffic Engineering Label Switched Paths (TE LSPs) for point-to-multipoint (P2MP) LSPs in MPLS and GMPLS networks across multiple domains is therefore required.
マルチキャストサービスは、マルチキャストVPN、IPTV（オンデマンドまたはストリーミングの可能性がある）、コンテンツが豊富なメディア配布（ソフトウェア配布、金融ストリーミング、データベースレプリケーションなど）などの大容量アプリケーションに対してますます需要が高まっています。したがって、複数のドメインにまたがるMPLSおよびGMPLSネットワークのポイントツーマルチポイント（P2MP）LSPの制約付きトラフィックエンジニアリングラベルスイッチドパス（TE LSP）を計算する機能が必要です。
The applicability of the PCE [RFC4655] for the computation of such paths is discussed in [RFC5671], and the requirements placed on the PCE Communication Protocol (PCEP) for this are given in [RFC5862].
そのようなパスの計算のためのPCE [RFC4655]の適用性は[RFC5671]で議論され、これのためのPCE通信プロトコル（PCEP）に課された要件は[RFC5862]で与えられます。
This document details the requirements for inter-domain P2MP path computation and then describes the experimental procedure "core-tree" path computation, developed to address the requirements and objectives for inter-domain P2MP path computation.
このドキュメントでは、ドメイン間のP2MPパス計算の要件を詳しく説明し、ドメイン間のP2MPパス計算の要件と目的に対処するために開発された実験手順「コアツリー」パス計算について説明します。
When results of implementation and deployment are available, this document will be updated and refined, and it will then be moved from Experimental status to Standards Track.
実装と展開の結果が利用可能になると、このドキュメントは更新および改良され、実験的ステータスから標準トラックに移動されます。
The inter-domain P2MP path computation procedures described in this document are experimental. The experiment is intended to enable research for the usage of the PCE to support inter-domain P2MP path computation.
このドキュメントで説明されているドメイン間のP2MPパス計算手順は実験的なものです。この実験の目的は、PCEの使用法を調査して、ドメイン間のP2MPパス計算をサポートすることです。
This document is not intended to replace the intra-domain P2MP path computation approach defined by [RFC6006] and will not impact existing PCE procedures and operations.
このドキュメントは、[RFC6006]で定義されているドメイン内P2MPパス計算アプローチに代わるものではなく、既存のPCEの手順と操作には影響しません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Terminology used in this document is consistent with the related MPLS/GMPLS and PCE documents [RFC4461], [RFC4655], [RFC4875], [RFC5376], [RFC5440], [RFC5441], [RFC5671], and [RFC5862].
このドキュメントで使用されている用語は、関連するMPLS / GMPLSおよびPCEドキュメント[RFC4461]、[RFC4655]、[RFC4875]、[RFC5376]、[RFC5440]、[RFC5441]、[RFC5671]、および[RFC5862]と一致しています。
Additional terms are defined below:
追加の用語を以下に定義します。
Core-Tree: a P2MP tree where the root is the ingress Label Switching Router (LSR) and the leaf nodes are the entry boundary nodes of the leaf domains.
コアツリー：P2MPツリー。ルートは入力ラベルスイッチングルーター（LSR）で、リーフノードはリーフドメインのエントリ境界ノードです。
Entry BN of domain(n): a boundary node (BN) connecting domain(n-1) to domain(n) along a determined sequence of domains.
domain（n）のエントリBN：決定された一連のドメインに沿ってdomain（n-1）をdomain（n）に接続する境界ノード（BN）。
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along a determined sequence of domains.
domain（n）の終了BN：決定された一連のドメインに沿ってdomain（n）をdomain（n + 1）に接続するBN。
H-PCE: Hierarchical PCE (as per [RFC6805]).
H-PCE：階層PCE（[RFC6805]による）。
Leaf Domain: a domain with one or more leaf nodes.
リーフドメイン：1つ以上のリーフノードを持つドメイン。
Path Tree: a set of LSRs and TE links that comprise the path of a P2MP TE LSP from the ingress LSR to all egress LSRs (the leaf nodes).
パスツリー：入力LSRからすべての出力LSR（リーフノード）へのP2MP TE LSPのパスを構成するLARおよびTHEリンクのセット。
Path Domain Sequence: the known sequence of domains for a path between the root domain and a leaf domain.
パスドメインシーケンス：ルートドメインとリーフドメイン間のパスの既知のドメインシーケンス。
Path Domain Tree: the tree formed by the domains that the P2MP path crosses, where the source (ingress) domain is the root domain.
パスドメインツリー：P2MPパスが交差するドメインによって形成されるツリー。ソース（入力）ドメインはルートドメインです。
PCE(i): a PCE that performs path computations for domain(i).
PCE（i）：domain（i）のパス計算を実行するPCE。
Root Domain: the domain that includes the ingress (root) LSR.
ルートドメイン：入力（ルート）LSRを含むドメイン。
Sub-tree: a P2MP tree where the root is the selected entry BN of the leaf domain and the leaf nodes are the destinations (leaves) in that domain. The sub-trees are grafted to the core-tree.
サブツリー：ルートがリーフドメインの選択されたエントリBNであり、リーフノードがそのドメインの宛先（リーフ）であるP2MPツリー。サブツリーはコアツリーに移植されます。
Transit/Branch Domain: a domain that has an upstream and one or more downstream neighbor domains.
トランジット/ブランチドメイン：アップストリームドメインと1つ以上のダウンストリームネイバードメインがあるドメイン。
The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed.
[RFC4655]で定義されているパス計算要素（PCE）は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算制約を適用できるエンティティです。パス計算クライアント（PCC）は、パスを計算するようにPCEに要求する場合があります。
[RFC4875] describes how to set up P2MP TE LSPs for use in MPLS- and GMPLS-controlled networks. The PCE is identified as a suitable application for the computation of paths for P2MP TE LSPs [RFC5671].
[RFC4875]は、MPLSおよびGMPLS制御ネットワークで使用するためにP2MP TE LSPを設定する方法を説明しています。 PCEは、P2MP TE LSP [RFC5671]のパスの計算に適したアプリケーションとして識別されます。
[RFC5441] specifies a procedure relying on the use of multiple PCEs to compute point-to-point (P2P) inter-domain constrained shortest paths across a predetermined sequence of domains, using a Backward-Recursive PCE-Based Computation (BRPC) technique. The technique can be combined with the use of Path-Keys [RFC5520] to preserve confidentiality across domains, which is sometimes required when domains are managed by different Service Providers.
[RFC5441]は、複数のPCEを使用して、ドメインの所定のシーケンス全体でポイントツーポイント（P2P）ドメイン間制約付き最短パスを計算する手順を指定します。この手法をパスキーの使用[RFC5520]と組み合わせて、ドメイン全体の機密性を維持できます。これは、ドメインが異なるサービスプロバイダーによって管理されている場合に必要になることがあります。
PCEP [RFC5440] was extended for point-to-multipoint (P2MP) path computation requests in [RFC6006].
PCEP [RFC5440]は、[RFC6006]のポイントツーマルチポイント（P2MP）パス計算リクエスト用に拡張されました。
As discussed in [RFC4461], a P2MP tree is the ordered set of LSRs and TE links that comprise the path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs. A P2MP LSP is set up with TE constraints and allows efficient packet or data replication at various branching points in the network. As per [RFC5671], selection of branch points is fundamental to the determination of the paths for a P2MP TE LSP. Not only is this selection constrained by the network topology and available network resources, but it is also determined by the objective functions (OFs) that may be applied to path computation.
[RFC4461]で説明されているように、P2MPツリーは、LSRとTEリンクの順序付けされたセットであり、その入力LSRからすべての出力LSRへのP2MP TE LSPのパスを構成します。 P2MP LSPにはTE制約が設定されており、ネットワーク内のさまざまな分岐ポイントでパケットまたはデータを効率的に複製できます。 [RFC5671]によると、分岐点の選択は、P2MP TE LSPのパスを決定するための基本です。この選択は、ネットワークトポロジと利用可能なネットワークリソースによって制約されるだけでなく、パス計算に適用される目的関数（OF）によっても決定されます。
Generally, an inter-domain P2MP tree (i.e., a P2MP tree with source and at least one destination residing in different domains) is particularly difficult to compute even for a distributed PCE architecture. For instance, while the BRPC may be well-suited for P2P paths, P2MP path computation involves multiple branching path segments from the source to the multiple destinations. As such, inter-domain P2MP path computation may result in a plurality of per-domain path options that may be difficult to coordinate efficiently and effectively between domains. That is, when one or more domains have multiple ingress and/or egress boundary nodes (i.e., when the domains are multiply inter-connected), existing techniques may be convoluted when used to determine which boundary node of another domain will be utilized for the inter-domain P2MP tree, and there is no way to limit the computation of the P2MP tree to those utilized boundary nodes.
一般に、ドメイン間P2MPツリー（つまり、送信元と少なくとも1つの宛先が異なるドメインに存在するP2MPツリー）は、分散PCEアーキテクチャの場合でも計算が特に困難です。たとえば、BRPCはP2Pパスに適している場合がありますが、P2MPパスの計算には、送信元から複数の宛先への複数の分岐パスセグメントが含まれます。このように、ドメイン間のP2MPパス計算は、ドメイン間で効率的かつ効果的に調整するのが難しい複数のドメインごとのパスオプションをもたらす可能性があります。つまり、1つ以上のドメインに複数の入口または出口の境界ノードがある場合（つまり、ドメインが複数相互接続されている場合）、別のドメインのどの境界ノードを使用するかを決定するために使用すると、既存の手法が複雑になる可能性があります。ドメイン間P2MPツリー。P2MPツリーの計算をそれらの利用された境界ノードに制限する方法はありません。
A trivial solution to the computation of the inter-domain P2MP tree would be to compute shortest inter-domain P2P paths from source to each destination and then combine them to generate an inter-domain, shortest-path-to-destination P2MP tree. This solution, however, cannot be used to trade cost to destination for overall tree cost (i.e., it cannot produce a Minimum Cost Tree (MCT)), and in the context of inter-domain P2MP TE LSPs, it cannot be used to reduce the number of domain boundary nodes that are transited. Computing P2P TE LSPs individually does not guarantee the generation of an optimal P2MP tree for every definition of "optimal" in every topology.
ドメイン間P2MPツリーの計算の簡単な解決策は、送信元から各宛先への最短ドメイン間P2Pパスを計算し、それらを組み合わせてドメイン間、最短パスから宛先P2MPツリーを生成することです。ただし、このソリューションは、全体的なツリーコストの宛先へのコストの交換には使用できません（つまり、最小コストツリー（MCT）を生成できません）。また、ドメイン間P2MP TE LSPのコンテキストでは、削減に使用できません。通過するドメイン境界ノードの数。 P2P TE LSPを個別に計算しても、すべてのトポロジで「最適」の定義ごとに最適なP2MPツリーが生成されるとは限りません。
Per-domain path computation [RFC5152] may be used to compute P2MP multi-domain paths but may encounter the issues previously described. Furthermore, this approach may be considered to have scaling issues during LSP setup. That is, the LSP to each leaf is signaled separately, and each boundary node needs to perform path computation for each leaf.
ドメインごとのパス計算[RFC5152]を使用してP2MPマルチドメインパスを計算できますが、前述の問題が発生する可能性があります。さらに、このアプローチには、LSPセットアップ中にスケーリングの問題があると考えられます。つまり、各リーフへのLSPは個別にシグナリングされ、各境界ノードは各リーフのパス計算を実行する必要があります。
P2MP MCT, i.e., a computation that guarantees the least cost resulting tree, typically is an NP-complete problem. Moreover, adding and/or removing a single destination to/from the tree may result in an entirely different tree. In this case, frequent MCT path computation requests may prove computationally intensive, and the resulting frequent tunnel reconfiguration may even cause network destabilization.
P2MP MCT、つまり、結果として得られるツリーのコストが最小になることを保証する計算は、通常、NP完全な問題です。さらに、ツリーへの単一の宛先の追加またはツリーからの単一の宛先の削除は、まったく異なるツリーになる可能性があります。この場合、MCTパス計算要求が頻繁に行われると、計算量が多くなり、その結果、トンネルが頻繁に再構成されるため、ネットワークが不安定になる可能性があります。
This document presents a solution, procedures, and extensions to PCEP to support P2MP inter-domain path computation.
このドキュメントでは、P2MPドメイン間パス計算をサポートするためのPCEPのソリューション、手順、および拡張について説明します。
Within this document we make the following assumptions:
このドキュメントでは、次のことを前提としています。
o Due to deployment and commercial limitations (e.g., inter-AS (Autonomous System) peering agreements), the path domain tree will be known in advance.
o 導入および商用の制限（AS間（自律システム）のピアリング契約など）により、パスドメインツリーは事前に認識されます。
o Each PCE knows about any leaf LSRs in the domain it serves.
o 各PCEは、それがサービスを提供するドメイン内のリーフLSRを認識しています。
Additional assumptions are documented in [RFC5441] and are not repeated here.
追加の仮定は[RFC5441]に文書化されており、ここでは繰り返されません。
This section summarizes the requirements specific to computing inter-domain P2MP paths. In these requirements, we note that the actual computation time taken by any PCE implementation is outside the scope of this document, but we observe that reducing the complexity of the required computations has a beneficial effect on the computation time regardless of implementation. Additionally, reducing the number of message exchanges and the amount of information exchanged will reduce the overall computation time for the entire P2MP tree. We refer to the "complexity of the computation" as the impact on these aspects of path computation time as various parameters of the topology and the P2MP TE LSP are changed.
このセクションでは、ドメイン間P2MPパスの計算に固有の要件をまとめています。これらの要件では、PCEの実装にかかる実際の計算時間はこのドキュメントの範囲外であることに注意してください。ただし、必要な計算の複雑さを軽減すると、実装に関係なく計算時間に有益な影響があることがわかります。さらに、メッセージ交換の数と交換される情報の量を減らすと、P2MPツリー全体の全体的な計算時間が短縮されます。トポロジとP2MP TE LSPのさまざまなパラメータが変更されるときのパス計算時間のこれらの側面への影響として、「計算の複雑さ」を参照します。
It is also important that the solution can preserve confidentiality across domains, which is required when domains are managed by different Service Providers via the Path-Key mechanism [RFC5520].
ソリューションがドメイン間で機密性を維持できることも重要です。これは、ドメインがパスキーメカニズム[RFC5520]を介してさまざまなサービスプロバイダーによって管理されている場合に必要です。
Other than the requirements specified in [RFC5862], a number of requirements specific to inter-domain P2MP are detailed below:
[RFC5862]で指定された要件以外に、ドメイン間P2MPに固有のいくつかの要件を以下に詳述します。
1. The complexity of the computation for each sub-tree within each domain SHOULD be dependent only on the topology of the domain, and it SHOULD be independent of the domain sequence.
1. 各ドメイン内の各サブツリーの計算の複雑さは、ドメインのトポロジーのみに依存する必要があり（SHOULD）、ドメインシーケンスとは無関係である必要があります（SHOULD）。
2. The number of PCReq (Path Computation Request) and PCRep (Path Computation Reply) messages SHOULD be independent of the number of multicast destinations in each domain.
2. PCReq（Path Computation Request）およびPCRep（Path Computation Reply）メッセージの数は、各ドメインのマルチキャスト宛先の数とは無関係である必要があります（SHOULD）。
3. It SHOULD be possible to specify the domain entry and exit nodes in the PCReq.
3. PCReqでドメインのエントリノードと終了ノードを指定できる必要があります（SHOULD）。
4. Specifying which nodes are to be used as branch nodes SHOULD be supported in the PCReq.
4. 分岐ノードとして使用されるノードの指定は、PCReqでサポートされるべきです（SHOULD）。
5. Reoptimization of existing sub-trees SHOULD be supported.
5. 既存のサブツリーの再最適化をサポートする必要があります（SHOULD）。
6. It SHOULD be possible to compute diverse P2MP paths from existing P2MP paths.
6. 既存のP2MPパスから多様なP2MPパスを計算できるようにする必要があります。
For the computation of a single or a set of P2MP TE LSPs, a request to meet specific optimization criteria, called an objective function (OF), MAY be used. SPT (Shortest Path Tree) and MCT (Minimum Cost Tree), defined in [RFC6006], are two such OF optimization criteria for the sub-tree within each domain used to select the "best" candidate path.
単一または一連のP2MP TE LSPの計算には、目的関数（OF）と呼ばれる特定の最適化基準を満たす要求を使用できます。 [RFC6006]で定義されているSPT（Shortest Path Tree）とMCT（Minimum Cost Tree）は、「最良の」候補パスを選択するために使用される各ドメイン内のサブツリーの2つのOF最適化基準です。
In addition to the OFs, the following constraints MAY also be beneficial for inter-domain P2MP path computation:
OFに加えて、次の制約もドメイン間P2MPパス計算に役立つ場合があります。
1. The computed P2MP "core-tree" SHOULD be optimal when only considering the paths to the leaf domain entry BNs.
1. 計算されたP2MP「コアツリー」は、リーフドメインエントリBNへのパスのみを考慮する場合に最適である必要があります（SHOULD）。
2. Grafting and pruning of multicast destinations (sub-trees) within a leaf domain SHOULD ensure minimal impact on other domains and on the core-tree.
2. リーフドメイン内のマルチキャスト宛先（サブツリー）のグラフティングとプルーニングは、他のドメインとコアツリーへの影響を最小限に抑える必要があります（SHOULD）。
3. It SHOULD be possible to choose to optimize the core-tree.
3. コアツリーを最適化することを選択できるはずです。
4. It SHOULD be possible to choose to optimize the entire tree (P2MP LSP).
4. ツリー全体を最適化することを選択できる必要があります（P2MP LSP）。
5. It SHOULD be possible to combine the aforementioned OFs and constraints for P2MP path computation.
5. 前述のOFとP2MPパス計算の制約を組み合わせることが可能であるべきです（SHOULD）。
When implementing and operating P2MP LSPs, the following need to be taken into consideration:
P2MP LSPを実装して操作するときは、次のことを考慮する必要があります。
o The complexity of computation.
o 計算の複雑さ。
o The optimality of the tree (core-tree as well as full P2MP LSP tree).
o ツリーの最適性（コアツリーおよび完全なP2MP LSPツリー）。
o The stability of the core-tree.
o コアツリーの安定性。
The solution SHOULD allow these trade-offs to be made at computation time.
ソリューションは、これらのトレードオフが計算時に行われることを許可する必要があります。
The algorithms used to compute optimal paths using a combination of OFs and multiple constraints are out of the scope of this document.
OFと複数の制約の組み合わせを使用して最適パスを計算するために使用されるアルゴリズムは、このドキュメントの範囲外です。
A P2MP path computation can be broken down into two steps: core-tree computation and grafting of sub-trees. Breaking the procedure into these specific steps has the following impact, allowing the core-tree-based solution to provide an optimal inter-domain P2MP TE LSP:
P2MPパス計算は、コアツリー計算とサブツリーのグラフティングの2つのステップに分けることができます。手順をこれらの特定のステップに分割すると、次のような影響があり、コアツリーベースのソリューションが最適なドメイン間P2MP TE LSPを提供できるようになります。
o The core-tree and sub-tree are smaller in comparison to the full P2MP tree and are thus easier to compute.
o コアツリーとサブツリーは、完全なP2MPツリーに比べて小さく、計算が簡単です。
o An implementation MAY choose to keep the core-tree fairly static or computed offline (trade-off with optimality).
o 実装は、コアツリーをかなり静的に保つか、オフラインで計算することを選択できます（最適性を備えたトレードオフ）。
o Adding/pruning of leaves requires changes to the sub-tree in the leaf-domain only.
o 葉の追加/プルーニングでは、葉ドメインのサブツリーのみを変更する必要があります。
o The PCEP message size is smaller in comparison.
o 比較すると、PCEPメッセージのサイズは小さくなります。
The following sub-sections describe the core-tree-based mechanism, including procedures and PCEP extensions that satisfy the requirements and objectives specified in Sections 5 and 6 of this document.
次のサブセクションでは、このドキュメントのセクション5と6で指定された要件と目的を満たす手順とPCEP拡張を含む、コアツリーベースのメカニズムについて説明します。
A core-tree is defined as a tree that satisfies the following conditions:
コアツリーは、次の条件を満たすツリーとして定義されます。
o The root of the core-tree is the ingress LSR in the root domain.
o コアツリーのルートは、ルートドメインの入力LSRです。
o The leaves of the core-tree are the entry boundary nodes in the leaf domains.
o コアツリーの葉は、葉ドメインのエントリー境界ノードです。
To support confidentiality, these nodes and links MAY be hidden using the Path-Key mechanism [RFC5520], but they MUST be computed and be a part of the core-tree.
機密性をサポートするために、これらのノードとリンクは、Path-Keyメカニズム[RFC5520]を使用して非表示にすることができますが、計算してコアツリーの一部にする必要があります。
For example, consider the domain tree in Figure 1, representing a domain tree of 6 domains and part of the resulting core-tree, which satisfies the aforementioned conditions.
たとえば、図1のドメインツリーを考えてみます。これは、6つのドメインのドメインツリーと、前述の条件を満たすコアツリーの一部を表しています。
+----------------+
| |Domain D1
| R |
| |
| A |
| |
+-B------------C-+
/ \
/ \
/ \
Domain D2 / \ Domain D3
+-------------D--+ +-----E----------+
| | | |
| F | | |
| G | | H |
| | | |
| | | |
+-I--------------+ +-J------------K-+
/\ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ Domain D4 \ Domain D5 / Domain D6 \
+-L-------------W+ +------P---------+ +-----------T----+
| | | | | |
| | | Q | | U |
| M O | | S | | |
| | | | | V |
| N | | R | | |
+----------------+ +----------------+ +----------------+
Figure 1: Domain Tree Example
図1：ドメインツリーの例
(R)
|
(A)
/ \
/ \
(B) (C)
/ \
/ \
(D) (E)
/ |
/ |
(G) (H)
/ / \
/ / \
(I) (J) (K)
/ \ / \
/ \ / \
(L) (W) (P) (T)
Figure 2: Core-Tree
図2：コアツリー
A core-tree is computed such that the root of the tree is R and the leaf nodes are the entry nodes of the destination domains (L, W, P, and T). The Path-Key mechanism can be used to hide the internal nodes and links in the final core-tree as shown below for domains D2 and D3 (nodes G and H are hidden via Path-Keys PK1 and PK2, respectively).
コアツリーは、ツリーのルートがRで、リーフノードが宛先ドメイン（L、W、P、およびT）のエントリーノードになるように計算されます。パスキーメカニズムを使用すると、ドメインD2とD3の以下に示すように、最終的なコアツリー内の内部ノードとリンクを非表示にできます（ノードGとHは、パスキーPK1とPK2でそれぞれ非表示になります）。
(R)
|
(A)
/ \
/ \
(B) (C)
/ \
/ \
(D) (E)
/ |
/ |
|PK1| |PK2|
/ / \
/ / \
(I) (J) (K)
/ \ / \
/ \ / \
(L) (W) (P) (T)
Figure 3: Core-Tree with Path-Key
図3：パスキーを使用したコアツリー
Applying the core-tree procedure to large groups of domains, such as the Internet, is not considered feasible or desirable and is out of the scope of this document.
コアツリー手順をインターネットなどのドメインの大きなグループに適用することは、実現可能または望ましいとは見なされず、このドキュメントの範囲外です。
The following extended BRPC-based procedure can be used to compute the core-tree. Note that a root PCE MAY further use its own enhanced optimization techniques in the future to compute the core-tree.
次の拡張BRPCベースの手順を使用して、コアツリーを計算できます。ルートPCEは、将来的に独自の拡張最適化手法を使用してコアツリーを計算する可能性があることに注意してください。
A BRPC-based core-tree path computation procedure is described below:
BRPCベースのコアツリーパス計算手順を以下に示します。
1. Use the BRPC procedures to compute the VSPT(i) (Virtual Shortest Path Tree) for each leaf BN(i), i=1 to n, where n is the total number of entry nodes for all the leaf domains. In each VSPT(i), there are a number of P(i) paths.
1. BRPC手順を使用して、各リーフBN（i）のVSPT（i）（仮想最短パスツリー）を計算します（i = 1からn）。ここで、nはすべてのリーフドメインのエントリノードの総数です。各VSPT（i）には、いくつかのP（i）パスがあります。
2. When the root PCE has computed all the VSPT(i), i=1 to n, take one path from each VSPT and form all possible sets of paths. We call them PathSet(j), j=1 to M, where M=P(1)xP(2)...xP(n).
2. ルートPCEがすべてのVSPT（i）（i = 1からn）を計算したら、各VSPTから1つのパスを取り、すべての可能なパスのセットを形成します。それらをPathSet（j）、j = 1からMと呼びます。ここで、M = P（1）xP（2）... xP（n）です。
3. For each PathSet(j), there are n S2L (Source-to-Leaf) BN paths. Form these n paths into a core-tree(j).
3. 各PathSet（j）には、n個のS2L（ソースからリーフ）BNパスがあります。これらのn個のパスをコアツリー（j）に形成します。
4. There will be M number core-trees computed from step 3. An optimal core-tree is selected based on the OF and constraints.
4. ステップ3から計算されたM個のコアツリーがあります。最適なコアツリーは、OFと制約に基づいて選択されます。
Note that since the point-to-point BRPC procedure is used to compute VSPT, the path request and response message formats defined in [RFC5440] are used.
ポイントツーポイントBRPCプロシージャはVSPTの計算に使用されるため、[RFC5440]で定義されているパス要求および応答メッセージ形式が使用されることに注意してください。
Also note that the application of BRPC in the aforementioned procedure differs from the typical one since paths returned from a downstream PCE are not necessarily pruned from the solution set (extended VSPT) by intermediate PCEs. The reason for this is that if the PCE in a downstream domain does the pruning and returns the single optimal sub-path to the upstream PCE, the combination of these single optimal sub-paths into a core-tree is not necessarily optimal even if each S2L (Source-to-Leaf) sub-path is optimal.
また、ダウンストリームPCEから返されたパスは、中間PCEによってソリューションセット（拡張VSPT）からプルーニングされるとは限らないため、前述の手順でのBRPCの適用は一般的なものとは異なります。これは、ダウンストリームドメインのPCEがプルーニングを実行し、単一の最適サブパスをアップストリームPCEに返す場合、これらの単一の最適サブパスの組み合わせがコアツリーに含まれていても、それぞれが最適であるとは限らないためです。 S2L（ソースからリーフ）サブパスが最適です。
Without trimming, the ingress PCE will obtain all the possible S2L sub-paths set for the entry boundary nodes of the leaf domain. By looking through all the combinations and taking one sub-path from each set to build one tree, the PCE will then select the optimal core-tree.
トリミングを行わない場合、入力PCEは、リーフドメインのエントリ境界ノードに設定可能なすべてのS2Lサブパスを取得します。すべての組み合わせを調べ、各セットから1つのサブパスを取得して1つのツリーを構築することにより、PCEは最適なコアツリーを選択します。
A PCE MAY add equal-cost paths within the domain while constructing an extended VSPT. This will provide the ingress PCE more candidate paths for an optimal core-tree.
PCEは、拡張VSPTを構築しながら、ドメイン内に等コストパスを追加する場合があります。これにより、最適なコアツリーのより多くの候補パスが入力PCEに提供されます。
The proposed method may present a scalability problem for the dynamic computation of the core-tree (by iterative checking of all combinations of the solution space), especially with dense/meshed domains. Considering a domain sequence D1, D2, D3, D4, where the leaf boundary node is at domain D4, PCE(4) will return 1 path. PCE(3) will return N paths, where N is E(3) x X(3), where E(k) x X(k) denotes the number of entry nodes times the number of exit nodes for that domain. PCE(2) will return M paths, where M = E(2) x X(2) x N = E(2) x X(2) x E(3) x X(3) x 1, etc. Generally speaking, the number of potential paths at the ingress PCE Q = prod E(k) x X(k).
提案された方法は、特に密/メッシュ領域で、（解空間のすべての組み合わせを繰り返しチェックすることにより）コアツリーの動的計算にスケーラビリティの問題を引き起こす可能性があります。リーフ境界ノードがドメインD4にあるドメインシーケンスD1、D2、D3、D4を考えると、PCE（4）は1つのパスを返します。 PCE（3）はN個のパスを返します。ここで、NはE（3）x X（3）です。ここで、E（k）x X（k）は、そのドメインの入口ノードの数に出口ノードの数を掛けたものです。 PCE（2）はMパスを返します。M= E（2）x X（2）x N = E（2）x X（2）x E（3）x X（3）x 1などです。一般的には、入口PCEでの潜在的なパスの数Q = prod E（k）x X（k）。
Consequently, it is expected that the core-tree will typically be computed offline, without precluding the use of dynamic, online mechanisms such as the one presented here, in which case it SHOULD be possible to configure transit PCEs to control the number of paths sent upstream during BRPC (trading trimming for optimality at the point of trimming and downwards).
その結果、コアツリーは通常、オフラインで計算されることが予想されます。ここに示すような動的なオンラインメカニズムの使用を排除することはありません。その場合、送信されるパスの数を制御するように中継PCEを構成することが可能です。 BRPC中の上流（トリミングのポイントでの最適化のための取引トリミングおよび下向き）。
Once the core-tree is built, the grafting of all the leaf nodes from each domain to the core-tree can be achieved by a number of algorithms. One algorithm for doing this phase is that the root PCE will send the request with the C-bit set (as defined in Section 7.5.1 of this document) for the path computation to the destination(s) directly to the PCE where the destination(s) belong(s) along with the core-tree computed per Section 7.2.
コアツリーが構築されると、各ドメインからコアツリーへのすべての葉ノードのグラフティングは、いくつかのアルゴリズムによって実現できます。このフェーズを実行するためのアルゴリズムの1つは、ルートPCEがCビットセット（このドキュメントのセクション7.5.1で定義）を使用して、宛先へのパス計算の要求をPCEに直接送信することです。セクション7.2に従って計算されたコアツリーと一緒に属します。
This approach requires that the root PCE manage a potentially large number of adjacencies (either in persistent or non-persistent mode), including PCEP adjacencies to PCEs that are not within neighbor domains.
このアプローチでは、ルートPCEが、隣接ドメイン内にないPCEへのPCEP隣接関係を含め、潜在的に多数の隣接関係（永続モードまたは非永続モードのいずれか）を管理する必要があります。
An alternative would involve establishing PCEP adjacencies that correspond to the PCE domain tree. This would require that branch PCEs forward requests and responses from the root PCE towards the leaf PCEs and vice versa.
別の方法では、PCEドメインツリーに対応するPCEP隣接関係を確立する必要があります。これには、ブランチPCEが要求と応答をルートPCEからリーフPCEに、またはその逆に転送する必要があります。
Note that the P2MP path request and response format is as per [RFC6006], where Record Route Objects (RROs) are used to carry the core-tree paths in the P2MP grafting request.
P2MPパスの要求と応答の形式は[RFC6006]のとおりであることに注意してください。レコードルートオブジェクト（RRO）は、P2MPグラフティング要求でコアツリーパスを運ぶために使用されます。
The algorithms to compute the optimal large sub-tree are outside the scope of this document.
最適な大きなサブツリーを計算するアルゴリズムは、このドキュメントの範囲外です。
This experiment will be carried out by extending the RP (Request Parameters) object (defined in [RFC5440]) used in PCEP requests and responses.
この実験は、PCEP要求と応答で使用されるRP（要求パラメーター）オブジェクト（[RFC5440]で定義）を拡張することによって実行されます。
The extended format of the RP object body to include the C-bit is as follows:
Cビットを含めるためのRPオブジェクト本体の拡張形式は次のとおりです。
The C-bit is added in the flag bits field of the RP object to signal the receiver of the message whether or not the request/reply is for inter-domain P2MP core-tree.
RPオブジェクトのフラグビットフィールドにCビットが追加され、要求/応答がドメイン間P2MPコアツリーに対するものであるかどうかにかかわらず、メッセージの受信者に信号が送られます。
The following flag is added in this document:
このドキュメントには、次のフラグが追加されています。
Bit Number Name Flag 17 Core-tree computation (C-bit)
ビット番号名前フラグ17コアツリー計算（Cビット）
C-bit (Core-Tree bit - 1 bit):
Cビット（コアツリービット-1ビット）：
0: Indicates that this is not for an inter-domain P2MP core-tree.
0：これがドメイン間P2MPコアツリー用ではないことを示します。
1: Indicates that this is a PCEP request or a response for the computation of an inter-domain core-tree or for the grafting of a sub-tree to an inter-domain core-tree.
1：これが、ドメイン間コアツリーの計算またはドメイン間コアツリーへのサブツリーのグラフティングに対するPCEP要求または応答であることを示します。
The procedure described in this document requires the domain tree to be known in advance. This information MAY be either administratively predetermined or dynamically discovered by some means, such as the Hierarchical PCE (H-PCE) framework [RFC6805], or derived through the IGP/BGP routing information.
このドキュメントで説明する手順では、ドメインツリーが事前にわかっている必要があります。この情報は、管理上事前に決定されるか、階層PCE（H-PCE）フレームワーク[RFC6805]などの手段によって動的に検出されるか、IGP / BGPルーティング情報を介して導出される場合があります。
Examples of ways to encode the domain path tree are found in [RFC5886], which uses PCE-ID Objects, and [DOMAIN-SEQ].
ドメインパスツリーをエンコードする方法の例は、PCE-IDオブジェクトを使用する[RFC5886]と[DOMAIN-SEQ]にあります。
The ingress/root PCE is responsible for the core-tree computation as well as grafting of sub-trees into the multi-domain tree. Therefore, the ingress/root PCE will receive all computed path segments from all the involved domains. When the ingress/root PCE chooses to have a PCEP session with all involved PCEs, this may cause an excessive number of sessions or added complexity in implementations.
入力/ルートPCEは、コアツリーの計算と、サブツリーのマルチドメインツリーへのグラフティングを担当します。したがって、入力/ルートPCEは、関連するすべてのドメインから計算されたすべてのパスセグメントを受信します。入力/ルートPCEが、関連するすべてのPCEとのPCEPセッションを持つことを選択すると、過剰な数のセッションが発生したり、実装が複雑になったりする可能性があります。
The H-PCE framework [RFC6805] may be used to establish a dedicated PCE with the capability (memory and CPU) and knowledge to maintain the necessary PCEP sessions. The parent PCE would be responsible for sending an intra-domain path computation request to the PCEs, combining them, and returning the overall P2MP tree.
H-PCEフレームワーク[RFC6805]を使用して、必要なPCEPセッションを維持する機能（メモリとCPU）と知識を持つ専用PCEを確立できます。親PCEは、ドメイン内パス計算要求をPCEに送信し、それらを結合して、全体的なP2MPツリーを返す役割を果たします。
In order to minimize latency in path computation in multi-domain networks, intra-domain path segments and intra-domain sub-trees can be computed in parallel when possible. The proposed procedures in this document present opportunities for parallelism:
マルチドメインネットワークでのパス計算のレイテンシを最小限に抑えるために、可能な場合は、ドメイン内パスセグメントとドメイン内サブツリーを並行して計算できます。このドキュメントで提案されている手順は、並列処理の機会を示しています。
1. The BRPC procedure for each leaf boundary node can be launched in parallel by the ingress/root PCE for dynamic computation of the core-tree.
1. 各リーフ境界ノードのBRPCプロシージャは、コアツリーの動的計算のために、入力/ルートPCEによって並行して起動できます。
2. The grafting of sub-trees can be triggered in parallel once the core-tree is computed.
2. コアツリーが計算されると、サブツリーのグラフティングを並行してトリガーできます。
One of the potential issues of parallelism is that the ingress PCE would require a potentially high number of PCEP adjacencies to "remote" PCEs at the same time; this situation may not be desirable.
並列処理の潜在的な問題の1つは、入力PCEが同時にPCEを「リモート」にするために、潜在的に多数のPCEP隣接関係を必要とすることです。この状況は望ましくない場合があります。
It is envisaged that protection may be required when deploying and using inter-domain P2MP TE LSPs. The procedures and mechanisms defined in this document do not prohibit the use of existing and proposed types of protection, including end-to-end protection [RFC4872] and domain protection schemes.
ドメイン間P2MP TE LSPを展開して使用する場合は、保護が必要になる可能性があると想定されています。このドキュメントで定義されている手順とメカニズムは、エンドツーエンド保護[RFC4872]やドメイン保護スキームを含む、既存および提案されているタイプの保護の使用を禁止していません。
Segment or facility (link and node) protection is problematic in inter-domain environments due to the limit of fast reroute (FRR) [RFC4875] requiring knowledge of its next hop across domain boundaries while maintaining domain confidentiality. However, the FRR protection might be implemented if next-hop information was known in advance.
高速再ルーティング（FRR）[RFC4875]の制限により、ドメインの機密性を維持しながらドメイン境界を越えたネクストホップの知識が必要なため、セグメントまたはファシリティ（リンクおよびノード）保護はドメイン間環境で問題があります。ただし、ネクストホップ情報が事前にわかっている場合は、FRR保護が実装される可能性があります。
An end-to-end protection (for nodes and links) principle can be applied for computing backup P2MP TE LSPs. During computation of the core-tree and sub-trees, protection may also be taken into consideration. A PCE may compute the primary and backup P2MP TE LSP together or sequentially.
エンドツーエンド保護（ノードとリンクの場合）の原則は、バックアップP2MP TE LSPの計算に適用できます。コアツリーとサブツリーの計算中に、保護も考慮される場合があります。 PCEは、プライマリとバックアップのP2MP TE LSPを一緒に、または順次計算できます。
In this protection scheme, a backup P2MP tree can be computed that excludes the transit/branch domain completely. A backup domain path tree is needed with the same source domain and destination domains and a new set of transit domains. The backup path tree can be applied to the above procedure to obtain the backup P2MP TE LSP with disjoint transit domains.
この保護スキームでは、トランジット/ブランチドメインを完全に除外するバックアップP2MPツリーを計算できます。バックアップドメインパスツリーは、同じソースドメインと宛先ドメイン、および一連の新しい中継ドメインで必要です。上記の手順にバックアップパスツリーを適用して、トランジットドメインが分離されたバックアップP2MP TE LSPを取得できます。
[RFC5862] describes various manageability requirements in support of P2MP path computation when applying PCEP. This section describes how the manageability requirements mentioned in [RFC5862] are supported in the context of PCEP extensions specified in this document.
[RFC5862]は、PCEPを適用する際のP2MPパス計算をサポートするためのさまざまな管理要件を説明しています。このセクションでは、[RFC5862]で言及されている管理要件が、このドキュメントで指定されているPCEP拡張のコンテキストでどのようにサポートされるかについて説明します。
Note that [RFC5440] describes various manageability considerations in PCEP, and most of the manageability requirements mentioned in [RFC6006] are already covered there.
[RFC5440]はPCEPでの管理性に関するさまざまな考慮事項を説明しており、[RFC6006]で言及されている管理性要件のほとんどはそこですでにカバーされています。
In addition to the PCE configuration parameters listed in [RFC5440] and [RFC6006], the following additional parameters might be required:
[RFC5440]および[RFC6006]にリストされているPCE構成パラメーターに加えて、以下の追加パラメーターが必要になる場合があります。
o The ability to enable or disable multi-domain P2MP path computations on the PCE.
o PCEでマルチドメインP2MPパス計算を有効または無効にする機能。
o Configuration of the PCE to enable or disable the advertisement of its multi-domain P2MP path computation capability.
o マルチドメインP2MPパス計算機能のアドバタイズを有効または無効にするPCEの構成。
A number of MIB objects have been defined for general PCEP control and monitoring of P2P computations in [PCEP-MIB]. [RFC5862] specifies that MIB objects will be required to support the control and monitoring of the protocol extensions defined in this document. [PCEP-P2MP-MIB] describes managed objects for modeling of PCEP communications between a PCC and PCE, communication between PCEs, and P2MP path computation requests and responses.
[PCEP-MIB]では、一般的なPCEP制御とP2P計算の監視のために、いくつかのMIBオブジェクトが定義されています。 [RFC5862]は、このドキュメントで定義されているプロトコル拡張の制御と監視をサポートするためにMIBオブジェクトが必要になることを指定しています。 [PCEP-P2MP-MIB]は、PCCとPCE間のPCEP通信、PCE間の通信、およびP2MPパス計算の要求と応答をモデリングするための管理対象オブジェクトについて説明します。
No changes are necessary to the liveness detection and monitoring requirements as already embodied in [RFC4657].
[RFC4657]で既に具体化されているように、活性検出と監視の要件を変更する必要はありません。
It should be noted that multi-domain P2MP computations are likely to take longer than P2P computations and single-domain P2MP computations. The liveness detection and monitoring features of the PCEP SHOULD take this into account.
マルチドメインP2MP計算は、P2P計算およびシングルドメインP2MP計算よりも時間がかかる可能性があることに注意してください。 PCEPの活性検出および監視機能は、これを考慮に入れるべきです（SHOULD）。
There are no additional requirements beyond those expressed in [RFC4657] for verifying the correct operation of the PCEP. Note that verification of the correct operation of the PCE and its algorithms is out of the scope of the protocol requirements, but a PCC MAY send the same request to more than one PCE and compare the results.
PCEPの正しい動作を検証するために、[RFC4657]で表現されているもの以外の追加の要件はありません。 PCEとそのアルゴリズムの正しい動作の検証はプロトコル要件の範囲外ですが、PCCは同じ要求を複数のPCEに送信して結果を比較する場合があります。
A PCE operates on a topology graph that may be built using information distributed by TE extensions to the routing protocol operating within the network. In order that the PCE can select a suitable path for the signaling protocol to use to install the P2MP TE LSP, the topology graph MUST include information about the P2MP signaling and branching capabilities of each LSR in the network.
PCEは、ネットワーク内で動作するルーティングプロトコルへのTE拡張機能によって配布された情報を使用して構築できるトポロジグラフで動作します。 PCEがシグナリングプロトコルがP2MP TE LSPをインストールするために使用する適切なパスを選択できるようにするために、トポロジグラフには、ネットワーク内の各LSRのP2MPシグナリングおよび分岐機能に関する情報を含める必要があります。
Mechanisms for the knowledge of other domains and the discovery of corresponding PCEs and their capabilities SHOULD be provided, and this information MAY be collected by other mechanisms.
他のドメインの知識と対応するPCEとその機能の発見のためのメカニズムが提供されるべきであり、この情報は他のメカニズムによって収集されてもよい（MAY）。
Whatever means is used to collect the information to build the topology graph, the graph MUST include the requisite information. If the TE extensions to the routing protocol are used, these SHOULD be as described in [RFC5073].
トポロジグラフを作成するための情報を収集するためにどのような手段を使用しても、グラフには必要な情報を含める必要があります。ルーティングプロトコルへのTE拡張が使用される場合、これらは[RFC5073]で説明されているとおりである必要があります。
The use of a PCE to compute P2MP paths is not expected to have significant impact on network operations. However, it should be noted that the introduction of P2MP support to a PCE that already provides P2P path computation might change the loading of the PCE significantly, and that might have an impact on the network behavior, especially during recovery periods immediately after a network failure.
PCEを使用してP2MPパスを計算しても、ネットワーク運用に大きな影響はありません。ただし、すでにP2Pパス計算を提供しているPCEにP2MPサポートを導入すると、PCEの負荷が大幅に変更される可能性があり、特にネットワーク障害の直後の回復期間に、ネットワークの動作に影響を与える可能性があることに注意してください。 。
The dynamic computation of core-trees might also have an impact on the load of the involved PCEs as well as path computation times.
コアツリーの動的計算は、パス計算時間だけでなく、関連するPCEの負荷にも影響を与える可能性があります。
It should be noted that pre-computing and maintaining domain trees might introduce considerable administration effort for the operator.
ドメインツリーを事前に計算して維持すると、オペレーターにとってかなりの管理作業が必要になる場合があることに注意してください。
[RFC5394] provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. They are also applicable to inter-domain P2MP path computation via the core-tree mechanism.
[RFC5394]は、PCEアーキテクチャ内のポリシーに関する追加の詳細を提供し、PCEポリシーのサポートのコンテキストも提供します。また、コアツリーメカニズムを介したドメイン間P2MPパス計算にも適用できます。
As described in [RFC5862], P2MP path computation requests are more CPU-intensive and also utilize more link bandwidth. In the event of an unauthorized P2MP path computation request or a denial-of-service attack, the subsequent PCEP requests and processing may be disruptive to the network. Consequently, it is important that implementations conform to the relevant security requirements of [RFC5440] that specifically help to minimize or negate unauthorized P2MP path computation requests and denial-of-service attacks. These mechanisms include:
[RFC5862]で説明されているように、P2MPパス計算リクエストはより多くのCPUを必要とし、より多くのリンク帯域幅を利用します。不正なP2MPパス計算要求またはサービス拒否攻撃が発生した場合、後続のPCEP要求と処理はネットワークに混乱をもたらす可能性があります。その結果、実装は、[RFC5440]の関連するセキュリティ要件に準拠することが重要です。これは、不正なP2MPパス計算要求とサービス拒否攻撃を最小限に抑えるか、無効にするのに特に役立ちます。これらのメカニズムは次のとおりです。
o Securing the PCEP session requests and responses using TCP security techniques (Section 10.2 of [RFC5440]).
o TCPセキュリティ技術を使用してPCEPセッションの要求と応答を保護する（[RFC5440]のセクション10.2）。
o Authenticating the PCEP requests and responses to ensure the message is intact and sent from an authorized node (Section 10.3 of [RFC5440]).
o PCEP要求と応答を認証して、メッセージが完全な状態で、承認済みノードから送信されたことを確認します（[RFC5440]のセクション10.3）。
o Providing policy control by explicitly defining which PCCs, via IP access lists, are allowed to send P2MP path requests to the PCE (Section 10.6 of [RFC5440]).
o IPアクセスリストを介してP2MPパスリクエストをPCEに送信できるPCCを明示的に定義することにより、ポリシー制御を提供します（[RFC5440]のセクション10.6）。
PCEP operates over TCP, so it is also important to secure the PCE and PCC against TCP denial-of-service attacks. Section 10.7.1 of [RFC5440] outlines a number of mechanisms for minimizing the risk of TCP-based denial-of-service attacks against PCEs and PCCs.
PCEPはTCPを介して動作するため、TCPサービス拒否攻撃からPCEおよびPCCを保護することも重要です。 [RFC5440]のセクション10.7.1は、PCEおよびPCCに対するTCPベースのサービス拒否攻撃のリスクを最小限に抑えるためのいくつかのメカニズムを概説しています。
PCEP implementations SHOULD also consider the additional security provided by the TCP Authentication Option (TCP-AO) [RFC5925].
PCEP実装は、TCP認証オプション（TCP-AO）[RFC5925]によって提供される追加のセキュリティも考慮する必要があります（SHOULD）。
Finally, any multi-domain operation necessarily involves the exchange of information across domain boundaries. This may represent a significant security and confidentiality risk, especially when the domains are controlled by different commercial entities. PCEP allows individual PCEs to maintain confidentiality of their domain path information by using Path-Keys [RFC5520] and would allow for securing of domain path information when performing core-tree-based path computations.
最後に、マルチドメイン操作には、ドメイン境界を越えた情報の交換が必要です。これは、特にドメインがさまざまな営利団体によって管理されている場合に、セキュリティと機密性に関する重大なリスクとなる可能性があります。 PCEPは、個々のPCEがパスキー[RFC5520]を使用してドメインパス情報の機密性を維持できるようにし、コアツリーベースのパス計算を実行するときにドメインパス情報を保護できるようにします。
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry and the "RP Object Flag Field" sub-registry.
IANAは、「Path Computation Element Protocol（PCEP）Numbers」レジストリと「RP Object Flag Field」サブレジストリを維持しています。
IANA has allocated a new bit from this registry as follows:
IANAは、このレジストリから次のように新しいビットを割り当てました。
Bit Description Reference 17 Core-tree computation (C-bit) [RFC7334]
ビット記述リファレンス17コアツリー計算（Cビット）[RFC7334]
The authors would like to thank Adrian Farrel, Dan Tappan, Olufemi Komolafe, Oscar Gonzalez de Dios, and Julien Meuric for their valuable comments on this document.
このドキュメントに対する貴重なコメントを提供してくれたAdrian Farrel、Dan Tappan、Olufemi Komolafe、Oscar Gonzalez de Dios、およびJulien Meuricに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、Ed。、and JL。 Le Roux編、「Path Computation Element（PCE）Communication Protocol（PCEP）」、RFC 5440、2009年3月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441] Vasseur、JP。、Ed。、Zhang、R.、Bitar、N.、and JL。 Le Roux、「最短の制約付きドメイン間トラフィックエンジニアリングラベルスイッチドパスを計算するための後方再帰PCEベースの計算（BRPC）手順」、RFC 5441、2009年4月。
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010.
[RFC6006] Zhao、Q.、Ed。、King、D.、Ed。、Verhaeghe、F.、Takeda、T.、Ali、Z. and J. Meuric、 "Extensions to the Path Computation Element Communication Protocol（PCEP ）ポイントツーマルチポイントトラフィックエンジニアリングラベルスイッチドパス」、RFC 6006、2010年9月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461] Yasukawa、S.、Ed。、「ポイントツーマルチポイントトラフィックエンジニアリングMPLSラベルスイッチドパス（LSP）のシグナリング要件」、RFC 4461、2006年4月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、2006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J。、編、およびJ. Le Roux、編、「Path Computation Element（PCE）Communication Protocol Generic Requirements」、RFC 4657、2006年9月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872] Lang、J。、編、Rekhter、Y。、編、およびD. Papadimitriou、編、「エンドツーエンドの汎用マルチプロトコルラベルスイッチング（GMPLS）リカバリをサポートするRSVP-TE拡張"、RFC 4872、2007年5月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875] Aggarwal、R.、Ed。、Papadimitriou、D.、Ed。、and S. Yasukawa、Ed。、 "Extensions to Resource Reservation Protocol-Traffic Engineering（RSVP-TE）for Point-to-Multipoint TE Label Switchedパス（LSP）」、RFC 4875、2007年5月。
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007.
[RFC5073] Vasseur、J.、Ed。およびJ. Le Roux、Ed。、 "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities"、RFC 5073、December 2007。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[RFC5152] Vasseur、JP。、編、Ayyangar、A。、編、およびR. Zhang、「ドメイン間トラフィックエンジニアリング（TE）ラベルスイッチドパス（LSP）を確立するためのドメインごとのパス計算方法」、 RFC 5152、2008年2月。
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5376] Bitar、N.、Zhang、R。、およびK. Kumaki、「パス計算要素通信プロトコル（PCECP）のInter-AS要件」、RFC 5376、2008年11月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「Policy-Enabled Path Computation Framework」、RFC 5394、2008年12月。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5520] Bradford、R。、編、Vasseur、JP、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算におけるトポロジの機密性の保持」、RFC 5520、2009年4月。
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, October 2009.
[RFC5671] Yasukawa、S. and A. Farrel、Ed。、 "Applicability of the Path Computation Element（PCE）to Point-to-Multipoint（P2MP）MPLS and GMPLS Traffic Engineering（TE）"、RFC 5671、October 2009。
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE", RFC 5862, June 2010.
[RFC5862] Yasukawa、S. and A. Farrel、 "Path Computation Clients（PCC）-Path Computation Element（PCE）Requirements for Point-to-Multipoint MPLS-TE"、RFC 5862、June 2010。
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, June 2010.
[RFC5886] Vasseur、JP。、Ed。、Le Roux、JL。、and Y. Ikejiri、 "A Set Monitoring Tools for Path Computation Element（PCE）-Based Architecture"、RFC 5886、2010年6月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A。、およびR. Bonica、「The TCP Authentication Option」、RFC 5925、2010年6月。
[RFC6805] King, D., Ed., and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, November 2012.
[RFC6805]キング、D。、エド、およびA.ファレル、エド、「MPLSおよびGMPLSにおけるドメインのシーケンスの決定へのパス計算要素アーキテクチャの適用」、RFC 6805、2012年11月。
[PCEP-MIB] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Protocol (PCEP) Management Information Base", Work in Progress, July 2014.
[PCEP-MIB] Koushik、A.、Stephan、E.、Zhao、Q.、King、D。、およびJ. Hardwick、「Path Computation Element Protocol（PCEP）Management Information Base」、Work in Progress、2014年7月。
[PCEP-P2MP-MIB] Zhao, Q., Dhody, D., Palle, U., and D. King, "Management Information Base for the PCE Communications Protocol (PCEP) When Requesting Point-to-Multipoint Services", Work in Progress, August 2012.
[PCEP-P2MP-MIB] Zhao、Q.、Dhody、D.、Palle、U。、およびD. King、「ポイントツーマルチポイントサービスを要求するときのPCE通信プロトコル（PCEP）の管理情報ベース」、作業進行中、2012年8月。
[DOMAIN-SEQ] Dhody, D., Palle, U., and R. Casellas, "Standard Representation Of Domain-Sequence", Work in Progress, July 2014.
[DOMAIN-SEQ] Dhody、D.、Palle、U。、およびR. Casellas、「Standard-Representation Of Domain-Sequence」、Work in Progress、2014年7月。
Siva Sivabalan Cisco Systems 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Shiva Sivabalan Cisco Systemsವイノベーションドライブカンタ、オンタリオQ1 ೮カナダ
EMail: msiva@cisco.com
Tarek Saad Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
たれｋ さあｄ しｓこ Ｓｙｓてｍｓ、 いんｃ。 ２０００ いんおゔぁちおん Ｄりゔぇ かなた、 おんたりお Ｋ２Ｋ ３え８ かなだ
EMail: tsaad@cisco.com
Authors' Addresses
著者のアドレス
Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US
Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton、MA 01719 US
EMail: quintin.zhao@huawei.com
Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka 560008 India
Dhruv Dhody Huawei Technology Leela Palace Bangalore、Karnataka、560008 India
EMail: dhruv.dhody@huawei.com
Daniel King Old Dog Consulting UK
Daniel King Old Dog Consulting UK
EMail: daniel@olddog.co.uk
Zafar Ali Cisco Systems 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
ざふぁｒ あぃ しｓこ Ｓｙｓてｍｓ ２０００ いんおゔぁちおん Ｄりゔぇ かなた、 おんたりお Ｋ２Ｋ ３え８ かなだ
EMail: zali@cisco.com
Ramon Casellas CTTC Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain
ラモンカセラスCTTC Av。カールフリードリヒガウスn7カステルデフェルス、バルセロナ08860スペイン
EMail: ramon.casellas@cttc.es