[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 2212

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/