RFC 4428
Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)
Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) 🦋
Okay so this is RFC 4428 🎀 It's an Informational doc from the Network Working Group, dated March 2006 📅 Its editors are D. Papadimitriou (Alcatel) and E. Mannie (Perceval) 💅 Informational means it's here to share knowledge with the Internet community, not to be a standard. Its header has no Obsoletes or Updates line, so it doesn't replace or change any other RFC. Clean! ✨
Table of Contents 📚
1. Introduction ....................................................3
2. Contributors ....................................................4
3. Conventions Used in this Document ...............................5
4. Fault Management ................................................5
4.1. Failure Detection ..........................................5
4.2. Failure Localization and Isolation .........................8
4.3. Failure Notification .......................................9
4.4. Failure Correlation .......................................11
5. Recovery Mechanisms ............................................11
5.1. Transport vs. Control Plane Responsibilities ..............11
5.2. Technology-Independent and Technology-Dependent
Mechanisms ................................................12
5.2.1. OTN Recovery .......................................12
5.2.2. Pre-OTN Recovery ...................................13
5.2.3. SONET/SDH Recovery .................................13
5.3. Specific Aspects of Control Plane-Based Recovery
Mechanisms ................................................14
5.3.1. In-Band vs. Out-Of-Band Signaling ..................14
5.3.2. Uni- vs. Bi-Directional Failures ...................15
5.3.3. Partial vs. Full Span Recovery .....................17
5.3.4. Difference between LSP, LSP Segment and
Span Recovery ......................................18
5.4. Difference between Recovery Type and Scheme ...............19
5.5. LSP Recovery Mechanisms ...................................21
5.5.1. Classification .....................................21
5.5.2. LSP Restoration ....................................23
5.5.3. Pre-Planned LSP Restoration ........................24
5.5.4. LSP Segment Restoration ............................25
6. Reversion ......................................................26
6.1. Wait-To-Restore (WTR) .....................................26
6.2. Revertive Mode Operation ..................................26
6.3. Orphans ...................................................27
7. Hierarchies ....................................................27
7.1. Horizontal Hierarchy (Partitioning) .......................28
7.2. Vertical Hierarchy (Layers) ...............................28
7.2.1. Recovery Granularity ...............................30
7.3. Escalation Strategies .....................................30
7.4. Disjointness ..............................................31
7.4.1. SRLG Disjointness ..................................32
8. Recovery Mechanisms Analysis ...................................33
8.1. Fast Convergence (Detection/Correlation and
Hold-off Time) ............................................34
8.2. Efficiency (Recovery Switching Time) ......................34
8.3. Robustness ................................................35
8.4. Resource Optimization .....................................36
8.4.1. Recovery Resource Sharing ..........................37
8.4.2. Recovery Resource Sharing and SRLG Recovery ........39
8.4.3. Recovery Resource Sharing, SRLG
Disjointness and Admission Control .................40
9. Summary and Conclusions ........................................42
10. Security Considerations .......................................43
11. Acknowledgements ..............................................43
12. References ....................................................44
12.1. Normative References .....................................44
12.2. Informative References ...................................44Status of This Memo 🌸
This memo gives information to the Internet community. It is not an Internet standard of any kind, and it doesn't specify one. Distribution of this memo is unlimited. 🫶
Copyright Notice ©️
Copyright (C) The Internet Society (2006). 💜
Abstract 🧚
Okay so this doc gives us an analysis grid to evaluate, compare, and contrast what the GMPLS (Generalized Multi-Protocol Label Switching) protocol suite can do against the recovery mechanisms being proposed at the IETF CCAMP Working Group 🔥 Each recovery phase gets a detailed analysis, using the terminology defined in RFC 4427. The big focus is transport plane survivability and recovery, NOT control plane resilience and related stuff 🙈
1. Introduction ✨
So this doc is basically an analysis grid to evaluate, compare, and contrast the GMPLS protocol suite capabilities with the recovery mechanisms proposed at the IETF CCAMP Working Group. The focus is on transport plane survivability and recovery, not on control-plane-resilience-related aspects. Although the recovery mechanisms here put different requirements on GMPLS-based recovery protocols, the protocols' specifications are not covered in this doc. 🦋
Even though the concepts are technology independent, this doc implicitly focuses on SONET [T1.105]/SDH [G.707], Optical Transport Networks (OTN) [G.709], and pre-OTN technologies. The exception is when specific details matter, like for failure detection. 💅
A detailed analysis is given for each recovery phase identified in [RFC4427]. These phases lay out the sequence of generic operations that need to happen when an LSP/Span failure (or any other event that causes one) occurs:
- Phase 1: Failure Detection
- Phase 2: Failure Localization (and Isolation)
- Phase 3: Failure Notification
- Phase 4: Recovery (Protection or Restoration)
- Phase 5: Reversion (Normalization)
Failure detection, localization, and notification are together called "fault management" 🔥 Inside a recovery domain, the entities involved in recovery operations are defined in [RFC4427], and they include ingress, egress, and intermediate nodes. 🎀
"Recovery mechanism" is the umbrella term covering both protection and restoration. The specific words "protection" and "restoration" only show up when you actually need to tell them apart. Same deal with "failure", which covers both signal failure and signal degradation. ✨
When analyzing the hierarchical recovery mechanisms (including the disjointness stuff), this doc makes a clear split between partitioning (horizontal hierarchy) and layering (vertical hierarchy). 👑 To check what the current GMPLS protocol capabilities can do and whether they need further extensions, the doc introduces the dimensions used to analyze each recovery mechanism. It wraps up by detailing how the current GMPLS protocol building blocks apply to recovery purposes. Iykyk, it's a whole plan 🧚
2. Contributors 🫶
Okay so this doc is the result of the CCAMP Working Group Protection and Restoration design team's joint effort. Besides the editors, these are the authors who contributed to the present memo 💖
Deborah Brungard (AT&T)
200 S. Laurel Ave.
Middletown, NJ 07748, USA
EMail: dbrungard@att.com
Sudheer Dharanikota
EMail: sudheer@ieee.org
Jonathan P. Lang (Sonos)
506 Chapala Street
Santa Barbara, CA 93101, USA
EMail: jplang@ieee.org
Guangzhi Li (AT&T)
180 Park Avenue,
Florham Park, NJ 07932, USA
EMail: gli@research.att.com
Eric Mannie
Perceval
Rue Tenbosch, 9
1000 Brussels
Belgium
Phone: +32-2-6409194
EMail: eric.mannie@perceval.net
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium
EMail: dimitri.papadimitriou@alcatel.be
Bala Rajagopalan
Microsoft India Development Center
Hyderabad, India
EMail: balar@microsoft.com
Yakov Rekhter (Juniper)
1194 N. Mathilda Avenue
Sunnyvale, CA 94089, USA
EMail: yakov@juniper.net3. Conventions Used in this Document 📖
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 [RFC2119]. Those are the official BCP 14 key words, so they carry real weight here 🔥
Any other recovery-related terminology used in this document conforms to what's defined in [RFC4427]. The reader is also assumed to be familiar with the terminology developed in [RFC3945], [RFC3471], [RFC3473], [RFC4202], and [RFC4204]. Do your homework bestie 📚
4. Fault Management 💅
4.1. Failure Detection
Okay so, transport failure detection is the ONE phase the control plane can't pull off by itself 😭 It needs a hook into the transport plane to get the info it needs. And even when the transport plane is the one that spots the failure, it has to tell the control plane what's up so the control plane can take the next steps. It does that through GMPLS signaling (see [RFC3471] and [RFC3473]) or through Link Management Protocol capabilities (see [RFC4204], Section 6). Main character handoff 💅
So by definition, transport failure detection depends on the transport technology 🦋 (which is why we're keeping the "transport plane" terminology here, just for this bit). In transport fault management, there's a difference between a defect and a failure. This section is about failure detection, which means a persistent fault cause. The technology-specific sections will get more precise 🧚
Let's look at SONET/SDH (see [G.707], [G.783], and [G.806]), which has supervision capabilities for:
- Continuity: SONET/SDH keeps an eye on whether a trail (a section or a path) is still continuous. It does this by checking whether the signal is there or not. Examples include Loss of Signal (LOS) detection at the physical layer, Unequipped (UNEQ) Signal detection at the path layer, and Server Signal Fail Detection (e.g., AIS) at the client layer.
- Connectivity: SONET/SDH checks that the signal is still routed correctly between the end-points. This matters when a layer offers flexible connectivity, whether that's automatic (like cross-connects) or manual (like a fiber distribution frame). An example is the Trail (section or path) Trace Identifier used at the different layers, along with the matching Trail Trace Identifier Mismatch detection.
- Alignment: SONET/SDH makes sure the client and server layer frame starts can still be recovered correctly. If that recovery is lost, it's detected as loss of alignment. How this works depends on the signal and frame structure, and it can involve (multi-)frame alignment, pointer processing, and aligning several independent frames to a common frame start when inverse multiplexing is in play. "Loss of alignment" is a catch-all term. Examples are loss of frame, loss of multi-frame, or loss of pointer.
- Payload type: SONET/SDH checks that compatible adaptation functions are being used at the source and the destination. Usually the source adds a payload type identifier (called the "signal label") at its adaptation function, and the destination compares it with the identifier it expects. For instance, the payload type identifier is compared with the corresponding mismatch detection.
- Signal Quality: SONET/SDH watches how well a signal is performing. If performance drops below a certain threshold, a defect is detected, either excessive errors (EXC) or degraded signal (DEG). 📉
The big takeaway is that these supervision processes, and the failure detection they feed (which kicks off the recovery phase or phases), end up as one of two things:
- Signal Degrade (SD): a signal saying the associated data has degraded, meaning a degraded defect condition is active. For example, a dDEG gets declared when the Bit Error Rate goes over a preset threshold. Or
- Signal Fail (SF): a signal saying the associated data has failed, meaning a signal interrupting near-end defect condition is active. This is different from the degraded defect. 💀
In Optical Transport Networks (OTN), you get similar supervision at the optical/digital section layers (Optical Transmission Section (OTS), Optical Multiplex Section (OMS), and Optical channel Transport Unit (OTU)) and at the optical/digital path layers (Optical Channel (OCh) and Optical channel Data Unit (ODU)). If you want the full details, go check the ITU-T Recommendations [G.798] and [G.709] 🤓
The examples above all show cases where the failure detecting and reporting entities (see [RFC4427]) live in the same place. The next example is different: those entities are NOT co-located. 🙈
In pre-OTN networks, an intermediate O-E-O based Optical Line System (OLS) can mask a failure, which stops a Photonic Cross-Connect (PXC) from seeing upstream failures. When that happens, an out-of-band communication channel can help with failure detection, and the failure condition can be reported to the PXC control plane. [RFC4209] extensions can do this by carrying IP message-based communication between the PXC and the OLS control plane. Also, PXCs don't care about the framing format, so failure conditions can only be triggered by detecting the absence of the optical signal or by measuring its quality. Those mechanisms are generally less reliable than electrical (digital) ones. Both types of detection are outside the scope of this document. If the intermediate OLS supports electrical (digital) mechanisms and uses the LMP communication channel, those failure conditions get reported to
the PXC, and the subsequent recovery actions are performed as described in Section 5. From the control plane's point of view, this makes the OLS-PXC combo a single logical entity, so it gets the same failure management mechanisms as any other O-E-O capable device. ✨
More generally, these are the typical failure conditions in SONET/SDH and pre-OTN networks:
- Loss of Light (LOL)/Loss of Signal (LOS): a Signal Failure (SF) condition where the optical signal is no longer detected on the receiver of a given interface.
- Signal Degrade (SD): detection of signal degradation over a specific period of time.
- For SONET/SDH payloads, all of the supervision capabilities above can be used, resulting in SD or SF conditions.
To wrap up, here's how the detecting and reporting entities can talk to each other:
- Co-located detecting and reporting entities: both are on the same node (for example SONET/SDH equipment, Opaque cross-connects, and, with some limitations, Transparent cross-connects).
- Non-co-located detecting and reporting entities: the entities are physically separated, but:
- with in-band communication between entities: the transport plane provides in-band communication between them (for example Server Signal Failures such as Alarm Indication Signal (AIS)).
- with out-of-band communication between entities: an out-of-band communication channel is provided between them (for example, using [RFCF4204]).
4.2. Failure Localization and Isolation
Failure localization tells the deciding entity where the transport plane entity that detected the LSP(s)/span(s) failure is (and so, who it is). With that info, the deciding entity can make a more accurate call and do finer-grained recovery switching action(s) 🎯 Quick note: this info can also be part of the failure notification (see Section 4.3).
Sometimes this accurate localization isn't urgent, so it can wait for more time-consuming failure isolation (see also Section 4.4). This is especially true when edge-to-edge LSP recovery runs off a simple failure notification (which includes the identification of the working LSPs that are under failure condition). "Edge" refers to a sub-network end-node, for instance. In that case, a more accurate localization and isolation can happen after those LSPs have recovered. 🌸
Failure localization should kick off right after the fault detection phase. It can happen at the transport plane and/or, if the transport plane can't do it, at the control plane level, where dedicated signaling messages can be used. When it's done at the control plane level, a protocol like LMP (see [RFC4204], Section 6) can be used for failure localization. 🫶
4.3. Failure Notification ✨
okay so failure notification has two jobs 💅. Job one is telling the intermediate nodes that an LSP/span failure has happened and been detected. Job two is telling the deciding entities (which can be any intermediate node or end-point of the failed LSP/span) that the service is not available 😭. These deciding entities are usually the ones making the right recovery call, and when they're co-located with the recovering entity, they also do the recovery action(s) 🎀.
Failure notification can come from either the transport plane or the control plane ✨. To give you an example, let's look at the failure notification mechanism at the SONET/SDH transport plane level first (also called maintenance signal supervision) 🦋:
- AIS (Alarm Indication Signal) shows up as a result of a failure condition like Loss of Signal, and it's used to notify downstream nodes (of the appropriate layer processing) that something broke 💀. AIS has two jobs: 1) it informs the intermediate nodes (with the appropriate layer monitoring capability) that a failure has been detected, and 2) it notifies the connection end-point that the service is no longer available 🥲.
For a distributed control plane that supports one (or more) failure notification mechanism(s), the same capabilities are needed no matter how the mechanism is actually implemented 🧚. The only difference is how much (or how little) information gets shared about the LSPs/spans under failure condition, their detailed statuses, and so on 📦.
The biggest difference between these mechanisms is that transport plane notifications (as defined today) would directly kick off a certain type of protection switching (like the ones in [RFC4427]) through the transport plane, or restoration actions through the management plane 👑.
Control plane notifications, on the other hand, give you the option to trigger either a protection or a restoration action through the control plane ✨. This is a big win because the control-plane-recovery-responsible entity doesn't have to be co-located with a transport maintenance/recovery domain 🌈. A control plane recovery domain can even be defined at entities that don't support transport plane recovery 🫶.
Also, as specified in [RFC3473], notification message exchanges through a GMPLS control plane may not follow the same path as the LSPs/spans they report on 🦋. This is what makes the whole thing fast, reliable (through acknowledgement and the use of either a dedicated control plane network or disjoint control channels), and efficient (through aggregating several LSP/span statuses within the same message) 🔥.
Other important properties the failure notification mechanism has to hit are mainly these 🎀:
- Notification messages must provide enough information so that the most efficient subsequent recovery action gets taken at the recovering entities (for most recovery types and schemes, this action is even deterministic) 💖. Remember that these entities can be either intermediate nodes or end-points that normal traffic flows through 🌸. Based on local policy, intermediate nodes may not use this information for subsequent recovery actions (see for instance the APS protocol phases as described in [RFC4427]) 🙈. Also, since fast notification is a mechanism running alongside the existing GMPLS signaling (see [RFC3473]), it lets intermediate nodes stay informed about the status of the working LSPs/spans under failure condition 👀.
The tricky part is deciding what information the LSP/span end-points (more precisely, the deciding entities) need so the recovering entity can take the best recovery action 😤. If not enough information is provided, the decision can't be optimal (and in that case, the key issue is quantifying how sub-optimal it is) 📉. If too much information is provided, the control plane may get overloaded with unnecessary information, and aggregating and correlating this notification information gets more complex and time-consuming 💀. A more detailed quantification of the amount of information to be exchanged and processed really depends on the failure notification protocol 🧠.
- If the failure localization and isolation aren't performed by one of the LSP/span end-points or some intermediate points, those points should receive enough information from the notification message to locate the failure 🗺️. Otherwise, they'd need to (re-)initiate a failure localization and isolation action 😩.
- Avoiding so-called notification storms means: 1) the failure detection output is correlated (i.e., alarm correlation) and aggregated at the node detecting the failure(s), 2) the failure notifications are directed to a restricted set of destinations (in general, the end-points), and 3) failure notification suppression (i.e., alarm suppression) is provided to limit flooding when multiple and/or correlated failures are detected at several locations in the network 🛑✨.
- Alarm correlation and aggregation (at the failure-detecting node) means making a consistent decision based on conditions where a trade-off between fast convergence (at the detecting node) and fast notification (which implies that correlation and aggregation happen at the receiving end-points) can be found 🎀.
4.4. Failure Correlation 🔗
A single failure event (like a span failure) can cause multiple failure conditions (like individual LSP failures) to get reported 💥. These can be grouped (i.e., correlated) to cut down the number of failure conditions sent over the reporting channel, for both in-band and out-of-band failure reporting 🧃.
In that kind of scenario, it can be important to wait for a certain period of time, typically called the failure correlation time, and gather all the failures so they can be reported as a group of failures (or simply a group failure) 🫧. For example, this can be done with LMP-WDM for pre-OTN networks (see [RFC4209]) or when using Signal Failure/Degrade Group in the SONET/SDH context 🌷.
Heads up: a default average time interval for failure correlation is hard to pin down, since it really depends on the underlying network topology 🗺️. So, providing a per-node configurable failure correlation time can be advisable 💅. The detailed selection criteria for this time interval are outside the scope of this document 🙈.
When failure correlation isn't provided, multiple failure notification messages may get sent out in response to a single failure (for instance, a fiber cut) 😵. Each failure notification message carries a set of information about the failed working resources (for instance, the individual lambda LSP flowing through this fiber) 🌈. This allows for a more prompt response, but it can potentially overload the control plane because of the huge number of failure notifications 📣.
5. Recovery Mechanisms 💖
5.1. Transport vs. Control Plane Responsibilities 👑
When it applies, recovery resources get provisioned for both protection and restoration using GMPLS signaling capabilities 🧚. So these are control plane-driven actions (topological and resource-constrained) that are always performed in this context 🫶.
The following tables give an overview of the responsibilities the control plane takes on for LSP/span recovery 📋:
1. LSP/span Protection
- Phase 1: Failure Detection Transport plane
- Phase 2: Failure Localization/Isolation Transport/Control plane
- Phase 3: Failure Notification Transport/Control plane
- Phase 4: Protection Switching Transport/Control plane
- Phase 5: Reversion (Normalization) Transport/Control planeNote: in the context of LSP/span protection, control plane actions can be performed for operational purposes, synchronization purposes (vertical synchronization between transport and control plane), and/or notification purposes (horizontal synchronization between end-nodes at the control plane level) 🔄. This suggests selecting the responsible plane (especially for protection switching) during the provisioning phase of the protected/protection LSP 💅.
2. LSP/span Restoration
- Phase 1: Failure Detection Transport plane
- Phase 2: Failure Localization/Isolation Transport/Control plane
- Phase 3: Failure Notification Control plane
- Phase 4: Recovery Switching Control plane
- Phase 5: Reversion (Normalization) Control planeSo this document mainly focuses on provisioning LSP recovery resources, failure notification mechanisms, recovery switching, and reversion operations 🎀. Some extra considerations are also dedicated to the mechanisms tied to the failure localization/isolation phase 🔍.
5.2. Technology-Independent and Technology-Dependent Mechanisms 🌸
This recovery mechanisms analysis applies to any circuit-oriented data plane technology with discrete bandwidth increments (like SONET/SDH, G.709 OTN, etc.) that's controlled by a GMPLS-based distributed control plane 🦋.
The following sub-sections aren't meant to favor one technology over another 🫶. They list the pros and cons of each technology so we can figure out which mechanisms GMPLS-based recovery needs to deliver to overcome the cons and make use of the pros in their respective applicability context ✨.
5.2.1. OTN Recovery 🧊
OTN recovery specifics are left for further consideration 🙈.
5.2.2. Pre-OTN Recovery 🌈
Pre-OTN recovery specifics (also referred to as "lambda switching") mainly have the following advantages 💅:
- They benefit from a simpler architecture, which makes them more suitable for mesh-based recovery types and schemes (on a per-channel basis) 🧩.
- Failure suppression at intermediate node transponders (e.g., the use of squelching) means that failures (such as LoL) will propagate to edge nodes 📡. So edge nodes get the chance to start recovery actions driven by upper layers (instead of using non-standard masking of upstream failures) 🙌.
The main disadvantage is the lack of interworking, due to the large number of failure management (in particular failure notification protocols) and recovery mechanisms currently available 😵💫.
Heads up, all-optical networks: combining recovery with optical physical impairments is left for a future release of this document, because the corresponding detection technologies are still under specification 🔮💀
5.2.3. SONET/SDH Recovery ✨
okay so SONET [T1.105] and SDH [G.707] are giving old-school reliability queen 👑, and so is TDM transport plane recovery in general. Here's why they're iconic 💅:
- Protection types work at the data plane level. They're standardized (see [G.841]), they can run across protected domains, and they can interwork (see [G.842]). 🫶
- They come with failure detection, failure notification, and path/section Automatic Protection Switching (APS) mechanisms. 🔥
- You get more control over granularity. You can recover the TDM LSPs/links themselves, not just the coarser optical channel (or the whole fiber content) through switching. 🎀
ngl there are some limitations too 😭
- Limited topological scope: SONET/SDH recovery usually leans on ring topologies, like dedicated Sub-Network Connection Protection (SNCP) or shared protection rings. That means less flexibility and less resource efficiency than meshed recovery, which is somewhat more complex but way more flexible. 🦋
- Inefficient use of spare capacity: SONET/SDH protection is mostly applied to rings, where spare capacity often just sits there idle. So bandwidth efficiency becomes a real issue. 💀
- Meshed recovery is a lot of work: supporting meshed recovery needs intensive network management development, and the functionality is capped by both the network elements and the capabilities of the element management systems. This is basically why GMPLS-based distributed recovery mechanisms got developed in the first place 🧚
5.3. Specific Aspects of Control Plane-Based Recovery Mechanisms 💜
5.3.1. In-Band vs. Out-Of-Band Signaling 🌸
the nodes talk to each other through IP terminating control channels, and those channels define the control plane (transport) topology. There are two classes of transport mechanism to think about here: in-fiber, or out-of-fiber. Out-of-fiber means a dedicated, physically diverse control network called the Data Communication Network (DCN). This section only looks at the impact of using in-fiber (signaling) transport.
in-fiber transport can be split again into in-band and out-of-band. So the difference between in-fiber in-band and in-fiber out-of-band signaling just comes down to whether the control plane topology is logically or physically embedded in the transport plane topology. For this document, we assume that at least one IP control channel between each pair of adjacent nodes is always available so recovery info and messages can get exchanged. Either way (in-band or out-of-band), at least one logical or physical control channel between each pair of nodes is always expected to be there 🍓
So the big question for in-fiber signaling is whether you can assume the control plane's fault tolerance is independent from the failures hitting the transport plane (nodes included). Existing specs like OTN do give a limited form of independence, though. They dedicate a separate optical supervisory channel (OSC, see [G.709] and [G.874]) to carry the overhead and other control traffic. In OTN, if the OSC fails, the optical channels don't fail with it. Same idea here: losing the control channel must not result in failing the data channels (transport plane). ✨
5.3.2. Uni- vs. Bi-Directional Failures 🦋
the failure detection, correlation, and notification mechanisms (described in Section 4) can kick in when a uni-directional or a bi-directional LSP/Span failure happens, or even a mix of both. Figures 1 and 2 show the two options:
- Uni-directional failure detection: the failure gets detected on the receiver side. That means only the downstream node to the failure detects it, or the upstream node does, depending on which way the failure propagates.
- Bi-directional failure detection: the failure gets detected on the receiver side of both the downstream node AND the upstream node to the failure. 💖
one thing to keep in mind: after the detection time, if you only have control-plane-based failure management, the peering node has no idea whether its neighbor detected the failure. 🙈
------- ------- ------- -------
| | | |Tx Rx| | | |
| NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
| |----...----| |---------| |----...----| |
------- ------- ------- -------
t0 >>>>>>> F
t1 x <---------------x
Notification
t2 <--------...--------x x--------...-------->
Up Notification Down Notification
Figure 1: Uni-directional failure detection ------- ------- ------- -------
| | | |Tx Rx| | | |
| NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
| |----...----| |xxxxxxxxx| |----...----| |
------- ------- ------- -------
t0 F <<<<<<< >>>>>>> F
t1 x <-------------> x
Notification
t2 <--------...--------x x--------...-------->
Up Notification Down Notification
Figure 2: Bi-directional failure detectiononce a failure is detected, these failure management steps can follow:
- Notify: each detecting entity sends a notification message to the transmitting entity it corresponds to. In Figure 1, node C sends a notification message to node B. In Figure 2, node C sends one to node B, and node B sends one to node C. For reliable failure notification, a dedicated acknowledgement message can be sent back to the sender node. 💌
- Correlate: within a certain (pre-determined) time window, the nodes hit by the failure can do their correlation. With uni-directional failure, node B only gets the notification from node C, so this step takes basically no time. With bi-directional failure, node B has to correlate the notification it got from node C with its own locally detected info, and node C has to do the same with the message from node B. 🧠
- Escalate: after some pre-determined period called the hold-off time, if the local recovery actions (see Section 5.3.4) weren't successful, this happens. For uni-directional failure, and depending on the LSP directionality, node B should send an upstream notification message (see [RFC3473]) to the ingress node A. Node C may send a downstream notification message (see [RFC3473]) to the egress node D. But in that case, only node A starts an edge-to-edge recovery action. Node A is the "master" and node D is the "slave", per [RFC4427]. The other LSP end-node (node D here) may optionally get notified with a downstream notification message (see [RFC3473]).
For bi-directional failure, node B should send an upstream notification message (see [RFC3473]) to the ingress node A. Node C may send a downstream notification message (see [RFC3473]) to the egress node D. Because it depends on LSP directionality, only the ingress node A starts an edge-to-edge recovery action. The other LSP end-node (node D here) should also be notified of this event using a downstream notification message (see [RFC3473]). Like, if an LSP directed from D to A is failing, only the notification from node C to D starts a recovery action. In that case, per [RFC4427], the deciding and recovering node D is the "master", and node A is the "slave" (the recovering-only entity). 🫠
Note: The determination of the master and the slave may be based either on configured information or dedicated protocol capability.
in all of these scenarios, the path taken by the upstream and downstream notification messages doesn't have to match the path the failed LSP used (see [RFC3473] for more on how notification messages get exchanged). The key point is this: either the detecting/reporting entity (nodes B and C) is also the deciding/recovering entity, or it's just an intermediate node in the recovery process that follows. The first case is called local recovery, and the second is called edge-to-edge recovery (see also Section 5.3.4). 💅
5.3.3. Partial vs. Full Span Recovery 🌈
when a span carries more than one LSP or LSP segment, there's one more thing to think about. If the span fails, the LSPs it carries can get recovered one at a time, as a group (aka bulk LSP recovery), or as independent sub-groups. If correlation time windows are in use and several LSPs can be recovered with one request, then picking this mechanism happens independently of the failure notification granularity. Also, how you form those sub-groups is outside the scope of this document. 🧚
sub-group LSP recovery gets messy. Between a given pair of nodes, the LSPs in one (sub-)group might have come from different source nodes (the initiators) and be heading toward different destination nodes. So after a bi-directional span failure that hits several LSPs (or the whole group they're in), the failure notification messages aren't necessarily going to the same initiator nodes. They might go to both the upstream and downstream nodes of the failure, which means recovery could kick off from both sides 😭
To make the recovery mechanisms (and their sequence) easier to define, this document assumes that, per [RFC4427], the deciding (and recovering) entity, which is the "master", is the only initiator of recovery for the whole LSP (sub-)group. Main character energy for the master, honestly 👑🎀
5.3.4. Difference between LSP, LSP Segment and Span Recovery 🦋
Okay bestie, the recovery definitions in [RFC4427] are super generic 🧠, and they apply to link (or local span) recovery and LSP recovery. The big difference between LSP, LSP Segment and span recovery is how many intermediate nodes the signaling messages have to travel through 🛣️. With LSP (or LSP Segment) recovery, the nodes aren't necessarily adjacent, so signaling exchanges going from the reporting entity to the deciding/recovery entity may have to cross several intermediate nodes. This is especially true for notification messages, because of how many hops sit between where a failure happens and where the message needs to end up. The result is an extra propagation and forwarding delay ⏳. The propagation delay can be non-negligible in some situations, e.g., in a copper out-of-band network it's about 1 ms per 200km 🐢.
Moreover, the recovery mechanisms for end-to-end LSPs and for the segments that can make up an end-to-end LSP (i.e., edge-to-edge recovery) can be exactly the same 💅. But in the latter case you'd expect the destination of the failure notification message to be the ingress/egress of each segment. So, using the mechanisms in Section 5.3.2, failure notification messages can be exchanged first between the terminating points of the LSP segment, and then, after the hold-off time expires, between the terminating points of the end-to-end LSP 🎀.
Note: Several studies provide quantitative analysis of the relative performance of LSP/span recovery techniques. [WANG] for instance, provides an analysis grid for these techniques showing that dynamic LSP restoration (see Section 5.5.2) performs well under medium network loads, but suffers performance degradations at higher loads due to greater contention for recovery resources. LSP restoration upon span failure, as defined in [WANG], degrades at higher loads because paths around failed links tend to increase the hop count of the affected LSPs and thus consume additional network resources. Also, performance of LSP restoration can be enhanced by a failed working LSP's source node initiating a new recovery attempt if an initial attempt fails. A single retry attempt is sufficient to produce large increases in the restoration success rate and ability to initiate successful LSP restoration attempts, especially at high loads, while not adding significantly to the long-term average recovery time. Allowing additional attempts produces only small additional gains in performance. This suggests using additional (intermediate) crankback signaling when using dynamic LSP restoration (described in Section 5.5.2 - case 2). Details on crankback signaling are outside the scope of this document.
5.4. Difference between Recovery Type and Scheme 🎨
[RFC4427] defines the basic LSP/span recovery types. This section describes the recovery schemes that can be built using these recovery types. In brief, a recovery scheme is defined as the combination of several ingress-egress node pairs supporting a given recovery type (from the set of recovery types they allow). Several examples are provided here to illustrate the difference between recovery types such as 1:1 or M:N, and recovery schemes such as (1:1)^n or (M:N)^n (referred to as shared-mesh recovery) 🧩.
1. (1:1)^n with recovery resource sharing
The exponent, n, indicates the number of times a 1:1 recovery type is applied between at most n different ingress-egress node pairs. Here, at most n pairs of disjoint working and recovery LSPs/spans share a common resource at most n times. Since the working LSPs/spans are mutually disjoint, simultaneous requests for use of the shared (common) resource will only occur in case of simultaneous failures, which are less likely to happen 🤞.
For instance, in the common (1:1)^2 case, if the 2 recovery LSPs in the group overlap the same common resource, then it can handle only single failures. Any multiple working LSP failures will cause at least one working LSP to be denied automatic recovery 😬. Consider for instance the following topology with the working LSPs A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and F-D-E-H that share a common D-E link resource.
A---------B---------C
\ /
\ /
D-------------E
/ \
/ \
F---------G---------H2. (M:N)^n with recovery resource sharing
The (M:N)^n scheme is documented here for the sake of completeness only (i.e., it is not mandated that GMPLS capabilities support this scheme) 📚. The exponent, n, indicates the number of times an M:N recovery type is applied between at most n different ingress-egress node pairs. So the interpretation follows from the previous case, except that here disjointness applies to the N working LSPs/spans and to the M recovery LSPs/spans, while sharing at most n times M common resources.
In both schemes, it results in a "group" of sum{n=1}^N N{n} working LSPs and a pool of shared recovery resources, not all of which are available to any given working LSP 🫧. In such conditions, defining a metric that describes the amount of overlap among the recovery LSPs would give some indication of the group's ability to handle simultaneous failures of multiple LSPs.
For instance, in the simple (1:1)^n case, if n recovery LSPs in a (1:1)^n group overlap, then the group can handle only single failures. Any simultaneous failure of multiple working LSPs will cause at least one working LSP to be denied automatic recovery. But if one considers, for instance, a (2:2)^2 group in which there are two pairs of overlapping recovery LSPs, then two LSPs (belonging to the same pair) can be simultaneously recovered 🙌. The latter case can be illustrated by the following topology with 2 pairs of working LSPs A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and F-D-E-H that share two common D-E link resources.
A========B========C
\\ //
\\ //
D =========== E
// \\
// \\
F========G========HMoreover, in all these schemes, (working) path disjointness can be enforced by exchanging information related to working LSPs during the recovery LSP signaling. Specific issues related to the combination of shared (discrete) bandwidth and disjointness for recovery schemes are described in Section 8.4.2 🔍.
5.5. LSP Recovery Mechanisms 🛠️
5.5.1. Classification 🗂️
The recovery time and ratio of LSPs/spans depend on proper recovery LSP provisioning (meaning pre-provisioning when performed before failure occurrence) and on the level of overbooking of recovery resources (i.e., over-provisioning). A proper balance of these two operations will result in the desired LSP/span recovery time and ratio when single or multiple failures occur. Note also that these operations are mostly performed during the network planning phases 🗓️.
The different options for LSP (pre-)provisioning and overbooking are classified below to structure the analysis of the different recovery mechanisms 💫.
1. Pre-Provisioning
Proper recovery LSP pre-provisioning will help to alleviate the failure of the working LSPs (due to the failure of the resources that carry these LSPs) 🛡️. As an example, one may compute and establish the recovery LSP either end-to-end or segment-per-segment, to protect a working LSP from multiple failure events affecting link(s), node(s) and/or SRLG(s). The recovery LSP pre-provisioning options are classified as follows, in the figure below:
(1) The recovery path can be either pre-computed or computed on-demand.
(2) When the recovery path is pre-computed, it can be either pre-signaled (implying recovery resource reservation) or signaled on-demand.
(3) When the recovery resources are pre-signaled, they can be either pre-selected or selected on-demand.
Recovery LSP provisioning phases:
(1) Path Computation --> On-demand
|
|
--> Pre-Computed
|
|
(2) Signaling --> On-demand
|
|
--> Pre-Signaled
|
|
(3) Resource Selection --> On-demand
|
|
--> Pre-SelectedNote that these different options lead to different LSP/span recovery times ⏱️. The following sections will consider the above-mentioned pre-provisioning options when analyzing the different recovery mechanisms.
2. Overbooking
There are many mechanisms available that allow the overbooking of the recovery resources 🍓. This overbooking can be done per LSP (as in the example mentioned above), per link (such as span protection), or even per domain. In all these cases, the level of overbooking, as shown in the below figure, can be classified as dedicated (such as 1+1 and 1:1), shared (such as 1:N and M:N), or unprotected (and thus restorable, if enough recovery resources are available).
Overbooking levels:
+----- Dedicated (for instance: 1+1, 1:1, etc.)
|
|
+----- Shared (for instance: 1:N, M:N, etc.)
|
Level of |
Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)Also, when using shared recovery, one may support preemptible extra-traffic. The recovery mechanism is then expected to allow preemption of this low-priority traffic in case of recovery resource contention during recovery operations 🌸. The following sections will consider the above-mentioned overbooking options when analyzing the different recovery mechanisms.
5.5.2. LSP Restoration ✨
Okay so here's the timing lineup 🕰️ We define these times so we can actually put numbers on how fast each LSP restoration mechanism is (aka LSP re-routing) 💅
- Path Computation Time:
Tc - Path Selection Time:
Ts - End-to-end LSP Resource Reservation Time:
Tr(a delta for resource selection is also considered, and the total time with it is calledTrs) - End-to-end LSP Resource Activation Time:
Ta(a delta for resource selection is also considered, and the total time with it is calledTas)
Ts only comes into play when a pool of recovery LSP paths between a given source/destination pair is already pre-computed. After a failure hits, you just pick one of those paths to rescue the LSP under failure 🦋
Note: ngl, failure management stuff like failure detection, correlation, and notification (for a given failure event) is treated as equally time-consuming for every mechanism below 🙈
1. With Route Pre-computation (or LSP re-provisioning)
An end-to-end restoration LSP gets set up after the failure(s) happen, based on a path that was already computed. So this one is basically an "LSP re-provisioning" mechanism 🎀 One or more (disjoint) paths for the restoration LSP get computed (and optionally pre-selected) before any failure happens.
No resources get reserved or selected along the restoration path before the failure occurs. So yeah, there's no guarantee a restoration LSP is available when things go wrong 😭
The expected total restoration time T is therefore Ts + Trs, or just Trs when a dedicated computation is done for each working LSP.
2. Without Route Pre-computation (or Full LSP re-routing)
An end-to-end restoration LSP is dynamically set up after the failure(s) happen. Once they do, one or more (disjoint) paths for the restoration LSP are computed on the spot and one gets picked. This is the full "LSP re-routing" mechanism, iconic behaviour 👑
Again, no resources are reserved or selected along the restoration path before the failure occurs, so there's no guarantee a restoration LSP is available when a failure happens 💀
The expected total restoration time T is therefore Tc (+ Ts) + Trs. The two approaches differ by the time needed for route computation Tc (plus its potential selection time, Ts) 🧚
5.5.3. Pre-Planned LSP Restoration 🌸
Pre-planned LSP restoration (also called pre-planned LSP re-routing) means the restoration LSP is pre-signaled. That means recovery resources get reserved along the restoration path. There are two cases depending on whether those recovery resources are pre-selected 🫶
1. With resource reservation and without resource pre-selection
Before failure occurrence, an end-to-end restoration path gets pre-selected from a set of pre-computed (disjoint) paths. The restoration LSP is signaled along this pre-selected path to reserve resources at each node, but those resources are not selected yet.
The resources reserved for each restoration LSP may be dedicated, or shared between multiple restoration LSPs whose working LSPs aren't expected to fail at the same time. Local node policies can set how far that sharing goes across independent failures. Also, since this is a restoration scheme, resource sharing should not be limited to restoration LSPs that start and end at the same ingress and egress nodes. So each node taking part in this scheme is expected to get some feedback on the sharing degree of the recovery resource(s) the scheme uses 🔥
When failure detection/notification messages come in, signaling starts along the restoration path to select the resources and do the right operation at each node crossed by the restoration LSP (e.g., cross-connections). If lower priority LSPs were using the restoration resources, they must be preempted when the restoration LSP gets activated 🫣
So the expected total restoration time T is Tas (post-failure activation), while the stuff done before the failure takes Tc + Ts + Tr.
2. With both resource reservation and resource pre-selection
Before failure occurrence, an end-to-end restoration path gets pre-selected from a set of pre-computed (disjoint) paths. The restoration LSP is signaled along this pre-selected path to reserve AND select resources at each node. These resources aren't committed at the data plane level yet. The selection only gets committed at the control plane level, so no cross-connections are performed along the restoration path 🧠
Here, the resources reserved and selected for each restoration LSP may be dedicated or even shared between multiple restoration LSPs whose associated working LSPs aren't expected to fail simultaneously. Local node policies can be applied to define how far that sharing goes across independent failures. And because a restoration scheme is in play, resource sharing should not be limited to restoration LSPs starting and ending at the same ingress and egress nodes. Each node in this scheme is expected to get some feedback on the sharing degree of the recovery resource(s) involved 💖
When failure detection/notification messages come in, signaling starts along the restoration path to activate the reserved and selected resources and do the right operation at each node crossed by the restoration LSP (e.g., cross-connections). If lower priority LSPs were using the restoration resources, they must be preempted when the restoration LSP is activated.
The expected total restoration time T is equal to Ta (post-failure activation), while the pre-failure work takes Tc + Ts + Trs. So the two approaches only differ by the time needed for resource selection during recovery LSP activation, which is Tas - Ta 🦋
5.5.4. LSP Segment Restoration 🧚
You can apply all of the above on an edge-to-edge LSP basis instead of end-to-end (to cut down the global recovery time) by letting individual LSP segments of the end-to-end LSP get recovered 🏃♀️
Also, using the horizontal hierarchy approach from Section 7.1, an end-to-end LSP can be recovered by multiple recovery mechanisms applied on a per-segment basis. For example, 1:1 edge-to-edge LSP protection in a metro network plus M:N edge-to-edge protection in the core. These mechanisms are ideally independent, and they may even use different failure localization and notification mechanisms 👑
6. Reversion 🔄
Reversion (a.k.a. normalization) is the mechanism that switches normal traffic from the recovery LSP/span back to the working LSP/span that was under failure condition. Whether you use normalization is up to the recovery domain policy. Depending on the normalization mechanism, it may impact the normal traffic (a second hit) 😬
If normalization is supported, then 1) the LSP/span must be returned to the working LSP/span when the failure condition clears, and 2) the ability to de-activate (turn off) reversion should be provided. De-activating reversion should not impact the normal traffic, whether it's currently using the working or recovery LSP/span 🌈
Note: while the failure is happening, reusing any non-failed resources (e.g., LSP and/or spans) that belong to the working LSP/span is up to the recovery domain policy.
6.1. Wait-To-Restore (WTR) ⏳
The Wait-To-Restore mechanism is there to stop frequent recovery switching caused by an intermittent defect (e.g., Bit Error Rate (BER) fluctuating around the SD threshold) 🙄
First, the LSP/span under failure condition has to become fault-free, e.g., a BER below a certain recovery threshold. Once the recovered LSP/span (i.e., the previously working LSP/span) meets that criterion, a fixed period of time shall elapse before normal traffic uses those resources again. This duration, called the Wait-To-Restore (WTR) period or timer, is generally on the order of a few minutes (for instance, 5 minutes) and should be capable of being set. The WTR timer may be either a fixed period, or give incrementally longer periods before retrying. An SF or SD condition on the previously working LSP/span will override the WTR timer value (i.e., the WTR cancels and the WTR timer restarts) 💅
6.2. Revertive Mode Operation 🎀
In revertive mode, when the recovery LSP/span is no longer needed (the failed working LSP/span is no longer in SD or SF condition), a local Wait-to-Restore (WTR) state gets activated before normal traffic switches back to the recovered working LSP/span ✨
While reversion is happening, this state becomes the highest priority, so signaling must maintain normal traffic on the recovery LSP/span instead of the previously failed working LSP/span. During this WTR state, any null traffic or extra traffic request (if applicable) gets rejected 🙅♀️
Still, the wait-to-restore timer can be deactivated (cancelled) if higher priority request attempts come in. In other words, the recovery LSP/span usage by normal traffic may be preempted if a higher priority request for that recovery LSP/span is attempted 🫣
6.3. Orphans 👻
When a reversion operation is requested, normal traffic must be switched from the recovery to the recovered working LSP/span. A tricky situation happens when the previously working LSP/span can't be recovered, so normal traffic can't switch back. In that case, the LSP/span under failure condition (also called an "orphan") must be cleared (i.e., removed) from the pool of resources allocated for normal traffic. Otherwise, the control and transport plane resource usage can get de-synchronized. Depending on the signaling protocol's capabilities and behaviour, different mechanisms are expected here 🧐
So any reserved or allocated resources for the LSP/span under failure condition must be unreserved/de-allocated. There are several ways to do that: wait for the clear-out time interval to elapse, initiate a deletion from the ingress or the egress node, or trigger deletion from an entity (such as an EMS or NMS) that can react when it gets an appropriate notification message 🌸
7. Hierarchies ✨
okay so recovery mechanisms are showing up at multiple (if not all) transport layers inside so-called "IP/MPLS-over-optical" networks 🌈 but each layer has its own recovery features, so we need to figure out exactly how they interact with each other 💅
Hierarchies are how we build big, scalable, complicated systems 🧚. You hide the messy internal details (that's abstraction, bestie 🫶), and you can use it to build huge networks or to enforce technology, topological, or administrative boundaries. The same hierarchical idea works for network survivability too 🛡️ Survivability is the set of capabilities that let a network restore affected traffic when something fails, and it's defined further in [RFC4427]. In general, the recovery action should be taken by the recoverable LSP/span closest to the failure, so we don't end up multiplying recovery actions everywhere 🙅♀️ Recovery hierarchies can also be tied to control plane logical partitions (e.g., administrative or topological boundaries), and each logical partition may apply different recovery mechanisms 🎀
Here's the main vibe: it's commonly accepted that lower layers give coarse but faster recovery, while higher layers give finer but slower recovery ⚡ It's also desirable to avoid similar layers with functional overlaps, because repeating the same capabilities at each layer doesn't add any value for the network as a whole, and it just wastes resources and processing overhead 💸 Even if a lower layer recovery mechanism is enabled, that doesn't stop you from also provisioning a recovery mechanism at the upper layer. The reverse isn't necessarily true, though: enabling an upper layer recovery mechanism may prevent the use of a lower layer recovery mechanism 👀 This section analyzes these hierarchical aspects, including the physical (passive) layer(s) 🦋
7.1. Horizontal Hierarchy (Partitioning)
A horizontal hierarchy happens when you partition a single-layer network (and its control plane) into several recovery domains 🍓 Inside a domain, the recovery scope can extend over a link (or span), an LSP segment, or even an end-to-end LSP. An administrative domain can also be a single recovery domain, or it can be split up into several smaller recovery domains. The operator can partition the network based on physical network topology, control plane capabilities, or various traffic engineering constraints 🗺️
An example that shows up a lot in the literature is the metro-core-metro application (sometimes extended to a metro-metro/core-core) within a single transport layer (see Section 7.2) 🏙️ For that case, there's an end-to-end LSP between the ingress and egress metro nodes, while LSP segments can be defined within the metro or core sub-networks. Each of these topological structures determines a so-called "recovery domain", since each LSP they carry can have its own recovery type (or even scheme) 💖 A sub-network that supports multiple recovery types and schemes is called a "multi-recovery capable domain" or simply "multi-recovery domain" ✨
7.2. Vertical Hierarchy (Layers)
Combining the different recovery capabilities available across the path (i.e., switching capable) and section layers is seriously hard 😭 but it's what you need to meet certain network survivability objectives for the services the network supports 💪
As a first analysis step, you can draw these guidelines for a vertical coordination of the recovery mechanisms 📝
- The lower the layer, the faster the notification and switching ⚡
- The higher the layer, the finer the granularity of the recoverable entity, and therefore the granularity of the recovery resource 🔍
In this analysis, a vertical hierarchy is made up of multiple layered transport planes that each provide different things 🧁
- Discrete bandwidth granularities for non-packet LSPs such as
OCh,ODUk,STS_SPE/HOVC, andVT_SPE/LOVCLSPs, and continuous bandwidth granularities for packet LSPs. - Potential recovery capabilities with different temporal granularities, ranging from milliseconds to tens of seconds ⏱️
Note: based on the bandwidth granularity, we can determine four classes of vertical hierarchies: (1) packet over packet, (2) packet over circuit, (3) circuit over packet, and (4) circuit over circuit. Below we briefly expand on (4) only. (2) is covered in [RFC3386]. (1) is extensively covered by the MPLS Working Group, and (3) by the PWE3 Working Group. 📚
In SONET/SDH environments, people typically treat the VT_SPE/LOVC and STS SPE/HOVC as independent layers. For example, a VT_SPE/LOVC LSP uses the underlying STS_SPE/HOVC LSPs as links 🔗 In OTN, the ODUk path layers sit on top of the OCh path layer, which means the ODUk LSPs use the underlying OCh LSPs as OTUk links 🌸 Lower layer LSPs may simply be provisioned, and they aren't necessarily triggered or established dynamically (control driven approach) 🙈 In this context, an LSP at the path layer (i.e., established using GMPLS signaling), such as an optical channel LSP, shows up at the OTUk layer as a link, and it's controlled by a link management protocol such as LMP 🎀
The first key issue with multi-layer recovery is that achieving individual or bulk LSP recovery is only as efficient as the underlying link (local span) recovery 🥺 In that case, the span can be either protected or unprotected, but the LSP it carries must be (at least locally) recoverable. So the span recovery process can either be independent when protected (or restorable), or be triggered by the upper LSP recovery process. The former case needs coordination to get subsequent LSP recovery working. So to get robustness and fast convergence, multi-layer recovery needs a finely tuned coordination mechanism 🎯
Also, if there isn't adequate recovery mechanism coordination (for instance, a pre-determined coordination using a hold-off timer), a failure notification can propagate from one layer to the next within a recovery hierarchy 😬 That can cause "collisions" and trigger simultaneous recovery actions, which can lead to race conditions. Those can reduce the optimization of resource utilization and/or cause global instabilities in the network (see [MANCHESTER]) 💀 So a consistent and efficient escalation strategy is needed to coordinate recovery across several layers 🫶
We can expect the definition of the recovery mechanisms and protocol(s) to be technology-independent, so they can be implemented consistently at different layers. That would make global coordination much simpler 🧩 Also, as mentioned in [RFC3386], some looser form of coordination and communication between (vertical) layers can be considered, such as a consistent hold-off timer configuration (set up through signaling during the working LSP establishment). That lets recovery actions be synchronized across these layers 🌈
7.2.1. Recovery Granularity
In most environments, the network design and the vertical distribution of the LSP bandwidth mean that the recovery granularity is finer at higher layers 🔍 The OTN and SONET/SDH layers can only recover the whole section or the individual connections they transport. The IP/MPLS control plane, on the other hand, can recover individual packet LSPs or groups of packet LSPs independently of their granularity 💅 Recovery granularity at the sub-wavelength level (i.e., SONET/SDH) can only be provided when the network includes devices switching at that same granularity, so it isn't possible at the optical channel level 🙃 Therefore, the network layer can deliver control-plane-driven recovery mechanisms on a per-LSP basis if and only if those LSPs have their corresponding switching granularity supported at the transport plane level 🔥
7.3. Escalation Strategies
There are two types of escalation strategies (see [DEMEESTER]): bottom-up and top-down 🧗♀️
The bottom-up approach assumes that lower layer recovery types and schemes are more expedient and faster than upper layer ones. So you can inhibit or hold off higher layer recovery 🙅♀️ But ngl, that assumption isn't entirely true. Take a SONET/SDH based protection mechanism (with a protection switching time of less than 50 ms) sitting on top of an OTN restoration mechanism (with a restoration time of less than 200 ms) 💀 So the assumption should (at least) be clarified like this: the lower layer recovery mechanism is expected to be faster than the upper level one, if the same type of recovery mechanism is used at each layer ✨
So, taking the recovery actions at the different layers into account in a bottom-up approach: if lower layer recovery mechanisms are provided and sequentially activated alongside higher layer ones, the lower layers must have an opportunity to recover normal traffic before the higher layers do 🫧 But if lower layer recovery is slower than higher layer recovery, the lower layer must either communicate the failure-related information to the higher layer(s) (and let it perform recovery), or use a hold-off timer to temporarily put the higher layer recovery action into a "standby mode" ⏸️ Note that the a priori information exchange between layers about their efficiency is not within the current scope of this document 📌 Still, the coordination functionality between layers must be configurable and tunable 🎛️
For example, coordination between the optical and packet layer control planes lets the optical layer handle the failure management operations (in particular, failure detection and notification), while giving the packet layer control plane the authority to decide and perform the recovery actions 👑 If the packet layer recovery action is unsuccessful, fallback at the optical layer can happen afterwards 🌙
The top-down approach tries service recovery at the higher layers before invoking lower layer recovery 🔝 Higher layer recovery is service selective, and it permits "per-CoS" or "per-connection" re-routing 🎀 With this approach, the most important thing is that the upper layer provides its own reliable and independent failure detection mechanism, separate from the lower layer 🫶
[DEMEESTER] also suggests recovery mechanisms with a coordinated effort shared by two adjacent layers, with periodic status updates 🤝 Some of these recovery operations can also be pre-assigned (on a per-link basis) to a certain layer. For instance, one link will be recovered at the packet layer while another will be recovered at the optical layer 🦋
7.4. Disjointness
Having link and node diverse working and recovery LSPs/spans does not guarantee their complete disjointness 🙀 Because of the common physical layer topology (passive), additional hierarchical concepts like the Shared Risk Link Group (SRLG), and mechanisms like SRLG diverse path computation, must be developed to provide complete working and recovery LSP/span disjointness (see [IPO-IMP] and [RFC4202]) 🧠 Otherwise, a failure affecting the working LSP/span could also affect the recovery LSP/span, and that's what we call a "common failure" 💔
7.4.1. SRLG Disjointness 🫶
okay so an SRLG (Shared Risk Link Group) is basically a set of links that all share the same risk 💀 like a common physical resource, think a fiber link or a fiber cable. fr fr, if a bunch of links L are all provisioned over the same fiber link f, then they all belong to the same SRLG s. it's giving shared fate 🧚
here are the SRLG properties, bestie:
- A link belongs to more than one SRLG if and only if it crosses one of the resources covered by each of them.
- Two links belonging to the same SRLG can belong individually to (one or more) other SRLGs.
- The SRLG set S of an LSP is defined as the union of the individual SRLG s of the individual links composing this LSP.
SRLG disjointness also applies to LSPs, and this is the part I'm obsessed with 😭 the whole concept rests on one postulate: an LSP (i.e., a sequence of links and nodes) covers an SRLG if and only if it crosses one of the links or nodes belonging to that SRLG.
so the SRLG disjointness for LSPs works like this: two LSPs are disjoint with respect to an SRLG s if and only if they do not cover this SRLG s at the same time 🌸
and with a whole set S of SRLGs, two LSPs are disjoint with respect to S if and only if the set of SRLGs that are common to both LSPs is disjoint from set S 💅
now the impact on recovery is honestly noticeable ✨ SRLG disjointness is a necessary (but not a sufficient) condition to ensure network survivability. so it's required, but it's not the whole story, periodt. when it comes to physical network resources, a working-recovery LSP/span pair must be SRLG-disjoint in case of dedicated recovery type. on the other hand, with shared recovery, a group of working LSP/spans must be mutually SRLG-disjoint, so that there can be a single common shared recovery LSP that is itself SRLG-disjoint from each of the working LSPs/spans. main character energy of planning, honestly 👑
8. Recovery Mechanisms Analysis 🔥
okay so to analyze the recovery mechanisms we covered in the earlier sections in a structured way, we can look at these five dimensions:
- Fast convergence (performance): a mechanism that aggregates multiple failures (which implies fast failure detection and correlation mechanisms) and makes the recovery decision fast, no matter how many failures are happening in the optical network (this also implies a fast failure notification).
- Efficiency (scalability): minimize the switching time needed for LSP/span recovery, no matter how many LSPs/spans are being recovered (this implies efficient failure correlation, fast failure notification, and time-efficient recovery mechanisms).
- Robustness (availability): minimize the LSP/span downtime no matter what the underlying topology of the transport plane looks like (this implies a highly responsive recovery mechanism).
- Resource optimization (optimality): minimize the resource capacity, including LSPs/spans and nodes (switching capacity), needed for recovery; this one can also be called optimizing the sharing degree of the recovery resources 🍓
- Cost optimization: provide a cost-effective recovery type or scheme 💜
ngl these dimensions are either outside the scope of this document (like cost optimization and recovery path computational aspects) or they clash with each other 🙈 for example, it's obvious that 1+1 LSP protection minimizes the LSP downtime when something fails, but it's non-scalable and it eats recovery resources without enabling any extra traffic. literally the classic tradeoff 💀
the following sections analyze the recovery phases and mechanisms from the previous sections against the dimensions above, so we can figure out what the GMPLS protocol suite can do and where it fits. and from there, we can judge whether we need any further GMPLS signaling and routing extensions 🦋
8.1. Fast Convergence (Detection/Correlation and Hold-off Time) 🌈
fast convergence is all about the failure management operations 🫶 it covers the time between failure detection/correlation and the hold-off time, which is the point where the recovery switching actions get kicked off. we went through this point back in Section 4.
8.2. Efficiency (Recovery Switching Time) ⚡
in general, the more pre-assignment/pre-planning you do for the recovery LSP/span, the faster the recovery is. since protection means pre-assigning (and cross-connecting) the protection resources, protection usually recovers faster than restoration 🏃♀️
span restoration is likely to be slower than most span protection types, though this really depends on how efficient the span restoration signaling is 🤔 LSP restoration with pre-signaled and pre-selected recovery resources is likely to be faster than fully dynamic LSP restoration, mostly because it gets rid of any potential crankback during recovery LSP establishment. no crankback = no drama 🙅♀️
if we leave crankback out of it, the difference between dynamic and pre-planned restoration comes down to how long the restoration path computation and selection takes. computational considerations are outside the scope of this document, so it's up to the vendor to decide the average and maximum path computation time in different scenarios, and up to the operator to decide whether dynamic restoration is worth it over pre-planned schemes, depending on the network environment. the difference also depends on how flexible pre-planned restoration is compared to dynamic restoration. pre-planned restoration covers a somewhat limited number of failure scenarios (which can be due to things like local storage capacity limits, for instance). dynamic restoration computes paths on demand based on the information received in a failure notification message, so it's more robust across the failure scenario scope 💖
and then there's LSP segment restoration. dynamic segment restoration (no path pre-computation, so none of the recovery resource is pre-reserved) will generally be faster than end-to-end LSP restoration 🚀 the catch is that local LSP restoration assumes each LSP segment end-point has enough computational capacity to do the operation, while end-to-end LSP restoration only requires that the LSP end-points provide this path computation capability. so it's a tradeoff, babe 💅
recovery time objectives for SONET/SDH protection switching (not including the time to detect the failure) are specified in [G.841] at 50 ms 🎀 they take into account constraints on distance, the number of connections involved, and, for ring enhanced protection, the number of nodes in the ring. recovery time objectives for restoration mechanisms have been proposed through a separate effort [RFC3386] 🧚
8.3. Robustness 🛡️
in general, the less pre-assignment (protection) or pre-planning (restoration) you have for the recovery LSP/span, the more robust the recovery type or scheme is against a variety of single failures, as long as there are adequate resources available 🍓 pre-selecting recovery resources also gives less flexibility than not pre-selecting them when multiple failures happen. for example, if failures hit two LSPs that share a common link along their restoration paths, only one of those LSPs can be recovered. unless the restoration path of at least one of them gets re-computed, or the local resource assignment gets modified on the fly, that's just how it goes 😭
also, recovery types and schemes with pre-planned recovery resources (in particular LSP/spans for protection and LSPs for restoration) can't recover from failures that hit both the working and the recovery LSP/span at the same time. so the recovery resources should ideally be as disjoint as possible (with respect to link, node, and SRLG) from the working ones, so that any single failure event won't affect both the working and recovery LSP/span. basically, working and recovery resources must be fully diverse to guarantee that one failure won't take out the working and the recovery LSP/span together 🫶 the risk of simultaneous failure of the working and recovery LSPs can also be reduced. one way is to compute a new recovery path whenever a failure happens along one of the recovery LSPs. another way is to compute a new recovery path and provision the matching LSP whenever a failure happens along a working LSP/span. both methods let the network keep the number of available recovery paths constant ✨
the robustness of a recovery scheme is also set by how many pre-reserved (i.e., signaled) recovery resources sit in a given shared resource pool. as the sharing degree of recovery resources goes up, the recovery scheme gets less robust against multiple LSP/span failures 🙈 for recovery schemes, especially restoration, with pre-signaled resource reservation (with or without pre-selection), it's a good idea to reserve enough resource to recover from any specific set of failure events, like any single SRLG failure, any two SRLG failures, and so on 🌈
8.4. Resource Optimization 💰
It's commonly admitted (everyone agrees, no cap) that sharing recovery resources gives you network resource optimization ✨. So from a resource utilization point of view, protection schemes get classified by how much they share recovery resources with the working entities. Non-permanent bridging protection types also let extra-traffic ride over the recovery resources under normal conditions 🫶.
From this angle, the following statements are true:
- 1+1 LSP/Span protection is the most resource-consuming protection type because it does not allow for any extra traffic. 💀
- 1:1 LSP/span recovery requires dedicated recovery LSP/span allowing for extra traffic.
- 1:N and M:N LSP/span recovery require 1 (and M, respectively) recovery LSP/span (shared between the N working LSP/span) allowing for extra traffic.
Obviously, 1+1 protection precludes sharing, and 1:1 recovery doesn't allow any recovery LSP/span sharing 😭. Meanwhile 1:N and M:N recovery do allow sharing of 1 (or M, respectively) recovery LSP/spans between N working LSP/spans 🎀. Here's the twist though: even though 1:1 LSP recovery precludes sharing the recovery LSP, the recovery schemes you can build from it (like (1:1)^n, see Section 5.4) do allow sharing of their recovery resources 👑. And the flexibility of shared recovery resources (especially shared links) can get limited by network topology restrictions, like the fixed ring topology used by traditional enhanced protection schemes 🧚.
Now, when you use LSP restoration with pre-signaled resource reservation, the amount of reserved restoration capacity is decided by the local bandwidth reservation policies 🍓. In LSP restoration schemes with re-provisioning, you can define a pool of spare resources, and after a failure, all the resources for restoration path computation get picked from that pool 🦋. How much sharing those restoration schemes allow across multiple independent failures is directly inferred from the size of that resource pool 📏. Spare resources can also carry preemptible traffic (so over preemptible LSP/span) in all restoration schemes, as long as those resources haven't been committed for LSP/span recovery purposes 🌈.
So it clearly follows that less recovery resources (LSP/spans and switching capacity) need to be allocated to a shared recovery resource pool when a greater sharing degree is allowed ✨. That means the network survivability level is determined by two things: the policy that defines the amount of shared recovery resources, and the maximum sharing degree allowed for them 💖.
8.4.1. Recovery Resource Sharing
When recovery resources are shared over several LSP/Spans, the Maximum Reservable Bandwidth, the Unreserved Bandwidth, and the Maximum LSP Bandwidth (see [RFC4202]) give you the info you need to optimize the network resources allocated for shared recovery 🔥.
The Maximum Reservable Bandwidth is defined as the Maximum Link Bandwidth, but it may be greater if the link is over-subscribed 🫧.
The Unreserved Bandwidth (at priority p) is the bandwidth not yet reserved on a given TE link. Its initial value for each priority p matches the Maximum Reservable Bandwidth 🌸. Last but not least, the Maximum LSP Bandwidth (at priority p) is the smaller of the Unreserved Bandwidth (at priority p) and the Maximum Link Bandwidth 💅.
Here, people generally consider a recovery resource sharing degree (or ratio) to globally optimize the shared recovery resource usage 🧠. The distribution of bandwidth utilization per TE link can be inferred from the per-priority bandwidth pre-allocation 📊. By using the Maximum LSP Bandwidth and the Maximum Reservable Bandwidth, the amount of (over-provisioned) resources that can be used for shared recovery is known from the IGP 🙌.
To analyze this behavior, we define the difference between the Maximum Reservable Bandwidth (in this case, a value greater than the Maximum Link Bandwidth) and the Maximum LSP Bandwidth per TE link i as the Maximum Shareable Bandwidth, or max_R[i]. Within that quantity, the bandwidth currently allocated for shared recovery per TE link i is defined as R[i]. Both quantities are expressed in discrete bandwidth units, so the Minimum LSP Bandwidth is one bandwidth unit 🎀.
You can exploit the info available per TE link to optimize the usage of the resources allocated per TE link for shared recovery 🦋. If r[i] is the actual bandwidth per TE link i (in discrete bandwidth units) committed for shared recovery, then the following quantity has to be maximized over the potential TE link candidates:
sum {i=1}^N [(R{i} - r{i})/(t{i} - b{i})]
or equivalently: sum {i=1}^N [(R{i} - r{i})/r{i}]
with R{i} >= 1 and r{i} >= 1 (in terms of per component
bandwidth unit)In this formula, N is the total number of links traversed by a given LSP, t[i] is the Maximum Link Bandwidth per TE link i, and b[i] is the sum per TE link i of the bandwidth committed for working LSPs and other recovery LSPs (so everything except "shared bandwidth" LSPs) 🧮. The quantity [(R{i} - r{i})/r{i}] is defined as the Shared (Recovery) Bandwidth Ratio per TE link i 💜. Also, TE links where R[i] reaches max_R[i], or where r[i] = 0, get pruned during shared recovery path computation. TE links where max_R[i] = r[i] get pruned too, since they simply can't be shared 🚫.
More generally, you can draw the following mapping between the available bandwidth at the transport and control plane level 🌈:
- ---------- Max Reservable Bandwidth
| ----- ^
|R ----- |
| ----- |
- ----- |max_R
----- |
-------- TE link Capacity - ------ | - Maximum TE Link Bandwidth
----- |r ----- v
----- <------ b ------> - ---------- Maximum LSP Bandwidth
----- -----
----- -----
----- -----
----- -----
----- ----- <--- Minimum LSP Bandwidth
-------- 0 ---------- 0Note that this approach doesn't require flooding any per LSP info, or any detailed distribution of bandwidth allocation per component link or individual ports, or even any per-priority shareable recovery bandwidth info (using a dedicated sub-TLV) 🙅♀️. That last one would give you the same capability as the already defined Maximum LSP bandwidth per-priority info. This approach is called Partial (or Aggregated) Information Routing, as described in [KODIALAM1] and [KODIALAM2]. They show that the difference compared to Full (or Complete) Information Routing (where, for the whole set of working and recovery LSPs, the amount of bandwidth units they use per link is known at each node and for each link) is clearly negligible 🤏. The Full Information Routing approach is detailed in [GLI]. And both approaches rely on deterministic knowledge (to different degrees) of the network topology and resource usage status 🧐.
Moreover, extending the GMPLS signaling capabilities can enhance Partial Information Routing 💫. This works by allowing working-LSP-related info, in particular its path (including link and node identifiers), to be exchanged with the recovery LSP request. That enables more efficient admission control at upstream nodes for shared recovery resources, and in particular for links (see Section 8.4.3) 🫶.
8.4.2. Recovery Resource Sharing and SRLG Recovery
Resource shareability can also be maximized with respect to how many times each SRLG is protected by a recovery resource (in particular, a shared TE link). Methods can also be considered for avoiding contention of shared recovery resources when a single SRLG fails 🛡️. These methods let two (or more) recovery LSPs share recovery resources, as long as their respective working LSPs are mutually disjoint with respect to link, node, and SRLGs. That way, a single failure doesn't take out several (or at least two) working LSPs at once 🙌.
For instance, [BOUILLET] shows that Partial Information Routing can be extended to cover recovery resource shareability with respect to SRLG recoverability (meaning how many times each SRLG is recoverable) ✨. By flooding this aggregated info per TE link, path computation and selection of SRLG-diverse recovery LSPs can be optimized with respect to the sharing of recovery resource reserved on each TE link 📈. The performance difference is less than 5%, which is negligible compared to the corresponding Full Information Flooding approach (see [GLI]) 🥰.
For this purpose, extensions to [RFC4202] to support path computation for shared mesh recovery have often been considered in the literature 📚. TE link attributes would include, among others, the current number of recovery LSPs sharing the recovery resources reserved on the TE link, and the current number of SRLGs recoverable by that amount of (shared) recovery resources. The latter is equivalent to the current number of SRLGs that will be recovered by the recovery LSPs sharing the recovery resource reserved on the TE link 🧩. If explicit SRLG recoverability is considered, a TE link attribute would be added that includes the explicit list of SRLGs (recoverable by the shared recovery resource reserved on the TE link) and their respective shareable recovery bandwidths. That info is equivalent to the shareable recovery bandwidth per SRLG (or per group of SRLGs), which means the amount of shareable bandwidth and the number of listed SRLGs will decrease over time ⏳.
Compared to recovery resource sharing alone (regardless of SRLG recoverability, as described in Section 8.4.1), these additional TE link attributes could potentially deliver better path computation and selection (at a distinct ingress node) for shared mesh recovery 🔍. However, due to the lack of evidence of better efficiency, and due to the complexity these extensions would generate, they aren't considered further in the scope of this analysis 🙈. For instance, a per-SRLG group minimum/maximum shareable recovery bandwidth is restricted by the length the corresponding (sub-)TLV may take, and thus by the number of SRLGs it can include. Therefore, that parameter should not be translated into GMPLS routing (or even signaling) protocol extensions in the form of a TE link sub-TLV 🚧.
8.4.3. Recovery Resource Sharing, SRLG Disjointness and Admission Control ✨
okay bestie, admission control is a strict requirement 💅 Nodes that give access to shared links have to fulfill it, no cap. Here's a picture of what that looks like:
A ------ C ====== D
| | |
| | |
| B |
| | |
| | |
------- E ------ FSo node A creates a working LSP to D (A-C-D). At the same time, B creates a working LSP to D (B-C-D) and also a recovery LSP to the same destination (B-E-F-D) 🦋. Then A decides it wants a recovery LSP to D too (A-E-F-D). But the C-D span is already carrying both working LSPs, so node E has two options. It can either assign a dedicated resource for this recovery LSP, or it can reject the request if the C-D span has already hit its maximum recovery bandwidth sharing ratio. If E goes with the second option, then a C-D span failure would mean one of the working LSPs wouldn't be recoverable. Yikes 😭
That's why node E must have the info it needs to do admission control on the recovery LSP requests it handles. For example, the path the working LSP takes has to be carried along with the matching recovery LSP request. If node E can guarantee that the working LSPs (A-C-D and B-C-D) are SRLG disjoint over the C-D span, then it may safely accept the incoming recovery LSP request and give the recovery LSPs (A-E-F-D and B-E-F-D) the same resources on the link E-F 🧚. This can happen when the link E-F hasn't hit its maximum recovery bandwidth sharing ratio yet. In this example, we're assuming the node failure probability is negligible compared to the link failure probability 🍓
Here's how it gets done. The path the working LSP follows gets sent along with the recovery LSP request, and every upstream node with potentially shareable links checks it. Admission control runs on the interface identifiers included in that path. Those identifiers are used to look up the SRLG IDs tied to each working LSP link in the TE DataBase. If the working LSPs (A-C-D and B-C-D) share one or more link or SRLG ID (in this case, one or more SRLG IDs over the C-D span), then node E should not assign the same resource on link E-F to the recovery LSPs (A-E-F-D and B-E-F-D). Otherwise, one of those working LSPs wouldn't be recoverable if the C-D span failed 💀
There are some issues with this method, and the big one is how many SRLG IDs a single link can cover. In complex environments, that number can be more than 100 🙈 Also, when link bundles are in play, this approach can end up rejecting some recovery LSP requests. That happens when the SRLG sub-TLV for a link bundle includes the union of the SRLG ID list of every component link in that bundle (see [RFC4202] and [RFC4201]).
To get past this specific problem, there's an extra mechanism that could work: query the nodes where the information is actually available. In this case, node E would query C. The catch is that this method, on top of the dedicated mechanism(s) it needs, can get really complicated when several common nodes are traversed by the working LSPs 🌀 So when link bundles are involved, fixing this is closely tied to the order of the recovery operations. Flooding SRLG identifiers per component would seriously hurt the scalability of the link state routing protocol. So the move is to rely on an online-accessible network management system instead 🫶
9. Summary and Conclusions ✨
Okay, here's the recap table of all the recovery types and schemes we went through in this document 📋
--------------------------------------------------------------------
| Path Search (computation and selection)
--------------------------------------------------------------------
| Pre-planned (a) | Dynamic (b)
--------------------------------------------------------------------
| | faster recovery | Does not apply
| | less flexible |
| 1 | less robust |
| | most resource-consuming |
Path | | |
Setup ------------------------------------------------------------
| | relatively fast recovery | Does not apply
| | relatively flexible |
| 2 | relatively robust |
| | resource consumption |
| | depends on sharing degree |
------------------------------------------------------------
| | relatively fast recovery | less faster (computation)
| | more flexible | most flexible
| 3 | relatively robust | most robust
| | less resource-consuming | least resource-consuming
| | depends on sharing degree |
--------------------------------------------------------------------1a. Recovery LSP setup (before failure occurrence) with resource reservation (i.e., signaling) and selection is referred to as LSP protection.
2a. Recovery LSP setup (before failure occurrence) with resource reservation (i.e., signaling) and with resource pre-selection is referred to as pre-planned LSP re-routing with resource pre-selection. This implies only recovery LSP activation after failure occurrence.
3a. Recovery LSP setup (before failure occurrence) with resource reservation (i.e., signaling) and without resource selection is referred to as pre-planned LSP re-routing without resource pre-selection. This implies recovery LSP activation and resource (i.e., label) selection after failure occurrence.
3b. Recovery LSP setup after failure occurrence is referred to as to as LSP re-routing, which is full when recovery LSP path computation occurs after failure occurrence.
So "pre-planned" is the word for recovery LSP path pre-computation, signaling (reservation), and a priori resource selection (optional), but it does not include cross-connection 💜 Also, the shared-mesh recovery scheme can be seen as a special case of 2a) and 3a), with the extra constraint described in Section 8.4.3 🌈
Implementing these recovery mechanisms only requires looking at extensions to GMPLS signaling protocols (i.e., [RFC3471] and [RFC3473]) ✨ Those GMPLS signaling extensions should mainly focus on delivering (1) recovery LSP pre-provisioning for cases 1a, 2a, and 3a, (2) LSP failure notification, (3) recovery LSP switching action(s), and (4) reversion mechanisms.
And the analysis in Section 8 shows that no GMPLS routing extensions are expected to efficiently implement any of these recovery types and schemes 👑
10. Security Considerations 🔐
This document doesn't add any new security issue, and it doesn't imply any specific security consideration from [RFC3945] for the current RSVP-TE GMPLS signaling, routing protocols (OSPF-TE, IS-IS-TE), or network management protocols 💅
But seriously, this part is important. Authorizing requests for resources by GMPLS-capable nodes should decide whether a given party, presumably already authenticated, has the right to access the requested resources. This is usually a matter of local policy control, for example by setting limits on the total bandwidth available to some party when resources are contested. These policies can get really complex as the number of users, types of resources, and sophistication of authorization rules goes up 😭 That's especially true for recovery schemes that assume pre-planned sharing of recovery resources, or for contention over resources during dynamic re-routing.
So control elements should match requests against the local authorization policy. These control elements must be able to make decisions based on the identity of the requester, as verified cryptographically and/or topologically 🔥
11. Acknowledgements 🫶
The authors want to thank Fabrice Poppe (Alcatel) and Bart Rousseau (Alcatel) for their revision work, and Richard Rabbat (Fujitsu Labs), David Griffith (NIST), and Lyndon Ong (Ciena) for their helpful comments 🌸
Thanks also to Adrian Farrel for the thorough review of the document 🎀
12. References 📚
12.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
- [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
- [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
- [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
- [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
- [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
- [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", RFC 4209, October 2005.
- [RFC4427] Mannie E., Ed. and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
12.2. Informative References 📚✨
okay so this is the reading list bit, bestie. these are the sources that give background and context, not the stuff you have to follow. 🤓 still, every single one is listed below exactly as the original has it. 💅
[BOUILLET] E. Bouillet, et al., "Stochastic Approaches to Compute
Shared Meshed Restored Lightpaths in Optical Network
Architectures," IEEE Infocom 2002, New York City, June
2002.
[DEMEESTER] P. Demeester, et al., "Resilience in Multilayer
Networks," IEEE Communications Magazine, Vol. 37, No. 8,
pp. 70-76, August 1998.
[GLI] G. Li, et al., "Efficient Distributed Path Selection for
Shared Restoration Connections," IEEE Infocom 2002, New
York City, June 2002.
[IPO-IMP] Strand, J. and A. Chiu, "Impairments and Other
Constraints on Optical Layer Routing", RFC 4054, May
2005.
[KODIALAM1] M. Kodialam and T.V. Lakshman, "Restorable Dynamic
Quality of Service Routing," IEEE Communications
Magazine, pp. 72-81, June 2002.
[KODIALAM2] M. Kodialam and T.V. Lakshman, "Dynamic Routing of
Restorable Bandwidth-Guaranteed Tunnels using Aggregated
Network Resource Usage Information," IEEE/ ACM
Transactions on Networking, pp. 399-410, June 2003.
[MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The
Evolution of Transport Network Survivability," IEEE
Communications Magazine, August 1999.
[RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and
Multilayer Survivability", RFC 3386, November 2002.
[T1.105] ANSI, "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, and
Formats," ANSI T1.105, January 2001.
[WANG] J. Wang, L. Sahasrabuddhe, and B. Mukherjee, "Path vs.
Subpath vs. Link Restoration for Fault Management in
IP-over-WDM Networks: Performance Comparisons Using
GMPLS Control Signaling," IEEE Communications Magazine,
pp. 80-87, November 2002.ITU stuff next, and the availability note is important here. 🌍 For information on the availability of the following documents, please see http://www.itu.int
[G.707] ITU-T, "Network Node Interface for the Synchronous
Digital Hierarchy (SDH)," Recommendation G.707, October
2000.
[G.709] ITU-T, "Network Node Interface for the Optical Transport
Network (OTN)," Recommendation G.709, February 2001 (and
Amendment no.1, October 2001).
[G.783] ITU-T, "Characteristics of Synchronous Digital Hierarchy
(SDH) Equipment Functional Blocks," Recommendation
G.783, October 2000.
[G.798] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional block," Recommendation
G.798, June 2004.
[G.806] ITU-T, "Characteristics of Transport Equipment -
Description Methodology and Generic Functionality",
Recommendation G.806, October 2000.
[G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841, October
1998.
[G.842] ITU-T, "Interworking of SDH network protection
architectures," Recommendation G.842, October 1998.
[G.874] ITU-T, "Management aspects of the optical transport
network element," Recommendation G.874, November 2001.Editors' Addresses 💌
The editors, and how to reach them 🫶
Dimitri Papadimitriou
Alcatel
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Eric Mannie
Perceval
Rue Tenbosch, 9
1000 Brussels
Belgium
Phone: +32-2-6409194
EMail: eric.mannie@perceval.netFull Copyright Statement ©️
Copyright (C) The Internet Society (2006). 🦋
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Here's the legal bit, and it matters, so it stays word for word 👇
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🔐
The IETF doesn't take a side on whether any intellectual property rights claimed for this technology are valid or how far they reach, and it doesn't say whether licenses for them are available. It also hasn't checked for any such rights itself. 🙈 Info on how rights work for RFC documents lives in BCP 78 and BCP 79.
Disclosures of IPR made to the IETF Secretariat, any assurances of licenses, and the results of any attempt to get a general license or permission for implementers or users can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF also invites anyone who knows about copyrights, patents, patent applications or other proprietary rights that might cover technology needed to implement this standard to tell them about it at ietf-ipr@ietf.org. 💜
Acknowledgement 🎀
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🌈
📦 where this page comes from
- ietf: rfc4428 2006-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms