rfc2212.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/4 页

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
      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

   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
   used by a policed flow, produces a delay-bounded service with no
   queueing loss for all conforming datagrams (assuming no failure of
   network components or changes in routing during the life of the
   flow).

   The end-to-end behavior conforms to the fluid model (described under
   Network Element Data Handling below) in that the delivered queueing
   delays do not exceed the fluid delays by more than the specified
   error bounds.  More precisely, the end-to-end delay bound is [(b-
   M)/R*(p-R)/(p-r)]+(M+Ctot)/R+Dtot for p>R>=r, and (M+Ctot)/R+Dtot for
   r<=p<=R, (where b, r, p, M, R, Ctot, and Dtot are defined later in
   this document).

      NOTE: While the per-hop error terms needed to compute the end-to-
      end delays are exported by the service module (see Exported
      Information below), the mechanisms needed to collect per-hop
      bounds and make the end-to-end quantities Ctot and Dtot known to
      the applications are not described in this specification.  These
      functions are provided by reservation setup protocols, routing
      protocols or other network management functions and are outside
      the scope of this document.

   The maximum end-to-end queueing delay (as characterized by Ctot and
   Dtot) and bandwidth (characterized by R) provided along a path will
   be stable.  That is, they will not change as long as the end-to-end
   path does not change.

   Guaranteed service does not control the minimal or average delay of
   datagrams, merely the maximal queueing delay.  Furthermore, to
   compute the maximum delay a datagram will experience, the latency of
   the path MUST be determined and added to the guaranteed queueing
   delay.  (However, as noted below, a conservative bound of the latency
   can be computed by observing the delay experienced by any one
   packet).

   This service is subject to admission control.



Shenker, et. al.            Standards Track                     [Page 3]

RFC 2212             Guaranteed Quality of Service        September 1997


Motivation

   Guaranteed service guarantees that datagrams will arrive within the
   guaranteed delivery time and will not be discarded due to queue
   overflows, provided the flow's traffic stays within its specified
   traffic parameters.  This service is intended for applications which
   need a firm guarantee that a datagram will arrive no later than a
   certain time after it was transmitted by its source.  For example,
   some audio and video "play-back" applications are intolerant of any
   datagram arriving after their play-back time.  Applications that have
   hard real-time requirements will also require guaranteed service.

   This service does not attempt to minimize the jitter (the difference
   between the minimal and maximal datagram delays); it merely controls
   the maximal queueing delay.  Because the guaranteed delay bound is a
   firm one, the delay has to be set large enough to cover extremely
   rare cases of long queueing delays.  Several studies have shown that
   the actual delay for the vast majority of datagrams can be far lower
   than the guaranteed delay.  Therefore, authors of playback
   applications should note that datagrams will often arrive far earlier
   than the delivery deadline and will have to be buffered at the
   receiving system until it is time for the application to process
   them.

   This service represents one extreme end of delay control for
   networks.  Most other services providing delay control provide much
   weaker assurances about the resulting delays.  In order to provide
   this high level of assurance, guaranteed service is typically only
   useful if provided by every network element along the path (i.e. by
   both routers and the links that interconnect the routers).  Moreover,
   as described in the Exported Information section, effective provision
   and use of the service requires that the set-up protocol or other
   mechanism used to request service provides service characterizations
   to intermediate routers and to the endpoints.

Network Element Data Handling Requirements

   The network element MUST ensure that the service approximates the
   "fluid model" of service.  The fluid model at service rate R is
   essentially the service that would be provided by a dedicated wire of
   bandwidth R between the source and receiver.  Thus, in the fluid
   model of service at a fixed rate R, the flow's service is completely
   independent of that of any other flow.








Shenker, et. al.            Standards Track                     [Page 4]

RFC 2212             Guaranteed Quality of Service        September 1997


   The flow's level of service is characterized at each network element
   by a bandwidth (or service rate) R and a buffer size B.  R represents
   the share of the link's bandwidth the flow is entitled to and B
   represents the buffer space in the network element that the flow may
   consume.  The network element MUST ensure that its service matches
   the fluid model at that same rate to within a sharp error bound.

   The definition of guaranteed service relies on the result that the
   fluid delay of a flow obeying a token bucket (r,b) and being served
   by a line with bandwidth R is bounded by b/R as long as R is no less
   than r.  Guaranteed service with a service rate R, where now R is a
   share of bandwidth rather than the bandwidth of a dedicated line,
   approximates this behavior.

   Consequently, the network element MUST ensure that the queueing delay
   of any datagram be less than b/R+C/R+D, where C and D describe the
   maximal local deviation away from the fluid model.  It is important
   to emphasize that C and D are maximums.  So, for instance, if an
   implementation has occasional gaps in service (perhaps due to
   processing routing updates), D needs to be large enough to account
   for the time a datagram may lose during the gap in service.  (C and D
   are described in more detail in the section on Exported Information).

      NOTE: Strictly speaking, this memo requires only that the service
      a flow receives is never worse than it would receive under this
      approximation of the fluid model.  It is perfectly acceptable to
      give better service.  For instance, if a flow is currently not
      using its share, R, algorithms such as Weighted Fair Queueing that
      temporarily give other flows the unused bandwidth, are perfectly
      acceptable (indeed, are encouraged).

   Links are not permitted to fragment datagrams as part of guaranteed
   service.  Datagrams larger than the MTU of the link MUST be policed
   as nonconformant which means that they will be policed according to
   the rules described in the Policing section below.

Invocation Information

   Guaranteed service is invoked by specifying the traffic (TSpec) and
   the desired service (RSpec) to the network element.  A service
   request for an existing flow that has a new TSpec and/or RSpec SHOULD
   be treated as a new invocation, in the sense that admission control
   SHOULD be reapplied to the flow.  Flows that reduce their TSpec
   and/or their RSpec (i.e., their new TSpec/RSpec is strictly smaller
   than the old TSpec/RSpec according to the ordering rules described in
   the section on Ordering below) SHOULD never be denied service.