RFC 9730

Interworking of GMPLS Control and Centralized Controller Systems

📅 published March 2025, from ietf

RFC 9730: Interworking of GMPLS Control and Centralized Controller Systems ✨

Part 1 of 8

okay bestie, this one is a March 2025 doc, filed as Informational 🎀. That means it's published for information and is not a Standards Track spec. The ISSN is 2070-1721 💅.

It was written by H. Zheng, Y. Lin (both Huawei Technologies), Y. Zhao (China Mobile), Y. Xu (CAICT), and D. Beller (Nokia) 🫶. The header doesn't have any Obsoletes or Updates line, so it doesn't replace or change any older RFC 🌸.

Status of This Memo ✨

so this doc is not an Internet Standards Track spec. It's published for info, full stop 💖.

It is a product of the IETF, it represents the consensus of the IETF community, it got public review, and the IESG approved it for publication 👑. Not every IESG-approved doc can become an Internet Standard though, so check Section 2 of RFC 7841 if you're curious 🙈.

for the current status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9730 🦋.

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info), as they were on the publication date. Read those carefully, because they're your rights and restrictions, not just fine print 🙈.

Code Components pulled out of this doc must include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License says 🔥.

1. Introduction 🧚

okay so GMPLS [RFC3945] takes MPLS and makes it work for different kinds of interfaces and switching, like Time-Division Multiplex Capable (TDM), Lambda Switch Capable (LSC), and Fiber-Switch Capable (FSC) 🌸. Every network element (NE) running a GMPLS control plane gathers network info from the other NEs and handles service provisioning through signaling, all in a distributed way ✨. If you want a more general look at traffic-engineering info exchange, go check [RFC7926] 💅.

on the other hand, Software-Defined Networking (SDN) came along to control transport networks centrally 👑. Centralized controllers can collect network info from each node and provision services on the right nodes 🎀. One example is ACTN [RFC8453], which sets up a hierarchy with the Provisioning Network Controller (PNC), Multi-Domain Service Coordinator (MDSC), and Customer Network Controller (CNC) as centralized controllers for different levels of network abstraction 🦋. There's also a PCE-based idea called Application-Based Network Operations (ABNO) in [RFC7491] 💜.

GMPLS can control NEs in these centralized controller setups too 🫶. A centralized controller can work with GMPLS-enabled domains, and in a domain like that, the GMPLS control plane handles service provisioning from ingress to egress 🍓. Here's the cool part: the centralized controller just sends a request to the entry node. It doesn't have to configure every NE along the path inside that domain, so it gets to use the GMPLS control plane for the heavy lifting 🌈. This doc describes how the GMPLS control plane interworks with a centralized controller system in a transport network 💖.

2. Abbreviations 📚

these are the abbreviations used in this doc. I kept the list exactly as it is:

The following abbreviations are used in this document.

ACTN:  Abstraction and Control of Traffic-Engineered Networks
   [RFC8453]

APS:  Automatic Protection Switching [G.808.1]

BRPC:  Backward Recursive PCE-Based Computation [RFC5441]

CSPF:  Constrained Shortest Path First

DoS:  Denial of Service

E2E:  end to end

ERO:  Explicit Route Object

FA:  Forwarding Adjacency

FRR:  Fast Reroute

GMPLS:  Generalized Multiprotocol Label Switching [RFC3945]

H-PCE:  Hierarchical PCE [RFC8685]

IDS:  Intrusion Detection System

IGP:  Interior Gateway Protocol

IoCs:  Indicators of Compromise [RFC9424]

IPS:  Intrusion Prevention System

IS-IS:  Intermediate System to Intermediate System

LMP:  Link Management Protocol [RFC4204]

LSP:  Label Switched Path

LSP-DB:  LSP Database

MD:  multi-domain

MDSC:  Multi-Domain Service Coordinator [RFC8453]

MITM:  Man in the Middle

ML:  multi-layer

MPI:  MDSC to PNC Interface [RFC8453]

NE:  network element

NETCONF:  Network Configuration Protocol [RFC6241]

NMS:  Network Management System

OSPF:  Open Shortest Path First

PCC:  Path Computation Client [RFC4655]

PCE:  Path Computation Element [RFC4655]

PCEP:  PCE Communication Protocol [RFC5440]

PCEP-LS:  Link State PCEP [PCEP-LS]

PLR:  Point of Local Repair

PNC:  Provisioning Network Controller [RFC8453]

RSVP:  Resource Reservation Protocol

SBI:  Southbound Interface

SDN:  Software-Defined Networking

TE:  Traffic Engineering

TED:  Traffic Engineering Database

TLS:  Transport Layer Security [RFC8446]

VNTM:  Virtual Network Topology Manager [RFC5623]

3. Overview 🌸

this section gives you the lay of the land: the GMPLS control plane, centralized controller systems, and how they interact in transport networks 💅.

a transport network [RFC5654] is a server-layer network built to provide connectivity for client-layer connectivity 🎀. It lets client traffic ride across the server-layer network resources seamlessly ✨.

3.1. Overview of GMPLS Control Plane 🦋

GMPLS separates the control plane from the data plane so it can do time-division, wavelength, and spatial switching, which matter a lot in transport networks 👑. For NE-level control in GMPLS, every node runs its own GMPLS control plane instance 💖. Things like service provisioning, protection, and restoration can happen through GMPLS communication between multiple NEs 🫶. The instance can also gather info about node and link resources to build the network topology and compute routing paths for service requests 🌈.

several protocols were designed for the GMPLS control plane [RFC3945], including link management [RFC4204], signaling [RFC3471], and routing [RFC4202] 🧚. The instances running these protocols talk to each other to swap resource info and set up LSPs 💜. That's how GMPLS control plane instances in different nodes end up with the same view of the network topology, and then provision services based on local policies 🍓.

3.2. Overview of Centralized Controller System 🔥

with SDN developing, a centralized controller architecture got introduced to transport networks 🌈. One example is in ACTN [RFC8453] 💖. In these systems, a controller knows the network topology and is responsible for provisioning incoming service requests 🙈.

there are multiple hierarchies of controllers, each one at a different level, doing different jobs 🎀. This setup makes multi-vendor, multi-domain, and multi-technology control possible ✨. For example, a higher-level controller coordinates several lower-level controllers that control different domains, for topology collection and service provisioning 🦋. Vendor-specific features can be abstracted between controllers, and a standard API (for example, generated from RESTCONF [RFC8040] / YANG [RFC7950]) may be used 👑.

3.3. GMPLS Control Interworking with a Centralized Controller System ✨

okay so besides GMPLS itself and the way the controller hierarchies talk to each other, the controllers also have to talk to the network elements (NEs) 🫶. Inside each domain, GMPLS control can be applied to each NE. The bottom-level centralized controller can act like an NE to collect network info and kick off LSPs 💅. Figure 1 shows an example of GMPLS interworking with centralized controllers. It uses ACTN terminology, so keep that in mind when you look at the diagram 🦋

                       +-------------------+
                       |    Orchestrator   |
                       |       (MDSC)      |
                       +-------------------+
                         ^       ^       ^
                         |       |       |
           +-------------+       |       +--------------+
           |                     |RESTCONF/YANG modules |
           V                     V                      V
     +-------------+      +-------------+       +-------------+
     |Controller(N)|      |Controller(G)|       |Controller(G)|
     |    (PNC)    |      |    (PNC)    |       |    (PNC)    |
     +-------------+      +-------------+       +-------------+
          ^  ^                  ^  ^                  ^  ^
          |  |                  |  |                  |  |
   NETCONF|  |PCEP       NETCONF|  |PCEP       NETCONF|  |PCEP
    /YANG |  |            /YANG |  |            /YANG |  |
          V  V                  V  V                  V  V
      .----------.  Inter-  .----------.  Inter-  .----------.
     /            \ domain /            \ domain /            \
    |              | link |     LMP      | link |     LMP      |
    |              |======|   OSPF-TE    |======|   OSPF-TE    |
    |              |      |   RSVP-TE    |      |   RSVP-TE    |
     \            /        \            /        \            /
      `----------`          `----------`          `----------`
   Non-GMPLS domain 1      GMPLS domain 2        GMPLS domain 3

Figure 1: Example of GMPLS/non-GMPLS Interworking with Controllers

  • Controller(N): a domain controller controlling a non-GMPLS domain
  • Controller(G): a domain controller controlling a GMPLS domain

So Figure 1 is the scenario with two GMPLS domains and one non-GMPLS domain 🌈. This system supports the interworking among non-GMPLS domains, GMPLS domains, and the controller hierarchies, which is so iconic ✨

For domain 1, the network elements were not enabled with GMPLS. That means the control is purely from the controller, via Network Configuration Protocol (NETCONF) [RFC6241] with a YANG data model [RFC7950] and/or PCE Communication Protocol (PCEP) [RFC5440] 🍓

For domains 2 and 3:

  • Each domain has the GMPLS control plane enabled at the physical network level 🔥. The Provisioning Network Controller (PNC) can exploit GMPLS capabilities implemented in the domain to listen to the IGP routing protocol messages (for example, OSPF Link State Advertisements (LSAs)) that the GMPLS control plane instances are disseminating into the network. That's how it learns the network topology 👀. For path computation in the domain with the PNC implementing a PCE, Path Computation Clients (PCCs) (e.g., NEs, other controllers/PCEs) use PCEP to ask the PNC for a path and get replies. The Multi-Domain Service Coordinator (MDSC) communicates with PNCs using, for example, Representational State Transfer (REST) / RESTCONF based on YANG data models. Once a PNC has learned its domain topology, it can report the topology to the MDSC. When a service arrives, the MDSC computes the path and coordinates PNCs to establish the corresponding LSP segment 💖
  • Alternatively, the NETCONF protocol can be used to retrieve topology information, using the YANG module in [RFC8795] and the technology-specific YANG module augmentations required for the specific network technology 🧚. The PNC can retrieve topology information from any NE (the GMPLS control plane instance of each NE in the domain has the same topological view), construct the topology of the domain, and export an abstract view to the MDSC. Based on the topology retrieved from multiple PNCs, the MDSC can create a topology graph of the multi-domain network and use it for path computation. To set up a service, the MDSC can exploit the YANG module in [YANG-TE] together with the technology-specific YANG module augmentations 💜

This document focuses on the interworking between GMPLS and the centralized controller system, including:

  • the interworking between the GMPLS domains and the centralized controllers (including the orchestrator, if it exists) controlling the GMPLS domains, and
  • the interworking between a non-GMPLS domain (which is controlled by a centralized controller system) and a GMPLS domain, through the controller hierarchy architecture.

For convenience, this document uses the following terminologies for the controller and the orchestrator:

  • Controller(G): a domain controller controlling a GMPLS domain (the Controller(G) of the GMPLS domains 2 and 3 in Figure 1)
  • Controller(N): a domain controller controlling a non-GMPLS domain (the Controller(N) of the non-GMPLS domain 1 in Figure 1)
  • H-Controller(G): a domain controller controlling the higher-layer GMPLS domain, in the context of multi-layer networks
  • L-Controller(G): a domain controller controlling the lower-layer GMPLS domain, in the context of multi-layer networks
  • H-Controller(N): a domain controller controlling the higher-layer non-GMPLS domain, in the context of multi-layer networks
  • L-Controller(N): a domain controller controlling the lower-layer non-GMPLS domain, in the context of multi-layer networks
  • Orchestrator(MD): an orchestrator used to orchestrate the multi-domain networks
  • Orchestrator(ML): an orchestrator used to orchestrate the multi-layer networks

4. Discovery Options 🔍

In GMPLS control, the link connectivity must be verified between each pair of nodes. This way, link resources, which are fundamental resources in the network, are discovered by both ends of the link 🦋

4.1. LMP

The Link Management Protocol (LMP) [RFC4204] runs between nodes and manages TE links. Besides setting up and maintaining control channels, LMP can be used to verify the data link connectivity and correlate the link properties 💅

5. Routing Options 🗺️

In GMPLS control, link state information is flooded within the network as defined in [RFC4202]. Each node in the network can build the network topology from the flooded link state information. Routing protocols such as OSPF-TE [RFC4203] and IS-IS-TE [RFC5307] have been extended to support different interfaces in GMPLS 👑

In a centralized controller system, the centralized controller can be placed in the GMPLS network and passively receive the IGP information flooded in the network. That way, the centralized controller can construct and update the network topology 🌸

5.1. OSPF-TE

OSPF-TE is introduced for TE networks in [RFC3630]. OSPF extensions have been defined in [RFC4203] to enable the capability of link state information for the GMPLS network. Building on this work, OSPF has been extended to support technology-specific routing. The routing protocols for the Optical Transport Network (OTN), Wavelength Switched Optical Network (WSON), and optical flexi-grid networks are defined in [RFC7138], [RFC7688], and [RFC8363], respectively 🦋

5.2. IS-IS-TE

IS-IS-TE is introduced for TE networks in [RFC5305], is extended to support GMPLS routing functions [RFC5307], and has been updated [RFC7074] to support the latest GMPLS switching capability and Types fields 💜

5.3. NETCONF/RESTCONF

NETCONF [RFC6241] and RESTCONF [RFC8040] protocols were originally used for network configuration. These protocols can also utilize topology-related YANG modules, such as those in [RFC8345] and [RFC8795]. They also provide a powerful mechanism for the notification (in addition to the provisioning and monitoring) of topology changes to the client 🔔

6. Path Computation 🧮

6.1. Controller-Based Path Computation

Once a controller learns the network topology, it can use the available resources to serve service requests by performing path computation. Because of abstraction, the controllers may not have enough information to compute the optimal path 🙈. In this case, the controller can interact with other controllers by sending, for example, YANG-based path computation requests [PATH-COMP] or PCEP, to compute a set of potential optimal paths. Then, based on its constraints, policy, and specific knowledge (e.g., cost of access link), the controller can choose the more feasible path for end-to-end (E2E) service path setup 💖

Path computation is one of the key objectives in various types of controllers. In the given architecture, different components that have the capability to compute the path are possible 🌈

6.2. Constraint-Based Path Computing in GMPLS Control

In GMPLS control, a routing path may be computed by the ingress node [RFC3473] based on the ingress node Traffic Engineering Database (TED). In this case, constraint-based path computation is performed according to the local policy of the ingress node ✨

6.3. Path Computation Element (PCE)

The PCE was first introduced in [RFC4655] as a functional component that offers services for computing paths within a network. In [RFC5440], path computation is achieved using the TED, which maintains a view of the link resources in the network. The introduction of the PCE has significantly improved the quality of network planning and offline computation. However, there is a potential risk that the computed path may be infeasible when there is a diversity requirement, because a stateless PCE lacks knowledge about previously computed paths 😭

To address this issue, a stateful PCE has been proposed in [RFC8231]. Besides the TED, an additional LSP Database (LSP-DB) is introduced to archive each LSP computed by the PCE. This way, the PCE can easily determine the relationship between the computing path and former computed paths. In this approach, the PCE provides computed paths to the PCC, and then the PCC decides which path is deployed and when it is to be established 🎀

With PCE-initiated LSPs [RFC8281], the PCE can trigger the PCC to perform setup, maintenance, and teardown of the PCE-initiated LSP under the stateful PCE model. This would allow a dynamic network that is centrally controlled and deployed 🦋

In a centralized controller system, the PCE can be implemented within the centralized controller. The centralized controller then calculates paths based on its local policies. Alternatively, the PCE can be located outside of the centralized controller. In this scenario, the centralized controller functions as a PCC and sends a path computation request to the PCE using the PCEP. A reference architecture for this can be found in [RFC7491] 🧚

7. Signaling Options ✨

Okay so signaling is how we actually set up LSPs in GMPLS control 🛤️💖 Messages get passed hop by hop between the ingress node and the egress node of the LSP, and each hop allocates labels as it goes. Once the labels are allocated along the whole path, the LSP setup is done and we're literally good to go 🎀 Signaling protocols like Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3473] have been extended to support the different interfaces in GMPLS 🔥

7.1. RSVP-TE 💅

RSVP-TE was introduced in [RFC3209] and then extended to do GMPLS signaling in [RFC3473] ✨ Several label formats are defined for a generalized label request, a generalized label, a suggested label, and label sets 🧚 Building on [RFC3473], RSVP-TE got extended again to handle technology-specific signaling. The RSVP-TE extensions for the OTN, WSON, and optical flexi-grid networks are defined in [RFC7139], [RFC7689], and [RFC7792], respectively 🌈

8. Interworking Scenarios 🦋

8.1. Topology Collection and Synchronization 🌸

Topology info is needed on both network elements and controllers 🫶 On a network element it's usually raw info, while the controller can use raw, reduced, or abstracted topology. Three different abstraction methods are described in [RFC8453], and different controllers can pick the matching method depending on the application 🍓

When the network topology changes, the impacted network elements need to report those changes to all the other network elements, plus the controller, so everyone stays in sync 👑 The inter-NE synchronization can be done with the protocols mentioned in Sections 4 and 5 (iykyk 😉). Topology sync between NEs and controllers can happen either through the routing protocols OSPF-TE/PCEP-LS in [PCEP-LS], or through NETCONF protocol notifications with a YANG module 💜

8.2. Multi-Domain Service Provisioning 💖

Service provisioning can be deployed based on the topology info on controllers and network elements ✨ Lots of methods have been specified for single-domain service provisioning, like the PCEP and RSVP-TE methods 🙈

Multi-domain service provisioning needs coordination among the controller hierarchies 😭 Given a service request, the end-to-end delivery procedure may include interactions at any level (i.e., interface) in the controller hierarchy (e.g., MPI and SBI for ACTN) 🔥 The computation for a cross-domain path is usually completed by controllers who have a global view of the topologies. Then the configuration is decomposed into lower-level controllers, which configure the network elements to set up the path 🧚

A combination of centralized and distributed protocols may be necessary to interact between network elements and controllers 💅 Several methods can be used to create the inter-domain path:

  1. With an end-to-end RSVP-TE session:

In this method, all the domains need to support the RSVP-TE protocol and thus need to be GMPLS domains. The Controller(G) of the source domain triggers the source node to create the end-to-end RSVP-TE session, and the assignment and distribution of the labels on the inter-domain links are done by the border nodes of each domain, using RSVP-TE protocol. So this method requires the interworking of RSVP-TE protocols between different domains 🌸

There are two possible methods:

1.1) One single end-to-end RSVP-TE session:

In this method, an end-to-end RSVP-TE session from the source node to the destination node will be used to create the inter-domain path. A typical example would be the PCE initiation scenario, in which a PCE message (PCInitiate) is sent from the Controller(G) to the source node, triggering an RSVP procedure along the path. Similarly, the interaction between the controller and the source node of the source domain can be achieved by using the NETCONF protocol with corresponding YANG modules, and then it can be completed by running RSVP among the network elements 🦋

1.2) LSP Stitching:

The LSP stitching method defined in [RFC5150] can also create the E2E LSP. That is, when the source node receives an end-to-end path creation request (e.g., using PCEP or NETCONF protocol), the source node starts an end-to-end RSVP-TE session along the endpoints of each LSP segment (S-LSP) (refers to S-LSP in [RFC5150]) of each domain, to assign the labels on the inter-domain links between each pair of neighbor S-LSPs and to stitch the end-to-end LSP to each S-LSP. See Figure 2 as an example. 🧩

Note that the S-LSP in each domain can be either created by its Controller(G) in advance, or created dynamically, triggered by the end-to-end RSVP-TE session.

                        +------------------------+
                        |    Orchestrator(MD)    |
                        +-----------+------------+
                                    |
       +---------------+     +------V-------+     +---------------+
       | Controller(G) |     | Controller(G)|     | Controller(G) |
       +-------+-------+     +------+-------+     +-------+-------+
               |                    |                     |
      +--------V--------+   +-------V--------+   +--------V--------+
      |Client           |   |                |   |           Client|
      |Signal   Domain 1|   |    Domain 2    |   |Domain 3   Signal|
      |  |              |   |                |   |              |  |
      |+-+-+            |   |                |   |            +-+-+|
      || | |  +--+  +--+|   |+--+  +--+  +--+|   |+--+  +--+  | | ||
      || | |  |  |  |  ||   ||  |  |  |  |  ||   ||  |  |  |  | | ||
      || ******************************************************** ||
      ||   |  |  |  |  ||   ||  |  |  |  |  ||   ||  |  |  |  |   ||
      |+---+  +--+  +--+|   |+--+  +--+  +--+|   |+--+  +--+  +---+|
      +-----------------+   +----------------+   +-----------------+
       |   .           .     .              .     .           .   |
       |   .<-S-LSP 1->.     .<- S-LSP 2 -->.     .<-S-LSP 3->.   |
       |               .     .              .     .               |
       |-------------->.---->.------------->.---->.-------------->|
       |<--------------.<----.<-------------.<----.<--------------|
       |       End-to-end RSVP-TE session for LSP stitching       |

                        Figure 2: LSP Stitching
  1. Without an end-to-end RSVP-TE session:

In this method, each domain can be a GMPLS domain or a non-GMPLS domain. Each controller (which may be a Controller(G) or a Controller(N)) is responsible for creating the path segment within its domain. The border node does not need to communicate with other border nodes in other domains for the distribution of labels on inter-domain links, so an end-to-end RSVP-TE session through multiple domains is not required, and the interworking of the RSVP-TE protocol between different domains is not needed 🫧

Note that path segments in the source domain and the destination domain are "asymmetrical" segments, because the configuration of client signal mapping into the server-layer tunnel is needed at only one end of the segment, while configuration of the server-layer cross-connect is needed at the other end of the segment. See the example in Figure 3. 👀

                     +------------------------+
                     |    Orchestrator(MD)    |
                     +-----------+------------+
                                 |
    +---------------+     +------V-------+     +---------------+
    |  Controller   |     |  Controller  |     |  Controller   |
    +-------+-------+     +------+-------+     +-------+-------+
            |                    |                     |
   +--------V--------+   +-------V--------+   +--------V--------+
   |Client   Domain 1|   |    Domain 2    |   | Domain 3  Client|
   |Signal           |   |                |   |           Signal|
   |  |  Server layer|   |                |   |              |  |
   |  |     tunnel   |   |                |   |              |  |
   |+-+-+       ^    |   |                |   |            +-+-+|
   || | |  +--+ |+--+|   |+--+  +--+  +--+|   |+--+  +--+  | | ||
   || | |  |  | ||  ||   ||  |  |  |  |  ||   ||  |  |  |  | | ||
   || ******************************************************** ||
   ||   |  |  |  |  || . ||  |  |  |  |  || . ||  |  |  |  |   ||
   |+---+  +--+  +--+| . |+--+  +--+  +--+| . |+--+  +--+  +---+|
   +-----------------+ . +----------------+ . +-----------------+
    .                  .                    .                  .
    .<-Path Segment 1->.<--Path Segment 2-->.<-Path Segment 3->.

           Figure 3: Example of an Asymmetrical Path Segment

The PCEP / GMPLS protocols should support the creation of such asymmetrical segments 🦄

Note also that mechanisms to assign the labels in the inter-domain links also need to be considered. There are two possible methods:

2.1) Inter-domain labels assigned by NEs:

The concept of a stitching label that allows stitching local path segments was introduced in [RFC5150] and [SPCE-ID], in order to form the inter-domain path crossing several different domains. It also describes the Backward Recursive PCE-Based Computation (BRPC) [RFC5441] and Hierarchical PCE (H-PCE) [RFC8685] PCInitiate procedure. In other words, the ingress node of each downstream domain assigns the stitching label for the inter-domain link between the downstream domain and its upstream neighbor domain. This stitching label is then passed to the upstream neighbor domain by PCE protocol, and it will be used for the path segment creation in that upstream neighbor domain 🧠

2.2) Inter-domain labels assigned by the controller:

If the resources of inter-domain links are managed by the Orchestrator(MD), each domain controller can provide to the Orchestrator(MD) the list of available labels (e.g., time slots if the OTN is the scenario) using topology-related YANG modules and specific technology-related extensions. Once the Orchestrator(MD) has computed the E2E path, RSVP-TE or PCEP can be used in the different domains to set up the related segment tunnel consisting of information about inter-domain labels. For example, for PCEP, the label Explicit Route Object (ERO) can be included in the PCInitiate message to indicate the inter-domain labels, so that each border node of each domain can configure the correct cross-connect within itself 🎀

8.3. Multi-Layer Service Provisioning ✨

okay so GMPLS can totally interwork with centralized controller systems in multi-layer networks 🧚

   +----------------+
   |Orchestrator(ML)|
   +------+--+------+
          |  |                            Higher-layer Network
          |  |                           .--------------------.
          |  |                          /                      \
          |  |   +--------------+      |   +--+   Link   +--+   |
          |  +-->| H-Controller +----->|   |  |**********|  |   |
          |      +--------------+      |   +--+          +--+   |
          |                             \    .            .    /
          |                               `--.------------.---`
          |                                  .            .
          |                              .---.------------.---.
          |                             /    .            .    \
          |      +--------------+      |   +--+   +--+   +--+   |
          +----->| L-Controller +----->|   | ============== |   |
                 +--------------+      |   +--+   +--+   +--+   |
                                        \         H-LSP        /
                                          `-------------------`
                                           Lower-layer Network

Figure 4: GMPLS-controller Interworking in Multi-Layer Networks

An example with two layers of network is shown in Figure 4. 🦋 In this example, the GMPLS control plane is enabled in at least one layer network (otherwise, it is out of the scope of this document) and interworks with the controller of its domain (H-Controller and L-Controller, respectively). The Orchestrator(ML) is used to coordinate the control of the multi-layer network. 💅

8.3.1. Multi-Layer Path Computation

[RFC5623] describes three inter-layer path computation models and four inter-layer path control models. 🌸

  • 3 path computation models:
    • Single PCE path computation model
    • Multiple PCE path computation with inter-PCE communication model
    • Multiple PCE path computation without inter-PCE communication model
  • 4 path control models:
    • PCE Virtual Network Topology Manager (PCE-VNTM) cooperation model
    • Higher-layer signaling trigger model
    • Network Management System VNTM (NMS-VNTM) cooperation model (integrated flavor)
    • NMS-VNTM cooperation model (separate flavor)

Section 4.2.4 of [RFC5623] also provides all the possible combinations of inter-layer path computation and inter-layer path control models. 📚

To apply [RFC5623] in a multi-layer network with GMPLS-controller interworking, the H-Controller and the L-Controller can act as the PCE Hi and PCE Lo, respectively. Typically, the Orchestrator(ML) can act as a VNTM because it has the abstracted view of both the higher-layer and lower-layer networks. 👑

Table 1 shows all possible combinations of path computation and path control models in multi-layer network with GMPLS-controller interworking. 🎀

    +======================+========+================+===============+
    | Path computation /   | Single | Multiple PCE   | Multiple PCE  |
    | Path control         | PCE    | with inter-PCE | w/o inter-PCE |
    +======================+========+================+===============+
    | PCE-VNTM cooperation | N/A    | Yes            | Yes           |
    +----------------------+--------+----------------+---------------+
    | Higher-layer         | N/A    | Yes            | Yes           |
    | signaling trigger    |        |                |               |
    +----------------------+--------+----------------+---------------+
    | NMS-VNTM cooperation | N/A    | Yes (1)        | No (1)        |
    | (integrated flavor)  |        |                |               |
    +----------------------+--------+----------------+---------------+
    | NMS-VNTM cooperation | N/A    | No (1)         | Yes (1)       |
    | (separate flavor)    |        |                |               |
    +----------------------+--------+----------------+---------------+

Table 1: Combinations of Path Computation and Path Control Models

Note that:

  • Since there is one PCE in each layer network, the path computation model "Single PCE path computation" is not applicable (N/A). 🙈
  • For the other two path computation models "Multiple PCE with inter-PCE" and "Multiple PCE w/o inter-PCE", the possible combinations are the same as defined in [RFC5623]. More specifically:
    • (1) The path control models "NMS-VNTM cooperation (integrated flavor)" and "NMS-VNTM cooperation (separate flavor)" are the typical models to be used in a multi-layer network with GMPLS-controller interworking. This is because, in these two models, the path computation is triggered by the NMS or VNTM. And in the centralized controller system, the path computation requests are typically from the Orchestrator(ML) (acts as VNTM). ✨
    • For the other two path control models "PCE-VNTM cooperation" and "Higher-layer signaling trigger", the path computation is triggered by the NEs, i.e., the NE performs PCC functions. It is still possible to use these two models, although they are not the main methods. 🌈

8.3.2. Cross-Layer Path Creation

In a multi-layer network, a lower-layer LSP in the lower-layer network can be created, which will construct a new link in the higher-layer network. Such a lower-layer LSP is called Hierarchical LSP, or H-LSP for short; see [RFC6107]. 🦋

The new link constructed by the H-LSP can then be used by the higher-layer network to create new LSPs. 💖

As described in [RFC5212], two methods are introduced to create the H-LSP: the static (pre-provisioned) method and the dynamic (triggered) method. 🧚

  1. Static (pre-provisioned) method:

In this method, the H-LSP in the lower-layer network is created in advance. After that, the higher-layer network can create LSPs using the resource of the link constructed by the H-LSP.

The Orchestrator(ML) is responsible to decide the creation of H-LSP in the lower-layer network if it acts as a VNTM. Then it requests the L-Controller to create the H-LSP via, for example, an MPI under the ACTN architecture. 🫶

If the lower-layer network is a GMPLS domain, the L-Controller(G) can trigger the GMPLS control plane to create the H-LSP. As a typical example, the PCInitiate message can be used for the communication between the L-Controller and the source node of the H-LSP. And the source node of the H-LSP can trigger the RSVP-TE signaling procedure to create the H-LSP, as described in [RFC6107]. 🔥

If the lower-layer network is a non-GMPLS domain, other methods may be used by the L-Controller(N) to create the H-LSP, which is out of scope of this document. 🙈

  1. Dynamic (triggered) method:

In this method, the signaling of LSP creation in the higher-layer network will trigger the creation of H-LSP in the lower-layer network dynamically, if it is necessary. Therefore, both the higher-layer and lower-layer networks need to support the RSVP-TE protocol and thus need to be GMPLS domains. 💜

In this case, after the cross-layer path is computed, the Orchestrator(ML) requests the H-Controller(G) for the cross-layer LSP creation. As a typical example, the MPI under the ACTN architecture could be used. ✨

The H-Controller(G) can trigger the GMPLS control plane to create the LSP in the higher-layer network. As a typical example, the PCInitiate message can be used for the communication between the H-Controller(G) and the source node of the higher-layer LSP, as described in Section 4.3 of [RFC8282]. At least two sets of ERO information should be included to indicate the routes of higher-layer LSP and lower-layer H-LSP. 🎀

The source node of the higher-layer LSP follows the procedure defined in Section 4 of [RFC6001] to trigger the GMPLS control plane in both the higher-layer network and the lower-layer network to create the higher-layer LSP and the lower-layer H-LSP. 🌸

On success, the source node of the H-LSP should report the information of the H-LSP to the L-Controller(G) via, for example, the PCRpt message. 🍓

If the higher-layer network and the lower-layer network are under the same GMPLS control plane instance, the H-LSP can be a Forwarding Adjacency LSP (FA-LSP). Then the information of the link constructed by this FA-LSP can be advertised in the routing instance, so that the H-Controller can be aware of this new FA. [RFC4206] and the following updates to it (including [RFC6001] and [RFC6107]) describe the detailed extensions to support advertisement of an FA. 🦋

If the higher-layer network and the lower-layer network are under separate GMPLS control plane instances or if one of the layer networks is a non-GMPLS domain, after an H-LSP is created in the lower-layer network, the link discovery procedure will be triggered in the higher-layer network to discover the information of the link constructed by the H-LSP. The LMP defined in [RFC4204] can be used if the higher-layer network supports GMPLS. The information of this new link will be advertised to the H-Controller. 💖

8.4. Recovery

The GMPLS recovery functions are described in [RFC4426]. Span protection and end-to-end protection and restoration are discussed with different protection schemes and message exchange requirements. 🛡️

Related RSVP-TE extensions to support end-to-end recovery are described in [RFC4872]. The extensions in [RFC4872] include protection, restoration, preemption, and rerouting mechanisms for an end-to-end LSP. Besides end-to-end recovery, a GMPLS segment recovery mechanism is defined in [RFC4873], which also intends to be compatible with Fast Reroute (FRR) (see [RFC4090], which defines RSVP-TE extensions for the FRR mechanism, and [RFC8271], which describes the updates of the GMPLS RSVP-TE protocol for FRR of GMPLS TE-LSPs). 🌈

8.4.1. Span Protection

Span protection refers to the protection of the link between two neighboring switches. The main protocol requirements include: 🧚

  • Link management: Link property correlation on the link protection type
  • Routing: Announcement of the link protection type
  • Signaling: Indication of link protection requirement for that LSP

GMPLS already supports the above requirements, and there are no new requirements in the scenario of interworking between GMPLS and a centralized controller system. 💅✨

8.4.2. LSP Protection

okay so LSP protection covers both end-to-end and segment LSP protection 💖 and the same rules apply to both, bestie:

  • In the provisioning phase:
    • In both single-domain and multi-domain scenarios, the disjoint path computation can be done by the centralized controller system, since it has the global topology and resource view 🧠✨
    • The path creation can be done by the procedure described in Section 8.2 🎀
  • In the protection switchover phase:
    • In both single-domain and multi-domain scenarios, the existing standards give us a distributed way to trigger the protection switchover 🔥. Examples are the data plane Automatic Protection Switching (APS) mechanism described in [G.808.1], [RFC7271], and [RFC8234], or the GMPLS Notify mechanism described in [RFC4872] and [RFC4873] 💅
    • When GMPLS is interworking with a centralized controller system, using these distributed mechanisms instead of a centralized one (where the controller triggers the protection switchover) can significantly shorten the protection switching time ⭐ it's giving speed, honestly 😭

8.4.3. Single-Domain LSP Restoration

  • Pre-planned LSP protection (including shared-mesh restoration):
    • In pre-planned protection, the protecting LSP is established only in the control plane during the provisioning phase, and it gets activated in the data plane once a failure occurs 🦋
    • In the scenario of interworking between GMPLS and a centralized controller system, the route of the protecting LSP can be computed by the centralized controller system. This takes the advantage of making better use of network resources, especially for resource sharing in shared-mesh restoration 🌸
  • Full LSP rerouting:
    • In full LSP rerouting, normal traffic gets switched to an alternate LSP that is fully established only after a failure occurrence 🧚
    • As described in [RFC4872] and [RFC4873], the alternate route can be computed on demand when there is a failure occurrence, or it can be pre-computed and stored before a failure occurrence 🍓
    • In a fully distributed scenario, pre-computation offers a faster restoration time, but it has the risk that the pre-computed alternate route may become out-of-date due to changes in the network 🙈 the vibes are a little risky tbh
    • In the scenario of interworking between GMPLS and a centralized controller system, the pre-computation of the alternate route could take place in the centralized controller (and may be stored in the controller or the head-end node of the LSP). That way, any changes in the network can trigger a refresh of the alternate route by the centralized controller. This makes sure that the alternate route will not become out-of-date 👑🫶

8.4.4. Multi-Domain LSP Restoration ✨

okay so this part is about LSPs that cross more than one domain, and not every domain is going to be running GMPLS distributed control 🌸 some might, some might not, and the whole thing is about figuring out what to do in each case 💅

A working LSP may traverse multiple domains, each of which may or may not support a GMPLS distributed control plane. 🦋

If all the domains support GMPLS, both the end-to-end rerouting method and the domain segment rerouting method could be used. ✨

If only some domains support GMPLS, the domain segment rerouting method could be used in those GMPLS domains. For other domains that do not support GMPLS, other mechanisms may be used to protect the LSP segments, which are out of scope of this document. 🎀 that last bit is kinda the "not my problem in this doc" zone, iykyk 🙈

  1. End-to-end rerouting:

In this scenario, a failure on the working LSP inside any domain or on the inter-domain links will trigger the end-to-end restoration. 💖

In both pre-planned and full LSP rerouting, the end-to-end protecting LSP could be computed by the centralized controller system and could be created by the procedure described in Section 8.2. Note that the end-to-end protecting LSP may traverse different domains from the working LSP, depending on the result of multi-domain path computation for the protecting LSP. 🧚 the protecting path is not guaranteed to hang out in the same domains as the working one, so don't assume it will!

                    +----------------+
                    |Orchestrator(MD)|
                    +-------.--------+
       ............................................
       .             .              .             .
  +----V-----+  +----V-----+   +----V-----+  +----V-----+
  |Controller|  |Controller|   |Controller|  |Controller|
  |  (G) 1   |  |  (G) 2   |   |  (G) 3   |  |  (G) 4   |
  +----.-----+  +-------.--+   +-------.--+  +----.-----+
       .                .              .          .
  +----V--------+     +-V-----------+  .  +-------V-----+
  |  Domain 1   |     |  Domain 2   |  .  |  Domain 4   |
  |+---+   +---+|     |+---+   +---+|  .  |+---+   +---+|
  || ===/~/======/~~~/================================ ||
  |+-*-+   +---+|     |+---+   +---+|  .  |+---+   +-*-+|
  |  *          |     +-------------+  .  |          *  |
  |  *          |                      .  |          *  |
  |  *          |     +-------------+  .  |          *  |
  |  *          |     |  Domain 3   <...  |          *  |
  |+-*-+   +---+|     |+---+   +---+|     |+---+   +-*-+|
  || ************************************************* ||
  |+---+   +---+|     |+---+   +---+|     |+---+   +---+|
  +-------------+     +-------------+     +-------------+

  ====: Working LSP   ****: Protecting LSP   /~/: Failure

                 Figure 5: End-to-End Restoration
  1. Domain segment rerouting:

2.1) Intra-domain rerouting:

If failure occurs on the working LSP segment in a GMPLS domain, the segment rerouting [RFC4873] could be used for the working LSP segment in that GMPLS domain. Figure 6 shows an example of intra-domain rerouting. 🌈

The intra-domain rerouting of a non-GMPLS domain is out of scope of this document. 💀

                         +----------------+
                         |Orchestrator(MD)|
                         +-------.--------+
            ............................................
            .             .              .             .
       +----V-----+  +----V-----+   +----V-----+  +----V-----+
       |Controller|  |Controller|   |Controller|  |Controller|
       |  (G) 1   |  |(G)/(N) 2 |   |(G)/(N) 3 |  |(G)/(N) 4 |
       +----.-----+  +-------.--+   +-------.--+  +----.-----+
            .                .              .          .
       +----V--------+     +-V-----------+  .  +-------V-----+
       |  Domain 1   |     |  Domain 2   |  .  |  Domain 4   |
       |+---+   +---+|     |+---+   +---+|  .  |+---+   +---+|
       || ===/~/=========================================== ||
       |+-*-+   +-*-+|     |+---+   +---+|  .  |+---+   +---+|
       |  *       *  |     +-------------+  .  |             |
       |  *       *  |                      .  |             |
       |  *       *  |     +-------------+  .  |             |
       |  *       *  |     |  Domain 3   <...  |             |
       |+-*-+   +-*-+|     |+---+   +---+|     |+---+   +---+|
       || ********* ||     ||   |   |   ||     ||   |   |   ||
       |+---+   +---+|     |+---+   +---+|     |+---+   +---+|
       +-------------+     +-------------+     +-------------+

     ====: Working LSP  ****: Rerouting LSP segment  /~/: Failure

               Figure 6: Intra-Domain Segment Rerouting

2.2) Inter-domain rerouting:

If intra-domain segment rerouting failed (e.g., due to lack of resource in that domain), or if failure occurs on the working LSP on an inter-domain link, the centralized controller system may coordinate with other domain(s) to find an alternative path or path segment to bypass the failure and then trigger the inter-domain rerouting procedure. Note that the rerouting path or path segment may traverse different domains from the working LSP. 🫶

The domains involved in the inter-domain rerouting procedure need to be GMPLS domains, which support the RSVP-TE signaling for the creation of a rerouting LSP segment. 👑

For inter-domain rerouting, the interaction between GMPLS and a centralized controller system is needed: ✨

  • A report of the result of intra-domain segment rerouting to its Controller(G) and then to the Orchestrator(MD). The former could be supported by the PCRpt message in [RFC8231], while the latter could be supported by the MPI of ACTN. 🍓
  • A report of inter-domain link failure to the two Controllers (e.g., Controller(G) 1 and Controller(G) 2 in Figure 7) by which the two ends of the inter-domain link are controlled, respectively, and then to the Orchestrator(MD). The former could be done as described in Section 8.1, while the latter could be supported by the MPI of ACTN. 🔥
  • The computation of a rerouting path or path segment crossing multi-domains by the centralized controller system (see [PATH-COMP]). 💜
  • The creation of a rerouting LSP segment in each related domain. The Orchestrator(MD) can send the LSP segment rerouting request to the source Controller(G) (e.g., Controller(G) 1 in Figure 7) via MPI interface, and then the Controller(G) can trigger the creation of a rerouting LSP segment through multiple GMPLS domains using GMPLS rerouting signaling. Note that the rerouting LSP segment may traverse a new domain that the working LSP does not traverse (e.g., Domain 3 in Figure 7). 🦋 plot twist: the detour can wander into a brand new domain!!
                         +----------------+
                         |Orchestrator(MD)|
                         +-------.--------+
        ..................................................
        .               .                .               .
  +-----V------+  +-----V------+   +-----V------+  +-----V------+
  | Controller |  | Controller |   | Controller |  | Controller |
  |   (G) 1    |  |   (G) 2    |   |   (G) 3    |  | (G)/(N) 4  |
  +-----.------+  +------.-----+   +-----.------+  +-----.------+
        .                .               .               .
  +-----V-------+   +----V--------+      .        +------V------+
  |  Domain 1   |   |  Domain 2   |      .        |  Domain 4   |
  |+---+   +---+|   |+---+   +---+|      .        |+---+   +---+|
  ||   |   |   ||   ||   |   |   ||      .        ||   |   |   ||
  || ============/~/========================================== ||
  || * |   |   ||   ||   |   | * ||      .        ||   |   |   ||
  |+-*-+   +---+|   |+---+   +-*-+|      .        |+---+   +---+|
  |  *          |   +----------*--+      .        |             |
  |  *          |              *****     .        |             |
  |  *          |       +----------*-----V----+   |             |
  |  *          |       |          *Domain 3  |   |             |
  |+-*-+   +---+|       |+---+   +-*-+   +---+|   |+---+   +---+|
  || * |   |   ||       ||   |   | * |   |   ||   ||   |   |   ||
  || ******************************* |   |   ||   ||   |   |   ||
  ||   |   |   ||       ||   |   |   |   |   ||   ||   |   |   ||
  |+---+   +---+|       |+---+   +---+   +---+|   |+---+   +---+|
  +-------------+       +---------------------+   +-------------+

   ====: Working LSP  ****: Rerouting LSP segment  /~/: Failure

          Figure 7: Inter-Domain Segment Rerouting

8.4.5. Fast Reroute ⚡

[RFC4090] defines two methods of fast reroute: the one-to-one backup method and the facility backup method. For both methods: 🎀

  1. Path computation of protecting LSP:

In Section 6.2 of [RFC4090], the protecting LSP (detour LSP in one-to-one backup or bypass tunnel in facility backup) could be computed by the Point of Local Repair (PLR) using, for example, a Constrained Shortest Path First (CSPF) computation. In the scenario of interworking between GMPLS and a centralized controller system, the protecting LSP could also be computed by the centralized controller system, as it has the global view of the network topology, resources, and information of LSPs. 🌸

  1. Protecting LSP creation:

In the scenario of interworking between GMPLS and a centralized controller system, the protecting LSP could still be created by the RSVP-TE signaling protocol as described in [RFC4090] and [RFC8271]. 🧚

In addition, if the protecting LSP is computed by the centralized controller system, the Secondary Explicit Route Object defined in [RFC4873] could be used to explicitly indicate the route of the protecting LSP. 💅

  1. Failure detection and traffic switchover:

If a PLR detects that failure occurs, it may significantly shorten the protection switching time by using the distributed mechanisms described in [RFC4090] to switch the traffic to the related detour LSP or bypass tunnel rather than doing so in a centralized way. ⭐

8.5. Controller Reliability 🛡️

The reliability of the controller is crucial due to its important role in the network. It is essential that if the controller is shut down or disconnected from the network, all currently provisioned services in the network continue to function and carry traffic. In addition, protection switching to pre-established paths should also work. 💖 It is desirable to have protection mechanisms, such as redundancy, to maintain full operational control even if one instance of the controller fails. This can be achieved through controller backup or functionality backup. There are several controller backup or federation mechanisms in the literature. It is also more reliable to have function backup in the network element to guarantee performance in the network. 👑 literally the whole vibe is "the controller can't just be a single point of drama," periodt 💅

9. Manageability Considerations 🎀

Okay bestie, every network entity, controllers and network elements, should be managed properly, with the right trust and security policies applied (see Section 10), because they're all going to be chatting with each other 💬 The manageability stuff for controller hierarchies and for network elements still applies, respectively. And the overall manageability of the protocols running in the network should also be a key consideration 💅

Everyone's job should be crystal clear 🫶 The way controllers split up control of function and policy should stay consistent through a proper negotiation process. No messy overlaps, just clean handoffs ✨

10. Security Considerations 🔐

Bestie, this document is all about how GMPLS and controller hierarchies work together 🦋 The security requirements for both systems still apply, no exceptions. The protocols referenced here come with their own security considerations, which must be adhered to, and their core specs and the risks they've already flagged are detailed earlier in this document. Read those first, periodt 📖

Security is a huge deal in both GMPLS and controller-based networks 😭 Solid security mechanisms are a must if you want to protect against threats and vulnerabilities. Here are the expanded security considerations, plus some relevant IETF RFC references 💜

  • Authentication and Authorization: It's essential to implement strong authentication and authorization so you can control access to the controller from multiple network elements. This makes sure only authorized devices and users can interact with the controller, which stops unauthorized access that could cause network disruptions or data breaches 🚨 "The Transport Layer Security (TLS) Protocol Version 1.3" [RFC8446] and "Enrollment over Secure Transport" [RFC7030] give guidelines on secure communication and certificate-based authentication that you can totally lean on for this 🔑
  • Controller Security: The controller's security is crucial because it's the central control point for the network elements 👑 The controller must be protected against various attacks, such as Denial of Service (DoS), Man in the Middle (MITM), and unauthorized access. Security mechanisms should include regular security audits, application of security patches, firewalls, and Intrusion Detection Systems (IDSs) / Intrusion Prevention Systems (IPSs) 🛡️
  • Data Transport Security: Security mechanisms on the controller should also protect the underlying network elements from unauthorized use of data transport resources. This includes encrypting data in transit to prevent eavesdropping and tampering, as well as ensuring data integrity and confidentiality 🔒
  • Secure Protocol Implementation: Protocols used within the GMPLS and controller frameworks must be implemented with security in mind 🧠 Known vulnerabilities should be addressed, and secure versions of protocols should be used wherever possible ⭐

Finally, robust network security often depends on Indicators of Compromise (IoCs) to detect, trace, and prevent malicious activity in networks or endpoints 👀 These are described in [RFC9424], along with the fundamentals, opportunities, operational limitations, and recommendations for IoC use. Go check it out, it's giving main character energy 🌈

11. IANA Considerations 🌸

Spoiler: this document has no IANA actions 🙈

12. References 📚

12.1. Normative References

12.2. Informative References 📚

okay so these are the informative ones, aka the "good to know" reading list. nothing here is required to implement the thing, but it's where all the backstory lives 🧚

[G.808.1]  ITU-T, "Generic protection switching - Linear trail and
           subnetwork protection", ITU-T Recommendation G.808.1, May
           2014, <https://www.itu.int/rec/T-REC-G.808.1-201405-I/en>.

[PATH-COMP]
           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-24, 13 February 2025,
           <https://datatracker.ietf.org/doc/html/draft-ietf-teas-
           yang-path-computation-24>.

[PCEP-LS]  Dhody, D., Peng, S., Lee, Y., Ceccarelli, D., Wang, A.,
           and G. S. Mishra, "PCEP extensions for Distribution of
           Link-State and TE Information", Work in Progress,
           Internet-Draft, draft-ietf-pce-pcep-ls-02, 20 October
           2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
           pce-pcep-ls-02>.

[RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
           Switching (GMPLS) Signaling Functional Description",
           RFC 3471, DOI 10.17487/RFC3471, January 2003,
           <https://www.rfc-editor.org/info/rfc3471>.

[RFC4202]  Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
           in Support of Generalized Multi-Protocol Label Switching
           (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
           <https://www.rfc-editor.org/info/rfc4202>.

[RFC4204]  Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
           DOI 10.17487/RFC4204, October 2005,
           <https://www.rfc-editor.org/info/rfc4204>.

[RFC4426]  Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
           Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
           Recovery Functional Specification", RFC 4426,
           DOI 10.17487/RFC4426, March 2006,
           <https://www.rfc-editor.org/info/rfc4426>.

[RFC5150]  Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
           "Label Switched Path Stitching with Generalized
           Multiprotocol Label Switching Traffic Engineering (GMPLS
           TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,
           <https://www.rfc-editor.org/info/rfc5150>.

[RFC5212]  Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
           M., and D. Brungard, "Requirements for GMPLS-Based Multi-
           Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
           DOI 10.17487/RFC5212, July 2008,
           <https://www.rfc-editor.org/info/rfc5212>.

[RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
           "A Backward-Recursive PCE-Based Computation (BRPC)
           Procedure to Compute Shortest Constrained Inter-Domain
           Traffic Engineering Label Switched Paths", RFC 5441,
           DOI 10.17487/RFC5441, April 2009,
           <https://www.rfc-editor.org/info/rfc5441>.

[RFC5623]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
           "Framework for PCE-Based Inter-Layer MPLS and GMPLS
           Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
           September 2009, <https://www.rfc-editor.org/info/rfc5623>.

[RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
           Sprecher, N., and S. Ueno, "Requirements of an MPLS
           Transport Profile", RFC 5654, DOI 10.17487/RFC5654,
           September 2009, <https://www.rfc-editor.org/info/rfc5654>.

[RFC7138]  Ceccarelli, D., Ed., Zhang, F., Belotti, S., Rao, R., and
           J. Drake, "Traffic Engineering Extensions to OSPF for
           GMPLS Control of Evolving G.709 Optical Transport
           Networks", RFC 7138, DOI 10.17487/RFC7138, March 2014,
           <https://www.rfc-editor.org/info/rfc7138>.

[RFC7139]  Zhang, F., Ed., Zhang, G., Belotti, S., Ceccarelli, D.,
           and K. Pithewan, "GMPLS Signaling Extensions for Control
           of Evolving G.709 Optical Transport Networks", RFC 7139,
           DOI 10.17487/RFC7139, March 2014,
           <https://www.rfc-editor.org/info/rfc7139>.

[RFC7271]  Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
           D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
           Transport Profile (MPLS-TP) Linear Protection to Match the
           Operational Expectations of Synchronous Digital Hierarchy,
           Optical Transport Network, and Ethernet Transport Network
           Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014,
           <https://www.rfc-editor.org/info/rfc7271>.

[RFC7688]  Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF
           Enhancement for Signal and Network Element Compatibility
           for Wavelength Switched Optical Networks", RFC 7688,
           DOI 10.17487/RFC7688, November 2015,
           <https://www.rfc-editor.org/info/rfc7688>.

[RFC7689]  Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
           and H. Harai, "Signaling Extensions for Wavelength
           Switched Optical Networks", RFC 7689,
           DOI 10.17487/RFC7689, November 2015,
           <https://www.rfc-editor.org/info/rfc7689>.

[RFC7792]  Zhang, F., Zhang, X., Farrel, A., Gonzalez de Dios, O.,
           and D. Ceccarelli, "RSVP-TE Signaling Extensions in
           Support of Flexi-Grid Dense Wavelength Division
           Multiplexing (DWDM) Networks", RFC 7792,
           DOI 10.17487/RFC7792, March 2016,
           <https://www.rfc-editor.org/info/rfc7792>.

[RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
           Computation Element Communication Protocol (PCEP)
           Extensions for Stateful PCE", RFC 8231,
           DOI 10.17487/RFC8231, September 2017,
           <https://www.rfc-editor.org/info/rfc8231>.

[RFC8234]  Ryoo, J., Cheung, T., van Helvoort, H., Busi, I., and G.
           Wen, "Updates to MPLS Transport Profile (MPLS-TP) Linear
           Protection in Automatic Protection Switching (APS) Mode",
           RFC 8234, DOI 10.17487/RFC8234, August 2017,
           <https://www.rfc-editor.org/info/rfc8234>.

[RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
           Computation Element Communication Protocol (PCEP)
           Extensions for PCE-Initiated LSP Setup in a Stateful PCE
           Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
           <https://www.rfc-editor.org/info/rfc8281>.

[RFC8345]  Clemm, A., Medved, J., Varga, R., Bahadur, N.,
           Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
           Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
           2018, <https://www.rfc-editor.org/info/rfc8345>.

[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, May 2018,
           <https://www.rfc-editor.org/info/rfc8363>.

[SPCE-ID]  Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
           Extension for Stateful Inter-Domain Tunnels", Work in
           Progress, Internet-Draft, draft-ietf-pce-stateful-
           interdomain-07, 3 March 2025,
           <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
           stateful-interdomain-07>.

[YANG-TE]  Saad, T., Gandhi, R., Liu, X., Beeram, V. P., and I.
           Bryskin, "A YANG Data Model for Traffic Engineering
           Tunnels, Label Switched Paths and Interfaces", Work in
           Progress, Internet-Draft, draft-ietf-teas-yang-te-37, 9
           October 2024, <https://datatracker.ietf.org/doc/html/
           draft-ietf-teas-yang-te-37>.

Acknowledgements 🫶

the authors shout out a whole crew of people who reviewed and commented on this doc, and they deserve all the flowers 💐 that's Jim Guichard, Area Director of IETF Routing Area 👑; Vishnu Pavan Beeram, Chair of TEAS WG 🌸; Jia He and Stewart Bryant, RTGDIR reviewers 🦋; Thomas Fossati, Gen-ART reviewer ⭐; Yingzhen Qu, OPSDIR reviewer 🌈; David Mandelberg, SECDIR reviewer 🔥; David Dong, IANA Services Sr. Specialist 🎀; and Éric Vyncke and Murray Kucherawy, IESG reviewers 💜. thank you all, you literally made this better 😭✨

Contributors 💖

these are the contributors 🧚

Xianlong Luo
Huawei Technologies
G1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: luoxianlong@huawei.com


Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com

Authors' Addresses 🎀

and finally, where to find the authors, bestie 💅

Haomian Zheng
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: zhenghaomian@huawei.com


Yi Lin
Huawei Technologies
H1, Huawei Xiliu Beipo Village, Songshan Lake
Dongguan
Guangdong, 523808
China
Email: yi.lin@huawei.com


Yang Zhao
China Mobile
Email: zhaoyangyjy@chinamobile.com


Yunbin Xu
CAICT
Email: xuyunbin@caict.ac.cn


Dieter Beller
Nokia
Email: Dieter.Beller@nokia.com
📦 where this page comes from