RFC 8934

PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE

📅 published October 2020, from ietf

1. Introduction ✨

Okay, title block tea first 🫖. This is RFC 8934, and the title is PCE Communication Protocol (PCEP) Extensions for Label Switched Path (LSP) Scheduling with Stateful PCE. It's a Standards Track doc from the IETF 🎀. The authors are H. Chen, Ed. (Futurewei), Y. Zhuang, Ed., Q. Wu (Huawei), and D. Ceccarelli (Ericsson). It came out in October 2020, and the ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates 🦋.

Abstract

So this doc adds a bunch of extensions to stateful PCEP so you can schedule LSPs (Label Switched Paths) 🗓️. That means computing, activating, setting up, and deleting them based on scheduled time intervals and the actual network resource usage, all in a centralized network environment, as laid out in RFC 8413 💅.

Status of This Memo

This is official paperwork energy 📜. It's an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841. For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8934 💖.

Copyright (c) 2020 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 in effect on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc 🙈. Any Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💜.

Table of Contents

   1.  Introduction
   2.  Conventions Used in This Document
     2.1.  Terminology
   3.  Motivation and Objectives
   4.  Procedures and Mechanisms
     4.1.  LSP Scheduling Overview
     4.2.  Support of LSP Scheduling
       4.2.1.  LSP Scheduling
       4.2.2.  Periodical LSP Scheduling
     4.3.  Scheduled LSP Creation
     4.4.  Scheduled LSP Modifications
     4.5.  Scheduled LSP Activation and Deletion
   5.  PCEP Objects and TLVs
     5.1.  Stateful PCE Capability TLV
     5.2.  LSP Object
       5.2.1.  SCHED-LSP-ATTRIBUTE TLV
       5.2.2.  SCHED-PD-LSP-ATTRIBUTE TLV
   6.  The PCEP Messages
     6.1.  The PCRpt Message
     6.2.  The PCUpd Message
     6.3.  The PCInitiate Message
     6.4.  The PCReq message
     6.5.  The PCRep Message
     6.6.  The PCErr Message
   7.  Security Considerations
   8.  Manageability Consideration
     8.1.  Control of Function and Policy
     8.2.  Information and Data Models
     8.3.  Liveness Detection and Monitoring
     8.4.  Verify Correct Operations
     8.5.  Requirements on Other Protocols
     8.6.  Impact on Network Operations
   9.  IANA Considerations
     9.1.  PCEP TLV Type Indicators
       9.1.1.  SCHED-PD-LSP-ATTRIBUTE TLV Opt Field
       9.1.2.  Schedule TLVs Flag Field
     9.2.  STATEFUL-PCE-CAPABILITY TLV Flag Field
     9.3.  PCEP-ERROR Object Error Types and Values
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgments
   Contributors
   Authors' Addresses

1. Introduction ✨

Okay, so PCEP, which is defined in [RFC5440], is the protocol a Path Computation Element (PCE) and a Path Computation Client (PCC) (or another PCE) use to chat about computing paths for Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) 🧚.

[RFC8231] adds extensions to PCEP for stateful control 👑. A stateful PCE doesn't just see what the network's Interior Gateway Protocol (IGP) carries. It also knows the set of active paths and their reserved resources for its computations. That extra state lets the PCE compute constrained paths while thinking about individual LSPs and how they interact, which is giving main character energy 💅.

Traditionally, bandwidth and other network resources have been handled by a Network Management System (NMS) using things like path pre-establishment. But that's not very efficient 😭. Established paths reserve resources forever, so other services can't use them even when nothing is actually flowing through them. [RFC8413] then provides a framework that describes and discusses this problem and defines an appropriate architecture for the scheduled reservation of TE resources 🦋.

Scheduled reservation of TE resources lets network operators reserve resources ahead of time, based on agreements with their customers. It also lets them share scheduling data, such as a specified start time and duration (for example, for a scheduled bulk data replication between data centers) 🍓. Bandwidth gets activated when the service is really being used, and other services can use that bandwidth whenever this service isn't 🌸. The need for scheduled LSP provisioning is mentioned in [RFC8231] and [RFC7399]. For deterministic networks [RFC8655], a scheduled LSP (or temporal LSP) can use network resources better on guaranteed links ⭐. This idea can also be applied in segment routing [RFC8402] to schedule network resources across the whole network in a centralized manner 🌈.

With all that in mind, this document defines the extensions to PCEP that stateful PCEs need in order to enable LSP scheduling. That covers path computation and LSP setup and deletion based on the actual network resource usage duration of a traffic service 🫶. A scheduled LSP is characterized by a start time and a duration. When the end of its life is reached, it's deleted so the resources are free for other LSPs, whether those are scheduled or not 💖.

2. Conventions Used in This Document ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀.

2.1. Terminology

The following terminology is reused from existing PCE documents 🧁.

This document also defines the following terminology 💅.

  • Scheduled TE LSP (or Scheduled LSP for short): An LSP with scheduling attributes that carries traffic flow demand at a start time and lasts for a certain duration (or from a start time to an end time, where the end time is the start time plus the duration). A scheduled LSP is also called a "temporal LSP". The PCE does path computation per LSP availability for the required time and duration 🗓️.
  • Scheduled LSP-DB (SLSP-DB): A database of scheduled LSPs 📚.
  • Scheduled TED: Traffic engineering database that's aware of scheduled resources for TE. The PCE generates this database from the information in the TED and the scheduled LSP-DB. It lets you know, at any time, the expected amount of available resources (discounting the possibility of failures in the future) 🔮.
  • Start time (Start-Time): This value indicates when the scheduled LSP is used, and the corresponding LSP must be set up and active. At other times (i.e., before the start time or after the start time plus duration), the LSP can be inactive, which leaves room for the resources to be used by other services 🌷.
  • Duration: This value indicates how long the LSP carries a traffic flow, and the corresponding LSP must be set up and active during that time. At the end of the duration, the LSP is torn down and removed from the database 🧹.

3. Motivation and Objectives ✨

A stateful PCE [RFC8231] can get better efficiency by using LSP scheduling, as described in the use case of [RFC8051] 🚀. To do that, the PCE has to maintain the scheduled LSPs and their associated resource usage (for example, bandwidth for a packet-switched network). It also needs the ability to trigger signaling for LSP setup and tear-down at the correct time ⏰.

Existing configuration tools can be used for LSP scheduling. But as highlighted in Section 3.1.3 of [RFC8231], and in discussions in [RFC8413], doing this as part of PCEP in a centralized manner has obvious advantages 🫶.

This document provides a set of extensions to PCEP that enable LSP scheduling for LSP creation and deletion under the stateful control of a PCE. It also responds to traffic service requests from customers, so network resources get used better 🌸.

4. Procedures and Mechanisms ✨

4.1. LSP Scheduling Overview ✨

okay so LSP scheduling lets PCEs and PCCs 💅 hand customers a scheduled LSP for their traffic at the time it actually gets used, which makes network resource utilization way more efficient 🦋 iconic.

For a stateful PCE that supports LSP scheduling, there are two types of LSP databases in this document 🫶. One is the LSP-DB defined in PCEP [RFC8231], and the other is the scheduled LSP database (SLSP-DB). The SLSP-DB records scheduled LSPs and gets used together with the TED and the LSP-DB. Also, those two types of LSP databases can live in one physical database or in two different databases. That's an implementation matter, and this document doesn't state a preference 💜.

Then there's the scheduled TED, which can be generated from the scheduled LSP-DB, LSP-DB, and TED to show network links and nodes with resource availability information for now and the future ✨. The scheduled TED MUST be maintained by all PCEs within the network environment 👑.

When it comes to PCC-initiated scheduled LSPs, a PCC MUST include that LSP's scheduling parameters (see Section 5.2.1), including the start time and duration, in a Path Computation State Report (PCRpt) message when it delegates a scheduled LSP 🎀. Since the LSP isn't signaled yet at delegation time, the LSP would be in down state. Once a stateful PCE receives the delegation of the scheduled LSP, it MUST check whether the parameters are valid. If they're valid, it SHALL check the scheduled TED for network resource availability on network nodes, compute a path for the LSP with the scheduling information, and update the PCC using the active stateful PCE techniques [RFC8231] 🔥.

The active stateful PCE can update the PCC with the path for the scheduled LSP at any time 🌸. However, the PCC should not signal the LSP over the path after receiving these messages, since the path isn't active yet. The PCC signals the LSP at the start time 🧚.

If there are multiple PCEs within a single domain, the PCEs need to synchronize their scheduling information with each other 🫶. This could be done with proprietary database-synchronization techniques or via a possible PCEP extension (see [PCE-STATE-SYNC]). The technique used to synchronize an SLSP-DB is out of scope for this document 🙈. When the scheduling information is out of synchronization among some PCEs, some scheduled LSPs may not get set up successfully 💀.

A scheduled LSP can also be initiated by a PCE itself 💖. For a PCE-initiated scheduled LSP, the stateful PCE SHALL check the network resource availability for the traffic, compute a path for the scheduled LSP, initiate the scheduled LSP at the PCC, and synchronize the scheduled LSP to other PCEs. The PCC could be notified immediately or at the start time of the scheduled LSP, depending on local policy 🌈. In the former case, the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) MUST be included in the message, whereas for the latter, the SCHED-LSP-ATTRIBUTE TLV SHOULD NOT be included. Either way, the synchronization to other PCEs MUST be done when the scheduled LSP is created 👑.

In both modes, for activation of scheduled LSPs, the PCC MUST initiate the setup of the scheduled LSP at the start time 🦋. Similarly, on the scheduled usage expiry, the PCC MUST initiate the removal of the LSP based on the flag set in the SCHED-LSP-ATTRIBUTE TLV 😭.

4.2. Support of LSP Scheduling 💜

4.2.1. LSP Scheduling ✨

For a scheduled LSP, a user configures it with an arbitrary scheduling period from time Ta to time Tb, which may be represented as [Ta, Tb] 🎀.

When an LSP is configured with the arbitrary scheduling period [Ta, Tb], a path satisfying the constraints for the LSP in that scheduling period gets computed, and the LSP along the path is set up to carry traffic from time Ta to time Tb 🔥.

4.2.2. Periodical LSP Scheduling 🌸

Besides LSP scheduling at an arbitrary time period, there's also periodical LSP scheduling 💅.

Periodical LSP scheduling means an LSP has multiple time intervals, and the LSP is set up to carry traffic in every time interval 🫶. It has a scheduling period such as [Ta, Tb], a number of repeats such as 10 (repeats 10 times), and a repeat cycle/time interval such as a week (repeats every week). The scheduling interval "[Ta, Tb] repeats n times with repeat cycle C" represents n+1 scheduling intervals as follows:

   [Ta, Tb], [Ta+C, Tb+C], [Ta+2C, Tb+2C], ..., [Ta+nC, Tb+nC]

When an LSP is configured with a scheduling interval such as "[Ta, Tb] repeats 10 times with a repeat cycle of a week" (representing 11 scheduling intervals), a path satisfying the constraints for the LSP in every interval represented by the periodical scheduling interval is computed once 🧚. Note that the path computed for one recurrence may be different from the path for another recurrence. Then the LSP along the path is set up to carry traffic in each of the scheduling intervals. If there is no path satisfying the constraints for some of the intervals, the LSP MUST NOT be set up at all. It MUST generate a PCEP Error (PCErr) with Error-Type = 29 (Path computation failure) and Error-value = 5 (Constraints could not be met for some intervals) 💀.

