[要約] 要約： RFC 5862は、Point-to-Multipoint MPLS-TEにおけるPath Computation Clients (PCC)とPath Computation Element (PCE)の要件を定義しています。目的： このRFCの目的は、Point-to-Multipoint MPLS-TEネットワークにおいて、PCCとPCEの間の通信と相互作用に関する要件を明確にすることです。
Internet Engineering Task Force (IETF) S. Yasukawa
Request for Comments: 5862 NTT Corporation
Category: Informational A. Farrel
ISSN: 2070-1721 Old Dog Consulting
June 2010
Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE
パス計算クライアント（PCC） - ポイントツーマルチポイントMPLS-TEのパス計算要素（PCE）要件
Abstract
概要
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
PATH計算要素（PCE）は、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPL（GMPLS）ネットワークのトラフィックエンジニアリングをサポートするパス計算関数を提供します。
Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.
MPLSおよびGMPLSシグナリングおよびルーティングプロトコルへの拡張は、ポイントツーマルチポイント（P2MP）トラフィックエンジニアリング（TE）ラベルスイッチ付きパス（LSP）をサポートするために作成されています。MPLSネットワークでのPCEの使用はすでに確立されており、P2MP TE LSPルートは計算するのに複雑な場合があるため、PCEがP2MP LSPに使用される可能性があります。
Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering.
PATH計算クライアント（PCCS）とPCES間の通信プロトコルの一般的な要件は、RFC 4657、「PATH COMPUTATION ELEMENT（PCE）通信プロトコルジェネリック要件」に示されています。このドキュメントは、一般的な要件を補完し、ポイントツーマルチポイントMPLS/GMPLSトラフィックエンジニアリングのPCC-PCE通信プロトコル要件の詳細なセットを提示します。
Status of This Memo
本文書の位置付け
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。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/rfc5862.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5862で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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. The intention is that the PCE is used to compute the path of Traffic Engineered Label Switched Paths (TE LSPs) within Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
[RFC4655]で定義されているパス計算要素（PCE）は、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるエンティティです。PCEは、マルチプロトコルラベルスイッチング（MPLS）および一般化されたMPLS（GMPLS）ネットワーク内のトラフィックエンジニアリングラベルスイッチ付きパス（TE LSP）のパスを計算するために使用されることです。
Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are documented in [RFC4461], and signaling protocol extensions for setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE networks are considered in support of various features, including layer 3 multicast virtual private networks [RFC4834].
ポイントツーマルチポイント（P2MP）MPLS TE LSPの要件は[RFC4461]に文書化されており、P2MP MPLS TE LSPをセットアップするためのシグナル伝達プロトコル拡張は[RFC4875]で定義されています。P2MP MPLS TEネットワークは、レイヤー3マルチキャスト仮想プライベートネットワーク[RFC4834]を含むさまざまな機能をサポートするために考慮されています。
Path computation for P2MP TE LSPs presents a significant challenge, and network optimization of multiple P2MP TE LSPs requires considerable computational resources. PCE offers a way to offload such path computations from Label Switching Routers (LSRs).
P2MP TE LSPのパス計算には大きな課題があり、複数のP2MP TE LSPのネットワーク最適化にはかなりの計算リソースが必要です。PCEは、ラベルスイッチングルーター（LSR）からこのようなパス計算をオフロードする方法を提供します。
The applicability of the PCE-based path computation architecture to P2MP MPLS TE is described in a companion document [RFC5671]. No further attempt is made to justify the use of PCE for P2MP MPLS TE within this document.
P2MP MPLS TEへのPCEベースのパス計算アーキテクチャの適用性は、コンパニオンドキュメント[RFC5671]で説明されています。このドキュメント内のP2MP MPLS TEのPCEの使用を正当化するためのさらなる試みは行われません。
This document presents a set of PCC-PCE communication protocol (PCECP) requirements for P2MP MPLS traffic engineering. It supplements the generic requirements documented in [RFC4657].
このドキュメントでは、P2MP MPLSトラフィックエンジニアリングのPCC-PCE通信プロトコル（PCECP）要件のセットを提示します。[RFC4657]に文書化された一般的な要件を補完します。
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]. Although this document is not a protocol specification, this convention is adopted for clarity of description of requirements.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [RFC2119]に記載されているように解釈される。このドキュメントはプロトコルの仕様ではありませんが、この規則は要件の説明を明確にするために採用されています。
This section sets out additional requirements specific to P2MP MPLS TE that are not covered in [RFC4657].
このセクションでは、[RFC4657]でカバーされていないP2MP MPLS TEに固有の追加要件を示します。
The PCC-PCE communication protocol MUST allow requests and replies for the computation of paths for P2MP LSPs.
PCC-PCE通信プロトコルは、P2MP LSPのパスの計算のリクエストと返信を許可する必要があります。
This requires no additional messages, but requires the addition of the parameters described in the following sections to the existing PCC-PCE communication protocol messages.
これには追加のメッセージは必要ありませんが、既存のPCC-PCE通信プロトコルメッセージに次のセクションで説明されているパラメーターを追加する必要があります。
R1: Although the presence of certain parameters (such as a list of more than one destination) MAY be used by a protocol specification to allow an implementation to infer that a Path Computation Request is for a P2MP LSP, an explicit parameter SHOULD be placed in a conspicuous place within a Path Computation Request message to allow a receiving PCE to easily identify that the request is for a P2MP path.
R1：特定のパラメーターの存在（複数の宛先のリストなど）をプロトコル仕様で使用することができますが、実装がパス計算要求がP2MP LSPに対してであると推測できるようにすることができますが、明示的なパラメーターを配置する必要があります。受信PCEがリクエストがP2MPパスのものであることを簡単に識別できるようにするパス計算要求メッセージ内の顕著な場所。
R2: [RFC4657] includes the requirement to be able to specify the objective functions to be applied by a PCE during path computation.
R2：[RFC4657]には、パス計算中にPCEによって適用される目的関数を指定できる要件が含まれています。
This document makes no change to that requirement, but it should be noted that new and different objective functions will be used for P2MP computation. Definitions for core objective functions can be found in [RFC5541] together with usage procedures. New objective functions for use with P2MP path computations will need to be defined and allocated codepoints in a separate document.
このドキュメントはその要件を変更しませんが、P2MP計算には新しい異なる目的関数が使用されることに注意する必要があります。コア目標関数の定義は、使用手順とともに[RFC5541]に記載されています。P2MPパス計算で使用する新しい目的関数は、別のドキュメントでコードポイントを定義し、割り当てる必要があります。
R3: PCEs are not required to support P2MP path computation. Therefore, it MUST be possible for a PCE to reject a P2MP Path Computation Request message with a reason code that indicates no support for P2MP path computation.
R3：P2MPパス計算をサポートするためにPCESは必要ありません。したがって、PCEがP2MPパス計算のサポートがないことを示す理由コードを備えたP2MPパス計算要求メッセージを拒否することが可能である必要があります。
It is possible that initial PCE implementations will be developed without support for P2MP path computation and without the ability to recognize the explicit parameter described in Section 3.1.1. Such legacy implementations will not be able to make use of the new reason code described in Section 3.1.3.
P2MPパス計算のサポートなしで、セクション3.1.1で説明されている明示的なパラメーターを認識する機能なしで、初期のPCE実装が開発される可能性があります。このようなレガシーの実装は、セクション3.1.3で説明されている新しい理由コードを利用することはできません。
R4: Therefore, at least one parameter required for inclusion in a P2MP Path Computation Request message MUST be defined in such a way as to cause automatic rejection as unprocessable or unrecognized by a back-level PCE implementation without requiring any changes to that PCE. It is RECOMMENDED that the parameter that causes this result be the parameter described in Section 3.1.1.
R4：したがって、P2MPパス計算要求メッセージに含めるために必要な少なくとも1つのパラメーターは、そのPCEに変更を必要とせずにバックレベルのPCE実装によって処理できない、または認識されない自動拒否を引き起こすような方法で定義する必要があります。この結果を引き起こすパラメーターは、セクション3.1.1で説明されているパラメーターであることをお勧めします。
R5: Since P2MP LSPs have more than one destination, it MUST be possible for a single Path Computation Request to list multiple destinations.
R5：P2MP LSPには複数の宛先があるため、単一のパス計算要求が複数の宛先をリストすることが可能である必要があります。
R6: The Path Computation Response MUST be able to carry the path of a P2MP LSP.
R6：パス計算応答は、P2MP LSPのパスを運ぶことができなければなりません。
P2MP paths can be expressed as a compressed series of routes as described in [RFC4875]. The Path Computation Response MUST be able to carry the P2MP path as either a compressed path (but not necessarily using the identical encoding as described in [RFC4875]), or as a non-compressed path comprising a series of source-to-leaf point-to-point (P2P) paths (known as S2L sub-paths).
P2MPパスは、[RFC4875]で説明されているように、圧縮された一連のルートとして表現できます。パス計算応答は、圧縮パスとしてP2MPパスを運ぶことができる必要があります（[RFC4875]で説明されているように同一のエンコードを使用するとは限らない）、または一連のソースからリーフポイントを含む非圧縮パスとして - ポイント（P2P）パス（S2Lサブパスとして知られています）。
R7: By default, the path returned by the PCE SHOULD use the compressed format.
R7：デフォルトでは、PCEによって返されるパスは圧縮形式を使用する必要があります。
The request from the PCC MAY allow the PCC to express a preference for receiving a compressed or non-compressed P2MP path in the response.
PCCからのリクエストにより、PCCは、応答で圧縮または非圧縮P2MPパスを受信することを好むことができる場合があります。
R8: A single P2MP LSP may have many destinations, and the computed path (tree) may be very extensive. In these cases, it is possible that the entire Path Computation Request or Response cannot fit within one PCE message. Therefore, it MUST be possible for a single request or response to be conveyed by a sequence of PCE messages.
R8：単一のP2MP LSPには多くの宛先がある場合があり、計算されたパス（ツリー）は非常に広範です。これらの場合、パス計算要求または応答全体が1つのPCEメッセージ内に適合できない可能性があります。したがって、一連のPCEメッセージによって単一のリクエストまたは応答を伝えることができなければなりません。
Note that there is a requirement in [RFC4657] for reliable and in-order message delivery, so it is assumed that components of the sequence will be delivered in order and without missing components.
[RFC4657]には、信頼性の高い順序的なメッセージ配信のための要件があるため、シーケンスのコンポーネントがコンポーネントが欠落していない場合に配信されると想定されていることに注意してください。
[RFC4875] requires that all branches of a single P2MP LSP have the same characteristics, and achieves this by not allowing the signaling parameters to be varied for different branches of the same P2MP LSP.
[RFC4875]では、単一のP2MP LSPのすべての分岐が同じ特性を持ち、同じP2MP LSPの異なる分岐でシグナルパラメーターを変化させないことでこれを達成する必要があります。
R9: It MUST NOT be possible to set different constraints, traffic parameters, or quality-of-service requirements for different destinations of a P2MP LSP within a single computation request.
R9：単一の計算要求内でP2MP LSPのさまざまな宛先のさまざまな制約、トラフィックパラメーター、またはサービス品質要件を設定することは不可能です。
R10: No changes are made to the requirement to support path modification and path diversity as described in [RFC4657]. Note, however, that a consequence of this requirement is that it MUST be possible to supply an existing path in a Path Computation Request. This requirement is unchanged from [RFC4657], but it is a new requirement that such paths MUST be able to be P2MP paths. The PCC MUST be able to supply these paths as compressed paths or as non-compressed paths (see Section 3.1.6) according to the preference of the PCC.
R10：[RFC4657]で説明されているように、パスの変更とパスの多様性をサポートする要件に変更は行われません。ただし、この要件の結果は、パス計算リクエストで既存のパスを供給できる必要があることに注意してください。この要件は[RFC4657]から変更されていませんが、そのようなパスがP2MPパスでなければならないことは新しい要件です。PCCは、PCCの好みに応じて、圧縮パスとして、または圧縮されていないパスとして、または圧縮されていないパスとして供給できる必要があります（セクション3.1.6を参照）。
R11: Reoptimization MUST be supported for P2MP TE LSPs as described for P2P LSPs in [RFC4657]. To support this, the existing path MUST be supplied as described in Section 3.1.9.
R11：[RFC4657]のP2P LSPについて説明されているように、P2MP TE LSPの再発現をサポートする必要があります。これをサポートするには、セクション3.1.9で説明されているように、既存のパスを提供する必要があります。
Because P2MP LSPs are more complex, it is often the case that small optimization improvements can be made after changes in network resource availability. However, re-signaling any LSP introduces risks to the stability of the service provided to the customer and the stability of the network, even when techniques like make-before-break [RFC3209] are used. Therefore, a P2MP Path Computation Request SHOULD contain a parameter that allows the PCC to express a cost-benefit reoptimization threshold for the whole LSP, as well as per destination. The setting of this parameter is subject to local policy at the PCC and SHOULD be subject to policy at the PCE [RFC5394].
P2MP LSPはより複雑であるため、ネットワークリソースの可用性の変更後に小さな最適化の改善を行うことができることがよくあります。ただし、LSPを再署名すると、Make-Be-Break [RFC3209]のような技術が使用されている場合でも、顧客に提供されるサービスの安定性とネットワークの安定性にリスクが導入されます。したがって、P2MPパス計算リクエストには、PCCがLSP全体および目的地ごとにコストベネフィットの再最適化しきい値を表現できるパラメーターを含める必要があります。このパラメーターの設定は、PCCでのローカルポリシーの対象となり、PCE [RFC5394]でポリシーの対象となる必要があります。
Path reoptimization responses SHOULD indicate which of the routes (as supplied according to Section 3.1.6) have been modified from the paths supplied in the request.
パス再最適化応答は、要求で提供されたパスから変更されたルート（セクション3.1.6に従って提供されている）を示す必要があります。
A variation of path modification described in Section 3.1.9 is that destinations may be added to, or removed from, existing P2MP TE LSPs.
セクション3.1.9で説明されているパス変更のバリエーションは、既存のP2MP TE LSPに宛先が追加または削除される可能性があることです。
In the case of the addition of one or more destinations, it is necessary to compute a path for a new branch of the P2MP LSP. It may be desirable to recompute the whole P2MP tree, to add the new branch as a simple spur from the existing tree, or to recompute part of the P2MP tree.
1つ以上の目的地が追加された場合、P2MP LSPの新しいブランチのパスを計算する必要があります。P2MPツリー全体を再計算したり、既存のツリーからの単純な拍車として新しいブランチを追加したり、P2MPツリーの一部を再計算することが望ましい場合があります。
R12: To support this function for leaf additions, it MUST be possible to make the following indications in a Path Computation Request:
R12：葉の追加のためにこの関数をサポートするには、パス計算リクエストで次の適応症を行うことができる必要があります。
- The path of an existing P2MP LSP (as described in Section 3.1.9).
- 既存のP2MP LSPの経路（セクション3.1.9で説明されています）。
- Which destinations are new additions to the tree.
- どの目的地がツリーに新たに追加されていますか。
- Which destinations of the existing tree must not have their paths modified.
- 既存のツリーのどの目的地がパスを変更してはなりません。
It MAY also be possible to indicate in a Path Computation Request a cost-benefit reoptimization threshold, such that the addition of new leaves will not cause reoptimization of the existing P2MP tree unless a certain improvement is made over simply grafting the new leaves to the existing tree. (Compare with Section 3.1.10.)
また、パス計算要求でコストベネフィットの再最適化しきい値を示すことも可能かもしれません。そのため、新しい葉を添加しても、既存の葉を既存の葉を単純に移植しない限り、既存のP2MPツリーの再最適化を引き起こすことはありません。木。（セクション3.1.10と比較してください。）
In the case of the deletion of one or more destinations, it is not necessary to compute a new path for the P2MP TE LSP, but such a computation may yield optimizations over a simple pruning of the tree. The recomputation function in this case is essentially the same as that described in Section 3.1.10, but note that it MAY be possible to supply the full previous path of the entire P2MP TE LSP (that is, before the deletion of the destinations) in the Path Computation Request.
1つ以上の目的地が削除された場合、P2MP TE LSPの新しいパスを計算する必要はありませんが、そのような計算は、ツリーの単純な剪定よりも最適化をもたらす可能性があります。この場合の再計算関数は、セクション3.1.10で説明されているものと本質的に同じですが、P2MP TE LSP（つまり、目的地の削除の前）の完全な以前のパスを供給することが可能であることに注意してください。パス計算要求。
For both addition and deletion of destinations, the Path Computation Response SHOULD indicate which of the routes (as supplied according to Section 3.1.6) have been modified from the paths supplied in the Path Computation Request, as described in Section 3.1.10.
宛先の追加と削除の両方について、パス計算応答は、セクション3.1.10で説明されているように、パス計算要求で提供されたパスから変更されたルート（セクション3.1.6に従って提供）を示す必要があります。
Note that the selection of all of these options is subject to local policy at the PCC and SHOULD be subject to policy at the PCE [RFC5394].
これらすべてのオプションの選択は、PCCでのローカルポリシーの対象であり、PCE [RFC5394]でポリシーの対象となるはずであることに注意してください。
For administrative or security reasons, or for other policy reasons, it may be desirable to limit the set of nodes within the network that may be used as branch points for a given LSP, i.e., to provide to the path computation a limiting set of nodes that can be used as branches for a P2MP path computation, or to provide a list of nodes that must not be used as branch points.
管理またはセキュリティ上の理由、または他のポリシーの理由から、特定のLSPの分岐点として使用できるネットワーク内のノードのセットを制限することが望ましい場合があります。これは、P2MPパス計算の分岐として使用すること、または分岐点として使用してはならないノードのリストを提供することができます。
R13: The PCC MUST be able to specify in a Path Computation Request a list of nodes that constitutes a limiting superset of the branch nodes for a P2MP path computation.
R13：PCCは、P2MPパス計算のブランチノードの制限スーパーセットを構成するノードのリストをパス計算リクエストで指定できる必要があります。
A PCC MUST be able to specify in a Path Computation Request a list of nodes that must not be used as branch nodes for a P2MP path computation.
PCCは、P2MPパス計算の分岐ノードとして使用してはならないノードのリストをパス計算リクエストで指定できる必要があります。
PCE capabilities exchange forms part of PCE discovery [RFC4674], but may also be included in the PCECP message exchanges [RFC4657].
PCE機能交換は、PCE発見[RFC4674]の一部を形成しますが、PCECPメッセージ交換[RFC4657]にも含まれる場合があります。
R14: The ability to perform P2MP path computation and the objective functions supported by a PCE SHOULD be advertised as part of PCE discovery. In the event that the PCE's ability to perform P2MP computation is not advertised as part of PCE discovery, the PCECP MUST allow a PCC to discover which PCEs with which it communicates support P2MP path computation, and which objective functions specific to P2MP path computation are supported by each PCE.
R14：P2MPパス計算とPCEによってサポートされる目的関数を実行する機能は、PCE発見の一部として宣伝する必要があります。P2MP計算を実行するPCEの能力がPCE発見の一部として宣伝されていない場合、PCCPはPCCがサポートP2MPパス計算を通信するPCESを発見する必要があり、P2MPパス計算に固有のどの客観的関数がサポートされているかを発見する必要があります。各PCEによって。
The list of objective functions is assumed to be coordinated with those that can be requested as described in Section 3.1.2.
目的関数のリストは、セクション3.1.2で説明されているように要求できるものと調整されると想定されています。
These requirements do not represent a change to [RFC4657], except to add more capabilities and objective functions.
これらの要件は、より多くの機能と目的機能を追加することを除いて、[RFC4657]の変更を表すものではありません。
Section 3.1.9 sets out the requirement to be able to request multiple diverse paths. Additionally, with P2MP trees, it may be that only parts of the tree can be, or need to be, diverse.
セクション3.1.9では、複数の多様なパスを要求できる要件を設定しています。さらに、P2MPツリーを使用すると、木の一部のみが多様であるか、または必要である必要がある可能性があります。
R15: The PCC SHOULD be able to request a PCE to compute a secondary P2MP path tree with partial path diversity for specific leaves or a specific S2L sub-path.
R15：PCCは、特定の葉または特定のS2Lサブパスの部分的なパスの多様性を備えた二次P2MPパスツリーを計算するようにPCEを要求できるはずです。
PCE implementations MAY provide a configuration switch to allow support of P2MP MPLS TE computations to be enabled or disabled. When the level of support is changed, this SHOULD be re-advertised as described in Section 3.1.13.
PCE実装では、P2MP MPLS TE計算のサポートを有効または無効にするための構成スイッチを提供する場合があります。サポートのレベルが変更されると、セクション3.1.13で説明されているように、これを再承認する必要があります。
Support for, and advertisement of support for, P2MP MPLS TE path computation MAY be subject to policy, and a PCE MAY hide its P2MP capabilities from certain PCCs by not advertising them through the discovery protocol and not reporting them to the specific PCCs in any PCECP capabilities exchange. Further, a PCE MAY be directed by policy to refuse a P2MP path computation for any reason including, but not limited to, the identity of the PCC that makes the request.
P2MP MPLS TEパス計算のサポートとサポートの広告はポリシーの対象となる可能性があり、PCEはディスカバリープロトコルを通じてそれらを宣伝せず、PCECPで特定のPCCに報告しないことにより、特定のPCCからそのP2MP機能を隠すことができます機能交換。さらに、PCEは、要求を行うPCCのIDを含むがこれらに限定されない、何らかの理由でP2MPパス計算を拒否するためのポリシーによって指示される場合があります。
PCECP protocol extensions to support P2MP MPLS TE SHOULD be accompanied by MIB objects for the control and monitoring of the protocol and the PCE that performs the computations. The MIB objects MAY be provided in the same MIB module as used for general PCECP control and monitoring or MAY be provided in a new MIB module.
P2MP MPLS TEをサポートするPCECPプロトコル拡張には、計算を実行するプロトコルとPCEの制御と監視のためにMIBオブジェクトを添付する必要があります。MIBオブジェクトは、一般的なPCECP制御と監視に使用されるのと同じMIBモジュールで提供されるか、新しいMIBモジュールで提供される場合があります。
The MIB objects SHOULD provide the ability to control and monitor all aspects of PCECP relevant to P2MP MPLS TE path computation.
MIBオブジェクトは、P2MP MPLS TEパス計算に関連するPCECPのすべての側面を制御および監視する機能を提供する必要があります。
No changes are necessary to the liveness detection and monitoring requirements as already embodied in [RFC4657]. However, it should be noted that, in general, P2MP computations are likely to take longer than P2P computations. The liveness detection and monitoring features of the PCECP SHOULD take this into account.
[RFC4657]ですでに具体化されているように、活性検出および監視要件には変更は必要ありません。ただし、一般に、P2MP計算にはP2P計算よりも時間がかかる可能性が高いことに注意してください。PCECPの活性検出と監視機能を考慮に入れる必要があります。
There are no additional requirements beyond those expressed in [RFC4657] for verifying the correct operation of the PCECP. Note that verification of the correct operation of the PCE and its algorithms is out of scope for the protocol requirements, but a PCC MAY send the same request to more than one PCE and compare the results.
PCECPの正しい動作を検証するために、[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 LSP, the topology graph must include information about the P2MP signaling and branching capabilities of each LSR in the network.
PCEは、ネットワーク内で動作するルーティングプロトコルにTE拡張機能によって分散された情報を使用して構築できるトポロジグラフで動作します。PCEがP2MP LSPのインストールに使用するシグナル伝達プロトコルの適切なパスを選択できるため、トポロジグラフには、ネットワーク内の各LSRのP2MPシグナル伝達と分岐機能に関する情報を含める必要があります。
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.
P2MPパスを計算するためにPCEを使用することは、ネットワーク操作に大きな影響を与えるとは予想されていません。ただし、P2Pパス計算を既に提供しているPCEへのP2MPサポートの導入は、PCEの負荷が大幅に変化する可能性があり、特にネットワーク障害直後の回復期間中にネットワークの動作に影響を与える可能性があることに注意してください。。
P2MP computation requests do not raise any additional security issues for the PCECP, as there are no new messages and no new PCC-PCE relationships or transactions introduced.
P2MP計算要求は、新しいメッセージがなく、新しいPCC-PCE関係やトランザクションが導入されていないため、PCECPの追加のセキュリティ問題を提起しません。
Note, however, that P2MP computation requests are more CPU-intensive and also use more link bandwidth. Therefore, if the PCECP was susceptible to denial of service attacks based on the injection of spurious Path Computation Requests, the support of P2MP path computation would exacerbate the effect.
ただし、P2MP計算要求はCPU集約型であり、より多くのリンク帯域幅を使用することに注意してください。したがって、PCECPがスプリアスパス計算要求の注入に基づいてサービス拒否攻撃の影響を受けやすい場合、P2MPパス計算のサポートは効果を悪化させます。
It would be possible to consider applying different authorization policies for P2MP Path Computation Requests compared to other requests.
他の要求と比較して、P2MPパス計算要求に異なる承認ポリシーを適用することを検討することができます。
Thanks to Dean Cheng, Young Lee, Quintin Zhao, Daniel King, Fabien Verhaeghe, and Francis Dupont for their comments and suggestions on this document.
ディーン・チェン、ヤング・リー、Quintin Zhao、Daniel King、Fabien Verhaeghe、およびFrancis Dupontに、この文書に関するコメントと提案に感謝します。
[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月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657] Ash、J.、ed。、およびJ. Le Roux、ed。、「Path Computation Element（PCE）通信プロトコルジェネリック要件」、RFC 4657、2006年9月。
[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、「ポリシー対応パス計算フレームワーク」、RFC 5394、2008年12月。
[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。、「Path-to-Multipoint（P2MP）MPLSおよびGMPLSトラフィックエンジニアリング（TE）へのパス計算要素（PCE）の適用可能性」、RFC 5671、2009年10月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、 "RSVP-TE：LSP TunnelsのRSVPへの拡張"、RFC 3209、12月2001年。
[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、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674] Le Roux、J.、ed。、「Path Computation Element（PCE）Discoveryの要件」、RFC 4674、2006年10月。
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[RFC4834] Morin、T.、ed。、「レイヤー3プロバイダープロビジョニング仮想ネットワーク（PPVPNS）のマルチキャストの要件」、RFC 4834、2007年4月。
[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。、ed。、Papadimitriou、D.、ed。、およびS. Yasukawa、ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルの交通工学（RSVP-TE）スイッチPaths（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ルーティングプロトコル拡張」、RFC 5073、2007年12月。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC5541] Le Roux、Jl。、Vasseur、Jp。、およびY. Lee、「パス計算要素通信プロトコル（PCEP）における目的関数のエンコード」、RFC 5541、2009年6月。
Authors' Addresses
著者のアドレス
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 JAPAN EMail: yasukawa.seisho@lab.ntt.co.jp
Seisho Yasukawa NTT Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585日本メール：Yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk