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: January 07, 2013                            July 07, 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 January 07, 2013.


Zhang                   Expires January 2013                  [Page 1]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 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 exhibits
   superiority in facilitating 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, with regard to stateful PCE usage in GMPLS networks.

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. PCEP Simplification .....................................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) .......................................... 9
   3. IANA Considerations ........................................ 10
      3.1. LayerCapability TLV.................................... 10
      3.2. SERVICE-TIME Object.................................... 10
      3.3. Extension to METRIC Object............................. 10
   4. Manageability Considerations................................ 10
   5. Security Considerations..................................... 11
   6. References ................................................. 11
      6.1. Normative References................................... 11
      6.2. Informative References................................. 11

Zhang                   Expires January 2013                  [Page 2]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 2012

   7. Contributors' Address....................................... 12
   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 there are common aspects for stateful PCE PCEP
   extension in GMPLS networks with that in 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 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 January 2013                  [Page 3]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 2012

2. PCEP Extensions

2.1. Overview

   According to the description in [Stateful-APP], a summary of PCEP
   extensions required for stateful PCE in GMPLS networks is provided
   as follows:

   o Advertisement and negotiation of stateful PCE capability;

   o LSP synchronization;

   These two are fundamental extension requirements needed in order to
   make a stateful PCE functional. 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].

   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 Simplification of the existing PCEP protocol [RFC5440];

   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.

   o Application-specific extensions desired;

   A list of examples is provided in [Stateful-APP] and they may
   require additional extensions or modification of the PCEP protocol.
   In this draft, we present the PCEP extensions for some typical
   application examples.

2.2. PCEP Extension for Stateful PCE Capability Advertisement and

   Whether a PCE has the 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 January 2013                  [Page 4]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 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

   If a LSP span across multiple domains and the delegation features
   presented in [Stateful-PCE] is supported, it adds complexity to LSP
   state synchronization/update. For instance, in a multi-domain
   networks where one PCE per domain is adopted, a contiguous LSP is
   setup which spans across multiple domains. Then, each PCE is
   responsible for synchronizing/updating or is able to modify only
   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 of additional

   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(?).

Zhang                   Expires January 2013                  [Page 5]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 2012

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

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.  PCEP Simplification

   One of the merits mentioned in [Stateful-APP] is its ability to
   simplify the information exchange between PCC and PCE. To be more
   specific, with a stateful PCE, it is possible for PCCs to carry only
   LSP ID information, instead of giving detailed LSP information (such
   as route), whenever necessary.

   Example 1: a PCC (e.g. NMS) requesting for a re-optimization of
   several LSPs, it can send the request with relevant LSP IDs.

   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

Zhang                   Expires January 2013                  [Page 6]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 2012

   correlate with one or multiple LSPs with their detailed state
   information and carry out optimization accordingly.

   Example 2: in order to set up a LSP which is diversified with one or
   more specific LSPs, a PCC can send a PCReq with the ID 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.

   In order to support this, a new subobject type should be supported,
   i.e. LSP ID(s). 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

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

Zhang                   Expires January 2013                  [Page 7]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 2012

   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

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

     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>


Zhang                   Expires January 2013                  [Page 8]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 2012



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


     <request >::=<RP>











   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.

Zhang                   Expires January 2013                  [Page 9]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 2012

   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.

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


Zhang                   Expires January 2013                 [Page 10]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 2012

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

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

Zhang                   Expires January 2013                 [Page 11]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 2012

7. Contributors' Address

   Dhruv Dhody
   Huawei Technology
   Leela Palace
   Bangalore, Karnataka 560008


Zhang                   Expires January 2013                 [Page 12]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 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 January 2013                 [Page 13]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 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 January 2013                 [Page 14]

draft-zhang-pce-pcep-stateful-pce-gmpls-00.txt                July 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 January 2013                 [Page 15]