Network Working Group S. Yasukawa
Request for Comments: 5671 NTT
Category: Informational A. Farrel, Ed.
Old Dog Consulting
October 2009
Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)
経路計算エレメント（PCE）の適用は、ポイントツーマルチポイント（P2MP）MPLSおよびGMPLSトラフィックエンジニアリング（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).
MPLSおよびGMPLSシグナリングおよびルーティングプロトコルの拡張は、ポイント・ツー・マルチポイントのサポートで行われている（P2MP）トラフィックエンジニア（TE）ラベルスイッチパス（LSP）。
This document examines the applicability of PCE to path computation for P2MP TE LSPs in MPLS and GMPLS networks. It describes the motivation for using a PCE to compute these paths and examines which of the PCE architectural models are appropriate.
この文書では、MPLSにおけるP2MP TE LSPをとGMPLSネットワークのための経路計算にPCEの適用性を検証します。それは、建築モデルが適切であるPCEのこれらのパスとが調べを計算するPCEを使用するための動機を記載しています。
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 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 BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Architectural Considerations ....................................4
2.1. Offline Computation ........................................4
2.2. Online Computation .........................................4
2.2.1. LSR Loading .........................................5
2.2.2. PCE Overload ........................................6
2.2.3. PCE Capabilities ....................................6
3. Fragmenting the P2MP Tree .......................................7
4. Central Replication Points ......................................8
5. Reoptimization and Modification .................................9
6. Repair .........................................................10
7. Disjoint Paths .................................................11
8. Manageability Considerations ...................................11
8.1. Control of Function and Policy ............................11
8.2. Information and Data Models ...............................11
8.3. Liveness Detection and Monitoring .........................12
8.4. Verifying Correct Operation ...............................12
8.5. Requirements on Other Protocols and Functional
Components ................................................12
8.6. Impact on Network Operation ...............................13
9. Security Considerations ........................................13
10. Acknowledgments ...............................................13
11. References ....................................................13
11.1. Normative References .....................................13
11.2. Informative References ...................................13
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 of 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を）パスのスイッチドトラフィックエンジニアのパスを計算するために使用されていることです。
[RFC4655] defines various deployment models that place PCEs differently within the network. The PCEs may be collocated with the Label Switching Routers (LSRs), may be part of the management system that requests the LSPs to be established, or may be positioned as one or more computation servers within the network.
[RFC4655]は、異なるネットワーク内のPCEを置き、さまざまな展開モデルを定義します。 PCEは、ラベルスイッチングルータ（LSRの）と一緒に配置することができる、確立されるLSPを要求管理システムの一部であってもよく、又はネットワーク内の1つまたは複数の計算サーバとして配置することができます。
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]. In this
ポイントツーマルチポイント（P2MP）MPLS TE LSPのための要件は、[RFC4461]に記載されていて、P2MP MPLS TE LSPを設定するためのプロトコル拡張をシグナリングは[RFC4875]で定義されています。この中
document, P2MP MPLS TE networks are considered in support of various features including layer 3 multicast VPNs [RFC4834], video distribution, etc.
文書は、P2MP TE MPLSネットワークは、レイヤ3つのマルチキャストVPNの[RFC4834]、映像配信などを含む様々な機能をサポートするために考慮されます
Fundamental to the determination of the paths for P2MP LSPs within a network is the selection of branch points. Not only is this selection constrained by the network topology and available network resources, but it is determined by the objective functions that may be applied to path computation. For example, one standard objective is to minimize the total cost of the tree (that is, to minimize the sum of the costs of each link traversed by the tree) to produce what is known as a Steiner tree. Another common objective function requires that the cost to reach each leaf of the P2MP tree be minimized.
ネットワーク内のP2MP LSPのためのパスの決意に基本的には、分岐点の選択です。のみならず、ネットワークトポロジおよび使用可能なネットワークリソースによって制約この選択であるが、経路計算に適用することができる目的関数によって決定されます。例えば、一つの標準的な目的は、スタイナー木として知られるものを生成するために（ツリーによって横断各リンクのコストの和を最小にするために、つまり）ツリーの総コストを最小化することです。他の一般的な目的関数は、P2MPツリーの各リーフに到達するためのコストが最小化されている必要があります。
The selection of branch points within the network is further complicated by the fact that not all LSRs in the network are necessarily capable of performing branching functions. This information may be recorded in the Traffic Engineering Database (TED) that the PCE uses to perform its computations, and may have been distributed using extensions to the Interior Gateway Protocol (IGP) operating within the network [RFC5073].
ネットワーク内の分岐点の選択は、さらに、ネットワーク内の全てのLSRは、必ずしも分岐機能を実行することが可能であるという事実によって複雑になります。この情報は、PCEは、その計算を実行するために使用し、内部ゲートウェイプロトコル（IGP）ネットワーク内で動作する[RFC5073]の拡張機能を使用して分散されていることをトラフィックエンジニアリングデータベース（TED）に記録されてもよいです。
Additionally, network policies may dictate specific branching behavior. For example, it may be decided that, for certain types of LSPs in certain types of networks, it is important that no branch LSR is responsible for handling more than a certain number of downstream branches for any one LSP. This might arise because the replication mechanism used at the LSRs is a round-robin copying process that delays the data transmission on each downstream branch by the time taken to replicate the data onto each previous downstream branch. Alternatively, administrative policies may dictate that replication should be concentrated on specific key replication nodes behaving like IP multicast rendezvous points (perhaps to ensure appropriate policing of receivers in the P2MP tree, or perhaps to make protection and resiliency easier to implement).
また、ネットワークポリシーは、特定の分岐動作を指示することができます。例えば、ネットワークの特定の種類におけるLSPの特定の種類のために、ブランチLSRは、いずれかのLSPのための下流の枝の一定数以上を処理する責任を負っていることが重要である、と判断することができます。 LSRで使用、複製メカニズムはそれぞれ、前の下流分岐上にデータを複製するのに要する時間によって各下流分岐上のデータ伝送を遅らせるラウンドロビンコピー処理であるため、これが発生する可能性があります。また、管理ポリシーは、その複製を指示することができるIPマルチキャストランデブーポイント（おそらくP2MPツリー内の受信機の適切なポリシングを確保するために、またはおそらく実装するの保護と回復力を容易にするために）ように振る舞う特定のキーの複製ノードに集中する必要があります。
Path computation for P2MP TE LSPs presents a significant challenge because of the complexity of the computations described above. Determining disjoint protection paths for P2MP TE LSPs can add considerably to this complexity, while small modifications to a P2MP tree (such as adding or removing just one leaf) can completely change the optimal path. Reoptimization of a network containing multiple P2MP TE LSPs requires considerable computational resources. All of this means that an ingress LSR might not have sufficient processing power to perform the necessary computations, and even if it does, the act of path computation might interfere with the control and management plane operation necessary to maintain existing LSPs. The PCE architecture offers a way to offload such path computations from LSRs.
P2MP TE LSPのための経路計算があるため、上記の計算の複雑さの重要な課題を提示しています。 （そのようなちょうど1つのリーフを追加または削除など）P2MPツリーに小さな修正が完全に最適経路を変更することができながら、P2MP TE LSPのためばらばら保護パスを決定することは、この複雑さを大幅に追加することができます。複数のP2MP TE LSPを含むネットワークの再最適化は、かなりの計算リソースを必要とします。このすべては、入口LSRは、必要な計算を実行するための十分な処理能力を持っていない可能性があり、それがない場合でも、経路計算の行為は、既存のLSPを維持するのに必要な制御および管理プレーンの動作を妨げる可能性があることを意味します。 PCEアーキテクチャは、LSRのから、このようなパス計算をオフロードする方法を提供しています。
Offline path computation is performed ahead of time, before the LSP setup is requested. That means that it is requested by, or performed as part of, a management application. This model can be seen in Section 5.5 of [RFC4655].
LSPの設定が要求される前に、オフラインの経路計算は、事前に行われます。すなわち、によって要求、または管理アプリケーションの一部として実行されることを意味します。このモデルは、[RFC4655]の5.5節で見ることができます。
The offline model is particularly appropriate to long-lived LSPs (such as those present in a transport network) or for planned responses to network failures. In these scenarios, more planning is normally a feature of LSP provisioning.
オフラインモデル（例えば、トランスポートネットワーク内に存在するものなど）、またはネットワーク障害への計画応答の長寿命のLSPに特に適しています。これらのシナリオでは、より多くの計画が正常にLSPのプロビジョニングの機能です。
This model may also be used where the network operator wishes to retain full manual control of the placement of LSPs, using the PCE only as a computation tool to assist the operator, not as part of an automated network.
ネットワークオペレータは、だけでなく、自動化ネットワークの一部として、オペレータを支援する計算ツールとしてPCEを使用して、LSPの配置の完全な手動制御を保持したい場合に、このモデルを使用してもよいです。
Offline path computation may be applied as a background activity for network reoptimization to determine whether and when the current LSP placements are significantly sub-optimal. See Section 5 for further discussions of reoptimization.
オフライン経路計算は、現在のLSPのプレースメントが有意サブ最適であるかどうか、および時期を決定するために、ネットワークの再最適化のためのバックグラウンドアクティビティとして適用することができます。再最適化のさらなる議論については、セクション5を参照してください。
Online path computation is performed on-demand as LSRs in the network determine that they need to know the paths to use for LSPs. Thus, each computation is triggered by a request from an LSR.
ネットワーク内のLSRは、彼らがLSPのために使用するパスを知っておく必要があると判断するとオンライン経路計算は、オンデマンドで実行されます。したがって、各計算がLSRからの要求によってトリガされます。
As described in [RFC4655], the path computation function for online computation may be collocated with the LSR that makes the request, or it may be present in a computation-capable PCE server within the network. The PCE server may be another LSR in the network, a dedicated server, or a functional component of a Network Management System (NMS). Furthermore, the computation is not necessarily achieved by a single PCE operating on its own, but may be the result of cooperation between several PCEs.
[RFC4655]に記載されているように、オンライン計算のための経路計算機能は、要求を行うLSRと一緒に配置されてもよく、またはそれは、ネットワーク内の計算可能なPCEサーバに存在してもよいです。 PCEサーバは、ネットワーク内の別のLSR、専用サーバ、またはネットワーク管理システム（NMS）の機能的な構成要素であってもよいです。さらに、計算は、必ずしもそれ自体で動作する単一のPCEによって達成されていないが、いくつかのPCEとの間の協働の結果であり得ます。
The remainder of this document makes frequent reference to these different online models in order to indicate which is more appropriate in different P2MP scenarios.
このドキュメントの残りは異なるP2MPシナリオでより適切であるかを示すために、これらの異なるオンラインのモデルを頻繁に参照します。
An important feature of P2MP path computation is the processing load that it places on the network element that is determining the path. Roughly speaking, the load to compute a least-cost-to-leaf tree is the same as the cost to compute a single optimal path to each leaf in turn. The load to compute a Steiner tree is approximately an order of magnitude greater, although algorithms exist to approximate Steiner trees in roughly the same order of magnitude of time as for a least-cost-to-leaf tree.
P2MPの経路計算の重要な特徴は、それがパスを決定されたネットワーク要素に置く処理負荷です。大雑把に言えば、最小コスト・ツー・葉の木を計算するための負荷が順番に各リーフへの単一の最適経路を計算するためのコストと同じです。アルゴリズムは、最小コスト・ツー・リーフツリーのような時間の大きさとほぼ同じ順序でスタイナーツリーを近似するために存在するがスタイナー木を計算する負荷は、約大きさ以上のオーダーです。
Whereas many LSRs are capable of simple Constrained Shortest Path First (CSPF) computations to determine a path for a single point-to-point (P2P) LSP, they rapidly become swamped if called on to perform multiple such computations, such as when recovering from a network failure. Thus, it is reasonable to expect that an LSR would struggle to handle a P2MP path computation for a tree with many destinations.
多くのLSRは、単一のポイントツーポイント（P2P）LSPのためのパスを決定するための単純な制約付き最短パス優先（CSPF）の計算が可能である一方、それらは急速にかかるから回復するときのように、複数のそのような計算を実行するために呼び出された場合圧倒なりますネットワーク障害。したがって、LSRは、多くの都市でツリーのP2MPの経路計算を処理するために苦労するだろうと予想するのが妥当です。
The result of an LSR becoming overloaded by a P2MP path computation may be two-fold. First, the LSR may be unable to provide timely computations of paths for P2P LSPs; this may impact LSP setup times for simple demand-based services and could damage the LSR's ability to recover services after network faults. Secondly, the LSR's processing capabilities may be diverted from other important tasks, not the least of which is maintaining the control plane protocols that are necessary to the support of existing LSPs and forwarding state within the network. It is obviously critically important that existing traffic should not be disrupted by the computation of a path for a new LSP.
P2MP経路計算によって過負荷になるLSRの結果は、二倍であってもよいです。まず、LSRは、P2PのLSPのためのパスのタイムリーな計算を提供することができません。これは、単純な需要ベースのサービスのためのLSP設定時間に影響を与える可能性があるし、ネットワーク障害の後にサービスを回復するLSRの能力を損傷する恐れがあります。第二に、LSRの処理能力は、既存のLSPのサポートに必要な制御プレーン・プロトコルを維持し、ネットワーク内の状態を転送していない少なくともそのうち、他の重要なタスクから分流されてもよいです。既存のトラフィックが新しいLSPのパスの計算によって破壊されるべきでないことを明らかに非常に重要です。
It is also not reasonable to expect the ingress LSRs of P2MP LSRs to be specially powerful and capable of P2MP computations. Although a solution to the overloading problem would be to require that all LSRs that form the ingresses to P2MP LSPs be sufficiently high-capacity to perform P2MP computations, this is not an acceptable solution because, in all other senses, the ingress to a P2MP LSP is just a normal ingress LSR.
P2MPのLSRの入口のLSRは、特別に強力で、P2MPの計算が可能であることを期待しても合理的ではありません。過負荷の問題に対する解決策は、P2MPのLSPにingressesを構成する全てのLSRは、P2MP計算を実行するために十分に大容量であることを必要とするであろうが、これは、他のすべての意味で、入力P2MP LSPに許容される解決策ではありません普通のイングレスLSRです。
Thus, there is an obvious solution: off-load P2MP path computations from LSRs to remotely located PCEs. Such PCE function can be provided on dedicated or high-capacity network elements (such as dedicated servers, or high-end routers that might be located as Autonomous System Border Routers - ASBRs).
遠隔のPCEを配置するためのLSRからオフロードP2MP経路計算：このように、明白な解決策があります。そのようなPCE機能（ - ASBRは、専用サーバ、または自律システム境界ルータとして配置されるかもしれないハイエンドルータなど）専用又は大容量のネットワーク要素に設けることができます。
Since P2MP path computations are resource-intensive, it may be that the introduction of P2MP LSPs into an established PCE network will cause overload at the PCEs. That is, the P2MP computations may block other P2P computations and might even overload the PCE.
P2MP経路計算はリソース集約的であるので、それは、確立されたPCEのネットワークへのP2MP LSPの導入のPCEで過負荷の原因となることがあってもよいです。すなわち、P2MP計算は、他のP2P計算をブロックすることがあり、さらにPCEをオーバーロード可能性があります。
Several measures can be taken within the PCE architecture to alleviate this situation as described in [RFC4655]. For example, path computation requests can be assigned priorities by the LSRs that issue them. Thus, the LSRs could assign lower priority to the P2MP requests, ensuring that P2P requests were serviced in preference. Furthermore, the PCEs are able to apply local and network-wide policy and this may dictate specific processing rules [RFC5394].
いくつかの対策が[RFC4655]に記載されているように、この状況を緩和するPCEアーキテクチャ内で取ることができます。例えば、経路計算要求は、それらを発行するのLSRによって優先順位を割り当てることができます。したがって、のLSRは、P2P要求が優先してサービスされたことを確認して、P2MP要求に低い優先順位を割り当てることができます。さらに、のPCEは、ローカルおよびネットワーク全体のポリシーを適用することができ、これは、特定の処理規則[RFC5394]を決定してもよいです。
But ultimately, a network must possess sufficient path computation resources for its needs and this is achieved within the PCE architecture simply by increasing the number of PCEs.
しかし、最終的には、ネットワークは、そのニーズに十分な経路計算リソースを持っている必要があり、これは単にのPCEの数を増やすことにより、PCEアーキテクチャ内で達成されます。
Once there are sufficient PCEs available within the network, the LSRs may choose between them and may use overload notification information supplied by the PCEs to spot which PCEs are currently over-loaded. Additionally, a PCE that is becoming over-loaded may redistribute its queue of computation requests (using the PCE cooperation model described in [RFC4655]) to other, less burdened PCEs within the network.
ネットワーク内で利用可能な十分なのPCEがあるならば、LSRには、それらの間を選択することができ、オーバーロードされ、現在であるのPCE発見するのPCEから供給される過負荷通知情報を使用することができます。また、オーバーロードされてなりつつあるPCEは、ネットワーク内の他の、あまり負担のPCEに（[RFC4655]に記載PCE協力モデルを使用して）計算要求のそのキューを再配布してもよいです。
An LSR chooses between available PCEs to select the one most likely to be able to perform the requested path computation. This selection may be based on overload notifications from the PCEs, but could also consider other computational capabilities.
LSRは、要求された経路計算を実行することができる可能性が最も高いものを選択することが可能なのPCEの間で選択します。この選択は、のPCEからの過負荷通知に基づいてもよいが、他の計算能力を検討することができます。
For example, it is quite likely that only a subset of the PCEs in the network have the ability to perform P2MP computations since this requires advanced functionality. Some of those PCEs might have the ability to satisfy certain objective functions (for example, least cost to destination), but lack support for other objective functions (for example, Steiner). Additionally, some PCEs might not be capable of the more complex P2MP reoptimization functionality.
例えば、ネットワーク内のPCEのサブセットのみが、これは高度な機能を必要とするため、P2MPの計算を実行する能力を持っている可能性が極めて高いです。これらのPCEの一部は、特定の目的関数を満足させる能力（先に例えば、最低コスト）が、他の目的関数のための不足のサポート（例えば、シュタイナー）を持っているかもしれません。さらに、いくつかのPCEは、より複雑なP2MPの再最適化機能することができない場合があります。
The PCE architecture allows an LSR to discover the capabilities of the PCEs within the network at the same time it discovers their existence. Further and more detailed exchanges of PCE capabilities can be made directly between the PCEs and the LSRs. This exchange of PCE capabilities information allows a Path Computation Client (PCC) to select the PCE that can best answer its computation requests.
PCEアーキテクチャは、LSRが、それは彼らの存在を発見すると同時に、ネットワーク内のPCEの能力を発見することができます。 PCE能力のさらなる、より詳細な交換はのPCEとのLSR間で直接行うことができます。 PCE能力情報のこの交換は、パス計算クライアント（PCC）が最高その計算要求に答えることができPCEを選択することができます。
A way to reduce the computational burden of computing a large P2MP tree on a single PCE is to fragment or partition the tree. This may be particularly obvious in a multi-domain network (such as multiple routing areas), but is equally applicable in a single domain.
単一PCEに大きなP2MPツリーを計算する計算上の負担を軽減するための方法は、フラグメントまたはツリーを分割することです。これは、（例えば、複数のルーティングエリアのような）マルチドメインネットワークにおいて特に明らかであるが、単一のドメインでも同様に適用することができます。
Consider the network topology in Figure 1. A P2MP LSP is required from ingress LSR A to egress LSRs s, t, u, v, w, x, y, and z. Using a single PCE model, LSR A may request the entire path of the tree and this may be supplied by the PCE. Alternatively, the PCE that is consulted by LSR A may only compute the first fragment of the tree (for example, from A to K, L, and M) and may rely on other PCEs to compute the three smaller trees from K to t, u, and v; from L to w and x; and from M to s, y, and z.
図1のA P2MP LSPにおけるネットワークトポロジを検討する出口LSRsのS、T、U、V、W、X、Y、及びZに入口LSR Aから要求されます。単一PCEモデルを使用して、LSR Aは、ツリーの全体のパスを要求することができ、これは、PCEによって供給されてもよいです。あるいは、LSR Aによって参照されるPCEのみ（K、L、及びMから、例えば）ツリーの最初のフラグメントを計算してもよいし、tにKから3本の小さな木を計算するために、他のPCEに頼ることができます、 U、およびV; WおよびXのLから。そしてMからS、yおよびzです。
The LSR consulted by A may simply return the first subtree and leave LSRs K, L, and M to invoke PCEs in their turn in order to complete the signaling. Alternatively, the first PCE may cooperate with other PCEs to collect the paths for the later subtrees and return them in a single computation response to PCE A. The mechanisms for both of these approaches are described in the PCE architecture [RFC4655].
Aによって相談LSRは、単に最初のサブツリーを返すとシグナリングを完了するために自分の順番でのPCEを呼び出すためのLSR K、L、及びMを残すことができます。あるいは、最初のPCEは、後でサブツリーのパスを収集し、これらのアプローチの両方のためのメカニズムは、PCEアーキテクチャ[RFC4655]に記載されているPCE Aに単一の計算応答にそれらを戻すために、他のPCEと協働することができます。
t
/
/
n--u
/
/
e--f--h--K--o--v
/
/
A--b--c--d--g--i--L--p--w
\ \
\ \
j x
\
\
M--r--y
\ \
\ \
s z
Figure 1: A P2MP Tree with Intermediate Computation Points
図1：中間計算ポイントとP2MPツリー
A further possibility is that LSRs at which the subtrees are stitched together (K, L, and M in this example) are selected from a set of potential such points using a cooperative PCE technique, such as the Backward Recursive Path Computation (BRPC) mechanism [RFC5441]. Indeed, if LSRs K, L, and M were ASBRs or Area Border Routers (ABRs), the BRPC technique would be particularly applicable.
さらなる可能性は、サブツリーは、（この例ではK、L、およびM）を一緒に縫合されるのLSRは、このような後方再帰パス計算（BRPC）メカニズムとして、協調PCE技術を使用して潜在的なこのような点の集合から選択されることです[RFC5441]。 LSR K、L、及びMは、のASBRまたはエリア境界ルータ（のABR）であれば実際に、BRPC技術が特に適用可能であろう。
Note, however, that while these mechanisms are superficially beneficial, it is far from obvious how the first LSR selects the transit LSRs K, L, and M, or how the leaf nodes are assigned to be downstream of particular downstream nodes. The computation to determine these questions may be no less intensive than the determination of the full tree unless there is some known property of the leaf node identifiers such as might be provided by address aggregation.
ただし、これらのメカニズムは、表面的に有益であるが、それは最初のLSRがリーフノードが特定の下流ノードの下流に割り当て方法トランジットのLSR K、L、及びMを選択し、又はどの程度明らかであること。このようなアドレス集合によって提供されるかもしれないようなリーフノード識別子のいくつかの既知のプロパティがない限り、これらの質問を決定するための計算は、完全なツリーの決意以上で集中しなくてもよいです。
A deployment model for P2MP LSPs is to use centralized, well-known replication points. This choice may be made for administrative or security reasons, or because of particular hardware capability limitations within the network. Indeed, this deployment model can be achieved using P2P LSPs between ingress and replication point as well as between replication point and each leaf so as to achieve a P2MP service without the use of P2MP MPLS-TE.
P2MP LSPのための配置モデルは、集中、よく知られたレプリケーション・ポイントを使用することです。この選択は、管理者またはセキュリティ上の理由のために作られた、またはので、ネットワーク内の特定のハードウェア機能の制限することができます。確かに、この展開モデルは、P2MP MPLS-TEを使用せずにP2MPサービスを実現するように入口およびレプリケーションポイントの間だけでなく、複製点と各葉の間にP2PのLSPを使用して達成することができます。
The motivations for this type of deployment are beyond the scope of this document, but it is appropriate to examine how PCE might be used to support this model.
このタイプの配置のための動機は、このドキュメントの範囲を超えていますが、PCEがこのモデルをサポートするために使用されるかもしれない方法を検討することが適当です。
In Figure 2, a P2MP service is required from ingress LSR a to egress LSRs m, n, o, and p. There are four replication-capable LSRs in the network: D, E, J, and K.
図2では、P2MPサービスは、入口LSRから出口LSRsのM、N、O、およびPが要求されます。 D、E、J、およびK.：ネットワークの4つの複製可能なのLSRがあります。
When LSR a consults a PCE, it could be given the full P2MP path from LSR a to the leaves, but in this model, the PCE simply returns a P2P path to the first replication point (in this case, LSR D). LSR D will consult a PCE in its turn and determine the P2P LSPs to egress LSRs m and p as well as the P2P LSP to the next replication point, LSR J. Finally, LSR J will use a PCE to determine P2P LSPs to egresses n and o.
LSR aはPCEを参照するとき、それは葉にLSRから完全P2MP経路を与えることができるが、このモデルでは、PCEは、単に（この場合、LSR D）第一の複製点へP2P経路を返します。 LSR Dが順番にPCEに相談し、出口LSRsのmおよびpならびに次複製点にP2P LSPへのP2P LSPを決定する、LSR J.最後に、LSR Jは、N egressesへのP2P LSPを決定するPCEを使用しますそして、O。
f--i--m
/
/
a--b--c--D--g--J--n
\ \
\ \
E h K o
\
\
l--p
Figure 2: Using Centralized Replication Points
図2：中央集中型レプリケーションポイントの使用
In this model of operation, it is quite likely that the PCE function is located at the replication points, which will be high-capacity LSRs. One of the main features of the computation activity is the selection of the replication points (for example, why is LSR D selected in preference to LSR E, and why is LSR J chosen over LSR K?). This selection may be made solely on the basis of path optimization as it would be for a P2MP computation, but may also be influenced by policy issues (for example, LSR D may be able to give better security to protect against rogue leaf attachment) or network loading concerns (for example, LSR E may already be handling a very large amount of traffic replication for other P2MP services).
操作のこのモデルでは、大容量のLSRされる、PCE機能が複製点に配置されていることは非常に可能性があります。計算活動の主な特徴の一つは、複製点の選択（例えば、なぜLSR DはLSR Eに優先して選択され、なぜLSR K上に選択されたLSR Jは？）です。この選択は、（例えば、LSR Dは、不正な葉の添付ファイルから保護するために、より良いセキュリティを与えることができる場合があります）、それはP2MP計算のためになるとしてのみパスの最適化に基づいて行われてもよいが、政策問題によって影響され得ますか、ネットワーク負荷の懸念が（例えば、LSR Eは、既に他のP2MPサービスのトラフィックの複製の非常に大きな金額を扱うこともあります）。
Once established, P2MP LSPs are more sensitive to modification than their P2P counterparts. If an egress is removed from a P2P LSP, the whole LSP is torn down. But egresses may be added to and removed from active P2MP LSPs as receivers come and go.
一度確立し、P2MPのLSPは、そのP2Pの対応よりも修正に敏感です。出口は、P2P LSPから削除された場合、全体のLSPが取り壊されます。しかしegressesは、に加えて、受信機が来て、行くようにアクティブP2MPのLSPをから除去することができます。
The removal of an egress from a P2MP LSP does not require any new path computation since the tree can be automatically pruned.
ツリーが自動的に剪定することができますので、P2MP LSPからの出口の除去は、任意の新しい経路計算を必要としません。
The addition of a new egress to a P2MP LSP can be handled as the computation of an appropriate branch point and the determination of a P2P path from the branch point to the new egress. This is a relatively simple computation and can be achieved by reverse-path CSPF, much as in the manner of some multicast IP routing protocols.
P2MP LSPに新しい出口の添加は、適切な分岐点の算出と新たな出口への分岐点からP2P経路の決定として扱うことができます。これは、比較的簡単な計算であり、いくつかのマルチキャストIPルーティングプロトコルのように限り、リバースパスCSPFによって達成することができます。
However, repeated addition to and removal from a P2MP LSP will almost certainly leave it in a sub-optimal state. The tree shape that was optimal for the original set of destinations will be distorted by the changes and will not be optimal for the new set of destinations.
しかし、P2MP LSPからの繰り返しに加えおよび除去はほぼ確実に、最適な状態でそれを残します。送信先の元のセットのために最適であった木の形状が変化によって歪めされ、目的地の新しいセットのために最適ではないでしょう。
Further, as resource availability changes in the network due to other LSPs being released or network resources being brought online, the path of the P2MP LSP may become sub-optimal.
さらに、P2MP LSPのパスが次善になることがあり、他のLSPのために、ネットワーク内のリソースの可用性の変化がリリースされているか、ネットワークリソースをオンラインにしているよう。
Computing a new optimal path for the P2MP LSP is as simple as computing any optimal P2MP path, but selecting a path that can be applied within the network as a migration from the existing LSP may be more complex. Additional constraints may be applied by the network administrator so that only subsets of the egresses (or subtrees of the P2MP tree) are optimized at any time. In these cases, the computational load of reoptimization may be considerable, but fortunately reoptimization computations may be performed as background activities. Splitting the P2MP tree into subtrees, as described in Section 3, may further reduce the computation load and may assist with administrative preferences for partial tree reoptimization.
P2MP LSPのための新たな最適経路を計算することは、任意の最適なP2MP経路を計算するのと同じくらい簡単であるが、既存のLSPからの移行のようなネットワーク内で適用することができる経路を選択することは、より複雑であってもよいです。 egresses（またはP2MPツリーのサブツリー）のサブセットのみが任意の時点で最適化されるように、追加の制約は、ネットワーク管理者によって適用することができます。これらの場合に、再最適化の計算負荷は相当であってもよいが、幸い再最適化計算は、バックグラウンドアクティビティとして実行されてもよいです。サブツリーにP2MPツリーを分割し、第3節で説明したように、さらに計算負荷を低減することができるし、部分木の再最適化のための管理設定を支援することができます。
Network-wide reoptimization of multiple LSPs [RFC5557] can achieve far greater improvements in optimality within overloaded networks than can be achieved by reoptimizing LSPs sequentially. Such computation would typically be performed offline and would usually require a dedicated processor such as a PCE invoked by the NMS.
複数のLSP [RFC5557]のネットワーク全体の再最適化を順次LSPをreoptimizingすることによって達成することができるよりも過負荷ネットワーク内で最適にはるかに大きな改善を達成することができます。そのような計算は、典型的にはオフラインで実行されると、通常、NMSによって呼び出さPCEなどの専用プロセッサを必要とするであろう。
LSP repair is necessary when a network fault disrupts the ability of the LSP to deliver data to an egress. For a P2MP LSP, a network fault is (statistically) likely to only impact a small subset of the total set of egresses. Repair activity, therefore, does not need to recompute the path of the entire P2MP tree. Rather, it needs to quickly find suitable new branches that can be grafted onto the existing tree to reconnect the disconnected leaves.
ネットワーク障害が出口にデータを提供するLSPの能力を破壊するときLSPの修復が必要です。 P2MP LSPのために、ネットワーク障害がegressesの合計組の小さなサブセットのみ影響する（統計的に）可能性があります。修復活動は、それゆえ、全体P2MPツリーのパスを再計算する必要はありません。むしろ、それはすぐに切断葉を再接続する既存のツリー上にグラフト化することができ、適切な新しい枝を見つける必要があります。
In fact, immediately after a network failure there may be a very large number of path computations required in order to restore multiple P2P and P2MP LSPs. The PCEs will be heavily loaded, and it is important that computation requests are restricted to only the 'essential'.
実際には、即座にネットワーク障害が発生した後、複数のP2PとP2MP LSPを復元するために必要なパス計算の非常に多数が存在し得ます。 PCEは、高負荷になり、そして計算要求が唯一の「不可欠」に制限されていることが重要です。
In this light, it is useful to note that the simple repair computations described in the first paragraph of this section may be applied to achieve a first repair of the LSPs, while more sophisticated reoptimization computations can be deferred until the network is stable and the load on the PCEs has been reduced. Those reoptimizations can be computed as described in Section 5.
この観点では、ネットワークが安定して負荷になるまで、より洗練された再最適化計算を延期することができるが、このセクションの最初の段落に記載さ簡単修復計算は、LSPの最初の修復を達成するために適用されてもよいことに留意することが有用ですPCEに減少しています。セクション5に記載されているように、これらreoptimizationsを計算することができます。
Disjoint paths are required for end-to-end protection services and sometimes for load balancing. They may require to be fully disjoint (except at the ingress and egress!), link disjoint (allowing common nodes on the paths), or best-effort disjoint (allowing shared links or nodes when no other path can be found).
ばらばらのパスは、エンドツーエンドの保護サービスのために、時には負荷分散のために必要とされます。彼らは完全にばらばらであることを必要とするかもしれない（入口及び出口以外で！）、ばらばらにリンク（パス上の共通のノードが可能）、またはベストエフォート互いに素（他のパスが見つからないとき、共有リンクまたはノードを許可します）。
It is possible to compute disjoint paths sequentially, but this can lead to blocking problems where the second path cannot be placed. Such issues are more readily avoided if the paths are computed in parallel.
順次互いに素な経路を計算することが可能であるが、これは第二の経路を配置することができないブロッキングの問題につながる可能性があります。経路が並列に計算される場合、このような問題がより容易に回避されます。
The computation of link disjoint P2P paths may be non-trivial and may be the sort of task that an LSR offloads to a PCE because of its complexity. The computation of disjoint P2MP paths is considerably more difficult and is therefore a good candidate to be offloaded to a PCE that has dedicated resources. In fact, it may well be the case that not all P2MP-capable PCEs can handle disjoint path requests and it may be necessary to select between PCEs based on their capabilities.
リンクディスジョイントP2P経路の計算は、非自明であってもよく、LSRは、その複雑さのPCEにオフロードタスクの一種であってもよいです。ばらばらP2MP経路の計算はかなり困難であり、したがって、リソースを捧げているPCEにオフロードされるべき良い候補です。実際には、それがうまくていないすべてのP2MP対応のPCEは独立経路要求を処理することができますし、自分の能力に基づいて、PCEの間で選択する必要があるかもしれない場合があります。
The use of PCE to compute P2MP paths has many of the same manageability considerations as when it is used for P2P LSPs [RFC5440]. There may be additional manageability implications for the size of P2MP computation requests and the additional loading exerted on the PCEs.
P2MP経路を計算するPCEの使用は、それがP2P LSPの[RFC5440]のために使用されたときと同じ管理の考慮事項の多くを有します。 P2MP計算要求のサイズとのPCEに作用する追加のローディングのための追加の管理機能への影響があってもよいです。
As already described, individual PCEs may choose to not be capable of P2MP computation, and where this function is available, it may be disabled by an operator, or may be automatically withdrawn when the PCE becomes loaded or based on other policy considerations.
既に説明したように、個々のPCEは、P2MP計算することができないことを選択してもよいし、この機能が利用可能である場合、それはオペレータによって無効にすることができ、又はPCEがロードまたは他のポリシーの考慮事項に基づいてなったときに自動的に引き出すことができます。
Further, a PCE may refuse any P2MP computation request or pass it on to another PCE based on policy.
さらに、PCEは、任意P2MP計算要求を拒否するか、ポリシーに基づいて他のPCEにそれを渡すことができます。
P2MP computation requests necessitate considerably more information exchange between the LSR and the PCE than is required for P2P computations. This will result in much larger data sets to be controlled and modeled, and will impact the utility of any management data models, such as MIB modules. Care needs to be taken in the design of such data models, and the use of other management protocols and data modeling structures, such as NETCONF [RFC4741] and the NETCONF Data Modeling Language (NETMOD), could be considered.
P2MP計算要求がLSRとP2Pの計算のために必要とされるよりもPCEの間でかなり多くの情報交換を必要とします。これは、制御されモデル化され、そしてそのようなMIBモジュールなどの任意の管理データモデルの有用性に影響を与えるべきはるかに大きなデータセットをもたらすであろう。ケアは、このようなデータモデルの設計、および、そのようなNETCONF [RFC4741]とNETCONFデータモデリング言語（NETMOD）など、他の管理プロトコルとデータモデリング構造の使用に注意が必要、と考えることができます。
PCE liveness detection and monitoring is unchanged from P2P operation, but it should be noted that P2MP requests will take longer to process than P2P requests, meaning that the time between request and response will be, on average, longer. This increases the chance of a communications failure between request and response and means that liveness detection is more important.
PCEの生存性の検出と監視がP2P操作から変更されていませんが、P2MP要求は要求と応答の間の時間が長く、平均的に、なることを意味し、P2P要求よりも処理に時間がかかりますことに留意すべきです。これは、要求と応答との間の通信障害の可能性を増加させ、ライブネス検出がより重要であることを意味します。
Correct operation of any communication between LSRs and PCEs is exactly as important as it is for P2P computations.
LSRとのPCEとの間の通信の正しい操作は、それがP2P計算するためのものであるとまったく同様に重要です。
The correct operation of path computation algorithms implemented at PCEs is out of scope, but LSRs that are concerned that PCE algorithms might not be operating correctly may make identical requests to separate PCEs and compare the responses.
PCEで実装経路計算アルゴリズムの正しい動作範囲の外であるが、PCEアルゴリズムが正しく動作していない可能性があることを懸念しているのLSRは、のPCEを分離し、応答を比較するために同じ要求を行うことができます。
As is clear from the PCE architecture, a communications protocol is necessary to allow LSRs to send computation requests to PCEs and for PCEs to cooperate. Requirements for such a protocol to handle P2P path computations are described in [RFC4657], and additional requirements in support of P2MP computations are described in [PCE-P2MP]. The PCE Communication Protocol (PCEP) is defined in [RFC5440], but extensions will be necessary to support P2MP computation requests.
PCEアーキテクチャから明らかなように、通信プロトコルのLSRがのPCEへと協力するのPCEの計算要求を送信できるようにする必要があります。 P2P経路計算を処理するためにそのようなプロトコルのための要件は、[RFC4657]に記載されており、P2MP計算のサポートで追加要件は[PCE-P2MP]に記載されています。 PCE通信プロトコル（PCEP）は[RFC5440]で定義されていますが、拡張子はP2MP計算要求をサポートする必要があります。
As described in the body of this document, LSRs need to be able to recognize which PCEs can perform P2MP computations. Capability advertisement is already present in the PCE Discovery protocols ([RFC5088] and [RFC5089]) and can also be exchanged in PCEP ([RFC5440]), but extensions will be required to describe P2MP capabilities.
本文書の本文に記載されているように、のLSRは、P2MPの計算を実行することができるのPCEを認識できるようにする必要があります。能力の広告は、（[RFC5088]と[RFC5089]）すでにPCE発見プロトコルに存在し、また、PCEP（[RFC5440]）に交換することができますが、拡張子はP2MP機能を記述する必要があります。
As also described in this document, the PCE needs to know the branch capabilities of the LSRs and store this information in the TED. This information can be distributed using the routing protocols as described in [RFC5073].
また、この文書で説明したように、PCEはのLSRの分岐機能を知っていて、TEDにこの情報を格納する必要があります。 [RFC5073]に記載されているように、この情報は、ルーティングプロトコルを使用して分散させることができます。
The use of a PCE to perform P2MP computations may have a beneficial impact on network operation if it can offload processing from the LSRs, freeing them up to handle protocol operations.
それはプロトコル動作を処理するためにそれらを解放する、のLSRから処理をオフロードできるかどうP2MP計算を実行するPCEの使用は、ネットワーク運用上の有益な影響を有していてもよいです。
Furthermore, the use of a PCE may enable more dynamic behavior in P2MP LSPs (such as the addition of new egresses, reoptimization, and failure recovery) than is possible using more traditional management-based planning techniques.
また、PCEの使用は、より伝統的な管理に基づく計画の技術を用いて可能であるよりも（例えば新しいegresses、再最適化、および障害回復の追加など）P2MPのLSPを、より動的挙動を可能にすることができます。
The use of PCE to compute P2MP paths does not raise any additional security issues beyond those that generally apply to the PCE architecture. See [RFC4655] for a full discussion.
P2MPパスを計算するPCEの使用は、一般的にPCEアーキテクチャに適用されるものを超えて追加のセキュリティ上の問題を提起しません。完全な議論のための[RFC4655]を参照してください。
Note, however, that P2MP computation requests are more CPU-intensive and also use more link bandwidth. Therefore, if the PCE was attacked by the injection of spurious path computation requests, it would be more vulnerable through a smaller number of such requests.
P2MP計算要求がより多くのCPU集約型であり、また、より多くのリンク帯域幅を使用していること、しかし、注意してください。 PCEは、スプリアス経路計算リクエストの注射により攻撃された場合そのため、そのような要求の数が少ないスルーより脆弱であろう。
Thus, the use of message integrity and authentication mechanisms within the PCE protocol should be used to mitigate attacks from devices that are not authorized to send requests to the PCE. It would be possible to consider applying different authorization policies for P2MP path computation requests compared to other requests.
したがって、PCEプロトコル内のメッセージの整合性および認証メカニズムの使用はPCEに要求を送信することを許可されていないデバイスからの攻撃を軽減するために使用されるべきです。他の要求に比べてP2MP経路計算要求に対して異なる認可ポリシーを適用を検討することも可能です。
The authors would like to thank Jerry Ash and Jean-Louis Le Roux for their thoughtful comments. Lars Eggert, Dan Romascanu, and Tim Polk provided useful comments during IESG review.
作者は彼らの思慮深いコメントをジェリー・アッシュとジャン=ルイ・ル・ルーに感謝したいと思います。ラースエッゲルト、ダンRomascanu、およびティムポークはIESGレビューの間に有用なコメントを提供しました。
[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月。
[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）」。
[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月。
[RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]エンス、R.、エド。、 "NETCONF構成プロトコル"、RFC 4741、2006年12月。
[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月。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088]ル・ルー、JL。、エド。、Vasseur、JP。、エド。、池尻、Y.、およびR.張、 "OSPFプロトコル拡張パスの計算要素（PCE）ディスカバリー"、RFC 5088、2008年1月。
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5089]ル・ルー、JL。、エド。、Vasseur、JP。、エド。、池尻、Y.、およびR.張は、 "IS-ISプロトコル拡張経路計算エレメント（PCE）の発見について"、RFC 5089、1月2008。
[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月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、編、およびJL。ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコル（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。、編、張、R.、ビタール、N.、およびJL。ル・ルー、RFC 5441、2009年4月「最短拘束ドメイン間トラフィックエンジニアリングラベルを計算するために下位再帰PCEベースの計算（BRPC）手順は、パスの交換しました」。
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, July 2009.
[RFC5557]リー、Y.、ル・ルー、JL。、キング、D.、およびE.沖、 "パス計算要素通信プロトコル（PCEP）の要件とプロトコルの拡張機能のグローバル同時最適化のサポートで"、RFC 5557、2009年7月。
[PCE-P2MP] Yasukawa, S., and Farrel, A., "PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", Work in Progress, May 2008.
[PCE-P2MP]安川、S.、およびファレル、A.は、進歩、2008年5月における作業 "ポイントのPCC-PCEの通信要件は、トラフィックエンジニアリング（MPLS-TE）をマルチプロトコルラベルスイッチング対多"。
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
メールアドレス：yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting
エードリアンファレル古い犬のコンサルティング
EMail: adrian@olddog.co.uk
メールアドレス：adrian@olddog.co.uk