Internet DRAFT - draft-nichols-dsopdef


HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 10:31:23 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Sat, 28 Mar 1998 16:26:06 GMT
ETag: "2e6c4d-a331-351d249e"
Accept-Ranges: bytes
Content-Length: 41777
Connection: close
Content-Type: text/plain

Internet Engineering Task Force                 Kathleen Nichols, editor
INTERNET-DRAFT                             Bay Networks Architecture Lab
Expires: August 1998                                Steven Blake, editor
                                                    IBM Microelectronics 

                                                           February 1998

        Differentiated Services Operational Model and Definitions


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 learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).

   Differentiated services are intended to provide scalable service
   discrimination in the Internet without the need for per-flow state
   and signaling at every hop.  The differentiated services approach to
   providing quality of service in networks employs a small, well-
   defined set of building blocks from which a variety of services may
   be built.  The services may be either end-to-end or intra-domain.  A
   wide range of services can be provided by a combination of:
   - setting bits in the TOS octet at network edges and administrative
   - using those bits to determine how packets are treated by the
     routers inside the network, and 
   - conditioning the marked packets at network boundaries in accordance
     with the requirements of each service.

   A differentiated-services-capable network node includes a classifier
   that selects packets based on the TOS octet and is capable of
   delivering the treatment corresponding to that marking of the TOS
   octet.  Setting of the TOS octet and other conditioning of the

Nichols, et. al.           Expires: August 1998                [Page  1]
INTERNET-DRAFT           Differentiated Services           February 1998 

   dynamic behavior of marked packets need only be performed at network
   boundaries and may vary in complexity.  This draft presents a
   differentiated services definition of the TOS octet and the
   operational model behind that definition.


   This document is the result of a collaborative effort among the
   following individuals: Fred Baker, Steve Blake, Scott Bradner, Scott
   Brim, Brian Carpenter, Dave Clark, Eric Crawley, Bruce Davie, Juha
   Heinanen, Geoff Huston, Van Jacobson, Jim Luciani, Kathleen Nichols,
   Mike O'Dell, John Wroclawski, and Lixia Zhang.

0.  Discussion of this draft

   We have set up a public mailing list for discussions of this draft
   and for other differentiated services BOF issues.  The list is:  To subscribe send mail to with the line "subscribe diff-serv" in the
   body.  A browsable archive for this mailing list is at and the archive can be
   downloaded from  Please use
   this mailing list rather than others for the discussion of
   differentiated services.

1.  Introduction

   The TOS octet is used to mark a packet to receive a particular per-
   hop behavior.  Marking is performed by traffic conditioners at
   network boundaries, including the edges of the network (first hop
   router/switch) and administrative boundaries.  Traffic conditioners
   may include the primitives of classification, marking, policing and
   shaping.  Service classes can be specified by the use of particular
   traffic conditioning at boundaries coupled with particular per-hop
   behaviors.  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

   A number of recent Internet Drafts have suggested various encodings
   of the TOS byte to get specific behavior from network nodes on a per-
   hop basis [Ellesson, Ferguson, Heinanen, SIMA] and others have
   discussed the behaviors required from the network [Clark, 2BIT].  All
   of these have made important points about the kinds of per-hop
   behaviors that are considered in this note.  In selecting the TOS
   octet definition and specifying per-hop behaviors to attach to
   particular bit-patterns, we have been influenced by all these drafts
   and the thoughtful work of their authors. 

Nichols, et. al.           Expires: August 1998                [Page  2]
INTERNET-DRAFT           Differentiated Services           February 1998 

   We define terminology used in this draft in Sec. 2 and propose a
   differentiated services definition for the TOS octet in Sec. 3.  In
   Sec. 4, we present an operational model for the assignment of per-hop
   behaviors and propose two specific per-hop behaviors for
   standardization.  Sec. 5 describes primitives that can be used for
   traffic conditioning.  Sec. 6 discusses service allocation and
   deployment and Sec. 7 covers some security considerations.  We
   present additional discussion of the TOS octet definition in Appendix
   A and in Appendix B present some example services that can be built
   from these differentiated services primitives.

2.  Terminology used in this document

   Service: The description of what is sold to a customer, specified
   either end-to-end or within an Autonomous System (e.g., an ISP or
   campus).  We use the phrase "sold to a customer" loosely enough to
   encompass any AS's allocation of network service to a user or
   Per-hop Behavior: The forwarding behavior a packet receives at a
   given network node.  It may be expressed in terms that can strongly
   suggest a particular algorithm or implementation but leaves the
   specific choice to the implementor.  To compose predictable services,
   per-hop behaviors probably need to be available in all routers in a
   differentiated-services-capable network.

   Mechanism:  The implementation of a behavior.

   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

   DS byte: the IP header TOS octet when configured in conformance with
   the definition given in this document.

   Differentiated services behavior aggregate: a collection of packets
   with the same DS byte pattern crossing a boundary in a particular
   direction.  The terms "aggregate" and "behavior aggregate" will be
   used interchangeably in this document. 

   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 see or at the egress of the last-hop
   differentiated-services-aware router or network node packets see
   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 

Nichols, et. al.           Expires: August 1998                [Page  3]
INTERNET-DRAFT           Differentiated Services           February 1998 

   a host, subject to local policy. 

   Traffic conditioning primitives: functions that can be applied to a
   behavior aggregate, flow, or other operationally useful subset of
   traffic, e.g., routing updates.  These include policing, shaping,
   header classification, and packet marking.  Again, these may be
   described in terms that can strongly suggest a particular algorithm
   or implementation but no specific choice of implementation is given.
   With the exception of a DS byte classifier at the packet forwarding
   engine, traffic conditioning primitives need not be implemented in
   all network nodes in a differentiated-services-capable network,
   instead appearing primarily at boundaries.

   To summarize, the TOS octet is used as a DS byte 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.  A Differentiated Services Definition of the TOS Octet

   We propose to redefine the structure for the 8-bit IPv4 TOS field
   [RFC791] and the 8-bit IPv6 Class field [IPv6], and re-label the
   field as the "DS byte".  The new structure is presented below:

        0   1   2   3   4   5   6   7
      |IN |        PHB        |  CU   |

        IN:  in (1) or out (0) of profile
        PHB: per-hop behavior
        CU:  currently unused (reserved)

   We have been influenced by [Ellesson] and by Dave Clark's talk at the
   int-serv WG December 8, 1997 meeting.  Adopting key elements of
   Clark's framework, though not the exact terminology or bit-patterns,
   we use five bits to define the per-hop behavior (PHB) the packet
   experiences and one bit (IN) to identify whether the packet may be
   in- or out-of-profile with respect to some traffic policy measured at
   a network boundary.  We also reserve a two-bit CU, or currently
   unused, field that may be assigned later, e.g., for explicit
   congestion notification [ECN].  Hosts SHOULD set the CU bits to
   zeroes, and traffic conditioners and routers SHOULD ignore their

   The IN indicator parameter may be used to mark packets for a higher

Nichols, et. al.           Expires: August 1998                [Page  4]
INTERNET-DRAFT           Differentiated Services           February 1998 

   level of service (e.g., lower loss probability) within whatever share
   of router interface resources (e.g., buffers, bandwidth) are
   associated with a particular per-hop behavior. 

   Router implementations SHOULD treat the 5-bit PHB field as an index
   to be used in selecting 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, implementations should treat it as an unstructured

   The structure of the DS byte shown above is incompatible with the
   existing definition of the IPv4 TOS octet in [RFC791, RFC1349].  The
   use of bit 7 as a "DiffServ semantics" indicator was contemplated,
   but the authors believe that there exists deployed equipment which
   does not test bit 7, thereby making it impossible to simultaneously
   support two sets of semantics within the same network.  Therefore, to
   maintain compatibility with IPv4 hosts and networks which utilize the
   existing TOS semantics, a differentiated services-enabled network
   MUST remark the TOS value of packets arriving at a boundary entry
   node to some acceptable value within the new semantics, and MAY
   remark (e.g., by zeroing) on exit at a boundary to a network
   supporting the existing semantics.  Validating the value of the TOS
   octet at network boundaries is sensible in any case since an upstream
   node can easily set them to any random value.  Differentiated-
   services-enabled networks which are not suitably isolated by a 
   remarking boundary node may deliver unpredictable service.

4.  Operational Model 

