[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network WG                                              James Polk, ed.
Internet-Draft                                                    Cisco
Intended status: Standards Track (PS)                         Feb, 2013
Obsoletes: RFC 4594
Updates: RFC 5865
Expires: August 25, 2013

           Standard Configuration of DiffServ Service Classes
                 draft-polk-tsvwg-rfc4594-update-03.txt

Abstract

   This document describes service classes configured with DiffServ and
   identifies how they are used and how to construct them using
   Differentiated Services Code Points (DSCPs), traffic conditioners,
   Per-Hop Behaviors (PHBs), and Active Queue Management (AQM)
   mechanisms.  There is no intrinsic requirement that particular
   DSCPs, traffic conditioners, PHBs, and AQM be used for a certain
   service class, but for consistent behavior under the same network
   conditions, configuring networks as described here is appropriate.


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 25, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Simplified BSD License text as described in


Polk                    Expires August 25, 2013                [Page 1]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.



Table of Contents

   1. Introduction ...................................................3
      1.1. Requirements Notation .....................................
      1.2. Expected Use in the Network ...............................
      1.3. Service Class Definition ..................................
      1.4. Key Differentiated Services Concepts ......................
         1.4.1. Queuing ..............................................
                1.4.1.1. Priority Queuing ............................
                1.4.1.2. Rate Queuing ................................
         1.4.2. Active Queue Management ..............................
         1.4.3. Traffic Conditioning .................................
         1.4.4. Differentiated Services Code Point (DSCP) ............
         1.4.5. Per-Hop Behavior (PHB) ...............................
      1.5. Key Service Concepts ......................................
         1.5.1. Default Forwarding (DF) ..............................
         1.5.2. Assured Forwarding (AF) ..............................
         1.5.3. Expedited Forwarding (EF) ...........................1
         1.5.4. Class Selector (CS) .................................1
         1.5.5. Admission Control ...................................1
      1.6 What Changes are Proposed Here from RFC 4594?..............1
   2. Service Differentiation .......................................1
      2.1. Service Classes ..........................................1
      2.2. Categorization of User Oriented Service Classes ..........1
      2.3. Service Class Characteristics ............................1
      2.4. Service Classes vs. Treatment Aggregate (from RFC 5127)...2
         2.4.1 Examples of Service Classes in Treatment Aggregates...2
   3. Network Control Traffic .......................................2
      3.1. Current Practice in the Internet .........................2
      3.2. Network Control Service Class ............................2
      3.3. OAM Service Class ........................................2
   4. User Oriented Traffic .........................................3
      4.1. Conversational Service Class Group .......................3
         4.1.1 Audio Service Class ..................................3
         4.1.2 Video Service Class ..................................3
         4.1.3 Hi-Res Service Class .................................3
      4.2. Realtime-Interactive Service Class ...................... 3
      4.3. Multimedia Conferencing Service Class ....................3
      4.4. Multimedia Streaming Service Class .......................3
      4.5. Broadcast Video Service Class ............................4
      4.6. Low-Latency Data Service Class ...........................4
      4.7. Conversational Signaling Service Class ...................4
      4.8. High-Throughput Data Service Class .......................4
      4.9. Standard Service Class ...................................4
      4.10. Low-Priority Data .......................................4
   5. Additional Information on Service Class Usage .................4
      5.1. Mapping for NTP ..........................................5


Polk                    Expires August 25, 2013                [Page 2]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

      5.2. VPN Service Mapping ......................................5
   6. Security Considerations .......................................5
   7. Contributing Authors ..........................................5
   8. Acknowledgements ..............................................5
   9. References ....................................................5
      9.1. Normative References .....................................5
      9.2. Informative References ...................................5
   Author's Address .................................................5
   Appendix A - Changes .............................................5



1.  Introduction

   Differentiated Services [RFC2474][RFC2475] provides the ability to
   mark/label/classify IP packets differently to distinguish how
   individual packets need to be treated differently through (or
   throughout) a network on a per hop basis. Local administrators are
   who configure each router for which Differentiated Services Code
   Points (DSCP) are to be treated differently, which are to be
   ignored (i.e., no differentiated treatment), and which DSCPs are to
   have their packets remarked (to different DSCPs) as they pass
   through a router. Local administrators are also who assign which
   applications, or traffic types, should use which DSCPs to receive
   the treatment the administrators expect within their network.

   What most people fail to understand is that DSCPs provide a per hop
   behavior (PHB) through that router, but not the previous or next
   router. In this way of understanding PHB markings, one can
   understand that Differentiated Services (DiffServ) is not a Quality
   of Service (QoS) mechanism, but rather a Classification of Service
   (CoS) mechanism.

   For instance, there are 64 possible DSCP values, i.e., using 6 bits
   of the old Type of Service (TOS) byte [RFC0791]. Each can be
   configured locally to have greater or less treatment relative to any
   other DSCP with two exceptions*.

      * Expedited Forwarding (EF) [RFC3246] DSCPs have a treatment
        requirement that any packet marked within an EF class has to be
        the next packet transmitted out its egress interface. If there
        are more than one EF marked packet in the queue, obviously the
        queue sets the order they are transmitted. Further, if there
        are more than one EF DSCP, local configuration determines if
        each are treated the same or differently relate to each other
        EF DSCP. Currently, there are two Expedited Forwarding DSCPs:
        EF (101110) [RFC3246] and VOICE-ADMIT (101100) [RFC5865].

      * Class Selector 6 (CS6) [RFC2474] is for routing protocol
        traffic. There are deemed important because if the network does
        not transmit and receive its routing protocol traffic in a
        timely manner, the network stops operating properly.


Polk                    Expires August 25, 2013                [Page 3]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   Not all are configured to mean anything other than best effort
   forwarding by local administrators of a network.  Let us say there
   are 5 DSCPs configured within network A. Network A's administrator
   chooses and configures which order (obeying the two exceptions noted
   above) which application packets are treated differently than any
   other packets within that network (A). The DSCPs are not fixed to a
   linear order for relative priority on a per hop basis. Further, and
   this is often the case, there might be packets with the same DSCP
   arriving at multiple interfaces of a node, each egressing that node
   out the same interface. At ingress to this node, everything was
   fine, with no poor behavior or noticeably excessive amount of
   packets with the same DSCP. However, at the egress interface, there
   might not be enough capacity to satisfy the load, thus the departing
   packets transmit at their maximum rate for that DSCP, but have
   additional latency due to the overload within that one node. This is
   called fan-in congestion (or problem). By itself, DiffServ will not
   remedy this problem for the application that is intolerant to added
   latency because DiffServ only functions within 1 node at a time.

   An additional mechanism is needed to ensure each flow or session
   receives the amount of packets at its destination that the
   application requires to perform properly; a mechanism such as
   IntServ, by way of RSVP [RFC2205] or NSIS [RFC4080]. With this added
   capability to be session aware, something DiffServ is not, the
   packets transmitted within a single session have a very good
   probability of arriving in such a way the receiving application can
   make full use of each. That said, signaling reservations for each
   session or flow adds complexity, which creates more work for those
   who maintain and administer such a network.  Adding bandwidth and
   using DiffServ marking is an easier pill to swallow. The deployment
   of not few, but more and more audio and (particularly bandwidth
   hogging) video codecs and their respective application rigidity has
   caused some to conclude that throwing bandwidth at the problem is no
   longer acceptable.

   With this in mind, this document incorporates five of the six new
   DSCPs from [ID-DSCP] identified as capacity-admitted DSCPs for most
   of the service classes in this document. As explained in [ID-DSCP],
   the five new capacity-admitted DSCPs are from Pool 3. [ID-DSCP] goes
   further to explain that many layer 2 technologies use fewer bits for
   marking and prioritization. Instead of six bits like DiffServ, they
   have three bits, which yields a maximum of 8 values, which tend to
   line up quite will with the TOS field values. Thus, aggregation of
   DSCPs is typically accomplished by simply ignoring or reducing the
   number of bits used to the most significant ones available, such as

      EF is 101110, at layer 2 this is merely 101;

      Broadcast is 011000, at layer 2 this is merely 011.

   However, that was not a premise DiffServ was built upon, to merely


Polk                    Expires August 25, 2013                [Page 4]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   reduce the number of bits. In other words, within DiffServ, XXX is
   not the same as XXX000 (where XXX is the same binary value in both
   cases).

   This document is originally built upon the RFC 4594 effort, while
   updating some of the usages and expanding the scope for newer
   applications that are in use today. The idea in RFC 4594 remains
   true here, to define a set of service classes, each having unique
   traffic characteristics, and assigning one or more DSCPs to each
   service class. As much as the focus could be on the DSCP values, it
   is not. The focus of this document is the unique traffic
   characteristics of each service class.

   There are many services classes defined in this document, not all
   will be used in each network at any period of time. This consistency
   packet markings we talk about is for several reasons, including in a
   network that does not currently implement a certain service class
   because they do not have that type of traffic in their network, or
   that the network merely gives that traffic best effort service.
   Having a solid guideline to know where to progress or reconfigure a
   network and endpoints to, say from best effort for a particular
   traffic type, is a very good thing to do more uniformly than not. A
   fair amount of burden is placed at DS boundaries needing to keep up
   with which markings turn into which other markings at both ingress
   and egress to a network. The same holds true for application
   developers choosing a default DSCP for their application, lacking a
   guideline means everyone picks for themselves - and usually with a
   highly inflated sense of self importance for their application or
   service.

   Another point to make is that there are 20+ service classes defined
   within the IETF, and that is far too many for most service providers
   to manage effectively. So, they have formed groups around certain
   aggregation solutions of service classes. One such aggregation group
   is based on RFC 5127, which defines what it calls a treatment
   aggregate, which is taking RFC 4594's service classes and placing
   them each into one of four treatment aggregates for service
   providers to handle as a group. SG12 within the ITU-T has an
   alternative that has nine aggregate groups, so there is work to be
   done to harmonize aggregates of service classes. This discussion is
   articulated more in section 2.4. At the end of Section 2.4 we have
   introduced a series of example configurations which provide examples
   of how only a few service classes - yet still most treatment
   aggregates - can be configured in example networks.

   Does RFC 4594 need updating? That document is an informational
   guideline on how networks can or should mark certain packet flows
   with differing traffic characteristics using DiffServ. There are
   several reasons why this informational RFC lacks the necessary
   clarity and strength to reach widespread adoption:

   o  confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of


Polk                    Expires August 25, 2013                [Page 5]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

      which is for aggregating many 6-bit DSCP values into a 3-bit (8
      value) field used specifically by service provider (SP) networks.

   o  some believe both RFCs are for SPs, while others ignore RFC 5127
      and use RFC 4594 as if it were standards track or BCP.

   o  some believe RFC 5127 is for SPs only, and want RFC 4594 to
      reduce the number of DSCPs within its guidelines to recommend
      using only 3 or 4 DSCPs. This seems to stem from a manageability
      and operational perspective.

   o  some know RFC 4594 is informational and do not follow its
      guidelines specifically because it is informational.

   o  some use DSCP values that are not defined within RFC 4594, making
      mapping between different networks using similar or identical
      application flows difficult.

   o  some believe enterprise networks should not use either RFC except
      at the edge of their networks, where they directly connect to SP
      networks.

   o  some argue that the services classes guidance per class is too
      broad and are therefore not sure in which service class a
      particular application is to reside.

   o  time has shown that video has become a dominant application on
      the Internet, and many believe it now requires to be treated
      uniquely in environments that want to. Video also does not always
      plan nice with audio, so knowing the two use the same transport
     (RTP) [RFC3550], a means of separation is in order.

   Service class definitions are based on the different traffic
   characteristics and required performance of the
   applications/services. There are a greater number of service classes
   in this document than there were when RFC 4594 [RFC4594] was
   published (the RFC this document intends to obsolete). The required
   performance of applications/services has also changed since the
   publication of RFC 4594, specifically in the area of conversational
   real time communications. As a result, this document has a greater
   number of real time applications with more granular set of DSCPs due
   to their different required performances. Like RFC 4594 before, this
   approach allows those applications with similar traffic
   characteristics and performance requirements to be placed in the
   same service class.

   The notion of traffic characteristics and required performance is a
   per application concept, therefore the label name of each service
   class remains the same on an end-to-end basis, even if we understand
   that DiffServ is only a PHB and cannot guarantee anything, even
   packet delivery at the intended destination node.  That said,
   several applications can be configured to have the same DSCP, or


Polk                    Expires August 25, 2013                [Page 6]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   each have different DSCPs that have the same treatment per hop
   within a network.

   Since RFC 4594 was first published, a new concept has been
   introduced that will appear throughout this document, including DSCP
   assignments -- the idea of "admitted" traffic, initially introduced
   into DiffServ within RFC 5865 [RFC5865]. The VOICE-ADMIT Expedited
   Forwarding class differentiates itself from the EF Expedited
   Forwarding by having the packets marked be for admitted traffic.
   This concept of "admitted" traffic is spread throughout the real
   time traffic classes.

   Thus, the document flow is as follows:

   o  maintain the general format of RFC 4594;

   o  augment the content with the concept of capacity-admission;

   o  incorporate more video into this document, as it has become a
      dominant application in enterprises and other managed networks,
      as well as on the open public Internet;

   o  reduce the discussion on voice and its examples;

   o  articulate the subtle differences learned since RFC 4594 was
      published.

   The goal here is to provide a standard configuration for DiffServ
   DSCP assignments and expected PHBs for enterprises and other managed
   networks, as well as towards the public Internet with specific
   traffic characteristics per Service class/DSCP, and example
   applications shown for each.

   This document describes service classes configured with DiffServ and
   defines how they can be used and how to construct them using
   Differentiated Services Code Points (DSCPs), and recommends how to
   construct them using traffic conditioners, Per-Hop Behaviors (PHBs),
   and Active Queue Management (AQM) mechanisms.  There is no intrinsic
   requirement that particular traffic conditioners, PHBs, and AQM be
   used for a certain service class, but as a policy and for
   interoperability it is useful to apply them consistently.

   We differentiate services and their characteristics in Section 2.
   Network control traffic, as well as user oriented traffic are
   discussed in Sections 3 and 4, respectively. We analyze the security
   considerations in Section 6. Section 7 offers a tribute to the
   authors of RFC 4594, from which this document is based. It is in its
   own section, and not part of the normal acknowledgements portion of
   each IETF document.





Polk                    Expires August 25, 2013                [Page 7]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

1.1.  Requirements Notation

   The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
   in this document are to be interpreted as described in [RFC2119]
   when they appear in ALL CAPS.  These words may also appear in this
   document in lower case as plain English words, absent their
   normative meanings.

1.2.  Expected Use in the Network

   In the Internet today, corporate LANs and ISP WANs are increasingly
   utilized, to the point in which network congestion is affecting
   performance of applications.  For this reason, congestion, loss, and
   variation in delay within corporate LANs and ISP backbones is
   becoming known to the users collectively as "the network is slow for
   this application" or just "right now" or "for today". Users do not
   directly detect network congestion. They react to applications that
   run slow, or to downloads that take too long in their mind(s). The
   explosion of video traffic on the internet recently has cause much
   of this, and is often the application the user is using when they
   have this slowness.

  In the past, application slowness occurred for three very good
  reasons.

   o  the networks the user oriented traffic traverses moves through
      cycles of bandwidth boom and bandwidth bust, the latter of which
      become apparent with the periodic deployment of new
      bandwidth-hungry applications.

   o  In access networks, the state is often different.  This may be
      because throughput rates are artificially limited or
      over-subscribed, or because of access network design trade-offs.

   o  Other characteristics, such as database design on web servers
      (that may create contention points, e.g., in filestore) and
      configuration of firewalls and routers, often look externally
      like a bandwidth limitation.

   The intent of this document is to provide a standardized marking,
   plus a conditioning and packet treatment strategy so that it can be
   configured and put into service on any link that is itself
   congested.


1.3.  Service Class Definition

   A "service class" represents a similar set of traffic
   characteristics for delay, loss, and jitter as packets traverse
   routers in a network. For example, "High-Throughput Data" service
   class for store-and-forward applications, or a "Broadcast" service


Polk                    Expires August 25, 2013                [Page 8]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   class for minimally time-shifted IPTV or Internet radio broadcasts.
   Such a service class may be defined locally in a Differentiated
   Services (DS) domain, or across multiple DS domains, possibly
   extending end to end. A goal of this document is to have most/all
   networks assign the same type of traffic the same for consistency.

   A service class is a naming convention which is defined as a word,
   phrase or initialism/acronym representing a set of necessary traffic
   characteristics of a certain type of data flow.  The necessary
   characteristics of these traffic flows can be realized by the use of
   defined per-hop behavior that started with [RFC2474].  The actual
   specification of the expected treatment of a traffic aggregate
   within a domain may also be defined as a per-domain behavior (PDB)
   [RFC3086].

   Each domain will locally choose to

   o  implement one or more service classes with traffic
      characteristics as defined here, or

   o  implement one or more service classes with similar traffic
      characteristics as defined here, or

   o  implement one or more service classes with similar traffic
      characteristics as defined here and to aggregate one or more
      service classes to reduce the number of unique DSCPs within their
      network, or

   o  implement one or more non-standard service classes with traffic
      characteristics not as defined here, or

   o  not use DiffServ within their domain.

   For example, low delay, low loss, and minimal jitter may be realized
   using the EF PHB, or with an over-provisioned AF PHB. This must be
   done with care as it may disrupt the end-to-end performance required
   by the applications/services. If the packet sizes are similar within
   an application, but different between two applications, say small
   voice packets and large video packets, these two applications may
   not realize optimum results if merged into the same aggregate if
   there are any bottlenecks in the network. We provide for this
   flexibility on a per hop or per domain basis within this document.

   This document provides standardized markings for traffic with
   similar characteristics, and usage expectations for PHBs for
   specific service classes for their consistent implementation.

   The Default Forwarding "Standard" service class is REQUIRED; all
   other service classes are OPTIONAL. That said, each service class
   lists traffic characteristics that are expected when using that type
   of traffic. It is RECOMMENDED that applications and protocols that
   fit a certain traffic characteristic use the appropriate service


Polk                    Expires August 25, 2013                [Page 9]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   class mark, i.e., the DSCP, for consistent behavior. It is expected
   that network administrators will base their endpoint application and
   router configuration choices on the level of service differentiation
   they require to meet the needs of their customers (i.e., their
   end-users).


1.4.  Key Differentiated Services Concepts

   In order to fully understand this document, a reader needs to
   familiarize themselves with the principles of the Differentiated
   Services Architecture [RFC2474].  We summarize some key concepts
   here only to provide convenience for the reader, the referenced RFCs
   providing the authoritative definitions.


1.4.1.  Queuing

   A queue is a data structure that holds packets that are awaiting
   transmission. A router interface can only transmit one packet at a
   time, however fast the interface speed is. If there is only 1 queue
   at an interface, the packets are transmitted in the order they are
   received into that queue - called FIFO, or "first in, first out".
   Sometimes there is a lag in the time between a packets arrives in
   the queue and when it is transmitted. This delay might be due to
   lack of bandwidth, or if there are multiple queues on that
   interface, because a packet is low in priority relative to other
   packets that are awaiting to transmit. The scheduler is the system
   entity that chooses which packet is next in line for transmission
   when more than one packet are awaiting transmission out the same
   router interface.


1.4.1.1 Priority Queuing

   A priority queuing system is a combination of a set of queues and a
   scheduler that empties the queues (of packets) in priority sequence.
   When asked for a packet, the scheduler inspects the highest
   priority queue and, if there is data present, returns a packet from
   that queue. Failing that, it inspects the next highest priority
   queue, and so on. A freeway onramp with a stoplight for one lane
   that allows vehicles in the high-occupancy-vehicle lane to pass is
   an example of a priority queuing system; the high-occupancy-vehicle
   lane represents the "queue" having priority.

   In a priority queuing system, a packet in the highest priority queue
   will experience a readily calculated delay.  This is proportional to
   the amount of data remaining to be serialized when the packet
   arrived plus the volume of the data already queued ahead of it in
   the same queue.  The technical reason for using a priority queue
   relates exactly to this fact: it limits delay and variations in
   delay and should be used for traffic that has that requirement.


Polk                    Expires August 25, 2013               [Page 10]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   A priority queue or queuing system needs to avoid starvation of
   lower-priority queues.  This may be achieved through a variety of
   means, such as admission control, rate control, or network
   engineering.

1.4.1.2.  Rate Queuing

   Similarly, a rate-based queuing system is a combination of a set of
   queues and a scheduler that empties each at a specified rate.  An
   example of a rate-based queuing system is a road intersection with a
   stoplight.  The stoplight acts as a scheduler, giving each lane a
   certain opportunity to pass traffic through the intersection.

   In a rate-based queuing system, such as Weighted Fair Queuing (WFQ)
   or Weighted Round Robin (WRR), the delay that a packet in any given
   queue will experience depends on the parameters and occupancy of its
   queue and the parameters and occupancy of the queues it is competing
   with.  A queue whose traffic arrival rate is much less than the rate
   at which it lets traffic depart will tend to be empty, and packets
   in it will experience nominal delays.  A queue whose traffic arrival
   rate approximates or exceeds its departure rate will tend not to be
   empty, and packets in it will experience greater delay.  Such a
   scheduler can impose a minimum rate, a maximum rate, or both, on any
   queue it touches.

1.4.2 Active Queue Management

   Active Queue Management, or AQM, is a generic name for any of a
   variety of procedures that use packet dropping or marking to manage
   the depth of a queue.  The canonical example of such a procedure is
   Random Early Detection (RED), in that a queue is assigned a minimum
   and maximum threshold, and the queuing algorithm maintains a moving
   average of the queue depth.  While the mean queue depth exceeds the
   maximum threshold, all arriving traffic is dropped.  While the mean
   queue depth exceeds the minimum threshold but not the maximum
   threshold, a randomly selected subset of arriving traffic is marked
   or dropped.  This marking or dropping of traffic is intended to
   communicate with the sending system, causing its congestion
   avoidance algorithms to kick in.  As a result of this behavior, it
   is reasonable to expect that TCP's cyclic behavior is desynchronized
   and that the mean queue depth (and therefore delay) should normally
   approximate the minimum threshold.

   A variation of the algorithm is applied in Assured Forwarding PHB
   [RFC2597], in that the behavior aggregate consists of traffic with
   multiple DSCP marks, which are intermingled in a common queue.
   Different minima and maxima are configured for the several DSCPs
   separately, such that traffic that exceeds a stated rate at ingress
   is more likely to be dropped or marked than traffic that is within
   its contracted rate.




Polk                    Expires August 25, 2013               [Page 11]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

1.4.3 Traffic Conditioning

   In addition, at the first router in a network that a packet crosses,
   arriving traffic may be measured and dropped or marked according to
   a policy, or perhaps shaped on network ingress, as in "A Rate
   Adaptive Shaper for Differentiated Services" [RFC2963].  This may be
   used to bias feedback loops, as is done in "Assured Forwarding PHB"
   [RFC2597], or to limit the amount of traffic in a system, as is done
   in "Expedited Forwarding PHB" [RFC3246].  Such measurement
   procedures are collectively referred to as "traffic conditioners".
   Traffic conditioners are normally built using token bucket meters,
   for example with a committed rate and burst size, as in Section
   1.5.3 of the DiffServ Model [RFC3290].  The Assured Forwarding PHB
   [RFC2597] uses a variation on a meter with multiple rate and burst
   size measurements to test and identify multiple levels of
   conformance.

   Multiple rates and burst sizes can be realized using multiple levels
   of token buckets or more complex token buckets; these are
   implementation details.  The following are some traffic conditioners
   that may be used in deployment of differentiated services:

   o  For Class Selector (CS) PHBs, a single token bucket meter to
      provide a rate plus burst size control.

   o  For Expedited Forwarding (EF) PHB, a single token bucket meter to
      provide a rate plus burst size control.

   o  For Assured Forwarding (AF) PHBs, usually two token bucket meters
      configured to provide behavior as outlined in "Two Rate Three
      Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color
      Marker  (srTCM)" [RFC2697].  The two-rate, three-color marker is
      used to enforce two rates, whereas the single-rate, three-color
      marker is used to enforce a committed rate with two burst
      lengths.


1.4.4 Differentiated Services Code Point (DSCP)

   The DSCP is a number in the range 0..63 that is placed into an IP
   packet to mark it according to the class of traffic it belongs in.
   These are divided into 3 groups, or pools, defined in RFC 2474,
   arranged as follows:

   o  Pool-1 has 32 values designated for standards assignment (of the
      form 'xxxxx0').

   o  Pool-2 has 16 values designated for experimental or local use
      only (EXP/LU) assignment (of the form 'xxxx11').

   o  Pool-3 has 16 values designated for experimental or local use
      (EXP/LU) assignment (of the form 'xxxx01').


Polk                    Expires August 25, 2013               [Page 12]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   However, pool-3 is allowed to be assigned for one of two reasons,

   #1 - if the values in pool-1 are exhausted, or

   #2 - if there is a justifiable reason for assigning a pool-3 DSCP
        prior to pool-1's exhaustion.


1.4.5 Per-Hop Behavior (PHB)

   In the end, the mechanisms described above are combined to form a
   specified set of characteristics for handling different kinds of
   traffic, depending on the needs of the application.  This document
   seeks to identify useful traffic aggregates and to specify what PHB
   should be applied to them.

1.5 Key Service Concepts

   While Differentiated Services is a general architecture that may be
   used to implement a variety of services, three fundamental
   forwarding behaviors have been defined and characterized for general
   use.  These are basic Default Forwarding (DF) behavior for elastic
   traffic, the Assured Forwarding (AF) behavior, and the Expedited
   Forwarding (EF) behavior for real-time (inelastic) traffic.  The
   facts that four code points are recommended for AF and that one code
   point is recommended for EF are arbitrary choices, and the
   architecture allows any reasonable number of AF and EF classes
   simultaneously.  The choice of four AF classes and one EF class in
   the current document is also arbitrary, and operators MAY choose to
   operate more or fewer of either.

   The terms "elastic" and "real-time" are defined in [RFC1633],
   Section 3.1, as a way of understanding broad-brush application
   requirements. This document should be reviewed to obtain a broad
   understanding of the issues in quality of service, just as [RFC2475]
   should be reviewed to understand the data plane architecture used in
   today's Internet.

1.5.1 Default Forwarding (DF)

   The basic forwarding behaviors applied to any class of traffic are
   those described in [RFC2474] and [RFC2309].  Best-effort service may
   be summarized as "I will accept your packets" and is typically
   configured with some bandwidth guarantee.  Packets in transit may be
   lost, reordered, duplicated, or delayed at random.  Generally,
   networks are engineered to limit this behavior, but changing traffic
   loads can push any network into such a state.

   Application traffic in the internet that uses default forwarding is
   expected to be "elastic" in nature.  By this, we mean that the
   sender of traffic will adjust its transmission rate in response to


Polk                    Expires August 25, 2013               [Page 13]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   changes in available rate, loss, or delay.

   For the basic best-effort service, a single DSCP value is provided
   to identify the traffic, a queue to store it, and active queue
   management to protect the network from it and to limit delays.

1.5.2 Assured Forwarding (AF)

   The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled
   on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss
   Priority (CLP) capability.  It is intended for networks that offer
   average-rate Service Level Agreements (SLAs) (as FR and ATM networks
   do).  This is an enhanced best-effort service; traffic is expected
   to be "elastic" in nature.  The receiver will detect loss or
   variation in delay in the network and provide feedback such that the
   sender adjusts its transmission rate to approximate available
   capacity.

   For such behaviors, multiple DSCP values are provided (two or three,
   perhaps more using local values) to identify the traffic, a common
   queue to store the aggregate, and active queue management to protect
   the network from it and to limit delays.  Traffic is metered as it
   enters the network, and traffic is variously marked depending on the
   arrival rate of the aggregate.  The premise is that it is normal for
   users occasionally to use more capacity than their contract
   stipulates, perhaps up to some bound.  However, if traffic should be
   marked or lost to manage the queue, this excess traffic will be
   marked or lost first.


1.5.3.  Expedited Forwarding (EF)

   The intent of Expedited Forwarding PHB [RFC3246] is to provide a
   building block for low-loss, low-delay, and low-jitter services.  It
   can be used to build an enhanced best-effort service: traffic
   remains subject to loss due to line errors and reordering during
   routing changes.  However, using queuing techniques, the probability
   of delay or variation in delay is minimized.  For this reason, it is
   generally used to carry voice and for transport of data information
   that requires "wire like" behavior through the IP network.  Voice is
   an inelastic "real-time" application that sends packets at the rate
   the codec produces them, regardless of availability of capacity.  As
   such, this service has the potential to disrupt or congest a network
   if not controlled.  It also has the potential for abuse.

   To protect the network, at minimum one SHOULD police traffic at
   various points to ensure that the design of a queue is not overrun,
   and then the traffic SHOULD be given a low-delay queue (often using
   priority, although it is asserted that a rate-based queue can do
   this) to ensure that variation in delay is not an issue, to meet
   application needs.



Polk                    Expires August 25, 2013               [Page 14]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

1.5.4 Class Selector (CS)

   Class Selector, those DSCPs that end in zeros (xxx000), provide
   support for historical codepoint definitions and PHB requirement.
   The CS fields provide a limited backward compatibility with legacy
   practice, as described in [RFC2474], Section 4.  Backward
   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 queuing
     requirements specified in [RFC1812]), and

   - this document will continue to permit their use in DS-compliant
     networks.

   In addition, there are some DSCPs that correspond to historical use
   of the IP Precedence field,

   - CS0 (000000) will remain 'Default Forwarding' (also known as 'Best
     Effort')

   - 11xxxx will remain for routing traffic

   and will map to PHBs that meet the general requirements specified in
   [RFC2474], Section 4.2.2.2.

   No attempt is made to maintain backward compatibility with the "DTR"
   or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in
   [RFC0791] and [RFC1349].

   A DS-compliant network can be deployed exclusively by using one or
   more CS-compliant PHB groups.  Thus, for example, codepoint '011000'
   would map to the same PHB as codepoint '011010'.


1.5.5 Admission Control

   Admission control (including refusal when policy thresholds are
   crossed) can ensure high-quality communication by ensuring the
   availability of bandwidth to carry a load.  Inelastic real-time
   flows such as Voice over Internet Protocol (VoIP) (audio) or video
   conferencing services can benefit from use of an admission control
   mechanism, as generally the audio or video service is configured
   with over-subscription, meaning that some users may not be able to
   make a call during peak periods.

   For VoIP (audio) service, a common approach is to use signaling
   protocols such as SIP, H.323, H.248, MEGACO, along with Resource
   Reservation Protocol (RSVP) to negotiate admittance and use of
   network transport capabilities.  When a user has been authorized to
   send voice traffic, this admission procedure has verified that data
   rates will be within the capacity of the network that it will use.


Polk                    Expires August 25, 2013               [Page 15]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   Many RTP voice and video payloads are inelastic and cannot react to
   loss or delay in any substantive way.  For these payload types, the
   network needs to police at ingress to ensure that the voice traffic
   stays within its negotiated bounds.  Having thus assured a
   predictable input rate, the network may use a priority queue to
   ensure nominal delay and variation in delay.


1.5.5.1 Capacity Admitted (*-Admit)

   This is a newer group of traffic types that started with RFC 5865
   and the Voice-Admit service type. Voice-Admit is an EF class marking
   but has capacity-admission always applied to it to ensure each of
   these flows are managed through a network, though not necessarily on
   an end-to-end basis. This depends on how many networks each flow
   transits and the load on each transited network.  There are a series
   of new DSCPs proposed in [ID-DSCP], each specifying unique
   characteristics necessitating a separate marking from what existing
   before that document.

   This document will import in four new '*-Admit' DSCPs from
   [ID-DSCP], 2 others that are new but not capacity-admitted, one from
   RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594.
   This is discussed throughout the rest of this document.


1.6 What Changes are Proposed Here from RFC 4594?

   Changing an entire network DiffServ configuration has proven to be a
   painful experience for both individuals and companies. It is not
   done very often, and for good reason. This effort is based on
   experience learned since the publication of RFC 4594 (circa 2006).
   Audio, once thought to be ok grouped with video, needs to be in
   separate service classes. Collaboration has taken off, mostly
   because of mobility, but also because of a worldwide recession that
   has limited physical travel, and relying on people to do more with
   their computers. With that in mind, there has been an explosion in
   application development for the individual (seems everyone has an
   "app-store"). The following set of bullets has this world - that
   needs a robust layer 3 - in mind.

   o Scope of document is changed to tighten it up for standards track
     consideration.

   o This document explicitly states there is a fundamental requirement
     that a particular DSCP(s) be used for each service class, each
     with a recommended set of applications to be used by that service
     class - at least on that individual's externally facing (public)
     interface.

   o Created the Conversational group of service classes to focus on
     realtime, mostly bidirectional communications (unless multicast is


Polk                    Expires August 25, 2013               [Page 16]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

     used).

     o "Realtime-Interactive"
          Moved to (near) realtime TCP-based apps

   Why the change? TCP based transports have proven, in certain
   environments, to be a bidirectional realtime transport, e.g., for
   multiplayer gaming and virtual desktops applications.

     o "Audio"
          Same as Telephony (which is now gone), adds Voice-Admit for
          capacity-admitted traffic

   Why the change? RFC 5865 (Voice-Admit) needed to be added to the
   Audio service class. Video needed to be separate from audio, hence
   the name change from Telephony (which includes video) to just audio.

     o "Video"
          NEW for video and audio/video conferencing, was in
          Multimedia-Conferencing service classification

   Why the change? Many networks are using the AF4X for video, but
   others are throwing anything "multimedia" into the same service
   class (like elastic TCP flows). Video has become so dominant that it
   should be what mostly goes into one service class.

     o "Hi-Res"
          NEW for video and audio/video conferencing

   Why the change? This entirely new service class is for local policy
   based higher end video (think Telepresence). Without congestion,
   this service class has the same treatment as Video, but if there is
   any pushback from the network, Hi-Res (note: not married to the
   name) has a better PHB.

     o "Multimedia-Conferencing"
          Now without audio or human video

   Why the change? The change is taking bidirectional human audio and
   video out of this service class. This is all about non-realtime
   collaboration - even in conjunction with an audio and/or video flow.

     o "Broadcast"
          Remains the same, added CS3-Admit for capacity-admitted

   Why the change? Removing the "-Video" from the name because there
   are so many more flows that are Broadcast in realtime than video.

     o "Low-Latency Data"
          Remains the same, adds IM & Presence traffic explicitly

   Why the change? Merely explicitly stating a place for some


Polk                    Expires August 25, 2013               [Page 17]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   additional traffic types that otherwise could go elsewhere.

     o "Conversational Signaling" (A/V-Sig)
          Was 'Signaling'

   Why the change? This change is merely a renaming of a service class,
   and acknowledgement that some of the previous authors inaccurate
   beliefs that DSCPs were linearly ordered with those values having a
   higher value definitely getting better treatment than lower values.


2.  Service Differentiation

   There are practical limits on the level of service differentiation
   that should be offered in the IP networks.  We believe we have
   defined a practical approach in delivering service differentiation
   by defining different service classes that networks may choose to
   support in order to provide the appropriate level of behaviors and
   performance needed by current and future applications and services.
   The defined structure for providing services allows several
   applications having similar traffic characteristics and performance
   requirements to be grouped into the same service class.  This
   approach provides a lot of flexibility in providing the appropriate
   level of service differentiation for current and new, yet unknown
   applications without introducing significant changes to routers or
   network configurations when a new traffic type is added to the
   network.


2.1 Service Classes

   Traffic flowing in a network can be classified in many different
   ways.  We have chosen to divide it into two groupings, network
   control and user/subscriber traffic.  To provide service
   differentiation, different service classes are defined in each
   grouping.  The network control traffic group can further be divided
   into two service classes (see Section 3 for detailed definition of
   each service class):

   o  "Network Control" for routing and network control function.

   o  "OAM" (Operations, Administration, and Management) for network
      configuration and management functions.

   The user/subscriber traffic group is broken down into ten service
   classes to provide service differentiation for all the different
   types of applications/services (see Section 4 for detailed
   definition of each service class):

   o  Conversational service group consists of three service classes:

      -  Audio, which includes both 'admitted' and 'unadmitted' audio


Polk                    Expires August 25, 2013               [Page 18]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

         service classes, is for non-one way (i.e., generally
         bidirectional) audio media packets between human users of
         smaller size and at a constant delivery rate.

      -  Hi-Res Video, which includes both 'admitted' and 'unadmitted'
         Hi-Res Video service classes, is for video traffic from higher
         end endpoints between human users necessitating different
         treatment that from desktop or video phone endpoints. This has
         a clearly business differentiation, and not a technical
         differentiation - as both Hi-Res-Video and Video will be
         treated similarly on the wire when no congestion occurs.

      -  Video, which includes both 'admitted' and 'unadmitted' video
         service classes, is for video traffic from lower end endpoints
         between human users necessitating different treatment that
         from higher end (i.e., Telepresence) endpoints. This has a
         clearly business differentiation, and not a technical
         differentiation - as both Hi-Res-Video and Video will be
         treated similarly on the wire when no congestion occurs.

   o  Conversational Signaling service class is for peer-to-peer and
      client-server signaling and control functions using protocols
      such as SIP, H.323, H.248, and Media Gateway Control Protocol
      (MGCP). This traffic needs to not be starved on the network.

   Editor's note: RFC 4594 had this DSCP marking as CS5, but with
                  clearly different characteristics (i.e., no
                  sensitivity to jitter or (unreasonable) delay), this
                  DSCP has been moved to a more appropriate (new)
                  value, defined in [ID-DSCP].

   o  Real-Time Interactive, which includes both 'admitted' and
      'unadmitted' Realtime-Interactive service class, is for
      bidirectional variable rate inelastic applications that require
      low jitter and loss and very low delay, such as interactive
      gaming applications that use RTP/UDP streams for game control
      commands, and Virtualized Desktop applications between the user
      and content source, typically in a centralized data center.

   o  Multimedia Conferencing, which includes both 'admitted' and
      'unadmitted' multimedia conferencing service class, is for
      applications that require minimal delay, but not like those of
      realtime application requirements. This service class can be
      bursty in nature, as well as not transmit packets for some time.
      Applications such as presentation data or collaborative
      application sharing will use this service class.

   o  Multimedia Streaming, which includes both 'admitted' and
      'unadmitted' multimedia streaming service class, is for one-way
      bufferable streaming media applications such as Video on Demand
      (VOD) and webcasts.



Polk                    Expires August 25, 2013               [Page 19]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   o  Broadcast, which includes both 'admitted' and 'unadmitted'
      broadcast service class, is for inelastic streaming media
      applications that may be of constant or variable rate, requiring
      low jitter and very low packet loss, such as broadcast TV and
      live events, video surveillance, and security.

   o  Low-Latency Data service class is for data processing
      applications such as client/server interactions or Instant
      Messaging (IM) and Presence data.

   o  Conversational Signaling (A/V-Sig) service class is for all
      signaling messages, whether in-band (i.e., along the data path)
      or out-of-band (separate from the data path), for the purposes of
      setting up, maintaining, managing and terminating bi- or
      multi-directional realtime sessions.

   o  High-Throughput Data service class is for store and forward
      applications such as FTP and billing record transfer.

   o  Standard service class, commonly called best effort (BE), is for
      traffic that has not been identified as requiring differentiated
      treatment.

   o  Low-Priority Data service class, which some could call the
      scavenger class, is for packet flows where bandwidth assurance is
      not required.


2.2 Categorization of User Oriented Service Classes

   The ten defined user/subscriber service classes listed above can be
   grouped into a small number of application categories.  For some
   application categories, it was felt that more than one service class
   was needed to provide service differentiation within that category
   due to the different traffic characteristic of the applications,
   control function, and the required flow behavior.  Figure 1 provides
   a summary of service class grouping into four application categories.

   Application Control Category

   o  The Conversational Signaling service class is intended to be used
      to control applications or user endpoints.  Examples of protocols
      that would use this service class are SIP, XMPP or H.323 for
      voice and/or video over IP services.  User signaling flows have
      similar performance requirements as Low-Latency Data, they
      require a separate DSCP to be distinguished other traffic and
      allow for a treatment that is unique.

   Media-Oriented Category

   Due to the vast number of new (in process of being deployed) and
   already-in-use media-oriented services in IP networks, seven service


Polk                    Expires August 25, 2013               [Page 20]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   classes have been defined.

   o  Audio service class is intended for Voice-over-IP (VoIP)
      services.  It may also be used for other applications that meet
      the defined traffic characteristics and performance requirements.

   o  Video service class is intended for Video over IP services. It
      may also be used for other applications that meet the defined
      traffic characteristics and performance requirements.

   o  Hi-Res service class is intended for higher end video services
      that have the same traffic characteristics as the video service
      class, but have a business requirement(s) to be treated
      differently. One example of this is Telepresence video
      applications.

   o  Realtime-Interactive service class is intended for inelastic
      applications such as desktop virtualization applications and for
      interactive gaming.

   o  Multimedia Conferencing service class is for everything about or
      within video conferencing solutions that does not include the
      voice or (human) video components. Several examples are

      - the presentation data part of an IP conference (call).

      - the application sharing part of an IP conference (call).

      - the whiteboarding aspect of an IP conference (call).

      Each of the above can be part of a lower end web-conferencing
      application or part of a higher end Telepresence video
      conference. Each also has the ability to reduce their
      transmission rate on detection of congestion.  These flows can
      therefore be classified as rate adaptive and most often more
      elastic than their voice and video counterparts.

   o  Broadcast Video service class is to be used for inelastic traffic
      flows specifically with minimal buffering expected by the source
      or destination, which are intended for broadcast HDTV service, as
      well as for transport of live video (sports or concerts) and
      audio events.

   o  Multimedia Streaming service class is to be used for elastic
      multimedia traffic flows where buffering is expected.  This is
      the fundamental difference between the Broadcast and multimedia
      streaming service classes. Multimedia streaming content is
      typically stored before being transmitted.  It is also buffered
      at the receiving end before being played out.  The buffering is
      sufficiently large to accommodate any variation in transmission
      rate that is encountered in the network.  Multimedia
      entertainment over IP delivery services that are being developed


Polk                    Expires August 25, 2013               [Page 21]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

      can generate both elastic and inelastic traffic flows; therefore,
      two service classes are defined to address this space,
      respectively: Multimedia Streaming and Broadcast Video.

   Data Category

   The data category is divided into three service classes.

   o  Low-Latency Data for applications/services that require low delay
      or latency for bursty but short-lived flows.

   o  High-Throughput Data for applications/services that require good
      throughput for long-lived bursty flows.  High Throughput and
      Multimedia Steaming are close in their traffic flow
      characteristics with High Throughput being a bit more bursty and
      not as long-lived as Multimedia Streaming.

   o  Low-Priority Data for applications or services that can tolerate
      short or long interruptions of packet flows.  The Low-Priority
      Data service class can be viewed as "don't care" to some degree.

   Best-Effort Category

   o  All traffic that is not differentiated in the network falls into
      this category and is mapped into the Standard service class.  If
      a packet is marked with a DSCP value that is not supported in the
      network, it SHOULD be forwarded using the Standard service class.

   Figure 1, below, provides a grouping of the defined user/subscriber
   service classes into four categories, with indications of which ones
   use an independent flow for signaling or control; type of flow
   behavior (elastic, rate adaptive, or inelastic); and the last column
   provides end user Class of Service (CoS) rating as defined in ITU-T
   Recommendation G.1010.

    -----------------------------------------------------------------
   | Application |    Service    | Signaled |  Flow     |   G.1010   |
   |  Categories |     Class     |          | Behavior  |   Rating   |
   |-------------+---------------+----------+-----------+------------|
   | Application |   A/V Sig     |   Not    | Inelastic | Responsive |
   |   Control   |               |applicable|           |            |
   |-------------+---------------+----------+-----------+------------|
   |             |   Realtime    |   Yes    | Inelastic | Interactive|
   |             |   Interactive |          |           |            |
   |             |---------------+----------+-----------+------------|
   |             |   Audio       |   Yes    | Inelastic | Interactive|
   |             |---------------+----------+-----------+------------|
   |             |   Video       |   Yes    | Inelastic | Interactive|
   |             |---------------+----------+-----------+------------|
   |             |   Hi-Res      |   Yes    | Inelastic | Interactive|
   |             |---------------+----------+-----------+------------|
   |    Media-   |   Multimedia  |   Yes    |    Rate   | Moderately |


Polk                    Expires August 25, 2013               [Page 22]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   |   Oriented  |   Conferencing|          |  Adaptive | Interactive|
   |             |---------------+----------+-----------+------------|
   |             |   Broadcast   |   Yes    | Inelastic | Responsive |
   |             |---------------+----------+-----------+------------|
   |             |   Multimedia  |   Yes    |  Elastic  |   Timely   |
   |             |   Streaming   |          |           |            |
   |-------------+---------------+----------+-----------+------------|
   |             |   Low-Latency |    No    |  Elastic  | Responsive |
   |             |   Data        |          |           |            |
   |             |---------------+----------+-----------+------------|
   |   Data      | Conversational|    No    |Elastic or |   Timely   |
   |             |   Signaling   |          | Inelastic |            |
   |             |---------------+----------+-----------+------------|
                     High-       |    No    |  Elastic  |   Timely   |
   |             |Throughput Data|          |           |            |
   |             |---------------+----------+-----------+------------|
   |             |   Low-        |    No    |  Elastic  |Non-critical|
   |             | Priority Data |          |           |            |
   |-------------+---------------+----------+-----------+------------|
   | Best Effort |   Standard    |    Not Specified     |Non-critical|
    -----------------------------------------------------------------

           Figure 1. User/Subscriber Service Classes Grouping


   Here is a short explanation of the end user CoS category as defined
   in ITU-T Recommendation G.1010.  User oriented traffic is divided
   into four different categories, namely, interactive, responsive,
   timely, and non-critical.  An example of interactive traffic is
   between two humans and is most sensitive to delay, loss, and jitter.
   Another example of interactive traffic is between two servers where
   very low delay and loss are needed.  Responsive traffic is typically
   between a human and a server but can also be between two servers.
   Responsive traffic is less affected by jitter and can tolerate
   longer delays than interactive traffic.  Timely traffic is either
   between servers or servers and humans and the delay tolerance is
   significantly longer than responsive traffic.  Non-critical traffic
   is normally between servers/machines where delivery may be delay for
   period of time.

2.3.  Service Class Characteristics

   This document specifies what network administrators are to expect
   when configuring service classes identified by their differing
   characteristics. Figure 2 identifies these service classes along
   with their characteristics, as well as the tolerance to loss, delay
   and jitter for each service class. Properly engineered networks to
   these PHBs will achieve expected results. That said, not all of the
   identified service classes are expected in each operator's network.


  -------------------------------------------------------------------


Polk                    Expires August 25, 2013               [Page 23]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

 |Service Class  |                              |    Tolerance to    |
 |    Name       |  Traffic Characteristics     | Loss |Delay |Jitter|
 |===============+==============================+======+======+======|
 |  Network      |Variable size packets, mostly |      |      |      |
 |  Control      |inelastic short messages, but |  Low |  Low |  Yes |
 |               |traffic can also burst (BGP)  |      |      |      |
 |---------------+------------------------------+------+------+------|
 |  Realtime     | Inelastic, mostly variable   | Low  | Very | Low  |
 |  Interactive  | rate                         |      | Low  |      |
 +---------------+------------------------------+------+------+------+
 |               | Fixed-size small packets,    | Very | Very | Very |
 |  Audio        | inelastic                    |  Low |  Low |  Low |
 |               |                              |      |      |      |
 +---------------+------------------------------+------+------+------+
 |               | Fixed-size small-large       | Very | Very | Very |
 |  Video        | packets, inelastic           |  Low |  Low |  Low |
 |               |                              |      |      |      |
 +---------------+------------------------------+------+------+------+
 |               | Fixed-size small-large       | Very | Very | Very |
 |  Hi-Res A/V   | packets, inelastic           |  Low |  Low |  Low |
 |               |                              |      |      |      |
 +---------------+------------------------------+------+------+------+
 |  Multimedia   | Variable size packets,       | Low  | Low  | Low  |
 |  Conferencing | constant transmit interval,  |  -   |  -   |  -   |
 |               | rate adaptive, reacts to loss|Medium|Medium|Medium|
 +---------------+------------------------------+------+------+------+
 |  Multimedia   | Variable size packets,       |Low - |Medium| High |
 |  Streaming    | elastic with variable rate   |Medium|      |      |
 +---------------+------------------------------+------+------+------+
 |  Broadcast    | Constant and variable rate,  | Very |Medium|  Low |
 |               | inelastic, non-bursty flows  |  Low |      |      |
 +---------------+------------------------------+------+------+------+
 |  Low-Latency  | Variable rate, bursty short- | Low  |Low - |  Yes |
 |      Data     |  lived elastic flows         |      |Medium|      |
 |---------------+------------------------------+------+------+------|
 |Conversational | Variable size packets, some  | Low  | Low  |  Yes |
 |   Signaling   | what bursty short-lived flows|      |      |      |
 |---------------+------------------------------+------+------+------|
 |  OAM          |  Variable size packets,      | Low  |Medium|  Yes |
 |               |  elastic & inelastic flows   |      |      |      |
 |---------------+------------------------------+------+------+------|
 |  High-        | Variable rate, bursty long-  | Low  |Medium|  Yes |
 |Throughput Data|   lived elastic flows        |      |- High|      |
 |---------------+------------------------------+------+------+------|
 |  Standard     | A bit of everything          |  Not Specified     |
 |---------------+------------------------------+------+------+------|
 |  Low-Priority | Non-real-time and elastic    | High | High | Yes  |
 |      Data     |                              |      |      |      |
  -------------------------------------------------------------------

               Figure 2. Service Class Characteristics



Polk                    Expires August 25, 2013               [Page 24]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   Notes for Figure 2: A "Yes" in the jitter-tolerant column implies
   that received data is buffered at the endpoint and that a moderate
   level of server or network-induced variation in delay is not
   expected to affect the application. Applications that use TCP or
   SCTP as a transport are generally good examples. Routing protocols
   and peer-to-peer signaling also fall in this class; although loss
   can create problems in setting up calls, a moderate level of jitter
   merely makes call placement a little less predictable in duration.

   Service classes indicate the required traffic forwarding treatment
   in order to meet user, application, and/or network expectations.
   Section 3 defines the service classes that MAY be used for
   forwarding network control traffic, and Section 4 defines the
   service classes that MAY be used for forwarding user oriented
   traffic with examples of intended application types mapped into each
   service class.  Note that the application types are only examples
   and are not meant to be all-inclusive or prescriptive.  Also, note
   that the service class naming or ordering does not imply any
   priority ordering.  They are simply reference names that are used in
   this document with associated QoS behaviors that are optimized for
   the particular application types they support.  Network
   administrators MAY choose to assign different service class names to
   the service classes that they will support. Figure 3 defines the
   RECOMMENDED relationship between service classes and DS codepoint
   assignment with application examples.  It is RECOMMENDED that this
   relationship be preserved end to end.


   +------------------------------------------------------------------+
   |   Service     |  DSCP   |    DSCP     |       Application        |
   |  Class Name   |  Name   |    Value    |        Examples          |
   |===============+=========+=============+==========================|
   |Network Control| CS6&CS7 |   11xxxx    | Network routing          |
   |---------------+---------+-------------+--------------------------|
   |  Realtime     | CS5,    |   101000,   | Remote/Virtual Desktop   |
   |  Interactive  |CS5-Admit|   101001    | and Interactive gaming   |
   |---------------+---------+-------------+--------------------------|
   |  Audio        |  EF     |   101110    | Voice bearer             |
   |               |Voice-Admit| 101100    |                          |
   |---------------+---------+-------------+--------------------------|
   |  Hi-Res A/V   | CS4,    |   100000,   | Conversational Hi-Res    |
   |               |CS4-Admit|   100001    | Audio/Video bearer       |
   |---------------+---------+-------------+--------------------------|
   |  Video        |AF41,AF42|100010,100100| Audio/Video conferencing |
   |               |  AF43   |   100110    | bearer                   |
   |---------------+---------+-------------+--------------------------|
   |  Multimedia   |  MC,    |   011101,   | Presentation Data and    |
   |  Conferencing | MC-Admit|   100101    | App Sharing/Whiteboarding|
   |---------------+---------+-------------+--------------------------|
   |  Multimedia   |AF31,AF32|011010,011100| Streaming video and      |
   |  Streaming    |  AF33   |   011110    | audio on demand          |
   |---------------+---------+-------------+--------------------------|


Polk                    Expires August 25, 2013               [Page 25]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   |  Broadcast    | CS3,    |   011000,   | Broadcast TV, live events|
   |               |CS3-Admit|   011001    | & video surveillance     |
   |---------------+---------+-------------+--------------------------|
   |  Low-Latency  |AF21,AF22|010010,010100|Client/server trans., Web-|
   |  Data         |  AF23   |   010110    |based ordering, IM/Pres   |
   |---------------+---------+-------------+--------------------------|
   |Conversational | A/V-Sig |   010001    | Conversational signaling |
   |  Signaling    |         |             |                          |
   |---------------+---------+-------------+--------------------------|
   |  OAM          |  CS2    |   010000    | OAM&P                    |
   |---------------+---------+-------------+--------------------------|
   |High-Throughput|AF11,AF12|001010,001100| Store and forward        |
   |  Data         |  AF13   |   001110    | applications             |
   |---------------+---------+-------------+--------------------------|
   |  Low-Priority |  CS1    |   001000    | Any flow that has no BW  |
   |  Data         |         |             | assurance                |
   |------------------------------------------------------------------|
   |  Best Effort  |  CS0    |   000000    | Undifferentiated         |
   |               |         |             | applications             |
   +---------------+---------+-------------+--------------------------+

                Figure 3. DSCP to Service Class Mapping

   Notes for Figure 3:

   o  Default Forwarding (DF) and Class Selector 0 (CS0) (i.e., Best
      Effort) provide equivalent behavior and use the same DS
      codepoint, '000000'.

   o  RFC 2474 identifies any DSCP with a value of 11xxxx to be for
      network control. This remains true, while it removes 12 DSCPs
      from the overall pool of 64 available DSCP values (the 4 that are
      x11 from this group are within pool 2 of RFC 2474, and remain as
      only experimentally assignable/useable).

   o  All PHB names that say "-Admit" are to be used only when a
      capacity-admission protocol is utilized for that or each traffic
      flow.

   Changes from table 3 of RFC 4594 are as follows:

   o  The old term "Signaling" was using CS5 (101000), now is
      exclusively for the "Conversational Signaling" service group
      using the DSCP name of "A/V-Sig" (010001), which is newly defined
      in [ID-DSCP]. This is because CS5 aggregates into the 101xxx
      aggregate when using layer 2 technologies such as 802.3 Ethernet,
      802.11 Wireless Ethernet MPLS, etc - each of which only have 3
      bits to mark with. A traffic type that can have very large
      packets and is not delay sensitive (within reason) is not
      appropriate for have a 101xxx marking. A REQUIRED behavior for
      this PHB is that it not be starved in any node.



Polk                    Expires August 25, 2013               [Page 26]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   o  "Conversational" is a new term to include all interactive audio
      and video. The Conversational service group consists of the audio
      service class, the video service class and the new Hi-Res service
      class.

   o  "Audio" obsoletes the term "Telephony", which has generally not
      retained the "video" aspect within the IETF, where video is still
      commonly called out as a separate thing. Audio retains the
      nonadmitted traffic PHB of EF (101110), while capacity-admitted
      audio has been added via the RFC 5865 defined PHB Voice-Admit.

   o  "Video" now is AF4x, with AF41 specifically for capacity-admitted
      video traffic, while AF42 and AF43 are nonadmitted video traffic.

   o  "Hi-Res A/V", part of the Conversational service group, is
      created by [ID-DSCP] for an additional business differentiation
      interactive video marking for higher end traffic. It is within
      the 100xxx as CS4 (for nonadmitted traffic) and CS4-Admit
      (100001) (for capacity-admitted traffic).

   o  "Realtime Interactive" is now using CS5 (for nonadmitted
      traffic), but adds a capacity-admitted DSCP CS5-Admit (101001).

   o  "Multimedia Conferencing" is no longer using the AF4x DSCPs,
      rather it will use the new PHB MC (100101) (for
      capacity-admitted) and MC-Admit (011101) (for nonadmitted
      traffic).

   o  "Multimedia Streaming" retains using AF3x, however, AF31 is now
      used for capacity-admitted traffic, while AF32/33 are
      nonadmitted.

   o  "Broadcast" replaces "Broadcast Video" using CS3 (for nonadmitted
      traffic), and adds a capacity-admitted PHB CS3-Admit (011001).

   It is expected that network administrators will base their choice of
   the service classes that they will support on their need.

   Figure 4 provides a summary of DiffServ CoS mechanisms that MUST be
   used for the defined service classes that are further detailed in
   Sections 3 and 4 of this document.  According to what
   applications/services need to be differentiated, network
   administrators MAY choose the service class(es) that need to be
   supported in their network.

   +-----------------------------------------------------------------+
   |  Service      |  DSCP | Conditioning at   |  PHB  | Queuing| AQM|
   |   Class       |       |    DS Edge        | Used  |        |    |
   |===============+=======+===================+=======+========+====|
   |Network Control|CS6/CS7| See Section 3.1   |RFC2474|  Rate  | Yes|
   |---------------+-------+-------------------+-------+--------+----|
   |  Realtime     | CS5,  |Police using sr+bs |RFC2474|  Rate  | No |


Polk                    Expires August 25, 2013               [Page 27]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   |  Interactive  | CS5-  |                   |       |        |    |
   |               | Admit*|                  |[ID-DSCP]|       |    |
   |---------------+-------+-------------------+-------+--------+----|
   |               |  EF,  |Police using sr+bs |RFC3246|Priority| No |
   |   Audio       |Voice- |                   |       |        |    |
   |               | Admit*|                   |RFC5865|        |    |
   |---------------+-------+-------------------+-------+--------+----|
   |               | CS4,  |Police using sr+bs |RFC2474|Priority| No |
   |  Hi-Res A/V   | CS4-  |                   |       |        |    |
   |               | Admit*|                  |[ID-DSCP]|       |    |
   |---------------+-------+-------------------+-------+--------+----|
   |               | AF41*,|  Using two-rate,  |       |        | Yes|
   |   Video       |  AF42 |three-color marker |RFC2597|  Rate  | per|
   |               |  AF43 | (such as RFC 2698)|       |        |DSCP|
   |---------------+-------+-------------------+-------+--------+----|
   |  Multimedia   | MC,   |Police using sr+bs|[ID-DSCP]| Rate  | No |
   | Conferencing  | MC-   |                   |       |        |    |
   |               | Admit*|                  |[ID-DSCP]|       |    |
   |---------------+-------+-------------------+-------+--------+----|
   |  Multimedia   | AF31*,|  Using two-rate,  |       |        | Yes|
   |  Streaming    |  AF32 |three-color marker |RFC2597|  Rate  | per|
   |               |  AF33 | (such as RFC 2698)|       |        |DSCP|
   |---------------+-------+-------------------+-------+--------+----|
   |  Broadcast    | CS3,  |Police using sr+bs |RFC2474|  Rate  | No |
   |               | CS3-  |                   |       |        |    |
   |               | Admit*|                  |[ID-DSCP]|       |    |
   |---------------+-------+-------------------+-------+--------+----|
   |    Low-       | AF21  | Using single-rate,|       |        | Yes|
   |    Latency    | AF22  |three-color marker |RFC2597|  Rate  | per|
   |    Data       | AF23  | (such as RFC 2697)|       |        |DSCP|
   |---------------+-------+-------------------+-------+--------+----|
   |Conversational |AV-Sig |Police using sr+bs|[ID-DSCP]| Rate  | No |
   |  Signaling    |       |                   |       |        |    |
   |---------------+-------+-------------------+-------+--------+----|
   |     OAM       | CS2   |Police using sr+bs |RFC2474|  Rate  | Yes|
   |---------------+-------+-------------------+-------+--------+----|
   |    High-      | AF11  |  Using two-rate,  |       |        | Yes|
   |  Throughput   | AF12  |three-color marker |RFC2597|  Rate  | per|
   |    Data       | AF13  | (such as RFC 2698)|       |        |DSCP|
   |---------------+-------+-------------------+-------+--------+----|
   |   Standard    | DF    | Not applicable    |RFC2474|  Rate  | Yes|
   |---------------+-------+-------------------+-------+--------+----|
   | Low-Priority  | CS1   | Not applicable    |RFC3662|  Rate  | Yes|
   |     Data      |       |                   |       |        |    |
   |---------------+-------+-------------------+-------+--------+----|

     Figure 4. Summary of CoS Mechanisms Used for Each Service Class

   * denotes each DSCP identified for capacity-admission traffic only.

   Notes for Figure 4:



Polk                    Expires August 25, 2013               [Page 28]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   o  Conditioning at DS edge means that traffic conditioning is
      performed at the edge of the DiffServ network where untrusted
      user devices are connected to two different administrative
      DiffServ networks.

   o  "sr+bs" represents a policing mechanism that provides single rate
      with burst size control.

   o  The single-rate, three-color marker (srTCM) behavior SHOULD be
      equivalent to RFC 2697, and the two-rate, three-color marker
      (trTCM) behavior SHOULD be equivalent to RFC 2698.

   o  The PHB for Realtime-Interactive service class SHOULD be
      configured to provide high bandwidth assurance.  It MAY be
      configured as another EF PHB (one capacity-admitted and one
      non-capacity-admitted, if both are to be used) that uses relaxed
      performance parameters and a rate scheduler.

   o  The PHB for Multimedia Conferencing service class SHOULD be
      configured to provide high bandwidth assurance.  It MAY be
      configured as another EF PHB (one capacity-admitted and one
      non-capacity-admitted, if both are to be used) that uses relaxed
      performance parameters and a rate scheduler.

   o  The PHB for Broadcast service class SHOULD be configured to
      provide high bandwidth assurance.  It MAY be configured as
      another EF PHB (one capacity-admitted and one
      non-capacity-admitted, if both are to be used) that uses relaxed
      performance parameters and a rate scheduler.


2.4. Service Classes vs. Treatment Aggregates (from RFC 5127)

   There are misconceptions about the differences between RFC 4594
   specified service classes, and RFC 5127 specified treatment
   aggregates. Often the two are conflated, and more often the phrase
   service class is used to mean both definitions. Almost all of the
   text previous to this section is used in defining service classes,
   and how one service class is different than another service class
   (based on traffic characteristics of the applications). Treatment
   aggregates are groupings of service classes with similar, but not
   identical, traffic characteristics to give similar treatment from a
   SP's network.

   Below is taken from appendix of RFC 5127 as its recommended
   groupings of service classes into aggregates based in RFC 4594
   specified traffic characteristic expectations.

   +------------------------------------------------------------+
   |Treatment |Treatment || DSCP                                |
   |Aggregate |Aggregate ||                                     |
   |          |Behavior  ||                                     |


Polk                    Expires August 25, 2013               [Page 29]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   |==========+==========++=====================================|
   | Network  | CS       || CS6                                 |
   | Control  |(RFC 2474)||                                     |
   |==========+==========++=====================================|
   | Real-    | EF       || EF, CS5, AF41, AF42, AF43, CS4, CS3 |
   | Time*    |(RFC 3246)||                                     |
   |==========+==========++=====================================|
   | Assured  | AF       || CS2, AF31, AF21, AF11               |
   | Elastic  |(RFC 2597)||-------------------------------------|
   |          |          || AF32, AF22, AF12                    |
   |          |          ||-------------------------------------|
   |          |          || AF33, AF23, AF13                    |
   |==========+==========++=====================================|
   | Elastic  | Default  || Default, (CS0)                      |
   |          |(RFC 2474)||-------------------------------------|
   |          |          || CS1                                 |
   +------------------------------------------------------------+

        Figure 5: RFC 5127 Defined Treatment Aggregate Behavior**

   *NOTE: The RFC 5865 created VOICE-ADMIT is absence from the above
          figure because VOICE-ADMIT was created far later than this
          recommendation was. VOICE-ADMIT is appropriate for the
          Realtime Traffic Aggregate.

  **NOTE: Figure 5 is directly from the appendix of RFC 5127 as that
          RFC's recommendation for configuration. This draft does not
          directly affect RFC 5127. That is left for an update to RFC
          5127 itself. Based on the WG's take on this draft, RFC 5127
          will necessitate an update to match this document's new
          service classes and additional DSCPs. The number of treatment
          aggregates are not expected to change in the RFC 5127 Update
          draft though, with the possible exception of a new treatment
          aggregate for capacity admitted flows; meaning there *might*
          be a 5th treatment aggregate proposed.

   Treatment Aggregates are designed to nicely fit into technologies
   that do not have many different treatment levels to use. Here are 3
   examples of technologies limited to an 8-value field,

   - MPLS with its 3 Traffic Class (TC) bits [RFC5462].

   - IEEE LANs with its 8-value Priority Code Point (PCP) field, as
     part of the 802.1Q header spec [IEEE1Q].

   - IEEE 802.1e, which defines QoS over Wi-Fi, also only defines 8
     levels (called User Priority or UP codes) [IEEE1E].

   Treatment Aggregates are dependent on service classes to exist.
   Therefore many service classes can exist without the need to
   consider the use of treatment aggregates or their 8-value
   technologies. For example, a Layer 3 VPN can be all that is needed


Polk                    Expires August 25, 2013               [Page 30]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   to transit traffic flows, regardless of desired treatment, between
   enterprise LAN campuses. From this reality, the number of treatment
   aggregates has no direct bearing on the number of service classes.


2.4.1 Examples of Service Classes in Treatment Aggregates

   It is *not* expected that all traffic characteristics are to be
   experienced across an SP's network for any given customer. For
   example, if VOICE-ADMIT is added to the Realtime Treatment Aggregate
   in Figure 5, there are 8 different service classes within the
   Realtime Treatment Aggregate. It is not expected that all 8 service
   classes will be deployed by customer networks traversing SP
   networks. RFC 5127's Treatment Aggregates are a table to configure
   which service class goes into which treatment aggregate. If there
   are 8 services classes in the Realtime treatment aggregate, there is
   very little difference than if there were one service within that
   same Realtime treatment aggregate - it would still be necessary to
   configure that treatment aggregate. Thus, it becomes a question of
   not

      "how many service classes are there that go into treatment
       aggregates?"

   but

      "how many treatment aggregates have one or more services
       classes requiring configuration"?

   Of the 4 treatment aggregates shown in Figure 5, if there are
   existing service classes in only 3 of the aggregates, then only 3
   treatment aggregates are necessary. Of the 3 following examples,
   notice that examples 2 and 3 have the same number of treatment
   aggregates, but example 3 has more applications in their own
   service classes.

   Examples 2 and 3 are made under the following assumptions:

   - this draft's Service Classes and DSCP assignments are utilized.

   - the new AF-Sig DSCP in the Assured Elastic treatment aggregate.

   - the Audio, Video service classes are in the EF treatment
     aggregate.

   - the VOICE-ADMIT DSCP is in the EF treatment aggregate.


2.4.1.1 Example 1 - Simple Voice Configuration/SLA

   For example 1, we have an SP running MPLS and has an SLA to deliver
   Network Control, Voice and everything else is Best Effort. The


Polk                    Expires August 25, 2013               [Page 31]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   following table would apply to this configuration/SLA:

   +----------------+----------------+-----------+--------------+
   |  Applications  |    Service     |  DSCP(s)  |   Treatment  |
   |                |     Class      |           |   Aggregate  |
   +================+================+===========+==============+
   |    Network     |    Network     |    CS6    |    Network   |
   |    Control     |    Control     |           |    Control   |
   +----------------+----------------+-----------+--------------+
   |     Voice      |     Audio      |    EF     |    Realtime  |
   +----------------+----------------+-----------+--------------+
   |   Everything   |      DF        |  Default  |    Elastic   |
   |      else      |                |   (CS0)   |              |
   +----------------+----------------+-----------+--------------+

   Figure 6. Example 1 Configuration

        Insert different treatments for this example
        (i.e., AQM, RED, WFQ, colors, etc from above charts)

2.4.1.2 Example 2 - Voice/Video/Surveillance Configuration/SLA

   For example 1, we have an SP running MPLS and has an SLA to deliver
   Control, audio, video, surveillance, audio & video signaling, and
   everything else is BE

   +----------------+----------------+-----------+--------------+
   |  Applications  |    Service     |  DSCP(s)  |   Treatment  |
   |                |     Class      |           |   Aggregate  |
   +================+================+===========+==============+
   |    Network     |    Network     |    CS6    |    Network   |
   |    Control     |    Control     |           |    Control   |
   +----------------+----------------+-----------+--------------+
   |  Voice, video, |  Audio, Video, | EF, AF42, |    Realtime  |
   |  surveillance  |   Broadcast    |   CS3     |              |
   +----------------+----------------+-----------+--------------+
   |  audio & video | Conversational |  AV-Sig   |    Assured   |
   |    signaling   |   Signaling    |           |    Elastic   |
   +----------------+----------------+-----------+--------------+
   |   Everything   |      DF        |  Default  |    Elastic   |
   |      else      |                |   (CS0)   |              |
   +----------------+----------------+-----------+--------------+

   Figure 7. Example 2 Configuration

        Insert different treatments for this example
        (i.e., AQM, RED, WFQ, colors, etc from above charts)

2.4.1.2 Example 3 - Complex CAC realtime/Surveillance/+apps
        Configuration/SLA

   For example 1, we have an SP running MPLS and has an SLA to deliver


Polk                    Expires August 25, 2013               [Page 32]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   Control, voice, CAC voice, CAC video, streaming, signaling, LL
   data, Network Mgmt., and everything else is BE (including non-CAC
   video because it is not authorized or authenticated on network)

   +-------------------+-----------------+-----------+--------------+
   |   Applications    |     Service     |  DSCP(s)  |   Treatment  |
   |                   |      Class      |           |   Aggregate  |
   +===================+=================+===========+==============+
   |     Network       |     Network     |    CS6    |    Network   |
   |     Control       |     Control     |           |    Control   |
   +-------------------+-----------------+-----------+--------------+
   | Voice, CAC-Voice  |  Audio, Video,  |Voice-Admit|    Realtime  |
   |    CAC-video,     |                 |  EF, AF41 |              |
   |   surveillance    |    Broadcast    |    CS3    |              |
   +-------------------+-----------------+-----------+--------------+
   |   audio & video   | Conversational  |  AV-Sig   |    Assured   |
   |    signaling,     | Signaling, Low- |   AF21    |    Elastic   |
   |  VOD (streaming), | Latency Data,   |   AF31    |              |
   |   Network Mgmt.   | Multimedia      |   CS2     |              |
   |                   | Streaming,      |           |              |
   |                   | OAM             |           |              |
   +-------------------+-----------------+-----------+--------------+
   |    Everything     |       DF        |  Default  |    Elastic   |
   |       else        |                 |   (CS0)   |              |
   +-------------------+-----------------+-----------+--------------+

   Figure 8. Example 3 Configuration

        Insert different treatments for this example
        (i.e., AQM, RED, WFQ, colors, etc from above charts)


3.  Network Control Traffic

   Network control traffic is defined as packet flows that are
   essential for stable operation of an administered network, as well
   as the information exchanged between neighboring networks across a
   peering point where SLAs are in place.  Network control traffic is
   different from user application control (signaling) that may be
   generated by some applications or services.  Network control traffic
   is mostly between routers and network nodes (e.g., routing or mgmt
   protocols) that are used for operating, administering, controlling,
   or managing whole networks, network parts or just network segments.
   Network Control Traffic may be split into two service classes, i.e.,
   Network Control and OAM.

3.1.  Current Practice in the Internet

   Based on today's routing protocols and network control procedures
   that are used in the Internet, we have determined that CS6 DSCP
   value SHOULD be used for routing and control and that CS7 DSCP value
   SHOULD be reserved for future use, specifically if needed for future


Polk                    Expires August 25, 2013               [Page 33]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   routing or control protocols.  Network administrators MAY use a
   Local/Experimental DSCP, any value that contains 11xx11; therefore,
   they may use a locally defined service class within their network to
   further differentiate their routing and control traffic.

   RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets:

   o  Drop or remark 111xxx packets at ingress to DiffServ network
      domain.

   o  111xxx marked packets SHOULD NOT be sent across peering points.
      Exchange of control information across peering points SHOULD be
      done using CS6 DSCP and the Network Control service class.

   o  any internally defined 11xxx1 values, valid within that network
      domain, be remarked to CS6 upon egress at network peering points.

3.2.  Network Control Service Class

   The Network Control service class is used for transmitting packets
   between network devices (routers) that require control (routing)
   information to be exchanged between similar devices within the
   administrative domain, as well as across a peering point between
   adjacent administrative domains.  Traffic transmitted in this
   service class is very important as it keeps the network operational,
   and it needs to be forwarded in a timely manner.

   The Network Control service class SHOULD be configured using the
   DiffServ CS6 PHB, defined in [RFC2474].  This service class MUST be
   configured so that the traffic receives a minimum bandwidth
   guarantee, to ensure that the packets always receive timely service.
   The configured forwarding resources for Network Control service
   class MUST be such that the probability of packet drop under peak
   load is very low.  The Network Control service class SHOULD be
   configured to use a Rate Queuing system such as defined in Section
   1.4.1.2 of this document.

   The following are examples of protocols and applications that MUST
   use the Network Control service class if present in a network:

   o  Routing packet flows: OSPF, BGP, ISIS, RIP.

   o  Control information exchange within and between different
      administrative domains across a peering point where SLAs are in
      place.

   o  LSP setup using CR-LDP and RSVP-TE.

   The following protocols and applications MUST NOT use the Network
   Control service class:

   o  User oriented traffic is not allowed to use this service class.


Polk                    Expires August 25, 2013               [Page 34]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

      By user oriented traffic, we mean packet flows that originate
      from user-controlled end points that are connected to the
      network.

      o  even if originating from a server or a device acting on behalf
         of a user or endpoint,

      o  even if it is application or in-band signaling to establish a
         connection wholly within a single network or across peering
         points of/to adjacent networks (e.g., creating a tunnel such
         as a VPN, or data path control signaling).

   The following are traffic characteristics of packet flows in the
   Network Control service class:

   o  Mostly messages sent between routers and network servers.

   o  Variable size packets, normally one packet at a time, but traffic
      can also burst (BGP, OSPF, etc).

   o  IGMP, hen is used only for the normal multicast routing purpose.

   The REQUIRED DSCP marking is CS6 (Class Selector 6).

   RECOMMENDED Network Edge Conditioning:

   o  At peering points (between two DiffServ networks) where SLAs are
      in place, CS6 marked packets MUST be policed, e.g., using a
      single rate with burst size (sr+bs) token bucket policer to keep
      the CS6 marked packet flows to within the traffic rate specified
      in the SLA.

   o  CS6 marked packet flows from untrusted sources (for example, end
      user devices) MUST be dropped or remarked at ingress to the
      DiffServ network. What a network admin remarks this user oriented
      traffic to if a matter of local policy, and inspection of the
      packets can determine which application is used for proper
      marking to a more appropriate DSCP, such as from table 3. of this
      document.

   o  Packets from users/subscribers are not permitted access to the
      Network Control service classes.

   The fundamental service offered to the Network Control service class
   is enhanced best-effort service with high bandwidth assurance.
   Since this service class is used to forward both elastic and
   inelastic flows, the service SHOULD be engineered so that the Active
   Queue Management (AQM) [RFC2309] is applied to CS6 marked packets.

   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
   specifies a target queue depth, and the max-threshold specifies the
   queue depth above which all traffic is dropped or ECN marked.  Thus,


Polk                    Expires August 25, 2013               [Page 35]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   in this service class, the following inequality should hold in queue
   configurations:

   o  min-threshold CS6 < max-threshold CS6

   o  max-threshold CS6 <= memory assigned to the queue

   Note: Many other AQM algorithms exist and are used; they should be
         configured to achieve a similar result.

3.3.  OAM Service Class

   The OAM (Operations, Administration, and Management) service class
   is RECOMMENDED for OAM&P (Operations, Administration, and Management
   and Provisioning) using protocols such as Simple Network Management
   Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet,
   and Common Open Policy Service (COPS).  Applications using this
   service class require a low packet loss but are relatively not
   sensitive to delay.  This service class is configured to provide
   good packet delivery for intermittent flows.

   The OAM service class SHOULD use the Class Selector (CS) PHB defined
   in [RFC2474].  This service class SHOULD be configured to provide a
   minimum bandwidth assurance for CS2 marked packets to ensure that
   they get forwarded.  The OAM service class SHOULD be configured to
   use a Rate Queuing system such as defined in Section 1.4.1.2 of this
   document.

   The following applications SHOULD use the OAM service class:

   o  Provisioning and configuration of network elements.

   o  Performance monitoring of network elements.

   o  Any network operational alarms.

   The following are traffic characteristics:

   o  Variable size packets.

   o  Intermittent traffic flows.

   o  Traffic may burst at times.

   o  Both elastic and inelastic flows.

   o  Traffic not sensitive to delays.

   RECOMMENDED DSCP marking:

   o  All flows in this service class are marked with CS2 (Class
      Selector 2).


Polk                    Expires August 25, 2013               [Page 36]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   Applications or IP end points SHOULD pre-mark their packets with CS2
   DSCP value.  If the end point is not capable of setting the DSCP
   value, then the router topologically closest to the end point SHOULD
   perform Multifield (MF) Classification, as defined in [RFC2475].

   RECOMMENDED conditioning performed at DiffServ network edge:

   o  Packet flow marking (DSCP setting) from untrusted sources (end
      user devices) SHOULD be verified at ingress to DiffServ network
      using Multifield (MF) Classification methods, defined in
      [RFC2475].

   o  Packet flows from untrusted sources (end user devices) SHOULD be
      policed at ingress to DiffServ network, e.g., using single rate
      with burst size token bucket policer to ensure that the traffic
      stays within its negotiated or engineered bounds.

   o  Packet flows from trusted sources (routers inside administered
      network) MAY not require policing.

   o  Normally OAM&P CS2 marked packet flows are not allowed to flow
      across peering points.  If that is the case, then CS2 marked
      packets SHOULD be policed (dropped) at both egress and ingress
      peering interfaces.

   The fundamental service offered to "OAM" traffic is enhanced
   best-effort service with controlled rate.  The service SHOULD be
   engineered so that CS2 marked packet flows have sufficient bandwidth
   in the network to provide high assurance of delivery.  Since this
   service class is used to forward both elastic and inelastic flows,
   the service SHOULD be engineered so that Active Queue Management
   [RFC2309] is applied to CS2 marked packets.

   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
   specifies a target queue depth for each DSCP, and the max-threshold
   specifies the queue depth above which all traffic with such a DSCP
   is dropped or ECN marked.  Thus, in this service class, the
   following inequality should hold in queue configurations:

   o  min-threshold CS2 < max-threshold CS2

   o  max-threshold CS2 <= memory assigned to the queue

   Note: Many other AQM algorithms exist and are used; they should be
   configured to achieve a similar result.

4.  User Oriented Traffic

   User oriented traffic is defined as packet flows between different
   users or subscribers, or from servers/nodes on behalf of a user.  It
   is the traffic that is sent to or from end-terminals and that


Polk                    Expires August 25, 2013               [Page 37]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   supports a very wide variety of applications and services, to
   include traffic about a user or application that assists a user
   communicate. User oriented traffic can be classified in many
   different ways. What we have articulated throughout this document is
   a series of non-exhaustive list of categories for classifying user
   oriented traffic.  We differentiated user oriented traffic that is
   real-time versus non-real-time, elastic or rate-adaptive versus
   inelastic, sensitive versus insensitive to loss as well as
   considering whether the traffic is interactive vs. one way
   communication, its responsiveness, whether it requires timely
   delivery, and critical verses non-critical.  In the final analysis,
   we used all of the above for service differentiation, mapping
   application types that seemed to have different sets of performance
   sensitivities, and requirements to different service classes.

   Network administrators can categorize their applications according
   to the type of behavior that they require and MAY choose to support
   all or a subset of the defined service classes.  At the same time,
   we include a public facing default DSCP value, with its associated
   PHB, that is expected for each traffic type to ensure common or
   pervasive performance. Figure 3 provides some common applications
   and the forwarding service classes that best support them, based on
   their performance requirements.

4.1.  Conversational Service Class Group

   The Conversational Service Class Group consists of 3 different
   service classes, audio, video, and Hi-Res. We are describing the
   media sample, or bearer, packets for applications (e.g., RTP from
   [RFC3550]) that require bi-directional real-time, very low delay,
   very low jitter, and very low packet loss for relatively
   constant-rate traffic sources (inelastic traffic sources). It is
   RECOMMENDED that RTCP feedback use the same service class and be
   marked with the same DSCP as the bearer traffic for that (audio
   and/or video) call. This ensures comparable treatment within the
   network between endpoints.

   The signaling to set-up these bearer flows is part of the
   Conversational Signaling service group that will be discussed later
   in Section 4.  The following 3 subsections will detail what is
   expected within each bearer service class.

4.1.1 Audio Service Class

   This service class MUST be used for IP Audio service.

   The fundamental service offered to traffic in the Audio service
   class is minimum jitter, delay, and packet loss service up to a
   specified upper bound.  There are two PHBs, both EF based, for the
   Audio service class:

      Nonadmitted Audio traffic - MUST use the EF DSCP [RFC3246], and


Polk                    Expires August 25, 2013               [Page 38]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

          is for traffic that has not had any capacity admission
          signaling performed for that flow or session.

      Capacity-Admitted Audio traffic - MUST use the Voice-Admit DSCP
          [RFC5865], and is for traffic that has had any capacity
          admission signaling performed for that flow or session, e.g.,
          RSVP [RFC2205] or NSIS [RFC4080].

   The capacity-admitted Audio traffic operation is similar to an ATM
   CBR service, which has guaranteed bandwidth and which, if it stays
   within the negotiated rate, experiences nominal delay and no loss.

   The nonadmitted Audio traffic, on the other hand, has had no such
   explicit guarantee, but has a favorable PHB ensuring high
   probability of delivery as well as nominal delay and no loss -
   implicitly assuming there is not too much like marked traffic
   between users within a flow.

   There are two typical scenarios in which audio calls are
   established, on the public open Internet using protocols such as
   SIP, XMPP or H.323, or in more managed networks like enterprises or
   certain service providers which offer a audio service with some
   feature benefits and take part in the call signaling. These SPs or
   enterprises also use protocols like SIP, XMPP, H.323, but also use
   H.248/MEGACO and MGCP.

   On the open Internet, typically there is no SP actively involved in
   the session set-up of calls, and therefore no servers providing
   assistance or features to help one user contact another user. Often,
   this traffic is marked or remarked with the DF (i.e., Best Effort)
   DSCP.

   In more managed networks in which one of more operators have active
   servers aiding the audio call set-up, where DiffServ can be used and
   preserved to differentiate traffic, networks are offering a service,
   therefore need to do some, or a lot of engineering to ensure that
   capacity offered to one or more applications does not exceed the
   load to the network. Otherwise, the operator will have unhappy
   users, at least for that application's usage. This is true for any
   application, but is especially true for inelastic applications in
   which the application is rigid in its delivery requirements. Audio
   bearer traffic is typically such an application, video is another
   such application, but we will get to video in the next subsection.

   When a user in a managed network has been authorized to send Audio
   traffic (i.e., call initiation via the operator's servers was not
   rejected), the call admission procedure should have verified that
   the newly admitted flow will be within the capacity of the Audio
   service class forwarding capability in the network. Capacity
   verification is a non-trivial thing, and can either be implicitly
   assumed by the call server(s) based on the operator's network
   design, or it can be explicitly signaled from an in-data-path


Polk                    Expires August 25, 2013               [Page 39]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   signaling mechanism that verifies the capacity is available now for
   this call, for each call made within that network. In the latter
   case, those that do not have verifiable network capacity along the
   data path are rejected. An in between means method is for call
   servers to count calls between two or more endpoints. By
   topologically understanding where the caller and called party is and
   have configured a known maximum it will allow between the two
   locations. This is especially true over WAN links that have far less
   capacity than LAN links or core parts of a network.  Network
   operators will need to understand the topology between any two
   callers to ensure the appropriate amount of bandwidth is available
   for an expected number of simultaneous audio calls.

   Once more than one bandwidth amount can be used for audio calls, for
   example - by allowing more than one codec with different bandwidths
   per codec for such calls, network engineering becomes more
   difficult. Since the inelastic nature of RTP payloads from this
   class do not react well to loss or significant delay in any
   substantive way, the Audio service class MUST forward packets as
   soon as possible.

   The Audio service class that does not have capacity admission
   performed in the data path MUST use the Expedited Forwarding (EF)
   PHB, as defined in [RFC3246], so that all packets are forwarded
   quickly. The Audio service class that does have capacity admission
   performed in the data path MUST use the Voice-Admit PHB, as defined
   in [RFC5865], so that all packets are forwarded quickly. The Audio
   service class SHOULD be configured to use a Priority Queuing system
   such as that defined in Section 1.4.1.1 of this document.

   The following applications SHOULD use the Audio service class:

   o  VoIP (G.711, G.729, iLBC and other audio codecs).

   o  Voice-band data over IP (modem, fax).

   o  T.38 fax over IP.

   o  Circuit emulation over IP, virtual wire, etc.

   o  IP Virtual Private Network (VPN) service that specifies
      single-rate, mean network delay that is slightly longer then
      network propagation delay, very low jitter, and a very low packet
      loss.

   The following are traffic characteristics:

   o  Mostly fixed-size packets for VoIP (30, 60, 70, 120 or 200 bytes
      in size).

   o  Packets emitted at constant time intervals.



Polk                    Expires August 25, 2013               [Page 40]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   o  Admission control of new flows is provided by Audio call server,
      media gateway, gatekeeper, edge router, end terminal, access node
      or in-data-path signaling that provides flow admission control
      function.

   Applications or IP end points SHOULD pre-mark their packets with EF
   or Voice-Admit DSCP value, whichever is appropriate.  If the end
   point is not capable of setting the DSCP value, then the router
   topologically closest to the end point SHOULD perform Multifield
   (MF) Classification, as defined in [RFC2475].

   The RECOMMENDED DSCP marking is EF for nonadmitted audio flows, and
   Voice-Admit for capacity-admitted flows for the following
   applications:

   o  VoIP (G.711, G.729 and other codecs).

   o  Voice-band data over IP (modem and fax).

   o  T.38 fax over IP.

   o  Circuit emulation over IP, virtual wire, etc.

   RECOMMENDED Network Edge Conditioning:

   o  Packet flow marking (DSCP setting) from untrusted sources (end
      user devices) SHOULD be verified at ingress to DiffServ network
      using Multifield (MF) Classification methods, defined in
      [RFC2475]. If untrusted, the network edge SHOULD know if
      capacity-admission has been applied, since the edge router will
      have taken part in the admission signaling; therefore will know
      whether EF or Voice-Admit is the proper marking for that flow.

   o  Packet flows from untrusted sources (end user devices) SHOULD be
      policed at ingress to DiffServ network, e.g., using single rate
      with burst size token bucket policer to ensure that the Audio
      traffic stays within its negotiated bounds.

   o  Policing is OPTIONAL for packet flows from trusted sources whose
      behavior is ensured via other means (e.g., administrative
      controls on those systems).

   o  Policing of Audio packet flows across peering points where SLA is
      in place is OPTIONAL as Audio traffic will be controlled by
      admission control mechanism between peering points.

   The fundamental service offered to "Audio" traffic is enhanced
   best-effort service with controlled rate, very low delay, and very
   low loss.  The service MUST be engineered so that EF marked packet
   flows have sufficient bandwidth in the network to provide guaranteed
   delivery. Otherwise, the service will have in place an explicit
   capacity-admission signaling protocol such as RSVP or NSIS and thus


Polk                    Expires August 25, 2013               [Page 41]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   mark the packets within the flow as Voice-Admit. Normally traffic in
   this service class does not respond dynamically to packet loss.  As
   such, Active Queue Management [RFC2309] SHOULD NOT be applied to EF
   marked packet flows.


4.1.2 Video Service Class

   The Video service class is for bidirectional applications that
   require real-time service for both constant and rate-adaptive
   traffic.  SIP and H.323/V2 (and later) versions of video
   conferencing equipment with constant and dynamic bandwidth
   adjustment are such applications.  The traffic sources in this
   service class either have a fixed bandwidth requirement (e.g.,
   MPEG2, etc.), or have the ability to dynamically change their
   transmission rate (e.g., MPEG4/H.264, etc.) based on feedback from
   the receiver.  This feedback SHOULD be accomplished using RTCP
   [RFC3550]. One approach for this downspeeding has the receiver
   detect packet loss, thus signaling in an RTCP message to the source
   the indication of lost (or delayed or out of order) packets in
   transit.  When necessary the source then selects a lower rate
   encoding codec. When available, the source merely sends less data,
   resulting in lower resolution of the same visual display.

   The Video service class is not for video downloads, webcasts, or
   single directional video or audio/video traffic of any kind. It is
   for human-to-human visual interaction between two users, or more if
   an MTP is used.

   Typical video conferencing configurations negotiate the setup of
   audio/video session using protocols such as SIP and H.323.  Just as
   with networks that have audio traversing them, video typically
   traverses the same two types of networks: the open big "I" Internet,
   in which most every type of traffic is best effort (DF), or on a
   more managed network such as an enterprise or SP's managed network
   in which servers within either network take part in the call
   signaling, thereby offering the video service.

   When a user in a managed network has been authorized to send video
   traffic (i.e., call initiation via the operator's servers was not
   rejected), the call admission procedure should have verified that
   the newly admitted flow will be within the capacity of the video
   service class forwarding capability in the network. Capacity
   verification is a non-trivial thing, and can either be implicitly
   assumed by the call server(s) based on the operator's network
   design, or it can be explicitly signaled from an in-data-path
   signaling mechanism that verifies the capacity is available now for
   this call, for each call made within that network. In the latter
   case, those that do not have verifiable network capacity along the
   data path are rejected. An in between means method is for call
   servers to count calls between two or more endpoints. By
   topologically understanding where the caller and called party is and


Polk                    Expires August 25, 2013               [Page 42]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   have configured a known maximum it will allow between the two
   locations. Video is larger in bandwidth than audio, and the
   difference can be significant. For example, for a single G.711 audio
   call that is 80kbps, an associated video bandwidth for the same
   call can easily be 4Mbps. This is especially true over WAN links
   that have far less capacity than LAN links or core parts of a
   network.  Network operators will need to understand the topology
   between any two callers to ensure the appropriate amount of
   bandwidth is available for an expected number of simultaneous video
   and/or audio/video calls.

   Note that it is OPTIONALLY the case in these networks that the
   accompanying audio for the video call will be marked as the video is
   marked (i.e., using the same DSCP), but not always.  One reason this
   has been done is for lip-sync.

   The Video service class MUST use the Assured Forwarding (AF) PHB,
   defined in [RFC2597].  This service class MUST be configured to
   provide a bandwidth assurance for AF41, AF42, and AF43 marked
   packets to ensure that they get forwarded.  The Video service class
   SHOULD be configured to use a Rate Queuing system for AF42 and AF43
   traffic flows, such as that defined in Section 1.4.1.2 of this
   document. However, AF41 MUST be designated as the DSCP for use when
   capacity-admission signaling has been used, such as RSVP or NSIS, to
   guarantee delivery through the network. AF42 and AF43 will be used
   for non-admitted video calls, as well as overflows from AF41 sources
   that send more packets than they have negotiated bandwidth for that
   call.

   The following applications MUST use the Video service class:

   o  SIP and H.323/V2 (and later) versions of video conferencing
      applications (interactive video).

   o  Video conferencing applications with rate control or traffic
      content importance marking.

   o  Interactive, time-critical, and mission-critical applications.

      NOTE with regards to the above bullet: this usage SHOULD be
           minimized, else the video traffic will suffer - unless this
           is engineered into the topology.

   The following are traffic characteristics:

   o  Variable size packets (i.e., small to large in size).

   o  The higher the resolution or change rate between each image, the
      higher the duration of large packets.

   o  Usually constant inter-packet time interval.



Polk                    Expires August 25, 2013               [Page 43]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   o  Can be Variable rate in transmission.

   o  Source is capable of reducing its transmission rate based on
      being told receiver is detecting packet loss (e.g., via RTCP).

   Applications or IP end points SHOULD pre-mark their packets with
   DSCP values as shown below.  If the end point is not capable of
   setting the DSCP value, then the router topologically closest to the
   end point SHOULD perform Multifield (MF) Classification, as defined
   in  [RFC2475] and mark all packets as AF4x.  Note: In this case, the
   two-rate, three-color marker will be configured to operate in
   Color-Blind mode.

   Mandatory DSCP marking when performed by router closest to source:

   o  AF41 = up to specified rate "A", which is dedicated to non-Hi-Res
             capacity-admitted video traffic.

      Note the audio of an A/V call can be marked AF41 as well.

   o  AF42 = all non-Hi-Res video traffic marked AF41 in excess of
             specified rate "A", or new non-admitted video traffic but
             below specified rate "B".

   o  AF43 = in excess of specified rate "B".

   o  Where "A" < "B".

   Note: One might expect "A" to approximate the peak rates of sum of
         all admitted video flows, plus the sum of the mean rates and
         "B" to approximate the sum of the peak rates of those same two
         flows.

   Mandatory DSCP marking when performed by SIP or H.323/V2
   videoconferencing equipment:

   o  AF41 = SIP or H.323 video conferencing audio stream RTP.

   o  AF41 = SIP or H.323 video conferencing video control RTCP.

   o  AF41 = SIP or H.323 video conferencing video stream up to
             specified rate "A".

   o  AF42 = SIP or H.323 video conferencing video stream in excess of
             specified rate "A" but below specified rate "B".

   o  AF42 = SIP or H.323 video conferencing video control RTCP, for
             those video streams that were generated using AF42.

   o  AF43 = SIP or H.323 video conferencing video stream in excess of
             specified rate "B".



Polk                    Expires August 25, 2013               [Page 44]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   o  AF43 = SIP or H.323 video conferencing video control RTCP, for
             those video streams that were generated using AF43.

   o  Where "A" < "B".

   Mandatory conditioning performed at DiffServ network edge:

   o  The two-rate, three-color marker SHOULD be configured to provide
      the behavior as defined in trTCM [RFC2698].

   o  If packets are marked by trusted sources or a previously trusted
      DiffServ domain and the color marking is to be preserved, then
      the two-rate, three-color marker SHOULD be configured to operate
      in Color-Aware mode.

   o  If the packet marking is not trusted or the color marking is not
      to be preserved, then the two-rate, three-color marker SHOULD be
      configured to operate in Color-Blind mode.

   The fundamental service offered to nonadmitted "Video" traffic is
   enhanced best-effort service with controlled rate and delay. The
   fundamental service offered to capacity-admitted "Video" traffic is
   a guaranteed service using in-data-path signaling to ensure expected
   delivery in a timely manner.  For a non-admitted video conferencing
   service, if a 1% packet loss detected at the receiver triggers an
   encoding rate change, thus dropping to the next lower provisioned
   video encoding rate then Active Queue Management [RFC2309] SHOULD be
   used primarily to switch the video encoding rate under congestion,
   changing from high rate to lower rate, i.e., 1472 kbps to 768 kbps.
   This rule applies to all AF42 and 43 flows. The probability of loss
   of AF41 traffic MUST NOT exceed the probability of loss of AF42
   traffic, which in turn MUST NOT exceed the probability of loss of
   AF43 traffic.

   Capacity-admitted video service should not result in packet loss.
   However, administratively this MAY be allowed to cause a purposeful
   downspeeding event (i.e., a change in resolution or a change in
   codec) to occur due to congestion.

   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
   specifies a target queue depth for each DSCP, and the max-threshold
   specifies the queue depth above which all traffic with such a DSCP
   is dropped or ECN marked.  Thus, in this service class, the
   following inequality should hold in queue configurations:

   o  min-threshold AF43 < max-threshold AF43

   o  max-threshold AF43 <= min-threshold AF42

   o  min-threshold AF42 < max-threshold AF42

   o  max-threshold AF42 <= min-threshold AF41


Polk                    Expires August 25, 2013               [Page 45]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   o  min-threshold AF41 < max-threshold AF41

   o  max-threshold AF41 <= memory assigned to the queue

   Note: This configuration tends to drop AF43 traffic before AF42 and
         AF42 before AF41.  Many other AQM algorithms exist and are
         used; they should be configured to achieve a similar result.


4.1.3 Hi-Res Service Class

   The Hi-Res service class is for higher end (i.e., deemed 'more
   important') bidirectional applications that require real-time
   service for both constant and rate-adaptive traffic. There are two
   PHBs, both EF based, for the Hi-Res video conferencing service
   class:

      Nonadmitted Hi-Res traffic - MUST use the CS4 DSCP [RFC2474], and
          is for traffic that has not had any capacity admission
          signaling performed for that flow or session.

      Capacity-Admitted Hi-Res traffic - MUST use the CS4-Admit DSCP
          [ID-DSCP], and is for traffic that has had any capacity
          admission signaling performed for that flow or session, e.g.,
          RSVP [RFC2205] or NSIS [RFC4080].

   The capacity-admitted Hi-Res video conferencing traffic operation is
   similar to an ATM CBR service, which has guaranteed bandwidth and
   which, if it stays within the negotiated rate, experiences nominal
   delay and no loss.

   SIP and H.323/V2 (and later) versions of video conferencing
   equipment with constant and dynamic bandwidth adjustment are such
   applications.  The traffic sources in this service class either have
   a fixed bandwidth requirement (e.g., MPEG2), or have the ability to
   dynamically change their transmission rate (e.g., MPEG4/H.264) based
   on feedback from the receiver.  This feedback SHOULD be accomplished
   using RTCP [RFC3550]. One approach for this downspeeding has the
   receiver detect packet loss, thus signaling in an RTCP message to
   the source the indication of lost (or delayed or out of order)
   packets in transit.  When necessary the source then selects a lower
   rate encoding codec. When available, the source merely sends less
   data, resulting in lower resolution of the same visual display.

   The Hi-Res service class, as with the Video service class, is not
   for video downloads, webcasts, or single directional video or
   audio/video traffic of any kind. It is for human-to-human visual
   interaction between two users, or more if an video conference bridge
   is used.

   Typical Hi-Res video conferencing configurations negotiate the setup


Polk                    Expires August 25, 2013               [Page 46]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   of audio/video session using protocols such as SIP and H.323.
   Hi-Res video conferencing is generally not over the big "I"
   Internet, rather nearly exclusively over more managed networks such
   as an enterprise or special purpose SP's managed network in which
   servers within either network take part in the call signaling,
   thereby offering the video service. In addition, typically this type
   of audio/video service has high business expectations for minimized
   packet loss, pixilation or other issues with the audio/video
   experience. In the recent past, entire T3s have been dedicated to a
   signal Hi-Res call; sometimes one T3 per site of a multi-site video
   conference.

   Hi-Res video conferencing often has larger in bandwidth than the
   typical video call. The audio portion can be increased as well, as
   stereo capabilities are often necessary to provide an in-room
   experience from a distance. The difference can be significant (or
   another step up from just a typical video service). For example, for
   a single G.711 audio call that is 80kbps, a Hi-Res conference
   usually runs G.722 wideband audio at 256kbps. Typical video delivery
   is up to 4Mbps, whereas a Hi-Res conference can have three
   1080p/30fps widescreen displays requiring at least 12Mbps, with a
   burst capability of much more.

   If there were no congestion on the wire, the expected treatment
   between a video service and a Hi-Res conference would be the same.
   However, it is typically the case that the Hi-Res conferencing flows
   have more rigid requirements for quality and business-wise, need to
   be experience far less errors than the regular video service on the
   same network.

   Note that it is likely the case in these networks that the
   accompanying audio to the Hi-Res video call will be marked as the
   Hi-Res video is marked (i.e., using the same DSCP.

   The Hi-Res service class MUST use the Class Selector 5 (CS4) PHB,
  defined in [RFC2474], for non-capacity-admitted conferences. While
   the capacity-admitted Hi-Res conferences MUST use the CS4-Admit PHB,
   defined in [ID-DSCP]. This service class MUST be configured to
   provide a bandwidth assurance for CS4 and CS4-Admit marked packets
   to ensure that they get forwarded.  The Hi-Res service class SHOULD
   be configured to use a Priority Queuing system such as that defined
   in Section 1.4.1.1 of this document. Further, CS4-Admit will be
   designated as the DSCP for use when capacity-admission signaling has
   been used, such as RSVP or NSIS, to guarantee delivery through the
   network. CS4 will be used for non-admitted Hi-Res conferences, as
   well as overflows from CS4-Admit sources that send more packets than
   they have negotiated bandwidth for that call.

   The following applications MUST use the Hi-Res service class:

   o  SIP and H.323/V2 (and later) versions of Hi-Res video
      conferencing applications (interactive Hi-Res video).


Polk                    Expires August 25, 2013               [Page 47]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   o  Video conferencing applications with rate control or traffic
      content importance marking.

   The following are traffic characteristics:

   o  Variable size packets.

   o  The higher the resolution or change rate between each image, the
      higher the duration of large packets.

   o  Usually constant inter-packet time interval.

   o  Can be Variable rate in transmission.

   o  Source is capable of reducing its transmission rate based on
      being told receiver is detecting packet loss.

   Applications or IP end points SHOULD pre-mark their packets with
   DSCP values as shown below.  If the end point is not capable of
   setting the DSCP value, then the router topologically closest to the
   end point SHOULD perform Multifield (MF) Classification, as defined
   in [RFC2475] and mark all packets as AF4x.

   Mandatory DSCP marking when performed by router closest to source:

   o  CS4-Admit = up to specified rate "A", which is dedicated to
            capacity-admitted Hi-Res traffic.

      Note the audio of an A/V call can be marked CS4-Admit as well.

   o  CS4 = all video traffic marked CS4-Admit in excess of specified
            rate "A", or new non-admitted video traffic but below
            specified rate "B".

   o  Where "A" < "B".

   Note: One might expect "A" to approximate the peak rates of sum of
         all admitted video flows, plus the sum of the mean rates and
         "B" to approximate the sum of the peak rates of those same two
         flows.

   Mandatory DSCP marking when performed by SIP or H.323/V2
   videoconferencing equipment:

   o  CS4-Admit = SIP or H.323 video conferencing audio stream RTP/UDP.

   o  CS4-Admit = SIP or H.323 video conferencing video control
            RTCP/TCP.

   o  CS4-Admit = SIP or H.323 video conferencing video stream up to
            specified rate "A".


Polk                    Expires August 25, 2013               [Page 48]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   o  CS4 = SIP or H.323 video conferencing video stream in excess of
            specified rate "A" but below specified rate "B".

   o  Where "A" < "B".

   Mandatory conditioning performed at DiffServ network edge:

   o  The two-rate, three-color marker SHOULD be configured to provide
      the behavior as defined in trTCM [RFC2698].

   o  If packets are marked by trusted sources or a previously trusted
      DiffServ domain and the color marking is to be preserved, then
      the two-rate, three-color marker SHOULD be configured to operate
      in Color-Aware mode.

   o  If the packet marking is not trusted or the color marking is not
      to be preserved, then the two-rate, three-color marker SHOULD be
      configured to operate in Color-Blind mode.

   The fundamental service offered to nonadmitted "Hi-Res" traffic is
   enhanced best-effort service with controlled rate and delay. The
   fundamental service offered to capacity-admitted "Hi-Res" traffic is
   a guaranteed service using in-data-path signaling to ensure expected
   or timely delivery.  Capacity-admitted video service SHOULD NOT
   result in packet loss. However, administratively this MAY be allowed
   to cause a purposeful downspeeding event (i.e., a change in
   resolution or a change in codec) to occur.


4.2.  Realtime-Interactive Service Class

   The Realtime-Interactive service class is for bidirectional
   applications that require low loss and jitter and very low delay for
   constant or variable rate inelastic traffic sources.  Interactive
   gaming applications that do not have the ability to change encoding
   rates or to mark packets with different importance indications is
   one good example of such an application.  Another set of
   applications is virtualized desktop applications in which a remote
   user has a keyboard, mouse and display monitor, but the desktop is
   virtualized with the memory/processor/applications back in a common
   data center, requiring near instantaneous feedback on the user's
   monitor of any changes caused by the application or an action by the
   user.  Rich media protocols for voice and video MUST NOT use the
   Realtime-Interactive service class, but rather the appropriate
   service class from the Conversational service group discussed early
   in Section 4.1.

   The Realtime-Interactive service class will use two PHBs:

      Nonadmitted Realtime-Interactive traffic - MUST use the CS5 DSCP
          [RFC2474], and is for traffic that has not had any capacity


Polk                    Expires August 25, 2013               [Page 49]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

          admission signaling performed for that flow or session.

      Capacity-Admitted Realtime-Interactive traffic - MUST use the
          CS5-Admit DSCP [ID-DSCP], and is for traffic that has had any
          capacity admission signaling performed for that flow or
          session, e.g., RSVP [RFC2205] or NSIS [RFC4080].

   The capacity-admitted Realtime-Interactive traffic operation is
   similar to an ATM CBR service, which has guaranteed bandwidth and
   which, if it stays within the negotiated rate, experiences nominal
   delay and no loss.

   Either of the above service classes can be configured as EF based by
   using a relaxed performance parameter and a rate scheduler.

   When a user/endpoint has been authorized to start a new session
   (i.e., joins a networked game or logs onto a virtualized
   workstation), the admission procedure should have verified that the
   newly admitted data rates will be within the engineered capacity of
   the Realtime-Interactive service class.  The bandwidth in the core
   network and the number of simultaneous Realtime-Interactive sessions
   that can be supported SHOULD be engineered to control traffic load
   for this service.

   This service class SHOULD be configured to provide a high assurance
   for bandwidth for CS5 PHB, defined in [RFC2474], or CS5-Admit
   [ID-DSCP] for guaranteed service through a capacity-admission
   signaling protocol. The Realtime-Interactive service class SHOULD be
   configured to use a Rate Queuing system such as that defined in
   Section 1.4.1.2 of this document.  Note that either
   Realtime-Interactive PHB MAY be configured as another EF PHB,
   specifically CS5-Admit,  that uses a relaxed performance parameter
   and a rate scheduler, in the priority queue as defined in Section
   1.4.1.1 of this document.

   The following applications MUST use the Realtime-Interactive service
   class:

   o  Interactive gaming and control.

   o  Remote Desktop applications

   o  Virtualized Desktop applications.

   o  Application server-to-application server non-bursty data transfer
      requiring very low delay.

   o  Inelastic, interactive, time-critical, and mission-critical
      applications requiring very low delay.

   The following are traffic characteristics:



Polk                    Expires August 25, 2013               [Page 50]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   o  Variable size packets.

   o  Variable rate,  though sometimes bursty, which will require
      engineering of the network to accommodate.

   o  Application is sensitive to delay variation between flows and
      sessions.

   o  Lost packets, if any, are usually ignored by application.

   RECOMMENDED DSCP marking:

   o  All non-admitted flows in this service class are marked with CS5
      (Class Selector 5).

   o  All capacity-admitted flows in this service class are marked with
      CS5-Admit.

   Applications or IP end points SHOULD pre-mark their packets with CS5
   or CS5-Admit DSCP value, depending on whether a capacity-admission
   signaling protocol is used for a flow.  If the end point is not
   capable of setting the DSCP value, then the router topologically
   closest to the end point SHOULD perform Multifield (MF)
   Classification, as defined in [RFC2475].

   RECOMMENDED conditioning performed at DiffServ network edge:

   o  Packet flow marking (DSCP setting) from untrusted sources (end
      user devices) SHOULD be verified at ingress to DiffServ network
      using Multifield (MF) Classification methods defined in
      [RFC2475].

   o  Packet flows from untrusted sources (end user devices) SHOULD be
      policed at ingress to DiffServ network, e.g., using single rate
      with burst size token bucket policer to ensure that the traffic
      stays within its negotiated or engineered bounds.

   o  Packet flows from trusted sources (application servers inside
      administered network) MAY not require policing.

   o  Policing of packet flows across peering points MUST adhere to the
      Service Level Agreement (SLA).

   The fundamental service offered to nonadmitted
   "Realtime-Interactive" traffic is enhanced best-effort service with
   controlled rate and delay.  The fundamental service offered to
   capacity-admitted "Realtime-Interactive" traffic is a guaranteed
   service using in-data-path signaling to ensure expected or timely
   delivery.  Capacity-admitted Realtime-Interactive service SHOULD NOT
   result in packet loss. The service SHOULD be engineered so that CS5
   marked packet flows have sufficient bandwidth in the network to
   provide high assurance of delivery.  Normally, traffic in this


Polk                    Expires August 25, 2013               [Page 51]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   service class does not respond dynamically to packet loss.  As such,
   Active Queue Management [RFC2309] SHOULD NOT be applied to CS5
   marked packet flows.


4.3.  Multimedia Conferencing Service Class

   The Multimedia Conferencing service class is for applications that
   have a low to medium tolerance to delay, and are rate adaptive to
   lost packets in transit from sources.  Presentation Data
   applications that are operational in conjunction with an audio/video
   conference is one good example of such an application.  Another set
   of applications is application sharing or whiteboarding
   applications, also in conjunction to an A/V conference. In either
   case, the audio & video part of the flow MUST NOT use the Multimedia
   Conferencing service class, rather the more appropriate service
   class within the Conversational service group discussed earlier in
   Section 4.1.

   The Multimedia Conferencing service class will use two PHBs:

      Nonadmitted Multimedia Conferencing traffic - MUST use the (new)
          MC DSCP [ID-DSCP], and is for traffic that has not had any
          capacity admission signaling performed for that flow or
          session.

      Capacity-Admitted Multimedia Conferencing traffic - MUST use the
          (new) MC-Admit DSCP [ID-DSCP], and is for traffic that has
          had any capacity admission signaling performed for that flow
          or session, e.g., RSVP [RFC2205] or NSIS [RFC4080].

   The capacity-admitted Multimedia Conferencing traffic operation is
   similar to an ATM CBR service, which has guaranteed bandwidth and
   which, if it stays within the negotiated rate, experiences nominal
   delay and no loss.

   When a user/endpoint initiates a presentation data, application
   sharing or whiteboarding session, it will typically be part of an
   audio or audio/video conference such as web-conferencing or an
   existing Telepresence call. The authorization procedure SHOULD be
   controlled through the coordinated effort to bind the A/V call with
   the correct Multimedia Conferencing packet flow through some use of
   identifiers not in scope of this document.  The managed network this
   flow traverse and the number of simultaneous Multimedia
   Conferencing sessions that can be supported SHOULD be engineered to
   control traffic load for this service.

   The non-capacity admitted Multimedia Conferencing service class
   SHOULD use the new MC PHB, defined in [ID-DSCP].  This service class
   SHOULD be configured to provide a high assurance for bandwidth for
   CS5 marked packets to ensure that they get forwarded.  The
   Multimedia Conferencing service class SHOULD be configured to use a


Polk                    Expires August 25, 2013               [Page 52]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   Rate Queuing system such as that defined in Section 1.4.1.2 of this
   document.  Note that this service class MAY be configured as another
   EF PHB that uses a relaxed performance parameter, a rate scheduler,
   and MC-Admit DSCP value, which MUST use the priority queue as
   defined in Section 1.4.1.1 of this document.

   The following applications MUST use the Multimedia Conferencing
   service class:

   o  Presentation Data applications, which can utilize vector
      graphics, raster graphics or video delivery.

   o  Virtualized Desktop applications.

   o  Application server-to-application server non-bursty data transfer
      requiring very low delay.

   The following are traffic characteristics:

   o  Variable size packets.

   o  Variable rate,  though sometimes bursty, which will require
      engineering of the network to accommodate.

   o  Application is sensitive to delay variation between flows and
      sessions.

   o  Lost packets, if any, can be ignored by the application.

   RECOMMENDED DSCP marking:

   o  All non-admitted flows in this service class are marked with the
      new MC DSCP.

   o  All capacity-admitted flows in this service class are marked with
      MC-Admit.

   Applications or IP end points SHOULD pre-mark their packets with the
   MC DSCP value.  If the end point is not capable of setting the DSCP
   value, then the router topologically closest to the end point SHOULD
   perform Multifield (MF) Classification, as defined in [RFC2475].

   RECOMMENDED conditioning performed at DiffServ network edge:

   o  Packet flow marking (DSCP setting) from untrusted sources (end
      user devices) SHOULD be verified at ingress to DiffServ network
      using Multifield (MF) Classification methods defined in
      [RFC2475].

   o  Packet flows from untrusted sources (end user devices) SHOULD be
      policed at ingress to DiffServ network, e.g., using single rate
      with burst size token bucket policer to ensure that the traffic


Polk                    Expires August 25, 2013               [Page 53]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

      stays within its negotiated or engineered bounds.

   o  Packet flows from trusted sources (application servers inside
      administered network) MAY not require policing.

   o  Policing of packet flows across peering points MUST adhere to the
      Service Level Agreement (SLA).

   The fundamental service offered to nonadmitted "Multimedia
   Conferencing" traffic is enhanced best-effort service with
   controlled rate and delay.  The fundamental service offered to
   capacity-admitted "Multimedia Conferencing" traffic is a guaranteed
   service using in-data-path signaling to ensure expected or timely
   delivery.  Capacity-admitted Multimedia Conferencing service SHOULD
   NOT result in packet loss. The service SHOULD be engineered so that
   Multimedia Conferencing marked packet flows have sufficient
   bandwidth in the network to provide high assurance of delivery.
   Normally, traffic in this service class does not respond dynamically
   to packet loss.  As such, Active Queue Management  [RFC2309] SHOULD
   NOT be applied to MC or MC-Admit marked packet flows.


4.4.  Multimedia Streaming Service Class

   The Multimedia Streaming service class is RECOMMENDED for
   applications that require near-real-time packet forwarding of
   variable rate elastic traffic sources that are not as delay
   sensitive as applications using the Broadcast service class. Such
   applications include streaming audio and video, some video  (movies)
   on-demand applications, and non-interactive webcasts.  In general,
   the Multimedia Streaming service class assumes that the traffic is
   buffered at the source/destination; therefore, it is less sensitive
   to delay and jitter.

   The Multimedia Streaming service class MUST use the Assured
   Forwarding (AF3x) PHB, defined in [RFC2597].  This service class
   MUST be configured to provide a minimum bandwidth assurance for
   AF31, AF32, and AF33 marked packets to ensure that they get
   forwarded.  The Multimedia Streaming service class SHOULD be
   configured to use Rate Queuing system for AF32 and AF33 traffic
   flows, such as that defined in Section 1.4.1.2 of this document.
   However, AF31 MUST be designated as the DSCP for use when
   capacity-admission signaling has been used, such as RSVP or NSIS, to
   guarantee delivery through the network. AF32 and AF33 will be used
   for non-admitted streaming flows, as well as overflows from AF31
   sources that send more packets than they have negotiated bandwidth
   for that call.

   The following applications SHOULD use the Multimedia Streaming
   service class:

   o  Buffered streaming audio (unicast).


Polk                    Expires August 25, 2013               [Page 54]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   o  Buffered streaming video (unicast).

   o  Non-interactive Webcasts.

   o  IP VPN service that specifies two rates and is less sensitive to
      delay and jitter.

   The following are traffic characteristics:

   o  Variable size packets.

   o  The higher the rate, the higher the density of large packets.

   o  Variable rate.

   o  Elastic flows.

   o  Some bursting at start of flow from some applications, as well as
      an expected stepping up and down on the rate of the flow based on
      changes in resolution due to network conditions.

   Applications or IP end points SHOULD pre-mark their packets with
   DSCP values as shown below.  If the end point is not capable of
   setting the DSCP value, then the router topologically closest to the
   end point SHOULD perform Multifield (MF) Classification, as defined
   in  [RFC2475], and mark all packets as AF3x.  Note: In this case,
   the two-rate, three-color marker will be configured to operate in
   Color-Blind mode.

   RECOMMENDED DSCP marking:

   o  AF31 = up to specified rate "A".

   o  AF32 = all traffic marked AF31 in excess of specified rate "A",
             or new AF32 traffic but below specified rate "B".

   o  AF33 = in excess of specified rate "B".

   o  Where "A" < "B".

   Note: One might expect "A" to approximate the peak rates of sum of
         all streaming flows, plus the sum of the mean rates and "B" to
         approximate the sum of the peak rates of those same two flows.

   RECOMMENDED conditioning performed at DiffServ network edge:

   o  The two-rate, three-color marker SHOULD be configured to provide
      the behavior as defined in trTCM [RFC2698].

   o  If packets are marked by trusted sources or a previously trusted
      DiffServ domain and the color marking is to be preserved, then


Polk                    Expires August 25, 2013               [Page 55]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

      the two-rate, three-color marker SHOULD be configured to operate
      in Color-Aware mode.

   o  If the packet marking is not trusted or the color marking is not
      to be preserved, then the two-rate, three-color marker SHOULD be
      configured to operate in Color-Blind mode.

   The fundamental service offered to nonadmitted "Multimedia
   Streaming" traffic is enhanced best-effort service with controlled
   rate and delay.  The fundamental service offered to
   capacity-admitted "Multimedia Streaming" traffic is a guaranteed
   service using in-data-path signaling to ensure expected delivery in
   a reasonable manner. The service SHOULD be engineered so that AF31
   marked packet flows have sufficient bandwidth in the network to
   provide high assurance of delivery.  Since the AF3x traffic is
   elastic and responds dynamically to packet loss, Active Queue
   Management [RFC2309] SHOULD be used primarily to reduce forwarding
   rate to the minimum assured rate at congestion points, unless AF31
   has had a capacity-admission signaling protocol applied to the flow,
   such as RSVP or NSIS.

   If a capacity-admission signaling protocol applied to the AF31 flow,
   which SHOULD be the case always, the AF31 PHB MAY be configured as
   another EF PHB that uses a relaxed performance parameter and a rate
   scheduler, in the priority queue as defined in Section 1.4.1.1 of
   this document.

   The probability of loss of AF31 traffic MUST NOT exceed the
   probability of loss of AF32 traffic, which in turn MUST NOT exceed
   the probability of loss of AF33.

   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
   specifies a target queue depth for each DSCP, and the max-threshold
   specifies the queue depth above which all traffic with such a DSCP
   is dropped or ECN marked.  Thus, in this service class, the
   following inequality MUST hold in queue configurations:

   o  min-threshold AF33 < max-threshold AF33

   o  max-threshold AF33 <= min-threshold AF32

   o  min-threshold AF32 < max-threshold AF32

   o  max-threshold AF32 <= min-threshold AF31

   o  min-threshold AF31 < max-threshold AF31

   o  max-threshold AF31 <= memory assigned to the queue

   Note#1: this confirmation MUST be modified if AF31 has a
           capacity-admission signaling protocol applied to those
           flows, and the above will only apply to AF32 and AF33, while


Polk                    Expires August 25, 2013               [Page 56]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

           AF31 (theoretically) has no packet loss.

   Note#2: This configuration tends to drop AF33 traffic before AF32
           and AF32 before AF31.  Note: Many other AQM algorithms exist
           and are used; they SHOULD be configured to achieve a similar
           result.


4.5.  Broadcast Service Class

   The Broadcast service class is RECOMMENDED for applications that
   require near-real-time packet forwarding with very low packet loss
   of constant rate and variable rate inelastic traffic sources that
   are more  delay sensitive than applications using the Multimedia
   Streaming service class.  Such applications include broadcast TV,
   streaming of live audio and video events, some video-on-demand
   applications, and video surveillance.  In general, the Broadcast
   service class assumes that the destination end point has a dejitter
   buffer, for video application usually a 2 - 8 video-frame buffer (66
   to several hundred of milliseconds), thus expecting far less
   buffering before play-out than Multimedia Streaming, which can
   buffer in the seconds to minutes (to hours).

   The Broadcast service class will use two PHBs:

      Nonadmitted Broadcast traffic - MUST use the CS3 DSCP [RFC2474],
          and is for traffic that has not had any capacity admission
          signaling performed for that flow or session.

      Capacity-Admitted Broadcast traffic - MUST use the CS3-Admit DSCP
          [ID-DSCP], and is for traffic that has had any capacity
          admission signaling performed for that flow or session, e.g.,
          RSVP [RFC2205] or NSIS [RFC4080].

   The capacity-admitted Broadcast traffic operation is similar to an
   ATM CBR service, which has guaranteed bandwidth and which, if it
   stays within the negotiated rate, experiences nominal delay and no
   loss.

   Either of the above service classes can be configured as EF based by
   using a relaxed performance parameter and a rate scheduler.

   When a user/endpoint initiates a new Broadcast session (i.e., starts
   an Internet radio application, starts a live Internet A/V event or a
   camera comes online to do video-surveillance), the admission
   procedure should be verified within the application that triggers
   the flow.  The newly admitted data rates will SHOULD be within the
   engineered capacity of the Broadcast service class within that
   network.  The bandwidth in the core network and the number of
   simultaneous Broadcast sessions that can be supported SHOULD be
   engineered to control traffic load for this service.



Polk                    Expires August 25, 2013               [Page 57]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   This service class SHOULD be configured to provide high assurance
   for bandwidth for CS3 marked packets to ensure that they get
   forwarded.  The Broadcast service class SHOULD be configured to use
   Rate Queuing system such as that defined in Section 1.4.1.2 of this
   document.  Note that either Broadcast PHB MAY be configured as
   another EF PHB, specifically CS3-Admit, that uses a relaxed
   performance parameter and a rate scheduler, in the priority queue as
   defined in Section 1.4.1.1 of this document.

   The following applications SHOULD use the Broadcast service class:

   o  Video surveillance and security (unicast).

   o  TV broadcast including HDTV (likely multicast, but can be
      unicast).

   o  Video on demand (unicast) with control (virtual DVD).

   o  Streaming of live audio events (both unicast and multicast).

   o  Streaming of live video events (both unicast and multicast).

   The following are traffic characteristics:

   o  Variable size packets.

   o  The higher the rate, the higher the density of large packets.

   o  Mixture of variable rate and constant rate flows.

   o  Fixed packet emission time intervals.

   o  Inelastic flows.

   RECOMMENDED DSCP marking:

   o  All non-admitted flows in this service class are marked with CS3
      (Class Selector 3).

   o  All capacity-admitted flows in this service class are marked with
      CS3-Admit.

   o  In some cases, such as those for security and video surveillance
      applications, it is NOT RECOMMENDED, but allowed to use a
      different DSCP marking.

      If so, then locally user definable (EXP/LU) codepoints in the
      range '011x11' MAY be used to provide unique traffic
      identification.  The locally administrator definable (EXP/LU,
      from pool 2 of RFC 2474) codepoint(s) MAY be associated with the
      PHB that is used for CS3 or CS3-Admit traffic. Furthermore,
      depending on the network scenario, additional network edge


Polk                    Expires August 25, 2013               [Page 58]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

      conditioning policy MAY be needed for the EXP/LU codepoint(s)
      used.

   Applications or IP end points SHOULD pre-mark their packets with CS3
   or CS3-Admit DSCP value.  If the end point is not capable of setting
   the DSCP value, then the router topologically closest to the end
   point SHOULD perform Multifield (MF) Classification, as defined in
   [RFC2475].

   RECOMMENDED conditioning performed at DiffServ network edge:

   o  Packet flow marking (DSCP setting) from untrusted sources (end
      user devices) SHOULD be verified at ingress to DiffServ network
      using Multifield (MF) Classification methods defined in
      [RFC2475].

   o  Packet flows from untrusted sources (end user devices) SHOULD be
      policed at ingress to DiffServ network, e.g., using single rate
      with burst size token bucket policer to ensure that the traffic
      stays within its negotiated or engineered bounds.

   o  Packet flows from trusted sources (application servers inside
      administered network) MAY not require policing.

   o  Policing of packet flows across peering points MUST be performed
      to the Service Level Agreement (SLA) of those peering entities.

   The fundamental service offered to "Broadcast"  traffic is enhanced
   best-effort service with controlled rate and delay.  The fundamental
   service offered to capacity-admitted "Broadcast" traffic is a
   guaranteed service using in-data-path signaling to ensure expected
   or timely delivery.  Capacity-admitted Broadcast service SHOULD NOT
   result in packet loss. The service SHOULD be engineered so that CS3
   and CS3-Admit marked packet flows have sufficient bandwidth in the
   network to provide high assurance of delivery.  Normally, traffic in
   this service class does not respond dynamically to packet loss.  As
   such, Active Queue Management  [RFC2309] SHOULD NOT be applied to
   CS3 marked packet flows.

4.6.  Low-Latency Data Service Class

   The Low-Latency Data service class is RECOMMENDED for elastic and
   responsive typically client-/server-based applications.
   Applications forwarded by this service class are those that require
   a relatively fast response and typically have asymmetrical bandwidth
   need, i.e., the client typically sends a short message to the server
   and the server responds with a much larger data flow back to the
   client.  The most common example of this is when a user clicks a
   hyperlink (~ few dozen bytes) on a web page, resulting in a new web
   page to be loaded  (Kbytes or MBs of data).  This service class is
   configured to provide good response for TCP [RFC1633] short-lived
   flows that require real-time packet forwarding of variable rate


Polk                    Expires August 25, 2013               [Page 59]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   traffic sources.

   The Low-Latency Data service class SHOULD use the Assured Forwarding
   (AF) PHB, defined in [RFC2597].  This service class SHOULD be
   configured to provide a minimum bandwidth assurance for AF21, AF22,
   and AF23 marked packets to ensure that they get forwarded.  The
   Low-Latency Data service class SHOULD be configured to use a Rate
   Queuing system such as that defined in Section 1.4.1.2 of this
   document.

   The following applications SHOULD use the Low-Latency Data service
   class:

   o  Client/server applications.

   o  Systems Network Architecture (SNA) terminal to host transactions
     (SNA over IP using Data Link Switching (DLSw)).

   o  Web-based transactions (E-commerce).

   o  Credit card transactions.

   o  Financial wire transfers.

   o  Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN).

   o  VPN service that supports Committed Information Rate (CIR) with
      up to two burst sizes.

   o  Instant Messaging and Presence protocols (e.g., SIP, XMPP).

   The following are traffic characteristics:

   o  Variable size packets.

   o  Variable packet emission rate.

   o  With packet bursts of TCP window size.

   o  Short traffic bursts.

   o  Source capable of reducing its transmission rate based on
      detection of packet loss at the receiver or through explicit
      congestion notification.

   Applications or IP end points SHOULD pre-mark their packets with
   DSCP values as shown below.  If the end point is not capable of
   setting the DSCP value, then the router topologically closest to the
   end point SHOULD perform Multifield (MF) Classification, as defined
   in  [RFC2475] and mark all packets as AF2x.  Note: In this case, the
   single-rate, three-color marker will be configured to operate in
   Color-Blind mode.


Polk                    Expires August 25, 2013               [Page 60]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   RECOMMENDED DSCP marking:

   o  AF21 = flow stream with packet burst size up to "A" bytes.

   o  AF22 = flow stream with packet burst size in excess of "A" but
             below "B" bytes.

   o  AF23 = flow stream with packet burst size in excess of "B" bytes.

   o  Where "A" < "B".

   RECOMMENDED conditioning performed at DiffServ network edge:

   o  The single-rate, three-color marker SHOULD be configured to
      provide the behavior as defined in srTCM [RFC2697].

   o  If packets are marked by trusted sources or a previously trusted
      DiffServ domain and the color marking is to be preserved, then
      the single-rate, three-color marker SHOULD be configured to
      operate in Color-Aware mode.

   o  If the packet marking is not trusted or the color marking is
      not to be preserved, then the single-rate, three-color marker
      SHOULD be configured to operate in Color-Blind mode.

   The fundamental service offered to "Low-Latency Data" traffic is
   enhanced best-effort service with controlled rate and delay.  The
   service SHOULD be engineered so that AF21 marked packet flows have
   sufficient bandwidth in the network to provide high assurance of
   delivery.  Since the AF2x traffic is elastic and responds
   dynamically to packet loss, Active Queue Management [RFC2309] SHOULD
   be used primarily to control TCP flow rates at congestion points by
   dropping packets from TCP flows that have large burst size.  The
   probability of loss of AF21 traffic MUST NOT exceed the probability
   of loss of AF22 traffic, which in turn MUST NOT exceed the
   probability of loss of AF23.  Explicit Congestion Notification (ECN)
   [RFC3168] MAY also be used with Active Queue Management.

   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
   specifies a target queue depth for each DSCP, and the max-threshold
   specifies the queue depth above which all traffic with such a DSCP
   is dropped or ECN marked.  Thus, in this service class, the
   following inequality should hold in queue configurations:

   o  min-threshold AF23 < max-threshold AF23

   o  max-threshold AF23 <= min-threshold AF22

   o  min-threshold AF22 < max-threshold AF22

   o  max-threshold AF22 <= min-threshold AF21


Polk                    Expires August 25, 2013               [Page 61]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   o  min-threshold AF21 < max-threshold AF21

   o  max-threshold AF21 <= memory assigned to the queue

   Note: This configuration tends to drop AF23 traffic before AF22 and
         AF22 before AF21.  Many other AQM algorithms exist and are
         used; they should be configured to achieve a similar result.

4.7.  Conversational Signaling Service Class

   The Signaling service class is MUST be limited to delay-sensitive
   signaling traffic only, and then only applying to signaling that
   involves the Conversational service group.  Audio signaling includes
   signaling between IP phone and soft-switch, soft-client and
   soft-switch, and media gateway and soft-switch as well as
   peer-to-peer using various protocols.  Video and Hi-Res signaling
   includes video endpoint to video endpoint, as well as to Media
   transfer Point (MTP), to call control server(S), etc. This service
   class is intended to be used for control of voice and video sessions
   and applications.  Protocols using this service class require a
   relatively fast response, as there are typically several messages of
   different sizes sent for control of the session.  This service class
   is configured to provide good response for short-lived, intermittent
   flows that require real-time packet forwarding.  This is not the
   service class for Instant Messaging (IM), that's within the bounds
   of the Low-Latency Data service class. The Conversational Signaling
   service class MUST be configured so that the probability of packet
   drop or significant queuing delay under peak load is very low in IP
   network segments that provide this interface.

   The Conversational Signaling service class MUST use the new A/V-Sig
   PHB, defined in [ID-DSCP].  This service class MUST be configured to
   provide a minimum bandwidth assurance for A/V-Sig marked packets to
   ensure that they get forwarded.  In other words, this service class
   MUST NOT be starved from transmission within a reasonable timeframe,
   given that the entire Conversational service group depends on these
   signaling messages successful delivery. Network engineering SHOULD
   be done to ensure there is roughly 1-4% available per node interface
   that audio and video traverse.  Local conditions MUST be considered
   when determining exactly how much bandwidth is given to this service
   class. The Conversational Signaling service class SHOULD be
   configured to use a Rate Queuing system such as that defined in
   Section 1.4.1.2 of this document.

   The following applications SHOULD use the Conversational Signaling
   service class:

   o  Peer-to-peer IP telephony signaling (e.g., SIP, H.323, XMPP).

   o  Peer-to-peer signaling for multimedia applications (e.g., SIP,
      H.323, XMPP).


Polk                    Expires August 25, 2013               [Page 62]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   o  Peer-to-peer real-time control function.

   o  Client-server IP telephony signaling using H.248, MEGACO, MGCP,
      IP encapsulated ISDN, or other proprietary protocols.

   o  Signaling to control IPTV applications using protocols such as
      IGMP.

   o  Signaling flows between high-capacity telephony call servers or
      soft switches using protocol such as SIP-T.  Such high-capacity
      devices may control thousands of telephony (VoIP) calls.

   o  Signaling for one-way video flows, such as RTSP [RFC2326].

   o  IGMP, when used for multicast session control such as channel
      changing in IPTV systems.

   o  OPTIONALLY, this service class can be used for on-path
      reservation signaling for the traffic flows that will use the
      "admitted" DSCPs. The alternative is to have the on-path
      signaling (for reservations) use the DSCP within that service
      class. This provides a similar treatment of the signaling to the
      data flow, which might be desired.

   The following are traffic characteristics:

   o  Variable size packets, normally one packet at a time.

   o  Intermittent traffic flows.

   o  Traffic may burst at times.

   o  Delay-sensitive control messages sent between two end points.

   RECOMMENDED DSCP marking:

   o  All flows in this service class are marked with A/V-Sig.

   Applications or IP end points SHOULD pre-mark their packets with
   A/V-Sig DSCP value.  If the end point is not capable of setting the
   DSCP value, then the router topologically closest to the end point
   SHOULD perform Multifield (MF) Classification, as defined in
   [RFC2475].

   RECOMMENDED conditioning performed at DiffServ network edge:

   o  Packet flow marking (DSCP setting) from untrusted sources (end
      user devices) SHOULD be verified at ingress to DiffServ network
      using Multifield (MF) Classification methods defined in
      [RFC2475].



Polk                    Expires August 25, 2013               [Page 63]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   o  Packet flows from untrusted sources (end user devices) SHOULD be
      policed at ingress to DiffServ network, e.g., using single rate
      with burst size token bucket policer to ensure that the traffic
      stays within its negotiated or engineered bounds.

   o  Packet flows from trusted sources (application servers inside
      administered network) MAY not require policing.

   o  Policing of packet flows across peering points in which each peer
      is participating in the call set-up MUST be performed to the
      Service Level Agreement (SLA).

   The fundamental service offered to "Conversational Signaling"
   traffic is enhanced best-effort service with controlled rate and
   delay.  The service SHOULD be engineered so that A/V-Sig marked
   packet flows have sufficient bandwidth in the network to provide
   high assurance of delivery and low delay.  Normally, traffic in this
   service class does not respond dynamically to packet loss.  As such,
   Active Queue Management  [RFC2309] SHOULD NOT be applied to A/V-Sig
   marked packet flows.


4.8.  High-Throughput Data Service Class

   The High-Throughput Data service class is RECOMMENDED for elastic
   applications that require timely packet forwarding of variable rate
   traffic sources and, more specifically, is configured to provide
   good throughput for TCP longer-lived flows.  TCP [RFC1633] or a
   transport with a consistent Congestion Avoidance Procedure [RFC2581]
   [RFC3782] normally will drive as high a data rate as it can obtain
   over a long period of time.  The FTP protocol is a common example,
   although one cannot definitively say that all FTP transfers are
   moving data in bulk.

   The High-Throughput Data service class SHOULD use the Assured
   Forwarding (AF) PHB, defined in [RFC2597].  This service class
   SHOULD be configured to provide a minimum bandwidth assurance for
   AF11, AF12, and AF13 marked packets to ensure that they are
   forwarded in a timely manner.  The High-Throughput Data service
   class SHOULD be configured to use a Rate Queuing system such as that
   defined in Section 1.4.1.2 of this document.

   The following applications SHOULD use the High-Throughput Data
   service class:

   o  Store and forward applications.

   o  File transfer applications (e.g., FTP, HTTP, etc).

   o  Email.

   o  VPN service that supports two rates (committed information rate


Polk                    Expires August 25, 2013               [Page 64]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

      and excess or peak information rate).

   The following are traffic characteristics:

   o  Variable size packets.

   o  Variable packet emission rate.

   o  Variable rate.

   o  With packet bursts of TCP window size.

   o  Source capable of reducing its transmission rate based on
      detection of packet loss at the receiver or through explicit
      congestion notification.

   Applications or IP end points SHOULD pre-mark their packets with
   DSCP values as shown below.  If the end point is not capable of
   setting the DSCP value, then the router topologically closest to the
   end point SHOULD perform Multifield (MF) Classification, as defined
   in [RFC2475], and mark all packets as AF1x.  Note: In this case, the
   two-rate, three-color marker will be configured to operate in
   Color-Blind mode.

   RECOMMENDED DSCP marking:

   o  AF11 = up to specified rate "A".

   o  AF12 = in excess of specified rate "A" but below specified rate
             "B".

   o  AF13 = in excess of specified rate "B".

   o  Where "A" < "B".

   RECOMMENDED conditioning performed at DiffServ network edge:

   o  The two-rate, three-color marker SHOULD be configured to provide
      the behavior as defined in trTCM [RFC2698].

   o  If packets are marked by trusted sources or a previously trusted
      DiffServ domain and the color marking is to be preserved, then
      the two-rate, three-color marker SHOULD be configured to operate
      in Color-Aware mode.

   o  If the packet marking is not trusted or the color marking is not
      to be preserved, then the two-rate, three-color marker SHOULD be
      configured to operate in Color-Blind mode.

   The fundamental service offered to "High-Throughput Data" traffic is
   enhanced best-effort service with a specified minimum rate.  The
   service SHOULD be engineered so that AF11 marked packet flows have


Polk                    Expires August 25, 2013               [Page 65]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   sufficient bandwidth in the network to provide assured delivery.  It
   can be assumed that this class will consume any available bandwidth
   and that packets traversing congested links may experience higher
   queuing delays or packet loss.  Since the AF1x traffic is elastic
   and responds dynamically to packet loss, Active Queue Management
   [RFC2309] SHOULD be used primarily to control TCP flow rates at
   congestion points by dropping packets from TCP flows that have
   higher rates first.  The probability of loss of AF11 traffic MUST
   NOT exceed the probability of loss of AF12 traffic, which in turn
   MUST NOT exceed the probability of loss of AF13.  In such a case, if
   one network customer is driving significant excess and another seeks
   to use the link, any losses will be experienced by the high-rate
   user, causing him to reduce his rate.  Explicit Congestion
   Notification (ECN) [RFC3168] MAY also be used with Active Queue
   Management.

   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
   specifies a target queue depth for each DSCP, and the max-threshold
   specifies the queue depth above which all traffic with such a DSCP
   is dropped or ECN marked.  Thus, in this service class, the
   following inequality should hold in queue configurations:

   o  min-threshold AF13 < max-threshold AF13

   o  max-threshold AF13 <= min-threshold AF12

   o  min-threshold AF12 < max-threshold AF12

   o  max-threshold AF12 <= min-threshold AF11

   o  min-threshold AF11 < max-threshold AF11

   o  max-threshold AF11 <= memory assigned to the queue

   Note: This configuration tends to drop AF13 traffic before AF12 and
         AF12 before AF11.  Many other AQM algorithms exist and are
         used; they should be configured to achieve a similar result.

4.9.  Standard Service Class

   The Standard service class is RECOMMENDED for traffic that has not
   been classified into one of the other supported forwarding service
   classes in the DiffServ network domain.  This service class provides
   the Internet's "best-effort" forwarding behavior.  This service
   class typically has minimum bandwidth guarantee.

   The Standard service class MUST use the Default Forwarding (DF) PHB,
   defined in [RFC2474], and SHOULD be configured to receive at least a
   small percentage of forwarding resources as a guaranteed minimum.
   This service class SHOULD be configured to use a Rate Queuing system
   such as that defined in Section 1.4.1.2 of this document.



Polk                    Expires August 25, 2013               [Page 66]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   The following applications SHOULD use the Standard service class:

   o  Network services, DNS, DHCP, BootP.

   o  Any undifferentiated application/packet flow transported through
      the DiffServ enabled network.

   The following is a traffic characteristic:

   o  Non-deterministic, mixture of everything.

   The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'.

   Network Edge Conditioning:

      There is no requirement that conditioning of packet flows be
      performed for this service class.

   The fundamental service offered to the Standard service class is
   best-effort service with active queue management to limit overall
   delay.  Typical configurations SHOULD use random packet dropping to
   implement Active Queue Management [RFC2309] or Explicit Congestion
   Notification [RFC3168], and MAY impose a minimum or maximum rate on
   the queue.

   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
   specifies a target queue depth, and the max-threshold specifies the
   queue depth above which all traffic is dropped or ECN marked.  Thus,
   in this service class, the following inequality should hold in queue
   configurations:

   o  min-threshold DF < max-threshold DF

   o  max-threshold DF <= memory assigned to the queue

   Note: Many other AQM algorithms exist and are used; they should be
         configured to achieve a similar result.

4.10.  Low-Priority Data

   The Low-Priority Data service class serves applications that run
   over TCP [RFC0793] or a transport with consistent congestion
   avoidance procedures [RFC2581] [RFC3782] and that the user is
   willing to accept service without guarantees.  This service class is
   specified in [RFC3662] and [QBSS].

   The following applications MAY use the Low-Priority Data service
   class:

   o  Any TCP based-application/packet flow transported through the
      DiffServ enabled network that does not require any bandwidth
      assurances.


Polk                    Expires August 25, 2013               [Page 67]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013


   The following is a traffic characteristic:

   o  Non-real-time and elastic.

   Network Edge Conditioning:

      There is no requirement that conditioning of packet flows be
      performed for this service class.

   The RECOMMENDED DSCP marking is CS1 (Class Selector 1).

   The fundamental service offered to the Low-Priority Data service
   class is best-effort service with zero bandwidth assurance.  By
   placing it into a separate queue or class, it may be treated in a
   manner consistent with a specific Service Level Agreement.

   Typical configurations SHOULD use Explicit Congestion Notification
   [RFC3168] or random loss to implement Active Queue Management
   [RFC2309].

   If RED [RFC2309] is used as an AQM algorithm, the min-threshold
   specifies a target queue depth, and the max-threshold specifies the
   queue depth above which all traffic is dropped or ECN marked.  Thus,
   in this service class, the following inequality should hold in queue
   configurations:

   o  min-threshold CS1 < max-threshold CS1

   o  max-threshold CS1 <= memory assigned to the queue

   Note: Many other AQM algorithms exist and are used; they should be
         configured to achieve a similar result.

5.  Additional Information on Service Class Usage

   In this section, we provide additional information on how some
   specific applications should be configured to use the defined
   service classes.

5.1. Mapping for NTP

   From tests that were performed, indications are that precise time
   distribution requires a very low packet delay variation (jitter)
   transport.  Therefore, we suggest that the following guidelines for
   Network Time Protocol (NTP) be used:

   o  When NTP is used for providing high-accuracy timing within an
      administrator's (carrier's) network or to end users/clients, the
      audio service class SHOULD be used, and NTP packets should be
      marked with EF DSCP value.



Polk                    Expires August 25, 2013               [Page 68]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   o  For applications that require "wall clock" timing accuracy, the
      Standard service class should be used, and packets should be
      marked with DF DSCP.

5.2.  VPN Service Mapping

   "Differentiated Services and Tunnels" [RFC2983] considers the
   interaction of DiffServ architecture with IP tunnels of various
   forms.  Further to guidelines provided in RFC 2983, below are
   additional guidelines for mapping service classes that are supported
   in one part of the network into a VPN connection.  This discussion
   is limited to VPNs that use DiffServ technology for traffic
   differentiation.

   o  The DSCP value(s) that is/are used to represent a PHB or a PHB
      group SHOULD be the same for the networks at both ends of the VPN
      tunnel, unless remarking of DSCP is done as ingress/egress
      processing function of the tunnel.  DSCP marking needs to be
      preserved along the tunnel, end to end.

   o  The VPN MAY be configured to support one or more service classes.
      It is left up to the administrators of the two networks to agree
      on the level of traffic differentiation that will be provided in
      the network that supports VPN service.  Service classes are then
      mapped into the supported VPN traffic forwarding behaviors that
      meet the traffic characteristics and performance requirements of
      the encapsulated service classes.

   o  The traffic treatment in the network that is providing the VPN
      service needs to be such that the encapsulated service class or
      classes receive comparable behavior and performance in terms of
      delay, jitter, and packet loss and that they are within the
      limits of the service specified.

   o  The DSCP value in the external header of the packet forwarded
      through the network providing the VPN service can be different
      from the DSCP value that is used end to end for service
      differentiation in the end network.

   o  The guidelines for aggregation of two or more service classes
      into a single traffic forwarding treatment in the network that is
      providing the VPN service is for further study.

6.  Security Considerations

   This document discusses policy and describes a common policy
   configuration, for the use of a Differentiated Services Code Point
   by transports and applications.  If implemented as described, it
   should require that the network do nothing that the network has not
   already allowed.  If that is the case, no new security issues should
   arise from the use of such a policy.



Polk                    Expires August 25, 2013               [Page 69]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   It is possible for the policy to be applied incorrectly, or for a
   wrong policy to be applied in the network for the defined service
   class.  In that case, a policy issue exists that the network SHOULD
   detect, assess, and deal with.  This is a known security issue in
   any network dependent on policy-directed behavior.

   A well-known flaw appears when bandwidth is reserved or enabled for
   a service (for example, voice and/or video transport) and another
   service or an attacking traffic stream uses it.  This possibility is
   inherent in DiffServ technology, which depends on appropriate packet
   markings. When bandwidth reservation or a priority queuing system is
   used in a vulnerable network, the use of authentication and flow
   admission is recommended.  To the author's knowledge, there is no
   known technical way to respond to an unauthenticated data stream
   using service that it is not intended to use, and such is the nature
   of the Internet.

   The use of a service class by a user is not an issue when the SLA
   between the user and the network permits him to use it, or to use it
   up to a stated rate.  In such cases, simple policing is used in the
   Differentiated Services Architecture.  Some service classes, such as
   Network Control, are not permitted to be used by users at all; such
   traffic should be dropped or remarked by ingress filters.  Where
   service classes are available under the SLA only to an authenticated
   user rather than to the entire population of users, authentication
   and authorization services are required, such as those surveyed in
   [AUTHMECH].


7.  Contributing Authors

   This section specifically calls out the authors of RFC 4594, from
   which this document is based on.

   Jozef Babiarz
   Nortel Networks

   Kwok Ho Chan
   Nortel Networks
   Email: khchan.work@gmail.com

   Fred Baker
   Cisco Systems
   EMail: fred@cisco.com

   Of note, two of the three mentioned authors above worked for Nortel
   Networks at the time of writing RFC 4594, a company that no longer
   exists. This author has not seen or heard from those two in many,
   many years or IETF meetings - as a result of not knowing their new
   email addresses (or phone numbers).

   While much of this document has been rewritten with either edited or


Polk                    Expires August 25, 2013               [Page 70]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

   brand new material, there are many short paragraphs that remain as
   they were from RFC 4594, as well as many sentences that were also
   left unchanged. Additionally, there were no new graphs, charts,
   diagrams, or tables introduced, meaning the first 4 tables within
   this document existed in RFC 4594, created by those authors.
   Presently, each of those tables contain modified and new
   information. The last 3 tables, specifically tables 5, 6, & 7 were
   removed because the examples section was removed.

   This author believes there must be proper credit given for all the
   contributions, including the framework this document retains from
   that RFC.  Periodically, throughout this document, what was written
   remains the best way of conveying a thought, rule, or otherwise
   stated behavior or mechanism. Because RFC 4594 was rather large,
   there is no realistic way of identifying each part that was left
   untouched. Further, properly quoting that RFC and leaving those
   sentences embedded in this document would render this document
   highly unreadable. Another application could be used to show the
   changes, deletions and additions - but not one that the IETF accepts
   presently.

   This author has created this "Contributing Authors" section as a way
   of properly identifying those 3 individuals that provided text
   within this document. We will let the community judge if this is
   'good enough' (i.e., rough consensus), or if another way is better.


8.  Acknowledgements

   The author would like to thank Paul Jones, Glen Lavers, Mo Zanaty,
   David Benham, Michael Ramalho, Gorry Fairhurst, David Black, Brian
   Carpenter, Al Morton, Ruediger Geib and Shitanshu Shah for their
   comments and questions about this effort that ultimately helped
   shape this document.




   Below are the folks that were acknowledged in RFC 4594, and this
   author does not want to lose their recognition of contributions to
   the original effort.

     "The authors thank the TSVWG reviewers, David Black, Brian E.
      Carpenter, and Alan O'Neill for their review and input to this
      document.

      The authors acknowledge a great many inputs, most notably from
      Bruce Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois
      Audet, Morgan Littlewood, Robert Milne, John Shuler, Nalin
      Mistry, Al Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil
      Dickinson, Mike Fidler, and Shane Amante.  Kimberly King, Joe
      Zebarth, and Alistair Munroe each did a thorough proofreading,


Polk                    Expires August 25, 2013               [Page 71]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

      and the document is better for their contributions."


9.  References

9.1.  Normative References

 [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
            September 1981.

 [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
            793, September 1981.

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

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

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

 [RFC2309]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
            S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
            Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
            S., Wroclawski, J., and L. Zhang, "Recommendations on
            Queue Management and Congestion Avoidance in the
            Internet", RFC 2309, April 1998.

 [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
            "Definition of the Differentiated Services Field (DS
            Field) in the IPv4 and IPv6 Headers", RFC 2474, December
            1998.

 [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
            and W. Weiss, "An Architecture for Differentiated
            Service", RFC 2475, December 1998.

 [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
            "Assured Forwarding PHB Group", RFC 2597, June 1999.

 [RFC3246]  Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
            Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D.
            Stiliadis, "An Expedited Forwarding PHB (Per-Hop
            Behavior)", RFC 3246, March 2002.

 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
           Jacobson, "RTP: A Transport Protocol for Real-Time
           Applications", STD 64, RFC 3550, July 2003.

 [RFC3662]  Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
            Per-Domain Behavior (PDB) for Differentiated Services",


Polk                    Expires August 25, 2013               [Page 72]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

            RFC 3662, December 2003.

 [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code
           Point (DSCP) for Capacity-Admitted Traffic", RFC 5865,
           May 2010


9.2.  Informative References

 [AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms",
            Work in Progress, September 2005.

 [QBSS]     "QBone Scavenger Service (QBSS) Definition", Internet2
            Technical Report Proposed Service Definition, March 2001.

 [IEEE1Q]   IEEE, 802.1Q Specification

 [IEEE1E]   IEEE, 802.1E Wireless LAN User Priority Specification

 [RFC1633]  Braden, R., Clark, D., and S. Shenker, "Integrated
            Services in the Internet Architecture: an Overview", RFC
            1633, June 1994.

 [RFC2205]  Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
            Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
            Functional Specification", RFC 2205, September 1997.

 [RFC2581]  Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
            Control", RFC 2581, April 1999.

 [RFC2697]  Heinanen, J. and R. Guerin, "A Single Rate Three Color
            Marker", RFC 2697, September 1999.

 [RFC2698]  Heinanen, J. and R. Guerin, "A Two Rate Three Color
            Marker", RFC 2698, September 1999.

 [RFC2963]  Bonaventure, O. and S. De Cnodder, "A Rate Adaptive
            Shaper for Differentiated Services", RFC 2963, October
            2000.

 [RFC2983]  Black, D., "Differentiated Services and Tunnels", RFC
            2983, October 2000.

 [RFC2996]  Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
            November 2000.

 [RFC3086]  Nichols, K. and B. Carpenter, "Definition of
            Differentiated Services Per Domain Behaviors and Rules
            for their Specification", RFC 3086, April 2001.

 [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
            of Explicit Congestion Notification (ECN) to IP", RFC


Polk                    Expires August 25, 2013               [Page 73]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013

            3168, September 2001.

 [RFC3175]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
            "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC
            3175, September 2001.

 [RFC3290]  Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
            Informal Management Model for Diffserv Routers", RFC 3290,
            May 2002.

 [RFC3782]  Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
            Modification to TCP's Fast Recovery Algorithm", RFC 3782,
            April 2004.

 [RFC5462] L. Andersson, R. Asati, "Multiprotocol Label Switching
           (MPLS) Label Stack Entry: EXP Field Renamed to Traffic Class
           Field", RFC 5462, February 2009


Authors' Address

James Polk
3913 Treemont Circle
Colleyville, Texas  76034

Phone: +1.817.271.3552
Email: jmpolk@cisco.com




Appendix A - Changes

   Here is a list of all the changes that were captured during the
   editing process. This will not be a complete list, and others are
   free to point out what the authors missed, and we'll include that in
   the next release.

A.1 Since Individual -02 to -03

   o  Inserted section 1.6 to explain fundamentally what has changed
      since RFC 4594, and why changes are necessary.


A.2  Since Individual -01 to -02

   o  Added text to the Intro section on the justification from
      DiffServ Problem Statement draft, as to more of why this update
      is necessary.

   o  Added text to the Intro section expanding on the concept of
      service classes vs. treatment aggregates (from RFC 5127).


Polk                    Expires August 25, 2013               [Page 74]


Internet-Draft  Std Config. for DiffServ Service Classes       Feb 2013



A.3  Since Individual -00 to -01

   o  Added Section 2.4 which covers the conflation issues regarding
      the differences between service classes and treatment aggregates.

   o  Added example operational configurations of treatment aggregates
      applied to this draft's new set of service classes and additional
      DSCPs.

   o  Added references RFC 5865, RFC 5462, IEEE 802.1E and IEEE 802.1Q.


A.4  Since RFC 4594 to Individual Update -00

   o  rewrote Intro to emphasize current topics

   o  Created a Conversational Service group, comprising the audio,
      video and Hi-Res service classes - because they have similar
      characteristics.

   o  Incorporated the 6 new DSCPs from [ID-DSCP].

   o  moved the example section, en mass, to an appendix that might not
      be kept for this version. We're not sure it accomplishes what it
      needs to, and might not provide any real usefulness.

   o  Moved 'Realtime-Interactive' service class to CS5, from CS4

   o  Changed 'Broadcast Video' service class to 'Broadcast' service
      class

   o  Changed AF4X to 'Video' service class, replacing 'Multimedia
      Conferencing' service class

   o  Moved 'Multimedia Conferencing' service class to different DSCPs

   o  Added the 'Hi-Res' service class

   o  Removed section 5.1 on signaling choices. It has been included in
      the main body of the text.

   o  Changed document title

   o  ...








Polk                    Expires August 25, 2013               [Page 74]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/