RFC 8282

Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering

📅 published December 2017, from ietf

RFC 8282 🦋 Extensions to the Path Computation Element Communication Protocol (PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering ✨

Bestie, this is RFC 8282, published in December 2017 🎀. It's a Standards Track document, so it's an actual Internet standard and not just a suggestion 💅. The ISSN is 2070-1721. Four authors wrote it: E. Oki (Kyoto University), T. Takeda (NTT), A. Farrel (Juniper Networks), and F. Zhang (Huawei Technologies Co., Ltd.) 👑. It doesn't list anything it obsoletes or updates, so it stands on its own 🫶.

Abstract 💜

Okay so the Path Computation Element (PCE) is the thing that does path computation for traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks 🧚.

MPLS and GMPLS networks can be built out of layered service networks 🌈. It's way more efficient for the whole network to do end-to-end traffic engineering across several layers at once, and that's called inter-layer traffic engineering 🔥. PCE is a strong candidate for handling that kind of job 💖.

The PCE Communication Protocol (PCEP) is the protocol that lets Path Computation Clients (PCCs) and PCEs talk to each other 💬. This document adds PCEP extensions for inter-layer traffic engineering ✨.

Status of This Memo 🌸

This is an Internet Standards Track document 🎀.

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

For the current status, any errata, and how to give feedback, head to https://www.rfc-editor.org/info/rfc8282 🦋.

Copyright (c) 2017 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 stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes ⭐.

Table of Contents 🎀

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
2.  Overview of PCE-Based Inter-Layer Path Computation  . . . . .   4
3.  Protocol Extensions . . . . . . . . . . . . . . . . . . . . .   4
  3.1.  INTER-LAYER Object  . . . . . . . . . . . . . . . . . . .   5
  3.2.  SWITCH-LAYER Object . . . . . . . . . . . . . . . . . . .   8
  3.3.  REQ-ADAP-CAP Object . . . . . . . . . . . . . . . . . . .   9
  3.4.  New Metric Types  . . . . . . . . . . . . . . . . . . . .  10
  3.5.  SERVER-INDICATION Object  . . . . . . . . . . . . . . . .  11
4.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .  11
  4.1.  Path Computation Request  . . . . . . . . . . . . . . . .  11
  4.2.  Path Computation Reply  . . . . . . . . . . . . . . . . .  12
  4.3.  Stateful PCE and PCE Initiated LSPs . . . . . . . . . . .  13
5.  Updated Format of PCEP Messages . . . . . . . . . . . . . . .  14
6.  Manageability Considerations  . . . . . . . . . . . . . . . .  15
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
  7.1.  New PCEP Objects  . . . . . . . . . . . . . . . . . . . .  16
  7.2.  New Registry for INTER-LAYER Object Flags . . . . . . . .  17
  7.3.  New Metric Types  . . . . . . . . . . . . . . . . . . . .  17
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
  9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  21
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1. Introduction 🦋

Okay, the Path Computation Element (PCE) defined in [RFC4655] is an entity that can work out a network path or route from a network graph while applying computational constraints 🧠. A Path Computation Client (PCC) can ask a PCE to compute paths, and a PCE can start or change services in a network by handing over new paths [RFC8231] [RFC8281] ✨.

A network can have multiple layers 🌈. Those layers might represent separate technologies, like packet switch capable (PSC), time division multiplex (TDM), and lambda switch capable (LSC) [RFC3945] 💅. They might also represent different data-plane switching granularity levels, like Virtual Circuit 4 (VC4) and VC12 [RFC5212] 🎀. Or they might show a client and server networking role split, like commercial or administrative separation between client and server networks 🫶. In this multi-layer setup, Label Switched Paths (LSPs) in lower layers carry higher-layer LSPs 🔥. The topology made by lower-layer LSPs, advertised as traffic engineering links (TE links) in the higher layer, is called a Virtual Network Topology (VNT) [RFC5212] 💖. Other ways to support network layering, where a higher-layer network gets connectivity from LSPs in a lower-layer network, are covered in [RFC7926] 🌸.

It's important to optimize network resources globally, meaning across all layers, instead of optimizing each layer on its own 👑. That gets you better network efficiency, and it's what we call inter-layer traffic engineering ⭐. It includes ways to compute end-to-end paths across layers (inter-layer path computation) and ways to control and manage the VNT by setting up and releasing LSPs in the lower layers [RFC5212] 🧚.

PCE can be a great fit for solving inter-layer path computation problems 💜. The framework for applying the PCE-based path computation architecture to inter-layer traffic engineering is in [RFC5623] 🦋.

PCEP is the communication protocol between PCCs and PCEs, and it's defined in [RFC5440] 💬. The requirements for PCEP extensions that support inter-layer traffic engineering are described in [RFC6457] 🎀.

This document presents PCEP extensions for inter-layer traffic engineering that meet the requirements in [RFC6457] 💅✨.

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

2. Overview of PCE-Based Inter-Layer Path Computation 🌸

[RFC4206] defines a way to signal a higher-layer LSP that has an explicit route, and that route includes hops traversed by LSPs in lower layers 🔥. Computing end-to-end paths across layers is called inter-layer path computation 💖.

A Label Switching Router (LSR) in the higher layer might not know about the lower-layer topology, especially in an overlay or augmented model [RFC3945] 🙈. Because of that, it may not be able to compute an end-to-end path across layers 💀.

PCE-based inter-layer path computation means using one or more PCEs to compute an end-to-end path across layers 🧚. One way to do this is a single PCE that knows the topology of multiple layers and can compute an end-to-end path across layers directly, looking at the topology of all the layers 👑. Another way is multiple cooperating PCEs, where each PCE knows the topology of one or more layers (but not all of them) and the PCEs work together to compute an end-to-end path 💜.

As [RFC5339] describes, a hybrid node can advertise a single TE link with multiple switching capabilities 🦋. Those TE links normally sit at the layer/region border 🎀. In that case, a PCE needs to be able to specify the server-layer path information whenever that information has to be returned to the PCC 💅.

[RFC5623] goes deeper into models for inter-layer path computation 🌈. It introduces the Virtual Network Topology Manager (VNTM), a functional element that controls the VNT, and it sets out three distinct models (plus a fourth hybrid model) for inter-layer control. Those models involve a PCE, triggered signaling, and a Network Management System (NMS) 🫶.

3. Protocol Extensions ✨

This section describes PCEP extensions for inter-layer path computation 🔥. Four new objects are defined: the INTER-LAYER object, the SWITCH-LAYER object, the REQ-ADAP-CAP object, and the SERVER-INDICATION object 💖. Two new metric types are also defined 👑.

3.1. INTER-LAYER Object 💖

Okay so bestie, the INTER-LAYER object is totally optional 🎀 but it's giving main character energy in PCReq and PCRep messages 💅 It also shows up in PCRpt, PCUpd, and PCInitiate messages, since those carry the <attribute-list> stuff from [RFC5440] plus the later extensions 🦋

In a PCReq, this object is where the PCC tells the PCE whether inter-layer path computation is allowed 🌈 It also says what kind of path it wants, and whether triggered signaling (hierarchical LSPs per [RFC4206] or stitched LSPs per [RFC5150], depending on the physical network tech) is allowed ✨ If the INTER-LAYER object is missing from a PCReq, the receiving PCE MUST process the request as though inter-layer path computation had been explicitly disallowed (I-bit set to zero, more on that below) 🙈 Not me being dramatic, but that default is so important!

In a PCRep, the object tells the PCC whether inter-layer path computation actually happened, what type of path got computed, and whether triggered signaling is used 🍓

If a PCReq has more than one request, you use one INTER-LAYER object per request 🧚 And if a PCRep answers with more than one path per request, you use one INTER-LAYER object per path 💜

For PCRpt and PCUpd, the object works the same way as the other objects on those messages, as described in [RFC8231] 🫶 For PCInitiate, it works the same as the other objects there, as described in [RFC8281] 🌸 All of these messages use the <attribute-list> from [RFC5440] (extended by other PCEP extensions too), so the <attribute-list> as extended in Section 5 can carry the INTER-LAYER object on them 💖

INTER-LAYER Object-Class is 36. 🔥

Inter-layer Object-Type is 1. ✨

Here's what the object body looks like, Figure 1 👑

    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                                             |T|M|I|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: The INTER-LAYER Object

I flag (1 bit): the PCC uses this in a PCReq to tell the PCE whether an inter-layer path is allowed. When I is set (one), the PCE MAY do inter-layer path computation and return an inter-layer path 🦋 When it's clear (zero), the returned path MUST NOT be an inter-layer path 🙅‍♀️

The PCE uses the I flag in a PCRep to tell the PCC whether the returned path is an inter-layer path. Set (one) means yes, it is 💅 Clear (zero) means the path stays inside a single layer, either because inter-layer computation wasn't performed, or because a mono-layer path (no virtual TE link and no loose hop spanning the lower-layer network) was found even though inter-layer computation was used 🌸

M flag (1 bit): the PCC uses this in a PCReq to say whether it wants a mono-layer path or a multi-layer path. Set (one) means multi-layer is requested, clear (zero) means mono-layer 💜

The PCE uses the M flag in a PCRep to say which one it returned, using the same meaning: set (one) is multi-layer, clear (zero) is mono-layer 🧚

If the I flag is clear (zero), the M flag has no meaning and MUST be ignored 🙈

[RFC6457] describes two sub-options for mono-layer path, and they're lowkey iconic 👑

  • A mono-layer path specified by strict hops. The path may include virtual TE links. ✨
  • A mono-layer path that includes loose hops spanning the lower-layer network. 🦋

You pick this sub-option with the O flag in the Request Parameter (RP) object from [RFC5440] 💖

T flag (1 bit): the PCC uses this in a PCReq to tell the PCE whether triggered signaling is allowed. Set (one) means allowed, clear (zero) means not allowed 🎀

In a PCRep, the PCE uses the T flag to say whether triggered signaling is required to support the returned path. Set (one) means required, clear (zero) means not required 🌈

Quick note: triggered signaling is what supports hierarchical [RFC4206] or stitched [RFC5150] LSPs, depending on the physical attributes of the network layers 🍓

If the I flag is clear (zero), the T flag has no meaning and MUST be ignored 🙈

Now, the I and M flags are different in some important ways 🫶 When I is clear (zero), virtual TE links must not be used in path computation, and loose hops spanning the lower-layer network must not be specified either. Only regular TE links from the same layer may be used 💀

  • When I is set (one), M is clear (zero), and T is set (one), virtual TE links are allowed in path computation. And if the O flag of the RP object is set, loose hops spanning the lower-layer network may be specified too. This will kick off lower-layer LSP setup, so the inter-layer path gets set up even though the computed result only has hops from the same layer 😭
  • BUT when I is set (one), M is clear (zero), and T is clear (zero), triggered signaling isn't allowed, so virtual TE links that haven't been pre-signaled MUST NOT be used in path computation. Loose hops spanning the lower-layer network MUST NOT be specified either. Basically this is the same as I being clear (zero) 😤

Reserved bits of the INTER-LAYER object sent between a PCC and PCE in the same domain MUST be transmitted as zero, and SHOULD be ignored on receipt 🧚 A PCE that forwards a path computation request to other PCEs MUST preserve the reserved bit settings in the PCReq messages it sends, and in the PCRep messages it forwards to PCCs 💜

Last thing, and it's important 🔥 The flags in a PCRpt message show the state of an LSP, whereas the flags in PCUpd and PCInitiate show the intended or desired state as decided by the PCE 🌸

3.2. SWITCH-LAYER Object 🦋

The SWITCH-LAYER object is optional on a PCReq, and it says which switching layers a path MUST, or MUST NOT, be established in 💅 A switching layer is expressed as a switching type plus an encoding type ✨

When a PCReq uses a SWITCH-LAYER object, it gets read together with the INTER-LAYER object on the same message 🎀 If there's no INTER-LAYER object, the PCE MUST process the SWITCH-LAYER object as though inter-layer path computation had been explicitly disallowed 🙈 In that case, the SWITCH-LAYER object MUST NOT have more than one LSP Encoding Type and Switching Type with the I flag set 💀

The SWITCH-LAYER object is optional on a PCRep too. There it goes together with the NO-PATH object when path computation fails, to show which constraints couldn't be satisfied 😭

A PCRpt message MAY carry a SWITCH-LAYER object, the same way existing LSP properties are reported on that message, as described in [RFC8231] 🌈 PCRpt uses the <attribute-list> from [RFC5440] (extended by more PCEP extensions), and it can use the <attribute-list> as extended in Section 5 to carry the SWITCH-LAYER object 🧚 The SWITCH-LAYER object is NOT used on PCUpd or PCInitiate messages 🙅‍♀️

SWITCH-LAYER Object-Class is 37. 🔥

Switch-layer Object-Type is 1. ✨

Here's the object body, 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LSP Enc. Type |Switching Type |          Reserved           |I|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               .                               |
   //                              .                              //
   |                               .                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LSP Enc. Type |Switching Type |          Reserved           |I|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: The SWITCH-LAYER Object

Each row says which switching type and encoding type MUST or MUST NOT be used for the specified layer(s) in the computed path 🦋

This format is based on [RFC3471] and has the same semantics 💖

LSP Encoding Type (8 bits): see [RFC3471] for a description of parameters 🎀

Switching Type (8 bits): see [RFC3471] for a description of parameters 🌸

I flag (1 bit): this tells you whether a layer with that switching type and encoding type MUST or MUST NOT be used by the computed path 🌈 When I is set (one), the computed path MUST traverse a layer with that switching type and encoding type 💅 When I is clear (zero), the computed path MUST NOT enter or traverse any layer with that switching type and encoding type 🙅‍♀️

If a combination of switching type and encoding type isn't in the SWITCH-LAYER object, the computed path MAY traverse a layer with that combo 🧚

A PCC might only want to specify a Switching Type and not an LSP Encoding Type 🫶 In that case, the LSP Encoding Type is set to zero 💜

3.3. REQ-ADAP-CAP Object ✨

okay so the REQ-ADAP-CAP object is optional 🎀 and it's how you ask for a specific adaptation capability for both ends of the lower-layer LSP. It shows up in a PCReq message for inter-PCE communication. The PCE that handles higher-layer paths acts like a PCC here and asks a PCE that handles lower-layer paths to do the computation for it. ngl, that's a whole power move 💅

The REQ-ADAP-CAP object also shows up in a PCRep message when path computation fails. In that case the PCRep also has a NO-PATH object, and REQ-ADAP-CAP tells you which constraints couldn't be satisfied. So it's basically the receipts for why it flopped 💀

The REQ-ADAP-CAP object MAY be used in a PCReq message in a mono-layer network to specify a requested adaptation capability for both ends of the LSP. When it's used like that, it MAY be carried without an INTER-LAYER object. Mono-layer besties, you're invited too 🦋

For PCRpt and PCUpd messages, the object applies the same way as the other objects on those messages, as described in [RFC8231]. For the PCInitiate message, it's the same deal as the other objects there, as described in [RFC8281]. These messages use the <attribute-list> as defined in [RFC5440] and extended by further PCEP extensions. They can also use the <attribute-list> as extended in Section 5 to carry the REQ-ADAP-CAP object. It's giving "everything connects" 🧚

REQ-ADAP-CAP Object-Class is 38. 🌸

Req-Adap-Cap Object-Type is 1. 🌸

Here's the body format 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Switching Cap |   Encoding    |          Reserved             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: The REQ-ADAP-CAP Object

The format is based on [RFC6001]. It has equivalent semantics to the Upper Switching Capability and Lower Switching Capability fields of the Interface Adjustment Capability Descriptor (IACD). Very twinning 👯‍♀️

Switching Capability (8 bits): see [RFC4203] for a description of parameters.

Encoding (8 bits): see [RFC3471] for a description of parameters.

A PCC might want to specify a Switching Capability but not an Encoding. In that case, the Encoding MUST be set to zero. Zero is the move here, no debate 🙈

3.4. New Metric Types 💜

This document defines two new metric types for use in the PCEP METRIC object. Two new metric types, two new ways to flex 💪

IANA has assigned the value 18 to indicate the metric "Number of adaptations on a path". 🌈

IANA has assigned the value 19 to indicate the metric "Number of layers on a path". 🌈

See Sections 4.1, 4.2, and 4.3 for a description of how these metrics are applied. Go check those, they're the how-to part 🧚

3.5. SERVER-INDICATION Object 🔥

The SERVER-INDICATION is optional and it's used to indicate that the path information in the Explicit Route Object (ERO) is server-layer information. It also specifies the characteristics of that server layer, e.g., the switching capability and encoding of the server-layer path. So it's like the ERO is saying "hey, this one's the server layer, here's the vibe" ✨

Here's the body format in Figure 4 🦋

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Switching Cap |   Encoding    |           Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                       Optional TLVs                           ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: The SERVER-INDICATION Object

SERVER-INDICATION Object-Class is 39. 🌸

Server-indication Object-Type is 1. 🌸

Switching Capability (8 bits): see [RFC4203] for a description of parameters.

Encoding (8 bits): see [RFC3471] for a description of parameters.

Optional TLVs: Optional TLVs MAY be included within the object to specify more specific server-layer path information, like traffic parameters. Those TLVs will be defined by other documents, so stay tuned 👀

4. Procedures ✨

4.1. Path Computation Request 🫶

A PCC requests or allows inter-layer path computation in a PCReq message by including the INTER-LAYER object with the I flag set. The INTER-LAYER object tells the PCE whether inter-layer path computation is allowed, which path type is requested, and whether triggered signaling is allowed. Super clear, very iconic 👑

The SWITCH-LAYER object MUST NOT be present unless the INTER-LAYER object is also present. It's optionally used to specify the switching types and encoding types that define layers that must, or must not, be used in the computed path. When the SWITCH-LAYER object is used with the INTER-LAYER object I flag clear (zero), inter-layer path computation is not allowed, but the constraints in the SWITCH-LAYER object still apply. Example usage includes path computation in a single-layer GMPLS network. Single-layer, still serving 🍓

The REQ-ADAP-CAP object is optionally used to specify the interface switching capability of both ends of the lower-layer LSP. It's used in inter-PCE communication, where the PCE that handles higher-layer paths makes a request as a PCC to a PCE that handles lower-layer paths. Alternatively, the REQ-ADAP-CAP object may be used in the NMS-VNTM model, where the VNTM makes a request as a PCC to a PCE that handles lower-layer paths. Two routes, same energy ⭐

The METRIC object is optionally used to specify metric types to be optimized or bounded. When metric type 18 is used, it indicates that path computation MUST minimize or bound the number of adaptations on a path. When metric type 19 is used, it indicates that path computation MUST minimize or bound the number of layers involved on a path. Those are the non-negotiables 💅

Furthermore, so that different Objective Functions (OFs) can be applied within different network layers, multiple OF objects [RFC5541] MAY be present. In that case, the first OF object specifies an objective function for the higher-layer network, and the subsequent OF objects specify objection functions of the subsequent lower-layer networks. Each layer gets its own vibe 🌈

4.2. Path Computation Reply 💖

In the case of successful path computation, the requested PCE replies to the requesting PCC for the inter-layer path computation result in a PCRep message that MAY include the INTER-LAYER object. When the INTER-LAYER object is included in a PCRep message, the I, M, and T flags indicate the semantics of the path as described in Section 3.1. Also, when the C flag of the METRIC object in a PCReq is set, the METRIC object MUST be included in the PCRep to provide the computed metric value, as specified in [RFC5440]. No skipping that one 🙈

The PCE MAY specify the server-layer path information in the ERO. In this case, the requested PCE replies with a PCRep message that includes at least two sets of ERO information in the path-list. One is for the client-layer path information, and the other is the server-layer path information. When SERVER-INDICATION is included in a PCRep message, it indicates that the path in the ERO is the server-layer path information. The server-layer path specified in the ERO could be loose or strict. Once the PCC (e.g., NMS and ingress node) gets the replied path, it can trigger the signaling to set up the LSPs according to the computed paths. Glow-up complete ✨

In the case of unsuccessful path computation, the PCRep message also contains a NO-PATH object, and the SWITCH-TYPE object and/or REQ-ADAP-CAP MAY be used to indicate the set of constraints that could not be satisfied. Receipts again, bestie 💀

4.3. Stateful PCE and PCE Initiated LSPs 🦋

Processing for stateful PCEs is described in [RFC8231]. That document defines the PCRpt message, which lets a PCC report to a PCE that an LSP already exists in the network and delegate control of that LSP to the PCE. Delegation era 👑

When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCRpt to describe an LSP that is delegated to the PCE so that the PCE may process the LSP. 🧚

Furthermore, [RFC8231] defines the PCUpd message, which lets a PCE modify an LSP that has been delegated to it. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCUpd to describe the new attributes of the modified LSP. Glam makeover for the LSP 💅

Processing for PCE-initiated LSPs is described in [RFC8281]. That document defines the PCInitiate message, which a PCE uses to request that a PCC set up a new LSP. When the LSP is a multi-layer LSP (or a mono-layer LSP for which specific adaptations exist), the message objects defined in this document are used on the PCInitiate to describe the attributes of the new LSP. Fresh LSP, who dis 🌸

The new metric types defined in this document can also be used with the stateful PCE extensions. The format of the PCEP messages described in [RFC8231] and [RFC8281] uses <attribute-list> (which is extended in Section 5 for the purpose of including the new metrics). 🎀

The stateful PCE implementation MAY use the extension of PCReq and PCRep messages as defined in Section 5 to also enable the use of inter-layer parameters during passive stateful operations, using the LSP object. Passive stateful? Still got the inter-layer energy 🫶

5. Updated Format of PCEP Messages 🌈

Message formats in this section, like those in [RFC5440], are presented using Routing Backus-Naur Format (RBNF) as specified in [RFC5511]. Grammar time, babe 🤓

The format of the PCReq message is updated as shown in Figure 5 🍓

   <PCReq Message>::= <Common Header>
                      [<svec-list>]
                      <request-list>

      where:
         <svec-list>::=<SVEC>
                       [<svec-list>]

         <request-list>::=<request>[<request-list>]

         <request>::= <RP>
                      <END-POINTS>
                      [<LSP>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<of-list>]
                      [<RRO>[<BANDWIDTH>]]
                      [<IRO>]
                      [<LOAD-BALANCING>]
                      [<INTER-LAYER> [<SWITCH-LAYER>]]
                      [<REQ-ADAP-CAP>]
      where:

      <of-list>::=<OF>[<of-list>]
      <metric-list>::=<METRIC>[<metric-list>]

Figure 5: The Updated PCReq Message

The format of the PCRep message is updated as shown in Figure 6 🦋

   <PCRep Message> ::= <Common Header>
                       <response-list>

      where:
         <response-list>::=<response>[<response-list>]

         <response>::=<RP>
                     [<LSP>]
                     [<NO-PATH>]
                     [<attribute-list>]
                     [<path-list>]

         <path-list>::=<path>[<path-list>]

         <path>::= <ERO><attribute-list>

      where:
         <attribute-list>::=[<of-list>]
                            [<LSPA>]
                            [<BANDWIDTH>]
                            [<metric-list>]
                            [<IRO>]
                            [<INTER-LAYER>]
                            [<SWITCH-LAYER>]
                            [<REQ-ADAP-CAP>]
                            [<SERVER-INDICATION>]

         <of-list>::=<OF>[<of-list>]
         <metric-list>::=<METRIC>[<metric-list>]

Figure 6: The Updated PCRep Message

6. Manageability Considerations ✨

Okay bestie, so implementations of this spec should provide a way to configure any optional features 🎀 (like whether a PCE supports inter-layer computation and which metrics it supports). Config is everything. 💅

A MIB module for modeling PCEP (MIB = Management Information Base, fyi 📚) is described in [RFC7420]. Systems that already use a MIB module to manage their PCEP setup might want to augment it so it can control and show the inter-layer features from this doc, and add counters for messages sent and received that contain the objects defined here. Very organized of them 🧚

However, the preferred mechanism for configuration is a YANG model 🦋 Work has started on a YANG model for PCEP [PCEP-YANG], and it could be enhanced the same way as the MIB module, above.

Extra policy configuration might also be provided so a PCE can tell apart the computation services it offers to different PCCs. Main character energy for the PCE 👑

A set of monitoring tools for the PCE-based architecture is provided in [RFC5886]. Systems implementing this specification and PCE monitoring should consider extending the mechanisms defined in [RFC5886] so they can also keep an eye on inter-layer path computation requests 👀🌸

7. IANA Considerations 🌈

IANA maintains a registry called "Path Computation Element Protocol (PCEP) Numbers" 📋 Per this document, IANA has carried out actions on subregistries of that registry, so let's see what they did. 🫶

7.1. New PCEP Objects

IANA has made the following assignments in the "PCEP Objects" subregistry. Four brand-new objects, bestie 🎉

      Object-Class Value | Name  | Object-Type           | Reference
      -------------------+-------+-----------------------+-----------
      INTER-LAYER        |   36  | 0: Reserved           | RFC 8282
                         |       | 1: Inter-layer        |
                         |       | 2-15: Unassigned      |
                         |       |                       |
      SWITCH-LAYER       |   37  | 0: Reserved           | RFC 8282
                         |       | 1: Switch-layer       |
                         |       | 2-15: Unassigned      |
                         |       |                       |
      REQ-ADAP-CAP       |   38  | 0: Reserved           | RFC 8282
                         |       | 1: Req-Adap-Cap       |
                         |       | 2-15: Unassigned      |
                         |       |                       |
      SERVER-INDICATION  |   39  | 0: Reserved           | RFC 8282
                         |       | 1: Server-indication  |

                        Figure 7: New PCEP Objects

7.2. New Registry for INTER-LAYER Object Flags

IANA has created a new subregistry to manage the Flag field of the INTER-LAYER object, called the "Inter-Layer Object Path Property Bits" registry. A whole new registry, it's giving official 💖

New bit numbers may be allocated only by "IETF Review" [RFC8126]. Each bit should be tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit up to a maximum of bit 31)
  • Capability Description
  • Defining RFC

IANA has populated the registry like this:

      Bit | Flag | Multi-Layer Path Property     | Reference
      ----+------+-------------------------------+------------
      0-28|      | Unassigned                    |
       29 |   T  | Triggered Signaling Allowed   | RFC 8282
       30 |   M  | Multi-Layer Requested         | RFC 8282
       31 |   I  | Inter-Layer Allowed           | RFC 8282

            Figure 8: New Registry for INTER-LAYER Object Flags

7.3. New Metric Types

Two new metric types are defined in this document for the METRIC object (specified in [RFC5440]) ✨ IANA has made the following allocations from the "Metric Object T Field" registry. Metrics unlocked 🔥

        Value | Description                     | Reference
      ------+---------------------------------+------------
        18  | Number of adaptations on a path | RFC 8282
        19  | Number of layers on a path      | RFC 8282

                        Figure 9: New Metric Types

IANA has updated the registry to show the registration procedure of "IETF Review" as already documented in [RFC5440]. Receipts, all documented 🧾

8. Security Considerations 🚨

Okay, this part is serious, so listen up 🙈 Inter-layer traffic engineering with PCE may raise new security issues when PCE-PCE communication happens between different layer networks for inter-layer path computation. That's a big deal, bestie. 😭

Security issues may also exist when a single PCE is granted full visibility of TE information that applies to multiple layers. One PCE seeing everything across layers is a lot of power in one place 💀

The Path-Key-based mechanism defined in [RFC5520] MAY be applied to address the topology confidentiality between different layers. This is the one that can help keep the topology private between layers 🔐

9. References 📚

9.1. Normative References

9.2. Informative References

Acknowledgments 🫶

The authors would like to thank Cyril Margaria for his valuable comments. Helpful comments and suggested text were offered by Dhruv Dhody, who also fixed the RBNF. Jonathan Hardwick provided a helpful review as document shepherd. Huge thanks to all of them 🌈💜

Contributors 🌸

okay so every good doc has a crew behind it, and this one's no different 🫶 Jean-Louis Le Roux helped shape the work without being one of the authors, so he gets his own shoutout. He's over at France Telecom R&D:

Jean-Louis Le Roux
France Telecom R&D
Av Pierre Marzin
Lannion 22300
France

Email: jeanlouis.leroux@orange.com

Authors' Addresses 💅

and now the main girls who wrote it, with where to find them 🎀 first up is Eiji Oki at Kyoto University in Japan, who's giving academic icon energy 🌈

Eiji Oki
Kyoto University
Yoshida-honmachi, Sakyo-ku, Kyoto
Japan

Email: oki@i.kyoto-u.ac.jp

next is Tomonori Takeda from NTT, based in Musashino-shi, Tokyo, Japan, who's absolutely serving networking realness ✨

Tomonori Takeda
NTT
3-9-11 Midori-cho
Musashino-shi, Tokyo
Japan

Email: tomonori.takeda@ntt.com

then Adrian Farrel from Juniper Networks, who is so obsessed with protocols it's unreal 🔥

Adrian Farrel
Juniper Networks

Email: afarrel@juniper.net

and last but absolutely not least, Fatai Zhang at Huawei Technologies Co., Ltd. in Bantian, Longgang District, Shenzhen, China 🧚 slay, you can reach her by phone too 💜

Fatai Zhang
Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District, Shenzhen  518129
China

Phone: +86-755-28972912
Email: zhangfatai@huawei.com
📦 where this page comes from