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) (telephony) or video
conferencing services can benefit from use of an admission control
mechanism, as generally the telephony service is configured with
over-subscription, meaning that some users may not be able to make a
call during peak periods.
For VoIP (telephony) service, a common approach is to use signaling
protocols such as SIP, H.323, H.248, MEGACO, and 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. Many RTP voice
payloads are inelastic and cannot react to loss or delay in any
substantive way. For these voice payloads, the network SHOULD police
at ingress to ensure that the voice traffic stays within its
negotiated bounds. Having thus assured a predictable input rate, the
network may use a priority queue to ensure nominal delay and
variation in delay.
Another approach that may be used in small and bandwidth-constrained
networks for limited number of flows is RSVP [RFC2205] [RFC2996].
However, there is concern with the scalability of this solution in
large networks where aggregation of reservations [RFC3175] is
considered to be required.
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 Telephony service class is best suited for applications that
require very low delay variation and are of constant rate, such as
IP telephony (VoIP) and circuit emulation over IP applications.
o Signaling service class is best suited for peer-to-peer and
client-server signaling and control functions using protocols such
as SIP, SIP-T, H.323, H.248, and Media Gateway Control Protocol
(MGCP).
o Multimedia Conferencing service class is best suited for
applications that require very low delay and have the ability to
change encoding rate (rate adaptive), such as H.323/V2 and later
video conferencing service.
o Real-Time Interactive service class is intended for interactive
variable rate inelastic applications that require low jitter and
loss and very low delay, such as interactive gaming applications
that use RTP/UDP streams for game control commands, and video
conferencing applications that do not have the ability to change
encoding rates or to mark packets with different importance
indications.
o Multimedia Streaming service class is best suited for variable
rate elastic streaming media applications where a human is waiting
for output and where the application has the capability to react
to packet loss by reducing its transmission rate, such as
streaming video and audio and webcast.
o Broadcast Video service class is best suited for inelastic
streaming media applications that may be of constant or variable
rate, requiring low jitter and very low packet loss, such as
broadcast TV and live events, video surveillance, and security.
o Low-Latency Data service class is best suited for data processing
applications where a human is waiting for output, such as web-
based ordering or an Enterprise Resource Planning (ERP)
application.
o High-Throughput Data service class is best suited for store and
forward applications such as FTP and billing record transfer.
o Standard service class is for traffic that has not been identified
as requiring differentiated treatment and is normally referred to
as best effort.
o Low-Priority Data service class is intended for packet flows where
bandwidth assurance is not required.
2.2. Categorization of User Service Classes
The ten defined user/subscriber service classes listed above can be
grouped into a small number of application categories. For some
application categories, it was felt that more than one service class
was needed to provide service differentiation within that category
due to the different traffic characteristic of the applications,
control function, and the required flow behavior. Figure 1 provides
a summary of service class grouping into four application categories.
Application Control Category
o The Signaling service class is intended to be used to control
applications or user endpoints. Examples of protocols that would
use this service class are SIP or H.248 for IP telephone service
and SIP or Internet Group Management Protocol (IGMP) for control
of broadcast TV service to subscribers. Although user signaling
flows have similar performance requirements as Low-Latency Data,
they need to be distinguished and marked with a different DSCP.
The essential distinction is something like "administrative
control and management" of the traffic affected as the protocols
in this class tend to be tied to the media stream/session they
signal and control.
Media-Oriented Category
Due to the vast number of new (in process of being deployed) and
already-in-use media-oriented services in IP networks, five service
classes have been defined.
o Telephony service class is intended for IP telephony (VoIP)
service. It may also be used for other applications that meet the
defined traffic characteristics and performance requirements.
o Real-Time Interactive service class is intended for inelastic
video flows from applications such as SIP-based desktop video
conferencing applications and for interactive gaming.
o Multimedia Conferencing service class is for video conferencing
solutions that have the ability to reduce their transmission rate
on detection of congestion. These flows can therefore be
classified as rate adaptive. As currently two types of video
conferencing equipment are used in IP networks (ones that generate
inelastic traffic and ones that generate rate-adaptive traffic),
two service class are needed. The Real-Time Interactive service
class should be used for equipment that generates inelastic video
flows and the Multimedia Conferencing service class for equipment
that generates rate-adaptive video flows.
o Broadcast Video service class is to be used for inelastic traffic
flows, which are intended for broadcast TV service and for
transport of live video and audio events.
o Multimedia Streaming service class is to be used for elastic
multimedia traffic flows. This multimedia content is typically
stored before being transmitted. It is also buffered at the
receiving end before being played out. The buffering is
sufficiently large to accommodate any variation in transmission
rate that is encountered in the network. Multimedia entertainment
over IP delivery services that are being developed can generate
both elastic and inelastic traffic flows; therefore, two service
classes are defined to address this space, respectively:
Multimedia Streaming and Broadcast Video.
Data Category
The data category is divided into three service classes.
o Low-Latency Data for applications/services that require low delay
or latency for bursty but short-lived flows.
o High-Throughput Data for applications/services that require good
throughput for long-lived bursty flows. High Throughput and
Multimedia Steaming are close in their traffic flow
characteristics with High Throughput being a bit more bursty and
not as long-lived as Multimedia Streaming.
o Low-Priority Data for applications or services that can tolerate
short or long interruptions of packet flows. The Low-Priority
Data service class can be viewed as "don’t care" to some degree.
Best-Effort Category
o All traffic that is not differentiated in the network falls into
this category and is mapped into the Standard service class. If a
packet is marked with a DSCP value that is not supported in the
network, it SHOULD be forwarded using the Standard service class.
Figure 1, below, provides a grouping of the defined user/subscriber
service classes into four categories, with indications of which ones
use an independent flow for signaling or control; type of flow
behavior (elastic, rate adaptive, or inelastic); and the last column
provides end user Quality of Service (QoS) rating as defined in ITU-T
Recommendation G.1010.
-----------------------------------------------------------------
| Application | Service | Signaled | Flow | G.1010 |
| Categories | Class | | Behavior | Rating |
|-------------+---------------+----------+-----------+------------|
| Application | Signaling | Not | Inelastic | Responsive |
| Control | |applicable| | |
|-------------+---------------+----------+-----------+------------|
| | Telephony | Yes | Inelastic | Interactive|
| |---------------+----------+-----------+------------|
| | Real-Time | Yes | Inelastic | Interactive|
| | Interactive | | | |
| |---------------+----------+-----------+------------|
| Media- | Multimedia | Yes | Rate | Interactive|
| Oriented | Conferencing | | Adaptive | |
| |---------------+----------+-----------+------------|
| |Broadcast Video| Yes | Inelastic | Responsive |
| |---------------+----------+-----------+------------|
| | Multimedia | Yes | Elastic | Timely |
| | Streaming | | | |
|-------------+---------------+----------+-----------+------------|
| | Low-Latency | No | Elastic | Responsive |
| | Data | | | |
| |---------------+----------+-----------+------------|
| Data |High-Throughput| No | Elastic | Timely |
| | Data | | | |
| |---------------+----------+-----------+------------|
| | Low-Priority | No | Elastic |Non-critical|
| | Data | | | |
|-------------+---------------+----------+-----------+------------|
| Best Effort | Standard | Not Specified |Non-critical|
-----------------------------------------------------------------
Figure 1. User/Subscriber Service Classes Grouping
Here is a short explanation of the end user QoS category as defined
in ITU-T Recommendation G.1010. User traffic is divided into four
different categories, namely, interactive, responsive, timely, and
non-critical. An example of interactive traffic is between two
humans and is most sensitive to delay, loss, and jitter. Another
example of interactive traffic is between two servers where very low
delay and loss are needed. Responsive traffic is typically between a
human and a server but can also be between two servers. Responsive
traffic is less affected by jitter and can tolerate longer delays
than interactive traffic. Timely traffic is either between servers
or servers and humans and the delay tolerance is significantly longer
than responsive traffic. Non-critical traffic is normally between
servers/machines where delivery may be delay for period of time.
2.3. Service Class Characteristics
This document provides guidelines for network administrators in
configuring their network for the level of service differentiation
that is appropriate in their network to meet their QoS needs. It is
expected that network operators will configure and provide in their
networks a subset of the defined service classes. Our intent is to
provide guidelines for configuration of Differentiated Services for a
wide variety of applications, services, and network configurations.
In addition, network administrators may choose to define and deploy
other service classes in their network.
Figure 2 provides a behavior view for traffic serviced by each
service class. The traffic characteristics column defines the
characteristics and profile of flows serviced, and the tolerance to
loss, delay, and jitter columns define the treatment the flows will
receive. End-to-end quantitative performance requirements may be
obtained from ITU-T Recommendations Y.1541 and Y.1540.
-------------------------------------------------------------------
|Service Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+==============================+======+======+======|
| Network |Variable size packets, mostly | | | |
| Control |inelastic short messages, but | Low | Low | Yes |
| | traffic can also burst (BGP) | | | |
|---------------+------------------------------+------+------+------|
| | Fixed-size small packets, | Very | Very | Very |
| Telephony | constant emission rate, | Low | Low | Low |
| | inelastic and low-rate flows | | | |
|---------------+------------------------------+------+------+------|
| Signaling | Variable size packets, some | Low | Low | Yes |
| | what bursty short-lived flows| | | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, | Low | Very | |
| Conferencing | constant transmit interval, | - | Low | Low |
| |rate adaptive, reacts to loss |Medium| | |
|---------------+------------------------------+------+------+------|
| Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low |
| Interactive | mostly variable rate | | Low | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, |Low - |Medium| Yes |
| Streaming | elastic with variable rate |Medium| | |
|---------------+------------------------------+------+------+------|
| Broadcast | Constant and variable rate, | Very |Medium| Low |
| Video | inelastic, non-bursty flows | Low | | |
|---------------+------------------------------+------+------+------|
| Low-Latency | Variable rate, bursty short- | Low |Low - | Yes |
| Data | lived elastic flows | |Medium| |
|---------------+------------------------------+------+------+------|
| OAM | Variable size packets, | Low |Medium| Yes |
| | elastic & inelastic flows | | | |
|---------------+------------------------------+------+------+------|
|High-Throughput| Variable rate, bursty long- | Low |Medium| Yes |
| Data | lived elastic flows | |- High| |
|---------------+------------------------------+------+------+------|
| Standard | A bit of everything | Not Specified |
|---------------+------------------------------+------+------+------|
| Low-Priority | Non-real-time and elastic | High | High | Yes |
| Data | | | | |
-------------------------------------------------------------------
Figure 2. Service Class Characteristics
Notes for Figure 2: A "Yes" in the jitter-tolerant column implies
that data is buffered in the endpoint and that a moderate level of
network-induced variation in delay will not affect the application.
Applications that use TCP as a transport are generally good examples.
Routing protocols and peer-to-peer signaling also fall in this class;
although loss can create problems in setting up calls, a moderate
level of jitter merely makes call placement a little less predictable
in duration.
Service classes indicate the required traffic forwarding treatment in
order to meet user, application, or network expectations. Section 3
defines the service classes that MAY be used for forwarding network
control traffic, and Section 4 defines the service classes that MAY
be used for forwarding user traffic with examples of intended
application types mapped into each service class. Note that the
application types are only examples and are not meant to be all-
inclusive or prescriptive. Also, note that the service class naming
or ordering does not imply any priority ordering. They are simply
reference names that are used in this document with associated QoS
behaviors that are optimized for the particular application types
they support. Network administrators MAY choose to assign different
service class names to the service classes that they will support.
Figure 3 defines the RECOMMENDED relationship between service classes
and DS codepoint assignment with application examples. It is
RECOMMENDED that this relationship be preserved end to end.
------------------------------------------------------------------
| Service | DSCP | DSCP | Application |
| Class Name | Name | Value | Examples |
|===============+=========+=============+==========================|
|Network Control| CS6 | 110000 | Network routing |
|---------------+---------+-------------+--------------------------|
| Telephony | EF | 101110 | IP Telephony bearer |
|---------------+---------+-------------+--------------------------|
| Signaling | CS5 | 101000 | IP Telephony signaling |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF41,AF42|100010,100100| H.323/V2 video |
| Conferencing | AF43 | 100110 | conferencing (adaptive) |
|---------------+---------+-------------+--------------------------|
| Real-Time | CS4 | 100000 | Video conferencing and |
| Interactive | | | Interactive gaming |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF31,AF32|011010,011100| Streaming video and |
| Streaming | AF33 | 011110 | audio on demand |
|---------------+---------+-------------+--------------------------|
|Broadcast Video| CS3 | 011000 |Broadcast TV & live events|
|---------------+---------+-------------+--------------------------|
| Low-Latency |AF21,AF22|010010,010100|Client/server transactions|
| Data | AF23 | 010110 | Web-based ordering |
|---------------+---------+-------------+--------------------------|
| OAM | CS2 | 010000 | OAM&P |
|---------------+---------+-------------+--------------------------|
|High-Throughput|AF11,AF12|001010,001100| Store and forward |
| Data | AF13 | 001110 | applications |
|---------------+---------+-------------+--------------------------|
| Standard | DF (CS0)| 000000 | Undifferentiated |
| | | | applications |
|---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
Figure 3. DSCP to Service Class Mapping
Notes for Figure 3: Default Forwarding (DF) and Class Selector 0
(CS0) provide equivalent behavior and use the same DS codepoint,
’000000’.
It is expected that network administrators will base their choice of
the service classes that they will support on their need, starting
off with three or four service classes for user traffic and adding
others as the need arises.
Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD be
used for the defined service classes that are further detailed in
Sections 3 and 4 of this document. According to what
applications/services need to be differentiated, network