Internet-Draft Stateful PCEP for GMPLS August 2023
Lee, et al. Expires 21 February 2024 [Page]
Workgroup:
PCE Working Group
Internet-Draft:
draft-ietf-pce-pcep-stateful-pce-gmpls-23
Published:
Intended Status:
Standards Track
Expires:
Authors:
Y. Lee
Samsung
H. Zheng
Huawei Technologies
O. Gonzalez de Dios
Telefonica
V. Lopez
Nokia
Z. Ali
Cisco

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

Abstract

The PCE 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, but 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 21 February 2024.

Table of Contents

1. Introduction

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

[RFC8051] describes how a stateful PCE can be applicable 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/TLVs, and 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), etc. technologies).

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 PCE 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, and a solution to address such requirements with PCEP object extensions 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 PCE specified in [RFC8231] and PCEP for GMPLS specified in [RFC8779].

The operation for Stateful PCE on LSPs can be divided into two types, active stateful PCE and passive stateful PCE as described in [RFC8051].

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

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

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

The requirements for GMPLS-specific stateful PCE 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 needs to be advertised as well.
  • All the PCEP messages need to be capable of indicating GMPLS-specific switching capabilities. GMPLS LSP creation/modification/deletion requires knowledge of LSP switching capability (e.g., Time-Division Multiplex Capable (TDM), Layer 2 Switch Capable (L2SC), OTN-TDM, Lambda Switch Capable (LSC), etc.) and the generalized payload (G-PID) to be used according to [RFC3471], [RFC3473]. It also requires the specification of data flow specific traffic parameters (also known as Traffic Specification (Tspec)), which are technology specific. 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 and hence a path computed by the PCE is associated with a specific lambda (label). Hence, 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 may be required.
  • Stateful PCEP messages also need to indicate the protection context information for the LSP specified by GMPLS, as defined in [RFC4872], [RFC4873].

5. Overview of Stateful PCEP Extensions for GMPLS Networks

5.1. Capability Advertisement for Stateful PCEP in GMPLS

Capability Advertisement has been specified in [RFC8231], and can be achieved by using the "STATEFUL-PCE-CAPABILITY TLV" in the Open message. Another GMPLS-CAPABILITY TLV has been defined in [RFC8779]. A subregistry to manage the Flag field of the GMPLS-CAPABILITY TLV is created by the 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(TBDa), LSP-UPDATE-CAPABILITY (TBD1), and LSP-INSTANTIATION-CAPABILITY (TBD2).

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

5.3. LSP Delegation and Cleanup

LSP delegation and cleanup procedure specified in [RFC8231] 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: Generalized END-POINTS was specified in [RFC8779] to include GMPLS capabilities. All Stateful PCEP messages MUST include the END-POINTS 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 MAY contain other TLVs defined in [RFC8779].
  • RP: RP object extension, together with the Routing Granularity (RG) flag defined in [RFC8779], are applicable in the Stateful PCEP for GMPLS networks.
  • BANDWIDTH: Generalized BANDWIDTH was specified in [RFC8779] to represent GMPLS features, including asymmetric bandwidth and G-PID information.
  • LSPA: LSPA Extensions in Section 2.8 of [RFC8779] is applicable in Stateful PCEP for GMPLS networks.
  • IRO: IRO Extensions in Section 2.6 of [RFC8779] is applicable in Stateful PCEP for GMPLS networks.
  • XRO: XRO Extensions in Section 2.7 of [RFC8779] is 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) was not extended in [RFC8779], nor is it in this document.
  • SWITCH-LAYER: SWITCHING-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 has allocated value 45 (GMPLS-CAPABILITY) from the "PCEP TLV Type Indicators" sub-registry. The specifcation add three flags to the flag field of this TLV to indicate the Report, Update, and Initiation capabilities.

R (LSP-REPORT-CAPABILITY(TBDa) -- 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(TBD1) -- 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(TBD2) -- 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 Sub-object in the XRO

[RFC5521] defines a mechanism for a PCC to request or demand that specific nodes, links, or other network resources are 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 sub-object for use with route exclusion defined in [RFC5521]. The LSP exclusion sub-object 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 (TBD3)  |     Length    |   Reserved    |    Flags      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  //                    Symbolic Path Name                       //
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: New LSP Exclusion Sub-object Format

X: Same as the X-bit defined in the XRO sub-objects 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: Sub-object Type for an LSP exclusion sub-object. Value of TBD3. To be assigned by IANA.

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

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 Sub-object 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/PCC could be excluded.

This sub-object MAY be present multiple times in the exclude route object (XRO) to exclude resources from multiple LSPs. When a stateful PCE receives a PCReq message carrying this sub-object, 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 Sub-object could also be used by non-GMPLS LSPs. The description by usage of 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(TBDb) -- 1 bit) : If set to 1, it indicates the LSP is a GMPLS LSP.
  • B (Bidirectional LSP(TBD4) -- 1 bit): If set to 0, it indicates a request to create a uni-directional LSP. If set to 1, it indicates a request to create a bidirectional co-routed LSP.
  • RG (Routing Granularity(TBDc) -- 2 bits) : RG flag for GMPLS is also defined in the LSP-EXTENDED-FLAG TLV. The value 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 capability 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 TBDx ("Attempted LSP Update Request for GMPLS if stateful PCE capability for GMPLS was 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 TBDy ("Attempted LSP Report Request for GMPLS if stateful PCE capability for GMPLS was 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 TBDz ("Attempted LSP Instantiation Request for GMPLS if stateful PCE instantiation capability for GMPLS was 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 Re-optimization

A stateful PCE is expected to perform an LSP re-optimization when receiving a message with the R bit set in the RP object. If no LSP state information is available to carry out re-optimization, the stateful PCE SHOULD report the error "LSP state information unavailable for the LSP re-optimization" (Error Type = 19, Error value= TBD6), although such a PCE MAY consider the re-optimization 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 sub-object in XRO is defined in Section 6.2.2 of this document MAY be present multiple times. When a stateful PCE receives a PCEP message carrying this sub-object, it searches for the identified LSP in its LSP-DB and 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 = TBD7 ("The LSP state information for route exclusion purpose cannot be found"). Optionally, it MAY also provide with the unrecognized symbolic path name 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 it that it has avoided using all resources associated with an LSP that doesn't exist.

7.4. Error Handling for generalized END-POINTS

Note that the END-POINTS object in the Stateful PCEP messages was introduced for 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 if the LSP-EXTENDED-FLAG TLV is missing in the LSP object or if 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 = TBD9 ("Use of Generalized Endpoint object type for non-GMPLS LSP").

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") and Error-value=TBD8 ("LABEL-REQUEST TLV missing").

8. Implementation

[NOTE TO RFC EDITOR : This whole section and the reference to RFC 7942 is to be removed before publication as an RFC]

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

8.1. Huawei Technologies

  • Organization: Huawei Technologies, Co. LTD
  • Implementation: Huawei NCE-T
  • Description: PCRpt, PCUpd and PCInitiate messages for GMPLS Network
  • Maturity Level: Production
  • Coverage: Full
  • Contact: zhenghaomian@huawei.com

9. IANA Considerations

9.1. title=New Flags in GMPLS-CAPABILITY TLV

[RFC8779] defines the GMPLS-CAPABILITY TLV; per that RFC, IANA created a registry to manage the value of the GMPLS-CAPABILITY TLV's Flag field. This document requests IANA to allocate new bits in the GMPLS-CAPABILITY TLV Flag Field registry, as follows. IANA is requested to make allocations starting from the least significant bit (31).


    Bit  | Description                      | Reference
    -----+----------------------------------+------------
    TBDa | LSP-REPORT-CAPABILITY (R)        | [This.I-D]
    TBD1 | LSP-UPDATE-CAPABILITY (U)        | [This.I-D]
    TBD2 | LSP-INSTANTIATION-CAPABILITY (I) | [This.I-D]

9.2. New Sub-object for the Exclude Route Object

IANA maintains the various XRO Subobjects types within the "XRO Subobjects" subregistry of the PCEP Numbers registry. IANA is requested to allocate a codepoint for another XRO subobject as follows:


   Value  | Description                  | Reference
  --------+------------------------------+-------------
   TBD3   | LSP                          | [This.I-D]

9.3. Flags Field for LSP exclusion Sub-object

IANA is requested to create a registry named "LSP Exclusion Sub-Object Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" group, to manage the Flag field of the LSP Exclusion sub-object in the XRO. No Flag is currently defined for this flag field in this document.

Codespace of the Flag field (LSP Exclusion sub-object)


     Bit  | Description       | Reference
    ------+-------------------+-------------
     0-7  | Unassigned        | [This.I-D]

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

  • Bit number (counting from bit 0 as the most significant bit)
  • Capability description
  • Defining RFC

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

[I-D.ietf-pce-lsp-extended-flags] 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 is requested to make assignments from this registry as follows:


    Bit   | Description                      | Reference
    ------+----------------------------------+------------
    TBDb  | GMPLS LSP (G)                    | [This.I-D]
    TBD4  | Bi-directional co-routed LSP (B) | [This.I-D]
    TBDc* | Routing Granularity Flag (RG)    | [This.I-D]

* - 2 bits need to be allocated

9.5. New PCEP Error Codes

IANA is requested to make the following allocation in the "PCEP-ERROR Object Error Types and Values" registry.


+===========+================+=========================+===========+
| Error-Type| Meaning        | Error-value             | Reference |
+===========+================+=========================+===========+
| 6         | Mandatory      |TBD8: LABEL-REQUEST TLV  | This I-D  |
|           | Object missing |missing                  |           |
|-----------|----------------+-------------------------+-----------+
|19         | Invalid        |TBD6: LSP state info     | This I-D  |
|           | Operation      |unavailable for the      |           |
|           |                |Re-optimization          |           |
|           |                +-------------------------+-----------+
|           |                |TBD7: LSP state info for | This I-D  |
|           |                |route exclusion not found|           |
|           |                +-------------------------+-----------+
|           |                |TBDx: Attempted LSP      | This I-D  |
|           |                |Update Request for GMPLS |           |
|           |                |if stateful PCE          |           |
|           |                |capability not advertised|           |
|           |                +-------------------------+-----------+
|           |                |TBDy: Attempted LSP State| This I-D  |
|           |                |Report for GMPLS if      |           |
|           |                |stateful PCE capability  |           |
|           |                |not advertised           |           |
|           |                +-------------------------+-----------+
|           |                |TBDz: Attempted LSP      | This I-D  |
|           |                |Instantiation Request for|           |
|           |                |GMPLS if stateful PCE    |           |
|           |                |instantiation capability |           |
|           |                |not advertised           |           |
|           |                +-------------------------+-----------+
|           |                |TBD9: use of Generalized | This I-D  |
|           |                |Endpoint object type for |           |
|           |                |non-GMPLS LSP            |           |
+-----------+----------------+-------------------------+-----------+

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

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

10.2. Information and Data Models

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

As described in [I-D.ietf-teas-yang-path-computation], a YANG-based interface can be used in some cases to request GMPLS path computations, instead of PCEP. Refer [I-D.ietf-teas-yang-path-computation] for details.

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

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

10.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 LSP state report process), this requires the ingress node of an LSP to carry the RRO object in order to enable the collection of such information.

10.6. Impact on Network Operation

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

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

12. Acknowledgement

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.

13. Nomative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/info/rfc5440>.
[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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc9357>.

14. Informative References

[I-D.ietf-pce-lsp-extended-flags]
Xiong, Q., "Label Switched Path (LSP) Object Flag Extension for Stateful PCE", Work in Progress, Internet-Draft, draft-ietf-pce-lsp-extended-flags-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-extended-flags-09>.
[I-D.ietf-pce-pcep-yang]
Dhody, D., 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-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-yang-21>.
[I-D.ietf-teas-yang-path-computation]
Busi, I., Belotti, S., 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, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-path-computation-21>.
[RFC3471]
Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc4873>.
[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, , <https://www.rfc-editor.org/info/rfc5511>.
[RFC6123]
Farrel, A., "Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts", RFC 6123, DOI 10.17487/RFC6123, , <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, , <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, , <https://www.rfc-editor.org/info/rfc7399>.
[RFC7942]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, , <https://www.rfc-editor.org/info/rfc7942>.
[RFC8051]
Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8745>.

Appendix A. Contributors' Address


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

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

B.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], augmented in [RFC8779] with explicit label control (ELC) and Path Keys.
  • <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>]

B.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 explicit label control (ELC) and Path Keys.
  • <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.

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

Authors' Addresses

Young Lee
Samsung
Haomian Zheng
Huawei Technologies
Oscar Gonzalez de Dios
Telefonica
Victor Lopez
Nokia
Zafar Ali
Cisco