Internet Engineering Task Force (IETF) Q. Zhao
Request for Comments: 7334 D. Dhody
Category: Experimental Huawei Technology
ISSN: 2070-1721 D. King
Old Dog Consulting
Z. Ali
Cisco Systems
R. Casellas
CTTC
August 2014
Internet Engineering Task Force (IETF) Q. Zhao
Request for Comments: 7334 D. Dhody
Category: Experimental Huawei Technology
ISSN: 2070-1721 D. King
Old Dog Consulting
Z. Ali
Cisco Systems
R. Casellas
CTTC
August 2014
PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths
基于PCE的最短约束点对多点域间流量工程标签交换路径计算方法
Abstract
摘要
The ability to compute paths for constrained point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains has been identified as a key requirement for the deployment of P2MP services in MPLS- and GMPLS-controlled networks. The Path Computation Element (PCE) has been recognized as an appropriate technology for the determination of inter-domain paths of P2MP TE LSPs.
跨多个域计算受限点对多点（P2MP）流量工程标签交换路径（TE LSP）路径的能力已被确定为在MPLS和GMPLS控制网络中部署P2MP服务的关键要求。路径计算元件（PCE）被认为是确定P2MP TE LSP域间路径的合适技术。
This document describes an experiment to provide procedures and extensions to the PCE Communication Protocol (PCEP) for the computation of inter-domain paths for P2MP TE LSPs.
本文档描述了一个实验，为PCE通信协议（PCEP）提供程序和扩展，用于计算P2MP TE LSP的域间路径。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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/rfc7334.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7334.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Requirements Language ......................................4
2. Terminology .....................................................5
3. Examination of Existing Mechanisms ..............................6
4. Assumptions .....................................................7
5. Requirements ....................................................8
6. Objective Functions and Constraints .............................9
7. P2MP Path Computation Procedures ...............................10
7.1. General ...................................................10
7.2. Core-Trees ................................................10
7.3. Optimal Core-Tree Computation Procedure ...................13
7.4. Sub-tree Computation Procedures ...........................15
7.5. PCEP Protocol Extensions ..................................15
7.5.1. Extension of RP Object .............................15
7.5.2. Domain and PCE Sequence ............................16
7.6. Using H-PCE for Scalability ...............................16
7.7. Parallelism ...............................................17
8. Protection .....................................................17
8.1. End-to-End Protection .....................................17
8.2. Domain Protection .........................................18
9. Manageability Considerations ...................................18
9.1. Control of Function and Policy ............................18
9.2. Information and Data Models ...............................18
9.3. Liveness Detection and Monitoring .........................19
9.4. Verifying Correct Operation ...............................19
9.5. Requirements on Other Protocols and Functional
Components ................................................19
9.6. Impact on Network Operation ...............................19
9.7. Policy Control ............................................20
10. Security Considerations .......................................20
11. IANA Considerations ...........................................21
12. Acknowledgements ..............................................21
13. References ....................................................21
13.1. Normative References .....................................21
13.2. Informative References ...................................22
14. Contributors' Addresses .......................................24
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Requirements Language ......................................4
2. Terminology .....................................................5
3. Examination of Existing Mechanisms ..............................6
4. Assumptions .....................................................7
5. Requirements ....................................................8
6. Objective Functions and Constraints .............................9
7. P2MP Path Computation Procedures ...............................10
7.1. General ...................................................10
7.2. Core-Trees ................................................10
7.3. Optimal Core-Tree Computation Procedure ...................13
7.4. Sub-tree Computation Procedures ...........................15
7.5. PCEP Protocol Extensions ..................................15
7.5.1. Extension of RP Object .............................15
7.5.2. Domain and PCE Sequence ............................16
7.6. Using H-PCE for Scalability ...............................16
7.7. Parallelism ...............................................17
8. Protection .....................................................17
8.1. End-to-End Protection .....................................17
8.2. Domain Protection .........................................18
9. Manageability Considerations ...................................18
9.1. Control of Function and Policy ............................18
9.2. Information and Data Models ...............................18
9.3. Liveness Detection and Monitoring .........................19
9.4. Verifying Correct Operation ...............................19
9.5. Requirements on Other Protocols and Functional
Components ................................................19
9.6. Impact on Network Operation ...............................19
9.7. Policy Control ............................................20
10. Security Considerations .......................................20
11. IANA Considerations ...........................................21
12. Acknowledgements ..............................................21
13. References ....................................................21
13.1. Normative References .....................................21
13.2. Informative References ...................................22
14. Contributors' Addresses .......................................24
Multicast services are increasingly in demand for high-capacity applications such as multicast VPNs, IPTV (which may be on-demand or streamed), and content-rich media distribution (for example, software distribution, financial streaming, or database replication). The ability to compute constrained Traffic Engineering Label Switched Paths (TE LSPs) for point-to-multipoint (P2MP) LSPs in MPLS and GMPLS networks across multiple domains is therefore required.
多播服务对高容量应用的需求越来越大，如多播VPN、IPTV（可以是按需或流媒体）和内容丰富的媒体分发（例如，软件分发、金融流媒体或数据库复制）。因此，需要能够计算MPLS和GMPLS网络中跨多个域的点对多点（P2MP）LSP的受限流量工程标签交换路径（TE LSP）。
The applicability of the PCE [RFC4655] for the computation of such paths is discussed in [RFC5671], and the requirements placed on the PCE Communication Protocol (PCEP) for this are given in [RFC5862].
[RFC5671]中讨论了PCE[RFC4655]对此类路径计算的适用性，而[RFC5862]中给出了PCE通信协议（PCEP）对此的要求。
This document details the requirements for inter-domain P2MP path computation and then describes the experimental procedure "core-tree" path computation, developed to address the requirements and objectives for inter-domain P2MP path computation.
本文件详细说明了域间P2MP路径计算的要求，然后描述了为满足域间P2MP路径计算的要求和目标而开发的实验程序“核心树”路径计算。
When results of implementation and deployment are available, this document will be updated and refined, and it will then be moved from Experimental status to Standards Track.
当实现和部署的结果可用时，将更新和完善本文档，然后将其从试验状态转移到标准跟踪。
The inter-domain P2MP path computation procedures described in this document are experimental. The experiment is intended to enable research for the usage of the PCE to support inter-domain P2MP path computation.
本文中描述的域间P2MP路径计算程序是实验性的。该实验旨在研究如何使用PCE来支持域间P2MP路径计算。
This document is not intended to replace the intra-domain P2MP path computation approach defined by [RFC6006] and will not impact existing PCE procedures and operations.
本文件不打算取代[RFC6006]定义的域内P2MP路径计算方法，也不会影响现有的PCE程序和操作。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Terminology used in this document is consistent with the related MPLS/GMPLS and PCE documents [RFC4461], [RFC4655], [RFC4875], [RFC5376], [RFC5440], [RFC5441], [RFC5671], and [RFC5862].
本文件中使用的术语与相关MPLS/GMPLS和PCE文件[RFC4461]、[RFC4655]、[RFC4875]、[RFC5376]、[RFC5440]、[RFC5441]、[RFC5671]和[RFC5862]一致。
Additional terms are defined below:
其他术语定义如下：
Core-Tree: a P2MP tree where the root is the ingress Label Switching Router (LSR) and the leaf nodes are the entry boundary nodes of the leaf domains.
核心树：P2MP树，其中根是入口标签交换路由器（LSR），叶节点是叶域的入口边界节点。
Entry BN of domain(n): a boundary node (BN) connecting domain(n-1) to domain(n) along a determined sequence of domains.
域（n）的入口BN：沿确定的域序列将域（n-1）连接到域（n）的边界节点（BN）。
Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along a determined sequence of domains.
域（n）的出口BN：沿着确定的域序列将域（n）连接到域（n+1）的BN。
H-PCE: Hierarchical PCE (as per [RFC6805]).
H-PCE：分级PCE（根据[RFC6805]）。
Leaf Domain: a domain with one or more leaf nodes.
叶域：具有一个或多个叶节点的域。
Path Tree: a set of LSRs and TE links that comprise the path of a P2MP TE LSP from the ingress LSR to all egress LSRs (the leaf nodes).
路径树：一组LSR和TE链路，包括P2MP TE LSP从入口LSR到所有出口LSR（叶节点）的路径。
Path Domain Sequence: the known sequence of domains for a path between the root domain and a leaf domain.
路径域序列：根域和叶域之间路径的已知域序列。
Path Domain Tree: the tree formed by the domains that the P2MP path crosses, where the source (ingress) domain is the root domain.
路径域树：由P2MP路径交叉的域形成的树，其中源（入口）域是根域。
PCE(i): a PCE that performs path computations for domain(i).
PCE（i）：为域（i）执行路径计算的PCE。
Root Domain: the domain that includes the ingress (root) LSR.
根域：包含入口（根）LSR的域。
Sub-tree: a P2MP tree where the root is the selected entry BN of the leaf domain and the leaf nodes are the destinations (leaves) in that domain. The sub-trees are grafted to the core-tree.
子树：P2MP树，其中根是叶域的选定条目BN，叶节点是该域中的目的地（叶）。这些子树被嫁接到核心树上。
Transit/Branch Domain: a domain that has an upstream and one or more downstream neighbor domains.
传输/分支域：具有上游和一个或多个下游邻居域的域。
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. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed.
[RFC4655]中定义的路径计算元素（PCE）是能够基于网络图计算网络路径或路由并应用计算约束的实体。路径计算客户端（PCC）可以向PCE请求要计算的路径。
[RFC4875] describes how to set up P2MP TE LSPs for use in MPLS- and GMPLS-controlled networks. The PCE is identified as a suitable application for the computation of paths for P2MP TE LSPs [RFC5671].
[RFC4875]描述了如何设置P2MP TE LSP，以便在MPLS和GMPLS控制的网络中使用。PCE被确定为P2MP TE LSP路径计算的合适应用[RFC5671]。
[RFC5441] specifies a procedure relying on the use of multiple PCEs to compute point-to-point (P2P) inter-domain constrained shortest paths across a predetermined sequence of domains, using a Backward-Recursive PCE-Based Computation (BRPC) technique. The technique can be combined with the use of Path-Keys [RFC5520] to preserve confidentiality across domains, which is sometimes required when domains are managed by different Service Providers.
[RFC5441]指定了一个程序，该程序依赖于使用多个PCE，使用基于PCE的反向递归计算（BRPC）技术，计算跨预定域序列的点到点（P2P）域间约束最短路径。该技术可以与使用路径密钥[RFC5520]相结合，以保持跨域的机密性，这在由不同服务提供商管理域时有时是必需的。
PCEP [RFC5440] was extended for point-to-multipoint (P2MP) path computation requests in [RFC6006].
PCEP[RFC5440]在[RFC6006]中针对点对多点（P2MP）路径计算请求进行了扩展。
As discussed in [RFC4461], a P2MP tree is the ordered set of LSRs and TE links that comprise the path of a P2MP TE LSP from its ingress LSR to all of its egress LSRs. A P2MP LSP is set up with TE constraints and allows efficient packet or data replication at various branching points in the network. As per [RFC5671], selection of branch points is fundamental to the determination of the paths for a P2MP TE LSP. Not only is this selection constrained by the network topology and available network resources, but it is also determined by the objective functions (OFs) that may be applied to path computation.
如[RFC4461]中所述，P2MP树是LSR和TE链路的有序集合，它们构成了P2MP TE LSP从其入口LSR到其所有出口LSR的路径。P2MP LSP设置有TE约束，允许在网络中的各个分支点进行有效的数据包或数据复制。根据[RFC5671]，分支点的选择是确定P2MP TE LSP路径的基础。这种选择不仅受到网络拓扑和可用网络资源的约束，而且还取决于可应用于路径计算的目标函数（OFs）。
Generally, an inter-domain P2MP tree (i.e., a P2MP tree with source and at least one destination residing in different domains) is particularly difficult to compute even for a distributed PCE architecture. For instance, while the BRPC may be well-suited for P2P paths, P2MP path computation involves multiple branching path segments from the source to the multiple destinations. As such, inter-domain P2MP path computation may result in a plurality of per-domain path options that may be difficult to coordinate efficiently and effectively between domains. That is, when one or more domains have multiple ingress and/or egress boundary nodes (i.e., when the domains are multiply inter-connected), existing techniques may be convoluted when used to determine which boundary node of another domain will be utilized for the inter-domain P2MP tree, and there is no way to limit the computation of the P2MP tree to those utilized boundary nodes.
通常，即使对于分布式PCE体系结构，域间P2MP树（即，源和至少一个目的地位于不同域中的P2MP树）也特别难以计算。例如，虽然BRPC可能非常适合P2P路径，但是P2MP路径计算涉及从源到多个目的地的多个分支路径段。因此，域间P2MP路径计算可能导致多个域内路径选项，这些路径选项可能难以在域之间高效和有效地协调。也就是说，当一个或多个域具有多个入口和/或出口边界节点时（即，当域被多重互连时），当用于确定另一个域的哪个边界节点将被用于域间P2MP树时，现有技术可被卷积，并且没有办法将P2MP树的计算限制到那些使用的边界节点。
A trivial solution to the computation of the inter-domain P2MP tree would be to compute shortest inter-domain P2P paths from source to each destination and then combine them to generate an inter-domain, shortest-path-to-destination P2MP tree. This solution, however, cannot be used to trade cost to destination for overall tree cost (i.e., it cannot produce a Minimum Cost Tree (MCT)), and in the context of inter-domain P2MP TE LSPs, it cannot be used to reduce the number of domain boundary nodes that are transited. Computing P2P TE LSPs individually does not guarantee the generation of an optimal P2MP tree for every definition of "optimal" in every topology.
计算域间P2MP树的一个简单解决方案是计算从源到每个目的地的最短域间P2P路径，然后将它们组合起来生成域间、到目的地的最短路径P2MP树。然而，该解决方案不能用于以目标成本换取总体树成本（即，它不能生成最小成本树（MCT）），并且在域间P2MP TE LSP的上下文中，它不能用于减少传输的域边界节点的数量。单独计算P2P TE LSP不能保证为每个拓扑中的每个“最优”定义生成最优P2MP树。
Per-domain path computation [RFC5152] may be used to compute P2MP multi-domain paths but may encounter the issues previously described. Furthermore, this approach may be considered to have scaling issues during LSP setup. That is, the LSP to each leaf is signaled separately, and each boundary node needs to perform path computation for each leaf.
每域路径计算[RFC5152]可用于计算P2MP多域路径，但可能会遇到前面描述的问题。此外，在LSP设置期间，此方法可能会被视为存在缩放问题。也就是说，到每个叶的LSP被单独地发信号，并且每个边界节点需要为每个叶执行路径计算。
P2MP MCT, i.e., a computation that guarantees the least cost resulting tree, typically is an NP-complete problem. Moreover, adding and/or removing a single destination to/from the tree may result in an entirely different tree. In this case, frequent MCT path computation requests may prove computationally intensive, and the resulting frequent tunnel reconfiguration may even cause network destabilization.
P2MP MCT，即保证生成树的成本最小的计算，通常是一个NP完全问题。此外，向树添加和/或从树中删除单个目的地可能会导致完全不同的树。在这种情况下，频繁的MCT路径计算请求可能会导致计算密集，由此产生的频繁隧道重新配置甚至可能导致网络不稳定。
This document presents a solution, procedures, and extensions to PCEP to support P2MP inter-domain path computation.
本文档介绍了支持P2MP域间路径计算的PCEP解决方案、过程和扩展。
Within this document we make the following assumptions:
在本文件中，我们做出以下假设：
o Due to deployment and commercial limitations (e.g., inter-AS (Autonomous System) peering agreements), the path domain tree will be known in advance.
o 由于部署和商业限制（例如，AS（自治系统）间对等协议），路径域树将提前知道。
o Each PCE knows about any leaf LSRs in the domain it serves.
o 每个PCE都知道它所服务的域中的任何叶LSR。
Additional assumptions are documented in [RFC5441] and are not repeated here.
[RFC5441]中记录了其他假设，此处不再重复。
This section summarizes the requirements specific to computing inter-domain P2MP paths. In these requirements, we note that the actual computation time taken by any PCE implementation is outside the scope of this document, but we observe that reducing the complexity of the required computations has a beneficial effect on the computation time regardless of implementation. Additionally, reducing the number of message exchanges and the amount of information exchanged will reduce the overall computation time for the entire P2MP tree. We refer to the "complexity of the computation" as the impact on these aspects of path computation time as various parameters of the topology and the P2MP TE LSP are changed.
本节总结了计算域间P2MP路径的特定要求。在这些要求中，我们注意到，任何PCE实施所花费的实际计算时间不在本文件的范围内，但我们观察到，降低所需计算的复杂性对计算时间有着有益的影响，而与实施无关。此外，减少消息交换的数量和交换的信息量将减少整个P2MP树的总体计算时间。我们将“计算复杂性”称为拓扑和P2MP TE LSP的各种参数改变时对路径计算时间的这些方面的影响。
It is also important that the solution can preserve confidentiality across domains, which is required when domains are managed by different Service Providers via the Path-Key mechanism [RFC5520].
同样重要的是，解决方案可以跨域保持机密性，这是由不同的服务提供商通过路径密钥机制管理域时所必需的[RFC5520]。
Other than the requirements specified in [RFC5862], a number of requirements specific to inter-domain P2MP are detailed below:
除[RFC5862]中规定的要求外，域间P2MP的一些特定要求详述如下：
1. The complexity of the computation for each sub-tree within each domain SHOULD be dependent only on the topology of the domain, and it SHOULD be independent of the domain sequence.
1. 每个域中每个子树的计算复杂度应仅取决于域的拓扑结构，并且应独立于域序列。
2. The number of PCReq (Path Computation Request) and PCRep (Path Computation Reply) messages SHOULD be independent of the number of multicast destinations in each domain.
2. PCReq（路径计算请求）和PCRep（路径计算回复）消息的数量应独立于每个域中的多播目的地的数量。
3. It SHOULD be possible to specify the domain entry and exit nodes in the PCReq.
3. 应该可以在PCReq中指定域入口和出口节点。
4. Specifying which nodes are to be used as branch nodes SHOULD be supported in the PCReq.
4. PCReq中应支持指定要用作分支节点的节点。
5. Reoptimization of existing sub-trees SHOULD be supported.
5. 应支持现有子树的重新优化。
6. It SHOULD be possible to compute diverse P2MP paths from existing P2MP paths.
6. 应该可以从现有P2MP路径计算不同的P2MP路径。
For the computation of a single or a set of P2MP TE LSPs, a request to meet specific optimization criteria, called an objective function (OF), MAY be used. SPT (Shortest Path Tree) and MCT (Minimum Cost Tree), defined in [RFC6006], are two such OF optimization criteria for the sub-tree within each domain used to select the "best" candidate path.
对于单个或一组P2MP TE LSP的计算，可使用满足特定优化标准的请求，称为目标函数（of）。[RFC6006]中定义的SPT（最短路径树）和MCT（最小成本树）是每个域中用于选择“最佳”候选路径的子树的两个优化标准。
In addition to the OFs, the following constraints MAY also be beneficial for inter-domain P2MP path computation:
除OFs外，以下约束也有利于域间P2MP路径计算：
1. The computed P2MP "core-tree" SHOULD be optimal when only considering the paths to the leaf domain entry BNs.
1. 当只考虑到叶域入口BNs的路径时，计算出的P2MP“核心树”应该是最优的。
2. Grafting and pruning of multicast destinations (sub-trees) within a leaf domain SHOULD ensure minimal impact on other domains and on the core-tree.
2. 叶域内多播目的地（子树）的嫁接和修剪应确保对其他域和核心树的影响最小。
3. It SHOULD be possible to choose to optimize the core-tree.
3. 应该可以选择优化核心树。
4. It SHOULD be possible to choose to optimize the entire tree (P2MP LSP).
4. 应该可以选择优化整个树（P2MP LSP）。
5. It SHOULD be possible to combine the aforementioned OFs and constraints for P2MP path computation.
5. 应该可以将上述OFs和约束结合起来进行P2MP路径计算。
When implementing and operating P2MP LSPs, the following need to be taken into consideration:
在实施和运行P2MP LSP时，需要考虑以下因素：
o The complexity of computation.
o 计算的复杂性。
o The optimality of the tree (core-tree as well as full P2MP LSP tree).
o 树的最优性（核心树和完整P2MP LSP树）。
o The stability of the core-tree.
o 核心树的稳定性。
The solution SHOULD allow these trade-offs to be made at computation time.
解决方案应允许在计算时进行这些权衡。
The algorithms used to compute optimal paths using a combination of OFs and multiple constraints are out of the scope of this document.
使用OFs和多个约束组合计算最优路径所用的算法不在本文档的范围内。
A P2MP path computation can be broken down into two steps: core-tree computation and grafting of sub-trees. Breaking the procedure into these specific steps has the following impact, allowing the core-tree-based solution to provide an optimal inter-domain P2MP TE LSP:
P2MP路径计算可分为两个步骤：核心树计算和子树嫁接。将过程分解为这些特定步骤具有以下影响，从而使基于核心树的解决方案能够提供最佳的域间P2MP TE LSP：
o The core-tree and sub-tree are smaller in comparison to the full P2MP tree and are thus easier to compute.
o 与完整的P2MP树相比，核心树和子树更小，因此更易于计算。
o An implementation MAY choose to keep the core-tree fairly static or computed offline (trade-off with optimality).
o 一个实现可以选择保持核心树相当静态或离线计算（与最佳性的权衡）。
o Adding/pruning of leaves requires changes to the sub-tree in the leaf-domain only.
o 添加/修剪叶只需要更改叶域中的子树。
o The PCEP message size is smaller in comparison.
o 相比之下，PCEP消息的大小更小。
The following sub-sections describe the core-tree-based mechanism, including procedures and PCEP extensions that satisfy the requirements and objectives specified in Sections 5 and 6 of this document.
以下小节描述了基于核心树的机制，包括满足本文件第5节和第6节规定的要求和目标的程序和PCEP扩展。
A core-tree is defined as a tree that satisfies the following conditions:
核心树定义为满足以下条件的树：
o The root of the core-tree is the ingress LSR in the root domain.
o 核心树的根是根域中的入口LSR。
o The leaves of the core-tree are the entry boundary nodes in the leaf domains.
o 核心树的叶子是叶子域中的入口边界节点。
To support confidentiality, these nodes and links MAY be hidden using the Path-Key mechanism [RFC5520], but they MUST be computed and be a part of the core-tree.
为了支持机密性，这些节点和链接可以使用路径密钥机制[RFC5520]隐藏，但它们必须经过计算，并且是核心树的一部分。
For example, consider the domain tree in Figure 1, representing a domain tree of 6 domains and part of the resulting core-tree, which satisfies the aforementioned conditions.
例如，考虑图1中的域树，表示6个域的域树和所得到的核心树的一部分，满足上述条件。
+----------------+
| |Domain D1
| R |
| |
| A |
| |
+-B------------C-+
/ \
/ \
/ \
Domain D2 / \ Domain D3
+-------------D--+ +-----E----------+
| | | |
| F | | |
| G | | H |
| | | |
| | | |
+-I--------------+ +-J------------K-+
/\ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ Domain D4 \ Domain D5 / Domain D6 \
+-L-------------W+ +------P---------+ +-----------T----+
| | | | | |
| | | Q | | U |
| M O | | S | | |
| | | | | V |
| N | | R | | |
+----------------+ +----------------+ +----------------+
+----------------+
| |Domain D1
| R |
| |
| A |
| |
+-B------------C-+
/ \
/ \
/ \
Domain D2 / \ Domain D3
+-------------D--+ +-----E----------+
| | | |
| F | | |
| G | | H |
| | | |
| | | |
+-I--------------+ +-J------------K-+
/\ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ Domain D4 \ Domain D5 / Domain D6 \
+-L-------------W+ +------P---------+ +-----------T----+
| | | | | |
| | | Q | | U |
| M O | | S | | |
| | | | | V |
| N | | R | | |
+----------------+ +----------------+ +----------------+
Figure 1: Domain Tree Example
图1：域树示例
(R)
|
(A)
/ \
/ \
(B) (C)
/ \
/ \
(D) (E)
/ |
/ |
(G) (H)
/ / \
/ / \
(I) (J) (K)
/ \ / \
/ \ / \
(L) (W) (P) (T)
(R)
|
(A)
/ \
/ \
(B) (C)
/ \
/ \
(D) (E)
/ |
/ |
(G) (H)
/ / \
/ / \
(I) (J) (K)
/ \ / \
/ \ / \
(L) (W) (P) (T)
Figure 2: Core-Tree
图2：核心树
A core-tree is computed such that the root of the tree is R and the leaf nodes are the entry nodes of the destination domains (L, W, P, and T). The Path-Key mechanism can be used to hide the internal nodes and links in the final core-tree as shown below for domains D2 and D3 (nodes G and H are hidden via Path-Keys PK1 and PK2, respectively).
计算核心树时，树的根是R，叶节点是目标域（L、W、P和T）的入口节点。路径键机制可用于隐藏最终核心树中的内部节点和链接，如下所示，用于域D2和D3（节点G和H分别通过路径键PK1和PK2隐藏）。
(R)
|
(A)
/ \
/ \
(B) (C)
/ \
/ \
(D) (E)
/ |
/ |
|PK1| |PK2|
/ / \
/ / \
(I) (J) (K)
/ \ / \
/ \ / \
(L) (W) (P) (T)
(R)
|
(A)
/ \
/ \
(B) (C)
/ \
/ \
(D) (E)
/ |
/ |
|PK1| |PK2|
/ / \
/ / \
(I) (J) (K)
/ \ / \
/ \ / \
(L) (W) (P) (T)
Figure 3: Core-Tree with Path-Key
图3：带路径键的核心树
Applying the core-tree procedure to large groups of domains, such as the Internet, is not considered feasible or desirable and is out of the scope of this document.
将核心树程序应用于大型域组（如互联网）被认为是不可行或不可取的，不在本文档的范围内。
The following extended BRPC-based procedure can be used to compute the core-tree. Note that a root PCE MAY further use its own enhanced optimization techniques in the future to compute the core-tree.
以下基于BRPC的扩展过程可用于计算核心树。注意，根PCE将来可能进一步使用其自己的增强优化技术来计算核心树。
A BRPC-based core-tree path computation procedure is described below:
基于BRPC的核心树路径计算过程描述如下：
1. Use the BRPC procedures to compute the VSPT(i) (Virtual Shortest Path Tree) for each leaf BN(i), i=1 to n, where n is the total number of entry nodes for all the leaf domains. In each VSPT(i), there are a number of P(i) paths.
1. 使用BRPC过程计算每个叶BN（i）的VSPT（i）（虚拟最短路径树），i=1到n，其中n是所有叶域的入口节点总数。在每个VSPT（i）中，有许多P（i）路径。
2. When the root PCE has computed all the VSPT(i), i=1 to n, take one path from each VSPT and form all possible sets of paths. We call them PathSet(j), j=1 to M, where M=P(1)xP(2)...xP(n).
2. 当根PCE计算了所有VSPT（i）时，i＝1到n，从每个VSPT取一条路径并形成所有可能的路径集。我们称它们为路径集（j），j=1到M，其中M=P（1）xP（2）…xP（n）。
3. For each PathSet(j), there are n S2L (Source-to-Leaf) BN paths. Form these n paths into a core-tree(j).
3. 对于每个路径集（j），有n条S2L（源到叶）BN路径。将这n条路径形成核心树（j）。
4. There will be M number core-trees computed from step 3. An optimal core-tree is selected based on the OF and constraints.
4. 从第3步计算出M个核心树。基于OF和约束选择最优核心树。
Note that since the point-to-point BRPC procedure is used to compute VSPT, the path request and response message formats defined in [RFC5440] are used.
注意，由于点对点BRPC过程用于计算VSPT，因此使用[RFC5440]中定义的路径请求和响应消息格式。
Also note that the application of BRPC in the aforementioned procedure differs from the typical one since paths returned from a downstream PCE are not necessarily pruned from the solution set (extended VSPT) by intermediate PCEs. The reason for this is that if the PCE in a downstream domain does the pruning and returns the single optimal sub-path to the upstream PCE, the combination of these single optimal sub-paths into a core-tree is not necessarily optimal even if each S2L (Source-to-Leaf) sub-path is optimal.
还请注意，上述过程中BRPC的应用与典型过程不同，因为从下游PCE返回的路径不一定由中间PCE从解决方案集（扩展VSPT）修剪。其原因是，如果下游域中的PCE进行修剪并将单个最优子路径返回给上游PCE，则即使每个S2L（源到叶）子路径是最优的，这些单个最优子路径到核心树的组合也不一定是最优的。
Without trimming, the ingress PCE will obtain all the possible S2L sub-paths set for the entry boundary nodes of the leaf domain. By looking through all the combinations and taking one sub-path from each set to build one tree, the PCE will then select the optimal core-tree.
在不修剪的情况下，入口PCE将获得为叶域的入口边界节点设置的所有可能的S2L子路径。通过查看所有组合并从每组中选取一个子路径来构建一棵树，PCE将选择最佳核心树。
A PCE MAY add equal-cost paths within the domain while constructing an extended VSPT. This will provide the ingress PCE more candidate paths for an optimal core-tree.
在构造扩展的VSPT时，PCE可以在域内添加相等的代价路径。这将为入口PCE提供更多候选路径以获得最佳核心树。
The proposed method may present a scalability problem for the dynamic computation of the core-tree (by iterative checking of all combinations of the solution space), especially with dense/meshed domains. Considering a domain sequence D1, D2, D3, D4, where the leaf boundary node is at domain D4, PCE(4) will return 1 path. PCE(3) will return N paths, where N is E(3) x X(3), where E(k) x X(k) denotes the number of entry nodes times the number of exit nodes for that domain. PCE(2) will return M paths, where M = E(2) x X(2) x N = E(2) x X(2) x E(3) x X(3) x 1, etc. Generally speaking, the number of potential paths at the ingress PCE Q = prod E(k) x X(k).
所提出的方法可能会为核心树的动态计算（通过迭代检查解空间的所有组合）带来可伸缩性问题，特别是对于密集/网格区域。考虑域序列D1、D2、D3、D4，其中叶边界节点位于域D4，PCE（4）将返回1路径。PCE（3）将返回N条路径，其中N是E（3）x（3），其中E（k）x（k）表示该域的入口节点数乘以出口节点数。PCE（2）将返回M条路径，其中M=E（2）x（2）x N=E（2）x（2）x E（3）x（3）x 1等。一般来说，入口PCE的潜在路径数Q=prod E（k）x（k）。
Consequently, it is expected that the core-tree will typically be computed offline, without precluding the use of dynamic, online mechanisms such as the one presented here, in which case it SHOULD be possible to configure transit PCEs to control the number of paths sent upstream during BRPC (trading trimming for optimality at the point of trimming and downwards).
因此，预计核心树通常将离线计算，而不排除使用动态在线机制，如本文所述的机制，在这种情况下，应该可以配置传输PCE以控制BRPC期间向上游发送的路径数量（在微调点和向下点，用微调换取最优值）。
Once the core-tree is built, the grafting of all the leaf nodes from each domain to the core-tree can be achieved by a number of algorithms. One algorithm for doing this phase is that the root PCE will send the request with the C-bit set (as defined in Section 7.5.1 of this document) for the path computation to the destination(s) directly to the PCE where the destination(s) belong(s) along with the core-tree computed per Section 7.2.
一旦建立了核心树，就可以通过多种算法将每个域的所有叶节点嫁接到核心树上。执行此阶段的一种算法是，根PCE将使用C位集（如本文件第7.5.1节中所定义）将路径计算请求直接发送到目的地所在的PCE，以及根据第7.2节计算的核心树。
This approach requires that the root PCE manage a potentially large number of adjacencies (either in persistent or non-persistent mode), including PCEP adjacencies to PCEs that are not within neighbor domains.
这种方法要求根PCE管理可能大量的邻接（在持久或非持久模式下），包括不在相邻域内的PCE的PCEP邻接。
An alternative would involve establishing PCEP adjacencies that correspond to the PCE domain tree. This would require that branch PCEs forward requests and responses from the root PCE towards the leaf PCEs and vice versa.
另一种方法是建立对应于PCE域树的PCEP邻接。这将要求分支PCE将请求和响应从根PCE转发到叶PCE，反之亦然。
Note that the P2MP path request and response format is as per [RFC6006], where Record Route Objects (RROs) are used to carry the core-tree paths in the P2MP grafting request.
请注意，P2MP路径请求和响应格式符合[RFC6006]，其中记录路由对象（RRO）用于承载P2MP请求中的核心树路径。
The algorithms to compute the optimal large sub-tree are outside the scope of this document.
计算最优大子树的算法不在本文档的范围内。
This experiment will be carried out by extending the RP (Request Parameters) object (defined in [RFC5440]) used in PCEP requests and responses.
该实验将通过扩展PCEP请求和响应中使用的RP（请求参数）对象（在[RFC5440]中定义）来执行。
The extended format of the RP object body to include the C-bit is as follows:
包含C位的RP对象体的扩展格式如下：
The C-bit is added in the flag bits field of the RP object to signal the receiver of the message whether or not the request/reply is for inter-domain P2MP core-tree.
将C位添加到RP对象的标志位字段中，以向消息接收方发出信号，表明请求/应答是否用于域间P2MP核心树。
The following flag is added in this document:
此文档中添加了以下标志：
Bit Number Name Flag 17 Core-tree computation (C-bit)
位号名称标志17核心树计算（C位）
C-bit (Core-Tree bit - 1 bit):
C位（核心树位-1位）：
0: Indicates that this is not for an inter-domain P2MP core-tree.
0：表示这不适用于域间P2MP核心树。
1: Indicates that this is a PCEP request or a response for the computation of an inter-domain core-tree or for the grafting of a sub-tree to an inter-domain core-tree.
1：表示这是用于计算域间核心树或将子树嫁接到域间核心树的PCEP请求或响应。
The procedure described in this document requires the domain tree to be known in advance. This information MAY be either administratively predetermined or dynamically discovered by some means, such as the Hierarchical PCE (H-PCE) framework [RFC6805], or derived through the IGP/BGP routing information.
本文档中描述的过程要求提前知道域树。该信息可以是管理上预先确定的，或者通过诸如分层PCE（H-PCE）框架[RFC6805]之类的方法动态发现的，或者通过IGP/BGP路由信息导出的。
Examples of ways to encode the domain path tree are found in [RFC5886], which uses PCE-ID Objects, and [DOMAIN-SEQ].
使用PCE-ID对象的[RFC5886]和[domain-SEQ]中提供了域路径树编码方法的示例。
The ingress/root PCE is responsible for the core-tree computation as well as grafting of sub-trees into the multi-domain tree. Therefore, the ingress/root PCE will receive all computed path segments from all the involved domains. When the ingress/root PCE chooses to have a PCEP session with all involved PCEs, this may cause an excessive number of sessions or added complexity in implementations.
入口/根PCE负责核心树计算以及将子树嫁接到多域树中。因此，入口/根PCE将接收来自所有相关域的所有计算路径段。当入口/根PCE选择与所有相关PCE进行PCEP会话时，这可能导致会话数量过多或在实现中增加复杂性。
The H-PCE framework [RFC6805] may be used to establish a dedicated PCE with the capability (memory and CPU) and knowledge to maintain the necessary PCEP sessions. The parent PCE would be responsible for sending an intra-domain path computation request to the PCEs, combining them, and returning the overall P2MP tree.
H-PCE框架[RFC6805]可用于建立具有维护必要PCEP会话的能力（内存和CPU）和知识的专用PCE。父PCE将负责向PCE发送域内路径计算请求，合并它们，并返回整个P2MP树。
In order to minimize latency in path computation in multi-domain networks, intra-domain path segments and intra-domain sub-trees can be computed in parallel when possible. The proposed procedures in this document present opportunities for parallelism:
为了减少多域网络中路径计算的延迟，可以在可能的情况下并行计算域内路径段和域内子树。本文件中的拟议程序提供了并行性的机会：
1. The BRPC procedure for each leaf boundary node can be launched in parallel by the ingress/root PCE for dynamic computation of the core-tree.
1. 每个叶边界节点的BRPC程序可由入口/根PCE并行启动，用于核心树的动态计算。
2. The grafting of sub-trees can be triggered in parallel once the core-tree is computed.
2. 一旦计算出核心树，就可以并行地触发子树的嫁接。
One of the potential issues of parallelism is that the ingress PCE would require a potentially high number of PCEP adjacencies to "remote" PCEs at the same time; this situation may not be desirable.
并行性的潜在问题之一是，入口PCE将同时要求与“远程”PCE的PCEP邻接的潜在高数量；这种情况可能不可取。
It is envisaged that protection may be required when deploying and using inter-domain P2MP TE LSPs. The procedures and mechanisms defined in this document do not prohibit the use of existing and proposed types of protection, including end-to-end protection [RFC4872] and domain protection schemes.
设想在部署和使用域间P2MP TE LSP时可能需要保护。本文件中定义的程序和机制不禁止使用现有和拟议的保护类型，包括端到端保护[RFC4872]和域保护方案。
Segment or facility (link and node) protection is problematic in inter-domain environments due to the limit of fast reroute (FRR) [RFC4875] requiring knowledge of its next hop across domain boundaries while maintaining domain confidentiality. However, the FRR protection might be implemented if next-hop information was known in advance.
网段或设施（链路和节点）保护在域间环境中存在问题，因为快速重路由（FRR）[RFC4875]的限制要求在保持域机密性的同时了解其跨域边界的下一跳。然而，如果预先知道下一跳信息，则可以实现FRR保护。
An end-to-end protection (for nodes and links) principle can be applied for computing backup P2MP TE LSPs. During computation of the core-tree and sub-trees, protection may also be taken into consideration. A PCE may compute the primary and backup P2MP TE LSP together or sequentially.
端到端保护（针对节点和链路）原则可用于计算备份P2MP TE LSP。在计算核心树和子树时，还可以考虑保护。PCE可以一起或顺序计算主P2MP TE LSP和备份P2MP TE LSP。
In this protection scheme, a backup P2MP tree can be computed that excludes the transit/branch domain completely. A backup domain path tree is needed with the same source domain and destination domains and a new set of transit domains. The backup path tree can be applied to the above procedure to obtain the backup P2MP TE LSP with disjoint transit domains.
在此保护方案中，可以计算完全排除传输/分支域的备份P2MP树。需要具有相同源域和目标域以及一组新的传输域的备份域路径树。备份路径树可应用于上述过程，以获得具有不相交传输域的备份P2MP TE LSP。
[RFC5862] describes various manageability requirements in support of P2MP path computation when applying PCEP. This section describes how the manageability requirements mentioned in [RFC5862] are supported in the context of PCEP extensions specified in this document.
[RFC5862]描述了应用PCEP时支持P2MP路径计算的各种可管理性要求。本节描述了[RFC5862]中提到的可管理性要求如何在本文档中指定的PCEP扩展上下文中得到支持。
Note that [RFC5440] describes various manageability considerations in PCEP, and most of the manageability requirements mentioned in [RFC6006] are already covered there.
请注意，[RFC5440]描述了PCEP中的各种可管理性注意事项，[RFC6006]中提到的大多数可管理性要求已经在这里介绍过。
In addition to the PCE configuration parameters listed in [RFC5440] and [RFC6006], the following additional parameters might be required:
除了[RFC5440]和[RFC6006]中列出的PCE配置参数外，可能还需要以下附加参数：
o The ability to enable or disable multi-domain P2MP path computations on the PCE.
o 在PCE上启用或禁用多域P2MP路径计算的能力。
o Configuration of the PCE to enable or disable the advertisement of its multi-domain P2MP path computation capability.
o 配置PCE以启用或禁用其多域P2MP路径计算能力的播发。
A number of MIB objects have been defined for general PCEP control and monitoring of P2P computations in [PCEP-MIB]. [RFC5862] specifies that MIB objects will be required to support the control and monitoring of the protocol extensions defined in this document. [PCEP-P2MP-MIB] describes managed objects for modeling of PCEP communications between a PCC and PCE, communication between PCEs, and P2MP path computation requests and responses.
[PCEP-MIB]中定义了许多MIB对象，用于一般PCEP控制和监控P2P计算。[RFC5862]规定需要MIB对象来支持本文档中定义的协议扩展的控制和监视。[PCEP-P2MP-MIB]描述用于对PCC和PCE之间的PCEP通信、PCE之间的通信以及P2MP路径计算请求和响应进行建模的托管对象。
No changes are necessary to the liveness detection and monitoring requirements as already embodied in [RFC4657].
[RFC4657]中已经包含的活性检测和监控要求无需更改。
It should be noted that multi-domain P2MP computations are likely to take longer than P2P computations and single-domain P2MP computations. The liveness detection and monitoring features of the PCEP SHOULD take this into account.
应注意，多域P2MP计算可能比P2P计算和单域P2MP计算花费更长的时间。PCEP的活性检测和监测功能应考虑到这一点。
There are no additional requirements beyond those expressed in [RFC4657] for verifying the correct operation of the PCEP. Note that verification of the correct operation of the PCE and its algorithms is out of the scope of the protocol requirements, but a PCC MAY send the same request to more than one PCE and compare the results.
除了[RFC4657]中规定的要求外，没有其他要求用于验证PCEP的正确操作。请注意，验证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 TE LSP, the topology graph MUST include information about the P2MP signaling and branching capabilities of each LSR in the network.
PCE在拓扑图上运行，拓扑图可以使用网络内运行的路由协议的TE扩展所分发的信息来构建。为了PCE能够为信令协议选择合适的路径以用于安装P2MP TE LSP，拓扑图必须包括关于网络中每个LSR的P2MP信令和分支能力的信息。
Mechanisms for the knowledge of other domains and the discovery of corresponding PCEs and their capabilities SHOULD be provided, and this information MAY be collected by other mechanisms.
应提供了解其他领域和发现相应PCE及其能力的机制，这些信息可由其他机制收集。
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的负载，并且这可能会对网络行为产生影响，尤其是在网络故障后的恢复期间。
The dynamic computation of core-trees might also have an impact on the load of the involved PCEs as well as path computation times.
核心树的动态计算也可能会影响相关PCE的负载以及路径计算时间。
It should be noted that pre-computing and maintaining domain trees might introduce considerable administration effort for the operator.
应该注意的是，预计算和维护域树可能会给操作员带来相当大的管理工作量。
[RFC5394] provides additional details on policy within the PCE architecture and also provides context for the support of PCE Policy. They are also applicable to inter-domain P2MP path computation via the core-tree mechanism.
[RFC5394]提供了有关PCE体系结构中策略的更多详细信息，还提供了支持PCE策略的上下文。它们也适用于通过核心树机制进行域间P2MP路径计算。
As described in [RFC5862], P2MP path computation requests are more CPU-intensive and also utilize more link bandwidth. In the event of an unauthorized P2MP path computation request or a denial-of-service attack, the subsequent PCEP requests and processing may be disruptive to the network. Consequently, it is important that implementations conform to the relevant security requirements of [RFC5440] that specifically help to minimize or negate unauthorized P2MP path computation requests and denial-of-service attacks. These mechanisms include:
如[RFC5862]中所述，P2MP路径计算请求更占用CPU，并且还利用了更多链路带宽。如果发生未经授权的P2MP路径计算请求或拒绝服务攻击，后续PCEP请求和处理可能会中断网络。因此，重要的是实现符合[RFC5440]的相关安全要求，特别有助于最小化或消除未经授权的P2MP路径计算请求和拒绝服务攻击。这些机制包括：
o Securing the PCEP session requests and responses using TCP security techniques (Section 10.2 of [RFC5440]).
o 使用TCP安全技术保护PCEP会话请求和响应（RFC5440第10.2节）。
o Authenticating the PCEP requests and responses to ensure the message is intact and sent from an authorized node (Section 10.3 of [RFC5440]).
o 验证PCEP请求和响应，以确保消息完好无损并从授权节点发送（RFC5440第10.3节）。
o Providing policy control by explicitly defining which PCCs, via IP access lists, are allowed to send P2MP path requests to the PCE (Section 10.6 of [RFC5440]).
o 通过明确定义允许哪些PCC通过IP访问列表向PCE发送P2MP路径请求来提供策略控制（RFC5440第10.6节）。
PCEP operates over TCP, so it is also important to secure the PCE and PCC against TCP denial-of-service attacks. Section 10.7.1 of [RFC5440] outlines a number of mechanisms for minimizing the risk of TCP-based denial-of-service attacks against PCEs and PCCs.
PCEP通过TCP运行，因此保护PCE和PCC免受TCP拒绝服务攻击也很重要。[RFC5440]的第10.7.1节概述了将针对PCE和PCC的基于TCP的拒绝服务攻击风险降至最低的一些机制。
PCEP implementations SHOULD also consider the additional security provided by the TCP Authentication Option (TCP-AO) [RFC5925].
PCEP实现还应该考虑TCP认证选项（TCP-AO）[RCF5925]提供的附加安全性。
Finally, any multi-domain operation necessarily involves the exchange of information across domain boundaries. This may represent a significant security and confidentiality risk, especially when the domains are controlled by different commercial entities. PCEP allows
最后，任何多域操作都必然涉及跨域边界的信息交换。这可能会带来重大的安全和保密风险，尤其是当域由不同的商业实体控制时。PCEP允许
individual PCEs to maintain confidentiality of their domain path information by using Path-Keys [RFC5520] and would allow for securing of domain path information when performing core-tree-based path computations.
单个PCE通过使用路径密钥[RFC5520]来维护其域路径信息的机密性，并允许在执行基于核心树的路径计算时保护域路径信息。
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry and the "RP Object Flag Field" sub-registry.
IANA维护“路径计算元素协议（PCEP）编号”注册表和“RP对象标志字段”子注册表。
IANA has allocated a new bit from this registry as follows:
IANA已从此注册表中分配了一个新位，如下所示：
Bit Description Reference 17 Core-tree computation (C-bit) [RFC7334]
位描述参考17核心树计算（C位）[RFC7334]
The authors would like to thank Adrian Farrel, Dan Tappan, Olufemi Komolafe, Oscar Gonzalez de Dios, and Julien Meuric for their valuable comments on this document.
作者感谢Adrian Farrel、Dan Tappan、Olufemi Komolafe、Oscar Gonzalez de Dios和Julien Meuri对本文件的宝贵评论。
[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月。
[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月。
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010.
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010.translate error, please retry
[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月。
[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月。
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
[RFC4872]Lang，J.，Ed.，Rekhter，Y.，Ed.，和D.Papadimitriou，Ed.，“支持端到端通用多协议标签交换（GMPLS）恢复的RSVP-TE扩展”，RFC 4872，2007年5月。
[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月。
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008.
[RFC5152]Vasseur，JP.，Ed.，Ayyangar，A.，Ed.，和R.Zhang，“用于建立域间流量工程（TE）标签交换路径（LSP）的每域路径计算方法”，RFC 5152，2008年2月。
[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008.
[RFC5376]Bitar，N.，Zhang，R.，和K.Kumaki，“路径计算元素通信协议（PCECP）的内部AS要求”，RFC 5376，2008年11月。
[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月。
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
[RFC5520]Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，2009年4月。
[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月。
[RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE", RFC 5862, June 2010.
[RFC5862]Yasukawa，S.和A.Farrel，“点对多点MPLS-TE的路径计算客户端（PCC）-路径计算元件（PCE）要求”，RFC 5862，2010年6月。
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, June 2010.
[RFC5886]Vasseur，JP.，Ed.，Le Roux，JL.，和Y.Ikejiri，“基于路径计算元素（PCE）架构的一套监控工具”，RFC 58862010年6月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RFC6805] King, D., Ed., and A. Farrel, Ed., "The Application of the Path Computation Element Architecture to the Determination of a Sequence of Domains in MPLS and GMPLS", RFC 6805, November 2012.
[RFC6805]King，D.，Ed.，和A.Farrel，Ed.，“路径计算元素架构在MPLS和GMPLS域序列确定中的应用”，RFC 6805，2012年11月。
[PCEP-MIB] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Protocol (PCEP) Management Information Base", Work in Progress, July 2014.
[PCEP-MIB]Koushik，A.，Stephan，E.，Zhao，Q.，King，D.，和J.Hardwick，“路径计算元素协议（PCEP）管理信息库”，正在进行的工作，2014年7月。
[PCEP-P2MP-MIB] Zhao, Q., Dhody, D., Palle, U., and D. King, "Management Information Base for the PCE Communications Protocol (PCEP) When Requesting Point-to-Multipoint Services", Work in Progress, August 2012.
[PCEP-P2MP-MIB]Zhao，Q.，Dhody，D.，Palle，U.，和D.King，“请求点对多点服务时PCE通信协议（PCEP）的管理信息库”，正在进行的工作，2012年8月。
[DOMAIN-SEQ] Dhody, D., Palle, U., and R. Casellas, "Standard Representation Of Domain-Sequence", Work in Progress, July 2014.
[DOMAIN-SEQ]Dhody，D.，Palle，U.，和R.Casellas，“域序列的标准表示”，正在进行的工作，2014年7月。
Siva Sivabalan Cisco Systems 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Siva Sivabalan思科系统2000创新大道加拿大安大略省卡纳塔K2K 3E8
EMail: msiva@cisco.com
EMail: msiva@cisco.com
Tarek Saad Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Tarek Saad Cisco Systems，Inc.加拿大安大略省卡纳塔创新大道2000号K2K 3E8
EMail: tsaad@cisco.com
EMail: tsaad@cisco.com
Authors' Addresses
作者地址
Quintin Zhao Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US
昆廷赵华为技术125美国马萨诸塞州阿克顿市纳戈科技园01719
EMail: quintin.zhao@huawei.com
EMail: quintin.zhao@huawei.com
Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka 560008 India
印度卡纳塔克邦班加罗尔杜鲁夫杜迪华为技术有限公司，邮编560008
EMail: dhruv.dhody@huawei.com
EMail: dhruv.dhody@huawei.com
Daniel King Old Dog Consulting UK
丹尼尔·金老狗咨询英国
EMail: daniel@olddog.co.uk
EMail: daniel@olddog.co.uk
Zafar Ali Cisco Systems 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
加拿大安大略省卡纳塔市Zafar Ali Cisco Systems 2000创新大道K2K 3E8
EMail: zali@cisco.com
EMail: zali@cisco.com
Ramon Casellas CTTC Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain
拉蒙·卡塞拉斯CTTC Av。Carl Friedrich Gauss n7 Castelldefels，巴塞罗那08860西班牙
EMail: ramon.casellas@cttc.es
EMail: ramon.casellas@cttc.es