draft-ietf-pce-stateful-pce-app-08.txt   rfc8051.txt 
PCE Working Group X. Zhang, Ed. Internet Engineering Task Force (IETF) X. Zhang, Ed.
Internet-Draft Huawei Technologies Request for Comments: 8051 Huawei Technologies
Intended status: Informational I. Minei, Ed. Category: Informational I. Minei, Ed.
Expires: May 4, 2017 Google, Inc. ISSN: 2070-1721 Google, Inc.
October 31, 2016 January 2017
Applicability of a Stateful Path Computation Element (PCE) Applicability of a Stateful Path Computation Element (PCE)
draft-ietf-pce-stateful-pce-app-08
Abstract Abstract
A stateful Path Computation Element (PCE) maintains information about A stateful Path Computation Element (PCE) maintains information about
Label Switched Path (LSP) characteristics and resource usage within a Label Switched Path (LSP) characteristics and resource usage within a
network in order to provide traffic engineering calculations for its network in order to provide traffic-engineering calculations for its
associated Path Computation Clients (PCCs). This document describes associated Path Computation Clients (PCCs). This document describes
general considerations for a stateful PCE deployment and examines its general considerations for a stateful PCE deployment and examines its
applicability and benefits, as well as its challenges and limitations applicability and benefits, as well as its challenges and
through a number of use cases. PCE Communication Protocol (PCEP) limitations, through a number of use cases. PCE Communication
extensions required for stateful PCE usage are covered in separate Protocol (PCEP) extensions required for stateful PCE usage are
documents. covered in separate documents.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on May 4, 2017. 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.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 4 3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 5
3.1. Optimization of LSP Placement . . . . . . . . . . . . . . 4 3.1. Optimization of LSP Placement . . . . . . . . . . . . . . 5
3.1.1. Throughput Maximization and Bin Packing . . . . . . . 5 3.1.1. Throughput Maximization and Bin Packing . . . . . . . 6
3.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 8 3.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 9
3.1.4. Predictability . . . . . . . . . . . . . . . . . . . 9 3.1.4. Predictability . . . . . . . . . . . . . . . . . . . 10
3.2. Auto-bandwidth Adjustment . . . . . . . . . . . . . . . . 11 3.2. Auto-Bandwidth Adjustment . . . . . . . . . . . . . . . . 11
3.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 11 3.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 12
3.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 12 3.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 14 3.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 15
3.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 15 3.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 15
3.6. LSP Re-optimization . . . . . . . . . . . . . . . . . . . 15 3.6. LSP Reoptimization . . . . . . . . . . . . . . . . . . . 16
3.7. Resource Defragmentation . . . . . . . . . . . . . . . . 16 3.7. Resource Defragmentation . . . . . . . . . . . . . . . . 17
3.8. Point-to-Multi-Point Applications . . . . . . . . . . . . 17 3.8. Point-to-Multipoint Applications . . . . . . . . . . . . 17
3.9. Impairment-Aware Routing and Wavelength Assignment (IA- 3.9. Impairment-Aware Routing and Wavelength Assignment
RWA) . . . . . . . . . . . . . . . . . . . . . . . . . . 17 (IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 18 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 19
4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 18 4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 19
4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 19 4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 19
4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 19 4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20 6.1. Normative References . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 6.2. Informative References . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 21 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
[RFC4655] defines the architecture for a Path Computation Element [RFC4655] defines the architecture for a model based on the Path
(PCE)-based model for the computation of Multiprotocol Label Computation Element (PCE) for the computation of Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
Label Switched Paths (TE LSPs). To perform such a constrained Label Switched Paths (TE LSPs). To perform such a constrained
computation, a PCE stores the network topology (i.e., TE links and computation, a PCE stores the network topology (i.e., TE links and
nodes) and resource information (i.e., TE attributes) in its TE nodes) and resource information (i.e., TE attributes) in its TE
Database (TED). [RFC5440] describes the Path Computation Element Database (TED). [RFC5440] describes the Path Computation Element
Protocol (PCEP) for interaction between a Path Computation Client Protocol (PCEP) for interaction between a Path Computation Client
(PCC) and a PCE, or between two PCEs, enabling computation of TE (PCC) and a PCE, or between two PCEs, enabling computation of TE
LSPs. LSPs.
As per [RFC4655], a PCE can be either stateful or stateless. A As per [RFC4655], a PCE can be either stateful or stateless. A
stateful PCE maintains two sets of information for use in path stateful PCE maintains two sets of information for use in path
computation. The first is the Traffic Engineering Database (TED) computation. The first is the Traffic Engineering Database (TED),
which includes the topology and resource state in the network. This which includes the topology and resource state in the network. This
information can be obtained by a stateful PCE using the same information can be obtained by a stateful PCE using the same
mechanisms as a stateless PCE (see [RFC4655]). The second is the LSP mechanisms as a stateless PCE (see [RFC4655]). The second is the LSP
State Database (LSP-DB), in which a PCE stores attributes of all State Database (LSP-DB), in which a PCE stores attributes of all
active LSPs in the network, such as their paths through the network, active LSPs in the network, such as their paths through the network,
bandwidth/resource usage, switching types and LSP constraints. This bandwidth/resource usage, switching types, and LSP constraints. This
state information allows the PCE to compute constrained paths while state information allows the PCE to compute constrained paths while
considering individual LSPs and their inter-dependency. However, considering individual LSPs and their inter-dependency. However,
this requires reliable state synchronization mechanisms between the this requires reliable state synchronization mechanisms between the
PCE and the network, between the PCE and the PCCs, and between PCE and the network, between the PCE and the PCCs, and between
cooperating PCEs, with potentially significant control plane overhead cooperating PCEs, with potentially significant control-plane overhead
and maintenance of a large amount of state data, as explained in and maintenance of a large amount of state data, as explained in
[RFC4655]. [RFC4655].
This document describes how a stateful PCE can be used to solve This document describes how a stateful PCE can be used to solve
various problems for MPLS-TE and GMPLS networks, and the benefits it various problems for MPLS-TE and GMPLS networks and the benefits it
brings to such deployments. Note that alternative solutions relying brings to such deployments. Note that alternative solutions relying
on stateless PCEs may also be possible for some of these use cases, on stateless PCEs may also be possible for some of these use cases
and will be mentioned for completeness where appropriate. and will be mentioned for completeness where appropriate.
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: PCC, This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP peer. PCE, and PCEP peer.
This document defines the following terms: This document defines the following terms:
Stateful PCE: a PCE that has access to not only the network state, 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 but also to the set of active paths and their reserved resources
for its computations. A stateful PCE might also retain for its computations. A stateful PCE might also retain
information regarding LSPs under construction in order to reduce information regarding LSPs under construction in order to reduce
churn and resource contention. The additional state allows the churn and resource contention. The additional state allows the
PCE to compute constrained paths while considering individual LSPs PCE to compute constrained paths while considering individual LSPs
and their interactions. Note that this requires reliable state and their interactions. Note that this requires reliable state
synchronization mechanisms between the PCE and the network, PCE synchronization mechanisms between the PCE and the network, PCE
and PCC, and between cooperating PCEs. and PCC, and between cooperating PCEs.
Passive Stateful PCE: a PCE that uses LSP state information learned Passive Stateful PCE: a PCE that uses LSP state information learned
from PCCs to optimize path computations. It does not actively from PCCs to optimize path computations. It does not actively
update LSP state. A PCC maintains synchronization with the PCE. update LSP state. A PCC maintains synchronization with the PCE.
Active Stateful PCE:: a PCE that may issue recommendations to the Active Stateful PCE: a PCE that may issue recommendations to the
network. For example, an Active Stateful PCE may utilize the network. For example, an Active Stateful PCE may use the
Delegation mechanism to update LSP parameters in those PCCs that Delegation mechanism to update LSP parameters in those PCCs that
delegated control over their LSPs to the PCE. delegate control over their LSPs to the PCE.
Delegation: an operation to grant a PCE temporary rights to modify a Delegation: an operation to grant a PCE temporary rights to modify a
subset of LSP parameters on one or more PCC's LSPs. LSPs are 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 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 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 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 point in time. For intra-domain LSPs, this PCC should be the LSP
head end. head end.
LSP State Database: information about all LSPs and their attributes. LSP State Database: information about all LSPs and their attributes.
PCE Initiation: a PCE, assuming LSP delegation granted by default, PCE Initiation: assuming LSP delegation granted by default, a PCE
can issue recommendations to the network. can issue recommendations to the network.
Minimum Cut Set: the minimum set of links for a specific source Minimum Cut Set: the minimum set of links for a specific source
destination pair which, when removed from the network, results in destination pair that, when removed from the network, results in a
a specific source being completely isolated from specific specific source being completely isolated from a specific
destination. The summed capacity of these links is equivalent to destination. The summed capacity of these links is equivalent to
the maximum capacity from the source to the destination by the the maximum capacity from the source to the destination by the
max-flow min-cut theorem. max-flow min-cut theorem.
3. Application Scenarios 3. Application Scenarios
In the following sections, several use cases are described, In the following sections, several use cases are described,
showcasing scenarios that benefit from the deployment of a stateful showcasing scenarios that benefit from the deployment of a stateful
PCE. PCE.
3.1. Optimization of LSP Placement 3.1. Optimization of LSP Placement
The following use cases demonstrate a need for visibility into global The following use cases demonstrate a need for visibility into global
LSP states in PCE path computations, and for a PCE control of LSP states in PCE path computations, and for a PCE control of
sequence and timing in altering LSP path characteristics within and sequence and timing in altering LSP path characteristics within and
across PCEP sessions. Reference topologies for the use cases across PCEP sessions. Reference topologies for the use cases
described later in this section are shown in Figures 1 and 2. described later in this section are shown in Figures 1 and 2.
Some of the use cases below are focused on MPLS-TE deployments, but Some of the use cases below are focused on MPLS-TE deployments but
may also apply to GMPLS. Unless otherwise cited, use cases assume may also apply to GMPLS. Unless otherwise cited, use cases assume
that all LSPs listed exist at the same LSP priority. that all LSPs listed exist at the same LSP priority.
The main benefit in the cases below comes from moving away from an 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 asynchronous PCC-driven mode of operation to a model that allows for
central control over LSP computations and maintenance, and focuses central control over LSP computations and maintenance, and focuses
specifically on the active stateful PCE model of operation. specifically on the active stateful PCE model of operation.
+-----+ +-----+
| A | | A |
+-----+ +-----+
\ \
+-----+ +-----+ +-----+ +-----+
| C |----------------------| E | | C |----------------------| E |
+-----+ +-----+ +-----+ +-----+
/ \ +-----+ / / \ +-----+ /
+-----+ +-----| D |-----+ +-----+ +-----| D |-----+
| B | +-----+ | B | +-----+
+-----+ +-----+
Figure 1: Reference topology 1 Figure 1: Reference Topology 1
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A | | B | | C | | A | | B | | C |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | |
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| E +--------+ F +--------+ G | | E +--------+ F +--------+ G |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 2: Reference topology 2 Figure 2: Reference Topology 2
3.1.1. Throughput Maximization and Bin Packing 3.1.1. Throughput Maximization and Bin Packing
Because LSP attribute changes in [RFC5440] are driven by Path Because LSP attribute changes in [RFC5440] are driven by Path
Computation Request (PCReq) messages under control of a PCC's local Computation Request (PCReq) messages under control of a PCC's local
timers, the sequence of resource reservation arrivals occurring in timers, the sequence of resource reservation arrivals occurring in
the network will be randomized. This, coupled with a lack of global 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 LSP state visibility on the part of a stateless PCE, may result in
suboptimal throughput in a given network topology, as will be shown suboptimal throughput in a given network topology, as will be shown
in the example below. in the example below.
Reference topology 2 in Figure 2 and Tables 1 and 2 show an example 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 lack of in which throughput is at 50% of optimal as a result of the lack of
visibility and synchronized control across PCC's. In this scenario, visibility and synchronized control across PCCs. In this scenario,
the decision must be made as to whether to route any portion of the 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 E-G demand, as any demand routed for this source and destination will
decrease system throughput. decrease system throughput.
+------+--------+----------+ +------+--------+----------+
| Link | Metric | Capacity | | Link | Metric | Capacity |
+------+--------+----------+ +------+--------+----------+
| A-E | 1 | 10 | | A-E | 1 | 10 |
| B-F | 1 | 10 | | B-F | 1 | 10 |
| C-G | 1 | 10 | | C-G | 1 | 10 |
| E-F | 1 | 10 | | E-F | 1 | 10 |
| F-G | 1 | 10 | | F-G | 1 | 10 |
+------+--------+----------+ +------+--------+----------+
Table 1: Link parameters for Throughput use case Table 1: Link Parameters for Throughput Use Case
+------+-----+-----+-----+--------+----------+-------+ +------+-----+-----+-----+--------+----------+-------+
| Time | LSP | Src | Dst | Demand | Routable | Path | | Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+-------+ +------+-----+-----+-----+--------+----------+-------+
| 1 | 1 | E | G | 10 | Yes | E-F-G | | 1 | 1 | E | G | 10 | Yes | E-F-G |
| 2 | 2 | A | B | 10 | No | --- | | 2 | 2 | A | B | 10 | No | --- |
| 3 | 1 | F | C | 10 | No | --- | | 3 | 1 | F | C | 10 | No | --- |
+------+-----+-----+-----+--------+----------+-------+ +------+-----+-----+-----+--------+----------+-------+
Table 2: Throughput use case demand time series Table 2: Throughput Use Case Demand Time Series
In many cases throughput maximization becomes a bin packing problem. In many cases, throughput maximization becomes a bin-packing problem.
While bin packing itself is an NP-hard problem, a number of common While bin packing itself is an NP-hard problem, a number of common
heuristics which run in polynomial time can provide significant heuristics that run in polynomial time can provide significant
improvements in throughput over random reservation event improvements in throughput over random reservation event
distribution, especially when traversing links which are members of distribution, especially when traversing links that are members of
the minimum cut set for a large subset of source destination pairs. the minimum cut set for a large subset of source destination pairs.
Tables 3 and 4 show a simple use case using Reference Topology 1 in 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 Figure 1, where LSP state visibility and control of reservation order
across PCCs would result in significant improvement in total across PCCs would result in significant improvement in total
throughput. throughput.
+------+--------+----------+ +------+--------+----------+
| Link | Metric | Capacity | | Link | Metric | Capacity |
+------+--------+----------+ +------+--------+----------+
| A-C | 1 | 10 | | A-C | 1 | 10 |
| B-C | 1 | 10 | | B-C | 1 | 10 |
| C-E | 10 | 5 | | C-E | 10 | 5 |
| C-D | 1 | 10 | | C-D | 1 | 10 |
| D-E | 1 | 10 | | D-E | 1 | 10 |
+------+--------+----------+ +------+--------+----------+
Table 3: Link parameters for Bin Packing use case Table 3: Link Parameters for Bin-Packing Use Case
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path | | Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 5 | Yes | A-C-D-E | | 1 | 1 | A | E | 5 | Yes | A-C-D-E |
| 2 | 2 | B | E | 10 | No | --- | | 2 | 2 | B | E | 10 | No | --- |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
Table 4: Bin Packing use case demand time series Table 4: Bin-Packing Use Case Demand Time Series
3.1.2. Deadlock 3.1.2. Deadlock
This section discusses a use case of cross-LSP impact under degraded This section discusses the use case of cross-LSP impact under
operation. Most existing RSVP-TE implementations will not tear down degraded operation. Most existing RSVP-TE implementations will not
established LSPs in the event of the failure of the bandwidth tear down established LSPs in the event of the failure of the
increase procedure detailed in [RFC3209]. This behavior is directly bandwidth increase procedure detailed in [RFC3209]. This behavior is
implied to be correct in [RFC3209] and is often desirable from an directly implied to be correct in [RFC3209] and is often desirable
operator's perspective, because either a) the destination prefixes from an operator's perspective, because either a) the destination
are not reachable via any means other than MPLS or b) this would prefixes are not reachable via any means other than MPLS or b) this
result in significant packet loss as demand is shifted to other LSPs would result in significant packet loss as demand is shifted to other
in the overlay mesh. LSPs in the overlay mesh.
In addition, there are currently few implementations offering dynamic In addition, there are currently few implementations offering dynamic
ingress admission control (policing of the traffic volume mapped onto ingress admission control (policing of the traffic volume mapped onto
an LSP) at the label edge router (LER). Having ingress admission an LSP) at the Label Edge Router (LER). Having ingress admission
control on a per LSP basis is not necessarily desirable from an control on a per-LSP basis is not necessarily desirable from an
operational perspective, as a) one must over-provision tunnels operational perspective, as a) one must over-provision tunnels
significantly in order to avoid deleterious effects resulting from significantly in order to avoid deleterious effects resulting from
stacked transport and flow control systems (for example for tunnels stacked transport and flow control systems (for example, for tunnels
that are dynamically resized based on current traffic) and b) there that are dynamically resized based on current traffic) and b) there
is currently no efficient commonly available northbound interface for is currently no efficient commonly available northbound interface for
dynamic configuration of per LSP ingress admission control. dynamic configuration of per-LSP ingress admission control.
Lack of ingress admission control coupled with the behavior in Lack of ingress admission control coupled with the behavior in
[RFC3209] may result in LSPs operating out of profile for significant [RFC3209] may result in LSPs operating out of profile for significant
periods of time. It is reasonable to expect that these out-of- periods of time. It is reasonable to expect that these out-of-
profile LSPs will be operating in a degraded state and experience profile LSPs will be operating in a degraded state and experience
traffic loss, but because they end up sharing common network traffic loss. Moreover, because those LSPs end up sharing common
interfaces with other LSPs operating within their bandwidth network interfaces with other LPSs operating within their bandwidth
reservations, thus impacting the operation of the in-profile LSPs, reservations, they will impact the operation of the in-profile LSPs,
even when there is unused network capacity elsewhere in the network. even when there is unused network capacity elsewhere in the network.
Furthermore, this behavior will cause information loss in the TED Furthermore, this behavior will cause information loss in the TED
with regards to the actual available bandwidth on the links used by 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 the out-of-profile LSPs, as the reservations on the links no longer
reflect the capacity used. reflect the capacity used.
Reference Topology 1 in Figure 1 and Tables 5 and 6 show a use case 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 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 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. respectively. At a later time, the demand of LSP 1 increases to 20.
Under such a demand, the LSP cannot be resignaled. However, the Under such a demand, the LSP cannot be resignaled. However, the
existing LSP will not be torn down. In the absence of ingress existing LSP will not be torn down. In the absence of ingress
policing, traffic on LSP 1 will cause degradation for traffic of LSP 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 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. information loss in the TED with regard to the actual network state.
The problem could be easily ameliorated by global visibility of LSP The problem could be easily ameliorated by global visibility of the
state coupled with PCC-external demand measurements and placement of LSP state coupled with PCC-external demand measurements and placement
two LSPs on disjoint links. Note that while the demand of 20 for LSP of two LSPs on disjoint links. Note that while the demand of 20 for
1 could never be satisfied in the given topology, what could be LSP 1 could never be satisfied in the given topology, isolation from
achieved would be isolation from the ill-effects of the the ill-effects of the (unsatisfiable) increased demand could be
(unsatisfiable) increased demand. achieved.
+------+--------+----------+ +------+--------+----------+
| Link | Metric | Capacity | | Link | Metric | Capacity |
+------+--------+----------+ +------+--------+----------+
| A-C | 1 | 10 | | A-C | 1 | 10 |
| B-C | 1 | 10 | | B-C | 1 | 10 |
| C-E | 10 | 5 | | C-E | 10 | 5 |
| C-D | 1 | 10 | | C-D | 1 | 10 |
| D-E | 1 | 10 | | D-E | 1 | 10 |
+------+--------+----------+ +------+--------+----------+
Table 5: Link parameters for the 'Degraded operation' example Table 5: Link Parameters for the 'Degraded Operation' Example
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path | | Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 2 | Yes | A-C-D-E | | 1 | 1 | A | E | 2 | Yes | A-C-D-E |
| 2 | 2 | B | E | 2 | Yes | B-C-D-E | | 2 | 2 | B | E | 2 | Yes | B-C-D-E |
| 3 | 1 | A | E | 20 | No | --- | | 3 | 1 | A | E | 20 | No | --- |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
Table 6: Degraded operation demand time series Table 6: 'Degraded Operation' Demand Time Series
3.1.3. Minimum Perturbation 3.1.3. Minimum Perturbation
As a result of both the lack of visibility into global LSP state and As a result of both the lack of visibility into the global LSP state
the lack of control over event ordering across PCE sessions, and the lack of control over event ordering across PCE sessions,
unnecessary perturbations may be introduced into the network by a unnecessary perturbations may be introduced into the network by a
stateless PCE. Tables 7 and 8 show an example of an unnecessary stateless PCE. Tables 7 and 8 show an example of an unnecessary
network perturbation using Reference Topology 1 in Figure 1. In this network perturbation using Reference Topology 1 in Figure 1. In this
case an unimportant (high LSP priority value) LSP (LSP1) is first set case, an unimportant (high LSP priority value) LSP (LSP1) is first
up along the shortest path. At time 2, which is assumed to be 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- relatively close to time 1, a second more important (lower LSP-
priority value) LSP (LSP2) is established, preempting LSP1, priority value) LSP (LSP2) is established, preempting LSP1
potentially causing traffic loss. LSP1 is then reestablished on the potentially causing traffic loss. LSP1 is then reestablished on the
longer A-C-E path. longer A-C-E path.
+------+--------+----------+ +------+--------+----------+
| Link | Metric | Capacity | | Link | Metric | Capacity |
+------+--------+----------+ +------+--------+----------+
| A-C | 1 | 10 | | A-C | 1 | 10 |
| B-C | 1 | 10 | | B-C | 1 | 10 |
| C-E | 10 | 10 | | C-E | 10 | 10 |
| C-D | 1 | 10 | | C-D | 1 | 10 |
| D-E | 1 | 10 | | D-E | 1 | 10 |
+------+--------+----------+ +------+--------+----------+
Table 7: Link parameters for the 'Minimum-Perturbation' example Table 7: Link Parameters for the 'Minimum-Perturbation' Example
+------+-----+-----+-----+--------+----------+----------+---------+ +------+-----+-----+-----+--------+----------+----------+---------+
| Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path | | Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path |
+------+-----+-----+-----+--------+----------+----------+---------+ +------+-----+-----+-----+--------+----------+----------+---------+
| 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E | | 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E |
| 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E | | 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E |
| 3 | 1 | A | E | 7 | 7 | Yes | A-C-E | | 3 | 1 | A | E | 7 | 7 | Yes | A-C-E |
+------+-----+-----+-----+--------+----------+----------+---------+ +------+-----+-----+-----+--------+----------+----------+---------+
Table 8: Minimum-Perturbation LSP and demand time series Table 8: 'Minimum-Perturbation' LSP and Demand Time Series
A stateful PCE can help in this scenario by computing both routes at A stateful PCE can help in this scenario by computing both routes at
the same time. The advantages of using a stateful PCE over the same time. The advantages of using a stateful PCE over
exploiting a stateless PCE via Global Concurrent Optimization(GCO) exploiting a stateless PCE via Global Concurrent Optimization (GCO)
are three folds. First is the ability to accommodate concurrent path are threefold. First is the ability to accommodate concurrent path
computation from different PCCs. Second is the reduction of control computation from different PCCs. Second is the reduction of control-
plane overhead since the stateful PCE has the route information of plane overhead since the stateful PCE has the route information of
the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to
further optimize the placement of LSPs. This will ensure placement further optimize the placement of LSPs. This will ensure placement
of the more important LSP along the shortest path, avoiding the setup of the more important LSP along the shortest path, avoiding the setup
and subsequent preemption of the lower priority LSP. Similarly, when and subsequent preemption of the lower priority LSP. Similarly, when
a new higher priority LSP which requires preemption of existing lower a new higher priority LSP that requires preemption of an existing
priority LSP(s), a stateful PCE can determine the minimum number of lower priority LSP(s), a stateful PCE can determine the minimum
lower priority LSP(s) to reroute using the make-before-break (MBB) number of lower priority LSPs to reroute using the Make-Before-Break
mechanism without disrupting any service and then set up the higher (MBB) mechanism without disrupting any service and then set up the
priority LSP. higher priority LSP.
3.1.4. Predictability 3.1.4. Predictability
Randomization of reservation events caused by lack of control over Randomization of reservation events caused by lack of control over
event ordering across PCE sessions results in poor predictability in event ordering across PCE sessions results in poor predictability in
LSP routing. An offline system applying a consistent optimization LSP routing. An offline system applying a consistent optimization
method will produce predictable results to within either the boundary method will produce predictable results to within either the boundary
of forecast error (when reservations are over-provisioned by of forecast error (when reservations are over-provisioned by
reasonable margins) or to the variability of the signal and the reasonable margins) or to the variability of the signal and the
forecast error (when applying some hysteresis in order to minimize forecast error (when applying some hysteresis in order to minimize
churn). Predictable results are valuable for being able to simulate churn). Predictable results are valuable for being able to simulate
the network and reliably test it under various scenarios, especially the network and reliably test it under various scenarios, especially
under various failure modes and planned maintenances when predictable under various failure modes and planned maintenances when predictable
path characteristics are desired under contention for network path characteristics are desired under contention for network
resources. resources.
Reference Topology 1 and Tables 9, 10 and 11 show the impact of event Reference Topology 1 and Tables 9, 10, and 11 show the impact of
ordering and predictability of LSP routing. event ordering and predictability of LSP routing.
+------+--------+----------+ +------+--------+----------+
| Link | Metric | Capacity | | Link | Metric | Capacity |
+------+--------+----------+ +------+--------+----------+
| A-C | 1 | 10 | | A-C | 1 | 10 |
| B-C | 1 | 10 | | B-C | 1 | 10 |
| C-E | 1 | 10 | | C-E | 1 | 10 |
| C-D | 1 | 10 | | C-D | 1 | 10 |
| D-E | 1 | 10 | | D-E | 1 | 10 |
+------+--------+----------+ +------+--------+----------+
Table 9: Link parameters for the 'Predictability' example Table 9: Link Parameters for the 'Predictability' Example
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path | | Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 7 | Yes | A-C-E | | 1 | 1 | A | E | 7 | Yes | A-C-E |
| 2 | 2 | B | E | 7 | Yes | B-C-D-E | | 2 | 2 | B | E | 7 | Yes | B-C-D-E |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
Table 10: Predictability LSP and demand time series 1 Table 10: 'Predictability' LSP and Demand Time Series 1
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path | | Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| 1 | 2 | B | E | 7 | Yes | B-C-E | | 1 | 2 | B | E | 7 | Yes | B-C-E |
| 2 | 1 | A | E | 7 | Yes | A-C-D-E | | 2 | 1 | A | E | 7 | Yes | A-C-D-E |
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
Table 11: Predictability LSP and demand time series 2 Table 11: 'Predictability' LSP and Demand Time Series 2
As can be shown in the example, both LSPs are routed in both cases, 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 but along very different paths. This would be a challenge if
reliable simulation of the network is attempted. An active stateful reliable simulation of the network is attempted. An active stateful
PCE can solve this through control over LSP ordering. Based on PCE can solve this through control over LSP ordering. Based on
triggers such as a failure or an optimization trigger, the PCE can triggers such as a failure or an optimization trigger, the PCE can
order the computations and path setup in a deterministic way. order the computations and path setup in a deterministic way.
3.2. Auto-bandwidth Adjustment 3.2. Auto-Bandwidth Adjustment
The bandwidth requirement of LSPs often change over time, requiring The bandwidth requirements of LSPs often change over time, requiring
resizing the LSP. In most implementations available today, the head- LSP resizing. In most implementations available today, the head-end
end node performs this function by monitoring the actual bandwidth node performs this function by monitoring the actual bandwidth usage,
usage, triggering a recomputation and resignaling when a threshold is triggering a recomputation and resignaling when a threshold is
reached. This operation is referred as auto-bandwidth adjustment. reached. This operation is referred to as "auto-bandwidth
The head-end node either recomputes the path locally, or it requests adjustment". The head-end node either recomputes the path locally,
a recomputation from a PCE by sending a PCReq message. In the latter or it requests a recomputation from a PCE by sending a PCReq message.
case, the PCE computes a new path and provides the new route In the latter case, the PCE computes a new path and provides the new
suggestion. Upon receiving the reply from the PCE, the PCC re- route suggestion. Upon receiving the reply from the PCE, the PCC
signals the LSP in Shared-Explicit (SE) mode along the newly computed resignals the LSP in Shared-Explicit (SE) mode along the newly
path. With a stateless PCE, the head-end node needs to provide the computed path. With a stateless PCE, the head-end node needs to
current used bandwidth and the route information via path computation provide the currently used bandwidth and the route information via
request messages. Note that in this scenario, the head-end node is path computation request messages. Note that in this scenario, the
the one that drives the LSP resizing based on local information, and head-end node is the one that drives the LSP resizing based on local
that the difference between using a stateless and a passive stateful information, and that the difference between using a stateless and a
PCE is in the level of optimization of the LSP placement as discussed passive stateful PCE is in the level of optimization of the LSP
in the previous section. placement as discussed in the previous section.
A more interesting smart bandwidth adjustment case is one where the A more interesting smart bandwidth adjustment case is one where the
LSP resizing decision is done by an external entity, with access to LSP resizing decision is done by an external entity with access to
additional information such as historical trending data, application- additional information such as historical trending data, application-
specific information about expected demands or policy information, as specific information about expected demands or policy information, as
well as knowledge of the actual desired flow volumes. In this case well as knowledge of the actual desired flow volumes. In this case,
an active stateful PCE provides an advantage in both the computation an active stateful PCE provides an advantage in both the computation
with knowledge of all LSPs in the domain and in the ability to with knowledge of all LSPs in the domain and in the ability to
trigger bandwidth modification of the LSP. trigger bandwidth modification of the LSP.
3.3. Bandwidth Scheduling 3.3. Bandwidth Scheduling
Bandwidth scheduling allows network operators to reserve resources in Bandwidth scheduling allows network operators to reserve resources in
advance according to the agreements with their customers, and allow advance according to the agreements with their customers and allows
them to transmit data with specified starting time and duration, for them to transmit data with a specified starting time and duration,
example for a scheduled bulk data replication between data centers. for example, for a scheduled bulk data replication between data
centers.
Traditionally, this can be supported by network management system Traditionally, this can be supported by Network Management System
(NMS) operation through path pre-establishment and activation on the (NMS) operation through path pre-establishment and activation on the
agreed starting time. However, this does not provide efficient agreed starting time. However, this does not provide efficient
network usage since the established paths exclude the possibility of network usage since the established paths exclude the possibility of
being used by other services even when they are not used for being used by other services even when they are not used for
undertaking any service. It can also be accomplished through GMPLS undertaking any service. It can also be accomplished through GMPLS
protocol extensions by carrying the related request information protocol extensions by carrying the related request information
(e.g., starting time and duration) across the network. Nevertheless, (e.g., starting time and duration) across the network. Nevertheless,
this method inevitably increases the complexity of signaling and this method inevitably increases the complexity of the signaling and
routing process. routing process.
A passive stateful PCE can support this application with better A passive stateful PCE can support this application with better
efficiency since it can alleviate the burden of processing on network efficiency since it can alleviate the burden of processing on network
elements. This requires the PCE to maintain the scheduled LSPs and elements. This requires the PCE to maintain the scheduled LSPs and
their associated resource usage, as well as the ability of head-ends their associated resource usage, as well as the ability of head-ends
to trigger signaling for LSP setup/deletion at the correct time. to trigger signaling for LSP setup/deletion at the correct time.
This approach requires coarse time synchronization between PCEs and This approach requires coarse time synchronization between PCEs and
PCCs. With PCE initiation capability, a PCE can trigger the setup PCCs. With PCE initiation capability, a PCE can trigger the setup
and deletion of scheduled requests in a centralized manner, without and deletion of scheduled requests in a centralized manner, without
skipping to change at page 12, line 28 skipping to change at page 13, line 8
The recovery use cases discussed in the following sections show how The recovery use cases discussed in the following sections show how
leveraging a stateful PCE can simplify the computation of recovery leveraging a stateful PCE can simplify the computation of recovery
path(s). In particular, two characteristics of a stateful PCE are path(s). In particular, two characteristics of a stateful PCE are
used: 1) using information stored in the LSP-DB for determining used: 1) using information stored in the LSP-DB for determining
shared protection resources and 2) performing computations with shared protection resources and 2) performing computations with
knowledge of all LSPs in a domain. knowledge of all LSPs in a domain.
3.4.1. Protection 3.4.1. Protection
If a PCC can specify in a request whether the computation is for a 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 working path or for protection and a PCC can report the resource as a
a working or protection path, then the following text applies. A PCC working or protection path, then the following text applies. A PCC
can send multiple requests to the PCE, asking for two LSPs and use can send multiple requests to the PCE, asking for two LSPs, and use
them as working and backup paths separately. Either way, the them as working and backup paths separately. Either way, the
resources bound to backup paths can be shared by different LSPs to resources bound to backup paths can be shared by different LSPs to
improve the overall network efficiency, such as m:n protection or improve the overall network efficiency, such as m:n protection or
pre-configured shared mesh recovery techniques as specified in pre-configured shared mesh recovery techniques as specified in
[RFC4427]. If resource sharing is supported for LSP protection, the [RFC4427]. If resource sharing is supported for LSP protection, the
information relating to existing LSPs is required to avoid allocation information relating to existing LSPs is required to avoid allocation
of shared protection resources to two LSPs that might fail together of shared protection resources to two LSPs that might fail together
and cause protection contention issues. A stateless PCE can and cause protection contention issues. A stateless PCE can
accommodate this use case by having the PCC pass this information as accommodate this use case by having the PCC pass this information as
a constraint in the path computation request. A passive stateful PCE a constraint in the path computation request. A passive stateful PCE
can more easily accommodate this need using the information stored in can more easily accommodate this need using the information stored in
its LSP-DB. Furthermore, an active stateful PCE can help with (re)- its LSP-DB. Furthermore, an active stateful PCE can help with
optimizization of protection resource sharing as well as LSP (re)optimization of protection resource sharing as well as LSP
maintenance operation with fewer impact on protection resources. maintenance operation with less impact on protection resources.
+----+ +----+
|PCE | |PCE |
+----+ +----+
+------+ +------+ +------+ +------+ +------+ +------+
| A +----------+ B +----------+ C | | A +----------+ B +----------+ C |
+--+---+ +---+--+ +---+--+ +--+---+ +---+--+ +---+--+
| | | | | |
| +---------+ | | +---------+ |
| | | | | |
| +--+---+ +------+ | | +--+---+ +------+ |
+-----+ E +----------+ D +-----+ +-----+ E +----------+ D +-----+
+------+ +------+ +------+ +------+
Figure 3: Reference topology 3 Figure 3: Reference Topology 3
For example, in the network depicted in Figure 3, suppose there For example, in the network depicted in Figure 3, suppose there
exists LSP1 with working path LSP1_working following A->E and with exists LSP1 with working path LSP1_working following A->E and with
backup path LSP1_backup following A->B->E. A request arrives asking 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 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 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 path LSP2_backup should not share the same protection resource with
LSP1 since LSP2 shares part of its resource (specifically A->E) 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 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. is no such constraint if B->C->D->E is chosen for LSP2_working.
If a stateless PCE is used, the head node B needs to be aware of the If a stateless PCE is used, the head node B needs to be aware of the
existence of LSPs which share the route of LSP2_working and 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 details of their protection resources. B must pass this information
to the PCE as a constraint so as to request a path with diversity. to the PCE as a constraint so as to request a path with diversity.
Alternatively, a stateless PCE may able to compute Shared Risk Link Alternatively, a stateless PCE may be able to compute paths
Group (SRLG)-diversified paths if TED is extended so that it includes diversified by SRLG (Shared Risk Link Group) if TED is extended so
the SRLG information that are protected by a given backup resource, that it includes the SRLG information that is protected by a given
but at the expense of a high complexity in routing. On the other backup resource, but at the expense of a high complexity in routing.
hand, a stateful PCE can get the LSPs information by itself given On the other hand, a stateful PCE can get the LSPs information by
that the LSP identifier(s) and can achieve the goal of finding SRLG- itself given the LSP identifier(s) and can then find SRLG-diversified
diversified protection paths for both LSPs. This is made possible by protection paths for both LSPs. This is made possible by comparing
comparing the LSP resource usage exploiting the LSP-DB accessible by the LSP resource usage exploiting the LSP-DB accessible by the
the stateful PCE. stateful PCE.
3.4.2. Restoration 3.4.2. Restoration
In case of a link failure, such as a fiber cut, multiple LSPs may 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 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. will be informed of the failure by the nodes detecting the failure.
These source nodes will send requests to a PCE for rerouting. In 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 order to reuse the resource taken by an existing LSP, the source node
can send a PCReq message including the Exclude Route Object (XRO) can send a PCReq message that includes the Exclude Route Object (XRO)
with Fail (F) bit set, together with the record route object (RRO) with Fail (F) bit set together with the Record Route Object (RRO)
containing the current route information, as specified in [RFC5521]. that contains the current route information, as specified in
[RFC5521].
If a stateless PCE is used, it might respond to the rerouting If a stateless PCE is used, it might respond to the rerouting
requests separately if they arrive at different times. Thus, it requests separately if the requests arrive at different times. Thus,
might result in sub-optimal resource usage. Even worse, it might it might result in suboptimal resource usage. Even worse, it might
unnecessarily block some of the rerouting requests due to unnecessarily block some of the rerouting requests due to
insufficient resources for later-arrived rerouting messages. If a insufficient resources for rerouting messages that arrive later. If
passive stateful PCE is used to fulfill this task, the procedure can a passive stateful PCE is used to fulfill this task, the procedure
be simplified. The PCCs reporting the failures can include LSP can be simplified. The PCCs reporting the failures can include LSP
identifiers instead of detailed information and the PCE can find identifiers instead of detailed information, and the PCE can find
relevant LSP information by inspecting the LSP-DB. Moreover, the PCE relevant LSP information by inspecting the LSP-DB. Moreover, the PCE
can re-compute the affected LSPs concurrently while reusing part of can recompute the affected LSPs concurrently while reusing part of
the existing LSPs resources when it is informed of the failed link the existing LSP's resources when it is informed of the failed link
identifier provided by the first request. This is made possible identifier provided by the first request. This is made possible
since the passive stateful PCE can check what other LSPs are affected because the passive stateful PCE can check what other LSPs are
by the failed link and their route information by inspecting its LSP- affected by the failed link and their route information by inspecting
DB. As a result, a better performance can be achieved, such as its LSP-DB. As a result, a better performance can be achieved, such
better resource usage or minimal probability of blocking upcoming new as better resource usage or minimal probability of blocking upcoming
rerouting requests sent as a result of the link failure. new rerouting requests sent as a result of the link failure.
If the target is to avoid resource contention within the time-window If the target is to avoid resource contention within the time window
of high number of LSP rerouting requests, a stateful PCE can retain of a high number of LSP rerouting requests, a stateful PCE can retain
the under-construction LSP resource usage information for a given the under-construction LSP resource usage information for a given
time and exclude it from being used for forthcoming LSPs request. In time and exclude it from being used for a forthcoming LSP's request.
this way, it can ensure that the resource will not be double-booked
and thus the issue of resource contention and computation crank-backs In this way, it can ensure that the resource will not be double-
can be alleviated. booked; thus, the issue of resource contention and computation crank-
backs can be alleviated.
3.4.3. SRLG Diversity 3.4.3. SRLG Diversity
An alternative way to achieve efficient resilience is to maintain An alternative way to achieve efficient resilience is to maintain
SRLG disjointness between LSPs, irrespective of whether these LSPs SRLG disjointness between LSPs, irrespective of whether or not these
share the source and destination nodes or not. This can be achieved LSPs share the source and destination nodes. This can be achieved at
at provisioning time, if the routes of all the LSPs are requested provisioning time, if the routes of all the LSPs are requested
together, using a synchronized computation of the different LSPs with together, using a synchronized computation of the different LSPs with
SRLG disjointness constraint. If the LSPs need to be provisioned at SRLG disjointness constraint. If the LSPs need to be provisioned at
different times, the PCC can specify, as constraints to the path different times, the PCC can specify, as constraints to the path
computation a set of SRLGs using the Exclude Route Object [RFC5521]. computation, a set of SRLGs using the Exclude Route Object [RFC5521].
However, for the latter to be effective, it is needed that the entity However, for the latter to be effective, the entity that requests the
that requests the route to the PCE maintains updated SRLG information route to the PCE needs to maintain updated SRLG information regarding
of all the LSPs to which it must maintain the disjointness. A all of the LSPs to which it must maintain the disjointness. A
stateless PCE can compute an SRLG-disjoint path by inspecting the TED stateless PCE can compute an SRLG-disjoint path by inspecting the TED
and precluding the links with the same SRLG values specified in the and precluding the links with the same SRLG values specified in the
PCReq message sent by a PCC. PCReq message sent by a PCC.
A passive stateful PCE maintains the updated SRLG information of the A passive stateful PCE maintains the updated SRLG information of the
established LSPs in a centralized manner. Therefore, the PCC can established LSPs in a centralized manner. Therefore, the PCC can
specify as constraints to the path computation the SRLG disjointness specify, as constraints to the path computation, the SRLG
of a set of already established LSPs by only providing the LSP disjointness of a set of already established LSPs by only providing
identifiers. Similarly, a passive stateful PCE can also accommodate the LSP identifiers. Similarly, a passive stateful PCE can also
disjointness using other constraints, such as link, node or path accommodate disjointness using other constraints, such as link, node,
segment etc. or path segment.
3.5. Maintenance of Virtual Network Topology (VNT) 3.5. Maintenance of Virtual Network Topology (VNT)
In Multi-Layer Networks (MLN), a Virtual Network Topology (VNT) 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 [RFC5212] consists of a set of one or more TE LSPs in the lower
which provides TE links to the upper layer. In [RFC5623], the PCE- layer, which provides TE links to the upper layer. In [RFC5623], the
based architecture is proposed to support path computation in MLN PCE-based architecture is proposed to support path computation in MLN
networks in order to achieve inter-layer TE. networks in order to achieve inter-layer TE.
The establishment/teardown of a TE link in VNT needs to take into 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 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 the higher layer. Hence, when a stateless PCE cannot find the route
for a request based on the upper layer topology information, it does for a request based on the upper-layer topology information, it does
not have enough information to decide whether to set up or remove a not have enough information to decide whether or not to set up or
TE link or not, which then can result in non-optimal usage of 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 resource. On the other hand, a passive stateful PCE can make a
better decision of when and how to modify the VNT either to better decision of when and how to modify the VNT either to
accommodate new LSP requests or to re-optimize resource usage across accommodate new LSP requests or to reoptimize resource usage across
layers irrespective of the PCE models as described in [RFC5623]. layers irrespective of the PCE models as described in [RFC5623].
Furthermore, given the active capability, the stateful PCE can issue Furthermore, given the active capability, the stateful PCE can issue
VNT modification suggestions in order to accommodate path setup VNT modification suggestions in order to accommodate path setup
requests or re-optimize resource usage across layers. requests or reoptimize resource usage across layers.
3.6. LSP Re-optimization 3.6. LSP Reoptimization
In order to make efficient usage of network resources, it is In order to make efficient usage of network resources, it is
sometimes desirable to re-optimize one or more LSPs dynamically. In sometimes desirable to reoptimize one or more LSPs dynamically. In
the case of a stateless PCE, in order to optimize network resource the case of a stateless PCE, in order to optimize network resource
usage dynamically through online planning, a PCC must send a request usage dynamically through online planning, a PCC must send a request
to the PCE together with detailed path/bandwidth information of the to the PCE together with detailed path/bandwidth information of the
LSPs that need to be concurrently optimized. This means the PCC must LSPs that need to be concurrently optimized. This means that the PCC
be able to determine when and which LSPs should be optimized. In the must be able to determine when and which LSPs should be optimized.
case of a passive stateful PCE, given the LSP state information in In the case of a passive stateful PCE, given the LSP state
the LSP database, the process of dynamic optimization of network information in the LSP database, the process of dynamic optimization
resources can be simplified without requiring the PCC to supply of network resources can be simplified without requiring the PCC to
detailed LSP state information. Moreover, an active stateful PCE can supply detailed LSP state information. Moreover, an active stateful
even make the process automated by triggering the request since a PCE can even make the process automated by triggering the request.
stateful PCE can maintain information for all LSPs that are in the Because a stateful PCE can maintain information for all LSPs that are
process of being set up and it may have the ability to control timing in the process of being set up and it may have the ability to control
and sequence of LSP setup/deletion, the optimization procedures can timing and sequence of LSP setup/deletion, the optimization
be performed more intelligently and effectively. A stateful PCE can procedures can be performed more intelligently and effectively. A
also determine which LSP should be re-optimized based on network stateful PCE can also determine which LSP should be reoptimized based
events. For example, when a LSP is torn down, its resources are on network events. For example, when an LSP is torn down, its
freed. This can trigger the stateful PCE to automatically determine resources are freed. This can trigger the stateful PCE to
which LSP should be reoptimized so that the recently freed resources automatically determine which LSP should be reoptimized so that the
may be allocated to it. recently freed resources may be allocated to it.
A special case of LSP re-optimization is GCO [RFC5557]. Global A special case of LSP reoptimization is GCO [RFC5557]. Global
control of LSP operation sequence in [RFC5557] is predicated on the control of the LSP operation sequence in [RFC5557] is predicated on
use of what is effectively a stateful (or semi-stateful) NMS. The the use of what is effectively a stateful (or semi-stateful) NMS.
NMS can be either not local to the network nodes, in which case The NMS can be either not local to the network nodes, in which case
another northbound interface is required for LSP attribute changes, another northbound interface is required for LSP attribute changes,
or local/collocated, in which case there are significant issues with or local/collocated, in which case there are significant issues with
efficiency in resource usage. A stateful PCE adds a few features efficiency in resource usage. A stateful PCE adds a few features
that: that:
o Roll the NMS visibility into the PCE and remove the requirement o Roll the NMS visibility into the PCE and remove the requirement
for an additional northbound interface for an additional northbound interface.
o Allow the PCE to determine when re-optimization is needed, with o Allow the PCE to determine when reoptimization is needed, with
which level (GCO or a more incremental optimization) which level (GCO or a more incremental optimization).
o Allow the PCE to determine which LSPs should be re-optimized o Allow the PCE to determine which LSPs should be reoptimized.
o Allow a PCE to control the sequence of events across multiple o Allow a PCE to control the sequence of events across multiple
PCCs, allowing for bulk (and truly global) optimization, LSP PCCs, allowing for bulk (and truly global) optimization, LSP
shuffling etc. shuffling, etc.
3.7. Resource Defragmentation 3.7. Resource Defragmentation
If LSPs are dynamically allocated and released over time, the If LSPs are dynamically allocated and released over time, the
resource becomes fragmented. In networks with link bundle, the resource becomes fragmented. In networks with link bundle, the
overall available resource on a (bundle) link might be sufficient for overall available resource on a (bundle) link might be sufficient for
a new LSP request, but if the available resource is not continuous, a new LSP request, but if the available resource is not continuous,
the request is rejected. In order to perform the defragmentation the request is rejected. Stateful PCEs can be used to perform the
procedure, stateful PCEs can be used, since global visibility of LSPs defragmentation procedure, because global visibility of LSPs in the
in the network is required to accurately assess resources on the network is required to accurately assess resources on the LSPs and to
LSPs, and perform de-fragmentation while ensuring a minimal perform defragmentation while ensuring a minimal disruption of the
disruption of the network. This use case cannot be accommodated by a network. This use case cannot be accommodated by a stateless PCE
stateless PCE since it does not possess the detailed information of because it does not possess the detailed information of existing LSPs
existing LSPs in the network. in the network.
Another case of particular interest is the optical spectrum Another case of particular interest is the optical spectrum
defragmentation in flexible grid networks. In Flexible grid networks defragmentation in flexible-grid networks. In flexible-grid networks
[RFC7698], LSPs with different optical spectrum sizes (such as [RFC7698], LSPs with different optical spectrum sizes (such as
12.5GHz, 25GHz etc.) can co-exist so as to accommodate the services 12.5GHz, 25GHz, etc.) can coexist so as to accommodate the services
with different bandwidth requests. Therefore, even if the overall with different bandwidth requests. Therefore, even if the overall
spectrum size can meet the service request, it may not be usable if spectrum size can meet the service request, it may not be usable if
the available spectrum resource is not contiguous, but rather the available spectrum resource is not contiguous, but rather
fragmented into smaller pieces. Thus, with the help of existing LSP fragmented into smaller pieces. Thus, with the help of existing LSP
state information, a stateful PCE can make the resource grouped state information, a stateful PCE can make the resource grouped
together to be usable. Moreover, a stateful PCE can proactively together to be usable. Moreover, a stateful PCE can proactively
choose routes for upcoming path requests to reduce the chance of choose routes for upcoming path requests to reduce the chance of
spectrum fragmentation. spectrum fragmentation.
3.8. Point-to-Multi-Point Applications 3.8. Point-to-Multipoint Applications
PCE has been identified as an appropriate technology for the PCE has been identified as an appropriate technology for the
determination of the paths of point-to-multipoint (P2MP) TE LSPs determination of the paths of Point-to-Multipoint (P2MP) TE LSPs
[RFC5671]. The application scenarios and use-cases described in [RFC5671]. The application scenarios and use cases described in
Section 3.1, Section 3.4 and Section 3.6 are also applicable to P2MP Sections 3.1, 3.4, and 3.6 are also applicable to P2MP TE LSPs.
TE LSPs.
In addition to these, the stateful nature of a PCE simplifies the In addition to these, the stateful nature of a PCE simplifies the
information conveyed in PCEP messages since it is possible to refer information conveyed in PCEP messages since it is possible to refer
to the LSPs via an identifier. For P2MP, this is an added advantage, 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 where the size of the PCEP message is much larger. In case of
stateless PCEs, modification of a P2MP tree requires encoding of all stateless PCEs, modification of a P2MP tree requires encoding of all
leaves along with the paths in PCReq message. But using a stateful leaves along with the paths in a PCReq message. But by using a
PCE with P2MP capability, the PCEP message can be used to convey only stateful PCE with P2MP capability, the PCEP message can be used to
the modifications (the other information can be retrieved from the convey only the modifications (the other information can be retrieved
identifier via the LSP-DB). from the identifier via the LSP-DB).
3.9. Impairment-Aware Routing and Wavelength Assignment (IA-RWA) 3.9. Impairment-Aware Routing and Wavelength Assignment (IA-RWA)
In Wavelength Switched Optical Networks (WSONs) [RFC6163], a In Wavelength Switched Optical Networks (WSONs) [RFC6163], a
wavelength-switched LSP traverses one or more fiber links. The bit wavelength-switched LSP traverses one or more fiber links. The bit
rates of the client signals carried by the wavelength LSPs may be the 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 same or different. Hence, a fiber link may transmit a number of
wavelength LSPs with equal or mixed bit rate signals. For example, a wavelength LSPs with equal or mixed bit-rate signals. For example, a
fiber link may multiplex the wavelengths with only 10Gb/s signals, fiber link may multiplex the wavelengths with only 10 Gbit/s signals,
mixed 10Gb/s and 40Gb/s signals, or mixed 40Gb/s and 100Gb/s signals. mixed 10 Gbit/s and 40 Gbit/s signals, or mixed 40 Gbit/s and 100
Gbit/s signals.
IA-RWA in WSONs refers to the process (i.e., lightpath computation) IA-RWA in WSONs refers to the process (i.e., lightpath computation)
that takes into account the optical layer/transmission imperfections that takes into account the optical layer/transmission imperfections
by considering as additional (i.e., physical layer) constraints. To as additional (i.e., physical layer) constraints. To be more
be more specific, linear and non-linear effects associated with the specific, linear and non-linear effects associated with the optical
optical network elements should be incorporated into the route and network elements should be incorporated into the route and wavelength
wavelength assignment procedure. For example, the physical assignment procedure. For example, the physical imperfection can
imperfection can result in the interference of two adjacent result in the interference of two adjacent lightpaths. Thus, a guard
lightpaths. Thus, a guard band should be reserved between them to band should be reserved between them to alleviate these effects. The
alleviate these effects. The width of the guard band between two width of the guard band between two adjacent wavelengths depends on
adjacent wavelengths depends on their characteristics, such as their characteristics, such as modulation formats and bit rates. Two
modulation formats and bit rates. Two adjacent wavelengths with adjacent wavelengths with different characteristics (e.g., different
different characteristics (e.g., different bit rates) may need a bit rates) may need a wider guard band and those with the same
wider guard band and with same characteristics may need a narrower characteristics may need a narrower guard band. For example, 50 GHz
guard band. For example, 50GHz spacing may be acceptable for two spacing may be acceptable for two adjacent wavelengths with 40 G
adjacent wavelengths with 40G signals. But for two adjacent signals. But for two adjacent wavelengths with different bit rates
wavelengths with different bit rates (e.g., 10G and 40G), a larger (e.g., 10 G and 40 G), a larger spacing such as 300 GHz may be
spacing such as 300GHz spacing may be needed. Hence, the needed. Hence, the characteristics (states) of the existing
characteristics (states) of the existing wavelength LSPs should be wavelength LSPs should be considered for a new RWA request in WSON.
considered for a new RWA request in WSON.
In summary, when stateful PCEs are used to perform the IA-RWA In summary, when stateful PCEs are used to perform the IA-RWA
procedure, they need to know the characteristics of the existing procedure, they need to know the characteristics of the existing
wavelength LSPs. The impairment information relating to existing and wavelength LSPs. The impairment information relating to existing and
to-be-established LSPs can be obtained by nodes in WSON networks via to-be-established LSPs can be obtained by nodes in WSON networks via
external configuration or other means such as monitoring or external configuration or other means such as monitoring or
estimation based on a vendor-specific impair model. However, WSON estimation based on a vendor-specific impair model. However, WSON-
related routing protocols, i.e., [RFC7688] and [RFC7580], only related routing protocols, i.e., [RFC7688] and [RFC7580], only
advertise limited information (i.e., availability) of the existing advertise limited information (i.e., availability) of the existing
wavelengths, without defining the supported client bit rates. It wavelengths, without defining the supported client bit rates. It
will incur substantial amount of control plane overhead if routing will incur a substantial amount of control-plane overhead if routing
protocols are extended to support dissemination of the new protocols are extended to support dissemination of the new
information relevant for the IA-RWA process. In this scenario, information relevant for the IA-RWA process. In this scenario,
stateful PCE(s) would be a more appropriate mechanism to solve this stateful PCE(s) would be a more appropriate mechanism to solve this
problem. Stateful PCE(s) can exploit impairment information of LSPs problem. Stateful PCE(s) can exploit impairment information of LSPs
stored in LSP-DB to provide accurate RWA calculation. stored in LSP-DB to provide accurate RWA calculation.
4. Deployment Considerations 4. Deployment Considerations
This section discusses general issues with stateful PCE deployments, This section discusses general issues with stateful PCE deployments
and identifies areas where additional protocol extensions and and identifies areas where additional protocol extensions and
precedures are needed to address them. Definitions of protocol procedures are needed to address them. Definitions of protocol
mechanisms are beyond the scope of this document. mechanisms are beyond the scope of this document.
4.1. Multi-PCE Deployments 4.1. Multi-PCE Deployments
Stateless and stateful PCEs can co-exist in the same network and be Stateless and stateful PCEs can coexist in the same network and be in
in charge of path computation of different types. To solve the charge of path computation of different types. To solve the problem
problem of distinguishing between the two types of PCEs, either of distinguishing between the two types of PCEs, either discovery or
discovery or configuration may be used. configuration may be used.
Multiple stateful PCEs can co-exist in the same network. These PCEs Multiple stateful PCEs can coexist in the same network. These PCEs
may provide redundancy for load sharing, resilience, or partitioning may provide redundancy for load sharing, resilience, or partitioning
of computation features. Regardless of the reason for multiple PCEs, 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 an LSP is only delegated to one of the PCEs at any given point in
time. However, an LSP can be re-delegated between PCEs, for example time. However, an LSP can be redelegated between PCEs, for example,
when a PCE fails. [RFC7399] discusses various approaches for when a PCE fails. [RFC7399] discusses various approaches for
synchronizing state among the PCEs when multiple PCEs are used for synchronizing state among the PCEs when multiple PCEs are used for
load sharing or backup and compute LSPs for the same network. load sharing or backup and compute LSPs for the same network.
4.2. LSP State Synchronization 4.2. LSP State Synchronization
The LSP-DB is populated using information received from the PCC. The LSP-DB is populated using information received from the PCC.
Because the accuracy of the computations depends on the accuracy of Because the accuracy of the computations depends on the accuracy of
the databases used, it is worth noting that the PCE view lags behind the databases used and because the updates must reach the PCE from
the true state of the network, because the updates must reach the PCE the network, it is worth noting that the PCE view lags behind the
from the network. Thus, the use of stateful PCE reduces but cannot true state of the network. Thus, the use of stateful PCE reduces but
eliminate the possibility of crankbacks, nor can it guarantee optimal cannot eliminate the possibility of crankbacks, nor can it guarantee
computations all the time. [RFC7399] discusses these limitations and optimal computations all the time. [RFC7399] discusses these
potential ways to alleviate them. limitations and potential ways to alleviate them.
In case of multiple PCEs with different capabilities, co-existing in In case of multiple PCEs with different capabilities coexisting in
the same network, such as a passive stateful PCE and an active the same network, such as a passive stateful PCE and an active
stateful PCE, it is useful to refer to a LSP, be it delegated or not, stateful PCE, it is useful to refer to an LSP, be it delegated or
by a unique identifier instead of providing detailed information not, by a unique identifier instead of providing detailed information
(e.g., route, bandwidth etc.) associated with it, when these PCEs (e.g., route, bandwidth) associated with it, when these PCEs
cooperate on path computation, such as for load sharing. cooperate on path computation, such as for load sharing.
4.3. PCE Survivability 4.3. PCE Survivability
For a stateful PCE, an important issue is to get the LSP state For a stateful PCE, an important issue is to get the LSP state
information resynchronized after a restart. LSP state information resynchronized after a restart. LSP state
synchronization procedures can be applied equally to a network node synchronization procedures can be applied equally to a network node
or another PCE, allowing multiple ways of re-acquiring the LSP or another PCE, allowing multiple ways to reacquire the LSP database
database on a restart. Because synchronization may also be skipped, on a restart. Because synchronization may also be skipped, if a PCE
if a PCE implementation has the means to retrieve its database in a implementation has the means to retrieve its database in a different
different way (for example from a backup copy stored locally), the way (for example, from a backup copy stored locally), the state can
state can be restored without further overhead in the network. A be restored without further overhead in the network. A hybrid
hybrid approach where the bulk of the state is recovered locally, and approach where the bulk of the state is recovered locally, and a
a small amount of state is reacquired from the network, is also small amount of state is reacquired from the network, is also
possible. Note that locally recovering the state would still require possible. Note that locally recovering the state would still require
some degree of resynchronization to ensure that the recovered state some degree of resynchronization to ensure that the recovered state
is indeed up-to-date. Depending on the resynchronization mechanism 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 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 delay in reaching the synchronized state, which may negatively affect
survivability. Different resynchronization methods are suited for survivability. Different resynchronization methods are suited for
different deployments and objectives. different deployments and objectives.
5. Security Considerations 5. Security Considerations
This document describes general considerations for a stateful PCE This document describes general considerations for a stateful PCE
deployment and examines its applicability and benefits, as well as deployment and examines its applicability and benefits, as well as
its challenges and limitations through a number of use cases. No new its challenges and limitations through a number of use cases. No new
protocol extensions to PCEP are defined in this document. protocol extensions to PCEP are defined in this document.
The PCEP extensions in support of the stateful PCE and the delegation The PCEP extensions in support of the stateful PCE and the delegation
of path control ability can result in more information and control of path control ability can result in more information and control
being available for a hypothetical adversary and a number of being available for a hypothetical adversary and a number of
additional attack surfaces which must be protected. This includes additional attack surfaces that must be protected. This includes,
but not limited to the authentication and encryption of PCEP but is not limited to, the authentication and encryption of PCEP
sessions, snooping of the state of the LSPs active in the network sessions, snooping of the state of the LSPs active in the network,
etc. Therefore, documents where the PCEP protocol extensions are etc. Therefore, documents in which the PCEP protocol extensions are
defined need to consider the issues and risks associated with a defined need to consider the issues and risks associated with a
stateful PCE. stateful PCE.
6. IANA Considerations 6. References
This document does not require any IANA action.
7. Contributing Authors
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
Edward Crabbe
Email: edward.crabbe@gmail.com
Dhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruv.dhody@huawei.com
Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
Madrid, 28045
Spain
Phone: +34 913374013
Email: ogondio@tid.es
Young Lee
Huawei
1700 Alma Drive, Suite 100
Plano, TX 75075
US
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
EMail: leeyoung@huawei.com
Jan Medved
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
US
Email: jmedved@cisco.com
Robert Varga
Pantheon Technologies LLC
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.sk
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Xiaobing Zi
Email: unknown
8. Acknowledgements
We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and
Ravi Torvi for the useful comments and discussions.
9. References
9.1. Normative References 6.1. Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. <http://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>. <http://www.rfc-editor.org/info/rfc5440>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399, Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014, DOI 10.17487/RFC7399, October 2014,
<http://www.rfc-editor.org/info/rfc7399>. <http://www.rfc-editor.org/info/rfc7399>.
9.2. Informative References 6.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>. <http://www.rfc-editor.org/info/rfc3209>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized (Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006, DOI 10.17487/RFC4427, March 2006,
<http://www.rfc-editor.org/info/rfc4427>. <http://www.rfc-editor.org/info/rfc4427>.
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <http://www.rfc-editor.org/info/rfc4657>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi- M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
DOI 10.17487/RFC5212, July 2008, DOI 10.17487/RFC5212, July 2008,
<http://www.rfc-editor.org/info/rfc5212>. <http://www.rfc-editor.org/info/rfc5212>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the [RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <http://www.rfc-editor.org/info/rfc5521>. 2009, <http://www.rfc-editor.org/info/rfc5521>.
skipping to change at page 23, line 35 skipping to change at page 22, line 23
DOI 10.17487/RFC7688, November 2015, DOI 10.17487/RFC7688, November 2015,
<http://www.rfc-editor.org/info/rfc7688>. <http://www.rfc-editor.org/info/rfc7688>.
[RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F.,
Fu, X., Ceccarelli, D., and I. Hussain, "Framework and Fu, X., Ceccarelli, D., and I. Hussain, "Framework and
Requirements for GMPLS-Based Control of Flexi-Grid Dense Requirements for GMPLS-Based Control of Flexi-Grid Dense
Wavelength Division Multiplexing (DWDM) Networks", Wavelength Division Multiplexing (DWDM) Networks",
RFC 7698, DOI 10.17487/RFC7698, November 2015, RFC 7698, DOI 10.17487/RFC7698, November 2015,
<http://www.rfc-editor.org/info/rfc7698>. <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.
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
Edward Crabbe
Email: edward.crabbe@gmail.com
Dhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
India
Email: dhruv.dhody@huawei.com
Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
Madrid, 28045
Spain
Phone: +34 913374013
Email: 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
Jan Medved
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: jmedved@cisco.com
Robert Varga
Pantheon Technologies LLC
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.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
Xiaobing Zi
Authors' Addresses Authors' Addresses
Xian Zhang (editor) Xian Zhang (editor)
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District F3-5-B R&D Center
Huawei Industrial Base
Bantian, Longgang District
Shenzhen, Guangdong 518129 Shenzhen, Guangdong 518129
P.R.China China
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Ina Minei (editor) Ina Minei (editor)
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US United States of America
Email: inaminei@google.com Email: inaminei@google.com
 End of changes. 120 change blocks. 
394 lines changed or deleted 383 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/