Internet Engineering Task Force (IETF) E. Oki
Request for Comments: 8282 Kyoto University
Category: Standards Track T. Takeda
ISSN: 2070-1721 NTT
A. Farrel
Juniper Networks
F. Zhang
Huawei Technologies Co., Ltd.
December 2017
Internet Engineering Task Force (IETF) E. Oki
Request for Comments: 8282 Kyoto University
Category: Standards Track T. Takeda
ISSN: 2070-1721 NTT
A. Farrel
Juniper Networks
F. Zhang
Huawei Technologies Co., Ltd.
December 2017
Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering
层间MPLS和GMPLS流量工程中路径计算元素通信协议（PCEP）的扩展
Abstract
摘要
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.
路径计算元件（PCE）提供路径计算功能，以支持多协议标签交换（MPLS）和通用MPLS（GMPLS）网络中的流量工程。
MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements.
MPLS和GMPLS网络可以由分层服务网络构成。通过一个称为层间流量工程的过程，跨多个网络层提供端到端流量工程，有利于整体网络效率。PCE是此类需求的候选解决方案。
The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering.
PCE通信协议（PCEP）设计为路径计算客户端（PCC）和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 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/rfc8282.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8282.
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. Overview of PCE-Based Inter-Layer Path Computation . . . . . 4
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
3.1. INTER-LAYER Object . . . . . . . . . . . . . . . . . . . 5
3.2. SWITCH-LAYER Object . . . . . . . . . . . . . . . . . . . 8
3.3. REQ-ADAP-CAP Object . . . . . . . . . . . . . . . . . . . 9
3.4. New Metric Types . . . . . . . . . . . . . . . . . . . . 10
3.5. SERVER-INDICATION Object . . . . . . . . . . . . . . . . 11
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Path Computation Request . . . . . . . . . . . . . . . . 11
4.2. Path Computation Reply . . . . . . . . . . . . . . . . . 12
4.3. Stateful PCE and PCE Initiated LSPs . . . . . . . . . . . 13
5. Updated Format of PCEP Messages . . . . . . . . . . . . . . . 14
6. Manageability Considerations . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. New PCEP Objects . . . . . . . . . . . . . . . . . . . . 16
7.2. New Registry for INTER-LAYER Object Flags . . . . . . . . 17
7.3. New Metric Types . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Overview of PCE-Based Inter-Layer Path Computation . . . . . 4
3. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4
3.1. INTER-LAYER Object . . . . . . . . . . . . . . . . . . . 5
3.2. SWITCH-LAYER Object . . . . . . . . . . . . . . . . . . . 8
3.3. REQ-ADAP-CAP Object . . . . . . . . . . . . . . . . . . . 9
3.4. New Metric Types . . . . . . . . . . . . . . . . . . . . 10
3.5. SERVER-INDICATION Object . . . . . . . . . . . . . . . . 11
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Path Computation Request . . . . . . . . . . . . . . . . 11
4.2. Path Computation Reply . . . . . . . . . . . . . . . . . 12
4.3. Stateful PCE and PCE Initiated LSPs . . . . . . . . . . . 13
5. Updated Format of PCEP Messages . . . . . . . . . . . . . . . 14
6. Manageability Considerations . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. New PCEP Objects . . . . . . . . . . . . . . . . . . . . 16
7.2. New Registry for INTER-LAYER Object Flags . . . . . . . . 17
7.3. New Metric Types . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed, and a PCE may initiate or modify services in a network by supplying new paths [RFC8231] [RFC8281].
[RFC4655]中定义的路径计算元素（PCE）是能够基于网络图计算网络路径或路由并应用计算约束的实体。路径计算客户端（PCC）可以向PCE请求要计算的路径，并且PCE可以通过提供新路径来启动或修改网络中的服务[RFC8231][RFC8281]。
A network may comprise multiple layers. These layers may represent separation of technologies (e.g., packet switch capable (PSC), time division multiplex (TDM), and lambda switch capable (LSC)) [RFC3945]; separation of data-plane switching granularity levels (e.g., Virtual Circuit 4 (VC4) and VC12) [RFC5212]; or a distinction between client and server networking roles (e.g., commercial or administrative separation of client and server networks). In this multi-layer network, Label Switched Paths (LSPs) in lower layers are used to carry higher-layer LSPs. The network topology formed by lower-layer LSPs and advertised as traffic engineering links (TE links) in the higher layer is called a Virtual Network Topology (VNT) [RFC5212]. Discussion of other ways that network layering can be supported such that connectivity in a higher-layer network can be provided by LSPs in a lower-layer network is provided in [RFC7926].
网络可以包括多个层。这些层可以表示技术的分离（例如，支持分组交换（PSC）、时分复用（TDM）和支持lambda交换（LSC））[RFC3945]；数据平面交换粒度级别的分离（例如，虚拟电路4（VC4）和VC12）[RFC5212]；或客户机和服务器网络角色之间的区别（例如，客户机和服务器网络的商业或管理分离）。在这种多层网络中，较低层的标签交换路径（LSP）用于承载较高层的LSP。由较低层LSP形成并在较高层中宣传为流量工程链路（TE链路）的网络拓扑称为虚拟网络拓扑（VNT）[RFC5212]。[RFC7926]中提供了对支持网络分层的其他方式的讨论，以使下层网络中的LSP能够提供高层网络中的连接。
It is important to optimize network resource utilization globally, i.e., taking into account all layers, rather than optimizing resource utilization at each layer independently. This allows better network efficiency to be achieved. This is what we call inter-layer traffic engineering. This includes mechanisms allowing the computation of end-to-end paths across layers (known as inter-layer path computation) and mechanisms for control and management of the VNT by setting up and releasing LSPs in the lower layers [RFC5212].
全局优化网络资源利用率非常重要，即考虑所有层，而不是单独优化每一层的资源利用率。这样可以实现更好的网络效率。这就是我们所说的层间流量工程。这包括允许跨层计算端到端路径的机制（称为层间路径计算）以及通过在较低层中设置和释放LSP来控制和管理VNT的机制[RFC5212]。
PCE can provide a suitable mechanism for resolving inter-layer path computation issues. The framework for applying the PCE-based path computation architecture to inter-layer traffic engineering is described in [RFC5623].
PCE可以为解决层间路径计算问题提供合适的机制。[RFC5623]中描述了将基于PCE的路径计算体系结构应用于层间流量工程的框架。
The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs and is defined in [RFC5440]. A set of requirements for PCEP extensions to support inter-layer traffic engineering is described in [RFC6457].
PCE通信协议（PCEP）设计为PCC和PCE之间的通信协议，并在[RFC5440]中定义。[RFC6457]中描述了支持层间流量工程的PCEP扩展的一组要求。
This document presents PCEP extensions for inter-layer traffic engineering that satisfy the requirements described in [RFC6457].
本文件介绍了满足[RFC6457]中所述要求的层间流量工程的PCEP扩展。
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]所述进行解释。
[RFC4206] defines a way to signal a higher-layer LSP, which has an explicit route that includes hops traversed by LSPs in lower layers. The computation of end-to-end paths across layers is called inter-layer path computation.
[RFC4206]定义了一种向高层LSP发送信号的方法，该LSP具有显式路由，其中包括下层LSP所穿越的跳。跨层端到端路径的计算称为层间路径计算。
A Label Switching Router (LSR) in the higher layer might not have information on the lower-layer topology, particularly in an overlay or augmented model [RFC3945]; hence, it may not be able to compute an end-to-end path across layers.
较高层中的标签交换路由器（LSR）可能没有关于较低层拓扑的信息，特别是在覆盖或增强模型中[RFC3945]；因此，它可能无法计算跨层的端到端路径。
PCE-based inter-layer path computation consists of using one or more PCEs to compute an end-to-end path across layers. This could be achieved by relying on a single PCE that has topology information about multiple layers and can directly compute an end-to-end path across layers considering the topology of all of the layers. Alternatively, the inter-layer path computation could be performed using multiple cooperating PCEs where each PCE has information about the topology of one or more layers (but not all layers) and where the PCEs collaborate to compute an end-to-end path.
基于PCE的层间路径计算包括使用一个或多个PCE计算跨层的端到端路径。这可以通过依赖单个PCE来实现，该PCE具有关于多个层的拓扑信息，并且可以考虑所有层的拓扑直接计算跨层的端到端路径。或者，层间路径计算可以使用多个协作PCE来执行，其中每个PCE具有关于一个或多个层（但不是所有层）的拓扑的信息，并且PCE协作以计算端到端路径。
As described in [RFC5339], a hybrid node may advertise a single TE link with multiple switching capabilities. Normally, those TE links exist at the layer/region boarder. In this case, a PCE needs to be capable of specifying the server-layer path information when the server-layer path information is required to be returned to the PCC.
如[RFC5339]中所述，混合节点可公布具有多个交换能力的单个TE链路。通常，这些TE链路存在于层/区域边界。在这种情况下，当需要将服务器层路径信息返回到PCC时，PCE需要能够指定服务器层路径信息。
[RFC5623] describes models for inter-layer path computation in more detail. It introduces the Virtual Network Topology Manager (VNTM), a functional element that controls the VNT, and sets out three distinct models (and a fourth hybrid model) for inter-layer control involving a PCE, triggered signaling, and a Network Management System (NMS).
[RFC5623]更详细地描述了层间路径计算的模型。它介绍了虚拟网络拓扑管理器（VNTM），一种控制VNT的功能元件，并为涉及PCE、触发信令和网络管理系统（NMS）的层间控制提出了三种不同的模型（和第四种混合模型）。
This section describes PCEP extensions for inter-layer path computation. Four new objects are defined: the INTER-LAYER object, the SWITCH-LAYER object, the REQ-ADAP-CAP object, and the SERVER-INDICATION object. Also, two new metric types are defined.
本节介绍层间路径计算的PCEP扩展。定义了四个新对象：层间对象、交换层对象、REQ-ADAP-CAP对象和服务器指示对象。此外，还定义了两种新的度量类型。
The INTER-LAYER object is optional and can be used in Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages, and also in Path Computation State Report (PCRpt), Path Computation Update Request (PCUpd), and Path Computation LSP Initiate Request (PCInitiate) messages.
层间对象是可选的，可以在路径计算请求（PCReq）和路径计算回复（PCRep）消息中使用，也可以在路径计算状态报告（PCRpt）、路径计算更新请求（PCUpd）和路径计算LSP启动请求（PCInitiate）消息中使用。
In a PCReq message, the INTER-LAYER object indicates whether inter-layer path computation is allowed, the type of path to be computed, and whether triggered signaling (hierarchical LSPs per [RFC4206] or stitched LSPs per [RFC5150] depending on physical network technologies) is allowed. When the INTER-LAYER object is absent from a PCReq message, the receiving PCE MUST process as though inter-layer path computation had been explicitly disallowed (I-bit set to zero -- see below).
在PCReq消息中，层间对象指示是否允许层间路径计算、要计算的路径类型，以及是否允许触发信令（根据物理网络技术，每个[RFC4206]的分层LSP或每个[RFC5150]的缝合LSP）。当层间对象不在PCReq消息中时，接收PCE必须进行处理，就像层间路径计算被明确禁止一样（I位设置为零——见下文）。
In a PCRep message, the INTER-LAYER object indicates whether inter-layer path computation has been performed, the type of path that has been computed, and whether triggered signaling is used.
在PCRep消息中，层间对象指示是否已执行层间路径计算、已计算的路径类型以及是否使用触发的信令。
When a PCReq message includes more than one request, an INTER-LAYER object is used per request. When a PCRep message includes more than one path per request that is responded to, an INTER-LAYER object is used per path.
当PCReq消息包含多个请求时，每个请求使用层间对象。当PCRep消息包含每个响应请求的多个路径时，每个路径使用层间对象。
The applicability of this object to PCRpt and PCUpd messages is the same as for other objects on those messages as described in [RFC8231]. The applicability of this object to the PCInitiate message is the same as for other objects on those messages as described in [RFC8281]. These messages use the <attribute-list> as defined in [RFC5440] and extended by further PCEP extensions, so the <attribute-list> as extended in Section 5 can be used to include the INTER-LAYER object on these messages.
此对象对PCRpt和PCUpd消息的适用性与[RFC8231]中描述的这些消息上的其他对象相同。此对象对PCInitiate消息的适用性与[RFC8281]中所述的那些消息上的其他对象的适用性相同。这些消息使用[RFC5440]中定义的<attribute list>，并通过进一步的PCEP扩展进行扩展，因此第5节中扩展的<attribute list>可用于在这些消息上包括层间对象。
INTER-LAYER Object-Class is 36.
层间对象类为36。
Inter-layer Object-Type is 1.
层间对象类型为1。
The format of the INTER-LAYER object body is shown in Figure 1.
层间对象体的格式如图1所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T|M|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |T|M|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The INTER-LAYER Object
图1：层间对象
I flag (1 bit): The I flag is used by a PCC in a PCReq message to indicate to a PCE whether an inter-layer path is allowed. When the I flag is set (one), the PCE MAY perform inter-layer path computation and return an inter-layer path. When the flag is clear (zero), the path that is returned MUST NOT be an inter-layer path.
I标志（1位）：PCC在PCReq消息中使用I标志向PCE指示是否允许层间路径。当I标志被设置（一）时，PCE可以执行层间路径计算并返回层间路径。当标志清除（零）时，返回的路径不能是层间路径。
The I flag is used by a PCE in a PCRep message to indicate to a PCC whether the path returned is an inter-layer path. When the I flag is set (one), the path is an inter-layer path. When it is clear (zero), the path is contained within a single layer because either inter-layer path computation was not performed or a mono-layer path (without any virtual TE link and without any loose hop that spans the lower-layer network) was found notwithstanding the use of inter-layer path computation.
PCE在PCRep消息中使用I标志向PCC指示返回的路径是否为层间路径。设置I标志（一）时，路径为层间路径。当清除（零）时，路径包含在单个层中，因为未执行层间路径计算，或者发现单层路径（没有任何虚拟TE链路，也没有跨越下层网络的任何松散跃点），尽管使用层间路径计算。
M flag (1 bit): The M flag is used by a PCC in a PCReq message to indicate to a PCE whether a mono-layer path or multi-layer path is requested. When the M flag is set (one), a multi-layer path is requested. When it is clear (zero), a mono-layer path is requested.
M标志（1位）：PCC在PCReq消息中使用M标志向PCE指示是请求单层路径还是多层路径。当设置M标志（一）时，将请求多层路径。清除（零）时，请求单层路径。
The M flag is used by a PCE in a PCRep message to indicate to a PCC whether a mono-layer path or multi-layer path is returned. When the M flag is set (one), a multi-layer path is returned. When the M flag is clear (zero), a mono-layer path is returned.
PCE在PCRep消息中使用M标志向PCC指示是返回单层路径还是多层路径。当设置M标志（一）时，将返回多层路径。当M标志清除（零）时，返回单层路径。
If the I flag is clear (zero), the M flag has no meaning and MUST be ignored.
如果I标志为清除（零），则M标志没有意义，必须忽略。
[RFC6457] describes two sub-options for mono-layer path.
[RFC6457]描述了单层路径的两个子选项。
o A mono-layer path that is specified by strict hops. The path may include virtual TE links.
o 由严格跃点指定的单层路径。该路径可以包括虚拟TE链路。
o A mono-layer path that includes loose hops that span the lower-layer network.
o 一种单层路径，包括跨越下层网络的松散跃点。
The choice of this sub-option can be specified by the use of the O flag in the Request Parameter (RP) object specified in [RFC5440].
此子选项的选择可以通过在[RFC5440]中指定的请求参数（RP）对象中使用O标志来指定。
T flag (1 bit): The T flag is used by a PCC in a PCReq message to indicate to a PCE whether triggered signaling is allowed. When the T flag is set (one), triggered signaling is allowed. When it is clear (zero), triggered signaling is not allowed.
T标志（1位）：PCC在PCReq消息中使用T标志向PCE指示是否允许触发信令。当设置T标志（一）时，允许触发信令。清除（零）时，不允许触发信号。
The T flag is used by a PCE in a PCRep message to indicate to a PCC whether triggered signaling is required to support the returned path. When the T flag is set (one), triggered signaling is required. When it is clear (zero), triggered signaling is not required.
PCE在PCRep消息中使用T标志向PCC指示是否需要触发信令来支持返回路径。当设置T标志（一）时，需要触发信号。清除（零）时，不需要触发信号。
Note that triggered signaling is used to support hierarchical [RFC4206] or stitched [RFC5150] LSPs according to the physical attributes of the network layers.
注意，触发信令用于根据网络层的物理属性支持分层[RFC4206]或缝合[RFC5150]LSP。
If the I flag is clear (zero), the T flag has no meaning and MUST be ignored.
如果I标志为清除（零），则T标志没有意义，必须忽略。
Note that the I and M flags differ in the following ways. When the I flag is clear (zero), virtual TE links must not be used in path computation. In addition, loose hops that span the lower-layer network must not be specified. Only regular TE links from the same layer may be used.
请注意，I和M标志在以下方面有所不同。当I标志清除（零）时，虚拟TE链路不得用于路径计算。此外，不得指定跨越较低层网络的松散跃点。只能使用来自同一层的常规TE链接。
o When the I flag is set (one), the M flag is clear (zero), and the T flag is set (one), virtual TE links are allowed in path computation. In addition, when the O flag of the RP object is set, loose hops that span the lower-layer network may be specified. This will initiate lower-layer LSP setup; thus, the inter-layer path is set up even though the path computation result from a PCE to a PCC includes hops from the same layer only.
o 当设置I标志（1）、清除M标志（0）和设置T标志（1）时，允许在路径计算中使用虚拟TE链路。此外，当设置RP对象的O标志时，可以指定跨越较低层网络的松散跳数。这将启动低层LSP设置；因此，即使从PCE到PCC的路径计算结果仅包括来自同一层的跳，也建立层间路径。
o However, when the I flag is set (one), the M flag is clear (zero), and the T flag is clear (zero), since triggered signaling is not allowed, virtual TE links that have not been pre-signaled MUST NOT be used in path computation. In addition, loose hops that span the lower-layer network MUST NOT be specified. Therefore, this is equivalent to the I flag being clear (zero).
o 然而，当设置I标志（一）、M标志为清除（零）且T标志为清除（零）时，由于不允许触发信令，因此在路径计算中不得使用未预发信令的虚拟TE链路。此外，不得指定跨越较低层网络的松散跃点。因此，这相当于I标志清除（零）。
Reserved bits of the INTER-LAYER object sent between a PCC and PCE in the same domain MUST be transmitted as zero and SHOULD be ignored on receipt. A PCE that forwards a path computation request to other PCEs MUST preserve the settings of reserved bits in the PCReq messages it sends and in the PCRep messages it forwards to PCCs.
在同一域中的PCC和PCE之间发送的层间对象的保留位必须作为零传输，并且在接收时应忽略。将路径计算请求转发给其他PCE的PCE必须在其发送的PCReq消息和转发给PCC的PCRep消息中保留保留位的设置。
Note that the flags in the PCRpt message indicate the state of an LSP, whereas the flags in the PCUpd and the PCInitiate messages indicate the intended/desired state as determined by the PCE.
请注意，PCRpt消息中的标志指示LSP的状态，而PCUpd和PCInitiate消息中的标志指示PCE确定的预期/期望状态。
The SWITCH-LAYER object is optional on a PCReq message and specifies switching layers in which a path MUST, or MUST NOT, be established. A switching layer is expressed as a switching type and encoding type.
SWITCH-LAYER对象在PCReq消息上是可选的，并指定必须或不必须在其中建立路径的交换层。交换层表示为交换类型和编码类型。
When a SWITCH-LAYER object is used on a PCReq, it is interpreted in the context of the INTER-LAYER object on the same message. If no INTER-LAYER object is present, the PCE MUST process the SWITCH-LAYER object as though inter-layer path computation had been explicitly disallowed. In such a case, the SWITCH-LAYER object MUST NOT have more than one LSP Encoding Type and Switching Type with the I flag set.
当在PCReq上使用开关层对象时，将在同一消息上的层间对象上下文中对其进行解释。如果不存在层间对象，则PCE必须处理交换层对象，就像明确禁止层间路径计算一样。在这种情况下，切换层对象不能有多个LSP编码类型和设置了I标志的切换类型。
The SWITCH-LAYER object is optional on a PCRep message, where it is used with the NO-PATH object in the case of unsuccessful path computation to indicate the set of constraints that could not be satisfied.
切换层对象在PCRep消息上是可选的，在路径计算失败的情况下，它与无路径对象一起使用，以指示无法满足的约束集。
The SWITCH-LAYER object may be used on a PCRpt message consistent with how properties of existing LSPs are reported on that message [RFC8231]. The PCRpt message uses the <attribute-list> as defined in [RFC5440] and extended by further PCEP extensions. This message can use the <attribute-list> as extended in Section 5 to carry the SWITCH-LAYER object. The SWITCH-LAYER object is not used on a PCUpd or PCInitiate messages.
交换层对象可用于PCRpt消息，该消息与现有LSP的属性在该消息上的报告方式一致[RFC8231]。PCRpt消息使用[RFC5440]中定义的<attribute list>，并通过进一步的PCEP扩展进行扩展。此消息可以使用第5节中扩展的<attribute list>来承载开关层对象。交换机层对象不用于PCUpd或PCInitiate消息。
SWITCH-LAYER Object-Class is 37.
开关层对象类是37。
Switch-layer Object-Type is 1.
开关层对象类型为1。
The format of the SWITCH-LAYER object body is shown in Figure 2.
开关层对象体的格式如图2所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
// . //
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
// . //
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | Reserved |I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The SWITCH-LAYER Object
图2:SWITCH-LAYER对象
Each row indicates a switching type and encoding type that must or must not be used for a specified layer(s) in the computed path.
每行表示一种交换类型和编码类型，该类型必须或不能用于计算路径中的指定层。
The format is based on [RFC3471] and has equivalent semantics.
该格式基于[RFC3471]，具有等效语义。
LSP Encoding Type (8 bits): see [RFC3471] for a description of parameters.
LSP编码类型（8位）：有关参数的说明，请参阅[RFC3471]。
Switching Type (8 bits): see [RFC3471] for a description of parameters.
开关类型（8位）：有关参数的说明，请参见[RFC3471]。
I flag (1 bit): the I flag indicates whether a layer with the specified switching type and encoding type must or must not be used by the computed path. When the I flag is set (one), the computed path MUST traverse a layer with the specified switching type and encoding type. When the I flag is clear (zero), the computed path MUST NOT enter or traverse any layer with the specified switching type and encoding type.
I标志（1位）：I标志指示具有指定交换类型和编码类型的层是否必须由计算路径使用。设置I标志（一）时，计算路径必须穿过具有指定切换类型和编码类型的层。当I标志清除（零）时，计算路径不得进入或穿过具有指定切换类型和编码类型的任何层。
When a combination of switching type and encoding type is not included in the SWITCH-LAYER object, the computed path MAY traverse a layer with that combination of switching type and encoding type.
当切换类型和编码类型的组合不包括在切换层对象中时，计算出的路径可以穿过具有该切换类型和编码类型组合的层。
A PCC may want to specify only a Switching Type and not an LSP Encoding Type. In this case, the LSP Encoding Type is set to zero.
PCC可能只希望指定交换类型，而不希望指定LSP编码类型。在这种情况下，LSP编码类型设置为零。
The REQ-ADAP-CAP object is optional and is used to specify a requested adaptation capability for both ends of the lower-layer LSP. The REQ-ADAP-CAP object is used in a PCReq message for inter-PCE communication, where the PCE that is responsible for computing higher-layer paths acts as a PCC to request a path computation from a PCE that is responsible for computing lower-layer paths.
REQ-ADAP-CAP对象是可选的，用于为下层LSP的两端指定请求的自适应能力。REQ-ADAP-CAP对象用于PCE间通信的PCReq消息中，其中负责计算高层路径的PCE充当PCC，从负责计算底层路径的PCE请求路径计算。
The REQ-ADAP-CAP object is used in a PCRep message in case of unsuccessful path computation (in this case, the PCRep message also contains a NO-PATH object, and the REQ-ADAP-CAP object is used to indicate the set of constraints that could not be satisfied).
路径计算不成功时，在PCRep消息中使用REQ-ADAP-CAP对象（在这种情况下，PCRep消息还包含无路径对象，REQ-ADAP-CAP对象用于指示无法满足的约束集）。
The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono-layer network to specify a requested adaptation capability for both ends of the LSP. In this case, it MAY be carried without an INTER-LAYER object.
REQ-ADAP-CAP对象可用于单层网络中的PCReq消息中，以指定LSP两端的请求自适应能力。在这种情况下，可以在没有层间对象的情况下携带它。
The applicability of this object to PCRpt and PCUpd messages is the same as for other objects on those messages as described in [RFC8231]. The applicability of this object to the PCInitiate
此对象对PCRpt和PCUpd消息的适用性与[RFC8231]中描述的这些消息上的其他对象相同。此对象对PCO的适用性
message is the same as for other objects on those messages as described in [RFC8281]. These messages use the <attribute-list> as defined in [RFC5440] and extended by further PCEP extensions. These messages can use the <attribute-list> as extended in Section 5 to carry the REQ-ADAP-CAP object.
消息与[RFC8281]中描述的那些消息上的其他对象相同。这些消息使用[RFC5440]中定义的<attribute list>，并通过进一步的PCEP扩展进行扩展。这些消息可以使用第5节中扩展的<attribute list>来携带REQ-ADAP-CAP对象。
REQ-ADAP-CAP Object-Class is 38.
REQ-ADAP-CAP对象类为38。
Req-Adap-Cap Object-Type is 1.
Req Adap Cap对象类型为1。
The format of the REQ-ADAP-CAP object body is shown in Figure 3.
REQ-ADAP-CAP对象体的格式如图3所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The REQ-ADAP-CAP Object
图3:REQ-ADAP-CAP对象
The format is based on [RFC6001] and has equivalent semantics as the Interface Adjustment Capability Descriptor (IACD) Upper Switching Capability and Lower Switching Capability fields.
该格式基于[RFC6001]，并具有与接口调整能力描述符（IACD）上切换能力和下切换能力字段等效的语义。
Switching Capability (8 bits): see [RFC4203] for a description of parameters.
交换能力（8位）：有关参数的说明，请参见[RFC4203]。
Encoding (8 bits): see [RFC3471] for a description of parameters.
编码（8位）：有关参数的说明，请参见[RFC3471]。
A PCC may want to specify a Switching Capability, but not an Encoding. In this case, the Encoding MUST be set to zero.
PCC可能希望指定交换能力，但不希望指定编码。在这种情况下，编码必须设置为零。
This document defines two new metric types for use in the PCEP METRIC object.
本文档定义了用于PCEP度量对象的两种新度量类型。
IANA has assigned the value 18 to indicate the metric "Number of adaptations on a path".
IANA已指定值18，以指示度量“路径上的自适应数”。
IANA has assigned the value 19 to indicate the metric "Number of layers on a path".
IANA已指定值19，以指示度量“路径上的层数”。
See Sections 4.1, 4.2, and 4.3 for a description of how these metrics are applied.
有关如何应用这些指标的说明，请参见第4.1、4.2和4.3节。
The SERVER-INDICATION is optional and is used to indicate that path information included in the Explicit Route Object (ERO) is server-layer information, and it specifies the characteristics of the server layer, e.g., the switching capability and encoding of the server-layer path.
服务器层指示是可选的，用于指示显式路由对象（ERO）中包含的路径信息是服务器层信息，并指定服务器层的特征，例如，服务器层路径的交换能力和编码。
The format of the SERVER-INDICATION object body is shown in Figure 4.
服务器指示对象主体的格式如图4所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Switching Cap | Encoding | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The SERVER-INDICATION Object
图4：服务器端指示对象
SERVER-INDICATION Object-Class is 39.
服务器对象类为39。
Server-indication Object-Type is 1.
服务器指示对象类型为1。
Switching Capability (8 bits): see [RFC4203] for a description of parameters.
交换能力（8位）：有关参数的说明，请参见[RFC4203]。
Encoding (8 bits): see [RFC3471] for a description of parameters.
编码（8位）：有关参数的说明，请参见[RFC3471]。
Optional TLVs: Optional TLVs MAY be included within the object to specify more specific server-layer path information (e.g., traffic parameters). Such TLVs will be defined by other documents.
可选TLV：对象中可能包含可选TLV，以指定更具体的服务器层路径信息（例如，流量参数）。此类TLV将由其他文件定义。
A PCC requests or allows inter-layer path computation in a PCReq message by including the INTER-LAYER object with the I flag set. The INTER-LAYER object indicates whether inter-layer path computation is allowed, which path type is requested, and whether triggered signaling is allowed.
PCC通过包括设置了I标志的层间对象，请求或允许在PCReq消息中进行层间路径计算。层间对象指示是否允许层间路径计算、请求的路径类型以及是否允许触发信令。
The SWITCH-LAYER object, which MUST NOT be present unless the INTER-LAYER object is also present, is optionally used to specify the switching types and encoding types that define layers that must, or must not, be used in the computed path. When the SWITCH-LAYER object is used with the INTER-LAYER object I flag clear (zero), inter-layer
交换层对象（除非层间对象也存在，否则该对象不得存在）可选择性地用于指定交换类型和编码类型，这些类型定义了计算路径中必须或不得使用的层。当开关层对象与层间对象I标志清除（零）一起使用时，层间
path computation is not allowed, but constraints specified in the SWITCH-LAYER object apply. Example usage includes path computation in a single-layer GMPLS network.
不允许进行路径计算，但应用开关层对象中指定的约束。示例用法包括单层GMPLS网络中的路径计算。
The REQ-ADAP-CAP object is optionally used to specify the interface switching capability of both ends of the lower-layer LSP. The REQ-ADAP-CAP object is used in inter-PCE communication, where the PCE that is responsible for computing higher-layer paths makes a request as a PCC to a PCE that is responsible for computing lower-layer paths. Alternatively, the REQ-ADAP-CAP object may be used in the NMS-VNTM model, where the VNTM makes a request as a PCC to a PCE that is responsible for computing lower-layer paths.
REQ-ADAP-CAP对象可选地用于指定下层LSP两端的接口交换能力。REQ-ADAP-CAP对象用于PCE间通信，其中负责计算高层路径的PCE作为PCC向负责计算底层路径的PCE发出请求。或者，REQ-ADAP-CAP对象可在NMS-VNTM模型中使用，其中VNTM向负责计算较低层路径的PCE发出作为PCC的请求。
The METRIC object is optionally used to specify metric types to be optimized or bounded. When metric type 18 is used, it indicates that path computation MUST minimize or bound the number of adaptations on a path. When metric type 19 is used, it indicates that path computation MUST minimize or bound the number of layers to be involved on a path.
公制对象可用于指定要优化或有界的公制类型。当使用度量类型18时，它指示路径计算必须最小化或限制路径上的自适应数量。当使用度量类型19时，它表示路径计算必须最小化或限制路径上涉及的层数。
Furthermore, in order to allow different Objective Functions (OFs) to be applied within different network layers, multiple OF objects [RFC5541] MAY be present. In such a case, the first OF object specifies an objective function for the higher-layer network, and subsequent OF objects specify objection functions of the subsequent lower-layer networks.
此外，为了允许在不同的网络层内应用不同的目标函数（OF），可以存在多个对象[RFC5541]。在这种情况下，第一个对象指定高层网络的目标函数，后续对象指定后续下层网络的目标函数。
In the case of successful path computation, the requested PCE replies to the requesting PCC for the inter-layer path computation result in a PCRep message that MAY include the INTER-LAYER object. When the INTER-LAYER object is included in a PCRep message, the I, M, and T flags indicate semantics of the path as described in Section 3.1. Furthermore, when the C flag of the METRIC object in a PCReq is set, the METRIC object MUST be included in the PCRep to provide the computed metric value, as specified in [RFC5440].
在路径计算成功的情况下，所请求的PCE在PCRep消息中回复请求PCC以获得层间路径计算结果，该PCRep消息可以包括层间对象。当层间对象包含在PCRep消息中时，I、M和T标志表示路径的语义，如第3.1节所述。此外，当设置PCReq中度量对象的C标志时，必须将度量对象包括在PCRep中，以提供[RFC5440]中规定的计算度量值。
The PCE MAY specify the server-layer path information in the ERO. In this case, the requested PCE replies with a PCRep message that includes at least two sets of ERO information in the path-list: one is for the client-layer path information, and another one is the server-layer path information. When SERVER-INDICATION is included in a PCRep message, it indicates that the path in the ERO is the server-layer path information. The server-layer path specified in the ERO could be loose or strict. On receiving the replied path, the PCC (e.g., NMS and ingress node) can trigger the signaling to set up the LSPs according to the computed paths.
PCE可以在ERO中指定服务器层路径信息。在这种情况下，请求的PCE使用PCRep消息进行回复，该消息在路径列表中包括至少两组ERO信息：一组用于客户端层路径信息，另一组用于服务器层路径信息。当PCRep消息中包含服务器层指示时，它表示ERO中的路径是服务器层路径信息。ERO中指定的服务器层路径可能松散或严格。在接收到应答路径时，PCC（例如，NMS和入口节点）可以触发信令以根据计算出的路径设置lsp。
In the case of unsuccessful path computation, the PCRep message also contains a NO-PATH object, and the SWITCH-TYPE object and/or REQ-ADAP-CAP MAY be used to indicate the set of constraints that could not be satisfied.
在路径计算不成功的情况下，PCRep消息还包含无路径对象，开关类型对象和/或REQ-ADAP-CAP可用于指示无法满足的约束集。
Processing for stateful PCEs is described in [RFC8231]. That document defines the PCRpt message to allow a PCC to report to a PCE that an LSP already exists in the network and to delegate control of that LSP to the PCE.
[RFC8231]中描述了有状态PCE的处理。该文档定义了PCRpt消息，以允许PCC向PCE报告网络中已存在LSP，并将该LSP的控制权委托给PCE。
When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCRpt to describe an LSP that is delegated to the PCE so that the PCE may process the LSP.
当LSP是多层LSP（或存在特定适配的单层LSP）时，本文档中定义的消息对象在PCRpt上用于描述委托给PCE的LSP，以便PCE可以处理LSP。
Furthermore, [RFC8231] defines the PCUpd message to allow a PCE to modify an LSP that has been delegated to it. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCUpd to describe the new attributes of the modified LSP.
此外，[RFC8231]定义PCUpd消息以允许PCE修改已委托给它的LSP。当LSP是多层LSP（或存在特定改编的单层LSP）时，本文档中定义的消息对象将用于PCUpd，以描述修改后LSP的新属性。
Processing for PCE-initiated LSPs is described in [RFC8281]. That document defines the PCInitiate message that is used by a PCE to request a PCC to set up a new LSP. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCInitiate to describe the attributes of the new LSP.
[RFC8281]中描述了PCE启动的LSP的处理。该文档定义PCE用于请求PCC设置新LSP的PCInitiate消息。当LSP是多层LSP（或存在特定适配的单层LSP）时，本文档中定义的消息对象将用于PCInitiate来描述新LSP的属性。
The new metric types defined in this document can also be used with the stateful PCE extensions. The format of PCEP messages described in [RFC8231] and [RFC8281] uses <attribute-list> (which is extended in Section 5 for the purpose of including the new metrics).
本文档中定义的新度量类型也可以与有状态PCE扩展一起使用。[RFC8231]和[RFC8281]中描述的PCEP消息格式使用<attribute list>（在第5节中进行了扩展，以包括新的度量）。
The stateful PCE implementation MAY use the extension of PCReq and PCRep messages as defined in Section 5 to also enable the use of inter-layer parameters during passive stateful operations, using the LSP object.
有状态PCE实现可以使用第5节中定义的PCReq和PCRep消息的扩展，也可以使用LSP对象在被动有状态操作期间使用层间参数。
Message formats in this section, as those in [RFC5440], are presented using Routing Backus-Naur Format (RBNF) as specified in [RFC5511].
本节中的消息格式与[RFC5440]中的消息格式一样，使用[RFC5511]中规定的路由Backus-Naur格式（RBNF）表示。
The format of the PCReq message is updated as shown in Figure 5.
PCReq消息的格式更新如图5所示。
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
where:
<svec-list>::=<SVEC>
[<svec-list>]
where:
<svec-list>::=<SVEC>
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<of-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
[<INTER-LAYER> [<SWITCH-LAYER>]]
[<REQ-ADAP-CAP>]
where:
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<of-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
[<INTER-LAYER> [<SWITCH-LAYER>]]
[<REQ-ADAP-CAP>]
where:
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 5: The Updated PCReq Message
图5：更新的PCReq消息
The format of the PCRep message is updated as shown in Figure 6.
PCRep消息的格式更新如图6所示。
<PCRep Message> ::= <Common Header>
<response-list>
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
where:
<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>
where:
<attribute-list>::=[<of-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<INTER-LAYER>]
[<SWITCH-LAYER>]
[<REQ-ADAP-CAP>]
[<SERVER-INDICATION>]
where:
<attribute-list>::=[<of-list>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<INTER-LAYER>]
[<SWITCH-LAYER>]
[<REQ-ADAP-CAP>]
[<SERVER-INDICATION>]
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
<of-list>::=<OF>[<of-list>]
<metric-list>::=<METRIC>[<metric-list>]
Figure 6: The Updated PCRep Message
图6：更新的PCRep消息
Implementations of this specification should provide a mechanism to configure any optional features (such as whether a PCE supports inter-layer computation and which metrics are supported).
本规范的实现应提供一种机制来配置任何可选功能（例如PCE是否支持层间计算以及支持哪些指标）。
A Management Information Base (MIB) module for modeling PCEP is described in [RFC7420]. Systems that already use a MIB module to manage their PCEP implementations might want to augment that module to provide controls and indicators for support of inter-layer features defined in this document and to add counters of messages sent and received containing the objects defined here.
[RFC7420]中描述了用于PCEP建模的管理信息库（MIB）模块。已经使用MIB模块来管理其PCEP实现的系统可能希望扩展该模块，以提供控制和指示器，以支持本文档中定义的层间功能，并添加发送和接收的包含此处定义的对象的消息计数器。
However, the preferred mechanism for configuration is through a YANG model. Work has started on a YANG model for PCEP [PCEP-YANG], and this could be enhanced as described for the MIB module, above.
然而，首选的配置机制是通过YANG模型。关于PCEP[PCEP-YANG]的YANG模型的工作已经开始，这可以像上面针对MIB模块所描述的那样得到增强。
Additional policy configuration might be provided to allow a PCE to discriminate between the computation services offered to different PCCs.
可以提供额外的策略配置，以允许PCE区分提供给不同pcc的计算服务。
A set of monitoring tools for the PCE-based architecture are provided in [RFC5886]. Systems implementing this specification and PCE monitoring should consider defining extensions to the mechanisms defined in [RFC5886] to help monitor inter-layer path computation requests.
[RFC5886]中提供了一套用于基于PCE的体系结构的监控工具。实现此规范和PCE监视的系统应考虑定义对[RCF586]中定义的机制的扩展，以帮助监视层间路径计算请求。
IANA maintains a registry called "Path Computation Element Protocol (PCEP) Numbers". Per this document, IANA has carried out actions on subregistries of that registry.
IANA维护一个名为“路径计算元素协议（PCEP）编号”的注册表。根据本文件，IANA已在该登记册的分区域开展了行动。
IANA has made the following assignments in the "PCEP Objects" subregistry.
IANA在“PCEP对象”子区域进行了以下分配。
Object-Class Value | Name | Object-Type | Reference
-------------------+-------+-----------------------+-----------
INTER-LAYER | 36 | 0: Reserved | RFC 8282
| | 1: Inter-layer |
| | 2-15: Unassigned |
| | |
SWITCH-LAYER | 37 | 0: Reserved | RFC 8282
| | 1: Switch-layer |
| | 2-15: Unassigned |
| | |
REQ-ADAP-CAP | 38 | 0: Reserved | RFC 8282
| | 1: Req-Adap-Cap |
| | 2-15: Unassigned |
| | |
SERVER-INDICATION | 39 | 0: Reserved | RFC 8282
| | 1: Server-indication |
Object-Class Value | Name | Object-Type | Reference
-------------------+-------+-----------------------+-----------
INTER-LAYER | 36 | 0: Reserved | RFC 8282
| | 1: Inter-layer |
| | 2-15: Unassigned |
| | |
SWITCH-LAYER | 37 | 0: Reserved | RFC 8282
| | 1: Switch-layer |
| | 2-15: Unassigned |
| | |
REQ-ADAP-CAP | 38 | 0: Reserved | RFC 8282
| | 1: Req-Adap-Cap |
| | 2-15: Unassigned |
| | |
SERVER-INDICATION | 39 | 0: Reserved | RFC 8282
| | 1: Server-indication |
Figure 7: New PCEP Objects
图7：新的PCEP对象
IANA has created a new subregistry to manage the Flag field of the INTER-LAYER object called the "Inter-Layer Object Path Property Bits" registry.
IANA创建了一个新的子区域，用于管理层间对象的标志字段，称为“层间对象路径属性位”注册表。
New bit numbers may be allocated only by "IETF Review" [RFC8126]. Each bit should be tracked with the following qualities:
新位号只能由“IETF审查”[RFC8126]分配。应按照以下质量跟踪每个位：
o Bit number (counting from bit 0 as the most significant bit up to a maximum of bit 31)
o 位号（从作为最高有效位的位0开始计算，最多为位31）
o Capability Description
o 能力描述
o Defining RFC
o 定义RFC
IANA has populated the registry as follows:
IANA已填充注册表，如下所示：
Bit | Flag | Multi-Layer Path Property | Reference
----+------+-------------------------------+------------
0-28| | Unassigned |
29 | T | Triggered Signaling Allowed | RFC 8282
30 | M | Multi-Layer Requested | RFC 8282
31 | I | Inter-Layer Allowed | RFC 8282
Bit | Flag | Multi-Layer Path Property | Reference
----+------+-------------------------------+------------
0-28| | Unassigned |
29 | T | Triggered Signaling Allowed | RFC 8282
30 | M | Multi-Layer Requested | RFC 8282
31 | I | Inter-Layer Allowed | RFC 8282
Figure 8: New Registry for INTER-LAYER Object Flags
图8：层间对象标志的新注册表
Two new metric types are defined in this document for the METRIC object (specified in [RFC5440]). IANA has made the following allocations from the "Metric Object T Field" registry.
本文件为度量对象定义了两种新的度量类型（在[RFC5440]中指定）。IANA从“Metric Object T Field”注册表进行了以下分配。
Value | Description | Reference
------+---------------------------------+------------
18 | Number of adaptations on a path | RFC 8282
19 | Number of layers on a path | RFC 8282
Value | Description | Reference
------+---------------------------------+------------
18 | Number of adaptations on a path | RFC 8282
19 | Number of layers on a path | RFC 8282
Figure 9: New Metric Types
图9：新的度量类型
IANA has updated the registry to show the registration procedure of "IETF Review" as already documented in [RFC5440].
IANA已更新注册表，以显示[RFC5440]中已记录的“IETF审查”注册程序。
Inter-layer traffic engineering with PCE may raise new security issues when PCE-PCE communication is done between different layer networks for inter-layer path computation. Security issues may also exist when a single PCE is granted full visibility of TE information that applies to multiple layers.
当在不同层网络之间进行PCE-PCE通信以进行层间路径计算时，使用PCE的层间流量工程可能会提出新的安全问题。当单个PCE被授予适用于多个层的TE信息的完全可见性时，也可能存在安全问题。
The Path-Key-based mechanism defined in [RFC5520] MAY be applied to address the topology confidentiality between different layers.
[RFC5520]中定义的基于路径密钥的机制可用于解决不同层之间的拓扑机密性。
[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>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <https://www.rfc-editor.org/info/rfc3471>.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，DOI 10.17487/RFC3471，2003年1月<https://www.rfc-editor.org/info/rfc3471>.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, DOI 10.17487/RFC3945, October 2004, <https://www.rfc-editor.org/info/rfc3945>.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 3945，DOI 10.17487/RFC3945，2004年10月<https://www.rfc-editor.org/info/rfc3945>.
[RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <https://www.rfc-editor.org/info/rfc4203>.
[RFC4203]Kompella，K.，Ed.和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，DOI 10.17487/RFC4203，2005年10月<https://www.rfc-editor.org/info/rfc4203>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <https://www.rfc-editor.org/info/rfc4206>.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，DOI 10.17487/RFC4206，2005年10月<https://www.rfc-editor.org/info/rfc4206>.
[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>.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009, <https://www.rfc-editor.org/info/rfc5520>.
[RFC5520]Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，DOI 10.17487/RFC5520，2009年4月<https://www.rfc-editor.org/info/rfc5520>.
[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>.
[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, <https://www.rfc-editor.org/info/rfc8231>.
[RFC8231]Crabbe，E.，Minei，I.，Medved，J.，和R.Varga，“有状态PCE的路径计算元素通信协议（PCEP）扩展”，RFC 8231，DOI 10.17487/RFC82312017年9月<https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <http://www.rfc-editor.org/info/rfc20>.
[RFC8281]Crabbe，E.，Minei，I.，Sivabalan，S.，和R.Varga，“有状态PCE模型中PCE启动LSP设置的路径计算元素通信协议（PCEP）扩展”，RFC 8281，DOI 10.17487/RFC8281，2017年12月<http://www.rfc-editor.org/info/rfc20>.
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, June 2017.
[PCEP-YANG]杜迪，D.，哈德威克，J.，比拉姆，V.，和J。jefftant@gmail.com，“路径计算元件通信协议（PCEP）的YANG数据模型”，正在进行的工作，草稿-ietf-pce-PCEP-YANG-052017年6月。
[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>.
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008, <https://www.rfc-editor.org/info/rfc5150>.
[RFC5150]Ayyangar，A.，Kompella，K.，Vasseur，JP.，和A.Farrel，“使用通用多协议标签交换流量工程（GMPLS TE）的标签交换路径缝合”，RFC 5150，DOI 10.17487/RFC5150，2008年2月<https://www.rfc-editor.org/info/rfc5150>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, DOI 10.17487/RFC5212, July 2008, <https://www.rfc-editor.org/info/rfc5212>.
[RFC5212]Shiomoto，K.，Papadimitriou，D.，Le Roux，JL.，Vigoureux，M.，和D.Brungard，“基于GMPLS的多区域和多层网络（MRN/MLN）的要求”，RFC 5212，DOI 10.17487/RFC5212，2008年7月<https://www.rfc-editor.org/info/rfc5212>.
[RFC5339] Le Roux, JL., Ed. and D. Papadimitriou, Ed., "Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 5339, DOI 10.17487/RFC5339, September 2008, <https://www.rfc-editor.org/info/rfc5339>.
[RFC5339]Le Roux，JL.，Ed.和D.Papadimitriou，Ed.，“针对多层和多区域网络（MLN/MRN）评估现有GMPLS协议”，RFC 5339，DOI 10.17487/RFC5339，2008年9月<https://www.rfc-editor.org/info/rfc5339>.
[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>.
[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>.
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010, <https://www.rfc-editor.org/info/rfc5886>.
[RFC5886]Vasseur，JP.，Ed.，Le Roux，JL.，和Y.Ikejiri，“基于路径计算元素（PCE）架构的一套监控工具”，RFC 5886，DOI 10.17487/RFC5886，2010年6月<https://www.rfc-editor.org/info/rfc5886>.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/ MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010, <https://www.rfc-editor.org/info/rfc6001>.
[RFC6001]Papadimitriou，D.，Vigoureux，M.，Shiomoto，K.，Brungard，D.，和JL。Le Roux，“多层和多区域网络（MLN/MRN）的通用MPLS（GMPLS）协议扩展”，RFC 6001，DOI 10.17487/RFC6001，2010年10月<https://www.rfc-editor.org/info/rfc6001>.
[RFC6457] Takeda, T., Ed. and A. Farrel, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", RFC 6457, DOI 10.17487/RFC6457, December 2011, <https://www.rfc-editor.org/info/rfc6457>.
[RFC6457]武田，T.，Ed.和A.Farrel，“层间流量工程的PCC-PCE通信和PCE发现要求”，RFC 6457，DOI 10.17487/RFC6457，2011年12月<https://www.rfc-editor.org/info/rfc6457>.
[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>.
[RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, July 2016, <https://www.rfc-editor.org/info/rfc7926>.
[RFC7926]Farrel，A.，Ed.，Drake，J.，Bitar，N.，Swallow，G.，Ceccarelli，D.，和X.Zhang，“互联流量工程网络之间信息交换的问题陈述和体系结构”，BCP 206，RFC 7926，DOI 10.17487/RFC7926，2016年7月<https://www.rfc-editor.org/info/rfc7926>.
Acknowledgments
致谢
The authors would like to thank Cyril Margaria for his valuable comments. Helpful comments and suggested text were offered by Dhruv Dhody, who also fixed the RBNF. Jonathan Hardwick provided a helpful review as document shepherd.
作者要感谢Cyril Margaria的宝贵评论。Dhruv Dhody提供了有用的评论和建议文本，他还修复了RBNF。Jonathan Hardwick作为文档管理员提供了有用的评论。
Contributors
贡献者
Jean-Louis Le Roux France Telecom R&D Av Pierre Marzin Lannion 22300 France
Jean-Louis Le Roux法国电信研发Av Pierre Marzin Lannion 22300法国
Email: jeanlouis.leroux@orange.com
Email: jeanlouis.leroux@orange.com
Authors' Addresses
作者地址
Eiji Oki Kyoto University Yoshida-honmachi, Sakyo-ku, Kyoto Japan
日本京都阪洋区本町吉田京都大学
Email: oki@i.kyoto-u.ac.jp
Email: oki@i.kyoto-u.ac.jp
Tomonori Takeda NTT 3-9-11 Midori-cho Musashino-shi, Tokyo Japan
武田智诺里NTT 3-9-11 Midori cho Musashino shi，日本东京
Email: tomonori.takeda@ntt.com
Email: tomonori.takeda@ntt.com
Adrian Farrel Juniper Networks
Adrian Farrel Juniper Networks
Email: afarrel@juniper.net
Email: afarrel@juniper.net
Fatai Zhang Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District, Shenzhen 518129 China
中国深圳市龙岗区华为基地坂田区华为技术有限公司F3-5-B研发中心
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Phone: +86-755-28972912
Email: zhangfatai@huawei.com