INTERNET-DRAFT                                          Kathleen Nichols
Diffserv Working Group                                      Bay Networks
Expires: February 1999                                      Steven Blake
                                         Torrent Networking Technologies
                                                              Fred Baker
                                                           Cisco Systems
                                                          David L. Black
                                                          The Open Group
                                                             August 1998

        Definition of the Differentiated Services Field (DS Field)
                      in the IPv4 and IPv6 Headers


Status of This Memo

   This document is an Internet-Draft.  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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on (Africa), (Northern
   Europe), (Southern Europe), (Pacific
   Rim), (US East Coast), or (US West Coast).

Copyright Notice

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


   Differentiated services enhancements to the IP protocol are intended
   to enable scalable service discrimination in the Internet without the
   need for per-flow state and signaling at every hop.  A variety of
   services may be built from a small, well-defined set of building
   blocks which are deployed in network nodes.  The services may be
   either end-to-end or intra-domain; they include both those that can
   satisfy quantitative performance requirements (e.g., peak bandwidth)
   and those based on relative performance (e.g., "class"
   differentiation).  Services can be constructed by a combination of:

   - setting bits in an IP header field at network boundaries
     (autonomous system boundaries, internal administrative boundaries,

Nichols, et. al.          Expires: February 1999               [Page  1]

INTERNET-DRAFT         Differentiated Services Field         August 1998

     or hosts),
   - using those bits to determine how packets are forwarded by the
     nodes inside the network, and
   - conditioning the marked packets at network boundaries in accordance
     with the requirements or rules of each service.

   The requirements or rules of each service must be set through
   administrative policy mechanisms which are outside the scope of this
   document.  A differentiated services-compliant network node includes a
   classifier that selects packets based on the value of the DS field
   and is capable of delivering the specific packet forwarding treatment
   indicated by the DS field value.  Setting of the DS field and
   conditioning of the temporal behavior of marked packets need only be
   performed at network boundaries and may vary in complexity.

   This document defines the IP header field, called the DS (for
   differentiated services) field.  In IPv4, it defines the layout of
   the TOS octet; in IPv6, the Traffic Class octet.  In addition, a base
   set of packet forwarding treatments, or per-hop behaviors, is

   For a more complete understanding of differentiated services, see
   also the differentiated services architecture [ARCH].

Table of Contents

   1.  Introduction .................................................  3
   2.  Terminology Used in This Document ............................  5
   3.  Differentiated Services Field Definition .....................  7
   4.  Historical Codepoint Definitions and PHB Requirements ........  8
     4.1  A Default PHB .............................................  9
     4.2  Once and Future IP Precedence Field Use ...................  9
       4.2.1  IP Precedence History and Evolution in Brief .......... 10
       4.2.2  Subsuming IP Precedence into Class Selector  .......... 10
              Codepoints  The Class Selector Codepoints ..................... 11  The Class Selector PHB Requirements ............... 11  Using the Class Selector PHB Requirements ......... 11
                  for IP Precedence Compatibility  Example Mechanisms for Implementing Class ......... 12
                  Selector Compliant PHB Groups
     4.3  Summary ................................................... 12
   5.  Per-Hop Behavior Standardization Guidelines .................. 12
   6.  IANA Considerations .......................................... 14
   7.  Security Considerations ...................................... 14
     7.1  Theft and Denial of Service ............................... 14
     7.2  IPsec and Tunneling Interactions .......................... 15
   8.  Acknowledgments .............................................. 16
   9.  References ................................................... 16
   Appendix A.  Examples of Class Selector Compliant PHB ............ 17
     A.1  Priority Queues ........................................... 17

Nichols, et. al.          Expires: February 1999               [Page  2]

INTERNET-DRAFT         Differentiated Services Field         August 1998

     A.2  Round Robin Queueing ...................................... 18
     A.3  Virtual Circuit or Virtual Channel Selection .............. 18
     A.4  Priority Buffer Management ................................ 19
   Authors' Addresses ............................................... 19
   Full Copyright Statement ......................................... 20

1.  Introduction

   Differentiated services are intended  to provide a framework and
   building blocks to enable deployment of scalable service
   discrimination in the Internet.  The differentiated services approach
   aims to speed deployment by separating the architecture into two
   major components, one of which is fairly well-understood and the
   other of which is just beginning to be understood.  In this, we are
   guided by the original design of the Internet where the decision was
   made to separate the forwarding and routing components.  Packet
   forwarding is the relatively simple task that needs to be performed
   on a per-packet basis as quickly as possible.  Forwarding uses the
   packet header to find an entry in a routing table that determines the
   packet's output interface.  Routing sets the entries in that table
   and may need to reflect a range of transit and other policies as well
   as to keep track of route failures.  Routing tables are maintained as
   a background process to the forwarding task.  Further, routing is the
   more complex task and it has continued to evolve over the past 20

   Analogously, the differentiated services architecture contains two
   main components.  One is the fairly well-understood behavior in the
   forwarding path and the other is the more complex and still emerging
   background policy and allocation component that configures parameters
   used in the forwarding path.  The forwarding path behaviors include
   the differential treatment an individual packet receives, as
   implemented by queue service disciplines and/or queue management
   disciplines.  These per-hop behaviors are useful and required in
   network nodes to deliver differentiated treatment of packets no
   matter how we construct end-to-end or intra-domain services.  Our
   focus is on the general semantics of the behaviors rather than the
   specific mechanisms used to implement them since these behaviors will
   evolve less rapidly than the mechanisms.

   Per-hop behaviors and mechanisms to select them on a per-packet basis
   can be deployed in network nodes today and it is this aspect of the
   differentiated services architecture that is being addressed first.
   In addition, the forwarding path may require that some monitoring,
   policing, and shaping be done on the network traffic designated for
   "special" treatment in order to enforce requirements associated with
   the delivery of the special treatment.  Mechanisms for this kind of
   traffic conditioning are also fairly well-understood.  The wide
   deployment of such traffic conditioners is also important to enable
   the construction of services, though their actual use in constructing
   services may evolve over time.

Nichols, et. al.          Expires: February 1999               [Page  3]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   The configuration of network elements with respect to which packets
   get special treatment and what kinds of rules are to be applied to
   the use of resources is much less well-understood.  Nevertheless,
   it is possible to deploy useful differentiated services in networks
   by using simple policies and static configurations.  As described in
   [ARCH], there are a number of ways to compose per-hop behaviors and
   traffic conditioners to create services.  In the process, additional
   experience is gained that will guide more complex policies and
   allocations.  The basic behaviors in the forwarding path can remain
   the same while this component of the architecture evolves.
   Experiences with the construction of such services will continue for
   some time, thus we avoid standardizing this construction as it is
   premature.  Further, much of the details of service construction are
   covered by legal agreements between different business entities and
   we avoid this as it is very much outside the scope of the IETF.

   This document concentrates on the forwarding path component.  In the
   packet forwarding path, differentiated services are realized by
   mapping the codepoint contained in a field in the IP packet header to
   a particular forwarding treatment, or per-hop behavior (PHB), at each
   network node along its path.  The codepoints may be chosen from a set
   of mandatory values defined later in this document, from a set of
   recommended values to be defined in future documents, or may have
   purely local meaning.  PHBs are expected to be implemented by
   employing a range of queue service and/or queue management
   disciplines on a network node's output interface queue: for example
   weighted round-robin (WRR) queue servicing or drop-preference queue

   Marking is performed by traffic conditioners at network boundaries,
   including the edges of the network (first-hop router or source host)
   and administrative boundaries.  Traffic conditioners may include the
   primitives of marking, metering, policing and shaping (these
   mechanisms are described in [ARCH]).  Services are realized by the
   use of particular packet classification and traffic conditioning
   mechanisms at boundaries coupled with the concatenation of per-hop
   behaviors along the transit path of the traffic.  A goal of the
   differentiated services architecture is to specify these building
   blocks for future extensibility, both of the number and type of the
   building blocks and of the services built from them.

   Terminology used in this draft is defined in Sec. 2.  The
   differentiated services field definition (DS field) is given in Sec.
   3.  In Sec. 4, we discuss the desire for partial backwards
   compatibility with current use of the IPv4 Precedence field.  As a
   solution, we introduce Class Selector Codepoints and Class Selector
   Compliant PHBs.  Sec. 5 presents guidelines for per-hop behavior
   standardization.  Sec. 6 discusses guidelines for allocation of
   codepoints.  Sec. 7 covers security considerations.  We present
   examples of Class Selector Compliant PHB implementations in the

Nichols, et. al.          Expires: February 1999               [Page  4]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   This document is a concise description of the DS field and its uses.
   It is intended to be read along with the differentiated services
   architecture [ARCH].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2.  Terminology Used in This Document

   Behavior Aggregate: a collection of packets with the same codepoint
   crossing a link in a particular direction.  The terms "aggregate" and
   "behavior aggregate" are used interchangeably in this document.

   Classifier: an entity which selects packets based on the content of
   packet headers according to defined rules.

   Class Selector Codepoint: any of the eight codepoints in the range
   'xxx000' (where 'x' may equal '0' or '1').  Class Selector Codepoints
   are discussed in Sec. 4.2.2.

   Class Selector Compliant PHB: a per-hop behavior satisfying the Class
   Selector PHB Requirements specified in Sec.

   Codepoint: a specific value of the DSCP portion of the DS field.
   Recommended codepoints SHOULD map to specific, standardized PHBs.
   Multiple codepoints MAY map to the same PHB.

   Differentiated Services Boundary: the edge of a DS domain, where
   classifiers and traffic conditioners are likely to be deployed.  A
   differentiated services boundary can be further sub-divided into
   ingress and egress nodes, where the ingress/egress nodes are the
   downstream/upstream nodes of a boundary link in a given traffic
   direction.  A differentiated services boundary typically is found at
   the ingress to the first-hop differentiated services-compliant router
   (or network node) a host's packets traverse, or at the egress of the
   last-hop differentiated services-compliant router or network node
   packets traverse before arriving at a host.  This is sometimes
   referred to as the boundary at a leaf router.  A differentiated
   services boundary might be co-located with a host, subject to local
   policy.  Also DS boundary.

   Differentiated Services-Compliant: in compliance with the
   requirements specified in this document.

   Differentiated Services Domain: a contiguous portion of the Internet
   over which a consistent set of differentiated services policies are
   administered in a coordinated fashion.  A differentiated services
   domain can represent different administrative domains or autonomous
   systems, different trust regions, different network technologies
   (e.g., cell/frame), hosts and routers, etc.  Also DS domain.

