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]