Internet Engineering Task Force (IETF) T. Takeda, Ed.
Request for Comments: 6457 NTT
Category: Informational A. Farrel
ISSN: 2070-1721 Old Dog Consulting
December 2011
Internet Engineering Task Force (IETF) T. Takeda, Ed.
Request for Comments: 6457 NTT
Category: Informational A. Farrel
ISSN: 2070-1721 Old Dog Consulting
December 2011
PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering
层间流量工程的PCC-PCE通信和PCE发现要求
Abstract
摘要
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS).
在由多协议标签交换（MPLS）和广义MPLS（GMPLS）控制的网络中，路径计算单元（PCE）提供了支持流量工程的路径计算功能。
MPLS and GMPLS networks may be constructed from layered client/server networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers. PCE is a candidate solution for such requirements.
MPLS和GMPLS网络可以由分层的客户机/服务器网络构成。跨多个网络层提供端到端流量工程有利于提高整体网络效率。PCE是此类需求的候选解决方案。
Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements". Generic requirements for a PCE discovery protocol are presented in RFC 4674, "Requirements for Path Computation Element (PCE) Discovery".
RFC 4657“路径计算元件（PCE）通信协议通用要求”中介绍了路径计算客户端（PCC）和PCE之间通信协议的通用要求。RFC 4674“路径计算元素（PCE）发现要求”中介绍了PCE发现协议的一般要求。
This document complements the generic requirements and presents detailed sets of PCC-PCE communication protocol requirements and PCE discovery protocol requirements for inter-layer traffic engineering.
本文件补充了通用要求，并提供了层间流量工程的PCC-PCE通信协议要求和PCE发现协议要求的详细集合。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6457.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6457.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Motivation for PCE-Based Inter-Layer Path Computation ...........4
3. PCC-PCE Communication and Discovery Requirements for
Inter-Layer .....................................................4
3.1. PCC-PCE Communication ......................................5
3.1.1. Control of Inter-Layer Path Computation .............5
3.1.2. Control of the Type of Path to Be Computed ..........5
3.1.3. Communication of Inter-Layer Constraints ............6
3.1.4. Adaptation Capability ...............................7
3.1.5. Cooperation between PCEs ............................7
3.1.6. Inter-Layer Diverse Paths ...........................7
3.2. Capabilities Advertisements for PCE Discovery ..............7
3.3. Supported Network Models ...................................8
4. Manageability Considerations ....................................8
4.1. Control of Function and Policy .............................8
4.2. Information and Data Models ................................8
4.3. Liveness Detection and Monitoring ..........................8
4.4. Verifying Correct Operation ................................9
4.5. Requirements on Other Protocols and Functional Components ..9
4.6. Impact on Network Operation ................................9
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Motivation for PCE-Based Inter-Layer Path Computation ...........4
3. PCC-PCE Communication and Discovery Requirements for
Inter-Layer .....................................................4
3.1. PCC-PCE Communication ......................................5
3.1.1. Control of Inter-Layer Path Computation .............5
3.1.2. Control of the Type of Path to Be Computed ..........5
3.1.3. Communication of Inter-Layer Constraints ............6
3.1.4. Adaptation Capability ...............................7
3.1.5. Cooperation between PCEs ............................7
3.1.6. Inter-Layer Diverse Paths ...........................7
3.2. Capabilities Advertisements for PCE Discovery ..............7
3.3. Supported Network Models ...................................8
4. Manageability Considerations ....................................8
4.1. Control of Function and Policy .............................8
4.2. Information and Data Models ................................8
4.3. Liveness Detection and Monitoring ..........................8
4.4. Verifying Correct Operation ................................9
4.5. Requirements on Other Protocols and Functional Components ..9
4.6. Impact on Network Operation ................................9
5. Security Considerations ........................................10
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
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.
[RFC4655]中定义的路径计算元素（PCE）是能够基于网络图计算网络路径或路由并应用计算约束的实体。
A network may comprise multiple layers. These layers may represent the separation of technologies (e.g., Packet Switch Capable (PSC), Time Division Multiplex (TDM), lambda switch capable (LSC)) into GMPLS regions [RFC3945], the separation of data plane switching
网络可以包括多个层。这些层可以表示将技术（例如，支持分组交换（PSC）、时分复用（TDM）、支持lambda交换（LSC））分离到GMPLS区域[RFC3945]，分离数据平面交换
granularity levels (e.g., PSC-1 and PSC-2 or Virtual Circuit 4 (VC4) and VC12) into GMPLS layers [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 upper-layer LSPs. The network topology formed by lower-layer LSPs and advertised to the higher layer is called a "Virtual Network Topology (VNT)" [RFC5212].
GMPLS层[RFC5212]的粒度级别（例如PSC-1和PSC-2或虚拟电路4（VC4）和VC12），或客户机和服务器网络角色之间的区别（例如，客户机和服务器网络的商业或管理分离）。在这种多层网络中，下层的标签交换路径（LSP）用于承载上层LSP。由较低层LSP形成并播发到较高层的网络拓扑称为“虚拟网络拓扑（VNT）”[RFC5212]。
In layered networks under the operation of Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) protocols, it is important to provide mechanisms to allow global optimization of network resources. That is, to take 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 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].
在多协议标签交换流量工程（MPLS-TE）和通用MPLS（GMPLS）协议运行的分层网络中，提供允许网络资源全局优化的机制非常重要。也就是说，要考虑所有层，而不是单独优化每层的资源利用率。这样可以实现更好的网络效率。这就是我们所说的“层间流量工程”。这包括允许跨层计算端到端路径的机制（称为“层间路径计算”），以及通过在较低层中设置和释放LSP来控制和管理VNT的机制[RFC5212]。
Inter-layer traffic engineering is included in the scope of the PCE architecture [RFC4655], and PCE can provide a suitable mechanism for resolving inter-layer path computation issues. The applicability of the PCE-based path computation architecture to inter-layer traffic engineering is described in [RFC5623].
层间流量工程包含在PCE体系结构[RFC4655]的范围内，PCE可以为解决层间路径计算问题提供合适的机制。[RFC5623]中描述了基于PCE的路径计算体系结构对层间流量工程的适用性。
This document presents sets of requirements for communication between Path Computation Clients (PCCs) and PCEs using the PCE Communication Protocol (PCEP) and for PCE discovery for inter-layer traffic engineering. It supplements the generic requirements documented in [RFC4657], [RFC4674], and the framework provided in [RFC5623].
本文档介绍了使用PCE通信协议（PCEP）的路径计算客户端（PCC）和PCE之间的通信以及层间流量工程的PCE发现的一系列要求。它补充了[RFC4657]、[RFC4674]中记录的通用需求以及[RFC5623]中提供的框架。
LSP: Label Switched Path.
标签交换路径。
LSR: Label Switching Router.
标签交换路由器。
PCC: A Path Computation Client is any client entity (component, application or network node) requesting a path computation to be performed by a Path Computation Element.
PCC：路径计算客户端是请求由路径计算元素执行路径计算的任何客户端实体（组件、应用程序或网络节点）。
PCE: A Path Computation Element is an entity that is capable of computing a network path or route based on a network graph and applying computational constraints.
PCE：路径计算元素是能够基于网络图计算网络路径或路由并应用计算约束的实体。
PCEP: A PCE Communication Protocol is a protocol for communication between PCCs and PCEs.
PCEP：PCE通信协议是PCC和PCE之间的通信协议。
Although this requirements document is informational and not a protocol specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119] for clarity of requirement specification.
尽管本要求文件是信息性文件，不是协议规范，但为了明确要求规范，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
[RFC4206] defines a way to signal an MPLS or a GMPLS LSP with an explicit route in a higher layer of a network that includes hops traversed by LSPs in lower layers of the network. The computation of end-to-end paths across layers is called "inter-layer path computation".
[RFC4206]定义了一种在网络的较高层用显式路由向MPLS或GMPLS LSP发送信号的方法，该显式路由包括网络较低层中LSP穿过的跳。跨层端到端路径的计算称为“层间路径计算”。
An LSR in the higher layer might not have information on the topology of lower layers, particularly in an overlay or augmented model; hence, it might not be able to compute an end-to-end path across layers.
较高层中的LSR可能没有关于较低层拓扑的信息，尤其是在覆盖或增强模型中；因此，它可能无法计算跨层的端到端路径。
PCE-based inter-layer path computation consists of relying on one or more PCEs to compute an end-to-end path across layers. This could rely on a single PCE path computation where the PCE 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 as a multiple PCE computation, where each member of a set of PCEs has information about the topology of one or more layers, but not all layers, and they collaborate to compute an end-to-end path.
基于PCE的层间路径计算包括依赖一个或多个PCE来计算跨层的端到端路径。这可能依赖于单个PCE路径计算，其中PCE具有关于多个层的拓扑信息，并且可以考虑所有层的拓扑直接计算跨层的端到端路径。或者，层间路径计算可以作为多个PCE计算来执行，其中一组PCE的每个成员具有关于一个或多个层（而不是所有层）的拓扑的信息，并且它们协作以计算端到端路径。
Consider a two-layer network where the higher-layer network is a packet-based IP/MPLS or GMPLS network and the lower-layer network is a GMPLS-controlled optical network. An ingress LSR in the higher-layer network tries to set up an LSP to an egress LSR also in the higher-layer network across the lower-layer network, and it needs a path in the higher-layer network. However, suppose that there is no TE link between border LSRs, which are located on the boundary between the higher-layer and lower-layer networks, and that the ingress LSR does not have topology visibility in the lower layer. If a single-layer path computation is applied for the higher layer, the path computation fails. On the other hand, inter-layer path computation is able to provide a route in the higher layer and a suggestion that a lower-layer LSP be set up between border LSRs, considering both layers as TE topologies.
考虑两层网络，其中上层网络是基于分组的IP/MPLS或GMPLS网络，而下层网络是GMPLS控制的光网络。高层网络中的入口LSR尝试在较低层网络上建立到高层网络中的出口LSR的LSP，并且它需要在较高层网络中的路径。然而，假设边界LSR之间不存在TE链路，其位于高层和下层网络之间的边界上，并且入口LSR在下层中不具有拓扑可见性。如果对较高层应用单层路径计算，则路径计算失败。另一方面，层间路径计算能够在较高层中提供路由，并建议在边界LSR之间建立较低层LSP，将两层都视为TE拓扑。
Further discussion of the application of PCE to inter-layer path computation can be found in [RFC5623].
有关PCE在层间路径计算中的应用的进一步讨论，请参见[RFC5623]。
3. PCC-PCE Communication and Discovery Requirements for Inter-Layer Traffic Engineering
3. 层间流量工程的PCC-PCE通信和发现要求
This section provides additional requirements specific to the problems of multi-layer TE that are not covered in [RFC4657] or [RFC4674].
本节提供了[RFC4657]或[RFC4674]中未涉及的多层TE问题的特定附加要求。
PCEP MUST allow requests and replies for inter-layer path computation.
PCEP必须允许层间路径计算的请求和响应。
This requires no additional messages, but it implies the following additional constraints to be added to PCEP.
这不需要额外的消息，但它意味着要向PCEP添加以下额外的约束。
A request from a PCC to a PCE MUST support the inclusion of an optional indication of whether inter-layer path computation is allowed. In the absence of such an indication, the default is that inter-layer path computation is not allowed.
从PCC到PCE的请求必须支持包含是否允许层间路径计算的可选指示。在没有此类指示的情况下，默认情况是不允许层间路径计算。
The PCE computes and returns a path to the PCC that the PCC can use to build a higher-layer or lower-layer LSP once converted to an Explicit Route Object (ERO) for use in RSVP - Traffic Engineering (RSVP-TE) signaling. There are two options [RFC5623].
PCE计算并返回到PCC的路径，一旦PCC转换为显式路由对象（ERO）以用于RSVP-流量工程（RSVP-TE）信令，PCC就可以使用该路径来构建更高层或更低层LSP。有两个选项[RFC5623]。
- Option 1: Mono-Layer Path. The PCE computes a "mono-layer" path, i.e., a path that includes only TE links from the same layer.
- 选项1：单层路径。PCE计算“单层”路径，即仅包括来自同一层的TE链路的路径。
- Option 2: Multi-Layer Path. The PCE computes a "multi-layer" path, i.e., a path that includes TE links from distinct layers [RFC4206].
- 选项2：多层路径。PCE计算“多层”路径，即包括来自不同层的TE链路的路径[RFC4206]。
It may be necessary or desirable for a PCC to control the type of path that is produced by a PCE. For example, a PCC may know that it is not possible, for technological or policy reasons, to signal a multi-layer path and that a mono-layer path is required, or the PCC may know that it does not wish the layer border node to have control of path computation. In order to make this level of control possible, PCEP MUST allow the PCC to select the path types to be computed, and that may be returned, by choosing one or more from the following list:
PCC控制由PCE产生的路径的类型可能是必要的或期望的。例如，PCC可能知道由于技术或政策原因，不可能向多层路径发送信号，并且需要单层路径，或者PCC可能知道它不希望层边界节点控制路径计算。为了实现这一控制级别，PCEP必须允许PCC通过从以下列表中选择一个或多个来选择要计算的路径类型以及可能返回的路径类型：
- A mono-layer path that is specified by strict hop(s). The path may include virtual TE link(s).
- 由严格跃点指定的单层路径。该路径可以包括虚拟TE链路。
- A mono-layer path that includes loose hop(s).
- 包含松散跃点的单层路径。
- A multi-layer path that can include the path (as strict or loose hops) of one or more lower-layer LSPs not yet established.
- 一种多层路径，可包括一个或多个尚未建立的较低层LSP的路径（作为严格跳数或松散跳数）。
The path computation response from a PCE to a PCC MUST report the type of path computed, and where a multi-layer path is returned, PCEP MUST support the inclusion, as part of end-to-end path, of the path of the lower-layer LSPs to be established.
从PCE到PCC的路径计算响应必须报告计算的路径类型，并且在返回多层路径的情况下，PCEP必须支持将要建立的较低层LSP的路径包括在内，作为端到端路径的一部分。
If a response message from a PCE to PCC carries a mono-layer path that is specified by strict hops but includes virtual TE link(s), includes loose hop(s), or carries a multi-layer path that can include the complete path of one or more lower-layer LSPs not yet established, the signaling of the higher-layer LSP may trigger the establishment of the lower-layer LSPs (triggered signaling). The triggered signaling may increase the higher-layer connection setup latency. An ingress LSR for the higher-layer LSP, or a PCC, needs to know whether or not triggered signaling is required.
如果从PCE到PCC的响应消息携带由严格跳数指定但包括虚拟TE链路的单层路径，包括松散跳数，或携带可包括一个或多个尚未建立的较低层LSP的完整路径的多层路径，上层LSP的信令可以触发下层LSP的建立（触发信令）。触发的信令可能会增加高层连接设置延迟。高层LSP或PCC的入口LSR需要知道是否需要触发信令。
A request from a PCC to a PCE MUST allow indicating whether or not triggered signaling is acceptable.
从PCC到PCE的请求必须允许指示触发的信令是否可接受。
A response from a PCE to a PCC MUST allow indicating whether or not the computed path requires triggered signaling.
从PCE到PCC的响应必须允许指示计算路径是否需要触发信令。
Note that a PCE may not be able to distinguish virtual TE links from regular TE links. In such cases, even if a request from a PCC to a PCE indicates that triggered signaling is not acceptable, a PCE may choose virtual TE links in path computation. Therefore, when a network uses virtual TE links and a PCE is not able to distinguish virtual TE links from regular TE links, a PCE MAY choose virtual TE links even if a request from a PCC to a PCE indicates triggered signaling is not acceptable.
请注意，PCE可能无法区分虚拟TE链路和常规TE链路。在这种情况下，即使从PCC到PCE的请求指示触发的信令不可接受，PCE也可以在路径计算中选择虚拟TE链路。因此，当网络使用虚拟TE链路并且PCE不能区分虚拟TE链路和常规TE链路时，即使从PCC到PCE的请求指示触发的信令不可接受，PCE也可以选择虚拟TE链路。
Also, note that an ingress LSR of a higher-layer or lower-layer LSP may be present in multiple layers. Thus, even when a mono-layer path is requested or supplied, PCEP MUST be able to indicate the required/provided path layer.
另外，注意，更高层或更低层LSP的入口LSR可以存在于多个层中。因此，即使请求或提供单层路径，PCEP也必须能够指示所需/提供的路径层。
A request from a PCC to a PCE MUST support the inclusion of constraints for a multi-layer path. This includes control over which network layers may, must, or must not be included in the computed path. Such control may be expressed in terms of the switching types of the layer networks.
从PCC到PCE的请求必须支持包含多层路径的约束。这包括控制哪些网络层可能、必须或不得包含在计算路径中。这种控制可以用层网络的交换类型来表示。
Furthermore, it may be desirable to constrain the number of layer boundaries crossed (i.e., the number of adaptations in the sense used in [RFC5212] performed on the end-to-end path), so PCEP SHOULD include a constraint or objective function to minimize or cap the number of adaptations on a path and a mechanism to report that number when a path is supplied.
此外，可能需要限制交叉的层边界的数量（即，在端到端路径上执行的[RFC5212]中使用的意义上的适配数量），因此，PCEP应包括一个约束或目标函数，以最小化或限制路径上的自适应数量，以及在提供路径时报告该数量的机制。
The path computation request MUST also allow for different objective functions to be applied within different network layers. For example, the path in a packet-network may need to be optimized for least delay using the IGP metric as a measure of delay, while the path in an underlying TDM network might be optimized for fewest hops.
路径计算请求还必须允许在不同的网络层中应用不同的目标函数。例如，分组网络中的路径可能需要使用IGP度量作为延迟度量来优化以获得最小延迟，而底层TDM网络中的路径可能需要优化以获得最小跳数。
The concept of adaptation is used here as introduced in [RFC5212].
此处使用了[RFC5212]中介绍的自适应概念。
It MUST be possible for the path computation request to indicate the desired adaptation function at the end points of the lower-layer LSP that is being computed. This will be particularly important where the ingress and egress LSR participate in more than one layer network but may not be capable of all associated adaptations.
路径计算请求必须能够在正在计算的较低层LSP的端点处指示所需的自适应功能。当入口和出口LSR参与多个层网络，但可能不能进行所有相关的适配时，这将特别重要。
When each layer is in scope of a different PCE, which only has access to the topology information of its layer, the PCEs of each layer need to cooperate to perform inter-layer path computation. In this case, communication between PCEs is required for inter-layer path computation. A PCE that behaves as a client is defined as a PCC [RFC4655].
当每一层都在不同的PCE范围内，而PCE只能访问其层的拓扑信息时，每一层的PCE需要协同执行层间路径计算。在这种情况下，层间路径计算需要pce之间的通信。作为客户端的PCE被定义为PCC[RFC4655]。
PCEP MUST allow requests and replies for multiple PCE inter-layer path computation.
PCEP必须允许多个PCE层间路径计算的请求和响应。
PCEP MUST allow for the computation of diverse inter-layer paths. A request from a PCC to a PCE MUST support the inclusion of multiple path requests, with the desired level of diversity at each layer (link, node, Shared Risk Link Group (SRLG)).
PCEP必须允许计算不同的层间路径。从PCC到PCE的请求必须支持包含多个路径请求，每个层（链路、节点、共享风险链路组（SRLG））具有所需的多样性级别。
In the case where there are several PCEs with distinct capabilities available, a PCC has to select one or more appropriate PCEs. For that purpose, the PCE discovery mechanism MAY support the disclosure of some detailed PCE capabilities. A PCE MAY (to be consistent with the above text and RFC 4674) be able to advise the following PCE capabilities related to inter-layer path computation:
如果有多个具有不同功能的PCE可用，PCC必须选择一个或多个合适的PCE。为此目的，PCE发现机制可支持披露一些详细的PCE能力。PCE可能（与上述文本和RFC 4674一致）能够建议与层间路径计算相关的以下PCE能力：
- Support for inter-layer path computation
- 支持层间路径计算
- Support for mono-layer/multi-layer paths
- 支持单层/多层路径
- Support for inter-layer constraints
- 支持层间约束
- Support for adaptation capability
- 支持适应能力
- Support for inter-PCE communication
- 支持PCE间通信
- Support for inter-layer diverse path computation
- 支持层间多样化路径计算
PCEP SHOULD allow several architectural alternatives for interworking between MPLS- and GMPLS-controlled networks: overlay, integrated, and augmented models [RFC3945] [RFC5145] [RFC5146].
PCEP应允许MPLS和GMPLS控制网络之间互通的几种架构备选方案：覆盖、集成和增强型[RFC3945][RFC5145][RFC5146]。
An individual PCE MAY elect to support inter-layer computations and advertise its capabilities as described in the previous sections. PCE implementations MAY provide a configuration switch to allow support of inter-layer path computations to be enabled or disabled. When the level of support is changed, this SHOULD be re-advertised.
单个PCE可选择支持层间计算并宣传其能力，如前几节所述。PCE实现可提供配置开关，以允许启用或禁用层间路径计算的支持。当支持级别更改时，应重新公布。
However, a PCE MAY also elect to support inter-layer computations, but not to advertise the fact, so that only those PCCs configured to know of the PCE and its capabilities can use it.
然而，PCE还可以选择支持层间计算，但不公布事实，以便只有那些配置为知道PCE及其能力的pcc可以使用它。
Support for, and advertisement of support for, inter-layer path computation MAY be subject to policy and a PCE MAY hide its inter-layer capabilities from certain PCCs by not advertising them through the discovery protocol and not reporting them to the specific PCCs in any PCEP capabilities exchange. Further, a PCE MAY be directed by policy to refuse an inter-layer path computation request for any reason including, but not limited to, the identity of the PCC that makes the request.
对层间路径计算的支持和对层间路径计算的支持的公布可能受制于策略，并且PCE可以通过不通过发现协议公布其层间能力以及不在任何PCEP能力交换中向特定pcc报告它们来对某些pcc隐藏其层间能力。此外，策略可指示PCE出于任何原因拒绝层间路径计算请求，包括但不限于发出请求的PCC的身份。
A further discussion of policy-enabled path computation can be found in [RFC5394].
关于策略启用的路径计算的进一步讨论，请参见[RFC5394]。
PCEP extensions to support inter-layer computations MUST be accompanied by MIB objects for the control and monitoring of the protocol and of the PCE that performs the computations. The MIB objects MAY be provided in the same MIB module as used for general PCEP control and monitoring [PCEP-MIB] or MAY be provided in a new MIB module.
支持层间计算的PCEP扩展必须附带MIB对象，用于控制和监控协议以及执行计算的PCE。MIB对象可以在用于一般PCEP控制和监控[PCEP-MIB]的相同MIB模块中提供，也可以在新的MIB模块中提供。
The MIB objects MUST provide the ability to control and monitor all aspects of PCEP relevant to inter-layer path computation.
MIB对象必须能够控制和监视与层间路径计算相关的PCEP的所有方面。
No changes are necessary to the liveness detection and monitoring requirements as already embodied in [RFC4657]. It should be noted, however, that inter-layer path computations might require extended cooperation between PCEs (as is also the case for inter-AS (Autonomous System) and inter-area computations), and so the liveness detection and monitoring SHOULD be applied to each PCEP communication and aggregated to report the behavior of an individual PCEP request to the originating PCC.
[RFC4657]中已经包含的活性检测和监控要求无需更改。然而，应注意，层间路径计算可能需要PCE之间的扩展合作（as间（自治系统）和区域间计算也是如此），因此，活跃度检测和监视应应用于每个PCEP通信，并聚合以向发起PCC报告单个PCEP请求的行为。
In particular, where a request is forwarded between multiple PCEs, neither the PCC nor the first PCE can monitor the liveness of all PCE-PCE connections or of the PCEs themselves. In this case, suitable performance of the original PCEP request relies on each PCE operating correct monitoring procedures and correlating any failures back to the PCEP requests that are outstanding. These requirements are no different from those for any cooperative PCE usage, and they are expected already to be covered by general, and by inter-AS and inter-area, implementations. Such a procedure is specified in [RFC5441]. In addition, [RFC5886] specifies mechanisms to gather various state metrics along the path computation chain.
特别地，在多个PCE之间转发请求的情况下，PCC或第一PCE都不能监视所有PCE-PCE连接或PCE本身的活动性。在这种情况下，原始PCEP请求的适当性能取决于每个PCE运行正确的监控程序，并将任何故障关联回未完成的PCEP请求。这些要求与任何合作PCE使用的要求没有什么不同，预计它们已经被通用、AS间和区域间的实现所涵盖。[RFC5441]中规定了此类程序。此外，[RFC5886]指定了沿路径计算链收集各种状态度量的机制。
There are no additional requirements beyond those expressed in [RFC4657] for verifying the correct operation of the PCEP. Note that verification of the correct operation of the PCE and its algorithms is out of scope for the protocol requirements, but a PCC MAY send the same request to more than one PCE and compare the results.
除了[RFC4657]中规定的要求外，没有其他要求用于验证PCEP的正确操作。请注意，验证PCE及其算法的正确操作超出协议要求的范围，但PCC可能会向多个PCE发送相同的请求并比较结果。
A PCE operates on a topology graph that may be built using information distributed by TE extensions to the routing protocol operating within the network. In order that the PCE can select a suitable path for the signaling protocol to use to install the inter-layer LSP, the topology graph must include information about the inter-layer signaling and forwarding (i.e., adaptation) capabilities of each LSR in the network.
PCE在拓扑图上运行，拓扑图可以使用网络内运行的路由协议的TE扩展所分发的信息来构建。为了PCE能够为信令协议选择合适的路径以用于安装层间LSP，拓扑图必须包括关于网络中每个LSR的层间信令和转发（即，自适应）能力的信息。
Whatever means are used to collect the information to build the topology graph, the graph MUST include the requisite information. If the TE extensions to the routing protocol are used, these SHOULD satisfy the requirements as described in [RFC5212].
无论使用何种方法收集信息以构建拓扑图，该图必须包含必要的信息。如果使用路由协议的TE扩展，这些扩展应满足[RFC5212]中所述的要求。
This section examines the impact on network operations of the use of a PCE for inter-layer traffic engineering. It does not present any further requirements on the PCE or PCC, for the PCEP or for deployment.
本节探讨层间流量工程中使用PCE对网络运营的影响。它没有对PCE或PCC、PCEP或部署提出任何进一步要求。
The use of a PCE to compute inter-layer paths is not expected to have significant impact on network operations if the upper-layer traffic engineering practices are aware of the frequent changes that might occur in the VNT. It should also be noted that the introduction of inter-layer support to a PCE that already provides mono-layer path computation might change the loading of the PCE and that might have an impact on the network behavior especially during recovery periods immediately after a network failure.
如果上层流量工程实践意识到VNT中可能发生的频繁变化，则使用PCE计算层间路径预计不会对网络操作产生重大影响。还应注意，对已经提供单层路径计算的PCE引入层间支持可能会改变PCE的负载，并且可能会对网络行为产生影响，尤其是在网络故障后的恢复期间。
On the other hand, it is envisioned that the use of inter-layer path computation will have significant benefits to the operation of a multi-layer network including improving the network resource usage and enabling a greater number of higher-layer LSPs to be supported.
另一方面，可以预见，层间路径计算的使用将对多层网络的操作具有显著的益处，包括改进网络资源使用和使得能够支持更多的高层lsp。
Inter-layer traffic engineering with PCE may raise new security issues when PCE-PCE communication is used 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 formal introduction of a VNT Manager component, as described in [RFC5623], provides the basis for the application of inter-layer security and policy.
如[RFC5623]所述，VNT管理器组件的正式引入为层间安全和策略的应用提供了基础。
It is expected that solutions for inter-layer protocol extensions will address these issues in detail.
预计层间协议扩展解决方案将详细解决这些问题。
We would like to thank Kohei Shiomoto, Ichiro Inoue, Dean Cheng, Meral Shirazipour, Julien Meuric, and Stewart Bryant for their useful comments. Thanks to members of ITU-T Study Group 15, Question 14 for their constructive comments during the liaison process.
我们要感谢Shiomoto Kohei、井上一郎、郑院长、Meral Shirazipour、Julien Meuri和Stewart Bryant提出的有用意见。感谢ITU-T研究组15，问题14的成员在联络过程中提出的建设性意见。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945]Mannie，E.，Ed.“通用多协议标签交换（GMPLS）体系结构”，RFC 39452004年10月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4655]Farrel，A.，Vasseur，J.-P.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 46552006年8月。
[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
[RFC4657]Ash，J.，Ed.，和J.Le Roux，Ed.，“路径计算元件（PCE）通信协议通用要求”，RFC 4657，2006年9月。
[RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
[RFC4674]Le Roux，J.，编辑，“路径计算元素（PCE）发现的要求”，RFC 4674，2006年10月。
[RFC5145] Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS Migration", RFC 5145, March 2008.
[RFC5145]Shiomoto，K.，Ed.“MPLS-TE到GMPLS迁移的框架”，RFC 51452008年3月。
[RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks", RFC 5146, March 2008.
[RFC5146]Kumaki，K.，Ed.“支持MPLS-TE在GMPLS网络上运行的互通要求”，RFC 5146，2008年3月。
[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, July 2008.
[RFC5212]Shiomoto，K.，Papadimitriou，D.，Le Roux，JL.，Vigoureux，M.，和D.Brungard，“基于GMPLS的多区域和多层网络（MRN/MLN）的要求”，RFC 52122008年7月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394]Bryskin，I.，Papadimitriou，D.，Berger，L.，和J.Ash，“策略启用路径计算框架”，RFC 53942008年12月。
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009.
[RFC5623]Oki，E.，Takeda，T.，Le Roux，JL.，和A.Farrel，“基于PCE的层间MPLS和GMPLS流量工程框架”，RFC 56232009年9月。
[PCEP-MIB] A. Koushik, and E. Stephan, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, July 2010.
[PCEP-MIB]A.Koushik和E.Stephan，“PCE通信协议（PCEP）管理信息库”，正在进行的工作，2010年7月。
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009.
[RFC5441]Vasseur，JP.，Ed.，Zhang，R.，Bitar，N.，和JL。Le Roux，“计算最短约束域间流量工程标签交换路径的基于PCE的反向递归计算（BRPC）过程”，RFC 54412009年4月。
[RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, June 2010.
[RFC5886]Vasseur，JP.，Ed.，Le Roux，JL.，和Y.Ikejiri，“基于路径计算元素（PCE）架构的一套监控工具”，RFC 58862010年6月。
Contributing Authors
撰稿人
Eiji Oki University of Electro-Communications Tokyo, Japan EMail: oki@ice.uec.ac.jp
东京电工大学东京电日本电子函件：oki@ice.uec.ac.jp
Jean-Louis Le Roux France Telecom R&D, Av Pierre Marzin, 22300 Lannion, France EMail: jeanlouis.leroux@orange-ftgroup.com
Jean-Louis Le Roux法国电信研发部，Av Pierre Marzin，法国兰尼翁22300电子邮件：jeanlouis。leroux@orange-ftgroup.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN EMail: ke-kumaki@kddi.com
Kenji Kumaki KDDI公司日本东京千代田区Iidabashi花园航空塔102-8460电子邮件：ke-kumaki@kddi.com
Authors' Addresses
作者地址
Tomonori Takeda (editor) NTT 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan EMail: takeda.tomonori@lab.ntt.co.jp
武田友诺里（编辑）NTT 3-9-11武藏县町美多里，东京180-8585，日本电子邮件：武田。tomonori@lab.ntt.co.jp
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel老狗咨询电子邮件：adrian@olddog.co.uk