RFC 7190

Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP)

📅 published March 2014, from ietf

RFC 7190: Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) 🎀

  • Who wrote it: C. Villamizar, from Outer Cape Cod Network Consulting 💖
  • Stream: IETF (Internet Engineering Task Force) 🌸
  • Category: Informational, so it's published for info and isn't a Standards Track spec 📚
  • Date: March 2014 🗓️
  • ISSN: 2070-1721 ✨
  • Obsoletes / Updates: The title block doesn't list any Obsoletes or Updates entries, so nothing gets replaced or amended here 🦋

Abstract 🦋

Okay so many MPLS implementations have supported multipath techniques, and tons of MPLS deployments have used them, especially in super high-bandwidth stuff like provider IP/MPLS core networks 🌐. MPLS Transport Profile (MPLS-TP) has strongly discouraged multipath, and ngl, some degradation of MPLS-TP Operations, Administration, and Maintenance (OAM) performance can't be avoided when you run it over many kinds of multipath implementations 😭.

Here's the plot twist 💅: using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths (LSPs) can ride over multipath links while still giving you a fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document describes how to support MPLS as a server layer for MPLS-TP ✨. It also talks about using MPLS-TP LSPs as a server layer for MPLS LSPs 🫶.

Status of This Memo 📝

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7190.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  MPLS as a Server Layer for MPLS-TP  . . . . . . . . . . . . .   5
  3.1.  MPLS-TP Forwarding and Server-Layer Requirements  . . . .   5
  3.2.  Methods of Supporting MPLS-TP Client LSPs over MPLS . . .   7
4.  MPLS-TP as a Server Layer for MPLS  . . . . . . . . . . . . .  11
5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  13

1. Introduction 🌈

Today, the need to handle big aggregations of traffic can be met by a bunch of techniques that we'll collectively call "multipath" 🚀. Multipath on parallel links between the same set of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link bundling [RFC4201], or other aggregation techniques, and some of those could be vendor specific 🔧. Multipath over diverse paths instead of parallel links includes Equal-Cost Multipath (ECMP) as applied to OSPF, IS-IS, or BGP, plus equal-cost Label Switched Paths (LSPs) 🛣️. Some vendors support load splitting across equal-cost MPLS LSPs, where the load is split proportionally to the reserved bandwidth of the set of LSPs 📊.

RFC 5654 requirement 33 requires the capability to carry a client MPLS Transport Profile (MPLS-TP) or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. This is possible in all cases with one exception 🙈. When an MPLS LSP exceeds the capacity of any single component link, it MAY be carried by a network using multipath techniques, but it SHOULD NOT be carried by a single MPLS-TP LSP 😭. That's because of the inherent MPLS-TP capacity limitation caused by OAM fate-sharing constraints and MPLS-TP Loss Measurement OAM packet-ordering constraints (see Section 3.1) 🧐. Instead, multiple MPLS-TP LSPs SHOULD be used to carry a large MPLS LSP (see Section 4) 💅.

The term "composite link" is broader than terms like "link aggregation" (which is specific to Ethernet) or "ECMP" (which implies equal-cost paths within a routing protocol) 💖. Using "composite link" here matches the broad definition in [ITU-T.G.800]. Multipath is very similar to the composite link defined by ITU-T, but it specifically excludes inverse multiplexing 🙅‍♀️.

MPLS LSPs today can function as a server layer and carry client MPLS LSPs ✨. When control-plane signaling is used, forwarding adjacency (FA) advertisements tell the set of Label Switching Routers (LSRs) about Packet Switching Capable (PSC) LSPs in the MPLS topology [RFC4206]. Client MPLS LSPs at a higher layer (lower PSC number) can signal that they want to use PSC LSPs as hops in the RSVP-TE Explicit Route Object (ERO) 🦋. LSRs with no explicit support for RFC 4206 see the PSC LSPs as ordinary links and therefore use them 🤷‍♀️.

An MPLS LSP that has been set up using RSVP-TE looks, to its ingress LSR, like a viable IP next hop to a distant LSR 🌸. If LDP is used and bidirectional RSVP-TE LSP connectivity is available, LDP signaling can be set up among the RSVP-TE LSP endpoints, and LDP can use the RSVP-TE LSP as an LDP hop. This is another existing form of MPLS-in-MPLS use 🪞. MPLS LSPs may also make use of hierarchy that is configured through the management plane rather than signaled using RSVP-TE 🗺️.

These existing forms of MPLS-in-MPLS may traverse multipath hops such as an Ethernet Link Aggregation Group (LAG) [IEEE-802.1AX] or MPLS Link Bundling [RFC4201] 🧩. MPLS-TP brings a new set of requirements that weren't considered in past deployments of the various forms of MPLS-in-MPLS where multipath was in use 👀. This document only discusses using existing forwarding and protocol mechanisms that can support the case where either the client-layer LSPs or the server-layer LSPs are MPLS-TP and multipath is used 🫶.

2. Definitions 📖

Please refer to the terminology related to multipath introduced in [ADV-MULTIPATH-REQ]. The following additional terms are used in this document, and related terms are grouped together 🗃️.

Link Bundle 🍓 Link bundling is a multipath technique specific to MPLS [RFC4201]. Link bundling supports two modes of operation. Either an LSP can be placed on one component link of a link bundle, or an LSP can be load-split across all members of the bundle. There is no signaling defined that allows a per-LSP preference regarding load split, so whether to load split is generally configured per bundle and applied to all LSPs across the bundle 🔗.

All-Ones Component 💜 Within the context of link bundling, [RFC4201] defines a special case where the same label is to be valid across all component links. This case is indicated in signaling by a bit value of "all ones" when identifying a component link. Following the publication of RFC 4201, this special case has been referred to as the "all-ones component" for brevity 1️⃣.

Equal-Cost Multipath (ECMP) 🌟 Equal-Cost Multipath (ECMP) is a specific form of multipath in which the costs of the links or paths must be equal in a given routing protocol. The load may be split equally across all available links (or available paths), or the load may be split proportionally to the capacity of each link (or path) ⚖️.

Loop-Free Alternate Paths (LFA) 🔁 "Loop-free alternate paths" (LFA) are defined in Section 5.2 of RFC 5714 [RFC5714] as follows: "Such a path exists when a direct neighbor of the router adjacent to the failure has a path to the destination that can be guaranteed not to traverse the failure." Further detail can be found in [RFC5286]. LFA as defined for IP Fast Reroute (IPFRR) can be used to load balance by relaxing the equal-cost criteria of ECMP, though IPFRR defined LFA for use in selecting protection paths. When used with IP, proportional split is generally not used. LFA use in load balancing is implemented by some vendors, though it may be rare or non-existent in deployments 🛡️.

Link Aggregation 🧷 The term "link aggregation" generally refers to Ethernet Link Aggregation as defined by [IEEE-802.1AX]. Ethernet Link Aggregation defines a Link Aggregation Control Protocol (LACP) which coordinates inclusion of Link Aggregation Group (LAG) members in the LAG 🤝.

Link Aggregation Group (LAG) 🫧 A group of physical Ethernet interfaces that are treated as a logical link when using Ethernet Link Aggregation is referred to as a Link Aggregation Group (LAG) 💫.

LAG Member 🧑‍🤝‍🧑 Ethernet Link Aggregation as defined in [IEEE-802.1AX] refers to an individual link in a LAG as a LAG member. A LAG member is a component link. An Ethernet LAG is a composite link. IEEE does not use the terms "composite link" or "component link" 🙃.

A small set of requirements is discussed. These requirements make use of keywords such as MUST and SHOULD as described in [RFC2119] 🥹.

3. MPLS as a Server Layer for MPLS-TP 🧚

An MPLS LSP may be used as a server layer for MPLS-TP LSPs as long as all MPLS-TP requirements are met 💖. Section 3.1 reviews the basis for requirements of a server layer that supports MPLS-TP as a client layer. Key requirements include OAM "fate-sharing" and that packets within an MPLS-TP LSP (including both payload and OAM packets) not be reordered 🌈. Section 3.2 discusses implied requirements where MPLS is the server layer for MPLS-TP client LSPs, and describes a set of solutions that use existing MPLS mechanisms 🔧.

3.1. MPLS-TP Forwarding and Server-Layer Requirements ✨

okay so bestie, [RFC5960] is the one that lays out the data-plane rules for MPLS-TP 🦋 Two paragraphs from its Section 3.1.1 ("LSP Packet Encapsulation and Forwarding") are lowkey the main ones:

RFC 5960, Section 3.1.1, Paragraph 3
    Except for transient packet reordering that may occur, for
    example, during fault conditions, packets are delivered in order
    on L-LSPs, and on E-LSPs within a specific ordered aggregate.
RFC 5960, Section 3.1.1, Paragraph 6
    Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed
    on an MPLS-TP LSP.  MPLS-TP LSPs as defined in this document MAY
    operate over a server layer that supports load-balancing, but
    this load-balancing MUST operate in such a manner that it is
    transparent to MPLS-TP.  This does not preclude the future
    definition of new MPLS-TP LSP types that have different
    requirements regarding the use of ECMP in the server layer.

So [RFC5960], Section 3.1.1, Paragraph 3 says packets in a specific ordered aggregate get delivered in order 💅 and that same rule already shows up in Differentiated Services [RFC2475] 🌸 Then [RFC5960], Section 3.1.1, Paragraph 6 is the ECMP one: no ECMP load-balancing on an MPLS-TP LSP itself 🙈 but a server layer is allowed to use ECMP as long as it stays transparent to the MPLS-TP client layer ✨ It's giving layers that don't bother each other 🫶

[RFC6371] adds a fate-sharing requirement for data traffic and OAM traffic 🔥 Here's the Section 1 ("Introduction") paragraph that sums it up:

RFC 6371, Section 1, Paragraph 7
    OAM packets that instrument a particular direction of a transport
    path are subject to the same forwarding treatment (i.e., fate-
    share) as the user data packets and in some cases, where
    Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may be
    required to have common per-hop behavior (PHB) Scheduling Class
    (PSC) End-to-End (E2E) with the class of traffic monitored.  In
    case of Label-Only-Inferred-PSC LSP (L-LSP), only one class of
    traffic needs to be monitored, and therefore the OAM packets have
    common PSC with the monitored traffic class.

Basically, OAM packets that check a transport path in a given direction get the same forwarding treatment as the user data 👑 With E-LSPs there may be a need for a common PHB and PSC end to end with the traffic being monitored 💜 With L-LSPs, only one traffic class needs monitoring, so the OAM packets share its PSC 🌈

[RFC6371] doesn't ban multilink techniques, which it covers in Section 4.6 ("Fate-Sharing Considerations for Multilink") 🦋 In that section, multilink means Ethernet Link Aggregation and Link Bundling for MPLS 🍓 The catch is that it does say such a network would only be partially MPLS-TP compliant 💀 The bit to avoid is this sentence:

RFC 6371, Section 4.6, Paragraph 1, last sentence
    These techniques frequently share the characteristic that an LSP
    may be spread over a set of component links and therefore be
    reordered, but no flow within the LSP is reordered (except when
    very infrequent and minimally disruptive load rebalancing
    occurs).

Honestly though, saying Link Bundling for MPLS gives you a partially MPLS-TP-compliant network might be a bit much 😭 Only the Link Bundling all-ones component link has that characteristic, so the blanket label feels overstated 🙈

[RFC6374] defines a direct Loss Measurement (LM) where LM OAM packets can't be reordered relative to payload packets 🧚 That means the payload packets themselves can't get reordered either 🎀 Section 2.9.4 ("Equal Cost Multipath") explains why, and this is the paragraph:

RFC 6374, Section 2.9.4, Paragraph 2
    The effects of ECMP on loss measurement will depend on the LM
    mode.  In the case of direct LM, the measurement will account for
    any packets lost between the sender and the receiver, regardless
    of how many paths exist between them.  However, the presence of
    ECMP increases the likelihood of misordering both of LM messages
    relative to data packets and of the LM messages themselves.  Such
    misorderings tend to create unmeasurable intervals and thus
    degrade the accuracy of loss measurement.  The effects of ECMP
    are similar for inferred LM, with the additional caveat that,
    unless the test packets are specially constructed so as to probe
    all available paths, the loss characteristics of one or more of
    the alternate paths cannot be accounted for.

The gist: with direct LM, lost packets get counted no matter how many paths there are, but ECMP makes misordering more likely for both LM messages and data packets 🌸 Those misorderings create unmeasurable gaps and make the loss numbers less accurate 📉 Inferred LM has the same ECMP issue, plus the alternate paths' loss can't be counted unless the test packets are built to probe every path 🔍

3.2. Methods of Supporting MPLS-TP Client LSPs over MPLS ✨

Okay bestie, so running MPLS-TP LSPs over a fully MPLS-TP conformant MPLS LSP server layer, where those server LSPs are using multipath, needs some special treatment 💅. The MPLS-TP LSPs have to meet the MPLS-TP forwarding requirements (see Section 3.1) or it's a no-go 🙈. Here's the short list of requirements, and they're kind of iconic 🎀:

  • MP#1 It MUST be possible for a midpoint MPLS-TP Label Switching Router (LSR) that is acting as ingress to a server-layer MPLS LSP to identify MPLS-TP LSPs, so the MPLS-TP forwarding requirements can be applied, or to otherwise accommodate those requirements. 🦋
  • MP#2 Being able to completely exclude MPLS-TP LSPs from the multipath hash and load split SHOULD be supported. If the selected component link no longer meets the requirements, the LSP is considered down, which may trigger protection and/or may require that the ingress LSR select a new path and signal a new LSP. 💔
  • MP#3 It SHOULD be possible to make sure MPLS-TP LSPs won't get moved to another component link because of a load-rebalancing operation for multipath. If the selected component link no longer meets the requirements, another component link may be selected; however, a change in path SHOULD NOT happen just for load balancing. ⚖️
  • MP#4 Where a Resource Reservation Protocol - Traffic Engineering (RSVP-TE) control plane is used, it MUST be possible for an ingress LSR that is setting up an MPLS-TP or an MPLS LSP to determine, at path selection time, whether a link or Forwarding Adjacency (FA; see [RFC4206]) within the topology can support the MPLS-TP requirements of the LSP. 🧚

So why is MP#1 even a thing? Not obvious at all, ngl 🙃. An MPLS-TP LSP can get bundled up with other client LSPs by a midpoint LSR into one super huge MPLS server-layer LSP, like a core-node-to-core-node MPLS LSP between major cities 🌆. In that situation, the ingress of the MPLS LSP is a midpoint LSR for a bunch of client LSPs, and it has no signaling mechanism to figure out whether one specific client LSP is using MPLS or MPLS-TP 😭. Multipath load splitting can be avoided for MPLS-TP LSPs if, at the server-layer MPLS LSP ingress LSR, an Entropy Label Indicator (ELI) and Entropy Label (EL) get added to the label stack by the midpoint LSR for the client MPLS-TP LSP, at the ingress of the MPLS LSP [RFC6790]. For client LSPs that are MPLS-TP LSPs, a single per-LSP EL value must be chosen. For client LSPs that are MPLS LSPs, per-packet entropy below the top label must, for practical reasons, be used to determine the entropy label value. The resulting label stack has the server MPLS LSP label, ELI, EL and the client LSP label. Requirement MP#1 basically just says there has to be a way to make this decision 🔥.

Right now there's no signaling mechanism defined to support MP#1, but that doesn't rule out a new extension being defined later 🌈. Without a signaling extension, MPLS-TP can be identified through some form of configuration, like configuration that gives an MPLS-TP-compatible server layer to all LSPs arriving on a specific interface or coming from a specific set of ingress LSRs 🎀.

Also, the need for MP#1 can be wiped out entirely if every MPLS-TP LSP created by an MPLS-TP ingress uses an Entropy Label Indicator (ELI) and Entropy Label (EL) below the MPLS-TP label [RFC6790]. The catch is that every MPLS-TP LSR in a deployment would need to support Entropy Label, which may make this totally impractical in lots of deployments 😬.

Some hardware that exists today can already do MP#2 💅. Signaling without MPLS Entropy Labels can use link bundling with the path pinned to a specific component for MPLS-TP LSPs, and link bundling using the all-ones component for MPLS LSPs. This stops MPLS-TP LSPs from being carried within MPLS LSPs, but it does let MPLS-TP and very large MPLS LSPs coexist 🧡.

When Entropy Label Indicators (ELIs) and Entropy Labels (ELs) aren't applied by MPLS-TP ingresses, MPLS-TP LSPs can still be carried as client LSPs within an MPLS server LSP. The trick is for the server-layer LSP's ingress to push an Entropy Label Indicator (ELI) and Entropy Label (EL) below the server-layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]. The EL value can be randomly picked when the client MPLS-TP LSP is set up, and that same EL value can be used for all packets of that MPLS-TP LSP. This lets MPLS-TP LSPs ride as client LSPs inside MPLS LSPs and still satisfy the MPLS-TP forwarding requirements, but it does require that MPLS LSRs can identify MPLS-TP LSPs (requirement MP#1) 🦋.

MPLS-TP traffic can be protected from degraded performance caused by an imperfect load split if the MPLS-TP traffic gets queuing priority 👑. For example, that could be done using (1) strict priority and policing, shaping at ingress, or per-LSP shaping locally, or (2) per-LSP weighted queuing locally. This can be done using the Traffic Class (TC) field and Diffserv treatment of traffic [RFC5462] [RFC2475]. If congestion happens because of load imbalance, only the non-prioritized traffic will suffer, as long as the percentage of prioritized traffic stays low 🍓.

If MPLS-TP LSPs are carried within MPLS LSPs and ELI and EL are used, requirement MP#3 is satisfied (1) for uncongested links where load balancing isn't required, or (2) for MPLS-TP LSPs using Traffic Class (TC) and Diffserv, where the load rebalancing implementation only rebalances the less preferred traffic 💜. Load rebalancing is generally only needed when congestion happens, so restricting MPLS-TP to be carried over MPLS LSPs that are known to only traverse links that are expected to be uncongested can satisfy requirement MP#3 ✨.

An MPLS-TP LSP can be pinned to a Link Bundle component link if the behavior of requirement MP#2 is preferred. An MPLS-TP LSP can be assigned to a Link Bundle but not pinned if the behavior of requirement MP#3 is preferred. In both of these cases, the MPLS-TP LSP must be the top-level LSP, except as noted above 🫶.

If MPLS-TP LSPs can be moved among component links, then either the Link Bundle all-ones component link can be used, or server-layer MPLS LSPs can be used with no restrictions on the server-layer MPLS use of multipath. The only catch is that Entropy Labels must be supported along the entire path. An Entropy Label must be used to make sure all of the MPLS-TP payload and OAM traffic is carried on the same component, except during very infrequent transitions due to load balancing. Since the Entropy Label Indicator and Entropy Label are always placed above the Generic Associated Channel Label (GAL) in the stack, the presence of a GAL won't affect the selection of a component link, as long as the LSR doesn't hash on the label stack entries below the Entropy Label 🌸.

An MPLS-TP LSP may not traverse multipath links on the path where MPLS-TP forwarding requirements can't be met 🚫. Those links include any using pre-[RFC6790] Ethernet Link Aggregation, pre-[RFC6790] Link Bundling using the all-ones component link, or any other form of multipath that doesn't support terminating the entropy search at the EL, as called for in [RFC6790]. An MPLS-TP LSP MUST NOT traverse a server-layer MPLS LSP that traverses any form of multipath that does not support termination of the entropy search at the EL. For this to be avoided, the MPLS-TP ingress LSR MUST be aware of these links. That's the whole reason MP#4 exists 💀.

Requirement MP#4 can be supported using administrative attributes. Administrative attributes are defined in [RFC3209]. Some configuration is required to make this work 🛠️.

In MPLS Link Bundling, the requirement for bidirectional co-routing can be read as meaning the same set of LSRs must be traversed, or it can be read as meaning the same set of component links must be traversed [RFC4201] [RFC3473]. Following the procedures of Section 3 of RFC 3473 where Link Bundling is used only makes sure the same set of LSRs are traversed and that acceptable labels get created in each direction 🎀.

When an MPLS-TP LSP is set up over an MPLS LSP, and the MPLS-TP LSP is bidirectional, providers who only want these MPLS-TP LSPs set up over bidirectional co-routed MPLS LSPs can use administrative attributes [RFC3209] to make sure that happens 🦋. If MPLS-TP LSPs are carried by unidirectional MPLS LSPs, the MPLS-TP OAM will be unaffected, since only the MPLS LSP endpoints will show up as MPLS-TP OAM Maintenance Entity Group Intermediate Points (MIPs) 🧚.

Two ways of adding an Entropy Label were described above. The MPLS-TP ingress needs a way to figure out which links can support MPLS-TP when picking a path (MP#4), and administrative attributes can cover that. If the MPLS-TP LSR can add ELI/EL to the label stack, that method is preferred. However, equipment furthest from a provider's network core is the least likely to support RFC 6790 in the near term 🥺. For parts of the topology where MPLS-TP is carried within a server-layer MPLS LSP, the ingress of the server-layer MPLS LSP can add ELI/EL using a fixed EL value per client LSP, except for those known not to need MPLS-TP treatment. There are plenty of ways to figure out which client LSPs are MPLS-TP LSPs and which aren't. That determination is out of scope and will vary between deployments, but configuration or the presence of specific attribute affinities in RSVP-TE signaling are among the likely ways to do it 💖.

4. MPLS-TP as a Server Layer for MPLS ✨

Okay so, carrying MPLS LSPs that are bigger than a single component link over an MPLS-TP server layer means the big client-layer LSP has to be squeezed into multiple server-layer LSPs 🧚. Multipath can be used in the client-layer MPLS, and that's the move 💅.

But here's the catch 🙈. Making multiple server-layer LSPs puts a bigger ILM scaling burden on the LSR. The vibe is that high-bandwidth MPLS cores with fewer nodes are the ones most likely to need LSPs bigger than component links, so having fewer nodes actually balances out the extra server-layer LSPs running in parallel 🫶. Today, this only becomes an issue where the deployed LSR ILMs are small 💀.

The biggest downside is that using MPLS-TP as a server layer makes carrying the MPLS client layer less efficient 😭. The thing with the largest offered load in provider networks is the Internet, and its LSP capacity reservations are basically predictions of expected load 🔮. A lot of these MPLS LSPs are smaller than a component link, so using MPLS-TP as a server layer creates bin-packing problems for them 📦. The bigger LSPs don't have to be (and often aren't) integer multiples of handy capacity steps like 10 Gbit/s, which is extra messy 🙃. Basically, using MPLS-TP as the underlying server layer really hurts the client-layer MPLS LSPs' ability to share capacity 😤. For example, if one MPLS LSP is underusing its predicted capacity, the fixed allocation of MPLS-TP to component links might not let another LSP go over its predicted capacity 🥺. So the resources might get used less efficiently, and the network might end up being less cost-effective 💸.

No additional requirements beyond MPLS-TP as it is currently defined are required to support MPLS-TP as a server layer for MPLS. So it's viable, but it has some undesirable characteristics we just talked about 🌸.

5. Summary 🌈

Okay, recap time 📝. MPLS equipment deployed in the core already supports multipath 🔥. For big service providers, the core LSR has to support some form of multipath to be deployable 👑. Deployed MPLS access and edge equipment is often totally oblivious to multipath in the core 🙈. It's expected that at least first-generation MPLS-TP equipment will be oblivious to multipath in the core too. This first-generation MPLS-TP equipment can be deployed in a core using multipath, with no adverse impact to RSVP-TE signaling, if:

  1. the edge equipment can support administrative attributes (RFC 3209),
  2. the core equipment can support ELI/EL, and
  3. the core equipment can put a per-LSP fixed EL value on any LSP that indicates a particular attribute affinity or can identify a client MPLS-TP LSP through some other means.

Bestie, there are no issues carrying MPLS over MPLS-TP, except when the MPLS LSP is too big for a single MPLS-TP LSP to carry 🥹. Most MPLS core equipment and some edge equipment can configure an MPLS Link Bundle [RFC4201] over multiple component links, where the component links are themselves MPLS LSPs 🦋. This already-existing capability can be used to carry large MPLS LSPs and get around the limited capacity of any single server-layer MPLS-TP LSP 💖.

MPLS OAM and MPLS-TP OAM are unaffected in the following cases proposed in this document ✨:

  1. Where MPLS is carried over a single MPLS-TP, all traffic flows on one link, MPLS OAM is unaffected and need not use multipath support in LSP Ping [RFC4379].
  2. Where MPLS-TP is carried over MPLS, all traffic for that MPLS-TP LSP is carried over one link thanks to the fixed EL value. In this case, MPLS-TP OAM is unaffected.
  3. Where MPLS LSPs are carried over MPLS LSPs (an existing case) or over multiple MPLS-TP LSPs, the multipath support in LSP Ping is used and LSP Ping operation is unaffected [RFC4379] [RFC6425].

6. Acknowledgements 🫶

Huge shoutout to Carlos Pignataro, Dave Allan, and Mach Chen for providing valuable comments and suggestions 💜. Carlos suggested that the MPLS-TP requirements in RFC 5960 be explicitly referenced or quoted 📚. An email conversation with Dave led to the inclusion of references and quotes from RFCs 6371 and 6374 💌. And Mach made suggestions to improve the clarity of the document ✨. Literally the best squad 👑.

7. Security Considerations 🔐

Okay, security time, and this part is important 🚨. This document specifies the use of existing MPLS and MPLS-TP mechanisms to support MPLS and MPLS-TP as client and server layers for each other 🔁. This use of existing mechanisms supports coexistence of MPLS/GMPLS (without MPLS-TP) when used over a packet network, MPLS-TP, and multipath 🌐. The combination of MPLS, MPLS-TP, and multipath does not introduce any new security threats 🛡️. The security considerations for MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [RFC6941] 📖.

8. References 📚

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.

[RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.

[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.

[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.

[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, November 2012.

8.2. Informative References

[ADV-MULTIPATH-REQ] Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. Yong, "Requirements for Advanced Multipath in MPLS Networks", Work in Progress, February 2014.

[IEEE-802.1AX] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", IEEE Std 802.1AX-2008, 2006, <http://standards.ieee.org/getieee802/download/802.1AX-2008.pdf>.

[ITU-T.G.800] ITU-T, "Unified functional architecture of transport networks", ITU-T G.800, 2007, <http://www.itu.int/rec/T-REC-G/recommendation.asp?parent=T-REC-G.800>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.

[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.

[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008.

[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, February 2009.

[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010.

[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.

[RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, November 2011.

[RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. Graveman, "MPLS Transport Profile (MPLS-TP) Security Framework", RFC 6941, April 2013.

Author's Address 🦋

Curtis Villamizar Outer Cape Cod Network Consulting

EMail: curtis@occnc.com

📦 where this page comes from