idnits 2.17.1 draft-ietf-tsvwg-diffserv-service-classes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2502. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2492. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 15, 2005) is 6860 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0791' is defined on line 2346, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-iab-auth-mech-03 ** Downref: Normative reference to an Informational draft: draft-iab-auth-mech (ref. 'I-D.iab-auth-mech') ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1349 (Obsoleted by RFC 2474) ** Obsolete normative reference: RFC 2309 (Obsoleted by RFC 7567) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 3662 (Obsoleted by RFC 8622) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2582 (Obsoleted by RFC 3782) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG J. Babiarz 3 Internet-Draft K. Chan 4 Expires: January 16, 2006 Nortel Networks 5 F. Baker 6 Cisco Systems 7 July 15, 2005 9 Configuration Guidelines for DiffServ Service Classes 10 draft-ietf-tsvwg-diffserv-service-classes-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 16, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This paper summarizes the recommended correlation between service 44 classes and their usage, with references to their corresponding 45 recommended Differentiated Service Code Points (DSCP), traffic 46 conditioners, Per-Hop Behaviors (PHB) and Active Queue Management 47 (AQM) mechanism. There is no intrinsic requirement that particular 48 DSCPs, traffic conditioner PHBs and AQM be used for a certain service 49 class, but as a policy it is useful that they be applied consistently 50 across the network. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1 Requirements Notation . . . . . . . . . . . . . . . . . . 4 56 1.2 Expected use in the Network . . . . . . . . . . . . . . . 4 57 1.3 Service Class Definition . . . . . . . . . . . . . . . . . 5 58 1.4 Key Differentiated Services Concepts . . . . . . . . . . . 5 59 1.4.1 Queuing . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.4.1.1 Priority Queuing . . . . . . . . . . . . . . . . . 6 61 1.4.1.2 Rate Queuing . . . . . . . . . . . . . . . . . . . 6 62 1.4.2 Active Queue Management . . . . . . . . . . . . . . . 7 63 1.4.3 Traffic Conditioning . . . . . . . . . . . . . . . . . 7 64 1.4.4 Differentiated Services Code Point (DSCP) . . . . . . 8 65 1.4.5 Per-Hop Behavior (PHB) . . . . . . . . . . . . . . . . 8 66 1.5 Key Service Concepts . . . . . . . . . . . . . . . . . . . 8 67 1.5.1 Default Forwarding (DF) . . . . . . . . . . . . . . . 9 68 1.5.2 Assured Forwarding (AF) . . . . . . . . . . . . . . . 9 69 1.5.3 Expedited Forwarding (EF) . . . . . . . . . . . . . . 10 70 1.5.4 Class Selector (CS) . . . . . . . . . . . . . . . . . 10 71 1.5.5 Admission Control . . . . . . . . . . . . . . . . . . 11 72 2. Service Differentiation . . . . . . . . . . . . . . . . . . . 11 73 2.1 Service Classes . . . . . . . . . . . . . . . . . . . . . 11 74 2.2 Categorization of User Service Classes . . . . . . . . . . 13 75 2.3 Service Class Characteristics . . . . . . . . . . . . . . 16 76 2.4 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 21 77 2.4.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . 21 78 2.4.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . 22 79 2.4.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . 25 80 3. Network Control Traffic . . . . . . . . . . . . . . . . . . . 27 81 3.1 Current Practice in The Internet . . . . . . . . . . . . . 27 82 3.2 Network Control Service Class . . . . . . . . . . . . . . 27 83 3.3 OAM Service Class . . . . . . . . . . . . . . . . . . . . 29 84 4. User Traffic . . . . . . . . . . . . . . . . . . . . . . . . . 30 85 4.1 Telephony Service Class . . . . . . . . . . . . . . . . . 31 86 4.2 Signaling Service Class . . . . . . . . . . . . . . . . . 32 87 4.3 Multimedia Conferencing Service Class . . . . . . . . . . 34 88 4.4 Real-time Interactive Service Class . . . . . . . . . . . 37 89 4.5 Multimedia Streaming Service Class . . . . . . . . . . . . 38 90 4.6 Broadcast Video Service Class . . . . . . . . . . . . . . 40 91 4.7 Low Latency Data Service Class . . . . . . . . . . . . . . 42 92 4.8 High Throughput Data Service Class . . . . . . . . . . . . 44 93 4.9 Standard Service Class . . . . . . . . . . . . . . . . . . 46 94 4.10 Low Priority Data . . . . . . . . . . . . . . . . . . . . 47 95 5. Additional Information on Service Class Usage . . . . . . . . 48 96 5.1 Mapping for Signaling . . . . . . . . . . . . . . . . . . 48 97 5.2 Mapping for NTP . . . . . . . . . . . . . . . . . . . . . 48 98 5.3 VPN Service Mapping . . . . . . . . . . . . . . . . . . . 49 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 49 100 7. Summary of Changes from Previous Draft . . . . . . . . . . . . 50 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51 102 9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 51 103 9.1 Explanation of Ring Clipping . . . . . . . . . . . . . . . 51 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 105 10.1 Normative References . . . . . . . . . . . . . . . . . . . 52 106 10.2 Informative References . . . . . . . . . . . . . . . . . . 53 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 54 108 Intellectual Property and Copyright Statements . . . . . . . . 56 110 1. Introduction 112 This paper summarizes the recommended correlation between service 113 classes and their usage, with references to their corresponding 114 recommended Differentiated Service Code Points (DSCP), traffic 115 conditioners, Per-Hop Behaviors (PHB) and Active Queue Management 116 (AQM) mechanisms. There is no intrinsic requirement that particular 117 DSCPs, traffic conditioner PHBs and AQM be used for a certain service 118 class, but as a policy it is useful that they be applied consistently 119 across the network. 121 Service classes are defined based on the different traffic 122 characteristics and required performance of the applications/ 123 services. This approach allows us to map current and future 124 applications/services of similar traffic characteristics and 125 performance requirements into the same service class. Since the 126 applications'/services' characteristics and required performance are 127 end to end, the service class notion needs to be preserved end to 128 end. With this approach, a limited set of service classes is 129 required. For completeness, we have defined twelve different service 130 classes, two for network operation/administration and ten for user/ 131 subscriber applications/services. However, we expect that network 132 administrators will implement a subset of these classes relevant to 133 their customers and their service offerings. Network Administrators 134 may also find it of value to add locally defined service classes, 135 although these will not necessarily enjoy end to end properties of 136 the same type. 138 Section 1, provides an introduction and overview of technologies that 139 are used for service differentiation in IP networks. Section 2, is 140 an overview of how service classes are constructed to provide service 141 differentiation with examples of deployment scenarios. Section 3, 142 provides configuration guidelines of service classes that are used 143 for stable operation and administration of the network. Section 4, 144 provides configuration guidelines of service classes that are used 145 for differentiation of user/subscriber traffic. Section 5, provides 146 additional guidance on mapping different applications/protocol to 147 service classes. Section 6, address security considerations. 149 1.1 Requirements Notation 151 The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL 152 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 153 this document are to be interpreted as described in [RFC2119]. 155 1.2 Expected use in the Network 157 In the Internet today, corporate LANs and ISP WANs are generally not 158 heavily utilized - they are commonly 10% utilized at most. For this 159 reason, congestion, loss, and variation in delay within corporate 160 LANs and ISP backbones is virtually unknown. This clashes with user 161 perceptions, for three very good reasons. 162 o The industry moves through cycles of bandwidth boom and bandwidth 163 bust, depending on prevailing market conditions and the periodic 164 deployment of new bandwidth-hungry applications. 165 o In access networks, the state is often different. This may be 166 because throughput rates are artificially limited, or are over 167 subscribed, or because of access network design trade-offs. 168 o Other characteristics, such as database design on web servers 169 (that may create contention points, e.g. in filestore), and 170 configuration of firewalls and routers, often look externally like 171 a bandwidth limitation. 173 The intent of this document is to provide a consistent marking, 174 conditioning and packet treatment strategy so that it can be 175 configured and put into service on any link which itself is 176 congested. 178 1.3 Service Class Definition 180 A "service class" represents a set of traffic that requires specific 181 delay, loss and jitter characteristics from the network for which a 182 consistent and defined per-hop behavior (PHB) [RFC2474] applies. 183 Conceptually, a service class pertains to applications with similar 184 characteristics and performance requirements, such as a "High 185 Throughput Data" service class for applications like the web and 186 electronic mail, or a "Telephony" service class for real-time traffic 187 such as voice and other telephony services. Such service class may 188 be defined locally in a Differentiated Services domain, or across 189 multiple DS domains, including possibly extending end to end. 191 A Service Class as defined here is essentially a statement of the 192 required characteristics of a traffic aggregate; the actual 193 specification of the expected treatment of a traffic aggregate within 194 a domain may also be defined as a Per Domain Behavior [RFC3086]. 196 The Default Forwarding "Standard" service class is REQUIRED, all 197 other service classes are OPTIONAL. It is expected that network 198 administrators will choose the level of service differentiation that 199 they will support based on their need, starting off with three or 200 four service classes for user traffic and add others as the need 201 arises. 203 1.4 Key Differentiated Services Concepts 205 The reader SHOULD be familiar with the principles of the 206 Differentiated Services Architecture [RFC2474]. However, we 207 recapitulate key concepts here to save searching. 209 1.4.1 Queuing 211 A queue is a data structure that holds packets that are awaiting 212 transmission. The packets may be delayed while in the queue, 213 possibly due to lack of bandwidth, or because it is low in priority. 214 There are a number of ways to implement a queue, a simple model of a 215 queuing system, however, is a set of data structures for packet data, 216 which we will call queues and a mechanism for selecting the next 217 packet from among them, which we call a scheduler. 219 1.4.1.1 Priority Queuing 221 A priority queuing system is a combination of a set of queues and a 222 scheduler that empties them in priority sequence. When asked for a 223 packet, the scheduler inspects the highest priority queue, and if 224 there is data present returns a packet from that queue. Failing 225 that, it inspects the next highest priority queue, and so on. A 226 freeway onramp with a stoplight for one lane, but which allows 227 vehicles in the high occupancy vehicle lane to pass, is an example of 228 a priority queuing system; the high occupancy vehicle lane represents 229 the "queue" having priority. 231 In a priority queuing system, a packet in the highest priority queue 232 will experience a readily calculated delay - it is proportional to 233 the amount of data remaining to be serialized when the packet arrived 234 plus the volume of the data already queued ahead of it in the same 235 queue. The technical reason for using a priority queue relates 236 exactly to this fact: it limits delay and variations in delay, and 237 should be used for traffic which has that requirement. 239 A priority queue or queuing system needs to avoid starvation of lower 240 priority queues. This may be achieved through a variety of means 241 such as admission control, rate control, or network engineering. 243 1.4.1.2 Rate Queuing 245 Similarly, a rate-based queuing system is a combination of a set of 246 queues and a scheduler that empties each at a specified rate. An 247 example of a rate based queuing system is a road intersection with a 248 stoplight - the stoplight acts as a scheduler, giving each lane a 249 certain opportunity to pass traffic through the intersection. 251 In a rate-based queuing system, such as WFQ or WRR, the delay that a 252 packet in any given queue will experience is dependant on the 253 parameters and occupancy of its queue and the parameters and 254 occupancy of the queues it is competing with. A queue whose traffic 255 arrival rate is much less than the rate at which it lets traffic 256 depart will tend to be empty and packets in it will experience 257 nominal delays. A queue whose traffic arrival rate approximates or 258 exceeds its departure rate will tend to be not empty, and packets in 259 it will experience greater delay. Such a scheduler can impose a 260 minimum rate, a maximum rate, or both, on any queue it touches. 262 1.4.2 Active Queue Management 264 "Active queue management" or AQM is a generic name for any of a 265 variety of procedures that use packet dropping or marking to manage 266 the depth of a queue. The canonical example of such a procedure is 267 Random Early Detection, in that a queue is assigned a minimum and 268 maximum threshold, and the queuing algorithm maintains a moving 269 average of the queue depth. While the mean queue depth exceeds the 270 maximum threshold, all arriving traffic is dropped. While the mean 271 queue depth exceeds the minimum threshold but not the maximum 272 threshold, a randomly selected subset of arriving traffic is marked 273 or dropped. This marking or dropping of traffic is intended to 274 communicate with the sending system, causing its congestion avoidance 275 algorithms to kick in. As a result of this behavior, it is 276 reasonable to expect that TCP's cyclic behavior is desynchronized, 277 and the mean queue depth (and therefore delay) should normally 278 approximate the minimum threshold. 280 A variation of the algorithm is applied in Assured Forwarding PHB 281 [RFC2597], in that the behavior aggregate consists of traffic with 282 multiple DSCP marks, which are intermingled in a common queue. 283 Different minima and maxima are configured for the several DSCPs 284 separately, such that traffic that exceeds a stated rate at ingress 285 is more likely to be dropped or marked than traffic that is within 286 its contracted rate. 288 1.4.3 Traffic Conditioning 290 Additionally, at the first router in a network that a packet crosses, 291 arriving traffic may be measured, and dropped or marked according to 292 a policy, or perhaps shaped on network ingress as in A Rate Adaptive 293 Shaper for Differentiated Services [RFC2963]. This may be used to 294 bias feedback loops, such as is done in Assured Forwarding PHB 295 [RFC2597], or to limit the amount of traffic in a system, as is done 296 in Expedited Forwarding PHB [RFC3246]. Such measurement procedures 297 are collectively referred to as "traffic conditioners". Traffic 298 conditioners are normally built using token bucket meters, for 299 example with a committed rate and a burst size, as in Section 1.5.3 300 of DiffServ Model [RFC3290]. With multiple rate and burst size 301 measurements added to the basic single rate single burst size token 302 bucket meter to achieve multiple levels of conformance used by 303 Assured Forwarding PHB [RFC2597]. Multiple rates and burst sizes can 304 be realized using multiple levels of token buckets or more complex 305 token buckets, these are implementation details. Some traffic 306 conditioners that may be used in deployment of differentiated 307 services are: 308 o For Class Selector (CS) PHBs, a single token bucket meter to 309 provide a rate plus burst size control 310 o For Expedited Forwarding (EF) PHB, a single token bucket meter to 311 provide a rate plus burst size control 312 o For Assured Forwarding (AF) PHBs, usually two token buckets meters 313 configured to provide behavior as outlined in Two Rate Three Color 314 Marker (trTCM) [RFC2698] or the Single Rate Three Color Marker 315 (srTCM) [RFC2697]. The two rate three color marker is used to 316 enforce two rates whereas, the single rate three color marker is 317 used to enforce a committed rate with two burst lengths. 319 1.4.4 Differentiated Services Code Point (DSCP) 321 The DSCP is a number in the range 0..63, that is placed into an IP 322 packet to mark it according to the class of traffic it belongs in. 323 Half of these values are earmarked for standardized services, and the 324 other half of them are available for local definition. 326 1.4.5 Per-Hop Behavior (PHB) 328 In the end, the mechanisms described above are combined to form a 329 specified set of characteristics for handling different kinds of 330 traffic, depending on the needs of the application. This document 331 seeks to identify useful traffic aggregates and specify what PHB 332 should be applied to them. 334 1.5 Key Service Concepts 336 While Differentiated Services is a general architecture that may be 337 used to implement a variety of services, three fundamental forwarding 338 behaviors have been defined and characterized for general use. These 339 are basic Default Forwarding (DF) behavior for elastic traffic, the 340 Assured Forwarding (AF) behavior, and the Expedited Forwarding (EF) 341 behavior for real-time (inelastic) traffic. The facts that four code 342 points are recommended for AF, and that one code point is recommended 343 for EF, are arbitrary choices, and the architecture allows any 344 reasonable number of AF and EF classes simultaneously. The choice of 345 four AF classes and one EF class in the current document is also 346 arbitrary, and operators MAY choose to operate more or fewer of 347 either. 349 The terms "elastic" and "real-time" are defined in [RFC1633] Section 350 3.1, as a way of understanding broad brush application requirements. 351 This document should be reviewed to obtain a broad understanding of 352 the issues in quality of service, just as [RFC2475] should be 353 reviewed to understand the data plane architecture used in today's 354 Internet. 356 1.5.1 Default Forwarding (DF) 358 The basic forwarding behavior applied to any class of traffic are 359 those described in [RFC2474] and [RFC2309]. Best Effort service may 360 be summarized as "I will accept your packets", and is typically 361 configured with some bandwidth guarantee. Packets in transit may be 362 lost, reordered, duplicated, or delayed at random. Generally, 363 networks are engineered to limit this behavior, but changing traffic 364 loads can push any network into such a state. 366 Application traffic in the internet which uses default forwarding is 367 expected to be "elastic" in nature. By this, we mean that the sender 368 of traffic will adjust its transmission rate in response to changes 369 in available rate, loss, or delay. 371 For the basic best effort service, a single DSCP value is provided to 372 identify the traffic, a queue to store it, and active queue 373 management to protect the network from it and to limit delays. 375 1.5.2 Assured Forwarding (AF) 377 The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled 378 on Frame Relay's DE flag or ATM's CLP capability, and is intended for 379 networks that offer average-rate SLAs (as FR and ATM networks do). 380 This is an enhanced best effort service; traffic is expected to be 381 "elastic" in nature. The receiver will detect loss or variation in 382 delay in the network and provide feedback such that the sender 383 adjusts its transmission rate to approximate available capacity. 385 For such behaviors, multiple DSCP values are provided (two or three, 386 perhaps more using local values) to identify the traffic, a common 387 queue to store the aggregate and active queue management to protect 388 the network from it and to limit delays. Traffic is metered as it 389 enters the network, and traffic is variously marked depending on the 390 arrival rate of the aggregate. The premise is that it is normal for 391 users to occasionally use more capacity than their contract 392 stipulates, perhaps up to some bound. However, if traffic SHOULD be 393 lost or marked to manage the queue, this excess traffic will be 394 marked or lost first. 396 1.5.3 Expedited Forwarding (EF) 398 Expedited Forwarding PHB [RFC3246] behavior was originally proposed 399 as a way to implement a virtual wire, and can be used in such a 400 manner. It is an enhanced best effort service: traffic remains 401 subject to loss due to line errors and reordering during routing 402 changes. However, using queuing techniques, the probability of delay 403 or variation in delay is minimized. For this reason, it is generally 404 used to carry voice and for transport of data information that 405 requires "wire like" behavior through the IP network. Voice is an 406 inelastic "real-time" application that sends packets at the rate the 407 codec produces them, regardless of availability of capacity. As 408 such, this service has the potential to disrupt or congest a network 409 if not controlled. It also has the potential for abuse. 411 To protect the network, at minimum one SHOULD police traffic at 412 various points to ensure that the design of a queue is not over-run, 413 and then the traffic SHOULD be given a low delay queue (often using 414 priority, although it is asserted that a rate-based queue can do 415 this) to ensure that variation in delay is not an issue, to meet 416 application needs. 418 1.5.4 Class Selector (CS) 420 Class Selector provides support for historical codepoint definitions 421 and PHB requirement. The Class Selector DS field provides a limited 422 backward compatibility with legacy (pre DiffServ) practice, as 423 described in [RFC2474] Section 4. Backward compatibility is 424 addressed in two ways. First, there are per-hop behaviors that are 425 already in widespread use (e.g. those satisfying the IPv4 Precedence 426 queuing requirements specified in [RFC1812], and we wish to permit 427 their continued use in DS-compliant networks. In addition, there are 428 some codepoints that correspond to historical use of the IP 429 Precedence field and we reserve these codepoints to map to PHBs that 430 meet the general requirements specified in [RFC2474] Section 4.2.2.2. 432 No attempt is made to maintain backward compatibility with the "DTR" 433 or TOS bits of the IPv4 TOS octet, as defined in [RFC0791]and 434 [RFC1349]. 436 A DS-compliant network can be deployed with a set of one or more 437 Class Selector compliant PHB groups. As well, network administrator 438 may configure the network nodes to map codepoints to PHBs 439 irrespective of bits 3-5 of the DSCP field to yield a network that is 440 compatible with historical IP Precedence use. Thus, for example, 441 codepoint '011000' would map to the same PHB as codepoint '011010'. 443 1.5.5 Admission Control 445 Admission control including refusal when policy thresholds are 446 crossed, can assure high quality communication by ensuring the 447 availability of bandwidth to carry a load. Inelastic real-time flows 448 like VoIP (telephony) or video conferencing services can benefit from 449 use of admission control mechanism, as generally the telephony 450 service is configured with over subscription, meaning that some 451 user(s) may not be able to make a call during peak periods. 453 For VoIP (telephony) service, a common approach is to use signaling 454 protocols such as SIP, H.323, H.248, MEGACO, RSVP, etc. to negotiate 455 admittance and use of network transport capabilities. When a user 456 has been authorized to send voice traffic, this admission procedure 457 has verified that data rates will be within the capacity of the 458 network that it will use. Since RTP voice does not react to loss or 459 delay in any substantive way, the network SHOULD police at ingress to 460 ensure that the voice traffic stays within its negotiated bounds. 461 Having thus assured a predictable input rate, the network may use a 462 priority queue to ensure nominal delay and variation in delay. 464 Another approach that may be used in small and bandwidth constrained 465 networks for limited number of flows is RSVP [RFC2205] [RFC2996]. 466 However, there is concern with the scalability of this solution in 467 large networks where aggregation of reservations[RFC3175] is 468 considered to be required. 470 2. Service Differentiation 472 There are practical limits on the level of service differentiation 473 that should be offered in the IP networks. We believe we have 474 defined a practical approach in delivering service differentiation by 475 defining different service classes that networks may choose to 476 support to provide the appropriate level of behaviors and performance 477 needed by current and future applications and services. The defined 478 structure for providing services allows several applications having 479 similar traffic characteristics and performance requirements to be 480 grouped into the same service class. This approach provides a lot of 481 flexibility in providing the appropriate level of service 482 differentiation for current and new yet unknown applications without 483 introducing significant changes to routers or network configurations 484 when a new traffic type is added to the network. 486 2.1 Service Classes 488 Traffic flowing in a network can be classified in many different 489 ways. We have chosen to divide it into two groupings, network 490 control and user/subscriber traffic. To provide service 491 differentiation, different service classes are defined in each 492 grouping. The network control traffic group can further be divided 493 into two service classes (see Section 3 for detailed definition of 494 each service class): 495 o "Network Control" for routing and network control function. 496 o "OAM" (Operations, Administration and Management) for network 497 configuration and management functions. 499 The user/subscriber traffic group is broken down into ten service 500 classes to provide service differentiation for all the different 501 types of applications/services, (see Section 4 for detailed 502 definition of each service class) in summary: 503 o Telephony service class is best suited for applications that 504 require very low delay variation and are of constant rate, such as 505 IP telephony (VoIP) and circuit emulation over IP applications. 506 o Signaling service class is best suited for peer-to-peer and 507 client-server signaling and control functions using protocols such 508 as SIP, SIP-T, H.323, H.248, MGCP, etc. 509 o Multimedia Conferencing service class is best suited for 510 applications that require very low delay, and have the ability to 511 change encoding rate (rate adaptive), such as H.323/V2 and later 512 video conferencing service. 513 o Real-time Interactive service class is intended for interactive 514 variable rate inelastic applications that require low jitter, loss 515 and very low delay, such as interactive gaming applications that 516 use RTP/UDP streams for game control commands, video conferencing 517 applications that do not have the ability to change encoding rates 518 or mark packets with different importance indications, etc. 519 o Multimedia Streaming service class is best suited for variable 520 rate elastic streaming media applications where a human is waiting 521 for output and where the application has the capability to react 522 to packet loss by reducing its transmission rate, such as 523 streaming video and audio, web cast, etc. 524 o Broadcast Video service class is best suited for inelastic 525 streaming media applications that may be of constant or variable 526 rate, requiring low jitter and very low packet loss, such as 527 broadcast TV and live events, video surveillance and security. 528 o Low Latency Data service class is best suited for data processing 529 applications where a human is waiting for output, such as web- 530 based ordering, Enterprise Resource Planning (ERP) application, 531 etc. 532 o High Throughput Data service class is best suited for store and 533 forward applications such as FTP, billing record transfer, etc. 534 o Standard service class is for traffic that has not been identified 535 as requiring differentiated treatment and is normally referred as 536 best effort. 538 o Low Priority Data service class is intended for packet flows where 539 bandwidth assurance is not required. 541 2.2 Categorization of User Service Classes 543 The ten defined user/subscriber services classes listed above can be 544 grouped into a small number of application categories. For some 545 application categories, it was felt that more than one service class 546 was needed to provide service differentiation within that category 547 due to the different traffic characteristic of the applications, 548 control function and the required flow behavior. Figure 1 provides 549 summary of service class grouping into four application categories. 551 Application Control category: 552 o The Signaling service class is intended to be used to control 553 applications or user endpoints. Examples of protocols that would 554 use this service class are, SIP or H.248 for IP telephone service 555 and SIP or IGMP for control of broadcast TV service to 556 subscribers. Although user signaling flows have similar 557 performance requirements as Low Latency Data they need to be 558 distinguished and marked with a different DSCP. The essential 559 distinction is something like "administrative control and 560 management" of the traffic affected as the protocols in this class 561 tend to be tied to the media stream/session they signal and 562 control. 564 Media-Oriented category: Due to the vest number of new (in process of 565 being deployed) and already in uses media-oriented services in IP 566 networks, five service classes have been defined. 567 o Telephony service class is intended for IP telephony (VoIP) 568 service as well it may be used for other applications that meet 569 the defined traffic characteristics and performance requirements. 570 o Real-time Interactive service class is intended for inelastic 571 video flows from such application like SIP based desktop video 572 conferencing applications and for interactive gaming. 573 o Multimedia Conferencing service class is for video conferencing 574 solutions that have the ability to reduce their transmission rate 575 on detection of congestion, therefore these flows can be 576 classified as rate adaptive. As currently there are both types of 577 video conferencing equipment used in IP networks, ones that 578 generate inelastic and ones that generate rate adaptive traffic, 579 therefore two service class are needed. Real-time Interactive 580 service class should be used for equipment that generate inelastic 581 video flows and Multimedia Conferencing service class for 582 equipment that generate rate adaptive video flows. 583 o Broadcast Video service class is to be used for inelastic traffic 584 flows which is intended for broadcast TV service and for transport 585 of live video and audio events. 587 o Multimedia Streaming service class is to be used for elastic 588 multimedia traffic flows. This multimedia content is typically 589 stored before being transmitted, as well it is buffered at the 590 receiving end before being played out. The buffering is 591 sufficient large to accommodate any variation in transmission rate 592 that is encountered in the network. Multimedia entertainment over 593 IP delivery services that are being developed can generate both 594 elastic and/or inelastic traffic flows, therefore two service 595 classes are defined to address this space. 597 Data category: The data category is divided into three service 598 classes. 599 o Low Latency Data for applications/services that require low delay 600 or latency for bursty but short lived flows. 601 o High Throughput Data for applications/services that require good 602 throughput for long lived bursty flows. High Throughput and 603 Multimedia Steaming are close in their traffic flow 604 characteristics with High Throughput being a bit more bursty and 605 not as long lived as Multimedia Steaming. 606 o Low Priority Data for applications or services that can tolerate 607 short or long interruptions of packet flows. Low Priority Data 608 service class can be viewed as don't care to some degree. 610 Best Effort category: 611 o All traffic that is not differentiated in the network falls into 612 this category and is mapped into the Standard service class. If a 613 packet is marked with a DSCP value that is not supported in the 614 network, it SHOULD be forwarded using the Standard service class. 616 Figure 1 below provides a grouping of the defined user/subscriber 617 service classes into four categories with indications of which ones 618 use an independent flow for signaling or control, type of flow 619 behavior elastic, rate adaptive or inelastic and finally the last 620 column provides end user QoS rating as defined in ITU-T 621 Recommendation G.1010. 623 ----------------------------------------------------------------- 624 | Application | Service | Signaled | Flow | G.1010 | 625 | Categories | Class | | Behavior | Rating | 626 |-------------+---------------+----------+-----------+------------| 627 | Application | Signaling | N.A. | Inelastic | Responsive | 628 | Control | | | | | 629 |-------------+---------------+----------+-----------+------------| 630 | | Telephony | Yes | Inelastic | Interactive| 631 | |---------------+----------+-----------+------------| 632 | | Real-time | Yes | Inelastic | Interactive| 633 | | Interactive | | | | 634 | |---------------+----------+-----------+------------| 635 | Media- | Multimedia | Yes | Rate | Interactive| 636 | Oriented | Conferencing | | Adaptive | | 637 | |---------------+----------+-----------+------------| 638 | |Broadcast Video| Yes | Inelastic | Responsive | 639 | |---------------+----------+-----------+------------| 640 | | Multimedia | Yes | Elastic | Timely | 641 | | Streaming | | | | 642 |-------------+---------------+----------+-----------+------------| 643 | | Low Latency | No | Elastic | Responsive | 644 | | Data | | | | 645 | |---------------+----------+-----------+------------| 646 | Data |High Throughput| No | Elastic | Timely | 647 | | Data | | | | 648 | |---------------+----------+-----------+------------| 649 | | Low Priority | No | Elastic |Non-critical| 650 | | Data | | | | 651 |-------------+---------------+----------+-----------+------------| 652 | Best Effort | Standard | Not Specified |Non-critical| 653 ----------------------------------------------------------------- 654 Note: N.A. = Not Applicable. 656 Figure 1: User/Subscriber Service Classes Grouping 658 Here is a short explanation of end user QoS category as defined in 659 ITU-T Recommendation G.1010. User traffic is divided into four 660 different categories, namely, interactive, responsive, timely, and 661 non-critical. An example of interactive traffic is between two 662 humans and is most sensitive to delay, loss and jitter. Another 663 example of interactive traffic is between two servers where very low 664 delay and loss is needed. Responsive traffic is typically between a 665 human and a server but also can be between two servers. Responsive 666 traffic is less affected by jitter and can tolerate longer delays 667 than interactive traffic. Timely traffic is either between servers 668 or servers and humans and the delay tolerance is significantly longer 669 than responsive traffic. Non-critical traffic is normally between 670 servers/machines where delivery may be delay for period of time. 672 2.3 Service Class Characteristics 674 This draft provides guidelines for network administrator in 675 configuring their network for the level of service differentiation 676 that is appropriate in their network to meet their QoS needs. It is 677 expected that network operators will configure and provide in their 678 networks a subset of the defined service classes. Our intent is to 679 provide guidelines for configuration of Differentiated Services for a 680 wide variety of applications, services and network configurations. 681 Additionally, network administrators may choose to define and deploy 682 in their network other service classes. 684 Figure 2 provides a behavior view for traffic serviced by each 685 service class. The traffic characteristics column defines the 686 characteristics and profile of flows serviced and the tolerance to 687 loss, delay and jitter columns define the treatment the flows will 688 receive. End-to-end quantitative performance requirements may be 689 obtained from ITU-T Recommendation Y.1541 and Y.1540. There is also 690 new work currently underway in ITU-T that applies to the service 691 classes defined in this document. 693 ------------------------------------------------------------------- 694 |Service Class | | Tolerance to | 695 | Name | Traffic Characteristics | Loss |Delay |Jitter| 696 |===============+==============================+======+======+======| 697 | Network |Variable size packets, mostly | | | | 698 | Control |inelastic short messages, but | Low | Low | Yes | 699 | | traffic can also burst (BGP) | | | | 700 |---------------+------------------------------+------+------+------| 701 | | Fixed size small packets, | Very | Very | Very | 702 | Telephony | constant emission rate, | Low | Low | Low | 703 | | inelastic and low rate flows | | | | 704 |---------------+------------------------------+------+------+------| 705 | Signaling | Variable size packets, some | Low | Low | Yes | 706 | | what bursty short lived flows| | | | 707 |---------------+------------------------------+------+------+------| 708 | Multimedia | Variable size packets, | Low | Very | | 709 | Conferencing | constant transmit interval, | - | Low | Low | 710 | |rate adaptive, reacts to loss |Medium| | | 711 |---------------+------------------------------+------+------+------| 712 | Real-time | RTP/UDP streams, inelastic, | Low | Very | Low | 713 | Interactive | mostly variable rate | | Low | | 714 |---------------+------------------------------+------+------+------| 715 | Multimedia | Variable size packets, |Low - |Medium| Yes | 716 | Streaming | elastic with variable rate |Medium| | | 717 |---------------+------------------------------+------+------+------| 718 | Broadcast | Constant and variable rate, | Very |Medium| Low | 719 | Video | inelastic, non bursty flows | Low | | | 720 |---------------+------------------------------+------+------+------| 721 | Low Latency | Variable rate, bursty short | Low |Low - | Yes | 722 | Data | lived elastic flows | |Medium| | 723 |---------------+------------------------------+------+------+------| 724 | OAM | Variable size packets, | Low |Medium| Yes | 725 | | elastic & inelastic flows | | | | 726 |---------------+------------------------------+------+------+------| 727 |High Throughput| Variable rate, bursty long | Low |Medium| Yes | 728 | Data | lived elastic flows | |- High| | 729 |---------------+------------------------------+------+------+------| 730 | Standard | A bit of everything | Not Specified | 731 |---------------+------------------------------+------+------+------| 732 | Low Priority | Non real-time and elastic | High | High | Yes | 733 | Data | | | | | 734 ------------------------------------------------------------------- 736 Figure 2: Service Class Characteristics 738 Note: A "Yes" in the jitter-tolerant column implies that data is 739 buffered in the endpoint, and a moderate level of network-induced 740 variation in delay will not affect the application. Applications 741 that use TCP as a transport are generally good examples. Routing 742 protocols and peer-to-peer signaling also fall in this class; while 743 loss can create problems in setting up calls, a moderate level of 744 jitter merely makes call placement a little less predictable in 745 duration. 747 Service classes indicate the required traffic forwarding treatment in 748 order to meet user, application or network expectations. Section 3in 749 this document defines the service classes that MAY be used for 750 forwarding network control traffic and Section 4 defines the service 751 classes that MAY be used for forwarding user traffic with examples of 752 intended application types mapped into each service class. Note that 753 the application types are only examples and are not meant to be all- 754 inclusive or prescriptive. Also it should be noted that the service 755 class naming or ordering does not imply any priority ordering. They 756 are simply reference names that are used in this document with 757 associated QoS behaviors that are optimized for the particular 758 application types they support. Network administrators MAY choose to 759 assign different service class names, to the service classes that 760 they will support. Figure 3 defines the RECOMMENDED relationship 761 between service classes and DS codepoint(s) assignment with 762 application examples. It is RECOMMENDED that this relationship be 763 preserved end to end. 765 ------------------------------------------------------------------ 766 | Service | DSCP | DSCP | Application | 767 | Class name | name | value | Examples | 768 |===============+=========+=============+==========================| 769 |Network Control| CS6 | 110000 | Network routing | 770 |---------------+---------+-------------+--------------------------| 771 | Telephony | EF | 101110 | IP Telephony bearer | 772 |---------------+---------+-------------+--------------------------| 773 | Signaling | CS5 | 101000 | IP Telephony signaling | 774 |---------------+---------+-------------+--------------------------| 775 | Multimedia |AF41,AF42|100010,100100| H.323/V2 video | 776 | Conferencing | AF43 | 100110 | conferencing (adaptive) | 777 |---------------+---------+-------------+--------------------------| 778 | Real-time | CS4 | 100000 | Video conferencing and | 779 | Interactive | | | Interactive gaming | 780 |---------------+---------+-------------+--------------------------| 781 | Multimedia |AF31,AF32|011010,011100| Streaming video and | 782 | Streaming | AF33 | 011110 | audio on demand | 783 |---------------+---------+-------------+--------------------------| 784 |Broadcast Video| CS3 | 011000 |Broadcast TV & live events| 785 |---------------+---------+-------------+--------------------------| 786 | Low Latency |AF21,AF22|010010,010100|Client/server transactions| 787 | Data | AF23 | 010110 | Web-based ordering | 788 |---------------+---------+-------------+--------------------------| 789 | OAM | CS2 | 010000 | OAM&P | 790 |---------------+---------+-------------+--------------------------| 791 |High Throughput|AF11,AF12|001010,001100| Store and forward | 792 | Data | AF13 | 001110 | applications | 793 |---------------+---------+-------------+--------------------------| 794 | Standard | DF,(CS0)| 000000 | Undifferentiated | 795 | | | | applications | 796 |---------------+---------+-------------+--------------------------| 797 | Low Priority | CS1 | 001000 | Any flow that has no BW | 798 | Data | | | assurance | 799 ------------------------------------------------------------------ 801 Figure 3: DSCP to Service Class Mapping 803 Note for Figure 3: 804 o Default Forwarding (DF) and Class Selector 0 (CS0) provide 805 equivalent behavior and use the same DS codepoint '000000'. 807 It is expected that network administrators will choose the service 808 classes that they will support based on their need, starting off with 809 three or four service classes for user traffic and add others as the 810 need arises. 812 Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD be 813 used for the defined service classes that are further detailed in 814 Section 3 and Section 4 of this document. Based on what 815 applications/services that need to be differentiated, network 816 administrators can choose the service class(es) that need to be 817 supported in their network. 818 ------------------------------------------------------------------ 819 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| 820 | Class | | DS Edge | Used | | | 821 |===============+======+===================+=========+========+====| 822 |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate |Yes | 823 |---------------+------+-------------------+---------+--------+----| 824 | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | 825 |---------------+------+-------------------+---------+--------+----| 826 | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | 827 |---------------+------+-------------------+---------+--------+----| 828 | Multimedia | AF41 | Using two rate | | | Yes| 829 | Conferencing | AF42 |three color marker | RFC2597 | Rate | per| 830 | | AF43 | (such as RFC2698) | | |DSCP| 831 |---------------+------+-------------------+---------+--------+----| 832 | Real-time | CS4 |Police using sr+bs | RFC2474 | Rate | No | 833 | Interactive | | | | | | 834 |---------------+------+-------------------+---------|--------+----| 835 | Multimedia | AF31 | Using two rate | | | Yes| 836 | Streaming | AF32 |three color marker | RFC2597 | Rate | per| 837 | | AF33 | (such as RFC2698) | | |DSCP| 838 |---------------+------+-------------------+---------+--------+----| 839 |Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No | 840 |---------------+------+-------------------+---------+--------+----| 841 | Low | AF21 | Using single rate | | | Yes| 842 | Latency | AF22 |three color marker | RFC2597 | Rate | per| 843 | Data | AF23 | (such as RFC2697) | | |DSCP| 844 |---------------+------+-------------------+---------+--------+----| 845 | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| 846 |---------------+------+-------------------+---------+--------+----| 847 | High | AF11 | Using two rate | | | Yes| 848 | Throughput | AF12 |three color marker | RFC2597 | Rate | per| 849 | Data | AF13 | (such as RFC2698) | | |DSCP| 850 |---------------+------+-------------------+---------+--------+----| 851 | Standard | DF | Not applicable | RFC2474 | Rate | Yes| 852 |---------------+------+-------------------+---------+--------+----| 853 | Low Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| 854 | Data | | | | | | 855 ------------------------------------------------------------------ 857 Figure 4: Summary of QoS Mechanisms used for each Service Class 859 Notes for Figure 4: 861 o Conditioning at DS edge, means that traffic conditioning is 862 performed at the edge of the DiffServ network where untrusted user 863 devices are connected or between two DiffServ networks. 864 o "sr+bs" represents a policing mechanism that provides single rate 865 with burst size control. 866 o The single rate three color marker (srTCM) behavior SHOULD be 867 equivalent to RFC 2697 and the two rate three color marker (trTCM) 868 behavior SHOULD be equivalent to RFC 2698. 869 o The PHB for Real-time Interactive service class SHOULD be 870 configured to provide high bandwidth assurance. It MAY be 871 configured as a second EF PHB that uses relaxed performance 872 parameters and a rate scheduler. 873 o The PHB for Broadcast Video service class SHOULD be configured to 874 provide high bandwidth assurance. It MAY be configured as a third 875 EF PHB that uses relaxed performance parameters and a rate 876 scheduler. 877 o In network segments that use IP precedence marking, only one of 878 the two service classes can be supported, High Throughput Data or 879 Low Priority Data. We RECOMMEND that the DSCP value(s) of the 880 unsupported service class to be changed to 000xx1 on ingress and 881 changed back to original value(s) on egress of the network segment 882 that uses precedence marking. For example, if Low Priority Data 883 is mapped to Standard service class, then 000001 DSCP marking MAY 884 be used to distinguish it from Standard marked packets on egress. 886 2.4 Deployment Scenarios 888 It is expected that network administrators will choose the service 889 classes that they will support based on their need, starting off with 890 three or four service classes for user traffic and add more service 891 classes as the need arises. In this section we provide three 892 examples of possible deployment scenarios. 894 2.4.1 Example 1 896 A network administrator determined that they need to provide 897 different performance levels (quality of service) in their network 898 for the services that they will be offering to their customers. They 899 need to enable their network to provide: 900 o Reliable VoIP (telephony) service, equivalent to PSTN 901 o A low delay assured bandwidth data service 902 o As well, support current Internet services 904 For this example, the network administrator's needs are addressed 905 with the deployment of the following six service classes: 906 o Network Control service class for routing and control traffic that 907 is needed for reliable operation of the provider's network 909 o Standard service class for all traffic that will receive normal 910 (undifferentiated) forwarding treatment through their network for 911 support of current Internet service 912 o Telephony service class for VoIP (telephony) bearer traffic 913 o Signaling service class for Telephony signaling to control the 914 VoIP service 915 o Low Latency Data service class for the low delay assured bandwidth 916 differentiated data service 917 o OAM service class for operation and management of the network 919 Figure 5, provides a summary of the mechanisms need for delivery of 920 service differentiation for Example 1. 921 ------------------------------------------------------------------- 922 | Service | DSCP | Conditioning at | PHB | | | 923 | Class | | DS Edge | Used | Queuing| AQM| 924 |===============+=======+===================+=========+========+====| 925 |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes| 926 |---------------+-------+-------------------+---------+--------+----| 927 | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | 928 |---------------+-------+-------------------+---------+--------+----| 929 | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | 930 |---------------+-------+-------------------+---------+--------+----| 931 | Low | AF21 | Using single rate | | |Yes | 932 | Latency | AF22 |three color marker | RFC2597 | Rate |Per | 933 | Data | AF23 | (such as RFC2697) | | |DSCP| 934 |---------------+-------+-------------------+---------+--------+----| 935 | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| 936 |---------------+-------+-------------------+---------+--------+----| 937 | Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes| 938 | | +other| | | | | 939 ------------------------------------------------------------------- 941 Figure 5: Service Provider Network Configuration Example 1 943 Notes for Figure 5: 944 o "sr+bs" represents a policing mechanism that provides single rate 945 with burst size control. 946 o The single rate three color marker (srTCM) behavior SHOULD be 947 equivalent to RFC 2697. 948 o Any packet that is marked with DSCP value that is not represented 949 by the supported service classes, SHOULD be forwarded using the 950 Standard service class. 952 2.4.2 Example 2 954 With this example we show how network operators with Example 1 955 capabilities can evolve their service offering to provide three new 956 additional services to their customers. The new additional service 957 capabilities that are to be added are: 958 o SIP based desktop video conference capability to complement VoIP 959 (telephony) service 960 o Provide TV and on demand movie viewing service to residential 961 subscribers 962 o Provide network based data storage and file backup service to 963 business customers 965 The new additional services that the network administrator would like 966 to offer are addressed with the deployment of the following four 967 additional service classes. (These are additions to the six service 968 classes already defined in Example 1): 969 o Real-time Interactive service class for transport of MPEG-4 real- 970 time video flows to support desktop video conferencing. The 971 control/signaling for video conferencing is done using the 972 Signaling service class. 973 o Broadcast Video service class for transport of IPTV broadcast 974 information. The channel selection and control is via IGMP 975 (Internet Group Management Protocol) mapped into the Signaling 976 service class. 977 o Multimedia Streaming service class for transport of stored MPEG-2 978 or MPEG-4 content. The selection and control of streaming 979 information is done using the Signaling service class. The 980 selection of Multimedia Streaming service class for on demand 981 movie service was chosen as the set-top box used for this service 982 has local buffering capability to compensate for the bandwidth 983 variability of the elastic streaming information. Note, if 984 transport of on demand movie service is inelastic, then the 985 Broadcast Video service class SHOULD be used. 986 o High Throughput Data service class is for transport of bulk data 987 for network based storage and file backup service to business 988 customers. 990 Figure 6, provides a summary of the mechanisms needed for delivery of 991 service differentiation for all the service classes used in Example 992 2. 994 ------------------------------------------------------------------- 995 | Service | DSCP | Conditioning at | PHB | | | 996 | Class | | DS Edge | Used | Queuing| AQM| 997 |===============+=======+===================+=========+========+====| 998 |Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes| 999 |---------------+-------+-------------------+---------+--------+----| 1000 | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | 1001 |---------------+-------+-------------------+---------+--------+----| 1002 | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | 1003 |---------------+-------+-------------------+---------+--------+----| 1004 | Real-time | CS4 |Police using sr+bs | RFC2474 | Rate | No | 1005 | Interactive | | | | | | 1006 |---------------+-------+-------------------+---------+--------+----| 1007 |Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No | 1008 |---------------+-------+-------------------+---------+--------+----| 1009 | Multimedia | AF31 | Using two rate | | |Yes | 1010 | Streaming | AF32 |three color marker | RFC2597 | Rate |Per | 1011 | | AF33 | (such as RFC2698) | | |DSCP| 1012 |---------------+-------+-------------------+---------+--------+----| 1013 | Low | AF21 | Using single rate | | |Yes | 1014 | Latency | AF22 |three color marker | RFC2597 | Rate |Per | 1015 | Data | AF23 | (such as RFC2697) | | |DSCP| 1016 |---------------+-------+-------------------+---------+--------+----| 1017 | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| 1018 |---------------+-------+-------------------+---------+--------+----| 1019 | High | AF11 | Using two rate | | |Yes | 1020 | Throughput | AF12 |three color marker | RFC2597 | Rate |Per | 1021 | Data | AF13 | (such as RFC2698) | | |DSCP| 1022 |---------------+-------+-------------------+---------+--------+----| 1023 | Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes| 1024 | | +other| | | | | 1025 ------------------------------------------------------------------- 1027 Figure 6: Service Provider Network Configuration Example 2 1029 Notes for Figure 6: 1030 o "sr+bs" represents a policing mechanism that provides single rate 1031 with burst size control. 1032 o The single rate three color marker (srTCM) behavior SHOULD be 1033 equivalent to RFC 2697 and the two rate three color marker (trTCM) 1034 behavior SHOULD be equivalent to RFC 2698. 1035 o Any packet that is marked with DSCP value that is not represented 1036 by the supported service classes, SHOULD be forwarded using the 1037 Standard service class. 1039 2.4.3 Example 3 1041 An enterprise network administrator determined that they need to 1042 provide different performance levels (quality of service) in their 1043 network for the new services that are being offered to corporate 1044 users. The enterprise network needs to: 1045 o Provide reliable corporate VoIP service 1046 o Provide video conferencing service to selected Conference Rooms 1047 o Support on demand distribution of prerecorded audio and video 1048 information to large number of users 1049 o Provide a priority data transfer capability for engineering teams 1050 to share design information 1051 o Reduce or deny bandwidth during peak traffic periods for selected 1052 applications 1053 o Continue to provide normal IP service to all remaining 1054 applications and services 1056 For this example, the enterprise's network needs are addressed with 1057 the deployment of the following nine service classes: 1058 o Network Control service class for routing and control traffic that 1059 is needed for reliable operation of the enterprise network 1060 o OAM service class for operation and management of the network 1061 o Standard service class for all traffic that will receive normal 1062 (undifferentiated) forwarding treatment 1063 o Telephony service class for VoIP (telephony) bearer traffic 1064 o Signaling service class for Telephony signaling to control the 1065 VoIP service 1066 o Multimedia Conferencing service class for support of inter 1067 Conference Room video conferencing service using H.323/V2 or 1068 similar equipment. 1069 o Multimedia Steaming service class for transfer of prerecorded 1070 audio and video information 1071 o High Throughput Data service class to provide bandwidth assurance 1072 for timely transfer of large engineering files 1073 o Low Priority Data service class for selected background 1074 applications where data transfer can be delayed or suspended for a 1075 period of time during peak network load conditions 1077 Figure 7, provides a summary of the mechanisms need for delivery of 1078 service differentiation for Example 3. 1080 ------------------------------------------------------------------- 1081 | Service | DSCP | Conditioning at | PHB | | | 1082 | Class | | DS Edge | Used | Queuing| AQM| 1083 |===============+=======+===================+=========+========+====| 1084 |Network Control| CS6 | See Section 3.2 | RFC2474 | Rate | Yes| 1085 |---------------+-------+-------------------+---------+--------+----| 1086 | Telephony | EF |Police using sr+bs | RFC3246 |Priority| No | 1087 |---------------+-------+-------------------+---------+--------+----| 1088 | Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No | 1089 |---------------+-------+-------------------+---------+--------+----| 1090 | Multimedia | AF41 | Using two rate | | | Yes| 1091 | Conferencing | AF42 | three color marker| RFC2597 | Rate | Per| 1092 | | AF43 | (such as RFC2698) | | |DSCP| 1093 |---------------+-------+-------------------+---------+--------+----| 1094 | Multimedia | AF31 | Using two rate | | | Yes| 1095 | Streaming | AF32 | three color marker| RFC2597 | Rate | Per| 1096 | | AF33 | (such as RFC2698) | | |DSCP| 1097 |---------------+-------+-------------------+---------+--------+----| 1098 | OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes| 1099 |---------------+-------+-------------------+---------+--------+----| 1100 | High | AF11 | Using two rate | | |Yes | 1101 | Throughput | AF12 |three color marker | RFC2597 | Rate |Per | 1102 | Data | AF13 | (such as RFC2698) | | |DSCP| 1103 |---------------+-------+-------------------+---------+--------+----| 1104 | Low Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| 1105 | Data | | | | | | 1106 |---------------+-------+-------------------+---------+--------+----| 1107 | Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes| 1108 | | +other| | | | | 1109 ------------------------------------------------------------------- 1111 Figure 7: Enterprise Network Configuration Example 1113 Notes for Figure 7: 1114 o The Administrative service class MAY be implemented using Rate 1115 queuing method as long as sufficient amount of bandwidth is 1116 guaranteed and latency of scheduler is sufficiently low to meet 1117 the requirement. 1118 o "sr+bs" represents a policing mechanism that provides single rate 1119 with burst size control. 1120 o The single rate three color marker (srTCM) behavior SHOULD be 1121 equivalent to RFC 2697 and the two rate three color marker (trTCM) 1122 behavior SHOULD be equivalent to RFC 2698. 1123 o Any packet that is marked with DSCP value that is not represented 1124 by the supported service classes, SHOULD be forwarded using the 1125 Standard service class. 1127 3. Network Control Traffic 1129 Network control traffic is defined as packet flows that are essential 1130 for stable operation of the administered network as well for 1131 information that may be exchanged between neighboring networks across 1132 a peering point where SLAs are in place. Network control traffic is 1133 different from user application control (signaling) that may be 1134 generated by some applications or services. Network control traffic 1135 is mostly between routers and network nodes that are used for 1136 operating, administering, controlling or managing the network 1137 segments. Network Control Traffic may be split into two service 1138 classes, i.e. Network Control and OAM. 1140 3.1 Current Practice in The Internet 1142 Based on today's routing protocols and network control procedures 1143 that are used in The Internet, we have determined that CS6 DSCP value 1144 SHOULD be used for routing and control and that CS7 DSCP value be 1145 reserved for future use, potentially for future routing and/or 1146 control protocols. Network administrator MAY use a Local/ 1147 Experimental DSCP therefore a locally defined service class within 1148 their network to further differentiate their routing and control 1149 traffic. 1151 RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets: 1152 o Drop or remark CS7 marked packets at ingress to DiffServ network 1153 domain. 1154 o CS7 marked packets SHOULD NOT be sent across peering points. 1155 Exchange of control information across peering points SHOULD be 1156 done using CS6 DSCP, using Network Control service class. 1158 3.2 Network Control Service Class 1160 The Network Control service class is used for transmitting packets 1161 between network devices (routers) that require control (routing) 1162 information to be exchanged between nodes within the administrative 1163 domain as well across a peering point between different 1164 administrative domains. Traffic transmitted in this service class is 1165 very important as it keeps the network operational and needs to be 1166 forwarded in a timely manner. 1168 The Network Control service class SHOULD be configured using the 1169 DiffServ Class Selector (CS) PHB defined in [RFC2474]. This service 1170 class SHOULD be configured so that the traffic receives a minimum 1171 bandwidth guarantee, to ensure that the packets always receive timely 1172 service. The configured forwarding resources for Network Control 1173 service class SHOULD be such that the probability of packet drop 1174 under peak load is very low in this service class. The Network 1175 Control service class SHOULD be configured to use a Rate Queuing 1176 system such as defined in Section 1.4.1.2 of this document. 1178 Examples of protocols and application that SHOULD use the Network 1179 Control service class: 1180 o Routing packet flows: OSPF, BGP, ISIS, RIP 1181 o Control information exchange within and between different 1182 administrative domains across a peering point where SLAs are in 1183 place 1184 o LSP setup using CR-LDP and RSVP-TE 1186 The following protocols and applications SHOULD NOT use the Network 1187 Control service class: 1188 o User traffic 1190 Traffic characteristics of packet flows in the Network Control 1191 service class: 1192 o Mostly messages sent between routers and network servers 1193 o Ranging from 50 to 1,500 byte packet sizes, normally one packet at 1194 a time but traffic can also burst (BGP) 1195 o User traffic is not allowed to use this service class. By user 1196 traffic we mean packet flows that originate from user controlled 1197 end points that are connected to the network. 1199 RECOMMENDED DSCP marking is CS6 (Class Selector 6) 1201 RECOMMENDED Network Edge Conditioning: 1202 o At peering points (between two DiffServ networks) where SLAs are 1203 in place, CS6 marked packets SHOULD be policed, e.g. using a 1204 single rate with burst size (sr+bs) token bucket policer to keep 1205 the CS6 marked packet flows to within the traffic rate specified 1206 in the SLA. 1207 o CS6 marked packet flows from untrusted sources (for example, end 1208 user devices) SHOULD be dropped or remarked at ingress to DiffServ 1209 network. 1210 o Packets from users/subscribers are not permitted access to the 1211 Network Control service classes. 1213 The fundamental service offered to the Network Control service class 1214 is enhanced best effort service with high bandwidth assurance. Since 1215 this service class is used to forward both elastic and inelastic 1216 flows, the service SHOULD be engineered so the Active Queue 1217 Management (AQM) [RFC2309] is applied to CS6 marked packets. 1219 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1220 specifies a target queue depth, and the max-threshold specifies the 1221 queue depth above which all traffic is dropped or ECN marked. Thus, 1222 in this service class, the following inequality should hold in queue 1223 configurations: 1224 o min-threshold CS6 < max-threshold CS6 1225 o max-threshold CS6 <= memory assigned to the queue 1226 Note: Many other AQM algorithms exist and are used; they should be 1227 configured to achieve a similar result. 1229 3.3 OAM Service Class 1231 The OAM (Operations, Administration and Management) service class is 1232 RECOMMENDED for OAM&P (Operations, Administration and Management and 1233 Provisioning) using protocols such as SNMP, TFTP, FTP, Telnet, COPS, 1234 etc. Applications using this service class require a low packet loss 1235 but are relatively not sensitive to delay. This service class is 1236 configured to provide good packet delivery for intermittent flows. 1238 The OAM service class SHOULD use the Class Selector (CS) PHB defined 1239 in [RFC2474]. This service class SHOULD be configured to provide a 1240 minimum bandwidth assurance for CS2 marked packets to ensure that 1241 they get forwarded. The OAM service class SHOULD be configured to 1242 use a Rate Queuing system such as defined in Section 1.4.1.2 of this 1243 document. 1245 The following applications SHOULD use the OAM service class: 1246 o For provisioning and configuration of network elements 1247 o For performance monitoring of network elements 1248 o For any network operational alarms 1250 Traffic characteristics: 1251 o Variable size packets (50 to 1500 bytes in size) 1252 o Intermittent traffic flows 1253 o Traffic may burst at times 1254 o Both elastic and inelastic flows 1255 o Traffic not sensitive to delays 1257 RECOMMENDED DSCP marking: 1258 o All flows in this service class are marked with CS2 (Class 1259 Selector 2) 1261 Applications or IP end points SHOULD pre-mark their packets with CS2 1262 DSCP value. If the end point is not capable of setting the DSCP 1263 value, then the router topologically closest to the end point SHOULD 1264 perform Multifield (MF) Classification as defined in [RFC2475]. 1266 RECOMMENDED Conditioning Performed at DiffServ Network Edge: 1267 o Packet flow marking (DSCP setting) from untrusted sources (end 1268 user devices) SHOULD be verified at ingress to DiffServ network 1269 using Multifield (MF) Classification methods defined in [RFC2475]. 1271 o Packet flows from untrusted sources (end user devices) SHOULD be 1272 policed at ingress to DiffServ network, e.g. using single rate 1273 with burst size token bucket policer to ensure that the traffic 1274 stays within its negotiated or engineered bounds. 1275 o Packet flows from trusted sources (routers inside administered 1276 network) MAY not require policing. 1277 o Normally OAM&P CS2 marked packet flows are not allowed to flow 1278 across peering points, if that is the case, then CS2 marked 1279 packets SHOULD be policed (dropped) at both egress and ingress 1280 peering interfaces. 1282 The fundamental service offered to "OAM" traffic is enhanced best 1283 effort service with controlled rate. The service SHOULD be 1284 engineered so that CS2 marked packet flows have sufficient bandwidth 1285 in the network to provide high assurance of delivery. Since this 1286 service class is used to forward both elastic and inelastic flows, 1287 the service SHOULD be engineered so that Active Queue Management 1288 [RFC2309] is applied to CS2 marked packets. 1290 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1291 specifies a target queue depth for each DSCP, and the max-threshold 1292 specifies the queue depth above which all traffic with such a DSCP is 1293 dropped or ECN marked. Thus, in this service class, the following 1294 inequality should hold in queue configurations: 1295 o min-threshold CS2 < max-threshold CS2 1296 o max-threshold CS2 <= memory assigned to the queue 1297 Note: Many other AQM algorithms exist and are used; they should be 1298 configured to achieve a similar result. 1300 4. User Traffic 1302 User traffic is defined as packet flows between different users or 1303 subscribers. It is the traffic that is sent to or from end-terminals 1304 and that support very wide variety of applications and services. 1305 User traffic can be differentiated in many different ways, therefore 1306 we investigated several different approaches to classify user 1307 traffic. We looked at differentiating user traffic as real-time 1308 versus non real-time, elastic or rate adaptive versus inelastic, 1309 sensitive versus insensitive to loss as well traffic categorization 1310 as interactive, responsive, timely and non-critical as defined in 1311 ITU-T Recommendation G.1010. At the end, we added up using all of 1312 the above for service differentiation, mapping of applications that 1313 have the matching traffic characteristics that fit the traffic 1314 profile and performance requirements of the defined service classes. 1316 Network administrators can categorize their applications based on the 1317 type of behavior that they require and MAY choose to support all or 1318 subset of the defined service classes. Figure 3 provides some common 1319 applications and the forwarding service class that best supports them 1320 based on their performance requirements. 1322 4.1 Telephony Service Class 1324 The Telephony service class is RECOMMENDED for applications that 1325 require real-time, very low delay, very low jitter and very low 1326 packet loss for relatively constant-rate traffic sources (inelastic 1327 traffic sources). This service class SHOULD be used for IP telephony 1328 service. 1330 The fundamental service offered to traffic in the Telephony service 1331 class is minimum jitter, delay and packet loss service up to a 1332 specified upper bound. Operation is in some respect similar to an 1333 ATM CBR service, which has guaranteed bandwidth and which, if it 1334 stays within the negotiated rate, experiences nominal delay and no 1335 loss. The EF PHB has a similar guarantee. 1337 Typical configurations negotiate the setup of telephone calls over IP 1338 using protocols such as H.248, MEGACO, H.323, or SIP. When a user 1339 has been authorized to send telephony traffic, the call admission 1340 procedure should have verified that the newly admitted flow will be 1341 within the capacity of the Telephony service class forwarding 1342 capability in the network. For VoIP (telephony) service, call 1343 admission control is usually performed by a telephony call server/ 1344 gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) on 1345 access points to the network. The bandwidth in the core network and 1346 the number of simultaneous VoIP sessions that can be supported needs 1347 to be engineered and controlled so that there is no congestion for 1348 this service. Since RTP telephony flows do not react to loss or 1349 substantial delay in any substantive way, the Telephony service class 1350 SHOULD forward packet as soon as possible. 1352 The Telephony service class SHOULD use Expedited Forwarding (EF) PHB 1353 as defined in [RFC3246] and SHOULD be configured to receive 1354 guaranteed forwarding resources so that all packets are forwarded 1355 quickly. The Telephony service class SHOULD be configured to use a 1356 Priority Queuing system such as defined in Section 1.4.1.1 of this 1357 document. 1359 The following application SHOULD use the Telephony service class: 1360 o VoIP (G.711, G.729 and other codecs) 1361 o Voice-band data over IP (modem, fax) 1362 o T.38 fax over IP 1363 o Circuit emulation over IP, virtual wire, etc. 1364 o IP VPN service that specifies single rate, mean network delay that 1365 is slightly longer then network propagation delay, very low jitter 1366 and a very low packet loss 1368 Traffic characteristics: 1369 o Mostly fixed size packets for VoIP (60, 70, 120 or 200 bytes in 1370 size) 1371 o Packets emitted at constant time intervals 1372 o Admission control of new flows is provided by telephony call 1373 server, media gateway, gatekeeper, edge router, end terminal or 1374 access node that provides flow admission control function. 1376 Applications or IP end points SHOULD pre-mark their packets with EF 1377 DSCP value. If the end point is not capable of setting the DSCP 1378 value, then the router topologically closest to the end point SHOULD 1379 perform Multifield (MF) Classification as defined in [RFC2475]. 1381 RECOMMENDED DSCP marking is EF for the following applications: 1382 o VoIP (G.711, G.729 and other codecs) 1383 o Voice-band data over IP (modem and fax) 1384 o T.38 fax over IP 1385 o Circuit emulation over IP, virtual wire, etc. 1387 RECOMMENDED Network Edge Conditioning: 1388 o Packet flow marking (DSCP setting) from untrusted sources (end 1389 user devices) SHOULD be verified at ingress to DiffServ network 1390 using Multifield (MF) Classification methods defined in [RFC2475]. 1391 o Packet flows from untrusted sources (end user devices) SHOULD be 1392 policed at ingress to DiffServ network, e.g. using single rate 1393 with burst size token bucket policer to ensure that the telephony 1394 traffic stays within its negotiated bounds. 1395 o Policing is OPTIONAL for packet flows from trusted sources whose 1396 behavior is assured via other means (e.g., administrative controls 1397 on those systems). 1398 o Policing of Telephony packet flows across peering points where SLA 1399 is in place is OPTIONAL as telephony traffic will be controlled by 1400 admission control mechanism between peering points. 1402 The fundamental service offered to "Telephony" traffic is enhanced 1403 best effort service with controlled rate, very low delay and very low 1404 loss. The service MUST be engineered so that EF marked packet flows 1405 have sufficient bandwidth in the network to provide guaranteed 1406 delivery. Normally traffic in this service class does not respond 1407 dynamically to packet loss. As such, Active Queue Management 1408 [RFC2309] SHOULD NOT be applied to EF marked packet flows. 1410 4.2 Signaling Service Class 1412 The Signaling service class is RECOMMENDED for delay sensitive 1413 client-server (traditional telephony) and peer-to-peer application 1414 signaling. Telephony signaling includes signaling between IP phone 1415 and soft-switch, soft-client and soft-switch, media gateway and soft- 1416 switch as well as peer-to-peer using various protocols. This service 1417 class is intended to be used for control of sessions and 1418 applications. Applications using this service class requiring a 1419 relatively fast response as there are typically several message of 1420 different size sent for control of the session. This service class 1421 is configured to provide good response for short lived, intermittent 1422 flows that require real-time packet forwarding. To minimize the 1423 possibility of ring clipping at start of call for VoIP service that 1424 interface to a circuit switch Exchange in the Public Switch Telephone 1425 Network (PSTN), the Signaling service class SHOULD be configured so 1426 that the probability of packet drop or significant queuing delay 1427 under peak load is very low in IP network segments that provide this 1428 interface. The term "ring clipping" refers to those instances where 1429 the front end of a ringing signal is altered because the bearer path 1430 is not made available in time to carry all of the audible ringing 1431 signal. This condition may occur due to a race condition between 1432 when the tone generator in the circuit switch Exchange is turn on and 1433 when the bearer path through the IP network is enabled. See 1434 Section 9.1 for additional explanation of "ring clipping" and 1435 Section 5.1 for explanation of mapping different signaling methods to 1436 service classes. 1438 The Signaling service class SHOULD use the Class Selector (CS) PHB 1439 defined in [RFC2474]. This service class SHOULD be configured to 1440 provide a minimum bandwidth assurance for CS5 marked packets to 1441 ensure that they get forwarded. The Signaling service class SHOULD 1442 be configured to use a Rate Queuing system such as defined in 1443 Section 1.4.1.2of this document. 1445 The following applications SHOULD use the Signaling service class: 1446 o Peer-to-peer IP telephony signaling (e.g., using SIP, H.323) 1447 o Peer-to-peer signaling for multimedia applications (e.g., using 1448 SIP, H.323) 1449 o Peer-to-peer real-time control function 1450 o Client-server IP telephony signaling using H.248, MEGACO, MGCP, IP 1451 encapsulated ISDN or other proprietary protocols 1452 o Signaling to control IPTV applications using protocols such as 1453 IGMP (Internet Group Management Protocol) 1454 o Signaling flows between high capacity telephony call servers or 1455 soft switches using protocol such as SIP-T. Such high capacity 1456 devices may control thousands of telephony (VoIP) calls. 1458 Traffic characteristics: 1459 o Variable size packets (50 to 1500 bytes in size) 1460 o Intermittent traffic flows 1461 o Traffic may burst at times 1462 o Delay sensitive control messages sent between two end-points 1464 RECOMMENDED DSCP marking: 1465 o All flows in this service class are marked with CS5 (Class 1466 Selector 5) 1468 Applications or IP end points SHOULD pre-mark their packets with CS5 1469 DSCP value. If the end point is not capable of setting the DSCP 1470 value, then the router topologically closest to the end point SHOULD 1471 perform Multifield (MF) Classification as defined in [RFC2475]. 1473 RECOMMENDED Conditioning Performed at DiffServ Network Edge: 1474 o Packet flow marking (DSCP setting) from untrusted sources (end 1475 user devices) SHOULD be verified at ingress to DiffServ network 1476 using Multifield (MF) Classification methods defined in [RFC2475]. 1477 o Packet flows from untrusted sources (end user devices) SHOULD be 1478 policed at ingress to DiffServ network, e.g. using single rate 1479 with burst size token bucket policer to ensure that the traffic 1480 stays within its negotiated or engineered bounds. 1481 o Packet flows from trusted sources (application servers inside 1482 administered network) MAY not require policing. 1483 o Policing of packet flows across peering points SHOULD be performed 1484 to the Service Level Agreement (SLA). 1486 The fundamental service offered to "Signaling" traffic is enhanced 1487 best effort service with controlled rate and delay. The service 1488 SHOULD be engineered so that CS5 marked packet flows have sufficient 1489 bandwidth in the network to provide high assurance of delivery and 1490 low delay. Normally traffic in this service class does not respond 1491 dynamically to packet loss. As such, Active Queue Management 1492 [RFC2309] SHOULD NOT be applied to CS5 marked packet flows. 1494 4.3 Multimedia Conferencing Service Class 1496 The Multimedia Conferencing service class is RECOMMENDED for 1497 applications that require real-time service for rate adaptive 1498 traffic. H.323/V2 and later versions of video conferencing equipment 1499 with dynamic bandwidth adjustment is such an application. The 1500 traffic sources (applications) in this service class have the 1501 capability to dynamically change their transmission rate based on 1502 feedback received from the receiving end, within bounds of packet 1503 loss by the receiver is sent using the applications control stream to 1504 the transmitter as an indication of possible congestion; the 1505 transmitter then selects a lower transmission rate based on pre- 1506 configured encoding rates (or transmission rates). Note, today many 1507 H.323/V2 video conferencing solutions implement fixed step bandwidth 1508 change (usually reducing the rate), traffic resembling step-wise CBR. 1510 Typical video conferencing configurations negotiate the setup of 1511 multimedia session using protocols such as H.323. When a user/ 1512 end-point has been authorized to start a multimedia session the 1513 admission procedure should have verified that the newly admitted data 1514 rate will be within the engineered capacity of the Multimedia 1515 Conferencing service class. The bandwidth in the core network and 1516 the number of simultaneous video conferencing sessions that can be 1517 supported SHOULD be engineered to control traffic load for this 1518 service. 1520 The Multimedia Conferencing service class SHOULD use the Assured 1521 Forwarding (AF) PHB defined in [RFC2597]. This service class SHOULD 1522 be configured to provide a bandwidth assurance for AF41, AF42, and 1523 AF43 marked packets to ensure that they get forwarded. The 1524 Multimedia Conferencing service class SHOULD be configured to use a 1525 Rate Queuing system such as defined in Section 1.4.1.2 of this 1526 document. 1528 The following application SHOULD use the Multimedia Conferencing 1529 service class: 1530 o H.323/V2 and later versions of video conferencing applications 1531 (interactive video) 1532 o Video conferencing applications with rate control or traffic 1533 content importance marking 1534 o Application server to application server non bursty data transfer 1535 requiring very low delay 1536 o IP VPN service that specifies two rates and mean network delay 1537 that is slightly longer then network propagation delay. 1538 o Interactive, time critical and mission critical applications. 1540 Traffic characteristics: 1541 o Variable size packets (50 to 1500 bytes in size) 1542 o Higher the rate, higher is the density of large packets 1543 o Constant packet emission time interval 1544 o Variable rate 1545 o Source is capable of reducing its transmission rate based on 1546 detection of packet loss at the receiver 1548 Applications or IP end points SHOULD pre-mark their packets with DSCP 1549 values as shown below. If the end point is not capable of setting 1550 the DSCP value, then the router topologically closest to the end 1551 point SHOULD perform Multifield (MF) Classification as defined in 1552 [RFC2475] and mark all packets as AF4x. Note: In this case, the two 1553 rate three color marker will be configured to operate in Color-Blind 1554 mode. 1556 RECOMMENDED DSCP marking when performed by router closest to source: 1558 o AF41 = up to specified rate "A" 1559 o AF42 = in excess of specified rate "A" but below specified rate 1560 "B" 1561 o AF43 = in excess of specified rate "B" 1562 o Where "A" < "B" 1563 Note: One might expect "A" to approximate the sum of the mean rates 1564 and "B" to approximate the sum of the peak rates. 1566 RECOMMENDED DSCP marking when performed by H.323/V2 video 1567 conferencing equipment: 1568 o AF41 = H.323 video conferencing audio stream RTP/UDP 1569 o AF41 = H.323 video conferencing video control RTCP/TCP 1570 o AF41 = H.323 video conferencing video stream up to specified rate 1571 "A" 1572 o AF42 = H.323 video conferencing video stream in excess of 1573 specified rate "A" but below specified rate "B" 1574 o AF43 = H.323 video conferencing video stream in excess of 1575 specified rate "B" 1576 o Where "A" < "B" 1578 RECOMMENDED Conditioning Performed at DiffServ Network Edge: 1579 o The two rate three color marker SHOULD be configured to provide 1580 the behavior as defined in trTCM [RFC2698]. 1581 o If packets are marked by a trusted sources or previous trusted 1582 DiffServ domain, and the color marking is to be preserved, then 1583 the two rate three color marker SHOULD be configured to operate in 1584 Color-Aware mode. 1585 o If the packet marking is not trusted or the color marking is not 1586 to be preserved, then the two rate three color marker SHOULD be 1587 configured to operate in Color-Blind mode. 1589 The fundamental service offered to "Multimedia Conferencing" traffic 1590 is enhanced best effort service with controlled rate and delay. For 1591 video conferencing service, typically a 1% packet loss detected at 1592 the receiver triggers an encoding rate change, dropping to next lower 1593 provisioned video encoding rate. As such, Active Queue Management 1594 [RFC2309] SHOULD be used primarily to switch video encoding rate 1595 under congestion, changing from high rate to lower rate i.e. 1472 1596 kbps to 768 kbps. The probability of loss of AF41 traffic MUST NOT 1597 exceed the probability of loss of AF42 traffic, which in turn MUST 1598 NOT exceed the probability of loss of AF43 traffic. 1600 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1601 specifies a target queue depth for each DSCP, and the max-threshold 1602 specifies the queue depth above which all traffic with such a DSCP is 1603 dropped or ECN marked. Thus, in this service class, the following 1604 inequality should hold in queue configurations: 1606 o min-threshold AF43 < max-threshold AF43 1607 o max-threshold AF43 <= min-threshold AF42 1608 o min-threshold AF42 < max-threshold AF42 1609 o max-threshold AF42 <= min-threshold AF41 1610 o min-threshold AF41 < max-threshold AF41 1611 o max-threshold AF41 <= memory assigned to the queue 1612 Note: This configuration tends to drop AF43 traffic before AF42 and 1613 AF42 before AF41. Many other AQM algorithms exist and are used; they 1614 should be configured to achieve a similar result. 1616 4.4 Real-time Interactive Service Class 1618 The Real-time Interactive service class is RECOMMENDED for 1619 applications that require low loss, jitter and very low delay for 1620 variable rate inelastic traffic sources. Interactive gaming and 1621 video conferencing applications that do not have the ability to 1622 change encoding rates or mark packets with different importance 1623 indications are such applications. The traffic sources in this 1624 traffic class does not have the ability to reduce their transmission 1625 rate based on feedback received from the receiving end. 1627 Typically, applications in this service class are configured to 1628 negotiate the setup of RTP/UDP control session. When a user/ 1629 end-point has been authorized to start a new session the admission 1630 procedure should have verified that the newly admitted data rates 1631 will be within the engineered capacity of the Real-time Interactive 1632 service class. The bandwidth in the core network and the number of 1633 simultaneous Real-time Interactive sessions that can be supported 1634 SHOULD be engineered to control traffic load for this service. 1636 The Real-time Interactive service class SHOULD use the Class Selector 1637 (CS) PHB defined in [RFC2474]. This service class SHOULD be 1638 configured to provide a high assurance for bandwidth for CS4 marked 1639 packets to ensure that they get forwarded. The Real-time Interactive 1640 service class SHOULD be configured to use a Rate Queuing system such 1641 as defined in Section 1.4.1.2 of this document. Note, this service 1642 class MAY be configured as a second EF PHB that uses relaxed 1643 performance parameter, a rate scheduler and CS4 DSCP value. 1645 The following application SHOULD use the Real-time Interactive 1646 service class: 1647 o Interactive gaming and control 1648 o Video conferencing applications without rate control or traffic 1649 content importance marking 1650 o IP VPN service that specifies single rate and mean network delay 1651 that is slightly longer then network propagation delay 1653 o Inelastic, interactive, time critical and mission critical 1654 applications requiring very low delay 1656 Traffic characteristics: 1657 o Variable size packets (50 to 1500 bytes in size) 1658 o Variable rate non bursty 1659 o Application is sensitive to delay variation between flows and 1660 sessions 1661 o Packets lost if any are usually ignored by application 1663 RECOMMENDED DSCP marking: 1664 o All flows in this service class are marked with CS4 (Class 1665 Selector 4) 1667 Applications or IP end points SHOULD pre-mark their packets with CS4 1668 DSCP value. If the end point is not capable of setting the DSCP 1669 value, then the router topologically closest to the end point SHOULD 1670 perform Multifield (MF) Classification as defined in [RFC2475]. 1672 RECOMMENDED Conditioning Performed at DiffServ Network Edge: 1673 o Packet flow marking (DSCP setting) from untrusted sources (end 1674 user devices) SHOULD be verified at ingress to DiffServ network 1675 using Multifield (MF) Classification methods defined in [RFC2475]. 1676 o Packet flows from untrusted sources (end user devices) SHOULD be 1677 policed at ingress to DiffServ network, e.g. using single rate 1678 with burst size token bucket policer to ensure that the traffic 1679 stays within its negotiated or engineered bounds. 1680 o Packet flows from trusted sources (application servers inside 1681 administered network) MAY not require policing. 1682 o Policing of packet flows across peering points SHOULD be performed 1683 to the Service Level Agreement (SLA). 1685 The fundamental service offered to "Real-time Interactive" traffic is 1686 enhanced best effort service with controlled rate and delay. The 1687 service SHOULD be engineered so that CS4 marked packet flows have 1688 sufficient bandwidth in the network to provide high assurance of 1689 delivery. Normally traffic in this service class does not respond 1690 dynamically to packet loss. As such, Active Queue Management 1691 [RFC2309] SHOULD NOT be applied to CS4 marked packet flows. 1693 4.5 Multimedia Streaming Service Class 1695 The Multimedia Streaming service class is RECOMMENDED for 1696 applications that require near-real-time packet forwarding of 1697 variable rate elastic traffic sources that are not as delay sensitive 1698 as applications using the Multimedia Conferencing service class. 1699 Such applications include streaming audio and video, some video 1700 (movies) on demand applications and Web casts. In general, the 1701 Multimedia Streaming service class assumes that the traffic is 1702 buffered at the source/destination and therefore, is less sensitive 1703 to delay and jitter. 1705 The Multimedia Streaming service class SHOULD use the Assured 1706 Forwarding (AF) PHB defined in [RFC2597]. This service class SHOULD 1707 be configured to provide a minimum bandwidth assurance for AF31, AF32 1708 and AF33 marked packets to ensure that they get forwarded. The 1709 Multimedia Streaming service class SHOULD be configured to use Rate 1710 Queuing system such as defined in Section 1.4.1.2 of this document. 1712 The following applications SHOULD use the Multimedia Streaming 1713 service class: 1714 o Buffered streaming audio (unicast) 1715 o Buffered streaming video (unicast) 1716 o Web casts 1717 o IP VPN service that specifies two rates and is less sensitive to 1718 delay and jitter 1720 Traffic characteristics: 1721 o Variable size packets (50 to 4196 bytes in size) 1722 o Higher the rate, higher density of large packets 1723 o Variable rate 1724 o Elastic flows 1725 o Some bursting at start of flow from some applications 1727 Applications or IP end points SHOULD pre-mark their packets with DSCP 1728 values as shown below. If the end point is not capable of setting 1729 the DSCP value, then the router topologically closest to the end 1730 point SHOULD perform Multifield (MF) Classification as defined in 1731 [RFC2475] and mark all packets as AF3x. Note: In this case, the two 1732 rate three color marker will be configured to operate in Color-Blind 1733 mode. 1735 RECOMMENDED DSCP marking: 1736 o AF31 = up to specified rate "A" 1737 o AF32 = in excess of specified rate "A" but below specified rate 1738 "B" 1739 o AF33 = in excess of specified rate "B" 1740 o Where "A" < "B" 1741 Note: One might expect "A" to approximate the sum of the mean rates 1742 and "B" to approximate the sum of the peak rates. 1744 RECOMMENDED Conditioning Performed at DiffServ Network Edge: 1745 o The two rate three color marker SHOULD be configured to provide 1746 the behavior as defined in trTCM [RFC2698]. 1748 o If packets are marked by a trusted sources or previous trusted 1749 DiffServ domain, and the color marking is to be preserved, then 1750 the two rate three color marker SHOULD be configured to operate in 1751 Color-Aware mode. 1752 o If the packet marking is not trusted or the color marking is not 1753 to be preserved, then the two rate three color marker SHOULD be 1754 configured to operate in Color-Blind mode. 1756 The fundamental service offered to "Multimedia Streaming" traffic is 1757 enhanced best effort service with controlled rate and delay. The 1758 service SHOULD be engineered so that AF31 marked packet flows have 1759 sufficient bandwidth in the network to provide high assurance of 1760 delivery. Since the AF3x traffic is elastic and responds dynamically 1761 to packet loss, Active Queue Management [RFC2309] SHOULD be used 1762 primarily to reduce forwarding rate to the minimum assured rate at 1763 congestion points. The probability of loss of AF31 traffic MUST NOT 1764 exceed the probability of loss of AF32 traffic, which in turn MUST 1765 NOT exceed the probability of loss of AF33. 1767 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1768 specifies a target queue depth for each DSCP, and the max-threshold 1769 specifies the queue depth above which all traffic with such a DSCP is 1770 dropped or ECN marked. Thus, in this service class, the following 1771 inequality should hold in queue configurations: 1772 o min-threshold AF33 < max-threshold AF33 1773 o max-threshold AF33 <= min-threshold AF32 1774 o min-threshold AF32 < max-threshold AF32 1775 o max-threshold AF32 <= min-threshold AF31 1776 o min-threshold AF31 < max-threshold AF31 1777 o max-threshold AF31 <= memory assigned to the queue 1778 Note: This configuration tends to drop AF33 traffic before AF32 and 1779 AF32 before AF31. Many other AQM algorithms exist and are used; they 1780 should be configured to achieve a similar result. 1782 4.6 Broadcast Video Service Class 1784 The Broadcast Video service class is RECOMMENDED for applications 1785 that require near-real-time packet forwarding with very low packet 1786 loss of constant and variable rate inelastic traffic sources that are 1787 not as delay sensitive as applications using the Real-time 1788 Interactive service class. Such applications include broadcast TV, 1789 streaming of live audio and video events, some video on demand 1790 applications and video surveillance. In general, the Broadcast Video 1791 service class assumes that the destination end point has a dejitter 1792 buffer, for video application usually a 2 - 8 video frames buffer (66 1793 to several hundred of milliseconds) therefore, is less sensitive to 1794 delay and jitter. 1796 The Broadcast Video service class SHOULD use the Class Selector (CS) 1797 PHB defined in [RFC2474]. This service class SHOULD be configured to 1798 provide high assurance for bandwidth for CS3 marked packets to ensure 1799 that they get forwarded. The Broadcast Video service class SHOULD be 1800 configured to use Rate Queuing system such as defined in 1801 Section 1.4.1.2 of this document. Note, this service class MAY be 1802 configured as a third EF PHB that uses relaxed performance parameter, 1803 a rate scheduler and CS3 DSCP value. 1805 The following applications SHOULD use the Broadcast Video service 1806 class: 1807 o Video surveillance and security (unicast) 1808 o TV broadcast including HDTV (multicast) 1809 o Video on demand (unicast) with control (virtual DVD) 1810 o Streaming of live audio events (both unicast and multicast) 1811 o Streaming of live video events (both unicast and multicast) 1813 Traffic characteristics: 1814 o Variable size packets (50 to 4196 bytes in size) 1815 o Higher the rate, higher density of large packets 1816 o Mixture of variable and constant rate flows 1817 o Fixed packet emission time intervals 1818 o Inelastic flows 1820 RECOMMENDED DSCP marking: 1821 o All flows in this service class are marked with CS3 (Class 1822 Selector 3) 1823 o In some cases, like for security and video surveillance 1824 applications, it may be desirable to use a different DSCP marking. 1825 If so, then locally user definable (EXP/LU) codepoint(s) in the 1826 range '011xx1' MAY be used to provide unique traffic 1827 identification. The locally user definable (EXP/LU) codepoint(s) 1828 MAY be associated with the PHB that is used for CS3 traffic. 1829 Further, depending on the network scenario, additional network 1830 edge conditioning policy MAY be need for the EXP/LU codepoint(s) 1831 used. 1833 Applications or IP end points SHOULD pre-mark their packets with CS3 1834 DSCP value. If the end point is not capable of setting the DSCP 1835 value, then the router topologically closest to the end point SHOULD 1836 perform Multifield (MF) Classification as defined in [RFC2475]. 1838 RECOMMENDED Conditioning Performed at DiffServ Network Edge: 1839 o Packet flow marking (DSCP setting) from untrusted sources (end 1840 user devices) SHOULD be verified at ingress to DiffServ network 1841 using Multifield (MF) Classification methods defined in [RFC2475]. 1843 o Packet flows from untrusted sources (end user devices) SHOULD be 1844 policed at ingress to DiffServ network, e.g. using single rate 1845 with burst size token bucket policer to ensure that the traffic 1846 stays within its negotiated or engineered bounds. 1847 o Packet flows from trusted sources (application servers inside 1848 administered network) MAY not require policing. 1849 o Policing of packet flows across peering points SHOULD be performed 1850 to the Service Level Agreement (SLA). 1852 The fundamental service offered to "Broadcast Video" traffic is 1853 enhanced best effort service with controlled rate and delay. The 1854 service SHOULD be engineered so that CS3 marked packet flows have 1855 sufficient bandwidth in the network to provide high assurance of 1856 delivery. Normally traffic in this service class does not respond 1857 dynamically to packet loss. As such, Active Queue Management 1858 [RFC2309] SHOULD NOT be applied to CS3 marked packet flows. 1860 4.7 Low Latency Data Service Class 1862 The Low Latency Data service class is RECOMMENDED for elastic and 1863 responsive typically client/server based applications. Applications 1864 forwarded by this service class are those requiring a relatively fast 1865 response and typically have asymmetrical bandwidth need, i.e. the 1866 client typically sends a short message to the server and the server 1867 responds with a much larger data flow back to the client. The most 1868 common example of this is when a user clicks a hyperlink (~few dozen 1869 bytes) on a web page resulting in a new web page to be loaded (Kbytes 1870 of data). This service class is configured to provide good response 1871 for TCP [RFC1633] short lived flows that require real-time packet 1872 forwarding of variable rate traffic sources. 1874 The Low Latency Data service class SHOULD use the Assured Forwarding 1875 (AF) PHB defined in [RFC2597]. This service class SHOULD be 1876 configured to provide a minimum bandwidth assurance for AF21, AF22 1877 and AF23 marked packets to ensure that they get forwarded. The Low 1878 Latency Data service class SHOULD be configured to use a Rate Queuing 1879 system such as defined in Section 1.4.1.2 of this document. 1881 The following applications SHOULD use the Low Latency Data service 1882 class: 1883 o Client/server applications 1884 o SNA terminal to host transactions (SNA over IP using DLSw) 1885 o Web based transactions (E-commerce) 1886 o Credit card transactions 1887 o Financial wire transfers 1888 o Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN) 1889 o VPN service that supports CIR (Committed Information Rate) with up 1890 to two burst sizes 1892 Traffic characteristics: 1893 o Variable size packets (50 to 1500 bytes in size) 1894 o Variable packet emission rate 1895 o With packet bursts of TCP window size 1896 o Short traffic bursts 1897 o Source capable of reducing its transmission rate based on 1898 detection of packet loss at the receiver or through explicit 1899 congestion notification 1901 Applications or IP end points SHOULD pre-mark their packets with DSCP 1902 values as shown below. If the end point is not capable of setting 1903 the DSCP value, then the router topologically closest to the end 1904 point SHOULD perform Multifield (MF) Classification as defined in 1905 [RFC2475] and mark all packets as AF2x. Note: In this case, the 1906 single rate three color marker will be configured to operate in 1907 Color-Blind mode. 1909 RECOMMENDED DSCP marking: 1910 o AF21 = flow stream with packet burst size up to "A" bytes 1911 o AF22 = flow stream with packet burst size in excess of "A" but 1912 below "B" bytes 1913 o AF23 = flow stream with packet burst size in excess of "B" bytes 1914 o Where "A" < "B" 1916 RECOMMENDED Conditioning Performed at DiffServ Network Edge: 1917 o The single rate three color marker SHOULD be configured to provide 1918 the behavior as defined in srTCM [RFC2697]. 1919 o If packets are marked by a trusted sources or previous trusted 1920 DiffServ domain, and the color marking is to be preserved, then 1921 the single rate three color marker SHOULD be configured to operate 1922 in Color-Aware mode. 1923 o If the packet marking is not trusted or the color marking is not 1924 to be preserved, then the single rate three color marker SHOULD be 1925 configured to operate in Color-Blind mode. 1927 The fundamental service offered to "Low Latency Data" traffic is 1928 enhanced best effort service with controlled rate and delay. The 1929 service SHOULD be engineered so that AF21 marked packet flows have 1930 sufficient bandwidth in the network to provide high assurance of 1931 delivery. Since the AF2x traffic is elastic and responds dynamically 1932 to packet loss, Active Queue Management [RFC2309] SHOULD be used 1933 primarily to control TCP flow rates at congestion points by dropping 1934 packet from TCP flows that have large burst size. The probability of 1935 loss of AF21 traffic MUST NOT exceed the probability of loss of AF22 1936 traffic, which in turn MUST NOT exceed the probability of loss of 1937 AF23. Active queue management MAY also be implemented using Explicit 1938 Congestion Notification (ECN) [RFC3168]. 1940 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1941 specifies a target queue depth for each DSCP, and the max-threshold 1942 specifies the queue depth above which all traffic with such a DSCP is 1943 dropped or ECN marked. Thus, in this service class, the following 1944 inequality should hold in queue configurations: 1945 o min-threshold AF23 < max-threshold AF23 1946 o max-threshold AF23 <= min-threshold AF22 1947 o min-threshold AF22 < max-threshold AF22 1948 o max-threshold AF22 <= min-threshold AF21 1949 o min-threshold AF21 < max-threshold AF21 1950 o max-threshold AF21 <= memory assigned to the queue 1951 Note: This configuration tends to drop AF23 traffic before AF22 and 1952 AF22 before AF21. Many other AQM algorithms exist and are used; they 1953 should be configured to achieve a similar result. 1955 4.8 High Throughput Data Service Class 1957 The High Throughput Data service class is RECOMMENDED for elastic 1958 applications that require timely packet forwarding of variable rate 1959 traffic sources and more specifically is configured to provide good 1960 throughput for TCP longer lived flows. TCP [RFC1633] or a transport 1961 with a consistent Congestion Avoidance Procedure [RFC2581] [RFC2582] 1962 normally will drive as high a data rate as it can obtain over a long 1963 period of time. The FTP protocol is a common example, although one 1964 cannot definitively say that all FTP transfers are moving data in 1965 bulk. 1967 The High Throughput Data service class SHOULD use the Assured 1968 Forwarding (AF) PHB defined in [RFC2597]. This service class SHOULD 1969 be configured to provide a minimum bandwidth assurance for AF11, AF12 1970 and AF13 marked packets to ensure that they are forwarded in timely 1971 manner. The High Throughput Data service class SHOULD be configured 1972 to use a Rate Queuing system such as defined in Section 1.4.1.2 of 1973 this document. 1975 The following applications SHOULD use the High Throughput Data 1976 service class: 1977 o Store and forward applications 1978 o File transfer applications 1979 o Email 1980 o VPN service that supports two rates (committed information rate 1981 and excess or peak information rate) 1983 Traffic characteristics: 1985 o Variable size packets (50 to 1500 bytes in size) 1986 o Variable packet emission rate 1987 o Variable rate 1988 o With packet bursts of TCP window size 1989 o Source capable of reducing its transmission rate based on 1990 detection of packet loss at the receiver or through explicit 1991 congestion notification 1993 Applications or IP end points SHOULD pre-mark their packets with DSCP 1994 values as shown below. If the end point is not capable of setting 1995 the DSCP value, then the router topologically closest to the end 1996 point SHOULD perform Multifield (MF) Classification as defined in 1997 [RFC2475] and mark all packets as AF1x. Note: In this case, the two 1998 rate three color marker will be configured to operate in Color-Blind 1999 mode. 2001 RECOMMENDED DSCP marking: 2002 o AF11 = up to specified rate "A" 2003 o AF12 = in excess of specified rate "A" but below specified rate 2004 "B" 2005 o AF13 = in excess of specified rate "B" 2006 o Where "A" < "B" 2008 RECOMMENDED Conditioning Performed at DiffServ Network Edge: 2009 o The two rate three color marker SHOULD be configured to provide 2010 the behavior as defined in trTCM [RFC2698]. 2011 o If packets are marked by a trusted sources or previous trusted 2012 DiffServ domain, and the color marking is to be preserved, then 2013 the two rate three color marker SHOULD be configured to operate in 2014 Color-Aware mode. 2015 o If the packet marking is not trusted or the color marking is not 2016 to be preserved, then the two rate three color marker SHOULD be 2017 configured to operate in Color-Blind mode. 2019 The fundamental service offered to "High Throughput Data" traffic is 2020 enhanced best effort service with a specified minimum rate. The 2021 service SHOULD be engineered so that AF11 marked packet flows have 2022 sufficient bandwidth in the network to provide assured delivery. It 2023 can be assumed that this class will consume any available bandwidth, 2024 and packets traversing congested links may experience higher queuing 2025 delays and/or packet loss. Since the AF1x traffic is elastic and 2026 responds dynamically to packet loss, Active Queue Management 2027 [RFC2309] SHOULD be used primarily to control TCP flow rates at 2028 congestion points by dropping packet from TCP flows that have higher 2029 rates first. The probability of loss of AF11 traffic MUST NOT exceed 2030 the probability of loss of AF12 traffic, which in turn MUST NOT 2031 exceed the probability of loss of AF13. In such a case, if one 2032 network customer is driving significant excess and another seeks to 2033 use the link, any losses will be experienced by the high rate user, 2034 causing him to reduce his rate. Active queue management MAY also be 2035 implemented using Explicit Congestion Notification (ECN) [RFC3168]. 2037 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2038 specifies a target queue depth for each DSCP, and the max-threshold 2039 specifies the queue depth above which all traffic with such a DSCP is 2040 dropped or ECN marked. Thus, in this service class, the following 2041 inequality should hold in queue configurations: 2042 o min-threshold AF13 < max-threshold AF13 2043 o max-threshold AF13 <= min-threshold AF12 2044 o min-threshold AF12 < max-threshold AF12 2045 o max-threshold AF12 <= min-threshold AF11 2046 o min-threshold AF11 < max-threshold AF11 2047 o max-threshold AF11 <= memory assigned to the queue 2048 Note: This configuration tends to drop AF13 traffic before AF12 and 2049 AF12 before AF11. Many other AQM algorithms exist and are used; they 2050 should be configured to achieve a similar result. 2052 4.9 Standard Service Class 2054 The Standard service class is RECOMMENDED for traffic that has not 2055 been classified into one of the other supported forwarding service 2056 classes in the DiffServ network domain. This service class provides 2057 the Internet's "best effort" forwarding behavior. This service class 2058 typically has minimum bandwidth guarantee. 2060 The Standard service class MUST use the Default Forwarding (DF) PHB 2061 defined in [RFC2474] and SHOULD be configured to receive at least a 2062 small percentage of forwarding resources as a guaranteed minimum. 2063 This service class SHOULD be configured to use a Rate Queuing system 2064 such as defined in Section 1.4.1.2 of this document. 2066 The following application SHOULD use the Standard service class: 2067 o Network services, DNS, DHCP, BootP 2068 o Any undifferentiated application/packet flow transported through 2069 the DiffServ enabled network 2071 Traffic Characteristics: 2072 o Non deterministic, mixture of everything 2074 RECOMMENDED DSCP marking is DF (Default Forwarding) '000000' 2076 Network Edge Conditioning: 2077 There is no requirement that conditioning of packet flows be 2078 performed for this service class. 2080 The fundamental service offered to the Standard service class is best 2081 effort service with active queue management to limit over-all delay. 2082 Typical configurations SHOULD use random packet dropping to implement 2083 Active Queue Management [RFC2309] or Explicit Congestion Notification 2084 [RFC3168], and MAY impose a minimum or maximum rate on the queue. 2086 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2087 specifies a target queue depth, and the max-threshold specifies the 2088 queue depth above which all traffic is dropped or ECN marked. Thus, 2089 in this service class, the following inequality should hold in queue 2090 configurations: 2091 o min-threshold DF < max-threshold DF 2092 o max-threshold DF <= memory assigned to the queue 2093 Note: Many other AQM algorithms exist and are used; they should be 2094 configured to achieve a similar result. 2096 4.10 Low Priority Data 2098 The Low Priority Data service class serves applications that run over 2099 TCP [RFC0793] or a transport with consistent congestion avoidance 2100 procedure [RFC2581] [RFC2582], and which the user is willing to 2101 accept service without guarantees. This service class is specified 2102 in [QBSS] and [RFC3662]. 2104 The following applications MAY use the Low Priority Data service 2105 class: 2106 o Any TCP based application/packet flow transported through the 2107 DiffServ enabled network that does not require any bandwidth 2108 assurances 2110 Traffic Characteristics: 2111 o Non real-time and elastic 2113 Network Edge Conditioning: 2114 There is no requirement that conditioning of packet flows be 2115 performed for this service class 2117 RECOMMENDED DSCP marking is CS1 (Class Selector 1) 2119 The fundamental service offered to the Low Priority Data service 2120 class is best effort service with zero bandwidth assurance. By 2121 placing it into a separate queue or class, it may be treated in a 2122 manner consistent with a specific service level agreement. 2124 Typical configurations SHOULD use Explicit Congestion Notification 2125 [RFC3168] or random loss to implement Active Queue Management 2126 [RFC2309]. 2128 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2129 specifies a target queue depth, and the max-threshold specifies the 2130 queue depth above which all traffic is dropped or ECN marked. Thus, 2131 in this service class, the following inequality should hold in queue 2132 configurations: 2133 o min-threshold CS1 < max-threshold CS1 2134 o max-threshold CS1 <= memory assigned to the queue 2135 Note: Many other AQM algorithms exist and are used; they should be 2136 configured to achieve a similar result. 2138 5. Additional Information on Service Class Usage 2140 In this section we provide additional information on how some 2141 specific applications should be configured to use the defined service 2142 classes. 2144 5.1 Mapping for Signaling 2146 There are many different signaling protocols, ways that signaling is 2147 used and performance requirements from applications that are 2148 controlled by these protocols. We believe that different signaling 2149 protocols should use the service class that best meet the objectives 2150 of application or service they control. The following mapping is 2151 recommended: 2152 o Peer-to-peer signaling using SIP/H.323 are marked with CS5 DSCP 2153 (use Signaling service class). 2154 o Client-server signaling as used in many implementation for IP 2155 telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN or 2156 proprietary protocols are marked with CS5 DSCP (use Signaling 2157 service class). 2158 o Signaling between call servers or soft-switches in carrier's 2159 network using SIP, SIP-T, IP encapsulated ISUP, are marked with 2160 CS5 DSCP (use Signaling service class). 2161 o RSVP signaling, depends on the application. If RSVP signaling is 2162 "on-path" as used in IntServ, then it needs to be forwarded from 2163 the same queue (service class) and marked with the same DSCP value 2164 as application data that it is controlling. This may also apply 2165 to the "on-path" NSIS signaling protocol. 2166 o IGMP (Internet Group Management Protocol). If used for multicast 2167 session control such as channel changing in IPTV systems, then 2168 IGMP packets should be marked with CS5 DSCP (use Signaling service 2169 class). When IGMP is used only for the normal multicast routing 2170 purpose, it should be marked with CS6 DSCP (use Network Control 2171 service class). 2173 5.2 Mapping for NTP 2175 From tests that were performed, indications are that precise time 2176 distribution requires a very low packet delay variation (jitter) 2177 transport. Therefore we suggest the following guidelines for NTP 2178 (Network Time Protocol) be used: 2179 o When NTP is used for providing high accuracy timing within 2180 administrator's (carrier's) network or to end users/clients, the 2181 Telephony service class should be used and NTP packets be marked 2182 with EF DSCP value. 2183 o For applications that require "wall clock" timing accuracy, the 2184 Standard service class should be used and packets should be marked 2185 with DF DSCP. 2187 5.3 VPN Service Mapping 2189 Differentiated Services and Tunnels [RFC2983] considers the 2190 interaction of DiffServ architecture with IP tunnels of various 2191 forms. Further to guidelines provided in RFC 2983, below are 2192 additional guidelines for mapping service classes that are supported 2193 in one part of the network into a VPN connection. This discussion is 2194 limit only to VPNs that use DiffServ technology for traffic 2195 differentiation. 2196 o The DSCP value(s) that is/are used to represent a PHB or a PHB 2197 group should be the same for the networks at both ends of the VPN 2198 tunnel, unless remarking of DSCP is done as ingress/egress 2199 processing function of the tunnel. DSCP marking needs to be 2200 preserve end-to-end. 2201 o The VPN may be configured to support one or more service 2202 class(es). It is left up to the administrators of the two 2203 networks to agree on the level of traffic differentiation that 2204 will be provide in the network that supports VPN service. Service 2205 classes are then mapped into the supported VPN traffic forwarding 2206 behaviors that meet the traffic characteristics and performance 2207 requirements of the encapsulated service classes. 2208 o The traffic treatment in the network that is providing the VPN 2209 service needs to be such that the encapsulated service class or 2210 classes receive comparable behavior and performance in terms of 2211 delay, jitter, packet loss and they are within the limits of the 2212 service specified. 2213 o The DSCP value in the external header of the packet forwarded 2214 through the network providing the VPN service may be different 2215 than the DSCP value that is used end-to-end for service 2216 differentiation in end network. 2217 o The guidelines for aggregation of two or more service classes into 2218 a single traffic forwarding treatment in the network that is 2219 providing the VPN service is for further study. 2221 6. Security Considerations 2223 This document discusses policy, and describes a common policy 2224 configuration, for the use of a Differentiated Services Code Point by 2225 transports and applications. If implemented as described, it should 2226 require the network to do nothing that the network has not already 2227 allowed. If that is the case, no new security issues should arise 2228 from the use of such a policy. 2230 It is possible for the policy to be applied incorrectly, or for a 2231 wrong policy to be applied in the network for the defined service 2232 class. In that case, a policy issue exists that the network SHOULD 2233 detect, assess, and deal with. This is a known security issue in any 2234 network dependent on policy directed behavior. 2236 A well known flaw appears when bandwidth is reserved or enabled for a 2237 service (for example, voice transport) and another service or an 2238 attacking traffic stream uses it. This possibility is inherent in 2239 DiffServ technology, which depends on appropriate packet markings. 2240 When bandwidth reservation or a priority queuing system is used in a 2241 vulnerable network, the use of authentication and flow admission is 2242 recommended. To the author's knowledge, there is no known technical 2243 way to respond to an unauthenticated data stream using service that 2244 it is not intended to use, and such is the nature of the Internet. 2246 The use of a service class by a user is not an issue when the SLA 2247 between the user and the network permits him to use it, or to use it 2248 up to a stated rate. In such cases, simple policing is used in the 2249 Differentiated Services Architecture. Some service classes, such as 2250 Network Control, are not permitted to be used by users at all; such 2251 traffic should be dropped or remarked by ingress filters. Where 2252 service classes are available under the SLA only to an authenticated 2253 user rather than to the entire population of users, AAA services such 2254 as described in [I-D.iab-auth-mech] are required. 2256 7. Summary of Changes from Previous Draft 2258 NOTE TO RFC EDITOR: Please remove this section during the publication 2259 process. 2261 Changes made to draft-ietf-tsvwg-diffserv-service-classes-00 based on 2262 minor typos on review by Mike Fidler. Following typos were fixed. 2264 1. page 20 first paragraph, "than 000001 DSCP marking" should be 2265 "then 000001 DSCP marking" 2267 2. page 22 last sentence of third bullet "than the Broadcast Video 2268 service class" should be "then the Broadcast..." 2270 3. page 29 third bullet "than CS2 marked packet" should be "then CS2 2271 marked packets" (note plural also) 2272 4. page 40 second sentence of second bullet under "RECOMMENDED DSCP 2273 marking" "If so, than" should be "If so, then" 2275 5. page 47 section 5.1 fourth bullet "than it needs to be forwarded" 2276 should be "then it needs to be forwarded" 2278 6. page 48 section 5.3 second bullet "Service classes are than 2279 mapped" should be "Service classes are then mapped" 2281 8. Acknowledgements 2283 The authors thank the TSVWG reviewers, David Black, Brian E Carpenter 2284 and Alan O'Neill for their review and input to this draft. 2286 The authors acknowledge great many inputs, most notably from Bruce 2287 Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet, 2288 Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al 2289 Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson and 2290 Shane Amante. Kimberly King, Joe Zebarth and Alistair Munroe each 2291 did a thorough proof-reading, and the document is better for their 2292 contributions. 2294 9. Appendix A 2296 9.1 Explanation of Ring Clipping 2298 The term "ring clipping" refers to those instances where the front 2299 end of a ringing signal is altered because the bearer channel is not 2300 made available in time to carry all of the audible ringing signal. 2301 This condition may occur due to a race condition between when the 2302 tone generator located in the circuit switch Exchange is turn on and 2303 when the bearer path through the IP network is enabled. To reduce 2304 ring clipping from occurring, delay of signaling path needs to be 2305 minimized. Below is a more detailed explanation. 2307 The bearer path setup delay target is defined as the ISUP Initial 2308 Address Message (IAM) / Address Complete Message (ACM) round trip 2309 delay. ISUP refers to ISDN User Part of Signaling System No. 7 (SS7) 2310 as defined by ITU-T. This consists of the amount of time it takes 2311 for the ISUP Initial Address Message (IAM) to leave the Transit 2312 Exchange, travel through the SS7 network (including any applicable 2313 STPs (Signaling Transfer Points)), be processed by the End Exchange 2314 thus generating the Address Complete Message (ACM) and for the ACM to 2315 travel back through the SS7 network and return to the Transit 2316 Exchange. If the bearer path has not been set up within the soft- 2317 switch, media gateway and the IP network that is performing the 2318 Transit Exchange function by the time the ACM is forwarded to the 2319 originating End Exchange, the phenomenon known as ring clipping may 2320 occur. If ACM processing within soft-switch, media gateway and delay 2321 through the IP network is excessive, it will delay the setup of the 2322 bearer path therefore may cause clipping of ring tone to be heard. 2324 A generic maximum ISUP IAM signaling delay value of 240ms for intra 2325 Exchange, which may consist of soft-switch, media gateways, queuing 2326 delay in routers and distance delays between media gateway and soft- 2327 switch implementations is assumed. This value represents the 2328 threshold where ring clipping theoretically commences. It is 2329 important to note that the 240ms delay objective as presented is a 2330 maximum value. Service administrators are free to choose specific 2331 IAM delay values based on their own preferences (i.e., they may wish 2332 to set a very low mean delay objective for strategic reasons to 2333 differentiate themselves from other providers). In summary, out of 2334 the 240ms delay budget, 200ms is allocated as cross-Exchange delay 2335 (soft-switch and media gateway) and 40ms for network delay (queuing 2336 and distance). 2338 10. References 2340 10.1 Normative References 2342 [I-D.iab-auth-mech] 2343 Rescorla, E., "A Survey of Authentication Mechanisms", 2344 draft-iab-auth-mech-03 (work in progress), March 2004. 2346 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2347 September 1981. 2349 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2350 RFC 793, September 1981. 2352 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 2353 Suite", RFC 1349, July 1992. 2355 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 2356 RFC 1812, June 1995. 2358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2359 Requirement Levels", BCP 14, RFC 2119, March 1997. 2361 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 2362 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 2363 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 2364 S., Wroclawski, J., and L. Zhang, "Recommendations on 2365 Queue Management and Congestion Avoidance in the 2366 Internet", RFC 2309, April 1998. 2368 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2369 "Definition of the Differentiated Services Field (DS 2370 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2371 December 1998. 2373 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2374 and W. Weiss, "An Architecture for Differentiated 2375 Services", RFC 2475, December 1998. 2377 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 2378 "Assured Forwarding PHB Group", RFC 2597, June 1999. 2380 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 2381 J., Courtney, W., Davari, S., Firoiu, V., and D. 2382 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 2383 Behavior)", RFC 3246, March 2002. 2385 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 2386 Per-Domain Behavior (PDB) for Differentiated Services", 2387 RFC 3662, December 2003. 2389 10.2 Informative References 2391 [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 2392 Technical Report Proposed Service Definition, March 2001. 2394 [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated 2395 Services in the Internet Architecture: an Overview", 2396 RFC 1633, June 1994. 2398 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 2399 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 2400 Functional Specification", RFC 2205, September 1997. 2402 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 2403 Control", RFC 2581, April 1999. 2405 [RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to 2406 TCP's Fast Recovery Algorithm", RFC 2582, April 1999. 2408 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 2409 Marker", RFC 2697, September 1999. 2411 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 2412 Marker", RFC 2698, September 1999. 2414 [RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper 2415 for Differentiated Services", RFC 2963, October 2000. 2417 [RFC2983] Black, D., "Differentiated Services and Tunnels", 2418 RFC 2983, October 2000. 2420 [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, 2421 November 2000. 2423 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 2424 Differentiated Services Per Domain Behaviors and Rules for 2425 their Specification", RFC 3086, April 2001. 2427 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2428 of Explicit Congestion Notification (ECN) to IP", 2429 RFC 3168, September 2001. 2431 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 2432 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 2433 RFC 3175, September 2001. 2435 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 2436 Informal Management Model for Diffserv Routers", RFC 3290, 2437 May 2002. 2439 Authors' Addresses 2441 Jozef Babiarz 2442 Nortel Networks 2443 3500 Carling Avenue 2444 Ottawa, Ont. K2H 8E9 2445 Canada 2447 Phone: +1-613-763-6098 2448 Fax: +1-613-765-7462 2449 Email: babiarz@nortel.com 2451 Kwok Ho Chan 2452 Nortel Networks 2453 600 Technology Park Drive 2454 Billerica, MA 01821 2455 US 2457 Phone: +1-978-288-8175 2458 Fax: +1-978-288-4690 2459 Email: khchan@nortel.com 2460 Fred Baker 2461 Cisco Systems 2462 1121 Via Del Rey 2463 Santa Barbara, CA 93117 2464 US 2466 Phone: +1-408-526-4257 2467 Fax: +1-413-473-2403 2468 Email: fred@cisco.com 2470 Intellectual Property Statement 2472 The IETF takes no position regarding the validity or scope of any 2473 Intellectual Property Rights or other rights that might be claimed to 2474 pertain to the implementation or use of the technology described in 2475 this document or the extent to which any license under such rights 2476 might or might not be available; nor does it represent that it has 2477 made any independent effort to identify any such rights. Information 2478 on the procedures with respect to rights in RFC documents can be 2479 found in BCP 78 and BCP 79. 2481 Copies of IPR disclosures made to the IETF Secretariat and any 2482 assurances of licenses to be made available, or the result of an 2483 attempt made to obtain a general license or permission for the use of 2484 such proprietary rights by implementers or users of this 2485 specification can be obtained from the IETF on-line IPR repository at 2486 http://www.ietf.org/ipr. 2488 The IETF invites any interested party to bring to its attention any 2489 copyrights, patents or patent applications, or other proprietary 2490 rights that may cover technology that may be required to implement 2491 this standard. Please address the information to the IETF at 2492 ietf-ipr@ietf.org. 2494 Disclaimer of Validity 2496 This document and the information contained herein are provided on an 2497 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2498 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2499 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2500 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2501 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2502 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2504 Copyright Statement 2506 Copyright (C) The Internet Society (2005). This document is subject 2507 to the rights, licenses and restrictions contained in BCP 78, and 2508 except as set forth therein, the authors retain all their rights. 2510 Acknowledgment 2512 Funding for the RFC Editor function is currently provided by the 2513 Internet Society.