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
            <draft-ietf-diffserv-traffcon-format-00.txt>


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