tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4594

 
 
 

Configuration Guidelines for DiffServ Service Classes

Part 2 of 4, p. 11 to 30
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 11 
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.

Top      Up      ToC       Page 12 
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  Telephony service class is best suited for applications that
      require very low delay variation and are of constant rate, such as
      IP telephony (VoIP) and circuit emulation over IP applications.
   o  Signaling service class is best suited for peer-to-peer and
      client-server signaling and control functions using protocols such
      as SIP, SIP-T, H.323, H.248, and Media Gateway Control Protocol
      (MGCP).
   o  Multimedia Conferencing service class is best suited for
      applications that require very low delay and have the ability to
      change encoding rate (rate adaptive), such as H.323/V2 and later
      video conferencing service.
   o  Real-Time Interactive service class is intended for interactive
      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 video
      conferencing applications that do not have the ability to change
      encoding rates or to mark packets with different importance
      indications.
   o  Multimedia Streaming service class is best suited for variable
      rate elastic streaming media applications where a human is waiting
      for output and where the application has the capability to react
      to packet loss by reducing its transmission rate, such as
      streaming video and audio and webcast.
   o  Broadcast Video service class is best suited 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.

Top      Up      ToC       Page 13 
   o  Low-Latency Data service class is best suited for data processing
      applications where a human is waiting for output, such as web-
      based ordering or an Enterprise Resource Planning (ERP)
      application.
   o  High-Throughput Data service class is best suited for store and
      forward applications such as FTP and billing record transfer.
   o  Standard service class is for traffic that has not been identified
      as requiring differentiated treatment and is normally referred to
      as best effort.
   o  Low-Priority Data service class is intended for packet flows where
      bandwidth assurance is not required.

2.2.  Categorization of User 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 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 or H.248 for IP telephone service
      and SIP or Internet Group Management Protocol (IGMP) for control
      of broadcast TV service to subscribers.  Although user signaling
      flows have similar performance requirements as Low-Latency Data,
      they need to be distinguished and marked with a different DSCP.
      The essential distinction is something like "administrative
      control and management" of the traffic affected as the protocols
      in this class tend to be tied to the media stream/session they
      signal and control.

   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, five service
   classes have been defined.

   o  Telephony service class is intended for IP telephony (VoIP)
      service.  It may also be used for other applications that meet the
      defined traffic characteristics and performance requirements.
   o  Real-Time Interactive service class is intended for inelastic
      video flows from applications such as SIP-based desktop video
      conferencing applications and for interactive gaming.

Top      Up      ToC       Page 14 
   o  Multimedia Conferencing service class is for video conferencing
      solutions that have the ability to reduce their transmission rate
      on detection of congestion.  These flows can therefore be
      classified as rate adaptive.  As currently two types of video
      conferencing equipment are used in IP networks (ones that generate
      inelastic traffic and ones that generate rate-adaptive traffic),
      two service class are needed.  The Real-Time Interactive service
      class should be used for equipment that generates inelastic video
      flows and the Multimedia Conferencing service class for equipment
      that generates rate-adaptive video flows.
   o  Broadcast Video service class is to be used for inelastic traffic
      flows, which are intended for broadcast TV service and for
      transport of live video and audio events.
   o  Multimedia Streaming service class is to be used for elastic
      multimedia traffic flows.  This multimedia 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 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.

Top      Up      ToC       Page 15 
   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 Quality of Service (QoS) rating as defined in ITU-T
   Recommendation G.1010.

    -----------------------------------------------------------------
   | Application |    Service    | Signaled |  Flow     |   G.1010   |
   |  Categories |     Class     |          | Behavior  |   Rating   |
   |-------------+---------------+----------+-----------+------------|
   | Application |   Signaling   |   Not    | Inelastic | Responsive |
   |   Control   |               |applicable|           |            |
   |-------------+---------------+----------+-----------+------------|
   |             |   Telephony   |   Yes    | Inelastic | Interactive|
   |             |---------------+----------+-----------+------------|
   |             |   Real-Time   |   Yes    | Inelastic | Interactive|
   |             |  Interactive  |          |           |            |
   |             |---------------+----------+-----------+------------|
   |    Media-   |   Multimedia  |   Yes    |    Rate   | Interactive|
   |   Oriented  |  Conferencing |          |  Adaptive |            |
   |             |---------------+----------+-----------+------------|
   |             |Broadcast Video|   Yes    | Inelastic | Responsive |
   |             |---------------+----------+-----------+------------|
   |             |  Multimedia   |   Yes    |  Elastic  |   Timely   |
   |             |   Streaming   |          |           |            |
   |-------------+---------------+----------+-----------+------------|
   |             |  Low-Latency  |    No    |  Elastic  | Responsive |
   |             |     Data      |          |           |            |
   |             |---------------+----------+-----------+------------|
   |   Data      |High-Throughput|    No    |  Elastic  |   Timely   |
   |             |    Data       |          |           |            |
   |             |---------------+----------+-----------+------------|
   |             | Low-Priority  |    No    |  Elastic  |Non-critical|
   |             |    Data       |          |           |            |
   |-------------+---------------+----------+-----------+------------|
   | Best Effort |   Standard    |    Not Specified     |Non-critical|
    -----------------------------------------------------------------

           Figure 1. User/Subscriber Service Classes Grouping

Top      Up      ToC       Page 16 
   Here is a short explanation of the end user QoS category as defined
   in ITU-T Recommendation G.1010.  User 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 provides guidelines for network administrators in
   configuring their network for the level of service differentiation
   that is appropriate in their network to meet their QoS needs.  It is
   expected that network operators will configure and provide in their
   networks a subset of the defined service classes.  Our intent is to
   provide guidelines for configuration of Differentiated Services for a
   wide variety of applications, services, and network configurations.
   In addition, network administrators may choose to define and deploy
   other service classes in their network.

   Figure 2 provides a behavior view for traffic serviced by each
   service class.  The traffic characteristics column defines the
   characteristics and profile of flows serviced, and the tolerance to
   loss, delay, and jitter columns define the treatment the flows will
   receive.  End-to-end quantitative performance requirements may be
   obtained from ITU-T Recommendations Y.1541 and Y.1540.

Top      Up      ToC       Page 17 
    -------------------------------------------------------------------
   |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) |      |      |      |
   |---------------+------------------------------+------+------+------|
   |               | Fixed-size small packets,    | Very | Very | Very |
   |  Telephony    | constant emission rate,      |  Low |  Low |  Low |
   |               | inelastic and low-rate flows |      |      |      |
   |---------------+------------------------------+------+------+------|
   |   Signaling   | Variable size packets, some  | Low  | Low  |  Yes |
   |               | what bursty short-lived flows|      |      |      |
   |---------------+------------------------------+------+------+------|
   |  Multimedia   | Variable size packets,       | Low  | Very |      |
   | Conferencing  | constant transmit interval,  |  -   | Low  | Low  |
   |               |rate adaptive, reacts to loss |Medium|      |      |
   |---------------+------------------------------+------+------+------|
   |   Real-Time   | RTP/UDP streams, inelastic,  | Low  | Very | Low  |
   |  Interactive  | mostly variable rate         |      | Low  |      |
   |---------------+------------------------------+------+------+------|
   |  Multimedia   |  Variable size packets,      |Low - |Medium|  Yes |
   |   Streaming   | elastic with variable rate   |Medium|      |      |
   |---------------+------------------------------+------+------+------|
   |   Broadcast   | Constant and variable rate,  | Very |Medium|  Low |
   |     Video     | inelastic, non-bursty flows  |  Low |      |      |
   |---------------+------------------------------+------+------+------|
   |  Low-Latency  | Variable rate, bursty short- | Low  |Low - |  Yes |
   |      Data     |  lived elastic flows         |      |Medium|      |
   |---------------+------------------------------+------+------+------|
   |      OAM      |  Variable size packets,      | Low  |Medium|  Yes |
   |               |  elastic & inelastic flows   |      |      |      |
   |---------------+------------------------------+------+------+------|
   |High-Throughput| Variable rate, bursty long-  | Low  |Medium|  Yes |
   |      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

Top      Up      ToC       Page 18 
   Notes for Figure 2: A "Yes" in the jitter-tolerant column implies
   that data is buffered in the endpoint and that a moderate level of
   network-induced variation in delay will not affect the application.
   Applications that use TCP 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, 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 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.

Top      Up      ToC       Page 19 
    ------------------------------------------------------------------
   |   Service     |  DSCP   |    DSCP     |       Application        |
   |  Class Name   |  Name   |    Value    |        Examples          |
   |===============+=========+=============+==========================|
   |Network Control|  CS6    |   110000    | Network routing          |
   |---------------+---------+-------------+--------------------------|
   | Telephony     |   EF    |   101110    | IP Telephony bearer      |
   |---------------+---------+-------------+--------------------------|
   |  Signaling    |  CS5    |   101000    | IP Telephony signaling   |
   |---------------+---------+-------------+--------------------------|
   | Multimedia    |AF41,AF42|100010,100100|   H.323/V2 video         |
   | Conferencing  |  AF43   |   100110    |  conferencing (adaptive) |
   |---------------+---------+-------------+--------------------------|
   |  Real-Time    |  CS4    |   100000    | Video conferencing and   |
   |  Interactive  |         |             | Interactive gaming       |
   |---------------+---------+-------------+--------------------------|
   | Multimedia    |AF31,AF32|011010,011100| Streaming video and      |
   | Streaming     |  AF33   |   011110    |   audio on demand        |
   |---------------+---------+-------------+--------------------------|
   |Broadcast Video|  CS3    |   011000    |Broadcast TV & live events|
   |---------------+---------+-------------+--------------------------|
   | Low-Latency   |AF21,AF22|010010,010100|Client/server transactions|
   |   Data        |  AF23   |   010110    | Web-based ordering       |
   |---------------+---------+-------------+--------------------------|
   |     OAM       |  CS2    |   010000    |         OAM&P            |
   |---------------+---------+-------------+--------------------------|
   |High-Throughput|AF11,AF12|001010,001100|  Store and forward       |
   |    Data       |  AF13   |   001110    |     applications         |
   |---------------+---------+-------------+--------------------------|
   |    Standard   | DF (CS0)|   000000    | Undifferentiated         |
   |               |         |             | applications             |
   |---------------+---------+-------------+--------------------------|
   | Low-Priority  |  CS1    |   001000    | Any flow that has no BW  |
   |     Data      |         |             | assurance                |
    ------------------------------------------------------------------

                Figure 3. DSCP to Service Class Mapping

   Notes for Figure 3: Default Forwarding (DF) and Class Selector 0
   (CS0) provide equivalent behavior and use the same DS codepoint,
   '000000'.

   It is expected that network administrators will base their choice of
   the service classes that they will support on their need, starting
   off with three or four service classes for user traffic and adding
   others as the need arises.

Top      Up      ToC       Page 20 
   Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD 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 can 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  | See Section 3.1   | RFC2474 |  Rate  | Yes|
   |---------------+------+-------------------+---------+--------+----|
   |   Telephony   |  EF  |Police using sr+bs | RFC3246 |Priority| No |
   |---------------+------+-------------------+---------+--------+----|
   |   Signaling   | CS5  |Police using sr+bs | RFC2474 |  Rate  | No |
   |---------------+------+-------------------+---------+--------+----|
   |   Multimedia  | AF41 |  Using two-rate,  |         |        | Yes|
   | Conferencing  | AF42 |three-color marker | RFC2597 |  Rate  | per|
   |               | AF43 | (such as RFC 2698)|         |        |DSCP|
   |---------------+------+-------------------+---------+--------+----|
   |   Real-Time   | CS4  |Police using sr+bs | RFC2474 |  Rate  | No |
   |   Interactive |      |                   |         |        |    |
   |---------------+------+-------------------+---------|--------+----|
   |  Multimedia   | AF31 |  Using two-rate,  |         |        | Yes|
   |  Streaming    | AF32 |three-color marker | RFC2597 |  Rate  | per|
   |               | AF33 | (such as RFC 2698)|         |        |DSCP|
   |---------------+------+-------------------+---------+--------+----|
   |Broadcast Video| CS3  |Police using sr+bs | RFC2474 |  Rate  | No |
   |---------------+------+-------------------+---------+--------+----|
   |    Low-       | AF21 | Using single-rate,|         |        | Yes|
   |    Latency    | AF22 |three-color marker | RFC2597 |  Rate  | per|
   |    Data       | AF23 | (such as RFC 2697)|         |        |DSCP|
   |---------------+------+-------------------+---------+--------+----|
   |     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 QoS Mechanisms Used for Each Service Class

Top      Up      ToC       Page 21 
   Notes for Figure 4:

   o  Conditioning at DS edge means that traffic conditioning is
      performed at the edge of the DiffServ network where untrusted user
      devices are connected or between two 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 Real-Time Interactive service class SHOULD be
      configured to provide high bandwidth assurance.  It MAY be
      configured as a second EF PHB that uses relaxed performance
      parameters and a rate scheduler.
   o  The PHB for Broadcast Video service class SHOULD be configured to
      provide high bandwidth assurance.  It MAY be configured as a third
      EF PHB that uses relaxed performance parameters and a rate
      scheduler.
   o  In network segments that use IP precedence marking, only one of
      the two service classes can be supported, High-Throughput Data or
      Low-Priority Data.  We RECOMMEND that the DSCP value(s) of the
      unsupported service class be changed to 000xx1 on ingress and
      changed back to original value(s) on egress of the network segment
      that uses precedence marking.  For example, if Low-Priority Data
      is mapped to Standard service class, then 000001 DSCP marking MAY
      be used to distinguish it from Standard marked packets on egress.

2.4.  Deployment Scenarios

   It is expected that network administrators will base their choice of
   the service classes that they will support on their need, starting
   off with three or four service classes for user traffic and adding
   more service classes as the need arises.  In this section, we provide
   three examples of possible deployment scenarios.

2.4.1.  Example 1

   A network administrator determines that he needs to provide different
   performance levels (quality of service) in his network for the
   services that he will be offering to his customers.  He needs to
   enable his network to provide:

Top      Up      ToC       Page 22 
   o  Reliable VoIP (telephony) service, equivalent to Public Switched
      Telephone Network (PSTN).
   o  A low-delay assured bandwidth data service.
   o  Support for current Internet services.

   For this example, the network administrator's needs are addressed
   with the deployment of the following six service classes:

   o  Network Control service class for routing and control traffic that
      is needed for reliable operation of the provider's network.
   o  Standard service class for all traffic that will receive normal
      (undifferentiated) forwarding treatment through the network for
      support of current Internet service.
   o  Telephony service class for VoIP (telephony) bearer traffic.
   o  Signaling service class for Telephony signaling to control the
      VoIP service.
   o  Low-Latency Data service class for the low-delay assured bandwidth
      differentiated data service.
   o  OAM service class for operation and management of the network.

   Figure 5 provides a summary of the mechanisms needed for delivery of
   service differentiation for Example 1.

    -------------------------------------------------------------------
   |  Service      |  DSCP | Conditioning at   |   PHB   |        |    |
   |   Class       |       |    DS Edge        |  Used   | Queuing| AQM|
   |===============+=======+===================+=========+========+====|
   |Network Control|  CS6  | See Section 3.1   | RFC2474 |  Rate  | Yes|
   |---------------+-------+-------------------+---------+--------+----|
   |  Telephony    |   EF  |Police using sr+bs | RFC3246 |Priority| No |
   |---------------+-------+-------------------+---------+--------+----|
   |  Signaling    |  CS5  |Police using sr+bs | RFC2474 |  Rate  | No |
   |---------------+-------+-------------------+---------+--------+----|
   |    Low-       | AF21  | Using single-rate,|         |        | Yes|
   |   Latency     | AF22  |three-color marker | RFC2597 |  Rate  | per|
   |    Data       | AF23  | (such as RFC 2697)|         |        |DSCP|
   |---------------+-------+-------------------+---------+--------+----|
   |      OAM      |  CS2  |Police using sr+bs | RFC2474 |  Rate  | Yes|
   |---------------+-------+-------------------+---------+--------+----|
   |   Standard    |DF(CS0)| Not applicable    | RFC2474 |  Rate  | Yes|
   |               | +other|                   |         |        |    |
    -------------------------------------------------------------------

       Figure 5. Service Provider Network Configuration Example 1

Top      Up      ToC       Page 23 
   Notes for Figure 5:

   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.
   o  Any packet that is marked with DSCP value that is not represented
      by the supported service classes SHOULD be forwarded using the
      Standard service class.

2.4.2.  Example 2

   With this example, we show how network operators with Example 1
   capabilities can evolve their service offering to provide three new
   additional services to their customers.  The new additional service
   capabilities that are to be added are:

   o  SIP-based desktop video conference capability to complement VoIP
      (telephony) service.
   o  TV and on-demand movie viewing service to residential subscribers.
   o  Network-based data storage and file backup service to business
      customers.

   The new additional services that the network administrator would like
   to offer are addressed with the deployment of the following four
   additional service classes (these are additions to the six service
   classes already defined in Example 1):

   o  Real-Time Interactive service class for transport of MPEG-4 real-
      time video flows to support desktop video conferencing.  The
      control/signaling for video conferencing is done using the
      Signaling service class.
   o  Broadcast Video service class for transport of IPTV broadcast
      information.  The channel selection and control is via IGMP mapped
      into the Signaling service class.
   o  Multimedia Streaming service class for transport of stored MPEG-2
      or MPEG-4 content.  The selection and control of streaming
      information is done using the Signaling service class.  The
      selection of Multimedia Streaming service class for on-demand
      movie service was chosen as the set-top box used for this service
      has local buffering capability to compensate for the bandwidth
      variability of the elastic streaming information.  Note that if
      transport of on-demand movie service is inelastic, then the
      Broadcast Video service class SHOULD be used.
   o  High-Throughput Data service class is for transport of bulk data
      for network-based storage and file backup service to business
      customers.

Top      Up      ToC       Page 24 
   Figure 6 provides a summary of the mechanisms needed for delivery of
   service differentiation for all the service classes used in Example
   2.

    -------------------------------------------------------------------
   |  Service      |  DSCP | Conditioning at   |   PHB   |        |    |
   |   Class       |       |    DS Edge        |  Used   | Queuing| AQM|
   |===============+=======+===================+=========+========+====|
   |Network Control|  CS6  | See Section 3.1   | RFC2474 |  Rate  |Yes |
   |---------------+-------+-------------------+---------+--------+----|
   |  Telephony    |   EF  |Police using sr+bs | RFC3246 |Priority| No |
   |---------------+-------+-------------------+---------+--------+----|
   |  Signaling    |  CS5  |Police using sr+bs | RFC2474 |  Rate  | No |
   |---------------+-------+-------------------+---------+--------+----|
   |  Real-time    |  CS4  |Police using sr+bs | RFC2474 |  Rate  | No |
   |  Interactive  |       |                   |         |        |    |
   |---------------+-------+-------------------+---------+--------+----|
   |Broadcast Video|  CS3  |Police using sr+bs | RFC2474 |  Rate  | No |
   |---------------+-------+-------------------+---------+--------+----|
   |  Multimedia   | AF31  |  Using two-rate,  |         |        |Yes |
   |  Streaming    | AF32  |three-color marker | RFC2597 |  Rate  |per |
   |               | AF33  | (such as RFC 2698)|         |        |DSCP|
   |---------------+-------+-------------------+---------+--------+----|
   |    Low-       | AF21  | Using single-rate,|         |        |Yes |
   |   Latency     | AF22  |three-color marker | RFC2597 |  Rate  |per |
   |    Data       | AF23  | (such as RFC 2697)|         |        |DSCP|
   |---------------+-------+-------------------+---------+--------+----|
   |      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(CS0)| Not applicable    | RFC2474 |  Rate  |Yes |
   |               | +other|                   |         |        |    |
    -------------------------------------------------------------------

       Figure 6. Service Provider Network Configuration Example 2

   Notes for Figure 6:

   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.

Top      Up      ToC       Page 25 
   o  Any packet that is marked with DSCP value that is not represented
      by the supported service classes SHOULD be forwarded using the
      Standard service class.