4.1 Per-Hop Behaviors

   The differentiated services model is that a router has 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).  Router
   vendors are free to offer whatever parameters and capabilities they
   feel are useful or marketable.  An ISP is free to configure those
   parameters in whatever way they feel is appropriate for their service
   offerings and traffic engineering objectives.  The router's
   capabilities and its particular configuration determine the different
   ways packets can be treated.  The DS byte then selects which
   treatment a particular packet receives.  For example, an ISP may
   configure eight weighted round robin queues in its routers and use
   the DS byte to select which queue (from zero, for smallest weight to
   seven, for largest weight or share of output link) a packet is placed
   for servicing.  Another ISP might configure a single queue with
   multiple drop priorities and use the DS byte to select the drop
   preference (from zero, most likely to drop to seven, least likely to
   drop) for packets in that queue.  Another might configure four queues

Nichols, et. al.           Expires: August 1998                [Page  5]
INTERNET-DRAFT           Differentiated Services           February 1998 

   with two levels of drop preference in each.  There is no requirement
   that different ISPs use the same router mechanisms or configuration
   or that any value of the DS byte map to a particular packet
   forwarding behavior (other than the behaviors described below and the
   general guidelines given in Appendix A).

   However, to the extent that  the per-hop behaviors are used to
   implement end-to-end services (see Appendix B for examples), it may
   be undesirable for the "same" per-hop behavior to be selected by
   different DS byte values in different ISPs.  For example, consider
   ISP A and ISP B both offering a low jitter, guaranteed rate, premium
   service.  If ISP A uses a PHB of 3 to select an appropriate router
   mechanism while ISP B uses a PHB of 7, packets that use this service
   and transit A to B must have the PHB field of their DS byte rewritten
   from 3 to 7.  Since the per-hop behaviors on each side must be
   functionally equivalent, this is simply useless work that has to be
   done in the forwarding path of a busy border router.  To avoid this,
   we expect that over time certain common per-hop behaviors will evolve
   (ones that are particularly useful for implementing end-to-end
   services) and that these will be associated with particular code
   points in the DS byte.  However, since our current experience with
   diffserv is quite limited, it is premature to hypothesize the exact
   specification of these code points and we have simply left room in
   the code space to allow for evolution, thus the defined space of the
   PHB field is intentionally sparse.  But we do not suggest that PHB
   patterns be selected and assigned without adherence to a larger
   context.  For more on the rationale of selecting and using PHBs, see
   Appendix A.

   Only those per-hop behaviors that have both some degree of
   orthogonality and have been implemented, deployed, and shown to be
   useful should be standardized. 

   Two per-hop behaviors are already in widespread use and we propose
   them for standardization: Default (DE) is the common, best-effort
   forwarding available in today's internet and already standardized in
   RFC-1812.  Expedited Forwarding (EF) is a "high priority" behavior
   typically used for network control traffic such as routing updates.
   The code points chosen for these are compatible with existing

      PHB field value     Behavior name
      ---------------     -------------

      00000               Default (DE)
      11100               Expedited Forwarding (EF)

   and are defined as follows:

Nichols, et. al.           Expires: August 1998                [Page  6]
INTERNET-DRAFT           Differentiated Services           February 1998 

   Default: an incoming packet goes to the tail of a queue that is
   serviced in FIFO order when the output link is free.  Thus if a
   continuous stream of DE-marked packets is sent into a device, packets
   that emerge will emerge in the same order they entered.  It is not
   required that all arriving packets are seen at the output, but it is
   required that the aggregate of packets with this marking are not
   completely starved.  Delay requirements are as soon as possible, and
   the corresponding bandwidth requirements are as much as possible
   (subject to the other constraints of the router's scheduling system)
   [CCBES].  The Default behavior is designed to closely approximate the
   best-effort behavior of existing routers.

   Expedited Forwarding: an EF-marked packet goes to the tail of a queue
   that is expected to be relatively short and which always gets the
   next opportunity to send a packet (possibly subject to some rate
   regulator policy which prevents starvation of the Default queue).
   Thus, when an EF-marked packet is sent into a device, that packet
   should emerge at the output within a very small number of packet
   times.  The expedited forwarding behavior may be used to implement
   services requiring low delay and low jitter, and may also be useful
   for network control traffic.  

   Even though the above behaviors have been encoded in 3 bits,
   implementors should note that the PHB field is 5 bits wide and
   routers MUST identify both the DE and EF PHBs by matching against the
   entire 5-bit PHB field.  Packets received with an unrecognized PHB
   value SHOULD be handled as if they were marked for DE.

   Note that precise definitions of PHBs can be unwieldy and unclear.
   For this reason, the PHBs above are described as the output of an
   example algorithm.  However, PHBs should be standardized, not the
   algorithms or the mechanisms used to implement them.  To illustrate
   the distinction between PHB and mechanism, we point out that the EF
   PHB can be implemented by several mechanisms, including: a strict
   priority queue, WFQ or variants [HPFQA], weighted round-robin with a
   large weight for the EF queue, or CBQ [CBQ].

4.2 The "In Profile" bit

   Packets marked with the IN bit set should experience a probability of
   loss or congestion indication which is always less than or equal to
   that experienced by packets with the IN bit cleared.  When the IN bit
   is used, RIO [Clark] or another drop preference or congestion
   indication mechanism may be used to implement its use.  The
   requirements on a drop preference mechanism may be specific to each
   per-hop behavior, but the general requirements include: (1) there
   should be no packet reordering between packets marked for this
   behavior; (2) The *average* (real or virtual) queue occupancy should
   be used in the drop or congestion notification calculation, in a way
   that maximizes the router's chances of selecting a non-preferred
   packet to drop or notify of congestion.

Nichols, et. al.           Expires: August 1998                [Page  7]
INTERNET-DRAFT           Differentiated Services           February 1998 

   In the absence of traffic profiles, we suggest the IN bit should be
   set to zero for Default traffic.  With traffic profiles, the IN bit
   can be used to provide further service differentiation of DE-marked
   packets; for example, it can be used to implement the Assured service
   described in [Clark].

   Use of the IN bit in combination with the EF PHB is a subject of
   further research; at this time, all packets marked EF should have the
   IN bit set.  A pattern of 0.EF.CU will be considered undefined. The
   use of the IN bit as an in-profile indicator with the EF PHB is
   problematic for two reasons.  First, the delay and jitter behavior of
   EF-marked packets is sensitive to the relative load of EF-marked
   packets on a link; service allocation policies and traffic
   conditioners are used to ensure that this load is small enough to
   permit the desired low-delay behavior to be realized.  Secondly, out-
   of-profile EF-marked packets receive priority relative to DE-marked
   packets; excessive out-of-profile EF-marked packets may degrade the
   service of the DE-marked aggregate beyond what is assumed in the
   domain's service allocation policy.

5.  Example Traffic Conditioners for Boundaries

   Recall from Sec. 2 that traffic conditioners are composed of one or
   more primitives: classifiers, markers, policers, and shapers.
   Traffic conditioners prepare behavior aggregates for differentiated
   services.  The primitives are defined as:

   Classifiers: select packets based on some portion of their packet
   header and steer packets matching some classifier rule to another
   traffic conditioner for further processing.  Classifiers are of two
   types: multi-field (MF) classifiers which can classify on the DS byte
   as well as any one of a number of header fields (like a RSVP
   classifier) and behavior aggregate (BA) classifiers which classify
   only on patterns in the DS byte.

   Markers: set the DS byte to a particular bit pattern, adding the
   marked packets to a particular differentiated services behavior

   Policers: monitor the the dynamic behavior of the packets steered to
   them by a classifier and take an action (usually remarking or
   dropping packets) based on the relationship of measured properties of
   the packet stream to configured properties (e.g., rate and burst).
   Policers are generally placed after either type of classifier: after
   MF classifiers (e.g., at a host/network or site/provider boundary)
   or after BA classifiers (e.g., at a provider/provider boundary).

   Shapers: cause conformance to some configured traffic properties
   (e.g., token bucket).  Like policers, shapers are generally placed
   after either type of classifier.  Only one of the two primitives,
   policers or shapers, would be expected to appear in the same traffic

Nichols, et. al.           Expires: August 1998                [Page  8]
INTERNET-DRAFT           Differentiated Services           February 1998 


   Although it is probably not necessary to standardize traffic
   conditioners or the primitives that compose them, traffic
   conditioners are required to instantiate services, and to enforce
   service allocation policies.  The only conditioning that is required
   for packets of a differentiated services aggregate is to set the DS
   byte appropriately.  Thus, the simplest traffic conditioner consists
   of only a packet marker that sets the DS byte of every packet on its
   interface to a particular pattern for a particular per-hop behavior.
   If the service being offered requires additional rule conformance,
   then other primitives must be added to the traffic conditioner.
   Another simple traffic conditioner might use an MF classifier to
   select packets with a particular source-destination pair and a marker
   to set these packets' DS byte to for a particular per-hop behavior.
   There are a number of ways to condition traffic at boundaries; see
   [Clark], [SIMA], and [2BIT].  We expect that many more might evolve
   as differentiated services is widely deployed.

   Applications SHOULD be aware that the value of the DS byte may be
   modified at each network boundary (possibly subject to some
   negotiated policy).  The value of the DS byte does not have end-to-
   end integrity; security and transport protocol checksums MUST not
   include this field.

6.  Service Allocation and Deployment

   As differentiated services are deployed, there will be concerns about
   service allocation and also about partial deployment.  The allocation
   of differentiated services does not require standardization or
   uniformity.  The differentiated services architecture leads quite
   naturally to a control structure where decisions about the rate of
   each type of marked packet are made on a per-domain basis.  Since
   traffic carried on a link between two domains can now be classified
   into a small set of possibilities, it should be relatively
   straightforward to write down a bilateral agreement between any two
   domains.  Differentiated services does not require end-to-end
   signaling, but permits each domain to develop allocations of its
   intra-domain traffic according to rules and processes that are as
   simple or complex as desired.  Inter-domain agreements can be as
   simple as a list of the different packet markings and a maximum rate
   permitted for each.  Thus, it is not necessary to standardize a
   service allocation strategy to deploy differentiated services. 

   We expect that a number of allocation methods will be tried within
   different domains: aggregated RSVP [AIISS, GBH], Bandwidth Brokers
   [2BIT], human configuration by a network manager.  Reports of
   experiences with different intra-domain allocation methods should
   prove valuable during early deployment.  Further, we expect the
   nature of the bilateral inter-domain agreements to evolve as
   experience is with differentiated services is gained. Again, reports

Nichols, et. al.           Expires: August 1998                [Page  9]
INTERNET-DRAFT           Differentiated Services           February 1998 

   on experience will do much to advance the field.

   Differentiated services are realized by the concatenation of per-hop
   behaviors along the transit path of a packet; therefore, the
   treatment experienced by a behavior aggregate along a particular path
   is unpredictable if some of the nodes along that path do not
   recognize and implement the proposed per-hop behaviors.  Note however
   that the behavior of a router on a lightly loaded, high-speed link
   which does not implement a set of per-hop behaviors may be
   indistinguishable from that of a router which does (since the
   proposed per-hop behaviors are work-conserving).  The choice of those
   nodes upon which to implement the proposed per-hop behaviors is
   subject to a domain's traffic engineering policy.

   Experiences with early deployment of differentiated services should
   be shared, creating a body of work that the community can draw upon
   when deploying differentiated services in a domain or when automating
   a formerly manual process of allocation.  Ultimately, we expect that
   at least some differentiated services will enlist the use of
   automated inter-domain messaging to provide more flexibility.
   Selecting and developing the best approach is a topic for research.
   Though, ultimately, we may need a standard format for these messages,
   this should not be an IETF topic in the near-term.

7.  Security Considerations

   Wide-spread deployment of IP Security obscures the IP- and transport-
   header fields which are frequently used to enable packet 
   classification for service differentiation.  Use of the DS byte 
   offers an alternative means of classification for differentiated
   services, thereby eliminating a disincentive to the deployment of IP
   Security (especially within virtual private networks using ESP in
   tunnel-mode [ESP]).

   Because the differentiated services per-hop behaviors introduce
   service bias, new denial-of-service attacks may be introduced.  As an
   example, unauthorized use of the EF PHB or IN bit may result in
   service degradation to other traffic flows.  Furthermore, an attack
   on the differentiated services authorization, signaling, or
   configuration mechanisms may permit theft-of-service or may enable a
   severe denial-of-service attack.  As a consequence, authorization,
   signaling, and configuration mechanisms must be strongly protected
   (e.g., by authentication).  Non-default per-hop behaviors should
   always be controlled at a network boundary via some traffic
   conditioner (classifier, marker, policer/shaper).

   The IP Security Authentication Header (AH) does not cover the IPv4
   TOS octet 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

Nichols, et. al.           Expires: August 1998                [Page 10]
INTERNET-DRAFT           Differentiated Services           February 1998 

   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.

8.  Acknowledgements

   In addition to the co-authors of this document, valuable input was
   received from Jim Boyle and Sally Floyd.

9.  References

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

   [AIISS]     S. Berson and S. Vincent, "Aggregation of Internet
               Integrated Services State",  Internet Draft
               <draft-berson-classy-approach-01.txt>, November 1997.

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

   [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

   [Clark]     D. Clark and J. Wroclawski, "An Approach to Service
               Allocation in the Internet", Internet Draft
               <draft-clark-diff-svc-alloc-00.txt>, July 1997.

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

   [Ellesson]  E. Ellesson and S. Blake, "A Proposal for the Format and
               Semantics of the TOS Byte and Traffic Class Byte in IPv4
               and IPv6", Internet Draft <draft-ellesson-tos-00.txt>,
               November 1997.

   [ESP]       S. Kent and R. Atkinson, "IP Encapsulating Security
               Payload", Internet Draft
               <draft-ietf-ipsec-esp-v2-01.txt>, October 1997.

Nichols, et. al.           Expires: August 1998                [Page 11]
INTERNET-DRAFT           Differentiated Services           February 1998 

   [Ferguson]  P. Ferguson, "Simple Differential Services: IP TOS and
               Precedence, Delay Indication, and Drop Preference,
               Internet Draft <draft-ferguson-delay-drop-00.txt>,
               November 1997.

   [GBH]       R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP-
               based QoS Requests", Internet Draft
               <draft-guerin-aggreg-rsvp-00.txt>, November 1997.

   [Heinanen]  J. Heinanen, "Use of the IPv4 TOS Octet to Support
               Differentiated Services", Internet Draft
               <draft-heinanen-diff-tos-octet-01.txt>, November 1997.  

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

   [SIMA]      K. Kilkki, "Simple Integrated Media Access (SIMA)",
               Internet Draft <draft-kalevi-simple-media-access-01.txt>,
               June 1997.

   [2BIT]      K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
               Differentiated Services Architecture for the Internet",
               Internet Draft <draft-nichols-diff-svc-arch-00.txt>,
               November 1997.

Appendix A.  Proposed Interpretation of the Three Most-Significant Bits
             of the PHB Field

   In this document, we have proposed two particular PHBs.  Observant
   readers will note that the numerical value of the PHB field assigned
   to the Expedited Forwarding behavior is greater than that assigned to
   the Default behavior.  This is compatible with the interpretation of
   the three most-significant bits of the PHB field (bits 1, 2, and 3 of
   the DS byte as shown in Sec. 3) as a "weight" or "traffic precedence"
   relative to some dimension of quality of service (e.g., delay,
   throughput, or loss).  We propose that implementors use bits 1, 2,
   and 3 as a weight parameter to enable experiments using multi-level
   priority (of loss, delay, and/or throughput), subject to the
   requirement that bits 4 and 5 of the DS byte have the value zero.
   The associated weight (e.g., increased delay priority, increased link
   share, decreased loss probability) should increase in the order of

Nichols, et. al.           Expires: August 1998                [Page 12]
INTERNET-DRAFT           Differentiated Services           February 1998 

   increasing numerical value of bits 1, 2, and 3.  The interpretation
   of bits 1, 2, and 3 when the value of bits 4 and 5 is not equal to
   zero is not defined.

   Because this proposal does not specify the specific QoS metric which
   is affected by this three bit weight, implementation of any
   particular differentiated service using this parameter is dependent
   on each router's interpretation and implementation of the weight.
   Potential behaviors which could utilize this weight field include
   multi-level delay priority, multi-level discard priority, or multiple
   link shares (where the share of a link increases in the order of
   increasing weight).

Appendix B.  Service Examples in this Framework

   We propose standardizing ONLY a new meaning for the TOS octet and
   particular per-hop behaviors associated with certain TOS octet
   patterns.  These will provide predictable building blocks from which
   a variety of services might be built.  There is thus no need to
   standardize the services as these are realized by combining traffic
   conditioners at boundaries with per-hop behaviors.  To illustrate
   this, we present some example services implemented in our framework.
   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 any of the services; the choice is up to
   the customer.

   Service: Best Effort
   Service definition: "like today" (as soon as possible; as much as
   possible [CCBES]).

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

   Service: Premium
   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

Nichols, et. al.           Expires: August 1998                [Page 13]
INTERNET-DRAFT           Differentiated Services           February 1998 

   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

   Service name: Assured
   Service definition: Assured service is characterized by a rate and
   burst profile [Clark].  Behavior aggregates that conform to their
   profile are unlikely to experience dropped packets.  Packets sent
   that are out-of-profile are serviced with a higher drop preference,
   but are not reordered with respect to in-profile packets.  At the
   network edge, an assured behavior aggregate is marked for DE, the IN
   bit is set, and it is policed to a configured rate and burst size.  A
   policer for assured service clears the IN bit of packets which exceed
   the configured rate, thus tagging them as "out-of-profile".  The IN
   bit is only used if there is congestion on a link, then "out" packets
   are dropped with higher probability than "in" packets.  The sum of
   the Assured rates along with all other reserved rates at a domain
   ingress should be less than the total available rate.  Packets must
   remain marked for DE as reordering is prohibited.

   Who/how to use this: fixed file transfer size in desired time,
   "better effort", certain adaptive applications.

   Though we believe it is too early to standardize more than the EF and
   DE PHBs, we describe a service that can be delivered with a "link
   share" interpretation of bits 1, 2, and 3 of the DS byte as described
   in Appendix A.

   Service name: Olympic
   Service definition: Olympic service provides three levels of service,
   gold, silver, and bronze, in decreasing order of congested link
   shares.  Deployment of this service requires the implementation of
   a rate-based link share scheduler behavior at each hop [HPFQA, CBQ].
   The particular link share associated with a packet could be selected
   as suggested in Appendix A.  When encountering a congested link,
   packets with "Olympic gold" service will get a larger share of the
   link than packets sent using the "Olympic silver" service which gets
   a larger share of the link than packets sent using the "Olympic
   bronze" service.  When there are no packet flows of gold or silver
   (or other higher serviced flows), bronze packet flows may utilize the
   entire output link.  This service classifies flows at a boundary,
   marking packets for link share (e.g., by setting the "weight"
   parameter in bits 1, 2, and 3) and setting the IN bit.  The weight
   parameter could be set to i for gold flow packets, i-1 for silver
   flow packets, and i-2 for bronze flow packets, where 2 < i < 7.
   Classification should be uniform across a single TCP flow or packet
   reordering may result.  The exact method of service discrimination

Nichols, et. al.           Expires: August 1998                [Page 14]
INTERNET-DRAFT           Differentiated Services           February 1998 

   among the parameters is not specified, but would presumably be
   selected so as to make a perceptible difference to customers.  For
   example, if the mechanism implementing link sharing has four weighted
   round robin queues with RIO droppers in each queue, a configuration
   might be 60% for gold, 30% for silver, 10% for bronze.  These are the
   percentages each aggregate gets when the link is congested, but an
   alternate specification is that silver would get three times as large
   a share of service as bronze and gold would get twice the service of
   silver (it is also possible to have a "hidden" majority share
   reserved for EF traffic).  Lengths of each queue might also be
   adjusted to meet certain requirements (this is a configuration option
   which would not be standardized).  Customers do not specify a
   particular traffic profile, flows are not admission-controlled, and
   flows are not shaped or policed in any way.

   Who/how use this: for customer discrimination within an ISP,
   corporate, or campus domain.

Editors' 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
   IBM Microelectronics
   C5BA  660/HH007
   800 Park Offices Drive
   Research Triangle Park, NC  27709
   Phone:  +1-919-254-2030
   Fax:    +1-919-254-3047

Nichols, et. al.           Expires: August 1998                [Page 15]