Internet Engineering Task Force (IETF) JP. Vasseur, Ed.
Request for Comments: 5886 Cisco Systems, Inc.
Category: Standards Track JL. Le Roux
ISSN: 2070-1721 France Telecom
Y. Ikejiri
NTT Communications Corporation
June 2010
Internet Engineering Task Force (IETF) JP. Vasseur, Ed.
Request for Comments: 5886 Cisco Systems, Inc.
Category: Standards Track JL. Le Roux
ISSN: 2070-1721 France Telecom
Y. Ikejiri
NTT Communications Corporation
June 2010
A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture
一套基于路径计算元素（PCE）体系结构的监控工具
Abstract
摘要
A Path Computation Element (PCE)-based architecture has been specified for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains (where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such as Interior Gateway Protocol (IGP) areas and Autonomous Systems). Path Computation Clients (PCCs) send computation requests to PCEs, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain".
针对多协议标签交换（MPLS）和广义MPLS（GMPLS）网络中单域或多域环境下的流量工程（TE）标签交换路径（LSP）计算，提出了一种基于路径计算元素（PCE）的体系结构（其中域是指地址管理或路径计算责任的公共范围内的网络元素集合，如内部网关协议（IGP）区域和自治系统）。路径计算客户端（PCC）向pce发送计算请求，这些pce可以将请求转发给形成“路径计算链”的其他pce并与之协作。
In PCE-based environments, it is thus critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest. This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) in order to gather such information.
因此，在基于PCE的环境中，监控路径计算链的状态对于故障排除和性能监控非常重要：每个元素的活跃度（PCE）涉及PCE链和潜在资源争用状态的检测以及路径计算时间方面的统计数据是此类感兴趣的度量的示例。本文件规定了路径计算元素协议（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/rfc5886.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5886.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Path Computation Monitoring Messages ............................6
3.1. Path Computation Monitoring Request (PCMonReq) Message .....6
3.2. Path Monitoring Reply (PCMonRep) Message ...................9
4. Path Computation Monitoring Objects ............................11
4.1. MONITORING Object .........................................11
4.2. PCC-ID-REQ Object .........................................13
4.3. PCE-ID Object .............................................14
4.4. PROC-TIME Object ..........................................15
4.5. OVERLOAD Object ...........................................17
5. Policy .........................................................18
6. Elements of Procedure ..........................................18
7. Manageability Considerations ...................................20
7.1. Control of Function and Policy ............................20
7.2. Information and Data Models ...............................20
7.3. Liveness Detection and Monitoring .........................20
7.4. Verify Correct Operations .................................20
7.5. Requirements on Other Protocols ...........................21
7.6. Impact on Network Operations ..............................21
8. Guidelines to Avoid Overload Thrashing .........................21
9. IANA Considerations ............................................22
9.1. New PCEP Message ..........................................22
9.2. New PCEP Objects ..........................................22
9.3. New Error-Values ..........................................23
9.4. MONITORING Object Flag Field ..............................23
9.5. PROC-TIME Object Flag Field ...............................24
9.6. OVERLOAD Object Flag Field ................................24
10. Security Considerations .......................................24
11. Acknowledgments ...............................................25
12. References ....................................................25
12.1. Normative References .....................................25
12.2. Informative References ...................................25
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Path Computation Monitoring Messages ............................6
3.1. Path Computation Monitoring Request (PCMonReq) Message .....6
3.2. Path Monitoring Reply (PCMonRep) Message ...................9
4. Path Computation Monitoring Objects ............................11
4.1. MONITORING Object .........................................11
4.2. PCC-ID-REQ Object .........................................13
4.3. PCE-ID Object .............................................14
4.4. PROC-TIME Object ..........................................15
4.5. OVERLOAD Object ...........................................17
5. Policy .........................................................18
6. Elements of Procedure ..........................................18
7. Manageability Considerations ...................................20
7.1. Control of Function and Policy ............................20
7.2. Information and Data Models ...............................20
7.3. Liveness Detection and Monitoring .........................20
7.4. Verify Correct Operations .................................20
7.5. Requirements on Other Protocols ...........................21
7.6. Impact on Network Operations ..............................21
8. Guidelines to Avoid Overload Thrashing .........................21
9. IANA Considerations ............................................22
9.1. New PCEP Message ..........................................22
9.2. New PCEP Objects ..........................................22
9.3. New Error-Values ..........................................23
9.4. MONITORING Object Flag Field ..............................23
9.5. PROC-TIME Object Flag Field ...............................24
9.6. OVERLOAD Object Flag Field ................................24
10. Security Considerations .......................................24
11. Acknowledgments ...............................................25
12. References ....................................................25
12.1. Normative References .....................................25
12.2. Informative References ...................................25
The Path Computation Element (PCE)-based architecture has been specified in [RFC4655] for the computation of Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks in the context of single or multiple domains where a domain refers to a collection of network elements within a common sphere of address management or path computational responsibility such Interior Gateway Protocol (IGP) areas and Autonomous Systems.
[RFC4655]中规定了基于路径计算元素（PCE）的体系结构，用于计算多协议标签交换（MPLS）和通用MPLS（GMPLS）中的流量工程（TE）标签交换路径（LSP）单个或多个域环境中的网络，其中域指地址管理或路径计算责任的公共范围内的网络元素集合，如内部网关协议（IGP）区域和自治系统。
Path Computation Clients (PCCs) send computation requests to PCEs using PCReq messages, and these may forward the requests to and cooperate with other PCEs forming a "path computation chain". In the case of successful path computation, the computed paths are then provided to the requesting PCC using PCRep messages. The PCReq and PCRep messages are defined in [RFC5440].
路径计算客户端（pcc）使用PCReq消息向pce发送计算请求，并且这些pcc可以将请求转发给形成“路径计算链”的其他pce并与之协作。在路径计算成功的情况下，然后使用PCRep消息将计算出的路径提供给请求PCC。PCReq和PCRep消息在[RFC5440]中定义。
In PCE-based environments, it is critical to monitor the state of the path computation chain for troubleshooting and performance monitoring purposes: liveness of each element (PCE) involved in the PCE chain and detection of potential resource contention states and statistics in terms of path computation times are examples of such metrics of interest.
在基于PCE的环境中，监控路径计算链的状态对于故障排除和性能监控非常重要：每个元素的活跃度（PCE）涉及PCE链和潜在资源争用状态的检测以及路径计算时间方面的统计数据是此类感兴趣的度量的示例。
As defined in [RFC4655], there are circumstances in which more than one PCE is involved in the computation of a TE LSP. A typical example is when the PCC requires the computation of a TE LSP where the head-end and the tail-end of the TE LSP do not reside in adjacent domains and there is no single PCE with the visibility of both the head-end and tail-end domain. We call the set of PCEs involved in the computation of a TE LSP a "path computation chain". As further discussed in Section 3.1, the path computation chain may either be static (pre-configured) or dynamically determined during the path computation process.
如[RFC4655]中所定义，在某些情况下，一个TE LSP的计算涉及多个PCE。一个典型的例子是，当PCC需要计算TE LSP时，其中TE LSP的头端和尾端不位于相邻域中，并且没有具有头端和尾端域可见性的单个PCE。我们将计算TE LSP所涉及的PCE集称为“路径计算链”。如第3.1节中进一步讨论的，路径计算链可以是静态（预配置）的，也可以是在路径计算过程中动态确定的。
As discussed in [RFC4655], a TE LSP may be computed by one PCE (referred to as single PCE path computation) or several PCEs (referred to as multiple PCE path computation). In the former case, the PCC may be able to use IGP extensions to check the liveness of the PCE (see [RFC5088] and [RFC5089]) or PCEP using Keepalive messages. In contrast, when multiple PCEs are involved in the path computation chain, an example of which is the Backward Recursive PCE-based Computation (BRPC) procedure defined in [RFC5441], the PCC's visibility may be limited to the first PCE involved in the path computation chain. Thus, it is critical to define mechanisms in order to monitor the state of the path computation chain.
如[RFC4655]中所述，TE LSP可由一个PCE（称为单PCE路径计算）或多个PCE（称为多PCE路径计算）计算。在前一种情况下，PCC可以使用IGP扩展来使用Keepalive消息检查PCE（参见[RFC5088]和[RFC5089]）或PCEP的活跃度。相反，当路径计算链中涉及多个PCE时（其示例为[RFC5441]中定义的基于PCE的反向递归计算（BRPC）过程），PCC的可视性可限于路径计算链中涉及的第一个PCE。因此，定义机制以监控路径计算链的状态至关重要。
This document specifies PCEP extensions in order to gather various state metrics along the path computation chain. In this document, we call a "state metric" a metric that characterizes a PCE state. For example, such a metric can have a form of a boolean (PCE is alive or not, PCE is congested or not) or a performance metric (path computation time at each PCE).
本文档指定了PCEP扩展，以便沿路径计算链收集各种状态度量。在本文中，我们将“状态度量”称为表征PCE状态的度量。例如，此类度量可以具有布尔形式（PCE是否活动，PCE是否拥挤）或性能度量（每个PCE的路径计算时间）。
PCE state metrics can be gathered in two different contexts: in band or out of band. By "in band" we refer to the situation whereby a PCC requests to gather metrics in the context of a path computation request. For example, a PCC may send a path computation request to a PCE and may want to know the processing time of that request in addition to the computed path. Conversely, if the request is "out of band", PCE state metric collection is performed as a standalone request (e.g., check the liveness of a specific path computation chain, collect the average processing time computed over the last 5-minute period on one or more PCEs).
PCE状态度量可以在两种不同的上下文中收集：带内或带外。“带内”指的是PCC请求在路径计算请求的上下文中收集度量的情况。例如，PCC可以向PCE发送路径计算请求，并且除了计算的路径之外，还可能希望知道该请求的处理时间。相反，如果请求为“带外”，则PCE状态度量收集将作为独立请求执行（例如，检查特定路径计算链的活动性，收集在一个或多个PCE上过去5分钟内计算的平均处理时间）。
In this document, we define two monitoring request types: general and specific. A general monitoring request relates to the collection of a PCE state metrics that is not coupled to a particular path computation request (e.g., average CPU load on a PCE). Conversely, a specific monitoring request relates to a particular path computation request (processing time to complete the path computation for a TE LSP).
在本文中，我们定义了两种监视请求类型：常规和特定。一般监视请求涉及未耦合到特定路径计算请求（例如，PCE上的平均CPU负载）的PCE状态度量的集合。相反，特定监视请求与特定路径计算请求相关（完成TE LSP的路径计算的处理时间）。
This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) ([RFC5440]), including new objects and new PCEP messages, in order to monitor the path computation chain and gather various performance metrics.
本文件规定了路径计算元素协议（PCEP）（[RFC5440]）的程序和扩展，包括新对象和新PCEP消息，以便监控路径计算链并收集各种性能指标。
The message formats in this document are specified using Backus Naur Format (BNF) encoding as specified in [RFC5511].
本文件中的消息格式使用[RFC5511]中规定的Backus Naur格式（BNF）编码指定。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
PCC (Path Computation Client): any client application requesting a path computation to be performed by a Path Computation Element.
PCC（路径计算客户端）：任何请求路径计算元素执行路径计算的客户端应用程序。
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.
PCE（路径计算元素）：能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
TE LSP: Traffic Engineering Label Switched Path.
TE LSP：流量工程标签交换路径。
As defined in [RFC5440], a PCEP message consists of a common header followed by a variable-length body made of a set of objects that can be either mandatory or optional. As a reminder, an object is said to be mandatory in a PCEP message when the object must be included for the message to be considered valid. The P flag (defined in [RFC5440]) is located in the common header of each PCEP object and can be set by a PCEP peer to require a PCE to take into account the related information during the path computation. Because the P flag exclusively relates to a path computation request, it MUST be cleared in the two PCEP messages (PCMonReq and PCMonRep message) defined in this document.
如[RFC5440]中所定义，PCEP消息由一个公共标头和一个可变长度的正文组成，正文由一组对象组成，这些对象可以是强制性的，也可以是可选的。作为提醒，当必须包含对象才能将消息视为有效时，PCEP消息中的对象称为强制对象。P标志（在[RFC5440]中定义）位于每个PCEP对象的公共报头中，可由PCEP对等方设置，以要求PCE在路径计算期间考虑相关信息。由于P标志专门与路径计算请求相关，因此必须在本文档中定义的两条PCEP消息（PCMonReq和PCMonRep消息）中清除该标志。
For each PCEP message type, a set of rules is defined that specify the set of objects that the message can carry. An implementation MUST form the PCEP messages using the object ordering specified in this document.
对于每种PCEP消息类型，都定义了一组规则，用于指定消息可以携带的对象集。实现必须使用本文档中指定的对象顺序形成PCEP消息。
In this document, we define two PCEP messages referred to as the Path Computation Monitoring Request (PCMonReq) and Path Computation Monitoring Reply (PCMonRep) messages so as to handle out-of-band monitoring requests. The aim of the PCMonReq message sent by a PCC to a PCE is to gather one or more PCE state metrics on a set of PCEs involved in a path computation chain. The PCMonRep message sent by a PCE to a PCC is used to provide such data.
在本文中，我们定义了两条PCEP消息，称为路径计算监控请求（PCMonReq）和路径计算监控回复（PCMonRep）消息，以处理带外监控请求。PCC发送给PCE的PCMonReq消息的目的是收集路径计算链中涉及的一组PCE上的一个或多个PCE状态度量。PCE发送给PCC的PCMonRep消息用于提供此类数据。
The Message-Type field of the PCEP common header for the PCMonReq message is set to 8.
PCMonReq消息的PCEP公共头的消息类型字段设置为8。
There is one mandatory object that MUST be included within a PCMonReq message: the MONITORING object (see Section 4.1). If the MONITORING object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING object missing). Other objects are optional.
PCMonReq消息中必须包含一个强制对象：监控对象（见第4.1节）。如果缺少监控对象，接收PCE必须发送一条PCErr消息，错误类型为6（强制对象缺少），错误值为4（监控对象缺少）。其他对象是可选的。
Format of a PCMonReq message (out-of-band request):
<PCMonReq Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<pce-list>]
[<svec-list>]
[<request-list>]
Format of a PCMonReq message (out-of-band request):
<PCMonReq Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<pce-list>]
[<svec-list>]
[<request-list>]
where:
哪里：
<pce-list>::=<PCE-ID>[<pce-list>]
<pce-list>::=<PCE-ID>[<pce-list>]
<svec-list>::=<SVEC>
[<OF>]
[<svec-list>]
<svec-list>::=<SVEC>
[<OF>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
[<XRO>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
[<XRO>]
<metric-list>::=<METRIC>[<metric-list>]
<metric-list>::=<METRIC>[<metric-list>]
Format of a PCReq message with monitoring data requested (in-band
request):
<PCReq Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<pce-list>]
[<svec-list>]
<request-list>
Format of a PCReq message with monitoring data requested (in-band
request):
<PCReq Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<pce-list>]
[<svec-list>]
<request-list>
where:
哪里：
<pce-list>::=<PCE-ID>[<pce-list>]
<pce-list>::=<PCE-ID>[<pce-list>]
<svec-list>::=<SVEC>[<svec-list>]
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
where:
哪里：
<metric-list>::=<METRIC>[<metric-list>]
<metric-list>::=<METRIC>[<metric-list>]
The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO, and LOAD-BALANCING objects are defined in [RFC5440]. The XRO object is defined in [RFC5521] and the OF object is defined in [RFC5541]. The PCC-ID-REQ object is defined in Section 4.2.
SVEC、RP、端点、LSPA、带宽、度量、RRO、IRO和负载平衡对象在[RFC5440]中定义。XRO对象在[RFC5521]中定义，OF对象在[RFC5541]中定义。PCC-ID-REQ对象在第4.2节中定义。
The PCMonReq message is used to gather various PCE state metrics along a path computation chain. The path computation chain may be determined by the PCC (in the form of a series of a series of PCE-ID objects defined in Section 4.3) according to policy specified on the PCC or alternatively may be determined by the path computation procedure. For example, if the BRPC procedure ([RFC5441]) is used to compute an inter-domain TE LSP, the path computation chain may be determined dynamically. In that case, the PCC sends a PCMonReq message that contains the PCEP objects that characterize the TE LSP attributes along with the MONITORING object (see Section 4.1) that lists the set of metrics of interest. If a list of PCEs is present in the monitoring request, it takes precedence over mechanisms used to dynamically determine the path computation chain. If a PCE receives a monitoring request that specifies a next-hop PCE in the PCE list that is unreachable, the request MUST be silently discarded.
PCMonReq消息用于沿路径计算链收集各种PCE状态度量。路径计算链可由PCC根据PCC上规定的策略确定（以第4.3节中定义的一系列PCE-ID对象的形式），或者也可由路径计算程序确定。例如，如果BRPC过程（[RFC5441]）用于计算域间TE LSP，则可以动态地确定路径计算链。在这种情况下，PCC发送一条PCMonReq消息，该消息包含表征TE LSP属性的PCEP对象以及列出相关度量集的监控对象（见第4.1节）。如果监控请求中存在PCE列表，则它优先于用于动态确定路径计算链的机制。如果PCE接收到一个监控请求，该请求在PCE列表中指定了一个无法访问的下一跳PCE，则该请求必须以静默方式放弃。
Several PCE state metrics may be requested that are specified by a set of objects defined in Section 4. Note that this set of objects may be extended in the future.
可以请求几个PCE状态度量，这些度量由第4节中定义的一组对象指定。请注意，这组对象将来可能会扩展。
As pointed out in [RFC5440], several situations can arise in the form of:
正如[RFC5440]中所指出的，可能出现以下几种情况：
o a bundle of a set of independent and non-synchronized path computation requests,
o 一组独立且非同步的路径计算请求，
o a bundle of a set of independent and synchronized path computation requests (SVEC object defined below required), or
o 一组独立且同步的路径计算请求（以下定义的SVEC对象是必需的），或
o a bundle of a set of dependent and synchronized path computation requests (SVEC object defined below required).
o 一组相关的和同步的路径计算请求（需要下面定义的SVEC对象）的捆绑包。
In the case of a bundle of a set of requests, the MONITORING object SHOULD only be present in the first PCReq or PCMonReq message, and the monitoring request applies to all the requests of the bundle, even in the case of dependent and/or synchronized requests sent using more than one PCReq or PCMonReq message.
在一组请求的捆绑情况下，监视对象应仅出现在第一条PCReq或PCMonReq消息中，并且监视请求适用于捆绑的所有请求，即使是使用多条PCReq或PCMonReq消息发送的从属和/或同步请求。
Examples of requests. For the sake of illustration, consider the three following examples:
请求的例子。为了说明，请考虑以下三个例子：
Example 1 (out-of-band request): PCC1 makes a request to check the path computation chain that would be used should it request a path computation for a specific TE LSP named T1. A PCMonReq message is sent that contains a MONITORING object specifying a path computation check, along with the appropriate set of objects (e.g., RP, END-POINTS, etc.) that would be included in a PCReq message for T1.
示例1（带外请求）：PCC1请求检查路径计算链，如果它请求对名为T1的特定TE LSP进行路径计算，将使用该路径计算链。发送的PCMonReq消息包含指定路径计算检查的监控对象，以及将包含在T1的PCReq消息中的适当对象集（例如RP、端点等）。
Example 2 (in-band request): PCC1 requests a path computation for a TE LSP and also makes a request to gather the processing time along the path computation chain selected for the computation of T1. A PCReq message is sent that also contains a MONITORING object that specifies the performance metrics of interest.
示例2（带内请求）：PCC1请求TE LSP的路径计算，并且还请求沿为计算T1而选择的路径计算链收集处理时间。将发送一条PCReq消息，该消息还包含一个监控对象，该监控对象指定感兴趣的性能指标。
Example 3 (out-of-band request): PCC2 requests to gather performance metrics along the specific path computation chain <pce1, pce2, pce3, pce7>. A PCMonReq message is sent to PCE1 that contains a MONITORING object and a sequence of PCE-ID objects that identify PCE1, PCE2, PCE3, and PCE7, respectively.
示例3（带外请求）：PCC2请求沿特定路径计算链收集性能指标<pce1、pce2、pce3、pce7>。PCMonReq消息被发送到PCE1，该消息包含一个监控对象和一系列PCE-ID对象，分别标识PCE1、PCE2、PCE3和PCE7。
In all of the examples above, a PCRep message (in-band request) or PCMonReq message (out-of-band request) is sent in response to the request that reports the computed metrics.
在上述所有示例中，发送PCRep消息（带内请求）或PCMonReq消息（带外请求）以响应报告计算度量的请求。
The PCMonRep message is used to provide PCE state metrics back to the requester for out-of-band monitoring requests. The Message-Type field of the PCEP common header for the PCMonRep message is set to 9.
PCMonRep消息用于向请求者提供PCE状态度量，以用于带外监控请求。PCMonRep消息的PCEP公用标头的消息类型字段设置为9。
There is one mandatory object that MUST be included within a PCMonRep message: the MONITORING object (see Section 4.1). If the MONITORING object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING object missing).
PCMonRep消息中必须包含一个强制对象：监控对象（见第4.1节）。如果缺少监控对象，接收PCE必须发送一条PCErr消息，错误类型为6（强制对象缺少），错误值为4（监控对象缺少）。
Other objects are optional.
其他对象是可选的。
Format of a PCMonRep (out-of-band request):
<PCMonRep Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<RP>]
[<metric-pce-list>]
Format of a PCMonRep (out-of-band request):
<PCMonRep Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<RP>]
[<metric-pce-list>]
where:
哪里：
<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce>::=<PCE-ID>
[<PROC-TIME>]
[<OVERLOAD>]
<metric-pce>::=<PCE-ID>
[<PROC-TIME>]
[<OVERLOAD>]
Format of a PCRep message with monitoring data (in band):
<PCRep Message> ::= <Common Header>
<response-list>
Format of a PCRep message with monitoring data (in band):
<PCRep Message> ::= <Common Header>
<response-list>
where:
哪里：
<response-list>::=<response>[<response-list>]
<response-list>::=<response>[<response-list>]
<response>::=<RP>
<MONITORING>
<PCC-ID-REQ>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
[<metric-pce-list>]
<response>::=<RP>
<MONITORING>
<PCC-ID-REQ>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
[<metric-pce-list>]
<path-list>::=<path>[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
<path>::= <ERO><attribute-list>
where:
哪里：
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-list>]
<metric-list>::=<METRIC>[<metric-list>]
<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce>::=<PCE-ID>
[<PROC-TIME>]
[<OVERLOAD>]
<metric-pce>::=<PCE-ID>
[<PROC-TIME>]
[<OVERLOAD>]
The RP and the NO-PATH objects are defined in [RFC5440]. The PCC-ID-REQ object is defined in Section 4.2.
RP和无路径对象在[RFC5440]中定义。PCC-ID-REQ对象在第4.2节中定义。
If the path computation chain has been statically specified in the corresponding monitoring request using the series of a series of PCE-ID objects defined in Section 4.3, the monitoring request MUST use the same path computation chain (using the PCE list but in the reverse order).
如果使用第4.3节中定义的一系列PCE-ID对象在相应的监控请求中静态指定了路径计算链，则监控请求必须使用相同的路径计算链（使用PCE列表，但顺序相反）。
The PCEP objects defined in the document are compliant with the PCEP object format defined in [RFC5440]. The P flag and the I flag of the PCEP objects defined in this document SHOULD always be set to 0 on transmission and MUST be ignored on receipt since these flags are exclusively related to path computation requests.
文档中定义的PCEP对象符合[RFC5440]中定义的PCEP对象格式。本文档中定义的PCEP对象的P标志和I标志在传输时应始终设置为0，并且在接收时必须忽略，因为这些标志仅与路径计算请求相关。
Several objects are defined in this section that can be carried within the PCEP PCReq or PCRep messages defined in [RFC5440] in the case of in-band monitoring requests (the PCC requests the computation of the TE LSP in addition to gathering PCE state metrics). In the case of out-of-band monitoring requests, the objects defined in this section are carried within PCMonReq and PCMonRep messages.
本节定义了几个对象，在带内监控请求的情况下，[RFC5440]中定义的PCEP PCReq或PCRep消息中可以携带这些对象（PCC除了收集PCE状态度量外，还请求计算TE LSP）。在带外监控请求的情况下，本节中定义的对象在PCMonReq和PCMonRep消息中进行。
All TLVs carried in objects defined in this document have the TLV format defined in [RFC5440]:
本文件中定义的对象中携带的所有TLV具有[RFC5440]中定义的TLV格式：
o Type: 2 bytes
o 类型：2字节
o Length: 2 bytes
o 长度：2字节
o Value: variable
o 值：变量
A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes specifying the TLV length, and a value field. The Length field defines the length of the value portion in bytes. The TLV is padded to 4-byte alignment; padding is not included in the Length field (so a 3-byte value would have a length of 3, but the total size of the TLV would be 8 bytes). Unrecognized TLVs MUST be ignored.
PCEP对象TLV由类型的2个字节、指定TLV长度的2个字节和一个值字段组成。长度字段以字节为单位定义值部分的长度。TLV填充为4字节对齐；长度字段中不包括填充（因此3字节值的长度为3，但TLV的总大小为8字节）。必须忽略无法识别的TLV。
The MONITORING object MUST be present within PCMonReq and PCMonRep messages (out-of-band monitoring requests) and MAY be carried within PCRep and PCReq messages (in-band monitoring requests). There SHOULD NOT be more than one instance of the MONITORING object in a PCMonReq or PCMonRep message: if more than one instance of the MONITORING object is present, the recipient MUST process the first instance and MUST ignore other instances.
监控对象必须存在于PCMonReq和PCMonRep消息（带外监控请求）中，并且可以在PCRep和PCReq消息（带内监控请求）中携带。PCMonReq或PCMonRep消息中不应存在多个监控对象实例：如果存在多个监控对象实例，则收件人必须处理第一个实例，并且必须忽略其他实例。
The MONITORING object is used to specify the set of requested PCE state metrics.
监视对象用于指定请求的PCE状态度量集。
The MONITORING Object-Class (19) has been assigned by IANA.
IANA已分配监控对象类（19）。
The MONITORING Object-Type (1) has been assigned by IANA.
IANA已分配监控对象类型（1）。
The format of the MONITORING object body is as follows:
监控对象主体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |I|C|P|G|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Monitoring-id-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |I|C|P|G|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Monitoring-id-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 24 bits
标志：24位
The following flags are currently defined:
当前定义了以下标志：
L (Liveness) - 1 bit: when set, this indicates that the state metric of interest is the PCE's liveness and thus the PCE MUST include a PCE-ID object in the corresponding reply. The L bit MUST always be ignored in a PCMonRep or PCRep message.
L（活跃度）-1位：设置时，这表示感兴趣的状态度量是PCE的活跃度，因此PCE必须在相应的回复中包含PCE-ID对象。在PCMonRep或PCRep消息中，必须始终忽略L位。
G (General) - 1 bit: when set, this indicates that the monitoring request is a general monitoring request. When the requested performance metric is specific, the G bit MUST be cleared. The G bit MUST always be ignored in a PCMonRep or PCRep message.
G（常规）-1位：设置时，表示监控请求为常规监控请求。当请求的性能指标是特定的时，必须清除G位。在PCMonRep或PCRep消息中，必须始终忽略G位。
P (Processing Time) - 1 bit: the P bit of the MONITORING object carried in a PCMonReq or a PCReq message is set to indicate that the processing times is a metric of interest. If allowed by policy, a PROC-TIME object MUST be inserted in the corresponding PCMonRep or PCRep message. The P bit MUST always be ignored in a PCMonRep or PCRep message.
P（处理时间）-1位：设置PCMonReq或PCReq消息中携带的监控对象的P位，以指示处理时间是相关度量。如果策略允许，则必须在相应的PCMonRep或PCRep消息中插入PROC-TIME对象。在PCMonRep或PCRep消息中必须始终忽略P位。
C (Overload) - 1 bit: The C bit of the MONITORING object carried in a PCMonReq or a PCReq message is set to indicate that the overload status is a metric of interest, in which case an OVERLOAD object MUST be inserted in the corresponding PCMonRep or PCRep message. The C bit MUST always be ignored in a PCMonRep or PCRep message.
C（过载）-1位：设置PCMonReq或PCReq消息中携带的监控对象的C位，以指示过载状态是一个相关度量，在这种情况下，必须在相应的PCMonRep或PCRep消息中插入过载对象。在PCMonRep或PCRep消息中，必须始终忽略C位。
I (Incomplete) - 1 bit: If a PCE supports a received PCMonReq message and that message does not trigger any policy violation, but the PCE cannot provide any of the set of requested performance metrics for unspecified reasons, the PCE MUST set the I bit. The I bit has no meaning in a request and SHOULD be ignored on receipt.
I（不完整）-1位：如果PCE支持接收到的PCMonReq消息，且该消息不会触发任何策略冲突，但由于未指定的原因，PCE无法提供任何请求的性能指标集，则PCE必须设置I位。I位在请求中没有意义，在收到时应忽略。
Monitoring-id-number (32 bits): The monitoring-id-number value combined with the PCC-REQ-ID identifying the requesting PCC uniquely identifies the monitoring request context. The monitoring-id-number MUST start at a non-zero value and MUST be incremented each time a new monitoring request is sent to a PCE. Each increment SHOULD have a value of 1 and may cause a wrap back to zero. If no reply to a monitoring request is received from the PCE, and the PCC wishes to resend its path computation monitoring request, the same monitoring-id-number MUST be used. Conversely, a different monitoring-id-number MUST be used for different requests sent to a PCE. A PCEP implementation SHOULD checkpoint the Monitoring-id-number of pending monitoring requests in case of restart thus avoiding the reuse of a Monitoring-id-number of an in-process monitoring request.
监控id号（32位）：监控id号值与识别请求PCC的PCC-REQ-id组合，唯一识别监控请求上下文。监控id号必须以非零值开始，并且必须在每次向PCE发送新的监控请求时递增。每个增量的值应为1，并可能导致回折为零。如果没有从PCE接收到对监控请求的回复，并且PCC希望重新发送其路径计算监控请求，则必须使用相同的监控id号。相反，对于发送到PCE的不同请求，必须使用不同的监控id号。PCEP实现应在重启时检查挂起的监视请求的监视id号，从而避免重用进程内监视请求的监视id号。
Unassigned bits are considered as reserved and MUST be set to zero on transmission and ignored on reception.
未分配位被视为保留位，在传输时必须设置为零，在接收时忽略。
No optional TLVs are currently defined.
当前未定义可选的TLV。
The PCC-ID-REQ object is used to specify the IP address of the requesting PCC.
PCC-ID-REQ对象用于指定请求PCC的IP地址。
The PCC-ID-REQ MUST be inserted within a PCReq or a PCMonReq message to specify the IP address of the requesting PCC.
PCC-ID-REQ必须插入PCReq或PCMonReq消息中，以指定请求PCC的IP地址。
Two PCC-ID-REQ objects (for IPv4 and IPv6) are defined. PCC-ID-REQ Object-Class (20) has been assigned by IANA. PCC-ID-REQ Object-Type (1 for IPv4 and 2 for IPv6) has been assigned by IANA.
定义了两个PCC-ID-REQ对象（用于IPv4和IPv6）。IANA已分配PCC-ID-REQ对象类（20）。IANA已分配PCC-ID-REQ对象类型（IPv4为1，IPv6为2）。
The format of the PCC-ID-REQ object body for IPv4 and IPv6 are as follows:
IPv4和IPv6的PCC-ID-REQ对象体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PCC-ID-REQ object body has a fixed length of 4 octets for IPv4 and 16 octets for IPv6.
PCC-ID-REQ对象体的固定长度为IPv4的4个八位字节和IPv6的16个八位字节。
The PCE-ID object is used to specify a PCE's IP address. The PCE-ID object can either be used to specify the list of PCEs for which monitoring data is requested and to specify the IP address of the requesting PCC.
PCE-ID对象用于指定PCE的IP地址。PCE-ID对象可用于指定为其请求监控数据的PCE列表，以及指定请求PCC的IP地址。
A set of PCE-ID objects may be inserted within a PCReq or a PCMonReq message to specify the PCE for which PCE state metrics are requested and in a PCMonRep or a PCRep message to record the IP address of the PCE reporting PCE state metrics or that was involved in the path computation chain.
可以在PCReq或PCMonReq消息中插入一组PCE-ID对象，以指定为其请求PCE状态度量的PCE，并在PCMonRep或PCRep消息中插入一组PCE-ID对象，以记录报告PCE状态度量或涉及路径计算链的PCE的IP地址。
Two PCE-ID objects (for IPv4 and IPv6) are defined. PCE-ID Object-Class (25) has been assigned by IANA. PCE-ID Object-Type (1 for IPv4 and 2 for IPv6) has been assigned by IANA.
定义了两个PCE-ID对象（用于IPv4和IPv6）。IANA已分配PCE-ID对象类（25）。IANA已分配PCE-ID对象类型（IPv4为1，IPv6为2）。
The format of the PCE-ID object body for IPv4 and IPv6 are as follows:
IPv4和IPv6的PCE-ID对象体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 octets for IPv6.
PCE-ID对象主体的固定长度为IPv4的4个八位字节和IPv6的16个八位字节。
When a dynamic discovery mechanism is used for PCE discovery, a PCE advertises its PCE address in the PCE-ADDRESS sub-TLV defined in [RFC5088] and [RFC5089]. A PCC MUST use this address in PCReq and PCMonReq messages and a PCE MUST also use this address in PCRep and PCMonRep messages.
当动态发现机制用于PCE发现时，PCE在[RFC5088]和[RFC5089]中定义的PCE地址子TLV中公布其PCE地址。PCC必须在PCReq和PCMonReq消息中使用此地址，PCE也必须在PCRep和PCMonRep消息中使用此地址。
If allowed by policy, the PCE includes a PROC-TIME object within a PCMonRep or a PCRep message if the P bit of the MONITORING object carried within the corresponding PCMonReq or PCReq message is set. The PROC-TIME object is used to report various processing time related metrics.
如果策略允许，PCE在PCMonRep或PCRep消息中包含PROC-TIME对象，如果设置了相应PCMonReq或PCReq消息中携带的监控对象的P位，则PCE在PCMonRep或PCRep消息中包含PROC-TIME对象。PROC-TIME对象用于报告各种与处理时间相关的度量。
1) Case of general monitoring requests
1) 一般监测请求的情况
A PCC may request processing time metrics for general monitoring requests (e.g., the PCC may want to know the minimum, maximum, and average processing times on a particular PCE). In this case, general requests can only be made by using PCMonReq/PCMonRep messages. The Current-processing-time field (as explained below) is exclusively used for specific monitoring requests and MUST be cleared for general monitoring requests. The algorithms used by a PCE to compute the minimum, maximum, average, and variance of the processing times are out of the scope of this document (a PCE may decide to compute the minimum processing time over a period of time, for the last N path computation requests, etc.).
PCC可以请求用于一般监视请求的处理时间度量（例如，PCC可能想要知道特定PCE上的最小、最大和平均处理时间）。在这种情况下，只能通过使用PCMonReq/PCMonRep消息发出常规请求。当前处理时间字段（如下所述）专门用于特定的监视请求，对于一般监视请求，必须清除该字段。PCE用于计算处理时间的最小值、最大值、平均值和方差的算法不在本文档的范围内（PCE可能决定计算一段时间内的最小处理时间，用于最后N个路径计算请求等）。
2) Case of specific monitoring requests
2) 具体监测请求的情况
In the case of a specific request, the algorithms used by a PCE to compute the Processing-time metrics are out of the scope of this document, but a flag is specified that is used to indicate to the requester whether the processing time value was estimated or computed. The PCE may either (1) estimate the processing time without performing an actual path computation or (2) effectively perform the computation to report the processing time. In the former case, the E bit of the PROC-TIME object MUST be set. The G bit MUST be cleared and the Min-processing-time, Max-processing-time, Average-processing-time, and Variance-processing-time MUST be set to 0x00000000.
在特定请求的情况下，PCE用于计算处理时间度量的算法不在本文档的范围内，但指定了一个标志，用于向请求者指示处理时间值是估计的还是计算的。PCE可以（1）在不执行实际路径计算的情况下估计处理时间，或者（2）有效地执行计算以报告处理时间。在前一种情况下，必须设置PROC-TIME对象的E位。必须清除G位，并且最小处理时间、最大处理时间、平均处理时间和方差处理时间必须设置为0x00000000。
When the processing time is requested in addition to a path computation (case where the MONITORING object is carried within a PCReq message), the PROC-TIME object always reports the actual processing time for that request and thus the E bit MUST be cleared.
当除了路径计算之外还请求处理时间时（监控对象在PCReq消息中携带的情况），PROC-time对象始终报告该请求的实际处理时间，因此必须清除E位。
The PROC-TIME Object-Class (26) has been assigned by IANA.
进程时间对象类（26）已由IANA分配。
The PROC-TIME Object-Type (1) has been assigned by IANA.
进程时间对象类型（1）已由IANA分配。
The format of the PROC-TIME object body is as follows:
PROC-TIME对象体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average-processing time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variance-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average-processing time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variance-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 16 bits - one flag is currently defined:
标志：16位-当前定义了一个标志：
E (Estimated) - 1 bit: when set, this indicates that the reported metric value is based on estimated processing time as opposed to actual computations.
E（估计）-1位：设置时，表示报告的度量值基于估计的处理时间，而不是实际计算。
Unassigned bits are considered as reserved and MUST be set to zero on transmission.
未分配位被视为保留位，在传输时必须设置为零。
Current-processing-time: This field indicates, in milliseconds, the processing time for the path computation of interest characterized in the corresponding PCMonReq message.
当前处理时间：该字段以毫秒为单位指示相应PCMonReq消息中所描述的感兴趣路径计算的处理时间。
Min-processing-time: This field indicates, in milliseconds, the minimum processing time.
最小处理时间：此字段以毫秒为单位指示最小处理时间。
Max-processing-time: This field indicates, in milliseconds, the maximum processing time.
最大处理时间：此字段以毫秒为单位指示最大处理时间。
Average-processing-time: This field indicates, in milliseconds, the average processing time.
平均处理时间：此字段以毫秒为单位指示平均处理时间。
Variance-processing-time: This field indicates, in milliseconds, the variance of the processing times.
差异处理时间：此字段以毫秒为单位指示处理时间的差异。
Since the PCC may potentially use monitoring metrics as input to their PCE selection, it MAY be required to normalize how time metrics (along with others metrics described in further revision of this document) are computed to ensure consistency between the monitoring metrics computed by a set of PCEs.
由于PCC可能会使用监控指标作为其PCE选择的输入，因此可能需要规范时间指标（以及本文件进一步修订版中描述的其他指标）的计算方式，以确保一组PCE计算的监控指标之间的一致性。
The OVERLOAD object is used to report a PCE processing congestion state. Note that "overload" as indicated by this object refers to the processing state of the PCE and its ability to handle new PCEP requests. A PCE is overloaded when it has a backlog of PCEP requests such that it cannot immediately start to process a new request thus leading to waiting times. The overload duration is quantified as being the (estimated) time until the PCE expects to be able to immediately process a new PCEP request.
重载对象用于报告PCE处理拥塞状态。请注意，此对象所指示的“过载”是指PCE的处理状态及其处理新PCEP请求的能力。当PCE积压了PCEP请求，无法立即开始处理新请求，从而导致等待时间过长时，PCE会过载。过载持续时间被量化为PCE期望能够立即处理新PCEP请求之前的（估计）时间。
The OVERLOAD object MUST be present within a PCMonRep or a PCRep message if the C bit of the MONITORING object carried within the corresponding PCMonReq or PCReq message is set and the PCE is experiencing a congested state. The OVERLOAD Object-Class (27) has been assigned by IANA. The overload Object-Type (1) has been assigned by IANA.
如果设置了相应PCMonReq或PCReq消息中携带的监控对象的C位，并且PCE处于拥塞状态，则PCMonRep或PCRep消息中必须存在过载对象。重载对象类（27）已由IANA分配。重载对象类型（1）已由IANA分配。
The format of the CONGESTION object body is as follows:
拥塞对象主体的格式如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Overload Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Overload Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags: 8 bits - No flag is currently defined.
标志：8位-当前未定义标志。
Overload duration - 16 bits: This field indicates the amount of time, in seconds, that the responding PCE expects that it may continue to be overloaded from the time that the response message was generated. The receiver MAY use this value to decide whether or not to send further requests to the same PCE.
过载持续时间-16位：此字段指示响应PCE从生成响应消息时起期望其继续过载的时间量（以秒为单位）。接收机可以使用该值来决定是否向同一PCE发送进一步的请求。
It is worth noting that a PCE along a path computation chain involved in the monitoring request may decide to learn from the overload information received by one of downstream PCEs in the chain.
值得注意的是，沿着涉及监视请求的路径计算链的PCE可以决定从链中下游PCE之一接收的过载信息中学习。
The receipt of a PCMonReq message may trigger a policy violation on some PCE; in which case, the PCE MUST send a PCErr message with Error-type=5 and Error-value=6.
收到PCMonReq消息可能会触发某些PCE上的策略冲突；在这种情况下，PCE必须发送错误类型为5且错误值为6的PCErr消息。
I bit processing: as indicated in Section 4.1, if a PCE supports a received PCMonReq message and that message does not trigger any policy violation, but the PCE cannot provide any of the set of requested performance metrics for unspecified reasons, the PCE MUST set the I bit. Once set, the I bit MUST NOT be changed by a receiving PCE.
I位处理：如第4.1节所述，如果PCE支持接收到的PCMonReq消息，且该消息不会触发任何策略冲突，但由于未指定的原因，PCE无法提供任何请求的性能指标集，则PCE必须设置I位。设置后，接收PCE不得更改I位。
Upon receiving a PCMonReq message:
收到PCMonReq消息后：
1) As specified in [RFC5440], if the PCE does not support the PCMonReq message, the PCE peer MUST send a PCErr message with Error-value=2 (capability not supported). According to the procedure defined in Section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages at a rate equal of greater than specified rate, the PCC/PCE must send a PCEP CLOSE message with close value=5 "Reception of an unacceptable number of unrecognized PCEP messages". In this case, the PCC/PCE must also close the TCP session and must not send any further PCEP messages on the PCEP session.
1) 如[RFC5440]中所述，如果PCE不支持PCMonReq消息，则PCE对等方必须发送错误值为2的PCErr消息（不支持功能）。根据[RFC5440]第6.9节中定义的程序，如果PCC/PCE以大于规定速率的速率接收到未识别的消息，则PCC/PCE必须发送关闭值为5的PCEP关闭消息“接收不可接受数量的未识别PCEP消息”。在这种情况下，PCC/PCE还必须关闭TCP会话，并且不得在PCEP会话上发送任何进一步的PCEP消息。
2) If the PCE supports the PCMonReq message but the monitoring request is prohibited by policy, the PCE must follow the procedure specified in Section 5. As pointed out in Section 4.3, a PCE may still partially satisfy a request, leaving out some of the required data if not allowed by policy.
2) 如果PCE支持PCMonReq消息，但政策禁止监控请求，则PCE必须遵循第5节中规定的程序。正如第4.3节所指出的，PCE仍然可以部分满足请求，如果政策不允许，则会遗漏一些必需的数据。
3) If the PCE supports the PCMonReq and the monitoring request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain. If the PCE is not the last element of the path computation chain, the PCMonReq message is relayed to the next-hop PCE: such a next hop may be either specified by means of a PCE-ID object present in the PCMonReq message or dynamically determined by means of a procedure outside of the scope of this document. Conversely, if the PCE is the last PCE of the path computation chain, the PCE originates a PCMonRep message that contains the requested objects according to the set of requested PCE states metrics listed in the MONITORING object carried in the corresponding PCMonReq message.
3) 如果PCE支持PCMonReq且监控请求未被策略禁止，则接收PCE必须首先确定它是否是路径计算链的最后一个PCE。如果PCE不是路径计算链的最后一个元素，则PCMonReq消息被中继到下一跳PCE：这样的下一跳可以通过PCMonReq消息中存在的PCE-ID对象来指定，或者通过本文档范围之外的过程来动态确定。相反，如果PCE是路径计算链的最后一个PCE，则PCE根据在相应PCMonReq消息中携带的监控对象中列出的一组请求的PCE状态度量来发起包含请求的对象的PCMonRep消息。
Upon receiving a PCReq message that carries a MONITORING and potentially other monitoring objects (e.g., PCE-ID object):
接收到携带监控对象和潜在其他监控对象（例如PCE-ID对象）的PCReq消息后：
1) As specified in [RFC5440], if the PCE does not support (in-band) monitoring, the PCE peer MUST send a PCErr message with Error-value=2 (capability not supported). According to the procedure defined in Section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages at a rate equal or greater than a specified rate, the PCC/PCE must send a PCEP CLOSE message with close value=5 "Reception of an unacceptable number of unrecognized PCEP messages". In this case, the PCC/PCE must also close the TCP session and must not send any further PCEP messages on the PCEP session.
1) 如[RFC5440]中所述，如果PCE不支持（带内）监控，则PCE对等方必须发送错误值为2的PCErr消息（不支持功能）。根据[RFC5440]第6.9节中定义的程序，如果PCC/PCE以等于或大于指定速率的速率接收到未识别的消息，则PCC/PCE必须发送关闭值为5的PCEP关闭消息“接收不可接受数量的未识别PCEP消息”。在这种情况下，PCC/PCE还必须关闭TCP会话，并且不得在PCEP会话上发送任何进一步的PCEP消息。
2) If the PCE supports the monitoring request but the monitoring request is prohibited by policy, the PCE must follow the procedure specified in Section 5. As pointed out in Section 4.3, a PCE may still partially satisfy a request, leaving out some of the required data if not allowed by policy.
2) 如果PCE支持监控请求，但政策禁止监控请求，则PCE必须遵循第5节规定的程序。正如第4.3节所指出的，PCE仍然可以部分满足请求，如果政策不允许，则会遗漏一些必需的数据。
3) If the PCE supports the monitoring request and that request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain. If the PCE is not the last element of the path computation chain, the PCReq message (with the MONITORING object and potentially other monitoring objects such as the PCE-ID) is relayed to the next-hop PCE: such a next hop may be either specified by means of a PCE-ID object present in the PCReq message or dynamically determined by means of a procedure outside of the scope of this document.
3) 如果PCE支持监控请求且该请求未被策略禁止，则接收PCE必须首先确定它是否是路径计算链的最后一个PCE。如果PCE不是路径计算链的最后一个元素，则PCReq消息（带有监控对象和潜在的其他监控对象，如PCE-ID）被中继到下一跳PCE：这种下一跳可以通过PCReq消息中存在的PCE-ID对象来指定，或者通过本文档范围之外的过程来动态确定。
Conversely, if the PCE is the last PCE of the path computation chain, the PCE originates a PCRep message that contains the requested objects according to the set of requested PCE states metrics listed in the MONITORING and potentially other monitoring objects carried in the corresponding PCReq message.
相反，如果PCE是路径计算链的最后一个PCE，则PCE根据监控中列出的请求PCE状态度量集和相应PCReq消息中携带的潜在其他监控对象，发起包含请求对象的PCRep消息。
Upon receiving a PCMonRep message, the PCE processes the request, adds the relevant objects to the PCMonRep message and forwards the PCMonRep message to the upstream requesting PCE or PCC.
收到PCMonRep消息后，PCE处理请求，将相关对象添加到PCMonRep消息，并将PCMonRep消息转发到上游请求PCE或PCC。
Upon receiving a PCRep message that carries monitoring data, the message is processed, additional monitoring data is added according to this specification, and the message is forwarded upstream to the requesting PCE or PCC.
在接收到携带监控数据的PCRep消息后，处理该消息，根据本规范添加额外的监控数据，并将该消息向上游转发到请求的PCE或PCC。
It MUST be possible to configure the activation/deactivation of PCEP monitoring on a PCEP speaker. In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring on a PCE whether or not specific, generic, in-band and out-of-band monitoring requests are allowed. Also, a PCEP implementation SHOULD allow configuring on a PCE a list of authorized state metrics (aliveness, overload, processing time, etc.). This may apply to any session in which the PCEP speaker participates, to a specific session with a given PCEP peer or to a specific group of sessions with a specific group of PCEP peers, for instance, the PCEP peers of a neighbor AS.
必须能够在PCEP扬声器上配置PCEP监控的激活/停用。除了[RFC5440]第8.1节中已列出的参数外，PCEP实现应允许在PCE上配置，无论是否允许特定、通用、带内和带外监控请求。此外，PCEP实现应允许在PCE上配置授权状态度量（有效性、过载、处理时间等）的列表。这可适用于PCEP演讲者参与的任何会话、与给定PCEP对等方的特定会话或与特定PCEP对等方组（例如，邻居AS的PCEP对等方）的特定会话组。
A new MIB Module may be defined that provides local PCE state metrics, as well as state metrics of other PCEs gathered using mechanisms defined in this document.
可以定义一个新的MIB模块，该模块提供本地PCE状态度量，以及使用本文档中定义的机制收集的其他PCE的状态度量。
This document provides mechanisms to monitor the liveliness and performances of a given path computation chain.
本文档提供了监控给定路径计算链的活动性和性能的机制。
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]中已列出的协议外，本文件中定义的机制并不意味着对其他协议的任何要求。
The frequency of PCMonReq messages may impact the operations of PCEs. An implementation SHOULD allow a limit to be placed on the rate of PCMonReq messages sent by a PCEP speaker and processed from a peer. It SHOULD also allow sending a notification when a rate threshold is reached. An implementation SHOULD allow handling PCReq messages with a higher priority than PCMonReq messages. An implementation SHOULD allow the configuration of a second limit for the PCReq message requesting monitoring data.
PCMonReq消息的频率可能会影响PCE的操作。实现应允许对PCEP扬声器发送并从对等机处理的PCMonReq消息的速率进行限制。它还应允许在达到速率阈值时发送通知。实现应允许以比PCMonReq消息更高的优先级处理PCReq消息。实现应允许为请求监控数据的PCReq消息配置第二个限制。
An important concern while processing overload information is to prevent the overload condition on one PCE simply being moved to another PCE. Indeed, there is a risk that the reaction to an indication of overload will act to increase the amount of overload within the network. Furthermore, this may lead to oscillations between PCEs if the overload information is not handled properly.
在处理过载信息时，一个重要的关注点是防止一个PCE上的过载情况简单地移动到另一个PCE。事实上，存在一种风险，即对过载指示的反应将增加网络内的过载量。此外，如果过载信息处理不当，这可能导致PCE之间的振荡。
This section presents some brief guidance on how a PCC (which term includes a PCE making requests of another PCE) should react when it receives an indication that a PCE is overloaded.
本节简要介绍了PCC（该术语包括PCE向另一PCE发出请求）在收到PCE过载指示时应如何作出反应。
When an overload indication is received (on a PCRep message or on a PCMonRep message), it identifies that new PCReq messages sent to the PCE might be subject to a delay equal to the value in the Overload Duration field (when present).
当接收到过载指示（在PCRep消息或PCMonRep消息上）时，它标识发送到PCE的新PCReq消息可能会受到与过载持续时间字段中的值相等的延迟（如果存在）。
It also indicates that PCReq messages already queued at the PCE might be subject to a delay. The PCC must decide how to handle new PCReq messages and what to do about PCReq messages already queued at the PCE.
它还指示已经在PCE排队的PCReq消息可能会受到延迟的影响。PCC必须决定如何处理新的PCReq消息，以及如何处理已经在PCE排队的PCReq消息。
It is RECOMMENDED that a PCC does not cancel a queued PCReq and reissue it to another PCE because of the PCE being overloaded.
建议PCC不要因为PCE过载而取消排队的PCReq并将其重新发送给另一个PCE。
Such behavior is likely to result in overload thrashing as multiple PCCs move the PCE queue to another PCE. This would simply introduce additional delay in the processing of all requests. A PCC MAY choose to cancel a queued PCE request if it is willing to sacrifice the request, maybe reissuing it later (after the overload condition has been determined to have cleared by use of a PCMonReq/Rep exchange).
当多个PCC将PCE队列移动到另一个PCE时，这种行为可能会导致过载振荡。这只会给所有请求的处理带来额外的延迟。PCC可以选择取消排队的PCE请求，如果它愿意牺牲该请求，可以稍后重新发出该请求（在通过使用PCMonReq/Rep交换确定过载条件已清除之后）。
It is then RECOMMENDED to send the cancellation request with a higher priority in order for the overloaded PCE to detect the request cancellation before processing the related request.
然后建议以更高的优先级发送取消请求，以便过载PCE在处理相关请求之前检测到请求取消。
A PCC that is aware of PCE overload at one PCE MAY select a different PCE to service its next PCReq message. In doing so, it is RECOMMENDED that the PCC consider whether the other PCE is overloaded or might be likely to become overloaded by other PCCs similarly directing new PCReq messages.
在一个PCE处意识到PCE过载的PCC可以选择不同的PCE来服务其下一个PCReq消息。在这样做时，建议PCC考虑其他PCE是否过载或可能会被其他PCC过载，类似地指示新PCReq消息。
Furthermore, should the second PCE be also overloaded, it is RECOMMENDED not to make any attempt to switch back to the other PCE without knowing that the first PCE is no longer overloaded.
此外，如果第二个PCE也过载，建议不要在不知道第一个PCE不再过载的情况下尝试切换回另一个PCE。
Each PCEP message has a message type value.
每个PCEP消息都有一个消息类型值。
Two new PCEP (specified in [RFC5440]) messages are defined in this document:
本文件中定义了两条新的PCEP（在[RFC5440]中指定）消息：
Value Description Reference 8 Path Computation Monitoring Request (PCMonReq) This document 9 Path Computation Monitoring Reply (PCMonRep) This document
值说明参考8路径计算监控请求（PCMonReq）本文档9路径计算监控回复（PCMonRep）本文档
Each PCEP object has an Object-Class and an Object-Type. The following new PCEP objects are defined in this document:
每个PCEP对象都有一个对象类和一个对象类型。本文档中定义了以下新的PCEP对象：
Object-Class Value Name Object-Type Reference
对象类值名称对象类型引用
19 MONITORING 1 This document
19.1本文件
20 PCC-REQ-ID 1: IPv4 addresses This document 2: IPv6 addresses
20 PCC-REQ-ID 1:IPv4地址本文档2:IPv6地址
25 PCE-ID 1: IPv4 addresses This document 2: IPv6 addresses This document
25 PCE-ID 1:IPv4地址此文档2:IPv6地址此文档
26 PROC-TIME 1 This document
26过程时间1本文件
27 OVERLOAD 1: overload This document
27重载1：重载此文档
A registry was created for the Error-type and Error-value of the PCEP Error Object.
已为PCEP错误对象的错误类型和错误值创建注册表。
A new Error-value for the PCErr message Error-type=5 (Policy Violation) (see [RFC5440]) is defined in this document.
本文档中定义了PCErr消息错误类型=5（策略冲突）的新错误值（请参阅[RFC5440]）。
Error-type Meaning Error-value Reference
错误类型表示错误值引用
5 Policy violation 6: Monitoring message This document supported but rejected due to policy violation
5策略冲突6：监视消息此文档受支持，但由于策略冲突而被拒绝
A new Error-value for the PCErr message Error-type=6 (Mandatory object missing) (see [RFC5440]) is defined in this document.
本文档中定义了PCErr消息错误类型=6（强制对象缺失）（请参见[RFC5440]）的新错误值。
Error-type Meaning Error-value Reference
错误类型表示错误值引用
6 Mandatory Object 4: MONITORING object This document missing missing
6强制对象4：监控对象本文件缺失
IANA has created a registry to manage the Flag field of the MONITORING object.
IANA已经创建了一个注册表来管理监控对象的标志字段。
New bit numbers may be allocated only by an IETF Review. Each bit should be tracked with the following qualities:
新的位号只能由IETF审查分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability Description
o 能力描述
o Defining RFC
o 定义RFC
Several bits are defined for the MONITORING Object flag field in this document:
本文档中为监控对象标志字段定义了几个位：
Codespace of the Flag field (MONITORING Object) Bit Description Reference 0-18 Unassigned 19 Incomplete This document 20 Overload This document 21 Processing Time This document 22 General This document 23 Liveness This document
标志字段（监控对象）的代码空间位描述参考0-18未分配19不完整本文档20过载本文档21处理时间本文档22概述本文档23活跃度本文档
IANA has created a registry to manage the Flag field of the PROC-TIME object.
IANA创建了一个注册表来管理PROC-TIME对象的标志字段。
New bit numbers may be allocated only by an IETF Review. Each bit should be tracked with the following qualities:
新的位号只能由IETF审查分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability Description
o 能力描述
o Defining RFC
o 定义RFC
One bit is defined for the PROC-TIME Object flag field in this document:
本文档中为PROC-TIME对象标志字段定义了一位：
Codespace of the Flag field (PROC-TIME Object) Bit Description Reference 0-14 Unassigned 15 Estimated This document
本文档中标志字段（PROC-TIME对象）位描述参考0-14未分配15的代码空间
IANA has created a registry to manage the Flag field of the OVERLOAD object.
IANA已经创建了一个注册表来管理重载对象的标志字段。
New bit numbers may be allocated only by an IETF Review. Each bit should be tracked with the following qualities:
新的位号只能由IETF审查分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit)
o 位号（从位0开始计算为最高有效位）
o Capability Description
o 能力描述
o Defining RFC
o 定义RFC
No Flag is currently defined for the OVERLOAD Object flag field in this document.
当前没有为此文档中的重载对象标志字段定义标志。
Codespace of the Flag field (OVERLOAD Object) Bit Description Reference 0-7 Unassigned
标志字段（重载对象）位描述参考0-7的代码空间未分配
The use of monitoring data can be used for various attacks such as denial-of-service (DoS) attacks (for example, by setting the C bit and overload duration field of the OVERLOAD object to stop PCCs from
监视数据的使用可用于各种攻击，例如拒绝服务（DoS）攻击（例如，通过设置过载对象的C位和过载持续时间字段来阻止PCC）
using a PCE). Thus, it is recommended to make use of the security mechanisms discussed in [RFC5440] to secure a PCEP session (authenticity, integrity, privacy, and DoS protection, etc.) to secure the PCMonReq and PCMonRep messages and PCE state metric objects defined in this document. An implementation SHOULD allow limiting the rate at which PCMonReq or PCReq messages carrying monitoring requests received from a specific peer are processed (input shaping) as discussed in Section 10.7.2 of [RFC5440], or from another domain (see also Section 7.6).
使用PCE）。因此，建议使用[RFC5440]中讨论的安全机制来保护PCEP会话（真实性、完整性、隐私和DoS保护等），以保护本文档中定义的PCMonReq和PCMonRep消息以及PCE状态度量对象。如[RFC5440]第10.7.2节所述，实现应允许限制处理从特定对等方接收的PCMonReq或承载监控请求的PCReq消息的速率（输入整形），或限制从另一个域接收的PCMonReq或PCReq消息的速率（另见第7.6节）。
The authors would like to thank Eiji Oki, Mach Chen, Fabien Verhaeghe, Dimitri Papadimitriou, and Francis Dupont for their useful comments. Special thanks to Adrian Farrel for his detailed review.
作者要感谢Oki Eiji、Mach Chen、Fabien Verhaeghe、Dimitri Papadimitriou和Francis Dupont的有用评论。特别感谢阿德里安·法雷尔的详细评论。
[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月。
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009.
[RFC5521]Oki，E.，Takeda，T.，和A.Farrel，“路由排除的路径计算元素通信协议（PCEP）扩展”，RFC 55212009年4月。
[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月。
[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月。
[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月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）过程”，RFC 54412009年4月。
Authors' Addresses
作者地址
JP. Vasseur (editor) Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
JP。瓦瑟尔（编辑）思科系统公司，美国马萨诸塞州博克斯堡马萨诸塞大道1414号，邮编01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
JL. Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion 22307 France
JL。法国勒鲁电信2号，皮埃尔·马津·拉尼翁大街22307号，法国
EMail: jeanlouis.leroux@orange-ftgroup.com
EMail: jeanlouis.leroux@orange-ftgroup.com
Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Japan
Yuichi Ikejiri NTT通信公司1-1-6，日本东京千代田区内石湾町100-8019
EMail: y.ikejiri@ntt.com
EMail: y.ikejiri@ntt.com