RFC 3214

LSP Modification Using CR-LDP

📅 published January 2002, from ietf

Network Working Group 🎀

Okay bestie, so this is RFC 3214, titled LSP Modification Using CR-LDP 💖 It's from the Network Working Group, and it's on the Standards Track ✨ Dated January 2002 🌸 It was written by J. Ash (AT&T), Y. Lee (Ceterus Networks), P. Ashwood-Smith, B. Jamoussi, D. Fedyk, and D. Skalecki (Nortel Networks), and L. Li (SS8 Networks) 👑 It doesn't list any obsoletes or updates entries, so it's not replacing or changing anything else 🦋

Status of this Memo 💅

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract 🧚

okay so this doc is all about changing the bandwidth (and maybe other stuff) of a CR-LSP (Constraint-based Routed Label Switched Path) that's already up and running, using CR-LDP (Constraint-based Routed Label Distribution Protocol) 🔥 and the best part is there's no service interruption 😭 Once a CR-LSP is set up, the network operator might need to change how much bandwidth it reserves, because the traffic on it has new requirements. CR-LDP can handle this with the _modify_value for the _action indicator flag_ in the LSPID TLV ✨ It's giving dynamic network resource management, especially when traffic with different priorities and service classes is involved 💜

Table of Contents 🍓

1.  Conventions Used in This Document ............................  2
2.  Introduction .................................................  2
3.  LSP Modification Using CR-LDP ................................  3
  3.1 Basic Procedure for Resource Modification ..................  3
  3.2 Rerouting LSPs .............................................  5
  3.3 Priority Handling ..........................................  6
  3.4 Modification Failure Case Handling .........................  6
4.  Application of LSP Bandwidth Modification in Dynamic Resource
    Management ...................................................  7
5.  Acknowledgments ..............................................  8
6.  Intellectual Property Considerations .........................  8
7.  Security Considerations ......................................  8
8.  References ...................................................  8
9.  Authors' Addresses ...........................................  9
10. Full Copyright Statement ..................................... 11

1. Conventions Used in This Document 📚

Here's the abbreviation cheat sheet, bestie 🫶

L:           LSP (Label Switched Path)
L-id:        LSPID (LSP Identifier)
T:           Traffic Parameters
R:           LSR (Label Switching Router)
FEC:         Forwarding Equivalence Class
NHLFE:       Next Hop Label Forwarding Entry
FTN:         FEC To NHLFE
TLV:         Type Length Value

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. 🙈

2. Introduction 🦋

Picture this: there's an LSP called L1 that's already been established with its set of traffic parameters T0 🌸 A certain amount of bandwidth is reserved along L1's path, right? But then stuff changes. Maybe L1 needs more bandwidth because there's more traffic, or the SLA for L1 needs to change because the customer wants a different service class 💅 So the network operator wants to change L1's characteristics, like swapping its traffic parameter set from T0 to T1, without tearing L1 down and interrupting service. Sometimes operators also want to reroute a CR-LSP onto a different path, either for better performance or better use of network resources. In all of these cases, LSP modification is needed ✨

Section 3 explains a way to modify an active LSP using CR-LDP. The LSPID concept in CR-LDP is what makes this work, and it does it without releasing the LSP, without interrupting service, and without double booking the bandwidth 👑 Section 4 then walks through an example of using this method to manage bandwidth needs dynamically without interrupting service 🔥 In CR-LDP, an action indicator flag of _modify_ is used to explicitly specify the behavior, and it leaves the existing LSPID free to support other networking capabilities in the future 💖 Reference [3], RFC XXXX, specifies the action indicator flag of _modify_ for CR-LDP.

3. LSP Modification Using CR-LDP 🎀

3.1 Basic Procedure for Resource Modification ✨

LSP modification can only be allowed when the LSP is already set up and active 💅 So modification isn't defined or allowed during LSP establishment or during the label release/withdraw phases 😭 In this document, only modification requested by the ingress LSR of the LSP is considered for CR-LSP 🧚 And the ingress LSR can't modify an LSP before a previous modification procedure is completed 🙈

Let's say CR-LSP L1 is set up with LSPID L-id1, which is unique in the MPLS network 🌈 The ingress LSR R1 of L1 has FEC1 -> Label A in its FTN (FEC To NHLFE) table, where A is the outgoing label for LSP L1 🦋 To modify L1's characteristics, R1 sends a Label Request Message. In that message, the TLVs carry the new requested values, and the LSPID TLV is included to indicate the value of L-id1 💜 The Traffic Parameters TLV, the ER-TLV, the Resource Class (color) TLV, and the Preemption TLV can all have values that differ from the ones in the original Label Request Message that was used to set up L1 earlier 🔥 So L1 can change its bandwidth request (Traffic Parameters TLV), its traffic service class (Traffic Parameters TLV), the route it takes (ER TLV), and its setup and holding priorities (Preemption TLV) 👑 Meanwhile, R1 still has FEC1 -> Label A in its FTN, and it's waiting to establish another entry for FEC1 🫶

When an LSR Ri along L1's path gets the Label Request message, it behaves the same way it would for any Label Request message ✨ The only extension is that Ri looks at the LSPID in the Label Request Message, L-id1, and checks whether it already has L-id1 🍓 If Ri doesn't have L-id1, it treats the message like a brand-new Label Request message 💖 If Ri already has L-id1, it takes the newly received Traffic Parameter TLV, works out the new bandwidth required, and derives the new service class 🎀 Compared with the bandwidth already reserved for L-id1, Ri now reserves only the difference in bandwidth requirements, which keeps Ri from double booking bandwidth 💅 If a new service class is requested, Ri also gets ready to receive the traffic on L1 the same way it would for a Label Request Message, maybe using a different type of queue 🌸 Then Ri assigns a new label for the Label Request Message 🧚

When the Label Mapping message comes back, there are two sets of labels for the same LSPID 🌈 So the ingress LSR R1 now has two outgoing labels, A and B, tied to the same FEC, where B is the new outgoing label for LSP L1 🦋 R1 can now activate the new FTN entry, FEC1 -> Label B 🔥 That means R1 swaps traffic on L1 over to the new label _B_ (the _new_ path) 😭 Packets can now go out with label B and the new set of traffic parameters (if any), and on a new path if the Label Request Message asked for one as part of the modification ✨ All the other LSRs along the path start receiving incoming packets with the new label 👑 For that incoming new label, the LSR has already set up its mapping to the new outgoing label, so the packets go out with the new outgoing label 💜 The LSRs don't need to implement any new procedures to track the new and old characteristics of the LSP 🙈

After that, the ingress LSR R1 starts releasing the original label A for LSP L1 💖 R1 sends a Label Release Message downstream. The Release message carries the LSPID L-id1 and the Label TLV to say which label is being released 🎀 The Release Message is propagated to the egress LSR so it can release the original labels that were used for L1 🍓 When LSR Ri receives the Label Release Message, it examines the LSPID, L-id1, and finds that L-id1 still has another set of labels (incoming/outgoing) under it 🌸 So the old label is released without releasing the resource that's in use 💅 In other words, if L1's bandwidth went down, only the delta bandwidth is released, and otherwise no bandwidth is released 🧚 This modification procedure can be used not only to change an active LSP's traffic parameters and/or service class, but also to reroute an existing LSP (as described in Section 3.2 below), and/or to change its setup/holding priority if desired 🌈 Once the release procedure is done, the LSP modification is complete ✨

This method follows the normal Label Request / Mapping / Notification / Release / Withdraw behavior of a CR-LDP operated LSR, with one specific action taken on an LSPID 🦋 If a Label Withdraw Message is used to withdraw a label associated with an LSPID, the Label TLV should be included to specify which label to withdraw 💜 Since the LSPID can also be used to support other features, an action indication flag of _modify_ assigned to the LSPID explicitly defines the action and semantics that should go with the messaging procedure 🔥 The details of this flag are covered in the CR-LDP document, Reference [3] 👑

3.2. Rerouting LSPs

okay so LSP modification can also be used to reroute an existing LSP 🛣️ but this doc only considers modifications requested by the ingress LSR of the LSP for CR-LSP. bestie, the Ingress LSR cannot modify an LSP before a previous modification procedure is completed 🙅‍♀️

let's use CR-LSP L1 with LSPID L-id1 as our example 🦋 to reroute it, the ingress LSR R1 sends a Label Request Message. in that message the LSPID TLV says L-id1, and the Explicit Route TLV has some different hops from the explicit route in the original Label Request Message. the action indication flag is set to modify ✨

at this point R1 still has an entry in FTN: FEC1 -> Label A. R1 is basically waiting to establish another entry for FEC1 👀

when an LSR Ri along the path of L1 gets the Label Request message, it acts exactly like it would for any Label Request that modifies some other parameters of the LSP 💅 Ri assigns a new label for the Label Request Message and forwards it along the explicit route. it does not allocate any more resources except as described in section 3.1.

then at another LSR Rj further along the path, the explicit route diverges from the previous route 🌿 Rj acts like Ri, but forwards the Label Request message along the new route. from that point on, each LSR treats the Label Request Message as setting up a new LSP, until the paths converge at a later LSR Rk. the modify value of the action indication flag is ignored here ✨

At Rk and subsequent LSRs, the Label Request Message is handled as at Ri. literally the same vibe 💖

now on the return path, when the Label Mapping message comes back, there are two sets of labels for the LSPID wherever the new route coincides with the old one 🫶 but only one set of labels exists at the LSRs where the routes diverge.

when the Label Mapping message reaches the ingress LSR R1, it has two outgoing labels, A and B, both tied to the same FEC. B is the new outgoing label received for LSP L1 💜 so R1 can activate the new entry, FEC1 - > Label B, and de-activate the old entry, FEC1 - > Label A. this means R1 swaps traffic on L1 over to the new label B. the packets are now sent with label B, on the new path 🔥 main character energy!!

after that, the ingress LSR R1 starts releasing the original label A for LSP L1 🧹 the Label Release Message is sent by R1 toward the downstream LSRs on the original route. the Release message carries the LSPID L-id1 and the Label TLV to say which label is being released. at each LSR the old label gets released, and no further action is required to change the path of the data packets that are already following the new route programmed by the Label Mapping message 🦢

okay now the tricky part 🥹 at some LSRs where the routes diverged, there's only one label for the LSPID. for example, between Rj and Rk, the Label Release Message follows the old route. at the LSRs between Rj and Rk, only the labels from the original route exist for LSPID L-id1. at these LSRs the LSPID TLV doesn't need to be examined to release the correct label, but it must still be updated and passed on to the next LSR as the Label Release message moves along. that way, at Rk where the routes converge, the downstream LSR knows which label to release, and it can keep forwarding the Label Release Message along the old route 🧚

3.3. Priority Handling

when you send a Label Request Message for an active LSP L1 to request changes, the setup priority in that message can be different from the one used in the previous Label Request Message 💅 which effectively signals the priority of this modification request. network operators can use this to decide what priority a modification request gets, based on their policies/algorithms and the current traffic situation in the network 🌸

for example, the priority for a modification can be determined by the priority of the customer/LSP. if a customer has gone way over the reserved bandwidth of its VPN LSP tunnel, the modification request's priority may be given a higher value 🔥

the Label Request message for modifying an active LSP can also be sent with a holding priority that's different from its previous one ✨ this effectively changes the holding priority of the LSP. when an LSR gets a Label Request Message that asks for a new holding priority, it assigns that new holding priority to the bandwidth. so the new holding priority is applied to both the existing incoming/outgoing labels and the new labels being set up for the LSPID in question 🦋 and that's how self-bumping gets prevented 🙅‍♀️💖

3.4. Modification Failure Case Handling

okay real talk 😭 a modification attempt can fail because of insufficient resources or other situations. when that happens, a Notification message is sent back to the ingress LSR R1 to indicate that the Label Request Message meant to modify the LSP failed. a retry may be attempted if the network operator wants one 🔁

if the LSP on its original path fails while a modification attempt is in progress, the attempt should be aborted by using the Label Abort Request message, as specified in the LDP document [5] 🛑

and if a modification fails, all modifications to the LSP, including the holding priority, must be restored to their original values 🫶 no leftovers, no drama 💅

4. Application of LSP Bandwidth Modification in Dynamic Resource Management ✨

okay bestie, this section is a fun example of dynamic network resource management using LSP bandwidth modification 🎀 the details live in a previous internet-draft [2] if you want the full tea.

so picture this: customers or services are assigned given CR-LSPs 💖 and each one gets one of three priorities: key, normal or best effort. the network operator really doesn't want to bump any LSPs during an LSP setup 😭 so after these CR-LSPs are set up, their holding priorities are all assigned the highest value 👑

the network operator also wants to control the resources on the links of the LSRs, so each LSR keeps track of the usage status of its links 👀 based on the usage history, each link gets a current threshold priority Pi. that means the link has no bandwidth available for a Label Request with a setup priority lower than Pi 🚧

when an LSP's bandwidth needs to be modified, the operator uses a policy-based algorithm to assign a priority for the modification request, let's say Mp for LSP L2 🧮 then the ingress LSR sends a Label Request message with Setup Priority = Mp. if there's enough bandwidth on the link for the modification, and the Setup priority in the Label Request Message is higher in priority (Mp numerically smaller) than the Pi threshold of the link, the Label Request Message gets accepted by the LSR ✅ otherwise, it gets rejected with a Notification message that says there are insufficient resources 🥀

also, a little heads-up 🦋 when OSPF (or IS-IS) floods the available-link-bandwidth information, any available bandwidth associated with a priority lower than Pi (numerical value bigger) should be interpreted as 0.

this example, which is based on a priority threshold Pi, is implementation specific 🧠 but it shows how flexible the modification procedure is for prioritizing and controlling network resources 💅 the calculation of Mp can depend on the network and the service, and it's based on the operator's routing policy 💜 for example, the operator may assign a higher priority (lower Mp value) to an L2 bandwidth modification if L2 belongs to a customer or service with Key priority 👑

the operator can also collect the actual usage of each LSP and give a lower priority (higher Mp) to an L2 bandwidth-increase modification. like, if in the past week L2 has exceeded its reserved bandwidth by 2 times on the average 📉

and here's the big twist 🌪️ an operator may try to increase the bandwidth of L2 on its existing path, but it's unsuccessful because there's insufficient bandwidth available on L2 😤 in that case, the operator is willing to increase the bandwidth of another LSP, L3, which has the same ingress/egress LSRs as L2, so the overall ingress/egress bandwidth allocation goes up 🙌 however, in this case the L3 bandwidth modification is performed with a lower priority (higher Mp value), since L3 is routed on a secondary path. that means the higher bandwidth allocation priority goes to the LSPs that are on their primary paths [2] 🫶 iconic, honestly.

Copyright (C) The Internet Society (2002). All Rights Reserved. 📜

okay so the legal part is actually pretty chill 💅 You're allowed to copy this document and share it with others. You can also make derivative works that comment on it, explain it, or help people implement it, and you can publish and distribute those in whole or in part with no restriction of any kind. The one condition is that the copyright notice and this paragraph have to be included on every copy and every derivative work 🎀

BUT the document itself can't be changed in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards (then you have to follow the copyright procedures in the Internet Standards process) or when you're translating it into a language other than English 🌍

These permissions are perpetual, meaning the Internet Society and its successors or assigns won't ever revoke them 🦋

The document and the info in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. no warranties, bestie, so read it carefully 🙈

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. thank you to the Internet Society for keeping the RFC Editor running 💜

📦 where this page comes from