doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc3006.txt b/doc/rfc/rfc3006.txt
new file mode 100644
index 0000000..5aa5cb6
--- /dev/null
+++ b/doc/rfc/rfc3006.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                          B. Davie
+Request for Comments: 3006                                 C. Iturralde
+Category: Standards Track                                       D. Oran
+                                                    Cisco Systems, Inc.
+                                                              S. Casner
+                                                          Packet Design
+                                                          J. Wroclawski
+                                                                MIT LCS
+                                                          November 2000
+
+
+       Integrated Services in the Presence of Compressible Flows
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   An Integrated Services (int-serv) router performs admission control
+   and resource allocation based on the information contained in a TSpec
+   (among other things).  As currently defined, TSpecs convey
+   information about the data rate (using a token bucket) and range of
+   packet sizes of the flow in question.  However, the TSpec may not be
+   an accurate representation of the resources needed to support the
+   reservation if the router is able to compress the data at the link
+   level.  This specification describes an extension to the TSpec which
+   enables a sender of potentially compressible data to provide hints to
+   int-serv routers about the compressibility they may obtain.  Routers
+   which support appropriate compression take advantage of the hint in
+   their admission control decisions and resource allocation procedures;
+   other routers ignore the hint.  An initial application of this
+   approach is to notify routers performing real-time transport protocol
+   (RTP) header compression that they may allocate fewer resources to
+   RTP flows.
+
+
+
+
+
+
+
+
+Davie, et al.               Standards Track                     [Page 1]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+Table of Contents
+
+   1      Introduction  ...........................................  2
+   2      Addition of a Hint to the Sender TSpec  .................  3
+   3      Admission Control and Resource Allocation  ..............  4
+   4      Object Format  ..........................................  8
+   4.1    Hint Numbering  .........................................  9
+   5      Backward Compatibility  ................................. 10
+   6      Security Considerations  ................................ 10
+   7      IANA Considerations  .................................... 11
+   8      Acknowledgments  ........................................ 11
+   9      References  ............................................. 11
+   10     Authors' Addresses  ..................................... 12
+   11     Full Copyright Statement ................................ 13
+
+1. Introduction
+
+   In an Integrated Services network, RSVP [RFC 2205] may be used as a
+   signalling protocol by which end nodes and network elements exchange
+   information about resource requirements, resource availability, and
+   the establishment and removal of resource reservations.  The
+   Integrated Services architecture currently defines two services,
+   Controlled-Load [RFC 2211] and Guaranteed [RFC 2212].  When
+   establishing a reservation using either service, RSVP requires a
+   variety of information to be provided by the sender(s) and
+   receiver(s) for a particular reservation which is used for the
+   purposes of admission control and allocation of resources to the
+   reservation.  Some of this information is provided by the receiver in
+   a FLOWSPEC object; some is provided by the sender in a SENDER_TSPEC
+   object [RFC 2210].
+
+   A situation that is not handled well by the current specs arises when
+   a router that is making an admission control decision is able to
+   perform some sort of compression on the flow for which a reservation
+   is requested.  For example, suppose a router is able to perform
+   IP/UDP/RTP header compression on one of its interfaces [RFC 2508].
+   The bandwidth needed to accommodate a compressible flow on that
+   interface would be less than the amount contained in the
+   SENDER_TSPEC.  Thus the router might erroneously reject a reservation
+   that could in fact have been accommodated.  At the same time, the
+   sender is not at liberty to reduce its TSpec to account for the
+   compression of the data, since it does not know if the routers along
+   the path are in fact able to perform compression.  Furthermore, it is
+   probable that only a subset of the routers on the path (e.g., those
+   connected to low-speed serial links) will perform compression.
+
+
+
+
+
+
+Davie, et al.               Standards Track                     [Page 2]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+   This specification describes a mechanism by which the sender can
+   provide a hint to network elements regarding the compressibility of
+   the data stream that it will generate.  Network elements may use this
+   hint as an additional piece of data when making admission control and
+   resource allocation decisions.
+
+   This specification is restricted to the case where compression is
+   performed only on a link-by-link basis, as with header compression.
+   Other cases (e.g., transcoding, audio silence detection) which would
+   affect the bandwidth consumed at all downstream nodes are for further
+   study.  In these latter cases, it would be necessary to modify a
+   sender TSpec as it is passed through a compressing node.  In the
+   approach presented here, the sender TSpec that appears on the wire is
+   never modified, just as specified in [RFC 2210].
+
+2. Addition of a Hint to the Sender TSpec
+
+   The appropriate place for a `compressibility hint' is the Sender
+   TSpec.  The reasons for this choice are:
+
+      -  The sender is the party who knows best what the data will look
+         like.
+
+      -  Unlike the Adspec, the Sender TSpec is not modified in transit
+
+      -  From the perspective of RSVP, the Sender TSpec is  a set of
+         opaque parameters that are passed to `traffic control'
+         (admission control and resource allocation); the
+         compressibility hint is just such a parameter.
+
+   An alternative to putting this information in the TSpec would be to
+   use an additional object in the RSVP PATH message.  While this could
+   be made to work for RSVP, it does not address the issue of how to get
+   the same information to an intserv router when mechanisms other than
+   RSVP are used to reserve resources.  It would also imply a change to
+   RSVP message processing just for the purposes of getting more
+   information to entities that are logically not part of RSVP
+   (admission control and resource allocation). The inclusion of the
+   information in the TSpec seems preferable and more consistent with
+   the Integrated Services architecture.
+
+   The contents of the hint are likely to vary depending on the exact
+   scenario.  The hint needs to tell the routers that receive it:
+
+      -  the type of compression that is possible on this flow (e.g.
+         IP/UDP/RTP);
+
+
+
+
+
+Davie, et al.               Standards Track                     [Page 3]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+      -  enough information to enable a router to determine the likely
+         compression ratio that may be achieved.
+
+   In a simple case such as IP/UDP/RTP header compression, it may be
+   sufficient to tell the routers nothing more than the fact that
+   IP/UDP/RTP data is being sent. Knowing this fact, the maximum packet
+   size of the flow (from the TSpec), and the local conditions at the
+   router, may be sufficient to allow the router to determine the
+   reduction in bandwidth that compression will allow.  In other cases,
+   it may be helpful or necessary for the sender to include additional
+   quantitative information to assist in the calculation of the
+   compression ratio.  To handle these cases, additional parameters
+   containing various amounts of information may be added to the sender
+   TSpec.  Details of the encoding of these parameters, following the
+   approach originally described in [RFC 2210] are described below.
+
+3. Admission Control and Resource Allocation
+
+   Integrated Services routers make admission control and resource
+   allocation decisions based on, among other things, information in the
+   sender TSpec.  If a router receives a sender TSpec which contains a
+   compressibility hint, it may use the hint to calculate a `compressed
+   TSpec' which can be used as input to the admission control and
+   resource allocation processes in place of the TSpec provided by the
+   sender.  To make this concrete, consider the following simple
+   example.  A router receives a reservation request for controlled load
+   service where:
+
+      -  The Sender TSpec and Receiver TSpec contain identical token
+         bucket parameters;
+
+      -  The rate parameter in the token bucket (r) is 48 kbps;
+
+      -  The token bucket depth (b) is 120 bytes;
+
+      -  The maximum packet size (M) in the TSpecs is 120 bytes;
+
+      -  The minimum policed unit (m) is 64 bytes;
+
+      -  The Sender TSpec contains a compressibility hint indicating
+         that the data is IP/UDP/RTP;
+
+      -  The compressibility hint includes a compression factor of 70%,
+         meaning that IP/UDP/RTP header compression will cause a
+         reduction in bandwidth consumed at the link level by a factor
+         of 0.7 (the result of compressing 40 bytes of IP/UDP/RTP header
+         to 4 bytes on a 120 byte packet)
+
+
+
+
+Davie, et al.               Standards Track                     [Page 4]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+      -  The interface on which the reservation is to be installed is
+         able to perform IP/UDP/RTP header compression.
+
+   The router may thus conclude that it can scale down the token bucket
+   parameters r and b by a factor of 0.7, i.e., to 33.6 kbps and 84
+   bytes respectively.  M may be scaled down by the same factor (to 84
+   bytes), but a different calculation should be used for m.  If the
+   sender actually sends a packet of size m, its header may be
+   compressed from 40 bytes to 4, thus reducing the packet to 28 bytes;
+   this value should be used for m.
+
+   Note that if the source always sends packets of the same size and
+   IP/UDP/RTP always works perfectly, the compression factor is not
+   strictly needed.  The router can independently determine that it can
+   compress the 40 bytes of IP/UDP/RTP header to 4 bytes (with high
+   probability).  To determine the worst-case (smallest) gain provided
+   by compression, it can assume that the sender always sends maximum
+   sized packets at 48 kbps, i.e., a 120 byte packet every 20
+   milliseconds.  The router can conclude that these packets would be
+   compressed to 84 bytes, yielding a token bucket rate of 33.6 kbps and
+   a token bucket depth of 84 bytes as before.  If the sender is willing
+   to allow an independent calculation of compression gain by the
+   router, the explicit compression factor may be omitted from the
+   TSpec.  Details of the TSpec encoding are provided below.
+
+   To generalize the above discussion, assume that the Sender TSpec
+   consists of values (r, b, p, M, m), that the explicit compression
+   factor provided by the sender is f percent, and that the number of
+   bytes saved by compression is N, independent of packet size.  The
+   parameters in the compressed TSpec would be:
+
+     r' = r * f/100
+     b' = b * f/100
+     p' = p
+     M' = M-N
+     m' = m-N
+
+   The calculations for r' and b' reflect that fact that f is expressed
+   as a percentage and must therefore be divided by 100.  The
+   calculations for M' and m' hold only in the case where the
+   compression algorithm reduces packets by a certain number of bytes
+   independent of content or length of the packet, as is true for header
+   compression.  Other compression algorithms may not have this
+   property.  In determining the value of N, the router may need to make
+   worst case assumptions about the number of bytes that may be removed
+   by compression, which depends on such factors as the presence of UDP
+   checksums and the linearity of RTP timestamps.
+
+
+
+
+Davie, et al.               Standards Track                     [Page 5]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+   All these adjusted values are used in the compressed TSpec.  The
+   router's admission control and resource allocation algorithms should
+   behave as if the sender TSpec contained those values.  [RFC 2205]
+   provides a set of rules by which sender and receiver TSpecs are
+   combined to calculate a single `effective' TSpec that is passed to
+   admission control.  When a reservation covering multiple senders is
+   to be installed, it is necessary to reduce each sender TSpec by its
+   appropriate compression factor. The set of sender TSpecs that apply
+   to a single reservation on an interface are added together to form
+   the effective sender TSpec, which is passed to traffic control.  The
+   effective receiver TSpec need not be modified; traffic control takes
+   the greatest lower bound of these two TSpecs when making its
+   admission control and resource allocation decisions.
+
+   The handling of the receiver RSpec depends on whether controlled load
+   or guaranteed service is used.  In the case of controlled load, no
+   additional processing of RSpec is needed.  However, a guaranteed
+   service RSpec contains a rate term R which does need to be adjusted
+   downwards to account for compression.  To determine how R should be
+   adjusted, we note that the receiver has chosen R to meet a certain
+   delay goal, and that the terms in the delay equation that depend on R
+   are b/R and C/R (when the peak rate is large).  The burstsize b in
+   this case is the sum of the burstsizes of all the senders for this
+   reservation, and each of these numbers has been scaled down by the
+   appropriate compression factor.  Thus, R should be scaled down using
+   an average compression factor
+
+      f_avg = (b1*f1 + b2*f2 + ... + bn*fn)/(b1 + b2 + ... bn)
+
+   where bk is the burstsize of sender k and fk is the corresponding
+   compression factor for this sender.  Note that f_avg, like the
+   individual fi's, is a percentage.  Note also that this results in a
+   compression factor of f in the case where all senders use the same
+   compression factor f.
+
+   To prevent an increase in delay caused by the C/R term when the
+   reduced value of R is used for the reservation, it is necessary for
+   this hop to `inflate' its value of C by dividing it by (f_avg/100).
+   This will cause the contribution to delay made by this hop's C term
+   to be what the receiver would expect when it chooses its value of R.
+
+   There are certain risks in adjusting the resource requirements
+   downwards for the purposes of admission control and resource
+   allocation.  Most compression algorithms are not completely
+   deterministic, and thus there is a risk that a flow will turn out to
+   be less compressible than had been assumed by admission control.
+   This risk is reduced by the use of the explicit compression factor
+   provided by the sender, and may be minimized if the router makes
+
+
+
+Davie, et al.               Standards Track                     [Page 6]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+   worst case assumptions about the amount of compression that may be
+   achieved.  This is somewhat analogous to the tradeoff between making
+   worst case assumptions when performing admission control or making
+   more optimistic assumptions, as in the case of measurement-based
+   admission control.  If a flow turns out to be less compressible that
+   had been assumed when performing admission control, any extra traffic
+   will need to be policed according to normal intserv rules.  For
+   example, if the router assumed that the 48 kbps stream above could be
+   compressed to 33.6 kbps and it was ultimately possible to compress it
+   to 35 kbps, the extra 1.4 kbps would be treated as excess.  The exact
+   treatment of such excess is service dependent.
+
+   A similar scenario may arise if  a sender claims that data for a
+   certain session is compressible when in fact it is not, or overstates
+   the extent of its compressibility.  This might cause the flow to be
+   erroneously admitted, and would cause insufficient resources to be
+   allocated to it.  To prevent such behavior from adversely affecting
+   other reserved flows, any flow that sends a compressibility hint
+   should be policed (in any router that has made use of the hint for
+   its admission control) on the assumption that it is indeed
+   compressible, i.e., using the compressed TSpec.  That is, if the flow
+   is found to be less compressible than advertised, the extra traffic
+   that must be forwarded  by the router above the compressed TSpec will
+   be policed according to intserv rules appropriate for the service.
+   Note that services that use the maximum datagram size M for policing
+   purposes (e.g. guaranteed service [RFC 2210]) should continue to use
+   the uncompressed value of M to allow for the possibility that some
+   packets may not be successfully compressed.
+
+   Note that RSVP does not generally require flows to be policed at
+   every hop.  To quote [RFC 2205]:
+
+      Some QoS services may require traffic policing at some or all of
+      (1) the edge of the network, (2) a merging point for data from
+      multiple senders, and/or (3) a branch point where traffic flow
+      from upstream may be greater than the downstream reservation being
+      requested.  RSVP knows where such points occur and must so
+      indicate to the traffic control mechanism.
+
+   For the purposes of policing, a router which makes use of the
+   compressibility hint in a sender TSpec should behave as if it is at
+   the edge of the network, because it is in a position to receive
+   traffic from a sender that, while it passed through policing at the
+   real network edge, may still need to be policed if the amount of data
+   sent exceeds the amount described by the compressed TSpec.
+
+
+
+
+
+
+Davie, et al.               Standards Track                     [Page 7]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+4. Object Format
+
+   The compressibility hint may be included in the sender TSpec using
+   the encoding rules of Appendix A in [RFC 2210].  The complete sender
+   TSpec is as follows:
+
+        31           24 23           16 15            8 7             0
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   1   | 0 (a) |    reserved           |            10 (b)             |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   2   |    1  (c)     |0| reserved    |             9 (d)             |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   3   |   127 (e)     |    0 (f)      |             5 (g)             |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   4   |  Token Bucket Rate [r] (32-bit IEEE floating point number)    |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   5   |  Token Bucket Size [b] (32-bit IEEE floating point number)    |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   6   |  Peak Data Rate [p] (32-bit IEEE floating point number)       |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   7   |  Minimum Policed Unit [m] (32-bit integer)                    |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   8   |  Maximum Packet Size [M]  (32-bit integer)                    |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   9   |   126 (h)     |    0 (i)      |             2 (j)             |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   10  |     Hint (assigned number)                                    |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   11  |  Compression factor [f] (32-bit integer)                      |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        (a) - Message format version number (0)
+        (b) - Overall length (10 words not including header)
+        (c) - Service header, service number 1 (default/global
+              information)
+        (d) - Length of service 1 data, 9 words not including header
+        (e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
+        (f) - Parameter 127 flags (none set)
+        (g) - Parameter 127 length, 5 words not including header
+        (h) - Parameter ID, parameter 126 (Compression_Hint)
+        (i) - Parameter 126 flags (none set)
+        (j) - Parameter 126 length, 2 words not including header
+
+   The difference between this TSpec and the one described in [RFC 2210]
+   is that the overall length contained in the first word is increased
+   by 3, as is the length of the `service 1 data', and the original
+   TSpec parameters are followed by a new parameter, the compressibility
+   hint.  This parameter contains the standard parameter header, and an
+
+
+
+Davie, et al.               Standards Track                     [Page 8]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+   assigned number indicating the type of compression that is possible
+   on this data.  Different values of the hint would imply different
+   compression algorithms may be applied to the data.  Details of the
+   numbering scheme for hints appear below.
+
+   Following the hint value is the compression factor f, expressed as a
+   32 bit integer representing the factor as a percentage value.  The
+   valid range for this factor is (0,100].  A sender that does not know
+   what value to use here or wishes to leave the compression factor
+   calculation to the routers' discretion may use the reserved value 0
+   to indicate this fact.  Zero is reserved because it is not possible
+   to compress a data stream to zero bits per second.  The value 100
+   indicates that no compression is expected on this stream.
+
+   In some cases, additional quantitative information about the traffic
+   may be required to enable a router to determine the amount of
+   compression possible.  In this case, a different encoding of the
+   parameter would be required.
+
+   In some cases it may be desirable to include more than one hint in a
+   Tspec (e.g., because more than one compression scheme could be
+   applied to the data.)  In this case, multiple instances of parameter
+   126 may appear in the Tspec and the overall length of the Tspec and
+   the length of the Service 1 data would be increased accordingly.
+
+   Note that the Compression_Hint is, like the Token_Bucket_Tspec, not
+   specific to a single service, and thus has a parameter value less
+   than 128.  It is also included as part of the default/global
+   information (service number 1).
+
+4.1. Hint Numbering
+
+   Hints are represented by a 32 bit field, with the high order 16 bits
+   being the IP-compression-protocol number as defined in [RFC 1332] and
+   [RFC 2509].  The low order 16 bits are a sub-option for the cases
+   where the IP-compression-protocol number alone is not sufficient for
+   int-serv purposes.  The following hint values are required at the
+   time of writing:
+
+      -  hint = 0x002d0000: IP/TCP data that may be compressed according
+         to [RFC 1144]
+
+      -  hint = 0x00610000: IP data that may be compressed according to
+         [RFC 2507]
+
+      -  hint = 0x00610100:  IP/UDP/RTP data that may be compressed
+         according to [RFC 2508]
+
+
+
+
+Davie, et al.               Standards Track                     [Page 9]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+5. Backward Compatibility
+
+   It is desirable that an intserv router which receives this new TSpec
+   format and does not understand the compressibility hint should
+   silently ignore the hint rather than rejecting the entire TSpec (or
+   the message containing it) as malformed.  While [RFC 2210] clearly
+   specifies the format of TSpecs in a way that they can be parsed even
+   when they contain unknown parameters, it does not specify what action
+   should be taken when unknown objects are received.  Thus it is quite
+   possible that some RSVP implementations will discard PATH messages
+   containing a TSpec with the compressibility hint.  In such a case,
+   the router should send a PathErr message to the sending host.  The
+   message should indicate a malformed TSpec (Error code 21, Sub-code
+   04).  The host may conclude that the hint caused the problem and send
+   a new PATH without the hint.
+
+   For the purposes of this specification, it would be preferable if
+   unknown TSpec parameters could be silently ignored.  In the case
+   where a parameter is silently ignored, the node should behave as if
+   that parameter were not present, but leave the unknown parameter
+   intact in the object that it forwards.  This should be the default
+   for unknown parameters of the type described in [RFC 2210].
+
+   It is possible that some future modifications to [RFC 2210] will
+   require unknown parameter types to cause an error response.  This
+   situation is analogous to RSVP's handling of unknown objects, which
+   allows for three different response to an unknown object, based on
+   the highest two bits of the Class-Num.  One way to handle this would
+   be to divide the parameter space further than already done in [RFC
+   2216].  For example, parameter numbers of the form x1xxxxxx could be
+   silently ignored if unrecognized, while parameter numbers of the form
+   x0xxxxxx could cause an error response if unrecognized.  (The meaning
+   of the highest order bit is already fixed by [RFC 2216].)  A third
+   possibility exists, which is to remove the unrecognized parameter
+   before forwarding, but this does not seem to be useful.
+
+6. Security Considerations
+
+   The extensions defined in this document pose essentially the same
+   security risks as those of [RFC 2210].  The risk that a sender will
+   falsely declare his data to be compressible is equivalent to the
+   sender providing an insufficiently large TSpec and is dealt with in
+   the same way.
+
+
+
+
+
+
+
+
+Davie, et al.               Standards Track                    [Page 10]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+7. IANA Considerations
+
+   This specification relies on IANA-assigned numbers for the
+   compression scheme hint.  Where possible the existing numbering
+   scheme for compression algorithm identification in PPP has been used,
+   but it may in the future be necessary for IANA to assign hint numbers
+   purely for the purposes of int-serv.
+
+8. Acknowledgments
+
+   Carsten Borman and Mike DiBiasio provided much helpful feedback on
+   this document.
+
+9. References
+
+   [RFC 1144]  Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
+               Serial Links", RFC 1144, February 1990.
+
+   [RFC 1332]  McGregor, G., "The PPP Internet Protocol Control Protocol
+               (IPCP)", RFC 1332, May 1992.
+
+   [RFC 2205]  Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
+               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
+               Functional Specification", RFC 2205, September 1997.
+
+   [RFC 2210]  Wroclawski, J., "The Use of RSVP with IETF Integrated
+               Services", RFC 2210, September 1997.
+
+   [RFC 2211]  Wroclawski, J., "Specification of the Controlled-Load
+               Network Element Service", RFC 2211, September 1997.
+
+   [RFC 2212]  Shenker, S., Partridge, C. and R. Guerin, "Specification
+               of Guaranteed Quality of Service", RFC 2212, September
+               1997.
+
+   [RFC 2216]  Shenker, S. and J. Wroclawski, "Network Element Service
+               Specification Template", RFC 2216, September 1997.
+
+   [RFC 2507]  Degermark, M., Nordgren, B. and S. Pink,"Header
+               Compression for IP", RFC 2507, February 1999.
+
+   [RFC 2508]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
+               Headers for Low-Speed Serial Links", RFC 2508, February
+               1999.
+
+   [RFC 2509]  Engan, M., Casner, S. and C. Bormann, "IP Header
+               Compression over PPP", RFC 2509, February 1999.
+
+
+
+
+Davie, et al.               Standards Track                    [Page 11]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+10. Authors' Addresses
+
+   Bruce Davie
+   Cisco Systems, Inc.
+   250 Apollo Drive
+   Chelmsford, MA, 01824
+
+   EMail: bsd@cisco.com
+
+
+   Carol Iturralde
+   Cisco Systems, Inc.
+   250 Apollo Drive
+   Chelmsford, MA, 01824
+
+   EMail: cei@cisco.com
+
+
+   Dave Oran
+   Cisco Systems, Inc.
+   170 Tasman Drive
+   San Jose, CA, 95134
+
+   EMail: oran@cisco.com
+
+
+   Stephen L. Casner
+   Packet Design
+   66 Willow Place
+   Menlo Park, CA 94025
+
+   EMail: casner@acm.org
+
+
+   John Wroclawski
+   MIT Laboratory for Computer Science
+   545 Technology Sq.
+   Cambridge, MA  02139
+
+   EMail: jtw@lcs.mit.edu
+
+
+
+
+
+
+
+
+
+
+
+Davie, et al.               Standards Track                    [Page 12]
+
+RFC 3006       Integrated Services in Compressible Flows   November 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davie, et al.               Standards Track                    [Page 13]
+