Specification of Guaranteed Quality of Service
RFC 2212
Network Working Group S. Shenker
Request for Comments: 2212 Xerox
Category: Standards Track C. Partridge
BBN
R. Guerin
IBM
September 1997
Specification of Guaranteed Quality of Service
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo describes the network element behavior required to deliver
a guaranteed service (guaranteed delay and bandwidth) in the
Internet. Guaranteed service provides firm (mathematically provable)
bounds on end-to-end datagram queueing delays. This service makes it
possible to provide a service that guarantees both delay and
bandwidth. This specification follows the service specification
template described in [1].
Introduction
This document defines the requirements for network elements that
support guaranteed service. This memo is one of a series of
documents that specify the network element behavior required to
support various qualities of service in IP internetworks. Services
described in these documents are useful both in the global Internet
and private IP networks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
This document is based on the service specification template given in
[1]. Please refer to that document for definitions and additional
information about the specification of qualities of service within
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 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)
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 values
Show full document text