doc: Add RFC documents

1 files changed, 1168 insertions, 0 deletions

diff --git a/doc/rfc/rfc9504.txt b/doc/rfc/rfc9504.txt
new file mode 100644
index 0000000..154b2fe
--- /dev/null
+++ b/doc/rfc/rfc9504.txt
@@ -0,0 +1,1168 @@
+
+
+
+
+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