Internet Engineering Task Force (IETF) F. Zhang
Request for Comments: 7150 Huawei
Category: Standards Track A. Farrel
ISSN: 2070-1721 Juniper Networks
March 2014
Internet Engineering Task Force (IETF) F. Zhang
Request for Comments: 7150 Huawei
Category: Standards Track A. Farrel
ISSN: 2070-1721 Juniper Networks
March 2014
Conveying Vendor-Specific Constraints in the Path Computation Element Communication Protocol
在路径计算元素通信协议中传递特定于供应商的约束
Abstract
摘要
The Path Computation Element communication Protocol (PCEP) is used to convey path computation requests and responses both between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) and between cooperating PCEs. In PCEP, the path computation requests carry details of the constraints and objective functions that the PCC wishes the PCE to apply in its computation.
路径计算元素通信协议（PCEP）用于在路径计算客户端（PCC）和路径计算元素（PCE）之间以及协作PCE之间传输路径计算请求和响应。在PCEP中，路径计算请求包含PCC希望PCE在其计算中应用的约束和目标函数的详细信息。
This document defines a facility to carry vendor-specific information in PCEP using a dedicated object and a new Type-Length-Variable that can be carried in any existing PCEP object.
本文件定义了一种设施，使用专用对象和可在任何现有PCEP对象中携带的新类型长度变量，在PCEP中携带供应商特定信息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7150.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7150.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
A Path Computation Element (PCE) is 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. An architecture for the use of PCEs is defined in [RFC4655].
路径计算元素（PCE）是能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。[RFC4655]中定义了PCE的使用架构。
The Path Computation Element communication Protocol (PCEP) is defined in [RFC5440] to exchange path computation requests and responses between Path Computation Clients (PCCs) and PCEs. It is also used between cooperating PCEs.
[RFC5440]中定义了路径计算元素通信协议（PCEP），用于在路径计算客户端（PCC）和PCE之间交换路径计算请求和响应。它也用于合作的PCE之间。
Path computations performed by a PCE depend on a set of constraints indicated by the PCC. These constraints include the endpoints of the path to compute (source and destination) and may include other simple constraints such as bandwidth requirements and metric maxima (for example, a maximum threshold for the hop count or the Traffic Engineering (TE) metric of the computed path).
PCE执行的路径计算取决于PCC指示的一组约束。这些约束包括要计算的路径的端点（源和目的地），并且可以包括其他简单约束，例如带宽要求和度量最大值（例如，计算路径的跳数的最大阈值或流量工程（TE）度量）。
The PCE also needs to use an objective function to qualify the path it selects as meeting the requirements of the PCC. The PCE may have a default objective function, but the PCC can also indicate which objective function it wants applied by placing an Objective Function object in the path computation request message [RFC5541]. A core set of objective functions to be supported in PCEP messages is defined in the base PCEP requirements [RFC4657], and [RFC5541] defines each of these functions as an abstract formula.
PCE还需要使用目标函数来确定其选择的路径是否满足PCC的要求。PCE可能有一个默认的目标函数，但是PCC也可以通过在路径计算请求消息[RFC5541]中放置目标函数对象来指示它想要应用哪个目标函数。PCEP基本要求[RFC4657]中定义了PCEP消息中支持的一组核心目标函数，[RFC5541]将这些函数定义为一个抽象公式。
The registry of codepoints used to indicate objective functions is managed by IANA and new assignments can be made according to "IETF Review" and "First Come First Served" policies [RFC5226]. PCE implementations may also choose to offer proprietary, vendor-specific
用于指示目标功能的代码点注册由IANA管理，可根据“IETF审查”和“先到先得”政策进行新的分配[RFC5226]。PCE实施也可以选择提供专有的、特定于供应商的服务
objective functions, and there is scope for this within the codepoint registry created by [RFC5541] using the codepoints that are flagged as "Reserved for Private Use".
目标函数，并且[RFC5541]使用标记为“保留供私人使用”的代码点创建的代码点注册表中存在此范围。
Proprietary objective functions may operate on non-standard constraints or metrics. The PCEP METRIC Object defined in [RFC5440] has scope for the definition of new, standardized metrics, but no facility for the definition of vendor-specific metrics. At the same time, there is no mechanism in PCEP for carrying other, more complex, vendor-specific information.
专有目标函数可以在非标准约束或指标上运行。[RFC5440]中定义的PCEP度量对象有定义新的标准化度量的范围，但没有定义供应商特定度量的工具。同时，PCEP中没有任何机制来承载其他更复杂的特定于供应商的信息。
This document defines a new PCEP object, the Vendor Information object that can be used to carry arbitrary, proprietary information such as vendor-specific constraints.
本文档定义了一个新的PCEP对象，即供应商信息对象，可用于携带任意专有信息，如供应商特定约束。
This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV that can be used to carry arbitrary information within any PCEP object that supports TLVs.
本文档还定义了一个新的PCEP TLV，即VENDOR-INFORMATION-TLV，可用于在支持TLV的任何PCEP对象内携带任意信息。
It should be noted that by the very definition of "vendor-specific", the inclusion of either a Vendor Information object or the VENDOR-INFORMATION-TLV implies an inability to interoperate at a functional level with implementations from other vendors unless there is some cooperation agreement between vendors. Sections 2.1 and 3.1 discuss backward compatibility, which indicates how these protocol constructs are handled by implementations that do not support them at all, while text in Sections 2 and 3 describe how implementations handle the constructs if they understand them, but do not support the embedded Enterprise Number that indicates to which vendor the constructs apply.
应该注意的是，根据“特定于供应商”的定义，包含供应商信息对象或供应商信息TLV意味着无法在功能级别与其他供应商的实现进行互操作，除非供应商之间存在某种合作协议。第2.1节和第3.1节讨论了向后兼容性，指出了根本不支持这些协议构造的实现如何处理这些协议构造，而第2节和第3节中的文本描述了实现如何处理这些构造（如果理解它们的话），但不支持嵌入式企业编号，该编号指示构造适用于哪个供应商。
When vendor-specific information is used by an implementation, the vendor is encouraged to document the meaning of the information to encourage wider use and implementation. In particular, when there is more general interest in a vendor-specific extension, the vendor is encouraged to bring it to the IETF for standardization as a regular protocol construct moving it out of the vendor-specific space.
当实施使用特定于供应商的信息时，鼓励供应商记录信息的含义，以鼓励更广泛的使用和实施。特别是，当对特定于供应商的扩展有更广泛的兴趣时，鼓励供应商将其作为常规协议构造带到IETF进行标准化，将其移出特定于供应商的空间。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
A PCC that wants to convey proprietary or vendor-specific constraints or metrics to a PCE does so by including a Vendor Information object in the PCReq message. The contents and format of the object are described in Section 4, but it is important to note that the object includes an Enterprise Number that is a unique identifier of an organization responsible for the definition of the content and meaning of the object.
想要向PCE传递专有或供应商特定约束或指标的PCC通过在PCReq消息中包含供应商信息对象来实现。第4节描述了对象的内容和格式，但需要注意的是，对象包括一个企业编号，该编号是负责定义对象内容和含义的组织的唯一标识符。
A PCE that receives a PCReq message containing a Vendor Information object MUST act according to the P flag in the object header. That is, if the P flag is set, the object will be treated as mandatory and the request will either be processed using the contents of the object or be rejected as defined in [RFC5440] (see also Section 2.1). If the P flag is clear, then, as defined in [RFC5440], the object may be used by the PCE or may be ignored. The PCC sets the P flag according to how it wishes the request to be processed.
接收包含供应商信息对象的PCReq消息的PCE必须根据对象头中的P标志进行操作。也就是说，如果设置了P标志，则对象将被视为强制对象，并且请求将使用对象的内容进行处理，或者按照[RFC5440]中的定义被拒绝（另请参见第2.1节）。如果P标志清除，则根据[RFC5440]中的定义，对象可由PCE使用或可忽略。PCC根据其希望处理请求的方式设置P标志。
The PCE determines how to interpret the information in the Vendor Information object by examining the Enterprise Number it contains. An implementation that supports the Vendor Information object, but receives one carrying an Enterprise Number that it does not support MUST act according to the P flag in the object. That is, if the P flag is set, the PCE MUST reject the PCReq as defined in [RFC5440] by sending an Error message with Error-Type="Not supported Object" along with the corresponding Vendor Information object.
PCE通过检查供应商信息对象包含的企业编号来确定如何解释该对象中的信息。支持供应商信息对象，但接收到一个包含其不支持的企业编号的实现时，必须根据对象中的P标志进行操作。也就是说，如果设置了P标志，PCE必须通过发送错误类型为“不支持对象”的错误消息以及相应的供应商信息对象来拒绝[RFC5440]中定义的PCReq。
The Vendor Information object is OPTIONAL in a PCReq message. Multiple instances of the object MAY be used on a single PCReq message, and each MUST be treated according to its P-bit setting. Different instances of the object can have different Enterprise Numbers.
供应商信息对象在PCReq消息中是可选的。对象的多个实例可用于单个PCReq消息，每个实例必须根据其P位设置进行处理。对象的不同实例可以具有不同的企业编号。
The object can be present in the PCReq message to enable it to apply to a single path computation request or to a set of synchronized requests. This usage mirrors the usage of the Objective Function object [RFC5541]. Thus, the PCReq message based on [RFC6006] is encoded as follows using the syntax described in [RFC5511].
对象可以存在于PCReq消息中，以使其能够应用于单路径计算请求或一组同步请求。此用法反映了目标函数对象[RFC5541]的用法。因此，基于[RFC6006]的PCReq消息使用[RFC5511]中描述的语法进行如下编码。
<PCReq Message> ::= <Common Header>
[<svec_list>]
<request-list>
<PCReq Message> ::= <Common Header>
[<svec_list>]
<request-list>
where
哪里
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<metric-list>]
[<vendor-info-list>]
[<svec-list>]
<svec-list> ::= <SVEC>
[<OF>]
[<GC>]
[<XRO>]
[<metric-list>]
[<vendor-info-list>]
[<svec-list>]
<metric-list> ::= <METRIC>
[<metric-list>]
<metric-list> ::= <METRIC>
[<metric-list>]
<vendor-info-list> ::= <VENDOR-INFORMATION>
[<vendor-info-list>]
<vendor-info-list> ::= <VENDOR-INFORMATION>
[<vendor-info-list>]
<request-list> ::= <request>
[<request-list>]
<request-list> ::= <request>
[<request-list>]
<request> ::= <RP>
[<vendor-info-list>]
<end-point-rro-pair-list>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
<request> ::= <RP>
[<vendor-info-list>]
<end-point-rro-pair-list>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<OF>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
where
哪里
<end-point-rro-pair-list> ::= <END-POINTS>
[<RRO-List>]
[<BANDWIDTH>]
[<vendor-info-list>]
[<end-point-rro-pair-list>]
<end-point-rro-pair-list> ::= <END-POINTS>
[<RRO-List>]
[<BANDWIDTH>]
[<vendor-info-list>]
[<end-point-rro-pair-list>]
<RRO-List> ::= <RRO> [<BANDWIDTH>] [<RRO-List>]
<RRO-List> ::= <RRO> [<BANDWIDTH>] [<RRO-List>]
<metric-list> ::= <METRIC> [<metric-list>]
<metric-list> ::= <METRIC> [<metric-list>]
The Vendor Information object can be included in a PCRep message in exactly the same way as any other object as defined in [RFC5440].
供应商信息对象可以以与[RFC5440]中定义的任何其他对象完全相同的方式包含在PCRep消息中。
Thus, the PCRep is encoded as follows:
因此，PCRep编码如下：
<PCRep Message> ::= <Common Header>
<response>
<PCRep Message> ::= <Common Header>
<response>
<response> ::= <RP>
[<vendor-info-list>]
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
<response> ::= <RP>
[<vendor-info-list>]
[<end-point-path-pair-list>]
[<NO-PATH>]
[<attribute-list>]
where:
哪里：
<end-point-path-pair-list> ::=
[<END-POINTS>]
<path>
[<vendor-info-list>]
[<end-point-path-pair-list>]
<end-point-path-pair-list> ::=
[<END-POINTS>]
<path>
[<vendor-info-list>]
[<end-point-path-pair-list>]
<path> ::= (<ERO>|<SERO>) [<path>]
<path> ::= (<ERO>|<SERO>) [<path>]
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
A legacy implementation that does not recognize the Vendor Information object will act according to the procedures set out in [RFC5440]. If the P flag is set in the object, the message will be rejected using a PCErr message with an Error Type of 3 ("Unknown Object"). If the P flag is not set, the object can safely be ignored by the recipient.
不识别供应商信息对象的传统实现将按照[RFC5440]中规定的程序进行操作。如果在对象中设置了P标志，则将使用错误类型为3（“未知对象”）的PCErr消息拒绝该消息。如果未设置P标志，则收件人可以安全地忽略该对象。
The Vendor Information TLV can be used to carry vendor-specific information that applies to a specific PCEP object by including the TLV in the object.
供应商信息TLV可用于通过将TLV包含在对象中来携带适用于特定PCEP对象的供应商特定信息。
The PCE determines how to interpret the Vendor Information TLV by examining the Enterprise Number it contains. If the Enterprise Number is unknown to the PCE, it MUST treat the Vendor Information TLV as an unknown TLV and handle it as described in [RFC5440] (see also Section 3.1).
PCE通过检查供应商信息TLV包含的企业编号来确定如何解释供应商信息TLV。如果PCE不知道企业编号，则必须将供应商信息TLV视为未知TLV，并按照[RFC5440]中的说明进行处理（另请参见第3.1节）。
Further specifications are needed to define the position and meaning of the Vendor Information TLV for specific PCEP objects.
需要进一步的规范来定义特定PCEP对象的供应商信息TLV的位置和意义。
A legacy implementation that does not recognize the Vendor Information TLV in an object will act according to the procedures set out in [RFC5440]. As described in Section 7.1 of [RFC5440], unrecognized TLVs MUST be ignored.
不识别对象中供应商信息TLV的遗留实现将按照[RFC5440]中规定的程序进行操作。如[RFC5440]第7.1节所述，必须忽略未识别的TLV。
The Vendor Information object and TLV conform to the format for PCEP objects and TLVs defined in [RFC5440].
供应商信息对象和TLV符合[RFC5440]中定义的PCEP对象和TLV格式。
VENDOR-INFORMATION Object-Class 32
供应商信息对象类32
VENDOR-INFORMATION Object-Type 1
供应商信息对象类型1
VENDOR-INFORMATION-TLV Type 7
供应商信息-TLV类型7
The format of the VENDOR-INFORMATION object and the format of the VENDOR-INFORMATION-TLV are the same and are as shown in Figure 1.
供应商信息对象的格式与供应商信息TLV的格式相同，如图1所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Enterprise-Specific Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Enterprise-Specific Information ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 : Format of the Vendor Information Object and TLV
图1：供应商信息对象和TLV的格式
Enterprise Number
企业编号
A unique identifier of an organization encoded as a 32-bit integer. Enterprise Numbers are assigned by IANA and managed through an IANA registry [RFC2578].
组织的唯一标识符，编码为32位整数。企业编号由IANA分配，并通过IANA注册中心进行管理[RFC2578]。
Enterprise-Specific Information
企业特定信息
The detailed enterprise-specific constraint information carried by the object. The format and interpretation of this information is a matter for the enterprise identified by the Enterprise Number. Such formats and interpretation may be published by the enterprise
对象携带的详细的企业特定约束信息。该信息的格式和解释由企业编号确定的企业负责。这些格式和解释可由企业发布
(possibly through an Informational RFC or through commercial documentation) so that PCCs or PCEs that are not part of the organization can use the information.
（可能通过信息RFC或商业文件）以便不属于组织的PCC或PCE可以使用该信息。
IANA maintains a registry of PCEP parameters called the "Path Computation Element Protocol (PCEP) Numbers".
IANA维护一个名为“路径计算元素协议（PCEP）编号”的PCEP参数注册表。
IANA has made an allocation from the "PCEP Objects" subregistry as follows.
IANA已从“PCEP对象”子区域进行分配，如下所示。
Object-Class Value Name Reference 32 VENDOR-INFORMATION [RFC7150] Object-Type 0: Unassigned 1: Vendor-Specific Constraints [RFC7150] 2-255: Unassigned
对象类值名称参考32供应商信息[RFC7150]对象类型0:未分配1:供应商特定约束[RFC7150]2-255:未分配
IANA has made an allocation from the "PCEP TLV Type Indicators" subregistry as follows.
IANA已从“PCEP TLV类型指示器”子区域进行分配，如下所示。
Value Description Reference 7 VENDOR-INFORMATION-TLV [RFC7150]
价值说明参考7供应商信息-TLV[RFC7150]
This section follows the guidance of [RFC5706] and [RFC6123].
本节遵循[RFC5706]和[RFC6123]的指南。
A PCEP implementation SHOULD allow configuring of various parameters as described in [RFC5440]. A PCC implementation that uses vendor-specific information MAY make the use of this information configurable either across the whole PCC, per PCE that the PCC uses, or per path computation request. A PCE that supports vendor-specific information MAY make the support of this information configurable, and MAY allow configuration of policies for the use of the information.
PCEP实现应允许配置[RFC5440]中所述的各种参数。使用特定于供应商的信息的PCC实现可以在整个PCC、PCC使用的每个PCE或每个路径计算请求中配置该信息的使用。支持特定于供应商的信息的PCE可以配置对该信息的支持，并允许配置使用该信息的策略。
A PCEP MIB module is defined in [PCE-MIB] that describes managed objects for modeling of PCEP communications.
[PCE-MIB]中定义了PCEP MIB模块，该模块描述了用于PCEP通信建模的托管对象。
It is NOT RECOMMENDED that standard MIB modules be extended to include detailed information about the content of the Vendor Information object or TLV. However, the standard MIB module MAY be extended to report the use of the Vendor Information object or TLV and the Enterprise Numbers that the objects and TLVs contain.
不建议将标准MIB模块扩展为包含有关供应商信息对象或TLV内容的详细信息。但是，可以扩展标准MIB模块，以报告供应商信息对象或TLV的使用情况以及对象和TLV包含的企业编号。
This document makes no change to the basic operation of PCEP, so there are no changes to the requirements for liveness detection and monitoring set out in [RFC4657] and [RFC5440].
本文件未对PCEP的基本操作进行任何更改，因此[RFC4657]和[RFC5440]中规定的活性检测和监测要求未作任何更改。
This document makes no change to the basic operation of PCEP, so there are no changes to the requirements or techniques for monitoring the correct operation of the protocol out in [RFC4657] and [RFC5440].
本文件未对PCEP的基本操作进行更改，因此[RFC4657]和[RFC5440]中监控协议正确运行的要求或技术未发生更改。
Note that "correct operation" in this context refers to the operation of the protocol itself and not to the operation of the computation algorithms which are out of scope for all PCEP work.
注意，本文中的“正确操作”指的是协议本身的操作，而不是所有PCEP工作范围之外的计算算法的操作。
Mechanisms for verifying the correct operation of computation algorithms might involve comparing the results returned by more than one PCE. Scope for this might be limited by the use of vendor information unless multiple PCEs support the same set of vendor information.
验证计算算法正确运行的机制可能涉及比较多个PCE返回的结果。除非多个PCE支持同一组供应商信息，否则此范围可能会受到供应商信息使用的限制。
This document does not place any new requirements on other network components or protocols. However, it may be beneficial to consider whether a PCE should advertise the Enterprise Numbers and vendor information it supports. This advertisement could be within PCE Discovery [RFC5088] [RFC5089] or through extensions to PCEP [RFC5440].
本文件未对其他网络组件或协议提出任何新要求。然而，考虑PCE是否应该宣传它支持的企业编号和供应商信息可能是有益的。此广告可以在PCE Discovery[RFC5088][RFC5089]中发布，也可以通过PCEP[RFC5440]的扩展发布。
Extensions for discovery and advertisement are outside the scope of this document.
发现和发布的扩展不在本文档的范围内。
The availability of vendor information in PCEP messages may facilitate more complex and detailed path computations that may enhance the way in which the network is operated.
PCEP消息中供应商信息的可用性可促进更复杂和更详细的路径计算，从而增强网络的运行方式。
On the other hand, the presence of additional vendor-specific information in PCEP messages may congest the operation of the protocol especially if the PCE does not support the information supplied by the PCC. Thus, a PCC SHOULD monitor the capabilities of a PCE either by discovery mechanisms as described in Section 6.5 or through the receipt of negative responses. A PCC SHOULD NOT include vendor information in a PCReq message to a PCE that it believes does not support the information and that will not forward the request to some other PCE that does support the information.
另一方面，在PCEP消息中存在额外的特定于供应商的信息可能会阻塞协议的操作，特别是在PCE不支持PCC提供的信息的情况下。因此，PCC应通过第6.5节所述的发现机制或通过接收负面响应来监控PCE的能力。PCC不应在发送给PCE的PCReq消息中包含供应商信息，因为PCC认为该消息不支持该信息，并且不会将请求转发给支持该信息的其他PCE。
The protocol extensions defined in this document do not substantially change the nature of PCEP. Therefore, the security considerations set out in [RFC5440] apply unchanged. Note that further security considerations for the use of PCEP over TCP are presented in [RFC6952].
本文件中定义的协议扩展并未实质性改变PCEP的性质。因此，[RFC5440]中规定的安全注意事项不作更改。请注意，[RFC6952]中介绍了通过TCP使用PCEP的进一步安全注意事项。
Operators should note that an attack on PCEP may involve making PCEP messages as large as possible in order to consume bandwidth and processing power. The Vendor Information object and TLV may provide a vector for this type of attack. It may be protected against by using the authentication and integrity procedures described in [RFC5440].
操作员应注意，对PCEP的攻击可能涉及使PCEP消息尽可能大，以消耗带宽和处理能力。供应商信息对象和TLV可能为这种类型的攻击提供向量。可使用[RFC5440]中所述的身份验证和完整性程序对其进行保护。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440]Vasseur，JP.，Ed.，和JL。Le Roux，Ed.“路径计算元素（PCE）通信协议（PCEP）”，RFC 54402009年3月。
[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月。
[RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, September 2010.
[RFC6006]Zhao，Q.，Ed.，King，D.，Ed.，Verhaeghe，F.，Takeda，T.，Ali，Z.，和J.Meuria，“点对多点流量工程标签交换路径的路径计算元素通信协议（PCEP）扩展”，RFC 60062010年9月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.，Ed.，和J.Le Roux，Ed.，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[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月。
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, June 2009.
[RFC5541]Le Roux，JL.，Vasseur，JP.，和Y.Lee，“路径计算元素通信协议（PCEP）中目标函数的编码”，RFC 55412009年6月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，2009年11月。
[RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, February 2011.
[RFC6123]Farrel，A.“在路径计算元素（PCE）工作组草案中纳入可管理性部分”，RFC 61232011年2月。
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, May 2013.
[RFC6952]Jethanandani，M.，Patel，K.，和L.Zheng，“根据路由协议键控和认证（KARP）设计指南分析BGP，LDP，PCEP和MSDP问题”，RFC 6952，2013年5月。
[PCE-MIB] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Protocol (PCEP) Management Information Base", Work in Progress, February 2014.
[PCE-MIB]Koushik，A.，Stephan，E.，Zhao，Q.，King，D.，和J.Hardwick，“路径计算元素协议（PCEP）管理信息库”，正在进行的工作，2014年2月。
Thanks to Meral Shirazipour, Ramon Casellas, Cyril Margaria, Dhruv Dhody, Julien Meuric, and Robert Sparks for review and comments.
感谢Meral Shirazipour、Ramon Casellas、Cyril Margaria、Dhruv Dhody、Julien Meuria和Robert Sparks的审查和评论。
Greg Bernstein Grotto Networking EMail: gregb@grotto-networking.com
Greg Bernstein Grotto网络电子邮件：gregb@grotto-网络
Ina Minei Juniper Networks EMail: ina@juniper.net
Ina Minei Juniper Networks电子邮件：ina@juniper.net
Authors' Addresses
作者地址
Adrian Farrel Juniper Networks EMail: adrian@olddog.co.uk
Adrian Farrel Juniper Networks电子邮件：adrian@olddog.co.uk
Fatai Zhang Huawei Technologies EMail: zhangfatai@huawei.com
华为技术有限公司电子邮件：zhangfatai@huawei.com