draft-ietf-pce-stateful-pce-app-00.txt   draft-ietf-pce-stateful-pce-app-01.txt 
Network Working Group X. Zhang, Ed. PCE Working Group X. Zhang, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational I. Minei, Ed. Intended status: Informational I. Minei, Ed.
Expires: February 15, 2014 Juniper Networks, Inc. Expires: March 29, 2014 Juniper Networks, Inc.
August 16, 2013 September 25, 2013
Applicability of Stateful Path Computation Element (PCE) Applicability of Stateful Path Computation Element (PCE)
draft-ietf-pce-stateful-pce-app-00 draft-ietf-pce-stateful-pce-app-01
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 through a number of use cases. Path applicability and benefits, as well as its challenges and limitations
Computation Element Protocol (PCEP) extensions required for stateful through a number of use cases. Path Computation Element Protocol
PCE usage are covered in separate documents. (PCEP) extensions required for stateful PCE usage are covered in
separate documents.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 15, 2014. This Internet-Draft will expire on March 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of stateful PCE . . . . . . . . . . . . . . . . . . . 4 3. Overview of Stateful PCE . . . . . . . . . . . . . . . . . . . 4
4. Deployment considerations . . . . . . . . . . . . . . . . . . 5 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
4.1. Multi-PCE deployments . . . . . . . . . . . . . . . . . . 5 4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 5
4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 5 4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 5
4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 5 4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 6
5. Application scenarios . . . . . . . . . . . . . . . . . . . . 6 5. Application Scenarios . . . . . . . . . . . . . . . . . . . . 6
5.1. Optimization of LSP placement . . . . . . . . . . . . . . 6 5.1. Optimization of LSP Placement . . . . . . . . . . . . . . 7
5.1.1. Throughput Maximization and Bin Packing . . . . . . . 7 5.1.1. Throughput Maximization and Bin Packing . . . . . . . 8
5.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . . 8 5.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . . 10 5.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . . 11
5.1.4. Predictability . . . . . . . . . . . . . . . . . . . . 11 5.1.4. Predictability . . . . . . . . . . . . . . . . . . . . 12
5.2. Auto-bandwidth Adjustment . . . . . . . . . . . . . . . . 12 5.2. Auto-bandwidth Adjustment . . . . . . . . . . . . . . . . 13
5.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . . 13 5.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . . 13
5.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4.1. Protection . . . . . . . . . . . . . . . . . . . . . . 13 5.4.1. Protection . . . . . . . . . . . . . . . . . . . . . . 14
5.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 15 5.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 15
5.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . . 16 5.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . . 16
5.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 16 5.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 17
5.6. LSP Re-optimization . . . . . . . . . . . . . . . . . . . 17 5.6. LSP Re-optimization . . . . . . . . . . . . . . . . . . . 17
5.7. Resource Defragmentation . . . . . . . . . . . . . . . . . 17 5.7. Resource Defragmentation . . . . . . . . . . . . . . . . . 18
5.8. Impairment-Aware Routing and Wavelength Assignment 5.8. Impairment-Aware Routing and Wavelength Assignment
(IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . . 18 (IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 19 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Editorial notes and open issues . . . . . . . . . . . 23 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 Path Computation Element
(PCE)-based model for the computation of Multiprotocol Label (PCE)-based model 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). PCEP defines the communication between a Path Protocol (PCEP) for interaction between a Path Computation Client
Computation Client (PCC) and a Path Control Element (PCE), or between (PCC) and a PCE, or between two PCEs, enabling computation of TE LSPs
two PCEs, enabling computation of Multiprotocol Label Switching in the context of MPLS networks. Extensions for support of GMPLS in
(MPLS) for Traffic Engineering Label Switched Path (TE LSP) PCEP are defined in [I-D.ietf-pce-gmpls-pcep-extensions].
characteristics. Extensions for support of GMPLS in PCEP are defined
in [I-D.ietf-pce-gmpls-pcep-extensions].
As per [RFC4655], a PCE can be either stateful or stateless. As per [RFC4655], a PCE can be either stateful or stateless.
Stateless PCEs have been shown to be useful in many scenarios, Stateless PCEs have been shown to be useful in many scenarios,
including constraint-based path computation in multi-domain/ including constraint-based path computation in multi-domain/
multi-layer networks. Compared to a stateless PCE, a stateful PCE multi-layer networks. Compared to a stateless PCE, a stateful PCE
has access to not only the network state, but also to the set of has access to not only the network state, but also to the set of
active paths and their reserved resources. Furthermore, a stateful active paths and their reserved resources. Furthermore, a stateful
PCE might also retain information regarding LSPs under construction PCE might also retain information regarding LSPs under construction
in order to reduce churn and resource contention. This state allows in order to reduce churn and resource contention. This state allows
the PCE to compute constrained paths while considering individual the PCE to compute constrained paths while considering individual
LSPs and their interactions. Note that this requires reliable state LSPs and their interactions. However, this requires reliable state
synchronization mechanisms between the PCE and the network, PCE and synchronization mechanisms between the PCE and the network, PCE and
PCC, and between cooperating PCEs, with potentially significant PCC, and between cooperating PCEs, with potentially significant
control plane overhead and maintenance of a large amount of state control plane overhead and maintenance of a large amount of state
data, as explained in [RFC4655]. data, as explained in [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, PCEP peer.
This document uses the following terms defined in This document uses the following terms defined in
[I-D.ietf-pce-stateful-pce]: Passive Stateful PCE, Active Stateful [I-D.ietf-pce-stateful-pce]: Passive Stateful PCE, Active Stateful
PCE, Delegation, Revocation, Delegation Timeout Interval, LSP State PCE, Delegation, Revocation, Delegation Timeout Interval, LSP State
Report, LSP Update Request, LSP State Database. Report, LSP Update Request, LSP State Database.
This document defines the following term: This document defines the following term:
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, result in a destination pair which, when removed from the network, results in
specific source being completely isolated from specific a specific source being completely isolated from 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. Overview of stateful PCE 3. Overview of Stateful PCE
This section is included for the convenience of the reader, please This section is included for the convenience of the reader, please
refer to the referenced documents for details of the operation. refer to the referenced documents for details of the operation.
[I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to
enable stateful control of tunnels within and across PCEP sessions in enable stateful control of tunnels within and across PCEP sessions in
compliance with [RFC4657]. It includes mechanisms to effect tunnel compliance with [RFC4657]. It includes mechanisms to effect tunnel
state synchronization between PCCs and PCEs, delegation of control state synchronization between PCCs and PCEs, delegation of control
over tunnels to PCEs, and PCE control of timing and sequence of path over tunnels to PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions. computations within and across PCEP sessions.
[I-D.ietf-pce-stateful-pce] applies equally to MPLS-TE and GMPLS [I-D.ietf-pce-stateful-pce] applies equally to MPLS-TE and GMPLS
LSPs. LSPs.
Several new functions were added in PCEP to support stateful PCEs and [I-D.ietf-pce-stateful-pce] distinguishes between an active and a
are described in [I-D.ietf-pce-stateful-pce]. A function can be passive stateful PCE. A passive stateful PCE uses LSP state
initiated either from a PCC towards a PCE (C-E) or from a PCE towards information learned from PCCs to optimize path computations but does
a PCC (E-C). The new functions are: not actively update LSP state. In contrast, an active stateful PCE
may issue recommendations to the network. For example, an active
stateful PCE may utilize the delegation mechanism to update LSP
parameters in those PCCs that delegated control over their LSPs to
the PCE.
Several new functions are added in PCEP to support both active and
passive stateful PCEs. They are described in
[I-D.ietf-pce-stateful-pce]. A function can be initiated either from
a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). The new
functions are:
Capability negotiation (E-C,C-E): both the PCC and the PCE must Capability negotiation (E-C,C-E): both the PCC and the PCE must
announce during PCEP session establishment that they support PCEP announce during PCEP session establishment that they support PCEP
Stateful PCE extensions. stateful PCE extensions.
LSP state synchronization (C-E): after the session between the PCC LSP state synchronization (C-E): after the session between the PCC
and a stateful PCE is initialized, the PCE must learn the state of and a stateful PCE is initialized, the PCE must learn the state of
a PCC's LSPs before it can perform path computations or update LSP a PCC's LSPs before it can perform path computations or update LSP
attributes in a PCC. attributes in a PCC.
LSP Update Request (E-C): A PCE requests modification of attributes LSP update request (E-C): A PCE requests modification of attributes
on a PCC's LSP. on a PCC's LSP.
LSP State Report (C-E): a PCC sends an LSP State Report to a PCE LSP state report (C-E): a PCC sends an LSP state report to a PCE
whenever the state of an LSP changes. whenever the state of an LSP changes.
LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to
update LSP attributes on one or more LSPs; the PCE becomes the update LSP attributes on one or more LSPs; the PCE becomes the
authoritative source of the LSP's attributes as long as the authoritative source of the LSP's attributes as long as the
delegation is in effect; the PCC may withdraw the delegation or delegation is in effect; the PCC may withdraw the delegation or
the PCE may give up the delegation. the PCE may give up the delegation.
[I-D.sivabalan-pce-disco-stateful] defines the extensions needed to [I-D.sivabalan-pce-disco-stateful] defines the extensions needed to
support autodiscovery of stateful PCEs when using the IGPs for PCE support auto-discovery of stateful PCEs when using IGP for PCE
discovery. discovery.
4. Deployment considerations 4. Deployment Considerations
This section discusses generic issues with Stateful PCE deployments, This section discusses generic issues with stateful PCE deployments,
and how specific protocol mechanisms can be used to address them. and how specific protocol mechanisms can be used to address them.
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 co-exist in the same network and be
in charge of path computation of different types. To solve the in charge of path computation of different types. To solve the
problem of distinguishing between the two types of PCEs, either problem of distinguishing between the two types of PCEs, either
discovery or configuration may be used. The capability negotiation discovery or configuration may be used. The capability negotiation
in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE
address is configured on the PCC. address is configured on the PCC.
Multiple stateful PCEs can co-exist in the same network. These PCEs
may provide redundancy for load sharing, resilience, or partitioning
of computation features. Regardless of the reason for multiple PCEs,
an LSP is only delegated to one of the PCEs at any given point in
time. [I-D.ietf-pce-stateful-pce] describes how LSPs can be re-
delegated between PCEs, and the procedures on a PCE failure.
[I-D.ietf-pce-questions] discusses various approaches for
synchronizing state among the PCEs when multiple PCEs are used for
load sharing and compute LSPs for the same network.
4.2. LSP State Synchronization 4.2. LSP State Synchronization
A stateful PCE maintains two sets of information for use in path A 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. The bandwidth/resource usage, switching types and LSP constraints. The
stateful PCE extensions defined in [I-D.ietf-pce-stateful-pce] stateful PCE extensions defined in [I-D.ietf-pce-stateful-pce]
support population of this database using information received from support population of this database using information received from
the network nodes via LSP State Report messages. Population of the PCCs via LSP state report messages. Population of the LSP database
LSP database via other means is not precluded. via other means is not precluded.
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 true state of the network, because the updates must reach the PCE
from the network. Thus, the use of stateful PCE reduces but cannot
eliminate the possibility of crankbacks, nor can it guarantee optimal
computations all the time. [I-D.ietf-pce-questions] discusses these
limitations and potential ways to alleviate them.
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. information resynchronized after a restart.
[I-D.ietf-pce-stateful-pce] includes support of a synchronization [I-D.ietf-pce-stateful-pce] includes support of a synchronization
function, allowing the PCC to synchronize its LSP state with the PCE. function, allowing the PCC to synchronize its LSP state with the PCE.
This can be applied equally to an Label Edge Router (LER) client or This can be applied equally to a Label Edge Router (LER) client or
another PCE, allowing for support of multiple ways of re-acquiring another PCE, allowing for support of multiple ways of re-acquiring
the LSP database on a restart. For example, the state can be the LSP database on a restart. For example, the state can be
retrieved from the network nodes, or from another stateful PCE. retrieved from the network nodes, or from another stateful PCE.
Because synchronization may also be skipped, if a PCE implementation Because synchronization may also be skipped, if a PCE implementation
has the means to retrieve its database in a different way (for has the means to retrieve its database in a different way (for
example from a backup copy stored locally), the state can be restored example from a backup copy stored locally), the state can be restored
without further overhead in the network. Note that locally without further overhead in the network. A hybrid approach where the
bulk of the state is recovered locally, and a small amount of state
is reacquired from the network is also possible. Note that locally
recovering the state would still require some degree of recovering the state would still require some degree of
resynchronization to ensure that the recovered state is indeed up-to- resynchronization to ensure that the recovered state is indeed up-to-
date. date. Depending on the resynchronization mechanism used, there may
be additional load on the PCE, and there may be a delay in reaching
the synchronized state, which may negatively affect survivabiliy.
Different resynchronization methods are suited for different
deployments and objectives.
5. Application scenarios 5. 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.
5.1. Optimization of LSP placement 5.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
inter-PCC LSP state in PCE path computations, and for a PCE control LSP states in PCE path computations, and for a PCE control of
of sequence and timing in altering LSP path characteristics within sequence and timing in altering LSP path characteristics within and
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 setup, and focuses central control over LSP computations and setup, and focuses
specifically on the active stateful PCE model of operation. specifically on the active stateful PCE model of operation.
skipping to change at page 7, line 19 skipping to change at page 8, line 8
| | | | | |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| E +--------+ F +--------+ G | | E +--------+ F +--------+ G |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 2: Reference topology 2 Figure 2: Reference topology 2
5.1.1. Throughput Maximization and Bin Packing 5.1.1. Throughput Maximization and Bin Packing
Because LSP attribute changes in [RFC5440] are driven by PCReq Because LSP attribute changes in [RFC5440] are driven by PCReq
messages under control of a PCC's local timers, the sequence of RSVP messages under control of a PCC's local timers, the sequence of
reservation arrivals occurring in the network will be randomized. resource reservation arrivals occurring in the network will be
This, coupled with a lack of global LSP state visibility on the part randomized. This, coupled with a lack of global LSP state visibility
of a stateless PCE may result in suboptimal throughput in a given on the part of a stateless PCE may result in suboptimal throughput in
network topology, as will be shown in the example below. a given network topology, as will be shown 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 lack of
visibility and synchronized control across PCC's. In this scenario, visibility and synchronized control across PCC's. 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 |
skipping to change at page 9, line 17 skipping to change at page 9, line 45
are not reachable via any means other than MPLS or b) this would are not reachable via any means other than MPLS or b) this would
result in significant packet loss as demand is shifted to other LSPs result in significant packet loss as demand is shifted to other LSPs
in the overlay mesh. 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 LER. Having ingress admission control on a per LSP an LSP) at the LER. Having ingress admission control on a per LSP
basis is not necessarily desirable from an operational perspective, basis is not necessarily desirable from an operational perspective,
as a) one must over-provision tunnels significantly in order to avoid as a) one must over-provision tunnels significantly in order to avoid
deleterious effects resulting from stacked transport and flow control deleterious effects resulting from stacked transport and flow control
systems and b) there is currently no efficient commonly available systems (for example for tunnels that are dynamically resized based
northbound interface for dynamic configuration of per LSP ingress on current traffic) and b) there is currently no efficient commonly
admission control (such an interface could easily be defined using available northbound interface for dynamic configuration of per LSP
the extensions for stateful PCE, but has not been yet at the time of ingress admission control.
this writing).
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, but because they end up sharing common network
interfaces with other LSPs operating within their bandwidth interfaces with other LSPs operating within their bandwidth
reservations, they will end up impacting the operation of the in- reservations, they will end up impacting the operation of the in-
profile LSPs, even when there is unused network capacity elsewhere in profile LSPs, even when there is unused network capacity elsewhere in
the network. Furthermore, this behavior will cause information loss the network. Furthermore, this behavior will cause information loss
skipping to change at page 11, line 18 skipping to change at page 12, line 5
| 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 evaluating both requests A stateful PCE can help in this scenario by evaluating both requests
at the same time (due to their proximity in time). This will ensure at the same time (due to their proximity in time). This will ensure
placement of the more important LSP along the shortest path, avoiding placement of the more important LSP along the shortest path, avoiding
the preemption of the lower priority LSP. the preemption of the lower priority LSP. Similarly, when a new
higher priority LSP which requires preemption of existing lower
priority LSP(s), a stateful PCE can determine the minimum number of
lower priority LSP(s) to reroute using the make-before-break (MBB)
mechanism without disrupting any service and then set up the higher
priority LSP.
5.1.4. Predictability 5.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
skipping to change at page 12, line 22 skipping to change at page 13, line 14
+------+-----+-----+-----+--------+----------+---------+ +------+-----+-----+-----+--------+----------+---------+
| 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 were 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 was attempted. A stateful PCE can reliable simulation of the network is attempted. A stateful PCE can
solve this through control over LSP ordering. solve this through control over LSP ordering.
5.2. Auto-bandwidth Adjustment 5.2. Auto-bandwidth Adjustment
The bandwidth requirement of LSPs often change over time, requiring The bandwidth requirement of LSPs often change over time, requiring
resizing the LSP. Currently the head-end node performs this function resizing the LSP. Currently the head-end node performs this function
by monitoring the actual bandwidth usage, triggering a recomputation by monitoring the actual bandwidth usage, triggering a recomputation
and resignaling when a threshold is reached. This operation is and resignaling when a threshold is reached. This operation is
referred as auto-bandwidth adjustment. The head-end node either referred as auto-bandwidth adjustment. The head-end node either
recomputes the path locally, or it requests a recomputation from a recomputes the path locally, or it requests a recomputation from a
PCE by sending a PCReq message. In the latter case, the PCE computes PCE by sending a Path Computation Request (PCReq) message. In the
a new path and provides the new route suggestion. Upon receiving the latter case, the PCE computes a new path and provides the new route
reply from the PCE, the PCC re-signals the LSP in Shared-Explicit suggestion. Upon receiving the reply from the PCE, the PCC re-
(SE) mode along the newly computed path. If a passive stateful PCE signals the LSP in Shared-Explicit (SE) mode along the newly computed
is used, only the new bandwidth information is needed to trigger a path. If a passive stateful PCE is used, only the new bandwidth
path re-computation since the LSP information is already known to the information is needed to trigger a path re-computation since the LSP
PCE. Note that in this scenario, the head-end node is the one that information is already known to the PCE. Note that in this scenario,
drives the LSP resizing based on local information, and that the the head-end node is the one that drives the LSP resizing based on
difference between using a stateless and a passive stateful PCE is in local information, and that the difference between using a stateless
the level of optimization of the LSP placement as discussed in the and a passive stateful PCE is in the level of optimization of the LSP
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.
skipping to change at page 13, line 33 skipping to change at page 14, line 24
increases the complexity of signaling and routing process. increases the complexity of signaling and 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. If an active stateful PCE is available, the PCE can trigger PCCs. If an active stateful PCE is available, the PCE can trigger
the setup/deletion of scheduled requests in a centralized manner, the setup/deletion of scheduled requests in a centralized manner,
without modification of existing head-end behaviors. without modification of existing head-end behaviors, by notifying the
PCCs to set up or tear down the paths.
5.4. Recovery 5.4. Recovery
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.
skipping to change at page 14, line 9 skipping to change at page 14, line 49
computing a set of paths for a given LSP. Alternatively, the PCC can computing a set of paths for a given LSP. Alternatively, the PCC can
send multiple requests to the PCE, asking for working and backup LSPs send multiple requests to the PCE, asking for working and backup LSPs
separately. Either way, the resources bound to backup paths can be separately. Either way, the resources bound to backup paths can be
shared by different LSPs to improve the overall network efficiency, shared by different LSPs to improve the overall network efficiency,
such as m:n protection or pre-configured shared mesh recovery such as m:n protection or pre-configured shared mesh recovery
techniques as specified in [RFC4427]. If resource sharing is techniques as specified in [RFC4427]. If resource sharing is
supported for LSP protection, the information relating to existing supported for LSP protection, the information relating to existing
LSPs is required to avoid allocation of shared protection resources LSPs is required to avoid allocation of shared protection resources
to two LSPs that might fail together and cause protection contention to two LSPs that might fail together and cause protection contention
issues. A stateless PCE can accommodate this use case by having the issues. A stateless PCE can accommodate this use case by having the
PCC pass in this information as a constraint to the path computation PCC pass this information as a constraint in the path computation
request. A stateful PCE can more easily accommodate this need using request. A passive stateful PCE can more easily accommodate this
the information stored in its LSP-DB. need using the information stored in its LSP-DB. Furthermore, an
active stateful PCE can help with (re)-optimizization of protection
resource sharing as well as LSP maintenance operation with fewer
impact on protection resources.
+----+ +----+
|PCE | |PCE |
+----+ +----+
+------+ +------+ +------+ +------+ +------+ +------+
| N1 +----------+ N2 +----------+ N3 | | A +----------+ B +----------+ C |
+--+---+ +---+--+ +---+--+ +--+---+ +---+--+ +---+--+
| | | | | |
| +---------+ | | +---------+ |
| | | | | |
| +--+---+ +------+ | | +--+---+ +------+ |
+-----+ N5 +----------+ N4 +-----+ +-----+ 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 N1->N5 and with exists LSP1 with working path LSP1_working following A->E and with
backup path LSP1_backup following N1->N2->N5. A request arrives backup path LSP1_backup following A->B->E. A request arrives asking
asking for a working and backup path pair to be computed for LSP2, for a working and backup path pair to be computed for LSP2, for a
for a request from N2 to N5. If the PCE decides LSP2_working follows request from B to E. If the PCE decides LSP2_working follows B->A->E,
N2->N1->N5, then the backup path LSP2_backup should not use the same then the backup path LSP2_backup should not use the same protection
protection resource with LSP1 since LSP2 shares part of its resource resource with LSP1 since LSP2 shares part of its resource
(specifically N1->N5) with LSP1 (i.e., these two LSPs are in the same (specifically A->E) with LSP1 (i.e., these two LSPs are in the same
shared risk group). Alternatively, there is no such constraint if shared risk group). Alternatively, there is no such constraint if
N2->N3->N4->N5 is chosen for LSP2_working. B->C->D->E is chosen for LSP2_working.
If a stateless PCE is used, the head node N2 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 which share the route of LSP2_working and of the
details of their protection resources. N2 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 SRLG to the PCE as a constraint so as to request a path with diversity.
diversity. On the other hand, a stateful PCE can get the LSPs On the other hand, a stateful PCE can get the LSPs information by
information by itself and can achieve the goal of finding SRLG- itself and can achieve the goal of finding 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.
5.4.2. Restoration 5.4.2. Restoration
In case of a link failure, such as fiber cut, multiple LSPs may fail In case of a link failure, such as fiber cut, multiple LSPs may fail
at the same time. Thus, the source nodes of the affected LSPs will at the same time. Thus, the source nodes of the affected LSPs will
be informed of the failure by the nodes detecting the failure. These be informed of the failure by the nodes detecting the failure. These
source nodes will send requests to a PCE for rerouting. In order to source nodes will send requests to a PCE for rerouting. In order to
reuse the resource taken by an existing LSP, the source node can send reuse the resource taken by an existing LSP, the source node can send
a PCReq message including the XRO object with F bit set, together a PCReq message including the XRO object with F bit set, together
with RRO object, as specified in [RFC5521]. with RRO object, as specified in [RFC5521].
If a stateless PCE is exploited, it might respond to the rerouting If a stateless PCE is exploited, it might respond to the rerouting
requests separately if they arrive at different times. Thus, it requests separately if they arrive at different times. Thus, it
might result in sub-optimal resource usage. Even worse, it might might result in sub-optimal 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 later-arrived rerouting messages. If a
stateful PCE is used to fulfill this task, it can re-compute the passive stateful PCE is used to fulfill this task, it can re-compute
affected LSPs concurrently while reusing part of the existing LSPs the affected LSPs concurrently while reusing part of the existing
resources when it is informed of the failed link identifier provided LSPs resources when it is informed of the failed link identifier
by the first request. This is made possible since the stateful PCE provided by the first request. This is made possible since the
can check what other LSPs are affected by the failed link and their passive stateful PCE can check what other LSPs are affected by the
route information by inspecting its LSP-DB. As a result, a better failed link and their route information by inspecting its LSP-DB. As
performance, such as better resource usage, minimal probability of a result, a better performance, such as better resource usage,
blocking upcoming new rerouting requests sent as a result of the link minimal probability of blocking upcoming new rerouting requests sent
failure, can be achieved. as a result of the link failure, can be achieved.
In order to further reduce the amount of LSP rerouting messages flow In order to further reduce the amount of LSP rerouting messages flow
in the network, the notification can be performed at the node(s) in the network, the notification can be performed at the node(s)
which detect the link failure. For example, suppose there are two which detect the link failure. For example, suppose there are two
LSPs in the network as shown in Figure 3: (i) LSP1: N1->N5->N4->N3; LSPs in the network as shown in Figure 3: (i) LSP1: A->E->D->C; (ii)
(ii) LSP2: N2->N5->N4. They traverse the failed link between N5-N4. LSP2: B->E->D. They traverse the failed link between E-D. When D
When N4 detects the failure, it can send a notification message to a detects the failure, it can send a notification message to a stateful
stateful PCE. Note that the stateful PCE stores the path information PCE. Note that the stateful PCE stores the path information of the
of the LSPs that are affected by the link failure, so it does not LSPs that are affected by the link failure, so it does not need to
need to acquire this information from N4. Moreover, it can make use acquire this information from D. Moreover, it can make use of the
of the bandwidth resources occupied by the affected LSPs when bandwidth resources occupied by the affected LSPs when performing
performing path recalculation. After N4 receives the new paths from path recalculation. After D receives the new paths from the PCE, it
the PCE, it notifies the ingress nodes of the LSPs, i.e., N1 and N2, notifies the ingress nodes of the LSPs, i.e., A and B, and specifies
and specifies the new paths which should be used as the rerouting the new paths which should be used as the rerouting paths. To
paths. To support this, it would require extensions to the existing support this, it would require extensions to the existing signaling
signaling protocols. protocols.
Alternatively, if the target is to avoid resource contention within Alternatively, if the target is to avoid resource contention within
the time-window of high LSP requests, a stateful PCE can retain the the time-window of high LSP requests, a stateful PCE can retain the
under-construction LSP resource usage information for a given time under-construction LSP resource usage information for a given time
and exclude it from being used for forthcoming LSPs request. In this and exclude it from being used for forthcoming LSPs request. In this
way, it can ensure that the resource will not be double-booked and way, it can ensure that the resource will not be double-booked and
thus the issue of resource contention and computation crank-backs can thus the issue of resource contention and computation crank-backs can
be resolved. be resolved.
5.4.3. SRLG Diversity 5.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 these LSPs
share the source and destination nodes or not. This can be achieved share the source and destination nodes or not. This can be achieved
at provisioning time, if the routes of all the LSPs are requested at 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 (more general, the routes are requested at different different times (more general, the routes are requested at different
times, e.g. in the case of a restoration), the PCC can specify, as times, e.g. in the case of a restoration), the PCC can specify, as
constraints to the path computation a set of Shared Risk Link Groups constraints to the path computation a set of Shared Risk Link Groups
(SRLGs) using the Explicit Route Object [RFC5521]. However, for the (SRLGs) using the Exclude Route Object [RFC5521]. However, for the
latter to be effective, it is needed that the entity that requests latter to be effective, it is needed that the entity that requests
the route to the PCE maintains updated SRLG information of all the the route to the PCE maintains updated SRLG information of all the
LSPs to which it must maintain the disjointness. A stateless PCE can LSPs to which it must maintain the disjointness. A stateless PCE can
compute an SRLG-disjoint path by inspecting the TED and precluding compute an SRLG-disjoint path by inspecting the TED and precluding
the links with the same SRLG values specified in the PCReq message the links with the same SRLG values specified in the PCReq message
sent by a PCC. sent by a PCC.
A 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 disjointness
of a set of already established LSPs by only providing the LSP of a set of already established LSPs by only providing the LSP
identifiers. identifiers. Similarly, a passive stateful PCE can also accommodate
disjointness using other contraints, such as link, node or path
segment etc.
5.5. Maintenance of Virtual Network Topology (VNT) 5.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 layer
which provides TE links to the upper layer. In [RFC5623], the PCE- which provides TE links to the upper layer. In [RFC5623], the PCE-
based architecture is proposed to support path computation in MLN 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. As specified in [RFC5623], a VNT manager (VNTM) is the higher layer. Hence, when a stateless PCE cannot find the route
in charge of setting up connections in the lower layer to provide TE for a request based on the upper layer topology information, it does
links for upper layer. Hence, when a stateless PCE cannot find the not have enough information to decide whether to set up or remove a
route for a request based on the upper layer topology information, it TE link or not, which then can result in non-optimal usage of
needs to interact with the VNTM and rely on the VNTM to decide resource. On the other hand, a passive stateful PCE can make a
whether to set up or remove a TE link or not. On the other hand, a better decision of when and how to modify the VNT either to
stateful PCE can make the decision of when and how to modify the VNT accommodate new LSP requests or to re-optimize resource usage across
either to accommodate new LSP requests or to re-optimize resource layers irrespective of the PCE models as described in [RFC5623].
usage across layers irrespective of the PCE models as described in Furthermore, given the active capability, the stateful PCE can issue
[RFC5623]. VNT modification suggestions in order to accommodate path setup
requests or re-optimize resource usage across layers.
5.6. LSP Re-optimization 5.6. LSP Re-optimization
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 re-optimize 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 the PCC must
be able to determine when and which LSPs should be optimized. In the be able to determine when and which LSPs should be optimized. In the
case of a stateful PCE, given the LSP state information in the LSP case of a stateful PCE, given the LSP state information in the LSP
database, the process of dynamic optimization of network resources database, the process of dynamic optimization of network resources
can be automated without requiring the PCC to supply LSP state can be automated without requiring the PCC to supply LSP state
information or to trigger the request. Moreover, since a stateful information or to trigger the request. Moreover, since a stateful
PCE can maintain information for all LSPs that are in the process of PCE can maintain information for all LSPs that are in the process of
being set up and since it may have the ability to control timing and being set up and since it may have the ability to control timing and
sequence of LSP setup/deletion, the optimization procedures can be sequence of LSP setup/deletion, the optimization procedures can be
performed more intelligently and effectively. performed more intelligently and effectively. A stateful PCE can
also determine which LSP should be re-optimized based on network
events. For example, when a LSP is torn down, its resources are
freed. This can trigger the stateful PCE to automatically determine
which LSP should be reoptimized so that the recently freed resources
may be allocated to it.
A special case of LSP re-optimization is Global Concurrent A special case of LSP re-optimization is Global Concurrent
Optimization (GCO) [RFC5557]. Global control of LSP operation Optimization (GCO) [RFC5557]. Global control of LSP operation
sequence in [RFC5557] is predicated on the use of what is effectively sequence in [RFC5557] is predicated on the use of what is effectively
a stateful (or semi-stateful) NMS. The NMS can be either not local a stateful (or semi-stateful) NMS. The NMS can be either not local
to the switch, in which case another northbound interface is required to the network nodes, in which case another northbound interface is
for LSP attribute changes, or local/collocated, in which case there required for LSP attribute changes, or local/collocated, in which
are significant issues with efficiency in resource usage. A stateful case there are significant issues with efficiency in resource usage.
PCE adds a few features that: A stateful PCE adds a few features 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 re-optimization 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 re-optimized
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.
5.7. Resource Defragmentation 5.7. Resource Defragmentation
In networks with link bundles, if LSPs are dynamically allocated and In networks with link bundles, if LSPs are dynamically allocated and
released over time, the resource becomes fragmented. The overall released over time, the resource becomes fragmented. The overall
available resource on a (bundle) link might be sufficient for a new available resource on a (bundle) link might be sufficient for a new
LSP request, but if the available resource is not continuous, the LSP request, but if the available resource is not continuous, the
request is rejected. In order to perform the defragmentation request is rejected. In order to perform the defragmentation
procedure, stateful PCEs cam be used, since global visibility of LSPs procedure, stateful PCEs can be used, since global visibility of LSPs
in the network is required to accurately assess resources on the in the network is required to accurately assess resources on the
LSPs, and perform de-fragmentation while ensuring a minimal LSPs, and perform de-fragmentation while ensuring a minimal
disruption of the network. This use case cannot be accommodated by a disruption of the network. This use case cannot be accommodated by a
stateless PCE since it does not possess the detailed information of stateless PCE since it does not possess the detailed information of
existing LSPs in the network. existing LSPs in the network.
A case of particular interest to GMPLS-based transport networks is A case of particular interest to GMPLS-based transport networks is
the frequency defragmentation in flexible grid. In Flexible grid the frequency defragmentation in flexible grid. In Flexible grid
networks [I-D.ogrcetal-ccamp-flexi-grid-fwk], LSPs with different networks [I-D.ogrcetal-ccamp-flexi-grid-fwk], LSPs with different
slot widths (such as 12.5G, 25G etc.) can co-exist so as to slot widths (such as 12.5G, 25G etc.) can co-exist so as to
accommodate the services with different bandwidth requests. accommodate the services with different bandwidth requests.
Therefore, even if the overall spectrum can meet the service request, Therefore, even if the overall spectrum can meet the service request,
it may not be usable if it is not contiguous. Thus, with the help of it may not be usable if it is not contiguous. Thus, with the help of
existing LSP state information, stateful PCE can make the resource existing LSP state information, a stateful PCE can make the resource
grouped together to be usable. Moreover, stateful PCE can grouped together to be usable. Moreover, a stateful PCE can
proactively choose routes for upcoming path requests to reduce the proactively choose routes for upcoming path requests to reduce the
chance of spectrum fragmentation. chance of spectrum fragmentation.
5.8. Impairment-Aware Routing and Wavelength Assignment (IA-RWA) 5.8. Impairment-Aware Routing and Wavelength Assignment (IA-RWA)
In WSONs [RFC6163], a wavelength-switched LSP traverses one or more In WSONs [RFC6163], a wavelength-switched LSP traverses one or more
fiber links. The bit rates of the client signals carried by the fiber links. The bit rates of the client signals carried by the
wavelength LSPs may be the same or different. Hence, a fiber link wavelength LSPs may be the same or different. Hence, a fiber link
may transmit a number of wavelength LSPs with equal or mixed bit rate may transmit a number of wavelength LSPs with equal or mixed bit rate
signals. For example, a fiber link may multiplex the wavelengths signals. For example, a fiber link may multiplex the wavelengths
skipping to change at page 19, line 23 skipping to change at page 20, line 25
without defining the supported client bit rates. It will incur without defining the supported client bit rates. It will incur
substantial amount of control plane overhead if routing protocols are substantial amount of control plane overhead if routing protocols are
extended to support dissemination of the new information relevant for extended to support dissemination of the new information relevant for
the IA-RWA process. In this scenario, stateful PCE(s) would be a the IA-RWA process. In this scenario, stateful PCE(s) would be a
more appropriate mechanism to solve this problem. Stateful PCE(s) more appropriate mechanism to solve this problem. Stateful PCE(s)
can exploit impairment information of LSPs stored in LSP-DB to can exploit impairment information of LSPs stored in LSP-DB to
provide accurate RWA calculation. provide accurate RWA calculation.
6. Security Considerations 6. Security Considerations
This document does not introduce any new security considerations The PCEP extensions in support of stateful PCE and the delegation of
beyond those discussed in [I-D.ietf-pce-stateful-pce]. path control, result in more information being available for a
hypothetical adversary and a number of additional attack surfaces
The following topics will be discussed in a future version of this which must be protected. [I-D.ietf-pce-stateful-pce] discusses
document: whether use of a stateful PCE makes the network more or different attack vectors and defines protocol mechanisms to protect
less secure, and security use cases if any. against them. It also lays out implementation requirements for
configuration capabilities that allow the operator to control the PCC
behavior when faced with an attack. This document does not introduce
any new security considerations beyond those discussed in
[I-D.ietf-pce-stateful-pce].
7. Contributing Authors 7. Contributing Authors
The following people all contributed significantly to this document The following people all contributed significantly to this document
and are listed below in alphabetical order: and are listed below in alphabetical order:
Ramon Casellas Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7 Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860 Castelldefels, Barcelona 08860
skipping to change at page 20, line 8 skipping to change at page 21, line 13
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: edc@google.com Email: edc@google.com
Dhruv Dhody Dhruv Dhody
Huawei Technology Huawei Technology
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
INDIA INDIA
EMail: dhruvd@huawei.com EMail: dhruv.dhody@huawei.com
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo Telefonica Investigacion y Desarrollo
Emilio Vargas 6 Emilio Vargas 6
Madrid, 28045 Madrid, 28045
Spain Spain
Phone: +34 913374013 Phone: +34 913374013
Email: ogondio@tid.es Email: ogondio@tid.es
Young Lee Young Lee
Huawei Huawei
1700 Alma Drive, Suite 100 1700 Alma Drive, Suite 100
Plano, TX 75075 Plano, TX 75075
US US
Phone: +1 972 509 5599 x2240 Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397 Fax: +1 469 229 5397
EMail: ylee@huawei.com EMail: leeyoung@huawei.com
Jan Medved Jan Medved
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Email: jmedved@cisco.com Email: jmedved@cisco.com
Robert Varga Robert Varga
Pantheon Technologies LLC Pantheon Technologies LLC
skipping to change at page 21, line 7 skipping to change at page 22, line 11
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28972912 Phone: +86-755-28972912
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Xiaobing Zi Xiaobing Zi
Email: unknown Email: unknown
8. Acknowledgements 8. Acknowledgements
We would like to thank Cyril Margaria, Adrian Farrel and JP Vasseur We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and
for the useful comments and discussions. Ravi Torvi for the useful comments and discussions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-pce-questions]
Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture",
draft-ietf-pce-questions-00 (work in progress), July 2013.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
Extensions for Stateful PCE", Extensions for Stateful PCE",
draft-ietf-pce-stateful-pce-04 (work in progress), draft-ietf-pce-stateful-pce-06 (work in progress),
May 2013. August 2013.
[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, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. March 2009.
9.2. Informative References 9.2. Informative References
[I-D.crabbe-pce-stateful-pce-mpls-te] [I-D.crabbe-pce-stateful-pce-mpls-te]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "Stateful Crabbe, E., Medved, J., Minei, I., and R. Varga, "Stateful
PCE extensions for MPLS-TE LSPs", PCE extensions for MPLS-TE LSPs",
draft-crabbe-pce-stateful-pce-mpls-te-01 (work in draft-crabbe-pce-stateful-pce-mpls-te-01 (work in
progress), May 2013. progress), May 2013.
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te] [I-D.ietf-ccamp-gmpls-general-constraints-ospf-te]
Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu, Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu,
"OSPF-TE Extensions for General Network Element "OSPF-TE Extensions for General Network Element
Constraints", Constraints",
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-04 draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05
(work in progress), July 2012. (work in progress), June 2013.
[I-D.ietf-ccamp-wson-signal-compatibility-ospf] [I-D.ietf-ccamp-wson-signal-compatibility-ospf]
Lee, Y. and G. Bernstein, "GMPLS OSPF Enhancement for Lee, Y. and G. Bernstein, "GMPLS OSPF Enhancement for
Signal and Network Element Compatibility for Wavelength Signal and Network Element Compatibility for Wavelength
Switched Optical Networks", Switched Optical Networks",
draft-ietf-ccamp-wson-signal-compatibility-ospf-11 (work draft-ietf-ccamp-wson-signal-compatibility-ospf-11 (work
in progress), February 2013. in progress), February 2013.
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-07 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-08 (work in
progress), October 2012. progress), July 2013.
[I-D.ogrcetal-ccamp-flexi-grid-fwk] [I-D.ogrcetal-ccamp-flexi-grid-fwk]
Dios, O., Casellas, R., Zhang, F., Fu, X., Ceccarelli, D., Dios, O., Casellas, R., Zhang, F., Fu, X., Ceccarelli, D.,
and I. Hussain, "Framework and Requirements for GMPLS and I. Hussain, "Framework and Requirements for GMPLS
based control of Flexi-grid DWDM networks", based control of Flexi-grid DWDM networks",
draft-ogrcetal-ccamp-flexi-grid-fwk-02 (work in progress), draft-ogrcetal-ccamp-flexi-grid-fwk-03 (work in progress),
February 2013. June 2013.
[I-D.sivabalan-pce-disco-stateful] [I-D.sivabalan-pce-disco-stateful]
Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
for Stateful PCE Discovery", for Stateful PCE Discovery",
draft-sivabalan-pce-disco-stateful-01 (work in progress), draft-sivabalan-pce-disco-stateful-02 (work in progress),
April 2013. July 2013.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global LSP Path Computation using Preemption", Global
Information Infrastructure Symposium, July 2007. Information Infrastructure Symposium, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear
programming algorithm for balancing the max-min fairness programming algorithm for balancing the max-min fairness
and throughput objectives in traffic engineering", pre- and throughput objectives in traffic engineering", pre-
print, 2011. print, 2011.
skipping to change at page 23, line 24 skipping to change at page 24, line 34
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS "Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, September 2009. Traffic Engineering", RFC 5623, September 2009.
[RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for [RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for
GMPLS and Path Computation Element (PCE) Control of GMPLS and Path Computation Element (PCE) Control of
Wavelength Switched Optical Networks (WSONs)", RFC 6163, Wavelength Switched Optical Networks (WSONs)", RFC 6163,
April 2011. April 2011.
Appendix A. Editorial notes and open issues
This section will be removed prior to publication.
The following open issues remain:
Use cases from draft-ietf-pce-stateful-pce To avoid loss of
information, the use cases will be removed from
[I-D.ietf-pce-stateful-pce] only after this document becomes a
working group document.
This document WILL NOT repeat terminology defined in other documents
or attempt to place any additional requirements on stateful PCE.
Authors' Addresses Authors' Addresses
Xian Zhang (editor) Xian Zhang (editor)
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei 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 P.R.China
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Ina Minei (editor) Ina Minei (editor)
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
 End of changes. 68 change blocks. 
187 lines changed or deleted 230 lines changed or added

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