diff options
Diffstat (limited to 'doc/rfc/rfc9504.txt')
| -rw-r--r-- | doc/rfc/rfc9504.txt | 1168 |
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 |