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