Internet-Draft PCEP Ext for Flexi-grid July 2026
Zheng, et al. Expires 6 January 2027 [Page]
Workgroup:
PCE Working Group
Internet-Draft:
draft-ietf-pce-flexible-grid-15
Published:
Intended Status:
Standards Track
Expires:
Authors:
H. Zheng, Ed.
Huawei Technologies Co., Ltd.
Y. Lee
CRU
R. Casellas
CTTC
D. Ceccarelli
Cisco

PCEP Extension for Flexible Grid Networks

Abstract

This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid 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 2 January 2027.

▲

Table of Contents

1. Introduction

[RFC4655] defines a Path Computation Element (PCE)-based path computation architecture and explains how a Path Computation Element (PCE) can compute Label Switched Paths (LSP) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks at the request of Path Computation Clients (PCCs). A PCC is said to be any network component that makes such a request and can be, for instance, an Optical Switching Element within a Wavelength Division Multiplexing (WDM) network. The PCE, itself, can be located anywhere within the network, and can be within an optical switching element, a Network Management System (NMS) or Operational Support System (OSS), or can be an independent network server.

The PCE communications Protocol (PCEP) is the communication protocol used between a PCC and a PCE, and can also be used between cooperating PCEs. [RFC4657] sets out the common protocol requirements for PCEP. Additional application-specific requirements for PCEP are deferred to separate documents.

[RFC8780] provides the PCEP extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON) based on the requirements specified in [RFC6163] and [RFC7449].

To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations [ITU-T_G.694.1] to include an enhanced Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". In such an environment, a data-plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid (flexi-grid). [RFC7698] provides Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks.

The term "Routing and Spectrum Assignment" (RSA) is introduced in [RFC7698] to refer to the process that determines a route and frequency slot for an LSP. Hence, when a path is computed, the spectrum assignment process determines the central frequency and slot width. The term "Spectrum Switched Optical Networks" is also introduced in [RFC7698] to refer to a flexi-grid enabled DWDM network, which can be controlled by a GMPLS or PCE control plane.

This document provides PCEP extensions to support RSA in Flexi-grid networks. The extensions in this document apply to point-to-point LSPs; support for point-to-multipoint (P2MP) LSPs is out of scope for this document and is left for future work.

Figure 1 shows one typical PCE-based implementation, which is referred to as the Combined Routing and Spectrum Assignment (RSA) [RFC7698]. With this architecture, the two processes of routing and spectrum assignment are accessed via a single PCE. This architecture is the base architecture from which the PCEP extensions are specified in this document.


                       +----------------------------+
         +-----+       |     +-------+     +--+     |
         |     |       |     |Routing|     |SA|     |
         | PCC |<----->|     +-------+     +--+     |
         |     |       |                            |
         +-----+       |             PCE            |
                       +----------------------------+
Figure 1: Combined Routing and Spectrum Assignment Architecture

2. Terminology

This document uses the terminology defined in [RFC4655], [RFC5440], and [RFC7698].

3. Requirements Language

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.

4. Spectrum Assignment (SA) Object

This document aligns with GMPLS extensions for PCEP [RFC8779] for generic properties such as label, label-set and label assignment, noting that frequency is a type of label. Frequency restrictions and constraints are also formulated in terms of labels per [RFC7579].

The SA Object enables a PCC to request spectrum assignment from the PCE and to express preferences such as assignment mode and frequency-slot restrictions. It thus allows the PCE to perform the combined Routing and Spectrum Assignment (RSA) according to the PCC's policies.

Spectrum allocation can be performed by the PCE by different means:

  1. By means of Explicit Label Control (ELC) where the PCE allocates which label to use for each interface/node along the path.
  2. By means of a Label Set where the PCE provides a range of potential frequency slots to allocate by each node along the path.

Option b. allows distributed spectrum allocation (performed during signaling) to complete spectrum assignment. When a range of potential frequency slots is given for allocation, a PC Request SHOULD convey the heuristic or mechanism to be used for the allocation.

The format Routing Backus-Naur Form (RBNF) [RFC5511] of a PCReq message per [RFC5440] after incorporating the Spectrum Assignment (SA) Object is as follows:


            <PCReq Message> ::= <Common Header>
                                   [<svec-list>]
                                   <request-list>
               Where:
            <request-list>::=<request>[<request-list>]
            <request>::= <RP>
                         <GENERALIZED ENDPOINTS>
                            [<SA>]
                            [other optional objects...]

If the SA Object is present in the PCReq message, it MUST be encoded after the GENERALIZED ENDPOINTS Object.

This document specifies the use of the SA Object in the PCReq message. The use of the SA Object in other PCEP messages, such as the LSP Initiate Request (PCInitiate) message defined in [RFC8281], is out of scope for this document and is left for future work.

The SA Object-Class is TBD1 (to be assigned by IANA). The SA Object-Type is 1.

This document does not define a new PCEP capability advertisement for the SA Object. If a PCE receives an RSA request and the PCE is not capable of RSA computation, it reports the condition using the error procedure defined in Section 5.1. This error-based approach avoids adding a new OPEN Object capability for this extension; operators can use the PCE Discovery mechanisms described in Section 6.4 to advertise Flexi-Grid RSA path computation capabilities to PCCs.

The format of the Spectrum Assignment (SA) Object body is as shown in Figure 2.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |            Flags            |M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                      Optional TLVs                          //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SA Object

Reserved (16 bits): the Reserved field MUST be set to zero by the sender and ignored by the receiver.

Flags (16 bits): bits 0-14 are unassigned. They MUST be set to zero by the sender and ignored by the receiver.

One flag bit is allocated as follows:

M (Mode - bit 15): M bit is used to indicate the mode of spectrum assignment. When the M bit is set to 1, this indicates that the spectrum assigned by the PCE MUST be explicit. That is, the selected way to convey the allocated spectrum is by means of Explicit Label Control (ELC) [RFC3472] for each hop of a computed LSP. Otherwise, when the M bit is set to 0, the spectrum assigned by the PCE does not need to be explicit (i.e., it can be suggested in the form of Label Set Objects in the corresponding response, to allow distributed SA). In such case, the PCE MUST return a Label Set Field as described in Section 2.6 of [RFC7579] in the response. See Section 5 of this document for the encoding discussion of a Label Set Field in a PCRep message.

IANA maintains the "SA Object Flag Field" registry requested in Section 9.2.

4.1. Frequency Slot Selection TLV

The Frequency Slot Selection TLV is used to indicate the frequency slot selection constraint in regard to the order of frequency slot assignment to be returned by the PCE. This TLV is only applied when the M bit is set in the SA Object specified in Section 4. This TLV SHOULD NOT be present and MUST be ignored when the M bit is set to 0.

The Frequency Slot Selection TLV format is defined as:


      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Type                 |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|        FSA Method           |           Reserved            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

S (Symmetry - 1 bit): This flag is only meaningful when the request is for a bidirectional LSP, i.e., when the B (Bi-directional) flag is set in the RP Object (see Section 7.4.1 of [RFC5440]). 0 denotes requiring the same frequency slot in both directions; 1 denotes that different spectrum in the two directions is allowed.

Frequency Slot Assignment (FSA) Method (15 bits):

  • 0: unspecified (any); This does not constrain the SA method used by a PCC. This value is implied when the Frequency Slot Selection TLV is absent.
  • 1: First-Fit. All the feasible frequency slots are numbered (based on 'n' parameter), and this SA method chooses the available frequency slot with the lowest index, where 'n' is the parameter in f = 193.1 THz + n x 0.00625 THz where 193.1THz is the ITU-T 'anchor frequency' and 'n' is a positive integer including 0 [RFC7698].
  • 2: Random. This SA method chooses a feasible frequency slot value of 'n' randomly.
  • 3-32767: Unassigned.

IANA maintains the "Frequency Slot Assignment Method Values" registry requested in Section 9.4.

Reserved (16 bits): the Reserved field MUST be set to zero by the sender and ignored by the receiver.

The Frequency Slot Selection TLV type is TBD2 (to be assigned by IANA).

If a PCE does not support the attribute(s), its behavior is specified below:

  • S bit clear not supported: a PathErr MUST be generated with the Error Code "Routing Problem" (24) with error sub-code "Unsupported Frequency Slot Selection Symmetry value" (TBD3).
  • FSA method not supported: a PathErr MUST be generated with the Error Code "Routing Problem" (24) with error sub-code "Unsupported Frequency Slot Assignment value" (TBD4).

4.2. Frequency Slot Restriction TLV

For any request that contains a frequency slot assignment, the requester (PCC) MUST be able to specify a restriction on the frequency slots to be used. This restriction is to be interpreted by the PCE as a constraint on the tuning ability of the origination laser transmitter or on any other maintenance related constraints.

The Frequency Slot Restriction TLV type is TBD5 (to be assigned by IANA). This TLV MAY appear more than once to be able to specify multiple restrictions. The TLV data is defined as shown in Figure 3.


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Action        |    Count      |            Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Identifiers                          |
    |                          . . .                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                Frequency Slot Restriction Field               |
    //                        . . . .                              //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Frequency Slot Restriction TLV Encoding

The fields in the TLV are as follows:

  • Action: 8 bits.

    • 0 - Inclusive List indicates that one or more link identifiers are included in the Link Set. Each identifies a separate link that is part of the set.
    • 1 - Inclusive Range indicates that the Link Set defines a range of links. It contains two link identifiers. The first identifier indicates the start of the range (inclusive). The second identifier indicates the end of the range (inclusive). All links with numeric values between the bounds are considered to be part of the set. A value of zero in either position indicates that there is no bound on the corresponding portion of the range. Note that the Action field can be set to 0 when unnumbered link identifier is used.
  • Count: The number of the link identifiers (8 bits).
  • Reserved: Reserved for future use (16 bits). It MUST be set to zero by the sender and ignored by the receiver.
  • Link Identifiers: Identifies each link ID for which restriction is applied. The length is dependent on the link format and the Count field. See Section 4.3.1 in [RFC8780] for Link Identifier encoding.

IANA maintains the "Frequency Slot Restriction TLV Action Values" registry requested in Section 9.6.

A PCC MAY add a frequency slot restriction that applies to all links by setting the Count field to zero and specifying just a set of frequency slots.

All link identifiers in the same list MUST be of the same type.

The Frequency Slot Restriction Field of the Frequency Slot Restriction TLV is encoded as defined in Section 4.2 of [RFC8363].

5. Encoding of an RSA Path Reply

This section provides the encoding of an RSA Path Reply, in the PCRep/PCUpd message, for frequency slot allocation as discussed in Section 4. The Spectrum Allocation TLV type is TBD6 (to be assigned by IANA). The Spectrum Allocation TLV uses the standard PCEP TLV format defined in Section 7.1 of [RFC5440]. The TLV is defined as shown in Figure 4.

[RFC7570] describes how an attribute TLV ([RFC5420]) can be carried in an ERO as a TLV within an LSP Attribute Subobject to provide a per-hop description of an LSP attribute. The Spectrum Assignment TLV can be carried in the LSP Attribute Subobject to indicate the spectrum to be assigned on the identified link.


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              Type             |             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Reserved             |            Flags            |M|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Link Identifier                           |
    |                          . . .                                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Allocated Spectrum                         |
    //                        . . . .                              //
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Spectrum Allocation TLV Encoding

IANA maintains the "Spectrum Allocation TLV Flag Field" registry requested in Section 9.8.

5.1. Error Indicator

To indicate errors associated with the RSA request, a new Error-Type (TBD7, Flexi-Grid RSA Error) and subsequent error-value are defined for inclusion in the PCEP-ERROR Object:

  • Error-Type=TBD7 (Flexi-Grid RSA Error); Error-value=1: if a PCE receives an RSA request and the PCE is not capable of RSA computation, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=TBD7) and an Error-value (Error-value=1). The PCE stops processing the request. The corresponding RSA computation MUST be cancelled at the PCC.

Note that generic resource exhaustion at the PCE (e.g., insufficient memory) is not signaled via this Error-Type; the PCEP overload mechanism (see Section 7.15 of [RFC5440]) applies.

5.2. NO-PATH Indicator

To communicate the reasons for not being able to find RSA for the path request, the NO-PATH Object can be used in the corresponding response. The format of the NO-PATH Object body is defined in [RFC5440]. The object MAY contain a NO-PATH-VECTOR TLV to provide additional information about why a path computation has failed.

One new bit flag is defined to be carried in the Flags field in the NO-PATH-VECTOR TLV carried in the NO-PATH Object.

  • Bit TBD8: When set, the PCE indicates no feasible path was found that meets all the optical spectrum constraints associated with the path computation request.

This flag is specific to spectrum-related path computation failures; other path-computation failure reasons continue to use the existing PCEP NO-PATH mechanisms.

6. Manageability Considerations

Manageability of flexi-grid Routing and Spectrum Assignment (RSA) with PCE includes the following considerations:

6.1. Control of Function and Policy

In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring the following PCEP session parameters on a PCC:

  • The ability to send a Flexi-Grid RSA request.

In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring the following PCEP session parameters on a PCE:

  • The support for Flexi-Grid RSA.
  • A set of Flexi-Grid RSA specific policies (authorized sender, request rate limiter, etc).

These parameters can be configured as default parameters for any PCEP session the PCEP speaker participates in, or can apply to a specific session with a given PCEP peer or a specific group of sessions with a specific group of PCEP peers.

6.2. Information and Data Models

Extensions to the PCEP YANG module can be defined to cover the Flexi-Grid RSA information introduced in this document. Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in Section 8.3 of [RFC5440].

6.3. Verifying Correct Operation

Mechanisms defined in this document do not imply any new verification requirements in addition to those already listed in section 8.4 of [RFC5440].

6.4. Requirements on Other Protocols and Functional Components

The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) can be used to advertise Flexi-Grid RSA path computation capabilities to PCCs.

6.5. Impact on Network Operation

Mechanisms defined in this document do not imply any new network operation requirements in addition to those already listed in Section 8.6 of [RFC5440].

7. Implementation Status

[NOTE TO RFC EDITOR: This whole section and the reference to [RFC7942] are 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".

7.1. CTTC

CTTC has implemented several aspects of the extensions defined by earlier revisions of this document in a research Path Computation Element and SDN controller. The PCC and PCE are built from the same codebase, and the implementation uses private codepoints for the new object and TLVs pending IANA allocation. Details are as follows:


Organization: Centre Tecnologic de Telecomunicacions de
   Catalunya (CTTC)

Implementation: Research PCE and SDN controller.

Description: The Spectrum Assignment (SA) Object is
   implemented using a private Object-Class codepoint and is
   encoded after the ENDPOINTS Object.  The M (Mode) flag is
   supported for spectrum assignment by means of Explicit
   Label Control (ELC), which is also the default behavior
   when the SA Object is absent; the spectrum assignment
   algorithms in use allocate ELC, and requests for
   non-explicit assignment raise an error.  The Frequency
   Slot Selection TLV is implemented, including the S
   (Symmetry) bit (the default for bidirectional LSPs) and
   the First-Fit (default) and Random assignment methods.
   The Frequency Slot Restriction TLV is partially
   implemented: the TLV is parsed in full, and restrictions
   that apply to all links (Count field set to zero) are
   supported, in practice as a single frequency slot that
   applies end to end for fixed transceivers.  The new error
   codes are not implemented; generic PCEP errors (e.g.,
   NO-PATH) are used instead.

Maturity Level: Research prototype used in research
   projects; not aimed at interoperability or product
   release.  Interoperability has been tested only between
   the PCC and PCE built from the same codebase.

Coverage: Partial.

Contact: ramon.casellas@cttc.es

8. Security Considerations

This document has no requirement for a change to the security models within PCEP. The security considerations described in [RFC5440] and the use of TLS to provide a secure transport for PCEP as described in [RFC8253] apply to the extensions defined in this document. The additional information distributed in order to address the RSA problem represents a disclosure of network capabilities that an operator might wish to keep private. Operators are encouraged to secure this information.

9. IANA Considerations

This document requests the following IANA actions.

9.1. New PCEP Object

IANA is requested to allocate a new object class from the "PCEP Objects" registry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects):


+====================+======+========================+===========+
| Object-Class Value | Name | Object-Type            | Reference |
+====================+======+========================+===========+
| TBD1               | SA   | 0: Reserved            |           |
|                    |      +------------------------+-----------+
|                    |      | 1: Spectrum Assignment | [This.I-D]|
|                    |      +------------------------+-----------+
|                    |      | 2-15: Unassigned       |           |
+--------------------+------+------------------------+-----------+

9.2. SA Object Flag Field

IANA is requested to create the "SA Object Flag Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry. New values are to be assigned by IETF Review [RFC8126]. Bits are numbered from bit 0 as the most significant bit.


        +=======+==========================+===========+
        | Bit   | Description              | Reference |
        +=======+==========================+===========+
        | 0-14  | Unassigned               |           |
        +-------+--------------------------+-----------+
        | 15    | Spectrum Assignment Mode | [This.I-D]|
        +-------+--------------------------+-----------+

9.3. New PCEP TLV: Frequency Slot Selection TLV

IANA is requested to allocate a new TLV type for the Frequency Slot Selection TLV from the "PCEP TLV Type Indicators" registry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators).


            +=======+==========================+===========+
            | Value | Description              | Reference |
            +=======+==========================+===========+
            | TBD2  | Frequency Slot Selection | [This.I-D]|
            +-------+--------------------------+-----------+

9.4. Frequency Slot Assignment Method Values

IANA is requested to create the "Frequency Slot Assignment Method Values" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry. New values are to be assigned by IETF Review [RFC8126].


            +=========+=============+===========+
            | Value   | Description | Reference |
            +=========+=============+===========+
            | 0       | Unspecified | [This.I-D]|
            +---------+-------------+-----------+
            | 1       | First-Fit   | [This.I-D]|
            +---------+-------------+-----------+
            | 2       | Random      | [This.I-D]|
            +---------+-------------+-----------+
            | 3-32767 | Unassigned  |           |
            +---------+-------------+-----------+

9.5. New PCEP TLV: Frequency Slot Restriction TLV

IANA is requested to allocate a new TLV type for the Frequency Slot Restriction TLV from the "PCEP TLV Type Indicators" registry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators).


            +=======+============================+===========+
            | Value | Description                | Reference |
            +=======+============================+===========+
            | TBD5  | Frequency Slot Restriction | [This.I-D]|
            +-------+----------------------------+-----------+

9.6. Frequency Slot Restriction TLV Action Values

IANA is requested to create the "Frequency Slot Restriction TLV Action Values" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry. New values are to be assigned by IETF Review [RFC8126].


            +=======+=================+===========+
            | Value | Description     | Reference |
            +=======+=================+===========+
            | 0     | Inclusive List  | [This.I-D]|
            +-------+-----------------+-----------+
            | 1     | Inclusive Range | [This.I-D]|
            +-------+-----------------+-----------+
            | 2-255 | Unassigned      |           |
            +-------+-----------------+-----------+

9.7. New PCEP TLV: Spectrum Allocation TLV

IANA is requested to allocate a new TLV type for the Spectrum Allocation TLV from the "PCEP TLV Type Indicators" registry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type-indicators).


            +=======+=====================+===========+
            | Value | Description         | Reference |
            +=======+=====================+===========+
            | TBD6  | Spectrum Allocation | [This.I-D]|
            +-------+---------------------+-----------+

9.8. Spectrum Allocation TLV Flag Field

IANA is requested to create the "Spectrum Allocation TLV Flag Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry. New values are to be assigned by IETF Review [RFC8126]. Bits are numbered from bit 0 as the most significant bit.


            +=======+==========================+===========+
            | Bit   | Description              | Reference |
            +=======+==========================+===========+
            | 0-14  | Unassigned               |           |
            +-------+--------------------------+-----------+
            | 15    | Spectrum Allocation Mode | [This.I-D]|
            +-------+--------------------------+-----------+

9.9. New No-Path Reasons

IANA is requested to allocate a new bit flag from the "PCEP NO-PATH-VECTOR TLV Flag Field" registry (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector-tlv).


            +=======+=============================+===========+
            | Bit   | Description                 | Reference |
            +=======+=============================+===========+
            | TBD8  | No spectrum constraints met | [This.I-D]|
            +-------+-----------------------------+-----------+

9.10. New Error-Types and Error-Values

IANA is requested to allocate a new Error-Type and Error-value from the "PCEP-ERROR Object Error Types and Values" registry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object).


+============+================+====================+===========+
| Error-Type | Meaning        | Error-value        | Reference |
+============+================+====================+===========+
| TBD7       | Flexi-Grid RSA | 1: RSA computation | [This.I-D]|
|            | Error          | not supported      |           |
+------------+----------------+--------------------+-----------+

9.11. New Error-Values for Existing Error Type (24)

IANA is requested to allocate two new PathErr values for the Existing Error Type (24):


+============+=================+====================+===========+
| Error-Type | Meaning         | Error-value        | Reference |
+============+=================+====================+===========+
| 24         | Routing Problem | TBD3: Unsupported  | [This.I-D]|
|            |                 | Frequency Slot     |           |
|            |                 | Selection Symmetry |           |
|            |                 | value              |           |
|            |                 +--------------------+-----------+
|            |                 | TBD4: Unsupported  | [This.I-D]|
|            |                 | Frequency Slot     |           |
|            |                 | Assignment value   |           |
+------------+-----------------+--------------------+-----------+

10. Acknowledgements

Thanks to Francesco Lazzeri for the technical contribution, and Quan Xiong, Dhruv Dhody and Adrian Farrel for useful comments. Thanks to Ketan Talaulikar for his detailed AD review and helpful suggestions.

11. Contributors' Address 

Ricard Vilalta
CTTC
Spain

Email: ricard.vilalta@cttc.es

12. References

12.1. Normative 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>.
[RFC3472]
Ashwood-Smith, P., Ed. and L. Berger, Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, DOI 10.17487/RFC3472, , <https://www.rfc-editor.org/info/rfc3472>.
[RFC5088]
Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, , <https://www.rfc-editor.org/info/rfc5088>.
[RFC5089]
Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, , <https://www.rfc-editor.org/info/rfc5089>.
[RFC5420]
Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangar, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, , <https://www.rfc-editor.org/info/rfc5420>.
[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>.
[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>.
[RFC7570]
Margaria, C., Ed., Martinelli, G., Balls, S., and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, , <https://www.rfc-editor.org/info/rfc7570>.
[RFC7579]
Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and J. Han, "General Network Element Constraint Encoding for GMPLS-Controlled Networks", RFC 7579, DOI 10.17487/RFC7579, , <https://www.rfc-editor.org/info/rfc7579>.
[RFC7699]
Farrel, A., King, D., Li, Y., and F. Zhang, "Generalized Labels for the Flexi-Grid in Lambda Switch Capable (LSC) Label Switching Routers", RFC 7699, DOI 10.17487/RFC7699, , <https://www.rfc-editor.org/info/rfc7699>.
[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>.
[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>.
[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>.
[RFC8363]
Zhang, X., Zheng, H., Casellas, R., Gonzalez de Dios, O., and D. Ceccarelli, "GMPLS OSPF-TE Extensions in Support of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 8363, DOI 10.17487/RFC8363, , <https://www.rfc-editor.org/info/rfc8363>.
[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>.
[RFC8780]
Lee, Y., Ed. and R. Casellas, Ed., "The Path Computation Element Communication Protocol (PCEP) Extension for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment (RWA)", RFC 8780, DOI 10.17487/RFC8780, , <https://www.rfc-editor.org/info/rfc8780>.

12.2. Informative References

[ITU-T_G.694.1]
ITU-, T., "SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS; Digital networks; Spectral grids for WDM applications: DWDM frequency grid", ITU-T Rec. G.694.1 , , <https://www.itu.int/rec/T-REC-G.694.1>.
[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>.
[RFC6163]
Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, "Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, DOI 10.17487/RFC6163, , <https://www.rfc-editor.org/info/rfc6163>.
[RFC7449]
Lee, Y., Ed., Bernstein, G., Ed., Martensson, J., Takeda, T., Tsuritani, T., and O. Gonzalez de Dios, "Path Computation Element Communication Protocol (PCEP) Requirements for Wavelength Switched Optical Network (WSON) Routing and Wavelength Assignment", RFC 7449, DOI 10.17487/RFC7449, , <https://www.rfc-editor.org/info/rfc7449>.
[RFC7698]
Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F., Fu, X., Ceccarelli, D., and I. Hussain, "Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 7698, DOI 10.17487/RFC7698, , <https://www.rfc-editor.org/info/rfc7698>.
[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>.
[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>.

Authors' Addresses

Haomian Zheng (editor)
Huawei Technologies Co., Ltd.
Young Lee
CRU
Ramon Casellas
CTTC
Daniele Ceccarelli
Cisco