idnits 2.17.1 draft-ietf-issll-rsvp-aggr-03.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-25) 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 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 41 longer pages, the longest (page 1) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 41 pages 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 are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 1486 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1009: '...regate bandwidth, the Deaggregator MAY...' RFC 2119 keyword, line 1055: '...the Deaggregator MAY anticipate the cu...' RFC 2119 keyword, line 1357: '... It is RECOMMENDED that implementati...' RFC 2119 keyword, line 1360: '...n of the IP protocol number SHOULD NOT...' 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 2001) is 8470 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? 'RSVP' on line 1719 looks like a reference -- Missing reference section? 'CSZ' on line 1666 looks like a reference -- Missing reference section? 'ISDS' on line 1707 looks like a reference -- Missing reference section? 'BERSON' on line 1697 looks like a reference -- Missing reference section? 'REFRESH' on line 1729 looks like a reference -- Missing reference section? 'INTEGRITY' on line 1742 looks like a reference -- Missing reference section? 'BRIM' on line 1702 looks like a reference -- Missing reference section? 'GUERIN' on line 1714 looks like a reference -- Missing reference section? 'BERNET' on line 1724 looks like a reference -- Missing reference section? 'TERZIS' on line 1734 looks like a reference -- Missing reference section? 'IP' on line 1672 looks like a reference -- Missing reference section? 'HOSTREQ' on line 1674 looks like a reference -- Missing reference section? 'DSFIELD' on line 1678 looks like a reference -- Missing reference section? 'PRINCIPLES' on line 1684 looks like a reference -- Missing reference section? 'ASSURED' on line 1688 looks like a reference -- Missing reference section? 'BROKER' on line 1692 looks like a reference -- Missing reference section? 'DCLASS' on line 1738 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Draft RSVP Reservation Aggregation February 2001 3 F. Baker 4 C. Iturralde 5 F. Le Faucheur 6 B. Davie 7 Cisco Systems 9 Aggregation of RSVP for IPv4 and IPv6 Reservations 10 draft-ietf-issll-rsvp-aggr-03.txt 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC 2026. Internet Drafts 14 are working documents of the Internet Engineering Task Force 15 (IETF), its Areas, and its Working Groups. Note that other 16 groups may also distribute working documents as Internet 17 Drafts. 19 Internet Drafts are valid for a maximum of six months and may 20 be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet Drafts as reference 22 material or to cite them other than as a "work in progress". 23 Comments should be made to the authors and the 24 issll@mercury.lcs.mit.edu list. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright (C) The Internet Society (2001). All Rights 33 Reserved. 35 Abstract 37 A key problem in the design of RSVP version 1 is, as noted in 38 its applicability statement, that it lacks facilities for 39 aggregation of individual reserved sessions into a common 40 class. The use of such aggregation is required for 41 scalability. 43 This document describes the use of a single RSVP reservation 44 to aggregate other RSVP reservations across a transit routing 45 region, in a manner conceptually similar to the use of Virtual 46 Paths in an ATM network. It proposes a way to dynamically 47 create the aggregate reservation, classify the traffic for 48 which the aggregate reservation applies, determine how much 49 bandwidth is needed to achieve the requirement, and recover 50 the bandwidth when the sub-reservations are no longer 51 required. It also contains recommendations concerning 52 algorithms and policies for predictive reservations. 54 Draft RSVP Reservation Aggregation February 2001 56 1. Introduction 58 A key problem in the design of RSVP version 1 [RSVP] is, as 59 noted in its applicability statement, that it lacks facilities 60 for aggregation of individual reserved sessions into a common 61 class. The use of such aggregation is recommended in [CSZ], 62 and required for scalability. 64 The problem of aggregation may be addressed in a variety of 65 ways. For example, it may sometimes be sufficient simply to 66 mark reserved traffic with a suitable DSCP (e.g. EF), thus 67 enabling aggregation of scheduling and classification state. 68 It may also be desirable to install one or more aggregate 69 reservations from ingress to egress of an "aggregation region" 70 (defined below) where each aggregate reservation carries 71 similarly marked packets from a large number of flows. This is 72 to provide high levels of assurance that the end-to-end 73 requirements of reserved flows will be met, while at the same 74 time enabling reservation state to be aggregated. 76 Throughout, we will talk about "Aggregator" and 77 "Deaggregator", referring to the routers at the ingress and 78 egress edges of an aggregation region. Exactly how a router 79 determines whether it should perform the role of aggregator or 80 deaggregator is described below. 82 We will refer to the individual reserved sessions (the 83 sessions we are attempting to aggregate) as "end-to-end" 84 reservations ("E2E" for short), and to their respective 85 Path/Resv messages as E2E Path/Resv messages. We refer to the 86 the larger reservation (that which represents many E2E 87 reservations) as an "aggregate" reservation, and its 88 respective Path/Resv messages as "aggregate Path/Resv 89 messages". 91 1.1. Problem Statement: Aggregation Of E2E Reservations 93 The problem of many small reservations has been extensively 94 discussed, and may be summarized in the observation that each 95 reservation requires a non-trivial amount of message exchange, 96 computation, and memory resources in each router along the 97 way. It would be nice to reduce this to a more manageable 98 level where the load is heaviest and aggregation is possible. 100 Aggregation, however, brings its own challenges. In 102 Draft RSVP Reservation Aggregation February 2001 104 particular, it reduces the level of isolation between 105 individual flows, implying that one flow may suffer delay from 106 the bursts of another. Synchronization of bursts from 107 different flows may occur. However, there is evidence [CSZ] to 108 suggest that aggregation of flows has no negative effect on 109 the mean delay of the flows, and actually leads to a reduction 110 of delay in the "tail" of the delay distribution (e.g. 99% 111 percentile delay) for the flows. These benefits of aggregation 112 to some extent offset the loss of strict isolation. 114 1.2. Proposed Solution 116 The solution we propose involves the aggregation of several 117 E2E reservations that cross an "aggregation region" and share 118 common ingress and egress routers into one larger reservation 119 from ingress to egress. We define an "aggregation region" as a 120 contiguous set of systems capable of performing RSVP 121 aggregation (as defined following) along any possible route 122 through this contiguous set. 124 Communication interfaces fall into two categories with respect 125 to an aggregation region; they are "exterior" to an 126 aggregation region, or they are "interior" to it. Routers that 127 have at least one interface in the region fall into one of 128 three categories with respect to a given RSVP session; they 129 aggregate, they deaggregate, or they are between an aggregator 130 and a deaggregator. 132 Aggregation depends on being able to hide E2E RSVP messages 133 from RSVP-capable routers inside the aggregation region. To 134 achieve this end, the IP Protocol Number in the E2E 135 reservation's Path, PathTear, and ResvConf messages is changed 136 from RSVP (46) to RSVP-E2E-IGNORE (a new value, to be 137 assigned) upon entering the aggregation region, and restored 138 to RSVP at the deaggregator point. These messages are ignored 139 (no state is stored and the message is forwarded as a normal 140 IP datagram) by each router within the aggregation region 141 whenever they are forwarded to an interior interface. Since 142 the deaggregating router perceives the previous RSVP hop on 143 such messages to be the aggregating router, Resv and other 144 messages do not require this modification; they are unicast 145 from RSVP hop to RSVP hop anyway. 147 The token buckets (SENDER_TSPECs and FLOWSPECS) of E2E 148 reservations are summed into the corresponding information 149 elements in aggregate Path and Resv messages. Aggregate Path 151 Draft RSVP Reservation Aggregation February 2001 153 messages are sent from the aggregator to the deaggregator(s) 154 using RSVP's normal IP Protocol Number. Aggregate Resv 155 messages are sent back from the deaggregator to the 156 aggregator, thus establishing an aggregate reservation on 157 behalf of the set of E2E flows that use this aggregator and 158 deaggregator. 160 Such establishment of a smaller number of aggregate 161 reservations on behalf of a larger number of E2E reservations 162 yields the corresponding reduction in the amount of state to 163 be stored and amount of signalling messages exchanged in the 164 aggregation region. 166 By using Differentiated Services mechanisms for classification 167 and scheduling of traffic supported by aggregate reservations 168 (rather than performing per aggregate reservation 169 classification and scheduling), the amount of classification 170 and scheduling state in the aggregation region is even further 171 reduced. It is not only independent of the number of E2E 172 reservations, it is also independent of the number of 173 aggregate reservations in the aggregation region. One or more 174 Diff-Serv DSCPs are used to identify traffic covered by 175 aggregate reservations and one or more Diff-Serv PHBs are used 176 to offer the required forwarding treatment to this traffic. 177 There may be more than one aggregate reservation between the 178 same pair of routers, each representing different classes of 179 traffic and each using a different DSCP and a different PHB. 181 1.3. Definitions 183 We define an "aggregation region" as a set of RSVP-capable 184 routers for which E2E RSVP messages arriving on an exterior 185 interface of one router in the set would traverse one or more 186 interior interfaces (of this and possibly of other routers in 187 the set) before finally traversing an exterior interface. 189 Such an E2E RSVP message is said to have crossed the 190 aggregation region. 192 We define the "aggregating" router for this E2E flow as the 193 first router that processes the E2E Path message as it enters 194 the aggregation region (i.e., the one which forwards the 195 message from an exterior interface to an interior interface). 197 We define the "deaggregating" router for this E2E flow as the 198 last router to process the E2E Path as it leaves the 200 Draft RSVP Reservation Aggregation February 2001 202 aggregation region (i.e., the one which forwards the message 203 from an interior interface to an exterior interface). 205 We define an "interior" router for this E2E flow as any router 206 in the aggregation region which receives this message on an 207 interior interface and forwards it to another interior 208 interface. Interior routers perform neither aggregation nor 209 deaggregation for this flow. 211 Note that by these definitions a single router with a mix of 212 interior and exterior interfaces may have the capability to 213 act as an aggregator on some E2E flows, a deaggregator on 214 other E2E flows, and an interior router on yet other flows. 216 1.4. Detailed Aspects of Proposed Solution 218 A number of issues jump to mind in considering this model. 220 1.4.1. Traffic Classification Within The Aggregation Region 222 One of the reasons that RSVP Version 1 did not identify a way 223 to aggregate sessions was that there was not a clear way to 224 classify the aggregate. With the development of the 225 Differentiated Services architecture, this is at least 226 partially resolved; traffic of a particular class can be 227 marked with a given DSCP and so classified. We presume this 228 model. 230 We presume that on each link en route, a queue, WDM color, or 231 similar management component is set aside for all aggregated 232 traffic of the same class, and that sufficient bandwidth is 233 made available to carry the traffic that has been assigned to 234 it. This bandwidth may be adjusted based on the total amount 235 of aggregated reservation traffic assigned to the same class. 237 There are numerous options for exactly which Diff-serv PHBs 238 might be used for different classes of traffic as it crosses 239 the aggregation region. This is the "service mapping" problem 240 described in [ISDS], and is applicable to situations broader 241 than those described in this document. Arguments can be made 242 for using either EF or one or more AF PHBs for aggregated 243 traffic. For example, since controlled load requires non- 244 TSpec-conformant (policed) traffic to be forwarded as best 245 effort traffic rather than dropped, it may be appropriate to 246 use an AF class for controlled load, using the higher drop 248 Draft RSVP Reservation Aggregation February 2001 250 preference for non-conformant packets. 252 In conventional (unaggregated) RSVP operation, a session is 253 identified by a destination address and optionally a protocol 254 port. Since data belonging to an aggregated reservation is 255 identified by a DSCP, the session is defined by the 256 destination address and DSCP. For those cases where two DSCPs 257 are used (for conformant and non-conformant packets, as noted 258 above), the session is identified by the DSCP of conformant 259 packets. In general we will talk about mapping aggregated 260 traffic onto a DSCP (even if a second DSCP may be used for 261 non-conformant traffic). 263 Whichever PHB or PHBs are used to carry aggregated 264 reservations, care needs to be take in an environment where 265 provisioned Diff-Serv and aggregated RSVP are used in the same 266 network, to ensure that the total admitted load for a single 267 PHB does not exceed the link capacity allocated to that PHB. 268 One solution to this is to reserve one PHB (or more) strictly 269 for the aggregated reservation traffic (e.g. AF1 Class) while 270 using other PHBs for provisioned Diff-Serv (e.g. AF2, AF3 and 271 AF4 Classes). 273 Inside the aggregation region, some RSVP reservation state is 274 maintained per aggregate reservation, while classification and 275 scheduling state (e.g., DSCPs used for classifying traffic) is 276 maintained on a per aggregate reservation class basis (rather 277 than per aggregate reservation). For example, if Guaranteed 278 Service reservations are mapped to the EF DSCP throughout the 279 aggregation region, there may be a reservation for each 280 aggregator/deaggregator pair in each router, but only the EF 281 DSCP needs to be inspected at each interior interface, and 282 only a single queue is used for all EF traffic. 284 1.4.2. Deaggregator Determination 286 The first question is "How do we determine the 287 Aggregator/Deaggregator pair that are responsible for 288 aggregating a particular E2E flow through the aggregation 289 region?" 291 Determination of the aggregator is trivial: we know that an 292 E2E flow has arrived at an aggregator when its Path message 293 arrives at a router on an exterior interface and must be 294 forwarded on an interior interface. 296 Draft RSVP Reservation Aggregation February 2001 298 Determination of the deaggregator is more involved. If an SPF 299 routing protocol, such as OSPF or IS-IS, is in use, and if it 300 has been extended to advertise information on Deaggregation 301 roles, it can tell us the set of routers from which the 302 deaggregator will be chosen. In principle, if the aggregator 303 and deaggregator are in the same area, then the identity of 304 the deaggregator could be determined from the link state 305 database. However, this approach would not work in multi-area 306 environments or for distance vector protocols. 308 One method for Deaggregator determination is manual 309 configuration. With this method the network operator would 310 configure the Aggregator and the Deaggregator with the 311 necessary information. 313 Another method allows automatic Deaggregator determination and 314 corresponding Aggregator notification. When the E2E RSVP Path 315 message transits from an interior interface to an exterior 316 interface, the deaggregating router must advise the 317 aggregating router of the correlation between itself and the 318 flow. This has the nice attribute of not being specific to the 319 routing protocol. It also has the property of automatically 320 adjusting to route changes. For instance, if because of a 321 topology change, another Deaggregator is now on the shortest 322 path, this method will automatically identify the new 323 Deaggregator and swap to it. 325 1.4.3. Mapping E2E Reservations Onto Aggregate Reservations 327 As discussed above, there may be multiple Aggregate 328 Reservations between the same Aggregator/Deaggregator pair. 329 The rules for mapping E2E reservations onto aggregate 330 reservations are policy decisions which depend on the network 331 environment and network administrator's objectives. Such a 332 policy is outside the scope of this specification and we 333 simply assume that such a policy is defined by the network 334 administrator. We also assume that such a policy is somehow 335 accessible to the Aggregators/Deaggregators but the details of 336 how this policy is made accessible to 337 Aggregators/Deaggregators (Local Configuration, COPS, LDAP, 338 etc.) is outside the scope of this specification. 340 An example of very simple policy would be that all the E2E 341 reservations are mapped onto a single Aggregate Reservation 342 (i.e., single DSCP) between a given pair of 344 Draft RSVP Reservation Aggregation February 2001 346 Aggregator/Deaggregator. 348 Another example of policy, which takes into account the Int- 349 Serv service type requested by the receiver (and signalled in 350 the E2E Resv), would be where Guaranteed Service E2E 351 reservations are mapped onto one DSCP in the aggregation 352 region and where Controlled Load E2E reservations are mapped 353 onto another DSCP. 355 A third example of policy would be one where the mapping of 356 E2E reservations onto Aggregate Reservations take into account 357 Policy Objects (such as information authenticating the end 358 user) which may be included by the sender in the E2E path 359 and/or by the receiver in the E2E Resv. 361 Regardless of the actual policy, a range of options are 362 conceivable for where the decision to map an E2E reservation 363 onto an aggregate reservation is taken and how this decision 364 is communicated between Aggregator and Deaggregator. Both 365 Aggregator and Deaggregator could be assumed to make such a 366 decision independently. However, this would either require 367 definition of additional procedures to solve inconsistent 368 mapping decisions (i.e., Aggregator and Deaggregator decide to 369 map a given E2E reservation onto different Aggregate 370 Reservations) or would result in possible undetected 371 misbehavior in the case of inconsistent decisions. 373 For simplicity and reliability, we assign the responsibility 374 of the mapping decision entirely to the Deaggregator. The 375 Aggregator is notified of the selected mapping by the 376 Deaggregator and follows this decision. The Deaggregator was 377 chosen rather than the Aggregator because the Deaggregator is 378 the first to have access to all the information required to 379 make such a decision (in particular receipt of the E2E Resv 380 which indicates the requested Int-Serv service type and 381 includes information signalled by the receiver). This allows 382 faster operations such as set-up or size adjustment of an 383 Aggregate Reservation in a number of situations resulting in 384 faster E2E reservation establishment. 386 1.4.4. Size of Aggregate Reservations 388 A range of options exist for determining the size of the 389 aggregate reservation, presenting a tradeoff between 390 simplicity and scalability. Simplistically, the size of the 391 aggregate reservation needs to be greater than or equal to the 393 Draft RSVP Reservation Aggregation February 2001 395 sum of the bandwidth of the E2E reservations it aggregates, 396 and its burst capacity must be greater than or equal to the 397 sum of their burst capacities. However, if followed 398 religiously, this leads us to change the bandwidth of the 399 aggregate reservation each time an underlying E2E reservation 400 changes, which loses one of the key benefits of aggregation, 401 the reduction of message processing cost in the aggregation 402 region. 404 We assume, therefore, that there is some policy, not defined 405 in this specification (although sample policies are suggested 406 which have the necessary characteristics). This policy 407 maintains the amount of bandwidth required on a given 408 aggregate reservation by taking account of the sum of the 409 bandwidths of its underlying E2E reservations, while 410 endeavoring to change it infrequently. This may require some 411 level of trend analysis. If there is a significant probability 412 that in the next interval of time the current aggregate 413 reservation will be exhausted, the router must predict the 414 necessary bandwidth and request it. If the router has a 415 significant amount of bandwidth reserved but has very little 416 probability of using it, the policy may be to predict the 417 amount of bandwidth required and release the excess. 419 This policy is likely to benefit from introduction of some 420 hysteresis (i.e. ensure that the trigger condition for 421 aggregate reservation size increase is sufficiently different 422 from the trigger condition for aggregate reservation size 423 decrease) to avoid oscillation in stable conditions. 425 Clearly, the definition and operation of such policies are as 426 much business issues as they are technical, and are out of the 427 scope of this document. 429 1.4.5. E2E Path ADSPEC update 431 As described above, E2E RSVP messages are hidden from the 432 Interior routers inside the aggregation region. Consequently, 433 the ADSPECs of E2E Path messages are not updated as they 434 travel through the aggregation region. Therefore, the 435 Deaggregator for a flow is responsible for updating the ADSPEC 436 in the corresponding E2E Path to reflect the impact of the 437 aggregation region on the QoS that may be achieved end-to-end. 438 The Deaggregator should update the ADSPEC of the E2E Path as 439 accurately as possible. 441 Draft RSVP Reservation Aggregation February 2001 443 Since Aggregate Path messages are processed inside the 444 aggregation region, their ADSPEC is updated by Interior 445 routers to reflect the impact of the aggregation region on the 446 QoS that may be achieved within the interior region. 447 Consequently, the Deaggregator should make use of the 448 information included in the ADSPEC from an Aggregate Path 449 where available. The Deaggregator may elect to wait until such 450 information is available before forwarding the E2E Path in 451 order to accurately update its ADSPEC. 453 To maximize the information made available to the 454 Deaggregator, whenever the Aggregator signals an Aggregate 455 Path, the Aggregator should include an ADSPEC with fragments 456 for all service types supported in the aggregation region 457 (even if the Aggregate Path corresponds to an Aggregate 458 Reservation that only supports a subset of those service 459 types). Providing this information to the Deaggregator for 460 every possible service type facilitates accurate and timely 461 update of the E2E ADSPEC by the Deaggregator. 463 Depending on the environment and on the policy for mapping E2E 464 reservations onto Aggregate Reservations, to accurately update 465 the E2E Path ADSPEC, the Deaggregator may for example: 467 - update all the E2E Path ADSPEC segments (Default 468 General Parameters Fragment, Guaranteed Service Fragment, 469 Controlled-Load Service Fragment) based on the ADSPEC of 470 a single Aggregate Path, or 472 - update the E2E Path ADSPEC by taking into account the 473 ADSPEC from multiple Aggregate Path messages (e.g.,. 474 update the Default General Parameters Fragment using the 475 "worst" value for each parameter across all the Aggregate 476 Paths' ADSPECs, update the Guaranteed Service Fragment 477 using the Guaranteed Service Fragment from the ADSPEC of 478 the Aggregate Path for the reservation used for 479 Guaranteed Services). 481 By taking into account the information contained in the ADSPEC 482 of Aggregate Path(s) as mentioned above, the Deaggregator 483 should be able to accurately update the e2e Path ADSPEC in 484 most situations. 486 However, we note that there may be particular situations where 487 the E2E Path ADSPEC update cannot be made entirely accurately 488 by the Deaggregator. This is most likely to happen when the 489 path taken across the aggregation region depends on the 491 Draft RSVP Reservation Aggregation February 2001 493 service requested in the E2E Resv, which is yet to arrive. 494 Such a situation could arise if, for example: 496 - The service mapping policy for the aggregation region 497 is such that E2E reservations requesting Guaranteed 498 Service are mapped to a different PHB that those 499 requesting Controlled Load service. 501 - Diff-Serv aware routing is used in the aggregation 502 region, so that packets with different DSCPs follow 503 different paths (sending them over different MPLS label 504 switched paths, for example). 506 As a result, the ADSPEC for the aggregate reservation that 507 supports guaranteed service may differ from the ADSPEC for the 508 aggregate reservation that supports controlled load. 510 Assume that the sender sends an E2E Path with an ADSPEC 511 containing segments for both Guaranteed Services and 512 Controlled Load. Then, at the time of updating the E2E ADSPEC, 513 the Deaggregator does not know which service type will 514 actually be requested by the receiver and therefore cannot 515 know which PHB will be used to transport this E2E flow and, in 516 turn, cannot pick the right parameter values to factor in when 517 updating the Default General Parameters Fragment. As mentioned 518 above, in this particular case, a conservative approach would 519 be to always take into account the worst value for every 520 parameter. Regardless of whether this conservative approach is 521 followed or some simpler approach such as taking into account 522 one of the two Aggregate Path ADSPEC, the E2E Path ADSPEC will 523 be inaccurate (over-optimistic or over-pessimistic) for at 524 least one service type actually requested by the destination. 526 Recognizing that entirely accurate update of E2E Path ADSPEC 527 may not be possible in all situations, we recommend that a 528 conservative approach be taken in such situations (over- 529 pessimistic rather than over-optimistic) and that the E2E Path 530 ADSPEC be corrected as soon as possible. In the example 531 described above, this would mean that as soon as the 532 Deaggregator receives the E2E Resv from the receiver, the 533 Deaggregator should generate another E2E Path with an 534 accurately updated ADSPEC based on the knowledge of which 535 aggregate reservation will actually carry the E2E flow. 537 Draft RSVP Reservation Aggregation February 2001 539 1.4.6. Intra-domain Routes 541 RSVP directly handles route changes, in that reservations 542 follow the routes that their data follow. This follows from 543 the property that Path messages contain the same IP source and 544 destination address as the data flow for which a reservation 545 is to be established. However, since we are now making 546 aggregate reservations by sending a Path message from an 547 aggregating to a deaggregating router, the reserved (E2E) data 548 packets no longer carry the same IP addresses as the relevant 549 (aggregate) Path message. The issue becomes one of making sure 550 that data packets for reserved flows follow the same path as 551 the Path message that established Path state for the aggregate 552 reservation. Several approaches are viable. 554 First, the data may be tunneled from aggregator to 555 deaggregator, using technologies such as IP-in-IP tunnels, GRE 556 tunnels, MPLS label-switched paths, and so on. These each have 557 particular advantages, especially MPLS, which allows traffic 558 engineering. They each also have some cost in link overhead 559 and configuration complexity. 561 If data is not tunneled, then we are depending on a 562 characteristic of IP best metric routing , which is that if 563 the route from A to Z includes the path from H to L, and the 564 best metric route was chosen all along the way, then the best 565 metric route was chosen from H to L. Therefore, an aggregate 566 path message which crosses a given aggregator and deaggregator 567 will of necessity use the best path between them. 569 If this is a single path, the problem is solved. If it is a 570 multi-path route, and the paths are of equal cost, then we are 571 forced to determine, perhaps by measurement, what proportion 572 of the traffic for a given E2E reservation is passing along 573 each of the paths, and assure ourselves of sufficient 574 bandwidth for the present use. A simple, though wasteful, way 575 of doing this is to reserve the total capacity of the 576 aggregate route down each path. 578 For this reason, we believe it is advantageous to use one of 579 the above-mentioned tunneling mechanisms in cases where 580 multiple equal-cost paths may exist. 582 Draft RSVP Reservation Aggregation February 2001 584 1.4.7. Inter-domain Routes 586 The case of inter-domain routes differs somewhat from the 587 intra-domain case just described. Specifically, best-path 588 considerations do not apply, as routing is by a combination of 589 routing policy and shortest AS path rather than simple best 590 metric. 592 In the case of inter-domain routes, data traffic belonging to 593 different E2E sessions (but the same aggregate session) may 594 not enter an aggregation region via the same aggregator 595 interface, and/or may not leave via the same deaggregator 596 interface. It is possible that we could identify this 597 occurrence in some central system which sees the reservation 598 information for both of the apparent sessions, but it is not 599 clear that we could determine a priori how much traffic went 600 one way or the other apart from measurement. 602 We simply note that this problem can occur and needs to be 603 allowed for in the implementation. We recommend that each such 604 E2E reservation be summed into its appropriate aggregate 605 reservation, even though this involves over-reservation. 607 1.4.8. Reservations for Multicast Sessions 609 Aggregating reservations for multicast sessions is 610 significantly more complex than for unicast sessions. The 611 first challenge is to construct a multicast tree for 612 distribution of the aggregate Path messages which follows the 613 same path as will be followed by the data packets for which 614 the aggregate reservation is to be made. This is complicated 615 by the fact that the path taken by a data packet may depend on 616 many factors such as its source address, the choice of shared 617 trees or source-specific trees, and the location of a 618 rendezvous point for the tree. 620 Once the problem of distributing aggregate Path messages is 621 solved, there are considerable problems in determining the 622 correct amount of resources to reserve at each link along the 623 multicast tree. Because of the amount of heterogeneity that 624 may exist in an aggregate multicast reservation, it appears 625 that it would be necessary to retain information about 626 individual E2E reservations within the aggregation region to 627 allocate resources correctly. Thus, we may end up with a 628 complex set of procedures for forming aggregate reservations 629 that do not actually reduce the amount of stored state 631 Draft RSVP Reservation Aggregation February 2001 633 significantly for multicast sessions. [BERSON] describes 634 possible ways to reduce this state by using measurement-based 635 admission control. 637 As noted above, there are several aspects to RSVP state, and 638 our approach for unicast aggregates all forms of state: 639 classification, scheduling, and reservation state. One 640 possible approach to multicast is to focus only on aggregation 641 of classification and scheduling state, which are arguably the 642 most important because of their impact on the forwarding path. 643 That approach is the one described in the current draft. 645 1.4.9. Multi-level Aggregation 647 Ideally, an aggregation scheme should be able to accommodate 648 recursive aggregation, with aggregate reservations being 649 themselves aggregated. Multi-level aggregation can be 650 accomplished using the procedures described here and a simple 651 extension to the protocol number swapping process. 653 We can consider E2E RSVP reservations to be at aggregation 654 level 0. When we aggregate these reservations, we produce 655 reservations at aggregation level 1. In general, level n 656 reservations may be aggregated to form reservations at level 657 n+1. 659 When an aggregating router receives an E2E Path, it swaps the 660 protocol number from RSVP to RSVP-E2E-IGNORE. In addition, it 661 should write the aggregation level (1, in this case) in the 2 662 byte field that is present (and currently unused) in the 663 router alert option. In general, a router which aggregates 664 reservations at level n to create reservations at level n+1 665 will write the number n+1 in the router alert field. A router 666 which deaggregates level n+1 reservations will examine all 667 messages with IP protocol number RSVP-E2E-IGNORE but will 668 process the message and swap the protocol number back to RSVP 669 only in the case where the router alert field carries the 670 number n+1. For any other value, the message is forwarded 671 unchanged. Interior routers ignore all messages with IP 672 protocol number RSVP-E2E-IGNORE. Note that only a few bits of 673 the 2 byte field in the option would be needed, given the 674 likely number of levels of aggregation. 676 For IPv6, certain values of the router alert "value" field are 677 reserved. This specification requires IANA assignment of a 678 small number of consecutive values for the purpose of 680 Draft RSVP Reservation Aggregation February 2001 682 recording the aggregation level. 684 1.4.10. Reliability Issues 686 There are a variety of issues that arise in the context of 687 aggregation that would benefit from some form of explicit 688 acknowledgment mechanism for RSVP messages. For example, it 689 is possible to configure a set of routers such that an E2E 690 Path of protocol type RSVP-E2E-IGNORE would be effectively 691 "black-holed", if it never reached a router which was 692 appropriately configured to act as a deaggregator. It could 693 then travel all the way to its destination where it would 694 probably be ignored due to its non-standard protocol number. 695 This situation is not easy to detect. The aggregator can be 696 sure this problem has not occurred if an aggregate PathErr 697 message is received from the deaggregator (as described in 698 detail below). It can also be sure there is no problem if an 699 E2E Resv is received. However, the fact that neither of these 700 events has happened may only mean that no receiver wishes to 701 reserve resources for this session, or that an RSVP message 702 loss occurred, or it may mean that the Path was black-holed. 703 However, if a neighbor-to-neighbor acknowledgment mechanism 704 existed, the aggregator would expect to receive an 705 acknowledgment of the E2E Path from the deaggregator, and 706 would interpret the lack of a response as an indication that a 707 problem of configuration existed. It could then refrain from 708 aggregating this particular session. We note that such a 709 reliability mechanism has been proposed for RSVP in [REFRESH] 710 and propose that it be used here. 712 1.4.11. Message Integrity and Node Authentication 714 [RSVP] defines a hop-by-hop authentication and integrity 715 check. The present specification allows use of this check on 716 Aggregate RSVP messages and also preserves this check on E2E 717 RSVP messages for E2E RSVP messages. 719 Outside the Aggregation Region, any E2E RSVP message may 720 contain an INTEGRITY object using a keyed cryptographic digest 721 technique which assumes that RSVP neighbors share a secret. 722 Because E2E RSVP messages are not processed by routers in the 723 Aggregation Region, the Aggregator and Deaggregator appear as 724 logical RSVP neighbors of each other. The Deaggregator is the 725 Aggregator's Next Hop for E2E RSVP messages while the 726 Aggregator is the Deaggregator's Previous Hop. Consequently, 728 Draft RSVP Reservation Aggregation February 2001 730 INTEGRITY objects which may appear in E2E RSVP messages 731 traversing the Aggregation Region are exchanged directly 732 between the Aggregator and Deaggregator in a manner which is 733 entirely transparent to the Interior routers. Thus, hop-by-hop 734 integrity checking for E2E messages over the Aggregation 735 Region requires that the Aggregator and Deaggregator share a 736 secret. Techniques for establishing that secret are described 737 in [INTEGRITY]. 739 Inside the Aggregation Region, any Aggregate RSVP message may 740 contain an INTEGRITY object which assumes that the 741 corresponding RSVP neighbors inside the Aggregation Region 742 (e.g. Aggregator and Interior Router, two Interior Routers, 743 Interior Router and Deaggregator) share a secret. 745 1.4.12. Aggregated reservations without E2E reservations 747 Up to this point we have assumed that the aggregate 748 reservation is established as a result of the establishment of 749 E2E reservations from outside the aggregation region. It 750 should be clear that alternative triggers are possible. As 751 discussed in [ISDS], an aggregate RSVP reservation can be used 752 to manage bandwidth in a diff-serv cloud even if RSVP is not 753 used end-to-end. 755 The simplest example of an alternative configuration is the 756 static configuration of an aggregated reservation for a 757 certain amount for traffic from an ingress (aggregator) router 758 to an egress (de-aggregator) router. This would have to be 759 configured in at least the system originating the aggregate 760 PATH message (the aggregator). The deaggregator could detect 761 that the PATH message is directed to it, and could be 762 configured to "turn around" such messages, i.e., it responds 763 with a RESV back to the aggregator. Alternatively, 764 configuration of the aggregate reservation could be performed 765 at both the aggregator and the deaggregator. As before, an 766 aggregate reservation is associated with a DSCP for the 767 traffic that will use the reserved capacity. 769 In the absence of E2E microflow reservations, the aggregator 770 can use a variety of policies to set the DSCP of packets 771 passing into the aggregation region, thus determining whether 772 they gain access to the resources reserved by the aggregate 773 reservation. These policies are a matter of local 774 configuration, as usual for a device at the edge of a diff- 776 Draft RSVP Reservation Aggregation February 2001 778 serv cloud. 780 Note that the "aggregator" could even be a device such as a 781 PSTN gateway which makes an aggregate reservation for the set 782 of calls to another PSTN gateway (the deaggregator) across an 783 intervening diff-serv region. In this case the reservation may 784 be established in response to call signalling. 786 From the perspective of RSVP signalling and the handling of 787 data packets in the aggregation region, these cases are 788 equivalent to the case of aggregating E2E RSVP reservations. 789 The only difference is that E2E RSVP signalling does not take 790 place and cannot therefore be used as a trigger, so some 791 additional knowledge is required in setting up the aggregate 792 reservation. 794 Draft RSVP Reservation Aggregation February 2001 796 2. Elements of Procedure 798 To implement aggregation, we define a number of elements of 799 procedure. 801 2.1. Receipt of E2E Path Message By Aggregating Router 803 The very first event is the arrival of the E2E Path message at 804 an exterior interface of an aggregator. Standard RSVP 805 procedures [RSVP] are followed for this, including onto what 806 set of interfaces the message should be forwarded. These 807 interfaces comprise zero or more exterior interfaces and zero 808 or more interior interfaces. (If the number of interior 809 interfaces is zero, the router is not acting as an aggregator 810 for this E2E flow.) 812 Service on exterior interfaces is handled as defined in 813 [RSVP]. 815 Service on interior interfaces is complicated by the fact that 816 the message needs to be included in some aggregate 817 reservation, but at this point it is not known which one, 818 because the deaggregator is not known. Therefore, the E2E Path 819 message is forwarded on the interior interface(s) using the IP 820 Protocol number RSVP-E2E-IGNORE, but in every other respect 821 identically to the way it would be sent by an RSVP router that 822 was not performing aggregation. 824 2.2. Handling Of E2E Path Message By Interior Routers 826 At this point, the E2E Path message traverses zero or more 827 interior routers. Interior routers receive the E2E Path 828 message on an interior interface and forward it on another 829 interior interface. The Router Alert IP Option alerts interior 830 routers to check internally, but they find that the IP 831 Protocol is RSVP-E2E-IGNORE and the next hop interface is 832 interior. As such, they simply forward it as a normal IP 833 datagram. 835 2.3. Receipt of E2E Path Message By Deaggregating Router 837 The E2E Path message finally arrives at a deaggregating 838 router, which receives it on an interior interface and 840 Draft RSVP Reservation Aggregation February 2001 842 forwards it on an exterior interface. Again, the Router Alert 843 IP Option alerts it to intercept the message, but this time 844 the IP Protocol is RSVP-E2E-IGNORE and the next hop interface 845 is an exterior interface. 847 Before forwarding the E2E Path towards the receiver, the 848 Deaggregator should update its ADSPEC. This update is to 849 reflect the impact of the aggregation region onto the QoS to 850 be achieved E2E by the flow. Such information can be collected 851 by the ADSPEC of Aggregate Path messages travelling from the 852 Aggregator to the Deaggregator. Thus, to enable correct 853 updating of the ADSPEC, a deaggregating router may wait as 854 described below for the arrival of an aggregate Path before 855 forwarding the E2E Path. 857 When receiving the E2E Path, depending on the policy for 858 mapping E2E reservation onto Aggregate Reservations, the 859 Deaggregator may or may not be in a position to decide which 860 DSCP the E2E flow for the processed E2E Path is going to be 861 mapped onto, as described above. If the Deaggregator is in a 862 position to know the mapping at this point, then the 863 Deaggregator first checks that there is an Aggregate Path in 864 place for the corresponding DSCP. If so, then the Deaggregator 865 uses the ADSPEC of this Aggregate Path to update the ADSPEC of 866 the E2E Path and then forwards the E2E Path towards the 867 receiver. If not, then the Deaggregator requests 868 establishment of the corresponding Aggregate Path by sending 869 an E2E PathErr message with an error code of NEW-AGGREGATE- 870 NEEDED and the desired DSCP encoded in the DCLASS Object. The 871 Deaggregator may also at the same time request establishment 872 of an aggregate reservation for other DSCPs. When receiving 873 the Aggregate Path for the desired DSCP, the Deaggregator then 874 uses the ADSPEC of this Aggregate Path to update the ADSPEC of 875 the E2E Path. 877 If the Deaggregator is not in a position to know the mapping 878 at this point, then the Deaggregator uses the information 879 contained in the ADSPEC of one Aggregate Path or of multiple 880 Aggregate Paths to update the E2E Path ADSPEC. Similarly, if 881 one or more of the necessary Aggregate Paths is not yet 882 established, the Deaggregator requests establishment of the 883 corresponding Aggregate Path by sending an E2E PathErr message 884 with an error code of NEW-AGGREGATE-NEEDED and the desired 885 DSCP encoded in the respective DCLASS Object. When receiving 886 the Aggregate Path for the desired DSCP, the Deaggregator then 887 uses the ADSPEC of this Aggregate Path to update the ADSPEC of 888 the E2E Path. 890 Draft RSVP Reservation Aggregation February 2001 892 Generating a E2E PathErr message with an error code of NEW- 893 AGGREGATE-NEEDED should not result in any Path state being 894 removed, but should result in the aggregating router 895 initiating the necessary aggregate Path message, as described 896 in the following section. 898 The deaggregating router changes the E2E Path message's IP 899 Protocol from RSVP-E2E-IGNORE to RSVP and forwards the E2E 900 Path message towards its intended destination. 902 2.4. Initiation of New Aggregate Path Message By Aggregating 903 Router 905 The aggregating Router is responsible for generating a new 906 Aggregate Path for a DSCP when receiving a E2E PathErr message 907 with the error code NEW-AGGREGATE-NEEDED from the 908 deaggregator. The DSCP value to include in the Aggregate Path 909 Session is found in the DCLASS Object of the received E2E 910 PathErr message. The identity of the deaggregator itself is 911 found in the ERROR SPECIFICATION of the E2E PathErr message. 912 The destination address of the aggregate Path message is the 913 address of the deaggregating router, and the message is sent 914 with IP protocol number RSVP. 916 Existing RSVP procedures specify that the size of a 917 reservation established for a flow is set to the minimum of 918 the Path SENDER_TSPEC and the Resv FLOW_SPEC. Consequently, 919 the size of an Aggregate Reservation cannot be larger than the 920 SENDER_TSPEC included in the Aggregate Path by the Aggregator. 921 To ensure that Aggregate Reservations can be sized by the 922 Deaggregator without undesired limitations, the Aggregating 923 router should always attempt to include in the Aggregate Path 924 a SENDER_TSPEC which is at least as large as the size that 925 would actually be required as determined by the Deaggregator. 926 One method to achieve this is to use a SENDER_TSPEC which is 927 obviously larger than the highest load of E2E reservations 928 that may be supported onto this network. Another method is for 929 the Aggregator to keep track of which flows are mapped onto a 930 DSCP and always add their E2E Path SENDER_TSPEC into the 931 Aggregate Path SENDER_TSPEC (and possibly also add some 932 additional bandwidth in anticipation of future E2E 933 reservations). 935 The aggregating router is notified of the mapping from an E2E 936 flow to a DSCP in two ways. First, when the aggregating router 937 receives a E2E PathErr with error code NEW-AGGREGATE-NEEDED, 939 Draft RSVP Reservation Aggregation February 2001 941 the Aggregator is notified that the corresponding E2E flow is 942 (at least temporarily) mapped onto a given DSCP. Secondly, 943 when the aggregating router receives an E2E Resv containing a 944 DCLASS Object (as described further below), the Aggregating 945 Router is notified that the corresponding E2E flow is mapped 946 onto a given DSCP. 948 2.5. Handling of E2E Resv Message by Deaggregating Router 950 Having sent the E2E Path message on toward the destination, 951 the deaggregator must now expect to receive an E2E Resv for 952 the session. On receipt, its responsibility is to ensure that 953 there is sufficient bandwidth reserved within the aggregation 954 region to support the new E2E reservation, and if there is, 955 then to forward the E2E Resv to the aggregating router. 957 The Deaggregating router first makes the final decision of 958 which Aggregate Reservation (and thus which DSCP) this E2E 959 reservation is to be mapped onto. This decision is made 960 according to the policy selected by the network administrator 961 as described above. 963 If this final mapping decision is such that the Deaggregator 964 can now make a more accurate update of the E2E Path ADSPEC 965 than done when forwarding the initial E2E Path, the 966 Deaggregator should do so and generate a new E2E Path 967 immediately in order to provide the accurate ADSPEC 968 information to the receiver as soon as possible. Otherwise, 969 normal Refresh procedures should be followed for the E2E Path. 971 If no Aggregate Reservation currently exists from the 972 corresponding aggregating router with the corresponding DSCP, 973 the Deaggregating router will establish a new Aggregate 974 Reservation as described in the next section. 976 If the corresponding Aggregate Reservation exists but has 977 insufficient bandwidth reserved to accommodate the new E2E 978 reservation (in addition to all the existing E2E reservations 979 currently mapped onto it), it should follow the normal RSVP 980 procedures [RSVP] for a reservation being placed with 981 insufficient bandwidth to support the reservation. It may also 982 first attempt to increase the aggregate reservation that is 983 supplying bandwidth by increasing the size of the FLOW_SPEC 984 that it includes in the aggregate Resv that it sends upstream. 985 As discussed in the previous section, the Aggregating Router 986 should ensure that the SENDER_TSPEC it includes in the 988 Draft RSVP Reservation Aggregation February 2001 990 Aggregate Path is always in excess of the FLOW_SPEC that may 991 be requested in the Aggregate Resv by the Deaggregator, so 992 that the Deaggregator is not unnecessarily prevented from 993 effectively increasing the Aggregate Reservation bandwidth as 994 required. 996 When sufficient bandwidth is available on the corresponding 997 aggregate reservation, the Deaggregating Router may simply 998 send the E2E Resv message with IP Protocol RSVP to the 999 aggregating router. This message should include the DCLASS 1000 object to indicate which DSCP the aggregator must use for this 1001 E2E flow. The deaggregator will also add the token bucket from 1002 the E2E Resv FLOWSPEC object into its internal understanding 1003 of how much of the Aggregate reservation is in use. 1005 As discussed above, in order to minimize the occurrence of 1006 situations where insufficient bandwidth is reserved on the 1007 corresponding Aggregate Reservation at the time of processing 1008 an E2E Resv, and in turn to avoid the delay associated with 1009 the increase of this aggregate bandwidth, the Deaggregator MAY 1010 anticipate the current demand and increase the Aggregate 1011 Reservations size ahead of actual requirements by E2E 1012 reservations. 1014 2.6. Initiation of New Aggregate Resv Message By 1015 Deaggregating Router 1017 Upon receiving an E2E Resv message on an exterior interface, 1018 and having determined the appropriate DSCP for the session 1019 according to the mapping policy, the Deaggregator looks for 1020 the corresponding path state for a session with the chosen 1021 DSCP. If aggregate Path state exists, but no aggregate Resv 1022 state exists, the Deaggregator creates a new aggregate Resv. 1024 If no aggregate Path state exists for the appropriate DSCP, 1025 this may be because the Deaggregator could not decide earlier 1026 the final mapping for this E2E flow and elected to not 1027 establish Aggregate Path state for all DSCPs. In that case, 1028 the Deaggregator should request establishment of the 1029 corresponding Aggregate Path by sending a E2E PathErr with 1030 error code of NEW-AGGREGATE-NEEDED and with a DCLASS 1031 containing the required DSCP. This will trigger the Aggregator 1032 to establish the corresponding Aggregate Path. Once the 1033 Deaggregator has determined that the aggregate Path state is 1034 established, it creates a new Aggregate Resv. 1036 Draft RSVP Reservation Aggregation February 2001 1038 The FLOW_SPEC of the new Aggregate Resv is set to a value not 1039 smaller than the requirement of the E2E reservation it is 1040 supporting. The Aggregate Resv is sent toward the aggregator 1041 (i.e., to the previous hop), using the AGGREGATED-RSVP session 1042 and filter specifications defined below. Since the DSCP is in 1043 the SESSION object, no DCLASS object is necessary. The message 1044 should be reliably delivered using the mechanisms in [REFRESH] 1045 or, alternatively, the CONFIRM object may be used, to assure 1046 that the aggregate Resv does indeed arrive and is granted. 1047 This enables the deaggregator to determine that the requested 1048 bandwidth is available to allocate to the E2E flows it 1049 supports. 1051 In order to minimize the occurrence of situations where no 1052 corresponding Aggregate Reservation is established at the time 1053 of processing an E2E Resv, and in turn to avoid the delay 1054 associated with the creation of this aggregate reservation, 1055 the Deaggregator MAY anticipate the current demand and create 1056 the Aggregate Reservation before receiving E2E Resv messages 1057 requiring bandwidth on those aggregate reservations. 1059 2.7. Handling of Aggregate Resv Message by Interior Routers 1061 The aggregate Resv message is handled in essentially the same 1062 way as defined in [RSVP]. The Session object contains the 1063 address of the deaggregating router (or the group address for 1064 the session in the case of multicast) and the DSCP that has 1065 been chosen for the session. The Filterspec object identifies 1066 the aggregating router. These routers perform admission 1067 control and resource allocation as usual and send the 1068 aggregate Resv on towards the aggregator. 1070 2.8. Handling of E2E Resv Message by Aggregating Router 1072 The receipt of the E2E Resv message with a DCLASS Object is 1073 the final confirmation to the aggregating router of the 1074 mapping of the E2E reservation onto an Aggregate Reservation. 1075 Under normal circumstances, this is the only way it will be 1076 informed of this association. It should now forward the E2E 1077 Resv to its previous hop, following normal RSVP processing 1078 rules [RSVP]. 1080 Draft RSVP Reservation Aggregation February 2001 1082 2.9. Removal of E2E Reservation 1084 E2E reservations are removed in the usual way via PathTear, 1085 ResvTear, timeout, or as the result of an error condition. 1086 When they are removed, their FLOWSPEC information must also be 1087 removed from the allocated portion of the aggregate 1088 reservation. This same bandwidth may be re-used for other 1089 traffic in the near future. When E2E Path messages are 1090 removed, their SENDER_TSPEC information must also be removed 1091 from the aggregate Path. 1093 2.10. Removal of Aggregate Reservation 1095 Should an aggregate reservation go away (presumably due to a 1096 configuration change, route change, or policy event), the E2E 1097 reservations it supports are no longer active. They must be 1098 treated accordingly. 1100 2.11. Handling of Data On Reserved E2E Flow by Aggregating 1101 Router 1103 Prior to establishment that a given E2E flow is part of a 1104 given aggregate, the flow's data should be treated as traffic 1105 without a reservation by whatever policies prevail for such. 1106 Generally, this will mean being given the same forwarding 1107 behavior as best effort traffic. However, upon establishing 1108 that the flow belongs to a given aggregate, the aggregating 1109 router is responsible for marking any related traffic with the 1110 correct DSCP and forwarding it in the manner appropriate to 1111 traffic on that reservation. This may imply forwarding it to a 1112 given IP next hop, or piping it down a given link layer 1113 circuit, tunnel, or MPLS label switched path. 1115 The aggregator is responsible for performing per-reservation 1116 policing on the E2E flows that it is aggregating. The 1117 aggregator performs metering of traffic belonging to each 1118 reservation to assess compliance to the token bucket for the 1119 corresponding E2E reservation. Packets which are assessed in 1120 compliance are forwarded as mentioned above. Packets which are 1121 assessed out of compliance must be either dropped, reshaped or 1122 marked to a different DSCP. The detailed policing behavior is 1123 an aspect of the service mapping described in [ISDS]. 1125 Draft RSVP Reservation Aggregation February 2001 1127 2.12. Procedures for Multicast Sessions 1129 Because of the difficulties of aggregating multicast sessions 1130 described above, we focus on the aggregation of scheduling and 1131 classification state in the multicast case. The main 1132 difference between the multicast and unicast cases is that 1133 rather than sending an aggregate Path message to the unicast 1134 address of a single deaggregating router, in the multicast 1135 case we send the "aggregate" Path message to the same group 1136 address as the E2E session. This ensures that the aggregate 1137 Path message follows the same route as the E2E Path. This 1138 difference between unicast and multicast is reflected in the 1139 Session objects defined below. A consequence of this approach 1140 is that we continue to have reservation state per multicast 1141 session inside the aggregation region. 1143 A further challenge arises in multicast sessions with 1144 heterogeneous receivers. Consider an interior router which 1145 must forward packets for a multicast session on two 1146 interfaces, but has only received a reservation request on one 1147 of those interfaces. It receives packets marked with the DSCP 1148 chosen for the aggregate reservation. When sending them out 1149 the interface which has no installed reservation, it has the 1150 following options: 1152 a) remark those packets to best effort before sending 1153 them out the interface; 1155 b) send the packets out the interface with the DSCP 1156 chosen for the aggregate reservation. 1158 The first approach suffers from the drawback that it requires 1159 MF classification at an interior router in order to recognize 1160 the flows whose packets must be demoted. The second approach 1161 requires over-reservation of resources on the interface on 1162 which no reservation was received. In the absence of such 1163 over-reservation, the packets sent with the "wrong" DSCP would 1164 be able to degrade the service experienced by packets using 1165 that DSCP legitimately. 1167 To make MF classification acceptable in an interior router, it 1168 may be possible to treat the case of heterogeneous flows as an 1169 exception. That is, an interior router only needs to be able 1170 to recognize those individual microflows that have 1171 heterogeneous resource needs on the outbound interfaces of 1172 this router. 1174 Draft RSVP Reservation Aggregation February 2001 1176 3. Protocol Elements 1178 3.1. IP Protocol RSVP-E2E-IGNORE 1180 This specification requires the assignment of a protocol type 1181 RSVP-E2E-IGNORE, whose number is at this point TBD. This is 1182 used only on E2E messages which require a router alert (Path, 1183 PathTear, and ResvConf), and signifies that the message must 1184 be treated one way when destined to an interior interface, and 1185 another way when destined to an exterior interface. The 1186 protocol type is swapped by the Aggregator from RSVP to RSVP- 1187 E2E-IGNORE in E2E Path, PathTear, and ResvConf messages when 1188 they enter the Aggregation Region. The protocol type is 1189 swapped back by the Deaggregator from RSVP-E2E-IGNORE to RSVP 1190 in such E2E messages when they exit the Aggregation Region. 1192 3.2. Path Error Code 1194 A PathErr code NEW-AGGREGATE-NEEDED is required. This value 1195 does not signify that a fatal error has occurred, but that an 1196 action is required of the aggregating router to avoid an error 1197 condition in the near future. 1199 3.3. SESSION Object 1201 The SESSION object contains two values: the IP Address of the 1202 aggregate session destination, and the DSCP that it will use 1203 on the E2E data the reservation contains. For unicast 1204 sessions, the session destination address is the address of 1205 the deaggregating router. For multicast sessions, the session 1206 destination is the multicast address of the E2E session (or 1207 sessions) being aggregated. The inclusion of the DSCP in the 1208 session allows for multiple sessions toward the same address 1209 to be distinguished by their DSCP and queued separately. It 1210 also provides the means for aggregating scheduling and 1211 classification state. In the case where a session uses a pair 1212 of PHBs (e.g. AF11 and AF12), the DSCP used should represent 1213 the numerically smallest PHB (e.g. AF11). This follows the 1214 same naming convention described in [BRIM]. 1216 Session types are defined for IPv4 and IPv6 addresses. 1218 Draft RSVP Reservation Aggregation February 2001 1220 o IP4 SESSION object: Class = SESSION, 1221 C-Type = RSVP-AGGREGATE-IP4 1223 +-------------+-------------+-------------+-------------+ 1224 | IPv4 Session Address (4 bytes) | 1225 +-------------+-------------+-------------+-------------+ 1226 | /////////// | Flags | ///////// | DSCP | 1227 +-------------+-------------+-------------+-------------+ 1229 o IP6 SESSION object: Class = SESSION, 1230 C-Type = RSVP-AGGREGATE-IP6 1232 +-------------+-------------+-------------+-------------+ 1233 | | 1234 + + 1235 | | 1236 + IPv6 Session Address (16 bytes) + 1237 | | 1238 + + 1239 | | 1240 +-------------+-------------+-------------+-------------+ 1241 | /////////// | Flags | ///////// | DSCP | 1242 +-------------+-------------+-------------+-------------+ 1244 3.4. SENDER_TEMPLATE Object 1246 The SENDER_TEMPLATE object identifies the aggregating router 1247 for the aggregate reservation. 1249 o IP4 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE, 1250 C-Type = RSVP-AGGREGATE-IP4 1252 +-------------+-------------+-------------+-------------+ 1253 | IPv4 Aggregator Address (4 bytes) | 1254 +-------------+-------------+-------------+-------------+ 1256 Draft RSVP Reservation Aggregation February 2001 1258 o IP6 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE, 1259 C-Type = RSVP-AGGREGATE-IP6 1261 +-------------+-------------+-------------+-------------+ 1262 | | 1263 + + 1264 | | 1265 + IPv6 Aggregator Address (16 bytes) + 1266 | | 1267 + + 1268 | | 1269 +-------------+-------------+-------------+-------------+ 1271 3.5. FILTER_SPEC Object 1273 The FILTER_SPEC object identifies the aggregating router for 1274 the aggregate reservation, and is syntactically identical to 1275 the SENDER_TEMPLATE object. 1277 Draft RSVP Reservation Aggregation February 2001 1279 4. Policies and Algorithms For Predictive Management Of 1280 Blocks Of Bandwidth 1282 The exact policies used in determining how much bandwidth 1283 should be allocated to an aggregate reservation at any given 1284 time are beyond the scope of this document, and may be 1285 proprietary to the service provider in question. However, here 1286 we explore some of the issues and suggest approaches. 1288 In short, the ideal condition is that the aggregate 1289 reservation always has enough resources to allocate to any E2E 1290 reservation that requires its support, and never takes too 1291 much. Simply stated, but more difficult to achieve. Factors 1292 that come into account include significant times in the 1293 diurnal cycle: one may find that a large number of people 1294 start placing calls at 8:00 AM, even though the hour from 7:00 1295 to 8:00 is dead calm. They also include recent history: if 1296 more people have been placing calls recently than have been 1297 finishing them, a prediction of the necessary bandwidth a few 1298 moments hence may call for more bandwidth than is currently 1299 allocated. Likewise, at the end of a busy period, we may find 1300 that the trend calls for declining reservation amounts. 1302 We recommend a policy something along this line. At any given 1303 time, one should expect that the amount of bandwidth required 1304 for the aggregate reservation is the larger of the following: 1306 (a) a requirement known a priori, such as from history of the 1307 diurnal cycle at a particular week day and time of day, 1308 and 1310 (b) the trend line over recent history, with 90 or 99% 1311 statistical confidence. 1313 We further expect that changes to that aggregate reservation 1314 would be made no more often than every few minutes, and 1315 ideally perhaps on larger granularity such as fifteen minute 1316 intervals or hourly. The finer the granularity, the greater 1317 the level of signaling required, while the coarser the 1318 granularity, the greater the chance for error, and the need to 1319 recover from that error. 1321 In general, we expect that the aggregate reservation will not 1322 ever add up to exactly the sum of the reservations it 1323 supports, but rather will be an integer multiple of some block 1324 reservation size, which exceeds that value. 1326 Draft RSVP Reservation Aggregation February 2001 1328 5. Security Considerations 1330 Numerous security issues pertain to this document; for 1331 example, the loss of an aggregate reservation to an aggressor 1332 causes many calls to operate unreserved, and the reservation 1333 of a great excess of bandwidth may result in a denial of 1334 service. However, these issues are not confined to this 1335 extension: RSVP itself has them. We believe that the security 1336 mechanisms in RSVP address these issues as well. 1338 One security issue specific to RSVP aggregation involves the 1339 modification of the IP protocol number in RSVP Path messages 1340 that traverse an aggregation region. If that field were 1341 maliciously modified in a Path message, it would cause the 1342 message to be ignored by all subsequent devices on its path, 1343 preventing reservations from being made. It could even be 1344 possible to correct the value before it reached the receiver, 1345 making it difficult to detect the attack. In theory, it might 1346 also be possible for a node to modify the IP protocol number 1347 for non-RSVP messages as well, thus interfering with the 1348 operation of other protocols. 1350 One way to mitigate the risks of malicious modification of the 1351 IP protocol number is to use an IPSEC authentication header, 1352 which would ensure that malicious modification of the IP 1353 header is detected. This is a desirable approach but imposes 1354 some administrative burden in the form of key management for 1355 authentication purposes. 1357 It is RECOMMENDED that implementations of this specification 1358 only support modification of the IP protocol number for RSVP 1359 Path, PathTear, and ResvConf messages. That is, a general 1360 facility for modification of the IP protocol number SHOULD NOT 1361 be made available. 1363 Network operators deploying routers with RSVP aggregation 1364 capability should be aware of the risks of inappropriate 1365 modification of the IP protocol number and should take 1366 appropriate steps (physical security, password protection, 1367 etc.) to reduce the risk that a router could be configured by 1368 an attacker to perform malicious modification of the protocol 1369 number. 1371 Draft RSVP Reservation Aggregation February 2001 1373 6. IANA Considerations 1375 Beyond allocating an IP Protocol, a PathErr code, a set of 1376 values for the IPv6 router alert option, and an RSVP 1377 Addressing object "type", there are no IANA issues in this 1378 document. We do not define an object that will itself require 1379 assignment by IANA. 1381 7. Acknowledgments 1383 The authors acknowledge that published documents and 1384 discussion with several people, notably John Wroclawski, Steve 1385 Berson, and Andreas Terzis materially contributed to this 1386 draft. The design derives directly from an internet draft by 1387 Roch Guerin [GUERIN] and from Steve Berson's drafts on the 1388 subject. It is also influenced by the design in the diff-edge 1389 draft by Bernet et al [BERNET] and by the RSVP tunnels draft 1390 [TERZIS]. 1392 8. APPENDIX 1: Example Signalling Flow For First E2E Flow 1394 This Appendix does not provide additional specification. It 1395 only illustrates the specification detailed above through a 1396 possible flow of RSVP signalling messages involved in the 1397 successful establishment of a unicast E2E reservation which is 1398 the first between a given pair of Aggregator/Deaggregator. 1400 Aggregator Deaggregator 1402 E2E Path 1403 ----------------> 1404 (1) 1405 E2E Path 1406 -------------------------------> 1407 (2) 1408 E2E PathErr(New-agg-needed, DCLASS=x) 1409 <------------------------------- 1411 Draft RSVP Reservation Aggregation February 2001 1413 E2E PathErr(New-agg-needed, DCLASS=y) 1414 <------------------------------- 1415 (3) 1416 AggPath(DSCP=x) 1417 -------------------------------> 1418 AggPath(DSCP=y) 1419 -------------------------------> 1420 (4) 1421 E2E Path 1422 -----------> 1423 (5) 1424 AggResv (DSCP=x) 1425 <------------------------------- 1426 AggResv (DSCP=y) 1427 <------------------------------- 1428 (6) 1430 AggResvConfirm (DSCP=x) 1431 ------------------------------> 1432 AggResvConfirm (DSCP=y) 1433 ------------------------------> 1434 (7) 1435 E2E Resv 1436 <---------- 1437 (8) 1438 E2E Resv (DCLASS=x) 1439 <----------------------------- 1440 (9) 1441 E2E Resv 1442 <--------------- 1444 (1) Aggregator forwards E2E Path into aggregation region after 1445 modifying its IP Protocol Number to RSVP-E2E-IGNORE 1447 (2) Let's assume no Aggregate Path exists. To be able to 1448 accurately update the ADSPEC of the E2E Path, the Deaggregator 1449 needs the ADSPEC of Aggregate PATH. In this example the 1450 Deaggregator elects to instruct the Aggregator to set up 1451 Aggregate Path states for the two supported DSCPs by sending a 1452 New-Agg-Needed PathErr code for each DSCP. 1454 (3) The Aggregator follows the request from the Deaggregator 1455 and signals an Aggregate Path for both DSCPs 1457 (4) The Deaggregator takes into account the information 1458 contained in the ADSPEC from both Aggregate Path and updates 1460 Draft RSVP Reservation Aggregation February 2001 1462 the E2E Path ADSPEC accordingly. The Deaggregator also 1463 modifies the E2E Path IP Protocol Number to RSVP before 1464 forwarding it. 1466 (5) In this example, the Deaggregator elects to immediately 1467 proceed with establishment of Aggregate Reservations for both 1468 DSCPs. In effect, the Deaggregator can be seen as anticipating 1469 the actual demand of E2E reservations so that resources are 1470 available on Aggregate Reservations when the E2E Resv requests 1471 arrive in order to speed up establishment of E2E reservations. 1472 Assume also that the Deaggregator includes the optional Resv 1473 Confirm Request in these Aggregate Resv. 1475 (6) The Aggregator merely complies with the received 1476 ResvConfirm Request and returns the corresponding Aggregate 1477 ResvConfirm. 1479 (7) The Deaggregator has explicit confirmation that both 1480 Aggregate Resv are established. 1482 (8) On receipt of the E2E Resv, the Deaggregator applies the 1483 mapping policy defined by the network administrator to map the 1484 E2E Resv onto an Aggregate Reservation. Let's assume that this 1485 policy is such that the E2E reservation is to be mapped onto 1486 the Aggregate Reservation with DSCP=x. The Deaggregator knows 1487 that an Aggregate Reservation is in place for the 1488 corresponding DSCP since (7). The Deaggregator performs 1489 admission control of the E2E Resv onto the Aggregate Resv for 1490 DSCP=x. Assuming that the Aggregate Resv for DSCP=x had been 1491 established with sufficient bandwidth to support the E2E Resv, 1492 the Deaggregator adjusts its counter tracking the unused 1493 bandwidth on the Aggregate Reservation and forwards the E2E 1494 Resv to the Aggregator including a DCLASS object conveying the 1495 selected mapping onto DSCP=x. 1497 (9) The Aggregator records the mapping of the E2E Resv onto 1498 DSCP=x. The Aggregator removes the DCLASS object and forwards 1499 the E2E Resv towards the sender. 1501 9. APPENDIX 2: Example Signalling Flow For Subsequent E2E 1502 Flow Without Reservation Resizing" 1504 This Appendix does not provide additional specification. It 1505 only illustrates the specification detailed above through a 1507 Draft RSVP Reservation Aggregation February 2001 1509 possible flow of RSVP signalling messages involved in the 1510 successful establishment of a unicast E2E reservation which 1511 follows other E2E reservations between a given pair of 1512 Aggregator/Deaggregator. This flow could be imagined as 1513 following the flow of messages illustrated in Appendix 1. 1515 Aggregator Deaggregator 1517 E2E Path 1518 ----------------> 1519 (10) 1520 E2E Path 1521 -------------------------------> 1522 (11) 1523 E2E Path 1524 -----------> 1526 E2E Resv 1527 <----------- 1528 (12) 1529 E2E Resv (DCLASS=x) 1530 <----------------------------- 1531 (13) 1532 E2E Resv 1533 <--------------- 1535 (10) Aggregator forwards E2E Path into aggregation region 1536 after modifying its IP Protocol Number to RSVP-E2E-IGNORE 1538 (11) Because previous E2E reservations have been established, 1539 let's assume that Aggregate Path exists for all supported 1540 DSCPs. The Deaggregator takes into account the information 1541 contained in the ADSPEC from the Aggregate Paths and updates 1542 the E2E Path ADSPEC accordingly. The Deaggregator also 1543 modifies the E2E Path IP Protocol Number to RSVP before 1544 forwarding it. 1546 (12) On receipt of the E2E Resv, the Deaggregator applies the 1547 mapping policy defined by the network administrator to map the 1548 E2E Resv onto an Aggregate Reservation. Let's assume that this 1549 policy is such that the E2E reservation is to be mapped onto 1550 the Aggregate Reservation with DSCP=x. Because previous E2E 1551 reservations have been established, let's assume that an 1552 Aggregate Reservation is in place for DSCP=x. The Deaggregator 1553 performs admission control of the E2E Resv onto the Aggregate 1554 Resv for DSCP=x. Assuming that the Aggregate Resv for DSCP=x 1555 has sufficient unused bandwidth to support the new E2E Resv, 1557 Draft RSVP Reservation Aggregation February 2001 1559 the Deaggregator then adjusts its counter tracking the unused 1560 bandwidth on the Aggregate Reservation and forwards the E2E 1561 Resv to the Aggregator including a DCLASS object conveying the 1562 selected mapping onto DSCP=x. 1564 (13) The Aggregator records the mapping of the E2E Resv onto 1565 DSCP=x. The Aggregator removes the DCLASS object and forwards 1566 the E2E Resv towards the sender. 1568 10. APPENDIX 3: Example Signalling Flow For Subsequent E2E 1569 Flow With Reservation Resizing 1571 This Appendix does not provide additional specification. It 1572 only illustrates the specification detailed above through a 1573 possible flow of RSVP signalling messages involved in the 1574 successful establishment of a unicast E2E reservation which 1575 follows other E2E reservations between a given pair of 1576 Aggregator/Deaggregator. This flow could be imagined as 1577 following the flow of messages illustrated in Appendix 2. 1579 Aggregator Deaggregator 1581 E2E Path 1582 ----------------> 1583 (14) 1584 E2E Path 1585 -------------------------------> 1586 (15) 1587 E2E Path 1588 -----------> 1590 E2E Resv 1591 <----------- 1593 (16) 1594 AggResv (DSCP=x, increased Bw) 1595 <------------------------------- 1596 (17) 1597 AggResvConfirm (DSCP=x, increased Bw) 1598 ------------------------------> 1599 (18) 1600 E2E Resv (DCLASS=x) 1601 <----------------------------- 1602 (19) 1604 Draft RSVP Reservation Aggregation February 2001 1606 E2E Resv 1607 <--------------- 1609 (14) Aggregator forwards E2E Path into aggregation region 1610 after modifying its IP Protocol Number to RSVP-E2E-IGNORE 1612 (15) Because previous E2E reservations have been established, 1613 let's assume that Aggregate Path exists for all supported 1614 DSCPs. The Deaggregator takes into account the information 1615 contained in the ADSPEC from the Aggregate Paths and updates 1616 the E2E Path ADSPEC accordingly. The Deaggregator also 1617 modifies the E2E Path IP Protocol Number to RSVP before 1618 forwarding it. 1620 (16) On receipt of the E2E Resv, the Deaggregator applies the 1621 mapping policy defined by the network administrator to map the 1622 E2E Resv onto an Aggregate Reservation. Let's assume that this 1623 policy is such that the E2E reservation is to be mapped onto 1624 the Aggregate Reservation with DSCP=x. Because previous E2E 1625 reservations have been established, let's assume that an 1626 Aggregate Reservation is in place for DSCP=x. The Deaggregator 1627 performs admission control of the E2E Resv onto the Agg Resv 1628 for DSCP=x. Let's assume that the Aggregate Resv for DSCP=x 1629 does NOT have sufficient unused bandwidth to support the new 1630 E2E Resv. The Deaggregator then attempts to increase the 1631 Aggregate Reservation bandwidth for DSCP=x by sending a new 1632 Aggregate Resv with an increased bandwidth sufficient to 1633 accommodate all the E2E reservations already mapped onto that 1634 Aggregate reservation plus the new E2E reservation plus 1635 possibly some additional spare bandwidth in anticipation of 1636 additional E2E reservations to come. Assume also that the 1637 Deaggregator includes the optional Resv Confirm Request in 1638 these Aggregate Resv. 1640 (17) The Aggregator merely complies with the received 1641 ResvConfirm Request and returns the corresponding Aggregate 1642 ResvConfirm. 1644 (18) The Deaggregator has explicit confirmation that the 1645 Aggregate Resv has been successfully increased. The 1646 Deaggregator performs again admission control of the E2E Resv 1647 onto the increased Aggregate Reservation for DSCP=x. Assuming 1648 that the increased Aggregate Reservation for DSCP=x now has 1649 sufficient unused bandwidth and resources to support the new 1650 E2E Resv, the Deaggregator then adjusts its counter tracking 1651 the unused bandwidth on the Aggregate Reservation and forwards 1652 the E2E Resv to the Aggregator including a DCLASS object 1654 Draft RSVP Reservation Aggregation February 2001 1656 conveying the selected mapping onto DSCP=x. 1658 (19) The Aggregator records the mapping of the E2E Resv onto 1659 DSCP=x. The Aggregator removes the DCLASS object and forwards 1660 the E2E Resv towards the sender. 1662 Draft RSVP Reservation Aggregation February 2001 1664 11. References 1666 [CSZ] 1667 Clark, D., S. Shenker, and L. Zhang, "Supporting Real- 1668 Time Applications in an Integrated Services Packet 1669 Network: Architecture and Mechanism," in Proc. 1670 SIGCOMM'92, September 1992. 1672 [IP] RFC 791, "Internet Protocol". J. Postel. Sep-01-1981. 1674 [HOSTREQ] 1675 RFC 1122, "Requirements for Internet hosts - 1676 communication layers". R.T. Braden. Oct-01-1989. 1678 [DSFIELD] 1679 Nichols, K., S. Blake, F. Baker, and D. Black, 1680 "Definition of the Differentiated Services Field (DS 1681 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1682 1998. 1684 [PRINCIPLES] 1685 RFC 1958, "Architectural Principles of the Internet". B. 1686 Carpenter. June 1996. 1688 [ASSURED] 1689 Heinanen, J, F. Baker, W. Weiss, and J. Wroclawski. 1690 Assured Forwarding PHB Group, RFC 2597, June 1999. 1692 [BROKER] 1693 Jacobson, V., Nichols K., and Zhang, L. "A Two-bit 1694 Differentiated Services Architecture for the Internet", 1695 RFC 2638, June 1999. 1697 [BERSON] 1698 Berson and Vincent. "Aggregation of Internet Integrated 1699 Services State". draft-berson-rsvp-aggregation-00.txt, 1700 August 1998. 1702 [BRIM] 1703 Brim, S., Carpenter, B., and LeFaucheur, F. "Per Hop 1704 Behavior Identification Codes". draft-ietf-diffserv- 1705 phbid-00.txt, October 1999. 1707 [ISDS] 1708 Bernet et al. "Integrated Services Operation Over 1709 Diffserv Networks". draft-ietf-issll-diffserv-rsvp- 1710 04.txt, March 2000. 1712 Draft RSVP Reservation Aggregation February 2001 1714 [GUERIN] 1715 Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP 1716 based QoS Requests", Internet Draft, draft-guerin- 1717 aggreg-rsvp-00.txt, November 1997. 1719 [RSVP] 1720 Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, 1721 S., "Resource Reservation Protocol (RSVP) Version 1 1722 Functional Specification", RFC 2205, September 1997. 1724 [BERNET] 1725 Bernet, Y., Durham, D., and F. Reichmeyer, "Requirements 1726 of Diff-serv Boundary Routers", Internet Draft, draft- 1727 bernet-diffedge-01.txt, November, 1998. 1729 [REFRESH] 1730 Berger, L., Gan, D., G. Swallow, P. Pan and F. Tommasi, 1731 "RSVP Refresh Reduction Extensions", Internet Draft, 1732 draft-ietf-rsvp-refresh-reduct-02.txt, January 2000. 1734 [TERZIS] 1735 Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, 1736 "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. 1738 [DCLASS] 1739 Bernet, Y., "Format of the RSVP DCLASS Object", Internet 1740 Draft, draft-ietf-issll-dclass-01.txt, October 1999. 1742 [INTEGRITY] 1743 Baker, F., Lindell, B. and Talwar, M. "RSVP Cryptographic 1744 Authentication", RFC 2747, January 2000. 1746 12. Authors' Addresses 1748 Fred Baker 1749 Cisco Systems 1750 519 Lado Drive 1751 Santa Barbara, California 93111 1752 Phone: (408) 526-4257 1753 Email: fred@cisco.com 1755 Carol Iturralde 1756 Cisco Systems 1757 250 Apollo Drive 1758 Chelmsford MA,01824 USA 1759 Phone: 978-244-8532 1761 Draft RSVP Reservation Aggregation February 2001 1763 Email: cei@cisco.com 1765 Francois Le Faucheur 1766 Cisco Systems 1767 291, rue Albert Caquot 1768 06560 Valbonne, France 1769 Phone: +33.1.6918 6266 1770 Email: flefauch@cisco.com 1772 Bruce Davie 1773 Cisco Systems 1774 250 Apollo Drive 1775 Chelmsford MA,01824 USA 1776 Phone: 978-244-8921 1777 Email: bdavie@cisco.com 1779 13. Full Copyright Statement 1781 Copyright (C) The Internet Society (2001). All Rights 1782 Reserved. 1784 This document and translations of it may be copied and 1785 furnished to others, and derivative works that comment on or 1786 otherwise explain it or assist in its implementation may be 1787 prepared, copied, published and distributed, in whole or in 1788 part, without restriction of any kind, provided that the above 1789 copyright notice and this paragraph are included on all such 1790 copies and derivative works. However, this document itself 1791 may not be modified in any way, such as by removing the 1792 copyright notice or references to the Internet Society or 1793 other Internet organizations, except as needed for the purpose 1794 of developing Internet standards in which case the procedures 1795 for copyrights defined in the Internet Standards process must 1796 be followed, or as required to translate it into languages 1797 other than English. 1799 The limited permissions granted above are perpetual and will 1800 not be revoked by the Internet Society or its successors or 1801 assigns. 1803 This document and the information contained herein is provided 1804 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1805 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1806 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1807 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1809 Draft RSVP Reservation Aggregation February 2001 1811 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1812 PARTICULAR PURPOSE."