4.2.2.1. Elastic Time LSP Scheduling 🦋

Besides basic LSP scheduling at an arbitrary time period, there's another option: elastic time intervals 🌈. These are represented as within -P and Q, where P and Q are amounts of time such as 300 seconds. P is called the elastic range lower bound, and Q is called the elastic range upper bound.

For a simple time interval such as [Ta, Tb] with an elastic range, the elastic time interval "[Ta, Tb] within -P and Q" means a time period from (Ta+X) to (Tb+X), where -P <= X <= Q. Note that both Ta and Tb are shifted by the same X 👀. This elastic time interval is suitable when a user wants a scheduled LSP to carry traffic in the time interval [Ta, Tb] and has some flexibility about shifting that interval a little bit, such as up to P seconds earlier/left or up to Q seconds later/right 💖.

When an LSP is configured with the elastic time interval "[Ta, Tb] within -P and Q", a path is computed such that it satisfies the constraints for the LSP in the time period from (Ta+Xv) to (Tb+Xv), and an optimization is performed on Xv from -P to Q. The optimization makes [Ta+Xv, Tb+Xv] the time interval closest to the time interval [Ta, Tb] within the elastic range. The LSP along the path is set up to carry traffic in the time period from (Ta+Xv) to (Tb+Xv) 🎀.

Similarly, for a recurrent time interval with an elastic range, the elastic time interval "[Ta, Tb] repeats n times with repeat cycle C within -P and Q" represents n+1 simple elastic time intervals as follows:

      [Ta+X0, Tb+X0], [Ta+C+X1, Tb+C+X1], ..., [Ta+nC+Xn, Tb+nC+Xn],
      where -P <= Xi <= Q, i = 0, 1, 2, ..., n.

If a user wants to keep the same repeat cycle between any two adjacent time intervals, the elastic time interval "[Ta, Tb] repeats n times with repeat cycle C within -P and Q SYNC" may be used, which represents n+1 simple elastic time intervals as follows:

      [Ta+X, Tb+X], [Ta+C+X, Tb+C+X], ..., [Ta+nC+X, Tb+nC+X], where -P
      <= X <= Q.

4.2.2.2. Grace Periods ⭐

Besides the stated time scheduling, a user may want some grace periods (short for "graceful time periods") for each or some of the time intervals for the LSP 🫶. Two grace periods may be configured for a time interval. One is the grace period before the time interval, called "Grace-Before", which extends the lifetime of the LSP by an amount of time (such as 30 seconds) before the time interval. The other grace period comes after the time interval and is called "Grace-After"; it extends the lifetime of the LSP by an amount of time (such as 60 seconds) after the time interval. Note that no network resources, such as link bandwidth, will be reserved for the LSP during the grace periods 🙈.

When an LSP is configured with a simple time interval such as [Ta, Tb] with grace periods such as Grace-Before GrB and Grace-After GrA, a path is computed such that it satisfies the constraints for the LSP in the time period from Ta to Tb. The LSP along the path is set up to carry traffic in the time period from (Ta-GrB) to (Tb+GrA). During the grace periods from (Ta-GrB) to Ta and from Tb to (Tb+GrA), the LSP is up to carry traffic in best effort 🧚.

4.3. Scheduled LSP Creation 🎀

To realize PCC-initiated scheduled LSPs in a centralized network environment, a PCC MUST separate the setup of an LSP into two steps 🫶. The first step is to request/delegate and get an LSP but not signal it over the network. The second step is to signal the scheduled LSP over the Label Switching Routers (LSRs) at its start time 🔥.

For PCC-initiated scheduled LSPs, a PCC MUST delegate the scheduled LSP by sending a PCRpt message that includes its demanded resources along with the scheduling information to a stateful PCE 💅. Note that the PCC MAY use Path Computation Request (PCReq) and Path Computation Reply (PCRep) messages with scheduling information before delegating 💜.

When the stateful PCE receives the delegation via PCRpt message, it MUST compute a path for the scheduled LSP per its start time and duration, based on the network resource availability stored in the scheduled TED (see Section 4.1) ✨.

The stateful PCE will send a Path Computation Update Request (PCUpd) message with the scheduled path information and the scheduled resource information for the scheduled LSP to the PCC 🌸. The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP, and would need to synchronize the scheduling information with other PCEs in the domain.

For a PCE-initiated scheduled LSP, the stateful PCE MUST automatically compute a path for the scheduled LSP per requests from network management systems, based on the network resource availability in the scheduled TED, and send an LSP Initiate Request (PCInitiate) message with the path information to the PCC. Based on local policy, the PCInitiate message could be sent immediately to ask the PCC to create a scheduled LSP (as per this document), or the PCInitiate message could be sent at the start time to the PCC to create a normal LSP (as per [RFC8281]) 🦋.

For both PCC-initiated and PCE-initiated scheduled LSPs:

  • The stateful PCE MUST update its local scheduled LSP-DB and scheduled TED with the scheduled LSP.
  • Upon receiving the PCUpd message or PCInitiate message for the scheduled LSP from PCEs with a found path, the PCC determines that it is a scheduled path for the LSP by the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) or SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2) in the message, and does not trigger signaling for the LSP setup on LSRs immediately.
  • The stateful PCE MUST update the scheduled LSP parameters on any network events using the PCUpd message to the PCC. These changes are also synchronized to other PCEs.
  • When it is time for the LSP to be set up (i.e., at the start time), based on the value of the C flag for the scheduled TLV, either the PCC MUST trigger the LSP to be signaled, or the delegated PCE MUST send a PCUpd message to the head-end LSR providing the updated path to be signaled (with the A flag set to indicate LSP activation) 👑.

4.4. Scheduled LSP Modifications

okay so once a scheduled LSP is set up, the user is totally allowed to change its parameters 💅. That includes the requested time and the bandwidth ✨. If it's a periodic-scheduled LSP, its unused recurrences can be modified or canceled 🔁. And if a scheduled LSP is already active, its duration (the lifetime) can be reduced ⏳.

In the PCC-initiated case, the PCC MUST send the PCE a PCRpt message for the scheduled LSP with the updated parameters. It also includes the scheduled info, either in the SCHED-LSP-ATTRIBUTE TLV (see Section 5.2.1) or the SCHED-PD-LSP-ATTRIBUTE TLV (see Section 5.2.2), carried in the LSP object 📨. The PCE SHOULD take the updated resources and schedule into consideration. Then it updates the new path for the scheduled LSP to the PCC and syncs with other PCEs in the network 🌐. If the path can't be set based on the new requirements, the previous LSP is not impacted 🛡️. This MUST be conveyed by using an empty Explicit Route Object (ERO) in the PCEP messages.

In the PCE-initiated case, the stateful PCE recomputes the path based on the updated parameters and scheduled information 🧠. If it has already told the PCC about this information by sending a PCInitiate message, it SHOULD update the path and the other scheduling and resource information by sending a PCUpd message 💜.

4.5. Scheduled LSP Activation and Deletion

In the PCC-initiated case, when it's time for the LSP to be set up (that's the start time ⏰), the C flag in the scheduled TLV decides what happens next 🎬. Either the PCC MUST trigger the LSP to be signaled, or the delegated PCE MUST send a PCUpd message to the head-end LSR. That message provides the updated path to be signaled, with the A flag set to indicate LSP activation 🚀. The PCC MUST report the status of the active LSP as per the procedures in [RFC8231]. At this point, the LSP MUST be considered part of the LSP-DB 🗂️. The A flag MUST be set in the scheduled TLV to show that the LSP is active now. Once the scheduled duration expires, the C flag decides the cleanup 🧹. Either the PCC MUST trigger the LSP deletion on itself, or the delegated PCE MUST send a PCUpd message to the PCC to delete the LSP as per the procedures in [RFC8231].

In the PCE-initiated case, it depends on the local policy 📋. If the scheduled LSP is already conveyed to the PCC at the time of creation, activation and deletion are handled the same way as the PCC-initiated case, following the setting of the C flag 🔄. Otherwise, the PCE MUST send the PCInitiate message to the PCC at the start time. That creates a normal LSP without the scheduled TLV, and the LSP is removed after the duration expires, as per [RFC8281] 🌸.

5. PCEP Objects and TLVs 🎀

5.1. Stateful PCE Capability TLV

A PCC and a PCE show that they can do LSP scheduling during their PCEP session establishment phase 🤝. In an environment with multiple PCEs, the PCEs SHOULD also set up a PCEP session and show their ability to do LSP scheduling among PCEP peers 🕸️. The OPEN object in the Open message contains the STATEFUL-PCE-CAPABILITY TLV. The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231] and updated in [RFC8281] and [RFC8232]. In this document, we add a new flag bit, B (LSP-SCHEDULING-CAPABILITY), to the Flags field of the STATEFUL-PCE-CAPABILITY TLV, to show support for LSP scheduling ✅. We also add another flag bit, PD (PD-LSP-CAPABILITY), to show support for LSP periodical scheduling 🔁.

B (LSP-SCHEDULING-CAPABILITY) - 1 bit (Bit Position 22): If set to 1 by a PCC, the B flag means the PCC allows LSP scheduling. If set to 1 by a PCE, the B flag means the PCE can do LSP scheduling. The B bit MUST be set by both PCEP peers in order to support LSP scheduling for path computation 💖.

PD (PD-LSP-CAPABILITY) - 1 bit (Bit Position - 21): If set to 1 by a PCC, the PD flag means the PCC allows LSP scheduling periodically. If set to 1 by a PCE, the PD flag means the PCE can do periodical LSP scheduling. Both the PD bit and the B bit MUST be set to 1 by both PCEP peers in order to support periodical LSP scheduling for path computation 🌈. If the PD bit or B bit is 0, then the periodical LSP scheduling capability MUST be ignored 🙈.

5.2. LSP Object

The LSP object is defined in [RFC8231]. This document adds an optional SCHED-LSP-ATTRIBUTE TLV for normal LSP scheduling, and an optional SCHED-PD-LSP-ATTRIBUTE TLV for periodical LSP scheduling 🧩. The LSP object for a scheduled LSP MUST NOT include these two TLVs. Only one scheduling, either normal or periodical, is allowed for a scheduled LSP. Pick one, bestie 💅.

The presence of the SCHED-LSP-ATTRIBUTE TLV in the LSP object tells you this LSP is normal scheduling. The SCHED-PD-LSP-ATTRIBUTE TLV tells you this scheduled LSP is periodical 📅. The SCHED-LSP-ATTRIBUTE TLV MUST be present in the LSP object for each normal-scheduled LSP carried in the PCEP messages. The SCHED-PD-LSP-ATTRIBUTE TLV MUST be used in the LSP object for each periodic-scheduled LSP carried in the PCEP messages ✨.

Only one SCHED-LSP-ATTRIBUTE TLV SHOULD be present in the LSP object. If more than one SCHED-LSP-ATTRIBUTE TLV is found, the first instance is processed and the others are ignored 🙅‍♀️. The SCHED-PD-LSP-ATTRIBUTE TLV is the same as the SCHED-LSP-ATTRIBUTE TLV when it comes to its presence in the LSP object 🫶.

5.2.1. SCHED-LSP-ATTRIBUTE TLV

The SCHED-LSP-ATTRIBUTE TLV MAY be included as an optional TLV within the LSP object for LSP scheduling for the requesting traffic service 🦋.

This TLV MUST NOT be included unless both PCEP peers have set the B (LSP-SCHEDULING-CAPABILITY) bit in the STATEFUL-PCE-CAPABILITY TLV carried in the Open message to one. If the TLV is received by a peer when both peers didn't set the B bit to one, the peer MUST generate a PCEP Error (PCErr) with a PCEP-ERROR object. That error has Error-Type = 19 (Invalid Operation) and Error-value = 15 (Attempted LSP scheduling while the scheduling capability was not advertised) 🚨. That's a whole vibe check, honestly 💀.

The format of the SCHED-LSP-ATTRIBUTE TLV is shown in Figure 1 📐.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type (49)         |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flags |R|C|A|G|               Reserved (0)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Start-Time                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Duration                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   GrB / Elastic-Lower-Bound   |   GrA / Elastic-Upper-Bound   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: SCHED-LSP-ATTRIBUTE TLV

The type of the TLV is 49, and the TLV has a fixed length of 16 octets 🔢.

Here are the fields in the format 👀:

  • Flags (8 bits): The following flags are defined in this document 🚩.
    • R (1 bit): Set to 1 to indicate that the Start-Time is a relative time, which is the number of seconds from the current time. The PCEs and PCCs MUST synchronize their clocks when relative time is used. It is RECOMMENDED that the Network Time Protocol [RFC5905] be used to synchronize clocks among them ⏱️. When the transmission delay from a PCE or PCC to another PCE or PCC is too big (such as greater than 1 second), the scheduling interval represented is not accurate if the delay is not considered 😬. Set to 0 to indicate that the 32-bit Start-Time is an absolute time, which is the number of seconds since the epoch. The epoch is 1 January 1970 at 00:00 UTC. It wraps around every 2^32 seconds, which is roughly 136 years, and the next wraparound will occur in the year 2106 🗓️. The received Start-Time is considered after the wraparound if the resulting value is less than the current time. In that case, the value of the 32-bit Start-Time is considered to be the number of seconds from the time of wraparound, because the Start-Time is always a future time 🔮.
    • C (1 bit): Set to 1 to indicate that the PCC is responsible to set up and remove the scheduled LSP based on the Start-Time and Duration. The PCE holds these responsibilities when the bit is set to zero 🎀.
    • A (1 bit): Set to 1 to indicate that the scheduled LSP has been activated 🚀.
    • G (1 bit): Set to 1 to indicate that the grace period is included in the fields GrB/Elastic-Lower-Bound and GrA/Elastic-Upper-Bound. Set to 0 to indicate that the elastic range is included in the fields 🌸.
  • Reserved (24 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt 🧹.
  • Start-Time (32 bits): This value, in seconds, indicates when the scheduled LSP is used to carry traffic, and the corresponding LSP MUST be set up and activated 🏁. Note that the transmission delay SHOULD be considered when R=1 and the value of Start-Time is small ⚡.
  • Duration (32 bits): This value, in seconds, indicates the duration that the LSP carries a traffic flow, and the corresponding LSP MUST be up to carry traffic ⌛. At the expiry of this duration, the LSP MUST be torn down and deleted 💥. A value of 0 MUST NOT be used in Duration, since it does not make any sense 🙃. The value of Duration SHOULD be greater than a constant MINIMUM-DURATION seconds, where MINIMUM-DURATION is 5 🧮.

Start-Time indicates a time at or before which the scheduled LSP MUST be set up. When the R bit is set to 0, the value of Start-Time represents the number of seconds since the epoch. When the R bit is set to 1, the value of Start-Time represents the number of seconds from the current time 🕰️.

In addition, the SCHED-LSP-ATTRIBUTE TLV contains the G flag set to 1 and a nonzero Grace-Before and Grace-After in the fields GrB/Elastic-Lower-Bound and GrA/Elastic-Upper-Bound, if grace periods are configured 🫧. It includes the G flag set to 0 and a nonzero elastic range lower bound and upper bound in the fields, if there is an elastic range configured 🎢. A TLV can configure a nonzero grace period or elastic range, but it MUST NOT provide both for an LSP. Pick a lane, bestie 🛣️.

  • GrB (Grace-Before, 16 bits): The grace period time length, in seconds, before the start time ⏪.
  • GrA (Grace-After, 16 bits): The grace period time length, in seconds, after time interval [start time, start time + duration] ⏩.
  • Elastic-Lower-Bound (16 bits): The maximum amount of time, in seconds, that the time interval can shift lower/left ⬅️.
  • Elastic-Upper-Bound (16 bits): The maximum amount of time, in seconds, that the time interval can shift higher/right ➡️.

5.2.2. SCHED-PD-LSP-ATTRIBUTE TLV ✨

Okay so the periodical LSP is a special case of LSP scheduling 🔁 The traffic service happens in a whole series of repeated time intervals, kinda like a show that airs every week 🍓 That's where the SCHED-PD-LSP-ATTRIBUTE TLV comes in. It can be included as an optional TLV within the LSP object for this periodical LSP scheduling 🎀

This TLV MUST NOT be included unless both PCEP peers have set the B (LSP-SCHEDULING-CAPABILITY) bit and PD (PD-LSP-CAPABILITY) bit in the STATEFUL-PCE-CAPABILITY TLV carried in the Open message to one. If a peer receives the TLV when either bit is zero (or both bits are zero), it MUST generate a PCEP Error (PCErr) with a PCEP-ERROR object having Error-Type = 19 (Invalid Operation) and Error-value = 15 (Attempted LSP scheduling while the scheduling capability was not advertised) 😭

The format of the SCHED-PD-LSP-ATTRIBUTE TLV is shown in Figure 2 💜

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Type (50)          |         Length                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Flags|R|C|A|G| Opt   |           NR          |  Reserved (0) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Start-Time                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Duration                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Repeat-time-length                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   GrB / Elastic-Lower-Bound   |   GrA / Elastic-Upper-Bound   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: SCHED-PD-LSP-ATTRIBUTE TLV

The type of the TLV is 50, and the TLV has a fixed length of 20 octets. The description, format, and meaning of the flags (R, C, A, and G bits), Start-Time, Duration, GrB, GrA, Elastic-Lower-Bound, and Elastic-Upper-Bound fields stay the same as in the SCHED-LSP-ATTRIBUTE TLV 🫶

Here are the brand-new fields 🦋

  • Opt (4 bits): Indicates options to repeat. When a PCE receives a TLV with an unknown Opt value, it does not compute any path for the LSP. It MUST generate a PCEP Error (PCErr) with a PCEP-ERROR object having Error-Type = 4 (Not supported object) and Error-value = 4 (Unsupported parameter) 🙈
    • Opt = 1: repeat every month
    • Opt = 2: repeat every year
    • Opt = 3: repeat every Repeat-time-length

A user may configure a Repeat-time-length in time units weeks, days, hours, minutes, and/or seconds. The value represented by these units is converted to the number of seconds in the TLV. For example, repeat every 2 weeks is equivalent to repeat every Repeat-time-length = 2*7*86,400 (seconds), where 86,400 is the number of seconds per day 📅

  • NR (12 bits): The number of repeats. During each repetition, the LSP carries traffic 🌈
  • Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt 🧚
  • Repeat-time-length (32 bits): The time in seconds between the Start-Time of one repetition and the Start-Time of the next repetition ⏰

6. The PCEP Messages 💌

6.1. The PCRpt Message

The Path Computation State Report (PCRpt) message is a PCEP message sent by a PCC to a PCE to report the status of one or more LSPs, as per [RFC8231]. Each LSP State Report in a PCRpt message carries the actual LSP's path, bandwidth, operational and administrative status, etc. An LSP Status Report carried in a PCRpt message is also used in delegation or revocation of control of an LSP to/from a PCE 👑 For a scheduled LSP, a scheduled TLV MUST be carried in the LSP object, and the ERO conveys the intended path for the scheduled LSP. The scheduled LSP MUST be delegated to a PCE 💅

6.2. The PCUpd Message

The Path Computation Update Request (PCUpd) message is a PCEP message sent by a PCE to a PCC to update LSP parameters on one or more LSPs, as per [RFC8231]. Each LSP Update Request in a PCUpd message contains all LSP parameters that a PCE wants set for a given LSP 🎯 For a scheduled LSP, a scheduled TLV MUST be carried in the LSP object, and the ERO conveys the intended path for the scheduled LSP. If no path can be found, an empty ERO is used. The A bit is used in the PCUpd message to indicate the activation of the scheduled LSP if the PCE is responsible for the activation (as per the C bit) ✨

6.3. The PCInitiate Message

The LSP Initiate Request (PCInitiate) message is a PCEP message sent by a PCE to a PCC to trigger LSP instantiation or deletion, as per [RFC8281]. For a scheduled LSP, based on the local policy, the PCE MAY convey the scheduled LSP to the PCC by including a scheduled TLV in the LSP object. Alternatively, the PCE would initiate the LSP only at the start time of the scheduled LSP, as per [RFC8281], without the use of scheduled TLVs 🌸

6.4. The PCReq Message

The Path Computation Request (PCReq) message is a PCEP message sent by a PCC to a PCE to request a path computation [RFC5440], and it may contain the LSP object [RFC8231] to identify the LSP for which the path computation is requested. For a scheduled LSP, a scheduled TLV MUST be carried in the LSP object in the PCReq message to request the path computation based on the scheduled TED and LSP-DB. A PCC MAY use the PCReq message to obtain the scheduled path before delegating the LSP. The parameters of the LSP may be changed (refer to Section 4.4) 🔍

6.5. The PCRep Message

The Path Computation Reply (PCRep) message is a PCEP message sent by a PCE to a PCC in reply to a path computation request [RFC5440], and it may contain the LSP object [RFC8231] to identify the LSP for which the path is computed. A PCRep message can contain either a set of computed paths if the request can be satisfied or a negative reply if not. A negative reply may indicate the reason why no path could be found 🙃 For a scheduled LSP, a scheduled TLV MUST be carried in the LSP object in the PCRep message to indicate the path computation based on the scheduled TED and LSP-DB. A PCC and PCE MAY use PCReq and PCRep messages to obtain the scheduled path before delegating the LSP 🫧

6.6. The PCErr Message

The PCEP Error (PCErr) message is a PCEP message, as described in [RFC5440], for error reporting. This document defines new error values for several error types to cover failures specific to scheduling, and it reuses the applicable error types and error values of [RFC5440] and [RFC8231] wherever appropriate 🚨

The PCEP extensions for scheduling MUST NOT be used if one or both of the PCEP speakers have not set the corresponding bits in the STATEFUL-PCE-CAPABILITY TLV in their respective Open messages to one. If the PCEP speaker supports the extensions of this specification but did not advertise this capability, then upon receipt of an LSP object with the scheduled TLV, it MUST generate a PCEP Error (PCErr) with Error-Type = 19 (Invalid Operation) and Error-value = 15 (Attempted LSP scheduling while the scheduling capability was not advertised), and it SHOULD ignore the TLV. As per Section 7.1 of [RFC5440], a legacy PCEP implementation that does not understand this specification would consider a scheduled TLV unknown and ignore it 💀

If the PCC decides that the scheduling parameters proposed in the PCUpd/PCInitiate message are unacceptable, it MUST report this error by including the LSP-ERROR-CODE TLV (Section 7.3.3 of [RFC8231]) with LSP Error-value = 4 (Unacceptable parameters) in the LSP object (with the scheduled TLV) in the PCRpt message to the PCE 🙅‍♀️

The scheduled TLV MUST be included in the LSP object for the scheduled LSPs. If the TLV is missing, the receiving PCEP speaker MUST send a PCErr message with Error-Type = 6 (Mandatory Object missing) and Error-value = 16 (Scheduled TLV missing) 🎀

7. Security Considerations 🔐

This document defines the LSP-SCHEDULING-CAPABILITY TLV and SCHED-LSP-ATTRIBUTE TLV, and the security considerations discussed in [RFC5440], [RFC8231], and [RFC8281] continue to apply. In some deployments, the scheduling information could provide details about the network operations that could be deemed extra sensitive. Additionally, snooping of PCEP messages with such data, or using PCEP messages for network reconnaissance, may give an attacker sensitive information about the operations of the network 👀

A single PCEP message can now instruct a PCC to set up and tear down an LSP every second for a number of times. That single message could have a significant effect on the network 😱 Thus, such deployments SHOULD employ suitable PCEP security mechanisms like the TCP Authentication Option (TCP-AO), which is discussed in [RFC5925] and [RFC8253]. Note that [RFC8253] is considered a security enhancement and is thus much better suited for sensitive information 🛡️ PCCs may also need to apply some form of rate limit to the processing of scheduled LSPs 🚦

8. Manageability Consideration 🛠️

8.1. Control of Function and Policy

The LSP scheduling feature MUST be controlled per tunnel by the active stateful PCE. The values for parameters like start time and duration SHOULD be configurable by customer applications and based on the local policy at the PCE. The suggested default values for start time and duration are one day (in seconds) from the current time and one year (in seconds), respectively. One day has 86,400 seconds. One year has 31,536,000 seconds 📆

When configuring the parameters for time, a user SHOULD consider leap years and leap seconds. If a scheduled LSP has a time interval containing a leap year, the duration of the LSP is 366 days plus the rest of the interval 🥰

8.2. Information and Data Models

An implementation SHOULD allow the operator to view the information about each scheduled LSP defined in this document. To serve this purpose, the PCEP YANG module [PCE-PCEP-YANG] could be extended 📊

8.3. Liveness Detection and Monitoring

Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440] 💓

8.4. Verify Correct Operations

Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440]. An implementation SHOULD allow a user to view information, including the status of a scheduled LSP, through a Command Line Interface (CLI) tool. In addition, it SHOULD check and handle the cases where there is a significant time correction or a clock skew between PCC and PCE 🕰️

8.5. Requirements on Other Protocols

Mechanisms defined in this document do not imply any new requirements on other protocols 🌷

8.6. Impact on Network Operations

Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440] 🌿

9. IANA Considerations ✨

9.1. PCEP TLV Type Indicators 💖

okay so IANA keeps the "PCEP TLV Type Indicators" subregistry, and it lives inside the "Path Computation Element Protocol (PCEP) Numbers" registry 🎀 this doc is where the new PCEP TLVs get their numbers, and IANA handed out two spots:

           +=======+========================+===============+
           | Value | Description            | Reference     |
           +=======+========================+===============+
           | 49    | SCHED-LSP-ATTRIBUTE    | This document |
           +-------+------------------------+---------------+
           | 50    | SCHED-PD-LSP-ATTRIBUTE | This document |
           +-------+------------------------+---------------+

             Table 1: Additions to PCEP TLV Type Indicators
                              Subregistry

9.1.1. SCHED-PD-LSP-ATTRIBUTE TLV Opt Field 🦋

IANA is making a brand new subregistry called "SCHED-PD-LSP-ATTRIBUTE TLV Opt Field" inside the "Path Computation Element Protocol (PCEP) Numbers" registry, and IANA will be the one keeping it up to date 💅 the starting values are right here, and any new values get handed out through Standards Action [RFC8126] 🌸

       +=======+=================================+===============+
       | Value | Description                     | Reference     |
       +=======+=================================+===============+
       | 0     | Reserved                        |               |
       +-------+---------------------------------+---------------+
       | 1     | REPEAT-EVERY-MONTH              | This document |
       +-------+---------------------------------+---------------+
       | 2     | REPEAT-EVERY-YEAR               | This document |
       +-------+---------------------------------+---------------+
       | 3     | REPEAT-EVERY-REPEAT-TIME-LENGTH | This document |
       +-------+---------------------------------+---------------+
       | 4-14  | Unassigned                      |               |
       +-------+---------------------------------+---------------+
       | 15    | Reserved                        |               |
       +-------+---------------------------------+---------------+

            Table 2: New SCHED-PD-LSP-ATTRIBUTE TLV Opt Field
                               Subregistry

9.1.2. Schedule TLVs Flag Field 🌈

IANA made a new subregistry called "Schedule TLVs Flag Field" inside the same PCEP Numbers registry 🧚 new values come in through Standards Action [RFC8126]. Each bit should be tracked with the following qualities:

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

The following values are defined in this document:

         +=====+===============================+===============+
         | Bit | Description                   | Reference     |
         +=====+===============================+===============+
         | 0-3 | Unassigned                    |               |
         +-----+-------------------------------+---------------+
         | 4   | Relative Time (R-bit)         | This document |
         +-----+-------------------------------+---------------+
         | 5   | PCC Responsible (C-bit)       | This document |
         +-----+-------------------------------+---------------+
         | 6   | LSP Activated (A-bit)         | This document |
         +-----+-------------------------------+---------------+
         | 7   | Grace Period Included (G-bit) | This document |
         +-----+-------------------------------+---------------+

            Table 3: New Schedule TLVs Flag Field Subregistry

9.2. STATEFUL-PCE-CAPABILITY TLV Flag Field 👑

this doc adds new bits to the Flags field in the STATEFUL-PCE-CAPABILITY TLV, which sits in the OPEN object ✨ IANA keeps the "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry inside the "Path Computation Element Protocol (PCEP) Numbers" registry, and these are the new additions:

       +=====+===================================+===============+
       | Bit | Description                       | Reference     |
       +=====+===================================+===============+
       | 22  | LSP-SCHEDULING-CAPABILITY (B-bit) | This document |
       +-----+-----------------------------------+---------------+
       | 21  | PD-LSP-CAPABILITY (PD-bit)        | This document |
       +-----+-----------------------------------+---------------+

          Table 4: Additions to STATEFUL-PCE-CAPABILITY TLV Flag
                            Field Subregistry

9.3. PCEP-ERROR Object Error Types and Values 🔥

IANA added some new error types to the existing error values inside the "PCEP-ERROR Object Error Types and Values" subregistry, which lives in the "Path Computation Element Protocol (PCEP) Numbers" registry 🙈

     +============+================+===============================+
     | Error-Type | Meaning        | Error-value                   |
     +============+================+===============================+
     | 6          | Mandatory      | 16: Scheduled TLV missing     |
     |            | Object missing |                               |
     +------------+----------------+-------------------------------+
     | 19         | Invalid        | 15: Attempted LSP scheduling  |
     |            | Operation      | while the scheduling          |
     |            |                | capability was not advertised |
     +------------+----------------+-------------------------------+
     | 29         | Path           | 5: Constraints could not be   |
     |            | computation    | met for some intervals        |
     |            | failure        |                               |
     +------------+----------------+-------------------------------+

         Table 5: Additions to PCEP-ERROR Object Error Types and
                            Values Subregistry

10. References 📚

10.1. Normative References 🫶

these are the must-read ones, bestie 💜

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

   [RFC8232]  Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
              and D. Dhody, "Optimizations of Label Switched Path State
              Synchronization Procedures for a Stateful PCE", RFC 8232,
              DOI 10.17487/RFC8232, September 2017,
              <https://www.rfc-editor.org/info/rfc8232>.

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

   [RFC8413]  Zhuang, Y., Wu, Q., Chen, H., and A. Farrel, "Framework
              for Scheduled Use of Resources", RFC 8413,
              DOI 10.17487/RFC8413, July 2018,
              <https://www.rfc-editor.org/info/rfc8413>.

10.2. Informative References 🌸

these are the extra-credit reads 🍓

   [PCE-PCEP-YANG]
              Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura,
              "A YANG Data Model for Path Computation Element
              Communications Protocol (PCEP)", Work in Progress,
              Internet-Draft, draft-ietf-pce-pcep-yang-15, 31 October
              2020,
              <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-15>.

   [PCE-STATE-SYNC]
              Litkowski, S., Sivabalan, S., Li, C., and H. Zheng, "Inter
              Stateful Path Computation Element (PCE) Communication
              Procedures.", Work in Progress, Internet-Draft, draft-
              litkowski-pce-state-sync-08, 12 July 2020,
              <https://tools.ietf.org/html/draft-litkowski-pce-state-
              sync-08>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC7399]  Farrel, A. and D. King, "Unanswered Questions in the Path
              Computation Element Architecture", RFC 7399,
              DOI 10.17487/RFC7399, October 2014,
              <https://www.rfc-editor.org/info/rfc7399>.

   [RFC8051]  Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
              Stateful Path Computation Element (PCE)", RFC 8051,
              DOI 10.17487/RFC8051, January 2017,
              <https://www.rfc-editor.org/info/rfc8051>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

Acknowledgments 💜

   The authors of this document would also like to thank Rafal Szarecki,
   Adrian Farrel, and Cyril Margaria for the review and comments.

Contributors 🎀

the people who helped build this, no cap 🫶

   Dhruv Dhody
   Huawei
   Divyashree Techno Park, Whitefield
   Bangalore 560066
   Karnataka
   India

   Email: dhruv.ietf@gmail.com


   Xufeng Liu
   Ericsson
   United States of America

   Email: xliu@kuatrotech.com


   Mehmet Toy
   Verizon
   United States of America

   Email: mehmet.toy@verizon.com


   Vic Liu
   China Mobile
   No.32 Xuanwumen West Street, Xicheng District
   Beijing
   100053
   China

   Email: liu.cmri@gmail.com


   Lei Liu
   Fujitsu
   United States of America

   Email: lliu@us.fujitsu.com


   Khuzema Pithewan
   Infinera

   Email: kpithewan@infinera.com


   Zitao Wang
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing
   Jiangsu, 210012
   China

   Email: wangzitao@huawei.com


   Xian Zhang
   Huawei Technologies
   Research Area F3-1B
   Huawei Industrial Base
   Shenzhen
   518129
   China

   Email: zhang.xian@huawei.com

Authors' Addresses ✨

okay bestie, meet the squad that wrote this whole thing 🫶 Huaimo Chen and Yan Zhuang are the editors, and Qin Wu and Daniele Ceccarelli are the other brilliant minds behind it 💅 here's where you can find them 🎀

Huaimo Chen (editor)
Futurewei
Boston, MA
United States of America

Email: huaimo.chen@futurewei.com
Yan Zhuang (editor)
Huawei
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China

Email: zhuangyan.zhuang@huawei.com
Qin Wu
Huawei
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China

Email: bill.wu@huawei.com
Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy

Email: daniele.ceccarelli@ericsson.com

that's a wrap on the document 🦋 these people did the research, the writing, and the late-night editing so we can all build better PCE stuff 🌈 go slay your next implementation 👑✨

📦 where this page comes from