Samsung

younglee.tx@gmail.com

Huawei Technologies

zhenghaomian@huawei.com

Telefonica

oscar.gonzalezdedios@telefonica.com

Nokia

victor.lopez@nokia.com

Cisco

zali@cisco.com

rtg pce Stateful PCE GMPLS PCE-initiated LSP 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 .

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 () 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

• .  Introduction
  • .  Conventions Used in This Document
• .  Terminology
• .  General Context of Stateful PCE and PCEP for GMPLS
• .  Main Requirements
• .  Overview of Stateful PCEP Extensions for GMPLS Networks
  • .  Capability Advertisement for Stateful PCEP in GMPLS
  • .  LSP Synchronization
  • .  LSP Delegation and Cleanup
  • .  LSP Operations
• .  PCEP Object Extensions
  • .  Existing Extensions Used for Stateful GMPLS
  • .  New Extensions
    • .  GMPLS-CAPABILITY TLV in OPEN Object
    • .  New LSP Exclusion Subobject in the XRO
    • .  New Flags in the LSP-EXTENDED-FLAG TLV in LSP Object
• .  Update to Error Handling
  • .  Error Handling in PCEP Capabilities Advertisement
  • .  Error Handling in LSP Reoptimization
  • .  Error Handling in Route Exclusion
  • .  Error Handling for the Generalized END-POINTS Object
• .  IANA Considerations
  • .  New Flags in the GMPLS-CAPABILITY TLV
  • .  New Subobject for the Exclude Route Object
  • .  Flags Field for the LSP Exclusion Subobject
  • .  New Flags in the LSP-EXTENDED-FLAGS TLV
  • .  New PCEP Error Codes
• .  Manageability Considerations
  • .  Control of Function through Configuration and Policy
  • .  Information and Data Models
  • .  Liveness Detection and Monitoring
  • .  Verifying Correct Operation
  • .  Requirements on Other Protocols and Functional Components
  • .  Impact on Network Operation
• . Security Considerations
• . References
  • .  Normative References
  • .  Informative References
• .  PCEP Messages
  • .  The PCRpt Message
  • .  The PCUpd Message
  • .  The PCInitiate Message
• Acknowledgements
• Contributors
• Authors' Addresses

Introduction 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". 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 . Stateful PCEs are shown to be helpful in many application scenarios, in both MPLS and GMPLS networks, as illustrated in . Further discussion of the concept of a stateful PCE can be found in . In order for these applications to be able to exploit the capability of stateful PCEs, extensions to stateful PCEP for GMPLS are required. 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. 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, 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. 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 . An overview of the PCEP extensions is specified in . A solution to address such requirements with PCEP object extensions is specified in .

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 when, and only when, they appear in all capitals, as shown here.

Terminology Terminology used in this document is the same as terminology used in , , , and .

General Context of Stateful PCE and PCEP for GMPLS This section is built on the basis of stateful PCEs specified in and PCEP for GMPLS specified in . The operation of a stateful PCE on LSPs can be divided into two types: active stateful PCE and passive stateful PCE (as described in ).

• 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 , 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 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. 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 , and the GMPLS-specific extensions are also included in this document.

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 . 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 (such as LSP update, delegation, and state synchronization/report). Protection context information that describes the GMPLS requirement can also follow the description in . 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 . The GMPLS-CAPABILITY TLV specified in 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 and . 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 and .

Overview of Stateful PCEP Extensions for GMPLS Networks

Capability Advertisement for Stateful PCEP in GMPLS Capability advertisement is specified in ; it can be achieved by using the STATEFUL-PCE-CAPABILITY TLV in the Open message. Another GMPLS-CAPABILITY TLV is defined in . A subregistry to manage the Flag field of the GMPLS-CAPABILITY TLV has been created by IANA as requested by . 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).

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 , 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 . The format of the PCRpt message is specified in and extended in to include the END-POINTS object. The END-POINTS object is extended for GMPLS in . The END-POINTS object can be carried in the PCRpt message as specified in . 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 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 (as the attribute-list defined in and extended by many other documents that define PCEP extensions for specific scenarios). The SWITCH-LAYER object is defined in . This object is carried in the PCRpt message as specified in .

LSP Delegation and Cleanup The LSP delegation and cleanup procedure specified in are equally applicable to GMPLS LSPs and this document does not modify the associated usage.

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

PCEP Object Extensions

Existing Extensions Used for Stateful GMPLS Existing extensions defined in 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 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 , 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 MUST be used to specify the unnumbered endpoint addresses.
• The Generalized END-POINTS object MAY contain other TLVs defined in .

RP:

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

BANDWIDTH:

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

LSPA:

LSPA Extensions in are applicable in stateful PCEP for GMPLS networks.

IRO:

IRO Extensions in are applicable in stateful PCEP for GMPLS networks.

XRO:

XRO Extensions in are applicable in stateful PCEP for GMPLS networks. A new flag is defined in of this document.

ERO:

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

SWITCH-LAYER:

The SWITCH-LAYER definition in is applicable in stateful PCEP messages for GMPLS networks.

New Extensions

GMPLS-CAPABILITY TLV in OPEN Object In , 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.

New LSP Exclusion Subobject in the XRO 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 . The LSP Exclusion subobject is as follows:

New LSP Exclusion Subobject Format 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 // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

X:

This field is the same as the X-bit defined in the XRO subobjects in 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 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.

New Flags in the LSP-EXTENDED-FLAG TLV in LSP Object The LSP object is defined in , and the new extended flags TLV is defined in . 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 :

00:

reserved

01:

node

10:

link

11:

label

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 . Please note that all error handling specified in is applicable and MUST be supported for a stateful PCE in GMPLS networks.

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

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.

Error Handling in Route Exclusion The LSP Exclusion subobject in XRO, as defined in 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 . 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.

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

IANA Considerations

New Flags in the GMPLS-CAPABILITY TLV 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

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

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

New values are to be assigned by Standards Action . 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

New Flags in the LSP-EXTENDED-FLAGS TLV 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

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 Object missing	20: LABEL-REQUEST TLV missing	RFC 9504
19	Invalid Operation	23: LSP state info unavailable for reoptimization	RFC 9504
		24: LSP state info for route exclusion not found	RFC 9504
		25: Attempted LSP update request for GMPLS if stateful PCE capability not advertised	RFC 9504
		26: Attempted LSP State Report for GMPLS if stateful PCE capability not advertised	RFC 9504
		27: Attempted LSP instantiation request for GMPLS if stateful PCE instantiation capability not advertised	RFC 9504
		28: Use of the Generalized Endpoint object type for non-GMPLS LSPs	RFC 9504

Manageability Considerations General PCE management considerations are discussed in and , and GMPLS-specific PCEP management considerations are described in . In this document, the management considerations for stateful PCEP extension in GMPLS are described. This section follows the guidance of .

Control of Function through Configuration and Policy In addition to the parameters already listed in , 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 , 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.

Information and Data Models The YANG module in 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 will include this. As described in , a YANG-based interface can be used in some cases to request GMPLS path computations, instead of PCEP. Refer to for details.

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

Verifying Correct Operation This document makes no change to the basic operations of PCEP and the considerations described in . New errors defined by this document should satisfy the requirement to log error events.

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.

Impact on Network Operation The management considerations concerning the impact on network operations described in apply here.

Security Considerations The security considerations elaborated in 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 . Therefore, the PCEP extension to support GMPLS specified in is used as the foundation of this document; the security considerations in should also be applicable to this document. The secure transport of PCEP specified in 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 and . Security issues caused by the extension in and are not altered by the additions in this document. The security considerations in and , including both issues and solutions, apply to this document as well.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF. There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation. Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work. This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols. [STANDARDS-TRACK] The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. When a Path Computation Client (PCC) requests a PCE for a route, it may be useful for the PCC to specify, as constraints to the path computation, abstract nodes, resources, and Shared Risk Link Groups (SRLGs) that are to be explicitly excluded from the computed route. Such constraints are termed "route exclusions". The PCE Communication Protocol (PCEP) is designed as a communication protocol between PCCs and PCEs. This document presents PCEP extensions for route exclusions. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP. This document updates RFC 5440 in regards to the PCEP initialization phase procedures. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. A Path Computation Element (PCE) provides path computation functions for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Additional requirements for GMPLS are identified in RFC 7025. This memo provides extensions to the Path Computation Element Communication Protocol (PCEP) for the support of the GMPLS control plane to address those requirements. RFC 8231 describes a set of extensions to the Path Computation Element Communication Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the extensions is the LSP object, which includes a Flag field with a length of 12 bits. However, all bits of the Flag field have already been assigned. This document defines a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended Flag field. Informative References Huawei Juniper Networks Microsoft Nvidia Work in Progress This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents. [STANDARDS-TRACK] This document describes extensions to Multi-Protocol Label Switching (MPLS) Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a RSVP-TE specific description of the extensions. A generic functional description can be found in separate documents. [STANDARDS-TRACK] Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community. This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK] This document describes protocol specific procedures for GMPLS (Generalized Multi-Protocol Label Switching) RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) signaling extensions to support label switched path (LSP) segment protection and restoration. These extensions are intended to complement and be consistent with the RSVP-TE Extensions for End-to-End GMPLS Recovery (RFC 4872). Implications and interactions with fast reroute are also addressed. This document also updates the handling of NOTIFY_REQUEST objects. [STANDARDS-TRACK] It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements. The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group. Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference. This document defines a Historic Document for the Internet community. The initial effort of the PCE (Path Computation Element) WG focused mainly on MPLS. As a next step, this document describes functional requirements for GMPLS applications of PCE. The Path Computation Element (PCE) architecture is set out in RFC 4655. The architecture is extended for multi-layer networking with the introduction of the Virtual Network Topology Manager (VNTM) in RFC 5623 and generalized to Hierarchical PCE (H-PCE) in RFC 6805. These three architectural views of PCE deliberately leave some key questions unanswered, especially with respect to the interactions between architectural components. This document draws out those questions and discusses them in an architectural context with reference to other architectural components, existing protocols, and recent IETF efforts. This document does not update the architecture documents and does not define how protocols or components must be used. It does, however, suggest how the architectural components might be combined to provide advanced PCE function. A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic-engineering calculations for its associated Path Computation Clients (PCCs). This document describes general considerations for a stateful PCE deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCE Communication Protocol (PCEP) extensions required for stateful PCE usage are covered in separate documents. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. A stateful Path Computation Element (PCE) has access to not only the information disseminated by the network's Interior Gateway Protocol (IGP) but also the set of active paths and their reserved resources for its computation. The additional Label Switched Path (LSP) state information allows the PCE to compute constrained paths while considering individual LSPs and their interactions. This requires a State Synchronization mechanism between the PCE and the network, the PCE and Path Computation Clients (PCCs), and cooperating PCEs. The basic mechanism for State Synchronization is part of the stateful PCE specification. This document presents motivations for optimizations to the base State Synchronization procedure and specifies the required Path Computation Element Communication Protocol (PCEP) extensions. The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. MPLS and GMPLS networks may be constructed from layered service networks. It is advantageous for overall network efficiency to provide end-to-end traffic engineering across multiple network layers through a process called inter-layer traffic engineering. PCE is a candidate solution for such requirements. The PCE Communication Protocol (PCEP) is designed as a communication protocol between Path Computation Clients (PCCs) and PCEs. This document presents PCEP extensions for inter-layer traffic engineering. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs. An active stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or more LSPs to provide end-to-end path protection. Huawei Technologies Nokia Telefonica Google China Unicom Work in Progress

PCEP Messages This section uses the Routing Backus-Naur Form (RBNF) 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.

The PCRpt Message According to , 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 and augmented in with ELC.
• <actual-attribute-list> consists of the actual computed and signaled values of the <BANDWIDTH> and <metric-lists> objects defined in .
• <actual-path> is represented by the RRO object defined in .
• <intended-attribute-list> is the attribute-list defined in 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>]

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 , augmented in with ELC.
• <intended-attribute-list> is the attribute-list defined in and extended by many other documents that define PCEP extensions for specific scenarios and as shown for PCRpt above.

The PCInitiate Message According to , 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 . All fields are similar to the PCRpt and the PCUpd messages.

Acknowledgements We would like to thank , , , , , and for the useful comments and discussions. Thanks to for Shepherding this document and providing useful comments.

Contributors Huawei Technologies

zhang.xian@huawei.com

Huawei Technology

India dhruv.ietf@gmail.com

Huawei Technologies

yi.lin@huawei.com

Huawei Technologies

zhangfatai@huawei.com

CTTC

Av. Carl Friedrich Gauss n7 Barcelona Castelldefels 08860 Spain ramon.casellas@cttc.es

Cisco Systems

msiva@cisco.com

Cisco Systems

cfilsfil@cisco.com

Pantheon Technologies

nite@hq.sk

Authors' Addresses Samsung

younglee.tx@gmail.com

Huawei Technologies

zhenghaomian@huawei.com

Telefonica

oscar.gonzalezdedios@telefonica.com

Nokia

victor.lopez@nokia.com

Cisco

zali@cisco.com