SAMSUNG 1026
`
`1
`
`Network Working Group J. Babiarz
`Request for Comments: 4594 K. Chan
`Category: Informational Nortel Networks
`F. Baker
`Cisco Systems
`August 2006
`Configuration Guidelines for DiffServ Service Classes
`Status of This Memo
`This memo provides information for the Internet community. It does
`not specify an Internet standard of any kind. Distribution of this
`memo is unlimited.
`Copyright Notice
`Copyright (C) The Internet Society (2006).
`Abstract
`This document describes service classes configured with Diffserv and
`recommends how they can be used and how to construct them using
`Differentiated Services Code Points (DSCPs), traffic conditioners,
`Per-Hop Behaviors (PHBs), and Active Queue Management (AQM)
`mechanisms. There is no intrinsic requirement that particular DSCPs,
`traffic conditioners, PHBs, and AQM be used for a certain service
`class, but as a policy and for interoperability it is useful to apply
`them consistently.
`Babiarz, et al. Informational [Page 1]
`

`

`2
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`Table of Contents
`1. Introduction ....................................................3
`1.1. Requirements Notation ......................................4
`1.2. Expected Use in the Network ................................4
`1.3. Service Class Definition ...................................5
`1.4. Key Differentiated Services Concepts .......................5
`1.4.1. Queuing .............................................6
`1.4.1.1. Priority Queuing ...........................6
`1.4.1.2. Rate Queuing ...............................6
`1.4.2. Active Queue Management .............................7
`1.4.3. Traffic Conditioning ................................7
`1.4.4. Differentiated Services Code Point (DSCP) ...........8
`1.4.5. Per-Hop Behavior (PHB) ..............................8
`1.5. Key Service Concepts .......................................8
`1.5.1. Default Forwarding (DF) .............................9
`1.5.2. Assured Forwarding (AF) .............................9
`1.5.3. Expedited Forwarding (EF) ..........................10
`1.5.4. Class Selector (CS) ................................10
`1.5.5. Admission Control ..................................11
`2. Service Differentiation ........................................11
`2.1. Service Classes ...........................................12
`2.2. Categorization of User Service Classes ....................13
`2.3. Service Class Characteristics .............................16
`2.4. Deployment Scenarios ......................................21
`2.4.1. Example 1 ..........................................21
`2.4.2. Example 2 ..........................................23
`2.4.3. Example 3 ..........................................25
`3. Network Control Traffic ........................................27
`3.1. Current Practice in the Internet ..........................27
`3.2. Network Control Service Class .............................27
`3.3. OAM Service Class .........................................29
`4. User Traffic ...................................................30
`4.1. Telephony Service Class ...................................31
`4.2. Signaling Service Class ...................................33
`4.3. Multimedia Conferencing Service Class .....................35
`4.4. Real-Time Interactive Service Class .......................37
`4.5. Multimedia Streaming Service Class ........................39
`4.6. Broadcast Video Service Class .............................41
`4.7. Low-Latency Data Service Class ............................43
`4.8. High-Throughput Data Service Class ........................45
`4.9. Standard Service Class ....................................47
`4.10. Low-Priority Data ........................................48
`5. Additional Information on Service Class Usage ..................49
`5.1. Mapping for Signaling .....................................49
`5.2. Mapping for NTP ...........................................50
`5.3. VPN Service Mapping .......................................50
`6. Security Considerations ........................................51
`Babiarz, et al. Informational [Page 2]
`

`

`3
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`7. Acknowledgements ...............................................52
`8.
`Appendix A .....................................................53
`8.1. Explanation of Ring Clipping ..............................53
`9. References .....................................................54
`9.1. Normative References ......................................54
`9.2. Informative References ....................................55
`1. Introduction
`To aid in understanding the role of this document, we use an analogy:
`the Differentiated Services specifications are fundamentally a
`toolkit. The specifications provide the equivalent of band saws,
`planers, drill presses, and other tools. In the hands of an expert,
`there is no limit to what can be built, but such a toolkit can be
`intimidating to the point of being inaccessible to a non-expert who
`just wants to build a bookcase. This document should be viewed as a
`set of "project plans" for building all the (diffserv) furniture that
`one might want. The user may choose what to build (e.g., perhaps our
`non-expert doesn't need a china cabinet right now), and how to go
`about building it (e.g., plans for a non-expert probably won't employ
`mortise/tenon construction, but that absence does not imply that
`mortise/tenon construction is forbidden or unsound). The authors
`hope that these diffserv "project plans" will provide a useful guide
`to Network Administrators in the use of diffserv techniques to
`implement quality-of-service measures appropriate for their network's
`traffic.
`This document describes service classes configured with Diffserv and
`recommends how they can be used and how to construct them using
`Differentiated Services Code Points (DSCPs), traffic conditioners,
`Per-Hop Behaviors (PHBs), and Active Queue Management (AQM)
`mechanisms. There is no intrinsic requirement that particular DSCPs,
`traffic conditioners, PHBs, and AQM be used for a certain service
`class, but as a policy and for interoperability it is useful to apply
`them consistently.
`Service class definitions are based on the different traffic
`characteristics and required performance of the
`applications/services. This approach allows us to map current and
`future applications/services of similar traffic characteristics and
`performance requirements into the same service class. Since the
`applications'/services' characteristics and required performance are
`end to end, the service class notion needs to be preserved end to
`end. With this approach, a limited set of service classes is
`required. For completeness, we have defined twelve different service
`classes, two for network operation/administration and ten for
`user/subscriber applications/services. However, we expect that
`network administrators will implement a subset of these classes
`Babiarz, et al. Informational [Page 3]
`

`

`4
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`relevant to their customers and their service offerings. Network
`Administrators may also find it of value to add locally defined
`service classes, although these will not necessarily enjoy end-to-end
`properties of the same type.
`Section 1 provides an introduction and overview of technologies that
`are used for service differentiation in IP networks. Section 2 is an
`overview of how service classes are constructed to provide service
`differentiation, with examples of deployment scenarios. Section 3
`provides configuration guidelines of service classes that are used
`for stable operation and administration of the network. Section 4
`provides configuration guidelines of service classes that are used
`for differentiation of user/subscriber traffic. Section 5 provides
`additional guidance on mapping different applications/protocols to
`service classes. Section 6 addresses security considerations.
`1.1. Requirements Notation
`The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL
`NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
`this document are to be interpreted as described in [RFC2119].
`1.2. Expected Use in the Network
`In the Internet today, corporate LANs and ISP WANs are generally not
`heavily utilized. They are commonly 10% utilized at most. For this
`reason, congestion, loss, and variation in delay within corporate
`LANs and ISP backbones is virtually unknown. This clashes with user
`perceptions, for three very good reasons.
`o The industry moves through cycles of bandwidth boom and bandwidth
`bust, depending on prevailing market conditions and the periodic
`deployment of new bandwidth-hungry applications.
`o In access networks, the state is often different. This may be
`because throughput rates are artificially limited or over-
`subscribed, or because of access network design trade-offs.
`o Other characteristics, such as database design on web servers
`(that may create contention points, e.g., in filestore) and
`configuration of firewalls and routers, often look externally like
`a bandwidth limitation.
`The intent of this document is to provide a consistent marking,
`conditioning, and packet treatment strategy so that it can be
`configured and put into service on any link that is itself congested.
`Babiarz, et al. Informational [Page 4]
`

`

`5
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`1.3. Service Class Definition
`A "service class" represents a set of traffic that requires specific
`delay, loss, and jitter characteristics from the network.
`Conceptually, a service class pertains to applications with similar
`characteristics and performance requirements, such as a "High-
`Throughput Data" service class for applications like the web and
`electronic mail, or a "Telephony" service class for real-time traffic
`such as voice and other telephony services. Such a service class may
`be defined locally in a Differentiated Services (DS) domain, or
`across multiple DS domains, possibly extending end to end.
`A service class as defined here is essentially a statement of the
`required characteristics of a traffic aggregate. The required
`characteristics of these traffic aggregates can be realized by the
`use of defined per-hop behavior (PHB) [RFC2474]. The actual
`specification of the expected treatment of a traffic aggregate within
`a domain may also be defined as a per-domain behavior (PDB)
`[RFC3086].
`Each domain may choose to implement different service classes or to
`use different behaviors to implement the service classes or to
`aggregate different kinds of traffic into the aggregates and still
`achieve their required characteristics. For example, low delay,
`loss, and jitter may be realized using the EF PHB, or with an over-
`provisioned AF PHB. This must be done with care as it may disrupt
`the end-to-end performance required by the applications/services.
`This document provides recommendations on usage of PHBs for specific
`service classes for their consistent implementation. These
`recommendations are not to be construed as prohibiting use of other
`PHBs that realize behaviors sufficient for the relevant class of
`traffic.
`The Default Forwarding "Standard" service class is REQUIRED; all
`other service classes are OPTIONAL. It is expected that network
`administrators will base their choice of the level of service
`differentiation that they will support on their need, starting off
`with three or four service classes for user traffic and adding others
`as the need arises.
`1.4. Key Differentiated Services Concepts
`The reader SHOULD be familiar with the principles of the
`Differentiated Services Architecture [RFC2474]. We recapitulate key
`concepts here only to provide convenience for the reader, the
`referenced RFCs providing the authoritative definitions.
`Babiarz, et al. Informational [Page 5]
`

`

`6
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`1.4.1. Queuing
`A queue is a data structure that holds packets that are awaiting
`transmission. The packets may be delayed while in the queue,
`possibly due to lack of bandwidth, or because it is low in priority.
`There are a number of ways to implement a queue. A simple model of a
`queuing system, however, is a set of data structures for packet data,
`which we will call queues, and a mechanism for selecting the next
`packet from among them, which we call a scheduler.
`1.4.1.1. Priority Queuing
`A priority queuing system is a combination of a set of queues and a
`scheduler that empties them in priority sequence. When asked for a
`packet, the scheduler inspects the highest priority queue and, if
`there is data present, returns a packet from that queue. Failing
`that, it inspects the next highest priority queue, and so on. A
`freeway onramp with a stoplight for one lane that allows vehicles in
`the high-occupancy-vehicle lane to pass is an example of a priority
`queuing system; the high-occupancy-vehicle lane represents the
`"queue" having priority.
`In a priority queuing system, a packet in the highest priority queue
`will experience a readily calculated delay. This is proportional to
`the amount of data remaining to be serialized when the packet arrived
`plus the volume of the data already queued ahead of it in the same
`queue. The technical reason for using a priority queue relates
`exactly to this fact: it limits delay and variations in delay and
`should be used for traffic that has that requirement.
`A priority queue or queuing system needs to avoid starvation of
`lower-priority queues. This may be achieved through a variety of
`means, such as admission control, rate control, or network
`engineering.
`1.4.1.2. Rate Queuing
`Similarly, a rate-based queuing system is a combination of a set of
`queues and a scheduler that empties each at a specified rate. An
`example of a rate-based queuing system is a road intersection with a
`stoplight. The stoplight acts as a scheduler, giving each lane a
`certain opportunity to pass traffic through the intersection.
`In a rate-based queuing system, such as Weighted Fair Queuing (WFQ)
`or Weighted Round Robin (WRR), the delay that a packet in any given
`queue will experience depends on the parameters and occupancy of its
`queue and the parameters and occupancy of the queues it is competing
`with. A queue whose traffic arrival rate is much less than the rate
`Babiarz, et al. Informational [Page 6]
`

`

`7
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`at which it lets traffic depart will tend to be empty, and packets in
`it will experience nominal delays. A queue whose traffic arrival
`rate approximates or exceeds its departure rate will tend not to be
`empty, and packets in it will experience greater delay. Such a
`scheduler can impose a minimum rate, a maximum rate, or both, on any
`queue it touches.
`1.4.2. Active Queue Management
`Active Queue Management, or AQM, is a generic name for any of a
`variety of procedures that use packet dropping or marking to manage
`the depth of a queue. The canonical example of such a procedure is
`Random Early Detection (RED), in that a queue is assigned a minimum
`and maximum threshold, and the queuing algorithm maintains a moving
`average of the queue depth. While the mean queue depth exceeds the
`maximum threshold, all arriving traffic is dropped. While the mean
`queue depth exceeds the minimum threshold but not the maximum
`threshold, a randomly selected subset of arriving traffic is marked
`or dropped. This marking or dropping of traffic is intended to
`communicate with the sending system, causing its congestion avoidance
`algorithms to kick in. As a result of this behavior, it is
`reasonable to expect that TCP's cyclic behavior is desynchronized and
`that the mean queue depth (and therefore delay) should normally
`approximate the minimum threshold.
`A variation of the algorithm is applied in Assured Forwarding PHB
`[
`RFC2597], in that the behavior aggregate consists of traffic with
`multiple DSCP marks, which are intermingled in a common queue.
`Different minima and maxima are configured for the several DSCPs
`separately, such that traffic that exceeds a stated rate at ingress
`is more likely to be dropped or marked than traffic that is within
`its contracted rate.
`1.4.3. Traffic Conditioning
`In addition, at the first router in a network that a packet crosses,
`arriving traffic may be measured and dropped or marked according to a
`policy, or perhaps shaped on network ingress, as in "A Rate Adaptive
`Shaper for Differentiated Services" [RFC2963]. This may be used to
`bias feedback loops, as is done in "Assured Forwarding PHB"
`[RFC2597], or to limit the amount of traffic in a system, as is done
`in "Expedited Forwarding PHB" [RFC3246]. Such measurement procedures
`are collectively referred to as "traffic conditioners". Traffic
`conditioners are normally built using token bucket meters, for
`example with a committed rate and burst size, as in Section 1.5.3 of
`the DiffServ Model [RFC3290]. The Assured Forwarding PHB [RFC2597]
`uses a variation on a meter with multiple rate and burst size
`measurements to test and identify multiple levels of conformance.
`Babiarz, et al. Informational [Page 7]
`

`

`8
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`Multiple rates and burst sizes can be realized using multiple levels
`of token buckets or more complex token buckets; these are
`implementation details. The following are some traffic conditioners
`that may be used in deployment of differentiated services:
`o For Class Selector (CS) PHBs, a single token bucket meter to
`provide a rate plus burst size control.
`o For Expedited Forwarding (EF) PHB, a single token bucket meter to
`provide a rate plus burst size control.
`o For Assured Forwarding (AF) PHBs, usually two token bucket meters
`configured to provide behavior as outlined in "Two Rate Three
`Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color Marker
`(srTCM)" [RFC2697]. The two-rate, three-color marker is used to
`enforce two rates, whereas the single-rate, three-color marker is
`used to enforce a committed rate with two burst lengths.
`1.4.4. Differentiated Services Code Point (DSCP)
`The DSCP is a number in the range 0..63 that is placed into an IP
`packet to mark it according to the class of traffic it belongs in.
`Half of these values are earmarked for standardized services, and the
`other half of them are available for local definition.
`1.4.5. Per-Hop Behavior (PHB)
`In the end, the mechanisms described above are combined to form a
`specified set of characteristics for handling different kinds of
`traffic, depending on the needs of the application. This document
`seeks to identify useful traffic aggregates and to specify what PHB
`should be applied to them.
`1.5. Key Service Concepts
`While Differentiated Services is a general architecture that may be
`used to implement a variety of services, three fundamental forwarding
`behaviors have been defined and characterized for general use. These
`are basic Default Forwarding (DF) behavior for elastic traffic, the
`Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF)
`behavior for real-time (inelastic) traffic. The facts that four code
`points are recommended for AF and that one code point is recommended
`for EF are arbitrary choices, and the architecture allows any
`reasonable number of AF and EF classes simultaneously. The choice of
`four AF classes and one EF class in the current document is also
`arbitrary, and operators MAY choose to operate more or fewer of
`either.
`Babiarz, et al. Informational [Page 8]
`

`

`9
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`The terms "elastic" and "real-time" are defined in [RFC1633], Section
`3.1, as a way of understanding broad-brush application requirements.
`This document should be reviewed to obtain a broad understanding of
`the issues in quality of service, just as [RFC2475] should be
`reviewed to understand the data plane architecture used in today's
`Internet.
`1.5.1. Default Forwarding (DF)
`The basic forwarding behaviors applied to any class of traffic are
`those described in [RFC2474] and [RFC2309]. Best-effort service may
`be summarized as "I will accept your packets" and is typically
`configured with some bandwidth guarantee. Packets in transit may be
`lost, reordered, duplicated, or delayed at random. Generally,
`networks are engineered to limit this behavior, but changing traffic
`loads can push any network into such a state.
`Application traffic in the internet that uses default forwarding is
`expected to be "elastic" in nature. By this, we mean that the sender
`of traffic will adjust its transmission rate in response to changes
`in available rate, loss, or delay.
`For the basic best-effort service, a single DSCP value is provided to
`identify the traffic, a queue to store it, and active queue
`management to protect the network from it and to limit delays.
`1.5.2. Assured Forwarding (AF)
`The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled
`on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss
`Priority (CLP) capability. It is intended for networks that offer
`average-rate Service Level Agreements (SLAs) (as FR and ATM networks
`do). This is an enhanced best-effort service; traffic is expected to
`be "elastic" in nature. The receiver will detect loss or variation
`in delay in the network and provide feedback such that the sender
`adjusts its transmission rate to approximate available capacity.
`For such behaviors, multiple DSCP values are provided (two or three,
`perhaps more using local values) to identify the traffic, a common
`queue to store the aggregate, and active queue management to protect
`the network from it and to limit delays. Traffic is metered as it
`enters the network, and traffic is variously marked depending on the
`arrival rate of the aggregate. The premise is that it is normal for
`users occasionally to use more capacity than their contract
`stipulates, perhaps up to some bound. However, if traffic should be
`marked or lost to manage the queue, this excess traffic will be
`marked or lost first.
`Babiarz, et al. Informational [Page 9]
`

`

`10
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`1.5.3. Expedited Forwarding (EF)
`The intent of Expedited Forwarding PHB [RFC3246] is to provide a
`building block for low-loss, low-delay, and low-jitter services. It
`can be used to build an enhanced best-effort service: traffic remains
`subject to loss due to line errors and reordering during routing
`changes. However, using queuing techniques, the probability of delay
`or variation in delay is minimized. For this reason, it is generally
`used to carry voice and for transport of data information that
`requires "wire like" behavior through the IP network. Voice is an
`inelastic "real-time" application that sends packets at the rate the
`codec produces them, regardless of availability of capacity. As
`such, this service has the potential to disrupt or congest a network
`if not controlled. It also has the potential for abuse.
`To protect the network, at minimum one SHOULD police traffic at
`various points to ensure that the design of a queue is not overrun,
`and then the traffic SHOULD be given a low-delay queue (often using
`priority, although it is asserted that a rate-based queue can do
`this) to ensure that variation in delay is not an issue, to meet
`application needs.
`1.5.4. Class Selector (CS)
`Class Selector provides support for historical codepoint definitions
`and PHB requirement. The Class Selector DS field provides a limited
`backward compatibility with legacy (pre DiffServ) practice, as
`described in
`[RFC2474], Section 4. Backward compatibility is
`addressed in two ways. First, there are per-hop behaviors that are
`already in widespread use (e.g., those satisfying the IPv4 Precedence
`queuing requirements specified in [RFC1812]), and we wish to permit
`their continued use in DS-compliant networks. In addition, there are
`some codepoints that correspond to historical use of the IP
`Precedence field, and we reserve these codepoints to map to PHBs that
`meet the general requirements specified in [RFC2474], Section
`4.2.2.2.
`No attempt is made to maintain backward compatibility with the "DTR"
`or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in
`[
`RFC0791] and [RFC1349].
`A DS-compliant network can be deployed with a set of one or more
`Class Selector-compliant PHB groups. Also, a network administrator
`may configure the network nodes to map codepoints to PHBs,
`irrespective of bits 3-5 of the DSCP field, to yield a network that
`is compatible with historical IP Precedence use. Thus, for example,
`codepoint '011000' would map to the same PHB as codepoint '011010'.
`Babiarz, et al. Informational [Page 10]
`

`

`11
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`1.5.5. Admission Control
`Admission control (including refusal when policy thresholds are
`crossed) can ensure high-quality communication by ensuring the
`availability of bandwidth to carry a load. Inelastic real-time flows
`such as Voice over Internet Protocol (VoIP) (telephony) or video
`conferencing services can benefit from use of an admission control
`mechanism, as generally the telephony service is configured with
`over-subscription, meaning that some users may not be able to make a
`call during peak periods.
`For VoIP (telephony) service, a common approach is to use signaling
`protocols such as SIP, H.323, H.248, MEGACO, and Resource Reservation
`Protocol (RSVP) to negotiate admittance and use of network transport
`capabilities. When a user has been authorized to send voice traffic,
`this admission procedure has verified that data rates will be within
`the capacity of the network that it will use. Many RTP voice
`payloads are inelastic and cannot react to loss or delay in any
`substantive way. For these voice payloads, the network SHOULD police
`at ingress to ensure that the voice traffic stays within its
`negotiated bounds. Having thus assured a predictable input rate, the
`network may use a priority queue to ensure nominal delay and
`variation in delay.
`Another approach that may be used in small and bandwidth-constrained
`networks for limited number of flows is RSVP [RFC2205] [RFC2996].
`However, there is concern with the scalability of this solution in
`large networks where aggregation of reservations [RFC3175] is
`considered to be required.
`2. Service Differentiation
`There are practical limits on the level of service differentiation
`that should be offered in the IP networks. We believe we have
`defined a practical approach in delivering service differentiation by
`defining different service classes that networks may choose to
`support in order to provide the appropriate level of behaviors and
`performance needed by current and future applications and services.
`The defined structure for providing services allows several
`applications having similar traffic characteristics and performance
`requirements to be grouped into the same service class. This
`approach provides a lot of flexibility in providing the appropriate
`level of service differentiation for current and new, yet unknown
`applications without introducing significant changes to routers or
`network configurations when a new traffic type is added to the
`network.
`Babiarz, et al. Informational [Page 11]
`

`

`12
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`2.1. Service Classes
`Traffic flowing in a network can be classified in many different
`ways. We have chosen to divide it into two groupings, network
`control and user/subscriber traffic. To provide service
`differentiation, different service classes are defined in each
`grouping. The network control traffic group can further be divided
`into two service classes (see Section 3 for detailed definition of
`each service class):
`o "Network Control" for routing and network control function.
`o "OAM" (Operations, Administration, and Management) for network
`configuration and management functions.
`The user/subscriber traffic group is broken down into ten service
`classes to provide service differentiation for all the different
`types of applications/services (see Section 4 for detailed definition
`of each service class):
`o Telephony service class is best suited for applications that
`require very low delay variation and are of constant rate, such as
`IP telephony (VoIP) and circuit emulation over IP applications.
`o Signaling service class is best suited for peer-to-peer and
`client-server signaling and control functions using protocols such
`as SIP, SIP-T, H.323, H.248, and Media Gateway Control Protocol
`(MGCP).
`o Multimedia Conferencing service class is best suited for
`applications that require very low delay and have the ability to
`change encoding rate (rate adaptive), such as H.323/V2 and later
`video conferencing service.
`o Real-Time Interactive service class is intended for interactive
`variable rate inelastic applications that require low jitter and
`loss and very low delay, such as interactive gaming applications
`that use RTP/UDP streams for game control commands, and video
`conferencing applications that do not have the ability to change
`encoding rates or to mark packets with different importance
`indications.
`o Multimedia Streaming service class is best suited for variable
`rate elastic streaming media applications where a human is waiting
`for output and where the application has the capability to react
`to packet loss by reducing its transmission rate, such as
`streaming video and audio and webcast.
`o Broadcast Video service class is best suited for inelastic
`streaming media applications that may be of constant or variable
`rate, requiring low jitter and very low packet loss, such as
`broadcast TV and live events, video surveillance, and security.
`Babiarz, et al. Informational [Page 12]
`

`

`13
`
`RFC 4594 Guidelines for DiffServ Service Classes August 2006
`o Low-Latency Data service class is best suited for data processing
`applications where a human is waiting for output, such as web-
`based ordering or an Enterprise Resource Planning (ERP)
`application.
`o High-Throughput Data service class is best suited for store and
`forward applications such as FTP and billing record transfer.
`o Standard service class is for traffic that has not been identified
`as requiring differentiated treatment and is normally referred to
`as best effort.
`o Low-Priority Data service class is intended for packet flows where
`bandwidth assurance is not required.
`2.2. Categorization of User Service Classes
`The ten defined user/subscriber service classes listed above can be
`grouped into a small number of application categories. For some
`application categories, it was felt that more than one service class
`was needed to provide service differentiation within that category
`due to the different traffic characteristic of the applications,
`control function, and the required flow behavior. Figure 1 provides
`a summary of service class grouping into four application categories.
`Application Control Category
`o The Signaling service class is intended to be used to control
`applications or user endpoints. Examples of protocols that would
`use this service class are SIP or H.248 for IP telephone service
`and SIP or Internet Group Management Protocol (IGMP) for control
`of broadcast TV service to subscribers. Although user signaling
`flows have similar performance requirements as Low-Latency Data,
`they need to be distinguished and marked with a different DSCP.
`The essential distinction is something like "administrative
`control and management" of the traffic affected as the protocols
`in this class tend to be tied to the media stream/session they
`signal and control.
`Media-Oriented Category
`Due to the vast number of new (in process of being deployed) and
`already-in-use media-oriented services in IP networks, five service
`classes have been defined.
`o Telephony service class is intended for IP telephony (VoIP)
`service. It may also be used for other applications that meet the
`defined traffic characteristics and performance requirements.
`o Real-Time Interactive service class is intended for inelastic
`video flows from applications such as SIP-based desktop vid