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
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.
経路計算エレメント（PCE）マルチプロトコルラベルスイッチング（MPLS）と一般化MPLS（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.
一般的なパス計算クライアント間の通信プロトコルのための要件（のPCC）とのPCEは、RFC 4657に提示されている、「パス計算要素（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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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 TE MPLSネットワークは、レイヤ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].
この文書では、PCC-PCE通信プロトコル（PCECP）P2MP MPLSトラフィックエンジニアリングのための要件のセットを提示します。これは、[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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
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：のPCEは、P2MPの経路計算をサポートする必要はありません。 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.
初期のPCEの実装はP2MPの経路計算のためのサポートなしで、セクション3.1.1で説明明示的なパラメータを認識する能力なしに開発される可能性があります。このような従来の実装は、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経路計算要求メッセージに含めるために必要な少なくとも一つのパラメータは、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).
[RFC4875]に記載されているようにP2MP経路は経路の圧縮された一連のように表すことができます。パス計算応答（[RFC4875]に記載されているように、必ずしも同一の符号を使用していない）圧縮パスのいずれかとしてP2MP経路を運ぶことができ、または非圧縮パスとしてソースツーリーフポイントのシリーズを含むMUST （S2Lサブ経路としても知られる）-to-ポイント（P2P）パス。
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.
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].
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).
- 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.6に従って供給されるように）セクション3.1.10に記載されているように、経路計算要求に供給されるパスから変更された経路のかを示すべきです。
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.
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発見の一部として宣伝されていない場合には、PCECPはP2MPの経路計算に特定の目的の機能がサポートされているか、それがサポートP2MPの経路計算を通信するのPCEなどを発見するためにPCCを許容しなければなりません各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能力を隠してもよい（MAY）機能交換。さらに、PCEは、以下を含む何らかの理由P2MPの経路計算を拒否するようにポリシーが監督、これらに限定されないが、要求を行うPCCのアイデンティティかもしれません。
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オブジェクトが付随されるべきです。一般PCECP制御および監視するために使用されるか、または新たなMIBモジュール内に設けることができるように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をインストールするために使用するシグナリングプロトコルに適した経路を選択することができるようにするために、トポロジ・グラフは、P2MPは、ネットワーク内の各LSRの能力をシグナリングおよび分岐に関する情報を含まなければなりません。
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.
導入された新しいメッセージと新しいPCC-PCE関係や取引が存在しないようP2MP計算要求は、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の趙、ダニエル・キング、ファビアンVerhaeghe、フランシスデュポンに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]アッシュ、J.、エド。、およびJ.ル・ルー、エド。、 "パス計算要素（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.、バーガー、L.、およびJ.アッシュ、 "政策対応の経路計算フレームワーク"、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]安川、S.およびA.ファレル、エド。、RFC 5671、2009年10月、 "ポイント・ツー・マルチポイントにする（P2MP）MPLSおよびGMPLSトラフィックエンジニアリング（TE）のパス計算要素（PCE）の適用"。
[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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのための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]安川、S.、エド。、2006 4月には、RFC 4461、「ポイントツーマルチポイントトラフィック・エンジニアMPLSラベルのためのシグナリング要件は、スイッチパス（LSP）」。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]ル・ルー、J.、エド。、RFC 4674、2006年10月 "経路計算エレメント（PCE）の発見のための要件"。
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[RFC4834]モリン、T.、エド。、 "レイヤーでのマルチキャストのための要件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]アガルワルは、R.、エド、Papadimitriou、D.、エド、およびS.安川、エド、「リソース予約プロトコルへの拡張 - 。。。は、ポイント・ツー・マルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）は、スイッチパス（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.、エド。、およびJ.ル・ルー、エド。、 "トラフィックエンジニアリングノード能力の発見のための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]ル・ルー、JL。、Vasseur、JP。、およびY.リー、 "パス計算要素通信プロトコル（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
せいしょ やすかわ んっｔ こｒぽらちおん ９ー１１、 みどりーちょ ３ーちょめ むさしのーし、 ときょ １８０ー８５８５ じゃぱん えまいｌ： やすかわ。せいしょ＠ぁｂ。んっｔ。こ。ｊｐ
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk