Internet Draft INTERNET DRAFT Kathleen Nichols Internet Engineering Task Force Cisco Systems Differentiated Services Working Group Brian Carpenter Expires August, 1999 IBM February, 1999 Format for Diffserv Working Group Traffic Conditioner DraftsStatus of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This draft outlines the format and required content for traffic conditioner drafts that are submitted to the Differentiated Services Working Group (Diff-Serv). This format is specified to expedite working group review of traffic conditioner submissions. The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC2119]. 1. Introduction A key component of the differentiated services architecture [RFC2474,RFC2475] is traffic conditioners. To expedite working group review of all drafts submitted on traffic conditioners, this document outlines the format and required content for such drafts. Each draft should describe only one traffic conditioner. Drafts describing traffic conditioners are to serve two main purposes: first, to describe a particular kind of traffic conditioner in a general way and, second, give guidelines for implementers of the traffic conditioner as to the minimum requirements and how to describe the features of the implementation. Each draft should be concise, but complete. In particular, each document should contain the information listed in the next section. 2. General format and content for traffic conditioner drafts Traffic conditioner drafts should have: 1) An abstract with the name of the traffic conditioner, a description of its general behavior and why it is useful. For example: "Shapers may delay packets of a behavior aggregate to enforce conformance to a traffic profile." 2) A labled block diagram of the traffic conditioner. The text version of the draft must include this. 3) Specify the required configuration parameters and monitoring data for the traffic conditioner as well as any additional non-required but externally visible parameters that may be configured. Specify the units or type of units that must be used. For example, a required statement could be: "The shaper's peak output rate MUST be configurable, though an implementation may specify either bytes per second or packets per second." An example of required monitoring data might read "It MUST be possible to monitor the number of packets that have arrived at the shaper and been dropped due to insufficient holding queue and it must also be possible to monitor the actual rate of shaped packets that have left the shaper." An example of additional optional configuration data is: "The size of the shaper's holding queue MAY be specified, in either packets or bytes. When this is not externally specified or for implementations where it is not possible to set this parameter, a default value of 2 times the configured rate in bytes per second times 0.1 should be used." 4) Describe the specific behavior of this traffic conditioner. In general, this section will be more verbose than the others. If there is a range of acceptable behavior, describe this as well as the manner in which a particular implementation should be documented. For example: "Shapers MAY be specified as operating on a per packet or a per byte basis. This MUST be made explicit. If shaping is done per packet, it MUST be made clear what packet size is assumed by the module or if this is a configurable parameter." 5) Describe the minimal functionality required for this type of traffic conditioner. For example "A shaper MUST at least allow a specification of peak rate and MUST provide a holding queue of at least 2 times this configured peak rate (in bytes) times 0.1. The output of the shaper MUST not exceed the configured peak rate for any time scale larger than the time to transmit an MTU-sized packet at the output line rate." 6) Describe the scaling properties of the described conditioner along with any security issues (for example, denial of service). 7) Document the assumptions, if any, made about the input traffic. That is, is there an assumed maximum rate or interarrival time for this traffic conditioner or can arrival traffic have arbitrary dynamic characteristics? 8) Describe one or more example services that could be offered with the described conditioner. 3. Security Considerations There may be security considerations associated with either a proposed traffic conditioner or an example service built with that traffic conditioner. These must be described in the draft. 4. References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. [RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", Internet RFC 2474, December 1998. [RFC2475] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and W. Weiss, "An Architecture for Differentiated Services", Internet RFC 2475, December 1998. 5. Authors' Addresses Kathleen Nichols Cisco Systems, Inc 170 W. Tasman Drive San Jose, CA 95134-1706 kmn@cisco.com Brian Carpenter IBM United Kingdom Laboratories MP 185, Hursley Park Winchester, Hampshire S021 2JN, UK