Skip to main content

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

Document Type Active Internet-Draft (pce WG)
Authors Young Lee , Haomian Zheng , Oscar Gonzalez de Dios , Victor Lopez , Zafar Ali
Last updated 2022-09-26 (Latest revision 2022-06-27)
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
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Dhruv Dhody
Shepherd write-up Show Last changed 2022-06-29
IESG IESG state AD Evaluation
Action Holder
Consensus boilerplate Yes
Telechat date (None)
Responsible AD John Scudder
Send notices to dd@dhruvdhody.com
draft-ietf-pce-pcep-stateful-pce-gmpls-20
PCE Working Group                                                Y. Lee 
Internet-Draft                                                  Samsung 
Intended status: Standards Track                               H. Zheng 
Expires: December 27, 2022                          Huawei Technologies 
                                                          O. G. de Dios 
                                                             Telefonica 
                                                           Victor Lopez 
                                                                  Nokia 
                                                                 Z. Ali 
                                                          Cisco Systems 
                                                          June 27, 2022 
                                      

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

Abstract 

   The PCE communication Protocol (PCEP) has been extended to support 
   stateful PCE functions where the Stateful PCE maintains information 
   about paths and resource usage within a network, but these 
   extensions do not cover all requirements for GMPLS networks.  

   This document provides the 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 December 2022                 [Page 1] 


Internet-Draft         Stateful PCEP for GMPLS               June 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 December 27, 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 Revised BSD License text as described in 
   Section 4.e of the Trust Legal Provisions and are provided without 
   warranty as described in the Revised BSD License. 

  

Table of Contents 

    
   Table of Contents ............................................... 2 
   1. Introduction ................................................. 3 
      1.1. Conventions used in this document ....................... 4 
   2. Terminology .................................................. 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 ..................................... 7 
      5.3. LSP Delegation and Cleanup .............................. 7 
      5.4. LSP Operations .......................................... 7 
   6. PCEP Object Extensions ....................................... 8 
      6.1. Existing Extensions used for Stateful GMPLS ............. 8 
      6.2. New Extensions .......................................... 9 
         6.2.1. GMPLS-CAPABILITY TLV in OPEN Object ................ 9 
         6.2.2. New LSP Exclusion Sub-object in the XRO ............ 9 
         6.2.3. New flags in the LSP-EXTENDED-FLAG TLV in LSP Object10 
   7. Update to Error Handling .................................... 11 
      7.1. Error Handling in PCEP Capabilities Advertisement ...... 11 
      7.2. Error Handling in LSP Re-optimization .................. 12 
 
 
