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

Versions: 00 01 02 03 04 draft-ietf-pce-stateful-pce-app

Network Working Group                                       Fatai Zhang
Internet-Draft                                               Xian Zhang
Intended status: Informational                                Young Lee
                                                         Ramon Casellas
                                                 Oscar Gonzalez de Dios
                                                         Telefonica I+D

Expires: April 17, 2013                                October 18, 2012

        Applicability of Stateful Path Computation Element (PCE)


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 17, 2013.


Zhang                   Expires January 2013                  [Page 1]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   The Path Computation Element (PCE) provides a solution for Traffic
   Engineering (TE) based path calculation in large, multi-domain,
   multi-region, or multi-layer networks. Depending on whether a PCE
   keeps information about LSPs and reserved resource usage in the
   network or not, it can be categorized as either stateful or

   This memo describes general considerations for stateful PCE(s) and
   examines its applicability through a number of typical scenarios. It
   shows how stateful PCE(s) can be applied to facilitate these
   applications. PCEP extensions required for stateful PCE usage are
   covered in separate document(s).

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [RFC2119].

Table of Contents

   Table of Contents .............................................. 2
   1. Introduction ................................................ 3
   2. General Considerations....................................... 5
      2.1. Architectural Considerations............................ 5
      2.2. LSP State Synchronization............................... 5
         2.2.1. Single Domain...................................... 6
         2.2.2. Multi-domain....................................... 6
         2.2.3. Multi-layer........................................ 8
      2.3. PCE Survivability/Reliability........................... 8
      2.4. Delegation and Policy................................... 9
         2.4.1. Use of Under-construction LSPs Information......... 9
   3. Application Scenarios....................................... 11
      3.1. Impairment-Aware Routing and Wavelength Assignment (IA-RWA)
       ........................................................... 11
      3.2. Defragmentation in Flexible Grid Networks ..............12
      3.3. Recovery .............................................. 13
         3.3.1. Protection........................................ 13
         3.3.2. Restoration....................................... 14
      3.4. SRLG Diversity ........................................ 15
      3.5. Maintenance of Virtual Network Topology (VNT).......... 15
      3.6. Global Concurrent Optimization (GCO)................... 16
      3.7. Point-to-Multipoint (P2MP) Application................. 16
      3.8. Time-based Scheduling.................................. 17
   4. Manageability Considerations................................ 17

Zhang                    Expires April 2013                   [Page 2]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

      4.1. Information and Data Models............................ 18
   5. Security Considerations..................................... 18
   6. References ................................................. 18
      6.1. Normative References................................... 18
      6.2. Informative References................................. 18
   7. Contributors' Address....................................... 20
   Authors' Addresses ............................................ 21

1. Introduction

   [RFC 4655] 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). To request path computation services to a PCE, [RFC
   5440] defines the PCE Communication Protocol (PCEP) for
   communications between a Path Computation Client (PCC) and a PCE, or
   between two PCEs. A PCC can initiate a path computation request to a
   PCE through a Path Computation Request (PCReq) message, and then the
   PCE will return the computed path to the requesting PCC in response
   to a previously received PCReq message through a PCEP Path
   Computation Reply (PCRep) message.

   As per [RFC 4655], a PCE can be either stateful or stateless.
   Compared to a stateless PCE, a stateful PCE stores not only the
   network states, but also the set of computed paths and reserved
   resources in use in the network. In other words, the ''state'' in a
   stateful PCE is determined not only by the TED but also by the set
   of active LSPs and their corresponding reserved resources.
   Furthermore, a stateful PCE might also retain the information of
   LSPs under construction in order to reduce resource contention. Such
   augmented state allows the PCE to compute constrained paths while
   considering individual LSPs and their interaction. Note that
   [RFC4655] further specifies that the TED contains link state and
   bandwidth availability as distributed by the IGPs or collected via
   other methods. Even if such information can provide increased
   granularity and more detail, it is not state information in the PCE
   context and so a model that uses it is still described as a
   stateless PCE.

   PCE capability is specified for both MPLS and GMPLS networks
   [RFC4655]. Although initial efforts only covers MPLS in [RFC5440],
   [RFc5441] PCEP extension in support of GMPLS is currently being
   standardized [PCEP-GMPLS]. Therefore, stateful extension of PCE

