Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks

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

Expires: April 17, 2013                                 October 18, 2012

   Path Computation Element (PCE) Protocol Extension for Stateful PCE
                        Usage in GMPLS Networks


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 April 2013                   [Page 1]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

   The Path Computation Element (PCE) facilitates Traffic Engineering
   (TE) based path calculation in large, multi-domain, multi-region, or
   multi-layer networks. PCE can be stateless or stateful. With the LSP
   state information acquired from the network, a stateful PCE enables
   a wide variety of applications, especially in GMPLS networks, such
   as impairment-aware routing and wavelength assignment in wavelength-
   switched optical networks (WSON), time-based scheduling applications.
   This memo provides extensions required for PCE communication
   protocol (i.e. PCEP) so as to enable the usage of a stateful PCE
   capability in GMPLS networks. To be more specific, the PCEP
   extensions specified in this memo include not only new objects but
   also modification of existing objects in PCEP messages.

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. PCEP Extensions ............................................. 4
      2.1. Overview ............................................... 4
      2.2. PCEP Extension for Stateful PCE Capability Advertisement and
      Negotiation ................................................. 4
         2.2.1. PCE Capability Negotiation/Advertisement in Multi-layer
         Networks ................................................. 5
      2.3. LSP Delegation ......................................... 5
      2.4. PCEP Extensions for LSP Synchronization .................6
      2.5. Modification of Existing PCEP Messages and Procedures....6
      2.6. Application-specific PCEP extensions for stateful PCE....7
         2.6.1. Time-based Scheduling.............................. 7
   PCEP Extension................................ 8
         2.6.2. RWA in Impairment-aware Wavelength-switched Optical
         Networks (WSON) ......................................... 10
   3. IANA Considerations ........................................ 11
      3.1. LayerCapability TLV.................................... 11
      3.2. SERVICE-TIME Object.................................... 11
      3.3. Extension to METRIC Object............................. 11
   4. Manageability Considerations................................ 11
   5. Security Considerations..................................... 11
   6. References ................................................. 11
      6.1. Normative References................................... 11
      6.2. Informative References................................. 11
   7. Contributors' Address....................................... 12

Zhang                   Expires April 2013                  [Page 2]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

   Authors' Addresses ............................................ 13

1. Introduction

   [RFC 4655] presents the architecture of a Path Computation Element
   (PCE)-based model for computing 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 route to the requesting PCC in response to a previously
   received PCReq message through a PCEP Path Computation Reply (PCRep)

   As per [RFC 4655], a PCE can be stateless or stateful. Compared to a
   stateless PCE, a stateful PCE stores not only the network state, but
   also the set of computed paths and reserved resources in use in the
   network. Note that [RFC4655] further specifies that the TED contains
   link state and bandwidth availability as distributed by IGPs or
   collected via other means. Even if such information can provide
   finer granularity and more details, it is not state information in
   the PCE context and so a model that uses it is still described as a
   stateless PCE.

   Stateful PCE(s) are shown to be helpful in many application
   scenarios, especially in GMPLS networks, as illustrated in
   [Stateful-APP]. In order for these applications to able to exploit
   the capability of stateful PCE(s), extensions to the PCE
   communication protocol (i.e., PCEP) are required.

   It is expected that the PCEP extensions enabling stateful PCEs in
   GMPLS networks will share common aspects with the extensions
   developed for MPLS networks [Stateful-PCE]. Therefore, this document
   focuses on the extensions unique to GMPLS networks while maintains a
   complete picture of the PCEP extensions required for a stateful PCE
   in general. In summary, this draft gives an overview of PCEP
   extensions necessary for stateful PCE usage in GMPLS networks as
   well as the details of required PCEP extension unique to stateful
   PCE usage in GMPLS networks.

Zhang                   Expires April 2013                  [Page 3]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

2. PCEP Extensions

2.1. Overview

   According to the description in [Stateful-APP], the PCEP extensions
   required for a stateful PCE in GMPLS networks should cover, at least,
   the following two main functional requirements:

   o Advertisement and negotiation of stateful PCE capability;

   o LSP synchronization;

   Attention should be paid in terms of the general considerations as
   discussed in [Stateful-APP]. Since the extensions to these two
   aspects are straightforward and have already been covered in
   [Stateful-PCE], we only cover the points that are either relevant to
   GMPLS or still missing in [Stateful-PCE].

   In addition, the next functional requirements

   o LSP Delegation;

   As explained in [Stateful-APP], the ability to collect LSP state
   information should be mandatory. As for PCE's ability to modify the
   LSP attributes as presented in [Stateful-PCE] as well as how it is
   enabled (per PCE base, per LSP base, or per NE base?) should be
   operator-dependent and is for further study.

   o Application-specific extensions;

   [Stateful-APP] identifies the applications that a stateful PCE
   enables. Such applications require PCEP extensions that are provided
   in this document.

   Since the LSP state is part of the information that a stateful PCE
   possesses, some simplifications to PCEP are possible and explained
   in this draft.

2.2. PCEP Extension for Stateful PCE Capability Advertisement and

   Whether a PCE has stateful capability or not can be negotiated
   during the PCEP session establishment process. It can also be
   advertised through routing protocols as described in [RFC5088]. In
   either case, the following additional aspects should also be

Zhang                   Expires April 2013                  [Page 4]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

 2.2.1. PCE Capability Negotiation/Advertisement in Multi-layer Networks

   In multi-layer network scenarios where there is a PCE responsible
   for each layer, then the PCCs should be informed of which PCE they
   should synchronize their LSP states with as well as send path
   computation requests to.

   A new LayerCapability TLV is defined as shown below to denote to
   which layer a PCE is in charge of LSP synchronization as well as
   path computation. It can be included in the OPEN Object if
   applicable. Alternatively, the extension to current OSPF PCED TLV is

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |       Type (T.B.D.)           |           Length              |
   | LSP Enc. Type | Switching Type|             Reserved          |
   |                               ...                              |
   | LSP Enc. Type | Switching Type|             Reserved          |

2.3. LSP Delegation

   The LSP state synchronization/update capability for LSPs that span
   multiple domains adds additional complexity for the stateful PCE(s).
   For instance, in a multi-domain networks where one PCE per domain is
   adopted, each PCE is responsible for synchronizing, updating or
   modifying the segment or part of the LSP within the network for
   which the PCE is deployed. Moreover, a modification action of a
   stateful PCE for partial LSP may trigger a chain of LSP updating
   actions (e.g., informing other PCEs of the modification or
   requesting other PCEs for additional modification).

   This needs to be considered carefully and modification capability
   specifications might be needed to limit the scope of LSP attribute
   modification action to avoid conflicts.

   [Editor Note: this needs clarification and further discussion. The
   scenario with mixed stateful/stateless PCE might also cause
   potential issues for LSP delegation ability. A use case and clearly

Zhang                   Expires April 2013                  [Page 5]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

   defined requirements are needed so not to try to cover all possible
   cases, in view of concrete implementations]

2.4. PCEP Extensions for LSP Synchronization

   For LSP state synchronization of stateful PCE(s) in GMPLS networks,
   the LSP attributes, such as its bandwidth, associated label as well
   as protection information etc, should be updated by PCC(s) to PCE
   LSP database (LSP-DB).

   As per [Stateful-PCE], it only covers LSP attributes pertaining to
   MPLS networks, based on [RFC5440]. Therefore, extensions of PCEP
   protocol for stateful PCE usage in GMPLS networks are required. The
   following presents a list of objects/TLVs that should be used by
   stateful PCE for LSP synchronization purpose when applied in GMPLS



   o Extended Objects to support the inclusion of label sub-object

      - RP

     - IRO

     - XRO

   Note that the list above should also be used for path computation
   requests/replies. Refer to [PCEP-GMPLS] for the details of these

