Internet DRAFT - draft-ietf-diffserv-headers

draft-ietf-diffserv-headers



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 01:54:09 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 08 May 1998 01:32:00 GMT
ETag: "2ed799-69bb-35526090"
Accept-Ranges: bytes
Content-Length: 27067
Connection: close
Content-Type: text/plain


INTERNET-DRAFT                                          Kathleen Nichols
Diffserv Working Group                     Bay Networks Architecture Lab
Expires: November 1998                                      Steven Blake
                                                    IBM Microelectronics

                                                                May 1998


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

                 <draft-ietf-diffserv-headers-00.txt>


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 ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


Abstract
 
   Differentiated services are intended to provide 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. Services can be provided by a combination of:
 
   - setting bits in an IP header field at network edges and
     administrative boundaries,
   - using those bits to determine how packets are forwarded by the
     routers inside the network, and 
   - conditioning the marked packets at network boundaries in accordance
     with the requirements or rules of each service.

   This document defines the IP header field, called the DS (for
   differentiated services) byte. In IPv4, it takes the place of the TOS
   octet; in IPv6, it takes the place of the Traffic Class octet.  A
   differentiated services-capable network node includes a classifier


Nichols, Blake            Expires: November 1998               [Page  1]

INTERNET-DRAFT            Differentiated Services               May 1998


   that selects packets based on the value of the DS byte and is capable
   of delivering the specific packet forwarding treatment corresponding
   to that value.  This document defines two packet forwarding
   treatments, or per-hop behaviors.  Setting of the DS byte and other
   conditioning of the dynamic behavior of marked packets need only be
   performed at network boundaries and may vary in complexity. 

   For a more complete understanding of differentiated services, this
   document should be read along with its companion documents, the
   differentiated services architecture [ARCH], the differentiated
   services framework [FWK], and other documents which specify
   additional per-hop behaviors, such as [Baker].


1.  Introduction

   The DS byte is used to mark a packet to receive a particular
   forwarding treatment, or per-hop behavior, on nodes along its path.
   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 classification, marking, policing and shaping (these
   mechanisms are described in [ARCH]).  Services are realized by the
   use of particular traffic conditioning at boundaries coupled with the
   concatenation of per-hop behaviors along the transit path of the
   traffic (services are discussed in [FWK]).  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 byte definition (DS byte) is given in Sec. 3.
   In Sec. 4, two specific per-hop behaviors are defined.  Sec. 5
   presents guidelines for per-hop behavior standardization.  Sec. 6
   discusses guidelines for allocation of per-hop behavior codepoints.
   Sec. 7 covers security considerations.  We present two example
   services which can be built from these differentiated services
   primitives in the Appendix.

   This document is a concise description of the DS byte and its uses.
   It is intended to be read along with its companion documents, the
   differentiated services architecture [ARCH], the differentiated
   services framework [FWK], and other documents which specify
   additional per-hop behaviors, such as [Baker].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].






Nichols, Blake            Expires: November 1998               [Page  2]

INTERNET-DRAFT            Differentiated Services               May 1998


2.  Terminology Used in This Document

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

   Boundary: Where two network "clouds" are linked; the "clouds" can
   represent different administrative domains or autonomous systems,
   different trust regions, different network technologies (e.g., cell/
   frame), hosts and routers, etc.  A boundary can be further sub-
   divided into exit and entry nodes, where the exit/entry nodes are the
   upstream/downstream nodes of a boundary link in a given traffic
   direction.

   Codepoint: a specific value of the PHB field in the DS byte.

   DS byte: the IPv4 header TOS octet or the IPv6 Traffic Class octet
   when interpreted in conformance with the definition given in this
   document.

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

   Network edge: refers to a particular boundary node, the edge of the
   differentiated services-compliant area.  This typically is at the
   ingress to the first-hop differentiated services-aware router (or
   network node) a host's packets traverse, or at the egress of the
   last-hop differentiated services-aware router or network node packets
   traverse before arriving at a host.  This is sometimes referred to as
   the boundary at a leaf router.  The network edge might be co-located
   with a host, subject to local policy. 

   Per-hop Behavior: a description of the externally observable 
   forwarding treatment applied at a differentiated services-enabled
   node to a behavior aggregate.

   Service: a description of the overall treatment of a customer's
   traffic within a particular domain or end-to-end.

   Traffic conditioner: an entity which performs traffic conditioning
   functions and which may contain header classifiers, meters, policers,
   shapers, and markers.  Traffic conditioners are typically deployed in
   boundary nodes only.

   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 header
   classification, 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.