Zhang                    Expires April 2013                   [Page 3]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   should also cover both types of networks. For example, transport
   networks, such as SDH, OTN and WDM, should be able to take advantage
   of stateful PCE ability for a variety of purposes, such as traffic

   As described in section 6.8 of [RFC 4655], there are many
   applications which can benefit from stateful PCE(s), e.g.:

   o Minimum perturbation: stateful PCE(s) can minimize the number of
   existing TE LSPs that are affected and preempted by a higher-
   priority TE LSP request in a crowded network.

   o Virtual Network Topology (VNT) maintenance: the information of
   existing LSPs in the higher layer is used as an input for setting
   up/tearing down the LSPs in the lower layer (i.e., VNT modification).

   Besides these scenarios, there are some additional scenarios that
   should be investigated further, especially for GMPLS networks. For
   instance, in impairment-aware Wavelength Switched Optical Networks
   (WSON) [WSON-Impairment], stateful PCEs could be used to perform
   Impairment-Aware Routing and Wavelength Assignment (IA-RWA)
   procedures. In this case, PCE(s) need to know the detailed
   information of the existing LSPs so that the new LSP(s) will not
   impact them. Such PCE(s) would maintain the existing LSPs states
   (e.g., route, wavelength and speed) to perform impairment aware RWA
   procedures simpler and with less protocol overhead.

   [RFC 4655] also discusses potential scalability and synchronization
   issues in order to implement stateful PCE(s). The main problem
   pointed out by [RFC 4655] is that a PCE would be constrained if the
   states of all the TE LSPs in a network are to be maintained by a PCE.
   Moreover, such state, when there are multiple PCEs, needs to be
   properly synchronized. These issues are especially relevant in
   packet networks, such as MPLS-TE networks, given a potentially large
   number of LSPs. Nonetheless, it is expected that in transport
   networks, such as OTN networks, the number of the LSPs will be much
   smaller, which makes stateful PCEs more applicable. Finally, with
   the increasing power and memory of the hardware platforms that a PCE
   may run, the number of LSPs that can be managed by a PCE is
   significantly large. Hence, there is lesser scaling issue for a PCE
   to store all the LSPs' states, especially for a transport network.

   This document presents general considerations for stateful PCE(s)
   and several examples of its application scenarios. It exhibits the
   utility of stateful PCE(s) in effective support of these
   applications to obtain better performance. Protocol specific
   extensions are covered in separate documents [stateful-PCEP-mpls],

Zhang                    Expires April 2013                   [Page 4]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

2. General Considerations

2.1. Architectural Considerations

   Several PCE architectures are described in Section 5 of [RFC4655]. A
   stateful PCE needs to maintain a large amount of data and
   potentially incur in a very high amount of control plane overhead.
   Moreover, there might be high computational demands on stateful PCE
   entities to effectively support the applications listed in Section 3.
   Therefore, the composite PCE architecture is NOT RECOMMENDED to
   support stateful PCEs. It does not exclude the possibility that
   multiple PCEs with different capabilities are included in the
   network. For example, both stateless and stateful PCEs can co-exist
   to be in charge of path computation of different types. In all cases,
   the stateful capability of PCE should be made known within the

2.2. LSP State Synchronization

   As suggested by the definition, a stateful PCE maintains two
   databases for path computation. The first one is the Traffic
   Engineering Database (TED) which includes the topology and resource
   in the network. TED can be obtained through participating in routing
   distribution of TE information or other means as explained in
   Section 6.7 of [RFC4655].

   The other database is the LSP state Database (LSP-DB), in which a
   PCE stores attributes of all existing LSPs in the network, such as
   payload signal, switching types and bandwidth/resource usage etc.

   In order for PCE to support GMPLS control plane, [RFC5440] needs
   extensions with regard to the features of GMPLS networks. Similarly,
   for LSP state synchronization, the attributes of LSP pertaining to
   GMPLS should be captured in PCECP extensions.

   A stateful PCE should gather the LSP information either from the
   network management system (NMS) or from the nodes in the network.
   For a NMS-based PCE, if the PCE is not co-located with the NMS, a
   standard communication protocol is needed for LSP state
   synchronization; otherwise, proprietary APIs can be used. If a PCE
   relies on network nodes for state synchronization, the strategies
   may vary depending on the network scenarios in which the PCE is
   applied to (i.e., single domain, multiple domain or multi-layer
   networks.) as well as the adoption of PCE computation model.

Zhang                    Expires April 2013                   [Page 5]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

2.2.1. Single Domain

   In a single domain network, LSP state information is maintained
   locally by the nodes initiating LSP(s). Therefore, PCE(s) should
   gather the LSP state information either passively or actively from
   the nodes in the network they have visibility. With a centralized
   stateful PCE computation model, it is straightforward that all nodes
   in the domain could communicate with the PCE for its LSP-DB
   synchronization. As for distributed stateful PCE computation model
   (i.e., there are multiple stateful PCEs in the network), there are
   several alternatives for synchronization:

   o Every node can update the PCE LSP-DBs by sending the LSP state
   information to each of the PCEs in the network separately.

   o Another feasible strategy is to choose one of the PCEs (i.e., a
   designated PCE) for synchronization with all the nodes in the
   network and the designated PCE also updates the LSP-DBs of all the
   other PCE(s).

   o A mixed of these two methods listed above can also be considered in
   which more than one PCEs (e.g., two PCEs) are chosen to interact
   directly with nodes in the network for state synchronization while
   other PCEs are updated via these PCEs.

2.2.2. Multi-domain

   In a multi-domain network with a centralized PCE model, the LSP
   state synchronization is similar to that of a single domain scenario.
   If there is a stateful PCE responsible for performing path
   computation within each domain, the LSPs (segments) traversing the
   domain/layer should be synchronized to the PCE.

Zhang                    Expires April 2013                   [Page 6]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   As described in [RFC4726], there are four methods to set up a LSP
   traversing multiple domains: LSP nesting, contiguous LSP, LSP
   stitching and hybrid methods, respectively. Hence, the ingress nodes
   of a LSP traversing a domain may exist in another domain (e.g., a
   contiguous LSP spanning across multiple domains). In this case, the
   border node of a domain (i.e., an intermediate node of a LSP), could
   be responsible for synchronizing the LSP segment in the domain to
   the PCE.
           |      +----+         |       +----+        |
           |      |PCE1|         |       |PCE2|        |
           |      +----+         |       +----+        |
           |      Domain 1       |       Domain 2      |
           |  +--+   +--+   +--+ | +--+   +--+   +--+  |
           |  |N1+---+N2+---+N3+---+N7+---+N8+---+N9|  |
           |  +-++   +--+   +-++ | +-++   +--+   +-++  |
           |    |             |  |   |             |   |
           |    |             |  |   |             |   |
           |  +-++   +--+   +-++ | +-+-+        +--++  |
           |  |N4+---+N5+---+N6+---+N10+--------+N11|  |
           |  +--+   +--+   +--+ | +---+        +---+  |

                      Figure 1: Multi-domain Scenario

   Figure 1 shows an example of multi-domain scenario. Suppose a
   contiguous LSP traverses N1-N2-N3-N7-N8-N9. Then in domain 1, the
   ingress node of the LSP (i.e., N1) SHOULD synchronize the state of
   the LSP segment N1-N2-N3 to PCE1. In domain 2, the border node (i.e.,
   N7) SHOULD synchronize the state of the LSP segment N7-N8-N9 to PCE2.

   This approach requires that N7 has a PCEP adjacency with its PCE
   (PCE2), i.e. setting up a PCEP session, for LSP state
   synchronization purpose even if no path computation expansions are
   required. N7 needs to check whether its RSVP-TE upstream node
   belongs to another domain and notify the PCE when the LSP is
   released. Note that synchronization may require detailed information
   of the LSP (e.g., a full record route, the actual reserved resources)
   which may only be available during Resv message processing.

   Alternatively, inter-PCE communication strategy can be adopted for
   LSP-DB synchronization. For instance, in Figure 1, upon the
   notification of the setup of LSP N1-N2-N3-N7-N8-N9, PCE1 can
   establish a PCEP adjacency to inform PCE2 to update its LSP-DB. This
   method SHOULD be preferred only when PCE1 has sufficient and valid
   information of the across-domain LSP, such as explicit LSP
   information. Otherwise, the method in which the border node(s) are
   in charge of LSP state update is more appropriate. For example,

Zhang                    Expires April 2013                   [Page 7]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   Backward Recursive Path Computation (BRPC) [RFC5441] in conjunction
   with path-key-based mechanism [RFC5520] can be adopted for inter-
   domain path computation. If this is the case with the example in
   Figure 1, PCE1 only acquires a loose LSP path (e.g., N1-N2-N3-N7-
   KEY1, where KEY1 can be interpreted only by PCE2). Since it depends
   on the local policy that how long a Path-Key should be stored, KEY1
   might not be valid anymore when it is used by PCE1 for PCE2 LSP-DB
   update notification. In this case, N7 will need to request PCE2 to
   unlock the Path-Key in order to complete the signaling process.
   Therefore, it is possible to use N7 instead for updating PCE2 LSP-DB.

   Note that a timely synchronization of PCEs and these two databases
   is a prerequisite to maintaining a good performance of a stateful

   To benefit from stateful PCE, during inter-domain path computation
   procedure, PCC and cooperating PCEs should try to select stateful
   PCE when multiple PCEs (stateful and stateless) are available in the
   domain. This will enable correct end-to-end path computation using
   of TED and LDP-DB in all domains. In case of unavailability of
   stateful PCE, stateless PCE can still be used to provide the inter-
   domain path computation.

   The inter-domain LSP synchronization as explained in this section is
   still applicable if some domain does not have stateful PCE support.
   All the domains with a stateful PCE present should synchronize their
   segment at the least.

2.2.3. Multi-layer

   In multi-layer scenarios, one node/domain may have multiple
   switching capabilities. For instance, Optical Transport Network (OTN)
   nodes may have both of electrical (e.g., ODU1, ODU2, ODU3) and
   optical switch capabilities. ODU LSPs and wavelength LSPs may be
   established in an OTN network.

   In such networks, a PCE may have the capability of performing single
   layer path computation or multi-layer path computation. If a
   stateful PCE has single layer path computation capability, the nodes
   should be aware of information pertaining to which layer should be
   synchronized to a specific PCE. Otherwise, the state of the LSPs in
   all layers should be synchronized to the single stateful PCE.

2.3. PCE Survivability/Reliability

   Since a PCE supports a centralized path computation model, its
   survivability should be carefully considered to ensure its proper
   operation. If a multiple stateful PCE model is used and these PCEs

Zhang                    Expires April 2013                   [Page 8]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   have a consistent view of the network, they can act as a hot backup
   for each other. Otherwise, other backup strategies SHOULD be present
   if only one PCE is deployed in the network to avoid a single point
   of failure.

2.4. Impact on Existing PCEP Operations

   For a stateful PCE, LSP state information is readily available. Thus,
   it is possible to allow a lighter information exchange of PCC and
   PCE for path computation, as compared to that of a stateless PCE.
   For instance, instead of detailed LSP information (such as route,
   bandwidth information etc.), only an global unique identifier is
   required for a stateful PCE to process the request. Therefore, due
   to this simplification, modification of the operations specified in
   [RFC5440] should be captured. This is specified in protocol-specific
   extension document [stateful-PCEP-gmpls].

2.5. Delegation and Policy

   Stateful PCE(s) are still subject to policies when performing path
   computation based on TED and LSP-DB as well as in what concerns LSP-
   DB organization and maintenance.

   For LSP-DB maintenance, a basic function of stateful PCEs that
   SHOULD be supported is the ability to keep LSP state information in
   the network within which they have visibility. This is termed as a
   passive stateful PCE in [stateful-PCEP-mpls]. OPTIONALLY, a stateful
   PCE can also extend its ability to support modification of LSP state
   information. This can be realized by obtaining the temporal LSP
   state control through negotiation with LSRs (i.e., LSP delegation).
   This is termed as an active stateful PCE in [stateful-PCEP-mpls].
   Please note that LSP state delegation should comply with the policy
   imposed by LSP state owner (i.e., LSRs) as well as the policy
   imposed upon PCE(s).

2.5.1. Use of Under-construction LSPs Information

   The TED and/or LSP-DB information retained by a stateful PCE might
   be out-of-syn. If this is the case, it might cause resource
   contention when the PCE computes paths based of the out-of-date
   information. Some sources of the potential TED/LSP-DB inaccuracy are:

      o Control plane link latencies. Such latencies may be increased
   due to several factors such as:

         a) The time required for a PCC to obtain the paths after a
         successful computation, requiring several Round-Trip-Times
         (RTT) as per TCP;

Zhang                    Expires April 2013                   [Page 9]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

         b) The setup delay;

         c) The time it takes for the PCE to update the local TED given
         IGP update times;

      o The routing and topology dissemination protocol (i.e. OSPF-TE),
   which may operate with timers for LSA updates, to avoid excessive
   control plane overhead.

      o Concurrent requests that arrive during the time window, between
   a response is sent and the LSP is setup and the topology changes are
   flooded. Even for very fast networks with low latency, there may be
   a batched of requests: several path computation requests within a
   PCReq message or, in dynamic restoration without pre-planning,
   several LSPs that need to be rerouted so as to avoid a failed link.

      o Local PCE contention, where the PCE needs to concurrently serve
   path computation requests and update the LSA (e.g. parsing OSPF-TE
   LSA updates). A PCE implementation may need to find a trade-off,
   when synchronizing access to the local TED: favor OSPF-TE parsing
   which means that some path computations are slightly delayed to
   allow an 'update' to be processed, or give strict priority to
   computation requests.

      In consequence, a PCE may assign the same (or a subset of the
   same) resources to several requests. Thus, it may result in
   contention and degraded network performance since it might cause
   path setup failure and excessive crank-backs.

      Therefore, information of the LSPs that are under construction
   can be used together with the TED and LSP-DB by a stateful PCE to
   reduce the path blocking and crank-backs issues. For example, the
   PCE can retain some context from paths it has recently computed so
   that it avoids suggesting the use of the same resources for other TE
   LSPs, using heuristics / statistic or forecasting for improved
   resource (i.e. wavelength) allocation.  In other words, a given PCE
   implementation may decide to perform additional book-keeping and
   management of resources strategies using the information of under
   construction LSPs, deploying policies that prevent sub-optimal
   allocations.  For instance, a PCE may compute the mean time used to
   update the TED based on the previous calculated TE-LSPs and TED
   updates.  Those kinds of mechanisms may reduce the TED inaccuracy
   but in all cases they cannot infer the PCC use of the TE-path.

Zhang                    Expires April 2013                  [Page 10]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

3. Application Scenarios

   In this section, several examples exploiting the capabilities of
   stateful PCE(s) are presented, although the application of stateful
   PCE(s) is not limited to them. In general, stateful PCE(s) can be
   deployed for applications where LSP state as well as traffic
   engineering information in the network are necessary inputs to
   achieve one or multiple of the following goals:

   o  Improving the performance such as reducing network blocking
      probability, achieving load balancing, improve network resources
      utilization or increasing the route computation success rate;

   o  Reducing the complexity of the relevant procedure(s) associated
      with the application(s);

   o  Lowering resource consumption;

   As discussed in [PSU-WSON] and [LCA-Stateless], some of the
   objectives can be achieved through limited LSP awareness in
   stateless PCE by exploiting objects defined in existing protocols,
   such as the SVEC object defined in [RFC5440] and/or XRO object
   defined in [RFC5521]. These methods are considered as transitional
   solutions because of two reasons. Firstly, these methods only have
   local/partial/temporal LSP related information and thus have limited
   utility in terms of achieving the goals, particularly for objectives
   set at a network level. Secondly, it might incur a substantial
   amount of overhead since it requires frequent message exchanges
   among PCC and PCE entities.

3.1. Impairment-Aware Routing and Wavelength Assignment (IA-RWA)

   In WSON networks [RFC6163], a wavelength-switched LSP traverses one
   or multiple 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

Zhang                    Expires April 2013                  [Page 11]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   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 PCE(s) are used to perform the IA-RWA
   procedure, it needs 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., [GEN-OSPF] and [WSON-OSPF], 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.

3.2. Defragmentation in Flexible Grid Networks

   Traditionally, in Dense Wavelength Division Multiplexing (DWDM)
   networks, the frequency and channel spacing for a single wavelength
   allocated to an optical connection is fixed, in terms of a fixed
   channel spacing grid. With the development of mixed-rate
   transmission and the increase in the speed of optical signal, the
   issue of poor optical spectrum usage needs to be addressed. Flexible
   grid is proposed to solve this problem [G.FLEXIGRID]. In Flexible
   grid networks, LSPs with different slot widths (such as 12.5G, 25G
   etc.) can co-exist so as to accommodate the services with different
   bandwidth requests.

   Yet another problem arises in this type of DWDM networks. Since in
   flexible grid networks LSPs are dynamically allocated and released
   over time, the optical spectrum resource becomes fragmented. The
   overall available spectrum resource on a link might be sufficient
   for a new LSP request. But if the available spectra are not
   continuous, the request would be rejected. In order to perform
   frequency defragmentation procedure, stateful PCE(s) COULD be used,

Zhang                    Expires April 2013                  [Page 12]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   since existing TE LSPs information (i.e., slot width and spectrum
   location information associated with TE LSPs) is required to
   accurately assess spectrum resources on the LSPs, and perform de-
   fragmentation while ensuring a minimal disruption of the network,
   e.g., based on active LSP priorities.

   [Editor's note: it is not suggested to start PCEP extensions on this
   application until the data plane technology and the corresponding
   GMPLS control is mature.]

3.3. Recovery