Lee & Zheng             Expires December 2022                 [Page 2] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

      7.3. Error Handling in Route Exclusion ...................... 12 
      7.4. Error Handling for generalized END-POINTS .............. 12 
   8. Implementation .............................................. 13 
      8.1. Huawei Technologies .................................... 13 
   9. IANA Considerations ......................................... 14 
      9.1. New Flags in GMPLS-CAPABILITY TLV ...................... 14 
      9.2. New Sub-object for the Exclude Route Object ............ 14 
      9.3. Flags Field for LSP exclusion Sub-object ............... 14 
      9.4. New  Flags in the LSP-EXTENDED-FLAGS TLV ............... 15 
      9.5. New PCEP Error Codes ................................... 15 
   10. Manageability Considerations ............................... 16 
      10.1. Control of Function through Configuration and Policy .. 16 
      10.2. Information and Data Models ........................... 16 
      10.3. Liveness Detection and Monitoring ..................... 17 
      10.4. Verifying Correct Operation ........................... 17 
      10.5. Requirements on Other Protocols and Functional Components17 
      10.6. Impact on Network Operation ........................... 17 
   11. Security Considerations .................................... 17 
   12. Acknowledgement ............................................ 18 
   13. References ................................................. 18 
      13.1. Normative References .................................. 18 
      13.2. Informative References ................................ 19 
   14. Contributors' Address ...................................... 21 
   Appendix A: PCEP Messages ...................................... 21 
      A.1  The PCRpt Message ...................................... 22 
      A.2 The PCUpd Message ....................................... 23 
      A.3 The PCInitiate Message .................................. 23 
   Authors' Addresses ............................................. 25 
    
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).  A PCE 
   that only maintains TED is referred to as a stateless PCE.  [RFC5440] 
   describes the Path Computation Element Communication Protocol (PCEP) 
   for interaction between a Path Computation Client (PCC) and a PCE, 
   or between two PCEs, enabling computation of TE LSPs.  PCEP is 
   further extended to support GMPLS-controlled networks as per 
   [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 
 
 
Lee & Zheng             Expires December 2022                 [Page 3] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

   capability of stateful PCEs, extensions to stateful PCEP for GMPLS 
   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.  

   [RFC8231] specifies a set of extensions to PCEP to enable stateful 
   control of TE LSPs where they are configured on the PCC, and control 
   over them could be delegated to the PCE. 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-
   controlled networks (e.g., Wavelength Switched Optical Network 
   (WSON), Optical Transport Network (OTN), Synchronous Optical Network 
   (SONET)/Synchronous Digital Hierarchy (SDH), etc. technologies).  

   This document focuses on the extensions that are necessary in order 
   for the deployment of stateful PCEs and the requirements for PCE-
   initiated LSPs in GMPLS-controlled networks. Section 3 provides a 
   general context of the usage of Stateful PCE and PCEP for GMPLS.  
   The various requirements for stateful GMPLS, including PCE-
   initiation for GMPLS LSPs, are provided in Section 4. An overview of 
   the PCEP extensions are specified in Section 5, as a solution to 
   address such requirements with PCEP object extensions in Section 6. 

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

2. Terminology 

   Terminology used in this document is the same as terminology used in   
   [RFC5440], [RFC8231], [RFC8281], and [RFC8779] 

    

3. General Context of Stateful PCE and PCEP for GMPLS 

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

 
 
Lee & Zheng             Expires December 2022                 [Page 4] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

   The operation for Stateful PCE on LSPs can be divided into two types, 
   active stateful PCE and passive stateful PCE as described in 
   [RFC8051].  

   For active stateful PCE, a Path Computation Update Request (PCUpd)  
   message is sent from PCE to PCC to update the LSP state for the LSPs 
   delegated to the PCE. Any changes to the delegated LSPs generate a 
   Path Computation State Report (PCRpt) message from the PCC to PCE to 
   convey the changes of the LSPs. 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 request 
   for path computation.  GMPLS-technology specific Objects and TLVs 
   are defined in [RFC8779], this document builds on it and adds the 
   stateful PCE aspects where applicable. Passive Stateful PCE makes 
   use of PCRpt messages when reporting LSP State changes sent by PCCs 
   to PCEs.  Any modifications to the 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. An LSP Initiate Request (PCInitiate) message is 
   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. PCE-Initiated LSPs follow the principle 
   specified in [RFC8281], and the 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], such as 
   LSP update, delegation and state synchronization/report.  Protection 
   context information that describes the GMPLS requirement can also 
 
 
Lee & Zheng             Expires December 2022                 [Page 5] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

   follow the description in [RFC8745].  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 specified in section 2.1 of [RFC8779] and its 
        extension in this document needs to be advertised as well.  

      o All the PCEP messages need to be capable of indicating GMPLS-
        specific switching capabilities.  GMPLS LSP 
        creation/modification/deletion requires knowledge of LSP 
        switching capability (e.g., Time-Division Multiplex Capable 
        (TDM), Layer 2 Switch Capable (L2SC), OTN-TDM, Lambda Switch 
        Capable (LSC), etc.) and the generalized payload (G-PID) to be 
        used according to [RFC3471], [RFC3473]. It also requires the 
        specification of data flow specific traffic parameters (also 
        known as Traffic Specification (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 Wavelength Division Multiplexing (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 TLV" in the Open 
   message. Another GMPLS-CAPABILITY TLV has been defined in [RFC8779].    
   A subregistry to manage the Flag field of the GMPLS-CAPABILITY TLV 
   is created by the IANA as requested by [RFC8779].  The following 
   bits are introduced by this document in the GMPLS-CAPABILITY TLV as 
 
 
Lee & Zheng             Expires December 2022                 [Page 6] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

   flags to indicate the capability for LSP report, update and 
   initiation in GMPLS networks: LSP-REPORT-CAPABILITY(TBDa), LSP-
   UPDATE-CAPABILITY (TBD1), and LSP-INSTANTIATION-CAPABILITY (TBD2).  

5.2. LSP Synchronization  

   After the session between the PCC and a stateful PCE is initialized, 
   the PCE must learn the state of a PCC's LSPs (including its 
   attributes) before it can perform path computations or update LSP 
   attributes in a PCC. 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 format of the PCRpt message is specified in [RFC8231] and 
   extended in [RFC8623] to include the END-POINTS object. The END-
   POINTS object is extended for GMPLS in [RFC8779]. The END-POINTS 
   object can be carried in the PCRpt message as specified in [RFC8623]. 
   The END-POINTS object type for GMPLS is included in the PCRpt 
   message as per the same.  

   The BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO) and 
   Exclude Route Object (XRO) objects are extended for GMPLS in 
   [RFC8779] and are also used in the PCRpt in the same manner. 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. 

 
 
Lee & Zheng             Expires December 2022                 [Page 7] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

6. PCEP Object Extensions 

6.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. All Stateful PCEP messages MUST include 
   the END-POINTS with Generalized Endpoint object type, containing the 
   LABEL-REQUEST TLV.  Further note that  

    *  As per [RFC8779] for stateless GMPLS path computation, the 
      Generalized END-POINTS object may contain a LABEL-REQUEST TLV 
      and/or LABEL-SET. In this document, only the LABEL-REQUEST TLV is 
      used to specify the switching type, encoding type and G-PID of the 
      LSP.  

    *  If unnumbered endpoint addresses are used for the LSP, the 
      UNNUMBERED-ENDPOINT TLV [RFC8779] MUST be used to specify the 
      unnumbered endpoint addresses. 

    *  The Generalized END-POINTS MAY contain other TLVs defined in 
      [RFC8779]. 

   o RP: RP object extension, together with the Routing Granularity 
   (RG) flag defined in [RFC8779], are applicable in the Stateful PCEP 
   for GMPLS networks.  

   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 Explicit Route Object (ERO) was not extended in 
   [RFC8779], and nor in this document.  

 
 
Lee & Zheng             Expires December 2022                 [Page 8] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

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

6.2. New Extensions 

 6.2.1. GMPLS-CAPABILITY TLV in OPEN Object 

   In [RFC8779], IANA has allocated value 45 (GMPLS-CAPABILITY) from 
   the "PCEP TLV Type Indicators" sub-registry.  The TLV is extended 
   with three flags to indicate the Report, Update, and Initiation 
   capabilities. 

   R (LSP-REPORT-CAPABILITY(TBDa) -- 1 bit): if set to 1 by a PCC, the 
   R flag indicates that the PCC is capable of reporting the current 
   state of an GMPLS LSP, whenever there's a change to the parameters 
   or operational status of the GMPLS LSP; if set to 1 by a PCE, the R 
   Flag indicates that the PCE is interested in receiving GMPLS LSP 
   State Reports whenever there is a parameter or operational status 
   change to the LSP.  The LSP-REPORT-CAPABILITY flag must be 
   advertised by both a PCC and a PCE for PCRpt messages to be allowed 
   on a PCEP session for GMPLS LSP. 

   U (LSP-UPDATE-CAPABILITY(TBD1) -- 1 bit): if set to 1 by a PCC, the 
   U flag indicates that the PCC allows modification of GMPLS LSP 
   parameters; if set to 1 by a PCE, the U flag indicates that the PCE 
   is capable of updating GMPLS 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 for GMPLS LSP. 

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

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

 
 
Lee & Zheng             Expires December 2022                 [Page 9] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

      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    |   Reserved    |    Flags      | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                                                               | 
     //                    Symbolic Path Name                       // 
     |                                                               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
               Figure 1: New LSP Exclusion Sub-object Format 
    
     X bit: Same as the X bit defined in XRO sub-objects by [RFC5521] 
     (i.e., mandatory vs. desired).  
 
     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.  
      
     Reserved: MUST be set to zero on transmission and ignored on 
     receipt. 
 
     Flags: This field may be used to further specify the exclusion 
     constraint with regard to the LSP. Currently, no flags 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].  
     It is worth noting that given that the Symbolic Path Name is 
     unique in the context of the headnode, only LSPs that share the 
     same headnode/PCC could be excluded. 
    
   This sub-object MAY be present multiple times in the exclude route 
   object (XRO) to exclude resources from multiple LSPs.  When a 
   stateful PCE receives a PCReq message carrying this sub-object, it 
   MUST search for the identified LSP in its LSP-DB and then exclude 
   from the new path computation all resources used by the identified 
   LSP. 

   Note that this XRO Sub-object could also be used by non-GMPLS LSPs.  
   The description of usage of non-GMPLS LSPs is not in the scope of 
   this document.  

 6.2.3. New flags in the LSP-EXTENDED-FLAG TLV in LSP Object 

   The LSP Object is defined in Section 7.3 of [RFC8231], and the new 
   extended flags TLV is defined in [I-D.ietf-pce-lsp-extended-flags].  
 
 
Lee & Zheng             Expires December 2022                [Page 10] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

   This TLV is used in PCUpd, PCRpt and PCInitiate messages for GMPLS, 
   with the following flags defined in this document. 

   o G (GMPLS LSP(TBDb) -- 1 bit) :  If set to 1, it indicates the LSP 
   is a GMPLS LSP. 

   o B (Bidirectional LSP(TBD4) -- 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. 

   o RG (Routing Granularity(TBDc) -- 2 bits) :  RG flag for GMPLS is 
   also defined in the LSP-EXTENDED-FLAG TLV  The value are defined as 
   per [RFC8779]: 

    00: reserved 
    01: node 
    10: link 
    11: label 

7. 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 handling procedures are 
   introduced.  All the error handling specified in section 3 of 
   [RFC8779] is applicable and MUST be supported for stateful PCE in 
   GMPLS networks.  

7.1. Error Handling in PCEP Capabilities Advertisement  

   The PCEP extensions described in this document for stateful PCEs 
   with GMPLS capability MUST NOT be used if the PCE has not advertised 
   its stateful capability with GMPLS as per Section 5.2.  If the PCC 
   understands the U flag that indicates the stateful LSP-UPDATE-
   CAPABILITY but did not advertise this capability, then upon receipt 
   of a PCUpd message for GMPLS LSP from the PCE, it SHOULD generate a 
   PCErr with error-type 19 ("Invalid Operation"), error-value TBDx 
   ("Attempted LSP Update Request for GMPLS if stateful PCE capability 
   for GMPLS was not advertised"), and terminate the PCEP session.   

   If the PCE understands the R flag that indicates the stateful LSP-
   REPORT-CAPABILITY but did not advertise this capability, then upon 
   receipt of a PCRpt message for GMPLS LSP from the PCC, it SHOULD 
   generate a PCErr with error-type 19 ("Invalid Operation"), error-
   value TBDy ("Attempted LSP Report Request for GMPLS if stateful PCE 
   capability for GMPLS was not advertised"), and terminate the PCEP 
   session.   
 
 
Lee & Zheng             Expires December 2022                [Page 11] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

   The PCEP extensions described in this document for PCC or PCE with 
   the PCE-Initiation capability for GMPLS LSPs MUST NOT be used if the 
   PCC or PCE has not advertised its stateful capability with 
   Instantiation and GMPLS-CAPABILITY as per [RFC8779].  If the PCC  
   understands the I flag that indicates LSP-INSTANTIATION-CAPABILITY 
   but did not advertise this capability, then upon receipt of a 
   PCInitiate message for GMPLS LSP from the PCE, it SHOULD generate a 
   PCErr with error-type 19 ("Invalid Operation"), error-value TBDz 
   ("Attempted LSP Instantiation Request for GMPLS if stateful PCE 
   instantiation capability for GMPLS was not advertised"), and 
   terminate the PCEP session. 

7.2. Error Handling in LSP Re-optimization   

   A stateful PCE is expected to perform an LSP re-optimization when 
   receiving a message with the R bit set in the 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 = 19, Error 
   value= TBD6).  Note that this error message could also be used by 
   non-GMPLS LSPs.  The PCE MAY suppress this error message by a 
   configurable threshold. 
    
7.3. Error Handling in Route Exclusion   

   The LSP exclusion sub-object in XRO is defined in section 6.2.2 of 
   this document MAY be present multiple times.  When a stateful PCE 
   receives a PCEP message carrying this sub-object, it searches for 
   the identified LSP in its LSP-DB and then excludes from the new path 
   computation all the resources used by the identified LSP.  If the 
   stateful PCE cannot recognize symbolic path name of the identified 
   LSP, it SHOULD send an error message PCErr reporting Error-type = 19 
   ("Invalid Operation"), Error-value = TBD7 ("The LSP state 
   information for route exclusion purpose cannot be found").  
   Optionally, it may also provide with the unrecognized symbolic path 
   name information to the requesting PCC using the error reporting 
   techniques described in [RFC5440].  However, the PCE MAY suppress 
   this error message by a configurable threshold. 
    
7.4. Error Handling for generalized END-POINTS   

   Note that the ENDPOINT object in the Stateful PCEP messages was 
   introduced for P2MP [RFC8623]. Similarly, the END-POINTS object MUST 
   be carried for the GMPLS LSP.  If the END-POINTS object is missing 
 
 
Lee & Zheng             Expires December 2022                [Page 12] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

   and the GMPLS flag in LSP-EXTENDED-FLAG is set, the receiving PCE or 
   PCC MUST send a PCErr message with Error-type=6 ("Mandatory Object 
   missing") and Error-value=3 ("END-POINTS object missing") (defined 
   in [RFC5440]). Similarly, if the END-POINTS object with the 
   Generalized Endpoint object type is received but if the LSP-
   EXTENDED-FLAG TLV is missing in the LSP object or if the G flag in 
   the LSP-EXTENDED-FLAG TLV is not set, the receiving PCE or PCC MUST 
   send a PCErr message with Error-type = 19 ("Invalid Operation"), 
   Error-value = TBD9 ("Use of Generalized Endpoint object type for 
   non-GMPLS LSP").    
    
   If the ENDPOINT object with Generalized Endpoint Object Type is 
   missing the LABEL-REQUEST TLV, the receiving PCE or PCC MUST send a 
   PCErr message with Error-type=6 ("Mandatory Object missing") and 
   Error-value=TBD8 ("LABEL-REQUEST TLV missing").  
    
8. 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". 

8.1. Huawei Technologies 

      o  Organization: Huawei Technologies, Co. LTD 
      o  Implementation: Huawei NCE-T  

 
 
Lee & Zheng             Expires December 2022                [Page 13] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

      o  Description: PCRpt, PCUpd and PCInitiate messages for GMPLS 
   Network 
      o  Maturity Level: Production 
      o  Coverage: Full 
      o  Contact: zhenghaomian@huawei.com 

9. IANA Considerations 

9.1. New Flags in GMPLS-CAPABILITY TLV 

   [RFC8779] defines the GMPLS-CAPABILITY TLV; per that RFC, IANA 
   created a registry to manage the value of the GMPLS-CAPABILITY TLV's 
   Flag field.  This document requests IANA to allocate new bits in the 
   GMPLS-CAPABILITY TLV Flag Field registry, as follows: 

       Bit  Description                      Reference 
       ---  -------------------------------- ------------- 
       TBDa   LSP-REPORT-CAPABILITY (R)         [This.I-D] 
       TBD1   LSP-UPDATE-CAPABILITY (U)         [This.I-D] 
       TBD2   LSP-INSTANTIATION-CAPABILITY (I)  [This.I-D] 

9.2. New Sub-object for the Exclude Route Object 

   IANA maintains the various XRO Subobjects types within the "XRO 
   Subobjects" subregistry of the PCEP Numbers registry.  IANA is 
   requested to allocate a codepoint for another XRO subobject as 
   follows: 

   Value       Description                    Reference  
  ----------+------------------------------+------------- 
    TBD3        LSP                            [This.I-D] 

9.3. Flags Field for LSP exclusion Sub-object 

   IANA is requested to create a registry to manage the Flag field of 
   the LSP Exclusion sub-object in the XRO.  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] 

   New values are to be assigned by Standards Action [RFC8126].     
   Each bit should be tracked with the following qualities: 

      o  Bit number (counting from bit 0 as the most significant bit) 
      o  Capability description 
      o  Defining RFC 
 
 
Lee & Zheng             Expires December 2022                [Page 14] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

9.4. New  Flags in the LSP-EXTENDED-FLAGS TLV 

   [I-D.ietf-pce-lsp-extended-flags] requested IANA to create a 
   subregistry, named the "LSP-EXTENDED-FLAG TLV Flag Field", within 
   the "Path Computation Element Protocol (PCEP) Numbers" registry, to 
   manage the Flag field of the LSP-EXTENDED-FLAG TLV. 

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

       Bit      Description                        Reference 
       ---      ----------------------------       ---------- 
       TBDb     GMPLS LSP (G)                      [This.I-D] 
       TBD4     Bi-directional co-routed LSP (B)   [This.I-D] 
       TBDc*    Routing Granularity Flag (RG)      [This.I-D] 
    
   * - 2 bits needs to be allocated 
    
9.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        | Error-value             | Reference | 
   +===========+================+=========================+===========+ 
   | 6         | Mandatory      | TBD8: LABEL-REQUEST TLV | This I-D  | 
   |           | Object missing | missing                 |           | 
   |-----------|----------------+-------------------------+-----------+ 
   |19         | Invalid        | TBD6: LSP state info    | This I-D  | 
   |           | Operation      | unavailable for the     |           | 
   |           |                | Re-optimization         |           | 
   |           |                +-------------------------+-----------+ 
   |           |                |TBD7: LSP state info for | This I-D  | 
   |           |                |route exclusion not found|           | 
   |           |                +-------------------------+-----------+ 
   |           |                | TBDx: Attempted LSP     | This I-D  | 
   |           |                | Update Request for GMPLS|           | 
   |           |                | if stateful PCE         |           | 
   |           |                |capability not advertised|           | 
   |           |                +-------------------------+-----------+ 
   |           |                |TBDy: Attempted LSP State| This I-D  | 
   |           |                |Report for GMPLS if      |           | 
   |           |                |stateful PCE capability  |           | 
   |           |                |not advertised           |           | 
   |           |                +-------------------------+-----------+ 
   |           |                |TBDz: Attempted LSP      | This I-D  | 
   |           |                |Instantiation Request for|           | 
 
 
Lee & Zheng             Expires December 2022                [Page 15] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

   |           |                |GMPLS if stateful PCE    |           | 
   |           |                |instantiation capability |           | 
   |           |                |not advertised           |           | 
   |           |                +-------------------------+-----------+ 
   |           |                | TBD9: use of Generalized| This I-D  | 
   |           |                | Endpoint object type for|           | 
   |           |                | non-GMPLS LSP           |           | 
   +-----------+----------------+-------------------------+-----------+ 

10. Manageability Considerations 

   General PCE management considerations are discussed in [RFC4655] and 
   [RFC5440], and GMPLS specific PCEP management considerations are 
   described in [RFC8779].  In this document the management 
   considerations for stateful PCEP extension in GMPLS are described.  

   This section follows the guidance of [RFC6123]. 

10.1. Control of Function through Configuration and Policy 

   In addition to the parameters already listed in Section 8.1 of 
   [RFC5440], a PCEP implementation SHOULD allow configuration of the 
   following PCEP session parameters on a PCC: 

   o  The ability to send stateful PCEP messages for GMPLS LSPs. 

   o  The ability to use path computation constraints (e.g, XRO).  

   In addition to the parameters already listed in Section 8.1 of 
   [RFC5440], a PCEP implementation SHOULD allow configuration of the 
   following PCEP session parameters on a PCE: 

   o  The ability to compute path in a stateful manner in GMPLS 
   networks. 

   o  A set of GMPLS-specific constraint. 

   These parameters may be configured as default parameters for any 
   PCEP session the PCEP speaker participates in, or they may apply to 
   a specific session with a given PCEP peer or a specific group of 
   sessions with a specific group of PCEP peers. 

10.2. Information and Data Models 

   The YANG model in [I-D.ietf-pce-pcep-yang] can be used to configure 
   and monitor PCEP states and messages. To make sure that the YANG 
   model is useful for the extensions as described in this document, it 

 
 
Lee & Zheng             Expires December 2022                [Page 16] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

   would need to include advertised GMPLS stateful capabilities etc. A 
   future version of [I-D.ietf-pce-pcep-yang] will include this.    

   As described in [I-D.ietf-teas-yang-path-computation], a YANG-based 
   interface can be used in some cases to request GMPLS path 
   computations, instead of PCEP. Refer [I-D.ietf-teas-yang-path-
   computation] for details.   

10.3. Liveness Detection and Monitoring 

   This document makes no change to the basic operation of PCEP, so 
   there are no changes to the requirements for liveness detection and 
   monitoring in [RFC4657] and [RFC5440], Section 8.3. 

10.4. Verifying Correct Operation 

   This document makes no change to the basic operations of PCEP and 
   the considerations described in [RFC5440], Section 8.4.  New errors 
   defined by this document should satisfy the requirement to log error 
   events. 

10.5. 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 requires the ingress node of an LSP carry the 
   RRO object in order to enable the collection of such information.  

10.6. Impact on Network Operation 

   This document makes no change to the basic operations of PCEP and 
   the considerations described in [RFC5440], Section 8.6.  In addition 
   to the limit on the rate of messages sent by a PCEP speaker, a limit 
   MAY be placed on the size of the PCEP messages. 

11. Security Considerations 

   The security considerations elaborated in [RFC5440] apply to this 
   document.  The PCEP extensions to support GMPLS-controlled networks 
   should be considered under the same security as for MPLS networks, 
   as noted in [RFC7025].  So the PCEP extension to support GMPLS 
   specified in [RFC8779] is used as the foundation of this document 
   and the security considerations in [RFC8779] should also be 
   applicable to this document.  The secure transport of PCEP specified 
   in [RFC8253] allows the usage of Transport Layer Security (TLS).  
   The same can also be used by the PCEP extension defined in this 
   document.  

 
 
Lee & Zheng             Expires December 2022                [Page 17] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

   This draft provides additional extensions to PCEP so as to 
   facilitate stateful PCE usage in GMPLS-controlled networks, on top 
   of [RFC8231] and [RFC8281].  Security issues caused by the extension 
   in [RFC8231] and RFC8281] are not altered by the additions in this 
   draft.  The security considerations in [RFC8231] and [RFC8281], 
   including both issues and solutions, apply to this document as well. 

12. Acknowledgement 

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

   Thanks to Dhruv Dhody for Shepherding this document and providing 
   useful comments. 

13. References 

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

   [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., Dhody, D., "PCEPS: 
             Usage of TLS to Provide a Secure Transport for the Path 
             Computation Element Communication Protocol (PCEP)", RFC 
             8253, October 2017. 

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

 
 
Lee & Zheng             Expires December 2022                [Page 18] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

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

   [I-D.ietf-pce-lsp-extended-flags] Xiong, Q., "LSP Object Flag 
             Extension of Stateful PCE", Work in progress.  

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

   [RFC4657]  Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation 
             Element (PCE) Communication Protocol Generic Requirements", 
             RFC 4657, September 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 December 2022                [Page 19] 


Internet-Draft         Stateful PCEP for GMPLS               June 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.  

   [RFC6123]  Farrel, A., "Inclusion of Manageability Sections in Path          
             Computation Element (PCE) Working Group Drafts", RFC 6123,         
             February 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. 

   [RFC8126]  Cotton M., Leiba, B., Narten, T., "Guidelines for Writing 
             an IANA Considerations Section in RFCs ", June, 2017.  

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

   [RFC8745]  Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 
             Negi, M., "Path Computation Element Communication Protocol 
             (PCEP) Extensions for Associating Working and Protection 
             Label Switched Paths (LSPs) with Stateful PCE", March 2020.  

   [I-D.ietf-pce-pcep-yang] Dhody, D., Hardwick, J., Beeram, V., 
             Tantsura, J., "A YANG Data Model for Path Computation 
             Element Communications Protocol (PCEP)", Work in progress. 

   [I-D.ietf-teas-yang-path-computation] Busi, I., Belotti, S., 
             Gonzalez de Dios, O., Sharma. A., Ceccarelli, D., "A YANG 
             Data Model for requesting path computation", Work in 
             progress.  

 
 
Lee & Zheng             Expires December 2022                [Page 20] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

14. 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 
    
   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 
    
Appendix A: PCEP Messages  

   This section uses the Routing Backus-Naur Form (RBNF) [RFC5511] to 
   illustrate the PCEP messages. The RBNF in this section is reproduced 
   for informative purposes. It is also expanded to show the GMPLS 
   specific objects.  

 
 
Lee & Zheng             Expires December 2022                [Page 21] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

A.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>] 
                            <LSP> 
                    [<END-POINTS>] 
                            <path> 
   Where: 
         <path>::= <intended-path> 
                   [<actual-attribute-list><actual-path>] 
                   <intended-attribute-list> 
         <actual-attribute-list>::=[<BANDWIDTH>] 
                                   [<metric-list>] 

   Where: 

     The END-POINTS object MUST be carried in a PCRpt message when the 
   G flag is set in the LSP-EXTENDED-FLAG TLV in the LSP object for a 
   GMPLS LSP. 

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

     <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 as shown below: 

       <attribute-list>::=[<of-list>] 
                               [<LSPA>] 
 
 
Lee & Zheng             Expires December 2022                [Page 22] 


Internet-Draft         Stateful PCEP for GMPLS               June 2022 
    

                               [<BANDWIDTH>] 
                               [<metric-list>] 
                               [<IRO>][<XRO>] 
                               [<INTER-LAYER>] 
                               [<SWITCH-LAYER>] 
                               [<REQ-ADAP-CAP>] 
                               [<SERVER-INDICATION>] 

   A.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> 
                              [<END-POINTS>] 
                              <path> 
   Where: 
         <path>::= <intended-path><intended-attribute-list> 

   Where: 

      The END-POINTS object MUST be carried in a PCUpd message for the 
   GMPLS LSP. 

      <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 and as shown for PCRpt above. 

A.3 The PCInitiate Message 

     According to [RFC8281], the PCInitiate Message is used allow 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 December 2022                [Page 23] 


Internet-Draft         Stateful PCEP for GMPLS               June 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]. All fields are similar to the PCRpt and the PCUpd 
   message.  

 

 
 
Lee & Zheng             Expires December 2022                [Page 24] 


Internet-Draft         Stateful PCEP for GMPLS               June 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 December 2022                [Page 25]