idnits 2.17.1 draft-ietf-issll-rsvp-aggr-01.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 26 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 26 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 86 characters in excess of 72. ** There are 960 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1999) is 8898 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 1091 looks like a reference -- Missing reference section? 'CSZ' on line 1040 looks like a reference -- Missing reference section? 'ISDS' on line 1079 looks like a reference -- Missing reference section? 'BERSON' on line 1070 looks like a reference -- Missing reference section? 'REFRESH' on line 1101 looks like a reference -- Missing reference section? 'DCLASS' on line 1111 looks like a reference -- Missing reference section? 'BRIM' on line 1075 looks like a reference -- Missing reference section? 'GUERIN' on line 1086 looks like a reference -- Missing reference section? 'BERNET' on line 1096 looks like a reference -- Missing reference section? 'TERZIS' on line 1106 looks like a reference -- Missing reference section? 'IP' on line 1046 looks like a reference -- Missing reference section? 'HOSTREQ' on line 1048 looks like a reference -- Missing reference section? 'FRAMEWORK' on line 1052 looks like a reference -- Missing reference section? 'PRINCIPLES' on line 1056 looks like a reference -- Missing reference section? 'ASSURED' on line 1060 looks like a reference -- Missing reference section? 'BROKER' on line 1065 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Draft RSVP Reservation Aggregation December 1999 3 F. Baker 4 C. Iturralde 5 F. Le Faucheur 6 B. Davie Cisco Systems 8 Aggregation of RSVP for IPv4 and IPv6 Reservations 9 draft-ietf-issll-rsvp-aggr-01.txt 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC 2026. Internet Drafts 13 are working documents of the Internet Engineering Task Force 14 (IETF), its Areas, and its Working Groups. Note that other 15 groups may also distribute working documents as Internet 16 Drafts. 18 Internet Drafts are valid for a maximum of six months and may 19 be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet Drafts as reference 21 material or to cite them other than as a "work in progress". 22 Comments should be made to the authors and the rsvp@isi.edu 23 list. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright (C) The Internet Society (1999). All Rights 32 Reserved. 34 Abstract 36 A key problem in the design of RSVP version 1 is, as noted in 37 its applicability statement, that it lacks facilities for 38 aggregation of individual reserved sessions into a common 39 class. The use of such aggregation is required for 40 scalability. 42 This document describes the use of a single RSVP reservation 43 to aggregate other RSVP reservations across a transit routing 44 region, in a manner conceptually similar to the use of Virtual 45 Paths in an ATM network. It proposes a way to dynamically 46 create the aggregate reservation, classify the traffic for 47 which the aggregate reservation applies, determine how much 48 bandwidth is needed to achieve the requirement, and recover 49 the bandwidth when the sub-reservations are no longer 50 required. It also contains recommendations concerning 51 algorithms and policies for predictive reservations. 53 Draft RSVP Reservation Aggregation December 1999 55 1. Introduction 57 A key problem in the design of RSVP version 1 [RSVP] is, as 58 noted in its applicability statement, that it lacks facilities 59 for aggregation of individual reserved sessions into a common 60 class. The use of such aggregation is recommended in [CSZ], 61 and required for scalability. 63 The problem of aggregation may be addressed in a variety of 64 ways. For example, it may sometimes be sufficient simply to 65 mark reserved traffic with a suitable DSCP (e.g. EF), thus 66 enabling aggregation of scheduling and classification state. 67 It may also be desirable to install one or more aggregate 68 reservations from ingress to egress of an "aggregation region" 69 (defined below) where each aggregate reservation carries 70 similarly marked packets from a large number of flows. This is 71 to provide high levels of assurance that the end-to-end 72 requirements of reserved flows will be met, while at the same 73 time enabling reservation state to be aggregated. 75 Throughout, we will talk about "Aggregator" and 76 "Deaggregator", referring to the routers at the ingress and 77 egress edges of an aggregation region. Exactly how a router 78 determines whether it should perform the role of aggregator or 79 deaggregator is described below. 81 We will refer to the individual reserved sessions (the 82 sessions we are attempting to aggregate) as "end-to-end" 83 reservations ("E2E" for short), and to their respective 84 Path/Resv messages as E2E Path/Resv messages. We refer to the 85 the larger reservation (that which represents many E2E 86 reservations) as an "aggregate" reservation, and its 87 respective Path/Resv messages as "aggregate Path/Resv 88 messages". 90 1.1. Problem Statement: Aggregation Of E2E Reservations 92 The problem of many small reservations has been extensively 93 discussed, and may be summarized in the observation that each 94 reservation requires a non-trivial amount of message exchange, 95 computation, and memory resources in each router along the 96 way. It would be nice to reduce this to a more manageable 97 level where the load is heaviest and aggregation is possible. 99 Aggregation, however, brings its own challenges. In 101 Draft RSVP Reservation Aggregation December 1999 103 particular, it reduces the level of isolation between 104 individual flows, implying that one flow may suffer delay from 105 the bursts of another. Synchronization of bursts from 106 different flows may occur. However, there is evidence [CSZ] to 107 suggest that aggregation of flows has no negative effect on 108 the mean delay of the flows, and actually leads to a reduction 109 of delay in the "tail" of the delay distribution (e.g. 99% 110 percentile delay) for the flows. These benefits of aggregation 111 to some extent offset the loss of strict isolation. 113 1.2. Proposed Solution 115 The solution we propose involves the aggregation of several 116 E2E reservations that cross an "aggregation region" and share 117 common ingress and egress routers into one larger reservation 118 from ingress to egress. We define an "aggregation region" as a 119 contiguous set of systems capable of performing RSVP 120 aggregation (as defined following) along any possible route 121 through this contiguous set. 123 Communication interfaces fall into two categories with respect 124 to an aggregation region; they are "exterior" to an 125 aggregation region, or they are "interior" to it. Routers that 126 have at least one interface in the region fall into one of 127 three categories with respect to a given RSVP session; they 128 aggregate, they deaggregate, or they are between an aggregator 129 and a deaggregator. 131 Aggregation depends on being able to hide E2E RSVP messages 132 from RSVP-capable routers inside the aggregation region. To 133 achieve this end, the IP Protocol Number in the E2E 134 reservation's Path, PathTear, and ResvConf messages is changed 135 from RSVP (46) to RSVP-E2E-IGNORE (a new value, to be 136 assigned) upon entering the aggregation region, and restored 137 to RSVP at the deaggregator point. These messages are ignored 138 (no state is stored and the message is forwarded as a normal 139 IP datagram) by each router within the aggregation region 140 whenever they are forwarded to an interior interface. Since 141 the deaggregating router perceives the previous RSVP hop on 142 such messages to be the aggregating router, Resv and other 143 messages do not require this modification; they are unicast 144 from RSVP hop to RSVP hop anyway. 146 The token buckets (SENDER_TSPECs and FLOWSPECS) of E2E 147 reservations are summed into the corresponding information 148 elements in aggregate Path and Resv messages. Aggregate Path 150 Draft RSVP Reservation Aggregation December 1999 152 messages are sent from the aggregator to the deaggregator(s) 153 using RSVP's normal IP Protocol Number. Aggregate Resv 154 messages are sent back from the deaggregator to the 155 aggregator, thus establishing an aggregate reservation on 156 behalf of the set of E2E flows that use this aggregator and 157 deaggregator. There may be several such aggregate reservations 158 between the same two routers, representing different classes 159 of traffic; the aggregate reservation is therefore for the 160 traffic marked with a particular DSCP. 162 1.3. Definitions 164 We define an "aggregation region" as a set of RSVP-capable 165 routers for which E2E RSVP messages arriving on an exterior 166 interface of one router in the set would traverse one or more 167 interior interfaces (of this and possibly of other routers in 168 the set) before finally traversing an exterior interface. 170 Such an E2E RSVP message is said to have crossed the 171 aggregation region. 173 We define the "aggregating" router for this E2E flow as the 174 first router that processes the E2E Path message as it enters 175 the aggregation region (i.e., the one which forwards the 176 message from an exterior interface to an interior interface). 178 We define the "deaggregating" router for this E2E flow as the 179 last router to process the E2E Path as it leaves the 180 aggregation region (i.e., the one which forwards the message 181 from an interior interface to an exterior interface). 183 We define an "interior" router for this E2E flow as any router 184 in the aggregation region which receives this message on an 185 interior interface and forwards it to another interior 186 interface. Interior routers perform neither aggregation nor 187 deaggregation for this flow. 189 Note that by these definitions a single router with a mix of 190 interior and exterior interfaces may have the capability to 191 act as an aggregator on some E2E flows, a deaggregator on 192 other E2E flows, and an interior router on yet other flows. 194 Draft RSVP Reservation Aggregation December 1999 196 1.4. Detailed Aspects of Proposed Solution 198 A number of issues jump to mind in considering this model. 200 1.4.1. Traffic Classification Within The Aggregation Region 202 One of the reasons that RSVP Version 1 did not identify a way 203 to aggregate sessions was that there was not a clear way to 204 classify the aggregate. With the development of the 205 Differentiated Services architecture, this is at least 206 partially resolved; traffic of a particular class can be 207 marked with a given DSCP and so classified. We presume this 208 model. 210 We presume that on each link en route, a queue, WDM color, or 211 similar management component is set aside for all aggregated 212 traffic of the same class, and that sufficient bandwidth is 213 made available to carry the traffic that has been assigned to 214 it. This bandwidth may be adjusted based on the total amount 215 of aggregated reservation traffic assigned to the same class. 217 There are numerous options for exactly which Diff-serv PHBs 218 might be used for different classes of traffic as it crosses 219 the aggregation region. This is the "service mapping" problem 220 described in [ISDS], and is applicable to situations broader 221 than those described in this document. Arguments can be made 222 for using either EF or one or more AF PHBs for aggregated 223 traffic. 225 Independent of which PHB is used, care needs to be take in an 226 environment where provisioned Diff-Serv and aggregated RSVP 227 are used in the same network, to ensure that the total offered 228 load for a single PHB does not exceed the link capacity 229 allocated to that PHB. One solution to this is to reserve one 230 of the four AF classes strictly for the aggregated reservation 231 traffic while using other AF classes for provisioned Diff- 232 Serv. 234 Inside the aggregation region, some RSVP reservation state is 235 maintained per aggregate reservation, while a single 236 classification and scheduling state (e.g., a DSCP used for 237 classifying traffic) is maintined per aggregate reservation 238 class (rather than per aggregate reservation). For example, 239 if Guaranteed Service is represented by the EF DSCP throughout 240 the aggregation region, there may be a reservation for each 241 aggregator/deaggregator pair in each router, but only the EF 243 Draft RSVP Reservation Aggregation December 1999 245 DSCP need be inspected at each interior interface, and only a 246 single queue is used for all EF traffic. 248 1.4.2. Deaggregator Determination 250 The first question is "How do we know which aggregate 251 reservation a particular E2E flow should aggregate into?" To 252 know that, we must know three things: its aggregating router, 253 its deaggregating router, and (assuming DSCPs are used to 254 differentiate among various reservations between the same two 255 routers), the relevant DSCP. 257 Determination of the aggregator is trivial: we know that an 258 E2E flow has arrived at an aggregator when its Path message 259 arrives at a router on an exterior interface and must be 260 forwarded on an interior interface. 262 Determining the DSCP is equally easy, or at least it is in 263 concept. The DSCP is chosen for an aggregate reservation based 264 on some policy, which may take into account such factors as 265 the intserv service class requested for the flow. (Some 266 details in the exact point at which the DSCP can be determined 267 are discussed below.) 269 Determination of the deaggregator is more involved. If an SPF 270 routing protocol, such as OSPF or IS-IS, is in use, and if it 271 has been extended to advertise information on Deaggregation 272 roles, it can tell us the set of routers from which the 273 deaggregator will be chosen. In principle, if the aggregator 274 and deaggregator are in the same area, then the identity of 275 the deaggregator could be determined from the link state 276 database. However, this approach would not work in multi-area 277 environments or for distance vector protocols. 279 One method for Deaggregator determination is manual 280 configuration. With this method the network operator would 281 configure the Aggregator and the Deaggregator with the 282 necessary information. 284 Another method allows automatic Deaggregator determination and 285 corresponding Aggregator notification. When the E2E RSVP Path 286 message transits from an interior interface to an exterior 287 interface, the deaggregating router must advise the 288 aggregating router of the correlation between itself and the 289 flow. This has the nice attribute of not being specific to the 290 routing protocol. It also has the property of automatically 292 Draft RSVP Reservation Aggregation December 1999 294 adjusting to route changes. For instance, if because of a 295 topology change, another Deaggregator is now on the shortest 296 path, this method will automatically identify the new 297 Deaggregator and swap to it. 299 1.4.3. Size of Aggregate Reservations 301 A range of options exist for determining the size of the 302 aggregate reservation, presenting a tradeoff between 303 simplicity and scalability. Simplistically, the size of the 304 aggregate reservation needs to be greater than or equal to the 305 sum of the bandwidth of the E2E reservations it aggregates, 306 and its burst capacity must be greater than or equal to the 307 sum of their burst capacities. However, if followed 308 religiously, this leads us to change the bandwidth of the 309 aggregate reservation each time an underlying E2E reservation 310 changes, which loses one of the key benefits of aggregation, 311 the reduction of message processing cost in the aggregation 312 region. 314 We assume, therefore, that there is some policy, not defined 315 in this specification (although sample policies are suggested 316 which have the necessary characteristics). This policy 317 maintains the amount of bandwidth required on a given 318 aggregate reservation by taking account of the sum of the 319 bandwidths of its underlying E2E reservations, while 320 endeavoring to change it infrequently. This may require some 321 level of trend analysis. If there is a significant probability 322 that in the next interval of time the current aggregate 323 reservation will be exhausted, the router must predict the 324 necessary bandwidth and request it. If the router has a 325 significant amount of bandwidth reserved but has very little 326 probability of using it, the policy may be to predict the 327 amount of bandwidth required and release the excess. 329 This policy is likely to benefit from introduction of some 330 hysteresis (i.e. ensure that the trigger condition for 331 aggregate reservation size increase is sufficiently different 332 from the trigger condition for aggregate reservation size 333 decrease) to avoid oscillation in stable conditions. 335 Clearly, the definition and operation of such policies are as 336 much business issues as they are technical, and are out of the 337 scope of this document. 339 Draft RSVP Reservation Aggregation December 1999 341 1.4.4. Intra-domain Routes 343 RSVP directly handles route changes, in that reservations 344 follow the routes that their data follow. This follows from 345 the property that Path messages contain the same IP source and 346 destination address as the data flow for which a reservation 347 is to be established. However, since we are now making 348 aggregate reservations by sending a Path message from an 349 aggregating to a deaggregating router, the reserved (E2E) data 350 packets no longer carry the same IP addresses as the relevant 351 (aggregate) Path message. The issue becomes one of making sure 352 that data packets for reserved flows follow the same path as 353 the Path message that established Path state for the aggregate 354 reservation. Several approaches are viable. 356 First, the data may be tunneled from aggregator to 357 deaggregator, using technologies such as IP-in-IP tunnels, GRE 358 tunnels, MPLS label-switched paths, and so on. These each have 359 particular advantages, especially MPLS, which allows traffic 360 engineering. They each also have some cost in link overhead 361 and configuration complexity. 363 If data is not tunneled, then we are depending a 364 characteristic of IP best metric routing , which is that if 365 the route from A to Z includes the path from H to L, and the 366 best metric route was chosen all along the way, then the best 367 metric route was chosen from H to L. Therefore, an aggregate 368 path message which crosses a given aggregator and deaggregator 369 will of necessity use the best path between them. 371 If this is a single path, the problem is solved. If it is a 372 multi-path route, and the paths are of equal cost, then we are 373 forced to determine, perhaps by measurement, what proportion 374 of the traffic for a given E2E reservation is passing along 375 each of the paths, and assure ourselves of sufficient 376 bandwidth for the present use. A simple, though inelegant, way 377 of doing this is to reserve the total capacity of the 378 aggregate route down each path. 380 For this reason, we believe it is advantageous to use one of 381 the above-mentioned tunneling mechanisms in cases where 382 multiple equal-cost paths may exist. 384 Draft RSVP Reservation Aggregation December 1999 386 1.4.5. Inter-domain Routes 388 The case of inter-domain routes differs somewhat from the 389 intra-domain case just described. Specifically, best-path 390 considerations do not apply, as routing is by a combination of 391 routing policy and shortest AS path rather than simple best 392 metric. 394 In the case of inter-domain routes, data traffic belonging to 395 different E2E sessions (but the same aggregate session) may 396 not enter an aggregation region via the same aggregator 397 interface, and/or may not leave via the same deaggregator 398 interface. It is possible that we could identify this 399 occurrence in some central system which sees the reservation 400 information for both of the apparent sessions, but it is not 401 clear that we could determine a priori how much traffic went 402 one way or the other apart from measurement. 404 We simply note that this problem can occur and needs to be 405 allowed for in the implementation. We recommend that each such 406 e2e reservation be summed into its appropriate aggregate 407 reservation, even though this involves over-reservation. 409 1.4.6. Reservations for Multicast Sessions 411 Aggregating reservations for multicast sessions is 412 significantly more complex than for unicast sessions. The 413 first challenge is to construct a multicast tree for 414 distribution of the aggregate Path messages which follows the 415 same path as will be followed by the data packets for which 416 the aggregate reservation is to be made. This is complicated 417 by the fact that the path taken by a data packet may depend on 418 many factors such as its source address, the choice of shared 419 trees or source-specific trees, and the location of a 420 rendezvous point for the tree. 422 Once the problem of distributing aggregate Path messages is 423 solved, there are considerable problems in determining the 424 correct amount of resources to reserve at each link along the 425 multicast tree. Because of the amount of heterogeneity that 426 may exist in an aggregate multicast reservation, it appears 427 that it would be necessary to retain information about 428 individual E2E reservations within the aggregation region to 429 allocate resources correctly. Thus, we may end up with a 430 complex set of procedures for forming aggregate reservations 431 that do not actually reduce the amount of stored state 433 Draft RSVP Reservation Aggregation December 1999 435 significantly for multicast sessions. [BERSON] describes 436 possible ways to reduce this state by using measurement-based 437 admission control. 439 As noted above, there are several aspects to RSVP state, and 440 our approach for unicast aggregates all forms of state: 441 classification, scheduling, and reservation state. One 442 possible approach to multicast is to focus only on aggregation 443 of classification and scheduling state, which are arguably the 444 most important because of their impact on the fast path. That 445 approach is the one described in the current draft. 447 1.4.7. Multi-level Aggregation 449 Ideally, an aggregation scheme should be able to accommodate 450 recursive aggregation, with aggregate reservations being 451 themselves aggregated. Multi-level aggregation can be 452 accomplished using the procedures described here and a simple 453 extension to the protocol number swapping process. 455 We can consider E2E RSVP reservations to be at aggregation 456 level 0. When we aggregate these reservations, we produce 457 reservations at aggregation level 1. In general, level n 458 reservations may be aggregated to form reservations at level 459 n+1. 461 When an aggregating router receives an E2E Path, it swaps the 462 protocol number from RSVP to RSVP-E2E-IGNORE. In addition, it 463 should write the aggregation level (1, in this case) in the 2 464 byte field that is present (and currently unused) in the 465 router alert option. In general, a router which aggregates 466 reservations at level n to create reservations at level n+1 467 will write the number n+1 in the router alert field. A router 468 which deaggregates level n+1 reservations will examine all 469 messages with IP protocol number RSVP-E2E-IGNORE but will 470 process the message and swap the protocol number back to RSVP 471 only in the case where the router alert field carries the 472 number n+1. For any other value, the message is forwarded 473 unchanged. Interior routers ignore all messages with IP 474 protocol number RSVP-E2E-IGNORE. Note that only a few bits of 475 the 2 byte field in the option would be needed, given the 476 likely number of levels of aggregation. 478 Draft RSVP Reservation Aggregation December 1999 480 1.4.8. Reliability Issues 482 There are a variety of issues that arise in the context of 483 aggregation that would benefit from some form of explicit 484 acknowledgment mechanism for RSVP messages. For example, it 485 is possible to configure a set of routers such that an E2E 486 Path of protocol type RSVP-E2E-IGNORE would be effectively 487 "black-holed", if it never reached a router which was 488 appropriately configured to act as a deaggregator. It could 489 then travel all the way to its destination where it would 490 probably be ignored due to its non-standard protocol number. 491 This situation is not easy to detect. The aggregator can be 492 sure this problem has not occurred if an aggregate PathErr 493 message is received from the deaggregator (as described in 494 detail below). It can also be sure there is no problem if an 495 E2E Resv is received. However, the fact that neither of these 496 events has happened may only mean that no receiver wishes to 497 reserve resources for this session, or that an RSVP message 498 loss occurred, or it may mean that the Path was black-holed. 499 However, if a neighbor-to-neighbor acknowledgment mechanism 500 existed, the aggregator would expect to receive an 501 acknowledgment of the E2E Path from the deaggregator, and 502 would interpret the lack of a response as an indication that a 503 problem of configuration existed. It could then refrain from 504 aggregating this particular session. We note that such a 505 reliability mechanism has been proposed for RSVP in [REFRESH] 506 and propose that it be used here. 508 1.4.9. Aggregated reservations without E2E reservations 510 Up to this point we have assumed that the aggregate 511 reservation is established as a result of the establishment of 512 E2E reservations from outside the aggregation region. It 513 should be clear that alternative triggers are possible. As 514 discussed in [ISDS], an aggregate RSVP reservation can be used 515 to manage bandwidth in a diff-serv cloud even if RSVP is not 516 used end-to-end. 518 The simplest example of an alternative configuration is the 519 static configuration of an aggregated reservation for a 520 certain amount for traffic from an ingress (aggregator) router 521 to an egress (de-aggregator) router. This would have to be 522 configured in at least the system originating the aggregate 523 PATH message (the aggregator). The deaggregator could detect 524 that the PATH message is directed to it, and could be 525 configured to "turn around" such messages, i.e., it responds 527 Draft RSVP Reservation Aggregation December 1999 529 with a RESV back to the aggregator. Alternatively, 530 configuration of the aggregate reservation could be performed 531 at both the aggregator and the deaggregator. As before, an 532 aggregate reservation is associated with a DSCP for the 533 traffic that will use the reserved capacity. 535 In the absence of E2E microflow reservations, the aggregator 536 can use a variety of policies to set the DSCP of packets 537 passing into the aggregation region, thus determining whether 538 they gain access to the resources reserved by the aggregate 539 reservation. These policies are a matter of local 540 configuration, as usual for a device at the edge of a diff- 541 serv cloud. 543 Note that the "aggregator" could even be a device such as a 544 PSTN gateway which makes an aggregate reservation for the set 545 of calls to another PSTN gateway (the deaggregator) across an 546 intervening diff-serv region. In this case the reservation may 547 be established in response to call signalling. 549 From the perspective of RSVP signalling and the handling of 550 data packets in the aggregation region, these cases are 551 equivalent to the case of aggregating E2E RSVP reservations. 552 The only difference is that E2E RSVP signalling does not take 553 place and cannot therefore be used as a trigger, so some 554 additional knowledge is required in setting up the aggregate 555 reservation. 557 Draft RSVP Reservation Aggregation December 1999 559 2. Elements of Procedure 561 To implement aggregation, we define a number of elements of 562 procedure. 564 2.1. Receipt of E2E Path Message By Aggregating Router 566 The very first event is the arrival of the E2E Path message at 567 an exterior interface of an aggregator. Standard RSVP 568 procedures [RSVP] are followed for this, including onto what 569 set of interfaces the message should be forwarded. These 570 interfaces comprise zero or more exterior interfaces and zero 571 or more interior interfaces. (If the number of interior 572 interfaces is zero, the router is not acting as an aggregator 573 for this E2E flow.) 575 Service on exterior interfaces is handled as defined in 576 [RSVP]. 578 Service on interior interfaces is complicated by the fact that 579 the message needs to be included in some aggregate 580 reservation, but at this point it is not known which one, 581 because the deaggregator is not known. Therefore, the E2E Path 582 message is forwarded on the interior interface(s) using the IP 583 Protocol number RSVP-E2E-IGNORE, but in every other respect 584 identically to the way it would be sent by an RSVP router that 585 was not performing aggregation. 587 2.2. Handling Of E2E Path Message By Interior Routers 589 At this point, the e2e Path message traverses zero or more 590 interior routers. Interior routers receive the e2e Path 591 message on an interior interface and forward it on another 592 interior interface. The Router Alert IP Option alerts interior 593 routers to check internally, but they find that the IP 594 Protocol is RSVP-E2E-IGNORE and the next hop interface is 595 interior. As such, they simply forward it as a normal IP 596 datagram. 598 2.3. Receipt of E2E Path Message By Deaggregating Router 600 The E2E Path message finally arrives at a deaggregating 601 router, which receives it on an interior interface and 603 Draft RSVP Reservation Aggregation December 1999 605 forwards it on an exterior interface. Again, the Router Alert 606 IP Option alerts it to intercept the message, but this time 607 the IP Protocol is RSVP-E2E-IGNORE and the next hop interface 608 is an exterior interface. 610 At this point, the deaggregating router associates the flow 611 with an aggregate reservation. This selection is done on the 612 basis of policy, and may take into account not only the 613 aggregating router (whose IP Address may be found in the RSVP 614 Hop Object) but other information about the flow. If no such 615 aggregate reservation exists and the router is so configured, 616 it may generate a PathErr with code NEW-AGGREGATE-NEEDED back 617 to the aggregating router. This should not result in any 618 reservation being taken down, but may result in the 619 aggregating router initiating the necessary aggregate Path 620 message, as described in the following section. 622 The deaggregating router changes the e2e Path message's IP 623 Protocol from RSVP-E2E-IGNORE to IP Protocol RSVP, updates the 624 ADSPEC of the e2e Path using information accumulated by the 625 aggregate Path ADSPEC (if an aggregate Path has been 626 received), and the E2E Path message is forwarded towards its 627 intended destination. To enable correct updating of the 628 ADSPEC, a deaggregating router may wait for the arrival of an 629 aggregate Path before forwarding the E2E Path. 631 2.4. Initiation of New Aggregate Path Message By Aggregating 632 Router 634 The aggregating router is responsible to take account of the 635 SENDER_TSPEC information from individual E2E Path messages in 636 constructing the SENDER_TSPEC of the aggregate Path message it 637 sends to its deaggregating router. The aggregating router may 638 know that an E2E session is associated with a given 639 deaggregator when one of two events occurs: it receives a 640 PathErr message with the error code NEW-AGGREGATE-NEEDED from 641 the deaggregator, or it receives an E2E Resv message from the 642 deaggregator. In the latter case, the Resv contains a DCLASS 643 object [DCLASS] indicating which DSCP the deaggregator 644 believes that the E2E flow belongs in. In the former case, the 645 aggregator must make its own determination of a suitable DSCP 646 based on the information in the E2E Path message(s) being 647 aggregated and using locally available policy information. 648 The identity of the deaggregator itself is found in either the 649 ERROR SPECIFICATION of the PathErr message or the RSVP HOP 651 Draft RSVP Reservation Aggregation December 1999 653 object of the E2E Resv. 655 On receipt of either message, if no corresponding aggregate 656 path state exists from the aggregator to the deaggregator for 657 a session with the appropriate DSCP, and the aggregator is 658 configured to do so, the aggregator should generate an 659 aggregate Path message for the aggregate reservation. The 660 destination address of the aggregate Path message is the 661 address of the deaggregating router, and the message is sent 662 with IP protocol number RSVP. 664 2.5. Handling of E2E Resv Message by Deaggregating Router 666 Having sent the E2E Path message on toward the destination, 667 the deaggregator must now expect to receive an E2E Resv for 668 the session. On receipt, its responsibility is to ensure that 669 there is sufficient bandwidth reserved within the aggregation 670 region to support the new E2E reservation, and if there is, 671 then to forward the E2E Resv to the aggregating router. 673 If there is insufficient bandwidth reserved, it should follow 674 the normal RSVP procedures [RSVP] for a reservation being 675 placed with insufficient bandwidth to support the reservation. 676 It may also immediately attempt to increase the aggregate 677 reservation that is supplying bandwidth by increasing the size 678 of the flowspec that it includes in the aggregate Resv that it 679 sends upstream. However, this may not be sufficient to 680 increase the size of the aggregate reservation, because RSVP 681 routers take the minimum of the Sender TSpec and Receiver 682 TSpec when installing a reservation, and thus the installed 683 aggregate reservation may be limited by the size of the sender 684 TSpec. The likelihood of this situation can be reduced by a 685 sufficiently large choice of TSpec by the aggregator. 687 When sufficient bandwidth is available, it may simply send the 688 E2E Resv message with IP Protocol RSVP to the aggregating 689 router. This message should, in addition to other data, 690 contain the DCLASS object to indicate which DSCP the 691 deaggregating router expects the aggregator to use. The choice 692 of DSCP may be made based on a combination of information in 693 the received E2E Resv and local policy. An example policy 694 might dictate a certain DSCP for Guaranteed Service and 695 another DSCP for Controlled Load. The de-aggregator will also 696 add the token bucket from the FLOWSPEC object into its 697 internal understanding of how much of that reservation is in 698 use. 700 Draft RSVP Reservation Aggregation December 1999 702 2.6. Initiation of New Aggregate Resv Message By 703 Deaggregating Router 705 Upon receiving an E2E Resv message on an exterior interface, 706 and having determined the appropriate DSCP for the session, 707 the deaggregator looks for corresponding path state for a 708 session with the chosen DSCP. If aggregate Path state exists, 709 but no aggregate Resv state exists, the deaggregator creates 710 an aggregate Resv and sets its initial request to a value not 711 smaller than the requirement of the E2E reservation it is 712 supporting. 714 If no aggregate Path state exists for the appropriate DSCP, 715 this may be because the aggregator has not yet responded to 716 the arrival of the E2E Resv sent in the preceding step. To 717 avoid deadlock while waiting for a response, it would be 718 desirable to use the acknowledgment mechanisms described in 719 [REFRESH]. 721 Once the deaggregator has established the aggregate Path 722 state, then it sends an aggregate Resv message toward the 723 aggregator (i.e., to the previous hop), using the AGGREGATED- 724 RSVP session and filter specifications. Since the DSCP is in 725 the SESSION object, the DCLASS is unnecessary. The message 726 should be reliably delivered using the mechanisms in [REFRESH] 727 or, alternatively, the CONFIRM object may be used, to assure 728 that the aggregate Resv does indeed arrive and is granted. 729 This enables the deaggregator to determine that the requested 730 bandwidth is available to allocate to the E2E flows it 731 supports. 733 2.7. Handling of Aggregate Resv Message by Interior Routers 735 The aggregate Resv message is handled in essentially the same 736 way as defined in [RSVP]. The Session object contains the 737 address of the deaggregating router (or the group address for 738 the session in the case of multicast) and the DSCP that has 739 been chosen for the session. The Filterspec object identifies 740 the aggregating router. These routers perform admission 741 control and resource allocation as usual and send the 742 aggregate Resv on towards the aggregator. 744 Draft RSVP Reservation Aggregation December 1999 746 2.8. Handling of E2E Resv Message by Aggregating Router 748 The E2E Resv message is the final confirmation to the 749 aggregating router that a proportion of a given aggregate's 750 bandwidth has been reserved. At this point, it should ensure 751 that the E2E reservation is associated with an appropriate 752 aggregate, that the aggregator and deaggregator expectations 753 synchronize, and that all things are in place. In particular, 754 it needs to ensure that the DCLASS carried in the E2E Resv 755 matches the DSCP for an aggregate session to that 756 deaggregator; if not, it needs to create a new aggregate Path 757 for the appropriate DSCP and send it to the deaggregator. It 758 should also ensure that the SENDER_TSPEC from the E2E Path 759 message has been accumulated into the appropriate aggregate 760 Path message. Under normal circumstances, this is the only way 761 it will be informed of this association. It should now forward 762 the E2E Resv to its previous hop, following normal RSVP 763 processing rules [RSVP]. 765 2.9. Removal of E2E Reservation 767 E2E reservations are removed in the usual way via PathTear, 768 ResvTear, timeout, or as the result of an error condition. 769 When they are removed, their FLOWSPEC information must also be 770 removed from the allocated portion of the aggregate 771 reservation. This same bandwidth may be re-used for other 772 traffic in the near future. When E2E Path messages are 773 removed, their SENDER_TSPEC information must also be removed 774 from the aggregate Path. 776 2.10. Removal of Aggregate Reservation 778 Should an aggregate reservation go away (presumably due to a 779 configuration change, route change, or policy event), the E2E 780 reservations it supports are no longer active. They must be 781 treated accordingly. 783 2.11. Handling of Data On Reserved E2E Flow by Aggregating 784 Router 786 Prior to establishment that a given E2E flow is part of a 787 given aggregate, the flow's data should be treated as traffic 788 without a reservation by whatever policies prevail for such. 789 Generally, this will mean being given the same forwarding 791 Draft RSVP Reservation Aggregation December 1999 793 behavior as non-essential traffic. However, upon establishing 794 that the flow belongs to a given aggregate, the aggregating 795 router is responsible to mark any related traffic with the 796 correct DSCP and forward it in the manner appropriate to 797 traffic on that reservation. This may imply forwarding it to a 798 given IP next hop, or piping it down a given link layer 799 circuit, tunnel, or MPLS label switched path. 801 The aggregator is responsible for performing per-reservation 802 policing on the E2E flows that it is aggregating. The 803 aggregator performs metering of traffic belonging to each 804 reservation to assess compliance to the token bucket for the 805 corresponding E2E reservation. Packets which are assessed in 806 compliance are forwarded as mentioned above. Packets which are 807 assessed out of compliance must be either dropped or marked to 808 a different DSCP. The detailed policing behavior is an aspect 809 of the service mapping described in [ISDS]. 811 2.12. Procedures for Multicast Sessions 813 Because of the difficulties of aggregating multicast sessions 814 described above, we focus on the aggregation of scheduling and 815 classification state in the multicast case. The main 816 difference between the multicast and unicast cases is that 817 rather than sending an aggregate Path message to the unicast 818 address of a single deaggregating router, in the multicast 819 case we send the "aggregate" Path message to the same group 820 address as the E2E session. This ensures that the aggregate 821 Path message follows the same route as the E2E Path. This 822 difference between unicast and multicast is reflected in the 823 Session objects defined below. A consequence of this approach 824 is that we continue to have reservation state per multicast 825 session inside the aggregation region. 827 A further challenge arises in multicast sessions with 828 heterogeneous receivers. Consider an interior router which 829 must forward packets for a multicast session on two 830 interfaces, but has only received a reservation request on one 831 of those interfaces. It receives packets marked with the DSCP 832 chosen for the aggregate reservation. When sending them out 833 the interface which has no installed reservation, it has the 834 following options: 836 a) remark those packets to best effort before sending 837 them out the interface; 839 Draft RSVP Reservation Aggregation December 1999 841 b) send the packets out the interface with the DSCP 842 chosen for the aggregate reservation. 844 The first approach suffers from the drawback that it requires 845 MF classification at an interior router in order to recognize 846 the flows whose packets must be demoted. The second approach 847 requires over-reservation of resources on the interface on 848 which no reservation was received. In the absence of such 849 over-reservation, the packets sent with the "wrong" DSCP would 850 be able to degrade the service experienced by packets using 851 that DSCP legitimately. 853 To make MF classification acceptable in an interior router, it 854 may be possible to treat the case of heterogenous flows as an 855 exception. That is, an interior router only needs to be able 856 to recognize those individual microflows that have 857 heterogeneous resource needs on the outbound interfaces of 858 this router. 860 3. Protocol Elements 862 3.1. IP Protocol RSVP-E2E-IGNORE 864 This specification presumes the assignment of a protocol type 865 RSVP-E2E-IGNORE, whose number is at this point TBD. This is 866 used only on messages which require a router alert (Path, 867 PathErr, and ResvConf), and signifies that the message must be 868 treated one way when copied to an interior interface, and 869 another way when copied to an exterior interface. 871 3.2. Path Error Code 873 A PathErr code NEW-AGGREGATE-NEEDED is presumed. This value 874 does not signify that a fatal error has occurred, but that an 875 action is required of the aggregating router to avoid an error 876 condition in the near future. 878 3.3. SESSION Object 880 The SESSION object contains two values: the IP Address of the 881 aggregate session destination, and the DSCP that it will use 882 on the E2E data the reservation contains. For unicast 883 sessions, the session destination address is the address of 884 the deaggregating router. For multicast sessions, the session 886 Draft RSVP Reservation Aggregation December 1999 888 destination is the multicast address of the E2E session (or 889 sessions) being aggregated. The inclusion of the DSCP in the 890 session allows for multiple sessions toward the same address 891 to be distinguished by their DSCP and queued separately. It 892 also provides the means for aggregating scheduling and 893 classification state. In the case where a session uses a pair 894 of PHBs (e.g. AF11 and AF12), the DSCP used should represent 895 the numerically smallest PHB (e.g. AF11). This follows the 896 same naming convention described in [BRIM]. 898 Session types are defined for IPv4 and IPv6 addresses. 900 o IP4 SESSION object: Class = SESSION, 901 C-Type = RSVP-AGGREGATE-IP4 903 +-------------+-------------+-------------+-------------+ 904 | IPv4 Session Address (4 bytes) | 905 +-------------+-------------+-------------+-------------+ 906 | /////////// | Flags | ///////// | DSCP | 907 +-------------+-------------+-------------+-------------+ 909 o IP6 SESSION object: Class = SESSION, 910 C-Type = RSVP-AGGREGATE-IP6 912 +-------------+-------------+-------------+-------------+ 913 | | 914 + + 915 | | 916 + IPv6 Session Address (16 bytes) + 917 | | 918 + + 919 | | 920 +-------------+-------------+-------------+-------------+ 921 | /////////// | Flags | ///////// | DSCP | 922 +-------------+-------------+-------------+-------------+ 924 3.4. SENDER_TEMPLATE Object 926 The SENDER_TEMPLATE object identifies the aggregating router 927 for the aggregate reservation. 929 Draft RSVP Reservation Aggregation December 1999 931 o IP4 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE, 932 C-Type = RSVP-AGGREGATE-IP4 934 +-------------+-------------+-------------+-------------+ 935 | IPv4 Aggregator Address (4 bytes) | 936 +-------------+-------------+-------------+-------------+ 938 o IP6 SENDER_TEMPLATE object: Class = SENDER_TEMPLATE, 939 C-Type = RSVP-AGGREGATE-IP6 941 +-------------+-------------+-------------+-------------+ 942 | | 943 + + 944 | | 945 + IPv6 Aggregator Address (16 bytes) + 946 | | 947 + + 948 | | 949 +-------------+-------------+-------------+-------------+ 951 3.5. FILTER_SPEC Object 953 The FILTER_SPEC object identifies the aggregating router for 954 the aggregate reservation, and is syntactically identical to 955 the SENDER_TEMPLATE object. 957 Draft RSVP Reservation Aggregation December 1999 959 4. Policies and Algorithms For Predictive Management Of 960 Blocks Of Bandwidth 962 The exact policies used in determining how much bandwidth 963 should be allocated to an aggregate reservation at any given 964 time are beyond the scope of this document, and may be 965 proprietary to the service provider in question. However, here 966 we explore some of the issues and suggest approaches. 968 In short, the ideal condition is that the aggregate 969 reservation always has enough resources to allocate to any E2E 970 reservation that requires its support, and never takes too 971 much. Simply stated, but more difficult to achieve. Factors 972 that come into account include significant times in the 973 diurnal cycle: one may find that a large number of people 974 start placing calls at 8:00 AM, even though the hour from 7:00 975 to 8:00 is dead calm. They also include recent history: if 976 more people have been placing calls recently than have been 977 finishing them, a prediction of the necessary bandwidth a few 978 moments hence may call for more bandwidth than is currently 979 allocated. Likewise, at the end of a busy period, we may find 980 that the trend calls for declining reservation amounts. 982 We recommend a policy something along this line. At any given 983 time, one should expect that the amount of bandwidth required 984 for the aggregate reservation is the larger of the following: 986 (a) a requirement known a priori, such as from history of the 987 diurnal cycle at a particular week day and time of day, 988 and 990 (b) the trend line over recent history, with 90 or 99% 991 statistical confidence. 993 We further expect that changes to that aggregate reservation 994 would be made no more often than every few minutes, and 995 ideally perhaps on larger granularity such as fifteen minute 996 intervals or hourly. The finer the granularity, the greater 997 the level of signaling required, while the coarser the 998 granularity, the greater the chance for error, and the need to 999 recover from that error. 1001 In general, we expect that the aggregate reservation will not 1002 ever add up to exactly the sum of the reservations it 1003 supports, but rather will be an integer multiple of some block 1004 reservation size, which exceeds that value. 1006 Draft RSVP Reservation Aggregation December 1999 1008 5. Security Considerations 1010 Numerous security issues pertain to this document; for 1011 example, the loss of an aggregate reservation to an aggressor 1012 causes many calls to operate unreserved, and the reservation 1013 of a great excess of bandwidth may result in a denial of 1014 service. However, these issues are not confined to this 1015 extension: RSVP itself has them. We believe that the security 1016 mechanisms in RSVP address these issues as well. 1018 6. IANA Considerations 1020 Beyond allocating an IP Protocol, a PathErr code, and an RSVP 1021 Addressing object "type", there are no IANA issues in this 1022 document. We do not define an object that will itself require 1023 assignment by IANA. 1025 7. Acknowledgments 1027 The authors acknowledge that published documents and 1028 discussion with several people, notably John Wroclawski, Steve 1029 Berson, and Andreas Terzis materially contributed to this 1030 draft. The design derives directly from an internet draft by 1031 Roch Guerin [GUERIN] and from Steve Berson's drafts on the 1032 subject. It is also influenced by the design in the diff-edge 1033 draft by Bernet et al [BERNET] and by the RSVP tunnels draft 1034 [TERZIS]. 1036 Draft RSVP Reservation Aggregation December 1999 1038 8. References 1040 [CSZ] 1041 Clark, D., S. Shenker, and L. Zhang, "Supporting Real- 1042 Time Applications in an Integrated Services Packet 1043 Network: Architecture and Mechanism," in Proc. 1044 SIGCOMM'92, September 1992. 1046 [IP] RFC 791, "Internet Protocol". J. Postel. Sep-01-1981. 1048 [HOSTREQ] 1049 RFC 1122, "Requirements for Internet hosts - 1050 communication layers". R.T. Braden. Oct-01-1989. 1052 [FRAMEWORK] 1053 Nichols, "Differentiated Services Operational Model and 1054 Definitions", 02/11/1998, draft-nichols-dsopdef-00.txt 1056 [PRINCIPLES] 1057 RFC 1958, "Architectural Principles of the Internet". B. 1058 Carpenter. June 1996. 1060 [ASSURED] 1061 Clark and Wroclawski, "An Approach to Service Allocation 1062 in the Internet", 08/04/1997, draft-clark-diff-svc- 1063 alloc-00.txt 1065 [BROKER] 1066 Nichols and Zhang, "A Two-bit Differentiated Services 1067 Architecture for the Internet", 12/23/1997, draft- 1068 nichols-diff-svc-arch-01.txt 1070 [BERSON] 1071 Berson and Vincent. "Aggregation of Internet Integrated 1072 Services State". draft-berson-rsvp-aggregation-00.txt, 1073 August 1998 1075 [BRIM] 1076 Brim and Carpenter. "Per Hop Behavior Identification 1077 Codes". draft-brim-diffserv-phbid-00.txt, April 1999. 1079 [ISDS] 1080 Bernet et al. "Integrated Services Operation Over 1081 Diffserv Networks". draft-ietf-issll-diffserv-rsvp- 1082 03.txt, Sept. 1999. 1084 Draft RSVP Reservation Aggregation December 1999 1086 [GUERIN] 1087 Guerin, R., Blake, S. and Herzog, S.,"Aggregating RSVP 1088 based QoS Requests", Internet Draft, draft-guerin- 1089 aggreg-rsvp-00.txt, November 1997. 1091 [RSVP] 1092 Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, 1093 S., "Resource Reservation Protocol (RSVP) Version 1 1094 Functional Specification", RFC 2205, September 1997. 1096 [BERNET] 1097 Bernet, Y., Durham, D., and F. Reichmeyer, "Requirements 1098 of Diff-serv Boundary Routers", Internet Draft, draft- 1099 bernet-diffedge-01.txt, November, 1998. 1101 [REFRESH] 1102 Berger, L., Gan, D., and G. Swallow, "RSVP Refresh 1103 Reduction Extensions", Internet Draft, draft-berger- 1104 rsvp-refresh-reduct-02.txt, May 1999. 1106 [TERZIS] 1107 Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, 1108 "RSVP Operation Over IP Tunnels", Internet Draft, draft- 1109 ietf-rsvp-tunnel-04.txt, May 1999. 1111 [DCLASS] 1112 Bernet, Y., "Usage and Format of the DCLASS Object With 1113 RSVP Signaling", Internet Draft, draft-bernet-dclass- 1114 01.txt, June 1999. 1116 9. Authors' Addresses 1118 Fred Baker 1119 Cisco Systems 1120 519 Lado Drive 1121 Santa Barbara, California 93111 1122 Phone: (408) 526-4257 1123 Email: fred@cisco.com 1125 Carol Iturralde 1126 Cisco Systems 1127 250 Apollo Drive 1128 Chelmsford MA,01824 USA 1129 Phone: 978-244-8532 1130 Email: cei@cisco.com 1132 Draft RSVP Reservation Aggregation December 1999 1134 Francois Le Faucheur 1135 Cisco Systems 1136 291, rue Albert Caquot 1137 06560 Valbonne, France 1138 Phone: +33.1.6918 6266 1139 Email: flefauch@cisco.com 1141 Bruce Davie 1142 Cisco Systems 1143 250 Apollo Drive 1144 Chelmsford MA,01824 USA 1145 Phone: 978-244-8921 1146 Email: bdavie@cisco.com 1148 10. Full Copyright Statement 1150 Copyright (C) The Internet Society (1999). All Rights 1151 Reserved. 1153 This document and translations of it may be copied and 1154 furnished to others, and derivative works that comment on or 1155 otherwise explain it or assist in its implmentation may be 1156 prepared, copied, published and distributed, in whole or in 1157 part, without restriction of any kind, provided that the above 1158 copyright notice and this paragraph are included on all such 1159 copies and derivative works. However, this document itself 1160 may not be modified in any way, such as by removing the 1161 copyright notice or references to the Internet Society or 1162 other Internet organizations, except as needed for the purpose 1163 of developing Internet standards in which case the procedures 1164 for copyrights defined in the Internet Standards process must 1165 be followed, or as required to translate it into languages 1166 other than English. 1168 The limited permissions granted above are perpetual and will 1169 not be revoked by the Internet Society or its successors or 1170 assigns. 1172 This document and the information contained herein is provided 1173 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1174 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1175 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 1176 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1177 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1178 PARTICULAR PURPOSE."