One document matched: draft-baker-diffserv-basic-classes-02.txt
Differences from draft-baker-diffserv-basic-classes-01.txt
Non F. Baker
Internet-Draft Cisco Systems
Expires: August 13, 2004 J. Babiarz
K. Chan
Nortel Networks
February 13, 2004
Configuration Guidelines for DiffServ Service Classes
draft-baker-diffserv-basic-classes-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 13, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This paper summarizes the recommended correlation between service
classes and their usage, with references to their corresponding
recommended Differentiated Service Code Points (DSCP), traffic
conditioners, Per-Hop Behaviors (PHB) and Active Queue Management
(AQM) mechanisms. There is no intrinsic requirement that particular
DSCPs, traffic conditioner PHBs and AQM be used for a certain service
class, but as a policy it is useful that they be applied consistently
across the network.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Baker, et al. Expires August 13, 2004 [Page 1]
Internet-Draft Document February 2004
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Expected use in the Network . . . . . . . . . . . . . . . 3
1.2 Key Differentiated Services Concepts . . . . . . . . . . . 4
1.2.1 Queuing . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1.1 Priority Queuing . . . . . . . . . . . . . . . . . . . . . 4
1.2.1.2 Rate Queuing . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.2 Active Queue Management . . . . . . . . . . . . . . . . . 5
1.2.3 Traffic Conditioning . . . . . . . . . . . . . . . . . . . 5
1.2.4 Differentiated Services Code Point (DSCP) . . . . . . . . 6
1.2.5 Per-Hop Behavior (PHB) . . . . . . . . . . . . . . . . . . 6
1.3 Key Service Concepts . . . . . . . . . . . . . . . . . . . 6
1.3.1 Default Forwarding (DF) . . . . . . . . . . . . . . . . . 7
1.3.2 Assured Forwarding (AF) . . . . . . . . . . . . . . . . . 8
1.3.3 Expedited Forwarding (EF) . . . . . . . . . . . . . . . . 8
1.3.4 Class Selector (CS) . . . . . . . . . . . . . . . . . . . 9
1.3.5 Admission Control . . . . . . . . . . . . . . . . . . . . 9
1.3.6 Service Differentiation . . . . . . . . . . . . . . . . . 10
2. Traffic Categories and Service Classes . . . . . . . . . . 10
2.1 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 14
2.2 Service Classes and Behavior Aggregates . . . . . . . . . 16
2.3 Issues with Aggregation . . . . . . . . . . . . . . . . . 17
3. Network Control Traffic Category . . . . . . . . . . . . . 18
3.1 Administrative Service Class . . . . . . . . . . . . . . . 18
3.2 Network Control Service Class . . . . . . . . . . . . . . 19
4. User Traffic Categories . . . . . . . . . . . . . . . . . 21
4.1 Interactive Traffic Category . . . . . . . . . . . . . . . 22
4.1.1 Telephony Service Class . . . . . . . . . . . . . . . . . 22
4.1.2 Multimedia Conferencing Service Class . . . . . . . . . . 24
4.2 Responsive Traffic Category . . . . . . . . . . . . . . . 26
4.2.1 Multimedia Streaming Service Class . . . . . . . . . . . . 26
4.2.2 Low Latency Data Service Class . . . . . . . . . . . . . . 29
4.3 Timely Traffic Category . . . . . . . . . . . . . . . . . 31
4.3.1 High Throughput Data Service Class . . . . . . . . . . . . 31
4.3.2 Standard Service Class . . . . . . . . . . . . . . . . . . 33
4.4 Non Critical Traffic Catgegory . . . . . . . . . . . . . . 34
4.4.1 Low Priority Data . . . . . . . . . . . . . . . . . . . . 34
5. Mapping Applications to Service Classes . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . . 36
7. Achnoledgements . . . . . . . . . . . . . . . . . . . . . 36
Normative References . . . . . . . . . . . . . . . . . . . 36
Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . 40
Baker, et al. Expires August 13, 2004 [Page 2]
Internet-Draft Document February 2004
1. Introduction
This paper summarizes the recommended correlation between service
classes and their usage, with references to their corresponding
recommended Differentiated Service Code Points (DSCP), traffic
conditioners, Per-Hop Behaviors (PHB) and Active Queue Management
(AQM) mechanisms. There is no intrinsic requirement that particular
DSCPs, traffic conditioner PHBs and AQM be used for a certain service
class, but as a policy it is useful that they be applied consistently
across the network.
Service classes are defined, based on the different traffic
characteristics and required performance of the applications/
services. This approach allows us to map current and future
applications/services of similar traffic characteristic and
performance requirements into the same service class. With this
approach, a limited set of service classes is required. For
completeness, we have defined nine different service classes, two for
network operation/administration and seven for user/subscriber
applications/services. However, we expect that network administrators
will selectively choose the service classes that are required in
their network based on their needs.
1.1 Expected use in the Network
In the Internet today, corporate LANs and ISP WANs are generally not
heavily utilized - they are commonly 10% utilized at most. For this
reason, congestion, loss, and variation in delay within corporate
LANs and ISP backbones is virtually unknown. This clashes with user
perceptions, for three very good reasons.
o The industry moves through cycles of bandwidth boom and bandwidth
bust, depending on prevailing market conditions and the periodic
deployment of new bandwidth-hungry applications.
o In access networks, the state is often different. This may be
because throughput rates are artificially limited, or are over
subscribe, or because of access network design trade-offs.
o Other characteristics, such as database design on web servers
(that may create contention points, e.g. in filestore), and
configuration of firewalls and routers, often look externally like
a bandwidth limitation.
The intent of this document is to provide a consistent marking,
conditioning and packet treatment strategy so that it can be
configured and put into service on any link which itself is
congested.
Baker, et al. Expires August 13, 2004 [Page 3]
Internet-Draft Document February 2004
1.2 Key Differentiated Services Concepts
The reader must be familiar with the principles of the Differentiated
Services Architecture RFC 2475 [9]. However, we recapitulate key
concepts here to save searching.
1.2.1 Queuing
A queue is a data structure that holds traffic that is awaiting
transmission. The traffic may be delayed while in the queue, possibly
due to lack of bandwidth, or because it is low in priority. There are
a number of ways to implement a queue; in some of these, it is more
natural to discuss "service classes in a queuing system" rather than
"a set of queues and a scheduler". In the literature, as a result,
the concepts are used somewhat interchangeably.
A simple model of a queuing system, however, is a set of data
structures for packet data, which we will call queues or service
classes and a mechanism for selecting the next packet from among
them, which we call a scheduler.
1.2.1.1 Priority Queuing
A priority queuing system is a combination of a set of queues and a
scheduler that empties them in priority sequence. When asked for a
packet, the scheduler inspects the highest priority queue, and if
there is data present returns a packet from that queue. Failing that,
it inspects the next highest priority queue, and so on. A freeway
onramp with a stoplight for one lane, but which allows vehicles in
the high occupancy vehicle lane to pass, is an example of a priority
queuing system; the high occupancy vehicle lane represents the
"queue" having priority.
In a priority queuing system, a packet in the highest priority queue
will experience a readily calculated delay - it is proportional to
the amount of data remaining to be serialized when the packet arrived
plus the volume of the data already queued ahead of it in the same
queue. The technical reason for using a priority queue relates
exactly to this fact: it limits delay and variations in delay, and
should be used for traffic which has that requirement.
A priority queue or queuing system needs to support rate and burst
size control mechanism(s) to provide starvation avoidance of lower
priority queues.
1.2.1.2 Rate Queuing
Similarly, a rate-based queuing system is a combination of a set of
Baker, et al. Expires August 13, 2004 [Page 4]
Internet-Draft Document February 2004
queues and a scheduler that empties each at a specified rate. An
example of a rate based queuing system is a road intersection with a
stoplight - the stoplight acts as a scheduler, giving each lane a
certain opportunity to pass traffic through the intersection.
In a rate-based queuing system, such as WFQ or WRR, the delay that a
packet in any given queue will experience is dependant on the
parameters and occupancy of its queue and the parameters and
occupancy of the queues it is competing with. A queue whose traffic
arrival rate is much less than the rate at which it lets traffic
depart will tend to be empty and packets in it will experience
nominal delays. A queue whose traffic arrival rate approximates or
exceeds its departure rate will tend to be not empty, and packets in
it will experience greater delay. Such a scheduler can impose a
minimum rate, a maximum rate, or both, on any queue it touches.
1.2.2 Active Queue Management
"Active queue management" or AQM is a generic name for any of a
variety of procedures that use packet dropping or marking to manage
the depth of a queue. The canonical example of such a procedure is
Random Early Detection, in that a queue is assigned a minimum and
maximum threshold, and the queuing algorithm maintains a moving
average of the queue depth. While the mean queue depth exceeds the
maximum threshold, all arriving traffic is dropped. While the mean
queue depth exceeds the minimum threshold but not the maximum
threshold, a randomly selected subset of arriving traffic is marked
or dropped. This marking or dropping of traffic is intended to
communicate with the sending system, causing its congestion avoidance
algorithms to kick in. As a result of this behavior, it is reasonable
to expect that TCP's cyclic behavior is desynchronized, and the mean
queue depth (and therefore delay) should normally approximate the
minimum threshold.
A variation of the algorithm is applied in Assured Forwarding [12],
in that the behavior aggregate consists of traffic with multiple DSCP
marks, which are intermingled in a common queue. Different minima and
maxima are configured for the several DSCPs separately, such that
traffic that exceeds a stated rate at ingress is more likely to be
dropped or marked than traffic that is within its contracted rate.
1.2.3 Traffic Conditioning
Additionally, at the first router in a network that a packet crosses,
arriving traffic may be measured, and dropped or marked according to
a policy, or perhaps shaped on network ingress as in A Rate Adaptive
Shaper for Differentiated Services [27]. This may be used to bias
feedback loops, such as is done in Assured Forwarding [12], or to
Baker, et al. Expires August 13, 2004 [Page 5]
Internet-Draft Document February 2004
limit the amount of traffic in a system, as is done in Expedited
Forwarding [22]. Such measurement procedures are collectively
referred to as "traffic conditioners". Two traffic conditioners that
are used in deployment of differentiated services that use Assured
Forwarding are the Two Rate Three Color Marker (trTCM) [14] and the
Single Rate Three Color Marker (trTCM) [13].
Two Rate Three Color Marker:
The Two Rate Three Color Marker (trTCM) [14] meters an IP packet
stream and marks its packets based on two rates, Peak Information
Rate (PIR) and Committed Information Rate (CIR), and their
associated burst sizes to be green, yellow, or red. A packet is
marked red if it exceeds the PIR. Otherwise it is marked either
yellow or green depending on whether it exceeds or doesn't exceed
the CIR. The trTCM is use to enforce committed rate separately
from Peak Information Rate.
Single Rate Three Color Marker:
The Single Rate Three Color Marker (srTCM) [13] meters an IP
packet stream and marks its packets green, yellow, or red.
Marking is based on a Committed Information Rate (CIR) and two
associated burst sizes, a Committed Burst Size (CBS) and an Excess
Burst Size (EBS). A packet is marked green if it doesn't exceed
the CBS, yellow if it does exceed the CBS, but not the EBS and red
otherwise. The srTCM is used to enforce the committed rate and
burst length.
1.2.4 Differentiated Services Code Point (DSCP)
The DSCP is a number in the range 0..63, that is placed into an IP
packet to mark it according to the class of traffic it belongs in.
Half of these values are earmarked for standardized services, and the
other half of them are available for local definition.
1.2.5 Per-Hop Behavior (PHB)
In the end, the mechanisms described above are combined to form a
specified set of characteristics for handling different kinds of
traffic, depending on the needs of the application. This document
seeks to identify useful traffic aggregates and specify what PHB
should be applied to them.
1.3 Key Service Concepts
While Differentiated Services is a general architecture that may be
used to implement a variety of services, three fundamental services
have been defined and characterized for general use. These are basic
service for elastic traffic, the Assured Forwarding service, and the
Baker, et al. Expires August 13, 2004 [Page 6]
Internet-Draft Document February 2004
Expedited Forwarding service for real-time (inelastic) traffic.
The terms "elastic" and "real-time" are defined in RFC 1633 [3]
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 RFC 2475
[9] should be reviewed to understand the data plane architecture used
in today's Internet.
The definition of "service class" is, a description of the overall
treatment of (or a subset of) a customer's traffic across a
particular domain, across a set of interconnected DiffServ (DS)
domains, or end-to-end. Service descriptions are covered by
administrative policy and services are constructed by applying
traffic conditioning to create behavior aggregates that experience a
known PHB at each node within the DS domain. A service class provides
the specified end-to-end behaviors in the network which will support
one or more applications or a set of applications that have similar
traffic characteristics and performance requirements. This concept
allows grouping of applications of similar traffic characteristics
and performance requirements into a common forwarding discipline
called a "service class" that provides consistent behavior in the
administered network. (Service class definition originates from RFC
2474 [8] Section 2, definition of a service).
1.3.1 Default Forwarding (DF)
The basic services applied to any class of traffic are those
described in RFC 2475 [8] and RFC 2309 [7]. Best Effort service may
be summarized as "I will accept your packets", with no further
guarantees. Packets in transit may be lost, reordered, duplicated, or
delayed at random. Generally, networks are engineered to limit this
behavior, but changing traffic loads can push any network into such a
state.
Application traffic in the internet is expected to be "elastic" in
nature. By this, we mean that 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 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. The
interesting thing is that by giving that queue a higher minimum rate
than its measured arrival rate, we can effectively limit the
deleterious effects of congestion on a given class of traffic,
transferring them to another class that is perhaps better able to
Baker, et al. Expires August 13, 2004 [Page 7]
Internet-Draft Document February 2004
absorb the impact or is considered to be of lower value to the
network administration. So, for example, if it is important to
service database exchange or transaction traffic in a timely fashion,
isolating the traffic into a queue and giving it a relatively high
minimum rate will accomplish that.
Scavenger, or less than best effort RFC 3662 [23], service can also
be provided, for applications with congestion avoidance capabilities
and is considered to be of lower value to the network administrator
than best effort traffic.
1.3.2 Assured Forwarding (AF)
The Assured Forwarding RFC 2597 [12] service is explicitly modeled on
Frame Relay's DE flag or ATM's CLP capability, and is intended for
networks that offer average-rate SLAs (as FR and ATM networks do).
This is an enhanced Best Effort service; traffic is expected to be
"elastic" in nature. The receiver will detect loss or variation in
delay in the network and provide feedback such that the sender
adjusts its transmission rate to approximate available capacity.
For such classes, multiple DSCP values are provided (two or three,
perhaps more using local values) to identify the traffic, a common
queue or class to store the aggregate and active queue management to
protect the network from it and to limit delays. Traffic is metered
as it enters the network, and traffic is variously marked depending
on the arrival rate of the aggregate. The premise is that it is
normal for users to occasionally use more capacity than their
contract stipulates, perhaps up to some bound. However, if traffic
must be lost or marked to manage the queue, this excess traffic will
be marked or lost first.
1.3.3 Expedited Forwarding (EF)
Expedited Forwarding RFC 3246 [22] was originally proposed as a way
to implement a virtual wire, and can be used in such a manner. It is
an enhanced best effort service: traffic remains subject to loss due
to line errors and reordering during routing changes. However, using
queuing techniques, the probability of delay or variation in delay is
minimized. For this reason, it is generally used to carry voice and
for transport of data information that requires "wire like" behavior
through the IP network. Voice is an inelastic "real-time" application
that sends packets at the rate the codec produces them, regardless of
availability of capacity. As such, this service has the potential to
disrupt or congest a network if not controlled. It also has the
potential for abuse.
To protect the network, at minimum one must police traffic at various
Baker, et al. Expires August 13, 2004 [Page 8]
Internet-Draft Document February 2004
points to ensure that the design of a queue is not over-run, and then
the traffic must be given a low delay queue (often using priority,
although it is asserted that a rate-based queue can do this) to
ensure that variation in delay is not an issue, to meet application
needs.
1.3.4 Class Selector (CS)
Class Selector provides support for historical codepoint definitions
and PHB requirement. The Class Selector DS field provides a limited
backward compatibility with legacy (pre DiffServ) practice, as
described in RFC 2474 [8] 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 RFC 1812), and we wish to permit
their continued use in DS-compliant networks. In addition, there are
some codepoints that correspond to historical use of the IP
Precedence field and we reserve these codepoints to map to PHBs that
meet the general requirements specified in RFC 2474 [8]Section
4.2.2.2.
No attempt is made to maintain backward compatibility with the "DTR"
or TOS bits of the IPv4 TOS octet, as defined in RFC 791 [1].
A DS-compliant network can be deployed with a set of one or more
Class Selector compliant PHB groups. As well, network administrator
may configure the network nodes to map codepoints to PHBs
irrespective of bits 3-5 of the DSCP field to yield a network that is
compatible with historical IP Precedence use. Thus, for example,
codepoint '011000' would map to the same PHB as codepoint '011010'.
1.3.5 Admission Control
Admission control including refusal when policy thresholds are
crossed, can assure high quality communication by ensuring the
availability of bandwidth to carry a load. Inelastic real-time flows
like VoIP (telephony) or video conferencing services can benefit from
use of admission control mechanism, as generally the telephony
service is configured with over subscription, meaning that some
user(s) may not be able to make a call during peak periods.
For VoIP (telephony) service, a common approach is to use signaling
protocols such as SIP, H.323, H.248, MEGACO, RSVP, etc. to negotiate
admittance and use of network transport capabilities. When a user has
been authorized to send voice traffic, this admission procedure has
verified that data rates will be within the capacity of the network
that it will use. Since RTP voice does not react to loss or marking
in any substantive way, the network must police at ingress to ensure
Baker, et al. Expires August 13, 2004 [Page 9]
Internet-Draft Document February 2004
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 [5]RFC 2996 [16].
However, there is concern with the scalability RFC 2206 [6]of this
solution in large networks and aggregation RFC 3175 [18]of sessions
is considered to be a requirement.
1.3.6 Service Differentiation
There are practical limits on the level of service differentiation
that should be offered in the IP networks. We believe we have defined
a practical approach in delivering service differentiation by
defining different service classes that networks may choose to
support to provide the appropriated 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 one service class and therefore
forwarded by single queue in a router. Also we provide a method for
different applications (flows) within a service class to have unique
DSCP marking so that different conditioning and policing polices may
be used for different flows, through the use of Class Selector (CS)
codepoints or locally defined DSCP (EXP/LU) values and associating
them with the standardized PHBs. 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 new traffic type is added to the network.
2. Traffic Categories and Service Classes
This document divides traffic into five categories, one for network
control and four for user/subscriber traffic. The term "user" and
"subscriber" are used interchangeable in this document. Network
control traffic can further be divided into two service classes:
"Administrative", for flows that are critical for stable operation of
the network, requiring lower delay or higher probability of being
serviced than normal "Network Control" flows. User/subscriber
traffic is broken down into four user traffic categories,
interactive, responsive, timely and non-critical as defined by ITU-T
Recommendation G.1010. These four user traffic categories can
further be subdivided into one or more different service classes
within each traffic category to provide further behavior
differentiation. End-to-end performance requirements for these
traffic categories and service classes are further defined in ITU-T
Baker, et al. Expires August 13, 2004 [Page 10]
Internet-Draft Document February 2004
Recommendation Y.1541, Y.1540, G.1010 and new work currently underway
in ITU-T. Additionally, network administrators may choose to define
other service classes.
The service classes define the required treatment for the traffic in
order to meet user, application or network expectations. Section 3
in this document defines the service classes that MAY be used for
forwarding network control traffic and Section 4 defines the service
classes that MAY be used for forwarding user traffic with examples of
intended application types mapped into each of their service classes.
Note that the application types are only examples and are not meant
to be all-inclusive or prescriptive. Also it should be noted that
the service class naming or ordering does not imply any priority
ordering. They are simply reference names that are used in this
document with associated QoS behaviors that are optimized for the
particular application types they support. Network administrators MAY
choose to assign different service class names, to the service
classes that they will support. Figure 1 defines the RECOMMENDED
relationship between service classes and DS codepoint(s) assignment
with application examples.
Baker, et al. Expires August 13, 2004 [Page 11]
Internet-Draft Document February 2004
------------------------------------------------------------------
| Service | DSCP | DSCP | Application |
| Class name | name | value | Examples |
|===============+=========+=============+==========================|
|Administrative | CS7 | 111000 | Heartbeats |
|---------------+---------+-------------+--------------------------|
|Network Control| CS6 | 110000 | Network routing |
|---------------+---------+-------------+--------------------------|
| Telephony | EF,CS5 |101010,101000| IP Telephony |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF41,AF42|100010,100100| Video conferencing |
| Conferencing | AF43 |100110 | Interactive gaming |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF31,AF32|011010,011100|Broadcast TV, Pay per view|
| Streaming |AF33, CS4|011110,100000|Video surveillance |
|---------------+---------+-------------+--------------------------|
| Low Latency |AF21,AF22|010010,010100|Client/server transactions|
| Data |AF23, CS3|010110,011000|peer-to-peer signaling |
|---------------+---------+-------------+--------------------------|
|High Throughput|AF11,AF12|001010,001100|Store&forward applications|
| Data |AF13, CS2|001110,010000|Non-critcal OAM&P |
|---------------+---------+-------------+--------------------------|
| Standard | DF,(CS0)| 000000 | Undifferentiated |
| | | | applications |
|---------------+---------+-------------+--------------------------|
| Low Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------
Figure 1: DSCP to Service Class Mapping
Note: The Class Selector 2,3 and 4 codepoints are aliases of AF11,
AF21 and AF31 codepoints respectively. Class Selector 5 codepoint is
alias of EF codepoint. Default Forwarding and Class Selector 0
provide equivalent behavior and use the same DS codepoint.
It is expected that network administrators will choose the service
classes that they will support based on their need, starting off with
two or three service classes for user traffic and adding others as
the need arises.
Figure 2 provides a summary of DiffServ QoS mechanisms that SHOULD be
used for the nine different service classes that are further defined
in Section 3 and 4 of this document. Based on what applications/
services that need to be differentiated, network administrators can
choose the service class(es) that need to be supported in their
network.
Baker, et al. Expires August 13, 2004 [Page 12]
Internet-Draft Document February 2004
------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | Queuing| AQM|
| Class | | DS Edge | Used | | |
|===============+======+===================+=========+========+====|
|Administrative | CS7* |Police using sr+bs | RFC2474 |Priority| No |
|---------------+------+-------------------+---------+--------+----|
|Network Control| CS6 |Police using sr+bs | RFC2474 | Rate |Yes |
|---------------+------+-------------------+---------+--------+----|
| Telephony |EF,CS5|Police using sr+bs | RFC3246 |Priority| No |
|---------------+------+-------------------+---------+--------+----|
| | AF41 | | | | Yes|
| Multimedia | AF42 | Using trTCM | RFC2597 | Rate | per|
| Conferencing | AF43 | (RFC2698) | | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| | AF31 | Police using sr+bs| | | |
| |------+-------------------| | | Yes|
| Multimedia | AF32 | Police sum using | | Rate | per|
| Streaming | AF33 | sr+bs | RFC2597 | |DSCP|
| |------+-------------------| | |----|
| | CS4 |Police using sr+bs | | | No |
|---------------+------+-------------------+---------+--------+----|
| | AF21 | | | | Yes|
| Low | AF22 | Using srTCM | | | per|
| Latency | AF23 | (RFC 2697) | RFC2597 | Rate |DSCP|
| Data |------+-------------------| | |----|
| | CS3 |Police using sr+bs | | | No |
|---------------+------+-------------------+---------+--------+----|
| | AF11 | | | | Yes|
| High | AF12 | Using srTCM | | | per|
| Throughput | AF13 | (RFC 2697) | RFC2597 | Rate |DSCP|
| Data |------+-------------------| | |----|
| | CS2 |Police using sr+bs | | | No |
|---------------+------+-------------------+---------+--------+----|
| Standard | DF | Not applicable | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| Low Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------
* Note: Administrative traffic is normally contained within a single
administrated domain.
Figure 2: Summary of QoS Mechanisms used for each Service Class
Note: Conditioning at DS edge, means that traffic conditioning is
performed at the edge of the DiffServ network were untrusted user
devices are connected or between two DiffServ networks.
Note: "sr+bs" represents a policing mechanism that provides single
Baker, et al. Expires August 13, 2004 [Page 13]
Internet-Draft Document February 2004
rate with burst size control.
2.1 Deployment Scenarios
It is expected that network administrators will choose the service
classes that they will support based on their need, starting off with
two or three service classes for user traffic and adding others as
the need arises. In this section we provide three examples of a
subset of service classes that could be deployed.
Example 1:
A network administrator determines that they need in their network to
provide three different levels of network performance (quality of
service) for the services that they will be offering to their
customers. They need to enable their network to provide:
o Reliable VoIP (telephony) service, equivalent to PSTN
o A low delay assured bandwidth data service
o As well, support current Internet services
For this example, the network administrator's needs are addressed
with the deployment of the following service classes:
o Network Control service class for routing and control traffic that
is needed for reliable operation of the provider's network
o Standard service class for all traffic that will receive normal
(undifferentiated) forwarding treatment through their network
o Telephony service class for VoIP (telephony) traffic
o Low Latency Data service class for the low delay assured bandwidth
differentiated data service
Figure 3, provides a popular industry view of the service
differentiation supported in core network.
Baker, et al. Expires August 13, 2004 [Page 14]
Internet-Draft Document February 2004
-----------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM |
|===============+=======+===================+=========+========+========|
| | CS7* | | | | CS7=No |
|Network Control| CS6 |Police using sr+bs | RFC2474 | Rate |CS6=Yes |
|---------------+-------+-------------------+---------+--------+--------|
| Telephony |EF, CS5|Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+--------|
| | AF21 | | | |AF21=Yes|
| Low | AF22 | Using srTCM | | |AF22=Yes|
| Latency | AF23 | (RFC 2697) | RFC2597 | Rate |AF23=Yes|
| Data |-------+-------------------| | |--------|
| | CS3 |Police using sr+bs | | | CS3=No |
|---------------+-------+-------------------+---------+--------+--------|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes |
| | +other| | | | |
-----------------------------------------------------------------------
* Note: Administrative traffic is normally contained within a single
administrated domain.
Figure 3: Popular Core Network Configuration
Example 2:
A network administrator determines that they need to support two
service classes for control and administration of their network plus
six levels of service differentiation for user traffic use the
following service classes:
o Administrative
o Network Control
o Standard
o Telephony
o Low Latency Data
o High Throughput Data
o Multimedia Conferencing
o Multimedia Streaming
Example 3:
An enterprise network administrator determines that they need to
provide seven levels of service differentiation for user traffic plus
one for running of their network. They would configure their network
to support the following service classes:
o Network Control
o Telephony
o Multimedia Streaming
Baker, et al. Expires August 13, 2004 [Page 15]
Internet-Draft Document February 2004
o Multimedia Conferencing
o Low Latency Data
o High Throughput Data
o Standard
o Low Priority Data
2.2 Service Classes and Behavior Aggregates
As stated earlier (Section 1.3) in this document, a service class
defines the end-to-end performance and forwarding behavior required
by application(s) and service(s) using them. However, network
administrator that configure core network(s) that support high speed
links (100 Mbps or higher) have the freedom of how they implement the
different service classes including aggregating several service
classes that they support into a signal Per-Hop Behavior (PHB) or Per
Domain Behavior (PDB) defined in RFC 3086 [29], as long as the
performance and traffic characteristic are met for all the aggregated
service classes into the signal PDB.
Figure 4, provides an example of how Telephony, Multimedia
Conferencing and Multimedia Streaming service classes MAY be
aggregated into a single PDB.
------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM |
|============+=======+==================+========+========+========|
| Network | CS7* | | | | CS7=No |
| Control | CS6 |Police using sr+bs| RFC2474| Rate |CS6=Yes |
|------------+-------+------------------+--------+--------+--------|
| Telephony |EF, CS5|Police using sr+bs| | | |
|------------+-------+------------------| | | |
| | AF41 | | | | |
| Multimedia | AF42 | Using trTCM | | | |
|Conferencing| AF43 | (RFC2698) | | | No |
|------------+-------+------------------| RFC3246| |for all |
| | AF31 |Police using sr+bs| |Priority| DSCP |
| |-------+------------------| | | mapped |
| Multimedia | AF32 | Police sum using | | |into PHB|
| Streaming | AF33 | sr+bs | | | |
| |-------+------------------| | | |
| | CS4 |Police using sr+bs| | | |
|------------+-------+------------------+--------+--------+--------|
| | AF21 | | | |AF21=Yes|
| Low | AF22 | Using srTCM | | |AF22=Yes|
| Latency | AF23 | (RFC 2697) | RFC2597| Rate |AF23=Yes|
| Data |-------+------------------| | |--------|
| | CS3 |Police using sr+bs| | | CS3=No |
Baker, et al. Expires August 13, 2004 [Page 16]
Internet-Draft Document February 2004
|------------+-------+------------------+--------+--------+--------|
| | AF1x | | | | |
| Standard |DF(CS0)| Not applicable | RFC2474| Rate | Yes |
| |CS2,CS1| | | | |
------------------------------------------------------------------
* Note: Administrative traffic is normally contained within a single
administrated domain.
Figure 4: Aggregation in Core Network
A network administrator configures a Per Domain Behavior (PDB) for
real-time traffic that meets or exceeds the performance requirements
and traffic characteristics of the aggregated service classes. For
this example the PDB MUST be implemented using the EF PHB and all the
traffic from the three aggregated service classes is forwarded using
the EF PHB in this domain. Therefore there is no service
differentiation between the individual aggregated service classes.
Further, the network administrator MUST enforce a Service Level
Agreement (SLA) for each service class that is aggregated into this
PDB. The SLA for each service class SHOULD support the following
parameters:
o DSCP marking
o Supported traffic rate
o Delay through network
o Delay variation or jitter
o Packet loss probability
o Plus, possibly other parameters
Traffic entering the EF PDB MUST be measured and enforced so that:
o Sum of traffic in Telephony service class is less than rate "A"
bps
o Sum of traffic in Multimedia Conferencing service class is less
than rate "B" bps
o Sum of traffic in Multimedia Streaming service class is less than
rate "C" bps
The EF PDB MUST to be configured so that the sum of rates A, B and C
is less than the forwarding bandwidth of this PDB. The experienced
delay, jitter and packet loss limits will be the same for the
aggregated service classes and the network configuration of the EF
PDB MUST met or exceed the performance requirements of the most
stringent SLA.
2.3 Issues with Aggregation
When service classes are aggregation, the original individual service
class behavior and performance requirements must not be violated.
Baker, et al. Expires August 13, 2004 [Page 17]
Internet-Draft Document February 2004
This is especially true for real-time traffic. The PHB or PDB must
be engineered so that the service rate is higher in comparison to the
maximum packet rate of the individual service classes being
aggregated so the smaller packets will not experience jitter outside
of its tolerable range when large packets are being service by the
same queue. Some of the impact of aggregating service classes can be
minimized by performing careful admission control on each of the
individual service class to make sure the impact of traffic of one
service class (i.e. Multimedia Streaming of large packets) does not
violate the behavior required by another service class (i.e.
Telephone using small packets).
3. Network Control Traffic Category
Network control traffic is defined as packet flows that are essential
for stable operation of the administered network as well for
information that may be exchanged between neighboring networks across
a peering point where SLAs are in place. Network control traffic is
different from user application control (signaling) that may be
generated by some applications or services. Network control traffic
is mostly between routers and network nodes that are used for
administering, controlling or managing the network segments and the
services that are provided in that network segment. A network
administrator MAY choose to split the network control traffic into
two service classes i.e., Administrative and Network Control to
provide two different forwarding treatments or just support one
forwarding treatment for all network control flows.
3.1 Administrative Service Class
The Administrative service class is intended to be used for control
traffic that is within a single administrative network domain. If
such traffic does not get through, the administered network domain
may not function properly. Example of such type of traffic is
heartbeats between core network switches/routers. Such heartbeats are
used to determine if the next hop is reachable. If no heartbeat is
received within a specified time interval, then the sending router
assumes that the particular link or next hop node is unreachable on a
particular interface and subsequently reroutes the traffic to a
backup interface that can reach the next hop node. This reroute is
typically done in a time interval much shorter than the time it would
take for the routing protocol to determine that the next hop node is
unreachable.
The Administrative service class if support MUST be configured using
the DiffServ Class Selector (CS) PHB defined in RFC 2474 [8] and
MUST be configured to receive sufficient forwarding resources so that
all packets are forwarded quickly. The Administrative service class
Baker, et al. Expires August 13, 2004 [Page 18]
Internet-Draft Document February 2004
SHOULD be configured to use a Priority Queuing system such as defined
in Section 1.2.1.1 of this document.
The following protocols and application SHOULD use the Administrative
service class:
o Network administrator's telnet sessions from secure and trusted
terminals, Secure Shell (SSH)
o Protocol(s) that are transmitted between nodes within the
administered network for detecting link and nodal failures
o Used for critical control traffic within an administrative domain
The following protocols and application MUST NOT use the
Administrative service class:
o User Traffic
o Inter-network domain (across peering points) control traffic
Traffic characteristics of packet flows in the Administrative service
class:
o Mostly messages between routers and network servers
o Typically small packet sizes, one packet at a time
o Packets requiring immediate forwarding
o User traffic is not allowed to use this service class
RECOMMENDED DSCP marking is CS7 (Class Selector 7)
RECOMMENDED Network Edge Conditioning:
o Drop or remark CS7 marked packets at ingress to DiffServ network
domain
o Depending on policy within the administered network, CS7 marked
packets MAY be dropped or remarked to CS6 at egress of DiffServ
network or across peering points
3.2 Network Control Service Class
The Network Control service class is used for transmitting packets
between network devices (routers, servers, etc.) that require control
information to be exchanged between different administrative domains
(across a peering point) and for non-critical network control
information exchange within one administrative domain. Traffic
transmitted in this service class is very important as it keeps the
network operational and MUST to be forwarded in a timely manner.
The Network Control service class MUST be configured using the
DiffServ Class Selector (CS) PHB defined in RFC 2474 [8]. This
service class MUST be configured so that the traffic receives a
minimum bandwidth guarantee, to ensure that the packets always
receive timely service. The configured forwarding resources for
Network Control service class SHOULD be such that the probability of
Baker, et al. Expires August 13, 2004 [Page 19]
Internet-Draft Document February 2004
packet drop under peak load is very low in this service class. The
Network Control service class SHOULD be configured to use a Rate
Queuing system such as defined in Section 1.2.1.2 of this document.
The following protocols and application SHOULD use the Network
Control service class:
o Routing packet flows, OSPF, BGP, ISIS, RIP
o Policy management flows between nodes in the network, COPS,
RSVP-TE, etc.
o Signaling flows between high capacity telephony call servers or
soft switches. Such high capacity devices may control thousands
of telephony (VoIP) calls
o Network services, DNS, DHCP, BootP, high priority OAM (SNMP) like
alarms, etc.
o Control information exchange within and between different
administrative domains across a peering point where SLAs are in
place
o In 3GPP wireless solutions, UMTS Signaling/control information
between wireless nodes
The following protocols and applications MUST NOT use the Network
Control service class:
o User traffic
Traffic characteristics of packet flows in the Network Control
service class:
o Mostly messages between routers and network servers
o Ranging from 50 to 1,500 byte packet sizes, normally one packet at
a time but traffic can also burst (BGP)
o User traffic is not allowed to use this service class
RECOMMENDED DSCP marking is CS6 (Class Selector 6)
RECOMMENDED Network Edge Conditioning:
o At peering points (between two DiffServ networks) where SLAs are
in place, CS6 marked packets are policed 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) are dropped or remarked at ingress to DiffServ
network. Packets from users are not permitted access to the
Network Control or Administrative service classes
The fundamental service offered to the Network Control service class
is enhanced best effort service with high bandwidth assurance. Since
this service class is used to forward both elastic and inelastic
flows, the service SHOULD be engineered so the Active Queue
Management [7] is applied to CS6 marked packets.
Baker, et al. Expires August 13, 2004 [Page 20]
Internet-Draft Document February 2004
If Administrative service class is not supported, then the Network
Control service class MUST be used for both normal network control
traffic and network administrative traffic defined in this document.
Packets marked with CS7 DSCP use the same Per-Hop Behavior (PHB) as
CS6 marked packets however, packets marked with CS7 DSCP MUST NOT be
put through Active Queue Management (AQM).
4. User Traffic Categories
User traffic is divided into four different categories, namely,
interactive, responsive, timely and non-critical. An example of
interactive traffic is traffic between two humans that is most
sensitive to delay, loss and jitter; another example of interactive
traffic is traffic 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; it is less affected by
jitter and can tolerate longer delays than interactive traffic.
Timely traffic is typically between two servers but can also be
between a server and a human; the delay tolerance is significantly
longer than for responsive traffic. Non-critical traffic is normally
between servers where delivery may be delayed for period of time. The
four traffic categories follow methodology defined by ITU-T
Recommendation G.1010. End-to-end performance requirements for the
listed service classes are currently being defined in ITU-T.
Network administrators can categorize their applications based on the
type of behavior that they require. Figure 1 provides some common
applications and the forwarding service class that best supports them
based on their performance requirements.
In summary:
o Telephony service class is best suited for applications that
require very low delay and are of constant rate, such as IP
telephony (VoIP) and circuit emulation over IP applications.
o Multimedia Conferencing service class is best suited for
applications that require very low delay but are of variable rate,
such as video conferencing and interactive gaming.
o Multimedia Streaming service class is best suited for streaming
media applications where a human is waiting for outputs, such as
broadcast TV, pay-per-view, video surveillance and security, etc.
o Low Latency Data service class is best suited for data processing
applications where a human is waiting for outputs, such as
web-based ordering, EPR application, peer-to-peer signaling, etc.
o High Throughput Data service class is best suited for store and
forward applications such as FTP, billing record transfer, etc.
o Standard service class is for traffic that has not been identified
as requiring differentiated treatment and is normally referred as
best effort.
Baker, et al. Expires August 13, 2004 [Page 21]
Internet-Draft Document February 2004
o Low Priority Data service class is intended for packet flows where
bandwidth assurance is not required.
Note, a network administrator MAY choose to support all or subsets of
the defined service classes and provide service differentiation only
to the applications/services that are mapped into them.
4.1 Interactive Traffic Category
Interactive traffic category can be further split into two service
classes, Telephony and Multimedia Conferencing to provide
differentiation based on the different behavior of source traffic
being forwarded.
4.1.1 Telephony Service Class
The Telephony service class is RECOMMENDED for applications that
require real-time, very low delay, very low jitter and very low
packet loss for relatively constant-rate traffic sources (inelastic
traffic sources). This service class MUST be used for IP telephony
services.
The fundamental service offered to traffic in the Telephony service
class is a higher priority service than best-effort up to a specified
upper bound with very low delay and very low packet loss. Operation
is in some respect similar to an ATM CBR service, which has
guaranteed bandwidth and which, if it stays within the negotiated
rate, experiences nominal delay and no loss. The EF PHB has a similar
guarantee.
Typical configurations negotiate the setup of telephone calls over IP
using protocols such as H.248, MEGACO, H.323 or SIP. When a user has
been authorized to send telephony traffic, the call admission
procedure should have verified that the newly admitted data rates
will be within the capacity of the Telephony service class forwarding
capability in the network that it will use. For VoIP (telephony)
service, call admission control is usually performed by a telephony
call server/gatekeeper using signaling (SIP, H.323, H.248, MEGACO,
etc.) on access points to the network. The bandwidth in the core
network and the number of simultaneous VoIP sessions that can be
supported needs to be engineered and controlled so that there is no
congestion for this service. Since RTP telephony flows do not react
to loss or substantial delay in any substantive way, the Telephony
service class SHOULD forward packet as soon as possible.
The Telephony service class MUST use Expedited Forwarding (EF) PHB as
defined in RFC 3246 [22] and MUST be configured to receive guaranteed
forwarding resources so that all packets are forwarded quickly. The
Baker, et al. Expires August 13, 2004 [Page 22]
Internet-Draft Document February 2004
Telephony service class MUST be configured to use a Priority Queuing
system such as defined in Section 1.2.1.1 of this document.
The following application SHOULD use the Telephony service class:
o VoIP (G.711, G.729 and other codecs)
o Telephony (trunk and/or stimulus) signaling between end device
(terminals/gateways) and the call server (H.248, MEGACO)
o Voice-band data over IP (modem, fax)
o T.38 fax over IP
o Circuit emulation over IP, virtual wire, etc.
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Conversational Traffic Class
Traffic characteristics:
o Mostly fixed size packets for VoIP (60, 70, 120 or 200 bytes in
size)
o Packets emitted at constant time intervals
o Admission control of new flows is provided by telephony call
server, media gateway, gatekeeper, edge router or access node that
provides "middlebox" function.
RECOMMENDED DSCP marking is EF for the following applications:
o VoIP (G.711, G.729 and other codecs)
o Voice-band data over IP (modem)
o Circuit emulation over IP, virtual wire, etc.
o Conversational UMTS Traffic Class
RECOMMENDED DSCP marking is CS5 for the following applications:
o Telephony (trunk and/or stimulus) signaling between end device
(terminals/gateways) and the call server (H.248, MEGACO)
o T.38 fax over IP
Both EF and CS5 DS codepoints SHOULD be mapped into the Telephony
service class and SHOULD used the Expedited Forwarding (EF) PHB. The
CS5 DS codepoint is aliased to the EF codepoint and packets marked
with CS5 are forwarded using the EF PHB.
RECOMMENDED Network Edge Conditioning:
o Packet flows from untrusted sources (end user devices) MUST be
policed at ingress to DiffServ network using single rate with
burst size token bucket policer to ensure that the telephony
traffic stays within its negotiated bounds.
o Packet flows from trusted sources (media gateways inside
administered network) do not require policing.
o Policing of Telephony packet flows across peering points where SLA
is in place is not required as telephony traffic will be
controlled by admission control mechanism between peering points.
Baker, et al. Expires August 13, 2004 [Page 23]
Internet-Draft Document February 2004
Note: On low speed links (typically access links below 1 Mbps), in
the attempt to minimize jitter/delay, it is RECOMMENDED that
packetized audio streams are separated from processed telephony data
information flows like T.38 fax and telephony signaling and forwarded
using less stringent (from delay/jitter perspective) service class.
PCM voice when compressed produces very small packets (perhaps 60
bytes in size) where T.38 fax and signaling packets can be much
bigger. The serialization delay and therefore delay/jitter, for the
larger T.38 fax and signaling packets can be significantly bigger
over low speed links then for 60 byte voice packets. For this reason
it is RECOMMENDED for low speed links that packetized voice packets
receive a higher priority forwarding treatment then the less
sensitive from delay/jitter perspective T.38 fax and telephony
signaling packets. PCM audio streams (voice) have a strict end-to-end
delay constrain and SHOULD use Priority Queuing system whereas T.38
fax or telephony signaling have a more liberal jitter/delay constrain
and SHOULD use a Rate Queuing system on access links below 1 Mbps.
On higher speed links the difference in serialization delay is very
small, so both types of telephony packet flows are aggregated in to a
single forwarding service class to simplify network engineering and
use a Priority Queuing system. Moreover, the forwarding of voice
packets and signaling packets with the same very low delay forwarding
service class minimizes delay as well as the difference in delay
between signaling and bearer path, thereby virtually eliminating
speech clipping and ring-clipping problems at start of a call when
interfacing to PSTN.
4.1.2 Multimedia Conferencing Service Class
The Multimedia Conferencing service class is RECOMMENDED for
applications that requires real-time and low delay for variable rate
elastic traffic sources. Video conferencing is such an application.
The traffic sources (applications) in this traffic class have the
capability to change their emission rate based on feedback received
from the receiving end. Detection of packet loss by the receiver is
sent using the applications control stream to the transmitter as an
indication of possible congestion; the transmitter then selects a
lower transmission rate based on pre-configured encoding rates (or
transmission rates).
Typical video conferencing configurations negotiate the setup of
multimedia session using protocols such as H.323 or SIP. When a
user/end-point has been authorized to start a multimedia session the
admission procedure should have verified that the newly admitted data
rates will be within the engineered capacity of the Multimedia
Conferencing service class. The bandwidth in the core network and the
number of simultaneous video conferencing sessions that can be
Baker, et al. Expires August 13, 2004 [Page 24]
Internet-Draft Document February 2004
supported SHOULD to be engineered to control traffic load for this
service.
The Multimedia Conferencing service class SHOULD use the Assured
Forwarding (AF) PHB defined in RFC 2597 [12]. This service class
SHOULD be configured to provide a bandwidth assurance for AF41, AF42,
and AF43 marked packets to ensure that they get forwarded. The
Multimedia Conferencing service class SHOULD be configured to use a
Rate Queuing system such as defined in Section 1.2.1.2 of this
document.
The following application SHOULD use the Multimedia Conferencing
service class:
o Video conferencing (interactive video)
o Interactive gaming
o Server to server data transfer requiring very low delay
o IP VPN service that specifies two rates and mean network delay
that is slightly longer then network propagation delay.
o Interactive, time critical and mission critical applications.
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Interactive Traffic Class with Traffic Handling Priority 1
(THP=1).
Traffic characteristics:
o Variable size packets (50 to 1500 bytes in size)
o Higher the rate, higher is the density of large packets
o Variable packet emission time
o Source is capable of reducing its transmission rate based on
detection of packet loss at the receiver
RECOMMENDED DSCP marking:
o Interactive gaming packets are marked with AF41
o Video conferencing packets are marked with AF4x
o VPN service may be marked with AF4x, depending on the service
characteristics
o Server to server data transfer with AF4x, depending on the service
characteristics
o UMTS Interactive THP=1 packets are marked with AF4x
Packet flows from video conferencing equipment MAY be marked at
source by the video conferencing equipment or by the edge router
using a Two Rate Three Color Marker (trTCM) RFC 2698 [14].
RECOMMENDED DSCP marking when performed by video conferencing
equipment:
o AF41 = H.323 video conferencing audio stream RTP/UDP
o AF41 = H.323 video conferencing video control RTCP/TCP
Baker, et al. Expires August 13, 2004 [Page 25]
Internet-Draft Document February 2004
o AF41 = H.323 video conferencing video stream below specified rate
"A"
o AF42 = H.323 video conferencing video stream between specified
rate "A" and "B"
o AF43 = H.323 video conferencing video stream above specified rate
"B"
o Where rate "B" is greater in magnitude than rate "A"
RECOMMENDED Conditioning Performed at DiffServ Network Edge:
The Two Rate Three Color Marker (trTCM) SHOULD be used as
specified in RFC 2698 [14].
If packets are marked by the sources or previous DiffServ domain,
then the trTCM SHOULD be configured to operate in Color-Aware
mode.
If the packets are not marked by the source or previous DiffServ
domain, then the trTCM MUST be configured to operate in
Color-Blind mode.
The fundamental service offered to "Multimedia Conferencing" traffic
is enhanced best effort service with controlled rate and delay. Some
traffic in this service class may not respond dynamically to packet
loss. For video conferencing service, typically a 1% packet loss
detected at the receiver triggers an encoding rate change, dropping
to next lower provisioned video encoding rate. As such, Active Queue
Management [7] SHOULD be used primarily to switch video encoding rate
under congestion, changing from high rate to lower rate i.e. 1472
kbps to 768 kbps. The probability of loss of AF41 traffic MUST NOT
exceed the probability of loss of AF42 traffic, which in turn MUST
NOT exceed the probability of loss of AF43 traffic.
4.2 Responsive Traffic Category
Responsive traffic category can be further split into two service
classes, Multimedia Streaming and Low Latency Data to provide
differentiation based on the different behavior of source traffic
being forwarded.
4.2.1 Multimedia Streaming Service Class
The Multimedia Streaming service class is RECOMMENDED for
applications that require near-real-time packet forwarding of
variable rate traffic sources that are not as delay sensitive as
applications using the Multimedia Conferencing service class. Such
applications include broadcast TV, streaming audio and video, video
(movies) on demand and surveillance video. In general, the
Multimedia Streaming service class assumes that the traffic is
buffered at the source/destination and therefore, is less sensitive
to delay and jitter.
Baker, et al. Expires August 13, 2004 [Page 26]
Internet-Draft Document February 2004
The Streaming service class SHOULD use the Assured Forwarding (AF)
PHB defined in RFC 2597 [12]. This service class SHOULD be configured
to provide a minimum bandwidth assurance for AF31, AF32, AF33 and CS4
marked packets to ensure that they get forwarded. The Streaming
service class SHOULD be configured to use Rate Queuing system such as
defined in Section 1.2.1.2 of this document.
The following applications SHOULD use the Multimedia Streaming
service class:
o Video surveillance and security (unicast)
o TV broadcast including HDTV (multicast)
o Pay per view movies and events (pre scheduled)
o Video on demand (unicast) with control (virtual DVD)
o Streaming audio (unicast)
o Streaming video (unicast)
o Web casts
o VPN service that supports different levels of flow assurance
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Streaming Traffic Class
Traffic characteristics:
o Variable size packets (50 to 4196 bytes in size)
o Higher the rate, higher density of large packets
o Variable packet emission rate
o Some bursting at start of flow from some applications
o At about 2% packet loss, a video session is usually terminated
Both the AF3x and CS4 DS codepoints SHOULD be mapped into the
Multimedia Streaming service classes and used the Assured Forwarding
(AF) PHB. The CS4 DS codepoint is aliases to the AF31 DS codepoint
and packets marked with CS4 are forwarded using the AF31 PHB.
However, Active Queue Management (AQM) MUST NOT be applied in the
router(s) to CS4 market packets.
Applications or end systems SHOULD pre-mark their packets with DSCP
values as shown in Figure 5. If a host is unable to pre-mark their
packets, then marking MUST be performed in the DiffServ edge router
using MF classification. Due to the nature of the service, it is
RECOMMENDED that video surveillance and security flows are marked
with a different DSCP value so that traffic conditioning and policing
policies can be different from other flows in the Multimedia
Streaming service class.
Baker, et al. Expires August 13, 2004 [Page 27]
Internet-Draft Document February 2004
------------------------------------------------------------------
| Applications | Protocol |DSCP|
|------------------------------------+------------------------+----|
|Video surveillance and security |For RTP/UDP payload and |CS4 |
| (unicast) |RTSP/TCP control streams| |
|------------------------------------+------------------------+----|
|TV broadcast (multicast), pay per |For RTP/UDP payloads and| |
|view movies and events (multicast) |RTSP/TCP control streams|AF31|
|Video on demand(unicast)with control| | |
|------------------------------------+------------------------+----|
| | For RTP/UDP streams |AF33|
| |------------------------+----|
| Video clips (unicast), premium WEB | For RTP/TCP streams |AF32|
| casts, etc. |------------------------+----|
| | RTP/TCP or HTTP control|AF32|
|------------------------------------+------------------------+----|
| | For RTP/UDP streams |AF33|
| |------------------------+----|
| Audio streaming (unicast) | For RTP/TCP streams |AF32|
| |------------------------+----|
| |RTSP/TCP or HTTP control|AF31|
|------------------------------------+------------------------+----|
| VPN service that support different | |AF31|
| levels of assurance |Implementation dependent|AF32|
| | |AF33|
|------------------------------------+------------------------+----|
| | |AF31|
| UMTS Streaming packets | GPRS tunnel over IP |AF32|
| | |AF33|
------------------------------------------------------------------
Figure 5: DSCP marking for Multimedia Streaming
RECOMMENDED Network Edge Conditioning:
Packet flows from untrusted sources MUST be policed at the
DiffServ network edge using single rate policers with a burst size
control for AF31, AF32, AF33 and CS4 marked packets. Policing
policy is based on the SLA for supported application(s). For the
above defined applications, three single rate policers with burst
size control SHOULD be provided; one for CS4 marked packets,
another for AF31 marked packets and the third policer for AF32 and
AF33 marked packets. Packet flows from trusted sources (e.g., TV
broadcast servers) normally do not require policing.
The fundamental service offered to "Multimedia Streaming" traffic is
enhanced best effort service with controlled rate and delay. This
traffic does not respond dynamically to packet loss. Packets marked
with AF31 and CS4 DSCP require very high assurance of delivery.
Baker, et al. Expires August 13, 2004 [Page 28]
Internet-Draft Document February 2004
Packets marked with AF32 and AF33 can generally tolerated up to 1%
and 2% packet loss respectively. As such, Active Queue Management [7]
SHOULD be used primarily to reduce the number of flows at congestion
points by dropping packets from less important flows first before any
AF31 and CS4 marked packets are dropped. The service SHOULD be
provisioned so that AF31 and CS4 marked packet flows have high
assurance for bandwidth in the network. 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.
Packets marked with CS4 DSCP (Video surveillance and security
packets) SHOULD NOT be put through Active Queue Management function.
4.2.2 Low Latency Data Service Class
The Low Latency Data service class is RECOMMENDED for elastic and
responsive typically client/server based applications. Applications
forwarded by this service class are those requiring a relatively fast
responses and typically have asymmetrical bandwidth need, i.e. the
client typically sends a short message to the server and the server
responds with a much larger data flow back to the client. The most
common example of this is when a user clicks a hyperlink (~few dozen
bytes) on a web page resulting in a new web page to be loaded (Kbytes
of data). This service class is configured to provide good response
for TCP [3] short lived flows that require real-time packet
forwarding of variable rate traffic sources.
The Low Latency Data service class MUST use the Assured Forwarding
(AF) PHB defined in RFC 2597 [12]. This service class SHOULD be
configured to provide a minimum bandwidth assurance for AF21, AF22,
AF23 and CS3 marked packets to ensure that they get forwarded. The
Low Latency Data service class MUST be configured to use a Rate
Queuing system such as defined in Section 1.2.1.2 of this document.
The following applications SHOULD use the Low Latency Data service
class:
o Client/server applications
o SNA terminal to host transactions (SNA over IP using DLSw)
o Web based transactions (E-commerce)
o Credit card transactions
o Financial wire transfers
o ERP applications (e.g., SAP/BaaN)
o Peer-to-peer signaling (SIP, H.323)
o VPN service that supports CIR (Committed Information Rate) with up
to two burst sizes
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Interactive Traffic Class with Traffic Handling Priority 2
(THP=2)
Baker, et al. Expires August 13, 2004 [Page 29]
Internet-Draft Document February 2004
Traffic characteristics:
o Variable size packets (50 to 1500 bytes in size)
o Variable packet emission rate
o With packet bursts of TCP window size
o Source capable of reducing its transmission rate based on
detection of packet loss at the receiver or through explicit
congestion notification
Both the AF2x and CS3 DS codepoints SHOULD be mapped into the Low
Latency Data service classes and use the Assured Forwarding (AF) PHB.
However, Active Queue Management (AQM) MUST NOT be applied in
router(s) to CS3 market packets.
RECOMMENDED DSCP marking:
o Peer-to-peer inelastic SIP, H.323 signaling packet flows are
marked with CS3
o Elastic TCP flows are marked with AF2x
o VPN service may be marked with AF2x or CS3 depending on the
service characteristics
o UMTS Interactive THP=2 packets are marked with AF2x
Marking of the DSCP MAY be performed by a host or by an edge router.
RECOMMENDED Conditioning Performed at the DiffServ Network Edge:
Conditioning MAY be performed on per-flow or on aggregated-flows
depending on the configuration and service offered. Metering and
(re)marking of flows is REQUIRED at DiffServ edge nodes and at
DiffServ boundary nodes. The Low Latency Data service class
SHOULD use a Single Rate Three Color Marker (srTCM) conditioner
for AF2x flows.
RECOMMENDED Conditioning Requirements for AF2x marked packets:
o Conditioning of aggregated packet flows destined for the Low
Latency Data service class MUST be performed at the DiffServ edge
of the network. Furthermore, conditioning SHOULD be performed
using Single Rate Three Color Marker (srTCM) as defined in RFC
2697 [13].
o If the packets are not pre-marked then the srTCM MUST be
configured to operate in the Color-Blind mode.
o If the packets are pre-marked by the source or previous network
(boundary node) then the srTCM SHOULD be configured to operate in
the Color-Aware mode.
RECOMMENDED Conditioning Requirements for CS3 marked packets:
o DiffServ edge and boundary nodes MUST police CS3 marked packets so
both rate and burst size can be enforced.
The fundamental service offered to "Low Latency Data" traffic is
Baker, et al. Expires August 13, 2004 [Page 30]
Internet-Draft Document February 2004
enhanced best effort service with controlled rate and delay. The
service SHOULD be engineered so that AF21 and CS3 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 [7] SHOULD be used primarily
to control TCP flow rates at congestion points by dropping packet
from TCP flows where the burst length is high. The probability of
loss of AF21 traffic MUST NOT exceed the probability of loss of AF22
traffic, which in turn MUST NOT exceed the probability of loss of
AF23. Active queue management MAY also be implemented using Explicit
Congestion Notification (ECN) RFC 3168 [17].
Packets marked with CS3 DSCP (SIP signaling packets) MUST NOT be put
through Active Queue Management [7] function.
4.3 Timely Traffic Category
Timely traffic category can be further split into two service
classes, High Throughput Data and Standard to provide differentiation
based on the different behavior of source traffic being forwarded.
4.3.1 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 [3] or a transport with a
consistent Congestion Avoidance Procedure [10][11] 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 MUST use the Assured
Forwarding (AF) PHB defined in RFC 2597 [12]. This service class
SHOULD be configured to provide a minimum bandwidth assurance for
AF11, AF12, AF13 and CS2 marked packets to ensure that they are
forwarded. The High Throughput Data service class MUST be configured
to use a Rate Queuing system such as defined in Section 1.2.1.2 of
this document.
The following applications SHOULD use the High Throughput Data
service class:
o Store and forward applications
o File transfer applications
o Email
o Non-critical OAM&P (Operation and Management and Provisioning)
using SNMP, XML, etc.
Baker, et al. Expires August 13, 2004 [Page 31]
Internet-Draft Document February 2004
o VPN service that supports CIR (Committed Information Rate) with up
to two burst sizes
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Interactive Traffic Class with Traffic Handling Priority 3
(THP=3)
Traffic characteristics:
o Variable size packets (50 to 1500 bytes in size)
o Variable packet emission rate
o With packet bursts of TCP window size
o Source capable of reducing its transmission rate based on
detection of packet loss at the receiver or through explicit
congestion notification
Both the AF1x and CS2 DS codepoints SHOULD be mapped into the High
Throughput Data service classes and use the Assured Forwarding (AF)
PHB. However, Active Queue Management (AQM) MUST NOT be applied in
router(s) to CS2 marked packets.
RECOMMENDED DSCP marking:
o Non-critical OAM&P (SNMP, XML, etc.) packets are marked with CS2
o Elastic TCP flows are marked with AF1x
o VPN service may be marked with AF1x or CS2 depending on the
service characteristics
o UMTS Interactive THP=3 packets are marked with AF1x
Note: Since the performance requirements for non-critical OAM&P
traffic can be met with the High Throughput Data service class and
the amount of non-critical OAM&P traffic is normally very small, we
recommend that non-critical OAM&P traffic be marked with CS2 DSCP and
forwarded using the High Throughput Data service class. The marking
of non-critical OAM&P traffic with CS2 DS codepoint is recommended so
that different conditioning, policing and queue management policies
can be used for non-critical OAM&P.
Marking of the DSCP MAY be performed by a host or by an edge router.
RECOMMENDED Conditioning Performed at the DiffServ Network Edge:
Conditioning MAY be performed on per-flow or for aggregated flows
depending on the configuration and the service offered. Metering
and (re)marking of DSCP is REQUIRED at the DiffServ edge node and
on the DiffServ boundary node. The High Throughput Data service
class SHOULD use a Single Rate Three Color Marker (srTCM)
conditioner for AF1x flows and a single rate policer with a burst
size limit for CS2 flows.
RECOMMENDED Conditioning Requirements for AF1x marked Packets:
Baker, et al. Expires August 13, 2004 [Page 32]
Internet-Draft Document February 2004
Conditioning of aggregated packet flows destined for the High
Throughput Data service class MUST be performed at the DiffServ
edge of the network. Furthermore, conditioning SHOULD be performed
as defined in RFC 2697 [13].
If the packets are not pre-marked, then the srTCM MUST be
configured to operate in the Color-Blind mode.
If the packets are pre-marked by the source or previous network
(boundary node) the srTCM SHOULD be configured to operate in the
Color-Aware mode.
RECOMMENDED Conditioning Requirements for CS2 marked Packets:
DiffServ edge and boundary nodes MUST police CS2 marked packets so
both rate and burst size can be enforced
The fundamental service offered to "High Throughput Data" traffic is
enhanced best effort service with a specified minimum rate. It can be
assumed that this class will consume any available bandwidth, and
packets traversing congested links may experience higher queuing
delays and/or packet loss.
Typical configurations use Explicit Congestion Notification [17] or
random packet dropping to implement Active Queue Management [7] and
MAY impose a minimum or maximum rate. 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
traffic. Ingress traffic conditioning passes traffic in the class up
to some specified threshold marked as AF11, additional traffic up to
some secondary threshold marked as AF12, and potentially passes
additional traffic marked as 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.
Packets marked with CS2 DSCP (OAM&P packets) MUST NOT be put through
Active Queue Management [7] function.
4.3.2 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 no bandwidth, delay, loss or jitter assurances.
The Standard service class MUST use the Default Forwarding (DF) PHB
defined in RFC 2474 [8] and SHOULD be configured to receive a small
percentage of forwarding resources (at least 5%). This service class
MUST be configured to use a Rate Queuing system such as defined in
Baker, et al. Expires August 13, 2004 [Page 33]
Internet-Draft Document February 2004
Section 1.2.1.2 of this document.
The following application SHOULD use the Standard service class:
o Any undifferentiated application/packet flow transported through
the DiffServ enabled network
o In wireless 3GPP applications, traffic that is mapped into the
UMTS Background Traffic Class
Traffic Characteristics:
o Non deterministic, mixture of everything
RECOMMENDED DSCP marking is DF (Default Forwarding)
Network Edge Conditioning:
There is no requirement that conditioning of packet flows be
performed for this service class
The fundamental service offered to the Standard service class is best
effort service with active queue management to limit over-all delay.
Typical configurations SHOULD use Explicit Congestion Notification
[17] or random packet dropping to implement Active Queue Management
[7], and MAY impose a minimum or maximum rate on the queue.
4.4 Non Critical Traffic Catgegory
Non-critical traffic category currently has only one service class
defined for differentiation from Standard traffic. When a need arise
other service class could be defined in the future.
4.4.1 Low Priority Data
The Low Priority Data service class serves applications that run over
TCP [2] or a transport with a consistent congestion avoidance
procedure [10][11], and which the user is willing to accept service
without guarantees. This service class is specified in [24] and RFC
3662 [23].
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
Traffic Characteristics:
o Non real-time and elastic
Network Edge Conditioning:
Baker, et al. Expires August 13, 2004 [Page 34]
Internet-Draft Document February 2004
There is no requirement that conditioning of packet flows be
performed for this service class
RECOMMENDED DSCP marking is CS1 (Class Selector 1)
The fundamental service offered to the Low Priority Data service
class is best effort service with zero bandwidth assurance. By
placing it into a separate queue or class, it may be treated in a
manner consistent with a specific service level agreement.
Typical configurations SHOULD use Explicit Congestion Notification
[17] or random loss to implement Active Queue Management [7].
5. Mapping Applications to Service Classes
Here we provide some examples for mapping different applications into
the defined service classes.
Mapping for Signaling:
There are many different signaling protocols, ways that signaling is
used and performance requirements from applications that are
controlled by these protocols. Therefore we have determined that the
different signaling protocols be mapped to service classes that best
meet the objectives. The following mapping is recommended:
SIP and H.323 are forwarded using Low Latency Data service class
H.248 and MEGACO are forwarded using the Telephony service class
SIP-T signaling between call servers in carrier's network using
Network Control service class.
RSVP signaling, depends on the application. If RSVP signaling is
"on-path" as used in IntServ or NSIS, than it needs to be
forwarded from the same queue (service class) as application data
that it is controlling. If it is "off-path" (not along the same
path as its applications data) then, Low Latency Data service
class should be used for RSVP signaling.
Mapping for NTP:
From tests that were performed, indications are that precise time
distribution requires a very low packet delay variation (jitter)
transport. Therefore we would suggest the following guidelines for
NTP be used:
When NTP is used for providing high accuracy timing within
administrator's (carrier's) network or to end users/clients, the
Telephony service class should be used and NTP packets be marked
with CS5 DSCP.
For applications that require "wall clock" timing accuracy, the
Standard service class should be used and packets should be marked
Baker, et al. Expires August 13, 2004 [Page 35]
Internet-Draft Document February 2004
with DF DSCP.
6. Security Considerations
This document discusses policy, and describes a common policy
configuration, for the use of a Differentiated Services Code Point by
transports and applications. If implemented as described, it should
require the network to do nothing that the network has not already
allowed. If that is the case, no new security issues should arise
from the use of such a policy.
It is possible for the policy to be applied incorrectly, or for a
wrong policy to be applied in the network for the defined service
class. In that case, a policy issue exists that the network must
detect, assess, and deal with. This is a known security issue in any
network dependent on policy directed behavior.
A well known flaw appears when bandwidth is reserved or enabled for a
service (for example, voice transport) and another service or an
attacking traffic stream uses it. This possibility is inherent in
DiffServ technology, which depends on appropriate packet markings.
When bandwidth reservation or a priority queuing system is used in a
vulnerable network, the use of authentication and flow admission is
recommended. To the author's knowledge, there is no known technical
way to respond to an unauthenticated data stream using service that
it is not intended to use, and such is the nature of the Internet.
7. Achnoledgements
The authors acknowledge a great many inputs, most notably from Bruce
Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet,
Brian E Carpenter, Morgan Littlewood, Robert Milne, John Shuler,
Nalin Mistry and Al Morton. Kimberly King, Joe Zebarth and Alistair
Munroe each did a thorough proof-reading, and the document is better
for their contributions.
Normative References
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[3] Braden, B., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Baker, et al. Expires August 13, 2004 [Page 36]
Internet-Draft Document February 2004
Levels", BCP 14, RFC 2119, March 1997.
[5] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[6] Baker, F., Krawczyk, J. and A. Sastry, "RSVP Management
Information Base using SMIv2", RFC 2206, September 1997.
[7] 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.
[8] 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.
[9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
[10] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[11] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's
Fast Recovery Algorithm", RFC 2582, April 1999.
[12] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[13] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker",
RFC 2697, September 1999.
[14] Heinanen, J. and R. Guerin, "A Two Rate Three Color Marker",
RFC 2698, September 1999.
[15] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
January 2000.
[16] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[17] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
Baker, et al. Expires August 13, 2004 [Page 37]
Internet-Draft Document February 2004
[18] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001.
[19] Herzog, S., "Signaled Preemption Priority Policy Element", RFC
3181, October 2001.
[20] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC
3182, October 2001.
[21] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
Waldbusser, "Terminology for Policy-Based Management", RFC
3198, November 2001.
[22] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J.,
Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March
2002.
[23] Bless, R., Nichols, K. and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", RFC
3662, December 2003.
[24] "QBone Scavenger Service (QBSS) Definition", Internet2
Technical Report Proposed Service Definition, March 2001.
Informative References
[25] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A.
Sastry, "The COPS (Common Open Policy Service) Protocol", RFC
2748, January 2000.
[26] Bernet, Y. and R. Pabbati, "Application and Sub Application
Identity Policy Element for Use with RSVP", RFC 2872, June
2000.
[27] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper for
Differentiated Services", RFC 2963, October 2000.
[28] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS
Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[29] Nichols, K. and B. Carpenter, "Definition of Differentiated
Services Per Domain Behaviors and Rules for their
Specification", RFC 3086, April 2001.
Baker, et al. Expires August 13, 2004 [Page 38]
Internet-Draft Document February 2004
Authors' Addresses
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA 93117
US
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Jozef Babiarz
Nortel Networks
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Canada
Phone: +1-613-763-6098
Fax: +1-613-768-2231
EMail: babiarz@nortelnetworks.com
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
US
Phone: +1-978-288-8175
Fax: +1-978-288-4690
EMail: khchan@nortelnetworks.com
Baker, et al. Expires August 13, 2004 [Page 39]
Internet-Draft Document February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Baker, et al. Expires August 13, 2004 [Page 40]
Internet-Draft Document February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Baker, et al. Expires August 13, 2004 [Page 41]
| PAFTECH AB 2003-2026 | 2026-04-23 17:41:13 |