Nichols, et. al.          Expires: February 1999               [Page  5]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   Differentiated Services Field: the IPv4 header TOS octet or the
   IPv6 Traffic Class octet when interpreted in conformance with the
   definition given in this document.  Also DS field.

   Mechanism:  The implementation of a per-hop behavior according to a
   particular algorithm.

   Microflow: a single instance of an application-to-application flow of
   packets which is identified by source address, destination address,
   protocol id, and source port, destination port (where applicable).

   Per-hop Behavior (PHB): a description of the externally observable
   forwarding treatment applied at a differentiated services-compliant
   node to a behavior aggregate.  The description of a PHB SHOULD
   be sufficiently detailed to allow the construction of predictable

   Per-hop Behavior Group: 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 management policy.  Also PHB Group.

   Traffic Conditioning: control functions that can be applied to a
   behavior aggregate, application flow, or other operationally useful
   subset of traffic, e.g., routing updates.  These MAY include
   metering, policing, shaping, and packet marking.  Traffic
   conditioning is used to enforce service level agreements between
   domains and to condition traffic to receive a differentiated service
   within a domain by marking packets with the appropriate codepoint in
   the DS field and by monitoring and altering the temporal
   characteristics of the aggregate where necessary.

   Traffic Conditioner: an entity which performs traffic conditioning
   functions and which MAY contain meters, policers, shapers, and
   markers.  Traffic conditioners are typically deployed in DS boundary
   nodes only.

   Service: a description of the overall treatment of a customer's
   traffic across a particular domain, across a set of interconnected
   DS domains, or end-to-end.  Service descriptions are covered by
   administrative policy and services are constructed by applying
   traffic conditioning to create behavior aggregates which experience a
   known PHB at each node within the DS domain.  Multiple services can
   be supported by a single per-hop behavior used in concert with a
   range of traffic conditioners.

   To summarize, classifiers and traffic conditioners are used to
   select which packets are to be added to behavior aggregates.
   Aggregates receive differentiated treatment in a DS domain and
   traffic conditioners MAY alter the temporal characteristics of the
   aggregate to conform to some requirements.  A packet's DS field is
   used to designate the packet's behavior aggregate and is subsequently

Nichols, et. al.          Expires: February 1999               [Page  6]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   used to determine which forwarding treatment the packet receives.  A
   DS field classifier which can select a differential output queue
   servicing discipline (or PHB) based on the codepoint in the DS field
   SHOULD be included in all network nodes in a DS domain.  The
   classifiers and traffic conditioners at DS boundaries are configured
   in accordance with some service specification, a matter of
   administrative policy outside the scope of this document.

   Additional differentiated services definitions are given in [ARCH].

3.  Differentiated Services Field Definition

   A new header field, called the DS field, is defined, which is
   intended to supersede the existing definitions of the IPv4 TOS octet
   [RFC791] and the IPv6 Traffic Class octet [IPv6].

   Six bits of the DS field are used as a codepoint (DSCP) to select the
   PHB a packet experiences at each node.  A two-bit currently unused
   (CU) field is reserved and may be assigned later, e.g., for explicit
   congestion notification.  The value of the CU bits are ignored by
   differentiated services-compliant nodes when determining the per-hop
   behavior to apply to a received packet.

   The DS field structure is presented below:

        0   1   2   3   4   5   6   7
      |         DSCP          |  CU   |

        DSCP: differentiated services codepoint
        CU:   currently unused

   Implementors should note that the DSCP field is six bits wide.  DS-
   compliant nodes MUST select PHBs by matching against the entire 6-
   bit DSCP field, e.g., by treating the value of the field as a table
   index which is used to select a particular packet handling mechanism
   which has been implemented in that device.  The DSCP field is defined
   as an unstructured field to facilitate the definition of future per-
   hop behaviors.

   With some exceptions noted below, the mapping of codepoints to PHBs
   MUST be configurable.  A DS-compliant node MUST support the logical
   equivalent of a configurable mapping table from codepoints to PHBs.
   PHB specifications MUST include a recommended default codepoint, but
   operators MAY choose to use different codepoints, either in addition
   to or in place of the recommended default.  Note that if operators do
   so choose, re-marking of DS fields will be necessary at
   administrative boundaries even if the same PHBs are implemented on

Nichols, et. al.          Expires: February 1999               [Page  7]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   both sides of the boundary.  See [ARCH] for further discussion of re-
   marking.  The recommended default codepoint for a PHB MUST be unique
   for codepoints in the standard space (see Sec. 6).

   The exceptions to general configurability are for codepoints 'xxx000'
   and are noted in Secs. 4.2.2 and 4.3.

   Packets received with an unrecognized codepoint SHOULD be forwarded
   as if they were marked for the Default behavior (see Sec. 4).  Such
   packets MUST NOT cause the network node to crash.

   The structure of the DS field shown above is incompatible with the
   existing definition of the IPv4 TOS octet in [RFC791, RFC1349].  The
   presumption is that DS domains protect themselves by deploying re-
   marking boundary nodes, as should networks using the RFC 791
   Precedence designations.  Correct operational procedure SHOULD follow
   [RFC791], which states: "If the actual use of these precedence
   designations is of concern to a particular network, it is the
   responsibility of that network to control the access to, and use of,
   those precedence designations."  Validating the value of the DS field
   at DS boundaries is sensible in any case since an upstream node can
   easily set it to any random value.  DS domains which are not suitably
   isolated by a re-marking boundary node may deliver unpredictable

   Nodes MAY rewrite the DS field as needed to provide a desired local
   or end-to-end service.  Specifications of DS field translations at
   DS boundaries are the subject of service level agreements between
   providers and users, and are outside the scope of this document.
   Standardized PHBs allow providers to build their services from a
   well-known set of packet forwarding treatments that can be expected
   to be present in the equipment of many vendors.

4.  Historical Codepoint Definitions and PHB Requirements

   The DS field will have a limited backwards compatibility with current
   practice, as described in this section.  Backwards compatibility is
   addressed in two ways.  First, there are per-hop behaviors that are
   already in widespread use (e.g., those satisfying the IPv4 Precedence
   queueing requirements specified in [RFC1812]), and we wish to permit
   their continued use in DS-compliant nodes.  In addition, there are
   some codepoints that correspond to historical use of the IP
   Precedence field and we reserve these codepoints to map to PHBs that
   meet the general requirements specified in Sec., though the
   specific differentiated services PHBs mapped to by those codepoints
   MAY have additional specifications.

   No attempt is made to maintain backwards compatibility with the "DTR"
   or TOS bits of the IPv4 TOS octet, as defined in [RFC791, RFC1349].

Nichols, et. al.          Expires: February 1999               [Page  8]

INTERNET-DRAFT         Differentiated Services Field         August 1998

4.1  A Default PHB

   A "default" PHB MUST be available in a DS-compliant node.  This is
   the common, best-effort forwarding behavior available in existing
   routers as standardized in [RFC1812].  When no other agreements are
   in place, it is assumed that packets belong to this aggregate.  Such
   packets MAY be sent into a network without adhering to any particular
   rules and the network will deliver as many of these packets as
   possible and as soon as possible, subject to other resource policy
   constraints.  A reasonable implementation of this PHB would be a
   queueing discipline that sends packets of this aggregate whenever the
   output link is not required to satisfy another PHB.  A reasonable
   policy for constructing services would ensure that the aggregate was
   not "starved".  This could be enforced by a mechanism in each node
   that reserves some minimal resources (e.g, buffers, bandwidth) for
   Default behavior aggregates.  This permits senders that are not
   differentiated services-aware to continue to use the network in the
   same manner as today.  The impact of the introduction of
   differentiated services into a domain on the service expectations of
   its customers and peers is a complex matter involving policy
   decisions by the domain and is outside the scope of this document.
   The RECOMMENDED codepoint for the Default PHB is the bit pattern
   '000000'; the value '000000' MUST map to a PHB that meets these
   specifications.  The codepoint chosen for Default behavior is
   compatible with existing practice [RFC791, RFC1349].  Where a
   codepoint is not mapped to a standardized or local use PHB, it SHOULD
   be mapped to the Default PHB.

   A "default" PHB MUST be available in a DS-compliant node.  This is
   A packet initially marked for the Default behavior MAY be re-marked
   with another codepoint as it passes a boundary into a DS domain so
   that it will be forwarded using a different PHB within that domain,
   possibly subject to some negotiated agreement between the peering

4.2  Once and Future IP Precedence Field Use

   We wish to maintain some form of backward compatibility with present
   uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet.
   Routers exist that use the IP Precedence field to select different
   per-hop forwarding treatments quite similarly to the use proposed
   here for the DSCP field.  Thus, a simple prototype differentiated
   services architecture can be quickly deployed by appropriately
   configuring these routers.  Further, IP systems today understand the
   location of the IP Precedence field, and thus if these bits are used
   in a similar manner as DS-compliant equipment is deployed,
   significant failures are not likely during early deployment.  In
   other words, strict DS-compliance need not be ubiquitous even within
   a single service provider's network if bits 0-2 of the DSCP field
   are employed in a manner similar to, or subsuming, the deployed uses
   of the IP Precedence field.

Nichols, et. al.          Expires: February 1999               [Page  9]

INTERNET-DRAFT         Differentiated Services Field         August 1998

4.2.1  IP Precedence History and Evolution in Brief

   The IP Precedence field is something of a forerunner of the DS field.
   IP Precedence, and the IP Precedence Field, were first defined in
   [RFC791].  The values that the three-bit IP Precedence Field might
   take were assigned to various uses, including network control
   traffic, routing traffic, and various levels of privilege.  The least
   level of privilege was deemed "routine traffic".  In [RFC791], the
   notion of Precedence was defined broadly as " An independent measure
   of the importance of this datagram."  Not all values of the IP
   Precedence field were assumed to have meaning across boundaries, for
   instance "The Network Control precedence designation is intended to
   be used within a network only.  The actual use and control of that
   designation is up to each network." [RFC791]

   Although early BBN IMPs implemented the Precedence feature, early
   commercial routers and UNIX IP forwarding code generally did not.  As
   networks became more complex and customer requirements grew,
   commercial router vendors developed ways to implement various kinds
   of queueing services including priority queueing, which were
   generally based on policies encoded in filters in the routers, which
   examined IP addresses, IP protocol numbers, TCP or UDP ports, and
   other header fields.  IP Precedence was and is among the options such
   filters can examine.

   In short, IP Precedence is widely deployed and widely used, if not in
   exactly the manner intended in [RFC791].  This was recognized in
   [RFC1122], which states that while the use of the IP Precedence field
   is valid, the specific assignment of the priorities in [RFC791] were
   merely historical.

4.2.2  Subsuming IP Precedence into Class Selector Codepoints

   A specification of the packet forwarding treatments selected by the
   IP Precedence field today would have to be quite general; probably
   not specific enough to build predictable services from in the
   differentiated services framework.  To preserve partial backwards
   compatibility with known current uses of the IP Precedence field
   without sacrificing future flexibility, we have taken the approach of
   describing minimum requirements on a set of PHBs that are compatible
   with most of the deployed forwarding treatments selected by the IP
   Precedence field.  In addition, we give a set of codepoints that MUST
   map to PHBs meeting these minimum requirements.  The PHBs mapped to
   by these codepoints MAY have a more detailed list of specifications
   in addition to the required ones stated here.  Other codepoints MAY
   map to these same PHBs.  We refer to this set of codepoints as the
   Class Selector Codepoints, and the minimum requirements for PHBs that
   these codepoints may map to are called the Class Selector PHB

Nichols, et. al.          Expires: February 1999               [Page 10]

INTERNET-DRAFT         Differentiated Services Field         August 1998  The Class Selector Codepoints

   The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU
   subfield unspecified, are reserved as a set of Class Selector
   Codepoints.  PHBs which are mapped to by these codepoints MUST
   satisfy the Class Selector PHB requirements in addition to preserving
   the Default PHB requirement on codepoint '000000' (Sec. 4.1).  The Class Selector PHB Requirements

   We refer to a Class Selector Codepoint with a larger numerical value
   than another Class Selector Codepoint as having a higher relative
   order while a Class Selector Codepoint with a smaller numerical value
   than another Class Selector Codepoint is said to have a lower
   relative order.  The set of PHBs mapped to by the eight Class
   Selector Codepoints MUST yield at least two independently forwarded
   classes of traffic, and PHBs selected by a Class Selector Codepoint
   SHOULD give packets a probability of timely forwarding that is not
   lower than that given to packets marked with a Class Selector
   codepoint of lower relative order, assuming roughly equivalent loads
   for each behavior aggregate.  A discarded packet is considered to be
   an extreme case of untimely forwarding.  In addition, PHBs selected
   by codepoint '11x000' MUST give packets a preferential forwarding
   treatment by comparison to the PHB selected by codepoint '000000' to
   preserve the common usage of IP Precedence values '110' and '111' for
   routing traffic.

   Where the relative loads of two or more Class Selector behavior
   aggregates are not roughly equivalent, the relative ordering of the
   observed forwarding behaviors is dependent on details of the PHB
   specification that are not defined here.  A discarded packet is
   considered to be an extreme case of untimely forwarding.

   Further, PHBs selected by distinct Class Selector Codepoints SHOULD
   be independently forwarded; that is, packets marked with different
   Class Selector Codepoints MAY be re-ordered.  A network node MAY
   enforce limits on the amount of the node's resources that can be
   utilized by each of these PHBs.

   PHB groups whose specification satisfy these requirements are
   referred to as Class Selector Compliant PHBs.

   The Class Selector PHB Requirements on codepoint '000000' are
   compatible with those listed for the Default PHB in Sec. 4.1.  Using the Class Selector PHB Requirements for IP Precedence

   A DS-compliant network node can be deployed with a set of one or more
   Class Selector Compliant PHB groups.  This document states that the
   set of codepoints 'xxx000' MUST map to such a set of PHBs.  As it is
   also possible to map multiple codepoints to the same PHB, the vendor

Nichols, et. al.          Expires: February 1999               [Page 11]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   or the network administrator MAY configure the network node to map
   codepoints to PHBs irrespective of bits 3-5 of the DSCP field to
   yield a network that is compatible with historical IP Precedence use.
   Thus, for example, codepoint '011010' would map to the same PHB as
   codepoint '011000'.  Example Mechanisms for Implementing Class Selector Compliant
            PHB Groups

   Class Selector Compliant PHBs can be realized by a variety of
   mechanisms, including strict priority queueing, weighted fair
   queueing (WFQ), WRR, or variants [RPS, HPFQA, DRR], or Class-Based
   Queuing [CBQ].  The distinction between PHBs and mechanisms is
   described in more detail in Sec. 5.

   It is important to note that these mechanisms might be available
   through other PHBs (standardized or not) that are available in a
   particular vendor's equipment.  For example, future documents may
   standardize a Strict Priority Queueing PHB group for a set of
   recommended codepoints.  A network administrator might configure
   those routers to select the Strict Priority Queueing PHBs with
   codepoints 'xxx000' in conformance with the requirements of this

   As a further example, another vendor might employ a CBQ mechanism in
   its routers.  The CBQ mechanism could be used to implement the Strict
   Priority Queueing PHBs as well as a set of Class Selector Compliant
   PHBs with a wider range of features than would be available in a set
   of PHBs that did no more than meet the minimum Class Selector PHB
   requirements.  More examples are given in the Appendix.