3.3.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. In either way, the resources bound to backup paths
   can be shared by different LSPs to improve the overall network
   efficiency. 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. If such
   information is required on each network node, extensions to existing
   signaling or routing protocols are needed in order to carry the
   necessary information for avoiding allocating shared protection
   resources for two non-disjoint working LSPs. However, stateful PCE(s)
   can easily accommodate this need using the information stored in its
   LSP-DB, without requiring extensions to existing routing protocols.

                 |PCE |

            +------+          +------+          +------+
            |  N1  +----------+  N2  +----------+  N3  |
            +--+---+          +---+--+          +---+--+
               |                  |                 |
               |        +---------+                 |
               |        |                           |
               |     +--+---+          +------+     |
               +-----+  N5  +----------+  N4  +-----+
                     +------+          +------+

                         Figure 2: Example Network

Zhang                    Expires April 2013                  [Page 13]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   For example, in the network depicted in Figure 2, suppose there
   exists LSP1 (N1->N5) with backup route following N1->N2->N5. A
   request arrives asking for a working and backup path pair to be
   computed for a request from N2 to N5. If the PCE decides N2->N1->N5
   to be the best working route, then the backup path should not use
   the same protection resource with LSP1 since the new LSP shares part
   of its resource 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 to be the right candidate for undertaking
   the request.

