--- 1/draft-ietf-tsvwg-diffserv-service-classes-01.txt 2006-02-18 01:12:32.000000000 +0100 +++ 2/draft-ietf-tsvwg-diffserv-service-classes-02.txt 2006-02-18 01:12:32.000000000 +0100 @@ -1,20 +1,20 @@ TSVWG J. Babiarz Internet-Draft K. Chan -Expires: January 16, 2006 Nortel Networks +Expires: August 20, 2006 Nortel Networks F. Baker Cisco Systems - July 15, 2005 + February 16, 2006 Configuration Guidelines for DiffServ Service Classes - draft-ietf-tsvwg-diffserv-service-classes-01 + draft-ietf-tsvwg-diffserv-service-classes-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,105 +25,123 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 16, 2006. + This Internet-Draft will expire on August 20, 2006. Copyright Notice - Copyright (C) The Internet Society (2005). + Copyright (C) The Internet Society (2006). Abstract - This paper summarizes the recommended correlation between service - classes and their usage, with references to their corresponding - recommended Differentiated Service Code Points (DSCP), traffic - conditioners, Per-Hop Behaviors (PHB) and Active Queue Management - (AQM) mechanism. There is no intrinsic requirement that particular - DSCPs, traffic conditioner PHBs and AQM be used for a certain service - class, but as a policy it is useful that they be applied consistently - across the network. + This document describes service classes configured with Diffserv, + recommends how they can be used and how to construct them using + Differentiated Service Code Points (DSCP), traffic conditioners, Per- + Hop Behaviors (PHB), and Active Queue Management (AQM) mechanisms. + There is no intrinsic requirement that particular DSCPs, traffic + conditioners, PHBs, and AQM be used for a certain service class, but + as a policy and for interoperability it is useful to apply them + consistently. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Requirements Notation . . . . . . . . . . . . . . . . . . 4 - 1.2 Expected use in the Network . . . . . . . . . . . . . . . 4 - 1.3 Service Class Definition . . . . . . . . . . . . . . . . . 5 - 1.4 Key Differentiated Services Concepts . . . . . . . . . . . 5 - 1.4.1 Queuing . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.4.1.1 Priority Queuing . . . . . . . . . . . . . . . . . 6 - 1.4.1.2 Rate Queuing . . . . . . . . . . . . . . . . . . . 6 - 1.4.2 Active Queue Management . . . . . . . . . . . . . . . 7 - 1.4.3 Traffic Conditioning . . . . . . . . . . . . . . . . . 7 - 1.4.4 Differentiated Services Code Point (DSCP) . . . . . . 8 - 1.4.5 Per-Hop Behavior (PHB) . . . . . . . . . . . . . . . . 8 - 1.5 Key Service Concepts . . . . . . . . . . . . . . . . . . . 8 - 1.5.1 Default Forwarding (DF) . . . . . . . . . . . . . . . 9 - 1.5.2 Assured Forwarding (AF) . . . . . . . . . . . . . . . 9 - 1.5.3 Expedited Forwarding (EF) . . . . . . . . . . . . . . 10 - 1.5.4 Class Selector (CS) . . . . . . . . . . . . . . . . . 10 - 1.5.5 Admission Control . . . . . . . . . . . . . . . . . . 11 - 2. Service Differentiation . . . . . . . . . . . . . . . . . . . 11 - 2.1 Service Classes . . . . . . . . . . . . . . . . . . . . . 11 - 2.2 Categorization of User Service Classes . . . . . . . . . . 13 - 2.3 Service Class Characteristics . . . . . . . . . . . . . . 16 - 2.4 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 21 - 2.4.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 21 - 2.4.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 22 - 2.4.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . 25 + 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 + 1.2. Expected use in the Network . . . . . . . . . . . . . . . 5 + 1.3. Service Class Definition . . . . . . . . . . . . . . . . . 5 + 1.4. Key Differentiated Services Concepts . . . . . . . . . . . 6 + 1.4.1. Queuing . . . . . . . . . . . . . . . . . . . . . . . 6 + 1.4.1.1. Priority Queuing . . . . . . . . . . . . . . . . . 7 + 1.4.1.2. Rate Queuing . . . . . . . . . . . . . . . . . . . 7 + 1.4.2. Active Queue Management . . . . . . . . . . . . . . . 7 + 1.4.3. Traffic Conditioning . . . . . . . . . . . . . . . . . 8 + 1.4.4. Differentiated Services Code Point (DSCP) . . . . . . 9 + 1.4.5. Per-Hop Behavior (PHB) . . . . . . . . . . . . . . . . 9 + 1.5. Key Service Concepts . . . . . . . . . . . . . . . . . . . 9 + 1.5.1. Default Forwarding (DF) . . . . . . . . . . . . . . . 9 + 1.5.2. Assured Forwarding (AF) . . . . . . . . . . . . . . . 10 + 1.5.3. Expedited Forwarding (EF) . . . . . . . . . . . . . . 10 + 1.5.4. Class Selector (CS) . . . . . . . . . . . . . . . . . 11 + 1.5.5. Admission Control . . . . . . . . . . . . . . . . . . 11 + 2. Service Differentiation . . . . . . . . . . . . . . . . . . . 12 + 2.1. Service Classes . . . . . . . . . . . . . . . . . . . . . 12 + 2.2. Categorization of User Service Classes . . . . . . . . . . 13 + 2.3. Service Class Characteristics . . . . . . . . . . . . . . 17 + 2.4. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 22 + 2.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 22 + 2.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 23 + 2.4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 26 3. Network Control Traffic . . . . . . . . . . . . . . . . . . . 27 - 3.1 Current Practice in The Internet . . . . . . . . . . . . . 27 - 3.2 Network Control Service Class . . . . . . . . . . . . . . 27 - 3.3 OAM Service Class . . . . . . . . . . . . . . . . . . . . 29 - 4. User Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 4.1 Telephony Service Class . . . . . . . . . . . . . . . . . 31 - 4.2 Signaling Service Class . . . . . . . . . . . . . . . . . 32 - 4.3 Multimedia Conferencing Service Class . . . . . . . . . . 34 - 4.4 Real-time Interactive Service Class . . . . . . . . . . . 37 - 4.5 Multimedia Streaming Service Class . . . . . . . . . . . . 38 - 4.6 Broadcast Video Service Class . . . . . . . . . . . . . . 40 - 4.7 Low Latency Data Service Class . . . . . . . . . . . . . . 42 - 4.8 High Throughput Data Service Class . . . . . . . . . . . . 44 - 4.9 Standard Service Class . . . . . . . . . . . . . . . . . . 46 - 4.10 Low Priority Data . . . . . . . . . . . . . . . . . . . . 47 - 5. Additional Information on Service Class Usage . . . . . . . . 48 - 5.1 Mapping for Signaling . . . . . . . . . . . . . . . . . . 48 - 5.2 Mapping for NTP . . . . . . . . . . . . . . . . . . . . . 48 - 5.3 VPN Service Mapping . . . . . . . . . . . . . . . . . . . 49 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 - 7. Summary of Changes from Previous Draft . . . . . . . . . . . . 50 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 - 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 51 - 9.1 Explanation of Ring Clipping . . . . . . . . . . . . . . . 51 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 - 10.1 Normative References . . . . . . . . . . . . . . . . . . . 52 - 10.2 Informative References . . . . . . . . . . . . . . . . . . 53 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 54 - Intellectual Property and Copyright Statements . . . . . . . . 56 + 3.1. Current Practice in The Internet . . . . . . . . . . . . . 28 + 3.2. Network Control Service Class . . . . . . . . . . . . . . 28 + 3.3. OAM Service Class . . . . . . . . . . . . . . . . . . . . 30 + 4. User Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 4.1. Telephony Service Class . . . . . . . . . . . . . . . . . 32 + 4.2. Signaling Service Class . . . . . . . . . . . . . . . . . 33 + 4.3. Multimedia Conferencing Service Class . . . . . . . . . . 35 + 4.4. Real-time Interactive Service Class . . . . . . . . . . . 38 + 4.5. Multimedia Streaming Service Class . . . . . . . . . . . . 39 + 4.6. Broadcast Video Service Class . . . . . . . . . . . . . . 41 + 4.7. Low Latency Data Service Class . . . . . . . . . . . . . . 43 + 4.8. High Throughput Data Service Class . . . . . . . . . . . . 45 + 4.9. Standard Service Class . . . . . . . . . . . . . . . . . . 47 + 4.10. Low Priority Data . . . . . . . . . . . . . . . . . . . . 48 + 5. Additional Information on Service Class Usage . . . . . . . . 49 + 5.1. Mapping for Signaling . . . . . . . . . . . . . . . . . . 49 + 5.2. Mapping for NTP . . . . . . . . . . . . . . . . . . . . . 49 + 5.3. VPN Service Mapping . . . . . . . . . . . . . . . . . . . 50 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 50 + 7. Summary of Changes from Previous Version . . . . . . . . . . . 51 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 54 + 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 54 + 9.1. Explanation of Ring Clipping . . . . . . . . . . . . . . . 54 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 55 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 56 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 + Intellectual Property and Copyright Statements . . . . . . . . . . 59 1. Introduction - This paper summarizes the recommended correlation between service - classes and their usage, with references to their corresponding - recommended Differentiated Service Code Points (DSCP), traffic - conditioners, Per-Hop Behaviors (PHB) and Active Queue Management - (AQM) mechanisms. There is no intrinsic requirement that particular - DSCPs, traffic conditioner PHBs and AQM be used for a certain service - class, but as a policy it is useful that they be applied consistently - across the network. + For understanding the role of this document we use an useful analogy, + starting from the fact that the Differentiated Services + specifications are fundamentally a toolkit - the specifications + provide the equivalent of band saws, planers, drill presses, etc. In + the hands of an expert, there's no limit to what can be built, but + such a toolkit can be intimidating to the point of inaccessible to a + non-expert who just wants to build a bookcase. This document should + be viewed as a set of "project plans" for building all the (diffserv) + furniture that one might want. The user may choose what to build + (e.g., perhaps our non-expert doesn't need a china cabinet right + now), and how to go about building it (e.g., plans for a non-expert + probably won't employ mortise/tenon construction, but that absence + does not imply that mortise/tenon construction is forbidden or + unsound). The authors hope that these diffserv "project plans" will + provide a useful guide to Network Administrators in the use of + diffserv techniques to implement quality of service measures + appropriate for their network's traffic. + + This document describes service classes configured with Diffserv, + recommends how they can be used and how to construct them using + Differentiated Service Code Points (DSCP), traffic conditioners, Per- + Hop Behaviors (PHB), and Active Queue Management (AQM) mechanisms. + There is no intrinsic requirement that particular DSCPs, traffic + conditioners, PHBs, and AQM be used for a certain service class, but + as a policy and for interoperability it is useful to apply them + consistently. Service classes are defined based on the different traffic characteristics and required performance of the applications/ services. This approach allows us to map current and future applications/services of similar traffic characteristics and performance requirements into the same service class. Since the applications'/services' characteristics and required performance are end to end, the service class notion needs to be preserved end to end. With this approach, a limited set of service classes is required. For completeness, we have defined twelve different service @@ -139,91 +157,106 @@ are used for service differentiation in IP networks. Section 2, is an overview of how service classes are constructed to provide service differentiation with examples of deployment scenarios. Section 3, provides configuration guidelines of service classes that are used for stable operation and administration of the network. Section 4, provides configuration guidelines of service classes that are used for differentiation of user/subscriber traffic. Section 5, provides additional guidance on mapping different applications/protocol to service classes. Section 6, address security considerations. -1.1 Requirements Notation +1.1. Requirements Notation The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. -1.2 Expected use in the Network +1.2. Expected use in the Network In the Internet today, corporate LANs and ISP WANs are generally not heavily utilized - they are commonly 10% utilized at most. For this reason, congestion, loss, and variation in delay within corporate LANs and ISP backbones is virtually unknown. This clashes with user perceptions, for three very good reasons. o The industry moves through cycles of bandwidth boom and bandwidth bust, depending on prevailing market conditions and the periodic deployment of new bandwidth-hungry applications. o In access networks, the state is often different. This may be because throughput rates are artificially limited, or are over subscribed, or because of access network design trade-offs. o Other characteristics, such as database design on web servers (that may create contention points, e.g. in filestore), and configuration of firewalls and routers, often look externally like a bandwidth limitation. The intent of this document is to provide a consistent marking, - conditioning and packet treatment strategy so that it can be + conditioning, and packet treatment strategy so that it can be configured and put into service on any link which itself is congested. -1.3 Service Class Definition +1.3. Service Class Definition A "service class" represents a set of traffic that requires specific - delay, loss and jitter characteristics from the network for which a - consistent and defined per-hop behavior (PHB) [RFC2474] applies. + delay, loss, and jitter characteristics from the network. Conceptually, a service class pertains to applications with similar characteristics and performance requirements, such as a "High Throughput Data" service class for applications like the web and electronic mail, or a "Telephony" service class for real-time traffic such as voice and other telephony services. Such service class may be defined locally in a Differentiated Services domain, or across multiple DS domains, including possibly extending end to end. - A Service Class as defined here is essentially a statement of the - required characteristics of a traffic aggregate; the actual + A service class as defined here is essentially a statement of the + required characteristics of a traffic aggregate. The required + characteristics of these traffic aggregates can be realized by the + use of defined per-hop behavior (PHB) [RFC2474]. The actual specification of the expected treatment of a traffic aggregate within - a domain may also be defined as a Per Domain Behavior [RFC3086]. + a domain may also be defined as a per domain behavior (PDB) + [RFC3086]. + + Each domain may choose to implement different service classes, or use + different behaviors to implement the service classes, or aggregate + different kinds of traffic into the aggregates and still achieve + their required characteristics. For example, low delay, loss, and + jitter may be realized using the EF PHB, or with an over provisioned + AF PHB. This must be done with care as it may disrupt the end to end + performance required by the applications/services. This document + provides recommendations on usage of PHBs for specific service + classes for their consistent implementation, these recommendations + are not to be construed as prohibiting use of other PHBs that realize + behaviors sufficient for the relevant class of traffic. The Default Forwarding "Standard" service class is REQUIRED, all other service classes are OPTIONAL. It is expected that network administrators will choose the level of service differentiation that they will support based on their need, starting off with three or four service classes for user traffic and add others as the need arises. -1.4 Key Differentiated Services Concepts +1.4. Key Differentiated Services Concepts The reader SHOULD be familiar with the principles of the - Differentiated Services Architecture [RFC2474]. However, we - recapitulate key concepts here to save searching. + Differentiated Services Architecture [RFC2474]. We recapitulate key + concepts here only to provide convenience for the reader, with the + referenced RFCs providing the authoritative definitions. -1.4.1 Queuing +1.4.1. Queuing A queue is a data structure that holds packets that are awaiting transmission. The packets may be delayed while in the queue, possibly due to lack of bandwidth, or because it is low in priority. There are a number of ways to implement a queue, a simple model of a queuing system, however, is a set of data structures for packet data, which we will call queues and a mechanism for selecting the next packet from among them, which we call a scheduler. -1.4.1.1 Priority Queuing +1.4.1.1. Priority Queuing A priority queuing system is a combination of a set of queues and a scheduler that empties them in priority sequence. When asked for a packet, the scheduler inspects the highest priority queue, and if there is data present returns a packet from that queue. Failing that, it inspects the next highest priority queue, and so on. A freeway onramp with a stoplight for one lane, but which 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. @@ -233,40 +266,40 @@ 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 which has that requirement. A priority queue or queuing system needs to avoid starvation of lower priority queues. This may be achieved through a variety of means such as admission control, rate control, or network engineering. -1.4.1.2 Rate Queuing +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 WFQ or WRR, the delay that a packet in any given queue will experience is dependant 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 to be not 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 +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, 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 @@ -278,21 +311,21 @@ approximate the minimum threshold. A variation of the algorithm is applied in Assured Forwarding PHB [RFC2597], in that the behavior aggregate consists of traffic with multiple DSCP marks, which are intermingled in a common queue. Different minima and maxima are configured for the several DSCPs separately, such that traffic that exceeds a stated rate at ingress is more likely to be dropped or marked than traffic that is within its contracted rate. -1.4.3 Traffic Conditioning +1.4.3. Traffic Conditioning Additionally, 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, such 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 @@ -302,43 +335,43 @@ bucket meter to achieve multiple levels of conformance used by Assured Forwarding PHB [RFC2597]. Multiple rates and burst sizes can be realized using multiple levels of token buckets or more complex token buckets, these are implementation details. Some traffic conditioners that may be used in deployment of differentiated services are: 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 buckets meters + 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 the 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) +1.4.4. Differentiated Services Code Point (DSCP) The DSCP is a number in the range 0..63, that is placed into an IP packet to mark it according to the class of traffic it belongs in. Half of these values are earmarked for standardized services, and the other half of them are available for local definition. -1.4.5 Per-Hop Behavior (PHB) +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 specify what PHB should be applied to them. -1.5 Key Service Concepts +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 @@ -346,83 +379,83 @@ 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) +1.5.1. Default Forwarding (DF) The basic forwarding behavior 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 which uses default forwarding is expected to be "elastic" in nature. By this, we mean that the sender of traffic will adjust its transmission rate in response to changes in available rate, loss, or delay. For the basic best effort service, a single DSCP value is provided to identify the traffic, a queue to store it, and active queue management to protect the network from it and to limit delays. -1.5.2 Assured Forwarding (AF) +1.5.2. Assured Forwarding (AF) The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled on Frame Relay's DE flag or ATM's CLP capability, and is intended for networks that offer average-rate 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 to occasionally use more capacity than their contract - stipulates, perhaps up to some bound. However, if traffic SHOULD be - lost or marked to manage the queue, this excess traffic will be + 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) +1.5.3. Expedited Forwarding (EF) - Expedited Forwarding PHB [RFC3246] behavior was originally proposed - as a way to implement a virtual wire, and can be used in such a - manner. It is an enhanced best effort service: traffic remains + 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 over-run, and then the traffic SHOULD be given a low delay queue (often using priority, although it is asserted that a rate-based queue can do this) to ensure that variation in delay is not an issue, to meet application needs. -1.5.4 Class Selector (CS) +1.5.4. Class Selector (CS) Class Selector provides support for historical codepoint definitions and PHB requirement. The Class Selector DS field provides a limited backward compatibility with legacy (pre DiffServ) practice, as described in [RFC2474] Section 4. Backward compatibility is addressed in two ways. First, there are per-hop behaviors that are already in widespread use (e.g. those satisfying the IPv4 Precedence queuing requirements specified in [RFC1812], and we wish to permit their continued use in DS-compliant networks. In addition, there are some codepoints that correspond to historical use of the IP @@ -433,21 +466,21 @@ or TOS bits of the IPv4 TOS octet, as defined in [RFC0791]and [RFC1349]. A DS-compliant network can be deployed with a set of one or more Class Selector compliant PHB groups. As well, network administrator may configure the network nodes to map codepoints to PHBs irrespective of bits 3-5 of the DSCP field to yield a network that is compatible with historical IP Precedence use. Thus, for example, codepoint '011000' would map to the same PHB as codepoint '011010'. -1.5.5 Admission Control +1.5.5. Admission Control Admission control including refusal when policy thresholds are crossed, can assure high quality communication by ensuring the availability of bandwidth to carry a load. Inelastic real-time flows like VoIP (telephony) or video conferencing services can benefit from use of admission control mechanism, as generally the telephony service is configured with over subscription, meaning that some user(s) may not be able to make a call during peak periods. For VoIP (telephony) service, a common approach is to use signaling @@ -476,21 +509,21 @@ support 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 +2.1. Service Classes Traffic flowing in a network can be classified in many different ways. We have chosen to divide it into two groupings, network control and user/subscriber traffic. To provide service differentiation, different service classes are defined in each grouping. The network control traffic group can further be divided into two service classes (see Section 3 for detailed definition of each service class): o "Network Control" for routing and network control function. o "OAM" (Operations, Administration and Management) for network @@ -527,27 +561,26 @@ broadcast TV and live events, video surveillance and security. o Low Latency Data service class is best suited for data processing applications where a human is waiting for output, such as web- based ordering, Enterprise Resource Planning (ERP) application, etc. o High Throughput Data service class is best suited for store and forward applications such as FTP, billing record transfer, etc. o Standard service class is for traffic that has not been identified as requiring differentiated treatment and is normally referred as best effort. - o Low Priority Data service class is intended for packet flows where bandwidth assurance is not required. -2.2 Categorization of User Service Classes +2.2. Categorization of User Service Classes - The ten defined user/subscriber services classes listed above can be + 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 summary of service class grouping into four application categories. Application Control category: o The Signaling service class is intended to be used to control applications or user endpoints. Examples of protocols that would @@ -555,21 +588,21 @@ and SIP or IGMP for control of broadcast TV service to subscribers. Although user signaling flows have similar performance requirements as Low Latency Data they need to be distinguished and marked with a different DSCP. The essential distinction is something like "administrative control and management" of the traffic affected as the protocols in this class tend to be tied to the media stream/session they signal and control. Media-Oriented category: Due to the vest number of new (in process of - being deployed) and already in uses media-oriented services in IP + being deployed) and already in use media-oriented services in IP networks, five service classes have been defined. o Telephony service class is intended for IP telephony (VoIP) service as well it may be used for other applications that meet the defined traffic characteristics and performance requirements. o Real-time Interactive service class is intended for inelastic video flows from such application like SIP based desktop video conferencing applications and for interactive gaming. o Multimedia Conferencing service class is for video conferencing solutions that have the ability to reduce their transmission rate on detection of congestion, therefore these flows can be @@ -576,40 +609,39 @@ classified as rate adaptive. As currently there are both types of video conferencing equipment used in IP networks, ones that generate inelastic and ones that generate rate adaptive traffic, therefore two service class are needed. Real-time Interactive service class should be used for equipment that generate inelastic video flows and Multimedia Conferencing service class for equipment that generate rate adaptive video flows. o Broadcast Video service class is to be used for inelastic traffic flows which is intended for broadcast TV service and for transport of live video and audio events. - o Multimedia Streaming service class is to be used for elastic multimedia traffic flows. This multimedia content is typically stored before being transmitted, as well it is buffered at the receiving end before being played out. The buffering is - sufficient 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/or inelastic traffic flows, therefore two service + 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/or inelastic traffic flows, therefore two service classes are defined to address this space. 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 Steaming. + 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. 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. @@ -652,50 +684,48 @@ | Best Effort | Standard | Not Specified |Non-critical| ----------------------------------------------------------------- Note: N.A. = Not Applicable. Figure 1: User/Subscriber Service Classes Grouping Here is a short explanation of end user QoS category as defined in ITU-T Recommendation G.1010. User traffic is divided into four different categories, namely, interactive, responsive, timely, and non-critical. An example of interactive traffic is between two - humans and is most sensitive to delay, loss and jitter. Another + 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 is needed. Responsive traffic is typically between a human and a server but also can be between two servers. Responsive traffic is less affected by jitter and can tolerate longer delays than interactive traffic. Timely traffic is either between servers or servers and humans and the delay tolerance is significantly longer than responsive traffic. Non-critical traffic is normally between servers/machines where delivery may be delay for period of time. -2.3 Service Class Characteristics +2.3. Service Class Characteristics - This draft provides guidelines for network administrator in + This document provides guidelines for network administrator in configuring their network for the level of service differentiation that is appropriate in their network to meet their QoS needs. It is expected that network operators will configure and provide in their networks a subset of the defined service classes. Our intent is to provide guidelines for configuration of Differentiated Services for a wide variety of applications, services and network configurations. Additionally, network administrators may choose to define and deploy in their network other service classes. Figure 2 provides a behavior view for traffic serviced by each service class. The traffic characteristics column defines the characteristics and profile of flows serviced and the tolerance to loss, delay and jitter columns define the treatment the flows will receive. End-to-end quantitative performance requirements may be - obtained from ITU-T Recommendation Y.1541 and Y.1540. There is also - new work currently underway in ITU-T that applies to the service - classes defined in this document. + obtained from ITU-T Recommendation Y.1541 and Y.1540. ------------------------------------------------------------------- |Service Class | | Tolerance to | | Name | Traffic Characteristics | Loss |Delay |Jitter| |===============+==============================+======+======+======| | Network |Variable size packets, mostly | | | | | Control |inelastic short messages, but | Low | Low | Yes | | | traffic can also burst (BGP) | | | | |---------------+------------------------------+------+------+------| | | Fixed size small packets, | Very | Very | Very | @@ -738,22 +768,22 @@ Note: A "Yes" in the jitter-tolerant column implies that data is buffered in the endpoint, and a moderate level of network-induced variation in delay will not affect the application. Applications that use TCP as a transport are generally good examples. Routing protocols and peer-to-peer signaling also fall in this class; while loss can create problems in setting up calls, a moderate level of jitter merely makes call placement a little less predictable in duration. Service classes indicate the required traffic forwarding treatment in - order to meet user, application or network expectations. Section 3in - this document defines the service classes that MAY be used for + order to meet user, application or network expectations. Section 3 + in this document defines the service classes that MAY be used for forwarding network control traffic and Section 4 defines the service classes that MAY be used for forwarding user traffic with examples of intended application types mapped into each service class. Note that the application types are only examples and are not meant to be all- inclusive or prescriptive. Also it should be noted 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 @@ -784,21 +814,21 @@ |Broadcast Video| CS3 | 011000 |Broadcast TV & live events| |---------------+---------+-------------+--------------------------| | Low Latency |AF21,AF22|010010,010100|Client/server transactions| | Data | AF23 | 010110 | Web-based ordering | |---------------+---------+-------------+--------------------------| | OAM | CS2 | 010000 | OAM&P | |---------------+---------+-------------+--------------------------| |High Throughput|AF11,AF12|001010,001100| Store and forward | | Data | AF13 | 001110 | applications | |---------------+---------+-------------+--------------------------| - | Standard | DF,(CS0)| 000000 | Undifferentiated | + | Standard | DF (CS0)| 000000 | Undifferentiated | | | | | applications | |---------------+---------+-------------+--------------------------| | Low Priority | CS1 | 001000 | Any flow that has no BW | | Data | | | assurance | ------------------------------------------------------------------ Figure 3: DSCP to Service Class Mapping Note for Figure 3: o Default Forwarding (DF) and Class Selector 0 (CS0) provide @@ -876,29 +906,29 @@ scheduler. o In network segments that use IP precedence marking, only one of the two service classes can be supported, High Throughput Data or Low Priority Data. We RECOMMEND that the DSCP value(s) of the unsupported service class to be changed to 000xx1 on ingress and changed back to original value(s) on egress of the network segment that uses precedence marking. For example, if Low Priority Data is mapped to Standard service class, then 000001 DSCP marking MAY be used to distinguish it from Standard marked packets on egress. -2.4 Deployment Scenarios +2.4. Deployment Scenarios It is expected that network administrators will choose the service classes that they will support based on their need, starting off with three or four service classes for user traffic and add more service classes as the need arises. In this section we provide three examples of possible deployment scenarios. -2.4.1 Example 1 +2.4.1. Example 1 A network administrator determined that they need to provide different performance levels (quality of service) in their network for the services that they will be offering to their customers. They need to enable their network to provide: o Reliable VoIP (telephony) service, equivalent to PSTN o A low delay assured bandwidth data service o As well, support current Internet services For this example, the network administrator's needs are addressed @@ -908,21 +938,21 @@ o Standard service class for all traffic that will receive normal (undifferentiated) forwarding treatment through their network for support of current Internet service o Telephony service class for VoIP (telephony) bearer traffic o Signaling service class for Telephony signaling to control the VoIP service o Low Latency Data service class for the low delay assured bandwidth differentiated data service o OAM service class for operation and management of the network - Figure 5, provides a summary of the mechanisms need for delivery of + Figure 5, provides a summary of the mechanisms needed for delivery of service differentiation for Example 1. ------------------------------------------------------------------- | Service | DSCP | Conditioning at | PHB | | | | Class | | DS Edge | Used | Queuing| AQM| |===============+=======+===================+=========+========+====| |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes| |---------------+-------+-------------------+---------+--------+----| | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | |---------------+-------+-------------------+---------+--------+----| | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | @@ -941,21 +971,21 @@ Notes for Figure 5: o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single rate three color marker (srTCM) behavior SHOULD be equivalent to RFC 2697. o Any packet that is marked with DSCP value that is not represented by the supported service classes, SHOULD be forwarded using the Standard service class. -2.4.2 Example 2 +2.4.2. Example 2 With this example we show how network operators with Example 1 capabilities can evolve their service offering to provide three new additional services to their customers. The new additional service capabilities that are to be added are: o SIP based desktop video conference capability to complement VoIP (telephony) service o Provide TV and on demand movie viewing service to residential subscribers o Provide network based data storage and file backup service to @@ -1028,21 +1058,21 @@ Notes for Figure 6: o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single rate three color marker (srTCM) behavior SHOULD be equivalent to RFC 2697 and the two rate three color marker (trTCM) behavior SHOULD be equivalent to RFC 2698. o Any packet that is marked with DSCP value that is not represented by the supported service classes, SHOULD be forwarded using the Standard service class. -2.4.3 Example 3 +2.4.3. Example 3 An enterprise network administrator determined that they need to provide different performance levels (quality of service) in their network for the new services that are being offered to corporate users. The enterprise network needs to: o Provide reliable corporate VoIP service o Provide video conferencing service to selected Conference Rooms o Support on demand distribution of prerecorded audio and video information to large number of users o Provide a priority data transfer capability for engineering teams @@ -1058,21 +1088,21 @@ is needed for reliable operation of the enterprise network o OAM service class for operation and management of the network o Standard service class for all traffic that will receive normal (undifferentiated) forwarding treatment o Telephony service class for VoIP (telephony) bearer traffic o Signaling service class for Telephony signaling to control the VoIP service o Multimedia Conferencing service class for support of inter Conference Room video conferencing service using H.323/V2 or similar equipment. - o Multimedia Steaming service class for transfer of prerecorded + o Multimedia Streaming service class for transfer of prerecorded audio and video information o High Throughput Data service class to provide bandwidth assurance for timely transfer of large engineering files o Low Priority Data service class for selected background applications where data transfer can be delayed or suspended for a period of time during peak network load conditions Figure 7, provides a summary of the mechanisms need for delivery of service differentiation for Example 3. @@ -1103,24 +1133,20 @@ | Low Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| | Data | | | | | | |---------------+-------+-------------------+---------+--------+----| | Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes| | | +other| | | | | ------------------------------------------------------------------- Figure 7: Enterprise Network Configuration Example Notes for Figure 7: - o The Administrative service class MAY be implemented using Rate - queuing method as long as sufficient amount of bandwidth is - guaranteed and latency of scheduler is sufficiently low to meet - the requirement. o "sr+bs" represents a policing mechanism that provides single rate with burst size control. o The single rate three color marker (srTCM) behavior SHOULD be equivalent to RFC 2697 and the two rate three color marker (trTCM) behavior SHOULD be equivalent to RFC 2698. o Any packet that is marked with DSCP value that is not represented by the supported service classes, SHOULD be forwarded using the Standard service class. 3. Network Control Traffic @@ -1129,39 +1155,39 @@ for stable operation of the administered network as well for information that may be exchanged between neighboring networks across a peering point where SLAs are in place. Network control traffic is different from user application control (signaling) that may be generated by some applications or services. Network control traffic is mostly between routers and network nodes that are used for operating, administering, controlling or managing the network segments. Network Control Traffic may be split into two service classes, i.e. Network Control and OAM. -3.1 Current Practice in The Internet +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 be reserved for future use, potentially for future routing and/or control protocols. Network administrator MAY use a Local/ Experimental DSCP therefore a locally defined service class within their network to further differentiate their routing and control traffic. RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets: o Drop or remark CS7 marked packets at ingress to DiffServ network domain. o CS7 marked packets SHOULD NOT be sent across peering points. Exchange of control information across peering points SHOULD be done using CS6 DSCP, using Network Control service class. -3.2 Network Control Service Class +3.2. Network Control Service Class The Network Control service class is used for transmitting packets between network devices (routers) that require control (routing) information to be exchanged between nodes within the administrative domain as well across a peering point between different administrative domains. Traffic transmitted in this service class is very important as it keeps the network operational and needs to be forwarded in a timely manner. The Network Control service class SHOULD be configured using the @@ -1218,21 +1244,21 @@ 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 +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 SNMP, TFTP, FTP, Telnet, COPS, etc. 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 @@ -1311,30 +1336,30 @@ the above for service differentiation, mapping of applications that have the matching traffic characteristics that fit the traffic profile and performance requirements of the defined service classes. Network administrators can categorize their applications based on the type of behavior that they require and MAY choose to support all or subset of the defined service classes. Figure 3 provides some common applications and the forwarding service class that best supports them based on their performance requirements. -4.1 Telephony Service Class +4.1. Telephony Service Class The Telephony service class is RECOMMENDED for applications that - require real-time, very low delay, very low jitter and very low + require real-time, very low delay, very low jitter, and very low packet loss for relatively constant-rate traffic sources (inelastic traffic sources). This service class SHOULD be used for IP telephony service. The fundamental service offered to traffic in the Telephony service - class is minimum jitter, delay and packet loss service up to a + class is minimum jitter, delay, and packet loss service up to a specified upper bound. Operation is in some respect similar to an ATM CBR service, which has guaranteed bandwidth and which, if it stays within the negotiated rate, experiences nominal delay and no loss. The EF PHB has a similar guarantee. Typical configurations negotiate the setup of telephone calls over IP using protocols such as H.248, MEGACO, H.323, or SIP. When a user has been authorized to send telephony traffic, the call admission procedure should have verified that the newly admitted flow will be within the capacity of the Telephony service class forwarding @@ -1398,21 +1425,21 @@ admission control mechanism between peering points. The fundamental service offered to "Telephony" traffic is enhanced best effort service with controlled rate, very low delay and very low loss. The service MUST be engineered so that EF marked packet flows have sufficient bandwidth in the network to provide guaranteed delivery. Normally traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to EF marked packet flows. -4.2 Signaling Service Class +4.2. Signaling Service Class The Signaling service class is RECOMMENDED for delay sensitive client-server (traditional telephony) and peer-to-peer application signaling. Telephony signaling includes signaling between IP phone and soft-switch, soft-client and soft-switch, media gateway and soft- switch as well as peer-to-peer using various protocols. This service class is intended to be used for control of sessions and applications. Applications using this service class requiring a relatively fast response as there are typically several message of different size sent for control of the session. This service class @@ -1482,21 +1510,21 @@ to the Service Level Agreement (SLA). The fundamental service offered to "Signaling" traffic is enhanced best effort service with controlled rate and delay. The service SHOULD be engineered so that CS5 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery and low delay. Normally traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to CS5 marked packet flows. -4.3 Multimedia Conferencing Service Class +4.3. Multimedia Conferencing Service Class The Multimedia Conferencing service class is RECOMMENDED for applications that require real-time service for rate adaptive traffic. H.323/V2 and later versions of video conferencing equipment with dynamic bandwidth adjustment is such an application. The traffic sources (applications) in this service class have the capability to dynamically change their transmission rate based on feedback received from the receiving end, within bounds of packet loss by the receiver is sent using the applications control stream to the transmitter as an indication of possible congestion; the @@ -1604,21 +1630,21 @@ o min-threshold AF43 < max-threshold AF43 o max-threshold AF43 <= min-threshold AF42 o min-threshold AF42 < max-threshold AF42 o max-threshold AF42 <= min-threshold AF41 o min-threshold AF41 < max-threshold AF41 o max-threshold AF41 <= memory assigned to the queue Note: This configuration tends to drop AF43 traffic before AF42 and AF42 before AF41. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. -4.4 Real-time Interactive Service Class +4.4. Real-time Interactive Service Class The Real-time Interactive service class is RECOMMENDED for applications that require low loss, jitter and very low delay for variable rate inelastic traffic sources. Interactive gaming and video conferencing applications that do not have the ability to change encoding rates or mark packets with different importance indications are such applications. The traffic sources in this traffic class does not have the ability to reduce their transmission rate based on feedback received from the receiving end. @@ -1680,21 +1707,21 @@ to the Service Level Agreement (SLA). The fundamental service offered to "Real-time Interactive" traffic is enhanced best effort service with controlled rate and delay. The service SHOULD be engineered so that CS4 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Normally traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to CS4 marked packet flows. -4.5 Multimedia Streaming Service Class +4.5. Multimedia Streaming Service Class The Multimedia Streaming service class is RECOMMENDED for applications that require near-real-time packet forwarding of variable rate elastic traffic sources that are not as delay sensitive as applications using the Multimedia Conferencing service class. Such applications include streaming audio and video, some video (movies) on demand applications and Web casts. In general, the Multimedia Streaming service class assumes that the traffic is buffered at the source/destination and therefore, is less sensitive to delay and jitter. @@ -1769,21 +1796,21 @@ o min-threshold AF33 < max-threshold AF33 o max-threshold AF33 <= min-threshold AF32 o min-threshold AF32 < max-threshold AF32 o max-threshold AF32 <= min-threshold AF31 o min-threshold AF31 < max-threshold AF31 o max-threshold AF31 <= memory assigned to the queue Note: This configuration tends to drop AF33 traffic before AF32 and AF32 before AF31. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. -4.6 Broadcast Video Service Class +4.6. Broadcast Video Service Class The Broadcast Video service class is RECOMMENDED for applications that require near-real-time packet forwarding with very low packet loss of constant and variable rate inelastic traffic sources that are not as delay sensitive as applications using the Real-time Interactive service class. Such applications include broadcast TV, streaming of live audio and video events, some video on demand applications and video surveillance. In general, the Broadcast Video service class assumes that the destination end point has a dejitter buffer, for video application usually a 2 - 8 video frames buffer (66 @@ -1847,21 +1874,21 @@ to the Service Level Agreement (SLA). The fundamental service offered to "Broadcast Video" traffic is enhanced best effort service with controlled rate and delay. The service SHOULD be engineered so that CS3 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. Normally traffic in this service class does not respond dynamically to packet loss. As such, Active Queue Management [RFC2309] SHOULD NOT be applied to CS3 marked packet flows. -4.7 Low Latency Data Service Class +4.7. Low Latency Data Service Class The Low Latency Data service class is RECOMMENDED for elastic and responsive typically client/server based applications. Applications forwarded by this service class are those requiring a relatively fast response and typically have asymmetrical bandwidth need, i.e. the client typically sends a short message to the server and the server responds with a much larger data flow back to the client. The most common example of this is when a user clicks a hyperlink (~few dozen bytes) on a web page resulting in a new web page to be loaded (Kbytes of data). This service class is configured to provide good response @@ -1924,39 +1952,39 @@ 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 packet from TCP flows that have large burst size. The probability of loss of AF21 traffic MUST NOT exceed the probability of loss of AF22 traffic, which in turn MUST NOT exceed the probability of loss of - AF23. Active queue management MAY also be implemented using Explicit - Congestion Notification (ECN) [RFC3168]. + AF23. Explicit Congestion Notification (ECN) [RFC3168] MAY also be + used with Active Queue Management. If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations: o min-threshold AF23 < max-threshold AF23 o max-threshold AF23 <= min-threshold AF22 o min-threshold AF22 < max-threshold AF22 o max-threshold AF22 <= min-threshold AF21 o min-threshold AF21 < max-threshold AF21 o max-threshold AF21 <= memory assigned to the queue Note: This configuration tends to drop AF23 traffic before AF22 and AF22 before AF21. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. -4.8 High Throughput Data Service Class +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] [RFC2582] 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. @@ -2021,39 +2048,39 @@ and packets traversing congested links may experience higher queuing delays and/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 packet 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. Active queue management MAY also be - implemented using Explicit Congestion Notification (ECN) [RFC3168]. + causing him to reduce his rate. Explicit Congestion Notification + (ECN) [RFC3168] MAY also be used with Active Queue Management. If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with such a DSCP is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations: o min-threshold AF13 < max-threshold AF13 o max-threshold AF13 <= min-threshold AF12 o min-threshold AF12 < max-threshold AF12 o max-threshold AF12 <= min-threshold AF11 o min-threshold AF11 < max-threshold AF11 o max-threshold AF11 <= memory assigned to the queue Note: This configuration tends to drop AF13 traffic before AF12 and AF12 before AF11. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. -4.9 Standard Service Class +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. @@ -2083,21 +2110,21 @@ If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked. Thus, in this service class, the following inequality should hold in queue configurations: o min-threshold DF < max-threshold DF o max-threshold DF <= memory assigned to the queue Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. -4.10 Low Priority Data +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 procedure [RFC2581] [RFC2582], and which the user is willing to accept service without guarantees. This service class is specified in [QBSS] and [RFC3662]. The following applications MAY use the Low Priority Data service class: o Any TCP based application/packet flow transported through the @@ -2131,21 +2159,21 @@ o max-threshold CS1 <= memory assigned to the queue Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. 5. Additional Information on Service Class Usage In this section we provide additional information on how some specific applications should be configured to use the defined service classes. -5.1 Mapping for Signaling +5.1. Mapping for Signaling There are many different signaling protocols, ways that signaling is used and performance requirements from applications that are controlled by these protocols. We believe that different signaling protocols should use the service class that best meet the objectives of application or service they control. The following mapping is recommended: o Peer-to-peer signaling using SIP/H.323 are marked with CS5 DSCP (use Signaling service class). o Client-server signaling as used in many implementation for IP @@ -2160,35 +2188,36 @@ the same queue (service class) and marked with the same DSCP value as application data that it is controlling. This may also apply to the "on-path" NSIS signaling protocol. o IGMP (Internet Group Management Protocol). If used for multicast session control such as channel changing in IPTV systems, then IGMP packets should be marked with CS5 DSCP (use Signaling service class). When IGMP is used only for the normal multicast routing purpose, it should be marked with CS6 DSCP (use Network Control service class). -5.2 Mapping for NTP +5.2. Mapping for NTP From tests that were performed, indications are that precise time distribution requires a very low packet delay variation (jitter) transport. Therefore we suggest the following guidelines for NTP (Network Time Protocol) be used: + o When NTP is used for providing high accuracy timing within administrator's (carrier's) network or to end users/clients, the Telephony service class should be used and NTP packets be marked with EF DSCP value. o For applications that require "wall clock" timing accuracy, the Standard service class should be used and packets should be marked with DF DSCP. -5.3 VPN Service Mapping +5.3. VPN Service Mapping Differentiated Services and Tunnels [RFC2983] considers the interaction of DiffServ architecture with IP tunnels of various forms. Further to guidelines provided in RFC 2983, below are additional guidelines for mapping service classes that are supported in one part of the network into a VPN connection. This discussion is limit only 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 @@ -2240,64 +2269,161 @@ 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, AAA services such - as described in [I-D.iab-auth-mech] are required. + user rather than to the entire population of users, authentication + and authorization services are required, such as those surveyed in + [I-D.iab-auth-mech]. -7. Summary of Changes from Previous Draft +7. Summary of Changes from Previous Version NOTE TO RFC EDITOR: Please remove this section during the publication process. - Changes made to draft-ietf-tsvwg-diffserv-service-classes-00 based on - minor typos on review by Mike Fidler. Following typos were fixed. - - 1. page 20 first paragraph, "than 000001 DSCP marking" should be - "then 000001 DSCP marking" - - 2. page 22 last sentence of third bullet "than the Broadcast Video - service class" should be "then the Broadcast..." - - 3. page 29 third bullet "than CS2 marked packet" should be "then CS2 - marked packets" (note plural also) - 4. page 40 second sentence of second bullet under "RECOMMENDED DSCP - marking" "If so, than" should be "If so, then" + Changes made to draft-ietf-tsvwg-diffserv-service-classes-01 from + review by David Black, Kathie Nichols, and Charlie Liu: + 1. In Abstract section on page 1, and Section 1 Introduction on + page 4 first paragraph. + Old Text: This paper summarizes the recommended correlation + between service classes and their usage, with references to + their corresponding recommended Differentiated Service Code + Points (DSCP), traffic conditioners, Per-Hop Behaviors (PHB) + and Active Queue Management (AQM) mechanism. There is no + intrinsic requirement that particular DSCPs, traffic + conditioner PHBs and AQM be used for a certain service class, + but as a policy it is useful that they be applied + consistently across the network. + New Text: This document describes service classes configured + with Diffserv, recommends how they can be used and how to + construct them using Differentiated Service Code Points + (DSCP), traffic conditioners, Per-Hop Behaviors (PHB), and + Active Queue Management (AQM) mechanisms. There is no + intrinsic requirement that particular DSCPs, traffic + conditioners, PHBs, and AQM be used for a certain service + class, but as a policy and for interoperability it is useful + to apply them consistently. + 2. In Section 1 Introduction on page 4. Added new first paragraph: + For understanding the role of this document we use an useful + analogy, starting from the fact that the Differentiated + Services specifications are fundamentally a toolkit - the + specifications provide the equivalent of band saws, planers, + drill presses, etc. In the hands of an expert, there's no + limit to what can be built, but such a toolkit can be + intimidating to the point of inaccessible to a non-expert who + just wants to build a bookcase. This document should be + viewed as a set of "project plans" for building all the + (diffserv) furniture that one might want. The user may + choose what to build (e.g., perhaps our non-expert doesn't + need a china cabinet right now), and how to go about building + it (e.g., plans for a non-expert probably won't employ + mortise/tenon construction, but that absence does not imply + that mortise/tenon construction is forbidden or unsound). + The authors hope that these diffserv "project plans" will + provide a useful guide to Network Administrators in the use + of diffserv techniques to implement quality of service + measures appropriate for their network's traffic. + 3. In Section 1.3 first paragraph on page 5. + Old Text: A "service class" represents a set of traffic that + requires specific delay, loss, and jitter characteristics + from the network for which a consistent and defined per-hop- + behavior (PHB) applies. + New Text: A "service class" represents a set of traffic that + requires specific delay, loss, and jitter characteristics + from the network. + 4. In Section 1.3 second paragraph on page 5. + Old Text: A Service Class as defined here is essentially a + statement of the required characteristics of a traffic + aggregate; the actual specification of the expected treatment + of a traffic aggregate within a domain may also be defined as + a Per Domain Behavior [RFC3086]. - 5. page 47 section 5.1 fourth bullet "than it needs to be forwarded" - should be "then it needs to be forwarded" + New Text: A service class as defined here is essentially a + statement of the required characteristics of a traffic + aggregate. The required characteristics of these traffic + aggregates can be realized by the use of defined per-hop + behavior (PHB) [RFC2474]. The actual specification of the + expected treatment of a traffic aggregate within a domain may + also be defined as a per domain behavior (PDB) [RFC3086]. + 5. In Section 1.3 third paragraph on page 5. + Added New Paragraph: Each domain may choose to implement + different service classes, or use different behaviors to + implement the service classes, or aggregate different kinds + of traffic into the aggregates and still achieve their + required characteristics. For example, low delay, loss, and + jitter may be realized using the EF PHB, or with an over + provisioned AF PHB. This must be done with care as it may + disrupt the end to end performance required by the + applications/services. This document provides + recommendations on usage of PHBs for specific service classes + for their consistent implementation, these recommendations + are not to be construed as prohibiting use of other PHBs that + realize behaviors sufficient for the relevant class of + traffic. + 6. In Section 1.4 first paragraph on page 5. + Old Text: The reader SHOULD be familiar with the principles of + the Differentiated Services Architecture [RFC2474]. However, + we recapitulate key concepts here to save searching. + New Text: The reader SHOULD be familiar with the principles of + the Differentiated Services Architecture [RFC2474]. We + recapitulate key concepts here only to provide convenience + for the reader, with the referenced RFCs providing the + authoritative definitions. + 7. In Section 1.5.3 first paragraph first sentence on page 10. + Old Text: Expedited Forwarding PHB [RFC3246] behavior was + originally proposed as a way to implement a virtual wire, and + can be used in such a manner. It is an enhanced best effort + service: + New Text: 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: + 8. In Section 2.3 second paragraph on page 16. Deleted the last + sentence: + There is also new work currently underway in ITU-T that + applies to the service classes defined in this document. + 9. In Section 2.4.3 Example 3, on page 25. Fixed typo: "Multimedia + Steaming", changed it to "Multimedia Streaming". - 6. page 48 section 5.3 second bullet "Service classes are than - mapped" should be "Service classes are then mapped" + 10. In Section 2.4.3 Example 3, on page 26. Deleted the first note + under Notes for Figure 7: Deleted text "The Administrative + service class MAY be implemented using Rate queuing method as + long as sufficient amount of bandwidth is guaranteed and latency + of scheduler is sufficiently low to meet the requirement. " + 11. In Section 10 on page 53. Moving the first reference: + [I-D.iab-auth-mech] Rescorla, E., "A Survey of Authentication + Mechanisms", draft-iab-auth-mech-04 (work in progress), + September 2005. + From Normative References section to Informative References + section. 8. Acknowledgements The authors thank the TSVWG reviewers, David Black, Brian E Carpenter and Alan O'Neill for their review and input to this draft. The authors acknowledge 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 and - Shane Amante. Kimberly King, Joe Zebarth and Alistair Munroe each - did a thorough proof-reading, and the document is better for their - contributions. + 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 proof-reading, and the document is better + for their contributions. 9. Appendix A -9.1 Explanation of Ring Clipping +9.1. Explanation of Ring Clipping The term "ring clipping" refers to those instances where the front end of a ringing signal is altered because the bearer channel is not made available in time to carry all of the audible ringing signal. This condition may occur due to a race condition between when the tone generator located in the circuit switch Exchange is turn on and when the bearer path through the IP network is enabled. To reduce ring clipping from occurring, delay of signaling path needs to be minimized. Below is a more detailed explanation. @@ -2327,25 +2453,21 @@ maximum value. Service administrators are free to choose specific IAM delay values based on their own preferences (i.e., they may wish to set a very low mean delay objective for strategic reasons to differentiate themselves from other providers). In summary, out of the 240ms delay budget, 200ms is allocated as cross-Exchange delay (soft-switch and media gateway) and 40ms for network delay (queuing and distance). 10. References -10.1 Normative References - - [I-D.iab-auth-mech] - Rescorla, E., "A Survey of Authentication Mechanisms", - draft-iab-auth-mech-03 (work in progress), March 2004. +10.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. @@ -2376,21 +2498,25 @@ [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, December 2003. -10.2 Informative References +10.2. Informative References + + [I-D.iab-auth-mech] + Rescorla, E., "A Survey of Authentication Mechanisms", + draft-iab-auth-mech-04 (work in progress), September 2005. [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 Technical Report Proposed Service Definition, March 2001. [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 @@ -2445,22 +2571,23 @@ Fax: +1-613-765-7462 Email: babiarz@nortel.com Kwok Ho Chan Nortel Networks 600 Technology Park Drive Billerica, MA 01821 US Phone: +1-978-288-8175 - Fax: +1-978-288-4690 + Fax: +1-978-288-8700 Email: khchan@nortel.com + Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US Phone: +1-408-526-4257 Fax: +1-413-473-2403 Email: fred@cisco.com @@ -2493,18 +2620,18 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2005). This document is subject + Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.