Internet Engineering Task Force. Integrated Services WG. INTERNET-DRAFT.
Scott Shenker draft-ietf-intserv-svc-template-00.txt. Xerox PARC. March, 1995.
Internet Engineering Task Force INTERNET-DRAFT draft-ietf-intserv-svc-template-00.txt
Integrated Services WG Scott Shenker 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
[email protected] 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-withadvertising 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
[email protected] 415-812-4840 415-812-4471 (FAX)
Shenker
Expires 9/1/95
[Page 4]
