Internet Engineering Task Force (IETF) X. Zhang, Ed.
Request for Comments: 8051 Huawei Technologies
Category: Informational I. Minei, Ed.
ISSN: 2070-1721 Google, Inc.
January 2017
Internet Engineering Task Force (IETF) X. Zhang, Ed.
Request for Comments: 8051 Huawei Technologies
Category: Informational I. Minei, Ed.
ISSN: 2070-1721 Google, Inc.
January 2017
Applicability of a Stateful Path Computation Element (PCE)
有状态路径计算元素（PCE）的适用性
Abstract
摘要
A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents.
有状态路径计算元素（PCE）维护关于网络内标签交换路径（LSP）特性和资源使用的信息，以便为其相关路径计算客户端（PCC）提供流量工程计算。本文档描述了有状态PCE部署的一般注意事项，并通过一些用例检查了其适用性和好处，以及其挑战和限制。有状态PCE使用所需的PCE通信协议（PCEP）扩展包含在单独的文档中。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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 http://www.rfc-editor.org/info/rfc8051.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8051.
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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 5
3.1. Optimization of LSP Placement . . . . . . . . . . . . . . 5
3.1.1. Throughput Maximization and Bin Packing . . . . . . . 6
3.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 9
3.1.4. Predictability . . . . . . . . . . . . . . . . . . . 10
3.2. Auto-Bandwidth Adjustment . . . . . . . . . . . . . . . . 11
3.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 12
3.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 15
3.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 15
3.6. LSP Reoptimization . . . . . . . . . . . . . . . . . . . 16
3.7. Resource Defragmentation . . . . . . . . . . . . . . . . 17
3.8. Point-to-Multipoint Applications . . . . . . . . . . . . 17
3.9. Impairment-Aware Routing and Wavelength Assignment
(IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 19
4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 19
4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 19
4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 5
3.1. Optimization of LSP Placement . . . . . . . . . . . . . . 5
3.1.1. Throughput Maximization and Bin Packing . . . . . . . 6
3.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 9
3.1.4. Predictability . . . . . . . . . . . . . . . . . . . 10
3.2. Auto-Bandwidth Adjustment . . . . . . . . . . . . . . . . 11
3.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 12
3.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 15
3.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 15
3.6. LSP Reoptimization . . . . . . . . . . . . . . . . . . . 16
3.7. Resource Defragmentation . . . . . . . . . . . . . . . . 17
3.8. Point-to-Multipoint Applications . . . . . . . . . . . . 17
3.9. Impairment-Aware Routing and Wavelength Assignment
(IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 19
4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 19
4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 19
4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
[RFC4655] defines the architecture for a model based on the Path Computation Element (PCE) for the computation of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs). To perform such a constrained computation, a PCE stores the network topology (i.e., TE links and nodes) and resource information (i.e., TE attributes) in its TE Database (TED). [RFC5440] describes the Path Computation Element Protocol (PCEP) for interaction between a Path Computation Client (PCC) and a PCE, or between two PCEs, enabling computation of TE LSPs.
[RFC4655]定义了基于路径计算元素（PCE）的模型架构，用于计算多协议标签交换（MPLS）和通用MPLS（GMPLS）流量工程标签交换路径（TE LSP）。为了执行这种受限计算，PCE将网络拓扑（即TE链路和节点）和资源信息（即TE属性）存储在其TE数据库（TE）中。[RFC5440]描述了用于路径计算客户端（PCC）和PCE之间或两个PCE之间交互的路径计算元素协议（PCEP），以实现TE LSP的计算。
As per [RFC4655], a PCE can be either stateful or stateless. A stateful PCE maintains two sets of information for use in path computation. The first is the Traffic Engineering Database (TED), which includes the topology and resource state in the network. This information can be obtained by a stateful PCE using the same mechanisms as a stateless PCE (see [RFC4655]). The second is the LSP State Database (LSP-DB), in which a PCE stores attributes of all active LSPs in the network, such as their paths through the network, bandwidth/resource usage, switching types, and LSP constraints. This state information allows the PCE to compute constrained paths while considering individual LSPs and their inter-dependency. However, this requires reliable state synchronization mechanisms between the PCE and the network, between the PCE and the PCCs, and between cooperating PCEs, with potentially significant control-plane overhead and maintenance of a large amount of state data, as explained in [RFC4655].
根据[RFC4655]，PCE可以是有状态的，也可以是无状态的。有状态PCE维护两组用于路径计算的信息。第一个是流量工程数据库（TED），它包括网络中的拓扑和资源状态。有状态PCE可以使用与无状态PCE相同的机制获得此信息（请参见[RFC4655]）。第二个是LSP状态数据库（LSP-DB），其中PCE存储网络中所有活动LSP的属性，例如它们通过网络的路径、带宽/资源使用、交换类型和LSP约束。该状态信息允许PCE在考虑单个LSP及其相互依赖性的同时计算受约束的路径。然而，这需要PCE和网络之间、PCE和PCC之间以及协作PCE之间的可靠状态同步机制，如[RFC4655]中所述，具有潜在的重大控制平面开销和大量状态数据的维护。
This document describes how a stateful PCE can be used to solve various problems for MPLS-TE and GMPLS networks and the benefits it brings to such deployments. Note that alternative solutions relying on stateless PCEs may also be possible for some of these use cases and will be mentioned for completeness where appropriate.
本文档描述了有状态PCE如何用于解决MPLS-TE和GMPLS网络的各种问题，以及它为此类部署带来的好处。请注意，依赖于无状态PCE的替代解决方案也可能适用于其中一些用例，并将在适当时提及完整性。
This document uses the following terms defined in [RFC5440]: PCC, PCE, and PCEP peer.
本文件使用[RFC5440]中定义的以下术语：PCC、PCE和PCEP对等。
This document defines the following terms:
本文件定义了以下术语：
Stateful PCE: a PCE that has access to not only the network state, but also to the set of active paths and their reserved resources for its computations. A stateful PCE might also retain information regarding LSPs under construction in order to reduce churn and resource contention. The additional state allows the PCE to compute constrained paths while considering individual LSPs and their interactions. Note that this requires reliable state synchronization mechanisms between the PCE and the network, PCE and PCC, and between cooperating PCEs.
有状态PCE：一种PCE，它不仅可以访问网络状态，还可以访问一组活动路径及其用于计算的保留资源。有状态PCE还可以保留有关正在构建的LSP的信息，以减少流失和资源争用。附加状态允许PCE在考虑单个LSP及其交互时计算约束路径。注意，这需要PCE和网络、PCE和PCC之间以及协作PCE之间的可靠状态同步机制。
Passive Stateful PCE: a PCE that uses LSP state information learned from PCCs to optimize path computations. It does not actively update LSP state. A PCC maintains synchronization with the PCE.
被动有状态PCE：一种PCE，使用从PCC获取的LSP状态信息来优化路径计算。它不会主动更新LSP状态。PCC与PCE保持同步。
Active Stateful PCE: a PCE that may issue recommendations to the network. For example, an Active Stateful PCE may use the Delegation mechanism to update LSP parameters in those PCCs that delegate control over their LSPs to the PCE.
主动有状态PCE：可向网络发出建议的PCE。例如，活动有状态PCE可以使用委托机制来更新那些将对其LSP的控制委托给PCE的pcc中的LSP参数。
Delegation: an operation to grant a PCE temporary rights to modify a subset of LSP parameters on one or more LSPs of a PCC. LSPs are delegated from a PCC to a PCE and are referred to as "delegated" LSPs. The PCC that owns the PCE state for the LSP has the right to delegate it. An LSP is owned by a single PCC at any given point in time. For intra-domain LSPs, this PCC should be the LSP head end.
委派：授予PCE临时权限以修改PCC的一个或多个LSP上的LSP参数子集的操作。LSP由PCC委托给PCE，称为“委托”LSP。拥有LSP PCE状态的PCC有权将其委派。LSP在任何给定时间点由单个PCC拥有。对于域内LSP，此PCC应为LSP前端。
LSP State Database: information about all LSPs and their attributes.
LSP状态数据库：有关所有LSP及其属性的信息。
PCE Initiation: assuming LSP delegation granted by default, a PCE can issue recommendations to the network.
PCE启动：假设默认情况下授予LSP委派，PCE可以向网络发出建议。
Minimum Cut Set: the minimum set of links for a specific source destination pair that, when removed from the network, results in a specific source being completely isolated from a specific destination. The summed capacity of these links is equivalent to the maximum capacity from the source to the destination by the max-flow min-cut theorem.
最小割集：特定源-目的地对的最小链路集，当从网络中删除时，会导致特定源与特定目的地完全隔离。根据最大流最小割定理，这些链路的总容量等于从源到目的地的最大容量。
In the following sections, several use cases are described, showcasing scenarios that benefit from the deployment of a stateful PCE.
在以下部分中，将描述几个用例，展示从部署有状态PCE中获益的场景。
The following use cases demonstrate a need for visibility into global LSP states in PCE path computations, and for a PCE control of sequence and timing in altering LSP path characteristics within and across PCEP sessions. Reference topologies for the use cases described later in this section are shown in Figures 1 and 2.
以下用例说明了在PCE路径计算中对全局LSP状态的可见性的需要，以及PCE在改变PCEP会话内和跨PCEP会话的LSP路径特征时对序列和定时的控制的需要。本节后面描述的用例的参考拓扑如图1和图2所示。
Some of the use cases below are focused on MPLS-TE deployments but may also apply to GMPLS. Unless otherwise cited, use cases assume that all LSPs listed exist at the same LSP priority.
下面的一些用例侧重于MPLS-TE部署，但也可能适用于GMPLS。除非另有引用，否则用例假定列出的所有LSP都具有相同的LSP优先级。
The main benefit in the cases below comes from moving away from an asynchronous PCC-driven mode of operation to a model that allows for central control over LSP computations and maintenance, and focuses specifically on the active stateful PCE model of operation.
以下情况的主要好处是从异步PCC驱动的运行模式转变为允许集中控制LSP计算和维护的模式，并特别关注活动状态PCE运行模式。
+-----+
| A |
+-----+
\
+-----+ +-----+
| C |----------------------| E |
+-----+ +-----+
/ \ +-----+ /
+-----+ +-----| D |-----+
| B | +-----+
+-----+
+-----+
| A |
+-----+
\
+-----+ +-----+
| C |----------------------| E |
+-----+ +-----+
/ \ +-----+ /
+-----+ +-----| D |-----+
| B | +-----+
+-----+
Figure 1: Reference Topology 1
图1：参考拓扑1
+-----+ +-----+ +-----+
| A | | B | | C |
+--+--+ +--+--+ +--+--+
| | |
| | |
+--+--+ +--+--+ +--+--+
| E +--------+ F +--------+ G |
+-----+ +-----+ +-----+
+-----+ +-----+ +-----+
| A | | B | | C |
+--+--+ +--+--+ +--+--+
| | |
| | |
+--+--+ +--+--+ +--+--+
| E +--------+ F +--------+ G |
+-----+ +-----+ +-----+
Figure 2: Reference Topology 2
图2：参考拓扑2
Because LSP attribute changes in [RFC5440] are driven by Path Computation Request (PCReq) messages under control of a PCC's local timers, the sequence of resource reservation arrivals occurring in the network will be randomized. This, coupled with a lack of global LSP state visibility on the part of a stateless PCE, may result in suboptimal throughput in a given network topology, as will be shown in the example below.
由于[RFC5440]中的LSP属性更改是由PCC本地定时器控制下的路径计算请求（PCReq）消息驱动的，因此网络中发生的资源预留到达序列将随机化。这加上无状态PCE部分缺乏全局LSP状态可见性，可能导致给定网络拓扑中的次优吞吐量，如下例所示。
Reference Topology 2 in Figure 2 and Tables 1 and 2 show an example in which throughput is at 50% of optimal as a result of the lack of visibility and synchronized control across PCCs. In this scenario, the decision must be made as to whether to route any portion of the E-G demand, as any demand routed for this source and destination will decrease system throughput.
图2中的参考拓扑2以及表1和表2显示了一个示例，其中，由于PCC之间缺乏可见性和同步控制，吞吐量达到了最佳吞吐量的50%。在这种情况下，必须决定是否路由E-G需求的任何部分，因为路由到此源和目的地的任何需求都将降低系统吞吐量。
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-E | 1 | 10 |
| B-F | 1 | 10 |
| C-G | 1 | 10 |
| E-F | 1 | 10 |
| F-G | 1 | 10 |
+------+--------+----------+
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-E | 1 | 10 |
| B-F | 1 | 10 |
| C-G | 1 | 10 |
| E-F | 1 | 10 |
| F-G | 1 | 10 |
+------+--------+----------+
Table 1: Link Parameters for Throughput Use Case
表1：吞吐量用例的链路参数
+------+-----+-----+-----+--------+----------+-------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+-------+
| 1 | 1 | E | G | 10 | Yes | E-F-G |
| 2 | 2 | A | B | 10 | No | --- |
| 3 | 1 | F | C | 10 | No | --- |
+------+-----+-----+-----+--------+----------+-------+
+------+-----+-----+-----+--------+----------+-------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+-------+
| 1 | 1 | E | G | 10 | Yes | E-F-G |
| 2 | 2 | A | B | 10 | No | --- |
| 3 | 1 | F | C | 10 | No | --- |
+------+-----+-----+-----+--------+----------+-------+
Table 2: Throughput Use Case Demand Time Series
表2：吞吐量用例需求时间序列
In many cases, throughput maximization becomes a bin-packing problem. While bin packing itself is an NP-hard problem, a number of common heuristics that run in polynomial time can provide significant improvements in throughput over random reservation event distribution, especially when traversing links that are members of the minimum cut set for a large subset of source destination pairs.
在许多情况下，吞吐量最大化成为一个装箱问题。虽然装箱本身是一个NP难问题，但在多项式时间内运行的许多常见启发式算法可以显著提高随机预约事件分布的吞吐量，特别是在遍历作为源-目的地对的一大子集的最小割集成员的链路时。
Tables 3 and 4 show a simple use case using Reference Topology 1 in Figure 1, where LSP state visibility and control of reservation order across PCCs would result in significant improvement in total throughput.
表3和表4显示了一个使用图1中的参考拓扑1的简单用例，其中LSP状态可见性和跨PCC的保留顺序控制将显著提高总吞吐量。
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 3: Link Parameters for Bin-Packing Use Case
表3：箱子包装用例的链接参数
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 5 | Yes | A-C-D-E |
| 2 | 2 | B | E | 10 | No | --- |
+------+-----+-----+-----+--------+----------+---------+
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 5 | Yes | A-C-D-E |
| 2 | 2 | B | E | 10 | No | --- |
+------+-----+-----+-----+--------+----------+---------+
Table 4: Bin-Packing Use Case Demand Time Series
表4：箱子包装用例需求时间序列
This section discusses the use case of cross-LSP impact under degraded operation. Most existing RSVP-TE implementations will not tear down established LSPs in the event of the failure of the bandwidth increase procedure detailed in [RFC3209]. This behavior is directly implied to be correct in [RFC3209] and is often desirable from an operator's perspective, because either a) the destination prefixes are not reachable via any means other than MPLS or b) this would result in significant packet loss as demand is shifted to other LSPs in the overlay mesh.
本节讨论降级运行下交叉LSP影响的用例。在[RFC3209]中详述的带宽增加程序失败的情况下，大多数现有RSVP-TE实施不会拆除已建立的LSP。该行为在[RFC3209]中被直接暗示为正确的，并且从运营商的角度来看通常是可取的，因为a）除了MPLS之外，目的地前缀无法通过任何方式到达，或者b）这将在需求转移到覆盖网中的其他LSP时导致显著的数据包丢失。
In addition, there are currently few implementations offering dynamic ingress admission control (policing of the traffic volume mapped onto an LSP) at the Label Edge Router (LER). Having ingress admission control on a per-LSP basis is not necessarily desirable from an operational perspective, as a) one must over-provision tunnels significantly in order to avoid deleterious effects resulting from stacked transport and flow control systems (for example, for tunnels that are dynamically resized based on current traffic) and b) there is currently no efficient commonly available northbound interface for dynamic configuration of per-LSP ingress admission control.
此外，目前很少有实现在标签边缘路由器（LER）上提供动态入口准入控制（对映射到LSP的流量进行监控）。从运营角度来看，在每个LSP的基础上进行入口准入控制并不一定是可取的，因为a）为了避免堆叠运输和流量控制系统（例如，对于根据当前交通量动态调整大小的隧道）造成的有害影响，必须对隧道进行大量的过度供应和b）目前没有用于动态配置每LSP入口准入控制的有效的通用北行接口。
Lack of ingress admission control coupled with the behavior in [RFC3209] may result in LSPs operating out of profile for significant periods of time. It is reasonable to expect that these out-of-profile LSPs will be operating in a degraded state and experience traffic loss. Moreover, because those LSPs end up sharing common network interfaces with other LPSs operating within their bandwidth reservations, they will impact the operation of the in-profile LSPs, even when there is unused network capacity elsewhere in the network. Furthermore, this behavior will cause information loss in the TED with regards to the actual available bandwidth on the links used by the out-of-profile LSPs, as the reservations on the links no longer reflect the capacity used.
缺乏进入许可控制加上[RFC3209]中的行为可能会导致LSP在相当长的一段时间内运行不正常。可以合理预期，这些非配置LSP将在降级状态下运行，并经历流量损失。此外，由于这些lsp最终与在其带宽保留内操作的其他lps共享公共网络接口，因此它们将影响配置文件内lsp的操作，即使在网络中其他地方存在未使用的网络容量时也是如此。此外，由于链路上的保留不再反映所使用的容量，此行为将导致TED中与非配置文件LSP使用的链路上的实际可用带宽相关的信息丢失。
Reference Topology 1 in Figure 1 and Tables 5 and 6 show a use case that demonstrates this behavior. Two LSPs, LSP 1 and LSP 2, are signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E, respectively. At a later time, the demand of LSP 1 increases to 20. Under such a demand, the LSP cannot be resignaled. However, the existing LSP will not be torn down. In the absence of ingress policing, traffic on LSP 1 will cause degradation for traffic of LSP 2 (due to oversubscription on the links C-D and D-E), as well as information loss in the TED with regard to the actual network state.
图1中的参考拓扑1以及表5和表6显示了演示此行为的用例。两个LSP，LSP 1和LSP 2，用需求2发送信号，并分别沿路径A-C-D-E和B-C-D-E路由。后来，LSP 1的需求增加到20。在这种要求下，LSP不能辞职。然而，现有的LSP不会被拆除。在没有入口监控的情况下，LSP 1上的流量将导致LSP 2的流量降级（由于链路C-D和D-E上的超额订阅），以及TED中与实际网络状态相关的信息丢失。
The problem could be easily ameliorated by global visibility of the LSP state coupled with PCC-external demand measurements and placement of two LSPs on disjoint links. Note that while the demand of 20 for LSP 1 could never be satisfied in the given topology, isolation from the ill-effects of the (unsatisfiable) increased demand could be achieved.
该问题可以通过LSP状态的全局可见性、PCC外部需求测量以及在不相交链路上放置两个LSP来轻松改善。请注意，虽然在给定拓扑中永远无法满足LSP 1的20需求，但可以实现与（无法满足的）需求增加的不良影响的隔离。
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 5: Link Parameters for the 'Degraded Operation' Example
表5：“降级运行”示例的链路参数
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 2 | Yes | A-C-D-E |
| 2 | 2 | B | E | 2 | Yes | B-C-D-E |
| 3 | 1 | A | E | 20 | No | --- |
+------+-----+-----+-----+--------+----------+---------+
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 2 | Yes | A-C-D-E |
| 2 | 2 | B | E | 2 | Yes | B-C-D-E |
| 3 | 1 | A | E | 20 | No | --- |
+------+-----+-----+-----+--------+----------+---------+
Table 6: 'Degraded Operation' Demand Time Series
表6：“降级运行”需求时间序列
As a result of both the lack of visibility into the global LSP state and the lack of control over event ordering across PCE sessions, unnecessary perturbations may be introduced into the network by a stateless PCE. Tables 7 and 8 show an example of an unnecessary network perturbation using Reference Topology 1 in Figure 1. In this case, an unimportant (high LSP priority value) LSP (LSP1) is first set up along the shortest path. At time 2, which is assumed to be relatively close to time 1, a second more important (lower LSP-priority value) LSP (LSP2) is established, preempting LSP1 potentially causing traffic loss. LSP1 is then reestablished on the longer A-C-E path.
由于缺乏对全局LSP状态的可视性和对跨PCE会话的事件顺序的控制，无状态PCE可能会将不必要的扰动引入网络。表7和表8显示了使用图1中的参考拓扑1的不必要网络扰动示例。在这种情况下，首先沿最短路径设置不重要的（高LSP优先级值）LSP（LSP1）。在时间2（假定相对接近时间1），建立第二个更重要的（较低的LSP优先级值）LSP（LSP2），抢占LSP1可能导致通信量丢失。然后在较长的A-C-E路径上重新建立LSP1。
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 7: Link Parameters for the 'Minimum-Perturbation' Example
表7：“最小扰动”示例的链路参数
+------+-----+-----+-----+--------+----------+----------+---------+
| Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path |
+------+-----+-----+-----+--------+----------+----------+---------+
| 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E |
| 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E |
| 3 | 1 | A | E | 7 | 7 | Yes | A-C-E |
+------+-----+-----+-----+--------+----------+----------+---------+
+------+-----+-----+-----+--------+----------+----------+---------+
| Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path |
+------+-----+-----+-----+--------+----------+----------+---------+
| 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E |
| 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E |
| 3 | 1 | A | E | 7 | 7 | Yes | A-C-E |
+------+-----+-----+-----+--------+----------+----------+---------+
Table 8: 'Minimum-Perturbation' LSP and Demand Time Series
表8：“最小扰动”LSP和需求时间序列
A stateful PCE can help in this scenario by computing both routes at the same time. The advantages of using a stateful PCE over exploiting a stateless PCE via Global Concurrent Optimization (GCO) are threefold. First is the ability to accommodate concurrent path computation from different PCCs. Second is the reduction of control-plane overhead since the stateful PCE has the route information of the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to further optimize the placement of LSPs. This will ensure placement of the more important LSP along the shortest path, avoiding the setup and subsequent preemption of the lower priority LSP. Similarly, when a new higher priority LSP that requires preemption of an existing lower priority LSP(s), a stateful PCE can determine the minimum number of lower priority LSPs to reroute using the Make-Before-Break (MBB) mechanism without disrupting any service and then set up the higher priority LSP.
在这种情况下，有状态PCE可以通过同时计算两条路由来提供帮助。与通过全局并发优化（GCO）利用无状态PCE相比，使用有状态PCE有三个优点。首先是能够容纳来自不同PCC的并发路径计算。第二，由于有状态PCE具有受影响LSP的路由信息，因此控制平面开销减少。第三，有状态PCE可以使用LSP-DB进一步优化LSP的放置。这将确保沿最短路径放置更重要的LSP，避免低优先级LSP的设置和后续抢占。类似地，当新的高优先级LSP需要抢占现有的低优先级LSP时，有状态PCE可以使用先通后断（MBB）机制确定要重新路由的低优先级LSP的最小数量，而不中断任何服务，然后设置高优先级LSP。
Randomization of reservation events caused by lack of control over event ordering across PCE sessions results in poor predictability in LSP routing. An offline system applying a consistent optimization method will produce predictable results to within either the boundary of forecast error (when reservations are over-provisioned by reasonable margins) or to the variability of the signal and the forecast error (when applying some hysteresis in order to minimize churn). Predictable results are valuable for being able to simulate the network and reliably test it under various scenarios, especially under various failure modes and planned maintenances when predictable path characteristics are desired under contention for network resources.
由于缺乏对PCE会话中事件顺序的控制，导致保留事件随机化，导致LSP路由的可预测性较差。采用一致优化方法的离线系统将在预测误差范围内产生可预测的结果（当预留量超出合理裕度时），或在信号和预测误差的可变性范围内产生可预测的结果（当应用一些滞后以最小化搅动时）。可预测的结果对于能够模拟网络并在各种场景下对其进行可靠测试非常有价值，尤其是在各种故障模式和计划维护下，当在网络资源争用情况下需要可预测的路径特征时。
Reference Topology 1 and Tables 9, 10, and 11 show the impact of event ordering and predictability of LSP routing.
参考拓扑1和表9、10和11显示了事件顺序和LSP路由可预测性的影响。
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 1 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 1 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 9: Link Parameters for the 'Predictability' Example
表9：“可预测性”示例的链接参数
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 7 | Yes | A-C-E |
| 2 | 2 | B | E | 7 | Yes | B-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 7 | Yes | A-C-E |
| 2 | 2 | B | E | 7 | Yes | B-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
Table 10: 'Predictability' LSP and Demand Time Series 1
表10：“可预测性”LSP和需求时间序列1
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 2 | B | E | 7 | Yes | B-C-E |
| 2 | 1 | A | E | 7 | Yes | A-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 2 | B | E | 7 | Yes | B-C-E |
| 2 | 1 | A | E | 7 | Yes | A-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
Table 11: 'Predictability' LSP and Demand Time Series 2
表11：“可预测性”LSP和需求时间序列2
As can be shown in the example, both LSPs are routed in both cases, but along very different paths. This would be a challenge if reliable simulation of the network is attempted. An active stateful PCE can solve this through control over LSP ordering. Based on triggers such as a failure or an optimization trigger, the PCE can order the computations and path setup in a deterministic way.
如示例中所示，两个LSP在这两种情况下都被路由，但路径非常不同。如果尝试对网络进行可靠的模拟，这将是一个挑战。主动有状态PCE可以通过控制LSP排序来解决这一问题。基于诸如故障或优化触发器之类的触发器，PCE可以以确定性方式对计算和路径设置进行排序。
The bandwidth requirements of LSPs often change over time, requiring LSP resizing. In most implementations available today, the head-end node performs this function by monitoring the actual bandwidth usage, triggering a recomputation and resignaling when a threshold is reached. This operation is referred to as "auto-bandwidth adjustment". The head-end node either recomputes the path locally, or it requests a recomputation from a PCE by sending a PCReq message. In the latter case, the PCE computes a new path and provides the new route suggestion. Upon receiving the reply from the PCE, the PCC resignals the LSP in Shared-Explicit (SE) mode along the newly computed path. With a stateless PCE, the head-end node needs to provide the currently used bandwidth and the route information via path computation request messages. Note that in this scenario, the head-end node is the one that drives the LSP resizing based on local information, and that the difference between using a stateless and a passive stateful PCE is in the level of optimization of the LSP placement as discussed in the previous section.
LSP的带宽需求经常随时间变化，需要调整LSP的大小。在目前可用的大多数实现中，前端节点通过监视实际带宽使用情况、触发重新计算并在达到阈值时重新签名来执行此功能。此操作称为“自动带宽调整”。前端节点要么在本地重新计算路径，要么通过发送PCReq消息从PCE请求重新计算。在后一种情况下，PCE计算新路径并提供新路由建议。在接收到来自PCE的应答后，PCC沿着新计算的路径以共享显式（SE）模式重新签名LSP。对于无状态PCE，前端节点需要通过路径计算请求消息提供当前使用的带宽和路由信息。请注意，在此场景中，前端节点是根据本地信息驱动LSP大小调整的节点，使用无状态和被动有状态PCE之间的区别在于LSP布局的优化级别，如前一节所述。
A more interesting smart bandwidth adjustment case is one where the LSP resizing decision is done by an external entity with access to additional information such as historical trending data, application-
一个更有趣的智能带宽调整案例是，LSP大小调整决策由外部实体完成，该实体可以访问其他信息，如历史趋势数据、应用程序-
specific information about expected demands or policy information, as well as knowledge of the actual desired flow volumes. In this case, an active stateful PCE provides an advantage in both the computation with knowledge of all LSPs in the domain and in the ability to trigger bandwidth modification of the LSP.
关于预期需求或政策信息的具体信息，以及实际期望流量的知识。在这种情况下，有源有状态PCE在利用域中所有LSP的知识进行计算以及在触发LSP的带宽修改的能力方面提供优势。
Bandwidth scheduling allows network operators to reserve resources in advance according to the agreements with their customers and allows them to transmit data with a specified starting time and duration, for example, for a scheduled bulk data replication between data centers.
带宽调度允许网络运营商根据与客户的协议提前预留资源，并允许他们以指定的开始时间和持续时间传输数据，例如，用于数据中心之间的计划批量数据复制。
Traditionally, this can be supported by Network Management System (NMS) operation through path pre-establishment and activation on the agreed starting time. However, this does not provide efficient network usage since the established paths exclude the possibility of being used by other services even when they are not used for undertaking any service. It can also be accomplished through GMPLS protocol extensions by carrying the related request information (e.g., starting time and duration) across the network. Nevertheless, this method inevitably increases the complexity of the signaling and routing process.
传统上，这可以通过网络管理系统（NMS）在约定的开始时间通过路径预建立和激活来支持。然而，这不能提供有效的网络使用，因为所建立的路径排除了被其他服务使用的可能性，即使它们不用于承担任何服务。它也可以通过GMPLS协议扩展来实现，通过在网络上传输相关的请求信息（例如，开始时间和持续时间）。然而，这种方法不可避免地增加了信令和路由过程的复杂性。
A passive stateful PCE can support this application with better efficiency since it can alleviate the burden of processing on network elements. This requires the PCE to maintain the scheduled LSPs and their associated resource usage, as well as the ability of head-ends to trigger signaling for LSP setup/deletion at the correct time. This approach requires coarse time synchronization between PCEs and PCCs. With PCE initiation capability, a PCE can trigger the setup and deletion of scheduled requests in a centralized manner, without modification of existing head-end behaviors, by notifying the PCCs to set up or tear down the paths.
被动有状态PCE可以更高效地支持此应用程序，因为它可以减轻网元上的处理负担。这要求PCE维持调度的LSP及其相关资源使用，以及前端在正确时间触发LSP设置/删除信令的能力。这种方法需要PCE和PCC之间的粗时间同步。通过PCE启动功能，PCE可以通过通知PCC设置或拆除路径，以集中的方式触发计划请求的设置和删除，而无需修改现有的前端行为。
The recovery use cases discussed in the following sections show how leveraging a stateful PCE can simplify the computation of recovery path(s). In particular, two characteristics of a stateful PCE are used: 1) using information stored in the LSP-DB for determining shared protection resources and 2) performing computations with knowledge of all LSPs in a domain.
以下各节中讨论的恢复用例显示了利用有状态PCE如何简化恢复路径的计算。具体地，使用有状态PCE的两个特征：1）使用存储在LSP-DB中的信息来确定共享保护资源，以及2）利用域中所有LSP的知识执行计算。
If a PCC can specify in a request whether the computation is for a working path or for protection and a PCC can report the resource as a working or protection path, then the following text applies. A PCC can send multiple requests to the PCE, asking for two LSPs, and use them as working and backup paths separately. Either way, the resources bound to backup paths can be shared by different LSPs to improve the overall network efficiency, such as m:n protection or pre-configured shared mesh recovery techniques as specified in [RFC4427]. If resource sharing is supported for LSP protection, the information relating to existing LSPs is required to avoid allocation of shared protection resources to two LSPs that might fail together and cause protection contention issues. A stateless PCE can accommodate this use case by having the PCC pass this information as a constraint in the path computation request. A passive stateful PCE can more easily accommodate this need using the information stored in its LSP-DB. Furthermore, an active stateful PCE can help with (re)optimization of protection resource sharing as well as LSP maintenance operation with less impact on protection resources.
如果PCC可以在请求中指定计算是用于工作路径还是用于保护，并且PCC可以将资源报告为工作路径或保护路径，则以下文本适用。PCC可以向PCE发送多个请求，请求两个LSP，并将它们分别用作工作和备份路径。无论哪种方式，绑定到备份路径的资源都可以由不同的LSP共享，以提高整体网络效率，如[RFC4427]中规定的m:n保护或预配置的共享网格恢复技术。如果LSP保护支持资源共享，则需要与现有LSP相关的信息，以避免将共享保护资源分配给两个LSP，这两个LSP可能同时发生故障并导致保护争用问题。无状态PCE可以通过让PCC在路径计算请求中将此信息作为约束传递来适应此用例。被动有状态PCE可以使用其LSP-DB中存储的信息更容易地满足这一需求。此外，主动有状态PCE有助于（重新）优化保护资源共享以及LSP维护操作，对保护资源的影响较小。
+----+
|PCE |
+----+
+----+
|PCE |
+----+
+------+ +------+ +------+
| A +----------+ B +----------+ C |
+--+---+ +---+--+ +---+--+
| | |
| +---------+ |
| | |
| +--+---+ +------+ |
+-----+ E +----------+ D +-----+
+------+ +------+
+------+ +------+ +------+
| A +----------+ B +----------+ C |
+--+---+ +---+--+ +---+--+
| | |
| +---------+ |
| | |
| +--+---+ +------+ |
+-----+ E +----------+ D +-----+
+------+ +------+
Figure 3: Reference Topology 3
图3：参考拓扑3
For example, in the network depicted in Figure 3, suppose there exists LSP1 with working path LSP1_working following A->E and with backup path LSP1_backup following A->B->E. A request arrives asking for a working and backup path pair to be computed for LSP2 from B to E. If the PCE decides LSP2_working follows B->A->E, then the backup path LSP2_backup should not share the same protection resource with LSP1 since LSP2 shares part of its resource (specifically A->E) with LSP1 (i.e., these two LSPs are in the same shared risk group). There is no such constraint if B->C->D->E is chosen for LSP2_working.
例如，在图3所示的网络中，假设存在LSP1，工作路径LSP1_工作在A->E之后，备份路径LSP1_备份在A->B->E之后。一个请求到达，要求为从B到E的LSP2计算工作和备份路径对。如果PCE决定LSP2_工作在B->A->E之后，然后，备份路径LSP2\u备份不应与LSP1共享相同的保护资源，因为LSP2与LSP1共享其部分资源（特别是A->E）（即，这两个LSP属于相同的共享风险组）。如果选择B->C->D->E进行LSP2\U工作，则不存在此类约束。
If a stateless PCE is used, the head node B needs to be aware of the existence of LSPs that share the route of LSP2_working and of the details of their protection resources. B must pass this information to the PCE as a constraint so as to request a path with diversity. Alternatively, a stateless PCE may be able to compute paths diversified by SRLG (Shared Risk Link Group) if TED is extended so that it includes the SRLG information that is protected by a given backup resource, but at the expense of a high complexity in routing. On the other hand, a stateful PCE can get the LSPs information by itself given the LSP identifier(s) and can then find SRLG-diversified protection paths for both LSPs. This is made possible by comparing the LSP resource usage exploiting the LSP-DB accessible by the stateful PCE.
如果使用无状态PCE，则头部节点B需要知道共享LSP2_工作路由的lsp的存在及其保护资源的细节。B必须将此信息作为约束传递给PCE，以便请求具有多样性的路径。或者，如果扩展TED使其包括由给定备份资源保护的SRLG信息，则无状态PCE可能能够计算由SRLG（共享风险链路组）多样化的路径，但代价是路由的高度复杂性。另一方面，有状态PCE可以在给定LSP标识符的情况下自行获取LSP信息，然后可以为两个LSP找到SRLG多样化的保护路径。这可以通过利用有状态PCE可访问的LSP-DB来比较LSP资源使用情况来实现。
In case of a link failure, such as a fiber cut, multiple LSPs may fail at the same time. Thus, the source nodes of the affected LSPs will be informed of the failure by the nodes detecting the failure. These source nodes will send requests to a PCE for rerouting. In order to reuse the resource taken by an existing LSP, the source node can send a PCReq message that includes the Exclude Route Object (XRO) with Fail (F) bit set together with the Record Route Object (RRO) that contains the current route information, as specified in [RFC5521].
在发生链路故障（如光纤切断）的情况下，多个LSP可能同时发生故障。因此，受影响lsp的源节点将被检测到故障的节点通知故障。这些源节点将向PCE发送请求以重新路由。为了重用现有LSP占用的资源，源节点可以发送PCReq消息，该消息包括设置了Fail（F）位的排除路由对象（XRO）以及包含当前路由信息的记录路由对象（RRO），如[RFC5521]中所述。
If a stateless PCE is used, it might respond to the rerouting requests separately if the requests arrive at different times. Thus, it might result in suboptimal resource usage. Even worse, it might unnecessarily block some of the rerouting requests due to insufficient resources for rerouting messages that arrive later. If a passive stateful PCE is used to fulfill this task, the procedure can be simplified. The PCCs reporting the failures can include LSP identifiers instead of detailed information, and the PCE can find relevant LSP information by inspecting the LSP-DB. Moreover, the PCE can recompute the affected LSPs concurrently while reusing part of the existing LSP's resources when it is informed of the failed link identifier provided by the first request. This is made possible because the passive stateful PCE can check what other LSPs are affected by the failed link and their route information by inspecting its LSP-DB. As a result, a better performance can be achieved, such as better resource usage or minimal probability of blocking upcoming new rerouting requests sent as a result of the link failure.
如果使用无状态PCE，如果请求在不同的时间到达，它可能会分别响应重新路由请求。因此，它可能会导致资源使用不理想。更糟糕的是，由于没有足够的资源用于重新路由稍后到达的消息，它可能会不必要地阻止一些重新路由请求。如果使用被动有状态PCE来完成此任务，则过程可以简化。报告故障的PCC可以包括LSP标识符而不是详细信息，PCE可以通过检查LSP-DB找到相关的LSP信息。此外，当PCE被告知由第一请求提供的失败链路标识符时，它可以在重用现有LSP的部分资源的同时并发地重新计算受影响的LSP。这是可能的，因为被动有状态PCE可以通过检查其LSP-DB来检查受故障链路影响的其他LSP及其路由信息。因此，可以实现更好的性能，例如更好的资源利用率或阻止即将到来的由于链路故障而发送的新重新路由请求的最小概率。
If the target is to avoid resource contention within the time window of a high number of LSP rerouting requests, a stateful PCE can retain the under-construction LSP resource usage information for a given time and exclude it from being used for a forthcoming LSP's request.
如果目标是在大量LSP重路由请求的时间窗口内避免资源争用，则有状态PCE可以在给定时间内保留正在构建的LSP资源使用信息，并将其排除在即将到来的LSP请求中。
In this way, it can ensure that the resource will not be double-booked; thus, the issue of resource contention and computation crank-backs can be alleviated.
这样可以确保资源不会被重复预订；因此，可以缓解资源争用和计算回退的问题。
An alternative way to achieve efficient resilience is to maintain SRLG disjointness between LSPs, irrespective of whether or not these LSPs share the source and destination nodes. This can be achieved at provisioning time, if the routes of all the LSPs are requested together, using a synchronized computation of the different LSPs with SRLG disjointness constraint. If the LSPs need to be provisioned at different times, the PCC can specify, as constraints to the path computation, a set of SRLGs using the Exclude Route Object [RFC5521]. However, for the latter to be effective, the entity that requests the route to the PCE needs to maintain updated SRLG information regarding all of the LSPs to which it must maintain the disjointness. A stateless PCE can compute an SRLG-disjoint path by inspecting the TED and precluding the links with the same SRLG values specified in the PCReq message sent by a PCC.
实现高效恢复能力的另一种方法是保持LSP之间的SRLG不相交，而不管这些LSP是否共享源节点和目标节点。如果同时请求所有LSP的路由，则可以在供应时使用具有SRLG分离约束的不同LSP的同步计算来实现这一点。如果需要在不同的时间供应LSP，PCC可以使用排除路由对象[RFC5521]指定一组SRLGs作为路径计算的约束。然而，为了使后者有效，请求到PCE的路由的实体需要维护关于其必须保持不相交的所有LSP的更新SRLG信息。无状态PCE可以通过检查TED并排除具有PCC发送的PCReq消息中指定的相同SRLG值的链路来计算SRLG不相交路径。
A passive stateful PCE maintains the updated SRLG information of the established LSPs in a centralized manner. Therefore, the PCC can specify, as constraints to the path computation, the SRLG disjointness of a set of already established LSPs by only providing the LSP identifiers. Similarly, a passive stateful PCE can also accommodate disjointness using other constraints, such as link, node, or path segment.
被动有状态PCE以集中的方式维护已建立LSP的更新SRLG信息。因此，PCC可以通过仅提供LSP标识符来指定一组已经建立的LSP的SRLG不相交性，作为对路径计算的约束。类似地，被动有状态PCE还可以使用其他约束（例如链接、节点或路径段）来适应不相交性。
In Multi-Layer Networks (MLN), a Virtual Network Topology (VNT) [RFC5212] consists of a set of one or more TE LSPs in the lower layer, which provides TE links to the upper layer. In [RFC5623], the PCE-based architecture is proposed to support path computation in MLN networks in order to achieve inter-layer TE.
在多层网络（MLN）中，虚拟网络拓扑（VNT）[RFC5212]由下层中的一组或多个TE LSP组成，它们向上层提供TE链路。在[RFC5623]中，提出了基于PCE的架构来支持MLN网络中的路径计算，以实现层间TE。
The establishment/teardown of a TE link in VNT needs to take into consideration the state of existing LSPs and/or new LSP request(s) in the higher layer. Hence, when a stateless PCE cannot find the route for a request based on the upper-layer topology information, it does not have enough information to decide whether or not to set up or remove a TE link, which then can result in non-optimal usage of a resource. On the other hand, a passive stateful PCE can make a better decision of when and how to modify the VNT either to accommodate new LSP requests or to reoptimize resource usage across layers irrespective of the PCE models as described in [RFC5623]. Furthermore, given the active capability, the stateful PCE can issue
VNT中TE链路的建立/拆除需要考虑更高层中现有LSP和/或新LSP请求的状态。因此，当无状态PCE无法根据上层拓扑信息找到请求的路由时，它没有足够的信息来决定是否设置或删除TE链路，这会导致资源的非最佳使用。另一方面，被动有状态PCE可以更好地决定何时以及如何修改VNT，以适应新的LSP请求或重新优化跨层的资源使用，而不考虑[RFC5623]中所述的PCE模型。此外，给定主动能力，有状态PCE可以发出
VNT modification suggestions in order to accommodate path setup requests or reoptimize resource usage across layers.
VNT修改建议，以适应路径设置请求或跨层重新优化资源使用。
In order to make efficient usage of network resources, it is sometimes desirable to reoptimize one or more LSPs dynamically. In the case of a stateless PCE, in order to optimize network resource usage dynamically through online planning, a PCC must send a request to the PCE together with detailed path/bandwidth information of the LSPs that need to be concurrently optimized. This means that the PCC must be able to determine when and which LSPs should be optimized. In the case of a passive stateful PCE, given the LSP state information in the LSP database, the process of dynamic optimization of network resources can be simplified without requiring the PCC to supply detailed LSP state information. Moreover, an active stateful PCE can even make the process automated by triggering the request. Because a stateful PCE can maintain information for all LSPs that are in the process of being set up and it may have the ability to control timing and sequence of LSP setup/deletion, the optimization procedures can be performed more intelligently and effectively. A stateful PCE can also determine which LSP should be reoptimized based on network events. For example, when an LSP is torn down, its resources are freed. This can trigger the stateful PCE to automatically determine which LSP should be reoptimized so that the recently freed resources may be allocated to it.
为了有效利用网络资源，有时需要动态地重新优化一个或多个LSP。在无状态PCE的情况下，为了通过在线规划动态优化网络资源使用，PCC必须向PCE发送请求以及需要同时优化的lsp的详细路径/带宽信息。这意味着PCC必须能够确定何时以及应该优化哪些LSP。在被动有状态PCE的情况下，给定LSP数据库中的LSP状态信息，可以简化网络资源的动态优化过程，而不需要PCC提供详细的LSP状态信息。此外，一个活动的有状态PCE甚至可以通过触发请求使过程自动化。由于有状态PCE可以维护正在设置的所有LSP的信息，并且可以控制LSP设置/删除的时间和顺序，因此可以更智能、更有效地执行优化过程。有状态PCE还可以根据网络事件确定应该重新优化哪个LSP。例如，当LSP被拆除时，其资源将被释放。这可以触发有状态PCE自动确定应该重新优化哪个LSP，以便将最近释放的资源分配给它。
A special case of LSP reoptimization is GCO [RFC5557]. Global control of the LSP operation sequence in [RFC5557] is predicated on the use of what is effectively a stateful (or semi-stateful) NMS. The NMS can be either not local to the network nodes, in which case another northbound interface is required for LSP attribute changes, or local/collocated, in which case there are significant issues with efficiency in resource usage. A stateful PCE adds a few features that:
LSP再优化的一个特例是GCO[RFC5557]。[RFC5557]中LSP操作序列的全局控制基于使用有效的有状态（或半有状态）NMS。NMS可以不是网络节点的本地接口，在这种情况下，LSP属性更改需要另一个北向接口；也可以是本地/并置接口，在这种情况下，资源使用效率存在重大问题。有状态PCE增加了以下几个功能：
o Roll the NMS visibility into the PCE and remove the requirement for an additional northbound interface.
o 将NMS可见性滚动到PCE中，并取消额外北行接口的要求。
o Allow the PCE to determine when reoptimization is needed, with which level (GCO or a more incremental optimization).
o 允许PCE确定何时需要重新优化，使用哪个级别（GCO或更增量的优化）。
o Allow the PCE to determine which LSPs should be reoptimized.
o 允许PCE确定应重新优化哪些LSP。
o Allow a PCE to control the sequence of events across multiple PCCs, allowing for bulk (and truly global) optimization, LSP shuffling, etc.
o 允许PCE控制跨多个PCC的事件序列，允许批量（真正的全局）优化、LSP洗牌等。
If LSPs are dynamically allocated and released over time, the resource becomes fragmented. In networks with link bundle, the overall available resource on a (bundle) link might be sufficient for a new LSP request, but if the available resource is not continuous, the request is rejected. Stateful PCEs can be used to perform the defragmentation procedure, because global visibility of LSPs in the network is required to accurately assess resources on the LSPs and to perform defragmentation while ensuring a minimal disruption of the network. This use case cannot be accommodated by a stateless PCE because it does not possess the detailed information of existing LSPs in the network.
如果LSP是随时间动态分配和释放的，那么资源就会变得支离破碎。在具有链路束的网络中，（束）链路上的总可用资源可能足以满足新的LSP请求，但如果可用资源不连续，则请求将被拒绝。有状态PCE可用于执行碎片整理过程，因为需要网络中LSP的全局可见性，以便准确评估LSP上的资源并执行碎片整理，同时确保网络中断最小化。无状态PCE无法适应此用例，因为它不具备网络中现有LSP的详细信息。
Another case of particular interest is the optical spectrum defragmentation in flexible-grid networks. In flexible-grid networks [RFC7698], LSPs with different optical spectrum sizes (such as 12.5GHz, 25GHz, etc.) can coexist so as to accommodate the services with different bandwidth requests. Therefore, even if the overall spectrum size can meet the service request, it may not be usable if the available spectrum resource is not contiguous, but rather fragmented into smaller pieces. Thus, with the help of existing LSP state information, a stateful PCE can make the resource grouped together to be usable. Moreover, a stateful PCE can proactively choose routes for upcoming path requests to reduce the chance of spectrum fragmentation.
另一个特别令人感兴趣的案例是灵活网格网络中的光谱碎片整理。在灵活网格网络[RFC7698]中，具有不同光谱大小（如12.5GHz、25GHz等）的LSP可以共存，以适应不同带宽请求的服务。因此，即使总体频谱大小能够满足服务请求，但如果可用频谱资源不是连续的，而是分割成更小的片段，则其可能不可用。因此，在现有LSP状态信息的帮助下，有状态PCE可以将资源分组在一起以使其可用。此外，有状态PCE可以为即将到来的路径请求主动选择路由，以减少频谱碎片的机会。
PCE has been identified as an appropriate technology for the determination of the paths of Point-to-Multipoint (P2MP) TE LSPs [RFC5671]. The application scenarios and use cases described in Sections 3.1, 3.4, and 3.6 are also applicable to P2MP TE LSPs.
PCE已被确定为确定点对多点（P2MP）TE LSP路径的合适技术[RFC5671]。第3.1、3.4和3.6节中描述的应用场景和用例也适用于P2MP TE LSP。
In addition to these, the stateful nature of a PCE simplifies the information conveyed in PCEP messages since it is possible to refer to the LSPs via an identifier. For P2MP, this is an added advantage where the size of the PCEP message is much larger. In case of stateless PCEs, modification of a P2MP tree requires encoding of all leaves along with the paths in a PCReq message. But by using a stateful PCE with P2MP capability, the PCEP message can be used to convey only the modifications (the other information can be retrieved from the identifier via the LSP-DB).
除此之外，PCE的有状态性质简化了在PCEP消息中传送的信息，因为可以通过标识符引用lsp。对于P2MP，这是一个额外的优势，因为PCEP消息的大小要大得多。在无状态PCE的情况下，修改P2MP树需要对PCReq消息中的所有叶子以及路径进行编码。但是，通过使用具有P2MP功能的有状态PCE，PCEP消息可仅用于传递修改（其他信息可通过LSP-DB从标识符检索）。
In Wavelength Switched Optical Networks (WSONs) [RFC6163], a wavelength-switched LSP traverses one or more fiber links. The bit rates of the client signals carried by the wavelength LSPs may be the same or different. Hence, a fiber link may transmit a number of wavelength LSPs with equal or mixed bit-rate signals. For example, a fiber link may multiplex the wavelengths with only 10 Gbit/s signals, mixed 10 Gbit/s and 40 Gbit/s signals, or mixed 40 Gbit/s and 100 Gbit/s signals.
在波长交换光网络（WSON）[RFC6163]中，波长交换LSP穿过一个或多个光纤链路。波长lsp承载的客户端信号的比特率可以相同或不同。因此，光纤链路可以传输具有相等或混合比特率信号的多个波长lsp。例如，光纤链路可以仅用10 Gbit/s信号、混合10 Gbit/s和40 Gbit/s信号或混合40 Gbit/s和100 Gbit/s信号复用波长。
IA-RWA in WSONs refers to the process (i.e., lightpath computation) that takes into account the optical layer/transmission imperfections as additional (i.e., physical layer) constraints. To be more specific, linear and non-linear effects associated with the optical network elements should be incorporated into the route and wavelength assignment procedure. For example, the physical imperfection can result in the interference of two adjacent lightpaths. Thus, a guard band should be reserved between them to alleviate these effects. The width of the guard band between two adjacent wavelengths depends on their characteristics, such as modulation formats and bit rates. Two adjacent wavelengths with different characteristics (e.g., different bit rates) may need a wider guard band and those with the same characteristics may need a narrower guard band. For example, 50 GHz spacing may be acceptable for two adjacent wavelengths with 40 G signals. But for two adjacent wavelengths with different bit rates (e.g., 10 G and 40 G), a larger spacing such as 300 GHz may be needed. Hence, the characteristics (states) of the existing wavelength LSPs should be considered for a new RWA request in WSON.
WSONs中的IA-RWA是指将光学层/传输缺陷作为附加（即物理层）约束考虑在内的过程（即光路计算）。更具体地说，与光网络元件相关联的线性和非线性效应应纳入路由和波长分配过程中。例如，物理缺陷可导致两个相邻光路的干涉。因此，应在它们之间保留保护带以减轻这些影响。两个相邻波长之间的保护带宽度取决于它们的特性，例如调制格式和比特率。具有不同特性（例如，不同比特率）的两个相邻波长可能需要更宽的保护带，而具有相同特性的波长可能需要更窄的保护带。例如，对于具有40g信号的两个相邻波长，50ghz间隔可被接受。但是对于具有不同比特率的两个相邻波长（例如，10g和40g），可能需要更大的间隔，例如300ghz。因此，对于WSON中的新RWA请求，应考虑现有波长LSP的特性（状态）。
In summary, when stateful PCEs are used to perform the IA-RWA procedure, they need to know the characteristics of the existing wavelength LSPs. The impairment information relating to existing and to-be-established LSPs can be obtained by nodes in WSON networks via external configuration or other means such as monitoring or estimation based on a vendor-specific impair model. However, WSON-related routing protocols, i.e., [RFC7688] and [RFC7580], only advertise limited information (i.e., availability) of the existing wavelengths, without defining the supported client bit rates. It will incur a substantial amount of control-plane overhead if routing protocols are extended to support dissemination of the new information relevant for the IA-RWA process. In this scenario, stateful PCE(s) would be a more appropriate mechanism to solve this problem. Stateful PCE(s) can exploit impairment information of LSPs stored in LSP-DB to provide accurate RWA calculation.
总之，当使用有状态PCE执行IA-RWA程序时，它们需要了解现有波长LSP的特性。WSON网络中的节点可通过外部配置或其他方式（例如基于供应商特定损害模型的监测或估计）获得与现有和待建立lsp相关的损害信息。然而，与WSON相关的路由协议，即[RFC7688]和[RFC7580]，仅公布现有波长的有限信息（即可用性），而不定义支持的客户端比特率。如果扩展路由协议以支持与IA-RWA流程相关的新信息的传播，将产生大量的控制平面开销。在这种情况下，有状态PCE将是解决此问题的更合适的机制。有状态PCE可以利用存储在LSP-DB中的LSP的损害信息提供准确的RWA计算。
This section discusses general issues with stateful PCE deployments and identifies areas where additional protocol extensions and procedures are needed to address them. Definitions of protocol mechanisms are beyond the scope of this document.
本节讨论有状态PCE部署的一般问题，并确定需要附加协议扩展和过程来解决这些问题的领域。协议机制的定义超出了本文件的范围。
Stateless and stateful PCEs can coexist in the same network and be in charge of path computation of different types. To solve the problem of distinguishing between the two types of PCEs, either discovery or configuration may be used.
无状态和有状态PCE可以共存于同一网络中，并负责不同类型的路径计算。为了解决区分这两种PCE的问题，可以使用查找或配置。
Multiple stateful PCEs can coexist in the same network. These PCEs may provide redundancy for load sharing, resilience, or partitioning of computation features. Regardless of the reason for multiple PCEs, an LSP is only delegated to one of the PCEs at any given point in time. However, an LSP can be redelegated between PCEs, for example, when a PCE fails. [RFC7399] discusses various approaches for synchronizing state among the PCEs when multiple PCEs are used for load sharing or backup and compute LSPs for the same network.
多个有状态PCE可以在同一网络中共存。这些PCE可为负载共享、弹性或计算功能分区提供冗余。无论多个PCE的原因是什么，LSP在任何给定时间点都只委派给其中一个PCE。但是，LSP可以在PCE之间重新分配，例如，当PCE发生故障时。[RFC7399]讨论了当多个PCE用于同一网络的负载共享或备份和计算LSP时，在PCE之间同步状态的各种方法。
The LSP-DB is populated using information received from the PCC. Because the accuracy of the computations depends on the accuracy of the databases used and because the updates must reach the PCE from the network, it is worth noting that the PCE view lags behind the true state of the network. Thus, the use of stateful PCE reduces but cannot eliminate the possibility of crankbacks, nor can it guarantee optimal computations all the time. [RFC7399] discusses these limitations and potential ways to alleviate them.
使用从PCC接收的信息填充LSP-DB。由于计算的准确性取决于所用数据库的准确性，并且更新必须从网络到达PCE，因此值得注意的是，PCE视图落后于网络的真实状态。因此，有状态PCE的使用减少了但不能消除回退的可能性，也不能保证始终进行最佳计算。[RFC7399]讨论了这些限制以及缓解这些限制的潜在方法。
In case of multiple PCEs with different capabilities coexisting in the same network, such as a passive stateful PCE and an active stateful PCE, it is useful to refer to an LSP, be it delegated or not, by a unique identifier instead of providing detailed information (e.g., route, bandwidth) associated with it, when these PCEs cooperate on path computation, such as for load sharing.
在具有不同能力的多个PCE共存于同一网络中的情况下，例如被动有状态PCE和主动有状态PCE，通过唯一标识符来引用LSP（无论是否委托）是有用的，而不是提供与其相关联的详细信息（例如，路由、带宽），当这些PCE合作进行路径计算时，例如负载共享。
For a stateful PCE, an important issue is to get the LSP state information resynchronized after a restart. LSP state synchronization procedures can be applied equally to a network node or another PCE, allowing multiple ways to reacquire the LSP database on a restart. Because synchronization may also be skipped, if a PCE
对于有状态PCE，一个重要的问题是在重启后重新同步LSP状态信息。LSP状态同步过程可以平等地应用于网络节点或另一个PCE，允许以多种方式在重新启动时重新获取LSP数据库。因为同步也可能被跳过，如果PCE
implementation has the means to retrieve its database in a different way (for example, from a backup copy stored locally), the state can be restored without further overhead in the network. A hybrid approach where the bulk of the state is recovered locally, and a small amount of state is reacquired from the network, is also possible. Note that locally recovering the state would still require some degree of resynchronization to ensure that the recovered state is indeed up-to-date. Depending on the resynchronization mechanism used, there may be an additional load on the PCE, and there may be a delay in reaching the synchronized state, which may negatively affect survivability. Different resynchronization methods are suited for different deployments and objectives.
实现可以以不同的方式（例如，从本地存储的备份副本）检索其数据库，可以恢复状态，而无需进一步增加网络开销。也可以采用混合方法，其中大部分状态在本地恢复，少量状态从网络重新获取。请注意，本地恢复状态仍需要一定程度的重新同步，以确保恢复的状态确实是最新的。根据使用的重新同步机制，PCE上可能存在额外负载，并且在达到同步状态时可能存在延迟，这可能会对生存性产生负面影响。不同的重新同步方法适用于不同的部署和目标。
This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations through a number of use cases. No new protocol extensions to PCEP are defined in this document.
本文档描述了有状态PCE部署的一般注意事项，并通过一些用例检查了其适用性和好处，以及其挑战和限制。本文件中未定义PCEP的新协议扩展。
The PCEP extensions in support of the stateful PCE and the delegation of path control ability can result in more information and control being available for a hypothetical adversary and a number of additional attack surfaces that must be protected. This includes, but is not limited to, the authentication and encryption of PCEP sessions, snooping of the state of the LSPs active in the network, etc. Therefore, documents in which the PCEP protocol extensions are defined need to consider the issues and risks associated with a stateful PCE.
支持有状态PCE和路径控制能力委派的PCEP扩展可以为假想对手提供更多的信息和控制，以及必须保护的其他攻击面。这包括但不限于，PCEP会话的认证和加密、在网络中活动的LSP的状态窥探等。因此，定义PCEP协议扩展的文档需要考虑与状态PCE相关的问题和风险。
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>.
[RFC4655]Farrel，A.，Vasseur，J.，和J.Ash，“基于路径计算元素（PCE）的体系结构”，RFC 4655，DOI 10.17487/RFC4655，2006年8月<http://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <http://www.rfc-editor.org/info/rfc5440>.
[RFC5440]Vasseur，JP.，Ed.和JL。Le Roux主编，“路径计算元件（PCE）通信协议（PCEP）”，RFC 5440，DOI 10.17487/RFC5440，2009年3月<http://www.rfc-editor.org/info/rfc5440>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path Computation Element Architecture", RFC 7399, DOI 10.17487/RFC7399, October 2014, <http://www.rfc-editor.org/info/rfc7399>.
[RFC7399]Farrel，A.和D.King，“路径计算元素架构中未回答的问题”，RFC 7399，DOI 10.17487/RFC7399，2014年10月<http://www.rfc-editor.org/info/rfc7399>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, DOI 10.17487/RFC4427, March 2006, <http://www.rfc-editor.org/info/rfc4427>.
[RFC4427]Mannie，E.，Ed.和D.Papadimitriou，Ed.，“通用多协议标签交换（GMPLS）的恢复（保护和恢复）术语”，RFC 4427，DOI 10.17487/RFC4427，2006年3月<http://www.rfc-editor.org/info/rfc4427>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc5212>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April 2009, <http://www.rfc-editor.org/info/rfc5521>.
[RFC5521]Oki，E.，Takeda，T.，和A.Farrel，“路由排除的路径计算元素通信协议（PCEP）扩展”，RFC 5521，DOI 10.17487/RFC5521，2009年4月<http://www.rfc-editor.org/info/rfc5521>.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557, July 2009, <http://www.rfc-editor.org/info/rfc5557>.
[RFC5557]Lee，Y.，Le Roux，JL.，King，D.，和E.Oki，“支持全局并发优化的路径计算元素通信协议（PCEP）要求和协议扩展”，RFC 5557，DOI 10.17487/RFC5557，2009年7月<http://www.rfc-editor.org/info/rfc5557>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc5623>.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, DOI 10.17487/RFC5671, October 2009, <http://www.rfc-editor.org/info/rfc5671>.
[RFC5671]Yasukawa，S.和A.Farrel，Ed.“路径计算元素（PCE）对点对多点（P2MP）MPLS和GMPLS流量工程（TE）的适用性”，RFC 5671，DOI 10.17487/RFC5671，2009年10月<http://www.rfc-editor.org/info/rfc5671>.
[RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, DOI 10.17487/RFC6163, April 2011, <http://www.rfc-editor.org/info/rfc6163>.
[RFC6163]Lee，Y.，Ed.，Bernstein，G.，Ed.，和W.Imajuku，“波长交换光网络（WSON）的GMPLS和路径计算元件（PCE）控制框架”，RFC 6163，DOI 10.17487/RFC6163，2011年4月<http://www.rfc-editor.org/info/rfc6163>.
[RFC7580] Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu, "OSPF-TE Extensions for General Network Element Constraints", RFC 7580, DOI 10.17487/RFC7580, June 2015, <http://www.rfc-editor.org/info/rfc7580>.
[RFC7580]Zhang，F.，Lee，Y.，Han，J.，Bernstein，G.，和Y.Xu，“一般网元约束的OSPF-TE扩展”，RFC 7580，DOI 10.17487/RFC75802015年6月<http://www.rfc-editor.org/info/rfc7580>.
[RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", RFC 7688, DOI 10.17487/RFC7688, November 2015, <http://www.rfc-editor.org/info/rfc7688>.
[RFC7688]Lee，Y.，Ed.和G.Bernstein，Ed.，“波长交换光网络信号和网元兼容性的GMPLS OSPF增强”，RFC 7688，DOI 10.17487/RFC7688，2015年11月<http://www.rfc-editor.org/info/rfc7688>.
[RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., Fu, X., Ceccarelli, D., and I. Hussain, "Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 7698, DOI 10.17487/RFC7698, November 2015, <http://www.rfc-editor.org/info/rfc7698>.
[RFC7698]Gonzalez de Dios，O.，Ed.，Casellas，R.，Ed.，Zhang，F.，Fu，X.，Ceccarelli，D.，和I.Hussain，“基于GMPLS的灵活网格密集波分复用（DWDM）网络控制框架和要求”，RFC 7698，DOI 10.17487/RFC7698，2015年11月<http://www.rfc-editor.org/info/rfc7698>.
Acknowledgements
致谢
We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur, and Ravi Torvi for the useful comments and discussions.
我们要感谢西里尔·玛格丽亚（Cyril Margaria）、阿德里安·法雷尔（Adrian Farrel）、JP Vasseur和拉维·托维（Ravi Torvi）的有益评论和讨论。
Contributors
贡献者
The following people all contributed significantly to this document and are listed below in alphabetical order:
以下人员对本文件做出了重大贡献，并按字母顺序排列如下：
Ramon Casellas CTTC - Centre Tecnologic de Telecomunicacions de Catalunya Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain Email: ramon.casellas@cttc.es
Ramon Casellas CTTC-加泰罗尼亚大道电信技术中心。Carl Friedrich Gauss n7 Castelldefels，巴塞罗那08860西班牙电子邮件：ramon。casellas@cttc.es
Edward Crabbe Email: edward.crabbe@gmail.com
爱德华·克拉布电子邮件：爱德华。crabbe@gmail.com
Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka 560008 India Email: dhruv.dhody@huawei.com
杜鲁夫杜迪华为技术有限公司，卡纳塔克邦班加罗尔，邮编560008，印度电子邮件：杜鲁夫。dhody@huawei.com
Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo Emilio Vargas 6 Madrid, 28045 Spain Phone: +34 913374013 Email: ogondio@tid.es
Oscar Gonzalez de Dios Telefonica Investigacion y Desarrollo Emilio Vargas 6马德里28045西班牙电话：+34 913374013电子邮件：ogondio@tid.es
Young Lee Huawei 1700 Alma Drive, Suite 100 Plano, TX 75075 United States of America Phone: +1 972 509 5599 x2240 Fax: +1 469 229 5397 Email: leeyoung@huawei.com
Young Lee Huawei 1700 Alma Drive，100号套房，德克萨斯州Plano，75075美国电话：+1 972 509 5599 x2240传真：+1 469 229 5397电子邮件：leeyoung@huawei.com
Jan Medved Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States of America Email: jmedved@cisco.com
Jan Medved Cisco Systems，Inc.170 West Tasman Dr.San Jose，CA 95134美利坚合众国电子邮件：jmedved@cisco.com
Robert Varga Pantheon Technologies LLC Mlynske Nivy 56 Bratislava 821 05 Slovakia Email: robert.varga@pantheon.sk
罗伯特·瓦尔加万神殿技术有限责任公司Mlynske Nivy 56布拉迪斯拉发821 05斯洛伐克电子邮件：罗伯特。varga@pantheon.sk
Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 China Phone: +86-755-28972912 Email: zhangfatai@huawei.com
深圳市龙岗区华为基地坂田华为技术研发中心F3-5-B Fatai Zhang中国电话：+86-755-28972912电子邮件：zhangfatai@huawei.com
Xiaobing Zi
子小兵
Authors' Addresses
作者地址
Xian Zhang (editor) Huawei Technologies F3-5-B R&D Center Huawei Industrial Base Bantian, Longgang District Shenzhen, Guangdong 518129 China
张贤（编辑）华为技术F3-5-B研发中心华为工业基地广东省深圳市龙岗区坂田518129
Email: zhang.xian@huawei.com
Email: zhang.xian@huawei.com
Ina Minei (editor) Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Ina Minei（编辑）谷歌公司1600圆形剧场公园路山景，加利福尼亚州94043美利坚合众国
Email: inaminei@google.com
Email: inaminei@google.com