2.5.  Modification of Existing PCEP Messages and Procedures

   One of the advantages mentioned in [Stateful-APP] is that the
   stateful nature of a PCE simplifies the information conveyed in PCEP
   messages, notably between PCC and PCE, since it is possible to refer
   to PCE managed state for active LSPs. To be more specific, with a
   stateful PCE, it is possible to refer to a LSP with a unique
   identifier in the scope of the PCC-PCEP session and thus use such
   identifier to refer to that LSP.

   Example 1: a PCC (e.g. NMS) requesting for a re-optimization of one
   or several LSPs can send the request with ''R'' bit set and only
   provides the relevant LSP unique identifier(s).

Zhang                   Expires April 2013                  [Page 6]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

   In order to support these, the LSP identifier TLV defined in
   [Stateful-PCE] can be used in the RP Object to specify the request
   LSP ID(s). Upon receiving the PCReq message, PCE should be able to
   correlate with one or multiple LSPs with their detailed state
   information and carry out optimization accordingly. The handling of
   RP object specified in [RFC5440] is stated as following:

   ''The absence of an RRO in the PCReq message for a non-zero-bandwidth
   TE LSP (when the R bit of the RP object is set) MUST trigger the
   sending of a PCErr message with Error-Type="Required Object Missing"
   and Error-value="RRO Object missing for reoptimization."

   If a PCE has stateful capabilities, and such capabilities have been
   negotiated and advertised, specific rules given in [RFC5440] may
   need to be relaxed. In particular, the re-optimization case: if the
   re-optimization request refers to a given LSP state, and the RRO
   information is available, the PCE can proceed.

   Example 2: in order to set up a LSP which has a constraint that its
   route should not use resources used by one or more existing LSPs, a
   PCC can send a PCReq with the identifier(s) of these LSPs. A
   stateful PCE should be able to find the corresponding route and
   resource information so as to meet the constraints set by the
   requesting PCC. Hence, the LSP identifier TLV defined in [Stateful-
   PCE] can be used in XRO object for this purpose.

