One document matched: draft-ietf-diffserv-new-terms-00.txt

Diffserv Working Group                                   Dan Grossman
Internet Draft                                           Motorola, Inc.
Expires: April 2000 draft-ietf-diffserv-new-terms-00.txt
                                                         October, 1999

                      New Terminology for Diffserv

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.

   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 captures Diffserv working group agreements concerning new
   and improved terminology.  It is intended as a living document for
   use by the Diffserv working group, and especially for use of authors
   of Diffserv drafts.  It is expected that the terminology in this memo
   will be incorporated into the existing Diffserv RFCs when they are
   updated.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1.  Introduction As the Diffserv work has evolved, there have been
   several cases where terminology has needed to be created or the
   definitions in [1] and [2] have needed to be refined.   This memo was
   created to capture and test group agreements on terminology, rather
   than attempting to revise the base RFCs and recycle them at proposed
   standard.  Diffserv authors are encouraged to use the new terminology

Grossman                                                        [Page 1]

draft-ietf-diffserv-new-terms-00.txt                        October 1999

   whereever appropriate.

   [Author's note:  the following represents in part the Author's
   understanding of  the agreements.  However, in some cases, the Author
   found it necessary to elaborate or expand.  The Author has also
   polled the Diffserv chairs and incorporated their recollection into
   this memo.  Every attempt will be made to refine this memo based on
   comments from the group. No claim is made that the ¸00 version of
   this memo represents a group consensus.)

2. Terminology related to Service Level Agreements (SLAs) The Diffserv
   Architecture [2] uses the term "Service Level Agreement" (SLA) to
   describe the "service contract... that specifies the forwarding
   service a customer should receive".  The SLA may include traffic
   conditioning rules which (at least  in part) constitute a Traffic
   Conditioning Agreement (TCA).  A TCA is "an agreement specifying
   classifier rules and any corresponding traffic profiles and metering,
   marking, discarding and/or shaping rules which are to apply...."

   As work progressed in Diffserv, it came to be believed that the
   notion of an "agreement" implied considerations that were of a
   pricing, contractual or other  business nature, as well as those that
   were strictly technical.  There also  could be other technical
   considerations in such an agreement (e.g., service availability)
   which are not addressed by Diffserv.  It was therefore agreed that
   the notions of SLAs and TCAs would be taken to represent the broader
   context, and that new terminology would be used to describe those
   elements of service and traffic conditioning that are addressed by
   Diffserv.

     - A Service Level Specfication (SLS) is a set of parameters and
     their values which together define the service offered to a traffic
     stream by a DS domain.

     - A Traffic Conditioning Specification (TCS) is a set of parameters
     and their values which together specify a set of classfier rules
     and a traffic profile.  A TCS is an integral element of an SLS.

Note that the definition of "Traffic stream" is unchanged from RFC 2475.
A traffic stream can be an individual microflow or a group of microflows
(i.e., in a source or destination  DS domain) or  it can be a BA.  Thus,
an SLS may apply in the source or destination DS domain to a single
microflow or group of microflows, as well as to a BA in any DS domain.

2. PHB Group RFC 2475 deines a PHB group to be:
     "a set of one or more PHBs that can only be meaningfully specified
     and implemented simultaneously, due to a common constraint applying
     to all PHBs in the set such as a queue servicing or queue

Grossman                                                        [Page 2]

draft-ietf-diffserv-new-terms-00.txt                        October 1999

     management policy. A PHB group provides a service building block
     that allows a set of related forwarding behaviors to be specified
     together (e.g., four dropping priorities).  A single PHB is a
     special case of a PHB group."

RFC 2497 [3] is entitled "Assured Forwarding PHB Group", and uses the
term AF PHB group consistently in discussing the set of twelve AF PHBs.
However, this usage is not consistent with RFC 2475.  There is no common
constraint which applies to BAs having different AF classes.  Indeed,
packets having different AF classes must be forwarded independently.
Therefore,  each of the four AF classes constitutes a separate PHB
group, each having three PHBs corresponding to three drop precedences.

A new definition is thus needed to describe a set of related PHB groups.

     PHB Group Family: a set of two or more PHB groups which are
     specified together and have similar relationships among their
     constituent PHBs, but which lack any common constraint.  A PHB
     group family provides a service building block that allows a set of
     related PHB groups to be specified together (e.g., three classes of
     PHB groups).

3. Definition of the DS Field Diffserv uses six bits of the IPV4 or IPV6
header to convey the Diffserv Codepoint (DSCP), which selects a PHB.
RFC 2474 attempts to rename the TOS octet of the IPV4 header, and
Traffic Class octet of the IPV6 header, respectively, to the DS field.
The DS Field has a six bit Diffserv Codepoint and two "currently unused
bits".

Several participants in the Diffserv working group have pointed out that
this leads to inconsistencies.  In particular, the CU bits of the DS
Field have not been assigned to Diffserv (and in fact are being used by
RFC 2481 [] for explicit congestion notification).   A DSCP is,
depending on context, either an encoding which selects a PHB or a sub-
field in the DS field which contains that encoding.

[Author's note:  there was no working group consensus on this subject.
This is my attempt at an intellectually satisfying solution, albeit one
that will require readers to switch between two sets of terminology
until RFC 2474 can be updated]

For use in future drafts, including the next update to RFC 2474,  the
following definitions should apply:
     - the Differentiated Services Field (DSField) is the six most
     significant bits of either the IPV4 TOS octet or the IPV6 Traffic
     Class octet.

Grossman                                                        [Page 3]

draft-ietf-diffserv-new-terms-00.txt                        October 1999

     - the Differentiated Services Codepoint (DSCP) is a value which is
     encoded in the DS field, and which each DS Node MUST use to select
     the PHB which is to be experienced by each packet it forwards.

The two least significant bits of the IPV4 TOS octet and the IPV6
Traffic Class octet are not presently used by Diffserv.

4. Ordered aggregates and PHB scheduling classes

Work on Diffserv support by MPLS LSRs led to the realization that a
concept was needed in Diffserv to capture the notion of a set of BAs
with a common ordering constraint.  This presently applies to AF
behavior aggregates, since a DS node may not reorder packets of the same
microflow if they belong to the same AF class.  This would, for example,
prevent an MPLS LSR which was also a DS node from discriminating between
packets of an AF BA based on drop precedence and forwarding packets of
the same AF class but different drop precedence over different LSPs.
The following new terms are defined.

     PHB Scheduling Class: A PHB group for which a common constraint is
     that ordering of packets must be preserved

     Ordered Aggregate (OA):  A set of Behavior Aggregates that share an
     ordering constraint. All of the packets of an OA are members of the
     same PHB scheduling class.

5. Security Considerations Security considerations are addressed in RFC
2475.

Acknowledgements

References

   [1]  RFC 2474.

   [2]  Blake, Black, Carlson, Davies, Wang and Weiss "An Architecture
        for Differentiated Services", RFC 2475, December 1998.

   [3] Heinanen and Guerin, "Assured Forwarding PHB Group", RFC 2497

Author's Address

Grossman                                                        [Page 4]

draft-ietf-diffserv-new-terms-00.txt                        October 1999

        Dan Grossman
        Motorola, Inc.
        20 Cabot Blvd.
        Mansfield, MA 02048
        Email: dan@dma.isg.mot.com

Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain
   itor assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Grossman                                                        [Page 5]