Internet Engineering Task Force                   Integrated Services WG
INTERNET-DRAFT                                  S. Shenker/J. Wroclawski
draft-ietf-intserv-svc-template-01.txt                Xerox PARC/MIT LCS
                                                              June, 1995
                                                       Expires: 12/25/95

             Network Element Service Specification Template

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 (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).

   This draft is a product of the Integrated Services Working Group of
   the Internet Engineering Task Force.  Comments are solicited and
   should be addressed to the working group's mailing list at int- and/or the author(s).


      This document defines a format for specifying services provided by
      network elements, and available to applications, in a network
      which offers multiple classes of service. The document provides
      necessary context, including definitions, data formats, and
      interfaces; 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

Shenker/Wroclawski          Expires 12/25/95                    [Page 1]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

      criteria for elements providing the service, and examples of how
      the service might be implemented (by network elements) and used
      (by applications).


   This document defines the format used to specify the functionality of
   internetwork system components related to "Integrated Services"; the
   ability to provide multiple, dynamically selectable qualities of
   service to applications using the 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, as specified by this document, 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 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.

   The service definition does not describe the protocols or mechanisms
   used to establish state in the network elements for flows that use
   the described service, but may specify information which must be
   carried between end-nodes and network elements by those mechanisms.

   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.


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

Shenker/Wroclawski          Expires 12/25/95                    [Page 2]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

 o Quality of Service (QoS)

   In the context of this document, quality of service refers to the
   suitability of a packet delivery service for the needs of a
   particular application, as defined 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 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-aware" network element is one
   which offers one or more of the services defined according to the
   format of this document. Note that this definition does not by itself
   preclude QoS-aware network elements which meet performance goals
   purely through adequate provisioning, rather than active control

 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.

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

Shenker/Wroclawski          Expires 12/25/95                    [Page 3]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995


 o Service

   The word "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 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 a "service module"
   contained within the network element. A network element may and
   generally will contain more than one service module and hence offer
   more than one service.

      NOTE: The above defines a precise meaning for the word "service";
      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

Shenker/Wroclawski          Expires 12/25/95                    [Page 4]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

   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

 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.

   Several characterizations may be computed for a single candidate data
   flow. Conversely, characterizations are not mandatory, 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 specification of the traffic
   pattern which a flow expects to exhibit. 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 -expected- 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).

   Traffic specifications are most frequently created by the originator
   of the data flow.

Shenker/Wroclawski          Expires 12/25/95                    [Page 5]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

 o Service Request Specification (RSpec)

   A Service Request Specification, or RSpec, is a specification of the
   quality of service a flow desires from a network element. The form 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. Service request specifications may originate from either the
   sender or receiver(s) of a data flow.

 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 [xxx], ST-II [xxx] and Q.2931 [xxx].

 o Token Bucket

   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.

   Token buckets are further discussed in [xxx].

 o Token Bucket Filter

   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 not. The specific treatment
   accorded nonconforming packets is not specified in this definition;
   common actions are discarding of the packet or marking the packet in
   some fashion.

      NOTE: The definition of token bucket in this document does not

Shenker/Wroclawski          Expires 12/25/95                    [Page 6]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

      allow for token bucket filters with a "backing buffer" which
      queues packets that do not immediately pass through the filter.
      The intent is to cleanly distinguish the bufferless case from the
      buffer case through the use of different names; however this draft
      does not yet provide a definition for the second case.

 o Admission Control

   Admission control is the process of deciding whether a newly arriving
   request for service from a network element can be granted, or must be
   refused due to scarcity of resources. This action must be performed
   by any service which wishes to offer absolute quantitative bounds on
   overall performance. It is not necessary for services which provide
   only relative statements about performance, such as the Internet's
   current best-effort service. The precise criteria for making the
   admission control decision are a specific to each particular service.

 o Policing

   Policing is the set of actions triggered when a flow's actual data
   traffic characteristics exceed the expected values given in the
   flow's traffic specification. Services which require policing
   functions to operate correctly must specify the locations in the
   network where discrepancies are to be detected and the action to be
   taken when such discrepancies occur. Examples of such actions might
   include dropping packets, reshaping the traffic, or marking non-
   conforming traffic for later discard if necessary.

Data Format and Representation

   Each service module will import and export a variety of data
   according to its specific requirements. The service definition MUST
   specify the format of each such data item in an abstract manner. The
   information specified must be sufficient for the designer of a setup
   protocol to correctly select an appropriate concrete (packet) format
   for variables containing this data. At minimum, the following
   information must be given:

     - Type: whether the quantity is an enumeration, a numerical value,

     - Range: for numerical quantities, the minimum and maximum values

Shenker/Wroclawski          Expires 12/25/95                    [Page 7]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

     the quantity must be able to represent. For enumerated quantities,
     an estimate of the maximum number of items which may need be
     enumerated in the future, even if many of the values are currently

     - Precision: the precision with which a numerical quantity must be
     represented, and whether that precision is absolute (calling for an
     integer quantity) or a percentage of the value (allowing for a
     floating point quantity).

   The service definition SHOULD additionally specify a preferred
   concrete format for each data field, in the usual packet-layout
   format used in current Internet Standard documents. If the service
   definition contains these concrete definitions, they should be
   sufficiently complete and detailed to allow the service definition to
   be incorporated by reference into the specifications for setup
   protocols and other users of the specified data.

      NOTE: The wording above is intended to encourage the use of common
      data formats by all protocols carrying data related to a specific
      service, while not mandating this common format or infringing on
      the freedom of protocol specification designers to define data
      representations using alternative mechanisms such as ASN.1 or XDR.


   The service module conceptually interacts with other portions of the
   network element through a number of interfaces. These interfaces are
   documented in [xxx; the non-existent new IS - Overview RFC]. The
   service specification document should clearly define each the
   specific data, including formats, which moves across each conceptual
   interface, and ensure that the mapping between conceptual interfaces
   and the specific mechanisms of the service being defined are clear.

Specification Document Format

   The following portion of this document describes the layout and
   contents of a service specification. Each service specification
   document MUST contain the sections marked [required] below, in the
   order listed. Each document SHOULD contain each of the remaining
   sections in the list below, unless there is a compelling argument
   that the presence of the section is not beneficial. Additional
   material, including references, should be included at the end of the

Shenker/Wroclawski          Expires 12/25/95                    [Page 8]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995


 o Components

   The body of a service specification document incorporates the
   following sections:

     - Motivation [required]

     - Network Element Data Handling Requirements [required]

     - Invocation Information [required]

     - Exported Information [required]

     - Policing [required]

     - Ordering and Merging [required]

     - Resulting Service [required]

     - Guidelines for Implementors

     - Evaluation Criteria [required]

     - Examples of Implementation

     - Examples of Use

 o Motivation

   This section discusses why this service is being defined. It
   describes what kinds of applications might make use of this service,
   and why this service might be more appropriate for those applications
   than other possible choices. This section is for informational
   purposes only.

 o Network Element Data Handling Requirements

   This section contains a description of the QoS properties seen by
   data packets processed by a network element using this service. The
   description must clearly explain what variables are controlled, the

Shenker/Wroclawski          Expires 12/25/95                    [Page 9]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

   degree of control exercised, and what aspects of the service's
   handling model are fixed or assumed. Examples of degree of control
   information include "this property must be mathematically assured"
   and "this property should be met under most conditions". An example
   of a stated assumption is "this service is assumed to have extremely
   low packet loss; delay targets must be met using admission control
   rather than by discarding packets when overloaded".

   Requirements on packet handling SHOULD, when at all possible, be
   expressed as performance requirements rather than by specifying a a
   particular packet scheduling algorithm. The performance requirements
   might, for example, be a specification of the maximal packet delays
   or the minimal bandwidth share given to a flow.

   This section also specifies actions which the packet handling path is
   required to take to actively provide feedback to end-nodes about
   conditions at the network element. Such actions might include the
   explicitly generated congestion feedback, indicated either as bits
   set in the header of data packets or separate control messages sent.

   When writing this section of the service specification document, the
   authors' goal should be to specify the required behavior as precisely
   as necessary while still leaving adequate room for the implementation
   and architectural tradeoffs appropriate to different circumstances
   and classes of network elements. Successfully achieving this balance
   may require some care.

 o Invocation Information

   This section describes the set of parameters required by a service
   module to invoke the service, and a description of how the parameter
   values are used by the service module.  For example, a hypothetical
   "bounded delay" service might be described as accepting a request
   indicating a delay target for the network element and the set of
   packets subject to that delay target, and processing packets in the
   given set with a delay of the target value or less.

   Necessary invocation information for most services can be broken into
   two parts, the Traffic Specification (TSpec) and the Service Request
   Specification (RSpec). The TSpec gives characteristics of the data to
   be handled, while the Rspec specifies the properties desired from the
   service. For example, a service offering a mathematical bound on
   delay might accept a TSpec giving the traffic flow's bandwidth and
   burstiness specified as a Token Bucket, and an RSpec giving the
   maximum tolerable queueing delay. These two components of the
   invocation information should be specified separately and

Shenker/Wroclawski          Expires 12/25/95                   [Page 10]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

   independently, as they will often be generated and transported by
   different elements of the internetwork

   All quantitative information specifications in this section should
   follow the guidelines given in the Data Formats section of this
   document, above.

 o Exported Information and Characterization Parameters

   This section describes information which must be collected and
   exported by the service module. Exported information is available to
   other portions of the network element, and by extension to setup
   protocols, routing protocols, network management tools, and the like.

   Information exported by service modules may be used in several ways.
   For example, quantities such as the amount of link bandwidth
   dedicated to the service and the set of data flows currently
   receiving the service are appropriate pieces of information to make
   available as network management variables.

   A service definition may identify a particular subset of the
   information exported by a service module as characterization
   parameters. These characterization parameters may be used to compute
   or estimate the end-to-end behavior of a data flow traversing a
   concatenation of network service elements. A service which defines
   characterization parameters also specifies the characterizations they
   are used to generate and the composition functions used to generate
   the characterizations.

      NOTE: Characterization parameters are identified as such by virtue
      of being the inputs to a service's defined composition functions.
      Because characterization parameters are part of a service's
      overall exported data set, they are also available to other
      functions, such as network management. The discussion below
      relates soley to their use as characterization parameters, and is
      not intended to limit other uses.

   Characterization parameters may be relatively static quantities, such
   as the bandwidth available on a specific link, or relatively dynamic
   quantities, such as a running estimation of current packet delay.

   Support for a service's defined characterization parameters is
   mandatory. Any network element offering this service must be able to
   measure, compute, or, if allowed by the specification, estimate the
   service's characterization parameters. Service designers are
   encouraged to understand the implications of specifying

Shenker/Wroclawski          Expires 12/25/95                   [Page 11]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

   characterization parameters for a service, particularly with respect
   to not unduly restricting the choice of hardware and software
   architectures used to implement the network element.

   Characterization parameters are used by composing the values exported
   by each network element along a data flow's path according to a
   composition rule. For each parameter or set of parameters used to
   develop a characterization, the service specification must specify
   the composition rule to be used. These composition rules should
   result in characterizations that are independent of the order in
   which the element are composed; commutativity and associativity are
   sufficient but not necessary conditions for this.

   Characterization parameters are available through a general
   interface, and are provided in response to a request that would most
   likely come from either the setup protocol or the routing protocol.
   The issue of exactly how, or if, a specific protocol (e.g., RSVP)
   uses characterization parameters to generate characterizations should
   be described in the specification of that specific protocol.

   There is no requirement that setup and routing protocols use the
   characterization parameters supplied by service modules, and there is
   no guarantee that characterizations will be available to end-nodes
   desiring to use a QOS control service. Service designers targeting
   services for the global Internet may wish to ensure that a service is
   useful even in the absence of characterizations, and to exhibit such
   uses in the "Examples" sections of the service description document.

   Conversely, the availability of characterizations may be mandatory in
   certain circumstances, particularly for private IP networks providing
   tightly controlled qualities of service for specific applications.
   Service designers targeting this environment should particularly
   ensure that the service provides adequate characterization parameters
   and composition functions to fully meet the needs of target
   audiences. It may be appropriate to specify the same basic service
   with additional characterizations for meeting specific requirements
   beyond those of the global Internet.

   It may be useful to define "generic" characterization parameters not
   associated with any specific service.  These might include the
   speed-of-light latency of communication links (additive composition
   rule) and available link bandwidth (minimum composition rule).
   Eventually, these generic parameters should be defined in the
   Integrated Services overview document, and incorporated by reference
   in the Router Requirements document and the relevant service
   specification documents.

   Characterization parameters are named, so that protocols which

