TSVWG J. Babiarz
Internet-Draft K. Chan
Expires: January 5, 2005 Nortel Networks
F. Baker
Cisco Systems
July 7, 2004
Configuration Guidelines for DiffServ Service Classes
draft-baker-diffserv-basic-classes-03
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 5, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This paper summarizes the recommended correlation between service
classes and their usage, with references to their corresponding
recommended Differentiated Service Code Points (DSCP), traffic
conditioners, Per-Hop Behaviors (PHB) and Active Queue Management
(AQM) mechanism. There is no intrinsic requirement that particular
DSCPs, traffic conditioner PHBs and AQM be used for a certain service
class, but as a policy it is useful that they be applied consistently
across the network.
Babiarz, et al. Expires January 5, 2005 [Page 1]
Internet-Draft Document July 2004
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Expected use in the Network . . . . . . . . . . . . . . . 4
1.2 Service Class Definition . . . . . . . . . . . . . . . . . 5
1.3 Key Differentiated Services Concepts . . . . . . . . . . . 5
1.3.1 Queuing . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1.1 Priority Queuing . . . . . . . . . . . . . . . . . 5
1.3.1.2 Rate Queuing . . . . . . . . . . . . . . . . . . . 6
1.3.2 Active Queue Management . . . . . . . . . . . . . . . 6
1.3.3 Traffic Conditioning . . . . . . . . . . . . . . . . . 7
1.3.4 Differentiated Services Code Point (DSCP) . . . . . . 8
1.3.5 Per-Hop Behavior (PHB) . . . . . . . . . . . . . . . . 8
1.4 Key Service Concepts . . . . . . . . . . . . . . . . . . . 8
1.4.1 Default Forwarding (DF) . . . . . . . . . . . . . . . 8
1.4.2 Assured Forwarding (AF) . . . . . . . . . . . . . . . 9
1.4.3 Expedited Forwarding (EF) . . . . . . . . . . . . . . 9
1.4.4 Class Selector (CS) . . . . . . . . . . . . . . . . . 9
1.4.5 Admission Control . . . . . . . . . . . . . . . . . . 10
2. Service Differentiation . . . . . . . . . . . . . . . . . . . 11
2.1 Service Classes . . . . . . . . . . . . . . . . . . . . . 11
2.2 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 16
3. Network Control Traffic . . . . . . . . . . . . . . . . . . . 19
3.1 Administrative Service Class . . . . . . . . . . . . . . . 19
3.2 Network Control Service Class . . . . . . . . . . . . . . 21
3.3 OAM Service Class . . . . . . . . . . . . . . . . . . . . 22
4. User Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 Telephony Service Class . . . . . . . . . . . . . . . . . 24
4.2 Signaling Service Class . . . . . . . . . . . . . . . . . 26
4.3 Multimedia Conferencing Service Class . . . . . . . . . . 27
4.4 Real-time Interactive Service Class . . . . . . . . . . . 30
4.5 Multimedia Streaming Service Class . . . . . . . . . . . . 32
4.6 Broadcast Video Service Class . . . . . . . . . . . . . . 34
4.7 Low Latency Data Service Class . . . . . . . . . . . . . . 35
4.8 High Throughput Data Service Class . . . . . . . . . . . . 37
4.9 Standard Service Class . . . . . . . . . . . . . . . . . . 39
4.10 Low Priority Data . . . . . . . . . . . . . . . . . . . . 40
5. Mapping Applications to Service Classes . . . . . . . . . . . 41
6. Security Considerations . . . . . . . . . . . . . . . . . . . 42
7. Summary of Changes from Previous Draft . . . . . . . . . . . . 43
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 44
9.2 Informative References . . . . . . . . . . . . . . . . . . . 45
Babiarz, et al. Expires January 5, 2005 [Page 2]
Internet-Draft Document July 2004
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . 47
Babiarz, et al. Expires January 5, 2005 [Page 3]
Internet-Draft Document July 2004
1. Introduction
This paper summarizes the recommended correlation between service
classes and their usage, with references to their corresponding
recommended Differentiated Service Code Points (DSCP), traffic
conditioners, Per-Hop Behaviors (PHB) and Active Queue Management
(AQM) mechanisms. There is no intrinsic requirement that particular
DSCPs, traffic conditioner PHBs and AQM be used for a certain service
class, but as a policy it is useful that they be applied consistently
across the network.
Service classes are defined based on the different traffic
characteristics and required performance of the applications/
services. This approach allows us to map current and future
applications/services of similar traffic characteristics and
performance requirements into the same service class. Since the
applications'/services' characteristics and required performance are
end to end, the service class notion needs to be preserved end to
end. With this approach, a limited set of service classes is
required. For completeness, we have defined thirteen different
service classes, three for network operation/administration and ten
for user/subscriber applications/services. However, we expect that
network administrators will implement a subset of these classes
relevant to their customers and their service offerings. Network
Administrators may also find it of value to add locally defined
service classes, although these will not necessarily enjoy end to end
properties of the same type.
Section 1, provides an introduction and overview of technologies that
are used for service differentiation in IP networks. Section 2, is
an overview of how service classes are constructed to provide service
differentiation with examples of deployment scenarios. Section 3,
provides configuration guidelines of service classes that are used
for stable operation and administration of the network. Section 4,
provides configuration guidelines of service classes that are used
for differentiation of user/subscriber traffic. Section 5, provides
additional guidance on mapping different applications/protocol to
service classes. Section 6, address security considerations.
1.1 Expected use in the Network
In the Internet today, corporate LANs and ISP WANs are generally not
heavily utilized - they are commonly 10% utilized at most. For this
reason, congestion, loss, and variation in delay within corporate
LANs and ISP backbones is virtually unknown. This clashes with user
perceptions, for three very good reasons.
o The industry moves through cycles of bandwidth boom and bandwidth
bust, depending on prevailing market conditions and the periodic
Babiarz, et al. Expires January 5, 2005 [Page 4]
Internet-Draft Document July 2004
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 are over
subscribe, 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 consistent marking,
conditioning and packet treatment strategy so that it can be
configured and put into service on any link which itself is
congested.
1.2 Service Class Definition
A "service class" represents a set of traffic that requires specific
delay, loss and jitter characteristics from the network for which a
consistent and defined per-hop behavior (PHB) [RFC2475] applies.
Conceptually, a service class pertains to applications with similar
characteristics and performance requirements, such as a "High
Throughput Data" service class for applications like the web and
electronic mail, or a "Telephony" service class for real-time traffic
such as voice and other telephony services. Such service class may
be defined locally in a Differentiated Services domain, or across
multiple DS domains, including possibly extending end to end.
1.3 Key Differentiated Services Concepts
The reader must be familiar with the principles of the Differentiated
Services Architecture [RFC2475]. However, we recapitulate key
concepts here to save searching.
1.3.1 Queuing
A queue is a data structure that holds packets that are awaiting
transmission. The packets may be delayed while in the queue,
possibly due to lack of bandwidth, or because it is low in priority.
There are a number of ways to implement a queue, a simple model of a
queuing system, however, is a set of data structures for packet data,
which we will call queues and a mechanism for selecting the next
packet from among them, which we call a scheduler.
1.3.1.1 Priority Queuing
A priority queuing system is a combination of a set of queues and a
scheduler that empties them in priority sequence. When asked for a
packet, the scheduler inspects the highest priority queue, and if
Babiarz, et al. Expires January 5, 2005 [Page 5]
Internet-Draft Document July 2004
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, but which 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 - it 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 which has that requirement.
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.3.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 WFQ or WRR, the delay that a
packet in any given queue will experience is dependant 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 to be not 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.3.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, 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
Babiarz, et al. Expires January 5, 2005 [Page 6]
Internet-Draft Document July 2004
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 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.
1.3.3 Traffic Conditioning
Additionally, 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, such 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 a burst size, as in Section 1.5.3
of DiffServModel [RFC3290]. With multiple rate and burst size
measurements added to the basic single rate single burst size token
bucket meter to achieve multiple levels of conformance used by
Assured Forwarding PHB [RFC2597]. Multiple rates and burst sizes can
be realized using multiple levels of token buckets or more complex
token buckets, these are implementation details. Some traffic
conditioners that may be used in deployment of differentiated
services are:
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 buckets meters
configured to provide behavior as outlined in Two Rate Three Color
Marker (trTCM) [RFC2698] or the 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.
Babiarz, et al. Expires January 5, 2005 [Page 7]
Internet-Draft Document July 2004
1.3.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.
Half of these values are earmarked for standardized services, and the
other half of them are available for local definition.
1.3.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 specify what PHB
should be applied to them.
1.4 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 behavior for elastic traffic, the
Assured Forwarding behavior, and the Expedited Forwarding behavior
for real-time (inelastic) traffic.
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.4.1 Default Forwarding (DF)
The basic forwarding behavior applied to any class of traffic are
those described in [RFC2475] and [RFC2309]. Best Effort service may
be summarized as "I will accept your packets", with no further
guarantees. 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 which 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 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
Babiarz, et al. Expires January 5, 2005 [Page 8]
Internet-Draft Document July 2004
management to protect the network from it and to limit delays.
1.4.2 Assured Forwarding (AF)
The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled
on Frame Relay's DE flag or ATM's CLP capability, and is intended for
networks that offer average-rate 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 to occasionally use more capacity than their contract
stipulates, perhaps up to some bound. However, if traffic must be
lost or marked to manage the queue, this excess traffic will be
marked or lost first.
1.4.3 Expedited Forwarding (EF)
Expedited Forwarding PHB [RFC3246] behavior was originally proposed
as a way to implement a virtual wire, and can be used in such a
manner. It is 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 must police traffic at various
points to ensure that the design of a queue is not over-run, and then
the traffic must 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.
1.4.4 Class Selector (CS)
Class Selector provides support for historical codepoint definitions
Babiarz, et al. Expires January 5, 2005 [Page 9]
Internet-Draft Document July 2004
and PHB requirement. The Class Selector DS field provides a limited
backward compatibility with legacy (pre DiffServ) 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 we wish to permit
their continued use in DS-compliant networks. In addition, there are
some codepoints that correspond to historical use of the IP
Precedence field and we reserve these codepoints to 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 TOS bits of the IPv4 TOS octet, as defined in [RFC0791]and
[RFC1349].
A DS-compliant network can be deployed with a set of one or more
Class Selector compliant PHB groups. As well, network administrator
may configure the network nodes to map codepoints to PHBs
irrespective of bits 3-5 of the DSCP field to yield a network that is
compatible with historical IP Precedence use. Thus, for example,
codepoint '011000' would map to the same PHB as codepoint '011010'.
1.4.5 Admission Control
Admission control including refusal when policy thresholds are
crossed, can assure high quality communication by ensuring the
availability of bandwidth to carry a load. Inelastic real-time flows
like VoIP (telephony) or video conferencing services can benefit from
use of admission control mechanism, as generally the telephony
service is configured with over subscription, meaning that some
user(s) may not be able to make a call during peak periods.
For VoIP (telephony) service, a common approach is to use signaling
protocols such as SIP, H.323, H.248, MEGACO, RSVP, etc. 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. Since RTP voice does not react to loss or
delay in any substantive way, the network must 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.
Another approach that may be used in small and bandwidth constrained
networks for limited number of flows is RSVP [RFC2205][RFC2996].
However, there is concern with the scalability of this solution in
large networks where aggregation of reservations[RFC3175] is
considered to be required.
Babiarz, et al. Expires January 5, 2005 [Page 10]
Internet-Draft Document July 2004
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 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 three service classes: Administrative for flows that are
critical for stable operation of the network, requiring lower delay
or higher probability of being serviced, Network Control for normal
network control flows and OAM 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) in summary:
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 client-server
(traditional telephony) and peer-to-peer signaling and control
functions using protocols such as SIP, H.323, H.248, MGCP, etc.
o Multimedia Conferencing service class is best suited for
applications that require very low delay, variable rate and have
the ability to change encoding rate (elastic), such as H.323/V2
video conferencing service.
o Real-time Interactive service class is intended for interactive
variable rate inelastic applications that require low jitter, loss
and very low delay, such as interactive gaming applications that
use RTP/UDP streams for game control commands, video conferencing
applications that do not have the ability to change encoding rates
or mark packets with different importance indications, etc.
Babiarz, et al. Expires January 5, 2005 [Page 11]
Internet-Draft Document July 2004
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, web cast, etc.
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.
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, EPR application, etc.
o High Throughput Data service class is best suited for store and
forward applications such as FTP, billing record transfer, etc.
o Standard service class is for traffic that has not been identified
as requiring differentiated treatment and is normally referred as
best effort.
o Low Priority Data service class is intended for packet flows where
bandwidth assurance is not required.
We provide guidelines for network administrator 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.
Additionally, network administrators may choose to define and deploy
in their network other service classes.
Figure 1 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 Recommendation Y.1541 and Y.1540. There is also
new work currently underway in ITU-T that applies to the service
classes defined in this document.
-------------------------------------------------------------------
|Service Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+==============================+======+======+======|
| Administrative| Small packet size, one packet| Very | Very | Yes |
| | at a time | Low | Low | |
|---------------+------------------------------+------+------+------|
| Network |Variable size packets, mostly | | | |
| Control |inelastic short messages, but | Low | Low | Yes |
| | traffic can also burst (BGP) | | | |
Babiarz, et al. Expires January 5, 2005 [Page 12]
Internet-Draft Document July 2004
|---------------+------------------------------+------+------+------|
| | 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 |
| | reacts to loss |Medium| | |
|---------------+------------------------------+------+------+------|
| Real-time | RTP/UDP streams, inelastic, | Low | Very | Low |
| Interactive | mostly variable rate | | Low | |
|---------------+------------------------------+------+------+------|
| Multimedia |Variable size packets, elastic|Low - |Medium| Yes |
| Streaming | with variable rates |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, elastic| Low |Medium| Yes |
| | & inelastic short lived 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 1: Service Class Characteristics
Note: A "Yes" in the jitter-tolerant column implies that data is
buffered in the endpoint, and 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; while
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
Babiarz, et al. Expires January 5, 2005 [Page 13]
Internet-Draft Document July 2004
order to meet user, application or network expectations. Section 3
in this document 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 it should be noted 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 2 defines the RECOMMENDED
relationship between service classes and DS codepoint(s) assignment
with application examples. It is RECOMMENDED that this relationship
be preserved end to end.
------------------------------------------------------------------
| Service | DSCP | DSCP | Application |
| Class name | name | value | Examples |
|===============+=========+=============+==========================|
|Administrative | CS7 | 111000 | Heartbeats |
|---------------+---------+-------------+--------------------------|
|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 (elastic) |
|---------------+---------+-------------+--------------------------|
| 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 | Non-critical OAM&P |
|---------------+---------+-------------+--------------------------|
|High Throughput|AF11,AF12|001010,001100| Store and forward |
| Data | AF13 | 001110 | applications |
|---------------+---------+-------------+--------------------------|
Babiarz, et al. Expires January 5, 2005 [Page 14]
Internet-Draft Document July 2004
| Standard | DF,(CS0)| 000000 | Undifferentiated |
| | | | applications |
|---------------+---------+-------------+--------------------------|
| Low Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
Figure 2: DSCP to Service Class Mapping
Note for Figure 2:
o 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 choose the service
classes that they will support based on their need, starting off with
three or four service classes for user traffic and add others as the
need arises.
Figure 3 provides a summary of DiffServ QoS mechanisms that SHOULD be
used for the defined service classes that are further detailed in
Section 3 and Section 4 of this document. Based on what
applications/services that 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 | | |
|===============+======+===================+=========+========+====|
|Administrative | CS7 | See Section 3.1 | RFC2474 |Priority| No |
|---------------+------+-------------------+---------+--------+----|
|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 | | | |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 | | | |DSCP|
|---------------+------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
Babiarz, et al. Expires January 5, 2005 [Page 15]
Internet-Draft Document July 2004
|---------------+------+-------------------+---------+--------+----|
| Low | AF21 | Using single rate | | | Yes|
| Latency | AF22 |three color marker | RFC2597 | Rate | per|
| Data | AF23 | | | |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 | | | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| Standard | DF | Not applicable | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| Low Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------
Figure 3: Summary of QoS Mechanisms used for each Service Class
Notes for Figure 3:
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 Administrative service class MAY be implemented using Rate
queuing method as long as sufficient amount of bandwidth is
guaranteed and latency of scheduler is sufficiently low to meet
the requirement.
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 High
Throughput Data or Low Priority Data service class can be
supported. The DSCP value(s) in the unsupported service class
MUST be changed to 000xxx on ingress and MUST be changed back to
original value(s) on egress of the network segment that uses
precedence marking.
2.2 Deployment Scenarios
It is expected that network administrators will choose the service
classes that they will support based on their need, starting off with
Babiarz, et al. Expires January 5, 2005 [Page 16]
Internet-Draft Document July 2004
three or four service classes for user traffic and adding others as
the need arises. In this section we provide three examples of a
subset of service classes that could be deployed with the first
example being detailed.
Example 1:
A network administrator determined that they need to provide
different performance levels (quality of service) in their network
for the services that they will be offering to their customers. They
need to enable their network to provide:
o Reliable VoIP (telephony) service, equivalent to PSTN
o A low delay assured bandwidth data service
o As well, support current Internet services
For this example, the network administrator's needs are addressed
with the deployment of the following service classes:
o Administrative service class for heartbeats between routers to
insure timely detection and path restoration under link or node
failure
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 their network for
support of current Internet services
o Telephony service class for VoIP (telephony) bearer traffic
o Signaling service class for Telephony signaling to control the
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 4, provides a popular industry view of the service
differentiation supported in core network.
Babiarz, et al. Expires January 5, 2005 [Page 17]
Internet-Draft Document July 2004
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
| Administrative| CS7 | See Section 3.2 | RFC2474 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
|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 |
|---------------+-------+-------------------+---------+--------+----|
| Low | AF21 | Using single rate | | |Yes |
| Latency | AF22 |three color marker | RFC2597 | Rate |Per |
| Data | AF23 | | | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | |
-------------------------------------------------------------------
Figure 4: Popular Core Network Configuration
Notes for Figure 4:
o The Administrative service class MAY be implemented using Rate
queuing method as long as sufficient amount of bandwidth is
guaranteed and latency of scheduler is sufficiently low to meet
the requirement.
o "sr+bs" represents a policing mechanism that provides single rate
with burst size control.
o Any packet that is marked with DSCP value that is not represented
by the supported service classes, MUST be forwarded using the
Standard service class.
Example 2:
A network administrator determines that they need to support three
service classes for control and administration of their network plus
five levels of service differentiation for user traffic using the
following service classes:
o Administrative
o Network Control
o OAM
o Standard
o Telephony
o Signaling
Babiarz, et al. Expires January 5, 2005 [Page 18]
Internet-Draft Document July 2004
o Low Latency Data
o Real-time Interactive
Example 3:
An enterprise network administrator determines that they need to
provide eight levels of service differentiation for user traffic plus
two for running of their network. They would configure their network
to support the following service classes:
o Network Control
o OAM
o Telephony
o Multimedia Conferencing
o Multimedia Streaming
o Low Latency Data
o Signaling
o High Throughput Data
o Standard
o Low Priority Data
3. Network Control Traffic
Network control traffic is defined as packet flows that are essential
for stable operation of the administered network as well 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 three service
classes, i.e. Administrative, Network Control and OAM.
3.1 Administrative Service Class
The Administrative service class is intended for control traffic that
is within a single administrative network domain. If such traffic
does not get through, the administered network domain may not
function properly. Example of such type of traffic is heartbeats
between core network switches/routers. Such heartbeats are used to
determine if the next hop is reachable. If no heartbeat is received
within a specified time interval, then the sending router assumes
that the particular link or next hop node is unreachable on a
particular interface and subsequently reroutes the traffic to a
backup interface that can reach the next hop node. This reroute is
typically done in a time interval much shorter than the time it would
take for the routing protocol to determine that the next hop node is
unreachable.
Babiarz, et al. Expires January 5, 2005 [Page 19]
Internet-Draft Document July 2004
The Administrative service class, if supported MUST be configured
using the DiffServ Class Selector (CS) PHB defined in [RFC2474] and
MUST be configured with sufficient forwarding resources so that all
packets are forwarded quickly. The Administrative service class
SHOULD be configured to use a Priority Queuing system such as defined
in Section 1.3.1.1 of this document. In network configuration where
inter node packets forwarding delays for CS7 marked heartbeats is not
stringent, Rate Queuing system such as defined in Section 1.3.1.2 MAY
be used, as long as sufficient bandwidth is guaranteed for network
heartbeats.
Examples of protocols and application that SHOULD use the
Administrative service class:
o Protocol(s) that are transmitted between nodes within the
administered network for detecting link and nodal failures i.e.,
IP-layer keep-alive
The following protocols and application MUST NOT use the
Administrative service class:
o User Traffic
o Inter-network domain (across peering points) control traffic
Traffic characteristics of packet flows in the Administrative service
class:
o Mostly messages sent between routers and network servers
o Typically small packet sizes, one packet at a time
o Packets requiring immediate forwarding
o User traffic is not allowed to use this service class
RECOMMENDED DSCP marking is CS7 (Class Selector 7)
RECOMMENDED Network Edge Conditioning:
o Drop or remark CS7 marked packets at ingress to DiffServ network
domain
o Packets from users are not permitted access to the Administrative
service class
o Depending on policy within the administered network, CS7 marked
packets MAY be dropped or remarked to CS6 at egress of DiffServ
network or across peering points
Note: CS7 marked packets SHOULD NOT be sent across peering points.
Exchange of control information across peering points SHOULD be done
using CS6 marked packets, using Network Control service class.
The fundamental service offered to the Administrative service class
is enhanced best effort service with guaranteed bandwidth. Since
this service class is used to forward inelastic flows, the service
SHOULD be engineered so the Active Queue Management (AQM) [RFC2309]
is not applied to CS7 marked packets.
Babiarz, et al. Expires January 5, 2005 [Page 20]
Internet-Draft Document July 2004
3.2 Network Control Service Class
The Network Control service class is used for transmitting packets
between network devices (routers, servers, etc.) that require control
information to be exchanged between different administrative domains
(across a peering point) and for non-critical network control
information exchange within one administrative domain. Traffic
transmitted in this service class is very important as it keeps the
network operational and needs to be forwarded in a timely manner.
The Network Control service class MUST be configured using the
DiffServ Class Selector (CS) 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 SHOULD be such that the probability of packet drop
under peak load is very low in this service class. The Network
Control service class SHOULD be configured to use a Rate Queuing
system such as defined in Section 1.3.1.2 of this document.
Examples of protocols and application that SHOULD use the Network
Control service class:
o Routing packet flows: OSPF, BGP, ISIS, RIP
o Signaling flows between high capacity telephony call servers or
soft switches. Such high capacity devices may control thousands
of telephony (VoIP) calls
o Network services, DNS, DHCP, BootP, high priority OAM (SNMP) like
alarms, etc.
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
o In 3GPP wireless solutions, UMTS Signaling/control information
between wireless nodes
The following protocols and applications MUST NOT use the Network
Control service class:
o User traffic
Traffic characteristics of packet flows in the Network Control
service class:
o Mostly messages sent between routers and network servers
o Ranging from 50 to 1,500 byte packet sizes, normally one packet at
a time but traffic can also burst (BGP)
o User traffic is not allowed to use this service class
RECOMMENDED DSCP marking is CS6 (Class Selector 6)
Babiarz, et al. Expires January 5, 2005 [Page 21]
Internet-Draft Document July 2004
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 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 the Active Queue
Management (AQM) [RFC2309] is applied to CS6 marked packets.
Some network administrators MAY choose to configure their network so
that both Administrative (CS7) and Network Control (CS6) packet flows
are forward out of the same queue. If that is the case, it is
RECOMMENDED that networks nodes use a Rate Queuing system and the
queue is configured to provide high bandwidth assurance for the sum
of CS7 and CS6 marked packets. Further, AQM SHOULD only be applied
to CS6 mark packets. AQM MUST NOT be applied to CS7 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,
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 Operation and Management (OAM) service class is RECOMMENDED for
non-critical OAM&P (Operation and Management and Provisioning) using
protocols such as SNMP, TFTP, FTP, Telnet, COPS, etc. 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 MUST 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
Babiarz, et al. Expires January 5, 2005 [Page 22]
Internet-Draft Document July 2004
they get forwarded. The OAM service class SHOULD be configured to
use a Rate Queuing system such as defined in Section 1.3.1.2 of this
document.
The following applications SHOULD use the OAM service class:
o For provisioning and configuration of network elements
o For performance monitoring of network elements
o For any non-critical OAM&P (Operation and Management and
Provisioning) function
Traffic characteristics:
o Variable size packets (50 to 1500 bytes in size)
o Intermittent traffic flows
o Traffic may burst at times
o Both elastic and inelastic short lived flows
o Traffic not sensitive to delays
RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS2 (Class
Selector 2)
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 MUST
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) MUST 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, than CS2 marked packet
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.
Babiarz, et al. Expires January 5, 2005 [Page 23]
Internet-Draft Document July 2004
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 Traffic
User traffic is defined as packet flows between different users or
subscribers. It is the traffic that is sent to or from end-terminals
and that support very wide variety of applications and services.
User traffic can be differentiated in many different ways, therefore
we investigated several different approaches to classify user
traffic. We looked at differentiating user traffic as real-time
versus non real-time, elastic versus inelastic, sensitive versus
insensitive to loss as well traffic categorization as interactive,
responsive, timely and non-critical as defined in ITU-T
Recommendation G.1010. At the end, we added up using all of the
above for service differentiation, mapping of applications that have
the matching traffic characteristics that fit the traffic profile and
performance requirements of the defined service classes.
Network administrators can categorize their applications based on the
type of behavior that they require and MAY choose to support all or
subset of the defined service classes. Figure 2 provides some common
applications and the forwarding service class that best supports them
based on their performance requirements.
4.1 Telephony Service Class
The Telephony service class is RECOMMENDED for applications that
require real-time, very low delay, very low jitter and very low
packet loss for relatively constant-rate traffic sources (inelastic
traffic sources). This service class MUST be used for IP telephony
service.
The fundamental service offered to traffic in the Telephony service
class is minimum jitter, delay and packet loss service up to a
specified upper bound. Operation is in some respect 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 EF PHB has a similar guarantee.
Typical configurations negotiate the setup of telephone calls over IP
Babiarz, et al. Expires January 5, 2005 [Page 24]
Internet-Draft Document July 2004
using protocols such as H.248, MEGACO, H.323 or SIP. When a user has
been authorized to send telephony traffic, the call admission
procedure should have verified that the newly admitted flow will be
within the capacity of the Telephony service class forwarding
capability in the network. For VoIP (telephony) service, call
admission control is usually performed by a telephony call server/
gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) on
access points to the network. The bandwidth in the core network and
the number of simultaneous VoIP sessions that can be supported needs
to be engineered and controlled so that there is no congestion for
this service. Since RTP telephony flows do not react to loss or
substantial delay in any substantive way, the Telephony service class
SHOULD forward packet as soon as possible.
The Telephony service class MUST use Expedited Forwarding (EF) PHB as
defined in [RFC3246] and SHOULD be configured to receive guaranteed
forwarding resources so that all packets are forwarded quickly. The
Telephony service class SHOULD be configured to use a Priority
Queuing system such as defined in Section 1.3.1.1 of this document.
The following application SHOULD use the Telephony service class:
o VoIP (G.711, G.729 and other codecs)
o Voice-band data over IP (modem, fax)
o T.38 fax over IP
o Circuit emulation over IP, virtual wire, etc.
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Conversational Traffic Class
Traffic characteristics:
o Mostly fixed size packets for VoIP (60, 70, 120 or 200 bytes in
size)
o Packets emitted at constant time intervals
o Admission control of new flows is provided by telephony call
server, media gateway, gatekeeper, edge router, end terminal or
access node that provides flow admission control function.
Applications or IP end points SHOULD pre-mark their packets with EF
DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point MUST
perform Multifield (MF) Classification as defined in [RFC2475].
RECOMMENDED DSCP marking is EF 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.
o Conversational UMTS Traffic Class
Babiarz, et al. Expires January 5, 2005 [Page 25]
Internet-Draft Document July 2004
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].
o Packet flows from untrusted sources (end user devices) MUST be
policed at ingress to DiffServ network, e.g. using single rate
with burst size token bucket policer to ensure that the telephony
traffic stays within its negotiated bounds.
o Packet flows from trusted sources (media gateways inside
administered network) MAY not require policing.
o Policing of Telephony packet flows across peering points where SLA
is in place is OPTIONAL as telephony traffic will be controlled by
admission control mechanism between peering points.
The fundamental service offered to "Telephony" 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. Normally traffic in this service class does not respond
dynamically to packet loss. As such, Active Queue Management
[RFC2309] MUST NOT be applied to EF marked packet flows.
4.2 Signaling Service Class
The Signaling service class is RECOMMENDED for delay sensitive
client-server (traditional telephony) and peer-to-peer application
signaling. Telephony signaling includes signaling between IP phone
and soft-switch, soft-client and soft-switch, media gateway and
soft-switch as well as peer-to-peer using various protocols.
Applications using this service class requiring a relatively fast
response as there are typically several message of different size
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. To minimize the possibility of
speech-clipping and/or ring-clipping at start of call when
interfacing to the PSTN (TDM Central Office equipment), the Signaling
service class SHOULD 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. See Section 5 for
explanation of mapping different signaling methods to service
classes.
The Signaling service class MUST use the Class Selector (CS) PHB
defined in [RFC2474]. This service class SHOULD be configured to
provide a minimum bandwidth assurance for CS5 marked packets to
ensure that they get forwarded. The Signaling service class SHOULD
be configured to use a Rate Queuing system such as defined in Section
1.3.1.2 of this document.
Babiarz, et al. Expires January 5, 2005 [Page 26]
Internet-Draft Document July 2004
The following applications SHOULD use the Signaling service class:
o Peer-to-peer IP telephony signaling (e.g., using SIP, H.323)
o Peer-to-peer signaling for multimedia applications (e.g., using
SIP, H.323)
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
Traffic characteristics:
o Variable size packets (50 to 1500 bytes in size)
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 CS5 (Class
Selector 5)
Applications or IP end points SHOULD pre-mark their packets with CS5
DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point MUST
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) MUST 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 SHOULD be performed
to the Service Level Agreement (SLA).
The fundamental service offered to "Signaling" traffic is enhanced
best effort service with controlled rate and delay. The service
SHOULD be engineered so that CS5 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] MUST NOT be applied to CS5 marked packet flows.
4.3 Multimedia Conferencing Service Class
The Multimedia Conferencing service class is RECOMMENDED for
applications that require real-time and very low delay for variable
Babiarz, et al. Expires January 5, 2005 [Page 27]
Internet-Draft Document July 2004
rate elastic traffic sources. Video conferencing is such an
application. The traffic sources (applications) in this traffic
class have the capability to reduce their transmission rate based on
feedback received from the receiving end. Detection of packet loss
by the receiver is sent using the applications control stream to the
transmitter as an indication of possible congestion; the transmitter
then selects a lower transmission rate based on pre-configured
encoding rates (or transmission rates). Note, today many H.323/V2
video conferencing solutions implement fixed step bandwidth change
(usually reducing the rate), traffic resembling step-wise CBR. In
the future, it is expected that these services will generate
continuously variable rate traffic with packet marking indicating
flow importance.
Typical video conferencing configurations negotiate the setup of
multimedia session using protocols such as H.323 or SIP. When a
user/end-point has been authorized to start a multimedia session the
admission procedure should have verified that the newly admitted data
rate will be within the engineered capacity of the Multimedia
Conferencing service class. The bandwidth in the core network and
the number of simultaneous video conferencing sessions that can be
supported SHOULD be engineered to control traffic load for this
service.
The Multimedia Conferencing service class MUST use the Assured
Forwarding (AF) PHB defined in [RFC2597]. This service class SHOULD
be configured to provide a bandwidth assurance for AF41, AF42, and
AF43 marked packets to ensure that they get forwarded. The
Multimedia Conferencing service class SHOULD be configured to use a
Rate Queuing system such as defined in Section 1.3.1.2 of this
document.
The following application SHOULD use the Multimedia Conferencing
service class:
o H.323/V2 Video conferencing (interactive video)
o Video conferencing applications with rate control or traffic
content importance marking
o Application server to application server non bursty data transfer
requiring very low delay
o IP VPN service that specifies two rates and mean network delay
that is slightly longer then network propagation delay.
o Interactive, time critical and mission critical applications.
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Interactive Traffic Class with Traffic Handling Priority 1
(THP=1).
Traffic characteristics:
Babiarz, et al. Expires January 5, 2005 [Page 28]
Internet-Draft Document July 2004
o Variable size packets (50 to 1500 bytes in size)
o Higher the rate, higher is the density of large packets
o Variable packet emission time
o Variable rate
o Source is capable of reducing its transmission rate based on
detection of packet loss at the receiver
RECOMMENDED DSCP marking:
o Video conferencing packets are marked with AF4x
o VPN service may be marked with AF4x, depending on the service
characteristics
o Server to server data transfer with AF4x, depending on the service
characteristics
o UMTS Interactive THP=1 packets are marked with AF4x
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 MUST perform Multifield (MF) Classification as defined in
[RFC2475] and mark all packets as AF41. Note: In this case, the two
rate three color marker will be configured to operate in Color-Aware
mode.
RECOMMENDED DSCP marking:
o AF41 = up to specified rate "A"
o AF42 = in excess of specified rate "A" 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 sum of the mean rates
and "B" to approximate the sum of the peak rates.
RECOMMENDED DSCP marking when performed by H.323/V2 video
conferencing equipment:
o AF41 = H.323 video conferencing audio stream RTP/UDP
o AF41 = H.323 video conferencing video control RTCP/TCP
o AF41 = H.323 video conferencing video stream up to specified rate
"A"
o AF42 = H.323 video conferencing video stream in excess of
specified rate "A" but below specified rate "B"
o AF43 = H.323 video conferencing video stream 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].
Babiarz, et al. Expires January 5, 2005 [Page 29]
Internet-Draft Document July 2004
o If packets are marked by a trusted sources or previous trusted
DiffServ domain, then the two rate three color marker SHOULD be
configured to operate in Color-Aware mode.
o If the packet marking is not trusted, then the two rate three
color marker MUST be configured to operate in Color-Blind mode.
The fundamental service offered to "Multimedia Conferencing" traffic
is enhanced best effort service with controlled rate and delay. For
video conferencing service, typically a 1% packet loss detected at
the receiver triggers an encoding rate change, dropping to next lower
provisioned video encoding rate. As such, Active Queue Management
[RFC2309] SHOULD be used primarily to switch video encoding rate
under congestion, changing from high rate to lower rate i.e. 1472
kbps to 768 kbps. 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.
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
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.4 Real-time Interactive Service Class
The Real-time Interactive service class is RECOMMENDED for
applications that require low loss, jitter and very low delay for
variable rate inelastic traffic sources. Interactive gaming and
video conferencing applications that do not have the ability to
change encoding rates or mark packets with different importance
indications are such applications. The traffic sources in this
traffic class does not have the ability to reduce their transmission
rate based on feedback received from the receiving end.
Typically, applications in this service class are configured to
negotiate the setup of RTP/UDP control session. When a user/
end-point has been authorized to start a new session the admission
procedure should have verified that the newly admitted data rates
will be within the engineered capacity of the Real-time Interactive
Babiarz, et al. Expires January 5, 2005 [Page 30]
Internet-Draft Document July 2004
service class. The bandwidth in the core network and the number of
simultaneous Real-time Interactive sessions that can be supported
SHOULD to be engineered to control traffic load for this service.
The Real-time Interactive service class MUST use the Class Selector
(CS) PHB defined in [RFC2474]. This service class SHOULD be
configured to provide a high assurance for bandwidth for CS4 marked
packets to ensure that they get forwarded. The Real-time Interactive
service class SHOULD be configured to use a Rate Queuing system such
as defined in Section 1.3.1.2 of this document. Note, this service
class MAY be configured as a second EF PHB that uses relaxed
performance parameter, a rate scheduler and CS4 DSCP value.
The following application SHOULD use the Real-time Interactive
service class:
o Interactive gaming and control
o Video conferencing applications with out rate control or traffic
content importance marking
o IP VPN service that specifies single rate and mean network delay
that is slightly longer then network propagation delay
o Inelastic, interactive, time critical and mission critical
applications requiring very low delay
Traffic characteristics:
o Variable size packets (50 to 1500 bytes in size)
o Variable rate non bursty
o Application is sensitive to delay variation between flows and
sessions
o Packets lost if any are usually ignored by application
RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS4 (Class
Selector 4)
Applications or IP end points SHOULD pre-mark their packets with CS4
DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point MUST
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) MUST 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.
Babiarz, et al. Expires January 5, 2005 [Page 31]
Internet-Draft Document July 2004
o Packet flows from trusted sources (application servers inside
administered network) MAY not require policing.
o Policing of packet flows across peering points SHOULD be performed
to the Service Level Agreement (SLA).
The fundamental service offered to "Real-time Interactive" traffic is
enhanced best effort service with controlled rate and delay. The
service SHOULD be engineered so that CS4 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 CS4 marked packet flows.
4.5 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 Multimedia Conferencing service class.
Such applications include streaming audio and video, some video
(movies) on demand applications and Web casts. In general, the
Multimedia Streaming service class assumes that the traffic is
buffered at the source/destination and therefore, is less sensitive
to delay and jitter.
The Multimedia Streaming service class MUST use the Assured
Forwarding (AF) PHB defined in [RFC2597]. This service class SHOULD
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 such as defined in Section 1.3.1.2 of this document.
The following applications SHOULD use the Multimedia Streaming
service class:
o Buffered streaming audio (unicast)
o Buffered streaming video (unicast)
o Web casts
o IP VPN service that specifies two rates and is less sensitive to
delay and jitter
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Streaming Traffic Class
Traffic characteristics:
o Variable size packets (50 to 4196 bytes in size)
o Higher the rate, higher density of large packets
o Variable rate
o Elastic flows
Babiarz, et al. Expires January 5, 2005 [Page 32]
Internet-Draft Document July 2004
o Some bursting at start of flow from some applications
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 MUST perform Multifield (MF) Classification as defined in
[RFC2475] and mark all packets as AF31. Note: In this case, the two
rate three color marker will be configured to operate in Color-Aware
mode.
RECOMMENDED DSCP marking:
o AF31 = up to specified rate "A"
o AF32 = in excess of specified rate "A" 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 sum of the mean rates
and "B" to approximate the sum of the peak rates.
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 a trusted sources or previous trusted
DiffServ domain, then the two rate three color marker SHOULD be
configured to operate in Color-Aware mode.
o If the packet marking is not trusted, then the two rate three
color marker MUST be configured to operate in Color-Blind mode.
The fundamental service offered to "Multimedia Streaming" traffic is
enhanced best effort service with controlled rate and delay. 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. 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 should 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
Babiarz, et al. Expires January 5, 2005 [Page 33]
Internet-Draft Document July 2004
o max-threshold AF32 <= min-threshold AF31
o min-threshold AF31 < max-threshold AF31
o max-threshold AF31 <= memory assigned to the queue
Note: This configuration tends to drop AF33 traffic before AF32 and
AF32 before AF31. Many other AQM algorithms exist and are used; they
should be configured to achieve a similar result.
4.6 Broadcast Video Service Class
The Broadcast Video service class is RECOMMENDED for applications
that require near-real-time packet forwarding with very low packet
loss of constant and variable rate inelastic traffic sources that are
not as delay sensitive as applications using the Real-time
Interactive 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 Video
service class assumes that the destination end point has a dejitter
buffer, for video application usually a 2 - 8 video frames buffer (66
to several hundred of milliseconds) therefore, is less sensitive to
delay and jitter.
The Broadcast Video service class MUST use the Class Selector (CS)
PHB defined in [RFC2474]. This service class SHOULD be configured to
provide high assurance for bandwidth for CS3 marked packets to ensure
that they get forwarded. The Broadcast Video service class SHOULD be
configured to use Rate Queuing system such as defined in Section
1.3.1.2 of this document. Note, this service class MAY be configured
as a third EF PHB that uses relaxed performance parameter, a rate
scheduler and CS3 DSCP value.
The following applications SHOULD use the Broadcast Video service
class:
o Video surveillance and security (unicast)
o TV broadcast including HDTV (multicast)
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)
Traffic characteristics:
o Variable size packets (50 to 4196 bytes in size)
o Higher the rate, higher density of large packets
o Mixture of variable and constant rate flows
o Fixed packet emission time intervals
o Inelastic flows
RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS3 (Class
Selector 3)
Babiarz, et al. Expires January 5, 2005 [Page 34]
Internet-Draft Document July 2004
o In some cases, like for security and video surveillance
applications, it may be desirable to use a different DSCP marking.
If so, than locally user definable (EXP/LU) codepoint(s) in the
range '011xxx' MAY be used to provide unique traffic
identification. The locally user definable (EXP/LU) codepoint(s)
MAY be associated with the PHB that is used for CS3 traffic.
Further, depending on the network scenario, additional network
edge conditioning policy MAY be need for the EXP/LU codepoint(s)
used.
Applications or IP end points SHOULD pre-mark their packets with CS3
DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point MUST
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) MUST 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 SHOULD be performed
to the Service Level Agreement (SLA).
The fundamental service offered to "Broadcast Video" traffic is
enhanced best effort service with controlled rate and delay. The
service SHOULD be engineered so that CS3 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] MUST NOT be applied to CS3 marked packet flows.
4.7 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 requiring a relatively fast
responses 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
of data). This service class is configured to provide good response
for TCP [RFC1633] short lived flows that require real-time packet
Babiarz, et al. Expires January 5, 2005 [Page 35]
Internet-Draft Document July 2004
forwarding of variable rate traffic sources.
The Low Latency Data service class MUST 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 defined in Section 1.3.1.2 of this document.
The following applications SHOULD use the Low Latency Data service
class:
o Client/server applications
o SNA terminal to host transactions (SNA over IP using DLSw)
o Web based transactions (E-commerce)
o Credit card transactions
o Financial wire transfers
o ERP applications (e.g., SAP/BaaN)
o VPN service that supports CIR (Committed Information Rate) with up
to two burst sizes
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Interactive Traffic Class with Traffic Handling Priority 2
(THP=2)
Traffic characteristics:
o Variable size packets (50 to 1500 bytes in size)
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 MUST perform Multifield (MF) Classification as defined in
[RFC2475] and mark all packets as AF21. Note: In this case, the
single rate three color marker will be configured to operate in
Color-Aware mode.
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:
Babiarz, et al. Expires January 5, 2005 [Page 36]
Internet-Draft Document July 2004
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 a trusted sources or previous trusted
DiffServ domain, then the single rate three color marker SHOULD be
configured to operate in Color-Aware mode.
o If the packet marking is not trusted, then the single rate three
color marker MUST 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
packet 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. Active queue management MAY also be implemented using Explicit
Congestion Notification (ECN) [RFC3168].
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
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.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][RFC2582]
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.
Babiarz, et al. Expires January 5, 2005 [Page 37]
Internet-Draft Document July 2004
The High Throughput Data service class MUST 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 timely
manner. The High Throughput Data service class SHOULD be configured
to use a Rate Queuing system such as defined in Section 1.3.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
o Email
o VPN service that supports two rates (committed information rate
and excess or peak information rate)
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Interactive Traffic Class with Traffic Handling Priority 3
(THP=3)
Traffic characteristics:
o Variable size packets (50 to 1500 bytes in size)
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 MUST perform Multifield (MF) Classification as defined in
[RFC2475] and mark all packets as AF11. Note: In this case, the two
rate three color marker will be configured to operate in Color-Aware
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 a trusted sources or previous trusted
DiffServ domain, then the two rate three color marker SHOULD be
Babiarz, et al. Expires January 5, 2005 [Page 38]
Internet-Draft Document July 2004
configured to operate in Color-Aware mode.
o If the packet marking is not trusted, then the two rate three
color marker MUST 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
sufficient bandwidth in the network to provide assured delivery. It
can be assumed that this class will consume any available bandwidth,
and packets traversing congested links may experience higher queuing
delays and/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 packet 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. Active queue management MAY also be
implemented using Explicit Congestion Notification (ECN) [RFC3168].
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 a small
percentage of forwarding resources (at least 5%). This service class
Babiarz, et al. Expires January 5, 2005 [Page 39]
Internet-Draft Document July 2004
SHOULD be configured to use a Rate Queuing system such as defined in
Section 1.3.1.2 of this document.
The following application SHOULD use the Standard service class:
o Any undifferentiated application/packet flow transported through
the DiffServ enabled network
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Background Traffic Class
Traffic Characteristics:
o Non deterministic, mixture of everything
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 over-all 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 consistentcongestion avoidance
procedure [RFC2581][RFC2582], and which the user is willing to accept
service without guarantees. This service class is specified in
[QBSS] and [RFC3662].
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
Babiarz, et al. Expires January 5, 2005 [Page 40]
Internet-Draft Document July 2004
Traffic Characteristics:
o Non real-time and elastic
Network Edge Conditioning:
There is no requirement that conditioning of packet flows be
performed for this service class
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. Mapping Applications to Service Classes
Here we provide some examples for mapping different applications into
the defined service classes.
Mapping for Signaling:
There are many different signaling protocols, ways that signaling is
used and performance requirements from applications that are
controlled by these protocols. Therefore we have determined that the
different signaling protocols be mapped to service classes that best
meet the objectives of application they are controlling. The
following mapping is recommended:
o Peer-to-peer signaling using SIP/H.323 are marked with CS5 DSCP
and are forwarded using Signaling service class
o Client-server signaling as used in many implementation for IP
telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN or
proprietary protocols are marked with CS5 DSCP and are forwarded
using the Signaling service class
Babiarz, et al. Expires January 5, 2005 [Page 41]
Internet-Draft Document July 2004
o Signaling between call servers or soft-switches in carrier's
network using SIP, SIP-T, IP encapsulated ISUP, are marked with
CS6 DSCP and are forwarded using the Network Control service
class.
o RSVP signaling, depends on the application. If RSVP signaling is
"on-path" as used in IntServ or NSIS, than it needs to be
forwarded from the same queue (service class) as application data
that it is controlling.
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 would suggest the following guidelines for
NTP be used:
o When NTP is used for providing high accuracy timing within
administrator's (carrier's) network or to end users/clients, the
Telephony service class should be used and NTP packets be marked
with EF DSCP value.
o For applications that require "wall clock" timing accuracy, the
Standard service class should be used and packets should be marked
with DF DSCP.
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 the network to 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.
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 must
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 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.
Babiarz, et al. Expires January 5, 2005 [Page 42]
Internet-Draft Document July 2004
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, AAA services such
as described in [I-D.iab-auth-mech] are required.
7. Summary of Changes from Previous Draft
NOTE TO RFC EDITOR: Please remove this section during the publication
process.
Made corrections to typos and grammar throughout document.
Incorporated comments received from Mike Pierce.
Moved some subsections in section 1 for better flow in document.
Added document overview to section 1.
Section 2, 3, and 4 were significantly reworked to incorporate
changes that coauthors discussed at Seoul meeting. Mainly using a
single PHB or PHB group per service class.
Incorporated changes to the service classes that support video
conferencing and video streaming applications that we received from
video encoding subject area experts .
Incorporated requested change from mailing list to separate telephony
singling from the Telephony service class. Removed telephony
signaling from the Telephony server class and generated a service
class just for application signaling. Also added an OAM service
class for operations and management and provisioning. As well, made
changes to section 2 to reflect the above changes.
8. Acknowledgements
The authors acknowledge a great many inputs, most notably from Bruce
Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet,
Brian E Carpenter, Morgan Littlewood, Robert Milne, John Shuler,
Nalin Mistry, Al Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer and
Fil Dickinson. Kimberly King, Joe Zebarth and Alistair Munroe each
did a thorough proof-reading, and the document is better for their
contributions.
Babiarz, et al. Expires January 5, 2005 [Page 43]
Internet-Draft Document July 2004
9. References
9.1 Normative References
[I-D.iab-auth-mech]
Rescorla, E., "A Survey of Authentication Mechanisms",
draft-iab-auth-mech-03 (work in progress), March 2004.
[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
Services", 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., 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.
[RFC3662] Bless, R., Nichols, K. and K. Wehrle, "A Lower Effort
Babiarz, et al. Expires January 5, 2005 [Page 44]
Internet-Draft Document July 2004
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, December 2003.
9.2 Informative References
[QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2
Technical Report Proposed Service Definition, March 2001.
[RFC1633] Braden, B., Clark, D. and S. Shenker, "Integrated Services
in the Internet Architecture: an Overview", RFC 1633, June
1994.
[RFC2205] Braden, B., 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.
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to
TCP's Fast Recovery Algorithm", RFC 2582, 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.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 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.
Babiarz, et al. Expires January 5, 2005 [Page 45]
Internet-Draft Document July 2004
Authors' Addresses
Jozef Babiarz
Nortel Networks
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Canada
Phone: +1-613-763-6098
Fax: +1-613-765-7462
EMail: babiarz@nortelnetworks.com
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
US
Phone: +1-978-288-8175
Fax: +1-978-288-4690
EMail: khchan@nortelnetworks.com
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA 93117
US
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Babiarz, et al. Expires January 5, 2005 [Page 46]
Internet-Draft Document July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Babiarz, et al. Expires January 5, 2005 [Page 47]