idnits 2.17.1 draft-villamizar-mpls-tp-multipath-te-extn-02.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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the Entropy Label Required bit is set and the LSP being set up is using Entropy Label, then the Largest IP Microflow and Largest L4 Microflow SHOULD be omitted. All midpoint LSR SHOULD not look for entropy beyond the Entropy Label. -- The document date (October 7, 2012) is 4213 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-09) exists of draft-ietf-mpls-tp-security-framework-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS C. Villamizar, Ed. 3 Internet-Draft Outer Cape Cod Network 4 Intended status: Standards Track Consulting 5 Expires: April 10, 2013 October 7, 2012 7 Multipath Extensions for MPLS Traffic Engineering 8 draft-villamizar-mpls-tp-multipath-te-extn-02 10 Abstract 12 Extensions to OSPF-TE, ISIS-TE, and RSVP-TE are defined in support of 13 carrying LSP with strict packet ordering requirements over multipath 14 and and carrying LSP with strict packet ordering requirements within 15 LSP without violating requirements to maintain packet ordering. LSP 16 with strict packet ordering requirements include MPLS-TP LSP. 18 OSPF-TE and ISIS-TE extensions defined here indicate node and link 19 capability regarding support for ordered aggregates of traffic, 20 multipath traffic distribution, and abilities to support multipath 21 load distribution differently per LSP. 23 RSVP-TE extensions either identifies an LSP as requiring strict 24 packet order, or identifies an LSP as carrying one or more LSP that 25 requires strict packet order further down in the label stack, or 26 identifies an LSP as having no restrictions on packet ordering except 27 the restriction to avoid reordering microflows. In addition an 28 extension indicates whether the first nibble of payload will reliably 29 indicate whether payload is IPv4, IPv6, or other type of payload, 30 most notably pseudowire using a pseudowire control word. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 10, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Architecture Summary . . . . . . . . . . . . . . . . . . . 4 68 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 70 2. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 6 71 2.1. Multipath Node Capability sub-TLV . . . . . . . . . . . . 6 72 2.2. Multipath Link Capability TLV . . . . . . . . . . . . . . 9 73 2.3. LSP Multipath Attributes TLV . . . . . . . . . . . . . . . 9 74 3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . . . 12 75 3.1. OSPF-TE and ISIS-TE Advertisement . . . . . . . . . . . . 12 76 3.1.1. Node Capability Advertisement . . . . . . . . . . . . 12 77 3.1.2. Link Capability Advertisement . . . . . . . . . . . . 12 78 3.1.3. Setting Max Depth and IP Depth . . . . . . . . . . . . 12 79 3.1.4. Advertising Multipath as Link Bundling . . . . . . . . 13 80 3.1.5. Hierarchical LSP Link Advertisement . . . . . . . . . 13 81 3.1.6. Advertisement of Legacy Multipath . . . . . . . . . . 14 82 3.2. RSVP-TE LSP Attributes . . . . . . . . . . . . . . . . . . 15 83 3.2.1. LSP Contained Ordered Aggregates Flags . . . . . . . . 15 84 3.2.2. LSP Attributes for Ordered Aggregates . . . . . . . . 17 85 3.2.3. Attributes for LSP without Packet Ordering . . . . . . 17 86 3.3. Path Computation Constraints . . . . . . . . . . . . . . . 20 87 3.3.1. Link Multipath Capabilities and Path Computation . . . 20 88 3.3.1.1. Path Computation with Ordering Constraints . . . . 20 89 3.3.1.2. Path Computation with No Ordering Constraint . . . 21 90 3.3.1.3. Path Computation for MPLS containing MPLS-TP . . . 21 91 3.3.2. Link IP Capabilities and Path Computation . . . . . . 21 92 3.3.2.1. LSP without Packet Ordering Requirements . . . . . 22 93 3.3.2.2. LSP with Ordering Requirements . . . . . . . . . . 22 94 3.3.3. Link Depth Limitations and Path Computation . . . . . 23 95 4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 24 96 4.1. Legacy Multipath Behavior . . . . . . . . . . . . . . . . 24 97 4.2. Networks without Multipath Extensions . . . . . . . . . . 24 98 4.2.1. Netowrks with MP Capability on all Multipath . . . . . 24 99 4.2.2. Netowrks with OA Capability on all Multipath . . . . . 26 100 4.2.3. Legacy Netowrks with Mixed MP and OA Links . . . . . . 26 101 4.3. Transition to Multipath Extension Support . . . . . . . . 27 102 4.3.1. Simple Transitions . . . . . . . . . . . . . . . . . . 27 103 4.3.2. More Challenging Transitions . . . . . . . . . . . . . 27 104 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 105 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 106 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 108 7.2. Informative References . . . . . . . . . . . . . . . . . . 29 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 111 1. Introduction 113 Today the requirement to handle large aggregations of traffic, can be 114 handled by a number of techniques which we will collectively call 115 multipath. Multipath is very similar to composite link as defined in 116 [ITU-T.G.800], except multipath specifically excludes inverse 117 multiplexing. Some types of LSP, including but potentially not 118 limited to MPLS-TP LSP, require strict packet ordering. 120 A means to support a MPLS-TP client layer over a MPLS server layer 121 using MPLS Entropy Label is defined in 122 [I-D.villamizar-mpls-tp-multipath]. It is noted in 123 [I-D.villamizar-mpls-tp-multipath] that absent some protocol 124 extensions, some limitations must be accepted. 126 This document defines protocol extensions which better supports using 127 MPLS with multipath as a server layer for MPLS-TP, or to carry 128 MPLS-TP directly over a network which makes use of multipath. 129 Extensions are also applicable to MPLS when used in the presense of 130 very large microflows or very large LSP which cannot be load split as 131 a result of using MPLS Entropy Label [I-D.ietf-mpls-entropy-label]. 133 1.1. Architecture Summary 135 Advertisements in a link state routing protocol, such as OSPF or 136 ISIS, support a topology map known as a link state database (LSDB). 137 When traffic engineering information is included in the LSDB the 138 topology map is known as a TE-LSDB or traffic engineering database 139 (TED). 141 A common MPLS LSP path computation is known as a constrained shortest 142 path first computation (CSPF) (see [RFC3945]). Other algorithms may 143 be used for path computation. Constraint-based routing was first 144 introduced in [RFC2702]). 146 OSPF-TE or ISIS-TE extensions are defined in Section 2.1 and 147 Section 2.2. OSPF-TE or ISIS-TE advertisements serve to populate the 148 TE-LSDB and provide the basis for constraint-based routing path 149 computation. Section 3.1 describes the use of OSPF-TE or ISIS-TE 150 multipath extensions in routing advertisements. 152 RSVP-TE extensions are defined in Section 2.3. Section 3.2 describes 153 the use of RSVP-TE extensions in setting up LSP including signaling 154 constraints on LSP which contain other LSP which specify RSVP-TE 155 extensions. 157 Section 3.3 describes the constraints on LSP path computation imposed 158 by the advertised ordered aggregate and multipath capabilities of 159 links. Section 3.3.2 describes the constraints on LSP path 160 computation imposed by link advertisements regarding use of IP 161 headers in multipath traffic distribution. Section 3.3.3 describes 162 the impact of label stack depth limitations. 164 1.2. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 1.3. Definitions 172 Please refer to [I-D.villamizar-mpls-tp-multipath]. 174 Ordered Aggregate (OA) 175 An ordered aggregate (OA) requires that packets be delivered in 176 the order in which they were received. Please refer to [RFC3260]. 178 Microflow 179 A microflow is a single instance of an application-to- application 180 flow. Please refer to [RFC2475]. Reordering packets within a 181 microflow can cause service disruption. Please refer to 182 [RFC2991]. 184 Multipath Traffic Distribution 185 Multipath traffic distribution refers to the mechanism which 186 distributes traffic among a set of component links or component 187 lower layer paths which together comprise a multipath. No 188 assumptions are made about the algorithms used in multipath 189 traffic distribution. This document only discusses constraints of 190 the type of information which can be used as the basis for 191 multipath traffic distribution in specific circumstances. 193 The phrase "strict packet ordering requirements" refers to the 194 requirement to deliver all packet in the order that they were 195 received. The absence of strict packet ordering requirements does 196 not imply total absence of packet ordering requirements. The 197 requirement to avoid reordering traffic within any given microflow, 198 as described in [RFC2991] applies to all traffic aggregates including 199 all MPLS LSP. 201 The abbreviations ELI and EL are Entropy Label Indicator and Entropy 202 Label, as defined in [I-D.ietf-mpls-entropy-label]. 204 2. Protocol Extensions 206 This section defined protocol extensions to OSPF-TE, ISIS-TE, and 207 RSVP-TE. Use of these extensions is described in Section 3 and 208 Section 4. 210 Two capability sub-TLV are added to two TLV that are used in both 211 OSPF-TE and ISIS-TE. The Multipath Node Capability sub-TLV is added 212 to the Node Attribute TLV ( see Section 2.1). The Multipath Link 213 Capability TLV is added to the Interface_ID (see Section 2.2). 215 One TLV is added to the LSP_ATTRIBUTES object defined in [RFC5420]. 217 2.1. Multipath Node Capability sub-TLV 219 The Node Attribute TLV is defined in [RFC5786]. A new sub-TLV, the 220 Multipath Node Capability sub-TLV, is defined for inclusion in the 221 Node Attribute TLV. 223 0 1 2 3 224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Type | Length | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Flags | Max Depth | IP Depth | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Largest Supportable Microflow | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 1: Multipath Capability Sub-TLV 235 The fields in the Multipath Capability sub-TLV are defined as 236 follows. 238 Type 239 The Type field is assigned a value of IANA-TBD-1. The Type field 240 is a two octet value. 242 Length 243 The Length field indicates the length of the sub-TLV in octets, 244 excluding the Type and Length fields. The Length field is a two 245 octet value. 247 Flags 248 The Flags field is a two octet (16 bit) value. The following 249 single bit fields are assigned within this value, starting at the 250 most significant bit, which is the bit transmitted first. 252 0x8000 Ordered Aggregate Enabled 253 Setting the Ordered Aggregate Enabled bit indicates that an LSP 254 can be carried as an Ordered Aggregate Enabled on one or more 255 links. 257 0x4000 Multipath Enabled 258 Setting the Multipath Enabled bit indicates that an LSP can be 259 spread across component links at one or more multipath links. 261 0x2000 IPv4 Enabled Multipath 262 Setting the IPv4 Enabled Multipath bit indicates that the IPv4 263 header information can be used in multipath load balance. The 264 Multipath Enabled bit must be set if the IPv4 Enabled Multipath 265 bit is set. 267 0x1000 IPv6 Enabled Multipath 268 Setting the IP bit indicates that the IPv6 header information 269 can be used in multipath load balance. The Multipath Enabled 270 bit must be set if the IPv6 Enabled Multipath bit is set. 272 0x0800 UDP/IPv4 Multipath 273 Setting the UDP/IPv4 Multipath bit indicates that the UDP port 274 numbers carried in UDP over IPv4 can be used in multipath load 275 balance. The IPv4 Enabled Multipath bit must be set if UDP/ 276 IPv4 Multipath is set. If the IPv4 Enabled Multipath bit is 277 set and the UDP/IPv4 Multipath bit is clear, then only source 278 and destination IP addresses are used. 280 0x0400 UDP/IPv6 Multipath 281 Setting the UDP/IPv6 Multipath bit indicates that the UDP port 282 numbers carried in UDP over IPv6 can be used in multipath load 283 balance. The IPv6 Enabled Multipath bit must be set if UDP/ 284 IPv6 Multipath is set. The IPv6 Enabled Multipath bit must be 285 set if UDP/IPv6 Multipath is set. If the IPv6 Enabled 286 Multipath bit is set and the UDP/IPv6 Multipath bit is clear, 287 then only source and destination IP addresses are used. 289 0x0200 TCP/IPv4 Multipath 290 Setting the TCP/IPv4 Multipath bit indicates that the TCP port 291 numbers carried in TCP over IPv4 can be used in multipath load 292 balance. The IPv4 Enabled Multipath bit must be set if TCP/ 293 IPv4 Multipath is set. If the IPv4 Enabled Multipath bit is 294 set and the TCP/IPv4 Multipath bit is clear, then only source 295 and destination IP addresses are used. 297 0x0100 TCP/IPv6 Multipath 298 Setting the TCP/IPv6 Multipath bit indicates that the TCP port 299 numbers carried in TCP over IPv6 can be used in multipath load 300 balance. The IPv6 Enabled Multipath bit must be set if TCP/ 301 IPv6 Multipath is set. The IPv6 Enabled Multipath bit must be 302 set if TCP/IPv6 Multipath is set. If the IPv6 Enabled 303 Multipath bit is set and the TCP/IPv6 Multipath bit is clear, 304 then only source and destination IP addresses are used. 306 0x0080 Default to Multipath 307 Setting the Default to Multipath bit indicates that for an LSP 308 which does not signal a desired behavior the traffic for that 309 LSP will be spread across component links at one or more 310 multipath links. If the Default to Multipath bit is not set, 311 then an LSP which does not signal otherwise will be treated as 312 an ordered aggregate. 314 0x0040 Default to IP/MPLS Multipath 315 Setting the Default to IP/MPLS Multipath indicates that for an 316 LSP which does not signal a desired behavior, the IP header 317 information will be used in the multipath load distribution. 318 If the Default to IP/MPLS Multipath is clear it indicates that 319 the the IP header information will not be used by default. 321 0x0020 Entropy Label Multipath 322 Setting the Entropy Label Multipath bit indicates that when 323 multipath is enabled for a given LSP, if an Entropy Label 324 Indicator (ELI) is found in the label stack, information below 325 the Entropy Label (EL) will not be used in multipath load 326 distribution. 328 0x0010 IP Optional Multipath 329 Setting the IP Optional Multipath bit indicates that when 330 multipath is enabled for a given LSP, whether the IP header 331 information is used in the multipath load distribution can be 332 set on a per LSP basis. 334 The remaining bits in the Flags field are reserved. 336 Max Depth 337 The Max Depth field is a one octet field indicating the maximum 338 label stack depth beyond which the multipath load distribution 339 cannot make use of further label stack entries. 341 IP Depth 342 The IP Depth field is a one octet field indicating the maximum 343 label stack depth beyond which the multipath load distribution 344 cannot make use of IP information. 346 Largest Supportable Microflow 347 The Largest Supportable Microflow field is a IEEE 32 bit floating 348 point value expressing in bytes/second. Any microflow which 349 exceeds this capacity may experience either packet loss, or out- 350 of-order delivery, or both. 352 The reserved bits in the Flags field MUST be set to zero and MUST be 353 ignored unless implementing an extension which redefines one or more 354 of the reserved bits. Any further extension which redefines one or 355 more reserved Flags bit should maintain backwards compatibility with 356 prior implementations. 358 2.2. Multipath Link Capability TLV 360 The Interface_ID is defined in [RFC3471]. The Interface_ID is 361 updated in [RFC4201] to support a form of multipath known as Link 362 Bundling. 364 A new TLV, the Multipath Link Capability TLV, is defined here. The 365 Multipath Link Capability TLV is optionally included in the 366 Interface_ID. The format of the Multipath Link Capability TLV is 367 identical to the Multipath Node Capability sub-TLV defined in 368 Section 2.1, with one exception. In the Multipath Link Capability 369 TLV the Type field value is IANA-TBD-2. 371 If a Multipath Link Capability TLV is advertised for any link, then a 372 Multipath Node Capability sub-TLV MUST be advertised for the node. 374 2.3. LSP Multipath Attributes TLV 376 The LSP_ATTRIBUTES object is defined in [RFC5420]. A new LSP 377 Multipath Attributes TLV is defined for the LSP_ATTRIBUTES object. 378 The TLV Type is IANA_TBD_3. The format is described below. 380 0 1 2 3 381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Flags | OA Depth | LSP Min Depth | LSP IP Depth | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Largest Microflow Capacities | 388 | (variable length) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Figure 2: LSP Multipath Attributes TLV 393 The fields in the LSP Multipath Attributes TLV are defined as 394 follows. 396 Type 397 The Type field is assigned a value of IANA-TBD-3. The Type field 398 is a two octet value. 400 Length 401 The Length field indicates the length of the sub-TLV in octets, 402 excluding the Type and Length fields. The Length field is a two 403 octet value. 405 Flags 406 The Flags field is a one octet (8 bit) value. The following 407 single bit fields are assigned within this value, starting at the 408 most significant bit, which is the bit transmitted first. 410 0x80 IP Multipath Allowed 411 Setting the IP Multipath Allowed bit indicates that it is safe 412 to enable the use of a potential IP payload in the multipath 413 traffic distribution. 415 0x40 May Contain IPv4 416 Setting the May Contain IPv4 bit indicates that IPv4 traffic 417 may be contained within this LSP. 419 0x20 May Contain IPv6 420 Setting the May Contain IPv6 bit indicates that IPv6 traffic 421 may be contained within this LSP. 423 0x02 Entropy Label Required 424 Setting the Entropy Label Used bit indicates that midpoint LSR 425 MUST support ELI and EL in order to not violate packet ordering 426 constraints of the LSP or of contained LSP. 428 0x01 Entropy Label Used 429 Setting the Entropy Label Used bit indicates that an ELI and EL 430 is present in some or all label stack entries within this LSP. 432 The remaining bits in the Flags field are reserved. 434 OA Depth 435 The OA Depth field is set as follows 437 0 An OA Depth value of zero indicates that no ordered aggregates 438 are carried within the LSP, except those which are protected 439 from out of order delivery using Entropy Label. 441 1 An OA Depth value of one indicates that the LSP is an ordered 442 aggregate of traffic (the LSP requires strict ordering of 443 packets) and has protected packet ordering using ELI and EL. 445 >1 An OA Depth value greater than one indicates that the LSP does 446 not have strict packet ordering requirements but contains 447 ordered aggregates at the label stack depth indicated or deeper 448 and that the ordered aggregates are not protected using ELI and 449 EL. 451 LSP Min Depth 452 The LSP Min Depth field indicates a minimal acceptable number of 453 label used in multipath traffic distribution for the stated 454 Largest Microflow Capacities field to be valid. If the LSP Min 455 Depth field is set to zero this value is unknown. See 456 Section 3.3.3. 458 LSP IP Depth 459 The LSP IP Depth field indicates a minimal label stack depth where 460 using an IP header is necessary for the stated Largest Microflow 461 Capacities field to be valid. If the LSP IP Depth field is set to 462 zero this value is unknown. See Section 3.3.3. 464 Largest Microflow Capacities 465 The Largest Microflow Capacities field contains zero, one, two, or 466 three IEEE 32 bit floating point values. Each value is a capacity 467 expressed in bytes per second. 469 Largest LSE Microflow 470 The first value, the Largest LSE Microflow, is the capacity of 471 the largest microflow if only the label stack entries are used 472 in multipath traffic distribution. If a Largest LSE Microflow 473 is not included, the LSP bandwidth request MUST be used. 475 Largest IP Microflow 476 The second value, the Largest IP Microflow, if present, is the 477 capacity of the largest microflow if the label stack entries 478 and any potential IP source and destination address are used in 479 multipath traffic distribution. If the Largest IP Microflow is 480 not included, the value of the Largest LSE Microflow MUST be 481 used. 483 Largest L4 Microflow 484 The third, the Largest L4 Microflow, if present, is the 485 capacity of the largest microflow if the label stack entries 486 and any potential IP addresses and TCP or UDP port numbers are 487 used in multipath traffic distribution. If a Largest L4 488 Microflow is not included, the value of the Largest IP 489 Microflow MUST be used. 491 3. Protocol Mechanisms 493 3.1. OSPF-TE and ISIS-TE Advertisement 495 Every compliant node MUST advertise exactly one Multipath Node 496 Capability sub-TLV and MAY advertise zero of more Multipath Link 497 Capability sub-TLV as needed. 499 Procedures for accommodating legacy forwarding capabilities and non- 500 compliant nodes are discussed in Section 4. 502 3.1.1. Node Capability Advertisement 504 Every LSR which is adjacent to one or more multipath link MUST 505 advertise a Multipath Node Capability sub-TLV (see Section 2.1). The 506 capabilities advertised for the node SHOULD reflect the capabilities 507 of the majority of multipath links adjacent to the node. 509 Every LSR which is not adjacent to any multipath links MUST advertise 510 a Multipath Node Capability sub-TLV with both the Ordered Aggregate 511 Enabled bit in Flags set and all other Flags bits clear. Both Max 512 Depth and IP Depth can be set to zero. This advertisement identifies 513 the LSR as one which is conformant but has no multipath links, 514 allowing it to be distinguished from a non-conformant LSR with LAG or 515 other multipath which may have to be avoided when determining a path 516 for some LSP. 518 3.1.2. Link Capability Advertisement 520 For all of the links whose capability does not exactly match the 521 Multipath Node Capability sub-TLV advertised by that same LSR, the 522 LSR MUST advertise a Multipath Link Capability sub-TLV (see 523 Section 2.2). 525 For all of the links whose capability does exactly match the 526 Multipath Node Capability sub-TLV advertised by that same LSR, the 527 LSR SHOULD NOT advertise a Multipath Link Capability sub-TLV (see 528 Section 2.2). In this case the Multipath Link Capability TLV is 529 redundant, but harmless. 531 3.1.3. Setting Max Depth and IP Depth 533 The Max Depth and IP Depth field are intended to capture 534 architectural limits. Most forwarding hardware will only use a 535 limited number of label entries in the multipath traffic 536 distribution. This limit is reflected in the Max Depth field. Most 537 forwarding hardware will limit the number of label entries that it 538 will look past before looking for an IP header to be used in the 539 multipath traffic distribution. This limit is reflected in the IP 540 Depth field. 542 3.1.4. Advertising Multipath as Link Bundling 544 All multipath links and FA for PSC LSP which traverse multipath links 545 MAY be advertised as Link Bundles as defined in [RFC4201]. The 546 settings of the Ordered Aggregate Enabled and Multipath Enabled 547 fields indicate key capabilities of the multipath. Advertising the 548 multipath as a link bundle can provide additional information, such 549 as the capability to place LSP on individual components. 551 If the Multipath Enabled bit is set in the Multipath Link Capability 552 TLV Flags, then the Maximum LSP Bandwidth in the Interface 553 Identification TLV can be set in one of two ways. 555 1. If the desired behavior for legacy LSR acting as ingress is to 556 limit LSP to the capacity of a single component link, then 557 Maximum LSP Bandwidth SHOULD be set as specified in [RFC4201]. 559 2. If the desired behavior for legacy LSR acting as ingress is to 560 allow LSP to exceed the capacity of a single component link, then 561 Maximum LSP Bandwidth MAY be set to a higher value, up to the 562 value of Maximum Reservable Bandwidth. This would normally be 563 done if the legacy LSR were known to be carrying traffic which is 564 easily load split, such as typical Internet traffic. 566 LSR acting as ingress SHOULD ignore the Maximum LSP Bandwidth and MAY 567 set up LSP with capacity up to the Maximum Reservable Bandwidth as 568 long as microflows within the LSP will not exceed the Largest 569 Supportable Microflow capacity. 571 3.1.5. Hierarchical LSP Link Advertisement 573 A PSC LSP, as defined in [RFC4206] and updated in [RFC6107], may 574 carry other LSP. When signaling a PSC LSP expected characteristics 575 of the contained traffic must be estimated. The FA advertised for 576 the PSC LSP MUST reflect the broadest set of requirements the PSC LSP 577 can carry. If the setup of an additional reservation would exceeded 578 current capacity, a PSC LSP may be resignaled using make-before-break 579 semantics ([RFC3209]. 581 For example, if it is expected that a PSC LSP will carry MPLS-TP LSP 582 or other LSP with strict packet reordering requirements at some label 583 depth, the minimum label stack depth at which an LSP with strict 584 packet reordering requirements can be carried must be signaled in the 585 OA Depth field of the LSP Multipath Attributes TLV (see Section 2.3. 587 When the Forwarding Adjacency (FA) is advertised, the advertised Max 588 Depth and IP Depth MUST be one less that the minimum of the Max Depth 589 and IP Depth of any link that the PSC LSP traverses. The Max Depth 590 and IP Depth are considered independently of each other. The 591 reduction by one takes into account the PSC label. The Flags 592 advertised for the FA MUST reflect the capabilities of the links 593 along the path. 595 3.1.6. Advertisement of Legacy Multipath 597 An Ethernet LAG with no support for Entropy Label MUST have the 598 Ordered Aggregate Enabled bit cleared and the Multipath Enabled bit 599 set in the Multipath Link Capability TLV Flags. This indicates that 600 a MPLS-TP compliant server layer cannot be supported and that LSP 601 larger than the component links (LAG members) can be supported. 603 A Link Bundle that does not support the all-ones component defined in 604 [RFC4201] MUST have the Ordered Aggregate Enabled bit set and the 605 Multipath Enabled bit cleared in the Multipath Link Capability TLV 606 Flags. This indicates that a MPLS-TP compliant server layer can be 607 supported and that LSP larger than the component links cannot be 608 supported. 610 A link bundle that can support either the pinning of a LSP to a 611 single component link or the spreading of traffic across multiple 612 component links MUST have the Ordered Aggregate Enabled bit set and 613 the Multipath Enabled bit set in the Multipath Link Capability TLV 614 Flags. This indicates that a MPLS-TP compliant server layer can be 615 supported and that LSP larger than the component links can also be 616 supported. 618 Any form of multipath that supports Entropy Label MUST have the 619 Ordered Aggregate Enabled bit set and the Multipath Enabled bit set 620 and the Entropy Label Multipath bit set in the Multipath Link 621 Capability TLV Flags. Any form of multipath that does not supports 622 Entropy Label MUST have the Entropy Label Multipath bit cleared in 623 the Multipath Link Capability TLV Flags. 625 The remaining bits in the Multipath Link Capability TLV Flags MUST be 626 set according to the capability and configuration of the multipath or 627 LSP. 629 3.2. RSVP-TE LSP Attributes 631 All LSR SHOULD advertise a LSP Multipath Attributes TLV with the 632 RSVP-TE signaling for each LSP for which it is serving as ingress. 633 If any legacy LSR remain in the network, it is easier to assign an 634 acceptable default treatment for LSP signaled by those legacy LSR if 635 the conforming LSR always send a LSP Multipath Attributes TLV. 637 There are two general cases, an LSP requires strict ordering of 638 packets, or it doesn't. In the latter case the LSP may contain other 639 LSP that require strict ordering and those must be protected from 640 reordering using an Entropy Label as described in 641 [I-D.villamizar-mpls-tp-multipath]. These two cases are briefly 642 described below. 644 Ordered Aggregates 645 LSP with strict packet order requirements MUST set the OA Depth 646 field to one to indicate that the LSP MUST be treated as ordered 647 aggregate. See Section 3.2.2. 649 LSP without Packet Ordering 650 LSP which do not have strict packet order requirements MUST only 651 carry LSP whose requirements are reflected in the containing LSP 652 Multipath Attributes TLV. See Section 3.2.3. 654 If an attempt is made to signal a contained LSP whose Ordered 655 Aggregate Attributes TLV and LSP Multipath Attributes TLV cannot be 656 supported by the containing (PSC) LSP, one of the two following 657 actions MUST be taken. 659 1. The containing (PSC) LSP MAY be resignaled with appropriate TLVs 660 to carry the new contained LSP using make-before-break semantics, 661 then continue to forward the contained LSP PATH message if the 662 containing (PSC) LSP is successfully updated. 664 2. The LSR MAY reject the contained LSP signaling by sending a 665 PathErr message. 667 3.2.1. LSP Contained Ordered Aggregates Flags 669 The Flags field in the LSP Multipath Attributes TLV MUST be set as 670 follows. 672 1. If the LSP may directly contain IPv4 traffic, then the May 673 Contain IPv4 bit in the Flags field MUST be set. 675 2. If the LSP may directly contain IPv6 traffic, then the May 676 Contain IPv6 bit in the Flags field MUST be set. 678 3. If the LSP contains an LSP which has the May Contain IPv4 bit in 679 the Flags field then the May Contain IPv4 bit in the Flags field 680 MUST be set in the containing LSP. 682 4. If the LSP contains an LSP which has the May Contain IPv6 bit in 683 the Flags field then the May Contain IPv6 bit in the Flags field 684 MUST be set in the containing LSP. 686 5. If the LSP may contain pseudowires that do not use a pseudowire 687 control word [RFC4385], and may contain IPv4 or IPv6 traffic, 688 then the IP Multipath Allowed bit in the Flags field MUST be 689 cleared. 691 6. If the LSP is known to contain no pseudowires that do not use a 692 pseudowire control word, then the IP Multipath Allowed bit in the 693 Flags field SHOULD be set unless disallowed due to a contained 694 LSP. 696 7. If an Entropy Label is added below the LSP label, then the 697 Entropy Label Used bit MUST be set. 699 8. If the LSP contains any LSP with the IP Multipath Allowed bit in 700 the Flags field clear, then the IP Multipath Allowed bit in the 701 Flags field MUST be clear. 703 If the LSP does not contain other LSP, it may contain IP traffic 704 and/or pseudowire that terminate on that LSR. If the LSP does not 705 contain other LSP. The LER will know whether the LSP is used in an 706 IP LER capacity. The LER will also know whether it terminates any 707 pseudowire for a given LSP. The LER will also know if it is using 708 Entropy Label for a given LSP and if it requires strict packet 709 ordering for a given LSP. Therefore, when a LSP does not contain 710 other LSP, then it is possible to accurately set the Flags field in 711 the LSP Multipath Attributes TLV, as well the OA Depth, and LSP IP 712 Depth fields. 714 If an LSP contains other LSP, and all of the contained include a LSP 715 Multipath Attributes TLV, then it is still possible to accurately set 716 the Flags field in the LSP Multipath Attributes TLV, as well the OA 717 Depth, and LSP IP Depth fields. It is only when LSP contains other 718 LSP that do not have a LSP Multipath Attributes TLV where default 719 behavior has to be configured based on assumptions about LSP 720 originated by the legacy LSR where there is a potential for those 721 configured assumptions to be inaccurate. 723 See Section 4 for guidelines for handling LSP which contain LSP that 724 do not have a LSP Multipath Attributes TLV. The most conservative 725 approach in this case is to clear the IP Multipath Allowed bit and 726 set the May Contain IPv4 bit and the May Contain IPv6 bit, however 727 this may not always be necessary. 729 3.2.2. LSP Attributes for Ordered Aggregates 731 An LSP with strict packet order requirements MUST always include a 732 LSP Multipath Attributes TLV. 734 Most of the Flags in the LSP Multipath Attributes TLV can be set as 735 described in Section 3.2.1. There are two cases which affect the 736 setting of the remaining Flags bits. 738 Entropy Label not used 739 If an Entropy Label is not used, then the Entropy Label Used bit, 740 the Entropy Label Required bit, and the IP Multipath Allowed bit 741 MUST be cleared. 743 Entropy Label is used If an Entropy Label is used, then the Entropy 744 Label Used bit, and the Entropy Label Required bit, and the IP 745 Multipath Allowed bit MUST be set. 747 The OA Depth field MUST be set to one. The Min Depth MUST be set to 748 one. The LSP IP Depth SHOULD be set to zero. The Largest Microflow 749 Capacities field SHOULD be empty. The entire LSP is one microflow. 750 The Largest Microflow Capacities field MAY contain one entry if there 751 is some reason to do so, such as an LSP which may peak at capacity 752 higher than the bandwidth reserved for the LSP. The Largest 753 Microflow Capacities for an LSP SHOULD be configurable independently 754 of the LSP bandwidth reservation. 756 3.2.3. Attributes for LSP without Packet Ordering 758 If an LSP does not have strict packet order constraints, then the 759 LSR_ATTRIBUTE object SHOULD always include a LSP Multipath Attributes 760 TLV. 762 Most of the Flags in the LSP Multipath Attributes TLV can be set as 763 described in Section 3.2.1. There are two cases which affect the 764 setting of the remaining Flags bits, the OA Depth field, the LSP Min 765 Depth, and the LSP IP Depth field. 767 Entropy Label not used 769 * The OA Depth MUST be either set to zero or set to a configured 770 value that is greater than one, or set based on the contained 771 LSP. 773 * If the OA Depth is set to a configured value, then any setup 774 attempt for a contained LSP with a depth greater than or equal 775 to that value SHOULD be rejected and a PathErr message sent. 776 Otherwise, if a setup attempt for a contained LSP with a depth 777 greater that the current value included in the containing LSP 778 OA Depth field, then the containing LSP MUST be rerouted with a 779 OA Depth field value greater than any of the contained OA Depth 780 field values. 782 * The Entropy Label Used bit MUST be set if any contained LSP has 783 the Entropy Label Used bit set. 785 * The Entropy Label Required bit MUST be set if any contained LSP 786 has the Entropy Label Required bit set. 788 Entropy Label is used 790 * The OA Depth MUST be set to zero. 792 * The Entropy Label Used bit MUST be set. 794 * The Entropy Label Required bit MUST be set if any contained LSP 795 has the Entropy Label Required bit set. 797 * The Entropy Label Required bit MUST be set if any contained LSP 798 has the OA Depth field set to a non-zero value. 800 * The Entropy Label Required bit SHOULD be clear if there are no 801 contained LSP has the OA Depth field set to a non-zero value 802 and no contained LSP with the Entropy Label Required bit set. 803 In this case the Entropy Label Required bit MAY be set by 804 configuration, generally in anticipation of needing it in the 805 future to carry other LSP. 807 * LSP Min Depth field MUST be set to three if the Entropy Label 808 Required bit is set. 810 * If the Entropy Label Required bit is not set, then the LSP Min 811 Depth field and LSP IP Depth field SHOULD be set to three if 812 there are no contained LSP. The LSP Min Depth field and LSP IP 813 Depth MAY be configured to a minimum value greater than three, 814 generally in anticipation of needing it in the future to carry 815 other LSP. 817 * If the Entropy Label Required bit is not set, and there are 818 contained LSP, then the LSP Min Depth field MUST be set to a 819 value greater than three. 821 * If the Entropy Label Required bit is not set, the LSP Min Depth 822 field MUST be set to a value that is at least the sum of three 823 plus the LSP Min Depth field in any contained LSP. 825 * If the Entropy Label Required bit is not set, and either the 826 May Contain IPv4 bit or the May Contain IPv6 bit is set, then 827 the LSP IP Depth field MUST be set to a value of one or 828 greater. 830 * If the Entropy Label Required bit is not set, and any contained 831 LSP has the May Contain IPv4 bit or the May Contain IPv6 bit is 832 set, then the LSP IP Depth field MUST be set to a value of two 833 or greater. 835 * If the Entropy Label Required bit is not set, and any contained 836 LSP has the LSP IP Depth field set to a value greater than one, 837 then the LSP IP Depth field MUST be set to a value greater than 838 the highest LSP IP Depth value set in any contained LSP. 840 The values of the LSP Min Depth field and the LSP IP Depth field MAY 841 be constrained to upper limits by configuration. If an attempt to 842 setup a contained LSP would result in exceeding one of these limits, 843 then the LSR SHOULD reject the signaling attempt and send a PathErr 844 message. 846 If Entropy Label is not used on the signaled LSP and there are no 847 contained LSP, then the Largest LSE Microflow in the Largest 848 Microflow Capacities field MUST be set to the requested bandwidth of 849 the LSP. The optional Largest IP Microflow and Largest L4 Microflow 850 SHOULD be included and MAY be set to configured minimum values. 852 If Entropy Label is not used on the signaled LSP an LSP that does not 853 have strict packet order constraints contains other LSP, then the LSP 854 Multipath Attributes TLV advertised by the set of contained LSP MUST 855 be used to set the LSP Multipath Attributes TLV Largest Microflow 856 Capacities values for LSP Multipath Attributes TLV. The value of 857 Largest LSE Microflow, Largest IP Microflow, and Largest L4 Microflow 858 in the LSP Multipath Attributes TLV of the containing LSP cannot be 859 less than the maximum effective value of the same parameter for any 860 contained LSP Multipath Attributes TLV. 862 If Entropy Label is used on the signaled LSP then the Largest LSE 863 Microflow field is set according to the largest microflow that can 864 result from computing the Entropy Label. This value is the greatest 865 of a set of sources of entropy. A configured value MAY be used for 866 IP, or it MAY be assumed that the largest interface carrying IP could 867 carry a single microflow. For contained LSP which have the Entropy 868 Label Used bit clear, the value in the Largest IP Microflow can be 869 used if the IP Multipath Allowed bit is set for that LSP and the LSR 870 can make use of the IP information in the label stack. For contained 871 LSP which have the Entropy Label Used bit set, the Largest LSE 872 Microflow value already reflects any prior hashing of IP fields. 874 If the Entropy Label Required bit is set and the LSP being set up is 875 using Entropy Label, then the Largest IP Microflow and Largest L4 876 Microflow SHOULD be omitted. All midpoint LSR SHOULD not look for 877 entropy beyond the Entropy Label. 879 If the LSP being set up is not using Entropy Label, then the Largest 880 IP Microflow and Largest L4 Microflow SHOULD be included unless the 881 Entropy Label Used bit is set for every contained LSP. The Largest 882 IP Microflow and Largest L4 Microflow SHOULD be omitted if hashing on 883 the IP addresses or IP addresses and ports would yield no greater 884 entropy than hashing on the label stack alone. 886 3.3. Path Computation Constraints 888 The RSVP-TE extensions provides a set of requirements to be met by 889 the links which the LSP is to traverse. This set of requirements 890 also serves as the basis for path computation constraints and for 891 admission control constraints. 893 3.3.1. Link Multipath Capabilities and Path Computation 895 Three cases are considered. An LSP may have strict ordering 896 constraints. An MPLS-TP LSP is an example of an LSP with strict 897 ordering constraints. This first type of LSP is covered in 898 Section 3.3.1.1. An LSP may have no ordering constraints at all 899 other than the constraint that microflows cannot be reordered. This 900 second case is covered in Section 3.3.1.2. The remaining case is 901 where an LSP has no ordering constraints but carries traffic for 902 other LSP which do have ordering constraints. This third case is 903 covered in Section 3.3.1.3. 905 3.3.1.1. Path Computation with Ordering Constraints 907 For an MPLS-TP LSP or other LSP with a strict packet ordering 908 constraint, any link or FA for which the Ordered Aggregate Enabled 909 bit and Entropy Label Multipath are both clear MUST be excluded from 910 the path computation. If the Default to Multipath bit is set on a 911 link, then setting the OA Depth field to one will override that 912 default. 914 Link with the Ordered Aggregate Enabled bit clear and the Entropy 915 Label Multipath bit set MAY be included in the path computation if 916 the LSR is capable of encapsulating an LSP with a strict packet 917 ordering constraint with a fixed Entropy Label. If the LSR is not 918 capable of adding an ELI and EL, then these links MUST be excluded 919 from the path computation. 921 3.3.1.2. Path Computation with No Ordering Constraint 923 For an MPLS LSP which has no constraint on packet ordering except 924 that microflows must remain in order and does not contain other LSP 925 with ordering constraints, any link for which the Multipath Enabled 926 bit is set can be used. If s link is advertised as a Link Bundle and 927 the Multipath Enabled bit is set for the link, the available 928 bandwidth SHOULD be taken from the "Unreserved Bandwidth" rather than 929 the "Maximum LSP Bandwidth" (see [RFC4201]). 931 For most LSP, the bandwidth requirement of the largest microflow is 932 not known but an upper bound is known. For example if the LSP 933 aggregates pseudowires or other LSP of no more than some maximum 934 capacity or LSP which have signaled a microflow upper bound, then an 935 upper bound on the largest microflow is known. If this upper bound 936 exceeds the "Maximum LSP Bandwidth" of a given link, then that link 937 MUST be excluded from the path computation. 939 3.3.1.3. Path Computation for MPLS containing MPLS-TP 941 To carry LSP which have strict packet ordering requirements and do 942 not have the Entropy Label Used flag set as a client within a server 943 LSP that do not have strict packet ordering requirements, Entropy 944 Label must be added at the server layer LSP to traverse any link or 945 FA that has the Multipath Enabled bit set. For these LSP links which 946 have the Multipath Enabled bit set and the Entropy Label Multipath 947 bit clear MUST be excluded from the path computation. 949 If the LSR is not capable of adding an Entropy Label, then to carry 950 any client LSP with the Entropy Label Used clear and the OA Depth set 951 to a non-zero value, the server LSP SHOULD exclude any link or FA 952 that has the Multipath Enabled bit set. For these LSP, any link or 953 FA that has the Multipath Enabled bit set and cannot carry a 954 microflow as large as the entire LSP MUST be excluded from the path 955 computation. These LSP MAY be signaled as having strict packet 956 ordering requirements if they can be carried as a single microflow, 957 but this practice is NOT RECOMMENDED. 959 3.3.2. Link IP Capabilities and Path Computation 961 An MPLS-TP LSP cannot be reordered. There may be other types of LSP 962 with strict packet ordering requirements. If LSP with strict packet 963 ordering requirements carry IP, using IP headers in the multipath 964 load distribution would violate the packet ordering requirements. 966 Some LSP cannot be reordered but do not carry IP, and do not carry 967 payloads which could be mistaken as IP. For example, any LSP 968 carrying only pseudowire traffic, where all pseudowires are using a 969 control word carries no payloads which could be mistaken as IP. 970 These type of LSP can be carried within MPLS LSP that allow use of IP 971 header information in multipath load distribution. 973 This section focuses on Cases in which links or FA must be excluded 974 from path computation based on the setings of the IP related Flags 975 bits in the Multipath Link Capability TLV. 977 3.3.2.1. LSP without Packet Ordering Requirements 979 Many LSP carry only IP or predominantly IP, use no hierarchy or have 980 little diversity in the MPLS label stack, and carry far more traffic 981 than can be carried over a single component link in a multipath. 982 Many LSP due to their high capacity, must traverse only multipath 983 which will use IP header information in the multipath traffic 984 distribution. 986 For these LSP, links must be excluded from the path computation which 987 do not have the IPv4 Enabled Multipath and IPv6 Enabled Multipath bit 988 set (if carrying both IPv4 and IPv6) and do not have either the 989 Default to IP/MPLS Multipath bit set or the IP Optional Multipath bit 990 set. 992 Hierarchical PSC LSP which require the use IP header information in 993 the multipath traffic distribution MUST NOT set the Ordered Aggregate 994 Enabled bit, MUST set the Default to IP/MPLS Multipath bit, and MUST 995 NOT set the IP Optional Multipath bit in the FA advertisement. The 996 IP Optional Multipath bit MUST be clear because the LSP cannot change 997 the behavior of midpoint LSR, except perhaps in the case of single 998 hop LSP. 1000 3.3.2.2. LSP with Ordering Requirements 1002 The only time that links or FA with both the Ordered Aggregate 1003 Enabled bit and the Entropy Label Multipath bit clear can be used is 1004 a special case for MPLS-TP LSP that carry only IP traffic. This case 1005 does not apply if the MPLS_TP LSP is carrying other LSP or if it is 1006 carrying pseudowires. 1008 Where MPLS-TP LSP are carrying only IP, any link or FA with both the 1009 Ordered Aggregate Enabled bit and the Entropy Label Multipath bit 1010 clear for which the use of IP header information is not disabled or 1011 cannot be disabled on a per LSP basis, that link MUST be excluded 1012 from the path computation. 1014 Where MPLS-TP LSP are carrying only IP, links MAY be included in the 1015 path computation have the IPv4 Enabled Multipath and IPv6 Enabled 1016 Multipath bits clear, or have the Default to IP/MPLS Multipath bit 1017 clear, or have the IP Optional Multipath bit set. Links with the IP 1018 Optional Multipath set, MUST disable use of IP in the load balance 1019 for LSP with the IP Multipath Allowed bit clear. 1021 An MPLS-TP LSP are carrying only IP MUST have OA Depth set to one and 1022 LSP Min Depth set to one and the IP Multipath Allowed bit cleared. 1023 Call admission SHOULD NOT reject an LSP on the basis of OA Depth 1024 being set to one if use of IP headers is always disabled, or can be 1025 disabled for the specific LSP. If an MPLS-TP is set up this way end 1026 then does start to carry other LSP or carry pseudowires, then 1027 reordering within the MPLS-TP LSP will occur. 1029 3.3.3. Link Depth Limitations and Path Computation 1031 For any LSP which does not have strict packet ordering constraints, 1032 LSP configuration SHOULD include the following parameters. 1034 LSP Min Depth 1035 a minimal acceptable number of label used in multipath traffic 1036 distribution, 1038 LSP IP Depth 1039 a minimal label stack depth where the IP header can be used in 1040 multipath traffic distribution 1042 For example, if a PSC LSP will carry LSP which in turn carry very 1043 high capacity pseudowires using the pseudowire flow label (see 1044 [RFC6391]), the flow label is four labels deep. In this case, LSP 1045 Min Depth should be four or higher. 1047 For example, if the same PSC LSP will carry LSP which carry IP 1048 traffic with no additional labels, then the IP header is two labels 1049 deep. In this case, LSP IP Depth should be two or higher. 1051 For an LSP with non-zero LSP Min Depth, all links with Max Depth set 1052 to a value below LSP Min Depth MUST be excluded from the LSP Path 1053 Computation. 1055 For an LSP with non-zero LSP IP Depth, all links with IP Depth set to 1056 a value below LSP IP Depth MUST be excluded from the LSP Path 1057 Computation. 1059 If all LSP carried an accurate LSP Min Depth and LSP IP Depth then 1060 neither of these parameters would ever have to be configured. In a 1061 network with legacy LSR, it may be necessary to configure these 1062 parameters for some LSP. A per-LSP minimum value of each parameter 1063 SHOULD be configurable. 1065 4. Backwards Compatibility 1067 Networks today use three forms of multipath. 1069 1. IP ECMP, including IP ECMP at LER using more than one LSP. 1071 2. Ethernet Link Aggregation [IEEE-802.1AX]. 1073 3. MPLS Link Bundling [RFC4201]. 1075 4.1. Legacy Multipath Behavior 1077 IP ECMP and Ethernet Link Aggregation always distribute traffic over 1078 the entire multipath either using information in the MPLS label 1079 stack, or using information in a potential IP header, or using both 1080 types of information. 1082 One of two behaviors is assumed for link bundles. Either the link 1083 bundles place each LSP in its entirety on a single link bundle 1084 component link for all LSP, or link bundles distribute traffic over 1085 the entire link bundle using the same techniques used for ECMP and 1086 Ethernet Link Aggregation. This second behavior is known as the "all 1087 ones" component link (see [RFC4201]). 1089 4.2. Networks without Multipath Extensions 1091 Networks exist that are comprised entirely of LSR which do not 1092 support these multipath extensions. In these networks there is no 1093 way of telling how multipath links will behave. Since an Ethernet 1094 Link Aggregation Goup (LAG) is advertised as an ordinary link, there 1095 is no way to tell that it is a LAG and not an ordinary link. 1097 4.2.1. Netowrks with MP Capability on all Multipath 1099 Most large core network today rely heavily on the use of multipath. 1100 Ethernet Link Aggregation is heavily used and LSR are configured to 1101 use the "all ones" component link for all LSP. The "all ones" 1102 component link is the default for many Link Bundling implementations 1103 used in core networks. 1105 This is equivalent to the following setting in the Multipath Node 1106 Capabilities sub-TLV or Multipath Link Capabilities sub-TLV. 1108 1. Clear the Ordered Aggregate Enabled bit and the IP Optional 1109 Multipath bit. 1111 2. Set the Multipath Enabled bit, set the Default to Multipath bit, 1112 and clear the Entropy Label Multipath bit. 1114 3. If the label stack is used in the multipath traffic distribution, 1115 set Max Depth to the number of label stack entries supported, 1116 otherwise set it to zero. 1118 4. Since Entropy Label support is not yet widespread, most LSR would 1119 behave as if Entropy Label Multipath were clear. 1121 5. If an IP packet under the label stack can be used in the 1122 multipath traffic distribution (very common, almost universal in 1123 core LSR), set IPv4 Enabled Multipath, set IPv6 Enabled 1124 Multipath, set Default to IP/MPLS Multipath, and set IP Depth to 1125 the maximum number of label stack entries which can be skipped 1126 over before finding the IP stack. Otherwise clear IPv4 Enabled 1127 Multipath, clear IPv6 Enabled Multipath and clear Default to IP/ 1128 MPLS Multipath. 1130 6. On core networks where UDP and TCP ports are rarely used in 1131 multipath, clear all UDP and TCP related bits. On networks where 1132 multipath is configured to use TCP and UDP port numbers, these 1133 bits would be set. 1135 These networks can support very large LSP but cannot support LSP 1136 which require strict packet ordering with other labels below such an 1137 LSP, such as pseudowire labels. They may also misroute OAM packet 1138 which use GAL (see [RFC5586]) if they use the GAL label in 1139 determining the load balance. Generally the Link Bundle 1140 advertisements indicate a "Maximum LSP Bandwidth" that is equal to 1141 the "Unreserved Bandwidth" if Link Bundling is used with the all-ones 1142 component link. 1144 Good or bad, if the behavior is consistent, defaults can be 1145 configured in other LSR, such that an accurate guess can be made when 1146 no Multipath Link Capability TLV is available for a given link. 1148 For example, in many networks, any link of 10 Gb/s or less can be 1149 assumed to be a plain link (no multipath) while any link with a 1150 capacity greater than 10 Gb/s can be assumed to be a multipath These 1151 assumptions would hold if no 40 Gb/s or 100 Gb/s links are used. 1153 4.2.2. Netowrks with OA Capability on all Multipath 1155 Some networks, particularly edge networks which tend to be lower 1156 capacity, do not use Link Aggregation, and if they use Link Bundling 1157 at all, configure each LSR to place each LSP in its entirety on a 1158 single link bundle component link for all LSP. Some edge equipment 1159 only supports this link bundle behavior. 1161 This is equivalent to the following setting in the Multipath Node 1162 Capabilities sub-TLV or Multipath Link Capabilities sub-TLV. 1164 Set the Ordered Aggregate Enabled bit, 1166 Clear the Multipath Enabled bit. 1168 All remaining bits in the Flags field should be clear. 1170 The Max Depth and IP Depth should be set to zero. 1172 These networks can support LSP which require strict packet ordering, 1173 but cannot support very large LSP. 1175 Like the behavior described in Section 4.2.1, whether this behavior 1176 is good or bad, defaults can be configured which accurately guess the 1177 capabilities of links for which no Multipath Link Capability TLV is 1178 available. 1180 4.2.3. Legacy Netowrks with Mixed MP and OA Links 1182 Some network may support Ethernet Link Aggregation and all or a 1183 subset of LSR which place each LSP in its entirety on a single link 1184 bundle component link for all LSP. 1186 If the "Maximum LSP Bandwidth" is set as described in Section 4.2.1, 1187 then very large LSP can be supported over link bundles. Very large 1188 LSP cannot be supported on LSR which place each LSP in its entirety 1189 on a single link bundle component link for all LSP, but these are 1190 clearly indicated in signaling, 1192 In these mixed networks it may not be possible to reliably support 1193 LSP which require strict packet ordering. It is not possible to know 1194 where Ethernet Link Aggregation is used and it is not possible to 1195 accurately determine Link Bundling behavior on link bundles where 1196 "Maximum LSP Bandwidth" is equal to "Unreserved Bandwidth". 1198 Upgrading LSR to support Entropy Label on both LAG and Link Bundles 1199 would improve the ability to carry LSP which require strict packet 1200 ordering. To gain any benefit the LSP ingress would have to add ELI 1201 and EL. 1203 If not all LSR are upgraded, then the MPLS TE multipath extensions 1204 identify those LSR and multipath that have been upgraded. 1206 4.3. Transition to Multipath Extension Support 1208 If a Multipath Node Capability sub-TLV is not advertised (see 1209 Section 2.1), then the LSR does not support these multipath 1210 extensions. This allows detection of such nodes and if necessary 1211 application of defaults to cover legacy multipath such as typical 1212 Ethernet Link Aggregation Behavior. 1214 4.3.1. Simple Transitions 1216 For networks with LSR that do not support multipath extensions, 1217 transition is easiest if all legacy LSR support and are configured 1218 with a common link bundling behavior. If Ethernet Link Aggregation 1219 is not used, a single configured default is needed to cover LSR that 1220 do not advertise a Multipath Node Capability sub-TLV. 1222 If Ethernet Link Aggregation had been previously used on Legacy LSR, 1223 if possible LAG should be disabled and the members of the former LAG 1224 configured and advertised as a link bundle which uses the equivalent 1225 "all ones" behavior. 1227 If Ethernet Link Aggregation remains but can be identified in some 1228 way, such as links with capacity in excess of some value (for 1229 example: greater than 10 Gb/s), then defaults can be set up for these 1230 LAG. Alternately administrative attributes could be used [RFC3209]. 1232 The transition network in this case lacks the ability to determine 1233 the largest microflow that can pass through legacy nodes, but this 1234 was the case prior to transition for the entire network prior to 1235 transition. 1237 4.3.2. More Challenging Transitions 1239 Transition is made more difficult if legacy LSR in a network support 1240 Ethernet Link Aggregation but do not support Link Bundle and cannot 1241 be identified by simple means, or the newer LSR lack sufficient 1242 configuration capability to support conditional defaults. 1244 This situation is most easily handled if a small upgrade to such an 1245 LSR can advertise a fixed Multipath Node Capability sub-TLV giving 1246 the characteristics of the Ethernet Link Aggregation implementation 1247 on that node. Absent of such cooperation, the problem can be solved 1248 by configuration on newer LSR which allows association of a Multipath 1249 Node Capability sub-TLV with a specific legacy router ID and possibly 1250 a legacy router ID and link. 1252 LSR supporting Multipath Extensions will need to assign default 1253 values through configuration to these legacy LSR running Ethernet 1254 Link Aggregation. These default values serve to allow LSP which 1255 require strict packet ordering to avoid these legacy LSR. 1257 LSR which do not support [RFC4201] may be sufficiently rare that the 1258 ability to assign default values per legacy LSR or per [RFC3209] 1259 administrative attribute may not be needed in practice. 1261 5. IANA Considerations 1263 [ ... to be completed ... ] 1265 The symbolic constants IANA-TBD-1 through IANA-TBD-3 need to be 1266 replaced. Complete instructions, including identification of the 1267 number space for each of these will be added to a later version of 1268 this internet-draft. 1270 6. Security Considerations 1272 The combination of MPLS, MPLS-TP, and multipath does not introduce 1273 any new security threats. The security considerations for MPLS/GMPLS 1274 and for MPLS-TP are documented in [RFC5920] and 1275 [I-D.ietf-mpls-tp-security-framework]. 1277 7. References 1279 7.1. Normative References 1281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1282 Requirement Levels", BCP 14, RFC 2119, March 1997. 1284 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1285 (GMPLS) Signaling Functional Description", RFC 3471, 1286 January 2003. 1288 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 1289 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 1291 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 1292 Ayyangarps, "Encoding of Attributes for MPLS LSP 1293 Establishment Using Resource Reservation Protocol Traffic 1294 Engineering (RSVP-TE)", RFC 5420, February 2009. 1296 [RFC5786] Aggarwal, R. and K. Kompella, "Advertising a Router's 1297 Local Addresses in OSPF Traffic Engineering (TE) 1298 Extensions", RFC 5786, March 2010. 1300 7.2. Informative References 1302 [I-D.ietf-mpls-entropy-label] 1303 Kompella, K., Drake, J., Amante, S., Henderickx, W., and 1304 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 1305 draft-ietf-mpls-entropy-label-06 (work in progress), 1306 September 2012. 1308 [I-D.ietf-mpls-tp-security-framework] 1309 Fang, L., Niven-Jenkins, B., Mansfield, S., and R. 1310 Graveman, "MPLS-TP Security Framework", 1311 draft-ietf-mpls-tp-security-framework-04 (work in 1312 progress), July 2012. 1314 [I-D.villamizar-mpls-tp-multipath] 1315 Villamizar, C., "Use of Multipath with MPLS-TP and MPLS", 1316 draft-villamizar-mpls-tp-multipath-03 (work in progress), 1317 October 2012. 1319 [IEEE-802.1AX] 1320 IEEE Standards Association, "IEEE Std 802.1AX-2008 IEEE 1321 Standard for Local and Metropolitan Area Networks - Link 1322 Aggregation", 2006, . 1325 [ITU-T.G.800] 1326 ITU-T, "Unified functional architecture of transport 1327 networks", 2007, . 1330 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1331 and W. Weiss, "An Architecture for Differentiated 1332 Services", RFC 2475, December 1998. 1334 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 1335 McManus, "Requirements for Traffic Engineering Over MPLS", 1336 RFC 2702, September 1999. 1338 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 1339 Multicast Next-Hop Selection", RFC 2991, November 2000. 1341 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1342 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1343 Tunnels", RFC 3209, December 2001. 1345 [RFC3260] Grossman, D., "New Terminology and Clarifications for 1346 Diffserv", RFC 3260, April 2002. 1348 [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching 1349 (GMPLS) Architecture", RFC 3945, October 2004. 1351 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1352 Hierarchy with Generalized Multi-Protocol Label Switching 1353 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1355 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1356 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1357 Use over an MPLS PSN", RFC 4385, February 2006. 1359 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 1360 Associated Channel", RFC 5586, June 2009. 1362 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 1363 Networks", RFC 5920, July 2010. 1365 [RFC6107] Shiomoto, K. and A. Farrel, "Procedures for Dynamically 1366 Signaled Hierarchical Label Switched Paths", RFC 6107, 1367 February 2011. 1369 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 1370 J., and S. Amante, "Flow-Aware Transport of Pseudowires 1371 over an MPLS Packet Switched Network", RFC 6391, 1372 November 2011. 1374 Author's Address 1376 Curtis Villamizar (editor) 1377 Outer Cape Cod Network Consulting 1379 Email: curtis@occnc.com