Shenker/Wroclawski          Expires 12/25/95                   [Page 12]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

   transport and use these parameters can uniquely identify them. The
   namespace is a two-level hierarchy: <service_name>.<parameter_name>;
   each of these elements is a numerical quantity. This same namespace
   is used to name the results of composition functions which are made
   available to end-nodes. The service specification author may also
   choose to name intermediate data which might be transported as part
   of a distributed composition function computation. The reason for
   assigning names to these data objects is to support a variety of
   styles for calculating the composition function, and to ensure that
   the end-nodes can clearly determine the meaning of data delivered to
   them as part of a characterization.

     - <Service Name> is a 16-bit number. The number space is broken
     into two regions. The region below 32768 (high bit 0) is managed by
     the IANA. Procedures for allocating service numbers in this region
     will be established by the IETF INT-SERV WG and the IANA. Services
     designed for public use should obtain a number from this space; the
     minimum requirement is a published RFC following the format
     described in this note.

     Numbers in the region above 32768 are reserved for experimental or
     private services. Service designers may allocate numbers from this
     space at random for local experimental use. A policy for global but
     temporary allocation of these numbers may be appropriate in the

     - <Parameter_name> is a 16-bit number assigned on a per-service
     basis.  Numbers are allocated by the author of the service
     specification document.

     [ Is 16 bits too big? Could be 8.8, or a non-byte split such as
     6.10 ]

   Service Number 0 (zero) is reserved for the "generic" parameters
   described above. Parameter numbers within this space are initially
   allocated by the INT-SERV WG, and may in the future be allocated by

   These <service_number>.<parameter_number> pairs should be used as
   last two levels of the MIB name when the parameters are made
   available to network management protocols.

Shenker/Wroclawski          Expires 12/25/95                   [Page 13]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

 o Policing

   This portion of the service description describes the nature of
   policing used to enforce adherence to a flow's Traffic Specification.
   The specification document must specify the following points

     - Expected policing action. This is the action taken when packets
     not conforming to the TSpec are detected.  Example actions include
     immediately dropping nonconforming packets, delaying these packets
     until they once again "fit" into the TSpec, or "marking"
     nonconforming packets in some way, to enable dropping them
     preferentially if a later network element in the marked packet's
     path should be overloaded.

     - Legality of alternative policing actions. The section must
     specify whether actions not specifically mentioned in
     specification's description of policing behavior are legal. For
     example, a service description which specifies that nonconforming
     packets are to be dropped should state whether an alternate action,
     such as delaying these packets, is acceptable.

     - Location of policing actions in the internetwork. The description
     of policing must specify where that policing is done. Possibilities
     include "at the edges of the network only", "at every hop", and
     "source merge points" (points where multiple data streams covered
     by a single resource reservation converge). The specification
     should clearly state requirements about topology information (for
     example "this is an edge node" or "this is a source merge point")
     which must be available from the setup protocol or another source.

     In this section the specification should also specify the legality
     of policing at additional points in the network, beyond those
     listed above.  This is important due to technical effects such as
     are described in the next paragraph.

     - Applicable additional technical considerations. If policing of
     data flows is required or legal at points other than the flow's
     first entry into the network, the service definition should
     describe any additional technical considerations which affect the

