Diffserv Working Group                                   Dan Grossman
Internet Draft                                           Motorola, Inc.
Expires: March 2001

                                                         August, 2000

                      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

     The list of Internet-Draft Shadow Directories can be accessed at

   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).


   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

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 Diffserv

Grossman                                                        [Page 1]

draft-ietf-diffserv-new-terms-03.txt                         August 2000

   standards track RFCs 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
   whereever appropriate.

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

   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

     - 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.

3. Usage of PHB Group

   RFC 2475 defines a PHB group to be:

     "a set of one or more PHBs that can only be meaningfully specified

Grossman                                                        [Page 2]

draft-ietf-diffserv-new-terms-03.txt                         August 2000

     and implemented simultaneously, due to a common constraint applying
     to all PHBs in the set such as a queue servicing or queue
     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."

One standards track PHB Group is defined in RFC 2497 [3], "Assured
Forwarding PHB Group".   Assured Forwarding (AF) is a type of forwarding
behavior with some assigned level of queuing resources and three drop
precedences.  An AF PHB Group consists of three PHBs, and uses three

RFC 2497 defines twelve DSCPs, corresponding to four independent AF
classes.  The AF classes are referred to as AF1x, AF2x, AF3x, and AF4x
(where 'x' is 1, 2, or 3 to represent drop precedence).  Each AF class
is one instance of an AF PHB Group.

There has been confusion expressed that RFC 2497 refers to all four AF
classes with their three drop precedences as being part of a single  PHB
Group. However, since each AF  class operates entirely independently of
the others, (and thus there is no common constraint among AF classes as
there is among drop precedences within an AF class) this usage is
inconsistent with RFC 2475.   The inconsistency exists  for historical
reasons and will be removed in future revisions of the AF specification.
It should  now be understood that AF is a _type_ of PHB group, and each
AF class is an _instance_ of the AF type.

Authors of new PHB specifications should be careful to adhere to the RFC
2475 definition of PHB Group. RFC 2475 does not prohibit new PHB
specifications from assigning enough DSCPs to represent multiple
independent instances of their PHB Group. However, such a set of DSCPs
must not be referred to as a single PHB Group.

4. 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".

It has been pointed out that this leads to inconsistencies and
ambiguities. In particular, the CU bits of the DS Field have not been
assigned to Diffserv, and have been assigned an experimental use for an
explicit congestion notification scheme [4].   In the current text, 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.

Grossman                                                        [Page 3]

draft-ietf-diffserv-new-terms-03.txt                         August 2000

The present text is also inconsistent with the IANA allocation
guidelines draft [5].  In that draft, the IPV4 TOS field and the IPV6
traffic class field are superceded by the 6 bit DS field and a 2 bit CU
field.  The IANA allocates values in the DS field following the IANA
considerations section in RFC 2474.  Experimental uses of the CU field
are assigned after IESG approval processes.  Permanent values in the CU
field are allocated following a Standards Action process.

The consensus of the DiffServ working group is that [5] correctly
restates the structure of the former TOS and traffic class fields.

Therefore, 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 the (former) IPV4 TOS octet or the (former)
     IPV6 Traffic Class octet.

     - 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.

   The update should also reference the IANA Allocation Guidelines,
   assuming that they are published as an RFC.

5. 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 at least those packets belonging to the same
     microflow must be preserved.

     Ordered Aggregate (OA):  A set of Behavior Aggregates that share an
     ordering constraint.  The set of PHBs that are applied to this set
     of Behavior Aggregates constitutes a PHB scheduling class.

Grossman                                                        [Page 4]

draft-ietf-diffserv-new-terms-03.txt                         August 2000

6. Unknown/improperly mapped DSCPs Several implementors have pointed out
   ambiguities or conflicts in the Diffserv RFCs concerning behavior
   when a DS-node recieves a packet with a DSCP which it does not

    RFC 2475 states:
      "Ingress nodes must condition all other inbound traffic to ensure
     that the DS codepoints are acceptable; packets found to have
     unacceptable codepoints must either be discarded or must have their
     DS codepoints modified to acceptable values before being forwarded.
     For example, an ingress  node receiving traffic from a domain with
     which no enhanced service agreement exists may reset the DS
     codepoint to the Default PHB  codepoint [DSFIELD]."

   On the other hand, RFC 2474 states:
     "Packets received with an unrecognized codepoint SHOULD be
     forwarded as if they were marked for the Default behavior (see Sec.
     4), and their codepoints should not be changed."

   The intent in RFC 2474 principally concerned DS-interior nodes.
   However, this behavior could also be performed in DS-ingress nodes
   AFTER the traffic conditioning required by RFC 2475 (in which case,
   an unrecognized DSCP would occur only in the case of
   misconfiguration).   If a packet showed up with a DSCP that hadn't
   been explicitly mapped to any particular  PHB, it should get treated
   the same way as a packet marked for Default. The alternatives were to
   assign it another PHB, which could result in misallocation of
   provisioned resources, or to drop it.  Those are the only
   alternatives within the framework of 2474. Neither alternative was
   considered desirable.  There has been discussion of a PHB which
   receives worse service than the default; this might be a better
   alternative.   Hence the imperitive was"SHOULD" rather than "SHALL".

   The intent in RFC 2475 is clearly concerns DS-ingress nodes, or to be
   more precise, the ingress traffic conditioning function.  This is
   another context where the "SHOULD" in RFC 2474 gives the flexibility
   to do what the group intended.  Such tortured readings are not

   Therefore, the statement in RFC 2474 will be clarified to indicate
   that it is not intended to apply at the ingress traffic conditioning
   function at a DS-ingress node, and cross reference RFC 2475 for that

   There is a similar issue, which manifests itself with EF. RFC 2598
     To protect itself against denial of service attacks, the edge of a
     DS domain MUST strictly police all EF marked packets to a rate

Grossman                                                        [Page 5]

draft-ietf-diffserv-new-terms-03.txt                         August 2000

     negotiated with the adjacent upstream domain.  (This rate must be
     <= the EF PHB configured rate.)  Packets in excess of the
     negotiated rate MUST be dropped.  If two adjacent domains have not
     negotiated an EF rate, the downstream domain MUST use 0 as the rate
     (i.e., drop all EF marked packets).

   The problem arises in the case of  misconfiguration or routing
   problems.   An egress DS-node at the edge of one DS-domain forwards
   packets an ingress DS-node at the edge of another DS domain.  These
   packets are marked with a DSCP that the egress node understands to
   map to EF, but which the ingress node does not recognize.  The
   statement in RFC 2475 would appear to apply to this case.  When RFC
   2598 is updated, a reference to RFC 2475 to cover the case of
   unrecognized DSCPs will be added.

6. Summary of pending changes

   The following standards track RFCs are expected to be updated to
   reflect the agreements captured in this memo.  It is intended that
   these updates occur when each specification progresses to Draft (or
   if some issue arises that forces recycling at Proposed).

     RFC 2474: revise definition of DS field.  Clarify that the
     suggested default forwarding in the event of an unrecognized DSCP
     is not intended to apply to ingress conditioning in DS-ingress

     RFC 2475: revise definition of DS field.  Add SLS and TCS
     definitions. Update body of document to use SLS and TCS
     appropriately.  Add definitions of PHB scheduling class and ordered

     RFC 2497: revise to reflect understanding that AF classes are
     instances of the AF PHB group, and are not collectively a PHB

     RFC 2598: put reference to RFC 2475 in security considerations to
     cover the case of a DS egress node receiving an unrecognized DSCP
     which maps to EF in the DS ingress node.

7. Security Considerations Security considerations are addressed in RFC



Grossman                                                        [Page 6]

draft-ietf-diffserv-new-terms-03.txt                         August 2000

   [1]  Nichols, Blake, Baker, Black, "Defintion of the Differentiated
        Services Field (DS Field) in the IPv4 and IPv6 Headers" RFC
        2474, December 1998.

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

   [3] Heinanen, Baker, Weiss, Wrocklawski, "Assured Forwarding PHB
        Group", RFC 2597

   [4] Ramakrishnan and Floyd, "A proposal to add Explicit Congestion
        Notification (ECN)" to IP, RFC 2481, January 1999

   [5] Bradner and Paxon, IANA Allocation Guidelines for Values in the
        Internet Protocol and Related Headers, draft-bradner-iana-
        allocation-02.txt, October 1999, work in progress

Author's Address

        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

   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

Grossman                                                        [Page 7]

draft-ietf-diffserv-new-terms-03.txt                         August 2000


Grossman                                                        [Page 8]