HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 03:21:46 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 27 Mar 1995 22:00:00 GMT ETag: "2edc88-1afb-2f773560" Accept-Ranges: bytes Content-Length: 6907 Connection: close Content-Type: text/plain Internet Engineering Task Force Integrated Services WG INTERNET-DRAFT S. Shenker/C. Partridge draft-ietf-intserv-guaranteed-svc-00.txt Xerox/BBN March, 1995 Expires: 9/1/95 Specification of Guaranteed Quality of Service 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 memo describes the expected behavior of a guaranteed service in the Internet. The memo follows the service template model of specifying per-network-element behavior, end-to-end behavior, and evaluation requirements. Introduction This memo is the third of a series of Service Definitions for quality of service in the Internet. This memo defines a guaranteed service. A guaranteed service provides mathematical guarantees that the end- to-end delay experienced by packets in a flow will not exceed a set limit, assuming that there are no hard failures in the intermediate nodes or packet routing changes within the lifetime of the flow (these issues are handled at higher levels of the protocol). The document uses the terms "network element" and "element" to mean any component of the internetwork which is capable of exercising QOS Shenker/Partridge Expires 9/1/95 [Page 1] INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-00.txt March, 1995 control over data flowing through it. Network elements might include routers, QOS-aware subnetworks, and end-note operating systems. [This draft is incomplete. Particularly, evaluation criteria are not supplied, and some of the math in this draft has yet to be fixed] 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). Motivation This service is designed for playback applications which are intolerant of any missed playback points and any applications with hard real-time requirements. This service is subject to admission control. Per-hop Service The level of service is characterized at each network element by a local rate, R, and buffer size, B. The network element must ensure that the service matches the "fluid model" of service at that same rate to within a sharp error bound. In other words, given a packet of size P, the delay should be (P+B)/R plus an error term. For instance, the error bound for Weighted Fair Queueing would be the MTU of the outbound link divided by the link bandwidth. Advertisements An element must advertise the delay bound and may advertise the error bound. The delay bound is the maximum time a packet will take passing through the network element. The end-to-end bound is computed using an additive composition rule, in which the delays at each hop are added. This bound must be advertised by a conformant network element. The error bound may optionally be advertised. Like the delay bound, the error bound composition rule is additive. Note that, by definition, the delay bound includes the error bound. So the range of delays through a conformant element will be between D-E and D, where D is the delay bound and E is the error bound. Shenker/Partridge Expires 9/1/95 [Page 2] INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-00.txt March, 1995 Traffic Specification and Policing Traffic is described by a token bucket filter (tbf), which is specified by a token bucket depth, b, and a token bucket rate, r. Policing is done at the edge of the network and at all source merge points. (A source merge point is where data from multiple different sources is merged into a single flow). Nonconforming packets are dropped. Invocation Service is invoked by specifying the traffic (TSpec) and service (RSpec). The TSpec is a token bucket depth, b, and a token bucket rate, r. Both r and b must be positive. The RSpec is a rate R, where R must be greater than or equal to r. The RSpec rate can be bigger than the TSpec rate because higher rates will reduce queueing delay. The value of B does not need to be specified because, except in cases where R is far larger than r, B must equal the token bucket depth, b, and thus is implicitly specified by the TSpec. Ordering The TSpec's are ordered as follows; both the token bucket depth and rate must be greater than or equal in order for the TSpec to be greater than or equal. The RSpec's are ordered on the size of R. Resulting Service The resulting end-to-end service is an assured bandwidth service which, when used by a policed flow, produces a delay bounded service. In fact, the service conforms to the fluid model to within the specified error bounds. Evaluation Criteria [To be developed. Briefly, one wants to confirm that a network element never violates a delay bound and test to see to what level of load (both rates and buffers) the element will continue to accept requests which it can guarantee. The major challenge is to characterize the traffic loads, since they must now be characterized in terms of both rate and bucket sizes] Shenker/Partridge Expires 9/1/95 [Page 3] INTERNET-DRAFT draft-ietf-intserv-guaranteed-svc-00.txt March, 1995 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@parc.xerox.com 415-812-4840 415-812-4471 (FAX) Craig Partridge BBN 2370 Amherst St Palo Alto CA 94306 craig@bbn.com Shenker/Partridge Expires 9/1/95 [Page 4]