Internet Engineering Task Force Integrated Services WG
INTERNET-DRAFT S. Shenker/C. Partridge
draft-ietf-intserv-guaranteed-svc-00.txt Xerox/BBN
March, 1995
Expires: 9/1/95
Specification of Guaranteed Quality of Service
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This memo describes the expected behavior of a guaranteed service in
the Internet. The memo follows the service template model of
specifying per-network-element behavior, end-to-end behavior, and
evaluation requirements.
Introduction
This memo is the third of a series of Service Definitions for quality
of service in the Internet. This memo defines a guaranteed service.
A guaranteed service provides mathematical guarantees that the end-
to-end delay experienced by packets in a flow will not exceed a set
limit, assuming that there are no hard failures in the intermediate
nodes or packet routing changes within the lifetime of the flow
(these issues are handled at higher levels of the protocol).
The document uses the terms "network element" and "element" to mean
any component of the internetwork which is capable of exercising QOS
Shenker/Partridge Expires 9/1/95 [Page 1]
INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-00.txt March, 1995
control over data flowing through it. Network elements might include
routers, QOS-aware subnetworks, and end-note operating systems.
[This draft is incomplete. Particularly, evaluation criteria are not
supplied, and some of the math in this draft has yet to be fixed]
This document is a product of the Integrated Services working group
within the Internet Engineering Task Force. Comments are solicited
and should be addressed to the working group's mailing list at
intserv@isi.edu and/or the author(s).
Motivation
This service is designed for playback applications which are
intolerant of any missed playback points and any applications with
hard real-time requirements. This service is subject to admission
control.
Per-hop Service
The level of service is characterized at each network element by a
local rate, R, and buffer size, B. The network element must ensure
that the service matches the "fluid model" of service at that same
rate to within a sharp error bound. In other words, given a packet
of size P, the delay should be (P+B)/R plus an error term. For
instance, the error bound for Weighted Fair Queueing would be the MTU
of the outbound link divided by the link bandwidth.
Advertisements
An element must advertise the delay bound and may advertise the error
bound.
The delay bound is the maximum time a packet will take passing
through the network element. The end-to-end bound is computed using
an additive composition rule, in which the delays at each hop are
added. This bound must be advertised by a conformant network
element.
The error bound may optionally be advertised. Like the delay bound,
the error bound composition rule is additive.
Note that, by definition, the delay bound includes the error bound.
So the range of delays through a conformant element will be between
D-E and D, where D is the delay bound and E is the error bound.
Shenker/Partridge Expires 9/1/95 [Page 2]
INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-00.txt March, 1995
Traffic Specification and Policing
Traffic is described by a token bucket filter (tbf), which is
specified by a token bucket depth, b, and a token bucket rate, r.
Policing is done at the edge of the network and at all source merge
points. (A source merge point is where data from multiple different
sources is merged into a single flow). Nonconforming packets are
dropped.
Invocation
Service is invoked by specifying the traffic (TSpec) and service
(RSpec).
The TSpec is a token bucket depth, b, and a token bucket rate, r.
Both r and b must be positive.
The RSpec is a rate R, where R must be greater than or equal to r.
The RSpec rate can be bigger than the TSpec rate because higher rates
will reduce queueing delay. The value of B does not need to be
specified because, except in cases where R is far larger than r, B
must equal the token bucket depth, b, and thus is implicitly
specified by the TSpec.
Ordering
The TSpec's are ordered as follows; both the token bucket depth and
rate must be greater than or equal in order for the TSpec to be
greater than or equal. The RSpec's are ordered on the size of R.
Resulting Service
The resulting end-to-end service is an assured bandwidth service
which, when used by a policed flow, produces a delay bounded service.
In fact, the service conforms to the fluid model to within the
specified error bounds.
Evaluation Criteria
[To be developed. Briefly, one wants to confirm that a network
element never violates a delay bound and test to see to what level of
load (both rates and buffers) the element will continue to accept
requests which it can guarantee. The major challenge is to
characterize the traffic loads, since they must now be characterized
in terms of both rate and bucket sizes]
Shenker/Partridge Expires 9/1/95 [Page 3]
INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-00.txt March, 1995
Security Considerations
Security considerations are not discussed in this memo.
Authors' Address:
Scott Shenker
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94304-1314
shenker@parc.xerox.com
415-812-4840
415-812-4471 (FAX)
Craig Partridge
BBN
2370 Amherst St
Palo Alto CA 94306
craig@bbn.com
Shenker/Partridge Expires 9/1/95 [Page 4]
