RFC 6974
Applicability of MPLS Transport Profile for Ring Topologies
RFC 6974: Applicability of MPLS Transport Profile for Ring Topologies 💖
okay bestie, this is Informational RFC 6974, published in July 2013 by the IETF 🌸. The authors are Y. Weingarten, S. Bryant (Cisco Systems), D. Ceccarelli, D. Caviglia, and F. Fondelli (Ericsson), M. Corsi (Altran), B. Wu (ZTE Corporation), and X. Dai. The header doesn't list an organisation for Y. Weingarten or X. Dai. The ISSN is 2070-1721. The title block doesn't list any RFCs this one obsoletes or updates, so it's a standalone doc 🫶.
Abstract ✨
okay so this doc takes the MPLS protection tools we already have, both local and end-to-end, and shows how they apply to the MPLS Transport Profile (MPLS-TP) when the network is a ring 💍. it doesn't invent any new mechanisms or protocols, zero new stuff, just applying what exists 🧚. the ring-protection requirements are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). this doc shows how most of those requirements get met by using linear protection as defined in RFC 6378 on a ring 💅.
Status of This Memo 🎀
this doc is not an Internet Standards Track spec. it's published for information only, so it's a vibe check, not a rulebook 📖.
it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🤝. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 🙈.
if you want the latest status, errata, or a place to send feedback, check http://www.rfc-editor.org/info/rfc6974 🔗.
Copyright Notice 💜
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read these carefully, because they spell out your rights and restrictions for this doc 📜. any Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🧾.
Table of Contents 🌈
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope of the Document . . . . . . . . . . . . . . . . . . 4
1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 5
2. Point-to-Point (P2P) Ring Protection . . . . . . . . . . . . . 6
2.1. Wrapping . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Steering . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. SPME for P2P Protection of a Ring Topology . . . . . . . . 10
2.3.1. Path SPME for Steering . . . . . . . . . . . . . . . . 11
2.3.2. Wrapping Link Protection with Segment-Based SPME . . . 12
2.3.3. Wrapping Node Protection . . . . . . . . . . . . . . . 13
2.3.4. Wrapping for Link and Node Protection . . . . . . . . 14
2.4. Analysis of P2P Protection . . . . . . . . . . . . . . . . 15
2.4.1. Recommendations for Protection of P2P Paths
Traversing a Ring . . . . . . . . . . . . . . . . . . 16
3. Point-to-Multipoint Protection . . . . . . . . . . . . . . . . 17
3.1. Wrapping for P2MP LSPs . . . . . . . . . . . . . . . . . . 17
3.1.1. Comparison of Wrapping and ROM-Wrapping . . . . . . . 19
3.1.2. Multiple Failures Comparison . . . . . . . . . . . . . 20
3.2. Steering for P2MP Paths . . . . . . . . . . . . . . . . . 21
3.2.1. Context Labels . . . . . . . . . . . . . . . . . . . . 21
3.2.2. Walk-Through Using Context Labels . . . . . . . . . . 23
4. Coordination Protocol . . . . . . . . . . . . . . . . . . . . 26
5. Conclusions and Recommendations . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 291. Introduction 🦋
okay so the MPLS Transport Profile (MPLS-TP) was standardised as a joint effort between the Internet Engineering Task Force (IETF) and the International Telecommunications Union Telecommunications Standardization Sector (ITU-T) 🤩. the requirements came out of that joint work, and the specs are based on them 📋.
the MPLS-TP requirement document [RFC5654] includes a requirement to support a network that may include subnetworks forming an MPLS-TP ring, as defined in that document. the thing is, the doc doesn't name any protection requirements that are specific to a ring topology 😭. it does say that protection mechanisms for ring topologies may be developed, as long as they let the network minimise:
- the number of OAM entities needed to trigger the protection
- the number of elements of recovery needed
- the number of labels required
- the number of control- and management-plane transactions during a maintenance operation
- the impact of signaling and routing information exchanged during protection, in the presence of a control plane
this doc explains how a set of basic MPLS-TP linear protection mechanisms, defined in [RFC6378], can protect the data flows that cross an MPLS-TP ring 💅. these mechanisms protect data flows against any switching trigger within a reasonable time frame, and they optimise the criteria in [RFC5654] that we just summarised 🫶. this doc doesn't define any new protocol mechanisms or procedures, so no surprises there ✨.
there's also a related topic in [RFC5654]: support for interconnected rings. that topic has a bunch of scenarios that still need further study. it'll be handled in a separate doc, based on the principles in this one 🔮.
1.1. Problem Statement 🧩
ring topologies, as defined in [RFC5654], show up in transport networks 🛞. when you design a protection mechanism for a single ring, you need to cover both of these cases:
- A point-to-point transport path that starts at a ring node, or enters an MPLS-TP-capable ring at a single ingress node, and exits the ring at a single egress node. It may also continue beyond the ring.
- The ring is used as a branching point for a point-to-multipoint transport path. So the transport path starts at, or enters the MPLS-TP-capable ring at, the ingress node, and exits through a number of egress nodes. It may also continue beyond the ring.
in either of those two situations, you also need to handle these different cases:
- One of the ring links causes a fault condition. This could be a unidirectional or a bidirectional fault, and the neighbouring nodes should detect it.
- One of the ring nodes causes a fault condition. This is always a bidirectional fault, although in rare cases of misconfiguration it could be detected as a unidirectional fault. The two neighbouring ring nodes should detect it.
- An operator command is issued to a specific ring node. It either changes the operational state of a node or a link, or explicitly triggers a protection action. An operator command changes the operational state of a node or a link, or specifically triggers a protection action, and it's issued to a specific ring node. The different operator commands are described in Section 4.13 of [RFC4427]. Examples include Manual Switch, Forced Switch, and Clear operations.
the protection domain in this doc is limited to traffic that traverses the ring 🎯. protection triggers on the transport path before the ring's ingress node, or after the egress nodes, may be protected by some other mechanism 🙌.
1.2. Scope of the Document 🌷
this doc covers the requirements in Section 2.5.6.1 of [RFC5654] about ring protection, using the linear protection defined in [RFC6378] 💖. requirement R93, about supporting interconnected rings and protecting faults in the interconnection nodes and links, is for further study 🔜.
also, requirement R105, which asks for lockout of specific nodes or spans, is only supported to the degree that the linear protection mechanism supports it 🔒.
more to come in the next part 🎀✨
1.3. Terminology and Notation 🎀
okay so the terminology in this doc is borrowed from the MPLS-TP framework documents, and you need all three of these bestie 💅
- MPLS-TP framework [RFC5921]
- MPLS-TP OAM framework [RFC6371]
- MPLS-TP survivability framework [RFC6372]
The MPLS-TP framework document [RFC5921] defines a Sub-Path Maintenance Entity (SPME) construct. It can be defined between any two Label Switching Routers (LSRs) of an MPLS-TP Label Switched Path (LSP) 🦋 The SPME can be configured as a co-routed bidirectional path, and it's there so you can manage and monitor any segment of a transport path. This concept gets used all over this doc to protect the traffic moving through an MPLS-TP ring, so pay attention to it 👑
We also talk about how the label stack gets used when protection redirects data packets. Here's the notation we use to describe the stack contents 🧚
- The label stack is enclosed in square brackets (
[]). - Each level in the stack is separated by the
|character. The label stack can have extra levels too, but we only show the ones that matter for the protection mechanism 💜 - When it applies, the S bit (which says a label is the bottom of the label stack) is shown as
+Sinside the label. If a label doesn't have+S, it may or may not be the bottom label.+Sonly shows up when it's important to illustrate that a label is definitely the last one in the stack 🌸 - The label of the LSP at the ring's ingress node is written as
LI. The label of the LSP expected at the ring's egress point is written asLE.LSEis the label expected at the exit LSR of a SPME. That can differ from the ring's egress point, like in the case described in Section 2.3 ✨ - The label
Pxi(y)in the stack is the label that LSR-x would use to transport the packet to LSR-y over the SPME whose index is i 🍓
Some examples to make it click:
- The label stack
[LI]is the stack received at the ring's ingress node. There may be more labels afterLI, like a PW label, but that doesn't matter for this protection scenario 🫶 [PB1(G) | LE]is a stack where the top label is the SPME-1 label for LSR-B to send the data packet to LSR-G. The second label is the one the egress LSR would use to keep sending the packet along the original LSP 🌈- If
LEwere the bottom label in the stack, the stack would be written as[PB1(G) | LE+S]🔥
2. Point-to-Point (P2P) Ring Protection 💖
Okay, there are two protection architecture mechanisms, "Wrapping" and "Steering," that have been used on ring topologies for a long time. They're based on Synchronous Digital Hierarchy (SDH) specifications [G.841], and people have proposed them in lots of forums for recovering a topological ring network. The next two subsections go through each one as it applies to an MPLS transport network 🦋
2.1. Wrapping 🌀
Wrapping is a local protection architecture, so it only involves the nodes that are neighbors of the detected fault 💅 When a fault shows up (a link or node failure), the neighboring node figures out that the fault would stop data from being forwarded along the data path. To keep the data moving, all the data traffic has to get "wrapped" around the ring on an alternate data path until it arrives at the node on the opposite side of the fault 😭 When that far-side node also notices a fault on the working path, it can tell that the traffic arriving on the alternate (protecting) data path is meant for the "broken" data path. So, making its own local decision, the far-side node wraps the data back onto the normal working path, all the way to the egress from the ring segment 👑
Wrapping behaves a lot like MPLS-TE Fast Reroute, which is defined in [RFC4090]. That one uses either bypass or detour tunnels. When you apply Fast Reroute to MPLS, you can wrap all the LSPs with one bypass tunnel and a single label, or you can wrap each LSP's traffic around the failed links with a detour tunnel that uses a different label for each LSP 🧚
___ ######## ___ ######## ___
======>/LSR\********/LSR\***XX***/LSR\
\_B_/@@@@@@@@\_A_/ \_F_/
*@ #*@
*@ #*@
*@ #*@
_*@ ___ #*@
/LSR\********/LSR\********/LSR\======>
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link
### working path @@@ wrapped data path
Figure 1: Wrapping Protection for P2P PathLook at Figure 1 🎀 This LSP enters the ring of LSRs at LSR-B and exits at LSR-E. The normal working path LSP goes through LSRs B-A-F-E. Say a fault gets detected on the link A<->F. The wrapping mechanism decides that LSR-A should wrap the traffic around the ring, on a wrapped data path A-B-C-D-E-F, so it reaches LSR-F on the far side of the failed link. Then LSR-F wraps the data packets back onto the working path F->E, heading to the egress node. With this protection scheme, the traffic follows the path B-A-B-C-D-E-F-E 🥹
This protection scheme is simple because the LSRs in the ring don't need to coordinate with each other. Only the LSRs that detect the fault have to wrap traffic, either onto the wrapped data path (at the near end) or back onto the working path (at the far end) 🫶 That said, switching over to the protection path would still need coordination to keep traffic on a co-routed bidirectional LSP, even when the fault is unidirectional 🌸
Here are the things to keep in mind when you're thinking about wrapping protection 🔥
- Detection of mis-connectivity or loss of continuity should be performed at the link level and/or per LSR when using node-level protection. The protection being performed (link protection or node protection) needs to be configured a priori, because the right protection path depends on that decision 💜
- There needs to be a defined data path that traverses the alternate path around the ring to connect the two neighbors of the detected fault. If you protect both the links and the nodes of an LSP, then a ring with N nodes needs O(2N) alternate paths 🌈
- When wrapping, the data is sent over some of the links twice, once in each direction. For example, in the figure above, the traffic goes B->A and then A->B, and later it goes E->F and F->E. This means extra bandwidth is needed for this protection 🍓
- If a double-fault situation happens in the ring, wrapping can't deliver any packets except between the ingress and the first fault location on the working path. That's because wrapping has to connect the neighbors of the fault location, and that isn't possible in the segmented ring 😭
- Pre-allocating resources for all the alternate paths could be a problem and cause massive oversubscription of the available resources. But since most of these alternate paths won't be used at the same time, you could allocate zero resources and rely on the Network Management System (NMS) to allocate the right resources around the ring based on actual traffic usage ✨
- Wrapping also adds a small amount of latency to packet delivery, because the packets traverse the entire ring during protection 🙈
2.2. Steering 💅
The second common ring protection scheme is steering. It takes advantage of the ring topology by defining two paths from the ring's ingress node to the egress point, going in opposite directions around the ring 🦋 Figure 2 shows this. Suppose the traffic needs to enter the ring at node B and exit through node F. We could define a primary path through nodes B-A-F, and an alternate path through nodes B-C-D-E-F. With steering, the switching is always done by the ingress node (node B in Figure 2). If a fault condition is detected anywhere on the working path (B-A-F), B redirects the traffic to the alternate path (that is, B-C-D-E-F) 👑
___ ___ ___
======>/LSR\********/LSR\********/LSR\======>
\_B_/########\_A_/########\_F_/
*@ @*
*@ @*
*@ @*
_*@ ___ @*_
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link
### working path @@@ protection path
Figure 2: Steering Protection in an MPLS-TP RingSteering is kind of similar to linear 1:1 protection [RFC6372]. The two paths around the ring act as the working and protection paths 🌈 This means the ingress node has to be told that it needs to switch over to the protection path, and the ingress and egress nodes have to coordinate the switchover. So you need a way to tell the ingress node it has to switch, and you need to coordinate the switchover between the two endpoints of the protected domain 🥹
Now for the steering-specific things you need to take into account 🎀
- Steering depends on a failure detection method that can notify the ingress node of the fault condition. This may involve OAM functionality described in [RFC6371], for example Remote Defect Indication or alarm reporting 💜
- Notifying the ingress node adds to the latency of the protection-switching process, since it happens after the fault is detected 🫶
- Steering doesn't need double bandwidth for the data path, but the ring still has to keep enough capacity for all of the data flowing in both directions around the ring 🔥
2.3. SPME for P2P Protection of a Ring Topology 🌀
okay so the SPME concept was introduced by [RFC5921] to help manage and monitor any arbitrary chunk of a transport 💅. But honestly, an SPME is basically a valid LSP 🎀 that can gather up all the LSP traffic going through the sub-path it marks out. And you can keep an eye on it with the OAM mechanisms from the MPLS-TP OAM framework document [RFC6371] 👀.
So when you treat an MPLS-TP ring as a protection domain, you need a protection mechanism that covers every LSP crossing the ring 🔄. The move is to attach a (working) SPME to the segment of the transport path that goes through the ring, and then set up an alternate (protecting) SPME that goes around the ring the opposite way ✨. Which SPMEs you pick depends on the transport path and protection types being used, and that gets detailed in the subsections below 🫶.
Because of this setup, you can cut down the number of alternate paths needed to protect the data crossing the ring ✂️. And since all the OAM work happens on the SPME carrying the traffic, you need fewer OAM sessions to watch the ring's data, instead of monitoring each individual LSP one by one 🙌.
In all of the following subsections, we use 1:1 linear protection [RFC6372] [RFC6378] to handle protection switching and coordination when a signal fault gets detected 🚨. The exact SPME setup can change depending on the methodology, and that gets covered in the upcoming sections. But the core idea stays the same: data goes out on the primary SPME, while OAM runs over both the primary and the secondary SPME to catch signal faults on either path 👯. If a signal fault shows up on the primary SPME, then the mechanism described in [RFC6378] shall be used to coordinate a switchover of data traffic to the secondary SPME 💖.
Assuming the SPME is implemented as a hierarchical LSP, packets that arrive at LSR-B with a label stack [LI] get the SPME label pushed at LSR-B, and the LSP label gets swapped for the one the egress LSR expects 🧚. So the packet arrives at LSR-A with a label stack of [PA1(B) | LE] and arrives at LSR-F with [PE1(F) | LE]. LSR-F pops the SPME label, then the LSP label is handled appropriately at LSR-F and forwarded along the LSP, outside the ring 💜. This is true for every LSP aggregated by this primary SPME 🍓.
2.3.1. Path SPME for Steering 🛤️
A P2P SPME that traverses part of a ring has two Maintenance Entity Group End Points (MEPs), and each one acts as the ingress and egress in one direction of the bidirectional SPME 🦋. Since the SPME is crossing a ring, we get to use another ring perk: there is always an alternative path between the two MEPs, which is traversing the ring in the opposite direction 😌. This alternative SPME can be defined as the protection path for the working path configured as part of the LSP and defined as an SPME.
For each pair of SPMEs defined this way, you can verify connectivity and continuity by applying MPLS-TP OAM functionality to both the working and protection SPME 🔍. If a discontinuity or mis-connectivity is detected, the MEPs will become aware of it and could perform a protection switch of all LSPs to the alternate, protection SPME 🫶.
Here's an MPLS-TP ring that's part of a larger MPLS-TP network 🗺️. The ring could be used as a network segment traversed by lots of LSPs. In particular, the figure shows that for all LSPs that connect to the ring at LSR-B and exit the ring from LSR-F, we configure two SPMEs through the ring (the first SPME traverses B-A-F, and the second SPME traverses B-C-D-E-F) 💅.
___ ___ ___
=====>/LSR\********/LSR\********/LSR\======>
\_B_/########\_A_/########\_F_/
*@ @*
*@ @*
*@ @*
_*@ ___ @*_
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
===> connected LSP *** physical link
### primary SPME @@@ secondary SPME
Figure 3: An MPLS-TP RingThis protection mechanism is identical to applying 1:1 linear protection [RFC6372] [RFC6378] to the pair of SPMEs 💜. Under normal conditions, all LSP data traffic is transmitted on the working SPME. If the linear protection is triggered by the OAM indication, another fault indication trigger, or an operator command, then the MEPs select the protection SPME to transmit all LSP data packets 🚀.
The protection SPME keeps transmitting the data packets until the fault condition has stably recovered 🌤️. Once recovery happens (the fault has cleared and the network is stabilized), the ingress LSR could switch traffic back to the working SPME, if the protection domain is configured for revertive behavior 🔁.
The control of the protection switching, especially for operator commands, would be covered by the protocol defined in [RFC6378] 📜.
2.3.2. Wrapping Link Protection with Segment-Based SPME 🧩
It's possible to use the SPME mechanism for segment-based protection 🔗. For each link in the ring, we define two SPMEs. The first is an SPME between the two LSRs connected by the link, and the second is between those same two LSRs but traverses the entire ring (except the link that connects them). In Figure 4, we show the primary SPME that connects LSR-A and LSR-F over a segment connection, and the secondary SPME that connects these same LSRs by traversing the ring in the opposite direction 🌈.
___ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
*@ *@
*@ *@
*@ *@
_*@ ___ _*@
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
*** physical link
### primary SPME @@@ secondary SPME
Figure 4: Segment SPMEsBy applying OAM monitoring to these two SPMEs (at each LSR), you can effect a wrapping protection mechanism for the LSP traffic traversing the ring 🎀. The LSR on either side of the segment would identify that there is a fault condition on the link and redirect all LSP traffic to the secondary SPME 🚨. The traffic would traverse the ring until it arrives at the neighboring (relative to the segment) LSR. At this point, the LSP traffic would be redirected onto the original LSP, quite likely over the neighboring SPME 💖.
Following the progression of the label stack through this switching operation (for an LSP that enters the ring at LSR-B and exits the ring at LSR-E) 🧚:
- The data packet arrives at LSR-A with label stack
[L1+S](i.e., the top label from the LSP and bottom-of-stack indicator) - In the normal case (no protection switching), LSR-A forwards the packet with label stack
[PA1(F) | LSE+S](i.e., swaps the label for the LSP, to be acceptable to the SPME egress, and pushes the label for the primary SPME from LSR-A to LSR-F). - When protection switching is in effect, LSR-A forwards the packet with label stack
[PA2(B) | LSE+S](i.e., LSR-A pushes the label for the secondary SPME from LSR-A to LSR-F, after swapping the label of the lower-level LSP). This will be transmitted along the secondary SPME until LSR-E forwards it to LSR-F with label stack[PE2(F) | LSE+S]. - When the packet arrives at LSR-F, it pops the SPME label, process the LSP label, and forwards the packet to the next point, possibly pushing a SPME label if the next segment is likewise protected.
2.3.3. Wrapping Node Protection 🌸
Implementing protection at the node level is similar to the mechanism described in the previous subsection 🎀. The difference is in the SPMEs that are used. For node protection, the primary SPME would be configured between the two LSRs connected to the node being protected (see the SPME between LSR-A and LSR-E through LSR-F in Figure 5), and the secondary SPME would be configured between these same nodes, going around the ring (see the secondary SPME in Figure 5) 💅.
___ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
*@ *#
*@ *#
*@ *#
_*@ ___ _*#
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
*** physical link
### primary SPME @@@ secondary SPME
Figure 5: Node-Protection SPMEsThe protection mechanism would work similarly. It would be based on 1:1 linear protection [RFC6372] and be triggered by OAM functions on both SPMEs 🔥. It would wrap the data packets onto the secondary SPME at the ingress MEP (e.g., LSR-A in the figure) of the SPME, and back onto the continuation of the LSP at the egress MEP (e.g., LSR-E in the figure) of the SPME 🦋.
2.3.4. Wrapping for Link and Node Protection ✨
okay so, in the wrapping setups from Section 2.3.2 and Section 2.3.3, there's a catch 🙈 The protection mechanism has to decide ahead of time whether it's protecting against a link failure or a node failure. On top of that, the neighboring LSR that spots the fault can't easily tell a link failure apart from a node failure. 😭
You could configure extra SPMEs so you're covered for both link and node failures, and you'd end up with the ring setup in Figure 6. 🎀 There are three protection SPMEs in this version:
- Secondary node#1 handles diverting traffic when LSR-F is unavailable. It redirects traffic to the path between LSR-A and LSR-E.
- Secondary node#2 handles diverting traffic when LSR-A is unavailable. It redirects traffic to the path between LSR-F and LSR-B.
- Secondary segment handles diverting traffic when the segment between LSR-A and LSR-F is unavailable. It redirects traffic to the path between LSR-A and LSR-F on the long circuit of the ring.
BUT 💀 picking which SPME to use for the wrapping would take a LOT of effort, and the protected traffic might end up not sharing the same protection path in both directions. nah 🙅♀️
___ ++++++++ ___ ___
/LSR\********/LSR\********/LSR\
\_B_/@@@@@@@@\_A_/########\_F_/
$+*@ +*$
$+*@ +*$
$+*@ +*$
$+*@ ++++++++ ___ ++++++++ +*$
/LSR\********/LSR\********/LSR\
\_C_/@@@@@@@@\_D_/@@@@@@@@\_E_/
$$$$$$$$ $$$$$$$$
*** physical link
### primary SPME @@@ secondary node#1 SPME
$$$ secondary node#2 SPME +++ secondary segment SPME
Figure 6: SPMEs for Protecting Segments and Node2.4. Analysis of P2P Protection 🧁
okay the vibe check is coming 💅 Looking at steering SPME protection (Section 2.3.1) and wrapping based on SPME (Section 2.3.2 or Section 2.3.3), here's what we can see. This is based on a ring with N nodes, where N is not more than 16:
- Number of SPMEs that need to be configured
- For steering: O(2N^2). There are two SPMEs from each ingress LSR to each of the other nodes in the ring.
- For wrapping: O(2N). (However, the operator must decide a priori whether to protect for link failures or node failures at each point.)
- Number of OAM sessions at each node
- For steering: O(2N)
- For wrapping: 3
- Bandwidth requirements
- For steering: single bandwidth at each link
- For wrapping: double bandwidth at links that are between ingress and wrapping node and between second wrapping node and egress.
- Special considerations
- For steering: latency of OAM detection of fault condition by ingress MEP. (Using alarm reporting could optimize over using CC-V only.)
- For wrapping: each node must decide a priori whether it is protecting for link or node failures. To protect for both node and link failures would increase the complexity of deciding which protection path to use, as well as violate the co-routedness of the protected traffic.
so based on all that, steering (Section 2.3.1) is giving main character energy 👑 because it's the simplest. It's also worth pointing out that you could cut down on the number of SPMEs by dropping each SPME between a pair of LSRs that isn't used as an ingress and egress pair. 🦋
2.4.1. Recommendations for Protection of P2P Paths Traversing a Ring 🌸
okay so, linear protection can be used to get wrapping protection in a ring topology, as we just showed 🫶 BUT there are some limitations when it comes to certain required behavior. Those limitations are:
- the need to configure a priori whether link or node protection will be provided
- the higher number of SPMEs that need to be defined
- the difficulty in addressing cases of multiple failures in the ring
Using linear protection with SPMEs inside the ring to set up steering is pretty straightforward, gets around the limitations above, and scales very well 🔥 For this and the other reasons we covered earlier, the authors recommend using steering to protect P2P paths that go through a ring topology. slay 💖
3. Point-to-Multipoint Protection 🦋
[RFC5654] requires that ring protection must provide protection for unidirectional point-to-multipoint paths through the ring. Ring topologies are a ready-made platform for supporting these data paths, honestly so iconic 🌈 A point-to-multipoint (P2MP) LSP in an MPLS-TP ring is characterized by a single ingress LSR and multiple egress LSRs. The following subsections go through how to protect the ring-based sections of these LSPs. 🧚
3.1. Wrapping for P2MP LSPs 💜
When protecting a P2MP ring data path using the wrapping architecture, the basic operation is similar to what we described before. The traffic gets wrapped back onto the normal working path on the far side of the detected fault, and it keeps being transported to all of the egress points. ✨
It's possible to optimize wrapping for P2MP LSPs by taking advantage of the topology of ring networks. 🎀
This improved mechanism is called Ring Optimized Multipoint Wrapping (ROM-Wrapping), and it behaves much the same as classical wrapping. The difference is that ROM-Wrapping configures a protection P2MP LSP for each node that is considered a failure risk. The protection P2MP LSP is routed from the failure risk node's upstream neighbor to all of the egress nodes (for that particular LSP) that are downstream of the failure risk node. 🫶
Check out Figure 7 🦋 You can see the protected (working) LSP (A-B-{C}-{D}-E-{F}) and one possible backup (protection) LSP. (Note: the egress nodes are shown in curly braces.) This protection LSP is used to wrap the data back around the ring to protect against a failure on link B-C. It's also a P2MP LSP configured with egress points (at nodes F, D, and C) that are complementary to the broken working data path. 🌸
|
|
V Ingress
___ _V_ ___
/LSR\ /LSR\**************/LSR\
<@@\_F_/@@@@@@@@@@@@@\_A_/@@@@@@@@@@@@@@\_B_/
@ * *
@ * *
@ * XXXX Failure
@ * *
@_* ___ __*
/LSR\*************/LSR\**************/LSR\
\_E_/@@@@@@@@@@@@@\_D_/@@@@@@@@@@@@@@\_C_/
@ @
@ @
V V
*** working LSP @@@ protection LSP
Figure 7: P2MP ROM-WrappingUsing this mechanism, you have to configure a particular protection LSP for each node on the working LSP. In the table below, "X's Backup" is the backup path that node X activates when a failure affects node Y (the downstream node with respect to X) or link X-Y. (Note: braces in the path indicate egress nodes.) 💅
Protected LSP: A->B->{C}->{D}->E->{F}
-- LINK/NODE PROTECTION --
A's Backup: A->{F}->E->{D}->{C}
B's Backup: B->A->{F}->E->{D}->{C}
C's Backup: C->B->A->{F}->E->{D}
D's Backup: D->C->B->A->{F}
E's Backup: E->D->C->B->A->{F}It should be noted that ROM-Wrapping is an LSP-based protection mechanism, as opposed to the SPME-based protection mechanisms presented in other sections of this document. I know it might seem limited in scope, but it can be super efficient for lots of applications built on P2MP distribution schemes 🍓 And while ROM-Wrapping can be applied to any network topology, it's particularly efficient for interconnected ring topologies. obsessed 😭🫶
3.1.1. Comparison of Wrapping and ROM-Wrapping 💅
okay bestie, let's compare wrapping and ROM-Wrapping 🦋 ngl ROM-Wrapping has some serious glow-up energy ✨ there are a few aspects we can line up side by side.
When you configure the protection LSP for wrapping, you have to pick one specific failure type: link protection or node protection 🎀. And if you set it up to protect against node failures but the actual problem is on a link, traffic might fail to reach the node even though it totally could have 😭
ROM-Wrapping doesn't have that drama 💜 because there's no split between node and link protection at all. Whether link B-C or node C fails, the rerouting just tries to reach C. If it's the link, traffic gets to C 🎉. If it's node C, the traffic still gets rerouted correctly until node D, and it gets blocked right there. But every egress node up to the failure still gets its traffic delivered properly 🌸
Second thing: the number of hops 🧚 Referring to Figure 7, where a failure is detected on link B-C, here's the set of nodes the data traverses in the protection:
Basic Wrapping:
A-B B-A-F-E-D-C {C}-{D}-E-{F}
"Upstream" segment backup path "Downstream" segment
with respect to the with respect to the
failure failure
ROM-Wrapping:
A-B B-A-{F}-E-{D}-{C} ..
"Upstream" segment backup path
with respect to the
failureCompare the two lists and it's giving obvious winner 👑 In this particular case, basic wrapping crosses significantly more hops than ROM-Wrapping does. Generally, the number of hops for basic wrapping is always greater than or equal to that for ROM-Wrapping. That means some bandwidth gets wasted on all the links that get crossed in both directions 😩
Now the bandwidth utilization on the ring in Figure 7 🌈 The protected LSP is set up from A to F clockwise, and an M Mbps bandwidth is reserved along the path. All the protection LSPs are pre-provisioned counterclockwise, and each of them may also have reserved bandwidth M. These LSPs share the same bandwidth in a SE (Shared Explicit) style, as described in [RFC2205].
The bandwidth reserved counterclockwise isn't used while the protected LSP is working properly, and in theory it could be used for extra traffic [RFC4427]. However, it should be noted that [RFC5654] does not require support of such extra traffic 🙈
The two recovery mechanisms need different protection bandwidths. With wrapping, the bandwidth used is M in both directions on many of the links. With ROM-Wrapping, only the links from the ingress node to the node performing the actual wrapping use M bandwidth in both directions, while all the other links use M bandwidth only in the counterclockwise direction ✨
Say there's a failure detected on link B-C as shown in Figure 7. Here's the bandwidth utilization on each link (in units equal to M), for each recovery mechanism and each direction (CW=clockwise, CCW=counterclockwise):
+----------+----------+--------------+
| | Wrapping | ROM-Wrapping |
+----------+----------+--------------+
| Link A-B | CW+CCW | CW+CCW |
| Link A-F | CCW | CCW |
| Link F-E | CW+CCW | CCW |
| Link E-D | CW+CCW | CCW |
| Link D-C | CW+CCW | CCW |
+----------+----------+--------------+3.1.2. Multiple Failures Comparison 💔
One more comparison: how the two handle multiple failures. The wrapping recovery mechanism can't recover from multiple failures on a ring network, while ROM-Wrapping is able to recover from some multiple failures 🦋
Take a double link failure hitting links B-C and C-D in Figure 7. Wrapping can't recover from it, because B has no alternative paths to reach C once it detects the failure. All the P2MP traffic is lost 😭 ROM-Wrapping can only partially recover, but the backup P2MP LSP to F and D is set up correctly and keeps delivering traffic 🫶
3.2. Steering for P2P Paths 🎀
Hmm, correction, bestie: this one's about P2MP. When protecting P2MP traffic that uses an MPLS-TP ring as its branching point (so the traffic enters the ring at a head-end node and exits at multiple nodes), we can use a steering mechanism based on 1+1 linear protection [RFC6372] 🔥 We can configure two P2MP unidirectional SPMEs from each node on the ring, and they traverse the ring in both directions. These SPMEs get configured with an egress at each ring node. To direct the LSP traffic to the right egress point for that particular LSP, we need context labeling as defined in [RFC5331] ✨ The way to use those labels is expanded on in Section 3.2.1.
For every LSP that enters the ring at a given node, the traffic gets sent through both of these SPMEs, each with its own context label plus the context-specific label for that LSP. The egress nodes should select the traffic arriving on the working SPME. When a failure condition is identified, the egress nodes should select the traffic from whichever of the two SPMEs is arriving at that node, since one of the two (presumably the working SPME) gets blocked by the failure. That's how all the egress nodes get the data traffic 💖 While each node detects connectivity from the ring's ingress node, it keeps selecting the data coming from the working SPME. If a node stops receiving connectivity messages from the working SPME, it knows it must switch to reading the data packets from the protection SPME 🌈
3.2.1. Context Labels 🧚
Figure 8 shows the two unidirectional P2MP SPMEs configured from LSR-A, with egress points at all the nodes on the ring. The clockwise SPME (A-B-C-D-E-F) is the working SPME, and it aggregates all traffic for P2MP LSPs that enter the ring at LSR-A and must exit at any subset of the ring nodes. The counter-clockwise SPME (A-F-E-D-C-B) is the protection SPME 💜
^ ^ ^
_|_ _|_ _|_
----->/LSR\********/LSR\********/LSR\
\_A_/========\_B_/========\_C_/
+* <+++++++++*||
+* +*||
+* +*||
+* +*||
+*_ ++++++++ ___ +++++++++*||
/LSR\********/LSR\********/LSR\
\_F_/<=======\_E_/========\_D_/
| | |
V V V
---> connected LSP *** physical link
=== working SPME +++ protection SPME
Figure 8: P2MP SPMEs[RFC5331] defines context labels. A context-identifying label defines a context label space, which is used to interpret the context-specific labels (found directly below the context-identifying label) for a specific tunnel. The SPME label is a context-identifying label. So at each hop, the node that receives the SPME label doesn't use it to point straight to a forwarding table; it points to a Label Information Base (LIB) 🦋 When a node receives an SPME label, it examines it, sees that it's a context label, pops the SPME label off, and looks up the next label down in the stack in the LIB that the context label indicates.
The label below this context-identifying label should be used by the node's forwarding function to decide what actions to take for the packet. In MPLS-TP protection of ring topologies, there are two context LIBs: one for the working SPME and one for the protection SPME. Every context LIB has a behavior defined for the end-to-end LSP label, but the behavior at each node may differ depending on which SPME it's in 🌸
Using the ring in Figure 8 as an example: the working SPME has a context-identifying label of CW at each node on the ring, and the protection SPME has a context-identifying label of CP at each node. For a specific LSP, we'll call the context-specific label used on the working SPME WL(x-y), where node-x forwards the packet to node-y. Similarly, a context-specific label on the protection SPME is called PL(x-y). A concrete example of label values shows up in the next subsection 🎀
Now assume we're applying 1+1 linear protection, as outlined above, for a P2MP LSP that enters the ring at LSR-A and has egress points at LSR-C and LSR-E, using the two SPMEs in Figure 8. A packet arriving at LSR-A with label stack [LI+S] gets forwarded on the working SPME with label stack [CW | WL(A-B)]. The packet should then be forwarded to LSR-C, arriving with label [CW | WL(B-C)], where WL(B-C) should instruct the forwarding function to egress the packet with [LE(C)] and forward a copy to LSR-D with label stack [CW | WL(C-D)] 💅
If a fault condition is detected (say, on link C-D), the nodes beyond the fault point (in this example, LSR-D, LSR-E, and LSR-F) stop receiving data packets from the clockwise (working) SPME. Each of these LSRs should then start switching its "selector bridge" to accept data packets from the protection (counter-clockwise) SPME. At the ingress point (LSR-A), all data packets have been transmitted on both the working SPME and the protection SPME. Continuing the example, LSR-A transmits one copy of the data to LSR-B with stack [CW | WL(A-B)] and one copy to LSR-F with stack [CP | PL(A-F)] 🦋 The packet arrives at LSR-C from the working SPME and egresses from the ring. LSR-E receives the packet from the protection SPME with stack [CP | PL(F-E)], and the context-sensitive label PL(F-E) instructs the forwarding function to send a copy out of the ring with label LE(E) and a second copy to LSR-D with stack [CP | PL(E-D)]. That way, each egress point gets the packet from whichever SPME is available at that point 🌈
This architecture has the added advantages that the ingress node doesn't need to identify the existence of the mis-connectivity, and there's no need for a return path from the egress points to the ingress ✨
3.2.2. Walk-Through Using Context Labels ✨
okay so context labels can get confusing fast, so let's walk through an example of the P2MP protection from this section 🫶 Check out Figure 9. There's a P2MP LSP looping around the ring 🔁. It gets on at LSR-B, branches off at LSR-D, LSR-E, and LSR-H, and stops there. It does not go past LSR-H.
For protection, we set up two unidirectional P2MP SPMEs on the ring, both starting from LSR-B. The working SPME has egress points at every LSR: C, D, E, F, G, H, J, K, A. The protection SPME goes the other way around with egress points at A, K, J, H, G, F, E, D, C. 🔄
^ ^ ^ ^
^ ^ ^ ^
___ xxxxxxxxx_+_ xxxxxxxxxX+_xxxxxxxxxX+_ xxxxxxxx_+_
xxxxx>/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
\_B_/========\_C_/========\_D_/=======\_E_/=======\_F_/
*+ <+++++++++ +++++++ ++++++++*||x
*+ +*||x
*+ +*||x
*+ +*||x
_*++++++++++ ___ +++++++++___ ++++++++___+++++++++*||x
/LSR\********/LSR\********/LSR\*******/LSR\*******/LSR\
\_A_/<=======\_K_/========\_J_/=======\_H_/=======\_G_/
+ + + +Xxxxxxxxxx +
v v v v v
v v v v v
xxx P2MP LSP (X LSP egress) *** physical link
=== working SPME +++ protection SPME
+>> protection SPME egress
Figure 9: P2MP SPMEsfor this example, the LSP traffic enters the ring at LSR-B with the label stack [99] and leaves the ring:
- at LSR-D with stack [199]
- at LSR-E with stack [299]
- at LSR-H with stack [399]
each SPME's context-identifying label can technically be set to a different value at each LSR, but to keep things simple, we'll say the working SPME uses 200 at every LSR in the ring, and the protection SPME uses 400 at every LSR. 🎀
for this connected LSP, we configure these context-specific labels:
+------+-----------------------------+------------------------------+
| node | W-context(200) | P-context(400) |
+------+-----------------------------+------------------------------+
| A | 65 {drop packet} | 165 {fwd w/ [400 | 190]} |
| C | 90 {fwd w/ [200 | 80]} | 190 {drop packet} |
| D | 80 {fwd w/ [200 | 75] + | 180 {egress w/ [199]} |
| | egress w/ [199]} | |
| E | 75 {fwd w/ [200 | 65] + | 175 {fwd w/ [400 | 180] + |
| | egress w/ [299]} | egress w/ [299]} |
| F | 65 {fwd w/ [200 | 55]} | 165 {fwd w/ [400 | 175]} |
| G | 55 {fwd w/ [200 | 45]} | 155 {fwd w/ [400 | 165]} |
| H | 45 {egress w/ [399]} | 145 {fwd w/ [400 | 155] + |
| | | egress w/ [399]} |
| J | 65 {drop packet} | 165 {fwd w/ [400 | 145]} |
| K | 65 {drop packet} | 190 {fwd w/ [400 | 165]} |
+------+-----------------------------+------------------------------+so when a packet hits LSR-B with stack [99], the forwarding function decides it has to go out on both the working SPME with stack [200 | 90] and the protection SPME with stack [400 | 165]. 💫 Each LSR on an SPME looks at the top label, which is 200 or 400, to figure out the context-identifying label. Then it uses the next label down the stack to pick the forwarding action from that context's table. 🧠
so at LSR-C, the packet on the working SPME shows up with stack [200 | 90]. The 200 points to the middle column of the table. After the 200 gets popped, the 90 picks the action "fwd w/ [200 | 80]", and the packet heads to LSR-D with stack [200 | 80]. The packet goes along both SPMEs following the context tables, but the egress points at LSR-D, LSR-E, and LSR-H each have a selector bridge, so they only read input from the working SPME. If one of those egress points spots a connection fault on the working SPME, the selector bridge makes the LSR read from the protection SPME instead. 🛟
4. Coordination Protocol ✨
okay the survivability framework [RFC6372] says we need to coordinate protection switching between the endpoints of a protected bidirectional domain 🤝 This coordination matters for some cases, because it keeps the bidirectional transport path co-routed. The cases where it gets necessary include unidirectional fault detection and operator commands.
we can use the same mechanisms [RFC6378] defines for linear protection to protect a single ring topology, which gives us one consistent solution for coordinating between the endpoints 💅 The Protection State Coordination Protocol in [RFC6378] covers all the coordination cases, including operator commands such as Forced Switch. 🙌
5. Conclusions and Recommendations 🌈
ring topologies are everywhere in traditional transport networks, and they're going to stick around for a bunch of reasons 💖 Protection for transport paths that cross a ring inside an MPLS network can be handled by an appropriate instance of linear protection, as defined in [RFC6372]. This document shows that each traditional ring-protection architecture has a linear protection setup that gives efficient coverage, built on the Sub-Path Maintenance Entity (SPME) defined in [RFC5921] and [RFC6371]. here are the highlights:
- P2P steering 🛤️: configure two SPMEs, from the ingress node of the ring to the egress node, plus 1:1 linear protection.
- P2P wrapping for link protection 🎁: configure two SPMEs, one for the protected link and one for the long route between the two neighboring nodes, plus 1:1 linear protection.
- P2P wrapping for node protection 🧩: configure two SPMEs, one between the two neighbors of the protected node and one between those two nodes on the long route, plus 1:1 linear protection.
- P2MP wrapping 🌀: you can optimize wrapping by configuring the protection path to egress the data at the right branching nodes.
- P2MP steering 🪄: combine 1+1 linear protection with an SPME configured using context-sensitive labeling of the protection path.
this document also shows that the protection architecture and mechanisms it suggests give the optimizations needed to justify ring-specific protection as defined in [RFC5654]. 👑
protecting traffic on a ring with the steering architecture and basic 1:1 linear protection is a super efficient setup for the sections of a P2P transport path that cross a ring 🔥 steering should be the preferred mechanism for P2P protection on a ring, since it cuts down the extra bandwidth needed when traffic doubles up through wrapped protection. It also protects against both link and node failures without complicating fault detection or needing multiple protection paths to be configured. 🫶 That said, you can still support either wrapping or steering, depending on the OAM functionality outlined in [RFC6371] (and specified in various documents) and on the coordination protocol for linear protection in [RFC6378]. 🦋
6. Security Considerations 💀
okay this part is important, so no cap: this document does not add any security risks to the network 🔐 Any security considerations are defined in [RFC6378], and how they apply to the information in this document follows naturally from how the mechanism in that document applies. Read [RFC6378] before you touch any of this. 🛡️
7. References 📚
7.1. Normative References
[RFC6378] Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
A. Fulignoli, "MPLS Transport Profile (MPLS-TP) Linear
Protection", RFC 6378, October 2011.7.2. Informative References
[G.841] ITU, "Types and characteristics of SDH network protection
architectures", ITU-T G.841, October 1998.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[RFC4427] Mannie, E. and D. Papadimitriou, "Recovery (Protection and
Restoration) Terminology for Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4427, March 2006.
[RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space",
RFC 5331, August 2008.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
[RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L.
Berger, "A Framework for MPLS in Transport Networks",
RFC 5921, July 2010.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[RFC6372] Sprecher, N. and A. Farrel, "MPLS Transport Profile
(MPLS-TP) Survivability Framework", RFC 6372,
September 2011.Appendix A. Acknowledgements 🫶
the authors want to give a huge shoutout to everyone who commented on this document and suggested improvements 🥰 you know who you are!
Appendix B. Contributors 🌸
the authors want to thank these folks who shared their insights and advice on this work ✨
- Nurit Sprecher (NSN) 💜
- Akira Sakurai (NEC) 💜
- Rolf Winter (NEC) 💜
- Eric Osborne (Cisco) 💜
Authors' Addresses 💖
okay bestie, last stop! 🫶 here's where you can find the humans behind this doc, and every address and email is copied exactly as written 🎀
Yaacov Weingarten
34 Hagefen St.
Karnei Shomron, 4485500
Israel
Phone:
EMail: wyaacov@gmail.comStewart Bryant
Cisco Systems
10 New Square, Bedfont Lakes
Feltham, Middlesex,
TW18 8HA
UK
EMail: stbryant@cisco.comDanielle Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova, Sestri Ponente
Italy
EMail: daniele.ceccarelli@ericsson.comDiego Caviglia
Ericsson
Via A. Negrone 1/A
Genova, Sestri Ponente
Italy
EMail: diego.caviglia@ericsson.comFrancesco Fondelli
Ericsson
Via A. Negrone 1/A
Genova, Sestri Ponente
Italy
EMail: francesco.fondelli@ericsson.comMarco Corsi
Altran
Via A. Negrone 1/A
Genova, Sestri Ponente
Italy
EMail: corsi.marco@gmail.comBo Wu
ZTE Corporation
4F, RD Building 2, Zijinghua Road
Nanjing, Yuhuatai District
P.R. China
EMail: wu.bo@zte.com.cnXuehui Dai
EMail: xuehuiwfsy@gmail.com📦 where this page comes from
- ietf: rfc6974 2013-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms