Integrated Services in the Presence of Compressible Flows
RFC 3006
|
| Document |
Type |
|
RFC - Proposed Standard
(November 2000; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3006 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text