draft-ietf-pce-stateful-pce-app-01.txt   draft-ietf-pce-stateful-pce-app-02.txt 
PCE 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: March 29, 2014 Juniper Networks, Inc. Expires: December 12, 2014 Google, Inc.
September 25, 2013 June 10, 2014
Applicability of Stateful Path Computation Element (PCE) Applicability of a Stateful Path Computation Element (PCE)
draft-ietf-pce-stateful-pce-app-01 draft-ietf-pce-stateful-pce-app-02
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 limitations
through a number of use cases. Path Computation Element Protocol through a number of use cases. PCE communication Protocol (PCEP)
(PCEP) extensions required for stateful PCE usage are covered in extensions required for stateful PCE usage are covered in separate
separate documents. 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 March 29, 2014. This Internet-Draft will expire on December 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Stateful PCE . . . . . . . . . . . . . . . . . . . 4 3. Overview of the Stateful PCE Protocol Extensions . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 6 4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 6
5. Application Scenarios . . . . . . . . . . . . . . . . . . . . 6 5. Application Scenarios . . . . . . . . . . . . . . . . . . . . 6
5.1. Optimization of LSP Placement . . . . . . . . . . . . . . 7 5.1. Optimization of LSP Placement . . . . . . . . . . . . . . 6
5.1.1. Throughput Maximization and Bin Packing . . . . . . . 8 5.1.1. Throughput Maximization and Bin Packing . . . . . . . 7
5.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . . 9 5.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 9
5.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . . 11 5.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 10
5.1.4. Predictability . . . . . . . . . . . . . . . . . . . . 12 5.1.4. Predictability . . . . . . . . . . . . . . . . . . . 11
5.2. Auto-bandwidth Adjustment . . . . . . . . . . . . . . . . 13 5.2. Auto-bandwidth Adjustment . . . . . . . . . . . . . . . . 13
5.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . . 13 5.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 13
5.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4.1. Protection . . . . . . . . . . . . . . . . . . . . . . 14 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) . . . . . . 17 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 . . . . . . . . . . . . . . . . . 18 5.7. Resource Defragmentation . . . . . . . . . . . . . . . . 18
5.8. Impairment-Aware Routing and Wavelength Assignment 5.8. Point-to-Multi-Point Applications . . . . . . . . . . . . 19
(IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.9. Impairment-Aware Routing and Wavelength Assignment (IA-
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 RWA) . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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) 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 LSPs (PCC) and a PCE, or between two PCEs, enabling computation of TE
in the context of MPLS networks. Extensions for support of GMPLS in LSPs. Extensions for support of GMPLS in PCEP are defined in
PCEP are defined in [I-D.ietf-pce-gmpls-pcep-extensions]. [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. A
Stateless PCEs have been shown to be useful in many scenarios, stateful PCE maintains two sets of information for use in path
including constraint-based path computation in multi-domain/ computation. The first is the Traffic Engineering Database (TED)
multi-layer networks. Compared to a stateless PCE, a stateful PCE which includes the topology and resource state in the network. This
has access to not only the network state, but also to the set of information can be obtained by a stateful PCE using the same
active paths and their reserved resources. Furthermore, a stateful mechanisms as a stateless PCE (see [RFC4655]). The second is the LSP
PCE might also retain information regarding LSPs under construction State Database (LSP-DB), in which a PCE stores attributes of all
in order to reduce churn and resource contention. This state allows active LSPs in the network, such as their paths through the network,
the PCE to compute constrained paths while considering individual bandwidth/resource usage, switching types and LSP constraints. This
LSPs and their interactions. However, this requires reliable state state information allows the PCE to compute constrained paths while
synchronization mechanisms between the PCE and the network, PCE and considering individual LSPs and their inter-dependency. However,
PCC, and between cooperating PCEs, with potentially significant this requires reliable state synchronization mechanisms between the
control plane overhead and maintenance of a large amount of state PCE and the network, between the PCE and the PCCs, and between
data, as explained in [RFC4655]. cooperating PCEs, with potentially significant control plane overhead
and maintenance of a large amount of state 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,
skipping to change at page 4, line 12 skipping to change at page 4, line 5
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, results in destination pair which, when removed from the network, results in
a 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 the Stateful PCE Protocol Extensions
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. and distinguishes between an active and a passive stateful PCE. A
passive stateful PCE uses LSP state information to optimize path
[I-D.ietf-pce-stateful-pce] distinguishes between an active and a computations but does not actively update LSP state. In contrast, an
passive stateful PCE. A passive stateful PCE uses LSP state active stateful PCE may issue recommendations to the network. For
information learned from PCCs to optimize path computations but does example, an active stateful PCE may update LSP parameters in those
not actively update LSP state. In contrast, an active stateful PCE PCCs that delegated control over their LSPs to the 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 Several new functions are added in PCEP to support both active and
passive stateful PCEs. They are described in passive stateful PCEs. They are described in
[I-D.ietf-pce-stateful-pce]. A function can be initiated either from [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 a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). The new
functions are: functions are:
Capability negotiation (E-C,C-E): both the PCC and the PCE must Stateful Capability negotiation (E-C,C-E): both the PCC and the PCE
announce during PCEP session establishment that they support PCEP must announce during PCEP session establishment that they support
stateful PCE extensions. stateful PCE PCEP extensions.
LSP state synchronization (C-E): after the session between the PCC LSP state synchronization (C-E): after the session between a PCC and
and a stateful PCE is initialized, the PCE must learn the state of a stateful PCE is initialized, the PCE can perform path
a PCC's LSPs before it can perform path computations or update LSP computation and update attributes in a PCC. However, if the goal
attributes in a PCC. of the PCE is to provide accurate path information based on the
most up-to-date state of the network, the PCE SHOULD wait until it
learns the state of the PCC's LSP states before doing so.
LSP update request (E-C): A PCE requests modification of attributes LSP update request (E-C): A PCE requests the modification of one or
on a PCC's LSP. more attributes (e.g., route) 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.
skipping to change at page 5, line 43 skipping to change at page 5, line 31
address is configured on the PCC. address is configured on the PCC.
Multiple stateful PCEs can co-exist in the same network. These PCEs Multiple stateful PCEs can co-exist 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. [I-D.ietf-pce-stateful-pce] describes how LSPs can be re- time. [I-D.ietf-pce-stateful-pce] describes how LSPs can be re-
delegated between PCEs, and the procedures on a PCE failure. delegated between PCEs, and the procedures on a PCE failure.
[I-D.ietf-pce-questions] discusses various approaches for [I-D.ietf-pce-questions] 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 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
A stateful PCE maintains two sets of information for use in path The population of the LSP-DB using information received from PCCs is
computation. The first is the Traffic Engineering Database (TED) supported by the stateful PCE extensions defined in
which includes the topology and resource state in the network. This [I-D.ietf-pce-stateful-pce] , i.e., via LSP state report messages.
information can be obtained by a stateful PCE using the same Population of the LSP database via other means is not precluded.
mechanisms as a stateless PCE (see [RFC4655]). The second is the LSP
State Database (LSP-DB), in which a PCE stores attributes of all
active LSPs in the network, such as their paths through the network,
bandwidth/resource usage, switching types and LSP constraints. The
stateful PCE extensions defined in [I-D.ietf-pce-stateful-pce]
support population of this database using information received from
PCCs via LSP state report messages. Population of the LSP database
via other means is not precluded.
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, it is worth noting that the PCE view lags behind
the true state of the network, because the updates must reach the PCE 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 from the network. Thus, the use of stateful PCE reduces but cannot
eliminate the possibility of crankbacks, nor can it guarantee optimal eliminate the possibility of crankbacks, nor can it guarantee optimal
computations all the time. [I-D.ietf-pce-questions] discusses these computations all the time. [I-D.ietf-pce-questions] discusses these
limitations and potential ways to alleviate them. limitations and potential ways to alleviate them.
In case of multiple PCEs with different capabilities, co-existing in
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,
by a unique identifier instead of providing detailed information
(e.g., route, bandwidth etc.) associated with it, when these PCEs
cooperate on path computation, such as for loading 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. information resynchronized after a restart.
[I-D.ietf-pce-stateful-pce] includes support of a synchronization [I-D.ietf-pce-stateful-pce] defines a synchronization function and
function, allowing the PCC to synchronize its LSP state with the PCE. procedure, allowing a PCC to synchronize its LSP state with the PCE.
This can be applied equally to a Label Edge Router (LER) client or This can be applied equally to a network nodes or another PCE,
another PCE, allowing for support of multiple ways of re-acquiring allowing multiple ways of re-acquiring the LSP database on a restart.
the LSP database on a restart. For example, the state can be
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. A hybrid approach where the without further overhead in the network. A hybrid approach where the
bulk of the state is recovered locally, and a small amount of state bulk of the state is recovered locally, and a small amount of state
is reacquired from the network is also possible. Note that locally 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. Depending on the resynchronization mechanism used, there may date. Depending on the resynchronization mechanism used, there may
be additional load on the PCE, and there may be a delay in reaching be an additional load on the PCE, and there may be a delay in
the synchronized state, which may negatively affect survivabiliy. reaching the synchronized state, which may negatively affect
Different resynchronization methods are suited for different survivability. Different resynchronization methods are suited for
deployments and objectives. 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
skipping to change at page 7, line 19 skipping to change at page 6, line 49
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 setup, 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 |
+-----+ +-----+ +-----+ +-----+
/ \ +-----+ / / \ +-----+ /
skipping to change at page 8, line 24 skipping to change at page 8, line 8
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 |
+------+--------+----------+ +------+--------+----------+
| 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 which 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 which 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
5.1.2. Deadlock 5.1.2. Deadlock
This section discusses a use case of cross-LSP impact under degraded This section discusses a use case of cross-LSP impact under degraded
operation. Most existing RSVP-TE implementations will not tear down operation. Most existing RSVP-TE implementations will not tear down
established LSPs in the event of the failure of the bandwidth established LSPs in the event of the failure of the bandwidth
increase procedure detailed in [RFC3209]. This behavior is directly increase procedure detailed in [RFC3209]. This behavior is directly
skipping to change at page 10, line 8 skipping to change at page 9, line 43
on current traffic) and b) there is currently no efficient commonly on current traffic) and b) there is currently no efficient commonly
available northbound interface for dynamic configuration of per LSP available northbound interface for dynamic configuration of per LSP
ingress admission control. 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, 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, thus impacting the operation of the in-profile LSPs,
profile LSPs, even when there is unused network capacity elsewhere in even when there is unused network capacity elsewhere in the network.
the network. Furthermore, this behavior will cause information loss Furthermore, this behavior will cause information loss in the TED
in the TED with regards to the actual available bandwidth on the with regards to the actual available bandwidth on the links used by
links used by the out-of-profile LSPs, as the reservations on the the out-of-profile LSPs, as the reservations on the links no longer
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.
skipping to change at page 10, line 35 skipping to change at page 10, line 21
The problem could be easily ameliorated by global visibility of LSP The problem could be easily ameliorated by global visibility of LSP
state coupled with PCC-external demand measurements and placement of state coupled with PCC-external demand measurements and placement of
two LSPs on disjoint links. Note that while the demand of 20 for LSP two LSPs on disjoint links. Note that while the demand of 20 for LSP
1 could never be satisfied in the given topology, what could be 1 could never be satisfied in the given topology, what could be
achieved would be isolation from the ill-effects of the achieved would be isolation from the ill-effects of the
(unsatisfiable) increased demand. (unsatisfiable) increased demand.
+------+--------+----------+ +------+--------+----------+
| 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
5.1.3. Minimum Perturbation 5.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 global LSP state and
the lack of control over event ordering across PCE sessions, 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
skipping to change at page 11, line 31 skipping to change at page 11, line 10
case an unimportant (high LSP priority value) LSP (LSP1) is first set case an unimportant (high LSP priority value) LSP (LSP1) is first set
up along the shortest path. At time 2, which is assumed to be 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 evaluating both requests A stateful PCE can help in this scenario by computing both routes at
at the same time (due to their proximity in time). This will ensure the same time. The advantages of using a stateful PCE over
placement of the more important LSP along the shortest path, avoiding exploiting a stateless PCE via Global Concurrent Optimization(GCO)
the preemption of the lower priority LSP. Similarly, when a new are three folds. First is the ability to accommodate concurrent path
higher priority LSP which requires preemption of existing lower computation from different PCCs. Second is the reduction of control
plane overhead since the stateful PCE has the route information of
the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to
further optimize the placement of LSPs. This will ensure placement
of the more important LSP along the shortest path, avoiding the setup
and subsequent preemption of the lower priority LSP. Similarly, when
a new higher priority LSP which requires preemption of existing lower
priority LSP(s), a stateful PCE can determine the minimum number of priority LSP(s), a stateful PCE can determine the minimum number of
lower priority LSP(s) to reroute using the make-before-break (MBB) lower priority LSP(s) to reroute using the make-before-break (MBB)
mechanism without disrupting any service and then set up the higher mechanism without disrupting any service and then set up the higher
priority LSP. 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
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 event
ordering and predictability of LSP routing. 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. 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. In most implementations available today, the head-
by monitoring the actual bandwidth usage, triggering a recomputation end node performs this function by monitoring the actual bandwidth
and resignaling when a threshold is reached. This operation is usage, triggering a recomputation and resignaling when a threshold is
referred as auto-bandwidth adjustment. The head-end node either reached. This operation is referred as auto-bandwidth adjustment.
recomputes the path locally, or it requests a recomputation from a The head-end node either recomputes the path locally, or it requests
PCE by sending a Path Computation Request (PCReq) message. In the a recomputation from a PCE by sending a PCReq message. In the latter
latter case, the PCE computes a new path and provides the new route case, the PCE computes a new path and provides the new route
suggestion. Upon receiving the reply from the PCE, the PCC re- suggestion. Upon receiving the reply from the PCE, the PCC re-
signals the LSP in Shared-Explicit (SE) mode along the newly computed signals the LSP in Shared-Explicit (SE) mode along the newly computed
path. If a passive stateful PCE is used, only the new bandwidth path. With a stateless PCE, the head-end node needs to provide the
information is needed to trigger a path re-computation since the LSP current used bandwidth and the route information via path computation
information is already known to the PCE. Note that in this scenario, request messages. Note that in this scenario, the head-end node is
the head-end node is the one that drives the LSP resizing based on the one that drives the LSP resizing based on local information, and
local information, and that the difference between using a stateless that the difference between using a stateless and a passive stateful
and a passive stateful PCE is in the level of optimization of the LSP PCE is in the level of optimization of the LSP placement as discussed
placement as discussed in the previous section. 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 14, line 38 skipping to change at page 14, line 24
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.
5.4.1. Protection 5.4.1. Protection
For protection purposes, a PCC may send a request to a PCE for If a PCC can specify in a request whether the computation is for a
computing a set of paths for a given LSP. Alternatively, the PCC can working or for protection, and a PCC can report the resource by a
send multiple requests to the PCE, asking for working and backup LSPs working or protection path, then the following text applies. A PCC
separately. Either way, the resources bound to backup paths can be can send multiple requests to the PCE, asking for two LSPs and use
shared by different LSPs to improve the overall network efficiency, them as working and backup paths separately. Either way, the
such as m:n protection or pre-configured shared mesh recovery resources bound to backup paths can be shared by different LSPs to
techniques as specified in [RFC4427]. If resource sharing is improve the overall network efficiency, such as m:n protection or
supported for LSP protection, the information relating to existing pre-configured shared mesh recovery techniques as specified in
LSPs is required to avoid allocation of shared protection resources [RFC4427]. If resource sharing is supported for LSP protection, the
to two LSPs that might fail together and cause protection contention information relating to existing LSPs is required to avoid allocation
issues. A stateless PCE can accommodate this use case by having the of shared protection resources to two LSPs that might fail together
PCC pass this information as a constraint in the path computation and cause protection contention issues. A stateless PCE can
request. A passive stateful PCE can more easily accommodate this accommodate this use case by having the PCC pass this information as
need using the information stored in its LSP-DB. Furthermore, an a constraint in the path computation request. A passive stateful PCE
active stateful PCE can help with (re)-optimizization of protection can more easily accommodate this need using the information stored in
resource sharing as well as LSP maintenance operation with fewer its LSP-DB. Furthermore, an active stateful PCE can help with (re)-
impact on protection resources. optimizization of protection resource sharing as well as LSP
maintenance operation with fewer 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, for a for a working and backup path pair to be computed for LSP2 from B to
request from B to E. If the PCE decides LSP2_working follows B->A->E, E. If the PCE decides LSP2_working follows B->A->E, then the backup
then the backup path LSP2_backup should not use the same protection path LSP2_backup should not share the same protection resource with
resource with LSP1 since LSP2 shares part of its resource LSP1 since LSP2 shares part of its resource (specifically A->E) with
(specifically A->E) with LSP1 (i.e., these two LSPs are in the same LSP1 (i.e., these two LSPs are in the same shared risk group). There
shared risk group). Alternatively, there is no such constraint if is no such constraint if B->C->D->E is chosen for LSP2_working.
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 which 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.
On the other hand, a stateful PCE can get the LSPs information by Alternatively, a stateless PCE may able to compute carry out Shared
itself and can achieve the goal of finding SRLG-diversified Risk Link Group (SRLG)-diversified paths if TED is extended so that
protection paths for both LSPs. This is made possible by comparing it includes the SRLG information that are protected by a given backup
the LSP resource usage exploiting the LSP DB accessible by the resource, but at the expense of a high complexity in routing. On the
stateful PCE. other hand, a stateful PCE can get the LSPs information by itself
given that the LSP identifier(s) and can achieve the goal of finding
SRLG-diversified protection paths for both LSPs. This is made
possible by comparing the LSP resource usage exploiting the LSP-DB
accessible by the stateful PCE.
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 a fiber cut, multiple LSPs may
at the same time. Thus, the source nodes of the affected LSPs will fail at the same time. Thus, the source nodes of the affected LSPs
be informed of the failure by the nodes detecting the failure. These will be informed of the failure by the nodes detecting the failure.
source nodes will send requests to a PCE for rerouting. In order to These source nodes will send requests to a PCE for rerouting. In
reuse the resource taken by an existing LSP, the source node can send order to reuse the resource taken by an existing LSP, the source node
a PCReq message including the XRO object with F bit set, together can send a PCReq message including the Exclude Route Object (XRO)
with RRO object, as specified in [RFC5521]. with Fail (F) bit set, together with the RRO object containing the
current route information, 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
passive stateful PCE is used to fulfill this task, it can re-compute passive stateful PCE is used to fulfill this task, the procedure can
the affected LSPs concurrently while reusing part of the existing be simplified. The PCCs reporting the failures can include LSP
LSPs resources when it is informed of the failed link identifier identifiers instead of detailed information and the PCE can find
provided by the first request. This is made possible since the relevant LSP information by inspecting the LSP-DB. Moreover, the PCE
passive stateful PCE can check what other LSPs are affected by the can re-compute the affected LSPs concurrently while reusing part of
failed link and their route information by inspecting its LSP-DB. As the existing LSPs resources when it is informed of the failed link
a result, a better performance, such as better resource usage, identifier provided by the first request. This is made possible
minimal probability of blocking upcoming new rerouting requests sent since the passive stateful PCE can check what other LSPs are affected
as a result of the link failure, can be achieved. by the failed link and their route information by inspecting its LSP-
DB. As a result, a better performance can be achieved, such as
In order to further reduce the amount of LSP rerouting messages flow better resource usage or minimal probability of blocking upcoming new
in the network, the notification can be performed at the node(s) rerouting requests sent as a result of the link failure.
which detect the link failure. For example, suppose there are two
LSPs in the network as shown in Figure 3: (i) LSP1: A->E->D->C; (ii)
LSP2: B->E->D. They traverse the failed link between E-D. When D
detects the failure, it can send a notification message to a stateful
PCE. Note that the stateful PCE stores the path information of the
LSPs that are affected by the link failure, so it does not need to
acquire this information from D. Moreover, it can make use of the
bandwidth resources occupied by the affected LSPs when performing
path recalculation. After D receives the new paths from the PCE, it
notifies the ingress nodes of the LSPs, i.e., A and B, and specifies
the new paths which should be used as the rerouting paths. To
support this, it would require extensions to the existing signaling
protocols.
Alternatively, if the target is to avoid resource contention within If the target is to avoid resource contention within the time-window
the time-window of high LSP requests, a stateful PCE can retain the of high number of LSP rerouting requests, a stateful PCE can retain
under-construction LSP resource usage information for a given time the under-construction LSP resource usage information for a given
and exclude it from being used for forthcoming LSPs request. In this time and exclude it from being used for forthcoming LSPs request. In
way, it can ensure that the resource will not be double-booked and this way, it can ensure that the resource will not be double-booked
thus the issue of resource contention and computation crank-backs can and thus the issue of resource contention and computation crank-backs
be resolved. can be alleviated.
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, the PCC can specify, as constraints to the path
times, e.g. in the case of a restoration), the PCC can specify, as computation a set of SRLGs using the Exclude Route Object [RFC5521].
constraints to the path computation a set of Shared Risk Link Groups However, for the latter to be effective, it is needed that the entity
(SRLGs) using the Exclude Route Object [RFC5521]. However, for the that requests the route to the PCE maintains updated SRLG information
latter to be effective, it is needed that the entity that requests of all the LSPs to which it must maintain the disjointness. A
the route to the PCE maintains updated SRLG information of all the stateless PCE can compute an SRLG-disjoint path by inspecting the TED
LSPs to which it must maintain the disjointness. A stateless PCE can and precluding the links with the same SRLG values specified in the
compute an SRLG-disjoint path by inspecting the TED and precluding PCReq message sent by a PCC.
the links with the same SRLG values specified in the 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 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. Similarly, a passive stateful PCE can also accommodate identifiers. Similarly, a passive stateful PCE can also accommodate
disjointness using other contraints, such as link, node or path disjointness using other constraints, such as link, node or path
segment etc. 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.
skipping to change at page 18, line 9 skipping to change at page 17, line 44
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 passive stateful PCE, given the LSP state information in
database, the process of dynamic optimization of network resources the LSP database, the process of dynamic optimization of network
can be automated without requiring the PCC to supply LSP state resources can be simplified without requiring the PCC to supply
information or to trigger the request. Moreover, since a stateful detailed LSP state information. Moreover, an active stateful PCE can
PCE can maintain information for all LSPs that are in the process of even make the process automated by triggering the request since a
being set up and since it may have the ability to control timing and stateful PCE can maintain information for all LSPs that are in the
sequence of LSP setup/deletion, the optimization procedures can be process of being set up and it may have the ability to control timing
performed more intelligently and effectively. A stateful PCE can and sequence of LSP setup/deletion, the optimization procedures can
be performed more intelligently and effectively. A stateful PCE can
also determine which LSP should be re-optimized based on network also determine which LSP should be re-optimized based on network
events. For example, when a LSP is torn down, its resources are events. For example, when a LSP is torn down, its resources are
freed. This can trigger the stateful PCE to automatically determine freed. This can trigger the stateful PCE to automatically determine
which LSP should be reoptimized so that the recently freed resources which LSP should be reoptimized so that the recently freed resources
may be allocated to it. may be allocated to it.
A special case of LSP re-optimization is Global Concurrent A special case of LSP re-optimization is GCO [RFC5557]. Global
Optimization (GCO) [RFC5557]. Global control of LSP operation control of LSP operation sequence in [RFC5557] is predicated on the
sequence in [RFC5557] is predicated on the use of what is effectively use of what is effectively a stateful (or semi-stateful) NMS. The
a stateful (or semi-stateful) NMS. The NMS can be either not local NMS can be either not local to the network nodes, in which case
to the network nodes, in which case another northbound interface is another northbound interface is required for LSP attribute changes,
required for LSP attribute changes, or local/collocated, in which or local/collocated, in which case there are significant issues with
case there are significant issues with efficiency in resource usage. efficiency in resource usage. A stateful PCE adds a few features
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 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 If LSPs are dynamically allocated and released over time, the
released over time, the resource becomes fragmented. The overall resource becomes fragmented. In networks with link bundle, the
available resource on a (bundle) link might be sufficient for a new overall available resource on a (bundle) link might be sufficient for
LSP request, but if the available resource is not continuous, the a new LSP request, but if the available resource is not continuous,
request is rejected. In order to perform the defragmentation the request is rejected. In order to perform the defragmentation
procedure, stateful PCEs can 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 Another case of particular interest is the optical spectrum
the frequency defragmentation in flexible grid. In Flexible grid defragmentation in flexible grid networks. In Flexible grid networks
networks [I-D.ogrcetal-ccamp-flexi-grid-fwk], LSPs with different [I-D.ietf-ccamp-flexi-grid-fwk], LSPs with different optical spectrum
slot widths (such as 12.5G, 25G etc.) can co-exist so as to sizes (such as 12.5GHz, 25GHz etc.) can co-exist so as to accommodate
accommodate the services with different bandwidth requests. the services with different bandwidth requests. Therefore, even if
Therefore, even if the overall spectrum can meet the service request, the overall spectrum size can meet the service request, it may not be
it may not be usable if it is not contiguous. Thus, with the help of usable if the available spectrum resource is not contiguous, but
rather fragmented into smaller pieces. Thus, with the help of
existing LSP state information, a stateful PCE can make the resource existing LSP state information, a stateful PCE can make the resource
grouped together to be usable. Moreover, a 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. Point-to-Multi-Point Applications
In WSONs [RFC6163], a wavelength-switched LSP traverses one or more PCE has been identified as an appropriate technology for the
fiber links. The bit rates of the client signals carried by the determination of the paths of point-to-multipoint (P2MP) TE LSPs
wavelength LSPs may be the same or different. Hence, a fiber link [RFC5671]. The application scenarios and use-cases described in
may transmit a number of wavelength LSPs with equal or mixed bit rate Section 5.1, Section 5.4 and Section 5.6 are also applicable to P2MP
signals. For example, a fiber link may multiplex the wavelengths TE LSPs.
with only 10G signals, mixed 10G and 40G signals, or mixed 40G and
100G signals.
IA-RWA in WSONs refers to the RWA process (i.e., lightpath In addition to these, the stateful nature of a PCE simplifies the
computation) that takes into account the optical layer/transmission information conveyed in PCEP messages since it is possible to refer
imperfections by considering as additional (i.e., physical layer) to the LSPs via an identifier. For P2MP, this is an added advantage,
constraints. To be more specific, linear and non-linear effects where the size of the PCEP message is much larger. In case of
associated with the optical network elements should be incorporated stateless PCEs, modification of a P2MP tree requires encoding of all
into the route and wavelength assignment procedure. For example, the leaves along with the paths in PCReq message. But using a stateful
physical imperfection can result in the interference of two adjacent PCE with P2MP capability, the PCEP message can be used to convey only
the modifications (the other information can be retrieved from the
identifier via the LSP-DB).
5.9. Impairment-Aware Routing and Wavelength Assignment (IA-RWA)
In Wavelength Switched Optical Networks (WSONs) [RFC6163], a
wavelength-switched LSP traverses one or more fiber links. The bit
rates of the client signals carried by the wavelength LSPs may be the
same or different. Hence, a fiber link may transmit a number of
wavelength LSPs with equal or mixed bit rate signals. For example, a
fiber link may multiplex the wavelengths with only 10Gb/s signals,
mixed 10Gb/s and 40Gb/s signals, or mixed 40Gb/s and 100Gb/s signals.
IA-RWA in WSONs refers to the process (i.e., lightpath computation)
that takes into account the optical layer/transmission imperfections
by considering as additional (i.e., physical layer) constraints. To
be more specific, linear and non-linear effects associated with the
optical network elements should be incorporated into the route and
wavelength assignment procedure. For example, the physical
imperfection can result in the interference of two adjacent
lightpaths. Thus, a guard band should be reserved between them to lightpaths. Thus, a guard band should be reserved between them to
alleviate these effects. The width of the guard band between two alleviate these effects. The width of the guard band between two
adjacent wavelengths depends on their characteristics, such as adjacent wavelengths depends on their characteristics, such as
modulation formats and bit rates. Two adjacent wavelengths with modulation formats and bit rates. Two adjacent wavelengths with
different characteristics (e.g., different bit rates) may need a different characteristics (e.g., different bit rates) may need a
wider guard band and with same characteristics may need a narrower wider guard band and with same characteristics may need a narrower
guard band. For example, 50GHz spacing may be acceptable for two guard band. For example, 50GHz spacing may be acceptable for two
adjacent wavelengths with 40G signals. But for two adjacent adjacent wavelengths with 40G signals. But for two adjacent
wavelengths with different bit rates (e.g., 10G and 40G), a larger wavelengths with different bit rates (e.g., 10G and 40G), a larger
spacing such as 300GHz spacing may be needed. Hence, the spacing such as 300GHz spacing may be needed. Hence, the
skipping to change at page 22, line 20 skipping to change at page 22, line 23
We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and
Ravi Torvi 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] [I-D.ietf-pce-questions]
Farrel, A. and D. King, "Unanswered Questions in the Path Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", Computation Element Architecture", draft-ietf-pce-
draft-ietf-pce-questions-00 (work in progress), July 2013. questions-06 (work in progress), June 2014.
[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-
draft-ietf-pce-stateful-pce-06 (work in progress), pce-08 (work in progress), February 2014.
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
March 2009. 2009.
9.2. Informative References 9.2. Informative References
[I-D.crabbe-pce-stateful-pce-mpls-te] [I-D.ietf-ccamp-flexi-grid-fwk]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "Stateful Dios, O., Casellas, R., Zhang, F., Fu, X., Ceccarelli, D.,
PCE extensions for MPLS-TE LSPs", and I. Hussain, "Framework and Requirements for GMPLS
draft-crabbe-pce-stateful-pce-mpls-te-01 (work in based control of Flexi-grid DWDM networks", draft-ietf-
progress), May 2013. ccamp-flexi-grid-fwk-01 (work in progress), February 2014.
[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-
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05 ospf-te-08 (work in progress), May 2014.
(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-
draft-ietf-ccamp-wson-signal-compatibility-ospf-11 (work compatibility-ospf-15 (work in progress), May 2014.
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-08 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-09 (work in
progress), July 2013. progress), February 2014.
[I-D.ogrcetal-ccamp-flexi-grid-fwk]
Dios, O., Casellas, R., Zhang, F., Fu, X., Ceccarelli, D.,
and I. Hussain, "Framework and Requirements for GMPLS
based control of Flexi-grid DWDM networks",
draft-ogrcetal-ccamp-flexi-grid-fwk-03 (work in progress),
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-
draft-sivabalan-pce-disco-stateful-02 (work in progress), stateful-03 (work in progress), January 2014.
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
Information Infrastructure Symposium, July 2007. 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.
[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network
Recovery: Protection and Restoration of Optical, SONET- Recovery: Protection and Restoration of Optical, SONET-
SDH, IP, and MPLS", The Morgan Kaufmann Series in SDH, IP, and MPLS", The Morgan Kaufmann Series in
Networking, June 2004. Networking, June 2004.
[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, December 2001. Tunnels", RFC 3209, December 2001.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006. Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657, Communication Protocol Generic Requirements", RFC 4657,
September 2006. September 2006.
[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, July
July 2008. 2008.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
December 2008.
[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, April 2009. Route Exclusions", RFC 5521, April 2009.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path [RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, July 2009. Concurrent Optimization", RFC 5557, July 2009.
[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.
[RFC5671] Yasukawa, S. and A. Farrel, "Applicability of the Path
Computation Element (PCE) to Point-to-Multipoint (P2MP)
MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
October 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.
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
skipping to change at page 25, line 4 skipping to change at page 24, line 37
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 P.R.China
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Ina Minei (editor) Ina Minei (editor)
Juniper Networks, Inc. Google, Inc.
1194 N. Mathilda Ave. 1600 Amphitheatre Parkway
Sunnyvale, CA 94089 Mountain View, CA 94043
US US
Email: ina@juniper.net Email: inaminei@google.com
 End of changes. 70 change blocks. 
340 lines changed or deleted 346 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/