< draft-ietf-intserv-guaranteed-svc-06.txt   draft-ietf-intserv-guaranteed-svc-07.txt >
Internet Engineering Task Force Integrated Services WG Internet Engineering Task Force Integrated Services WG
INTERNET-DRAFT S. Shenker/C. Partridge/R. Guerin INTERNET-DRAFT S. Shenker/C. Partridge/R. Guerin
draft-ietf-intserv-guaranteed-svc-06.txt Xerox/BBN/IBM draft-ietf-intserv-guaranteed-svc-07.txt Xerox/BBN/IBM
13 August 1996 3 February 1997
Expires: 2/13/97 Expires: 8/3/98
Specification of Guaranteed Quality of Service Specification of Guaranteed Quality of Service
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 19 skipping to change at page 2, line 19
documents that specify the network element behavior required to documents that specify the network element behavior required to
support various qualities of service in IP internetworks. Services support various qualities of service in IP internetworks. Services
described in these documents are useful both in the global Internet described in these documents are useful both in the global Internet
and private IP networks. and private IP networks.
This document is based on the service specification template given in This document is based on the service specification template given in
[1]. Please refer to that document for definitions and additional [1]. Please refer to that document for definitions and additional
information about the specification of qualities of service within information about the specification of qualities of service within
the IP protocol family. the IP protocol family.
In brief, the concept behind this memo is that a flow is described
using a token bucket and given this description of a flow, a service
element (a router, a subnet, etc) computes various parameters
describing how the service element will handle the flow's data. By
combining the parameters from the various service elements in a path,
it is possible to compute the maximum delay a piece of data will
experience when transmitted via that path.
It is important to note three characteristics of this memo and the
service it specifies:
1. While the requirements a setup mechanism must follow to achieve
a guaranteed reservation are carefully specified, neither the
setup mechanism itself nor the method for identifying flows is
specified. One can create a guaranteed reservation using a
protocol like RSVP, manual configuration of relevant routers or a
network management protocol like SNMP. This specification is
intentionally independent of setup mechanism.
2. To achieve a bounded delay requires that every service element
in the path supports guaranteed service or adequately mimics
guaranteed service. However this requirement does not imply that
guaranteed service must be deployed throughout the Internet to be
useful. Guaranteed service can have clear benefits even when
partially deployed. If fully deployed in an intranet, that
intranet can support guaranteed service internally. And an ISP
can put guaranteed service in its backbone and provide guaranteed
service between customers (or between POPs).
3. Because service elements produce a delay bound as a result
rather than take a delay bound as an input to be achieved, it is
sometimes assumed that applications cannot control the delay. In
reality, guaranteed service gives applications considerable
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 the
chosen path, which is determined not by guaranteed service but by
the setup mechanism. Only queueing delay is determined by
guaranteed service. And (as the equations later in this memo
show) the queueing delay is primarily a function of two
parameters: the token bucket (in particular, the bucket size b)
and the data rate (R) the application requests. These two values
are completely under the application's control. In other words,
an application can usually accurately estimate, a priori, what
queueing delay guaranteed service will likely promise.
Furthermore, if the delay is larger than expected, the application
can modify its token bucket and data rate in predictable ways to
achieve a lower delay.
End-to-End Behavior End-to-End Behavior
The end-to-end behavior provided by a series of network elements that The end-to-end behavior provided by a series of network elements that
conform to this document is an assured level of bandwidth that, when conform to this document is an assured level of bandwidth that, when
used by a policed flow, produces a delay-bounded service with no used by a policed flow, produces a delay-bounded service with no
queueing loss for all conforming datagrams (assuming no failure of queueing loss for all conforming datagrams (assuming no failure of
network components or changes in routing during the life of the network components or changes in routing during the life of the
flow). flow).
The end-to-end behavior conforms to the fluid model (described under The end-to-end behavior conforms to the fluid model (described under
skipping to change at page 6, line 9 skipping to change at page 7, line 9
The guaranteed service uses the general TOKEN_BUCKET_TSPEC The guaranteed service uses the general TOKEN_BUCKET_TSPEC
parameter defined in Reference [8] to describe a data flow's parameter defined in Reference [8] to describe a data flow's
traffic characteristics. The description above is of that traffic characteristics. The description above is of that
parameter. The TOKEN_BUCKET_TSPEC is general parameter number parameter. The TOKEN_BUCKET_TSPEC is general parameter number
127. Use of this parameter for the guaranteed service TSpec 127. Use of this parameter for the guaranteed service TSpec
simplifies the use of guaranteed Service in a multi-service simplifies the use of guaranteed Service in a multi-service
environment. environment.
The RSpec is a rate R and a slack term S, where R MUST be greater The RSpec is a rate R and a slack term S, where R MUST be greater
than or equal to r and S MUST be nonnegative. The RSpec rate can be than or equal to r and S MUST be nonnegative. The rate R is again
bigger than the TSpec rate because higher rates will reduce queueing measured in bytes of IP datagrams per second and has the same range
delay. The slack term signifies the difference between the desired and suggested representation as the bucket and the peak rates. The
delay and the delay obtained by using a reservation level R. This slack term S is in microseconds. The RSpec rate can be bigger than
slack term can be utilized by the network element to reduce its the TSpec rate because higher rates will reduce queueing delay. The
resource reservation for this flow. When a network element chooses to slack term signifies the difference between the desired delay and the
utilize some of the slack in the RSpec, it MUST follow specific rules delay obtained by using a reservation level R. This slack term can
in updating the R and S fields of the RSpec; these rules are be utilized by the network element to reduce its resource reservation
specified in the Ordering and Merging section. If at the time of for this flow. When a network element chooses to utilize some of the
service invocation no slack is specified, the slack term, S, is set slack in the RSpec, it MUST follow specific rules in updating the R
to zero. No buffer specification is included in the RSpec because and S fields of the RSpec; these rules are specified in the Ordering
the network element is expected to derive the required buffer space and Merging section. If at the time of service invocation no slack
to ensure no queueing loss from the token bucket and peak rate in the is specified, the slack term, S, is set to zero. No buffer
TSpec, the reserved rate and slack in the RSpec, the exported specification is included in the RSpec because the network element is
information received at the network element, i.e., Ctot and Dtot or expected to derive the required buffer space to ensure no queueing
Csum and Dsum, combined with internal information about how the loss from the token bucket and peak rate in the TSpec, the reserved
element manages its traffic. rate and slack in the RSpec, the exported information received at the
network element, i.e., Ctot and Dtot or Csum and Dsum, combined with
internal information about how the element manages its traffic.
The TSpec can be represented by three floating point numbers in The TSpec can be represented by three floating point numbers in
single-precision IEEE floating point format followed by two 32-bit single-precision IEEE floating point format followed by two 32-bit
integers in network byte order. The first floating point value is integers in network byte order. The first floating point value is
the rate (r), the second floating point value is the bucket size (b), 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 is the third floating point is the peak rate (p), the first integer is
the minimum policed unit (m), and the second integer is the maximum the minimum policed unit (m), and the second integer is the maximum
datagram size (M). datagram size (M).
The RSpec rate term, R, can also be represented using single- The RSpec rate term, R, can also be represented using single-
precision IEEE floating point. precision IEEE floating point.
The Slack term, S, can be represented as a 32-bit integer. The Slack term, S, can be represented as a 32-bit integer. Its value
can range from 0 to (2**32)-1 microseconds.
When r, b, p, and R terms are represented as IEEE floating point When r, b, p, and R terms are represented as IEEE floating point
values, the sign bit MUST be zero (all values MUST be non-negative). values, the sign bit MUST be zero (all values MUST be non-negative).
Exponents less than 127 (i.e., 0) are prohibited. Exponents greater Exponents less than 127 (i.e., 0) are prohibited. Exponents greater
than 162 (i.e., positive 35) are discouraged, except for specifying a than 162 (i.e., positive 35) are discouraged, except for specifying a
peak rate of infinity. Infinity is represented with an exponent of peak rate of infinity. Infinity is represented with an exponent of
all ones (255) and a sign bit and mantissa of all zeroes. all ones (255) and a sign bit and mantissa of all zeroes.
Exported Information Exported Information
skipping to change at page 10, line 17 skipping to change at page 11, line 23
guaranteed service, the amount of buffering required to reshape any guaranteed service, the amount of buffering required to reshape any
conforming traffic back to its original token bucket shape is conforming traffic back to its original token bucket shape is
b+Csum+(Dsum*r), where Csum and Dsum are the sums of the parameters C b+Csum+(Dsum*r), where Csum and Dsum are the sums of the parameters C
and D between the last reshaping point and the current reshaping and D between the last reshaping point and the current reshaping
point. Note that the knowledge of the peak rate at the reshapers can point. Note that the knowledge of the peak rate at the reshapers can
be used to reduce these buffer requirements (see the section on be used to reduce these buffer requirements (see the section on
"Guidelines for Implementors" below). A network element MUST provide "Guidelines for Implementors" below). A network element MUST provide
the necessary buffers to ensure that conforming traffic is not lost the necessary buffers to ensure that conforming traffic is not lost
at the reshaper. at the reshaper.
NOTE: Observe that a router that is not reshaping can still
identify non-conforming datagrams (and discard them or schedule
them at lower priority) by observing when queued traffic for the
flow exceeds b+Csum+(Dsum*r).
If a datagram arrives to discover the reshaping buffer is full, then If a datagram arrives to discover the reshaping buffer is full, then
the datagram is non-conforming. Observe this means that a reshaper the datagram is non-conforming. Observe this means that a reshaper
is effectively policing too. As with a policer, the reshaper SHOULD is effectively policing too. As with a policer, the reshaper SHOULD
relegate non-conforming datagrams to best effort. [If marking is relegate non-conforming datagrams to best effort. [If marking is
available, the non-conforming datagrams SHOULD be marked] available, the non-conforming datagrams SHOULD be marked]
NOTE: As with policers, it SHOULD be possible to configure how NOTE: As with policers, it SHOULD be possible to configure how
reshapers handle non-conforming datagrams. reshapers handle non-conforming datagrams.
Note that while the large buffer makes it appear that reshapers add Note that while the large buffer makes it appear that reshapers add
skipping to change at page 11, line 43 skipping to change at page 13, line 6
TSpec A is "less than or equal" to TSpec B if (1) both the token rate TSpec A is "less than or equal" to TSpec B if (1) both the token rate
r and bucket depth b for TSpec A are less than or equal to those of r and bucket depth b for TSpec A are less than or equal to those of
TSpec B; (2) the peak rate p in TSpec A is at least as small as the TSpec B; (2) the peak rate p in TSpec A is at least as small as the
peak rate in TSpec B; (3) the minimum policed unit m is at least as peak rate in TSpec B; (3) the minimum policed unit m is at least as
large for TSpec A as it is for TSpec B; and (4) the maximum datagram large for TSpec A as it is for TSpec B; and (4) the maximum datagram
size M is at least as small for TSpec A as it is for TSpec B. 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) 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) the the largest token bucket rate, (2) the largest bucket size, (3) the
largest peak rate, (4) the smallest minimum policed unit, and (5) the largest peak rate, (4) the smallest minimum policed unit, and (5) the
largest maximum datagram size across all members of the set. This smallest maximum datagram size across all members of the set. This
use of the word "merging" is similar to that in the RSVP protocol use of the word "merging" is similar to that in the RSVP protocol
[10]; a merged TSpec is one which is adequate to describe the traffic [10]; a merged TSpec is one which is adequate to describe the traffic
from any one of constituent TSpecs. from any one of constituent TSpecs.
A summed TSpec may be calculated over a set of TSpecs by computing A summed TSpec may be calculated over a set of TSpecs by computing
(1) the sum of the token bucket rates, (2) the sum of the bucket (1) the sum of the token bucket rates, (2) the sum of the bucket
sizes, (3) the sum of the peak rates, (4) the smallest minimum sizes, (3) the sum of the peak rates, (4) the smallest minimum
policed unit, and (5) the maximum packet size parameter. policed unit, and (5) the maximum datagram size parameter.
A least common TSpec is one that is sufficient to describe the
traffic of any one in a set of traffic flows. A least common TSpec
may be calculated over a set of TSpecs by computing: (1) the largest
token bucket rate, (2) the largest bucket size, (3) the largest peak
rate, (4) the smallest minimum policed unit, and (5) the largest
maximum datagram size across all members of the set.
The minimum of two TSpecs differs according to whether the TSpecs can The minimum of two TSpecs differs according to whether the TSpecs can
be ordered. If one TSpec is less than the other TSpec, the smaller be ordered. If one TSpec is less than the other TSpec, the smaller
TSpec is the minimum. Otherwise, the minimum TSpec of two TSpecs is TSpec is the minimum. Otherwise, the minimum TSpec of two TSpecs is
determined by comparing the respective values in the two TSpecs and determined by comparing the respective values in the two TSpecs and
choosing (1) the smaller token bucket rate, (2) the larger token choosing (1) the smaller token bucket rate, (2) the larger token
bucket size (3) the smaller peak rate, (4) the smaller minimum bucket size (3) the smaller peak rate, (4) the smaller minimum
policed unit, and (5) the smaller maximum packet size. policed unit, and (5) the smaller maximum datagram size.
The RSpec's are merged in a similar manner as the TSpecs, i.e. a set The RSpec's are merged in a similar manner as the TSpecs, i.e. a set
of RSpecs is merged onto a single RSpec by taking the largest rate R, 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 substitute and the smallest slack S. More precisely, RSpec A is a substitute
for RSpec B if the value of reserved service rate, R, in RSpec A is for RSpec B if the value of reserved service rate, R, in RSpec A is
greater than or equal to the value in RSpec B, and the value of the greater than or equal to the value in RSpec B, and the value of the
slack, S, in RSpec A is smaller than or equal to that in RSpec B. 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, Each network element receives a service request of the form (TSpec,
RSpec), where the RSpec is of the form (Rin, Sin). The network RSpec), where the RSpec is of the form (Rin, Sin). The network
skipping to change at page 12, line 34 skipping to change at page 14, line 4
a. it accepts the request and returns a new Rspec of the form a. it accepts the request and returns a new Rspec of the form
(Rout, Sout); (Rout, Sout);
b. it rejects the request. b. it rejects the request.
The processing rules for generating the new RSpec are governed by the The processing rules for generating the new RSpec are governed by the
delay constraint: delay constraint:
Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin, Sout + b/Rout + Ctoti/Rout <= Sin + b/Rin + Ctoti/Rin,
where Ctoti is the cumulative sum of the error terms, C, for all the where Ctoti is the cumulative sum of the error terms, C, for all the
network elements that are upstream of the current element, i. In network elements that are upstream of and including the current
other words, this element consumes (Sin - Sout) of slack and can use element, i. In other words, this element consumes (Sin - Sout) of
it to reduce its reservation level, provided that the above slack and can use it to reduce its reservation level, provided that
inequality is satisfied. Rin and Rout MUST also satisfy the the above inequality is satisfied. Rin and Rout MUST also satisfy
constraint: the constraint:
r <= Rout <= Rin. r <= Rout <= Rin.
When several RSpec's, each with rate Rj, j=1,2..., are to be merged When several RSpec's, each with rate Rj, j=1,2..., are to be merged
at a split point, the value of Rout is the maximum over all the rates at a split point, the value of Rout is the maximum over all the rates
Rj, and the value of Sout is the minimum over all the slack terms Sj. Rj, and the value of Sout is the minimum over all the slack terms Sj.
NOTE: The various TSpec functions described above are used by NOTE: The various TSpec functions described above are used by
applications which desire to combine TSpecs. It is important to applications which desire to combine TSpecs. It is important to
observe, however, that the properties of the actual reservation observe, however, that the properties of the actual reservation
skipping to change at page 15, line 27 skipping to change at page 16, line 46
The parameter D for each network element SHOULD be set to the maximum The parameter D for each network element SHOULD be set to the maximum
datagram transfer delay variation (independent of rate and bucket datagram transfer delay variation (independent of rate and bucket
size) through the network element. For instance, in a simple router, size) through the network element. For instance, in a simple router,
one might compute the difference between the worst case and best case one might compute the difference between the worst case and best case
times it takes for a datagram to get through the input interface to times it takes for a datagram to get through the input interface to
the processor, and add it to any variation that may occur in how long the processor, and add it to any variation that may occur in how long
it would take to get from the processor to the outbound link it would take to get from the processor to the outbound link
scheduler (assuming the queueing schemes work correctly). scheduler (assuming the queueing schemes work correctly).
For datagramized weighted fair queueing, D is set to the link MTU For weighted fair queueing in a datagram environment, D is set to the
divided by the link bandwidth, to account for the possibility that a link MTU divided by the link bandwidth, to account for the
packet arrives just as a maximum-sized packet begins to be possibility that a packet arrives just as a maximum-sized packet
transmitted, and that the arriving packet should have departed before begins to be transmitted, and that the arriving packet should have
the maximum-sized packet. For a frame-based, slotted system such as departed before the maximum-sized packet. For a frame-based, slotted
Stop and Go queueing, D is the maximum number of slots a datagram may system such as Stop and Go queueing, D is the maximum number of slots
have to wait before getting a chance to be transmitted. a datagram may have to wait before getting a chance to be
transmitted.
Note that multicasting may make determining D more difficult. In Note that multicasting may make determining D more difficult. In
many subnets, ATM being one example, the properties of the subnet may many subnets, ATM being one example, the properties of the subnet may
depend on the path taken from the multicast sender to the receiver. depend on the path taken from the multicast sender to the receiver.
There are a number of possible approaches to this problem. One is to There are a number of possible approaches to this problem. One is to
choose a representative latency for the overall subnet and set D to choose a representative latency for the overall subnet and set D to
the (non-negative) difference from that latency. Another is to the (non-negative) difference from that latency. Another is to
estimate subnet properties at exit points from the subnet, since the estimate subnet properties at exit points from the subnet, since the
exit point presumably is best placed to compute the properties of its exit point presumably is best placed to compute the properties of its
path from the source. path from the source.
 End of changes. 10 change blocks. 
36 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/