Network Working Group S. Yasukawa
Request for Comments: 5671 NTT
Category: Informational A. Farrel, Ed.
Old Dog Consulting
October 2009
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.
本文研究了PCE在MPLS和GMPLS网络中P2MP TE LSP路径计算中的适用性。它描述了使用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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第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 ....................................................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的管理系统的一部分，或者可以定位为网络内的一个或多个计算服务器。
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
[RFC4461]中记录了点对多点（P2MP）MPLS TE LSP的要求，而[RFC4875]中定义了用于设置P2MP MPLS TE LSP的信令协议扩展。在这个
document, P2MP MPLS TE networks are considered in support of various features including layer 3 multicast VPNs [RFC4834], video distribution, etc.
文件中，P2MP MPLS TE网络被认为支持各种功能，包括第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路径的基础是选择分支点。这种选择不仅受到网络拓扑和可用网络资源的约束，而且还取决于可应用于路径计算的目标函数。例如，一个标准目标是最小化树的总成本（即最小化树遍历的每个链接的成本之和），以生成所谓的Steiner树。另一个常见的目标函数要求到达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用于执行其计算的流量工程数据库（TED）中，并可使用网络内运行的内部网关协议（IGP）扩展进行分发[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
由于上述计算的复杂性，P2MP-TE-lsp的路径计算提出了重大挑战。确定P2MP TE LSP的不相交保护路径会大大增加这种复杂性，而对P2MP树的小修改（例如仅添加或删除一片叶子）会完全改变最佳路径。重新优化包含多个P2MP TE LSP的网络需要大量的计算资源。所有这一切意味着入口LSR可能没有足够的处理能力来执行必要的计算，即使它有，路径计算的行为也可能干扰控制和控制
management plane operation necessary to maintain existing LSPs. The PCE architecture offers a way to offload such path computations from LSRs.
维护现有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）或针对网络故障的计划响应。在这些场景中，更多的规划通常是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.
当网络运营商希望保留对LSP放置的完全手动控制时，也可使用该模型，仅将PCE用作辅助运营商的计算工具，而不是作为自动化网络的一部分。
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路径计算的一个重要特征是它在确定路径的网元上施加的处理负载。粗略地说，计算叶树的最小成本的负载与依次计算每个叶的单个最优路径的成本相同。计算Steiner树的负载大约要大一个数量级，尽管现有的算法用于近似Steiner树的时间数量级与叶树的最小成本大致相同。
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能够进行简单的约束最短路径优先（CSPF）计算，以确定单个点对点（P2P）LSP的路径，但如果要求它们执行多个此类计算，例如在从网络故障中恢复时，它们会很快被淹没。因此，可以合理预期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.
LSR因P2MP路径计算而过载的结果可能是双重的。首先，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入口的所有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).
因此，有一个明显的解决方案：将P2MP路径计算从LSR卸载到远程PCE。此类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路径计算是资源密集型的，将P2MP LSP引入已建立的PCE网络可能会导致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可以为P2MP请求分配较低的优先级，从而确保优先服务P2P请求。此外，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可以将其计算请求队列（使用[RFC4655]中描述的PCE合作模型）重新分配给网络内其他负担较轻的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。该选择可以基于来自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可能有能力满足某些目标函数（例如，目的地成本最低），但缺乏对其他目标函数的支持（例如，Steiner）。此外，一些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能力的进一步和更详细的交换。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中的网络拓扑结构。从入口LSR A到出口LSR s、t、u、v、w、x、y和z需要P2MP LSP。使用单个PCE模型，LSR a可以请求树的整个路径，这可以由PCE提供。或者，LSR A咨询的PCE可以仅计算树的第一片段（例如，从A到K、L和M），并且可以依赖其他PCE来计算从K到t、u和v的三个较小的树；从L到w和x；从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可以简单地返回第一子树，并让LSR K、L和M依次调用pce以完成信令。或者，第一PCE可以与其他PCE合作，以收集后续子树的路径，并在单个计算响应中将其返回给PCE a。这两种方法的机制在PCE架构[RFC4655]中描述。
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
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.
另一种可能性是，使用协作PCE技术，例如反向递归路径计算（BRPC）机制[RFC5441]，从一组潜在的此类点中选择子树缝合在一起的LSR（本例中为K、L和M）。事实上，如果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的部署模型是使用集中的、众所周知的复制点。这种选择可能是出于管理或安全原因，或者是由于网络中特定的硬件能力限制。实际上，这种部署模型可以通过在入口和复制点之间以及在复制点和每个叶之间使用P2P lsp来实现，从而在不使用P2MP MPLS-TE的情况下实现P2MP服务。
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中，从入口LSR a到出口LSR m、n、o和p需要P2MP服务。网络中有四个支持复制的LSR：D、E、J和K。
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 a到叶子的完整P2MP路径，但在该模型中，PCE只返回到第一个复制点（在本例中为LSR D）的P2P路径。LSR D将依次咨询PCE，并确定要出口LSR m和p的P2P LSP以及到下一个复制点LSR J的P2P LSP。最后，LSR J将使用PCE确定要出口n和o的P2P LSP。
f--i--m
/
/
a--b--c--D--g--J--n
\ \
\ \
E h K o
\
\
l--p
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).
在此操作模型中，PCE功能很可能位于复制点，这将是高容量LSR。计算活动的主要特征之一是复制点的选择（例如，为什么选择LSR D而不是LSR E，为什么选择LSR J而不是LSR K？）。与P2MP计算一样，此选择可能仅基于路径优化，但也可能受到策略问题（例如，LSR D可能能够提供更好的安全性以防止恶意叶连接）或网络负载问题的影响（例如，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将被拆除。但是，当接收器来来去去去时，可以将出口添加到活动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路径来处理。这是一个相对简单的计算，可以通过反向路径CSPF实现，就像某些多播IP路由协议一样。
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.
此外，随着由于其他LSP被释放或网络资源在线而导致网络中的资源可用性改变，P2MP 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的迁移可能更复杂。网络管理员可以应用附加约束，以便在任何时候仅优化出口的子集（或P2MP树的子树）。在这些情况下，重新优化的计算量可能相当大，但幸运的是，重新优化计算可以作为背景活动执行。如第3节所述，将P2MP树拆分为子树，可进一步减少计算负载，并有助于部分树重新优化的管理偏好。
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更大的优化。此类计算通常离线执行，通常需要专用处理器，如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，网络故障（统计上）可能只影响整个出口集合的一小部分。因此，修复活动不需要重新计算整个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节所述计算这些再优化。
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.
使用PCE计算P2MP路径与用于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
P2MP计算请求需要在LSR和PCE之间进行比P2P计算所需的信息交换多得多的信息交换。这将导致控制和建模更大的数据集，并将影响任何管理数据模型（如MIB模块）的实用性。在工作中需要小心
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.
可以考虑设计此类数据模型，以及使用其他管理协议和数据建模结构，如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进行合作。[RFC4657]中描述了此类协议处理P2P路径计算的要求，而[PCE-P2MP]中描述了支持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需要能够识别哪些PCE可以执行P2MP计算。PCE发现协议（[RFC5088]和[RFC5089]）中已经存在能力公告，并且也可以在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.
使用PCE执行P2MP计算可能会对网络运行产生有益的影响，如果它可以从LSR中卸载处理，使其能够处理协议操作。
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可以在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.
使用PCE来计算P2MP路径不会产生任何额外的安全问题，这些问题通常适用于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发送请求的设备的攻击。与其他请求相比，可以考虑对PMP路径计算请求应用不同的授权策略。
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.
作者要感谢Jerry Ash和Jean-Louis Le Roux的深思熟虑的评论。Lars Eggert、Dan Romascanu和Tim Polk在IESG审查期间提供了有用的意见。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]Yasukawa，S.，Ed.“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，2006年4月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.，Ed.，和J.Le Roux，Ed.，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[RFC4741] Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]恩斯，R.，编辑，“网络配置协议”，RFC 47412006年12月。
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[RFC4834]Morin，T.，Ed.“第3层提供商提供的虚拟专用网络（PPVPN）中的多播要求”，RFC 4834，2007年4月。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC4875]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 48752007年5月。
[RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007.
[RFC5073]Vasseur，J.，Ed.，和J.Le Roux，Ed.，“发现流量工程节点能力的IGP路由协议扩展”，RFC 5073，2007年12月。
[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]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，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]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，2008年1月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“策略启用路径计算框架”，RFC 53942008年12月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）过程”，RFC 54412009年4月。
[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]Lee，Y.，Le Roux，JL.，King，D.，和E.Oki，“支持全局并行优化的路径计算元素通信协议（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]Yasukawa，S.和Farrel，A.，“点对多点多协议标签交换流量工程（MPLS-TE）的PCC-PCE通信要求”，正在进行的工作，2008年5月。
Authors' Addresses
作者地址
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585, Japan
日本东京武藏町3-Chome-Musashino Shi Midori Cho 3-Chome Yasukawa NTT公司9-11号，东京180-8585
EMail: yasukawa.seisho@lab.ntt.co.jp
EMail: yasukawa.seisho@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting
阿德里安·法雷尔老狗咨询公司
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk