RFC 6378
MPLS Transport Profile (MPLS-TP) Linear Protection
Part 1 of 9 🎀
RFC 6378: MPLS Transport Profile (MPLS-TP) Linear Protection 💖
Okay bestie, this is RFC 6378, published by the IETF as a Standards Track document in October 2011 ✨. It has ISSN 2070-1721. It doesn't obsolete or update anything listed in its header.
The editors are Y. Weingarten (Ed.) from Nokia Siemens Networks and A. Fulignoli (Ed.) from Ericsson. The other authors are S. Bryant, E. Osborne from Cisco, and N. Sprecher from Nokia Siemens Networks 🧚. Fun fact: two of the authors come from Nokia Siemens Networks, so that's a whole team effort 🫶.
Abstract ✨
This doc is a joint IETF / ITU-T project 🌈. Its goal is to bring an MPLS Transport Profile into the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures, so they can support everything a packet transport network needs, as defined by the ITU-T 💅.
It covers the functionality from the MPLS-TP Survivability Framework document (RFC 6372), and it defines a protocol you can use for the Protection State Coordination for linear protection that the framework describes 🦋.
Status of This Memo 🌸
This is an Internet Standards Track document 👑.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 📚.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6378 💌.
Copyright Notice 💜
Copyright (c) 2011 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) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for this document 📜. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🧾.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process 🙈. Unless you get an adequate license from the person(s) controlling the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exception is formatting it for publication as an RFC or translating it into languages other than English 🌍.
Table of Contents 🍓
1. Introduction ....................................................4
1.1. Protection Architectures ...................................4
1.2. Scope of the Document ......................................5
2. Conventions Used in This Document ...............................6
2.1. Acronyms ...................................................6
2.2. Definitions and Terminology ................................7
3. Protection State Control Logic ..................................7
3.1. Local Request Logic ........................................9
3.2. Remote Requests ...........................................11
3.3. PSC Control Logic .........................................12
3.4. PSC Message Generator .....................................12
3.5. Wait-to-Restore (WTR) Timer ...............................12
3.6. PSC Control States ........................................13
3.6.1. Local and Remote State .............................14
4. Protection State Coordination (PSC) Protocol ...................14
4.1. Transmission and Acceptance of PSC Control Packets ........15
4.2. Protocol Format ...........................................16
4.2.1. PSC Ver Field ......................................16
4.2.2. PSC Request Field ..................................17
4.2.3. Protection Type (PT) Field .........................18
4.2.4. Revertive (R) Field ................................18
4.2.5. Fault Path (FPath) Field ...........................19
4.2.6. Data Path (Path) Field .............................19
4.2.7. Additional TLV Information .........................19
4.3. Principles of Operation ...................................20
4.3.1. Basic Operation ....................................20
4.3.2. Priority of Inputs .................................21
4.3.3. Operation of PSC States ............................22
5. IANA Considerations ............................................33
5.1. Pseudowire Associated Channel Type ........................33
5.2. PSC Request Field .........................................33
5.3. Additional TLVs ...........................................34
6. Security Considerations ........................................34
7. Acknowledgements ...............................................35
8. Contributing Authors ...........................................36
9. References .....................................................37
9.1. Normative References ......................................37
9.2. Informative References ....................................37
Appendix A. PSC State Machine Tables ..............................39
Appendix B. Exercising the Protection Domain ......................441. Introduction ✨
The MPLS Transport Profile (MPLS-TP) [RFC5921] is a framework for building and running packet-switched transport networks 🚀. It's based on the MPLS architectures ([RFC3031] and [RFC3032]), the Pseudowire (PW) architectures ([RFC3985] and [RFC5659]), and the requirements in [RFC5654] 💅.
Network survivability is a network's ability to get traffic flowing again after a failure, or degradation, of its resources 🛟. The MPLS-TP Survivability Framework [RFC6372] is the framework for survivability in MPLS-TP networks 🦋. It covers recovery elements, types, methods, and topological considerations, and it mostly focuses on recovering MPLS-TP Label Switched Paths (LSPs) 🌈.
Linear protection in mesh networks (networks with arbitrary interconnectivity between nodes) is described in Section 4.7 of [RFC6372] 🕸️. It's rapid and simple protection switching, which is so iconic for a mesh network ⭐. It can operate between any pair of points in the network, and it can protect against a defect in an intermediate node, a span, a transport path segment, or an end-to-end transport path 👑.
1.1. Protection Architectures 🎀
Protection switching is a fully allocated survivability mechanism 💎. "Fully allocated" means the route and resources of the protection path are reserved for a selected working path, or a set of working paths 🔒. It's a fast and simple survivability mechanism, and it lets the network operator easily see the active state of the network. It can also operate between any pair of points within the network 🙌.
As the Survivability Framework document [RFC6372] describes, protection switching is applied to a protection domain 🧩. For this document, the protection domain of a point-to-point LSP consists of two Label Edge Routers (LERs) and the transport paths that connect them (see Figure 3) 🗺️. For a point-to-multipoint LSP, the protection domain includes the root (or source) LER, the destination (or sink) LERs, and the transport paths that connect them 🌟.
In the 1+1 unidirectional architecture presented in [RFC6372], a protection transport path is dedicated to the working transport path 💖. Normal traffic is bridged (as defined in [RFC4427]) and fed to both the working and the protection paths by a permanent bridge at the source of the protection domain 🌉. The sink of the protection domain uses a selector to choose either the working or the protection path to receive traffic from, based on predetermined criteria, such as a server defect indication 🎯. When used for bidirectional switching, the 1+1 protection architecture must also support a Protection State Coordination (PSC) protocol 🤝. That protocol helps both ends of the protection domain coordinate on selecting the proper traffic flow 🫶.
In the 1:1 architecture, a protection transport path is dedicated to the working transport path of a single service 🍭. Traffic is only transmitted on either the working or the protection path, using a selector at the source of the protection domain 🎈. A selector at the sink of the protection domain then selects the path that carries the normal traffic 🛤️. Since the source and sink need to coordinate so both ends' selectors pick the same path, this architecture must support a PSC protocol 💅.
The 1:n protection architecture takes the 1:1 architecture above and shares the protection path among n services 🧚♀️. Again, the protection path is fully allocated and disjoint from any of the n working transport paths it's protecting 💜. Each service's normal data traffic goes on its normal working path, or, in cases that trigger protection switching (as listed in [RFC6372]), it may be sent on the protection path 🌸. The switching action is similar to the 1:1 case, where a selector is used at the source 🔁. When several working path services have triggered protection switching, some services may not be transmitted because of limited resources on the protection path, depending on their Service Level Agreement (SLA) 😭. It should be noted that in this architecture, there may be a need for coordinating the protection switching and for resource allocation negotiation 📝. The procedures for this are for further study and may be addressed in future documents 🔮.
1.2. Scope of the Document ✨
okay so, the Survivability Framework [RFC6372] and the stuff we just hyped up above both point at the same thing 💅: when you use bidirectional protection schemes, the end points of the protection domain need to coordinate with each other. It's especially important when you need to check that traffic is still moving over a bidirectional LSP that's co-routed 🦋.
This document presents a protocol for the Protection State Coordination of Linear Protection 🎀. It handles protection of LSPs in an MPLS-TP network, as required by [RFC5654] (in particular, requirements 63-65 and 74-79) and described in [RFC6372]. The basic protocol is built to work with the 1:1 protection architecture, bidirectional protection, and 1+1 protection of a bidirectional path (covering both unidirectional and bidirectional protection switching) 🌸. Applicability to 1:1 unidirectional protection and to 1:n protection schemes may be documented in a future document, and that's out of scope here. Applicability to additional MPLS-TP constructs and topologies may also show up in future documents 🧚.
Unidirectional 1+1 protection doesn't need a coordination protocol 🙈, but the protocol can still be used by the ingress node of the path to tell the far-side end point that a switching condition has happened, and to check that the end-point configurations match. This could be especially handy for point-to-multipoint transport paths, which are unidirectional by definition of [RFC5654] 💜. Using this protocol on point-to-multipoint paths is out of scope for this document and may be covered in a future applicability document 🍓.
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]. 📖
2.1. Acronyms 💖
This document uses the following acronyms 🌈:
CT Channel Type
DNR Do-not-Revert
FS Forced Switch
G-ACh Generic Associated Channel
LER Label Edge Router
LO Lockout of protection
LSR Label Switching Router
MEG Managed Entity Group
MEP MEG End Point
MPLS-TP Transport Profile for MPLS
MS Manual Switch
NR No Request
OAM Operations, Administration, and Maintenance
PSC Protection State Coordination Protocol
S-PE Switching Provider Edge
SD Signal Degrade
SF Signal Fail
SFc Clear Signal Fail
SLA Service Level Agreement
T-PE Terminating Provider Edge
WTR Wait-to-Restore2.2. Definitions and Terminology 🧠
The terminology in this document is based on what's defined in [RFC4427], and it's further adapted for MPLS-TP in [RFC6372] ✨. On top of that, we use the term "LER" to mean any MPLS-TP Network Element, whether it's an LSR, LER, T-PE, or S-PE 🫶.
3. Protection State Control Logic 👑
Protection switching handles the local triggers described in requirements 74-79 of [RFC5654], and it also takes in inputs received from the far-end LER 🔥. Based on those inputs, the LER takes certain protection switching actions. For example, it might switch the selector to transmit on the working or protection path for 1:1 protection, or switch the selector to receive the traffic for either 1:1 or 1+1 protection, and transmit different protocol messages 💅.
The figure below shows the logical breakdown of the Protection State Control logic into different logical processing units 🦋. These units get their own subsections later in this document. This breakdown is only meant for describing things; any implementation that produces the external behavior described in Section 4 is acceptable 🌸.
Server Indication Control-Plane Indication
-----------------+ +-------------
Operator Command | | OAM Indication
----------------+ | | +---------------
| | | |
V V V V
+---------------+ +-------+
| Local Request |<--------| WTR |
| logic |WTR Exps | Timer |
+---------------+ +-------+
| ^
Highest local|request |
V | Start/Stop
+-----------------+ |
Remote PSC | PSC Control |------------+
------------>| logic |
Request +-----------------+
|
| Action +------------+
+---------------->| Message |
| Generator |
+------------+
|
Output PSC | Message
V
Figure 1: Protection State Control LogicFigure 1 lays out the logical architecture of the protection switching control 🧚. The Local Request logic unit takes in triggers from the OAM, the server layer, external operator commands, the local control plane (when there is one), and the Wait-to-Restore timer 🎀. After looking at all of these local request sources, it figures out the highest priority local request 👑. That high-priority request gets passed to the PSC Control logic, which cross-checks it against the information it got from the far-end LER 💜. The PSC Control logic uses this input to decide what actions need to happen, like local actions at the LER or which message should go to the far-end LER, and it also tracks the current status of the protection domain ✨.
3.1. Local Request Logic 🌸
The Local Request logic processes input triggers from five sources 🍓.
- Operator command - The network operator may issue local administrative commands on the LER that trigger protection switching. The commands Forced Switch, Manual Switch, Clear, and Lockout of protection (defined in [RFC4427] as Forced switch-over, Manual switch-over, Clear, and Lockout of recovery LSP/span, respectively) MUST be supported 💖. An implementation MAY provide additional commands for operator use. As long as those commands don't introduce incompatible behavior between two arbitrary implementations, they're outside the scope of this document 🦋. For example, an implementation could offer a command that manually sets off a "WTR Expires" trigger (see below) input without waiting for the WTR timer to run out. Since that just speeds up the move from one state to another and doesn't change the state machine itself, it would be perfectly valid 🌈.
- Server-layer alarm indication - The underlying server layer of the network detects failure conditions at the underlying layer and may issue an indication to the MPLS-TP layer 🧚. The server layer may use its own protection switching mechanism, so this input MAY be controlled by a hold-off timer, and that hold-off timer SHOULD be configurable by the network operator ⏳. The hold-off timer is described in more detail in [RFC6372] 💅.
- Control-Plane Indication - If there's an active control plane in the network (signaling or routing), it MAY trigger protection switching based on conditions the control plane detects 🔥. If the control plane is based on GMPLS [RFC3945], then the recovery process SHALL comply with the process described in [RFC4872] and [RFC4873] 👑.
- OAM indication - OAM fault management or performance measurement tools may detect a failure or degrade condition on either the working or protection transport path, and this MUST input an indication to the Local Request logic 🫶.
- WTR Expires - The Wait-to-Restore timer is used together with recovery from failure conditions on the working path in revertive mode ⭐. The timer SHALL signal the PSC control process when it expires, and the end point SHALL revert to normal transmission of user data traffic 🌸.
The input from these sources SHOULD be kept persistently for as long as the condition that started the trigger is still going 💜. The Local Request logic processes these different input sources and, based on the priorities between them (see Section 4.3.2), produces a current local request 🎀. If more than one local input source generates a trigger, the Local Request logic picks the higher priority indicator and ignores any lower priority one 💖. So in the end there's a single current local request that gets passed to the PSC Control logic ✨. The different local requests that can come out of the Local Request logic are:
- Clear - If the operator cancels an active local administrative command, i.e., LO/FS/MS 🧼.
- Lockout of protection (LO) - If the operator requested to prevent switching data traffic to the protection path, for any purpose 🔒.
- Signal Fail (SF) - If any of the server-layer, control-plane, or OAM indications signaled a failure condition on either the protection path or one of the working paths 💀.
- Signal Degrade (SD) - If any of the server-layer, control-plane, or OAM indications signaled a degraded transmission condition on either the protection path or one of the working paths 🥀. The determination and actions for SD are for further study and may appear in a separate document. All references to SD input are placeholders for that extension 🧩.
- Clear Signal Fail (SFc) - If all of the server-layer, control-plane, or OAM indications are no longer indicating a failure condition on a path that was previously indicating one 🌤️.
- Forced Switch (FS) - If the operator requested that traffic be switched from one of the working paths to the protection path 🚀.
- Manual Switch (MS) - If the operator requested that traffic be switched from the working path to the protection path. This only matters if there's no currently active fault condition or operator command 🙋♀️.
- WTR Expires (
WTRExp) - Generated by the WTR timer finishing its period ⏰.
If none of the input sources have generated any triggers, the Local Request logic should generate a No Request (NR) as the current local request 🦋.
3.2. Remote Requests ✨
okay so besides the local requests from the local triggers we just covered, the PSC Control logic SHALL accept PSC messages from the far-end LER of the transport path 🦋. Remote messages basically spill the tea on the transport path's status from the far-end LER's point of view 👀. These messages may drive state changes on the local MEP, as defined later in this document 🌸. When using 1+1 unidirectional protection, an LER that receives a remote request SHALL NOT perform any protection switching action. It just keeps selecting traffic from the working path and transporting traffic on both paths 🙈 no switching drama, periodt.
The following remote requests may be received by the PSC process:
- Remote LO - the remote end point is in Unavailable state because of a Lockout of protection operator command 🔒
- Remote SF - the remote end point has detected a Signal Fail condition on one of the transport paths in the protection domain 💀. This remote message says which transport path is affected by the SF condition. Also, the SF condition may be either a unidirectional or a bidirectional failure, even if the transport path is bidirectional, so it should be noted 👀
- Remote SD - the remote end point has detected a Signal Degrade condition on one of the transport paths in the protection domain 😭. This remote message says which transport path is affected by the SD condition. Also, the SD condition may be either a unidirectional or a bidirectional failure, even if the transport path is bidirectional, so it should be noted too 👀
- Remote FS - the remote end point is operating under an operator command to switch the traffic to the protection path 🧚
- Remote MS - the remote end point is operating under an operator command to switch the traffic from the working path to the protection path 🎀
- Remote WTR - the remote end point has figured out that the failure condition has recovered and has started its WTR timer, getting ready to revert to the Normal state ⏳
- Remote DNR - the remote end point has figured out that the failure condition has recovered and will keep transporting traffic on the protection path. This is because of operator configuration that stops automatic reversion to the Normal state 🙅♀️
- Remote NR - the remote end point has no abnormal condition to report ✨ all good over there
3.3. PSC Control Logic 🧠
the PSC Control logic takes in the following input:
- a. the current local request output from the Local Request logic (see Section 3.1),
- b. the remote request message from the remote end point of the transport path (see Section 3.2), and
- c. the current state of the PSC Control logic (maintained internally by the PSC Control logic).
Based on the priorities between the different inputs, the PSC Control logic works out its new state and what actions need to be taken 👑.
The new state information is retained by the PSC Control logic 💾. The requested action should be sent to the PSC Message Generator (see Section 3.4) so it can generate and transmit the proper PSC message to the remote end point of the protection domain 📨.
3.4. PSC Message Generator 💌
based on the action output from the PSC Control logic, this unit formats the PSC protocol message that gets transmitted to the remote end point of the protection domain. This message may either be the same as the previously transmitted message, or it may change when the PSC control state (see Section 3.6) has changed 🔄. The messages are transmitted as described in Section 4.1 of this document.
3.5. Wait-to-Restore (WTR) Timer ⏳
the WTR timer is used to delay reversion to Normal state when recovering from a failure condition on the working path, as long as the protection domain is configured for revertive behavior 🔁. The length of the timer may be provisioned by the operator. The WTR may be in one of two states: Running or Stopped. The PSC Control logic manages the control of the WTR timer, using internal signals to start and stop (i.e., reset) the WTR timer 🎛️.
If the WTR timer expires before it gets stopped, it SHALL generate a WTR Expires local signal that is processed by the Local Request logic 🚨.
If the WTR timer is running, sending a Stop command SHALL reset the timer and put the WTR timer into Stopped state, but it SHALL NOT generate a WTR Expires local signal 🙅♀️. If the WTR timer is already stopped, a Stop command SHALL be ignored 🫠.
3.6. PSC Control States 🗺️
The PSC Control logic should maintain information on the current state of the protection domain 📍. Each LER within the protection domain maintains information about the state of the domain. This state information would include the current state of the protection domain, an indication of the cause for the current state (e.g., unavailable due to local LO command, or protecting due to remote FS), and, for each LER, should include an indication of whether the state is related to a remote or local condition 🕵️♀️.
It should be noted that when we talk about the "transport" of the data traffic in the descriptions that follow, and later in the document, the data will be sent on both the working and the protection paths when using 1+1 protection 🫶. When using 1:1 protection, it goes on either the working or the protection path exclusively. When using 1+1 protection, the receiving LER should select the proper transmission, according to the state of the protection domain 💅.
The protection domain states that the PSC Control logic supports are as follows:
- Normal state - Both the protection and working paths are fully allocated and active, data traffic is being transported over (or selected from) the working path, and no trigger events are reported within the domain 🌈.
- Unavailable state - The protection path is unavailable 😵. This is either because of an operator Lockout command or a failure condition detected on the protection path.
- Protecting failure state - The working path has reported a failure/degrade condition, and the user traffic is being transported (or selected) on the protection path 🛡️.
- Protecting administrative state - The operator has issued a command switching the user traffic to the protection path 🧑💼.
- Wait-to-Restore state - The protection domain is recovering from an SF/SD condition on the working path, and that recovery is being controlled by the Wait-to-Restore (WTR) timer ⏳.
- Do-not-Revert state - The protection domain has recovered from a Protecting state, but the operator has configured the protection domain not to automatically revert to the Normal state upon recovery 🙅♀️. The protection domain SHALL remain in this state until the operator issues a command to revert to the Normal state, or there is a new trigger to switch to a different state 🔒.
See Section 4.3.3 for details on what actions the PSC Process logic takes in each state and for the relevant input 📖.
3.6.1. Local and Remote State 💫
An end point may be in a given state because of either a local input indicator (e.g., OAM, WTR timer) or because it received a PSC message from the far-end LER. If the state is entered because of a local input indicator, then the state is considered a local state 🏠. If the state is entered because of a PSC message, in the absence of a local input, then the state is considered a remote state 🛰️. This difference affects how the LER reacts to different inputs, as described in Section 4.3.3. The PSC Control logic should maintain, together with the current protection domain state, an indication of whether this is a local or remote state for this LER 🧾.
In any instance where the LER has both a local and a remote indicator that cause the protection domain to enter a particular state, the state is considered a local state, no matter what order the indicators were processed in 🥇. If, however, the LER has local and remote indicators that would cause the protection domain to enter different states, e.g., a local SF on working and a remote Lockout of protection message, then the input with the higher priority (see Section 4.3.2) decides the outcome, and the source of that indicator determines whether it is local or remote ⚖️. In the given example, the result would be a Remote Unavailable state, transmitting PSC messages that indicate an SF condition on the working path and that the protection path is not being used to transport protected traffic (as described in the next section) 🫣.
4. Protection State Coordination (PSC) Protocol 🫶
okay bestie, bidirectional protection switching (and unidirectional 1:1 protection too) needs the two end points to coordinate, so they both know which of the two possible paths, the working or the protection path, is transmitting the data traffic in any given situation 🤝. When protection switching is triggered as described in Section 3, the end points must inform each other of the switchover from one path to the other in a coordinated fashion 💕.
There are different possibilities for the type of coordinating protocol 🧩. One possibility is a two-phased coordination, where the LER that starts the protection switching sends a protocol message indicating the switch, but the actual switchover only happens after it receives an 'Ack' from the far-end LER 📬. The other possibility is a single-phased coordination, where the initiating LER performs the protection switchover to the alternate path and informs the far-end LER of the switch, and then the far-end LER completes the switchover ⚡.
This protocol is a single-phased protocol, as described above 🦋. In the following subsections, we describe the protocol messages that are used between the two end points of the protection domain 📝.
4.1. Transmission and Acceptance of PSC Control Packets ✨
Okay so PSC control packets SHALL be sent over the protection path only 🛤️ This keeps regular data traffic undisturbed in the most common case, which is the Normal state 💅 Sticking to one path also dodges messy conflicts and race conditions that could pop up if PSC messages went down both paths 🙈
When the protection domain state changes because of a local input, three PSC messages SHALL be sent as quickly as possible so switching is fast ⚡ That burst of three means switching still works even if one or two of the packets get lost or corrupted 🫶 When the state changes because of a remote message, the LER SHOULD send those three rapid messages. But if the LER moves from WTR state to Normal state because of a remote NR message, the three rapid messages SHALL be sent. After the rapid burst, the LER MUST keep retransmitting the most recently sent PSC message on a continual basis 🔁
Both the default frequency of the three rapid messages and the default frequency of the continual message transmission SHALL be configurable by the operator 🎀 The actual frequencies MAY be configurable, at the time of establishment, for each individual protected LSP. For management purposes, the operator SHOULD be able to check the current default frequency values as well as the actual values for any specific LSP 📋 For protection switching within 50 ms, it is RECOMMENDED that the default interval of the first three rapid PSC messages SHOULD be no longer than 3.3 ms ⏱️ Using that frequency would let the far end be guaranteed to receive the trigger within 10 ms and finish the switch within 50 ms ✨ Subsequent messages SHOULD be continuously transmitted with a default interval of 5 seconds 💜 The continual messages exist to check that the PSC session is still alive 🌸
If no valid PSC message is received over a period of several continual message intervals, the last valid received message stays applicable 🧚
4.2. Protocol Format 🎀
The protocol messages SHALL be sent over the G-ACh as described in [RFC5586]. There is a single channel type for the whole set of PSC messages 💌 and the actual message function SHALL be identified by the Request field of the ACH payload, as described below.
The channel type for the PSC messages SHALL be PSC-CT=0x0024.
Here's the complete PSC message layout 👀
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|Version| Reserved | PSC-CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|Request|PT |R| Reserved1 | FPath | Path |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Length | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of PSC Packet with a G-ACh HeaderHere's what the pieces mean:
- Both
Reserved1andReserved2fields MUST be set to0and ignored upon receipt. 🙅 - The following subsections describe the remaining fields of the PSC payload.
4.2.1. PSC Ver Field 💖
The Ver field identifies the version of the protocol. For this version of the document, the value SHALL be 1.
4.2.2. PSC Request Field 🔥
The PSC protocol SHALL support transmission of the following requests between the two end points of the protection domain:
(14)Lockout of protection: the end point has disabled the protection path because of an administrative command. Both theFPathandPathfields SHALL be set to0. 🔒(12)Forced Switch: the transmitting end point has switched traffic to the protection path because of an administrative command. TheFPathfield SHALL indicate that the working path is being blocked (i.e.,FPathset to1), and thePathfield SHALL indicate that user data traffic is being transported on the protection path (i.e.,Pathset to1). 💪(10)Signal Fail: the transmitting end point has identified a signal fail condition on either the working or protection path. TheFPathfield SHALL identify the path that is reporting the failure condition (i.e., if protection path, thenFPathis set to0; if working path, thenFPathis set to1), and thePathfield SHALL indicate where the data traffic is being transported (i.e., if protection path is blocked, thenPathis set to0; if working path is blocked, thenPathis set to1). 🚨(7)Signal Degrade: the transmitting end point has identified a degradation of the signal, or of the integrity of the packet transmission, on either the working or protection path. This request is only a placeholder for now 🫠 The specifics for how this degradation is identified are out of scope for this document, and the details of what to do in this situation are left for future specification.(5)Manual Switch: the transmitting end point has switched traffic to the protection path because of an administrative Manual Switch command. TheFPathfield SHALL indicate that the working path is being blocked (i.e.,FPathset to1), and thePathfield SHALL indicate that user data traffic is being transported on the protection path (i.e.,Pathset to1). 🕹️(4)Wait-to-Restore: the transmitting end point is recovering from a failure condition of the working path and has started the Wait-to-Restore timer.FPathSHALL be set to0and ignored upon receipt.PathSHALL indicate the working path that is currently being protected (i.e.,Pathset to1). ⏳(1)Do-not-Revert: the transmitting end point has recovered from a failure or blocked condition, but because of its local settings, it is asking the protection domain to keep transporting the data as if it is in a protecting state, instead of reverting to the Normal state.FPathSHALL be set to0and ignored upon receipt.PathSHALL indicate the working path that is currently being protected (i.e.,Pathset to1). 🙅♀️(0)No Request: the transmitting end point has nothing to report. TheFPathandPathfields SHALL be set according to the transmission state of the end point; see Section 4.3.3 for detailed scenarios. 🌤️
All other values are for future extensions (to be administered by IANA) and SHALL be ignored upon receipt. 🔮
4.2.3. Protection Type (PT) Field 🦋
The PT field indicates the currently configured protection architecture type. This SHOULD be validated to be consistent for both ends of the protection domain. If an inconsistency is detected, then an alarm SHALL be sent to the management system. The possible values are:
3: bidirectional switching using a permanent bridge2: bidirectional switching using a selector bridge1: unidirectional switching using a permanent bridge0: for future extensions
As described in the Introduction (Section 1.1), a 1+1 protection architecture is characterized by the use of a permanent bridge at the source node, whereas the 1:1 and 1:n protection architectures are characterized by the use of a selector bridge at the source node. 🌉
4.2.4. Revertive (R) Field 🔄
This field indicates that the transmitting end point is configured to work in revertive mode. If there is an inconsistency between the two end points (one end point is configured for revertive action and the other is in non-revertive mode), then the management system SHOULD be notified. The possible values are:
0- non-revertive mode1- revertive mode
4.2.5. Fault Path (FPath) Field 🛠️
The FPath field indicates which path (i.e., working or protection) is identified to be in a fault condition or affected by an administrative command, when a fault or command is indicated by the Request field to be in effect. The possible values are:
0: indicates that the anomaly condition is on the protection path1: indicates that the anomaly condition is on the working path2-255: for future extensions and SHALL be ignored by this version of the protocol.
4.2.6. Data Path (Path) Field 🛣️
The Path field indicates which data is being transported on the protection path. Under normal conditions, the protection path (especially in 1:1 or 1:n architecture) does not need to carry any user data traffic. If there is a failure or degrade condition on one of the working paths, then that working path's data traffic will be transported over the protection path. The possible values are:
0: indicates that the protection path is not transporting user data traffic (in 1:n architecture) or is transporting redundant user data traffic (in 1+1 architecture).1: indicates that the protection path is transmitting user traffic, replacing the use of the working path.2-255: for future extensions and SHALL be ignored by this version of the protocol.
4.2.7. Additional TLV Information 🧩
It may be necessary for future applications of the protocol to include additional information for the proper processing of the requests. For this purpose, optional additional information may be included in the PSC payload. This information MUST include a header that indicates the total length (in bytes) of the additional information.
This information includes the following fields:
- TLV Length: indicates the number of bytes included in the optional TLV information. For the basic PSC protocol operation described in this document, this value MUST be
0. - Optional TLVs: this includes any additional information formatted as TLV units. There are no TLV units defined for the basic PSC operation.
4.3. Principles of Operation 🌈
In all of the following subsections, assume a protection domain between LER-A and LER-Z, using paths W (working) and P (protection), as shown in Figure 3.
+-----+ //=======================\\ +-----+
|LER-A|// Working Path \\|LER-Z|
| /| |\ |
| ?< | | >? |
| \|\\ Protection Path //|/ |
+-----+ \\=======================// +-----+
|--------Protection Domain--------|
Figure 3: Protection Domain4.3.1. Basic Operation 💖
okay so the whole point of the PSC protocol is to let one end point of the protection domain tell its bestie (the peer) what's going on in the domain from its own point of view, and to coordinate where the user data traffic actually goes 🦋. The end point's current state shows up in two places: the Request field (its own local requests) and the FPath field (what it knows about a blocked path) ✨. The coordination part lives in the Path field, which says where the user data is being transmitted 🛤️. Except during a protection switch, the Path field should be identical on both end points at any given time 💅. The Request and FPath values, though, are allowed to be different between the two ends, no drama 🫶. The big tea is that a remote message might NOT make the end point change the Request field it's sending, even though it does affect the Path field 👀 (the details are in the subsections below).
The protocol is single-phased 🌸. "Single-phased" just means each end point tells its peer about a change in operation (switching to or from the protection path) and then makes the switch right away, without waiting for an acknowledgement 🏃♀️. The side effect is that during state transitions triggered from one side only (like operator commands or unidirectional SF), there's a short window where one LER might be transporting or selecting data from one transport path while the other end point is doing it from the other path 😭. That gets sorted out once the remote message arrives and the far-end LER does its protection switching operation ✨.
The subsections below spell out which messages each end point sends in different scenarios 📝. Messages are written as REQ(FP, P), where REQ is the value of the Request field, FP is the value of the FPath field, and P is the value of the Path field 🎀. Everything assumes a protection domain between LER-A and LER-Z with one working path and one protection path (see Figure 3) 🛣️. Quick reminder: with 1:1 protection the data goes exclusively on either the protection path or the working path 🙅♀️, but with 1+1 protection the traffic goes on both paths and the receiving LER picks the right signal based on the state 🧚. The text calls this choosing-and-sending business "transport" of the data traffic 💜. For 1+1 unidirectional protection, the selector only switches in reaction to a local message 🔒. When a LER configured for 1+1 unidirectional protection gets a remote message, it moves to the new remote state, but it keeps selecting data according to the latest known local state 🫣. And when the LER transitions into the Normal state, the PSC Control Process SHALL check the persistent state of the local triggers to decide whether it should go into yet another new state 🔍.
4.3.2. Priority of Inputs 👑
As noted above (in Section 3.1), the PSC Control Process takes input from five local input sources 🎯. Some locally triggered inputs outrank others, so there's a priority order. From highest to lowest priority, the local requests are:
- Clear (operator command) 🧹
- Lockout of protection (operator command) 🔐
- Forced Switch (operator command) ⚡
- Signal Fail on protection (OAM / control-plane / server indication) 💀
- Signal Fail on working (OAM / control-plane / server indication) 🙈
- Signal Degrade on working (OAM / control-plane / server indication) 🍂
- Clear Signal Fail/Degrade (OAM / control-plane / server indication) 🧼
- Manual Switch (operator command) 🕹️
- WTR Expires (WTR timer) ⏰
- No Request (default) 🌈
Like we said before, the Local Request logic SHALL always pick the local input with the highest priority as the current local request 💅. Only that top input gets to drive the control logic, and anything lower than it gets ignored 🙅♀️.
The remote message from the far-end LER gets a priority that sits just below the matching local input 🪞. For example, a remote Forced Switch ranks just below a local Forced Switch, but still above a local Signal Fail on protection 💖. As mentioned in Section 3.6.1, the state transition is decided by whichever is higher: the highest-priority local input or the remote message 🏆. That same comparison also decides whether the state is classified as local or remote 🧠. The subsections that follow walk through the transitions based on the current state and the higher of those two inputs 🎀.
4.3.3. Operation of PSC States 🌟
The following subsections cover how each state from Section 3.6 operates 🧩. For every state, we define the reaction (the new state plus the message to transmit) to each possible input, which is either the highest-priority local input or a PSC message from the remote LER 📮. Heads up: the new state is always described from the point of view of the LER reporting it, so "the LER goes into a state" really means "the LER is reporting that the protection domain is now in this new state" 🪄. If a definition says to "ignore" a message, the protection domain SHALL stay in its current state, and the LER SHALL keep transmitting the current PSC message (as covered in Section 4.1) 🫶.
When a LER is in a remote state (meaning it transitioned because of a PSC message from the far-end LER) and it receives a new PSC message from the far end that signals a contradictory state, like being in remote Unavailable state and then getting a remote FS(1,1) message, the PSC Control logic SHALL re-evaluate all inputs (both the local input and the remote message) as if the LER were in the Normal state 🔄. Plot twist, but it's all very orderly 💜.
4.3.3.1. Normal State 🌸
When there's no special condition in effect for the protection domain, the ingress LER SHALL forward the user data along the working path 🛤️. In the case of 1+1 protection, the Permanent Bridge bridges the data onto the protection path as well 🌉. The receiving LER SHALL read the data from the working path 📥.
When the LER transitions into the Normal state, the PSC Control Process SHALL check the persistent state of the local triggers to decide whether it should further transition into a new state 🔍. If that check leads to a new state, the LER SHALL transmit the matching message described in this section, and SHALL use the data path that goes with the new state 🚀. While the protection domain stays in Normal state, the end point SHALL transmit an NR(0,0) message, which basically says "nothing to report, and the data traffic is being transported on the working path" 😌✨.
When the protection domain is in Normal state, these are the transitions that matter for a local input to the LER 💅:
- A local Lockout of protection input SHALL make the LER go into local Unavailable state and start transmitting an
LO(0,0)message 🔐. - A local Forced Switch input SHALL make the LER go into local Protecting administrative state and start transmitting an
FS(1,1)message ⚡. - A local Signal Fail indication on the protection path SHALL make the LER go into local Unavailable state and start transmitting an
SF(0,0)message 💀. - A local Signal Fail indication on the working path SHALL make the LER go into local Protecting failure state and start transmitting an
SF(1,1)message 🙈. - A local Manual Switch input SHALL make the LER go into local Protecting administrative state and start transmitting an
MS(1,1)message 🕹️. - All other local inputs SHALL be ignored 🙃.
In Normal state, remote messages get the following reactions from the LER 📮:
- A remote Lockout of protection message SHALL make the LER go into remote Unavailable state, while it keeps transmitting the
NR(0,0)message 🔒. - A remote Forced Switch message SHALL make the LER go into remote Protecting administrative state and start transmitting an
NR(0,1)message 💫. - A remote Signal Fail message indicating the failure is on the protection path SHALL make the LER (LER-A) go into remote Unavailable state, while it keeps transmitting the
NR(0,0)message 🫣. - A remote Signal Fail message indicating the failure is on the working path SHALL make the LER go into remote Protecting failure state, and transmit an
NR(0,1)message 🌧️. - A remote Manual Switch message SHALL make the LER go into remote Protecting administrative state, and transmit an
NR(0,1)message 🎀. - All other remote messages SHALL be ignored 🙈.
4.3.3.2. Unavailable State 🙈
okay so the protection domain lands in the Unavailable state when the protection path is unavailable 💀. That can happen because someone hit a Lockout operator command, or because there's an SF detected on the protection path. In this state the data traffic SHALL be transported on the working path and is not protected 😭. When the domain is in Unavailable state, the PSC messages may not get through, so the protection depends more on the local inputs than on the remote messages (which may not be received) 🫶.
The protection domain exits the Unavailable state and goes back to the Normal state when either the operator clears the Lockout command or the protection path recovers from the signal fail or degraded situation ✨. Both ends keep sending the PSC messages over the protection path after that recovery 🦋.
When the LER (assume LER-A) is in Unavailable state, these transitions matter when a local input shows up 👑:
- A local Clear input SHALL be ignored if the LER is in remote Unavailable state. If it's in local Unavailable state due to a Lockout command, then the input SHALL cause the LER to go to Normal state 💅.
- A local Lockout of protection input SHALL cause the LER to remain in local Unavailable state and transmit an
LO(0,0)message to the far-end LER (LER-Z) 🔒. - A local Clear SF of the protection path in local Unavailable state that is due to an SF on the protection path SHALL cause the LER to go to Normal state. If the LER is in remote Unavailable state but has an active local SF condition, then the local Clear SF SHALL clear the SF local condition, and the LER SHALL remain in remote Unavailable state and begin transmitting
NR(0,0)messages 🌸. In all other cases, the local Clear SF SHALL be ignored. - A local Forced Switch SHALL be ignored by the PSC Control logic when in Unavailable state as a result of a (local or remote) Lockout of protection 🙅. If it's in Unavailable state due to an SF on protection, then the FS SHALL cause the LER to go into local Protecting administrative state and begin transmitting an
FS(1,1)message 🎀. It should be noted that because the protection path is unavailable (i.e., due to the SF condition), this FS may not be received by the far-end until the SF condition is cleared 🥺. - A local Signal Fail on the protection path input when in local Unavailable state (by implication, this is due to a local SF on protection) SHALL cause the LER to remain in local Unavailable state and transmit an
SF(0,0)message 💀. - A local Signal Fail on the working path input when in remote Unavailable state SHALL cause the LER to remain in remote Unavailable state and transmit an
SF(1,0)message 🧚. - All other local inputs SHALL be ignored 🫠.
If remote messages are coming in over the protection path, here's what they do 📬:
- A remote Lockout of protection message SHALL cause the LER to remain in Unavailable state. (Note that if the LER was previously in local Unavailable state due to a Signal Fail on the protection path, it will now be in remote Unavailable state.) It also continues transmitting the current message, which is either
NR(0,0),LO(0,0), orSF(0,0)🍓. - A remote Forced Switch message SHALL be ignored by the PSC Control logic when in Unavailable state as a result of a (local or remote) Lockout of protection 🚫. If it's in Unavailable state due to a local or remote SF on protection, then the FS SHALL cause the LER to go into remote Protecting administrative state. If the Unavailable state is due to a local SF, the LER also begins transmitting an
SF(0,1)message ✨. - A remote Signal Fail message that indicates the failure is on the protection path SHALL cause the LER to remain in Unavailable state and continue transmitting the current message, which is
NR(0,0),SF(0,0), orLO(0,0)💜. - A remote No Request, when the LER is in remote Unavailable state and there's no active local Signal Fail, SHALL cause the LER to go into Normal state and continue transmitting the current message 🌈. If there's a local Signal Fail on the protection path, the LER SHALL remain in local Unavailable state and transmit an
SF(0,0)message 😤. If there's a local Signal Fail on the working path, the LER SHALL go into local Protecting Failure state and transmit anSF(1,1)message 🔥. When in local Unavailable state, the remote message SHALL be ignored 🙈. - All other remote messages SHALL be ignored 💅.
4.3.3.3. Protecting Administrative State 🌷
In the Protecting administrative state, the user data traffic SHALL be transported on the protection path, while the working path is blocked by an operator command (i.e., Forced Switch or Manual Switch) 🦋. The difference between a local FS and a local MS affects which local indicators can be received 👀. The Local Request logic will block any local SF when under the influence of a local FS, whereas the SF would override a local MS 🙅♀️. In general, an MS gets canceled when there's either a local or remote SF or LO condition 💔.
Here's how the LER reacts to local input 🎀:
- A local Clear SHALL be ignored if in remote Protecting administrative state. If it's in local Protecting administrative state, then this input SHALL cause the LER to go into Normal state 💅.
- A local Lockout of protection input SHALL cause the LER to go into local Unavailable state and begin transmission of an
LO(0,0)message 🔒. - A local Forced Switch input SHALL cause the LER to remain in local Protecting administrative state and transmit an
FS(1,1)message 👑. - A local Signal Fail indication on the protection path SHALL cause the LER to go into local Unavailable state and begin transmission of an
SF(0,0)message, if the current state is due to a (local or remote) Manual Switch operator command. If the LER is in (local or remote) Protecting administrative state due to an FS situation, then the SF on protection SHALL be ignored 🥲. - A local Signal Fail indication on the working path SHALL cause the LER to go into local Protecting failure state and begin transmitting an
SF(1,1)message, if the current state is due to a (local or remote) Manual Switch operator command. If the LER is in remote Protecting administrative state due to a remote Forced Switch command, then this local indication SHALL cause the LER to remain in remote Protecting administrative state and transmit anSF(1,1)message. If the LER is in local Protecting administrative state due to a local Forced Switch command, then this indication SHALL be ignored (i.e., the indication should have been blocked by the Local Request logic) 🧠. - A local Clear SF SHALL clear any local SF condition that may exist. If it's in remote Protecting administrative state, the LER SHALL stop transmitting the
SF(x,1)message and begin transmitting anNR(0,1)message 🌟. - A local Manual Switch input SHALL be ignored if in remote Protecting administrative state due to a remote Forced Switch command. If the current state is due to a (local or remote) Manual Switch operator command, it SHALL cause the LER to remain in local Protecting administrative state and transmit an
MS(1,1)message 🍭. - All other local inputs SHALL be ignored 🫧.
While in Protecting administrative state, the LER may receive and react to remote PSC messages like this 📨:
- A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state and begin transmitting an
NR(0,0)message 😱. It should be noted that this automatically cancels the current Forced Switch or Manual Switch command, and data traffic is reverted to the working path 🙃. - A remote Forced Switch message SHALL be ignored by the PSC Process logic if there's an active local Forced Switch operator command 🛑. If the Protecting administrative state is due to a remote Forced Switch message, then the LER SHALL remain in remote Protecting administrative state and continue transmitting the last message 🫶. If the Protecting administrative state is due to either a local or remote Manual Switch, then the LER SHALL remain in remote Protecting administrative state (updating the state information with the proper relevant information) and begin transmitting an
NR(0,1)message 🌈. - A remote Signal Fail message indicating a failure on the protection path SHALL cause the LER to go into remote Unavailable state and begin transmitting an
NR(0,0)message, if the Protecting administrative state is due to a Manual Switch command. It should be noted that this automatically cancels the current Manual Switch command, and data traffic is reverted to the working path 🌷. - A remote Signal Fail message indicating a failure on the working path SHALL be ignored if there's an active local Forced Switch command. If the Protecting state is due to a local or remote Manual Switch, then the LER SHALL go to remote Protecting failure state and begin transmitting an
NR(0,1)message 💫. - A remote Manual Switch message SHALL be ignored by the PSC Control logic if in Protecting administrative state due to a local or remote Forced Switch 🙅. If it's in Protecting administrative state due to a remote Manual Switch, then the LER SHALL remain in remote Protecting administrative state and continue transmitting the current message 🎀. If it's in local Protecting administrative state due to an active Manual Switch, then the LER SHALL remain in local Protecting administrative state and continue transmission of the
MS(1,1)message 🦋. - A remote
DNR(0,1)message SHALL be ignored if in local Protecting administrative state. If it's in remote Protecting administrative state, then the LER SHALL go to Do-not-Revert state and continue transmitting the current message 🧁. - A remote
NR(0,0)message SHALL be ignored if in local Protecting administrative state. If it's in remote Protecting administrative state and there's no active local Signal Fail indication, then the LER SHALL go to Normal state and begin transmitting anNR(0,0)message ✨. If there's a local Signal Fail on the working path, the LER SHALL go to local Protecting failure state and begin transmitting anSF(1,1)message 🚨. - All other remote messages SHALL be ignored 🫧.
4.3.3.4. Protecting Failure State ✨
Okay so this is the moment the protection mechanism has been triggered and the protection domain has actually done a protection switch 🔄. Now the domain is in the Protecting failure state 🛡️. In this state the normal data traffic SHALL be transported on the protection path. If an LER is here, it means either there was a local SF condition or it got a remote SF PSC message. Either way, the SF condition or message is telling it that the failure is on the working path 💅.
This state may get overridden by the Unavailable state triggers (aka Lockout of protection or SF on the protection path) or by issuing an FS operator command. It gets cleared when the SF condition is cleared 🧹. To stop flapping from an intermittent fault, the LER SHOULD employ a Wait-to-Restore timer so it delays going back to Normal until the network has actually stabilized (see Section 3.5) ⏳.
Here's how the LER reacts to local input 🎀:
- A local Clear SF SHALL be ignored if in remote Protecting failure state. If in local Protecting failure state and the LER is configured for revertive behavior, then this input SHALL cause the LER to go into Wait-to-Restore state, start the WTR timer, and begin transmitting a
WTR(0,1)message. If in local Protecting failure state and the LER is configured for non-revertive behavior, then this input SHALL cause the LER to go into Do-not-Revert state and begin transmitting aDNR(0,1)message. - A local Lockout of protection input SHALL cause the LER to go into Unavailable state and begin transmission of an
LO(0,0)message. - A local Forced Switch input SHALL cause the LER to go into Protecting administrative state and begin transmission of an
FS(1,1)message. - A local Signal Fail indication on the protection path SHALL cause the LER to go into Unavailable state and begin transmission of an
SF(0,0)message. - A local Signal Fail indication on the working path SHALL cause the LER to remain in local Protecting failure state and transmit an
SF(1,1)message. - All other local inputs SHALL be ignored.
While in Protecting failure state, the LER may receive remote PSC messages and react to them like this 👀:
- A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state. If it's in local Protecting failure state, the LER SHALL transmit an
SF(1,0)message; otherwise, it SHALL transmit anNR(0,0)message. It should be noted that this may cause loss of user data since the working path is still in a failure condition 😭. - A remote Forced Switch message SHALL cause the LER to go into remote Protecting administrative state. If it's in local Protecting failure state, the LER SHALL transmit the
SF(1,1)message; otherwise, it SHALL transmitNR(0,1). - A remote Signal Fail message indicating a failure on the protection path SHALL cause the LER to go into remote Unavailable state. If it's in local Protecting failure state, then the LER SHALL transmit an
SF(1,0)message; otherwise, it SHALL transmit anNR(0,0)message. It should be noted that this may cause loss of user data since the working path is still in a failure condition 💀. - If in remote Protecting failure state, a remote Wait-to-Restore message SHALL cause the LER to go into remote Wait-to-Restore state and continue transmission of the current message.
- If in remote Protecting failure state, a remote Do-not-Revert message SHALL cause the LER to go into remote Do-not-Revert state and continue transmission of the current message.
- If in remote Protecting failure state, a remote
NR(0,0)SHALL cause the LER to go to Normal state. - All other remote messages SHALL be ignored.
4.3.3.5. Wait-to-Restore State 🌸
When a failure condition on the working path is recovering, the Wait-to-Restore state is what the PSC protocol uses to delay reverting to Normal state. It waits for the WTR timer to run out so the recovering failure has time to settle 🧘♀️. While in Wait-to-Restore state, the data traffic SHALL continue to be transported on the protection path. The natural move from Wait-to-Restore to Normal happens when the WTR timer expires ⏰.
When in Wait-to-Restore state, here's the reaction to local inputs:
- A local Lockout of protection command SHALL send the Stop command to the WTR timer, go into local Unavailable state, and begin transmitting an
LO(0,0)message. - A local Forced Switch command SHALL send the Stop command to the WTR timer, go into local Protecting administrative state, and begin transmission of an
FS(1,1)message. - A local Signal Fail indication on the protection path SHALL send the Stop command to the WTR timer, go into local Unavailable state, and begin transmission of an
SF(0,0)message. - A local Signal Fail indication on the working path SHALL send the Stop command to the WTR timer, go into local Protecting failure state, and begin transmission of an
SF(1,1)message. - A local Manual Switch input SHALL send the Stop command to the WTR timer, go into local Protecting administrative state, and begin transmission of an
MS(1,1)message. - A local WTR Expires input SHALL cause the LER to remain in Wait-to-Restore state, and begin transmitting an
NR(0,1)message. - All other local inputs SHALL be ignored.
When in Wait-to-Restore state, here's the reaction to remote messages 📡:
- A remote Lockout of protection message SHALL send the Stop command to the WTR timer, go into remote Unavailable state, and begin transmitting an
NR(0,0)message. - A remote Forced Switch message SHALL send the Stop command to the WTR timer, go into remote Protecting administrative state, and begin transmission of an
NR(0,1)message. - A remote Signal Fail message for the protection path SHALL send the Stop command to the WTR timer, go into remote Unavailable state, and begin transmission of an
NR(0,0)message. - A remote Signal Fail message for the working path SHALL send the Stop command to the WTR timer, go into remote Protecting failure state, and begin transmission of an
NR(0,1)message. - A remote Manual Switch message SHALL send the Stop command to the WTR timer, go into remote Protecting administrative state, and begin transmission of an
NR(0,1)message. - If the WTR timer is running, then a remote NR message SHALL be ignored. If the WTR timer is stopped, then a remote NR message SHALL cause the LER to go into Normal state.
- All other remote messages SHALL be ignored.
4.3.3.6. Do-not-Revert State 🙅♀️
Do-not-Revert state is basically a continuation of the Protecting failure state when the protection domain is set up for non-revertive behavior. While in Do-not-Revert state, data traffic SHALL continue to be transported on the protection path until the administrator sends a command to revert to Normal state. It should be noted that there is a fundamental difference between this state and Normal -- whereas Forced Switch in Normal state actually causes a switch in the transport path used, in Do-not-Revert state the Forced Switch just switches the state (to Protecting administrative state) but the traffic would continue to be transported on the protection path! 🤯 To revert back to Normal state, the administrator SHALL issue a Lockout of protection command followed by a Clear command.
When in Do-not-Revert state, here's the reaction to local input:
- A local Lockout of protection command SHALL cause the LER to go into local Unavailable state and begin transmitting an
LO(0,0)message. - A local Forced Switch command SHALL cause the LER to go into local Protecting administrative state and begin transmission of an
FS(1,1)message. - A local Signal Fail indication on the protection path SHALL cause the LER to go into local Unavailable state and begin transmission of an
SF(0,0)message. - A local Signal Fail indication on the working path SHALL cause the LER to go into local Protecting failure state and begin transmission of an
SF(1,1)message. - A local Manual Switch input SHALL cause the LER to go into local Protecting administrative state and begin transmission of an
MS(1,1)message. - All other local inputs SHALL be ignored.
When in Do-not-Revert state, here's the reaction to remote messages 🫶:
- A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state and begin transmitting an
NR(0,0)message. - A remote Forced Switch message SHALL cause the LER to go into remote Protecting administrative state and begin transmission of an
NR(0,1)message. - A remote Signal Fail message for the protection path SHALL cause the LER to go into remote Unavailable state and begin transmission of an
NR(0,0)message. - A remote Signal Fail message for the working path SHALL cause the LER to go into remote Protecting failure state and begin transmission of an
NR(0,1)message. - A remote Manual Switch message SHALL cause the LER to go into remote Protecting administrative state and begin transmission of an
NR(0,1)message. - All other remote messages SHALL be ignored.
5. IANA Considerations 📋
5.1. Pseudowire Associated Channel Type 🦋
In the "Pseudowire Name Spaces (PWE3)" registry, IANA maintains the "Pseudowire Associated Channel Types" registry.
IANA has assigned a new code point from this registry. The code point has been assigned from the code point space that requires "IETF Review" as follows:
Registry:
Value Description TLV Follows Reference
------ ----------------------- ----------- ---------------
0x0024 Protection State no [this document]
Coordination Protocol -
Channel Type (PSC-CT)5.2. PSC Request Field 💜
IANA has created and maintains a new sub-registry within the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry called the "MPLS PSC Request Registry". All code points within this registry shall be allocated according to the "Standards Action" procedure as specified in [RFC5226].
The PSC Request Field is 4 bits, and the values have been allocated as follows:
Value Description Reference
----- --------------------- ---------------
0 No Request [this document]
1 Do-not-Revert [this document]
2 - 3 Unassigned
4 Wait-to-Restore [this document]
5 Manual Switch [this document]
6 Unassigned
7 Signal Degrade [this document]
8 - 9 Unassigned
10 Signal Fail [this document]
11 Unassigned
12 Forced Switch [this document]
13 Unassigned
14 Lockout of protection [this document]
15 Unassigned5.3. Additional TLVs 🧚
The IANA has created and maintains a new sub-registry within the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry called the "MPLS PSC TLV Registry". All code points within this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC5226].
6. Security Considerations 🔒✨
okay bestie, MPLS-TP is basically a subset of MPLS, so it borrows a ton of MPLS's security vibes 💖. MPLS networks assume it's super hard to inject traffic into the network and equally hard to make traffic leave it 🙈. The control-plane protocols use hop-by-hop security and a "chain-of-trust" model, so there's no end-to-end control-plane security. If you want the generic MPLS security stuff, go check [RFC5920] 📚.
This document describes a protocol carried in the G-ACh [RFC5586], so it depends on the security of the G-ACh itself 🫶. The G-ACh is a generalization of the Associated Channel defined in [RFC4385], which means this document leans really heavily on the security mechanisms for the Associated Channel described in those two documents 💅.
A specific concern for the G-ACh is that it can be used to provide a covert channel 👀. This problem is bigger than this document, so it doesn't need to be solved here. Still, the channel provides end-to-end connectivity and SHOULD NOT be policed by transit nodes, which means there's no simple way to prevent traffic from being carried between G-ACh consenting nodes 🙃.
A good discussion of the data-plane security of an associated channel is in [RFC5085], and that document also describes some mitigation techniques 🌸.
The G-ACh is essentially connection oriented, so injecting or modifying control messages specified in this document requires subverting a transit node 🕵️♀️. That's generally considered hard in MPLS networks and impossible to protect against at the protocol level, so management-level techniques are more appropriate 🎀.
Heads up: there's a new concern for this document, and it's accidental corruption of messages (through faulty implementations or random corruption) 😭. The main worry is theRequest,FPath, andPathfields, because changing any of them would change how the peer endpoint behaves 💀.
This document doesn't define a way to avoid a change in network behavior when a message indicates a change in protection status. Still, the transition between states will converge on a known and stable behavior, even when messages don't match reality 🦋✨.
7. Acknowledgements 🫶
The authors want to give a huge thank-you to everyone in the teams that helped define and specify the MPLS Transport Profile 🌈. That means the Joint Working Team, the MPLS Interoperability Design Team in the IETF, and the T-MPLS Ad Hoc Group in ITU-T 💜.
8. Contributing Authors 🧚
Here are the contributing authors and their contact info, exactly as they appear in the original:
Hao Long
Huawei Technologies Co., Ltd.
F3 Building, Huawei Industrial Park
Bantian, Shenzhen, China
EMail: longhao@huawei.com
Davide Chiara
Ericsson
Via Calda 5, 16152 Genova Italy
EMail: davide.chiara@ericsson.com
Dan Frost
Cisco Systems
EMail: danfrost@cisco.com
Francesco Fondelli
Ericsson
via Moruzzi 1
56100, Pisa
Italy
EMail: francesco.fondelli@ericsson.com9. References 📚🎀
9.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.
- [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
9.2. Informative References
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
- [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
- [RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006.
- [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
- [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
- [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
- [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
- [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
- [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011.
Appendix A. PSC State Machine Tables ✨
okay so this appendix is basically the whole PSC state machine but in a big cute table 🧚 it's the same info as Section 4.3.3, just in grid form, so if the table and the text ever disagree, the text wins 💅 this is a functional description, not an implementation spec, so don't treat it like code to copy 🎀
bestie, the table splits the 6 text states into 13 states 🌸 why? bc they're differentiating between all the different conditional cases in the text, and the remote and local versions of Unavailable, Protecting failure, and Protecting administrative get split too 💖
there's only one table, but it's chopped into two parts for space reasons 🦋 part one is the 13 states, the eight local inputs (stuff the node itself generates), and what happens when each input shows up in each state. part two is the 13 states and the eight remote inputs (stuff from some other node) 🫶
there are 13 rows, headers aside, and each row is one extended state ✨
the first column is the current state. states with both a source and a cause get written as State:Cause:Source, so UA:LO:L means Unavailable, caused by a Lockout of protection that was a local input 😭 and plain N is just Normal, no cause tracked bc there's nothing to track 💀
here are the 13 extended states:
N: Normal stateUA:LO:L: Unavailable state due to local LockoutUA:P:L: Unavailable state due to local SF on protection pathUA:LO:R: Unavailable state due to remote Lockout of protection messageUA:P:R: Unavailable state due to remote SF message on protection pathPF:W:L: Protecting failure state due to local SF on working pathPF:W:R: Protecting failure state due to remote SF message on working pathPA:F:L: Protecting administrative state due to local FS operator commandPA:M:L: Protecting administrative state due to local MS operator commandPA:F:R: Protecting administrative state due to remote FS messagePA:M:R: Protecting administrative state due to remote MS messageWTR: Wait-to-Restore stateDNR: Do-not-Revert state
each state sends a particular set of Request, FPath and Path bits 🍓 the table below shows the message usually sent in each state, and if a state sends something different, there's a footnote under the state-machine table to tell you 🙈
State REQ(FP,P)
------- ---------
N NR(0,0)
UA:LO:L LO(0,0)
UA:P:L SF(0,0)
UA:LO:R NR(0,0)
UA:P:R NR(0,0)
PF:W:L SF(1,1)
PF:W:R NR(0,1)
PA:F:L FS(1,1)
PA:M:L MS(1,1)
PA:F:R NR(0,1)
PA:M:R NR(0,1)
WTR WTR(0,1)
DNR DNR(0,1)the top row of each table is the list of possible inputs 👑 the local ones are:
NR: No RequestOC: Operator ClearLO: Lockout of protectionSF-P: Signal Fail on protection pathSF-W: Signal Fail on working pathFS: Forced SwitchSFc: Clear Signal FailMS: Manual SwitchWTRExp: WTR Expired
and the remote ones are:
LO: remote LO messageSF-P: remote SF message indicating protection pathSF-W: remote SF message indicating working pathFS: remote FS messageMS: remote MS messageWTR: remote WTR messageDNR: remote DNR messageNR: remote NR message
okay now the source stuff 🔥 Section 4.3.3 calls some states 'remote' and some 'local', and by definition every state in the local-sources table is a local state, and every state in the remote-sources table is a remote state 💜 for example, Section 4.3.3.1 says "A local Lockout of protection input SHALL cause the LER to go into local Unavailable state" 🌈 since the trigger is local, 'local Unavailable state' shows up in the local-sources table, by definition ✨ and Section 4.3.3.1 also says:
"A remote Lockout of protection message SHALL cause the LER to go into remote Unavailable state"
so the Unavailable rows in the remote-sources table are, by definition, remote Unavailable states 🦋
every cell in the table has either a state, a footnote, or the letter 'i' 💖 'i' means Ignore, which is just a fancy way of saying keep doing what you're doing 🌸 see Section 4.3.3, and the footnotes sit below the table 🎀
Part 1: Local input state machine
| OC | LO | SF-P | FS | SF-W | SFc | MS | WTRExp
--------+-----+-------+------+------+------+------+------+-------
N | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i
UA:LO:L | N | i | i | i | i | i | i | i
UA:P:L | i |UA:LO:L| i |PA:F:L| i | [5] | i | i
UA:LO:R | i |UA:LO:L| [1] | i | [2] | [6] | i | i
UA:P:R | i |UA:LO:L|UA:P:L|PA:F:L| [3] | [6] | i | i
PF:W:L | i |UA:LO:L|UA:P:L|PA:F:L| i | [7] | i | i
PF:W:R | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i | i | i
PA:F:L | N |UA:LO:L| i | i | i | i | i | i
PA:M:L | N |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i | i | i
PA:F:R | i |UA:LO:L| i |PA:F:L| [4] | [8] | i | i
PA:M:R | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i
WTR | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| [9]
DNR | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |PA:M:L| i
Part 2: Remote messages state machine
| LO | SF-P | FS | SF-W | MS | WTR | DNR | NR
--------+-------+------+------+------+------+------+------+------
N |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | i
UA:LO:L | i | i | i | i | i | i | i | i
UA:P:L | [10] | i | [19] | i | i | i | i | i
UA:LO:R | i | i | i | i | i | i | i | [16]
UA:P:R |UA:LO:R| i |PA:F:R| i | i | i | i | [16]
PF:W:L | [11] | [12] |PA:F:R| i | i | i | i | i
PF:W:R |UA:LO:R|UA:P:R|PA:F:R| i | i | [14] | [15] | N
PA:F:L |UA:LO:R| i | i | i | i | i | i | i
PA:M:L |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | i | i
PA:F:R |UA:LO:R| i | i | i | i | i | DNR | [17]
PA:M:R |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | DNR | N
WTR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | [18]
DNR |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | i | ithe footnotes, bestie 🧚 read these carefully, they're the fine print:
- [1] Remain in the current state (UA:LO:R) and transmit SF(0,0).
- [2] Remain in the current state (UA:LO:R) and transmit SF(1,0).
- [3] Remain in the current state (UA:P:R) and transmit SF(1,0).
- [4] Remain in the current state (PA:F:R) and transmit SF(1,1).
- [5] If the SF being cleared is SF-P, transition to N. If it's SF-W, ignore the clear.
- [6] Remain in current state (UA:x:R), if the SFc corresponds to a previous SF, then begin transmitting NR(0,0).
- [7] If domain configured for revertive behavior transition to WTR, else transition to DNR.
- [8] Remain in PA:F:R and transmit NR(0,1).
- [9] Remain in WTR, send NR(0,1).
- [10] Transition to UA:LO:R continue sending SF(0,0).
- [11] Transition to UA:LO:R and send SF(1,0).
- [12] Transition to UA and send SF(1,0).
- [13] Transition to PF:W:R and send NR(0,1).
- [14] Transition to WTR state and continue to send the current message.
- [15] Transition to DNR state and continue to send the current message.
- [16] If the local input is SF-P, then transition to UA:P:L. If the local input is SF-W, then transition to PF:W:L. Else, transition to N state and continue to send the current message.
- [17] If the local input is SF-W, then transition to PF:W:L. Else, transition to N state and continue to send the current message.
- [18] If the receiving LER's WTR timer is running, maintain current state and message. If the WTR timer is stopped, transition to N.
- [19] Transition to PA:F:R and send SF (0,1).
Appendix B. Exercising the Protection Domain 🦋
okay so there's a requirement in [RFC5654] (number 84) about verifying that the protection path is viable 🫶 the PSC protocol doesn't define a specific operation for this 🙈 but you can totally do it by combining PSC operations with other OAM functionalities 💅
one possible combo: issue a Lockout of protection operation, then use the OAM function for diagnostic testing of the protection path 🎀 and to test the paths when the working path isn't active, you'd do a Forced Switch to protection, then run the diagnostic function on either the working or protection path 🌸
Authors' Addresses 💖
Yaacov Weingarten (editor) Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel
EMail: yaacov.weingarten@nsn.com
Stewart Bryant Cisco United Kingdom
EMail: stbryant@cisco.com
Eric Osborne Cisco United States
EMail: eosborne@cisco.com
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon 45241 Israel
EMail: nurit.sprecher@nsn.com
Annamaria Fulignoli (editor) Ericsson Via Moruzzi Pisa 56100 Italy
EMail: annamaria.fulignoli@ericsson.com
📦 where this page comes from
- ietf: rfc6378 2011-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms