diff options
Diffstat (limited to 'doc/rfc/rfc4594.txt')
| -rw-r--r-- | doc/rfc/rfc4594.txt | 3195 |
1 files changed, 3195 insertions, 0 deletions
diff --git a/doc/rfc/rfc4594.txt b/doc/rfc/rfc4594.txt new file mode 100644 index 0000000..135cebf --- /dev/null +++ b/doc/rfc/rfc4594.txt @@ -0,0 +1,3195 @@ + + + + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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 video + conferencing applications and for interactive gaming. + + + +Babiarz, et al. Informational [Page 13] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + o Multimedia Conferencing service class is for video conferencing + solutions that have the ability to reduce their transmission rate + on detection of congestion. These flows can therefore be + classified as rate adaptive. As currently two types of video + conferencing equipment are used in IP networks (ones that generate + inelastic traffic and ones that generate rate-adaptive traffic), + two service class are needed. The Real-Time Interactive service + class should be used for equipment that generates inelastic video + flows and the Multimedia Conferencing service class for equipment + that generates rate-adaptive video flows. + o Broadcast Video service class is to be used for inelastic traffic + flows, which are intended for broadcast TV service and for + transport of live video and audio events. + o Multimedia Streaming service class is to be used for elastic + multimedia traffic flows. This multimedia content is typically + stored before being transmitted. It is also buffered at the + receiving end before being played out. The buffering is + sufficiently large to accommodate any variation in transmission + rate that is encountered in the network. Multimedia entertainment + over IP delivery services that are being developed can generate + both elastic and inelastic traffic flows; therefore, two service + classes are defined to address this space, respectively: + Multimedia Streaming and Broadcast Video. + + Data Category + + The data category is divided into three service classes. + + o Low-Latency Data for applications/services that require low delay + or latency for bursty but short-lived flows. + o High-Throughput Data for applications/services that require good + throughput for long-lived bursty flows. High Throughput and + Multimedia Steaming are close in their traffic flow + characteristics with High Throughput being a bit more bursty and + not as long-lived as Multimedia Streaming. + o Low-Priority Data for applications or services that can tolerate + short or long interruptions of packet flows. The Low-Priority + Data service class can be viewed as "don't care" to some degree. + + Best-Effort Category + + o All traffic that is not differentiated in the network falls into + this category and is mapped into the Standard service class. If a + packet is marked with a DSCP value that is not supported in the + network, it SHOULD be forwarded using the Standard service class. + + + + + + +Babiarz, et al. Informational [Page 14] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Figure 1, below, provides a grouping of the defined user/subscriber + service classes into four categories, with indications of which ones + use an independent flow for signaling or control; type of flow + behavior (elastic, rate adaptive, or inelastic); and the last column + provides end user Quality of Service (QoS) rating as defined in ITU-T + Recommendation G.1010. + + ----------------------------------------------------------------- + | Application | Service | Signaled | Flow | G.1010 | + | Categories | Class | | Behavior | Rating | + |-------------+---------------+----------+-----------+------------| + | Application | Signaling | Not | Inelastic | Responsive | + | Control | |applicable| | | + |-------------+---------------+----------+-----------+------------| + | | Telephony | Yes | Inelastic | Interactive| + | |---------------+----------+-----------+------------| + | | Real-Time | Yes | Inelastic | Interactive| + | | Interactive | | | | + | |---------------+----------+-----------+------------| + | Media- | Multimedia | Yes | Rate | Interactive| + | Oriented | Conferencing | | Adaptive | | + | |---------------+----------+-----------+------------| + | |Broadcast Video| Yes | Inelastic | Responsive | + | |---------------+----------+-----------+------------| + | | Multimedia | Yes | Elastic | Timely | + | | Streaming | | | | + |-------------+---------------+----------+-----------+------------| + | | Low-Latency | No | Elastic | Responsive | + | | Data | | | | + | |---------------+----------+-----------+------------| + | Data |High-Throughput| No | Elastic | Timely | + | | Data | | | | + | |---------------+----------+-----------+------------| + | | Low-Priority | No | Elastic |Non-critical| + | | Data | | | | + |-------------+---------------+----------+-----------+------------| + | Best Effort | Standard | Not Specified |Non-critical| + ----------------------------------------------------------------- + + Figure 1. User/Subscriber Service Classes Grouping + + + + + + + + + + + +Babiarz, et al. Informational [Page 15] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Here is a short explanation of the end user QoS category as defined + in ITU-T Recommendation G.1010. User traffic is divided into four + different categories, namely, interactive, responsive, timely, and + non-critical. An example of interactive traffic is between two + humans and is most sensitive to delay, loss, and jitter. Another + example of interactive traffic is between two servers where very low + delay and loss are needed. Responsive traffic is typically between a + human and a server but can also be between two servers. Responsive + traffic is less affected by jitter and can tolerate longer delays + than interactive traffic. Timely traffic is either between servers + or servers and humans and the delay tolerance is significantly longer + than responsive traffic. Non-critical traffic is normally between + servers/machines where delivery may be delay for period of time. + +2.3. Service Class Characteristics + + This document provides guidelines for network administrators in + configuring their network for the level of service differentiation + that is appropriate in their network to meet their QoS needs. It is + expected that network operators will configure and provide in their + networks a subset of the defined service classes. Our intent is to + provide guidelines for configuration of Differentiated Services for a + wide variety of applications, services, and network configurations. + In addition, network administrators may choose to define and deploy + other service classes in their network. + + Figure 2 provides a behavior view for traffic serviced by each + service class. The traffic characteristics column defines the + characteristics and profile of flows serviced, and the tolerance to + loss, delay, and jitter columns define the treatment the flows will + receive. End-to-end quantitative performance requirements may be + obtained from ITU-T Recommendations Y.1541 and Y.1540. + + + + + + + + + + + + + + + + + + + +Babiarz, et al. Informational [Page 16] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + ------------------------------------------------------------------- + |Service Class | | Tolerance to | + | Name | Traffic Characteristics | Loss |Delay |Jitter| + |===============+==============================+======+======+======| + | Network |Variable size packets, mostly | | | | + | Control |inelastic short messages, but | Low | Low | Yes | + | | traffic can also burst (BGP) | | | | + |---------------+------------------------------+------+------+------| + | | Fixed-size small packets, | Very | Very | Very | + | Telephony | constant emission rate, | Low | Low | Low | + | | inelastic and low-rate flows | | | | + |---------------+------------------------------+------+------+------| + | Signaling | Variable size packets, some | Low | Low | Yes | + | | what bursty short-lived flows| | | | + |---------------+------------------------------+------+------+------| + | Multimedia | Variable size packets, | Low | Very | | + | Conferencing | constant transmit interval, | - | Low | Low | + | |rate adaptive, reacts to loss |Medium| | | + |---------------+------------------------------+------+------+------| + | Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low | + | Interactive | mostly variable rate | | Low | | + |---------------+------------------------------+------+------+------| + | Multimedia | Variable size packets, |Low - |Medium| Yes | + | Streaming | elastic with variable rate |Medium| | | + |---------------+------------------------------+------+------+------| + | Broadcast | Constant and variable rate, | Very |Medium| Low | + | Video | inelastic, non-bursty flows | Low | | | + |---------------+------------------------------+------+------+------| + | Low-Latency | Variable rate, bursty short- | Low |Low - | Yes | + | Data | lived elastic flows | |Medium| | + |---------------+------------------------------+------+------+------| + | OAM | Variable size packets, | Low |Medium| Yes | + | | elastic & inelastic flows | | | | + |---------------+------------------------------+------+------+------| + |High-Throughput| Variable rate, bursty long- | Low |Medium| Yes | + | Data | lived elastic flows | |- High| | + |---------------+------------------------------+------+------+------| + | Standard | A bit of everything | Not Specified | + |---------------+------------------------------+------+------+------| + | Low-Priority | Non-real-time and elastic | High | High | Yes | + | Data | | | | | + ------------------------------------------------------------------- + + Figure 2. Service Class Characteristics + + + + + + + +Babiarz, et al. Informational [Page 17] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Notes for Figure 2: A "Yes" in the jitter-tolerant column implies + that data is buffered in the endpoint and that a moderate level of + network-induced variation in delay will not affect the application. + Applications that use TCP as a transport are generally good examples. + Routing protocols and peer-to-peer signaling also fall in this class; + although loss can create problems in setting up calls, a moderate + level of jitter merely makes call placement a little less predictable + in duration. + + Service classes indicate the required traffic forwarding treatment in + order to meet user, application, or network expectations. Section 3 + defines the service classes that MAY be used for forwarding network + control traffic, and Section 4 defines the service classes that MAY + be used for forwarding user traffic with examples of intended + application types mapped into each service class. Note that the + application types are only examples and are not meant to be all- + inclusive or prescriptive. Also, note that the service class naming + or ordering does not imply any priority ordering. They are simply + reference names that are used in this document with associated QoS + behaviors that are optimized for the particular application types + they support. Network administrators MAY choose to assign different + service class names to the service classes that they will support. + Figure 3 defines the RECOMMENDED relationship between service classes + and DS codepoint assignment with application examples. It is + RECOMMENDED that this relationship be preserved end to end. + + + + + + + + + + + + + + + + + + + + + + + + + + +Babiarz, et al. Informational [Page 18] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + ------------------------------------------------------------------ + | Service | DSCP | DSCP | Application | + | Class Name | Name | Value | Examples | + |===============+=========+=============+==========================| + |Network Control| CS6 | 110000 | Network routing | + |---------------+---------+-------------+--------------------------| + | Telephony | EF | 101110 | IP Telephony bearer | + |---------------+---------+-------------+--------------------------| + | Signaling | CS5 | 101000 | IP Telephony signaling | + |---------------+---------+-------------+--------------------------| + | Multimedia |AF41,AF42|100010,100100| H.323/V2 video | + | Conferencing | AF43 | 100110 | conferencing (adaptive) | + |---------------+---------+-------------+--------------------------| + | Real-Time | CS4 | 100000 | Video conferencing and | + | Interactive | | | Interactive gaming | + |---------------+---------+-------------+--------------------------| + | Multimedia |AF31,AF32|011010,011100| Streaming video and | + | Streaming | AF33 | 011110 | audio on demand | + |---------------+---------+-------------+--------------------------| + |Broadcast Video| CS3 | 011000 |Broadcast TV & live events| + |---------------+---------+-------------+--------------------------| + | Low-Latency |AF21,AF22|010010,010100|Client/server transactions| + | Data | AF23 | 010110 | Web-based ordering | + |---------------+---------+-------------+--------------------------| + | OAM | CS2 | 010000 | OAM&P | + |---------------+---------+-------------+--------------------------| + |High-Throughput|AF11,AF12|001010,001100| Store and forward | + | Data | AF13 | 001110 | applications | + |---------------+---------+-------------+--------------------------| + | Standard | DF (CS0)| 000000 | Undifferentiated | + | | | | applications | + |---------------+---------+-------------+--------------------------| + | Low-Priority | CS1 | 001000 | Any flow that has no BW | + | Data | | | assurance | + ------------------------------------------------------------------ + + Figure 3. DSCP to Service Class Mapping + + Notes for Figure 3: Default Forwarding (DF) and Class Selector 0 + (CS0) provide equivalent behavior and use the same DS codepoint, + '000000'. + + It is expected that network administrators will base their choice of + the service classes 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. + + + + + +Babiarz, et al. Informational [Page 19] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD be + used for the defined service classes that are further detailed in + Sections 3 and 4 of this document. According to what + applications/services need to be differentiated, network + administrators can choose the service class(es) that need to be + supported in their network. + + ------------------------------------------------------------------ + | Service | DSCP | Conditioning at | PHB | Queuing| AQM| + | Class | | DS Edge | Used | | | + |===============+======+===================+=========+========+====| + |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes| + |---------------+------+-------------------+---------+--------+----| + | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | + |---------------+------+-------------------+---------+--------+----| + | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | + |---------------+------+-------------------+---------+--------+----| + | Multimedia | AF41 | Using two-rate, | | | Yes| + | Conferencing | AF42 |three-color marker | RFC2597 | Rate | per| + | | AF43 | (such as RFC 2698)| | |DSCP| + |---------------+------+-------------------+---------+--------+----| + | Real-Time | CS4 |Police using sr+bs | RFC2474 | Rate | No | + | Interactive | | | | | | + |---------------+------+-------------------+---------|--------+----| + | Multimedia | AF31 | Using two-rate, | | | Yes| + | Streaming | AF32 |three-color marker | RFC2597 | Rate | per| + | | AF33 | (such as RFC 2698)| | |DSCP| + |---------------+------+-------------------+---------+--------+----| + |Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No | + |---------------+------+-------------------+---------+--------+----| + | Low- | AF21 | Using single-rate,| | | Yes| + | Latency | AF22 |three-color marker | RFC2597 | Rate | per| + | Data | AF23 | (such as RFC 2697)| | |DSCP| + |---------------+------+-------------------+---------+--------+----| + | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| + |---------------+------+-------------------+---------+--------+----| + | High- | AF11 | Using two-rate, | | | Yes| + | Throughput | AF12 |three-color marker | RFC2597 | Rate | per| + | Data | AF13 | (such as RFC 2698)| | |DSCP| + |---------------+------+-------------------+---------+--------+----| + | Standard | DF | Not applicable | RFC2474 | Rate | Yes| + |---------------+------+-------------------+---------+--------+----| + | Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| + | Data | | | | | | + ------------------------------------------------------------------ + + Figure 4. Summary of QoS Mechanisms Used for Each Service Class + + + + +Babiarz, et al. Informational [Page 20] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Notes for Figure 4: + + o Conditioning at DS edge means that traffic conditioning is + performed at the edge of the DiffServ network where untrusted user + devices are connected or between two DiffServ networks. + o "sr+bs" represents a policing mechanism that provides single rate + with burst size control. + o The single-rate, three-color marker (srTCM) behavior SHOULD be + equivalent to RFC 2697, and the two-rate, three-color marker + (trTCM) behavior SHOULD be equivalent to RFC 2698. + o The PHB for Real-Time Interactive service class SHOULD be + configured to provide high bandwidth assurance. It MAY be + configured as a second EF PHB that uses relaxed performance + parameters and a rate scheduler. + o The PHB for Broadcast Video service class SHOULD be configured to + provide high bandwidth assurance. It MAY be configured as a third + EF PHB that uses relaxed performance parameters and a rate + scheduler. + o In network segments that use IP precedence marking, only one of + the two service classes can be supported, High-Throughput Data or + Low-Priority Data. We RECOMMEND that the DSCP value(s) of the + unsupported service class be changed to 000xx1 on ingress and + changed back to original value(s) on egress of the network segment + that uses precedence marking. For example, if Low-Priority Data + is mapped to Standard service class, then 000001 DSCP marking MAY + be used to distinguish it from Standard marked packets on egress. + +2.4. Deployment Scenarios + + It is expected that network administrators will base their choice of + the service classes that they will support on their need, starting + off with three or four service classes for user traffic and adding + more service classes as the need arises. In this section, we provide + three examples of possible deployment scenarios. + +2.4.1. Example 1 + + A network administrator determines that he needs to provide different + performance levels (quality of service) in his network for the + services that he will be offering to his customers. He needs to + enable his network to provide: + + + + + + + + + + +Babiarz, et al. Informational [Page 21] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + o Reliable VoIP (telephony) service, equivalent to Public Switched + Telephone Network (PSTN). + o A low-delay assured bandwidth data service. + o Support for current Internet services. + + For this example, the network administrator's needs are addressed + with the deployment of the following six service classes: + + o Network Control service class for routing and control traffic that + is needed for reliable operation of the provider's network. + o Standard service class for all traffic that will receive normal + (undifferentiated) forwarding treatment through the network for + support of current Internet service. + o Telephony service class for VoIP (telephony) bearer traffic. + o Signaling service class for Telephony signaling to control the + VoIP service. + o Low-Latency Data service class for the low-delay assured bandwidth + differentiated data service. + o OAM service class for operation and management of the network. + + Figure 5 provides a summary of the mechanisms needed for delivery of + service differentiation for Example 1. + + ------------------------------------------------------------------- + | Service | DSCP | Conditioning at | PHB | | | + | Class | | DS Edge | Used | Queuing| AQM| + |===============+=======+===================+=========+========+====| + |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes| + |---------------+-------+-------------------+---------+--------+----| + | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | + |---------------+-------+-------------------+---------+--------+----| + | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | + |---------------+-------+-------------------+---------+--------+----| + | Low- | AF21 | Using single-rate,| | | Yes| + | Latency | AF22 |three-color marker | RFC2597 | Rate | per| + | Data | AF23 | (such as RFC 2697)| | |DSCP| + |---------------+-------+-------------------+---------+--------+----| + | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| + |---------------+-------+-------------------+---------+--------+----| + | Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes| + | | +other| | | | | + ------------------------------------------------------------------- + + Figure 5. Service Provider Network Configuration Example 1 + + + + + + + +Babiarz, et al. Informational [Page 22] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Notes for Figure 5: + + o "sr+bs" represents a policing mechanism that provides single rate + with burst size control. + o The single-rate, three-color marker (srTCM) behavior SHOULD be + equivalent to RFC 2697. + o Any packet that is marked with DSCP value that is not represented + by the supported service classes SHOULD be forwarded using the + Standard service class. + +2.4.2. Example 2 + + With this example, we show how network operators with Example 1 + capabilities can evolve their service offering to provide three new + additional services to their customers. The new additional service + capabilities that are to be added are: + + o SIP-based desktop video conference capability to complement VoIP + (telephony) service. + o TV and on-demand movie viewing service to residential subscribers. + o Network-based data storage and file backup service to business + customers. + + The new additional services that the network administrator would like + to offer are addressed with the deployment of the following four + additional service classes (these are additions to the six service + classes already defined in Example 1): + + o Real-Time Interactive service class for transport of MPEG-4 real- + time video flows to support desktop video conferencing. The + control/signaling for video conferencing is done using the + Signaling service class. + o Broadcast Video service class for transport of IPTV broadcast + information. The channel selection and control is via IGMP mapped + into the Signaling service class. + o Multimedia Streaming service class for transport of stored MPEG-2 + or MPEG-4 content. The selection and control of streaming + information is done using the Signaling service class. The + selection of Multimedia Streaming service class for on-demand + movie service was chosen as the set-top box used for this service + has local buffering capability to compensate for the bandwidth + variability of the elastic streaming information. Note that if + transport of on-demand movie service is inelastic, then the + Broadcast Video service class SHOULD be used. + o High-Throughput Data service class is for transport of bulk data + for network-based storage and file backup service to business + customers. + + + + +Babiarz, et al. Informational [Page 23] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Figure 6 provides a summary of the mechanisms needed for delivery of + service differentiation for all the service classes used in Example + 2. + + ------------------------------------------------------------------- + | Service | DSCP | Conditioning at | PHB | | | + | Class | | DS Edge | Used | Queuing| AQM| + |===============+=======+===================+=========+========+====| + |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate |Yes | + |---------------+-------+-------------------+---------+--------+----| + | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | + |---------------+-------+-------------------+---------+--------+----| + | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | + |---------------+-------+-------------------+---------+--------+----| + | Real-time | CS4 |Police using sr+bs | RFC2474 | Rate | No | + | Interactive | | | | | | + |---------------+-------+-------------------+---------+--------+----| + |Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No | + |---------------+-------+-------------------+---------+--------+----| + | Multimedia | AF31 | Using two-rate, | | |Yes | + | Streaming | AF32 |three-color marker | RFC2597 | Rate |per | + | | AF33 | (such as RFC 2698)| | |DSCP| + |---------------+-------+-------------------+---------+--------+----| + | Low- | AF21 | Using single-rate,| | |Yes | + | Latency | AF22 |three-color marker | RFC2597 | Rate |per | + | Data | AF23 | (such as RFC 2697)| | |DSCP| + |---------------+-------+-------------------+---------+--------+----| + | OAM | CS2 |Police using sr+bs | RFC2474 | Rate |Yes | + |---------------+-------+-------------------+---------+--------+----| + | High- | AF11 | Using two-rate, | | |Yes | + | Throughput | AF12 |three-color marker | RFC2597 | Rate |per | + | Data | AF13 | (such as RFC 2698)| | |DSCP| + |---------------+-------+-------------------+---------+--------+----| + | Standard |DF(CS0)| Not applicable | RFC2474 | Rate |Yes | + | | +other| | | | | + ------------------------------------------------------------------- + + Figure 6. Service Provider Network Configuration Example 2 + + Notes for Figure 6: + + o "sr+bs" represents a policing mechanism that provides single rate + with burst size control. + o The single-rate, three-color marker (srTCM) behavior SHOULD be + equivalent to RFC 2697, and the two-rate, three-color marker + (trTCM) behavior SHOULD be equivalent to RFC 2698. + + + + + +Babiarz, et al. Informational [Page 24] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + o Any packet that is marked with DSCP value that is not represented + by the supported service classes SHOULD be forwarded using the + Standard service class. + +2.4.3. Example 3 + + An enterprise network administrator determines that they need to + provide different performance levels (quality of service) in their + network for the new services that are being offered to corporate + users. The enterprise network needs to: + + o Provide reliable corporate VoIP service. + o Provide video conferencing service to selected Conference Rooms. + o Support on-demand distribution of prerecorded audio and video + information to large number of users. + o Provide a priority data transfer capability for engineering teams + to share design information. + o Reduce or deny bandwidth during peak traffic periods for selected + applications. + o Continue to provide normal IP service to all remaining + applications and services. + + For this example, the enterprise's network needs are addressed with + the deployment of the following nine service classes: + + o Network Control service class for routing and control traffic that + is needed for reliable operation of the enterprise network. + o OAM service class for operation and management of the network. + o Standard service class for all traffic that will receive normal + (undifferentiated) forwarding treatment. + o Telephony service class for VoIP (telephony) bearer traffic. + o Signaling service class for Telephony signaling to control the + VoIP service. + o Multimedia Conferencing service class for support of inter- + Conference Room video conferencing service using H.323/V2 or + similar equipment. + o Multimedia Streaming service class for transfer of prerecorded + audio and video information. + o High-Throughput Data service class to provide bandwidth assurance + for timely transfer of large engineering files. + o Low-Priority Data service class for selected background + applications where data transfer can be delayed or suspended for a + period of time during peak network load conditions. + + + + + + + + +Babiarz, et al. Informational [Page 25] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Figure 7 provides a summary of the mechanisms needed for delivery of + service differentiation for Example 3. + + ------------------------------------------------------------------- + | Service | DSCP | Conditioning at | PHB | | | + | Class | | DS Edge | Used | Queuing| AQM| + |===============+=======+===================+=========+========+====| + |Network Control| CS6 | See Section 3.2 | RFC2474 | Rate | Yes| + |---------------+-------+-------------------+---------+--------+----| + | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | + |---------------+-------+-------------------+---------+--------+----| + | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | + |---------------+-------+-------------------+---------+--------+----| + | Multimedia | AF41 | Using two-rate, | | | Yes| + | Conferencing | AF42 | three-color marker| RFC2597 | Rate | per| + | | AF43 | (such as RFC 2698)| | |DSCP| + |---------------+-------+-------------------+---------+--------+----| + | Multimedia | AF31 | Using two-rate, | | | Yes| + | Streaming | AF32 | three-color marker| RFC2597 | Rate | per| + | | AF33 | (such as RFC 2698)| | |DSCP| + |---------------+-------+-------------------+---------+--------+----| + | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| + |---------------+-------+-------------------+---------+--------+----| + | High- | AF11 | Using two-rate, | | |Yes | + | Throughput | AF12 |three-color marker | RFC2597 | Rate |per | + | Data | AF13 | (such as RFC 2698)| | |DSCP| + |---------------+-------+-------------------+---------+--------+----| + | Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| + | Data | | | | | | + |---------------+-------+-------------------+---------+--------+----| + | Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes| + | | +other| | | | | + ------------------------------------------------------------------- + + Figure 7. Enterprise Network Configuration Example + + Notes for Figure 7: + + o "sr+bs" represents a policing mechanism that provides single rate + with burst size control. + o The single-rate, three-color marker (srTCM) behavior SHOULD be + equivalent to RFC 2697, and the two-rate, three-color marker + (trTCM) behavior SHOULD be equivalent to RFC 2698. + o Any packet that is marked with DSCP value that is not represented + by the supported service classes SHOULD be forwarded using the + Standard service class. + + + + + +Babiarz, et al. Informational [Page 26] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + +3. Network Control Traffic + + Network control traffic is defined as packet flows that are essential + for stable operation of the administered network as well as for + information that may be exchanged between neighboring networks across + a peering point where SLAs are in place. Network control traffic is + different from user application control (signaling) that may be + generated by some applications or services. Network control traffic + is mostly between routers and network nodes that are used for + operating, administering, controlling, or managing the network + segments. Network Control Traffic may be split into two service + classes, i.e., Network Control and OAM. + +3.1. Current Practice in the Internet + + Based on today's routing protocols and network control procedures + that are used in the Internet, we have determined that CS6 DSCP value + SHOULD be used for routing and control and that CS7 DSCP value SHOULD + be reserved for future use, potentially for future routing or control + protocols. Network administrators MAY use a Local/Experimental DSCP; + therefore, they may use a locally defined service class within their + network to further differentiate their routing and control traffic. + + RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets: + + o Drop or remark CS7 packets at ingress to DiffServ network domain. + o CS7 marked packets SHOULD NOT be sent across peering points. + Exchange of control information across peering points SHOULD be + done using CS6 DSCP and the Network Control service class. + +3.2. Network Control Service Class + + The Network Control service class is used for transmitting packets + between network devices (routers) that require control (routing) + information to be exchanged between nodes within the administrative + domain as well as across a peering point between different + administrative domains. Traffic transmitted in this service class is + very important as it keeps the network operational, and it needs to + be forwarded in a timely manner. + + The Network Control service class SHOULD be configured using the + DiffServ Class Selector (CS) PHB, defined in [RFC2474]. This service + class SHOULD be configured so that the traffic receives a minimum + bandwidth guarantee, to ensure that the packets always receive timely + service. The configured forwarding resources for Network Control + service class SHOULD be such that the probability of packet drop + under peak load is very low in this service class. The Network + + + + +Babiarz, et al. Informational [Page 27] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Control service class SHOULD be configured to use a Rate Queuing + system such as defined in Section 1.4.1.2 of this document. + + The following are examples of protocols and applications that SHOULD + use the Network Control service class: + + o Routing packet flows: OSPF, BGP, ISIS, RIP. + o Control information exchange within and between different + administrative domains across a peering point where SLAs are in + place. + o LSP setup using CR-LDP and RSVP-TE. + + The following protocols and applications SHOULD NOT use the Network + Control service class: + + o User traffic. + + The following are traffic characteristics of packet flows in the + Network Control service class: + + o Mostly messages sent between routers and network servers. + o Variable size packets, normally one packet at a time, but traffic + can also burst (BGP). + o User traffic is not allowed to use this service class. By user + traffic, we mean packet flows that originate from user-controlled + end points that are connected to the network. + + The RECOMMENDED DSCP marking is CS6 (Class Selector 6). + + RECOMMENDED Network Edge Conditioning: + + o At peering points (between two DiffServ networks) where SLAs are + in place, CS6 marked packets SHOULD be policed, e.g., using a + single rate with burst size (sr+bs) token bucket policer to keep + the CS6 marked packet flows to within the traffic rate specified + in the SLA. + o CS6 marked packet flows from untrusted sources (for example, end + user devices) SHOULD be dropped or remarked at ingress to the + DiffServ network. + o Packets from users/subscribers are not permitted access to the + Network Control service classes. + + The fundamental service offered to the Network Control service class + is enhanced best-effort service with high bandwidth assurance. Since + this service class is used to forward both elastic and inelastic + flows, the service SHOULD be engineered so that the Active Queue + Management (AQM) [RFC2309] is applied to CS6 marked packets. + + + + +Babiarz, et al. Informational [Page 28] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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 CS6 < max-threshold CS6 + o max-threshold CS6 <= memory assigned to the queue + + Note: Many other AQM algorithms exist and are used; they should be + configured to achieve a similar result. + +3.3. OAM Service Class + + The OAM (Operations, Administration, and Management) service class is + RECOMMENDED for OAM&P (Operations, Administration, and Management and + Provisioning) using protocols such as Simple Network Management + Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet, + and Common Open Policy Service (COPS). Applications using this + service class require a low packet loss but are relatively not + sensitive to delay. This service class is configured to provide good + packet delivery for intermittent flows. + + The OAM service class SHOULD use the Class Selector (CS) PHB defined + in [RFC2474]. This service class SHOULD be configured to provide a + minimum bandwidth assurance for CS2 marked packets to ensure that + they get forwarded. The OAM service class SHOULD be configured to + use a Rate Queuing system such as defined in Section 1.4.1.2 of this + document. + + The following applications SHOULD use the OAM service class: + + o Provisioning and configuration of network elements. + o Performance monitoring of network elements. + o Any network operational alarms. + + The following are traffic characteristics: + + o Variable size packets. + o Intermittent traffic flows. + o Traffic may burst at times. + o Both elastic and inelastic flows. + o Traffic not sensitive to delays. + + RECOMMENDED DSCP marking: + + o All flows in this service class are marked with CS2 (Class + Selector 2). + + + +Babiarz, et al. Informational [Page 29] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Applications or IP end points SHOULD pre-mark their packets with CS2 + DSCP value. If the end point is not capable of setting the DSCP + value, then the router topologically closest to the end point SHOULD + perform Multifield (MF) Classification, as defined in [RFC2475]. + + RECOMMENDED conditioning performed at DiffServ network edge: + + o Packet flow marking (DSCP setting) from untrusted sources (end + user devices) SHOULD be verified at ingress to DiffServ network + using Multifield (MF) Classification methods, defined in + [RFC2475]. + o Packet flows from untrusted sources (end user devices) SHOULD be + policed at ingress to DiffServ network, e.g., using single rate + with burst size token bucket policer to ensure that the traffic + stays within its negotiated or engineered bounds. + o Packet flows from trusted sources (routers inside administered + network) MAY not require policing. + o Normally OAM&P CS2 marked packet flows are not allowed to flow + across peering points. If that is the case, then CS2 marked + packets SHOULD be policed (dropped) at both egress and ingress + peering interfaces. + + The fundamental service offered to "OAM" traffic is enhanced best- + effort service with controlled rate. The service SHOULD be + engineered so that CS2 marked packet flows have sufficient bandwidth + in the network to provide high assurance of delivery. Since this + service class is used to forward both elastic and inelastic flows, + the service SHOULD be engineered so that Active Queue Management + [RFC2309] is applied to CS2 marked packets. + + If RED [RFC2309] is used as an AQM algorithm, the min-threshold + specifies a target queue depth for each DSCP, and the max-threshold + specifies the queue depth above which all traffic with such a DSCP is + dropped or ECN marked. Thus, in this service class, the following + inequality should hold in queue configurations: + + o min-threshold CS2 < max-threshold CS2 + o max-threshold CS2 <= memory assigned to the queue + + Note: Many other AQM algorithms exist and are used; they should be + configured to achieve a similar result. + +4. User Traffic + + User traffic is defined as packet flows between different users or + subscribers. It is the traffic that is sent to or from end-terminals + and that supports a very wide variety of applications and services. + User traffic can be differentiated in many different ways; therefore, + + + +Babiarz, et al. Informational [Page 30] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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. + + + + +Babiarz, et al. Informational [Page 31] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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. + + + +Babiarz, et al. Informational [Page 32] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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 + + + + +Babiarz, et al. Informational [Page 33] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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). + + + + +Babiarz, et al. Informational [Page 34] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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). + + + + +Babiarz, et al. Informational [Page 35] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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". + + + +Babiarz, et al. Informational [Page 36] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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 + + + +Babiarz, et al. Informational [Page 37] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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). + + + + + + +Babiarz, et al. Informational [Page 38] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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. + + + + + +Babiarz, et al. Informational [Page 39] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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. + + + + + +Babiarz, et al. Informational [Page 40] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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 + + + +Babiarz, et al. Informational [Page 41] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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. + + + +Babiarz, et al. Informational [Page 42] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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. + + + + + +Babiarz, et al. Informational [Page 43] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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 + + + +Babiarz, et al. Informational [Page 44] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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). + + + +Babiarz, et al. Informational [Page 45] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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 + + + +Babiarz, et al. Informational [Page 46] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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. + + + +Babiarz, et al. Informational [Page 47] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + 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. + + + + + + + +Babiarz, et al. Informational [Page 48] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Network Edge Conditioning: + + There is no requirement that conditioning of packet flows be + performed for this service class. + + The RECOMMENDED DSCP marking is CS1 (Class Selector 1). + + The fundamental service offered to the Low-Priority Data service + class is best-effort service with zero bandwidth assurance. By + placing it into a separate queue or class, it may be treated in a + manner consistent with a specific Service Level Agreement. + + Typical configurations SHOULD use Explicit Congestion Notification + [RFC3168] or random loss to implement Active Queue Management + [RFC2309]. + + If RED [RFC2309] is used as an AQM algorithm, the min-threshold + specifies a target queue depth, and the max-threshold specifies the + queue depth above which all traffic is dropped or ECN marked. Thus, + in this service class, the following inequality should hold in queue + configurations: + + o min-threshold CS1 < max-threshold CS1 + o max-threshold CS1 <= memory assigned to the queue + + Note: Many other AQM algorithms exist and are used; they should be + configured to achieve a similar result. + +5. Additional Information on Service Class Usage + + In this section, we provide additional information on how some + specific applications should be configured to use the defined service + classes. + +5.1. Mapping for Signaling + + There are many different signaling protocols, ways that signaling is + used and performance requirements from applications that are + controlled by these protocols. We believe that different signaling + protocols should use the service class that best meets the objectives + of application or service they control. The following mapping is + recommended: + + o Peer-to-peer signaling using SIP/H.323 is marked with CS5 DSCP + (use Signaling service class). + + + + + + +Babiarz, et al. Informational [Page 49] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + o Client-server signaling as used in many implementation for IP + telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN, or + proprietary protocols is marked with CS5 DSCP (use Signaling + service class). + o Signaling between call servers or soft-switches in carrier's + network using SIP, SIP-T, or IP encapsulated ISUP is marked with + CS5 DSCP (use Signaling service class). + o RSVP signaling depends on the application. If RSVP signaling is + "on-path" as used in IntServ, then it needs to be forwarded from + the same queue (service class) and marked with the same DSCP value + as application data that it is controlling. This may also apply + to the "on-path" Next Steps in Signaling (NSIS) protocol. + o If IGMP is used for multicast session control such as channel + changing in IPTV systems, then IGMP packets should be marked with + CS5 DSCP (use Signaling service class). When IGMP is used only + for the normal multicast routing purpose, it should be marked with + CS6 DSCP (use Network Control service class). + +5.2. Mapping for NTP + + From tests that were performed, indications are that precise time + distribution requires a very low packet delay variation (jitter) + transport. Therefore, we suggest that the following guidelines for + Network Time Protocol (NTP) be used: + + o When NTP is used for providing high-accuracy timing within an + administrator's (carrier's) network or to end users/clients, the + Telephony service class should be used, and NTP packets should be + marked with EF DSCP value. + o For applications that require "wall clock" timing accuracy, the + Standard service class should be used, and packets should be + marked with DF DSCP. + +5.3. VPN Service Mapping + + "Differentiated Services and Tunnels" [RFC2983] considers the + interaction of DiffServ architecture with IP tunnels of various + forms. Further to guidelines provided in RFC 2983, below are + additional guidelines for mapping service classes that are supported + in one part of the network into a VPN connection. This discussion is + limited to VPNs that use DiffServ technology for traffic + differentiation. + + o The DSCP value(s) that is/are used to represent a PHB or a PHB + group should be the same for the networks at both ends of the VPN + tunnel, unless remarking of DSCP is done as ingress/egress + processing function of the tunnel. DSCP marking needs to be + preserved end to end. + + + +Babiarz, et al. Informational [Page 50] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + o The VPN may be configured to support one or more service classes. + It is left up to the administrators of the two networks to agree + on the level of traffic differentiation that will be provided in + the network that supports VPN service. Service classes are then + mapped into the supported VPN traffic forwarding behaviors that + meet the traffic characteristics and performance requirements of + the encapsulated service classes. + o The traffic treatment in the network that is providing the VPN + service needs to be such that the encapsulated service class or + classes receive comparable behavior and performance in terms of + delay, jitter, and packet loss and that they are within the limits + of the service specified. + o The DSCP value in the external header of the packet forwarded + through the network providing the VPN service may be different + from the DSCP value that is used end to end for service + differentiation in the end network. + o The guidelines for aggregation of two or more service classes into + a single traffic forwarding treatment in the network that is + providing the VPN service is for further study. + +6. Security Considerations + + This document discusses policy and describes a common policy + configuration, for the use of a Differentiated Services Code Point by + transports and applications. If implemented as described, it should + require that the network do nothing that the network has not already + allowed. If that is the case, no new security issues should arise + from the use of such a policy. + + It is possible for the policy to be applied incorrectly, or for a + wrong policy to be applied in the network for the defined service + class. In that case, a policy issue exists that the network SHOULD + detect, assess, and deal with. This is a known security issue in any + network dependent on policy-directed behavior. + + A well-known flaw appears when bandwidth is reserved or enabled for a + service (for example, voice transport) and another service or an + attacking traffic stream uses it. This possibility is inherent in + DiffServ technology, which depends on appropriate packet markings. + When bandwidth reservation or a priority queuing system is used in a + vulnerable network, the use of authentication and flow admission is + recommended. To the author's knowledge, there is no known technical + way to respond to an unauthenticated data stream using service that + it is not intended to use, and such is the nature of the Internet. + + The use of a service class by a user is not an issue when the SLA + between the user and the network permits him to use it, or to use it + up to a stated rate. In such cases, simple policing is used in the + + + +Babiarz, et al. Informational [Page 51] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + Differentiated Services Architecture. Some service classes, such as + Network Control, are not permitted to be used by users at all; such + traffic should be dropped or remarked by ingress filters. Where + service classes are available under the SLA only to an authenticated + user rather than to the entire population of users, authentication + and authorization services are required, such as those surveyed in + [AUTHMECH]. + +7. Acknowledgements + + The authors thank the TSVWG reviewers, David Black, Brian E. + Carpenter, and Alan O'Neill for their review and input to this + document. + + The authors acknowledge a great many inputs, most notably from Bruce + Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet, + Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al + Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson, Mike + Fidler, and Shane Amante. Kimberly King, Joe Zebarth, and Alistair + Munroe each did a thorough proofreading, and the document is better + for their contributions. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Babiarz, et al. Informational [Page 52] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + +8. Appendix A + +8.1. Explanation of Ring Clipping + + The term "ring clipping" refers to those instances where the front + end of a ringing signal is altered because the bearer channel is not + made available in time to carry all the audible ringing signal. This + condition may occur due to a race condition between when the tone + generator located in the circuit switch Exchange is turned on and + when the bearer path through the IP network is enabled. To reduce + ring clipping from occurring, delay of signaling path needs to be + minimized. Below is a more detailed explanation. + + The bearer path setup delay target is defined as the ISUP Initial + Address Message (IAM) / Address Complete Message (ACM) round-trip + delay. ISUP refers to ISDN User Part of Signaling System No. 7 + (SS7), as defined by ITU-T. This consists of the amount of time it + takes for the ISUP Initial Address Message (IAM) to leave the Transit + Exchange, travel through the SS7 network (including any applicable + STPs, or Signaling Transfer Points), and be processed by the End + Exchange thus generating the Address Complete Message (ACM) and for + the ACM to travel back through the SS7 network and return to the + Transit Exchange. If the bearer path has not been set up within the + soft-switch media gateway and the IP network that is performing the + Transit Exchange function by the time the ACM is forwarded to the + originating End Exchange, the phenomenon known as ring clipping may + occur. If ACM processing within the soft-switch media gateway and + delay through the IP network is excessive, it will delay the setup of + the bearer path, and therefore may cause clipping of the ring tone to + be heard. + + The intra-exchange ISUP IAM signaling delay value should not exceed + 240ms. This may include soft-switch, media gateway, router, and + propagation delay on the inter-exchange data path. This value + represents the threshold where ring clipping theoretically commences. + It is important to note that the 240ms delay objective as presented + is a maximum value. Service administrators are free to choose + specific IAM delay values according to their own preferences (i.e., + they may wish to set a very low mean delay objective for strategic + reasons to differentiate themselves from other providers). In + summary, out of the 240-ms delay budget, 200ms is allocated as + cross-Exchange delay (soft-switch and media gateway) and 40ms for + network delay (queuing and distance). + + + + + + + + +Babiarz, et al. Informational [Page 53] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + +9. References + +9.1. Normative References + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September + 1981. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC1349] Almquist, P., "Type of Service in the Internet Protocol + Suite", RFC 1349, July 1992. + + [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC + 1812, June 1995. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, + S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., + Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, + S., Wroclawski, J., and L. Zhang, "Recommendations on + Queue Management and Congestion Avoidance in the + Internet", RFC 2309, April 1998. + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, December + 1998. + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., + and W. Weiss, "An Architecture for Differentiated + Service", RFC 2475, December 1998. + + [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, + "Assured Forwarding PHB Group", RFC 2597, June 1999. + + [RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le + Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. + Stiliadis, "An Expedited Forwarding PHB (Per-Hop + Behavior)", RFC 3246, March 2002. + + [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort + Per-Domain Behavior (PDB) for Differentiated Services", + RFC 3662, December 2003. + + + + + +Babiarz, et al. Informational [Page 54] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + +9.2. Informative References + + [AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms", + Work in Progress, September 2005. + + [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 + Technical Report Proposed Service Definition, March 2001. + + [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated + Services in the Internet Architecture: an Overview", RFC + 1633, June 1994. + + [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. + Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 + Functional Specification", RFC 2205, September 1997. + + [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion + Control", RFC 2581, April 1999. + + [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color + Marker", RFC 2697, September 1999. + + [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color + Marker", RFC 2698, September 1999. + + [RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper + for Differentiated Services", RFC 2963, October 2000. + + [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC + 2983, October 2000. + + [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, + November 2000. + + [RFC3086] Nichols, K. and B. Carpenter, "Definition of + Differentiated Services Per Domain Behaviors and Rules for + their Specification", RFC 3086, April 2001. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", RFC + 3168, September 2001. + + [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, + "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC + 3175, September 2001. + + + + + + +Babiarz, et al. Informational [Page 55] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + + [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An + Informal Management Model for Diffserv Routers", RFC 3290, + May 2002. + + [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno + Modification to TCP's Fast Recovery Algorithm", RFC 3782, + April 2004. + +Authors' Addresses + + Jozef Babiarz + Nortel Networks + 3500 Carling Avenue + Ottawa, Ont. K2H 8E9 + Canada + + Phone: +1-613-763-6098 + Fax: +1-613-765-7462 + EMail: babiarz@nortel.com + + + Kwok Ho Chan + Nortel Networks + 600 Technology Park Drive + Billerica, MA 01821 + US + + Phone: +1-978-288-8175 + Fax: +1-978-288-8700 + EMail: khchan@nortel.com + + + Fred Baker + Cisco Systems + 1121 Via Del Rey + Santa Barbara, CA 93117 + US + + Phone: +1-408-526-4257 + Fax: +1-413-473-2403 + EMail: fred@cisco.com + + + + + + + + + + +Babiarz, et al. Informational [Page 56] + +RFC 4594 Guidelines for DiffServ Service Classes August 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Babiarz, et al. Informational [Page 57] + |