RFC 8051
Applicability of a Stateful Path Computation Element (PCE)
Okay bestie, RFC 8051 is here 💖 It's called Applicability of a Stateful Path Computation Element (PCE) 🎀. It's Informational, so it's not a Standards Track spec. It was published in January 2017 and the ISSN is 2070-1721 ✨. The authors are X. Zhang, Ed. from Huawei Technologies and I. Minei, Ed. from Google, Inc. 🫶 It doesn't list anything it obsoletes or updates, so no drama there 🧚.
Abstract ✨
okay so a stateful PCE keeps track of LSP stuff (characteristics and resource usage) across the whole network 🦋. That lets it do traffic-engineering calculations for the PCCs it works with 💅. This doc walks through general deployment vibes, how useful it is, the challenges, and the limits, using a bunch of use cases 🌸. The PCEP extensions you need for stateful PCE usage are in separate docs 📚.
Status of This Memo ✨
This doc is not an Internet Standards Track spec. It's published for info purposes only 💜.
It's a product of the IETF 🌈. It reflects what the IETF community agrees on, got public review, and was approved for publication by the IESG 👑. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for that 🔥.
For the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8051 🍓.
Copyright Notice ✨
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date 📜. Read these carefully, because they're your rights and restrictions for this doc 🫶. 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 come without warranty as described in the Simplified BSD License 💅.
Table of Contents 🌸
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Application Scenarios . . . . . . . . . . . . . . . . . . . . 5
3.1. Optimization of LSP Placement . . . . . . . . . . . . . . 5
3.1.1. Throughput Maximization and Bin Packing . . . . . . . 6
3.1.2. Deadlock . . . . . . . . . . . . . . . . . . . . . . 7
3.1.3. Minimum Perturbation . . . . . . . . . . . . . . . . 9
3.1.4. Predictability . . . . . . . . . . . . . . . . . . . 10
3.2. Auto-Bandwidth Adjustment . . . . . . . . . . . . . . . . 11
3.3. Bandwidth Scheduling . . . . . . . . . . . . . . . . . . 12
3.4. Recovery . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.1. Protection . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. Restoration . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. SRLG Diversity . . . . . . . . . . . . . . . . . . . 15
3.5. Maintenance of Virtual Network Topology (VNT) . . . . . . 15
3.6. LSP Reoptimization . . . . . . . . . . . . . . . . . . . 16
3.7. Resource Defragmentation . . . . . . . . . . . . . . . . 17
3.8. Point-to-Multipoint Applications . . . . . . . . . . . . 17
3.9. Impairment-Aware Routing and Wavelength Assignment
(IA-RWA) . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 19
4.1. Multi-PCE Deployments . . . . . . . . . . . . . . . . . . 19
4.2. LSP State Synchronization . . . . . . . . . . . . . . . . 19
4.3. PCE Survivability . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 241. Introduction 💖
okay so [RFC4655] lays out the PCE-based architecture for computing MPLS and GMPLS Traffic Engineering Label Switched Paths (TE LSPs) 🦋. To do that constrained computation, a PCE stores the network topology (TE links and nodes) and the resource info (TE attributes) in its TE Database (TED) 🧚. [RFC5440] describes the Path Computation Element Protocol (PCEP), which is how a Path Computation Client (PCC) and a PCE talk to each other, or how two PCEs talk, to make TE LSPs happen 🫶.
As per [RFC4655], a PCE can be stateful or stateless 💅. A stateful PCE keeps two sets of info for path computation ✨. The first is the Traffic Engineering Database (TED), with the topology and resource state of the network 🌈. A stateful PCE can get this info the same way a stateless PCE does (see [RFC4655]) 💜. The second is the LSP State Database (LSP-DB), where the PCE stores attributes of all active LSPs in the network 🔥. Those attributes include their paths through the network, bandwidth/resource usage, switching types, and LSP constraints 🍓. This state lets the PCE compute constrained paths while looking at individual LSPs and how they depend on each other 👑. But it needs reliable state synchronization between the PCE and the network, between the PCE and the PCCs, and between cooperating PCEs 😭. That can mean a lot of control-plane overhead and a big pile of state data to maintain, as explained in [RFC4655] 💀.
This doc shows how a stateful PCE can solve different problems for MPLS-TE and GMPLS networks, and what benefits it brings to those deployments 🎀. Stateless PCEs might also solve some of these use cases, and those alternatives get mentioned where it makes sense, just for completeness 🌸.
2. Terminology ✨
This doc uses the following terms defined in [RFC5440]: PCC, PCE, and PCEP peer 🦋.
This doc defines these terms too 🧚:
- Stateful PCE: a PCE that can access not only the network state, but also the set of active paths and their reserved resources for its computations 💖. It might also keep info about LSPs under construction, to cut down on churn and resource contention 💅. That extra state lets the PCE compute constrained paths while considering individual LSPs and how they interact 🔥. This needs reliable state synchronization between the PCE and the network, the PCE and the PCC, and between cooperating PCEs 🫶.
- Passive Stateful PCE: a PCE that uses LSP state info it learned from PCCs to optimize path computations 🌈. It doesn't actively update LSP state 🙈. A PCC keeps synchronization with the PCE 💜.
- Active Stateful PCE: a PCE that may issue recommendations to the network 👑. For example, an Active Stateful PCE may use the Delegation mechanism to update LSP parameters in those PCCs that delegate control over their LSPs to the PCE ✨.
- Delegation: an operation that grants a PCE temporary rights to modify a subset of LSP parameters on one or more LSPs of a PCC 🎀. LSPs get delegated from a PCC to a PCE, and they're called "delegated" LSPs 🦋. The PCC that owns the PCE state for the LSP has the right to delegate it 💅. An LSP is owned by a single PCC at any given point in time 🧚. For intra-domain LSPs, this PCC should be the LSP head end 🍓.
- LSP State Database: info about all LSPs and their attributes 📚.
- PCE Initiation: assuming LSP delegation is granted by default, a PCE can issue recommendations to the network 🌸.
- Minimum Cut Set: the minimum set of links for a specific source-destination pair that, when removed from the network, leaves a specific source completely isolated from a specific destination 💖. The summed capacity of these links equals the maximum capacity from the source to the destination, by the max-flow min-cut theorem 🔥.
3. Application Scenarios 🌈
In the sections below, several use cases get described, showing scenarios that benefit from deploying a stateful PCE 💅.
3.1. Optimization of LSP Placement ✨
The use cases below need visibility into global LSP states in PCE path computations 👑. They also need PCE control over the sequence and timing of changes to LSP path characteristics, within and across PCEP sessions 🫶. The reference topologies for the use cases later in this section are shown in Figures 1 and 2 🦋.
Some of the use cases below focus on MPLS-TE deployments but may also apply to GMPLS 💜. Unless otherwise cited, the use cases assume that all LSPs listed exist at the same LSP priority 🎀.
The main benefit in these cases comes from moving away from an asynchronous PCC-driven mode of operation, toward a model that allows central control over LSP computations and maintenance 🧚. It focuses specifically on the active stateful PCE model of operation 🔥.
+-----+
| A |
+-----+
\
+-----+ +-----+
| C |----------------------| E |
+-----+ +-----+
/ \ +-----+ /
+-----+ +-----| D |-----+
| B | +-----+
+-----+Figure 1: Reference Topology 1
+-----+ +-----+ +-----+
| A | | B | | C |
+--+--+ +--+--+ +--+--+
| | |
| | |
+--+--+ +--+--+ +--+--+
| E +--------+ F +--------+ G |
+-----+ +-----+ +-----+Figure 2: Reference Topology 2
3.1.1. Throughput Maximization and Bin Packing ✨
okay so bestie, because LSP attribute changes in [RFC5440] are driven by Path Computation Request (PCReq) messages under control of a PCC's local timers, the order that resource reservations show up in the network gets randomized 🎲. Add a stateless PCE that has zero global LSP state visibility and you can end up with suboptimal throughput in a given topology. we'll see that in the example below 👀
Reference Topology 2 in Figure 2 and Tables 1 and 2 show an example where throughput is at 50% of optimal because the PCEs can't see the whole picture and the PCCs aren't synchronized 💀. In this scenario, a decision has to be made about whether to route any portion of the E-G demand, since any demand routed for this source and destination will decrease system throughput.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-E | 1 | 10 |
| B-F | 1 | 10 |
| C-G | 1 | 10 |
| E-F | 1 | 10 |
| F-G | 1 | 10 |
+------+--------+----------+Table 1: Link Parameters for Throughput Use Case
+------+-----+-----+-----+--------+----------+-------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+-------+
| 1 | 1 | E | G | 10 | Yes | E-F-G |
| 2 | 2 | A | B | 10 | No | --- |
| 3 | 1 | F | C | 10 | No | --- |
+------+-----+-----+-----+--------+----------+-------+Table 2: Throughput Use Case Demand Time Series
In a lot of cases, throughput maximization turns into a bin-packing problem 📦. Bin packing is NP-hard, but a bunch of common heuristics that run in polynomial time can still give big throughput wins over random reservation event distribution 🙌. That's especially true when you're going over links that are members of the minimum cut set for a large subset of source destination pairs.
Tables 3 and 4 show a simple use case using Reference Topology 1 in Figure 1, where LSP state visibility and control of reservation order across PCCs would lead to a huge boost in total throughput 📈.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+Table 3: Link Parameters for Bin-Packing Use Case
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 5 | Yes | A-C-D-E |
| 2 | 2 | B | E | 10 | No | --- |
+------+-----+-----+-----+--------+----------+---------+Table 4: Bin-Packing Use Case Demand Time Series
3.1.2. Deadlock 🔒
this section is about cross-LSP impact when things are running in degraded mode 😬. Most existing RSVP-TE implementations won't tear down established LSPs when the bandwidth increase procedure in [RFC3209] fails. [RFC3209] basically implies this is correct, and operators often like it, because either a) the destination prefixes can't be reached any way other than MPLS, or b) tearing down would cause significant packet loss as demand gets shifted to other LSPs in the overlay mesh.
also, there are barely any implementations offering dynamic ingress admission control (policing the traffic volume mapped onto an LSP) at the Label Edge Router (LER) 🙅♀️. Per-LSP ingress admission control isn't necessarily desirable operationally, because a) you have to over-provision tunnels a lot to avoid nasty effects from stacked transport and flow control systems (for example, for tunnels that get dynamically resized based on current traffic), and b) there's currently no efficient, commonly available northbound interface for dynamically configuring per-LSP ingress admission control.
Lack of ingress admission control combined with the behavior in [RFC3209] can leave LSPs operating out of profile for long stretches 😭. Those out-of-profile LSPs will probably be running in a degraded state and experiencing traffic loss. Worse, those LSPs end up sharing common network interfaces with other LSPs that are operating within their bandwidth reservations, so they'll mess with the in-profile LSPs, even when there's unused capacity elsewhere in the network 🥲. And this behavior causes information loss in the TED about the actual available bandwidth on the links used by the out-of-profile LSPs, since the reservations on those links no longer reflect the capacity actually used 📉.
Reference Topology 1 in Figure 1 and Tables 5 and 6 show a use case that demonstrates this 🎬. Two LSPs, LSP 1 and LSP 2, are signaled with demand 2 and routed along paths A-C-D-E and B-C-D-E, respectively. Later on, the demand of LSP 1 goes up to 20. At that demand, the LSP can't be resignaled. However, the existing LSP won't be torn down. Without ingress policing, traffic on LSP 1 will degrade traffic on LSP 2 (because of oversubscription on the links C-D and D-E), plus you get information loss in the TED about the real network state 🫠.
The problem could be easily improved with global visibility of the LSP state, coupled with PCC-external demand measurements and placement of the two LSPs on disjoint links 🧠. Note that even though the demand of 20 for LSP 1 could never be satisfied in this topology, isolation from the ill effects of that (unsatisfiable) increased demand could still be achieved ✨.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 5 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+Table 5: Link Parameters for the 'Degraded Operation' Example
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 2 | Yes | A-C-D-E |
| 2 | 2 | B | E | 2 | Yes | B-C-D-E |
| 3 | 1 | A | E | 20 | No | --- |
+------+-----+-----+-----+--------+----------+---------+Table 6: 'Degraded Operation' Demand Time Series
3.1.3. Minimum Perturbation 🌀
because of both the lack of visibility into global LSP state and the lack of control over event ordering across PCE sessions, a stateless PCE can accidentally introduce unnecessary perturbations into the network 😤. Tables 7 and 8 show an example of an unnecessary network perturbation using Reference Topology 1 in Figure 1. Here, an unimportant LSP (high LSP priority value) called LSP1 gets set up along the shortest path first. At time 2, which is assumed to be pretty close to time 1, a second, more important LSP (lower LSP-priority value) called LSP2 gets established, preempting LSP1 and potentially causing traffic loss 💔. LSP1 then gets reestablished on the longer A-C-E path.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 10 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+Table 7: Link Parameters for the 'Minimum-Perturbation' Example
+------+-----+-----+-----+--------+----------+----------+---------+
| Time | LSP | Src | Dst | Demand | LSP Prio | Routable | Path |
+------+-----+-----+-----+--------+----------+----------+---------+
| 1 | 1 | A | E | 7 | 7 | Yes | A-C-D-E |
| 2 | 2 | B | E | 7 | 0 | Yes | B-C-D-E |
| 3 | 1 | A | E | 7 | 7 | Yes | A-C-E |
+------+-----+-----+-----+--------+----------+----------+---------+Table 8: 'Minimum-Perturbation' LSP and Demand Time Series
a stateful PCE can help here by computing both routes at the same time 🧩. The advantages of using a stateful PCE over exploiting a stateless PCE via Global Concurrent Optimization (GCO) are threefold 💅. First, it can handle concurrent path computation from different PCCs. Second, it cuts down control-plane overhead, since the stateful PCE already has the route information of the affected LSPs. Thirdly, the stateful PCE can use the LSP-DB to further optimize the placement of LSPs 👑. This makes sure the more important LSP gets placed along the shortest path, so you avoid the setup and then subsequent preemption of the lower priority LSP. Similarly, when a new higher priority LSP needs to preempt existing lower priority LSP(s), a stateful PCE can work out the minimum number of lower priority LSPs to reroute using the Make-Before-Break (MBB) mechanism, without disrupting any service, and then set up the higher priority LSP 🦋.
3.1.4. Predictability ✨
okay so when reservation events get randomized because nobody controls the order they happen in across PCE sessions, LSP routing becomes super unpredictable 😭. An offline system that uses a consistent optimization method will give results you can predict, either within the boundary of forecast error (if reservations are over-provisioned by reasonable margins) or within the variability of the signal and the forecast error (if you apply some hysteresis to cut down on churn) 💅. Predictable results are seriously valuable 🔥 because they let you simulate the network and test it reliably under all kinds of scenarios, especially failure modes and planned maintenance, where you want predictable path characteristics while everything is competing for network resources 🫶.
Reference Topology 1 and Tables 9, 10, and 11 show how event ordering affects predictability of LSP routing 👀.
+------+--------+----------+
| Link | Metric | Capacity |
+------+--------+----------+
| A-C | 1 | 10 |
| B-C | 1 | 10 |
| C-E | 1 | 10 |
| C-D | 1 | 10 |
| D-E | 1 | 10 |
+------+--------+----------+
Table 9: Link Parameters for the 'Predictability' Example
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 1 | A | E | 7 | Yes | A-C-E |
| 2 | 2 | B | E | 7 | Yes | B-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
Table 10: 'Predictability' LSP and Demand Time Series 1
+------+-----+-----+-----+--------+----------+---------+
| Time | LSP | Src | Dst | Demand | Routable | Path |
+------+-----+-----+-----+--------+----------+---------+
| 1 | 2 | B | E | 7 | Yes | B-C-E |
| 2 | 1 | A | E | 7 | Yes | A-C-D-E |
+------+-----+-----+-----+--------+----------+---------+
Table 11: 'Predictability' LSP and Demand Time Series 2As the example shows, both LSPs get routed in both cases, but they end up on really different paths 🙈. That's a real problem if you're trying to simulate the network reliably. An active stateful PCE can fix this by controlling LSP ordering 👑. Based on triggers like a failure or an optimization trigger, the PCE can order the computations and path setup in a deterministic way ✨.
3.2. Auto-Bandwidth Adjustment
The bandwidth needs of LSPs often change over time, so they need resizing 🌈. In most implementations out there today, the head-end node handles this by monitoring the actual bandwidth usage and triggering a recomputation and resignaling once a threshold is reached. This is called "auto-bandwidth adjustment" 💖. The head-end node either recomputes the path locally, or it asks a PCE for a recomputation by sending a PCReq message. In that second case, the PCE computes a new path and sends back its new route suggestion. Once the PCC gets the reply, it resignals the LSP in Shared-Explicit (SE) mode along the newly computed path 🦋. With a stateless PCE, the head-end node has to pass along the currently used bandwidth and the route information in path computation request messages 📨. Here the head-end node is the one driving the LSP resizing based on local information. The difference between a stateless and a passive stateful PCE comes down to how well the LSP placement gets optimized, which we already covered in the previous section 🧚.
Now a more interesting smart bandwidth adjustment case is when an external entity makes the LSP resizing decision. That entity has access to extra info like historical trending data, application-specific info about expected demands, policy information, and knowledge of the actual desired flow volumes 🍓. In that case, an active stateful PCE has the edge, both in computation (since it knows about all the LSPs in the domain) and in its ability to trigger bandwidth modification of the LSP 💅.
3.3. Bandwidth Scheduling
Bandwidth scheduling lets network operators reserve resources in advance based on agreements with their customers 📅. It also lets them transmit data with a specified starting time and duration, like a scheduled bulk data replication between data centers 🫧.
Traditionally, this could be supported by Network Management System (NMS) operations, using path pre-establishment and activation at the agreed starting time. But that isn't very efficient 😤, because the established paths can't be used by other services even when nobody is actually using them. It can also be done with GMPLS protocol extensions that carry the related request information (for example, the starting time and duration) across the network. The catch is that this inevitably makes the signaling and routing process more complicated 🌀.
A passive stateful PCE can support this application more efficiently 🎀, since it takes some of the processing burden off the network elements. This requires the PCE to maintain the scheduled LSPs and their associated resource usage, and it requires head-ends to be able to trigger signaling for LSP setup and deletion at the right time ⏰. This approach needs coarse time synchronization between PCEs and PCCs. With PCE initiation capability, a PCE can trigger the setup and deletion of scheduled requests in a centralized way, without changing how head-ends already behave, by telling the PCCs to set up or tear down the paths 🦋.
3.4. Recovery
The recovery use cases in the following sections show how a stateful PCE can simplify computing recovery path(s) 🛟. Two characteristics of a stateful PCE do the heavy lifting here: 1) it uses information stored in the LSP-DB to determine shared protection resources, and 2) it performs computations with knowledge of all LSPs in a domain 🧠.
3.4.1. Protection
If a PCC can say in a request whether the computation is for a working path or for protection, and it can report the resource as a working or protection path, then the following text applies 🛡️. A PCC can send multiple requests to the PCE asking for two LSPs, then use them as working and backup paths separately. Either way, the resources tied to backup paths can be shared by different LSPs to boost overall network efficiency. Examples are m:n protection or pre-configured shared mesh recovery techniques, as specified in [RFC4427] 🌸. If resource sharing is supported for LSP protection, the information about existing LSPs is required so you don't allocate shared protection resources to two LSPs that might fail together, which would cause protection contention issues 😬. A stateless PCE can handle this use case if the PCC passes this information as a constraint in the path computation request. A passive stateful PCE can handle it more easily by using the information stored in its LSP-DB. And an active stateful PCE can help with (re)optimizing protection resource sharing, as well as with LSP maintenance operations that have less impact on protection resources 👑.
+----+
|PCE |
+----+
+------+ +------+ +------+
| A +----------+ B +----------+ C |
+--+---+ +---+--+ +---+--+
| | |
| +---------+ |
| | |
| +--+---+ +------+ |
+-----+ E +----------+ D +-----+
+------+ +------+
Figure 3: Reference Topology 3Take the network in Figure 3 as an example 🗺️. Say there's an LSP1 with working path LSP1_working following A->E, and backup path LSP1_backup following A->B->E. Then a request comes in asking for a working and backup path pair to be computed for LSP2 from B to E. If the PCE decides LSP2_working follows B->A->E, then LSP2_backup shouldn't share the same protection resource with LSP1, because LSP2 shares part of its resource (specifically A->E) with LSP1. In other words, these two LSPs are in the same shared risk group 🚨. There's no such constraint if B->C->D->E gets chosen for LSP2_working ✨.
If a stateless PCE is used, the head node B needs to know about the existence of LSPs that share the route of LSP2_working, and about the details of their protection resources. B must pass this information to the PCE as a constraint so it can request a path with diversity 🙏. Another option is that a stateless PCE may be able to compute paths diversified by SRLG (Shared Risk Link Group), but only if the TED is extended to include the SRLG information protected by a given backup resource. The downside is that this comes at the expense of high complexity in routing 😵💫. A stateful PCE, on the other hand, can get the LSP information by itself, given the LSP identifier(s), and then find SRLG-diversified protection paths for both LSPs 💜. It does this by comparing LSP resource usage using the LSP-DB that the stateful PCE can access 🦋.
3.4.2. Restoration ✨
okay so bestie, picture a fiber cut 😭✂️. Like, one snip and suddenly a bunch of LSPs go down at the same time. The source nodes of those affected LSPs get told about the failure by whichever nodes spotted it first, and then they all rush off to ask a PCE for new routes 🏃♀️💨. To make it smart, the source node can send a PCReq message that has the Exclude Route Object (XRO) with the Fail (F) bit set, plus the Record Route Object (RRO) showing the current route info, as specified in [RFC5521]. The XRO with F set is basically the move that lets the LSP reuse the resources it's already holding 🧠💖.
okay now the tea ☕. If you've got a stateless PCE, it's gonna answer each rerouting request separately if they show up at different times. Lowkey messy 🙈, because that can end up being suboptimal resource usage. Even worse 💀, it might block some of the rerouting requests that arrive later, just because it ran out of resources for them. Not it. 🚫
If you've got a passive stateful PCE instead, the whole thing gets so much simpler 🥹✨. The PCCs reporting the failures can just send LSP identifiers instead of all the detailed info, and the PCE goes "oh I got this" and looks up the relevant LSP info in the LSP-DB 🗂️. It can even recompute the affected LSPs concurrently and reuse part of the existing LSP's resources once it hears about the failed link identifier from the first request 🔥. This works because the passive stateful PCE can check which other LSPs are affected by the failed link and what their routes look like, just by checking its LSP-DB 👑. The result is better performance, like better resource usage, and a much lower chance of blocking new rerouting requests that pop up because of that same link failure 💅.
And if the goal is to avoid resource contention during a big burst of LSP rerouting requests, a stateful PCE can hold onto the resource usage info for under-construction LSPs for a given amount of time and exclude that from being used for a forthcoming LSP's request 🦋. This way, resources don't get double-booked, so resource contention and computation crankbacks get way less likely 🌸🫶.
3.4.3. SRLG Diversity 🎀
okay so an alternative way to get efficient resilience is to keep SRLG disjointness between LSPs 💜, no matter whether those LSPs share the same source and destination nodes or not. You can get this at provisioning time if all the routes are requested together and computed in one synchronized go with the SRLG disjointness constraint 🧩. But if the LSPs need to get provisioned at different times, the PCC can tell the path computation which set of SRLGs to avoid using the Exclude Route Object [RFC5521] 🙅♀️. The catch is that for this to actually work, the entity asking the PCE for routes has to keep up-to-date SRLG info for all the LSPs it needs to stay disjoint from 😭. A stateless PCE can still compute an SRLG-disjoint path by checking the TED and cutting out any links that share the SRLG values listed in the PCReq message the PCC sent ✂️.
A passive stateful PCE keeps the updated SRLG info for established LSPs in one centralized spot 🧠✨. So the PCC can say "keep me disjoint from these already-established LSPs" by only giving the LSP identifiers 🪪. Same deal with a passive stateful PCE for other constraints too, like link, node, or path segment disjointness 💖.
3.5. Maintenance of Virtual Network Topology (VNT) 🌈
okay so in Multi-Layer Networks (MLN), a Virtual Network Topology (VNT) [RFC5212] is made of one or more TE LSPs in the lower layer, and those give TE links to the upper layer 🪜. [RFC5623] proposes a PCE-based architecture to support path computation in MLN networks so you can get inter-layer TE 🦋.
Setting up or tearing down a TE link in the VNT has to take into account the state of existing LSPs and/or new LSP requests in the higher layer 🫠. So if a stateless PCE can't find a route for a request based on the upper-layer topology info, it doesn't have enough info to decide whether to set up or remove a TE link 😬. That can lead to non-optimal resource usage, and that's not the vibe 🙅♀️.
A passive stateful PCE, on the other hand, can make a better call on when and how to modify the VNT 👑. It can accommodate new LSP requests or reoptimize resource usage across layers, irrespective of the PCE models described in [RFC5623] 💅. And since an active capability is available, the stateful PCE can even issue VNT modification suggestions to accommodate path setup requests or reoptimize resource usage across layers 🚀💖.
3.6. LSP Reoptimization 🔄
okay so sometimes it's really worth reoptimizing one or more LSPs dynamically to use network resources efficiently 🍓. With a stateless PCE, doing this through online planning means the PCC has to send a request to the PCE along with detailed path and bandwidth info for all the LSPs that need to be optimized at the same time 📋. Which means the PCC has to figure out when and which LSPs should be optimized by itself 😅.
With a passive stateful PCE, the LSP state info in the LSP database makes the dynamic optimization so much easier 🥹. The PCC doesn't have to send detailed LSP state info at all ✨. And an active stateful PCE can even automate the whole thing by triggering the request itself 🤖💜.
Because a stateful PCE keeps track of all the LSPs that are being set up, and it might be able to control the timing and sequence of LSP setup and deletion, optimization can happen more intelligently and effectively 🧠🎀. A stateful PCE can also decide which LSP to reoptimize based on network events 🌟. For example, when an LSP gets torn down, its resources are freed up 🫧, and that can trigger the stateful PCE to automatically figure out which LSP should be reoptimized so the newly freed resources can go to it 🦋.
A special case of LSP reoptimization is GCO [RFC5557] 👑. Global control of the LSP operation sequence in [RFC5557] depends on what's basically a stateful (or semi-stateful) NMS 💅. That NMS can either live somewhere not local to the network nodes, in which case another northbound interface is needed for LSP attribute changes, or it can be local/collocated, in which case there are big efficiency issues with resource usage 😩. A stateful PCE adds a few features that:
- Roll the NMS visibility into the PCE and remove the requirement for an additional northbound interface. 🫶
- Allow the PCE to determine when reoptimization is needed, and with which level (GCO or a more incremental optimization). 🕰️
- Allow the PCE to determine which LSPs should be reoptimized. 🎯
- Allow a PCE to control the sequence of events across multiple PCCs, allowing for bulk (and truly global) optimization, LSP shuffling, etc. 🌈✨
3.7. Resource Defragmentation 🧩
okay so if LSPs keep getting allocated and released over time, the resource gets fragmented 🥲. In networks with link bundles, the overall available resource on a (bundle) link might be enough for a new LSP request, but if that available resource isn't contiguous, the request gets rejected 💔. Stateful PCEs can do the defragmentation because they need global visibility of LSPs in the network to accurately assess resources on the LSPs and defragment while keeping network disruption minimal 🫧. A stateless PCE can't handle this use case because it doesn't have the detailed info about existing LSPs in the network 🙅♀️.
Another case that's especially interesting is optical spectrum defragmentation in flexible-grid networks 🌈. In flexible-grid networks [RFC7698], LSPs with different optical spectrum sizes (like 12.5GHz, 25GHz, etc.) can coexist so they can serve services with different bandwidth requests 🌸. So even if the overall spectrum size can meet a service request, it might not be usable if the available spectrum is fragmented into smaller, non-contiguous pieces 😭. With the help of existing LSP state info, a stateful PCE can group the resource together so it becomes usable 🪄. A stateful PCE can also proactively choose routes for upcoming path requests to reduce the chance of spectrum fragmentation 🧠💖.
3.8. Point-to-Multipoint Applications 🦋
PCE has been identified as an appropriate technology for determining the paths of Point-to-Multipoint (P2MP) TE LSPs [RFC5671] 🌟. The application scenarios and use cases described in Sections 3.1, 3.4, and 3.6 also apply to P2MP TE LSPs 💅.
On top of that, the stateful nature of a PCE simplifies the info conveyed in PCEP messages, since you can refer to LSPs via an identifier 🪪. For P2MP this is an extra big win, because the size of the PCEP message is much larger otherwise 😱. With stateless PCEs, modifying a P2MP tree means encoding all the leaves along with the paths in a PCReq message 📦. But with a stateful PCE that has P2MP capability, the PCEP message can just convey the modifications, since the other info can be retrieved from the identifier via the LSP-DB 🫶✨.
3.9. Impairment-Aware Routing and Wavelength Assignment (IA-RWA) 🌈
Okay so in Wavelength Switched Optical Networks (WSONs) [RFC6163], a wavelength-switched LSP hops across one or more fiber links ✨. The client signals riding on those wavelength LSPs can have the same bit rate or totally different ones 💅, so one fiber link can carry a bunch of wavelength LSPs with equal or mixed bit-rate signals. Like, a fiber link might multiplex wavelengths with only 10 Gbit/s signals, or mixed 10 Gbit/s and 40 Gbit/s signals, or mixed 40 Gbit/s and 100 Gbit/s signals. Mixing is giving variety 🎀
IA-RWA in WSONs is the process (i.e., lightpath computation) that takes the optical layer and transmission imperfections into account as extra physical layer constraints 🔥. To be more specific, the linear and non-linear effects of the optical network elements should be built into the route and wavelength assignment procedure. For example, a physical imperfection can cause two adjacent lightpaths to interfere with each other 🙈. So a guard band should be reserved between them to ease those effects. How wide that guard band needs to be depends on the characteristics of the two wavelengths, like their modulation formats and bit rates. Two adjacent wavelengths with different characteristics (e.g., different bit rates) may need a wider guard band, while those with the same characteristics may need a narrower one. For example, 50 GHz spacing may be acceptable for two adjacent wavelengths with 40 G signals. But for two adjacent wavelengths with different bit rates (e.g., 10 G and 40 G), a larger spacing such as 300 GHz may be needed. So the characteristics (states) of the existing wavelength LSPs should be considered for a new RWA request in WSON 💖
In summary, when stateful PCEs do the IA-RWA procedure, they need to know the characteristics of the existing wavelength LSPs 🧚. Nodes in WSON networks can get the impairment information for existing and to-be-established LSPs through external configuration, or through other means like monitoring or estimation based on a vendor-specific impair model. The catch is that WSON-related routing protocols, i.e., [RFC7688] and [RFC7580], only advertise limited information (i.e., availability) about the existing wavelengths, without defining the supported client bit rates 😭. Extending routing protocols to disseminate the new information relevant for the IA-RWA process would incur a substantial amount of control-plane overhead. So in this scenario, stateful PCE(s) would be a more appropriate mechanism to solve this problem. Stateful PCE(s) can use the impairment information of LSPs stored in the LSP-DB to give accurate RWA calculations 👑
4. Deployment Considerations 🚀
This section talks about general issues with stateful PCE deployments and points out the areas where extra protocol extensions and procedures are needed to deal with them 🫶. Definitions of protocol mechanisms are beyond the scope of this document, so don't come for them here 🙈
4.1. Multi-PCE Deployments
Stateless and stateful PCEs can coexist in the same network and be in charge of different types of path computation 🦋. To tell the two types of PCEs apart, either discovery or configuration may be used.
Multiple stateful PCEs can coexist in the same network too 🌸. They might provide redundancy for load sharing, resilience, or partitioning of computation features. No matter why there are multiple PCEs, an LSP is only delegated to one of the PCEs at any given point in time 💅. Still, an LSP can be redelegated between PCEs, for example, when a PCE fails 😭. [RFC7399] discusses various approaches for synchronizing state among the PCEs when multiple PCEs are used for load sharing or backup and compute LSPs for the same network 🎀
4.2. LSP State Synchronization
The LSP-DB gets filled in with information received from the PCC 🍓. The accuracy of the computations depends on how accurate the databases are, and the updates have to reach the PCE from the network, so the PCE view lags behind the true state of the network ⏳. Thus, using a stateful PCE reduces but cannot eliminate the possibility of crankbacks, and it can't guarantee optimal computations all the time 💀. [RFC7399] discusses these limitations and potential ways to ease them.
When there are multiple PCEs with different capabilities in the same network, such as a passive stateful PCE and an active stateful PCE, it's useful to refer to an LSP by a unique identifier 🧩. That's better than spelling out detailed information (e.g., route, bandwidth) about it, especially when these PCEs cooperate on path computation, such as for load sharing ✨. This is true whether the LSP is delegated or not.
4.3. PCE Survivability
For a stateful PCE, a big deal is getting the LSP state information resynchronized after a restart 🔁. LSP state synchronization procedures can be applied equally to a network node or to another PCE, so there are multiple ways to reacquire the LSP database on a restart 🌈. Synchronization can also be skipped. If a PCE implementation has a way to retrieve its database differently (for example, from a backup copy stored locally), the state can be restored without further overhead in the network 🫶. A hybrid approach is also possible, where the bulk of the state is recovered locally and a small amount is reacquired from the network 💖. Just note that recovering the state locally would still need some degree of resynchronization to make sure the recovered state is actually up-to-date 👀. Depending on the resynchronization mechanism used, there may be extra load on the PCE, and there may be a delay in reaching the synchronized state, which may negatively affect survivability 😬. Different resynchronization methods suit different deployments and objectives.
5. Security Considerations 🔐
This document describes general considerations for a stateful PCE deployment and looks at its applicability and benefits, as well as its challenges and limitations, through a number of use cases. No new protocol extensions to PCEP are defined in this document 🙌
The PCEP extensions that support the stateful PCE and the delegation of path control ability can make more information and control available to a hypothetical adversary, and they open a number of additional attack surfaces that must be protected 🚨 This includes, but is not limited to, the authentication and encryption of PCEP sessions, snooping of the state of the LSPs active in the network, etc. Seriously, this is a big deal 💀 So documents that define PCEP protocol extensions need to consider the issues and risks associated with a stateful PCE 🔥
6. References 📚
6.1. Normative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path
Computation Element Architecture", RFC 7399,
DOI 10.17487/RFC7399, October 2014,
<http://www.rfc-editor.org/info/rfc7399>.6.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427,
DOI 10.17487/RFC4427, March 2006,
<http://www.rfc-editor.org/info/rfc4427>.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux,
M., and D. Brungard, "Requirements for GMPLS-Based Multi-
Region and Multi-Layer Networks (MRN/MLN)", RFC 5212,
DOI 10.17487/RFC5212, July 2008,
<http://www.rfc-editor.org/info/rfc5212>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <http://www.rfc-editor.org/info/rfc5521>.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, DOI 10.17487/RFC5557,
July 2009, <http://www.rfc-editor.org/info/rfc5557>.
[RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
"Framework for PCE-Based Inter-Layer MPLS and GMPLS
Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
September 2009, <http://www.rfc-editor.org/info/rfc5623>.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the
Path Computation Element (PCE) to Point-to-Multipoint
(P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
DOI 10.17487/RFC5671, October 2009,
<http://www.rfc-editor.org/info/rfc5671>.
[RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
"Framework for GMPLS and Path Computation Element (PCE)
Control of Wavelength Switched Optical Networks (WSONs)",
RFC 6163, DOI 10.17487/RFC6163, April 2011,
<http://www.rfc-editor.org/info/rfc6163>.
[RFC7580] Zhang, F., Lee, Y., Han, J., Bernstein, G., and Y. Xu,
"OSPF-TE Extensions for General Network Element
Constraints", RFC 7580, DOI 10.17487/RFC7580, June 2015,
<http://www.rfc-editor.org/info/rfc7580>.
[RFC7688] Lee, Y., Ed. and G. Bernstein, Ed., "GMPLS OSPF
Enhancement for Signal and Network Element Compatibility
for Wavelength Switched Optical Networks", RFC 7688,
DOI 10.17487/RFC7688, November 2015,
<http://www.rfc-editor.org/info/rfc7688>.
[RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F.,
Fu, X., Ceccarelli, D., and I. Hussain, "Framework and
Requirements for GMPLS-Based Control of Flexi-Grid Dense
Wavelength Division Multiplexing (DWDM) Networks",
RFC 7698, DOI 10.17487/RFC7698, November 2015,
<http://www.rfc-editor.org/info/rfc7698>.Acknowledgements 🫶
We would like to thank Cyril Margaria, Adrian Farrel, JP Vasseur, and Ravi Torvi for the useful comments and discussions 💜 you all are the real MVPs ✨
Contributors ✨
okay bestie, these are the people who put SO much work into this doc 🫶 listed alphabetically, no cap. they all contributed significantly, so they get the spotlight 🌟
Ramon Casellas
CTTC - Centre Tecnologic de Telecomunicacions de Catalunya
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
Email: ramon.casellas@cttc.esEdward Crabbe
Email: edward.crabbe@gmail.comDhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
India
Email: dhruv.dhody@huawei.comOscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo
Emilio Vargas 6
Madrid, 28045
Spain
Phone: +34 913374013
Email: ogondio@tid.esYoung Lee
Huawei
1700 Alma Drive, Suite 100
Plano, TX 75075
United States of America
Phone: +1 972 509 5599 x2240
Fax: +1 469 229 5397
Email: leeyoung@huawei.comJan Medved
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: jmedved@cisco.comRobert Varga
Pantheon Technologies LLC
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.skFatai Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
China
Phone: +86-755-28972912
Email: zhangfatai@huawei.comXiaobing ZiAuthors' Addresses ✨
and last but not least, the two editors who kept this whole thing together 💖🎀
Xian Zhang (editor)
Huawei Technologies
F3-5-B R&D Center
Huawei Industrial Base
Bantian, Longgang District
Shenzhen, Guangdong 518129
China
Email: zhang.xian@huawei.comIna Minei (editor)
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: inaminei@google.com📦 where this page comes from
- ietf: rfc8051 2017-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms