RFC 9504

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

📅 published December 2023, from ietf

Part 1 of 5 💖

RFC 9504 🎀 Title Block Tea

Okay bestie, first things first: this is RFC 9504, titled "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Usage in GMPLS-Controlled Networks." It's a Standards Track document ✨, published in December 2023, with ISSN 2070-1721.

The authors are Y. Lee (Samsung), H. Zheng (Huawei Technologies), O. Gonzalez de Dios (Telefonica), V. Lopez (Nokia), and Z. Ali (Cisco). The title block doesn't list anything it obsoletes or updates, so it's a standalone spec 🧚

Abstract 🌸

The Path Computation Element Communication Protocol (PCEP) has already been extended to support stateful PCE functions, where the stateful PCE keeps track of information about paths and resource usage within a network. The catch is that these extensions don't cover every requirement for GMPLS networks 🙈

So this document adds the extensions PCEP needs to make the stateful PCE capability usable in GMPLS-controlled networks. It's giving "finally, the missing piece" 💅

Status of This Memo 🦋

This is an Internet Standards Track document.

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841.

For the current status, any errata, and how to send feedback, head to 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) as they stood on the publication date. Please read those carefully, because they explain your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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] lays out 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 do this constrained computation, a PCE stores the network topology (TE links and nodes) and the resource info (TE attributes) in its TE Database (TED). A PCE that only keeps a TED is called a "stateless PCE." [RFC5440] describes the Path Computation Element Communication Protocol (PCEP), which lets a Path Computation Client (PCC) talk to a PCE, or two PCEs talk to each other, so TE LSPs can be computed. PCEP was then extended for GMPLS-controlled networks by [RFC8779] 💜

Stateful PCEs are super helpful in lots of application scenarios, in both MPLS and GMPLS networks, as shown in [RFC8051]. You can read more about the concept of a stateful PCE in [RFC7399]. For these applications to actually use what stateful PCEs can do, stateful PCEP needs extensions for GMPLS. It's giving "necessary upgrade" 🔥

[RFC8051] explains how a stateful PCE can solve different problems for MPLS-TE and GMPLS networks, and what benefits it brings to those deployments 🍓

[RFC8231] defines a set of PCEP extensions for stateful control of TE LSPs. These LSPs are configured on the PCC, and control over them can be delegated to the PCE. [RFC8281] then covers the setup and teardown of PCE-initiated LSPs under the active stateful PCE model, without needing local configuration on the PCC. The thing is, both documents skip the specification for technology-specific objects and TLVs, and neither covers GMPLS-controlled networks (like Wavelength Switched Optical Network (WSON), Optical Transport Network (OTN), and Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH)) 🙈

This document focuses on the extensions needed to deploy stateful PCEs, plus the requirements for PCE-initiated LSPs in GMPLS-controlled networks. Section 3 gives the general context for using stateful PCEs and PCEP for GMPLS. The various requirements for stateful GMPLS, including PCE initiation for GMPLS LSPs, are in Section 4. An overview of the PCEP extensions is in Section 5, and a solution for those requirements using PCEP object extensions is 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. Basically, the capital letters are the whole point, so if it's not in caps, it's just regular English 💅

2. Terminology 🧸

Terminology used in this document is the same as the terminology used in [RFC5440], [RFC8231], [RFC8281], and [RFC8779]. No new vocab here, bestie, just the same squad of terms 🫶

3. General Context of Stateful PCE and PCEP for GMPLS 🌟

This section is built on the stateful PCEs specified in [RFC8231] and the PCEP for GMPLS specified in [RFC8779] ✨

The way a stateful PCE operates on LSPs splits into two types: the active stateful PCE and the passive stateful PCE (as described in [RFC8051]) 🦋

  • For active stateful PCEs, a Path Computation Update Request (PCUpd) message goes from the PCE to the PCC to update the LSP state for the LSPs delegated to the PCE. Any change to the delegated LSPs produces a Path Computation State Report (PCRpt) message from the PCC to the PCE, which conveys the change. Any modifications to the objects and TLVs 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. The GMPLS-specific objects and TLVs are defined in [RFC8779], which this document builds on, adding the stateful PCE aspects where they apply. A passive stateful PCE uses PCRpt messages when it gets LSP state changes that PCCs send to PCEs. Any modifications to the objects and TLVs identified in this document to support GMPLS-specific attributes will be carried in the PCRpt message 🌸

Next up is the LSP Initiation function of PCEP, defined in [RFC8281], which lets the PCE start 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 identified in this document to support GMPLS-specific attributes will be carried in the PCInitiate messages 🧚

[RFC8779] defines GMPLS-specific objects and TLVs for stateless PCEP. This document uses these objects and TLVs without modifications where that works. Where they need changes to support stateful PCEs, those changes are described in this document. PCE-initiated LSPs follow the principle in [RFC8281], and the GMPLS-specific extensions for them are also included in this document. Stay tuned for more, because the good stuff is coming up 👑

4. Main Requirements ✨

okay so this section is the big checklist of what GMPLS-controlled networks need from stateful PCEs 🧚 It's based on [RFC8051], and a lot of it is already covered by [RFC8231] (LSP update, delegation, state sync/report, all that good stuff). Protection context info for GMPLS can follow [RFC8745] too. So this document doesn't re-explain those extensions. It only adds protocol extensions for the GMPLS-specific stuff 💅

The GMPLS-specific stateful PCE requirements are:

  • Advertisement of the stateful PCE capability. This generic requirement is covered in Section 5.4 of [RFC8231]. The GMPLS-CAPABILITY TLV from Section 2.1 of [RFC8779] (and its extension in this document) needs to be advertised as well 🎀
  • All the PCEP messages need to be capable of indicating GMPLS-specific switching capabilities. Creating, modifying, and deleting GMPLS LSPs requires knowing the LSP switching capabilities (like Time-Division Multiplex Capable (TDM), Layer 2 Switch Capable (L2SC), OTN-TDM, Lambda Switch Capable (LSC), and so on) plus the Generalized Payload Identifier (G-PID) to use, per [RFC3471] and [RFC3473]. It also needs traffic parameters that are both data flow and technology specific. These are called "Traffic Specification" or "Tspec" 🦋 That info has to show up in various PCEP messages.
  • Path calculation tied to label selection. In some technologies, path calculation is tightly coupled with label selection along the route. In a Wavelength Division Multiplexing (WDM) network, for example, the calculation might involve lambda continuity and/or lambda feasibility constraints. So a path computed by the PCE is tied to a specific lambda (label) 🌈 That means the label info needs to reach a PCC so a PCE can initiate GMPLS LSPs under the active stateful PCE model. In other words, Explicit Label Control (ELC) may be required.
  • Protection context. Stateful PCEP messages also need to indicate the protection context info for the GMPLS LSP, 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]. You can do it with the STATEFUL-PCE-CAPABILITY TLV in the Open message. There's another GMPLS-CAPABILITY TLV defined in [RFC8779] 💜 IANA made a subregistry to manage the Flag field of that TLV, as [RFC8779] asked. This document adds three bits to the GMPLS-CAPABILITY TLV as flags for capability in LSP report, update, and initiation in GMPLS networks:

  • LSP-REPORT-CAPABILITY (31)
  • LSP-UPDATE-CAPABILITY (30)
  • LSP-INSTANTIATION-CAPABILITY (29)

5.2. LSP Synchronization

Once the session between the PCC and a stateful PCE is initialized, the PCE must learn the state of a PCC's LSPs (including their attributes) before it can do path computations or update LSP attributes at the PCC. This is called "LSP state synchronization" 🔥 The LSP attributes (bandwidth, associated route, protection info, and more) get stored by the PCE in the LSP database (LSP-DB).

As [RFC8231] describes, LSP state synchronization covers both the bulk reporting of LSPs at initialization and the reporting of new or modified LSPs during normal operation. Incremental LSP-DB synchronization may be desired in a GMPLS-controlled network, and it's specified in [RFC8232] 🍓

The PCRpt message format 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], and the END-POINTS object type for GMPLS goes in the PCRpt message the same way.

These objects are extended for GMPLS in [RFC8779] and get used in the PCRpt in the same manner: BANDWIDTH, LSP Attributes (LSPA), Include Route Object (IRO), and Exclude Route Object (XRO). They're carried in the PCRpt message as specified in [RFC8231] (as the attribute-list defined in Section 6.5 of [RFC5440], which other docs extend for specific PCEP scenarios) 🌸

The SWITCH-LAYER object is defined in [RFC8282]. It's 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 in [RFC8281] applies equally to GMPLS LSPs. This document doesn't change how it's used 💅

5.4. LSP Operations

Both the passive and active stateful PCE mechanisms in [RFC8231] apply in GMPLS-controlled networks. Remote LSP Initiation in [RFC8281] also applies there 👑

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. That includes 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. Also worth knowing:
    • 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]) applies 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] apply in stateful PCEP for GMPLS networks.
  • IRO: IRO Extensions in Section 2.6 of [RFC8779] apply in stateful PCEP for GMPLS networks.
  • XRO: XRO Extensions in Section 2.7 of [RFC8779] apply in stateful PCEP for GMPLS networks. There's also a new flag defined in Section 6.2.3 of this document 🌈
  • ERO: The Explicit Route Object (ERO) isn't extended in [RFC8779], and it isn't extended in this document either 🙈
  • SWITCH-LAYER: The SWITCH-LAYER definition in Section 3.2 of [RFC8282] applies in stateful PCEP messages for GMPLS networks ⭐

6.2. New Extensions

6.2.1. GMPLS-CAPABILITY TLV in OPEN Object

In [RFC8779], IANA allocated value 45 (GMPLS-CAPABILITY) from the "PCEP TLV Type Indicators" subregistry. This specification adds three flags to the Flag field of this TLV for 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 ✨

Okay bestie, so [RFC5521] is the mechanism that lets a PCC request, or demand, that certain nodes, links, or other network resources get excluded from the paths a PCE computes 🙈 A PCC might totally want a path that dodges every link and node some other LSP is using. So this doc creates a brand new subobject for that route exclusion stuff from [RFC5521] 💅

The LSP Exclusion subobject looks like this:

 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 💖

Okay so, [RFC9357] asked IANA to set up a brand new subregistry called the "LSP-EXTENDED-FLAG TLV Flag Field" inside the "Path Computation Element Protocol (PCEP) Numbers" registry. Its whole job is managing the Flag field of the LSP-EXTENDED-FLAG TLV 🎀

IANA has already made the following assignments from it. Bits 2-3 are the Routing Granularity (RG) bits, so they cover two bits together ✨

+=====+=================================+===========+
| 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 6 is the "Mandatory Object missing" one, and Error-Type 19 is the "Invalid Operation" one, which has a whole bunch of new error-values under it 💀

+============+===========+===========================+===========+
| 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 🧚

Okay, the general PCE management stuff is covered in [RFC4655] and [RFC5440], and the GMPLS-specific PCEP management stuff is in [RFC8779]. This document is all about the management considerations for the stateful PCEP extension in GMPLS 💜

This section follows the guidance of [RFC6123] ✨

9.1. Control of Function through Configuration and Policy 🎛️

Besides the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD let you configure the following PCEP session parameters on a PCC. An implementation MAY choose to make these features available on all PCEP sessions though, so it's not a must-have for every setup 🌸

  • The ability to send stateful PCEP messages for GMPLS LSPs.
  • The ability to use path computation constraints (e.g., XRO).

Also, besides the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD let you configure 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 one specific session with a given PCEP peer, or a specific group of sessions with a specific group of PCEP peers. Options for days 🦋

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 it's actually useful for the extensions in this document, it would need to include advertised GMPLS stateful capabilities etc. A future version of [PCE-PCEP-YANG] will include this, so stay tuned 🫶

As described in [YANG-PATH-COMPUTATION], a YANG-based interface can be used in some cases to request GMPLS path computations, instead of PCEP. Go to [YANG-PATH-COMPUTATION] for the 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]. Nothing new to see here, bestie 🌈

9.4. Verifying Correct Operation 🔍

This document makes no change to the basic operations of PCEP, and the considerations in Section 8.4 of [RFC5440] still apply. 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), the ingress node of an LSP has to carry the Record Route Object (RRO) object. That's how the collection of this information gets enabled 🍓

9.6. Impact on Network Operation 🌐

The management considerations about the impact on network operations described in Section 4.6 of [RFC8779] apply here too 💜

10. Security Considerations 🔐

Okay, this part is serious, so read it carefully, bestie 😭

The security considerations elaborated in [RFC5440] apply to this document. The PCEP extensions to support GMPLS-controlled networks should be considered under the same security as for MPLS networks, as noted in [RFC7025]. So the PCEP extension to support GMPLS specified in [RFC8779] is used as the foundation of this document, and the security considerations in [RFC8779] should also be applicable to this document too. 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 extensions in [RFC8231] and [RFC8281] are not altered by the additions in this document. The security considerations in [RFC8231] and [RFC8281], including both the issues and the solutions, apply to this document as well 🛡️

11. References 📚

11.1. Normative References 🎀

11.2. Informative References 📚

Okay bestie, here's the background reading list 💖 These are informative, so they give you context rather than rules:

[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 show the PCEP messages, so you can see exactly how they're built 🧩 The RBNF here is copied over for informative purposes, and it's 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 so it can report the status of LSPs with GMPLS characteristics ✨

The format of the PCRpt message looks like this:

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

Here's the tea on each piece 🍓

  • 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. No skipping this one, bestie 💅
  • <intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5440] and augmented in [RFC8779] with ELC.
  • <actual-attribute-list> holds 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]. It's been extended by a whole bunch of 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 looks like this:

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

And the details 👑

  • The END-POINTS object MUST be carried in a PCUpd message for the GMPLS LSP. Non-negotiable 🫶
  • <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]. It's extended by many other documents that define PCEP extensions for specific scenarios, and it works the same way as shown for PCRpt above 🧚

A.3. The PCInitiate Message 🧚‍♀️

According to [RFC8281], the PCInitiate message is used to allow LSP Initiation. This document extends the message so it can initiate LSPs with GMPLS characteristics ⭐ Here's the format of a PCInitiate message:

<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]. Every field is similar to the PCRpt and PCUpd messages, so if you know one, you basically know all three 🙈✨

Acknowledgements ✨

Huge thanks to Adrian Farrel, Cyril Margaria, George Swallow, Jan Medved, Sue Hares, and John Scudder for the super useful comments and discussions 🫶

Thanks also to Dhruv Dhody for shepherding this document and dropping 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
📦 where this page comes from