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 Drafts
	    


Status 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