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
   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.