Internet DRAFT - draft-polk-tsvwg-rfc4594-update

draft-polk-tsvwg-rfc4594-update






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]