RFC 8413

Framework for Scheduled Use of Resources

📅 published July 2018, from ietf

Framework for Scheduled Use of Resources ✨

Hiii bestie 💖 okay so this one is an Informational doc 🎀, which means it's not a Standards Track spec, it's just here to share the vibes and the architecture thinking. Written by Y. Zhuang, Q. Wu, H. Chen (all from Huawei 🧚) and A. Farrel (Juniper Networks 🌸), and it dropped in July 2018 📅. It's RFC 8413, and it doesn't obsolete or update anything, so it's a fresh start 🦋 It's also all about Time-Scheduled (TS) reservation of TE resources, which is basically booking network resources in advance like a restaurant reservation 🍓

Title block vibes: a clean, brand new framework doc 💅

Abstract

okay so the whole point here is giving TE Label Switched Paths a booking system 💅 Time-Scheduled reservation of TE resources lets operators guarantee services for customers and use network capacity more efficiently at any moment, including stuff planned for the future 🔥 This doc gives a framework that describes and discusses the architecture for doing scheduled reservations of TE resources. It does not define any specific protocols or protocol extensions to make this happen 🫶

Status of This Memo

not gonna lie, this section is super official 🙈 This document is not an Internet Standards Track specification 💀 It's published for informational purposes, so it's more of a "here's the thinking" than a "you must do this" 🌈

It's a product of the IETF, it represents the consensus of the IETF community, and it got public review and was approved for publication by the IESG ✨ Just because the IESG approved something doesn't mean it's a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious 💜

For the current status, errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8413 🎀

Copyright (c) 2018 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 were on the publication date 📜 Read those carefully because they describe your rights and restrictions. Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License 💅

Table of Contents

Here's the map of the whole doc, in order 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
  2.1.  Provisioning TE-LSPs and TE Resources . . . . . . . . . .   4
  2.2.  Selecting the Path of an LSP  . . . . . . . . . . . . . .   4
  2.3.  Planning Future LSPs  . . . . . . . . . . . . . . . . . .   5
  2.4.  Looking at Future Demands on TE Resources . . . . . . . .   6
    2.4.1.  Interaction between Time-Scheduled and Ad Hoc
            Reservations  . . . . . . . . . . . . . . . . . . . .   6
  2.5.  Requisite State Information . . . . . . . . . . . . . . .   7
3.  Architectural Concepts  . . . . . . . . . . . . . . . . . . .   8
  3.1.  Where is Scheduling State Held? . . . . . . . . . . . . .   8
  3.2.  What State is Held? . . . . . . . . . . . . . . . . . . .  10
  3.3.  Enforcement of Operator Policy  . . . . . . . . . . . . .  12
4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .  13
  4.1.  Service Request . . . . . . . . . . . . . . . . . . . . .  13
    4.1.1.  Reoptimization After TED Updates  . . . . . . . . . .  14
  4.2.  Initialization and Recovery . . . . . . . . . . . . . . .  15
  4.3.  Synchronization Between PCEs  . . . . . . . . . . . . . .  15
5.  Multi-domain Considerations . . . . . . . . . . . . . . . . .  16
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
8.  Informative References  . . . . . . . . . . . . . . . . . . .  19
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  21
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1. Introduction 🦋

okay so Traffic Engineering Label Switched Paths (TE-LSPs) are connection-oriented tunnels in packet and non-packet networks [RFC3209] [RFC3945] 🧚 They can reserve network resources for the traffic they carry, which gives some service delivery guarantees and lets an operator plan resource use across the whole network 🔥

In some tech, like wavelength switched optical networks, the resource is literally the same thing as the label switched on the LSP path 💀 So you can't set up an LSP that carries traffic without also assigning a physical resource to it. In other tech, like packet switched networks, the resources assigned to an LSP measure how much capacity of a link is dedicated to the traffic on that LSP 🌈

No matter the tech, network planning means picking paths for LSPs through the network so there's no contention for resources 💅 LSP establishment is setting up an LSP and reserving resources in the network ✨ Network optimization or reoptimization is moving LSPs around so the unreserved resources are more useful for future LSPs, while the established LSPs still meet their objectives 🎀

Sometimes you already know an LSP will be needed at a specific time in the future 🌸 You could compute a path using the LSPs that exist now and the resources available now, but that gives zero certainty the resources will still be there when it's time to set up the new LSP 🙈 Setting up the LSP early would guarantee the resources, but that's wasteful, since the network could be doing something else with them in the meantime 😭

It's also possible to know an LSP won't be needed after some future time and will get torn down then, which releases its resources 💜 That info is super helpful when you're planning where a future LSP goes 🫶

So Time-Scheduled (TS) reservation of TE resources can give resource booking for TE-LSPs, better guaranteeing services for customers and improving efficiency of resource usage into the future 🦋 This doc describes the problem and discusses the architecture for scheduled reservation of TE resources. It does not describe any specific protocols or protocol extensions needed to realize this service 🌈

2. Problem Statement 🔍

2.1. Provisioning TE-LSPs and TE Resources

okay so TE-LSPs in existing networks get provisioned in a bunch of different ways 🎀 They may be set up using RSVP-TE as a signaling protocol [RFC3209] [RFC3473] 💖 Or they could be established by direct control of network elements, like in the Software-Defined Networking (SDN) paradigm ✨ They could also be provisioned using the PCE Communication Protocol (PCEP) [RFC5440] as a control protocol to talk to the network elements 🧚

TE resources get reserved at the point of use 🌸 So the resources (wavelengths, timeslots, bandwidth, etc.) are reserved for use on a specific link and tracked by the Label Switching Routers (LSRs) at the endpoints of that link 🫶 Those LSRs learn which resources to reserve during the LSP setup process 💅

You can change how the TE resources get used by changing the parameters of the LSP that uses them, and you can release them by tearing down the LSP 🦋

Resources already reserved for one LSP may get preempted for another LSP 😭 If RSVP-TE signaling is in use, a holding priority and a preemption priority decide which LSPs can preempt the resources in use by other LSPs 🔥 If direct (central) control is in use, the controller makes preemption decisions 👑 Either way, operator policy is a huge part of preemption, because there's always a trade between disrupting existing LSPs and enabling new ones 💀

2.2. Selecting the Path of an LSP

so TE-LSPs could figure out their paths hop by hop, using the shortest path toward the destination to route the signaling messages [RFC3209] 🙈 But in practice nobody really does this, because it doesn't look far enough ahead to check the resources you need are actually available 💀 Instead, the full path of an LSP is usually computed ahead of time, either by the head-end LSR of a signaled LSP or by Path Computation Element (PCE) functionality that lives on a dedicated server or inside network management software [RFC4655] 🎀

Full-path computation is used so an end-to-end view of the network's available resources can pick the best shot at setting up a viable LSP that meets the service requirements 🔥 Even so, two LSPs being set up at the same time can still compete for scarce resources, so one or both could fail 😭 To avoid that, you can use a centralized PCE that knows about the LSP setup requests currently in progress 👑

Path selection may make allowance for preemption, as described in Section 2.1 💅 That means when picking a path, you might choose one that causes an existing LSP to get preempted 🌈 The trade-off between picking a less optimal path, not picking any path at all, and preempting an existing LSP must be subject to operator policy ✨

Path computation is driven by "objective functions," which define what criteria need to be met when the LSP is placed [RFC4655] 🧚 These can be about the LSP itself (like the shortest path to the destination) or about the network state after the LSP is set up (like maximized residual link bandwidth) 💖 The application asking for the LSP may request the objective functions, and the computation engine may filter and enhance them according to operator policy 🦋

Part 1 of 5 done bestie, more coming 💜🎀

2.3. Planning Future LSPs ✨

Okay so, LSPs can be set up "on demand" 💅 whenever the requester decides it needs a new one. In that case, the path gets computed the way we went over in Section 2.2, no cap.

But lowkey, a lot of the time the requester already knows an LSP will be needed at some specific time in the future 🗓️. Like, there might be a huge traffic flow starting at a well-known time, maybe for a database synchronization or for content getting swapped between streaming sites 🎬. The requester might also know how long the LSP is needed before it can be torn down ⏳.

Here's the thing though 🙈. Those requests for future LSPs could get stored in a central database (like one held by a Network Management System (NMS)). Then, when the time comes for each LSP to be set up, the NMS asks the PCE to compute a path and then requests that the LSP be provisioned. The problem is that this has a bunch of drawbacks, because nobody can know ahead of time whether the LSP will actually be deliverable. The resources it needs might already be used by other LSPs in the network 😭. So when the requester asks for the future LSP, the NMS can only make a best-effort guarantee that it'll be set up at the desired time. Not iconic.

So the better move 🦋 is to service the requests for future LSPs right away! The paths can be computed ahead of time and turned into reservations of network resources during specific windows in the future. Basically, even though the path is computed and the resources are reserved now, the LSP isn't actually established in the network until its scheduled time ⏰.

There's also operator policy to think about 👑. Stuff like 1) the amount of capacity available for scheduling future reservations, 2) the operator's preference for the measures used on scheduled resources during rapid changes in traffic demand events, or 3) a complex (multiple nodes/links) failure event, so the network doesn't get destabilized 🌪️. We'll talk more about operator policy in Section 3.3.

2.4. Looking at Future Demands on TE Resources 🔮

Path computation, as described in Section 2.2, is super smart about the network resources that are available right now 🧠. It tries to place LSPs so future LSPs have the best chance of fitting in too. BUT it can't handle every single scenario 💀. It's really easy to build a situation where LSPs placed one at a time end up blocking future LSPs, even though if you'd known about all of the LSPs upfront, they could've all been set up just fine 😩.

So if we could know in advance which LSPs were going to be requested, we could plan for them and make sure the resources are there. Honestly, that approach also lets the network make a commitment to a service user that an LSP will be set up and available at a specific time 🫶.

A reservation service can be achieved by tracking the current use of network resources and also keeping a future view of resource usage ✨. We call this Time-Scheduled TE (TS-TE) resource reservation 🎀.

2.4.1. Interaction between Time-Scheduled and Ad Hoc Reservations 🌈

There's gonna be a mix of resource uses in a network, obviously 💁‍♀️. For example, normal unplanned LSPs might get requested right alongside TS-TE LSPs. When an unplanned LSP is requested, nothing was prepared in advance to arrange resource availability, so the LSP can be placed no better than it would be without TS-TE. However, the new LSP can be placed while considering the future demands of TS-TE LSPs that were already requested 🧩. And hey, the unplanned LSP has no known end time, so any network planning has to assume it'll eat up resources forever 😤.

2.5. Requisite State Information 📦

To get TS-TE resource reservation working, the use of resources on the path needs to be scheduled 🗓️. The scheduling state is what tells you when resources are reserved and when they're free to use 💜.

A simple information model for one piece of the scheduling state looks like this:

      {
        link id;
        resource id or reserved capacity;
        reservation start time;
        reservation end time
      }

The resource being scheduled could be link capacity, physical resources on a link, buffers on an interface, etc. It could even include more advanced stuff like CPU utilization and memory availability at nodes within the network 🧠⚡. The resource-related info might also include the maximal unreserved bandwidth of the link over a time interval 📊. The whole point is to book (reserve) a percentage of the residual (unreserved) bandwidth of the link 🍓. This could be used, for example, to reserve bandwidth for a particular class of traffic (such as IP) that doesn't have a provisioned LSP 💖.

For any one resource, there could be multiple pieces of scheduling state, and for any one link, the timing windows might overlap 🌀.

There are multiple ways to realize this information model, and different ways to store the data too 🗂️. The resource state could be expressed as a start time and an end time (like shown above), or as a start time and a duration ⏱️. Multiple reservation periods, possibly of different lengths, may need to be recorded for each resource. And the current state of network reservation could be kept separate from the scheduled usage, or everything could be merged into a single TS database 🧃.

An application may make a reservation request for immediate resource usage, or to book resources for future use so it can maximize the chance of services being delivered and avoid contention for resources later 🎯. A single reservation request may book resources for multiple periods, and it might request a reservation that repeats on a regular cycle 🔁.

A computation engine (that's a PCE) may use the scheduling state information to help optimize the use of resources into the future and reduce contention or blocking when the resources are actually needed 🧮.

Also, it's necessary to store the information about future LSPs separately from the specific resource scheduling 📝. This info is held so the LSPs can be instantiated when they're due and use the paths/resources that were computed for them. It also provides correlation with the TS-TE resource reservations, so it's clear why resources were reserved 🔗. That's what allows preemption and handling the release of reserved resources if a future LSP gets canceled 🚫. See Section 3.2 for further discussion of the distinction between scheduled resource state and scheduled LSP state 💅.

Network performance factors (such as maximum link utilization and the residual capacity of the network), with respect to supporting scheduled reservations, need to be supported and are subject to operator policy 🌸.

3. Architectural Concepts 🏛️

This section examines several important architectural concepts. The goal is to understand the design decisions reached in this document for achieving TS-TE in a scalable and robust manner 💜🦋.

3.1. Where is Scheduling State Held? 🧚

okay so, the scheduling state from Section 2.5 has to live somewhere, and there are really only two places that make sense 👀

  • in the network nodes where the resources exist, or;
  • in a central scheduling controller where the allocation decisions get made 💅

The first option makes policing resource allocation easier 🫶 Lots of points in the network can request immediate or scheduled LSPs with their resource reservation, and all of those requests can be correlated right where the resources get allocated. BUT it has some scaling and technical problems, bestie 😭

  • The big one is that every network node has to keep the full time-based state for all of its resources. In a busy network with a high arrival rate of new LSPs and a low hold time for each LSP, that's a LOT of state. And network nodes usually come with minimal spare memory 💀
  • The Path Computation Element (PCE) [RFC4655] needs a database of the available links and nodes in the network (plus the TE properties of those links) so it can do path computation 🗺️ That database is the Traffic Engineering Database (TED), and it's usually filled from info each network node advertises in the IGP, or exported using BGP Link State (BGP-LS) [RFC7752]. To compute a path for a future LSP, the PCE has to fill the TED with ALL of the future resource availability. If that info lives on the network nodes, it also has to be advertised in the IGP. That could be a seriously big scaling issue for the IGP and the nodes, because everything gets held at every node and has to be refreshed by the IGP on a regular basis 😩
  • When a normal node restarts, it can recover its resource reservation state from the forwarding hardware, from Non-Volatile Random-Access Memory (NVRAM), or from adjacent nodes through the signaling protocol [RFC5063]. If the scheduling state lives on the nodes, it has to be recovered after a node restarts too. The forwarding hardware can't help with that, since the reservation was never made there. Getting it from NVRAM could need extra pricey NVRAM, and getting it from neighbours might mean ALL the adjacent nodes also hold the scheduling state so they can reinstall it on the restarting node. That's potentially complex processing with scaling and cost implications 🥴

Now flip it: if the scheduling state is held centrally, it's super easy to grab right where it's needed 🎀 The PCE can use the state to plan future LSPs and then update that stored info with the scheduled reservations for those future LSPs. This approach has its own issues though:

  • If there are multiple controllers, they have to sync their stored scheduling state as they each plan future LSPs, and they need a way to resolve resource contention. This is relatively simple, and it's helped by the fact that there's plenty of processing time to replan future LSPs when contention happens 🫠
  • If other sources of immediate LSPs are allowed (like other controllers, or head-end LSRs doing their own thing), then the changes in resource availability from setting up or tearing down those LSPs have to show up in the TED (through the IGP, the same way it already normally works), and they might affect planned future LSPs. That impact can be handled by replanning future LSPs or by LSP preemption 🔄
  • If the scheduling state is held centrally at a PCE, it has to be held and restored after a system restart. That's relatively easy on a central server that can access non-volatile storage. The PCE could also sync the scheduling state with other PCEs after a restart. See Section 4.2 for details 📚
  • Of course, a centralized system has to store info about ALL the resources in the network. In a busy network with a high arrival rate and low hold times, that's a lot of state again. It's multiplied by the size of the network, measured by both the number of links and nodes AND the number of trackable resources on each link or at each node 😵 This might get eased by the central server being dedicated hardware, but collecting the info from the network in a timely way is still a problem, especially when there's potentially a huge amount to collect and it's changing fast. That last challenge only gets solved if the central server has full control over booking resources and setting up new LSPs, so the info coming from the network just confirms what the central server already expected ✨

So, weighing all these trade-offs, the architectural conclusion is that the scheduling state should be held centrally at the point of use and NOT in the network devices. Iconic decision, honestly 👑

3.2. What State is Held? 🦋

As we already covered, the PCE needs access to an enhanced, time-based TED. It stores the Traffic Engineering (TE) info, like bandwidth, for every link across a series of time intervals. There are a few ways to store the TE info in the TED. For example, say the unreserved bandwidth at a priority level for a link is Bj in a time interval from time Tj to Tk (k = j+1), where j = 0, 1, 2, .... 🌈

     Bandwidth
      ^
      |                                    B3
      |          B1                        ___________
      |          __________
      |B0                                             B4
      |__________          B2                         _________
      |                    ________________
      |
     -+-------------------------------------------------------> Time
      |T0        T1        T2              T3         T4


          Figure 1: A Plot of Bandwidth Usage against Time

The unreserved bandwidth for the link can be represented and stored in the TED as [T0, B0], [T1, B1], [T2, B2], [T3, B3], ... as shown in Figure 1 📊

But here's the thing, bestie: service requests for future LSPs are known in terms of the LSPs whose paths are computed and for which resources are scheduled 🧠 For example, if the requester of a future LSP decides to cancel or modify the request, the PCE has to be able to map that back to the resources that were reserved. When the LSP (or the request for the LSP with a number of time intervals) is canceled, the PCE must release the resources reserved on each of the links along the LSP's path in every time interval from the TED. If the bandwidth reserved for the LSP on a link was B from time T2 to T3, and the unreserved bandwidth on that link was B2 from T2 to T3, then B gets added back to the link for the T2-to-T3 interval, and the unreserved bandwidth there will be B2 + B 🔁

This suggests the PCE needs an LSP Database (LSP-DB) [RFC8231] that holds info not just about LSPs that are active in the network, but also the planned ones 🗂️ For each time interval that applies to the LSP, the info stored in the LSP-DB for an LSP includes: the time interval, the paths computed for the LSP satisfying the constraints in that time interval, and the resources (like bandwidth) reserved for the LSP in that time interval. See also Section 2.3 💜

How the TED and LSP-DB get stored, both for dynamic use and for recovery after a failure or restart, is an implementation choice 🛠️ It's worth noting that all of the info in the scheduled TED can be recovered from the active network state and from the scheduled LSP-DB 🫶

3.3. Enforcement of Operator Policy 👮‍♀️

Computation requests for LSPs get serviced according to operator policy 📋 For example, a PCE may refuse a computation request because the application making it doesn't have sufficient permissions, or because servicing it might push a specific resource usage over a given threshold 🚫

The preemption and holding priorities of any particular computation request may also be subject to the operator's policies. The request could be rejected if it doesn't conform to the operator's policies, or (possibly more likely) the priorities could be set or overwritten according to those policies 🎯

Also, the Objective Functions (OFs) of a computation request (like maximizing residual bandwidth) are subject to operator policies too. It's highly likely that an application doesn't get to choose the OFs. Instead, they're selected by the PCE or management system, subject to operator policies and knowledge of the application 🧚

None of these statements is new for scheduled resources. They apply to stateless, stateful, passive, and active PCEs, and they keep applying to scheduling of resources 💅

An operator may choose to configure special behaviour for a PCE that handles resource scheduling. For example, an operator might want only a certain percentage of any resource to be bookable 🍓 And an operator might want the preemption of booked resources to be an inverse function of how far in the future the resources are first needed ⏳

It's a general assumption about the architecture described in Section 4 that a PCE is under the operational control of the operator that owns the resources the PCE manipulates. So the operator may configure any amount of (potentially complex) policy at the PCE. That configuration would also include policy points around reoptimization of existing and planned LSPs when the current and future (planned) resource availability changes 🌸

The granularity of the timing window offered to an application depends on the operator's policy, as well as the implementation in the PCE, and it's what defines the operator's service offerings 🎀 Different granularities and different lengths of prebooking may be offered to different applications 🫧

4. Architecture Overview 🏗️

The architectural considerations and conclusions from the previous section lead to the architecture in this section, illustrated in Figure 2. The interfaces and interactions shown in the figure and labeled (a) through (f) are described in Section 4.1 👀

       -------------------
      | Service Requester |
       -------------------
                  ^
                 a|
                  v
               -------   b   --------
              |       |<--->| LSP-DB |
              |       |      --------
              |  PCE  |
              |       |  c    -----
              |       |<---->| TED |
               -------        -----
               ^     ^
               |     |
              d|     |e
               |     |
         ------+-----+--------------------
               |     |          Network
               |     --------
               |    | Router |
               |     --------
               v
             -----          -----
            | LSR |<------>| LSR |
             -----     f    -----

   Figure 2: Reference Architecture for Scheduled Use of Resources

4.1. Service Request ✨

Okay so, as Figure 2 shows, some component in the network requests a service 💅. That could be an application, an NMS, an LSR, or literally any component that qualifies as a Path Computation Client (PCC) 🫶. The figure calls it the "Service Requester," and it sends a request to the PCE for an LSP to be set up at some time (either now or in the future) 🕰️. The request, marked on Figure 2 by arrow (a), packs in all the LSP parameters the requester wants to supply, like priority, bandwidth, start time, and end time. Also, the requester might be the LSR shown in the figure, or it might be a totally separate system, no cap 🦋.

The PCE logs the LSP request in its LSP-DB (b) and uses info from its TED (c) to compute a path that satisfies the constraints (like bandwidth) for the LSP in the time interval from the start time to the end time 🎀. It updates the future resource availability in the TED so later path computations can account for the scheduled resource usage 📅. Then it stores the path for the LSP into the LSP-DB (b) 💾.

When it's time (i.e., at the start time) for the LSP to be set up, the PCE sends a PCEP Initiate request to the head-end LSR (d). That request gives the path to be signaled, plus other parameters like the bandwidth of the LSP ✨.

As the LSP gets signaled between LSRs (f), the network's resource usage gets updated and distributed using the IGP 📡. This info is shared with the PCE either through the IGP or using BGP-LS (e), and then the PCE updates its TED (c) to match 🌈.

After the LSP is set up, the head-end LSR sends a PCEP LSP State Report (PCRpt) message to the PCE (d). The report contains the resources for the LSP, such as bandwidth usage. The PCE updates the status of the LSP in the LSP-DB according to the report 💜.

When an LSP is no longer required (either because the Service Requester has canceled the request or because the LSP's scheduled lifetime has expired), the PCE can remove it 👋. If the LSP is currently active, the PCE tells the head-end LSR to tear it down (d), and the network resource usage gets updated by the IGP and advertised back to the PCE through the IGP or BGP-LS (e). Once the LSP is no longer active, the PCE can remove it from the LSP-DB (b) 🫧.

4.1.1. Reoptimization After TED Updates

When the TED is updated as indicated in Section 4.1, the PCE may, depending on operator policy (so as to minimize network perturbations), reoptimize the LSPs it has computed paths for 🔄. These LSPs might already be provisioned, in which case the PCE issues PCEP Update request messages for the LSPs that should be adjusted. Or the LSPs being reoptimized might be scheduled LSPs that haven't been provisioned yet, in which case reoptimization means updating the store of scheduled LSPs and resources 🗂️.

In every case, reoptimization is all about taking account of the resource usage and availability in the network, and computing paths for the current and future LSPs that best satisfy the objectives of those LSPs while keeping the network as clear as possible to support further LSPs ✨. Since reoptimization can perturb established LSPs, it is subject to operator oversight and policy. Frequent changes affect the network's stability, so the extent and impact of any reoptimization needs to be subject to operator policy 🙈.

Also, the status of the reserved resources (alarms) can enhance the computation and planning for future LSPs, and may influence repair and reoptimization 🚨. Control of recalculations based on failures, and notifications to the operator, is also subject to policy.

See Section 3.3 for further discussion of operator policy 💅.

4.2. Initialization and Recovery

When a PCE in the architecture shown in Figure 2 is initialized, it must learn the state from the network, from its stored databases, and potentially from other PCEs in the network 🧚.

Step one is getting an accurate view of the topology and resource availability in the network. This would normally mean reading the state straight from the network via the IGP or BGP-LS (e), but it might also include receiving a copy of the TED from another PCE. Quick note: a TED stored from a previous instantiation of the PCE is unlikely to be valid 💀.

Next, the PCE must construct a time-based TED to show scheduled resource usage. How it does this is implementation specific, and this document does not dictate any particular mechanism 🤷. It may recover a time-based TED previously saved to non-volatile storage, or it may reconstruct the time-based TED from information retrieved from the LSP-DB previously saved to non-volatile storage. If there is more than one PCE active in the network, the recovering PCE will need to synchronize the LSP-DB and time-based TED with other PCEs (see Section 4.3) 🔁.

Note that the stored LSP-DB needs to include the intended state and actual state of the LSPs, so that when a PCE recovers, it is able to determine what actions are necessary 🎀.

4.3. Synchronization Between PCEs

If more than one PCE that supports scheduling is active in the network, it is important to achieve some consistency between the scheduled TED and scheduled LSP-DB held by the PCEs 👯.

[RFC7399] answers various questions around synchronization between the PCEs. It's worth noting that the time-based "scheduled" information adds another dimension to the synchronization issue between PCEs. Also, a deployment may use a primary PCE with other PCEs as backups, where a backup PCE can take over only if the primary PCE fails. Alternatively, the PCEs may share the load at all times. Which synchronization technique you pick depends largely on how the PCEs are deployed in the network 🧠.

One option for making sure multiple PCEs use the same scheduled information is to simply have the PCEs driven from the same shared database. It's likely to be inefficient, though, and interoperation between multiple implementations will be harder 😬.

Another option is for each PCE to be responsible for its own scheduled database, and to use some distributed database synchronization mechanism to keep the information consistent. Depending on the implementation, this could be efficient, but interoperation between heterogeneous implementations is still hard 🫠.

A further approach is to use PCEP messages to synchronize the scheduled state between PCEs. This works well if the number of PCEs that support scheduling is small, but as the number increases, considerable message exchange needs to happen to keep the scheduled databases synchronized 📨. Future solutions could also use some synchronization optimization techniques for efficiency. Another variation would be to request information from other PCEs for a particular time slice, but this might have an impact on the optimization algorithm ⏰.

5. Multi-domain Considerations

Multi-domain path computation usually needs some form of cooperation between PCEs, and each one is responsible for working out a segment of the end-to-end path in the domain it computes for 🗺️. When computing a scheduled path, resources need to be booked in all of the domains that the path will cross, so they're available when the LSP is finally signaled ✈️.

Per-domain path computation [RFC5152] isn't an appropriate mechanism when a scheduled LSP is being computed, because the computation requests at downstream PCEs are only triggered by signaling 🙅. However, a similar mechanism could work where cooperating PCEs exchange Path Computation Request (PCReq) messages for a scheduled LSP, as shown in Figure 3. Here, the service requester asks for a scheduled LSP that spans two domains (a). PCE1 computes a path across Domain 1, reserves the resources, and also asks PCE2 to compute and reserve in Domain 2 (b). PCE2 may return a full path, or it could return a path key [RFC5520]. When it's time for LSP setup, PCE1 triggers the head-end LSR (c), and the LSP is signaled (d). If a path key is used, the entry LSR in Domain 2 will consult PCE2 for the path expansion (e) before completing signaling (f) 🧩.

          -------------------
         | Service Requester |
          -------------------
             ^
            a|
             v
          ------         b          ------
         |      |<---------------->|      |
         | PCE1 |                  | PCE2 |
         |      |                  |      |
          ------                    ------
            ^                         ^
            |                         |
           c|                        e|
            |                         |
        ----+-----------------    ----+-----------------
       |    |        Domain 1 |  |    |        Domain 2 |
       |    v                 |  |    v                 |
       |  -----   d   -----   |  |   -----   f   -----  |
       | | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
       |  -----       -----   |  |   -----       -----  |
        ----------------------    ----------------------

Figure 3: Per-Domain Path Computation for Scheduled LSPs 📊

Another mechanism for PCE cooperation in multi-domain LSP setup is Backward Recursive PCE-Based Computation (BRPC) [RFC5441]. This approach relies on the downstream domain to supply a variety of potential paths to the upstream domain. Although BRPC can arrive at a more optimal end-to-end path than per-domain path computation, it isn't well suited to LSP scheduling, because the downstream PCE would need to reserve resources on all of the potential paths and then release those that the upstream PCE announced it did not plan to use 😵.

Finally, we should consider hierarchical PCE (H-PCE) [RFC6805]. This mode of operation is similar to that shown in Figure 3, but a parent PCE is used to coordinate the requests to the child PCEs. That gives better visibility of the end-to-end path and better coordination of the resource booking 👑. The sequenced flow of control is shown in Figure 4.

          -------------------
         | Service Requester |
          -------------------
             ^
            a|
             v
          --------
         |        |
         | Parent |
         |  PCE   |
         |        |
          --------
             ^ ^         b
            b| |_______________________
             |                         |
             v                         v
          ------                    ------
         |      |                  |      |
         | PCE1 |                  | PCE2 |
         |      |                  |      |
          ------                    ------
            ^                         ^
            |                         |
           c|                        e|
            |                         |
        ----+-----------------    ----+-----------------
       |    |        Domain 1 |  |    |        Domain 2 |
       |    v                 |  |    v                 |
       |  -----   d   -----   |  |   -----   f   -----  |
       | | LSR |<--->| LSR |<-+--+->| LSR |<--->| LSR | |
       |  -----       -----   |  |   -----       -----  |
        ----------------------    ----------------------

Figure 4: Hierarchical PCE for Path Computation for Scheduled LSPs 🌸

6. Security Considerations 🔒✨

Okay so the protocol side of scheduled resources is literally the same as "on demand" LSP computation and setup, so nothing new there 💅. Securing PCEP is covered in [RFC5440], and the work to extend that security lives in [RFC8253]. The path key mechanism in [RFC5520] can also be used to level up privacy and security 🦋.

Similarly, there's no change to the security implications for signaling scheduled LSPs. You can read about the security of the signaling protocols that would be used in [RFC5920] 🫶.

BUT ngl, scheduled LSPs make the attack surface for a PCE-enabled TE system bigger 😭. They give attackers a larger (logically infinite!) window to start or plan an attack. If bogus scheduled LSPs can be requested and entered into the LSP-DB, then a huge number of LSPs could launch and block significant network resources 💀.

Bestie, this is the big one: scheduling requests need to be controlled by operator policy, and extra authorization needs to be applied before anyone gets access to LSP scheduling. 🚨

Diagnostic tools also need to be provided so people can inspect the LSP-DB and spot attacks 🔍🌈.

7. IANA Considerations 🌸

This document has no IANA actions. Nothing for IANA to do here, bestie 💜.

8. Informative References 📚

Acknowledgements 🫶

This work has benefited from discussions about resource scheduling over the years, and I'm so grateful for them 🌈. In particular, the DRAGON project [DRAGON] and [AUTOBW] both bring approaches to auto-bandwidth services in GMPLS networks 🔥.

Mehmet Toy, Lei Liu, and Khuzema Pithewan contributed to an earlier version of [FRAMEWORK-TTS]. Huge thanks to the authors of that Temporal Tunnel Services document, whose material helped us think through this one 🧚.

Thanks to Michael Scharf and Daniele Ceccarelli for useful comments on this work 💖.

Jonathan Hardwick provided a helpful Routing Directorate review 👑.

Deborah Brungard, Mirja Kuehlewind, and Benjamin Kaduk suggested many changes during their Area Director reviews 🙈.

Contributors 💜

The following person contributed to discussions that led to the development of this document:

  • Dhruv Dhody
  • Email: dhruv.dhody@huawei.com

Authors' Addresses 🦋

  • Yan Zhuang
    • Huawei, 101 Software Avenue, Yuhua District, Nanjing, Jiangsu 210012, China
    • Email: zhuangyan.zhuang@huawei.com
  • Qin Wu
    • Huawei, 101 Software Avenue, Yuhua District, Nanjing, Jiangsu 210012, China
    • Email: bill.wu@huawei.com
  • Huaimo Chen
    • Huawei, Boston, MA, United States of America
    • Email: huaimo.chen@huawei.com
  • Adrian Farrel
    • Juniper Networks
    • Email: afarrel@juniper.net
📦 where this page comes from