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)




The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.


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).


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 ( 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ドキュメント(に関連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
1. Introduction
1. はじめに

The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph and 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].


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のから、このようなパス計算をオフロードする方法を提供しています。

2. Architectural Considerations
2.1. Offline Computation
2.1. オフライン計算

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].


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.


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.


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.


2.2. Online Computation
2.2. オンライン計算

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.


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.


2.2.1. LSR Loading
2.2.1. LSRロード

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.


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.


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.


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は、専用サーバ、または自律システム境界ルータとして配置されるかもしれないハイエンドルータなど)専用又は大容量のネットワーク要素に設けることができます。

2.2.2. PCE Overload
2.2.2. PCEの過負荷

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].


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.


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.


2.2.3. PCE Capabilities
2.2.3. 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.


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.


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を選択することができます。

3. Fragmenting the P2MP Tree
3. P2MPツリーの断片化

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.


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と協働することができます。

                            \        \
                             \        \
                              j        x
                                  \  \
                                   \  \
                                    s  z

Figure 1: A P2MP Tree with Intermediate Computation Points


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を選択し、又はどの程度明らかであること。このようなアドレス集合によって提供されるかもしれないようなリーフノード識別子のいくつかの既知のプロパティがない限り、これらの質問を決定するための計算は、完全なツリーの決意以上で集中しなくてもよいです。

4. Central Replication Points

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.


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。

                              \     \
                               \     \
                             E  h  K  o

Figure 2: Using Centralized Replication Points


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サービスのトラフィックの複製の非常に大きな金額を扱うこともあります)。

5. Reoptimization and Modification

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などの専用プロセッサを必要とするであろう。

6. Repair

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.


7. Disjoint Paths

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.


8. Manageability Considerations

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に作用する追加のローディングのための追加の管理機能への影響があってもよいです。

8.1. Control of Function and Policy
8.1. 機能とポリシーの管理

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.


Further, a PCE may refuse any P2MP computation request or pass it on to another PCE based on policy.


8.2. Information and Data Models
8.2. 情報とデータモデル

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)など、他の管理プロトコルとデータモデリング構造の使用に注意が必要、と考えることができます。

8.3. Liveness Detection and Monitoring
8.3. 生体検知とモニタリング

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.


8.4. Verifying Correct Operation
8.4. 正しい動作を確認

Correct operation of any communication between LSRs and PCEs is exactly as important as it is for P2P computations.


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.


8.5. Requirements on Other Protocols and Functional Components
8.5. その他のプロトコルと機能コンポーネントの要件

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.


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]に記載されているように、この情報は、ルーティングプロトコルを使用して分散させることができます。

8.6. Impact on Network Operation
8.6. ネットワークオペレーションへの影響

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.


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.


9. Security Considerations

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.


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.


10. Acknowledgments

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.


11. References
11.1. Normative References
11.1. 引用規格

[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月。

11.2. Informative References
11.2. 参考文献

[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

せいしょ やすかわ んっt こrぽらちおん 9ー11、 みどりーちょ 3ーちょめ むさしのーし、 ときょ 180ー8585、 じゃぱん



Adrian Farrel Old Dog Consulting