[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-zhang-pce-stateful-pce-app) 00 01 02 03 04 05 06 07 08 RFC 8051

PCE Working Group                                          X. Zhang, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Informational                             I. Minei, Ed.
Expires: March 29, 2014                           Juniper Networks, Inc.
                                                      September 25, 2013


        Applicability of Stateful Path Computation Element (PCE)
                   draft-ietf-pce-stateful-pce-app-01

Abstract

   A stateful Path Computation Element (PCE) maintains information about
   Label Switched Path (LSP) characteristics and resource usage within a
   network in order to provide traffic engineering calculations for its
   associated Path Computation Clients (PCCs).  This document describes
   general considerations for a stateful PCE deployment and examines its
   applicability and benefits, as well as its challenges and limitations
   through a number of use cases.  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 March 29, 2014.

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



Zhang & Minei            Expires March 29, 2014                 [Page 1]


Internet-Draft       Applicability for Stateful PCE       September 2013


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


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  . . . . . . . . . . . . . . . . . . . .  6
   5.  Application Scenarios  . . . . . . . . . . . . . . . . . . . .  6
     5.1.  Optimization of LSP Placement  . . . . . . . . . . . . . .  7
       5.1.1.  Throughput Maximization and Bin Packing  . . . . . . .  8
       5.1.2.  Deadlock . . . . . . . . . . . . . . . . . . . . . . .  9
       5.1.3.  Minimum Perturbation . . . . . . . . . . . . . . . . . 11
       5.1.4.  Predictability . . . . . . . . . . . . . . . . . . . . 12
     5.2.  Auto-bandwidth Adjustment  . . . . . . . . . . . . . . . . 13
     5.3.  Bandwidth Scheduling . . . . . . . . . . . . . . . . . . . 13
     5.4.  Recovery . . . . . . . . . . . . . . . . . . . . . . . . . 14
       5.4.1.  Protection . . . . . . . . . . . . . . . . . . . . . . 14
       5.4.2.  Restoration  . . . . . . . . . . . . . . . . . . . . . 15
       5.4.3.  SRLG Diversity . . . . . . . . . . . . . . . . . . . . 16
     5.5.  Maintenance of Virtual Network Topology (VNT)  . . . . . . 17
     5.6.  LSP Re-optimization  . . . . . . . . . . . . . . . . . . . 17
     5.7.  Resource Defragmentation . . . . . . . . . . . . . . . . . 18
     5.8.  Impairment-Aware Routing and Wavelength Assignment
           (IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . . 19
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7.  Contributing Authors . . . . . . . . . . . . . . . . . . . . . 20
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 22
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24











Zhang & Minei            Expires March 29, 2014                 [Page 2]


Internet-Draft       Applicability for Stateful PCE       September 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) for interaction between a Path Computation Client
   (PCC) and a PCE, or between two PCEs, enabling computation of TE LSPs
   in the context of MPLS networks.  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.  However, 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.

   This document defines the following term:




Zhang & Minei            Expires March 29, 2014                 [Page 3]


Internet-Draft       Applicability for Stateful PCE       September 2013


   Minimum Cut Set:  the minimum set of links for a specific source
      destination pair which, when removed from the network, results 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.

   [I-D.ietf-pce-stateful-pce] distinguishes between an active and a
   passive stateful PCE.  A passive stateful PCE uses LSP state
   information learned from PCCs to optimize path computations but does
   not actively update LSP state.  In contrast, an active stateful PCE
   may issue recommendations to the network.  For example, an active
   stateful PCE may utilize the delegation mechanism to update LSP
   parameters in those PCCs that delegated control over their LSPs to
   the PCE.

   Several new functions are added in PCEP to support both active and
   passive stateful PCEs.  They are described in
   [I-D.ietf-pce-stateful-pce].  A function can be initiated either from
   a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C).  The new
   functions are:

   Capability negotiation (E-C,C-E):  both the PCC and the PCE must
      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.





Zhang & Minei            Expires March 29, 2014                 [Page 4]


Internet-Draft       Applicability for Stateful PCE       September 2013


   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.

   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 auto-discovery of stateful PCEs when using IGP 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.

   Multiple stateful PCEs can co-exist in the same network.  These PCEs
   may provide redundancy for load sharing, resilience, or partitioning
   of computation features.  Regardless of the reason for multiple PCEs,
   an LSP is only delegated to one of the PCEs at any given point in
   time.  [I-D.ietf-pce-stateful-pce] describes how LSPs can be re-
   delegated between PCEs, and the procedures on a PCE failure.
   [I-D.ietf-pce-questions] discusses various approaches for
   synchronizing state among the PCEs when multiple PCEs are used for
   load sharing and compute LSPs for the same network.

