Internet Engineering Task Force (IETF) I. Nishioka
Request for Comments: 6007 NEC Corp.
Category: Informational D. King
ISSN: 2070-1721 Old Dog Consulting
September 2010
Internet Engineering Task Force (IETF) I. Nishioka
Request for Comments: 6007 NEC Corp.
Category: Informational D. King
ISSN: 2070-1721 Old Dog Consulting
September 2010
Use of the Synchronization VECtor (SVEC) List for Synchronized Dependent Path Computations
使用同步向量（SVEC）列表进行同步相关路径计算
Abstract
摘要
A Path Computation Element (PCE) may be required to perform dependent path computations. Dependent path computations are requests that need to be synchronized in order to meet specific objectives. An example of a dependent request would be a PCE computing a set of services that are required to be diverse (disjointed) from each other. When a PCE computes sets of dependent path computation requests concurrently, use of the Synchronization VECtor (SVEC) list is required for association among the sets of dependent path computation requests. The SVEC object is optional and carried within the Path Computation Element Communication Protocol (PCEP) PCRequest (PCReq) message.
可能需要路径计算元件（PCE）来执行从属路径计算。依赖路径计算是为了满足特定目标而需要同步的请求。依赖请求的一个例子是PCE计算一组相互不同（脱节）的服务。当PCE同时计算依赖路径计算请求集时，需要使用同步向量（SVEC）列表来关联依赖路径计算请求集。SVEC对象是可选的，在路径计算元素通信协议（PCEP）PCReq（PCReq）消息中携带。
This document does not specify the PCEP SVEC object or procedure. This informational document clarifies the use of the SVEC list for synchronized path computations when computing dependent requests. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments.
本文件未规定PCEP SVEC对象或程序。本信息性文档说明了在计算依赖请求时，如何使用SVEC列表进行同步路径计算。本文档还描述了单域和多域环境中SVEC列表的多种使用场景。
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/rfc6007.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6007.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
1.1. SVEC Object ................................................4
1.2. Application of SVEC Lists ..................................5
2. Terminology .....................................................6
3. SVEC Association Scenarios ......................................7
3.1. Synchronized Computation for Diverse Path Requests .........7
3.2. Synchronized Computation for Point-to-Multipoint
Path Requests ..............................................8
4. SVEC Association ................................................9
4.1. SVEC List ..................................................9
4.2. Associated SVECs ...........................................9
4.3. Non-Associated SVECs ......................................10
5. Processing of SVEC List ........................................10
5.1. Single-PCE, Single-Domain Environments ....................10
5.2. Multi-PCE, Single-Domain Environments .....................11
5.3. Multi-PCE, Multi-Domain Environments ......................11
6. End-to-End Diverse Path Computation ............................13
6.1. Disjoint VSPT .............................................13
6.2. Disjoint VSPT Encoding ....................................14
6.3. Path Computation Procedure ................................15
7. Manageability Considerations ...................................15
7.1. Control of Function and Policy ............................15
7.2. Information and Data Models (MIB Modules) .................15
7.3. Liveness Detection and Monitoring .........................15
7.4. Verifying Correct Operation ...............................15
7.5. Requirements on Other Protocols and Functional
Components ................................................16
7.6. Impact on Network Operation ...............................16
8. Security Considerations ........................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
10. Acknowledgements ..............................................18
1. Introduction ....................................................3
1.1. SVEC Object ................................................4
1.2. Application of SVEC Lists ..................................5
2. Terminology .....................................................6
3. SVEC Association Scenarios ......................................7
3.1. Synchronized Computation for Diverse Path Requests .........7
3.2. Synchronized Computation for Point-to-Multipoint
Path Requests ..............................................8
4. SVEC Association ................................................9
4.1. SVEC List ..................................................9
4.2. Associated SVECs ...........................................9
4.3. Non-Associated SVECs ......................................10
5. Processing of SVEC List ........................................10
5.1. Single-PCE, Single-Domain Environments ....................10
5.2. Multi-PCE, Single-Domain Environments .....................11
5.3. Multi-PCE, Multi-Domain Environments ......................11
6. End-to-End Diverse Path Computation ............................13
6.1. Disjoint VSPT .............................................13
6.2. Disjoint VSPT Encoding ....................................14
6.3. Path Computation Procedure ................................15
7. Manageability Considerations ...................................15
7.1. Control of Function and Policy ............................15
7.2. Information and Data Models (MIB Modules) .................15
7.3. Liveness Detection and Monitoring .........................15
7.4. Verifying Correct Operation ...............................15
7.5. Requirements on Other Protocols and Functional
Components ................................................16
7.6. Impact on Network Operation ...............................16
8. Security Considerations ........................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................17
10. Acknowledgements ..............................................18
[RFC5440] describes the specifications for the Path Computation Element Communication Protocol (PCEP). PCEP specifies the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs based on the PCE architecture [RFC4655]. PCEP interactions include path computation requests and path computation replies.
[RFC5440]描述了路径计算元素通信协议（PCEP）的规范。PCEP指定路径计算客户端（PCC）和路径计算元素（PCE）之间的通信，或基于PCE体系结构的两个PCE之间的通信[RFC4655]。PCEP交互包括路径计算请求和路径计算回复。
The PCE may be required to compute independent and dependent path requests. Path computation requests are said to be independent if they are not related to each other and therefore not required to be
可能需要PCE来计算独立和依赖路径请求。如果路径计算请求彼此不相关，因此不需要相互关联，则称其为独立的
synchronized. Conversely, a set of dependent path computation requests is such that their computations cannot be performed independently of each other, and the requests must be synchronized. The Synchronization VECtor (SVEC) with a list of the path computation request identifiers carried within the request message allows the PCC or PCE to specify a list of multiple path computation requests that must be synchronized. Section 1.1 ("SVEC Object") describes the SVEC object. Section 1.2 ("Application of SVEC Lists") describes the application of SVEC lists in certain scenarios.
同步的。相反，一组依赖路径计算请求使得它们的计算不能彼此独立地执行，并且请求必须同步。具有在请求消息内携带的路径计算请求标识符的列表的同步向量（SVEC）允许PCC或PCE指定必须同步的多路径计算请求的列表。第1.1节（“SVEC对象”）描述了SVEC对象。第1.2节（“SVEC列表的应用”）描述了SVEC列表在某些场景中的应用。
This informational document clarifies the handling of dependent and synchronized path computation requests, using the SVEC list, based on the PCE architecture [RFC4655] and PCEP [RFC5440]. The document also describes a number of usage scenarios for SVEC lists within single-domain and multi-domain environments. This document is not intended to specify the procedure when using SVEC lists for dependent and synchronized path computation requests.
本信息性文档阐明了基于PCE体系结构[RFC4655]和PCEP[RFC5440]使用SVEC列表处理依赖和同步路径计算请求的方法。本文档还描述了单域和多域环境中SVEC列表的多种使用场景。本文档不打算指定将SVEC列表用于从属和同步路径计算请求时的过程。
When a PCC or PCE sends path computation requests to a PCE, a PCEP Path Computation Request (PCReq) message may carry multiple requests, each of which has a unique path computation request identifier. The SVEC with a list of the path computation request identifiers carried within the request message allows the PCC or PCE to specify a list of multiple path computation requests that must be synchronized, and also allows the specification of any dependency relationships between the paths. The path computation requests listed in the SVEC must be handled in a specific relation to each other (i.e., synchronized).
当PCC或PCE向PCE发送路径计算请求时，PCEP路径计算请求（PCReq）消息可携带多个请求，每个请求具有唯一的路径计算请求标识符。具有在请求消息中携带的路径计算请求标识符列表的SVEC允许PCC或PCE指定必须同步的多个路径计算请求的列表，并且还允许指定路径之间的任何依赖关系。SVEC中列出的路径计算请求必须按照彼此之间的特定关系进行处理（即同步）。
[RFC5440] defines two synchronous path computation modes for dependent or independent path computation requests specified by the dependency flags (i.e., Node, Link, or Shared Risk Link Group (SRLG) diverse flags) in the SVEC:
[RFC5440]为SVEC中的依赖标志（即节点、链路或共享风险链路组（SRLG）不同标志）指定的依赖或独立路径计算请求定义了两种同步路径计算模式：
o A set of independent and synchronized path computation requests.
o 一组独立且同步的路径计算请求。
o A set of dependent and synchronized path computation requests.
o 一组相关和同步的路径计算请求。
See [RFC5440] for more details on dependent, independent, and synchronous path computation.
有关依赖、独立和同步路径计算的更多详细信息，请参阅[RFC5440]。
These computation modes are exclusive to each other in a single SVEC. If one of the dependency flags in a SVEC is set, it indicates that a set of synchronous path computation requests has a dependency and does not allow any other path computation requests. In order to be synchronized with other path computation requests with a dependency, it is necessary to associate them.
这些计算模式在单个SVEC中相互排斥。如果设置了SVEC中的一个依赖项标志，则表示一组同步路径计算请求具有依赖项，并且不允许任何其他路径计算请求。为了与具有依赖关系的其他路径计算请求同步，必须将它们关联起来。
The aim of the SVEC object carried within a PCReq message is to request the synchronization of M path computation requests. Each path computation request is uniquely identified by the Request-ID-number carried within the respective Request Parameters (RP) object. The SVEC object also contains a set of flags that specify the synchronization type. The SVEC object is defined in Section 7.13 ("SVEC Object") of [RFC5440].
PCReq消息中携带的SVEC对象的目的是请求M个路径计算请求的同步。每个路径计算请求由各自请求参数（RP）对象中携带的请求ID号唯一标识。SVEC对象还包含一组用于指定同步类型的标志。[RFC5440]第7.13节（“SVEC对象”）对SVEC对象进行了定义。
It is important for the PCE, when performing path computations, to synchronize any path computation requests with a dependency. For example, consider two protected end-to-end services:
PCE在执行路径计算时，将任何路径计算请求与依赖项同步非常重要。例如，考虑两个受保护的端到端服务：
o It would be beneficial for each back-up path to be disjointed so they do not share the same links and nodes as the working path.
o 将每个备份路径分离，这样它们就不会与工作路径共享相同的链接和节点，这将是有益的。
o Two diverse path computation requests would be needed to compute the working and disjointed protected paths.
o 需要两个不同的路径计算请求来计算工作路径和分离的受保护路径。
If the diverse path requests are computed sequentially, fulfillment of the initial diverse path computation without consideration of the second diverse path computation and disjoint constraint may result in the PCE either providing sub-optimal path disjoint results for the protected path or failing to meet the end-to-end disjoint requirement altogether.
如果按顺序计算不同的路径请求，在不考虑第二多样路径计算和不相交约束的情况下实现初始多样路径计算可能导致PCE要么为受保护路径提供次优路径不相交结果，要么无法完全满足端到端不相交要求。
Additionally, SVEC can be applied to end-to-end diverse path computations that traverse multiple domains. [RFC5441] describes two approaches, synchronous (i.e., simultaneous) and 2-step approaches, for end-to-end diverse path computation across a chain of domains. The path computation procedure is specified for the 2-step approaches in [RFC5521], but no guidelines are provided for the synchronous approach described in this document.
此外，SVEC可以应用于跨多个域的端到端不同路径计算。[RFC5441]描述了两种方法，同步（即同步）和两步方法，用于跨域链的端到端不同路径计算。[RFC5521]中规定了两步进近的路径计算程序，但没有为本文件中描述的同步进近提供指南。
The following scenarios are specifically described within this document:
本文档中具体描述了以下场景：
o Single-domain, single-PCE, dependent and synchronized path computation request.
o 单域、单PCE、相关和同步路径计算请求。
o Single-domain, multi-PCE, dependent and synchronized path request.
o 单域、多PCE、依赖和同步路径请求。
o Multi-domain, dependent and synchronized path computation request, including end-to-end diverse path computation.
o 多域、相关和同步的路径计算请求，包括端到端的不同路径计算。
The association among multiple SVECs for multiple sets of synchronized dependent path computations is also described in this document, as well as the disjoint Virtual Shortest Path Tree (VSPT) encoding rule for end-to-end diverse path computation across domains. Path computation algorithms for these path computation scenarios are out of the scope of this document.
本文还描述了多组同步相关路径计算的多个SVEC之间的关联，以及跨域端到端不同路径计算的不相交虚拟最短路径树（VSPT）编码规则。这些路径计算场景的路径计算算法不在本文档的范围内。
The clarifications and use cases in this document are applicable to the Global Concurrent Optimization (GCO) path computation mechanism specified in [RFC5557]. The GCO application provides the capability to optimize a set of services within the network, in order to maximize efficient use of network resources. A single objective function (OF) or a set of OFs can be applied to a GCO. To compute a set of such traffic-engineered paths for the GCO application, PCEP supports the synchronous and dependent path computation requests required in [RFC4657].
本文档中的说明和用例适用于[RFC5557]中规定的全局并发优化（GCO）路径计算机制。GCO应用程序能够优化网络内的一组服务，以最大限度地高效利用网络资源。单一目标函数（OF）或一组OF可应用于GCO。为计算GCO应用程序的一组此类流量工程路径，PCEP支持[RFC4657]中要求的同步和相关路径计算请求。
The SVEC association and the disjoint VSPT described in this document do not require any extension to PCEP messages and object formats, when computing a GCO for multiple or end-to-end diverse paths. In addition, the use of multiple SVECs is not restricted to only SRLG, node, and link diversity currently defined in the SVEC object [RFC5440], but is also available for other dependent path computation requests.
当计算多条或端到端不同路径的GCO时，本文档中描述的SVEC关联和不相交VSPT不需要对PCEP消息和对象格式进行任何扩展。此外，多个SVEC的使用不仅限于SVEC对象[RFC5440]中当前定义的SRLG、节点和链路分集，还可用于其他依赖路径计算请求。
The SVEC association and disjoint VSPT are available to both single-PCE path computation and multi-PCE path computation.
SVEC关联和不相交VSPT可用于单PCE路径计算和多PCE路径计算。
This document uses PCE terminology defined in [RFC4655], [RFC4875], and [RFC5440].
本文件使用[RFC4655]、[RFC4875]和[RFC5440]中定义的PCE术语。
Associated SVECs: A group of multiple SVECs (Synchronization VECtors), defined in this document, to indicate a set of synchronized or concurrent path computations.
关联SVEC：本文档中定义的一组多个SVEC（同步向量），用于指示一组同步或并发路径计算。
Disjoint VSPT: A set of VSPTs, defined in this document, to indicate a set of virtual diverse path trees.
不相交VSPT：本文档中定义的一组VSPT，用于指示一组虚拟多样路径树。
GCO (Global Concurrent Optimization): A concurrent path computation application, defined in [RFC5557], where a set of traffic engineered (TE) paths is computed concurrently in order to efficiently utilize network resources.
GCO（全局并发优化）：在[RFC5557]中定义的并发路径计算应用程序，其中并发计算一组流量工程（TE）路径，以便有效利用网络资源。
Synchronized: Describes a set of path computation requests that the PCE associates and that the PCE does not compute independently of each other.
Synchronized（同步）：描述PCE关联且PCE不相互独立计算的一组路径计算请求。
VSPT: Virtual Shortest Path Tree, defined in [RFC5441].
VSPT：虚拟最短路径树，在[RFC5441]中定义。
This section clarifies several path computation scenarios in which SVEC association can be applied. Also, any combination of scenarios described in this section could be applicable.
本节阐明了几个可应用SVEC关联的路径计算场景。此外，本节中描述的任何场景组合都可能适用。
A PCE may compute two or more point-to-point diverse paths concurrently, in order to increase the probability of meeting primary and secondary path diversity (or disjointness) objectives and network resource optimization objectives.
PCE可以同时计算两个或多个点对点多样性路径，以增加满足主要和次要路径多样性（或不相交性）目标和网络资源优化目标的概率。
Two scenarios can be considered for the SVEC association of point-to-point diverse paths.
对于点到点不同路径的SVEC关联，可以考虑两种情况。
o Two or more end-to-end diverse paths
o 两条或多条端到端的多样化路径
When concurrent path computation of two or more end-to-end diverse paths is requested, SVEC association is needed among diverse path requests. Note here that each diverse path request consists of primary, secondary, and tertiary (and beyond) path requests, in which all path requests are grouped with one SVEC association.
当请求两个或多个端到端不同路径的并发路径计算时，不同路径请求之间需要SVEC关联。请注意，每个不同的路径请求都由主、次和第三（及以上）路径请求组成，其中所有路径请求都使用一个SVEC关联进行分组。
Consider two end-to-end services that are to be kept separate by using diverse paths. The path computation requests would need to be associated so that diversity could be assured. Consider further that each of these services requires a backup path that can protect against any failure in the primary path. These backup paths must be computed using requests that are associated with the primary paths, giving rise to a set of four associated requests.
考虑两个端到端服务，它们将通过使用不同的路径来保持分离。需要关联路径计算请求，以便确保多样性。进一步考虑，这些服务中的每一个都需要一个可以防止主路径中的任何故障的备份路径。必须使用与主路径关联的请求来计算这些备份路径，从而产生一组四个关联请求。
o End-to-end primary path and its segmented secondary paths
o 端到端主路径及其分段次路径
When concurrent path computation for segment recovery paths, as shown in Figure 1, is requested, SVEC association is needed between a primary path and several segmented secondary paths.
当为段恢复路径请求并发路径计算时，如图1所示，一条主路径和多条分段次路径之间需要SVEC关联。
<------------ primary ----------->
<------------ primary ----------->
A------B------C---D------E------F
A------B------C---D------E------F
\ / \ /
\ / \ /
P---Q---R X---Y---Z
P---Q---R X---Y---Z
<--secondary1--> <--secondary2-->
<--secondary1--> <--secondary2-->
Figure 1. Segment Recovery Paths
图1。段恢复路径
In this scenario, we assume that the primary path may be pre-computed and used for specifying the segment for secondary paths. Otherwise, the segment for secondary path requests is specified in advance, by using Exclude Route Object (XRO) and/or Include Route Object (IRO) constraints in the primary request.
在这种情况下，我们假设主路径可以预先计算并用于指定辅助路径的段。否则，通过在主请求中使用排除路由对象（XRO）和/或包括路由对象（IRO）约束，预先指定辅助路径请求的段。
For point-to-multipoint path requests, SVEC association can be applied.
对于点对多点路径请求，可以应用SVEC关联。
o Two or more point-to-multipoint paths
o 两个或多个点对多点路径
If a point-to-multipoint path computation request is represented as a set of point-to-point paths [RFC6006], two or more point-to-multipoint path computation requests can be associated for concurrent path computation, in order to optimize network resources.
如果点对多点路径计算请求表示为一组点对点路径[RFC6006]，则可以将两个或多个点对多点路径计算请求关联以进行并发路径计算，以优化网络资源。
o Point-to-multipoint paths and their secondary paths
o 点对多点路径及其辅助路径
When concurrent path computation of a point-to-multipoint path and its point-to-point secondary paths [RFC4875], or a point-to-multipoint path and its point-to-multipoint secondary paths is requested, SVEC association is needed among these requests. In this scenario, we use the same assumption as the "end-to-end primary path and its segmented secondary paths" scenario in Section 3.1.
当请求点对多点路径及其点对点次路径[RFC4875]或点对多点路径及其点对多点次路径的并发路径计算时，这些请求之间需要SVEC关联。在此场景中，我们使用与第3.1节中“端到端主路径及其分段次路径”场景相同的假设。
This section describes the associations among SVECs in a SVEC list.
本节介绍SVEC列表中SVEC之间的关联。
PCEP provides the capability to carry one or more SVEC objects in a PCReq message, and this set of SVEC objects within the PCReq message is termed a SVEC list. Each SVEC object in the SVEC list contains a distinct group of path computation requests. When requesting association among such distinct groups, associated SVECs described in this document are used.
PCEP提供在PCReq消息中携带一个或多个SVEC对象的能力，PCReq消息中的这组SVEC对象称为SVEC列表。SVEC列表中的每个SVEC对象都包含一组不同的路径计算请求。当请求这些不同组之间的关联时，将使用本文档中描述的关联SVEC。
"Associated SVECs" means that there are relationships among multiple SVECs in a SVEC list. Note that there is no automatic association in [RFC5440] between the members of one SVEC and the members of another SVEC in the same SVEC list. The associated SVEC is introduced to associate these SVECs, especially for correlating among SVECs with dependency flags.
“关联SVEC”是指SVEC列表中的多个SVEC之间存在关系。请注意，[RFC5440]中一个SVEC的成员与同一SVEC列表中另一个SVEC的成员之间没有自动关联。引入关联的SVEC来关联这些SVEC，特别是用于SVEC与依赖标志之间的关联。
Request identifiers in the SVEC objects are used to indicate the association among SVEC objects. If the same request-IDs exist in SVEC objects, this indicates these SVEC objects are associated. When associating among SVEC objects, at least one request identifier must be shared between associated SVECs. The SVEC objects can be associated regardless of the dependency flags in each SVEC object, but it is recommended to use a single SVEC if the dependency flags are not set in all SVEC objects. Similarly, when associating among SVEC objects with dependency flags, it is recommended to construct them using a minimum set of associated SVECs, thus avoiding complex relational associations.
SVEC对象中的请求标识符用于指示SVEC对象之间的关联。如果SVEC对象中存在相同的请求ID，则表示这些SVEC对象已关联。在SVEC对象之间关联时，关联的SVEC之间必须至少共享一个请求标识符。无论每个SVEC对象中的依赖标志是什么，都可以关联SVEC对象，但是如果没有在所有SVEC对象中设置依赖标志，建议使用单个SVEC。类似地，当SVEC对象与依赖标志关联时，建议使用最小的关联SVEC集来构造它们，从而避免复杂的关系关联。
Below is an example of associated SVECs. In this example, the first SVEC is associated with the other SVECs, and all of the path computation requests contained in the associated SVECs (i.e., Request-IDs #1, #2, #3, #4, #X, #Y, and #Z) must be synchronized.
下面是相关SVEC的示例。在本例中，第一个SVEC与其他SVEC相关联，并且包含在关联SVEC中的所有路径计算请求（即，请求id#1、#2、#3、#4、#X、#Y和#Z）必须同步。
<SVEC-list>
<SVEC列表>
<SVEC> without dependency flags
不带依赖标志的<SVEC>
Request-ID #1, Request-ID #3, Request-ID #X
Request-ID #1, Request-ID #3, Request-ID #X
<SVEC> with one or more dependency flags
具有一个或多个依赖项标志的<SVEC>
Request-ID #1, Request-ID #2
请求ID#1，请求ID#2
<SVEC> with one or more dependency flags
具有一个或多个依赖项标志的<SVEC>
Request-ID #3, Request-ID #4
请求ID#3，请求ID#4
<SVEC> without dependency flag
不带依赖标志的<SVEC>
Request-ID #X, Request-ID #Y, Request-ID #Z
Request-ID #X, Request-ID #Y, Request-ID #Z
"Non-associated SVECs" means that there are no relationships among SVECs. If none of the SVEC objects in the SVEC list on a PCReq message contains a common request-ID, there is no association between the SVECs and so no association between the requests in one SVEC and the requests in another SVEC.
“非关联SVEC”表示SVEC之间没有关系。如果PCReq消息的SVEC列表中没有任何SVEC对象包含公共请求ID，则SVEC之间没有关联，因此一个SVEC中的请求与另一个SVEC中的请求之间没有关联。
Below is an example of non-associated SVECs that do not contain any common request-IDs.
下面是不包含任何公共请求ID的非关联SVEC的示例。
<SVEC-list>
<SVEC列表>
<SVEC> with one or more dependency flags
具有一个或多个依赖项标志的<SVEC>
Request-ID #1, Request-ID #2
请求ID#1，请求ID#2
<SVEC> with one or more dependency flags
具有一个或多个依赖项标志的<SVEC>
Request-ID #3, Request-ID #4
请求ID#3，请求ID#4
<SVEC> without dependency flags
不带依赖标志的<SVEC>
Request-ID #X, Request-ID #Y, Request-ID #Z
Request-ID #X, Request-ID #Y, Request-ID #Z
In this environment, there is a single PCE within the domain.
在此环境中，域中只有一个PCE。
When a PCE receives PCReq messages with more than one SVEC object in the SVEC list, PCEP has to first check the request-IDs in all SVEC objects in order to identify any associations among them.
当PCE接收到包含SVEC列表中多个SVEC对象的PCReq消息时，PCEP必须首先检查所有SVEC对象中的请求ID，以识别它们之间的任何关联。
If there are no matching request-IDs in the different SVEC objects, these SVEC objects are not associated, and then each set of path computation requests in the non-associated SVEC objects has to be computed separately.
如果不同的SVEC对象中没有匹配的请求ID，则这些SVEC对象不关联，然后必须分别计算非关联SVEC对象中的每组路径计算请求。
If there are matching request-IDs in the different SVEC objects, these SVEC objects are associated, and then all path computation requests in the associated SVEC objects are treated in a synchronous manner for GCO application.
如果不同的SVEC对象中存在匹配的请求ID，则这些SVEC对象将关联，然后关联的SVEC对象中的所有路径计算请求将以同步方式处理，以供GCO应用程序使用。
If a PCE that is unable to handle the associated SVEC finds the common request-IDs in multiple SVEC objects, the PCE should cancel the path computation request and respond to the PCC with the PCErr message Error-Type="Capability not supported".
如果无法处理相关SVEC的PCE在多个SVEC对象中找到公共请求ID，则PCE应取消路径计算请求，并使用PCErr消息Error Type=“Capability not supported”（能力不受支持）响应PCC。
In the case that M path computation requests are sent across multiple PCReq messages, the PCE may start a SyncTimer as recommended in Section 7.13.3 ("Handling of the SVEC Object") of [RFC5440]. In this case, the associated SVECs should also be handled as described in [RFC5440], i.e., after receiving the entire set of M path computation requests associated by SVECs, the computation should start at one. If the SyncTimer has expired or the subsequent PCReq messages are malformed, the PCE should cancel the path computation request and respond to the PCC with the relevant PCErr message.
如果M路径计算请求跨多个PCReq消息发送，则PCE可按照[RFC5440]第7.13.3节（“SVEC对象的处理”）中的建议启动同步定时器。在这种情况下，还应按照[RFC5440]中所述处理关联的SVEC，即，在接收到SVEC关联的整个M路径计算请求集后，计算应在1点开始。如果SyncTimer已过期或后续PCReq消息格式不正确，则PCE应取消路径计算请求，并使用相关PCErr消息响应PCC。
There are multiple PCEs in a domain, to which PCCs can communicate directly, and PCCs can choose an appropriate PCE for load-balanced path computation requests. In this environment, it is possible that dependent path computation requests are sent to different PCEs.
一个域中有多个PCE，PCC可以直接与之通信，PCC可以为负载平衡路径计算请求选择合适的PCE。在这种环境中，依赖路径计算请求可能被发送到不同的pce。
However, if a PCC sends path computation requests to a PCE, and then sends a further path computation request to a different PCE using the SVEC list to show that the further request is dependent on the first requests, there is no method for the PCE to correlate the dependent requests sent to different PCEs. No SVEC object correlation function between the PCEs is specified in [RFC5440]. No mechanism exists to resolve this problem, and the issue is open for future study. Therefore, a PCC must not send dependent path computation requests associated by SVECs to different PCEs.
然而，如果PCC向PCE发送路径计算请求，然后使用SVEC列表向不同的PCE发送进一步的路径计算请求以表明进一步的请求依赖于第一个请求，则PCE没有方法关联发送到不同PCE的依赖请求。[RFC5440]中未指定PCE之间的SVEC对象相关函数。不存在解决这一问题的机制，这一问题有待进一步研究。因此，PCC不得将SVEC关联的从属路径计算请求发送到不同的PCE。
In this environment, there are multiple domains in which PCEs are located in each domain, and end-to-end dependent paths (i.e., diverse paths) are computed using multiple PCEs. Note that we assume a chain of PCEs is predetermined and the Backward-Recursive PCE-Based Computation (BRPC) procedure [RFC5441] is in use.
在这种环境中，存在多个域，其中pce位于每个域中，并且使用多个pce计算端到端依赖路径（即不同路径）。注意，我们假设PCE链是预先确定的，并且使用了基于PCE的反向递归计算（BRPC）过程[RFC5441]。
The SVECs can be applied to end-to-end diverse path computations that traverse multiple domains. [RFC5441] describes two approaches, synchronous (i.e., simultaneous) and 2-step approaches, for
SVEC可以应用于跨多个域的端到端不同路径计算。[RFC5441]描述了两种方法，同步（即同步）和两步方法，用于
end-to-end diverse path computation across a chain of domains. In the 2-step approaches described in [RFC5521], it is not necessary to use the associated SVECs if any of the dependency flags in a SVEC object are not set. On the other hand, the simultaneous approach may require the associated SVEC because at least one of the dependency flags is required to be set in a SVEC object. Thus, a use case of the simultaneous approach is described in this environment.
跨域链的端到端多样化路径计算。在[RFC5521]中描述的两步方法中，如果未设置SVEC对象中的任何依赖标志，则无需使用关联的SVEC。另一方面，同时方法可能需要相关联的SVEC，因为SVEC对象中需要设置至少一个依赖标志。因此，在此环境中描述了同时方法的用例。
When a chain of PCEs located in separate domains is used for simultaneous path computations, additional path computation processing is required, as described in Section 6 of this document.
当位于不同域中的PCE链用于同时路径计算时，需要额外的路径计算处理，如本文件第6节所述。
If the PCReq message contains multiple associated SVEC objects and these SVEC objects contain path computation requests that will be sent to the next PCE along the path computation chain, the following procedures are applied.
如果PCReq消息包含多个关联的SVEC对象，并且这些SVEC对象包含将沿路径计算链发送到下一个PCE的路径计算请求，则应用以下过程。
When a chain of PCEs is a unique sequence for all of the path computation requests in a PCReq message, it is not necessary to reconstruct associations among SVEC objects. Thus, the PCReq message is passed to the tail-end PCE. When a PCReq message contains more than one SVEC object with the dependency flag set, the contained SVECs may then be associated. PCEs receiving the associated SVECs must maintain their association and must consider their relationship when performing path computations after receiving a corresponding PCReply (PCRep) message.
当PCE链是PCReq消息中所有路径计算请求的唯一序列时，无需重建SVEC对象之间的关联。因此，PCReq消息被传递到后端PCE。当PCReq消息包含多个设置了依赖标志的SVEC对象时，所包含的SVEC可能会关联起来。接收相关联的SECCS的PCE必须保持它们的关联，并且必须在接收到相应的PCCREP（PCRIP）消息之后执行路径计算时考虑它们的关系。
When a chain of PCEs is different, it is required that intermediate PCEs receiving such PCReq messages may reconstruct associations among SVEC objects, and then send PCReq messages to corresponding PCEs located in neighboring domains. If the associated SVECs are reconstructed at the intermediate PCE, the PCE must not start its path computation until all PCRep messages have been received from all neighbor PCEs. However, a complex PCE implementation is required for SVEC reconstruction, and waiting mechanisms must be implemented. Therefore, it is not recommended to associate path computation requests with different PCE chains. This is an open issue and is currently being discussed in [H-PCE], which proposes a hierarchical PCE architecture.
当pce链不同时，要求接收此类PCReq消息的中间pce可以重构SVEC对象之间的关联，然后将PCReq消息发送到位于相邻域中的对应pce。如果相关联的svec在中间PCE处重建，则在从所有相邻PCE接收到所有PCRep消息之前，PCE不得开始其路径计算。然而，SVEC重建需要复杂的PCE实施，必须实施等待机制。因此，不建议将路径计算请求与不同的PCE链相关联。这是一个悬而未决的问题，目前正在[H-PCE]中讨论，该文提出了一种分层PCE体系结构。
In this section, the synchronous approach is provided to compute primary and secondary paths simultaneously.
在本节中，将提供同步方法来同时计算主路径和次路径。
The BRPC procedure constructs a VSPT to inform the enquiring PCE of potential paths to the destination node.
BRPC过程构造一个VSPT，以通知查询PCE到目标节点的潜在路径。
In the end-to-end diverse path computation, diversity (or disjointness) information among the potential paths must be preserved in the VSPT to ensure an end-to-end disjoint path. In order to preserve diversity (or disjointness) information, disjoint VSPTs are sent in the PCEP PCRep message. The PCReq containing a SVEC object with the appropriate diverse flag set would signal that the PCE should compute a disjoint VSPT.
在端到端多样性路径计算中，VSPT必须保留潜在路径之间的多样性（或不相交性）信息，以确保端到端不相交的路径。为了保留多样性（或不相交性）信息，在PCEP PCRep消息中发送不相交的VSPT。PCReq包含一个SVEC对象，该SVEC对象具有适当的差异标志集，该PCE将发出信号，表示该PCE应计算不相交的VSPT。
A definition of the disjoint VSPT is a collection of VSPTs, in which each VSPT contains a potential set of primary and secondary paths.
不相交VSPT的定义是VSPT的集合，其中每个VSPT包含一组潜在的主路径和次路径。
Figure 2 shows an example network. Here, transit nodes in domains are not depicted, and PCE1 and PCE2 may be located in border nodes. In this network, there are three VSPTs for the potential set of diverse paths, shown in Figure 3, when the primary path and secondary path are requested from S1 to D1. These VSPTs consist of a disjoint VSPT, which is indicated in a PCRep to PCE1. When receiving the disjoint VSPT, PCE1 recognizes the disjoint request and disjoint VSPT information. PCE1 will then continue to process the request and compute the diverse path using the BRPC procedure [RFC5441]. Encoding for the disjoint VSPT is described in Section 6.2.
图2显示了一个示例网络。这里，未描述域中的传输节点，并且PCE1和PCE2可位于边界节点中。在该网络中，当从S1到D1请求主路径和次路径时，有三个VSPT用于不同路径的潜在集合，如图3所示。这些VSPT由不相交的VSPT组成，在PCRep到PCE1中指示。当接收到不相交的VSPT时，PCE1识别不相交的请求和不相交的VSPT信息。然后，PCE1将继续处理该请求，并使用BRPC过程[RFC5441]计算不同路径。不相交VSPT的编码如第6.2节所述。
Domain1 Domain2
域1域2
+----------+ +----------+
+----------+ +----------+
| PCE1 | | PCE2 | S1: Source node
| PCE1 | | PCE2 | S1: Source node
| BN1---BN4 | D1: Destination node
| BN1---BN4 | D1: Destination node
| S1 BN2---BN5 D1 | BN1-BN6: Border nodes
| S1 BN2---BN5 D1 | BN1-BN6: Border nodes
| BN3---BN6 |
| BN3---BN6 |
+----------+ +----------+
+----------+ +----------+
Figure 2. Example Network for Diverse Path Computation
图2。用于不同路径计算的示例网络
VSPT1: VSPT2: VSPT3:
VSPT1:VSPT2:VSPT3:
D1 D1 D1
首被告
/ \ / \ / \
/ \ / \ / \
BN4 BN5 BN4 BN6 BN5 BN6
BN4 BN5 BN4 BN6 BN5 BN6
Figure 3. Disjoint VSPTs from PCE2 to PCE1
图3。从PCE2到PCE1的不相交VSPT
Encoding for the disjoint VSPT follows the definition of PCEP message encoding in [RFC5440].
不相交VSPT的编码遵循[RFC5440]中PCEP消息编码的定义。
The PCEP PCRep message returns a disjoint VSPT as <path list> for each RP object (Request Parameter object). The order of <path> in <path list> among <responses> implies a set of primary Explicit Route Objects (EROs) and secondary EROs.
PCEP PCRep消息为每个RP对象（请求参数对象）返回一个不相交的VSPT作为<path list>。<responses>中<path list>中<path>的顺序表示一组主要显式路由对象（ero）和次要ero。
A PCE sending a PCRep with a disjoint VSPT can reply with a partial disjoint VSPT based on its network operation policy, but the order of <path> in <path list> must be aligned correctly.
发送带有不相交VSPT的PCRep的PCE可以根据其网络操作策略使用部分不相交VSPT进行回复，但必须正确对齐<path list>中<path>的顺序。
If confidentiality is required between domains, the path key mechanism defined in [RFC5520] is used for a disjoint VSPT.
如果域之间需要保密，则[RFC5520]中定义的路径密钥机制用于不相交的VSPT。
Below are the details of the disjoint VSPT encoding (in Figure 3), when a primary path and a secondary path are requested from S1 to D1.
下面是从S1到D1请求主路径和次路径时不相交VSPT编码的详细信息（图3）。
o Request ID #1 (Primary)
o 请求ID#1（主）
- ERO1 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO1 BN4（TE路由ID）-…-D1（TE路由器ID）[用于VSPT1]
- ERO2 BN4(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO2 BN4（TE路由ID）-…-D1（TE路由器ID）[用于VSPT2]
- ERO3 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT3]
- ERO3 BN5（TE路由ID）-…-D1（TE路由器ID）[用于VSPT3]
o Request ID #2 (Secondary)
o 请求ID#2（辅助）
- ERO4 BN5(TE route ID)- ...-D1(TE-Router ID) [for VSPT1]
- ERO4 BN5（TE路由ID）-…-D1（TE路由器ID）[用于VSPT1]
- ERO5 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT2]
- ERO5 BN6（TE路由ID）-…-D1（TE路由器ID）[用于VSPT2]
- ERO6 BN6(TE route ID)- ...-D1(TE-Router ID) [for VSPT3]
- ERO6 BN6（TE路由ID）-…-D1（TE路由器ID）[用于VSPT3]
For end-to-end diverse path computation, the same mode of operation as that of the BRPC procedure can be applied (i.e., Step 1 to Step n in Section 4.2 of [RFC5441]). A question that must be considered is how to recognize disjoint VSPTs.
对于端到端不同路径计算，可采用与BRPC程序相同的操作模式（即[RFC5441]第4.2节中的步骤1至步骤n）。必须考虑的一个问题是如何识别不相交的VSPT。
The recognition of disjoint VSPTs is achieved by the PCE sending a PCReq to its neighbor PCE, which maintains the path computation request (PCReq) information. If the PCReq has one or more SVEC object(s) with the appropriate dependency flags, the received PCRep will contain the disjoint VSPT. If not, the received VSPT is a normal VSPT based on the shortest path computation.
不相交VSPT的识别是通过PCE向其邻居PCE发送PCReq来实现的，后者维护路径计算请求（PCReq）信息。如果PCReq具有一个或多个具有适当依赖标志的SVEC对象，则接收到的PCRep将包含不相交的VSPT。如果不是，则接收到的VSPT是基于最短路径计算的正常VSPT。
Note that the PCE will apply a suitable algorithm for computing requests with disjoint VSPTs. The selection and application of the appropriate algorithm is out of scope in this document.
请注意，PCE将应用适当的算法来计算具有不相交VSPT的请求。适当算法的选择和应用超出了本文件的范围。
This section describes manageability considerations specified in [PCE-MNG-REQS].
本节描述了[PCE-MNG-REQS]中规定的可管理性注意事项。
In addition to [RFC5440], PCEP implementations should allow the PCC to be responsible for mapping the requested paths to computation requests. The PCC should construct the SVECs to identify and associate SVEC relationships.
除了[RFC5440]，PCEP实现还应允许PCC负责将请求的路径映射到计算请求。PCC应构建SVEC，以识别和关联SVEC关系。
There are currently no additional parameters for MIB modules. There would be value in a MIB module that details the SVEC association. This work is currently out of scope of this document.
目前没有MIB模块的其他参数。MIB模块中会有详细说明SVEC关联的值。这项工作目前不在本文件的范围内。
The associated SVEC in this document allows PCEs to compute optimal sets of diverse paths. This type of path computation may require more time to obtain its results. Therefore, it is recommended for PCEP to support the PCE monitoring mechanism specified in [RFC5886].
本文中相关的SVEC允许PCE计算不同路径的最佳集合。这种类型的路径计算可能需要更多的时间才能获得结果。因此，建议PCEP支持[RFC5886]中规定的PCE监测机制。
[RFC5440] provides a sufficient description for this document. There are no additional considerations.
[RFC5440]为本文件提供了充分的说明。没有其他考虑。
This document does not require any other protocol and functional components.
本文件不需要任何其他协议和功能组件。
[RFC5440] provides descriptions for the mechanisms discussed in this document. There is value in considering that large associated SVECs will require greater PCE resources, compared to non-associated SVECs. Additionally, the sending of large associated SVECs within multiple PCReq messages will require more network resources. Solving these specific issues is out of scope of this document.
[RFC5440]提供了本文件中讨论的机制的说明。考虑到与非关联SVEC相比，大型关联SVEC需要更多的PCE资源是有价值的。此外，在多个PCReq消息中发送大型关联SVEC将需要更多的网络资源。解决这些具体问题超出了本文件的范围。
This document describes the usage of the SVEC list, and does not have any extensions for PCEP. The security of the procedures described in this document depends on PCEP [RFC5440]. However, a PCE that supports associated SVECs may be open to Denial-of-Service (DoS) attacks from a rogue PCC. A PCE may be made to queue large numbers of requests waiting for other requests that will never arrive. Additionally, a PCE might be made to compute exceedingly complex associated SVEC computations. These DoS attacks may be mitigated with the use of practical SVEC list limits, as well as:
本文档描述了SVEC列表的用法，没有PCEP的任何扩展。本文件中所述程序的安全性取决于PCEP[RFC5440]。但是，支持相关SVEC的PCE可能会受到来自恶意PCC的拒绝服务（DoS）攻击。PCE可能会让大量请求排队等待永远不会到达的其他请求。此外，PCE可用于计算极其复杂的相关SVEC计算。这些DoS攻击可以通过使用实际的SVEC列表限制以及：
o Applying provisioning to PCEs, e.g., for a given number of simultaneous services (recommended).
o 将资源调配应用于PCE，例如，针对给定数量的同时服务（推荐）。
o Using a priority-based multi-queuing mechanism in which path computation requests with a smaller SVEC list are prioritized for path computation processing.
o 使用基于优先级的多队列机制，其中具有较小SVEC列表的路径计算请求优先用于路径计算处理。
o Specifying which PCCs may request large SVEC associations through PCE access policy control.
o 指定哪些PCC可以通过PCE访问策略控制请求大型SVEC关联。
[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月。
[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月。
[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月。
[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月。
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009.
[RFC5521]Oki，E.，Takeda，T.，和A.Farrel，“路由排除的路径计算元素通信协议（PCEP）扩展”，RFC 55212009年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月。
[H-PCE] 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 & GMPLS", Work in Progress, December 2009.
[H-PCE]King，D.，Ed.，和A.Farrel，Ed.，“路径计算元素架构在MPLS和GMPLS域序列确定中的应用”，正在进行的工作，2009年12月。
[PCE-MNG-REQS] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, July 2009.
[PCE-MNG-REQS]Farrel，A.，“将可管理性部分纳入PCE工作组草案”，正在进行的工作，2009年7月。
[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月。
[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.，和J.Meuria，“点对多点流量工程标签交换路径的路径计算元素通信协议（PCEP）扩展”，RFC 60062010年9月。
The authors would like to thank Adrian Farrel, Julien Meuric, and Filippo Cugini for their valuable comments.
作者要感谢Adrian Farrel、Julien Meuria和Filippo Cugini的宝贵评论。
Authors' Addresses
作者地址
Itaru Nishioka NEC Corp. 1753 Shimonumabe, Kawasaki, 211-8666, Japan
Itaru Nishioka NEC Corp.1753 Shimonumabe，川崎，211-8666，日本
Phone: +81 44 396 3287
EMail: i-nishioka@cb.jp.nec.com
Phone: +81 44 396 3287
EMail: i-nishioka@cb.jp.nec.com
Daniel King Old Dog Consulting United Kingdom
丹尼尔·金英国老狗咨询公司
Phone: +44 7790 775187
EMail: daniel@olddog.co.uk
Phone: +44 7790 775187
EMail: daniel@olddog.co.uk