idnits 2.17.1 draft-kompella-mpls-rsvp-ecmp-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5420, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3473, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3209, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3209, updated by this document, for RFC5378 checks: 1998-11-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2015) is 3336 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) == Unused Reference: 'RFC4875' is defined on line 519, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 548, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft Juniper Networks 4 Updates: 3209, 3473, 5420 M. Hellers 5 (if approved) LINX 6 Intended status: Standards Track R. Singh 7 Expires: September 10, 2015 Juniper Networks 8 March 9, 2015 10 Multi-path Label Switched Paths Signaled Using RSVP-TE 11 draft-kompella-mpls-rsvp-ecmp-06.txt 13 Abstract 15 This document describes extensions to Resource ReSerVation Protocol - 16 Traffic Engineering for the set up of multi-path Traffic Engineered 17 Label Switched Paths (LSPs) in Multi Protocol Label Switching (MPLS) 18 and Generalized MPLS networks, i.e., LSPs that conform to traffic 19 engineering constraints, but follow multiple independent paths from 20 source to destination. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 10, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Conventions used in this document . . . . . . . . . . . . 4 59 2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Multi-path Label Switched Paths . . . . . . . . . . . . . 5 61 2.2. ECMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 8 63 2.4. The Capabilities of TE-based Load Balancing . . . . . . . 9 64 3. Operation of MLSPs . . . . . . . . . . . . . . . . . . . . . . 10 65 3.1. Signaling MLSPs . . . . . . . . . . . . . . . . . . . . . 10 66 3.1.1. Indicating Equi-bandwidth (EB) nature . . . . . . . . 10 67 3.2. Label Allocation . . . . . . . . . . . . . . . . . . . . . 10 68 3.3. Bandwidth Accounting . . . . . . . . . . . . . . . . . . . 10 69 3.4. MLSP Data Plane Actions . . . . . . . . . . . . . . . . . 11 70 4. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 79 1. Introduction 81 In selecting a protocol for setting up and signaling "tunnel" Labeled 82 Switched Paths (LSPs) in Multi Protocol Label Switching (MPLS) and 83 Generalized MPLS (GMPLS) networks, one first chooses whether one 84 wants Equal Cost Multi-Path (ECMP) load balancing or Traffic 85 Engineering (TE). For the former, one uses the Label Distribution 86 Protocol (LDP) ([RFC5036]); for the latter, the Resource ReSerVation 87 Protocol - Traffic Engineering (RSVP-TE) ([RFC3209]). [Two other 88 criteria, the need for fast protection and the desire for less 89 configuration, are no longer the deciding factors they used to be, 90 thanks to "IP fast reroute" ([RFC5286]) and "RSVP-TE automesh" 91 ([RFC4972])]. 93 This document describes how one can set up a tunnel LSP that has both 94 ECMP and TE characteristics using RSVP-TE. The techniques described 95 in this document can be used to create a "Multipath LSP" (MLSP) to a 96 destination, that consists of several "sub-LSPs", each potentially 97 taking a different path through the network to the destination. The 98 techniques can also be used to create a single MLSP to multiple 99 equivalent destinations (such as equidistant BGP nexthops announcing 100 a common set of reachable addresses), such that each destination is 101 served by one or more sub-LSPs. 103 There are several alternatives to choose from when considering MLSPs. 104 One is whether the ingress Label Switching Router (LSR) computes (or 105 otherwise obtains) the full path for each sub-LSP, or whether LSRs 106 along the various paths can compute paths further downstream (using 107 techniques such as "loose hop expansion", as in [RFC5152]). Another 108 is whether the various paths that make up the MLSP have equal cost 109 (or distance) from ingress to egress (i.e., ECMP), whether they may 110 have differing costs. Finally, one can choose whether to terminate a 111 multi-path LSP on a single egress or on several equivalent egresses. 112 For now, the first of each of these alternatives is assumed; future 113 work can explore other choices. 115 1.1. Terminology 117 The term Multipath LSP, or MLSP, will be used to denote the (logical) 118 container LSP from an ingress LSR to one or more egress LSR(s). An 119 MLSP is the unit of configuration and management. 121 An MLSP consists of one or more "sub-LSPs". A sub-LSP consists of a 122 single path from the ingress of the MLSPs to one of its egresses. A 123 sub-LSP is the unit of signaling of an MLSP. An Explicit Route 124 Object (ERO) will be used to define the path of a sub-LSP. 126 The "downstream links" of an MLSP Z at LSR X is the union of the 127 downstream links of all sub-LSPs of Z traversing X. Similarly, the 128 "upstream links" of an MLSP Z at LSR X is the union of upstream links 129 of all sub-LSPs of Z traversing X. 131 The agent that takes the configuration parameters of a tunnel and 132 computes the corresponding paths is called the Path Computation Agent 133 (PCA). The PCA is responsible for acquiring the tunnel 134 configuration, computing the paths of the sub-LSPs, and, if the PCA 135 is not co-located with the ingress, informing the ingress about the 136 tunnel and the EROs for the sub-LSPs. 138 1.2. Conventions used in this document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 2. Theory of Operation 146 2.1. Multi-path Label Switched Paths 148 An MLSP is configured with various constraints associated with TE 149 LSPs, such as destination LSR(s), bandwidth (on a per-class basis, if 150 desired), link colors, Shared Risk Link Groups, etc. [Auto-mesh 151 techniques ([RFC4972]) can be used to reduce configuration; this is 152 not described further here.] In addition, parameters specifically 153 related to MLSPs, such as how many (or the maximum number of) sub- 154 LSPs to create, whether traffic should be split equally across sub- 155 LSPs or not, etc. may also be specified. This configuration lives on 156 the PCA, which is responsible for computing the paths (i.e., the 157 EROs) for the various sub-LSPs. The PCA informs the ingress LSR 158 about the MLSP and the constituent sub-LSPs, including EROs and 159 bandwidths. 161 The PCA uses the configuration parameters to decide how many sub-LSPs 162 to compute for this MLSP, what paths they should take, and how much 163 bandwidth each sub-LSP is responsible for. Each sub-LSP MUST meet 164 all the constraints of the MLSP (except bandwidth). The bandwidths 165 (per-class, if applicable) of all the sub-LSPs MUST add up to the 166 bandwidth of the MLSP. A Path Computation Element ([RFC4655]) that 167 is multi-path LSP-aware may be used as the PCA. 169 Having computed (or otherwise obtained) the paths of all the sub- 170 LSPs, the ingress A then signals the MLSP by signaling all the 171 individual sub-LSPs across the MPLS/GMPLS network. To do this, the 172 ingress first picks an MLSP ID, a 16-bit number that is unique in the 173 context of the ingress. This ID is used in an ASSOCIATION object 174 that is placed in each sub-LSP to let all transit LSRs know that the 175 sub-LSPs belong to the same MLSP. 177 If multiple sub-LSPs of the same MLSP pass through LSR Y, and Y has 178 downstream links YP, YQ and YR for the various sub-LSPs, then Y has 179 to load balance incoming traffic for the MLSP across the three 180 downstream links in proportion to the sum of the bandwidths of the 181 sub-LSPs going to each downstream (see Figure 1). 183 One must distinguish carefully between the signaled bandwidth of a 184 sub-LSP, a static value capturing the expected or maximum traffic on 185 the sub-LSP, and the instantaneous traffic received on a sub-LSP, a 186 constantly varying quantity. Suppose there are three sub-LSPs 187 traversing Y, with bandwidths 10Gbps, 20Gbps and 30Gbps, going to P, 188 Q and R respectively. Suppose further Y receives some traffic over 189 each of these sub-LSPs. Y must balance this received traffic over 190 the three downstream links YP, YQ and YR in the ratio 1:2:3. 192 2.2. ECMP 194 ------------- M ----- 195 / \ 196 / --- P -- \ 197 / / \ \ 198 A --- X --- Y --- Q --- T --- B 199 \ \ / | 200 \ --- R ------- | 201 \ | 202 ------- S ---------- 204 An example network illustrating ECMP. Assume that paths AMB, AXYPTB, 205 AXYQTB, AXYRB and AXSB all have the same path length (cost). 207 Figure 1: Example Network Topology 209 In an IP or LDP network, incoming traffic arriving at A headed for B 210 will be split equally between M and X at A. Similarly, traffic for B 211 arriving at Y will be split equally among P, Q and R. If the traffic 212 arriving at A for B is 120Gbps, then the AMB path will carry 60Gbps, 213 the paths AXYPTB, AXYQTB and AXYRB will each carry 10Gbps, and the 214 AXSB path will carry 30Gbps. We'll call this "IP-style" load 215 balancing. 217 Note: all load balancing is subject to the overriding requirement of 218 mapping the same "flow" to the same downstream. (What constitutes a 219 "flow" is beyond the scope of this document.) This requirement takes 220 precedence over all attempts to balance traffic among downstreams. 221 Thus, the statements above (e.g., "the AMB path will carry 60Gbps") 222 are to be interpreted as ideal targets, not hard requirements, of 223 load balancing. 225 One can simulate the IP or LDP ECMP behavior with TE-based ECMP by 226 creating an MLSP with five sub-LSPs S1 through S5 taking paths AMB, 227 AXYPTB, AXYQTB, AXYRB and AXSB, with bandwidths 60Gbps, 10Gbps, 228 10Gbps, 10Gbps and 30Gbps, respectively. 230 With such an arrangement, the MB link carries 60Gbps while the RB 231 link carries just 10Gbps. If one wishes instead to carry equal 232 amounts of traffic on the links incoming to B, then one could arrange 233 the sub-LSPs S1 to S5 to have bandwidths 30Gbps, 15Gbps, 15Gbps, 234 30Gbps and 30Gbps, respectively. In this case, the bandwidth on each 235 of the four links going to B is 30Gbps, illustrating some of the 236 capabilities of TE-based ECMP. 238 Staying with this example, A has one sub-LSP of bandwidth 30Gbps to M 239 and four sub-LSPs of total bandwidth 90Gbps through X. Thus, A should 240 load balance traffic in the ratio 1:3 between the AM and the AX 241 links. Similarly, X has three sub-LSPs of total bandwidth 60Gbps to 242 Y and one sub-LSP of bandwidth 30Gbps to S, so X should load balance 243 traffic 2:1 between Y and S. Y has a sub-LSP of bandwidth 15Gbps to 244 each of P and Q and one sub-LSP of bandwidth 30Gbps to R, so Y should 245 load balance traffic 1:1:2 among P, Q and R, respectively. Thus, in 246 general, TE-based ECMP does not assume equal distribution of traffic 247 among downstream LSRs, unlike IP- or LDP-style ECMP. 249 ---U--- 250 | | 251 --L-- --P-- | --V-- | 252 / \ / \|/ \| 253 A S---Q---T---W---B 254 \ / \ /|\ /| 255 --M-- --R-- | --X-- | 256 | | 257 ---Y--- 259 Another example network illustrating 30 ECMP paths between A and B. 261 Figure 2: Another Network Topology 263 In Figure 2, there are potentially 2x3x5=30 ECMP paths between A and 264 B. With IP or LDP, exploiting all these paths is straightforward, and 265 doesn't need a lot of state. With an MLSP as seen so far, this would 266 require 30 sub-LSPs to achieve equivalent load balancing. This 267 suggests that a different approach is needed to efficiently achieve 268 IP-style load balancing with TE LSPs. To this end, we introduce the 269 notion of "equi-bandwidth" (EB) sub-LSPs and EB MLSPs. A sub-LSP is 270 equi-bandwidth if its "E" bit is set (see Section 3.1.1). An MLSP is 271 equi-bandwidth if all of its sub-LSPs are equi-bandwidth. 273 If a set of EB sub-LSPs of the same MLSP traverse an LSR S, say to 274 downstream links SP, SQ and SR, then S MUST attempt to load balance 275 traffic received on these EB sub-LSPs equally among the links SP, SQ 276 and SR, independent of how many sub-LSPs go over each of these links. 277 Furthermore, S MUST redistribute traffic received from each of its 278 upstream LSRs, and SHOULD redistribute all traffic received from 279 upstream as a whole. One can do the former by signaling the same 280 label to each of its upstream LSRs; one can do the latter by 281 signaling the same label to all upstream LSRs (see Section 3.2). For 282 example, in Figure 2, if L sends 12Gbps of traffic to S and M sends 283 18Gbps to S, S can redistribute L's traffic by sending 4Gbps to each 284 of P, Q and R; and can similarly send 6Gbps of M's traffic to each of 285 P, Q and R. Alternatively, S can load balance the aggregate 30Gbps of 286 traffic received from L and M to each of P, Q and R, thus sending 287 10Gbps to each. EB sub-LSPs have an added benefit of not requiring 288 unequal load balancing across links, which may pose problems for some 289 hardware. 291 Given the notion of EB sub-LSPs and EB MLSPs, A can signal an EB MLSP 292 Z comprised of five EB sub-LSPs E1 through E5 with the following 293 paths: ALSPTUB, AMSQTVB, ALSRTWB, AMSPTXB and ALSQTYB (respectively). 294 Then, A has two downstream links for the five sub-LSPs, AL and AM, 295 between which A will load balance equally. Similarly, S has three 296 downstream links, SP, SQ and SR; and T has five downstreams, TU, TV, 297 TW, TX and TY. Thus the load balancing behavior of the MLSP will 298 replicate IP load balancing. The state required for an EB MLSP to 299 achieve IP-style load balancing is somewhat greater than for LDP 300 LSPs, but significantly less than that for multiple "regular" TE 301 LSPs, or for a non-EB MLSP. 303 2.3. Discussion 305 Some of the power of TE-based ECMP was illustrated in the above 306 examples. Another is ability to request that all sub-LSPs avoid 307 links colored red. If in the example network in Figure 1, the QT 308 link is colored red but all other links are not, then there are four 309 ECMP paths that satisfy these constraints, and the traffic 310 distribution among them will naturally be different than it would 311 without the link color constraint. 313 One can also ask whether an MLSP with sub-LSPs is any better than N 314 "regular" LSPs from the same ingress to the same egress. Here are 315 some benefits of an MLSP: 317 1. With an MLSP, there is a single entity to provision, manage and 318 monitor, versus N separate entities in the case of LSPs. A 319 consequence of this is that with an MLSP, changes in topology can 320 be dealt with easily and autonomously by the ingress LSR, by 321 adding, changing or removing sub-LSPs to rebalance traffic, while 322 maintaining the same TE constraints. With individual LSPs, such 323 changes would require changes in configuration, and thus are 324 harder to automate. 326 2. An ingress LSR, knowing that an MLSP is for load balancing, can 327 decide on an optimum number of sub-LSPs, and place them 328 appropriately across the network to optimize load balancing. On 329 the other hand, an ingress LSR asked to create N independent LSPs 330 will do so without regard to whether N is a good number of equal 331 cost paths, and, more importantly, may place several of the N 332 LSPs on the same path, defeating the purpose of load balancing. 334 3. The EB sub-LSP mechanism will, in many cases, result in far fewer 335 sub-LSPs than independent LSPs and thus less control plane state. 337 4. Finally, an MLSP will usually have less data plane state than N 338 independent LSPs: whenever multiple sub-LSPs traverse a link, a 339 single label will be used for all of them, whereas if multiple 340 LSPs traverse a link, each will need a separate label. 342 2.4. The Capabilities of TE-based Load Balancing 344 Definition: Let G=(V, E) be a directed graph (or network), and let A 345 and B in V be two nodes in G. Let T be the traffic arriving at A 346 destined for B. T is said to be "IP-style" load balanced if for every 347 node X on a shortest path from A to B, the portion of T arriving at X 348 is split equally among all nodes Yi that are adjacent to X and are on 349 a shortest path from X to B. 351 Theorem: An MLSP can accurately mimic IP-style load balancing between 352 any two nodes in any network. 354 Proof: left to the reader. 356 Corollary: MLSPs provide a strictly more powerful load balancing 357 mechanism than IP-style load balancing. 359 3. Operation of MLSPs 361 3.1. Signaling MLSPs 363 Sub-LSPs of an MLSP are tied together using ASSOCIATION objects. 364 ASSOCIATION objects have a new Association Type for MLSPs (TBD). The 365 Association ID is chosen by the ingress of the MLSP; the Association 366 Source is the loopback address of the ingress of the MLSP. All sub- 367 LSPs containing an ASSOCIATION object with a given Association Source 368 and Type belong to the same MLSP. 370 3.1.1. Indicating Equi-bandwidth (EB) nature 372 A sub-LSP is considered equi-bandwidth if its Path message carries 373 the optional LSP_ATTRIBUTES object ([RFC5420]) with an EBC (equi- 374 bandwidth capability) flag in the Attribute Flags TLV. The bit 375 number for the EBC flag is yet to be assigned by IANA. 377 3.2. Label Allocation 379 A LSR S that receives Path messages for several sub-LSPs of the same 380 MLSP from the same upstream LSR SHOULD allocate the same label for 381 all the sub-LSPs. This simplifies load balancing for the aggregate 382 traffic on those sub-LSPs. If the sub-LSPs are EB sub-LSPs, then S 383 SHOULD allocate the same label for all EB sub-LSPs of the same MLSP 384 that pass through S, regardless of which upstream LSR they come from. 385 This allows S to load balance the aggregate traffic received on the 386 MLSP, as all the MLSP traffic arrives at S with the same label. 387 However, an LSR that can achieve the load balancing requirements 388 independent of label allocation strategies is free to do so. 390 3.3. Bandwidth Accounting 392 Since MLSPs are traffic engineered, there needs to be strict 393 bandwidth accounting, or admission control, on every link that an 394 MLSP traverses. For non-EB sub-LSPs, this is straightforward, and 395 analogous to regular TE LSPs. However, for EB sub-LSPs, two new 396 procedures are needed, one for signaling bandwidth, and the other for 397 admission control. First, for a given MLSP Z, an LSR X MUST ensure 398 (via signaling) that the total incoming bandwidth of EB sub-LSPs of 399 MLSP Z is divided equally among all the downstream links of X which 400 at least one of the EB sub-LSPs traverses. Second, LSR X MUST ensure 401 that, for each upstream link of X, there is sufficient bandwidth to 402 accommodate all EB sub-LSPs of MLSP Z that traverse that link. 404 Let's take the example of Figure 2, with MLSP Z having five EB sub- 405 LSPs E1 to E5, and say that MLSP Z is configured with a bandwidth of 406 30Gbps. Here are some of the steps involved. 408 1. LSR A, being the ingress, has no upstream links. A has two 409 downstream links, AL and AM. Three EB sub-LSPs of MLSP Z 410 traverse AL, and two traverse AM. A MUST signal a total of 411 15Gbps for the sub-LSPs to L, and a total of 15Gbps for the sub- 412 LSPs to M. The required bandwidth may be divided up among the 413 sub-LSPs to L (similarly, to M) in any manner so long as the 414 total is 15Gbps. For example, A can signal sub-LSP E1 with 415 15Gbps, and sub-LSPs E3 and E5 with 0 bandwidth. 417 2. LSR L has one upstream link AL with three EB sub-LSPs with a 418 total bandwidth of 15Gbps. L MUST ensure that 15Gbps is 419 available for the AL link. If this bandwidth is not available, L 420 MUST send a PathErr on ALL of the EB sub-LSPs on the AL link. 421 Let's assume that the AL link has sufficient bandwidth. 423 3. Next, it is up to L to decide how to divide the incoming 15Gbps 424 among the three downstream EB sub-LSPs to S. Say L signals sub- 425 LSP E1 with 15Gbps, and the others with 0 bandwidth. 427 4. LSR S has two upstream links: LS with three EB sub-LSPs with a 428 total bandwidth of 15Gbps, and MS with two EB sub-LSPs with a 429 total bandwidth of 15Gbps. S MUST ensure that 15Gbps is 430 available for each of the LS and MS links. S has thus a total 431 incoming bandwidth of 30Gbps on MLSP Z. S has to divide this 432 equally among its downstream links SP, SQ and SR, yielding 10Gbps 433 each. S MUST ensure that the total bandwidth requested on the SP 434 link for sub-LSPs E1 and E4 is 10Gbps. S may choose to signal 435 these sub-LSPs with 5Gbps each. Similarly for the SQ and SR 436 links. 438 There are two important points to note here. One is that the 439 bandwidth reservation (TSpec) for a given EB sub-LSP can (and usually 440 will) change hop-by-hop. The second is that as new EB sub-LSPs are 441 signaled for an MLSP, the bandwidth reservations for existing EB sub- 442 LSPs belonging to the same MLSP may have to be updated. To minimize 443 these updates, it is RECOMMENDED that the first EB sub-LSP on a link 444 be signaled with the total required bandwidth (as far as is known), 445 and later sub-LSPs on the same link be signaled with 0 bandwidth. 447 3.4. MLSP Data Plane Actions 449 Traffic intended to be sent over an MLSP is determined at the ingress 450 LSR by means outside the scope of this document, and at transit LSRs 451 by the label(s) assigned by the transit LSR to its upstream LSRs. In 452 the case of non-EB sub-LSPs, this traffic is load balanced across 453 downstream links in the ratio of the bandwidths of the sub-LSPs that 454 comprise the MLSP. In the case of EB sub-LSPs, the traffic belonging 455 to an MLSP from an upstream LSR (or better still, the aggregate 456 traffic for the MLSP from all upstream LSRs) is load balanced equally 457 among all downstream links. 459 As noted above, the overriding concern is that flows are mapped to 460 the same downstream link (except when the MLSP or some constituent 461 sub-LSPs are changing); this is typically done by hashing fields that 462 define a flow, and mapping hash results to different downstream LSRs. 463 Hash-based load balancing typically assumes that the numbers of flows 464 is sufficiently large and the bandwidth per flow is reasonably well- 465 balanced so that the results of hashing yields reasonable traffic 466 distribution. 468 Entropy labels ([RFC6790] and [RFC6391]) can be used to improve load 469 balancing at intermediate nodes. 471 4. Manageability 473 TBD 475 5. Security Considerations 477 This document introduces no new security concerns in the setup and 478 signaling of LSPs using RSVP-TE, or in the use of the RSVP protocol. 479 [RFC2205] specifies the message integrity mechanisms for RSVP 480 signaling. These mechanisms apply to RSVP-TE signaling of MLSPs 481 described in this document, and are highly recommended pending newer 482 integrity mechanisms for RSVP. 484 6. Acknowledgments 486 The author would like to thank the Routing Protocol group at Juniper 487 Networks for their questions, comments and encouragement for this 488 proposal. While many participated, special thanks go to Yakov 489 Rekhter, John Drake and Rahul Aggarwal. Many thanks too to John for 490 suggesting the use of ASSOCIATION objects. 492 7. IANA Considerations 494 IANA is requested to assign the following: 496 A new Association Type for MLSP. This Association Type is to be used 497 for ASSOCIATION objects with C-Type 1 (IPv4 Source) and 2 (IPv6 498 Source). 500 A new flag in the Attribute Flags TLV in the LSP_ATTRIBUTES object 501 ([RFC5420]: a bit number for the EBC (equi-bandwidth capability) to 502 indicate that a specific sub-LSP is an equi-bandwidth sub-LSP. 504 8. References 506 8.1. Normative References 508 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 509 Requirement Levels", BCP 14, RFC 2119, March 1997. 511 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 512 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 513 Functional Specification", RFC 2205, September 1997. 515 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 516 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 517 Tunnels", RFC 3209, December 2001. 519 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 520 "Extensions to Resource Reservation Protocol - Traffic 521 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 522 Switched Paths (LSPs)", RFC 4875, May 2007. 524 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 525 Ayyangarps, "Encoding of Attributes for MPLS LSP 526 Establishment Using Resource Reservation Protocol Traffic 527 Engineering (RSVP-TE)", RFC 5420, February 2009. 529 8.2. Informative References 531 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 532 Element (PCE)-Based Architecture", RFC 4655, August 2006. 534 [RFC4972] Vasseur, JP., Leroux, JL., Yasukawa, S., Previdi, S., 535 Psenak, P., and P. Mabbey, "Routing Extensions for 536 Discovery of Multiprotocol (MPLS) Label Switch Router 537 (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, 538 July 2007. 540 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 541 Specification", RFC 5036, October 2007. 543 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 544 Path Computation Method for Establishing Inter-Domain 545 Traffic Engineering (TE) Label Switched Paths (LSPs)", 546 RFC 5152, February 2008. 548 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 549 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 550 May 2008. 552 [RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP Fast 553 Reroute: Loop-Free Alternates", RFC 5286, September 2008. 555 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 556 J., and S. Amante, "Flow-Aware Transport of Pseudowires 557 over an MPLS Packet Switched Network", RFC 6391, 558 November 2011. 560 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 561 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 562 RFC 6790, November 2012. 564 Authors' Addresses 566 Kireeti Kompella 567 Juniper Networks 568 1194 N. Mathilda Ave. 569 Sunnyvale, CA 94089 570 US 572 Email: kireeti.kompella@gmail.com 574 Mike Hellers 575 LINX 577 Email: mikeh@linx.net 579 Ravi Singh 580 Juniper Networks 582 Email: ravis@juniper.net