4.2.  LSP State Synchronization

   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



Zhang & Minei            Expires March 29, 2014                 [Page 5]


Internet-Draft       Applicability for Stateful PCE       September 2013


   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
   the databases used, it is worth noting that the PCE view lags behind
   the true state of the network, because the updates must reach the PCE
   from the network.  Thus, the use of stateful PCE reduces but cannot
   eliminate the possibility of crankbacks, nor can it guarantee optimal
   computations all the time.  [I-D.ietf-pce-questions] discusses these
   limitations and potential ways to alleviate them.

4.3.  PCE Survivability

   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 a Label Edge Router (LER) client or
   another PCE, allowing for support of multiple ways of re-acquiring
   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.  A hybrid approach where the
   bulk of the state is recovered locally, and a small amount of state
   is reacquired from the network is also possible.  Note that locally
   recovering the state would still require some degree of
   resynchronization to ensure that the recovered state is indeed up-to-
   date.  Depending on the resynchronization mechanism used, there may
   be additional load on the PCE, and there may be a delay in reaching
   the synchronized state, which may negatively affect survivabiliy.
   Different resynchronization methods are suited for different
   deployments and objectives.


5.  Application Scenarios

   In the following sections, several use cases are described,
   showcasing scenarios that benefit from the deployment of a stateful
   PCE.





Zhang & Minei            Expires March 29, 2014                 [Page 6]


Internet-Draft       Applicability for Stateful PCE       September 2013


5.1.  Optimization of LSP Placement

   The following use cases demonstrate a need for visibility into global
   LSP states in PCE path computations, and for a PCE control of
   sequence and timing in altering LSP path characteristics within and
   across PCEP sessions.  Reference topologies for the use cases
   described later in this section are shown in Figures 1 and 2.

   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


               +-----+        +-----+        +-----+
               |  A  |        |  B  |        |  C  |
               +--+--+        +--+--+        +--+--+
                  |              |              |
                  |              |              |
               +--+--+        +--+--+        +--+--+
               |  E  +--------+  F  +--------+  G  |
               +-----+        +-----+        +-----+


                      Figure 2: Reference topology 2








Zhang & Minei            Expires March 29, 2014                 [Page 7]


Internet-Draft       Applicability for Stateful PCE       September 2013


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
   resource reservation arrivals occurring in the network will be
   randomized.  This, coupled with a lack of global LSP state visibility
   on the part of a stateless PCE may result in suboptimal throughput in
   a given network topology, as will be shown in the example below.

   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

          +------+-----+-----+-----+--------+----------+-------+
          | 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



Zhang & Minei            Expires March 29, 2014                 [Page 8]


Internet-Draft       Applicability for Stateful PCE       September 2013


   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
   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 (for example for tunnels that are dynamically resized based
   on current traffic) and b) there is currently no efficient commonly
   available northbound interface for dynamic configuration of per LSP
   ingress admission control.

   Lack of ingress admission control coupled with the behavior in
   [RFC3209] may result in LSPs operating out of profile for significant



Zhang & Minei            Expires March 29, 2014                 [Page 9]


Internet-Draft       Applicability for Stateful PCE       September 2013


   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.

                       +------+--------+----------+
                       | 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












Zhang & Minei            Expires March 29, 2014                [Page 10]


Internet-Draft       Applicability for Stateful PCE       September 2013


         +------+-----+-----+-----+--------+----------+---------+
         | 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

    +------+-----+-----+-----+--------+----------+----------+---------+
    | 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



Zhang & Minei            Expires March 29, 2014                [Page 11]


Internet-Draft       Applicability for Stateful PCE       September 2013


   placement of the more important LSP along the shortest path, avoiding
   the preemption of the lower priority LSP.  Similarly, when a new
   higher priority LSP which requires preemption of existing lower
   priority LSP(s), a stateful PCE can determine the minimum number of
   lower priority LSP(s) to reroute using the make-before-break (MBB)
   mechanism without disrupting any service and then set up the higher
   priority LSP.

5.1.4.  Predictability

   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

         +------+-----+-----+-----+--------+----------+---------+
         | 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





Zhang & Minei            Expires March 29, 2014                [Page 12]