Shenker/Wroclawski          Expires 12/25/95                   [Page 14]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

     design of such policing. For example, many potential services will
     allow a data flow to become more bursty as it progresses through
     the network. If such a service allows policing at points other than
     the network edge, the traffic specification describing the flow
     will have to be modified from that given by the application to the
     network to account for this growing burstiness. Otherwise, it is
     likely that the flow will be overpoliced, with packets being
     penalized unnecessarily.

 o Ordering and Merging

   Ordering and merging come into play when a service receives several
   invocation requests covering the same data flow. As examples, this
   could occur if several receivers of a multicast data flow requested
   QOS services for that flow using the RSVP setup protocol, or if a
   flow was subject to both a statically installed permanent invocation
   request and a dynamic request from a resource setup protocol.

   In this situation the service module must be able to answer questions
   about the ordering between different invocation requests, and must be
   able to generate a single new invocation request which meets the
   requirements of all the original requesters. This new request is a
   "merged" request. It may be equal to one of the original requests, or
   it may be a newly computed request. Operationally, this is achieved
   by having the setup protocol ask the service module, given a set of
   requests R1...Rn, to compute an merged request which which results in
   service to the merged flow at least equivalent to that which any of
   the original requests would obtain for its corresponding unmerged
   flow. Hence, the merged invocation request represents an "upper
   bound" on the set of original invocation requests. This upper bound
   calculation must be performed by the service module because it is
   specific to a particular service.

   The calculated upper bound need not be a least upper bound, nor do
   the various network elements along the path need to all use the same
   choice of upper bound.  Any selection of invocation parameters Ru is
   compliant as long as it substitutable for each of the parameters
   R1...Rn from which it is calculated.  Intuitively, one set of
   parameters is substitutable for another if the resulting quality of
   service is at least as desirable to all applications. A precise
   definition of this "substitutable for" function; the ordering
   relation, MUST be specified in the service definition. (It may be
   specified as the empty set, in which case merging of dissimilar
   requests will not be allowed). A merging computation (upper bound
   calculation) MAY be given in the document as well.

Shenker/Wroclawski          Expires 12/25/95                   [Page 15]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

   Typically the ordering relation will be described separately for the
   service's TSpec and RSpec.  An invocation request is ordered with
   respect to another if and only if both its TSpec and its RSpec are
   similarly ordered with respect to each other.

   For TSpecs, the basic ordering relation is well defined.  TSpec A is
   substitutable for TSpec B if and only any flow that is compliant with
   TSpec B is also compliant with TSpec A. The service specification
   must explain how to compare two TSpecs to determine whether this is

   For RSpecs, the ordering relation is dependent on the service. RSpec
   A is substitutable for RSpec B if the quality of service invoked by
   RSpec A is at least as good as the quality of service invoked by
   RSpec B.  Since there is no precise mathematical description of
   "goodness" of quality of service, these ordering relations must be
   spelled out explicitly in the service description.

   This portion of the service description may also note any ordering
   relationships with other services which are strictly ordered with
   respect to the service being defined. Two services A and B are
   strictly ordered if it is always possible to substitute service B for
   the service A given a set of invocation parameters for service A.
   This ordering information may be used to allow network elements which
   provide service B to respond to requests for service A, even if the
   element does not provide service A directly. If the service
   specification describes such an inter-service ordering, it SHOULD
   also include a description of the invocation parameter mapping
   function for that ordering.

   Substitution of of one service for another in cases where they are
   not strictly ordered is currently not supported. A future version of
   this document may augment the service specification format to support
   this capability.

 o End-to-end Behavior

   This is a description of the behavior that results if all network
   elements along the path offer the same service, invoked with a
   defined set of parameters. This section should be as detailed as
   possible.  There are certain services where the end-to-end behavior
   is a highly nontrivial result of the concatenation of per-hop
   services; one purpose of this section is that such nontrivial results
   are not left unrevealed to the reader of this document.

   In private networks it will generally be the case that the required

Shenker/Wroclawski          Expires 12/25/95                   [Page 16]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

   end-to-end behavior is obtained by concatenation of network elements
   utilizing the same service and making significant use of

   In the global Internet, this will not always be true. End-to-end
   behaviors will frequently be obtained through a concatenation of
   network elements supporting different services, including in some
   cases elements which exercise no QoS control at all. Mechanisms to
   characterize end-to-end behavior in this circumstance are not fully
   established at this time. Future versions of this document may impose
   additional requirements on service specifications to facilitate
   inter-service composition.

      NOTE: This service specification template does not allow a service
      definition to -require- that a setup or invocation mechanism used
      with the service perform any function other than transport of
      invocation parameters to the network elements and signalling of
      errors generated by the network elements to the end nodes. A
      notable example of this is that service specification documents
      may not require or assume that characterizations defined in the
      specification are actually computed or presented to the end nodes.

      That point notwithstanding, the practical usefulness of a specific
      service may be highly dependent on the presence of some additional
      behavior in the networked system, such as the computation and
      presentation of characterizations to end-nodes or the reliable
      assurance that every network element in the path from sender to
      receivers supports the given service. Service specification
      authors are strongly encouraged to clearly explain the situation
      of their service in this regard. Statements such as:

        "The characterizations defined by this service serve as useful
        hints to the application. However, the service is specifically
        intended to be useful even if characterizations are not


        The usefulness of this service depends strongly on the delivery
        of both characterizations and the knowledge that all network
        elements on the path support the service. Requests for this
        service when characterizations are not available are likely to
        lead to incorrect or misleading results.

Shenker/Wroclawski          Expires 12/25/95                   [Page 17]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

      are appropriate. It may also be useful to consider this point in
      the "Examples of Use" section described below. ]

      NOTE: The possibility of adopting alternative wording for this
      document which allows a service to require that the invocation
      protocol support specific additional functionality or return an
      error is a topic open to discussion.

 o Guidelines for Implementors

   Many services may be defined in a manner which allows the range of
   behavior of a compliant network element to be rather broad.  This
   section should provide some guidance as to what range of behaviors
   the author of the service specification expects the community to
   desire in their implementations.  Because these guidelines depend on
   such imprecise and undefinable notions at "typical loads", these
   guidelines cannot be incorporated as part of a strict compliance
   test. Instead, they are for informational purposes only.

 o Evaluation Criteria

   Specific functional behaviors required of an implementation for
   conformance to a service specification is detailed in the previous
   sections.  However, the service specifications are intended to allow
   a wide range of implementations, and these implementations will
   differ in performance. This section describes tests that can be used
   to evaluate a network element's implementation of a given service.

   Implementors of service modules face a number of tradeoffs, and it is
   unlikely that a single implementation would be considered "best"
   under all circumstances. For instance, given the same service
   specification, an implementation appropriate for a low-speed link
   might target extremely high link utilization, while a different
   implementation might attempt to reduce non-loaded packet forwarding
   delay to the minimum at the expense of somewhat lower utilization of
   the link. The intention of the tests specified in this section should
   be to probe the tradeoffs made by the implementation designer, and to
   provide metrics useful to guide the customer's choice of an
   appropriate implementation for her needs.

   The tests specified in this section should be designed to operate on
   a single network element in isolation. This enables their use in a
   comparative rating system for QoS-aware network elements. In
   production networks, users will be more concerned with the end-to-end

Shenker/Wroclawski          Expires 12/25/95                   [Page 18]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

   behavior obtained, which will depend not just on the particular
   network elements selected, but also on other factors such as the
   setup protocol and the bandwidth of the links. Some user-relevant
   performance factors are the rate of admission control rejections, the
   range of services offered, and the packet delay and drop rates in the
   various service classes.  The form of any standardized end-to-end
   metrics and measurement tools for integrated service internetworks is
   not specified by this document or by service specification document
   which follow the format given here.

 o Examples of Implementation

   This section describes example instantiations of the service.  Often
   these will just be references to the literature, or brief sketches of
   how the service could be implemented.  The purposes of the section
   are to to provide a more concrete sense of the service being
   specified and to provide pointers and hints to aid the implementor.
   However, the descriptions in this section are specifically not
   intended to exclude other implementation strategies.

 o Examples of Use

   In order to provide more a more concrete sense of how this service
   might be used, this section describes some example uses of the
   service, for informational purposes only.  The examples here are not
   meant to be exhaustive, and do not exclude in any way other uses of
   the service.

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/Wroclawski          Expires 12/25/95                   [Page 19]

INTERNET-DRAFT   draft-ietf-intserv-svc-template-01.txt       June, 1995

   415-812-4471 (FAX)

   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139
   617-253-2673 (FAX)

Shenker/Wroclawski          Expires 12/25/95                   [Page 20]