Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result.
3.3. OAM Service Class
The OAM (Operations, Administration, and Management) service class is
RECOMMENDED for OAM&P (Operations, Administration, and Management and
Provisioning) using protocols such as Simple Network Management
Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet,
and Common Open Policy Service (COPS). Applications using this
service class require a low packet loss but are relatively not
sensitive to delay. This service class is configured to provide good
packet delivery for intermittent flows.
The OAM service class SHOULD use the Class Selector (CS) PHB defined
in [RFC2474]. This service class SHOULD be configured to provide a
minimum bandwidth assurance for CS2 marked packets to ensure that
they get forwarded. The OAM service class SHOULD be configured to
use a Rate Queuing system such as defined in Section 1.4.1.2 of this
document.
The following applications SHOULD use the OAM service class:
o Provisioning and configuration of network elements.
o Performance monitoring of network elements.
o Any network operational alarms.
The following are traffic characteristics:
o Variable size packets.
o Intermittent traffic flows.
o Traffic may burst at times.
o Both elastic and inelastic flows.
o Traffic not sensitive to delays.
RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS2 (Class
Selector 2).
Applications or IP end points SHOULD pre-mark their packets with CS2
DSCP value. If the end point is not capable of setting the DSCP
value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification, as defined in [RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods, defined in
[RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (routers inside administered
network) MAY not require policing.
o Normally OAM&P CS2 marked packet flows are not allowed to flow
across peering points. If that is the case, then CS2 marked
packets SHOULD be policed (dropped) at both egress and ingress
peering interfaces.
The fundamental service offered to "OAM" traffic is enhanced best-
effort service with controlled rate. The service SHOULD be
engineered so that CS2 marked packet flows have sufficient bandwidth
in the network to provide high assurance of delivery. Since this
service class is used to forward both elastic and inelastic flows,
the service SHOULD be engineered so that Active Queue Management
[RFC2309] is applied to CS2 marked packets.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP is
dropped or ECN marked. Thus, in this service class, the following
inequality should hold in queue configurations:
o min-threshold CS2 < max-threshold CS2
o max-threshold CS2 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result.
4. User Traffic
User traffic is defined as packet flows between different users or
subscribers. It is the traffic that is sent to or from end-terminals
and that supports a very wide variety of applications and services.
User traffic can be differentiated in many different ways; therefore,
we investigated several different approaches to classifying user
traffic. We looked at differentiating user traffic as real-time
versus non-real-time, elastic or rate-adaptive versus inelastic,
sensitive versus insensitive to loss as well as traffic
categorization as interactive, responsive, timely, and non-critical,
as defined in ITU-T Recommendation G.1010. In the final analysis, we
used all of the above for service differentiation, mapping
application types that seemed to have different sets of performance
sensitivities, and requirements to different service classes.
Network administrators can categorize their applications according to
the type of behavior that they require and MAY choose to support all
or a subset of the defined service classes. Figure 3 provides some
common applications and the forwarding service classes that best
support them, based on their performance requirements.
4.1. Telephony Service Class
The Telephony service class is RECOMMENDED for applications that
require real-time, very low delay, very low jitter, and very low
packet loss for relatively constant-rate traffic sources (inelastic
traffic sources). This service class SHOULD be used for IP telephony
service.
The fundamental service offered to traffic in the Telephony service
class is minimum jitter, delay, and packet loss service up to a
specified upper bound. Operation is in some respect similar to an
ATM CBR service, which has guaranteed bandwidth and which, if it
stays within the negotiated rate, experiences nominal delay and no
loss. The EF PHB has a similar guarantee.
Typical configurations negotiate the setup of telephone calls over
IP, using protocols such as H.248, MEGACO, H.323, or SIP. When a
user has been authorized to send telephony traffic, the call
admission procedure should have verified that the newly admitted flow
will be within the capacity of the Telephony service class forwarding
capability in the network. For VoIP (telephony) service, call
admission control is usually performed by a telephony call server/
gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) on
access points to the network. The bandwidth in the core network and
the number of simultaneous VoIP sessions that can be supported needs
to be engineered and controlled so that there is no congestion for
this service. Since the inelastic types of RTP payloads in this
class do not react to loss or significant delay in any substantive
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,
as defined in [RFC3246], and SHOULD be configured to receive
guaranteed forwarding resources so that all packets are forwarded
quickly. The Telephony service class SHOULD be configured to use a
Priority Queuing system such as that defined in Section 1.4.1.1 of
this document.
The following applications SHOULD use the Telephony service class:
o VoIP (G.711, G.729 and other codecs).
o Voice-band data over IP (modem, fax).
o T.38 fax over IP.
o Circuit emulation over IP, virtual wire, etc.
o IP Virtual Private Network (VPN) service that specifies single-
rate, mean network delay that is slightly longer then network
propagation delay, very low jitter, and a very low packet loss.
The following are traffic characteristics:
o Mostly fixed-size packets for VoIP (60, 70, 120 or 200 bytes in
size).
o Packets emitted at constant time intervals.
o Admission control of new flows is provided by telephony call
server, media gateway, gatekeeper, edge router, end terminal, or
access node that provides flow admission control function.
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
value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification, as defined in [RFC2475].
The RECOMMENDED DSCP marking is EF for the following applications:
o VoIP (G.711, G.729 and other codecs).
o Voice-band data over IP (modem and fax).
o T.38 fax over IP.
o Circuit emulation over IP, virtual wire, etc.
RECOMMENDED Network Edge Conditioning:
o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods, defined in
[RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the telephony
traffic stays within its negotiated bounds.
o Policing is OPTIONAL for packet flows from trusted sources whose
behavior is ensured via other means (e.g., administrative controls
on those systems).
o Policing of Telephony packet flows across peering points where SLA
is in place is OPTIONAL as telephony traffic will be controlled by
admission control mechanism between peering points.
The fundamental service offered to "Telephony" traffic is enhanced
best-effort service with controlled rate, very low delay, and very
low loss. The service MUST be engineered so that EF marked packet
flows have sufficient bandwidth in the network to provide guaranteed
delivery. Normally traffic in this service class does not respond
dynamically to packet loss. As such, Active Queue Management
[RFC2309] SHOULD NOT be applied to EF marked packet flows.
4.2. Signaling Service Class
The Signaling service class is RECOMMENDED for delay-sensitive
client-server (traditional telephony) and peer-to-peer application
signaling. Telephony signaling includes signaling between IP phone
and soft-switch, soft-client and soft-switch, and media gateway and
soft-switch as well as peer-to-peer using various protocols. This
service class is intended to be used for control of sessions and
applications. Applications using this service class require a
relatively fast response, as there are typically several messages of
different sizes sent for control of the session. This service class
is configured to provide good response for short-lived, intermittent
flows that require real-time packet forwarding. To minimize the
possibility of ring clipping at start of call for VoIP service that
interfaces to a circuit switch Exchange in the Public Switched
Telephone Network (PSTN), the Signaling service class SHOULD be
configured so that the probability of packet drop or significant
queuing delay under peak load is very low in IP network segments that
provide this interface. The term "ring clipping" refers to those
instances where the front end of a ringing signal is altered because
the bearer path is not made available in time to carry all of the
audible ringing signal. This condition may occur due to a race
condition between when the tone generator in the circuit switch
Exchange is turned on and when the bearer path through the IP network
is enabled. See Section 8.1 for additional explanation of "ring
clipping" and Section 5.1 for explanation of mapping different
signaling methods to service classes.
The Signaling service class SHOULD use the Class Selector (CS) PHB,
defined in [RFC2474]. This service class SHOULD be configured to
provide a minimum bandwidth assurance for CS5 marked packets to
ensure that they get forwarded. The Signaling service class SHOULD
be configured to use a Rate Queuing system such as that defined in
Section 1.4.1.2 of this document.
The following applications SHOULD use the Signaling service class:
o Peer-to-peer IP telephony signaling (e.g., using SIP, H.323).
o Peer-to-peer signaling for multimedia applications (e.g., using
SIP, H.323).
o Peer-to-peer real-time control function.
o Client-server IP telephony signaling using H.248, MEGACO, MGCP, IP
encapsulated ISDN, or other proprietary protocols.
o Signaling to control IPTV applications using protocols such as
IGMP.
o Signaling flows between high-capacity telephony call servers or
soft switches using protocol such as SIP-T. Such high-capacity
devices may control thousands of telephony (VoIP) calls.
The following are traffic characteristics:
o Variable size packets, normally one packet at a time.
o Intermittent traffic flows.
o Traffic may burst at times.
o Delay-sensitive control messages sent between two end points.
RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS5 (Class
Selector 5).
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
value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification, as defined in [RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in [RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (application servers inside
administered network) MAY not require policing.
o Policing of packet flows across peering points SHOULD be performed
to the Service Level Agreement (SLA).
The fundamental service offered to "Signaling" traffic is enhanced
best-effort service with controlled rate and delay. The service
SHOULD be engineered so that CS5 marked packet flows have sufficient
bandwidth in the network to provide high assurance of delivery and
low delay. Normally, traffic in this service class does not respond
dynamically to packet loss. As such, Active Queue Management
[RFC2309] SHOULD NOT be applied to CS5 marked packet flows.
4.3. Multimedia Conferencing Service Class
The Multimedia Conferencing service class is RECOMMENDED for
applications that require real-time service for rate-adaptive
traffic. H.323/V2 and later versions of video conferencing equipment
with dynamic bandwidth adjustment are such applications. The traffic
sources in this service class have the ability to dynamically change
their transmission rate based on feedback from the receiver. One
approach used in H.323/V2 equipment is, when the receiver detects a
pre-configured level of packet loss, it signals to the transmitter
the indication of possible on-path congestion. When available, the
transmitter then selects a lower rate encoding codec. Note that
today, many H.323/V2 video conferencing solutions implement fixed-
step bandwidth change (usually reducing the rate), traffic resembling
step-wise CBR.
Typical video conferencing configurations negotiate the setup of
multimedia session using protocols such as H.323. When a user/end-
point has been authorized to start a multimedia session, the
admission procedure should have verified that the newly admitted data
rate will be within the engineered capacity of the Multimedia
Conferencing service class. The bandwidth in the core network and
the number of simultaneous video conferencing sessions that can be
supported SHOULD be engineered to control traffic load for this
service.
The Multimedia Conferencing service class SHOULD use the Assured
Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD
be configured to provide a bandwidth assurance for AF41, AF42, and
AF43 marked packets to ensure that they get forwarded. The
Multimedia Conferencing service class SHOULD be configured to use a
Rate Queuing system such as that defined in Section 1.4.1.2 of this
document.
The following applications SHOULD use the Multimedia Conferencing
service class:
o H.323/V2 and later versions of video conferencing applications
(interactive video).
o Video conferencing applications with rate control or traffic
content importance marking.
o Application server-to-application server non-bursty data transfer
requiring very low delay.
o IP VPN service that specifies two rates and mean network delay
that is slightly longer then network propagation delay.
o Interactive, time-critical, and mission-critical applications.
The following are traffic characteristics:
o Variable size packets.
o The higher the rate, the higher the density of large packets.
o Constant packet emission time interval.
o Variable rate.
o Source is capable of reducing its transmission rate based on
detection of packet loss at the receiver.
Applications or IP end points SHOULD pre-mark their packets with DSCP
values as shown below. If the end point is not capable of setting
the DSCP value, then the router topologically closest to the end
point SHOULD perform Multifield (MF) Classification, as defined in
[RFC2475] and mark all packets as AF4x. Note: In this case, the
two-rate, three-color marker will be configured to operate in Color-
Blind mode.
RECOMMENDED DSCP marking when performed by router closest to source:
o AF41 = up to specified rate "A".
o AF42 = in excess of specified rate "A" but below specified rate
"B".
o AF43 = in excess of specified rate "B".
o Where "A" < "B".
Note: One might expect "A" to approximate the sum of the mean rates
and "B" to approximate the sum of the peak rates.
RECOMMENDED DSCP marking when performed by H.323/V2 video
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 video stream up to specified rate
"A".
o AF42 = H.323 video conferencing video stream in excess of
specified rate "A" but below specified rate "B".
o AF43 = H.323 video conferencing video stream in excess of
specified rate "B".
o Where "A" < "B".
RECOMMENDED conditioning performed at DiffServ network edge:
o The two-rate, three-color marker SHOULD be configured to provide
the behavior as defined in trTCM [RFC2698].
o If packets are marked by trusted sources or a previously trusted
DiffServ domain and the color marking is to be preserved, then the
two-rate, three-color marker SHOULD be configured to operate in
Color-Aware mode.
o If the packet marking is not trusted or the color marking is not
to be preserved, then the two-rate, three-color marker SHOULD be
configured to operate in Color-Blind mode.
The fundamental service offered to "Multimedia Conferencing" traffic
is enhanced best-effort service with controlled rate and delay. For
video conferencing service, typically a 1% packet loss detected at
the receiver triggers an encoding rate change, dropping to the next
lower provisioned video encoding rate. As such, Active Queue
Management [RFC2309] SHOULD be used primarily to switch the video
encoding rate under congestion, changing from high rate to lower
rate, i.e., 1472 kbps to 768 kbps. The probability of loss of AF41
traffic MUST NOT exceed the probability of loss of AF42 traffic,
which in turn MUST NOT exceed the probability of loss of AF43
traffic.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth for each DSCP, and the max-threshold
specifies the queue depth above which all traffic with such a DSCP is
dropped or ECN marked. Thus, in this service class, the following
inequality should hold in queue configurations:
o min-threshold AF43 < max-threshold AF43
o max-threshold AF43 <= min-threshold AF42
o min-threshold AF42 < max-threshold AF42
o max-threshold AF42 <= min-threshold AF41
o min-threshold AF41 < max-threshold AF41
o max-threshold AF41 <= memory assigned to the queue
Note: This configuration tends to drop AF43 traffic before AF42 and
AF42 before AF41. Many other AQM algorithms exist and are used; they
should be configured to achieve a similar result.
4.4. Real-Time Interactive Service Class
The Real-Time Interactive service class is RECOMMENDED for
applications that require low loss and jitter and very low delay for
variable rate inelastic traffic sources. Interactive gaming and
video conferencing applications that do not have the ability to
change encoding rates or to mark packets with different importance
indications are such applications. The traffic sources in this
traffic class do not have the ability to reduce their transmission
rate according to feedback received from the receiving end.
Typically, applications in this service class are configured to
negotiate the setup of RTP/UDP control session. When a user/end-
point has been authorized to start a new session, the admission
procedure should have verified that the newly admitted data rates
will be within the engineered capacity of the Real-Time Interactive
service class. The bandwidth in the core network and the number of
simultaneous Real-time Interactive sessions that can be supported
SHOULD be engineered to control traffic load for this service.
The Real-Time Interactive service class SHOULD use the Class Selector
(CS) PHB, defined in [RFC2474]. This service class SHOULD be
configured to provide a high assurance for bandwidth for CS4 marked
packets to ensure that they get forwarded. The Real-Time Interactive
service class SHOULD be configured to use a Rate Queuing system such
as that defined in Section 1.4.1.2 of this document. Note that this
service class MAY be configured as a second EF PHB that uses relaxed
performance parameter, a rate scheduler, and CS4 DSCP value.
The following applications SHOULD use the Real-Time Interactive
service class:
o Interactive gaming and control.
o Video conferencing applications without rate control or traffic
content importance marking.
o IP VPN service that specifies single rate and mean network delay
that is slightly longer then network propagation delay.
o Inelastic, interactive, time-critical, and mission-critical
applications requiring very low delay.
The following are traffic characteristics:
o Variable size packets.
o Variable rate, non-bursty.
o Application is sensitive to delay variation between flows and
sessions.
o Lost packets, if any, are usually ignored by application.
RECOMMENDED DSCP marking:
o All flows in this service class are marked with CS4 (Class
Selector 4).
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
value, then the router topologically closest to the end point SHOULD
perform Multifield (MF) Classification, as defined in [RFC2475].
RECOMMENDED conditioning performed at DiffServ network edge:
o Packet flow marking (DSCP setting) from untrusted sources (end
user devices) SHOULD be verified at ingress to DiffServ network
using Multifield (MF) Classification methods defined in [RFC2475].
o Packet flows from untrusted sources (end user devices) SHOULD be
policed at ingress to DiffServ network, e.g., using single rate
with burst size token bucket policer to ensure that the traffic
stays within its negotiated or engineered bounds.
o Packet flows from trusted sources (application servers inside
administered network) MAY not require policing.
o Policing of packet flows across peering points SHOULD be performed
to the Service Level Agreement (SLA).
The fundamental service offered to "Real-Time Interactive" traffic is
enhanced best-effort service with controlled rate and delay. The
service SHOULD be engineered so that CS4 marked packet flows have
sufficient bandwidth in the network to provide high assurance of
delivery. Normally, traffic in this service class does not respond
dynamically to packet loss. As such, Active Queue Management
[RFC2309] SHOULD NOT be applied to CS4 marked packet flows.
4.5. Multimedia Streaming Service Class
The Multimedia Streaming service class is RECOMMENDED for
applications that require near-real-time packet forwarding of
variable rate elastic traffic sources that are not as delay sensitive