2.6.  Application-specific PCEP extensions for stateful PCE

   [Editor's Note: this is not a complete list of application-specific
   PCEP extensions. Suggestions are welcome on expansion on this

 2.6.1. Time-based Scheduling

   [Editor's note: synchronization is complex and we cannot assume that
   the PCE and PCC clocks are equal and issues such as whether it
   should be kept centralized or not will be reflected in the later

   To support time-based scheduling, network operators need to reserve
   resources in advance according to customers' requests with specified
   starting time and duration. A simple utilization example of this
   service is to support scheduled data transmission between data
   centers or any generic scheduled based services.

   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

Zhang                   Expires April 2013                  [Page 7]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

   established paths exclude the possibility of being used by other
   services even when they are not used for undertaking any service due
   to the lack of a time-based mechanism. 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.

   Since a stateful PCE needs to collect LSP related information for
   the whole network, it can naturally support this service with
   resource usage flexibility (i.e., only excluding the time slot(s)
   reserved for time-based scheduling requests). Moreover, it can avoid
   the need to add complexity on network elements in this regard. 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 having all the reserved
   information with time reference incorporated into LSP-DB. The
   details of organizing time-based scheduling related information are
   subject to network provider's policy and administrative
   consideration and thus outside of the scope of this document. PCEP Extension

   For a PCC to request a path computation for scheduled service, it
   MUST be able to specify the time-related information, including the
   starting time and LSP holding time, in PCEP request.

   A SERVICE-TIME object is presented as follows to provide the
   required information (i.e. service starting time and holding time).

   The Object-Class is TBD and the Object-Type is 1.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |       Start-Year              |    Month      |     Day       |
   |     Hour      |    Minute     |    Second     |   Reserved    |
   |                       Duration (in seconds)                   |

     field      Length       range

      -----      ------     --------

Zhang                   Expires April 2013                  [Page 8]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

     Start-Year  16 bit    0..65536

     Month       8 bit     1..12

     Day         8 bit     1..31

     Hour        8 bit     0..23

     Minute      8 bit     0..59

     Second      8 bit     0..59

   The SERVICE-TIME object can be included in a PCEP request as
   specified in the following manner:

   <PCReq Message>::=<Common Header>




      [<svec-list>]::= <SVEC> [<svec-list>]


     <request >::=<RP>











Zhang                   Expires April 2013                  [Page 9]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

   Upon receiving the PCReq message, PCE should compute the path taking
   into consideration the constraints of the TED, LSP-DB as well as
   other scheduled service information and return the computed route
   back to the requesting PCC. If no path can be found, PCE should
   return an error message specifying the reason.

 2.6.2. RWA in Impairment-aware Wavelength-switched Optical Networks

   In impairment-ware WSON networks, the routing and wavelength
   assignment process needs to consider the constraints incurred by the
   physical impairments. As described in [Stateful-APP], stateful PCE
   can effectively reduce the control plane overhead by centrally
   maintaining the impairment-information related to each LSP.

   In order to establish an impairment-aware LSP, a path computation
   request may need to specify the desired values and/or constraints
   for one or more of the following parameters:

   o Power

   o OSNR

   o PMD

   o T.B.D.

   Upon receiving the path computation request, a stateful PCE should
   take into consideration the explicitly defined constraints as well
   as those of the existing LSPs, stored in LSP-DB. Furthermore, a PCE
   may need to reply in PCRep with the actual values of the one or more
   of the above-mentioned parameters to the requesting PCC as well as
   the adjustment needed. After receiving the reply message, the PCC
   can take appropriate actions along the to-be-established paths in
   tuning its power or changing other impairment-related parameters so
   as to achieve the desired signal quality.

   To support the above-mentioned requirements, the METRIC object
   defined in [RFC5440] can be exploited with proper extension. A new
   type value should be added.

   T=T.B.D.: Impairment-aware information

   Furthermore, as described in [PCE-IA-WSON], there are two types of
   parameters that can be specified, i.e. path level or link level. If
   a stateful PCE needs to reply with adjustment needed for path level
   parameters. Then further extension to the METRIC object is desirable
   and this will be considered in the future.

Zhang                   Expires April 2013                 [Page 10]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

3. IANA Considerations

   IANA is requested to allocate new Types for the TLV/Object defined
   in this document.

3.1. LayerCapability TLV

3.2. SERVICE-TIME Object

3.3. Extension to METRIC Object

4. Manageability Considerations


5. Security Considerations


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.

   [RFC5088] Le Roux, JL., Vasseur, J.-P., Ikejiri, Y., Zhang, R.,
             ''OSPF Protocol Extensions for Path Computation Element
             (PCE) Discovery'', RFC 5088, April 2008.

6.2. Informative References

   [Stateful-APP] Zhang, F., Zhang, X., Lee, Y., Casellas, R., Gonzalez
             de Dios, O., "Applicability of Stateful Path Computation
             Element (PCE) ", draft-zhang-pce-stateful-pce-app, work in

Zhang                   Expires April 2013                 [Page 11]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

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

   [PCE-IA-WSON] Lee, Y., Bernstein G., Takeda, T., Tsuritani, T.,
             ''PCEP Extensions for WSON Impairments'', draft-lee-pce-
             wson-impairments, work in progress.

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

7. Contributors' Address

   Dhruv Dhody
   Huawei Technology
   Leela Palace
   Bangalore, Karnataka 560008


Zhang                   Expires April 2013                 [Page 12]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

Authors' Addresses

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

   Phone: +86-755-28972913

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

   Phone: +1 972 509 5599 x2240
   Fax:   +1 469 229 5397

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


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

   Phone: +34 913374013

Intellectual Property

Zhang                   Expires April 2013                 [Page 13]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012

   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

   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
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at

   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

Zhang                   Expires April 2013                 [Page 14]

draft-zhang-pce-pcep-stateful-pce-gmpls-01.txt             October 2012


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
   ( in effect on the date of
   publication of this document. Please review these documents
   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.

Zhang                   Expires April 2013                 [Page 15]