path: root/doc/rfc/rfc9504.txt

Internet Engineering Task Force (IETF)                            Y. Lee
Request for Comments: 9504                                       Samsung
Category: Standards Track                                       H. Zheng
ISSN: 2070-1721                                      Huawei Technologies
                                                     O. Gonzalez de Dios
                                                              Telefonica
                                                                V. Lopez
                                                                   Nokia
                                                                  Z. Ali
                                                                   Cisco
                                                           December 2023


 Path Computation Element Communication Protocol (PCEP) Extensions for
            Stateful PCE Usage in GMPLS-Controlled Networks

Abstract

   The Path Computation Element 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; however, 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 is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9504.

Copyright Notice

   Copyright (c) 2023 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
   (https://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

   1.  Introduction
     1.1.  Conventions Used in This Document
   2.  Terminology
   3.  General Context of Stateful PCE and PCEP for GMPLS
   4.  Main Requirements
   5.  Overview of Stateful PCEP Extensions for GMPLS Networks
     5.1.  Capability Advertisement for Stateful PCEP in GMPLS
     5.2.  LSP Synchronization
     5.3.  LSP Delegation and Cleanup
     5.4.  LSP Operations
   6.  PCEP Object Extensions
     6.1.  Existing Extensions Used for Stateful GMPLS
     6.2.  New Extensions
       6.2.1.  GMPLS-CAPABILITY TLV in OPEN Object
       6.2.2.  New LSP Exclusion Subobject in the XRO
       6.2.3.  New Flags in the LSP-EXTENDED-FLAG TLV in LSP Object
   7.  Update to Error Handling
     7.1.  Error Handling in PCEP Capabilities Advertisement
     7.2.  Error Handling in LSP Reoptimization
     7.3.  Error Handling in Route Exclusion
     7.4.  Error Handling for the Generalized END-POINTS Object
   8.  IANA Considerations
     8.1.  New Flags in the GMPLS-CAPABILITY TLV
     8.2.  New Subobject for the Exclude Route Object
     8.3.  Flags Field for the LSP Exclusion Subobject
     8.4.  New Flags in the LSP-EXTENDED-FLAGS TLV
     8.5.  New PCEP Error Codes
   9.  Manageability Considerations
     9.1.  Control of Function through Configuration and Policy
     9.2.  Information and Data Models
     9.3.  Liveness Detection and Monitoring
     9.4.  Verifying Correct Operation
     9.5.  Requirements on Other Protocols and Functional Components
     9.6.  Impact on Network Operation
   10. Security Considerations
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Appendix A.  PCEP Messages
     A.1.  The PCRpt Message
     A.2.  The PCUpd Message
     A.3.  The PCInitiate Message
   Acknowledgements
   Contributors
   Authors' Addresses

1.  Introduction

   [RFC4655] presents the architecture of a 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 a
   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 the concept of a stateful PCE can be found in
   [RFC7399].  In order for these applications to be able to exploit the
   capability of stateful PCEs, extensions to stateful PCEP for GMPLS
   are required.

   [RFC8051] describes how a stateful PCE can be applied 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 documents omit the specification for
   technology-specific objects and TLVs, and they do not cover GMPLS-
   controlled networks (e.g., Wavelength Switched Optical Network
   (WSON), Optical Transport Network (OTN), Synchronous Optical Network
   (SONET) / Synchronous Digital Hierarchy (SDH)).

   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 PCEs 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 is specified in Section 5.  A solution to address such
   requirements with PCEP object extensions is specified 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 PCEs specified in
   [RFC8231] and PCEP for GMPLS specified in [RFC8779].

   The operation of a stateful PCE on LSPs can be divided into two
   types: active stateful PCE and passive stateful PCE (as described in
   [RFC8051]).

   *  For active stateful PCEs, a Path Computation Update Request
      (PCUpd) message is sent from the PCE to the 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 the PCE to convey the changes of the LSPs.
      Any modifications to the objects and TLVs that are identified in
      this document to support GMPLS-specific attributes will be carried
      in the PCRpt and PCUpd messages.

   *  For passive stateful PCEs, Path Computation Request (PCReq) and
      Path Computation Reply (PCRep) messages are used to request path
      computation.  GMPLS-specific objects and TLVs are defined in
      [RFC8779], which this document builds on and adds the stateful PCE
      aspects where applicable.  A passive stateful PCE makes use of
      PCRpt messages when reporting LSP state changes sent by PCCs to
      PCEs.  Any modifications to the objects and TLVs that are
      identified in this document to support GMPLS-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 and TLVs that are identified in this document to support
   GMPLS-specific attributes will be carried in the PCInitiate messages.

   [RFC8779] defines GMPLS-specific objects and TLVs in stateless PCEP;
   this document makes use of these objects and TLVs without
   modifications where applicable.  Where these objects and TLVs require
   modifications to incorporate stateful PCEs, 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 PCEs 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 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 that are specific to
   the use of a stateful PCE in a GMPLS-controlled network.

   The requirements for GMPLS-specific stateful PCEs are as follows:

   *  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 need to be advertised as well.

   *  All the PCEP messages need to be capable of indicating GMPLS-
      specific switching capabilities.  GMPLS LSP creation,
      modification, and deletion require knowledge of LSP switching
      capabilities (e.g., Time-Division Multiplex Capable (TDM), Layer 2
      Switch Capable (L2SC), OTN-TDM, Lambda Switch Capable (LSC), etc.)
      and the Generalized Payload Identifier (G-PID) to be used
      according to [RFC3471] and [RFC3473].  It also requires that
      traffic parameters that are both data flow and technology specific
      be defined.  These traffic parameters are also known as "Traffic
      Specification" or "Tspec".  Such information would need to be
      included in various PCEP messages.

   *  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; hence, a
      path computed by the PCE is associated with a specific lambda
      (label).  Thus, 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
      (ELC) may be required.

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

5.  Overview of Stateful PCEP Extensions for GMPLS Networks

5.1.  Capability Advertisement for Stateful PCEP in GMPLS

   Capability advertisement is specified in [RFC8231]; it can be
   achieved by using the STATEFUL-PCE-CAPABILITY TLV in the Open
   message.  Another GMPLS-CAPABILITY TLV is defined in [RFC8779].  A
   subregistry to manage the Flag field of the GMPLS-CAPABILITY TLV has
   been created by IANA as requested by [RFC8779].  The following bits
   are introduced by this document in the GMPLS-CAPABILITY TLV as flags
   to indicate the capability for LSP report, update, and initiation in
   GMPLS networks: LSP-REPORT-CAPABILITY (31), LSP-UPDATE-CAPABILITY
   (30), and LSP-INSTANTIATION-CAPABILITY (29).

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 as the reporting of new
   or modified LSPs during normal operation.  Incremental LSP-DB
   synchronization may be desired in a GMPLS-controlled network; 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 following objects are extended for GMPLS in [RFC8779] and are
   also used in the PCRpt in the same manner: BANDWIDTH, LSP Attributes
   (LSPA), Include Route Object (IRO), and Exclude Route Object (XRO).
   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 the PCRpt message as specified in Section 3.2 of
   [RFC8282].

5.3.  LSP Delegation and Cleanup

   The LSP delegation and cleanup procedure specified in [RFC8281] 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.  PCEP Object Extensions

6.1.  Existing Extensions Used for Stateful GMPLS

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

   END-POINTS:  The END-POINTS object was specified in [RFC8779] to
      include GMPLS capabilities.  All stateful PCEP messages MUST
      include the END-POINTS object 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 and/
         or LABEL-SET TLV.  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 object MAY contain other TLVs
         defined in [RFC8779].

   RP:  The Request Parameter (RP) object extension (together with the
      Routing Granularity (RG) flag defined in [RFC8779]) is applicable
      in stateful PCEP for GMPLS networks.

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

   LSPA:  LSPA Extensions in Section 2.8 of [RFC8779] are applicable in
      stateful PCEP for GMPLS networks.

   IRO:  IRO Extensions in Section 2.6 of [RFC8779] are applicable in
      stateful PCEP for GMPLS networks.

   XRO:  XRO Extensions in Section 2.7 of [RFC8779] are applicable in
      stateful PCEP for GMPLS networks.  A new flag is defined in
      Section 6.2.3 of this document.

   ERO:  The Explicit Route Object (ERO) is not extended in [RFC8779],
      nor is it in this document.

   SWITCH-LAYER:  The SWITCH-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 allocates value 45 (GMPLS-CAPABILITY) from the
   "PCEP TLV Type Indicators" subregistry.  This specification adds
   three flags to the Flag field of this TLV to indicate the Report,
   Update, and Initiation capabilities.

   R (LSP-REPORT-CAPABILITY (31) -- 1 bit):
      If set to 1 by a PCC, the R flag indicates that the PCC is capable
      of reporting the current state of a 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 (30) -- 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 (29) -- 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 Subobject in the XRO

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

   To this end, this document defines a new subobject for use with route
   exclusion defined in [RFC5521].  The LSP Exclusion subobject 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 (11)    |     Length    |   Reserved    |    Flags      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                    Symbolic Path Name                       //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: New LSP Exclusion Subobject Format

   X:  This field is the same as the X-bit defined in the XRO subobjects
      in Section 2.1.1 of [RFC5521] where it says:

         The X-bit indicates whether the exclusion is mandatory or
         desired.  0 indicates that the resource specified MUST be
         excluded from the path computed by the PCE.  1 indicates that
         the resource specified SHOULD be excluded from the path
         computed by the PCE, but MAY be included subject to PCE policy
         and the absence of a viable path that meets the other
         constraints and excludes the resource.

   Type:  The subobject type for an LSP Exclusion subobject.  Value of
      11.

   Length:  The Length contains the total length of the subobject in
      bytes, including the Type and Length fields.

   Reserved:  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.  Its
      syntax and semantics are identical to those of the Symbolic Path
      Name field defined in Section 7.3.2 of [RFC8231] where it says:
      "symbolic name for the LSP, unique in the PCC.  It SHOULD be a
      string of printable ASCII characters, without a NULL terminator."
      The symbolic path name in the LSP Exclusion subobject MUST only
      vary from being a string of printable ASCII characters without a
      NULL terminator when it is matching the value contained in another
      subobject.  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 or PCC could be excluded.

      This subobject MAY be present multiple times in the XRO to exclude
      resources from multiple LSPs.  When a stateful PCE receives a
      PCReq message carrying this subobject, 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 subobject could also be used by non-GMPLS LSPs.
      The usage of the XRO subobject for any 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 [RFC9357].  This TLV is used in
   PCUpd, PCRpt and PCInitiate messages for GMPLS, with the following
   flags defined in this document:

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

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

   RG (Routing Granularity (2-3) -- 2 bits):
      The RG flag for GMPLS is also defined in the LSP-EXTENDED-FLAG
      TLV.  The values 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.
   This section adds additional error handling procedures to those
   specified in Section 3 of [RFC8779].  Please note that all error
   handling specified in Section 3 of [RFC8779] is applicable and MUST
   be supported for a 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 capabilities MUST NOT be used if the PCE has not advertised its
   capabilities with GMPLS as per Section 6.2.1.

   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
   25 ("Attempted LSP update request for GMPLS if stateful PCE
   capability not advertised") and terminate the PCEP session.  Such a
   PCC MAY decide to utilize the capability even though it did not
   advertise support for it.

   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
   26 ("Attempted LSP State Report for GMPLS if stateful PCE capability
   not advertised") and terminate the PCEP session.  Such a PCE MAY
   decide to utilize the capability even though it did not advertise
   support for it.

   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
   27 ("Attempted LSP instantiation request for GMPLS if stateful PCE
   instantiation capability for not advertised") and terminate the PCEP
   session.  Such a PCC MAY decide to utilize the capability even though
   it did not advertise support for it.

7.2.  Error Handling in LSP Reoptimization

   A stateful PCE is expected to perform an LSP reoptimization when
   receiving a message with the R bit set in the RP object.  If no LSP
   state information is available to carry out reoptimization, the
   stateful PCE SHOULD report Error-Type 19 ("Invalid Operation") Error-
   value 23 ("LSP state info unavailable for reoptimization"), although
   such a PCE MAY consider the reoptimization to have successfully
   completed.  Note that this error message could also be used by non-
   GMPLS LSPs.

7.3.  Error Handling in Route Exclusion

   The LSP Exclusion subobject in XRO, as defined in Section 6.2.2 of
   this document, MAY be present multiple times.  When a stateful PCE
   receives a PCEP message carrying this subobject, it searches for the
   identified LSP in its LSP-DB.  It then excludes from the new path
   computation all the resources used by the identified LSP.  If the
   stateful PCE cannot recognize the symbolic path name of the
   identified LSP, it SHOULD send an error message PCErr reporting
   Error-Type 19 ("Invalid Operation") Error-value 24 ("LSP state info
   for route exclusion not found").  Along with the unrecognized
   symbolic path name, it MAY also provide information to the requesting
   PCC using the error-reporting techniques described in [RFC5440].  An
   implementation MAY choose to ignore the requested exclusion when the
   LSP cannot be found because it could claim that it has avoided using
   all resources associated with an LSP that doesn't exist.

7.4.  Error Handling for the Generalized END-POINTS Object

   Note that the END-POINTS object in stateful PCEP messages was
   introduced for Point-to-Multipoint (P2MP) [RFC8623].  Similarly, the
   END-POINTS object MUST be carried for the GMPLS LSP.  If the END-
   POINTS object is missing 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 the LSP-EXTENDED-FLAG TLV is missing in the LSP object or 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 28 ("Use of the Generalized Endpoint object
   type for non-GMPLS LSPs").

   If the END-POINTS 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") Error-
   value 20 ("LABEL-REQUEST TLV missing").

8.  IANA Considerations

8.1.  New Flags in the GMPLS-CAPABILITY TLV

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

          +=====+==================================+===========+
          | Bit | Capability Description           | Reference |
          +=====+==================================+===========+
          | 31  | LSP-REPORT-CAPABILITY (R)        | RFC 9504  |
          +-----+----------------------------------+-----------+
          | 30  | LSP-UPDATE-CAPABILITY (U)        | RFC 9504  |
          +-----+----------------------------------+-----------+
          | 29  | LSP-INSTANTIATION-CAPABILITY (I) | RFC 9504  |
          +-----+----------------------------------+-----------+

                                 Table 1

8.2.  New Subobject for the Exclude Route Object

   IANA maintains the various XRO subobject types within the "XRO
   Subobjects" subregistry of the "Path Computation Element Protocol
   (PCEP) Numbers" registry.  IANA has allocated a codepoint for another
   XRO subobject as follows:

                    +=======+=============+===========+
                    | Value | Description | Reference |
                    +=======+=============+===========+
                    | 11    | LSP         | RFC 9504  |
                    +-------+-------------+-----------+

                                  Table 2

8.3.  Flags Field for the LSP Exclusion Subobject

   IANA has created a registry named "LSP Exclusion Subobject Flag
   Field", within the "Path Computation Element Protocol (PCEP) Numbers"
   group, to manage the Flag field of the LSP Exclusion subobject in the
   XRO.  No flag is currently defined for this Flag field in this
   document.

   Codespace of the Flag field (LSP Exclusion Subobject)

               +=====+========================+===========+
               | Bit | Capability Description | Reference |
               +=====+========================+===========+
               | 0-7 | Unassigned             | RFC 9504  |
               +-----+------------------------+-----------+

                                 Table 3

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

   *  Bit number (counting from bit 0 as the most significant bit)

   *  Capability description

   *  Reference to defining RFC

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

   [RFC9357] 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 has made assignments from this registry as follows:

           +=====+=================================+===========+
           | Bit | Capability Description          | Reference |
           +=====+=================================+===========+
           | 0   | GMPLS LSP (G)                   | RFC 9504  |
           +-----+---------------------------------+-----------+
           | 1   | Bidirectional Co-routed LSP (B) | RFC 9504  |
           +-----+---------------------------------+-----------+
           | 2-3 | Routing Granularity (RG)        | RFC 9504  |
           +-----+---------------------------------+-----------+

                                  Table 4

8.5.  New PCEP Error Codes

   IANA has made the following allocations in the "PCEP-ERROR Object
   Error Types and Values" registry.

    +============+===========+===========================+===========+
    | Error-Type | Meaning   | Error-value               | Reference |
    +============+===========+===========================+===========+
    | 6          | Mandatory | 20: LABEL-REQUEST TLV     | RFC 9504  |
    |            | Object    | missing                   |           |
    |            | missing   |                           |           |
    +------------+-----------+---------------------------+-----------+
    | 19         | Invalid   | 23: LSP state info        | RFC 9504  |
    |            | Operation | unavailable for           |           |
    |            |           | reoptimization            |           |
    |            |           +---------------------------+-----------+
    |            |           | 24: LSP state info for    | RFC 9504  |
    |            |           | route exclusion not found |           |
    |            |           +---------------------------+-----------+
    |            |           | 25: Attempted LSP update  | RFC 9504  |
    |            |           | request for GMPLS if      |           |
    |            |           | stateful PCE capability   |           |
    |            |           | not advertised            |           |
    |            |           +---------------------------+-----------+
    |            |           | 26: Attempted LSP State   | RFC 9504  |
    |            |           | Report for GMPLS if       |           |
    |            |           | stateful PCE capability   |           |
    |            |           | not advertised            |           |
    |            |           +---------------------------+-----------+
    |            |           | 27: Attempted LSP         | RFC 9504  |
    |            |           | instantiation request for |           |
    |            |           | GMPLS if stateful PCE     |           |
    |            |           | instantiation capability  |           |
    |            |           | not advertised            |           |
    |            |           +---------------------------+-----------+
    |            |           | 28: Use of the            | RFC 9504  |
    |            |           | Generalized Endpoint      |           |
    |            |           | object type for non-GMPLS |           |
    |            |           | LSPs                      |           |
    +------------+-----------+---------------------------+-----------+

                                 Table 5

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

9.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.  However, an
   implementation MAY choose to make these features available on all
   PCEP sessions:

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

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

   *  The ability to compute paths in a stateful manner in GMPLS
      networks.

   *  A set of GMPLS-specific constraints.

   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.

9.2.  Information and Data Models

   The YANG module in [PCE-PCEP-YANG] can be used to configure and
   monitor PCEP states and messages.  To make sure that the YANG module
   is useful for the extensions as described in this document, it would
   need to include advertised GMPLS stateful capabilities etc.  A future
   version of [PCE-PCEP-YANG] will include this.

   As described in [YANG-PATH-COMPUTATION], a YANG-based interface can
   be used in some cases to request GMPLS path computations, instead of
   PCEP.  Refer to [YANG-PATH-COMPUTATION] for details.

9.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 Section 8.3 of [RFC5440].

9.4.  Verifying Correct Operation

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

9.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 the LSP State
   Report process), this requires the ingress node of an LSP to carry
   the Record Route Object (RRO) object in order to enable the
   collection of such information.

9.6.  Impact on Network Operation

   The management considerations concerning the impact on network
   operations described in Section 4.6 of [RFC8779] apply here.

10.  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].  Therefore, the PCEP extension to support GMPLS
   specified in [RFC8779] is used as the foundation of this document;
   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.

   This document 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
   document.  The security considerations in [RFC8231] and [RFC8281],
   including both issues and solutions, apply to this document as well.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, DOI 10.17487/RFC5511, April
              2009, <https://www.rfc-editor.org/info/rfc5511>.

   [RFC5521]  Oki, E., Takeda, T., and A. Farrel, "Extensions to the
              Path Computation Element Communication Protocol (PCEP) for
              Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
              2009, <https://www.rfc-editor.org/info/rfc5521>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [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, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

   [RFC8779]  Margaria, C., Ed., Gonzalez de Dios, O., Ed., and F.
              Zhang, Ed., "Path Computation Element Communication
              Protocol (PCEP) Extensions for GMPLS", RFC 8779,
              DOI 10.17487/RFC8779, July 2020,
              <https://www.rfc-editor.org/info/rfc8779>.

   [RFC9357]  Xiong, Q., "Label Switched Path (LSP) Object Flag
              Extension for Stateful PCE", RFC 9357,
              DOI 10.17487/RFC9357, February 2023,
              <https://www.rfc-editor.org/info/rfc9357>.

11.2.  Informative References

   [PCE-PCEP-YANG]
              Dhody, D., Ed., Beeram, V. P., Hardwick, J., and J.
              Tantsura, "A YANG Data Model for Path Computation Element
              Communications Protocol (PCEP)", Work in Progress,
              Internet-Draft, draft-ietf-pce-pcep-yang-22, 11 September
              2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
              pce-pcep-yang-22>.

   [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Functional Description",
              RFC 3471, DOI 10.17487/RFC3471, January 2003,
              <https://www.rfc-editor.org/info/rfc3471>.

   [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
              Switching (GMPLS) Signaling Resource ReserVation Protocol-
              Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
              DOI 10.17487/RFC3473, January 2003,
              <https://www.rfc-editor.org/info/rfc3473>.

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC4657]  Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol Generic
              Requirements", RFC 4657, DOI 10.17487/RFC4657, September
              2006, <https://www.rfc-editor.org/info/rfc4657>.

   [RFC4872]  Lang, J.P., 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, DOI 10.17487/RFC4872, May 2007,
              <https://www.rfc-editor.org/info/rfc4872>.

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
              "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
              May 2007, <https://www.rfc-editor.org/info/rfc4873>.

   [RFC6123]  Farrel, A., "Inclusion of Manageability Sections in Path
              Computation Element (PCE) Working Group Drafts", RFC 6123,
              DOI 10.17487/RFC6123, February 2011,
              <https://www.rfc-editor.org/info/rfc6123>.

   [RFC7025]  Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
              Margaria, "Requirements for GMPLS Applications of PCE",
              RFC 7025, DOI 10.17487/RFC7025, September 2013,
              <https://www.rfc-editor.org/info/rfc7025>.

   [RFC7399]  Farrel, A. and D. King, "Unanswered Questions in the Path
              Computation Element Architecture", RFC 7399,
              DOI 10.17487/RFC7399, October 2014,
              <https://www.rfc-editor.org/info/rfc7399>.

   [RFC8051]  Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
              Stateful Path Computation Element (PCE)", RFC 8051,
              DOI 10.17487/RFC8051, January 2017,
              <https://www.rfc-editor.org/info/rfc8051>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [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,
              DOI 10.17487/RFC8232, September 2017,
              <https://www.rfc-editor.org/info/rfc8232>.

   [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, DOI 10.17487/RFC8282, December
              2017, <https://www.rfc-editor.org/info/rfc8282>.

   [RFC8623]  Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful
              Path Computation Element (PCE) Protocol Extensions for
              Usage with Point-to-Multipoint TE Label Switched Paths
              (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,
              <https://www.rfc-editor.org/info/rfc8623>.

   [RFC8745]  Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
              and M. Negi, "Path Computation Element Communication
              Protocol (PCEP) Extensions for Associating Working and
              Protection Label Switched Paths (LSPs) with Stateful PCE",
              RFC 8745, DOI 10.17487/RFC8745, March 2020,
              <https://www.rfc-editor.org/info/rfc8745>.

   [YANG-PATH-COMPUTATION]
              Busi, I., Ed., Belotti, S., Ed., de Dios, O. G., Sharma,
              A., and Y. Shi, "A YANG Data Model for requesting path
              computation", Work in Progress, Internet-Draft, draft-
              ietf-teas-yang-path-computation-21, 7 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
              yang-path-computation-21>.

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.

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] and augmented in [RFC8779] with ELC.

   *  <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>]
                        [<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 ELC.

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

   <Common Header> is defined in <xref target="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
   messages.

Acknowledgements

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

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

Contributors

   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
   08860 Barcelona Castelldefels
   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


Authors' Addresses

   Young Lee
   Samsung
   Email: younglee.tx@gmail.com


   Haomian Zheng
   Huawei Technologies
   Email: zhenghaomian@huawei.com


   Oscar Gonzalez de Dios
   Telefonica
   Email: oscar.gonzalezdedios@telefonica.com


   Victor Lopez
   Nokia
   Email: victor.lopez@nokia.com


   Zafar Ali
   Cisco
   Email: zali@cisco.com