RFC 3006 (rfc3006) - Page 2 of 13

Integrated Services in the Presence of Compressible Flows

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