idnits 2.17.1 draft-baker-rsvp-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-26) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 690 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 1999) is 9202 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) -- Missing reference section? 'CSZ' on line 78 looks like a reference -- Missing reference section? 'EF' on line 183 looks like a reference -- Missing reference section? 'Guerin' on line 782 looks like a reference -- Missing reference section? 'Bernet' on line 785 looks like a reference -- Missing reference section? 'IP' on line 791 looks like a reference -- Missing reference section? 'HOSTREQ' on line 793 looks like a reference -- Missing reference section? 'FRAMEWORK' on line 797 looks like a reference -- Missing reference section? 'PRINCIPLES' on line 801 looks like a reference -- Missing reference section? 'ASSURED' on line 805 looks like a reference -- Missing reference section? 'BROKER' on line 810 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft RSVP Reservation Aggregation February 1999 4 Aggregation of RSVP for IP4 and IP6 Reservations 5 draft-baker-rsvp-aggregation-00.txt 7 This document is an Internet-Draft and is in full conformance with all 8 provisions of Section 10 of RFC 2026. Internet Drafts are 9 working documents of the Internet Engineering Task Force 10 (IETF), its Areas, and its Working Groups. Note that other 11 groups may also distribute working documents as Internet 12 Drafts. 14 Internet Drafts are valid for a maximum of six months and may 15 be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet Drafts as reference 17 material or to cite them other than as a "work in progress". 18 Comments should be made to the authors and the rsvp@isi.edu 19 list. 21 Abstract 23 A key problem in the design of RSVP version 1 is, as noted in 24 its applicability statement, that it lacks facilities for 25 aggregation of individual reserved sessions into a common 26 class. The use of such aggregation is recommended in the paper 27 by Clark, Shenker, and Zhang in SIGCOMM '92, and required for 28 scalability. 30 This document describes the use of a single RSVP reservation 31 to aggregate other RSVP reservations across a transit routing 32 region, in a manner conceptually similar to the use of Virtual 33 Paths in an ATM network. It proposes a way to dynamically 34 create the aggregate reservation, classify the traffic for 35 which the aggregate reservation applies, determine how much 36 bandwidth is needed to achieve the requirement, and recover 37 the bandwidth when the sub-reservations are no longer 38 required. It also contains recommendations concerning 39 algorithms and policies for predictive reservations. 41 Draft RSVP Reservation Aggregation February 1999 43 1. Introduction 45 A key problem in the design of RSVP version 1 is, as noted in 46 its applicability statement, that it lacks facilities for 47 aggregation of individual reserved sessions into a common 48 class. The use of such aggregation is recommended in [CSZ], 49 and required for scalability. 51 The problem of aggregation may be addressed in a variety of 52 ways. For example, it may sometimes be sufficient simply to 53 mark reserved traffic with a suitable DSCP (e.g. EF). It may 54 be desirable to install one or more aggregate reservations 55 from ingress to egress of an "aggregation region" (defined 56 below) where each aggregate reservation carries similarly 57 marked packets from a large number of flows. This is to 58 provide high levels of assurance that the end-to-end 59 requirements of reserved flows will be met. 61 Throughout, we will talk about "Aggregator" and 62 "Deaggregator", referring to the routers at the ingress and 63 egress edges of an aggregation region. 65 1.1. Problem Statement: Aggregation Of Small Reservations 67 The problem of many small reservations has been extensively 68 discussed, and may be summarized in the observation that each 69 reservation requires a non-trivial amount of message exchange, 70 computation, and memory resources in each router along the 71 way. It would be nice to reduce this to a more manageable 72 level where the load is heaviest and aggregation is possible. 74 Aggregation, however, brings its own challenges. In 75 particular, it reduces the level of isolation between 76 individual flows, implying that one flow may suffer delay from 77 the bursts of another. Synchronization of bursts from 78 different flows may occur. However, there is evidence [CSZ] to 79 suggest that aggregation of flows has no negative effect on 80 the mean delay of the flows, and actually leads to a reduction 81 of delay in the "tail" of the delay distribution (e.g. 99% 82 percentile delay) for the flows. These benefits of aggregation 83 to some extent offset the loss of strict isolation. 85 Draft RSVP Reservation Aggregation February 1999 87 1.2. Proposed Solution 89 The solution we propose involves the aggregation of several 90 individual reservations that cross an "aggregation region" and 91 share common ingress and egress routers into one larger 92 reservation from ingress to egress. We define an "aggregation 93 region" as a contiguous set of systems capable of performing 94 RSVP aggregation (as defined following) along any possible 95 route through this contiguous set. 97 Communication interfaces fall into two categories with respect 98 to an aggregation region; they are "exterior" to an 99 aggregation region, or they are "interior" to it. Routers that 100 have at least one interface in the region fall into three 101 categories with respect to a given RSVP session; they 102 aggregate, they deaggregate, or they are between an aggregator 103 and a deaggregator. 105 In this case, the IP Protocol Number in the individual 106 reservation's PATH and PATH-TEAR messages is changed from RSVP 107 to AGGREGATED-RSVP within the aggregation region, and restored 108 to RSVP at the deaggregator point. These messages are ignored 109 (no state is stored and the message is forwarded as a normal 110 IP datagram) by each router within the aggregation region 111 whenever a reservation follows an interior interface. Since 112 the deaggregating router perceives the previous hop on such 113 messages to be in aggregating router, other RESV and other 114 messages do not require this modification; they are unicast 115 from system to system anyway. 117 The token buckets (SENDER_TSPECs and FLOWSPECS) of these 118 reservations are, however, summed into the corresponding 119 information elements in aggregate PATH and RESV messages. 120 These PATH messages are sent from the aggregator to the 121 deaggregator(s) using RSVP's normal IP Protocol Number. The 122 RESV messages are sent back from the deaggregator to the 123 aggregator, thus establishing an aggregate reservation on 124 behalf of the set of individual flows that use this aggregator 125 and deaggregator. There may be several such reservations 126 between the same two routers, representing different classes 127 of traffic; the reservation is therefore for the traffic 128 marked with a particular DSCP Group. 130 Draft RSVP Reservation Aggregation February 1999 132 1.3. Definitions 134 We define an "aggregation region" as a set of RSVP-capable 135 routers for which normal RSVP messages arriving on an outside 136 interface of one router would in the set would traverse one or 137 more inside interfaces (of this and/or other routers in the 138 set) before finally traversing an outside interface. 140 Such an RSVP message is said to have crossed the aggreagation 141 region. 143 We define the "ingress" router for this flow as the first 144 router (the one which forwards the message from an ouside 145 interface to an inside interface). The ingress router 146 performs aggregation for this flow. 148 We define the "egress" router for this flow as the last router 149 (the one which forwards the message from an inside interface 150 to an outside interface). The egress router performs 151 deaggregation for this flow. 153 We define an "interior" router for this flow as any router in 154 the aggregation region which receives this message on an 155 inside interface and forwards it to another inside interface. 156 Interior routers neither perform aggregation nor deaggregation 157 for this flow. 159 1.4. Detailed Aspects of Proposed Solution 161 A number of issues jump to mind in considering this model. 163 1.4.1. Traffic Classification Within The Aggregation region 165 One of the reasons that RSVP Version 1 did not identify a way 166 to aggregate sessions was that there was not a clear way to 167 classify the aggregate. With the development of the 168 Differentiated Services architecture, this is at least 169 partially resolved; traffic of a particular class can be 170 marked with a given DSCP and so classified. We presume this 171 model. 173 We presume that on each link en route, a queue, WDM color, or 174 similar management component is set aside for all aggregated 175 traffic of the same class, and that sufficient bandwidth is 176 made available to carry the traffic that has been assigned to 177 Draft RSVP Reservation Aggregation February 1999 179 it. This bandwidth may be adjusted based on the total amount 180 of aggregated reservation traffic assigned to the same class. 181 Since the total offered load of reserved traffic is known 182 based on the Tspecs and Rspecs of the aggregated reservations, 183 it is reasonable to use the Expedited Forwarding PHB [EF] for 184 the aggregate reservations, or two similar local PHBs with 185 differing code points, prioritizing CBR voice over VBR video. 186 However, it may also be desirable to use one or more of the AF 187 classes for aggregated reservations. This allows non- 188 conformant traffic to be nevertheless forwarded as part of the 189 aggregate reservation, but with lower drop precedence. 191 Independent of which PHB is used, care needs to be take in an 192 environment where provisioned Diff-Serv and aggregated RSVP 193 are used in the same network, to ensure that the total offered 194 load for a single PHB is not excessive relative to the link 195 capacity allocated to that PHB. One solution to this is to 196 reserve one of the four AF classes strictly for the aggregated 197 reservation traffic while using other AF classes for 198 provisioned Diff-Serv. 200 Therefore, while a RSVP state per aggregate reservation is 201 maintained inside the aggregation region, a single 202 classification and scheduling state (e.g., a DSCP used for 203 classifying traffic) is maintained per aggregation reservation 204 class (rather than per aggregate reservation) inside the 205 aggregation region. For example, if "cbr-voice" service is 206 represented by the EF DSCP throughout the aggregation region, 207 there may be a reservation for each aggregator/deaggregator 208 pair in each router, but only the EF DSCP need be inspected at 209 each interior interface. 211 1.4.2. Deaggregator Determination 213 The first question is "How do we know which aggregate 214 reservation a particular flow should aggregate into?" To know 215 that, we must know three items of information: its aggregating 216 router, its deaggregating router, and (assuming DSCPs are used 217 to differentiate among various reservations between the same 218 two routers), the relevant DSCP. 220 The aggregator is trivial: we know that a flow reservation has 221 arrived at an aggregator when its PATH message arrives at a 222 so-configured system from another region. The DSCP is equally 223 easy, or at least it is in concept. Whatever policy would set 224 the DSCP in so doing selects the DSCP for the aggregate 225 Draft RSVP Reservation Aggregation February 1999 227 reservation. 229 The deaggregator is more involved. If an SPF routing protocol, 230 such as OSPF or IS-IS, is in use, and if it has been extended 231 to advertise information on Deaggregation roles, it can tell 232 us what selection of routers the deaggregator will be chosen 233 from among. However, if that set contains more than one 234 router, it would not tell us which. Also, even if the Link 235 State protocol was extended as mentioned above, multi-area 236 operation is likely to prevent proper advertisement of the 237 Deaggregation attributes and thus deaggregator selection. 239 One method for Deaggregator determination is manual 240 configuration. With this method the network operator would 241 configure the Aggregator and the Deaggregator the necessary 242 information. 244 Another method allows automatic Deaggregator determination and 245 corresponding Aggregator notification. When the RSVP PATH 246 message transits from either an aggregator or an interior 247 interface to a deaggregator interface, the deaggregating 248 router must advise the aggregating router of the correlation 249 between itself and the flow. This has the nice attribute of 250 not being specific to the routing protocol. It also has the 251 property of automatically adjusting to route change. For 252 instance, if because of a topology change, another 253 Deaggregator is now on the shortest path, this method will 254 automatically identify the new Deaggregator and swap to it. 256 1.4.3. Size of Aggregate Reservations 258 A range of options exist for determining the size of the 259 aggregate reservation, presenting a tradeoff between 260 simplicity and scalability. Simplistically, the size of the 261 aggregate reservation needs to be greater than or equal to the 262 sum of the bandwidth of the connections it aggregates, and its 263 burst capacity must be greater than or equal to the sum of 264 their burst capacities. However, if followed religiously, this 265 leads us to change the bandwidth of the aggregate reservation 266 each time an underlying reservation changes, which loses one 267 of the key benefits of aggregation, the reduction of message 268 processing cost in the aggregation region. 270 We assume, therefore, that there is some policy, not defined 271 in this specification (although sample policies are suggested 272 which have the necessary characteristics). This policy 273 Draft RSVP Reservation Aggregation February 1999 275 maintains the amount of bandwidth on a given aggregate 276 reservation at an amount greater than or equal to the sum of 277 the bandwidths of its underlying reservations, while changing 278 it but infrequently. This may require some level of trend 279 analysis if there is a significant probability that in the 280 next interval of time the current aggregate reservation will 281 be exhausted, the router must predict the necessary bandwidth 282 and request it. If the router has a significant amount of 283 bandwidth reserved but has very little probability of using 284 it, the policy may be to predict the amount of bandwidth 285 required and release the excess. 287 This policy is likely to benefit from introduction of some 288 hysteresis (i.e. ensure that the trigger condition for 289 reservation size increase is sufficiently different from the 290 trigger condition for reservation size decrease) to avoid 291 oscillation in stable conditions. 293 Clearly, the definition and operation of such policies are as 294 much business issues as they are technical, and are out of the 295 scope of this document. 297 1.4.4. Intra-domain Routes 299 RSVP directly handles route changes, in that reservations 300 follow the routes that their data follow. This follows from 301 the property that PATH messages contain the same IP source and 302 destination address as the data flow for which a reservation 303 is to be established. However, since we are now making 304 aggregate reservations by sending a PATH message from an 305 ingress to an egress router, the reserved data packets no 306 longer carry the same IP addresses as the relevant PATH 307 message. The issue becomes one of making sure that data 308 packets for reserved flows follow the same path as the PATH 309 message that established Path state for the aggregate 310 reservation. Several approaches are viable. 312 First, the data may be tunneled from aggregator to 313 deaggregator, using technologies such as IP-in-IP tunnels, GRE 314 tunnels, MPLS labeled tunnels, and so on. These each have 315 particular advantages, especially MPLS, which admits traffic 316 engineering. They each also have some cost in link overhead 317 and configuration complexity. 319 If data is not tunneled, then we are depending a 320 characteristic of IP best metric routing , which is that if 321 Draft RSVP Reservation Aggregation February 1999 323 the route from A to Z includes the path from H to L, and the 324 best metric route was chosen all along the way, then the best 325 metric route was chosen from H to L. Therefore, a path which 326 crosses a given aggregator and deaggregator will of necessity 327 use the best path between them. 329 If this is a single path, the problem is solved. If it is a 330 multi-path route, then we are forced to determine, perhaps by 331 measurement, what proportion of the traffic for a given 332 reservation is passing along each of the paths, and assure 333 ourselves of sufficient bandwidth for the present use. A 334 simple, though inelegant, way of doing this is to reserve the 335 total capacity of the aggregate route down each path. 337 For this reason, we believe it is advantageous to use one of 338 the above-mentioned tunneling mechanisms in cases where 339 multi-path routes may exist. 341 1.4.5. Inter-domain Routes 343 Again, RSVP responds directly to route changes, in that 344 reservations follow the routes that their data follow. 345 However, in this case, the best-path considerations do not 346 apply, as routing is by a combination of routing policy and 347 shortest AS path rather than simple best metric. 349 In this case, we must presume that a data flow might come in 350 on different aggregator interfaces and leave on different 351 deaggregator interfaces. It is possible that we could identify 352 this occurrence in some central system which sees the 353 reservation information for both of the apparent sessions, but 354 it is not clear that we could determine a priori how much 355 traffic went one way or the other apart from measurement. 357 As a result, we simply note that the problem can occur and 358 needs to be allowed for in the implementation. We recommend 359 that each such flow reservation be summed into each 360 appropriate aggregate reservation, even though this involves 361 over-reservation. 363 1.4.6. Reservations for Intra-domain Multicast Routing 365 Multicast routing, in this framework, acts much like a 366 superset of multipath unicast routing. It differs in that the 367 information from a given aggregator may divide at some 368 Draft RSVP Reservation Aggregation February 1999 370 interior router and proceed to more than one deaggregator. For 371 this reason, we recommend that multicast routes use a distinct 372 set of DSCPs, and that a form of shared explicit reservation 373 be used. Since such reservations must be from one source 374 (aggregator) to multiple destinations (deaggregator), and 375 Shared Explicit (SE) reservations traverse one session and 376 many filter specifications, we therefore choose to identify 377 the aggregator in the session object and the deaggregator in 378 the filter object. 380 1.4.7. Reservations for Inter-domain Multicast Routing 382 to be filled in: 384 Draft RSVP Reservation Aggregation February 1999 386 2. Elements of Procedure 388 To implement this, we define a number of elements of 389 procedure. 391 2.1. Receipt of Flow Reservation Path Message By aggregating 392 router 394 The very first event is the arrival of the PATH message for a 395 microflow at an exterior interface of an aggregator. RSVP 396 version 1's standard procedures are followed for this, 397 including consideration of what set of interfaces it needs to 398 be forwarded onto. These interfaces comprise zero or more 399 deaggregator interfaces and zero or more interior interfaces. 401 Service on deaggregator interfaces is handled as defined in 402 RSVP Version 1. 404 Service on interior interfaces is complicated by the fact that 405 the message needs to be included in some number of aggregate 406 reservations, but at this point it is not known which one, 407 because the deaggregator is not known. Therefore, the PATH 408 message is forwarded on the interface using the IP Protocol 409 number RSVP-AGGREGATE, but in every other respect identically 410 to the way it would be sent by RSVP Version 1. 412 2.2. Handling Of Flow Reservation Path Message By Interior 413 Routers 415 At this point, the message traverses zero or more interior 416 routers, which receive an RSVP-AGGREGATE message on an 417 interior interface and forward it to another interior 418 interface. The Router Alert IP Option alerts them to check 419 internally, but they find that the IP Protocol is RSVP- 420 AGGREGATE and the next hop interface is interior. As such, 421 they simply forward it as a normal IP datagram. 423 2.3. Receipt of Flow Reservation Path Message By 424 Deaggregating router 426 The PATH message finally arrives at a deaggegating router, 427 which receives it from an interior interface and forwards it 428 to an external interface. Again, the Router Alert IP Option 429 alerts it to intercept the message, but this time the IP 430 Draft RSVP Reservation Aggregation February 1999 432 Protocol is RSVP-AGGREGATE and the next hop interface is an 433 external interface. 435 At this point, the deaggregating router associates the flow 436 with an aggregate reservation. This selection is done on the 437 basis of policy, and may take into account not only the 438 aggregating router (whose IP Address may be found in the RSVP 439 Hop Object) but other information about the flow. If no such 440 aggregate reservation exists and the router is so configured, 441 it may generate a PATH ERROR with code NEW-AGGREGATE-NEEDED 442 back to the aggregating router. This should not result in any 443 reservation being taken down, but may result in the 444 aggregating router initiating the necessary path message. 446 The message is also changed from IP Protocol RSVP-AGGREGATE 447 back to IP Protocol RSVP, the ADSPEC information accumulated 448 by that aggregate reservation added into this ADSPEC, and the 449 PATH message is forwarded towards its intended destination. 451 2.4. Initiation of New Aggregate Reservation Path Message By 452 Aggregating router 454 The aggregating router is responsible to include the 455 SENDER_TSPEC information from individual flow reservations in 456 the SENDER_TSPEC being announced to its deaggregating router. 457 It may know that a reservation is associated with a given 458 deaggregator when one of two events occurs: it receives a PATH 459 ERROR message with the error code NEW-AGGREGATE-NEEDED, or 460 when it receives an RESV message from the deaggregator for the 461 flow. The DCLASS object in the message indicates which DSCP 462 the deaggregator believes that the flow belongs in. The 463 identity of the deaggregator itself is to be found in the 464 ERROR SPECIFICATION or the RSVP HOP object. 466 On receipt of either, if no corresponding aggregate 467 reservation exists and the router is configured to do so, it 468 should generate a PATH message for the aggregate reservation. 469 The destination address of the PATH message is the address of 470 the deaggregating router, and the message is sent with IP 471 protocol number RSVP. 473 For multicast, the PATH message could be sent to an "All 474 Deaggregators" multicast address. Shared Explicit signaling 475 could also be used to direct shared multicasts directly to 476 each of the indicated egress points. This latter, while 477 requiring perhaps a few more messages, means that we need 478 Draft RSVP Reservation Aggregation February 1999 480 neither a set of multicast addresses corresponding to all 481 permutations of possible egress routers, nor a way to handle 482 excess irrelevant messages. 484 2.5. Handling of Flow Reservation RESV Message by 485 Deaggregating Router 487 Having sent the flow PATH message on toward the destination, 488 the router must now expect to receive an RESV for the session. 489 On receipt, its responsibility is to assure itself that there 490 is sufficient bandwidth reserved to accomplish the task, and 491 if there is, then to forward the RESV to the aggregating 492 router. 494 Note that there is discussion among the authors as to whether 495 the aggregator or the de-aggregator should assure that the 496 aggregate reservation has enough bandwidth to support the 497 individual flow. 499 If there is insufficient bandwidth reserved, it should follow 500 the RSVP Version 1 procedures for a reservation being placed 501 with insufficient bandwidth to support the reservation. It may 502 also immediately attempt to increase the aggregate reservation 503 that is supplying bandwidth. 505 When sufficient bandwidth is available, it may now simply send 506 an RESV message with IP Protocol RSVP to the aggregating 507 router. This message should, in addition to other data, 508 contain the DCLASS object to indicate which DSCP the 509 deaggregating router expects the aggregator to use. It will 510 also add the token bucket from the FLOWSPEC object into its 511 internal understanding of how much of that reservation is in 512 use. 514 2.6. Initiation of New Aggregate Reservation RESV Message By 515 Deaggregating Router 517 If there is a PATH message for the aggregate reservation but 518 no RESV message, at this point the deaggregating router should 519 create such an RESV and set its initial request to a value not 520 smaller than the requirement of the flow it is supporting. 522 If there is not a PATH message, a deadlock exists; the sender 523 has not created one, meaning that it may have missed the PATH 524 ERROR message intended to trigger the event, or it may have 525 Draft RSVP Reservation Aggregation February 1999 527 not been configured to create the message. The deaggregator 528 should generate the necessary state with which to respond to 529 such a PATH message, initiate a PATH ERROR message as a 530 retransmission, and quiesce. 532 Once it has the PATH message for the aggregate, the 533 deaggregator sends a normal RESV message toward the aggregator 534 (e.g., to the previous hop), using the AGGREGATED-RSVP session 535 and filter specifications. Since the DSCP is in the SESSION 536 object, the DCLASS is unnecessary. However, the CONFIRM object 537 should be used, to assure that the reservation does indeed 538 arrive and is granted. The de-aggregator may presume any 539 confirmed bandwidth to be available to allocate to the flows 540 it supports. 542 2.7. Handling of Flow Reservation RESV Message by Interior 543 Routers 545 The RESV is handled in the usual manner, with respect to 546 bandwidth allocation and other aspects. However, since the 547 flow of the reservation differs from that of other session 548 types, it bears explaining. 550 RSVP V1 sessions proceed from a set of senders to a receiver 551 or class of receivers. For this reason, RSVP V1 uses the 552 receiver's address in the SESSION object and places senders in 553 the FILTER SPECIFICATION. This is backwards of that - 554 aggregated RSVP sessions proceed from a single aggregator 555 towards one or more deaggregators. Therefore, the aggregator's 556 IP Address is used in the SESSION object, and the filter-list 557 is essentially a list of receivers. 559 The interior routers, therefore, apply either the FF or SE 560 flow merging rules as appropriate, and in the multicast case 561 forward toward the aggregator the union of the sets of FILTER 562 specifications. 564 2.8. Handling of Flow Reservation RESV Message by Aggregating 565 Router 567 The RESV message is the final confirmation to the aggregating 568 router that a proportion of a given aggregate's bandwidth has 569 been reserved. At this point, it should assure itself that the 570 flow reservation is associated with an appropriate aggregate, 571 that the aggregator and deaggregator expectations synchronize, 572 Draft RSVP Reservation Aggregation February 1999 574 and that all things are in place. It should also assure itself 575 that the SENDER_TSPEC from the PATH message has been 576 accumulated into the aggregate PATH message. Under normal 577 circumstances, this is the only way it will be informed of 578 this association. It should now forward the flow's RESV to its 579 previous hop, following RSVP Version 1 rules. 581 2.9. Removal of Flow Reservation 583 Flow reservations are removed in the usual way via PATH TEAR, 584 RESV TEAR, timeout, or as the result of an error condition. 585 When they are removed, their FLOWSPEC information must also be 586 removed from the allocated portion of the aggregate 587 reservation. This same bandwidth may be re-used for other 588 traffic in the near future. When PATH messages are removed, 589 their SENDER_TSPEC information must also be removed from the 590 aggregate PATH. 592 2.10. Removal of Aggregate Reservation 594 Should an aggregate reservation go away (presumably due to a 595 configuration change, route change, or policy event), the 596 reservations it supports are no longer active. They must be 597 treated accordingly. 599 2.11. Handling of Data On Reserved Flow by Aggregating 600 Router 602 Prior to establishment that a given flow is part of a given 603 aggregate, the flow's data should be treated as general best 604 effort traffic by whatever policies prevail for such. 605 Generally, this will mean being given the same throughput 606 behavior as non-essential traffic. However, upon establishing 607 that, the aggregating router is responsible to mark any 608 related traffic with the correct DSCP and forward it in the 609 manner appropriate to traffic on that reservation. This may 610 imply forwarding it to a given IP next hop, or piping it down 611 a given link layer circuit, tunnel, or MPLS label switched 612 path. 614 Draft RSVP Reservation Aggregation February 1999 616 3. Protocol Elements 618 3.1. IP Protocol RSVP-AGGREGATE 620 This specification presumes the assignment of a protocol type 621 RSVP-AGGREGATE, whose number is at this point TBD. This is 622 used only on messages which require a router alert (PATH, PATH 623 ERROR, and RESV CONFIRM), and signifies that the message must 624 be treated one way when copied to an interior interface, and 625 another way when copied to en exterior interface. 627 3.2. Path Error Code 629 A PATH ERROR code NEW-AGGREGATE-NEEDED is presumed. This value 630 does not signify that a terminal error has occurred, but that 631 an action is required of the aggregating router to avoid an 632 error condition in the near future. 634 3.3. SESSION Object 636 The SESSION object contains two values: the IP Address of the 637 aggregating router, and the DSCP that it will use on the data 638 the reservation contains. This is exactly backwards of RSVP 639 Version 1, and is intended to support shared explicit 640 multicast reservations along a network route branching away 641 from the aggregator. Two types must be designed: one 642 specifying the aggregator by its IP4 Address, and one 643 specifying the aggregator by its IP6 address. 644 o IP4 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP4 646 +-------------+-------------+-------------+-------------+ 647 | IPv4 Aggregator Address (4 bytes) | 648 +-------------+-------------+-------------+-------------+ 649 | /////////// | Flags | ///////// | DSCP | 650 +-------------+-------------+-------------+-------------+ 652 o IP6 SESSION object: Class = SESSION, C-Type = RSVP-AGGREGATE-IP6 654 +-------------+-------------+-------------+-------------+ 655 | | 656 + + 657 | | 658 + IPv6 Aggregator Address (16 bytes) + 659 | | 660 Draft RSVP Reservation Aggregation February 1999 662 + + 663 | | 664 +-------------+-------------+-------------+-------------+ 665 | /////////// | Flags | ///////// | DSCP | 666 +-------------+-------------+-------------+-------------+ 668 3.4. SENDER_TEMPLATE Object 670 The SENDER_TEMPLATE is omitted from PATH messages for 671 aggregate reservations. 673 3.5. FILTER Object 675 The FILTER object identifies the deaggregating router, or set 676 of deaggregating routers in the event that there are several. 677 o IP4 SESSION object: Class = FILTER, C-Type = RSVP-AGGREGATE-IP4 679 +-------------+-------------+-------------+-------------+ 680 | IPv4 De-aggregator Address (4 bytes) | 681 +-------------+-------------+-------------+-------------+ 683 o IP6 SESSION object: Class = FILTER, C-Type = RSVP-AGGREGATE-IP6 685 +-------------+-------------+-------------+-------------+ 686 | | 687 + + 688 | | 689 + IPv6 De-aggregator Address (16 bytes) | 690 | | 691 + + 692 | | 693 +-------------+-------------+-------------+-------------+ 695 3.6. DCLASS Object 697 The DCLASS object indicates the DSCP that the deaggregator 698 expects the aggregator to use in marking the data. This may be 699 used for coherence checks. 701 o DCLASS object: Class = DCLASS, C-Type = Diff-serv 703 +-------------+-------------+-------------+-------------+ 704 | ////////////////////////////////////// | DSCP | 705 Draft RSVP Reservation Aggregation February 1999 707 +-------------+-------------+-------------+-------------+ 708 Draft RSVP Reservation Aggregation February 1999 710 4. Policies and Algorithms For Predictive Management Of 711 Blocks Of Bandwidth 713 The exact policies used in determining how much bandwidth 714 should be allocated to an aggregate reservation at any given 715 time are beyond the scope of this document, and may be 716 proprietary to the service provider in question. However, here 717 we explore some of the issues and suggest approaches. 719 In short, the ideal condition is that the aggregate 720 reservation always has enough to allocate to any flow 721 reservation that requires its support, and never takes too 722 much. Simply stated, but more difficult to achieve. Factors 723 that come into account include significant times in the 724 diurnal cycle: one may find that a large number of people 725 start placing calls at 8:00 AM, even though the hour from 7:00 726 to 8:00 is dead calm. They also include recent history: if 727 more people have been placing calls recently than have been 728 finishing them, a prediction of the necessary bandwidth a few 729 moments hence may call for more bandwidth than is currently 730 allocated. Likewise, at the end of a busy period, we may find 731 that the trend calls for declining reservation amounts. 733 We would recommend a policy something along this line. At any 734 given time, one should expect that the amount of bandwidth 735 required for the aggregate reservation is the larger of the 736 following: 738 (a) a requirement known a priori, such as from history of the 739 diurnal cycle at a particular week day and time of day, 740 and 742 (b) the trend line over recent history, with 90 or 99% 743 statistical confidence. 745 We would further expect that changes to that aggregate 746 reservation would be made no more often than every few 747 minutes, and ideally perhaps on larger granularity such as 748 fifteen minute intervals or hourly. The finer the granularity, 749 the greater the level of signaling required, while the coarser 750 the granularity, the greater the chance for error, and the 751 need to recover from that error. 753 In general, we expect that the aggregate reservation will not 754 ever add up to exactly the sum of the reservations it 755 supports, but rather will be an integer multiple of some block 756 reservation size, which exceeds that value. 758 Draft RSVP Reservation Aggregation February 1999 760 5. Security Considerations 762 Numerous security issues pertain to this document; for 763 example, the loss of an aggregate reservation to an aggressor 764 causes many calls to operate unreserved, and the reservation 765 of a great excess of bandwidth may result in a denial of 766 service. However, these issues are not confined to this 767 extension: RSVP itself has them. We believe that the security 768 mechanisms in RSVP address these issues as well. 770 6. IANA Considerations 772 Beyond allocating an IP Protocol, a PATH ERROR code, and an 773 RSVP Addressing object "type", there are no IANA issues in 774 this document. We do not define an object that will itself 775 require assignment by IANA. 777 7. Acknowledgments 779 The authors freely acknowledge that published documents and 780 discussion with several people materially contributed to the 781 correct specification of this function. The design derives 782 directly from an internet draft by Roch Guerin [Guerin] and 783 from Steve Berson's drafts on the subject. It is also 784 influenced by the design in the diff-edge draft by Bernet et 785 al [Bernet]. 787 Draft RSVP Reservation Aggregation February 1999 789 8. References 791 [IP] RFC 791, "Internet Protocol". J. Postel. Sep-01-1981. 793 [HOSTREQ] 794 RFC 1122, "Requirements for Internet hosts - 795 communication layers". R.T. Braden. Oct-01-1989. 797 [FRAMEWORK] 798 Nichols, "Differentiated Services Operational Model and 799 Definitions", 02/11/1998, draft-nichols-dsopdef-00.txt 801 [PRINCIPLES] 802 RFC 1958, "Architectural Principles of the Internet". B. 803 Carpenter. June 1996. 805 [ASSURED] 806 Clark and Wroclawski, "An Approach to Service Allocation 807 in the Internet", 08/04/1997, draft-clark-diff-svc- 808 alloc-00.txt 810 [BROKER] 811 Nichols and Zhang, "A Two-bit Differentiated Services 812 Architecture for the Internet", 12/23/1997, draft- 813 nichols-diff-svc-arch-00.txt 815 {BERSON] 816 Berson and Vincent. Aggregation of Internet Integrated 817 Services State. draft-berson-rsvp-aggregation-00.txt, 818 August 1998 820 9. Author's Addresses 822 Fred Baker 823 Cisco Systems 824 519 Lado Drive 825 Santa Barbara, California 93111 826 Phone: (408) 526-4257 827 Email: fred@cisco.com 829 Carol Iturralde 830 Cisco Systems 831 250 Apollo Drive 832 Chelmsford MA,01824 USA 833 Phone: 978-244-8532 834 Email: cei@cisco.com 835 Draft RSVP Reservation Aggregation February 1999 837 Francois Le Faucheur 838 Cisco Systems 839 Office: 16 av du Quebec, 840 Villebon-BP 706, 91961 Les Ulis - 841 France 842 Phone: +33.1.6918 6266 843 Email: flefauch@cisco.com 845 Bruce Davie 846 Cisco Systems 847 250 Apollo Drive 848 Chelmsford MA,01824 USA 849 Phone: 978-244-8921 850 Email: bdavie@cisco.com