Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 8233 Q. Wu
Category: Standards Track Huawei
ISSN: 2070-1721 V. Manral
Nano Sec Co
Z. Ali
Cisco Systems
K. Kumaki
KDDI Corporation
September 2017
Internet Engineering Task Force (IETF) D. Dhody
Request for Comments: 8233 Q. Wu
Category: Standards Track Huawei
ISSN: 2070-1721 V. Manral
Nano Sec Co
Z. Ali
Cisco Systems
K. Kumaki
KDDI Corporation
September 2017
Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)
路径计算元素通信协议（PCEP）的扩展，用于计算服务感知标签交换路径（LSP）
Abstract
摘要
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation.
在某些网络中，例如但不限于金融信息网络（例如股票市场数据提供商），网络性能标准（例如延迟）对于数据路径选择的重要性与其他指标和约束一样。这些指标与客户和服务提供商之间的服务级别协议（SLA）相关。链路带宽利用率（实际转发中链路的总带宽）是路径计算过程中考虑的另一个重要因素。
IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation.
IGP流量工程（TE）度量扩展分别描述了通过OSPF和is-is分发网络性能信息的机制。路径计算元素通信协议（PCEP）为路径计算元素（PCE）提供响应于路径计算客户端（PCC）请求执行路径计算的机制。本文档描述了对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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8233.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8233.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Terminology .....................................................4
3. PCEP Extensions .................................................5
3.1. Extensions to METRIC Object ................................5
3.1.1. Path Delay Metric ...................................6
3.1.1.1. Path Delay Metric Value ....................7
3.1.2. Path Delay Variation Metric .........................7
3.1.2.1. Path Delay Variation Metric Value ..........8
3.1.3. Path Loss Metric ....................................8
3.1.3.1. Path Loss Metric Value .....................9
3.1.4. Non-Understanding / Non-Support of
Service-Aware Path Computation ......................9
3.1.5. Mode of Operation ..................................10
3.1.5.1. Examples ..................................11
3.1.6. Point-to-Multipoint (P2MP) .........................11
3.1.6.1. P2MP Path Delay Metric ....................11
3.1.6.2. P2MP Path Delay Variation Metric ..........12
3.1.6.3. P2MP Path Loss Metric .....................12
3.2. Bandwidth Utilization .....................................12
3.2.1. Link Bandwidth Utilization (LBU) ...................12
3.2.2. Link Reserved Bandwidth Utilization (LRBU) .........13
3.2.3. Bandwidth Utilization (BU) Object ..................13
3.2.3.1. Elements of Procedure .....................14
3.3. Objective Functions .......................................15
4. Stateful PCE and PCE Initiated LSPs ............................16
5. PCEP Message Extension .........................................17
5.1. The PCReq Message .........................................17
5.2. The PCRep Message .........................................18
5.3. The PCRpt Message .........................................19
6. Other Considerations ...........................................20
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Terminology .....................................................4
3. PCEP Extensions .................................................5
3.1. Extensions to METRIC Object ................................5
3.1.1. Path Delay Metric ...................................6
3.1.1.1. Path Delay Metric Value ....................7
3.1.2. Path Delay Variation Metric .........................7
3.1.2.1. Path Delay Variation Metric Value ..........8
3.1.3. Path Loss Metric ....................................8
3.1.3.1. Path Loss Metric Value .....................9
3.1.4. Non-Understanding / Non-Support of
Service-Aware Path Computation ......................9
3.1.5. Mode of Operation ..................................10
3.1.5.1. Examples ..................................11
3.1.6. Point-to-Multipoint (P2MP) .........................11
3.1.6.1. P2MP Path Delay Metric ....................11
3.1.6.2. P2MP Path Delay Variation Metric ..........12
3.1.6.3. P2MP Path Loss Metric .....................12
3.2. Bandwidth Utilization .....................................12
3.2.1. Link Bandwidth Utilization (LBU) ...................12
3.2.2. Link Reserved Bandwidth Utilization (LRBU) .........13
3.2.3. Bandwidth Utilization (BU) Object ..................13
3.2.3.1. Elements of Procedure .....................14
3.3. Objective Functions .......................................15
4. Stateful PCE and PCE Initiated LSPs ............................16
5. PCEP Message Extension .........................................17
5.1. The PCReq Message .........................................17
5.2. The PCRep Message .........................................18
5.3. The PCRpt Message .........................................19
6. Other Considerations ...........................................20
6.1. Inter-domain Path Computation .............................20
6.1.1. Inter-AS Links .....................................20
6.1.2. Inter-Layer Path Computation .......................20
6.2. Reoptimizing Paths ........................................21
7. IANA Considerations ............................................21
7.1. METRIC Types ..............................................21
7.2. New PCEP Object ...........................................22
7.3. BU Object .................................................22
7.4. OF Codes ..................................................22
7.5. New Error-Values ..........................................23
8. Security Considerations ........................................23
9. Manageability Considerations ...................................24
9.1. Control of Function and Policy ............................24
9.2. Information and Data Models ...............................24
9.3. Liveness Detection and Monitoring .........................24
9.4. Verify Correct Operations .................................24
9.5. Requirements on Other Protocols ...........................24
9.6. Impact on Network Operations ..............................24
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................26
Appendix A. PCEP Requirements .....................................28
Acknowledgments ...................................................29
Contributors ......................................................30
Authors' Addresses ................................................31
6.1. Inter-domain Path Computation .............................20
6.1.1. Inter-AS Links .....................................20
6.1.2. Inter-Layer Path Computation .......................20
6.2. Reoptimizing Paths ........................................21
7. IANA Considerations ............................................21
7.1. METRIC Types ..............................................21
7.2. New PCEP Object ...........................................22
7.3. BU Object .................................................22
7.4. OF Codes ..................................................22
7.5. New Error-Values ..........................................23
8. Security Considerations ........................................23
9. Manageability Considerations ...................................24
9.1. Control of Function and Policy ............................24
9.2. Information and Data Models ...............................24
9.3. Liveness Detection and Monitoring .........................24
9.4. Verify Correct Operations .................................24
9.5. Requirements on Other Protocols ...........................24
9.6. Impact on Network Operations ..............................24
10. References ....................................................25
10.1. Normative References .....................................25
10.2. Informative References ...................................26
Appendix A. PCEP Requirements .....................................28
Acknowledgments ...................................................29
Contributors ......................................................30
Authors' Addresses ................................................31
Real-time network performance information is becoming critical in the path computation in some networks. Mechanisms to measure latency, delay variation, and packet loss in an MPLS network are described in [RFC6374]. It is important that latency, delay variation, and packet loss are considered during the path selection process, even before the Label Switched Path (LSP) is set up.
在某些网络中，实时网络性能信息在路径计算中变得至关重要。在MPLS网络中测量延迟、延迟变化和数据包丢失的机制在[RFC6374]中描述。在路径选择过程中，即使在设置标签交换路径（LSP）之前，也必须考虑延迟、延迟变化和数据包丢失。
Link bandwidth utilization based on real-time traffic along the path is also becoming critical during path computation in some networks. Thus, it is important that the link bandwidth utilization is factored in during the path computation.
在某些网络中，基于路径实时流量的链路带宽利用率在路径计算过程中也变得至关重要。因此，在路径计算期间考虑链路带宽利用率是很重要的。
The Traffic Engineering Database (TED) is populated with network performance information like link latency, delay variation, packet loss, as well as parameters related to bandwidth (residual bandwidth, available bandwidth, and utilized bandwidth) via TE Metric Extensions in OSPF [RFC7471] or IS-IS [RFC7810] or via a management system. [RFC7823] describes how a Path Computation Element (PCE) [RFC4655] can use that information for path selection for explicitly routed LSPs.
流量工程数据库（TED）通过OSPF[RFC7471]或is-is[RFC7810]中的TE度量扩展或通过管理系统填充网络性能信息，如链路延迟、延迟变化、数据包丢失，以及与带宽（剩余带宽、可用带宽和利用带宽）相关的参数。[RFC7823]描述了路径计算元素（PCE）[RFC4655]如何将该信息用于显式路由LSP的路径选择。
A Path Computation Client (PCC) can request a PCE to provide a path meeting end-to-end network performance criteria. This document extends the Path Computation Element Communication Protocol (PCEP) [RFC5440] to handle network performance constraints that include any combination of latency, delay variation, packet loss, and bandwidth utilization constraints.
路径计算客户端（PCC）可以请求PCE提供满足端到端网络性能标准的路径。本文档扩展了路径计算元素通信协议（PCEP）[RFC5440]以处理网络性能约束，包括延迟、延迟变化、数据包丢失和带宽利用率约束的任意组合。
[RFC7471] and [RFC7810] describe various considerations regarding:
[RFC7471]和[RFC7810]描述了与以下各项有关的各种注意事项：
o Announcement thresholds and filters
o 公告阈值和过滤器
o Announcement suppression
o 公告抑制
o Announcement periodicity and network stability
o 公告周期与网络稳定性
The first two provide configurable mechanisms to bound the number of re-advertisements in IGP. The third provides a way to throttle announcements. Section 1.2 of [RFC7823] also describes the oscillation and stability considerations while advertising and considering service-aware information.
前两个提供了可配置的机制来限制IGP中的重新播发数量。第三种方法提供了限制公告的方法。[RFC7823]的第1.2节还描述了广告和考虑服务感知信息时的振荡和稳定性注意事项。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The following terminology is used in this document.
本文件使用以下术语。
IGP: Interior Gateway Protocol; either of the two routing protocols, Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).
IGP：内部网关协议；两种路由协议之一，开放最短路径优先（OSPF）或中间系统到中间系统（IS-IS）。
IS-IS: Intermediate System to Intermediate System
IS-IS：中间系统至中间系统
LBU: Link Bandwidth Utilization (see Section 3.2.1)
LBU：链路带宽利用率（见第3.2.1节）
LRBU: Link Reserved Bandwidth Utilization (see Section 3.2.2)
LRBU：链路预留带宽利用率（见第3.2.2节）
MPLP: Minimum Packet Loss Path (see Section 3.3)
MPLP：最小丢包路径（见第3.3节）
MRUP: Maximum Reserved Under-Utilized Path (see Section 3.3)
MRUP：最大保留未充分利用路径（见第3.3节）
MUP: Maximum Under-Utilized Path (see Section 3.3)
MUP：最大未利用路径（见第3.3节）
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.). (See [RFC5541].)
目标函数；用于计算单个路径（例如，路径成本最小化）或用于同步计算一组路径（例如，总带宽消耗最小化等）的一组或多个优化标准。（见[RFC5541]。）
OSPF: Open Shortest Path First
开放最短路径优先
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：路径计算单元；能够基于网络图计算网络路径或路由并应用计算约束的实体（组件、应用程序或网络节点）。
RSVP: Resource Reservation Protocol
资源预留协议
TE: Traffic Engineering
交通工程
TED: Traffic Engineering Database
交通工程数据库
This section defines PCEP extensions (see [RFC5440]) for requirements outlined in Appendix A. The proposed solution is used to support network performance and service-aware path computation.
本节针对附录A中概述的要求定义了PCEP扩展（见[RFC5440]）。建议的解决方案用于支持网络性能和服务感知路径计算。
The METRIC object is defined in Section 7.8 of [RFC5440], comprising metric-value and metric-type (T field), and a flags field, comprising a number of bit flags (B bit and P bit). This document defines the following types for the METRIC object.
[RFC5440]第7.8节定义了度量对象，包括度量值和度量类型（T字段）以及一个标志字段，该字段包括许多位标志（B位和P位）。本文档定义了度量对象的以下类型。
o T=12: Path Delay metric (Section 3.1.1)
o T=12：路径延迟度量（第3.1.1节）
o T=13: Path Delay Variation metric (Section 3.1.2)
o T=13：路径延迟变化度量（第3.1.2节）
o T=14: Path Loss metric (Section 3.1.3)
o T=14：路径损耗指标（第3.1.3节）
o T=15: P2MP Path Delay metric (Section 3.1.6.1)
o T=15:P2MP路径延迟度量（第3.1.6.1节）
o T=16: P2MP Path Delay Variation metric (Section 3.1.6.2)
o T=16:P2MP路径延迟变化度量（第3.1.6.2节）
o T=17: P2MP Path Loss metric (Section 3.1.6.3)
o T=17:P2MP路径损耗指标（第3.1.6.3节）
The following terminology is used and expanded along the way.
在此过程中使用并扩展了以下术语。
o A network comprises of a set of N links {Li, (i=1...N)}.
o 网络由一组N个链路{Li，（i=1…N）}组成。
o A path P of a point-to-point (P2P) LSP is a list of K links {Lpi,(i=1...K)}.
o 点到点（P2P）LSP的路径P是K个链路的列表{Lpi，（i=1…K）}。
The Link Delay metric is defined in [RFC7471] and [RFC7810] as "Unidirectional Link Delay". The Path Delay metric type of the METRIC object in PCEP represents the sum of the Link Delay metric of all links along a P2P path. Specifically, extending on the above-mentioned terminology:
链路延迟度量在[RFC7471]和[RFC7810]中定义为“单向链路延迟”。PCEP中度量对象的路径延迟度量类型表示沿P2P路径的所有链路的链路延迟度量之和。具体而言，扩展上述术语：
o A Link Delay metric of link L is denoted D(L).
o 链路L的链路延迟度量表示为D（L）。
o A Path Delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}.
o P2P路径P=Sum{D（Lpi），（i=1…K）}的路径延迟度量。
This is as per the sum of means composition function (Section 4.2.5 of [RFC6049]). Section 1.2 of [RFC7823] describes oscillation and stability considerations, and Section 2.1 of [RFC7823] describes the calculation of the end-to-end Path Delay metric. Further, Section 4.2.9 of [RFC6049] states when this composition function may fail.
这是根据均值和合成函数（RFC6049第4.2.5节）确定的。[RFC7823]的第1.2节描述了振荡和稳定性注意事项，[RFC7823]的第2.1节描述了端到端路径延迟度量的计算。此外，[RFC6049]第4.2.9节规定了该合成功能可能失败的时间。
Metric Type T=12: Path Delay metric
度量类型T=12：路径延迟度量
A PCC MAY use the Path Delay metric in a Path Computation Request (PCReq) message to request a path meeting the end-to-end latency requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path Delay metric that must not be exceeded for
PCC可以在路径计算请求（PCReq）消息中使用路径延迟度量来请求满足端到端延迟要求的路径。在这种情况下，必须将B位设置为建议路径延迟度量的界限（最大值），该界限不得超过
the PCC to consider the computed path as acceptable. The Path Delay metric must be less than or equal to the value specified in the metric-value field.
PCC将计算路径视为可接受的。路径延迟度量必须小于或等于度量值字段中指定的值。
A PCC can also use this metric to ask PCE to optimize the path delay during path computation. In this case, the B bit MUST be cleared.
PCC还可以使用该度量来要求PCE在路径计算期间优化路径延迟。在这种情况下，必须清除B位。
A PCE MAY use the Path Delay metric in a Path Computation Reply (PCRep) message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed Path Delay metric to the PCC.
在PCE不能计算满足该约束的路径的情况下，PCE可以在路径计算应答（PCRep）消息中使用路径延迟度量以及无路径对象。PCE还可以使用该度量将计算出的路径延迟度量发送到PCC。
[RFC7471] and [RFC7810] define "Unidirectional Link Delay Sub-TLV" to advertise the link delay in microseconds in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). Consequently, the encoding for the Path Delay metric value is quantified in units of microseconds and encoded in IEEE floating point format. The conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision.
[RFC7471]和[RFC7810]定义“单向链路延迟子TLV”，以在24位字段中以微秒为单位公布链路延迟。[RFC5440]使用以IEEE浮点格式编码的32位度量值定义度量对象（请参见[IEEE.754]）。因此，路径延迟度量值的编码以微秒为单位进行量化，并以IEEE浮点格式进行编码。从24位整数到32位IEEE浮点的转换可能会导致精度损失。
The Link Delay Variation metric is defined in [RFC7471] and [RFC7810] as "Unidirectional Delay Variation". The Path Delay Variation metric type of the METRIC object in PCEP encodes the sum of the Link Delay Variation metric of all links along the path. Specifically, extending on the above-mentioned terminology:
链路延迟变化度量在[RFC7471]和[RFC7810]中定义为“单向延迟变化”。PCEP中度量对象的路径延迟变化度量类型对沿路径的所有链路的链路延迟变化度量之和进行编码。具体而言，扩展上述术语：
o A delay variation of link L is denoted DV(L) (average delay variation for link L).
o 链路L的延迟变化表示为DV（L）（链路L的平均延迟变化）。
o A Path Delay Variation metric for the P2P path P = Sum {DV(Lpi), (i=1...K)}.
o P2P路径P=Sum{DV（Lpi），（i=1…K）}的路径延迟变化度量。
Section 1.2 of [RFC7823] describes oscillation and stability considerations, and Section 2.1 of [RFC7823] describes the calculation of the end-to-end Path Delay Variation metric. Further, Section 4.2.9 of [RFC6049] states when this composition function may fail.
[RFC7823]的第1.2节描述了振荡和稳定性考虑，而[RFC7823]的第2.1节描述了端到端路径延迟变化度量的计算。此外，[RFC6049]第4.2.9节规定了该合成功能可能失败的时间。
Note that the IGP advertisement for link attributes includes the average delay variation over a period of time. An implementation, therefore, MAY use the sum of the average delay variation of links along a path to derive the delay variation of the path. An end-to-end bound on delay variation is typically used as constraint
注意，链路属性的IGP广告包括一段时间内的平均延迟变化。因此，实现可以使用沿路径的链路的平均延迟变化之和来导出路径的延迟变化。延迟变化的端到端界限通常用作约束
in the path computation. An implementation MAY also use some enhanced composition function for computing the delay variation of a path with better accuracy.
在路径计算中。一种实现还可以使用一些增强的合成函数来更精确地计算路径的延迟变化。
Metric Type T=13: Path Delay Variation metric
度量类型T=13：路径延迟变化度量
A PCC MAY use the Path Delay Variation metric in a PCReq message to request a path meeting the path delay variation requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path Delay Variation metric that must not be exceeded for the PCC to consider the computed path as acceptable. The path delay variation must be less than or equal to the value specified in the metric-value field.
PCC可以在PCReq消息中使用路径延迟变化度量来请求满足路径延迟变化要求的路径。在这种情况下，必须设置B位来建议对于PCC必须超过的路径延迟变化度量的约束（最大值），以考虑所计算的路径为可接受的。路径延迟变化必须小于或等于“度量值”字段中指定的值。
A PCC can also use this metric to ask the PCE to optimize the path delay variation during path computation. In this case, the B flag MUST be cleared.
PCC还可以使用该度量来要求PCE在路径计算期间优化路径延迟变化。在这种情况下，必须清除B标志。
A PCE MAY use the Path Delay Variation metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end-to-end Path Delay Variation metric to the PCC.
在PCE不能计算满足该约束的路径的情况下，PCE可以在PCRep消息中使用路径延迟变化度量以及无路径对象。PCE还可以使用该度量将计算出的端到端路径延迟变化度量发送到PCC。
[RFC7471] and [RFC7810] define "Unidirectional Delay Variation Sub-TLV" to advertise the link delay variation in microseconds in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). Consequently, the encoding for the Path Delay Variation metric value is quantified in units of microseconds and encoded in IEEE floating point format. The conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision.
[RFC7471]和[RFC7810]定义“单向延迟变化子TLV”，以在24位字段中以微秒为单位公布链路延迟变化。[RFC5440]使用以IEEE浮点格式编码的32位度量值定义度量对象（请参见[IEEE.754]）。因此，路径延迟变化度量值的编码以微秒为单位进行量化，并以IEEE浮点格式进行编码。从24位整数到32位IEEE浮点的转换可能会导致精度损失。
[RFC7471] and [RFC7810] define "Unidirectional Link Loss". The Path Loss (as a packet percentage) metric type of the METRIC object in PCEP encodes a function of the unidirectional loss metrics of all links along a P2P path. The end-to-end packet loss for the path is represented by this metric. Specifically, extending on the above mentioned terminology:
[RFC7471]和[RFC7810]定义了“单向链路损耗”。PCEP中度量对象的路径丢失（作为分组百分比）度量类型编码沿P2P路径的所有链路的单向丢失度量的函数。路径的端到端数据包丢失由该度量表示。具体而言，扩展上述术语：
o The percentage link loss of link L is denoted PL(L).
o 链路L的链路损耗百分比表示为PL（L）。
o The fractional link loss of link L is denoted FL(L) = PL(L)/100.
o 链路L的部分链路损耗表示为FL（L）=PL（L）/100。
o The percentage Path Loss metric for the P2P path P = (1 - ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100 for a path P with links Lp1 to LpK.
o 对于具有链路Lp1到LpK的路径P，P2P路径P的百分比路径损耗度量=（1-（（1-FL（Lp1））*（1-FL（Lp2））*…*（1-FL（LpK）））*100。
This is as per the composition function described in Section 5.1.5 of [RFC6049].
这符合[RFC6049]第5.1.5节所述的合成功能。
Metric Type T=14: Path Loss metric
度量类型T=14：路径损耗度量
A PCC MAY use the Path Loss metric in a PCReq message to request a path meeting the end-to-end packet loss requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path Loss metric that must not be exceeded for the PCC to consider the computed path as acceptable. The Path Loss metric must be less than or equal to the value specified in the metric-value field.
PCC可以使用PCReq消息中的路径丢失度量来请求满足端到端分组丢失要求的路径。在这种情况下，必须设置B位来建议对于PCC必须超过的路径损耗度量的约束（最大值），以考虑所计算的路径为可接受的。路径损耗度量必须小于或等于“度量值”字段中指定的值。
A PCC can also use this metric to ask the PCE to optimize the path loss during path computation. In this case, the B flag MUST be cleared.
PCC还可以使用该度量来要求PCE在路径计算期间优化路径损耗。在这种情况下，必须清除B标志。
A PCE MAY use the Path Loss metric in a PCRep message along with a NO-PATH object in the case where the PCE cannot compute a path meeting this constraint. A PCE can also use this metric to send the computed end-to-end Path Loss metric to the PCC.
在PCE无法计算满足此约束的路径的情况下，PCE可以在PCRep消息中使用路径损失度量以及无路径对象。PCE还可以使用该度量将计算出的端到端路径损耗度量发送到PCC。
[RFC7471] and [RFC7810] define "Unidirectional Link Loss Sub-TLV" to advertise the link loss in percentage in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). Consequently, the encoding for the Path Loss metric value is quantified as a percentage and encoded in IEEE floating point format.
[RFC7471]和[RFC7810]定义了“单向链路损耗子TLV”，以在24位字段中以百分比的形式公布链路损耗。[RFC5440]使用以IEEE浮点格式编码的32位度量值定义度量对象（请参见[IEEE.754]）。因此，路径损耗度量值的编码被量化为百分比并以IEEE浮点格式编码。
3.1.4. Non-Understanding / Non-Support of Service-Aware Path Computation
3.1.4. 不理解/不支持服务感知路径计算
If a PCE receives a PCReq message containing a METRIC object with a type defined in this document, and the PCE does not understand or support that metric type, and the P bit is clear in the METRIC object header, then the PCE SHOULD simply ignore the METRIC object as per the processing specified in [RFC5440].
如果PCE接收到包含本文档中定义类型的度量对象的PCReq消息，且PCE不理解或不支持该度量类型，且度量对象标题中的P位为空，则PCE应根据[RFC5440]中指定的处理忽略该度量对象。
If the PCE does not understand the new METRIC type, and the P bit is set in the METRIC object header, then the PCE MUST send a PCEP Error (PCErr) message containing a PCEP-ERROR Object with Error-Type = 4 (Not supported object) and Error-value = 4 (Unsupported parameter) [RFC5440][RFC5441].
如果PCE不理解新的度量类型，并且在度量对象标头中设置了P位，则PCE必须发送一条PCEP Error（PCErr）消息，其中包含错误类型为4（不支持的对象）且错误值为4（不支持的参数）[RFC5440][RFC5441]的PCEP-Error对象。
If the PCE understands but does not support the new METRIC type, and the P bit is set in the METRIC object header, then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 4 (Not supported object) with Error-value = 5 (Unsupported network performance constraint). The path computation request MUST then be canceled.
如果PCE理解但不支持新的度量类型，并且在度量对象标头中设置了P位，则PCE必须发送PCErr消息，其中包含错误类型为4（不支持的对象）且错误值为5（不支持的网络性能约束）的PCEP-ERROR对象。然后必须取消路径计算请求。
If the PCE understands the new METRIC type, but the local policy has been configured on the PCE to not allow network performance constraint, and the P bit is set in the METRIC object header, then the PCE MUST send a PCErr message containing a PCEP-ERROR Object with Error-Type = 5 (Policy violation) with Error-value = 8 (Not allowed network performance constraint). The path computation request MUST then be canceled.
如果PCE了解新的度量类型，但PCE上已将本地策略配置为不允许网络性能约束，并且在度量对象标头中设置了P位，则PCE必须发送一条PCErr消息，其中包含错误类型为5（策略冲突）且错误值为8的PCEP-ERROR对象（不允许网络性能约束）。然后必须取消路径计算请求。
As explained in [RFC5440], the METRIC object is optional and can be used for several purposes. In a PCReq message, a PCC MAY insert one or more METRIC objects:
如[RFC5440]所述，公制对象是可选的，可用于多种用途。在PCReq消息中，PCC可以插入一个或多个度量对象：
o To indicate the metric that MUST be optimized by the path computation algorithm (path delay, path delay variation, or path loss).
o 指示必须通过路径计算算法优化的度量（路径延迟、路径延迟变化或路径损失）。
o To indicate a bound on the METRIC (path delay, path delay variation, or path loss) that MUST NOT be exceeded for the path to be considered as acceptable by the PCC.
o 指示度量（路径延迟、路径延迟变化或路径损失）的界限，该界限不得超过PCC认为可接受的路径。
In a PCRep message, the PCE MAY insert the METRIC object with an Explicit Route Object (ERO) so as to provide the METRIC (path delay, path delay variation, or path loss) for the computed path. The PCE MAY also insert the METRIC object with a NO-PATH object to indicate that the metric constraint could not be satisfied.
在PCRep消息中，PCE可以插入具有显式路由对象（ERO）的度量对象，以便为计算出的路径提供度量（路径延迟、路径延迟变化或路径损失）。PCE还可以插入带有无路径对象的度量对象，以指示无法满足度量约束。
The path computation algorithmic aspects used by the PCE to optimize a path with respect to a specific metric are outside the scope of this document.
PCE用于针对特定度量优化路径的路径计算算法方面超出了本文档的范围。
All the rules of processing the METRIC object as explained in [RFC5440] are applicable to the new metric types as well.
[RFC5440]中解释的处理度量对象的所有规则也适用于新的度量类型。
If a PCC sends a path computation request to a PCE where the metric to optimize is the path delay and the path loss must not exceed the value of M, then two METRIC objects are inserted in the PCReq message:
如果PCC向PCE发送路径计算请求，其中要优化的度量是路径延迟，且路径损失不得超过M值，则在PCReq消息中插入两个度量对象：
o First METRIC object with B=0, T=12, C=1, metric-value=0x0000
o B=0、T=12、C=1、度量值=0x0000的第一个度量对象
o Second METRIC object with B=1, T=14, metric-value=M
o 第二个度量对象，B=1，T=14，度量值=M
As per [RFC5440], if a path satisfying the set of constraints can be found by the PCE and there is no policy that prevents the return of the computed metric, then the PCE inserts one METRIC object with B=0, T=12, metric-value= computed path delay. Additionally, the PCE MAY insert a second METRIC object with B=1, T=14, metric-value=computed path loss.
根据[RFC5440]，如果PCE可以找到满足约束集的路径，并且没有阻止返回计算度量的策略，则PCE插入一个B=0、T=12、度量值=计算路径延迟的度量对象。另外，PCE可以插入B＝1、T＝14、度量值＝计算路径损耗的第二度量对象。
This section defines the following types for the METRIC object to be used for the P2MP TE LSPs.
本节定义了用于P2MP TE LSP的度量对象的以下类型。
The P2MP Path Delay metric type of the METRIC object in PCEP encodes the Path Delay metric for the destination that observes the worst delay metric among all destinations of the P2MP tree. Specifically, extending on the above-mentioned terminology:
PCEP中度量对象的P2MP路径延迟度量类型对在P2MP树的所有目的地中观察到最差延迟度量的目的地的路径延迟度量进行编码。具体而言，扩展上述术语：
o A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)}.
o P2MP树T包括一组M个目的地{Dest_j，（j=1…M）}。
o The P2P Path Delay metric of the path to destination Dest_j is denoted by PDM(Dest_j).
o 到目的地Dest_j的路径的P2P路径延迟度量由PDM（Dest_j）表示。
o The P2MP Path Delay metric for the P2MP tree T = Maximum {PDM(Dest_j), (j=1...M)}.
o P2MP树的P2MP路径延迟度量T=Maximum{PDM（Dest_j），（j=1…M）}。
The value for the P2MP Path Delay metric type (T) = 15.
P2MP路径延迟度量类型（T）的值=15。
The P2MP Path Delay Variation metric type of the METRIC object in PCEP encodes the Path Delay Variation metric for the destination that observes the worst delay variation metric among all destinations of the P2MP tree. Specifically, extending on the above-mentioned terminology:
PCEP中度量对象的P2MP路径延迟变化度量类型对观察P2MP树所有目的地中最差延迟变化度量的目的地的路径延迟变化度量进行编码。具体而言，扩展上述术语：
o A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)}.
o P2MP树T包括一组M个目的地{Dest_j，（j=1…M）}。
o The P2P Path Delay Variation metric of the path to the destination Dest_j is denoted by PDVM(Dest_j).
o 到目的地Dest_j的路径的P2P路径延迟变化度量由PDVM（Dest_j）表示。
o The P2MP Path Delay Variation metric for the P2MP tree T = Maximum {PDVM(Dest_j), (j=1...M)}.
o P2MP树的P2MP路径延迟变化度量T=Maximum{PDVM（Dest_j），（j=1…M）}。
The value for the P2MP Path Delay Variation metric type (T) = 16.
P2MP路径延迟变化度量类型（T）的值=16。
The P2MP Path Loss metric type of the METRIC object in PCEP encodes the path packet loss metric for the destination that observes the worst packet loss metric among all destinations of the P2MP tree. Specifically, extending on the above-mentioned terminology:
PCEP中度量对象的P2MP路径丢失度量类型为在P2MP树的所有目的地中观察到最差分组丢失度量的目的地的路径分组丢失度量进行编码。具体而言，扩展上述术语：
o A P2MP tree T comprises of a set of M destinations {Dest_j, (j=1...M)}.
o P2MP树T由一组M个目的地{Dest_j，（j=1…M）}组成。
o The P2P Path Loss metric of the path to destination Dest_j is denoted by PLM(Dest_j).
o 到目的地Dest_j的路径的P2P路径损失度量由PLM（Dest_j）表示。
o The P2MP Path Loss metric for the P2MP tree T = Maximum {PLM(Dest_j), (j=1...M)}.
o P2MP树的P2MP路径损耗度量T=Maximum{PLM（Dest_j），（j=1…M）}。
The value for the P2MP Path Loss metric type (T) = 17.
P2MP路径损耗度量类型（T）的值=17。
The LBU on a link, forwarding adjacency, or bundled link is populated in the TED ("Unidirectional Utilized Bandwidth Sub-TLV" in [RFC7471] and [RFC7810]). For a link or forwarding adjacency, the bandwidth utilization represents the actual utilization of the link (i.e., as measured in the router). For a bundled link, the bandwidth
链路、转发邻接或捆绑链路上的LBU填充在TED中（[RFC7471]和[RFC7810]中的“单向利用带宽子TLV”）。对于链路或转发邻接，带宽利用率表示链路的实际利用率（即，在路由器中测量）。对于捆绑链路，带宽
utilization is defined to be the sum of the component link bandwidth utilization. This includes traffic for both RSVP-TE and non-RSVP-TE label switched path packets.
利用率定义为组件链路带宽利用率的总和。这包括RSVP-TE和非RSVP-TE标签交换路径数据包的通信量。
The LBU in percentage is described as the (utilized bandwidth / maximum bandwidth) * 100.
以百分比表示的LBU被描述为（利用带宽/最大带宽）*100。
The "maximum bandwidth" is defined in [RFC3630] and [RFC5305] and "utilized bandwidth" in [RFC7471] and [RFC7810].
[RFC3630]和[RFC5305]中定义了“最大带宽”；[RFC7471]和[RFC7810]中定义了“利用带宽”。
The LRBU on a link, forwarding adjacency, or bundled link can be calculated from the TED. The utilized bandwidth includes traffic for both RSVP-TE and non-RSVP-TE LSPs; the reserved bandwidth utilization considers only the RSVP-TE LSPs.
链路上的LRBU、转发邻接或捆绑链路可根据TED计算。所利用的带宽包括RSVP-TE和非RSVP-TE lsp的业务量；保留带宽利用率仅考虑RSVP-TE LSP。
The reserved bandwidth utilization can be calculated by using the residual bandwidth, available bandwidth, and utilized bandwidth described in [RFC7471] and [RFC7810]. The actual bandwidth by non-RSVP-TE traffic can be calculated by subtracting the available bandwidth from the residual bandwidth ([RFC7471] and [RFC7810]), which is further deducted from utilized bandwidth to get the reserved bandwidth utilization. Thus,
保留带宽利用率可以通过使用[RFC7471]和[RFC7810]中描述的剩余带宽、可用带宽和利用带宽来计算。非RSVP TE流量的实际带宽可以通过从剩余带宽（[RFC7471]和[RFC7810]）中减去可用带宽来计算，剩余带宽进一步从利用带宽中扣除，以获得保留带宽利用率。因此
reserved bandwidth utilization = utilized bandwidth - (residual bandwidth - available bandwidth)
保留带宽利用率=已利用带宽-（剩余带宽-可用带宽）
The LRBU in percentage is described as the (reserved bandwidth utilization / maximum reservable bandwidth) * 100.
LRBU的百分比表示为（保留带宽利用率/最大保留带宽）*100。
The "maximum reservable bandwidth" is defined in [RFC3630] and [RFC5305]. The "utilized bandwidth", "residual bandwidth", and "available bandwidth" are defined in [RFC7471] and [RFC7810].
[RFC3630]和[RFC5305]中定义了“最大可保留带宽”。[RFC7471]和[RFC7810]中定义了“已利用带宽”、“剩余带宽”和“可用带宽”。
The BU object is used to indicate the upper limit of the acceptable link bandwidth utilization percentage.
BU对象用于指示可接受链路带宽利用率百分比的上限。
The BU object MAY be carried within the PCReq message and PCRep messages.
BU对象可以在PCReq消息和PCRep消息中携带。
BU Object-Class is 35.
BU对象类是35。
BU Object-Type is 1.
BU对象类型为1。
The format of the BU object body is as follows:
BU对象体的格式如下：
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 | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BU Object Body Format
对象体格式
Reserved (24 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
保留（24位）：此字段在传输时必须设置为零，在接收时必须忽略。
Type (8 bits): Represents the bandwidth utilization type. Two values are currently defined.
类型（8位）：表示带宽利用率类型。当前定义了两个值。
* Type 1 is LBU (Link Bandwidth Utilization)
* 类型1为LBU（链路带宽利用率）
* Type 2 is LRBU (Link Residual Bandwidth Utilization)
* 类型2为LRBU（链路剩余带宽利用率）
Bandwidth Utilization (32 bits): Represents the bandwidth utilization quantified as a percentage (as described in Sections 3.2.1 and 3.2.2) and encoded in IEEE floating point format (see [IEEE.754]).
带宽利用率（32位）：表示量化为百分比（如第3.2.1节和第3.2.2节所述）并以IEEE浮点格式编码的带宽利用率（见[IEEE.754]）。
The BU object body has a fixed length of 8 bytes.
BU对象体的固定长度为8字节。
A PCC that wants the PCE to factor in the bandwidth utilization during path computation includes a BU object in the PCReq message. A PCE that supports this object MUST ensure that no link on the computed path has the LBU or LRBU percentage exceeding the given value.
希望PCE在路径计算期间考虑带宽利用率的PCC在PCReq消息中包括BU对象。支持此对象的PCE必须确保计算路径上没有链路的LBU或LRBU百分比超过给定值。
A PCReq or PCRep message MAY contain multiple BU objects so long as each is for a different bandwidth utilization type. If a message contains more than one BU object with the same bandwidth utilization type, the first MUST be processed by the receiver and subsequent instances MUST be ignored.
PCReq或PCRep消息可以包含多个BU对象，只要每个BU对象用于不同的带宽利用率类型。如果消息包含多个具有相同带宽利用率类型的BU对象，则接收器必须处理第一个BU对象，并且必须忽略后续实例。
If the BU object is unknown/unsupported, the PCE is expected to 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
如果BU对象未知/不受支持，则PCE应遵循[RFC5440]中定义的程序。也就是说，如果设置了P位，PCE将发送错误类型为3或4（未知/不支持对象）和错误值1或2（未知/不支持对象）的PCErr消息
object class / object type), and the related path computation request will be discarded. If the P bit is cleared, the PCE is free to ignore the object.
对象类/对象类型），相关的路径计算请求将被丢弃。如果清除P位，则PCE可自由忽略该对象。
If the PCE understands but does not support path computation requests using the BU object, and the P bit is set in the BU object header, then the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 4 (Not supported object) with Error-value = 5 (Unsupported network performance constraint), and the related path computation request MUST be discarded.
如果PCE理解但不支持使用BU对象的路径计算请求，并且在BU对象头中设置了P位，则PCE必须发送PCErr消息，其中PCEP-ERROR对象错误类型=4（不支持的对象），错误值=5（不支持的网络性能约束），并且必须放弃相关的路径计算请求。
If the PCE understands the BU object but the local policy has been configured on the PCE to not allow network performance constraint, and the P bit is set in the BU object header, then the PCE MUST send a PCErr message with a PCEP-ERROR Object Error-Type = 5 (Policy violation) with Error-value = 8 (Not allowed network performance constraint). The path computation request MUST then be canceled.
如果PCE了解BU对象，但PCE上已将本地策略配置为不允许网络性能约束，并且在BU对象标头中设置了P位，则PCE必须发送PCErr消息，其中PCEP-ERROR对象错误类型=5（策略冲突），错误值=8（不允许网络性能约束）。然后必须取消路径计算请求。
If path computation is unsuccessful, then a PCE MAY insert a BU object (along with a NO-PATH object) into a PCRep message to indicate the constraints that could not be satisfied.
如果路径计算不成功，则PCE可将BU对象（连同无路径对象）插入PCRep消息中，以指示无法满足的约束。
Usage of the BU object for P2MP LSPs is outside the scope of this document.
P2MP LSP的BU对象的使用超出了本文档的范围。
[RFC5541] defines a mechanism to specify an objective function that is used by a PCE when it computes a path. The new metric types for path delay and path delay variation can continue to use the existing objective function -- Minimum Cost Path (MCP) [RFC5541]. For path loss, the following new OF is defined.
[RFC5541]定义了一种机制，用于指定PCE在计算路径时使用的目标函数。路径延迟和路径延迟变化的新度量类型可以继续使用现有的目标函数——最小成本路径（MCP）[RFC5541]。对于路径损耗，定义了以下新的OF。
o A network comprises a set of N links {Li, (i=1...N)}.
o 网络由一组N个链路{Li，（i=1…N）}组成。
o A path P is a list of K links {Lpi,(i=1...K)}.
o 路径P是K个链接的列表{Lpi，（i=1…K）}。
o The percentage link loss of link L is denoted PL(L).
o 链路L的链路损耗百分比表示为PL（L）。
o The fractional link loss of link L is denoted FL(L) = PL(L) / 100.
o 链路L的部分链路损耗表示为FL（L）=PL（L）/100。
o The percentage path loss of a path P is denoted PL(P), where PL(P) = (1 - ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100.
o 路径P的路径损耗百分比表示为PL（P），其中PL（P）=（1-（（1-FL（Lp1））*（1-FL（Lp2））*…*（1-FL（LpK）））*100。
Objective Function Code: 9 Name: Minimum Packet Loss Path (MPLP) Description: Find a path P such that PL(P) is minimized.
目标函数代码：9名称：最小丢包路径（MPLP）描述：找到一条路径P，使PL（P）最小化。
Two additional objective functions -- namely, the Maximum Under-Utilized Path (MUP) and the Maximum Reserved Under-Utilized Path (MRUP) are needed to optimize bandwidth utilization. These two new objective function codes are defined below.
优化带宽利用率还需要两个额外的目标函数，即最大未利用路径（MUP）和最大保留未利用路径（MRUP）。这两个新的目标函数代码定义如下。
These objective functions are formulated using the following additional terminology:
这些目标函数使用以下附加术语制定：
o The bandwidth utilization on link L is denoted u(L).
o 链路L上的带宽利用率表示为u（L）。
o The reserved bandwidth utilization on link L is denoted ru(L).
o 链路L上的保留带宽利用率表示为ru（L）。
o The maximum bandwidth on link L is denoted M(L).
o 链路L上的最大带宽表示为M（L）。
o The maximum reservable bandwidth on link L is denoted R(L).
o 链路L上的最大可保留带宽表示为R（L）。
The description of the two new objective functions is as follows.
两个新目标函数的描述如下。
Objective Function Code: 10 Name: Maximum Under-Utilized Path (MUP) Description: Find a path P such that (Min {(M(Lpi)- u(Lpi)) / M(Lpi), i=1...K } ) is maximized.
目标函数代码：10名称：最大未利用路径（MUP）描述：找到一条路径P，使（Min{（M（Lpi）-u（Lpi））/M（Lpi），i=1…K}）最大化。
Objective Function Code: 11 Name: Maximum Reserved Under-Utilized Path (MRUP) Description: Find a path P such that (Min {(R(Lpi)- ru(Lpi)) / R(Lpi), i=1...K } ) is maximized.
目标函数代码：11名称：最大保留未利用路径（MRUP）说明：找到一条路径P，使（Min{（R（Lpi）-ru（Lpi））/R（Lpi），i=1…K}）最大化。
These new objective functions are used to optimize paths based on the bandwidth utilization as the optimization criteria.
这些新的目标函数用于基于带宽利用率作为优化准则的路径优化。
If the objective functions defined in this document are unknown/ unsupported by a PCE, then the procedure as defined in Section 3.1.1 of [RFC5541] is followed.
如果本文件中定义的目标函数未知/PCE不支持，则遵循[RFC5541]第3.1.1节中定义的程序。
[RFC8231] specifies a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP and the maintaining of these LSPs at the stateful PCE. It further distinguishes between an active and a passive stateful PCE. A passive stateful PCE uses LSP state information learned from PCCs to optimize path computations but does not actively update LSP state. In contrast, an active stateful PCE utilizes the LSP delegation mechanism to update LSP parameters in those PCCs that delegated control over their LSPs to the PCE. [PCE-INITIATED] describes the setup, maintenance, and teardown of
[RFC8231]指定PCEP的一组扩展，以通过PCEP启用MPLS-TE和GMPLS LSP的状态控制，并在状态PCE中维护这些LSP。它进一步区分了主动状态PCE和被动状态PCE。被动有状态PCE使用从PCC学习的LSP状态信息来优化路径计算，但不主动更新LSP状态。相反，主动有状态PCE利用LSP委托机制来更新那些将其LSP控制权委托给PCE的PCC中的LSP参数。[PCE-INITIATED]描述了以下各项的设置、维护和拆卸：
PCE-initiated LSPs under the stateful PCE model. The document defines the PCInitiate message that is used by a PCE to request a PCC to set up a new LSP.
PCE在有状态PCE模型下启动LSP。本文档定义PCE用于请求PCC设置新LSP的PCInitiate消息。
The new metric type and objective functions defined in this document can also be used with the stateful PCE extensions. The format of PCEP messages described in [RFC8231] and [PCE-INITIATED] uses <intended-attribute-list> and <attribute-list>, respectively, (where the <intended-attribute-list> is the attribute-list defined in Section 6.5 of [RFC5440] and extended in Section 5.2 of this document) for the purpose of including the service-aware parameters.
本文中定义的新度量类型和目标函数也可用于有状态PCE扩展。[RFC8231]和[PCE-INITIATED]中描述的PCEP消息格式分别使用<预期属性列表>和<属性列表>（其中<预期属性列表>是[RFC5440]第6.5节中定义并在本文件第5.2节中扩展的属性列表），以包括服务感知参数。
The stateful PCE implementation MAY use the extension of PCReq and PCRep messages as defined in Sections 5.1 and 5.2 to enable the use of service-aware parameters during passive stateful operations.
有状态PCE实现可以使用第5.1节和第5.2节中定义的PCReq和PCRep消息的扩展，以便在被动有状态操作期间使用服务感知参数。
Message formats in this document are expressed using Routing Backus-Naur Form (RBNF) as used in [RFC5440] and defined in [RFC5511].
本文件中的消息格式使用[RFC5440]中使用并在[RFC5511]中定义的路由Backus Naur表单（RBNF）表示。
The extensions to the PCReq message are:
PCReq消息的扩展为：
o new metric types using existing METRIC object
o 使用现有度量对象的新度量类型
o a new optional BU object
o 一个新的可选BU对象
o new objective functions using existing OF object [RFC5541]
o 使用现有对象的新目标函数[RFC5541]
The format of the PCReq message (with [RFC5541] and [RFC8231] as a base) is updated as follows:
PCReq消息的格式（以[RFC5541]和[RFC8231]为基础）更新如下：
<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>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<bu-list>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
<request> ::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<bu-list>]
[<metric-list>]
[<OF>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
and where:
<bu-list>::=<BU>[<bu-list>]
<metric-list> ::= <METRIC>[<metric-list>]
and where:
<bu-list>::=<BU>[<bu-list>]
<metric-list> ::= <METRIC>[<metric-list>]
The extensions to the PCRep message are:
PCRep消息的扩展包括：
o new metric types using existing METRIC object
o 使用现有度量对象的新度量类型
o a new optional BU object (during unsuccessful path computation, to indicate the bandwidth utilization as a reason for failure)
o 一个新的可选BU对象（在路径计算失败期间，将带宽利用率作为失败的原因）
o new objective functions using existing OF object [RFC5541]
o 使用现有对象的新目标函数[RFC5541]
The format of the PCRep message (with [RFC5541] and [RFC8231] as a base) is updated as follows:
PCRep消息的格式（以[RFC5541]和[RFC8231]为基础）更新如下：
<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>
[<LSP>]
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<response> ::= <RP>
[<LSP>]
[<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>]
[<bu-list>]
[<metric-list>]
[<IRO>]
<attribute-list> ::= [<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<bu-list>]
[<metric-list>]
[<IRO>]
<bu-list>::=<BU>[<bu-list>]
<metric-list> ::= <METRIC> [<metric-list>]
<bu-list>::=<BU>[<bu-list>]
<metric-list> ::= <METRIC> [<metric-list>]
A Path Computation LSP State Report message (also referred to as PCRpt message) is a PCEP message sent by a PCC to a PCE to report the current state or delegate control of an LSP. The BU object in a PCRpt message specifies the upper limit set at the PCC at the time of LSP delegation to an active stateful PCE.
路径计算LSP状态报告消息（也称为PCRpt消息）是PCC发送给PCE的PCEP消息，用于报告LSP的当前状态或委托控制。PCRpt消息中的BU对象指定LSP委托给活动状态PCE时在PCC设置的上限。
The format of the PCRpt message is described in [RFC8231], which uses the <intended-attribute-list>, which is the attribute-list defined in Section 6.5 of [RFC5440] and extended by PCEP extensions.
PCRpt消息的格式在[RFC8231]中进行了描述，该消息使用了[RFC5440]第6.5节中定义并通过PCEP扩展扩展的<预期属性列表>。
The PCRpt message can use the updated <attribute-list> (as extended in Section 5.2) for the purpose of including the BU object.
PCRpt消息可以使用更新的<attribute list>（如第5.2节中的扩展）来包含BU对象。
[RFC5441] describes the Backward Recursive PCE-Based Computation (BRPC) procedure to compute an end-to-end optimized inter-domain path by cooperating PCEs. The new metric types defined in this document can be applied to end-to-end path computation, in a similar manner to the existing IGP or TE metrics. The new BU object defined in this document can be applied to end-to-end path computation, in a similar manner to a METRIC object with its B bit set to 1.
[RFC5441]描述了基于PCE的反向递归计算（BRPC）过程，通过协作PCE计算端到端优化域间路径。本文档中定义的新度量类型可应用于端到端路径计算，方式与现有IGP或TE度量类似。本文档中定义的新BU对象可应用于端到端路径计算，其方式与B位设置为1的度量对象类似。
All domains should have the same understanding of the METRIC (path delay variation, etc.) and the BU object for end-to-end inter-domain path computation to make sense. Otherwise, some form of metric normalization as described in [RFC5441] MUST be applied.
所有域都应该对度量（路径延迟变化等）和BU对象有相同的理解，以便进行端到端域间路径计算。否则，必须应用[RFC5441]中所述的某种形式的度量标准化。
The IGP in each neighbor domain can advertise its inter-domain TE link capabilities. This has been described in [RFC5316] (IS-IS) and [RFC5392] (OSPF). The network performance link properties are described in [RFC7471] and [RFC7810]. The same properties must be advertised using the mechanism described in [RFC5392] (OSPF) and [RFC5316] (IS-IS).
每个相邻域中的IGP可以公布其域间TE链路能力。这已在[RFC5316]（IS-IS）和[RFC5392]（OSPF）中描述。[RFC7471]和[RFC7810]中描述了网络性能链路属性。必须使用[RFC5392]（OSPF）和[RFC5316]（IS-IS）中描述的机制公布相同的属性。
[RFC5623] provides a framework for PCE-based inter-layer MPLS and GMPLS traffic engineering. Lower-layer LSPs that are advertised as TE links into the higher-layer network form a Virtual Network Topology (VNT). The advertisement into the higher-layer network should include network performance link properties based on the end-to-end metric of the lower-layer LSP. Note that the new metrics defined in this document are applied to end-to-end path computation, even though the path may cross multiple layers.
[RFC5623]为基于PCE的层间MPLS和GMPLS流量工程提供了一个框架。作为TE链路播发到高层网络的下层LSP形成虚拟网络拓扑（VNT）。进入高层网络的广告应包括基于下层LSP的端到端度量的网络性能链路属性。请注意，本文档中定义的新指标应用于端到端路径计算，即使路径可能跨越多个层。
[RFC6374] defines the measurement of loss, delay, and related metrics over LSPs. A PCC can utilize these measurement techniques. In case it detects a degradation of network performance parameters relative to the value of the constraint it gave when the path was set up, or relative to an implementation-specific threshold, it MAY ask the PCE to reoptimize the path by sending a PCReq with the R bit set in the RP object, as per [RFC5440].
[RFC6374]定义了LSP上损失、延迟和相关度量的度量。PCC可以利用这些测量技术。如果它检测到网络性能参数相对于设置路径时给出的约束值或相对于特定于实现的阈值的退化，它可以根据[RFC5440]要求PCE通过发送在RP对象中设置了R位的PCReq来重新优化路径。
A PCC may also detect the degradation of an LSP without making any direct measurements, by monitoring the TED (as populated by the IGP) for changes in the network performance parameters of the links that carry its LSPs. The PCC can issue a reoptimization request for any impacted LSPs. For example, a PCC can monitor the link bandwidth utilization along the path by monitoring changes in the bandwidth utilization parameters of one or more links on the path in the TED. If the bandwidth utilization percentage of any of the links in the path changes to a value less than that required when the path was set up, or otherwise less than an implementation-specific threshold, then the PCC can issue a reoptimization request to a PCE.
PCC还可以通过监视TED（由IGP填充）来检测承载其LSP的链路的网络性能参数的变化，而不进行任何直接测量来检测LSP的退化。PCC可以对任何受影响的LSP发出重新优化请求。例如，PCC可以通过监视TED中路径上的一个或多个链路的带宽利用率参数的变化来监视沿路径的链路带宽利用率。如果路径中任何链路的带宽利用率百分比变为小于设置路径时所需的值，或者小于特定于实现的阈值，则PCC可以向PCE发出重新优化请求。
A stateful PCE can also determine which LSPs should be reoptimized based on network events or triggers from external monitoring systems. For example, when a particular link deteriorates and its loss increases, this can trigger the stateful PCE to automatically determine which LSPs are impacted and should be reoptimized.
有状态PCE还可以根据网络事件或来自外部监控系统的触发器确定哪些LSP应重新优化。例如，当特定链路恶化且其损耗增加时，这会触发有状态PCE自动确定哪些LSP受到影响并应重新优化。
IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" registry at <http://www.iana.org/assignments/pcep>. Within this registry, IANA maintains a subregistry for "METRIC Object T Field". Six new metric types are defined in this document for the METRIC object (specified in [RFC5440]).
IANA在以下位置维护“路径计算元素协议（PCEP）编号”注册表：<http://www.iana.org/assignments/pcep>. 在该注册表中，IANA为“公制对象T字段”维护一个子区域。本文件为度量对象定义了六种新的度量类型（在[RFC5440]中指定）。
IANA has made the following allocations:
IANA进行了以下分配：
Value Description Reference
----------------------------------------------------------
12 Path Delay metric RFC 8233
13 Path Delay Variation metric RFC 8233
14 Path Loss metric RFC 8233
15 P2MP Path Delay metric RFC 8233
16 P2MP Path Delay variation metric RFC 8233
17 P2MP Path Loss metric RFC 8233
Value Description Reference
----------------------------------------------------------
12 Path Delay metric RFC 8233
13 Path Delay Variation metric RFC 8233
14 Path Loss metric RFC 8233
15 P2MP Path Delay metric RFC 8233
16 P2MP Path Delay variation metric RFC 8233
17 P2MP Path Loss metric RFC 8233
IANA maintains Object-Types within the "PCEP Objects" registry. IANA has made the following allocation:
IANA在“PCEP对象”注册表中维护对象类型。IANA已作出以下分配：
Object Object Name Reference
Class Type
------------------------------------------------------
35 0 Reserved RFC 8233
1 BU RFC 8233
Object Object Name Reference
Class Type
------------------------------------------------------
35 0 Reserved RFC 8233
1 BU RFC 8233
IANA has created a new subregistry, named "BU Object Type Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Type field of the BU object. New values are to be assigned by Standards Action [RFC8126]. Each value should be tracked with the following qualities:
IANA在“路径计算元素协议（PCEP）编号”注册表中创建了一个新的子区域，名为“BU对象类型字段”，用于管理BU对象的类型字段。新值将由标准行动[RFC8126]分配。应通过以下质量跟踪每个值：
o Type
o 类型
o Name
o 名称
o Reference
o 参考
The following values are defined in this document:
本文件中定义了以下值：
Type Name Reference
---------------------------------------------------------------
0 Reserved RFC 8233
Type Name Reference
---------------------------------------------------------------
0 Reserved RFC 8233
1 LBU (Link Bandwidth Utilization) RFC 8233
1个LBU（链路带宽利用率）RFC 8233
2 LRBU (Link Residual Bandwidth Utilization) RFC 8233
2 LRBU（链路剩余带宽利用率）RFC 8233
IANA maintains the "Objective Function" subregistry (described in [RFC5541]) within the "Path Computation Element Protocol (PCEP) Numbers" registry. Three new objective functions have been defined in this document.
IANA在“路径计算元素协议（PCEP）编号”注册表中维护“目标函数”子区域（如[RFC5541]所述）。本文件定义了三个新的目标函数。
IANA has made the following allocations:
IANA进行了以下分配：
Code Name Reference
Point
-----------------------------------------------------------------
9 Minimum Packet Loss Path (MPLP) RFC 8233
Code Name Reference
Point
-----------------------------------------------------------------
9 Minimum Packet Loss Path (MPLP) RFC 8233
10 Maximum Under-Utilized Path (MUP) RFC 8233
10最大未利用路径（MUP）RFC 8233
11 Maximum Reserved Under-Utilized Path (MRUP) RFC 8233
11最大保留未利用路径（MRUP）RFC 8233
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" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry.
IANA维护用于PCEP消息的错误类型和错误值的注册表。这被维护为“路径计算元素协议（PCEP）编号”注册表的“PCEP-ERROR对象错误类型和值”子区。
IANA has made the following allocations:
IANA进行了以下分配：
Two new Error-values are defined for the Error-Type "Not supported object" (type 4) and "Policy violation" (type 5).
为错误类型“不支持的对象”（类型4）和“策略冲突”（类型5）定义了两个新的错误值。
Error-Type Meaning and error values Reference
-------------------------------------------------------------
4 Not supported object
Error-Type Meaning and error values Reference
-------------------------------------------------------------
4 Not supported object
Error-value 5: Unsupported network RFC 8233 performance constraint
错误值5:不支持的网络RFC 8233性能约束
5 Policy violation
5违反政策
Error-value 8: Not allowed network RFC 8233 performance constraint
错误值8：不允许网络RFC 8233性能约束
This document defines new METRIC types, a new BU object, and new OF codes that do not add any new security concerns beyond those discussed in [RFC5440] and [RFC5541] in itself. Some deployments may find the service-aware information like delay and packet loss to be extra sensitive and could be used to influence path computation and setup with adverse effect. Additionally, snooping of PCEP messages with such data or using PCEP messages for network reconnaissance may give an attacker sensitive information about the operations of the network. Thus, such deployment should employ suitable PCEP security
本文档定义了新的度量类型、新的BU对象和新的代码，这些代码本身不会增加[RFC5440]和[RFC5541]中讨论的安全问题之外的任何新的安全问题。一些部署可能会发现延迟和数据包丢失等服务感知信息特别敏感，并可能被用于影响路径计算和设置，产生不利影响。此外，利用此类数据窥探PCEP消息或使用PCEP消息进行网络侦察可能会向攻击者提供有关网络操作的敏感信息。因此，此类部署应采用适当的PCEP安全性
mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or [PCEPS]. The procedure based on Transport Layer Security (TLS) in [PCEPS] is considered a security enhancement and thus is much better suited for the sensitive service-aware information.
TCP身份验证选项（TCP-AO）[RFC5925]或[PCEPS]等机制。[PCEPS]中基于传输层安全性（TLS）的过程被认为是一种安全增强，因此更适合敏感的服务感知信息。
The only configurable item is the support of the new constraints on a PCE, which MAY be controlled by a policy module on an individual basis. If the new constraint is not supported/allowed on a PCE, it MUST send a PCErr message accordingly.
唯一可配置的项目是对PCE的新约束的支持，这可能由策略模块单独控制。如果PCE不支持/不允许新约束，则必须相应地发送PCErr消息。
[RFC7420] describes the PCEP MIB. There are no new MIB Objects for this document.
[RFC7420]描述了PCEP MIB。此文档没有新的MIB对象。
The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
除了[RFC5440]中已经列出的机制外，本文件中定义的机制并不意味着任何新的活性检测和监测要求。
The mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440].
除了[RFC5440]中已经列出的机制外，本文件中定义的机制并不意味着任何新的运行验证要求。
The PCE requires the TED to be populated with network performance information like link latency, delay variation, packet loss, and utilized bandwidth. This mechanism is described in [RFC7471] and [RFC7810].
PCE要求TED填充网络性能信息，如链路延迟、延迟变化、数据包丢失和利用带宽。[RFC7471]和[RFC7810]中描述了该机制。
The mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440].
除[RFC5440]中已列出的机制外，本文件中定义的机制对网络运行没有任何影响。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，DOI 10.17487/RFC3630，2003年9月<https://www.rfc-editor.org/info/rfc3630>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5305]Li，T.和H.Smit，“交通工程的IS-IS扩展”，RFC 5305，DOI 10.17487/RFC5305，2008年10月<https://www.rfc-editor.org/info/rfc5305>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<https://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5511]Farrel，A.，“路由Backus-Naur形式（RBNF）：用于在各种路由协议规范中形成编码规则的语法”，RFC 5511，DOI 10.17487/RFC5511，2009年4月<https://www.rfc-editor.org/info/rfc5511>.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>.
[RFC5541]Le Roux，JL.，Vasseur，JP.，和Y.Lee，“路径计算元素通信协议（PCEP）中目标函数的编码”，RFC 5541，DOI 10.17487/RFC55412009年6月<https://www.rfc-editor.org/info/rfc5541>.
[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, <https://www.rfc-editor.org/info/rfc7471>.
[RFC7471]Giacalone，S.，Ward，D.，Drake，J.，Atlas，A.，和S.Previdi，“OSPF交通工程（TE）度量扩展”，RFC 7471，DOI 10.17487/RFC7471，2015年3月<https://www.rfc-editor.org/info/rfc7471>.
[RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, <https://www.rfc-editor.org/info/rfc7810>.
[RFC7810]Previdi，S.，Ed.，Giacalone，S.，Ward，D.，Drake，J.，和Q.Wu，“IS-IS交通工程（TE）度量扩展”，RFC 7810，DOI 10.17487/RFC7810，2016年5月<https://www.rfc-editor.org/info/rfc7810>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <http://www.rfc-editor.org/info/rfc8231>.
[RFC8231]Crabbe，E.，Minei，I.，Medved，J.，和R.Varga，“有状态PCE的路径计算元素通信协议（PCEP）扩展”，RFC 8231，DOI 10.17487/RFC82312017年9月<http://www.rfc-editor.org/info/rfc8231>.
[IEEE.754] IEEE, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754-2008, DOI 10.1109/IEEESTD.2008.4610935, August 2008.
[IEEE.754]IEEE，“二进制浮点运算标准”，IEEE标准754-2008，DOI 10.1109/IEEESTD.2008.46109352008年8月。
[PCE-INITIATED] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Work in Progress, draft-ietf-pce-pce-initiated-lsp-10, June 2017.
[PCE-启动]Crabbe，E.，Minei，I.，Sivabalan，S.，和R.Varga，“状态PCE模型中PCE启动LSP设置的PCEP扩展”，正在进行的工作，草稿-ietf-PCE-PCE-INITIATED-LSP-10，2017年6月。
[PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-16, September 2017.
[PCEP]Lopez，D.，Dios，O.，Wu，W.，和D.Dhody，“PCEP的安全运输”，正在进行的工作，草案-ietf-pce-PCEPS-16，2017年9月。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<https://www.rfc-editor.org/info/rfc4655>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[RFC5316]Chen，M.，Zhang，R.，和X.Duan，“支持自治系统间MPLS和GMPLS流量工程的ISIS扩展”，RFC 5316，DOI 10.17487/RFC5316，2008年12月<https://www.rfc-editor.org/info/rfc5316>.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, <https://www.rfc-editor.org/info/rfc5392>.
[RFC5392]Chen，M.，Zhang，R.，和X.Duan，“支持跨自治系统（AS）MPLS和GMPLS流量工程的OSPF扩展”，RFC 5392，DOI 10.17487/RFC5392，2009年1月<https://www.rfc-editor.org/info/rfc5392>.
[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, DOI 10.17487/RFC5441, April 2009, <https://www.rfc-editor.org/info/rfc5441>.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）程序”，RFC 5441，DOI 10.17487/RFC5441，2009年4月<https://www.rfc-editor.org/info/rfc5441>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623, September 2009, <https://www.rfc-editor.org/info/rfc5623>.
[RFC5623]Oki，E.，Takeda，T.，Le Roux，JL.，和A.Farrel，“基于PCE的层间MPLS和GMPLS流量工程框架”，RFC 5623，DOI 10.17487/RFC5623，2009年9月<https://www.rfc-editor.org/info/rfc5623>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 5925，DOI 10.17487/RFC5925，2010年6月<https://www.rfc-editor.org/info/rfc5925>.
[RFC6049] Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011, <https://www.rfc-editor.org/info/rfc6049>.
[RFC6049]Morton，A.和E.Stephan，“度量的空间构成”，RFC 6049，DOI 10.17487/RFC6049，2011年1月<https://www.rfc-editor.org/info/rfc6049>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <https://www.rfc-editor.org/info/rfc6374>.
[RFC6374]Frost，D.和S.Bryant，“MPLS网络的数据包丢失和延迟测量”，RFC 6374，DOI 10.17487/RFC6374，2011年9月<https://www.rfc-editor.org/info/rfc6374>.
[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
[RFC7420]Koushik，A.，Stephan，E.，Zhao，Q.，King，D.，和J.Hardwick，“路径计算元素通信协议（PCEP）管理信息库（MIB）模块”，RFC 7420，DOI 10.17487/RFC7420，2014年12月<https://www.rfc-editor.org/info/rfc7420>.
[RFC7823] Atlas, A., Drake, J., Giacalone, S., and S. Previdi, "Performance-Based Path Selection for Explicitly Routed Label Switched Paths (LSPs) Using TE Metric Extensions", RFC 7823, DOI 10.17487/RFC7823, May 2016, <https://www.rfc-editor.org/info/rfc7823>.
[RFC7823]Atlas，A.，Drake，J.，Giacalone，S.，和S.Previdi，“使用TE度量扩展的显式路由标签交换路径（LSP）的基于性能的路径选择”，RFC 7823，DOI 10.17487/RFC7823，2016年5月<https://www.rfc-editor.org/info/rfc7823>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
End-to-end service optimization based on latency, delay variation, packet loss, and link bandwidth utilization are key requirements for service providers. The following associated key requirements are identified for PCEP:
基于延迟、延迟变化、数据包丢失和链路带宽利用率的端到端服务优化是服务提供商的关键要求。确定了PCEP的以下相关关键要求：
1. A PCE supporting this specification MUST have the capability to compute end-to-end paths with latency, delay variation, packet loss, and bandwidth utilization constraints. It MUST also support the combination of network performance constraints (latency, delay variation, loss,...) with existing constraints (cost, hop-limit,...).
1. 支持此规范的PCE必须能够计算具有延迟、延迟变化、数据包丢失和带宽利用率约束的端到端路径。它还必须支持网络性能约束（延迟、延迟变化、丢失等）与现有约束（成本、跃点限制等）的组合。
2. A PCC MUST be able to specify any network performance constraint in a PCReq message to be applied during the path computation.
2. PCC必须能够在路径计算期间应用的PCReq消息中指定任何网络性能约束。
3. A PCC MUST be able to request that a PCE optimizes a path using any network performance criteria.
3. PCC必须能够请求PCE使用任何网络性能标准优化路径。
4. A PCE that supports this specification is not required to provide service-aware path computation to any PCC at any time.
4. 支持此规范的PCE无需在任何时候向任何PCC提供服务感知路径计算。
Therefore, it MUST be possible for a PCE to reject a PCReq message with a reason code that indicates service-aware path computation is not supported. Furthermore, a PCE that does not support this specification will either ignore or reject such requests using pre-existing mechanisms; therefore, the requests MUST be identifiable to legacy PCEs, and rejections by legacy PCEs MUST be acceptable within this specification.
因此，PCE必须能够拒绝带有指示不支持服务感知路径计算的原因码的PCReq消息。此外，不支持本规范的PCE将使用预先存在的机制忽略或拒绝此类请求；因此，请求必须能够被遗留PCE识别，并且在本规范范围内，遗留PCE的拒绝必须是可接受的。
5. A PCE SHOULD be able to return end-to-end network performance information of the computed path in a PCRep message.
5. PCE应该能够在PCRep消息中返回计算路径的端到端网络性能信息。
6. A PCE SHOULD be able to compute multi-domain (e.g., Inter-AS, Inter-Area, or Multi-Layer) service-aware paths.
6. PCE应该能够计算多域（例如，AS间、区域间或多层）服务感知路径。
Such constraints are only meaningful if used consistently: for instance, if the delay of a computed path segment is exchanged between two PCEs residing in different domains, a consistent way of defining the delay must be used.
此类约束只有在一致使用时才有意义：例如，如果计算路径段的延迟在驻留在不同域中的两个PCE之间交换，则必须使用一致的定义延迟的方法。
Acknowledgments
致谢
We would like to thank Alia Atlas, John E. Drake, David Ward, Young Lee, Venugopal Reddy, Reeja Paul, Sandeep Kumar Boina, Suresh Babu, Quintin Zhao, Chen Huaimo, Avantika, and Adrian Farrel for their useful comments and suggestions.
我们要感谢Alia Atlas、John E.Drake、David Ward、Young Lee、Venugopal Reddy、Reeja Paul、Sandeep Kumar Boina、Suresh Babu、Quintin Zhao、陈怀默、Avantika和Adrian Farrel提出的有用意见和建议。
Also, the authors gratefully acknowledge reviews and feedback provided by Qin Wu, Alfred Morton, and Paul Aitken during performance directorate review.
此外，作者感谢秦武、阿尔弗雷德·莫顿和保罗·艾特肯在绩效董事会审查期间提供的审查和反馈。
Thanks to Jonathan Hardwick for shepherding this document and providing valuable comments. His help in fixing the editorial and grammatical issues is also appreciated.
感谢Jonathan Hardwick指导本文件并提供了宝贵的意见。他在解决编辑和语法问题方面的帮助也受到了赞赏。
Thanks to Christian Hopps for the routing directorate review.
感谢Christian Hopps的路线董事会审查。
Thanks to Jouni Korhonen and Alfred Morton for the operational directorate review.
感谢Jouni Korhonen和Alfred Morton对运营董事会的审查。
Thanks to Christian Huitema for the security directorate review.
感谢Christian Huitema对安全理事会的审查。
Thanks to Deborah Brungard for being the responsible AD.
感谢Deborah Brungard作为负责任的广告。
Thanks to Ben Campbell, Joel Jaeggli, Stephen Farrell, Kathleen Moriarty, Spencer Dawkins, Mirja Kuehlewind, Jari Arkko, and Alia Atlas for the IESG reviews.
感谢Ben Campbell、Joel Jaeggli、Stephen Farrell、Kathleen Moriarty、Spencer Dawkins、Mirja Kuehlewind、Jari Arkko和Alia Atlas的IESG评论。
Contributors
贡献者
Clarence Filsfils Cisco Systems Email: cfilsfil@cisco.com
Clarence Filsfils Cisco Systems电子邮件：cfilsfil@cisco.com
Siva Sivabalan Cisco Systems Email: msiva@cisco.com
Siva Sivabalan Cisco Systems电子邮件：msiva@cisco.com
George Swallow Cisco Systems Email: swallow@cisco.com
George Swallow Cisco Systems电子邮件：swallow@cisco.com
Stefano Previdi Cisco Systems, Inc Via Del Serafico 200 Rome 00191 Italy Email: sprevidi@cisco.com
Stefano Previdi Cisco Systems，Inc.通过Del Serafico 200罗马00191意大利电子邮件：sprevidi@cisco.com
Udayasree Palle Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: udayasree.palle@huawei.com
Udayasree Palle华为技术部位于卡纳塔克邦Whitefield Bangalore的三个技术园，邮编560066印度电子邮件：Udayasree。palle@huawei.com
Avantika Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: avantika.sushilkumar@huawei.com
Avantika华为技术部位于卡纳塔克邦班加罗尔Whitefield Bangalore的三个技术园，邮编560066印度电子邮件：Avantika。sushilkumar@huawei.com
Xian Zhang Huawei Technologies F3-1-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen, Guangdong 518129 China Email: zhang.xian@huawei.com
中国广东省深圳市龙岗区华为基地坂田华为技术F3-1-B研发中心邮编：518129电子邮件：张。xian@huawei.com
Authors' Addresses
作者地址
Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India
印度卡纳塔克邦班加罗尔Whitefield Bangalore Dhruv Dhody华为技术分部，邮编560066
Email: dhruv.ietf@gmail.com
Email: dhruv.ietf@gmail.com
Qin Wu Huawei Technologies 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China
中国江苏省南京市雨花区软件大道101号秦武华为技术有限公司210012
Email: bill.wu@huawei.com
Email: bill.wu@huawei.com
Vishwas Manral Nano Sec Co 3350 Thomas Rd. Santa Clara, CA United States of America
美国加利福尼亚州圣克拉拉市托马斯路3350号维斯瓦斯曼拉尔纳米公司
Email: vishwas@nanosec.io
Email: vishwas@nanosec.io
Zafar Ali Cisco Systems
扎法尔·阿里思科系统公司
Email: zali@cisco.com
Email: zali@cisco.com
Kenji Kumaki KDDI Corporation
Kenji Kumaki KDDI公司
Email: ke-kumaki@kddi.com
Email: ke-kumaki@kddi.com