Network Working Group JL. Le Roux
Request for Comments: 5541 France Telecom
Category: Standards Track JP. Vasseur
Cisco System Inc.
Y. Lee
Huawei
June 2009
Network Working Group JL. Le Roux
Request for Comments: 5541 France Telecom
Category: Standards Track JP. Vasseur
Cisco System Inc.
Y. Lee
Huawei
June 2009
Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)
路径计算元素通信协议（PCEP）中目标函数的编码
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions (e.g., minimum cost path, widest path, etc.).
多协议标签交换（MPLS）和广义MPLS（GMPLS）网络中一个或一组流量工程标签交换路径（TE LSP）的计算受一组或多个特定优化标准的约束，称为目标函数（例如，最小成本路径、最宽路径等）。
In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a path to be computed for one or more TE LSPs according to a specific objective function. Thus, the PCC needs to instruct the PCE to use the correct objective function. Furthermore, it is possible that not all PCEs support the same set of objective functions; therefore, it is useful for the PCC to be able to automatically discover the set of objective functions supported by each PCE.
在路径计算元素（PCE）架构中，路径计算客户端（PCC）可能希望根据特定目标函数为一个或多个TE lsp计算路径。因此，PCC需要指示PCE使用正确的目标函数。此外，可能并非所有PCE都支持同一组目标函数；因此，PCC能够自动发现每个PCE支持的目标函数集是有用的。
This document defines extensions to the PCE communication Protocol (PCEP) to allow a PCE to indicate the set of objective functions it supports. Extensions are also defined so that a PCC can indicate in a path computation request the required objective function, and a PCE can report in a path computation reply the objective function that was used for path computation.
本文件定义了PCE通信协议（PCEP）的扩展，以允许PCE指示其支持的目标函数集。还定义了扩展，以便PCC可以在路径计算请求中指示所需的目标函数，并且PCE可以在路径计算回复中报告用于路径计算的目标函数。
This document defines objective function code types for six objective functions previously listed in the PCE requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests.
本文件定义了先前在PCE需求工作中列出的六个目标函数的目标函数代码类型，并提供了适用于一组同步请求的四个新度量类型的定义。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................5
1.2. Terminology ................................................5
1.3. Message Formats ............................................6
2. Discovery of PCE Objective Functions ............................6
2.1. OF-List TLV ................................................6
2.2. Elements of Procedure ......................................7
3. Objective Function in PCEP Path Computation Request and Reply
Messages ........................................................7
3.1. OF Object ..................................................7
3.1.1. Elements of Procedure ...............................8
3.2. Carrying The OF Object In a PCEP Message ...................9
3.3. New RP Object Flag ........................................12
3.3.1. Elements Of Procedure ..............................12
4. Objective Functions Definition .................................13
5. New Metric Types ...............................................14
6. IANA Considerations ............................................15
6.1. PCE Objective Function Sub-Registry .......................15
6.2. PCEP Code Points ..........................................16
6.2.1. OF Object ..........................................16
6.2.2. OF-List TLV ........................................16
6.2.3. PCEP Error Values ..................................16
6.2.4. RP Object Flag .....................................17
6.2.5. Metric Types .......................................17
7. Security Considerations ........................................17
8. Manageability Considerations ...................................18
8.1. Control of Function and Policy ............................18
8.2. Information and Data Models ...............................18
8.3. Liveness Detection and Monitoring .........................18
8.4. Verify Correct Operations .................................18
8.5. Requirements On Other Protocols ...........................19
8.6. Impact On Network Operations ..............................19
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. RBNF Code Fragments ...................................21
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................5
1.2. Terminology ................................................5
1.3. Message Formats ............................................6
2. Discovery of PCE Objective Functions ............................6
2.1. OF-List TLV ................................................6
2.2. Elements of Procedure ......................................7
3. Objective Function in PCEP Path Computation Request and Reply
Messages ........................................................7
3.1. OF Object ..................................................7
3.1.1. Elements of Procedure ...............................8
3.2. Carrying The OF Object In a PCEP Message ...................9
3.3. New RP Object Flag ........................................12
3.3.1. Elements Of Procedure ..............................12
4. Objective Functions Definition .................................13
5. New Metric Types ...............................................14
6. IANA Considerations ............................................15
6.1. PCE Objective Function Sub-Registry .......................15
6.2. PCEP Code Points ..........................................16
6.2.1. OF Object ..........................................16
6.2.2. OF-List TLV ........................................16
6.2.3. PCEP Error Values ..................................16
6.2.4. RP Object Flag .....................................17
6.2.5. Metric Types .......................................17
7. Security Considerations ........................................17
8. Manageability Considerations ...................................18
8.1. Control of Function and Policy ............................18
8.2. Information and Data Models ...............................18
8.3. Liveness Detection and Monitoring .........................18
8.4. Verify Correct Operations .................................18
8.5. Requirements On Other Protocols ...........................19
8.6. Impact On Network Operations ..............................19
9. Acknowledgments ................................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. RBNF Code Fragments ...................................21
The Path Computation Element-based network architecture [RFC4655] defines a Path Computation Element (PCE) as an entity capable of computing the paths of Traffic Engineered Label Switched Paths (TE LSPs) based on a network graph and of applying computational constraints. A PCE services path computation requests that are sent by Path Computation Clients (PCC).
基于路径计算元素的网络体系结构[RFC4655]将路径计算元素（PCE）定义为能够基于网络图计算流量工程标签交换路径（TE LSP）的路径并应用计算约束的实体。PCE为路径计算客户端（PCC）发送的路径计算请求提供服务。
The PCE communication Protocol (PCEP), defined in [RFC5440], allows for communication between a PCC and a PCE or between two PCEs, in compliance with requirements and guidelines set forth in [RFC4657]. Such interactions include path computation requests and path computation replies.
[RFC5440]中定义的PCE通信协议（PCEP）允许PCC和PCE之间或两个PCE之间的通信，符合[RFC4657]中规定的要求和指南。这种交互包括路径计算请求和路径计算回复。
The computation of one or a set of TE LSPs is subject to a set of one or more optimization criteria, called an objective function. An objective function is used by the PCE when it computes a path or a set of paths in order to select the "best" candidate paths. There is a variety of objective functions: an objective function could apply either to a set of non-synchronized path computation requests, or to a set of synchronized path computation requests. In the former case, the objective function refers to an individual path computation request (e.g., computation of the shortest constrained path where the metric is the IGP metric, computation of the least loaded constrained path, etc.). Conversely, in the latter case, the objective function refers to a set of path computation requests the computation of which is synchronized (e.g., minimize the aggregate bandwidth consumption of all LSPs, minimize the sum of the delays for two diverse paths or of the delta between those delays, etc.). Moreover, some objective functions relate to the optimization of a single metric and others to the optimization of a set of metrics (organized in a hierarchical manner, using a weighted function, etc.).
一个或一组TE LSP的计算受制于一组或多个优化标准，称为目标函数。PCE在计算一条或一组路径以选择“最佳”候选路径时使用目标函数。目标函数有多种：目标函数可以应用于一组非同步路径计算请求，也可以应用于一组同步路径计算请求。在前一种情况下，目标函数指单个路径计算请求（例如，计算最短约束路径，其中度量是IGP度量，计算最小负载约束路径等）。相反，在后一种情况下，目标函数指的是一组路径计算请求，其计算是同步的（例如，最小化所有lsp的总带宽消耗，最小化两条不同路径的延迟之和或这些延迟之间的增量，等等）。此外，一些目标函数与单个度量的优化有关，而另一些目标函数与一组度量的优化有关（以分层方式组织，使用加权函数等）。
As spelled out in [RFC4674], it may be useful for a PCC to discover the set of objective functions supported by a PCE. Furthermore, [RFC4657] requires the ability for a PCC to indicate in a path computation request a required/desired objective function, as well as optional function parameters.
如[RFC4674]所述，PCC发现PCE支持的目标函数集可能很有用。此外，[RFC4657]要求PCC能够在路径计算请求中指示所需/期望的目标函数以及可选函数参数。
For these purposes, this document extends the PCE communication Protocol (PCEP). It defines PCEP extensions that allow a PCE to advertise a list of supported objective functions, as well as extensions to carry the objective function in PCEP request and reply messages. It complements the PCEP base specification [RFC5440].
为此，本文件扩展了PCE通信协议（PCEP）。它定义了允许PCE公布支持的目标函数列表的PCEP扩展，以及在PCEP请求和回复消息中携带目标函数的扩展。它补充了PCEP基本规范[RFC5440]。
Note that OSPF- and IS-IS-based PCE discovery mechanisms are defined in [RFC5088] and [RFC5089]. These mechanisms are dedicated to the discovery of a few generic parameters, while more detailed PCE parameters should be discovered using the PCE communication Protocol. Objective functions are in this second category; thus, the objective function discovery procedure is handled by PCEP.
请注意，[RFC5088]和[RFC5089]中定义了基于OSPF和IS的PCE发现机制。这些机制专用于发现一些通用参数，而更详细的PCE参数应使用PCE通信协议来发现。目标函数属于第二类；因此，目标函数发现过程由PCEP处理。
A new PCEP TLV, named the OF-List TLV, is defined in Section 2. The OF-List TLV is carried in the PCEP OPEN object and allows a PCE to list, during PCEP session-setup phase, the objective functions that it supports.
第2节定义了一个新的PCEP TLV，名为TLV列表。TLV列表包含在PCEP OPEN对象中，允许PCE在PCEP会话设置阶段列出其支持的目标函数。
A new PCEP object, the OF object, is defined in Section 3. The OF object is carried within a PCReq (Path Computation Request) message to indicate the required/desired objective function to be applied by a PCE, or in a PCRep (Path Computation Reply) message to indicate the objective function that was used for path computation.
第3节定义了一个新的PCEP对象，即OF对象。在PCReq（路径计算请求）消息中携带OF对象以指示PCE应用的所需/期望目标函数，或在PCRep（路径计算应答）消息中携带OF对象以指示用于路径计算的目标函数。
Six mandatory objective functions that must be supported by PCEP are listed in [RFC4657]. This document provides a definition of these six mandatory objective functions. Additional objective functions may be defined in other documents. Note that additional objective functions are defined for the PCE Global Concurrent Optimization (GCO) application, in [PCE-GCO].
[RFC4657]中列出了PCEP必须支持的六个强制性目标函数。本文件提供了这六个强制性目标函数的定义。其他目标函数可在其他文件中定义。请注意，[PCE-GCO]中为PCE全局并行优化（GCO）应用程序定义了其他目标函数。
This document also provides the definition of four new metric types that apply to a set of synchronized requests.
本文档还提供了适用于一组同步请求的四种新度量类型的定义。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
LSR: Label Switching Router.
标签交换路由器。
OF: Objective Function. A set of one or more optimization criteria used for the computation of a single path (e.g., path cost minimization) or for the synchronized computation of a set of paths (e.g., aggregate bandwidth consumption minimization, etc.).
目标函数。用于计算单个路径（例如，路径成本最小化）或用于同步计算一组路径（例如，总带宽消耗最小化等）的一组或多个优化标准。
PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
路径计算客户端。任何请求由路径计算元素执行的路径计算的客户端应用程序。
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 of applying computational constraints.
PCE：路径计算元素。能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
PCEP: Path Computation Element communication Protocol.
PCEP：路径计算元素通信协议。
TE LSP: Traffic Engineered Label Switched Path.
TE LSP：流量工程标签交换路径。
Message formats in this document are expressed using Reduced BNF as used in [RFC5440] and defined in [RFC5511].
本文件中的消息格式使用[RFC5440]中使用并在[RFC5511]中定义的简化BNF表示。
This section defines PCEP extensions (see [RFC5440]) so as to support the advertisement of the objective functions supported by a PCE.
本节定义了PCEP扩展（参见[RFC5440]），以支持PCE支持的目标函数的公布。
A new PCEP OF-List (Objective Function list) TLV is defined. The PCEP OF-List TLV is carried within an OPEN object. This way, during PCEP session-setup phase, a PCE can advertise to a PCEP peer the list of objective functions it supports.
定义了一种新的列表（目标函数列表）TLV的PCEP。列表TLV的PCEP携带在开放对象中。这样，在PCEP会话设置阶段，PCE可以向PCEP对等方公布其支持的目标函数列表。
The PCEP OF-List TLV is optional. It MAY be carried within an OPEN object sent by a PCE in an Open message to a PCEP peer so as to indicate the list of supported objective functions.
列表TLV的PCEP是可选的。它可以携带在由PCE在开放消息中发送给PCEP对等方的开放对象中，以指示支持的目标函数的列表。
The OF-List TLV format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the TLV length, and a Value field. The Length field defines the length of the value portion in octets. The TLV is padded to 4-octet alignment, and padding is not included in the Length field (e.g., a 3-octet value would have a length of three, but the total size of the TLV would be eight octets).
TLV格式列表符合[RFC5440]中定义的PCEP TLV格式。也就是说，TLV由类型的2个八位字节、指定TLV长度的2个八位字节和一个值字段组成。长度字段定义值部分的长度（以八位字节为单位）。TLV填充为4-八位字节对齐，填充不包括在长度字段中（例如，3-八位字节值的长度为3，但TLV的总大小为8个八位字节）。
The PCEP OF-List TLV has the following format:
TLV列表的PCEP具有以下格式：
TYPE: 4 LENGTH: N * 2 (where N is the number of objective functions) VALUE: list of 2-byte objective function code points, identifying the objective functions supported by the sender of the Open message.
类型：4长度：N*2（其中N为目标函数数）值：2字节目标函数代码点列表，标识开放消息发送方支持的目标函数。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #1 | OF Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #1 | OF Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code #N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OF Code (2 bytes): Objective Function code point identifier. IANA manages the "PCE Objective Function" code point registry (see Section 6).
代码类型（2字节）：目标函数代码点标识符。IANA管理“PCE目标函数”代码点注册表（见第6节）。
A PCE MAY include an OF-List TLV within an OPEN object in an Open message sent to a PCEP peer in order to advertise a set of one or more objective functions. The OF-List TLV MUST NOT appear more than once in an OPEN object. If it appears more than once, the PCEP session MUST be rejected with error type 1 and error value 1 (PCEP session establishment failure / Reception of an invalid Open message). The absence of the OF-List TLV in an OPEN object MUST be interpreted as an absence of information on the list of supported objective functions by the PCE.
PCE可以在发送给PCEP对等方的开放消息中包括开放对象内的TLV列表，以便公布一组或多个目标函数。TLV列表在打开的对象中不得出现多次。如果出现多次，则必须拒绝PCEP会话，错误类型为1，错误值为1（PCEP会话建立失败/接收到无效的打开消息）。开放对象中TLV列表的缺失必须解释为PCE支持的目标函数列表信息的缺失。
As specified in [RFC5440], a PCEP peer that does not recognize the OF-List TLV will silently ignore it.
如[RFC5440]中所述，不识别TLV列表的PCEP对等方将自动忽略该列表。
3. Objective Function in PCEP Path Computation Request and Reply Messages
3. PCEP路径计算请求和应答消息中的目标函数
This section defines PCEP extensions [RFC5440] so as to support the communication of objective functions in PCEP path computation request and reply messages. A new PCEP OF (Objective Function) object is defined, to be carried within a PCReq message in order for the PCC to indicate the required/desired objective function.
本节定义了PCEP扩展[RFC5440]，以支持PCEP路径计算请求和回复消息中目标函数的通信。定义了一个新的PCEP OF（目标函数）对象，该对象将在PCReq消息中携带，以便PCC指示所需/期望的目标函数。
The PCEP OF object may also be carried within a PCRep message in order for the PCE to indicate the objective function that was used by the PCE.
对象的PCEP也可以在PCRep消息中携带，以便PCE指示PCE使用的目标函数。
A new flag is defined in the RP (Request Parameters) object. The flag is used in a PCReq message to indicate that the PCE MUST include an OF object in the PCRep message to indicate the objective function that was used during path computation.
RP（请求参数）对象中定义了一个新标志。该标志用于PCReq消息中，以指示PCE必须在PCRep消息中包含OF对象，以指示路径计算期间使用的目标函数。
Also, new PCEP error types and values are defined.
此外，还定义了新的PCEP错误类型和值。
The PCEP OF (Objective Function) object is optional. It MAY be carried within a PCReq message so as to indicate the desired/required objective function to be applied by the PCE during path computation or within a PCRep message so as to indicate the objective function that was used by the PCE during path computation.
（目标函数）对象的PCEP是可选的。它可以在PCReq消息中携带以指示PCE在路径计算期间应用的期望/所需目标函数，或者在PCRep消息中携带以指示PCE在路径计算期间使用的目标函数。
The OF object format is compliant with the PCEP object format defined in [RFC5440].
对象格式的格式符合[RFC5440]中定义的PCEP对象格式。
The OF Object-Class is 21. The OF Object-Type is 1.
对象类的名称为21。对象类型的值为1。
The format of the OF object body is:
对象体的格式为：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OF Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OF Code (2 bytes): The identifier of the objective function. IANA manages the "PCE Objective Function" code point registry (see Section 6).
代码类型（2字节）：目标函数的标识符。IANA管理“PCE目标函数”代码点注册表（见第6节）。
Reserved (2 bytes): This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（2字节）：此字段在传输时必须设置为零，在接收时必须忽略。
Optional TLVs may be defined in the future so as to encode objective function parameters.
将来可能会定义可选的TLV，以便对目标函数参数进行编码。
To request the use of a specific objective function by the PCE, a PCC includes an OF object in the PCReq message.
为了请求PCE使用特定目标函数，PCC在PCReq消息中包括of对象。
[RFC5440] specifies a bit flag, referred to as the P bit, carried in the common PCEP object header. The P bit is set by a PCC to mandate that a PCE must take the information carried in the object into account during the path computation.
[RFC5440]指定公共PCEP对象头中携带的位标志，称为P位。P位由PCC设置，以强制PCE在路径计算期间必须考虑对象中携带的信息。
If the P bit is set in the OF object, the objective function is mandatory (required objective function) and the PCE MUST use the objective function during path computation. If the P bit is clear in the OF object, the objective function is optional (desired objective function) and the PCE SHOULD apply the function if it is supported but MAY choose to apply a different objective function, according to local capabilities and policies.
如果在OF对象中设置了P位，则目标函数是必需的（必需的目标函数），并且PCE必须在路径计算期间使用目标函数。如果对象中的P位是明确的，则目标函数是可选的（期望的目标函数），PCE应应用该函数（如果支持），但可以根据本地能力和政策选择应用不同的目标函数。
On receipt of a PCReq message with an OF object, a PCE MUST proceed as follows:
在收到带有of对象的PCReq消息时，PCE必须按照以下步骤进行：
- If the OF object is unknown/unsupported, the PCE MUST follow procedures defined in [RFC5440]. That is, if the P bit is set, the PCE sends a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 1 or 2 (unknown / unsupported object class / object type), and the related path computation request MUST be discarded. If the P bit is cleared, the PCE is free to ignore the object.
- 如果对象的类型未知/不受支持，则PCE必须遵循[RFC5440]中定义的程序。也就是说，如果设置了P位，PCE将发送错误类型为3或4（未知/不支持的对象）和错误值1或2（未知/不支持的对象类/对象类型）的PCErr消息，并且必须放弃相关的路径计算请求。如果清除P位，则PCE可自由忽略该对象。
- If the objective function is unknown/unsupported and the P bit is set, the PCE MUST send a PCErr message with error type 3 or 4 (Unknown / Not supported object) and error value 4 (Unrecognized/Unsupported parameter), and the related path computation request MUST be discarded.
- 如果目标函数未知/不受支持且设置了P位，则PCE必须发送错误类型为3或4（未知/不受支持的对象）和错误值4（无法识别/不受支持的参数）的PCErr消息，并且必须放弃相关的路径计算请求。
- If the objective function is unknown/unsupported and the P bit is cleared, the PCE SHOULD apply another (default) objective function.
- 如果目标函数未知/不受支持且P位已清除，则PCE应应用另一个（默认）目标函数。
- If the objective function is supported but policy does not permit applying it and if the P bit is set, the PCE MUST send a PCErr message with the PCEP error type "policy-violation" (type 5) and a new error value, "objective function not allowed", which is defined in this document.
- 如果支持目标函数，但策略不允许应用该函数，并且设置了P位，则PCE必须发送一条PCErr消息，其中PCEP错误类型为“策略冲突”（类型5）和一个新的错误值“目标函数不允许”，该错误值在本文档中定义。
- If the objective function is supported but policy does not allow applying it and if the P bit is cleared, the PCE SHOULD apply another (default) objective function.
- 如果支持目标函数，但策略不允许应用该函数，并且如果清除了P位，则PCE应应用另一个（默认）目标函数。
- If the objective function is supported and policy allows applying it and if the P bit is set, the PCE MUST apply the requested objective function. Otherwise, if the P bit is cleared, the PCE is free to apply any other objective function.
- 如果支持目标函数且策略允许应用该函数，并且如果设置了P位，则PCE必须应用请求的目标函数。否则，如果P位被清除，PCE可以自由应用任何其他目标函数。
The default objective function may be locally configured.
默认目标函数可以在本地配置。
The OF object MAY be carried within a PCReq message. If an objective function is to be applied to a set of synchronized path computation requests, the OF object MUST be carried just after the corresponding SVEC (Synchronization VECtor) object and MUST NOT be repeated for each elementary request.
可以在PCReq消息中携带对象的名称。如果要将目标函数应用于一组同步路径计算请求，则必须在对应的SVEC（同步向量）对象之后携带对象的值，并且不得对每个基本请求重复该值。
Similarly, if a metric is to be applied to a set of synchronized requests, the METRIC object MUST follow the SVEC object and MUST NOT be repeated for each elementary request. Note that metrics applied to a set of synchronized requests are defined in Section 5.
类似地，如果要将度量应用于一组同步请求，则度量对象必须跟随SVEC对象，并且不得对每个基本请求重复。注意，应用于一组同步请求的度量在第5节中定义。
An OF object specifying an objective function that applies to an individual path computation request (non-synchronized case) MUST follow the RP object for which it applies.
指定应用于单个路径计算请求（非同步情况）的目标函数的对象类型必须遵循其应用的RP对象。
The format of the PCReq message is updated as follows. Please see Appendix A for a full set of RBNF fragments defined in this document and the necessary code license.
PCReq消息的格式更新如下。有关本文档中定义的全套RBNF片段和必要的代码许可证，请参见附录A。
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
and where:
地点：
<metric-list> ::= <METRIC>[<metric-list>]
<metric-list> ::= <METRIC>[<metric-list>]
The OF object MAY be carried within a PCRep message to indicate the objective function used by the PCE during path computation.
可以在PCRep消息中携带对象的位置，以指示PCE在路径计算期间使用的目标函数。
When the PCE wants to indicate to the PCC the objective function that was used for the synchronized computation of a set of paths, the PCRep message MUST include the corresponding SVEC object directly followed by the OF object, which MUST NOT be repeated for each elementary request. If a metric is applicable to the set of paths, the METRIC object MUST directly follow the SVEC object and MUST NOT be repeated for each elementary request.
当PCE希望向PCC指示用于一组路径的同步计算的目标函数时，PCRep消息必须包括对应的SVEC对象，后面紧跟of对象，对于每个基本请求，不得重复该对象。如果度量适用于路径集，则度量对象必须直接跟随SVEC对象，并且不得对每个基本请求重复。
An OF object specifying an objective function used for an individual path computation (non-synchronized case) MUST follow the RP object for which it applies.
指定用于单个路径计算（非同步情况）的目标函数的对象类型必须遵循其应用的RP对象。
The format of the PCRep message is updated as follows. Please see Appendix A for a full set of RBNF fragments defined in this document and the necessary code license.
PCRep消息的格式更新如下。有关本文档中定义的全套RBNF片段和必要的代码许可证，请参见附录A。
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
where:
哪里：
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<response-list> ::= <response> [<response-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
<path> ::= <ERO>
<attribute-list>
and where:
地点：
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list> ::= <METRIC> [<metric-list>]
<metric-list> ::= <METRIC> [<metric-list>]
Note: The OF object MAY be associated to a negative reply, i.e., a reply with a NO-PATH object.
注意：OF对象可能与否定回复相关联，即带有无路径对象的回复。
In some cases, where no objective function is specified in the request or an optional objective function is desired (P flag cleared in the OF object common header) but the PCE does not follow the request, the PCC may desire to know the objective function that was used by the PCE during path computation. To that end, a new flag is defined in the RP object, named the OF flag, allowing a PCC to request for the inclusion in the path computation reply of the objective function that was used by the PCE during path computation.
在某些情况下，如果在请求中未指定目标函数，或者需要可选目标函数（在OF object common报头中清除P标志），但是PCE不遵循请求，则PCC可能希望知道PCE在路径计算期间使用的目标函数。为此，在RP对象中定义了一个名为OF标志的新标志，允许PCC请求在路径计算应答中包含PCE在路径计算期间使用的目标函数。
The following new bit flag of the RP object is defined:
定义了RP对象的以下新位标志：
The Supply OF on response flag (bit number 24). When set in a PCReq message, this indicates that the PCE MUST provide the applied objective function (should a path satisfying the constraints be found) in the PCRep message. When set in a PCRep message, this indicates that the objective function that was used during path computation is included.
提供on响应标志（位号24）。当在PCReq消息中设置时，这表示PCE必须在PCRep消息中提供应用的目标函数（如果找到满足约束的路径）。当在PCRep消息中设置时，这表示包含路径计算期间使用的目标函数。
If the PCC wants to know the objective function used by the PCE during path computation for a given request, it sets the OF flag in the RP object.
如果PCC希望知道PCE在给定请求的路径计算期间使用的目标函数，它将在RP对象中设置OF标志。
On receipt of a PCReq message with the OF flag in the RP object set, the PCE proceeds as follows:
在接收到RP对象集中带有of标志的PCReq消息时，PCE按如下方式进行：
- If policy permits, it MUST include in the PCRep message an OF object indicating the objective function it used during path computation.
- 如果策略允许，它必须在PCRep消息中包含一个对象，指示它在路径计算期间使用的目标函数。
- If policy does not permit, it MUST send a PCErr message with the PCEP error code "policy-violation" (type 5) and a new error value, "objective function indication not allowed", which is defined in this document.
- 如果策略不允许，则必须发送一条PCErr消息，其中包含PCEP错误代码“策略违规”（类型5）和新的错误值“目标函数指示不允许”，该错误值在本文档中定义。
Note that a legacy PCE might not recognize the OF flag in the RP object. According to the definition of the Flags field for the RP object (Section 7.4.1 of [RFC5440]), the legacy PCE will ignore the unknown flag, resulting in it sending a PCRep that does not contain an OF object. In this case, the PCC's behavior is an implementation choice. The PCC might:
请注意，传统PCE可能无法识别RP对象中的OF标志。根据RP对象标志字段的定义（RFC5440的第7.4.1节），传统PCE将忽略未知标志，导致其发送不包含of对象的PCRep。在这种情况下，PCC的行为是一种实现选择。委员会可：
- Discard the PCRep because it really wanted the OF object returned.
- 丢弃PCRep，因为它确实希望返回对象的名称。
- Accept the PCRep without the knowledge of the OF that was applied.
- 接受PCRep时，不知道所应用的。
Note also that these procedures can give rise to the situation where a PCC receives a PCRep that contains an OF object with an objective function identifier that the PCC does not recognize. In this situation, the PCC behavior is dependent on implementation and configuration. The PCC could choose any of the following (or some other action):
还要注意，这些过程可能会导致PCC接收到一个PCRep，该PCRep包含一个目标函数标识符为PCC无法识别的OF对象。在这种情况下，PCC行为取决于实现和配置。PCC可以选择以下任何一项（或其他行动）：
- Ignore the OF object and use the computed path.
- 忽略对象的路径，并使用计算的路径。
- Add the objective function to its view of the PCE's repertoire for inclusion in future computation requests.
- 将目标函数添加到其对PCE指令集的视图中，以便包含在未来的计算请求中。
- Discard the PCRep (i.e., the computed path) and send a PCReq to another PCE.
- 丢弃PCRep（即计算路径）并向另一个PCE发送PCReq。
- Discard the PCRep (i.e., the computed path) and send another PCReq to the same PCE explicitly requiring the use of some other objective function (i.e., by setting the P bit in the OF object).
- 丢弃PCRep（即，计算路径），并向同一PCE发送另一个PCReq，该PCE明确要求使用其他目标函数（即，通过设置对象中的P位）。
Six objective functions that must be supported by PCEP are listed in [RFC4657]. Objective function codes have been assigned by IANA and are described below.
[RFC4657]中列出了PCEP必须支持的六个目标函数。IANA分配了目标功能代码，如下所述。
Objective functions are formulated using the following terminology:
目标函数使用以下术语制定：
- A network comprises a set of N links {Li, (i=1...N)}.
- 网络由一组N个链路{Li，（i=1…N）}组成。
- A path P is a list of K links {Lpi,(i=1...K)}.
- 路径P是K个链接的列表{Lpi，（i=1…K）}。
- Metric of link L is denoted M(L). This can be the IGP metric, the TE metric, or any other metric.
- 链路L的度量表示为M（L）。这可以是IGP度量、TE度量或任何其他度量。
- The cost of a path P is denoted C(P), where C(P) = sum {M(Lpi), (i=1...K)}.
- 路径P的代价表示为C（P），其中C（P）=和{M（Lpi），（i=1…K）}。
- Residual bandwidth on link L is denoted r(L).
- 链路L上的剩余带宽表示为r（L）。
- Maximum reservable bandwidth on link L is denoted R(L).
- 链路L上的最大可保留带宽表示为R（L）。
There are three objective functions that apply to the computation of a single path:
有三个目标函数适用于单个路径的计算：
Objective Function Code: 1 Name: Minimum Cost Path (MCP) Description: Find a path P such that C(P) is minimized.
目标函数代码：1名称：最小成本路径（MCP）描述：找到一条路径P，使C（P）最小化。
Objective Function Code: 2 Name: Minimum Load Path (MLP) Description: Find a path P such that ( Max {(R(Lpi) - r(Lpi)) / R(Lpi), i=1...K } ) is minimized.
目标函数代码：2名称：最小负载路径（MLP）说明：找到一条路径P，使（Max{（R（Lpi）-R（Lpi））/R（Lpi），i=1…K}）最小化。
Objective Function Code: 3 Name: Maximum residual Bandwidth Path (MBP) Description: Find a path P such that ( Min { r(Lpi), i=1...K } ) is maximized.
目标函数代码：3名称：最大剩余带宽路径（MBP）说明：查找路径P，使（Min{r（Lpi），i=1…K}）最大化。
There are three objective functions that apply to a set of path computation requests the computation of which is synchronized:
有三个目标函数适用于一组同步计算的路径计算请求：
Objective Function Code: 4 Name: Minimize aggregate Bandwidth Consumption (MBC) Description: Find a set of paths such that ( Sum {R(Li) - r(Li), i=1...N} ) is minimized.
目标函数代码：4名称：最小化聚合带宽消耗（MBC）描述：找到一组路径，使（Sum{R（Li）-R（Li），i=1…N}）最小化。
Objective Function Code: 5 Name: Minimize the Load of the most loaded Link (MLL) Description: Find a set of paths such that ( Max { (R(Li) - r(Li)) / R(Li), i=1...N}) is minimized.
目标函数代码：5名称：最小化最大负载链路（MLL）的负载描述：找到一组路径，使（Max{（R（Li）-R（Li））/R（Li），i=1…N}）最小化。
Objective Function Code: 6 Name: Minimize the Cumulative Cost of a set of paths (MCC) Description: Find a set of paths {P1...Pm} such that (Sum { C(Pi), i=1...m}) is minimized.
目标函数代码：6名称：最小化一组路径的累积成本（MCC）说明：找到一组路径{P1…Pm}，使（和{C（Pi），i=1…m}）最小化。
Other objective functions may be defined in separate documents.
其他目标函数可在单独的文件中定义。
Three metric types are defined in PCEP for the METRIC object: TE metric, IGP metric, and hop count. These metric types apply to an individual request. Here, we define four new metric types that apply to a set of synchronized requests:
PCEP中为度量对象定义了三种度量类型：TE度量、IGP度量和跃点计数。这些度量类型适用于单个请求。在这里，我们定义了四种适用于一组同步请求的新度量类型：
Type 4: Aggregate bandwidth consumption.
类型4：聚合带宽消耗。
Type 5: Load of the most loaded link.
类型5：负载最多的链路的负载。
Type 6: Cumulative IGP cost.
类型6：累计IGP成本。
Type 7: Cumulative TE cost.
类型7：累积TE成本。
These metrics may be used in a PCReq to indicate a bound (B bit set in the METRIC object) or to request the computation of a metric (C bit set in the METRIC object), or in a PCRep to indicate a computed metric.
这些度量可以在PCReq中用于指示界限（度量对象中设置的B位）或请求度量的计算（度量对象中设置的C位），或者在PCRep中用于指示计算的度量。
A METRIC object with one of these four types follows the SVEC object for which it applies.
具有这四种类型之一的度量对象遵循其应用的SVEC对象。
This document defines a 16-bit PCE objective function identifier to be carried within the PCEP OF object, and also defines the PCEP OF-List TLV.
本文件定义了一个16位PCE目标函数标识符，该标识符将携带在对象的PCEP中，并且还定义了列表TLV的PCEP。
IANA created and now manages the 16-bit "PCE Objective Function" code point registry, starting from 1 and continuing through 32767, as follows:
IANA创建并管理16位“PCE目标函数”代码点注册表，从1开始，一直到32767，如下所示：
- Objective Function code point value - Objective Function name - Defining RFC
- 目标函数代码点值-目标函数名称-定义RFC
The same registry is applicable to the OF object and the OF-List TLV that are defined in this document.
同一注册表适用于本文件中定义的对象和TLV列表。
The guidelines (using terms defined in [RFC5226]) for the assignment of objective function code point values are as follows:
分配目标函数代码点值的指南（使用[RFC5226]中定义的术语）如下所示：
- Function code value 0 is reserved.
- 保留功能代码值0。
- Function code values in the range 1-32767 are assigned as follows:
- 1-32767范围内的功能代码值分配如下：
o Function code values 1 through 1023 are assigned by IANA using the "IETF Review" policy.
o IANA使用“IETF审查”策略分配功能代码值1至1023。
o Function code values 1024 through 32767 are assigned by IANA, using the "First Come First Served" policy.
o IANA使用“先到先得”策略分配功能代码值1024到32767。
o Function code values in the range 32768-65535 are for "Private Use".
o 32768-65535范围内的功能代码值用于“私人使用”。
Six objective functions are defined in Section 4 of this document and have been assigned by IANA:
本文件第4节定义了六个目标函数，并由IANA分配：
Code Point Name Reference
-------------------------------------------------------
1 MCP RFC 5541
2 MLP RFC 5541
3 MBP RFC 5541
4 MBC RFC 5541
5 MLL RFC 5541
6 MCC RFC 5541
Code Point Name Reference
-------------------------------------------------------
1 MCP RFC 5541
2 MLP RFC 5541
3 MBP RFC 5541
4 MBC RFC 5541
5 MLL RFC 5541
6 MCC RFC 5541
IANA manages the PCEP Objects code point registry (see [RFC5440]). This is maintained as the "PCEP Objects" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANA管理PCEP对象代码点注册表（请参见[RFC5440]）。它作为“路径计算元素协议（PCEP）编号”注册表的“PCEP对象”子注册表进行维护。
This document defines a new PCEP object, the OF object, to be carried in PCReq and PCRep messages. IANA has made the following allocation:
本文档定义了一个新的PCEP对象，即OF对象，该对象将在PCReq和PCRep消息中携带。IANA已作出以下分配：
Object Name Object Name Reference
Class Type
------------------------------------------------------------
21 OF 1 Objective Function RFC 5541
Object Name Object Name Reference
Class Type
------------------------------------------------------------
21 OF 1 Objective Function RFC 5541
IANA manages the PCEP TLV code point registry (see [RFC5440]). This is maintained as the "PCEP TLV Type Indicators" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANA管理PCEP TLV代码点注册表（请参阅[RFC5440]）。它作为“路径计算元素协议（PCEP）编号”注册表的“PCEP TLV类型指示器”子注册表进行维护。
This document defines a new PCEP TLV, the OF-List TLV, to be carried in the OPEN object. IANA has made the following allocation:
本文件定义了一个新的PCEP TLV，即开放对象中要携带的TLV列表。IANA已作出以下分配：
Type TLV name References
-----------------------------------------------
4 OF-List RFC 5541
Type TLV name References
-----------------------------------------------
4 OF-List RFC 5541
IANA maintains a registry of Error-types and Error-values for use in PCEP messages. This is maintained as the "PCEP-ERROR Object Error Types and Values" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANA维护用于PCEP消息的错误类型和错误值的注册表。它作为“路径计算元素协议（PCEP）编号”注册表的“PCEP-ERROR对象错误类型和值”子注册表进行维护。
Two new Error-values are defined for the Error-type "policy violation" (type 5):
为错误类型“策略冲突”（类型5）定义了两个新的错误值：
Error-type Meaning and error values Reference
------------------------------------------------------------------
5 Policy violation
Error-type Meaning and error values Reference
------------------------------------------------------------------
5 Policy violation
Error-value=3: objective function not RFC 5541 allowed (request rejected)
错误值=3：不允许目标函数RFC 5541（请求被拒绝）
Error-value=4: OF bit of the RP object RFC 5541 set (request rejected)
错误值=4:RP对象RFC 5541集合的位（请求被拒绝）
A new flag of the RP object (specified in [RFC5440]) is defined in this document. IANA maintains a registry of RP object flags in the "RP Object Flag Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
本文件中定义了RP对象的新标志（在[RFC5440]中指定）。IANA在“路径计算元素协议（PCEP）编号”注册表的“RP对象标志字段”子注册表中维护RP对象标志的注册表。
IANA has made the following allocation:
IANA已作出以下分配：
Bit Description Reference
-------------------------------------------
24 Supply OF on response RFC 5541
Bit Description Reference
-------------------------------------------
24 Supply OF on response RFC 5541
Four new metric types are defined in this document for the METRIC object (specified in [RFC5440]). IANA maintains a registry of metric types in the "METRIC Object T Field" sub-registry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
本文件为度量对象定义了四种新的度量类型（在[RFC5440]中指定）。IANA在“路径计算元素协议（PCEP）编号”注册表的“metric Object T Field”子注册表中维护度量类型注册表。
IANA has made the following allocations:
IANA进行了以下分配：
- Type 4: Aggregate bandwidth consumption - Type 5: Load of the most loaded link - Type 6: Cumulative IGP cost - Type 7: Cumulative TE cost
- 类型4：聚合带宽消耗-类型5：负载最多的链路的负载-类型6：累积IGP成本-类型7：累积TE成本
PCEP security mechanisms are described in [RFC5440] and are used to secure entire PCEP messages. Nothing in this document changes the message flows or introduces any new messages, so the security mechanisms set out in [RFC5440] continue to be applicable.
[RFC5440]中描述了PCEP安全机制，用于保护整个PCEP消息。本文档中的任何内容都不会更改消息流或引入任何新消息，因此[RFC5440]中规定的安全机制仍然适用。
This document introduces a single new object that may optionally be carried on PCEP messages and will be automatically secured using the mechanisms described in [RFC5440].
本文档介绍了一个新对象，该对象可以选择性地携带在PCEP消息中，并将使用[RFC5440]中描述的机制自动保护。
If a PCEP message is vulnerable to attack (for example, because the security mechanisms are not used), then the OF object could be used as part of an attack; however, it is likely that other objects will provide far more significant ways of attacking a PCE or PCC in this case.
如果PCEP消息易受攻击（例如，因为未使用安全机制），则对象的类型可以用作攻击的一部分；然而，在这种情况下，其他对象可能会提供更重要的方法来攻击PCE或PCC。
It MUST be possible to configure the activation/deactivation of objective function discovery in PCEP.
必须能够在PCEP中配置目标函数发现的激活/停用。
In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring a list of authorized objective functions on a PCE. This may apply to any session the PCEP speaker participates in, to a specific session with a given PCEP peer, or to a specific group of sessions with a specific group of PCEP peers.
除了[RFC5440]第8.1节中已列出的参数外，PCEP实施还应允许在PCE上配置授权目标函数列表。这可能适用于PCEP演讲者参与的任何会话、与给定PCEP对等方的特定会话或与特定PCEP对等方组的特定会话组。
Note that it is not mandatory for an implementation to support all objective functions defined in Section 4.
请注意，实施支持第4节中定义的所有目标功能不是强制性的。
It MUST be possible to configure a default objective function used for path computation when a path request is received that requests to use an optional objective function.
当收到请求使用可选目标函数的路径请求时，必须能够配置用于路径计算的默认目标函数。
The PCEP MIB Module defined in [PCEP-MIB] could be extended to include objective functions.
[PCEP-MIB]中定义的PCEP MIB模块可以扩展为包括目标函数。
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
除了[RFC5440]中已经列出的机制外，本文件中定义的机制并不意味着任何新的活性检测和监测要求。
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].
除了[RFC5440]中已经列出的机制外，本文件中定义的机制并不意味着任何新的操作验证要求。
Mechanisms defined in this document do not imply any requirements on other protocols in addition to those already listed in [RFC5440].
除[RFC5440]中已列出的协议外，本文件中定义的机制并不意味着对其他协议的任何要求。
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440].
除[RFC5440]中列出的机制外，本文件中定义的机制对网络运行没有任何影响。
The authors would like to thank Jerry Ash, Fabien Verhaeghe, Robert Sparks, and Adrian Farrel for their useful comments.
作者要感谢Jerry Ash、Fabien Verhaeghe、Robert Sparks和Adrian Farrel的有用评论。
[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月。
[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月。
[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月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]Le Roux，J.，编辑，“路径计算元素（PCE）发现的要求”，RFC 4674，2006年10月。
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5088]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的OSPF协议扩展”，RFC 5088，2008年1月。
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5089]Le Roux，JL.，Ed.，Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“路径计算元素（PCE）发现的IS-IS协议扩展”，RFC 5089，2008年1月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[PCE-GCO] 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", Work in Progress, March 2009.
[PCE-GCO]Lee，Y.，Le Roux，JL.，King，D.，和E.Oki，“支持全局并行优化的路径计算元素通信协议（PCEP）要求和协议扩展”，正在进行的工作，2009年3月。
[PCEP-MIB] Koushik, K., and E. Stephan, "PCE Communication Protocol (PCEP) Management Information Base", Work in Progress, January 2009.
[PCEP-MIB]Koushik，K.和E.Stephan，“PCE通信协议（PCEP）管理信息库”，正在进行的工作，2009年1月。
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF) - A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009.
[RFC5511]Farrel，A.，“路由Backus-Naur形式（RBNF）-用于在各种路由协议规范中形成编码规则的语法”，RFC 5511，2009年4月。
This appendix contains the full set of code fragments defined in this document.
本附录包含本文档中定义的全套代码片段。
Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved.
版权所有（c）2009 IETF信托基金和被确定为代码作者的人员。版权所有。
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
在满足以下条件的情况下，允许以源代码和二进制格式重新分发和使用，无论是否修改：
o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
o 源代码的重新分发必须保留上述版权声明、此条件列表和以下免责声明。
o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
o 以二进制形式重新分发时，必须在分发时提供的文档和/或其他材料中复制上述版权声明、本条件列表和以下免责声明。
o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission.
o 未经事先书面许可，不得使用互联网协会、IETF或IETF Trust的名称或特定贡献者的名称来认可或推广源自本软件的产品。
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
本软件由版权所有者和贡献者“按原样”提供，不承担任何明示或暗示的担保，包括但不限于对适销性和特定用途适用性的暗示担保。在任何情况下，版权所有人或贡献者均不对任何直接、间接、偶然、特殊、惩戒性或后果性损害（包括但不限于替代商品或服务的采购；使用、数据或利润的损失；或业务中断）负责，无论是在合同中还是在任何责任理论下，严格责任，或因使用本软件而产生的侵权行为（包括疏忽或其他），即使告知可能发生此类损害。
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
<PCReq Message> ::= <Common Header>
[<svec-list>]
<request-list>
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
<PCRep Message> ::= <Common Header>
[<svec-list>]
<response-list>
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<svec-list> ::= <SVEC>
[<OF>]
[<metric-list>]
[<svec-list>]
<request-list> ::= <request> [<request-list>]
<request-list> ::= <request> [<request-list>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
<request> ::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
<metric-list> ::= <METRIC>[<metric-list>]
<metric-list> ::= <METRIC>[<metric-list>]
<response-list> ::= <response> [<response-list>]
<response-list> ::= <response> [<response-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<response> ::= <RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list> ::= <path> [<path-list>]
<path-list> ::= <path> [<path-list>]
<path> ::= <ERO>
<attribute-list>
<path> ::= <ERO>
<attribute-list>
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
Authors' Addresses
作者地址
JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion 22307 France
法国勒鲁电信2号，皮埃尔·马津·拉尼翁大街，邮编22307
EMail: jeanlouis.leroux@orange-ftgroup.com
EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Philippe Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France
Jean-Philippe Vasseur Cisco Systems，Inc.，11号，亚特兰蒂斯卡米尔·德斯穆林街92782号
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Young Lee Huawei Technologies, LTD. 1700 Alma Drive, Suite 100 Plano, TX 75075 USA
杨利华为技术有限公司，美国德克萨斯州普莱诺市阿尔玛大道1700号100室，邮编75075
EMail: ylee@huawei.com
EMail: ylee@huawei.com