idnits 2.17.1 draft-ietf-intserv-compress-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 130 has weird spacing: '...Spec is a set...' == Line 308 has weird spacing: '...rise if a sen...' == Line 318 has weird spacing: '...rwarded by th...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2000) is 8836 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: 'M' is mentioned on line 360, but not defined == Missing Reference: 'RFC 1144' is mentioned on line 425, but not defined == Unused Reference: 'RFC1144' is defined on line 492, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2216 ** Obsolete normative reference: RFC 2509 (Obsoleted by RFC 3544) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bruce Davie 2 Internet Draft Cisco Systems, Inc. 3 Expiration Date: August 2000 4 Steve Casner 5 Cisco Systems, Inc. 7 Carol Iturralde 8 Cisco Systems, Inc. 10 David Oran 11 Cisco Systems, Inc. 13 John Wroclawski 14 MIT LCS 16 February 2000 18 Integrated Services in the Presence of Compressible Flows 20 draft-ietf-intserv-compress-02.txt 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 44 An Integrated Services router performs admission control and resource 45 allocation based on the information contained in a TSpec (among other 46 things). As currently defined, TSpecs convey information about the 47 data rate (using a token bucket) and range of packet sizes of the 48 flow in question. However, the TSpec may not be an accurate 49 representation of the resources needed to support the reservation if 50 the router is able to compress the data at the link level. This 51 specification describes an extension to the TSpec which enables a 52 sender of potentially compressible data to provide hints to int-serv 53 routers about the compressibility they may obtain. Routers which 54 support appropriate compression take advantage of the hint in their 55 admission control decisions and resource allocation procedures; other 56 routers ignore the hint. An initial application of this approach is 57 to notify routers performing RTP header compression that they may 58 allocate fewer resources to RTP flows. 60 Contents 62 1 Introduction ........................................... 2 63 2 Addition of a Hint to the Sender TSpec ................. 3 64 3 Admission Control and Resource Allocation .............. 5 65 4 Object Format .......................................... 8 66 4.1 Hint Numbering ......................................... 10 67 5 Backward Compatibility ................................. 11 68 6 Security Considerations ................................ 11 69 7 IANA Considerations .................................... 12 70 8 Acknowledgments ........................................ 12 71 9 References ............................................. 12 72 10 Authors' Addresses ..................................... 13 74 1. Introduction 76 In an Integrated Services network, RSVP [RFC 2205] may be used as a 77 signalling protocol by which end nodes and network elements exchange 78 information about resource requirements, resource availability, and 79 the establishment and removal of resource reservations. The 80 Integrated Services architecture currently defines two services, 81 Controlled-Load [RFC 2211] and Guaranteed [RFC 2212]. When 82 establishing a reservation using either service, RSVP requires a 83 variety of information to be provided by the sender(s) and 84 receiver(s) for a particular reservation which is used for the 85 purposes of admission control and allocation of resources to the 86 reservation. Some of this information is provided by the receiver in 87 a FLOWSPEC object; some is provided by the sender in a SENDER_TSPEC 88 object [RFC 2210]. 90 A situation that is not handled well by the current specs arises when 91 a router that is making an admission control decision is able to 92 perform some sort of compression on the flow for which a reservation 93 is requested. For example, suppose a router is able to perform 94 IP/UDP/RTP header compression on one of its interfaces [RFC 2508]. 95 The bandwidth needed to accommodate a compressible flow on that 96 interface would be less than the amount contained in the 97 SENDER_TSPEC. Thus the router might erroneously reject a reservation 98 that could in fact have been accommodated. At the same time, the 99 sender is not at liberty to reduce its TSpec to account for the 100 compression of the data, since it does not know if the routers along 101 the path are in fact able to perform compression. Furthermore, it is 102 probable that only a subset of the routers on the path (e.g., those 103 connected to low-speed serial links) will perform compression. 105 This specification describes a mechanism by which the sender can 106 provide a hint to network elements regarding the compressibility of 107 the data stream that it will generate. Network elements may use this 108 hint as an additional piece of data when making admission control and 109 resource allocation decisions. 111 This specification is restricted to the case where compression is 112 performed only on a link-by-link basis, as with header compression. 113 Other cases (e.g., transcoding, audio silence detection) which would 114 affect the bandwidth consumed at all downstream nodes are for further 115 study. In these latter cases, it would be necessary to modify a 116 sender TSpec as it is passed through a compressing node. In the 117 approach presented here, the sender TSpec that appears on the wire is 118 never modified, just as specified in [RFC 2210]. 120 2. Addition of a Hint to the Sender TSpec 122 The appropriate place for a `compressibility hint' is the Sender 123 TSpec. The reasons for this choice are: 125 - The sender is the party who knows best what the data will look 126 like. 128 - Unlike the Adspec, the Sender TSpec is not modified in transit 130 - From the perspective of RSVP, the Sender TSpec is a set of 131 opaque parameters that are passed to `traffic control' (admission 132 control and resource allocation); the compressibility hint is just 133 such a parameter. 135 An alternative to putting this information in the TSpec would be to 136 use an additional object in the RSVP PATH message. While this could 137 be made to work for RSVP, it does not address the issue of how to get 138 the same information to an intserv router when mechanisms other than 139 RSVP are used to reserve resources. It would also imply a change to 140 RSVP message processing just for the purposes of getting more 141 information to entities that are logically not part of RSVP 142 (admission control and resource allocation). The inclusion of the 143 information in the TSpec seems preferable and more consistent with 144 the Integrated Services architecture. 146 The contents of the hint are likely to vary depending on the exact 147 scenario. The hint needs to tell the routers that receive it: 149 - the type of compression that is possible on this flow (e.g. 150 IP/UDP/RTP); 152 - enough information to enable a router to determine the likely 153 compression ratio that may be achieved. 155 In a simple case such as IP/UDP/RTP header compression, it may be 156 sufficient to tell the routers nothing more than the fact that 157 IP/UDP/RTP data is being sent. Knowing this fact, the maximum packet 158 size of the flow (from the TSpec), and the local conditions at the 159 router, may be sufficient to allow the router to determine the 160 reduction in bandwidth that compression will allow. In other cases, 161 it may be helpful or necessary for the sender to include additional 162 quantitative information to assist in the calculation of the 163 compression ratio. To handle these cases, additional parameters 164 containing various amounts of information may be added to the sender 165 TSpec. Details of the encoding of these parameters, following the 166 approach originally described in [RFC 2210] are described below. 168 3. Admission Control and Resource Allocation 170 Integrated Services routers make admission control and resource 171 allocation decisions based on, among other things, information in the 172 sender TSpec. If a router receives a sender TSpec which contains a 173 compressibility hint, it may use the hint to calculate a `compressed 174 TSpec' which can be used as input to the admission control and 175 resource allocation processes in place of the TSpec provided by the 176 sender. To make this concrete, consider the following simple example. 177 A router receives a reservation request for controlled load service 178 where: 180 - The Sender TSpec and Receiver TSpec contain identical token 181 bucket parameters; 183 - The rate parameter in the token bucket (r) is 48 kbps; 185 - The token bucket depth (b) is 120 bytes; 187 - The maximum packet size (M) in the TSpecs is 120 bytes; 189 - The minimum policed unit (m) is 64 bytes; 191 - The Sender TSpec contains a compressibility hint indicating that 192 the data is IP/UDP/RTP; 194 - The compressibility hint includes a compression factor of 70%, 195 meaning that IP/UDP/RTP header compression will cause a reduction 196 in bandwidth consumed at the link level by a factor of 0.7 (the 197 result of compressing 40 bytes of IP/UDP/RTP header to 4 bytes on 198 a 120 byte packet) 200 - The interface on which the reservation is to be installed is 201 able to perform IP/UDP/RTP header compression. 203 The router may thus conclude that it can scale down the token bucket 204 parameters r and b by a factor of 0.7, i.e., to 33.6 kbps and 84 205 bytes respectively. M may be scaled down by the same factor (to 84 206 bytes), but a different calculation should be used for m. If the 207 sender actually sends a packet of size m, its header may be 208 compressed from 40 bytes to 4, thus reducing the packet to 28 bytes; 209 this value should be used for m. 211 Note that if the source always sends packets of the same size and 212 IP/UDP/RTP always works perfectly, the compression factor is not 213 strictly needed. The router can independently determine that it can 214 compress the 40 bytes of IP/UDP/RTP header to 4 bytes (with high 215 probability). To determine the worst-case (smallest) gain provided by 216 compression, it can assume that the sender always sends maximum sized 217 packets at 48 kbps, i.e. a 120 byte packet every 20 milliseconds. The 218 router can conclude that these packets would be compressed to 84 219 bytes, yielding a token bucket rate of 33.6 kbps and a token bucket 220 depth of 84 bytes as before. If the sender is willing to allow an 221 independent calculation of compression gain by the router, the 222 explicit compression factor may be omitted from the TSpec. Details of 223 the TSpec encoding are provided below. 225 To generalize the above discussion, assume that the Sender TSpec 226 consists of values (r, b, p, M, m), that the explicit compression 227 factor provided by the sender is f percent, and that the number of 228 bytes saved by compression is N, independent of packet size. The 229 parameters in the compressed TSpec would be: 231 r' = r * f/100 232 b' = b * f/100 233 p' = p 234 M' = M-N 235 m' = m-N 237 The calculations for r' and b' reflect that fact that f is expressed 238 as a percentage and must therefore be divided by 100. The 239 calculations for M' and m' hold only in the case where the 240 compression algorithm reduces packets by a certain number of bytes 241 independent of content or length of the packet, as is true for header 242 compression. Other compression algorithms may not have this property. 243 In determining the value of N, the router may need to make worst case 244 assumptions about the number of bytes that may be removed by 245 compression, which depends on such factors as the presence of UDP 246 checksums and the linearity of RTP timestamps. 248 All these adjusted values are used in the compressed TSpec. The 249 router's admission control and resource allocation algorithms should 250 behave as if the sender TSpec contained those values. [RFC 2205] 251 provides a set of rules by which sender and receiver TSpecs are 252 combined to calculate a single `effective' TSpec that is passed to 253 admission control. When a reservation covering multiple senders is to 254 be installed, it is necessary to reduce each sender TSpec by its 255 appropriate compression factor. The set of sender TSpecs that apply 256 to a single reservation on an interface are added together to form 257 the effective sender TSpec, which is passed to traffic control. The 258 effective receiver TSpec need not be modified; traffic control takes 259 the greatest lower bound of these two TSpecs when making its 260 admission control and resource allocation decisions. 262 The handling of the receiver RSpec depends on whether controlled load 263 or guaranteed service is used. In the case of controlled load, no 264 additional processing of RSpec is needed. However, a guaranteed 265 service RSpec contains a rate term R which does need to be adjusted 266 downwards to account for compression. To determine how R should be 267 adjusted, we note that the receiver has chosen R to meet a certain 268 delay goal, and that the terms in the delay equation that depend on R 269 are b/R and C/R (when the peak rate is large). The burstsize b in 270 this case is the sum of the burstsizes of all the senders for this 271 reservation, and each of these numbers has been scaled down by the 272 appropriate compression factor. Thus, R should be scaled down using 273 an average compression factor 275 f_avg = (b1*f1 + b2*f2 + ... + bn*fn)/(b1 + b2 + ... bn) 277 where bk is the burstsize of sender k and fk is the corresponding 278 compression factor for this sender. Note that f_avg, like the 279 individual fi's, is a percentage. Note also that this results in a 280 compression factor of f in the case where all senders use the same 281 compression factor f. 283 To prevent an increase in delay caused by the C/R term when the 284 reduced value of R is used for the reservation, it is necessary for 285 this hop to `inflate' its value of C by dividing it by (f_avg/100). 286 This will cause the contribution to delay made by this hop's C term 287 to be what the receiver would expect when it chooses its value of R. 289 There are certain risks in adjusting the resource requirements 290 downwards for the purposes of admission control and resource 291 allocation. Most compression algorithms are not completely 292 deterministic, and thus there is a risk that a flow will turn out to 293 be less compressible than had been assumed by admission control. This 294 risk is reduced by the use of the explicit compression factor 295 provided by the sender, and may be minimized if the router makes 296 worst case assumptions about the amount of compression that may be 297 achieved. This is somewhat analogous to the tradeoff between making 298 worst case assumptions when performing admission control or making 299 more optimistic assumptions, as in the case of measurement-based 300 admission control. If a flow turns out to be less compressible that 301 had been assumed when performing admission control, any extra traffic 302 will need to be policed according to normal intserv rules. For 303 example, if the router assumed that the 48 kbps stream above could be 304 compressed to 33.6 kbps and it was ultimately possible to compress it 305 to 35 kbps, the extra 1.4 kbps would be treated as excess. The exact 306 treatment of such excess is service dependent. 308 A similar scenario may arise if a sender claims that data for a 309 certain session is compressible when in fact it is not, or overstates 310 the extent of its compressibility. This might cause the flow to be 311 erroneously admitted, and would cause insufficient resources to be 312 allocated to it. To prevent such behavior from adversely affecting 313 other reserved flows, any flow that sends a compressibility hint 314 should be policed (in any router that has made use of the hint for 315 its admission control) on the assumption that it is indeed 316 compressible, i.e. using the compressed TSpec. That is, if the flow 317 is found to be less compressible than advertised, the extra traffic 318 that must be forwarded by the router above the compressed TSpec will 319 be policed according to intserv rules appropriate for the service. 321 Note that RSVP does not generally require flows to be policed at 322 every hop. To quote [RFC 2205] 324 Some QoS services may require traffic policing at some or all of 325 (1) the edge of the network, (2) a merging point for data from 326 multiple senders, and/or (3) a branch point where traffic flow 327 from upstream may be greater than the downstream reservation being 328 requested. RSVP knows where such points occur and must so 329 indicate to the traffic control mechanism. 331 For the purposes of policing, a router which makes use of the 332 compressibility hint in a sender TSpec should behave as if it is at 333 the edge of the network, because it is in a position to receive 334 traffic from a sender that, while it passed through policing at the 335 real network edge, may still need to be policed if the amount of data 336 sent exceeds the amount described by the compressed TSpec. 338 4. Object Format 340 The compressibility hint may be included in the sender TSpec using 341 the encoding rules of Appendix A in [RFC 2210]. The complete sender 342 TSpec is as follows: 344 31 24 23 16 15 8 7 0 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 1 | 0 (a) | reserved | 10 (b) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 2 | 1 (c) |0| reserved | 9 (d) | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 3 | 127 (e) | 0 (f) | 5 (g) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 7 | Minimum Policed Unit [m] (32-bit integer) | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 8 | Maximum Packet Size [M] (32-bit integer) | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 9 | 126 (h) | 0 (i) | 2 (j) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 10 | Hint (assigned number) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 11 | Compression factor [f] (32-bit integer) | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 (a) - Message format version number (0) 370 (b) - Overall length (10 words not including header) 371 (c) - Service header, service number 1 (default/global information) 372 (d) - Length of service 1 data, 9 words not including header 373 (e) - Parameter ID, parameter 127 (Token_Bucket_TSpec) 374 (f) - Parameter 127 flags (none set) 375 (g) - Parameter 127 length, 5 words not including header 376 (h) - Parameter ID, parameter 126 (Compression_Hint) 377 (i) - Parameter 126 flags (none set) 378 (j) - Parameter 126 length, 2 words not including header 380 The difference between this TSpec and the one described in [RFC 2210] 381 is that the overall length contained in the first word is increased 382 by 3, as is the length of the `service 1 data', and the original 383 TSpec parameters are followed by a new parameter, the compressibility 384 hint. This parameter contains the standard parameter header, and an 385 assigned number indicating the type of compression that is possible 386 on this data. Different values of the hint would imply different 387 compression algorithms may be applied to the data. Details of the 388 numbering scheme for hints appear below. 390 Following the hint value is the compression factor f, expressed as a 391 32 bit integer representing the factor as a percentage value. The 392 valid range for this factor is (0,100]. A sender that does not know 393 what value to use here or wishes to leave the compression factor 394 calculation to the routers' discretion may use the reserved value 0 395 to indicate this fact. Zero is reserved because it is not possible to 396 compress a data stream to zero bits per second. The value 100 397 indicates that no compression is expected on this stream. 399 In some cases, additional quantitative information about the traffic 400 may be required to enable a router to determine the amount of 401 compression possible. In this case, a different encoding of the 402 parameter would be required. 404 In some cases it may be desirable to include more than one hint in a 405 Tspec (e.g. because more than one compression scheme could be applied 406 to the data.) In this case, multiple instances of parameter 126 may 407 appear in the Tspec and the overall length of the Tspec and the 408 length of the Service 1 data would be increased accordingly. 410 Note that the Compression_Hint is, like the Token_Bucket_Tspec, not 411 specific to a single service, and thus has a parameter value less 412 than 128. It is also included as part of the default/global 413 information (service number 1). 415 4.1. Hint Numbering 417 Hints are represented by a 32 bit field, with the high order 16 bits 418 being the IP-compression-protocol number as defined in [RFC 1332] and 419 [RFC 2509]. The low order 16 bits are a sub-option for the cases 420 where the IP-compression-protocol number alone is not sufficient for 421 int-serv purposes. The following hint values are required at the time 422 of writing: 424 - hint = 0x002d0000: IP/TCP data that may be compressed according 425 to [RFC 1144] 427 - hint = 0x00610000: IP data that may be compressed according to 428 [RFC 2507] 430 - hint = 0x00610100: IP/UDP/RTP data that may be compressed 431 according to [RFC 2508] 433 5. Backward Compatibility 435 It is desirable that an intserv router which receives this new TSpec 436 format and does not understand the compressibility hint should 437 silently ignore the hint rather than rejecting the entire TSpec (or 438 the message containing it) as malformed. While [RFC 2210] clearly 439 specifies the format of TSpecs in a way that they can be parsed even 440 when they contain unknown parameters, it does not specify what action 441 should be taken when unknown objects are received. Thus it is quite 442 possible that some RSVP implementations will discard PATH messages 443 containing a TSpec with the compressibility hint. In such a case, the 444 router should send a PathErr message to the sending host. The message 445 should indicate a malformed TSpec (Error code 21, Sub-code 04). The 446 host may conclude that the hint caused the problem and send a new 447 PATH without the hint. 449 For the purposes of this specification, it would be preferable if 450 unknown TSpec parameters could be silently ignored. In the case where 451 a parameter is silently ignored, the node should behave as if that 452 parameter were not present, but leave the unknown parameter intact in 453 the object that it forwards. This should be the default for unknown 454 parameters of the type described in [RFC 2210]. 456 It is possible that some future modifications to [RFC 2210] will 457 require unknown parameter types to cause an error response. This 458 situation is analogous to RSVP's handling of unknown objects, which 459 allows for three different response to an unknown object, based on 460 the highest two bits of the Class-Num. One way to handle this would 461 be to divide the parameter space further than already done in [RFC 462 2216]. For example, parameter numbers of the form x1xxxxxx could be 463 silently ignored if unrecognized, while parameter numbers of the form 464 x0xxxxxx could cause an error response if unrecognized. (The meaning 465 of the highest order bit is already fixed by [RFC 2216].) A third 466 possibility exists, which is to remove the unrecognized parameter 467 before forwarding, but this does not seem to be useful. 469 6. Security Considerations 471 The extensions defined in this document pose essentially the same 472 security risks as those of [RFC 2210]. The risk that a sender will 473 falsely declare his data to be compressible is equivalent to the 474 sender providing an insufficiently large TSpec and is dealt with in 475 the same way. 477 7. IANA Considerations 479 This specification relies on IANA-assigned numbers for the 480 compression scheme hint. Where possible the existing numbering scheme 481 for compression algorithm identification in PPP has been used, but it 482 may in the future be necessary for IANA to assign hint numbers purely 483 for the purposes of int-serv. 485 8. Acknowledgments 487 Carsten Borman and Mike DiBiasio provided much helpful feedback on 488 this document. 490 9. References 492 [RFC1144] Jacobson, V. Compressing TCP/IP Headers for Low-Speed 493 Serial Links, RFC 1144, February 1990. 495 [RFC 1332] McGregor, G. The PPP Internet Protocol Control Protocol 496 (IPCP). RFC 1332, May 1992. 498 [RFC 2205] Braden, R. et al. Resource ReSerVation Protocol (RSVP) -- 499 Version 1 Functional Specification, RFC 2205, Sep. 1997. 501 [RFC 2210] Wroclawski, J. The Use of RSVP with IETF Integrated 502 Services, RFC 2210, Sep. 1997. 504 [RFC 2211] Wroclawski, J. Specification of the Controlled-Load 505 Network Element Service, RFC 2211, Sep. 1997. 507 [RFC 2212] Shenker, S., Partridge, C., and Guerin, R. Specification 508 of Guaranteed Quality of Service, RFC 2212, Sep. 1997. 510 [RFC 2216] Shenker, S., and Wroclawski, J. Network Element Service 511 Specification Template, RFC 2216, Sep. 1997. 513 [RFC 2507] Degermark, M., Nordgren, B. and S. Pink. Header 514 Compression for IP, RFC 2507, February 1999. 516 [RFC 2508] Casner, S. and V. Jacobson. Compressing IP/UDP/RTP Headers 517 for Low-Speed Serial Links, RFC 2508, February 1999. 519 [RFC 2509] Engan, M., Casner, S., and Bormann, C. IP Header 520 Compression over PPP, RFC 2509, February 1999. 522 10. Authors' Addresses 524 Bruce Davie 525 Cisco Systems, Inc. 526 250 Apollo Drive 527 Chelmsford, MA, 01824 529 E-mail: bsd@cisco.com 531 Stephen L. Casner 532 Cisco Systems, Inc. 533 170 Tasman Drive 534 San Jose, CA, 95134 536 E-mail: casner@cisco.com 538 Carol Iturralde 539 Cisco Systems, Inc. 540 250 Apollo Drive 541 Chelmsford, MA, 01824 543 E-mail: cei@cisco.com 545 Dave Oran 546 Cisco Systems, Inc. 547 170 Tasman Drive 548 San Jose, CA, 95134 550 E-mail: oran@cisco.com 552 John Wroclawski 553 MIT Laboratory for Computer Science 554 545 Technology Sq. 555 Cambridge, MA 02139 557 E-mail: jtw@lcs.mit.edu 559 Copyright (C) The Internet Society (1999). All Rights Reserved. 561 This document and translations of it may be copied and furnished to 562 others, and derivative works that comment on or otherwise explain it 563 or assist in its implmentation may be prepared, copied, published and 564 distributed, in whole or in part, without restriction of any kind, 565 provided that the above copyright notice and this paragraph are 566 included on all such copies and derivative works. However, this 567 document itself may not be modified in any way, such as by removing 568 the copyright notice or references to the Internet Society or other 569 Internet organizations, except as needed for the purpose of 570 developing Internet standards in which case the procedures for 571 copyrights defined in the Internet Standards process must be 572 followed, or as required to translate it into languages other than 573 English. 575 The limited permissions granted above are perpetual and will not be 576 revoked by the Internet Society or its successors or assigns. 578 This document and the information contained herein is provided on an 579 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 580 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 581 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 582 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 583 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."