Internet Engineering Task Force (IETF) S. Yasukawa
Request for Comments: 5862 NTT Corporation
Category: Informational A. Farrel
ISSN: 2070-1721 Old Dog Consulting
June 2010
Internet Engineering Task Force (IETF) S. Yasukawa
Request for Comments: 5862 NTT Corporation
Category: Informational A. Farrel
ISSN: 2070-1721 Old Dog Consulting
June 2010
Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE
路径计算客户端（PCC）.点对多点MPLS-TE的路径计算元件（PCE）要求
Abstract
摘要
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
路径计算元件（PCE）提供路径计算功能，以支持多协议标签交换（MPLS）和通用MPLS（GMPLS）网络中的流量工程。
Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.
对MPLS和GMPLS信令和路由协议进行了扩展，以支持点对多点（P2MP）流量工程（TE）标签交换路径（LSP）。PCE在MPLS网络中的使用已经建立，并且由于P2MP TE LSP路由有时计算起来很复杂，因此PCE很可能将用于P2MP LSP。
Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering.
RFC 4657“路径计算元件（PCE）通信协议通用要求”中介绍了路径计算客户端（PCC）和PCE之间通信协议的通用要求。本文件补充了通用要求，并为点对多点MPLS/GMPLS流量工程提供了一套详细的PCC-PCE通信协议要求。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5862.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5862.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. The intention is that the PCE is used to compute the path of Traffic Engineered Label Switched Paths (TE LSPs) within Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
[RFC4655]中定义的路径计算元素（PCE）是能够基于网络图计算网络路径或路由并应用计算约束的实体。其目的是使用PCE计算多协议标签交换（MPLS）和广义MPLS（GMPLS）网络中的流量工程标签交换路径（TE LSP）的路径。
Requirements for point-to-multipoint (P2MP) MPLS TE LSPs are documented in [RFC4461], and signaling protocol extensions for setting up P2MP MPLS TE LSPs are defined in [RFC4875]. P2MP MPLS TE networks are considered in support of various features, including layer 3 multicast virtual private networks [RFC4834].
[RFC4461]中记录了点对多点（P2MP）MPLS TE LSP的要求，而[RFC4875]中定义了用于设置P2MP MPLS TE LSP的信令协议扩展。P2MP MPLS TE网络被认为支持各种功能，包括第3层多播虚拟专用网络[RFC4834]。
Path computation for P2MP TE LSPs presents a significant challenge, and network optimization of multiple P2MP TE LSPs requires considerable computational resources. PCE offers a way to offload such path computations from Label Switching Routers (LSRs).
P2MP-TE-lsp的路径计算是一个重大挑战，多个P2MP-TE-lsp的网络优化需要大量的计算资源。PCE提供了一种从标签交换路由器（LSR）中卸载此类路径计算的方法。
The applicability of the PCE-based path computation architecture to P2MP MPLS TE is described in a companion document [RFC5671]. No further attempt is made to justify the use of PCE for P2MP MPLS TE within this document.
基于PCE的路径计算架构对P2MP MPLS TE的适用性在附带文档[RFC5671]中进行了描述。本文件中没有进一步尝试证明P2MP MPLS TE使用PCE的合理性。
This document presents a set of PCC-PCE communication protocol (PCECP) requirements for P2MP MPLS traffic engineering. It supplements the generic requirements documented in [RFC4657].
本文档介绍了P2MP MPLS流量工程的一组PCC-PCE通信协议（PCECP）要求。它补充了[RFC4657]中记录的通用要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Although this document is not a protocol specification, this convention is adopted for clarity of description of requirements.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。虽然本文件不是协议规范，但采用本公约是为了清楚地描述要求。
This section sets out additional requirements specific to P2MP MPLS TE that are not covered in [RFC4657].
本节规定了[RFC4657]中未涉及的P2MP MPLS TE的额外要求。
The PCC-PCE communication protocol MUST allow requests and replies for the computation of paths for P2MP LSPs.
PCC-PCE通信协议必须允许P2MP LSP路径计算的请求和响应。
This requires no additional messages, but requires the addition of the parameters described in the following sections to the existing PCC-PCE communication protocol messages.
这不需要额外的消息，但需要在现有PCC-PCE通信协议消息中添加以下章节中描述的参数。
R1: Although the presence of certain parameters (such as a list of more than one destination) MAY be used by a protocol specification to allow an implementation to infer that a Path Computation Request is for a P2MP LSP, an explicit parameter SHOULD be placed in a conspicuous place within a Path Computation Request message to allow a receiving PCE to easily identify that the request is for a P2MP path.
R1：尽管协议规范可以使用某些参数（例如多个目的地的列表）的存在来允许实现推断路径计算请求是针对P2MP LSP的，显式参数应放置在路径计算请求消息内的显眼位置，以允许接收PCE轻松识别该请求是针对P2MP路径的。
R2: [RFC4657] includes the requirement to be able to specify the objective functions to be applied by a PCE during path computation.
R2:[RFC4657]包括能够指定PCE在路径计算期间应用的目标函数的要求。
This document makes no change to that requirement, but it should be noted that new and different objective functions will be used for P2MP computation. Definitions for core objective functions can be found in [RFC5541] together with usage procedures. New objective functions for use with P2MP path computations will need to be defined and allocated codepoints in a separate document.
本文件未对该要求进行更改，但应注意，P2MP计算将使用新的不同目标函数。核心目标函数的定义见[RFC5541]和使用程序。用于P2MP路径计算的新目标函数需要在单独的文件中定义和分配码点。
R3: PCEs are not required to support P2MP path computation. Therefore, it MUST be possible for a PCE to reject a P2MP Path Computation Request message with a reason code that indicates no support for P2MP path computation.
R3：PCE不需要支持P2MP路径计算。因此，PCE必须能够拒绝P2MP路径计算请求消息，其原因代码表明不支持P2MP路径计算。
It is possible that initial PCE implementations will be developed without support for P2MP path computation and without the ability to recognize the explicit parameter described in Section 3.1.1. Such legacy implementations will not be able to make use of the new reason code described in Section 3.1.3.
初始PCE实施可能在不支持P2MP路径计算且不具备识别第3.1.1节所述明确参数的能力的情况下开发。此类遗留实施将无法使用第3.1.3节中描述的新原因代码。
R4: Therefore, at least one parameter required for inclusion in a P2MP Path Computation Request message MUST be defined in such a way as to cause automatic rejection as unprocessable or unrecognized by a back-level PCE implementation without requiring any changes to that PCE. It is RECOMMENDED that the parameter that causes this result be the parameter described in Section 3.1.1.
R4：因此，在P2MP路径计算请求消息中包含的至少一个参数必须以这样的方式定义，即在不需要对该PCE进行任何更改的情况下，导致自动拒绝，即后台PCE实现无法处理或无法识别。建议导致该结果的参数为第3.1.1节中所述的参数。
R5: Since P2MP LSPs have more than one destination, it MUST be possible for a single Path Computation Request to list multiple destinations.
R5：由于P2MP LSP有多个目的地，因此单路径计算请求必须能够列出多个目的地。
R6: The Path Computation Response MUST be able to carry the path of a P2MP LSP.
R6：路径计算响应必须能够承载P2MP LSP的路径。
P2MP paths can be expressed as a compressed series of routes as described in [RFC4875]. The Path Computation Response MUST be able to carry the P2MP path as either a compressed path (but not necessarily using the identical encoding as described in [RFC4875]), or as a non-compressed path comprising a series of source-to-leaf point-to-point (P2P) paths (known as S2L sub-paths).
P2MP路径可以表示为[RFC4875]中所述的一系列压缩路由。路径计算响应必须能够以压缩路径（但不一定使用[RFC4875]中所述的相同编码）或包含一系列源到叶点（P2P）路径（称为S2L子路径）的非压缩路径的形式携带P2MP路径。
R7: By default, the path returned by the PCE SHOULD use the compressed format.
R7：默认情况下，PCE返回的路径应使用压缩格式。
The request from the PCC MAY allow the PCC to express a preference for receiving a compressed or non-compressed P2MP path in the response.
来自PCC的请求可允许PCC表示在响应中接收压缩或非压缩P2MP路径的偏好。
R8: A single P2MP LSP may have many destinations, and the computed path (tree) may be very extensive. In these cases, it is possible that the entire Path Computation Request or Response cannot fit within one PCE message. Therefore, it MUST be possible for a single request or response to be conveyed by a sequence of PCE messages.
R8：单个P2MP LSP可能有许多目的地，并且计算的路径（树）可能非常广泛。在这些情况下，整个路径计算请求或响应可能无法包含在一条PCE消息中。因此，必须能够通过PCE消息序列传送单个请求或响应。
Note that there is a requirement in [RFC4657] for reliable and in-order message delivery, so it is assumed that components of the sequence will be delivered in order and without missing components.
请注意，[RFC4657]中有可靠且有序的消息传递要求，因此假定序列的组件将有序地传递，且不会丢失组件。
[RFC4875] requires that all branches of a single P2MP LSP have the same characteristics, and achieves this by not allowing the signaling parameters to be varied for different branches of the same P2MP LSP.
[RFC4875]要求单个P2MP LSP的所有分支具有相同的特性，并通过不允许同一P2MP LSP的不同分支改变信令参数来实现这一点。
R9: It MUST NOT be possible to set different constraints, traffic parameters, or quality-of-service requirements for different destinations of a P2MP LSP within a single computation request.
R9：不能在单个计算请求中为P2MP LSP的不同目的地设置不同的约束、流量参数或服务质量要求。
R10: No changes are made to the requirement to support path modification and path diversity as described in [RFC4657]. Note, however, that a consequence of this requirement is that it MUST be possible to supply an existing path in a Path Computation Request. This requirement is unchanged from [RFC4657], but it is a new requirement that such paths MUST be able to be P2MP paths. The PCC MUST be able to supply these paths as compressed paths or as non-compressed paths (see Section 3.1.6) according to the preference of the PCC.
R10：未对[RFC4657]中所述的支持路径修改和路径多样性的要求进行任何更改。但是，请注意，此要求的结果是必须能够在路径计算请求中提供现有路径。该要求与[RFC4657]相同，但这是一个新的要求，即此类路径必须能够是P2MP路径。根据PCC的偏好，PCC必须能够将这些路径作为压缩路径或非压缩路径（见第3.1.6节）提供。
R11: Reoptimization MUST be supported for P2MP TE LSPs as described for P2P LSPs in [RFC4657]. To support this, the existing path MUST be supplied as described in Section 3.1.9.
R11:P2MP TE LSP必须支持重新优化，如[RFC4657]中对P2P LSP所述。为了支持这一点，必须按照第3.1.9节所述提供现有路径。
Because P2MP LSPs are more complex, it is often the case that small optimization improvements can be made after changes in network resource availability. However, re-signaling any LSP introduces risks to the stability of the service provided to the customer and the stability of the network, even when techniques like make-before-break [RFC3209] are used. Therefore, a P2MP Path Computation Request SHOULD contain a parameter that allows
由于P2MP LSP更为复杂，通常情况下，在网络资源可用性发生变化后，可以进行小的优化改进。然而，任何LSP的重新信令都会给提供给客户的服务的稳定性和网络的稳定性带来风险，即使使用了先通后断[RFC3209]等技术。因此，P2MP路径计算请求应包含允许
the PCC to express a cost-benefit reoptimization threshold for the whole LSP, as well as per destination. The setting of this parameter is subject to local policy at the PCC and SHOULD be subject to policy at the PCE [RFC5394].
PCC表示整个LSP以及每个目的地的成本效益再优化阈值。此参数的设置取决于PCC的本地政策，并且应取决于PCE的政策[RFC5394]。
Path reoptimization responses SHOULD indicate which of the routes (as supplied according to Section 3.1.6) have been modified from the paths supplied in the request.
路径重新优化响应应表明哪些路由（根据第3.1.6节提供）已从请求中提供的路径修改。
A variation of path modification described in Section 3.1.9 is that destinations may be added to, or removed from, existing P2MP TE LSPs.
第3.1.9节中描述的路径修改的一个变体是，可将目的地添加到现有P2MP TE LSP或从现有P2MP TE LSP中删除。
In the case of the addition of one or more destinations, it is necessary to compute a path for a new branch of the P2MP LSP. It may be desirable to recompute the whole P2MP tree, to add the new branch as a simple spur from the existing tree, or to recompute part of the P2MP tree.
在添加一个或多个目的地的情况下，需要计算P2MP LSP的新分支的路径。可能需要重新计算整个P2MP树，将新分支作为现有树的简单分支添加，或重新计算P2MP树的一部分。
R12: To support this function for leaf additions, it MUST be possible to make the following indications in a Path Computation Request:
R12：为了支持叶添加的此功能，必须能够在路径计算请求中进行以下指示：
- The path of an existing P2MP LSP (as described in Section 3.1.9).
- 现有P2MP LSP的路径（如第3.1.9节所述）。
- Which destinations are new additions to the tree.
- 哪些目的地是树中新添加的目的地。
- Which destinations of the existing tree must not have their paths modified.
- 现有树的哪些目标不能修改其路径。
It MAY also be possible to indicate in a Path Computation Request a cost-benefit reoptimization threshold, such that the addition of new leaves will not cause reoptimization of the existing P2MP tree unless a certain improvement is made over simply grafting the new leaves to the existing tree. (Compare with Section 3.1.10.)
还可以在路径计算请求中指示成本效益再优化阈值，使得添加新叶不会导致现有P2MP树的再优化，除非在简单地将新叶嫁接到现有树上的基础上进行了某种改进。（与第3.1.10节进行比较。）
In the case of the deletion of one or more destinations, it is not necessary to compute a new path for the P2MP TE LSP, but such a computation may yield optimizations over a simple pruning of the tree. The recomputation function in this case is essentially the same as that described in Section 3.1.10, but note that it MAY be possible to supply the full previous path of the entire P2MP TE LSP (that is, before the deletion of the destinations) in the Path Computation Request.
在删除一个或多个目的地的情况下，不需要为P2MP TE LSP计算新路径，但是这种计算可以通过简单的树修剪产生优化。这种情况下的重新计算功能基本上与第3.1.10节所述相同，但请注意，可以在路径计算请求中提供整个P2MP TE LSP的完整先前路径（即，在删除目的地之前）。
For both addition and deletion of destinations, the Path Computation Response SHOULD indicate which of the routes (as supplied according to Section 3.1.6) have been modified from the paths supplied in the Path Computation Request, as described in Section 3.1.10.
对于目的地的添加和删除，路径计算响应应表明哪些路由（根据第3.1.6节提供）已从路径计算请求中提供的路径修改，如第3.1.10节所述。
Note that the selection of all of these options is subject to local policy at the PCC and SHOULD be subject to policy at the PCE [RFC5394].
请注意，所有这些选项的选择均受PCC当地政策的约束，且应遵守PCE的政策[RFC5394]。
For administrative or security reasons, or for other policy reasons, it may be desirable to limit the set of nodes within the network that may be used as branch points for a given LSP, i.e., to provide to the path computation a limiting set of nodes that can be used as branches for a P2MP path computation, or to provide a list of nodes that must not be used as branch points.
出于管理或安全原因，或出于其他策略原因，可能需要限制网络中可用作给定LSP的分支点的节点集，即，向路径计算提供可用作P2MP路径计算的分支的限制节点集，或提供不能用作分支点的节点列表。
R13: The PCC MUST be able to specify in a Path Computation Request a list of nodes that constitutes a limiting superset of the branch nodes for a P2MP path computation.
R13:PCC必须能够在路径计算请求中指定节点列表，该列表构成P2MP路径计算的分支节点的限制超集。
A PCC MUST be able to specify in a Path Computation Request a list of nodes that must not be used as branch nodes for a P2MP path computation.
PCC必须能够在路径计算请求中指定不能用作P2MP路径计算的分支节点的节点列表。
PCE capabilities exchange forms part of PCE discovery [RFC4674], but may also be included in the PCECP message exchanges [RFC4657].
PCE能力交换构成PCE发现[RFC4674]的一部分，但也可能包括在PCECP消息交换[RFC4657]中。
R14: The ability to perform P2MP path computation and the objective functions supported by a PCE SHOULD be advertised as part of PCE discovery. In the event that the PCE's ability to perform P2MP computation is not advertised as part of PCE discovery, the PCECP MUST allow a PCC to discover which PCEs with which it communicates support P2MP path computation, and which objective functions specific to P2MP path computation are supported by each PCE.
R14：执行P2MP路径计算的能力和PCE支持的目标函数应作为PCE发现的一部分进行宣传。如果PCE执行P2MP计算的能力未作为PCE发现的一部分公布，PCECP必须允许PCC发现与其通信的哪些PCE支持P2MP路径计算，以及每个PCE支持哪些特定于P2MP路径计算的目标函数。
The list of objective functions is assumed to be coordinated with those that can be requested as described in Section 3.1.2.
假设目标函数列表与第3.1.2节所述可请求的目标函数相协调。
These requirements do not represent a change to [RFC4657], except to add more capabilities and objective functions.
这些要求并不代表[RFC4657]的变更，只是增加了更多的能力和目标功能。
Section 3.1.9 sets out the requirement to be able to request multiple diverse paths. Additionally, with P2MP trees, it may be that only parts of the tree can be, or need to be, diverse.
第3.1.9节规定了能够请求多条不同路径的要求。此外，对于P2MP树，可能只有树的一部分可以或需要多样化。
R15: The PCC SHOULD be able to request a PCE to compute a secondary P2MP path tree with partial path diversity for specific leaves or a specific S2L sub-path.
R15:PCC应该能够请求PCE计算具有特定叶或特定S2L子路径的部分路径分集的次要P2MP路径树。
PCE implementations MAY provide a configuration switch to allow support of P2MP MPLS TE computations to be enabled or disabled. When the level of support is changed, this SHOULD be re-advertised as described in Section 3.1.13.
PCE实现可提供配置开关，以允许启用或禁用对P2MP MPLS TE计算的支持。当支撑水平发生变化时，应按照第3.1.13节的说明重新公布。
Support for, and advertisement of support for, P2MP MPLS TE path computation MAY be subject to policy, and a PCE MAY hide its P2MP capabilities from certain PCCs by not advertising them through the discovery protocol and not reporting them to the specific PCCs in any PCECP capabilities exchange. Further, a PCE MAY be directed by policy to refuse a P2MP path computation for any reason including, but not limited to, the identity of the PCC that makes the request.
对P2MP MPLS TE路径计算的支持和对P2MP MPLS TE路径计算的支持的公布可能受制于策略，并且PCE可以通过不通过发现协议公布其P2MP能力以及不在任何PCECP能力交换中将其报告给特定pcc来对某些pcc隐藏其P2MP能力。此外，PCE可被策略指示出于任何原因拒绝P2MP路径计算，包括但不限于发出请求的PCC的身份。
PCECP protocol extensions to support P2MP MPLS TE SHOULD be accompanied by MIB objects for the control and monitoring of the protocol and the PCE that performs the computations. The MIB objects MAY be provided in the same MIB module as used for general PCECP control and monitoring or MAY be provided in a new MIB module.
支持P2MP MPLS TE的PCECP协议扩展应附带MIB对象，用于控制和监控协议以及执行计算的PCE。MIB对象可以在用于一般PCECP控制和监控的同一MIB模块中提供，也可以在新的MIB模块中提供。
The MIB objects SHOULD provide the ability to control and monitor all aspects of PCECP relevant to P2MP MPLS TE path computation.
MIB对象应该能够控制和监视与P2MP MPLS TE路径计算相关的PCECP的所有方面。
No changes are necessary to the liveness detection and monitoring requirements as already embodied in [RFC4657]. However, it should be noted that, in general, P2MP computations are likely to take longer than P2P computations. The liveness detection and monitoring features of the PCECP SHOULD take this into account.
[RFC4657]中已经包含的活性检测和监控要求无需更改。然而，应该注意的是，一般来说，P2MP计算可能比P2P计算花费更长的时间。PCECP的活性检测和监控功能应考虑到这一点。
There are no additional requirements beyond those expressed in [RFC4657] for verifying the correct operation of the PCECP. Note that verification of the correct operation of the PCE and its algorithms is out of scope for the protocol requirements, but a PCC MAY send the same request to more than one PCE and compare the results.
除了[RFC4657]中规定的要求外，没有其他要求用于验证PCECP的正确运行。请注意，验证PCE及其算法的正确操作超出协议要求的范围，但PCC可能会向多个PCE发送相同的请求并比较结果。
A PCE operates on a topology graph that may be built using information distributed by TE extensions to the routing protocol operating within the network. In order that the PCE can select a suitable path for the signaling protocol to use to install the P2MP LSP, the topology graph must include information about the P2MP signaling and branching capabilities of each LSR in the network.
PCE在拓扑图上运行，拓扑图可以使用网络内运行的路由协议的TE扩展所分发的信息来构建。为了PCE能够为信令协议选择合适的路径以用于安装P2MP LSP，拓扑图必须包括关于网络中每个LSR的P2MP信令和分支能力的信息。
Whatever means is used to collect the information to build the topology graph, the graph MUST include the requisite information. If the TE extensions to the routing protocol are used, these SHOULD be as described in [RFC5073].
无论使用何种方法收集信息以构建拓扑图，该图必须包含必要的信息。如果使用路由协议的TE扩展，这些扩展应如[RFC5073]中所述。
The use of a PCE to compute P2MP paths is not expected to have significant impact on network operations. However, it should be noted that the introduction of P2MP support to a PCE that already provides P2P path computation might change the loading of the PCE significantly, and that might have an impact on the network behavior, especially during recovery periods immediately after a network failure.
使用PCE计算P2MP路径预计不会对网络运营产生重大影响。然而，应当注意，对已经提供P2P路径计算的PCE引入P2MP支持可能会显著改变PCE的负载，并且这可能会对网络行为产生影响，尤其是在网络故障后的恢复期间。
P2MP computation requests do not raise any additional security issues for the PCECP, as there are no new messages and no new PCC-PCE relationships or transactions introduced.
P2MP计算请求不会给PCECP带来任何额外的安全问题，因为没有新消息，也没有引入新的PCC-PCE关系或事务。
Note, however, that P2MP computation requests are more CPU-intensive and also use more link bandwidth. Therefore, if the PCECP was susceptible to denial of service attacks based on the injection of spurious Path Computation Requests, the support of P2MP path computation would exacerbate the effect.
然而，请注意，P2MP计算请求更需要CPU，并且使用更多的链路带宽。因此，如果PCECP容易受到基于虚假路径计算请求注入的拒绝服务攻击，那么支持P2MP路径计算将加剧这种影响。
It would be possible to consider applying different authorization policies for P2MP Path Computation Requests compared to other requests.
与其他请求相比，可以考虑对PMP路径计算请求应用不同的授权策略。
Thanks to Dean Cheng, Young Lee, Quintin Zhao, Daniel King, Fabien Verhaeghe, and Francis Dupont for their comments and suggestions on this document.
感谢郑院长、杨莉、赵昆廷、丹尼尔·金、法比恩·维哈伊和弗朗西斯·杜邦对本文件的评论和建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.，Ed.，和J.Le Roux，Ed.，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“策略启用路径计算框架”，RFC 53942008年12月。
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, October 2009.
[RFC5671]Yasukawa，S.和A.Farrel，Ed.“路径计算元素（PCE）对点对多点（P2MP）MPLS和GMPLS流量工程（TE）的适用性”，RFC 56712009年10月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]Yasukawa，S.，Ed.“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，2006年4月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]Le Roux，J.，编辑，“路径计算元素（PCE）发现的要求”，RFC 4674，2006年10月。
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4834, April 2007.
[RFC4834]Morin，T.，Ed.“第3层提供商提供的虚拟专用网络（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月。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC5541]Le Roux，JL.，Vasseur，JP.，和Y.Lee，“路径计算元素通信协议（PCEP）中目标函数的编码”，RFC 55412009年6月。
Authors' Addresses
作者地址
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 JAPAN EMail: yasukawa.seisho@lab.ntt.co.jp
日本东京武藏寺3-Chome Musashino Shi，日本靖川诚雄NTT公司9-11，180-8585电子邮件：靖川。seisho@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk