RFC 8227
MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology
RFC 8227: MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology 💍
Title block tea ☕ This one's from the IETF, and it's a Standards Track document, so it's an actual Internet Standard, not just a vibe. It's from August 2017 and the ISSN is 2070-1721. The authors are W. Cheng, L. Wang, and H. Li (all from China Mobile), H. van Helvoort (Hai Gaoming BV), and J. Dong (Huawei Technologies). Nothing is listed as obsoleted or updated in the header, so it's not replacing or patching any older RFC 🫶.
Abstract ✨
okay so this doc describes the requirements, architecture, and solutions for MPLS-TP Shared-Ring Protection (MSRP) on a ring topology for point-to-point (P2P) services 🔁. MSRP is designed to meet the ring protection requirements from RFC 5654. The doc also defines the Ring Protection Switching (RPS) protocol, which is what the nodes on an MPLS ring use to coordinate how they protect traffic 💅.
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 for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841 🌸.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8227 🦋.
Copyright Notice 💜
Copyright (c) 2017 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. Read these carefully because they spell out your rights and restrictions for this document 📖. Code Components pulled out of this document must include the 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4
3. MPLS-TP Ring Protection Criteria and Requirements . . . . . . 5
4. Shared-Ring Protection Architecture . . . . . . . . . . . . . 6
4.1. Ring Tunnel . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Establishment of the Ring Tunnel . . . . . . . . . . 8
4.1.2. Label Assignment and Distribution . . . . . . . . . . 9
4.1.3. Forwarding Operation . . . . . . . . . . . . . . . . 9
4.2. Failure Detection . . . . . . . . . . . . . . . . . . . . 10
4.3. Ring Protection . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . 12
4.3.2. Short-Wrapping . . . . . . . . . . . . . . . . . . . 14
4.3.3. Steering . . . . . . . . . . . . . . . . . . . . . . 17
4.4. Interconnected Ring Protection . . . . . . . . . . . . . 21
4.4.1. Interconnected Ring Topology . . . . . . . . . . . . 21
4.4.2. Interconnected Ring Protection Mechanisms . . . . . . 22
4.4.3. Ring Tunnels in Interconnected Rings . . . . . . . . 23
4.4.4. Interconnected Ring-Switching Procedure . . . . . . . 25
4.4.5. Interconnected Ring Detection Mechanism . . . . . . . 26
5. Ring Protection Coordination Protocol . . . . . . . . . . . . 27
5.1. RPS and PSC Comparison on Ring Topology . . . . . . . . . 27
5.2. RPS Protocol . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1. Transmission and Acceptance of RPS Requests . . . . . 30
5.2.2. RPS Protocol Data Unit (PDU) Format . . . . . . . . . 31
5.2.3. Ring Node RPS States . . . . . . . . . . . . . . . . 32
5.2.4. RPS State Transitions . . . . . . . . . . . . . . . . 34
5.3. RPS State Machine . . . . . . . . . . . . . . . . . . . . 36
5.3.1. Switch Initiation Criteria . . . . . . . . . . . . . 36
5.3.2. Initial States . . . . . . . . . . . . . . . . . . . 39
5.3.3. State Transitions When Local Request Is Applied . . . 40
5.3.4. State Transitions When Remote Request is Applied . . 44
5.3.5. State Transitions When Request Addresses to Another
Node is Received . . . . . . . . . . . . . . . . . . 47
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
6.1. G-ACh Channel Type . . . . . . . . . . . . . . . . . . . 51
6.2. RPS Request Codes . . . . . . . . . . . . . . . . . . . . 51
7. Operational Considerations . . . . . . . . . . . . . . . . . 52
8. Security Considerations . . . . . . . . . . . . . . . . . . . 52
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1. Normative References . . . . . . . . . . . . . . . . . . 53
9.2. Informative References . . . . . . . . . . . . . . . . . 54
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 561. Introduction 🌈
okay so, as Section 2.5.6.1 of [RFC5654] explains, a bunch of service providers are super into running MPLS Transport Profile (MPLS-TP) on ring topologies, and they need a high-level survivability function on those rings 💖. In real transport deployments, MPLS-TP networks are often built as rings, so we need a mechanism that's efficient and optimized. The goal is simple operation and fast recovery, sub 50 ms 🏃♀️⚡.
This document specifies an MPLS-TP Shared-Ring Protection mechanism. It meets the criteria for ring protection and the ring protection requirements from Section 2.5.6.1 of [RFC5654] ✨.
The basic concept and architecture of MPLS-TP Shared-Ring Protection are laid out here. This doc covers solutions for point-to-point transport paths. The basic concept might also work for point-to-multipoint transport paths, but the solution for point-to-multipoint is out of scope for this document 🙈.
1.1. Requirements Language 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 🍓.
2. Terminology and Notation 📚
Let's get the vocab down first 🧚.
Ring node: every node in the ring topology is a ring node, and they MUST actively participate in the ring protection. No lurking allowed 👑.
Ring tunnel: a ring tunnel gives a server layer for the Label Switched Paths (LSPs) that traverse the ring. The notation is R<d><p><X>, where <d> is c (clockwise) or a (anticlockwise), <p> is W (working) or P (protecting), and <X> is the node name 🦋.
Ring map: every ring node has a ring map. It holds the ring topology info: the nodes in the ring, how the ring nodes are adjacent to each other, and the status of the links between ring nodes, which is either Intact or Severed. Every ring node uses the ring map to decide how the ring tunnels switch over 🗺️💜.
Notation: this is how we describe the label stack contents:
- The label stack is enclosed in square brackets ("[]").
- Each level in the stack is separated by the '|' character. It should be noted that the label stack may contain additional layers. However, we only present the layers that relate to the protection mechanism 🌸.
- If Node X assigns the label, the Node Name goes in parentheses ("()") 🎀.
3. MPLS-TP Ring Protection Criteria and Requirements 🎯
The generic MPLS-TP protection requirements live in [RFC5654], and the ring-specific ones are in Section 2.5.6.1 of [RFC5654]. This section shows how the ring protection criteria get met. It's giving checklist energy 💖.
a. The number of Operations, Administration, and Maintenance (OAM) entities needed to trigger protection: each ring node needs just one instance of the RPS protocol per ring. The OAM for the links to the adjacent ring nodes has to go to this one instance so it can trigger protection. Details are in Section 5.2 🔁.
b. The number of elements of recovery in the ring: each ring node needs just one instance of the RPS protocol, and that count doesn't depend on how many LSPs get protected. Details are in Section 5.2 ✨.
c. The required number of labels required for the protection paths: the RPS protocol uses ring tunnels, and each tunnel has its own set of labels. The number of ring tunnel labels depends on the number of ring nodes, not on how many LSPs are protected. Details are in Section 4.1.2 🧚.
d. The amount of control and management-plane transactions: each ring node needs just one instance of the RPS protocol per ring. So only one maintenance operation is needed per ring node. Details are in Section 5.2 💅.
e. Minimize the signaling and routing information exchange during protection: info exchange during a protection switch rides on the in-band RPS and OAM messages. No control-plane interactions are required. Details are in Section 5.2 🫶.
4. Shared-Ring Protection Architecture 🔥
4.1. Ring Tunnel 🎀
okay so this bit introduces a brand new logical layer of the ring for shared-ring protection in MPLS-TP networks 🦋 Figure 1 shows it. The new layer is made of ring tunnels, and they act as a server layer for the LSPs crossing the ring. Once a ring tunnel is set up, all the forwarding and protection switching happens at the ring tunnel level. A port can carry multiple ring tunnels, and one ring tunnel can carry multiple LSPs. it's giving layers 💅
+-------------
+-------------|
+-------------| |
===Service1===| | |
===Service2===| LSP1 | |
+-------------| |
|Ring-Tunnel1 |
+-------------| |
===Service3===| | |
===Service4===| LSP2 | |
+-------------| |
+-------------| Physical
+-------------|
+-------------| | Port
===Service5===| | |
===Service6===| LSP3 | |
+-------------| |
|Ring-Tunnel2 |
+-------------| |
===Service7===| | |
===Service8===| LSP4 | |
+-------------| |
+-------------|
+-------------Figure 1: The Logical Layers of the Ring
The label stack used in the MPLS-TP Shared-Ring Protection mechanism is [Ring Tunnel Label|LSP Label|Service Label](Payload), as Figure 2 shows 🌸
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ring Tunnel Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: Label Stack Used in MPLS-TP Shared-Ring Protection
4.1.1. Establishment of the Ring Tunnel ✨
ring tunnels get set up based on the egress nodes 🧚 The egress node is just the spot where traffic leaves the ring. LSPs that share the same egress node and travel the ring in the same direction (clockwise or anticlockwise) share the same ring tunnels. So basically, every LSP going the same way and exiting at the same node shares one working ring tunnel and one protection ring tunnel. For each egress node, four ring tunnels get made:
- one clockwise working ring tunnel, which is protected by the anticlockwise protection ring tunnel
- one anticlockwise protection ring tunnel
- one anticlockwise working ring tunnel, which is protected by the clockwise protection ring tunnel
- one clockwise protection ring tunnel
The structure of the protection tunnels depends on which protection mechanism gets picked. More on that in the later sections 🫶
In Figure 3, LSP1, LSP2 and LSP3 enter the ring at Node E, Node A and Node B respectively, and they all leave at Node D 💖 To protect them, we build a clockwise working ring tunnel RcW_D going E->F->A->B->C->D, plus its anticlockwise protection buddy RaP_D going D->C->B->A->F->E->D. We also build an anticlockwise working ring tunnel RaW_D going C->B->A->F->E->D, with its clockwise protection ring tunnel RcP_D going D->E->F->A->B->C->D. Figure 3 only draws RcW_D and RaP_D to keep things simple. A similar provisioning should be applied for any other node on the ring. So, when each node acts as an egress node, these are the ring tunnels it gets:
- To Node A:
RcW_A,RaW_A,RcP_A,RaP_A - To Node B:
RcW_B,RaW_B,RcP_B,RaP_B - To Node C:
RcW_C,RaW_C,RcP_C,RaP_C - To Node D:
RcW_D,RaW_D,RcP_D,RaP_D - To Node E:
RcW_E,RaW_E,RcP_E,RaP_E - To Node F:
RcW_F,RaW_F,RcP_F,RaP_F
+---+#############+---+
| F |-------------| A | +-- LSP2
+---+*************+---+
#/* *\#
#/* *\#
#/* *\#
+---+ +---+
LSP1 --+ | E | | B |+-- LSP3
+---+ +---+
#\ */#
#\ */#
#\ */#
+---+*************+---+
LSP1 +--| D |-------------| C |
LSP2 +---+#############+---+
LSP3
----- Physical Links
***** RcW_D
##### RaP_D
Figure 3: Ring Tunnels in MSRPThanks to these working and protection ring tunnels, LSPs entering from any node can reach any egress node on the ring, and they stay protected from ring failures. so protected 🛡️✨
4.1.2. Label Assignment and Distribution 🌈
The ring tunnel labels are downstream-assigned labels, as defined in [RFC3031]. Each hop of a ring tunnel can get its labels in one of three ways: configured statically, provisioned by a controller, or distributed dynamically through a control protocol. For an LSP that rides a ring tunnel, the ingress ring node and the egress ring node count as adjacent at the LSP layer, so the LSP label has to be allocated at those two ring nodes. The control plane for label distribution is outside the scope of this document 💜
4.1.3. Forwarding Operation 🦋
When an MPLS-TP transport path (an LSP) enters the ring, the ingress node pushes the working ring tunnel label used to reach the specific egress node, then sends the traffic on to the next hop. Transit nodes on the working ring tunnel swap the ring tunnel labels and forward the packets along. When a packet reaches the egress node, that node pops the ring tunnel label and forwards based on the inner LSP label and service label. Figure 4 shows the label operations in the MPLS-TP Shared-Ring Protection mechanism. Let's say LSP1 enters the ring at Node A and exits at Node D, and these label operations happen 👑
- Ingress node: Packets of LSP1 arrive at Node A with the label stack
[LSP1]and are supposed to go in the clockwise direction of the ring. The label of the clockwise working ring tunnelRcW_Dgets pushed at Node A, so the label stack on the forwarded packet becomes[RcW_D(B)|LSP1]. - Transit nodes: Nodes B and C forward the packets by swapping the working ring tunnel labels. For example,
[RcW_D(B)|LSP1]gets swapped to[RcW_D(C)|LSP1]at Node B. - Egress node: When the packet reaches Node D (the egress node) with the label stack
[RcW_D(D)|LSP1], Node D popsRcW_D(D)and then deals with the inner labels of LSP1.
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#[RaP_D(A)]
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ */#
[RaP_D(D)]#\ [RxW_D(C)]*/#[RaP_D(B)]
#\ */#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
----- Physical Links
***** RcW_D
##### RaP_D
Figure 4: Label Operation of MSRP4.2. Failure Detection 🚨
The MPLS-TP section-layer OAM keeps an eye on connectivity between each pair of adjacent nodes on the ring, using the mechanisms defined in [RFC6371]. When OAM spots a failure on the ring, protection switching gets triggered 👀
Two ports of a link form a Maintenance Entity Group (MEG), and a MEG End Point (MEP) function lives in each ring port. Continuity Check (CC) OAM packets get swapped periodically between each pair of MEPs to check the link health. Three consecutive lost CC packets MUST be interpreted as a link failure. no cap, that's a hard rule 😭
A node failure counts as the failure of the two links attached to that node. The two nodes next to the failed node are the ones who notice the failure on the links connected to it 🥹
4.3. Ring Protection 💅
okay bestie, time for the juicy part: ring protection 🫶 this section gets into the nitty gritty of each mechanism. I'm using the clockwise working ring tunnel and its anticlockwise protection ring tunnel as the main example, but it works the exact same way for anticlockwise working and clockwise protection 🔄
In a ring network, every working ring tunnel is paired with a protection ring tunnel going the opposite direction 🦋 Every node MUST obtain the ring topology, either by configuration or through a topology discovery mechanism 🗺️ The ring topology plus the connectivity (Intact or Severed) between each pair of adjacent ring nodes is what we call the ring map ✨ Each ring node keeps the ring map and uses it to do ring protection switching 💖
Take the topology in Figure 4 as an example 👀 LSP1 gets on the ring at Node A and gets off at Node D. In normal state, LSP1 rides the clockwise working ring tunnel (RcW_D) along the path A->B->C->D 🚂 The label operation is:
[LSP1](Payload) -> [RCW_D(B)|LSP1](NodeA) -> [RCW_D(C)|LSP1](NodeB)
-> [RCW_D(D)| LSP1](NodeC) -> [LSP1](Payload).Then at Node D, the packet gets forwarded based on LSP1's label stack 🎀
There are three typical ring protection mechanisms covered here: wrapping, short-wrapping, and steering 🌈 All nodes on the same ring MUST use the same protection mechanism, no mixing and matching 🙅♀️ If the RPS protocol on any node gets an RPS message with a protection-switching mode that isn't provisioned on that node, it reports a failure of protocol and the protection mechanism doesn't get activated 💀
Wrapping ring protection: the node that detects a failure or accepts a switch request flips the impacted traffic to the opposite direction (away from the failure) 🔁 So the switching node upstream of the failure moves the impacted traffic onto the protection ring tunnel, it travels around the ring on that protection tunnel to the switching node downstream of the failure, and there it gets switched back onto the working ring tunnel to reach the egress node 🏁
Short-wrapping ring protection is an optimisation of wrapping ✨ The impacted traffic only gets switched once, onto the protection ring tunnel at the switching node upstream of the failure 🌸 At the egress node, the traffic leaves the ring straight from the protection ring tunnel. This cuts down the traffic detour that wrapping causes 🛤️
Steering ring protection means the node that detects a failure sends a request along the ring to the other node adjacent to the failure, and every node on the ring processes that info 📣 For the impacted traffic, the ingress node (the one adding traffic to the ring) switches it from working to the protection ring tunnel, and the egress node drops the traffic it receives from the protection ring tunnel 🗑️
The following sections dig into each of these mechanisms in detail 🔍
4.3.1. Wrapping 🌯
With wrapping, the protection ring tunnel is a closed ring identified by the egress node 💍 In Figure 4, RaP_D is the anticlockwise protection ring tunnel for the clockwise working ring tunnel RcW_D 🎯 As the next sections spell out, this closed-ring protection tunnel can protect against both link failures and node failures 🛡️ Wrapping can also be applied to protect Point-to-Multipoint (P2MP) LSPs on the ring, but the details of that are outside the scope of this document 🤷
4.3.1.1. Wrapping for Link Failure 💥
Say the link between Nodes B and C fails 💔 If it's a bidirectional failure, both Nodes B and C can detect it via the OAM mechanism. If it's a unidirectional failure, one of the two nodes is the one that detects it via the OAM mechanism. Either way, the node on the other side of the detected failure is figured out from the ring map and informed using the RPS protocol, which is specified in Section 5 📨 Then Node B switches RcW_D over to the anticlockwise protection ring tunnel (RaP_D), and Node C switches RaP_D back to RcW_D 🔄 The payload entering at Node A and leaving at Node D follows the path A->B->A->F->E->D->C->D 🗺️ The label operation is:
[LSP1](Payload) -> [RcW_D(B)|LSP1](Node A) -> [RaP_D(A)|LSP1](Node B)
-> [RaP_D(F)|LSP1](Node A) -> [RaP_D(E)|LSP1] (Node F) ->
[RaP_D(D)|LSP1] (Node E) -> [RaP_D(C)|LSP1] (Node D) ->
[RcW_D(D)|LSP1](Node C) -> [LSP1](Payload). +---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ *x#
[RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B)
#\ *x#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
----- Physical Links xxxxx Failure Links
***** RcW_D ##### RaP_DFigure 5: Wrapping for Link Failure 🦋
4.3.1.2. Wrapping for Node Failure 😱
As shown in Figure 6, when Node B fails, Node A detects the failure between A and B and switches RcW_D to the anticlockwise protection ring tunnel (RaP_D) 💫 Node C detects the failure between C and B and switches RaP_D back to RcW_D. The node on the other side of the failed node gets figured out from the ring map and informed using the RPS protocol specified in Section 5 📬
The payload entering at Node A and exiting at Node D follows the path A->F->E->D->C->D 🛣️ The label operation is:
[LSP1](Payload)-> [RaP_D(F)|LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) ->
[RaP_D(D)|LSP1](NodeE) -> [RaP_D(C)|LSP1] (NodeD) -> [RcW_D(D)|LSP1]
(NodeC) -> [LSP1](Payload).In one special case where Node D fails, all the ring tunnels with Node D as the egress become unusable 💀 The ingress node updates its ring map according to the received RPS messages and works out that the egress node isn't reachable. So it sends traffic to neither the working nor the protection tunnel 🙅 However, before the failure location info reaches all the ring nodes, wrapping can cause a temporary traffic loop 🌀 Node C detects the failure and switches traffic from RcW_D to RaP_D, while Node E also detects it and switches traffic from RaP_D back to RcW_D. A possible mechanism to mitigate the temporary loop problem is: the TTL of the ring tunnel label is set to 2*N by the ingress ring node of the traffic, where N is the number of nodes on the ring 🧮
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ xxxxx
| E | x B x
+---+ xxxxx
#\ */#
[RaP_D(D)]#\ [RcW_D(C)]*/#RaP_D(B)
#\ */#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+#####[RaP_D(C)]####+---+
----- Physical Links xxxxx Failure Nodes
***** RcW_D ##### RaP_DFigure 6: Wrapping for Node Failure 🌈
4.3.2. Short-Wrapping ✂️
With the wrapping protection scheme, protection switching runs at both nodes adjacent to the failure, so the traffic gets wrapped twice 🌯 This adds latency and bandwidth consumption when traffic gets switched onto the protection path 😩
With short-wrapping, protection switching only happens at the node upstream of the failure, and the packet leaves the ring on the protection ring tunnel at the egress node 🎉 This can reduce the extra latency and bandwidth consumption when traffic moves to the protection path. However, the two directions of a protected bidirectional LSP are no longer co-routed under the protection-switching conditions 👀
In traditional wrapping, the protection ring tunnel is configured as a closed ring. In short-wrapping, the protection ring tunnel is configured to end at the egress node, similar to the working ring tunnel 🎀 Short-wrapping is easy to implement in shared-ring protection because both the working and protection ring tunnels terminate on the egress nodes 🧩 Figure 7 shows the clockwise working ring tunnel and the anticlockwise protection ring tunnel with Node D as the egress node 🖼️
4.3.2.1. Short-Wrapping for Link Failure 🔀
As Figure 7 shows, in normal state LSP1 rides the clockwise working ring tunnel (RcW_D) along the path A->B->C->D 🛤️ When a link failure between Nodes B and C occurs, Node B switches the working ring tunnel RcW_D to the protection ring tunnel RaP_D in the opposite direction. The difference from wrapping shows up at the egress node's protection ring tunnel. In short-wrapping protection, Rap_D ends in Node D, and then traffic gets forwarded based on the LSP labels 🏁 So with short-wrapping, LSP1 follows the path A->B->A->F->E->D when a link failure between Node B and Node C happens 🌟 The protection switch at Node D is based on the information from its ring map and the information received via the RPS protocol 🧠
+---+#####[RaP_D(F)]######+---+
| F |---------------------| A | +-- LSP1
+---+*****[RcW_D(A)]******+---+
#/* *\#
[RaP_D(E)]#/*[RcW_D(F)] [RcW_D(B)]*\#RaP_D(A)
#/* *\#
+---+ +---+
| E | | B |
+---+ +---+
#\ *x#
[RaP_D(D)]#\ [RcW_D(C)]*x#RaP_D(B)
#\ *x#
+---+*****[RcW_D(D)]****+---+
LSP1 +-- | D |-------------------| C |
+---+ +---+
----- Physical Links xxxxx Failure Links
***** RcW_D ##### RaP_DFigure 7: Short-Wrapping for Link Failure 💜
4.3.2.2. Short-Wrapping for Node Failure ✨
okay so this one is the egress node failure case 💀 the non-egress version is basically the same vibe as the link failure we just covered, so the real drama is when the node that LSP1 is supposed to leave the ring on goes down 😭
As shown in Figure 8, LSP1 enters the ring on Node A and leaves the ring on Node D. In normal state, LSP1 rides the clockwise working ring tunnel (RcW_D) through the path A->B->C->D 🎀. When Node D fails, nothing can protect LSP1 using any ring tunnel that has Node D as its egress node. So the ingress node updates its ring map from the RPS messages it gets, figures out that the egress node is unreachable, and just doesn't send traffic onto either the working or the protection tunnel 🙈.
BUT here's the tea: before the failure location has spread to every ring node through RPS, Node C switches all the traffic on the working ring tunnel RcW_D over to the protection ring tunnel RaP_D, going the opposite direction, based on what's in its ring map 🔥. Then when the traffic reaches Node E, which also noticed Node D is down, RaP_D can't get anything to Node D. With short-wrapping, protection switching only happens once, from the working ring tunnel to the protection ring tunnel. So Node E MUST NOT switch the traffic already on the protection ring tunnel back onto the working ring tunnel in the opposite direction 🙅♀️. Instead, Node E just discards the traffic it receives on RaP_D locally. This is what stops a temporary traffic loop when the failure is on the egress node of the ring tunnel 🌀. It also shows off one of the perks of having separate working and protection ring tunnels in each ring direction 👑.
+---+#####[RaP_D(F)]######+---+
| F | --------------------- | A | +-- LSP1 |
+---+[RcW_D(A)]*+---+ #/* # [RaP_D(E)]#/[RcW_D(F)] [RcW_D(B)]#RaP_D(A) #/ *# +---+ +---+
| E | B |
+---+ +---+ #\ /# [RaP_D(D)]#\ [RcW_D(C)]/#RaP_D(B) #\ /# xxxxx[RcW_D(D)]+---+ LSP1 +-- x D x-------------------| C | xxxxx +---+
----- Physical Links xxxxx Failure Nodes * RcW_D ##### RaP_D
Figure 8: Short-Wrapping for Egress Node Failure
4.3.3. Steering 🦋
okay so steering is the one where the ingress node (the one that adds traffic to the ring) does the switching from working to protection ring tunnel, and then at the egress node, traffic leaves the ring off the protection ring tunnel 💖.
When something breaks in the ring, whichever node spots it with an OAM mechanism sends the failure info the opposite way from the failure, hop by hop around the ring, using an RPS request message plus the ring-map info 📨. When a ring node gets an RPS message that flags a failure, it can work out where the fault is by using the topology info in the ring map and updating that ring map to match ✨. Then it decides whether the LSPs entering the ring locally need to switch over or not 🤔. For the ones that do, it moves them from their working ring tunnels to the matching protection ring tunnels 🫶.
4.3.3.1. Steering for Link Failure 💅
Ring Map of F +--LSP1 +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]### +---/ +-+-+-+-+-+-+-+
| F | A | B | C | D | E | F | F | ---------------- | A | A | B | C | D | E | F | A |
+-+-+-+-+-+-+-+ +---+ [RcW_D(A)] +---+ +-+-+-+-+-+-+-+
| I | I | I | S | I | I | #/* *# | I | I | S | I | I | I |
+-+-+-+-+-+-+ #/* # +-+-+-+-+-+-+ [RaP_D(E)] #/ [RcW_D(B)] # [RaP_D(A)] #/ [RcW_D(F)] # +-+-+-+-+-+-+-+ #/ *#
| E | F | A | B | C | D | E | +---+ +---+ +-- LSP2 |
+-+-+-+-+-+-+-+ | E | | B | +-+-+-+-+-+-+-+
| I | I | I | I | S | I | +---+ +---+ | B | C | D | E | F | A | B |
+-+-+-+-+-+-+ #* /# +-+-+-+-+-+-+-+ #* [RcW_D(E)] [RcW_D(C)] */# |I|S|I|I|I|I| [RaP_D(D)] #* */# +-+-+-+-+-+-+ #* */# [RaP_D(B)] +-+-+-+-+-+-+-+ +---+ [RcW_D(D)] +---+ +-+-+-+-+-+-+-+
| D | E | F | A | B | C | D | +-- | D | xxxxxxxxxxxxxxxxx | C | C | D | E | F | A | B | C |
+-+-+-+-+-+-+-+ LSP1 +---+ [RaP_D(C)] +---+ +-+-+-+-+-+-+-+
| I | I | I | I | I | S | LSP2 | S | I | I | I | I | I |
+-+-+-+-+-+-+ +-+-+-+-+-+-+
----- Physical Links * RcW_D ##### RaP_D I: Intact S: Severed
Figure 9: Steering Operation and Protection Switching When Link C-D Fails
okay so in Figure 9, LSP1 enters the ring at Node A and LSP2 enters at Node B, and they both have Node D as their destination 🎯.
In normal state, LSP1 rides the clockwise working ring tunnel (RcW_D) through A->B->C->D, and the label operation is: [LSP1](Payload) -> [RcW_D(B)|LSP1](NodeA) -> [RcW_D(C)| LSP1](NodeB) -> [RcW_D(D)|LSP1](NodeC) -> [LSP1](Payload)
LSP2 rides the clockwise working ring tunnel (RcW_D) through B->C->D, and its label operation is: [LSP2](Payload) -> [RcW_D(C)|LSP2](NodeB) -> [RcW_D(D)|LSP2](NodeC) -> [LSP2](Payload)
If the link between Nodes C and D fails, then according to the fault detection and distribution mechanisms, Node D finds out there's a failure on the C-D link 😱. It updates its ring topology's link state so C-D goes from normal to fault. In the direction opposite the failure, Node D sends a state report message to Node E, telling E about the fault between C and D, and E updates its ring topology's link state to match, changing C-D from normal to fault 💌. That's how the state report gets sent hop by hop in the clockwise direction. Node C does the same thing as Node D, but sends its failure info the anticlockwise way 🔄.
When Node A gets the failure report and updates the link state in its ring map, it knows the clockwise working ring tunnel to Node D (RcW_D) has a fault. LSP1 enters the ring locally and rides that tunnel, so Node A decides to switch LSP1 onto the anticlockwise protection ring tunnel to Node D (RaP_D) 🏃♀️. After the switch, LSP1 takes the path A->F->E->D, with this label operation: [LSP1](Payload) -> [RaP_D(F)| LSP1](NodeA) -> [RaP_D(E)|LSP1](NodeF) -> [RaP_D(D)|LSP1](NodeE) -> [LSP1](Payload)
Same procedure for LSP2 🫶. When Node B updates the link state in its ring topology and finds that the working ring tunnel RcW_D has failed, it switches LSP2 onto the anticlockwise protection tunnel RaP_D. After that, LSP2 goes through B->A->F->E->D, with this label operation: [LSP2](Payload) -> [RaP_D(A)|LSP2](NodeB) -> [RaP_D(F)|LSP2](NodeA) -> [RaP_D(E)|LSP2](NodeF) -> [RaP_D(D)|LSP2](NodeE) -> [LSP2](Payload)
Now let's say the link between Nodes A and B breaks, as shown in Figure 10 💔. Kind of like the last case, Node B detects a fault on the A-B link and updates its ring map, changing the A-B link state from normal to fault. The state report gets sent hop by hop in the clockwise direction, telling every node there's a fault between A and B, and every node updates its ring topology's link state 📡. So Node A notices a fault on the working ring tunnel to Node D and switches LSP1 to the protection ring tunnel. Meanwhile Node B figures out the working ring tunnel for LSP2 is still fine, so it does NOT do the switchover 🙌.
/+-- LSP1 +-+-+-+-+-+-+-+ +---+ ###[RaP_D(F)]#### +---/ +-+-+-+-+-+-+-+
| F | A | B | C | D | E | F | F | ----------------- | A | A | B | C | D | E | F | A |
+-+-+-+-+-+-+-+ +---+ *[RcW_D(A)]** +---+ +-+-+-+-+-+-+-+
| I | S | I | I | I | I | #/* x | S | I | I | I | I | I |
+-+-+-+-+-+-+ #/* x +-+-+-+-+-+-+ [RaP_D(E)] #/[RcW_D(F)] [RcW_D(B)]x [RaP_D(A)] #/ x /+-- LSP2 +-+-+-+-+-+-+-+ +---+ +---/ +-+-+-+-+-+-+-+
| E | F | A | B | C | D | E | E | B | B | C | D | E | F | A | B |
+-+-+-+-+-+-+-+ +---+ +---+ +-+-+-+-+-+-+-+
| I | I | S | I | I | I | #* */# | I | I | I | I | I | S |
+-+-+-+-+-+-+ #*[RcW_D(E)] [RcW_D(C)] /# +-+-+-+-+-+-+ [RaP_D(D)] #* */# [RaP_D(B)] +-+-+-+-+-+-+-+ #* */# +-+-+-+-+-+-+-+
| D | E | F | A | B | C | D | +---+ [RcW_D(D)] +---+ | C | D | E | F | A | B | C |
+-+-+-+-+-+-+-+ +-- | D | ---------------- | C | +-+-+-+-+-+-+-+
| I | I | I | S | I | I | LSP1 +---+ ###[RaP_D(C)]### +---+ | I | I | I | I | S | I |
+-+-+-+-+-+-+ LSP2 +-+-+-+-+-+-+
----- Physical Links * RcW_D ##### RaP_D
Figure 10: Steering Operation and Protection Switching When Link A-B Fails
4.3.3.2. Steering for Node Failure 🌸
For a node failure on a non-egress node, steering protection switching is similar to the link failure case we just did 💖.
If the failure happens at the egress node of the LSP, the ingress node updates its ring map from the received RPS messages. It also works out that the egress node is unreachable after the failure, so it doesn't send traffic onto either the working or the protection tunnel, and that's how a traffic loop gets avoided 🔁✨.
4.4. Interconnected Ring Protection 👑
4.4.1. Interconnected Ring Topology ✨
okay so interconnected ring topology is literally everywhere in MPLS-TP networks 🌸 For a given ring, the interconnection node acts as the egress node for that ring. That means every LSP that uses it as the exit from one ring into another will use the same group of ring tunnels inside that ring. This doc walks through two typical versions 💖
- Single-node interconnected rings
In single-node interconnected rings, the two rings connect through just one node. The interconnection node is literally a single point of failure, so this topology should be avoided in real transport networks 💀
Figure 11 shows this layout. Node C is the interconnection node between Ring1 and Ring2.
+---+ +---+ +---+ +---+
| A |------| B |----- -----| G |------| H |
+---+ +---+ \ / +---+ +---+
| \ / |
| \ +---+ / |
| Ring1 | C | Ring2 |
| / +---+ \ |
| / \ |
+---+ +---+ / \ +---+ +---+
| F |------| E |----- -----| J |------| I |
+---+ +---+ +---+ +---+Figure 11: Single-Node Interconnected Rings
- Dual-node interconnected rings
In dual-node interconnected rings, the two rings connect through two nodes. Both interconnection nodes belong to both rings, and this setup can recover from one interconnection node failure 🦋
Figure 12 shows this layout. Nodes C and D are the interconnection nodes between Ring1 and Ring2.
+---+ +---+ +---+ +---+ +---+
| A |------| B |------| C |------| G |------| H |
+---+ +---+ +---+ +---+ +---+
| | |
| | |
| Ring1 | Ring2 |
| | |
| | |
+---+ +---+ +---+ +---+ +---+
| F |------| E |------| D |------| J |------| I |
+---+ +---+ +---+ +---+ +---+Figure 12: Dual-Node Interconnected Rings
4.4.2. Interconnected Ring Protection Mechanisms 🛡️
okay bestie, interconnected rings can be treated as two independent rings 🫶 The RPS protocol runs on each ring on its own. A failure in one ring only triggers protection switching in that ring and doesn't affect the other one, unless the failure is on the interconnection node. So protection switching on each ring works just like the mechanisms in Section 4.3 ✨
The service LSPs that go through the interconnected rings use the ring tunnels in each ring. Inside a given ring, the tunnel gets picked with the normal ring-selection procedures. The traversing LSPs get stitched together on the interconnection node. There, the ring tunnel label of the source ring is popped, then the LSP label is swapped, and after that the ring tunnel label of the destination ring is pushed 🎀
In the dual-node interconnected ring scenario, the two interconnection nodes can be managed as one virtual node group 👑 On top of the ring tunnels to each physical ring node, each ring SHOULD assign the working and protection ring tunnels to the virtual interconnection node group. Both nodes in that group also get the same LSP label for each traversed LSP. This way, any interconnection node in the virtual group can terminate the working or protection ring tunnels aimed at the group and stitch the service LSP from the source ring tunnel to the destination ring tunnel 🧚
When a service LSP goes through the interconnected rings, the direction of the working ring tunnels on both rings SHOULD be the same. In dual-node interconnected rings, this means that in normal state the traffic passes through only one of the two interconnection nodes and never crosses the link between them. Traffic only gets switched to the protection path if the interconnection node on the working path fails 😭 For example, if the service LSP uses the clockwise working ring tunnel on Ring1, then when it leaves Ring1 and enters Ring2, the working ring tunnel on Ring2 should also follow the clockwise direction 🌈
4.4.3. Ring Tunnels in Interconnected Rings 🍓
The same ring tunnels described in Section 4.1 get used in each ring of the interconnected rings. On top of that, ring tunnels to the virtual interconnection node group get set up on each ring, specifically:
- one clockwise working ring tunnel to the virtual interconnection node group
- one anticlockwise protection ring tunnel to the virtual interconnection node group
- one anticlockwise working ring tunnel to the virtual interconnection node group
- one clockwise protection ring tunnel to the virtual interconnection node group
These ring tunnels to the virtual group are shared by all LSPs that need to be forwarded to other rings. They can terminate at any node in the virtual interconnection node group 💅
For example, all the ring tunnels on Ring1 in Figure 13 are provisioned like this:
- To Node A: R1cW_A, R1aW_A, R1cP_A, R1aP_A
- To Node B: R1cW_B, R1aW_B, R1cP_B, R1aP_B
- To Node C: R1cW_C, R1aW_C, R1cP_C, R1aP_C
- To Node D: R1cW_D, R1aW_D, R1cP_D, R1aP_D
- To Node E: R1cW_E, R1aW_E, R1cP_E, R1aP_E
- To Node F: R1cW_F, R1aW_F, R1cP_F, R1aP_F
- To the virtual interconnection node group (including Nodes F and A): R1cW_F&A, R1aW_F&A, R1cP_F&A, R1aP_F&A
All the ring tunnels on Ring2 in Figure 13 are provisioned like this:
- To Node A: R2cW_A, R2aW_A, R2cP_A, R2aP_A
- To Node F: R2cW_F, R2aW_F, R2cP_F, R2aP_F
- To Node G: R2cW_G, R2aW_G, R2cP_G, R2aP_G
- To Node H: R2cW_H, R2aW_H, R2cP_H, R2aP_H
- To Node I: R2cW_I, R2aW_I, R2cP_I, R2aP_I
- To Node J: R2cW_J, R2aW_J, R2cP_J, R2aP_J
- To the virtual interconnection node group (including Nodes F and A): R2cW_F&A, R2aW_F&A, R2cP_F&A, R2aP_F&A
+---+ccccccccccccc+---+
| H |-------------| I |--->LSP1
+---+ +---+
c/a a\
c/a a\
c/a a\
+---+ +---+
| G | Ring2 | J |
+---+ +---+
c\a a/c
c\a a/c
c\a aaaaaaaaaaaaa a/c
+---+ccccccccccccc+---+
| F |-------------| A |
+---+ccccccccccccc+---+
c/aaaaaaaaaaaaaaaaaaa a\
c/ a\
c/ a\
+---+ +---+
| E | Ring1 | B |
+---+ +---+
c\a a/c
c\a a/c
c\a a/c
+---+aaaaaaaaaaaaa+---+
LSP1--->| D |-------------| C |
+---+ccccccccccccc+---+
Ring1:
ccccccccccc R1cW_F&A
aaaaaaaaaaa R1aP_F&A
Ring2:
ccccccccccc R2cW_I
aaaaaaaaaaa R2aP_IFigure 13: Ring Tunnels for the Interconnected Rings
4.4.4. Interconnected Ring-Switching Procedure 🌸
As Figure 13 shows, take the service LSP1 that enters Ring1 at Node D, leaves Ring1 at Node F, re-enters Ring2 at Node F, and leaves Ring2 at Node I. The short-wrapping protection scheme works like this 💖
In normal state, LSP1 follows R1cW_F&A in Ring1 and R2cW_I in Ring2. At the interconnection Node F, the label for the working ring tunnel R1cW_F&A in Ring1 gets popped, the LSP label gets swapped, and the label for the working ring tunnel R2cW_I in Ring2 gets pushed based on the inner LSP label lookup. The working path for service LSP1 is: LSP1->R1cW_F&A(D->E->F)->R2cW_I(F->G->H->I)->LSP1 ✨
In case of link failure, for example when a failure happens on the link between Nodes F and E, Node E will detect the failure and run protection switching as described in Section 4.3.2 😱 After switching, the path for service LSP1 changes to: LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1
In case of a non-interconnection node failure, for example when the failure happens at Node E in Ring1, Node D will detect it and run protection switching as described in Section 4.3.2 🙈 After switching, the path for service LSP1 becomes: LSP1->R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1
In case of an interconnection node failure, for example when the failure happens at the interconnection Node F, Node E in Ring1 will detect it and run protection switching as described in Section 4.3.2. Node A in Ring2 will also detect it and run protection switching as described in Section 4.3.2 👑 After switching, the path for the service traffic LSP1 is: LSP1->R1cW_F&A(D->E)->R1aP_F&A(E->D->C->B->A)->R2aP_I(A->J->I)->LSP1 iconic routing, periodt 🌈
4.4.5. Interconnected Ring Detection Mechanism 🦋
okay so picture this 🧚 In the normal state (Figure 13), the service traffic LSP1 goes D->E->F in Ring1 and then F->G->H->I in Ring2. Nodes A and F are the interconnection nodes 💜. Now say both the link between F and G and the link between F and A die 💀. The ring tunnel from Node F to Node I in Ring2 is now unreachable. BUT the other interconnection node, A, is still alive, so LSP1 can still reach Node I through Node A. Main character save 🙌
To pull this off, the interconnection nodes need to know the ring topology of each ring so they can judge whether a node is reachable 🗺️. That judgment is based on the ring map plus the fault location. The ring map can come from the Network Management System (NMS) or from topology discovery mechanisms. The fault location comes from sending the fault info around the ring 📣. The nodes that detect the failure transmit the fault info in the opposite direction, hop by hop, using the RPS protocol message. When an interconnection node receives the message that informs it of the failure, it works out where the fault is using its own topology info. Then it decides whether the LSPs entering the ring at itself can reach the destination ✨. If the destination node is reachable, the LSP leaves the source ring and enters the destination ring. If the destination node is not reachable, the LSP switches to the anticlockwise protection ring tunnel.
In Figure 13, Node F determines that the ring tunnel to Node I is unreachable 🚨. So the service LSP1, whose destination on Ring2 is Node I, MUST switch to the protection ring tunnel (R1aP_F&A). As a result, the service traffic LSP1 goes through the interconnected rings at Node A. Node A pops the ring tunnel label of Ring1, pushes the ring tunnel label of Ring2, and sends the traffic to Node I via the ring tunnel (R2aW_I) 🎀.
5. Ring Protection Coordination Protocol 👑
5.1. RPS and PSC Comparison on Ring Topology
This section compares RPS with Protection State Coordination (PSC) [RFC6378] [RFC6974] on ring topologies 💅. It helps explain why we needed a brand-new protocol for ring protection switching.
The PSC protocol [RFC6378] is built for point-to-point LSPs, where protection switching can only happen on one or both endpoints of the LSP. RPS is built for ring tunnels, which are made of multiple ring nodes, and a failure can happen on any segment of the ring. So RPS can identify and handle the different failures on the ring and coordinate the protection-switching behavior of all the nodes on it ✨. As you'll see in the following sections, this works through a "pass-through" state for the ring nodes, and the location of the protection request is identified via the node IDs in the RPS request message 🧩.
Taking a ring topology with N nodes as an example:
With the mechanism specified in [RFC6974], every ring node needs a linear protection configuration provisioned with every other node in the ring, i.e., with (N-1) other nodes. So every ring node ends up with (N-1) instances of the PSC protocol 😵. To detect faults and transport the PSC message, each instance shall have a MEP on the working path and a MEP on the protection path, respectively. That means every node on the ring needs to be configured with (N-1) * 2 MEPs 🫠.
With the mechanism defined in this document, every ring node has only a single instance of the RPS protocol 🥳. To detect faults and transport the RPS message, each node only needs a MEP on the section to its adjacent nodes, respectively. So every ring node only needs to be configured with 2 MEPs.
As the example above shows, RPS is designed for ring topologies and can achieve ring protection efficiently with minimum protection instances and OAM entities. That meets the requirements on topology-specific recovery mechanisms as specified in [RFC5654] 🏆.
5.2. RPS Protocol
The RPS protocol defined in this section is used to coordinate the protection-switching action of all the ring nodes in the same ring 💖.
The protection operation of the ring tunnels is controlled with the help of the RPS protocol. The RPS processes in each of the individual ring nodes that form the ring MUST communicate using the Generic Associated Channel (G-ACh) 📡. The RPS protocol applies to all three ring protection modes. This section takes the short-wrapping mechanism described in Section 4.3.2 as an example 🌸.
The RPS protocol is used to distribute the ring status information and RPS requests to all the ring nodes. Changes can be initiated automatically based on link status or caused by external commands 🔄.
Each node on the ring is uniquely identified by being assigned a node ID. The node ID MUST be unique on each ring. The maximum number of nodes on the ring supported by the RPS protocol is 127 🔢. The node ID SHOULD be independent of the order in which the nodes appear on the ring. The node ID is used to identify the source and destination nodes of each RPS request 🎯.
Every node obtains the ring topology either by configuration or via some topology discovery mechanism. The ring map consists of the ring topology information and the connectivity status (Intact or Severed) between adjacent ring nodes, which is determined via the OAM message exchanged between the adjacent nodes 🧠. The ring map is used by every ring node to determine the switchover behavior of the ring tunnels 💅.
As shown in Figure 14, when no protection switching is active on the ring, each node MUST send RPS requests with No Request (NR) to its two adjacent nodes periodically. The transmission interval of RPS requests is specified in Section 5.2.1 ⏱️.
+---+ A->B(NR) +---+ B->C(NR) +---+ C->D(NR)
-------| A |-------------| B |-------------| C |-------
(NR)F<-A +---+ (NR)A<-B +---+ (NR)B<-C +---+
Figure 14: RPS Communication between the Ring Nodes in
Case of No Failure in the RingAs shown in Figure 15, when a node detects a failure and determines that protection switching is required, it MUST send the appropriate RPS request in both directions to the destination node. The destination node is the other node that is adjacent to the identified failure. When a node that is not the destination node receives an RPS request and it has no higher-priority local request, it MUST transfer in the same direction the RPS request as received. In this way, the switching nodes can maintain RPS protocol communication in the ring 🔁. The RPS request MUST be terminated by the destination node of the message. If an RPS request with the node itself set as the source node is received, this message MUST be dropped and not be forwarded to the next node 🚫.
+---+ C->B(SF) +---+ B->C(SF) +---+ C->B(SF)
-------| A |-------------| B |----- X -----| C |-------
(SF)C<-B +---+ (SF)C<-B +---+ (SF)B<-C +---+
Figure 15: RPS Communication between the Ring Nodes in
Case of Failure between Nodes B and CNote that in the case of a bidirectional failure such as a cable cut, the two adjacent nodes detect the failure and send each other an RPS request in opposite directions 💥.
- In rings utilizing the wrapping protection, each node that detects the failure or receives the RPS request as the destination node MUST perform the switch from/to the working ring tunnels to/from the protection ring tunnels if it has no higher-priority active RPS request.
- In rings utilizing the short-wrapping protection, each node that detects the failure or receives the RPS request as the destination node MUST perform the switch only from the working ring tunnels to the protection ring tunnels.
- In rings utilizing the steering protection, when a ring switch is required, any node MUST perform the switches if its added/dropped traffic is affected by the failure. Determination of the affected traffic MUST be performed by examining the RPS requests (indicating the nodes adjacent to the failure or failures) and the stored ring map (indicating the relative position of the failure and the added traffic destined towards that failure).
When the failure has cleared and the Wait-to-Restore (WTR) timer has expired, the nodes that generate the RPS requests MUST drop their respective switches and MUST generate an RPS request carrying the NR code. The node receiving such an RPS request from both directions MUST drop its protection switches 🧹.
A protection switch MUST be initiated by one of the criteria specified in Section 5.3. A failure of the RPS protocol or controller MUST NOT trigger a protection switch 🛡️.
Ring switches MUST be preempted by higher-priority RPS requests. For example, consider a protection switch that is active due to a manual switch request on the given link, and another protection switch is required due to a failure on another link. Then an RPS request MUST be generated, the former protection switch MUST be dropped, and the latter protection switch established 👑.
The MPLS-TP Shared-Ring Protection mechanism supports multiple protection switches in the ring, resulting in the ring being segmented into two or more separate segments. This may happen when several RPS requests of the same priority exist in the ring due to multiple failures or external switch commands 🌈.
Proper operation of the MSRP mechanism relies on all nodes using their ring map to determine the state of the ring (nodes and links). In order to accommodate ring state knowledge, the RPS requests MUST be sent in both directions during a protection switch 🫶.
5.2.1. Transmission and Acceptance of RPS Requests
A new RPS request MUST be transmitted immediately when a change in the transmitted status occurs ⚡.
The first three RPS protocol messages carrying a new RPS request MUST be transmitted as fast as possible. For fast protection switching within 50 ms, the interval of the first three RPS protocol messages SHOULD be 3.3 ms. The successive RPS requests SHOULD be transmitted with the interval of 5 seconds. A ring node that is not the destination of the received RPS message MUST forward it to the next node along the ring immediately 🏃♀️💨
5.2.2. RPS Protocol Data Unit (PDU) Format 📦✨
Okay bestie, this is where the RPS packet gets its whole outfit 👗 Figure 16 shows what it looks like when it rides the G-ACh. The Channel Type field gets set so everyone knows it's an RPS message 💅
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 | RPS Channel Type (0x002A) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dest Node ID | Src Node ID | Request | M | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 16: G-ACh RPS Packet Format 🎀
These fields are a must-have, so the following fields MUST be provided:
Destination Node ID: 🎯 The destination node ID MUST always be set to the value of the node ID of the adjacent node. The node ID MUST be unique on each ring. Valid destination node ID values are 1-127.Source Node ID: 🙋 The source node ID MUST always be set to the ID value of the node generating the RPS request. The node ID MUST be unique on each ring. Valid source node ID values are 1-127.Protection-Switching Mode (M): 🔐 This 2-bit field tells you which protection-switching mode the sending node is using. It's how you check that all the ring nodes on the same ring are using the same protection-switching mechanism. The defined values of the M field are listed below:
+------------------+-----------------------------+
| Bits (MSB - LSB) | Protection-Switching Mode |
+------------------+-----------------------------+
| 0 0 | Reserved |
| 0 1 | Wrapping |
| 1 0 | Short-Wrapping |
| 1 1 | Steering |
+------------------+-----------------------------+Note: MSB = most significant bit LSB = least significant bit
RPS Request Code: 🚦 A code made of 8 bits, as specified below:
+------------------+-----------------------------+----------+
| Bits | Condition, State, | Priority |
| (MSB - LSB) | or External Request | |
+------------------+-----------------------------+----------+
| 0 0 0 0 1 1 1 1 | Lockout of Protection (LP) | highest |
| 0 0 0 0 1 1 0 1 | Forced Switch (FS) | |
| 0 0 0 0 1 0 1 1 | Signal Fail (SF) | |
| 0 0 0 0 0 1 1 0 | Manual Switch (MS) | |
| 0 0 0 0 0 1 0 1 | Wait-to-Restore (WTR) | |
| 0 0 0 0 0 0 1 1 | Exercise (EXER) | |
| 0 0 0 0 0 0 0 1 | Reverse Request (RR) | |
| 0 0 0 0 0 0 0 0 | No Request (NR) | lowest |
+------------------+-----------------------------+----------+5.2.3. Ring Node RPS States 🌀
Okay so every ring node is always in one of these vibes:
Idle state: A node is in the idle state when it has no RPS request and is sending and receiving an NR code to and from both directions. Quiet, chill, zero drama 😌
Switching state: A node that is not in the idle or pass-through states is in the switching state. It's the node that's actually busy handling something 🔄
Pass-through state: A node is in the pass-through state when its highest priority RPS request is one that isn't destined to it or generated by it. The pass-through is bidirectional, so it works both ways 🫶
5.2.3.1. Idle State 😴
A node in the idle state MUST generate the NR request in both directions.
A node in the idle state MUST terminate RPS requests that flow in both directions.
A node in the idle state MUST block the traffic flow on protection ring tunnels in both directions.
5.2.3.2. Switching State 🚨
A node in the switching state MUST generate an RPS request to its adjacent node with its highest RPS request code in both directions when it detects a failure or receives an external command. Alarm bells, everyone 🔔
In a bidirectional failure condition, both of the nodes adjacent to the failure detect the failure and send the RPS request in both directions, with the destination set to each other. Each node can only receive the RPS request via the long path, because the message sent via the short path gets lost due to the bidirectional failure 💀 Here, the short path refers to the shorter path on the ring between the source and destination node of the RPS request, and the long path refers to the longer path on the ring between the source and destination node of the RPS request. Upon receipt of the RPS request on the long path, the destination node of the RPS request MUST send an RPS request with its highest request code periodically along the long path to the other node adjacent to the failure.
In a unidirectional failure condition, the node that detects the failure MUST send the RPS request in both directions, with the destination node set to the other node adjacent to the failure. The destination node of the RPS request cannot detect the failure itself, but it will receive an RPS request from both the short path and the long path 🧐 The destination node MUST acknowledge the received RPS requests by replying with an RPS request with the RR code on the short path, and an RPS request with the received RPS request code on the long path. So when the node that detects the failure receives the RPS request with RR code on the short path, the RPS request received from the same node along the long path SHOULD be ignored. Main character energy of the short path, honestly 👑
A node in the switching state MUST terminate the received RPS requests in both directions and not forward them further along the ring.
The following switches, as defined in Section 5.3.1, MUST be allowed to coexist:
- LP and LP
- FS and FS
- SF and SF
- FS and SF
When multiple MS RPS requests exist at the same time, addressing different links, and there is no higher-priority request on the ring, no switch SHOULD be executed and existing switches MUST be dropped. The nodes MUST still signal an RPS request with the MS code.
Multiple EXER requests MUST be allowed to coexist in the ring. Lowkey the most chill combo ever 🧘
A node in a ring-switching state that receives the external command LP for the affected link MUST drop its switch and MUST signal NR for the locked link if there is no other RPS request on another link. The node still SHOULD signal a relevant RPS request for another link. 🔒
5.2.3.3. Pass-Through State 🦋
When a node is in a pass-through state, it MUST transfer the received RPS request unchanged in the same direction.
When a node is in a pass-through state, it MUST enable the traffic flow on protection ring tunnels in both directions. Traffic just floats right through 🌊
5.2.4. RPS State Transitions 🔁
All state transitions are triggered by an incoming RPS request change, a WTR expiration, an externally initiated command, or locally detected MPLS-TP section failure conditions. So many triggers, so much going on 🎬
RPS requests due to a locally detected failure, an externally initiated command, or a received RPS request shall preempt existing RPS requests in the prioritized order given in Section 5.2.2, unless the requests are allowed to coexist. Priority rules are literally everything 💅
5.2.4.1. Transitions between Idle and Pass-Through States 🌉
The transition from the idle state to the pass-through state MUST be triggered by a valid RPS request change, in any direction, from the NR code to any other code, as long as the new request is not destined to the node itself. Both directions then move into a pass-through state, so traffic entering the node through the protection ring tunnels gets transferred transparently through the node ✨
A node MUST revert from the pass-through state to the idle state when an RPS request with an NR code is received in both directions. Then both directions revert simultaneously from the pass-through state to the idle state. Synchronized swimming, but make it networking 🏊♀️
5.2.4.2. Transitions between Idle and Switching States 🔀
Transition of a node from the idle state to the switching state MUST be triggered by one of the following conditions:
- A valid RPS request change from the NR code to any code, received on either the long or the short path, and destined to this node
- An externally initiated command for this node
- The detection of an MPLS-TP section-layer failure at this node
Actions taken at a node in the idle state upon transition to the switching state are:
- For all protection-switch requests, except EXER and LP, the node MUST execute the switch
- For EXER and LP, the node MUST signal the appropriate request but not execute the switch
In one of the following conditions, transition from the switching state to the idle state MUST be triggered:
- On the node that triggers the protection switching, when the WTR time expires or an externally initiated command is cleared, the node MUST transit from the switching state to the idle state and signal the NR code using an RPS message in both directions.
- On the node that enters the switching state due to the received RPS request: upon reception of the NR code from both directions, the head-end node MUST drop its switch, transition to the idle state, and signal the NR code in both directions. Clean exit, no loose ends 🧹
5.2.4.3. Transitions between Switching States 🔄💖
When a node that is currently executing any protection switch receives a higher-priority RPS request (due to a locally detected failure, an externally initiated command, or a ring protection switch request destined to it) for the same link, it MUST update the priority of the switch it is executing to the priority of the received RPS request. Level up, instantly ⬆️
When a failure condition clears at a node, the node MUST enter the WTR condition and remain in it for the appropriate time-out interval, unless:
- A different RPS request with a higher priority than WTR is received
- Another failure is detected
- An externally initiated command becomes active
The node MUST send out a WTR code on both the long and short paths. ⏳
When a node that is executing a switch in response to an incoming SF RPS request (not due to a locally detected failure) receives a WTR code (unidirectional failure case), it MUST send out the RR code on the short path and the WTR on the long path. Every path has its job 🎀
5.2.4.4. Transitions between Switching and Pass-Through States 🌈
When a node that is currently executing a switch receives an RPS request for a non-adjacent link of higher priority than the switch it is executing, it MUST drop its switch immediately and enter the pass-through state. Instant glow-up 💅
The transition of a node from the pass-through state to the switching state MUST be triggered by:
- An equal priority, a higher priority, or an allowed coexisting externally initiated command
- The detection of an equal priority, a higher priority, or an allowed coexisting automatic initiated command
- The receipt of an equal, a higher priority, or an allowed coexisting RPS request destined to this node
5.3. RPS State Machine 🧠
5.3.1. Switch Initiation Criteria 🚀
5.3.1.1. Administrative Commands ✨
okay so the network operator can kick off admin commands from the Network Management System (NMS) 🖥️, and the command gets sent to the right node inside an MPLS-TP RPS message 📬.
Here's what the RPS message can carry 👇
- Lockout of Protection (LP) 🔒: this one shuts down all protection activity and stops anyone from using ring switches anywhere in the ring. If any ring switches already exist, this command makes them drop. 💀
- Forced Switch (FS) to protection 💪: this performs the ring switch of normal traffic from the working entity to the protection entity, for the link between the node where the command starts and the adjacent node it's aimed at. It happens regardless of the state of the MPLS-TP section for that link, unless a higher-priority switch request is already active.
- Manual Switch (MS) to protection 🎀: same vibe as FS. The ring switch of normal traffic from working to protection happens for the link between the starting node and the targeted adjacent node. The catch is that it only happens if the MPLS-TP section for that link isn't already satisfying an equal or higher priority switch request.
- Exercise (EXER) 🧪: this exercises ring protection switching on the addressed link without actually completing the switch. The command gets issued and the responses (RRs) get checked, but no normal traffic is affected. Practice run, no drama 🫶
Now the commands that do not travel in the RPS message 🙅♀️
- Clear 🧹: this clears the administrative command and the WTR timer at the node the command was addressed to. The node-to-node signaling after the externally initiated commands are removed is handled using the NR code.
- Lockout of Working (LW) 🚫: this stops normal traffic on the addressed link from being switched to the protection entity, by disabling the node's ability to request a switch for that link when there's a failure. If normal traffic is already switched onto the protection entity, that switch gets dropped. If no other switch requests are active on the ring, the NR code is transmitted. It has zero impact on any other link. If the node gets a switch request from the adjacent node on any side, it performs the requested switch. If the node gets a switch request addressed to the other node, it enters the pass-through state. ✨
5.3.1.2. Automatically Initiated Commands 🤖
okay these ones just happen on their own, based on MPLS-TP section-layer OAM indications and the switch requests the node receives 👀
The node can start the following switch requests automatically:
- Signal Fail (SF) 🚨: this gets issued when the MPLS-TP section-layer OAM detects a signal failure condition. Oof. 😭
- Wait-to-Restore (WTR) ⏳: this gets issued when the MPLS-TP section detects that the SF condition has cleared. It's used to hold the state during the WTR period, unless something with higher priority preempts it. The operator can configure the WTR time in 1 minute steps between 0 and 12 minutes, and the default is 5 minutes. Patience is a virtue, bestie 🧘♀️
- Reverse Request (RR) 🔁: this gets transmitted to the source node of the received RPS message, over the short path, as an acknowledgment that the switch request was received. Basically the "got it, bestie" reply 💌
5.3.2. Initial States 💜
this section breaks down the possible states of a ring node, what the working and protection ring tunnels do on that node, and which RPS request the node should generate in each state. Here's the whole lineup 👑
+-----------------------------------+----------------+
| State | Signaled RPS |
+-----------------------------------+----------------+
| A | Idle | NR |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
| B | Pass-through | N/A |
| | Working: no switch | |
| | Protection: pass-through | |
+-----+-----------------------------+----------------+
| C | Switching - LP | LP |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
| D | Idle - LW | NR |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+
| E | Switching - FS | FS |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| F | Switching - SF | SF |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| G | Switching - MS | MS |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| H | Switching - WTR | WTR |
| | Working: switched | |
| | Protection: switched | |
+-----+-----------------------------+----------------+
| I | Switching - EXER | EXER |
| | Working: no switch | |
| | Protection: no switch | |
+-----+-----------------------------+----------------+5.3.3. State Transitions When Local Request Is Applied ✨
okay bestie, this part is the big state-change cheat sheet 💅. It shows what happens when a new local request shows up, depending on which state the node is already in. Heads up: in the descriptions below, 'O' means the new local request gets rejected because of a request that's already in progress 🙅♀️.
=====================================================================
Initial state New request New state
------------- ----------- ---------
A (Idle) LP C (Switching - LP)
LW D (Idle - LW)
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS G (Switching - MS)
Clear N/A
WTR expires N/A
EXER I (Switching - EXER)
=====================================================================Starting from A (Idle) 🌸, basically everything is allowed to kick off a new state. LP, LW, FS, SF, MS, and EXER all take you somewhere new. Recover from SF, Clear, and WTR expires are N/A, so they just don't do anything here 🤷♀️.
=====================================================================
Initial state New request New state
------------- ----------- ---------
B (Pass-through) LP C (Switching - LP)
LW B (Pass-through)
FS O - if current state is due to
LP sent by another node
E (Switching - FS) - otherwise
SF O - if current state is due to
LP sent by another node
F (Switching - SF) - otherwise
Recover from SF N/A
MS O - if current state is due to
LP, SF, or FS sent by
another node
G (Switching - MS) - otherwise
Clear N/A
WTR expires N/A
EXER O
=====================================================================Now B (Pass-through) 🦋 is where it gets a little spicy 🌶️. FS and SF can get rejected, but only if the current state was caused by an LP that another node sent. MS gets rejected if the current state is due to LP, SF, or FS from another node. Otherwise, the new request goes through. EXER is always O here, and LW just leaves you in B.
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP N/A
LW O
FS O
SF O
Recover from SF N/A
MS O
Clear A (Idle) - if there is no
failure in the ring
F (Switching - SF) - if there
is a failure at this node
B (Pass-through) - if there is
a failure at another node
WTR expires N/A
EXER O
=====================================================================When you're in C (Switching - LP) 💜, almost everything new gets blocked with O. The only exception is Clear, which is the main way out. Clear sends you back to A (Idle) if the ring has no failure, to F (Switching - SF) if the failure is at this node, or to B (Pass-through) if the failure is somewhere else. LP and WTR expires are N/A, and EXER is O.
=====================================================================
Initial state New request New state
------------- ----------- ---------
D (Idle - LW) LP C (Switching - LP)
LW N/A - if on the same link
D (Idle - LW) - if on another
link
FS O - if on the same link
E (Switching - FS) - if on
another link
SF O - if on the addressed link
F (Switching - SF) - if on
another link
Recover from SF N/A
MS O - if on the same link
G (Switching - MS) - if on
another link
Clear A (Idle) - if there is no
failure on addressed link
F (Switching - SF) - if there
is a failure on this link
WTR expires N/A
EXER O
=====================================================================Next up is D (Idle - LW) 🎀. This one is all about the link. A lot of things get rejected only if they're on the same link, but if they're on another link, they're totally welcome. Clear is the fun one: it takes you to A (Idle) when the addressed link is failure-free, and to F (Switching - SF) if this link has a failure.
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP C (Switching - LP)
LW O - if on another link
D (Idle - LW) - if on the same
link
FS N/A - if on the same link
E (Switching - FS) - if on
another link
SF O - if on the addressed link
E (Switching - FS) - if on
another link
Recover from SF N/A
MS O
Clear A (Idle) - if there is no
failure in the ring
F (Switching - SF) - if there
is a failure at this node
B (Pass-through) - if there is
a failure at another node
WTR expires N/A
EXER O
=====================================================================In E (Switching - FS) 🧚, the same-link vs. other-link split shows up again for LW, FS, and SF. MS and EXER are always O. Clear works just like it does in state C, going to A, F, or B depending on where the failure is.
=====================================================================
Initial state New request New state
------------- ----------- ---------
F (Switching - SF) LP C (Switching - LP)
LW O - if on another link
D (Idle - LW) - if on the same
link
FS E (Switching - FS)
SF N/A - if on the same link
F (Switching - SF) - if on
another link
Recover from SF H (Switching - WTR)
MS O
Clear N/A
WTR expires N/A
EXER O
=====================================================================Now F (Switching - SF) 💖. Recover from SF is the big move here, since it takes you into H (Switching - WTR). FS is accepted and sends you to E, but Clear does nothing, and MS and EXER are O.
=====================================================================
Initial state New request New state
------------- ----------- ---------
G (Switching - MS) LP C (Switching - LP)
LW O - if on another link
D (Idle - LW) - if on the same
link
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS N/A - if on the same link
G (Switching - MS) - if on
another link, release the
switches but signal MS
Clear A
WTR expires N/A
EXER O
=====================================================================G (Switching - MS) 🔥 is pretty chill. Most new requests are accepted, and Clear takes you right back to A. The MS-on-another-link case is a special one: the switches get released, but MS is still signaled. EXER is O.
=====================================================================
Initial state New request New state
------------- ----------- ---------
H (Switching - WTR) LP C (Switching - LP)
LW D (Idle - W)
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS G (Switching - MS)
Clear A
WTR expires A
EXER O
=====================================================================H (Switching - WTR) 🌈 lets most requests in. Clear and WTR expires both bring you back to A, and EXER is the only thing that gets blocked.
=====================================================================
Initial state New request New state
------------- ----------- ---------
I (Switching - EXER) LP C (Switching - LP)
LW D (Idle - W)
FS E (Switching - FS)
SF F (Switching - SF)
Recover from SF N/A
MS G (Switching - MS)
Clear A
WTR expires N/A
EXER N/A - if on the same link
I (Switching - EXER)
=====================================================================Last one: I (Switching - EXER) 🧁. Most requests move you along, Clear sends you to A, and EXER only keeps you in I when it's on the same link. That's the whole table set, so you've now seen every starting state 🫶✨.
5.3.4. State Transitions When Remote Request is Applied ✨
okay so the big thing here is that a remote request's priority doesn't care which side of the ring it came in on 💅 priority is priority, no favourites 🫶 Here's the full breakdown, state by state 🎀
Starting from A (Idle) 🦋
=====================================================================
Initial state New request New state
------------- ----------- ---------
A (Idle) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR N/A
EXER I (Switching - EXER)
RR N/A
NR A (Idle)
=====================================================================Next up, B (Pass-through) 🌸 this one has the most "cannot happen" moments, so read it slowly 👀
=====================================================================
Initial state New request New state
------------- ----------- ---------
B (Pass-through) LP C (Switching - LP)
FS N/A - cannot happen when there
is an LP request in the
ring
E (Switching - FS) - otherwise
SF N/A - cannot happen when there
is an LP request in the
ring
F (Switching - SF) - otherwise
MS N/A - cannot happen when there
is an LP, FS, or SF
request in the ring
G (Switching - MS) - otherwise
WTR N/A - cannot happen when there
is an LP, FS, SF, or MS
request in the ring
EXER N/A - cannot happen when there
is an LP, FS, SF, MS, or
a WTR request in the
ring
I (Switching - EXER) -
otherwise
RR N/A
NR A (Idle) - if received from
both sides
=====================================================================Now C (Switching - LP) 🔥 LP is the boss here, so basically everything else either bounces or gets ignored 💀
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP C (Switching - LP)
FS N/A - cannot happen when there
is an LP request in the
ring
SF N/A - cannot happen when there
is an LP request in the
ring
MS N/A - cannot happen when there
is an LP request in the
ring
WTR N/A
EXER N/A - cannot happen when there
is an LP request in the
ring
RR C (Switching - LP)
NR N/A
=====================================================================D (Idle - LW) is giving Idle vibes but with a little LW twist 🧚
=====================================================================
Initial state New request New state
------------- ----------- ---------
D (Idle - LW) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR N/A
EXER I (Switching - EXER)
RR N/A
NR D (Idle - LW)
=====================================================================E (Switching - FS) 💖 FS is the one holding the spotlight here
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP C (Switching - LP)
FS E (Switching - FS)
SF E (Switching - FS)
MS N/A - cannot happen when there
is an FS request in the
ring
WTR N/A
EXER N/A - cannot happen when there
is an FS request in the
ring
RR E (Switching - FS)
NR N/A
=====================================================================F (Switching - SF) ✨ same energy as FS, just with SF stealing the show
=====================================================================
Initial state New request New state
------------- ----------- ---------
F (Switching - SF) LP C (Switching - LP)
FS F (Switching - SF)
SF F (Switching - SF)
MS N/A - cannot happen when there
is an SF request in the
ring
WTR N/A
EXER N/A - cannot happen when there
is an SF request in the
ring
RR F (Switching - SF)
NR N/A
=====================================================================G (Switching - MS) 🌈 this one has a little "release the switches but signal MS" moment, which is so specific I'm obsessed 😭
=====================================================================
Initial state New request New state
------------- ----------- ---------
G (Switching - MS) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS) - release
the switches but signal MS
WTR N/A
EXER N/A - cannot happen when there
is an MS request in the
ring
RR G (Switching - MS)
NR N/A
=====================================================================H (Switching - WTR) 🦋 WTR is waiting patiently, and new requests can still come in and take over 👑
=====================================================================
Initial state New request New state
------------- ----------- ---------
H (Switching - WTR) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR H (Switching - WTR)
EXER N/A - cannot happen when there
is a WTR request in the
ring
RR H (Switching - WTR)
NR N/A
=====================================================================And last but definitely not least, I (Switching - EXER) 🍓 the final boss table, bestie 🫶
=====================================================================
Initial state New request New state
------------- ----------- ---------
I (Switching - EXER) LP C (Switching - LP)
FS E (Switching - FS)
SF F (Switching - SF)
MS G (Switching - MS)
WTR N/A
EXER I (Switching - EXER)
RR I (Switching - EXER)
NR N/A
=====================================================================5.3.5. State Transitions When Request Addresses to Another Node is Received ✨
okay so the priority of a remote request literally doesn't care which side it shows up from 💅 it's the same energy no matter where it came in 🫶
Here's the full tea on how each state reacts when a request addressed to another node comes in:
=====================================================================
Initial state New request New state
------------- ----------- ---------
A (Idle) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR B (Pass-through)
EXER B (Pass-through)
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
B (Pass-through) LP B (Pass-through)
FS N/A - cannot happen when there
is an LP request in the
ring
B (Pass-through) - otherwise
SF N/A - cannot happen when there
is an LP request in the
ring
B (Pass-through) - otherwise
MS N/A - cannot happen when there
is an LP, FS, or SF
request in the ring
B (Pass-through) - otherwise
WTR N/A - cannot happen when there
is an LP, FS, SF, or MS
request in the ring
B (Pass-through) - otherwise
EXER N/A - cannot happen when there
is an LP, FS, SF, MS, or
a WTR request in the
ring
B (Pass-through) - otherwise
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
C (Switching - LP) LP C (Switching - LP)
FS N/A - cannot happen when there
is an LP request in the
ring
SF N/A - cannot happen when there
is an LP request in the
ring
MS N/A - cannot happen when there
is an LP request in the
ring
WTR N/A - cannot happen when there
is an LP request in the
ring
EXER N/A - cannot happen when there
is an LP request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
D (Idle - LW) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR B (Pass-through)
EXER B (Pass-through)
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
E (Switching - FS) LP B (Pass-through)
FS E (Switching - FS)
SF E (Switching - FS)
MS N/A - cannot happen when there
is an FS request in the
ring
WTR N/A - cannot happen when there
is an FS request in the
ring
EXER N/A - cannot happen when there
is an FS request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
F (Switching - SF) LP B (Pass-through)
FS F (Switching - SF)
SF F (Switching - SF)
MS N/A - cannot happen when there
is an SF request in the
ring
WTR N/A - cannot happen when there
is an SF request in the
ring
EXER N/A - cannot happen when there
is an SF request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
G (Switching - MS) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS G (Switching - MS) - release
the switches but signal MS
WTR N/A - cannot happen when there
is an MS request in the
ring
EXER N/A - cannot happen when there
is an MS request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
H (Switching - WTR) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR N/A
EXER N/A - cannot happen when there
is a WTR request in the
ring
RR N/A
NR N/A
=====================================================================
Initial state New request New state
------------- ----------- ---------
I (Switching - EXER) LP B (Pass-through)
FS B (Pass-through)
SF B (Pass-through)
MS B (Pass-through)
WTR N/A
EXER I (Switching - EXER)
RR N/A
NR N/A
=====================================================================6. IANA Considerations 🎀
IANA has the values listed in the sections below all sorted out, so you can go check them there 🌸
6.1. G-ACh Channel Type 🦋
The Channel Types for G-ACh are pulled from the PW Associated Channel Type registry, which is defined in [RFC4446] and updated by [RFC5586]. Main character energy 👑
IANA has allocated the following new G-ACh Channel Type in the "MPLS Generalized Associated Channel (G-ACh) Types (including Pseudowire Associated Channel Types)" registry:
Value | Description | Reference
-------+---------------------------------+--------------
0x002A | Ring Protection Switching (RPS) | this document
| Protocol |
-------+---------------------------------+--------------6.2. RPS Request Codes 💜
IANA has created the subregistry "MPLS RPS Request Code Registry" under the "Generic Associated Channel (G-ACh) Parameters" registry. Every code point in this registry shall be allocated according to the "Specification Required" procedure, as specified in [RFC8126]. It's giving organized 💅
The RPS request field is 8 bits, and these are the allocated values:
Value Description Reference
------- --------------------------- -------------
0 No Request (NR) this document
1 Reverse Request (RR) this document
2 Unassigned
3 Exercise (EXER) this document
4 Unassigned
5 Wait-to-Restore (WTR) this document
6 Manual Switch (MS) this document
7-10 Unassigned
11 Signal Fail (SF) this document
12 Unassigned
13 Forced Switch (FS) this document
14 Unassigned
15 Lockout of Protection (LP) this document
16-254 Unassigned
255 Reserved7. Operational Considerations ✨
Okay bestie, this part is all about the three protection modes of the RPS protocol 🎀. Operators get to pick whichever one fits their network and service needs 💅.
Wrapping mode 🌀 is a ring protection mechanism where the protected traffic reaches every node on the ring 🔁. It works for point-to-point LSPs and also for LSPs that need to get dropped at several ring nodes (the point-to-multipoint applications) 🌸. When protection is inactive, the protected traffic gets wrapped to and from the protection ring tunnel on both sides of the defective link/node 🫶. Ngl, the extra propagation delay and bandwidth eaten by that protection tunnel are considerable 😭. For bidirectional LSPs, the traffic in both directions is co-routed 💜.
Short-wrapping mode ✂️ can only be used to protect point-to-point LSPs 🦋. When protection is inactive, the traffic gets wrapped into the protection ring tunnel at the defective link/node, then leaves the ring when the tunnel reaches the egress node 🧚. Compared with wrapping mode, it cuts down on propagation latency and protection tunnel bandwidth, which is lowkey iconic ✨. The catch is that the two directions of a protected bidirectional LSP are not totally co-routed 🙈.
Steering mode 🚗 is also only for protecting point-to-point LSPs 💖. When protection is inactive, the traffic gets switched onto the protection ring tunnel at the ingress node and leaves the ring when that tunnel reaches the egress node 👑. Out of all three modes, this one has the least propagation delay and bandwidth consumption 🌈, and both directions of a protected bidirectional LSP can stay co-routed 🫶.
🚨 Heads up: only one protection mode can be provisioned in the whole ring, for all protected traffic. No mixing and matching, periodt 💅.
8. Security Considerations 🔐
Okay, this section is SERIOUS, but I'm still gonna make it fun 😤. MPLS-TP is a subset of MPLS, so it builds on a lot of MPLS's security model 🧠. For generic MPLS security issues and ways to secure traffic privacy and integrity, go check out [RFC5920] 💜.
The RPS message defined in this document is used to coordinate protection on the ring 🛞. If an attacker injects or modifies it, the ring nodes might not agree on the protection action 😱, and the improper protection-switching action could cause a temporary break for services traversing the ring 💀. So it's super important that the RPS message is used within a trusted MPLS-TP network domain, as described in [RFC6941] 🔒.
The RPS message is 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] 🌸. That means this document relies on the security mechanisms provided for the Associated Channel in those two documents 🤝.
As described in the security considerations of [RFC6378], the G-ACh is essentially connection oriented 🧵. So injecting or modifying control messages requires subverting a transit node 🕵️. That kind of subversion is generally considered hard in connection-oriented MPLS networks, and impossible to protect against at the protocol level 😤. Management-level techniques are the better fit ✅. The procedures and protocol extensions defined in this document do not affect the security model of MPLS-TP linear protection as defined in [RFC6378] 🦋.
9. References 📚
9.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. 📖 - [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001,
<https://www.rfc-editor.org/info/rfc3031>. 📖 - [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, DOI 10.17487/RFC4385, February 2006,
<https://www.rfc-editor.org/info/rfc4385>. 📖 - [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006,
<https://www.rfc-editor.org/info/rfc4446>. 📖 - [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009,
<https://www.rfc-editor.org/info/rfc5586>. 📖 - [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009,
<https://www.rfc-editor.org/info/rfc5654>. 📖 - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>. 📖
9.2. Informative References
- [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<https://www.rfc-editor.org/info/rfc5920>. 📖 - [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011,
<https://www.rfc-editor.org/info/rfc6371>. 📖 - [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS-TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, October 2011,
<https://www.rfc-editor.org/info/rfc6378>. 📖 - [RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed., and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, DOI 10.17487/RFC6941, April 2013,
<https://www.rfc-editor.org/info/rfc6941>. 📖 - [RFC6974] Weingarten, Y., Bryant, S., Ceccarelli, D., Caviglia, D., Fondelli, F., Corsi, M., Wu, B., and X. Dai, "Applicability of MPLS Transport Profile for Ring Topologies", RFC 6974, DOI 10.17487/RFC6974, July 2013,
<https://www.rfc-editor.org/info/rfc6974>. 📖 - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. 📖
Acknowledgements 🙏
Huge thanks to Gregory Mirsky, Yimin Shen, Eric Osborne, Spencer Jackson, and Eric Gray for their valuable comments and suggestions 🫶✨.
Contributors 👯♀️
These people contributed significantly to the content of this document and should be considered co-authors 💖:
- Kai Liu
- Huawei Technologies
- Email: alex.liukai@huawei.com
- Jia He
- Huawei Technologies
- Email: hejia@huawei.com
- Fang Li
- China Academy of Telecommunication Research MIIT
- China
- Email: lifang@catr.cn
- Jian Yang
- ZTE Corporation
- China
- Email: yang.jian90@zte.com.cn
- Junfang Wang
- Fiberhome Telecommunication Technologies Co., LTD.
- Email: wjf@fiberhome.com.cn
- Wen Ye
- China Mobile
- Email: yewen@chinamobile.com
- Minxue Wang
- China Mobile
- Email: wangminxue@chinamobile.com
- Sheng Liu
- China Mobile
- Email: liusheng@chinamobile.com
- Guanghui Sun
- Huawei Technologies
- Email: sunguanghui@huawei.com
Authors' Addresses 🌟
- Weiqiang Cheng
- China Mobile
- Email: chengweiqiang@chinamobile.com
- Lei Wang
- China Mobile
- Email: wangleiyj@chinamobile.com
- Han Li
- China Mobile
- Email: lihan@chinamobile.com
- Huub van Helvoort
- Hai Gaoming BV
- Email: huubatwork@gmail.com
- Jie Dong
- Huawei Technologies
- Email: jie.dong@huawei.com
📦 where this page comes from
- ietf: rfc8227 2017-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms