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

Document Type Active Internet-Draft (pce WG)
Authors Young Lee , Haomian Zheng , Oscar Gonzalez de Dios , Victor Lopez , Zafar Ali
Last updated 2022-02-10
Replaces draft-zhang-pce-pcep-stateful-pce-gmpls, draft-ietf-pce-remote-initiated-gmpls-lsp
Stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats plain text htmlized pdfized bibtex
Stream WG state Waiting for WG Chair Go-Ahead
Revised I-D Needed - Issue raised by WGLC
Document shepherd Dhruv Dhody
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to dd@dhruvdhody.com
draft-ietf-pce-pcep-stateful-pce-gmpls-17
PCE Working Group                                                Y. Lee 
Internet-Draft                                                  Samsung 
Intended status: Standards Track                               H. Zheng 
Expires: August 10, 2022                            Huawei Technologies 
                                                          O. G. de Dios 
                                                             Telefonica 
                                                           Victor Lopez 
                                                                  Nokia 
                                                                 Z. Ali 
                                                          Cisco Systems 
                                                      February 10, 2022 
                                      

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

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. The list of current Internet-Drafts is at 
   https://datatracker.ietf.org/drafts/current/. 

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in progress." 

 
 
 
Lee & Zheng, et al       Expires August 2022                  [Page 1] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   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 August 10, 2022. 

Copyright Notice 

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

  

Table of Contents 

    
   Table of Contents .............................................. 2 
   1. Introduction ................................................ 3 
   2. Conventions used in this document ........................... 4 
   3. General Context of Stateful PCE and PCEP for GMPLS .......... 4 
   4. Main Requirements ........................................... 5 
   5. Overview of Stateful PCEP Extensions for GMPLS Networks ..... 6 
      5.1. Capability Advertisement for Stateful PCEP in GMPLS .... 6 
      5.2. LSP Synchronization .................................... 6 
      5.3. LSP Delegation and Cleanup ............................. 7 
      5.4. LSP Operations ......................................... 7 
   6. Extension of Existing PCEP Messages ......................... 7 
      6.1. The PCRpt Message ...................................... 7 
      6.2. The PCUpd Message ...................................... 9 
      6.3. The PCInitiate Message ................................. 9 
   7. PCEP Object Extensions ..................................... 11 
      7.1. Existing Extensions used for Stateful GMPLS ........... 11 
      7.2. New Extensions ........................................ 11 
         7.2.1. OPEN Object Extension GMPLS-CAPABILITY TLV ....... 11 
         7.2.2. New LSP Exclusion Sub-object in the XRO .......... 12 
         7.2.3. SRP Extension .................................... 13 
 
 
Lee & Zheng              Expires August 2022                  [Page 2] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   8. Update to Error Handling .................................... 13 
      8.1. Error Handling in LSP Re-optimization .................. 13 
      8.2. Error Handling in Route Exclusion ...................... 13 
      8.3. Error Handling for generalized END-POINTS .............. 14 
   9. Implementation .............................................. 14 
      9.1. Huawei Technologies .................................... 14 
   10. IANA Considerations......................................... 15 
      10.1. New GMPLS-CAPABILITY .................................. 15 
      10.2. New Sub-object for the Exclude Route Object ........... 15 
      10.3. Flag Field for new XRO Sub-object ..................... 15 
      10.4. New "B" Flag in the SRP Object ........................ 16 
      10.5. New PCEP Error Codes .................................. 16 
   11. Manageability Considerations ............................... 16 
      11.1. Requirements on Other Protocols ....................... 17 
   12. Security Considerations .................................... 17 
   13. Acknowledgement ............................................ 17 
   14. References ................................................. 17 
      14.1. Normative References .................................. 17 
      14.2. Informative References ................................ 18 
   15. Contributors' Address ...................................... 19 
   Authors' Addresses ............................................. 21 
    
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 [RFC5440] mainly focuses on MPLS networks and the PCEP 
   extensions needed for GMPLS-controlled networks are provided in 
   [RFC8779].  

   Stateful PCEs are shown to be helpful in many application scenarios, 
   in both MPLS and GMPLS networks, as illustrated in [RFC8051].  
   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.  

   [RFC8051] describes how a stateful PCE can be applicable to solve 
   various problems for MPLS-TE and GMPLS networks and the benefits it 
   brings to such deployments.  

 
 
Lee & Zheng              Expires August 2022                  [Page 3] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   [RFC8231] provides the fundamental extensions needed for stateful 
   PCE to support general functionality. Furthermore, [RFC8281] 
   describes the setup and teardown of PCE-initiated LSPs under the 
   active stateful PCE model, without the need for local configuration 
   on the PCC. However, both the documents left out the specification 
   for technology-specific objects/TLVs, and do not cover the GMPLS 
   networks (e.g., WSON, OTN, SONET/ SDH, etc. technologies).  

   This document focuses on the extensions that are necessary in order 
   for the deployment of stateful PCEs and the requirements for remote-
   initiated LSPs in GMPLS-controlled networks. Section 3 provides 
   General context of Stateful PCE and PCEP for GMPLS are provided in 
   Section 3, and PCE initiation requirement for GMPLS is provided in 
   section 4. Protocol extensions are included in section 5, as a 
   solution to address such requirements. 

    
2. Conventions used in this document 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
   "OPTIONAL" in this document are to be interpreted as described in 
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
   capitals, as shown here. 

3. General Context of Stateful PCE and PCEP for GMPLS 

   This section is built on the basis of Stateful PCE in [RFC8231] and 
   PCEP for GMPLS in [RFC8779].  

   The operation for Stateful PCE on LSPs can be divided into two types, 
   active stateful PCE and passive stateful PCE.  

   For active stateful PCE, a PCUpd message is sent from PCE to PCC to 
   update the LSP state for the LSP delegated to the PCE. Any changes 
   to the delegated LSPs generate a PCRpt message from the PCC to PCE 
   to convey the changes of the LSP. Any modifications to the 
   Objects/TLVs that are identified in this document to support GMPLS 
   technology-specific attributes will be carried in the PCRpt and 
   PCUpd messages. 

   For passive stateful PCEs, PCReq/PCRep messages are used to convey 
   path computation instructions.  GMPLS-technology specific Objects 
   and TLVs are defined in [RFC8779], so this document just points at 
   that work and only adds the stateful PCE aspects where applicable. 
   Passive Stateful PCE makes use of PCRpt messages when reporting LSP 
   State changes sent by PCC to PCEs.  Any modifications to the 

 
 
Lee & Zheng              Expires August 2022                  [Page 4] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   Objects/TLVs that are identified in this document to support GMPLS 
   technology-specific attributes will be carried in the PCRpt message.  

   Furthermore, the LSP Initiation function of PCEP is defined in 
   [RFC8281] to allow the PCE to initiate LSP establishment after the 
   path is computed. PCInitiate messages are used to trigger the end 
   node to set up the LSP. Any modifications to the Objects/TLVs that 
   are identified in this document to support GMPLS technology-specific 
   attributes will be carried in the PCInitiate messages. 

   [RFC8779] defines GMPLS-technology specific Objects/TLVs in 
   stateless PCEP, and this document makes use of these Objects/TLVs 
   without modifications where applicable. Where these Objects/TLVs 
   require modifications to incorporate stateful PCE, they are 
   described in this document. The remote-initiated LSP would follow 
   the principle specified in [RFC8281], and GMPLS-specific extensions 
   are also included in this document.  

4. Main Requirements 

   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 [RFC8051].  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 [RFC8231].  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 requirements for GMPLS-specific stateful PCE are as follows: 

      o Advertisement of the stateful PCE capability.  This generic 
        requirement is covered in Section 5.4 of [RFC8231]. The GMPLS 
        CAPABILITY TLV in section 2.1 of [RFC8779] and its extension in 
        this document MUST be advertised as well.  

      o LSP operations, including LSP update, delegation and state 
        synchronization/report are covered in [RFC8231]. This document 
        provides extensions for its application in GMPLS-controlled 
        networks. 

      o All the PCEP messages need to be capable of indicating GMPLS-
        specific switching capabilities a per TE link basis.  GMPLS LSP 
        creation/modification/deletion requires knowledge of LSP 
        switching capability (e.g., TDM, L2SC, OTN-TDM, LSC, etc.) and 
        the generalized payload (G-PID) to be used according to 
 
 
Lee & Zheng              Expires August 2022                  [Page 5] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

        [RFC3471], [RFC3473]. It also requires the specification of data 
        flow specific traffic parameters (also known as TSpec), which 
        are technology specific. Such information would need to be 
        included in various PCEP messages. 

      o In some technologies, path calculation is tightly coupled with 
        label selection along the route.  For example, path calculation 
        in a WDM network may include lambda continuity and/or lambda 
        feasibility constraints and hence a path computed by the PCE is 
        associated with a specific lambda (label).  Hence, in such 
        networks, the label information needs to be provided to a PCC in 
        order for a PCE to initiate GMPLS LSPs under the active stateful 
        PCE model, i.e., explicit label control may be required. 

      o Stateful PCEP messages also need to indicate the protection 
        context information for the LSP specified by GMPLS, as defined 
        in [RFC4872], [RFC4873]. 

5. Overview of Stateful PCEP Extensions for GMPLS Networks 

5.1. Capability Advertisement for Stateful PCEP in GMPLS 

   Capability Advertisement has been specified in [RFC8231], and can be 
   achieved by using the "STATEFUL-PCE-CAPABILITY" in the PCEP TLV Type 
   Indicators. Another GMPLS-CAPABILITY TLV in the PCEP TLV Type 
   Indicators has been defined in [RFC8779].  According to [RFC8779], 
   IANA created a registry to manage the value of the GMPLS-CAPABILITY 
   TLV's Flag field.  New bits, LSP-UPDATE-CAPABILITY (TBD1) and LSP-
   INSTANTIATION-CAPABILITY (TBD2), are introduced as flags to indicate 
   the capability for LSP update and remote LSP initiation in GMPLS 
   networks.  

5.2. LSP Synchronization  

   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 including bandwidth,    
   associated route, and protection information etc., are stored by the   
   PCE in the LSP database (LSP-DB).  Note that, as described in    
   [RFC8231], the LSP state synchronization covers both the bulk   
   reporting of LSPs at initialization as well the reporting of new or   
   modified LSPs during normal operation. Incremental LSP-DB 
   synchronization may be desired in a GMPLS-controlled network and it 
   is specified in [RFC8232]. 

   The END-POINTS object is extended for GMPLS in [RFC8779]. The END-
   POINTS object is carried in the PCRpt message as specified in 

 
 
Lee & Zheng              Expires August 2022                  [Page 6] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   [RFC8623]. The END-POINTS object type for GMPLS is included in the 
   PCRpt message as per the same.  

   The BANDWIDTH, LSPA, IRO and XRO objects are extended for GMPLS in 
   [RFC8779]. These objects are carried in the PCRpt message as 
   specified in [RFC8231] (as the attribute-list defined in Section 6.5 
   of [RFC5440] and extended by many other documents that define PCEP 
   extensions for specific scenarios).  

   The SWITCH-LAYER object is defined in [RFC8282]. This object is 
   carried in PCRpt message as specified in section 3.2 of [RFC8282]. 

5.3. LSP Delegation and Cleanup 

   LSP delegation and cleanup procedure specified in [RFC8231] are 
   equally applicable to GMPLS LSPs and this document does not modify 
   the associated usage. 

5.4. LSP Operations  

   Both passive and active stateful PCE mechanisms in [RFC8231] are 
   applicable in GMPLS-controlled networks. Remote LSP Initiation in 
   [RFC8281] is also applicable in GMPLS-controlled networks. 

6. Extension of Existing PCEP Messages  

   This section describes how the PCEP messages are extended by using 
   Routing Backus-Naur Form (RBNF) [RFC5511] formats. Contents in this 
   section are for informative purpose.  

6.1. The PCRpt Message 

   According to [RFC8231], the PCRpt Message is used to report the 
   current state of an LSP. This document extends the message in 
   reporting the status of LSPs with GMPLS characteristics.  

   The format of the PCRpt message is as follows: 

         <PCRpt Message> ::= <Common Header> 

                             <state-report-list> 

      Where: 

         <state-report-list> ::= <state-report>[<state-report-list>] 

         <state-report> ::= [<SRP>] 

 
 
Lee & Zheng              Expires August 2022                  [Page 7] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

                            <LSP> 

                            <path> 

       Where: 

         <path>::= <intended-path> 

                   [<actual-attribute-list><actual-path>] 

                   <intended-attribute-list> 

    

         <actual-attribute-list>::=[<BANDWIDTH>] 

                                   [<metric-list>] 

   Where: 

     <intended-path> is represented by the ERO object defined in    
   Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label 
   control (ELC) and Path Keys. 

     <actual-attribute-list> consists of the actual computed and      
   signaled values of the <BANDWIDTH> and <metric-lists> objects      
   defined in [RFC5440]. GENERALIZED-BANDWIDTH object has been defined 
   in [RFC8779] to address the limitation of the BANDWIDTH object, with 
   supporting the following: 

   o Asymmetric bandwidth (different bandwidth in forward and reverse 
   direction), as described in [RFC6387]. 

   o Technology specific GMPLS parameters (e.g., TSpec for SDH/SONET, 
   G.709, ATM, MEF, etc.). 

     <actual-path> is represented by the RRO object defined in      
   Section 7.10 of [RFC5440]. 

     <intended-attribute-list> is the attribute-list defined in      
   Section 6.5 of [RFC5440] and extended by many other documents that 
   define PCEP extensions for specific scenarios. 

     The SRP object is OPTIONAL, and the usage is extended in the 
   section 7.2.3 of this document.   

 
 
Lee & Zheng              Expires August 2022                  [Page 8] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

6.2. The PCUpd Message 

   The format of a PCUpd message is as follows: 

         <PCUpd Message> ::= <Common Header> 

                             <update-request-list> 

      Where: 

         <update-request-list> ::= <update-request>[<update-request-
   list>] 

         <update-request> ::= <SRP> 

                              <LSP> 

                              <path> 

      Where: 

         <path>::= <intended-path><intended-attribute-list> 

      Where: 

      <intended-path> is represented by the ERO object defined in    
   Section 7.9 of [RFC5440], augmented in [RFC8779] with explicit label 
   control (ELC) and Path Keys. 

      <intended-attribute-list> is the attribute-list defined in    
   [RFC5440] and extended by many other documents that define PCEP 
   extensions for specific scenarios. 

      The SRP object is OPTIONAL, and the usage is extended in the 
   section 7.2.3 of this document. 

6.3. The PCInitiate Message 

     According to [RFC8281], the PCInitiate Message is used allow 
   remote LSP Initiation. This document extends the message in 
   initiating LSPs with GMPLS characteristics.  The format of a 
   PCInitiate message is as follows: 

        <PCInitiate Message> ::= <Common Header> 

                                 <PCE-initiated-lsp-list> 

      Where: 
 
 
Lee & Zheng              Expires August 2022                  [Page 9] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

        <Common Header> is defined in [RFC5440]. 

        <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> 

                                     [<PCE-initiated-lsp-list>] 

        <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-
   instantiation>| 

                                         <PCE-initiated-lsp-deletion>) 

        <PCE-initiated-lsp-instantiation> ::= <SRP> 

                                              <LSP> 

                                              [<END-POINTS>] 

                                              <ERO> 

                                              [<attribute-list>] 

        <PCE-initiated-lsp-deletion> ::= <SRP> 

                                         <LSP> 

   The format of the PCInitiate message is unchanged from Section 5.1 
   of [RFC8281].  However, note the following: 

      o  The END-POINTS object was been extended by [RFC8779] to 
   include a new object type called "Generalized Endpoint".  A 
   PCInitiate message used to trigger a GMPLS LSP instantiation MUST 
   use that extension. 

      o  A PCInitiate message sent by a PCE to a PCC to trigger a GMPLS 
   LSP instantiation MUST include the END-POINTS with Generalized 
   Endpoint object type (even though it is marked as optional in the 
   message definition. 

      o  The END-POINTS object MUST contain a "label request" TLV per    
   [RFC8779].  The label request TLV is used to specify the switching   
   type, encoding type and G-PID of the LSP being instantiated by the   
   PCE.  

      o  If unnumbered endpoint addresses are used for the LSP being    
   instantiated by the PCE, the unnumbered endpoint TLV [RFC8779]     
   MUST be use to specify the unnumbered endpoint addresses. 

      o  The END-POINTS MAY contain other TLVs defined in [RFC8779]. 
 
 
Lee & Zheng              Expires August 2022                 [Page 10] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

7. PCEP Object Extensions 

7.1. Existing Extensions used for Stateful GMPLS 

   Existing extensions defined in [RFC8779] can be used in the Stateful 
   PCEP with no changes or slightly changes for GMPLS network control, 
   including the following:  

   o END-POINTS: Generalized END-POINTS was specified in [RFC8779] to 
   include GMPLS capabilities. Stateful PCEP messages MUST include the 
   END-POINTS with Generalized Endpoint object type, containing the 
   "label request" TLV. 

   o BANDWIDTH: Generalized BANDWIDTH was specified in [RFC8779] to 
   represent GMPLS features, including asymmetric bandwidth and G-PID 
   information.  

   o LSPA: LSPA Extensions in Section 2.8 of [RFC8779] is applicable 
   in Stateful PCEP for GMPLS networks.  

   o IRO: IRO Extensions in Section 2.6 of [RFC8779] is applicable in 
   Stateful PCEP for GMPLS networks. 

   o XRO: XRO Extensions in Section 2.7 of [RFC8779] is applicable in 
   Stateful PCEP for GMPLS networks. A new flag is defined in section 
   7.2.2 of this document.  

   o ERO: The ERO was not extended in [RFC8779], and not in this 
   document as well.  

   o SWITCH-LAYER: SWITCHING-LAYER definition in Section 3.2 of 
   [RFC8282] is applicable in Stateful PCEP messages for GMPLS networks. 

7.2. New Extensions 

 7.2.1. OPEN Object Extension GMPLS-CAPABILITY TLV 

   In [RFC8779], IANA has allocated value 45 (GMPLS-CAPABILITY) from 
   the "PCEP TLV Type Indicators" sub-registry.  The TLV is extended 
   with two flags to indicate the Stateful and remote initiate 
   capability. 

   S (LSP-UPDATE-CAPABILITY(TBD1) -- 1 bit): if set to 1 by a PCC, the 
   S flag indicates that the PCC allows modification of LSP parameters; 
   if set to 1 by a PCE, the S flag indicates that the PCE is capable 
   of updating LSP parameters.  The LSP-UPDATE-CAPABILITY flag must be 
   advertised by both a PCC and a PCE for PCUpd messages to be allowed 
   on a PCEP session. 
 
 
Lee & Zheng              Expires August 2022                 [Page 11] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   I (LSP-INSTANTIATION-CAPABILITY(TBD2) -- 1 bit): If set to 1 by a 
   PCC, the I flag indicates that the PCC allows instantiation of an 
   LSP by a PCE.  If set to 1 by a PCE, the I flag indicates that the 
   PCE supports instantiating LSPs.  The LSP-INSTANTIATION-CAPABILITY 
   flag must be set by both the PCC and PCE in order to enable PCE-
   initiated LSP instantiation. 

 7.2.2. New LSP Exclusion Sub-object in the XRO 

   [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  |    Flags       |  
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                                                               |  
     //                    Symbolic Path Name                       // 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     
    
     X bit and Attribute fields are defined in [RFC5521].  
 
     Type: Sub-object Type for an LSP exclusion sub-object. Value of 
     TBD3. To be assigned by IANA.  
          
     Length: The Length contains the total length of the sub-object in 
     bytes, including the Type and Length fields.  
 
     Flags: This field may be used to further specify the exclusion 
     constraint with regard to the LSP. Currently, no values are 
     defined. 
    
     Symbolic Path Name: This is the identifier given to an LSP and is 
     unique in the context of the PCC address as defined in [RFC8231]. 
    
   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 MUST search for the identified 

 
 
Lee & Zheng              Expires August 2022                 [Page 12] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   LSP in its LSP-DB and then exclude from the new path computation all 
   resources used by the identified LSP.   

 7.2.3. SRP Extension 

   The format of the SRP object is defined in [RFC8231].  The object is 
   used in PCUpd and PCInitiate messages for GMPLS. 

   This document defines a new flag to be carried in the Flags field of 
   the SRP object.   This flag indicates a bidirectional co-routed LSP 
   setup operation initiated by the PCE as follows: 

   o B (Bidirectional LSP -- 1 bit):  If set to 0, it indicates a 
   request to create a uni-directional LSP.  If set to 1, it indicates 
   a request to create a bidirectional co-routed LSP. 

   The bit position is TBD4 as assigned by IANA. 

8. Update to Error Handling 

   A PCEP-ERROR object is used to report a PCEP error and is 
   characterized by an Error-Type that specifies the type of error and 
   an Error-value that provides additional information about the error.  
   In this document the following Error-Type and Error-Value are 
   introduced.  

8.1. Error Handling in LSP Re-optimization   

   A stateful PCE performs the re-optimization when the R bit is set in 
   RP object. If no LSP state information is available to carry out re-
   optimization, the stateful PCE SHOULD report the error "LSP state 
   information unavailable for the LSP re-optimization" (Error Type = 
   TBD5, Error value= TBD6).  The PCE MAY suppress this error message 
   on a configurable threshold. 
    
8.2. Error Handling in Route Exclusion   

   This sub-object in XRO defined in section 7.2.2 of this document is 
   OPTIONAL and can be present multiple times.  When a stateful PCE 
   receives a PCReq message carrying this sub-object, it searches for 
   the identified LSP in its LSP-DB and then excludes 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" 

 
 
Lee & Zheng              Expires August 2022                 [Page 13] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   (Error-type = TBD5, Error-value = TBD7).  Optionally, it may also 
   provide with the unrecognized identifier information to the 
   requesting PCC using the error reporting techniques described in 
   [RFC5440].  However, the PCE MAY suppress this error message on a 
   configurable threshold. 
    
8.3. Error Handling for generalized END-POINTS   

   If the END-POINTS Object of type Generalized Endpoint is missing the 
   label request TLV, the PCC MUST send a PCErr message with Error-
   type=6 (Mandatory Object missing) and Error-value= TBD8 (label 
   request TLV missing). 
    
9. Implementation 

   [NOTE TO RFC EDITOR : This whole section and the reference to RFC   
   7942 is to be removed before publication as an RFC] 

   This section records the status of known implementations of the 
   protocol defined by this specification at the time of posting of 
   this Internet-Draft, and is based on a proposal described in 
   [RFC7942].  The description of implementations in this section is 
   intended to assist the IETF in its decision processes in progressing 
   drafts to RFCs.  Please note that the listing of any individual 
   implementation here does not imply endorsement by the IETF.  
   Furthermore, no effort has been spent to verify the information 
   presented here that was supplied by IETF contributors.  This is not 
   intended as, and must not be construed to be, a catalog of available 
   implementations or their features.  Readers are advised to note that 
   other implementations may exist. 

   According to [RFC7942], "this will allow reviewers and working 
   groups to assign due consideration to documents that have the 
   benefit of running code, which may serve as evidence of valuable 
   experimentation and feedback that have made the implemented 
   protocols more mature. It is up to the individual working groups to 
   use this information as they see fit". 

9.1. Huawei Technologies 

      o  Organization: Huawei Technologies, Co. LTD 

      o  Implementation: Huawei NCE-T  

      o  Description: PCRpt, PCUpd and PCInitiate messages for GMPLS 
   Network 
 
 
Lee & Zheng              Expires August 2022                 [Page 14] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

      o  Maturity Level: Production 

      o  Coverage: Full 

      o  Contact: zhenghaomian@huawei.com 

10. IANA Considerations 

10.1. New GMPLS-CAPABILITY 

   [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, 
   IANA created a registry to manage the value of the STATEFUL-PCE-
   CAPABILITY TLV's Flag field.  IANA has allocated a new bit in the 
   STATEFUL-PCE-CAPABILITY TLV Flag Field registry, as follows: 

       Bit  Description                      Reference 

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

       TBD1   LSP-UPDATE-CAPABILITY (S)         [This.I-D] 

       TBD2   LSP-INSTANTIATION-CAPABILITY (I)  [This.I-D] 

10.2. New Sub-object 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 Exclusion sub-object     [This.I-D]  

10.3. Flag Field for new XRO Sub-object 

   IANA has created a registry to manage the Flag field of the LSP 
   Exclusion sub-object in XRO object.  No Flag is currently defined 
   for this flag field in this document. 

      Codespace of the Flag field (LSP Exclusion sub-object) 

        Bit      Description             Reference 

        0-7      Unassigned             [This.I-D] 
 
 
Lee & Zheng              Expires August 2022                 [Page 15] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

10.4. New "B" Flag in the SRP Object 

   IANA maintains a subregistry, named the "SRP Object Flag Field", 
   within the "Path Computation Element Protocol (PCEP) Numbers" 
   registry, to manage the Flag field of the SRP object. 

   IANA is requested to make an assignment from this registry as 
   follows: 

          Bit      Description                        Reference 
          ---      ----------------------------       ---------- 
    
          TBD4     Bi-directional co-routed LSP       [This.I-D] 
    
10.5. 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 

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

   Error-value TBD6: LSP state information unavailable    [This.I-D] 
                     for the LSP re-optimization 
                     
   Error-value TBD7: LSP state information for route  
                     exclusion purpose cannot be found    [This.I-D] 
                     
    
   This document defines the following new Error-Value: 
    
   Error-Type   Error-Value                     Reference 
    
   6         Error-value TBD8: Label Request TLV  
                  missing                       [This.I-D] 
    

11. 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 [RFC8231] should 
   also be considered. 

 
 
Lee & Zheng              Expires August 2022                 [Page 16] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

11.1. Requirements on Other Protocols 

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

12. Security Considerations 

   This draft provides additional extensions to PCEP so as to 
   facilitate stateful PCE usage in GMPLS-controlled networks, on top 
   of [RFC8231].  The PCEP extensions to support GMPLS-controlled 
   networks should be considered under the same security as for MPLS 
   networks, as noted in [RFC7025]. Therefore, the security 
   considerations elaborated in [RFC5440] still apply to this draft. 
   Furthermore, [RFC8231] provides a detailed analysis of the 
   additional security issues incurred due to the new extensions and 
   possible solutions needed to support for the new stateful PCE 
   capabilities and they apply to this document as well. 

13. Acknowledgement 

   We would like to thank Adrian Farrel, Cyril Margaria, George Swallow 
   and Jan Medved for the useful comments and discussions. 

14. References 

14.1. Normative References 

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

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

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

   [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 
             Key Words", RFC 8174, May 2017. 

   [RFC8231] Crabbe, E., Medved, J., Varga, R., Minei, I., "Path 
             Computation Element Communication Protocol (PCEP) 
             Extensions for Stateful PCE", RFC 8231, September 2017. 

 
 
Lee & Zheng              Expires August 2022                 [Page 17] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 
             Computation Element Communication Protocol (PCEP) 
             Extensions for PCE-Initiated LSP Setup in a Stateful PCE 
             Model", RFC 8281, December 2017. 

   [RFC8779] Margaria, C., Gonzalez de Dios, O., Zhang, F., "Path 
             Computation Element Communication Protocol (PCEP) 
             extensions for GMPLS", RFC 8779, July 2020. 

14.2. Informative References 

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of 
             Running Code: The Implementation Status Section", BCP 205,         
             RFC 7942, DOI 10.17487/RFC7942, July 2016,              
             <https://www.rfc-editor.org/info/rfc7942>. 

   [RFC8051] Zhang, X., Minei, I., et al, "Applicability of Stateful 
             Path Computation Element (PCE) ", RFC 8051, January 2017. 

   [RFC8232] 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", RFC 8232, 
             September 2017. 

   [RFC8282] Oki, E., Takeda, T., Farrel, A., and F. Zhang, "Extensions 
             to the Path Computation Element communication Protocol 
             (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", 
             RFC 8282, December 2017. 

   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label 
             Switching (GMPLS) Signaling Functional Description", RFC 
             3471, January 2003. 

   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label 
             Switching (GMPLS) Signaling Resource ReserVation Protocol 
             Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 
             January 2003. 

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

   [RFC4872]  Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, 
             Ed., "RSVP-TE Extensions in Support of End-to-End 
             Generalized Multi-Protocol Label Switching (GMPLS) 
             Recovery", RFC 4872, May 2007. 

 
 
Lee & Zheng              Expires August 2022                 [Page 18] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, 
             "GMPLS Segment Recovery", RFC 4873, May 2007. 

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 
             Used to Form Encoding Rules in Various Routing Protocol 
             Specifications", RFC5511, April 2005.  

   [RFC6387]  Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. 
             Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label 
             Switched Paths (LSPs)", RFC 6387, September 2011.    

   [RFC7025]  Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.             
             Margaria, "Requirements for GMPLS Applications of PCE",            
             RFC 7025, September 2013, 

   [RFC7399]  Farrel, A., King, D., "Unanswered Questions in the Path 
             Computation Element Architecture", RFC 7399, October 2014. 

   [RFC8623]  Palle, U., Dhody, D., Tanaka, Y., Beeram, V., "Stateful 
             Path Computation Element (PCE) Protocol Extensions for 
             Usage with Point-to-Multipoint TE Label Switched Paths 
             (LSPs)" June 2019. 

    

15. Contributors' Address 

   Xian Zhang 
   Huawei Technologies 
   Email: zhang.xian@huawei.com 
 
    
   Dhruv Dhody 
   Huawei Technology 
   India 
   Email: dhruv.ietf@gmail.com 
    

   Yi Lin 
   Huawei Technologies 
   Email: yi.lin@huawei.com 
    

 
 
Lee & Zheng              Expires August 2022                 [Page 19] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

   Fatai Zhang 
   Huawei Technologies 
   Email: zhangfatai@huawei.com 
    
   Ramon Casellas 
   CTTC  
   Av. Carl Friedrich Gauss n7 
   Castelldefels, Barcelona 08860 
   Spain 
   Email: ramon.casellas@cttc.es 
    
   Siva Sivabalan 
   Cisco Systems 
   Email: msiva@cisco.com 
    
    
   Clarence Filsfils 
   Cisco Systems 
   Email: cfilsfil@cisco.com 
    
   Robert Varga 
   Pantheon Technologies 
   Email: nite@hq.sk 
    
    

 
 
Lee & Zheng              Expires August 2022                 [Page 20] 


Internet-Draft         Stateful PCEP for GMPLS           February 2022 
    

Authors' Addresses 

    
    
   Young Lee 
   Samsung 
   Email: younglee.tx@gmail.com 
                           
   Haomian Zheng 
   Huawei Technologies 
   H1, Huawei Xiliu Beipo Village, Songshan Lake 
   Dongguan, Guangdong  523808 
   China 
   Email: zhenghaomian@huawei.com 
    
   Oscar Gonzalez de Dios  
   Telefonica  
   Phone: +34 913374013 
   Email: oscar.gonzalezdedios@telefonica.com  
 
 
   Victor Lopez 
   Nokia 
   Email: victor.lopez@nokia.com  
 
   Zafar Ali 
   Cisco Systems 
  Email: zali@cisco.com 
    
    

 
 
Lee & Zheng              Expires August 2022                 [Page 21]