2.4.3.  Example 3

   An enterprise network administrator determines that they need to
   provide different performance levels (quality of service) in their
   network for the new services that are being offered to corporate
   users.  The enterprise network needs to:

   o  Provide reliable corporate VoIP service.
   o  Provide video conferencing service to selected Conference Rooms.
   o  Support on-demand distribution of prerecorded audio and video
      information to large number of users.
   o  Provide a priority data transfer capability for engineering teams
      to share design information.
   o  Reduce or deny bandwidth during peak traffic periods for selected
      applications.
   o  Continue to provide normal IP service to all remaining
      applications and services.

   For this example, the enterprise's network needs are addressed with
   the deployment of the following nine service classes:

   o  Network Control service class for routing and control traffic that
      is needed for reliable operation of the enterprise network.
   o  OAM service class for operation and management of the network.
   o  Standard service class for all traffic that will receive normal
      (undifferentiated) forwarding treatment.
   o  Telephony service class for VoIP (telephony) bearer traffic.
   o  Signaling service class for Telephony signaling to control the
      VoIP service.
   o  Multimedia Conferencing service class for support of inter-
      Conference Room video conferencing service using H.323/V2 or
      similar equipment.
   o  Multimedia Streaming service class for transfer of prerecorded
      audio and video information.
   o  High-Throughput Data service class to provide bandwidth assurance
      for timely transfer of large engineering files.
   o  Low-Priority Data service class for selected background
      applications where data transfer can be delayed or suspended for a
      period of time during peak network load conditions.

Top      Up      ToC       Page 26 
   Figure 7 provides a summary of the mechanisms needed for delivery of
   service differentiation for Example 3.

    -------------------------------------------------------------------
   |  Service      |  DSCP | Conditioning at   |   PHB   |        |    |
   |   Class       |       |    DS Edge        |  Used   | Queuing| AQM|
   |===============+=======+===================+=========+========+====|
   |Network Control|  CS6  | See Section 3.2   | RFC2474 |  Rate  | Yes|
   |---------------+-------+-------------------+---------+--------+----|
   |  Telephony    |   EF  |Police using sr+bs | RFC3246 |Priority| No |
   |---------------+-------+-------------------+---------+--------+----|
   |  Signaling    |  CS5  |Police using sr+bs | RFC2474 |  Rate  | No |
   |---------------+-------+-------------------+---------+--------+----|
   |  Multimedia   | AF41  |  Using two-rate,  |         |        | Yes|
   | Conferencing  | AF42  | three-color marker| RFC2597 |  Rate  | per|
   |               | AF43  | (such as RFC 2698)|         |        |DSCP|
   |---------------+-------+-------------------+---------+--------+----|
   |  Multimedia   | AF31  |  Using two-rate,  |         |        | Yes|
   |   Streaming   | AF32  | three-color marker| RFC2597 |  Rate  | per|
   |               | AF33  | (such as RFC 2698)|         |        |DSCP|
   |---------------+-------+-------------------+---------+--------+----|
   |      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|
   |---------------+-------+-------------------+---------+--------+----|
   | Low-Priority  |  CS1  | Not applicable    | RFC3662 |  Rate  | Yes|
   |     Data      |       |                   |         |        |    |
   |---------------+-------+-------------------+---------+--------+----|
   |   Standard    |DF(CS0)| Not applicable    | RFC2474 |  Rate  | Yes|
   |               | +other|                   |         |        |    |
    -------------------------------------------------------------------

           Figure 7. Enterprise Network Configuration Example

   Notes for Figure 7:

   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  Any packet that is marked with DSCP value that is not represented
      by the supported service classes SHOULD be forwarded using the
      Standard service class.

Top      Up      ToC       Page 27 
3.  Network Control Traffic

   Network control traffic is defined as packet flows that are essential
   for stable operation of the administered network as well as for
   information that may be 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 that are used for
   operating, administering, controlling, or managing the 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, potentially for future routing or control
   protocols.  Network administrators MAY use a Local/Experimental DSCP;
   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 CS7 packets at ingress to DiffServ network domain.
   o  CS7 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.

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 nodes within the administrative
   domain as well as across a peering point between different
   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 Class Selector (CS) PHB, defined in [RFC2474].  This service
   class SHOULD 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 SHOULD be such that the probability of packet drop
   under peak load is very low in this service class.  The Network

Top      Up      ToC       Page 28 
   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 SHOULD
   use the Network Control service class:

   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 SHOULD NOT use the Network
   Control service class:

   o  User traffic.

   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).
   o  User traffic is not allowed to use this service class.  By user
      traffic, we mean packet flows that originate from user-controlled
      end points that are connected to the network.

   The RECOMMENDED 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 SHOULD 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) SHOULD be dropped or remarked at ingress to the
      DiffServ network.
   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.

Top      Up      ToC       Page 29 
   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 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).

Top      Up      ToC       Page 30 
   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.



(page 30 continued on part 3)

Next RFC Part