Internet DRAFT - draft-polk-tsvwg-rfc4594-update
draft-polk-tsvwg-rfc4594-update
Network WG James Polk, ed.
Internet-Draft Cisco
Intended status: Standards Track (PS) Feb, 2013
Obsoletes: RFC 4594
Updates: RFC 5865
Expires: August 25, 2013
Standard Configuration of DiffServ Service Classes
draft-polk-tsvwg-rfc4594-update-03.txt
Abstract
This document describes service classes configured with DiffServ and
identifies how they are used and how to construct them using
Differentiated Services Code Points (DSCPs), traffic conditioners,
Per-Hop Behaviors (PHBs), and Active Queue Management (AQM)
mechanisms. There is no intrinsic requirement that particular
DSCPs, traffic conditioners, PHBs, and AQM be used for a certain
service class, but for consistent behavior under the same network
conditions, configuring networks as described here is appropriate.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 25, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Polk Expires August 25, 2013 [Page 1]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction ...................................................3
1.1. Requirements Notation .....................................
1.2. Expected Use in the Network ...............................
1.3. Service Class Definition ..................................
1.4. Key Differentiated Services Concepts ......................
1.4.1. Queuing ..............................................
1.4.1.1. Priority Queuing ............................
1.4.1.2. Rate Queuing ................................
1.4.2. Active Queue Management ..............................
1.4.3. Traffic Conditioning .................................
1.4.4. Differentiated Services Code Point (DSCP) ............
1.4.5. Per-Hop Behavior (PHB) ...............................
1.5. Key Service Concepts ......................................
1.5.1. Default Forwarding (DF) ..............................
1.5.2. Assured Forwarding (AF) ..............................
1.5.3. Expedited Forwarding (EF) ...........................1
1.5.4. Class Selector (CS) .................................1
1.5.5. Admission Control ...................................1
1.6 What Changes are Proposed Here from RFC 4594?..............1
2. Service Differentiation .......................................1
2.1. Service Classes ..........................................1
2.2. Categorization of User Oriented Service Classes ..........1
2.3. Service Class Characteristics ............................1
2.4. Service Classes vs. Treatment Aggregate (from RFC 5127)...2
2.4.1 Examples of Service Classes in Treatment Aggregates...2
3. Network Control Traffic .......................................2
3.1. Current Practice in the Internet .........................2
3.2. Network Control Service Class ............................2
3.3. OAM Service Class ........................................2
4. User Oriented Traffic .........................................3
4.1. Conversational Service Class Group .......................3
4.1.1 Audio Service Class ..................................3
4.1.2 Video Service Class ..................................3
4.1.3 Hi-Res Service Class .................................3
4.2. Realtime-Interactive Service Class ...................... 3
4.3. Multimedia Conferencing Service Class ....................3
4.4. Multimedia Streaming Service Class .......................3
4.5. Broadcast Video Service Class ............................4
4.6. Low-Latency Data Service Class ...........................4
4.7. Conversational Signaling Service Class ...................4
4.8. High-Throughput Data Service Class .......................4
4.9. Standard Service Class ...................................4
4.10. Low-Priority Data .......................................4
5. Additional Information on Service Class Usage .................4
5.1. Mapping for NTP ..........................................5
Polk Expires August 25, 2013 [Page 2]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
5.2. VPN Service Mapping ......................................5
6. Security Considerations .......................................5
7. Contributing Authors ..........................................5
8. Acknowledgements ..............................................5
9. References ....................................................5
9.1. Normative References .....................................5
9.2. Informative References ...................................5
Author's Address .................................................5
Appendix A - Changes .............................................5
1. Introduction
Differentiated Services [RFC2474][RFC2475] provides the ability to
mark/label/classify IP packets differently to distinguish how
individual packets need to be treated differently through (or
throughout) a network on a per hop basis. Local administrators are
who configure each router for which Differentiated Services Code
Points (DSCP) are to be treated differently, which are to be
ignored (i.e., no differentiated treatment), and which DSCPs are to
have their packets remarked (to different DSCPs) as they pass
through a router. Local administrators are also who assign which
applications, or traffic types, should use which DSCPs to receive
the treatment the administrators expect within their network.
What most people fail to understand is that DSCPs provide a per hop
behavior (PHB) through that router, but not the previous or next
router. In this way of understanding PHB markings, one can
understand that Differentiated Services (DiffServ) is not a Quality
of Service (QoS) mechanism, but rather a Classification of Service
(CoS) mechanism.
For instance, there are 64 possible DSCP values, i.e., using 6 bits
of the old Type of Service (TOS) byte [RFC0791]. Each can be
configured locally to have greater or less treatment relative to any
other DSCP with two exceptions*.
* Expedited Forwarding (EF) [RFC3246] DSCPs have a treatment
requirement that any packet marked within an EF class has to be
the next packet transmitted out its egress interface. If there
are more than one EF marked packet in the queue, obviously the
queue sets the order they are transmitted. Further, if there
are more than one EF DSCP, local configuration determines if
each are treated the same or differently relate to each other
EF DSCP. Currently, there are two Expedited Forwarding DSCPs:
EF (101110) [RFC3246] and VOICE-ADMIT (101100) [RFC5865].
* Class Selector 6 (CS6) [RFC2474] is for routing protocol
traffic. There are deemed important because if the network does
not transmit and receive its routing protocol traffic in a
timely manner, the network stops operating properly.
Polk Expires August 25, 2013 [Page 3]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
Not all are configured to mean anything other than best effort
forwarding by local administrators of a network. Let us say there
are 5 DSCPs configured within network A. Network A's administrator
chooses and configures which order (obeying the two exceptions noted
above) which application packets are treated differently than any
other packets within that network (A). The DSCPs are not fixed to a
linear order for relative priority on a per hop basis. Further, and
this is often the case, there might be packets with the same DSCP
arriving at multiple interfaces of a node, each egressing that node
out the same interface. At ingress to this node, everything was
fine, with no poor behavior or noticeably excessive amount of
packets with the same DSCP. However, at the egress interface, there
might not be enough capacity to satisfy the load, thus the departing
packets transmit at their maximum rate for that DSCP, but have
additional latency due to the overload within that one node. This is
called fan-in congestion (or problem). By itself, DiffServ will not
remedy this problem for the application that is intolerant to added
latency because DiffServ only functions within 1 node at a time.
An additional mechanism is needed to ensure each flow or session
receives the amount of packets at its destination that the
application requires to perform properly; a mechanism such as
IntServ, by way of RSVP [RFC2205] or NSIS [RFC4080]. With this added
capability to be session aware, something DiffServ is not, the
packets transmitted within a single session have a very good
probability of arriving in such a way the receiving application can
make full use of each. That said, signaling reservations for each
session or flow adds complexity, which creates more work for those
who maintain and administer such a network. Adding bandwidth and
using DiffServ marking is an easier pill to swallow. The deployment
of not few, but more and more audio and (particularly bandwidth
hogging) video codecs and their respective application rigidity has
caused some to conclude that throwing bandwidth at the problem is no
longer acceptable.
With this in mind, this document incorporates five of the six new
DSCPs from [ID-DSCP] identified as capacity-admitted DSCPs for most
of the service classes in this document. As explained in [ID-DSCP],
the five new capacity-admitted DSCPs are from Pool 3. [ID-DSCP] goes
further to explain that many layer 2 technologies use fewer bits for
marking and prioritization. Instead of six bits like DiffServ, they
have three bits, which yields a maximum of 8 values, which tend to
line up quite will with the TOS field values. Thus, aggregation of
DSCPs is typically accomplished by simply ignoring or reducing the
number of bits used to the most significant ones available, such as
EF is 101110, at layer 2 this is merely 101;
Broadcast is 011000, at layer 2 this is merely 011.
However, that was not a premise DiffServ was built upon, to merely
Polk Expires August 25, 2013 [Page 4]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
reduce the number of bits. In other words, within DiffServ, XXX is
not the same as XXX000 (where XXX is the same binary value in both
cases).
This document is originally built upon the RFC 4594 effort, while
updating some of the usages and expanding the scope for newer
applications that are in use today. The idea in RFC 4594 remains
true here, to define a set of service classes, each having unique
traffic characteristics, and assigning one or more DSCPs to each
service class. As much as the focus could be on the DSCP values, it
is not. The focus of this document is the unique traffic
characteristics of each service class.
There are many services classes defined in this document, not all
will be used in each network at any period of time. This consistency
packet markings we talk about is for several reasons, including in a
network that does not currently implement a certain service class
because they do not have that type of traffic in their network, or
that the network merely gives that traffic best effort service.
Having a solid guideline to know where to progress or reconfigure a
network and endpoints to, say from best effort for a particular
traffic type, is a very good thing to do more uniformly than not. A
fair amount of burden is placed at DS boundaries needing to keep up
with which markings turn into which other markings at both ingress
and egress to a network. The same holds true for application
developers choosing a default DSCP for their application, lacking a
guideline means everyone picks for themselves - and usually with a
highly inflated sense of self importance for their application or
service.
Another point to make is that there are 20+ service classes defined
within the IETF, and that is far too many for most service providers
to manage effectively. So, they have formed groups around certain
aggregation solutions of service classes. One such aggregation group
is based on RFC 5127, which defines what it calls a treatment
aggregate, which is taking RFC 4594's service classes and placing
them each into one of four treatment aggregates for service
providers to handle as a group. SG12 within the ITU-T has an
alternative that has nine aggregate groups, so there is work to be
done to harmonize aggregates of service classes. This discussion is
articulated more in section 2.4. At the end of Section 2.4 we have
introduced a series of example configurations which provide examples
of how only a few service classes - yet still most treatment
aggregates - can be configured in example networks.
Does RFC 4594 need updating? That document is an informational
guideline on how networks can or should mark certain packet flows
with differing traffic characteristics using DiffServ. There are
several reasons why this informational RFC lacks the necessary
clarity and strength to reach widespread adoption:
o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of
Polk Expires August 25, 2013 [Page 5]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
which is for aggregating many 6-bit DSCP values into a 3-bit (8
value) field used specifically by service provider (SP) networks.
o some believe both RFCs are for SPs, while others ignore RFC 5127
and use RFC 4594 as if it were standards track or BCP.
o some believe RFC 5127 is for SPs only, and want RFC 4594 to
reduce the number of DSCPs within its guidelines to recommend
using only 3 or 4 DSCPs. This seems to stem from a manageability
and operational perspective.
o some know RFC 4594 is informational and do not follow its
guidelines specifically because it is informational.
o some use DSCP values that are not defined within RFC 4594, making
mapping between different networks using similar or identical
application flows difficult.
o some believe enterprise networks should not use either RFC except
at the edge of their networks, where they directly connect to SP
networks.
o some argue that the services classes guidance per class is too
broad and are therefore not sure in which service class a
particular application is to reside.
o time has shown that video has become a dominant application on
the Internet, and many believe it now requires to be treated
uniquely in environments that want to. Video also does not always
plan nice with audio, so knowing the two use the same transport
(RTP) [RFC3550], a means of separation is in order.
Service class definitions are based on the different traffic
characteristics and required performance of the
applications/services. There are a greater number of service classes
in this document than there were when RFC 4594 [RFC4594] was
published (the RFC this document intends to obsolete). The required
performance of applications/services has also changed since the
publication of RFC 4594, specifically in the area of conversational
real time communications. As a result, this document has a greater
number of real time applications with more granular set of DSCPs due
to their different required performances. Like RFC 4594 before, this
approach allows those applications with similar traffic
characteristics and performance requirements to be placed in the
same service class.
The notion of traffic characteristics and required performance is a
per application concept, therefore the label name of each service
class remains the same on an end-to-end basis, even if we understand
that DiffServ is only a PHB and cannot guarantee anything, even
packet delivery at the intended destination node. That said,
several applications can be configured to have the same DSCP, or
Polk Expires August 25, 2013 [Page 6]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
each have different DSCPs that have the same treatment per hop
within a network.
Since RFC 4594 was first published, a new concept has been
introduced that will appear throughout this document, including DSCP
assignments -- the idea of "admitted" traffic, initially introduced
into DiffServ within RFC 5865 [RFC5865]. The VOICE-ADMIT Expedited
Forwarding class differentiates itself from the EF Expedited
Forwarding by having the packets marked be for admitted traffic.
This concept of "admitted" traffic is spread throughout the real
time traffic classes.
Thus, the document flow is as follows:
o maintain the general format of RFC 4594;
o augment the content with the concept of capacity-admission;
o incorporate more video into this document, as it has become a
dominant application in enterprises and other managed networks,
as well as on the open public Internet;
o reduce the discussion on voice and its examples;
o articulate the subtle differences learned since RFC 4594 was
published.
The goal here is to provide a standard configuration for DiffServ
DSCP assignments and expected PHBs for enterprises and other managed
networks, as well as towards the public Internet with specific
traffic characteristics per Service class/DSCP, and example
applications shown for each.
This document describes service classes configured with DiffServ and
defines how they can be used and how to construct them using
Differentiated Services Code Points (DSCPs), and recommends how to
construct them using traffic conditioners, Per-Hop Behaviors (PHBs),
and Active Queue Management (AQM) mechanisms. There is no intrinsic
requirement that particular traffic conditioners, PHBs, and AQM be
used for a certain service class, but as a policy and for
interoperability it is useful to apply them consistently.
We differentiate services and their characteristics in Section 2.
Network control traffic, as well as user oriented traffic are
discussed in Sections 3 and 4, respectively. We analyze the security
considerations in Section 6. Section 7 offers a tribute to the
authors of RFC 4594, from which this document is based. It is in its
own section, and not part of the normal acknowledgements portion of
each IETF document.
Polk Expires August 25, 2013 [Page 7]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
1.1. Requirements Notation
The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC2119]
when they appear in ALL CAPS. These words may also appear in this
document in lower case as plain English words, absent their
normative meanings.
1.2. Expected Use in the Network
In the Internet today, corporate LANs and ISP WANs are increasingly
utilized, to the point in which network congestion is affecting
performance of applications. For this reason, congestion, loss, and
variation in delay within corporate LANs and ISP backbones is
becoming known to the users collectively as "the network is slow for
this application" or just "right now" or "for today". Users do not
directly detect network congestion. They react to applications that
run slow, or to downloads that take too long in their mind(s). The
explosion of video traffic on the internet recently has cause much
of this, and is often the application the user is using when they
have this slowness.
In the past, application slowness occurred for three very good
reasons.
o the networks the user oriented traffic traverses moves through
cycles of bandwidth boom and bandwidth bust, the latter of which
become apparent with the periodic deployment of new
bandwidth-hungry applications.
o In access networks, the state is often different. This may be
because throughput rates are artificially limited or
over-subscribed, or because of access network design trade-offs.
o Other characteristics, such as database design on web servers
(that may create contention points, e.g., in filestore) and
configuration of firewalls and routers, often look externally
like a bandwidth limitation.
The intent of this document is to provide a standardized marking,
plus a conditioning and packet treatment strategy so that it can be
configured and put into service on any link that is itself
congested.
1.3. Service Class Definition
A "service class" represents a similar set of traffic
characteristics for delay, loss, and jitter as packets traverse
routers in a network. For example, "High-Throughput Data" service
class for store-and-forward applications, or a "Broadcast" service
Polk Expires August 25, 2013 [Page 8]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
class for minimally time-shifted IPTV or Internet radio broadcasts.
Such a service class may be defined locally in a Differentiated
Services (DS) domain, or across multiple DS domains, possibly
extending end to end. A goal of this document is to have most/all
networks assign the same type of traffic the same for consistency.
A service class is a naming convention which is defined as a word,
phrase or initialism/acronym representing a set of necessary traffic
characteristics of a certain type of data flow. The necessary
characteristics of these traffic flows can be realized by the use of
defined per-hop behavior that started with [RFC2474]. The actual
specification of the expected treatment of a traffic aggregate
within a domain may also be defined as a per-domain behavior (PDB)
[RFC3086].
Each domain will locally choose to
o implement one or more service classes with traffic
characteristics as defined here, or
o implement one or more service classes with similar traffic
characteristics as defined here, or
o implement one or more service classes with similar traffic
characteristics as defined here and to aggregate one or more
service classes to reduce the number of unique DSCPs within their
network, or
o implement one or more non-standard service classes with traffic
characteristics not as defined here, or
o not use DiffServ within their domain.
For example, low delay, low loss, and minimal jitter may be realized
using the EF PHB, or with an over-provisioned AF PHB. This must be
done with care as it may disrupt the end-to-end performance required
by the applications/services. If the packet sizes are similar within
an application, but different between two applications, say small
voice packets and large video packets, these two applications may
not realize optimum results if merged into the same aggregate if
there are any bottlenecks in the network. We provide for this
flexibility on a per hop or per domain basis within this document.
This document provides standardized markings for traffic with
similar characteristics, and usage expectations for PHBs for
specific service classes for their consistent implementation.
The Default Forwarding "Standard" service class is REQUIRED; all
other service classes are OPTIONAL. That said, each service class
lists traffic characteristics that are expected when using that type
of traffic. It is RECOMMENDED that applications and protocols that
fit a certain traffic characteristic use the appropriate service
Polk Expires August 25, 2013 [Page 9]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
class mark, i.e., the DSCP, for consistent behavior. It is expected
that network administrators will base their endpoint application and
router configuration choices on the level of service differentiation
they require to meet the needs of their customers (i.e., their
end-users).
1.4. Key Differentiated Services Concepts
In order to fully understand this document, a reader needs to
familiarize themselves with the principles of the Differentiated
Services Architecture [RFC2474]. We summarize some key concepts
here only to provide convenience for the reader, the referenced RFCs
providing the authoritative definitions.
1.4.1. Queuing
A queue is a data structure that holds packets that are awaiting
transmission. A router interface can only transmit one packet at a
time, however fast the interface speed is. If there is only 1 queue
at an interface, the packets are transmitted in the order they are
received into that queue - called FIFO, or "first in, first out".
Sometimes there is a lag in the time between a packets arrives in
the queue and when it is transmitted. This delay might be due to
lack of bandwidth, or if there are multiple queues on that
interface, because a packet is low in priority relative to other
packets that are awaiting to transmit. The scheduler is the system
entity that chooses which packet is next in line for transmission
when more than one packet are awaiting transmission out the same
router interface.
1.4.1.1 Priority Queuing
A priority queuing system is a combination of a set of queues and a
scheduler that empties the queues (of packets) in priority sequence.
When asked for a packet, the scheduler inspects the highest
priority queue and, if there is data present, returns a packet from
that queue. Failing that, it inspects the next highest priority
queue, and so on. A freeway onramp with a stoplight for one lane
that allows vehicles in the high-occupancy-vehicle lane to pass is
an example of a priority queuing system; the high-occupancy-vehicle
lane represents the "queue" having priority.
In a priority queuing system, a packet in the highest priority queue
will experience a readily calculated delay. This is proportional to
the amount of data remaining to be serialized when the packet
arrived plus the volume of the data already queued ahead of it in
the same queue. The technical reason for using a priority queue
relates exactly to this fact: it limits delay and variations in
delay and should be used for traffic that has that requirement.
Polk Expires August 25, 2013 [Page 10]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
A priority queue or queuing system needs to avoid starvation of
lower-priority queues. This may be achieved through a variety of
means, such as admission control, rate control, or network
engineering.
1.4.1.2. Rate Queuing
Similarly, a rate-based queuing system is a combination of a set of
queues and a scheduler that empties each at a specified rate. An
example of a rate-based queuing system is a road intersection with a
stoplight. The stoplight acts as a scheduler, giving each lane a
certain opportunity to pass traffic through the intersection.
In a rate-based queuing system, such as Weighted Fair Queuing (WFQ)
or Weighted Round Robin (WRR), the delay that a packet in any given
queue will experience depends on the parameters and occupancy of its
queue and the parameters and occupancy of the queues it is competing
with. A queue whose traffic arrival rate is much less than the rate
at which it lets traffic depart will tend to be empty, and packets
in it will experience nominal delays. A queue whose traffic arrival
rate approximates or exceeds its departure rate will tend not to be
empty, and packets in it will experience greater delay. Such a
scheduler can impose a minimum rate, a maximum rate, or both, on any
queue it touches.
1.4.2 Active Queue Management
Active Queue Management, or AQM, is a generic name for any of a
variety of procedures that use packet dropping or marking to manage
the depth of a queue. The canonical example of such a procedure is
Random Early Detection (RED), in that a queue is assigned a minimum
and maximum threshold, and the queuing algorithm maintains a moving
average of the queue depth. While the mean queue depth exceeds the
maximum threshold, all arriving traffic is dropped. While the mean
queue depth exceeds the minimum threshold but not the maximum
threshold, a randomly selected subset of arriving traffic is marked
or dropped. This marking or dropping of traffic is intended to
communicate with the sending system, causing its congestion
avoidance algorithms to kick in. As a result of this behavior, it
is reasonable to expect that TCP's cyclic behavior is desynchronized
and that the mean queue depth (and therefore delay) should normally
approximate the minimum threshold.
A variation of the algorithm is applied in Assured Forwarding PHB
[RFC2597], in that the behavior aggregate consists of traffic with
multiple DSCP marks, which are intermingled in a common queue.
Different minima and maxima are configured for the several DSCPs
separately, such that traffic that exceeds a stated rate at ingress
is more likely to be dropped or marked than traffic that is within
its contracted rate.
Polk Expires August 25, 2013 [Page 11]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
1.4.3 Traffic Conditioning
In addition, at the first router in a network that a packet crosses,
arriving traffic may be measured and dropped or marked according to
a policy, or perhaps shaped on network ingress, as in "A Rate
Adaptive Shaper for Differentiated Services" [RFC2963]. This may be
used to bias feedback loops, as is done in "Assured Forwarding PHB"
[RFC2597], or to limit the amount of traffic in a system, as is done
in "Expedited Forwarding PHB" [RFC3246]. Such measurement
procedures are collectively referred to as "traffic conditioners".
Traffic conditioners are normally built using token bucket meters,
for example with a committed rate and burst size, as in Section
1.5.3 of the DiffServ Model [RFC3290]. The Assured Forwarding PHB
[RFC2597] uses a variation on a meter with multiple rate and burst
size measurements to test and identify multiple levels of
conformance.
Multiple rates and burst sizes can be realized using multiple levels
of token buckets or more complex token buckets; these are
implementation details. The following are some traffic conditioners
that may be used in deployment of differentiated services:
o For Class Selector (CS) PHBs, a single token bucket meter to
provide a rate plus burst size control.
o For Expedited Forwarding (EF) PHB, a single token bucket meter to
provide a rate plus burst size control.
o For Assured Forwarding (AF) PHBs, usually two token bucket meters
configured to provide behavior as outlined in "Two Rate Three
Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color
Marker (srTCM)" [RFC2697]. The two-rate, three-color marker is
used to enforce two rates, whereas the single-rate, three-color
marker is used to enforce a committed rate with two burst
lengths.
1.4.4 Differentiated Services Code Point (DSCP)
The DSCP is a number in the range 0..63 that is placed into an IP
packet to mark it according to the class of traffic it belongs in.
These are divided into 3 groups, or pools, defined in RFC 2474,
arranged as follows:
o Pool-1 has 32 values designated for standards assignment (of the
form 'xxxxx0').
o Pool-2 has 16 values designated for experimental or local use
only (EXP/LU) assignment (of the form 'xxxx11').
o Pool-3 has 16 values designated for experimental or local use
(EXP/LU) assignment (of the form 'xxxx01').
Polk Expires August 25, 2013 [Page 12]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
However, pool-3 is allowed to be assigned for one of two reasons,
#1 - if the values in pool-1 are exhausted, or
#2 - if there is a justifiable reason for assigning a pool-3 DSCP
prior to pool-1's exhaustion.
1.4.5 Per-Hop Behavior (PHB)
In the end, the mechanisms described above are combined to form a
specified set of characteristics for handling different kinds of
traffic, depending on the needs of the application. This document
seeks to identify useful traffic aggregates and to specify what PHB
should be applied to them.
1.5 Key Service Concepts
While Differentiated Services is a general architecture that may be
used to implement a variety of services, three fundamental
forwarding behaviors have been defined and characterized for general
use. These are basic Default Forwarding (DF) behavior for elastic
traffic, the Assured Forwarding (AF) behavior, and the Expedited
Forwarding (EF) behavior for real-time (inelastic) traffic. The
facts that four code points are recommended for AF and that one code
point is recommended for EF are arbitrary choices, and the
architecture allows any reasonable number of AF and EF classes
simultaneously. The choice of four AF classes and one EF class in
the current document is also arbitrary, and operators MAY choose to
operate more or fewer of either.
The terms "elastic" and "real-time" are defined in [RFC1633],
Section 3.1, as a way of understanding broad-brush application
requirements. This document should be reviewed to obtain a broad
understanding of the issues in quality of service, just as [RFC2475]
should be reviewed to understand the data plane architecture used in
today's Internet.
1.5.1 Default Forwarding (DF)
The basic forwarding behaviors applied to any class of traffic are
those described in [RFC2474] and [RFC2309]. Best-effort service may
be summarized as "I will accept your packets" and is typically
configured with some bandwidth guarantee. Packets in transit may be
lost, reordered, duplicated, or delayed at random. Generally,
networks are engineered to limit this behavior, but changing traffic
loads can push any network into such a state.
Application traffic in the internet that uses default forwarding is
expected to be "elastic" in nature. By this, we mean that the
sender of traffic will adjust its transmission rate in response to
Polk Expires August 25, 2013 [Page 13]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
changes in available rate, loss, or delay.
For the basic best-effort service, a single DSCP value is provided
to identify the traffic, a queue to store it, and active queue
management to protect the network from it and to limit delays.
1.5.2 Assured Forwarding (AF)
The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled
on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss
Priority (CLP) capability. It is intended for networks that offer
average-rate Service Level Agreements (SLAs) (as FR and ATM networks
do). This is an enhanced best-effort service; traffic is expected
to be "elastic" in nature. The receiver will detect loss or
variation in delay in the network and provide feedback such that the
sender adjusts its transmission rate to approximate available
capacity.
For such behaviors, multiple DSCP values are provided (two or three,
perhaps more using local values) to identify the traffic, a common
queue to store the aggregate, and active queue management to protect
the network from it and to limit delays. Traffic is metered as it
enters the network, and traffic is variously marked depending on the
arrival rate of the aggregate. The premise is that it is normal for
users occasionally to use more capacity than their contract
stipulates, perhaps up to some bound. However, if traffic should be
marked or lost to manage the queue, this excess traffic will be
marked or lost first.
1.5.3. Expedited Forwarding (EF)
The intent of Expedited Forwarding PHB [RFC3246] is to provide a
building block for low-loss, low-delay, and low-jitter services. It
can be used to build an enhanced best-effort service: traffic
remains subject to loss due to line errors and reordering during
routing changes. However, using queuing techniques, the probability
of delay or variation in delay is minimized. For this reason, it is
generally used to carry voice and for transport of data information
that requires "wire like" behavior through the IP network. Voice is
an inelastic "real-time" application that sends packets at the rate
the codec produces them, regardless of availability of capacity. As
such, this service has the potential to disrupt or congest a network
if not controlled. It also has the potential for abuse.
To protect the network, at minimum one SHOULD police traffic at
various points to ensure that the design of a queue is not overrun,
and then the traffic SHOULD be given a low-delay queue (often using
priority, although it is asserted that a rate-based queue can do
this) to ensure that variation in delay is not an issue, to meet
application needs.
Polk Expires August 25, 2013 [Page 14]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
1.5.4 Class Selector (CS)
Class Selector, those DSCPs that end in zeros (xxx000), provide
support for historical codepoint definitions and PHB requirement.
The CS fields provide a limited backward compatibility with legacy
practice, as described in [RFC2474], Section 4. Backward
compatibility is addressed in two ways,
- First, there are per-hop behaviors that are already in widespread
use (e.g., those satisfying the IPv4 Precedence queuing
requirements specified in [RFC1812]), and
- this document will continue to permit their use in DS-compliant
networks.
In addition, there are some DSCPs that correspond to historical use
of the IP Precedence field,
- CS0 (000000) will remain 'Default Forwarding' (also known as 'Best
Effort')
- 11xxxx will remain for routing traffic
and will map to PHBs that meet the general requirements specified in
[RFC2474], Section 4.2.2.2.
No attempt is made to maintain backward compatibility with the "DTR"
or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in
[RFC0791] and [RFC1349].
A DS-compliant network can be deployed exclusively by using one or
more CS-compliant PHB groups. Thus, for example, codepoint '011000'
would map to the same PHB as codepoint '011010'.
1.5.5 Admission Control
Admission control (including refusal when policy thresholds are
crossed) can ensure high-quality communication by ensuring the
availability of bandwidth to carry a load. Inelastic real-time
flows such as Voice over Internet Protocol (VoIP) (audio) or video
conferencing services can benefit from use of an admission control
mechanism, as generally the audio or video service is configured
with over-subscription, meaning that some users may not be able to
make a call during peak periods.
For VoIP (audio) service, a common approach is to use signaling
protocols such as SIP, H.323, H.248, MEGACO, along with Resource
Reservation Protocol (RSVP) to negotiate admittance and use of
network transport capabilities. When a user has been authorized to
send voice traffic, this admission procedure has verified that data
rates will be within the capacity of the network that it will use.
Polk Expires August 25, 2013 [Page 15]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
Many RTP voice and video payloads are inelastic and cannot react to
loss or delay in any substantive way. For these payload types, the
network needs to police at ingress to ensure that the voice traffic
stays within its negotiated bounds. Having thus assured a
predictable input rate, the network may use a priority queue to
ensure nominal delay and variation in delay.
1.5.5.1 Capacity Admitted (*-Admit)
This is a newer group of traffic types that started with RFC 5865
and the Voice-Admit service type. Voice-Admit is an EF class marking
but has capacity-admission always applied to it to ensure each of
these flows are managed through a network, though not necessarily on
an end-to-end basis. This depends on how many networks each flow
transits and the load on each transited network. There are a series
of new DSCPs proposed in [ID-DSCP], each specifying unique
characteristics necessitating a separate marking from what existing
before that document.
This document will import in four new '*-Admit' DSCPs from
[ID-DSCP], 2 others that are new but not capacity-admitted, one from
RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594.
This is discussed throughout the rest of this document.
1.6 What Changes are Proposed Here from RFC 4594?
Changing an entire network DiffServ configuration has proven to be a
painful experience for both individuals and companies. It is not
done very often, and for good reason. This effort is based on
experience learned since the publication of RFC 4594 (circa 2006).
Audio, once thought to be ok grouped with video, needs to be in
separate service classes. Collaboration has taken off, mostly
because of mobility, but also because of a worldwide recession that
has limited physical travel, and relying on people to do more with
their computers. With that in mind, there has been an explosion in
application development for the individual (seems everyone has an
"app-store"). The following set of bullets has this world - that
needs a robust layer 3 - in mind.
o Scope of document is changed to tighten it up for standards track
consideration.
o This document explicitly states there is a fundamental requirement
that a particular DSCP(s) be used for each service class, each
with a recommended set of applications to be used by that service
class - at least on that individual's externally facing (public)
interface.
o Created the Conversational group of service classes to focus on
realtime, mostly bidirectional communications (unless multicast is
Polk Expires August 25, 2013 [Page 16]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
used).
o "Realtime-Interactive"
Moved to (near) realtime TCP-based apps
Why the change? TCP based transports have proven, in certain
environments, to be a bidirectional realtime transport, e.g., for
multiplayer gaming and virtual desktops applications.
o "Audio"
Same as Telephony (which is now gone), adds Voice-Admit for
capacity-admitted traffic
Why the change? RFC 5865 (Voice-Admit) needed to be added to the
Audio service class. Video needed to be separate from audio, hence
the name change from Telephony (which includes video) to just audio.
o "Video"
NEW for video and audio/video conferencing, was in
Multimedia-Conferencing service classification
Why the change? Many networks are using the AF4X for video, but
others are throwing anything "multimedia" into the same service
class (like elastic TCP flows). Video has become so dominant that it
should be what mostly goes into one service class.
o "Hi-Res"
NEW for video and audio/video conferencing
Why the change? This entirely new service class is for local policy
based higher end video (think Telepresence). Without congestion,
this service class has the same treatment as Video, but if there is
any pushback from the network, Hi-Res (note: not married to the
name) has a better PHB.
o "Multimedia-Conferencing"
Now without audio or human video
Why the change? The change is taking bidirectional human audio and
video out of this service class. This is all about non-realtime
collaboration - even in conjunction with an audio and/or video flow.
o "Broadcast"
Remains the same, added CS3-Admit for capacity-admitted
Why the change? Removing the "-Video" from the name because there
are so many more flows that are Broadcast in realtime than video.
o "Low-Latency Data"
Remains the same, adds IM & Presence traffic explicitly
Why the change? Merely explicitly stating a place for some
Polk Expires August 25, 2013 [Page 17]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
additional traffic types that otherwise could go elsewhere.
o "Conversational Signaling" (A/V-Sig)
Was 'Signaling'
Why the change? This change is merely a renaming of a service class,
and acknowledgement that some of the previous authors inaccurate
beliefs that DSCPs were linearly ordered with those values having a
higher value definitely getting better treatment than lower values.
2. Service Differentiation
There are practical limits on the level of service differentiation
that should be offered in the IP networks. We believe we have
defined a practical approach in delivering service differentiation
by defining different service classes that networks may choose to
support in order to provide the appropriate level of behaviors and
performance needed by current and future applications and services.
The defined structure for providing services allows several
applications having similar traffic characteristics and performance
requirements to be grouped into the same service class. This
approach provides a lot of flexibility in providing the appropriate
level of service differentiation for current and new, yet unknown
applications without introducing significant changes to routers or
network configurations when a new traffic type is added to the
network.
2.1 Service Classes
Traffic flowing in a network can be classified in many different
ways. We have chosen to divide it into two groupings, network
control and user/subscriber traffic. To provide service
differentiation, different service classes are defined in each
grouping. The network control traffic group can further be divided
into two service classes (see Section 3 for detailed definition of
each service class):
o "Network Control" for routing and network control function.
o "OAM" (Operations, Administration, and Management) for network
configuration and management functions.
The user/subscriber traffic group is broken down into ten service
classes to provide service differentiation for all the different
types of applications/services (see Section 4 for detailed
definition of each service class):
o Conversational service group consists of three service classes:
- Audio, which includes both 'admitted' and 'unadmitted' audio
Polk Expires August 25, 2013 [Page 18]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
service classes, is for non-one way (i.e., generally
bidirectional) audio media packets between human users of
smaller size and at a constant delivery rate.
- Hi-Res Video, which includes both 'admitted' and 'unadmitted'
Hi-Res Video service classes, is for video traffic from higher
end endpoints between human users necessitating different
treatment that from desktop or video phone endpoints. This has
a clearly business differentiation, and not a technical
differentiation - as both Hi-Res-Video and Video will be
treated similarly on the wire when no congestion occurs.
- Video, which includes both 'admitted' and 'unadmitted' video
service classes, is for video traffic from lower end endpoints
between human users necessitating different treatment that
from higher end (i.e., Telepresence) endpoints. This has a
clearly business differentiation, and not a technical
differentiation - as both Hi-Res-Video and Video will be
treated similarly on the wire when no congestion occurs.
o Conversational Signaling service class is for peer-to-peer and
client-server signaling and control functions using protocols
such as SIP, H.323, H.248, and Media Gateway Control Protocol
(MGCP). This traffic needs to not be starved on the network.
Editor's note: RFC 4594 had this DSCP marking as CS5, but with
clearly different characteristics (i.e., no
sensitivity to jitter or (unreasonable) delay), this
DSCP has been moved to a more appropriate (new)
value, defined in [ID-DSCP].
o Real-Time Interactive, which includes both 'admitted' and
'unadmitted' Realtime-Interactive service class, is for
bidirectional variable rate inelastic applications that require
low jitter and loss and very low delay, such as interactive
gaming applications that use RTP/UDP streams for game control
commands, and Virtualized Desktop applications between the user
and content source, typically in a centralized data center.
o Multimedia Conferencing, which includes both 'admitted' and
'unadmitted' multimedia conferencing service class, is for
applications that require minimal delay, but not like those of
realtime application requirements. This service class can be
bursty in nature, as well as not transmit packets for some time.
Applications such as presentation data or collaborative
application sharing will use this service class.
o Multimedia Streaming, which includes both 'admitted' and
'unadmitted' multimedia streaming service class, is for one-way
bufferable streaming media applications such as Video on Demand
(VOD) and webcasts.
Polk Expires August 25, 2013 [Page 19]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o Broadcast, which includes both 'admitted' and 'unadmitted'
broadcast service class, is for inelastic streaming media
applications that may be of constant or variable rate, requiring
low jitter and very low packet loss, such as broadcast TV and
live events, video surveillance, and security.
o Low-Latency Data service class is for data processing
applications such as client/server interactions or Instant
Messaging (IM) and Presence data.
o Conversational Signaling (A/V-Sig) service class is for all
signaling messages, whether in-band (i.e., along the data path)
or out-of-band (separate from the data path), for the purposes of
setting up, maintaining, managing and terminating bi- or
multi-directional realtime sessions.
o High-Throughput Data service class is for store and forward
applications such as FTP and billing record transfer.
o Standard service class, commonly called best effort (BE), is for
traffic that has not been identified as requiring differentiated
treatment.
o Low-Priority Data service class, which some could call the
scavenger class, is for packet flows where bandwidth assurance is
not required.
2.2 Categorization of User Oriented Service Classes
The ten defined user/subscriber service classes listed above can be
grouped into a small number of application categories. For some
application categories, it was felt that more than one service class
was needed to provide service differentiation within that category
due to the different traffic characteristic of the applications,
control function, and the required flow behavior. Figure 1 provides
a summary of service class grouping into four application categories.
Application Control Category
o The Conversational Signaling service class is intended to be used
to control applications or user endpoints. Examples of protocols
that would use this service class are SIP, XMPP or H.323 for
voice and/or video over IP services. User signaling flows have
similar performance requirements as Low-Latency Data, they
require a separate DSCP to be distinguished other traffic and
allow for a treatment that is unique.
Media-Oriented Category
Due to the vast number of new (in process of being deployed) and
already-in-use media-oriented services in IP networks, seven service
Polk Expires August 25, 2013 [Page 20]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
classes have been defined.
o Audio service class is intended for Voice-over-IP (VoIP)
services. It may also be used for other applications that meet
the defined traffic characteristics and performance requirements.
o Video service class is intended for Video over IP services. It
may also be used for other applications that meet the defined
traffic characteristics and performance requirements.
o Hi-Res service class is intended for higher end video services
that have the same traffic characteristics as the video service
class, but have a business requirement(s) to be treated
differently. One example of this is Telepresence video
applications.
o Realtime-Interactive service class is intended for inelastic
applications such as desktop virtualization applications and for
interactive gaming.
o Multimedia Conferencing service class is for everything about or
within video conferencing solutions that does not include the
voice or (human) video components. Several examples are
- the presentation data part of an IP conference (call).
- the application sharing part of an IP conference (call).
- the whiteboarding aspect of an IP conference (call).
Each of the above can be part of a lower end web-conferencing
application or part of a higher end Telepresence video
conference. Each also has the ability to reduce their
transmission rate on detection of congestion. These flows can
therefore be classified as rate adaptive and most often more
elastic than their voice and video counterparts.
o Broadcast Video service class is to be used for inelastic traffic
flows specifically with minimal buffering expected by the source
or destination, which are intended for broadcast HDTV service, as
well as for transport of live video (sports or concerts) and
audio events.
o Multimedia Streaming service class is to be used for elastic
multimedia traffic flows where buffering is expected. This is
the fundamental difference between the Broadcast and multimedia
streaming service classes. Multimedia streaming content is
typically stored before being transmitted. It is also buffered
at the receiving end before being played out. The buffering is
sufficiently large to accommodate any variation in transmission
rate that is encountered in the network. Multimedia
entertainment over IP delivery services that are being developed
Polk Expires August 25, 2013 [Page 21]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
can generate both elastic and inelastic traffic flows; therefore,
two service classes are defined to address this space,
respectively: Multimedia Streaming and Broadcast Video.
Data Category
The data category is divided into three service classes.
o Low-Latency Data for applications/services that require low delay
or latency for bursty but short-lived flows.
o High-Throughput Data for applications/services that require good
throughput for long-lived bursty flows. High Throughput and
Multimedia Steaming are close in their traffic flow
characteristics with High Throughput being a bit more bursty and
not as long-lived as Multimedia Streaming.
o Low-Priority Data for applications or services that can tolerate
short or long interruptions of packet flows. The Low-Priority
Data service class can be viewed as "don't care" to some degree.
Best-Effort Category
o All traffic that is not differentiated in the network falls into
this category and is mapped into the Standard service class. If
a packet is marked with a DSCP value that is not supported in the
network, it SHOULD be forwarded using the Standard service class.
Figure 1, below, provides a grouping of the defined user/subscriber
service classes into four categories, with indications of which ones
use an independent flow for signaling or control; type of flow
behavior (elastic, rate adaptive, or inelastic); and the last column
provides end user Class of Service (CoS) rating as defined in ITU-T
Recommendation G.1010.
-----------------------------------------------------------------
| Application | Service | Signaled | Flow | G.1010 |
| Categories | Class | | Behavior | Rating |
|-------------+---------------+----------+-----------+------------|
| Application | A/V Sig | Not | Inelastic | Responsive |
| Control | |applicable| | |
|-------------+---------------+----------+-----------+------------|
| | Realtime | Yes | Inelastic | Interactive|
| | Interactive | | | |
| |---------------+----------+-----------+------------|
| | Audio | Yes | Inelastic | Interactive|
| |---------------+----------+-----------+------------|
| | Video | Yes | Inelastic | Interactive|
| |---------------+----------+-----------+------------|
| | Hi-Res | Yes | Inelastic | Interactive|
| |---------------+----------+-----------+------------|
| Media- | Multimedia | Yes | Rate | Moderately |
Polk Expires August 25, 2013 [Page 22]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
| Oriented | Conferencing| | Adaptive | Interactive|
| |---------------+----------+-----------+------------|
| | Broadcast | Yes | Inelastic | Responsive |
| |---------------+----------+-----------+------------|
| | Multimedia | Yes | Elastic | Timely |
| | Streaming | | | |
|-------------+---------------+----------+-----------+------------|
| | Low-Latency | No | Elastic | Responsive |
| | Data | | | |
| |---------------+----------+-----------+------------|
| Data | Conversational| No |Elastic or | Timely |
| | Signaling | | Inelastic | |
| |---------------+----------+-----------+------------|
High- | No | Elastic | Timely |
| |Throughput Data| | | |
| |---------------+----------+-----------+------------|
| | Low- | No | Elastic |Non-critical|
| | Priority Data | | | |
|-------------+---------------+----------+-----------+------------|
| Best Effort | Standard | Not Specified |Non-critical|
-----------------------------------------------------------------
Figure 1. User/Subscriber Service Classes Grouping
Here is a short explanation of the end user CoS category as defined
in ITU-T Recommendation G.1010. User oriented traffic is divided
into four different categories, namely, interactive, responsive,
timely, and non-critical. An example of interactive traffic is
between two humans and is most sensitive to delay, loss, and jitter.
Another example of interactive traffic is between two servers where
very low delay and loss are needed. Responsive traffic is typically
between a human and a server but can also be between two servers.
Responsive traffic is less affected by jitter and can tolerate
longer delays than interactive traffic. Timely traffic is either
between servers or servers and humans and the delay tolerance is
significantly longer than responsive traffic. Non-critical traffic
is normally between servers/machines where delivery may be delay for
period of time.
2.3. Service Class Characteristics
This document specifies what network administrators are to expect
when configuring service classes identified by their differing
characteristics. Figure 2 identifies these service classes along
with their characteristics, as well as the tolerance to loss, delay
and jitter for each service class. Properly engineered networks to
these PHBs will achieve expected results. That said, not all of the
identified service classes are expected in each operator's network.
-------------------------------------------------------------------
Polk Expires August 25, 2013 [Page 23]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
|Service Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+==============================+======+======+======|
| Network |Variable size packets, mostly | | | |
| Control |inelastic short messages, but | Low | Low | Yes |
| |traffic can also burst (BGP) | | | |
|---------------+------------------------------+------+------+------|
| Realtime | Inelastic, mostly variable | Low | Very | Low |
| Interactive | rate | | Low | |
+---------------+------------------------------+------+------+------+
| | Fixed-size small packets, | Very | Very | Very |
| Audio | inelastic | Low | Low | Low |
| | | | | |
+---------------+------------------------------+------+------+------+
| | Fixed-size small-large | Very | Very | Very |
| Video | packets, inelastic | Low | Low | Low |
| | | | | |
+---------------+------------------------------+------+------+------+
| | Fixed-size small-large | Very | Very | Very |
| Hi-Res A/V | packets, inelastic | Low | Low | Low |
| | | | | |
+---------------+------------------------------+------+------+------+
| Multimedia | Variable size packets, | Low | Low | Low |
| Conferencing | constant transmit interval, | - | - | - |
| | rate adaptive, reacts to loss|Medium|Medium|Medium|
+---------------+------------------------------+------+------+------+
| Multimedia | Variable size packets, |Low - |Medium| High |
| Streaming | elastic with variable rate |Medium| | |
+---------------+------------------------------+------+------+------+
| Broadcast | Constant and variable rate, | Very |Medium| Low |
| | inelastic, non-bursty flows | Low | | |
+---------------+------------------------------+------+------+------+
| Low-Latency | Variable rate, bursty short- | Low |Low - | Yes |
| Data | lived elastic flows | |Medium| |
|---------------+------------------------------+------+------+------|
|Conversational | Variable size packets, some | Low | Low | Yes |
| Signaling | what bursty short-lived flows| | | |
|---------------+------------------------------+------+------+------|
| OAM | Variable size packets, | Low |Medium| Yes |
| | elastic & inelastic flows | | | |
|---------------+------------------------------+------+------+------|
| High- | Variable rate, bursty long- | Low |Medium| Yes |
|Throughput Data| lived elastic flows | |- High| |
|---------------+------------------------------+------+------+------|
| Standard | A bit of everything | Not Specified |
|---------------+------------------------------+------+------+------|
| Low-Priority | Non-real-time and elastic | High | High | Yes |
| Data | | | | |
-------------------------------------------------------------------
Figure 2. Service Class Characteristics
Polk Expires August 25, 2013 [Page 24]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
Notes for Figure 2: A "Yes" in the jitter-tolerant column implies
that received data is buffered at the endpoint and that a moderate
level of server or network-induced variation in delay is not
expected to affect the application. Applications that use TCP or
SCTP as a transport are generally good examples. Routing protocols
and peer-to-peer signaling also fall in this class; although loss
can create problems in setting up calls, a moderate level of jitter
merely makes call placement a little less predictable in duration.
Service classes indicate the required traffic forwarding treatment
in order to meet user, application, and/or network expectations.
Section 3 defines the service classes that MAY be used for
forwarding network control traffic, and Section 4 defines the
service classes that MAY be used for forwarding user oriented
traffic with examples of intended application types mapped into each
service class. Note that the application types are only examples
and are not meant to be all-inclusive or prescriptive. Also, note
that the service class naming or ordering does not imply any
priority ordering. They are simply reference names that are used in
this document with associated QoS behaviors that are optimized for
the particular application types they support. Network
administrators MAY choose to assign different service class names to
the service classes that they will support. Figure 3 defines the
RECOMMENDED relationship between service classes and DS codepoint
assignment with application examples. It is RECOMMENDED that this
relationship be preserved end to end.
+------------------------------------------------------------------+
| Service | DSCP | DSCP | Application |
| Class Name | Name | Value | Examples |
|===============+=========+=============+==========================|
|Network Control| CS6&CS7 | 11xxxx | Network routing |
|---------------+---------+-------------+--------------------------|
| Realtime | CS5, | 101000, | Remote/Virtual Desktop |
| Interactive |CS5-Admit| 101001 | and Interactive gaming |
|---------------+---------+-------------+--------------------------|
| Audio | EF | 101110 | Voice bearer |
| |Voice-Admit| 101100 | |
|---------------+---------+-------------+--------------------------|
| Hi-Res A/V | CS4, | 100000, | Conversational Hi-Res |
| |CS4-Admit| 100001 | Audio/Video bearer |
|---------------+---------+-------------+--------------------------|
| Video |AF41,AF42|100010,100100| Audio/Video conferencing |
| | AF43 | 100110 | bearer |
|---------------+---------+-------------+--------------------------|
| Multimedia | MC, | 011101, | Presentation Data and |
| Conferencing | MC-Admit| 100101 | App Sharing/Whiteboarding|
|---------------+---------+-------------+--------------------------|
| Multimedia |AF31,AF32|011010,011100| Streaming video and |
| Streaming | AF33 | 011110 | audio on demand |
|---------------+---------+-------------+--------------------------|
Polk Expires August 25, 2013 [Page 25]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
| Broadcast | CS3, | 011000, | Broadcast TV, live events|
| |CS3-Admit| 011001 | & video surveillance |
|---------------+---------+-------------+--------------------------|
| Low-Latency |AF21,AF22|010010,010100|Client/server trans., Web-|
| Data | AF23 | 010110 |based ordering, IM/Pres |
|---------------+---------+-------------+--------------------------|
|Conversational | A/V-Sig | 010001 | Conversational signaling |
| Signaling | | | |
|---------------+---------+-------------+--------------------------|
| OAM | CS2 | 010000 | OAM&P |
|---------------+---------+-------------+--------------------------|
|High-Throughput|AF11,AF12|001010,001100| Store and forward |
| Data | AF13 | 001110 | applications |
|---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
|------------------------------------------------------------------|
| Best Effort | CS0 | 000000 | Undifferentiated |
| | | | applications |
+---------------+---------+-------------+--------------------------+
Figure 3. DSCP to Service Class Mapping
Notes for Figure 3:
o Default Forwarding (DF) and Class Selector 0 (CS0) (i.e., Best
Effort) provide equivalent behavior and use the same DS
codepoint, '000000'.
o RFC 2474 identifies any DSCP with a value of 11xxxx to be for
network control. This remains true, while it removes 12 DSCPs
from the overall pool of 64 available DSCP values (the 4 that are
x11 from this group are within pool 2 of RFC 2474, and remain as
only experimentally assignable/useable).
o All PHB names that say "-Admit" are to be used only when a
capacity-admission protocol is utilized for that or each traffic
flow.
Changes from table 3 of RFC 4594 are as follows:
o The old term "Signaling" was using CS5 (101000), now is
exclusively for the "Conversational Signaling" service group
using the DSCP name of "A/V-Sig" (010001), which is newly defined
in [ID-DSCP]. This is because CS5 aggregates into the 101xxx
aggregate when using layer 2 technologies such as 802.3 Ethernet,
802.11 Wireless Ethernet MPLS, etc - each of which only have 3
bits to mark with. A traffic type that can have very large
packets and is not delay sensitive (within reason) is not
appropriate for have a 101xxx marking. A REQUIRED behavior for
this PHB is that it not be starved in any node.
Polk Expires August 25, 2013 [Page 26]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o "Conversational" is a new term to include all interactive audio
and video. The Conversational service group consists of the audio
service class, the video service class and the new Hi-Res service
class.
o "Audio" obsoletes the term "Telephony", which has generally not
retained the "video" aspect within the IETF, where video is still
commonly called out as a separate thing. Audio retains the
nonadmitted traffic PHB of EF (101110), while capacity-admitted
audio has been added via the RFC 5865 defined PHB Voice-Admit.
o "Video" now is AF4x, with AF41 specifically for capacity-admitted
video traffic, while AF42 and AF43 are nonadmitted video traffic.
o "Hi-Res A/V", part of the Conversational service group, is
created by [ID-DSCP] for an additional business differentiation
interactive video marking for higher end traffic. It is within
the 100xxx as CS4 (for nonadmitted traffic) and CS4-Admit
(100001) (for capacity-admitted traffic).
o "Realtime Interactive" is now using CS5 (for nonadmitted
traffic), but adds a capacity-admitted DSCP CS5-Admit (101001).
o "Multimedia Conferencing" is no longer using the AF4x DSCPs,
rather it will use the new PHB MC (100101) (for
capacity-admitted) and MC-Admit (011101) (for nonadmitted
traffic).
o "Multimedia Streaming" retains using AF3x, however, AF31 is now
used for capacity-admitted traffic, while AF32/33 are
nonadmitted.
o "Broadcast" replaces "Broadcast Video" using CS3 (for nonadmitted
traffic), and adds a capacity-admitted PHB CS3-Admit (011001).
It is expected that network administrators will base their choice of
the service classes that they will support on their need.
Figure 4 provides a summary of DiffServ CoS mechanisms that MUST be
used for the defined service classes that are further detailed in
Sections 3 and 4 of this document. According to what
applications/services need to be differentiated, network
administrators MAY choose the service class(es) that need to be
supported in their network.
+-----------------------------------------------------------------+
| Service | DSCP | Conditioning at | PHB | Queuing| AQM|
| Class | | DS Edge | Used | | |
|===============+=======+===================+=======+========+====|
|Network Control|CS6/CS7| See Section 3.1 |RFC2474| Rate | Yes|
|---------------+-------+-------------------+-------+--------+----|
| Realtime | CS5, |Police using sr+bs |RFC2474| Rate | No |
Polk Expires August 25, 2013 [Page 27]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
| Interactive | CS5- | | | | |
| | Admit*| |[ID-DSCP]| | |
|---------------+-------+-------------------+-------+--------+----|
| | EF, |Police using sr+bs |RFC3246|Priority| No |
| Audio |Voice- | | | | |
| | Admit*| |RFC5865| | |
|---------------+-------+-------------------+-------+--------+----|
| | CS4, |Police using sr+bs |RFC2474|Priority| No |
| Hi-Res A/V | CS4- | | | | |
| | Admit*| |[ID-DSCP]| | |
|---------------+-------+-------------------+-------+--------+----|
| | AF41*,| Using two-rate, | | | Yes|
| Video | AF42 |three-color marker |RFC2597| Rate | per|
| | AF43 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+-------+--------+----|
| Multimedia | MC, |Police using sr+bs|[ID-DSCP]| Rate | No |
| Conferencing | MC- | | | | |
| | Admit*| |[ID-DSCP]| | |
|---------------+-------+-------------------+-------+--------+----|
| Multimedia | AF31*,| Using two-rate, | | | Yes|
| Streaming | AF32 |three-color marker |RFC2597| Rate | per|
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+-------+--------+----|
| Broadcast | CS3, |Police using sr+bs |RFC2474| Rate | No |
| | CS3- | | | | |
| | Admit*| |[ID-DSCP]| | |
|---------------+-------+-------------------+-------+--------+----|
| Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three-color marker |RFC2597| Rate | per|
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+-------+-------------------+-------+--------+----|
|Conversational |AV-Sig |Police using sr+bs|[ID-DSCP]| Rate | No |
| Signaling | | | | | |
|---------------+-------+-------------------+-------+--------+----|
| OAM | CS2 |Police using sr+bs |RFC2474| Rate | Yes|
|---------------+-------+-------------------+-------+--------+----|
| High- | AF11 | Using two-rate, | | | Yes|
| Throughput | AF12 |three-color marker |RFC2597| Rate | per|
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+-------+--------+----|
| Standard | DF | Not applicable |RFC2474| Rate | Yes|
|---------------+-------+-------------------+-------+--------+----|
| Low-Priority | CS1 | Not applicable |RFC3662| Rate | Yes|
| Data | | | | | |
|---------------+-------+-------------------+-------+--------+----|
Figure 4. Summary of CoS Mechanisms Used for Each Service Class
* denotes each DSCP identified for capacity-admission traffic only.
Notes for Figure 4:
Polk Expires August 25, 2013 [Page 28]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o Conditioning at DS edge means that traffic conditioning is
performed at the edge of the DiffServ network where untrusted
user devices are connected to two different administrative
DiffServ networks.
o "sr+bs" represents a policing mechanism that provides single rate
with burst size control.
o The single-rate, three-color marker (srTCM) behavior SHOULD be
equivalent to RFC 2697, and the two-rate, three-color marker
(trTCM) behavior SHOULD be equivalent to RFC 2698.
o The PHB for Realtime-Interactive service class SHOULD be
configured to provide high bandwidth assurance. It MAY be
configured as another EF PHB (one capacity-admitted and one
non-capacity-admitted, if both are to be used) that uses relaxed
performance parameters and a rate scheduler.
o The PHB for Multimedia Conferencing service class SHOULD be
configured to provide high bandwidth assurance. It MAY be
configured as another EF PHB (one capacity-admitted and one
non-capacity-admitted, if both are to be used) that uses relaxed
performance parameters and a rate scheduler.
o The PHB for Broadcast service class SHOULD be configured to
provide high bandwidth assurance. It MAY be configured as
another EF PHB (one capacity-admitted and one
non-capacity-admitted, if both are to be used) that uses relaxed
performance parameters and a rate scheduler.
2.4. Service Classes vs. Treatment Aggregates (from RFC 5127)
There are misconceptions about the differences between RFC 4594
specified service classes, and RFC 5127 specified treatment
aggregates. Often the two are conflated, and more often the phrase
service class is used to mean both definitions. Almost all of the
text previous to this section is used in defining service classes,
and how one service class is different than another service class
(based on traffic characteristics of the applications). Treatment
aggregates are groupings of service classes with similar, but not
identical, traffic characteristics to give similar treatment from a
SP's network.
Below is taken from appendix of RFC 5127 as its recommended
groupings of service classes into aggregates based in RFC 4594
specified traffic characteristic expectations.
+------------------------------------------------------------+
|Treatment |Treatment || DSCP |
|Aggregate |Aggregate || |
| |Behavior || |
Polk Expires August 25, 2013 [Page 29]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
|==========+==========++=====================================|
| Network | CS || CS6 |
| Control |(RFC 2474)|| |
|==========+==========++=====================================|
| Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 |
| Time* |(RFC 3246)|| |
|==========+==========++=====================================|
| Assured | AF || CS2, AF31, AF21, AF11 |
| Elastic |(RFC 2597)||-------------------------------------|
| | || AF32, AF22, AF12 |
| | ||-------------------------------------|
| | || AF33, AF23, AF13 |
|==========+==========++=====================================|
| Elastic | Default || Default, (CS0) |
| |(RFC 2474)||-------------------------------------|
| | || CS1 |
+------------------------------------------------------------+
Figure 5: RFC 5127 Defined Treatment Aggregate Behavior**
*NOTE: The RFC 5865 created VOICE-ADMIT is absence from the above
figure because VOICE-ADMIT was created far later than this
recommendation was. VOICE-ADMIT is appropriate for the
Realtime Traffic Aggregate.
**NOTE: Figure 5 is directly from the appendix of RFC 5127 as that
RFC's recommendation for configuration. This draft does not
directly affect RFC 5127. That is left for an update to RFC
5127 itself. Based on the WG's take on this draft, RFC 5127
will necessitate an update to match this document's new
service classes and additional DSCPs. The number of treatment
aggregates are not expected to change in the RFC 5127 Update
draft though, with the possible exception of a new treatment
aggregate for capacity admitted flows; meaning there *might*
be a 5th treatment aggregate proposed.
Treatment Aggregates are designed to nicely fit into technologies
that do not have many different treatment levels to use. Here are 3
examples of technologies limited to an 8-value field,
- MPLS with its 3 Traffic Class (TC) bits [RFC5462].
- IEEE LANs with its 8-value Priority Code Point (PCP) field, as
part of the 802.1Q header spec [IEEE1Q].
- IEEE 802.1e, which defines QoS over Wi-Fi, also only defines 8
levels (called User Priority or UP codes) [IEEE1E].
Treatment Aggregates are dependent on service classes to exist.
Therefore many service classes can exist without the need to
consider the use of treatment aggregates or their 8-value
technologies. For example, a Layer 3 VPN can be all that is needed
Polk Expires August 25, 2013 [Page 30]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
to transit traffic flows, regardless of desired treatment, between
enterprise LAN campuses. From this reality, the number of treatment
aggregates has no direct bearing on the number of service classes.
2.4.1 Examples of Service Classes in Treatment Aggregates
It is *not* expected that all traffic characteristics are to be
experienced across an SP's network for any given customer. For
example, if VOICE-ADMIT is added to the Realtime Treatment Aggregate
in Figure 5, there are 8 different service classes within the
Realtime Treatment Aggregate. It is not expected that all 8 service
classes will be deployed by customer networks traversing SP
networks. RFC 5127's Treatment Aggregates are a table to configure
which service class goes into which treatment aggregate. If there
are 8 services classes in the Realtime treatment aggregate, there is
very little difference than if there were one service within that
same Realtime treatment aggregate - it would still be necessary to
configure that treatment aggregate. Thus, it becomes a question of
not
"how many service classes are there that go into treatment
aggregates?"
but
"how many treatment aggregates have one or more services
classes requiring configuration"?
Of the 4 treatment aggregates shown in Figure 5, if there are
existing service classes in only 3 of the aggregates, then only 3
treatment aggregates are necessary. Of the 3 following examples,
notice that examples 2 and 3 have the same number of treatment
aggregates, but example 3 has more applications in their own
service classes.
Examples 2 and 3 are made under the following assumptions:
- this draft's Service Classes and DSCP assignments are utilized.
- the new AF-Sig DSCP in the Assured Elastic treatment aggregate.
- the Audio, Video service classes are in the EF treatment
aggregate.
- the VOICE-ADMIT DSCP is in the EF treatment aggregate.
2.4.1.1 Example 1 - Simple Voice Configuration/SLA
For example 1, we have an SP running MPLS and has an SLA to deliver
Network Control, Voice and everything else is Best Effort. The
Polk Expires August 25, 2013 [Page 31]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
following table would apply to this configuration/SLA:
+----------------+----------------+-----------+--------------+
| Applications | Service | DSCP(s) | Treatment |
| | Class | | Aggregate |
+================+================+===========+==============+
| Network | Network | CS6 | Network |
| Control | Control | | Control |
+----------------+----------------+-----------+--------------+
| Voice | Audio | EF | Realtime |
+----------------+----------------+-----------+--------------+
| Everything | DF | Default | Elastic |
| else | | (CS0) | |
+----------------+----------------+-----------+--------------+
Figure 6. Example 1 Configuration
Insert different treatments for this example
(i.e., AQM, RED, WFQ, colors, etc from above charts)
2.4.1.2 Example 2 - Voice/Video/Surveillance Configuration/SLA
For example 1, we have an SP running MPLS and has an SLA to deliver
Control, audio, video, surveillance, audio & video signaling, and
everything else is BE
+----------------+----------------+-----------+--------------+
| Applications | Service | DSCP(s) | Treatment |
| | Class | | Aggregate |
+================+================+===========+==============+
| Network | Network | CS6 | Network |
| Control | Control | | Control |
+----------------+----------------+-----------+--------------+
| Voice, video, | Audio, Video, | EF, AF42, | Realtime |
| surveillance | Broadcast | CS3 | |
+----------------+----------------+-----------+--------------+
| audio & video | Conversational | AV-Sig | Assured |
| signaling | Signaling | | Elastic |
+----------------+----------------+-----------+--------------+
| Everything | DF | Default | Elastic |
| else | | (CS0) | |
+----------------+----------------+-----------+--------------+
Figure 7. Example 2 Configuration
Insert different treatments for this example
(i.e., AQM, RED, WFQ, colors, etc from above charts)
2.4.1.2 Example 3 - Complex CAC realtime/Surveillance/+apps
Configuration/SLA
For example 1, we have an SP running MPLS and has an SLA to deliver
Polk Expires August 25, 2013 [Page 32]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
Control, voice, CAC voice, CAC video, streaming, signaling, LL
data, Network Mgmt., and everything else is BE (including non-CAC
video because it is not authorized or authenticated on network)
+-------------------+-----------------+-----------+--------------+
| Applications | Service | DSCP(s) | Treatment |
| | Class | | Aggregate |
+===================+=================+===========+==============+
| Network | Network | CS6 | Network |
| Control | Control | | Control |
+-------------------+-----------------+-----------+--------------+
| Voice, CAC-Voice | Audio, Video, |Voice-Admit| Realtime |
| CAC-video, | | EF, AF41 | |
| surveillance | Broadcast | CS3 | |
+-------------------+-----------------+-----------+--------------+
| audio & video | Conversational | AV-Sig | Assured |
| signaling, | Signaling, Low- | AF21 | Elastic |
| VOD (streaming), | Latency Data, | AF31 | |
| Network Mgmt. | Multimedia | CS2 | |
| | Streaming, | | |
| | OAM | | |
+-------------------+-----------------+-----------+--------------+
| Everything | DF | Default | Elastic |
| else | | (CS0) | |
+-------------------+-----------------+-----------+--------------+
Figure 8. Example 3 Configuration
Insert different treatments for this example
(i.e., AQM, RED, WFQ, colors, etc from above charts)
3. Network Control Traffic
Network control traffic is defined as packet flows that are
essential for stable operation of an administered network, as well
as the information exchanged between neighboring networks across a
peering point where SLAs are in place. Network control traffic is
different from user application control (signaling) that may be
generated by some applications or services. Network control traffic
is mostly between routers and network nodes (e.g., routing or mgmt
protocols) that are used for operating, administering, controlling,
or managing whole networks, network parts or just network segments.
Network Control Traffic may be split into two service classes, i.e.,
Network Control and OAM.
3.1. Current Practice in the Internet
Based on today's routing protocols and network control procedures
that are used in the Internet, we have determined that CS6 DSCP
value SHOULD be used for routing and control and that CS7 DSCP value
SHOULD be reserved for future use, specifically if needed for future
Polk Expires August 25, 2013 [Page 33]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
routing or control protocols. Network administrators MAY use a
Local/Experimental DSCP, any value that contains 11xx11; therefore,
they may use a locally defined service class within their network to
further differentiate their routing and control traffic.
RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets:
o Drop or remark 111xxx packets at ingress to DiffServ network
domain.
o 111xxx marked packets SHOULD NOT be sent across peering points.
Exchange of control information across peering points SHOULD be
done using CS6 DSCP and the Network Control service class.
o any internally defined 11xxx1 values, valid within that network
domain, be remarked to CS6 upon egress at network peering points.
3.2. Network Control Service Class
The Network Control service class is used for transmitting packets
between network devices (routers) that require control (routing)
information to be exchanged between similar devices within the
administrative domain, as well as across a peering point between
adjacent administrative domains. Traffic transmitted in this
service class is very important as it keeps the network operational,
and it needs to be forwarded in a timely manner.
The Network Control service class SHOULD be configured using the
DiffServ CS6 PHB, defined in [RFC2474]. This service class MUST be
configured so that the traffic receives a minimum bandwidth
guarantee, to ensure that the packets always receive timely service.
The configured forwarding resources for Network Control service
class MUST be such that the probability of packet drop under peak
load is very low. The Network Control service class SHOULD be
configured to use a Rate Queuing system such as defined in Section
1.4.1.2 of this document.
The following are examples of protocols and applications that MUST
use the Network Control service class if present in a network:
o Routing packet flows: OSPF, BGP, ISIS, RIP.
o Control information exchange within and between different
administrative domains across a peering point where SLAs are in
place.
o LSP setup using CR-LDP and RSVP-TE.
The following protocols and applications MUST NOT use the Network
Control service class:
o User oriented traffic is not allowed to use this service class.
Polk Expires August 25, 2013 [Page 34]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
By user oriented traffic, we mean packet flows that originate
from user-controlled end points that are connected to the
network.
o even if originating from a server or a device acting on behalf
of a user or endpoint,
o even if it is application or in-band signaling to establish a
connection wholly within a single network or across peering
points of/to adjacent networks (e.g., creating a tunnel such
as a VPN, or data path control signaling).
The following are traffic characteristics of packet flows in the
Network Control service class:
o Mostly messages sent between routers and network servers.
o Variable size packets, normally one packet at a time, but traffic
can also burst (BGP, OSPF, etc).
o IGMP, hen is used only for the normal multicast routing purpose.
The REQUIRED DSCP marking is CS6 (Class Selector 6).
RECOMMENDED Network Edge Conditioning:
o At peering points (between two DiffServ networks) where SLAs are
in place, CS6 marked packets MUST be policed, e.g., using a
single rate with burst size (sr+bs) token bucket policer to keep
the CS6 marked packet flows to within the traffic rate specified
in the SLA.
o CS6 marked packet flows from untrusted sources (for example, end
user devices) MUST be dropped or remarked at ingress to the
DiffServ network. What a network admin remarks this user oriented
traffic to if a matter of local policy, and inspection of the
packets can determine which application is used for proper
marking to a more appropriate DSCP, such as from table 3. of this
document.
o Packets from users/subscribers are not permitted access to the
Network Control service classes.
The fundamental service offered to the Network Control service class
is enhanced best-effort service with high bandwidth assurance.
Since this service class is used to forward both elastic and
inelastic flows, the service SHOULD be engineered so that the Active
Queue Management (AQM) [RFC2309] is applied to CS6 marked packets.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth, and the max-threshold specifies the
queue depth above which all traffic is dropped or ECN marked. Thus,
Polk Expires August 25, 2013 [Page 35]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
in this service class, the following inequality should hold in queue
configurations:
o min-threshold CS6 < max-threshold CS6
o max-threshold CS6 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result.
3.3. OAM Service Class
The OAM (Operations, Administration, and Management) service class
is RECOMMENDED for OAM&P (Operations, Administration, and Management
and Provisioning) using protocols such as Simple Network Management
Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet,
and Common Open Policy Service (COPS). Applications using this
service class require a low packet loss but are relatively not
sensitive to delay. This service class is configured to provide
good packet delivery for intermittent flows.
The OAM service class SHOULD use the Class Selector (CS) PHB defined
in [RFC2474]. This service class SHOULD be configured to provide a
minimum bandwidth assurance for CS2 marked packets to ensure that
they get forwarded. The OAM service class SHOULD be configured to
use a Rate Queuing system such as defined in Section 1.4.1.2 of this
document.
The following applications SHOULD use the OAM service class:
o Provisioning and configuration of network elements.
o Performance monitoring of network elements.
o Any network operational alarms.
The following are traffic characteristics:
o Variable size packets.
o Intermittent traffic flows.
o Traffic may burst at times.
o Both elastic and inelastic flows.
o Traffic not sensitive to delays.
RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS2 (Class
Selector 2).
Polk Expires August 25, 2013 [Page 36]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
Applications or IP end points SHOULD pre-mark their packets with CS2
DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification, as defined in [RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods, defined in
[RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (routers inside administered
network) MAY not require policing.
o Normally OAM&P CS2 marked packet flows are not allowed to flow
across peering points. If that is the case, then CS2 marked
packets SHOULD be policed (dropped) at both egress and ingress
peering interfaces.
The fundamental service offered to "OAM" traffic is enhanced
best-effort service with controlled rate. The service SHOULD be
engineered so that CS2 marked packet flows have sufficient bandwidth
in the network to provide high assurance of delivery. Since this
service class is used to forward both elastic and inelastic flows,
the service SHOULD be engineered so that Active Queue Management
[RFC2309] is applied to CS2 marked packets.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP
is dropped or ECN marked. Thus, in this service class, the
following inequality should hold in queue configurations:
o min-threshold CS2 < max-threshold CS2
o max-threshold CS2 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result.
4. User Oriented Traffic
User oriented traffic is defined as packet flows between different
users or subscribers, or from servers/nodes on behalf of a user. It
is the traffic that is sent to or from end-terminals and that
Polk Expires August 25, 2013 [Page 37]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
supports a very wide variety of applications and services, to
include traffic about a user or application that assists a user
communicate. User oriented traffic can be classified in many
different ways. What we have articulated throughout this document is
a series of non-exhaustive list of categories for classifying user
oriented traffic. We differentiated user oriented traffic that is
real-time versus non-real-time, elastic or rate-adaptive versus
inelastic, sensitive versus insensitive to loss as well as
considering whether the traffic is interactive vs. one way
communication, its responsiveness, whether it requires timely
delivery, and critical verses non-critical. In the final analysis,
we used all of the above for service differentiation, mapping
application types that seemed to have different sets of performance
sensitivities, and requirements to different service classes.
Network administrators can categorize their applications according
to the type of behavior that they require and MAY choose to support
all or a subset of the defined service classes. At the same time,
we include a public facing default DSCP value, with its associated
PHB, that is expected for each traffic type to ensure common or
pervasive performance. Figure 3 provides some common applications
and the forwarding service classes that best support them, based on
their performance requirements.
4.1. Conversational Service Class Group
The Conversational Service Class Group consists of 3 different
service classes, audio, video, and Hi-Res. We are describing the
media sample, or bearer, packets for applications (e.g., RTP from
[RFC3550]) that require bi-directional real-time, very low delay,
very low jitter, and very low packet loss for relatively
constant-rate traffic sources (inelastic traffic sources). It is
RECOMMENDED that RTCP feedback use the same service class and be
marked with the same DSCP as the bearer traffic for that (audio
and/or video) call. This ensures comparable treatment within the
network between endpoints.
The signaling to set-up these bearer flows is part of the
Conversational Signaling service group that will be discussed later
in Section 4. The following 3 subsections will detail what is
expected within each bearer service class.
4.1.1 Audio Service Class
This service class MUST be used for IP Audio service.
The fundamental service offered to traffic in the Audio service
class is minimum jitter, delay, and packet loss service up to a
specified upper bound. There are two PHBs, both EF based, for the
Audio service class:
Nonadmitted Audio traffic - MUST use the EF DSCP [RFC3246], and
Polk Expires August 25, 2013 [Page 38]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
is for traffic that has not had any capacity admission
signaling performed for that flow or session.
Capacity-Admitted Audio traffic - MUST use the Voice-Admit DSCP
[RFC5865], and is for traffic that has had any capacity
admission signaling performed for that flow or session, e.g.,
RSVP [RFC2205] or NSIS [RFC4080].
The capacity-admitted Audio traffic operation is similar to an ATM
CBR service, which has guaranteed bandwidth and which, if it stays
within the negotiated rate, experiences nominal delay and no loss.
The nonadmitted Audio traffic, on the other hand, has had no such
explicit guarantee, but has a favorable PHB ensuring high
probability of delivery as well as nominal delay and no loss -
implicitly assuming there is not too much like marked traffic
between users within a flow.
There are two typical scenarios in which audio calls are
established, on the public open Internet using protocols such as
SIP, XMPP or H.323, or in more managed networks like enterprises or
certain service providers which offer a audio service with some
feature benefits and take part in the call signaling. These SPs or
enterprises also use protocols like SIP, XMPP, H.323, but also use
H.248/MEGACO and MGCP.
On the open Internet, typically there is no SP actively involved in
the session set-up of calls, and therefore no servers providing
assistance or features to help one user contact another user. Often,
this traffic is marked or remarked with the DF (i.e., Best Effort)
DSCP.
In more managed networks in which one of more operators have active
servers aiding the audio call set-up, where DiffServ can be used and
preserved to differentiate traffic, networks are offering a service,
therefore need to do some, or a lot of engineering to ensure that
capacity offered to one or more applications does not exceed the
load to the network. Otherwise, the operator will have unhappy
users, at least for that application's usage. This is true for any
application, but is especially true for inelastic applications in
which the application is rigid in its delivery requirements. Audio
bearer traffic is typically such an application, video is another
such application, but we will get to video in the next subsection.
When a user in a managed network has been authorized to send Audio
traffic (i.e., call initiation via the operator's servers was not
rejected), the call admission procedure should have verified that
the newly admitted flow will be within the capacity of the Audio
service class forwarding capability in the network. Capacity
verification is a non-trivial thing, and can either be implicitly
assumed by the call server(s) based on the operator's network
design, or it can be explicitly signaled from an in-data-path
Polk Expires August 25, 2013 [Page 39]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
signaling mechanism that verifies the capacity is available now for
this call, for each call made within that network. In the latter
case, those that do not have verifiable network capacity along the
data path are rejected. An in between means method is for call
servers to count calls between two or more endpoints. By
topologically understanding where the caller and called party is and
have configured a known maximum it will allow between the two
locations. This is especially true over WAN links that have far less
capacity than LAN links or core parts of a network. Network
operators will need to understand the topology between any two
callers to ensure the appropriate amount of bandwidth is available
for an expected number of simultaneous audio calls.
Once more than one bandwidth amount can be used for audio calls, for
example - by allowing more than one codec with different bandwidths
per codec for such calls, network engineering becomes more
difficult. Since the inelastic nature of RTP payloads from this
class do not react well to loss or significant delay in any
substantive way, the Audio service class MUST forward packets as
soon as possible.
The Audio service class that does not have capacity admission
performed in the data path MUST use the Expedited Forwarding (EF)
PHB, as defined in [RFC3246], so that all packets are forwarded
quickly. The Audio service class that does have capacity admission
performed in the data path MUST use the Voice-Admit PHB, as defined
in [RFC5865], so that all packets are forwarded quickly. The Audio
service class SHOULD be configured to use a Priority Queuing system
such as that defined in Section 1.4.1.1 of this document.
The following applications SHOULD use the Audio service class:
o VoIP (G.711, G.729, iLBC and other audio codecs).
o Voice-band data over IP (modem, fax).
o T.38 fax over IP.
o Circuit emulation over IP, virtual wire, etc.
o IP Virtual Private Network (VPN) service that specifies
single-rate, mean network delay that is slightly longer then
network propagation delay, very low jitter, and a very low packet
loss.
The following are traffic characteristics:
o Mostly fixed-size packets for VoIP (30, 60, 70, 120 or 200 bytes
in size).
o Packets emitted at constant time intervals.
Polk Expires August 25, 2013 [Page 40]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o Admission control of new flows is provided by Audio call server,
media gateway, gatekeeper, edge router, end terminal, access node
or in-data-path signaling that provides flow admission control
function.
Applications or IP end points SHOULD pre-mark their packets with EF
or Voice-Admit DSCP value, whichever is appropriate. If the end
point is not capable of setting the DSCP value, then the router
topologically closest to the end point SHOULD perform Multifield
(MF) Classification, as defined in [RFC2475].
The RECOMMENDED DSCP marking is EF for nonadmitted audio flows, and
Voice-Admit for capacity-admitted flows for the following
applications:
o VoIP (G.711, G.729 and other codecs).
o Voice-band data over IP (modem and fax).
o T.38 fax over IP.
o Circuit emulation over IP, virtual wire, etc.
RECOMMENDED Network Edge Conditioning:
o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods, defined in
[RFC2475]. If untrusted, the network edge SHOULD know if
capacity-admission has been applied, since the edge router will
have taken part in the admission signaling; therefore will know
whether EF or Voice-Admit is the proper marking for that flow.
o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the Audio
traffic stays within its negotiated bounds.
o Policing is OPTIONAL for packet flows from trusted sources whose
behavior is ensured via other means (e.g., administrative
controls on those systems).
o Policing of Audio packet flows across peering points where SLA is
in place is OPTIONAL as Audio traffic will be controlled by
admission control mechanism between peering points.
The fundamental service offered to "Audio" traffic is enhanced
best-effort service with controlled rate, very low delay, and very
low loss. The service MUST be engineered so that EF marked packet
flows have sufficient bandwidth in the network to provide guaranteed
delivery. Otherwise, the service will have in place an explicit
capacity-admission signaling protocol such as RSVP or NSIS and thus
Polk Expires August 25, 2013 [Page 41]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
mark the packets within the flow as Voice-Admit. Normally traffic in
this service class does not respond dynamically to packet loss. As
such, Active Queue Management [RFC2309] SHOULD NOT be applied to EF
marked packet flows.
4.1.2 Video Service Class
The Video service class is for bidirectional applications that
require real-time service for both constant and rate-adaptive
traffic. SIP and H.323/V2 (and later) versions of video
conferencing equipment with constant and dynamic bandwidth
adjustment are such applications. The traffic sources in this
service class either have a fixed bandwidth requirement (e.g.,
MPEG2, etc.), or have the ability to dynamically change their
transmission rate (e.g., MPEG4/H.264, etc.) based on feedback from
the receiver. This feedback SHOULD be accomplished using RTCP
[RFC3550]. One approach for this downspeeding has the receiver
detect packet loss, thus signaling in an RTCP message to the source
the indication of lost (or delayed or out of order) packets in
transit. When necessary the source then selects a lower rate
encoding codec. When available, the source merely sends less data,
resulting in lower resolution of the same visual display.
The Video service class is not for video downloads, webcasts, or
single directional video or audio/video traffic of any kind. It is
for human-to-human visual interaction between two users, or more if
an MTP is used.
Typical video conferencing configurations negotiate the setup of
audio/video session using protocols such as SIP and H.323. Just as
with networks that have audio traversing them, video typically
traverses the same two types of networks: the open big "I" Internet,
in which most every type of traffic is best effort (DF), or on a
more managed network such as an enterprise or SP's managed network
in which servers within either network take part in the call
signaling, thereby offering the video service.
When a user in a managed network has been authorized to send video
traffic (i.e., call initiation via the operator's servers was not
rejected), the call admission procedure should have verified that
the newly admitted flow will be within the capacity of the video
service class forwarding capability in the network. Capacity
verification is a non-trivial thing, and can either be implicitly
assumed by the call server(s) based on the operator's network
design, or it can be explicitly signaled from an in-data-path
signaling mechanism that verifies the capacity is available now for
this call, for each call made within that network. In the latter
case, those that do not have verifiable network capacity along the
data path are rejected. An in between means method is for call
servers to count calls between two or more endpoints. By
topologically understanding where the caller and called party is and
Polk Expires August 25, 2013 [Page 42]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
have configured a known maximum it will allow between the two
locations. Video is larger in bandwidth than audio, and the
difference can be significant. For example, for a single G.711 audio
call that is 80kbps, an associated video bandwidth for the same
call can easily be 4Mbps. This is especially true over WAN links
that have far less capacity than LAN links or core parts of a
network. Network operators will need to understand the topology
between any two callers to ensure the appropriate amount of
bandwidth is available for an expected number of simultaneous video
and/or audio/video calls.
Note that it is OPTIONALLY the case in these networks that the
accompanying audio for the video call will be marked as the video is
marked (i.e., using the same DSCP), but not always. One reason this
has been done is for lip-sync.
The Video service class MUST use the Assured Forwarding (AF) PHB,
defined in [RFC2597]. This service class MUST be configured to
provide a bandwidth assurance for AF41, AF42, and AF43 marked
packets to ensure that they get forwarded. The Video service class
SHOULD be configured to use a Rate Queuing system for AF42 and AF43
traffic flows, such as that defined in Section 1.4.1.2 of this
document. However, AF41 MUST be designated as the DSCP for use when
capacity-admission signaling has been used, such as RSVP or NSIS, to
guarantee delivery through the network. AF42 and AF43 will be used
for non-admitted video calls, as well as overflows from AF41 sources
that send more packets than they have negotiated bandwidth for that
call.
The following applications MUST use the Video service class:
o SIP and H.323/V2 (and later) versions of video conferencing
applications (interactive video).
o Video conferencing applications with rate control or traffic
content importance marking.
o Interactive, time-critical, and mission-critical applications.
NOTE with regards to the above bullet: this usage SHOULD be
minimized, else the video traffic will suffer - unless this
is engineered into the topology.
The following are traffic characteristics:
o Variable size packets (i.e., small to large in size).
o The higher the resolution or change rate between each image, the
higher the duration of large packets.
o Usually constant inter-packet time interval.
Polk Expires August 25, 2013 [Page 43]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o Can be Variable rate in transmission.
o Source is capable of reducing its transmission rate based on
being told receiver is detecting packet loss (e.g., via RTCP).
Applications or IP end points SHOULD pre-mark their packets with
DSCP values as shown below. If the end point is not capable of
setting the DSCP value, then the router topologically closest to the
end point SHOULD perform Multifield (MF) Classification, as defined
in [RFC2475] and mark all packets as AF4x. Note: In this case, the
two-rate, three-color marker will be configured to operate in
Color-Blind mode.
Mandatory DSCP marking when performed by router closest to source:
o AF41 = up to specified rate "A", which is dedicated to non-Hi-Res
capacity-admitted video traffic.
Note the audio of an A/V call can be marked AF41 as well.
o AF42 = all non-Hi-Res video traffic marked AF41 in excess of
specified rate "A", or new non-admitted video traffic but
below specified rate "B".
o AF43 = in excess of specified rate "B".
o Where "A" < "B".
Note: One might expect "A" to approximate the peak rates of sum of
all admitted video flows, plus the sum of the mean rates and
"B" to approximate the sum of the peak rates of those same two
flows.
Mandatory DSCP marking when performed by SIP or H.323/V2
videoconferencing equipment:
o AF41 = SIP or H.323 video conferencing audio stream RTP.
o AF41 = SIP or H.323 video conferencing video control RTCP.
o AF41 = SIP or H.323 video conferencing video stream up to
specified rate "A".
o AF42 = SIP or H.323 video conferencing video stream in excess of
specified rate "A" but below specified rate "B".
o AF42 = SIP or H.323 video conferencing video control RTCP, for
those video streams that were generated using AF42.
o AF43 = SIP or H.323 video conferencing video stream in excess of
specified rate "B".
Polk Expires August 25, 2013 [Page 44]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o AF43 = SIP or H.323 video conferencing video control RTCP, for
those video streams that were generated using AF43.
o Where "A" < "B".
Mandatory conditioning performed at DiffServ network edge:
o The two-rate, three-color marker SHOULD be configured to provide
the behavior as defined in trTCM [RFC2698].
o If packets are marked by trusted sources or a previously trusted
DiffServ domain and the color marking is to be preserved, then
the two-rate, three-color marker SHOULD be configured to operate
in Color-Aware mode.
o If the packet marking is not trusted or the color marking is not
to be preserved, then the two-rate, three-color marker SHOULD be
configured to operate in Color-Blind mode.
The fundamental service offered to nonadmitted "Video" traffic is
enhanced best-effort service with controlled rate and delay. The
fundamental service offered to capacity-admitted "Video" traffic is
a guaranteed service using in-data-path signaling to ensure expected
delivery in a timely manner. For a non-admitted video conferencing
service, if a 1% packet loss detected at the receiver triggers an
encoding rate change, thus dropping to the next lower provisioned
video encoding rate then Active Queue Management [RFC2309] SHOULD be
used primarily to switch the video encoding rate under congestion,
changing from high rate to lower rate, i.e., 1472 kbps to 768 kbps.
This rule applies to all AF42 and 43 flows. The probability of loss
of AF41 traffic MUST NOT exceed the probability of loss of AF42
traffic, which in turn MUST NOT exceed the probability of loss of
AF43 traffic.
Capacity-admitted video service should not result in packet loss.
However, administratively this MAY be allowed to cause a purposeful
downspeeding event (i.e., a change in resolution or a change in
codec) to occur due to congestion.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP
is dropped or ECN marked. Thus, in this service class, the
following inequality should hold in queue configurations:
o min-threshold AF43 < max-threshold AF43
o max-threshold AF43 <= min-threshold AF42
o min-threshold AF42 < max-threshold AF42
o max-threshold AF42 <= min-threshold AF41
Polk Expires August 25, 2013 [Page 45]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o min-threshold AF41 < max-threshold AF41
o max-threshold AF41 <= memory assigned to the queue
Note: This configuration tends to drop AF43 traffic before AF42 and
AF42 before AF41. Many other AQM algorithms exist and are
used; they should be configured to achieve a similar result.
4.1.3 Hi-Res Service Class
The Hi-Res service class is for higher end (i.e., deemed 'more
important') bidirectional applications that require real-time
service for both constant and rate-adaptive traffic. There are two
PHBs, both EF based, for the Hi-Res video conferencing service
class:
Nonadmitted Hi-Res traffic - MUST use the CS4 DSCP [RFC2474], and
is for traffic that has not had any capacity admission
signaling performed for that flow or session.
Capacity-Admitted Hi-Res traffic - MUST use the CS4-Admit DSCP
[ID-DSCP], and is for traffic that has had any capacity
admission signaling performed for that flow or session, e.g.,
RSVP [RFC2205] or NSIS [RFC4080].
The capacity-admitted Hi-Res video conferencing traffic operation is
similar to an ATM CBR service, which has guaranteed bandwidth and
which, if it stays within the negotiated rate, experiences nominal
delay and no loss.
SIP and H.323/V2 (and later) versions of video conferencing
equipment with constant and dynamic bandwidth adjustment are such
applications. The traffic sources in this service class either have
a fixed bandwidth requirement (e.g., MPEG2), or have the ability to
dynamically change their transmission rate (e.g., MPEG4/H.264) based
on feedback from the receiver. This feedback SHOULD be accomplished
using RTCP [RFC3550]. One approach for this downspeeding has the
receiver detect packet loss, thus signaling in an RTCP message to
the source the indication of lost (or delayed or out of order)
packets in transit. When necessary the source then selects a lower
rate encoding codec. When available, the source merely sends less
data, resulting in lower resolution of the same visual display.
The Hi-Res service class, as with the Video service class, is not
for video downloads, webcasts, or single directional video or
audio/video traffic of any kind. It is for human-to-human visual
interaction between two users, or more if an video conference bridge
is used.
Typical Hi-Res video conferencing configurations negotiate the setup
Polk Expires August 25, 2013 [Page 46]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
of audio/video session using protocols such as SIP and H.323.
Hi-Res video conferencing is generally not over the big "I"
Internet, rather nearly exclusively over more managed networks such
as an enterprise or special purpose SP's managed network in which
servers within either network take part in the call signaling,
thereby offering the video service. In addition, typically this type
of audio/video service has high business expectations for minimized
packet loss, pixilation or other issues with the audio/video
experience. In the recent past, entire T3s have been dedicated to a
signal Hi-Res call; sometimes one T3 per site of a multi-site video
conference.
Hi-Res video conferencing often has larger in bandwidth than the
typical video call. The audio portion can be increased as well, as
stereo capabilities are often necessary to provide an in-room
experience from a distance. The difference can be significant (or
another step up from just a typical video service). For example, for
a single G.711 audio call that is 80kbps, a Hi-Res conference
usually runs G.722 wideband audio at 256kbps. Typical video delivery
is up to 4Mbps, whereas a Hi-Res conference can have three
1080p/30fps widescreen displays requiring at least 12Mbps, with a
burst capability of much more.
If there were no congestion on the wire, the expected treatment
between a video service and a Hi-Res conference would be the same.
However, it is typically the case that the Hi-Res conferencing flows
have more rigid requirements for quality and business-wise, need to
be experience far less errors than the regular video service on the
same network.
Note that it is likely the case in these networks that the
accompanying audio to the Hi-Res video call will be marked as the
Hi-Res video is marked (i.e., using the same DSCP.
The Hi-Res service class MUST use the Class Selector 5 (CS4) PHB,
defined in [RFC2474], for non-capacity-admitted conferences. While
the capacity-admitted Hi-Res conferences MUST use the CS4-Admit PHB,
defined in [ID-DSCP]. This service class MUST be configured to
provide a bandwidth assurance for CS4 and CS4-Admit marked packets
to ensure that they get forwarded. The Hi-Res service class SHOULD
be configured to use a Priority Queuing system such as that defined
in Section 1.4.1.1 of this document. Further, CS4-Admit will be
designated as the DSCP for use when capacity-admission signaling has
been used, such as RSVP or NSIS, to guarantee delivery through the
network. CS4 will be used for non-admitted Hi-Res conferences, as
well as overflows from CS4-Admit sources that send more packets than
they have negotiated bandwidth for that call.
The following applications MUST use the Hi-Res service class:
o SIP and H.323/V2 (and later) versions of Hi-Res video
conferencing applications (interactive Hi-Res video).
Polk Expires August 25, 2013 [Page 47]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o Video conferencing applications with rate control or traffic
content importance marking.
The following are traffic characteristics:
o Variable size packets.
o The higher the resolution or change rate between each image, the
higher the duration of large packets.
o Usually constant inter-packet time interval.
o Can be Variable rate in transmission.
o Source is capable of reducing its transmission rate based on
being told receiver is detecting packet loss.
Applications or IP end points SHOULD pre-mark their packets with
DSCP values as shown below. If the end point is not capable of
setting the DSCP value, then the router topologically closest to the
end point SHOULD perform Multifield (MF) Classification, as defined
in [RFC2475] and mark all packets as AF4x.
Mandatory DSCP marking when performed by router closest to source:
o CS4-Admit = up to specified rate "A", which is dedicated to
capacity-admitted Hi-Res traffic.
Note the audio of an A/V call can be marked CS4-Admit as well.
o CS4 = all video traffic marked CS4-Admit in excess of specified
rate "A", or new non-admitted video traffic but below
specified rate "B".
o Where "A" < "B".
Note: One might expect "A" to approximate the peak rates of sum of
all admitted video flows, plus the sum of the mean rates and
"B" to approximate the sum of the peak rates of those same two
flows.
Mandatory DSCP marking when performed by SIP or H.323/V2
videoconferencing equipment:
o CS4-Admit = SIP or H.323 video conferencing audio stream RTP/UDP.
o CS4-Admit = SIP or H.323 video conferencing video control
RTCP/TCP.
o CS4-Admit = SIP or H.323 video conferencing video stream up to
specified rate "A".
Polk Expires August 25, 2013 [Page 48]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o CS4 = SIP or H.323 video conferencing video stream in excess of
specified rate "A" but below specified rate "B".
o Where "A" < "B".
Mandatory conditioning performed at DiffServ network edge:
o The two-rate, three-color marker SHOULD be configured to provide
the behavior as defined in trTCM [RFC2698].
o If packets are marked by trusted sources or a previously trusted
DiffServ domain and the color marking is to be preserved, then
the two-rate, three-color marker SHOULD be configured to operate
in Color-Aware mode.
o If the packet marking is not trusted or the color marking is not
to be preserved, then the two-rate, three-color marker SHOULD be
configured to operate in Color-Blind mode.
The fundamental service offered to nonadmitted "Hi-Res" traffic is
enhanced best-effort service with controlled rate and delay. The
fundamental service offered to capacity-admitted "Hi-Res" traffic is
a guaranteed service using in-data-path signaling to ensure expected
or timely delivery. Capacity-admitted video service SHOULD NOT
result in packet loss. However, administratively this MAY be allowed
to cause a purposeful downspeeding event (i.e., a change in
resolution or a change in codec) to occur.
4.2. Realtime-Interactive Service Class
The Realtime-Interactive service class is for bidirectional
applications that require low loss and jitter and very low delay for
constant or variable rate inelastic traffic sources. Interactive
gaming applications that do not have the ability to change encoding
rates or to mark packets with different importance indications is
one good example of such an application. Another set of
applications is virtualized desktop applications in which a remote
user has a keyboard, mouse and display monitor, but the desktop is
virtualized with the memory/processor/applications back in a common
data center, requiring near instantaneous feedback on the user's
monitor of any changes caused by the application or an action by the
user. Rich media protocols for voice and video MUST NOT use the
Realtime-Interactive service class, but rather the appropriate
service class from the Conversational service group discussed early
in Section 4.1.
The Realtime-Interactive service class will use two PHBs:
Nonadmitted Realtime-Interactive traffic - MUST use the CS5 DSCP
[RFC2474], and is for traffic that has not had any capacity
Polk Expires August 25, 2013 [Page 49]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
admission signaling performed for that flow or session.
Capacity-Admitted Realtime-Interactive traffic - MUST use the
CS5-Admit DSCP [ID-DSCP], and is for traffic that has had any
capacity admission signaling performed for that flow or
session, e.g., RSVP [RFC2205] or NSIS [RFC4080].
The capacity-admitted Realtime-Interactive traffic operation is
similar to an ATM CBR service, which has guaranteed bandwidth and
which, if it stays within the negotiated rate, experiences nominal
delay and no loss.
Either of the above service classes can be configured as EF based by
using a relaxed performance parameter and a rate scheduler.
When a user/endpoint has been authorized to start a new session
(i.e., joins a networked game or logs onto a virtualized
workstation), the admission procedure should have verified that the
newly admitted data rates will be within the engineered capacity of
the Realtime-Interactive service class. The bandwidth in the core
network and the number of simultaneous Realtime-Interactive sessions
that can be supported SHOULD be engineered to control traffic load
for this service.
This service class SHOULD be configured to provide a high assurance
for bandwidth for CS5 PHB, defined in [RFC2474], or CS5-Admit
[ID-DSCP] for guaranteed service through a capacity-admission
signaling protocol. The Realtime-Interactive service class SHOULD be
configured to use a Rate Queuing system such as that defined in
Section 1.4.1.2 of this document. Note that either
Realtime-Interactive PHB MAY be configured as another EF PHB,
specifically CS5-Admit, that uses a relaxed performance parameter
and a rate scheduler, in the priority queue as defined in Section
1.4.1.1 of this document.
The following applications MUST use the Realtime-Interactive service
class:
o Interactive gaming and control.
o Remote Desktop applications
o Virtualized Desktop applications.
o Application server-to-application server non-bursty data transfer
requiring very low delay.
o Inelastic, interactive, time-critical, and mission-critical
applications requiring very low delay.
The following are traffic characteristics:
Polk Expires August 25, 2013 [Page 50]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o Variable size packets.
o Variable rate, though sometimes bursty, which will require
engineering of the network to accommodate.
o Application is sensitive to delay variation between flows and
sessions.
o Lost packets, if any, are usually ignored by application.
RECOMMENDED DSCP marking:
o All non-admitted flows in this service class are marked with CS5
(Class Selector 5).
o All capacity-admitted flows in this service class are marked with
CS5-Admit.
Applications or IP end points SHOULD pre-mark their packets with CS5
or CS5-Admit DSCP value, depending on whether a capacity-admission
signaling protocol is used for a flow. If the end point is not
capable of setting the DSCP value, then the router topologically
closest to the end point SHOULD perform Multifield (MF)
Classification, as defined in [RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in
[RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (application servers inside
administered network) MAY not require policing.
o Policing of packet flows across peering points MUST adhere to the
Service Level Agreement (SLA).
The fundamental service offered to nonadmitted
"Realtime-Interactive" traffic is enhanced best-effort service with
controlled rate and delay. The fundamental service offered to
capacity-admitted "Realtime-Interactive" traffic is a guaranteed
service using in-data-path signaling to ensure expected or timely
delivery. Capacity-admitted Realtime-Interactive service SHOULD NOT
result in packet loss. The service SHOULD be engineered so that CS5
marked packet flows have sufficient bandwidth in the network to
provide high assurance of delivery. Normally, traffic in this
Polk Expires August 25, 2013 [Page 51]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
service class does not respond dynamically to packet loss. As such,
Active Queue Management [RFC2309] SHOULD NOT be applied to CS5
marked packet flows.
4.3. Multimedia Conferencing Service Class
The Multimedia Conferencing service class is for applications that
have a low to medium tolerance to delay, and are rate adaptive to
lost packets in transit from sources. Presentation Data
applications that are operational in conjunction with an audio/video
conference is one good example of such an application. Another set
of applications is application sharing or whiteboarding
applications, also in conjunction to an A/V conference. In either
case, the audio & video part of the flow MUST NOT use the Multimedia
Conferencing service class, rather the more appropriate service
class within the Conversational service group discussed earlier in
Section 4.1.
The Multimedia Conferencing service class will use two PHBs:
Nonadmitted Multimedia Conferencing traffic - MUST use the (new)
MC DSCP [ID-DSCP], and is for traffic that has not had any
capacity admission signaling performed for that flow or
session.
Capacity-Admitted Multimedia Conferencing traffic - MUST use the
(new) MC-Admit DSCP [ID-DSCP], and is for traffic that has
had any capacity admission signaling performed for that flow
or session, e.g., RSVP [RFC2205] or NSIS [RFC4080].
The capacity-admitted Multimedia Conferencing traffic operation is
similar to an ATM CBR service, which has guaranteed bandwidth and
which, if it stays within the negotiated rate, experiences nominal
delay and no loss.
When a user/endpoint initiates a presentation data, application
sharing or whiteboarding session, it will typically be part of an
audio or audio/video conference such as web-conferencing or an
existing Telepresence call. The authorization procedure SHOULD be
controlled through the coordinated effort to bind the A/V call with
the correct Multimedia Conferencing packet flow through some use of
identifiers not in scope of this document. The managed network this
flow traverse and the number of simultaneous Multimedia
Conferencing sessions that can be supported SHOULD be engineered to
control traffic load for this service.
The non-capacity admitted Multimedia Conferencing service class
SHOULD use the new MC PHB, defined in [ID-DSCP]. This service class
SHOULD be configured to provide a high assurance for bandwidth for
CS5 marked packets to ensure that they get forwarded. The
Multimedia Conferencing service class SHOULD be configured to use a
Polk Expires August 25, 2013 [Page 52]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
Rate Queuing system such as that defined in Section 1.4.1.2 of this
document. Note that this service class MAY be configured as another
EF PHB that uses a relaxed performance parameter, a rate scheduler,
and MC-Admit DSCP value, which MUST use the priority queue as
defined in Section 1.4.1.1 of this document.
The following applications MUST use the Multimedia Conferencing
service class:
o Presentation Data applications, which can utilize vector
graphics, raster graphics or video delivery.
o Virtualized Desktop applications.
o Application server-to-application server non-bursty data transfer
requiring very low delay.
The following are traffic characteristics:
o Variable size packets.
o Variable rate, though sometimes bursty, which will require
engineering of the network to accommodate.
o Application is sensitive to delay variation between flows and
sessions.
o Lost packets, if any, can be ignored by the application.
RECOMMENDED DSCP marking:
o All non-admitted flows in this service class are marked with the
new MC DSCP.
o All capacity-admitted flows in this service class are marked with
MC-Admit.
Applications or IP end points SHOULD pre-mark their packets with the
MC DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification, as defined in [RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in
[RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic
Polk Expires August 25, 2013 [Page 53]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (application servers inside
administered network) MAY not require policing.
o Policing of packet flows across peering points MUST adhere to the
Service Level Agreement (SLA).
The fundamental service offered to nonadmitted "Multimedia
Conferencing" traffic is enhanced best-effort service with
controlled rate and delay. The fundamental service offered to
capacity-admitted "Multimedia Conferencing" traffic is a guaranteed
service using in-data-path signaling to ensure expected or timely
delivery. Capacity-admitted Multimedia Conferencing service SHOULD
NOT result in packet loss. The service SHOULD be engineered so that
Multimedia Conferencing marked packet flows have sufficient
bandwidth in the network to provide high assurance of delivery.
Normally, traffic in this service class does not respond dynamically
to packet loss. As such, Active Queue Management [RFC2309] SHOULD
NOT be applied to MC or MC-Admit marked packet flows.
4.4. Multimedia Streaming Service Class
The Multimedia Streaming service class is RECOMMENDED for
applications that require near-real-time packet forwarding of
variable rate elastic traffic sources that are not as delay
sensitive as applications using the Broadcast service class. Such
applications include streaming audio and video, some video (movies)
on-demand applications, and non-interactive webcasts. In general,
the Multimedia Streaming service class assumes that the traffic is
buffered at the source/destination; therefore, it is less sensitive
to delay and jitter.
The Multimedia Streaming service class MUST use the Assured
Forwarding (AF3x) PHB, defined in [RFC2597]. This service class
MUST be configured to provide a minimum bandwidth assurance for
AF31, AF32, and AF33 marked packets to ensure that they get
forwarded. The Multimedia Streaming service class SHOULD be
configured to use Rate Queuing system for AF32 and AF33 traffic
flows, such as that defined in Section 1.4.1.2 of this document.
However, AF31 MUST be designated as the DSCP for use when
capacity-admission signaling has been used, such as RSVP or NSIS, to
guarantee delivery through the network. AF32 and AF33 will be used
for non-admitted streaming flows, as well as overflows from AF31
sources that send more packets than they have negotiated bandwidth
for that call.
The following applications SHOULD use the Multimedia Streaming
service class:
o Buffered streaming audio (unicast).
Polk Expires August 25, 2013 [Page 54]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o Buffered streaming video (unicast).
o Non-interactive Webcasts.
o IP VPN service that specifies two rates and is less sensitive to
delay and jitter.
The following are traffic characteristics:
o Variable size packets.
o The higher the rate, the higher the density of large packets.
o Variable rate.
o Elastic flows.
o Some bursting at start of flow from some applications, as well as
an expected stepping up and down on the rate of the flow based on
changes in resolution due to network conditions.
Applications or IP end points SHOULD pre-mark their packets with
DSCP values as shown below. If the end point is not capable of
setting the DSCP value, then the router topologically closest to the
end point SHOULD perform Multifield (MF) Classification, as defined
in [RFC2475], and mark all packets as AF3x. Note: In this case,
the two-rate, three-color marker will be configured to operate in
Color-Blind mode.
RECOMMENDED DSCP marking:
o AF31 = up to specified rate "A".
o AF32 = all traffic marked AF31 in excess of specified rate "A",
or new AF32 traffic but below specified rate "B".
o AF33 = in excess of specified rate "B".
o Where "A" < "B".
Note: One might expect "A" to approximate the peak rates of sum of
all streaming flows, plus the sum of the mean rates and "B" to
approximate the sum of the peak rates of those same two flows.
RECOMMENDED conditioning performed at DiffServ network edge:
o The two-rate, three-color marker SHOULD be configured to provide
the behavior as defined in trTCM [RFC2698].
o If packets are marked by trusted sources or a previously trusted
DiffServ domain and the color marking is to be preserved, then
Polk Expires August 25, 2013 [Page 55]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
the two-rate, three-color marker SHOULD be configured to operate
in Color-Aware mode.
o If the packet marking is not trusted or the color marking is not
to be preserved, then the two-rate, three-color marker SHOULD be
configured to operate in Color-Blind mode.
The fundamental service offered to nonadmitted "Multimedia
Streaming" traffic is enhanced best-effort service with controlled
rate and delay. The fundamental service offered to
capacity-admitted "Multimedia Streaming" traffic is a guaranteed
service using in-data-path signaling to ensure expected delivery in
a reasonable manner. The service SHOULD be engineered so that AF31
marked packet flows have sufficient bandwidth in the network to
provide high assurance of delivery. Since the AF3x traffic is
elastic and responds dynamically to packet loss, Active Queue
Management [RFC2309] SHOULD be used primarily to reduce forwarding
rate to the minimum assured rate at congestion points, unless AF31
has had a capacity-admission signaling protocol applied to the flow,
such as RSVP or NSIS.
If a capacity-admission signaling protocol applied to the AF31 flow,
which SHOULD be the case always, the AF31 PHB MAY be configured as
another EF PHB that uses a relaxed performance parameter and a rate
scheduler, in the priority queue as defined in Section 1.4.1.1 of
this document.
The probability of loss of AF31 traffic MUST NOT exceed the
probability of loss of AF32 traffic, which in turn MUST NOT exceed
the probability of loss of AF33.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP
is dropped or ECN marked. Thus, in this service class, the
following inequality MUST hold in queue configurations:
o min-threshold AF33 < max-threshold AF33
o max-threshold AF33 <= min-threshold AF32
o min-threshold AF32 < max-threshold AF32
o max-threshold AF32 <= min-threshold AF31
o min-threshold AF31 < max-threshold AF31
o max-threshold AF31 <= memory assigned to the queue
Note#1: this confirmation MUST be modified if AF31 has a
capacity-admission signaling protocol applied to those
flows, and the above will only apply to AF32 and AF33, while
Polk Expires August 25, 2013 [Page 56]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
AF31 (theoretically) has no packet loss.
Note#2: This configuration tends to drop AF33 traffic before AF32
and AF32 before AF31. Note: Many other AQM algorithms exist
and are used; they SHOULD be configured to achieve a similar
result.
4.5. Broadcast Service Class
The Broadcast service class is RECOMMENDED for applications that
require near-real-time packet forwarding with very low packet loss
of constant rate and variable rate inelastic traffic sources that
are more delay sensitive than applications using the Multimedia
Streaming service class. Such applications include broadcast TV,
streaming of live audio and video events, some video-on-demand
applications, and video surveillance. In general, the Broadcast
service class assumes that the destination end point has a dejitter
buffer, for video application usually a 2 - 8 video-frame buffer (66
to several hundred of milliseconds), thus expecting far less
buffering before play-out than Multimedia Streaming, which can
buffer in the seconds to minutes (to hours).
The Broadcast service class will use two PHBs:
Nonadmitted Broadcast traffic - MUST use the CS3 DSCP [RFC2474],
and is for traffic that has not had any capacity admission
signaling performed for that flow or session.
Capacity-Admitted Broadcast traffic - MUST use the CS3-Admit DSCP
[ID-DSCP], and is for traffic that has had any capacity
admission signaling performed for that flow or session, e.g.,
RSVP [RFC2205] or NSIS [RFC4080].
The capacity-admitted Broadcast traffic operation is similar to an
ATM CBR service, which has guaranteed bandwidth and which, if it
stays within the negotiated rate, experiences nominal delay and no
loss.
Either of the above service classes can be configured as EF based by
using a relaxed performance parameter and a rate scheduler.
When a user/endpoint initiates a new Broadcast session (i.e., starts
an Internet radio application, starts a live Internet A/V event or a
camera comes online to do video-surveillance), the admission
procedure should be verified within the application that triggers
the flow. The newly admitted data rates will SHOULD be within the
engineered capacity of the Broadcast service class within that
network. The bandwidth in the core network and the number of
simultaneous Broadcast sessions that can be supported SHOULD be
engineered to control traffic load for this service.
Polk Expires August 25, 2013 [Page 57]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
This service class SHOULD be configured to provide high assurance
for bandwidth for CS3 marked packets to ensure that they get
forwarded. The Broadcast service class SHOULD be configured to use
Rate Queuing system such as that defined in Section 1.4.1.2 of this
document. Note that either Broadcast PHB MAY be configured as
another EF PHB, specifically CS3-Admit, that uses a relaxed
performance parameter and a rate scheduler, in the priority queue as
defined in Section 1.4.1.1 of this document.
The following applications SHOULD use the Broadcast service class:
o Video surveillance and security (unicast).
o TV broadcast including HDTV (likely multicast, but can be
unicast).
o Video on demand (unicast) with control (virtual DVD).
o Streaming of live audio events (both unicast and multicast).
o Streaming of live video events (both unicast and multicast).
The following are traffic characteristics:
o Variable size packets.
o The higher the rate, the higher the density of large packets.
o Mixture of variable rate and constant rate flows.
o Fixed packet emission time intervals.
o Inelastic flows.
RECOMMENDED DSCP marking:
o All non-admitted flows in this service class are marked with CS3
(Class Selector 3).
o All capacity-admitted flows in this service class are marked with
CS3-Admit.
o In some cases, such as those for security and video surveillance
applications, it is NOT RECOMMENDED, but allowed to use a
different DSCP marking.
If so, then locally user definable (EXP/LU) codepoints in the
range '011x11' MAY be used to provide unique traffic
identification. The locally administrator definable (EXP/LU,
from pool 2 of RFC 2474) codepoint(s) MAY be associated with the
PHB that is used for CS3 or CS3-Admit traffic. Furthermore,
depending on the network scenario, additional network edge
Polk Expires August 25, 2013 [Page 58]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
conditioning policy MAY be needed for the EXP/LU codepoint(s)
used.
Applications or IP end points SHOULD pre-mark their packets with CS3
or CS3-Admit DSCP value. If the end point is not capable of setting
the DSCP value, then the router topologically closest to the end
point SHOULD perform Multifield (MF) Classification, as defined in
[RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in
[RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (application servers inside
administered network) MAY not require policing.
o Policing of packet flows across peering points MUST be performed
to the Service Level Agreement (SLA) of those peering entities.
The fundamental service offered to "Broadcast" traffic is enhanced
best-effort service with controlled rate and delay. The fundamental
service offered to capacity-admitted "Broadcast" traffic is a
guaranteed service using in-data-path signaling to ensure expected
or timely delivery. Capacity-admitted Broadcast service SHOULD NOT
result in packet loss. The service SHOULD be engineered so that CS3
and CS3-Admit marked packet flows have sufficient bandwidth in the
network to provide high assurance of delivery. Normally, traffic in
this service class does not respond dynamically to packet loss. As
such, Active Queue Management [RFC2309] SHOULD NOT be applied to
CS3 marked packet flows.
4.6. Low-Latency Data Service Class
The Low-Latency Data service class is RECOMMENDED for elastic and
responsive typically client-/server-based applications.
Applications forwarded by this service class are those that require
a relatively fast response and typically have asymmetrical bandwidth
need, i.e., the client typically sends a short message to the server
and the server responds with a much larger data flow back to the
client. The most common example of this is when a user clicks a
hyperlink (~ few dozen bytes) on a web page, resulting in a new web
page to be loaded (Kbytes or MBs of data). This service class is
configured to provide good response for TCP [RFC1633] short-lived
flows that require real-time packet forwarding of variable rate
Polk Expires August 25, 2013 [Page 59]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
traffic sources.
The Low-Latency Data service class SHOULD use the Assured Forwarding
(AF) PHB, defined in [RFC2597]. This service class SHOULD be
configured to provide a minimum bandwidth assurance for AF21, AF22,
and AF23 marked packets to ensure that they get forwarded. The
Low-Latency Data service class SHOULD be configured to use a Rate
Queuing system such as that defined in Section 1.4.1.2 of this
document.
The following applications SHOULD use the Low-Latency Data service
class:
o Client/server applications.
o Systems Network Architecture (SNA) terminal to host transactions
(SNA over IP using Data Link Switching (DLSw)).
o Web-based transactions (E-commerce).
o Credit card transactions.
o Financial wire transfers.
o Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN).
o VPN service that supports Committed Information Rate (CIR) with
up to two burst sizes.
o Instant Messaging and Presence protocols (e.g., SIP, XMPP).
The following are traffic characteristics:
o Variable size packets.
o Variable packet emission rate.
o With packet bursts of TCP window size.
o Short traffic bursts.
o Source capable of reducing its transmission rate based on
detection of packet loss at the receiver or through explicit
congestion notification.
Applications or IP end points SHOULD pre-mark their packets with
DSCP values as shown below. If the end point is not capable of
setting the DSCP value, then the router topologically closest to the
end point SHOULD perform Multifield (MF) Classification, as defined
in [RFC2475] and mark all packets as AF2x. Note: In this case, the
single-rate, three-color marker will be configured to operate in
Color-Blind mode.
Polk Expires August 25, 2013 [Page 60]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
RECOMMENDED DSCP marking:
o AF21 = flow stream with packet burst size up to "A" bytes.
o AF22 = flow stream with packet burst size in excess of "A" but
below "B" bytes.
o AF23 = flow stream with packet burst size in excess of "B" bytes.
o Where "A" < "B".
RECOMMENDED conditioning performed at DiffServ network edge:
o The single-rate, three-color marker SHOULD be configured to
provide the behavior as defined in srTCM [RFC2697].
o If packets are marked by trusted sources or a previously trusted
DiffServ domain and the color marking is to be preserved, then
the single-rate, three-color marker SHOULD be configured to
operate in Color-Aware mode.
o If the packet marking is not trusted or the color marking is
not to be preserved, then the single-rate, three-color marker
SHOULD be configured to operate in Color-Blind mode.
The fundamental service offered to "Low-Latency Data" traffic is
enhanced best-effort service with controlled rate and delay. The
service SHOULD be engineered so that AF21 marked packet flows have
sufficient bandwidth in the network to provide high assurance of
delivery. Since the AF2x traffic is elastic and responds
dynamically to packet loss, Active Queue Management [RFC2309] SHOULD
be used primarily to control TCP flow rates at congestion points by
dropping packets from TCP flows that have large burst size. The
probability of loss of AF21 traffic MUST NOT exceed the probability
of loss of AF22 traffic, which in turn MUST NOT exceed the
probability of loss of AF23. Explicit Congestion Notification (ECN)
[RFC3168] MAY also be used with Active Queue Management.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP
is dropped or ECN marked. Thus, in this service class, the
following inequality should hold in queue configurations:
o min-threshold AF23 < max-threshold AF23
o max-threshold AF23 <= min-threshold AF22
o min-threshold AF22 < max-threshold AF22
o max-threshold AF22 <= min-threshold AF21
Polk Expires August 25, 2013 [Page 61]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o min-threshold AF21 < max-threshold AF21
o max-threshold AF21 <= memory assigned to the queue
Note: This configuration tends to drop AF23 traffic before AF22 and
AF22 before AF21. Many other AQM algorithms exist and are
used; they should be configured to achieve a similar result.
4.7. Conversational Signaling Service Class
The Signaling service class is MUST be limited to delay-sensitive
signaling traffic only, and then only applying to signaling that
involves the Conversational service group. Audio signaling includes
signaling between IP phone and soft-switch, soft-client and
soft-switch, and media gateway and soft-switch as well as
peer-to-peer using various protocols. Video and Hi-Res signaling
includes video endpoint to video endpoint, as well as to Media
transfer Point (MTP), to call control server(S), etc. This service
class is intended to be used for control of voice and video sessions
and applications. Protocols using this service class require a
relatively fast response, as there are typically several messages of
different sizes sent for control of the session. This service class
is configured to provide good response for short-lived, intermittent
flows that require real-time packet forwarding. This is not the
service class for Instant Messaging (IM), that's within the bounds
of the Low-Latency Data service class. The Conversational Signaling
service class MUST be configured so that the probability of packet
drop or significant queuing delay under peak load is very low in IP
network segments that provide this interface.
The Conversational Signaling service class MUST use the new A/V-Sig
PHB, defined in [ID-DSCP]. This service class MUST be configured to
provide a minimum bandwidth assurance for A/V-Sig marked packets to
ensure that they get forwarded. In other words, this service class
MUST NOT be starved from transmission within a reasonable timeframe,
given that the entire Conversational service group depends on these
signaling messages successful delivery. Network engineering SHOULD
be done to ensure there is roughly 1-4% available per node interface
that audio and video traverse. Local conditions MUST be considered
when determining exactly how much bandwidth is given to this service
class. The Conversational Signaling service class SHOULD be
configured to use a Rate Queuing system such as that defined in
Section 1.4.1.2 of this document.
The following applications SHOULD use the Conversational Signaling
service class:
o Peer-to-peer IP telephony signaling (e.g., SIP, H.323, XMPP).
o Peer-to-peer signaling for multimedia applications (e.g., SIP,
H.323, XMPP).
Polk Expires August 25, 2013 [Page 62]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o Peer-to-peer real-time control function.
o Client-server IP telephony signaling using H.248, MEGACO, MGCP,
IP encapsulated ISDN, or other proprietary protocols.
o Signaling to control IPTV applications using protocols such as
IGMP.
o Signaling flows between high-capacity telephony call servers or
soft switches using protocol such as SIP-T. Such high-capacity
devices may control thousands of telephony (VoIP) calls.
o Signaling for one-way video flows, such as RTSP [RFC2326].
o IGMP, when used for multicast session control such as channel
changing in IPTV systems.
o OPTIONALLY, this service class can be used for on-path
reservation signaling for the traffic flows that will use the
"admitted" DSCPs. The alternative is to have the on-path
signaling (for reservations) use the DSCP within that service
class. This provides a similar treatment of the signaling to the
data flow, which might be desired.
The following are traffic characteristics:
o Variable size packets, normally one packet at a time.
o Intermittent traffic flows.
o Traffic may burst at times.
o Delay-sensitive control messages sent between two end points.
RECOMMENDED DSCP marking:
o All flows in this service class are marked with A/V-Sig.
Applications or IP end points SHOULD pre-mark their packets with
A/V-Sig DSCP value. If the end point is not capable of setting the
DSCP value, then the router topologically closest to the end point
SHOULD perform Multifield (MF) Classification, as defined in
[RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in
[RFC2475].
Polk Expires August 25, 2013 [Page 63]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (application servers inside
administered network) MAY not require policing.
o Policing of packet flows across peering points in which each peer
is participating in the call set-up MUST be performed to the
Service Level Agreement (SLA).
The fundamental service offered to "Conversational Signaling"
traffic is enhanced best-effort service with controlled rate and
delay. The service SHOULD be engineered so that A/V-Sig marked
packet flows have sufficient bandwidth in the network to provide
high assurance of delivery and low delay. Normally, traffic in this
service class does not respond dynamically to packet loss. As such,
Active Queue Management [RFC2309] SHOULD NOT be applied to A/V-Sig
marked packet flows.
4.8. High-Throughput Data Service Class
The High-Throughput Data service class is RECOMMENDED for elastic
applications that require timely packet forwarding of variable rate
traffic sources and, more specifically, is configured to provide
good throughput for TCP longer-lived flows. TCP [RFC1633] or a
transport with a consistent Congestion Avoidance Procedure [RFC2581]
[RFC3782] normally will drive as high a data rate as it can obtain
over a long period of time. The FTP protocol is a common example,
although one cannot definitively say that all FTP transfers are
moving data in bulk.
The High-Throughput Data service class SHOULD use the Assured
Forwarding (AF) PHB, defined in [RFC2597]. This service class
SHOULD be configured to provide a minimum bandwidth assurance for
AF11, AF12, and AF13 marked packets to ensure that they are
forwarded in a timely manner. The High-Throughput Data service
class SHOULD be configured to use a Rate Queuing system such as that
defined in Section 1.4.1.2 of this document.
The following applications SHOULD use the High-Throughput Data
service class:
o Store and forward applications.
o File transfer applications (e.g., FTP, HTTP, etc).
o Email.
o VPN service that supports two rates (committed information rate
Polk Expires August 25, 2013 [Page 64]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
and excess or peak information rate).
The following are traffic characteristics:
o Variable size packets.
o Variable packet emission rate.
o Variable rate.
o With packet bursts of TCP window size.
o Source capable of reducing its transmission rate based on
detection of packet loss at the receiver or through explicit
congestion notification.
Applications or IP end points SHOULD pre-mark their packets with
DSCP values as shown below. If the end point is not capable of
setting the DSCP value, then the router topologically closest to the
end point SHOULD perform Multifield (MF) Classification, as defined
in [RFC2475], and mark all packets as AF1x. Note: In this case, the
two-rate, three-color marker will be configured to operate in
Color-Blind mode.
RECOMMENDED DSCP marking:
o AF11 = up to specified rate "A".
o AF12 = in excess of specified rate "A" but below specified rate
"B".
o AF13 = in excess of specified rate "B".
o Where "A" < "B".
RECOMMENDED conditioning performed at DiffServ network edge:
o The two-rate, three-color marker SHOULD be configured to provide
the behavior as defined in trTCM [RFC2698].
o If packets are marked by trusted sources or a previously trusted
DiffServ domain and the color marking is to be preserved, then
the two-rate, three-color marker SHOULD be configured to operate
in Color-Aware mode.
o If the packet marking is not trusted or the color marking is not
to be preserved, then the two-rate, three-color marker SHOULD be
configured to operate in Color-Blind mode.
The fundamental service offered to "High-Throughput Data" traffic is
enhanced best-effort service with a specified minimum rate. The
service SHOULD be engineered so that AF11 marked packet flows have
Polk Expires August 25, 2013 [Page 65]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
sufficient bandwidth in the network to provide assured delivery. It
can be assumed that this class will consume any available bandwidth
and that packets traversing congested links may experience higher
queuing delays or packet loss. Since the AF1x traffic is elastic
and responds dynamically to packet loss, Active Queue Management
[RFC2309] SHOULD be used primarily to control TCP flow rates at
congestion points by dropping packets from TCP flows that have
higher rates first. The probability of loss of AF11 traffic MUST
NOT exceed the probability of loss of AF12 traffic, which in turn
MUST NOT exceed the probability of loss of AF13. In such a case, if
one network customer is driving significant excess and another seeks
to use the link, any losses will be experienced by the high-rate
user, causing him to reduce his rate. Explicit Congestion
Notification (ECN) [RFC3168] MAY also be used with Active Queue
Management.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP
is dropped or ECN marked. Thus, in this service class, the
following inequality should hold in queue configurations:
o min-threshold AF13 < max-threshold AF13
o max-threshold AF13 <= min-threshold AF12
o min-threshold AF12 < max-threshold AF12
o max-threshold AF12 <= min-threshold AF11
o min-threshold AF11 < max-threshold AF11
o max-threshold AF11 <= memory assigned to the queue
Note: This configuration tends to drop AF13 traffic before AF12 and
AF12 before AF11. Many other AQM algorithms exist and are
used; they should be configured to achieve a similar result.
4.9. Standard Service Class
The Standard service class is RECOMMENDED for traffic that has not
been classified into one of the other supported forwarding service
classes in the DiffServ network domain. This service class provides
the Internet's "best-effort" forwarding behavior. This service
class typically has minimum bandwidth guarantee.
The Standard service class MUST use the Default Forwarding (DF) PHB,
defined in [RFC2474], and SHOULD be configured to receive at least a
small percentage of forwarding resources as a guaranteed minimum.
This service class SHOULD be configured to use a Rate Queuing system
such as that defined in Section 1.4.1.2 of this document.
Polk Expires August 25, 2013 [Page 66]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
The following applications SHOULD use the Standard service class:
o Network services, DNS, DHCP, BootP.
o Any undifferentiated application/packet flow transported through
the DiffServ enabled network.
The following is a traffic characteristic:
o Non-deterministic, mixture of everything.
The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'.
Network Edge Conditioning:
There is no requirement that conditioning of packet flows be
performed for this service class.
The fundamental service offered to the Standard service class is
best-effort service with active queue management to limit overall
delay. Typical configurations SHOULD use random packet dropping to
implement Active Queue Management [RFC2309] or Explicit Congestion
Notification [RFC3168], and MAY impose a minimum or maximum rate on
the queue.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth, and the max-threshold specifies the
queue depth above which all traffic is dropped or ECN marked. Thus,
in this service class, the following inequality should hold in queue
configurations:
o min-threshold DF < max-threshold DF
o max-threshold DF <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result.
4.10. Low-Priority Data
The Low-Priority Data service class serves applications that run
over TCP [RFC0793] or a transport with consistent congestion
avoidance procedures [RFC2581] [RFC3782] and that the user is
willing to accept service without guarantees. This service class is
specified in [RFC3662] and [QBSS].
The following applications MAY use the Low-Priority Data service
class:
o Any TCP based-application/packet flow transported through the
DiffServ enabled network that does not require any bandwidth
assurances.
Polk Expires August 25, 2013 [Page 67]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
The following is a traffic characteristic:
o Non-real-time and elastic.
Network Edge Conditioning:
There is no requirement that conditioning of packet flows be
performed for this service class.
The RECOMMENDED DSCP marking is CS1 (Class Selector 1).
The fundamental service offered to the Low-Priority Data service
class is best-effort service with zero bandwidth assurance. By
placing it into a separate queue or class, it may be treated in a
manner consistent with a specific Service Level Agreement.
Typical configurations SHOULD use Explicit Congestion Notification
[RFC3168] or random loss to implement Active Queue Management
[RFC2309].
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth, and the max-threshold specifies the
queue depth above which all traffic is dropped or ECN marked. Thus,
in this service class, the following inequality should hold in queue
configurations:
o min-threshold CS1 < max-threshold CS1
o max-threshold CS1 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result.
5. Additional Information on Service Class Usage
In this section, we provide additional information on how some
specific applications should be configured to use the defined
service classes.
5.1. Mapping for NTP
From tests that were performed, indications are that precise time
distribution requires a very low packet delay variation (jitter)
transport. Therefore, we suggest that the following guidelines for
Network Time Protocol (NTP) be used:
o When NTP is used for providing high-accuracy timing within an
administrator's (carrier's) network or to end users/clients, the
audio service class SHOULD be used, and NTP packets should be
marked with EF DSCP value.
Polk Expires August 25, 2013 [Page 68]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
o For applications that require "wall clock" timing accuracy, the
Standard service class should be used, and packets should be
marked with DF DSCP.
5.2. VPN Service Mapping
"Differentiated Services and Tunnels" [RFC2983] considers the
interaction of DiffServ architecture with IP tunnels of various
forms. Further to guidelines provided in RFC 2983, below are
additional guidelines for mapping service classes that are supported
in one part of the network into a VPN connection. This discussion
is limited to VPNs that use DiffServ technology for traffic
differentiation.
o The DSCP value(s) that is/are used to represent a PHB or a PHB
group SHOULD be the same for the networks at both ends of the VPN
tunnel, unless remarking of DSCP is done as ingress/egress
processing function of the tunnel. DSCP marking needs to be
preserved along the tunnel, end to end.
o The VPN MAY be configured to support one or more service classes.
It is left up to the administrators of the two networks to agree
on the level of traffic differentiation that will be provided in
the network that supports VPN service. Service classes are then
mapped into the supported VPN traffic forwarding behaviors that
meet the traffic characteristics and performance requirements of
the encapsulated service classes.
o The traffic treatment in the network that is providing the VPN
service needs to be such that the encapsulated service class or
classes receive comparable behavior and performance in terms of
delay, jitter, and packet loss and that they are within the
limits of the service specified.
o The DSCP value in the external header of the packet forwarded
through the network providing the VPN service can be different
from the DSCP value that is used end to end for service
differentiation in the end network.
o The guidelines for aggregation of two or more service classes
into a single traffic forwarding treatment in the network that is
providing the VPN service is for further study.
6. Security Considerations
This document discusses policy and describes a common policy
configuration, for the use of a Differentiated Services Code Point
by transports and applications. If implemented as described, it
should require that the network do nothing that the network has not
already allowed. If that is the case, no new security issues should
arise from the use of such a policy.
Polk Expires August 25, 2013 [Page 69]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
It is possible for the policy to be applied incorrectly, or for a
wrong policy to be applied in the network for the defined service
class. In that case, a policy issue exists that the network SHOULD
detect, assess, and deal with. This is a known security issue in
any network dependent on policy-directed behavior.
A well-known flaw appears when bandwidth is reserved or enabled for
a service (for example, voice and/or video transport) and another
service or an attacking traffic stream uses it. This possibility is
inherent in DiffServ technology, which depends on appropriate packet
markings. When bandwidth reservation or a priority queuing system is
used in a vulnerable network, the use of authentication and flow
admission is recommended. To the author's knowledge, there is no
known technical way to respond to an unauthenticated data stream
using service that it is not intended to use, and such is the nature
of the Internet.
The use of a service class by a user is not an issue when the SLA
between the user and the network permits him to use it, or to use it
up to a stated rate. In such cases, simple policing is used in the
Differentiated Services Architecture. Some service classes, such as
Network Control, are not permitted to be used by users at all; such
traffic should be dropped or remarked by ingress filters. Where
service classes are available under the SLA only to an authenticated
user rather than to the entire population of users, authentication
and authorization services are required, such as those surveyed in
[AUTHMECH].
7. Contributing Authors
This section specifically calls out the authors of RFC 4594, from
which this document is based on.
Jozef Babiarz
Nortel Networks
Kwok Ho Chan
Nortel Networks
Email: khchan.work@gmail.com
Fred Baker
Cisco Systems
EMail: fred@cisco.com
Of note, two of the three mentioned authors above worked for Nortel
Networks at the time of writing RFC 4594, a company that no longer
exists. This author has not seen or heard from those two in many,
many years or IETF meetings - as a result of not knowing their new
email addresses (or phone numbers).
While much of this document has been rewritten with either edited or
Polk Expires August 25, 2013 [Page 70]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
brand new material, there are many short paragraphs that remain as
they were from RFC 4594, as well as many sentences that were also
left unchanged. Additionally, there were no new graphs, charts,
diagrams, or tables introduced, meaning the first 4 tables within
this document existed in RFC 4594, created by those authors.
Presently, each of those tables contain modified and new
information. The last 3 tables, specifically tables 5, 6, & 7 were
removed because the examples section was removed.
This author believes there must be proper credit given for all the
contributions, including the framework this document retains from
that RFC. Periodically, throughout this document, what was written
remains the best way of conveying a thought, rule, or otherwise
stated behavior or mechanism. Because RFC 4594 was rather large,
there is no realistic way of identifying each part that was left
untouched. Further, properly quoting that RFC and leaving those
sentences embedded in this document would render this document
highly unreadable. Another application could be used to show the
changes, deletions and additions - but not one that the IETF accepts
presently.
This author has created this "Contributing Authors" section as a way
of properly identifying those 3 individuals that provided text
within this document. We will let the community judge if this is
'good enough' (i.e., rough consensus), or if another way is better.
8. Acknowledgements
The author would like to thank Paul Jones, Glen Lavers, Mo Zanaty,
David Benham, Michael Ramalho, Gorry Fairhurst, David Black, Brian
Carpenter, Al Morton, Ruediger Geib and Shitanshu Shah for their
comments and questions about this effort that ultimately helped
shape this document.
Below are the folks that were acknowledged in RFC 4594, and this
author does not want to lose their recognition of contributions to
the original effort.
"The authors thank the TSVWG reviewers, David Black, Brian E.
Carpenter, and Alan O'Neill for their review and input to this
document.
The authors acknowledge a great many inputs, most notably from
Bruce Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois
Audet, Morgan Littlewood, Robert Milne, John Shuler, Nalin
Mistry, Al Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil
Dickinson, Mike Fidler, and Shane Amante. Kimberly King, Joe
Zebarth, and Alistair Munroe each did a thorough proofreading,
Polk Expires August 25, 2013 [Page 71]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
and the document is better for their contributions."
9. References
9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
Polk Expires August 25, 2013 [Page 72]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
RFC 3662, December 2003.
[RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code
Point (DSCP) for Capacity-Admitted Traffic", RFC 5865,
May 2010
9.2. Informative References
[AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms",
Work in Progress, September 2005.
[QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2
Technical Report Proposed Service Definition, March 2001.
[IEEE1Q] IEEE, 802.1Q Specification
[IEEE1E] IEEE, 802.1E Wireless LAN User Priority Specification
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", RFC
1633, June 1994.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, September 1999.
[RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive
Shaper for Differentiated Services", RFC 2963, October
2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules
for their Specification", RFC 3086, April 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
Polk Expires August 25, 2013 [Page 73]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
3168, September 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC
3175, September 2001.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290,
May 2002.
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP's Fast Recovery Algorithm", RFC 3782,
April 2004.
[RFC5462] L. Andersson, R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: EXP Field Renamed to Traffic Class
Field", RFC 5462, February 2009
Authors' Address
James Polk
3913 Treemont Circle
Colleyville, Texas 76034
Phone: +1.817.271.3552
Email: jmpolk@cisco.com
Appendix A - Changes
Here is a list of all the changes that were captured during the
editing process. This will not be a complete list, and others are
free to point out what the authors missed, and we'll include that in
the next release.
A.1 Since Individual -02 to -03
o Inserted section 1.6 to explain fundamentally what has changed
since RFC 4594, and why changes are necessary.
A.2 Since Individual -01 to -02
o Added text to the Intro section on the justification from
DiffServ Problem Statement draft, as to more of why this update
is necessary.
o Added text to the Intro section expanding on the concept of
service classes vs. treatment aggregates (from RFC 5127).
Polk Expires August 25, 2013 [Page 74]
Internet-Draft Std Config. for DiffServ Service Classes Feb 2013
A.3 Since Individual -00 to -01
o Added Section 2.4 which covers the conflation issues regarding
the differences between service classes and treatment aggregates.
o Added example operational configurations of treatment aggregates
applied to this draft's new set of service classes and additional
DSCPs.
o Added references RFC 5865, RFC 5462, IEEE 802.1E and IEEE 802.1Q.
A.4 Since RFC 4594 to Individual Update -00
o rewrote Intro to emphasize current topics
o Created a Conversational Service group, comprising the audio,
video and Hi-Res service classes - because they have similar
characteristics.
o Incorporated the 6 new DSCPs from [ID-DSCP].
o moved the example section, en mass, to an appendix that might not
be kept for this version. We're not sure it accomplishes what it
needs to, and might not provide any real usefulness.
o Moved 'Realtime-Interactive' service class to CS5, from CS4
o Changed 'Broadcast Video' service class to 'Broadcast' service
class
o Changed AF4X to 'Video' service class, replacing 'Multimedia
Conferencing' service class
o Moved 'Multimedia Conferencing' service class to different DSCPs
o Added the 'Hi-Res' service class
o Removed section 5.1 on signaling choices. It has been included in
the main body of the text.
o Changed document title
o ...
Polk Expires August 25, 2013 [Page 74]
