rfc3006.txt

RFC 的详细文档！

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