as applications using the Multimedia Conferencing service class.
Such applications include streaming audio and video, some video
(movies) on-demand applications, and webcasts. In general, the
Multimedia Streaming service class assumes that the traffic is
buffered at the source/destination; therefore, it is less sensitive
to delay and jitter.
The Multimedia Streaming service class SHOULD use the Assured
Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD
be configured to provide a minimum bandwidth assurance for AF31,
AF32, and AF33 marked packets to ensure that they get forwarded. The
Multimedia Streaming service class SHOULD be configured to use Rate
Queuing system such as that defined in Section 1.4.1.2 of this
document.
The following applications SHOULD use the Multimedia Streaming
service class:
o Buffered streaming audio (unicast).
o Buffered streaming video (unicast).
o Webcasts.
o IP VPN service that specifies two rates and is less sensitive to
delay and jitter.
The following are traffic characteristics:
o Variable size packets.
o The higher the rate, the higher the density of large packets.
o Variable rate.
o Elastic flows.
o Some bursting at start of flow from some applications.
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 AF3x. Note: In this case, the
two-rate, three-color marker will be configured to operate in Color-
Blind mode.
RECOMMENDED DSCP marking:
o AF31 = up to specified rate "A".
o AF32 = in excess of specified rate "A" but below specified rate
"B".
o AF33 = 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 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 Streaming" traffic is
enhanced best-effort service with controlled rate and delay. The
service SHOULD be engineered so that AF31 marked packet flows have
sufficient bandwidth in the network to provide high assurance of
delivery. Since the AF3x traffic is elastic and responds dynamically
to packet loss, Active Queue Management [RFC2309] SHOULD be used
primarily to reduce forwarding rate to the minimum assured rate at
congestion points. The probability of loss of AF31 traffic MUST NOT
exceed the probability of loss of AF32 traffic, which in turn MUST
NOT exceed the probability of loss of AF33.
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 AF33 < max-threshold AF33
o max-threshold AF33 <= min-threshold AF32
o min-threshold AF32 < max-threshold AF32
o max-threshold AF32 <= min-threshold AF31
o min-threshold AF31 < max-threshold AF31
o max-threshold AF31 <= memory assigned to the queue
Note: This configuration tends to drop AF33 traffic before AF32 and
AF32 before AF31. Note: Many other AQM algorithms exist and are
used; they should be configured to achieve a similar result.
4.6. Broadcast Video Service Class
The Broadcast Video service class is RECOMMENDED for applications
that require near-real-time packet forwarding with very low packet
loss of constant rate and variable rate inelastic traffic sources
that are not as delay sensitive as applications using the Real-Time
Interactive service class. Such applications include broadcast TV,
streaming of live audio and video events, some video-on-demand
applications, and video surveillance. In general, the Broadcast
Video service class assumes that the destination end point has a
dejitter buffer, for video application usually a 2 - 8 video-frame
buffer (66 to several hundred of milliseconds), and therefore that it
is less sensitive to delay and jitter.
The Broadcast Video service class SHOULD use the Class Selector (CS)
PHB, defined in [RFC2474]. This service class SHOULD be configured
to provide high assurance for bandwidth for CS3 marked packets to
ensure that they get forwarded. The Broadcast Video service class
SHOULD be configured to use 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 third EF PHB that uses relaxed performance
parameter, a rate scheduler, and CS3 DSCP value.
The following applications SHOULD use the Broadcast Video service
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).
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:
o All flows in this service class are marked with CS3 (Class
Selector 3).
o In some cases, such as those for security and video surveillance
applications, it may be desirable to use a different DSCP marking.
If so, then locally user definable (EXP/LU) codepoints in the
range ’011xx1’ MAY be used to provide unique traffic
identification. The locally user definable (EXP/LU) codepoint(s)
MAY be associated with the PHB that is used for CS3 traffic.
Furthermore, depending on the network scenario, additional network
edge conditioning policy MAY be needed for the EXP/LU codepoint(s)
used.
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
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 "Broadcast Video" traffic is
enhanced best-effort service with controlled rate and delay. The
service SHOULD be engineered so that CS3 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 CS3 marked packet flows.
4.7. Low-Latency Data Service Class
The Low-Latency Data service class is RECOMMENDED for elastic and
responsive typically client-/server-based applications. Applications
forwarded by this service class are those that require a relatively
fast response and typically have asymmetrical bandwidth need, i.e.,
the client typically sends a short message to the server and the
server responds with a much larger data flow back to the client. The
most common example of this is when a user clicks a hyperlink (~ few
dozen bytes) on a web page, resulting in a new web page to be loaded
(Kbytes of data). This service class is configured to provide good
response for TCP [RFC1633] short-lived flows that require real-time
packet forwarding of variable rate traffic sources.
The Low-Latency Data service class SHOULD use the Assured Forwarding
(AF) PHB, defined in [RFC2597]. This service class SHOULD be
configured to provide a minimum bandwidth assurance for AF21, AF22,
and AF23 marked packets to ensure that they get forwarded. The Low-
Latency Data 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 Low-Latency Data service
class:
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.
The following are traffic characteristics:
o Variable size packets.
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
detection of packet loss at the receiver or through explicit
congestion notification.
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 AF2x. Note: In this case, the
single-rate, three-color marker will be configured to operate in
Color-Blind mode.
RECOMMENDED DSCP marking:
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
below "B" bytes.
o AF23 = flow stream with packet burst size in excess of "B" bytes.
o Where "A" < "B".
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 If packets are marked by trusted sources or a previously trusted
DiffServ domain and the color marking is to be preserved, then the
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
to be preserved, then the single-rate, three-color marker SHOULD
be configured to operate in Color-Blind mode.
The fundamental service offered to "Low-Latency Data" traffic is
enhanced best-effort service with controlled rate and delay. The
service SHOULD be engineered so that AF21 marked packet flows have
sufficient bandwidth in the network to provide high assurance of
delivery. Since the AF2x traffic is elastic and responds dynamically
to packet loss, Active Queue Management [RFC2309] SHOULD be used
primarily to control TCP flow rates at congestion points by dropping
packets from TCP flows that have large burst size. The probability
of loss of AF21 traffic MUST NOT exceed the probability of loss of
AF22 traffic, which in turn MUST NOT exceed the probability of loss
of AF23. Explicit Congestion Notification (ECN) [RFC3168] MAY also
be used with Active Queue Management.
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 AF23 < max-threshold AF23
o max-threshold AF23 <= min-threshold AF22
o min-threshold AF22 < max-threshold AF22
o max-threshold AF22 <= min-threshold AF21
o min-threshold AF21 < max-threshold AF21
o max-threshold AF21 <= memory assigned to the queue
Note: This configuration tends to drop AF23 traffic before AF22 and
AF22 before AF21. Many other AQM algorithms exist and are used; they
should be configured to achieve a similar result.
4.8. High-Throughput Data Service Class
The High-Throughput Data service class is RECOMMENDED for elastic
applications that require timely packet forwarding of variable rate
traffic sources and, more specifically, is configured to provide good
throughput for TCP longer-lived flows. TCP [RFC1633] or a transport
with a consistent Congestion Avoidance Procedure [RFC2581] [RFC3782]
normally will drive as high a data rate as it can obtain over a long
period of time. The FTP protocol is a common example, although one
cannot definitively say that all FTP transfers are moving data in
bulk.
The High-Throughput Data service class SHOULD use the Assured
Forwarding (AF) PHB, defined in [RFC2597]. This service class SHOULD
be configured to provide a minimum bandwidth assurance for AF11,
AF12, and AF13 marked packets to ensure that they are forwarded in a
timely manner. The High-Throughput Data 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 High-Throughput Data
service class:
o Store and forward applications.
o File transfer applications.
o Email.
o VPN service that supports two rates (committed information rate
and excess or peak information rate).
The following are traffic characteristics:
o Variable size packets.
o Variable packet emission rate.
o Variable rate.
o With packet bursts of TCP window size.
o Source capable of reducing its transmission rate based on
detection of packet loss at the receiver or through explicit
congestion notification.
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 AF1x. Note: In this case, the
two-rate, three-color marker will be configured to operate in Color-
Blind mode.
RECOMMENDED DSCP marking:
o AF11 = up to specified rate "A".
o AF12 = in excess of specified rate "A" but below specified rate
"B".
o AF13 = 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 "High-Throughput Data" traffic is
enhanced best-effort service with a specified minimum rate. The
service SHOULD be engineered so that AF11 marked packet flows have
sufficient bandwidth in the network to provide assured delivery. It
can be assumed that this class will consume any available bandwidth
and that packets traversing congested links may experience higher
queuing delays or packet loss. Since the AF1x traffic is elastic and
responds dynamically to packet loss, Active Queue Management
[RFC2309] SHOULD be used primarily to control TCP flow rates at
congestion points by dropping packets from TCP flows that have higher
rates first. The probability of loss of AF11 traffic MUST NOT exceed
the probability of loss of AF12 traffic, which in turn MUST NOT
exceed the probability of loss of AF13. In such a case, if one
network customer is driving significant excess and another seeks to
use the link, any losses will be experienced by the high-rate user,
causing him to reduce his rate. Explicit Congestion Notification
(ECN) [RFC3168] MAY also be used with Active Queue Management.
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 AF13 < max-threshold AF13
o max-threshold AF13 <= min-threshold AF12
o min-threshold AF12 < max-threshold AF12
o max-threshold AF12 <= min-threshold AF11
o min-threshold AF11 < max-threshold AF11
o max-threshold AF11 <= memory assigned to the queue
Note: This configuration tends to drop AF13 traffic before AF12 and
AF12 before AF11. Many other AQM algorithms exist and are used; they
should be configured to achieve a similar result.
4.9. Standard Service Class
The Standard service class is RECOMMENDED for traffic that has not
been classified into one of the other supported forwarding service
classes in the DiffServ network domain. This service class provides
the Internet’s "best-effort" forwarding behavior. This service class
typically has minimum bandwidth guarantee.
The Standard service class MUST use the Default Forwarding (DF) PHB,
defined in [RFC2474], and SHOULD be configured to receive at least a
small percentage of forwarding resources as a guaranteed minimum.
This 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 Standard service class:
o Network services, DNS, DHCP, BootP.
o Any undifferentiated application/packet flow transported through
the DiffServ enabled network.
The following is a traffic characteristic:
o Non-deterministic, mixture of everything.
The RECOMMENDED DSCP marking is DF (Default Forwarding) ’000000’.
Network Edge Conditioning:
There is no requirement that conditioning of packet flows be
performed for this service class.
The fundamental service offered to the Standard service class is
best-effort service with active queue management to limit overall
delay. Typical configurations SHOULD use random packet dropping to
implement Active Queue Management [RFC2309] or Explicit Congestion
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
specifies a target queue depth, and the max-threshold specifies the
queue depth above which all traffic is dropped or ECN marked. Thus,
in this service class, the following inequality should hold in queue
configurations:
o min-threshold DF < max-threshold DF
o max-threshold DF <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result.
4.10. Low-Priority Data
The Low-Priority Data service class serves applications that run over
TCP [RFC0793] or a transport with consistent congestion avoidance
procedures [RFC2581] [RFC3782] and that the user is willing to accept
service without guarantees. This service class is specified in
[RFC3662] and [QBSS].
The following applications MAY use the Low-Priority Data service
class:
o Any TCP based-application/packet flow transported through the
DiffServ enabled network that does not require any bandwidth
assurances.
The following is a traffic characteristic:
o Non-real-time and elastic.
Network Edge Conditioning:
There is no requirement that conditioning of packet flows be
performed for this service class.
The RECOMMENDED DSCP marking is CS1 (Class Selector 1).
The fundamental service offered to the Low-Priority Data service
class is best-effort service with zero bandwidth assurance. By
placing it into a separate queue or class, it may be treated in a
manner consistent with a specific Service Level Agreement.
Typical configurations SHOULD use Explicit Congestion Notification
[RFC3168] or random loss to implement Active Queue Management
[RFC2309].
If RED [RFC2309] is used as an AQM algorithm, the min-threshold
specifies a target queue depth, and the max-threshold specifies the
queue depth above which all traffic is dropped or ECN marked. Thus,
in this service class, the following inequality should hold in queue
configurations:
o min-threshold CS1 < max-threshold CS1
o max-threshold CS1 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be
configured to achieve a similar result.
5. Additional Information on Service Class Usage
In this section, we provide additional information on how some
specific applications should be configured to use the defined service
classes.
5.1. Mapping for Signaling
There are many different signaling protocols, ways that signaling is
used and performance requirements from applications that are
controlled by these protocols. We believe that different signaling
protocols should use the service class that best meets the objectives
of application or service they control. The following mapping is
recommended:
o Peer-to-peer signaling using SIP/H.323 is marked with CS5 DSCP
(use Signaling service class).
o Client-server signaling as used in many implementation for IP
telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN, or
proprietary protocols is marked with CS5 DSCP (use Signaling
service class).
o Signaling between call servers or soft-switches in carrier’s
network using SIP, SIP-T, or IP encapsulated ISUP is marked with
CS5 DSCP (use Signaling service class).
o RSVP signaling depends on the application. If RSVP signaling is
"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
as application data that it is controlling. This may also apply
to the "on-path" Next Steps in Signaling (NSIS) protocol.
o If IGMP is used for multicast session control such as channel
changing in IPTV systems, then IGMP packets should be marked with
CS5 DSCP (use Signaling service class). When IGMP is used only
for the normal multicast routing purpose, it should be marked with
CS6 DSCP (use Network Control service class).
5.2. Mapping for NTP
From tests that were performed, indications are that precise time
distribution requires a very low packet delay variation (jitter)
transport. Therefore, we suggest that the following guidelines for
Network Time Protocol (NTP) be used:
o When NTP is used for providing high-accuracy timing within an
administrator’s (carrier’s) network or to end users/clients, the
Telephony service class should be used, and NTP packets should be
marked with EF DSCP value.
o For applications that require "wall clock" timing accuracy, the
Standard service class should be used, and packets should be
marked with DF DSCP.
5.3. VPN Service Mapping
"Differentiated Services and Tunnels" [RFC2983] considers the
interaction of DiffServ architecture with IP tunnels of various