As per Relevance of the word resource, we have this rfc below:
Network Working Group B.
Request for Comments: 3006 C.
Category: Standards Track D.
Cisco Systems, Inc
S.
Packet
J.
MIT
November 2000
Integrated Services in the Presence of Compressible
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
An Integrated Services (int-serv) router performs admission
and resource allocation based on the information contained in a
(among other things). As currently defined, TSpecs
information about the data rate (using a token bucket) and range
packet sizes of the flow in question. However, the TSpec may not
an accurate representation of the resources needed to support
reservation if the router is able to compress the data at the
level. This specification describes an extension to the TSpec
enables a sender of potentially compressible data to provide hints
int-serv routers about the compressibility they may obtain.
which support appropriate compression take advantage of the hint
their admission control decisions and resource allocation procedures
other routers ignore the hint. An initial application of
approach is to notify routers performing real-time transport
(RTP) header compression that they may allocate fewer resources
RTP flows
Davie, et al. Standards Track [Page 1]
RFC 3006 Integrated Services in Compressible Flows November 2000
Table of
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.
In an Integrated Services network, RSVP [RFC 2205] may be used as
signalling protocol by which end nodes and network elements
information about resource requirements, resource availability,
the establishment and removal of resource reservations.
Integrated Services architecture currently defines two services
Controlled-Load [RFC 2211] and Guaranteed [RFC 2212].
establishing a reservation using either service, RSVP requires
variety of information to be provided by the sender(s)
receiver(s) for a particular reservation which is used for
purposes of admission control and allocation of resources to
reservation. Some of this information is provided by the receiver
a FLOWSPEC object; some is provided by the sender in a SENDER_
object [RFC 2210].
A situation that is not handled well by the current specs arises
a router that is making an admission control decision is able
perform some sort of compression on the flow for which a
is requested. For example, suppose a router is able to
IP/UDP/RTP header compression on one of its interfaces [RFC 2508].
The bandwidth needed to accommodate a compressible flow on
interface would be less than the amount contained in
SENDER_TSPEC. Thus the router might erroneously reject a
that could in fact have been accommodated. At the same time,
sender is not at liberty to reduce its TSpec to account for
compression of the data, since it does not know if the routers
the path are in fact able to perform compression. Furthermore, it
probable that only a subset of the routers on the path (e.g.,
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
provide a hint to network elements regarding the compressibility
the data stream that it will generate. Network elements may use
hint as an additional piece of data when making admission control
resource allocation decisions
This specification is restricted to the case where compression
performed only on a link-by-link basis, as with header compression
Other cases (e.g., transcoding, audio silence detection) which
affect the bandwidth consumed at all downstream nodes are for
study. In these latter cases, it would be necessary to modify
sender TSpec as it is passed through a compressing node. In
approach presented here, the sender TSpec that appears on the wire
never modified, just as specified in [RFC 2210].
2. Addition of a Hint to the Sender
The appropriate place for a `compressibility hint' is the
TSpec. The reasons for this choice are
- The sender is the party who knows best what the data will
like
- Unlike the Adspec, the Sender TSpec is not modified in
- From the perspective of RSVP, the Sender TSpec is a set
opaque parameters that are passed to `traffic control
(admission control and resource allocation);
compressibility hint is just such a parameter
An alternative to putting this information in the TSpec would be
use an additional object in the RSVP PATH message. While this
be made to work for RSVP, it does not address the issue of how to
the same information to an intserv router when mechanisms other
RSVP are used to reserve resources. It would also imply a change
RSVP message processing just for the purposes of getting
information to entities that are logically not part of
(admission control and resource allocation). The inclusion of
information in the TSpec seems preferable and more consistent
the Integrated Services architecture
The contents of the hint are likely to vary depending on the
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
compression ratio that may be achieved
In a simple case such as IP/UDP/RTP header compression, it may
sufficient to tell the routers nothing more than the fact
IP/UDP/RTP data is being sent. Knowing this fact, the maximum
size of the flow (from the TSpec), and the local conditions at
router, may be sufficient to allow the router to determine
reduction in bandwidth that compression will allow. In other cases
it may be helpful or necessary for the sender to include
quantitative information to assist in the calculation of
compression ratio. To handle these cases, additional
containing various amounts of information may be added to the
TSpec. Details of the encoding of these parameters, following
approach originally described in [RFC 2210] are described below
3. Admission Control and Resource
Integrated Services routers make admission control and
allocation decisions based on, among other things, information in
sender TSpec. If a router receives a sender TSpec which contains
compressibility hint, it may use the hint to calculate a `
TSpec' which can be used as input to the admission control
resource allocation processes in place of the TSpec provided by
sender. To make this concrete, consider the following
example. A router receives a reservation request for controlled
service where
- The Sender TSpec and Receiver TSpec contain identical
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
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
reduction in bandwidth consumed at the link level by a
of 0.7 (the result of compressing 40 bytes of IP/UDP/RTP
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
able to perform IP/UDP/RTP header compression
The router may thus conclude that it can scale down the token
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
sender actually sends a packet of size m, its header may
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
IP/UDP/RTP always works perfectly, the compression factor is
strictly needed. The router can independently determine that it
compress the 40 bytes of IP/UDP/RTP header to 4 bytes (with
probability). To determine the worst-case (smallest) gain
by compression, it can assume that the sender always sends
sized packets at 48 kbps, i.e., a 120 byte packet every 20
milliseconds. The router can conclude that these packets would
compressed to 84 bytes, yielding a token bucket rate of 33.6 kbps
a token bucket depth of 84 bytes as before. If the sender is
to allow an independent calculation of compression gain by
router, the explicit compression factor may be omitted from
TSpec. Details of the TSpec encoding are provided below
To generalize the above discussion, assume that the Sender
consists of values (r, b, p, M, m), that the explicit
factor provided by the sender is f percent, and that the number
bytes saved by compression is N, independent of packet size.
parameters in the compressed TSpec would be
r' = r * f/100
b' = b * f/100
p' =
M' = M-
m' = m-
The calculations for r' and b' reflect that fact that f is
as a percentage and must therefore be divided by 100.
calculations for M' and m' hold only in the case where
compression algorithm reduces packets by a certain number of
independent of content or length of the packet, as is true for
compression. Other compression algorithms may not have
property. In determining the value of N, the router may need to
worst case assumptions about the number of bytes that may be
by compression, which depends on such factors as the presence of
checksums and the linearity of RTP timestamps
Davie, et al. Standards Track [Page 5]
RFC 3006 Integrated Services in Compressible Flows November 2000
All these adjusted values are used in the compressed TSpec.
router's admission control and resource allocation algorithms
behave as if the sender TSpec contained those values. [RFC 2205]
provides a set of rules by which sender and receiver TSpecs
combined to calculate a single `effective' TSpec that is passed
admission control. When a reservation covering multiple senders
to be installed, it is necessary to reduce each sender TSpec by
appropriate compression factor. The set of sender TSpecs that
to a single reservation on an interface are added together to
the effective sender TSpec, which is passed to traffic control.
effective receiver TSpec need not be modified; traffic control
the greatest lower bound of these two TSpecs when making
admission control and resource allocation decisions
The handling of the receiver RSpec depends on whether controlled
or guaranteed service is used. In the case of controlled load,
additional processing of RSpec is needed. However, a
service RSpec contains a rate term R which does need to be
downwards to account for compression. To determine how R should
adjusted, we note that the receiver has chosen R to meet a
delay goal, and that the terms in the delay equation that depend on
are b/R and C/R (when the peak rate is large). The burstsize b
this case is the sum of the burstsizes of all the senders for
reservation, and each of these numbers has been scaled down by
appropriate compression factor. Thus, R should be scaled down
an average compression
f_avg = (b1*f1 + b2*f2 + ... + bn*fn)/(b1 + b2 + ... bn
where bk is the burstsize of sender k and fk is the
compression factor for this sender. Note that f_avg, like
individual fi's, is a percentage. Note also that this results in
compression factor of f in the case where all senders use the
compression factor f
To prevent an increase in delay caused by the C/R term when
reduced value of R is used for the reservation, it is necessary
this hop to `inflate' its value of C by dividing it by (f_avg/100).
This will cause the contribution to delay made by this hop's C
to be what the receiver would expect when it chooses its value of R
There are certain risks in adjusting the resource
downwards for the purposes of admission control and
allocation. Most compression algorithms are not
deterministic, and thus there is a risk that a flow will turn out
be less compressible than had been assumed by admission control
This risk is reduced by the use of the explicit compression
provided by the sender, and may be minimized if the router
Davie, et al. Standards Track [Page 6]
RFC 3006 Integrated Services in Compressible Flows November 2000
worst case assumptions about the amount of compression that may
achieved. This is somewhat analogous to the tradeoff between
worst case assumptions when performing admission control or
more optimistic assumptions, as in the case of measurement-
admission control. If a flow turns out to be less compressible
had been assumed when performing admission control, any extra
will need to be policed according to normal intserv rules.
example, if the router assumed that the 48 kbps stream above could
compressed to 33.6 kbps and it was ultimately possible to compress
to 35 kbps, the extra 1.4 kbps would be treated as excess. The
treatment of such excess is service dependent
A similar scenario may arise if a sender claims that data for
certain session is compressible when in fact it is not, or
the extent of its compressibility. This might cause the flow to
erroneously admitted, and would cause insufficient resources to
allocated to it. To prevent such behavior from adversely
other reserved flows, any flow that sends a compressibility
should be policed (in any router that has made use of the hint
its admission control) on the assumption that it is
compressible, i.e., using the compressed TSpec. That is, if the
is found to be less compressible than advertised, the extra
that must be forwarded by the router above the compressed TSpec
be policed according to intserv rules appropriate for the service
Note that services that use the maximum datagram size M for
purposes (e.g. guaranteed service [RFC 2210]) should continue to
the uncompressed value of M to allow for the possibility that
packets may not be successfully compressed
Note that RSVP does not generally require flows to be policed
every hop. To quote [RFC 2205]:
Some QoS services may require traffic policing at some or all
(1) the edge of the network, (2) a merging point for data
multiple senders, and/or (3) a branch point where traffic
from upstream may be greater than the downstream reservation
requested. RSVP knows where such points occur and must
indicate to the traffic control mechanism
For the purposes of policing, a router which makes use of
compressibility hint in a sender TSpec should behave as if it is
the edge of the network, because it is in a position to
traffic from a sender that, while it passed through policing at
real network edge, may still need to be policed if the amount of
sent exceeds the amount described by the compressed TSpec
Davie, et al. Standards Track [Page 7]
RFC 3006 Integrated Services in Compressible Flows November 2000
4. Object
The compressibility hint may be included in the sender TSpec
the encoding rules of Appendix A in [RFC 2210]. The complete
TSpec is as follows
31 24 23 16 15 8 7 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | 0 (a) | reserved | 10 (b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 | 1 (c) |0| reserved | 9 (d) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 | 127 (e) | 0 (f) | 5 (g) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4 | Token Bucket Rate [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 | Token Bucket Size [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6 | Peak Data Rate [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7 | Minimum Policed Unit [m] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8 | Maximum Packet Size [M] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9 | 126 (h) | 0 (i) | 2 (j) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 | Hint (assigned number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 | Compression factor [f] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) - Message format version number (0)
(b) - Overall length (10 words not including header
(c) - Service header, service number 1 (default/
information
(d) - Length of service 1 data, 9 words not including
(e) - Parameter ID, parameter 127 (Token_Bucket_TSpec
(f) - Parameter 127 flags (none set
(g) - Parameter 127 length, 5 words not including
(h) - Parameter ID, parameter 126 (Compression_Hint
(i) - Parameter 126 flags (none set
(j) - Parameter 126 length, 2 words not including
The difference between this TSpec and the one described in [RFC 2210]
is that the overall length contained in the first word is
by 3, as is the length of the `service 1 data', and the
TSpec parameters are followed by a new parameter, the
hint. This parameter contains the standard parameter header, and
Davie, et al. Standards Track [Page 8]
RFC 3006 Integrated Services in Compressible Flows November 2000
assigned number indicating the type of compression that is
on this data. Different values of the hint would imply
compression algorithms may be applied to the data. Details of
numbering scheme for hints appear below
Following the hint value is the compression factor f, expressed as
32 bit integer representing the factor as a percentage value.
valid range for this factor is (0,100]. A sender that does not
what value to use here or wishes to leave the compression
calculation to the routers' discretion may use the reserved value 0
to indicate this fact. Zero is reserved because it is not
to compress a data stream to zero bits per second. The value 100
indicates that no compression is expected on this stream
In some cases, additional quantitative information about the
may be required to enable a router to determine the amount
compression possible. In this case, a different encoding of
parameter would be required
In some cases it may be desirable to include more than one hint in
Tspec (e.g., because more than one compression scheme could
applied to the data.) In this case, multiple instances of
126 may appear in the Tspec and the overall length of the Tspec
the length of the Service 1 data would be increased accordingly
Note that the Compression_Hint is, like the Token_Bucket_Tspec,
specific to a single service, and thus has a parameter value
than 128. It is also included as part of the default/
information (service number 1).
4.1. Hint
Hints are represented by a 32 bit field, with the high order 16
being the IP-compression-protocol number as defined in [RFC 1332]
[RFC 2509]. The low order 16 bits are a sub-option for the
where the IP-compression-protocol number alone is not sufficient
int-serv purposes. The following hint values are required at
time of writing
- hint = 0x002d0000: IP/TCP data that may be compressed
to [RFC 1144]
- hint = 0x00610000: IP data that may be compressed according
[RFC 2507]
- hint = 0x00610100: IP/UDP/RTP data that may be
according to [RFC 2508]
Davie, et al. Standards Track [Page 9]
RFC 3006 Integrated Services in Compressible Flows November 2000
5. Backward
It is desirable that an intserv router which receives this new
format and does not understand the compressibility hint
silently ignore the hint rather than rejecting the entire TSpec (
the message containing it) as malformed. While [RFC 2210]
specifies the format of TSpecs in a way that they can be parsed
when they contain unknown parameters, it does not specify what
should be taken when unknown objects are received. Thus it is
possible that some RSVP implementations will discard PATH
containing a TSpec with the compressibility hint. In such a case
the router should send a PathErr message to the sending host.
message should indicate a malformed TSpec (Error code 21, Sub-
04). The host may conclude that the hint caused the problem and
a new PATH without the hint
For the purposes of this specification, it would be preferable
unknown TSpec parameters could be silently ignored. In the
where a parameter is silently ignored, the node should behave as
that parameter were not present, but leave the unknown
intact in the object that it forwards. This should be the
for unknown parameters of the type described in [RFC 2210].
It is possible that some future modifications to [RFC 2210]
require unknown parameter types to cause an error response.
situation is analogous to RSVP's handling of unknown objects,
allows for three different response to an unknown object, based
the highest two bits of the Class-Num. One way to handle this
be to divide the parameter space further than already done in [
2216]. For example, parameter numbers of the form x1xxxxxx could
silently ignored if unrecognized, while parameter numbers of the
x0xxxxxx could cause an error response if unrecognized. (The
of the highest order bit is already fixed by [RFC 2216].) A
possibility exists, which is to remove the unrecognized
before forwarding, but this does not seem to be useful
6. Security
The extensions defined in this document pose essentially the
security risks as those of [RFC 2210]. The risk that a sender
falsely declare his data to be compressible is equivalent to
sender providing an insufficiently large TSpec and is dealt with
the same way
Davie, et al. Standards Track [Page 10]
RFC 3006 Integrated Services in Compressible Flows November 2000
7. IANA
This specification relies on IANA-assigned numbers for
compression scheme hint. Where possible the existing
scheme for compression algorithm identification in PPP has been used
but it may in the future be necessary for IANA to assign hint
purely for the purposes of int-serv
8.
Carsten Borman and Mike DiBiasio provided much helpful feedback
this document
9.
[RFC 1144] Jacobson, V., "Compressing TCP/IP Headers for Low-
Serial Links", RFC 1144, February 1990.
[RFC 1332] McGregor, G., "The PPP Internet Protocol Control
(IPCP)", RFC 1332, May 1992.
[RFC 2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC 2210] Wroclawski, J., "The Use of RSVP with IETF
Services", RFC 2210, September 1997.
[RFC 2211] Wroclawski, J., "Specification of the Controlled-
Network Element Service", RFC 2211, September 1997.
[RFC 2212] Shenker, S., Partridge, C. and R. Guerin, "
of Guaranteed Quality of Service", RFC 2212,
1997.
[RFC 2216] Shenker, S. and J. Wroclawski, "Network Element
Specification Template", RFC 2216, September 1997.
[RFC 2507] Degermark, M., Nordgren, B. and S. Pink,"
Compression for IP", RFC 2507, February 1999.
[RFC 2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/
Headers for Low-Speed Serial Links", RFC 2508,
1999.
[RFC 2509] Engan, M., Casner, S. and C. Bormann, "IP
Compression over PPP", RFC 2509, February 1999.
Davie, et al. Standards Track [Page 11]
RFC 3006 Integrated Services in Compressible Flows November 2000
10. Authors'
Bruce
Cisco Systems, Inc
250 Apollo
Chelmsford, MA, 01824
EMail: bsd@cisco.
Carol
Cisco Systems, Inc
250 Apollo
Chelmsford, MA, 01824
EMail: cei@cisco.
Dave
Cisco Systems, Inc
170 Tasman
San Jose, CA, 95134
EMail: oran@cisco.
Stephen L.
Packet
66 Willow
Menlo Park, CA 94025
EMail: casner@acm.
John
MIT Laboratory for Computer
545 Technology Sq
Cambridge, MA 02139
EMail: jtw@lcs.mit.
Davie, et al. Standards Track [Page 12]
RFC 3006 Integrated Services in Compressible Flows November 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Davie, et al. Standards Track [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
