RFC 4427
Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)
Hi bestie, RFC 4427 is here 🦋
Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) 🎀
Okay so this one is a Informational doc, which means it's giving "here's some info" and not "you must do this" 💅 It's from March 2006 and it was put together by the Network Working Group. The editors are E. Mannie (Perceval) and D. Papadimitriou (Alcatel), and they both got the Ed. credit because they're the ones who pulled it all together ✨ It doesn't obsolete anything and it doesn't update anything either. It's just a brand new glossary 🧚
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract 💜
This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS.
Table of Contents 📋
1. Introduction ....................................................3
2. Contributors ....................................................4
3. Conventions Used in this Document ...............................5
4. Recovery Terminology Common to Protection and Restoration .......5
4.1. Working and Recovery LSP/Span ..............................6
4.2. Traffic Types ..............................................6
4.3. LSP/Span Protection and Restoration ........................6
4.4. Recovery Scope .............................................7
4.5. Recovery Domain ............................................8
4.6. Recovery Types .............................................8
4.7. Bridge Types ..............................................10
4.8. Selector Types ............................................10
4.9. Recovery GMPLS Nodes ......................................11
4.10. Switch-over Mechanism ....................................11
4.11. Reversion operations .....................................11
4.12. Failure Reporting ........................................12
4.13. External commands ........................................12
4.14. Unidirectional versus Bi-Directional Recovery Switching ..13
4.15. Full versus Partial Span Recovery Switching ..............14
4.16. Recovery Schemes Related Time and Durations ..............14
4.17. Impairment ...............................................15
4.18. Recovery Ratio ...........................................15
4.19. Hitless Protection Switch-over ...........................15
4.20. Network Survivability ....................................15
4.21. Survivable Network .......................................16
4.22. Escalation ...............................................16
5. Recovery Phases ................................................16
5.1. Entities Involved During Recovery .........................17
6. Protection Schemes .............................................17
6.1. 1+1 Protection ............................................18
6.2. 1:N (N >= 1) Protection ...................................18
6.3. M:N (M, N > 1, N >= M) Protection .........................18
6.4. Notes on Protection Schemes ...............................19
7. Restoration Schemes ............................................19
7.1. Pre-Planned LSP Restoration ...............................19
7.1.1. Shared-Mesh Restoration ............................19
7.2. LSP Restoration ...........................................20
7.2.1. Hard LSP Restoration ...............................20
7.2.2. Soft LSP Restoration ...............................20
8. Security Considerations ........................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................20
10. Acknowledgements ..............................................211. Introduction 🌸
Okay so this doc is all about a shared vocab for GMPLS-based recovery (that's protection and restoration) 🫶 The terms don't care what transport tech is underneath, which is so iconic of them.
The terminology here is independent of the underlying transport technologies. It borrows from the G.808.1 ITU-T Recommendation [G.808.1] and from the G.841 ITU-T Recommendation [G.841]. The restoration terms and concepts were gathered from loads of sources, including IETF documents.
In this doc, "recovery" means both protection and restoration. The specific words "protection" and "restoration" only get used when we actually need to tell them apart 💅
This doc is focused on recovering Label Switched Paths (LSPs) that are controlled by a GMPLS control plane. The terms apply to end-to-end, segment, and span (i.e., link) recovery. Heads up though, recovering the control plane itself is not in scope here 🙈
Protecting and restoring switched LSPs under tight time constraints is honestly a hard problem. It matters most for optical networks made of Time Division Multiplex (TDM) and/or all-optical (photonic) cross-connects. Those are called GMPLS nodes (or just nodes, or sometimes "Label Switching Routers, or LSRs"), and they're connected in a general topology [RFC3945] ✨
Recovery usually means switching over to a recovery (or alternate) LSP when the working LSP runs into a failure 🦋
A working or recovery LSP is described by an ingress interface, an egress interface, and a set of intermediate nodes and spans that the LSP is routed through. The working and recovery LSPs are typically resource disjoint (e.g., node and/or span disjoint). That way, one single failure can't take out both of them 🔥
A bi-directional span between neighbouring nodes is usually made of a pair of unidirectional spans. So the end-to-end path for a bi-directional LSP is a chain of bi-directional segments (i.e., Sub-Network Connections, or SNCs, in ITU-T terms) between the source and destination nodes, going through the intermediate nodes ✨
2. Contributors 🫶
This doc is the result of a joint effort by the CCAMP Working Group Protection and Restoration design team. The authors who contributed to it are listed below, with their details exactly as they appear in the original:
Deborah Brungard (AT&T)
Rm. D1-3C22 - 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].
4. Recovery Terminology Common to Protection and Restoration 💖
This section defines some general terms that are shared by both protection and restoration (i.e., recovery). Most of these terms also apply to end-to-end, segment, and span LSP recovery. Just so you know, span recovery doesn't protect the nodes at each end of the span. If you need that, use end-to-end or segment LSP recovery instead 👑
The terms and definitions were originally taken from [G.808.1]. For generalization, though, the following language (which isn't directly about recovery) has been adapted to GMPLS and common IETF terminology:
An LSP is the generic term for either an SNC (Sub-Network Connection) or an NC (Network Connection) in ITU-T terminology. The ITU-T uses the term transport entity for a link, an SNC, or an NC. We say "Traffic" instead of "Traffic Signal", and "scheme" instead of "architecture" when we talk about protection or restoration 🧚
Want more on SDH protection and Generic Protection Switching terminology? Go read [G.841] and [G.808.1] respectively. Also, restoration isn't in the scope of [G.808.1], so keep that in mind 🙈
4.1. Working and Recovery LSP/Span ✨
A working LSP/span is one carrying "normal" user traffic. A recovery LSP/span is one that carries "normal" user traffic when the working LSP/span fails. The recovery LSP/span can also carry "extra" user traffic (i.e., pre-emptable traffic) while normal traffic is on the working LSP/span 🦋
4.2. Traffic Types 🌈
Here are the different types of traffic that can go over an LSP/span, in the context of this doc:
A. Normal traffic:
User traffic that may be protected by two alternative LSPs/spans (the working and recovery LSPs/spans).
B. Extra traffic:
User traffic carried over recovery resources (e.g., a recovery LSP/span) when those resources aren't being used to recover normal traffic (i.e., when the recovery resources are on standby). When the recovery resources are needed to recover normal traffic from the failed working LSP/span, the extra traffic gets pre-empted. Extra traffic isn't protected by definition, but it may be restored. Also, extra traffic doesn't have to start or end at the ends of the LSPs/spans it uses 💜
C. Null traffic:
Traffic carried over the recovery LSP/span when it isn't being used for normal or extra traffic. Null traffic can be any kind of traffic that conforms to the signal structure of the specific layer, and it gets ignored (not selected) at the egress of the recovery LSP/span. It's giving filler, but make it structured 💅
4.3. LSP/Span Protection and Restoration ✨
okay so bestie, "protection" and "restoration" get used like they mean the same thing all the time 😭 but there's a real difference, and [RFC3386] is where that's laid out. 🫶
the difference comes down to how much of the resource allocation happens before things break. for protection, it's decided when the recovery LSP/span gets set up. for restoration, it depends on how much route computation, signaling, and resource allocation happens during the restoration LSP/span setup. it's giving layers 💅
A. LSP/Span Protection
LSP/span protection is the setup where one or more dedicated protection LSP(s)/span(s) are fully set up ahead of time to protect one or more working LSP(s)/span(s). 👑
for a protection LSP, that means the route got computed, the LSP was fully signaled all the way through, and its resources were fully picked out (allocated) and cross-connected between the ingress and egress nodes. 🌸
for a protection span, it means the span has been chosen and reserved for protection. 🦋
so the big deal here is that no signaling happens to set up the protection LSP/span when a failure hits. the protection is already ready to go 🔥 that said, other kinds of signaling can still happen between the ingress and egress nodes, like for fault notification, to keep their use of the protection LSP/span in sync, for reversion, and so on. 💜
B. LSP/Span Restoration
LSP/span restoration is the setup where some restoration resources might get pre-computed, signaled, and selected ahead of time, but they're not cross-connected yet. the restoration LSP/span only gets fully set up after the working LSP/span fails, and that part needs some extra signaling. 🧚
so both protection and restoration need signaling. there's signaling to set up the recovery resources, and there's signaling for using the recovery LSP(s)/span(s) once they're needed. both are necessary, bestie 🫶
4.4. Recovery Scope
recovery can happen at different levels across the network 🌈 an LSP might get local (span), segment, and/or end-to-end recovery, depending on the setup.
local (span) recovery is when an LSP gets recovered over a link between two nodes. 🍓
end-to-end recovery is when the whole LSP gets recovered, from its source (the ingress node end-point) to its destination (the egress node end-point). ✨
segment recovery is when a segment LSP (what ITU-T calls an SNC) of an end-to-end LSP gets recovered over one part of the network. it protects against span and/or node failure over that particular stretch that the end-to-end LSP goes through. 🎀
4.5. Recovery Domain
a recovery domain is a set of nodes and spans where one or more recovery schemes are provided. when a recovery domain is served by one single recovery scheme, it's called a "single recovery domain". when it's served by multiple recovery schemes, it's called a "multi recovery domain". 💖
the recovery operation stays inside the recovery domain. a GMPLS recovery domain must be entirely contained within a GMPLS domain. and a GMPLS domain (a set of nodes and spans controlled by GMPLS) can hold multiple recovery domains. 🌸
4.6. Recovery Types
the different recovery types are sorted by how many recovery LSPs/spans are protecting a given number of working LSPs/spans. these definitions are from the point of view of one working LSP/span that needs protecting by a recovery scheme. 🦋
A. 1+1 type: dedicated protection
one dedicated protection LSP/span protects exactly one working LSP/span, and the normal traffic is permanently duplicated at the ingress node onto both the working and protection LSPs/spans. no extra traffic can ride on the protection LSP/span. 💅
this type works for LSP/span protection, but not for LSP/span restoration. 🙈
B. 0:1 type: unprotected
no specific recovery LSP/span protects the working LSP/span. still, the working LSP/span can potentially be restored over any other available route/span, with or without a pre-computed restoration route. just note that no resources are set up ahead of time for this recovery type. 🌈
this type works for LSP/span restoration, but not for LSP/span protection. for example, span restoration can be done by moving all the LSPs carried over a failed span onto a dynamically chosen span. 🧚
C. 1:1 type: dedicated recovery with extra traffic
one specific recovery LSP/span protects exactly one specific working LSP/span, but the normal traffic only goes over one LSP (working or recovery) at a time. extra traffic can be carried using the recovery LSP/span's resources. ✨
this type works for LSP/span protection and LSP restoration, but not for span restoration. 💜
D. 1:N (N > 1) type: shared recovery with extra traffic
one specific recovery LSP/span is dedicated to protecting up to N working LSPs/spans. the set of working LSPs/spans is explicitly identified. extra traffic can be carried over the recovery LSP/span. all of these LSPs/spans must start and end at the same nodes. 🎀
sometimes the working LSPs/spans are assumed to be resource disjoint in the network, so they don't share any failure probability, but that's not mandatory. obviously, if more than one working LSP/span in the set of N gets hit by a failure at the same time, only one of those failed LSPs/spans can have its traffic recovered over the recovery LSP/span. also, N can be arbitrarily large (i.e., infinite). choosing N is a policy decision 👑
this type works for LSP/span protection and LSP restoration, but not for span restoration. 🫶
Note: a shared recovery where each recovery resource can be shared by a maximum of X LSPs/spans is not defined as a recovery type but as a recovery scheme. choosing X is a network resource management policy decision. 💅
E. M:N (M, N > 1, N >= M) type:
a set of M specific recovery LSPs/spans protects a set of up to N specific working LSPs/spans. both sets are explicitly identified. extra traffic can be carried over the M recovery LSPs/spans when they're available. all the LSPs/spans must start and end at the same nodes. 🌸
sometimes the working LSPs/spans are assumed to be resource disjoint in the network, so they don't share any failure probability, but that's not mandatory. obviously, if several working LSPs/spans in the set of N get hit by failures at the same time, the traffic on only M of those failed LSPs/spans can be recovered. also, N can be arbitrarily large (i.e., infinite). choosing N and M is a policy decision 🦋
this type works for LSP/span protection and LSP restoration, but not for span restoration. 🔥
4.7. Bridge Types
a bridge is the function that connects the normal traffic and the extra traffic to the working and recovery LSP/span. 🌉
A. Permanent bridge
under a 1+1 type, the bridge connects the normal traffic to both the working and protection LSPs/spans. this type of bridge doesn't apply to restoration types. there's, of course, no extra traffic connected to the recovery LSP/span. 💖
B. Broadcast bridge
for 1:N and M:N types, the bridge permanently connects the normal traffic to the working LSP/span. when recovery switching happens, the normal traffic is also connected to the recovery LSP/span. the extra traffic is either not connected, or it's connected to the recovery LSP/span. 📡
C. Selector bridge
for 1:N and M:N types, the bridge connects the normal traffic to either the working or the recovery LSP/span. the extra traffic is either not connected, or it's connected to the recovery LSP/span. 🧚
4.8. Selector Types
a selector is the function that pulls the normal traffic out of either the working or the recovery LSP/span. the extra traffic is either pulled out of the recovery LSP/span, or it isn't pulled out at all. 🌈
A. Selective selector
this is a selector that pulls the normal traffic from either the working LSP/span output or the recovery LSP/span output. 💅
B. Merging selector
for 1:N and M:N protection types, the selector permanently pulls the normal traffic from both the working and recovery LSP/span outputs. this option only works together with a selector bridge. ✨
4.9. Recovery GMPLS Nodes
this section defines the GMPLS nodes that get involved during recovery. 🫶
A. Ingress GMPLS node of an end-to-end LSP/segment LSP/span
the ingress node of an end-to-end LSP/segment LSP/span is where the normal traffic may be bridged onto the recovery end-to-end LSP/segment LSP/span. it's also called the source node in ITU-T terminology. 🌸
B. Egress GMPLS node of an end-to-end LSP/segment LSP/span
the egress node of an end-to-end LSP/segment LSP/span is where the normal traffic may be selected from either the working or the recovery end-to-end LSP/segment LSP/span. it's also called the sink node in ITU-T terminology. 🦋
C. Intermediate GMPLS node of an end-to-end LSP/segment LSP
this is a node along either the working or the recovery end-to-end LSP/segment LSP route, between the corresponding ingress and egress nodes. it's also called an intermediate node in ITU-T terminology. 🎀
4.10. Switch-over Mechanism
a switch-over is an action that can be done at both the bridge and the selector. here's how it works: 🔁
A. For the selector:
it's the action of selecting the normal traffic from the recovery LSP/span instead of from the working LSP/span. 💖
B. For the bridge:
if the connection to the working LSP/span is permanent, the action is connecting or disconnecting the normal traffic to or from the recovery LSP/span. if the connection to the working LSP/span is non-permanent, the action is connecting the normal traffic to the recovery LSP/span. 🌈
4.11. Reversion operations
a revertive recovery operation is a recovery switching operation where the traffic goes back to (or stays on) the working LSP/span when the switch-over requests end, meaning when the working LSP/span has recovered from the failure. 🔄
so a non-revertive recovery switching operation is one where the traffic does not go back to the working LSP/span when the switch-over requests end. 🙃
4.12. Failure Reporting
this section gives, for information, a few signal types that are commonly used in transport planes to report a failure condition. just note that fault reporting may need additional signaling mechanisms too. 📣
A. Signal Degrade (SD)
a signal showing that the associated data has degraded. 📉
B. Signal Fail (SF)
a signal showing that the associated data has failed. 💀
C. Signal Degrade Group (SDG)
a signal showing that the associated group data has degraded. 📉
D. Signal Fail Group (SFG)
a signal showing that the associated group has failed. 💀
Note: SDG and SFG definitions are still under discussion at the ITU-T. 🙈
4.13. External commands ✨
okay so this bit is all about external commands 🎀. These are the ones an operator usually sends through the Network Management System (NMS)/Element Management System (EMS) to steer the recovery schemes around 💅
A. Lockout of recovery LSP/span:
A configuration action that comes from outside and leaves the recovery LSP/span temporarily unavailable to carry traffic, whether normal or extra. 🔒
B. Lockout of normal traffic:
A configuration action that comes from outside and temporarily stops normal traffic from being routed over its recovery LSP/span. ngl this one is sneaky, because extra-traffic is still allowed on the recovery LSP/span 🦋
C. Freeze:
A configuration action that comes from outside and blocks any switch-over action, so the current state just stays frozen ❄️
D. Forced switch-over for normal traffic:
A switch-over action, started from outside, that moves normal traffic onto the recovery LSP/span, unless an equal or higher priority switch-over command is already in effect. 💪
E. Manual switch-over for normal traffic:
A switch-over action, started from outside, that moves normal traffic onto the recovery LSP/span, unless there's a fault condition on other LSPs/spans (including the recovery LSP/span) or an equal or higher priority switch-over command is already in effect. it's giving careful, respectful energy 🫶
F. Manual switch-over for recovery LSP/span:
A switch-over action, started from outside, that moves normal traffic onto the working LSP/span, unless there's a fault condition on the working LSP/span or an equal or higher priority switch-over command is already in effect. 🌸
G. Clear:
An action, started from outside, that clears the active external command. bestie, this is the reset button 🧹✨
4.14. Unidirectional versus Bi-Directional Recovery Switching
okay this one is the difference between two switching modes, and it's kind of iconic 👑
A. Unidirectional recovery switching:
A recovery switching mode where, for a unidirectional fault (a fault that only affects one direction of transmission), only the normal traffic going in the affected direction of the LSP or span gets switched to the recovery LSP/span. very targeted, very precise 🎯
B. Bi-directional recovery switching:
A recovery switching mode where, for a unidirectional fault, the normal traffic in both directions of the LSP or span gets switched to the recovery LSP/span. That means the affected direction AND the unaffected direction both move over 🌈
4.15. Full versus Partial Span Recovery Switching
so bulk LSP recovery kicks off when a span failure notification or a bulk failure notification comes in for the S LSPs carried on that span 🧚 Either way, the recovery switching actions happen at the LSP level, and the goal is to keep the ratio between the number of recovery switching messages and the number of recovered LSPs (in one direction) as low as possible. If that ratio is exactly 1, we call it full span recovery. If it's greater than 1, it's partial span recovery. the math is giving main character energy 🧮
A. Full Span Recovery
All the S LSPs carried over a given span get recovered when there's a span failure condition. Full span recovery is also known as "bulk recovery" 💖
B. Partial Span Recovery
Only a subset s of the S LSPs carried over a given span gets recovered under a span failure condition. Both the selection criteria for the entities in that subset, and the decision about recovering the remaining (S - s) LSPs, are based on local policy 📋
4.16. Recovery Schemes Related Time and Durations
this section lists some typical timing definitions that matter a lot for recovery schemes ⏰ time is literally everything here 😭
A. Detection time:
The time between when the fault or degradation happens and when it gets detected. ngl this is kind of a theoretical time, since it's really hard to measure in practice 🙈
B. Correlation time:
The time between when the fault or degradation gets detected and when the signal fail or degrade is reported. This one is usually used for correlating related failures or degradations 🔗
C. Notification time:
The time between when the signal fail or degrade is reported and when the entities deciding on the recovery switching operation(s) receive the indication of that event 📨
D. Recovery Switching time:
The time between starting the recovery switching operation and the moment the normal traffic is selected from the recovery LSP/span. 🔁
E. Total Recovery time:
The total recovery time is the sum of the detection, correlation, notification, and recovery switching times. it's the whole journey, all added up 🧾
F. Wait To Restore time:
A period of time that must elapse after a recovered fault before an LSP/span can be used again to carry normal traffic and/or be selected for normal traffic. it's like a cooldown before things go back to normal 🧊
Note: the hold-off time is defined as the time between the reporting of signal fail or degrade and the start of the recovery switching operation. This is useful when multiple layers of recovery are being used. ✨
4.17. Impairment
A defect or performance degradation, which may lead to an SF or SD trigger. 🚨
4.18. Recovery Ratio
The quotient of the actual recovery bandwidth divided by the traffic bandwidth that is intended to be protected. it's just a fraction, but it's a slay one 📊
4.19. Hitless Protection Switch-over
A protection switch-over that doesn't cause data loss, data duplication, data disorder, or bit errors when the recovery switching action happens. this is the dream, bestie 🥹🧚
4.20. Network Survivability
The set of capabilities that lets a network restore affected traffic when a failure happens. How survivable a network is depends on its ability to survive single failures and multiple failures. 🛡️
4.21. Survivable Network
A network that can restore traffic when a failure happens. Simple and iconic 👑
4.22. Escalation
A network survivability action that gets triggered because the survivability function in lower layers can't do the job. when the lower layers tap out, it escalates 🆙
5. Recovery Phases
okay so it's commonly accepted that when an LSP/span or a node fails, recovery involves the following generic operations 📚
- Phase 1: Failure Detection
This is when the impairment (a defect or performance degradation) gets detected as a defect condition, and that leads to an SF or SD trigger going to the control plane through the internal interface with the transport plane. Failure detection (which should happen at the transport layer closest to the failure) is the only phase the control plane can't handle alone. 🔍
- Phase 2: Failure Localization (and Isolation)
Failure localization tells the deciding entity where the transport plane entity that caused the LSP(s)/span(s) failure is, which means its identity too. With that info, the deciding entity can make an accurate decision for finer grained recovery switching action(s). 📍
- Phase 3: Failure Notification
The failure notification phase does two things: 1) it informs intermediate nodes that an LSP(s)/span(s) failure has occurred and been detected, and 2) it informs the recovery deciding entities (which can be any intermediate node or end-point of the failed LSP/span) that the corresponding LSP/span isn't available. 📣
- Phase 4: Recovery (Protection or Restoration)
See Section 4.3. 🔗
- Phase 5: Reversion (Normalization)
See Section 4.11. 🔗
The combination of Failure Detection, Failure Localization, and Notification is called Fault Management. 🧰
5.1. Entities Involved During Recovery
these are the entities involved in recovery operations. They're all parts of ingress, egress, and intermediate nodes, as defined earlier 🧩
A. Detecting Entity (Failure Detection):
An entity that detects a failure or a group of failures, giving a non-correlated list of failures. 🕵️♀️
B. Reporting Entity (Failure Correlation and Notification):
An entity that can make an intelligent decision about fault correlation and report the failure to the deciding entity. Fault reporting can happen automatically when the deciding entity itself detects the failure. 📢
C. Deciding Entity (part of the failure recovery decision process):
An entity that makes the recovery decision or selects the recovery resources. It tells the impacted LSPs/spans which recovery actions to perform. 👑
D. Recovering Entity (part of the failure recovery activation process):
An entity that takes part in recovering the LSPs/spans. 🙌
The process of moving failed LSPs from a failed (working) span to a protection span must be initiated by one of the nodes that terminates the span, e.g., A or B. The deciding (and recovering) entity is called the "master", while the other node is called the "slave" and is a recovering-only entity. it's giving hierarchy, but make it cute 🎀
Note: The determination of the master and the slave may be based on configured information or protocol-specific requirements. 💜
6. Protection Schemes
this section breaks down the different protection schemes and the specific protection terminology 💖
6.1. 1+1 Protection
1+1 protection has one working LSP/span, one protection LSP/span, and a permanent bridge. At the ingress node, the normal traffic is permanently bridged to both the working and protection LSP/span. At the egress node, the normal traffic is selected from the better of the two LSPs/spans. it's the most dramatic pairing, honestly 💅
Because of the permanent bridging, 1+1 protection doesn't allow an unprotected extra traffic signal to be provided. 🚫
6.2. 1:N (N >= 1) Protection
1:N protection has N working LSPs/spans that carry normal traffic, and 1 protection LSP/span that may carry extra-traffic. 🧁
At the ingress, the normal traffic is either permanently connected to its working LSP/span and may also be connected to the protection LSP/span (in the case of a broadcast bridge), or it's connected to either its working LSP/span or the protection LSP/span (in the case of a selector bridge). At the egress node, the normal traffic is selected from either its working or protection LSP/span. 🌉
Unprotected extra traffic can be carried over the protection LSP/span whenever that protection LSP/span isn't being used for normal traffic. 🦋
6.3. M:N (M, N > 1, N >= M) Protection
M:N protection has N working LSPs/spans carrying normal traffic and M protection LSP/span that may carry extra-traffic. ✨
At the ingress, the normal traffic is either permanently connected to its working LSP/span and may also be connected to one of the protection LSPs/spans (in the case of a broadcast bridge), or it's connected to either its working LSP/span or one of the protection LSPs/spans (in the case of a selector bridge). At the egress node, the normal traffic is selected from either its working or one of the protection LSP/span. 🌈
Unprotected extra traffic can be carried over the M protection LSP/span whenever the protection LSPs/spans aren't being used for normal traffic. 💜
6.4. Notes on Protection Schemes
All protection types are either uni- or bi-directional. Obviously, the bi-directional kind only applies to bi-directional LSPs/spans, and it needs coordination between the ingress and egress node during protection switching. 🤝
All protection types except 1+1 unidirectional protection switching need a communication channel between the ingress and the egress node. 📡
In the GMPLS context, span protection refers to the full or partial span recovery of the LSPs carried over that span (see Section 4.15). 🧠
7. Restoration Schemes
this section breaks down the different restoration schemes and the specific restoration terminology. it's the comeback arc, and I'm here for it 🦋🔥
7.1. Pre-Planned LSP Restoration
Also known as pre-planned LSP re-routing 🦋 Okay so, before a failure is detected or notified, one or more restoration LSPs get set up between the same ingress-egress node pair as the working LSP. The restoration resources have to be pre-computed and signaled ✨ They may be selected a priori, but they may not cross-connected, so the restoration LSP can't carry any extra-traffic 🫶
The full setup of the restoration LSP (aka activation) only happens after the working LSP's failure gets detected and/or notified, and it needs some extra restoration signaling. So this mechanism protects you from working LSP failures, but the restoration LSP has to be activated after the failure happens 😭 Once the ingress node has activated it, the restoration LSP can carry the normal traffic 💖
Note: when each working LSP is recoverable by exactly one restoration LSP, people also call this 1:1 (pre-planned) re-routing without extra-traffic. It's giving one-to-one energy 🎀
7.1.1. Shared-Mesh Restoration
"Shared-mesh" restoration is a special case of pre-planned LSP re-routing 🌸 The big win is that it cuts down on restoration resource requirements, because multiple restoration LSPs (started from different ingress nodes) are allowed to share common resources, including links and nodes. Resource sharing is everything 👑
7.2. LSP Restoration
Also known as LSP re-routing 💅 The ingress node switches the normal traffic over to an alternate LSP, which gets signaled and fully established (aka cross-connected) only after failure detection and/or notification. The alternate LSP path can be computed after the failure is detected and/or notified too, and when that happens, people call it "Full LSP Re-routing." Lowkey iconic 🔥
The alternate LSP is signaled from the ingress node, and it may reuse the intermediate node's resources from the working LSP under failure conditions (and it may also include additional intermediate nodes) 🧚
7.2.1. Hard LSP Restoration
Also known as hard LSP re-routing. This is a re-routing operation where the LSP gets released before the alternate LSP is fully established, which is break-before-make 💀
7.2.2. Soft LSP Restoration
Also known as soft LSP re-routing. This one is the opposite: the LSP only gets released after the alternate LSP is fully established, which is make-before-break 🫶 Much safer vibes, no cap 💜
8. Security Considerations ✨
Security considerations are detailed in [RFC4428] and [RFC4426]. Go read those for the full story 🙈 This part is serious, bestie, so don't skip the references 😭
9. References 🌈
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.9.2. Informative References
[RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and
Multilayer Survivability", RFC 3386, November 2002.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC4426] Lang, J., Rajagopalan B., and D.Papadimitriou, Editors,
"Generalized Multiprotocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426, March
2006.
[RFC4428] Papadimitriou D. and E.Mannie, Editors, "Analysis of
Generalized Multi-Protocol Label Switching (GMPLS)-based
Recovery Mechanisms (including Protection and
Restoration)", RFC 4428, March 2006.For information on the availability of the following documents, please see http://www.itu.int
[G.808.1] ITU-T, "Generic Protection Switching - Linear trail and
subnetwork protection," Recommendation G.808.1, December
2003.
[G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841, October
1998.10. Acknowledgements 💖
Many thanks to Adrian Farrel for having thoroughly review this document. 🫶
Editors' Addresses 🎀
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
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.beFull 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.
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 takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF 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: rfc4427 2006-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms