Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4594

Configuration Guidelines for DiffServ Service Classes

Pages: 57
Informational
Errata
Updated by:  58658622
Part 3 of 4 – Pages 30 to 49
First   Prev   Next

Top   ToC   RFC4594 - Page 30   prevText

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,
Top   ToC   RFC4594 - Page 31
   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.
Top   ToC   RFC4594 - Page 32
   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.
Top   ToC   RFC4594 - Page 33
   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
Top   ToC   RFC4594 - Page 34
   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).
Top   ToC   RFC4594 - Page 35
   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).
Top   ToC   RFC4594 - Page 36
   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".
Top   ToC   RFC4594 - Page 37
   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
Top   ToC   RFC4594 - Page 38
   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).
Top   ToC   RFC4594 - Page 39
   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.
Top   ToC   RFC4594 - Page 40
   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.
Top   ToC   RFC4594 - Page 41
   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
Top   ToC   RFC4594 - Page 42
   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.
Top   ToC   RFC4594 - Page 43
   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.
Top   ToC   RFC4594 - Page 44
   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
Top   ToC   RFC4594 - Page 45
   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).
Top   ToC   RFC4594 - Page 46
   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
Top   ToC   RFC4594 - Page 47
   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.
Top   ToC   RFC4594 - Page 48
   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.
Top   ToC   RFC4594 - Page 49
   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.



(page 49 continued on part 4)

Next Section