draft-ietf-tsvwg-diffserv-service-classes-02.txt   rfc4594.txt 
TSVWG J. Babiarz Network Working Group J. Babiarz
Internet-Draft K. Chan Request for Comments: 4594 K. Chan
Expires: August 20, 2006 Nortel Networks Category: Informational Nortel Networks
F. Baker F. Baker
Cisco Systems Cisco Systems
February 16, 2006 August 2006
Configuration Guidelines for DiffServ Service Classes Configuration Guidelines for DiffServ Service Classes
draft-ietf-tsvwg-diffserv-service-classes-02
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 20, 2006. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes service classes configured with Diffserv, This document describes service classes configured with Diffserv and
recommends how they can be used and how to construct them using recommends how they can be used and how to construct them using
Differentiated Service Code Points (DSCP), traffic conditioners, Per- Differentiated Services Code Points (DSCPs), traffic conditioners,
Hop Behaviors (PHB), and Active Queue Management (AQM) mechanisms. Per-Hop Behaviors (PHBs), and Active Queue Management (AQM)
There is no intrinsic requirement that particular DSCPs, traffic mechanisms. There is no intrinsic requirement that particular DSCPs,
conditioners, PHBs, and AQM be used for a certain service class, but traffic conditioners, PHBs, and AQM be used for a certain service
as a policy and for interoperability it is useful to apply them class, but as a policy and for interoperability it is useful to apply
consistently. them consistently.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation ......................................4
1.2. Expected use in the Network . . . . . . . . . . . . . . . 5 1.2. Expected Use in the Network ................................4
1.3. Service Class Definition . . . . . . . . . . . . . . . . . 5 1.3. Service Class Definition ...................................5
1.4. Key Differentiated Services Concepts . . . . . . . . . . . 6 1.4. Key Differentiated Services Concepts .......................5
1.4.1. Queuing . . . . . . . . . . . . . . . . . . . . . . . 6 1.4.1. Queuing .............................................6
1.4.1.1. Priority Queuing . . . . . . . . . . . . . . . . . 7 1.4.1.1. Priority Queuing ...........................6
1.4.1.2. Rate Queuing . . . . . . . . . . . . . . . . . . . 7 1.4.1.2. Rate Queuing ...............................6
1.4.2. Active Queue Management . . . . . . . . . . . . . . . 7 1.4.2. Active Queue Management .............................7
1.4.3. Traffic Conditioning . . . . . . . . . . . . . . . . . 8 1.4.3. Traffic Conditioning ................................7
1.4.4. Differentiated Services Code Point (DSCP) . . . . . . 9 1.4.4. Differentiated Services Code Point (DSCP) ...........8
1.4.5. Per-Hop Behavior (PHB) . . . . . . . . . . . . . . . . 9 1.4.5. Per-Hop Behavior (PHB) ..............................8
1.5. Key Service Concepts . . . . . . . . . . . . . . . . . . . 9 1.5. Key Service Concepts .......................................8
1.5.1. Default Forwarding (DF) . . . . . . . . . . . . . . . 9 1.5.1. Default Forwarding (DF) .............................9
1.5.2. Assured Forwarding (AF) . . . . . . . . . . . . . . . 10 1.5.2. Assured Forwarding (AF) .............................9
1.5.3. Expedited Forwarding (EF) . . . . . . . . . . . . . . 10 1.5.3. Expedited Forwarding (EF) ..........................10
1.5.4. Class Selector (CS) . . . . . . . . . . . . . . . . . 11 1.5.4. Class Selector (CS) ................................10
1.5.5. Admission Control . . . . . . . . . . . . . . . . . . 11 1.5.5. Admission Control ..................................11
2. Service Differentiation . . . . . . . . . . . . . . . . . . . 12 2. Service Differentiation ........................................11
2.1. Service Classes . . . . . . . . . . . . . . . . . . . . . 12 2.1. Service Classes ...........................................12
2.2. Categorization of User Service Classes . . . . . . . . . . 13 2.2. Categorization of User Service Classes ....................13
2.3. Service Class Characteristics . . . . . . . . . . . . . . 17 2.3. Service Class Characteristics .............................16
2.4. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 22 2.4. Deployment Scenarios ......................................21
2.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 22 2.4.1. Example 1 ..........................................21
2.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 23 2.4.2. Example 2 ..........................................23
2.4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 26 2.4.3. Example 3 ..........................................25
3. Network Control Traffic . . . . . . . . . . . . . . . . . . . 27 3. Network Control Traffic ........................................27
3.1. Current Practice in The Internet . . . . . . . . . . . . . 28 3.1. Current Practice in the Internet ..........................27
3.2. Network Control Service Class . . . . . . . . . . . . . . 28 3.2. Network Control Service Class .............................27
3.3. OAM Service Class . . . . . . . . . . . . . . . . . . . . 30 3.3. OAM Service Class .........................................29
4. User Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 31 4. User Traffic ...................................................30
4.1. Telephony Service Class . . . . . . . . . . . . . . . . . 32 4.1. Telephony Service Class ...................................31
4.2. Signaling Service Class . . . . . . . . . . . . . . . . . 33 4.2. Signaling Service Class ...................................33
4.3. Multimedia Conferencing Service Class . . . . . . . . . . 35 4.3. Multimedia Conferencing Service Class .....................35
4.4. Real-time Interactive Service Class . . . . . . . . . . . 38 4.4. Real-Time Interactive Service Class .......................37
4.5. Multimedia Streaming Service Class . . . . . . . . . . . . 39 4.5. Multimedia Streaming Service Class ........................39
4.6. Broadcast Video Service Class . . . . . . . . . . . . . . 41 4.6. Broadcast Video Service Class .............................41
4.7. Low Latency Data Service Class . . . . . . . . . . . . . . 43 4.7. Low-Latency Data Service Class ............................43
4.8. High Throughput Data Service Class . . . . . . . . . . . . 45 4.8. High-Throughput Data Service Class ........................45
4.9. Standard Service Class . . . . . . . . . . . . . . . . . . 47 4.9. Standard Service Class ....................................47
4.10. Low Priority Data . . . . . . . . . . . . . . . . . . . . 48 4.10. Low-Priority Data ........................................48
5. Additional Information on Service Class Usage . . . . . . . . 49 5. Additional Information on Service Class Usage ..................49
5.1. Mapping for Signaling . . . . . . . . . . . . . . . . . . 49 5.1. Mapping for Signaling .....................................49
5.2. Mapping for NTP . . . . . . . . . . . . . . . . . . . . . 49 5.2. Mapping for NTP ...........................................50
5.3. VPN Service Mapping . . . . . . . . . . . . . . . . . . . 50 5.3. VPN Service Mapping .......................................50
6. Security Considerations . . . . . . . . . . . . . . . . . . . 50 6. Security Considerations ........................................51
7. Summary of Changes from Previous Version . . . . . . . . . . . 51 7. Acknowledgements ...............................................52
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 8. Appendix A .....................................................53
9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 54 8.1. Explanation of Ring Clipping ..............................53
9.1. Explanation of Ring Clipping . . . . . . . . . . . . . . . 54 9. References .....................................................54
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 9.1. Normative References ......................................54
10.1. Normative References . . . . . . . . . . . . . . . . . . . 55 9.2. Informative References ....................................55
10.2. Informative References . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . . . . 59
1. Introduction 1. Introduction
For understanding the role of this document we use an useful analogy, To aid in understanding the role of this document, we use an analogy:
starting from the fact that the Differentiated Services the Differentiated Services specifications are fundamentally a
specifications are fundamentally a toolkit - the specifications toolkit. The specifications provide the equivalent of band saws,
provide the equivalent of band saws, planers, drill presses, etc. In planers, drill presses, and other tools. In the hands of an expert,
the hands of an expert, there's no limit to what can be built, but there is no limit to what can be built, but such a toolkit can be
such a toolkit can be intimidating to the point of inaccessible to a intimidating to the point of being inaccessible to a non-expert who
non-expert who just wants to build a bookcase. This document should just wants to build a bookcase. This document should be viewed as a
be viewed as a set of "project plans" for building all the (diffserv) set of "project plans" for building all the (diffserv) furniture that
furniture that one might want. The user may choose what to build one might want. The user may choose what to build (e.g., perhaps our
(e.g., perhaps our non-expert doesn't need a china cabinet right non-expert doesn't need a china cabinet right now), and how to go
now), and how to go about building it (e.g., plans for a non-expert about building it (e.g., plans for a non-expert probably won't employ
probably won't employ mortise/tenon construction, but that absence mortise/tenon construction, but that absence does not imply that
does not imply that mortise/tenon construction is forbidden or mortise/tenon construction is forbidden or unsound). The authors
unsound). The authors hope that these diffserv "project plans" will hope that these diffserv "project plans" will provide a useful guide
provide a useful guide to Network Administrators in the use of to Network Administrators in the use of diffserv techniques to
diffserv techniques to implement quality of service measures implement quality-of-service measures appropriate for their network's
appropriate for their network's traffic. traffic.
This document describes service classes configured with Diffserv, This document describes service classes configured with Diffserv and
recommends how they can be used and how to construct them using recommends how they can be used and how to construct them using
Differentiated Service Code Points (DSCP), traffic conditioners, Per- Differentiated Services Code Points (DSCPs), traffic conditioners,
Hop Behaviors (PHB), and Active Queue Management (AQM) mechanisms. Per-Hop Behaviors (PHBs), and Active Queue Management (AQM)
There is no intrinsic requirement that particular DSCPs, traffic mechanisms. There is no intrinsic requirement that particular DSCPs,
conditioners, PHBs, and AQM be used for a certain service class, but traffic conditioners, PHBs, and AQM be used for a certain service
as a policy and for interoperability it is useful to apply them class, but as a policy and for interoperability it is useful to apply
consistently. them consistently.
Service classes are defined based on the different traffic Service class definitions are based on the different traffic
characteristics and required performance of the applications/ characteristics and required performance of the
services. This approach allows us to map current and future applications/services. This approach allows us to map current and
applications/services of similar traffic characteristics and future applications/services of similar traffic characteristics and
performance requirements into the same service class. Since the performance requirements into the same service class. Since the
applications'/services' characteristics and required performance are applications'/services' characteristics and required performance are
end to end, the service class notion needs to be preserved end to end to end, the service class notion needs to be preserved end to
end. With this approach, a limited set of service classes is end. With this approach, a limited set of service classes is
required. For completeness, we have defined twelve different service required. For completeness, we have defined twelve different service
classes, two for network operation/administration and ten for user/ classes, two for network operation/administration and ten for
subscriber applications/services. However, we expect that network user/subscriber applications/services. However, we expect that
administrators will implement a subset of these classes relevant to network administrators will implement a subset of these classes
their customers and their service offerings. Network Administrators relevant to their customers and their service offerings. Network
may also find it of value to add locally defined service classes, Administrators may also find it of value to add locally defined
although these will not necessarily enjoy end to end properties of service classes, although these will not necessarily enjoy end-to-end
the same type. properties of the same type.
Section 1, provides an introduction and overview of technologies that Section 1 provides an introduction and overview of technologies that
are used for service differentiation in IP networks. Section 2, is are used for service differentiation in IP networks. Section 2 is an
an overview of how service classes are constructed to provide service overview of how service classes are constructed to provide service
differentiation with examples of deployment scenarios. Section 3, differentiation, with examples of deployment scenarios. Section 3
provides configuration guidelines of service classes that are used provides configuration guidelines of service classes that are used
for stable operation and administration of the network. Section 4, for stable operation and administration of the network. Section 4
provides configuration guidelines of service classes that are used provides configuration guidelines of service classes that are used
for differentiation of user/subscriber traffic. Section 5, provides for differentiation of user/subscriber traffic. Section 5 provides
additional guidance on mapping different applications/protocol to additional guidance on mapping different applications/protocols to
service classes. Section 6, address security considerations. service classes. Section 6 addresses security considerations.
1.1. Requirements Notation 1.1. Requirements Notation
The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in [RFC2119].
1.2. Expected use in the Network 1.2. Expected Use in the Network
In the Internet today, corporate LANs and ISP WANs are generally not In the Internet today, corporate LANs and ISP WANs are generally not
heavily utilized - they are commonly 10% utilized at most. For this heavily utilized. They are commonly 10% utilized at most. For this
reason, congestion, loss, and variation in delay within corporate reason, congestion, loss, and variation in delay within corporate
LANs and ISP backbones is virtually unknown. This clashes with user LANs and ISP backbones is virtually unknown. This clashes with user
perceptions, for three very good reasons. perceptions, for three very good reasons.
o The industry moves through cycles of bandwidth boom and bandwidth o The industry moves through cycles of bandwidth boom and bandwidth
bust, depending on prevailing market conditions and the periodic bust, depending on prevailing market conditions and the periodic
deployment of new bandwidth-hungry applications. deployment of new bandwidth-hungry applications.
o In access networks, the state is often different. This may be o In access networks, the state is often different. This may be
because throughput rates are artificially limited, or are over because throughput rates are artificially limited or over-
subscribed, or because of access network design trade-offs. subscribed, or because of access network design trade-offs.
o Other characteristics, such as database design on web servers o Other characteristics, such as database design on web servers
(that may create contention points, e.g. in filestore), and (that may create contention points, e.g., in filestore) and
configuration of firewalls and routers, often look externally like configuration of firewalls and routers, often look externally like
a bandwidth limitation. a bandwidth limitation.
The intent of this document is to provide a consistent marking, The intent of this document is to provide a consistent marking,
conditioning, and packet treatment strategy so that it can be conditioning, and packet treatment strategy so that it can be
configured and put into service on any link which itself is configured and put into service on any link that is itself congested.
congested.
1.3. Service Class Definition 1.3. Service Class Definition
A "service class" represents a set of traffic that requires specific A "service class" represents a set of traffic that requires specific
delay, loss, and jitter characteristics from the network. delay, loss, and jitter characteristics from the network.
Conceptually, a service class pertains to applications with similar Conceptually, a service class pertains to applications with similar
characteristics and performance requirements, such as a "High characteristics and performance requirements, such as a "High-
Throughput Data" service class for applications like the web and Throughput Data" service class for applications like the web and
electronic mail, or a "Telephony" service class for real-time traffic electronic mail, or a "Telephony" service class for real-time traffic
such as voice and other telephony services. Such service class may such as voice and other telephony services. Such a service class may
be defined locally in a Differentiated Services domain, or across be defined locally in a Differentiated Services (DS) domain, or
multiple DS domains, including possibly extending end to end. across multiple DS domains, possibly extending end to end.
A service class as defined here is essentially a statement of the A service class as defined here is essentially a statement of the
required characteristics of a traffic aggregate. The required required characteristics of a traffic aggregate. The required
characteristics of these traffic aggregates can be realized by the characteristics of these traffic aggregates can be realized by the
use of defined per-hop behavior (PHB) [RFC2474]. The actual use of defined per-hop behavior (PHB) [RFC2474]. The actual
specification of the expected treatment of a traffic aggregate within specification of the expected treatment of a traffic aggregate within
a domain may also be defined as a per domain behavior (PDB) a domain may also be defined as a per-domain behavior (PDB)
[RFC3086]. [RFC3086].
Each domain may choose to implement different service classes, or use Each domain may choose to implement different service classes or to
different behaviors to implement the service classes, or aggregate use different behaviors to implement the service classes or to
different kinds of traffic into the aggregates and still achieve aggregate different kinds of traffic into the aggregates and still
their required characteristics. For example, low delay, loss, and achieve their required characteristics. For example, low delay,
jitter may be realized using the EF PHB, or with an over provisioned loss, and jitter may be realized using the EF PHB, or with an over-
AF PHB. This must be done with care as it may disrupt the end to end provisioned AF PHB. This must be done with care as it may disrupt
performance required by the applications/services. This document the end-to-end performance required by the applications/services.
provides recommendations on usage of PHBs for specific service This document provides recommendations on usage of PHBs for specific
classes for their consistent implementation, these recommendations service classes for their consistent implementation. These
are not to be construed as prohibiting use of other PHBs that realize recommendations are not to be construed as prohibiting use of other
behaviors sufficient for the relevant class of traffic. PHBs that realize behaviors sufficient for the relevant class of
traffic.
The Default Forwarding "Standard" service class is REQUIRED, all The Default Forwarding "Standard" service class is REQUIRED; all
other service classes are OPTIONAL. It is expected that network other service classes are OPTIONAL. It is expected that network
administrators will choose the level of service differentiation that administrators will base their choice of the level of service
they will support based on their need, starting off with three or differentiation that they will support on their need, starting off
four service classes for user traffic and add others as the need with three or four service classes for user traffic and adding others
arises. as the need arises.
1.4. Key Differentiated Services Concepts 1.4. Key Differentiated Services Concepts
The reader SHOULD be familiar with the principles of the The reader SHOULD be familiar with the principles of the
Differentiated Services Architecture [RFC2474]. We recapitulate key Differentiated Services Architecture [RFC2474]. We recapitulate key
concepts here only to provide convenience for the reader, with the concepts here only to provide convenience for the reader, the
referenced RFCs providing the authoritative definitions. referenced RFCs providing the authoritative definitions.
1.4.1. Queuing 1.4.1. Queuing
A queue is a data structure that holds packets that are awaiting A queue is a data structure that holds packets that are awaiting
transmission. The packets may be delayed while in the queue, transmission. The packets may be delayed while in the queue,
possibly due to lack of bandwidth, or because it is low in priority. possibly due to lack of bandwidth, or because it is low in priority.
There are a number of ways to implement a queue, a simple model of a There are a number of ways to implement a queue. A simple model of a
queuing system, however, is a set of data structures for packet data, queuing system, however, is a set of data structures for packet data,
which we will call queues and a mechanism for selecting the next which we will call queues, and a mechanism for selecting the next
packet from among them, which we call a scheduler. packet from among them, which we call a scheduler.
1.4.1.1. Priority Queuing 1.4.1.1. Priority Queuing
A priority queuing system is a combination of a set of queues and a 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 scheduler that empties them in priority sequence. When asked for a
packet, the scheduler inspects the highest priority queue, and if packet, the scheduler inspects the highest priority queue and, if
there is data present returns a packet from that queue. Failing there is data present, returns a packet from that queue. Failing
that, it inspects the next highest priority queue, and so on. A that, it inspects the next highest priority queue, and so on. A
freeway onramp with a stoplight for one lane, but which allows freeway onramp with a stoplight for one lane that allows vehicles in
vehicles in the high occupancy vehicle lane to pass, is an example of the high-occupancy-vehicle lane to pass is an example of a priority
a priority queuing system; the high occupancy vehicle lane represents queuing system; the high-occupancy-vehicle lane represents the
the "queue" having priority. "queue" having priority.
In a priority queuing system, a packet in the highest priority queue In a priority queuing system, a packet in the highest priority queue
will experience a readily calculated delay - it is proportional to will experience a readily calculated delay. This is proportional to
the amount of data remaining to be serialized when the packet arrived 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 plus the volume of the data already queued ahead of it in the same
queue. The technical reason for using a priority queue relates queue. The technical reason for using a priority queue relates
exactly to this fact: it limits delay and variations in delay, and exactly to this fact: it limits delay and variations in delay and
should be used for traffic which has that requirement. should be used for traffic that has that requirement.
A priority queue or queuing system needs to avoid starvation of lower A priority queue or queuing system needs to avoid starvation of
priority queues. This may be achieved through a variety of means lower-priority queues. This may be achieved through a variety of
such as admission control, rate control, or network engineering. means, such as admission control, rate control, or network
engineering.
1.4.1.2. Rate Queuing 1.4.1.2. Rate Queuing
Similarly, a rate-based queuing system is a combination of a set of 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 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 example of a rate-based queuing system is a road intersection with a
stoplight - the stoplight acts as a scheduler, giving each lane a stoplight. The stoplight acts as a scheduler, giving each lane a
certain opportunity to pass traffic through the intersection. certain opportunity to pass traffic through the intersection.
In a rate-based queuing system, such as WFQ or WRR, the delay that a In a rate-based queuing system, such as Weighted Fair Queuing (WFQ)
packet in any given queue will experience is dependant on the or Weighted Round Robin (WRR), the delay that a packet in any given
parameters and occupancy of its queue and the parameters and queue will experience depends on the parameters and occupancy of its
occupancy of the queues it is competing with. A queue whose traffic queue and the parameters and occupancy of the queues it is competing
arrival rate is much less than the rate at which it lets traffic with. A queue whose traffic arrival rate is much less than the rate
depart will tend to be empty and packets in it will experience at which it lets traffic depart will tend to be empty, and packets in
nominal delays. A queue whose traffic arrival rate approximates or it will experience nominal delays. A queue whose traffic arrival
exceeds its departure rate will tend to be not empty, and packets in rate approximates or exceeds its departure rate will tend not to be
it will experience greater delay. Such a scheduler can impose a empty, and packets in it will experience greater delay. Such a
minimum rate, a maximum rate, or both, on any queue it touches. scheduler can impose a minimum rate, a maximum rate, or both, on any
queue it touches.
1.4.2. Active Queue Management 1.4.2. Active Queue Management
"Active queue management" or AQM is a generic name for any of a Active Queue Management, or AQM, is a generic name for any of a
variety of procedures that use packet dropping or marking to manage variety of procedures that use packet dropping or marking to manage
the depth of a queue. The canonical example of such a procedure is 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 Random Early Detection (RED), in that a queue is assigned a minimum
maximum threshold, and the queuing algorithm maintains a moving and maximum threshold, and the queuing algorithm maintains a moving
average of the queue depth. While the mean queue depth exceeds the average of the queue depth. While the mean queue depth exceeds the
maximum threshold, all arriving traffic is dropped. While the mean maximum threshold, all arriving traffic is dropped. While the mean
queue depth exceeds the minimum threshold but not the maximum queue depth exceeds the minimum threshold but not the maximum
threshold, a randomly selected subset of arriving traffic is marked threshold, a randomly selected subset of arriving traffic is marked
or dropped. This marking or dropping of traffic is intended to or dropped. This marking or dropping of traffic is intended to
communicate with the sending system, causing its congestion avoidance communicate with the sending system, causing its congestion avoidance
algorithms to kick in. As a result of this behavior, it is algorithms to kick in. As a result of this behavior, it is
reasonable to expect that TCP's cyclic behavior is desynchronized, reasonable to expect that TCP's cyclic behavior is desynchronized and
and the mean queue depth (and therefore delay) should normally that the mean queue depth (and therefore delay) should normally
approximate the minimum threshold. approximate the minimum threshold.
A variation of the algorithm is applied in Assured Forwarding PHB A variation of the algorithm is applied in Assured Forwarding PHB
[RFC2597], in that the behavior aggregate consists of traffic with [RFC2597], in that the behavior aggregate consists of traffic with
multiple DSCP marks, which are intermingled in a common queue. multiple DSCP marks, which are intermingled in a common queue.
Different minima and maxima are configured for the several DSCPs Different minima and maxima are configured for the several DSCPs
separately, such that traffic that exceeds a stated rate at ingress separately, such that traffic that exceeds a stated rate at ingress
is more likely to be dropped or marked than traffic that is within is more likely to be dropped or marked than traffic that is within
its contracted rate. its contracted rate.
1.4.3. Traffic Conditioning 1.4.3. Traffic Conditioning
Additionally, at the first router in a network that a packet crosses, In addition, at the first router in a network that a packet crosses,
arriving traffic may be measured, and dropped or marked according to arriving traffic may be measured and dropped or marked according to a
a policy, or perhaps shaped on network ingress as in A Rate Adaptive policy, or perhaps shaped on network ingress, as in "A Rate Adaptive
Shaper for Differentiated Services [RFC2963]. This may be used to Shaper for Differentiated Services" [RFC2963]. This may be used to
bias feedback loops, such as is done in Assured Forwarding PHB bias feedback loops, as is done in "Assured Forwarding PHB"
[RFC2597], or to limit the amount of traffic in a system, as is done [RFC2597], or to limit the amount of traffic in a system, as is done
in Expedited Forwarding PHB [RFC3246]. Such measurement procedures in "Expedited Forwarding PHB" [RFC3246]. Such measurement procedures
are collectively referred to as "traffic conditioners". Traffic are collectively referred to as "traffic conditioners". Traffic
conditioners are normally built using token bucket meters, for conditioners are normally built using token bucket meters, for
example with a committed rate and a burst size, as in Section 1.5.3 example with a committed rate and burst size, as in Section 1.5.3 of
of DiffServ Model [RFC3290]. With multiple rate and burst size the DiffServ Model [RFC3290]. The Assured Forwarding PHB [RFC2597]
measurements added to the basic single rate single burst size token uses a variation on a meter with multiple rate and burst size
bucket meter to achieve multiple levels of conformance used by measurements to test and identify multiple levels of conformance.
Assured Forwarding PHB [RFC2597]. Multiple rates and burst sizes can
be realized using multiple levels of token buckets or more complex Multiple rates and burst sizes can be realized using multiple levels
token buckets, these are implementation details. Some traffic of token buckets or more complex token buckets; these are
conditioners that may be used in deployment of differentiated implementation details. The following are some traffic conditioners
services are: that may be used in deployment of differentiated services:
o For Class Selector (CS) PHBs, a single token bucket meter to o For Class Selector (CS) PHBs, a single token bucket meter to
provide a rate plus burst size control provide a rate plus burst size control.
o For Expedited Forwarding (EF) PHB, a single token bucket meter to o For Expedited Forwarding (EF) PHB, a single token bucket meter to
provide a rate plus burst size control provide a rate plus burst size control.
o For Assured Forwarding (AF) PHBs, usually two token bucket meters o For Assured Forwarding (AF) PHBs, usually two token bucket meters
configured to provide behavior as outlined in Two Rate Three Color configured to provide behavior as outlined in "Two Rate Three
Marker (trTCM) [RFC2698] or the Single Rate Three Color Marker Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color Marker
(srTCM) [RFC2697]. The two rate three color marker is used to (srTCM)" [RFC2697]. The two-rate, three-color marker is used to
enforce two rates whereas, the single rate three color marker is enforce two rates, whereas the single-rate, three-color marker is
used to enforce a committed rate with two burst lengths. used to enforce a committed rate with two burst lengths.
1.4.4. Differentiated Services Code Point (DSCP) 1.4.4. Differentiated Services Code Point (DSCP)
The DSCP is a number in the range 0..63, that is placed into an IP 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. packet to mark it according to the class of traffic it belongs in.
Half of these values are earmarked for standardized services, and the Half of these values are earmarked for standardized services, and the
other half of them are available for local definition. other half of them are available for local definition.
1.4.5. Per-Hop Behavior (PHB) 1.4.5. Per-Hop Behavior (PHB)
In the end, the mechanisms described above are combined to form a In the end, the mechanisms described above are combined to form a
specified set of characteristics for handling different kinds of specified set of characteristics for handling different kinds of
traffic, depending on the needs of the application. This document traffic, depending on the needs of the application. This document
seeks to identify useful traffic aggregates and specify what PHB seeks to identify useful traffic aggregates and to specify what PHB
should be applied to them. should be applied to them.
1.5. Key Service Concepts 1.5. Key Service Concepts
While Differentiated Services is a general architecture that may be While Differentiated Services is a general architecture that may be
used to implement a variety of services, three fundamental forwarding used to implement a variety of services, three fundamental forwarding
behaviors have been defined and characterized for general use. These behaviors have been defined and characterized for general use. These
are basic Default Forwarding (DF) behavior for elastic traffic, the are basic Default Forwarding (DF) behavior for elastic traffic, the
Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF) Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF)
behavior for real-time (inelastic) traffic. The facts that four code behavior for real-time (inelastic) traffic. The facts that four code
points are recommended for AF, and that one code point is recommended points are recommended for AF and that one code point is recommended
for EF, are arbitrary choices, and the architecture allows any for EF are arbitrary choices, and the architecture allows any
reasonable number of AF and EF classes simultaneously. The choice of reasonable number of AF and EF classes simultaneously. The choice of
four AF classes and one EF class in the current document is also four AF classes and one EF class in the current document is also
arbitrary, and operators MAY choose to operate more or fewer of arbitrary, and operators MAY choose to operate more or fewer of
either. either.
The terms "elastic" and "real-time" are defined in [RFC1633] Section The terms "elastic" and "real-time" are defined in [RFC1633], Section
3.1, as a way of understanding broad brush application requirements. 3.1, as a way of understanding broad-brush application requirements.
This document should be reviewed to obtain a broad understanding of This document should be reviewed to obtain a broad understanding of
the issues in quality of service, just as [RFC2475] should be the issues in quality of service, just as [RFC2475] should be
reviewed to understand the data plane architecture used in today's reviewed to understand the data plane architecture used in today's
Internet. Internet.
1.5.1. Default Forwarding (DF) 1.5.1. Default Forwarding (DF)
The basic forwarding behavior applied to any class of traffic are The basic forwarding behaviors applied to any class of traffic are
those described in [RFC2474] and [RFC2309]. Best Effort service may those described in [RFC2474] and [RFC2309]. Best-effort service may
be summarized as "I will accept your packets", and is typically be summarized as "I will accept your packets" and is typically
configured with some bandwidth guarantee. Packets in transit may be configured with some bandwidth guarantee. Packets in transit may be
lost, reordered, duplicated, or delayed at random. Generally, lost, reordered, duplicated, or delayed at random. Generally,
networks are engineered to limit this behavior, but changing traffic networks are engineered to limit this behavior, but changing traffic
loads can push any network into such a state. loads can push any network into such a state.
Application traffic in the internet which uses default forwarding is Application traffic in the internet that uses default forwarding is
expected to be "elastic" in nature. By this, we mean that the sender expected to be "elastic" in nature. By this, we mean that the sender
of traffic will adjust its transmission rate in response to changes of traffic will adjust its transmission rate in response to changes
in available rate, loss, or delay. in available rate, loss, or delay.
For the basic best effort service, a single DSCP value is provided to For the basic best-effort service, a single DSCP value is provided to
identify the traffic, a queue to store it, and active queue identify the traffic, a queue to store it, and active queue
management to protect the network from it and to limit delays. management to protect the network from it and to limit delays.
1.5.2. Assured Forwarding (AF) 1.5.2. Assured Forwarding (AF)
The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled
on Frame Relay's DE flag or ATM's CLP capability, and is intended for on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss
networks that offer average-rate SLAs (as FR and ATM networks do). Priority (CLP) capability. It is intended for networks that offer
This is an enhanced best effort service; traffic is expected to be average-rate Service Level Agreements (SLAs) (as FR and ATM networks
"elastic" in nature. The receiver will detect loss or variation in do). This is an enhanced best-effort service; traffic is expected to
delay in the network and provide feedback such that the sender 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. adjusts its transmission rate to approximate available capacity.
For such behaviors, multiple DSCP values are provided (two or three, For such behaviors, multiple DSCP values are provided (two or three,
perhaps more using local values) to identify the traffic, a common perhaps more using local values) to identify the traffic, a common
queue to store the aggregate and active queue management to protect queue to store the aggregate, and active queue management to protect
the network from it and to limit delays. Traffic is metered as it the network from it and to limit delays. Traffic is metered as it
enters the network, and traffic is variously marked depending on the enters the network, and traffic is variously marked depending on the
arrival rate of the aggregate. The premise is that it is normal for arrival rate of the aggregate. The premise is that it is normal for
users to occasionally use more capacity than their contract users occasionally to use more capacity than their contract
stipulates, perhaps up to some bound. However, if traffic should be stipulates, perhaps up to some bound. However, if traffic should be
marked or lost to manage the queue, this excess traffic will be marked or lost to manage the queue, this excess traffic will be
marked or lost first. marked or lost first.
1.5.3. Expedited Forwarding (EF) 1.5.3. Expedited Forwarding (EF)
The intent of Expedited Forwarding PHB [RFC3246] is to provide a The intent of Expedited Forwarding PHB [RFC3246] is to provide a
building block for low loss, low delay, and low jitter services. It building block for low-loss, low-delay, and low-jitter services. It
can be used to build an enhanced best effort service: traffic remains can be used to build an enhanced best-effort service: traffic remains
subject to loss due to line errors and reordering during routing subject to loss due to line errors and reordering during routing
changes. However, using queuing techniques, the probability of delay changes. However, using queuing techniques, the probability of delay
or variation in delay is minimized. For this reason, it is generally or variation in delay is minimized. For this reason, it is generally
used to carry voice and for transport of data information that used to carry voice and for transport of data information that
requires "wire like" behavior through the IP network. Voice is an requires "wire like" behavior through the IP network. Voice is an
inelastic "real-time" application that sends packets at the rate the inelastic "real-time" application that sends packets at the rate the
codec produces them, regardless of availability of capacity. As codec produces them, regardless of availability of capacity. As
such, this service has the potential to disrupt or congest a network such, this service has the potential to disrupt or congest a network
if not controlled. It also has the potential for abuse. if not controlled. It also has the potential for abuse.
To protect the network, at minimum one SHOULD police traffic at To protect the network, at minimum one SHOULD police traffic at
various points to ensure that the design of a queue is not over-run, various points to ensure that the design of a queue is not overrun,
and then the traffic SHOULD be given a low delay queue (often using and then the traffic SHOULD be given a low-delay queue (often using
priority, although it is asserted that a rate-based queue can do 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 this) to ensure that variation in delay is not an issue, to meet
application needs. application needs.
1.5.4. Class Selector (CS) 1.5.4. Class Selector (CS)
Class Selector provides support for historical codepoint definitions Class Selector provides support for historical codepoint definitions
and PHB requirement. The Class Selector DS field provides a limited and PHB requirement. The Class Selector DS field provides a limited
backward compatibility with legacy (pre DiffServ) practice, as backward compatibility with legacy (pre DiffServ) practice, as
described in [RFC2474] Section 4. Backward compatibility is described in [RFC2474], Section 4. Backward compatibility is
addressed in two ways. First, there are per-hop behaviors that are addressed in two ways. First, there are per-hop behaviors that are
already in widespread use (e.g. those satisfying the IPv4 Precedence already in widespread use (e.g., those satisfying the IPv4 Precedence
queuing requirements specified in [RFC1812], and we wish to permit queuing requirements specified in [RFC1812]), and we wish to permit
their continued use in DS-compliant networks. In addition, there are their continued use in DS-compliant networks. In addition, there are
some codepoints that correspond to historical use of the IP some codepoints that correspond to historical use of the IP
Precedence field and we reserve these codepoints to map to PHBs that Precedence field, and we reserve these codepoints to map to PHBs that
meet the general requirements specified in [RFC2474] Section 4.2.2.2. meet the general requirements specified in [RFC2474], Section
4.2.2.2.
No attempt is made to maintain backward compatibility with the "DTR" No attempt is made to maintain backward compatibility with the "DTR"
or TOS bits of the IPv4 TOS octet, as defined in [RFC0791]and or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in
[RFC1349]. [RFC0791] and [RFC1349].
A DS-compliant network can be deployed with a set of one or more A DS-compliant network can be deployed with a set of one or more
Class Selector compliant PHB groups. As well, network administrator Class Selector-compliant PHB groups. Also, a network administrator
may configure the network nodes to map codepoints to PHBs 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 irrespective of bits 3-5 of the DSCP field, to yield a network that
compatible with historical IP Precedence use. Thus, for example, is compatible with historical IP Precedence use. Thus, for example,
codepoint '011000' would map to the same PHB as codepoint '011010'. codepoint '011000' would map to the same PHB as codepoint '011010'.
1.5.5. Admission Control 1.5.5. Admission Control
Admission control including refusal when policy thresholds are Admission control (including refusal when policy thresholds are
crossed, can assure high quality communication by ensuring the crossed) can ensure high-quality communication by ensuring the
availability of bandwidth to carry a load. Inelastic real-time flows availability of bandwidth to carry a load. Inelastic real-time flows
like VoIP (telephony) or video conferencing services can benefit from such as Voice over Internet Protocol (VoIP) (telephony) or video
use of admission control mechanism, as generally the telephony conferencing services can benefit from use of an admission control
service is configured with over subscription, meaning that some mechanism, as generally the telephony service is configured with
user(s) may not be able to make a call during peak periods. over-subscription, meaning that some users may not be able to make a
call during peak periods.
For VoIP (telephony) service, a common approach is to use signaling For VoIP (telephony) service, a common approach is to use signaling
protocols such as SIP, H.323, H.248, MEGACO, RSVP, etc. to negotiate protocols such as SIP, H.323, H.248, MEGACO, and Resource Reservation
admittance and use of network transport capabilities. When a user Protocol (RSVP) to negotiate admittance and use of network transport
has been authorized to send voice traffic, this admission procedure capabilities. When a user has been authorized to send voice traffic,
has verified that data rates will be within the capacity of the this admission procedure has verified that data rates will be within
network that it will use. Since RTP voice does not react to loss or the capacity of the network that it will use. Many RTP voice
delay in any substantive way, the network SHOULD police at ingress to payloads are inelastic and cannot react to loss or delay in any
ensure that the voice traffic stays within its negotiated bounds. substantive way. For these voice payloads, the network SHOULD police
Having thus assured a predictable input rate, the network may use a at ingress to ensure that the voice traffic stays within its
priority queue to ensure nominal delay and variation in delay. 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 Another approach that may be used in small and bandwidth-constrained
networks for limited number of flows is RSVP [RFC2205] [RFC2996]. networks for limited number of flows is RSVP [RFC2205] [RFC2996].
However, there is concern with the scalability of this solution in However, there is concern with the scalability of this solution in
large networks where aggregation of reservations[RFC3175] is large networks where aggregation of reservations[RFC3175] is
considered to be required. considered to be required.
2. Service Differentiation 2. Service Differentiation
There are practical limits on the level of service differentiation There are practical limits on the level of service differentiation
that should be offered in the IP networks. We believe we have that should be offered in the IP networks. We believe we have
defined a practical approach in delivering service differentiation by defined a practical approach in delivering service differentiation by
defining different service classes that networks may choose to defining different service classes that networks may choose to
support to provide the appropriate level of behaviors and performance support in order to provide the appropriate level of behaviors and
needed by current and future applications and services. The defined performance needed by current and future applications and services.
structure for providing services allows several applications having The defined structure for providing services allows several
similar traffic characteristics and performance requirements to be applications having similar traffic characteristics and performance
grouped into the same service class. This approach provides a lot of requirements to be grouped into the same service class. This
flexibility in providing the appropriate level of service approach provides a lot of flexibility in providing the appropriate
differentiation for current and new yet unknown applications without level of service differentiation for current and new, yet unknown
introducing significant changes to routers or network configurations applications without introducing significant changes to routers or
when a new traffic type is added to the network. network configurations when a new traffic type is added to the
network.
2.1. Service Classes 2.1. Service Classes
Traffic flowing in a network can be classified in many different Traffic flowing in a network can be classified in many different
ways. We have chosen to divide it into two groupings, network ways. We have chosen to divide it into two groupings, network
control and user/subscriber traffic. To provide service control and user/subscriber traffic. To provide service
differentiation, different service classes are defined in each differentiation, different service classes are defined in each
grouping. The network control traffic group can further be divided grouping. The network control traffic group can further be divided
into two service classes (see Section 3 for detailed definition of into two service classes (see Section 3 for detailed definition of
each service class): each service class):
skipping to change at page 12, line 40 skipping to change at page 12, line 14
2.1. Service Classes 2.1. Service Classes
Traffic flowing in a network can be classified in many different Traffic flowing in a network can be classified in many different
ways. We have chosen to divide it into two groupings, network ways. We have chosen to divide it into two groupings, network
control and user/subscriber traffic. To provide service control and user/subscriber traffic. To provide service
differentiation, different service classes are defined in each differentiation, different service classes are defined in each
grouping. The network control traffic group can further be divided grouping. The network control traffic group can further be divided
into two service classes (see Section 3 for detailed definition of into two service classes (see Section 3 for detailed definition of
each service class): each service class):
o "Network Control" for routing and network control function. o "Network Control" for routing and network control function.
o "OAM" (Operations, Administration and Management) for network o "OAM" (Operations, Administration, and Management) for network
configuration and management functions. configuration and management functions.
The user/subscriber traffic group is broken down into ten service The user/subscriber traffic group is broken down into ten service
classes to provide service differentiation for all the different classes to provide service differentiation for all the different
types of applications/services, (see Section 4 for detailed types of applications/services (see Section 4 for detailed definition
definition of each service class) in summary: of each service class):
o Telephony service class is best suited for applications that o Telephony service class is best suited for applications that
require very low delay variation and are of constant rate, such as require very low delay variation and are of constant rate, such as
IP telephony (VoIP) and circuit emulation over IP applications. IP telephony (VoIP) and circuit emulation over IP applications.
o Signaling service class is best suited for peer-to-peer and o Signaling service class is best suited for peer-to-peer and
client-server signaling and control functions using protocols such client-server signaling and control functions using protocols such
as SIP, SIP-T, H.323, H.248, MGCP, etc. as SIP, SIP-T, H.323, H.248, and Media Gateway Control Protocol
(MGCP).
o Multimedia Conferencing service class is best suited for o Multimedia Conferencing service class is best suited for
applications that require very low delay, and have the ability to applications that require very low delay and have the ability to
change encoding rate (rate adaptive), such as H.323/V2 and later change encoding rate (rate adaptive), such as H.323/V2 and later
video conferencing service. video conferencing service.
o Real-time Interactive service class is intended for interactive o Real-Time Interactive service class is intended for interactive
variable rate inelastic applications that require low jitter, loss variable rate inelastic applications that require low jitter and
and very low delay, such as interactive gaming applications that loss and very low delay, such as interactive gaming applications
use RTP/UDP streams for game control commands, video conferencing that use RTP/UDP streams for game control commands, and video
applications that do not have the ability to change encoding rates conferencing applications that do not have the ability to change
or mark packets with different importance indications, etc. encoding rates or to mark packets with different importance
indications.
o Multimedia Streaming service class is best suited for variable o Multimedia Streaming service class is best suited for variable
rate elastic streaming media applications where a human is waiting rate elastic streaming media applications where a human is waiting
for output and where the application has the capability to react for output and where the application has the capability to react
to packet loss by reducing its transmission rate, such as to packet loss by reducing its transmission rate, such as
streaming video and audio, web cast, etc. streaming video and audio and webcast.
o Broadcast Video service class is best suited for inelastic o Broadcast Video service class is best suited for inelastic
streaming media applications that may be of constant or variable streaming media applications that may be of constant or variable
rate, requiring low jitter and very low packet loss, such as rate, requiring low jitter and very low packet loss, such as
broadcast TV and live events, video surveillance and security. broadcast TV and live events, video surveillance, and security.
o Low Latency Data service class is best suited for data processing
o Low-Latency Data service class is best suited for data processing
applications where a human is waiting for output, such as web- applications where a human is waiting for output, such as web-
based ordering, Enterprise Resource Planning (ERP) application, based ordering or an Enterprise Resource Planning (ERP)
etc. application.
o High Throughput Data service class is best suited for store and o High-Throughput Data service class is best suited for store and
forward applications such as FTP, billing record transfer, etc. forward applications such as FTP and billing record transfer.
o Standard service class is for traffic that has not been identified o Standard service class is for traffic that has not been identified
as requiring differentiated treatment and is normally referred as as requiring differentiated treatment and is normally referred to
best effort. as best effort.
o Low Priority Data service class is intended for packet flows where o Low-Priority Data service class is intended for packet flows where
bandwidth assurance is not required. bandwidth assurance is not required.
2.2. Categorization of User Service Classes 2.2. Categorization of User Service Classes
The ten defined user/subscriber service classes listed above can be The ten defined user/subscriber service classes listed above can be
grouped into a small number of application categories. For some grouped into a small number of application categories. For some
application categories, it was felt that more than one service class application categories, it was felt that more than one service class
was needed to provide service differentiation within that category was needed to provide service differentiation within that category
due to the different traffic characteristic of the applications, due to the different traffic characteristic of the applications,
control function and the required flow behavior. Figure 1 provides control function, and the required flow behavior. Figure 1 provides
summary of service class grouping into four application categories. a summary of service class grouping into four application categories.
Application Control Category
Application Control category:
o The Signaling service class is intended to be used to control o The Signaling service class is intended to be used to control
applications or user endpoints. Examples of protocols that would applications or user endpoints. Examples of protocols that would
use this service class are, SIP or H.248 for IP telephone service use this service class are SIP or H.248 for IP telephone service
and SIP or IGMP for control of broadcast TV service to and SIP or Internet Group Management Protocol (IGMP) for control
subscribers. Although user signaling flows have similar of broadcast TV service to subscribers. Although user signaling
performance requirements as Low Latency Data they need to be flows have similar performance requirements as Low-Latency Data,
distinguished and marked with a different DSCP. The essential they need to be distinguished and marked with a different DSCP.
distinction is something like "administrative control and The essential distinction is something like "administrative
management" of the traffic affected as the protocols in this class control and management" of the traffic affected as the protocols
tend to be tied to the media stream/session they signal and in this class tend to be tied to the media stream/session they
control. signal and control.
Media-Oriented Category
Due to the vast number of new (in process of being deployed) and
already-in-use media-oriented services in IP networks, five service
classes have been defined.
Media-Oriented category: Due to the vest number of new (in process of
being deployed) and already in use media-oriented services in IP
networks, five service classes have been defined.
o Telephony service class is intended for IP telephony (VoIP) o Telephony service class is intended for IP telephony (VoIP)
service as well it may be used for other applications that meet service. It may also be used for other applications that meet the
the defined traffic characteristics and performance requirements. defined traffic characteristics and performance requirements.
o Real-time Interactive service class is intended for inelastic o Real-Time Interactive service class is intended for inelastic
video flows from such application like SIP based desktop video video flows from applications such as SIP-based desktop video
conferencing applications and for interactive gaming. conferencing applications and for interactive gaming.
o Multimedia Conferencing service class is for video conferencing o Multimedia Conferencing service class is for video conferencing
solutions that have the ability to reduce their transmission rate solutions that have the ability to reduce their transmission rate
on detection of congestion, therefore these flows can be on detection of congestion. These flows can therefore be
classified as rate adaptive. As currently there are both types of classified as rate adaptive. As currently two types of video
video conferencing equipment used in IP networks, ones that conferencing equipment are used in IP networks (ones that generate
generate inelastic and ones that generate rate adaptive traffic, inelastic traffic and ones that generate rate-adaptive traffic),
therefore two service class are needed. Real-time Interactive two service class are needed. The Real-Time Interactive service
service class should be used for equipment that generate inelastic class should be used for equipment that generates inelastic video
video flows and Multimedia Conferencing service class for flows and the Multimedia Conferencing service class for equipment
equipment that generate rate adaptive video flows. that generates rate-adaptive video flows.
o Broadcast Video service class is to be used for inelastic traffic o Broadcast Video service class is to be used for inelastic traffic
flows which is intended for broadcast TV service and for transport flows, which are intended for broadcast TV service and for
of live video and audio events. transport of live video and audio events.
o Multimedia Streaming service class is to be used for elastic o Multimedia Streaming service class is to be used for elastic
multimedia traffic flows. This multimedia content is typically multimedia traffic flows. This multimedia content is typically
stored before being transmitted, as well it is buffered at the stored before being transmitted. It is also buffered at the
receiving end before being played out. The buffering is receiving end before being played out. The buffering is
sufficiently large to accommodate any variation in transmission sufficiently large to accommodate any variation in transmission
rate that is encountered in the network. Multimedia entertainment rate that is encountered in the network. Multimedia entertainment
over IP delivery services that are being developed can generate over IP delivery services that are being developed can generate
both elastic and/or inelastic traffic flows, therefore two service both elastic and inelastic traffic flows; therefore, two service
classes are defined to address this space. classes are defined to address this space, respectively:
Multimedia Streaming and Broadcast Video.
Data category: The data category is divided into three service Data Category
classes.
o Low Latency Data for applications/services that require low delay The data category is divided into three service classes.
or latency for bursty but short lived flows.
o High Throughput Data for applications/services that require good o Low-Latency Data for applications/services that require low delay
throughput for long lived bursty flows. High Throughput and or latency for bursty but short-lived flows.
o High-Throughput Data for applications/services that require good
throughput for long-lived bursty flows. High Throughput and
Multimedia Steaming are close in their traffic flow Multimedia Steaming are close in their traffic flow
characteristics with High Throughput being a bit more bursty and characteristics with High Throughput being a bit more bursty and
not as long lived as Multimedia Streaming. not as long-lived as Multimedia Streaming.
o Low Priority Data for applications or services that can tolerate o Low-Priority Data for applications or services that can tolerate
short or long interruptions of packet flows. Low Priority Data short or long interruptions of packet flows. The Low-Priority
service class can be viewed as don't care to some degree. Data service class can be viewed as "don't care" to some degree.
Best-Effort Category
Best Effort category:
o All traffic that is not differentiated in the network falls into o All traffic that is not differentiated in the network falls into
this category and is mapped into the Standard service class. If a this category and is mapped into the Standard service class. If a
packet is marked with a DSCP value that is not supported in the packet is marked with a DSCP value that is not supported in the
network, it SHOULD be forwarded using the Standard service class. network, it SHOULD be forwarded using the Standard service class.
Figure 1 below provides a grouping of the defined user/subscriber Figure 1, below, provides a grouping of the defined user/subscriber
service classes into four categories with indications of which ones service classes into four categories, with indications of which ones
use an independent flow for signaling or control, type of flow use an independent flow for signaling or control; type of flow
behavior elastic, rate adaptive or inelastic and finally the last behavior (elastic, rate adaptive, or inelastic); and the last column
column provides end user QoS rating as defined in ITU-T provides end user Quality of Service (QoS) rating as defined in ITU-T
Recommendation G.1010. Recommendation G.1010.
----------------------------------------------------------------- -----------------------------------------------------------------
| Application | Service | Signaled | Flow | G.1010 | | Application | Service | Signaled | Flow | G.1010 |
| Categories | Class | | Behavior | Rating | | Categories | Class | | Behavior | Rating |
|-------------+---------------+----------+-----------+------------| |-------------+---------------+----------+-----------+------------|
| Application | Signaling | N.A. | Inelastic | Responsive | | Application | Signaling | Not | Inelastic | Responsive |
| Control | | | | | | Control | |applicable| | |
|-------------+---------------+----------+-----------+------------| |-------------+---------------+----------+-----------+------------|
| | Telephony | Yes | Inelastic | Interactive| | | Telephony | Yes | Inelastic | Interactive|
| |---------------+----------+-----------+------------| | |---------------+----------+-----------+------------|
| | Real-time | Yes | Inelastic | Interactive| | | Real-Time | Yes | Inelastic | Interactive|
| | Interactive | | | | | | Interactive | | | |
| |---------------+----------+-----------+------------| | |---------------+----------+-----------+------------|
| Media- | Multimedia | Yes | Rate | Interactive| | Media- | Multimedia | Yes | Rate | Interactive|
| Oriented | Conferencing | | Adaptive | | | Oriented | Conferencing | | Adaptive | |
| |---------------+----------+-----------+------------| | |---------------+----------+-----------+------------|
| |Broadcast Video| Yes | Inelastic | Responsive | | |Broadcast Video| Yes | Inelastic | Responsive |
| |---------------+----------+-----------+------------| | |---------------+----------+-----------+------------|
| | Multimedia | Yes | Elastic | Timely | | | Multimedia | Yes | Elastic | Timely |
| | Streaming | | | | | | Streaming | | | |
|-------------+---------------+----------+-----------+------------| |-------------+---------------+----------+-----------+------------|
| | Low Latency | No | Elastic | Responsive | | | Low-Latency | No | Elastic | Responsive |
| | Data | | | | | | Data | | | |
| |---------------+----------+-----------+------------| | |---------------+----------+-----------+------------|
| Data |High Throughput| No | Elastic | Timely | | Data |High-Throughput| No | Elastic | Timely |
| | Data | | | | | | Data | | | |
| |---------------+----------+-----------+------------| | |---------------+----------+-----------+------------|
| | Low Priority | No | Elastic |Non-critical| | | Low-Priority | No | Elastic |Non-critical|
| | Data | | | | | | Data | | | |
|-------------+---------------+----------+-----------+------------| |-------------+---------------+----------+-----------+------------|
| Best Effort | Standard | Not Specified |Non-critical| | Best Effort | Standard | Not Specified |Non-critical|
----------------------------------------------------------------- -----------------------------------------------------------------
Note: N.A. = Not Applicable.
Figure 1: User/Subscriber Service Classes Grouping
Here is a short explanation of end user QoS category as defined in Figure 1. User/Subscriber Service Classes Grouping
ITU-T Recommendation G.1010. User traffic is divided into four Here is a short explanation of the end user QoS category as defined
in ITU-T Recommendation G.1010. User traffic is divided into four
different categories, namely, interactive, responsive, timely, and different categories, namely, interactive, responsive, timely, and
non-critical. An example of interactive traffic is between two non-critical. An example of interactive traffic is between two
humans and is most sensitive to delay, loss, and jitter. Another humans and is most sensitive to delay, loss, and jitter. Another
example of interactive traffic is between two servers where very low example of interactive traffic is between two servers where very low
delay and loss is needed. Responsive traffic is typically between a delay and loss are needed. Responsive traffic is typically between a
human and a server but also can be between two servers. Responsive human and a server but can also be between two servers. Responsive
traffic is less affected by jitter and can tolerate longer delays traffic is less affected by jitter and can tolerate longer delays
than interactive traffic. Timely traffic is either between servers than interactive traffic. Timely traffic is either between servers
or servers and humans and the delay tolerance is significantly longer or servers and humans and the delay tolerance is significantly longer
than responsive traffic. Non-critical traffic is normally between than responsive traffic. Non-critical traffic is normally between
servers/machines where delivery may be delay for period of time. servers/machines where delivery may be delay for period of time.
2.3. Service Class Characteristics 2.3. Service Class Characteristics
This document provides guidelines for network administrator in This document provides guidelines for network administrators in
configuring their network for the level of service differentiation configuring their network for the level of service differentiation
that is appropriate in their network to meet their QoS needs. It is that is appropriate in their network to meet their QoS needs. It is
expected that network operators will configure and provide in their expected that network operators will configure and provide in their
networks a subset of the defined service classes. Our intent is to networks a subset of the defined service classes. Our intent is to
provide guidelines for configuration of Differentiated Services for a provide guidelines for configuration of Differentiated Services for a
wide variety of applications, services and network configurations. wide variety of applications, services, and network configurations.
Additionally, network administrators may choose to define and deploy In addition, network administrators may choose to define and deploy
in their network other service classes. other service classes in their network.
Figure 2 provides a behavior view for traffic serviced by each Figure 2 provides a behavior view for traffic serviced by each
service class. The traffic characteristics column defines the service class. The traffic characteristics column defines the
characteristics and profile of flows serviced and the tolerance to characteristics and profile of flows serviced, and the tolerance to
loss, delay and jitter columns define the treatment the flows will loss, delay, and jitter columns define the treatment the flows will
receive. End-to-end quantitative performance requirements may be receive. End-to-end quantitative performance requirements may be
obtained from ITU-T Recommendation Y.1541 and Y.1540. obtained from ITU-T Recommendations Y.1541 and Y.1540.
------------------------------------------------------------------- -------------------------------------------------------------------
|Service Class | | Tolerance to | |Service Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter| | Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+==============================+======+======+======| |===============+==============================+======+======+======|
| Network |Variable size packets, mostly | | | | | Network |Variable size packets, mostly | | | |
| Control |inelastic short messages, but | Low | Low | Yes | | Control |inelastic short messages, but | Low | Low | Yes |
| | traffic can also burst (BGP) | | | | | | traffic can also burst (BGP) | | | |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
| | Fixed size small packets, | Very | Very | Very | | | Fixed-size small packets, | Very | Very | Very |
| Telephony | constant emission rate, | Low | Low | Low | | Telephony | constant emission rate, | Low | Low | Low |
| | inelastic and low rate flows | | | | | | inelastic and low-rate flows | | | |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
| Signaling | Variable size packets, some | Low | Low | Yes | | Signaling | Variable size packets, some | Low | Low | Yes |
| | what bursty short lived flows| | | | | | what bursty short-lived flows| | | |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, | Low | Very | | | Multimedia | Variable size packets, | Low | Very | |
| Conferencing | constant transmit interval, | - | Low | Low | | Conferencing | constant transmit interval, | - | Low | Low |
| |rate adaptive, reacts to loss |Medium| | | | |rate adaptive, reacts to loss |Medium| | |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
| Real-time | RTP/UDP streams, inelastic, | Low | Very | Low | | Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low |
| Interactive | mostly variable rate | | Low | | | Interactive | mostly variable rate | | Low | |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, |Low - |Medium| Yes | | Multimedia | Variable size packets, |Low - |Medium| Yes |
| Streaming | elastic with variable rate |Medium| | | | Streaming | elastic with variable rate |Medium| | |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
| Broadcast | Constant and variable rate, | Very |Medium| Low | | Broadcast | Constant and variable rate, | Very |Medium| Low |
| Video | inelastic, non bursty flows | Low | | | | Video | inelastic, non-bursty flows | Low | | |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
| Low Latency | Variable rate, bursty short | Low |Low - | Yes | | Low-Latency | Variable rate, bursty short- | Low |Low - | Yes |
| Data | lived elastic flows | |Medium| | | Data | lived elastic flows | |Medium| |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
| OAM | Variable size packets, | Low |Medium| Yes | | OAM | Variable size packets, | Low |Medium| Yes |
| | elastic & inelastic flows | | | | | | elastic & inelastic flows | | | |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
|High Throughput| Variable rate, bursty long | Low |Medium| Yes | |High-Throughput| Variable rate, bursty long- | Low |Medium| Yes |
| Data | lived elastic flows | |- High| | | Data | lived elastic flows | |- High| |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
| Standard | A bit of everything | Not Specified | | Standard | A bit of everything | Not Specified |
|---------------+------------------------------+------+------+------| |---------------+------------------------------+------+------+------|
| Low Priority | Non real-time and elastic | High | High | Yes | | Low-Priority | Non-real-time and elastic | High | High | Yes |
| Data | | | | | | Data | | | | |
------------------------------------------------------------------- -------------------------------------------------------------------
Figure 2: Service Class Characteristics Figure 2. Service Class Characteristics
Notes for Figure 2: A "Yes" in the jitter-tolerant column implies
Note: A "Yes" in the jitter-tolerant column implies that data is that data is buffered in the endpoint and that a moderate level of
buffered in the endpoint, and a moderate level of network-induced network-induced variation in delay will not affect the application.
variation in delay will not affect the application. Applications Applications that use TCP as a transport are generally good examples.
that use TCP as a transport are generally good examples. Routing Routing protocols and peer-to-peer signaling also fall in this class;
protocols and peer-to-peer signaling also fall in this class; while although loss can create problems in setting up calls, a moderate
loss can create problems in setting up calls, a moderate level of level of jitter merely makes call placement a little less predictable
jitter merely makes call placement a little less predictable in in duration.
duration.
Service classes indicate the required traffic forwarding treatment in Service classes indicate the required traffic forwarding treatment in
order to meet user, application or network expectations. Section 3 order to meet user, application, or network expectations. Section 3
in this document defines the service classes that MAY be used for defines the service classes that MAY be used for forwarding network
forwarding network control traffic and Section 4 defines the service control traffic, and Section 4 defines the service classes that MAY
classes that MAY be used for forwarding user traffic with examples of be used for forwarding user traffic with examples of intended
intended application types mapped into each service class. Note that application types mapped into each service class. Note that the
the application types are only examples and are not meant to be all- application types are only examples and are not meant to be all-
inclusive or prescriptive. Also it should be noted that the service inclusive or prescriptive. Also, note that the service class naming
class naming or ordering does not imply any priority ordering. They or ordering does not imply any priority ordering. They are simply
are simply reference names that are used in this document with reference names that are used in this document with associated QoS
associated QoS behaviors that are optimized for the particular behaviors that are optimized for the particular application types
application types they support. Network administrators MAY choose to they support. Network administrators MAY choose to assign different
assign different service class names, to the service classes that service class names to the service classes that they will support.
they will support. Figure 3 defines the RECOMMENDED relationship Figure 3 defines the RECOMMENDED relationship between service classes
between service classes and DS codepoint(s) assignment with and DS codepoint assignment with application examples. It is
application examples. It is RECOMMENDED that this relationship be RECOMMENDED that this relationship be preserved end to end.
preserved end to end.
------------------------------------------------------------------ ------------------------------------------------------------------
| Service | DSCP | DSCP | Application | | Service | DSCP | DSCP | Application |
| Class name | name | value | Examples | | Class Name | Name | Value | Examples |
|===============+=========+=============+==========================| |===============+=========+=============+==========================|
|Network Control| CS6 | 110000 | Network routing | |Network Control| CS6 | 110000 | Network routing |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Telephony | EF | 101110 | IP Telephony bearer | | Telephony | EF | 101110 | IP Telephony bearer |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Signaling | CS5 | 101000 | IP Telephony signaling | | Signaling | CS5 | 101000 | IP Telephony signaling |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Multimedia |AF41,AF42|100010,100100| H.323/V2 video | | Multimedia |AF41,AF42|100010,100100| H.323/V2 video |
| Conferencing | AF43 | 100110 | conferencing (adaptive) | | Conferencing | AF43 | 100110 | conferencing (adaptive) |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Real-time | CS4 | 100000 | Video conferencing and | | Real-Time | CS4 | 100000 | Video conferencing and |
| Interactive | | | Interactive gaming | | Interactive | | | Interactive gaming |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Multimedia |AF31,AF32|011010,011100| Streaming video and | | Multimedia |AF31,AF32|011010,011100| Streaming video and |
| Streaming | AF33 | 011110 | audio on demand | | Streaming | AF33 | 011110 | audio on demand |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
|Broadcast Video| CS3 | 011000 |Broadcast TV & live events| |Broadcast Video| CS3 | 011000 |Broadcast TV & live events|
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Low Latency |AF21,AF22|010010,010100|Client/server transactions| | Low-Latency |AF21,AF22|010010,010100|Client/server transactions|
| Data | AF23 | 010110 | Web-based ordering | | Data | AF23 | 010110 | Web-based ordering |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| OAM | CS2 | 010000 | OAM&P | | OAM | CS2 | 010000 | OAM&P |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
|High Throughput|AF11,AF12|001010,001100| Store and forward | |High-Throughput|AF11,AF12|001010,001100| Store and forward |
| Data | AF13 | 001110 | applications | | Data | AF13 | 001110 | applications |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Standard | DF (CS0)| 000000 | Undifferentiated | | Standard | DF (CS0)| 000000 | Undifferentiated |
| | | | applications | | | | | applications |
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Low Priority | CS1 | 001000 | Any flow that has no BW | | Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance | | Data | | | assurance |
------------------------------------------------------------------ ------------------------------------------------------------------
Figure 3: DSCP to Service Class Mapping Figure 3. DSCP to Service Class Mapping
Note for Figure 3: Notes for Figure 3: Default Forwarding (DF) and Class Selector 0
o Default Forwarding (DF) and Class Selector 0 (CS0) provide (CS0) provide equivalent behavior and use the same DS codepoint,
equivalent behavior and use the same DS codepoint '000000'. '000000'.
It is expected that network administrators will choose the service It is expected that network administrators will base their choice of
classes that they will support based on their need, starting off with the service classes that they will support on their need, starting
three or four service classes for user traffic and add others as the off with three or four service classes for user traffic and adding
need arises. others as the need arises.
Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD be Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD be
used for the defined service classes that are further detailed in used for the defined service classes that are further detailed in
Section 3 and Section 4 of this document. Based on what Sections 3 and 4 of this document. According to what
applications/services that need to be differentiated, network applications/services need to be differentiated, network
administrators can choose the service class(es) that need to be administrators can choose the service class(es) that need to be
supported in their network. supported in their network.
------------------------------------------------------------------ ------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | Queuing| AQM| | Service | DSCP | Conditioning at | PHB | Queuing| AQM|
| Class | | DS Edge | Used | | | | Class | | DS Edge | Used | | |
|===============+======+===================+=========+========+====| |===============+======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate |Yes | |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate |Yes |
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
skipping to change at page 21, line 19 skipping to change at page 20, line 22
------------------------------------------------------------------ ------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | Queuing| AQM| | Service | DSCP | Conditioning at | PHB | Queuing| AQM|
| Class | | DS Edge | Used | | | | Class | | DS Edge | Used | | |
|===============+======+===================+=========+========+====| |===============+======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate |Yes | |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate |Yes |
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Multimedia | AF41 | Using two rate | | | Yes| | Multimedia | AF41 | Using two-rate, | | | Yes|
| Conferencing | AF42 |three color marker | RFC2597 | Rate | per| | Conferencing | AF42 |three-color marker | RFC2597 | Rate | per|
| | AF43 | (such as RFC2698) | | |DSCP| | | AF43 | (such as RFC2698) | | |DSCP|
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Real-time | CS4 |Police using sr+bs | RFC2474 | Rate | No | | Real-Time | CS4 |Police using sr+bs | RFC2474 | Rate | No |
| Interactive | | | | | | | Interactive | | | | | |
|---------------+------+-------------------+---------|--------+----| |---------------+------+-------------------+---------|--------+----|
| Multimedia | AF31 | Using two rate | | | Yes| | Multimedia | AF31 | Using two-rate, | | | Yes|
| Streaming | AF32 |three color marker | RFC2597 | Rate | per| | Streaming | AF32 |three-color marker | RFC2597 | Rate | per|
| | AF33 | (such as RFC2698) | | |DSCP| | | AF33 | (such as RFC2698) | | |DSCP|
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No | |Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Low | AF21 | Using single rate | | | Yes| | Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three color marker | RFC2597 | Rate | per| | Latency | AF22 |three-color marker | RFC2597 | Rate | per|
| Data | AF23 | (such as RFC2697) | | |DSCP| | Data | AF23 | (such as RFC2697) | | |DSCP|
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| High | AF11 | Using two rate | | | Yes| | High- | AF11 | Using two-rate, | | | Yes|
| Throughput | AF12 |three color marker | RFC2597 | Rate | per| | Throughput | AF12 |three-color marker | RFC2597 | Rate | per|
| Data | AF13 | (such as RFC2698) | | |DSCP| | Data | AF13 | (such as RFC2698) | | |DSCP|
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Standard | DF | Not applicable | RFC2474 | Rate | Yes| | Standard | DF | Not applicable | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Low Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| | Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | | | Data | | | | | |
------------------------------------------------------------------ ------------------------------------------------------------------
Figure 4: Summary of QoS Mechanisms used for each Service Class Figure 4. Summary of QoS Mechanisms Used for Each Service Class
Notes for Figure 4: Notes for Figure 4:
o Conditioning at DS edge, means that traffic conditioning is o Conditioning at DS edge means that traffic conditioning is
performed at the edge of the DiffServ network where untrusted user performed at the edge of the DiffServ network where untrusted user
devices are connected or between two DiffServ networks. devices are connected or between two DiffServ networks.
o "sr+bs" represents a policing mechanism that provides single rate o "sr+bs" represents a policing mechanism that provides single rate
with burst size control. with burst size control.
o The single rate three color marker (srTCM) behavior SHOULD be o The single-rate, three-color marker (srTCM) behavior SHOULD be
equivalent to RFC 2697 and the two rate three color marker (trTCM) equivalent to RFC 2697, and the two-rate, three-color marker
behavior SHOULD be equivalent to RFC 2698. (trTCM) behavior SHOULD be equivalent to RFC 2698.
o The PHB for Real-time Interactive service class SHOULD be o The PHB for Real-Time Interactive service class SHOULD be
configured to provide high bandwidth assurance. It MAY be configured to provide high bandwidth assurance. It MAY be
configured as a second EF PHB that uses relaxed performance configured as a second EF PHB that uses relaxed performance
parameters and a rate scheduler. parameters and a rate scheduler.
o The PHB for Broadcast Video service class SHOULD be configured to o The PHB for Broadcast Video service class SHOULD be configured to
provide high bandwidth assurance. It MAY be configured as a third provide high bandwidth assurance. It MAY be configured as a third
EF PHB that uses relaxed performance parameters and a rate EF PHB that uses relaxed performance parameters and a rate
scheduler. scheduler.
o In network segments that use IP precedence marking, only one of o In network segments that use IP precedence marking, only one of
the two service classes can be supported, High Throughput Data or the two service classes can be supported, High-Throughput Data or
Low Priority Data. We RECOMMEND that the DSCP value(s) of the Low-Priority Data. We RECOMMEND that the DSCP value(s) of the
unsupported service class to be changed to 000xx1 on ingress and unsupported service class be changed to 000xx1 on ingress and
changed back to original value(s) on egress of the network segment changed back to original value(s) on egress of the network segment
that uses precedence marking. For example, if Low Priority Data that uses precedence marking. For example, if Low-Priority Data
is mapped to Standard service class, then 000001 DSCP marking MAY is mapped to Standard service class, then 000001 DSCP marking MAY
be used to distinguish it from Standard marked packets on egress. be used to distinguish it from Standard marked packets on egress.
2.4. Deployment Scenarios 2.4. Deployment Scenarios
It is expected that network administrators will choose the service It is expected that network administrators will base their choice of
classes that they will support based on their need, starting off with the service classes that they will support on their need, starting
three or four service classes for user traffic and add more service off with three or four service classes for user traffic and adding
classes as the need arises. In this section we provide three more service classes as the need arises. In this section, we provide
examples of possible deployment scenarios. three examples of possible deployment scenarios.
2.4.1. Example 1 2.4.1. Example 1
A network administrator determined that they need to provide A network administrator determines that he needs to provide different
different performance levels (quality of service) in their network performance levels (quality of service) in his network for the
for the services that they will be offering to their customers. They services that he will be offering to his customers. He needs to
need to enable their network to provide: enable his network to provide:
o Reliable VoIP (telephony) service, equivalent to PSTN
o A low delay assured bandwidth data service o Reliable VoIP (telephony) service, equivalent to Public Switched
o As well, support current Internet services Telephone Network (PSTN).
o A low-delay assured bandwidth data service.
o Support for current Internet services.
For this example, the network administrator's needs are addressed For this example, the network administrator's needs are addressed
with the deployment of the following six service classes: with the deployment of the following six service classes:
o Network Control service class for routing and control traffic that o Network Control service class for routing and control traffic that
is needed for reliable operation of the provider's network is needed for reliable operation of the provider's network.
o Standard service class for all traffic that will receive normal o Standard service class for all traffic that will receive normal
(undifferentiated) forwarding treatment through their network for (undifferentiated) forwarding treatment through the network for
support of current Internet service support of current Internet service.
o Telephony service class for VoIP (telephony) bearer traffic o Telephony service class for VoIP (telephony) bearer traffic.
o Signaling service class for Telephony signaling to control the o Signaling service class for Telephony signaling to control the
VoIP service VoIP service.
o Low Latency Data service class for the low delay assured bandwidth o Low-Latency Data service class for the low-delay assured bandwidth
differentiated data service differentiated data service.
o OAM service class for operation and management of the network o OAM service class for operation and management of the network.
Figure 5, provides a summary of the mechanisms needed for delivery of Figure 5 provides a summary of the mechanisms needed for delivery of
service differentiation for Example 1. service differentiation for Example 1.
------------------------------------------------------------------- -------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | | | Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM| | Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====| |===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes| |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
skipping to change at page 23, line 26 skipping to change at page 22, line 38
------------------------------------------------------------------- -------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | | | Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM| | Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====| |===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes| |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Low | AF21 | Using single rate | | |Yes | | Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three color marker | RFC2597 | Rate |Per | | Latency | AF22 |three-color marker | RFC2597 | Rate | per|
| Data | AF23 | (such as RFC2697) | | |DSCP| | Data | AF23 | (such as RFC2697) | | |DSCP|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes| | Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | | | | +other| | | | |
------------------------------------------------------------------- -------------------------------------------------------------------
Figure 5: Service Provider Network Configuration Example 1 Figure 5. Service Provider Network Configuration Example 1
Notes for Figure 5: Notes for Figure 5:
o "sr+bs" represents a policing mechanism that provides single rate o "sr+bs" represents a policing mechanism that provides single rate
with burst size control. with burst size control.
o The single rate three color marker (srTCM) behavior SHOULD be o The single-rate, three-color marker (srTCM) behavior SHOULD be
equivalent to RFC 2697. equivalent to RFC 2697.
o Any packet that is marked with DSCP value that is not represented o Any packet that is marked with DSCP value that is not represented
by the supported service classes, SHOULD be forwarded using the by the supported service classes SHOULD be forwarded using the
Standard service class. Standard service class.
2.4.2. Example 2 2.4.2. Example 2
With this example we show how network operators with Example 1 With this example, we show how network operators with Example 1
capabilities can evolve their service offering to provide three new capabilities can evolve their service offering to provide three new
additional services to their customers. The new additional service additional services to their customers. The new additional service
capabilities that are to be added are: capabilities that are to be added are:
o SIP based desktop video conference capability to complement VoIP
(telephony) service o SIP-based desktop video conference capability to complement VoIP
o Provide TV and on demand movie viewing service to residential (telephony) service.
subscribers o TV and on-demand movie viewing service to residential subscribers.
o Provide network based data storage and file backup service to o Network-based data storage and file backup service to business
business customers customers.
The new additional services that the network administrator would like The new additional services that the network administrator would like
to offer are addressed with the deployment of the following four to offer are addressed with the deployment of the following four
additional service classes. (These are additions to the six service additional service classes (these are additions to the six service
classes already defined in Example 1): classes already defined in Example 1):
o Real-time Interactive service class for transport of MPEG-4 real-
o Real-Time Interactive service class for transport of MPEG-4 real-
time video flows to support desktop video conferencing. The time video flows to support desktop video conferencing. The
control/signaling for video conferencing is done using the control/signaling for video conferencing is done using the
Signaling service class. Signaling service class.
o Broadcast Video service class for transport of IPTV broadcast o Broadcast Video service class for transport of IPTV broadcast
information. The channel selection and control is via IGMP information. The channel selection and control is via IGMP mapped
(Internet Group Management Protocol) mapped into the Signaling into the Signaling service class.
service class.
o Multimedia Streaming service class for transport of stored MPEG-2 o Multimedia Streaming service class for transport of stored MPEG-2
or MPEG-4 content. The selection and control of streaming or MPEG-4 content. The selection and control of streaming
information is done using the Signaling service class. The information is done using the Signaling service class. The
selection of Multimedia Streaming service class for on demand selection of Multimedia Streaming service class for on-demand
movie service was chosen as the set-top box used for this service movie service was chosen as the set-top box used for this service
has local buffering capability to compensate for the bandwidth has local buffering capability to compensate for the bandwidth
variability of the elastic streaming information. Note, if variability of the elastic streaming information. Note that if
transport of on demand movie service is inelastic, then the transport of on-demand movie service is inelastic, then the
Broadcast Video service class SHOULD be used. Broadcast Video service class SHOULD be used.
o High Throughput Data service class is for transport of bulk data o High-Throughput Data service class is for transport of bulk data
for network based storage and file backup service to business for network-based storage and file backup service to business
customers. customers.
Figure 6, provides a summary of the mechanisms needed for delivery of Figure 6 provides a summary of the mechanisms needed for delivery of
service differentiation for all the service classes used in Example service differentiation for all the service classes used in Example
2. 2.
------------------------------------------------------------------- -------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | | | Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM| | Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====| |===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes| |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Real-time | CS4 |Police using sr+bs | RFC2474 | Rate | No | | Real-time | CS4 |Police using sr+bs | RFC2474 | Rate | No |
| Interactive | | | | | | | Interactive | | | | | |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No | |Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF31 | Using two rate | | |Yes | | Multimedia | AF31 | Using two-rate, | | |Yes |
| Streaming | AF32 |three color marker | RFC2597 | Rate |Per | | Streaming | AF32 |three-color marker | RFC2597 | Rate |per |
| | AF33 | (such as RFC2698) | | |DSCP| | | AF33 | (such as RFC2698) | | |DSCP|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Low | AF21 | Using single rate | | |Yes | | Low- | AF21 | Using single-rate,| | |Yes |
| Latency | AF22 |three color marker | RFC2597 | Rate |Per | | Latency | AF22 |three-color marker | RFC2597 | Rate |per |
| Data | AF23 | (such as RFC2697) | | |DSCP| | Data | AF23 | (such as RFC2697) | | |DSCP|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| High | AF11 | Using two rate | | |Yes | | High- | AF11 | Using two-rate, | | |Yes |
| Throughput | AF12 |three color marker | RFC2597 | Rate |Per | | Throughput | AF12 |three-color marker | RFC2597 | Rate |per |
| Data | AF13 | (such as RFC2698) | | |DSCP| | Data | AF13 | (such as RFC2698) | | |DSCP|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes| | Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | | | | +other| | | | |
------------------------------------------------------------------- -------------------------------------------------------------------
Figure 6: Service Provider Network Configuration Example 2 Figure 6. Service Provider Network Configuration Example 2
Notes for Figure 6: Notes for Figure 6:
o "sr+bs" represents a policing mechanism that provides single rate o "sr+bs" represents a policing mechanism that provides single rate
with burst size control. with burst size control.
o The single rate three color marker (srTCM) behavior SHOULD be o The single-rate, three-color marker (srTCM) behavior SHOULD be
equivalent to RFC 2697 and the two rate three color marker (trTCM) equivalent to RFC 2697, and the two-rate, three-color marker
behavior SHOULD be equivalent to RFC 2698. (trTCM) behavior SHOULD be equivalent to RFC 2698.
o Any packet that is marked with DSCP value that is not represented o Any packet that is marked with DSCP value that is not represented
by the supported service classes, SHOULD be forwarded using the by the supported service classes SHOULD be forwarded using the
Standard service class. Standard service class.
2.4.3. Example 3 2.4.3. Example 3
An enterprise network administrator determined that they need to An enterprise network administrator determines that they need to
provide different performance levels (quality of service) in their provide different performance levels (quality of service) in their
network for the new services that are being offered to corporate network for the new services that are being offered to corporate
users. The enterprise network needs to: users. The enterprise network needs to:
o Provide reliable corporate VoIP service
o Provide video conferencing service to selected Conference Rooms o Provide reliable corporate VoIP service.
o Support on demand distribution of prerecorded audio and video o Provide video conferencing service to selected Conference Rooms.
information to large number of users o Support on-demand distribution of prerecorded audio and video
information to large number of users.
o Provide a priority data transfer capability for engineering teams o Provide a priority data transfer capability for engineering teams
to share design information to share design information.
o Reduce or deny bandwidth during peak traffic periods for selected o Reduce or deny bandwidth during peak traffic periods for selected
applications applications.
o Continue to provide normal IP service to all remaining o Continue to provide normal IP service to all remaining
applications and services applications and services.
For this example, the enterprise's network needs are addressed with For this example, the enterprise's network needs are addressed with
the deployment of the following nine service classes: the deployment of the following nine service classes:
o Network Control service class for routing and control traffic that o Network Control service class for routing and control traffic that
is needed for reliable operation of the enterprise network is needed for reliable operation of the enterprise network.
o OAM service class for operation and management of the network o OAM service class for operation and management of the network.
o Standard service class for all traffic that will receive normal o Standard service class for all traffic that will receive normal
(undifferentiated) forwarding treatment (undifferentiated) forwarding treatment.
o Telephony service class for VoIP (telephony) bearer traffic o Telephony service class for VoIP (telephony) bearer traffic.
o Signaling service class for Telephony signaling to control the o Signaling service class for Telephony signaling to control the
VoIP service VoIP service.
o Multimedia Conferencing service class for support of inter o Multimedia Conferencing service class for support of inter-
Conference Room video conferencing service using H.323/V2 or Conference Room video conferencing service using H.323/V2 or
similar equipment. similar equipment.
o Multimedia Streaming service class for transfer of prerecorded o Multimedia Streaming service class for transfer of prerecorded
audio and video information audio and video information.
o High Throughput Data service class to provide bandwidth assurance o High-Throughput Data service class to provide bandwidth assurance
for timely transfer of large engineering files for timely transfer of large engineering files.
o Low Priority Data service class for selected background o Low-Priority Data service class for selected background
applications where data transfer can be delayed or suspended for a applications where data transfer can be delayed or suspended for a
period of time during peak network load conditions period of time during peak network load conditions.
Figure 7, provides a summary of the mechanisms need for delivery of Figure 7 provides a summary of the mechanisms needed for delivery of
service differentiation for Example 3. service differentiation for Example 3.
------------------------------------------------------------------- -------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | | | Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM| | Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====| |===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.2 | RFC2474 | Rate | Yes| |Network Control| CS6 | See Section 3.2 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF41 | Using two rate | | | Yes| | Multimedia | AF41 | Using two-rate, | | | Yes|
| Conferencing | AF42 | three color marker| RFC2597 | Rate | Per| | Conferencing | AF42 | three-color marker| RFC2597 | Rate | per|
| | AF43 | (such as RFC2698) | | |DSCP| | | AF43 | (such as RFC2698) | | |DSCP|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF31 | Using two rate | | | Yes| | Multimedia | AF31 | Using two-rate, | | | Yes|
| Streaming | AF32 | three color marker| RFC2597 | Rate | Per| | Streaming | AF32 | three-color marker| RFC2597 | Rate | per|
| | AF33 | (such as RFC2698) | | |DSCP| | | AF33 | (such as RFC2698) | | |DSCP|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| High | AF11 | Using two rate | | |Yes | | High- | AF11 | Using two-rate, | | |Yes |
| Throughput | AF12 |three color marker | RFC2597 | Rate |Per | | Throughput | AF12 |three-color marker | RFC2597 | Rate |per |
| Data | AF13 | (such as RFC2698) | | |DSCP| | Data | AF13 | (such as RFC2698) | | |DSCP|
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Low Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| | Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | | | Data | | | | | |
|---------------+-------+-------------------+---------+--------+----| |---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes| | Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | | | | +other| | | | |
------------------------------------------------------------------- -------------------------------------------------------------------
Figure 7: Enterprise Network Configuration Example Figure 7. Enterprise Network Configuration Example
Notes for Figure 7: Notes for Figure 7:
o "sr+bs" represents a policing mechanism that provides single rate o "sr+bs" represents a policing mechanism that provides single rate
with burst size control. with burst size control.
o The single rate three color marker (srTCM) behavior SHOULD be o The single-rate, three-color marker (srTCM) behavior SHOULD be
equivalent to RFC 2697 and the two rate three color marker (trTCM) equivalent to RFC 2697, and the two-rate, three-color marker
behavior SHOULD be equivalent to RFC 2698. (trTCM) behavior SHOULD be equivalent to RFC 2698.
o Any packet that is marked with DSCP value that is not represented o Any packet that is marked with DSCP value that is not represented
by the supported service classes, SHOULD be forwarded using the by the supported service classes SHOULD be forwarded using the
Standard service class. Standard service class.
3. Network Control Traffic 3. Network Control Traffic
Network control traffic is defined as packet flows that are essential Network control traffic is defined as packet flows that are essential
for stable operation of the administered network as well for for stable operation of the administered network as well as for
information that may be exchanged between neighboring networks across information that may be exchanged between neighboring networks across
a peering point where SLAs are in place. Network control traffic is a peering point where SLAs are in place. Network control traffic is
different from user application control (signaling) that may be different from user application control (signaling) that may be
generated by some applications or services. Network control traffic generated by some applications or services. Network control traffic
is mostly between routers and network nodes that are used for is mostly between routers and network nodes that are used for
operating, administering, controlling or managing the network operating, administering, controlling, or managing the network
segments. Network Control Traffic may be split into two service segments. Network Control Traffic may be split into two service
classes, i.e. Network Control and OAM. classes, i.e., Network Control and OAM.
3.1. Current Practice in The Internet 3.1. Current Practice in the Internet
Based on today's routing protocols and network control procedures Based on today's routing protocols and network control procedures
that are used in The Internet, we have determined that CS6 DSCP value that are used in the Internet, we have determined that CS6 DSCP value
SHOULD be used for routing and control and that CS7 DSCP value be SHOULD be used for routing and control and that CS7 DSCP value SHOULD
reserved for future use, potentially for future routing and/or be reserved for future use, potentially for future routing or control
control protocols. Network administrator MAY use a Local/ protocols. Network administrators MAY use a Local/Experimental DSCP;
Experimental DSCP therefore a locally defined service class within therefore, they may use a locally defined service class within their
their network to further differentiate their routing and control network to further differentiate their routing and control traffic.
traffic.
RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets: RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets:
o Drop or remark CS7 marked packets at ingress to DiffServ network
domain. o Drop or remark CS7 packets at ingress to DiffServ network domain.
o CS7 marked packets SHOULD NOT be sent across peering points. o CS7 marked packets SHOULD NOT be sent across peering points.
Exchange of control information across peering points SHOULD be Exchange of control information across peering points SHOULD be
done using CS6 DSCP, using Network Control service class. done using CS6 DSCP and the Network Control service class.
3.2. Network Control Service Class 3.2. Network Control Service Class
The Network Control service class is used for transmitting packets The Network Control service class is used for transmitting packets
between network devices (routers) that require control (routing) between network devices (routers) that require control (routing)
information to be exchanged between nodes within the administrative information to be exchanged between nodes within the administrative
domain as well across a peering point between different domain as well as across a peering point between different
administrative domains. Traffic transmitted in this service class is administrative domains. Traffic transmitted in this service class is
very important as it keeps the network operational and needs to be very important as it keeps the network operational, and it needs to
forwarded in a timely manner. be forwarded in a timely manner.
The Network Control service class SHOULD be configured using the The Network Control service class SHOULD be configured using the
DiffServ Class Selector (CS) PHB defined in [RFC2474]. This service DiffServ Class Selector (CS) PHB, defined in [RFC2474]. This service
class SHOULD be configured so that the traffic receives a minimum class SHOULD be configured so that the traffic receives a minimum
bandwidth guarantee, to ensure that the packets always receive timely bandwidth guarantee, to ensure that the packets always receive timely
service. The configured forwarding resources for Network Control service. The configured forwarding resources for Network Control
service class SHOULD be such that the probability of packet drop service class SHOULD be such that the probability of packet drop
under peak load is very low in this service class. The Network under peak load is very low in this service class. The Network
Control service class SHOULD be configured to use a Rate Queuing Control service class SHOULD be configured to use a Rate Queuing
system such as defined in Section 1.4.1.2 of this document. system such as defined in Section 1.4.1.2 of this document.
Examples of protocols and application that SHOULD use the Network The following are examples of protocols and applications that SHOULD
Control service class: use the Network Control service class:
o Routing packet flows: OSPF, BGP, ISIS, RIP
o Routing packet flows: OSPF, BGP, ISIS, RIP.
o Control information exchange within and between different o Control information exchange within and between different
administrative domains across a peering point where SLAs are in administrative domains across a peering point where SLAs are in
place place.
o LSP setup using CR-LDP and RSVP-TE o LSP setup using CR-LDP and RSVP-TE.
The following protocols and applications SHOULD NOT use the Network The following protocols and applications SHOULD NOT use the Network
Control service class: Control service class:
o User traffic
Traffic characteristics of packet flows in the Network Control o User traffic.
service class:
o Mostly messages sent between routers and network servers The following are traffic characteristics of packet flows in the
o Ranging from 50 to 1,500 byte packet sizes, normally one packet at Network Control service class:
a time but traffic can also burst (BGP)
o Mostly messages sent between routers and network servers.
o Variable size packets, normally one packet at a time, but traffic
can also burst (BGP).
o User traffic is not allowed to use this service class. By user o User traffic is not allowed to use this service class. By user
traffic we mean packet flows that originate from user controlled traffic, we mean packet flows that originate from user-controlled
end points that are connected to the network. end points that are connected to the network.
RECOMMENDED DSCP marking is CS6 (Class Selector 6) The RECOMMENDED DSCP marking is CS6 (Class Selector 6).
RECOMMENDED Network Edge Conditioning: RECOMMENDED Network Edge Conditioning:
o At peering points (between two DiffServ networks) where SLAs are o At peering points (between two DiffServ networks) where SLAs are
in place, CS6 marked packets SHOULD be policed, e.g. using a in place, CS6 marked packets SHOULD be policed, e.g., using a
single rate with burst size (sr+bs) token bucket policer to keep single rate with burst size (sr+bs) token bucket policer to keep
the CS6 marked packet flows to within the traffic rate specified the CS6 marked packet flows to within the traffic rate specified
in the SLA. in the SLA.
o CS6 marked packet flows from untrusted sources (for example, end o CS6 marked packet flows from untrusted sources (for example, end
user devices) SHOULD be dropped or remarked at ingress to DiffServ user devices) SHOULD be dropped or remarked at ingress to the
network. DiffServ network.
o Packets from users/subscribers are not permitted access to the o Packets from users/subscribers are not permitted access to the
Network Control service classes. Network Control service classes.
The fundamental service offered to the Network Control service class The fundamental service offered to the Network Control service class
is enhanced best effort service with high bandwidth assurance. Since is enhanced best-effort service with high bandwidth assurance. Since
this service class is used to forward both elastic and inelastic this service class is used to forward both elastic and inelastic
flows, the service SHOULD be engineered so the Active Queue flows, the service SHOULD be engineered so that the Active Queue
Management (AQM) [RFC2309] is applied to CS6 marked packets. Management (AQM) [RFC2309] is applied to CS6 marked packets.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth, and the max-threshold specifies the specifies a target queue depth, and the max-threshold specifies the
queue depth above which all traffic is dropped or ECN marked. Thus, queue depth above which all traffic is dropped or ECN marked. Thus,
in this service class, the following inequality should hold in queue in this service class, the following inequality should hold in queue
configurations: configurations:
o min-threshold CS6 < max-threshold CS6 o min-threshold CS6 < max-threshold CS6
o max-threshold CS6 <= memory assigned to the queue o max-threshold CS6 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result. configured to achieve a similar result.
3.3. OAM Service Class 3.3. OAM Service Class
The OAM (Operations, Administration and Management) service class is The OAM (Operations, Administration, and Management) service class is
RECOMMENDED for OAM&P (Operations, Administration and Management and RECOMMENDED for OAM&P (Operations, Administration, and Management and
Provisioning) using protocols such as SNMP, TFTP, FTP, Telnet, COPS, Provisioning) using protocols such as Simple Network Management
etc. Applications using this service class require a low packet loss Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet,
but are relatively not sensitive to delay. This service class is and Common Open Policy Service (COPS). Applications using this
configured to provide good packet delivery for intermittent flows. service class require a low packet loss but are relatively not
sensitive to delay. This service class is configured to provide good
packet delivery for intermittent flows.
The OAM service class SHOULD use the Class Selector (CS) PHB defined The OAM service class SHOULD use the Class Selector (CS) PHB defined
in [RFC2474]. This service class SHOULD be configured to provide a in [RFC2474]. This service class SHOULD be configured to provide a
minimum bandwidth assurance for CS2 marked packets to ensure that minimum bandwidth assurance for CS2 marked packets to ensure that
they get forwarded. The OAM service class SHOULD be configured to they get forwarded. The OAM service class SHOULD be configured to
use a Rate Queuing system such as defined in Section 1.4.1.2 of this use a Rate Queuing system such as defined in Section 1.4.1.2 of this
document. document.
The following applications SHOULD use the OAM service class: The following applications SHOULD use the OAM service class:
o For provisioning and configuration of network elements
o For performance monitoring of network elements
o For any network operational alarms
Traffic characteristics: o Provisioning and configuration of network elements.
o Variable size packets (50 to 1500 bytes in size) o Performance monitoring of network elements.
o Intermittent traffic flows o Any network operational alarms.
o Traffic may burst at times
o Both elastic and inelastic flows The following are traffic characteristics:
o Traffic not sensitive to delays
o Variable size packets.
o Intermittent traffic flows.
o Traffic may burst at times.
o Both elastic and inelastic flows.
o Traffic not sensitive to delays.
RECOMMENDED DSCP marking: RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS2 (Class o All flows in this service class are marked with CS2 (Class
Selector 2) Selector 2).
Applications or IP end points SHOULD pre-mark their packets with CS2 Applications or IP end points SHOULD pre-mark their packets with CS2
DSCP value. If the end point is not capable of setting the DSCP DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point SHOULD value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification as defined in [RFC2475]. perform Multifield (MF) Classification, as defined in [RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
RECOMMENDED Conditioning Performed at DiffServ Network Edge:
o Packet flow marking (DSCP setting) from untrusted sources (end o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in [RFC2475]. using Multifield (MF) Classification methods, defined in
[RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g. using single rate policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds. stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (routers inside administered o Packet flows from trusted sources (routers inside administered
network) MAY not require policing. network) MAY not require policing.
o Normally OAM&P CS2 marked packet flows are not allowed to flow o Normally OAM&P CS2 marked packet flows are not allowed to flow
across peering points, if that is the case, then CS2 marked across peering points. If that is the case, then CS2 marked
packets SHOULD be policed (dropped) at both egress and ingress packets SHOULD be policed (dropped) at both egress and ingress
peering interfaces. peering interfaces.
The fundamental service offered to "OAM" traffic is enhanced best The fundamental service offered to "OAM" traffic is enhanced best-
effort service with controlled rate. The service SHOULD be effort service with controlled rate. The service SHOULD be
engineered so that CS2 marked packet flows have sufficient bandwidth engineered so that CS2 marked packet flows have sufficient bandwidth
in the network to provide high assurance of delivery. Since this in the network to provide high assurance of delivery. Since this
service class is used to forward both elastic and inelastic flows, service class is used to forward both elastic and inelastic flows,
the service SHOULD be engineered so that Active Queue Management the service SHOULD be engineered so that Active Queue Management
[RFC2309] is applied to CS2 marked packets. [RFC2309] is applied to CS2 marked packets.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP is specifies the queue depth above which all traffic with such a DSCP is
skipping to change at page 31, line 25 skipping to change at page 30, line 40
in the network to provide high assurance of delivery. Since this in the network to provide high assurance of delivery. Since this
service class is used to forward both elastic and inelastic flows, service class is used to forward both elastic and inelastic flows,
the service SHOULD be engineered so that Active Queue Management the service SHOULD be engineered so that Active Queue Management
[RFC2309] is applied to CS2 marked packets. [RFC2309] is applied to CS2 marked packets.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP is specifies the queue depth above which all traffic with such a DSCP is
dropped or ECN marked. Thus, in this service class, the following dropped or ECN marked. Thus, in this service class, the following
inequality should hold in queue configurations: inequality should hold in queue configurations:
o min-threshold CS2 < max-threshold CS2 o min-threshold CS2 < max-threshold CS2
o max-threshold CS2 <= memory assigned to the queue o max-threshold CS2 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result. configured to achieve a similar result.
4. User Traffic 4. User Traffic
User traffic is defined as packet flows between different users or User traffic is defined as packet flows between different users or
subscribers. It is the traffic that is sent to or from end-terminals subscribers. It is the traffic that is sent to or from end-terminals
and that support very wide variety of applications and services. and that supports a very wide variety of applications and services.
User traffic can be differentiated in many different ways, therefore User traffic can be differentiated in many different ways; therefore,
we investigated several different approaches to classify user we investigated several different approaches to classifying user
traffic. We looked at differentiating user traffic as real-time traffic. We looked at differentiating user traffic as real-time
versus non real-time, elastic or rate adaptive versus inelastic, versus non-real-time, elastic or rate-adaptive versus inelastic,
sensitive versus insensitive to loss as well traffic categorization sensitive versus insensitive to loss as well as traffic
as interactive, responsive, timely and non-critical as defined in categorization as interactive, responsive, timely, and non-critical,
ITU-T Recommendation G.1010. At the end, we added up using all of as defined in ITU-T Recommendation G.1010. In the final analysis, we
the above for service differentiation, mapping of applications that used all of the above for service differentiation, mapping
have the matching traffic characteristics that fit the traffic application types that seemed to have different sets of performance
profile and performance requirements of the defined service classes. sensitivities, and requirements to different service classes.
Network administrators can categorize their applications based on the Network administrators can categorize their applications according to
type of behavior that they require and MAY choose to support all or the type of behavior that they require and MAY choose to support all
subset of the defined service classes. Figure 3 provides some common or a subset of the defined service classes. Figure 3 provides some
applications and the forwarding service class that best supports them common applications and the forwarding service classes that best
based on their performance requirements. support them, based on their performance requirements.
4.1. Telephony Service Class 4.1. Telephony Service Class
The Telephony service class is RECOMMENDED for applications that The Telephony service class is RECOMMENDED for applications that
require real-time, very low delay, very low jitter, and very low require real-time, very low delay, very low jitter, and very low
packet loss for relatively constant-rate traffic sources (inelastic packet loss for relatively constant-rate traffic sources (inelastic
traffic sources). This service class SHOULD be used for IP telephony traffic sources). This service class SHOULD be used for IP telephony
service. service.
The fundamental service offered to traffic in the Telephony service The fundamental service offered to traffic in the Telephony service
class is minimum jitter, delay, and packet loss service up to a class is minimum jitter, delay, and packet loss service up to a
specified upper bound. Operation is in some respect similar to an specified upper bound. Operation is in some respect similar to an
ATM CBR service, which has guaranteed bandwidth and which, if it ATM CBR service, which has guaranteed bandwidth and which, if it
stays within the negotiated rate, experiences nominal delay and no stays within the negotiated rate, experiences nominal delay and no
loss. The EF PHB has a similar guarantee. loss. The EF PHB has a similar guarantee.
Typical configurations negotiate the setup of telephone calls over IP Typical configurations negotiate the setup of telephone calls over
using protocols such as H.248, MEGACO, H.323, or SIP. When a user IP, using protocols such as H.248, MEGACO, H.323, or SIP. When a
has been authorized to send telephony traffic, the call admission user has been authorized to send telephony traffic, the call
procedure should have verified that the newly admitted flow will be admission procedure should have verified that the newly admitted flow
within the capacity of the Telephony service class forwarding will be within the capacity of the Telephony service class forwarding
capability in the network. For VoIP (telephony) service, call capability in the network. For VoIP (telephony) service, call
admission control is usually performed by a telephony call server/ admission control is usually performed by a telephony call server/
gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) on gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) on
access points to the network. The bandwidth in the core network and access points to the network. The bandwidth in the core network and
the number of simultaneous VoIP sessions that can be supported needs the number of simultaneous VoIP sessions that can be supported needs
to be engineered and controlled so that there is no congestion for to be engineered and controlled so that there is no congestion for
this service. Since RTP telephony flows do not react to loss or this service. Since the inelastic types of RTP payloads in this
substantial delay in any substantive way, the Telephony service class class do not react to loss or significant delay in any substantive
SHOULD forward packet as soon as possible. way, the Telephony service class SHOULD forward packets as soon as
possible. Some RTP payloads that may be used in telephony
applications are adaptive and will not be in this class.
The Telephony service class SHOULD use Expedited Forwarding (EF) PHB The Telephony service class SHOULD use Expedited Forwarding (EF) PHB,
as defined in [RFC3246] and SHOULD be configured to receive as defined in [RFC3246], and SHOULD be configured to receive
guaranteed forwarding resources so that all packets are forwarded guaranteed forwarding resources so that all packets are forwarded
quickly. The Telephony service class SHOULD be configured to use a quickly. The Telephony service class SHOULD be configured to use a
Priority Queuing system such as defined in Section 1.4.1.1 of this Priority Queuing system such as that defined in Section 1.4.1.1 of
document. this document.
The following application SHOULD use the Telephony service class: The following applications SHOULD use the Telephony service class:
o VoIP (G.711, G.729 and other codecs)
o Voice-band data over IP (modem, fax) o VoIP (G.711, G.729 and other codecs).
o T.38 fax over IP o Voice-band data over IP (modem, fax).
o T.38 fax over IP.
o Circuit emulation over IP, virtual wire, etc. o Circuit emulation over IP, virtual wire, etc.
o IP VPN service that specifies single rate, mean network delay that o IP Virtual Private Network (VPN) service that specifies single-
is slightly longer then network propagation delay, very low jitter rate, mean network delay that is slightly longer then network
and a very low packet loss propagation delay, very low jitter, and a very low packet loss.
Traffic characteristics: The following are traffic characteristics:
o Mostly fixed size packets for VoIP (60, 70, 120 or 200 bytes in o Mostly fixed-size packets for VoIP (60, 70, 120 or 200 bytes in
size) size).
o Packets emitted at constant time intervals o Packets emitted at constant time intervals.
o Admission control of new flows is provided by telephony call o Admission control of new flows is provided by telephony call
server, media gateway, gatekeeper, edge router, end terminal or server, media gateway, gatekeeper, edge router, end terminal, or
access node that provides flow admission control function. access node that provides flow admission control function.
Applications or IP end points SHOULD pre-mark their packets with EF Applications or IP end points SHOULD pre-mark their packets with EF
DSCP value. If the end point is not capable of setting the DSCP DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point SHOULD value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification as defined in [RFC2475]. perform Multifield (MF) Classification, as defined in [RFC2475].
RECOMMENDED DSCP marking is EF for the following applications: The RECOMMENDED DSCP marking is EF for the following applications:
o VoIP (G.711, G.729 and other codecs)
o Voice-band data over IP (modem and fax) o VoIP (G.711, G.729 and other codecs).
o T.38 fax over IP o Voice-band data over IP (modem and fax).
o T.38 fax over IP.
o Circuit emulation over IP, virtual wire, etc. o Circuit emulation over IP, virtual wire, etc.
RECOMMENDED Network Edge Conditioning: RECOMMENDED Network Edge Conditioning:
o Packet flow marking (DSCP setting) from untrusted sources (end o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in [RFC2475]. using Multifield (MF) Classification methods, defined in
[RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g. using single rate policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the telephony with burst size token bucket policer to ensure that the telephony
traffic stays within its negotiated bounds. traffic stays within its negotiated bounds.
o Policing is OPTIONAL for packet flows from trusted sources whose o Policing is OPTIONAL for packet flows from trusted sources whose
behavior is assured via other means (e.g., administrative controls behavior is ensured via other means (e.g., administrative controls
on those systems). on those systems).
o Policing of Telephony packet flows across peering points where SLA o Policing of Telephony packet flows across peering points where SLA
is in place is OPTIONAL as telephony traffic will be controlled by is in place is OPTIONAL as telephony traffic will be controlled by
admission control mechanism between peering points. admission control mechanism between peering points.
The fundamental service offered to "Telephony" traffic is enhanced The fundamental service offered to "Telephony" traffic is enhanced
best effort service with controlled rate, very low delay and very low best-effort service with controlled rate, very low delay, and very
loss. The service MUST be engineered so that EF marked packet flows low loss. The service MUST be engineered so that EF marked packet
have sufficient bandwidth in the network to provide guaranteed flows have sufficient bandwidth in the network to provide guaranteed
delivery. Normally traffic in this service class does not respond delivery. Normally traffic in this service class does not respond
dynamically to packet loss. As such, Active Queue Management dynamically to packet loss. As such, Active Queue Management
[RFC2309] SHOULD NOT be applied to EF marked packet flows. [RFC2309] SHOULD NOT be applied to EF marked packet flows.
4.2. Signaling Service Class 4.2. Signaling Service Class
The Signaling service class is RECOMMENDED for delay sensitive The Signaling service class is RECOMMENDED for delay-sensitive
client-server (traditional telephony) and peer-to-peer application client-server (traditional telephony) and peer-to-peer application
signaling. Telephony signaling includes signaling between IP phone signaling. Telephony signaling includes signaling between IP phone
and soft-switch, soft-client and soft-switch, media gateway and soft- and soft-switch, soft-client and soft-switch, and media gateway and
switch as well as peer-to-peer using various protocols. This service soft-switch as well as peer-to-peer using various protocols. This
class is intended to be used for control of sessions and service class is intended to be used for control of sessions and
applications. Applications using this service class requiring a applications. Applications using this service class require a
relatively fast response as there are typically several message of relatively fast response, as there are typically several messages of
different size sent for control of the session. This service class different sizes sent for control of the session. This service class
is configured to provide good response for short lived, intermittent is configured to provide good response for short-lived, intermittent
flows that require real-time packet forwarding. To minimize the flows that require real-time packet forwarding. To minimize the
possibility of ring clipping at start of call for VoIP service that possibility of ring clipping at start of call for VoIP service that
interface to a circuit switch Exchange in the Public Switch Telephone interfaces to a circuit switch Exchange in the Public Switched
Network (PSTN), the Signaling service class SHOULD be configured so Telephone Network (PSTN), the Signaling service class SHOULD be
that the probability of packet drop or significant queuing delay configured so that the probability of packet drop or significant
under peak load is very low in IP network segments that provide this queuing delay under peak load is very low in IP network segments that
interface. The term "ring clipping" refers to those instances where provide this interface. The term "ring clipping" refers to those
the front end of a ringing signal is altered because the bearer path instances where the front end of a ringing signal is altered because
is not made available in time to carry all of the audible ringing the bearer path is not made available in time to carry all of the
signal. This condition may occur due to a race condition between audible ringing signal. This condition may occur due to a race
when the tone generator in the circuit switch Exchange is turn on and condition between when the tone generator in the circuit switch
when the bearer path through the IP network is enabled. See Exchange is turned on and when the bearer path through the IP network
Section 9.1 for additional explanation of "ring clipping" and is enabled. See Section 8.1 for additional explanation of "ring
Section 5.1 for explanation of mapping different signaling methods to clipping" and Section 5.1 for explanation of mapping different
service classes. signaling methods to service classes.
The Signaling service class SHOULD use the Class Selector (CS) PHB The Signaling service class SHOULD use the Class Selector (CS) PHB,
defined in [RFC2474]. This service class SHOULD be configured to defined in [RFC2474]. This service class SHOULD be configured to
provide a minimum bandwidth assurance for CS5 marked packets to provide a minimum bandwidth assurance for CS5 marked packets to
ensure that they get forwarded. The Signaling service class SHOULD ensure that they get forwarded. The Signaling service class SHOULD
be configured to use a Rate Queuing system such as defined in be configured to use a Rate Queuing system such as that defined in
Section 1.4.1.2 of this document. Section 1.4.1.2 of this document.
The following applications SHOULD use the Signaling service class: The following applications SHOULD use the Signaling service class:
o Peer-to-peer IP telephony signaling (e.g., using SIP, H.323)
o Peer-to-peer IP telephony signaling (e.g., using SIP, H.323).
o Peer-to-peer signaling for multimedia applications (e.g., using o Peer-to-peer signaling for multimedia applications (e.g., using
SIP, H.323) SIP, H.323).
o Peer-to-peer real-time control function o Peer-to-peer real-time control function.
o Client-server IP telephony signaling using H.248, MEGACO, MGCP, IP o Client-server IP telephony signaling using H.248, MEGACO, MGCP, IP
encapsulated ISDN or other proprietary protocols encapsulated ISDN, or other proprietary protocols.
o Signaling to control IPTV applications using protocols such as o Signaling to control IPTV applications using protocols such as
IGMP (Internet Group Management Protocol) IGMP.
o Signaling flows between high capacity telephony call servers or o Signaling flows between high-capacity telephony call servers or
soft switches using protocol such as SIP-T. Such high capacity soft switches using protocol such as SIP-T. Such high-capacity
devices may control thousands of telephony (VoIP) calls. devices may control thousands of telephony (VoIP) calls.
Traffic characteristics: The following are traffic characteristics:
o Variable size packets (50 to 1500 bytes in size)
o Intermittent traffic flows o Variable size packets, normally one packet at a time.
o Traffic may burst at times o Intermittent traffic flows.
o Delay sensitive control messages sent between two end-points o Traffic may burst at times.
o Delay-sensitive control messages sent between two end points.
RECOMMENDED DSCP marking: RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS5 (Class o All flows in this service class are marked with CS5 (Class
Selector 5) Selector 5).
Applications or IP end points SHOULD pre-mark their packets with CS5 Applications or IP end points SHOULD pre-mark their packets with CS5
DSCP value. If the end point is not capable of setting the DSCP DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point SHOULD value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification as defined in [RFC2475]. perform Multifield (MF) Classification, as defined in [RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
RECOMMENDED Conditioning Performed at DiffServ Network Edge:
o Packet flow marking (DSCP setting) from untrusted sources (end o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in [RFC2475]. using Multifield (MF) Classification methods defined in [RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g. using single rate policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds. stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (application servers inside o Packet flows from trusted sources (application servers inside
administered network) MAY not require policing. administered network) MAY not require policing.
o Policing of packet flows across peering points SHOULD be performed o Policing of packet flows across peering points SHOULD be performed
to the Service Level Agreement (SLA). to the Service Level Agreement (SLA).
The fundamental service offered to "Signaling" traffic is enhanced The fundamental service offered to "Signaling" traffic is enhanced
best effort service with controlled rate and delay. The service best-effort service with controlled rate and delay. The service
SHOULD be engineered so that CS5 marked packet flows have sufficient SHOULD be engineered so that CS5 marked packet flows have sufficient
bandwidth in the network to provide high assurance of delivery and bandwidth in the network to provide high assurance of delivery and
low delay. Normally traffic in this service class does not respond low delay. Normally, traffic in this service class does not respond
dynamically to packet loss. As such, Active Queue Management dynamically to packet loss. As such, Active Queue Management
[RFC2309] SHOULD NOT be applied to CS5 marked packet flows. [RFC2309] SHOULD NOT be applied to CS5 marked packet flows.
4.3. Multimedia Conferencing Service Class 4.3. Multimedia Conferencing Service Class
The Multimedia Conferencing service class is RECOMMENDED for The Multimedia Conferencing service class is RECOMMENDED for
applications that require real-time service for rate adaptive applications that require real-time service for rate-adaptive
traffic. H.323/V2 and later versions of video conferencing equipment traffic. H.323/V2 and later versions of video conferencing equipment
with dynamic bandwidth adjustment is such an application. The with dynamic bandwidth adjustment are such applications. The traffic
traffic sources (applications) in this service class have the sources in this service class have the ability to dynamically change
capability to dynamically change their transmission rate based on their transmission rate based on feedback from the receiver. One
feedback received from the receiving end, within bounds of packet approach used in H.323/V2 equipment is, when the receiver detects a
loss by the receiver is sent using the applications control stream to pre-configured level of packet loss, it signals to the transmitter
the transmitter as an indication of possible congestion; the the indication of possible on-path congestion. When available, the
transmitter then selects a lower transmission rate based on pre- transmitter then selects a lower rate encoding codec. Note that
configured encoding rates (or transmission rates). Note, today many today, many H.323/V2 video conferencing solutions implement fixed-
H.323/V2 video conferencing solutions implement fixed step bandwidth step bandwidth change (usually reducing the rate), traffic resembling
change (usually reducing the rate), traffic resembling step-wise CBR. step-wise CBR.
Typical video conferencing configurations negotiate the setup of Typical video conferencing configurations negotiate the setup of
multimedia session using protocols such as H.323. When a user/ multimedia session using protocols such as H.323. When a user/end-
end-point has been authorized to start a multimedia session the point has been authorized to start a multimedia session, the
admission procedure should have verified that the newly admitted data admission procedure should have verified that the newly admitted data
rate will be within the engineered capacity of the Multimedia rate will be within the engineered capacity of the Multimedia
Conferencing service class. The bandwidth in the core network and Conferencing service class. The bandwidth in the core network and
the number of simultaneous video conferencing sessions that can be the number of simultaneous video conferencing sessions that can be
supported SHOULD be engineered to control traffic load for this supported SHOULD be engineered to control traffic load for this
service. service.
The Multimedia Conferencing service class SHOULD use the Assured The Multimedia Conferencing service class SHOULD use the Assured
Forwarding (AF) PHB defined in [RFC2597]. This service class SHOULD Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD
be configured to provide a bandwidth assurance for AF41, AF42, and be configured to provide a bandwidth assurance for AF41, AF42, and
AF43 marked packets to ensure that they get forwarded. The AF43 marked packets to ensure that they get forwarded. The
Multimedia Conferencing service class SHOULD be configured to use a Multimedia Conferencing service class SHOULD be configured to use a
Rate Queuing system such as defined in Section 1.4.1.2 of this Rate Queuing system such as that defined in Section 1.4.1.2 of this
document. document.
The following application SHOULD use the Multimedia Conferencing The following applications SHOULD use the Multimedia Conferencing
service class: service class:
o H.323/V2 and later versions of video conferencing applications o H.323/V2 and later versions of video conferencing applications
(interactive video) (interactive video).
o Video conferencing applications with rate control or traffic o Video conferencing applications with rate control or traffic
content importance marking content importance marking.
o Application server to application server non bursty data transfer o Application server-to-application server non-bursty data transfer
requiring very low delay requiring very low delay.
o IP VPN service that specifies two rates and mean network delay o IP VPN service that specifies two rates and mean network delay
that is slightly longer then network propagation delay. that is slightly longer then network propagation delay.
o Interactive, time critical and mission critical applications. o Interactive, time-critical, and mission-critical applications.
Traffic characteristics: The following are 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 size packets.
o Constant packet emission time interval o The higher the rate, the higher the density of large packets.
o Variable rate o Constant packet emission time interval.
o Variable rate.
o Source is capable of reducing its transmission rate based on o Source is capable of reducing its transmission rate based on
detection of packet loss at the receiver detection of packet loss at the receiver.
Applications or IP end points SHOULD pre-mark their packets with DSCP Applications or IP end points SHOULD pre-mark their packets with DSCP
values as shown below. If the end point is not capable of setting values as shown below. If the end point is not capable of setting
the DSCP value, then the router topologically closest to the end the DSCP value, then the router topologically closest to the end
point SHOULD perform Multifield (MF) Classification as defined in point SHOULD perform Multifield (MF) Classification, as defined in
[RFC2475] and mark all packets as AF4x. Note: In this case, the two [RFC2475] and mark all packets as AF4x. Note: In this case, the
rate three color marker will be configured to operate in Color-Blind two-rate, three-color marker will be configured to operate in Color-
mode. Blind mode.
RECOMMENDED DSCP marking when performed by router closest to source: RECOMMENDED DSCP marking when performed by router closest to source:
o AF41 = up to specified rate "A"
o AF41 = up to specified rate "A".
o AF42 = in excess of specified rate "A" but below specified rate o AF42 = in excess of specified rate "A" but below specified rate
"B" "B".
o AF43 = in excess of specified rate "B" o AF43 = in excess of specified rate "B".
o Where "A" < "B" o Where "A" < "B".
Note: One might expect "A" to approximate the sum of the mean rates Note: One might expect "A" to approximate the sum of the mean rates
and "B" to approximate the sum of the peak rates. and "B" to approximate the sum of the peak rates.
RECOMMENDED DSCP marking when performed by H.323/V2 video RECOMMENDED DSCP marking when performed by H.323/V2 video
conferencing equipment: conferencing equipment:
o AF41 = H.323 video conferencing audio stream RTP/UDP
o AF41 = H.323 video conferencing video control RTCP/TCP o AF41 = H.323 video conferencing audio stream RTP/UDP.
o AF41 = H.323 video conferencing video control RTCP/TCP.
o AF41 = H.323 video conferencing video stream up to specified rate o AF41 = H.323 video conferencing video stream up to specified rate
"A" "A".
o AF42 = H.323 video conferencing video stream in excess of o AF42 = H.323 video conferencing video stream in excess of
specified rate "A" but below specified rate "B" specified rate "A" but below specified rate "B".
o AF43 = H.323 video conferencing video stream in excess of o AF43 = H.323 video conferencing video stream in excess of
specified rate "B" specified rate "B".
o Where "A" < "B" o Where "A" < "B".
RECOMMENDED Conditioning Performed at DiffServ Network Edge: RECOMMENDED conditioning performed at DiffServ network edge:
o The two rate three color marker SHOULD be configured to provide
o The two-rate, three-color marker SHOULD be configured to provide
the behavior as defined in trTCM [RFC2698]. the behavior as defined in trTCM [RFC2698].
o If packets are marked by a trusted sources or previous trusted o If packets are marked by trusted sources or a previously trusted
DiffServ domain, and the color marking is to be preserved, then DiffServ domain and the color marking is to be preserved, then the
the two rate three color marker SHOULD be configured to operate in two-rate, three-color marker SHOULD be configured to operate in
Color-Aware mode. Color-Aware mode.
o If the packet marking is not trusted or the color marking is not o If the packet marking is not trusted or the color marking is not
to be preserved, then the two rate three color marker SHOULD be to be preserved, then the two-rate, three-color marker SHOULD be
configured to operate in Color-Blind mode. configured to operate in Color-Blind mode.
The fundamental service offered to "Multimedia Conferencing" traffic The fundamental service offered to "Multimedia Conferencing" traffic
is enhanced best effort service with controlled rate and delay. For is enhanced best-effort service with controlled rate and delay. For
video conferencing service, typically a 1% packet loss detected at video conferencing service, typically a 1% packet loss detected at
the receiver triggers an encoding rate change, dropping to next lower the receiver triggers an encoding rate change, dropping to the next
provisioned video encoding rate. As such, Active Queue Management lower provisioned video encoding rate. As such, Active Queue
[RFC2309] SHOULD be used primarily to switch video encoding rate Management [RFC2309] SHOULD be used primarily to switch the video
under congestion, changing from high rate to lower rate i.e. 1472 encoding rate under congestion, changing from high rate to lower
kbps to 768 kbps. The probability of loss of AF41 traffic MUST NOT rate, i.e., 1472 kbps to 768 kbps. The probability of loss of AF41
exceed the probability of loss of AF42 traffic, which in turn MUST traffic MUST NOT exceed the probability of loss of AF42 traffic,
NOT exceed the probability of loss of AF43 traffic. which in turn MUST NOT exceed the probability of loss of AF43
traffic.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP is specifies the queue depth above which all traffic with such a DSCP is
dropped or ECN marked. Thus, in this service class, the following dropped or ECN marked. Thus, in this service class, the following
inequality should hold in queue configurations: inequality should hold in queue configurations:
o min-threshold AF43 < max-threshold AF43 o min-threshold AF43 < max-threshold AF43
o max-threshold AF43 <= min-threshold AF42 o max-threshold AF43 <= min-threshold AF42
o min-threshold AF42 < max-threshold AF42 o min-threshold AF42 < max-threshold AF42
o max-threshold AF42 <= min-threshold AF41 o max-threshold AF42 <= min-threshold AF41
o min-threshold AF41 < max-threshold AF41 o min-threshold AF41 < max-threshold AF41
o max-threshold AF41 <= memory assigned to the queue o max-threshold AF41 <= memory assigned to the queue
Note: This configuration tends to drop AF43 traffic before AF42 and Note: This configuration tends to drop AF43 traffic before AF42 and
AF42 before AF41. Many other AQM algorithms exist and are used; they AF42 before AF41. Many other AQM algorithms exist and are used; they
should be configured to achieve a similar result. should be configured to achieve a similar result.
4.4. Real-time Interactive Service Class 4.4. Real-Time Interactive Service Class
The Real-time Interactive service class is RECOMMENDED for The Real-Time Interactive service class is RECOMMENDED for
applications that require low loss, jitter and very low delay for applications that require low loss and jitter and very low delay for
variable rate inelastic traffic sources. Interactive gaming and variable rate inelastic traffic sources. Interactive gaming and
video conferencing applications that do not have the ability to video conferencing applications that do not have the ability to
change encoding rates or mark packets with different importance change encoding rates or to mark packets with different importance
indications are such applications. The traffic sources in this indications are such applications. The traffic sources in this
traffic class does not have the ability to reduce their transmission traffic class do not have the ability to reduce their transmission
rate based on feedback received from the receiving end. rate according to feedback received from the receiving end.
Typically, applications in this service class are configured to Typically, applications in this service class are configured to
negotiate the setup of RTP/UDP control session. When a user/ negotiate the setup of RTP/UDP control session. When a user/end-
end-point has been authorized to start a new session the admission point has been authorized to start a new session, the admission
procedure should have verified that the newly admitted data rates procedure should have verified that the newly admitted data rates
will be within the engineered capacity of the Real-time Interactive will be within the engineered capacity of the Real-Time Interactive
service class. The bandwidth in the core network and the number of service class. The bandwidth in the core network and the number of
simultaneous Real-time Interactive sessions that can be supported simultaneous Real-time Interactive sessions that can be supported
SHOULD be engineered to control traffic load for this service. SHOULD be engineered to control traffic load for this service.
The Real-time Interactive service class SHOULD use the Class Selector The Real-Time Interactive service class SHOULD use the Class Selector
(CS) PHB defined in [RFC2474]. This service class SHOULD be (CS) PHB, defined in [RFC2474]. This service class SHOULD be
configured to provide a high assurance for bandwidth for CS4 marked configured to provide a high assurance for bandwidth for CS4 marked
packets to ensure that they get forwarded. The Real-time Interactive packets to ensure that they get forwarded. The Real-Time Interactive
service class SHOULD be configured to use a Rate Queuing system such service class SHOULD be configured to use a Rate Queuing system such
as defined in Section 1.4.1.2 of this document. Note, this service as that defined in Section 1.4.1.2 of this document. Note that this
class MAY be configured as a second EF PHB that uses relaxed service class MAY be configured as a second EF PHB that uses relaxed
performance parameter, a rate scheduler and CS4 DSCP value. performance parameter, a rate scheduler, and CS4 DSCP value.
The following application SHOULD use the Real-time Interactive The following applications SHOULD use the Real-Time Interactive
service class: service class:
o Interactive gaming and control
o Interactive gaming and control.
o Video conferencing applications without rate control or traffic o Video conferencing applications without rate control or traffic
content importance marking content importance marking.
o IP VPN service that specifies single rate and mean network delay o IP VPN service that specifies single rate and mean network delay
that is slightly longer then network propagation delay that is slightly longer then network propagation delay.
o Inelastic, interactive, time critical and mission critical o Inelastic, interactive, time-critical, and mission-critical
applications requiring very low delay applications requiring very low delay.
Traffic characteristics: The following are traffic characteristics:
o Variable size packets (50 to 1500 bytes in size) o Variable size packets.
o Variable rate non bursty o Variable rate, non-bursty.
o Application is sensitive to delay variation between flows and o Application is sensitive to delay variation between flows and
sessions sessions.
o Packets lost if any are usually ignored by application o Lost packets, if any, are usually ignored by application.
RECOMMENDED DSCP marking: RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS4 (Class o All flows in this service class are marked with CS4 (Class
Selector 4) Selector 4).
Applications or IP end points SHOULD pre-mark their packets with CS4 Applications or IP end points SHOULD pre-mark their packets with CS4
DSCP value. If the end point is not capable of setting the DSCP DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point SHOULD value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification as defined in [RFC2475]. perform Multifield (MF) Classification, as defined in [RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
RECOMMENDED Conditioning Performed at DiffServ Network Edge:
o Packet flow marking (DSCP setting) from untrusted sources (end o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in [RFC2475]. using Multifield (MF) Classification methods defined in [RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g. using single rate policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds. stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (application servers inside o Packet flows from trusted sources (application servers inside
administered network) MAY not require policing. administered network) MAY not require policing.
o Policing of packet flows across peering points SHOULD be performed o Policing of packet flows across peering points SHOULD be performed
to the Service Level Agreement (SLA). to the Service Level Agreement (SLA).
The fundamental service offered to "Real-time Interactive" traffic is The fundamental service offered to "Real-Time Interactive" traffic is
enhanced best effort service with controlled rate and delay. The enhanced best-effort service with controlled rate and delay. The
service SHOULD be engineered so that CS4 marked packet flows have service SHOULD be engineered so that CS4 marked packet flows have
sufficient bandwidth in the network to provide high assurance of sufficient bandwidth in the network to provide high assurance of
delivery. Normally traffic in this service class does not respond delivery. Normally, traffic in this service class does not respond
dynamically to packet loss. As such, Active Queue Management dynamically to packet loss. As such, Active Queue Management
[RFC2309] SHOULD NOT be applied to CS4 marked packet flows. [RFC2309] SHOULD NOT be applied to CS4 marked packet flows.
4.5. Multimedia Streaming Service Class 4.5. Multimedia Streaming Service Class
The Multimedia Streaming service class is RECOMMENDED for The Multimedia Streaming service class is RECOMMENDED for
applications that require near-real-time packet forwarding of applications that require near-real-time packet forwarding of
variable rate elastic traffic sources that are not as delay sensitive variable rate elastic traffic sources that are not as delay sensitive
as applications using the Multimedia Conferencing service class. as applications using the Multimedia Conferencing service class.
Such applications include streaming audio and video, some video Such applications include streaming audio and video, some video
(movies) on demand applications and Web casts. In general, the (movies) on-demand applications, and webcasts. In general, the
Multimedia Streaming service class assumes that the traffic is Multimedia Streaming service class assumes that the traffic is
buffered at the source/destination and therefore, is less sensitive buffered at the source/destination; therefore, it is less sensitive
to delay and jitter. to delay and jitter.
The Multimedia Streaming service class SHOULD use the Assured The Multimedia Streaming service class SHOULD use the Assured
Forwarding (AF) PHB defined in [RFC2597]. This service class SHOULD Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD
be configured to provide a minimum bandwidth assurance for AF31, AF32 be configured to provide a minimum bandwidth assurance for AF31,
and AF33 marked packets to ensure that they get forwarded. The AF32, and AF33 marked packets to ensure that they get forwarded. The
Multimedia Streaming service class SHOULD be configured to use Rate Multimedia Streaming service class SHOULD be configured to use Rate
Queuing system such as defined in Section 1.4.1.2 of this document. Queuing system such as that defined in Section 1.4.1.2 of this
document.
The following applications SHOULD use the Multimedia Streaming The following applications SHOULD use the Multimedia Streaming
service class: service class:
o Buffered streaming audio (unicast)
o Buffered streaming video (unicast) o Buffered streaming audio (unicast).
o Web casts o Buffered streaming video (unicast).
o Webcasts.
o IP VPN service that specifies two rates and is less sensitive to o IP VPN service that specifies two rates and is less sensitive to
delay and jitter delay and jitter.
Traffic characteristics: The following are traffic characteristics:
o Variable size packets (50 to 4196 bytes in size) o Variable size packets.
o Higher the rate, higher density of large packets o The higher the rate, the higher the density of large packets.
o Variable rate o Variable rate.
o Elastic flows o Elastic flows.
o Some bursting at start of flow from some applications o Some bursting at start of flow from some applications.
Applications or IP end points SHOULD pre-mark their packets with DSCP Applications or IP end points SHOULD pre-mark their packets with DSCP
values as shown below. If the end point is not capable of setting values as shown below. If the end point is not capable of setting
the DSCP value, then the router topologically closest to the end the DSCP value, then the router topologically closest to the end
point SHOULD perform Multifield (MF) Classification as defined in point SHOULD perform Multifield (MF) Classification, as defined in
[RFC2475] and mark all packets as AF3x. Note: In this case, the two [RFC2475], and mark all packets as AF3x. Note: In this case, the
rate three color marker will be configured to operate in Color-Blind two-rate, three-color marker will be configured to operate in Color-
mode. Blind mode.
RECOMMENDED DSCP marking: RECOMMENDED DSCP marking:
o AF31 = up to specified rate "A"
o AF31 = up to specified rate "A".
o AF32 = in excess of specified rate "A" but below specified rate o AF32 = in excess of specified rate "A" but below specified rate
"B" "B".
o AF33 = in excess of specified rate "B" o AF33 = in excess of specified rate "B".
o Where "A" < "B" o Where "A" < "B".
Note: One might expect "A" to approximate the sum of the mean rates Note: One might expect "A" to approximate the sum of the mean rates
and "B" to approximate the sum of the peak rates. and "B" to approximate the sum of the peak rates.
RECOMMENDED Conditioning Performed at DiffServ Network Edge: RECOMMENDED conditioning performed at DiffServ network edge:
o The two rate three color marker SHOULD be configured to provide
o The two-rate, three-color marker SHOULD be configured to provide
the behavior as defined in trTCM [RFC2698]. the behavior as defined in trTCM [RFC2698].
o If packets are marked by a trusted sources or previous trusted o If packets are marked by trusted sources or a previously trusted
DiffServ domain, and the color marking is to be preserved, then DiffServ domain and the color marking is to be preserved, then the
the two rate three color marker SHOULD be configured to operate in two-rate, three-color marker SHOULD be configured to operate in
Color-Aware mode. Color-Aware mode.
o If the packet marking is not trusted or the color marking is not o If the packet marking is not trusted or the color marking is not
to be preserved, then the two rate three color marker SHOULD be to be preserved, then the two-rate, three-color marker SHOULD be
configured to operate in Color-Blind mode. configured to operate in Color-Blind mode.
The fundamental service offered to "Multimedia Streaming" traffic is The fundamental service offered to "Multimedia Streaming" traffic is
enhanced best effort service with controlled rate and delay. The enhanced best-effort service with controlled rate and delay. The
service SHOULD be engineered so that AF31 marked packet flows have service SHOULD be engineered so that AF31 marked packet flows have
sufficient bandwidth in the network to provide high assurance of sufficient bandwidth in the network to provide high assurance of
delivery. Since the AF3x traffic is elastic and responds dynamically delivery. Since the AF3x traffic is elastic and responds dynamically
to packet loss, Active Queue Management [RFC2309] SHOULD be used to packet loss, Active Queue Management [RFC2309] SHOULD be used
primarily to reduce forwarding rate to the minimum assured rate at primarily to reduce forwarding rate to the minimum assured rate at
congestion points. The probability of loss of AF31 traffic MUST NOT congestion points. The probability of loss of AF31 traffic MUST NOT
exceed the probability of loss of AF32 traffic, which in turn MUST exceed the probability of loss of AF32 traffic, which in turn MUST
NOT exceed the probability of loss of AF33. NOT exceed the probability of loss of AF33.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
skipping to change at page 41, line 25 skipping to change at page 41, line 21
primarily to reduce forwarding rate to the minimum assured rate at primarily to reduce forwarding rate to the minimum assured rate at
congestion points. The probability of loss of AF31 traffic MUST NOT congestion points. The probability of loss of AF31 traffic MUST NOT
exceed the probability of loss of AF32 traffic, which in turn MUST exceed the probability of loss of AF32 traffic, which in turn MUST
NOT exceed the probability of loss of AF33. NOT exceed the probability of loss of AF33.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP is specifies the queue depth above which all traffic with such a DSCP is
dropped or ECN marked. Thus, in this service class, the following dropped or ECN marked. Thus, in this service class, the following
inequality should hold in queue configurations: inequality should hold in queue configurations:
o min-threshold AF33 < max-threshold AF33 o min-threshold AF33 < max-threshold AF33
o max-threshold AF33 <= min-threshold AF32 o max-threshold AF33 <= min-threshold AF32
o min-threshold AF32 < max-threshold AF32 o min-threshold AF32 < max-threshold AF32
o max-threshold AF32 <= min-threshold AF31 o max-threshold AF32 <= min-threshold AF31
o min-threshold AF31 < max-threshold AF31 o min-threshold AF31 < max-threshold AF31
o max-threshold AF31 <= memory assigned to the queue o max-threshold AF31 <= memory assigned to the queue
Note: This configuration tends to drop AF33 traffic before AF32 and Note: This configuration tends to drop AF33 traffic before AF32 and
AF32 before AF31. Many other AQM algorithms exist and are used; they AF32 before AF31. Note: Many other AQM algorithms exist and are
should be configured to achieve a similar result. used; they should be configured to achieve a similar result.
4.6. Broadcast Video Service Class 4.6. Broadcast Video Service Class
The Broadcast Video service class is RECOMMENDED for applications The Broadcast Video service class is RECOMMENDED for applications
that require near-real-time packet forwarding with very low packet that require near-real-time packet forwarding with very low packet
loss of constant and variable rate inelastic traffic sources that are loss of constant rate and variable rate inelastic traffic sources
not as delay sensitive as applications using the Real-time that are not as delay sensitive as applications using the Real-Time
Interactive service class. Such applications include broadcast TV, Interactive service class. Such applications include broadcast TV,
streaming of live audio and video events, some video on demand streaming of live audio and video events, some video-on-demand
applications and video surveillance. In general, the Broadcast Video applications, and video surveillance. In general, the Broadcast
service class assumes that the destination end point has a dejitter Video service class assumes that the destination end point has a
buffer, for video application usually a 2 - 8 video frames buffer (66 dejitter buffer, for video application usually a 2 - 8 video-frame
to several hundred of milliseconds) therefore, is less sensitive to buffer (66 to several hundred of milliseconds), and therefore that it
delay and jitter. is less sensitive to delay and jitter.
The Broadcast Video service class SHOULD use the Class Selector (CS) The Broadcast Video service class SHOULD use the Class Selector (CS)
PHB defined in [RFC2474]. This service class SHOULD be configured to PHB, defined in [RFC2474]. This service class SHOULD be configured
provide high assurance for bandwidth for CS3 marked packets to ensure to provide high assurance for bandwidth for CS3 marked packets to
that they get forwarded. The Broadcast Video service class SHOULD be ensure that they get forwarded. The Broadcast Video service class
configured to use Rate Queuing system such as defined in SHOULD be configured to use Rate Queuing system such as that defined
Section 1.4.1.2 of this document. Note, this service class MAY be in Section 1.4.1.2 of this document. Note that this service class
configured as a third EF PHB that uses relaxed performance parameter, MAY be configured as a third EF PHB that uses relaxed performance
a rate scheduler and CS3 DSCP value. parameter, a rate scheduler, and CS3 DSCP value.
The following applications SHOULD use the Broadcast Video service The following applications SHOULD use the Broadcast Video service
class: class:
o Video surveillance and security (unicast)
o TV broadcast including HDTV (multicast)
o Video on demand (unicast) with control (virtual DVD)
o Streaming of live audio events (both unicast and multicast)
o Streaming of live video events (both unicast and multicast)
Traffic characteristics: o Video surveillance and security (unicast).
o Variable size packets (50 to 4196 bytes in size) o TV broadcast including HDTV (multicast).
o Higher the rate, higher density of large packets o Video on demand (unicast) with control (virtual DVD).
o Mixture of variable and constant rate flows o Streaming of live audio events (both unicast and multicast).
o Fixed packet emission time intervals o Streaming of live video events (both unicast and multicast).
o Inelastic flows
The following are traffic characteristics:
o Variable size packets.
o The higher the rate, the higher the density of large packets.
o Mixture of variable rate and constant rate flows.
o Fixed packet emission time intervals.
o Inelastic flows.
RECOMMENDED DSCP marking: RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS3 (Class o All flows in this service class are marked with CS3 (Class
Selector 3) Selector 3).
o In some cases, like for security and video surveillance o In some cases, such as those for security and video surveillance
applications, it may be desirable to use a different DSCP marking. applications, it may be desirable to use a different DSCP marking.
If so, then locally user definable (EXP/LU) codepoint(s) in the If so, then locally user definable (EXP/LU) codepoints in the
range '011xx1' MAY be used to provide unique traffic range '011xx1' MAY be used to provide unique traffic
identification. The locally user definable (EXP/LU) codepoint(s) identification. The locally user definable (EXP/LU) codepoint(s)
MAY be associated with the PHB that is used for CS3 traffic. MAY be associated with the PHB that is used for CS3 traffic.
Further, depending on the network scenario, additional network Furthermore, depending on the network scenario, additional network
edge conditioning policy MAY be need for the EXP/LU codepoint(s) edge conditioning policy MAY be needed for the EXP/LU codepoint(s)
used. used.
Applications or IP end points SHOULD pre-mark their packets with CS3 Applications or IP end points SHOULD pre-mark their packets with CS3
DSCP value. If the end point is not capable of setting the DSCP DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point SHOULD value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification as defined in [RFC2475]. perform Multifield (MF) Classification, as defined in [RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
RECOMMENDED Conditioning Performed at DiffServ Network Edge:
o Packet flow marking (DSCP setting) from untrusted sources (end o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in [RFC2475]. using Multifield (MF) Classification methods defined in [RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g. using single rate policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds. stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (application servers inside o Packet flows from trusted sources (application servers inside
administered network) MAY not require policing. administered network) MAY not require policing.
o Policing of packet flows across peering points SHOULD be performed o Policing of packet flows across peering points SHOULD be performed
to the Service Level Agreement (SLA). to the Service Level Agreement (SLA).
The fundamental service offered to "Broadcast Video" traffic is The fundamental service offered to "Broadcast Video" traffic is
enhanced best effort service with controlled rate and delay. The enhanced best-effort service with controlled rate and delay. The
service SHOULD be engineered so that CS3 marked packet flows have service SHOULD be engineered so that CS3 marked packet flows have
sufficient bandwidth in the network to provide high assurance of sufficient bandwidth in the network to provide high assurance of
delivery. Normally traffic in this service class does not respond delivery. Normally, traffic in this service class does not respond
dynamically to packet loss. As such, Active Queue Management dynamically to packet loss. As such, Active Queue Management
[RFC2309] SHOULD NOT be applied to CS3 marked packet flows. [RFC2309] SHOULD NOT be applied to CS3 marked packet flows.
4.7. Low Latency Data Service Class 4.7. Low-Latency Data Service Class
The Low Latency Data service class is RECOMMENDED for elastic and The Low-Latency Data service class is RECOMMENDED for elastic and
responsive typically client/server based applications. Applications responsive typically client-/server-based applications. Applications
forwarded by this service class are those requiring a relatively fast forwarded by this service class are those that require a relatively
response and typically have asymmetrical bandwidth need, i.e. the fast response and typically have asymmetrical bandwidth need, i.e.,
client typically sends a short message to the server and the server the client typically sends a short message to the server and the
responds with a much larger data flow back to the client. The most server responds with a much larger data flow back to the client. The
common example of this is when a user clicks a hyperlink (~few dozen most common example of this is when a user clicks a hyperlink (~ few
bytes) on a web page resulting in a new web page to be loaded (Kbytes dozen bytes) on a web page, resulting in a new web page to be loaded
of data). This service class is configured to provide good response (Kbytes of data). This service class is configured to provide good
for TCP [RFC1633] short lived flows that require real-time packet response for TCP [RFC1633] short-lived flows that require real-time
forwarding of variable rate traffic sources. packet forwarding of variable rate traffic sources.
The Low Latency Data service class SHOULD use the Assured Forwarding The Low-Latency Data service class SHOULD use the Assured Forwarding
(AF) PHB defined in [RFC2597]. This service class SHOULD be (AF) PHB, defined in [RFC2597]. This service class SHOULD be
configured to provide a minimum bandwidth assurance for AF21, AF22 configured to provide a minimum bandwidth assurance for AF21, AF22,
and AF23 marked packets to ensure that they get forwarded. The Low and AF23 marked packets to ensure that they get forwarded. The Low-
Latency Data service class SHOULD be configured to use a Rate Queuing Latency Data service class SHOULD be configured to use a Rate Queuing
system such as defined in Section 1.4.1.2 of this document. system such as that defined in Section 1.4.1.2 of this document.
The following applications SHOULD use the Low Latency Data service The following applications SHOULD use the Low-Latency Data service
class: 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 Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN)
o VPN service that supports CIR (Committed Information Rate) with up
to two burst sizes
Traffic characteristics: o Client/server applications.
o Systems Network Architecture (SNA) terminal to host transactions
(SNA over IP using Data Link Switching (DLSw)).
o Web-based transactions (E-commerce).
o Credit card transactions.
o Financial wire transfers.
o Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN).
o VPN service that supports Committed Information Rate (CIR) with up
to two burst sizes.
o Variable size packets (50 to 1500 bytes in size) The following are traffic characteristics:
o Variable packet emission rate
o With packet bursts of TCP window size o Variable size packets.
o Short traffic bursts o Variable packet emission rate.
o With packet bursts of TCP window size.
o Short traffic bursts.
o Source capable of reducing its transmission rate based on o Source capable of reducing its transmission rate based on
detection of packet loss at the receiver or through explicit detection of packet loss at the receiver or through explicit
congestion notification congestion notification.
Applications or IP end points SHOULD pre-mark their packets with DSCP Applications or IP end points SHOULD pre-mark their packets with DSCP
values as shown below. If the end point is not capable of setting values as shown below. If the end point is not capable of setting
the DSCP value, then the router topologically closest to the end the DSCP value, then the router topologically closest to the end
point SHOULD perform Multifield (MF) Classification as defined in point SHOULD perform Multifield (MF) Classification, as defined in
[RFC2475] and mark all packets as AF2x. Note: In this case, the [RFC2475] and mark all packets as AF2x. Note: In this case, the
single rate three color marker will be configured to operate in single-rate, three-color marker will be configured to operate in
Color-Blind mode. Color-Blind mode.
RECOMMENDED DSCP marking: RECOMMENDED DSCP marking:
o AF21 = flow stream with packet burst size up to "A" bytes
o AF21 = flow stream with packet burst size up to "A" bytes.
o AF22 = flow stream with packet burst size in excess of "A" but o AF22 = flow stream with packet burst size in excess of "A" but
below "B" bytes below "B" bytes.
o AF23 = flow stream with packet burst size in excess of "B" bytes o AF23 = flow stream with packet burst size in excess of "B" bytes.
o Where "A" < "B" o Where "A" < "B".
RECOMMENDED Conditioning Performed at DiffServ Network Edge: RECOMMENDED conditioning performed at DiffServ network edge:
o The single rate three color marker SHOULD be configured to provide
the behavior as defined in srTCM [RFC2697]. o The single-rate, three-color marker SHOULD be configured to
o If packets are marked by a trusted sources or previous trusted provide the behavior as defined in srTCM [RFC2697].
DiffServ domain, and the color marking is to be preserved, then o If packets are marked by trusted sources or a previously trusted
the single rate three color marker SHOULD be configured to operate DiffServ domain and the color marking is to be preserved, then the
in Color-Aware mode. single-rate, three-color marker SHOULD be configured to operate in
Color-Aware mode.
o If the packet marking is not trusted or the color marking is not o If the packet marking is not trusted or the color marking is not
to be preserved, then the single rate three color marker SHOULD be to be preserved, then the single-rate, three-color marker SHOULD
configured to operate in Color-Blind mode. be configured to operate in Color-Blind mode.
The fundamental service offered to "Low Latency Data" traffic is The fundamental service offered to "Low-Latency Data" traffic is
enhanced best effort service with controlled rate and delay. The enhanced best-effort service with controlled rate and delay. The
service SHOULD be engineered so that AF21 marked packet flows have service SHOULD be engineered so that AF21 marked packet flows have
sufficient bandwidth in the network to provide high assurance of sufficient bandwidth in the network to provide high assurance of
delivery. Since the AF2x traffic is elastic and responds dynamically delivery. Since the AF2x traffic is elastic and responds dynamically
to packet loss, Active Queue Management [RFC2309] SHOULD be used to packet loss, Active Queue Management [RFC2309] SHOULD be used
primarily to control TCP flow rates at congestion points by dropping primarily to control TCP flow rates at congestion points by dropping
packet from TCP flows that have large burst size. The probability of packets from TCP flows that have large burst size. The probability
loss of AF21 traffic MUST NOT exceed the probability of loss of AF22 of loss of AF21 traffic MUST NOT exceed the probability of loss of
traffic, which in turn MUST NOT exceed the probability of loss of AF22 traffic, which in turn MUST NOT exceed the probability of loss
AF23. Explicit Congestion Notification (ECN) [RFC3168] MAY also be of AF23. Explicit Congestion Notification (ECN) [RFC3168] MAY also
used with Active Queue Management. be used with Active Queue Management.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP is specifies the queue depth above which all traffic with such a DSCP is
dropped or ECN marked. Thus, in this service class, the following dropped or ECN marked. Thus, in this service class, the following
inequality should hold in queue configurations: inequality should hold in queue configurations:
o min-threshold AF23 < max-threshold AF23 o min-threshold AF23 < max-threshold AF23
o max-threshold AF23 <= min-threshold AF22 o max-threshold AF23 <= min-threshold AF22
o min-threshold AF22 < max-threshold AF22 o min-threshold AF22 < max-threshold AF22
o max-threshold AF22 <= min-threshold AF21 o max-threshold AF22 <= min-threshold AF21
o min-threshold AF21 < max-threshold AF21 o min-threshold AF21 < max-threshold AF21
o max-threshold AF21 <= memory assigned to the queue o max-threshold AF21 <= memory assigned to the queue
Note: This configuration tends to drop AF23 traffic before AF22 and Note: This configuration tends to drop AF23 traffic before AF22 and
AF22 before AF21. Many other AQM algorithms exist and are used; they AF22 before AF21. Many other AQM algorithms exist and are used; they
should be configured to achieve a similar result. should be configured to achieve a similar result.
4.8. High Throughput Data Service Class 4.8. High-Throughput Data Service Class
The High Throughput Data service class is RECOMMENDED for elastic The High-Throughput Data service class is RECOMMENDED for elastic
applications that require timely packet forwarding of variable rate applications that require timely packet forwarding of variable rate
traffic sources and more specifically is configured to provide good traffic sources and, more specifically, is configured to provide good
throughput for TCP longer lived flows. TCP [RFC1633] or a transport throughput for TCP longer-lived flows. TCP [RFC1633] or a transport
with a consistent Congestion Avoidance Procedure [RFC2581] [RFC2582] with a consistent Congestion Avoidance Procedure [RFC2581] [RFC3782]
normally will drive as high a data rate as it can obtain over a long 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 period of time. The FTP protocol is a common example, although one
cannot definitively say that all FTP transfers are moving data in cannot definitively say that all FTP transfers are moving data in
bulk. bulk.
The High Throughput Data service class SHOULD use the Assured The High-Throughput Data service class SHOULD use the Assured
Forwarding (AF) PHB defined in [RFC2597]. This service class SHOULD Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD
be configured to provide a minimum bandwidth assurance for AF11, AF12 be configured to provide a minimum bandwidth assurance for AF11,
and AF13 marked packets to ensure that they are forwarded in timely AF12, and AF13 marked packets to ensure that they are forwarded in a
manner. The High Throughput Data service class SHOULD be configured timely manner. The High-Throughput Data service class SHOULD be
to use a Rate Queuing system such as defined in Section 1.4.1.2 of configured to use a Rate Queuing system such as that defined in
this document. Section 1.4.1.2 of this document.
The following applications SHOULD use the High Throughput Data The following applications SHOULD use the High-Throughput Data
service class: service class:
o Store and forward applications
o File transfer applications o Store and forward applications.
o Email o File transfer applications.
o Email.
o VPN service that supports two rates (committed information rate o VPN service that supports two rates (committed information rate
and excess or peak information rate) and excess or peak information rate).
Traffic characteristics: The following are traffic characteristics:
o Variable size packets (50 to 1500 bytes in size)
o Variable packet emission rate o Variable size packets.
o Variable rate o Variable packet emission rate.
o With packet bursts of TCP window size o Variable rate.
o With packet bursts of TCP window size.
o Source capable of reducing its transmission rate based on o Source capable of reducing its transmission rate based on
detection of packet loss at the receiver or through explicit detection of packet loss at the receiver or through explicit
congestion notification congestion notification.
Applications or IP end points SHOULD pre-mark their packets with DSCP Applications or IP end points SHOULD pre-mark their packets with DSCP
values as shown below. If the end point is not capable of setting values as shown below. If the end point is not capable of setting
the DSCP value, then the router topologically closest to the end the DSCP value, then the router topologically closest to the end
point SHOULD perform Multifield (MF) Classification as defined in point SHOULD perform Multifield (MF) Classification, as defined in
[RFC2475] and mark all packets as AF1x. Note: In this case, the two [RFC2475], and mark all packets as AF1x. Note: In this case, the
rate three color marker will be configured to operate in Color-Blind two-rate, three-color marker will be configured to operate in Color-
mode. Blind mode.
RECOMMENDED DSCP marking: RECOMMENDED DSCP marking:
o AF11 = up to specified rate "A"
o AF11 = up to specified rate "A".
o AF12 = in excess of specified rate "A" but below specified rate o AF12 = in excess of specified rate "A" but below specified rate
"B" "B".
o AF13 = in excess of specified rate "B" o AF13 = in excess of specified rate "B".
o Where "A" < "B" o Where "A" < "B".
RECOMMENDED Conditioning Performed at DiffServ Network Edge: RECOMMENDED conditioning performed at DiffServ network edge:
o The two rate three color marker SHOULD be configured to provide
o The two-rate, three-color marker SHOULD be configured to provide
the behavior as defined in trTCM [RFC2698]. the behavior as defined in trTCM [RFC2698].
o If packets are marked by a trusted sources or previous trusted o If packets are marked by trusted sources or a previously trusted
DiffServ domain, and the color marking is to be preserved, then DiffServ domain and the color marking is to be preserved, then the
the two rate three color marker SHOULD be configured to operate in two-rate, three-color marker SHOULD be configured to operate in
Color-Aware mode. Color-Aware mode.
o If the packet marking is not trusted or the color marking is not o If the packet marking is not trusted or the color marking is not
to be preserved, then the two rate three color marker SHOULD be to be preserved, then the two-rate, three-color marker SHOULD be
configured to operate in Color-Blind mode. configured to operate in Color-Blind mode.
The fundamental service offered to "High Throughput Data" traffic is The fundamental service offered to "High-Throughput Data" traffic is
enhanced best effort service with a specified minimum rate. The enhanced best-effort service with a specified minimum rate. The
service SHOULD be engineered so that AF11 marked packet flows have service SHOULD be engineered so that AF11 marked packet flows have
sufficient bandwidth in the network to provide assured delivery. It sufficient bandwidth in the network to provide assured delivery. It
can be assumed that this class will consume any available bandwidth, can be assumed that this class will consume any available bandwidth
and packets traversing congested links may experience higher queuing and that packets traversing congested links may experience higher
delays and/or packet loss. Since the AF1x traffic is elastic and queuing delays or packet loss. Since the AF1x traffic is elastic and
responds dynamically to packet loss, Active Queue Management responds dynamically to packet loss, Active Queue Management
[RFC2309] SHOULD be used primarily to control TCP flow rates at [RFC2309] SHOULD be used primarily to control TCP flow rates at
congestion points by dropping packet from TCP flows that have higher congestion points by dropping packets from TCP flows that have higher
rates first. The probability of loss of AF11 traffic MUST NOT exceed rates first. The probability of loss of AF11 traffic MUST NOT exceed
the probability of loss of AF12 traffic, which in turn MUST NOT the probability of loss of AF12 traffic, which in turn MUST NOT
exceed the probability of loss of AF13. In such a case, if one exceed the probability of loss of AF13. In such a case, if one
network customer is driving significant excess and another seeks to network customer is driving significant excess and another seeks to
use the link, any losses will be experienced by the high rate user, use the link, any losses will be experienced by the high-rate user,
causing him to reduce his rate. Explicit Congestion Notification causing him to reduce his rate. Explicit Congestion Notification
(ECN) [RFC3168] MAY also be used with Active Queue Management. (ECN) [RFC3168] MAY also be used with Active Queue Management.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP is specifies the queue depth above which all traffic with such a DSCP is
dropped or ECN marked. Thus, in this service class, the following dropped or ECN marked. Thus, in this service class, the following
inequality should hold in queue configurations: inequality should hold in queue configurations:
o min-threshold AF13 < max-threshold AF13 o min-threshold AF13 < max-threshold AF13
o max-threshold AF13 <= min-threshold AF12 o max-threshold AF13 <= min-threshold AF12
o min-threshold AF12 < max-threshold AF12 o min-threshold AF12 < max-threshold AF12
o max-threshold AF12 <= min-threshold AF11 o max-threshold AF12 <= min-threshold AF11
o min-threshold AF11 < max-threshold AF11 o min-threshold AF11 < max-threshold AF11
o max-threshold AF11 <= memory assigned to the queue o max-threshold AF11 <= memory assigned to the queue
Note: This configuration tends to drop AF13 traffic before AF12 and Note: This configuration tends to drop AF13 traffic before AF12 and
AF12 before AF11. Many other AQM algorithms exist and are used; they AF12 before AF11. Many other AQM algorithms exist and are used; they
should be configured to achieve a similar result. should be configured to achieve a similar result.
4.9. Standard Service Class 4.9. Standard Service Class
The Standard service class is RECOMMENDED for traffic that has not The Standard service class is RECOMMENDED for traffic that has not
been classified into one of the other supported forwarding service been classified into one of the other supported forwarding service
classes in the DiffServ network domain. This service class provides classes in the DiffServ network domain. This service class provides
the Internet's "best effort" forwarding behavior. This service class the Internet's "best-effort" forwarding behavior. This service class
typically has minimum bandwidth guarantee. typically has minimum bandwidth guarantee.
The Standard service class MUST use the Default Forwarding (DF) PHB The Standard service class MUST use the Default Forwarding (DF) PHB,
defined in [RFC2474] and SHOULD be configured to receive at least a defined in [RFC2474], and SHOULD be configured to receive at least a
small percentage of forwarding resources as a guaranteed minimum. small percentage of forwarding resources as a guaranteed minimum.
This service class SHOULD be configured to use a Rate Queuing system This service class SHOULD be configured to use a Rate Queuing system
such as defined in Section 1.4.1.2 of this document. such as that defined in Section 1.4.1.2 of this document.
The following application SHOULD use the Standard service class: The following applications SHOULD use the Standard service class:
o Network services, DNS, DHCP, BootP
o Network services, DNS, DHCP, BootP.
o Any undifferentiated application/packet flow transported through o Any undifferentiated application/packet flow transported through
the DiffServ enabled network the DiffServ enabled network.
Traffic Characteristics: The following is a traffic characteristic:
o Non deterministic, mixture of everything
RECOMMENDED DSCP marking is DF (Default Forwarding) '000000' o Non-deterministic, mixture of everything.
The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'.
Network Edge Conditioning: Network Edge Conditioning:
There is no requirement that conditioning of packet flows be There is no requirement that conditioning of packet flows be
performed for this service class. performed for this service class.
The fundamental service offered to the Standard service class is best The fundamental service offered to the Standard service class is
effort service with active queue management to limit over-all delay. best-effort service with active queue management to limit overall
Typical configurations SHOULD use random packet dropping to implement delay. Typical configurations SHOULD use random packet dropping to
Active Queue Management [RFC2309] or Explicit Congestion Notification implement Active Queue Management [RFC2309] or Explicit Congestion
[RFC3168], and MAY impose a minimum or maximum rate on the queue. Notification [RFC3168], and MAY impose a minimum or maximum rate on
the queue.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth, and the max-threshold specifies the specifies a target queue depth, and the max-threshold specifies the
queue depth above which all traffic is dropped or ECN marked. Thus, queue depth above which all traffic is dropped or ECN marked. Thus,
in this service class, the following inequality should hold in queue in this service class, the following inequality should hold in queue
configurations: configurations:
o min-threshold DF < max-threshold DF o min-threshold DF < max-threshold DF
o max-threshold DF <= memory assigned to the queue o max-threshold DF <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result. configured to achieve a similar result.
4.10. Low Priority Data 4.10. Low-Priority Data
The Low Priority Data service class serves applications that run over The Low-Priority Data service class serves applications that run over
TCP [RFC0793] or a transport with consistent congestion avoidance TCP [RFC0793] or a transport with consistent congestion avoidance
procedure [RFC2581] [RFC2582], and which the user is willing to procedures [RFC2581] [RFC3782] and that the user is willing to accept
accept service without guarantees. This service class is specified service without guarantees. This service class is specified in
in [QBSS] and [RFC3662]. [RFC3662] and [QBSS].
The following applications MAY use the Low Priority Data service The following applications MAY use the Low-Priority Data service
class: class:
o Any TCP based application/packet flow transported through the
o Any TCP based-application/packet flow transported through the
DiffServ enabled network that does not require any bandwidth DiffServ enabled network that does not require any bandwidth
assurances assurances.
Traffic Characteristics: The following is a traffic characteristic:
o Non real-time and elastic
o Non-real-time and elastic.
Network Edge Conditioning: Network Edge Conditioning:
There is no requirement that conditioning of packet flows be There is no requirement that conditioning of packet flows be
performed for this service class performed for this service class.
RECOMMENDED DSCP marking is CS1 (Class Selector 1) The RECOMMENDED DSCP marking is CS1 (Class Selector 1).
The fundamental service offered to the Low Priority Data service The fundamental service offered to the Low-Priority Data service
class is best effort service with zero bandwidth assurance. By class is best-effort service with zero bandwidth assurance. By
placing it into a separate queue or class, it may be treated in a placing it into a separate queue or class, it may be treated in a
manner consistent with a specific service level agreement. manner consistent with a specific Service Level Agreement.
Typical configurations SHOULD use Explicit Congestion Notification Typical configurations SHOULD use Explicit Congestion Notification
[RFC3168] or random loss to implement Active Queue Management [RFC3168] or random loss to implement Active Queue Management
[RFC2309]. [RFC2309].
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth, and the max-threshold specifies the specifies a target queue depth, and the max-threshold specifies the
queue depth above which all traffic is dropped or ECN marked. Thus, queue depth above which all traffic is dropped or ECN marked. Thus,
in this service class, the following inequality should hold in queue in this service class, the following inequality should hold in queue
configurations: configurations:
skipping to change at page 49, line 7 skipping to change at page 49, line 29
[RFC2309]. [RFC2309].
If RED [RFC2309] is used as an AQM algorithm, the min-threshold If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth, and the max-threshold specifies the specifies a target queue depth, and the max-threshold specifies the
queue depth above which all traffic is dropped or ECN marked. Thus, queue depth above which all traffic is dropped or ECN marked. Thus,
in this service class, the following inequality should hold in queue in this service class, the following inequality should hold in queue
configurations: configurations:
o min-threshold CS1 < max-threshold CS1 o min-threshold CS1 < max-threshold CS1
o max-threshold CS1 <= memory assigned to the queue o max-threshold CS1 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result. configured to achieve a similar result.
5. Additional Information on Service Class Usage 5. Additional Information on Service Class Usage
In this section we provide additional information on how some In this section, we provide additional information on how some
specific applications should be configured to use the defined service specific applications should be configured to use the defined service
classes. classes.
5.1. Mapping for Signaling 5.1. Mapping for Signaling
There are many different signaling protocols, ways that signaling is There are many different signaling protocols, ways that signaling is
used and performance requirements from applications that are used and performance requirements from applications that are
controlled by these protocols. We believe that different signaling controlled by these protocols. We believe that different signaling
protocols should use the service class that best meet the objectives protocols should use the service class that best meets the objectives
of application or service they control. The following mapping is of application or service they control. The following mapping is
recommended: recommended:
o Peer-to-peer signaling using SIP/H.323 are marked with CS5 DSCP
o Peer-to-peer signaling using SIP/H.323 is marked with CS5 DSCP
(use Signaling service class). (use Signaling service class).
o Client-server signaling as used in many implementation for IP o Client-server signaling as used in many implementation for IP
telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN or telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN, or
proprietary protocols are marked with CS5 DSCP (use Signaling proprietary protocols is marked with CS5 DSCP (use Signaling
service class). service class).
o Signaling between call servers or soft-switches in carrier's o Signaling between call servers or soft-switches in carrier's
network using SIP, SIP-T, IP encapsulated ISUP, are marked with network using SIP, SIP-T, or IP encapsulated ISUP is marked with
CS5 DSCP (use Signaling service class). CS5 DSCP (use Signaling service class).
o RSVP signaling, depends on the application. If RSVP signaling is o RSVP signaling depends on the application. If RSVP signaling is
"on-path" as used in IntServ, then it needs to be forwarded from "on-path" as used in IntServ, then it needs to be forwarded from
the same queue (service class) and marked with the same DSCP value the same queue (service class) and marked with the same DSCP value
as application data that it is controlling. This may also apply as application data that it is controlling. This may also apply
to the "on-path" NSIS signaling protocol. to the "on-path" Next Steps in Signaling (NSIS) protocol.
o IGMP (Internet Group Management Protocol). If used for multicast o If IGMP is used for multicast session control such as channel
session control such as channel changing in IPTV systems, then changing in IPTV systems, then IGMP packets should be marked with
IGMP packets should be marked with CS5 DSCP (use Signaling service CS5 DSCP (use Signaling service class). When IGMP is used only
class). When IGMP is used only for the normal multicast routing for the normal multicast routing purpose, it should be marked with
purpose, it should be marked with CS6 DSCP (use Network Control CS6 DSCP (use Network Control service class).
service class).
5.2. Mapping for NTP 5.2. Mapping for NTP
From tests that were performed, indications are that precise time From tests that were performed, indications are that precise time
distribution requires a very low packet delay variation (jitter) distribution requires a very low packet delay variation (jitter)
transport. Therefore we suggest the following guidelines for NTP transport. Therefore, we suggest that the following guidelines for
(Network Time Protocol) be used: Network Time Protocol (NTP) be used:
o When NTP is used for providing high accuracy timing within o When NTP is used for providing high-accuracy timing within an
administrator's (carrier's) network or to end users/clients, the administrator's (carrier's) network or to end users/clients, the
Telephony service class should be used and NTP packets be marked Telephony service class should be used, and NTP packets should be
with EF DSCP value. marked with EF DSCP value.
o For applications that require "wall clock" timing accuracy, the o For applications that require "wall clock" timing accuracy, the
Standard service class should be used and packets should be marked Standard service class should be used, and packets should be
with DF DSCP. marked with DF DSCP.
5.3. VPN Service Mapping 5.3. VPN Service Mapping
Differentiated Services and Tunnels [RFC2983] considers the "Differentiated Services and Tunnels" [RFC2983] considers the
interaction of DiffServ architecture with IP tunnels of various interaction of DiffServ architecture with IP tunnels of various
forms. Further to guidelines provided in RFC 2983, below are forms. Further to guidelines provided in RFC 2983, below are
additional guidelines for mapping service classes that are supported additional guidelines for mapping service classes that are supported
in one part of the network into a VPN connection. This discussion is in one part of the network into a VPN connection. This discussion is
limit only to VPNs that use DiffServ technology for traffic limited to VPNs that use DiffServ technology for traffic
differentiation. differentiation.
o The DSCP value(s) that is/are used to represent a PHB or a PHB o The DSCP value(s) that is/are used to represent a PHB or a PHB
group should be the same for the networks at both ends of the VPN group should be the same for the networks at both ends of the VPN
tunnel, unless remarking of DSCP is done as ingress/egress tunnel, unless remarking of DSCP is done as ingress/egress
processing function of the tunnel. DSCP marking needs to be processing function of the tunnel. DSCP marking needs to be
preserve end-to-end. preserved end to end.
o The VPN may be configured to support one or more service
class(es). It is left up to the administrators of the two o The VPN may be configured to support one or more service classes.
networks to agree on the level of traffic differentiation that It is left up to the administrators of the two networks to agree
will be provide in the network that supports VPN service. Service on the level of traffic differentiation that will be provided in
classes are then mapped into the supported VPN traffic forwarding the network that supports VPN service. Service classes are then
behaviors that meet the traffic characteristics and performance mapped into the supported VPN traffic forwarding behaviors that
requirements of the encapsulated service classes. meet the traffic characteristics and performance requirements of
the encapsulated service classes.
o The traffic treatment in the network that is providing the VPN o The traffic treatment in the network that is providing the VPN
service needs to be such that the encapsulated service class or service needs to be such that the encapsulated service class or
classes receive comparable behavior and performance in terms of classes receive comparable behavior and performance in terms of
delay, jitter, packet loss and they are within the limits of the delay, jitter, and packet loss and that they are within the limits
service specified. of the service specified.
o The DSCP value in the external header of the packet forwarded o The DSCP value in the external header of the packet forwarded
through the network providing the VPN service may be different through the network providing the VPN service may be different
than the DSCP value that is used end-to-end for service from the DSCP value that is used end to end for service
differentiation in end network. differentiation in the end network.
o The guidelines for aggregation of two or more service classes into o The guidelines for aggregation of two or more service classes into
a single traffic forwarding treatment in the network that is a single traffic forwarding treatment in the network that is
providing the VPN service is for further study. providing the VPN service is for further study.
6. Security Considerations 6. Security Considerations
This document discusses policy, and describes a common policy This document discusses policy and describes a common policy
configuration, for the use of a Differentiated Services Code Point by configuration, for the use of a Differentiated Services Code Point by
transports and applications. If implemented as described, it should transports and applications. If implemented as described, it should
require the network to do nothing that the network has not already require that the network do nothing that the network has not already
allowed. If that is the case, no new security issues should arise allowed. If that is the case, no new security issues should arise
from the use of such a policy. from the use of such a policy.
It is possible for the policy to be applied incorrectly, or for a 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 wrong policy to be applied in the network for the defined service
class. In that case, a policy issue exists that the network SHOULD class. In that case, a policy issue exists that the network SHOULD
detect, assess, and deal with. This is a known security issue in any detect, assess, and deal with. This is a known security issue in any
network dependent on policy directed behavior. network dependent on policy-directed behavior.
A well known flaw appears when bandwidth is reserved or enabled for a A well-known flaw appears when bandwidth is reserved or enabled for a
service (for example, voice transport) and another service or an service (for example, voice transport) and another service or an
attacking traffic stream uses it. This possibility is inherent in attacking traffic stream uses it. This possibility is inherent in
DiffServ technology, which depends on appropriate packet markings. DiffServ technology, which depends on appropriate packet markings.
When bandwidth reservation or a priority queuing system is used in a When bandwidth reservation or a priority queuing system is used in a
vulnerable network, the use of authentication and flow admission is vulnerable network, the use of authentication and flow admission is
recommended. To the author's knowledge, there is no known technical recommended. To the author's knowledge, there is no known technical
way to respond to an unauthenticated data stream using service that 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. it is not intended to use, and such is the nature of the Internet.
The use of a service class by a user is not an issue when the SLA The use of a service class by a user is not an issue when the SLA
between the user and the network permits him to use it, or to use it between the user and the network permits him to use it, or to use it
up to a stated rate. In such cases, simple policing is used in the up to a stated rate. In such cases, simple policing is used in the
Differentiated Services Architecture. Some service classes, such as Differentiated Services Architecture. Some service classes, such as
Network Control, are not permitted to be used by users at all; such Network Control, are not permitted to be used by users at all; such
traffic should be dropped or remarked by ingress filters. Where traffic should be dropped or remarked by ingress filters. Where
service classes are available under the SLA only to an authenticated service classes are available under the SLA only to an authenticated
user rather than to the entire population of users, authentication user rather than to the entire population of users, authentication
and authorization services are required, such as those surveyed in and authorization services are required, such as those surveyed in
[I-D.iab-auth-mech]. [AUTHMECH].
7. Summary of Changes from Previous Version
NOTE TO RFC EDITOR: Please remove this section during the publication
process.
Changes made to draft-ietf-tsvwg-diffserv-service-classes-01 from
review by David Black, Kathie Nichols, and Charlie Liu:
1. In Abstract section on page 1, and Section 1 Introduction on
page 4 first paragraph.
Old Text: This paper summarizes the recommended correlation
between service classes and their usage, with references to
their corresponding recommended Differentiated Service Code
Points (DSCP), traffic conditioners, Per-Hop Behaviors (PHB)
and Active Queue Management (AQM) mechanism. There is no
intrinsic requirement that particular DSCPs, traffic
conditioner PHBs and AQM be used for a certain service class,
but as a policy it is useful that they be applied
consistently across the network.
New Text: This document describes service classes configured
with Diffserv, recommends how they can be used and how to
construct them using 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
conditioners, PHBs, and AQM be used for a certain service
class, but as a policy and for interoperability it is useful
to apply them consistently.
2. In Section 1 Introduction on page 4. Added new first paragraph:
For understanding the role of this document we use an useful
analogy, starting from the fact that the Differentiated
Services specifications are fundamentally a toolkit - the
specifications provide the equivalent of band saws, planers,
drill presses, etc. In the hands of an expert, there's no
limit to what can be built, but such a toolkit can be
intimidating to the point of inaccessible to a non-expert who
just wants to build a bookcase. This document should be
viewed as a set of "project plans" for building all the
(diffserv) furniture that one might want. The user may
choose what to build (e.g., perhaps our non-expert doesn't
need a china cabinet right now), and how to go about building
it (e.g., plans for a non-expert probably won't employ
mortise/tenon construction, but that absence does not imply
that mortise/tenon construction is forbidden or unsound).
The authors hope that these diffserv "project plans" will
provide a useful guide to Network Administrators in the use
of diffserv techniques to implement quality of service
measures appropriate for their network's traffic.
3. In Section 1.3 first paragraph on page 5.
Old Text: A "service class" represents a set of traffic that
requires specific delay, loss, and jitter characteristics
from the network for which a consistent and defined per-hop-
behavior (PHB) applies.
New Text: A "service class" represents a set of traffic that
requires specific delay, loss, and jitter characteristics
from the network.
4. In Section 1.3 second paragraph on page 5.
Old Text: A Service Class as defined here is essentially a
statement of the required characteristics of a traffic
aggregate; the actual specification of the expected treatment
of a traffic aggregate within a domain may also be defined as
a Per Domain Behavior [RFC3086].
New Text: A service class as defined here is essentially a
statement of the required characteristics of a traffic
aggregate. The required characteristics of these traffic
aggregates can be realized by the use of defined per-hop
behavior (PHB) [RFC2474]. The actual specification of the
expected treatment of a traffic aggregate within a domain may
also be defined as a per domain behavior (PDB) [RFC3086].
5. In Section 1.3 third paragraph on page 5.
Added New Paragraph: Each domain may choose to implement
different service classes, or use different behaviors to
implement the service classes, or aggregate different kinds
of traffic into the aggregates and still achieve their
required characteristics. For example, low delay, loss, and
jitter may be realized using the EF PHB, or with an over
provisioned AF PHB. This must be done with care as it may
disrupt the end to end performance required by the
applications/services. This document provides
recommendations on usage of PHBs for specific service classes
for their consistent implementation, these recommendations
are not to be construed as prohibiting use of other PHBs that
realize behaviors sufficient for the relevant class of
traffic.
6. In Section 1.4 first paragraph on page 5.
Old Text: The reader SHOULD be familiar with the principles of
the Differentiated Services Architecture [RFC2474]. However,
we recapitulate key concepts here to save searching.
New Text: The reader SHOULD be familiar with the principles of
the Differentiated Services Architecture [RFC2474]. We
recapitulate key concepts here only to provide convenience
for the reader, with the referenced RFCs providing the
authoritative definitions.
7. In Section 1.5.3 first paragraph first sentence on page 10.
Old Text: Expedited Forwarding PHB [RFC3246] behavior was
originally proposed as a way to implement a virtual wire, and
can be used in such a manner. It is an enhanced best effort
service:
New Text: The intent of Expedited Forwarding PHB [RFC3246] is to
provide a building block for low loss, low delay, and low
jitter services. It can be used to build an enhanced best
effort service:
8. In Section 2.3 second paragraph on page 16. Deleted the last
sentence:
There is also new work currently underway in ITU-T that
applies to the service classes defined in this document.
9. In Section 2.4.3 Example 3, on page 25. Fixed typo: "Multimedia
Steaming", changed it to "Multimedia Streaming".
10. In Section 2.4.3 Example 3, on page 26. Deleted the first note
under Notes for Figure 7: Deleted text "The Administrative
service class MAY be implemented using Rate queuing method as
long as sufficient amount of bandwidth is guaranteed and latency
of scheduler is sufficiently low to meet the requirement. "
11. In Section 10 on page 53. Moving the first reference:
[I-D.iab-auth-mech] Rescorla, E., "A Survey of Authentication
Mechanisms", draft-iab-auth-mech-04 (work in progress),
September 2005.
From Normative References section to Informative References
section.
8. Acknowledgements 7. Acknowledgements
The authors thank the TSVWG reviewers, David Black, Brian E Carpenter The authors thank the TSVWG reviewers, David Black, Brian E.
and Alan O'Neill for their review and input to this draft. Carpenter, and Alan O'Neill for their review and input to this
document.
The authors acknowledge great many inputs, most notably from Bruce The authors acknowledge a great many inputs, most notably from Bruce
Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet, Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet,
Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al
Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson, Mike Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson, Mike
Fidler and Shane Amante. Kimberly King, Joe Zebarth and Alistair Fidler, and Shane Amante. Kimberly King, Joe Zebarth, and Alistair
Munroe each did a thorough proof-reading, and the document is better Munroe each did a thorough proofreading, and the document is better
for their contributions. for their contributions.
9. Appendix A 8. Appendix A
9.1. Explanation of Ring Clipping 8.1. Explanation of Ring Clipping
The term "ring clipping" refers to those instances where the front The term "ring clipping" refers to those instances where the front
end of a ringing signal is altered because the bearer channel is not end of a ringing signal is altered because the bearer channel is not
made available in time to carry all of the audible ringing signal. made available in time to carry all the audible ringing signal. This
This condition may occur due to a race condition between when the condition may occur due to a race condition between when the tone
tone generator located in the circuit switch Exchange is turn on and generator located in the circuit switch Exchange is turned on and
when the bearer path through the IP network is enabled. To reduce when the bearer path through the IP network is enabled. To reduce
ring clipping from occurring, delay of signaling path needs to be ring clipping from occurring, delay of signaling path needs to be
minimized. Below is a more detailed explanation. minimized. Below is a more detailed explanation.
The bearer path setup delay target is defined as the ISUP Initial The bearer path setup delay target is defined as the ISUP Initial
Address Message (IAM) / Address Complete Message (ACM) round trip Address Message (IAM) / Address Complete Message (ACM) round-trip
delay. ISUP refers to ISDN User Part of Signaling System No. 7 (SS7) delay. ISUP refers to ISDN User Part of Signaling System No. 7
as defined by ITU-T. This consists of the amount of time it takes (SS7), as defined by ITU-T. This consists of the amount of time it
for the ISUP Initial Address Message (IAM) to leave the Transit takes for the ISUP Initial Address Message (IAM) to leave the Transit
Exchange, travel through the SS7 network (including any applicable Exchange, travel through the SS7 network (including any applicable
STPs (Signaling Transfer Points)), be processed by the End Exchange STPs, or Signaling Transfer Points), and be processed by the End
thus generating the Address Complete Message (ACM) and for the ACM to Exchange thus generating the Address Complete Message (ACM) and for
travel back through the SS7 network and return to the Transit the ACM to travel back through the SS7 network and return to the
Exchange. If the bearer path has not been set up within the soft- Transit Exchange. If the bearer path has not been set up within the
switch, media gateway and the IP network that is performing the soft-switch media gateway and the IP network that is performing the
Transit Exchange function by the time the ACM is forwarded to the Transit Exchange function by the time the ACM is forwarded to the
originating End Exchange, the phenomenon known as ring clipping may originating End Exchange, the phenomenon known as ring clipping may
occur. If ACM processing within soft-switch, media gateway and delay occur. If ACM processing within the soft-switch media gateway and
through the IP network is excessive, it will delay the setup of the delay through the IP network is excessive, it will delay the setup of
bearer path therefore may cause clipping of ring tone to be heard. the bearer path, and therefore may cause clipping of the ring tone to
be heard.
A generic maximum ISUP IAM signaling delay value of 240ms for intra The intra-exchange ISUP IAM signaling delay value should not exceed
Exchange, which may consist of soft-switch, media gateways, queuing 240ms. This may include soft-switch, media gateway, router, and
delay in routers and distance delays between media gateway and soft- propagation delay on the inter-exchange data path. This value
switch implementations is assumed. This value represents the represents the threshold where ring clipping theoretically commences.
threshold where ring clipping theoretically commences. It is It is important to note that the 240ms delay objective as presented
important to note that the 240ms delay objective as presented is a is a maximum value. Service administrators are free to choose
maximum value. Service administrators are free to choose specific specific IAM delay values according to their own preferences (i.e.,
IAM delay values based on their own preferences (i.e., they may wish they may wish to set a very low mean delay objective for strategic
to set a very low mean delay objective for strategic reasons to reasons to differentiate themselves from other providers). In
differentiate themselves from other providers). In summary, out of summary, out of the 240-ms delay budget, 200ms is allocated as
the 240ms delay budget, 200ms is allocated as cross-Exchange delay cross-Exchange delay (soft-switch and media gateway) and 40ms for
(soft-switch and media gateway) and 40ms for network delay (queuing network delay (queuing and distance).
and distance).
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
September 1981. 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 793, September 1981. 793, September 1981.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol [RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992. Suite", RFC 1349, July 1992.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
RFC 1812, June 1995. 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998. Internet", RFC 2309, April 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474, December
December 1998. 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Service", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
J., Courtney, W., Davari, S., Firoiu, V., and D. Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. Behavior)", RFC 3246, March 2002.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, December 2003. RFC 3662, December 2003.
10.2. Informative References 9.2. Informative References
[I-D.iab-auth-mech] [AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms",
Rescorla, E., "A Survey of Authentication Mechanisms", Work in Progress, September 2005.
draft-iab-auth-mech-04 (work in progress), September 2005.
[QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2
Technical Report Proposed Service Definition, March 2001. Technical Report Proposed Service Definition, March 2001.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", Services in the Internet Architecture: an Overview", RFC
RFC 1633, June 1994. 1633, June 1994.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999. Control", RFC 2581, April 1999.
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to
TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999. Marker", RFC 2697, September 1999.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, September 1999. Marker", RFC 2698, September 1999.
[RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper [RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper
for Differentiated Services", RFC 2963, October 2000. for Differentiated Services", RFC 2963, October 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
RFC 2983, October 2000. 2983, October 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000. November 2000.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of [RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, April 2001. their Specification", RFC 3086, April 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP", RFC
RFC 3168, September 2001. 3168, September 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC
RFC 3175, September 2001. 3175, September 2001.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290, Informal Management Model for Diffserv Routers", RFC 3290,
May 2002. May 2002.
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP's Fast Recovery Algorithm", RFC 3782,
April 2004.
Authors' Addresses Authors' Addresses
Jozef Babiarz Jozef Babiarz
Nortel Networks Nortel Networks
3500 Carling Avenue 3500 Carling Avenue
Ottawa, Ont. K2H 8E9 Ottawa, Ont. K2H 8E9
Canada Canada
Phone: +1-613-763-6098 Phone: +1-613-763-6098
Fax: +1-613-765-7462 Fax: +1-613-765-7462
Email: babiarz@nortel.com EMail: babiarz@nortel.com
Kwok Ho Chan Kwok Ho Chan
Nortel Networks Nortel Networks
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01821 Billerica, MA 01821
US US
Phone: +1-978-288-8175 Phone: +1-978-288-8175
Fax: +1-978-288-8700 Fax: +1-978-288-8700
Email: khchan@nortel.com EMail: khchan@nortel.com
Fred Baker Fred Baker
Cisco Systems Cisco Systems
1121 Via Del Rey 1121 Via Del Rey
Santa Barbara, CA 93117 Santa Barbara, CA 93117
US US
Phone: +1-408-526-4257 Phone: +1-408-526-4257
Fax: +1-413-473-2403 Fax: +1-413-473-2403
Email: fred@cisco.com EMail: fred@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 59, line 29 skipping to change at page 57, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 460 change blocks. 
1202 lines changed or deleted 1159 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/