RFC 7271
MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators
Title Block 💖
Request for Comments: 7271 🎀 Category: Standards Track ✨ Updates: 6378 (this one adds a capability advertisement method to RFC 6378 🦋) Obsoletes: nothing listed in the header 🙈 ISSN: 2070-1721 Date: June 2014 🌸
Authors: J. Ryoo (Editor, ETRI), E. Gray (Editor, Ericsson), H. van Helvoort (Huawei Technologies), A. D'Alessandro (Telecom Italia), T. Cheung (ETRI), and E. Osborne (no affiliation listed) 🫶
MPLS Transport Profile (MPLS-TP) Linear Protection to Match the Operational Expectations of Synchronous Digital Hierarchy, Optical Transport Network, and Ethernet Transport Network Operators 🌈
Abstract 🧚
okay so this doc is about giving MPLS-TP linear protection a glow-up 💅 It describes some alternate ways to do a few of the functions from RFC 6378 (see [RFC6378]), and it also adds brand new mechanisms. The whole point is giving operators the control and the experience they're used to from other transport networks, so it feels familiar. 🥹
It also introduces capabilities and modes. A capability is one individual behavior, and a mode is a specific combo of capabilities. Two modes are defined here: Protection State Coordination (PSC) mode and Automatic Protection Switching (APS) mode. ✨
The doc spells out how the PSC protocol behaves, including its priority logic and state machine, when every capability tied to APS mode is turned on. 👑
Last but not least, this doc updates RFC 6378, because the capability advertisement method defined here is an addition to that one. 🦋
Status of This Memo 📝
This is an Internet Standards Track document. 🔥
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. More info on Internet Standards lives in Section 2 of RFC 5741. 💜
For the current status, any errata, and how to send feedback, check out http://www.rfc-editor.org/info/rfc7271. 🍓
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 (http://trustee.ietf.org/license-info), as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes. 🫶
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Capability 1: Priority Modification . . . . . . . . . . . . . 6
4.1. Motivation for Swapping Priorities of FS and SF-P . . . . 6
4.2. Motivation for Raising the Priority of SFc . . . . . . . 7
4.3. Motivation for Introducing the Freeze Command . . . . . . 7
4.4. Procedures in Support of Priority Modification . . . . . 8
5. Capability 2: Non-revertive Behavior Modification . . . . . . 8
6. Capability 3: Support of the MS-W Command . . . . . . . . . . 8
6.1. Motivation for adding MS-W . . . . . . . . . . . . . . . 8
6.2. Terminology to Support MS-W . . . . . . . . . . . . . . . 9
6.3. Behavior of MS-P and MS-W . . . . . . . . . . . . . . . . 9
6.4. Equal-Priority Resolution for MS . . . . . . . . . . . . 10
7. Capability 4: Support of Protection against SD . . . . . . . 10
7.1. Motivation for Supporting Protection against SD . . . . . 10
7.2. Terminology to Support SD . . . . . . . . . . . . . . . . 10
7.3. Behavior of Protection against SD . . . . . . . . . . . . 11
7.4. Equal-Priority Resolution . . . . . . . . . . . . . . . . 12
8. Capability 5: Support of EXER Command . . . . . . . . . . . . 13
9. Capabilities and Modes . . . . . . . . . . . . . . . . . . . 14
9.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14
9.1.1. Sending and Receiving the Capabilities TLV . . . . . 15
9.2. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2.1. PSC Mode . . . . . . . . . . . . . . . . . . . . . . 16
9.2.2. APS Mode . . . . . . . . . . . . . . . . . . . . . . 16
10. PSC Protocol in APS Mode . . . . . . . . . . . . . . . . . . 17
10.1. Request Field in PSC Protocol Message . . . . . . . . . 17
10.2. Priorities of Local Inputs and Remote Requests . . . . . 17
10.2.1. Equal-Priority Requests . . . . . . . . . . . . . . 18
10.3. Acceptance and Retention of Local Inputs . . . . . . . . 20
11. State Transition Tables in APS Mode . . . . . . . . . . . . . 20
11.1. State Transition by Local Inputs . . . . . . . . . . . . 23
11.2. State Transition by Remote Messages . . . . . . . . . . 25
11.3. State Transition for 1+1 Unidirectional Protection . . . 27
12. Provisioning Mismatch and Protocol Failure in APS Mode . . . 27
13. Security Considerations . . . . . . . . . . . . . . . . . . . 28
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
14.1. MPLS PSC Request Registry . . . . . . . . . . . . . . . 29
14.2. MPLS PSC TLV Registry . . . . . . . . . . . . . . . . . 29
14.3. MPLS PSC Capability Flag Registry . . . . . . . . . . . 29
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
16.1. Normative References . . . . . . . . . . . . . . . . . . 30
16.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. An Example of an Out-of-Service Scenario . . . . . . 32
Appendix B. An Example of a Sequence Diagram Showing
the Problem with the Priority Level of SFc . . . . . 33
Appendix C. Freeze Command . . . . . . . . . . . . . . . . . . . 34
Appendix D. Operation Examples of the APS Mode . . . . . . . . . 351. Introduction 🦋
okay bestie, so the linear protection mechanisms for MPLS-TP are described in RFC 6378 [RFC6378], and they're there to meet the requirements from RFC 5654 [RFC5654]. ✨
This document comes in with alternate mechanisms for some of the linear protection functions, plus some additional mechanisms. The goal is operator control and experience that feels a lot like linear protection in other transport networks, like Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), and Ethernet transport networks. The linear protection for those networks is defined in ITU-T Recommendations G.841 [G841], G.873.1 [G873.1], and G.8031 [G8031], in that order. 🌸
You're assumed to already know [RFC6378], so no need to re-explain the basics 💅
The alternative mechanisms in this doc cover these capabilities:
- Priority modification,
- non-revertive behavior modification,
and these capabilities are new, added to define additional mechanisms:
- support of the Manual Switch to Working path (MS-W) command,
- support of protection against Signal Degrade (SD), and
- support of the Exercise (EXER) command.
Priority modification means raising the priority of Signal Fail on Protection path (SF-P) relative to Forced Switch (FS), and raising the priority level of Clear Signal Fail (SFc) above SF-P. 🔥
Non-revertive behavior gets modified so it lines up with RFC 4427 [RFC4427], and so it also follows the way linear protection behaves in other transport networks. 💜
Support for the MS-W command, which reverts traffic to the working path in non-revertive operation, is covered here. 🍓
Support for the protection-switching protocol against SD is covered here too. How you actually identify SD is out of scope for this doc. It's handled the same way as Signal Fail (SF) in [RFC6378]. 🧚
Support for the EXER command is covered as well. It tests whether Protection State Coordination (PSC) communication is working correctly. The cool part is that it does this without switching any traffic. EXER tests and validates the linear protection mechanism and the PSC protocol, including whether the priority logic, PSC state machine, PSC message generation and reception, and the protection path's integrity are all alive and well. 🫶
This doc introduces capabilities and modes. A capability is an individual behavior, and a node's capabilities get advertised using the method in this document. A mode is a particular combo of capabilities. Two modes are defined here: PSC mode and Automatic Protection Switching (APS) mode. 👑
Other modes can be defined later, either as new combos of the capabilities in this doc or by defining new capabilities. Either way, whoever writes the spec for a new mode is on the hook for documenting that mode's PSC protocol behavior, priority logic, and state machine when its set of capabilities is enabled. 🌈
This doc describes the behavior, priority logic, and state machine of the PSC protocol when every capability tied to APS mode is enabled. The PSC protocol behavior for PSC mode is whatever [RFC6378] says. 🎀
This document updates [RFC6378] by adding a capability advertisement mechanism. It is recommended that existing implementations of the PSC protocol be updated to support this capability. Backward compatibility with existing implementations that don't support this mechanism is covered in Section 9.2.1. ✨
Implementations are expected to be configured for one specific set of capabilities (a mode), and to reject messages that signal a different set of capabilities (a different mode). So the capability advertisement isn't a negotiation. It's just a check that peers are using the same mode. 💅
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 RFC 2119 [RFC2119]. 🔥
3. Acronyms 💅✨
okay bestie, here's the acronym cheat sheet 🎀 this doc uses the following acronyms:
APS Automatic Protection Switching
DNR Do-not-Revert
EXER Exercise
FS Forced Switch
LO Lockout of protection
MS Manual Switch
MS-P Manual Switch to Protection path
MS-W Manual Switch to Working path
MPLS-TP MPLS Transport Profile
NR No Request
OC Operator Clear
OTN Optical Transport Network
PSC Protection State Coordination
RR Reverse Request
SD Signal Degrade
SD-P Signal Degrade on Protection path
SD-W Signal Degrade on Working path
SDH Synchronous Digital Hierarchy
SF Signal Fail
SF-P Signal Fail on Protection path
SF-W Signal Fail on Working path
SFc Clear Signal Fail
SFDc Clear Signal Fail or Degrade
WTR Wait-to-Restore4. Capability 1: Priority Modification 🔥
okay so [RFC6378] says FS outranks SF-P 💀 and it says Clear SF (SFc) is low priority too. this doc swaps the vibe: FS and SF-P trade places, and SFc gets bumped up 📈. it also adds a Freeze command (see Appendix C) 🧊. the reasons are below, from both the technical side and the network-ops side 🦋
4.1. Motivation for Swapping Priorities of FS and SF-P 🌸
ngl this one is kinda scary 😭 if FS beats SF-P, the protected traffic can get kicked out of service. when the protection path fails, PSC communication might stop too. so if anything that needs to be signaled to the other end outranks SF-P, you can end up in a protection-switching state nobody can predict 🙈 there's an example of an out-of-service situation in Appendix A.
according to Section 2.4 of [RFC5654], it MUST be possible to operate an MPLS-TP network without using a control plane 🧚 so the PSC channel matters a LOT for moving external switching commands (like FS), and those commands shouldn't need a control plane to work. so a failure of the PSC channel outranks FS. period 👑
other transport networks (SDH, OTN, Ethernet transport) have always had SF-P outrank FS 🍓 so operators want MPLS-TP to act the same way, so their muscle memory still works. like, an FS usually goes out before maintenance (swapping optical cables, other gear). if an operator yanks a cable on the protection path by accident, the traffic should keep being protected, and they expect that because of how traditional transport networks have always behaved ✨
4.2. Motivation for Raising the Priority of SFc 💜
the SFc priority in [RFC6378] can cause traffic disruption when a node that had local signal fails on both the working and protection paths is recovering from them 😬
there's a sequence diagram showing the SFc problem as defined in [RFC6378] in Appendix B 🎀
4.3. Motivation for Introducing the Freeze Command 🧊
with FS and SF-P swapped, traffic always moves back to the working path when SF-P happens in Protecting Administrative state. but what if operators want traffic to stay on the protection path even when the PSC channel is broken? that's what Freeze is for 🙌 it's a "local" command, so it isn't signaled to the remote node. see Appendix C for how to use it 💖
4.4. Procedures in Support of Priority Modification 📋
when the modified priority order from this doc is in use, the list of local requests in order of priority SHALL be as follows (highest to lowest):
- Clear Signal Fail
- Signal Fail on Protection path
- Forced Switch
- Signal Fail on Working path
this needs changes to the PSC Control Logic (including the state machine) compared to [RFC6378]. Sections 10 and 11 show the PSC Control Logic when all APS mode capabilities are enabled 🦋
5. Capability 2: Non-revertive Behavior Modification 🌈
non-revertive protection switching is defined in [RFC4427] 💅 in this mode, traffic doesn't go back to the working path when switch-over requests end.
BUT 😤 [RFC6378]'s PSC only supports this when recovering from a defect condition. it does NOT support the non-revertive function when an operator's switch-over command (like FS or Manual Switch (MS)) gets cleared. to match other transport networks and stay consistent with [RFC4427], a node should go into the Do-not-Revert (DNR) state not just when a failure on the working path clears, but also when an operator command requesting switch-over gets cleared 🫶
this needs changes to the PSC Control Logic (including the state machine) compared to [RFC6378]. Sections 10 and 11 show the PSC Control Logic when all APS mode capabilities are enabled ✨
6. Capability 3: Support of the MS-W Command 🎀
6.1. Motivation for adding MS-W 💖
changing non-revertive operation (see Section 5) means we need a new operator command to bring traffic back to the working path while in the DNR state 🙏 when traffic is on the protection path in DNR, a Manual Switch to Working (MS-W) command switches normal traffic back to the working path. per Section 4.3.3.6 (Do-not-Revert State) in [RFC6378]: "To revert back to the Normal state, the administrator SHALL issue a Lockout of protection command followed by a Clear command." 😩 but using Lockout of protection (LO) can leave you unprotected while LO is active, which is risky 🙈
the "Manual switch-over for recovery LSP/span" command is defined in [RFC4427]. Requirement 83 in [RFC5654] says the external commands defined in [RFC4427] MUST be supported. [RFC6378] doesn't support this external command, so this functionality should be added to PSC 🌸 that's what MS-W does: it corresponds to the "Manual switch-over for recovery LSP/span" command 👑
6.2. Terminology to Support MS-W 🧚
[RFC6378] uses "Manual Switch" and its acronym "MS". this doc uses "Manual Switch to Protection path" and "MS-P" to mean the same thing, so it doesn't get mixed up with "Manual Switch to Working path" and "MS-W" 🍓
we also rename the "Protecting Administrative" state (from [RFC6378]) to "Switching Administrative" 🦋 this covers the case where traffic is switched to the working path because of the external MS-W command.
6.3. Behavior of MS-P and MS-W 💅
MS-P and MS-W SHALL have the same priority ✨ we look at a couple of cases for figuring out priority when commands arrive one after another or at the same time:
- when two commands arrive in succession, the command received after the first one SHALL be cancelled 🙅♀️
- if two nodes simultaneously get commands asking for opposite operations (one gets MS-P, the other gets MS-W) and they both send those to the remote node, MS-W SHALL be considered higher priority, and MS-P SHALL be cancelled and discarded 😤
MS-P and MS-W are sent with the same Request field value, but they SHALL indicate in the Fault Path (FPath) value which path the traffic is being diverted from 🌈 when traffic moves to the protection path, FPath SHALL be set to 1 (diverted from the working path). when traffic moves to the working path, FPath SHALL be set to 0 (diverted from the protection path). the Data Path (Path) field SHALL show where user data is being carried: working path selected means Path is 0, protection path selected means Path is 1 💖
when an MS command is in effect at a node, any later MS or EXER command and any other lower-priority requests SHALL be ignored 🛑
6.4. Equal-Priority Resolution for MS 🔥
[RFC6378] has only one rule for the equal-priority case, in Section 4.3.2: "The remote message from the far-end LER is assigned a priority just below the similar local input." 🤏 to support the Manual Switch behavior from Section 6.3, we need extra equal-priority rules. since protecting against signal degrade needs similar equal-priority handling too, those rules are in Section 7.4 🫶
supporting this needs changes to the PSC Control Logic (including the state machine) compared to [RFC6378]. Sections 10 and 11 show the PSC Control Logic when all APS mode capabilities are enabled 💜
7. Capability 4: Support of Protection against SD 🌸
7.1. Motivation for Supporting Protection against SD 🧚
the MPLS-TP Survivability Framework in [RFC6372] says both SF and SD fault conditions can trigger protection switching 🙌
[RFC6378] is the protection-switching protocol for MPLS-TP, but it doesn't say how SF and SD get detected, and it only covers the protection-switching protocol for SF 😬
this doc covers the PSC protocol for SD. how SD gets detected is out of scope for the protection protocol, same as SF detection and MS or FS command initiation 🦋
7.2. Terminology to Support SD 💅
in this doc, Clear Signal Fail or Degrade (SFDc) means the clearing of either a degraded condition or a failure condition ✨
the second paragraph of Section 4.3.3.2 (Unavailable State) in [RFC6378] shows the intent to put Signal Degrade on Protection path (SD-P) in the Unavailable state. even though the protection path can be partly available with SD-P, this doc follows the same state grouping as [RFC6378] for SD-P 🎀
the bulleted item on the Protecting Failure state in Section 3.6 of [RFC6378] puts the degraded condition in the Protecting Failure state. this doc follows that same state grouping as [RFC6378] for Signal Degrade on Working path (SD-W) 💖
7.3. Behavior of Protection against SD ✨
okay so bestie, we want MPLS-TP networks to actually line up with the other transport crews (SDH, OTN, and Ethernet transport networks) 💅 so we define these:
- The priorities of SD-P and SD-W SHALL be equal.
- Once a switch has been completed due to SD on one path, it will not be overridden by SD on the other path (first come, first served behavior), to avoid protection switching that cannot improve signal quality. 🙈
okay the SD message is basically the node going "hey, something's off with the signal or packet integrity on either the working path or the protection path" 🚨 The FPath field SHALL identify the path that is reporting the degraded condition (so if it's the protection path, FPath is set to 0, and if it's the working path, FPath is set to 1). The Path field SHALL indicate where the data traffic is actually being sent (working path selected means Path is 0, protection path selected means Path is 1). 🎀
when the SD condition clears and the protected domain is recovering, the Wait-to-Restore (WTR) timer SHALL be used if the domain is set up for revertive behavior ⏳ The WTR timer SHALL start at the node that recovers from a local degraded condition on the working path. no cap, it's giving patience 🧚
now the really iconic part 🔥 Protection switching against SD is always handled by a selector bridge that duplicates the user data traffic and feeds it to both the working path and the protection path while there's an SD condition. When a local or remote SD shows up on either path, the node SHALL duplicate the user data traffic and SHALL feed it to both paths. The duplication SHALL keep going as long as any SD condition exists in the protected domain. When the SD condition clears, in revertive operation the duplication SHALL continue in the WTR state and SHALL stop once the node leaves the WTR state. In non-revertive operation, the duplication SHALL stop immediately. 💜
the selector bridge doing the duplication under SD is non-permanent, and it still counts as a 1:1 protection architecture ✨
protection switching against SD doesn't change how the selector at the sink node works (the one described in [RFC6378]) 🦋 The selector picks either the working or protection path to receive normal traffic in both 1:1 and 1+1 architectures. Where it points is decided by the PSC protocol in bidirectional switching, or by the local input in unidirectional switching. 💖
7.4. Equal-Priority Resolution 👑
so to make the MS behavior from Section 6.3 and the protection against SD from Section 7.3 work together, we have to expand the rules for handling equal-priority inputs 🫶
for equal-priority local inputs like MS and SD, it's a simple first-come, first-served rule. Once a local input is the highest priority local input, any later equal-priority local input asking for a different action (meaning the action ends up with the same PSC Request field but a different FPath value) will NOT be presented to the PSC Control Logic as the highest local request. And if it's an MS command, the later local MS command asking for something different gets cancelled. 💅
if a node is already in a remote state because of a remote SD (or MS) message, then a later local input with the same priority that asks for something different gets treated as lower priority than the remote message and gets ignored. 🙈 For example, if a node is in remote Switching Administrative state because of a remote MS-P, then any later local MS-W SHALL be ignored and automatically cancelled. If a node is in remote Unavailable state because of a remote SD-P, then any later local SD-W input will be ignored. However, the local SD-W SHALL continue to show up in the Local Request Logic as long as the SD condition exists, but it SHALL NOT be the top-priority global request, which is the thing that decides the state transition at the PSC Control Logic. 🧚
okay so there are cases where both end-points of the protected domain get local triggers of the same priority that want different things (for example, one node gets SD-P and the other gets SD-W). Then each node receives a remote message with the opposite action indication. To deal with these moments, we define these priority resolution rules:
- When MS-W and MS-P occur simultaneously at both nodes, MS-W SHALL be considered as having higher priority than MS-P at both nodes.
- When SD-W and SD-P occur simultaneously at both nodes, the SD on the standby path (the path from which the selector does not select the user data traffic) is considered as having higher priority than the SD on the active path (the path from which the selector selects the user data traffic), regardless of its origin (local or remote message). That means no unnecessary protection switching gets done, and the user data traffic keeps being selected from the active path. 🌈
in the paragraphs above, "simultaneously" means the case where a sent SD (or MS) request hasn't been confirmed by the remote end in bidirectional protection switching. When a local node that already sent an SD message receives an SD (or MS) message with a different Path field value than the one it sent, both the local and remote SD requests count as happening simultaneously 🌸
adding protection against SD means the PSC Control Logic (including the state machine) has to change compared to what's described in [RFC6378]. Sections 10 and 11 show the PSC Control Logic when all APS mode capabilities are enabled. 💜
8. Capability 5: Support of EXER Command 🎀
the EXER command is how we check that the PSC communication is working right ✨ That means making sure the Local Request Logic is alive, the PSC Control Logic is intact, the PSC message generation and reception mechanism works, and the protection path is healthy. EXER does NOT trigger any actual traffic switching. 🦋
this command only matters for bidirectional protection switching, because it depends on getting a response from the remote node. EXER is given lower priority than any switching message. It may be used regardless of the traffic usage of the working path. 🍓
when a node gets a remote EXER message, it SHOULD respond with a Reverse Request (RR) message, with the FPath and Path fields set according to the node's current condition 💅 The RR message SHALL be generated only in response to a remote EXER message. 🙈
this command is documented in R84 of [RFC5654] 📚
if EXER commands get input at both ends, a race condition can happen. Here's how it gets sorted out:
- If a node has issued EXER and receives EXER before receiving RR, it MUST treat the received EXER as it would an RR, and it SHOULD NOT respond with RR. 🫶
the following PSC Requests get added to the PSC Request field to support the Exercise command (see also Section 14.1):
- (3) Exercise - indicates that the transmitting end-point is exercising the protection channel and mechanism. FPath and Path are set to the same value of the No Request (NR), RR, or DNR message whose transmission is stopped by EXER.
- (2) Reverse Request - indicates that the transmitting end-point is responding to an EXER command from the remote node. FPath and Path are set to the same value of the NR or DNR message whose transmission is stopped by RR.
the relative priorities of EXER and RR are defined in Section 10.2 ⭐
9. Capabilities and Modes 👑
9.1. Capabilities 💖
a Capability is one individual behavior whose use gets signaled in a Capabilities TLV. That TLV goes in the Optional TLVs field inside the PSC message shown in Figure 2 of [RFC6378] ✨ The format of the Capabilities TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = Capabilities | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value = Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: Format of Capabilities TLV
the Type field value is 1 🌸
the Length field value is the length of the Flags field in octets. The Flags field MUST be a multiple of 4 octets and MUST be the minimum required to signal all the required capabilities. 🧚
Sections 4 to 8 cover five capabilities signaled using the five most significant bits. If a node wants to signal these five capabilities, it MUST send a Flags field of 4 octets. A node would send a Flags field bigger than 4 octets only if it had more than 32 Capabilities to indicate. All unused bits MUST be set to zero. 🦋
if the bit for an individual capability is set to 1, that means the sending node intends to use that capability in the protected domain. If it's set to 0, the sending node does NOT intend to use it in the protected domain. Note that you can't tell the difference between "I don't intend to use this capability" and "I don't support this capability at all (aka I haven't implemented it)" 🙈
this document defines five specific capabilities, described in Section 4 to Section 8. Each capability gets a bit like this:
0x80000000: priority modification
0x40000000: non-revertive behavior modification
0x20000000: support of MS-W command
0x10000000: support of protection against SD
0x08000000: support of EXER commandif all five capabilities should be used, a node SHALL set the Flags field to 0xF8000000 👑
9.1.1. Sending and Receiving the Capabilities TLV 📬
a node MUST include its Capabilities TLV in every PSC message it transmits. The transmission and acceptance of the PSC message is described in Section 4.1 of [RFC6378] 💌
when a node receives a Capabilities TLV, it MUST compare the Flags value to the most recent Flags value it transmitted. If the two are equal, the protected domain is running in the mode indicated by that set of capabilities (see Section 9.2) ✨ If the sent and received Capabilities TLVs are NOT equal, that's a Capabilities TLV mismatch.
When this happens, the node MUST alert the operator and MUST NOT perform any protection switching until the operator resolves the mismatch between the two end-points. 🚨
9.2. Modes 🌈
a mode is a given set of Capabilities. Modes are just shorthand 💅 Referring to a set of capabilities by their individual values or by the name of their mode does NOT change the protocol behavior. This document defines two modes -- PSC and APS. Capabilities TLVs with other combinations than the one specified by a mode are not supported in this specification. 🦋
9.2.1. PSC Mode 🎀
okay so PSC mode is basically the "no extras, thank u" setting 💅. It means you don't support any of the additional capabilities in this doc, so your Capabilities set is 0x0. And it's the behavior from [RFC6378] 🌸
There are two ways to declare PSC mode 🦋 A node can send no Capabilities TLV at all (since [RFC6378] doesn't define any TLV units, that's valid), or it can send a Capabilities TLV with the Flags value set to 0x0. Now here's the lowkey clever part 🧚 Two endpoints might not be the same kind of smart. One can send Capabilities TLVs and one can't, so the node that CAN send and process the PSC mode Capabilities TLV MUST be able to do BOTH: send the PSC mode Capabilities TLV AND send no Capabilities TLV at all. And an implementation MUST be configurable between those two options 💜 Main character backwards-compat energy, no cap 👑
9.2.2. APS Mode 🌈
APS mode is the full glam: all five of the specific capabilities, the ones covered in Sections 4 to 8 of this document 💖 You turn APS mode on with the Flags value 0xF8000000 ✨
10. PSC Protocol in APS Mode 🧚
okay this section and the next one are the rules for the PSC protocol when every single one of those capabilities is turned on, aka APS mode 🔥 Let's gooo 😭
10.1. Request Field in PSC Protocol Message 💌
This doc adds two brand new values to the "Request" field of the PSC protocol message (the one shown in Figure 2 of [RFC6378]) 🍓 They're:
(2) Reverse Request
(3) Exercise
And if you want the full details, check out Section 14.1 of this document 🫶
10.2. Priorities of Local Inputs and Remote Requests 👑
okay this one is a whole thing, so bear with me 🙈 Based on what's described in Sections 3 and 4.3.2 in [RFC6378], the priorities of multiple outstanding local inputs get sorted out in the Local Request Logic, where the highest priority local input (the highest local request) gets picked. That highest local request then goes to the PSC Control Logic, which figures out the higher-priority input (the top-priority global request) between the highest local request and the last received remote message. And when a remote message shows up at the PSC Control Logic, the top-priority global request is decided between that remote message and whatever the highest local request is. The top-priority global request is what drives the state transition, which is covered in Section 11 ✨ Also, to keep the PSC Control Logic description simple, this doc strictly decouples the priority evaluation from the state transition table lookup 🦋
Here's the priority order for both local and remote requests, from highest to lowest 💅
- Operator Clear (Local only)
- Lockout of protection (Local and Remote)
- Clear Signal Fail or Degrade (Local only)
- Signal Fail on Protection path (Local and Remote)
- Forced Switch (Local and Remote)
- Signal Fail on Working path (Local and Remote)
- Signal Degrade on either Protection path or Working path (Local and Remote)
- Manual Switch to either Protection path or Working path (Local and Remote)
- WTR Timer Expiry (Local only)
- WTR (Remote only)
- Exercise (Local and Remote)
- Reverse Request (Remote only)
- Do-Not-Revert (Remote only)
- No Request (Remote and Local)
Now, the "Local only" requests never get sent to the remote node 🙅♀️ And the "Remote only" requests don't exist in the Local Request Logic as local inputs 🌸 Like, the priority of WTR only applies to the WTR message that comes in from the remote node. The remote node running its WTR timer in the WTR state has no local request, so it's giving "no local request" vibes 🥺
The remote SF and SD on either the working path or the protection path, plus the remote MS to either path, are shown by the values of the Request and FPath fields in the PSC message 🧚
A remote request gets a priority just below the same local request, EXCEPT for NR and equal-priority requests (like SD and MS). Since a received NR message has to be used in the state transition table lookup when there's no outstanding local request, the remote NR request SHALL have a higher priority than the local NR 🫧 For the equal-priority requests, check out Section 10.2.1 💖
10.2.1. Equal-Priority Requests 🌈
as Section 10.2 already said, a remote request is assigned a priority just below the same local request 💅 BUT for equal-priority requests, like SD and MS, the priority SHALL be evaluated the way this section describes, so pay attention lol 🙈
For equal-priority local requests, the first-come, first-served rule SHALL be applied ⏰ Once a local request shows up in the Local Request Logic, a later equal-priority local request that asks for a different action (meaning it gives the same Request value but a different FPath value) SHALL be considered to have a lower priority 🥀 And, for an MS command specifically, the later local MS command asking for a different action SHALL be rejected and cleared 💀
When the priority is being evaluated in the PSC Control Logic between the highest local request and a remote request, these equal-priority resolution rules SHALL be applied 👑
- If two requests ask for the same action (same Request and FPath values), then the local request SHALL be considered to have a higher priority than the remote request. 💜
- When the highest local request reaches the PSC Control Logic, if a remote request asking for a different action exists, then the highest local request SHALL be ignored and the remote request SHALL remain the top-priority global request. For an MS command, the local MS command asking for a different action SHALL be cancelled. 🙅♀️
- When the remote request reaches the PSC Control Logic, if the highest local request asking for a different action exists, then the top-priority global request SHALL be determined by these rules:
- For MS requests, the MS-W request SHALL be considered to have a higher priority than the MS-P request. The node that has the local MS-W request SHALL maintain the local MS-W request as the top-priority global request. The other node, the one that has the local MS-P request, SHALL cancel the MS-P command and SHALL generate "Operator Clear" internally as the top-priority global request. 🫶
- For SD requests, the SD on the standby path (the path the selector does NOT select for user data traffic) SHALL be considered to have a higher priority than the SD on the active path (the path the selector DOES select for user data traffic), no matter where it came from (local or remote message). The node that has the SD on the standby path SHALL maintain the local SD on the standby path request as the top-priority global request. The other node that has the local SD on the active path SHALL use the remote SD on the standby path as the top-priority global request to look up the state transition table. The active and standby paths are told apart by which path was selected for user data traffic when each node detected its local SD 🧚
10.3. Acceptance and Retention of Local Inputs 🦋
A local input that indicates a defect, like SF-P, SF-W, SD-P, and SD-W, SHALL be accepted and kept persistently in the Local Request Logic for as long as the defect condition exists 🥹 If there's any higher-priority local input than the local defect input, that higher-priority input gets passed to the PSC Control Logic as the highest local request, but the local defect input can't be removed and just stays in the Local Request Logic 🌸 Once the higher-priority local input is cleared, the local defect becomes the highest local request again, as long as the defect condition still exists 💅
The Operator Clear (OC) command, SFDc, and WTR Timer Expiry are NOT persistent 🙅♀️ Once they show up in the Local Request Logic and finish all the operations in the protection-switching control, they SHALL disappear 🫧
The LO, FS, MS, and EXER commands SHALL be rejected if there's any higher-priority local input in the Local Request Logic 🙈 If a new higher-priority local request (including an operator command) is accepted, any previous lower-priority local operator command SHALL be cancelled 💀 When any higher-priority remote request is received, a lower-priority local operator command SHALL be cancelled too. The cancelled operator command is cleared 🥀 If the operators want to renew a cancelled command, they should reissue it 💖
11. State Transition Tables in APS Mode ✨
okay bestie, this is where the state machine gets its whole glow-up 💅 whenever the highest local request changes or remote PSC messages roll in, the top-priority global request SHALL be evaluated, and the state transition tables SHALL be looked up in the PSC Control Logic 🔥 here are the rules for that lookup, no cap:
- If the top-priority global request, which determines the state transition, is the highest local request, the local state transition table in Section 11.1 SHALL be used to decide the next state of the node. Otherwise, the remote state transition table in Section 11.2 SHALL be used. 🎀
- If in remote state, the highest local defect condition (SF-P, SF-W, SD-P, or SD-W) SHALL always be reflected in the Request and FPath fields. 💖
- For the node currently in the local state, if the top-priority global request is changed to OC or SFDc, causing the next state to be Normal, WTR, or DNR, then all the local and remote requests SHALL be re-evaluated as if the node is in the state specified in the footnotes to the state transition tables, before deciding the final state. If there are no active requests, the node enters the state specified in the footnotes to the state transition tables. This re-evaluation is an internal operation confined within the local node, and the PSC messages are generated according to the final state. 🧚
- The WTR timer is started only when the node that has recovered from a local failure or degradation enters the WTR state. A node that is entering into the WTR state due to a remote WTR message does not start the WTR timer. The WTR timer SHALL be stopped when any local or remote request triggers the state change out of the WTR state. ⏱️
The extended states, as they show up in the tables, go like this 🦋
N Normal state
UA:LO:L Unavailable state due to local LO command
UA:P:L Unavailable state due to local SF-P
UA:DP:L Unavailable state due to local SD-P
UA:LO:R Unavailable state due to remote LO message
UA:P:R Unavailable state due to remote SF-P message
UA:DP:R Unavailable state due to remote SD-P message
PF:W:L Protecting Failure state due to local SF-W
PF:DW:L Protecting Failure state due to local SD-W
PF:W:R Protecting Failure state due to remote SF-W message
PF:DW:R Protecting Failure state due to remote SD-W message
SA:F:L Switching Administrative state due to local FS command
SA:MW:L Switching Administrative state due to local MS-W command
SA:MP:L Switching Administrative state due to local MS-P command
SA:F:R Switching Administrative state due to remote FS message
SA:MW:R Switching Administrative state due to remote MS-W message
SA:MP:R Switching Administrative state due to remote MS-P message
WTR Wait-to-Restore state
DNR Do-not-Revert state
E::L Exercise state due to local EXER command
E::R Exercise state due to remote EXER messageEach state corresponds to the transmission of a particular set of Request, FPath, and Path fields. The table below lists the message that is generally sent in each particular state. If the message to be sent in a particular state deviates from the table below, it is noted in the footnotes of the state transition tables. 📝
State Request(FPath,Path)
------- ------------------------------------
N NR(0,0)
UA:LO:L LO(0,0)
UA:P:L SF(0,0)
UA:DP:L SD(0,0)
UA:LO:R highest local request(local FPath,0)
UA:P:R highest local request(local FPath,0)
UA:DP:R highest local request(local FPath,0)
PF:W:L SF(1,1)
PF:DW:L SD(1,1)
PF:W:R highest local request(local FPath,1)
PF:DW:R highest local request(local FPath,1)
SA:F:L FS(1,1)
SA:MW:L MS(0,0)
SA:MP:L MS(1,1)
SA:F:R highest local request(local FPath,1)
SA:MW:R NR(0,0)
SA:MP:R NR(0,1)
WTR WTR(0,1)
DNR DNR(0,1)
E::L EXER(0,x), where x is the existing Path value
when Exercise command is issued.
E::R RR(0,x), where x is the existing Path value
when RR message is generated.Some operation examples of APS mode are shown in Appendix D, so go peek if you want to see it in action 👀
In the state transition tables below, the letter 'i' stands for "ignore" 🙈 it means remain in the current state and keep transmitting the current PSC message, simple as that.
11.1. State Transition by Local Inputs 🌸
| OC | LO | SFDc | SF-P | FS | SF-W |
--------+-----+---------+------+--------+--------+--------+
N | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
UA:LO:L | (1) | i | i | i | i | i |
UA:P:L | i | UA:LO:L | (1) | i | i | i |
UA:DP:L | i | UA:LO:L | (1) | UA:P:L | SA:F:L | PF:W:L |
UA:LO:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L |
UA:P:R | i | UA:LO:L | i | UA:P:L | i | PF:W:L |
UA:DP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
PF:W:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | i |
PF:DW:L | i | UA:LO:L | (2) | UA:P:L | SA:F:L | PF:W:L |
PF:W:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
PF:DW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
SA:F:L | (3) | UA:LO:L | i | UA:P:L | i | i |
SA:MW:L | (1) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
SA:MP:L | (3) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
SA:F:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
SA:MW:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
SA:MP:R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
WTR | (4) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
DNR | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
E::L | (5) | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |
E::R | i | UA:LO:L | i | UA:P:L | SA:F:L | PF:W:L |(Continued)
| SD-P | SD-W | MS-W | MS-P | WTRExp | EXER
--------+---------+---------+---------+---------+--------+------
N | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L
UA:LO:L | i | i | i | i | i | i
UA:P:L | i | i | i | i | i | i
UA:DP:L | i | i | i | i | i | i
UA:LO:R | UA:DP:L | PF:DW:L | i | i | i | i
UA:P:R | UA:DP:L | PF:DW:L | i | i | i | i
UA:DP:R | UA:DP:L | PF:DW:L | i | i | i | i
PF:W:L | i | i | i | i | i | i
PF:DW:L | i | i | i | i | i | i
PF:W:R | UA:DP:L | PF:DW:L | i | i | i | i
PF:DW:R | UA:DP:L | PF:DW:L | i | i | i | i
SA:F:L | i | i | i | i | i | i
SA:MW:L | UA:DP:L | PF:DW:L | i | i | i | i
SA:MP:L | UA:DP:L | PF:DW:L | i | i | i | i
SA:F:R | UA:DP:L | PF:DW:L | i | i | i | i
SA:MW:R | UA:DP:L | PF:DW:L | SA:MW:L | i | i | i
SA:MP:R | UA:DP:L | PF:DW:L | i | SA:MP:L | i | i
WTR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | (6) | i
DNR | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::L
E::L | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | i
E::R | UA:DP:L | PF:DW:L | SA:MW:L | SA:MP:L | i | E::LNOTES 📌
(1) Re-evaluate to determine the final state as if the node is in the Normal state. If there are no active requests, the node enters the Normal State.
(2) In the case that both local input after SFDc and the last received remote message are NR, the node enters into the WTR state when the domain is configured for revertive behavior, or the node enters into the DNR state when the domain is configured for non-revertive behavior. In all the other cases, where one or more active requests exist, re-evaluate to determine the final state as if the node is in the Normal state.
(3) Re-evaluate to determine final state as if the node is in the Normal state when the domain is configured for revertive behavior, or as if the node is in the DNR state when the domain is configured for non-revertive behavior. If there are no active requests, the node enters either the Normal state when the domain is configured for revertive behavior or the DNR state when the domain is configured for non-revertive behavior.
(4) Remain in the WTR state and send an NR(0,1) message. Stop the WTR timer if it is running. In APS mode, OC can cancel the WTR timer and hasten the state transition to the Normal state, as in other transport networks. ⏰
(5) If Path value is 0, re-evaluate to determine final state as if the node is in the Normal state. If Path value is 1, re-evaluate to determine final state as if the node is in the DNR state. If there are no active requests, the node enters the Normal state when Path value is 0, or the DNR state when Path value is 1.
(6) Remain in the WTR state and send an NR(0,1) message.
11.2. State Transition by Remote Messages 🦋
| LO | SF-P | FS | SF-W | SD-P | SD-W |
--------+---------+--------+--------+--------+---------+---------+
N | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
UA:LO:L | i | i | i | i | i | i |
UA:P:L | UA:LO:R | i | i | i | i | i |
UA:DP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | (7) |
UA:LO:R | i | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
UA:P:R | UA:LO:R | i | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
UA:DP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | i | PF:DW:R |
PF:W:L | UA:LO:R | UA:P:R | SA:F:R | i | i | i |
PF:DW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | (8) | i |
PF:W:R | UA:LO:R | UA:P:R | SA:F:R | i | UA:DP:R | PF:DW:R |
PF:DW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | i |
SA:F:L | UA:LO:R | UA:P:R | i | i | i | i |
SA:MW:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
SA:MP:L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
SA:F:R | UA:LO:R | UA:P:R | i | PF:W:R | UA:DP:R | PF:DW:R |
SA:MW:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
SA:MP:R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
WTR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
DNR | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
E::L | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R |
E::R | UA:LO:R | UA:P:R | SA:F:R | PF:W:R | UA:DP:R | PF:DW:R | | MS-W | MS-P | WTR | EXER | RR | DNR | NR
--------+---------+---------+-----+------+----+------+----
N | SA:MW:R | SA:MP:R | i | E::R | i | i | i
UA:LO:L | i | i | i | i | i | i | i
UA:P:L | i | i | i | i | i | i | i
UA:DP:L | i | i | i | i | i | i | i
UA:LO:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N
UA:P:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N
UA:DP:R | SA:MW:R | SA:MP:R | i | E::R | i | i | N
PF:W:L | i | i | i | i | i | i | i
PF:DW:L | i | i | i | i | i | i | i
PF:W:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11)
PF:DW:R | SA:MW:R | SA:MP:R | (9) | E::R | i | (10) | (11)
SA:F:L | i | i | i | i | i | i | i
SA:MW:L | i | i | i | i | i | i | i
SA:MP:L | i | i | i | i | i | i | i
SA:F:R | SA:MW:R | SA:MP:R | i | E::R | i | DNR | N
SA:MW:R | i | SA:MP:R | i | E::R | i | i | N
SA:MP:R | SA:MW:R | i | i | E::R | i | DNR | N
WTR | SA:MW:R | SA:MP:R | i | i | i | i | (12)
DNR | SA:MW:R | SA:MP:R | (13)| E::R | i | i | i
E::L | SA:MW:R | SA:MP:R | i | i | i | i | i
E::R | SA:MW:R | SA:MP:R | i | i | i | DNR | NOkay so the table keeps going and it is still giving chaos 🌀💅 Here are the notes that go with it, bestie:
- (7) If the received
SD-Wmessage hasPath=0, ignore the message. If the receivedSD-Wmessage hasPath=1, go to thePF:DW:Rstate and transmit anSD(0,1)message. 🦋 - (8) If the received
SD-Pmessage hasPath=1, ignore the message. If the receivedSD-Pmessage hasPath=0, go to theUA:DP:Rstate and transmit anSD(1,0)message. 🫶 - (9) Transition to the WTR state and continue to send the current message. 🌸
- (10) Transition to the DNR state and continue to send the current message. ✨
- (11) If the received NR message has
Path=1, transition to the WTR state if the domain is configured for revertive behavior, else transition to the DNR state. If the received NR message hasPath=0, transition to the Normal state. 👑 - (12) If the receiving node's WTR timer is running, maintain the current state and message. If the WTR timer is not running, transition to the Normal state. ⏳
- (13) Transit to the WTR state and send an
NR(0,1)message. The WTR timer is not initiated. 🙈
11.3. State Transition for 1+1 Unidirectional Protection
Okay so the state transition tables in Sections 11.1 and 11.2 are for bidirectional protection switching, where remote PSC protocol messages decide the protection-switching actions 🔥. 1+1 unidirectional protection switching doesn't need the remote info in the PSC protocol message at all, and it only acts on local inputs 🧚. So the state transition by local inputs in Section 11.1 SHALL be reused for 1+1 unidirectional protection under these conditions:
- The value of Request field in the received remote message is ignored and always assumed to be no request. 💅
- Replace footnote (4) with "Stop the WTR timer and transit to the Normal state." 🎀
- Replace footnote (6) with "Transit to the Normal state." 🍓
- Exercise command is not relevant. 💀
12. Provisioning Mismatch and Protocol Failure in APS Mode
Bestie, this part is about what happens when the remote PSC message gets checked for provisioning mismatch and protocol failure 😭. In APS mode, provisioning mismatches get handled like this:
- If the PSC message is received from the working path because of a working/protection path configuration mismatch, the node MUST alert the operator and MUST NOT perform any protection switching until the operator resolves this path configuration mismatch. 🚨
- If the mismatch happens in the two-bit "Protection Type (PT)" field, which indicates the permanent/selector bridge type and the uni/bidirectional switching type:
- If the value of the PT field on one side is 2 (i.e., selector bridge) and the other side has 1 or 3 (i.e., permanent bridge), then this event MUST be notified to the operator, and each node MUST NOT perform any protection switching until the operator resolves this bridge type mismatch. 🙅♀️
- If the bridge type matches but the switching type mismatches, i.e., one side has PT=1 (unidirectional switching) while the other side has PT=2 or 3 (bidirectional switching), then the node provisioned for bidirectional switching SHOULD fall back to unidirectional switching to allow interworking. The node SHOULD notify the operator of this event. 🌈
- If the "Revertive (R)" bit mismatches, the two sides will interwork and traffic is protected according to the state transition definition given in Section 11. The node SHOULD notify the operator of this event. 🦋
- If the Capabilities TLV mismatches, the node MUST alert the operator and MUST NOT perform any protection switching until the operator resolves the mismatch in the Capabilities TLV. 🚫
Here are the protocol failure situations and what to do about them, iykyk 🧠:
- No match in sent "Data Path (Path)" and received "Data Path (Path)" for more than 50 ms: The node MAY continue to perform protection switching and SHOULD notify the operator of this event. 🫠
- No PSC message is received on the protection path during at least 3.5 times the long PSC message interval (e.g., at least 17.5 seconds with a default message interval of 5 seconds), and there is no defect on the protection path: The node MUST alert the operator and MUST NOT perform any protection switching until the operator resolves this defect. 😱
13. Security Considerations
Okay this section is serious, so I'm keeping it real 🔐. This document introduces no new security risks. [RFC6378] points out that MPLS relies on assumptions about the difficulty of traffic injection and assumes that the control plane does not have end-to-end security. [RFC5920] describes MPLS security issues and generic methods for securing traffic privacy and integrity. MPLS use should conform to such advice. 🛡️✨
14. IANA Considerations
14.1. MPLS PSC Request Registry
In the "Generic Associated Channel (G-ACh) Parameters" registry, IANA maintains the "MPLS PSC Request Registry". 📋
IANA has assigned the following two new code points from this registry. 💖
Value Description Reference
----- --------------------- ---------------
2 Reverse Request (this document)
3 Exercise (this document)14.2. MPLS PSC TLV Registry
In the "Generic Associated Channel (G-ACh) Parameters" registry, IANA maintains the "MPLS PSC TLV Registry". 🗂️
This document defines the following new value for the Capabilities TLV type in the "MPLS PSC TLV Registry". 🎀
Value Description Reference
------ --------------------- ---------------
1 Capabilities (this document)14.3. MPLS PSC Capability Flag Registry
IANA has created and now maintains a new registry within the "Generic Associated Channel (G-ACh) Parameters" registry called "MPLS PSC Capability Flag Registry". All flags within this registry SHALL be allocated according to the "Standards Action" procedures as specified in RFC 5226 [RFC5226]. 🔒
The length of each flag MUST be a multiple of 4 octets. This document defines 4-octet flags. Flags greater than 4 octets SHALL be used only if more than 32 Capabilities need to be defined. The flags defined in this document are: 🌸
Bit Hex Value Capability Reference
---- ---------- ----------------------------------- ---------------
0 0x80000000 priority modification (this document)
1 0x40000000 non-revertive behavior modification (this document)
2 0x20000000 support of MS-W command (this document)
3 0x10000000 support of protection against SD (this document)
4 0x08000000 support of EXER command (this document)
5-31 Unassigned (this document)15. Acknowledgements
The authors would like to thank Yaacov Weingarten, Yuji Tochio, Malcolm Betts, Ross Callon, Qin Wu, and Xian Zhang for their valuable comments and suggestions on this document. Huge thank you, besties 🫶💜
We would also like to acknowledge explicit text provided by Loa Andersson and Adrian Farrel. 🙌
16. References
16.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 📖
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 📖
- [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. 📖
- [RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, October 2011. 📖
16.2. Informative References
- [G8031] International Telecommunication Union, "Ethernet Linear Protection Switching", ITU-T Recommendation G.8031/Y.1342, June 2011. 🌐
- [G841] International Telecommunication Union, "Types and characteristics of SDH network protection architectures", ITU-T Recommendation G.841, October 1998. 🌐
- [G873.1] International Telecommunication Union, "Optical Transport Network (OTN): Linear protection", ITU-T Recommendation G.873.1, July 2011. 🌐
- [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. 📚
- [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. 📚
- [RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011. 📚
Appendix A. An Example of an Out-of-Service Scenario ✨
Okay so this diagram is a sneak peek at the out-of-service mess 😭 It follows the priority levels from [RFC6378], and it shows the first PSC message that's different from the one before it 🎀
A Z
| |
(1) |-- NR(0,0) ------>| (1)
|<----- NR(0,0) ---|
| |
| |
| (FS issued at Z) | (2)
(3) |<------ FS(1,1) --|
|-- NR(0,1) ------>|
| |
| |
(4) | (SF on P(A<-Z)) |
| |
| |
| (Clear FS at Z) | (5)
(6) | X <- NR(0,0) --|
| |
| |- (1) Both ends start out in the Normal state, sending NR(0,0) messages 💖
- (2) Node Z issues an FS command, so it goes into the local Protecting Administrative state (PA:F:L) and starts sending an FS(1,1) message 🔥
- (3) That remote FS message pushes node A into the remote Protecting Administrative state (PA:F:R), and node A starts sending NR(0,1) messages 🦋
- (4) Node A spots a unidirectional SF-P. But SF-P gets ignored in the PA:F:R state, so node A just keeps sending NR(0,1) 🙈
- (5) A Clear command at node Z sends it back to the Normal state, and it starts sending NR(0,0) again 🧚
- (6) Here's the plot twist 💀 Node A can't receive any PSC messages because of its local unidirectional SF-P. No valid PSC message shows up over several message intervals in a row, so the last valid message it got still counts, and node A keeps sending NR(0,1) while stuck in PA:F:R
Now here's the drama: node A is sending NR(0,1) and node Z is sending NR(0,0), so their selector and bridge positions don't match 😬 That mismatch leaves the whole thing out of service, even when there's no SF-W and no FS going on. Not me being dramatic, it's literally what happens 💅
Appendix B. An Example of a Sequence Diagram Showing the Problem with the Priority Level of SFc
Okay, bestie, this one shows the SFc priority problem from [RFC6378] 🍓 The diagram below is for the case where the bidirectional signal fails. Other unidirectional signal fail cases can end up with the exact same problem, though. Again, the first PSC message that's different from the previous one is the one shown 🦋
A Z
| |
(1) |-- NR(0,0) ------>| (1)
|<----- NR(0,0) ---|
| |
| |
(2) | (SF on P(A<->Z)) | (2)
|-- SF(0,0) ------>|
|<------ SF(0,0) --|
| |
| |
(3) | (SF on W(A<->Z)) | (3)
| |
| |
(4) | (Clear SF-P) | (4)
| |
| |
(5) | (Clear SF-W) | (5)
| |
| |- (1) Both ends are in the Normal state, sending NR(0,0) messages 💜
- (2) When SF-P happens, each node goes into the UA:P:L state and sends SF(0,0) messages. Traffic stays on the working path 🌸
- (3) Then SF-W happens too 😭 Both nodes stay in UA:P:L, because SF-W has a lower priority than SF-P. Traffic is still on the working path, and it can't get delivered, since the working path and the protection path are both dealing with signal fails
- (4) Now SF-P clears, but the local "Clear SF-P" request can't make it to the PSC Control Logic 🙃 The logic grabs the highest local request and runs the PSC state machine, and "Clear SF-P" ranks lower than SF-W. So nothing changes state, and the selector and/or bridge keep pointing at the working path, which still has the SF condition 💀
Traffic still can't get delivered even though the protection path has recovered and is available 😤 The same problem shows up if the order of the SF-P and SF-W events gets switched too, just so you know 🔥
Let's keep going and see what happens after SF-W clears 👀
- (5) When SF-W clears, the local "Clear SF-W" request can get passed to the PSC Control Logic, since there's no higher-priority local input. But the PSC Control Logic ignores it based on the state transition definition in [RFC6378], so there's no change in state and no protocol message gets sent 🫠
Here's where it gets messy. SF-W is cleared and the selector and/or bridge are still pointing at the working path, so traffic delivery comes back. But both nodes are still in UA:P:L and sending SF(0,0), even though there's no outstanding protection-switching request at all 😭 And any future legit requests, like another SF-W, will get rejected, because each node thinks the protection path is unavailable. Iconic behavior, not in a good way 💅
Appendix C. Freeze Command 🧊
The "Freeze" command is a local-only thing. It applies to the local node of the protection group and never gets signaled to the remote node 🫶 It freezes the state of the protection group. Until the Freeze is cleared, any extra local commands get rejected, and condition changes and received PSC information get ignored, so it's basically on pause 🌈
The "Clear Freeze" command clears the local freeze. Once that happens, the state of the protection group gets recomputed based on the persistent condition of the local triggers ✨
Here's the catch 😬 Because the freeze is local, if someone freezes only one end, a protocol failure can happen. The other end is still wide open to accept any operator command or fault condition, so the two ends can end up out of sync 💀
Appendix D. Operation Examples of the APS Mode ✨
okay so this part is all about the APS mode in action 🎀 these sequence diagrams are just a few examples, not the whole story bestie 💅 we only show the first PSC protocol message that's different from the one before it, and we skip the hold-off timer because it's not the star here 🙈 we also only show the Request, FPath, and Path fields that change during the PSC message exchange. so SF(1,0) means a PSC message with Request=SF, FPath=1, and Path=0 💖 every other field just stays the same as the initial config. and W(A->Z) and P(A->Z) mean the working path and the protection path in the A to Z direction, respectively 🦋
Example 1. 1:1 bidirectional protection switching (revertive operation) - Unidirectional SF case 🌸
A Z
| |
(1) |<---- NR(0,0)---->| (1)
| |
| |
(2) | (SF on W(Z->A)) |
|---- SF(1,1)----->| (3)
(4) |<----- NR(0,1)----|
| |
| |
(5) | (Clear SF-W) |
|---- WTR(0,1)---->|
/| |
| | |
WTR timer | |
| | |
\| |
(6) |---- NR(0,1)----->| (7)
(8) |<----- NR(0,0)----|
|---- NR(0,0)----->| (9)
| |(1) the protected domain is chilling with no defects 😌 the working path is carrying the traffic in the Normal state
(2) SF-W shows up in the Z to A direction 😭 node A goes into the PF:W:L state and sends out an SF(1,1) message. both node A's selector and bridge are pointing at the protection path
(3) node Z gets that SF(1,1) message and sets both its selector and bridge to the protection path 🫶 there's no local request on node Z, so it sends an NR(0,1) message in the PF:W:R state
(4) node A double checks that the remote node is also selecting the protection path ✨
(5) node A notices the SF condition has cleared, so it starts the WTR timer and sends a WTR(0,1) message in the WTR state 🧚
(6) once the WTR timer runs out, node A sets both the selector and bridge back to the working path and sends an NR(0,1) message 💜
(7) node Z finds out the remote request is cleared, so it moves to the Normal state and sends an NR(0,0) message 🎀
(8) node A gets that NR(0,0) message and moves to the Normal state, then sends an NR(0,0) message of its own 🍓
(9) it's confirmed that the remote node is also selecting the working path. literally everyone is on the same page now 👑
Example 2. 1:1 bidirectional protection switching (revertive operation) - Bidirectional SF case - Inconsistent WTR timers 🦋
A Z
| |
(1) |<---- NR(0,0)---->| (1)
| |
| |
(2) | (SF on W(A<->Z)) | (2)
|<---- SF(1,1)---->|
| |
| |
(3) | (Clear SF-W) | (3)
|<---- NR(0,1)---->|
(4) |<--- WTR(0,1) --->| (4)
/| |\
| | | |
WTR timer | | WTR timer
| | | |
| | |/
| |<------ NR(0,1)---| (5)
| | |
\| |
(6) |--- NR(0,1)------>|
|<------ NR(0,0)---| (7)
(8) |--- NR(0,0)------>|
| |(1) both ends are in the Normal state, each sending NR(0,0) messages 🌈
(2) when SF-W happens, each node enters the PF:W:L state and sends SF(1,1) messages. the traffic moves over to the protection path. when each node gets an SF(1,1) message, it confirms the remote node is also sending and receiving traffic from the protection path 💅
(3) when SF-W clears, each node moves to the PF:W:R state and sends NR(0,1) messages, because the last message it received was SF-W 😭
(4) once each node gets NR(0,1) messages, it goes into the WTR state, starts the WTR timer, and sends WTR(0,1) messages ⭐
(5) when the WTR timer runs out on node Z, node Z sends an NR(0,1) message, since the last APS message it got was WTR. when that NR(0,1) reaches node A, node A stays in the WTR state and keeps sending its current WTR messages, as described in the state transition table 🧚
(6) when the WTR timer runs out on node A, node A sends an NR(0,1) message 🫶
(7) when that NR(0,1) message reaches node Z, node Z moves to the Normal state, sets both the selector and bridge to the working path, and sends an NR(0,0) message 👑
(8) the NR(0,0) message makes node A go to the Normal state too 🎀 and now the traffic switches back to the working path. bestie we did it 💖
Example 3. 1:1 bidirectional protection switching - R bit mismatch 🍓
this one is giving "they're different but they still work together" 💜 both sides interwork and the traffic stays protected even when node A is set to revertive operation and node Z is set to non-revertive operation. the state transition tables cover how this interworking works ✨
(revertive) A Z (non-revertive)
| |
(1) |<---- NR(0,0)---->| (1)
| |
| |
(2) | (SF on W(A<->Z)) | (2)
|<---- SF(1,1)---->|
| |
| |
(3) | (Clear SF-W) | (3)
|<---- NR(0,1)---->|
(4) |<----- DNR(0,1)---| (4)
/|-- WTR(0,1)------>|
| |<----- NR(0,1)----| (5)
| | |
WTR timer | |
| | |
| | |
\| |
(6) |--- NR(0,1)------>|
|<------ NR(0,0)---| (7)
(8) |--- NR(0,0)------>|
| |(1) both ends are in the Normal state, each sending NR(0,0) messages 🌸
(2) when SF-W happens, each node enters the PF:W:L state and sends SF(l,l) messages. the traffic is switched to the protection path. when an SF(1,1) message arrives, each node confirms the remote node is also sending and receiving traffic on the protection path 😭
(3) when SF-W clears, each node moves to the PF:W:R state and sends NR(0,1) messages, because the last message it got was SF-W 🧚
(4) once node A gets NR(0,1) messages, it goes into the WTR state, starts the WTR timer, and sends WTR(0,1) messages. at the same time, node Z moves to the DNR state and sends a DNR(0,1) message 💅
(5) when the WTR message reaches node Z, node Z moves to the WTR state and sends an NR(0,1) message, following the state transition table. at the same time, the DNR message that arrived at node Z gets ignored, per the state transition table. so node Z, even though it's set to non-revertive operation, ends up acting like it's in revertive operation 🫶
(6) when the WTR timer runs out on node A, node A sends an NR(0,1) message 🌈
(7) when that NR(0,1) message reaches node Z, node Z moves to the Normal state, sets both the selector and bridge to the working path, and sends an NR(0,0) message 👑
(8) the NR(0,0) message makes node A move to the Normal state. now the traffic is switched back to the working path 🎀 iconic ending, no cap 💖
Authors' Addresses 🧚
Jeong-dong Ryoo (editor)
ETRI
218 Gajeongno
Yuseong-gu, Daejeon 305-700
South Korea
Phone: +82-42-860-5384
EMail: ryoo@etri.re.kr
Eric Gray (editor)
Ericsson
EMail: eric.gray@ericsson.com
Huub van Helvoort
Huawei Technologies
Karspeldreef 4,
Amsterdam 1101 CJ
The Netherlands
Phone: +31 20 4300936
EMail: huub.van.helvoort@huawei.com
Alessandro D'Alessandro
Telecom Italia
via Reiss Romoli, 274
Torino 10148
Italy
Phone: +39 011 2285887
EMail: alessandro.dalessandro@telecomitalia.it
Taesik Cheung
ETRI
218 Gajeongno
Yuseong-gu, Daejeon 305-700
South Korea
Phone: +82-42-860-5646
EMail: cts@etri.re.kr
Eric Osborne
EMail: eric.osborne@notcom.com📦 where this page comes from
- ietf: rfc7271 2014-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms