Specification of Guaranteed Quality of Service
RFC 2212

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

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