One document matched: draft-baker-diffserv-basic-classes-00.txt
Internet Draft Fred Baker
draft-baker-diffserv-basic-classes-00.txt Cisco
Expires: December 2003 Jozef Babiarz
Kwok Ho Chan
Nortel Networks
June 2003
Configuration Guidelines for Basic Classes
of Managed Traffic
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This paper summarizes a recommended correlation of applications to
Differentiated Service Code Points (DSCP) and packet treatments in
the network. There is no intrinsic requirement that individual
DSCPs correspond to given applications, but as a policy it is
useful if they can be applied consistently.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC-2119].
Babiarz et al. Expires December 2003 [Page 1]
Internet Draft DiffServ-Basic-Classes June 2003
Table of Contents
1. Introduction....................................................3
1.1 Expected use in the Network....................................3
1.2 Key Differentiated Services Concepts...........................3
1.2.1 Queuing......................................................3
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)......................................7
1.3.3 Expedited Forwarding (EF)....................................8
1.3.4 Class Selector (CS)..........................................8
1.3.5 Admission Control............................................9
1.3.6 Service Differentiation......................................9
2. Traffic Categories and Service Classes.........................10
3.0 Network Control Traffic Category..............................12
3.1 Critical Service Class........................................13
3.2 Network Service Class.........................................14
4 User Traffic Categories.........................................15
4.1 Interactive Traffic Category..................................16
4.1.1 Premium Service Class.......................................16
4.1.2 Multimedia Service Class....................................18
4.2 Responsive Traffic Category...................................20
4.2.1 Streaming Service Class.....................................20
4.2.2 Human-Responsive Service Class..............................23
4.3 Timely Traffic Category.......................................24
4.3.1 Transaction Service Class...................................24
4.3.2 Standard Service Class......................................27
4.4 Scavenger Service Class.......................................27
5. Security Considerations........................................28
6. Acknowledgements...............................................28
7. Normative References...........................................28
8. Informative References.........................................30
9. Author's Address...............................................31
10. Full Copyright Statement......................................31
Babiarz et al. Expires December 2003 [Page 2]
Internet Draft DiffServ-Basic-Classes June 2003
1. Introduction
This paper summarizes a recommended correlation of applications to
Differentiated Service Code Points (DSCP), Per-Hop Behaviors (PHB)
and traffic conditioners. There is no intrinsic requirement that
particular DSCPs be used for certain applications, but as a policy
it is useful that DSCP marking, traffic conditioning and PHBs be
applied consistently across the network.
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.
- 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.
- In access networks, the state is often different. This may be
because throughput rates are artificially limited, or because of
access network design trade-offs.
- Other characteristics, such as database design on web servers
(which 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 finds itself
congested.
1.2 Key Differentiated Services Concepts
The reader must be familiar with the principles of the
Differentiated Services Architecture [8]. However, we recapitulate
key concepts here so 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"
Babiarz et al. Expires December 2003 [Page 3]
Internet Draft DiffServ-Basic-Classes June 2003
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
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[27][26] or WRR[28], 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.
Babiarz et al. Expires December 2003 [Page 4]
Internet Draft DiffServ-Basic-Classes June 2003
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 [25], in which 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 [11],
in which 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 which exceeds a stated rate at ingress is more
likely to be dropped or marked than traffic which was 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 [23]. This may be
used to bias feedback loops, such as is done in Assured Forwarding
[11], or to limit the amount of traffic in a system, as is done in
Expedited Forwarding [19]. Such measurement procedures are
collectively referred to as "traffic conditioners". Two traffic
conditioners that are use in deployment of differentiated services
that use Assured Forwarding are the Two Rate Three Color Marker
(trTCM) [18] and the Single Rate Three Color Marker (srTCM) [17].
Two Rate Three Color Marker:
The Two Rate Three Color Marker (trTCM) 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.
Babiarz et al. Expires December 2003 [Page 5]
Internet Draft DiffServ-Basic-Classes June 2003
Single Rate Three Color Marker:
The Single Rate Three Color Marker (srTCM) 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, which 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
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
Expedited Forwarding service for real-time (inelastic) traffic.
The terms "elastic" and "real-time" are defined in RFC 1633[2]
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[8] 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 Domain
(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 which 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
Babiarz et al. Expires December 2003 [Page 6]
Internet Draft DiffServ-Basic-Classes June 2003
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
definitions originates from RFC 2474 [7] 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 2474[7] and RFC 2309[6]. 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
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, service can also be provided,
for applications with congestion avoidance capabilities and is
considered to be of lower value to the network administration then
best effort traffic.
1.3.2 Assured Forwarding (AF)
The Assured Forwarding RFC 2597[11] service is explicitly modeled on
Frame Relay's DE flag or ATM's CLP capability, and is intended for
networks which 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
Babiarz et al. Expires December 2003 [Page 7]
Internet Draft DiffServ-Basic-Classes June 2003
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[19] 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 send packets at the rate the codec produces them,
regardless of availability of capacity. As such, this service has
the potential to disrupt or congest a network if not controlled. It
also has the potential for abuse.
To protect the network, at minimum one must police traffic at
various points to ensure that the design of a queue is not over-run,
and then the traffic must be given a low delay queue (often using
priority, although it is asserted that a rate-based queue can do
this) to ensure that variation in delay is not an issue, to meet
application needs.
1.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 [7] 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 Sec. 4.2.2.2.
Babiarz et al. Expires December 2003 [Page 8]
Internet Draft DiffServ-Basic-Classes June 2003
No attempt is made to maintain backward compatibility with the "DTR"
or TOS bits of the IPv4 TOS octet, as defined in [RFC 791].
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 call
admission control that is performed by a telephony call
server/gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.)
on access points to the network. The bandwidth for telephony service
on access points needs to be configured for the number of
simultaneous VoIP sessions supported. Another approach that may be
used in small and bandwidth constrained networks for limited number
of flows is RSVP[4][13]. However, there is concern with the
Scalability [5] of this solution in large networks and Aggregation
[15] 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 need to support
to provide the appropriated level of behaviors and performance
needed to support 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
application (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
Babiarz et al. Expires December 2003 [Page 9]
Internet Draft DiffServ-Basic-Classes June 2003
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 four categories, one network
control and three user/subscriber traffic categories. The term
"user" and "subscriber" are used interchangeable in this document.
Network control traffic can further be divided into two service
classes, mainly flows that are critical, require lower delay or
higher probability of being serviced and normal network control
flows. User/subscriber traffic is broken down into three user
traffic categories, interactive, responsive and timely as defined by
ITU-T Recommendation G.1010. These three user traffic categories
can further be subdivided into two 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 Recommendation Y.1541,
Y.1540 and G.1010. Additionally, network operators may choose to
define other service classes, like less than best effort or
Scavenger.
The service classes define the required treatment for the traffic in
order to meet user, application or network expectations. Section 3
defines the network control traffic category and section 4 defines
the user traffic categories 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. 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 applications they
support. Network administrators may choose to assign different
service class names, to the services that they will support. Table
1 below defines the relationship between traffic categories, service
classes and DS codepoint(s) assignment with application examples.
Babiarz et al. Expires December 2003 [Page 10]
Internet Draft DiffServ-Basic-Classes June 2003
------------------------------------------------------------------
| Traffic | Service | DSCP | DSCP | Application |
| Category | Class name | name | value | Example |
|-----------+------------+---------+-------------+-----------------|
| Network | Critical | CS7 | 111000 | Heartbeats |
| Control |------------+---------+-------------+-----------------|
| | Network | CS6 | 110000 | Network Routing |
|-----------+------------+---------+-------------+-----------------|
| | Premium | CS5, EF |101000,101010| IP Telephony |
|Interactive|------------+---------+-------------+-----------------|
| | Multimedia |CS4,AF41,|100000,100010| Video |
| | |AF42,AF41|100100,100110| Conferencing |
|-----------+------------+---------+-------------+-----------------|
| | Streaming |CS3,AF31,|011000,011010| Streaming |
| | |AF32,AF23|011100,011110| Media |
|Responsive |------------+---------+-------------+-----------------|
| | Human- |AF21, |010010, | Client/server |
| | Responsive |AF22,AF23|010100,010110| transactions |
|-----------+------------+---------+-------------+-----------------|
| |Transactioin|CS2,AF11,|010000,001010|Store and forward|
| | |AF12,AF13|001100,001110| applications |
| Timely |------------+---------+-------------+-----------------|
| | Standard | DF,(CS0)| 000000 | Undifferentiated|
| | | | | applications |
|-----------+------------+---------+-------------+-----------------|
| Other | Scavenger | CS1 | 001000 |Any flow that has|
| | | | | no BW assurance |
------------------------------------------------------------------
Table 1: DSCP to Service Category and Class Mapping
Note: The Class Selector 3-4 codepoints are aliases of AF31-AF41
codepoints, Class Selector 2 codepoint is alias to AF11 and Class
Selector 5 codepoint is alias of EF codepoint. Default Forwarding
and Class Selector 0 provide equivalent behavior and use the same
DS codepoint.
Table 2 provides a summary of DiffServ QoS mechanisms used for the
nine different service classes that are further defined in Section
3 and 4 of this document. Note, network operators normally would
only implement subset of the defined service classes.
Babiarz et al. Expires December 2003 [Page 11]
Internet Draft DiffServ-Basic-Classes June 2003
------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | Queuing| AQM |
| Class | | DS Edge | Reference| | |
|-----------+------+-------------------+----------+--------+-------|
| Critical | CS7 |Police using sr+bs | RFC 2474 |Priority| No |
|-----------+------+-------------------+----------+--------+-------|
| Network | CS6 |Police using sr+bs | RFC 2474 | Rate | No |
|-----------+------+-------------------+----------+--------+-------|
| Premium |EF,CS5|Police using sr+bs | RFC 3246 |Priority| No |
|-----------+------+-------------------+----------+--------+-------|
| | AF41 | | | | Yes |
| | AF42 | Using trTCM | | Rate | per |
| Multimedia| AF43 | (RFC 2698) | RFC 2597 | | DSCP |
| |------+-------------------| | |-------|
| | CS4 |Police using sr+bs | | | Yes |
|-----------+------+-------------------+----------+--------+-------|
| | AF31 | Police using sr+bs| | | |
| |------+-------------------| | | Yes |
| Streaming | AF32 | Police sum using | | Rate | per |
| | AF33 | sr+bs | RFC 2597 | | DSCP |
| |------+-------------------| | |-------|
| | CS3 |Police using sr+bs | | | Yes |
|-----------+------+-------------------+----------+--------+-------|
| Human- | AF21 | | | Rate | Yes |
| Responsive| AF22 | Using trTCM | RFC 2597 | | per |
| | AF23 | (RFC 2698) | | | DSCP |
|-----------+------+-------------------+----------+--------+-------|
| | AF11 | | | | Yes |
| | AF12 | Using trTCM | | Rate | per |
|Transaction| AF13 | (RFC 2698) | RFC 2597 | | DSCP |
| |------+-------------------| | |-------|
| | CS2 |Police using sr+bs | | | Yes |
|-----------+------+-------------------+----------+--------+-------|
| Standard | DF | Not applicable | RFC 2474 | Rate | Yes |
|-----------+------+-------------------+----------+--------+-------|
| Scavenger | CS1 | Not applicable | RFC 2474 | Rate | Yes |
------------------------------------------------------------------
Table 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
rate with burst size control.
3.0 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
Babiarz et al. Expires December 2003 [Page 12]
Internet Draft DiffServ-Basic-Classes June 2003
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
operator may choose to split the network control traffic into two
service classes i.e., critical network control and normal network
control and provide two different forwarding treatments or just
support one forwarding treatment for all network control flows.
3.1 Critical Service Class
The Critical 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 administrated 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 Critical service class uses the DiffServ Class Selector (CS) PHB
defined in RFC 2474 [7] and should be configured to receive sufficed
forwarding resources so that all packets are forwarded quickly. The
Critical service class should be configured to use Priority Queuing
system such as defined in Section 1.2.1.1 of this document.
The following protocols and application should use the Critical
service class:
- Network administrator telnet sessions from secure and trusted
terminals
- Protocol(s) that are transmitted between nodes within the
administered network for detecting of link and nodal failures
- Used for critical control traffic within an administrative
domain
- May be used for any control traffic that is forwarded within the
administered network domain
- User traffic must not be mapped into this service class
- Inter-network domain (across peering points) control traffic
must not be mapped into this service class
Traffic characteristics of critical control packet flows:
- Mostly messages between routers and network servers
- Typically 50 to 200 byte packet sizes, one packet at a time
- No user-to-user traffic is allowed to use this service class
Babiarz et al. Expires December 2003 [Page 13]
Internet Draft DiffServ-Basic-Classes June 2003
Recommended DSCP marking is CS7 (Class Selector 7)
Network edge conditioning:
- Drop or remark CS7 marked packets at ingress to DiffServ network
domain.
- 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 Service Class
The Network service class is used for transmitting packets between
network devices (routers, servers, etc.) that require control
information to be exchanged between different administrative domains
(across a peering point) and for non-critical network control
information exchange within one administrative domain. Traffic
transmitted in this service class is very important as it keeps the
network operational and needs to be forwarded in a timely manner.
The Network service class uses the DiffServ Class Selector (CS) PHB
defined in RFC 2474 [7]. This service class is 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 service class should be such that the
probability of packet drop under peak load is very low in this
service class. The Network service class should be configured to use
Rate Queuing system such as defined in Section 1.2.1.2 of this
document.
The following protocols and applications should use the Network
service class:
- Routing packet flows, OSPF, BGP, ISIS, RIP, ICMP
- Policy management flows between nodes in the network, COPS,
RSVP, RSVP-TE, etc.
- SIP signaling between high capacity telephony call servers or
soft switches. Such high capacity devices may control thousands
of telephony (VoIP) calls.
- Network services, DNS, DHCP, BootP, high priority OAM (SNMP)
like alarms, etc.
- Used for control information exchange within and between
different administrative domains across a peering point where
SLAs are in place.
- In 3GPP wireless solutions, used to transport UMTS Signaling
information between wireless nodes
- User traffic must not be mapped into this service class
Traffic characteristics of network control packet flows:
- Mostly messages between routers and network servers
- Ranging from 50 to 1,500 byte packet sizes, normally one packet
at a time but traffic can also burst (BGP)
- No user-to-user traffic is allowed to use this service class
Babiarz et al. Expires December 2003 [Page 14]
Internet Draft DiffServ-Basic-Classes June 2003
Recommended DSCP marking is CS6 (Class Selector 6)
Network edge conditioning:
- 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.
- CS6 marked packet flows from untrusted sources (end user
devices) are dropped or remarked at ingress to DiffServ network.
Packets from users are not permitted access to the Network or
Critical service classes
If Critical service class is not supported, then the Network service
class is used for both normal network control traffic and critical
control traffic defined in this document and packets marked with CS7
DSCP receive the same forwarding treatment as CS6 marked packets.
4 User Traffic Categories
User traffic is divided into three different categories, namely,
interactive, responsive and timely. 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 is needed. Responsive traffic
is typically between a human and a server but also can 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. The three traffic
categories follow methodology defined by ITU-T Recommendation Y.1541
and G.1010.
To put this into perspective:
- Interactive traffic requires a delay performance through the IP
network on the order of 10s of milliseconds
- Responsive traffic requires a delay performance through the IP
network on the order of 100s of milliseconds
- Timely traffic requires a delay performance through the IP
network of less than 1 second.
Network operators can categorize their applications based on the
type of behavior that they require. Table 1 provides some common
applications and the forwarding service class that best supports
them based on their performance requirements.
In summary:
- Premium service class is best suited for IP telephony (VoIP) and
circuit emulation over IP applications.
Babiarz et al. Expires December 2003 [Page 15]
Internet Draft DiffServ-Basic-Classes June 2003
- Multimedia service class is best suited for applications that
require very low delay but are of variable rate in nature, such
as video conferencing and interactive gaming.
- Streaming service class is best suited for streaming media
applications.
- Human-Responsive service class is best suited for interactive
client / server applications.
- Transaction service class is best suited for store and forward
applications such as FTP.
- Standard service class is for traffic that has not bean
identified as requiring differentiated treatment and is normally
referred as being best effort.
- Scavenger service class is intended for traffic or networks
where bandwidth assurance is not required.
Note, a network operator may choose to support all or subsets of the
defined service classes and provide service differentiation only to
the applications/service that are mapped into them.
4.1 Interactive Traffic Category
Interactive traffic category can be further split into two service
classes, Premium and Multimedia to provide differentiation based on
the different behavior of source traffic being forwarded.
4.1.1 Premium Service Class
Used for applications that require real-time, low delay, very low
packet loss for relatively constant-rate traffic sources (inelastic
traffic sources). This forwarding class is used predominantly for IP
telephony services and provides the low latency, jitter and loss
required.
The fundamental service offered to traffic in Premium service class
is best effort service up to a specified upper bound with low delay
and very low packet loss. Operation is in some respect similar to an
ATM CBR service, which has guaranteed bandwidth and if it stays
within the negotiated rate it 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 has verified that the newly admitted data rates will be
within the capacity of the Premium service class forwarding
capability in the network that it will use. For VoIP (telephony)
service, the common approach is to use call admission control
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
Babiarz et al. Expires December 2003 [Page 16]
Internet Draft DiffServ-Basic-Classes June 2003
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 respond to loss or substantial delay in
any substantive way, the Premium service class should forward packet
as soon as possible.
The Premium service class uses Expedited Forwarding (EF) PHB as
defined in RFC 3246 [19] and must be configured to receive
guaranteed forwarding resources so that all packets are forwarded
quickly. The Premium service class should be configured to use
Priority Queuing system such as defined in Section 1.2.1.1 of this
document.
Target applications for Premium service class:
- VoIP (G.711, G.729 and other codecs)
- Telephony signaling between end device (terminals/gateways) and
the call server (H.248, MEGACO, H.323, SIP)
- Lawful Intercept
- T.38 fax over IP
- Voice-band data over IP (modem, fax)
- Circuit emulation over IP, virtual wire, etc.
- In wireless 3GPP applications, used to forward traffic that is
mapped into the UMTS Conversational Traffic Class
Traffic characteristics:
- Mostly fixed size packets for VoIP (60 or 70 or 120 or 200 bytes
in size)
- Packet emitted at constant time intervals
- Admission control of new flows is provided by telephony call
server, media gateway, gatekeeper or access node that provides
"middlebox" function.
Recommended DSCP marking EF for the following applications:
- VoIP (G.711, G.729 and other codecs)
- Lawful Intercept
- Voice-band data over IP (modem)
- Circuit emulation over IP, virtual wire, etc.
- Conversational UMTS Traffic Class
Recommended DSCP marking CS5 for the following applications:
- Telephony signaling between end device (terminals/gateways) and
the call server (H.248, MEGACO, H.323, SIP)
- T.38 fax over IP
Both EF and CS5 DS codepoints are mapped into the Premium service
classes and 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.
Network Edge Conditioning:
- Packet flows from untrusted sources (end user devices) must be
policed at ingress to DiffServ network using single rate with
Babiarz et al. Expires December 2003 [Page 17]
Internet Draft DiffServ-Basic-Classes June 2003
burst size token bucket policer to ensure that the telephony
traffic stays within its negotiated bounds.
- Packet flows from trusted sources (media gateways inside
administered network) do not require policing.
- Policing of Premium packet flows across peering points where SLA
is in place is also not required as telephony traffic will be
controlled by admission control mechanism between peering
points.
Note: On low speed links (typically access links below 1Mbps), 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 i.e. 60
bytes in size were T.38 fax and signaling packets are much bigger.
The serialization delay, 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 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 where as T.38 fax or telephony signaling
have a more liberal jitter/delay constrain and should use Rate
Queuing system on access links below 1 Mbps.
On higher speed links the difference in serialization delay is very
small, therefore both types of telephony packet flows are aggregated
in to a single forwarding service class to simplify network
engineering and use Priority Queuing system. As well, 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, therefore virtually
eliminating speech clipping and ring-clipping problems at start of
call when interfacing to PSTN.
4.1.2 Multimedia Service Class
Used for applications that requires real-time and low delay for
variable rate elastic traffic source. The traffic sources
(applications) in this traffic class have the capability to change
their emitting 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 based on pre-configured
encoding rates (or transmitting rates) selects a lower rate for
transmission.
Typical video conferencing configurations negotiate the setup of
multimedia session using protocols such as H.323 or SIP. When a
Babiarz et al. Expires December 2003 [Page 18]
Internet Draft DiffServ-Basic-Classes June 2003
user/end-point has been authorized to start a multimedia session the
admission procedure has verified that the newly admitted data rates
will be within the engineered capacity of the Multimedia service
class. The bandwidth in the core network and the number of
simultaneous video conferencing sessions that can be supported needs
to be engineered to control traffic load for this service.
The Multimedia service class uses the Assured Forwarding (AF) PHB
defined in RFC 2597 [11]. This service class is configured to
provide a bandwidth assurance for AF41, AF42, AF43 and CS4 marked
packets to ensure that they get forwarded. The Multimedia service
class should be configured to use Rate Queuing system such as
defined in Section 1.2.1.2 of this document.
Target application for Multimedia service class:
- Video conferencing (interactive video)
- Interactive gaming
- Server to server data transfer requiring very low delay
- IP VPN service that specifies two rates and mean network delay
that is slightly longer then network propagation delay.
Interactive, time critical and mission critical application
maybe encapsulated into this VPN service.
- In wireless 3GPP applications, used to forward traffic that is
mapped into the UMTS Interactive Traffic Class with Traffic
Handling Priority 1 (THP=1)
Traffic characteristics:
- Variable size packets (50 to 1500 bytes in size)
- Higher the rate, higher density of large packets
- Variable packet emission time
- Source capable of reducing its transmission rate based on
detection of packet loss at the receiver
Both the AF4x and CS4 DS codepoints are mapped into the Multimedia
service class and used the Assured Forwarding (AF) PHB. The CS4 DS
codepoint is aliased to the AF41 DS codepoint and packets marked
with CS4 are forwarded using the AF41 PHB.
Packet Marking:
- Interactive gaming packets are marked with CS4
- Video conferencing packets are marked with AF4x
- VPN service may be marked with AF4x or CS4 depending on the
service characteristics
- Server to server data transfer with AF4x or CS4 depending on the
service characteristics
- UMTS Interactive THP=1 packets are marked with AF4x
Packet flows from video conferencing equipment may be marked by the
video conferencing equipment or by the edge router using Two Rate
Three Color Marked (trTCM) as specified in RFC 2698 [18].
Example of DSCP marking when performed by video conferencing
equipment:
Babiarz et al. Expires December 2003 [Page 19]
Internet Draft DiffServ-Basic-Classes June 2003
- AF41 = H.323 video conferencing audio stream RTP/UDP
- AF41 = H.323 video conferencing video control RTCP/TCP
- AF41 = H.323 video conferencing video stream below specified
rate "A"
- AF42 = H.323 video conferencing video stream between specified
rate "A" and "B"
- AF43 = H.323 video conferencing video stream above specified
rate "B"
- Where rate "B" is greater in magnitude than rate "A"
Conditioning Performed at DiffServ Network Edge:
The Two Rate Three Color Marker (trTCM) should be used as specified
in RFC 2698 [18].
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.
Conditioning Requirements for CS4 marked Packets:
At DiffServ edge and boundary policing of CS4 marked packets must
be performed so both rate and burst size can be enforced.
The fundamental service offered to "Multimedia" traffic is 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 encoding rate change, drop to next lower
provisioned video encoding rate. As such, Active Queue Management
[6] is used primarily to switch video encoding rate under
congestion, change from high rate to lower rate i.e. 1472 kbps to
768 kbps. The probability of loss of AF41 and CS4 traffic may not
exceed the probability of loss of AF42 traffic, which in turn may
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, Streaming and Human-Responsive to provide differentiation
based on the different behavior of source traffic being forwarded.
4.2.1 Streaming Service Class
The Streaming service class is used for applications that require
near-real-time packet forwarding of variable rate traffic sources
which are not as delay sensitive as applications using the
Multimedia service class. Such applications include broadcast TV,
streaming audio and video, video (movies) on demand and surveillance
Babiarz et al. Expires December 2003 [Page 20]
Internet Draft DiffServ-Basic-Classes June 2003
video. In general, the Streaming service class assumes that the
traffic is buffered at the source/destination and therefore, is less
sensitive to delay and jitter.
The Streaming service class uses the Assured Forwarding (AF) PHB
defined in RFC 2597 [11]. This service class is configured to
provide a minimum bandwidth assurance for AF31, AF32, AF33 and CS3
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.
Target application for Streaming service class:
- Video surveillance and security (unicast)
- TV broadcast including HDTV (multicast)
- Pay per view movies and events (pre scheduled)
- Video on demand (unicast) with control (virtual DVD)
- Streaming audio (unicast)
- Streaming video (unicast)
- Web casts
- VPN service that supports different levels of flow assurance
- In wireless 3GPP applications, used to forward traffic that is
mapped into the UMTS Streaming Traffic Class
Traffic Characteristics:
- Variable size packets (50 to 4196 bytes in size)
- Higher the rate, higher density of large packets
- Variable packet emission rate
- Some bursting at start of flow from some applications
- At about 2% packet loss, video session is usually terminated
Both the AF3x and CS3 DS codepoints are mapped into the Streaming
service classes and used the Assured Forwarding (AF) PHB. The CS3 DS
codepoint is aliased to the AF31 DS codepoint and packets marked
with CS3 are forwarded using the AF31 PHB.
Applications or end systems pre-mark their packets with DSCP values
as shown in Table 3 below. If host is unable to pre-mark their
packets, then marking is performed on the DiffServ edge router using
MF classification. Due to the nature of the service, it is
recommended that video surveillance and security flows are market
with a different DSCP value so that traffic conditioning and
policing policies can be different from other flows in the Streaming
service class.
Babiarz et al. Expires December 2003 [Page 21]
Internet Draft DiffServ-Basic-Classes June 2003
------------------------------------------------------------------
| Applications | Protocol |DSCP|
|------------------------------------+------------------------+----|
|Video surveillance and security |For RTP/UDP payload and |CS3 |
| (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|
------------------------------------------------------------------
Table 3: Example of DSCP marking for Streaming
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 CS3 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 CS3 marked packets, another for
AF31 marked packets and the third policer for AF32 and AF33 marked
packets. Packet flows from trusted sources i.e. TV broadcast
servers, etc. normally do not require policing.
The fundamental service offered to "Streaming" traffic is best
effort service with controlled rate and delay. This traffic does not
respond dynamically to packet loss. Packets marked with AF31 and CS3
DSCP requires very high assurance of delivery. Packets marked with
AF32 and AF33 can generally tolerated up to 1% and 2% packet loss
respectfully. As such, Active Queue Management [6] is used primarily
to reduce the number of flows at congestion points by dropping
packets from less important flows first before any AF31 and CS3
marked packets are dropped. The service should be provisioned so
Babiarz et al. Expires December 2003 [Page 22]
Internet Draft DiffServ-Basic-Classes June 2003
that CS3 and AF31 marked packet flows have high assurance for
bandwidth in the network. The probability of loss of AF31 and CS3
traffic may not exceed the probability of loss of AF32 traffic,
which in turn may not exceed the probability of loss of AF33.
4.2.2 Human-Responsive Service Class
The Human-Responsive service class is used for elastic and
responsive typically client/server based applications. Applications
forwarded by this service class are those requiring a relatively
fast response and typically have asymmetrical bandwidth need, i.e.
the client typically sends a short message to the server and the
server responds with a much larger data flow back to the client.
The most common example of this is when a user clicks a hyperlink
(~few dozen bytes) on a web page resulting in a new web page to be
loaded (Kbytes of data). This service class is configured to provide
good response for TCP [1] short lived flows that require real-time
packet forwarding of variable rate traffic sources.
The Human-Responsive service class uses the Assured Forwarding (AF)
PHB defined in RFC 2597 [11]. This service class is configured to
provide a minimum bandwidth assurance for AF21, AF22 and AF23 marked
packets to ensure that they get forwarded. The Human-Responsive
service class should be configured to use Rate Queuing system such
as defined in Section 1.2.1.2 of this document.
Target applications for Human-Responsive service class:
- Client / server applications
- SNA terminal to host transactions (SNA over IP using DLSw)
- Web based transactions (E-commerce)
- Credit card transactions
- Financial wire transfers
- ERP applications (.e.g. SAP / BaaN)
- VPN service that supports CIR (Committed Information Rate) with
up to two burst sizes
- In wireless 3GPP applications, used to forward traffic that is
mapped into the UMTS Interactive Traffic Class with Traffic
Handling Priority 2 (THP=2)
Traffic Characteristics:
- Variable size packets (50 to 1500 bytes in size)
- Variable packet emission rate
- With packet bursts of TCP window size
- Source capable of reducing its transmission rate based on
detection of packet loss at the receiver or through explicit
congestion notification.
The AF2x DS codepoints are mapped into the Human-Responsive service
classes and use the Assured Forwarding (AF) PHB.
DSCP marking:
Babiarz et al. Expires December 2003 [Page 23]
Internet Draft DiffServ-Basic-Classes June 2003
- Inelastic packet flows are marked with AF21
- Elastic TCP flows are marked with AF2x
- VPN service may be marked with AF2x depending on the service
characteristics
- UMTS Interactive THP=2 packets are marked with AF2x
Marking of the DSCP may be performed by a host or by an edge router.
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 node and on
DiffServ boundary node. The Human-Responsive service class uses a
Single Rate Three Color Marker (srTCM) conditioner for AF2x flows.
Conditioning Requirements for AF2x marked packets:
Conditioning of aggregated packet flows destined for the Human-
Responsive 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 [17].
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) then the srTCM should be configured to operate in
the Color-Aware mode.
The fundamental service offered to "Human-Responsive" traffic is
best effort service with controlled rate and delay. The service
should be engineered so that AF21 marked packet flows have sufficed
bandwidth in the network to provide high assurance of delivery.
Since this traffic is elastic and responds dynamically to packet
loss, Active Queue Management [6] is used primarily to control TCP
flow rates at congestion points by dropping packet from TCP flows
where the burst length is high (AF23 and AF22 marked packets) first
before any AF21 packets are dropped. The probability of loss of AF21
traffic may not exceed the probability of loss of AF22 traffic,
which in turn may not exceed the probability of loss of AF23. Active
queue management may also be implemented using Explicit Congestion
Notification (ECN) [17] method as defined in RFC 3168.
4.3 Timely Traffic Category
Timely traffic category can be further split into two service
classes, Transaction and Standard to provide differentiation based
on the different behavior of source traffic being forwarded.
4.3.1 Transaction Service Class
Babiarz et al. Expires December 2003 [Page 24]
Internet Draft DiffServ-Basic-Classes June 2003
The Transaction service class is configured to support 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[1] or a transport with a
consistent Congestion Avoidance Procedure[9][10] 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 Transaction service class uses the Assured Forwarding (AF) PHB
defined in RFC 2597 [11]. This service class is configured to
provide a minimum bandwidth assurance for AF11, AF12, AF13 and CS2
marked packets to ensure that they are forwarded. The Transaction
service class should be configured to use Rate Queuing system such
as defined in Section 1.2.1.2 of this document.
Target applications for Transaction service class:
- Store and forward applications
- File transfer applications
- Email
- Non-critical OAM&P (Operation and Management and Provisioning)
using SNMP, XML, etc.
- VPN service that supports CIR (Committed Information Rate) with
up to two burst sizes
- In wireless 3GPP applications, used to forward traffic that is
mapped into the UMTS Interactive Traffic Class with Traffic
Handling Priority 3 (THP=3)
Traffic Characteristics:
- Variable size packets (50 to 1500 bytes in size)
- Variable packet emission rate
- With packet bursts of TCP window size
- 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 are mapped into the Transaction
service classes and use the Assured Forwarding (AF) PHB. The CS2 DS
codepoint is aliased to the AF11 DS codepoint and packets marked
with CS1 are forwarded using the AF11 PHB.
DSCP marking:
- Non-critical OAM&P (SNMP, XML, etc.) packets are marked with CS2
- Elastic TCP flows are marked with AF1x
- VPN service may be marked with AF1x or CS2 depending on the
service characteristics
- 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 Transaction 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 Transaction service class. The marking of non-
Babiarz et al. Expires December 2003 [Page 25]
Internet Draft DiffServ-Basic-Classes June 2003
critical OAM&P traffic with CS2 DS codepoint is recommended so that
different conditioning and policing policies can be used for non-
critical OAM&P and other transaction traffic.
Marking of the DSCP may be performed by a host or by an edge router.
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 Transaction service class uses
a Single Rate Three Color Marker (srTCM) conditioner for AF1x flows
and a single rate policer with a burst size limit for CS2 flows.
Conditioning Requirements for AF1x marked Packets:
Conditioning of aggregated packet flows destined for the
Transaction service class must be performed at the DiffServ edge of
the network. Furthermore, conditioning should be performed as
defined in RFC 2697 [17].
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.
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 "Transaction" traffic is 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 [14] as
defined in RFC 3168 or random packet dropping to implement Active
Queue Management [6] and may impose a minimum or maximum rate. The
probability of loss of AF11 traffic may not exceed the probability
of loss of AF12 traffic, which in turn may 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) should not be put
through Active Queue Management [6] function.
Babiarz et al. Expires December 2003 [Page 26]
Internet Draft DiffServ-Basic-Classes June 2003
4.3.2 Standard Service Class
The Standard service class is used for all 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 uses the Default Forwarding (DF) PHB
defined in RFC 2474 [7] and should be configured to receive a small
percentage of forwarding resources (at least 5%). This service class
should be configured to use Rate Queuing system such as defined in
Section 1.2.1.2 of this document.
Target application for the Standard service class:
- Any undifferentiated application/packet flow transported through
the DiffServ enabled network
- In wireless 3GPP applications, used to forward traffic that is
mapped into the UMTS Background Traffic Class
Traffic Characteristics:
- Non deterministic, mixture of everything
The 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 use Explicit Congestion Notification
[14] or random packet dropping to implement Active Queue Management
[6], and may impose a minimum or maximum rate on the queue.
4.4 Scavenger Service Class
The Scavenger service class serves applications which run over TCP
[1] or a transport with a consistent congestion avoidance procedure
[9][10], and which the user is willing to accept service without
guarantees. This service class is specified in [20].
Target application for the Scavenger service class:
- Any TCP based application/packet flow transported through the
DiffServ enabled network that does not require any bandwidth
assurances.
Traffic Characteristics:
- Non real-time and elastic.
The DSCP marking is CS1 (Class Selector 1)
Babiarz et al. Expires December 2003 [Page 27]
Internet Draft DiffServ-Basic-Classes June 2003
Network Edge Conditioning:
There is no requirement that conditioning of packet flows be
performed for this service class.
The fundamental service offered to the scavenger 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 use Explicit Congestion Notification [14] or
random loss to implement active queue management [6].
5. 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 which 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.
6. Acknowledgements
The authors acknowledge a great many inputs, most notably from Bruce
Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet.
Kimberly King, Joe Zebarth and Alistair Munroe each did a thorough
proof-reading, and the document is better for their contributions.
7. Normative References
[1] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, RFC 793,
September 1981.
Babiarz et al. Expires December 2003 [Page 28]
Internet Draft DiffServ-Basic-Classes June 2003
[2] BRADEN, B., CLARK, D. and S. SHENKER, "INTEGRATED SERVICES IN
THE INTERNET ARCHITECTURE: AN OVERVIEW", RFC 1633, June 1994.
[3] BRADNER, S., "KEY WORDS FOR USE IN RFCS TO INDICATE REQUIREMENT
LEVELS", BCP 14, RFC 2119, March 1997.
[4] ZHANG, L., BERSON, S., HERZOG, S. and S. JAMIN, "RESOURCE
RESERVATION PROTOCOL (RSVP) -- VERSION 1 FUNCTIONAL SPECIFICATION",
RFC 2205, September 1997.
[5] BAKER, F., KRAWCZYK, J. and A. SASTRY, "RSVP MANAGEMENT
INFORMATION BASE USING SMIV2", RFC 2206, September 1997.
[6] 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.
[7] 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.
[8] BLAKE, S., BLACK, D., CARLSON, M., DAVIES, E., WANG, Z. and W.
WEISS, "AN ARCHITECTURE FOR DIFFERENTIATED SERVICES", RFC 2475,
December 1998.
[9] ALLMAN, M., PAXSON, V. and W. STEVENS, "TCP CONGESTION
CONTROL", RFC 2581, April 1999.
[10] FLOYD, S. and T. HENDERSON, "THE NEWRENO MODIFICATION TO TCP'S
FAST RECOVERY ALGORITHM", RFC 2582, April 1999.
[11] HEINANEN, J., BAKER, F., WEISS, W. and J. WROCLAWSKI, "ASSURED
FORWARDING PHB GROUP", RFC 2597, June 1999.
[12] HERZOG, S., "RSVP EXTENSIONS FOR POLICY CONTROL", RFC 2750,
January 2000.
[13] Bernet, Y., "FORMAT OF THE RSVP DCLASS OBJECT", RFC 2996,
November 2000.
[14] Ramakrishnan, K., Floyd, S. and D. Black, "THE ADDITION OF
EXPLICIT CONGESTION NOTIFICATION (ECN) TO IP", RFC 3168, September
2001.
[15] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,
"AGGREGATION OF RSVP FOR IPV4 AND IPV6 RESERVATIONS", RFC 3175,
September 2001.
[16] Herzog, S., "SIGNALED PREEMPTION PRIORITY POLICY ELEMENT", RFC
3181, October 2001.
Babiarz et al. Expires December 2003 [Page 29]
Internet Draft DiffServ-Basic-Classes June 2003
[17] Heinanen, J. and Guerin, R. "A SINGLE RATE THREE COLOR MARKER",
RFC 2697, September 1999.
[18] Heinanen, J. and Guerin, R. "A TWO RATE THREE COLOR MARKER",
RFC 2698, September 1999.
[19] 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.
[20] "QBone Scavenger Service (QBSS) Definition", Internet2
Technical Report Proposed Service Definition, March 2001.
8. Informative References
[21] DURHAM, D., BOYLE, J., COHEN, R., HERZOG, S., RAJAN, R. and A.
SASTRY, "THE COPS (COMMON OPEN POLICY SERVICE) PROTOCOL", RFC 2748,
January 2000.
[22] Bernet, Y. and R. Pabbati, "APPLICATION AND SUB APPLICATION
IDENTITY POLICY ELEMENT FOR USE WITH RSVP", RFC 2872, June 2000.
[23] Bonaventure, O. and S. De Cnodder, "A RATE ADAPTIVE SHAPER FOR
DIFFERENTIATED SERVICES", RFC 2963, October 2000.
[24] 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.
[25] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for
Congestion Avoidance", IEEE/ACM Transactions on Networking , August
1993.
[26] Zhang, L., "Virtual Clock: A New Traffic control Algorithm for
Packet Switching Networks", ACM SIGCOMM 1990, September 1990.
[27] Keshav, S., "On the Efficient Implementation of Fair Queueing",
Internetworking: Research and Experiences Vol 2, September 1991.
[28] Katevenis, M., Sidiropoulos, S. and C. Courcoubetis, "Weighted
Round-Robin Cell Multiplexing in a General Purpose ATM Switch Chip",
IEEE JSAC Vol. 9, No. 8, October 1991.
[29] "International Emergency Preparedness Scheme", ITU E.106, March
2000.
[30] "Service Description for an International Emergency Multimedia
Service (Draft)", ITU-T F.706, August 2001.
Babiarz et al. Expires December 2003 [Page 30]
Internet Draft DiffServ-Basic-Classes June 2003
9. Author's Address
Jozef Babiarz
Nortel Networks
3500 Carling Avenue
Ottawa, Ont. Canada
K2H 8E9
Phone: +1-613-763-6098
Fax: +1-613-768-2231
EMail: babiarz@nortelnetworks.com
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA 93117 USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821 USA
Phone: +1-978-288-8175
Fax: +1-978-288-4690
EMail: khchan@nortelnetworks.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2003). 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 assigns.
Babiarz et al. Expires December 2003 [Page 31]
Internet Draft DiffServ-Basic-Classes June 2003
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Babiarz et al. Expires December 2003 [Page 32]
| PAFTECH AB 2003-2026 | 2026-04-23 12:54:36 |