RFC 3469
Framework for Multi-Protocol Label Switching (MPLS)-based Recovery
RFC 3469 ✨ Framework for Multi-Protocol Label Switching (MPLS)-based Recovery
Part 1 of 8, more coming bestie! 🧚
okay so let's start with the title block 🎀 this is RFC 3469, and its title is "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery." it came out of the Network Working Group in February 2003 and its category is Informational 📅. the authors are V. Sharma, Ed. (Metanoia, Inc.) and F. Hellstrand, Ed. (Nortel Networks) 👯♀️. the title block doesn't list any RFCs that it obsoletes or updates, so nothing gets replaced or patched here 🫶
Status of This Memo 📜
this memo is giving information to the Internet community 💌 it does not specify an Internet standard of any kind, and distribution of this memo is unlimited 🌸
Copyright Notice ©️
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🦋
MPLS basically takes the label swapping forwarding paradigm and mashes it together with network layer routing 🔥 to deliver reliable service, MPLS needs a bunch of procedures that protect the traffic riding on different paths 🛡️ this means the label switching routers (LSRs) have to support fault detection, fault notification, and fault recovery mechanisms, and MPLS signaling has to support configuring recovery 💅 with all of that in mind, this document specifies a framework for MPLS based recovery. restart issues are not part of this framework, so don't look for them here 🙈
Table of Contents 🗺️
1. Introduction................................................2
1.1. Background............................................3
1.2. Motivation for MPLS-Based Recovery....................4
1.3. Objectives/Goals......................................5
2. Overview....................................................6
2.1. Recovery Models.......................................7
2.1.1 Rerouting.....................................7
2.1.2 Protection Switching..........................8
2.2. The Recovery Cycles...................................8
2.2.1 MPLS Recovery Cycle Model.....................8
2.2.2 MPLS Reversion Cycle Model...................10
2.2.3 Dynamic Re-routing Cycle Model...............12
2.2.4 Example Recovery Cycle.......................13
2.3. Definitions and Terminology..........................14
2.3.1 General Recovery Terminology.................14
2.3.2 Failure Terminology..........................17
2.4. Abbreviations........................................18
3. MPLS-based Recovery Principles.............................18
3.1. Configuration of Recovery............................19
3.2. Initiation of Path Setup.............................19
3.3. Initiation of Resource Allocation....................20
3.3.1 Subtypes of Protection Switching.............21
3.4. Scope of Recovery....................................21
3.4.1 Topology.....................................21
3.4.2 Path Mapping.................................24
3.4.3 Bypass Tunnels...............................25
3.4.4 Recovery Granularity.........................25
3.4.5 Recovery Path Resource Use...................26
3.5. Fault Detection......................................26
3.6. Fault Notification...................................27
3.7. Switch-Over Operation................................28
3.7.1 Recovery Trigger.............................28
3.7.2 Recovery Action..............................29
3.8. Post Recovery Operation..............................29
3.8.1 Fixed Protection Counterparts................29
3.8.2 Dynamic Protection Counterparts..............30
3.8.3 Restoration and Notification.................31
3.8.4 Reverting to Preferred Path
(or Controlled Rearrangement)................31
3.9. Performance..........................................32
4. MPLS Recovery Features.....................................32
5. Comparison Criteria........................................33
6. Security Considerations....................................35
7. Intellectual Property Considerations.......................36
8. Acknowledgements...........................................36
9. References.................................................36
9.1 Normative References.................................36
9.2 Informative References...............................37
10. Contributing Authors.......................................37
11. Authors' Addresses.........................................39
12. Full Copyright Statement...................................401. Introduction ✨
this memo describes a framework for MPLS-based recovery 🧁 we give a detailed taxonomy of recovery terminology, and we talk about the motivation for, the objectives of, and the requirements for MPLS-based recovery. we outline principles for MPLS-based recovery, and we also provide comparison criteria that can be used as a basis for comparing and evaluating different recovery schemes 🔍
at some points in the document we share some thoughts about the operation or viability of certain recovery objectives. these should be seen as the opinions of the authors, not the consolidated views of the IETF 🙋♀️ the document is informational, and a standards track document is expected to be developed later to describe a subset of this document as to meet the needs currently specified by the TE WG 🎯
1.1. Background 🌐
network routing deployed today is focused mainly on connectivity, and it typically supports only one class of service, the best effort class 🫠 Multi-protocol label switching [RFC3031] is different. by integrating forwarding based on label-swapping of a link local label with network layer routing, it allows flexibility in delivering new routing services 🦄 MPLS can use media-specific forwarding mechanisms like label swapping, and that enables some sophisticated features such as quality-of-service (QoS) and traffic engineering [RFC2702] to be implemented more effectively 💫 an important part of providing QoS, though, is being able to transport data reliably and efficiently 🥹
here's the tea ☕ although current routing algorithms are robust and survivable, they can take a significant amount of time to recover from a fault. that's several seconds for interior gateway protocols (IGPs), or minutes for exterior gateway protocols such as the Border Gateway Protocol (BGP) 😱 in the meantime, service gets disrupted for some applications. this is unacceptable when the aim is a highly reliable service, with recovery times in the order of seconds down to 10's of milliseconds ⏱️ IP routing also may not be able to provide bandwidth recovery, where the goal is to provide not only an alternative path but also bandwidth equivalent to what was available on the original path 💸 (for some recent work on bandwidth recovery schemes, the reader is referred to [MPLS-BACKUP].) examples of these applications are Virtual Leased Line services, Stock Exchange data services, voice traffic, video services etc, i.e., basically every application that gets a disruption in service long enough to break service agreements or the required level of quality 📉💀
MPLS recovery may be motivated by the idea that there are limits to how much the recovery times of current routing algorithms can be improved 🧠 additional improvement can be obtained by augmenting these algorithms with MPLS recovery mechanisms [MPLS-PATH]. since MPLS is a possible technology of choice for future IP-based transport networks, it's useful for MPLS to be able to provide protection and restoration of traffic 👑 MPLS may also help converge network functionality onto a common control and management plane 🤝 further, a protection priority could be used as a differentiating mechanism for premium services that need high reliability, such as Virtual Leased Line services and high priority voice and video traffic 💎 the rest of this document provides a framework for MPLS based recovery. it's focused at a conceptual level and is meant to address motivation, objectives and requirements. issues of mechanism, policy, routing plans and the characteristics of traffic carried by recovery paths are beyond the scope of this document 🚫
1.2. Motivation for MPLS-Based Recovery 💖
MPLS based protection of traffic (called MPLS-based Recovery) is useful for a bunch of reasons 🎀 the biggest one is its ability to increase network reliability by responding to faults faster than traditional Layer 3 (or IP layer) approaches can by themselves, while still giving the network visibility that Layer 3 provides 👀 on top of that, a protection mechanism using MPLS could let IP traffic go directly over WDM optical channels and give a recovery option without an intervening SONET layer or optical protection 🌈 that would make it easier to build IP-over-WDM networks that ask for fast recovery 🏗️ (note that this means transporting IP traffic over WDM links, not the Generalized MPLS, or GMPLS, control of a WDM link ⚠️)
the need for MPLS-based recovery comes from the following:
- I. Layer 3 or IP rerouting may be too slow for a core MPLS network that needs to support recovery times smaller than the convergence times of IP routing protocols. 🐢
- II. Layer 3 or IP rerouting does not provide the ability to give bandwidth protection to specific flows (e.g., voice over IP, virtual leased line services). 🎤
- III. Layer 0 (for example, optical layer) or Layer 1 (for example, SONET) mechanisms may be a wasteful use of resources. 🗑️
- IV. The granularity at which the lower layers may be able to protect traffic may be too coarse for traffic that is switched using MPLS-based mechanisms. 🥄
- V. Layer 0 or Layer 1 mechanisms may have no visibility into higher layer operations. So while they may provide, for example, link protection, they cannot easily provide node protection or protection of traffic transported at layer 3. Further, this may stop the lower layers from providing restoration based on the traffic's needs. For example, fast restoration for traffic that needs it, and slower restoration (with possibly more optimal use of resources) for traffic that does not require fast restoration. In networks where the latter class of traffic is dominant, providing fast restoration to all classes of traffic may not be cost effective from a service provider's perspective. 🧾
- VI. MPLS has desirable attributes when applied to the purpose of recovery for connectionless networks. Specifically, an LSP is source routed, and a forwarding path for recovery can be "pinned" and is not affected by transient instability in SPF routing brought on by failure scenarios. 📌
- VII. Establishing interoperability of protection mechanisms between routers/LSRs from different vendors in IP or MPLS networks is desired, so recovery mechanisms can work in a multivendor environment and certain protected services can move to an MPLS core. 🤝✨
1.3. Objectives/Goals
Okay bestie, here are the big goals MPLS-based recovery is chasing 🎯✨
I. MPLS-based recovery mechanisms may be subject to the traffic engineering goal of optimal use of resources. 💅
II. MPLS based recovery mechanisms should aim to facilitate restoration times that are sufficiently fast for the end user application. That is, that better match the end-user's application requirements. In some cases, this may be as short as 10s of milliseconds. ⚡
We observe that I and II may be conflicting objectives, and a trade off may exist between them. The optimal choice depends on the end-user application's sensitivity to restoration time and the cost impact of introducing restoration in the network, as well as the end-user application's sensitivity to cost. 🤔
III. MPLS-based recovery should aim to maximize network reliability and availability. MPLS-based recovery of traffic should aim to minimize the number of single points of failure in the MPLS protected domain. 🛡️
IV. MPLS-based recovery should aim to enhance the reliability of the protected traffic while minimally or predictably degrading the traffic carried by the diverted resources. 🫶
V. MPLS-based recovery techniques should aim to be applicable for protection of traffic at various granularities. For example, it should be possible to specify MPLS-based recovery for a portion of the traffic on an individual path, for all traffic on an individual path, or for all traffic on a group of paths. Note that a path is used as a general term and includes the notion of a link, IP route or LSP. 🌈
VI. MPLS-based recovery techniques may be applicable for an entire end-to-end path or for segments of an end-to-end path. 🧚
VII. MPLS-based recovery mechanisms should aim to take into consideration the recovery actions of lower layers. MPLS-based mechanisms should not trigger lower layer protection switching nor should MPLS-based mechanisms be triggered when lower layer switching has or may imminently occur. 🙈
VIII. MPLS-based recovery mechanisms should aim to minimize the loss of data and packet reordering during recovery operations. (The current MPLS specification itself has no explicit requirement on reordering.) 🍓
IX. MPLS-based recovery mechanisms should aim to minimize the state overhead incurred for each recovery path maintained. 🌸
X. MPLS-based recovery mechanisms should aim to minimize the signaling overhead to setup and maintain recovery paths and to notify failures. 📣
XI. MPLS-based recovery mechanisms should aim to preserve the constraints on traffic after switchover, if desired. That is, if desired, the recovery path should meet the resource requirements of, and achieve the same performance characteristics as, the working path. 👑
We observe that some of the above are conflicting goals, and real deployment will often involve engineering compromises based on a variety of factors such as cost, end-user application requirements, network efficiency, complexity involved, and revenue considerations. Thus, these goals are subject to tradeoffs based on the above considerations. ⚖️
2. Overview ✨
There are several options for providing protection of traffic. The most generic requirement is the specification of whether recovery should be via Layer 3 (or IP) rerouting or via MPLS protection switching or rerouting actions. 🦋
Generally network operators aim to provide the fastest, most stable, and the best protection mechanism that can be provided at a reasonable cost. The higher the levels of protection, the more the resources consumed. Therefore it is expected that network operators will offer a spectrum of service levels. MPLS-based recovery should give the flexibility to select the recovery mechanism, choose the granularity at which traffic is protected, and to also choose the specific types of traffic that are protected in order to give operators more control over that tradeoff. With MPLS-based recovery, it can be possible to provide different levels of protection for different classes of service, based on their service requirements. 💖
For example, using approaches outlined below, a Virtual Leased Line (VLL) service or real-time applications like Voice over IP (VoIP) may be supported using link/node protection together with pre-established, pre-reserved path protection. Best effort traffic, on the other hand, may use path protection that is established on demand or may simply rely on IP re-route or higher layer recovery mechanisms. 📞
As another example of their range of application, MPLS-based recovery strategies may be used to protect traffic not originally flowing on label switched paths, such as IP traffic that is normally routed hop-by-hop, as well as traffic forwarded on label switched paths. 🌍
2.1. Recovery Models
There are two basic models for path recovery: rerouting and protection switching. 🔁
Protection switching and rerouting, as defined below, may be used together. For example, protection switching to a recovery path may be used for rapid restoration of connectivity while rerouting determines a new optimal network configuration, rearranging paths, as needed, at a later time. 🧩
2.1.1. Rerouting
Recovery by rerouting is defined as establishing new paths or path segments on demand for restoring traffic after the occurrence of a fault. The new paths may be based upon fault information, network routing policies, pre-defined configurations and network topology information. Thus, upon detecting a fault, paths or path segments to bypass the fault are established using signaling. 🛣️
Once the network routing algorithms have converged after a fault, it may be preferable, in some cases, to reoptimize the network by performing a reroute based on the current state of the network and network policies. This is discussed further in Section 3.8. 🔄
In terms of the principles defined in section 3, reroute recovery employs paths established-on-demand with resources reserved-on-demand. 📦
2.1.2. Protection Switching
Protection switching recovery mechanisms pre-establish a recovery path or path segment, based upon network routing policies, the restoration requirements of the traffic on the working path, and administrative considerations. The recovery path may or may not be link and node disjoint with the working path. However if the recovery path shares sources of failure with the working path, the overall reliability of the construct is degraded. When a fault is detected, the protected traffic is switched over to the recovery path(s) and restored. 🔀
In terms of the principles in section 3, protection switching employs pre-established recovery paths, and, if resource reservation is required on the recovery path, pre-reserved resources. The various sub-types of protection switching are detailed in Section 4.4 of this document. 🎀
2.2. The Recovery Cycles
There are three defined recovery cycles: the MPLS Recovery Cycle, the MPLS Reversion Cycle and the Dynamic Re-routing Cycle. The first cycle detects a fault and restores traffic onto MPLS-based recovery paths. If the recovery path is non-optimal the cycle may be followed by any of the two latter cycles to achieve an optimized network again. The reversion cycle applies for explicitly routed traffic that does not rely on any dynamic routing protocols to converge. The dynamic re-routing cycle applies for traffic that is forwarded based on hop-by-hop routing. 🔄💜
2.2.1. MPLS Recovery Cycle Model
The MPLS recovery cycle model is illustrated in Figure 1. Definitions and a key to abbreviations follow. 📊
--Network Impairment
| --Fault Detected
| | --Start of Notification
| | | -- Start of Recovery Operation
| | | | --Recovery Operation Complete
| | | | | --Path Traffic Recovered
| | | | | |
| | | | | |
v v v v v v
----------------------------------------------------------------
| T1 | T2 | T3 | T4 | T5 |Figure 1. MPLS Recovery Cycle Model
The various timing measures used in the model are described below. ⏱️
T1 Fault Detection Time
T2 Fault Hold-off Time
T3 Fault Notification Time
T4 Recovery Operation Time
T5 Traffic Recovery TimeDefinitions of the recovery cycle times are as follows: 📝
Fault Detection Time
The time between the occurrence of a network impairment and the moment the fault is detected by MPLS-based recovery mechanisms. This time may be highly dependent on lower layer protocols. 🔍
Fault Hold-Off Time
The configured waiting time between the detection of a fault and taking MPLS-based recovery action, to allow time for lower layer protection to take effect. The Fault Hold-off Time may be zero. ⏳
Note: The Fault Hold-Off Time may occur after the Fault Notification Time interval if the node responsible for the switchover, the Path Switch LSR (PSL), rather than the detecting LSR, is configured to wait. 🙃
Fault Notification Time
The time between initiation of a Fault Indication Signal (FIS) by the LSR detecting the fault and the time at which the Path Switch LSR (PSL) begins the recovery operation. This is zero if the PSL detects the fault itself or infers a fault from such events as an adjacency failure. 📨
Note: If the PSL detects the fault itself, there still may be a Fault Hold-Off Time period between detection and the start of the recovery operation. 🕰️
Recovery Operation Time
The time between the first and last recovery actions. This may include message exchanges between the PSL and PML (Path Merge LSR) to coordinate recovery actions. 🤝
Traffic Recovery Time
The time between the last recovery action and the time that the traffic (if present) is completely recovered. This interval is intended to account for the time required for traffic to once again arrive at the point in the network that experienced disrupted or degraded service due to the occurrence of the fault (e.g., the PML). This time may depend on the location of the fault, the recovery mechanism, and the propagation delay along the recovery path. 🌅
2.2.2 MPLS Reversion Cycle Model 🎀
Okay so bestie, protection switching has a revertive mode, which means the traffic has to get switched back to the preferred path once the fault on that path is cleared 🔁✨ It's giving "welcome home, babe." The reversion cycle is shown in Figure 2 🦋 and it comes after the recovery cycle from Fig. 1, so think of it as the sequel 🍿
--Network Impairment Repaired
| --Fault Cleared
| | --Path Available
| | | --Start of Reversion Operation
| | | | --Reversion Operation Complete
| | | | | --Traffic Restored on Preferred Path
| | | | | |
| | | | | |
v v v v v v
-----------------------------------------------------------------
| T7 | T8 | T9 | T10| T11|Figure 2. MPLS Reversion Cycle Model 💅
Here are the timing measures in the model, bestie 🧚
T7 Fault Clearing Time
T8 Clear Hold-Off Time
T9 Clear Notification Time
T10 Reversion Operation Time
T11 Traffic Reversion TimeAlso, time T6 isn't in the diagram, but it still counts 👀 It's the time where the network impairment is not repaired and the traffic is flowing on the recovery path.
Now let's get into the definitions 💖
Fault Clearing Time 🔍
The time between the repair of a network impairment and the time that MPLS-based mechanisms learn that the fault has been cleared. This time may be highly dependent on lower layer protocols.
Clear Hold-Off Time ⏳
The configured waiting time between the clearing of a fault and MPLS-based recovery action(s). Waiting time may be needed to ensure that the path is stable and to avoid flapping in cases where a fault is intermittent. The Clear Hold-Off Time may be zero.
Note: The Clear Hold-Off Time may occur after the Clear Notification Time interval if the PSL is configured to wait.
Clear Notification Time 📣
The time between initiation of a Fault Recovery Signal (FRS) by the LSR clearing the fault and the time at which the path switch LSR begins the reversion operation. This is zero if the PSL clears the fault itself.
Note: If the PSL clears the fault itself, there still may be a Clear Hold-off Time period between fault clearing and the start of the reversion operation.
Reversion Operation Time 🔄
The time between the first and last reversion actions. This may include message exchanges between the PSL and PML to coordinate reversion actions.
Traffic Reversion Time 🚦
The time between the last reversion action and the time that traffic (if present) is completely restored on the preferred path. This interval is expected to be quite small since both paths are working and care may be taken to limit the traffic disruption (e.g., using "make before break" techniques and synchronous switch-over).
In practice, the most interesting times in the reversion cycle are the Clear Hold-off Time and the Reversion Operation Time together with Traffic Reversion Time (or some other measure of traffic disruption). The first interval is to ensure stability of the repaired path, and the latter one is to minimize disruption time while the reversion action is in progress 🫶
Given that both paths are available, it is better to wait to have a well-controlled switch-back with minimal disruption than have an immediate operation that may cause new faults to be introduced (except, perhaps, when the recovery path is unable to offer a quality of service comparable to the preferred path). Patience is cute, bestie 🌸
2.2.3 Dynamic Re-routing Cycle Model 🌈
Dynamic rerouting is all about bringing the IP network back to a stable state after a network impairment has happened ✨ A re-optimized network is achieved after the routing protocols have converged, and then the traffic moves from a recovery path to a (possibly) new working path. The steps are illustrated in Figure 3 🗺️
This cycle can be overlaid on the recovery cycle in Fig. 1 or the reversion cycle in Fig. 2, or both (in the event that both the recovery cycle and the reversion cycle take place before the routing protocols converge). It happens if, after the convergence of the routing protocols, it is determined (based on on-line algorithms or off-line traffic engineering tools, network configuration, or a variety of other possible criteria) that there is a better route for the working path 👑
--Network Enters a Semi-stable State after an Impairment
| --Dynamic Routing Protocols Converge
| | --Initiate Setup of New Working Path between PSL
| | | and PML
| | | --Switchover Operation Complete
| | | | --Traffic Moved to New Working Path
| | | | |
| | | | |
v v v v v
-----------------------------------------------------------------
| T12 | T13 | T14 | T15 |Figure 3. Dynamic Rerouting Cycle Model 🦋
The timing measures for this one:
T12 Network Route Convergence Time
T13 Hold-down Time (optional)
T14 Switchover Operation Time
T15 Traffic Restoration TimeNetwork Route Convergence Time 🕰️
We define the network route convergence time as the time taken for the network routing protocols to converge and for the network to reach a stable state.
Holddown Time 🧊
We define the holddown period as a bounded time for which a recovery path must be used. In some scenarios it may be difficult to determine if the working path is stable. In these cases a holddown time may be used to prevent excess flapping of traffic between a working and a recovery path.
Switchover Operation Time 🔀
The time between the first and last switchover actions. This may include message exchanges between the PSL and PML to coordinate the switchover actions.
Traffic Restoration Time 💖
The time between the last restoration action and the time that traffic (if present) is completely restored on the new preferred path.
2.2.4 Example Recovery Cycle 🎬
Let's watch the whole recovery cycle play out, bestie 🍓 This is a sequence of events that happens after a network impairment, when a protection switch is followed by dynamic rerouting. It's the full main character arc 💅
I. Link or path fault occurs
II. Signaling initiated (FIS) for the detected fault
III. FIS arrives at the PSL
IV. The PSL initiates a protection switch to a pre-configured
recovery path
V. The PSL switches over the traffic from the working path to the
recovery path
VI. The network enters a semi-stable state
VII. Dynamic routing protocols converge after the fault, and a new
working path is calculated (based, for example, on some of the
criteria mentioned in Section 2.1.1).
VIII. A new working path is established between the PSL and the PML
(assumption is that PSL and PML have not changed)
IX. Traffic is switched over to the new working path.2.3. Definitions and Terminology 📚
This document assumes the terminology given in [RFC3031], and, in addition, introduces the following new terms. Let's get into it 🧚✨
2.3.1 General Recovery Terminology ✨
bestie, this is the glossary moment 📚💅 we're gonna go through every term so we're all speaking the same language.
Re-routing 🦋 okay so this is when the recovery path or path segments get created on the fly after a fault shows up on the working path. ngl it's giving "figure it out once it breaks." the recovery path isn't set up ahead of time. 🙈
Protection Switching 🛡️ the opposite energy! the recovery path or path segments are already built before anything goes wrong on the working path. so the recovery path is pre-established and just sitting there waiting for its moment 👑
Working Path 🌸 this is the protected path that's carrying the traffic before any fault happens. the working path can look different depending on the setup: a hop-by-hop routed path, a trunk, a link, an LSP, or part of a multipoint-to-point LSP.
Other names for it are primary path and active path. same girl, different outfits 💖
Recovery Path 🧚 this is the path the traffic gets restored onto after a fault. basically, it's where the mechanism directs traffic when things go sideways. the recovery path is established using MPLS means ✨
It can be an equivalent recovery path, which means there's no reduction in quality of service. or it can be a limited recovery path, which doesn't guarantee the same quality of service (or any other performance criteria) as the working path. a limited recovery path isn't expected to be used for a long time, so don't get too cozy with it 🫶
Other names for it are back-up path, alternative path, and protection path.
Protection Counterpart 🪞 when we're talking about pre-planned protection switching, the "other" path is the counterpart. the protection counterpart of the working path is the recovery path, and vice versa. they're like soulmates in the routing world 💜
Path Switch LSR (PSL) 🔀 this is the LSR in charge of switching or replicating traffic between the working path and the recovery path.
Path Merge LSR (PML) 🫂 this LSR receives the traffic coming off the recovery path, then either merges it back onto the working path or, if it's the destination itself, passes the traffic up to the higher layer protocols. it's the cleanup crew 🧹✨
Point of Repair (POR) 🔧 an LSR that's set up to perform MPLS recovery. in other words, it's the one responsible for actually fixing an LSP. depending on the type of recovery scheme, the POR can be a PSL or a PML. it's whoever's on duty for the repair 💅
Intermediate LSR 🌷 any LSR on a working or recovery path that is neither a PSL nor a PML for that path. they're just in the middle, doing their thing, no drama 🙂
Path Group (PG) 🍓 a logical bundle of multiple working paths that are all routed the exact same way between a Path Switch LSR and a Path Merge LSR. it's a friend group that always travels together 👯♀️
Protected Path Group (PPG) 🛡️ a path group that needs protection. VIP section only 👑
Protected Traffic Portion (PTP) 🎯 the part of the traffic on an individual path that needs protection. for example, code points in the EXP bits of the shim header can identify which portion is protected. the bits are doing the talking 🗣️💖
Bypass Tunnel 🚇 a path that backs up a set of working paths using the label stacking approach [RFC3031]. the working paths and the bypass tunnel must all share the same path switch LSR (PSL) and the path merge LSR (PML). everybody has to be on the same page, no exceptions 📖
Switch-Over 🔄 the process of moving traffic off the path it's currently flowing on and onto one or more alternate paths. this can mean shifting traffic from a working path onto one or more recovery paths, or moving it from recovery path(s) onto a more optimal working path(s). glow up energy ✨
Switch-Back ↩️ the process of returning traffic from one or more recovery paths back to the working path(s). the glow-down is over, we're going home 🏠
Revertive Mode 🔁 a recovery mode where traffic is automatically switched back from the recovery path to the original working path once the working path is restored to a fault-free condition. this assumes a failed working path doesn't automatically give up its resources to the network. it's holding its spot 🪑💅
Non-revertive Mode 🚫🔁 a recovery mode where traffic is not automatically switched back to the original working path after that path is restored to a fault-free condition. depending on the configuration, the original working path might become the recovery path once it's fault-free. or it might get used for new working traffic and stop being associated with its original recovery path. in that case, it's surrendered to the network 🕊️
MPLS Protection Domain 🏰 the set of LSRs over which a working path and its corresponding recovery path are routed. this is the whole neighborhood 🏘️
MPLS Protection Plan 🗺️ the set of all LSP protection paths, plus the mapping from working paths to protection paths, that's deployed in an MPLS protection domain at a given time. it's the master plan, bestie 📝
Liveness Message 💓 a message exchanged periodically between two adjacent LSRs that works as a link probing mechanism. it gives an integrity check of the forward and backward directions of the link between the two LSRs, and it checks neighbor aliveness too. it's basically a heartbeat 💗
Path Continuity Test 🧪 a test that verifies the integrity and continuity of a path or path segment. the details of such a test are beyond the scope of this document. (it could be done, for example, by sending a control message along the same links and nodes as the data traffic, or it could be measured by the absence of traffic and by providing feedback.) it's a whole other episode 📺
2.3.2 Failure Terminology 💀
Path Failure (PF) 💔 a fault detected by MPLS-based recovery mechanisms. it's defined as the failure of the liveness message test or a path continuity test, which tells us path connectivity is lost. rip connectivity 🥀
Path Degraded (PD) 😬 a fault detected by MPLS-based recovery mechanisms that indicates the quality of the path is unacceptable. not dead, just… not it 🫠
Link Failure (LF) 🔌 a lower layer fault that indicates link continuity is lost. the lower layer may communicate this to the MPLS-based recovery mechanisms ⚡
Link Degraded (LD) 📉 a lower layer indication to MPLS-based recovery mechanisms that the link is performing below an acceptable level. the link is struggling, we see you 🥺
Fault Indication Signal (FIS) 🚨 a signal that says a fault has occurred along a path. each intermediate LSR relays it to its upstream or downstream neighbor until it reaches an LSR set up to perform MPLS recovery (the POR). the FIS gets transmitted periodically by the node or nodes closest to the point of failure, for some configurable length of time, or until the transmitting node receives an acknowledgement from its neighbor. it's basically the group chat yelling "SOMETHING BROKE" until someone replies 📣
Fault Recovery Signal (FRS) ✅ a signal that says a fault along a working path has been repaired. just like the FIS, each intermediate LSR relays it to its upstream or downstream neighbor until it reaches the LSR that performs recovery of the original path. the FRS also gets transmitted periodically by the node or nodes closest to the point of failure, for some configurable length of time or until the transmitting node gets an acknowledgement from its neighbor. "we're so back" energy 🎉🌈
2.4. Abbreviations 🔤
FIS: Fault Indication Signal.
FRS: Fault Recovery Signal.
LD: Link Degraded.
LF: Link Failure.
PD: Path Degraded.
PF: Path Failure.
PML: Path Merge LSR.
PG: Path Group.
POR: Point of Repair.
PPG: Protected Path Group.
PTP: Protected Traffic Portion.
PSL: Path Switch LSR.3. MPLS-based Recovery Principles 🧠
MPLS-based recovery is all about pulling off quick and complete restoration of traffic hit by a fault in an MPLS-enabled network. the fault might get detected at the IP layer, or in the lower layers that carry the IP traffic. the fastest MPLS recovery is assumed to come from protection switching. its LSR switch completion time can be viewed as comparable to, or equivalent to, the 50 ms switch-over completion time of the SONET layer. ⚡ MPLS-based recovery may also provide bandwidth protection for paths that need it 💪
This section talks through the concepts and principles of MPLS-based recovery. the concepts are presented as atomic or primitive terms, which can be combined to specify recovery approaches. we don't make any assumptions about the underlying layer 1 or layer 2 transport mechanisms or their recovery mechanisms. we're just focusing on the MPLS side of the story 🎀
3.1. Configuration of Recovery ⚙️
An LSR may support any or all of the following recovery options on a per-path basis.
Default-recovery (No MPLS-based recovery enabled): traffic on the working path is recovered only through Layer 3 or IP rerouting, or by some lower layer mechanism such as SONET APS. this is the same as having no MPLS-based recovery. this option may be used for low priority traffic, or for traffic that gets recovered some other way. for example, load shared traffic on parallel working paths may be automatically recovered when a fault hits one of those working paths, by distributing it among the remaining working paths 🥡
Recoverable (MPLS-based recovery enabled): this working path is recovered using one or more recovery paths, either via rerouting or via protection switching. the main character gets backup ✨
3.2. Initiation of Path Setup 🚀
there are three options for kicking off the recovery path setup 🎬. the active and recovery paths may be established using either RSVP-TE [RFC2205][RFC3209] or CR-LDP [RFC3212], or by any other means, including SNMP.
Pre-established: this is the same as the protection switching option. here, a recovery path (or paths) is established before any failure on the working path. the path selection can either be determined by an administrative centralized tool, or chosen by some algorithm implemented at the PSL and possibly intermediate nodes. to guard against the situation where the pre-established recovery path fails before or at the same time as the working path, the recovery path should have secondary configuration options, as explained in Section 3.3 below. planning ahead is lowkey everything 📅💅
Pre-Qualified: a pre-established path doesn't need to be created. it can just be pre-qualified. a pre-qualified recovery path isn't created specifically to protect the working path. instead, it's a path that was created for other purposes and then designated as a recovery path, once it's been determined to be an acceptable alternative for carrying the working path traffic. variants include the case where an optical path or trail is configured, but no switches are set. it's the "already exists, just needs a new job" arc 🌟
Established-on-Demand: this is the same as the rerouting option. here, a recovery path is established after a failure on its working path has been detected and notified to the PSL. the recovery path may be pre-computed or computed on demand, and that choice affects recovery times. so the timing depends on how it gets computed 🕰️
3.3. Initiation of Resource Allocation ✨
okay so a recovery path might support the same traffic contract as the working path, or it might not 💅 we use two different additive terms to tell these situations apart. If the recovery path can replace the working path without degrading service, it's called an equivalent recovery path 💖. If it lacks the resources (or resource reservations) to replace the working path without degrading service, it's called a limited recovery path 🥺. Based on that, there are two options for initiating resource allocation 🎀
Pre-reserved: this option applies only to protection switching 🛡️ here a pre-established recovery path reserves the required resources on all hops along its route while it's being set up. The reserved resources (e.g., bandwidth and/or buffers) at each node can't be used to admit more working paths, but they're available to all the traffic that's already at the node before a failure happens. The resources held by a set of recovery paths may be shared if they protect resources that aren't going to fail at the same time 🦋
Reserved-on-Demand: this option may apply to rerouting or to protection switching 🔁 here a recovery path reserves the required resources after a failure on the working path has been detected and notified to the PSL, and before the traffic on the working path gets switched over to the recovery path 🫶
Note that under both of the options above, depending on how many resources get reserved on the recovery path, it could be either an equivalent recovery path or a limited recovery path. iykyk 👑
3.3.1 Subtypes of Protection Switching
okay the resources (bandwidth, buffers, processing) on the recovery path can be used to carry either a copy of the working path traffic, or extra traffic that gets displaced when a protection switch happens 🌸 this gives us two subtypes of protection switching 💜
In 1+1 ("one plus one") protection, the resources (bandwidth, buffers, processing capacity) on the recovery path are fully reserved and carry the same traffic as the working path 🧚 selection between the traffic on the working and recovery paths happens at the path merge LSR (PML). Basically the PSL's job is reduced to setting up the working and recovery paths plus a simple replication function, and the recovery intelligence gets handed off to the PML 💅
In 1:1 ("one for one") protection, the resources (if any) allocated on the recovery path are fully available to preemptible low priority traffic, except when the recovery path is in use because of a fault on the working path 🍓 in other words, in 1:1 protection the protected traffic normally travels only on the working path, and only gets switched to the recovery path when the working path has a fault. Once the protection switch starts, the low priority traffic riding the recovery path may get displaced by the protected traffic. This is a way to make efficient use of the recovery path resources ✨
This concept can be extended to 1:n (one for n) and m:n (m for n) protection 🌈
3.4. Scope of Recovery 🌍
3.4.1 Topology
3.4.1.1 Local Repair
okay so the whole point of local repair is to protect against a link or neighbor node fault, and to keep the time it takes for the failure to propagate as short as possible ⏱️ in local repair (also known as local recovery), the node immediately upstream of the fault is the one that initiates recovery (either rerouting or protection switching). Local repair can be one of two types:
Link Recovery/Restoration: in this case, the recovery path may be configured to route around a certain link that's deemed unreliable 🔗 if protection switching is used, several recovery paths may be configured for one working path, depending on which specific faulty link each one protects against.
Alternatively, if rerouting is used, then when a fault happens on the specified link, each path gets rebuilt so it detours around the faulty link 🗺️
In this case the recovery path only needs to be disjoint from its working path at a particular link on the working path, and it may have overlapping segments with the working path 🦋 traffic on the working path gets switched over to an alternate path at the upstream LSR that connects to the failed link. Link recovery is potentially the fastest to perform the switchover, and it can be super effective when certain path components are way more unreliable than others 🔥
Node Recovery/Restoration: in this case, the recovery path may be configured to route around a neighbor node that's deemed unreliable 🙈 so the recovery path is disjoint from the working path only at a particular node, and at the links associated with the working path at that node. Once again, the traffic on the primary path gets switched over to the recovery path at the upstream LSR that directly connects to the failed node, and the recovery path shares overlapping portions with the working path 💜
3.4.1.2 Global Repair
okay the intent of global repair is to protect against any link or node fault on a path or on a segment of a path, with the obvious exception of faults occurring at the ingress node of the protected path segment 🌟 in global repair, the POR is usually far away from the failure, so it needs to be notified by a FIS 📨
in global repair too, end-to-end path recovery/restoration applies 💖 in lots of cases the recovery path can be made completely link and node disjoint from its working path. This has the advantage of protecting against all link and node fault(s) on the working path (end-to-end path or path segment) 👑
however, in some cases it may be slower than local repair, since the fault notification message has to travel all the way to the POR to trigger the recovery action 🐢
3.4.1.3 Alternate Egress Repair
it's possible to restore service without specifically recovering the faulted path 🫠
For example, for best effort IP service, it's possible to select a recovery path that has a different egress point from the working path (i.e., there is no PML) 🧭 the recovery path egress just has to be a router that's acceptable for forwarding the FEC carried by the working path (without creating looping). In an engineering context, specific alternative FEC/LSP mappings with alternate egresses can be formed 🛠️
This may make it simpler to enhance the reliability of implicitly constructed MPLS topologies 🌸 a PSL may qualify LSP/FEC bindings as candidate recovery paths as long as they're simply link and node disjoint with the immediate downstream LSR of the working path 🎀
3.4.1.4 Multi-Layer Repair
multi-layer repair gives network designers a bigger toolbox 🧰 for cases where multiple network layers can be managed together to hit overall network goals. Specific criteria for deciding when multi-layer repair is appropriate are beyond the scope of this document 🙃
3.4.1.5 Concatenated Protection Domains
a given service may cross multiple networks, and those networks may use different recovery mechanisms 🌐 it's possible to concatenate protection domains so service recovery can be provided end-to-end ✨ it's considered that the recovery mechanisms in different domains may operate autonomously, and that multiple points of attachment may be used between domains (to make sure there's no single point of failure) 🫶 alternate egress repair needs management of concatenated domains, because an explicit MPLS point of failure (the PML) is by definition excluded 🙅♀️ details of concatenated protection domains are beyond the scope of this document 💅
3.4.2 Path Mapping
path mapping refers to the methods of mapping traffic from a faulty working path onto the recovery path 🗂️ there are several options for this, as described below. Note that these options should be viewed as atomic terms that only describe how the working and protection paths are mapped to each other 🧩 the issues of resource reservation along these paths, and how switchover is actually performed, lead to the more commonly used composite terms, such as 1+1 and 1:1 protection, which were described in Section 4.3.1.. 🔍
1-to-1 Protection: in 1-to-1 protection, the working path has a designated recovery path that is only to be used to recover that specific working path 💖
n-to-1 Protection: in n-to-1 protection, up to n working paths are protected using only one recovery path. If the intent is to protect against any single fault on any of the working paths, the n working paths should be diversely routed between the same PSL and PML. In some cases, handshaking between PSL and PML may be required to complete the recovery, and the details of that are beyond the scope of this document 🤝
n-to-m Protection: in n-to-m protection, up to n working paths are protected using m recovery paths. Once again, if the intent is to protect against any single fault on any of the n working paths, the n working paths and the m recovery paths should be diversely routed between the same PSL and PML. In some cases, handshaking between PSL and PML may be required to complete the recovery, and the details of that are beyond the scope of this document. n-to-m protection is for further study 🔮
Split Path Protection: in split path protection, multiple recovery paths are allowed to carry the traffic of a working path based on a configurable load splitting ratio ⚖️ this is especially useful when no single recovery path can be found that can carry the entire traffic of the working path in case of a fault. Split path protection may require handshaking between the PSL and the PML(s), and may require the PML(s) to correlate the traffic arriving on multiple recovery paths with the working path 🧵 it's an attractive option, but the details of split path protection are beyond the scope of this document 🥹
3.4.3 Bypass Tunnels
sometimes it's convenient to create a "bypass tunnel" for a PPG between a PSL and PML, which lets multiple recovery paths stay transparent to intervening LSRs [RFC2702] 🚇 in this case, one LSP (the tunnel) is established between the PSL and PML following an acceptable route, and a number of recovery paths can be supported through the tunnel via label stacking. It's not necessary to apply label stacking when using a bypass tunnel 🫧 a bypass tunnel can be used with any of the path mapping options discussed in the previous section 💜
just like recovery paths, the bypass tunnel may or may not have resource reservations sufficient to provide recovery without service degradation 🤷♀️ it's possible the bypass tunnel has enough resources to recover some number of working paths, but not all at the same time. If the number of recovery paths carrying traffic in the tunnel at any given time is restricted, this is similar to the n-to-1 or n-to-m protection cases mentioned in Section 3.4.2 🌸
3.4.4 Recovery Granularity
another dimension of recovery looks at how much traffic actually needs protecting 🔎 this can range from a fraction of a path all the way up to a bundle of paths 🎀
3.4.4.1 Selective Traffic Recovery 🎀
okay so this option lets you protect just a fraction of the traffic on the same path 🧚 The slice of traffic on one path that actually needs protection is called a protected traffic portion (PTP). ngl this is so real, because a single path can carry different classes of traffic with different protection needs 💅 The protected part can be picked out by its class, like with the EXP bits in the MPLS shim header or the priority bit in the ATM header ✨
3.4.4.2 Bundling 🧺
Bundling is how you group a bunch of working paths together so they can be recovered at the same time 🫶 When several working paths need protection and they're all routed the exact same way between a PSL and a PML, that logical group is called a protected path group (PPG). If a fault hits the working path carrying the PPG, the whole PPG can be protected by switching it to a bypass tunnel or by switching it to a recovery path. main character energy for the whole group 👑
3.4.5 Recovery Path Resource Use 🌸
so for pre-reserved recovery paths there's a big question: what can those resources be used for when the recovery path isn't in use? there are two options 👀
Dedicated-resource: if the recovery path resources are dedicated, they may not be used for anything except carrying the working traffic. for example, with 1+1 protection, the working traffic is always carried on the recovery path. even if the recovery path isn't always carrying the working traffic, it may not be possible or desirable to let other traffic use these resources 🙈
Extra-traffic-allowed: if the recovery path only carries the working traffic when the working path fails, then it's possible to let extra traffic use the reserved resources at other times ✨ extra traffic is, by definition, traffic that can be displaced (without violating service agreements) whenever the recovery path resources are needed for carrying the working path traffic 🦋
Shared-resource: a shared recovery resource is dedicated for use by multiple primary resources that (according to SRLGs) are not expected to fail simultaneously 🧚
3.5. Fault Detection 🔍
okay here's the vibe: MPLS recovery gets kicked off after detecting either a lower layer fault, a fault at the IP layer, or a problem in the operation of MPLS-based mechanisms 💖 we look at four classes of impairments: Path Failure, Path Degraded, Link Failure, and Link Degraded.
Path Failure (PF) is a fault that tells an MPLS-based recovery scheme that the connectivity of the path is lost 💀 this may be detected by a path continuity test between the PSL and PML. some path failures, and probably the most common ones, may be detected using a link probing mechanism between neighbor LSRs. an example of a probing mechanism is a liveness message that gets exchanged periodically along the working path between peer LSRs [MPLS-PATH]. for either a link probing mechanism or a path continuity test to be effective, the test message must be guaranteed to follow the same route as the working or recovery path, over the segment being tested. the path continuity test must also take the path merge points into consideration 🌈 and for a bi-directional link implemented as two unidirectional links, a path failure could mean that either one or both unidirectional links are damaged 😭
Path Degraded (PD) is a fault that tells MPLS-based recovery schemes and mechanisms that the path has connectivity, but the quality of the connection is unacceptable 🥺 this may be detected by a path performance monitoring mechanism, or some other mechanism for determining the error rate on the path or some portion of the path. this is local to the LSR and consists of excessive discarding of packets at an interface, either due to label mismatch or due to TTL errors, for example 🫠
Link Failure (LF) is an indication from a lower layer that the link over which the path is carried has failed 🔥 if the lower layer supports detection and reporting of this fault (that is, any fault that indicates link failure, e.g., SONET LOS (Loss of Signal)), this may be used by the MPLS recovery mechanism. in some cases, using LF indications may provide faster fault detection than using only MPLS-based fault detection mechanisms ⭐
Link Degraded (LD) is an indication from a lower layer that the link over which the path is carried is performing below an acceptable level 🌸 if the lower layer supports detection and reporting of this fault, it may be used by the MPLS recovery mechanism. in some cases, using LD indications may provide faster fault detection than using only MPLS-based fault detection mechanisms 💜
3.6. Fault Notification 📣
MPLS-based recovery relies on rapid and reliable notification of faults 🚨 once a fault is detected, the node that detected it has to figure out whether it's severe enough to require path recovery. if the node can't start direct action itself (e.g., as a point of repair, POR), the node should send out a notification of the fault by transmitting a FIS to the POR. this can take several forms:
- (i) control plane messaging: relayed hop-by-hop along the path upstream of the failed LSP until a POR is reached.
- (ii) user plane messaging: sent downstream to the PML, which may take corrective action (as a POR for 1+1) or communicate with a POR upstream (for 1:n) by any of several means:
- control plane messaging
- user plane return path (either through a bi-directional LSP or via other means)
since the FIS is a control message, it should be transmitted with high priority so it propagates rapidly towards the affected POR(s) 🏃♀️ depending on how fault notification is configured in the LSRs of an MPLS domain, the FIS could be sent either as a Layer 2 or Layer 3 packet [MPLS-PATH]. using Layer 2-based notification requires a Layer 2 path direct to the POR. an example of a FIS could be the liveness message sent by a downstream LSR to its upstream neighbor, with an optional fault notification field set, or it can be implicitly denoted by a teardown message. alternatively, it could be a separate fault notification packet. the intermediate LSR should identify which of its incoming links to propagate the FIS on 🧚
3.7. Switch-Over Operation 🔄
3.7.1 Recovery Trigger ⚡
the activation of an MPLS protection switch after a fault is detected or notified needs a trigger mechanism at the PSL 💅 MPLS protection switching may be initiated due to automatic inputs or external commands. the automatic activation of an MPLS protection switch results from a response to a defect or fault conditions detected at the PSL, or to fault notifications received at the PSL. it's possible that the fault detection and trigger mechanisms may be combined, as is the case when a PF, PD, LF, or LD is detected at a PSL and triggers a protection switch to the recovery path. in most cases, though, the detection and trigger mechanisms are distinct: a fault is detected at some intermediate LSR, then a fault notification is propagated to the POR via the FIS, which serves as the protection switch trigger at the POR 🎀 MPLS protection switching in response to external commands happens when the operator initiates a protection switch with a command to a POR (or alternatively with a configuration command to an intermediate LSR, which transmits the FIS towards the POR).
note that the PF fault applies to hard failures (fiber cuts, transmitter failures, or LSR fabric failures), and so does the LF fault. the difference is that LF is a lower layer impairment that may be communicated to MPLS-based recovery mechanisms 🔌 the PD (or LD) fault, on the other hand, applies to soft defects (excessive errors due to noise on the link, for instance) 🌧️ PD (or LD) only results in a fault declaration when the percentage of lost packets exceeds a given threshold. that threshold is provisioned and may be set based on the service level agreement(s) in effect between a service provider and a customer 📝
3.7.2 Recovery Action 🛠️
after a fault is detected or a FIS is received by the POR, the recovery action involves either a rerouting or a protection switching operation ✨ in both scenarios, the next hop label forwarding entry for a recovery path is bound to the working path.
3.8. Post Recovery Operation 🦋
when traffic is flowing on the recovery path, decisions can be made about whether to let it stay there and treat it as a new working path, or to switch back to the old working path or to a new one 🔁 this post recovery operation has two styles. in one, the protection counterparts (the working and recovery paths) are fixed or "pinned" to their routes. in the other, the PSL or another network entity with real-time knowledge of the failure dynamically performs re-establishment or controlled rearrangement of the paths comprising the protected service 🧠
3.8.1 Fixed Protection Counterparts 📌
for fixed protection counterparts, the PSL will be pre-configured with the appropriate behavior to take when the original fixed path is restored to service. the choices are revertive and non-revertive mode 💖 the choice will typically depend on the relative costs of the working and protection paths, and on how well the service tolerates switching paths yet again. these protection modes indicate whether or not there is a preferred path for the protected traffic 👑
3.8.1.1 Revertive Mode 🔙
if the working path always is the preferred path, this path will be used whenever it's available 🌟 so in the event of a fault on this path, its unused resources won't be reclaimed by the network on failure. resources here may include assigned labels, links, bandwidth, etc. if the working path has a fault, traffic is switched to the recovery path. in revertive mode, when the preferred path is restored, the traffic is automatically switched back to it 🥰
there are a number of implications to pinned working and recovery paths:
- upon failure, and after traffic has been moved to the recovery path, the traffic is unprotected until the path defect in the original working path is repaired and that path is restored to service 🫣
- upon failure, and after traffic has been moved to the recovery path, the resources associated with the original path remain reserved 🧺
3.8.1.2 Non-revertive Mode 🦋
okay so in non-revertive mode there's either no preferred path, or it's just kinder to avoid shaking up the service again with a revertive switch 😭. Switching back to the original working path isn't wanted, or isn't even possible, because that original path might not exist anymore after a fault hit it 💀. If the working path faults, traffic gets switched over to the recovery path 🫶. When the faulty path (the one that was originally working) comes back, it can become the recovery path, either by configuration or, if you want, by management actions ✨.
the working traffic may or may not get restored to a new optimal working path, or to the original working path, anyway 💅. This is because it can be useful to (a) administratively do a protection switch back to the original working path after you've gotten more assurance about the integrity of the path, or (b) just keep running on the recovery path, which is totally acceptable, or (c) move the traffic to a new optimal working path that's calculated from network topology and network policies 🌈. Once a new working path has been defined, an associated recovery path may be set up 🎀.
3.8.2 Dynamic Protection Counterparts 🌸
For dynamic protection counterparts, when the traffic gets switched over to a recovery path, the association between the original working path and the recovery path may no longer exist, since the original path itself may be gone after the fault 🥺. Instead, once the network reaches a stable state following routing convergence, the recovery path may be switched over to a different preferred path. That can be based on optimization using the new network topology and associated information, or on pre-configured information 🧚.
Dynamic protection counterparts assume that upon failure, the PSL or other network entity will establish new working paths if another switch-over will be performed 👑.
3.8.3 Restoration and Notification 💜
MPLS restoration is all about returning the working traffic from the recovery path to the original or a new working path 🔥. It's performed by the PSL either when it gets notified, via FRS, that the working path is repaired, or when it gets notified that a new working path is established.
For fixed counterparts in revertive mode, an LSR that detected the fault on the working path also detects the restoration of that working path ✨. If the working path had experienced an LF defect, the LSR detects a return to normal operation when it receives a liveness message from its peer. If the working path had experienced an LD defect at an LSR interface, the LSR could detect a return to normal operation when error-free packet reception resumes on that interface. Alternatively, a lower layer that no longer detects an LF defect may inform the MPLS-based recovery mechanisms at the LSR that the link to its peer LSR is operational. Then the LSR transmits FRS to its upstream LSR(s) that were transmitting traffic on the working path 📣. When the PSL receives the FRS, it switches the working traffic back to the original working path 🦋.
A similar scheme is used for dynamic counterparts, where e.g., an update of topology and/or network convergence may trigger installation or setup of new working paths and may send notification to the PSL to perform a switch over 🌊.
We note that if there is a way to transmit fault information back along a recovery path towards a PSL, and if the recovery path is an equivalent working path, it is possible for the working path and its recovery path to exchange roles once the original working path is repaired following a fault 🔄. This is because, in that case, the recovery path effectively becomes the working path, and the restored working path functions as a recovery path for the original recovery path. This is important, since it affords the benefits of non-revertive switch operation outlined in Section 4.8.1, without leaving the recovery path unprotected 🛡️✨.
3.8.4 Reverting to Preferred Path (or Controlled Rearrangement) 🎀
In the revertive mode, "make before break" restoration switching can be used, which is less disruptive than performing protection switching when network impairments occur 💖. This minimizes both packet loss and packet reordering. The controlled rearrangement of paths can also be used to satisfy traffic engineering requirements for load balancing across an MPLS domain 🍓.
3.9. Performance 💅
Resource/performance requirements for recovery paths should be specified in terms of the following attributes:
- I. Resource Class Attribute:
- Equivalent Recovery Class: The recovery path has the same performance guarantees as the working path. In other words, the recovery path meets the same SLAs as the working path ✅.
- Limited Recovery Class: The recovery path does not have the same performance guarantees as the working path.
- A. Lower Class: The recovery path has lower resource requirements or less stringent performance requirements than the working path.
- B. Best Effort Class: The recovery path is best effort 🫠.
- II. Priority Attribute: The recovery path has a priority attribute just like the working path (i.e., the priority attribute of the associated traffic trunks). It can have the same priority as the working path or lower priority 🌟.
- III. Preemption Attribute: The recovery path can have the same preemption attribute as the working path or a lower one 💜.
4. MPLS Recovery Features ✨
The following features are desirable from an operational point of view 👑:
- I. It is desirable that MPLS recovery provides an option to identify protection groups (PPGs) and protection portions (PTPs).
- II. Each PSL should be capable of performing MPLS recovery upon the detection of the impairments or upon receipt of notifications of impairments.
- III. A MPLS recovery method should not preclude manual protection switching commands. This implies that it would be possible under administrative commands to transfer traffic from a working path to a recovery path, or to transfer traffic from a recovery path to a working path, once the working path becomes operational following a fault 🛠️.
- IV. A PSL may be capable of performing either a switch back to the original working path after the fault is corrected, or a switchover to a new working path, upon the discovery or establishment of a more optimal working path 🦋.
- V. The recovery model should take into consideration path merging at intermediate LSRs. If a fault affects the merged segment, all the paths sharing that merged segment should be able to recover. Similarly, if a fault affects a non-merged segment, only the path that is affected by the fault should be recovered 🧩.
5. Comparison Criteria 💅
okay so if we're gonna compare MPLS-based recovery schemes (and bestie, we absolutely are 🧚), these are the criteria on the table ✨
Recovery Time
recovery time is how long it takes for a recovery path to get activated and traffic flowing again after a fault 🫶 it's the sum of the Fault Detection Time, Hold-off Time, Notification Time, Recovery Operation Time, and the Traffic Restoration Time. in other words, it's the gap between a node or link failing and the moment a recovery path is installed and traffic is actually moving on it 🚀
Full Restoration Time
this one is for a permanent restoration 💖 it's the time until traffic gets routed onto links that can handle it, or that have been engineered well enough to handle it in recovery scenarios. ngl this might or might not match the Recovery Time, depending on whether equivalent or limited recovery paths are used 🤔
Setup vulnerability
the amount of time a working path (or a set of them) is left unprotected during stuff like recovery path computation and recovery path setup can be used to compare schemes 🔥 and the nature of that vulnerability should be taken into account, e.g., End to End schemes tie the vulnerability to working paths, Local Repair schemes have a topological correlation that cuts across working paths, and Network Plan approaches have a correlation that impacts the entire network 💀
Backup Capacity
recovery schemes may need differing amounts of "backup capacity" when a fault happens 🌸 that depends on the network's traffic characteristics, but it can also depend on the protection plan selection algorithms and the signaling and re-routing methods too 🎀
Additive Latency
recovery schemes may add latency for traffic 🐢 for example, a recovery path may take many more hops than the working path. this may depend on the recovery path selection algorithms 🧭
Quality of Protection
packet survivability is a whole spectrum, from "relative" to "absolute" 🌈 relative means the packet is on an equal footing with other traffic of, say, the same diff-serv code point (DSCP), when they're all fighting for resources in the part of the network that survives the failure. absolute means the survivability of the protected traffic has explicit guarantees 👑
Re-ordering
recovery schemes may introduce re-ordering of packets 🙈 and putting traffic back on preferred paths might cause re-ordering too 🌀
State Overhead
as the number of recovery paths in a protection plan grows, so does the state needed to maintain them 📈 schemes may need differing numbers of paths to maintain certain levels of coverage, and the state may depend on the particular scheme used for recovery. it may be a function of several parameters, like the number of recovery paths and the number of the protected facilities (links, nodes, or shared link risk groups (SRLGs)) 🧩
Loss
recovery schemes may introduce a certain amount of packet loss during switchover to a recovery path 😭 schemes that do can measure this loss by evaluating recovery times in proportion to the link speed. and in case of link or node failure, a certain packet loss is inevitable 💔
Coverage
recovery schemes can offer various types of failover coverage, and the total coverage can be defined with several metrics 🦋
I. Fault Types: recovery schemes may account for only link faults, or both node and link faults, or also degraded service. for example, a scheme may require more recovery paths to take node faults into account 🍓
II. Number of concurrent faults: depending on the layout of recovery paths in the protection plan, multiple fault scenarios may be able to be restored 🌟
III. Number of recovery paths: for a given fault, there may be one or more recovery paths 🧚
IV. Percentage of coverage: depending on a scheme and its implementation, a certain percentage of faults may be covered. this may be subdivided into percentage of link faults and percentage of node faults 📊
V. The number of protected paths may effect how fast the total set of paths affected by a fault could be recovered. the ratio of protection is n/N, where n is the number of protected paths and N is the total number of paths 💜
6. Security Considerations 🔐
the MPLS recovery specified here doesn't raise any security issues that aren't already present in the MPLS architecture 🛡️
confidentiality or encryption of information on the recovery path is outside the scope of this document, but any method designed to do this in other contexts may be used with the methods described in this document 🔒
7. Intellectual Property Considerations ⚖️
the IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. for more information, consult the online list of claimed rights 📜
8. Acknowledgements 🫶
big thanks to members of the MPLS WG mailing list for their suggestions on the earlier versions of this document 💕 in particular, Bora Akyol, Dave Allan, Dave Danenberg, Sharam Davari, and Neil Harrison, whose suggestions and comments were very helpful in revising the document ✨
the editors would like to give very special thanks to Curtis Villamizar for his careful and extremely thorough reading of the document and for taking the time to provide numerous suggestions, which were very helpful in the last couple of revisions 👑 thanks are also due to Adrian Farrel for a through reading of the last version of the document, and to Jean-Phillipe Vasseur and Anna Charny for several useful editorial comments and suggestions, and for input on bandwidth recovery 🌸
9. References 📚
9.1. Normative
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V. and G. Swallow, "RSVP-TE Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3212] Jamoussi, B. (Ed.), Andersson, L., Callon, R., Dantu,
R., Wu, L., Doolan, P., Worster, T., Feldman, N.,
Fredette, A., Girish, M., Gray, E., Heinanen, J.,
Kilty, T. and A. Malis, "Constraint-Based LSP Setup
using LDP", RFC 3212, January 2002.9.2. Informative
[MPLS-BACKUP] Vasseur, J. P., Charny, A., LeFaucheur, F., and
Achirica, "MPLS Traffic Engineering Fast reroute:
backup tunnel path computation for bandwidth
protection", Work in Progress.
[MPLS-PATH] Haung, C., Sharma, V., Owens, K., Makam, V. "Building
Reliable MPLS Networks Using a Path Protection
Mechanism", IEEE Commun. Mag., Vol. 40, Issue 3, March
2002, pp. 156-162.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.10. Contributing Authors 🌷
this document was the collective work of several individuals over a period of three years 🥰 the text and content were contributed by the editors and the co-authors listed below. (the contact information for the editors appears in Section 11, and isn't repeated below.)
Ben Mack-Crane
Tellabs Operations, Inc.
1415 West Diehl Road
Naperville, IL 60563
Phone: (630) 798-6197
EMail: Ben.Mack-Crane@tellabs.com
Srinivas Makam
Eshernet, Inc.
1712 Ada Ct.
Naperville, IL 60540
Phone: (630) 308-3213
EMail: Smakam60540@yahoo.com
Ken Owens
Edward Jones Investments
201 Progress Parkway
St. Louis, MO 63146
Phone: (314) 515-3431
EMail: ken.owens@edwardjones.com
Changcheng Huang
Carleton University
Minto Center, Rm. 3082
1125 Colonial By Drive
Ottawa, Ont. K1S 5B6 Canada
Phone: (613) 520-2600 x2477
EMail: Changcheng.Huang@sce.carleton.ca
Jon Weil
Brad Cain
Storigen Systems
650 Suffolk Street
Lowell, MA 01854
Phone: (978) 323-4454
EMail: bcain@storigen.com
Loa Andersson
EMail: loa@pi.se
Bilel Jamoussi
Nortel Networks
3 Federal Street, BL3-03
Billerica, MA 01821, USA
Phone:(978) 288-4506
EMail: jamoussi@nortelnetworks.com
Angela Chiu
AT&T Labs-Research
200 Laurel Ave. Rm A5-1F13
Middletown , NJ 07748
Phone: (732) 420-9061
EMail: chiu@research.att.com
Seyhan Civanlar
Lemur Networks, Inc.
135 West 20th Street, 5th Floor
New York, NY 10011
Phone: (212) 367-7676
EMail: scivanlar@lemurnetworks.com11. Editors' Addresses ✏️
Vishal Sharma (Editor)
Metanoia, Inc.
1600 Villa Street, Unit 352
Mountain View, CA 94041-1174
Phone: (650) 386-6723
EMail: v.sharma@ieee.org
Fiffi Hellstrand (Editor)
Nortel Networks
St Eriksgatan 115
PO Box 6701
113 85 Stockholm, Sweden
Phone: +46 8 5088 3687
EMail: fiffi@nortelnetworks.com12. Full Copyright Statement 📝
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is 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.
Acknowledgement 🌈
Funding for the RFC Editor function is currently provided by the Internet Society 💖
📦 where this page comes from
- ietf: rfc3469 2003-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms