diff options
Diffstat (limited to 'doc/rfc/rfc7190.txt')
| -rw-r--r-- | doc/rfc/rfc7190.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc7190.txt b/doc/rfc/rfc7190.txt new file mode 100644 index 0000000..1591926 --- /dev/null +++ b/doc/rfc/rfc7190.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Villamizar +Request for Comments: 7190 Outer Cape Cod Network Consulting +Category: Informational March 2014 +ISSN: 2070-1721 + + + Use of Multipath with MPLS and MPLS Transport Profile (MPLS-TP) + +Abstract + + Many MPLS implementations have supported multipath techniques, and + many MPLS deployments have used multipath techniques, particularly in + very high-bandwidth applications, such as provider IP/MPLS core + networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged + the use of multipath techniques. Some degradation of MPLS-TP + Operations, Administration, and Maintenance (OAM) performance cannot + be avoided when operating over many types of multipath + implementations. + + Using MPLS Entropy Labels (RFC 6790), MPLS Label Switched Paths + (LSPs) can be carried over multipath links while also providing a + fully MPLS-TP-compliant server layer for MPLS-TP LSPs. This document + describes the means of supporting MPLS as a server layer for MPLS-TP. + The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also + discussed. + +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. + + + + + + + + + + +Villamizar Informational [Page 1] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + +Copyright Notice + + 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 requirement to handle large aggregations of traffic can be + met by a number of techniques that we will collectively call + "multipath". Multipath applied to parallel links between the same + set of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link + bundling [RFC4201], or other aggregation techniques, some of which + could be vendor specific. Multipath applied to diverse paths rather + than parallel links includes Equal-Cost Multipath (ECMP) as applied + to OSPF, IS-IS, or BGP, and 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 + + + +Villamizar Informational [Page 2] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + component link, it MAY be carried by a network using multipath + techniques, but it SHOULD NOT be carried by a single MPLS-TP LSP due + to the inherent MPLS-TP capacity limitation imposed by MPLS-TP + Operations, Administration, and Maintenance (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 more general than terms such as "link + aggregation" (which is specific to Ethernet) or "ECMP" (which implies + equal-cost paths within a routing protocol). The use of the term + "composite link" here is consistent with the broad definition in + [ITU-T.G.800]. Multipath is very similar to composite link as + defined by ITU-T but specifically excludes inverse multiplexing. + + MPLS LSPs today are able to function as a server layer and carry + client MPLS LSPs. When control-plane signaling is used, forwarding + adjacency (FA) advertisements are used to inform the set of Label + Switching Routers (LSRs) of Packet Switching Capable (PSC) LSPs + within the MPLS topology [RFC4206]. Client MPLS LSP at a higher + layer (lower PSC number) may signal their intention 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 appears to its ingress + LSR as a viable IP next hop to a distant LSR. If LDP is used and + bidirectional RSVP-TE LSP connectivity is available, then LDP + signaling can be set up among the RSVP-TE LSP endpoints, and LDP can + make use of the RSVP-TE LSP as an LDP hop. This is another form of + existing 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 Ethernet Link Aggregation Group (LAG) [IEEE-802.1AX] or MPLS Link + Bundling [RFC4201]. MPLS-TP brings with it a new set of requirements + not considered in past deployments of the various forms of MPLS-in- + MPLS where multipath was in use. This document merely discusses use + of 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 where multipath is used. + + + + + + + + + +Villamizar Informational [Page 3] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + +2. Definitions + + Please refer to the terminology related to multipath introduced in + [ADV-MULTIPATH-REQ]. The following additional terms are used in this + document; related terms are grouped together. + + Link Bundle + Link bundling is a multipath technique specific to MPLS + [RFC4201]. Link bundling supports two modes of operations. + 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, therefore 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, for brevity this special case has been + referred to as the "all-ones component". + + 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. + + + + + + + + +Villamizar Informational [Page 4] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + 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 are 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 + + [RFC5960] defines the data-plane requirements for MPLS-TP. Two very + relevant paragraphs in Section 3.1.1 ("LSP Packet Encapsulation and + Forwarding") are the following: + + 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. + + + + + + + + + +Villamizar Informational [Page 5] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + 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. + + [RFC5960], Section 3.1.1, Paragraph 3 requires that packets within a + specific ordered aggregate be delivered in order. This same + requirement is already specified by Differentiated Services + [RFC2475]. [RFC5960], Section 3.1.1, Paragraph 6 explicitly allows a + server layer to use ECMP, provided that it is transparent to the + MPLS-TP client layer. + + [RFC6371] adds a requirement for data traffic and OAM traffic "fate- + sharing". The following paragraph in Section 1 ("Introduction") + summarizes this requirement. + + 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. + + [RFC6371] does not prohibit multilink techniques in Section 4.6 + ("Fate-Sharing Considerations for Multilink"), where multilink is + defined as Ethernet Link Aggregation and the use of Link Bundling for + MPLS, but it does declare that such a network would be only partially + MPLS-TP compliant. The characteristic that is to be avoided is + contained in the following sentence in that section. + + 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). + + A declaration that implies that Link Bundling for MPLS yields a + partially MPLS-TP-compliant network is perhaps overstated since only + the Link Bundling all-ones component link has this characteristic. + + + +Villamizar Informational [Page 6] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + [RFC6374] defines a direct Loss Measurement (LM) where LM OAM packets + cannot be reordered with respect to payload packets. This will + require that payload packets themselves not be reordered. The + following paragraph in Section 2.9.4 ("Equal Cost Multipath") gives + the reason for this restriction. + + 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. + +3.2. Methods of Supporting MPLS-TP Client LSPs over MPLS + + Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS LSP + server layer where the MPLS LSPs are making use of multipath requires + special treatment of the MPLS-TP LSPs such that those LSPs meet MPLS- + TP forwarding requirements (see Section 3.1). This implies the + following brief set of requirements. + + MP#1 It MUST be possible for a midpoint MPLS-TP Label Switching + Router (LSR) that is serving as ingress to a server-layer MPLS + LSP to identify MPLS-TP LSPs, so that MPLS-TP forwarding + requirements can be applied, or to otherwise accommodate the + MPLS-TP forwarding requirements. + + MP#2 The ability to completely exclude MPLS-TP LSPs from the + multipath hash and load split SHOULD be supported. If the + selected component link no longer meets requirements, an 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 ensure that MPLS-TP LSPs will not be + moved to another component link as a result of a load- + rebalancing operation for multipath. If the selected component + link no longer meets requirements, another component link may + be selected; however, a change in path SHOULD NOT occur solely + for load balancing. + + + + +Villamizar Informational [Page 7] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + 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. + + The reason for requirement MP#1 may not be obvious. An MPLS-TP LSP + may be aggregated along with other client LSPs by a midpoint LSR into + a very large MPLS server-layer LSP, as would be the case in a core- + node-to-core-node MPLS LSP between major cities. In this case, the + ingress of the MPLS LSP, being a midpoint LSR for a set of client + LSPs, has no signaling mechanism that can be used to determine + whether one of its specific client LSPs is using MPLS or MPLS-TP. + Multipath load splitting can be avoided for MPLS-TP LSPs if at the + MPLS server-layer LSP ingress LSR an Entropy Label Indicator (ELI) + and Entropy Label (EL) are added to the label stack by the midpoint + LSR for the client MPLS-TP LSP, at the ingress of the MPLS LSP + [RFC6790]. For those client LSPs that are MPLS-TP LSPs, a single + per-LSP EL value must be chosen. For those 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 contains the server MPLS LSP label, ELI, EL and the + client LSP label. Requirement MP#1 simply states that there must be + a means to make this decision. + + There is currently no signaling mechanism defined to support + requirement MP#1, though that does not preclude a new extension being + defined later. In the absence of a signaling extension, MPLS-TP can + be identified through some form of configuration, such as + configuration that provides an MPLS-TP-compatible server layer to all + LSPs arriving on a specific interface or originating from a specific + set of ingress LSRs. + + Alternatively, the need for requirement MP#1 can be eliminated if + every MPLS-TP LSP created by an MPLS-TP ingress makes use of an + Entropy Label Indicator (ELI) and Entropy Label (EL) below the MPLS- + TP label [RFC6790]. This would require that all MPLS-TP LSRs in a + deployment support Entropy Label, which may render it impractical in + many deployments. + + Some hardware that exists today can support requirement MP#2. + Signaling in the absence of MPLS Entropy Labels can make use of 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 prevents MPLS-TP LSPs from being carried within MPLS LSPs but + does allow the coexistence of MPLS-TP and very large MPLS LSPs. + + + + +Villamizar Informational [Page 8] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + When Entropy Label Indicators (ELIs) and Entropy Labels (ELs) are not + applied by MPLS-TP ingresses, MPLS-TP LSPs can be carried as client + LSPs within an MPLS server LSP if the ingress of the MPLS server- + layer LSP pushes 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 value of EL can be + randomly selected at the client MPLS-TP LSP setup time, and the same + EL value can be used for all packets of that MPLS-TP LSP. This + allows MPLS-TP LSPs to be carried as client LSPs within MPLS LSPs and + satisfies MPLS-TP forwarding requirements but requires that MPLS LSRs + be able to identify MPLS-TP LSPs (requirement MP#1). + + MPLS-TP traffic can be protected from degraded performance due to an + imperfect load split if the MPLS-TP traffic is given queuing + priority. For example, using (1) strict priority and policing, + shaping at ingress, or per-LSP shaping locally, or (2) per-LSP + weighted queuing locally. This can be accomplished using the Traffic + Class (TC) field and Diffserv treatment of traffic [RFC5462] + [RFC2475]. In the event of congestion due to load imbalance, only + non-prioritized traffic will suffer as long as there is a low + percentage of prioritized traffic. + + 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 is not required, or (2) for MPLS-TP LSPs using Traffic + Class (TC) and Diffserv, where the load rebalancing implementation + rebalances only the less preferred traffic. Load rebalance is + generally needed only when congestion occurs; therefore, restricting + MPLS-TP to be carried over MPLS LSPs that are known to traverse only + 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 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, except that Entropy Labels must be supported along the + entire path. An Entropy Label must be used to ensure that all of the + MPLS-TP payload and OAM traffic are 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 + + + + +Villamizar Informational [Page 9] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + presence of a GAL will not affect the selection of a component link + as long as the LSR does not 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 cannot be met. Such 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 does not support termination of 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 occur, the MPLS-TP ingress LSR MUST be aware of these links. + This is the reason for requirement MP#4. + + Requirement MP#4 can be supported using administrative attributes. + Administrative attributes are defined in [RFC3209]. Some + configuration is required to support this. + + In MPLS Link Bundling the requirement for bidirectional co-routing + can be interpreted as meaning that the same set of LSRs must be + traversed or can be interpreted to mean that 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 + ensures that the same set of LSRs are traversed and that acceptable + labels are created in each direction. + + When an MPLS-TP LSP is set up over a MPLS LSP, if the MPLS-TP LSP is + a bidirectional LSP, then providers who want to only set these MPLS- + TP LSPs over bidirectional co-routed MPLS LSPs can make use of + administrative attributes [RFC3209] to ensure that this occurs. If + MPLS-TP LSPs are carried by unidirectional MPLS LSPs, the MPLS-TP OAM + will be unaffected, as only the MPLS LSP endpoints will appear as + MPLS-TP OAM Maintenance Entity Group Intermediate Points (MIPs). + + Two methods of adding an Entropy Label are described above. The + MPLS-TP ingress must have a means to determine which links can + support MPLS-TP in selecting a path (MP#4). Administrative + attributes can satisfy that requirement. If the MPLS-TP LSR is + capable of adding ELI/EL to the label stack, this 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 + portions of the topology where an 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 those known not to + require MPLS-TP treatment. There are numerous ways to determine + which client LSPs are MPLS-TP LSPs and which are not. While this + + + + +Villamizar Informational [Page 10] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + determination is out of scope and will vary among deployments, + configuration or the presence of specific attribute affinities in + RSVP-TE signaling are among the likely means to do so. + +4. MPLS-TP as a Server Layer for MPLS + + Carrying MPLS LSPs that are larger than a component link over an + MPLS-TP server layer requires that the large MPLS client-layer LSP be + accommodated by multiple MPLS-TP server-layer LSPs. MPLS multipath + can be used in the client-layer MPLS. + + Creating multiple MPLS-TP server-layer LSPs places a greater Incoming + Label Map (ILM) scaling burden on the LSR. High-bandwidth MPLS cores + with a smaller amount of nodes have the greatest tendency to require + LSPs in excess of component links; therefore, the reduction in the + number of nodes offsets the impact of increasing the number of + server-layer LSPs in parallel. Today, only in cases where deployed + LSR ILMs are small would this be an issue. + + The most significant disadvantage of MPLS-TP as a server layer for + MPLS is that the use of MPLS-TP server-layer LSPs reduces the + efficiency of carrying the MPLS client layer. The service that + provides by far the largest offered load in provider networks is the + Internet, for which the LSP capacity reservations are predictions of + expected load. Many of these MPLS LSPs may be smaller than component + link capacity. Using MPLS-TP as a server layer results in bin- + packing problems for these smaller LSPs. For those LSPs that are + larger than component link capacity, the LSP capacities need not be + (and often are not) integer multiples of convenient capacity + increments such as 10 Gbit/s. Using MPLS-TP as an underlying server + layer greatly reduces the ability of the client-layer MPLS LSPs to + share capacity. For example, when one MPLS LSP is underutilizing its + predicted capacity, the fixed allocation of MPLS-TP to component + links may not allow another LSP to exceed its predicted capacity. + Using MPLS-TP as a server layer may result in less efficient use of + resources and may result in a less cost-effective network. + + No additional requirements beyond MPLS-TP as it is now currently + defined are required to support MPLS-TP as a server layer for MPLS. + It is therefore viable but has some undesirable characteristics + discussed above. + +5. Summary + + MPLS equipment deployed in the core currently supports multipath. + For large service providers, core LSR must support some form of + multipath to be deployable. Deployed MPLS access and edge equipment + is often oblivious to the use of multipath in the core. It is + + + +Villamizar Informational [Page 11] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + expected that at least first-generation MPLS-TP equipment will be + oblivious to the use of multipath in the core. This first-generation + MPLS-TP equipment is deployable 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. + + There are no issues carrying MPLS over MPLS-TP, except when the MPLS + LSP is too big to be carried by a single MPLS-TP LSP. 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 LSP. This existing capability can be used to carry + large MPLS LSPs and overcome 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 + + Carlos Pignataro, Dave Allan, and Mach Chen provided valuable + comments and suggestions. Carlos suggested that 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. Mach made suggestions to improve the + clarity of the document. + + + + + + +Villamizar Informational [Page 12] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + +7. Security Considerations + + This document specifies 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>. + + + + +Villamizar Informational [Page 13] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + [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. + + + + + + +Villamizar Informational [Page 14] + +RFC 7190 MPLS and MPLS-TP Multipath March 2014 + + + [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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Villamizar Informational [Page 15] + |