idnits 2.17.1 draft-fredette-mpls-aggregation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 601 has weird spacing: '...ext hop combi...' -- 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 (November 1997) is 9652 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: 'MPLS-A' is defined on line 693, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ARA' -- Possible downref: Non-RFC (?) normative reference: ref. 'HEIN' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-A' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-F' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft A. Fredette 3 Expires May 1998 Bay Networks, Inc. 5 C. White 6 Bay Networks, Inc. 8 Loa Andersson 9 Ericsson Telecom 11 Paul Doolan 12 Ennovate Networks 14 November 1997 16 Stream Aggregation 18 20 Status of this Memo 22 This document is an Internet-Draft. Internet-Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its areas, 24 and its working groups. Note that other groups may also distribute 25 working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as ``work in progress.'' 32 To learn the current status of any Internet-Draft, please check the 33 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 34 Directories on ds.internic.net (US East Coast), nic.nordu.net 35 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 36 Rim). 38 Abstract 40 This document describes issues with aggregating streams of data in an 41 MPLS system and suggests alternatives for increasing the level of 42 aggregation possible. 44 1. Introduction 45 One of the important areas for the application of MPLS is in ATM 46 switching hardware. It has been recognized that non-VC-merging ATM 47 switches (the most common in existence today) require a significantly 48 larger number of labels than merge-capable switches. This number can 49 be even larger than many have realized if stream aggregation is not 50 applied intelligently. In Section 3, we examine the different levels 51 of stream aggregation that are possible. Then, in Section 4, we 52 discuss possible solutions for achieving the highest possible level 53 of aggregation. 55 2. Terminology 57 Terms used in this document are aligned as much as possible with 58 definitions provided in the MPLS Framework document [MPLS-F]. 60 Flow 62 A single instance of an application to application flow of data (as 63 in the RSVP and IFMP use of the term "flow") 65 Stream 67 An aggregate of one or more flows, treated as one aggregate for the 68 purpose of forwarding in L2 and/or L3 nodes (e.g., may be described 69 using a single label). In many cases a stream may be the aggregate 70 of a very large number of flows. Synonymous with "aggregate 71 stream". 73 merged stream 75 An aggregate of one or more streams such that the decision to 76 aggregate is local to the merging LSR. 78 aggregated stream 80 An aggregate of one or more streams such that the decision to 81 aggregate is made by some downstream LSR. 83 MPLS domain 85 a contiguous set of nodes which operate MPLS routing and forwarding 86 and which are also in one Routing or Administrative Domain 88 merge capable 90 An LSR capable of merging frames received with different labels 91 onto the same outgoing interface with the same label. The ATM 92 specific case, VC- merge capable, is the capability of an ATM 93 switch to merge cell streams without interleaving cells from 94 different AAL5 frames. 96 Port 98 Logical port that represents an ingress to an LSR. A single 99 physical interface may support multiple logical ports. 101 Note, in this document, the term stream may refer either to a single 102 flow or an aggregate of multiple flows or streams. A flow, however, 103 can never refer to a stream that is an aggregate. 105 The difference between a merged stream and an aggregated stream is 106 subtle. In particular, the term "aggregated stream" is somewhat 107 overloading the word aggregate. For the purpose of this document, 108 the terms "aggregate" and "aggregation" are used only in reference to 109 "aggregated streams", and are not used in reference to merged 110 streams. 112 3. Overview 114 It is useful for an MPLS network to aggregate streams that share the 115 same ingress-egress pair through a routing domain. For example, 116 consider the network in Figure 1 118 S1--A-------+ 119 | +-D1 120 | | 121 C-------D-+ 122 | | 123 | +-D2 124 S2--B-------+ 125 Figure 1: Sample MPLS Network 127 MPLS is used on internal links. Given sources S1 and S2 and 128 destinations D1 and D2, consider four best effort traffic streams: 130 - S1-A-C-D-D1 132 - S1-A-C-D-D2 134 - S2-B-C-D-D1 136 - S2-B-C-D-D2 138 All four streams use LSR D as the egress LSR of the MPLS domain. 139 Given that all four streams share the same stream descriptor (e.g., 140 they are all best effort), from the perspective of MPLS, it is 141 irrelevant that D1 and D2 are separate destinations. In this figure, 142 relative to these four streams, LSRs A and B are Ingress LSRs and LSR 143 D is an Egress LSR. We assume that LSRs A and B are merge capable. 145 Stream aggregation allows streams that share a common Ingress LSR (or 146 set of Ingress LSRs), Egress LSR and FEC to be aggregated into an 147 aggregate stream, thus reducing label consumption within the MPLS 148 network. 150 Sections 3.1 - 3.4 describe each of four different possibilities for 151 assigning labels. Note that downstream label allocation on demand is 152 used for the examples, although this is not necessarily a 153 requirement. 155 3.1 No Merge, No Aggregation 157 In the worst case, none of the internal switches are capable of 158 merging and no aggregation is performed. At each LSR, a different 159 label must be allocated for each label request received from an 160 upstream neighbor. There is no means of determining which label 161 requests can be aggregated. 163 For example, in Figure 1, LSR A makes independent label requests for 164 D1 and D2 to LSR C, its next hop. LSR B makes two similar requests. 165 Since LSR C is unable to perform merge, it requests two different 166 labels for D1 and two different labels for D2 from LSR D. LSR D 167 receives four label requests. From LSR Ds perspective, D1 and D2 are 168 in the same forwarding equivalence class (FEC), but because LSR D is 169 unaware of the history of the requests, it must respond 170 conservatively and assign a different label for each request. 172 In this example, the "history" of a request refers to information 173 that indicates the source of the request as well as the path taken. 174 Without this information, it is not possible for LSR D to distinguish 175 requests originated by LSR A from those originated by LSR B. 177 In networks that do not support merge and do not perform aggregation, 178 the number of LSPs setup can be expressed as: 180 LSPs = O(N^2 * D) 182 N = Number of ingress LSRs = Number of egress LSRs (every 183 ingress is also an egress) 184 D = Number of destination addresses per egress LSR 186 This follows from the fact that for every route that appears in an 187 ingress LSRs routing table, the LSR must request a separate label, 188 generating a separate LSP. Each ingress LSR will generate D LSPs to 189 each of N-1 egress LSRs. There are N ingress LSRs yielding O(N^2 * 190 D) LSPs for the entire network. A label space of this size can be 191 particularly problematical since D can easily be greater than O(N^2) 192 for a given routing domain. 194 3.2 No Merge With Aggregation 196 If it is possible to aggregate all the streams that share an LSP, 197 labels can be conserved. This is accomplished by including 198 information with each label request that uniquely identifies the path 199 that the request followed. This allows the egress LSR to assign a 200 single label for all requests that share the same path. 202 In the network shown in Figure 1, LSR A still makes two independent 203 label requests for D1 and D2, but attaches information that "A" is 204 the source of each request. LSR C in turn makes two requests for D1 205 and D2, but retains "A" as the source of the request. Similarly, LSR 206 B generates two requests which are propagated by LSR C indicating "B" 207 as the source. 209 When LSR D receives the four independent requests, it can assign a 210 single label for the two requests from source "A". Likewise it can 211 assign a single label for the two requests from source "B". 213 In networks that do not support merge but do perform aggregation, the 214 number of LSPs setup can be expressed as: 216 LSPs = O(N^2) 218 N = Number of ingress LSRs = Number of egress LSRs 220 D = Number of destination addresses per egress LSR 222 This is an improvement of O(D) over the previous example without 223 aggregation. 225 3.3 Merge, No Aggregation 227 When LSRs are capable of merging VCs, the number of separate VCs used 228 in the network is significantly reduced. Let's now assume that LSR C 229 in Figure 1 is capable of merging. Here, no aggregation is 230 performed. 232 LSR A makes independent label request for D1 and D2 to LSR C. LSR B 233 makes two similar requests. Since LSR C is now able to merge, it 234 requests from LSR D only a single label for D1 and a single label for 235 D2. The egress LSR D then receives only two label requests. If LSR D 236 is unaware of the capabilities of LSR C, LSR D must respond 237 conservatively and assign a different label for each request. 239 In networks that support Merge but do not perform aggregation, the 240 number of LSPs setup can be expressed as: 242 LSPs = O(N*D) 244 N = Number of ingress LSRs = Number of egress LSRs 246 D = Number of destination addresses per egress LSR 248 It should be noted, however, that in a system of fully merge capable 249 LSRs, a downstream LSR may aggregate as it desires as is described in 250 the next section. 252 3.4 Merge With Aggregation 254 The optimal case is when the network is capable of merging and 255 aggregation is performed. In this case, a single multipoint to point 256 LSP is used for all traffic to the egress LSR, regardless of the 257 final destination beyond the LSR. 259 Let's again assume that LSR C in Figure 1 is capable of merging. LSR 260 A makes two independent label requests for D1 and D2, but attaches 261 information that "A" is the source of each request. LSR B makes two 262 similar requests. Since LSR C is now able to perform merge, it 263 requests from LSR D only a single label for D1 and another for D2, 264 however, since LSR C is capable of merge, it changes the attached 265 information to indicate that "C" is the source of the request (acting 266 like an ingress LSR). 268 When LSR D receives the two requests, it can assign a single label 269 for both requests since they share the same "source" LSR. 271 In networks that support both merge and aggregation, the number of 272 LSPs setup can be expressed as: 274 LSPs = O(N) 276 N = Number of ingress LSRs = Number of egress LSRs 277 D = Number of destination addresses per egress LSR 279 This is an improvement of O(D) over the previous example without 280 aggregation. In general, aggregation will yield an improvement on 281 the order of the number of destination routes per LSR. 283 Using egress-based aggregation significantly reduces label 284 consumption within the MPLS network. This leads to a best case of 285 one label per egress per hop and a worst case of one label per 286 ingress/egress pair per hop in the MPLS domain. The best case can be 287 achieved by a network fully supporting merge. The worst case is seen 288 when using all non-merge capable LSRs, as this leads to a full-mesh 289 of LSPs between all LSRs. 291 4. Stream Aggregation 293 An aggregated stream can be described in terms of the Merge LSR, 294 Intermediate LSRs, and the Egress LSR. In Figure 2, the Merge LSR 295 (LSR A) is the first LSR of the aggregated stream and is responsible 296 for merging frames from multiple streams onto the same LSP with the 297 same label. Intermediate LSRs (LSR B) simply forward the data along 298 the LSP and require no special forwarding capabilities. The Egress 299 LSR (LSR C) is the last LSR in the aggregated path and is responsible 300 for de- aggregating the streams from the merged LSP. 302 +-D1 303 | 304 S1--A-------B-------C-+ 305 | 306 +-D2 308 Figure 2 An Aggregated Stream: Merge LSR, Intermediate LSRs and Egress LSR 310 A common scenario could be where the Merge LSR is an L3 router and is 311 the ingress LSR to the MPLS domain. Similarly, the Egress LSR could 312 be an L3 router and be the egress LSR from the MPLS domain. 314 The following sub-sections describe several possibilities for 315 achieving stream aggregation. 317 4.1 Merge LSR "Hides" Aggregation 319 Merge LSR A analyzes the routed path for both D1 and D2 and decides 320 that the LSP to Egress LSR C is the same for both destinations. LSR 321 A requests a label only for D1. The LSP for D1 is set up normally. 323 LSR A forwards data destined for D2 using the label assigned for D1. 325 Note that since the routing protocol boundary need not coincide with 326 the MPLS boundary, additional information is required in the routing 327 protocol to indicate which hops are MPLS LSRs such that when MPLS 328 analyzes the routed path, it can determine the extent of the MPLS 329 path. With OSPF, this could be accomplished by adding an opaque LSA 330 that is advertised by all LSRs. 332 This method hides the fact that D2 data is being aggregated onto the 333 same LSP used for D1. LSR A is the only node that is aware of any 334 aggregation taking place. This approach defeats the capability of 335 Egress LSR D to assign different labels for D1 and D2. When 336 downstream allocation is used, LSR D assigns a label for D1 and may 337 reasonably assume that only D1 traffic will arrive with this label. 338 Traffic for D2 will be unexpected and may inadvertently be dropped as 339 an error. 341 4.2 Merge LSR Aggregates to Egress LSR 343 In an approach similar to the one described in Section 4.1, each LSR 344 in a given OSPF area can request an LSP to each other LSR in the 345 area. Then, it can use its link-state database to determine which 346 routes should be forwarded to which egress LSR. This approach is 347 preferable the one described in Section 4.1 because the LSP ends at 348 the router and is not overloaded. 350 For example, in Figure 2, LSR A requests labels for LSRs B and C. 351 Then, it uses its link-state database to determine that LSR C is the 352 egress for D1 and D2. After making this determination, LSR A can use 353 the label for C on packets destined for D1 and D2. 355 One may note that this approach is similar to the one described in 356 [ARA] and [HEIN]. 358 4.3 Merge LSR Groups Requests 360 Again, Merge LSR A analyzes the routed path for both D1 and D2 and 361 decides that the LSP to Egress LSR C is the same for both 362 destinations. LSR A groups label requests for D1 and D2. 363 Intermediate LSR B maintains this grouping until Egress LSR C 364 receives the grouped request. LSR C assigns a single label for all 365 requests in the same group. 367 This approach allows the egress to choose whether to reply with the 368 same label for the two destinations. The major problem with this 369 approach is the overhead involved in dealing with topology changes. 370 Each topology change that affects the members of a group requires 371 that a new request be generated containing the all members of the 372 group. For example, if D2 were to become available at a different 373 Egress LSR, the original grouping with D1 would have to be re- 374 established with only D1. This is in addition to establishing a 375 group for D2 to the new Egress LSR. 377 4.4 Merge LSR ID in Requests 379 The key issue in aggregating multiple requests is the ability to 380 identify groups of requests that follow the same path, and can thus 381 be assigned to the same LSP. The previous sections describe methods 382 to solve this with brute force by having the Merge LSR determine and 383 maintain the groups. Use of the Merge LSR ID, and the next section 384 use of a Merge ID rely on the Egress LSR to determine which requests 385 can be grouped. The burden of maintaining the grouping throughout 386 topology changes is distributed among all LSRs in the path. 388 Information could be added to each label request that would uniquely 389 identify the merge LSR. This would allow the Egress LSR an indication 390 about which requests can be aggregated. For example, in the network 391 in Figure 3, LSR A generates a label request for D1 and another for 392 D2, attaching "A" as the Merge LSR ID. LSR C (not merge capable) 393 propagates these requests on to LSR D, leaving the Merge LSR ID as 394 "A" for both requests. LSR D can easily aggregate the two requests 395 since they share the same Merge LSR ID. 397 S1--A-------+ 398 | +-D1 399 | | 400 C-------D-+ 401 | | 402 | +-D2 403 S2--B-------+ 404 Figure 3 Using Merge LSR ID for Flow Aggregation 406 Since the Merge LSR ID is attached to each label request 407 independently, topology changes are easily handled. If a new 408 destination D3 appeared off of D, LSR A would generate a single 409 request for D3 with "A" as the Merge LSR ID. LSR C propagates the 410 request to LSR D who can determine that the same label used for the 411 previous requests from Merge LSR A can be used. 413 This approach suffers in that it only identifies unique Merge LSRs 414 and not unique paths from a given Merge LSR. As shown in more detail 415 in the next section, if packets from a given Merge LSR to a given 416 Egress LSR can take different paths, merging can be inappropriately 417 applied and cell interleaving can occur. This approach, therefore, 418 is not adequate. 420 4.5 Merge Identifier (MID) in Label Binding Requests 422 A slight modification to the previous algorithm solves the problem of 423 identifying unique paths from a Merge LSR to an Egress LSR. A Merge 424 Identifier (MID) is used to identify unique paths that traverse a 425 given link. Similar to labels, the MID only has local significance 426 between two LSRs and is mapped to a different MID at each hop on a 427 path. 429 MID values are assigned by the upstream neighbor and are included 430 with each label request. As a label request progresses from Merge 431 LSR to Egress LSR, the MID is mapped at each intermediate hop. At 432 any given link, all requests with the same MID are guaranteed to 433 share the same path from the same Merge LSR. Thus, at the Egress 434 LSR, all requests sharing the same MID can be safely aggregated onto 435 the same LSP. 437 Figure 4 shows a possible MID mapping from two Merge LSRs, A and B, 438 to a common Egress LSR D. Note that in this figure, LSR C is not 439 capable of merge, and thus is an Intermediate LSR. 441 MID=0 442 S1--A-------+ 443 | +-D1 444 | MID=3 | 445 C-------D-+ 446 | MID=2 | 447 | +-D2 448 S2--B-------+ 449 MID=0 450 Figure 4 MID mappings to indicate unique Merge LSRs 452 Each label request that LSR A originates includes an MID=0 (Null). 453 When LSR C receives a label request from A that must be propagated to 454 LSR D, LSR C allocates a unique MID=3 and maps to 455 . It propagates the request to D with MID=3. LSR B 456 uses MID=0, LSR C maps to . 458 Label requests received at D will have either an MID=3 (corresponding 459 to LSP A-C-D) or MID=2 (corresponding to LSP B-C-D). Regardless of 460 the number of label requests generated by LSR A, LSR D can use the 461 same label as long as the traffic descriptor for the requests is the 462 same. 464 The need for MID mappings is clear when considering multiple paths 465 from the same Merge LSR to the same Egress LSR. This may result, for 466 example, from multiple equal cost paths generated by the routing 467 protocol yielding a different next hop for different prefixes. 468 Figure 5 illustrates two separate paths from Merge LSR A to Egress 469 LSR E: A-B-D-E and A-C-D-E. If the Merge LSR ID approach from 470 Section 4.4 were used, LSR E would incorrectly assume that it could 471 use the same label for both requests. Then, when the streams are 472 merged at LSR D, cell interleaving can occur. 474 It is important to note here that a similar problem can occur when 475 using VP merge. In a commonly discussed approach, each ingress LSR 476 has a unique VCI that is uses in the transmission of frames on all 477 VPIs. If the multipath condition described above occurs, cell 478 interleaving can occur at LSR D. 480 MID=0 MID=5 481 +-------B-------+ 482 | | +-D1 483 | | MID=3 | 484 S1--A D-------E-+ 485 | | MID=2 | 486 | | +-D2 487 +-------C-------+ 488 MID=0 MID=6 489 Figure 5 MID mappings to indicate unique paths from same Merge LSR 491 In order for the egress to properly aggregate streams from LSR A, 492 Egress LSR E must be able to discern which path a request used. 493 Using only the Merge LSR ID in the request would result in LSR E 494 assigning the same label for all requests from LSR A. This results 495 in LSR D using the same outgoing label for streams from two different 496 incoming interfaces. As LSR D is not merge capable, it would 497 incorrectly merge/interleave cells from frames received from LSRs B 498 and C. 500 4.5.1 MID Tree 502 The mapping of MID values from Merge LSR to all possible Egress LSRs 503 forms a point-to-multipoint tree rooted at the Merge LSR. The leaves 504 of the tree are the Egress LSRs. All other LSRs are Intermediate 505 LSRs and are not merge capable. 507 The path from the Merge LSR to any Egress LSR on the MID tree is the 508 same as a valid routed data path. For any link on the MID tree, the 509 MID value used corresponds directly to a unique path from the Merge 510 LSR. 512 On any given link the number of MID values in use represents the 513 number of unique paths from all Merge LSRs that cross this link. 515 4.5.2 Merge Capable LSRs 517 In the event that an LSR in the middle of the MPLS domain is merge- 518 capable, the LSR simply acts as an Egress LSR to upstream neighbors 519 and as a Merge LSR to downstream neighbors. For example, in the 520 previous example (shown in Figure 5), if LSR D were merge-capable, it 521 would perform aggregation of requests from upstream neighbors B and 522 C. It would use a MID=0 for requests to LSR E allowing E to use a 523 single label. Figure 6 demonstrates the resulting LSPs and MID 524 mappings. 526 MID=0 MID=5 527 +-------B-------+ 528 | | +-D1 529 | | MID=0 | 530 S1--A D-------E-+ 531 | | MID=0 | 532 | | +-D2 533 +-------C-------+ 534 MID=0 MID=6 535 Figure 6 Merge LSRs in the middle of an MPLS domain 537 Note that each Merge LSR only uses single MID per interface (assuming 538 it is Merge LSR for all LSPs traversing this LSR). Since the 539 interfaces are independent, the same MID can be used for each 540 interface. In this case, the NULL MID of 0 can always be used. In a 541 network of only Merge- capable LSRs, the MID can always be left as 542 NULL. 544 Similar to label mappings, mapping of MIDs must include port 545 information as well. Thus the tuple maps to 546 . 548 4.5.3 Operation of Merge LSRs 550 The Merge LSR is the first LSR in the aggregate stream. It makes no 551 decisions regarding which outgoing streams can be aggregated. There 552 is no snooping of the routing table and no changes to the routing 553 protocol. 555 Operating conservatively, the Merge LSR makes independent label 556 requests just as it would without considering stream aggregation. 557 However, for each request generated, it attaches a MID=0, indicating 558 to the downstream LSR that it is acceptable to aggregate the stream 559 associated with this request with any other previous binding. (Note 560 that for an LSR operating as a Merge LSR for some LSPs and as an 561 Intermediate LSR for others, the MID would not always be NULL.) 563 When label bindings are received from downstream, the Merge LSR 564 simply incorporates the bindings into the interfaces label 565 information base (LIB). If the binding is in response to a previous 566 request (downstream allocation on demand), the stream to which the 567 binding applies and the MID of the binding must match that of the 568 corresponding request. 570 Any stream aggregation is performed downstream and is only noticeable 571 at the Merge LSR by multiple binding using the same label. 573 4.5.4 Operation of Intermediate LSRs 575 Intermediate LSRs are, in general, not merge capable. With regard to 576 the aggregated stream, the Intermediate LSR will only bind the same 577 label for multiple upstream streams (on the same incoming interface) 578 when the streams are assigned the same label by the next downstream 579 LSR. 581 As with the Merge LSR, all label requests are independent. For each 582 label request received on an incoming interface, a label request will 583 be generated and sent to the next hop according to the local LSR's 584 routing table. A unique MID is attached to each request sent 585 downstream for each unique tuple. 587 Label bindings received from downstream LSRs will contain a stream 588 (e.g., a route prefix), the assigned label and a MID. Flow 589 aggregation performed downstream is noticeable at the Intermediate 590 LSR by multiple streams using the same label and the same MID. It is 591 an error if the same label is used for two streams that do not have 592 the same MID. 594 When allocating a label for a new stream to an upstream LSR, the 595 Intermediate LSR may use a label in use for an existing stream (or 596 streams) on the same incoming interface if the following conditions 597 are met: 599 - The incoming MID of the new stream matches the incoming MID of 600 the existing stream(s) 601 - The new and existing streams use the same next hop combined with 602 condition 1, this implies that the outgoing MID of the new and 603 existing streams is the same 605 - The same label has been assigned by the downstream LSR for the 606 new and existing streams 608 If any of these conditions are not met, the Intermediate LSR must 609 allocate a new label for the upstream neighbor. If at a later time 610 the conditions are satisfied, the Intermediate LSR may release the 611 previous binding and bind the stream to the label of the exiting 612 stream(s). 614 4.5.5 Operation of Egress LSRs 616 The Egress LSR is responsible for determining whether multiple 617 streams may be aggregated. All streams that share the same MID are 618 eligible for aggregation. 620 Again, all label requests are independent. Each label request 621 received from upstream will contain an MID. 623 When allocating a label for a new stream to an upstream LSR, the 624 Egress LSR may use a label in use for an existing stream (or streams) 625 on the same incoming interface if the following condition is met: 627 - The incoming MID of the new stream matches the incoming MID of 628 the existing stream(s) 630 If this condition is not met, the Egress LSR must allocate a new 631 label for the upstream neighbor. If at a later time, the condition 632 is satisfied, the Egress LSR may release the previous binding and 633 bind the stream to the label of the exiting stream(s). 635 4.5.6 Reserved MID Values 637 It may be desirable to designate certain MID values or ranges of 638 values to be used for special circumstances. 640 4.5.6.1 NoAggregateValue 642 When setting up a point-to-point stream, it may be desirable for a 643 separate LSP to be setup that is not aggregated with any other 644 streams. A special MID=NoAggregateValue indicates to Egress LSRs that 645 a separate label should be allocated for this stream and not used for 646 any other stream. Possible uses include: 648 - RSVP streams 650 - Dedicated LSPs for control traffic 652 4.5.6.2 UnassignedMID 654 LSRs that allocate and distribute labels for streams before receiving 655 requests may use this MID value to indicate to the upstream LSR that 656 the associated label can be used for any MID value. The downstream 657 LSR assigning the label awaits an acknowledgment from upstream. A 658 positive acknowledgment must include a MID value associated with this 659 binding. 661 Using the UnassignedMID value allows upstream LSRs to make use of a 662 label before it is associated with a MID. It may shorten the setup 663 time as it does not require a full request to the downstream LSR and 664 then a response. 666 5. Conclusions 668 Four levels of aggregation and merging were described in this 669 document. It was shown that for non-merge capable LSRs, if left 670 unchecked, lack of aggregation can cause an explosion of the label 671 space. 673 Two viable alternatives were proposed: 675 1) Use a link-state routing protocol to decide at the ingress what 676 streams to aggregate (Section 4.2). 678 2) Use a merge ID (MID) in label binding requests (Section 4.5). 680 Furthermore, if option 2) is used, it only places an additional 681 burden on non-VC-merge capable switches. 683 6. References 685 [ARA] R. Coltun, J Heinanen, "The OSPF Address Resolution 686 Advertisement Option", Internet Draft, November 1997, 687 . 689 [HEIN] Heinanen, J., "Intra-area IP unicast among routers over 690 legacy ATM", Internet Draft, July 1997, 691 693 [MPLS-A] E. Rosen, A. Viswanathan, R. Callon, A Proposed 694 Architecture for MPLS, Internet Draft , August 1997. 697 [MPLS-F] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, 698 A. Viswanathan, A Framework for Multiprotocol Label 699 Switching, Internet Draft 700 , August 1997. 702 Author's Address 704 Andre N. Fredette 705 Bay Networks, Inc. 706 3 Federal St. 707 Billerica, MA 01821 708 Phone: (978) 916-8524 709 EMail: fredette@baynetworks.com 711 Christopher J. White 712 Bay Networks, Inc. 713 3 Federal St. 714 Billerica, MA 01821 715 Phone: (978) 916-4712 716 EMail: cwhite@baynetworks.com 718 Loa Andersson 719 Ericsson 720 Phone: + 46 8 719 52 67 721 email: loa.andersson@etx.ericsson.se 723 Paul Doolan 724 Ennovate Networks 725 330 Codman Hill Rd 726 Marlborough MA 01719 727 Phone: 978 263-2002 728 email: pdoolan@cisco.com