Internet-Draft       Applicability for Stateful PCE       September 2013


         +------+-----+-----+-----+--------+----------+---------+
         | 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 are routed in both cases,
   but along very different paths.  This would be a challenge if
   reliable simulation of the network is 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 Path Computation Request (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
   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



Zhang & Minei            Expires March 29, 2014                [Page 13]


Internet-Draft       Applicability for Stateful PCE       September 2013


   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, by notifying the
   PCCs to set up or tear down the paths.

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
   techniques as specified in [RFC4427].  If resource sharing is
   supported for LSP protection, the information relating to existing
   LSPs is required to avoid allocation of shared protection resources
   to two LSPs that might fail together and cause protection contention
   issues.  A stateless PCE can accommodate this use case by having the
   PCC pass this information as a constraint in the path computation
   request.  A passive stateful PCE can more easily accommodate this
   need using the information stored in its LSP-DB.  Furthermore, an



Zhang & Minei            Expires March 29, 2014                [Page 14]


Internet-Draft       Applicability for Stateful PCE       September 2013


   active stateful PCE can help with (re)-optimizization of protection
   resource sharing as well as LSP maintenance operation with fewer
   impact on protection resources.

                 +----+
                 |PCE |
                 +----+

            +------+          +------+          +------+
            |  A   +----------+  B   +----------+  C   |
            +--+---+          +---+--+          +---+--+
               |                  |                 |
               |        +---------+                 |
               |        |                           |
               |     +--+---+          +------+     |
               +-----+  E   +----------+  D   +-----+
                     +------+          +------+


                      Figure 3: Reference topology 3

   For example, in the network depicted in Figure 3 , suppose there
   exists LSP1 with working path LSP1_working following A->E and with
   backup path LSP1_backup following A->B->E. A request arrives asking
   for a working and backup path pair to be computed for LSP2, for a
   request from B to E. If the PCE decides LSP2_working follows B->A->E,
   then the backup path LSP2_backup should not use the same protection
   resource with LSP1 since LSP2 shares part of its resource
   (specifically A->E) with LSP1 (i.e., these two LSPs are in the same
   shared risk group).  Alternatively, there is no such constraint if
   B->C->D->E is chosen for LSP2_working.

   If a stateless PCE is used, the head node B needs to be aware of the
   existence of LSPs which share the route of LSP2_working and of the
   details of their protection resources.  B must pass this information
   to the PCE as a constraint so as to request a path with diversity.
   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.

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



Zhang & Minei            Expires March 29, 2014                [Page 15]


Internet-Draft       Applicability for Stateful PCE       September 2013


   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
   passive 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
   passive stateful PCE can check what other LSPs are affected by the
   failed link and their route information by inspecting its LSP-DB.  As
   a result, a better performance, 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: 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
   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.

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



Zhang & Minei            Expires March 29, 2014                [Page 16]


Internet-Draft       Applicability for Stateful PCE       September 2013


   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 Exclude 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 passive stateful PCE maintains the updated SRLG information of the
   established LSPs in a centralized manner.  Therefore, the PCC can
   specify as constraints to the path computation the SRLG disjointness
   of a set of already established LSPs by only providing the LSP
   identifiers.  Similarly, a passive stateful PCE can also accommodate
   disjointness using other contraints, such as link, node or path
   segment etc.

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.  Hence, when a stateless PCE cannot find the route
   for a request based on the upper layer topology information, it does
   not have enough information to decide whether to set up or remove a
   TE link or not, which then can result in non-optimal usage of
   resource.  On the other hand, a passive stateful PCE can make a
   better decision of when and how to modify the VNT either to
   accommodate new LSP requests or to re-optimize resource usage across
   layers irrespective of the PCE models as described in [RFC5623].
   Furthermore, given the active capability, the stateful PCE can issue
   VNT modification suggestions in order to accommodate path setup
   requests or re-optimize resource usage across layers.

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



Zhang & Minei            Expires March 29, 2014                [Page 17]


Internet-Draft       Applicability for Stateful PCE       September 2013


   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 stateful PCE can
   also determine which LSP should be re-optimized based on network
   events.  For example, when a LSP is torn down, its resources are
   freed.  This can trigger the stateful PCE to automatically determine
   which LSP should be reoptimized so that the recently freed resources
   may be allocated to it.

   A special case of LSP re-optimization is Global Concurrent
   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 network nodes, in which case another northbound interface is
   required for LSP attribute changes, or local/collocated, in which
   case there are significant issues with efficiency in resource usage.
   A stateful PCE adds a few features that:

   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 can be used, since global visibility of LSPs



Zhang & Minei            Expires March 29, 2014                [Page 18]


Internet-Draft       Applicability for Stateful PCE       September 2013


   in the network is required to accurately assess resources on the
   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, a stateful PCE can make the resource
   grouped together to be usable.  Moreover, a stateful PCE can
   proactively choose routes for upcoming path requests to reduce the
   chance of spectrum fragmentation.

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.




Zhang & Minei            Expires March 29, 2014                [Page 19]


Internet-Draft       Applicability for Stateful PCE       September 2013


   In summary, when stateful PCEs are used to perform the IA-RWA
   procedure, they need to know the characteristics of the existing
   wavelength LSPs.  The impairment information relating to existing and
   to-be-established LSPs can be obtained by nodes in WSON networks via
   external configuration or other means such as monitoring or
   estimation based on a vendor-specific impair model.  However, WSON
   related routing protocols, i.e.,
   [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

   The PCEP extensions in support of stateful PCE and the delegation of
   path control, result in more information being available for a
   hypothetical adversary and a number of additional attack surfaces
   which must be protected.  [I-D.ietf-pce-stateful-pce] discusses
   different attack vectors and defines protocol mechanisms to protect
   against them.  It also lays out implementation requirements for
   configuration capabilities that allow the operator to control the PCC
   behavior when faced with an attack.  This document does not introduce
   any new security considerations beyond those discussed in
   [I-D.ietf-pce-stateful-pce].


7.  Contributing Authors

   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



Zhang & Minei            Expires March 29, 2014                [Page 20]


Internet-Draft       Applicability for Stateful PCE       September 2013


   Mountain View, CA 94043
   US
   Email: edc@google.com

   Dhruv Dhody
   Huawei Technology
   Leela Palace
   Bangalore, Karnataka 560008
   INDIA
   EMail: dhruv.dhody@huawei.com

   Oscar Gonzalez de Dios
   Telefonica Investigacion y Desarrollo
   Emilio Vargas 6
   Madrid, 28045
   Spain
   Phone: +34 913374013
   Email: ogondio@tid.es

   Young Lee
   Huawei
   1700 Alma Drive, Suite 100
   Plano, TX 75075
   US
   Phone: +1 972 509 5599 x2240
   Fax: +1 469 229 5397
   EMail: leeyoung@huawei.com

   Jan Medved
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA 95134
   US
   Email: jmedved@cisco.com

   Robert Varga
   Pantheon Technologies LLC
   Mlynske Nivy 56
   Bratislava 821 05
   Slovakia
   Email: robert.varga@pantheon.sk

   Fatai Zhang
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China
   Phone: +86-755-28972912



Zhang & Minei            Expires March 29, 2014                [Page 21]


Internet-Draft       Applicability for Stateful PCE       September 2013


   Email: zhangfatai@huawei.com

   Xiaobing Zi
   Email: unknown


8.  Acknowledgements

   We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur and
   Ravi Torvi for the useful comments and discussions.


9.  References

9.1.  Normative References

   [I-D.ietf-pce-questions]
              Farrel, A. and D. King, "Unanswered Questions in the Path
              Computation Element Architecture",
              draft-ietf-pce-questions-00 (work in progress), July 2013.

   [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
              Extensions for Stateful PCE",
              draft-ietf-pce-stateful-pce-06 (work in progress),
              August 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-05
              (work in progress), June 2013.



Zhang & Minei            Expires March 29, 2014                [Page 22]


Internet-Draft       Applicability for Stateful PCE       September 2013


   [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-08 (work in
              progress), July 2013.

   [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]
              Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
              for Stateful PCE Discovery",
              draft-sivabalan-pce-disco-stateful-02 (work in progress),
              July 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)



Zhang & Minei            Expires March 29, 2014                [Page 23]


Internet-Draft       Applicability for Stateful PCE       September 2013


              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,
              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.


Authors' Addresses

   Xian Zhang (editor)
   Huawei Technologies
   F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
   Shenzhen, Guangdong  518129
   P.R.China

   Email: zhang.xian@huawei.com











Zhang & Minei            Expires March 29, 2014                [Page 24]


Internet-Draft       Applicability for Stateful PCE       September 2013


   Ina Minei (editor)
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   US

   Email: ina@juniper.net












































Zhang & Minei            Expires March 29, 2014                [Page 25]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/