3.3.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 2: (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,

Zhang                    Expires April 2013                  [Page 14]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   and specifies the new paths which should be used as the rerouting
   paths. To support this, it would require extensions to existing
   signaling protocol.

   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.

3.4. SRLG Diversity

   A common requirement is to maintain SRLG disjointness between LSPs.
   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 [RFC
   5521]. 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

   Using a stateful PCE allows the maintenance of the updated SRLG
   information of the established LSPs in a centralized manner. Having
   such information in the PCE facilitates the PCC to specify, as
   constraint to the path computation, the SRLG disjointess of a set of
   already established LSPs by only providing LSPs' identifiers.

3.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 to provide 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. Traditionally, a VNT manager (VNTM) is in
   charge of the topology in the upper layer by connections in the
   lower layer. Hence, when a stateless PCE is requested to compute a

Zhang                    Expires April 2013                  [Page 15]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   new TE link, it will need interaction with VNTM for detailed TE link
   information. To be more specific, without detailed LSP information,
   this process would be inefficient or even infeasible for stateless
   PCE(s), unless with cooperation with VNTM. On the other hand, a
   stateful PCE seems more suitable to make the decision of when and
   how to modify the VNT either to accommodate new LSP requests or to
   re-optimize resource use across layers irrespective of PCE models.
   As described in Section 2.2, path computation for a VNT change can
   be performed by the PCE if a single PCE model is adopted. On the
   other hand, if a per-layer PCE model is more appropriate,
   coordination between PCEs is required.

3.6. Global Concurrent Optimization (GCO)

   GCO is introduced in [RFC5557] to calculate multiple paths
   concurrently so as to improve network resource efficiency. By taking
   into consideration the network topology as well as existing TE LSPs
   information, GCO can (re)optimize the entire network simultaneously.
   Alternatively, GCO can be applied to (re)optimize one or a subset of
   existing TE LSPs or plan for forthcoming LSP(s) with specific
   objectives. GCO can also support off-line one-time optimization
   (i.e., planning) given a traffic matrix and network topology. Due to
   its complexity and potentially high computational demand, it is
   recommended to be performed in a centralized way (e.g., based on a
   management-based PCE).

   In case of a stateless PCE, in order to optimize network resource
   usage dynamically through online planning, PCC (e.g., NMS) should
   send a request to PCE together with detailed path/bandwidth
   information of the LSPs that need to be concurrently optimized. This
   would require a PCC (e.g., NMS) to determine when and which LSPs
   should be optimized. Given all of the existing LSP state information
   kept at a stateful PCE, it allows automation of this process without
   the PCC (e.g. NMS) to supply the existing LSP state information.
   Moreover, since a stateful PCE can maintain the information
   regarding to all LSPs that are currently under signaling, it makes
   the optimization procedures be performed more intelligently and

3.7. Point-to-Multipoint (P2MP) Application

   Route computation for P2MP application involves selection of
   branching points together with calculating multiple sub-LSPs with
   certain objective(s) such as minimizing the overall cost of the P2MP
   tree. Moreover, egress nodes addition and removal in a P2MP tree
   necessitates (re)optimization. Besides these, there are also some
   constraints and policies that make the P2MP tree computation hard,

Zhang                    Expires April 2013                  [Page 16]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   requiring high computation power. Therefore, PCE is proposed to
   support P2MP application [RFC5671].

   If a stateless PCE is used for P2MP calculation or optimization
   under constraints such as load balancing or path disjointedness,
   then a large amount of sub-LSP information might need to be
   exchanged between the PCE and the requesting entities. Moreover, if
   the requesting entity cannot provide complete information of sub-
   LSPs pertaining to the P2MP tree, then the performance of stateless
   PCE will be sub-optimal. On the contrary, a stateful PCE can support
   the P2MP tree computation/optimization with reduced overhead and
   improved efficiency.

3.8. Time-based Scheduling

   Time-based scheduling allows network operators to reserve resources
   in advance upon request from the customers to transmit large bulk of
   data with specified starting time and duration, such as in support
   of scheduled data transmission 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 stateful PCE can support this application with better efficiency
   since it can alleviate the burden of processing on network elements
   as well as enable the flexibility of resources usage by only
   excluding the time slot(s) reserved for time-based scheduling
   requests. In order to support this application, a stateful PCE
   should also maintain a database that stores all the reserved
   information with time reference. This can be achieved either by
   maintaining a separate database or incorporated into LSP-DB. The
   details of organizing time-based scheduling related information as
   well as its impact on LSP-DB is subject to network provider's policy
   and administrative consideration and thus outside of the scope of
   this document.

4. Manageability Considerations

   The description and functionality specifications presented related
   to stateful PCE(s) should also comply with the manageability
   specifications covered in Section 8 of [RFC4655]. Furthermore, a

Zhang                    Expires April 2013                  [Page 17]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   further list of manageability issues presented in [Stateful-PCEP-
   mpls] may also be considered. Information and Data Models

   A Management Information Base (MIB) module for management of the
   PCEP is being specified in a separate document [PCEP-MIB].  That MIB
   module allows examination of individual PCEP messages, in particular
   requests, responses and errors.  The MIB module MUST be extended to
   include the ability to view stateful PCE PCEP extensions defined in
   relevant documents.

5. Security Considerations

   The security issues presented in [RFC5440] still applies to this
   document. In addition, the security concerns raised by [Stateful-
   PCEP-mpls] may also be considered.

6. References

6.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
             requirements levels", RFC 2119, March 1997.

   [RFC4655] Farrel, A., Vasseur, J.-P., and Ash, J., "A Path
             Computation Element (PCE)-Based Architecture", RFC 4655,
             August 2006.

   [RFC5440] Vasseur, J.-P., and Le Roux, JL., "Path Computation
             Element (PCE) Communication Protocol (PCEP)", RFC 5440,
             March 2009.

   [RFC6163] Lee, Y., Bernstein, G., "Framework for GMPLS and Path
             Computation Element (PCE) Control of Wavelength Switched
             Optical Networks (WSONs)", RFC 6163, April, 2011.

   [RFC5521] Oki, E., Farrel, A., "Extensions to the Path Computation
             Element Communication Protocol (PCEP) for Route
             Exclusions", RFC5521, April 2009.

6.2. Informative References

   [WSON-Impairment] Lee, Y., Bernstein, G., Li, D., Martinelli, G., "A
             Framework for the Control of Wavelength Switched Optical
             Network (WSON) with Impairments", draft-ietf-ccamp-wson-
             impairments, work in progress.

Zhang                    Expires April 2013                  [Page 18]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   [RFC4726] Farrel, A., Vasseur, J.-P., Ayyangar, A., "A Framework for
             Inter-Domain Multiprotocol Label Switching Traffic
             Engineering", RFC 4726, November 2006.

   [RFC5520] Bradford, R., Vasseur, JP., Farrel, A., "Preserving
             Topology Confidentiality in Inter-Domain Path Computation
             Using a Path-Key-Based Mechanism", RFC 5520, April 2009.

   [RFC5441] Vasseur, J.-P., Zhang, R., Bitar, N., Le Roux, JL., "A
             Backward-Recursive PCE-Based Computation (BRPC) Procedure
             to Compute Shortest Constrained Inter-Domain Traffic
             Engineering Label Switched Paths", RFC 5441, April 2009.

   [PSU-WSON] Giorgetti, A, Cugini, G, et al, "Path state-based update
             of PCE traffic engineering database in wavelength switched
             optical networks", IEEE Com. Let., June 2010.

   [LCA-Stateless] Gonzalez de Dios, O., et al, "Benefits of limited
             context awareness in stateless PCE", Optical Fiber
             Communication Conference, March 2011.

   [WSON-OSPF] Lee, Y., Bernstein, G., "GMPLS OSPF Enhancement for
             Signal and Network Element Compatibility for Wavelength
             Switched Optical Networks", draft-ietf-ccamp-wson-signal-
             compatibility-ospf-07, October 2011.

   [GEN-OSPF] Zhang, Fatai, Lee, Y., Han, Jianrui, Bernstein, G., Xu,
             Yunbin, "OSPF-TE Extensions for General Network Element
             Constraints", draft-ietf-ccamp-gmpls-general-constraints-
             ospf-te-02, September 2011.

   [G.FLEXIGRID] Draft revised G.694.1 version 1.3, Unpublished ITU-T
             Study Group 15, Question 6.

   [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
             M., Brungard, D., "Requirements for GMPLS-Based Multi-
             Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July

   [RFC5557] Lee, Y., Le Roux, JL., King, D., Oki E., "Path Computation
             Element Communication Protocol (PCEP) Requirements and
             Protocol Extensions in Support of Global Concurrent
             Optimization", RFC 5557, July, 2009.

   [RFC5671] Yasukawa, S., Farrel, A., "Applicability of the Path
             Computation Element (PCE) to Point-to-Multipoint (P2MP)
             MPLS and GMPLS Traffic Engineering (TE)", October, 2009.

Zhang                    Expires April 2013                  [Page 19]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   [RFC5623] Oki, E., Takeda, T., Le Roux, JL., Farrel, A., "Framework
             for PCE-Based Inter-Layer MPLS and GMPLS Traffic
             Engineering", RFC5623, September 2009.

   [stateful-PCEP-mpls] Crabbe, E., Medved, J., Varga, R., Minei, I.,
             ''PCEP Extensions for Stateful PCE'', draft-ietf-pce-
             stateful-pce, work in progress.

   [stateful-PCEP-gmpls] Zhang, X., Lee, Y., Casellas, R., Gonzalez de
             Dios, O., '' Path Computation Element (PCE) Protocol
             Extension for Stateful PCE Usage in GMPLS Networks'',
             draft-zhang-pce-pcep-stateful-pce-gmpls, work in progress

   [PCEP-MIB] Kiran Koushik, A S., Stephan, E., Zhao, Q., King, D.,
             "PCE communication protocol (PCEP) Management Information
             Base", draft-ietf-pce-pcep-mib, work in progress

   [PCEP-GMPLS] C. Margaria O. Gonzalez de Dios F. Zhang  ''PCEP
             extensions for GMPLS''  draft-ietf-pce-gmpls-pcep-
             extensions-06  work in progress.

   Contributors' Address

Zhang                    Expires April 2013                  [Page 20]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   Dhruv Dhody
   Huawei Technology
   Leela Palace
   Bangalore, Karnataka 560008

   EMail: dhruvd@huawei.com

   Xiaobing Zi
   Huawei Technologies
   F3-5-B R&D Center, Huawei Base
   Bantian, Longgang District
   Shenzhen 518129 P.R.China

   Phone: +86-755-28973229
   Email: zixiaobing@huawei.com

Authors' Addresses

   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

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

   Phone: +86-755-28972913
   Email: zhang.xian@huawei.com

   Young Lee
   1700 Alma Drive, Suite 100
   Plano, TX  75075

Zhang                    Expires April 2013                  [Page 21]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   Phone: +1 972 509 5599 x2240
   Fax:   +1 469 229 5397
   EMail: ylee@huawei.com

   Ramon Casellas
   CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
   Av. Carl Friedrich Gauss n7
   Castelldefels, Barcelona 08860

   Email: ramon.casellas@cttc.es

   Oscar Gonzalez de Dios
   Telefonica Investigacion y Desarrollo
   Emilio Vargas 6
   Madrid,   28045

   Phone: +34 913374013
   Email: ogondio@tid.es

Intellectual Property

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology
   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line
   IPR   repository at http://www.ietf.org/ipr

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement

Zhang                    Expires April 2013                  [Page 22]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions
   of   these Legal Provisions that are published by third parties,
   including   those that are translated into other languages, should
   not be   considered to be definitive versions of these Legal

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect
   and   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.

Disclaimer of Validity

   All IETF Documents and the information contained therein are
   provided   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION

Full Copyright Statement

   Copyright (c) 2012 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

Zhang                    Expires April 2013                  [Page 23]

draft-zhang-pce-stateful-pce-app-02.txt                    October 2012

   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.

Zhang                    Expires April 2013                  [Page 24]

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