RFC 7347
Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP)
📡 RFC 7347: Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP) 💖
Okay bestie, here's the whole title block tea ☕✨
- RFC number: 7347
- Title: Pre-standard Linear Protection Switching in MPLS Transport Profile (MPLS-TP)
- Authors: H. van Helvoort (Ed., Huawei Technologies), J. Ryoo (Ed., ETRI), H. Zhang (Huawei Technologies), F. Huang (Philips), H. Li (China Mobile), and A. D'Alessandro (Telecom Italia)
- Stream: Independent Submission 🦋
- Category: Informational 🌸
- ISSN: 2070-1721
- Date: September 2014 📅
- Obsoletes/Updates: The title block doesn't list anything this RFC obsoletes or updates 🙈
Abstract ✨
The official IETF Standards Track answer for MPLS Transport Profile (MPLS-TP) Linear Protection lives in RFCs 6378, 7271, and 7324. 💅
This document describes the pre-standard version of MPLS-TP Linear Protection. Several network operators have deployed it, using gear from multiple vendors. When this was published, these pre-standard implementations were still running live traffic, so they're not just a museum piece 😭🔥
The mechanism supports 1+1 unidirectional/bidirectional protection switching and 1:1 bidirectional protection switching. It's purely supported by the MPLS-TP data plane, and it can work without any control plane. Main character energy, no cap 👑
Status of This Memo ✨
This document is not an Internet Standards Track specification. It's published for informational purposes, so it's not a spec you're forced to follow 🌈
This is a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor chose to publish it at their discretion, and they make no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for the details 🧚
Info about the current status of this document, any errata, and how to give feedback on it can be found at:
http://www.rfc-editor.org/info/rfc7347
Copyright Notice ✨
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they stand on the publication date. Here's http://trustee.ietf.org/license-info. Please actually read these, because they spell out your rights and restrictions for this document 🫶
Table of Contents ✨
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Linear Protection-Switching Overview . . . . . . . . . . . . 6
4.1. Protection Architecture Types . . . . . . . . . . . . . . 6
4.1.1. 1+1 Architecture . . . . . . . . . . . . . . . . . . 6
4.1.2. 1:1 Architecture . . . . . . . . . . . . . . . . . . 6
4.1.3. 1:n Architecture . . . . . . . . . . . . . . . . . . 7
4.2. Protection Switching Type . . . . . . . . . . . . . . . . 7
4.3. Protection Operation Type . . . . . . . . . . . . . . . . 7
5. Protection-Switching Trigger Conditions . . . . . . . . . . . 8
5.1. Fault Conditions . . . . . . . . . . . . . . . . . . . . 8
5.2. External Commands . . . . . . . . . . . . . . . . . . . . 8
5.2.1. End-to-End Commands . . . . . . . . . . . . . . . . . 8
5.2.2. Local Commands . . . . . . . . . . . . . . . . . . . 9
6. Protection-Switching Schemes . . . . . . . . . . . . . . . . 10
6.1. 1+1 Unidirectional Protection Switching . . . . . . . . . 10
6.2. 1+1 Bidirectional Protection Switching . . . . . . . . . 11
6.3. 1:1 Bidirectional Protection Switching . . . . . . . . . 12
7. APS Protocol . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. APS PDU Format . . . . . . . . . . . . . . . . . . . . . 13
7.2. APS Transmission . . . . . . . . . . . . . . . . . . . . 16
7.3. Hold-Off Timer . . . . . . . . . . . . . . . . . . . . . 17
7.4. WTR Timer . . . . . . . . . . . . . . . . . . . . . . . . 17
7.5. Command Acceptance and Retention . . . . . . . . . . . . 18
7.6. Exercise Operation . . . . . . . . . . . . . . . . . . . 18
8. Protection-Switching Logic . . . . . . . . . . . . . . . . . 19
8.1. Principle of Operation . . . . . . . . . . . . . . . . . 19
8.2. Equal Priority Requests . . . . . . . . . . . . . . . . . 21
8.3. Signal Degrade of the Protection Transport Entity . . . . 22
9. Protection-Switching State Transition Tables . . . . . . . . 22
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. Operation Examples of the APS Protocol . . . . . . . 261. Introduction 🌸
The official IETF Standards Track solution for MPLS Transport Profile (MPLS-TP) Linear Protection is in [RFC6378], [RFC7271], and [RFC7324]. 💖
This document describes the pre-standard version of MPLS-TP Linear Protection. Several network operators deployed it with equipment from multiple vendors, and when this was published, those pre-standard implementations were still carrying live traffic 🔥
This implementation was considered in the MPLS WG, but a different path was chosen. Oh well 🙈
This document might be useful later if a vendor or operator needs to interwork with a different vendor or operator who has deployed the pre-standard implementation. It also gives a permanent record of the pre-standard implementation. Worth noting too: the experience from deploying the implementations in this document was used to refine [RFC7271] ✨
MPLS-TP is defined as the transport profile of MPLS technology, so it can be deployed in transport networks. A typical feature of a transport network is that it can provide fast protection switching for end-to-end transport paths and transport path segments. The protection-switching time is generally required to be less than 50 ms, to meet the strict requirements of services such as voice, private line, etc. 📞
The goal of a linear protection-switching mechanism is to meet the requirement of fast protection switching for an MPLS-TP network. Linear protection switching means that, for one or more working transport entities (working paths), there is one protection transport entity (protection path). It's disjoint from any of the working transport entities, and it's ready to take over the service transmission when a working transport entity has failed. Backup squad assemble 🦸♀️
This document specifies a 1+1 unidirectional protection-switching mechanism for a unidirectional transport entity, which can be point to point or point to multipoint. It also specifies a bidirectional point-to-point transport entity, and a 1+1/1:1 bidirectional protection-switching mechanism for a point-to-point bidirectional transport entity. Bidirectional protection switching needs the two endpoints of the transport entity to coordinate, so this document also specifies the Automatic Protection Switching (APS) protocol, which is used for exactly that 🫶
The linear protection mechanism described in this document applies to both Label Switched Paths (LSPs) and Pseudowires (PWs). Both are covered, no one's left out 🧚
The APS protocol specified here is based on the same principles and behavior as the APS protocol designed for Synchronous Optical Network (SONET) [T1.105.01] / Synchronous Digital Hierarchy (SDH) [G.841], Optical Transport Network (OTN) [G.873.1], and Ethernet [G.8031]. It also shares commonality with the established operation models used in transport network technologies (e.g., SDH/SONET, OTN, and Ethernet). It's giving family reunion 🌈
2. 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 words, so read them carefully 🎀
3. Acronyms 💅
This document uses the following acronyms. Here's the full list, bestie 📝
APS Automatic Protection Switching
DNR Do not Revert
EXER Exercise
G-ACh Generic Associated Channel
FS Forced Switch
LO Lockout of Protection
LSP Label Switched Path
MPLS-TP MPLS Transport Profile
MS Manual Switch
MS-P Manual Switch to Protection transport entity
MS-W Manual Switch to Working transport entity
NR No Request
OAM Operations, Administration, and Maintenance
OTN Optical Transport Network
PDU Protocol Data Unit
PW Pseudowire
RR Reverse Request
SD Signal Degrade
SD-P Signal Degrade on Protection transport entity
SD-W Signal Degrade on Working transport entity
SDH Synchronous Digital Hierarchy
SF Signal Fail
SF-P Signal Fail on Protection transport entity
SF-W Signal Fail on Working transport entity
SONET Synchronous Optical Network
WTR Wait to Restore4. Linear Protection-Switching Overview 🦋
To guarantee the protection-switching time for a working transport entity, its protection transport entity is always preconfigured before the failure happens. Normally, traffic is sent and received on the working transport entity. Switching over to the protection transport entity is usually triggered by a link or node failure, external commands, etc. 🔥
External commands are often used in transport networks by operators, and honestly they're super useful for service adjustment, path maintenance, etc. Note that they're a whole vibe 💜
4.1. Protection Architecture Types 🌷
4.1.1. 1+1 Architecture 🎀
In the 1+1 architecture, the protection transport entity is associated with a working transport entity. The normal traffic is permanently bridged onto both the working transport entity and the protection transport entity at the source endpoint of the protected domain. 🌊
The normal traffic on the working and protection transport entities is transmitted simultaneously to the destination sink endpoint of the protected domain. There, a selection between the working and protection transport entity is made based on predetermined criteria, such as signal fail and signal degrade indications. Both copies are already flying, and the sink just picks the one that looks healthier ✨
4.1.2. 1:1 Architecture 🦋
okay bestie, so in the 1:1 setup every working transport entity gets its very own protection transport entity 🫶 When the working one is determined to be impaired, the normal traffic MUST be transferred from the working to the protection transport entity at both the source and sink endpoints of the protected domain. The pick between working and protection is made using predetermined criteria, like signal fail and signal degrade indications from the working or protection transport entity 💅
The bridge at the source endpoint can be done in two ways: it's either a selector bridge or a broadcast bridge ✨ With a selector bridge, the normal traffic is connected to either the working transport entity or the protection transport entity. With a broadcast bridge, the normal traffic is permanently connected to the working transport entity, and when a protection switch is active, it's also connected to the protection transport entity. The broadcast bridge is recommended to be used in revertive mode only 🌸
4.1.3. 1:n Architecture 🧚
the details for the 1:n protection-switching architecture are out of scope for this document and will be provided in a different document in the future 🫠
ngl though, the APS protocol defined here is capable of supporting 1:n operations 👑
4.2. Protection Switching Type 🔥
the linear protection-switching types can be a unidirectional switching type or a bidirectional switching type, and here's the tea:
- Unidirectional switching type: only the affected direction of the working transport entity gets switched to the protection transport entity, and the selectors at each endpoint operate independently 🎀 This switching type is recommended to be used for 1+1 protection in this document.
- Bidirectional switching type: both directions of the working transport entity, the affected direction and the unaffected direction, get switched to the protection transport entity 🦋 For bidirectional switching, the APS protocol is required to coordinate the two endpoints so that both have the same bridge and selector settings, even for a unidirectional failure. This type is applicable for 1+1 and 1:1 protection.
4.3. Protection Operation Type 🍓
the linear protection operation types can be a non-revertive operation type or a revertive operation type 💖
- Non-revertive operation: the normal traffic will not be switched back to the working transport entity, even after a protection switching cause has cleared 🙈 This is generally accomplished by replacing the previous switch request with a "Do not Revert (DNR)" request, which has a low priority.
- Revertive operation: the normal traffic is restored to the working transport entity after the condition(s) causing the protection switching has cleared. If we're clearing a command (like Forced Switch), this happens immediately ⚡ If we're clearing a defect, this generally happens after the expiry of a "Wait to Restore (WTR)" timer, which is used to avoid chattering of selectors in the case of intermittent defects 🌈
5. Protection-Switching Trigger Conditions 🚨
5.1. Fault Conditions 💀
fault conditions are the requests generated by the local Operations, Administration, and Maintenance (OAM) function, so basically the local OAM is the one raising its hand 🙋♀️
- Signal Fail (SF): if an endpoint detects a failure by an OAM function or other mechanism, it will submit a local signal failure (local SF) to the APS module to request a protection switch. The local SF could be on the working transport entity (Signal Fail on Working transport entity (SF-W)) or the protection transport entity (Signal Fail on Protection transport entity (SF-P)) 😭
- Signal Degrade (SD): if an endpoint detects signal degradation by an OAM function or other mechanism, it will submit a local signal degrade (local SD) to the APS module to request a protection switching. The local SD could be on the working transport entity (Signal Degrade on Working transport entity (SD-W)) or the protection transport entity (Signal Degrade on Protection transport entity (SD-P)) 🫶
5.2. External Commands 👑
the external command issues an appropriate external request to the protection process. Think of it as the operator sliding into the group chat with a very specific request 💅
5.2.1. End-to-End Commands 🌸
these commands get applied to both local and remote nodes. When the APS protocol is present, these commands (except the Clear command) are signaled to the far end of the connection. In bidirectional switching, these commands affect the bridge and selector at both ends, so it's a whole team effort 🧚
- Lockout of Protection (LO): this command is used to give the operator a tool for temporarily disabling access to the protection transport entity 🔒
- Manual Switch (MS): this command is used to give the operator a tool for temporarily switching normal traffic to the working transport entity (Manual Switch to Working transport entity (MS-W)) or to the protection transport entity (Manual Switch to Protection transport entity (MS-P)), unless a higher priority switch request (i.e., LO, FS, or SF) is in effect.
- Forced Switch (FS): this command is used to give the operator a tool for temporarily switching normal traffic from the working transport entity to the protection transport entity, unless a higher priority switch request (i.e., LO or SF-P) is in effect 🔥
- Exercise (EXER): exercise is a command to test if the APS communication is operating correctly 🧪 The EXER command SHALL NOT affect the state of the protection selector and bridge. Hands off, EXER is just checking the vibes ✨
- Clear: this command between management and the local protection process is not a request sent by APS to other endpoints. It's used to clear the active near-end external command or WTR state 🧹
5.2.2. Local Commands 🎀
these commands apply only to the near end (local node) of the protection group. Even when an APS protocol is supported, they are not signaled to the far end, so they stay local, bestie 🤫
- Freeze: this command freezes the state of the protection group. Until the freeze is cleared, additional near-end commands are rejected, and condition changes and received APS information are ignored 🧊 When the Freeze command is cleared, the state of the protection group is recomputed based on the condition and received APS information.
Because the freeze is local, if the freeze is issued at one end only, a failure of protocol can occur, since the other end is open to accept any operator command or fault condition 😬
- Clear Freeze: this command clears the local freeze 🌤️
6. Protection-Switching Schemes 🧚
6.1. 1+1 Unidirectional Protection Switching 🦋
+-----------+ +-----------+
| |---------------------------------------| |
| -+---------------------------------------+- |
| / |---------------------------------------| \ |
| / | Working transport entity | \ |
--+-------> | | --------+->
| \ | | |
| \ |---------------------------------------| |
| -+---------------------------------------| |
| source |---------------------------------------| sink |
+-----------+ Protection transport entity +-----------+
(normal condition)
+-----------+ +-----------+
| |---------------------------------------| |
| -+------------------XX-------------------+ |
| / |---------------------------------------| |
| / | Working transport entity (failure) | |
--|-------> | | --------+->
| \ | | / |
| \ |---------------------------------------| / |
| -+---------------------------------------+- |
| source |---------------------------------------| sink |
+-----------+ Protection transport entity +-----------+
(failure condition)Figure 1: 1+1 Unidirectional Linear Protection Switching 📊
1+1 unidirectional protection switching is the simplest protection switching mechanism, and honestly it's giving easy mode 😌 The normal traffic is permanently bridged on both the working and protection transport entities at the source endpoint of the protected domain. In the normal condition, the sink endpoint receives traffic from the working transport entity. If the sink endpoint detects a failure on the working transport entity, it will switch to receive traffic from the protection transport entity. 1+1 unidirectional protection switching is recommended to be used for unidirectional transport 🌈
Note that 1+1 unidirectional protection switching does not use the APS coordination protocol, since it only performs protection switching based on the local request 💜
6.2. 1+1 Bidirectional Protection Switching 🦋
+-----------+ +-----------+
| |---------------------------------------| |
| -+<--------------------------------------+- |
| / +-------------------------------------->+ \ |
| sink / /|---------------------------------------|\ \ sink |
<-+-------/ / | Working transport entity | --\-------+->
--+--------> | | <------+--
| source \ | | / source|
| \|---------------------------------------| / |
| +-------------------------------------->| / |
| |<--------------------------------------+- |
| APS <...................................................> APS |
| |---------------------------------------+ |
+-----------+ Protection transport entity +-----------+
(normal condition)
+-----------+ +-----------+
| |---------------------------------------| |
| +<----------------XX--------------------+- |
| +-------------------------------------->+ \ |
| /|---------------------------------------| \ |
| source / | Working transport entity (failure) | \ source|
--+--------> | | \<-----+--
<-+------- \ | | --/------+->
| sink \ \|---------------------------------------| / / sink |
| \ +-------------------------------------->+- / |
| --+<--------------------------------------+-/ |
| APS <...................................................> APS |
| |---------------------------------------+ |
+-----------+ Protection transport entity +-----------+
(failure condition)
Figure 2: 1+1 Bidirectional Linear Protection SwitchingOkay so in 1+1 bidirectional protection switching, the normal traffic gets permanently bridged onto both the working and protection transport entities, for each direction, at the source endpoint of the protected domain. 🌸 That's the "1+1" part, and it's giving double coverage. In the normal condition, the sink endpoint, for each direction, receives its traffic from the working transport entity. ✨
If the sink endpoint detects a failure on the working transport entity, it switches over and starts receiving traffic from the protection transport entity instead. 💅 It also sends an APS message so the sink endpoint on the other direction knows to switch to the protection transport entity too. Iconic teamwork, honestly. 🫶
The APS mechanism is necessary to coordinate the two endpoints of the transport entity. It's also what lets 1+1 bidirectional protection switching work even for a unidirectional failure. Main character energy for the APS, no cap. 👑
6.3. 1:1 Bidirectional Protection Switching 🌈
+-----------+ +-----------+
| |---------------------------------------| |
| -+<--------------------------------------+- |
| / +-------------------------------------->+ \ |
| sink / /|---------------------------------------|\ \ source|
<-+-------/ / | Working transport entity | \ <-------+--
--+--------> | | ---------+->
| source | | sink |
| |---------------------------------------| |
| | | |
| | | |
| APS <...................................................> APS |
| |---------------------------------------| |
+-----------+ Protection transport entity +-----------+
(normal condition)
+-----------+ +-----------+
| |---------------------------------------| |
| | \/ | |
| | /\ | |
| |---------------------------------------| |
| source | Working transport entity (failure) | sink |
--+-------> | | --------+->
<-+------- \ | | / <------+--
| sink \ \ |---------------------------------------| / / source|
| \ -+-------------------------------------->+- / |
| --+<--------------------------------------+-- |
| APS <...................................................> APS |
| |---------------------------------------+ |
+-----------+ Protection transport entity +-----------+
(failure condition)
Figure 3: 1:1 Bidirectional Linear Protection SwitchingThis one's a little different, bestie. 🧚 In 1:1 bidirectional protection switching, for each direction, the source endpoint sends its traffic on either the working transport entity or the protection transport entity. The sink endpoint then receives that traffic from the very same transport entity the source endpoint used. 🍓
In the normal condition, both the source and sink endpoints send and receive traffic from the working transport entity, for each direction. Simple and clean. 💜
If the sink endpoint detects a failure on the working transport entity, it switches to sending and receiving traffic from the protection transport entity. 🔥 It also sends an APS message to tell the sink endpoint on another direction to switch to sending and receiving traffic from the protection transport entity as well. Everyone gets the memo. 💖
The APS mechanism is necessary to coordinate the two endpoints of the transport entity. It's what lets 1:1 bidirectional protection switching happen even for a unidirectional failure. Obsessed, honestly. 😭
7. APS Protocol ✨
This APS protocol is based on the APS protocol defined in Section 11 of [G.8031]. Ngl, that's the source of truth, so if you want the nitty-gritty on the Protocol Data Unit (PDU) fields and protocol details beyond what's in this document, go read that reference. 🎀
7.1. APS PDU Format 💅
APS packets MUST be sent over a Generic Associated Channel (G-ACh) as defined in [RFC5586]. Non-negotiable, bestie. 🫶
The format of the APS PDU is specified in Figure 4 below. 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| Channel Type (=0x7FFA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEL | Version | OpCode | Flags | TLV Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| APS Specific Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End TLV |
+-+-+-+-+-+-+-+-+
Figure 4: APS PDU FormatThe following values MUST be used for the APS PDU: 🦋
- Channel Type: The Channel Type MUST be configurable by the implementation. During deployment, the local system administrator provisioned the value
0x7FFA. This is a code point value in the range of experimental Channel Types as described in RFC 5586, Section 10. Very experimental, very cute. 🧪 - Maintenance Entity group Level (MEL): The MEL value to set and check MUST be configurable. The DEFAULT value MUST be
"111". With co-routed bidirectional transport paths, the configured MEL MUST be the same in both directions. Consistency is everything. 💜 - Version:
0x00 - OpCode:
0x27(=0d39) - Flags:
0x00 - TLV Offset:
4 - End TLV:
0x00
The format of the APS-specific information is defined in Figure 5. 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Request|Pr.Type| Requested | Bridged | | |
| / |-+-+-+-| | |T| Reserved(0)|
| State |A|B|D|R| Signal | Signal | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: APS-Specific Information FormatAll bits defined as "Reserved" MUST be transmitted as 0 and ignored on reception. Reserved bits are the quiet ones, but they still matter. 🙈
- Request/State: The four bits indicate the protection-switching request type. See Figure 6 for the code of each request/state type. In case there are multiple protection-switching requests, only the protection-switching request with the highest priority MUST be processed. Priority is literally the whole vibe here. 👑
+------------------------------------+---------------+
| Request/State | Code/Priority |
+------------------------------------+---------------+
|Lockout of Protection (LO) | 1111 (highest)|
+------------------------------------+---------------+
|Signal Fail on Protection (SF-P) | 1110 |
+------------------------------------+---------------+
|Forced Switch (FS) | 1101 |
+------------------------------------+---------------+
|Signal Fail on Working (SF-W) | 1011 |
+------------------------------------+---------------+
|Signal Degrade (SD) | 1001 |
+------------------------------------+---------------+
|Manual Switch (MS) | 0111 |
+------------------------------------+---------------+
|Wait to Restore (WTR) | 0101 |
+------------------------------------+---------------+
|Exercise (EXER) | 0100 |
+------------------------------------+---------------+
|Reverse Request (RR) | 0010 |
+------------------------------------+---------------+
|Do Not Revert (DNR) | 0001 |
+------------------------------------+---------------+
|No Request (NR) | 0000 (lowest) |
+------------------------------------+---------------+
Figure 6: Protection-Switching Request Code/Priority- Protection Type (Pr.Type): The four bits are used to specify the protection type. 🍓
- A: reserved (set by default to 1)
- B:
0- 1+1 (permanent bridge);1- 1:1 (no permanent bridge) - D:
0- Unidirectional switching;1- Bidirectional switching - R:
0- Non-revertive operation;1- Revertive operation
- Requested Signal: This byte is used to indicate the traffic that the near-end requests to be carried over the protection entity.
value = 0: Null traffic.value = 1: Normal traffic 1.value = 2~255: Reserved. ✨ - Bridged Signal: This byte is used to indicate the traffic that is bridged onto the protection entity.
value = 0: Null traffic.value = 1: Normal traffic 1.value = 2~255: Reserved. 🌸 - Bridge Type (T): This bit is used to further specify the type of non-permanent bridge for 1:1 protection switching.
value = 0: Selector bridge.value = 1: Broadcast bridge. 🦋 - Reserved: This field MUST be set to zero. Keep it clean, babe. 🧼
7.2. APS Transmission 🎀
okay so the APS message MUST be sent over the protection transport entity, wrapped up with the protection transport entity label (that's the label of the LSP carrying protection traffic) 📦. if an endpoint gets APS-specific info from the working transport entity, it MUST ignore that info, and it MUST report the failure of protocol defect (see Section 8.1) to the operator 🚨. no skipping that report, bestie.
a new APS packet MUST be transmitted immediately when the transmitted status changes ⚡. the first three APS packets MUST be transmitted as fast as possible, but only if the APS info has changed in a way that makes fast protection switching possible, even if one or two APS packets get lost or corrupted 🏃♀️. the interval for those first three APS packets SHOULD be 3.3 ms. APS packets after the first three MUST be transmitted with an interval of 5 seconds 💅.
if no valid APS-specific info is received, the last valid received info stays applicable 🫶.
7.3. Hold-Off Timer ⏳
so to coordinate timing of protection switches across multiple layers, a hold-off timer MAY be required 🧚. the whole point is to give a server-layer protection switch a chance to fix the problem before the client layer switches 🙈.
each selector SHOULD have a provisioned hold-off timer. the suggested range is 0 to 10 seconds in steps of 100 ms (accuracy of +/-5 ms) ⏱️.
when a new defect or a more severe defect shows up (new SF or SD) on the active transport entity (the one currently carrying and selecting traffic), it does not get reported to protection switching right away if the provisioned hold-off timer value is non-zero 😤. instead, the hold-off timer SHALL be started. when it expires, it SHALL be checked whether a defect still exists on the transport entity that started the timer. if it does, that defect SHALL be reported to protection switching. the defect doesn't have to be the same one that started the timer 🦋.
this hold-off timer mechanism SHALL be applied for both working and protection transport entities 💖.
7.4. WTR Timer ⏰
in revertive mode of operation, to stop the protection switch from flipping back and forth because of an intermittent defect, a failed working transport entity MUST become fault free 🙅♀️. once it meets that criterion, a fixed period of time SHALL elapse before normal traffic signal uses it again. this period, called a WTR period, MAY be configured by the operator in 1 minute steps between 5 and 12 minutes; the default value is 5 minutes ⏳. an SF or SD condition will override the WTR 🚫.
to activate the WTR timer properly, even when both ends concurrently detect clearance of SF-W and SD-W: when the local state transits from SF-W or SD-W to No Request (NR) with the requested signal number 1, the previous local state, SF-W or SD-W, MUST be memorized 🧠. if both the local state and far-end state are NR with the requested signal number 1, the local state transits to WTR only when the previous local state is SF-W or SD-W. otherwise, the local state transits to NR with the requested signal number 0 🔄.
in revertive mode, when protection is no longer requested (i.e., the failed working transport entity is no longer in SF or SD condition, and assuming no other requesting transport entities), a local WTR state will be activated 🪄. since this state becomes the highest in priority, it's indicated on the APS signal and keeps the normal traffic signal from the previously failed working transport entity on the protection transport entity 💜. this state SHALL normally time out and become an NR state. the WTR timer deactivates earlier when any request of higher priority preempts this state 👑.
7.5. Command Acceptance and Retention 📝
the commands Clear, LO, FS, MS, and EXER are accepted or rejected in the context of previous commands, the condition of the working and protection entities in the protection group, and (in bidirectional switching only) the APS information received 💅.
the Clear command MUST be only valid if a near-end LO, FS, MS, or EXER command is in effect or if a WTR state is present at the near end, and rejected otherwise. this command removes the near-end command or WTR state, so the next lower-priority condition or (in bidirectional switching) APS request can be asserted 🧹.
other commands MUST be rejected unless they are higher priority than the previously existing command, condition, or (in bidirectional switching) APS request. if a new command is accepted, any previous, lower-priority command that gets overridden MUST be forgotten 🫠. if a higher priority command overrides a lower-priority condition or (in bidirectional switching) APS request, that other request will be reasserted if it still exists at the time the command is cleared 🔁. if a command is overridden by a condition or (in bidirectional switching) APS request, that command MUST be forgotten 💀.
7.6. Exercise Operation 🏋️♀️
exercise is a command to test whether APS communication is operating correctly 🧪. it's lower priority than any "real" switch request. it's only valid in bidirectional switching, since that's the only place you can get a meaningful test by looking for a response 🔍.
the Exercise command SHALL issue the command with the same requested and bridged signal numbers as the NR, Reverse Request (RR), or DNR request that it replaces. the valid response will be an RR with the corresponding requested and bridged signal numbers. when Exercise commands are input at both ends, an EXER, instead of RR, MUST be transmitted from both ends 🪞. the standard response to DNR MUST be DNR rather than NR. when the exercise command is cleared, it MUST be replaced with NR or RR if the requested signal number is 0, and DNR or RR if the requested signal number is 1 🌈.
8. Protection-Switching Logic ✨
8.1. Principle of Operation 🎀
okay bestie, this is the part where the whole switching brain comes together 🧠✨ Figure 7 shows how the pieces talk to each other, and honestly it's giving main character energy 💅
+-------------+ Persistent +----------+
SF,SD | Hold-off | fault | Local |
----------->| timer logic |----------->| request |
+-------------+ | logic |
Other local requests ----------------->| |
(LO, FS, MS, EXER, Clear) +----------+
|
| Highest
| local request
|
Remote APS V
message +-------+ Remote APS +----------------+
------------->| APS | request/state | APS process |
(received | check |-------------->| logic |
from far end) +-------+ +----------------+
| ^ | |
| | | Signaled |
| | | APS |
| | Txed | |
| | "Requested V |
| | Signal" +-----------+ |
| +-----------------| APS mess. | |
| | generator | |
| +-----------+ |
| | |
V | |
Failure of V |
protocol APS message |
detection V
Set local
bridge/selector
Figure 7: Protection-Switching LogicFigure 7 is the protection-switching logic, the whole vibe in one picture 🦋
One or more local protection-switching requests can be active at the same time 🌸 The "local request logic" figures out which one is the highest, using the order of priority from Figure 6. That highest local request info MUST be passed on to the "APS process logic" 💖 Hot tip that's actually in the spec: an accepted Clear command, clearance of SF or SD, or expiration of the WTR timer SHALL NOT be processed by the local request logic. Instead they SHALL be treated as the highest local request and sent to the APS process logic for processing 🙈
Wait, I need to correct that. The original says the highest local request info SHALL be passed on, so I should keep that wording exactly. The sentence I just wrote used MUST, which the original does not say. Here is the faithful version:
This highest local request information SHALL be passed on to the "APS process logic". Note that an accepted Clear command, clearance of SF or SD, or expiration of the WTR timer SHALL NOT be processed by the local request logic but SHALL be considered as the highest local request and submitted to the APS process logic for processing. 💅
The remote APS message comes in from the far end and gets checked in "APS check", which does the validity check and mismatch detection 🔍 These are the failure of protocol situations:
- The "B" field mismatch due to incompatible provisioning 🙅♀️
- The reception of the APS message from the working entity due to working/protection configuration mismatch 🙃
- No match in sent "Requested Signal" and received "Requested Signal" for more than 50 ms 😭
- No APS message is received on the protection transport entity during at least 3.5 times the long APS interval (e.g., at least 17.5 seconds), and there is no defect on the protection transport entity 💀
Provided the "B" field matches, these mismatches are handled as follows ✨
- If the "D" bit mismatches, the bidirectional side will fall back to unidirectional switching. 🦋
- If the "R" bit mismatches, one side will clear switches to WTR and the other will clear to DNR. The two sides will interwork and the traffic is protected. 🫶
- If the "T" bit mismatches, the side using a broadcast bridge will fall back to using a selector bridge. 🌈
The APS message with invalid information MUST be ignored, and the last valid received information remains applicable. Iykyk, that's the golden rule 👑
The linear protection-switching algorithm SHALL commence immediately every time one of its input signals changes. That means when the status of any local request changes, or when different APS-specific information comes in from the far end ⚡ The consequent actions also kick off right away: change the local bridge/selector position (if necessary), transmit new APS-specific information (if necessary), or detect the failure of protocol defect if the protection switching isn't completed within 50 ms ⏱️
The state transition gets calculated in the "APS process logic" based on three things: the highest local request, the request from the last received "Request/State" information, and the state transition tables in Section 9. Here's how it goes 💜
- If the highest local request is Clear, clearance of SF or SD, or expiration of WTR, a state transition is first calculated from the highest local request and the state machine table for local requests, which gives an intermediate state. This intermediate state is the final state in case of clearance of SF-P. Otherwise, starting from this intermediate state, the last received far-end request and the state machine table for far-end requests are used to calculate the final state. 🧚
- If the highest local request is neither Clear nor clearance of SF or of SD nor expiration of WTR, the APS process logic compares the highest local request with the request from the last received "Request/State" information, based on Figure 6.
- If the highest local request has higher or equal priority, it is used with the state transition table for local requests defined in Section 9 to determine the final state. Otherwise,
- The request from the last received "Request/State" information is used with the state transition table for far-end requests defined in Section 9 to determine the final state. 🍓
Finally, the "APS message generator" takes the signaled APS information for that final state and generates the APS-specific information, coded as described in Figure 5 📮
8.2. Equal Priority Requests 💞
Generally speaking, once a switch has been completed because of a request, it won't be overridden by another request of the same priority. This is a first-come, first-served policy, very fair, very cute 🎀 Equal priority requests from both sides of a bidirectional protection group are both considered valid, and here's how they play out 👯♀️
- If the local state is NR, with the requested signal number 1, and the far-end state is NR, with the requested signal number 0, the local state transits to NR with the requested signal number 0. This applies when the remote request for switching to the protection transport entity has been cleared. 🌸
- If both the local and far-end states are NR, with the requested signal number 1, the local state transits to the appropriate new state: DNR state for non-revertive mode and WTR state for revertive mode. This applies when the old request has been cleared at both ends. ✨
- If both the local and far-end states are RR, with the same requested signal number, both ends transit to the appropriate new state according to the requested signal number. This applies to concurrent deactivation of EXER from both ends. 🔁
- In other cases, no state transition occurs, even if equal priority requests are activated from both ends. Also, if MSs are issued simultaneously to both working and protection transport entities, whether as local or far-end requests, the MS to the working transport entity is considered to have higher priority than the MS to the protection transport entity. 🫣
8.3. Signal Degrade of the Protection Transport Entity 🩷
Signal degrade (SD) on the protection transport entity has the same priority as signal degrade on the working transport entity 🤝 So if an SD condition affects both transport entities, the first SD detected MUST NOT be overridden by the second SD detected. 🙅♀️ If the SD is detected simultaneously, either as local or far-end requests on both working and protection transport entities, then the SD on the standby transport entity MUST be considered as having higher priority than the SD on the active transport entity. The normal traffic signal keeps coming from the active transport entity, which means no unnecessary protection switching happens 🧘♀️
In the sentence above, "simultaneously" refers to SD occurring on both the active and standby transport entities at the input to the protection-switching process at the same time. It also covers the case where an SD request has not yet been acknowledged by the remote end in bidirectional protection switching ⏳
9. Protection-Switching State Transition Tables 🗺️
Okay, the state transition tables are where everything gets super organized 📚 In this section we describe state transition tables for these protection-switching configurations:
- 1:1 bidirectional (revertive mode, non-revertive mode) 🌷
- 1+1 bidirectional (revertive mode, non-revertive mode) 🌼
- 1+1 unidirectional (revertive mode, non-revertive mode) 🌻
Note that any other global or local request that is not described in the state transition tables does not trigger any state transition 🙌
Here's what each state means, bestie 🤓
- NR: NR is the state entered by the local priority under all conditions where no local protection-switching requests (including WTR and DNR) are active. NR can also indicate that the highest local request is overridden by a far-end request whose priority is higher than the highest local request. The normal traffic signal is selected from the corresponding transport entity. 🥰
- LO, SF-P, SD-P: The access by the normal traffic to the protection transport entity is NOT allowed in this state. The normal traffic is carried by the working transport entity, regardless of any fault or degrade condition that may be present (because of the highest priority of the switching triggers that led to this state). 🚫
- FS, SF-W, SD-W, MS-W, MS-P: A switching trigger that does NOT result in the protection transport entity being unavailable is present. The normal traffic is selected either from the corresponding working transport entity or from the protection transport entity, depending on how that specific switching trigger behaves. 🔀
- WTR: In revertive operation, after the clearing of an SF-W or SD-W, this maintains normal traffic as selected from the protection transport entity until the WTR timer expires or another request with higher priority, including the Clear command, is received. This is used to prevent frequent operation of the selector in the case of intermittent failures. 🕰️
- DNR: In non-revertive operation, this is used to maintain normal traffic selected from the protection transport entity. 🔒
- EXER: Exercise of the APS protocol. 🏋️♀️
- RR: The near end will enter and signal Reverse Request only in response to an EXER from the far end. 🔄
[State transition tables are shown at the end of the PDF form of this document.]
10. Security Considerations ✨
okay bestie, security time, and I need you to take this one seriously 🫶 MPLS-TP is basically a subset of MPLS, so it inherits a lot of MPLS's security vibes. The MPLS crowd is built on the assumption that it's super hard to sneak traffic into a network and equally hard to make traffic leave the network in the wrong direction 🔒 The control-plane protocols use hop-by-hop security and run on a "chain-of-trust" model, which means end-to-end control-plane security is not used 💅 If you want the generic MPLS security tea, check out [RFC5920] 🦋
This document describes a protocol carried in the G-ACh [RFC5586], so it's totally dependent on the security of the G-ACh itself 😭 The G-ACh is a generalization of the associated channel defined in [RFC4385], so this document leans hard on the security mechanisms provided for the associated channel and described in those two documents. No cap, it's a whole group project 🌸
11. Acknowledgements 🎀
The authors want to shout out Hao Long, Vincenzo Sestito, Italo Busi, Igor Umansky, and Andy Malis for their input to and review of the current 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.
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[G.841] International Telecommunications Union, "Types and characteristics of SDH network protection architectures", ITU-T Recommendation G.841, October 1998.
[G.873.1] International Telecommunications Union, "Optical Transport Network (OTN): Linear protection", ITU-T Recommendation G.873.1, May 2014.
[G.8031] International Telecommunications Union, "Ethernet linear protection switching", ITU-T Recommendation G.8031/Y.1342, June 2011.
[T1.105.01] American National Standards Institute, "Synchronous Optical Network (SONET) - Automatic Protection Switching", ANSI 0900105.01:2000 (R2010), March 2000.
12.2. Informative References 🌈
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011.
[RFC7271] Ryoo, J., Gray, E., van Helvoort, H., D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS Transport Profile (MPLS- TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators", RFC 7271, June 2014.
[RFC7324] Osborne, E., "Updates to MPLS Transport Profile Linear Protection", RFC 7324, July 2014.
Appendix A. Operation Examples of the APS Protocol ✨
Okay so this appendix is the fun part 🎀 Everything below is a little sequence diagram of APS messages bouncing between nodes A and Z. These are only a few examples, not every trick APS can do, bestie 💅 We only show the first APS message that differs from the one before it, and we skip the hold-off timer entirely 🙈 The fields that actually change during the exchange are Request/State, requested traffic, and bridged traffic. Everything else stays exactly as it was in the starting config.
Quick decoder ring 💜 SF(0,1) means an APS packet with Request/State = SF, Requested Signal = 0, and Bridged Signal = 1. Signal numbers 0 and 1 mean null signal and normal traffic signal. W(A->Z) and P(A->Z) are the working and protection paths going from A to Z.
Example 1. 1:1 bidirectional protection switching (revertive mode) - Unidirectional SF case
A Z
| |
(1) |---- NR(0,0)----->|
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z->A)) |
|---- SF(1,1)----->| (3)
|<----- NR(1,1)----|
(4) | |
| |
(5) | (Recovery) |
|---- WTR(1,1)---->|
/| |
WTR timer | |
\| |
(6) |---- NR(0,0)----->| (7)
(8) |<----- NR(0,0)----|
| |(1) The protected domain is running with zero defects, and the working entity is carrying the normal traffic. Main character energy ✨
(2) Signal Fail hits the working entity in the Z to A direction 💀 Node A's selector and bridge switch over to the protection entity, and A sends an SF(1,1) message.
(3) Node Z gets that SF(1,1), sets its selector and bridge to the protection entity, and since Z has no local request of its own, it sends back an NR(1,1) message.
(4) Node A checks in and confirms the far end is also on the protection entity 🫶
(5) Node A notices the SF condition has cleared, starts the WTR timer, and sends a WTR(1,1) message.
(6) When the WTR timer runs out, node A puts its selector and bridge back on the working entity and sends an NR(0,0) message.
(7) Node Z hears that the far-end request is gone and puts its selector and bridge back on the working entity too 🦋
(8) Both sides confirm the far end is on the working entity. Iconic, periodt 👑
Example 2. 1:1 bidirectional protection switching (revertive mode) - Bidirectional SF case
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z<->A)) | (2)
|<---- SF(1,1)---->|
(3) | | (3)
| |
(4) | (Recovery) | (4)
|<---- NR(1,1)---->|
(5) |<--- WTR(1,1)---->| (5)
/| |\
WTR timer | | WTR timer
\| |/
(6) |<---- NR(1,1)---->| (6)
(7) |<----- NR(0,0)--->| (7)
(8) | | (8)(1) Everything is healthy 🌸 The protected domain is running with no defects, and the working entity is carrying the normal traffic.
(2) Both nodes A and Z spot local SF conditions on the working entity. They each switch their selector and bridge over to the protection entity and send SF(1,1) messages. Double the drama 😭
(3) When each node receives SF(1,1), it confirms the far end is also on the protection entity.
(4) Each node sees its SF condition clear and sends an NR(1,1) message, because the last APS message it received was SF.
(5) Once each node gets NR(1,1), it starts its WTR timer and sends WTR(1,1).
(6) When the WTR timer expires, each node sends NR(1,1), because the last APS message it received was WTR.
(7) Each node gets NR(1,1), puts its selector and bridge back on the working entity, and sends an NR(0,0) message 🧚
(8) Both nodes confirm the far end is also on the working entity. Clean finish 💖
Example 3. 1:1 bidirectional protection switching (revertive mode) - Bidirectional SF case - Inconsistent WTR timers
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z<->A)) | (2)
|<---- SF(1,1)---->|
(3) | | (3)
| |
(4) | (Recovery) | (4)
|<---- NR(1,1)---->|
(5) |<--- WTR(1,1)---->| (5)
/| |\
WTR timer | | |
\| | WTR timer
(6) |----- NR(1,1)---->| | (7)
| |/
(9) |<----- NR(0,0)----| (8)
|---- NR(0,0)----->| (10)(1) Everything is healthy 🌈 The protected domain is running with no defects, and the working entity is carrying the normal traffic.
(2) Nodes A and Z both detect local SF conditions on the working entity. Each one sets its selector and bridge to the protection entity and sends an SF(1,1) message.
(3) Each node gets SF(1,1) and confirms the far end is also on the protection entity.
(4) Each node sees the SF condition clear and sends an NR(1,1) message, since the last APS message it received was SF.
(5) Each node gets NR(1,1), starts its WTR timer, and sends WTR(1,1).
(6) Node A's WTR timer expires first, so node A sends an NR(1,1) message, because the last APS message it received was WTR.
(7) Node Z's local WTR has higher priority, so the NR(1,1) it just received gets ignored 🙅♀️
(8) Node Z's WTR timer expires, so node Z puts its selector and bridge back on the working entity and sends an NR(0,0) message.
(9) Node A gets that NR(0,0), puts its selector and bridge back on the working entity, and sends an NR(0,0) message of its own.
(10) Both sides confirm the far end is on the working entity. Timers are a lot, bestie, but it all works out 🫶
Example 4. 1:1 bidirectional protection switching (non-revertive mode) - Unidirectional SF on working followed by unidirectional SF on protection
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(Z->A)) |
|----- SF(1,1)---->| (3)
(4) |<----- NR(1,1)----|
| |
| |
(5) | (Recovery) |
|----- DNR(1,1)--->| (6)
|<--- DNR(1,1)---->|
| |
| |
| (SF on P(A->Z)) | (7)
(8) |<--- SF-P(0,0)----|
|---- NR(0,0)----->|
| |
| |
| (Recovery) | (9)
|<----- NR(0,0)----|
| |(1) The protected domain is running with zero defects, and the working entity is carrying the normal traffic.
(2) Signal Fail hits the working entity in the Z to A direction. Node A's selector and bridge switch to the protection entity, and node A sends an SF(1,1) message.
(3) Node Z gets SF(1,1), sets its selector and bridge to the protection entity, and since it has no local request, it generates an NR(1,1) message.
(4) Node A confirms the far end is also on the protection entity 🌸
(5) Node A sees the SF condition clear and sends a DNR(1,1) message. Non-revertive mode means it's staying put on protection for now 🦋
(6) When node Z gets DNR(1,1), it generates a DNR(1,1) message of its own.
(7) Okay plot twist 😱 Signal Fail hits the protection entity in the A to Z direction. Node Z's selector and bridge switch to the working entity, and node Z generates an SF-P(0,0) message.
(8) Node A gets SF-P(0,0), sets its selector and bridge to the working entity, and generates an NR(0,0) message.
(9) Node Z detects the SF condition clear and sends an NR(0,0) message. Recovered, and no drama left 💅
Example 5. 1:1 bidirectional protection switching (non-revertive mode) - Bidirectional SF on working followed by bidirectional SF on protection
A Z
| |
(1) |---- NR(0,0)----->| (1)
|<----- NR(0,0)----|
| |
| |
(2) | (SF on W(A<->Z)) | (2)
(3) |<---- SF(1,1)---->| (3)
| |
| |
(4) | (Recovery) | (4)
(5) |<---- NR(1,1)---->| (5)
|<--- DNR(1,1)---->|
| |
| |
(6) | (SF on P(A<->Z)) | (6)
(7) |<--- SF-P(0,0)--->| (7)
| |
| |
(8) | (Recovery) | (8)
|<---- NR(0,0)---->|
| |(1) Everything is healthy 🌈 The protected domain is running with no defects, and the working entity is carrying the normal traffic.
(2) Nodes A and Z both detect local SF conditions on the working entity. Each one sets its selector and bridge to the protection entity and sends an SF(1,1) message.
(3) Each node gets SF(1,1) and confirms the far end is also on the protection entity.
(4) Each node sees its SF condition clear and sends an NR(1,1) message, since the last APS message it received was SF.
(5) Each node gets NR(1,1) and sends a DNR(1,1) message.
(6) Signal Fail now hits the protection entity in both directions at once 😭 Each node sets its selector and bridge back to the working entity and generates an SF-P(0,0) message.
(7) Each node gets SF-P(0,0) and confirms the far end is also on the working entity.
(8) Each node sees the SF condition clear and sends an NR(0,0) message. The whole thing is resolved, bestie 🫶✨
Authors' Addresses 💖
okay bestie, these are the squad members who wrote this spec, and they each left their contact info 🫶 ✨
- Huub van Helvoort (editor) 🎀
- Huawei Technologies
- EMail:
huub@van-helvoort.eu
- Jeong-dong Ryoo (editor) 🦋
- ETRI
- EMail:
ryoo@etri.re.kr
- Haiyan Zhang 🌸
- Huawei Technologies
- EMail:
zhanghaiyan@huawei.com
- Feng Huang 🧚
- Philips
- EMail:
feng.huang@philips.com
- Han Li 💜
- China Mobile
- EMail:
lihan@chinamobile.com
- Alessandro D'Alessandro 👑
- Telecom Italia
- EMail:
alessandro.dalessandro@telecomitalia.it
and that's a whole wrap, the spec is done!! 🌈💅 thank you for reading all the way to the end, you're literally the best 😭🫶
📦 where this page comes from
- ietf: rfc7347 2014-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms