RFC 3006 (rfc3006) - Page 2 of 13
Integrated Services in the Presence of Compressible Flows
Alternative Format: Original Text Document
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