Network Working Group J. Ash, Ed.
Request for Comments: 4657 AT&T
Category: Informational J.L. Le Roux, Ed.
France Telecom
September 2006
Network Working Group J. Ash, Ed.
Request for Comments: 4657 AT&T
Category: Informational J.L. Le Roux, Ed.
France Telecom
September 2006
Path Computation Element (PCE) Communication Protocol Generic Requirements
路径计算元件（PCE）通信协议通用要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol.
PCE模型在“PCE体系结构”文档中进行了描述，并促进了从路径计算客户端（PCC）到路径计算元素（PCE）的路径计算请求。本文件规定了PCC和PCE之间以及PCE之间通信协议的一般要求，其中PCE之间需要合作。后续文件将规定PCE通信协议的特定应用要求。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Overview of PCE Communication Protocol (PCECP) ..................4
5. PCE Communication Protocol Generic Requirements .................5
5.1. Basic Protocol Requirements ................................5
5.1.1. Commonality of PCC-PCE and PCE-PCE Communication ....5
5.1.2. Client-Server Communication .........................5
5.1.3. Transport ...........................................5
5.1.4. Path Computation Requests ...........................5
5.1.5. Path Computation Responses ..........................7
5.1.6. Cancellation of Pending Requests ....................7
5.1.7. Multiple Requests and Responses .....................8
5.1.8. Reliable Message Exchange ...........................8
5.1.9. Secure Message Exchange .............................9
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Overview of PCE Communication Protocol (PCECP) ..................4
5. PCE Communication Protocol Generic Requirements .................5
5.1. Basic Protocol Requirements ................................5
5.1.1. Commonality of PCC-PCE and PCE-PCE Communication ....5
5.1.2. Client-Server Communication .........................5
5.1.3. Transport ...........................................5
5.1.4. Path Computation Requests ...........................5
5.1.5. Path Computation Responses ..........................7
5.1.6. Cancellation of Pending Requests ....................7
5.1.7. Multiple Requests and Responses .....................8
5.1.8. Reliable Message Exchange ...........................8
5.1.9. Secure Message Exchange .............................9
5.1.10. Request Prioritization ............................10
5.1.11. Unsolicited Notifications .........................10
5.1.12. Asynchronous Communication ........................10
5.1.13. Communication Overhead Minimization ...............10
5.1.14. Extensibility .....................................11
5.1.15. Scalability .......................................11
5.1.16. Constraints .......................................12
5.1.17. Objective Functions Supported .....................13
5.2. Deployment Support Requirements ...........................13
5.2.1. Support for Different Service Provider
Environments .......................................13
5.2.2. Policy Support .....................................14
5.3. Aliveness Detection & Recovery Requirements ...............14
5.3.1. Aliveness Detection ................................14
5.3.2. Protocol Recovery ..................................14
5.3.3. LSP Rerouting & Reoptimization .....................14
6. Security Considerations ........................................15
7. Manageability Considerations ...................................16
8. Contributors ...................................................17
9. Acknowledgements ...............................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
5.1.10. Request Prioritization ............................10
5.1.11. Unsolicited Notifications .........................10
5.1.12. Asynchronous Communication ........................10
5.1.13. Communication Overhead Minimization ...............10
5.1.14. Extensibility .....................................11
5.1.15. Scalability .......................................11
5.1.16. Constraints .......................................12
5.1.17. Objective Functions Supported .....................13
5.2. Deployment Support Requirements ...........................13
5.2.1. Support for Different Service Provider
Environments .......................................13
5.2.2. Policy Support .....................................14
5.3. Aliveness Detection & Recovery Requirements ...............14
5.3.1. Aliveness Detection ................................14
5.3.2. Protocol Recovery ..................................14
5.3.3. LSP Rerouting & Reoptimization .....................14
6. Security Considerations ........................................15
7. Manageability Considerations ...................................16
8. Contributors ...................................................17
9. Acknowledgements ...............................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
A Path Computation Element (PCE) [RFC4655] supports requests for path computation issued by a Path Computation Client (PCC), which may be 'composite' (co-located) or 'external' (remote) from a PCE. When the PCC is external from the PCE, a request/response communication protocol is required to carry the path computation request and return the response. In order for the PCC and PCE to communicate, the PCC must know the location of the PCE; PCE discovery is described in [PCE-DISC-REQ].
路径计算元素（PCE）[RFC4655]支持由路径计算客户端（PCC）发出的路径计算请求，路径计算客户端可以是来自PCE的“复合”（共址）或“外部”（远程）。当PCC在PCE外部时，需要一个请求/响应通信协议来承载路径计算请求并返回响应。为了使PCC和PCE通信，PCC必须知道PCE的位置；PCE发现在[PCE-DISC-REQ]中有描述。
The PCE operates on a network graph in order to compute paths based on the path computation request(s) issued by the PCC(s). The path computation request will include the source and destination of the paths to be computed and a set of constraints to be applied during the computation, and it may also include an objective function. The PCE response includes the computed paths or the reason for a failed computation.
PCE在网络图上运行，以便根据PCC发出的路径计算请求计算路径。路径计算请求将包括要计算的路径的源和目的地以及在计算期间应用的一组约束，并且它还可以包括目标函数。PCE响应包括计算路径或计算失败的原因。
This document lists a set of generic requirements for the PCE Communication Protocol (PCECP). Application-specific requirements are beyond the scope of this document, and will be addressed in separate documents. For example, application-specific communication protocol requirements are given in [PCECP-INTER-AREA] and [PCECP-INTER-LAYER] for inter-area and inter-layer PCE applications, respectively.
本文件列出了PCE通信协议（PCECP）的一组通用要求。具体应用要求超出了本文件的范围，将在单独的文件中予以说明。例如，[PCECP-INTER-AREA]和[PCECP-INTER-LAYER]中分别针对区域间和层间PCE应用给出了特定于应用的通信协议要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "MAY NOT", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”、“不可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
Domain: Any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include Interior Gateway Protocol (IGP) areas, Autonomous Systems (ASs), multiple ASs within a service provider network, or multiple ASs across multiple service provider networks.
域：地址管理或路径计算责任的公共范围内的任何网络元素集合。域的示例包括内部网关协议（IGP）区域、自治系统（ASs）、服务提供商网络内的多个ASs或跨多个服务提供商网络的多个ASs。
GMPLS: Generalized Multi-Protocol Label Switching
广义多协议标签交换
LSP: MPLS/GMPLS Label Switched Path
LSP:MPLS/GMPLS标签交换路径
LSR: Label Switch Router
标签交换路由器
MPLS: Multi-Protocol Label Switching
多协议标签交换
PCC: Path Computation Client: Any client application requesting a path computation to be performed by the PCE.
路径计算客户端：任何请求由PCE执行路径计算的客户端应用程序。
PCE: Path Computation Element: An entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints (see further description in [RFC4655]).
PCE：路径计算元素：能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）（参见[RFC4655]中的进一步说明）。
TED: Traffic Engineering Database, which contains the topology and resource information of the network or network segment used by a PCE.
TED：流量工程数据库，包含PCE使用的网络或网段的拓扑和资源信息。
TE LSP: Traffic Engineering (G)MPLS Label Switched Path.
TE LSP：流量工程（G）MPLS标签交换路径。
See [RFC4655] for further definitions of terms.
有关术语的更多定义，请参见[RFC4655]。
In the PCE model, path computation requests are issued by a PCC to a PCE that may be composite (co-located) or external (remote). If the PCC and PCE are not co-located, a request/response communication protocol is required to carry the request and return the response. If the PCC and PCE are co-located, a communication protocol is not required, but implementations may choose to utilize a protocol for exchanges between the components.
在PCE模型中，路径计算请求由PCC向PCE发出，PCE可以是复合的（共址的）或外部的（远程的）。如果PCC和PCE不在同一位置，则需要一个请求/响应通信协议来承载请求并返回响应。如果PCC和PCE位于同一位置，则不需要通信协议，但是实现可以选择利用协议在组件之间进行交换。
In order for a PCC and PCE to communicate, the PCC must know the location of the PCE. This can be configured or discovered. The PCE discovery mechanism is out of scope of this document, but requirements are documented in [PCE-DISC-REQ].
为了使PCC和PCE通信，PCC必须知道PCE的位置。这可以配置或查找。PCE发现机制不在本文件范围内，但要求记录在[PCE-DISC-REQ]中。
The PCE operates on a network graph built from the TED in order to compute paths. The mechanism by which the TED is populated is out of scope for the PCECP.
PCE在TED构建的网络图上运行，以计算路径。填充TED的机制超出PCECP的范围。
A path computation request issued by the PCC includes a specification of the path(s) needed. The information supplied includes, at a minimum, the source and destination for the paths, but may also include a set of further requirements (known as constraints) as described in Section 5.
PCC发出的路径计算请求包括所需路径的规范。所提供的信息至少包括路径的来源和目的地，但也可能包括一组进一步的要求（称为约束条件），如第5节所述。
The response from the PCE may be positive in which case it will include the paths that have been computed. If the computation fails or cannot be performed, a negative response is required with an indication of the type of failure.
来自PCE的响应可能为正，在这种情况下，它将包括已计算的路径。如果计算失败或无法执行，则需要否定响应，并指示故障类型。
A request/response protocol is also required for a PCE to communicate path computation requests to another PCE and for that PCE to return the path computation response. As described in [RFC4655], there is no reason to assume that two different protocols are needed, and this document assumes that a single protocol will satisfy all requirements for PCC-PCE and PCE-PCE communication.
PCE还需要请求/响应协议来将路径计算请求传送到另一个PCE，并且该PCE返回路径计算响应。如[RFC4655]所述，没有理由假设需要两个不同的协议，本文件假设一个协议将满足PCC-PCE和PCE-PCE通信的所有要求。
[RFC4655] describes four models of PCE: composite, external, multiple PCE path computation, and multiple PCE path computation with inter-PCE communication. In all cases except the composite PCE model, a PCECP is required. The requirements defined in this document are applicable to all models described in [RFC4655].
[RFC4655]描述了PCE的四种模型：复合、外部、多PCE路径计算和具有PCE间通信的多PCE路径计算。除复合PCE型号外，所有情况下都需要PCECP。本文件中定义的要求适用于[RFC4655]中描述的所有型号。
A single protocol MUST be defined for PCC-PCE and PCE-PCE communication. A PCE requesting a path from another PCE can be considered a PCC, and in the remainder of this document we refer to all communications as PCC-PCE regardless of whether they are PCC-PCE or PCE-PCE.
必须为PCC-PCE和PCE-PCE通信定义一个协议。从另一个PCE请求路径的PCE可以被视为PCC，在本文档的其余部分中，我们将所有通信称为PCC-PCE，无论它们是PCC-PCE还是PCE-PCE。
PCC-PCE communication is by nature client-server based. The PCECP MUST allow a PCC to send a request message to a PCE to request path computation, and for a PCE to reply with a response message to the requesting PCC once the path has been computed.
PCC-PCE通信本质上是基于客户机-服务器的。PCECP必须允许PCC向PCE发送请求消息以请求路径计算，并允许PCE在计算路径后向请求PCC回复响应消息。
In addition to this request-response mode, there are cases where there is unsolicited communication from the PCE to the PCC (see Section 5.1.11).
除此请求-响应模式外，还存在从PCE到PCC的未经请求的通信（见第5.1.11节）。
The PCECP SHOULD utilize an existing transport protocol that supports congestion control. This transport protocol may also be used to satisfy some requirements in other sections of this document, such as reliability. The PCECP SHOULD be defined for one transport protocol only in order to ensure interoperability. The transport protocol MUST NOT limit the size of the message used by the PCECP.
PCECP应利用支持拥塞控制的现有传输协议。该传输协议也可用于满足本文件其他章节的某些要求，如可靠性。应仅为一个传输协议定义PCECP，以确保互操作性。传输协议不得限制PCECP使用的消息的大小。
The path computation request message MUST include at least the source and destination. Note that the path computation request is for an LSP or LSP segment, and the source and destination supplied are the start and end of the computation being requested (i.e., of the LSP segment).
路径计算请求消息必须至少包括源和目标。注意，路径计算请求是针对LSP或LSP段的，并且提供的源和目的地是所请求的计算（即LSP段）的开始和结束。
The path computation request message MUST support the inclusion of a set of one or more path constraints, including but not limited to the requested bandwidth or resources (hops, affinities, etc.) to include/exclude. For example, a PCC may request the PCE to exclude points of failure in the computation of a new path if an LSP setup fails. The actual inclusion of constraints is a choice for the PCC issuing the request. A list of core constraints that must be supported by the PCECP is supplied in Section 5.1.16. Specification of constraints MUST be future-proofed as described in Section 5.1.14.
路径计算请求消息必须支持包含一组或多个路径约束，包括但不限于要包含/排除的请求带宽或资源（跳数、亲缘关系等）。例如，如果LSP设置失败，PCC可以请求PCE排除新路径计算中的故障点。实际包含约束是发出请求的PCC的选择。第5.1.16节提供了PCECP必须支持的核心约束列表。约束规范必须按照第5.1.14节所述进行未来验证。
The requester MUST be allowed to select from or prefer an advertised list or minimal subset of standard objective functions and functional options. An objective function is used by the PCE to process constraints to a path computation request when it computes a path in order to select the "best" candidate paths (e.g., minimum hop path), and corresponds to the optimization criteria used for the computation of one path, or the synchronized computation of a set of paths. In the case of unsynchronized path computation, this can be, for example, the path cost or the residual bandwidth on the most loaded path link. In the case of synchronized path computation, this can be, for example, the global bandwidth consumption or the residual bandwidth on the most loaded network link.
必须允许请求者从公布的列表或标准目标函数和功能选项的最小子集中进行选择或选择。当PCE计算路径以选择“最佳”候选路径（例如，最小跳路径）时，目标函数被PCE用于处理对路径计算请求的约束，并且对应于用于计算一条路径或同步计算一组路径的优化准则。在非同步路径计算的情况下，例如，这可以是路径成本或负载最大的路径链路上的剩余带宽。在同步路径计算的情况下，例如，这可以是全局带宽消耗或负载最大的网络链路上的剩余带宽。
A list of core objective functions that MUST be supported by the PCECP is supplied in Section 5.1.17. Specification of objective functions MUST be future-proofed as described in Section 5.1.14.
第5.1.17节提供了PCECP必须支持的核心目标函数列表。目标函数的规范必须按照第5.1.14节所述进行未来验证。
The requester SHOULD also be able to select a vendor-specific or experimental objective function or functional option. Furthermore, the requester MUST be allowed to customize the function/options in use. That is, individual objective functions will often have parameters to be set in the request from PCC to PCE. Support for the specification of objective functions and objective parameters is required in the protocol extensibility specified in Section 5.1.14.
请求者还应能够选择供应商特定的或实验性的目标函数或功能选项。此外，必须允许请求者自定义正在使用的功能/选项。也就是说，单个目标函数通常会在从PCC到PCE的请求中设置参数。第5.1.14节规定的协议扩展性要求支持目标函数和目标参数的规范。
A request message MAY include TE parameters carried by the MPLS/GMPLS LSP setup signaling protocol. Also, it MUST be possible for the PCE to apply additional objective functions. This might include policy-based routing path computation for load balancing instructed by the management plane.
请求消息可以包括由MPLS/GMPLS LSP设置信令协议携带的TE参数。此外，PCE必须能够应用额外的目标函数。这可能包括管理平面指示的用于负载平衡的基于策略的路由路径计算。
Shortest path selection may rely either on the TE metric or on the IGP metric [METRIC]. Hence the PCECP request message MUST allow the PCC to indicate the metric type (IGP or TE) to be used for shortest path selection. Note that other metric types may be specified in the future.
最短路径选择可能依赖于TE度量或IGP度量[metric]。因此，PCECP请求消息必须允许PCC指示用于最短路径选择的度量类型（IGP或TE）。请注意，将来可能会指定其他度量类型。
There may be cases where a single path cannot fit a given bandwidth request, while a set of paths could be combined to fit the request. Such path combination to serve a given request is called load-balancing. The request message MUST allow the PCC to indicate if load-balancing is allowed. It MUST also include the maximum number of paths in a load-balancing path group, and the minimum path bandwidth in a load-balancing path group. The request message MUST allow specification of the degree of disjointness of the members of the load-balancing group.
在某些情况下，单个路径无法满足给定的带宽请求，而一组路径可以组合以满足该请求。这种服务于给定请求的路径组合称为负载平衡。请求消息必须允许PCC指示是否允许负载平衡。它还必须包括负载平衡路径组中的最大路径数和负载平衡路径组中的最小路径带宽。请求消息必须允许指定负载平衡组成员的不相交程度。
The path computation response message MUST allow the PCE to return various elements including, at least, the computed path(s).
路径计算响应消息必须允许PCE返回各种元素，至少包括计算出的路径。
The protocol MUST be capable of returning any explicit path that would be acceptable for use for MPLS and GMPLS LSPs once converted to an Explicit Route Object for use in RSVP-TE signaling. In addition, anything that can be expressed in an Explicit Route Object MUST be capable of being returned in the computed path. Note that the resultant path(s) may be made up of a set of strict or loose hops, or any combination of strict and loose hops. Moreover, a hop may have the form of a non-simple abstract node. See [RFC3209] for the definition of strict hop, loose hop, and abstract node.
一旦转换为显式路由对象用于RSVP-TE信令，协议必须能够返回MPLS和GMPLS LSP可接受的任何显式路径。此外，可以在显式路由对象中表示的任何内容都必须能够在计算路径中返回。注意，结果路径可以由一组严格跳或松散跳组成，或者由严格跳和松散跳的任意组合组成。此外，跳可以具有非简单抽象节点的形式。有关严格跃点、松散跃点和抽象节点的定义，请参见[RFC3209]。
A positive response from the PCE MUST include the paths that have been computed. A positive PCECP computation response MUST support the inclusion of a set of attributes of the computed path, such as the path costs (e.g., cumulative link TE metrics and cumulative link IGP metrics) and the computed bandwidth. The latter is useful when a single path cannot serve the requested bandwidth and load balancing is applied.
PCE的肯定响应必须包括已计算的路径。正的PCECP计算响应必须支持包含计算路径的一组属性，例如路径成本（例如，累积链路TE度量和累积链路IGP度量）和计算带宽。当单个路径无法提供请求的带宽且应用了负载平衡时，后者非常有用。
When a path satisfying the constraints cannot be found, or if the computation fails or cannot be performed, a negative response MUST be sent. This response MAY include further details of the reason(s) for the failure and MAY include advice about which constraints might be relaxed to be more likely to achieve a positive result.
当无法找到满足约束的路径时，或者如果计算失败或无法执行，则必须发送否定响应。该响应可能包括故障原因的进一步详细信息，并可能包括关于哪些约束可能被放宽以更可能实现积极结果的建议。
The PCECP response message MUST support the inclusion of the set of computed paths of a load-balancing path group, as well as their respective bandwidths.
PCECP响应消息必须支持包含负载平衡路径组的一组计算路径，以及它们各自的带宽。
A PCC MUST be able to cancel a pending request using an appropriate message. A PCC that has sent a request to a PCE and no longer needs a response, for instance, because it no longer wants to set up the
PCC必须能够使用适当的消息取消挂起的请求。例如，已向PCE发送请求且不再需要响应的PCC，因为它不再希望设置
associated service, MUST be able to notify the PCE that it can clear the request (i.e., stop the computation if already started, and clear the context). The PCE may also wish to cancel a pending request because of some congested state.
关联服务必须能够通知PCE它可以清除请求（即，如果已经启动，则停止计算，并清除上下文）。由于某些拥塞状态，PCE还可能希望取消挂起的请求。
It MUST be possible to send multiple path computation requests within the same request message. Such requests may be correlated (e.g., requesting disjoint paths) or uncorrelated (requesting paths for unrelated services). It MUST be possible to limit by configuration of both PCCs and PCEs the number of requests that can be carried within a single message.
必须能够在同一请求消息中发送多个路径计算请求。此类请求可以是相关的（例如，请求不相交的路径）或不相关的（请求不相关服务的路径）。必须能够通过配置PCC和PCE来限制单个消息中可承载的请求数量。
Similarly, it MUST be possible to return multiple computed paths within the same response message, corresponding either to the same request (e.g., multiple suited paths, paths of a load-balancing path group) or to distinct requests, correlated or not, of the same request message or distinct request messages.
类似地，必须能够在同一响应消息内返回多个计算路径，对应于同一请求（例如，多个适合的路径、负载平衡路径组的路径）或同一请求消息或不同请求消息的不同请求（相关与否）。
It MUST be possible to provide "continuation correlation" where all related requests or computed paths cannot fit within one message and are carried in a sequence of correlated messages.
如果所有相关请求或计算路径不能包含在一条消息中，并且在一系列相关消息中进行，则必须能够提供“连续相关”。
The PCE MUST inform the PCC of its capabilities. Maximum acceptable message sizes and the maximum number of requests per message supported by a PCE MAY form part of PCE capabilities advertisement [PCE-DISC-REQ] or MAY be exchanged through information messages from the PCE as part of the protocol described here.
PCE必须将其能力告知PCC。PCE支持的最大可接受消息大小和每条消息的最大请求数可以构成PCE能力公告[PCE-DISC-REQ]的一部分，或者可以通过来自PCE的信息消息作为此处描述的协议的一部分进行交换。
It MUST be possible for a PCC to specify, in the request message, the maximum acceptable response message sizes and the maximum number of computed paths per response message it can support.
PCC必须能够在请求消息中指定可接受的最大响应消息大小以及它可以支持的每个响应消息的最大计算路径数。
It MUST be possible to limit the message size by configuration on PCCs and PCEs.
必须能够通过PCC和PCE上的配置限制消息大小。
The PCECP MUST support reliable transmission of PCECP packets. This may form part of the protocol itself or may be achieved by the selection of a suitable transport protocol (see Section 5.1.3).
PCECP必须支持PCECP数据包的可靠传输。这可能构成协议本身的一部分，也可能通过选择合适的传输协议来实现（见第5.1.3节）。
In particular, it MUST allow for the detection and recovery of lost messages to occur quickly and not impede the operation of the PCECP.
特别是，它必须允许快速检测和恢复丢失的消息，并且不妨碍PCECP的运行。
In some cases (e.g., after link failure), a large number of PCCs may simultaneously send requests to a PCE, leading to a potential
在某些情况下（例如，链路故障后），大量PCC可能同时向PCE发送请求，从而导致潜在的故障
saturation of the PCEs. The PCECP MUST support indication of congestion state and rate limitation state. This should enable, for example, a PCE to limit the rate of incoming request messages if the request rate is too high.
PCE的饱和。PCECP必须支持拥塞状态和速率限制状态的指示。例如，如果请求速率太高，这应允许PCE限制传入请求消息的速率。
The PCECP or its transport protocol MUST provide the following:
PCECP或其传输协议必须提供以下内容：
- Detection and report of lost or corrupted messages - Automatic attempts to retransmit lost messages without reference to the application - Handling of out-of-order messages - Handling of duplicate messages - Flow control and back-pressure to enable throttling of requests and responses - Rapid PCECP communication failure detection - Distinction between partner failure and communication channel failure after the PCECP communication is recovered
- 检测和报告丢失或损坏的消息-自动尝试在不参考应用程序的情况下重新传输丢失的消息-处理无序消息-处理重复消息-流量控制和背压以实现请求和响应的节流-快速PCECP通信故障检测-区分PCECP通信恢复后，伙伴故障和通信信道故障之间
If it is necessary to add functions to PCECP to overcome shortcomings in the chosen transport mechanisms, these functions SHOULD be based on and re-use where possible techniques developed in other protocols to overcome the same shortcomings. Functionality MUST NOT be added to the PCECP where the chosen transport protocol already provides it.
如果有必要向PCECP添加功能以克服所选传输机制中的缺点，则这些功能应基于并在可能的情况下重用其他协议中开发的技术以克服相同的缺点。如果所选传输协议已提供功能，则不得将功能添加到PCECP。
The PCC-PCE communication protocol MUST include provisions to ensure the security of the exchanges between the entities. In particular, it MUST support mechanisms to prevent spoofing (e.g., authentication), snooping (e.g., preservation of confidentiality of information through techniques such as encryption), and Denial of Service (DoS) attacks (e.g., packet filtering, rate limiting, no promiscuous listening). Once a PCC is identified and authenticated, it has the same privileges as all other PCCs.
PCC-PCE通信协议必须包括确保实体间交换安全的规定。特别是，它必须支持防止欺骗（例如，身份验证）、窥探（例如，通过加密等技术保护信息的机密性）和拒绝服务（DoS）攻击（例如，数据包过滤、速率限制、无乱听）的机制。一旦一个PCC被识别和认证，它就拥有与所有其他PCC相同的特权。
To ensure confidentiality, the PCECP SHOULD allow local policy to be configured on the PCE to not provide explicit path(s). If a PCC requests an explicit path when this is not allowed, the PCE MUST return an error message to the requesting PCC and the pending path computation request MUST be discarded.
为确保机密性，PCECP应允许在PCE上配置本地策略，以不提供显式路径。如果PCC在不允许的情况下请求显式路径，PCE必须向请求PCC返回错误消息，并且必须放弃挂起的路径计算请求。
Authorization requirements [RFC3127] include reject capability, reauthorization on demand, support for access rules and filters, and unsolicited disconnect.
授权要求[RFC3127]包括拒绝功能、按需重新授权、对访问规则和过滤器的支持以及主动断开连接。
IP addresses are used to identify PCCs and PCEs. Where the PCC-PCE communication takes place entirely within one limited domain, the use of a private address space that is not available to customer systems MAY be used to help protect the information exchange, but other mechanisms MUST also be available.
IP地址用于识别PCC和PCE。如果PCC-PCE通信完全在一个有限域内进行，则可以使用客户系统不可用的专用地址空间来帮助保护信息交换，但也必须使用其他机制。
These functions may be provided by the transport protocol or directly by the PCECP. See Section 6 for further discussion of security considerations.
这些功能可以由传输协议提供，也可以直接由PCECP提供。有关安全注意事项的进一步讨论，请参见第6节。
The PCECP MUST allow a PCC to specify the priority of a computation request.
PCECP必须允许PCC指定计算请求的优先级。
Implementation of priority-based activity within a PCE is subject to implementation and local policy. This application processing is out of scope of the PCECP.
PCE内基于优先级的活动的实施取决于实施和当地政策。此应用程序处理超出PCECP的范围。
The normal operational mode is for the PCC to make path computation requests to the PCE and for the PCE to respond.
正常操作模式是PCC向PCE发出路径计算请求并由PCE响应。
The PCECP MUST support unsolicited notifications from PCE to PCC, or PCC to PCE. This requirement facilitates the unsolicited communication of information and alerts between PCCs and PCEs. As specified in Section 5.1.8, these notification messages must be supported by a reliable transmission protocol. The PCECP MAY also support response messages to the unsolicited notification messages.
PCECP必须支持从PCE到PCC或PCC到PCE的非请求通知。这一要求有助于PCC和PCE之间的信息和警报的主动通信。如第5.1.8节所述，这些通知消息必须由可靠的传输协议支持。PCECP还可以支持对未经请求的通知消息的响应消息。
The PCC-PCE protocol MUST allow for asynchronous communication. A PCC MUST NOT have to wait for a response to one request before it can make another request.
PCC-PCE协议必须允许异步通信。PCC在发出另一个请求之前，不必等待对一个请求的响应。
It MUST also be possible to have the order of responses differ from the order of the corresponding requests. This may occur, for instance, when path request messages have different priorities (see Requirement 5.1.10). A consequent requirement is that path computation responses MUST include a direct correlation to the associated request.
还必须能够使响应顺序不同于相应请求的顺序。例如，当路径请求消息具有不同优先级时，可能会发生这种情况（见要求5.1.10）。随后的要求是路径计算响应必须包括与相关请求的直接关联。
The request and response messages SHOULD be designed so that the communication overhead is minimized. In particular, the overhead per
请求和响应消息的设计应使通信开销最小化。特别是，每小时的开销
message SHOULD be minimized, and the number of bytes exchanged to arrive at a computation answer SHOULD be minimized. Other considerations in overhead minimization include the following:
消息应该最小化，并且为了得到计算结果而交换的字节数应该最小化。开销最小化的其他注意事项包括：
- the number of background messages used by the protocol or its transport protocol to keep alive any session or association between the PCE and PCC - the processing cost at the PCE (or PCC) associated with request/response messages (as distinct from processing the computation requests themselves)
- 协议或其传输协议用于保持PCE和PCC之间的任何会话或关联的后台消息数-PCE（或PCC）与请求/响应消息相关联的处理成本（不同于处理计算请求本身）
The PCECP MUST provide a way for the introduction of new path computation constraints, diversity types, objective functions, optimization methods and parameters, and so on, without requiring major modifications in the protocol.
PCECP必须提供引入新路径计算约束、多样性类型、目标函数、优化方法和参数等的方法，而不需要对协议进行重大修改。
For example, the PCECP MUST be extensible to support various PCE-based applications, such as the following:
例如，PCECP必须可扩展以支持各种基于PCE的应用程序，例如：
- intra-area path computation - inter-area path computation [PCECP-INTER-AREA] - inter-AS intra provider and inter-AS inter-provider path computation [PCECP-INTER-AS] - inter-layer path computation [PCECP-INTER-LAYER]
- 区域内路径计算-区域间路径计算[PCECP-inter-area]-作为内部提供者的内部和作为内部提供者的内部路径计算[PCECP-inter-AS]-层间路径计算[PCECP-inter-layer]
The PCECP MUST support the requirements specified in the application-specific requirements documents. The PCECP MUST also allow extensions as more PCE applications will be introduced in the future.
PCECP必须支持应用程序特定要求文件中规定的要求。PCECP还必须允许扩展，因为将来将引入更多的PCE应用程序。
The PCECP SHOULD also be extensible to support future applications not currently in the scope of the PCE working group, such as, for instance, point-to-multipoint path computations, multi-hop pseudowire path computation, etc.
PCECP还应可扩展以支持当前不在PCE工作组范围内的未来应用，例如，点对多点路径计算、多跳伪线路径计算等。
Note that application specific requirements are out of the scope of this document and will be addressed in separate requirements documents.
请注意，特定于应用程序的要求不在本文件的范围内，将在单独的要求文件中予以说明。
The PCECP MUST scale well, at least as good as linearly, with an increase of any of the following parameters. Minimum order of magnitude estimates of what the PCECP should support are given in parenthesis (note: these are requirements on the PCECP, not on the PCE):
随着下列任何参数的增加，PCECP必须具有良好的伸缩性，至少与线性一样好。括号中给出了PCECP应支持的最低数量级估计值（注：这些是PCECP的要求，而不是PCE的要求）：
- number of PCCs (1000/domain) - number of PCEs (100/domain) - number of PCCs communicating with a single PCE (1000) - number of PCEs communicated to by a single PCC (100) - number of domains (20) - number of path request messages (average of 10/second/PCE) - handling bursts of requests (burst of 100/second/PCE within a 10- second interval).
- PCC的数量（1000/域）-PCE的数量（100/域）-与单个PCE通信的PCC的数量（1000）-由单个PCC通信的PCE的数量（100）-域的数量（20）-路径请求消息的数量（平均10/秒/PCE）-处理请求的突发（在10秒内突发100/秒/PCE）。
Note that path requests can be bundled in path request messages, for example, 10 PCECP request messages/second may correspond to 100 path requests/second.
注意，路径请求可以捆绑在路径请求消息中，例如，每秒10个PCECP请求消息可能对应每秒100个路径请求。
Bursts of requests may arise, for example, after a network outage when multiple recomputations are requested. The PCECP MUST handle the congestion in a graceful way so that it does not unduly impact the rest of the network, and so that it does not gate the ability of the PCE to perform computation.
例如，在网络中断后，当请求多次重新计算时，可能会出现突发请求。PCECP必须以一种优雅的方式处理拥塞，以便它不会对网络的其余部分造成不适当的影响，并且不会限制PCE执行计算的能力。
This section provides a list of generic constraints that MUST be supported by the PCECP. Other constraints may be added to service specific applications as identified by separate application-specific requirements documents. Note that the provisions of Section 5.1.14 mean that new constraints can be added to this list without impacting the protocol to a level that requires major protocol changes.
本节提供PCECP必须支持的通用约束列表。其他约束可能会添加到服务特定的应用程序中，如单独的应用程序特定需求文件所示。请注意，第5.1.14节的规定意味着可以将新的约束添加到此列表中，而不会对协议造成影响，从而需要对协议进行重大更改。
The set of supported generic constraints MUST include at least the following:
受支持的通用约束集必须至少包括以下内容：
o MPLS-TE and GMPLS generic constraints: - Bandwidth - Affinities inclusion/exclusion - Link, Node, Shared Risk Link Group (SRLG) inclusion/exclusion - Maximum end-to-end IGP metric - Maximum hop count - Maximum end-to-end TE metric - Degree of paths disjointness (Link, Node, SRLG)
o MPLS-TE和GMPLS通用约束：-带宽-亲和力包含/排除-链路、节点、共享风险链路组（SRLG）包含/排除-最大端到端IGP度量-最大跳数-最大端到端TE度量-路径不相交度（链路、节点、SRLG）
o MPLS-TE specific constraints - Class-type - Local protection - Node protection - Bandwidth protection
o MPLS-TE特定约束-类别类型-本地保护-节点保护-带宽保护
o GMPLS specific constraints - Switching type, encoding type - Link protection type
o GMPLS特定约束-切换类型、编码类型-链路保护类型
This section provides a list of generic objective functions that MUST be supported by the PCECP. Other objective functions MAY be added to service specific applications as identified by separate application-specific requirements documents. Note that the provisions of Section 5.1.14 mean that new objective functions MAY be added to this list without impacting the protocol.
本节提供了PCECP必须支持的通用目标函数列表。其他目标功能可添加到服务特定应用中，如单独的应用特定需求文件所示。注意，第5.1.14节的规定意味着可以在不影响协议的情况下将新的目标函数添加到此列表中。
The PCECP MUST support at least the following "unsynchronized" functions:
PCECP必须至少支持以下“非同步”功能：
- Minimum cost path with respect to a specified metric (shortest path) - Least loaded path - Maximum available bandwidth path
- 相对于指定指标的最小成本路径（最短路径）-最小负载路径-最大可用带宽路径
Also, the PCECP MUST support at least the following "synchronized" objective functions:
此外，PCECP必须至少支持以下“同步”目标函数：
- Minimize aggregate bandwidth consumption on all links - Maximize the residual bandwidth on the most loaded link - Minimize the cumulative cost of a set of diverse paths
- 最小化所有链路上的总带宽消耗-最大化负载最多的链路上的剩余带宽-最小化一组不同路径的累积成本
The PCECP must at least support the following environments:
PCECP必须至少支持以下环境：
- MPLS-TE and GMPLS networks - Packet and non-packet networks - Centralized and distributed PCE path computation - Single and multiple PCE path computation
- MPLS-TE和GMPLS网络-分组和非分组网络-集中式和分布式PCE路径计算-单个和多个PCE路径计算
For example, PCECP is possibly applicable to packet networks (e.g., IP networks), non-packet networks (e.g., time-division multiplexed (TDM) transport), and perhaps to multi-layer GMPLS control plane environments. Definitions of centralized, distributed, single, and multiple PCE path computation can be found in [RFC4655].
例如，PCECP可能适用于分组网络（例如IP网络）、非分组网络（例如时分复用（TDM）传输），并且可能适用于多层GMPLS控制平面环境。集中式、分布式、单个和多个PCE路径计算的定义见[RFC4655]。
The PCECP MUST allow for the use of policies to accept/reject requests. It MUST include the ability for a PCE to supply sufficient detail when it rejects a request for policy reasons to allow the PCC to determine the reason for rejection or failure. For example, filtering could be required for a PCE that serves one domain (perhaps an AS) such that all requests that come from another domain (AS) are rejected. However, specific policy details are left to application-specific PCECP requirements. Actual policies, configuration of policies, and applicability of policies are out of scope.
PCECP必须允许使用策略来接受/拒绝请求。它必须包括PCE在出于政策原因拒绝请求时提供足够详细信息的能力，以允许PCC确定拒绝或失败的原因。例如，可能需要对服务于一个域（可能是AS）的PCE进行过滤，以便拒绝来自另一个域（AS）的所有请求。但是，具体的策略细节由特定于应用程序的PCECP要求决定。实际策略、策略配置和策略适用性超出范围。
Note that work on supported policy models and the corresponding requirements/implications is being undertaken as a separate work item in the PCE working group.
请注意，关于受支持的政策模型和相应要求/影响的工作正在PCE工作组中作为一个单独的工作项目进行。
PCECP messages MUST be able to carry transparent policy information.
PCECP消息必须能够携带透明的策略信息。
The PCECP MUST allow a PCC/PCE to
PCECP必须允许PCC/PCE
- check the liveliness of the PCC-PCE communication, - rapidly detect PCC-PCE communication failure (indifferently to partner failure or connectivity failure), and - distinguish PCC/PCE node failures from PCC-PCE connectivity failures, after the PCC-PCE communication is recovered.
- 检查PCC-PCE通信的活跃性，-在恢复PCC-PCE通信后，快速检测PCC-PCE通信故障（与合作伙伴故障或连接故障无关），并-区分PCC/PCE节点故障和PCC-PCE连接故障。
The aliveness detection mechanism MUST ensure reciprocal knowledge of PCE and PCC liveness.
活性检测机制必须确保PCE和PCC活性的相互了解。
In the event of the failure of a sender or of the communication channel, the PCECP, upon recovery, MUST support resynchronization of information (e.g., PCE congestion status) and requests between the sender and the receiver; this SHOULD be arranged so as to minimize repeat data transfer.
在发送方或通信信道发生故障的情况下，PCECP在恢复时必须支持发送方和接收方之间的信息（例如，PCE拥塞状态）和请求的重新同步；这种安排应尽量减少重复数据传输。
If an LSP fails owing to the failure of a link or node that it traverses, a new computation request may be made to a PCE in order to repair the LSP. Since the PCC cannot know that the PCE's TED has been updated to reflect the failure network information, it is useful to include this information in the new path computation request.
如果LSP由于其所穿越的链路或节点的故障而失败，则可以向PCE发出新的计算请求以修复LSP。由于PCC无法知道PCE的TED已更新以反映故障网络信息，因此在新路径计算请求中包含该信息是有用的。
Also, in order to re-use the resources used by the old LSP, it may be advantageous to indicate the route of the old LSP as part of the new path computation request.
此外，为了重用旧LSP使用的资源，将旧LSP的路由指示为新路径计算请求的一部分可能是有利的。
Hence the path computation request message MUST allow an indication of whether the computation is for LSP restoration, and it MUST support the inclusion of the previously computed path as well as the identity of the failed element. Note that the old path might only be useful if the old LSP has not yet been torn down. The PCE MAY choose to take failure indication information carried in a given request into account when handling subsequent requests. This should be driven by local policy decision.
因此，路径计算请求消息必须允许指示计算是否用于LSP恢复，并且必须支持包含先前计算的路径以及失败元素的标识。请注意，只有在旧LSP尚未拆除的情况下，旧路径才可能有用。PCE可以选择在处理后续请求时考虑给定请求中携带的故障指示信息。这应该由当地的政策决定来推动。
Note that a network failure may impact a large number of LSPs. In this case, a potentially large number of PCCs will simultaneously send requests to the PCE. The PCECP MUST properly handle such overload situations, such as, for instance, through throttling of requests as set forth in Section 5.1.8.
请注意，网络故障可能会影响大量LSP。在这种情况下，潜在的大量PCC将同时向PCE发送请求。PCECP必须正确处理此类过载情况，例如，通过第5.1.8节规定的请求节流。
The path computation request message MUST support TE LSP path reoptimization and the inclusion of a previously computed path. This will help ensure optimal routing of a reoptimized path, since it will allow the PCE to avoid double bandwidth accounting and help reduce blocking issues.
路径计算请求消息必须支持TE LSP路径重新优化和包含先前计算的路径。这将有助于确保重新优化路径的最佳路由，因为这将允许PCE避免双带宽计费，并有助于减少阻塞问题。
Key management MUST be provided by the PCECP to provide for the authenticity and integrity of PCECP messages. This will allow protecting against PCE or PCC impersonation and also against message content falsification.
PCECP必须提供密钥管理，以确保PCECP消息的真实性和完整性。这将允许防止PCE或PCC模拟，也可以防止消息内容伪造。
The impact of the use of a PCECP MUST be considered in light of the impact that it has on the security of the existing routing and signaling protocols and techniques in use within the network. Intra-domain security is impacted since there is a new interface, protocol, and element in the network. Any host in the network could impersonate a PCC and receive detailed information on network paths. Any host could also impersonate a PCE, both gathering information about the network before passing the request on to a real PCE and spoofing responses. Some protection here depends on the security of the PCE discovery process (see [PCE-DISC-REQ]). An increase in inter-domain information flows may increase the vulnerability to security attacks, and the facilitation of inter-domain paths may increase the impact of these security attacks.
必须根据PCECP对网络中使用的现有路由和信令协议和技术的安全性的影响来考虑PCECP的使用影响。由于网络中存在新的接口、协议和元素，域内安全受到影响。网络中的任何主机都可以模拟PCC并接收有关网络路径的详细信息。任何主机也可以模拟PCE，既可以在将请求传递给真实PCE之前收集有关网络的信息，也可以欺骗响应。此处的某些保护取决于PCE发现过程的安全性（请参阅[PCE-DISC-REQ]）。域间信息流的增加可能会增加安全攻击的脆弱性，而域间路径的便利化可能会增加这些安全攻击的影响。
Of particular relevance are the implications for confidentiality inherent in a PCECP for multi-domain networks. It is not necessarily
特别相关的是多域网络PCECP中固有的保密性含义。不一定
the case that a multi-domain PCE solution will compromise security, but solutions MUST examine their impacts in this area.
多域PCE解决方案会损害安全性，但解决方案必须检查其在该领域的影响。
Applicability statements for particular combinations of signaling, routing, and path computation techniques are expected to contain detailed security sections.
信令、路由和路径计算技术的特定组合的适用性声明预计将包含详细的安全部分。
It should be observed that the use of an external PCE introduces additional security issues. Most notable among these are the following:
应该注意的是，使用外部PCE会带来额外的安全问题。其中最值得注意的是：
- Interception of PCE requests or responses - Impersonation of PCE or PCC - DoS attacks on PCEs or PCCs
- 拦截PCE请求或响应-模拟PCE或PCC-对PCE或PCC的DoS攻击
The PCECP MUST address these issues in detail using authentication, encryption, and DoS protection techniques. See also Section 5.1.9.
PCECP必须使用身份验证、加密和DoS保护技术详细解决这些问题。另见第5.1.9节。
There are security implications of allowing arbitrary objective functions, as discussed in Section 5.1.17, and the PCECP MUST allow mitigating the risk of, for example, a PCC using complex objectives to intentionally drive a PCE into resource exhaustion.
如第5.1.17节所述，允许任意目标函数存在安全影响，PCECP必须允许降低PCC使用复杂目标故意驱动PCE耗尽资源的风险。
Manageability of the PCECP MUST address the following considerations:
PCECP的可管理性必须考虑以下因素：
- The need for a MIB module for control and monitoring of PCECP - The need for built-in diagnostic tools to test the operation of the protocol (e.g., partner failure detection, Operations Administration and Maintenance (OAM), etc.) - Configuration implications for the protocol
- 需要MIB模块来控制和监控PCECP-需要内置诊断工具来测试协议的运行（例如，合作伙伴故障检测、操作管理和维护（OAM）等）-协议的配置影响
PCECP operations MUST be modeled and controlled through appropriate MIB modules. There are enough specific differences between PCCs and PCEs to lead to the need of defining separate MIB modules. Statistics gathering will form an important part of the operation of the PCECP. The MIB modules MUST provide information that will allow an operator to determine PCECP historical interactions and the success rate of requests. Similarly, it is important for an operator to be able to determine PCECP and PCE load and whether an individual PCC is responsible for a disproportionate amount of the load. It MUST be possible, through use of MIB modules, to record and inspect statistics about the PCECP communications, including issues such as malformed messages, unauthorized messages, and messages discarded owing to congestion.
PCECP操作必须通过适当的MIB模块进行建模和控制。PCC和PCE之间有足够的具体差异，因此需要定义单独的MIB模块。统计数据收集将构成PCECP运作的重要组成部分。MIB模块必须提供允许操作员确定PCECP历史交互和请求成功率的信息。同样，运营商能够确定PCECP和PCE负荷以及单个PCC是否对不成比例的负荷负责也很重要。通过使用MIB模块，必须能够记录和检查PCECP通信的统计信息，包括错误消息、未授权消息和因拥塞而丢弃的消息等问题。
The new MIB modules should also be used to provide notifications (traps) when thresholds are crossed or when important events occur. For example, the MIB module may support indication of exceeding the congestion state threshold or rate limitation state.
新的MIB模块还应用于在超过阈值或发生重要事件时提供通知（陷阱）。例如，MIB模块可支持超过拥塞状态阈值或速率限制状态的指示。
PCECP techniques must enable a PCC to determine the liveness of a PCE both before it sends a request and in the period between sending a request and receiving a response.
PCECP技术必须使PCC能够在发送请求之前以及在发送请求和接收响应之间确定PCE的活跃度。
It is also important for a PCE to know about the liveness of PCCs to gain a predictive view of the likely loading of a PCE in the future and to allow a PCE to abandon processing of a received request.
对于PCE来说，了解pcc的活跃度以获得对未来可能的PCE加载的预测视图并允许PCE放弃对接收到的请求的处理也是重要的。
The PCECP MUST support indication of congestion state and rate limitation state, and MAY allow the operator to control such a function.
PCECP必须支持拥塞状态和速率限制状态的指示，并允许操作员控制此类功能。
This document is the result of the PCE Working Group PCECP requirements design team joint effort. In addition to the authors/editors listed in the "Authors' Addresses" section, the following are the design team members who contributed to the document:
本文件是PCE工作组PCECP需求设计团队共同努力的结果。除了“作者地址”部分中列出的作者/编辑外，以下是对本文件作出贡献的设计团队成员：
Alia K. Atlas Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA EMail: akatlas@alum.mit.edu
Alia K.Atlas Google Inc.1600圆形剧场公园路山景，加利福尼亚州94043美国电子邮件：akatlas@alum.mit.edu
Arthi Ayyangar Nuova Systems, 2600 San Tomas Expressway Santa Clara, CA 95051 EMail: arthi@nuovasystems.com
Arthi Ayangar Nuova Systems，加利福尼亚州圣克拉拉市圣托马斯高速公路2600号，邮编95051电子邮件：arthi@nuovasystems.com
Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 USA EMail: nabil.bitar@verizon.com
Nabil Bitar Verizon美国马萨诸塞州沃尔瑟姆Sylvan路40号02145电子邮件：Nabil。bitar@verizon.com
Igor Bryskin Independent Consultant EMail: i_bryskin@yahoo.com
Igor Bryskin独立顾问电子邮件：i_bryskin@yahoo.com
Dean Cheng Cisco Systems, Inc. 3700 Cisco Way San Jose CA 95134 USA Phone: 408 527 0677 EMail: dcheng@cisco.com
Dean Cheng Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科路3700号电话：408 527 0677电子邮件：dcheng@cisco.com
Durga Gangisetti MCI EMail: durga.gangisetti@mci.com
Durga Gangisetti MCI电子邮件：Durga。gangisetti@mci.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: 3-6678-3103 EMail: ke-kumaki@kddi.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi，Chiyoda ku，Tokyo 102-8460，日本电话：3-6678-3103电子邮件：ke-kumaki@kddi.com
Eiji Oki NTT Midori-cho 3-9-11 Musashino-shi, Tokyo 180-8585, JAPAN EMail: oki.eiji@lab.ntt.co.jp
日本东京武藏野史3-9-11，180-8585，邮编：Oki。eiji@lab.ntt.co.jp
Raymond Zhang BT INFONET Services Corporation 2160 E. Grand Ave. El Segundo, CA 90245 USA EMail: Raymond_zhang@bt.infonet.com
雷蒙德·张英国电信信息网服务公司美国加利福尼亚州埃尔塞贡多大道东2160号90245电子邮件：雷蒙德_zhang@bt.infonet.com
The authors would like to extend their warmest thanks to (in alphabetical order) Lou Berger, Ross Callon, Adrian Farrel, Thomas Morin, Dimitri Papadimitriou, Robert Sparks, and J.P. Vasseur for their review and suggestions.
作者谨向Lou Berger、Ross Callon、Adrian Farrel、Thomas Morin、Dimitri Papadimitriou、Robert Sparks和J.P.Vasseur（按字母顺序）表示最热烈的感谢，感谢他们的评论和建议。
[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月。
[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月。
[METRIC] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 2004.
[度量]Le Faucheur，F.，Uppili，R.，Vedrene，A.，Merckx，P.，和T.Telkamp，“内部网关协议（IGP）度量作为第二个MPLS流量工程（TE）度量的使用”，BCP 87，RFC 3785，2004年5月。
[PCE-DISC-REQ] Le Roux, J.L., et al., "Requirements for Path Computation Element (PCE) Discovery", Work in Progress.
[PCE-DISC-REQ]Le Roux，J.L.等，“路径计算元素（PCE）发现的要求”，正在进行的工作。
[PCECP-INTER-AREA] Le Roux, J.L., et al., "PCE Communication Protocol (PCECP) specific requirements for Inter-Area (G)MPLS Traffic Engineering", Work in Progress.
[PCECP-区域间]Le Roux，J.L.等，“区域间（G）MPLS流量工程的PCE通信协议（PCECP）特定要求”，正在进行的工作。
[PCECP-INTER-LAYER] Oki, E., et al., "PCC-PCE Communication Requirements for Inter-Layer Traffic Engineering", Work in Progress.
[PCECP-层间]Oki，E.等，“层间流量工程的PCC-PCE通信要求”，正在进行的工作。
[PCECP-INTER-AS] Bitar, N., Zhang, R., Kumaki, K., "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", Work in Progress.
[PCECP-INTER-AS]Bitar，N.，Zhang，R.，Kumaki，K.，“路径计算元素通信协议（PCECP）的INTER-AS要求”，正在进行中。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3127] Mitton, D., St.Johns, M., Barkley, S., Nelson, D., Patil, B., Stevens, M., and B. Wolff, "Authentication, Authorization, and Accounting: Protocol Evaluation", RFC 3127, June 2001.
[RFC3127]密顿、圣约翰、巴克利、纳尔逊、帕蒂尔、史蒂文斯和沃尔夫，“认证、授权和会计：协议评估”，RFC 3127，2001年6月。
Authors' Addresses
作者地址
Jerry Ash (Editor) AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA
Jerry Ash（编辑）美国电话电报公司MT D5-2A01室，地址：美国新泽西州劳雷尔大道中城200号，邮编：07748
Phone: (732)-420-4578 EMail: gash@att.com
电话：（732）-420-4578电子邮件：gash@att.com
Jean-Louis Le Roux (Editor) France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, FRANCE
Jean-Louis Le Roux（编辑）法国电信2号，Pierre Marzin大街22307号，法国拉尼翁塞德斯
EMail: jeanlouis.leroux@orange-ft.com
EMail: jeanlouis.leroux@orange-ft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。