rfc2216.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                         S. Shenker
Request for Comments: 2216                                 J. Wroclawski
Category: Informational                               Xerox PARC/MIT LCS
                                                          September 1997


             Network Element Service Specification Template


Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   This document defines a framework for specifying services provided by
   network elements, and available to applications, in an internetwork
   which offers multiple qualities of service. The document first
   provides some necessary context -- including relevant definitions and
   suggested data formats -- and then specifies a "template" which
   service specification documents should follow. The specification
   template includes per-element requirements such as the service's
   packet handling behavior, parameters required and made available by
   the service, traffic specification and policing requirements, and
   traffic ordering relationships.  It also includes evaluation criteria
   for elements providing the service, and examples of how the service
   might be implemented (by network elements) and used (by
   applications).

Introduction

   This document defines the framework used to specify the functionality
   of internetwork system components which support the the ability to
   provide multiple, dynamically selectable qualities of service to
   applications using an internetwork. The behavior of individual
   routers and subnetworks is captured as a set of "services", some or
   all of which may be offered by each element. The concatenation of
   these services along the end-to-end data paths used by an application
   provides overall quality of service control.

   The definition of a service states what is required of a router (or,
   more generally, any network element; a router, switch, subnet, etc.)
   which supports a particular service. The service definition also






Shenker & Wroclawski         Informational                      [Page 1]

RFC 2216            Network Element Service Template      September 1997


   specifies parameters used to invoke the service, the relationship
   between those parameters and the service delivered, and the end-to-
   end behavior obtained by concatenating several instances of the
   service.

   Each service definition also specifies the interface between that
   service and the environment. This includes the parameters needed to
   invoke the service, informational parameters which the service must
   make available for use by setup, routing, and management mechanisms,
   and information which should be carried between end-nodes and network
   elements by those mechanisms in order to achieve the desired end-to-
   end behavior. However, a service definition does not describe the
   specific protocols or mechanisms used to establish state in the
   network elements for flows that use the described service.

   Services defined following the guidelines of this document are
   intended for use both within the global Internet and private IP
   networks. In certain cases a concatenation of network element
   services may be used to provide a range of end-to-end behaviors, some
   more suited to a decentralized internet and some more appropriate for
   a tightly managed private network. This document points out places
   where such distinction may be appropriate.

   This document is comprised of three parts.  The first defines some
   terms used both in this document and in the various service
   specification documents.  The second discusses data formats and
   representations.  The third portion of the document describes the
   various components of the service specification template.

Definitions

   The following terms are used throughout this document. Service
   specification documents should employ the same terms to express these
   concepts.

 o Quality of Service (QoS)

   In the context of this document, quality of service refers to the
   nature of the packet delivery service provided, as described by
   parameters such as achieved bandwidth, packet delay, and packet loss
   rates. Traditionally, the Internet has offered a single quality of
   service, best-effort delivery, with available bandwidth and delay
   characteristics dependent on instantaneous load. Control over the
   quality of service seen by applications is exercised by adequate
   provisioning of the network infrastructure. In contrast, a network
   with dynamically controllable quality of service allows individual
   application sessions to request network packet delivery
   characteristics according to their perceived needs, and may provide



Shenker & Wroclawski         Informational                      [Page 2]

RFC 2216            Network Element Service Template      September 1997


   different qualities of service to different applications. It should
   be understood that there is a range of useful possibilities between
   the two endpoints of providing no dynamic QoS control at all and
   providing extremely precise and accurate control of QoS parameters.

 o Network Element

   A "Network Element" (or the equivalent shorter form "Element"), is
   any component of an internetwork which directly handles data packets
   and thus is potentially capable of exercising QoS control over data
   flowing through it. Network elements include routers, subnetworks,
   and end-node operating systems. A QoS-capable network element is one
   which offers one or more of the services defined according to the
   rules given in this document.  Note that this definition, by itself,
   preclude QoS-capable network elements that meet performance goals
   purely through adequate provisioning rather than active admission and
   traffic control mechanisms.  A "QoS-aware" network element is one
   which supports the interfaces (described below) required by the
   service definitions.  Thus, a QoS-aware network element need not
   actually offer any of the services defined according to the format of
   this document; it merely needs to know how to deny service requests.

 o Flow

   For the purposes of this document a flow is a set of packets
   traversing a network element all of which are covered by the same
   request for control of quality of service. At a given network element
   a flow may consist of the packets from a single application session,
   or it may be an aggregation comprising the combined data traffic from
   a number of application sessions.

      NOTE: this definition of a flow is different from that used in
      IPv6, where a flow is defined as those packets with the same
      source address and FlowID.

   Mechanisms used to associate a request for quality of service control
   with the packets covered by that request are beyond the scope of this
   document.

 o Service

   The phrase "service" or "QoS Control Service" describes a named,
   coordinated set of QoS control capabilities provided by a single
   network element.  The definition of a service includes a
   specification of the functions to be performed by the network






Shenker & Wroclawski         Informational                      [Page 3]

RFC 2216            Network Element Service Template      September 1997


   element, the information required by the element to perform these
   functions, and the information made available by the element to other
   elements of the system.  A service is conceptually implemented within
   the "service module" contained within the network element.

      NOTE: The above defines a precise meaning for the word "service".
      Service is a word which has a variety of meanings throughout the
      networking community;  the definition of "service" given here
      refers specifically to the actions and responses of a single
      network element such as a router or subnet. This contrasts with
      the more end-to-end oriented definition of the same word seen in
      some other networking contexts.

 o Behavior

   A "behavior" is the QoS-related end-to-end performance seen by an
   application session. This behavior is the end result of composing the
   services offered by each network element along the path of the
   application's data flow.

   When each network element along a data flow path offers the same
   service, it is frequently possible to explain the resulting end-to-
   end behavior in a straightforward fashion. The behavior of a data
   flow path comprised of elements using different services is more
   complicated, and may in fact be undefined. A future version of this
   document may impose additional requirements on the service
   specification relating to multi-service concatenation.

 o Characterization

   A characterization is a computed approximation of the actual end-to-
   end behavior which would be seen by a flow requesting specific QoS
   services from the network.  By providing additional information to
   the end-nodes before a flow is established, characterizations assist
   the end-nodes in choosing the services to be requested from the
   network.

 o Characterization Parameters

   Characterizations are computed from a set of characterization
   parameters provided by each network element on the flow's path, and a
   composition function which computes the end-to-end characterization
   from those parameters. The composition function may in practice be
   executed in a distributed fashion by the setup or routing protocol,
   or the characterization parameters may be gathered to a single point
   and the characterization computed at that point.





Shenker & Wroclawski         Informational                      [Page 4]

RFC 2216            Network Element Service Template      September 1997


   Several characterizations may be computed for a single candidate data
   flow. Conversely, a service may provide no characterizations, and
   under some conditions no characterizations may be available to the
   end-nodes requesting QoS services.

 o Composition Function

   A composition function accepts characterization parameters as input
   and computes a characterization, as described above.

 o Traffic Specification (TSpec)

   A Traffic Specification, or TSpec, is a description of the traffic
   pattern for which service is being requested. In general, the TSpec
   forms one side of a "contract" between the data flow and the service.
   Once a service request is accepted, the service module has agreed to
   provide a specific QoS as long as the flow's data traffic continues
   to be accurately described by the TSpec.

   As examples, this specification might take the form of a token bucket
   filter (defined below) or an upper bound on the peak rate. Note that
   the traffic specification specifies the flow's *allowed* traffic
   pattern, not the flows *actual* traffic pattern. The behavior of a
   service when a flow's actual traffic does not conform to the traffic
   specification must be defined by the service (see "Policing" below).

 o Service Request Specification (RSpec)

   A Service Request Specification, or RSpec, is a specification of the
   quality of service a flow wishes to request from a network element.
   The contents of a service request specification is highly specific to
   a particular service. As examples, these specifications might contain
   information about bandwidth allocated to the flow, maximum delays, or
   packet loss rates.

 o Setup Protocol

   A setup protocol is used to carry QoS-related information from the
   end-nodes requesting QoS control to network elements which must
   exercise that control, and to install and maintain to required QoS
   control state in those network elements.  A setup protocol may also
   be used to collect QoS-related information from interior network
   elements along an application's data flow path for ultimate delivery
   to end nodes. Examples of protocols which perform setup functions are
   RSVP [RFC 2205], ST-II [RFC 1819], and Q.2931.






Shenker & Wroclawski         Informational                      [Page 5]

RFC 2216            Network Element Service Template      September 1997


   Note that other mechanisms, such as network management protocols, may
   also perform this function. The phrase "setup protocol"
   conventionally refers to a protocol with this function as its primary
   purpose.

 o Token Bucket

   A Token Bucket is a particular form of traffic specification
   consisting of a "token rate" r and a "bucket size" b. Essentially,
   the r parameter specifies the continually sustainable data rate,
   while the b parameter specifies the extent to which the data rate can
   exceed the sustainable level for short periods of time.  More
   specifically, the traffic must obey the rule that over all time
   periods, the amount of data sent cannot exceed rT+b, where T is the
   length of the time period.

   Token buckets are further discussed in [PARTRIDGE].

 o Token Bucket Filter

   A Token Bucket Filter is a filtering or policing function which
   differentiates those packets in a traffic flow which conform to a
   particular token bucket specification from those packets which do