As per Relevance of the word guarantee, we have this rfc below:
Network Working Group S.
Request for Comments: 2212
Category: Standards Track C.
R.
September 1997
Specification of Guaranteed Quality of
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
This memo describes the network element behavior required to
a guaranteed service (guaranteed delay and bandwidth) in
Internet. Guaranteed service provides firm (mathematically provable
bounds on end-to-end datagram queueing delays. This service makes
possible to provide a service that guarantees both delay
bandwidth. This specification follows the service
template described in [1].
This document defines the requirements for network elements
support guaranteed service. This memo is one of a series
documents that specify the network element behavior required
support various qualities of service in IP internetworks.
described in these documents are useful both in the global
and private IP networks
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119.
This document is based on the service specification template given
[1]. Please refer to that document for definitions and
information about the specification of qualities of service
the IP protocol family
Shenker, et. al. Standards Track [Page 1]
RFC 2212 Guaranteed Quality of Service September 1997
In brief, the concept behind this memo is that a flow is
using a token bucket and given this description of a flow, a
element (a router, a subnet, etc) computes various
describing how the service element will handle the flow's data.
combining the parameters from the various service elements in a path
it is possible to compute the maximum delay a piece of data
experience when transmitted via that path
It is important to note three characteristics of this memo and
service it specifies
1. While the requirements a setup mechanism must follow to
a guaranteed reservation are carefully specified, neither
setup mechanism itself nor the method for identifying flows
specified. One can create a guaranteed reservation using
protocol like RSVP, manual configuration of relevant routers or
network management protocol like SNMP. This specification
intentionally independent of setup mechanism
2. To achieve a bounded delay requires that every service
in the path supports guaranteed service or adequately
guaranteed service. However this requirement does not imply
guaranteed service must be deployed throughout the Internet to
useful. Guaranteed service can have clear benefits even
partially deployed. If fully deployed in an intranet,
intranet can support guaranteed service internally. And an
can put guaranteed service in its backbone and provide
service between customers (or between POPs).
3. Because service elements produce a delay bound as a
rather than take a delay bound as an input to be achieved, it
sometimes assumed that applications cannot control the delay.
reality, guaranteed service gives applications
control over their delay
In brief, delay has two parts: a fixed delay (transmission delays
etc) and a queueing delay. The fixed delay is a property of
chosen path, which is determined not by guaranteed service but
the setup mechanism. Only queueing delay is determined
guaranteed service. And (as the equations later in this
show) the queueing delay is primarily a function of
parameters: the token bucket (in particular, the bucket size b
Shenker, et. al. Standards Track [Page 2]
RFC 2212 Guaranteed Quality of Service September 1997
and the data rate (R) the application requests. These two
are completely under the application's control. In other words
an application can usually accurately estimate, a priori,
queueing delay guaranteed service will likely promise
Furthermore, if the delay is larger than expected, the
can modify its token bucket and data rate in predictable ways
achieve a lower delay
End-to-End
The end-to-end behavior provided by a series of network elements
conform to this document is an assured level of bandwidth that,
used by a policed flow, produces a delay-bounded service with
queueing loss for all conforming datagrams (assuming no failure
network components or changes in routing during the life of
flow).
The end-to-end behavior conforms to the fluid model (described
Network Element Data Handling below) in that the delivered
delays do not exceed the fluid delays by more than the
error bounds. More precisely, the end-to-end delay bound is [(b
M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot for p>R>=r, and (M+Ctot)/R+Dtot
r<=p<=R, (where b, r, p, M, R, Ctot, and Dtot are defined later
this document).
NOTE: While the per-hop error terms needed to compute the end-to
end delays are exported by the service module (see
Information below), the mechanisms needed to collect per-
bounds and make the end-to-end quantities Ctot and Dtot known
the applications are not described in this specification.
functions are provided by reservation setup protocols,
protocols or other network management functions and are
the scope of this document
The maximum end-to-end queueing delay (as characterized by Ctot
Dtot) and bandwidth (characterized by R) provided along a path
be stable. That is, they will not change as long as the end-to-
path does not change
Guaranteed service does not control the minimal or average delay
datagrams, merely the maximal queueing delay. Furthermore,
compute the maximum delay a datagram will experience, the latency
the path MUST be determined and added to the guaranteed
delay. (However, as noted below, a conservative bound of the
can be computed by observing the delay experienced by any
packet).
This service is subject to admission control
Shenker, et. al. Standards Track [Page 3]
RFC 2212 Guaranteed Quality of Service September 1997
Guaranteed service guarantees that datagrams will arrive within
guaranteed delivery time and will not be discarded due to
overflows, provided the flow's traffic stays within its
traffic parameters. This service is intended for applications
need a firm guarantee that a datagram will arrive no later than
certain time after it was transmitted by its source. For example
some audio and video "play-back" applications are intolerant of
datagram arriving after their play-back time. Applications that
hard real-time requirements will also require guaranteed service
This service does not attempt to minimize the jitter (the
between the minimal and maximal datagram delays); it merely
the maximal queueing delay. Because the guaranteed delay bound is
firm one, the delay has to be set large enough to cover
rare cases of long queueing delays. Several studies have shown
the actual delay for the vast majority of datagrams can be far
than the guaranteed delay. Therefore, authors of
applications should note that datagrams will often arrive far
than the delivery deadline and will have to be buffered at
receiving system until it is time for the application to
them
This service represents one extreme end of delay control
networks. Most other services providing delay control provide
weaker assurances about the resulting delays. In order to
this high level of assurance, guaranteed service is typically
useful if provided by every network element along the path (i.e.
both routers and the links that interconnect the routers). Moreover
as described in the Exported Information section, effective
and use of the service requires that the set-up protocol or
mechanism used to request service provides service
to intermediate routers and to the endpoints
Network Element Data Handling
The network element MUST ensure that the service approximates
"fluid model" of service. The fluid model at service rate R
essentially the service that would be provided by a dedicated wire
bandwidth R between the source and receiver. Thus, in the
model of service at a fixed rate R, the flow's service is
independent of that of any other flow
Shenker, et. al. Standards Track [Page 4]
RFC 2212 Guaranteed Quality of Service September 1997
The flow's level of service is characterized at each network
by a bandwidth (or service rate) R and a buffer size B. R
the share of the link's bandwidth the flow is entitled to and
represents the buffer space in the network element that the flow
consume. The network element MUST ensure that its service
the fluid model at that same rate to within a sharp error bound
The definition of guaranteed service relies on the result that
fluid delay of a flow obeying a token bucket (r,b) and being
by a line with bandwidth R is bounded by b/R as long as R is no
than r. Guaranteed service with a service rate R, where now R is
share of bandwidth rather than the bandwidth of a dedicated line
approximates this behavior
Consequently, the network element MUST ensure that the queueing
of any datagram be less than b/R+C/R+D, where C and D describe
maximal local deviation away from the fluid model. It is
to emphasize that C and D are maximums. So, for instance, if
implementation has occasional gaps in service (perhaps due
processing routing updates), D needs to be large enough to
for the time a datagram may lose during the gap in service. (C and
are described in more detail in the section on Exported Information).
NOTE: Strictly speaking, this memo requires only that the
a flow receives is never worse than it would receive under
approximation of the fluid model. It is perfectly acceptable
give better service. For instance, if a flow is currently
using its share, R, algorithms such as Weighted Fair Queueing
temporarily give other flows the unused bandwidth, are
acceptable (indeed, are encouraged).
Links are not permitted to fragment datagrams as part of
service. Datagrams larger than the MTU of the link MUST be
as nonconformant which means that they will be policed according
the rules described in the Policing section below
Invocation
Guaranteed service is invoked by specifying the traffic (TSpec)
the desired service (RSpec) to the network element. A
request for an existing flow that has a new TSpec and/or RSpec
be treated as a new invocation, in the sense that admission
SHOULD be reapplied to the flow. Flows that reduce their
and/or their RSpec (i.e., their new TSpec/RSpec is strictly
than the old TSpec/RSpec according to the ordering rules described
the section on Ordering below) SHOULD never be denied service
Shenker, et. al. Standards Track [Page 5]
RFC 2212 Guaranteed Quality of Service September 1997
The TSpec takes the form of a token bucket plus a peak rate (p),
minimum policed unit (m), and a maximum datagram size (M).
The token bucket has a bucket depth, b, and a bucket rate, r. Both
and r MUST be positive. The rate, r, is measured in bytes of
datagrams per second, and can range from 1 byte per second to
large as 40 terabytes per second (or close to what is believed to
the maximum theoretical bandwidth of a single strand of fiber).
Clearly, particularly for large bandwidths, only the first few
are significant and so the use of floating point representations
accurate to at least 0.1% is encouraged
The bucket depth, b, is also measured in bytes and can range from 1
byte to 250 gigabytes. Again, floating point
accurate to at least 0.1% are encouraged
The range of values is intentionally large to allow for the
bandwidths. The range is not intended to imply that a
element has to support the entire range
The peak rate, p, is measured in bytes of IP datagrams per second
has the same range and suggested representation as the bucket rate
The peak rate is the maximum rate at which the source and
reshaping points (reshaping points are defined below) may
bursts of traffic into the network. More precisely, it is
requirement that for all time periods the amount of data sent
exceed M+pT where M is the maximum datagram size and T is the
of the time period. Furthermore, p MUST be greater than or equal
the token bucket rate, r. If the peak rate is unknown
unspecified, then p MUST be set to infinity
The minimum policed unit, m, is an integer measured in bytes. All
datagrams less than size m will be counted, when policed and
for conformance to the TSpec, as being of size m. The
datagram size, M, is the biggest datagram that will conform to
traffic specification; it is also measured in bytes. The flow
be rejected if the requested maximum datagram size is larger than
MTU of the link. Both m and M MUST be positive, and m MUST be
than or equal to M
The guaranteed service uses the general TOKEN_BUCKET_
parameter defined in Reference [8] to describe a data flow'
traffic characteristics. The description above is of
parameter. The TOKEN_BUCKET_TSPEC is general parameter
127. Use of this parameter for the guaranteed service
simplifies the use of guaranteed Service in a multi-
environment
Shenker, et. al. Standards Track [Page 6]
RFC 2212 Guaranteed Quality of Service September 1997
The RSpec is a rate R and a slack term S, where R MUST be
than or equal to r and S MUST be nonnegative. The rate R is
measured in bytes of IP datagrams per second and has the same
and suggested representation as the bucket and the peak rates.
slack term S is in microseconds. The RSpec rate can be bigger
the TSpec rate because higher rates will reduce queueing delay.
slack term signifies the difference between the desired delay and
delay obtained by using a reservation level R. This slack term
be utilized by the network element to reduce its resource
for this flow. When a network element chooses to utilize some of
slack in the RSpec, it MUST follow specific rules in updating the
and S fields of the RSpec; these rules are specified in the
and Merging section. If at the time of service invocation no
is specified, the slack term, S, is set to zero. No
specification is included in the RSpec because the network element
expected to derive the required buffer space to ensure no
loss from the token bucket and peak rate in the TSpec, the
rate and slack in the RSpec, the exported information received at
network element, i.e., Ctot and Dtot or Csum and Dsum, combined
internal information about how the element manages its traffic
The TSpec can be represented by three floating point numbers
single-precision IEEE floating point format followed by two 32-
integers in network byte order. The first floating point value
the rate (r), the second floating point value is the bucket size (b),
the third floating point is the peak rate (p), the first integer
the minimum policed unit (m), and the second integer is the
datagram size (M).
The RSpec rate term, R, can also be represented using single
precision IEEE floating point
The Slack term, S, can be represented as a 32-bit integer. Its
can range from 0 to (2**32)-1 microseconds
When r, b, p, and R terms are represented as IEEE floating
values, the sign bit MUST be zero (all values MUST be non-negative).
Exponents less than 127 (i.e., 0) are prohibited. Exponents
than 162 (i.e., positive 35) are discouraged, except for specifying
peak rate of infinity. Infinity is represented with an exponent
all ones (255) and a sign bit and mantissa of all zeroes
Exported
Each guaranteed service module MUST export at least the
information. All of the parameters described below
characterization parameters
Shenker, et. al. Standards Track [Page 7]
RFC 2212 Guaranteed Quality of Service September 1997
A network element's implementation of guaranteed service
characterized by two error terms, C and D, which represent how
element's implementation of the guaranteed service deviates from
fluid model. These two parameters have an additive composition rule
The error term C is the rate-dependent error term. It represents
delay a datagram in the flow might experience due to the
parameters of the flow. An example of such an error term is the
to account for the time taken serializing a datagram broken up
ATM cells, with the cells sent at a frequency of 1/r
NOTE: It is important to observe that when computing the
bound, parameter C is divided by the reservation rate R.
division is done because, as with the example of serializing
datagram, the effect of the C term is a function of
transmission rate. Implementors should take care to confirm
their C values, when divided by various rates, give
results. Delay values that are not dependent on the rate
be incorporated into the value for the D parameter
The error term D is the rate-independent, per-element error term
represents the worst case non-rate-based transit time
through the service element. It is generally determined or set
boot or configuration time. An example of D is a slotted network,
which guaranteed flows are assigned particular slots in a cycle
slots. Some part of the per-flow delay may be determined by
slots in the cycle are allocated to the flow. In this case, D
measure the maximum amount of time a flow's data, once ready to
sent, might have to wait for a slot. (Observe that this value can
computed before slots are assigned and thus can be advertised.
instance, imagine there are 100 slots. In the worst case, a
might get all of its N slots clustered together, such that if
packet was made ready to send just after the cluster ended,
packet might have to wait 100-N slot times before transmitting.
this case one can easily approximate this delay by setting D to 100
slot times).
If the composition function is applied along the entire path
compute the end-to-end sums of C and D (Ctot and Dtot) and
resulting values are then provided to the end nodes (by
the setup protocol), the end nodes can compute the maximal
queueing delays. Moreover, if the partial sums (Csum and Dsum)
the most recent reshaping point (reshaping points are defined below
downstream towards receivers are handed to each network element
these network elements can compute the buffer allocations
Shenker, et. al. Standards Track [Page 8]
RFC 2212 Guaranteed Quality of Service September 1997
to achieve no datagram loss, as detailed in the section
for Implementors. The proper use and provision of this
requires that the quantities Ctot and Dtot, and the quantities
and Dsum be computed. Therefore, we assume that usage of
service will be primarily in contexts where these quantities are
available to end nodes and network elements
The error term C is measured in units of bytes. An
element can advertise a C value between 1 and 2**28 (a little
250 megabytes) and the total added over all elements can range
high as (2**32)-1. Should the sum of the different elements
exceed (2**32)-1, the end-to-end error term MUST be set to (2**32)-1.
The error term D is measured in units of one microsecond.
individual element can advertise a delay value between 1 and 2**28
(somewhat over two minutes) and the total delay added over
elements can range as high as (2**32)-1. Should the sum of
different elements delay exceed (2**32)-1, the end-to-end delay
be set to (2**32)-1.
The guaranteed service is service_name 2.
The RSpec parameter is numbered 130.
Error characterization parameters C and D are numbered 131 and 132.
The end-to-end composed values for C and D (Ctot and Dtot)
numbered 133 and 134. The since-last-reshaping point composed
for C and D (Csum and Dsum) are numbered 135 and 136.
There are two forms of policing in guaranteed service. One form
simple policing (hereafter just called policing to be consistent
other documents), in which arriving traffic is compared against
TSpec. The other form is reshaping, where an attempt is made
restore (possibly distorted) traffic's shape to conform to the TSpec
and the fact that traffic is in violation of the TSpec is
because the reshaping fails (the reshaping buffer overflows).
Policing is done at the edge of the network. Reshaping is done
all heterogeneous source branch points and at all source
points. A heterogeneous source branch point is a spot where
multicast distribution tree from a source branches to
distinct paths, and the TSpec's of the reservations on the
outgoing links are not all the same. Reshaping need only be done
the TSpec on the outgoing link is "less than" (in the sense
in the Ordering section) the TSpec reserved on the
upstream link. A source merge point is where the distribution
Shenker, et. al. Standards Track [Page 9]
RFC 2212 Guaranteed Quality of Service September 1997
or trees from two different sources (sharing the same reservation
merge. It is the responsibility of the invoker of the service (
setup protocol, local configuration tool, or similar mechanism)
identify points where policing is required. Reshaping may be done
other points as well as those described above. Policing MUST not
done except at the edge of the network
The token bucket and peak rate parameters require that traffic
obey the rule that over all time periods, the amount of data
cannot exceed M+min[pT, rT+b-M], where r and b are the token
parameters, M is the maximum datagram size, and T is the length
the time period (note that when p is infinite this reduces to
standard token bucket requirement). For the purposes of
accounting, links MUST count datagrams which are smaller than
minimum policing unit to be of size m. Datagrams which arrive at
element and cause a violation of the the M+min[pT, rT+b-M] bound
considered non-conformant
At the edge of the network, traffic is policed to ensure it
to the token bucket. Non-conforming datagrams SHOULD be treated
best-effort datagrams. [If and when a marking ability
available, these non-conformant datagrams SHOULD be ''marked''
being non-compliant and then treated as best effort datagrams at
subsequent routers.]
Best effort service is defined as the default service a
element would give to a datagram that is not part of a flow and
sent between the flow's source and destination. Among
implications, this definition means that if a flow's datagram
changed to a best effort datagram, all flow control (e.g., RED [2])
that is normally applied to best effort datagrams is applied to
datagram too
NOTE: There may be situations outside the scope of this document
such as when a service module's implementation of
service is being used to implement traffic sharing rather than
quality of service, where the desired action is to discard non
conforming datagrams. To allow for such uses, implementors
ensure that the action to be taken for non-conforming datagrams
configurable
Inside the network, policing does not produce the desired results
because queueing effects will occasionally cause a flow's
that entered the network as conformant to be no longer conformant
some downstream network element. Therefore, inside the network
network elements that wish to police traffic MUST do so by
traffic to the token bucket. Reshaping entails delaying
until they are within conformance of the TSpec
Shenker, et. al. Standards Track [Page 10]
RFC 2212 Guaranteed Quality of Service September 1997
Reshaping is done by combining a buffer with a token bucket and
rate regulator and buffering data until it can be sent in
with the token bucket and peak rate parameters. (The token
regulator MUST start with its token bucket full of tokens).
guaranteed service, the amount of buffering required to reshape
conforming traffic back to its original token bucket shape
b+Csum+(Dsum*r), where Csum and Dsum are the sums of the parameters
and D between the last reshaping point and the current
point. Note that the knowledge of the peak rate at the reshapers
be used to reduce these buffer requirements (see the section
"Guidelines for Implementors" below). A network element MUST
the necessary buffers to ensure that conforming traffic is not
at the reshaper
NOTE: Observe that a router that is not reshaping can
identify non-conforming datagrams (and discard them or
them at lower priority) by observing when queued traffic for
flow exceeds b+Csum+(Dsum*r).
If a datagram arrives to discover the reshaping buffer is full,
the datagram is non-conforming. Observe this means that a
is effectively policing too. As with a policer, the reshaper
relegate non-conforming datagrams to best effort. [If marking
available, the non-conforming datagrams SHOULD be marked
NOTE: As with policers, it SHOULD be possible to configure
reshapers handle non-conforming datagrams
Note that while the large buffer makes it appear that reshapers
considerable delay, this is not the case. Given a valid TSpec
accurately describes the traffic, reshaping will cause little
actual delay at the reshaping point (and will not affect the
bound at all). Furthermore, in the normal case, reshaping will
cause the loss of any data
However, (typically at merge or branch points), it may happen
the TSpec is smaller than the actual traffic. If this happens
reshaping will cause a large queue to develop at the reshaping point
which both causes substantial additional delays and forces
datagrams to be treated as non-conforming. This scenario makes
unpleasant denial of service attack possible, in which a receiver
is successfully receiving a flow's traffic via best effort service
pre-empted by a new receiver who requests a reservation for the flow
but with an inadequate TSpec and RSpec. The flow's traffic will
be policed and possibly reshaped. If the policing function
chosen to discard datagrams, the best-effort receiver would
receiving traffic. For this reason, in the normal case, policers
simply to treat non-conforming datagrams as best effort (and
Shenker, et. al. Standards Track [Page 11]
RFC 2212 Guaranteed Quality of Service September 1997
them if marking is implemented). While this protects against
of service, it is still true that the bad TSpec may cause
delays to increase
NOTE: To minimize problems of reordering datagrams,
points may wish to forward a best-effort datagram from the
of the reshaping queue when a new datagram arrives and
reshaping buffer is full
Readers should also observe that reclassifying datagrams as
effort (as opposed to dropping the datagrams) also makes
for elastic flows easier. They can reserve a modest token
and when their traffic exceeds the token bucket, the
traffic will be sent best effort
A related issue is that at all network elements, datagrams
than the MTU of the network element MUST be considered non-
and SHOULD be classified as best effort (and will then either
fragmented or dropped according to the element's handling of
effort traffic). [Again, if marking is available, these
datagrams SHOULD be marked.]
Ordering and
TSpec's are ordered according to the following rules
TSpec A is a substitute ("as good or better than") for TSpec B if (1)
both the token rate r and bucket depth b for TSpec A are greater
or equal to those of TSpec B; (2) the peak rate p is at least
large in TSpec A as it is in TSpec B; (3) the minimum policed unit
is at least as small for TSpec A as it is for TSpec B; and (4)
maximum datagram size M is at least as large for TSpec A as it is
TSpec B
TSpec A is "less than or equal" to TSpec B if (1) both the token
r and bucket depth b for TSpec A are less than or equal to those
TSpec B; (2) the peak rate p in TSpec A is at least as small as
peak rate in TSpec B; (3) the minimum policed unit m is at least
large for TSpec A as it is for TSpec B; and (4) the maximum
size M is at least as small for TSpec A as it is for TSpec B
A merged TSpec may be calculated over a set of TSpecs by taking (1)
the largest token bucket rate, (2) the largest bucket size, (3)
largest peak rate, (4) the smallest minimum policed unit, and (5)
smallest maximum datagram size across all members of the set.
use of the word "merging" is similar to that in the RSVP
[10]; a merged TSpec is one which is adequate to describe the
from any one of constituent TSpecs
Shenker, et. al. Standards Track [Page 12]
RFC 2212 Guaranteed Quality of Service September 1997
A summed TSpec may be calculated over a set of TSpecs by
(1) the sum of the token bucket rates, (2) the sum of the
sizes, (3) the sum of the peak rates, (4) the smallest
policed unit, and (5) the maximum datagram size parameter
A least common TSpec is one that is sufficient to describe
traffic of any one in a set of traffic flows. A least common
may be calculated over a set of TSpecs by computing: (1) the
token bucket rate, (2) the largest bucket size, (3) the largest
rate, (4) the smallest minimum policed unit, and (5) the
maximum datagram size across all members of the set
The minimum of two TSpecs differs according to whether the TSpecs
be ordered. If one TSpec is less than the other TSpec, the
TSpec is the minimum. Otherwise, the minimum TSpec of two TSpecs
determined by comparing the respective values in the two TSpecs
choosing (1) the smaller token bucket rate, (2) the larger
bucket size (3) the smaller peak rate, (4) the smaller
policed unit, and (5) the smaller maximum datagram size
The RSpec's are merged in a similar manner as the TSpecs, i.e. a
of RSpecs is merged onto a single RSpec by taking the largest rate R
and the smallest slack S. More precisely, RSpec A is a
for RSpec B if the value of reserved service rate, R, in RSpec A
greater than or equal to the value in RSpec B, and the value of
slack, S, in RSpec A is smaller than or equal to that in RSpec B
Each network element receives a service request of the form (TSpec
RSpec), where the RSpec is of the form (Rin, Sin). The
element processes this request and performs one of two actions
a. it accepts the request and returns a new Rspec of the
(Rout, Sout);
b. it rejects the request
The processing rules for generating the new RSpec are governed by
delay constraint
Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin
where Ctoti is the cumulative sum of the error terms, C, for all
network elements that are upstream of and including the
element, i. In other words, this element consumes (Sin - Sout)
slack and can use it to reduce its reservation level, provided
the above inequality is satisfied. Rin and Rout MUST also
the constraint
r <= Rout <= Rin
Shenker, et. al. Standards Track [Page 13]
RFC 2212 Guaranteed Quality of Service September 1997
When several RSpec's, each with rate Rj, j=1,2..., are to be
at a split point, the value of Rout is the maximum over all the
Rj, and the value of Sout is the minimum over all the slack terms Sj
NOTE: The various TSpec functions described above are used
applications which desire to combine TSpecs. It is important
observe, however, that the properties of the actual
are determined by combining the TSpec with the RSpec rate (R).
Because the guaranteed reservation requires both the TSpec and
RSpec rate, there exist some difficult problems for
reservations in RSVP, particularly where two or more
streams meet. Upstream of the meeting point, it would
desirable to reduce the TSpec and RSpec to use only as
bandwidth and buffering as is required by the individual source'
traffic. (Indeed, it may be necessary if the sender
transmitting over a low bandwidth link).
However, the RSpec's rate is set to achieve a particular
bound (and is notjust a function of the TSpec), so changing
RSpec may cause the reservation to fail to meet the receiver'
delay requirements. At the same time, not adjusting the
rate means that "shared" RSVP reservations using
service will fail whenever the bandwidth available at a
link is less than the receiver's requested rate R, even if
bandwidth is adequate to support the number of senders
using the link. At this time, this limitation is an open
in using the guaranteed service with RSVP
Guidelines for
This section discusses a number of important implementation issues
no particular order
It is important to note that individual subnetworks are
elements and both routers and subnetworks MUST support the
service model to achieve guaranteed service. Since
typically are not capable of negotiating service using IP-
protocols, as part of providing guaranteed service, routers will
to act as proxies for the subnetworks they are attached to
In some cases, this proxy service will be easy. For instance,
leased line managed by a WFQ scheduler on the upstream node,
proxy need simply ensure that the sum of all the flows' RSpec
does not exceed the bandwidth of the line, and needs to advertise
rate-based and non-rate-based delays of the link as the values of
and D
Shenker, et. al. Standards Track [Page 14]
RFC 2212 Guaranteed Quality of Service September 1997
In other cases, this proxy service will be complex. In an
network, for example, it may require establishing an ATM VC for
flow and computing the C and D terms for that VC. Readers
observe that the token bucket and peak rate used by
service map directly to the Sustained Cell Rate, Burst Size, and
Cell Rate of ATM's Q.2931 QoS parameters for Variable Bit
traffic
The assurance that datagrams will not be lost is obtained by
the router buffer space B to be equal to the token bucket b plus
error term (described below).
Another issue related to subnetworks is that the TSpec's token
rates measure IP traffic and do not (and cannot) account for
level headers. So the subnetwork network elements MUST adjust
rate and possibly the bucket size to account for adding link
headers. Tunnels MUST also account for the additional IP
that they add
For datagram networks, a maximum header rate can usually be
by dividing the rate and bucket sizes by the minimum policed unit
For networks that do internal fragmentation, such as ATM,
computation may be more complex, since one MUST account for
per-fragment overhead and any wastage (padding bytes transmitted)
to mismatches between datagram sizes and fragment sizes.
instance, a conservative estimate of the additional data rate
by ATM AAL5 plus ATM segmentation and reassembly
((r/48)*5)+((r/m)*(8+52))
which represents the rate divided into 48-byte cells multiplied
the 5-byte ATM header, plus the maximum datagram rate (r/m
multiplied by the cost of the 8-byte AAL5 header plus the
space that can be wasted by ATM segmentation of a datagram (which
the 52 bytes wasted in a cell that contains one byte). But
estimate is likely to be wildly high, especially if m is small,
ATM wastage is usually much less than 52 bytes. (ATM
should be warned that the token bucket may also have to be
when setting the VC parameters for call setup and that this
does not account for overhead incurred by encapsulations such
those specified in RFC 1483).
To ensure no loss, network elements will have to allocate
buffering for bursts. If every hop implemented the fluid
perfectly, this buffering would simply be b (the token bucket size).
However, as noted in the discussion of reshaping earlier
implementations are approximations and we expect that traffic
become more bursty as it goes through the network. However, as
Shenker, et. al. Standards Track [Page 15]
RFC 2212 Guaranteed Quality of Service September 1997
shaping the amount of buffering required to handle the burstiness
bounded by b+Csum+Dsum*R. If one accounts for the peak rate,
can be further reduced
M + (b-M)(p-X)/(p-r) + (Csum/R + Dsum)
where X is set to r if (b-M)/(p-r) is less than Csum/R+Dsum and X
R if (b-M)/(p-r) is greater than or equal to Csum/R+Dsum and p>R
otherwise, X is set to p. This reduction comes from the fact
the peak rate limits the rate at which the burst, b, can be placed
the network. Conversely, if a non-zero slack term, Sout, is
by the network element, the buffer requirements are increased
adding Sout to Dsum
While sending applications are encouraged to set the peak
parameter and reshaping points are required to conform to it, it
always acceptable to ignore the peak rate for the purposes
computing buffer requirements and end-to-end delays. The result
simply an overestimate of the buffering and delay. As noted above
if the peak rate is unknown (and thus potentially infinite),
buffering required is b+Csum+Dsum*R. The end-to-end delay
the peak rate is b/R+Ctot/R+Dtot
The parameter D for each network element SHOULD be set to the
datagram transfer delay variation (independent of rate and
size) through the network element. For instance, in a simple router
one might compute the difference between the worst case and best
times it takes for a datagram to get through the input interface
the processor, and add it to any variation that may occur in how
it would take to get from the processor to the outbound
scheduler (assuming the queueing schemes work correctly).
For weighted fair queueing in a datagram environment, D is set to
link MTU divided by the link bandwidth, to account for
possibility that a packet arrives just as a maximum-sized
begins to be transmitted, and that the arriving packet should
departed before the maximum-sized packet. For a frame-based,
system such as Stop and Go queueing, D is the maximum number of
a datagram may have to wait before getting a chance to
transmitted
Note that multicasting may make determining D more difficult.
many subnets, ATM being one example, the properties of the subnet
depend on the path taken from the multicast sender to the receiver
There are a number of possible approaches to this problem. One is
Shenker, et. al. Standards Track [Page 16]
RFC 2212 Guaranteed Quality of Service September 1997
choose a representative latency for the overall subnet and set D
the (non-negative) difference from that latency. Another is
estimate subnet properties at exit points from the subnet, since
exit point presumably is best placed to compute the properties of
path from the source
NOTE: It is important to note that there is no fixed set of
about how a subnet determines its properties, and each
technology will have to develop its own set of procedures
accurately compute C and D and slack values
D is intended to be distinct from the latency through the
element. Latency is the minimum time through the device (the
of light delay in a fiber or the absolute minimum time it would
to move a packet through a router), while parameter D is intended
bound the variability in non-rate-based delay. In practice,
distinction is sometimes arbitrary (the latency may be minimal) --
such cases it is perfectly reasonable to combine the latency with
and to advertise any latency as zero
NOTE: It is implicit in this scheme that to get a
guarantee of the maximum delay a packet might experience, a
of this service will need to know both the queueing
(provided by C and D) and the latency. The latency is
advertised by this service but is a general
parameter (advertised as specified in [8]).
However, even if latency is not advertised, this service can
be used. The simplest approach is to measure the
experienced by the first packet (or the minimum delay of the
few packets) received and treat this delay value as an upper
on the latency
The parameter C is the data backlog resulting from the vagaries
how a specific implementation deviates from a strict bit-by-
service. So, for instance, for datagramized weighted fair queueing,
is set to M to account for packetization effects
If a network element uses a certain amount of slack, Si, to
the amount of resources that it has reserved for a particular flow
i, the value Si SHOULD be stored at the network element
Subsequently, if reservation refreshes are received for flow i,
network element MUST use the same slack Si without any
computation. This guarantees consistency in the reservation process
Shenker, et. al. Standards Track [Page 17]
RFC 2212 Guaranteed Quality of Service September 1997
As an example for the use of the slack term, consider the case
the required end-to-end delay, Dreq, is larger than the maximum
of the fluid flow system. The latter is obtained by setting R=r
the fluid delay formula (for stability, R>=r must be true), and
given
b/r + Ctot/r + Dtot
In this case the slack term
S = Dreq - (b/r + Ctot/r + Dtot).
The slack term may be used by the network elements to adjust
local reservations, so that they can admit flows that would
have been rejected. A network element at an intermediate
element that can internally differentiate between delay and
guarantees can now take advantage of this information to lower
amount of resources allocated to this flow. For example, by taking
amount of slack s <= S, an RCSD scheduler [5] can increase the
delay bound, d, assigned to the flow, to d+s. Given an RSpec, (Rin
Sin), it would do so by setting Rout = Rin and Sout = Sin - s
Similarly, a network element using a WFQ scheduler can decrease
local reservation from Rin to Rout by using some of the slack in
RSpec. This can be accomplished by using the transformation
given in the previous section, that ensure that the
reservation level will not increase the overall end-to-end delay
Evaluation
The scheduling algorithm and admission control algorithm of
element MUST ensure that the delay bounds are never violated
datagrams are not lost, when a source's traffic conforms to
TSpec. Furthermore, the element MUST ensure that misbehaving
do not affect the service given to other flows. Vendors
encouraged to formally prove that their implementation is
approximation of the fluid model
Examples of
Several algorithms and implementations exist that approximate
fluid model. They include Weighted Fair Queueing (WFQ) [2], Jitter
EDD [3], Virtual Clock [4] and a scheme proposed by IBM [5]. A
theoretical presentation that shows these schemes are part of a
class of algorithms can be found in [6].
Shenker, et. al. Standards Track [Page 18]
RFC 2212 Guaranteed Quality of Service September 1997
Examples of
Consider an application that is intolerant of any lost or
datagrams. It uses the advertised values Ctot and Dtot and the
of the flow, to compute the resulting delay bound from a
request with rate R. Assuming R < p, it then sets its playback
to [(b-M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot
Security
This memo discusses how this service could be abused to permit
of service attacks. The service, as defined, does not allow
of service (although service may degrade under
circumstances).
Appendix 1: Use of the Guaranteed service with
The use of guaranteed service in conjunction with the RSVP
reservation setup protocol is specified in reference [9].
document gives the format of RSVP FLOWSPEC, SENDER_TSPEC, and
objects needed to support applications desiring guaranteed
and gives information about how RSVP processes those objects.
RSVP protocol itself is specified in Reference [10].
[1] Shenker, S., and J. Wroclawski, "Network Element
Specification Template", RFC 2216, September 1997.
[2] A. Demers, S. Keshav and S. Shenker, "Analysis and Simulation
a Fair Queueing Algorithm," in Internetworking: Research
Experience, Vol 1, No. 1., pp. 3-26.
[3] L. Zhang, "Virtual Clock: A New Traffic Control Algorithm
Packet Switching Networks," in Proc. ACM SIGCOMM '90, pp. 19-29.
[4] D. Verma, H. Zhang, and D. Ferrari, "Guaranteeing Delay
Bounds in Packet Switching Networks," in Proc. Tricomm '91.
[5] L. Georgiadis, R. Guerin, V. Peris, and K. N. Sivarajan
"Efficient Network QoS Provisioning Based on per Node
Shaping," IBM Research Report No. RC-20064.
[6] P. Goyal, S.S. Lam and H.M. Vin, "Determining End-to-End
Bounds in Heterogeneous Networks," in Proc. 5th Intl. Workshop
Network and Operating System Support for Digital Audio and Video
April 1995.
Shenker, et. al. Standards Track [Page 19]
RFC 2212 Guaranteed Quality of Service September 1997
[7] A.K.J. Parekh, A Generalized Processor Sharing Approach to
Control in Integrated Services Networks, MIT Laboratory
Information and Decision Systems, Report LIDS-TH-2089, February 1992.
[8] Shenker, S., and J. Wroclawski, "General
Parameters for Integrated Service Network Elements", RFC 2215,
September 1997.
[9] Wroclawski, J., "Use of RSVP with IETF Integrated Services",
2210, September 1997.
[10] Braden, R., Ed., et. al., "Resource Reservation Protocol (RSVP
- Version 1 Functional Specification", RFC 2205, September 1997.
Authors'
Scott
Xerox
3333 Coyote Hill
Palo Alto, CA 94304-1314
Phone: 415-812-4840
Fax: 415-812-4471
EMail: shenker@parc.xerox.
Craig
2370 Amherst
Palo Alto CA 94306
EMail: craig@bbn.
Roch
IBM T.J. Watson Research
Yorktown Heights, NY 10598
Phone: 914-784-7038
Fax: 914-784-6318
EMail: guerin@watson.ibm.
Shenker, et. al. Standards Track [Page 20]
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
