Skip to main content

Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage in GMPLS-controlled Networks
draft-ietf-pce-pcep-stateful-pce-gmpls-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9504.
Authors Xian Zhang , Young Lee , Fatai Zhang , Ramon Casellas , Oscar Gonzalez de Dios , Zafar Ali
Last updated 2015-07-05
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 9504 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-pce-pcep-stateful-pce-gmpls-03
PCE Working Group                                            Xian Zhang 
Internet-Draft                                                Young Lee 
Intended status: Standards Track                            Fatai Zhang 
                                                                 Huawei 
                                                         Ramon Casellas 
                                                                   CTTC 
                                                 Oscar Gonzalez de Dios 
                                                         Telefonica I+D 
                                                              Zafar Ali 
                                                          Cisco Systems 
                                                    
                                                                  
Expires: January 05, 2016                                 July 06, 2015 
                                      

                                    
   Path Computation Element (PCE) Protocol Extensions for Stateful PCE 
                   Usage in GMPLS-controlled Networks 
                                      
               draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt 

Abstract 

   The Path Computation Element (PCE) facilitates Traffic Engineering 
   (TE) based path calculation in large, multi-domain, multi-region, or 
   multi-layer networks. The PCE communication Protocol (PCEP) has been 
   extended to support stateful PCE functions where the PCE retains 
   information about the paths already present in the network, but 
   those extensions are technology-agnostic. This memo provides 
   extensions required for PCEP so as to enable the usage of a stateful 
   PCE capability in GMPLS-controlled 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-   
   Drafts. 

   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 

 
 
 
Zhang et al             Expires January 2016                  [Page 1] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

   as reference   material or to cite them other than as "work in 
   progress." 

   The list of current Internet-Drafts can be accessed at   
   http://www.ietf.org/ietf/1id-abstracts.txt. 

   The list of Internet-Draft Shadow Directories can be accessed at   
   http://www.ietf.org/shadow.html. 

   This Internet-Draft will expire on January 5, 2016. 

Copyright Notice 

   Copyright (c) 2015 IETF Trust and the persons identified as the    
   document authors.  All rights reserved. 

   This document is subject to BCP 78 and the IETF Trust's Legal 
   Provisions Relating to IETF Documents 
   (http://trustee.ietf.org/license-info) in effect on the date of 
   publication of this document. Please review these documents 
   carefully, as they describe your rights and restrictions with 
   respect 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. 

  

Conventions used in this document 

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

Table of Contents 

    
   Table of Contents .............................................. 2 
   1. Introduction ................................................ 3 
   2. PCEP Extensions ............................................. 3 
      2.1. Overview of Requirements................................ 3 
      2.2. LSP Delegation in GMPLS-controlled Networks ............. 4 
      2.3. LSP Synchronization in GMPLS-controlled Networks......... 5 
      2.4. Modification of Existing PCEP Messages and Procedures.... 6 
         2.4.1. Modification for LSP Re-optimization ............... 6 
         2.4.2. Modification for Route Exclusion ................... 7 
      2.5. Object Encoding......................................... 8 
   3. IANA Considerations ......................................... 8 
 
 
Zhang et al             Expires January 2016                  [Page 2] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

      3.1. New PCEP Error Codes.................................... 8 
      3.2. New Subobject for the Exclude Route Object ..............9 
   4. Manageability Considerations................................. 9 
      4.1. Requirements on Other Protocols and Functional Components 9 
   5. Security Considerations...................................... 9 
   6. Acknowledgement ............................................. 9 
   7. References ................................................. 10 
      7.1. Normative References................................... 10 
      7.2. Informative References................................. 10 
   8. Contributors' Address....................................... 10 
   Authors' Addresses ............................................ 12 
    
    

1. Introduction 

   [RFC4655] 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).  Such a 
   PCE is usually referred as a stateless PCE. To request path 
   computation services to a PCE, [RFC5440] defines the PCE 
   communication Protocol (PCEP) for interaction between a Path 
   Computation Client (PCC) and a PCE, or between two PCEs.  PCEP as 
   specified in [RFC 5440] mainly focuses on MPLS networks and the PCEP 
   extensions needed for GMPLS-controlled networks are provided in 
   [PCEP-GMPLS].  

   Stateful PCEs are shown to be helpful in many application scenarios, 
   in both MPLS and GMPLS networks, as illustrated in [Stateful-APP].  
   Further discussion of concept of a stateful PCE can be found in 
   [RFC7399].  In order for these applications to able to exploit the 
   capability of stateful PCEs, extensions to PCEP are required.  

   [Stateful-PCE] provides the fundamental extensions needed for 
   stateful PCE to support general functionality, but leaves out the 
   specification for technology-specific objects/TLVs. This document 
   focuses on the extensions that are necessary in order for the 
   deployment of stateful PCEs in GMPLS-controlled networks.  

2. PCEP Extensions  

2.1. Overview of Requirements 

    

 
 
Zhang et al             Expires January 2016                  [Page 3] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

   This section notes the main functional requirements for PCEP    
   extensions to support stateful PCE for use in GMPLS-controlled    
   networks, based on the description in [Stateful-APP].  Many    
   requirements are common across a variety of network types (e.g.,    
   MPLS-TE networks and GMPLS networks) and the protocol extensions to    
   meet the requirements are already described in [Stateful-PCE].  This    
   document does not repeat the description of those protocol   
   extensions.  This document presents protocol extensions for a set of    
   requirements which are specific to the use of a stateful PCE in a    
   GMPLS-controlled network. 

   The basic requirements are as follows: 

   o  Advertisement of the stateful PCE capability.  This generic 
      requirement is covered in Section 7.1.1. of [Stateful-PCE].  This 
      document does not provide any further extensions. 

   o  LSP delegation is already covered in Section 5.5. of [Stateful-
      PCE].  Section 2.3. of this document provides extension for its 
      application in GMPLS-controlled networks.  Moreover, further   
      discussion of some generic details that need additional 
      consideration is provided.  

   o  LSP state synchronization and LSP state report. This is a generic 
      requirement already covered in Section 5.4. of [Stateful-PCE].  
      However, there are further extensions required specifically for 
      GMPLS-controlled networks and discussed in Section 2.4.  Reference 
      to LSPs by identifiers is discussed in Section 7.3. of [Stateful-
      PCE].  This feature can be applied to reduce the data carried in 
      PCEP messages.  Use cases and additional Error Codes are necessary, 
      as described in Section 2.5. of this document. 

 
2.2. LSP Delegation in GMPLS-controlled Networks  

   [Stateful-PCE] defines the Path Computation LSP Update Request 
   (PCUpd) message to enable to update the attributes of an LSP. 
   However, that document does not define technology-specific 
   parameters. 

   A key element of the PCUpd message is the attribute-list construct   
   defined in [RFC5440] and extended by many other PCEP specifications. 

   For GMPLS purposes we note that the BANDWIDTH object used in the   
   attribute-list is defined in [PCEP-GMPLS].  Furthermore, additional 
   TLVs are defined for the LSPA object in [PCEP-GMPLS] and MAY be 
   included to indicate technology-specific attributes. 

 
 
Zhang et al             Expires January 2016                  [Page 4] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

   LSP parameter update controlled by a stateful PCE in a multi-domain    
   network is complex and requires well-defined operational procedures 
   as well as protocol design and is out of scope of this document and 
   left for further study. 

2.3. LSP Synchronization in GMPLS-controlled Networks 

   PCCs need to report the attributes of LSPs to the PCE to enable   
   stateful operation of a GMPLS network.  This process is known as   
   LSP state synchronization.  The LSP attributes include bandwidth,    
   associated route, and protection information etc., are stored by the   
   PCE in the LSP database (LSP-DB).  Note that, as described in    
   [Stateful-PCE], the LSP state synchronization covers both the bulk   
   reporting of LSPs at initialization as well the reporting of new or   
   modified LSP during normal operation. Incremental LSP-DB 
   synchronization may be desired in a GMPLS-controlled network and it 
   is specified in [Sync-OPT]. 

   [Stateful-PCE] describes mechanisms for LSP synchronization using 
   the Path Computation State Report (PCRpt) message, but does not 
   cover reporting of technology-specific attributes. As stated in 
   [Stateful-PCE], the <path> construct is further composed of a 
   compulsory ERO object and a compulsory attribute-list and a optional 
   RRO object. In order to report LSP states in GMPLS networks, this 
   specification allows the use within a PCRpt message of technology- 
   and GMPLS-specific attribute objects and TLVs defined in [PCEP-GMPLS] 
   as follows: 

      o Extensions to the ERO, RRO, IRO, and XRO to carry label sub-
   objects for SDH/SONET, OTN, and DWDM networks. 

       o Extended objects to support the inclusion of the label and      
   unnumbered links. 

      o END-POINTS (Generalized END-POINTS Object Type)  

      o BANDWIDTH (Generalized BANDWIDTH Object Type) 

      o PROTECTION ATTRIBUTE TLV 

      o IF_ID_ERROR_SPEC (extending [Stateful-PCE] section 7.3.4 that 
   only considers the use of RSVP ERROR_SPEC) 

   The END-POINTS object SHOULD be carried within the attribute-list to 
   specify the endpoints pertaining to the reported LSP. The XRO object 
   MAY be carried to specify the network resources that the reported 
   LSP avoids and a PCE SHOULD consider avoid these network resources 

 
 
