QoS – DSCP Classification Guidelines (RFC 4594)
April 19th, 2010
RFC 4594 describes some example and provides guidelines for DiffServ service classification which may be used as guidelines or as a basis for a QoS Classification Strategy:
RFC 4594 Guidelines for DiffServ Service Classes August 2006
-------------------------------------------------------------------
|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
RFC 4594 Guidelines for DiffServ Service Classes August 2006
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.
RFC 4594 Guidelines for DiffServ Service Classes August 2006
------------------------------------------------------------------
| 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.
RFC 4594 Guidelines for DiffServ Service Classes August 2006
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
RFC 4594 Guidelines for DiffServ Service Classes August 2006
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:
RFC 4594 Guidelines for DiffServ Service Classes August 2006
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
RFC 4594 Guidelines for DiffServ Service Classes August 2006
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.
RFC 4594 Guidelines for DiffServ Service Classes August 2006
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.
RFC 4594 Guidelines for DiffServ Service Classes August 2006
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.
RFC 4594 Guidelines for DiffServ Service Classes August 2006
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.