4.3  Summary

   This document defines codepoints 'xxx000' as the Class Selector
   codepoints, where PHBs selected by these codepoints MUST meet the
   Class Selector PHB Requirements described in Sec.  This is
   done to preserve a useful level of backward compatibility with
   current uses of the IP Precedence field in the Internet without
   unduly limiting future flexibility.  In addition, codepoint '000000'
   is used as the Default PHB value for the Internet and, as such, is
   not configurable.  The remaining seven non-zero Class Selector
   codepoints are configurable only to the extent that they map to PHBs
   that meet the requirements in Sec.

5.  Per-Hop Behavior Standardization Guidelines

   The behavioral characteristics of a PHB are to be standardized, and
   not the particular algorithms or the mechanisms used to implement
   them.  A node may have a (possibly large) set of parameters that can
   be used to control how packets are scheduled onto an output interface

Nichols, et. al.          Expires: February 1999               [Page 12]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   (e.g., N separate queues with settable priorities, queue lengths,
   round-robin weights, drop algorithm, drop preference weights and
   thresholds, etc).  To illustrate the distinction between a PHB and a
   mechanism, we point out that Class Selector Compliant PHBs might be
   implemented by several mechanisms, including: strict priority
   queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in
   isolation or in combination (see Appendix).

   PHBs may be specified individually, or as a group (a single PHB is a
   special case of a PHB group).  A PHB group usually consists of a set
   two or more PHBs that can only be meaningfully specified and
   implemented simultaneously, due to a common constraint applying to
   each PHB within the group, such as a queue servicing or queue
   management policy.  A PHB group specification SHOULD describe
   conditions under which a packet might be re-marked to select another
   PHB within the group.  It is RECOMMENDED that PHB implementations do
   not introduce any packet re-ordering within a microflow.  PHB group
   specifications MUST identify any possible packet re-ordering
   implications which may occur for each individual PHB, and which may
   occur if different packets within a microflow are marked for
   different PHBs within the group.

   Only those per-hop behaviors that are not described by an existing
   PHB standard, and have been implemented, deployed, and shown to be
   useful, SHOULD be standardized.  Since current experience with
   differentiated services is quite limited, it is premature to
   hypothesize the exact specification of these per-hop behaviors.

   Each standardized PHB MUST have an associated RECOMMENDED codepoint,
   allocated out of a space of 32 codepoints (see Sec. 6).  This
   specification has left room in the codepoint space to allow for
   evolution, thus the defined space ('xxx000') is intentionally sparse.

   Network equipment vendors are free to offer whatever parameters and
   capabilities are deemed useful or marketable.  When a particular,
   standardized PHB is implemented in a node, a vendor MAY use any
   algorithm that satisfies the definition of the PHB according to the
   standard.  The node's capabilities and its particular configuration
   determine the different ways that packets can be treated.

   Service providers are not required to use the same node mechanisms
   or configurations to enable service differentiation within their
   networks, and are free to configure the node parameters in whatever
   way that is appropriate for their service offerings and traffic
   engineering objectives.  Over time certain common per-hop behaviors
   are likely to evolve (i.e., ones that are particularly useful for
   implementing end-to-end services) and these MAY be associated with
   particular EXP/LU PHB codepoints in the DS field, allowing use across
   domain boundaries (see Sec. 6).  These PHBs are candidates for future

Nichols, et. al.          Expires: February 1999               [Page 13]

INTERNET-DRAFT         Differentiated Services Field         August 1998

6.  IANA Considerations

   The DSCP field within the DS field is capable of conveying 64
   distinct codepoints.  The codepoint space is divided into three pools
   for the purpose of codepoint assignment and management: a pool of 32
   RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as
   defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved for
   experimental or Local Use (EXP/LU) as defined in [CONS], and a pool
   of 16 codepoints (Pool 3) which are initially available for
   experimental or local use, but which should be preferentially
   utilized for standardized assignments if Pool 1 is ever exhausted.
   The pools are defined in the following table (where 'x' refers to
   either '0' or '1'):

   Pool        Codepoint space          Assignment Policy
   ----        ---------------          -----------------

    1            xxxxx0                 Standards Action
    2            xxxx11                 EXP/LU
    3            xxxx01                 EXP/LU (*)

   (*) may be utilized for future Standards Action allocations as

   This document assigns eight RECOMMENDED codepoints ('xxx000') which
   are drawn from Pool 1 above.  These codepoints MUST be mapped, not to
   specific PHBs, but to PHBs that meet "at least" the requirements set
   forth in Sec. to provide a minimal level of backwards
   compatibility with IP Precedence as defined in [RFC791] and as
   deployed in some current equipment.

7.  Security Considerations

   This section considers security issues raised by the introduction of
   differentiated services, primarily the potential for denial-of-
   service attacks, and the related potential for theft of service by
   unauthorized traffic (Section 7.1).  Section 7.2 addresses the
   operation of differentiated services in the presence of IPsec
   including its interaction with IPsec tunnel mode and other tunneling
   protocols.  More extensive treatment of the security concerns raised
   by the overall differentiated services architecture are discussed in

7.1  Theft and Denial of Service

   The primary goal of differentiated services is to allow different
   levels of service to be provided for traffic streams on a common
   network infrastructure.  A variety of techniques may be used to

Nichols, et. al.          Expires: February 1999               [Page 14]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   achieve this, but the end result will be that some packets receive
   different (e.g., better) service than others.  The mapping of network
   traffic to the specific behaviors that result in different (e.g.,
   better or worse) service is indicated primarily by the DS codepoint,
   and hence an adversary may be able to obtain better service by
   modifying the codepoint to values indicating behaviors used for
   enhanced services or by injecting packets with such codepoint values.
   Taken to its limits, such theft of service becomes a denial-of-
   service attack when the modified or injected traffic depletes the
   resources available to forward it and other traffic streams.

   The defense against this class of theft- and denial-of-service
   attacks consists of the combination of traffic conditioning at
   network boundaries with security and integrity of the network
   infrastructure within a DS domain.  Network boundary nodes MUST
   ensure that all traffic entering the domain is marked with codepoint
   values appropriate to the traffic and the domain, remarking the
   traffic with new codepoint values if necessary.  These DS boundary
   nodes are the primary line of defense against theft- and denial-of-
   service attacks based on modified codepoints, as success of any such
   attack indicates that the codepoints used by the attacking traffic
   were inappropriate.  An important instance of a boundary node is that
   any traffic-originating node within a DS domain is the initial
   boundary node for that traffic.  Interior nodes in a DS domain rely
   on DS codepoints to associate traffic with the forwarding PHBs, and
   are not required to check codepoint values before using them.  As a
   result, the interior nodes depend on the correct operation of the DS
   domain to prevent the arrival of traffic with inappropriate
   codepoints that would disrupt operation of the domain.

7.2  IPsec and Tunnelling Interactions

   The IPsec protocol, as defined in [ESP, AH], does not include the IP
   header's DS field in any of its cryptographic calculations (in the
   case of tunnel mode, it is the outer IP header's DS field that is not
   included).  Hence modification of the DS field by a network node has
   no effect on IPsec's end-to-end security, because it cannot cause any
   IPsec integrity check to fail.  As a consequence, IPsec does not
   provide any defense against an adversary's modification of the DS
   field (i.e., a man-in-the-middle attack), as the adversary's
   modification will also have no effect on IPsec's end-to-end security.

   IPsec's tunnel mode provides security for the encapsulated IP
   header's DS field.  A tunnel mode IPsec packet contains two IP
   headers: an outer header supplied by the tunnel ingress node and an
   encapsulated inner header supplied by the original source of the
   packet.  When an IPsec tunnel is hosted (in whole or in part) on a
   differentiated services network, the intermediate network nodes
   operate on the DS field in the outer header.  At the tunnel egress
   node, IPsec processing includes removing the outer header and
   forwarding the packet (if required) using the inner header.  The

Nichols, et. al.          Expires: February 1999               [Page 15]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   IPsec protocol REQUIRES that the inner header's DS field not be
   changed by this decapsulation processing to ensure that modifications
   to the DS field cannot be used to launch theft- or denial-of-service
   attacks across an IPsec tunnel endpoint.  This document makes no
   change to that requirement.  If the inner IP header has not been
   processed by a DS boundary node for the tunnel egress node's DS
   domain, the tunnel egress node is the boundary node for traffic
   exiting the tunnel, and hence MUST ensure that the resulting traffic
   has appropriate DS codepoints.

   When IPsec tunnel egress decapsulation processing includes a
   sufficiently strong cryptographic integrity check of the encapsulated
   packet (where sufficiency is determined by local security policy),
   the tunnel egress node can safely assume that the DS field in the
   inner header has the same value as it had at the tunnel ingress node.
   An important consequence is that otherwise insecure links within a DS
   domain can be secured by a sufficiently strong IPsec tunnel.  This
   analysis and its implications apply to any tunneling protocol that
   performs integrity checks, but the level of assurance of the inner
   header's DS field depends on the strength of the integrity check
   performed by the tunneling protocol.  In the absence of sufficient
   assurance for a tunnel that may transit nodes outside the current DS
   domain (or is otherwise vulnerable), the encapsulated packet MUST be
   treated as if it had arrived at a boundary from outside the DS

8.  Acknowledgements

   The authors would like to acknowledge the Differentiated Services
   Working Group for discussions which helped shape this document.

9.  References

   [AH]        S. Kent and R. Atkinson, "IP Authentication Header",
               Internet Draft <draft-ietf-ipsec-auth-header-07.txt>,
               July 1998.

   [ARCH]      D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and
               W. Weiss, "An Architecture for Differentiated Services",
               Internet Draft <draft-ietf-diffserv-arch-01.txt>,
               August 1998.

   [CBQ]       S. Floyd and V. Jacobson, "Link-sharing and Resource
               Management Models for Packet Networks", IEEE/ACM
               Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
               August 1995.

   [CLARK]     D. Clark and W. Fang, "Explicit Allocation of Best
               Effort Packet Delivery Service",

