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

Versions: 00 01 02 RFC 2216

Internet Engineering Task Force                   Integrated Services WG
INTERNET-DRAFT                                             Scott Shenker
draft-ietf-intserv-svc-template-00.txt                        Xerox PARC
                                                             March, 1995
                                                         Expires: 9/1/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 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 document defines a format for specifying services provided by
   network elements, and available to applications, in an integrated
   service network. The specification template includes per-element
   information such as scheduling and admission control requirements,
   end-to-end information such as composition rules, and evaluation
   criteria for elements providing the service.

Introduction

   This document presents a format for describing services available
   within an integrated services network. Each service incorporated into
   the service model must be described.  These service descriptions
   define what is required of a router (or, more generally, a network
   element) to support a particular service.  They do not describe the
   behavior of the protocols or mechanisms used to setup flows that use
   the service, except to describe formal interactions between the
   network elements and the setup mechanisms.



Shenker                      Expires 9/1/95                     [Page 1]


INTERNET-DRAFT   draft-ietf-intserv-svc-template-00.txt      March, 1995


   The document uses the terms "network element" and "element" to mean
   any component of the internetwork which is capable of exercising QOS
   control over data flowing through it. Network elements might include
   routers, QOS-aware subnetworks, and end-note operating systems.

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

Template Format

   The following multipart template will be used for these service
   descriptions.  In what follows, we will describe the content of each
   of the parts of this template.  Note that while the presence or
   absence of admission control is part of the service description, the
   nature of the admission control algorithm (if applicable) is not.

 o Motivation

   This describes the intended usage of the service, for informational
   purposes only.

 o Per-hop Service

   This is a description of how the packets are handled.  These are
   requirements on, for example, maximal packet delays or bandwidth
   shares given to a flow.  This also includes issues of feedback (as in
   explicit congestion feedback, where bits in the header must be set or
   control messages sent).  This portion of the service description is
   the most central aspect (at least for most services) and will require
   the most care in describing.

 o Advertisements

   This is a description of how the services provided by the network
   element are characterized.  In particular, this section describes
   what information the network element is obliged to give the setup
   protocols or mechanisms.

   Note that this section is not tied directly to the one-pass-with-
   advertising proposal (OPWA) made to the RSVP WG (although OPWA does
   use it); any service which wants its behavior characterized must make
   these quantities available.  These characterizations are not
   necessarily the same parameters that were used to invoke the service.
   These advertisements are provided in response from a request (most
   likely from either the set-up protocol or the routing protocol).
   These quantities can either be mandatory (any element offering this



Shenker                      Expires 9/1/95                     [Page 2]


INTERNET-DRAFT   draft-ietf-intserv-svc-template-00.txt      March, 1995


   service must be able to provide this characterization) or optional.
   It is assumed that these characterizations are composed along the
   path, and part of the specification of an advertisement is the
   composition rule.  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.

   The issue of exactly how advertisements are used in a specific
   protocol (e.g., RSVP) is another issue that is best described in the
   context of that specific protocol.  However, the interface to the
   service module should be flexible enough to allow the request of any
   and all advertised numbers.

 o Traffic Specification and Policing

   For many kinds of network service, flows must provide a specification
   of their traffic to the network before receiving service.  This
   portion of the service description must both describe the nature of
   the traffic specification (e.g., a token bucket filter) and the
   nature of policing (e.g., policing could either drop or delay
   nonconforming packets) used to enforce adherence to that traffic
   specification.  The description of policing must also describe where
   that policing is done, which might for example be at the edge of the
   network only, at every hop, or at all merge points (considering the
   edge a merge point).  The abstractions available to the service
   module from the set-up protocol about the topology must include these
   notions of edge and merge points.

 o Invocation

   This describes the set of parameters handed to the network element's
   service control module to invoke the service, and the mapping between
   those parameter values and the resulting service.  For example, one
   might hand the element a delay target and have the flow mapped into
   the bounded delay class with the bound closest to that target.  This
   portion of the service description will eventually describe the
   detailed layout of the bits in the service invocation (but not in
   this draft).

   The invocation for all the services listed so far can be broken into
   two parts, the traffic descriptor (which we will call the TSpec) and
   the service request descriptor (which we will call the RSpec).  For
   instance, the TSpec might be token bucket filter parameters and the
   RSpec the level of Predictive service desired.






Shenker                      Expires 9/1/95                     [Page 3]


INTERNET-DRAFT   draft-ietf-intserv-svc-template-00.txt      March, 1995


 o Ordering

   The service module must be able to answer questions about the
   ordering between different service requests.  This is used when
   merging service requests from different receivers.  One service
   request is greater than or equal to another if and only if both its
   TSpec and its RSpec are greater than or equal.

   This portion of the service description should also note any ordering
   relationships with other services.  Of course, this portion of the
   service description must be updated as new services are added to
   ensure that the entries are complete and consistent.

 o Resulting Service

   This is a description of the service that results if all network
   elements along the path offer the same service.  This is for
   informational purposes only.  Its inclusion does not imply that the
   common case is that all elements offer the same service end-to-end.
   Rather, there are some services, Guaranteed being the most notable
   example, where the resulting delay bound is a highly nontrivial
   result of the concatenation of per-hop services; the purpose of this
   entry in the template is so that such nontrivial results are not left
   unrevealed to the reader of this document.

 o Evaluation Criteria

   This section describes how to evaluate how well an element implements
   the particular service.  The focus of this section is on tests that
   can be used to test an element's implementation of a given service.

Security Considerations

   Security considerations are not discussed in this memo.

Author's  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)







Shenker                      Expires 9/1/95                     [Page 4]


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