Zhang et al             Expires January 2016                  [Page 5] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

   during the process of re-optimizing after this LSP is delegated to 
   the PCE.  To be more specific, the <attribute-list> is updated as: 

   <attribute-list> ::= [<END-POINTS>] 
                        [<LSPA>] 
                        [<BANDWIDTH>] 
                        [<metric-list>] 
                        [<IRO>] 
                        [<XRO>] 
    
   <metric-list>::= <METRIC>[<metric-list>] 

   If the LSP being reported protects another LSP, the PROTECTION-   
   ATTRIBUTE TLV [PCEP-GMPLS] MUST be included in the LSPA object to   
   describe its attributes and restrictions.  Moreover, if the status 
   of the protecting LSP changes from non-operational to operational, 
   this SHOULD to be synchronized to the stateful PCE using a PCRpt 
   message. 

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

 2.4.1. Modification for LSP Re-optimization 

   The Request Parameters (RP) object on a Path Computation Request   
   (PCReq) message carries the R bit.  When set, this indicates that    
   the PCC is requesting reoptimization of an existing LSP. Upon    
   receiving such a PCReq, a stateful PCE SHOULD perform the    
   reoptimization in the following cases:  

      - The existing bandwidth and route information of the LSP to be     
   reoptimized is provided in the PCReq message using the BANDWIDTH      
   object and the ERO.  

      - The existing bandwidth and route information is not supplied in 
   the PCReq message, but can be found in the PCE's LSP-DB.  In this 
   case, the LSP MUST be identified using an LSP identifier carried in 
   the PCReq message, and that fact requires that the LSP identifier 

 
 
Zhang et al             Expires January 2016                  [Page 6] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

   was previously supplied either by the PCC in a PCRpt message or by 
   the PCE in a PCRep.  [Stateful-PCE] defines how this is achieved 
   using a combination of the per-node LSP identifier (PLSP-ID) and the      
   PCC's address. 

   If no LSP state information is available to carry out    
   reoptimization, the stateful PCE should report the error "LSP state    
   information unavailable for the LSP reoptimization" (Error Type =      
   TBD1, Error value= TBD2). 

 2.4.2. Modification for Route Exclusion 

   [RFC5521] defines a mechanism for a PCC to request or demand that    
   specific nodes, links, or other network resources are excluded from   
   paths computed by a PCE.  A PCC may wish to request the computation    
   of a path that avoids all link and nodes traversed by some other LSP. 

   To this end this document defines a new sub-object for use with 
   route exclusion defined in [RFC5521].  The LSP exclusion sub-object 
   is as follows: 

       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 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |X|Type (TBD3) |     Length    |   Attributes  |    Flag        |  
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |               PLSP-ID                   |      Reserved       |  
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     
    
       X bit and Attribute fields are defined in [RFC5521].  
       X bit:  indicates whether the exclusion is mandatory (X=1) and 
   MUST be accommodated, or desired (X=0) and SHOULD be accommodated.  
    
      Type: Subobject Type for an LSP exclusion sub-object. Value of 
   TBD3. To be assigned by IANA.  
          
      Length: The Length contains the total length of the subobject in 
   bytes, including the Type and Length fields.  
    
      Attributes: indicates how the exclusion object is to be 
   interpreted. Currently, Interface (Attributes = 0), Node (Attributes 
   =1) and SRLG (Attributes =2) are defined in [RFC5521] and this 
   document does not define new values. 
    
      Flags: This field may be used to further specify the exclusion 
   constraint with regard to the LSP. Currently, no values are defined. 
    
 
 
Zhang et al             Expires January 2016                  [Page 7] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

      PLSP-ID: This is the identifier given to a LSP and is unique in 
   the context of the PCC address as defined in [Stateful-PCE]. 
    
     Reserved: MUST be transmitted as zero and SHOULD be ignored on 
   receipt. 
    
   This sub-object is OPTIONAL in the exclude route object (XRO) and 
   can be present multiple times.  When a stateful PCE receives a PCReq 
   message carrying this sub-object, it SHOULD search for the 
   identified LSP in its LSP-DB and then exclude it from the new path 
   computation all resources used by the identified LSP.  If the 
   stateful PCE cannot recognize one or more of the received LSP 
   identifiers, it should send an error message PCErr reporting "The 
   LSP state information for route exclusion purpose cannot be found" 
   (Error-type = TBD1, Error-value = TBD4).  Optionally, it may provide 
   with the unrecognized identifier information to the requesting PCC 
   using the error reporting techniques described in [RFC5440]. 

2.5. Object Encoding  

   Note that, as is stated in Section 7 of [Stateful-PCE], the P flag   
   and the I flag of the PCEP objects used on PCUpd and PCRpt messages   
   SHOULD be set to 0 on transmission and SHOULD be ignored on receipt   
   since these flags are exclusively related to path computation    
   requests. 

3. IANA Considerations 

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

3.1. New PCEP Error Codes 

   IANA is requested to make the following allocation in the "PCEP-
   ERROR Object Error Types and Values" registry.   

   Error Type        Meaning                                Reference 

   TBD1         LSP state information missing              [This.I-D] 

   Error-value TBD2:    LSP state information unavailable  [This.I-D] 

                     for the LSP re-optimization 

   Error-value TBD4:   LSP state information for route  

                    exclusion purpose cannot be found       [This.I-D] 

 
 
Zhang et al             Expires January 2016                  [Page 8] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

    

3.2. New Subobject for the Exclude Route Object 

   IANA maintains the "PCEP Parameters" registry containing a    
   subregistry called "PCEP Objects".  This registry has a subregistry   
   for the XRO (Exclude Route Object) listing the sub-objects that can   
   be carried in the XRO.  IANA is requested to assign a further sub-   
   object that can be carried in the XRO as follows: 

      Value       Description                    Reference  

   ----------+------------------------------+------------- 

      TBD3        LSP identifier sub-object     [This.I-D]  

4. Manageability Considerations 

   The description and functionality specifications presented related 
   to stateful PCEs should also comply with the manageability 
   specifications covered in Section 8 of [RFC4655]. Furthermore, a 
   further list of manageability issues presented in [Stateful-PCE] 
   should also be considered. 

   Additional considerations are presented in the next sections. 

4.1. Requirements on Other Protocols and Functional Components 

   When the detailed route information is included for LSP state 
   synchronization (either at the initial stage or during LSP state 
   report process), this require the ingress node of an LSP carry the 
   RRO object in order to enable the collection of such information.  

5. Security Considerations 

   The security issues presented in [RFC5440] and [Stateful-PCE] apply 
   to this document.  

6. Acknowledgement 

   We would like to thank Adrian Farrel and Cyril Margaria for the 
   useful comments and discussions. 

 
 
Zhang et al             Expires January 2016                  [Page 9] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

7. References 

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

   [Stateful-PCE]Crabbe, E., Medved, J., Varga, R., Minei, I., "PCEP 
             Extensions for Stateful PCE", draft-ietf-pce-stateful-pce, 
             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.2. Informative References 

   [Stateful-APP] Zhang, X., Minei, I., et al, "Applicability of 
             Stateful Path Computation Element (PCE) ", draft-ietf-pce-
             stateful-pce-app, work in progress. 

   [Sync-OPT] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,          
             and D. Dhody, "Optimizations of Label Switched Path State          
             Synchronization Procedures for a Stateful PCE", draft-             
             ietf-pce-stateful-sync-optimizations, work in progress. 

8. Contributors' Address 

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

   Yi Lin 
   Huawei Technologies 
   F3-5-B R&D Center, Huawei Base 
 
 
Zhang et al             Expires January 2016                 [Page 10] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

   Bantian, Longgang District 
   Shenzhen 518129 P.R.China 
    
   Phone: +86-755-28972914 
   Email: yi.lin@huawei.com

 
 
Zhang et al             Expires January 2016                 [Page 11] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

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-28972645 
   Email: zhang.xian@huawei.com
    
    
   Young Lee 
   Huawei 
   1700 Alma Drive, Suite 100 
   Plano, TX  75075 
   US 
    
   Phone: +1 972 509 5599 x2240 
   Fax:   +1 469 229 5397 
   EMail: ylee@huawei.com
    
    
   Fatai Zhang 
   Huawei 
   F3-5-B R&D Center, Huawei Base 
   Bantian, Longgang District 
   P.R. China 
    
   Phone: +86-755-28972912 
   Email: zhangfatai@huawei.com
    
   Ramon Casellas 
   CTTC  
   Av. Carl Friedrich Gauss n7 
   Castelldefels, Barcelona 08860 
   Spain 
    
   Phone: 
   Email: ramon.casellas@cttc.es
    
    
   Oscar Gonzalez de Dios  
   Telefonica Investigacion y Desarrollo 
   Emilio Vargas 6 
   Madrid,   28045 
   Spain 
    
 
 
Zhang et al             Expires January 2016                 [Page 12] 


draft-ietf-pce-pcep-stateful-pce-gmpls-03.txt                 July 2015 
    

   Phone: +34 913374013 
   Email: ogondio@tid.es
 
 
   Zafar Ali 
   Cisco Systems 
  Email: zali@cisco.com
    
    

 
 
Zhang et al             Expires January 2016                 [Page 13]