Nichols, Blake            Expires: November 1998               [Page  3]

INTERNET-DRAFT            Differentiated Services               May 1998


   To summarize, the DS byte is used to designate behaviors.  A DS byte
   classifier and per-hop behaviors based on those classifications are
   required in all network nodes of a differentiated services-capable
   network.  More extensive traffic conditioners may appear at
   boundaries.  Multiple services can be supported by a single per-hop
   behavior used in concert with a range of traffic conditioners.


3.  Differentiated Services Byte Definition

   A new header field, called the DS byte, is defined. The DS byte then
   overrides existing definitions of the IPv4 TOS octet [RFC791] and the
   IPv6 Traffic Class octet [IPv6].  

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

   The DS byte structure is presented below:


        0   1   2   3   4   5   6   7
      +---+---+---+---+---+---+---+---+
      |          PHB          |  CU   |
      +---+---+---+---+---+---+---+---+

        PHB: per-hop behavior
        CU:  currently unused


   Implementors should note that the PHB field is 6 bits wide.  Routers
   MUST identify PHBs by matching against the entire 6-bit PHB field,
   e.g., by treating the value or "codepoint" of the PHB field as a
   table index or a switch/case statement variable which is used to
   select a particular packet handling mechanism which has been
   implemented in that device.  Although the IANA may assume some
   structure within the PHB field when assigning values for new per-hop
   behaviors, we define it as an unstructured field to facilitate the
   definition of future per-hop behaviors.

   Packets received with an unrecognized codepoint SHOULD be forwarded
   as if they were marked for the Default behavior (see Sec. 4).

   The structure of the DS byte shown above is incompatible with the
   existing definition of the IPv4 TOS octet in [RFC791, RFC1349].  The
   presumption is that differentiated services-aware networks 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


Nichols, Blake            Expires: November 1998               [Page  4]

INTERNET-DRAFT            Differentiated Services               May 1998


   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 byte at network boundaries is sensible in any case since an
   upstream node can easily set it to any random value.  Differentiated
   services-enabled networks which are not suitably isolated by a
   re-marking boundary node may deliver unpredictable service.  A
   companion document [Baker] describes how a minimal necessary amount
   of compatibility with RFC 791 Precedence can be maintained under use
   of the DS byte.


4.  Initial Per-Hop Behavior Definitions

   Two per-hop behaviors are already in widespread use and we propose
   them for standardization: Default (DE) is the common, best-effort
   forwarding behavior available in existing routers and is already
   standardized in [RFC1812].  Expedited Forwarding (EF) is a "high
   priority" forwarding behavior such as might be used for delay
   sensitive traffic such as audio and video.  The codepoints for these
   two behaviors are shown below:


      Codepoint           Behavior name
      ---------           -------------

       000000             Default (DE)
       000010             Expedited Forwarding (EF)


   and the behaviors are defined as follows:

   Default: a DE-marked packet is queued for an outgoing interface
   according to the availability of buffer resources and according to
   any active queue management policy that may be implemented [ACTIVE].
   It is not required that all arriving packets are seen at the output,
   but it is RECOMMENDED that the aggregate of packets with this marking
   not be completely starved.  Forwarding requirements are as soon as
   possible, and the corresponding output bandwidth requirements are as
   much as possible, subject to the other constraints of the router's
   scheduling and buffer management sub-systems [CCBES].  The Default
   behavior is intended to closely approximate the best-effort behavior
   of existing routers.  The codepoint chosen for Default behavior is
   compatible with existing practice [RFC791, RFC1349].

   A packet originating from a node and marked for the Default behavior
   may be re-marked with another PHB codepoint at a downstream network
   boundary to enable preferential forwarding within that network,
   possibly subject to some negotiated agreement.

   Expedited Forwarding: for traffic levels of EF-marked packets which
   are a small fraction of the link rate of an outgoing interface, the


Nichols, Blake            Expires: November 1998               [Page  5]

INTERNET-DRAFT            Differentiated Services               May 1998


   implementation of Expedited Forwarding should exhibit the following
   behavioral characteristics: low absolute delay, low delay variation,
   and extremely low loss, irrespective of the rate of non-EF-marked
   traffic which is forwarded through that same outgoing interface.  The
   delay and loss characteristics should be similar to that observed by
   a single packet traversing an otherwise idle router, and should not
   vary significantly as the rate of non-EF-marked traffic is increased.
   The maximum rate of EF-marked traffic which can be forwarded on an
   outgoing link while satisfying the desired behavioral characteristics
   is implementation-dependent.  The Expedited Forwarding behavior can
   be realized by a variety of mechanisms, including strict priority
   queueing, WFQ or variants [HPFQA], weighted round-robin queueing with
   a large weight for the EF queue, or CBQ [CBQ].

   The Expedited Forwarding behavior may be used to implement services
   requiring low delay and low jitter.  Service guarantees for this
   class of traffic SHOULD depend on conformance to some rate and
   burstiness constraints which are enforced by traffic conditioners at
   network boundaries, possibly subject to some negotiated agreement.
   EF-marked aggregates which are in excess of these constraints may
   have some or all of their packets delayed (by a shaper) or discarded.

   Note that conforming implementations will commonly employ separate
   scheduler queues for DE- and EF-marked packets.  Thus it should be
   expected that packet streams which include both DE- and EF-marked
   packets may suffer packet reordering when traversing a conforming
   router.


5.  Per-Hop Behavior Standardization Guidelines 

   Thirty-two PHB codepoints are reserved for standardization, and 32
   codepoints are reserved for experimental or local use (EXP/LU)
   (see Sec. 6 for further details).

   The behavioral characteristics of a PHB are to be standardized, and 
   not the algorithms or the mechanisms used to implement them.  A
   router may have a (possibly large) set of parameters that can be used
   to control how packets are scheduled onto an output interface (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 the EF PHB might be implemented by
   several mechanisms, including: strict priority queueing, WFQ or
   variants [HPFQA], weighted round-robin queueing with a large weight
   for the EF queue, or CBQ [CBQ].

   Router vendors are free to offer whatever parameters and capabilities
   are deemed useful or marketable.  When a particular, standardized PHB
   is implemented in a router, a vendor may use any algorithm that
   satisfies the definition of the PHB according to the standard.  The
   router's capabilities and its particular configuration determine the


Nichols, Blake            Expires: November 1998               [Page  6]

INTERNET-DRAFT            Differentiated Services               May 1998


   different ways that packets can be treated.

   Service providers are not required to use the same router mechanisms
   or configurations to enable service differentiation within their
   networks, and are free to configure the router 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 byte, allowing use across
   domain boundaries (see Sec. 6).  These PHBs are candidates for future
   standardization.

   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.  This
   specification has left room in the codepoint space to allow for
   evolution, thus the defined space is intentionally sparse.


6.  IANA Considerations

   The PHB field in the DS byte 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
   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
       necessary


   This document defines two per-hop behaviors for standardization, and
   recommends the assignment of two codepoints (000000 and 000010) which
   are drawn from Pool 1 above.



Nichols, Blake            Expires: November 1998               [Page  7]

INTERNET-DRAFT            Differentiated Services               May 1998


   The IANA should note that a companion document may recommend
   assignment of the codepoint space xxxx00 within Pool 1 for use by
   per-hop behaviors which provide a minimal level of backwards
   compatibility with IP Precedence as defined in [RFC791].


7.  Security Considerations

   The IP Security Authentication Header (AH) does not cover the IPv4
   TOS octet or the IPv6 Traffic Class field in the integrity check
   value computation [AH].  This behavior is in fact essential for the
   deployment of differentiated services since the value of the DS byte
   may be changed in transit so that the source host does not know what
   value will be delivered to the destination host.  Also, since the
   network is free to ignore the DS byte, end-to-end integrity of a DS
   byte value does not guarantee that a differentiated service has been
   delivered.  Separate measurement and assurance mechanisms are needed
   to ensure that any negotiated differentiated services are being
   provided.

   Packets marked for Expedited Forwarding receive priority service
   relative to packets with other markings.  The rate of EF-marked
   packets MUST be regulated to prevent starvation of other traffic.
   EF-marked traffic received across a boundary link SHOULD be
   authenticated (e.g., either by IPsec, by header classification, or by
   aggregate policing).

   Additional security issues of the general differentiated services
   architecture are discussed in [ARCH].


8.  Acknowledgements

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


9.  References

   [ACTIVE]    B. Braden, et. al., "Recommendations on Queue Management
               and Congestion Avoidance in the Internet", Internet RFC
               2309, April 1998.

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

   [ARCH]      Differentiated Services Architecture Document (work in
               preparation).





Nichols, Blake            Expires: November 1998               [Page  8]

INTERNET-DRAFT            Differentiated Services               May 1998


   [Baker]     F. Baker, S. Brim, T. Li, F. Kastenholz, S. Jagannath,
               and J. Renwick, "IP Precedence in Differentiated
               Services Using the Assured Service", Internet Draft
               <draft-diff-serv-precedence-00.txt>, April 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.

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

   [CCBES]     C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang,
               "Congestion Control for Best-Effort Service: Why We Need
               a New Paradigm", IEEE Network, Vol. 10, no. 1, January
               1996.

   [ECN]       K. Ramakrishnan and S. Floyd, "A Proposal to Add Explicit
               Congestion Notification (ECN) to IPv6 and to TCP",
               Internet Draft <draft-kksjf-ecn-00.txt>, November 1997.

   [FWK]       Differentiated Services Framework Document (work in
               preparation).

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

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

   [2BIT]      K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
               Differentiated Services Architecture for the Internet",
               http://www-nrg.ee.lbl.gov/papers/2bitarch.pdf.






Nichols, Blake            Expires: November 1998               [Page  9]

INTERNET-DRAFT            Differentiated Services               May 1998


Appendix A.  Service Examples in this Framework

   We present two example services which may be implemented using the
   per-hop behaviors defined in this document.  We do not attempt to
   define "quality of service" for applications nor do we make
   assumptions about what service a particular application might use.
   Thus, although we give some example uses, we do not characterize the
   services as being "for real-time video" or "for file transfer data".
   Instead, we characterize a service by the type of performance packets
   of that service can expect from the network.  Any IP application can
   utilize either of these services; the choice is up to the customer.

   Service: Best Effort
   PHBs used: Default
   Service definition: "like today" (as soon as possible; as much as
   possible [CCBES]).  At the network edge, packets of the Best Effort
   aggregate should be marked with the Default PHB (though this is also
   the forwarding treatment that a packet with an unknown marking should
   receive).  This might be accomplished by marking all packets at the
   network edge for the Default PHB which can be changed if the packet
   header matches an multi-field classifier set up at the network edge.

   Who/how to use this: The basic service of the Internet, what one gets
   when merely buying connectivity.


   Service: Premium
   PHBs used: Expedited Forwarding
   Service definition: Premium service is a peak-limited, extremely low-
   delay service, resembling a leased line [2BIT].  At the network edge,
   where a Premium aggregate is first created, it must be either shaped
   or policed to a rate with no more than a two-packet burst.  A policer
   for Premium service is set to drop packets which exceed the
   configured peak rate.  For this service, the peak rate of the Premium
   aggregate across any boundary must be specified and the rate must be
   smaller than the link capacity (in practice, it is expected to be a
   good deal less than the link capacity).  Policing to this rate is
   expected at the ingress of any domain and the policing action taken
   may be one of two possibilities only: 1) drop the over-rate packet
   and 2) hold the over-rate packet until it will be in compliance with
   the peak rate (shaping). 

   Who/how to use this: Voice-over-IP "trunk", videoconference, fixed
   size transfer in fixed time, virtual leased line, low delay
   applications.









Nichols, Blake            Expires: November 1998               [Page 10]

INTERNET-DRAFT            Differentiated Services               May 1998


Authors' Addresses

   Steven Blake
   IBM Microelectronics
   C5BA  660/HH007
   800 Park Offices Drive
   Research Triangle Park, NC  27709
   Phone:  +1-919-254-2030
   Fax:    +1-919-254-3047
   E-mail: slblake@raleigh.ibm.com

   Kathleen Nichols
   Bay Networks Architecture Lab
   4401 Great America Parkway
   SC01-04
   Santa Clara, CA 95052-8185
   Phone:  +1-408-495-3252
   Fax:    +1-408-495-1299
   E-mail: knichols@baynetworks.com



































Nichols, Blake            Expires: November 1998               [Page 11]