Internet DRAFT - draft-zhang-pce-stateful-pce-app
draft-zhang-pce-stateful-pce-app
Network Working Group X. Zhang, Ed.
Internet-Draft Huawei Technologies
Intended status: Informational I. Minei, Ed.
Expires: November 25, 2013 Juniper Networks, Inc.
May 24, 2013
Applicability of Stateful Path Computation Element (PCE)
draft-zhang-pce-stateful-pce-app-04
Abstract
A stateful Path Computation Element (PCE) maintains information about
Label Switched Path (LSP) characteristics and resource usage within a
network in order to provide traffic engineering calculations for its
associated Path Computation Clients (PCCs). This document describes
general considerations for a stateful PCE deployment and examines its
applicability and benefits through a number of use cases. Path
Computation Element Protocol (PCEP) extensions required for stateful
PCE usage are covered in separate documents.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 25, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Zhang & Minei Expires November 25, 2013 [Page 1]
Internet-Draft Applicability for Stateful PCE May 2013
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of stateful PCE . . . . . . . . . . . . . . . . . . . 4
4. Deployment considerations . . . . . . . . . . . . . . . . . . 5
4.1. Multi-PCE deployments . . . . . . . . . . . . . . . . . . 5
4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 5
4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 5
5. Application scenarios . . . . . . . . . . . . . . . . . . . . 6
5.1. Optimization of LSP placement . . . . . . . . . . . . . . 6
5.1.1. Throughput Maximization and Bin Packing . . . . . . . 7
5.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . . 10
5.1.4. Predictability . . . . . . . . . . . . . . . . . . . . 11
5.2. Auto-bandwidth Adjustment . . . . . . . . . . . . . . . . 12
5.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . . 13
5.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.1. Protection . . . . . . . . . . . . . . . . . . . . . . 13
5.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 15
5.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . . 16
5.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 16
5.6. LSP Re-optimization . . . . . . . . . . . . . . . . . . . 17
5.7. Resource Defragmentation . . . . . . . . . . . . . . . . . 17
5.8. Impairment-Aware Routing and Wavelength Assignment
(IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Editorial notes and open issues . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Zhang & Minei Expires November 25, 2013 [Page 2]
Internet-Draft Applicability for Stateful PCE May 2013
1. Introduction
[RFC4655] defines the architecture for a Path Computation Element
(PCE)-based model for the computation of Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
Label Switched Paths (TE LSPs). To perform such a constrained
computation, a PCE stores the network topology (i.e., TE links and
nodes) and resource information (i.e., TE attributes) in its TE
Database (TED). [RFC5440] describes the Path Computation Element
Protocol (PCEP). PCEP defines the communication between a Path
Computation Client (PCC) and a Path Control Element (PCE), or between
two PCEs, enabling computation of Multiprotocol Label Switching
(MPLS) for Traffic Engineering Label Switched Path (TE LSP)
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.
Stateless PCEs have been shown to be useful in many scenarios,
including constraint-based path computation in multi-domain/
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
active paths and their reserved resources. Furthermore, a stateful
PCE might also retain information regarding LSPs under construction
in order to reduce churn and resource contention. This state allows
the PCE to compute constrained paths while considering individual
LSPs and their interactions. Note that this requires reliable state
synchronization mechanisms between the PCE and the network, PCE and
PCC, and between cooperating PCEs, 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
various problems for MPLS-TE and GMPLS networks, and the benefits it
brings to such deployments. Note that alternative solutions relying
on stateless PCEs may also be possible for some of these use cases,
and will be mentioned for completeness where appropriate.
2. Terminology
This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer.
This document uses the following terms defined in
[I-D.ietf-pce-stateful-pce]: Passive Stateful PCE, Active Stateful
PCE, Delegation, Revocation, Delegation Timeout Interval, LSP State
Report, LSP Update Request, LSP State Database.
Zhang & Minei Expires November 25, 2013 [Page 3]
Internet-Draft Applicability for Stateful PCE May 2013
This document defines the following term:
Minimum Cut Set: the minimum set of links for a specific source
destination pair which, when removed from the network, result in a
specific source being completely isolated from specific
destination. The summed capacity of these links is equivalent to
the maximum capacity from the source to the destination by the
max-flow min-cut theorem.
3. Overview of stateful PCE
This section is included for the convenience of the reader, please
refer to the referenced documents for details of the operation.
[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
compliance with [RFC4657]. It includes mechanisms to effect tunnel
state synchronization between PCCs and PCEs, delegation of control
over tunnels to PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions.
[I-D.ietf-pce-stateful-pce] applies equally to MPLS-TE and GMPLS
LSPs.
Several new functions were added in PCEP to support stateful PCEs and
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
announce during PCEP session establishment that they support PCEP
Stateful PCE extensions.
LSP state synchronization (C-E): after the session between the PCC
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
attributes in a PCC.
LSP Update Request (E-C): A PCE requests modification of attributes
on a PCC's LSP.
LSP State Report (C-E): a PCC sends an LSP State Report to a PCE
whenever the state of an LSP changes.
Zhang & Minei Expires November 25, 2013 [Page 4]
Internet-Draft Applicability for Stateful PCE May 2013
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
authoritative source of the LSP's attributes as long as the
delegation is in effect; the PCC may withdraw the delegation or
the PCE may give up the delegation.
[I-D.sivabalan-pce-disco-stateful] defines the extensions needed to
support autodiscovery of stateful PCEs when using the IGPs for PCE
discovery.
4. Deployment considerations
This section discusses generic issues with Stateful PCE deployments,
and how specific protocol mechanisms can be used to address them.
4.1. Multi-PCE deployments
Stateless and stateful PCEs can co-exist in the same network and be
in charge of path computation of different types. To solve the
problem of distinguishing between the two types of PCEs, either
discovery or configuration may be used. The capability negotiation
in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE
address is configured on the PCC.
4.2. LSP State Synchronization
A stateful PCE maintains two sets of information for use in path
computation. The first is the Traffic Engineering Database (TED)
which includes the topology and resource state in the network. This
information can be obtained by a stateful PCE using the same
mechanisms as a stateless PCE (see [RFC4655]). The second is the LSP
State Database (LSP-DB), in which a PCE stores attributes of all
active LSPs in the network, such as their paths through the network,
bandwidth/resource usage, switching types and LSP constraints. The
stateful PCE extensions defined in [I-D.ietf-pce-stateful-pce]
support population of this database using information received from
the network nodes via LSP State Report messages. Population of the
LSP database via other means is not precluded.
4.3. PCE Survivability
For a stateful PCE, an important issue is to get the LSP state
information resynchronized after a restart.
[I-D.ietf-pce-stateful-pce] includes support of a synchronization
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
another PCE, allowing for support of multiple ways of re-acquiring
Zhang & Minei Expires November 25, 2013 [Page 5]
Internet-Draft Applicability for Stateful PCE May 2013
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
has the means to retrieve its database in a different way (for
example from a backup copy stored locally), the state can be restored
without further overhead in the network. Note that locally
recovering the state would still require some degree of
resynchronization to ensure that the recovered state is indeed up-to-
date.
5. Application scenarios
In the following sections, several use cases are described,
showcasing scenarios that benefit from the deployment of a stateful
PCE.
5.1. Optimization of LSP placement
The following use cases demonstrate a need for visibility into global
inter-PCC LSP state in PCE path computations, and for a PCE control
of sequence and timing in altering LSP path characteristics within
and across PCEP sessions. Reference topologies for the use cases
described later in this section are shown in Figures 1 and 2.
Some of the use cases below are focused on MPLS-TE deployments, but
may also apply to GMPLS. Unless otherwise cited, use cases assume
that all LSPs listed exist at the same LSP priority.
The main benefit in the cases below comes from moving away from an
asynchronous PCC-driven mode of operation to a model that allows for
central control over LSP computations and setup, and focuses
specifically on the active stateful PCE model of operation.
+-----+
| A |
+-----+
\
+-----+ +-----+
| C |----------------------| E |
+-----+ +-----+
/ \ +-----+ /
+-----+ +-----| D |-----+
| B | +-----+
+-----+
Figure 1: Reference topology 1
Zhang & Minei Expires November 25, 2013 [Page 6]
Internet-Draft Applicability for Stateful PCE May 2013
+-----+ +-----+ +-----+
| A | | B | | C |
+--+--+ +--+--+ +--+--+
| | |
| | |
+--+--+ +--+--+ +--+--+
| E +--------+ F +--------+ G |
+-----+ +-----+ +-----+
Figure 2: Reference topology 2
5.1.1. Throughput Maximization and Bin Packing
Because LSP attribute changes in [RFC5440] are driven by PCReq
messages under control of a PCC's local timers, the sequence of RSVP
reservation arrivals occurring in the network will be randomized.
This, coupled with a lack of global LSP state visibility on the part
of a stateless PCE may result in suboptimal throughput in a given
network topology, as will be shown in the example below.
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
visibility and synchronized control across PCC's. In this scenario,
the decision must be made as to whether to route any portion of the
E-G demand, as any demand routed for this source and destination will
decrease system throughput.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-E | 1 | 10 |
| B-F | 1 | 10 |
| C-G | 1 | 10 |
| E-F | 1 | 10 |
| F-G | 1 | 10 |
+------+--------+----------+
Table 1: Link parameters for Throughput use case
Zhang & Minei Expires November 25, 2013 [Page 7]
Internet-Draft Applicability for Stateful PCE May 2013
+------+-----+-----+-----+--------+----------+-------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+-------+
| 1 | 1 | E | G | 10 | Yes | E-F-G |
| 2 | 2 | A | B | 10 | No | --- |
| 3 | 1 | F | C | 10 | No | --- |
+------+-----+-----+-----+--------+----------+-------+
Table 2: Throughput use case demand time series
In many cases throughput maximization becomes a bin packing problem.
While bin packing itself is an NP-hard problem, a number of common
heuristics which run in polynomial time can provide significant
improvements in throughput over random reservation event
distribution, especially when traversing links which are members of
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
Figure 1, where LSP state visibility and control of reservation order
across PCCs would result in significant improvement in total
throughput.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 3: Link parameters for Bin Packing use case
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 5 | Yes | A-C-D-E |
| 2 | 2 | B | E | 10 | No | --- |
+------+-----+-----+-----+--------+----------+---------+
Table 4: Bin Packing use case demand time series
5.1.2. Deadlock
This section discusses a use case of cross-LSP impact under degraded
operation. Most existing RSVP-TE implementations will not tear down
established LSPs in the event of the failure of the bandwidth
Zhang & Minei Expires November 25, 2013 [Page 8]
Internet-Draft Applicability for Stateful PCE May 2013
increase procedure detailed in [RFC3209]. This behavior is directly
implied to be correct in [RFC3209] and is often desirable from an
operator's perspective, because either a) the destination prefixes
are not reachable via any means other than MPLS or b) this would
result in significant packet loss as demand is shifted to other LSPs
in the overlay mesh.
In addition, there are currently few implementations offering dynamic
ingress admission control (policing of the traffic volume mapped onto
an LSP) at the LER. Having ingress admission control on a per LSP
basis is not necessarily desirable from an operational perspective,
as a) one must over-provision tunnels significantly in order to avoid
deleterious effects resulting from stacked transport and flow control
systems and b) there is currently no efficient commonly available
northbound interface for dynamic configuration of per LSP ingress
admission control (such an interface could easily be defined using
the extensions for stateful PCE, but has not been yet at the time of
this writing).
Lack of ingress admission control coupled with the behavior in
[RFC3209] may result in LSPs operating out of profile for significant
periods of time. It is reasonable to expect that these out-of-
profile LSPs will be operating in a degraded state and experience
traffic loss, but because they end up sharing common network
interfaces with other LSPs operating within their bandwidth
reservations, they will end up impacting the operation of the in-
profile LSPs, even when there is unused network capacity elsewhere in
the network. Furthermore, this behavior will cause information loss
in the TED with regards to the actual available bandwidth on the
links used by the out-of-profile LSPs, as the reservations on the
links no longer reflect the capacity used.
Reference Topology 1 in Figure 1 and Tables 5 and 6 show a use case
that demonstrates this behavior. Two LSPs, LSP 1 and LSP 2 are
signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E
respectively. At a later time, the demand of LSP 1 increases to 20.
Under such a demand, the LSP cannot be resignaled. However, the
existing LSP will not be torn down. In the absence of ingress
policing, traffic on LSP 1 will cause degradation for traffic of LSP
2 (due to oversubscription on the links C-D and D-E), as well as
information loss in the TED with regard to the actual network state.
The problem could be easily ameliorated by global visibility of LSP
state coupled with PCC-external demand measurements and placement of
two LSPs on disjoint links. Note that while the demand of 20 for LSP
1 could never be satisfied in the given topology, what could be
achieved would be isolation from the ill-effects of the
(unsatisfiable) increased demand.
Zhang & Minei Expires November 25, 2013 [Page 9]
Internet-Draft Applicability for Stateful PCE May 2013
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 5: Link parameters for the 'Degraded operation' example
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 2 | Yes | A-C-D-E |
| 2 | 2 | B | E | 2 | Yes | B-C-D-E |
| 3 | 1 | A | E | 20 | No | --- |
+------+-----+-----+-----+--------+----------+---------+
Table 6: Degraded operation demand time series
5.1.3. Minimum Perturbation
As a result of both the lack of visibility into global LSP state and
the lack of control over event ordering across PCE sessions,
unnecessary perturbations may be introduced into the network by a
stateless PCE. Tables 7 and 8 show an example of an unnecessary
network perturbation using Reference Topology 1 in Figure 1. In this
case an unimportant (high LSP priority value) LSP (LSP1) is first set
up along the shortest path. At time 2, which is assumed to be
relatively close to time 1, a second more important (lower LSP-
priority value) LSP (LSP2) is established, preempting LSP1,
potentially causing traffic loss. LSP1 is then reestablished on the
longer A-C-E path.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 7: Link parameters for the 'Minimum-Perturbation' example
Zhang & Minei Expires November 25, 2013 [Page 10]
Internet-Draft Applicability for Stateful PCE May 2013
+------+-----+-----+-----+--------+----------+----------+---------+
| Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path |
+------+-----+-----+-----+--------+----------+----------+---------+
| 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E |
| 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E |
| 3 | 1 | A | E | 7 | 7 | Yes | A-C-E |
+------+-----+-----+-----+--------+----------+----------+---------+
Table 8: Minimum-Perturbation LSP and demand time series
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
placement of the more important LSP along the shortest path, avoiding
the preemption of the lower priority LSP.
5.1.4. Predictability
Randomization of reservation events caused by lack of control over
event ordering across PCE sessions results in poor predictability in
LSP routing. An offline system applying a consistent optimization
method will produce predictable results to within either the boundary
of forecast error when reservations are over-provisioned by
reasonable margins or to the variability of the signal and the
forecast error when applying some hysteresis in order to minimize
churn. Predictable results are valuable for being able to simulate
the network and reliably test it under various scenarios, especially
under various failure modes and planned maintenances when predictable
path characteristics are desired under contention for network
resources.
Reference Topology 1 and Tables 9, 10 and 11 show the impact of event
ordering and predictability of LSP routing.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 1 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 9: Link parameters for the 'Predictability' example
Zhang & Minei Expires November 25, 2013 [Page 11]
Internet-Draft Applicability for Stateful PCE May 2013
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 7 | Yes | A-C-E |
| 2 | 2 | B | E | 7 | Yes | B-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
Table 10: Predictability LSP and demand time series 1
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 2 | B | E | 7 | Yes | B-C-E |
| 2 | 1 | A | E | 7 | Yes | A-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
Table 11: Predictability LSP and demand time series 2
As can be shown in the example, both LSPs were routed in both cases,
but along very different paths. This would be a challenge if
reliable simulation of the network was attempted. A stateful PCE can
solve this through control over LSP ordering.
5.2. Auto-bandwidth Adjustment
The bandwidth requirement of LSPs often change over time, requiring
resizing the LSP. Currently the head-end node performs this function
by monitoring the actual bandwidth usage, triggering a recomputation
and resignaling when a threshold is reached. This operation is
referred as auto-bandwidth adjustment. The head-end node either
recomputes the path locally, or it requests a recomputation from a
PCE by sending a PCReq message. In the latter case, the PCE computes
a new path and provides the new route suggestion. Upon receiving the
reply from the PCE, the PCC re-signals the LSP in Shared-Explicit
(SE) mode along the newly computed path. If a passive stateful PCE
is used, only the new bandwidth information is needed to trigger a
path re-computation since the LSP information is already known to the
PCE. Note that in this scenario, the head-end node is the one that
drives the LSP resizing based on local information, and that the
difference between using a stateless and a passive stateful PCE is in
the level of optimization of the LSP placement as discussed in the
previous section.
A more interesting smart bandwidth adjustment case is one where the
LSP resizing decision is done by an external entity, with access to
additional information such as historical trending data, application-
specific information about expected demands or policy information, as
well as knowledge of the actual desired flow volumes. In this case
Zhang & Minei Expires November 25, 2013 [Page 12]
Internet-Draft Applicability for Stateful PCE May 2013
an active stateful PCE provides an advantage in both the computation
with knowledge of all LSPs in the domain and in the ability to
trigger bandwidth modification of the LSP.
5.3. Bandwidth Scheduling
Bandwidth scheduling allows network operators to reserve resources in
advance according to the agreements with their customers, and allow
them to transmit data with specified starting time and duration, for
example for a scheduled bulk data replication between data centers.
Traditionally, this can be supported by NMS operation through path
pre-establishment and activation on the agreed starting time.
However, this does not provide efficient network usage since the
established paths exclude the possibility of being used by other
services even when they are not used for undertaking any service. It
can also be accomplished through GMPLS protocol extensions by
carrying the related request information (e.g., starting time and
duration) across the network. Nevertheless, this method inevitably
increases the complexity of signaling and routing process.
A passive stateful PCE can support this application with better
efficiency since it can alleviate the burden of processing on network
elements. This requires the PCE to maintain the scheduled LSPs and
their associated resource usage, as well as the ability of head-ends
to trigger signaling for LSP setup/deletion at the correct time.
This approach requires coarse time synchronization between PCEs and
PCCs. If an active stateful PCE is available, the PCE can trigger
the setup/deletion of scheduled requests in a centralized manner,
without modification of existing head-end behaviors.
5.4. Recovery
The recovery use cases discussed in the following sections show how
leveraging a stateful PCE can simplify the computation of recovery
path(s). In particular, two characteristics of a stateful PCE are
used: 1) using information stored in the LSP-DB for determining
shared protection resources and 2) performing computations with
knowledge of all LSPs in a domain.
5.4.1. Protection
For protection purposes, a PCC may send a request to a PCE for
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
separately. Either way, the resources bound to backup paths can be
shared by different LSPs to improve the overall network efficiency,
such as m:n protection or pre-configured shared mesh recovery
Zhang & Minei Expires November 25, 2013 [Page 13]
Internet-Draft Applicability for Stateful PCE May 2013
techniques as specified in [RFC4427]. If resource sharing is
supported for LSP protection, the information relating to existing
LSPs is required to avoid allocation of shared protection resources
to two LSPs that might fail together and cause protection contention
issues. A stateless PCE can accommodate this use case by having the
PCC pass in this information as a constraint to the path computation
request. A stateful PCE can more easily accommodate this need using
the information stored in its LSP-DB.
+----+
|PCE |
+----+
+------+ +------+ +------+
| N1 +----------+ N2 +----------+ N3 |
+--+---+ +---+--+ +---+--+
| | |
| +---------+ |
| | |
| +--+---+ +------+ |
+-----+ N5 +----------+ N4 +-----+
+------+ +------+
Figure 3: Reference topology 3
For example, in the network depicted in Figure 3 , suppose there
exists LSP1 with working path LSP1_working following N1->N5 and with
backup path LSP1_backup following N1->N2->N5. A request arrives
asking for a working and backup path pair to be computed for LSP2,
for a request from N2 to N5. If the PCE decides LSP2_working follows
N2->N1->N5, then the backup path LSP2_backup should not use the same
protection resource with LSP1 since LSP2 shares part of its resource
(specifically N1->N5) with LSP1 (i.e., these two LSPs are in the same
shared risk group). Alternatively, there is no such constraint if
N2->N3->N4->N5 is chosen for LSP2_working.
If a stateless PCE is used, the head node N2 needs to be aware 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
to the PCE as a constraint so as to request a path with SRLG
diversity. On the other hand, a stateful PCE can get the LSPs
information by itself 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.
Zhang & Minei Expires November 25, 2013 [Page 14]
Internet-Draft Applicability for Stateful PCE May 2013
5.4.2. Restoration
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
be informed of the failure by the nodes detecting the failure. These
source nodes will send requests to a PCE for rerouting. In order to
reuse the resource taken by an existing LSP, the source node can send
a PCReq message including the XRO object with F bit set, together
with RRO object, as specified in [RFC5521].
If a stateless PCE is exploited, it might respond to the rerouting
requests separately if they arrive at different times. Thus, it
might result in sub-optimal resource usage. Even worse, it might
unnecessarily block some of the rerouting requests due to
insufficient resources for later-arrived rerouting messages. If a
stateful PCE is used to fulfill this task, it can re-compute the
affected LSPs concurrently while reusing part of the existing LSPs
resources when it is informed of the failed link identifier provided
by the first request. This is made possible since the stateful PCE
can check what other LSPs are affected by the failed link and their
route information by inspecting its LSP-DB. As a result, a better
performance, such as better resource usage, minimal probability of
blocking upcoming new rerouting requests sent as a result of the link
failure, can be achieved.
In order to further reduce the amount of LSP rerouting messages flow
in the network, the notification can be performed at the node(s)
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;
(ii) LSP2: N2->N5->N4. They traverse the failed link between N5-N4.
When N4 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 N4. Moreover, it can make use
of the bandwidth resources occupied by the affected LSPs when
performing path recalculation. After N4 receives the new paths from
the PCE, it notifies the ingress nodes of the LSPs, i.e., N1 and N2,
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
the time-window of high LSP requests, a stateful PCE can retain the
under-construction LSP resource usage information for a given time
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
thus the issue of resource contention and computation crank-backs can
be resolved.
Zhang & Minei Expires November 25, 2013 [Page 15]
Internet-Draft Applicability for Stateful PCE May 2013
5.4.3. SRLG Diversity
An alternative way to achieve efficient resilience is to maintain
SRLG disjointness between LSPs, irrespective of whether these LSPs
share the source and destination nodes or not. This can be achieved
at provisioning time, if the routes of all the LSPs are requested
together, using a synchronized computation of the different LSPs with
SRLG disjointness constraint. If the LSPs need to be provisioned at
different times (more general, the routes are requested at different
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
(SRLGs) using the Explicit Route Object [RFC5521]. However, for the
latter to be effective, it is needed that the entity that requests
the route to the PCE maintains updated SRLG information of all the
LSPs to which it must maintain the disjointness. A stateless PCE can
compute an SRLG-disjoint path by inspecting the TED and precluding
the links with the same SRLG values specified in the PCReq message
sent by a PCC.
A stateful PCE maintains the updated SRLG information of the
established LSPs in a centralized manner. Therefore, the PCC can
specify as constraints to the path computation the SRLG disjointness
of a set of already established LSPs by only providing the LSP
identifiers.
5.5. Maintenance of 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
which provides TE links to the upper layer. In [RFC5623], the PCE-
based architecture is proposed to support path computation in MLN
networks in order to achieve inter-layer TE.
The establishment/teardown of a TE link in VNT needs to take into
consideration the state of existing LSPs and/or new LSP request(s) in
the higher layer. As specified in [RFC5623], a VNT manager (VNTM) is
in charge of setting up connections in the lower layer to provide TE
links for upper layer. Hence, when a stateless PCE cannot find the
route for a request based on the upper layer topology information, it
needs to interact with the VNTM and rely on the VNTM to decide
whether to set up or remove a TE link or not. On the other hand, a
stateful PCE can make the decision of when and how to modify the VNT
either to accommodate new LSP requests or to re-optimize resource
usage across layers irrespective of the PCE models as described in
[RFC5623].
Zhang & Minei Expires November 25, 2013 [Page 16]
Internet-Draft Applicability for Stateful PCE May 2013
5.6. LSP Re-optimization
In order to make efficient usage of network resources, it is
sometimes desirable to re-optimize one or more LSPs dynamically. In
the case of a stateless PCE, in order to optimize network resource
usage dynamically through online planning, a PCC must send a request
to the PCE together with detailed path/bandwidth information of the
LSPs that need to be concurrently optimized. This means the PCC must
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
database, the process of dynamic optimization of network resources
can be automated without requiring the PCC to supply LSP state
information or to trigger the request. Moreover, since a stateful
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
sequence of LSP setup/deletion, the optimization procedures can be
performed more intelligently and effectively.
A special case of LSP re-optimization is Global Concurrent
Optimization (GCO) [RFC5557]. Global control of LSP operation
sequence in [RFC5557] is predicated on the use of what is effectively
a stateful (or semi-stateful) NMS. The NMS can be either not local
to the switch, in which case another northbound interface is required
for LSP attribute changes, or local/collocated, in which case there
are significant issues with efficiency in resource usage. A stateful
PCE adds a few features that:
o Roll the NMS visibility into the PCE and remove the requirement
for an additional northbound interface
o Allow the PCE to determine when re-optimization is needed, with
which level (GCO or a more incremental optimization)
o Allow the PCE to determine which LSPs should be re-optimized
o Allow a PCE to control the sequence of events across multiple
PCCs, allowing for bulk (and truly global) optimization, LSP
shuffling etc.
5.7. Resource Defragmentation
In networks with link bundles, if LSPs are dynamically allocated and
released over time, the resource becomes fragmented. The overall
available resource on a (bundle) link might be sufficient for a new
LSP request, but if the available resource is not continuous, the
request is rejected. In order to perform the defragmentation
procedure, stateful PCEs cam be used, since global visibility of LSPs
in the network is required to accurately assess resources on the
Zhang & Minei Expires November 25, 2013 [Page 17]
Internet-Draft Applicability for Stateful PCE May 2013
LSPs, and perform de-fragmentation while ensuring a minimal
disruption of the network. This use case cannot be accommodated by a
stateless PCE since it does not possess the detailed information of
existing LSPs in the network.
A case of particular interest to GMPLS-based transport networks is
the frequency defragmentation in flexible grid. In Flexible grid
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
accommodate the services with different bandwidth requests.
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
existing LSP state information, stateful PCE can make the resource
grouped together to be usable. Moreover, stateful PCE can
proactively choose routes for upcoming path requests to reduce the
chance of spectrum fragmentation.
5.8. Impairment-Aware Routing and Wavelength Assignment (IA-RWA)
In 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 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
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
alleviate these effects. The width of the guard band between two
adjacent wavelengths depends on their characteristics, such as
modulation formats and bit rates. Two adjacent wavelengths with
different characteristics (e.g., different bit rates) may need a
wider guard band and with same characteristics may need a narrower
guard band. For example, 50GHz spacing may be acceptable for two
adjacent wavelengths with 40G signals. But for two adjacent
wavelengths with different bit rates (e.g., 10G and 40G), a larger
spacing such as 300GHz spacing may be needed. Hence, the
characteristics (states) of the existing wavelength LSPs should be
considered for a new RWA request in WSON.
In summary, when stateful PCEs are used to perform the IA-RWA
Zhang & Minei Expires November 25, 2013 [Page 18]
Internet-Draft Applicability for Stateful PCE May 2013
procedure, they need to know the characteristics of the existing
wavelength LSPs. The impairment information relating to existing and
to-be-established LSPs can be obtained by nodes in WSON networks via
external configuration or other means such as monitoring or
estimation based on a vendor-specific impair model. However, WSON
related routing protocols, i.e.,
[I-D.ietf-ccamp-wson-signal-compatibility-ospf] and
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te], only advertise
limited information (i.e., availability) of the existing wavelengths,
without defining the supported client bit rates. It will incur
substantial amount of control plane overhead if routing protocols are
extended to support dissemination of the new information relevant for
the IA-RWA process. In this scenario, stateful PCE(s) would be a
more appropriate mechanism to solve this problem. Stateful PCE(s)
can exploit impairment information of LSPs stored in LSP-DB to
provide accurate RWA calculation.
6. Security Considerations
This document does not introduce any new security considerations
beyond those discussed in [I-D.ietf-pce-stateful-pce].
The following topics will be discussed in a future version of this
document: whether use of a stateful PCE makes the network more or
less secure, and security use cases if any.
7. Contributing Authors
The following people all contributed significantly to this document
and are listed below in alphabetical order:
Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
Email: ramon.casellas@cttc.es
Edward Crabbe
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: edc@google.com
Dhruv Dhody
Zhang & Minei Expires November 25, 2013 [Page 19]
Internet-Draft Applicability for Stateful PCE May 2013
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruvd@huawei.com
Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
Madrid, 28045
Spain
Phone: +34 913374013
Email: ogondio@tid.es
Young Lee
Huawei
1700 Alma Drive, Suite 100
Plano, TX 75075
US
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
EMail: ylee@huawei.com
Jan Medved
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
US
Email: jmedved@cisco.com
Robert Varga
Pantheon Technologies LLC
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.sk
Fatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129 P.R.China
Phone: +86-755-28972912
Email: zhangfatai@huawei.com
Xiaobing Zi
Email: unknown
Zhang & Minei Expires November 25, 2013 [Page 20]
Internet-Draft Applicability for Stateful PCE May 2013
8. Acknowledgements
We would like to thank Cyril Margaria, Adrian Farrel and JP Vasseur
for the useful comments and discussions.
9. References
9.1. Normative References
[I-D.ietf-pce-stateful-pce]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
Extensions for Stateful PCE",
draft-ietf-pce-stateful-pce-04 (work in progress),
May 2013.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
9.2. Informative References
[I-D.crabbe-pce-stateful-pce-mpls-te]
Crabbe, E., Medved, J., Minei, I., and R. Varga, "Stateful
PCE extensions for MPLS-TE LSPs",
draft-crabbe-pce-stateful-pce-mpls-te-01 (work in
progress), May 2013.
[I-D.ietf-ccamp-gmpls-general-constraints-ospf-te]
Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu,
"OSPF-TE Extensions for General Network Element
Constraints",
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-04
(work in progress), July 2012.
[I-D.ietf-ccamp-wson-signal-compatibility-ospf]
Lee, Y. and G. Bernstein, "GMPLS OSPF Enhancement for
Signal and Network Element Compatibility for Wavelength
Switched Optical Networks",
draft-ietf-ccamp-wson-signal-compatibility-ospf-11 (work
in progress), February 2013.
[I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-07 (work in
Zhang & Minei Expires November 25, 2013 [Page 21]
Internet-Draft Applicability for Stateful PCE May 2013
progress), October 2012.
[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-02 (work in progress),
February 2013.
[I-D.sivabalan-pce-disco-stateful]
Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
for Stateful PCE Discovery",
draft-sivabalan-pce-disco-stateful-01 (work in progress),
April 2013.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global
Information Infrastructure Symposium, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear
programming algorithm for balancing the max-min fairness
and throughput objectives in traffic engineering", pre-
print, 2011.
[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network
Recovery: Protection and Restoration of Optical, SONET-
SDH, IP, and MPLS", The Morgan Kaufmann Series in
Networking, June 2004.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE)
Communication Protocol Generic Requirements", RFC 4657,
September 2006.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
July 2008.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
Zhang & Minei Expires November 25, 2013 [Page 22]
Internet-Draft Applicability for Stateful PCE May 2013
December 2008.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, April 2009.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, July 2009.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, September 2009.
[RFC6163] Lee, Y., Bernstein, G., and W. Imajuku, "Framework for
GMPLS and Path Computation Element (PCE) Control of
Wavelength Switched Optical Networks (WSONs)", RFC 6163,
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
Xian Zhang (editor)
Huawei Technologies
F3-5-B R&D Center, Huawei Base Bantian, Longgang District
Shenzhen, Guangdong 518129
P.R.China
Email: zhang.xian@huawei.com
Zhang & Minei Expires November 25, 2013 [Page 23]
Internet-Draft Applicability for Stateful PCE May 2013
Ina Minei (editor)
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: ina@juniper.net
Zhang & Minei Expires November 25, 2013 [Page 24]
