Network WG James Polk, ed. Internet-Draft Cisco Intended status: Standards Track (PS) Oct 22, 2012 Obsoletes: RFC 4594 Updates: RFC 5865 Expires: April 22, 2013 Standard Configuration of DiffServ Service Classes draft-polk-tsvwg-rfc4594-update-02.txt Abstract This document describes service classes configured with DiffServ and identifies how they are 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 for consistent behavior under the same network conditions, configuring networks as described here is appropriate. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 22, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Polk Expires April 22, 2013 [Page 1] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ...................................................3 1.1. Requirements Notation .....................................8 1.2. Expected Use in the Network ...............................8 1.3. Service Class Definition ..................................8 1.4. Key Differentiated Services Concepts .....................10 1.4.1. Queuing .............................................10 1.4.1.1. Priority Queuing ...........................10 1.4.1.2. Rate Queuing ...............................11 1.4.2. Active Queue Management .............................11 1.4.3. Traffic Conditioning ................................12 1.4.4. Differentiated Services Code Point (DSCP) ...........12 1.4.5. Per-Hop Behavior (PHB) ..............................13 1.5. Key Service Concepts .....................................13 1.5.1. Default Forwarding (DF) .............................13 1.5.2. Assured Forwarding (AF) .............................14 1.5.3. Expedited Forwarding (EF) ...........................14 1.5.4. Class Selector (CS) .................................15 1.5.5. Admission Control ...................................15 2. Service Differentiation .......................................16 2.1. Service Classes ..........................................16 2.2. Categorization of User Oriented Service Classes ..........18 2.3. Service Class Characteristics ............................22 2.4. Service Classes vs. Treatment Aggregate (from RFC 5127)...27 2.4.1 Examples of Service Classes in Treatment Aggregates...29 3. Network Control Traffic .......................................31 3.1. Current Practice in the Internet .........................32 3.2. Network Control Service Class ............................32 3.3. OAM Service Class ........................................34 4. User Oriented Traffic .........................................36 4.1. Conversational Service Class Group .......................36 4.1.1 Audio Service Class ..................................37 4.1.2 Video Service Class ..................................40 4.1.3 Hi-Res Service Class .................................44 4.2. Realtime-Interactive Service Class ...................... 47 4.3. Multimedia Conferencing Service Class ....................50 4.4. Multimedia Streaming Service Class .......................52 4.5. Broadcast Video Service Class ............................55 4.6. Low-Latency Data Service Class ...........................58 4.7. Conversational Signaling Service Class ...................60 4.8. High-Throughput Data Service Class .......................62 4.9. Standard Service Class ...................................65 4.10. Low-Priority Data .......................................66 5. Additional Information on Service Class Usage .................67 5.1. Mapping for NTP ..........................................67 5.2. VPN Service Mapping ......................................67 Polk Expires April 22, 2013 [Page 2] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 6. Security Considerations .......................................68 7. Contributing Authors ..........................................68 8. Acknowledgements ..............................................69 9. References ....................................................70 9.1. Normative References .....................................70 9.2. Informative References ...................................71 Author's Address .................................................72 Appendix A - Changes .............................................72 1. Introduction Differentiated Services [RFC2474][RFC2475] provides the ability to mark/label/classify IP packets differently to distinguish how individual packets need to be treated differently through (or throughout) a network on a per hop basis. Local administrators are who configure each router for which Differentiated Services Code Points (DSCP) are to be treated differently, which are to be ignored (i.e., no differentiated treatment), and which DSCPs are to have their packets remarked (to different DSCPs) as they pass through a router. Local administrators are also who assign which applications, or traffic types, should use which DSCPs to receive the treatment the administrators expect within their network. What most people fail to understand is that DSCPs provide a per hop behavior (PHB) through that router, but not the previous or next router. In this way of understanding PHB markings, one can understand that Differentiated Services (DiffServ) is not a Quality of Service (QoS) mechanism, but rather a Classification of Service (CoS) mechanism. For instance, there are 64 possible DSCP values, i.e., using 6 bits of the old Type of Service (TOS) byte [RFC0791]. Each can be configured locally to have greater or less treatment relative to any other DSCP with two exceptions*. * Expedited Forwarding (EF) [RFC3246] DSCPs have a treatment requirement that any packet marked within an EF class has to be the next packet transmitted out its egress interface. If there are more than one EF marked packet in the queue, obviously the queue sets the order they are transmitted. Further, if there are more than one EF DSCP, local configuration determines if each are treated the same or differently relate to each other EF DSCP. Currently, there are two Expedited Forwarding DSCPs: EF (101110) [RFC3246] and VOICE-ADMIT (101100) [RFC5865]. * Class Selector 6 (CS6) [RFC2474] is for routing protocol traffic. There are deemed important because if the network does not transmit and receive its routing protocol traffic in a timely manner, the network stops operating properly. Polk Expires April 22, 2013 [Page 3] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 Not all are configured to mean anything other than best effort forwarding by local administrators of a network. Let us say there are 5 DSCPs configured within network A. Network A's administrator chooses and configures which order (obeying the two exceptions noted above) which application packets are treated differently than any other packets within that network (A). The DSCPs are not fixed to a linear order for relative priority on a per hop basis. Further, and this is often the case, there might be packets with the same DSCP arriving at multiple interfaces of a node, each egressing that node out the same interface. At ingress to this node, everything was fine, with no poor behavior or noticeably excessive amount of packets with the same DSCP. However, at the egress interface, there might not be enough capacity to satisfy the load, thus the departing packets transmit at their maximum rate for that DSCP, but have additional latency due to the overload within that one node. This is called fan-in congestion (or problem). By itself, DiffServ will not remedy this problem for the application that is intolerant to added latency because DiffServ only functions within 1 node at a time. An additional mechanism is needed to ensure each flow or session receives the amount of packets at its destination that the application requires to perform properly; a mechanism such as IntServ, by way of RSVP [RFC2205] or NSIS [RFC4080]. With this added capability to be session aware, something DiffServ is not, the packets transmitted within a single session have a very good probability of arriving in such a way the receiving application can make full use of each. That said, signaling reservations for each session or flow adds complexity, which creates more work for those who maintain and administer such a network. Adding bandwidth and using DiffServ marking is an easier pill to swallow. The deployment of not few, but more and more audio and (particularly bandwidth hogging) video codecs and their respective application rigidity has caused some to conclude that throwing bandwidth at the problem is no longer acceptable. With this in mind, this document incorporates five of the six new DSCPs from [ID-DSCP] identified as capacity-admitted DSCPs for most of the service classes in this document. As explained in [ID-DSCP], the five new capacity-admitted DSCPs are from Pool 3. [ID-DSCP] goes further to explain that many layer 2 technologies use fewer bits for marking and prioritization. Instead of six bits like DiffServ, they have three bits, which yields a maximum of 8 values, which tend to line up quite will with the TOS field values. Thus, aggregation of DSCPs is typically accomplished by simply ignoring or reducing the number of bits used to the most significant ones available, such as EF is 101110, at layer 2 this is merely 101; Broadcast is 011000, at layer 2 this is merely 011. However, that was not a premise DiffServ was built upon, to merely reduce the number of bits. In other words, within DiffServ, XXX is Polk Expires April 22, 2013 [Page 4] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 not the same as XXX000 (where XXX is the same binary value in both cases). This document is originally built upon the RFC 4594 effort, while updating some of the usages and expanding the scope for newer applications that are in use today. The idea in RFC 4594 remains true here, to define a set of service classes, each having unique traffic characteristics, and assigning one or more DSCPs to each service class. As much as the focus could be on the DSCP values, it is not. The focus of this document is the unique traffic characteristics of each service class. There are many services classes defined in this document, not all will be used in each network at any period of time. This consistency packet markings we talk about is for several reasons, including in a network that does not currently implement a certain service class because they do not have that type of traffic in their network, or that the network merely gives that traffic best effort service. Having a solid guideline to know where to progress or reconfigure a network and endpoints to, say from best effort for a particular traffic type, is a very good thing to do more uniformly than not. A fair amount of burden is placed at DS boundaries needing to keep up with which markings turn into which other markings at both ingress and egress to a network. The same holds true for application developers choosing a default DSCP for their application, lacking a guideline means everyone picks for themselves - and usually with a highly inflated sense of self importance for their application or service. Another point to make is that there are 20+ service classes defined within the IETF, and that is far too many for most service providers to manage effectively. So, they have formed groups around certain aggregation solutions of service classes. One such aggregation group is based on RFC 5127, which defines what it calls a treatment aggregate, which is taking RFC 4594's service classes and placing them each into one of four treatment aggregates for service providers to handle as a group. SG12 within the ITU-T has an alternative that has nine aggregate groups, so there is work to be done to harmonize aggregates of service classes. This discussion is articulated more in section 2.4. At the end of Section 2.4 we have introduced a series of example configurations which provide examples of how only a few service classes - yet still most treatment aggregates - can be configured in example networks. Does RFC 4594 need updating? That document is an informational guideline on how networks can or should mark certain packet flows with differing traffic characteristics using DiffServ. There are several reasons why this informational RFC lacks the necessary clarity and strength to reach widespread adoption: o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of which is for aggregating many 6-bit DSCP values into a 3-bit (8 Polk Expires April 22, 2013 [Page 5] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 value) field used specifically by service provider (SP) networks. o some believe both RFCs are for SPs, while others ignore RFC 5127 and use RFC 4594 as if it were standards track or BCP. o some believe RFC 5127 is for SPs only, and want RFC 4594 to reduce the number of DSCPs within its guidelines to recommend using only 3 or 4 DSCPs. This seems to stem from a manageability and operational perspective. o some know RFC 4594 is informational and do not follow its guidelines specifically because it is informational. o some use DSCP values that are not defined within RFC 4594, making mapping between different networks using similar or identical application flows difficult. o some believe enterprise networks should not use either RFC except at the edge of their networks, where they directly connect to SP networks. o some argue that the services classes guidance per class is too broad and are therefore not sure in which service class a particular application is to reside. o time has shown that video has become a dominant application on the Internet, and many believe it now requires to be treated uniquely in environments that want to. Video also does not always plan nice with audio, so knowing the two use the same transport (RTP) [RFC3550], a means of separation is in order. Service class definitions are based on the different traffic characteristics and required performance of the applications/services. There are a greater number of service classes in this document than there were when RFC 4594 [RFC4594] was published (the RFC this document intends to obsolete). The required performance of applications/services has also changed since the publication of RFC 4594, specifically in the area of conversational real time communications. As a result, this document has a greater number of real time applications with more granular set of DSCPs due to their different required performances. Like RFC 4594 before, this approach allows those applications with similar traffic characteristics and performance requirements to be placed in the same service class. The notion of traffic characteristics and required performance is a per application concept, therefore the label name of each service class remains the same on an end-to-end basis, even if we understand that DiffServ is only a PHB and cannot guarantee anything, even packet delivery at the intended destination node. That said, several applications can be configured to have the same DSCP, or each have different DSCPs that have the same treatment per hop Polk Expires April 22, 2013 [Page 6] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 within a network. Since RFC 4594 was first published, a new concept has been introduced that will appear throughout this document, including DSCP assignments -- the idea of "admitted" traffic, initially introduced into DiffServ within RFC 5865 [RFC5865]. The VOICE-ADMIT Expedited Forwarding class differentiates itself from the EF Expedited Forwarding by having the packets marked be for admitted traffic. This concept of "admitted" traffic is spread throughout the real time traffic classes. Thus, the document flow is as follows: o maintain the general format of RFC 4594; o augment the content with the concept of capacity-admission; o incorporate much more video into this document, as it has become a dominant application in enterprises and other managed networks, as well as on the open public Internet; o reduce the discussion on voice and its examples; o articulate the subtle differences learned since RFC 4594 was published. The goal here is to provide a standard configuration for DiffServ DSCP assignments and expected PHBs for enterprises and other managed networks, as well as towards the public Internet with specific traffic characteristics per Service class/DSCP, and example applications shown for each. This document describes service classes configured with DiffServ and defines how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), and recommends how to construct them using traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There is no intrinsic requirement that particular 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. This document explicitly states there is a fundamental requirement that a particular DSCP or DSCPs be used for each service class. We differentiate services and their characteristics in Section 2. Network control traffic, as well as user oriented traffic are discussed in Sections 3 and 4, respectively. We analyze the security considerations in Section 6. Section 7 offers a tribute to the authors of RFC 4594, from which this document is based. It is in its own section, and not part of the normal acknowledgements portion of each IETF document. Polk Expires April 22, 2013 [Page 7] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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] when they appear in ALL CAPS. These words may also appear in this document in lower case as plain English words, absent their normative meanings. 1.2. Expected Use in the Network In the Internet today, corporate LANs and ISP WANs are increasingly utilized, to the point in which network congestion is affecting performance of applications. For this reason, congestion, loss, and variation in delay within corporate LANs and ISP backbones is becoming known to the users collectively as "the network is slow for this application" or just "right now" or "for today". Users do not directly detect network congestion. They react to applications that run slow, or to downloads that take too long in their mind(s). The explosion of video traffic on the internet recently has cause much of this, and is often the application the user is using when they have this slowness. In the past, application slowness occurred for three very good reasons. o the networks the user oriented traffic traverses moves through cycles of bandwidth boom and bandwidth bust, the latter of which become apparent with 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 standardized marking, plus a conditioning and packet treatment strategy so that it can be configured and put into service on any link that is itself congested. 1.3. Service Class Definition A "service class" represents a similar set of traffic characteristics for delay, loss, and jitter as packets traverse routers in a network. For example, "High-Throughput Data" service class for store-and-forward applications, or a "Broadcast" service Polk Expires April 22, 2013 [Page 8] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 class for minimally time-shifted IPTV or Internet radio broadcasts. 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 goal of this document is to have most/all networks assign the same type of traffic the same for consistency. A service class is a naming convention which is defined as a word, phrase or initialism/acronym representing a set of necessary traffic characteristics of a certain type of data flow. The necessary characteristics of these traffic flows can be realized by the use of defined per-hop behavior that started with [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 will locally choose to o implement one or more service classes with traffic characteristics as defined here, or o implement one or more service classes with similar traffic characteristics as defined here, or o implement one or more service classes with similar traffic characteristics as defined here and to aggregate one or more service classes to reduce the number of unique DSCPs within their network, or o implement one or more non-standard service classes with traffic characteristics not as defined here, or o not use DiffServ within their domain. For example, low delay, low loss, and minimal 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. If the packet sizes are similar within an application, but different between two applications, say small voice packets and large video packets, these two applications may not realize optimum results if merged into the same aggregate if there are any bottlenecks in the network. We provide for this flexibility on a per hop or per domain basis within this document. This document provides standardized markings for traffic with similar characteristics, and usage expectations for PHBs for specific service classes for their consistent implementation. The Default Forwarding "Standard" service class is REQUIRED; all other service classes are OPTIONAL. That said, each service class lists traffic characteristics that are expected when using that type of traffic. It is RECOMMENDED that applications and protocols that fit a certain traffic characteristic use the appropriate service Polk Expires April 22, 2013 [Page 9] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 class mark, i.e., the DSCP, for consistent behavior. It is expected that network administrators will base their endpoint application and router configuration choices on the level of service differentiation they require to meet the needs of their customers (i.e., their end-users). 1.4. Key Differentiated Services Concepts In order to fully understand this document, a reader needs to familiarize themselves with the principles of the Differentiated Services Architecture [RFC2474]. We summarize some key concepts here only to provide convenience for the reader, the referenced RFCs providing the authoritative definitions. 1.4.1. Queuing A queue is a data structure that holds packets that are awaiting transmission. A router interface can only transmit one packet at a time, however fast the interface speed is. If there is only 1 queue at an interface, the packets are transmitted in the order they are received into that queue - called FIFO, or "first in, first out". Sometimes there is a lag in the time between a packets arrives in the queue and when it is transmitted. This delay might be due to lack of bandwidth, or if there are multiple queues on that interface, because a packet is low in priority relative to other packets that are awaiting to transmit. The scheduler is the system entity that chooses which packet is next in line for transmission when more than one packet are awaiting transmission out the same router interface. 1.4.1.1 Priority Queuing A priority queuing system is a combination of a set of queues and a scheduler that empties the queues (of packets) 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. Polk Expires April 22, 2013 [Page 10] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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 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. Polk Expires April 22, 2013 [Page 11] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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. 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. These are divided into 3 groups, or pools, defined in RFC 2474, arranged as follows: o Pool-1 has 32 values designated for standards assignment (of the form 'xxxxx0'). o Pool-2 has 16 values designated for experimental or local use only (EXP/LU) assignment (of the form 'xxxx11'). o Pool-3 has 16 values designated for experimental or local use (EXP/LU) assignment (of the form 'xxxx01'). Polk Expires April 22, 2013 [Page 12] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 However, pool-3 is allowed to be assigned for one of two reasons, #1 - if the values in pool-1 are exhausted, or #2 - if there is a justifiable reason for assigning a pool-3 DSCP prior to pool-1's exhaustion. 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. 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 Polk Expires April 22, 2013 [Page 13] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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. 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. Polk Expires April 22, 2013 [Page 14] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 1.5.4 Class Selector (CS) Class Selector, those DSCPs that end in zeros (xxx000), provide support for historical codepoint definitions and PHB requirement. The CS fields provide a limited backward compatibility with legacy 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 - this document will continue to permit their use in DS-compliant networks. In addition, there are some DSCPs that correspond to historical use of the IP Precedence field, - CS0 (000000) will remain 'Default Forwarding' (also know as 'Best Effort') - 11xxxx will remain for routing traffic and will 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 exclusively by using one or more CS-compliant PHB groups. Thus, for example, codepoint '011000' would map to the same PHB as codepoint '011010'. 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) (audio) or video conferencing services can benefit from use of an admission control mechanism, as generally the audio or video service is configured with over-subscription, meaning that some users may not be able to make a call during peak periods. For VoIP (audio) service, a common approach is to use signaling protocols such as SIP, H.323, H.248, MEGACO, along with 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. Polk Expires April 22, 2013 [Page 15] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 Many RTP voice and video payloads are inelastic and cannot react to loss or delay in any substantive way. For these payload types, the network needs to 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. 1.5.5.1 Capacity Admitted (*-Admit) This is a newer group of traffic types that started with RFC 5865 and the Voice-Admit service type. Voice-Admit is an EF class marking but has capacity-admission always applied to it to ensure each of these flows are managed through a network, though not necessarily on an end-to-end basis. This depends on how many networks each flow transits and the load on each transited network. There are a series of new DSCPs proposed in [ID-DSCP], each specifying unique characteristics necessitating a separate marking from what existing before that document. This document will import in four new '*-Admit' DSCPs from [ID-DSCP], 2 others that are new but not capacity-admitted, one from RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594. This is discussed throughout the rest of this document. 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. 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 Polk Expires April 22, 2013 [Page 16] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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 Conversational service group consists of three service classes: - Audio, which includes both 'admitted' and 'unadmitted' audio service classes, is for non-one way (i.e., generally bidirectional) audio media packets between human users of smaller size and at a constant delivery rate. - Hi-Res Video, which includes both 'admitted' and 'unadmitted' Hi-Res Video service classes, is for video traffic from higher end endpoints between human users necessitating different treatment that from desktop or video phone endpoints. This has a clearly business differentiation, and not a technical differentiation - as both Hi-Res-Video and Video will be treated similarly on the wire when no congestion occurs. - Video, which includes both 'admitted' and 'unadmitted' video service classes, is for video traffic from lower end endpoints between human users necessitating different treatment that from higher end (i.e., Telepresence) endpoints. This has a clearly business differentiation, and not a technical differentiation - as both Hi-Res-Video and Video will be treated similarly on the wire when no congestion occurs. o Conversational Signaling service class is for peer-to-peer and client-server signaling and control functions using protocols such as SIP, H.323, H.248, and Media Gateway Control Protocol (MGCP). This traffic needs to not be starved on the network. Editor's note: RFC 4594 had this DSCP marking as CS5, but with clearly different characteristics (i.e., no sensitivity to jitter or (unreasonable) delay), this DSCP has been moved to a more appropriate (new) value, defined in [ID-DSCP]. o Real-Time Interactive, which includes both 'admitted' and 'unadmitted' Realtime-Interactive service class, is for bidirectional 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 Virtualized Desktop applications between the user Polk Expires April 22, 2013 [Page 17] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 and content source, typically in a centralized data center. o Multimedia Conferencing, which includes both 'admitted' and 'unadmitted' multimedia conferencing service class, is for applications that require minimal delay, but not like those of realtime application requirements. This service class can be bursty in nature, as well as not transmit packets for some time. Applications such as presentation data or collaborative application sharing will use this service class. o Multimedia Streaming, which includes both 'admitted' and 'unadmitted' multimedia streaming service class, is for one-way bufferable streaming media applications such as Video on Demand (VOD) and webcasts. o Broadcast, which includes both 'admitted' and 'unadmitted' broadcast service class, is 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. o Low-Latency Data service class is for data processing applications such as client/server interactions or Instant Messaging (IM) and Presence data. o Conversational Signaling (A/V-Sig) service class is for all signaling messages, whether in-band (i.e., along the data path) or out-of-band (separate from the data path), for the purposes of setting up, maintaining, managing and terminating bi- or multi-directional realtime sessions. o High-Throughput Data service class is for store and forward applications such as FTP and billing record transfer. o Standard service class, commonly called best effort (BE), is for traffic that has not been identified as requiring differentiated treatment. o Low-Priority Data service class, which some could call the scavenger class, is for packet flows where bandwidth assurance is not required. 2.2 Categorization of User Oriented 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. Polk Expires April 22, 2013 [Page 18] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 Application Control Category o The Conversational 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, XMPP or H.323 for voice and/or video over IP services. User signaling flows have similar performance requirements as Low-Latency Data, they require a separate DSCP to be distinguished other traffic and allow for a treatment that is unique. 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, seven service classes have been defined. o Audio service class is intended for Voice-over-IP (VoIP) services. It may also be used for other applications that meet the defined traffic characteristics and performance requirements. o Video service class is intended for Video over IP services. It may also be used for other applications that meet the defined traffic characteristics and performance requirements. o Hi-Res service class is intended for higher end video services that have the same traffic characteristics as the video service class, but have a business requirement(s) to be treated differently. One example of this is Telepresence video applications. o Realtime-Interactive service class is intended for inelastic applications such as desktop virtualization applications and for interactive gaming. o Multimedia Conferencing service class is for everything about or within video conferencing solutions that does not include the voice or (human) video components. Several examples are - the presentation data part of an IP conference (call). - the application sharing part of an IP conference (call). - the whiteboarding aspect of an IP conference (call). Each of the above can be part of a lower end web-conferencing application or part of a higher end Telepresence video conference. Each also has the ability to reduce their transmission rate on detection of congestion. These flows can therefore be classified as rate adaptive and most often more elastic than their voice and video counterparts. Polk Expires April 22, 2013 [Page 19] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 o Broadcast Video service class is to be used for inelastic traffic flows specifically with minimal buffering expected by the source or destination, which are intended for broadcast HDTV service, as well as for transport of live video (sports or concerts) and audio events. o Multimedia Streaming service class is to be used for elastic multimedia traffic flows where buffering is expected. This is the fundamental difference between the Broadcast and multimedia streaming service classes. Multimedia streaming 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. 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 Class of Service (CoS) rating as defined in ITU-T Recommendation G.1010. Polk Expires April 22, 2013 [Page 20] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 ----------------------------------------------------------------- | Application | Service | Signaled | Flow | G.1010 | | Categories | Class | | Behavior | Rating | |-------------+---------------+----------+-----------+------------| | Application | A/V Sig | Not | Inelastic | Responsive | | Control | |applicable| | | |-------------+---------------+----------+-----------+------------| | | Realtime | Yes | Inelastic | Interactive| | | Interactive | | | | | |---------------+----------+-----------+------------| | | Audio | Yes | Inelastic | Interactive| | |---------------+----------+-----------+------------| | | Video | Yes | Inelastic | Interactive| | |---------------+----------+-----------+------------| | | Hi-Res | Yes | Inelastic | Interactive| | |---------------+----------+-----------+------------| | Media- | Multimedia | Yes | Rate | Moderately | | Oriented | Conferencing| | Adaptive | Interactive| | |---------------+----------+-----------+------------| | | Broadcast | Yes | Inelastic | Responsive | | |---------------+----------+-----------+------------| | | Multimedia | Yes | Elastic | Timely | | | Streaming | | | | |-------------+---------------+----------+-----------+------------| | | Low-Latency | No | Elastic | Responsive | | | Data | | | | | |---------------+----------+-----------+------------| | Data | Conversational| No |Elastic or | Timely | | | Signaling | | Inelastic | | | |---------------+----------+-----------+------------| High- | No | Elastic | Timely | | |Throughput Data| | | | | |---------------+----------+-----------+------------| | | Low- | No | Elastic |Non-critical| | | Priority Data | | | | |-------------+---------------+----------+-----------+------------| | Best Effort | Standard | Not Specified |Non-critical| ----------------------------------------------------------------- Figure 1. User/Subscriber Service Classes Grouping Here is a short explanation of the end user CoS category as defined in ITU-T Recommendation G.1010. User oriented 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 Polk Expires April 22, 2013 [Page 21] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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 specifies what network administrators are to expect when configuring service classes identified by their differing characteristics. Figure 2 identifies these service classes along with their characteristics, as well as the tolerance to loss, delay and jitter for each service class. Properly engineered networks to these PHBs will achieve expected results. That said, not all of the identified service classes are expected in each operator's network. ------------------------------------------------------------------- |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) | | | | |---------------+------------------------------+------+------+------| | Realtime | Inelastic, mostly variable | Low | Very | Low | | Interactive | rate | | Low | | +---------------+------------------------------+------+------+------+ | | Fixed-size small packets, | Very | Very | Very | | Audio | inelastic | Low | Low | Low | | | | | | | +---------------+------------------------------+------+------+------+ | | Fixed-size small-large | Very | Very | Very | | Video | packets, inelastic | Low | Low | Low | | | | | | | +---------------+------------------------------+------+------+------+ | | Fixed-size small-large | Very | Very | Very | | Hi-Res A/V | packets, inelastic | Low | Low | Low | | | | | | | +---------------+------------------------------+------+------+------+ | Multimedia | Variable size packets, | Low | Low | Low | | Conferencing | constant transmit interval, | - | - | - | | | rate adaptive, reacts to loss|Medium|Medium|Medium| +---------------+------------------------------+------+------+------+ | Multimedia | Variable size packets, |Low - |Medium| High | | Streaming | elastic with variable rate |Medium| | | +---------------+------------------------------+------+------+------+ | Broadcast | Constant and variable rate, | Very |Medium| Low | | | inelastic, non-bursty flows | Low | | | +---------------+------------------------------+------+------+------+ | Low-Latency | Variable rate, bursty short- | Low |Low - | Yes | | Data | lived elastic flows | |Medium| | |---------------+------------------------------+------+------+------| Polk Expires April 22, 2013 [Page 22] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 |Conversational | Variable size packets, some | Low | Low | Yes | | Signaling | what bursty short-lived flows| | | | |---------------+------------------------------+------+------+------| | OAM | Variable size packets, | Low |Medium| Yes | | | elastic & inelastic flows | | | | |---------------+------------------------------+------+------+------| | High- | Variable rate, bursty long- | Low |Medium| Yes | |Throughput 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 Notes for Figure 2: A "Yes" in the jitter-tolerant column implies that received data is buffered at the endpoint and that a moderate level of server or network-induced variation in delay is not expected to affect the application. Applications that use TCP or SCTP 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, and/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 oriented 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. +------------------------------------------------------------------+ | Service | DSCP | DSCP | Application | | Class Name | Name | Value | Examples | |===============+=========+=============+==========================| |Network Control| CS6&CS7 | 11xxxx | Network routing | |---------------+---------+-------------+--------------------------| | Realtime | CS5, | 101000, | Remote/Virtual Desktop | Polk Expires April 22, 2013 [Page 23] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 | Interactive |CS5-Admit| 101001 | and Interactive gaming | |---------------+---------+-------------+--------------------------| | Audio | EF | 101110 | Voice bearer | | |Voice-Admit| 101100 | | |---------------+---------+-------------+--------------------------| | Hi-Res A/V | CS4, | 100000, | Conversational Hi-Res | | |CS4-Admit| 100001 | Audio/Video bearer | |---------------+---------+-------------+--------------------------| | Video |AF41,AF42|100010,100100| Audio/Video conferencing | | | AF43 | 100110 | bearer | |---------------+---------+-------------+--------------------------| | Multimedia | MC, | 011101, | Presentation Data and | | Conferencing | MC-Admit| 100101 | App Sharing/Whiteboarding| |---------------+---------+-------------+--------------------------| | Multimedia |AF31,AF32|011010,011100| Streaming video and | | Streaming | AF33 | 011110 | audio on demand | |---------------+---------+-------------+--------------------------| | Broadcast | CS3, | 011000, | Broadcast TV, live events| | |CS3-Admit| 011001 | & video surveillance | |---------------+---------+-------------+--------------------------| | Low-Latency |AF21,AF22|010010,010100|Client/server trans., Web-| | Data | AF23 | 010110 |based ordering, IM/Pres | |---------------+---------+-------------+--------------------------| |Conversational | A/V-Sig | 010001 | Conversational signaling | | Signaling | | | | |---------------+---------+-------------+--------------------------| | OAM | CS2 | 010000 | OAM&P | |---------------+---------+-------------+--------------------------| |High-Throughput|AF11,AF12|001010,001100| Store and forward | | Data | AF13 | 001110 | applications | |---------------+---------+-------------+--------------------------| | Low-Priority | CS1 | 001000 | Any flow that has no BW | | Data | | | assurance | |------------------------------------------------------------------| | Best Effort | CS0 | 000000 | Undifferentiated | | | | | applications | +---------------+---------+-------------+--------------------------+ Figure 3. DSCP to Service Class Mapping Notes for Figure 3: o Default Forwarding (DF) and Class Selector 0 (CS0) (i.e., Best Effort) provide equivalent behavior and use the same DS codepoint, '000000'. o RFC 2474 identifies any DSCP with a value of 11xxxx to be for network control. This remains true, while it removes 12 DSCPs from the overall pool of 64 available DSCP values (the 4 that are x11 from this group are within pool 2 of RFC 2474, and remain as only experimentally assignable/useable). Polk Expires April 22, 2013 [Page 24] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 o All PHB names that say "-Admit" are to be used only when a capacity-admission protocol is utilized for that or each traffic flow. Changes from table 3 of RFC 4594 are as follows: o The old term "Signaling" was using CS5 (101000), now is exclusively for the "Conversational Signaling" service group using the DSCP name of "A/V-Sig" (010001), which is newly defined in [ID-DSCP]. This is because CS5 aggregates into the 101xxx aggregate when using layer 2 technologies such as 802.3 Ethernet, 802.11 Wireless Ethernet MPLS, etc - each of which only have 3 bits to mark with. A traffic type that can have very large packets and is not delay sensitive (within reason) is not appropriate for have a 101xxx marking. A REQUIRED behavior for this PHB is that it not be starved in any node. o "Conversational" is a new term to include all interactive audio and video. The Conversational service group consists of the audio service class, the video service class and the new Hi-Res service class. o "Audio" obsoletes the term "Telephony", which has generally not retained the "video" aspect within the IETF, where video is still commonly called out as a separate thing. Audio retains the nonadmitted traffic PHB of EF (101110), while capacity-admitted audio has been added via the RFC 5865 defined PHB Voice-Admit. o "Video" now is AF4x, with AF41 specifically for capacity-admitted video traffic, while AF42 and AF43 are nonadmitted video traffic. o "Hi-Res A/V", part of the Conversational service group, is created by [ID-DSCP] for an additional business differentiation interactive video marking for higher end traffic. It is within the 100xxx as CS4 (for nonadmitted traffic) and CS4-Admit (100001) (for capacity-admitted traffic). o "Realtime Interactive" is now using CS5 (for nonadmitted traffic), but adds a capacity-admitted DSCP CS5-Admit (101001). o "Multimedia Conferencing" is no longer using the AF4x DSCPs, rather it will use the new PHB MC (100101) (for capacity-admitted) and MC-Admit (011101) (for nonadmitted traffic). o "Multimedia Streaming" retains using AF3x, however, AF31 is now used for capacity-admitted traffic, while AF32/33 are nonadmitted. o "Broadcast" replaces "Broadcast Video" using CS3 (for nonadmitted traffic), and adds a capacity-admitted PHB CS3-Admit (011001). Polk Expires April 22, 2013 [Page 25] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 It is expected that network administrators will base their choice of the service classes that they will support on their need. Figure 4 provides a summary of DiffServ CoS mechanisms that MUST 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 MAY 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/CS7| See Section 3.1 |RFC2474| Rate | Yes| |---------------+-------+-------------------+-------+--------+----| | Realtime | CS5, |Police using sr+bs |RFC2474| Rate | No | | Interactive | CS5- | | | | | | | Admit*| |[ID-DSCP]| | | |---------------+-------+-------------------+-------+--------+----| | | EF, |Police using sr+bs |RFC3246|Priority| No | | Audio |Voice- | | | | | | | Admit*| |RFC5865| | | |---------------+-------+-------------------+-------+--------+----| | | CS4, |Police using sr+bs |RFC2474|Priority| No | | Hi-Res A/V | CS4- | | | | | | | Admit*| |[ID-DSCP]| | | |---------------+-------+-------------------+-------+--------+----| | | AF41*,| Using two-rate, | | | Yes| | Video | AF42 |three-color marker |RFC2597| Rate | per| | | AF43 | (such as RFC 2698)| | |DSCP| |---------------+-------+-------------------+-------+--------+----| | Multimedia | MC, |Police using sr+bs|[ID-DSCP]| Rate | No | | Conferencing | MC- | | | | | | | Admit*| |[ID-DSCP]| | | |---------------+-------+-------------------+-------+--------+----| | Multimedia | AF31*,| Using two-rate, | | | Yes| | Streaming | AF32 |three-color marker |RFC2597| Rate | per| | | AF33 | (such as RFC 2698)| | |DSCP| |---------------+-------+-------------------+-------+--------+----| | Broadcast | CS3, |Police using sr+bs |RFC2474| Rate | No | | | CS3- | | | | | | | Admit*| |[ID-DSCP]| | | |---------------+-------+-------------------+-------+--------+----| | Low- | AF21 | Using single-rate,| | | Yes| | Latency | AF22 |three-color marker |RFC2597| Rate | per| | Data | AF23 | (such as RFC 2697)| | |DSCP| |---------------+-------+-------------------+-------+--------+----| |Conversational |AV-Sig |Police using sr+bs|[ID-DSCP]| Rate | No | | Signaling | | | | | | |---------------+-------+-------------------+-------+--------+----| | OAM | CS2 |Police using sr+bs |RFC2474| Rate | Yes| Polk Expires April 22, 2013 [Page 26] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 |---------------+-------+-------------------+-------+--------+----| | 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 CoS Mechanisms Used for Each Service Class * denotes each DSCP identified for capacity-admission traffic only. 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 to two different administrative 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 Realtime-Interactive service class SHOULD be configured to provide high bandwidth assurance. It MAY be configured as another EF PHB (one capacity-admitted and one non-capacity-admitted, if both are to be used) that uses relaxed performance parameters and a rate scheduler. o The PHB for Multimedia Conferencing service class SHOULD be configured to provide high bandwidth assurance. It MAY be configured as another EF PHB (one capacity-admitted and one non-capacity-admitted, if both are to be used) that uses relaxed performance parameters and a rate scheduler. o The PHB for Broadcast service class SHOULD be configured to provide high bandwidth assurance. It MAY be configured as another EF PHB (one capacity-admitted and one non-capacity-admitted, if both are to be used) that uses relaxed performance parameters and a rate scheduler. 2.4. Service Classes vs. Treatment Aggregates (from RFC 5127) There are misconceptions about the differences between RFC 4594 specified service classes, and RFC 5127 specified treatment Polk Expires April 22, 2013 [Page 27] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 aggregates. Often the two are conflated, and more often the phrase service class is used to mean both definitions. Almost all of the text previous to this section is used in defining service classes, and how one service class is different than another service class (based on traffic characteristics of the applications). Treatment aggregates are groupings of service classes with similar, but not identical, traffic characteristics to give similar treatment from a SP's network. Below is taken from appendix of RFC 5127 as its recommended groupings of service classes into aggregates based in RFC 4594 specified traffic characteristic expectations. +------------------------------------------------------------+ |Treatment |Treatment || DSCP | |Aggregate |Aggregate || | | |Behavior || | |==========+==========++=====================================| | Network | CS || CS6 | | Control |(RFC 2474)|| | |==========+==========++=====================================| | Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | | Time* |(RFC 3246)|| | |==========+==========++=====================================| | Assured | AF || CS2, AF31, AF21, AF11 | | Elastic |(RFC 2597)||-------------------------------------| | | || AF32, AF22, AF12 | | | ||-------------------------------------| | | || AF33, AF23, AF13 | |==========+==========++=====================================| | Elastic | Default || Default, (CS0) | | |(RFC 2474)||-------------------------------------| | | || CS1 | +------------------------------------------------------------+ Figure 5: RFC 5127 Defined Treatment Aggregate Behavior** *NOTE: The RFC 5865 created VOICE-ADMIT is absence from the above figure because VOICE-ADMIT was created far later than this recommendation was. VOICE-ADMIT is appropriate for the Realtime Traffic Aggregate. **NOTE: Figure 5 is directly from the appendix of RFC 5127 as that RFC's recommendation for configuration. This draft does not directly affect RFC 5127. That is left for an update to RFC 5127 itself. Based on the WG's take on this draft, RFC 5127 will necessitate an update to match this document's new service classes and additional DSCPs. The number of treatment aggregates are not expected to change in the RFC 5127 Update draft though, with the possible exception of a new treatment aggregate for capacity admitted flows; meaning there *might* be a 5th treatment aggregate proposed. Polk Expires April 22, 2013 [Page 28] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 Treatment Aggregates are designed to nicely fit into technologies that do not have many different treatment levels to use. Here are 3 examples of technologies limited to an 8-value field, - MPLS with its 3 Traffic Class (TC) bits [RFC5462]. - IEEE LANs with its 8-value Priority Code Point (PCP) field, as part of the 802.1Q header spec [IEEE1Q]. - IEEE 802.1e, which defines QoS over Wi-Fi, also only defines 8 levels (called User Priority or UP codes) [IEEE1E]. Treatment Aggregates are dependent on service classes to exist. Therefore many service classes can exist without the need to consider the use of treatment aggregates or their 8-value technologies. For example, a Layer 3 VPN can be all that is needed to transit traffic flows, regardless of desired treatment, between enterprise LAN campuses. From this reality, the number of treatment aggregates has no direct bearing on the number of service classes. 2.4.1 Examples of Service Classes in Treatment Aggregates It is *not* expected that all traffic characteristics are to be experienced across an SP's network for any given customer. For example, if VOICE-ADMIT is added to the Realtime Treatment Aggregate in Figure 5, there are 8 different service classes within the Realtime Treatment Aggregate. It is not expected that all 8 service classes will be deployed by customer networks traversing SP networks. RFC 5127's Treatment Aggregates are a table to configure which service class goes into which treatment aggregate. If there are 8 services classes in the Realtime treatment aggregate, there is very little difference than if there were one service within that same Realtime treatment aggregate - it would still be necessary to configure that treatment aggregate. Thus, it becomes a question of not "how many service classes are there that go into treatment aggregates?" but "how many treatment aggregates have one or more services classes requiring configuration"? Of the 4 treatment aggregates shown in Figure 5, if there are existing service classes in only 3 of the aggregates, then only 3 treatment aggregates are necessary. Of the 3 following examples, notice that examples 2 and 3 have the same number of treatment aggregates, but example 3 has more applications in their own service classes. Polk Expires April 22, 2013 [Page 29] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 Examples 2 and 3 are made under the following assumptions: - this draft's Service Classes and DSCP assignments are utilized. - the new AF-Sig DSCP in the Assured Elastic treatment aggregate. - the Audio, Video service classes are in the EF treatment aggregate. - the VOICE-ADMIT DSCP is in the EF treatment aggregate. 2.4.1.1 Example 1 - Simple Voice Configuration/SLA For example 1, we have an SP running MPLS and has an SLA to deliver Network Control, Voice and everything else is Best Effort. The following table would apply to this configuration/SLA: +----------------+----------------+-----------+--------------+ | Applications | Service | DSCP(s) | Treatment | | | Class | | Aggregate | +================+================+===========+==============+ | Network | Network | CS6 | Network | | Control | Control | | Control | +----------------+----------------+-----------+--------------+ | Voice | Audio | EF | Realtime | +----------------+----------------+-----------+--------------+ | Everything | DF | Default | Elastic | | else | | (CS0) | | +----------------+----------------+-----------+--------------+ Figure 6. Example 1 Configuration Insert different treatments for this example (i.e., AQM, RED, WFQ, colors, etc from above charts) 2.4.1.2 Example 2 - Voice/Video/Surveillance Configuration/SLA For example 1, we have an SP running MPLS and has an SLA to deliver Control, audio, video, surveillance, audio & video signaling, and everything else is BE +----------------+----------------+-----------+--------------+ | Applications | Service | DSCP(s) | Treatment | | | Class | | Aggregate | +================+================+===========+==============+ | Network | Network | CS6 | Network | | Control | Control | | Control | +----------------+----------------+-----------+--------------+ | Voice, video, | Audio, Video, | EF, AF42, | Realtime | | surveillance | Broadcast | CS3 | | Polk Expires April 22, 2013 [Page 30] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 +----------------+----------------+-----------+--------------+ | audio & video | Conversational | AV-Sig | Assured | | signaling | Signaling | | Elastic | +----------------+----------------+-----------+--------------+ | Everything | DF | Default | Elastic | | else | | (CS0) | | +----------------+----------------+-----------+--------------+ Figure 7. Example 2 Configuration Insert different treatments for this example (i.e., AQM, RED, WFQ, colors, etc from above charts) 2.4.1.2 Example 3 - Complex CAC realtime/Surveillance/+apps Configuration/SLA For example 1, we have an SP running MPLS and has an SLA to deliver Control, voice, CAC voice, CAC video, streaming, signaling, LL data, Network Mgmt., and everything else is BE (including non-CAC video because it is not authorized or authenticated on network) +-------------------+-----------------+-----------+--------------+ | Applications | Service | DSCP(s) | Treatment | | | Class | | Aggregate | +===================+=================+===========+==============+ | Network | Network | CS6 | Network | | Control | Control | | Control | +-------------------+-----------------+-----------+--------------+ | Voice, CAC-Voice | Audio, Video, |Voice-Admit| Realtime | | CAC-video, | | EF, AF41 | | | surveillance | Broadcast | CS3 | | +-------------------+-----------------+-----------+--------------+ | audio & video | Conversational | AV-Sig | Assured | | signaling, | Signaling, Low- | AF21 | Elastic | | VOD (streaming), | Latency Data, | AF31 | | | Network Mgmt. | Multimedia | CS2 | | | | Streaming, | | | | | OAM | | | +-------------------+-----------------+-----------+--------------+ | Everything | DF | Default | Elastic | | else | | (CS0) | | +-------------------+-----------------+-----------+--------------+ Figure 8. Example 3 Configuration Insert different treatments for this example (i.e., AQM, RED, WFQ, colors, etc from above charts) 3. Network Control Traffic Network control traffic is defined as packet flows that are Polk Expires April 22, 2013 [Page 31] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 essential for stable operation of an administered network, as well as the information 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 (e.g., routing or mgmt protocols) that are used for operating, administering, controlling, or managing whole networks, network parts or just 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, specifically if needed for future routing or control protocols. Network administrators MAY use a Local/Experimental DSCP, any value that contains 11xx11; 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 111xxx packets at ingress to DiffServ network domain. o 111xxx 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. o any internally defined 11xxx1 values, valid within that network domain, be remarked to CS6 upon egress at network peering points. 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 similar devices within the administrative domain, as well as across a peering point between adjacent 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 CS6 PHB, defined in [RFC2474]. This service class MUST 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 MUST be such that the probability of packet drop under peak load is very low. The Network Control service class SHOULD be configured to use a Rate Queuing system such as defined in Section Polk Expires April 22, 2013 [Page 32] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 1.4.1.2 of this document. The following are examples of protocols and applications that MUST use the Network Control service class if present in a network: 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 MUST NOT use the Network Control service class: o User oriented traffic is not allowed to use this service class. By user oriented traffic, we mean packet flows that originate from user-controlled end points that are connected to the network. o even if originating from a server or a device acting on behalf of a user or endpoint, o even if it is application or in-band signaling to establish a connection wholly within a single network or across peering points of/to adjacent networks (e.g., creating a tunnel such as a VPN, or data path control signaling). 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, OSPF, etc). o IGMP, hen is used only for the normal multicast routing purpose. The REQUIRED 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 MUST 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) MUST be dropped or remarked at ingress to the DiffServ network. What a network admin remarks this user oriented Polk Expires April 22, 2013 [Page 33] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 traffic to if a matter of local policy, and inspection of the packets can determine which application is used for proper marking to a more appropriate DSCP, such as from table 3. of this document. 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. 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. Polk Expires April 22, 2013 [Page 34] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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). 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 Polk Expires April 22, 2013 [Page 35] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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 Oriented Traffic User oriented traffic is defined as packet flows between different users or subscribers, or from servers/nodes on behalf of a user. It is the traffic that is sent to or from end-terminals and that supports a very wide variety of applications and services, to include traffic about a user or application that assists a user communicate. User oriented traffic can be classified in many different ways. What we have articulated throughout this document is a series of non-exhaustive list of categories for classifying user oriented traffic. We differentiated user oriented traffic that is real-time versus non-real-time, elastic or rate-adaptive versus inelastic, sensitive versus insensitive to loss as well as considering whether the traffic is interactive vs. one way communication, its responsiveness, whether it requires timely delivery, and critical verses non-critical. 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. At the same time, we include a public facing default DSCP value, with its associated PHB, that is expected for each traffic type to ensure common or pervasive performance. Figure 3 provides some common applications and the forwarding service classes that best support them, based on their performance requirements. 4.1. Conversational Service Class Group The Conversational Service Class Group consists of 3 different service classes, audio, video, and Hi-Res. We are describing the media sample, or bearer, packets for applications (e.g., RTP from [RFC3550]) that require bi-directional real-time, very low delay, very low jitter, and very low packet loss for relatively constant-rate traffic sources (inelastic traffic sources). It is RECOMMENDED that RTCP feedback use the same service class and be marked with the same DSCP as the bearer traffic for that (audio and/or video) call. This ensures comparable treatment within the Polk Expires April 22, 2013 [Page 36] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 network between endpoints. The signaling to set-up these bearer flows is part of the Conversational Signaling service group that will be discussed later in Section 4. The following 3 subsections will detail what is expected within each bearer service class. 4.1.1 Audio Service Class This service class MUST be used for IP Audio service. The fundamental service offered to traffic in the Audio service class is minimum jitter, delay, and packet loss service up to a specified upper bound. There are two PHBs, both EF based, for the Audio service class: Nonadmitted Audio traffic - MUST use the EF DSCP [RFC3246], and is for traffic that has not had any capacity admission signaling performed for that flow or session. Capacity-Admitted Audio traffic - MUST use the Voice-Admit DSCP [RFC5865], and is for traffic that has had any capacity admission signaling performed for that flow or session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. The capacity-admitted Audio traffic operation is 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 nonadmitted Audio traffic, on the other hand, has had no such explicit guarantee, but has a favorable PHB ensuring high probability of delivery as well as nominal delay and no loss - implicitly assuming there is not too much like marked traffic between users within a flow. There are two typical scenarios in which audio calls are established, on the public open Internet using protocols such as SIP, XMPP or H.323, or in more managed networks like enterprises or certain service providers which offer a audio service with some feature benefits and take part in the call signaling. These SPs or enterprises also use protocols like SIP, XMPP, H.323, but also use H.248/MEGACO and MGCP. On the open Internet, typically there is no SP actively involved in the session set-up of calls, and therefore no servers providing assistance or features to help one user contact another user. Often, this traffic is marked or remarked with the DF (i.e., Best Effort) DSCP. In more managed networks in which one of more operators have active servers aiding the audio call set-up, where DiffServ can be used and preserved to differentiate traffic, networks are offering a service, Polk Expires April 22, 2013 [Page 37] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 therefore need to do some, or a lot of engineering to ensure that capacity offered to one or more applications does not exceed the load to the network. Otherwise, the operator will have unhappy users, at least for that application's usage. This is true for any application, but is especially true for inelastic applications in which the application is rigid in its delivery requirements. Audio bearer traffic is typically such an application, video is another such application, but we will get to video in the next subsection. When a user in a managed network has been authorized to send Audio traffic (i.e., call initiation via the operator's servers was not rejected), the call admission procedure should have verified that the newly admitted flow will be within the capacity of the Audio service class forwarding capability in the network. Capacity verification is a non-trivial thing, and can either be implicitly assumed by the call server(s) based on the operator's network design, or it can be explicitly signaled from an in-data-path signaling mechanism that verifies the capacity is available now for this call, for each call made within that network. In the latter case, those that do not have verifiable network capacity along the data path are rejected. An in between means method is for call servers to count calls between two or more endpoints. By topologically understanding where the caller and called party is and have configured a known maximum it will allow between the two locations. This is especially true over WAN links that have far less capacity than LAN links or core parts of a network. Network operators will need to understand the topology between any two callers to ensure the appropriate amount of bandwidth is available for an expected number of simultaneous audio calls. Once more than one bandwidth amount can be used for audio calls, for example - by allowing more than one codec with different bandwidths per codec for such calls, network engineering becomes more difficult. Since the inelastic nature of RTP payloads from this class do not react well to loss or significant delay in any substantive way, the Audio service class MUST forward packets as soon as possible. The Audio service class that does not have capacity admission performed in the data path MUST use the Expedited Forwarding (EF) PHB, as defined in [RFC3246], so that all packets are forwarded quickly. The Audio service class that does have capacity admission performed in the data path MUST use the Voice-Admit PHB, as defined in [RFC5865], so that all packets are forwarded quickly. The Audio 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 Audio service class: o VoIP (G.711, G.729, iLBC and other audio codecs). o Voice-band data over IP (modem, fax). Polk Expires April 22, 2013 [Page 38] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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 (30, 60, 70, 120 or 200 bytes in size). o Packets emitted at constant time intervals. o Admission control of new flows is provided by Audio call server, media gateway, gatekeeper, edge router, end terminal, access node or in-data-path signaling that provides flow admission control function. Applications or IP end points SHOULD pre-mark their packets with EF or Voice-Admit DSCP value, whichever is appropriate. 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 nonadmitted audio flows, and Voice-Admit for capacity-admitted flows 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]. If untrusted, the network edge SHOULD know if capacity-admission has been applied, since the edge router will have taken part in the admission signaling; therefore will know whether EF or Voice-Admit is the proper marking for that flow. o Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate Polk Expires April 22, 2013 [Page 39] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 with burst size token bucket policer to ensure that the Audio traffic stays within its negotiated bounds. o Policing is OPTIONAL for packet flows from trusted sources whose behavior is ensured via other means (e.g., administrative controls on those systems). o Policing of Audio packet flows across peering points where SLA is in place is OPTIONAL as Audio traffic will be controlled by admission control mechanism between peering points. The fundamental service offered to "Audio" 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. Otherwise, the service will have in place an explicit capacity-admission signaling protocol such as RSVP or NSIS and thus mark the packets within the flow as Voice-Admit. 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.1.2 Video Service Class The Video service class is for bidirectional applications that require real-time service for both constant and rate-adaptive traffic. SIP and H.323/V2 (and later) versions of video conferencing equipment with constant and dynamic bandwidth adjustment are such applications. The traffic sources in this service class either have a fixed bandwidth requirement (e.g., MPEG2, etc.), or have the ability to dynamically change their transmission rate (e.g., MPEG4/H.264, etc.) based on feedback from the receiver. This feedback SHOULD be accomplished using RTCP [RFC3550]. One approach for this downspeeding has the receiver detect packet loss, thus signaling in an RTCP message to the source the indication of lost (or delayed or out of order) packets in transit. When necessary the source then selects a lower rate encoding codec. When available, the source merely sends less data, resulting in lower resolution of the same visual display. The Video service class is not for video downloads, webcasts, or single directional video or audio/video traffic of any kind. It is for human-to-human visual interaction between two users, or more if an MTP is used. Typical video conferencing configurations negotiate the setup of audio/video session using protocols such as SIP and H.323. Just as with networks that have audio traversing them, video typically traverses the same two types of networks: the open big "I" Internet, in which most every type of traffic is best effort (DF), or on a more managed network such as an enterprise or SP's managed network Polk Expires April 22, 2013 [Page 40] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 in which servers within either network take part in the call signaling, thereby offering the video service. When a user in a managed network has been authorized to send video traffic (i.e., call initiation via the operator's servers was not rejected), the call admission procedure should have verified that the newly admitted flow will be within the capacity of the video service class forwarding capability in the network. Capacity verification is a non-trivial thing, and can either be implicitly assumed by the call server(s) based on the operator's network design, or it can be explicitly signaled from an in-data-path signaling mechanism that verifies the capacity is available now for this call, for each call made within that network. In the latter case, those that do not have verifiable network capacity along the data path are rejected. An in between means method is for call servers to count calls between two or more endpoints. By topologically understanding where the caller and called party is and have configured a known maximum it will allow between the two locations. Video is larger in bandwidth than audio, and the difference can be significant. For example, for a single G.711 audio call that is 80kbps, an associated video bandwidth for the same call can easily be 4Mbps. This is especially true over WAN links that have far less capacity than LAN links or core parts of a network. Network operators will need to understand the topology between any two callers to ensure the appropriate amount of bandwidth is available for an expected number of simultaneous video and/or audio/video calls. Note that it is OPTIONALLY the case in these networks that the accompanying audio for the video call will be marked as the video is marked (i.e., using the same DSCP), but not always. One reason this has been done is for lip-sync. The Video service class MUST use the Assured Forwarding (AF) PHB, defined in [RFC2597]. This service class MUST be configured to provide a bandwidth assurance for AF41, AF42, and AF43 marked packets to ensure that they get forwarded. The Video service class SHOULD be configured to use a Rate Queuing system for AF42 and AF43 traffic flows, such as that defined in Section 1.4.1.2 of this document. However, AF41 MUST be designated as the DSCP for use when capacity-admission signaling has been used, such as RSVP or NSIS, to guarantee delivery through the network. AF42 and AF43 will be used for non-admitted video calls, as well as overflows from AF41 sources that send more packets than they have negotiated bandwidth for that call. The following applications MUST use the Video service class: o SIP and H.323/V2 (and later) versions of video conferencing applications (interactive video). o Video conferencing applications with rate control or traffic Polk Expires April 22, 2013 [Page 41] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 content importance marking. o Interactive, time-critical, and mission-critical applications. NOTE with regards to the above bullet: this usage SHOULD be minimized, else the video traffic will suffer - unless this is engineered into the topology. The following are traffic characteristics: o Variable size packets (i.e., small to large in size). o The higher the resolution or change rate between each image, the higher the duration of large packets. o Usually constant inter-packet time interval. o Can be Variable rate in transmission. o Source is capable of reducing its transmission rate based on being told receiver is detecting packet loss (e.g., via RTCP). 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. Mandatory DSCP marking when performed by router closest to source: o AF41 = up to specified rate "A", which is dedicated to non-Hi-Res capacity-admitted video traffic. Note the audio of an A/V call can be marked AF41 as well. o AF42 = all non-Hi-Res video traffic marked AF41 in excess of specified rate "A", or new non-admitted video traffic 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 peak rates of sum of all admitted video flows, plus the sum of the mean rates and "B" to approximate the sum of the peak rates of those same two flows. Mandatory DSCP marking when performed by SIP or H.323/V2 videoconferencing equipment: Polk Expires April 22, 2013 [Page 42] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 o AF41 = SIP or H.323 video conferencing audio stream RTP. o AF41 = SIP or H.323 video conferencing video control RTCP. o AF41 = SIP or H.323 video conferencing video stream up to specified rate "A". o AF42 = SIP or H.323 video conferencing video stream in excess of specified rate "A" but below specified rate "B". o AF42 = SIP or H.323 video conferencing video control RTCP, for those video streams that were generated using AF42. o AF43 = SIP or H.323 video conferencing video stream in excess of specified rate "B". o AF43 = SIP or H.323 video conferencing video control RTCP, for those video streams that were generated using AF43. o Where "A" < "B". Mandatory 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 nonadmitted "Video" traffic is enhanced best-effort service with controlled rate and delay. The fundamental service offered to capacity-admitted "Video" traffic is a guaranteed service using in-data-path signaling to ensure expected delivery in a timely manner. For a non-admitted video conferencing service, if a 1% packet loss detected at the receiver triggers an encoding rate change, thus dropping to the next lower provisioned video encoding rate then 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. This rule applies to all AF42 and 43 flows. 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. Capacity-admitted video service should not result in packet loss. Polk Expires April 22, 2013 [Page 43] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 However, administratively this MAY be allowed to cause a purposeful downspeeding event (i.e., a change in resolution or a change in codec) to occur due to congestion. 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.1.3 Hi-Res Service Class The Hi-Res service class is for higher end (i.e., deemed 'more important') bidirectional applications that require real-time service for both constant and rate-adaptive traffic. There are two PHBs, both EF based, for the Hi-Res video conferencing service class: Nonadmitted Hi-Res traffic - MUST use the CS4 DSCP [RFC2474], and is for traffic that has not had any capacity admission signaling performed for that flow or session. Capacity-Admitted Hi-Res traffic - MUST use the CS4-Admit DSCP [ID-DSCP], and is for traffic that has had any capacity admission signaling performed for that flow or session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. The capacity-admitted Hi-Res video conferencing traffic operation is 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. SIP and H.323/V2 (and later) versions of video conferencing equipment with constant and dynamic bandwidth adjustment are such applications. The traffic sources in this service class either have Polk Expires April 22, 2013 [Page 44] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 a fixed bandwidth requirement (e.g., MPEG2), or have the ability to dynamically change their transmission rate (e.g., MPEG4/H.264) based on feedback from the receiver. This feedback SHOULD be accomplished using RTCP [RFC3550]. One approach for this downspeeding has the receiver detect packet loss, thus signaling in an RTCP message to the source the indication of lost (or delayed or out of order) packets in transit. When necessary the source then selects a lower rate encoding codec. When available, the source merely sends less data, resulting in lower resolution of the same visual display. The Hi-Res service class, as with the Video service class, is not for video downloads, webcasts, or single directional video or audio/video traffic of any kind. It is for human-to-human visual interaction between two users, or more if an video conference bridge is used. Typical Hi-Res video conferencing configurations negotiate the setup of audio/video session using protocols such as SIP and H.323. Hi-Res video conferencing is generally not over the big "I" Internet, rather nearly exclusively over more managed networks such as an enterprise or special purpose SP's managed network in which servers within either network take part in the call signaling, thereby offering the video service. In addition, typically this type of audio/video service has high business expectations for minimized packet loss, pixilation or other issues with the audio/video experience. In the recent past, entire T3s have been dedicated to a signal Hi-Res call; sometimes one T3 per site of a multi-site video conference. Hi-Res video conferencing often has larger in bandwidth than the typical video call. The audio portion can be increased as well, as stereo capabilities are often necessary to provide an in-room experience from a distance. The difference can be significant (or another step up from just a typical video service). For example, for a single G.711 audio call that is 80kbps, a Hi-Res conference usually runs G.722 wideband audio at 256kbps. Typical video delivery is up to 4Mbps, whereas a Hi-Res conference can have three 1080p/30fps widescreen displays requiring at least 12Mbps, with a burst capability of much more. If there were no congestion on the wire, the expected treatment between a video service and a Hi-Res conference would be the same. However, it is typically the case that the Hi-Res conferencing flows have more rigid requirements for quality and business-wise, need to be experience far less errors than the regular video service on the same network. Note that it is likely the case in these networks that the accompanying audio to the Hi-Res video call will be marked as the Hi-Res video is marked (i.e., using the same DSCP. The Hi-Res service class MUST use the Class Selector 5 (CS4) PHB, Polk Expires April 22, 2013 [Page 45] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 defined in [RFC2474], for non-capacity-admitted conferences. While the capacity-admitted Hi-Res conferences MUST use the CS4-Admit PHB, defined in [ID-DSCP]. This service class MUST be configured to provide a bandwidth assurance for CS4 and CS4-Admit marked packets to ensure that they get forwarded. The Hi-Res service class SHOULD be configured to use a Priority Queuing system such as that defined in Section 1.4.1.1 of this document. Further, CS4-Admit will be designated as the DSCP for use when capacity-admission signaling has been used, such as RSVP or NSIS, to guarantee delivery through the network. CS4 will be used for non-admitted Hi-Res conferences, as well as overflows from CS4-Admit sources that send more packets than they have negotiated bandwidth for that call. The following applications MUST use the Hi-Res service class: o SIP and H.323/V2 (and later) versions of Hi-Res video conferencing applications (interactive Hi-Res video). o Video conferencing applications with rate control or traffic content importance marking. The following are traffic characteristics: o Variable size packets. o The higher the resolution or change rate between each image, the higher the duration of large packets. o Usually constant inter-packet time interval. o Can be Variable rate in transmission. o Source is capable of reducing its transmission rate based on being told receiver is detecting packet loss. 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. Mandatory DSCP marking when performed by router closest to source: o CS4-Admit = up to specified rate "A", which is dedicated to capacity-admitted Hi-Res traffic. Note the audio of an A/V call can be marked CS4-Admit as well. o CS4 = all video traffic marked CS4-Admit in excess of specified rate "A", or new non-admitted video traffic but below specified rate "B". Polk Expires April 22, 2013 [Page 46] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 o Where "A" < "B". Note: One might expect "A" to approximate the peak rates of sum of all admitted video flows, plus the sum of the mean rates and "B" to approximate the sum of the peak rates of those same two flows. Mandatory DSCP marking when performed by SIP or H.323/V2 videoconferencing equipment: o CS4-Admit = SIP or H.323 video conferencing audio stream RTP/UDP. o CS4-Admit = SIP or H.323 video conferencing video control RTCP/TCP. o CS4-Admit = SIP or H.323 video conferencing video stream up to specified rate "A". o CS4 = SIP or H.323 video conferencing video stream in excess of specified rate "A" but below specified rate "B". o Where "A" < "B". Mandatory 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 nonadmitted "Hi-Res" traffic is enhanced best-effort service with controlled rate and delay. The fundamental service offered to capacity-admitted "Hi-Res" traffic is a guaranteed service using in-data-path signaling to ensure expected or timely delivery. Capacity-admitted video service SHOULD NOT result in packet loss. However, administratively this MAY be allowed to cause a purposeful downspeeding event (i.e., a change in resolution or a change in codec) to occur. 4.2. Realtime-Interactive Service Class The Realtime-Interactive service class is for bidirectional applications that require low loss and jitter and very low delay for constant or variable rate inelastic traffic sources. Interactive Polk Expires April 22, 2013 [Page 47] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 gaming applications that do not have the ability to change encoding rates or to mark packets with different importance indications is one good example of such an application. Another set of applications is virtualized desktop applications in which a remote user has a keyboard, mouse and display monitor, but the desktop is virtualized with the memory/processor/applications back in a common data center, requiring near instantaneous feedback on the user's monitor of any changes caused by the application or an action by the user. Rich media protocols for voice and video MUST NOT use the Realtime-Interactive service class, but rather the appropriate service class from the Conversational service group discussed early in Section 4.1. The Realtime-Interactive service class will use two PHBs: Nonadmitted Realtime-Interactive traffic - MUST use the CS5 DSCP [RFC2474], and is for traffic that has not had any capacity admission signaling performed for that flow or session. Capacity-Admitted Realtime-Interactive traffic - MUST use the CS5-Admit DSCP [ID-DSCP], and is for traffic that has had any capacity admission signaling performed for that flow or session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. The capacity-admitted Realtime-Interactive traffic operation is 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. Either of the above service classes can be configured as EF based by using a relaxed performance parameter and a rate scheduler. When a user/endpoint has been authorized to start a new session (i.e., joins a networked game or logs onto a virtualized workstation), the admission procedure should have verified that the newly admitted data rates will be within the engineered capacity of the Realtime-Interactive service class. The bandwidth in the core network and the number of simultaneous Realtime-Interactive sessions that can be supported SHOULD be engineered to control traffic load for this service. This service class SHOULD be configured to provide a high assurance for bandwidth for CS5 PHB, defined in [RFC2474], or CS5-Admit [ID-DSCP] for guaranteed service through a capacity-admission signaling protocol. The Realtime-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 either Realtime-Interactive PHB MAY be configured as another EF PHB, specifically CS5-Admit, that uses a relaxed performance parameter and a rate scheduler, in the priority queue as defined in Section 1.4.1.1 of this document. Polk Expires April 22, 2013 [Page 48] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 The following applications MUST use the Realtime-Interactive service class: o Interactive gaming and control. o Remote Desktop applications o Virtualized Desktop applications. o Application server-to-application server non-bursty data transfer requiring very low 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, though sometimes bursty, which will require engineering of the network to accommodate. 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 non-admitted flows in this service class are marked with CS5 (Class Selector 5). o All capacity-admitted flows in this service class are marked with CS5-Admit. Applications or IP end points SHOULD pre-mark their packets with CS5 or CS5-Admit DSCP value, depending on whether a capacity-admission signaling protocol is used for a flow. 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 Polk Expires April 22, 2013 [Page 49] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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 MUST adhere to the Service Level Agreement (SLA). The fundamental service offered to nonadmitted "Realtime-Interactive" traffic is enhanced best-effort service with controlled rate and delay. The fundamental service offered to capacity-admitted "Realtime-Interactive" traffic is a guaranteed service using in-data-path signaling to ensure expected or timely delivery. Capacity-admitted Realtime-Interactive service SHOULD NOT result in packet loss. The service SHOULD be engineered so that CS5 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 CS5 marked packet flows. 4.3. Multimedia Conferencing Service Class The Multimedia Conferencing service class is for applications that have a low to medium tolerance to delay, and are rate adaptive to lost packets in transit from sources. Presentation Data applications that are operational in conjunction with an audio/video conference is one good example of such an application. Another set of applications is application sharing or whiteboarding applications, also in conjunction to an A/V conference. In either case, the audio & video part of the flow MUST NOT use the Multimedia Conferencing service class, rather the more appropriate service class within the Conversational service group discussed earlier in Section 4.1. The Multimedia Conferencing service class will use two PHBs: Nonadmitted Multimedia Conferencing traffic - MUST use the (new) MC DSCP [ID-DSCP], and is for traffic that has not had any capacity admission signaling performed for that flow or session. Capacity-Admitted Multimedia Conferencing traffic - MUST use the (new) MC-Admit DSCP [ID-DSCP], and is for traffic that has had any capacity admission signaling performed for that flow or session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. The capacity-admitted Multimedia Conferencing traffic operation is 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. Polk Expires April 22, 2013 [Page 50] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 When a user/endpoint initiates a presentation data, application sharing or whiteboarding session, it will typically be part of an audio or audio/video conference such as web-conferencing or an existing Telepresence call. The authorization procedure SHOULD be controlled through the coordinated effort to bind the A/V call with the correct Multimedia Conferencing packet flow through some use of identifiers not in scope of this document. The managed network this flow traverse and the number of simultaneous Multimedia Conferencing sessions that can be supported SHOULD be engineered to control traffic load for this service. The non-capacity admitted Multimedia Conferencing service class SHOULD use the new MC PHB, defined in [ID-DSCP]. This service class SHOULD be configured to provide a high assurance for bandwidth for CS5 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. Note that this service class MAY be configured as another EF PHB that uses a relaxed performance parameter, a rate scheduler, and MC-Admit DSCP value, which MUST use the priority queue as defined in Section 1.4.1.1 of this document. The following applications MUST use the Multimedia Conferencing service class: o Presentation Data applications, which can utilize vector graphics, raster graphics or video delivery. o Virtualized Desktop applications. o Application server-to-application server non-bursty data transfer requiring very low delay. The following are traffic characteristics: o Variable size packets. o Variable rate, though sometimes bursty, which will require engineering of the network to accommodate. o Application is sensitive to delay variation between flows and sessions. o Lost packets, if any, can be ignored by the application. RECOMMENDED DSCP marking: o All non-admitted flows in this service class are marked with the new MC DSCP. o All capacity-admitted flows in this service class are marked with Polk Expires April 22, 2013 [Page 51] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 MC-Admit. Applications or IP end points SHOULD pre-mark their packets with the MC 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 MUST adhere to the Service Level Agreement (SLA). The fundamental service offered to nonadmitted "Multimedia Conferencing" traffic is enhanced best-effort service with controlled rate and delay. The fundamental service offered to capacity-admitted "Multimedia Conferencing" traffic is a guaranteed service using in-data-path signaling to ensure expected or timely delivery. Capacity-admitted Multimedia Conferencing service SHOULD NOT result in packet loss. The service SHOULD be engineered so that Multimedia Conferencing 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 MC or MC-Admit marked packet flows. 4.4. 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 Broadcast service class. Such applications include streaming audio and video, some video (movies) on-demand applications, and non-interactive 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 MUST use the Assured Polk Expires April 22, 2013 [Page 52] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 Forwarding (AF3x) PHB, defined in [RFC2597]. This service class MUST 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 for AF32 and AF33 traffic flows, such as that defined in Section 1.4.1.2 of this document. However, AF31 MUST be designated as the DSCP for use when capacity-admission signaling has been used, such as RSVP or NSIS, to guarantee delivery through the network. AF32 and AF33 will be used for non-admitted streaming flows, as well as overflows from AF31 sources that send more packets than they have negotiated bandwidth for that call. The following applications SHOULD use the Multimedia Streaming service class: o Buffered streaming audio (unicast). o Buffered streaming video (unicast). o Non-interactive 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, as well as an expected stepping up and down on the rate of the flow based on changes in resolution due to network conditions. 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 = all traffic marked AF31 in excess of specified rate "A", Polk Expires April 22, 2013 [Page 53] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 or new AF32 traffic 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 peak rates of sum of all streaming flows, plus the sum of the mean rates and "B" to approximate the sum of the peak rates of those same two flows. 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 nonadmitted "Multimedia Streaming" traffic is enhanced best-effort service with controlled rate and delay. The fundamental service offered to capacity-admitted "Multimedia Streaming" traffic is a guaranteed service using in-data-path signaling to ensure expected delivery in a reasonable manner. 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, unless AF31 has had a capacity-admission signaling protocol applied to the flow, such as RSVP or NSIS. If a capacity-admission signaling protocol applied to the AF31 flow, which SHOULD be the case always, the AF31 PHB MAY be configured as another EF PHB that uses a relaxed performance parameter and a rate scheduler, in the priority queue as defined in Section 1.4.1.1 of this document. 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 Polk Expires April 22, 2013 [Page 54] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 following inequality MUST 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#1: this confirmation MUST be modified if AF31 has a capacity-admission signaling protocol applied to those flows, and the above will only apply to AF32 and AF33, while AF31 (theoretically) has no packet loss. Note#2: 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.5. Broadcast Service Class The Broadcast 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 more delay sensitive than applications using the Multimedia Streaming 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 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), thus expecting far less buffering before play-out than Multimedia Streaming, which can buffer in the seconds to minutes (to hours). The Broadcast service class will use two PHBs: Nonadmitted Broadcast traffic - MUST use the CS3 DSCP [RFC2474], and is for traffic that has not had any capacity admission signaling performed for that flow or session. Capacity-Admitted Broadcast traffic - MUST use the CS3-Admit DSCP [ID-DSCP], and is for traffic that has had any capacity admission signaling performed for that flow or session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. The capacity-admitted Broadcast traffic operation is similar to an Polk Expires April 22, 2013 [Page 55] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 ATM CBR service, which has guaranteed bandwidth and which, if it stays within the negotiated rate, experiences nominal delay and no loss. Either of the above service classes can be configured as EF based by using a relaxed performance parameter and a rate scheduler. When a user/endpoint initiates a new Broadcast session (i.e., starts an Internet radio application, starts a live Internet A/V event or a camera comes online to do video-surveillance), the admission procedure should be verified within the application that triggers the flow. The newly admitted data rates will SHOULD be within the engineered capacity of the Broadcast service class within that network. The bandwidth in the core network and the number of simultaneous Broadcast sessions that can be supported SHOULD be engineered to control traffic load for this service. This service class SHOULD be configured to provide high assurance for bandwidth for CS3 marked packets to ensure that they get forwarded. The Broadcast 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 either Broadcast PHB MAY be configured as another EF PHB, specifically CS3-Admit, that uses a relaxed performance parameter and a rate scheduler, in the priority queue as defined in Section 1.4.1.1 of this document. The following applications SHOULD use the Broadcast service class: o Video surveillance and security (unicast). o TV broadcast including HDTV (likely multicast, but can be unicast). 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: Polk Expires April 22, 2013 [Page 56] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 o All non-admitted flows in this service class are marked with CS3 (Class Selector 3). o All capacity-admitted flows in this service class are marked with CS3-Admit. o In some cases, such as those for security and video surveillance applications, it is NOT RECOMMENDED, but allowed to use a different DSCP marking. If so, then locally user definable (EXP/LU) codepoints in the range '011x11' MAY be used to provide unique traffic identification. The locally administrator definable (EXP/LU, from pool 2 of RFC 2474) codepoint(s) MAY be associated with the PHB that is used for CS3 or CS3-Admit 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 or CS3-Admit 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 MUST be performed to the Service Level Agreement (SLA) of those peering entities. The fundamental service offered to "Broadcast" traffic is enhanced best-effort service with controlled rate and delay. The fundamental service offered to capacity-admitted "Broadcast" traffic is a guaranteed service using in-data-path signaling to ensure expected or timely delivery. Capacity-admitted Broadcast service SHOULD NOT result in packet loss. The service SHOULD be engineered so that CS3 and CS3-Admit marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Normally, traffic in Polk Expires April 22, 2013 [Page 57] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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.6. 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 or MBs 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. o Instant Messaging and Presence protocols (e.g., SIP, XMPP). The following are traffic characteristics: o Variable size packets. Polk Expires April 22, 2013 [Page 58] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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 Polk Expires April 22, 2013 [Page 59] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 of loss of AF22 traffic, which in turn MUST NOT exceed the probability of loss of AF23. Explicit Congestion Notification (ECN) [RFC3168] MAY also be used with Active Queue Management. If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations: o min-threshold AF23 < max-threshold AF23 o max-threshold AF23 <= min-threshold AF22 o min-threshold AF22 < max-threshold AF22 o max-threshold AF22 <= min-threshold AF21 o min-threshold AF21 < max-threshold AF21 o max-threshold AF21 <= memory assigned to the queue Note: This configuration tends to drop AF23 traffic before AF22 and AF22 before AF21. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. 4.7. Conversational Signaling Service Class The Signaling service class is MUST be limited to delay-sensitive signaling traffic only, and then only applying to signaling that involves the Conversational service group. Audio 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. Video and Hi-Res signaling includes video endpoint to video endpoint, as well as to Media transfer Point (MTP), to call control server(S), etc. This service class is intended to be used for control of voice and video sessions and applications. Protocols 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. This is not the service class for Instant Messaging (IM), that's within the bounds of the Low-Latency Data service class. The Conversational Signaling service class MUST 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 Conversational Signaling service class MUST use the new A/V-Sig PHB, defined in [ID-DSCP]. This service class MUST be configured to provide a minimum bandwidth assurance for A/V-Sig marked packets to ensure that they get forwarded. In other words, this service class Polk Expires April 22, 2013 [Page 60] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 MUST NOT be starved from transmission within a reasonable timeframe, given that the entire Conversational service group depends on these signaling messages successful delivery. Network engineering SHOULD be done to ensure there is roughly 1-4% available per node interface that audio and video traverse. Local conditions MUST be considered when determining exactly how much bandwidth is given to this service class. The Conversational Signaling service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document. The following applications SHOULD use the Conversational Signaling service class: o Peer-to-peer IP telephony signaling (e.g., SIP, H.323, XMPP). o Peer-to-peer signaling for multimedia applications (e.g., SIP, H.323, XMPP). 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. o Signaling for one-way video flows, such as RTSP [RFC2326]. o IGMP, when used for multicast session control such as channel changing in IPTV systems. o OPTIONALLY, this service class can be used for on-path reservation signaling for the traffic flows that will use the "admitted" DSCPs. The alternative is to have the on-path signaling (for reservations) use the DSCP within that service class. This provides a similar treatment of the signaling to the data flow, which might be desired. 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. Polk Expires April 22, 2013 [Page 61] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 RECOMMENDED DSCP marking: o All flows in this service class are marked with A/V-Sig. Applications or IP end points SHOULD pre-mark their packets with A/V-Sig 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 in which each peer is participating in the call set-up MUST be performed to the Service Level Agreement (SLA). The fundamental service offered to "Conversational Signaling" traffic is enhanced best-effort service with controlled rate and delay. The service SHOULD be engineered so that A/V-Sig 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 A/V-Sig marked packet flows. 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 Polk Expires April 22, 2013 [Page 62] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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 (e.g., FTP, HTTP, etc). o Email. o VPN service that supports two rates (committed information rate and excess or peak information rate). The following are traffic characteristics: o Variable size packets. o Variable packet emission rate. o Variable rate. o With packet bursts of TCP window size. o Source capable of reducing its transmission rate based on detection of packet loss at the receiver or through explicit congestion notification. Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below. If the end point is not capable of setting the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475], and mark all packets as AF1x. Note: In this case, the two-rate, three-color marker will be configured to operate in Color-Blind mode. RECOMMENDED DSCP marking: o AF11 = up to specified rate "A". o AF12 = in excess of specified rate "A" but below specified rate "B". o AF13 = in excess of specified rate "B". o Where "A" < "B". Polk Expires April 22, 2013 [Page 63] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 RECOMMENDED conditioning performed at DiffServ network edge: o The two-rate, three-color marker SHOULD be configured to provide the behavior as defined in trTCM [RFC2698]. o If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Aware mode. o If the packet marking is not trusted or the color marking is not to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Blind mode. The fundamental service offered to "High-Throughput Data" traffic is enhanced best-effort service with a specified minimum rate. The service SHOULD be engineered so that AF11 marked packet flows have sufficient bandwidth in the network to provide assured delivery. It can be assumed that this class will consume any available bandwidth and that packets traversing congested links may experience higher queuing delays or packet loss. Since the AF1x traffic is elastic and responds dynamically to packet loss, Active Queue Management [RFC2309] SHOULD be used primarily to control TCP flow rates at congestion points by dropping packets from TCP flows that have higher rates first. The probability of loss of AF11 traffic MUST NOT exceed the probability of loss of AF12 traffic, which in turn MUST NOT exceed the probability of loss of AF13. In such a case, if one network customer is driving significant excess and another seeks to use the link, any losses will be experienced by the high-rate user, causing him to reduce his rate. Explicit Congestion Notification (ECN) [RFC3168] MAY also be used with Active Queue Management. If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations: o min-threshold AF13 < max-threshold AF13 o max-threshold AF13 <= min-threshold AF12 o min-threshold AF12 < max-threshold AF12 o max-threshold AF12 <= min-threshold AF11 o min-threshold AF11 < max-threshold AF11 o max-threshold AF11 <= memory assigned to the queue Note: This configuration tends to drop AF13 traffic before AF12 and Polk Expires April 22, 2013 [Page 64] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 AF12 before AF11. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. 4.9. Standard Service Class The Standard service class is RECOMMENDED for traffic that has not been classified into one of the other supported forwarding service classes in the DiffServ network domain. This service class provides the Internet's "best-effort" forwarding behavior. This service class typically has minimum bandwidth guarantee. The Standard service class MUST use the Default Forwarding (DF) PHB, defined in [RFC2474], and SHOULD be configured to receive at least a small percentage of forwarding resources as a guaranteed minimum. This service class SHOULD be configured to use a Rate Queuing system such as that defined in Section 1.4.1.2 of this document. The following applications SHOULD use the Standard service class: o Network services, DNS, DHCP, BootP. o Any undifferentiated application/packet flow transported through the DiffServ enabled network. The following is a traffic characteristic: o Non-deterministic, mixture of everything. The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'. Network Edge Conditioning: There is no requirement that conditioning of packet flows be performed for this service class. The fundamental service offered to the Standard service class is best-effort service with active queue management to limit overall delay. Typical configurations SHOULD use random packet dropping to implement Active Queue Management [RFC2309] or Explicit Congestion Notification [RFC3168], and MAY impose a minimum or maximum rate on the queue. If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations: o min-threshold DF < max-threshold DF o max-threshold DF <= memory assigned to the queue Polk Expires April 22, 2013 [Page 65] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. 4.10. Low-Priority Data The Low-Priority Data service class serves applications that run over TCP [RFC0793] or a transport with consistent congestion avoidance procedures [RFC2581] [RFC3782] and that the user is willing to accept service without guarantees. This service class is specified in [RFC3662] and [QBSS]. The following applications MAY use the Low-Priority Data service class: o Any TCP based-application/packet flow transported through the DiffServ enabled network that does not require any bandwidth assurances. The following is a traffic characteristic: o Non-real-time and elastic. Network Edge Conditioning: There is no requirement that conditioning of packet flows be performed for this service class. The RECOMMENDED DSCP marking is CS1 (Class Selector 1). The fundamental service offered to the Low-Priority Data service class is best-effort service with zero bandwidth assurance. By placing it into a separate queue or class, it may be treated in a manner consistent with a specific Service Level Agreement. Typical configurations SHOULD use Explicit Congestion Notification [RFC3168] or random loss to implement Active Queue Management [RFC2309]. If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations: o min-threshold CS1 < max-threshold CS1 o max-threshold CS1 <= memory assigned to the queue Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. Polk Expires April 22, 2013 [Page 66] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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 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 audio 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.2. 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 along the tunnel, end to end. 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. Polk Expires April 22, 2013 [Page 67] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 o The DSCP value in the external header of the packet forwarded through the network providing the VPN service can 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 and/or video 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 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. Contributing Authors This section specifically calls out the authors of RFC 4594, from which this document is based on. Polk Expires April 22, 2013 [Page 68] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 Jozef Babiarz Nortel Networks Kwok Ho Chan Nortel Networks Email: khchan.work@gmail.com Fred Baker Cisco Systems EMail: fred@cisco.com Of note, two of the three mentioned authors above worked for Nortel Networks at the time of writing RFC 4594, a company that no longer exists. This author has not seen or heard from those two in many, many years or IETF meetings - as a result of not knowing their new email addresses (or phone numbers). While much of this document has been rewritten with either edited or brand new material, there are many short paragraphs that remain as they were from RFC 4594, as well as many sentences that were also left unchanged. Additionally, there were no new graphs, charts, diagrams, or tables introduced, meaning the first 4 tables within this document existed in RFC 4594, created by those authors. Presently, each of those tables contain modified and new information. The last 3 tables, specifically tables 5, 6, & 7 were removed because the examples section was removed. This author believes there must be proper credit given for all the contributions, including the framework this document retains from that RFC. Periodically, throughout this document, what was written remains the best way of conveying a thought, rule, or otherwise stated behavior or mechanism. Because RFC 4594 was rather large, there is no realistic way of identifying each part that was left untouched. Further, properly quoting that RFC and leaving those sentences embedded in this document would render this document highly unreadable. Another application could be used to show the changes, deletions and additions - but not one that the IETF accepts presently. This author has created this "Contributing Authors" section as a way of properly identifying those 3 individuals that provided text within this document. We will let the community judge if this is 'good enough' (i.e., rough consensus), or if another way is better. 8. Acknowledgements The author would like to thank Paul Jones, Glen Lavers, Mo Zanaty, David Benham, Michael Ramalho, Gorry Fairhurst, David Black, Brian Carpenter, Al Morton, Ruediger Geib and Shitanshu Shah for their comments and questions about this effort that ultimately helped shape this document. Polk Expires April 22, 2013 [Page 69] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 Below are the folks that were acknowledged in RFC 4594, and this author does not want to lose their recognition of contributions to the original effort. "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." 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 Polk Expires April 22, 2013 [Page 70] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 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. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003. [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, May 2010 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. [IEEE1Q] IEEE, 802.1Q Specification [IEEE1E] IEEE, 802.1E Wireless LAN User Priority Specification [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. Polk Expires April 22, 2013 [Page 71] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 [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. [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. [RFC5462] L. Andersson, R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: EXP Field Renamed to Traffic Class Field", RFC 5462, February 2009 Authors' Address James Polk 3913 Treemont Circle Colleyville, Texas 76034 Phone: +1.817.271.3552 Email: jmpolk@cisco.com Appendix A - Changes Here is a list of all the changes that were captured during the editing process. This will not be a complete list, and others are free to point out what the authors missed, and we'll include that in Polk Expires April 22, 2013 [Page 72] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 the next release. A.1 Since Individual -01 to -02 o Added text to the Intro section on the justification from DiffServ Problem Statement draft, as to more of why this update is necessary. o Added text to the Intro section expanding on the concept of service classes vs. treatment aggregates (from RFC 5127). A.2 Since Individual -00 to -01 o Added Section 2.4 which covers the conflation issues regarding the differences between service classes and treatment aggregates. o Added example operational configurations of treatment aggregates applied to this draft's new set of service classes and additional DSCPs. o Added references RFC 5865, RFC 5462, IEEE 802.1E and IEEE 802.1Q. A.3 Since RFC 4594 to Individual Update -00 o rewrote Intro to emphasize current topics o Created a Conversational Service group, comprising the audio, video and Hi-Res service classes - because they have similar characteristics. o Incorporated the 6 new DSCPs from [ID-DSCP]. o moved the example section, en mass, to an appendix that might not be kept for this version. We're not sure it accomplishes what it needs to, and might not provide any real usefulness. o Moved 'Realtime-Interactive' service class to CS5, from CS4 o Changed 'Broadcast Video' service class to 'Broadcast' service class o Changed AF4X to 'Video' service class, replacing 'Multimedia Conferencing' service class o Moved 'Multimedia Conferencing' service class to different DSCPs o Added the 'Hi-Res' service class o Removed section 5.1 on signaling choices. It has been included in the main body of the text. Polk Expires April 22, 2013 [Page 73] Internet-Draft Std Config. for DiffServ Service Classes Oct 2012 o Changed document title o ... Polk Expires April 22, 2013 [Page 74]