idnits 2.17.1 draft-ietf-mpls-multipath-use-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 28, 2014) is 3741 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-rtgwg-cl-requirement-15 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS C. Villamizar 3 Internet-Draft Outer Cape Cod Network Consulting 4 Intended status: Informational January 28, 2014 5 Expires: August 01, 2014 7 Use of Multipath with MPLS and MPLS-TP 8 draft-ietf-mpls-multipath-use-04 10 Abstract 12 Many MPLS implementations have supported multipath techniques and 13 many MPLS deployments have used multipath techniques, particularly in 14 very high bandwidth applications, such as provider IP/MPLS core 15 networks. MPLS Transport Profile (MPLS-TP) has strongly discouraged 16 the use of multipath techniques. Some degradation of MPLS-TP 17 Operations, Administration, and Maintenance (OAM) performance cannot 18 be avoided when operating over many types of multipath 19 implementations. 21 Using MPLS Entropy Labels (RFC6790), MPLS Label Switched Paths (LSPs) 22 can be carried over multipath links while also providing a fully 23 MPLS-TP compliant server layer for MPLS-TP LSPs. This document 24 describes the means of supporting MPLS as a server layer for MPLS-TP. 25 The use of MPLS-TP LSPs as a server layer for MPLS LSPs is also 26 discussed. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 01, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. MPLS as a Server Layer for MPLS-TP . . . . . . . . . . . . . 5 65 3.1. MPLS-TP Forwarding and Server Layer Requirements . . . . 5 66 3.2. Methods of Supporting MPLS-TP client LSPs over MPLS . . . 7 67 4. MPLS-TP as a Server Layer for MPLS . . . . . . . . . . . . . 10 68 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 70 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 10.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 Today the requirement to handle large aggregations of traffic can be 81 met by a number of techniques which we will collectively call 82 multipath. Multipath applied to parallel links between the same set 83 of nodes includes Ethernet Link Aggregation [IEEE-802.1AX], link 84 bundling [RFC4201], or other aggregation techniques some of which 85 could be vendor specific. Multipath applied to diverse paths rather 86 than parallel links includes Equal Cost MultiPath (ECMP) as applied 87 to OSPF, IS-IS, or BGP, and equal cost Label Switched Paths (LSPs). 88 Some vendors support load splitting across equal cost MPLS LSPs where 89 the load is split proportionally to the reserved bandwidth of the set 90 of LSPs. 92 RFC 5654 requirement 33 requires the capability to carry a client 93 MPLS Transport Profile (MPLS-TP) or MPLS layer over a server MPLS-TP 94 or MPLS layer [RFC5654]. This is possible in all cases with one 95 exception. When an MPLS LSP exceeds the capacity of any single 96 component link it MAY be carried by a network using multipath 97 techniques, but SHOULD NOT be carried by a single MPLS-TP LSP due to 98 the inherent MPLS-TP capacity limitation imposed by MPLS-TP 99 Operations, Administration, and Maintenance (OAM) fate-sharing 100 constraints and MPLS-TP LM OAM packet ordering constraints (see 101 Section 3.1). Instead, multiple MPLS-TP LSPs SHOULD be used to carry 102 a large MPLS LSP (see Section 4). 104 The term composite link is more general than terms such as link 105 aggregation (which is specific to Ethernet) or ECMP (which implies 106 equal cost paths within a routing protocol). The use of the term 107 composite link here is consistent with the broad definition in 108 [ITU-T.G.800]. Multipath is very similar to composite link as 109 defined by ITU-T, but specifically excludes inverse multiplexing. 111 MPLS LSPs today are able to function as a server layer and carry 112 client MPLS LSPs. When control plane signaling is used, forwarding 113 adjacency (FA) advertisements are used to inform the set of LSR of 114 Packet Switching Capable (PSC) LSP within the MPLS topology 115 [RFC4206]. Client MPLS LSP at a higher layer (lower PSC number) may 116 signal their intention to use PSC LSP as hops in the RSVP-TE Explicit 117 Route Object (ERO). LSR with no explicit support for RFC 4206 see 118 the PSC LSP as ordinary links and therefore use them. 120 An MPLS LSP that has been set up using RSVP-TE appears to its ingress 121 LSR as a viable IP next hop to a distant LSR. If LDP is used and 122 bidirectional RSVP-TE LSP connectivity is available, then LDP 123 signaling can be set up among the RSVP-TE LSP endpoints and LDP can 124 make use of the RSVP-TE LSP as an LDP hop. This is another form of 125 existing MPLS-in-MPLS use. MPLS LSPs may also make use of hierarchy 126 that is configured through the management plane rather than signaled 127 using RSVP-TE. 129 These existing forms of MPLS-in-MPLS may traverse multipath hops such 130 as Ethernet LAG [IEEE-802.1AX] or MPLS Link Bundling [RFC4201]. 131 MPLS-TP brings with it a new set of requirements not considered in 132 past deployments of the various forms of MPLS-in-MPLS where multipath 133 was in use. This document merely discusses use of existing 134 forwarding and protocol mechanisms that can support the case where 135 either the client layer LSPs or the server layer LSPs are MPLS-TP and 136 where multipath is used. 138 2. Definitions 140 Please refer to the terminology related to multipath introduced in 141 [I-D.ietf-rtgwg-cl-requirement]. The following additional terms are 142 used in this document with related terms grouped together. 144 Link Bundle 145 Link bundling is a multipath technique specific to MPLS 146 [RFC4201]. Link bundling supports two modes of operations. 147 Either an LSP can be placed on one component link of a link 148 bundle, or an LSP can be load split across all members of the 149 bundle. There is no signaling defined which allows a per LSP 150 preference regarding load split, therefore whether to load split 151 is generally configured per bundle and applied to all LSPs across 152 the bundle. 154 All-Ones Component 155 Within the context of link bundling, [RFC4201] defines a special 156 case where the same label is to be valid across all component 157 links. This case is indicated in signaling by a bit value of 158 "all ones" when identifying a component link. Following the 159 publication of RFC 4201, for brevity this special case has been 160 referred to as the "all-ones component". 162 Equal Cost Multipath (ECMP) 163 Equal Cost Multipath (ECMP) is a specific form of multipath in 164 which the costs of the links or paths must be equal in a given 165 routing protocol. The load may be split equally across all 166 available links (or available paths), or the load may be split 167 proportionally to the capacity of each link (or path). 169 Loop-Free Alternate Paths (LFA) 170 "Loop-free alternate paths" (LFA) are defined in RFC 5714, 171 Section 5.2 [RFC5714] as follows: "Such a path exists when a 172 direct neighbor of the router adjacent to the failure has a path 173 to the destination that can be guaranteed not to traverse the 174 failure." Further detail can be found in [RFC5286]. LFA as 175 defined for IP Fast Reroute (IPFRR) can be used to load balance 176 by relaxing the equal cost criteria of ECMP, though IPFRR defined 177 LFA for use in selecting protection paths. When used with IP, 178 proportional split is generally not used. LFA use in load 179 balancing is implemented by some vendors though it may be rare or 180 non-existent in deployments. 182 Link Aggregation 183 The term "link aggregation" generally refers to Ethernet Link 184 Aggregation as defined by the [IEEE-802.1AX]. Ethernet Link 185 Aggregation defines a Link Aggregation Control Protocol (LACP) 186 which coordinates inclusion of Link Aggregation Group (LAG) 187 members in the LAG. 189 Link Aggregation Group (LAG) 190 A group of physical Ethernet interfaces that are treated as a 191 logical link when using Ethernet Link Aggregation is referred to 192 as a Link Aggregation Group (LAG). 194 LAG Member 195 Ethernet Link Aggregation as defined in [IEEE-802.1AX] refers to 196 an individual link in a LAG as a LAG member. A LAG member is a 197 component link. An Ethernet LAG is a composite link. IEEE does 198 not use the terms composite link or component link. 200 A small set of requirements are discussed. These requirements make 201 use of keywords such as MUST and SHOULD as described in [RFC2119]. 203 3. MPLS as a Server Layer for MPLS-TP 205 An MPLS LSP may be used as a server layer for MPLS-TP LSPs as long as 206 all MPLS-TP requirements are met. Section 3.1 reviews the basis for 207 requirements of a server layer that supports MPLS-TP as a client 208 layer. Key requirements include OAM "fate-sharing", and the 209 requirement that packets within an MPLS-TP LSP are not reordered, 210 including both payload and OAM packets. Section 3.2 discusses 211 implied requirements where MPLS is the server layer for MPLS-TP 212 client LSPs, and describes a set of solutions using existing MPLS 213 mechanisms. 215 3.1. MPLS-TP Forwarding and Server Layer Requirements 217 [RFC5960] defines the data plane requirements for MPLS-TP. Two very 218 relevant paragraphs in "Section 3.1.1 LSP Packet Encapsulation and 219 Forwarding" are the following: 221 RFC 5960, Section 3.1.1, Paragraph 3 222 Except for transient packet reordering that may occur, for 223 example, during fault conditions, packets are delivered in order 224 on L-LSPs, and on E-LSPs within a specific ordered aggregate. 226 RFC 5960, Section 3.1.1, Paragraph 6 227 Equal-Cost Multi-Path (ECMP) load-balancing MUST NOT be performed 228 on an MPLS-TP LSP. MPLS-TP LSPs as defined in this document MAY 229 operate over a server layer that supports load-balancing, but 230 this load-balancing MUST operate in such a manner that it is 231 transparent to MPLS-TP. This does not preclude the future 232 definition of new MPLS-TP LSP types that have different 233 requirements regarding the use of ECMP in the server layer. 235 [RFC5960] Section 3.1.1, Paragraph 3 requires that packets within a 236 specific ordered aggregate be delivered in order. This same 237 requirement is already specified by Differentiated Services 238 [RFC2475]. [RFC5960] Section 3.1.1, Paragraph 6 explicitly allows a 239 server layer to use ECMP provided that it is transparent to the MPLS- 240 TP client layer. 242 [RFC6371] adds a requirement for data traffic and OAM traffic "fate- 243 sharing". The following paragraph in Section 1 ("Introduction") 244 summarizes this requirement. 246 RFC 6371, Section 1, Paragraph 7 247 OAM packets that instrument a particular direction of a transport 248 path are subject to the same forwarding treatment (i.e., fate- 249 share) as the user data packets and in some cases, where 250 Explicitly EXP-encoded-PSC LSPs (E-LSPs) are employed, may be 251 required to have common per-hop behavior (PHB) Scheduling Class 252 (PSC) End-to-End (E2E) with the class of traffic monitored. In 253 case of Label-Only-Inferred-PSC LSP (L-LSP), only one class of 254 traffic needs to be monitored, and therefore the OAM packets have 255 common PSC with the monitored traffic class. 257 [RFC6371] does not prohibit multilink techniques in "Section 4.6 258 Fate-Sharing Considerations for Multilink", where multilink is 259 defined as Ethernet Link Aggregation and the use of Link Bundling for 260 MPLS, but does declare that such a network would be only partially 261 MPLS-TP compliant. The characteristic that is to be avoided is 262 contained in the following sentence in this section. 264 RFC 6371, Section 4.6, Paragraph 1, last sentence 265 These techniques frequently share the characteristic that an LSP 266 may be spread over a set of component links and therefore be 267 reordered, but no flow within the LSP is reordered (except when 268 very infrequent and minimally disruptive load rebalancing 269 occurs). 271 A declaration that implies that Link Bundling for MPLS yields a 272 partially MPLS-TP compliant network, is perhaps overstated since only 273 the Link Bundling all-ones component link has this characteristic. 275 [RFC6374] defines a direct Loss Measurement (LM) where LM OAM packets 276 cannot be reordered with respect to payload packets. This will 277 require that payload packets themselves not be reordered. The 278 following paragraph in Section 2.9.4 ("Equal Cost Multipath") gives 279 the reason for this restriction. 281 RFC 6374, Section 2.9.4, Paragraph 2 282 The effects of ECMP on loss measurement will depend on the LM 283 mode. In the case of direct LM, the measurement will account for 284 any packets lost between the sender and the receiver, regardless 285 of how many paths exist between them. However, the presence of 286 ECMP increases the likelihood of misordering both of LM messages 287 relative to data packets and of the LM messages themselves. Such 288 misorderings tend to create unmeasurable intervals and thus 289 degrade the accuracy of loss measurement. The effects of ECMP 290 are similar for inferred LM, with the additional caveat that, 291 unless the test packets are specially constructed so as to probe 292 all available paths, the loss characteristics of one or more of 293 the alternate paths cannot be accounted for. 295 3.2. Methods of Supporting MPLS-TP client LSPs over MPLS 297 Supporting MPLS-TP LSPs over a fully MPLS-TP conformant MPLS LSP 298 server layer where the MPLS LSPs are making use of multipath, 299 requires special treatment of the MPLS-TP LSPs such that those LSPs 300 meet MPLS-TP forwarding requirements (see Section 3.1). This implies 301 the following brief set of requirements. 303 MP#1 It MUST be possible for a midpoint MPLS-TP Label Switching 304 Router (LSR) which is serving as ingress to a server layer MPLS 305 LSP to identify MPLS-TP LSPs, so that MPLS-TP forwarding 306 requirements can be applied, or to otherwise accommodate the 307 MPLS-TP forwarding requirements. 309 MP#2 The ability to completely exclude MPLS-TP LSPs from the 310 multipath hash and load split SHOULD be supported. If the 311 selected component link no longer meets requirements, an LSP is 312 considered down which may trigger protection and/or may require 313 that the ingress LSR select a new path and signal a new LSP. 315 MP#3 It SHOULD be possible to ensure that MPLS-TP LSPs will not be 316 moved to another component link as a result of a composite link 317 load rebalancing operation. If the selected component link no 318 longer meets requirements, another component link may be 319 selected, however a change in path SHOULD NOT occur solely for 320 load balancing. 322 MP#4 Where an Resource Reservation Protocol - Traffic Engineering 323 (RSVP-TE) control plane is used, it MUST be possible for an 324 ingress LSR which is setting up an MPLS-TP or an MPLS LSP to 325 determine at path selection time whether a link or Forwarding 326 Adjacency (FA, see [RFC4206]) within the topology can support the 327 MPLS-TP requirements of the LSP. 329 The reason for requirement MP#1 may not be obvious. An MPLS-TP LSP 330 may be aggregated along with other client LSPs by a midpoint LSR into 331 a very large MPLS server layer LSP, as would be the case in a core 332 node to core node MPLS LSP between major cities. In this case the 333 ingress of the MPLS LSP, being a midpoint LSR for a set of client 334 LSPs, has no signaling mechanism that can be used to determine if any 335 specific client LSP contained within it is MPLS or MPLS-TP. 336 Multipath load splitting can be avoided for MPLS-TP LSPs if at the 337 MPLS server layer LSP ingress LSR an Entropy Label Indicator (ELI) 338 and Entropy Label (EL) are added to the label stack by the midpoint 339 LSR for the client MPLS-TP LSP, at the ingress of the MPLS LSP 340 [RFC6790]. For those client LSPs that are MPLS-TP LSPs, a single 341 per-LSP EL value must be chosen. For those client LSPs that are MPLS 342 LSPs, per packet entropy below the top label must, for practical 343 reasons, be used to determine the entropy label value. The resulting 344 label stack contains the server MPLS LSP label, ELI, EL and the 345 client LSP label. Requirement MP#1 simply states that there must be 346 a means to make this decision. 348 There is currently no signaling mechanism defined to support 349 requirement MP#1, though that does not preclude a new extension being 350 defined later. In the absence of a signaling extension, MPLS-TP can 351 be identified through some form of configuration, such as 352 configuration which provides an MPLS-TP compatible server layer to 353 all LSPs arriving on a specific interface or originating from a 354 specific set of ingress LSRs. 356 Alternately, the need for requirement MP#1 can be eliminated if every 357 MPLS-TP LSP created by an MPLS-TP ingress makes use of an Entropy 358 Label Indicator (ELI) and Entropy Label (EL) below the MPLS-TP label 359 [RFC6790]. This would require that all MPLS-TP LSR in a deployment 360 support Entropy Label, which may render it impractical in many 361 deployments. 363 Some hardware which exists today can support requirement MP#2. 364 Signaling in the absence of MPLS Entropy Label can make use of link 365 bundling with the path pinned to a specific component for MPLS-TP 366 LSPs and link bundling using the all-ones component for MPLS LSPs. 367 This prevents MPLS-TP LSPs from being carried within MPLS LSPs but 368 does allow the coexistance of MPLS-TP and very large MPLS LSPs. 370 When Entropy Label Indicator (ELIs) and Entropy Labels (ELs) are not 371 applied by MPLS-TP ingresses, MPLS-TP LSPs can be carried as client 372 LSPs within an MPLS server LSP if the ingress of the MPLS server 373 layer LSP pushes an Entropy Label Indicator (ELI) and Entropy Label 374 (EL) below the server layer LSP label(s) in the label stack, just 375 above the MPLS-TP LSP label entry [RFC6790]. The value of EL can be 376 randomly selected at the client MPLS-TP LSP setup time and the same 377 EL value used for all packets of that MPLS-TP LSP. This allows MPLS- 378 TP LSPs to be carried as client LSPs within MPLS LSPs and satisfies 379 MPLS-TP forwarding requirements but requires that MPLS LSRs be able 380 to identify MPLS-TP LSPs (requirement MP#1). 382 MPLS-TP traffic can be protected from degraded performance due to an 383 imperfect load split if the MPLS-TP traffic is given queuing priority 384 (using strict priority and policing or shaping at ingress or locally 385 or weighted queuing locally). This can be accomplished using the 386 Traffic Class (TC) field and Diffserv treatment of traffic 387 [RFC5462][RFC2475]. In the event of congestion due to load 388 imbalance, only non-prioritized traffic will suffer as long as there 389 is a low percentage of prioritized traffic. 391 If MPLS-TP LSPs are carried within MPLS LSPs and ELI and EL are used, 392 requirement MP#3 is satisfied only for uncongested links where load 393 balancing is not required, or if MPLS-TP LSPs use Traffic Class (TC) 394 and Diffserv and the load rebalancing implementation rebalances only 395 the less preferred traffic. Load rebalance is generally needed only 396 when congestion occurs, therefore restricting MPLS-TP to be carried 397 only over MPLS LSPs that are known to traverse only links which are 398 expected to be uncongested can satisfy requirement MP#3. 400 An MPLS-TP LSP can be pinned to a Link Bundle component link if the 401 behavior of requirement MP#2 is preferred. An MPLS-TP LSP can be 402 assigned to a Link Bundle but not pinned if the behavior of 403 requirement MP#3 is preferred. In both of these cases, the MPLS-TP 404 LSP must be the top level LSP, except as noted above. 406 If MPLS-TP LSPs can be moved among component links, then the Link 407 Bundle all-ones component link can be used or server layer MPLS LSPs 408 can be used with no restrictions on the server layer MPLS use of 409 multipath except that Entropy Label must be supported along the 410 entire path. An Entropy Label must be used to ensure that all of the 411 MPLS-TP payload and OAM traffic are carried on the same component, 412 except during very infrequent transitions due to load balancing. 413 Since the Entropy Label Indicator and Entropy Label are always placed 414 above the Generic Associated Channel Label (GAL) in the stack, the 415 presence of GAL will not affect the selection of a component link as 416 long as the LSR does not hash on the label stack entries below the 417 Entropy Label. 419 An MPLS-TP LSP may not traverse multipath links on the path where 420 MPLS-TP forwarding requirements cannot be met. Such links include 421 any using pre- RFC 6790 Ethernet Link Aggregation, pre- RFC 6790 Link 422 Bundling using the all-ones component link, or other form of 423 multipath not supporting termination of the entropy search at the EL 424 as called for in [RFC6790]. An MPLS-TP LSP MUST NOT traverse a 425 server layer MPLS LSP which traverses any form of multipath not 426 supporting termination of the entropy search at the EL. For this to 427 occur, the MPLS-TP ingress LSR MUST be aware of these links. This is 428 the reason for requirement MP#4. 430 Requirement MP#4 can be supported using administrative attributes. 431 Administrative attributes are defined in [RFC3209]. Some 432 configuration is required to support this. 434 In MPLS Link Bundling the requirement for bidirectional co-routing 435 can be interpreted as meaning that the same set of LSR must be 436 traversed or can be interpreted to mean that the same set of 437 component links must be traversed [RFC4201][RFC3473]. Following the 438 procedures of Section 3 of RFC 3473 where Link Bundling is used only 439 ensures that the same set of LSR are traversed and that acceptable 440 labels are created in each direction. 442 When an MPLS-TP LSP is set up over a MPLS LSP, if the MPLS-TP LSP is 443 a bidirectional LSP, then providers who want to only set these MPLS- 444 TP LSP over bidirectional co-routed MPLS LSP can make use of 445 administrative attributes [RFC3209] to ensure that this occurs. If 446 MPLS-TP are carried by unidirectional MPLS LSP, the MPLS-TP OAM will 447 be unaffected as only the MPLS LSP endpoints will appear as MPLS-TP 448 OAM Maintenance Entity Group Intermediate Points (MIPs). 450 Two methods of adding an Entropy Label are described above. The 451 MPLS-TP ingress must have a means to determine which links can 452 support MPLS-TP in selecting a path (MP#4). Administrative 453 attributes can satisfy that requirement. If the MPLS-TP LSR is 454 capable of adding ELI/EL to the label stack, this method is 455 preferred. However equipment furthest from a provider's network core 456 is the least likely to support RFC 6790 in the near term. For 457 portions of the topology where an MPLS-TP is carried within a server 458 layer MPLS LSP the ingress of the server layer MPLS LSP can add ELI/ 459 EL using a fixed EL value per client LSP, except those known not to 460 require MPLS-TP treatment. There are numerous ways to determine 461 which client LSP are MPLS-TP LSP and which are not. While this 462 determination is out of scope and will vary among deployments, 463 configuration or the presence of specific attribute affinities in 464 RSVP-TE signaling are among the likely means to do so. 466 4. MPLS-TP as a Server Layer for MPLS 468 Carrying MPLS LSPs which are larger than a component link over an 469 MPLS-TP server layer requires that the large MPLS client layer LSP be 470 accommodated by multiple MPLS-TP server layer LSPs. MPLS multipath 471 can be used in the client layer MPLS. 473 Creating multiple MPLS-TP server layer LSPs places a greater Incoming 474 Label Map (ILM) scaling burden on the LSR. High bandwidth MPLS cores 475 with a smaller amount of nodes have the greatest tendency to require 476 LSPs in excess of component links, therefore the reduction in the 477 number of nodes offsets the impact of increasing the number of server 478 layer LSPs in parallel. Today, only in cases where deployed LSR ILMs 479 are small would this be an issue. 481 The most significant disadvantage of MPLS-TP as a server layer for 482 MPLS is that the use of MPLS-TP server layer LSPs reduces the 483 efficiency of carrying the MPLS client layer. The service which 484 provides by far the largest offered load in provider networks is 485 Internet, for which the LSP capacity reservations are predictions of 486 expected load. Many of these MPLS LSPs may be smaller than component 487 link capacity. Using MPLS-TP as a server layer results in bin 488 packing problems for these smaller LSPs. For those LSPs that are 489 larger than component link capacity, the LSP capacities need not be 490 (and often are not) integer multiples of convenient capacity 491 increments such as 10 Gb/s. Using MPLS-TP as an underlying server 492 layer greatly reduces the ability of the client layer MPLS LSPs to 493 share capacity. For example, when one MPLS LSP is underutilizing its 494 predicted capacity, the fixed allocation of MPLS-TP to component 495 links may not allow another LSP to exceed its predicted capacity. 496 Using MPLS-TP as a server layer may result in less efficient use of 497 resources and may result in a less cost effective network. 499 No additional requirements beyond MPLS-TP as it is now currently 500 defined are required to support MPLS-TP as a server layer for MPLS. 501 It is therefore viable but has some undesirable characteristics 502 discussed above. 504 5. Summary 506 MPLS equipment deployed in the core currently supports multipath. 507 For large service providers, core LSR must support some form of 508 multipath to be deployable. Deployed MPLS access and edge equipment 509 is often oblivious to the use of multipath in the core. It is 510 expected that at least first generation MPLS-TP equipment will be 511 oblivious to the use of multipath in the core. This first generation 512 MPLS-TP equipment is deployable in a core using multipath, with no 513 adverse impact to RSVP-TE signaling, if the edge equipment can 514 support administrative attributes (RFC 3209) and the core equipment 515 can support ELI/EL and put a per-LSP fixed EL value on any LSP that 516 indicates a particular attribute affinity or can identify client 517 MPLS-TP LSP through some other means. 519 There are no issues carrying MPLS over MPLS-TP, except when the MPLS 520 LSP is too big to be carried by a single MPLS-TP LSP. Most MPLS core 521 equipment and some edge equipment can configure an MPLS Link Bundle 522 [RFC4201] over multiple component links where the component links are 523 themselves MPLS LSP. This existing capability can be used to carry 524 large MPLS LSP and overcome the limited capacity of any single server 525 layer MPLS-TP LSP. 527 MPLS OAM and MPLS-TP OAM are unaffected in the following cases 528 proposed in this document: 530 1. Where MPLS is carried over a single MPLS-TP all traffic flows on 531 one link, MPLS OAM is unaffected and need not use multipath 532 support in LSP Ping [RFC4379]. 534 2. Where MPLS-TP is carried over MPLS, all traffic for that MPLS-TP 535 LSP is carried over one link thanks to the fixed EL value. In 536 this case MPLS-TP OAM is unaffected. 538 3. Where MPLS is carried over MPLS (an existing case) or over 539 multiple MPLS-TP, the multipath support in LSP Ping is used and 540 LSP Ping operation is unaffected [RFC4379][RFC6425]. 542 6. Acknowledgements 544 Carlos Pignataro, Dave Allan, and Mach Chen provided valuable 545 comments and suggestions. Carlos suggested that MPLS-TP requirements 546 in RFC 5960 be explicitly referenced or quoted. An email 547 conversation with Dave led to the inclusion of references and quotes 548 from RFC 6371 and RFC 6374. Mach made suggestions to improve clarity 549 of the document. 551 7. Implementation Status 553 Note: this section is temporary and supports the experiment called 554 for in draft-sheffer-running-code. 556 This is an informational document which describes usage of MPLS and 557 MPLS-TP. No new protocol extensions or forwarding behavior are 558 specified. Ethernet Link Aggregation and MPLS Link Bundling are 559 widely implemented and deployed. 561 Entropy Label is not yet widely implemented and deployed, but both 562 implementation and deployment are expected soon. At least a few 563 existing high-end, commodity packet processing chips are capable of 564 supporting Entropy Label. It would be helpful if a few LSR suppliers 565 would state their intentions to support RFC 6790 on the MPLS mailing 566 list. 568 Dynamic multipath (multipath load split adjustment in response to 569 observed load) is referred to but not a requirement of the usage 570 recommendations made in this document. Dynamic multipath has been 571 implemented and deployed, however (afaik) the only core LSR vendor 572 supporting dynamic multipath is no longer in the router business 573 (Avici Systems). At least a few existing high-end, commodity packet 574 processing chips are capable of supporting dynamic multipath. 576 8. IANA Considerations 577 This memo includes no request to IANA. 579 9. Security Considerations 581 This document specifies use of existing MPLS and MPLS-TP mechanisms 582 to support MPLS and MPLS-TP as client and server layers for each 583 other. This use of existing mechanisms supports coexistence of MPLS/ 584 GMPLS (without MPLS-TP) when used over a packet network, MPLS-TP, and 585 multipath. The combination of MPLS, MPLS-TP, and multipath does not 586 introduce any new security threats. The security considerations for 587 MPLS/GMPLS and for MPLS-TP are documented in [RFC5920] and [RFC6941]. 589 10. References 591 10.1. Normative References 593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 594 Requirement Levels", BCP 14, RFC 2119, March 1997. 596 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 597 and S. Ueno, "Requirements of an MPLS Transport Profile", 598 RFC 5654, September 2009. 600 [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport 601 Profile Data Plane Architecture", RFC 5960, August 2010. 603 [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and 604 Maintenance Framework for MPLS-Based Transport Networks", 605 RFC 6371, September 2011. 607 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 608 Measurement for MPLS Networks", RFC 6374, September 2011. 610 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 611 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 612 RFC 6790, November 2012. 614 10.2. Informative References 616 [I-D.ietf-rtgwg-cl-requirement] 617 Villamizar, C., McDysan, D., Ning, S., Malis, A., and L. 618 Yong, "Requirements for Advanced Multipath in MPLS 619 Networks", draft-ietf-rtgwg-cl-requirement-15 (work in 620 progress), January 2014. 622 [IEEE-802.1AX] 623 IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE 624 Standard for Local and Metropolitan Area Networks - Link 625 Aggregation", 2006, . 628 [ITU-T.G.800] 629 ITU-T, "Unified functional architecture of transport 630 networks", 2007, . 633 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 634 and W. Weiss, "An Architecture for Differentiated 635 Services", RFC 2475, December 1998. 637 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 638 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 639 Tunnels", RFC 3209, December 2001. 641 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 642 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 643 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 645 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 646 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 648 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 649 Hierarchy with Generalized Multi-Protocol Label Switching 650 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 652 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 653 Label Switched (MPLS) Data Plane Failures", RFC 4379, 654 February 2006. 656 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 657 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 659 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 660 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 661 Class" Field", RFC 5462, February 2009. 663 [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 664 5714, January 2010. 666 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 667 Networks", RFC 5920, July 2010. 669 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 670 S., and T. Nadeau, "Detecting Data-Plane Failures in 671 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 672 6425, November 2011. 674 [RFC6941] Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 675 Graveman, "MPLS Transport Profile (MPLS-TP) Security 676 Framework", RFC 6941, April 2013. 678 Author's Address 680 Curtis Villamizar 681 Outer Cape Cod Network Consulting 683 Email: curtis@occnc.com