Integrated Services in the Presence of Compressible Flows
RFC 3006

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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