Nichols, et. al.          Expires: February 1999               [Page 16]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   [CONS]      T. Narten and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", Internet Draft
               <draft-iesg-iana-considerations-04.txt>, May 1998.

   [DRR]       M. Shreedhar and G. Varghese, Efficient Fair Queueing
               using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.

   [ESP]       S. Kent and R. Atkinson, "IP Encapsulating Security
               Payload (ESP)", Internet Draft
               <draft-ietf-ipsec-esp-v2-06.txt>, July 1998.

   [HPFQA]     J. Bennett and Hui Zhang, "Hierarchical Packet Fair
               Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.

   [IPv6]      S. Deering and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", Internet Draft
               <draft-ietf-ipngwg-ipv6-spec-v2-01.txt>, November 1997.

   [RFC791]    Information Sciences Institute, "Internet Protocol",
               Internet RFC 791, September 1981.

   [RFC1122]   R. T. Braden, "Requirements for Internet hosts -
               communication layers", Internet RFC 1122, October 1989.

   [RFC1349]   P. Almquist, "Type of Service in the Internet Protocol
               Suite", Internet RFC 1349, July 1992.

   [RFC1812]   F. Baker, editor, "Requirements for IP Version 4
               Routers", Internet RFC 1812, June 1995.

   [RFC2119]   S. Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", Internet RFC 2119, March 1997.

   [RPS]       D. Stiliadis and A. Varma, "Rate-Proportional Servers:
               A Design Methodology for Fair Queueing Algorithms", IEEE/
               ACM Trans. on Networking, April 1998.

Appendix.  Examples of Class Selector Compliant PHB Implementations

   This appendix shows how four different mechanisms can be used to
   implement Class Selector Compliant PHBs.

A.1  Priority Queues

   This approach employs eight queues where each of the eight codepoints
   maps to a different queue.  Queues are serviced in priority order so
   that each queue, from the perspective of the next lower priority
   queue, implements a "low loss, low delay" forwarding behavior.  As an
   alternative, one can employ four queues, where bits 0 and 1 of the
   codepoint are used to select the queue.  Bit 2 of the codepoint is

Nichols, et. al.          Expires: February 1999               [Page 17]

INTERNET-DRAFT         Differentiated Services Field         August 1998

   used as a drop preference within the queue.  RED is used within the
   queues according to its usual parameters, but with in-profile traffic
   having a higher min-threshold and max-threshold than out-of-profile
   traffic, and therefore experiencing a higher probability of timely
   delivery [CLARK].  Out-of-profile traffic should consider the
   presence of lower order in-profile traffic in the calculation of drop

   The strength of this second approach is that packet order is
   maintained within each precedence queue, but higher ordered traffic
   may be sent before lower ordered traffic (since lower ordered traffic
   within a queue may be dropped).  It has a weakness, however, in that
   apart from admission control and policing, it affords lower
   precedence traffic no assurance of eventual transmission.

A.2  Weighted Link-Share Queueing

   Like the previous example, this approach employs a queue per
   codepoint, but each queue is emptied at some non-zero rate, in round-
   robin order by means of some appropriate algorithm [HPFQA, RPS, DRR],
   rather than being given simple priority service.

   The strength of this approach is that higher ordered traffic is, on
   average, queued for a shorter duration than lower ordered traffic,
   assuming roughly equivalent relative loads for each order.  It also
   avoids the lockout issue that priority queuing systems may
   experience.  A counter-intuitive scenario can occur, however, if a
   high rate queue is heavily utilized while a lower rate queue is
   under-utilized; a packet directed to the lower rate queue can
   actually be better protected from loss and variation in delay when
   placed in an empty or very short queue.

A.3  Virtual Circuit or Virtual Channel Selection

   The difference between this approach and Weighted Link-Share Queuing
   is somewhat academic.  If one has a serial line to a routing
   neighbor, and manages the link using a link sharing algorithm, the
   link sharing algorithm in some sense emulates the way the line would
   behave if it were in reality a number of different lines, or if it
   were one channelized line.  In a virtual circuit selection model, the
   emulation becomes reality - one deploys a set of rate-limited VCs to
   a routing neighbor, and uses them in the same way one would otherwise
   have used round-robin queues.

   The strengths and weaknesses are very similar to those of Weighted
   Link-Share Queuing, except that this allows one to capitalize on the
   capabilities of a link layer such as ATM or Frame Relay.

Nichols, et. al.          Expires: February 1999               [Page 18]

INTERNET-DRAFT         Differentiated Services Field         August 1998

A.4  Priority Buffer Management

   This approach assigns buffer occupancy thresholds for each codepoint,
   with the threshold for a higher ordered codepoint being no lower than
   the threshold for a lower ordered codepoint.  Under link congestion,
   packets marked with a lower ordered codepoint are discard before
   those packets marked with a higher ordered codepoint.  The
   thresholding mechanism might be deterministic, or based on average
   queue occupancies and statistical discard probability weighting
   functions [CLARK].

Authors' Addresses

   Kathleen Nichols
   Bay Networks Architecture Lab
   4401 Great America Parkway
   Santa Clara, CA 95052-8185
   Phone:  +1-408-495-3252
   Fax:    +1-408-495-1299

   Steven Blake
   Torrent Networking Technologies
   2221 Broadbirch Drive
   Silver Spring, MD  20904
   Phone:  +1-301-625-1600

   Fred Baker
   Cisco Systems
   519 Lado Drive
   Santa Barbara, California 93111
   Phone:  +1-408-526-4257

   David L. Black
   The Open Group
   11 Cambridge Center
   Cambridge, MA 02142
   Phone:  +1-617-621-7347

Nichols, et. al.          Expires: February 1999               [Page 19]

INTERNET-DRAFT         Differentiated Services Field         August 1998

Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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 it
   or 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

Nichols, et. al.          Expires: February 1999               [Page 20]