RFC 7412

Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection

📅 published December 2014, from ietf

Requirements for MPLS Transport Profile (MPLS-TP) Shared Mesh Protection 🎀

Okay bestie, this is RFC 7412 ✨. It's an Informational doc, so it's not a Standards Track spec. It was published in December 2014 and the authors are Y. Weingarten (Huawei Technologies), S. Aldrin (Huawei Technologies), P. Pan (Infinera), J. Ryoo (ETRI), and G. Mirsky (Ericsson). It's from the IETF, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so no drama there 💅.

Abstract ✨

So the main idea 🦋: this doc lays out the basic network goals for how Shared Mesh Protection (SMP) should behave when there's no control-plane support. It's basically an upgraded, more detailed version of the basic requirements in RFC 5654 ("Requirements of an MPLS Transport Profile") and RFC 6372 ("MPLS Transport Profile (MPLS-TP) Survivability Framework"). It gives requirements for any mechanism that would implement SMP for MPLS-TP data paths, in networks that hand off protection switch coordination to the data plane 🫶.

Status of This Memo 🌸

Not a Standards Track spec, just published for info purposes. It is an IETF product and represents the consensus of the IETF community. It got public review and was approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you're curious 🙈.

For the latest status, errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7412 🔗.

Copyright (c) 2014 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 publication date. Read those carefully, since they explain your rights and restrictions. Code Components pulled from this doc must include the 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
2. Terminology and Notation ........................................3
   2.1. Acronyms and Terminology ...................................4
3. Shared Mesh Protection Reference Model ..........................4
   3.1. Protection or Restoration ..................................5
   3.2. Scope of Document ..........................................5
        3.2.1. Relationship to MPLS ................................5
4. SMP Architecture ................................................6
   4.1. Coordination of Resources ..................................8
   4.2. Control Plane or Data Plane ................................8
5. SMP Network Objectives ..........................................9
   5.1. Resource Reservation and Coordination ......................9
        5.1.1. Checking Resource Availability for Multiple
               Protection Paths ....................................9
   5.2. Multiple Triggers .........................................10
        5.2.1. Soft Preemption ....................................10
        5.2.2. Hard Preemption ....................................10
   5.3. Notification ..............................................11
   5.4. Reversion .................................................11
   5.5. Protection Switching Time .................................11
   5.6. Timers ....................................................12
   5.7. Communication Channel and Fate-Sharing ....................12
6. Manageability Considerations ...................................13
7. Security Considerations ........................................13
8. Normative References ...........................................13
Acknowledgements ..................................................15
Contributors ......................................................15
Authors' Addresses ................................................16

1. Introduction 🍓

The MPLS Transport Profile (MPLS-TP) is described in [RFC5921]. [RFC6372] gives a survivability framework for MPLS-TP and is the foundation for this doc 🌈.

Terminology for recovering connectivity in networks is in [RFC4427]. It covers surviving network faults (survivability) by re-establishing connections (restoration) and switching traffic to pre-established backup paths (protection). MPLS has control-plane tools for different survivability schemes, and some are listed in [RFC4426]. Recently the IETF has also started building data-plane tools for data protection. Specifically, [RFC6378] and [RFC7271] define a set of triggers and coordination protocols for 1:1 and 1+1 linear protection of point-to-point paths 👑.

So here's the vibe 💅: if you're looking at a full-mesh network and protecting the different paths that cross it, you can get an acceptable level of protection while using fewer protection resources. As [RFC6372] and [RFC4427] point out, 1+1 protection means resources get allocated for both the working and protection paths. 1:1 protection also allocates the same resources, but the protection path's resources can be used for preemptible extra traffic. Extending this to 1:n or m:n protection lets one protection path's resources be shared across several working paths. The catch is that 1:n or m:n protection is limited because all of the n+1 or m+n paths must have the same endpoints. m:n protection gives m protection paths to protect n working paths, where m or n can be 1 🎀.

This document provides requirements for any mechanism that would be used to implement SMP for MPLS-TP data paths, in networks that delegate protection switch coordination to the data plane ✨.

2. Terminology and Notation 🦋

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

Okay so this doc isn't a protocol spec, but using that language helps protocol designers know what they need to do to meet the requirements here 🫶.

The terminology here is based on the MPLS-TP Survivability Framework document [RFC6372], which is itself based on [RFC4427] 💜.

2.1. Acronyms and Terminology 🌸

This document uses the following acronyms:

   LSP  Label Switched Path
   SLA  Service Level Agreement
   SMP  Shared Mesh Protection
   SRLG Shared Risk Link Group

This document defines the following term:

   SMP Protection Group: the set of different protection paths that
      share a common segment.

3. Shared Mesh Protection Reference Model 🧚

As [RFC6372] describes, SMP supports sharing protection resources while protecting multiple working paths that don't need common endpoints and don't share common points of failure. Some protection resources may be shared while others may not be 🌈. Figure 1 shows an example of data paths using SMP. Two working paths, <ABCDE> and <VWXYZ>, are protected with 1:1 linear protection by protection paths <APQRE> and <VPQRZ>. Both protection paths go through segment <PQR>, so they share the protection resources on that segment 👑.

                       A----B----C----D----E
                        \                 /
                         \               /
                          \             /
                           P-----Q-----R
                          /             \
                         /               \
                        /                 \
                       V----W----X----Y----Z

                 Figure 1: Basic SMP Architecture

3.1. Protection or Restoration 💅

[RFC6372], based on the definitions in [RFC4427], tells "protection" and "restoration" apart based on how dynamic the resource allocation is. The same distinction is used in [RFC3945], [RFC4426], and [RFC4428] ✨.

This document uses the same distinction between protection and restoration that [RFC6372] states 🫶.

3.2. Scope of Document 🍓

[RFC5654] establishes that MPLS-TP SHOULD support shared protection (Requirement 68) and that MPLS-TP MUST support sharing of protection resources (Requirement 69). This document gives the network objectives and a framework for applying SMP within an MPLS network, without using control-plane protocols. There are existing control-plane solutions for SMP within MPLS, but a data-plane solution is required for networks that don't run a full control-plane operation for some reason (e.g., service provider preferences or limitations), or that need service restoration faster than control-plane mechanisms can manage 🔥.

The network objectives will also cover possible extra restrictions on SMP behavior in networks that delegate protection switching for resiliency to the data plane. Defining the logic and specific protocol messaging is out of scope for this document 🙈.

3.2.1. Relationship to MPLS 🌈

Some of the restrictions in this document come from the properties of transport networks. Nothing stops this information from being applied to MPLS networks outside the scope of the Transport Profile of MPLS 🦋.

4. SMP Architecture ✨

Okay so, Figure 1 shows a super basic setup of working and protection paths that can use SMP 💖. But we can level up to a slightly more complex setup, like the one in Figure 2, to show off what a mesh network with SMP looks like 🕸️🦋.

                      A----B----C----D----E---N
                       \            /    /    \
                        \          M ---/--    \
                         \             /   \    \
                          P-----Q-----R-----S----T
                         /|      \     \     \    \
                        / F---G---H    J--K---L    \
                       /                            \
                      V------W-------X-------Y-------Z

              Figure 2: Example of a Larger SMP Architecture

Let's look at the network in Figure 2 😌. There are five working paths:

  • <ABCDE>
  • <MDEN>
  • <FGH>
  • <JKL>
  • <VWXYZ>

Each of these has a matching protection path:

  • <APQRE> (p1)
  • <MSTN> (p2)
  • <FPQH> (p3)
  • <JRSL> (p4)
  • <VPQRSTZ> (p5)

Now the shared segments, which is where it gets spicy 🌶️. <PQ> is shared by p1, p3, and p5. <QR> is shared by p1 and p5. <RS> is shared by p4 and p5. And <ST> is shared by p2 and p5. So in Figure 2, the SMP Protection Groups are {p1, p3, p5} for <PQ>, {p1, p5} for <QR>, {p4, p5} for <RS>, and {p2, p5} for <ST> 🧩.

We're assuming the protection resources on these shared segments aren't enough to carry the full traffic capacity of every working path that might use those protection paths 😭. We can also notice that if you have a good way of coordinating sharing and preemption, there are no co-routing constraints on shared components at the segment level 💅.

Preemption in the network is usually a business or policy call 💼. So when protection resources are fought over, priority can decide who gets to use them 👑.

Here's the vibe check: with simple linear protection, the working and protection paths have a fixed relationship and the protection path's resources are fully dedicated to it 🎀. With SMP, though, the protection path is made of segments that protect its own working path and segments shared with other protection paths 🌈. So the protection resources are typically oversubscribed, which is totally fine because the working paths involved don't share common points of failure 🫶. What's required is a preemption mechanism to put business priority first when multiple failure scenarios happen ⭐. That means the protection resources might be allocated, but they won't actually get used until they're requested and sorted out with the other members of the SMP Protection Group during a protection switchover 🔥.

[RFC6372] defines two kinds of preemption for how SMP Protection Group resources get shared 🦋. One is "soft preemption", where traffic on lower-priority paths gets degraded. The other is "hard preemption", where traffic on lower-priority paths gets completely blocked 🙈. In this document, the traffic of lower-priority paths can be seen as the extra traffic being preempted, as [RFC6372] describes 🍓. "Hard preemption" needs selectors at the ingress of each shared segment that specify the priorities of backup paths, so lower-priority traffic can be preempted 🧚. And when any protection mechanism is used where the protection endpoint might have a choice of protection paths (for example m:n or m:1), the shared segment selectors also need coordinating with the protection endpoints 🤝.

Deploying services that use SMP takes a bunch of network planning 📝. That includes the following:

  • Figuring out how many working and protection paths are needed to hit the service's resiliency targets 🎯.
  • Looking over the network topology to decide which working or protection paths need to be disjoint from each other, and excluding specified resources like links, nodes, or shared risk link groups (SRLGs) 🗺️.
  • Deciding the size (bandwidth) of the shared resource 📏.

4.1. Coordination of Resources

When a protection switch gets triggered, the SMP network does two things at once 💫: it switches data traffic over to a protection path, and it coordinates how the associated shared resources get used. Both should happen at the same time, or as close together as possible, for fast protection ⚡. How well the resource coordination goes depends on whether those resources are available at each shared segment 🤔.

When a particular protection path is using the reserved resources of a shared segment, there might not be enough left for another protection path 😬. That means if another working path in the SMP domain triggers a protection switch, the resource coordination might fail 💀. The different working paths in the SMP network all take part in resource coordination, and that's part of the bigger SMP protection switching coordination 🧸.

4.2. Control Plane or Data Plane

As both [RFC6372] and [RFC4428] say, fully controlling SMP, including both configuration and coordinating protection switching, can be really complicated 🌀. So the suggestion is to run this under a dynamic control plane based on Generalized MPLS (GMPLS) [RFC3945] 🎛️. SMP implementations with GMPLS already exist, and the general principles of how it works are well known, even if they aren't fully written down 📖.

But some operators, especially in the transport sector, don't run their MPLS-TP networks under a control plane 🚫. Others have handed resilience actions over to the data plane for other reasons 🛠️. Those operators still need to be able to use SMP protection 🙏. For networks like that, it's absolutely essential that all the required coordination of selectors and endpoints for SMP can be done through data-plane operations 💜.

5. SMP Network Objectives 🎯

5.1. Resource Reservation and Coordination

SMP runs on pre-configuration of working paths and their matching protection paths 🛤️. That configuration can come from a control protocol or from static configuration by the management system 🖥️. Even when a control protocol like GMPLS does the configuration, the control protocol SHALL NOT be used as the primary mechanism for detecting or reporting network failures, or for starting or coordinating protection switchover 🚨. That is, it SHALL NOT be used as the primary resilience mechanism 🛡️.

The protection relationship between working and protection paths SHOULD be configured, and the shared segments of the protection path MUST be identified before the protection paths get used 🔍. Relative priority for working paths, used to settle contention when multiple working paths want a protection path, MAY also be specified ahead of time 🏅.

When a protection switch gets triggered by any fault condition or operator command, the SMP network MUST perform two operations: switch data traffic over to a protection path, and coordinate the utilization of the associated shared resources 🔁. To keep protection fast, both operations MUST occur at the same time or as close to the same time as possible ⏱️.

If multiple working paths fail, the shared resource utilization coordination SHALL be between the different working paths in the SMP network 🤝.

5.1.1. Checking Resource Availability for Multiple Protection Paths

In a hard-preemption scenario, when an endpoint spots a protection switching trigger and has more than one possible action (for example, m:1 protection), it MUST verify that the necessary protection resources are available on the selected protection path 🔎. The resources might not be available because they're already being used to protect one or more higher-priority working paths, for example 🙃.

5.2. Multiple Triggers

If more than one working path triggers a protection switch in a way that oversubscribes a protection segment, the SMP network has two different actions it can pick from: soft preemption and hard preemption [RFC6372] 🎭.

5.2.1. Soft Preemption

For networks that support multiplexing packets over the shared segments, the requirement goes like this 🧃:

  • All of the protection paths MAY be allowed to share the resources of the shared segments 🤗.

5.2.2. Hard Preemption

Some networks need the exclusive use of protection resources when a protection segment gets oversubscribed 🔒. Traffic of lower-priority paths is completely blocked in that case 🚫. These include networks that support the requirements in [RFC5654], and in particular support Requirement 58 📚. For those networks, the following requirements apply 💅:

  1. Relative priority MAY be assigned to each of the working paths of an SMP domain. If no priority is assigned, the working paths are assumed to have equal priority 🥇.
  2. Resources of the shared segments SHALL be utilized by the protection path according to the highest priority amongst those requesting use of the resources 👑.
  3. If multiple protection paths of equal priority are requesting the shared resources, the resources SHALL be utilized on a first come first served basis. Traffic of the protection paths that request the shared resources late SHALL be preempted 🏃‍♀️. To cover the situation where first come first served can't settle contention among equal-priority requests, which happens when the requests occur simultaneously, tie-breaking rules SHALL be defined in the scope of an SMP domain 🪢.
  4. If a higher-priority path needs the protection resources currently used by a lower-priority path, the resources SHALL be utilized by the higher-priority path. Traffic with the lower priority SHALL be preempted 💫.
  5. Once resources of shared segments have been successfully utilized by a protection path, the traffic on that protection path SHALL NOT be interrupted by any protection traffic whose priority is equal to or lower than the protecting path currently in use 🛑.
  6. During preemption, shared segment resources MAY be used by both existing traffic (that is being preempted) and higher-priority traffic 🌊.

5.3. Notification

When a working path endpoint has a protection switch triggered, it SHOULD try to switch the traffic to the protection path and request coordination of the shared resource utilization 📣. If the necessary shared resources are unavailable, the endpoints of the requesting working path SHALL be notified of protection switchover failure, and the switchover won't be completed 😢.

Similarly, if preemption is supported and the resources currently used by a particular working path are being preempted, then the endpoints of the affected working path, whose traffic is being preempted, SHALL be notified that those resources are being preempted 📢. As [RFC6372] describes, Operations, Administration, and Maintenance (OAM) may detect the preemption event and report it as a fault or as a degradation of traffic delivery 🔔✨.

5.4. Reversion ✨

Okay so bestie, once the thing that set off the protection switch is cleared 🧹, you get to pick: go back to the working path resources, or keep chilling on the protection ones 🌸. Staying on protection lets the operator push the service blip until traffic is lighter 🌙. The switchover needs an explicit operator command 🫶, unless a higher-priority fault preempts the protection resources 🚨. So both automatic and manual revertive behaviors MUST be supported for hard preemption in an SMP domain 💅. Normally the network should revert to the working path resources so the protection resources are free to protect other path triggers ✨. However, the protocol MUST support non-revertive configurations 🦋.

5.5. Protection Switching Time ⏱️

Protection switching time is the transfer time (Tt) from [G.808.1] and the recovery switching time from [RFC4427]. Basically it's the gap from when a switching trigger gets identified until traffic starts flowing on the protection path 🚀. It does NOT count the time to kick off the switch after a failure, or the time to finish preempting existing traffic on the shared segments (see Section 4.2) 🙅‍♀️. Kicking off the switch is the detection or correlation time in [RFC4427], and that's OAM or management territory 🛎️. Finishing preemption is all about what happens inside the SMP domain 🧠. Hitting 50 ms depends on the initial switchover to the protection path, but the preemption time SHOULD also be taken into account to keep total service interruption small 💖. When triggered, protection switching action SHOULD be initiated immediately to keep that interruption short ⚡.

5.6. Timers ⏲️

To stop multiple switching actions from one trigger when there are several network layers 🥞, SMP SHOULD be controlled by a hold-off timer. That lets lower-layer mechanisms finish their switching before SMP protection actions kick in, as described in [RFC6372] 🫠. And so an unstable recovering working path doesn't keep flipping things back and forth 🙃, SMP SHOULD employ a Wait-To-Restore timer during any reversion switching, as described in [RFC6372] 💜.

5.7. Communication Channel and Fate-Sharing 🤝

SMP SHOULD provide a communication channel along the protection path, between its endpoints, to support fast protection switching ⚡. SMP in hard-preemption mode SHOULD include support for communicating information to coordinate use of the shared protection resources among multiple working paths 👯. The message encoding and the communication channel between the nodes of the shared protection resource and the endpoints of the protection path are out of scope for this document 🙈. Bidirectional protection switching SHOULD be supported in SMP 🔁.

6. Manageability Considerations 🛠️

The network management architecture and requirements for MPLS-TP are specified in [RFC5951] 📋. They derive from the generic specifications in ITU-T G.7710/Y.1701 [G.7710] for transport technologies 🌐. This document does not introduce any new manageability requirements beyond the ones covered in those documents 💅.

7. Security Considerations 🔐

Okay, this section is SERIOUS, so please read every word 🫶.

General security considerations for MPLS-TP are covered in [RFC5921] 🧯. The security considerations for the generic associated control channel are described in [RFC5586] 📡.

Security considerations for any proposed solution should consider exhaustion of resources related to preemption, especially by a malicious actor. That's a threat vector, so those resources should be protected 🚨😭. Protections should also be considered to prevent a malicious actor from attempting to create an alternate path on which to force traffic from a sensor or device, which would enable pervasive monitoring [RFC7258] 👀. Bestie, do not skip this part 💀.

8. Normative References 📚

Acknowledgements 🙏

This document is the outcome of discussions on Shared Mesh Protection for MPLS-TP. The authors would like to thank all contributors to these discussions, and especially Eric Osborne for facilitating them 🌷.

We would also like to thank Matt Hartley for working on the English review and Lou Berger for his valuable comments and suggestions on this document 💖.

Contributors 🌟

David Allan
Ericsson
EMail: david.i.allan@ericsson.com

Daniel King
Old Dog Consulting
EMail: daniel@olddog.co.uk

Taesik Cheung
ETRI
EMail: cts@etri.re.kr

Authors' Addresses 🏡

Yaacov Weingarten
34 Hagefen St.
Karnei Shomron,  4485500
Israel

EMail: wyaacov@gmail.com


Sam Aldrin
Huawei Technologies
2330 Central Expressway
Santa Clara, CA  95050
United States

EMail: aldrin.ietf@gmail.com


Ping Pan
Infinera

EMail: ppan@infinera.com


Jeong-dong Ryoo
ETRI
218 Gajeongno
Yuseong, Daejeon  305-700
South Korea

EMail: ryoo@etri.re.kr


Greg Mirsky
Ericsson

EMail: gregory.mirsky@ericsson.com
📦 where this page comes from