idnits 2.17.1 draft-polk-tsvwg-rfc4594-update-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 75 pages 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.) ** There are 6 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2895 has weird spacing: '...re more delay...' == 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). -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC4080' is mentioned on line 2914, but not defined == Missing Reference: 'ID-DSCP' is mentioned on line 3824, but not defined == Missing Reference: 'RFC5127' is mentioned on line 255, but not defined == Missing Reference: 'RFC4594' is mentioned on line 291, but not defined == Missing Reference: 'RFC2326' is mentioned on line 3206, but not defined ** Obsolete undefined reference: RFC 2326 (Obsoleted by RFC 7826) == Unused Reference: 'RFC2996' is defined on line 3748, but no explicit reference was found in the text == Unused Reference: 'RFC3175' is defined on line 3759, but no explicit reference was found in the text ** 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) ** 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 3782 (Obsoleted by RFC 6582) Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network WG James Polk, ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track (PS) Feb, 2013 5 Obsoletes: RFC 4594 6 Updates: RFC 5865 7 Expires: August 25, 2013 9 Standard Configuration of DiffServ Service Classes 10 draft-polk-tsvwg-rfc4594-update-03.txt 12 Abstract 14 This document describes service classes configured with DiffServ and 15 identifies how they are used and how to construct them using 16 Differentiated Services Code Points (DSCPs), traffic conditioners, 17 Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) 18 mechanisms. There is no intrinsic requirement that particular 19 DSCPs, traffic conditioners, PHBs, and AQM be used for a certain 20 service class, but for consistent behavior under the same network 21 conditions, configuring networks as described here is appropriate. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 25, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction ...................................................3 58 1.1. Requirements Notation ..................................... 59 1.2. Expected Use in the Network ............................... 60 1.3. Service Class Definition .................................. 61 1.4. Key Differentiated Services Concepts ...................... 62 1.4.1. Queuing .............................................. 63 1.4.1.1. Priority Queuing ............................ 64 1.4.1.2. Rate Queuing ................................ 65 1.4.2. Active Queue Management .............................. 66 1.4.3. Traffic Conditioning ................................. 67 1.4.4. Differentiated Services Code Point (DSCP) ............ 68 1.4.5. Per-Hop Behavior (PHB) ............................... 69 1.5. Key Service Concepts ...................................... 70 1.5.1. Default Forwarding (DF) .............................. 71 1.5.2. Assured Forwarding (AF) .............................. 72 1.5.3. Expedited Forwarding (EF) ...........................1 73 1.5.4. Class Selector (CS) .................................1 74 1.5.5. Admission Control ...................................1 75 1.6 What Changes are Proposed Here from RFC 4594?..............1 76 2. Service Differentiation .......................................1 77 2.1. Service Classes ..........................................1 78 2.2. Categorization of User Oriented Service Classes ..........1 79 2.3. Service Class Characteristics ............................1 80 2.4. Service Classes vs. Treatment Aggregate (from RFC 5127)...2 81 2.4.1 Examples of Service Classes in Treatment Aggregates...2 82 3. Network Control Traffic .......................................2 83 3.1. Current Practice in the Internet .........................2 84 3.2. Network Control Service Class ............................2 85 3.3. OAM Service Class ........................................2 86 4. User Oriented Traffic .........................................3 87 4.1. Conversational Service Class Group .......................3 88 4.1.1 Audio Service Class ..................................3 89 4.1.2 Video Service Class ..................................3 90 4.1.3 Hi-Res Service Class .................................3 91 4.2. Realtime-Interactive Service Class ...................... 3 92 4.3. Multimedia Conferencing Service Class ....................3 93 4.4. Multimedia Streaming Service Class .......................3 94 4.5. Broadcast Video Service Class ............................4 95 4.6. Low-Latency Data Service Class ...........................4 96 4.7. Conversational Signaling Service Class ...................4 97 4.8. High-Throughput Data Service Class .......................4 98 4.9. Standard Service Class ...................................4 99 4.10. Low-Priority Data .......................................4 100 5. Additional Information on Service Class Usage .................4 101 5.1. Mapping for NTP ..........................................5 102 5.2. VPN Service Mapping ......................................5 103 6. Security Considerations .......................................5 104 7. Contributing Authors ..........................................5 105 8. Acknowledgements ..............................................5 106 9. References ....................................................5 107 9.1. Normative References .....................................5 108 9.2. Informative References ...................................5 109 Author's Address .................................................5 110 Appendix A - Changes .............................................5 112 1. Introduction 114 Differentiated Services [RFC2474][RFC2475] provides the ability to 115 mark/label/classify IP packets differently to distinguish how 116 individual packets need to be treated differently through (or 117 throughout) a network on a per hop basis. Local administrators are 118 who configure each router for which Differentiated Services Code 119 Points (DSCP) are to be treated differently, which are to be 120 ignored (i.e., no differentiated treatment), and which DSCPs are to 121 have their packets remarked (to different DSCPs) as they pass 122 through a router. Local administrators are also who assign which 123 applications, or traffic types, should use which DSCPs to receive 124 the treatment the administrators expect within their network. 126 What most people fail to understand is that DSCPs provide a per hop 127 behavior (PHB) through that router, but not the previous or next 128 router. In this way of understanding PHB markings, one can 129 understand that Differentiated Services (DiffServ) is not a Quality 130 of Service (QoS) mechanism, but rather a Classification of Service 131 (CoS) mechanism. 133 For instance, there are 64 possible DSCP values, i.e., using 6 bits 134 of the old Type of Service (TOS) byte [RFC0791]. Each can be 135 configured locally to have greater or less treatment relative to any 136 other DSCP with two exceptions*. 138 * Expedited Forwarding (EF) [RFC3246] DSCPs have a treatment 139 requirement that any packet marked within an EF class has to be 140 the next packet transmitted out its egress interface. If there 141 are more than one EF marked packet in the queue, obviously the 142 queue sets the order they are transmitted. Further, if there 143 are more than one EF DSCP, local configuration determines if 144 each are treated the same or differently relate to each other 145 EF DSCP. Currently, there are two Expedited Forwarding DSCPs: 146 EF (101110) [RFC3246] and VOICE-ADMIT (101100) [RFC5865]. 148 * Class Selector 6 (CS6) [RFC2474] is for routing protocol 149 traffic. There are deemed important because if the network does 150 not transmit and receive its routing protocol traffic in a 151 timely manner, the network stops operating properly. 153 Not all are configured to mean anything other than best effort 154 forwarding by local administrators of a network. Let us say there 155 are 5 DSCPs configured within network A. Network A's administrator 156 chooses and configures which order (obeying the two exceptions noted 157 above) which application packets are treated differently than any 158 other packets within that network (A). The DSCPs are not fixed to a 159 linear order for relative priority on a per hop basis. Further, and 160 this is often the case, there might be packets with the same DSCP 161 arriving at multiple interfaces of a node, each egressing that node 162 out the same interface. At ingress to this node, everything was 163 fine, with no poor behavior or noticeably excessive amount of 164 packets with the same DSCP. However, at the egress interface, there 165 might not be enough capacity to satisfy the load, thus the departing 166 packets transmit at their maximum rate for that DSCP, but have 167 additional latency due to the overload within that one node. This is 168 called fan-in congestion (or problem). By itself, DiffServ will not 169 remedy this problem for the application that is intolerant to added 170 latency because DiffServ only functions within 1 node at a time. 172 An additional mechanism is needed to ensure each flow or session 173 receives the amount of packets at its destination that the 174 application requires to perform properly; a mechanism such as 175 IntServ, by way of RSVP [RFC2205] or NSIS [RFC4080]. With this added 176 capability to be session aware, something DiffServ is not, the 177 packets transmitted within a single session have a very good 178 probability of arriving in such a way the receiving application can 179 make full use of each. That said, signaling reservations for each 180 session or flow adds complexity, which creates more work for those 181 who maintain and administer such a network. Adding bandwidth and 182 using DiffServ marking is an easier pill to swallow. The deployment 183 of not few, but more and more audio and (particularly bandwidth 184 hogging) video codecs and their respective application rigidity has 185 caused some to conclude that throwing bandwidth at the problem is no 186 longer acceptable. 188 With this in mind, this document incorporates five of the six new 189 DSCPs from [ID-DSCP] identified as capacity-admitted DSCPs for most 190 of the service classes in this document. As explained in [ID-DSCP], 191 the five new capacity-admitted DSCPs are from Pool 3. [ID-DSCP] goes 192 further to explain that many layer 2 technologies use fewer bits for 193 marking and prioritization. Instead of six bits like DiffServ, they 194 have three bits, which yields a maximum of 8 values, which tend to 195 line up quite will with the TOS field values. Thus, aggregation of 196 DSCPs is typically accomplished by simply ignoring or reducing the 197 number of bits used to the most significant ones available, such as 199 EF is 101110, at layer 2 this is merely 101; 201 Broadcast is 011000, at layer 2 this is merely 011. 203 However, that was not a premise DiffServ was built upon, to merely 204 reduce the number of bits. In other words, within DiffServ, XXX is 205 not the same as XXX000 (where XXX is the same binary value in both 206 cases). 208 This document is originally built upon the RFC 4594 effort, while 209 updating some of the usages and expanding the scope for newer 210 applications that are in use today. The idea in RFC 4594 remains 211 true here, to define a set of service classes, each having unique 212 traffic characteristics, and assigning one or more DSCPs to each 213 service class. As much as the focus could be on the DSCP values, it 214 is not. The focus of this document is the unique traffic 215 characteristics of each service class. 217 There are many services classes defined in this document, not all 218 will be used in each network at any period of time. This consistency 219 packet markings we talk about is for several reasons, including in a 220 network that does not currently implement a certain service class 221 because they do not have that type of traffic in their network, or 222 that the network merely gives that traffic best effort service. 223 Having a solid guideline to know where to progress or reconfigure a 224 network and endpoints to, say from best effort for a particular 225 traffic type, is a very good thing to do more uniformly than not. A 226 fair amount of burden is placed at DS boundaries needing to keep up 227 with which markings turn into which other markings at both ingress 228 and egress to a network. The same holds true for application 229 developers choosing a default DSCP for their application, lacking a 230 guideline means everyone picks for themselves - and usually with a 231 highly inflated sense of self importance for their application or 232 service. 234 Another point to make is that there are 20+ service classes defined 235 within the IETF, and that is far too many for most service providers 236 to manage effectively. So, they have formed groups around certain 237 aggregation solutions of service classes. One such aggregation group 238 is based on RFC 5127, which defines what it calls a treatment 239 aggregate, which is taking RFC 4594's service classes and placing 240 them each into one of four treatment aggregates for service 241 providers to handle as a group. SG12 within the ITU-T has an 242 alternative that has nine aggregate groups, so there is work to be 243 done to harmonize aggregates of service classes. This discussion is 244 articulated more in section 2.4. At the end of Section 2.4 we have 245 introduced a series of example configurations which provide examples 246 of how only a few service classes - yet still most treatment 247 aggregates - can be configured in example networks. 249 Does RFC 4594 need updating? That document is an informational 250 guideline on how networks can or should mark certain packet flows 251 with differing traffic characteristics using DiffServ. There are 252 several reasons why this informational RFC lacks the necessary 253 clarity and strength to reach widespread adoption: 255 o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of 256 which is for aggregating many 6-bit DSCP values into a 3-bit (8 257 value) field used specifically by service provider (SP) networks. 259 o some believe both RFCs are for SPs, while others ignore RFC 5127 260 and use RFC 4594 as if it were standards track or BCP. 262 o some believe RFC 5127 is for SPs only, and want RFC 4594 to 263 reduce the number of DSCPs within its guidelines to recommend 264 using only 3 or 4 DSCPs. This seems to stem from a manageability 265 and operational perspective. 267 o some know RFC 4594 is informational and do not follow its 268 guidelines specifically because it is informational. 270 o some use DSCP values that are not defined within RFC 4594, making 271 mapping between different networks using similar or identical 272 application flows difficult. 274 o some believe enterprise networks should not use either RFC except 275 at the edge of their networks, where they directly connect to SP 276 networks. 278 o some argue that the services classes guidance per class is too 279 broad and are therefore not sure in which service class a 280 particular application is to reside. 282 o time has shown that video has become a dominant application on 283 the Internet, and many believe it now requires to be treated 284 uniquely in environments that want to. Video also does not always 285 plan nice with audio, so knowing the two use the same transport 286 (RTP) [RFC3550], a means of separation is in order. 288 Service class definitions are based on the different traffic 289 characteristics and required performance of the 290 applications/services. There are a greater number of service classes 291 in this document than there were when RFC 4594 [RFC4594] was 292 published (the RFC this document intends to obsolete). The required 293 performance of applications/services has also changed since the 294 publication of RFC 4594, specifically in the area of conversational 295 real time communications. As a result, this document has a greater 296 number of real time applications with more granular set of DSCPs due 297 to their different required performances. Like RFC 4594 before, this 298 approach allows those applications with similar traffic 299 characteristics and performance requirements to be placed in the 300 same service class. 302 The notion of traffic characteristics and required performance is a 303 per application concept, therefore the label name of each service 304 class remains the same on an end-to-end basis, even if we understand 305 that DiffServ is only a PHB and cannot guarantee anything, even 306 packet delivery at the intended destination node. That said, 307 several applications can be configured to have the same DSCP, or 308 each have different DSCPs that have the same treatment per hop 309 within a network. 311 Since RFC 4594 was first published, a new concept has been 312 introduced that will appear throughout this document, including DSCP 313 assignments -- the idea of "admitted" traffic, initially introduced 314 into DiffServ within RFC 5865 [RFC5865]. The VOICE-ADMIT Expedited 315 Forwarding class differentiates itself from the EF Expedited 316 Forwarding by having the packets marked be for admitted traffic. 317 This concept of "admitted" traffic is spread throughout the real 318 time traffic classes. 320 Thus, the document flow is as follows: 322 o maintain the general format of RFC 4594; 324 o augment the content with the concept of capacity-admission; 326 o incorporate more video into this document, as it has become a 327 dominant application in enterprises and other managed networks, 328 as well as on the open public Internet; 330 o reduce the discussion on voice and its examples; 332 o articulate the subtle differences learned since RFC 4594 was 333 published. 335 The goal here is to provide a standard configuration for DiffServ 336 DSCP assignments and expected PHBs for enterprises and other managed 337 networks, as well as towards the public Internet with specific 338 traffic characteristics per Service class/DSCP, and example 339 applications shown for each. 341 This document describes service classes configured with DiffServ and 342 defines how they can be used and how to construct them using 343 Differentiated Services Code Points (DSCPs), and recommends how to 344 construct them using traffic conditioners, Per-Hop Behaviors (PHBs), 345 and Active Queue Management (AQM) mechanisms. There is no intrinsic 346 requirement that particular traffic conditioners, PHBs, and AQM be 347 used for a certain service class, but as a policy and for 348 interoperability it is useful to apply them consistently. 350 We differentiate services and their characteristics in Section 2. 351 Network control traffic, as well as user oriented traffic are 352 discussed in Sections 3 and 4, respectively. We analyze the security 353 considerations in Section 6. Section 7 offers a tribute to the 354 authors of RFC 4594, from which this document is based. It is in its 355 own section, and not part of the normal acknowledgements portion of 356 each IETF document. 358 1.1. Requirements Notation 360 The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL 361 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 362 in this document are to be interpreted as described in [RFC2119] 363 when they appear in ALL CAPS. These words may also appear in this 364 document in lower case as plain English words, absent their 365 normative meanings. 367 1.2. Expected Use in the Network 369 In the Internet today, corporate LANs and ISP WANs are increasingly 370 utilized, to the point in which network congestion is affecting 371 performance of applications. For this reason, congestion, loss, and 372 variation in delay within corporate LANs and ISP backbones is 373 becoming known to the users collectively as "the network is slow for 374 this application" or just "right now" or "for today". Users do not 375 directly detect network congestion. They react to applications that 376 run slow, or to downloads that take too long in their mind(s). The 377 explosion of video traffic on the internet recently has cause much 378 of this, and is often the application the user is using when they 379 have this slowness. 381 In the past, application slowness occurred for three very good 382 reasons. 384 o the networks the user oriented traffic traverses moves through 385 cycles of bandwidth boom and bandwidth bust, the latter of which 386 become apparent with the periodic deployment of new 387 bandwidth-hungry applications. 389 o In access networks, the state is often different. This may be 390 because throughput rates are artificially limited or 391 over-subscribed, or because of access network design trade-offs. 393 o Other characteristics, such as database design on web servers 394 (that may create contention points, e.g., in filestore) and 395 configuration of firewalls and routers, often look externally 396 like a bandwidth limitation. 398 The intent of this document is to provide a standardized marking, 399 plus a conditioning and packet treatment strategy so that it can be 400 configured and put into service on any link that is itself 401 congested. 403 1.3. Service Class Definition 405 A "service class" represents a similar set of traffic 406 characteristics for delay, loss, and jitter as packets traverse 407 routers in a network. For example, "High-Throughput Data" service 408 class for store-and-forward applications, or a "Broadcast" service 409 class for minimally time-shifted IPTV or Internet radio broadcasts. 410 Such a service class may be defined locally in a Differentiated 411 Services (DS) domain, or across multiple DS domains, possibly 412 extending end to end. A goal of this document is to have most/all 413 networks assign the same type of traffic the same for consistency. 415 A service class is a naming convention which is defined as a word, 416 phrase or initialism/acronym representing a set of necessary traffic 417 characteristics of a certain type of data flow. The necessary 418 characteristics of these traffic flows can be realized by the use of 419 defined per-hop behavior that started with [RFC2474]. The actual 420 specification of the expected treatment of a traffic aggregate 421 within a domain may also be defined as a per-domain behavior (PDB) 422 [RFC3086]. 424 Each domain will locally choose to 426 o implement one or more service classes with traffic 427 characteristics as defined here, or 429 o implement one or more service classes with similar traffic 430 characteristics as defined here, or 432 o implement one or more service classes with similar traffic 433 characteristics as defined here and to aggregate one or more 434 service classes to reduce the number of unique DSCPs within their 435 network, or 437 o implement one or more non-standard service classes with traffic 438 characteristics not as defined here, or 440 o not use DiffServ within their domain. 442 For example, low delay, low loss, and minimal jitter may be realized 443 using the EF PHB, or with an over-provisioned AF PHB. This must be 444 done with care as it may disrupt the end-to-end performance required 445 by the applications/services. If the packet sizes are similar within 446 an application, but different between two applications, say small 447 voice packets and large video packets, these two applications may 448 not realize optimum results if merged into the same aggregate if 449 there are any bottlenecks in the network. We provide for this 450 flexibility on a per hop or per domain basis within this document. 452 This document provides standardized markings for traffic with 453 similar characteristics, and usage expectations for PHBs for 454 specific service classes for their consistent implementation. 456 The Default Forwarding "Standard" service class is REQUIRED; all 457 other service classes are OPTIONAL. That said, each service class 458 lists traffic characteristics that are expected when using that type 459 of traffic. It is RECOMMENDED that applications and protocols that 460 fit a certain traffic characteristic use the appropriate service 461 class mark, i.e., the DSCP, for consistent behavior. It is expected 462 that network administrators will base their endpoint application and 463 router configuration choices on the level of service differentiation 464 they require to meet the needs of their customers (i.e., their 465 end-users). 467 1.4. Key Differentiated Services Concepts 469 In order to fully understand this document, a reader needs to 470 familiarize themselves with the principles of the Differentiated 471 Services Architecture [RFC2474]. We summarize some key concepts 472 here only to provide convenience for the reader, the referenced RFCs 473 providing the authoritative definitions. 475 1.4.1. Queuing 477 A queue is a data structure that holds packets that are awaiting 478 transmission. A router interface can only transmit one packet at a 479 time, however fast the interface speed is. If there is only 1 queue 480 at an interface, the packets are transmitted in the order they are 481 received into that queue - called FIFO, or "first in, first out". 482 Sometimes there is a lag in the time between a packets arrives in 483 the queue and when it is transmitted. This delay might be due to 484 lack of bandwidth, or if there are multiple queues on that 485 interface, because a packet is low in priority relative to other 486 packets that are awaiting to transmit. The scheduler is the system 487 entity that chooses which packet is next in line for transmission 488 when more than one packet are awaiting transmission out the same 489 router interface. 491 1.4.1.1 Priority Queuing 493 A priority queuing system is a combination of a set of queues and a 494 scheduler that empties the queues (of packets) in priority sequence. 495 When asked for a packet, the scheduler inspects the highest 496 priority queue and, if there is data present, returns a packet from 497 that queue. Failing that, it inspects the next highest priority 498 queue, and so on. A freeway onramp with a stoplight for one lane 499 that allows vehicles in the high-occupancy-vehicle lane to pass is 500 an example of a priority queuing system; the high-occupancy-vehicle 501 lane represents the "queue" having priority. 503 In a priority queuing system, a packet in the highest priority queue 504 will experience a readily calculated delay. This is proportional to 505 the amount of data remaining to be serialized when the packet 506 arrived plus the volume of the data already queued ahead of it in 507 the same queue. The technical reason for using a priority queue 508 relates exactly to this fact: it limits delay and variations in 509 delay and should be used for traffic that has that requirement. 511 A priority queue or queuing system needs to avoid starvation of 512 lower-priority queues. This may be achieved through a variety of 513 means, such as admission control, rate control, or network 514 engineering. 516 1.4.1.2. Rate Queuing 518 Similarly, a rate-based queuing system is a combination of a set of 519 queues and a scheduler that empties each at a specified rate. An 520 example of a rate-based queuing system is a road intersection with a 521 stoplight. The stoplight acts as a scheduler, giving each lane a 522 certain opportunity to pass traffic through the intersection. 524 In a rate-based queuing system, such as Weighted Fair Queuing (WFQ) 525 or Weighted Round Robin (WRR), the delay that a packet in any given 526 queue will experience depends on the parameters and occupancy of its 527 queue and the parameters and occupancy of the queues it is competing 528 with. A queue whose traffic arrival rate is much less than the rate 529 at which it lets traffic depart will tend to be empty, and packets 530 in it will experience nominal delays. A queue whose traffic arrival 531 rate approximates or exceeds its departure rate will tend not to be 532 empty, and packets in it will experience greater delay. Such a 533 scheduler can impose a minimum rate, a maximum rate, or both, on any 534 queue it touches. 536 1.4.2 Active Queue Management 538 Active Queue Management, or AQM, is a generic name for any of a 539 variety of procedures that use packet dropping or marking to manage 540 the depth of a queue. The canonical example of such a procedure is 541 Random Early Detection (RED), in that a queue is assigned a minimum 542 and maximum threshold, and the queuing algorithm maintains a moving 543 average of the queue depth. While the mean queue depth exceeds the 544 maximum threshold, all arriving traffic is dropped. While the mean 545 queue depth exceeds the minimum threshold but not the maximum 546 threshold, a randomly selected subset of arriving traffic is marked 547 or dropped. This marking or dropping of traffic is intended to 548 communicate with the sending system, causing its congestion 549 avoidance algorithms to kick in. As a result of this behavior, it 550 is reasonable to expect that TCP's cyclic behavior is desynchronized 551 and that the mean queue depth (and therefore delay) should normally 552 approximate the minimum threshold. 554 A variation of the algorithm is applied in Assured Forwarding PHB 555 [RFC2597], in that the behavior aggregate consists of traffic with 556 multiple DSCP marks, which are intermingled in a common queue. 557 Different minima and maxima are configured for the several DSCPs 558 separately, such that traffic that exceeds a stated rate at ingress 559 is more likely to be dropped or marked than traffic that is within 560 its contracted rate. 562 1.4.3 Traffic Conditioning 564 In addition, at the first router in a network that a packet crosses, 565 arriving traffic may be measured and dropped or marked according to 566 a policy, or perhaps shaped on network ingress, as in "A Rate 567 Adaptive Shaper for Differentiated Services" [RFC2963]. This may be 568 used to bias feedback loops, as is done in "Assured Forwarding PHB" 569 [RFC2597], or to limit the amount of traffic in a system, as is done 570 in "Expedited Forwarding PHB" [RFC3246]. Such measurement 571 procedures are collectively referred to as "traffic conditioners". 572 Traffic conditioners are normally built using token bucket meters, 573 for example with a committed rate and burst size, as in Section 574 1.5.3 of the DiffServ Model [RFC3290]. The Assured Forwarding PHB 575 [RFC2597] uses a variation on a meter with multiple rate and burst 576 size measurements to test and identify multiple levels of 577 conformance. 579 Multiple rates and burst sizes can be realized using multiple levels 580 of token buckets or more complex token buckets; these are 581 implementation details. The following are some traffic conditioners 582 that may be used in deployment of differentiated services: 584 o For Class Selector (CS) PHBs, a single token bucket meter to 585 provide a rate plus burst size control. 587 o For Expedited Forwarding (EF) PHB, a single token bucket meter to 588 provide a rate plus burst size control. 590 o For Assured Forwarding (AF) PHBs, usually two token bucket meters 591 configured to provide behavior as outlined in "Two Rate Three 592 Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color 593 Marker (srTCM)" [RFC2697]. The two-rate, three-color marker is 594 used to enforce two rates, whereas the single-rate, three-color 595 marker is used to enforce a committed rate with two burst 596 lengths. 598 1.4.4 Differentiated Services Code Point (DSCP) 600 The DSCP is a number in the range 0..63 that is placed into an IP 601 packet to mark it according to the class of traffic it belongs in. 602 These are divided into 3 groups, or pools, defined in RFC 2474, 603 arranged as follows: 605 o Pool-1 has 32 values designated for standards assignment (of the 606 form 'xxxxx0'). 608 o Pool-2 has 16 values designated for experimental or local use 609 only (EXP/LU) assignment (of the form 'xxxx11'). 611 o Pool-3 has 16 values designated for experimental or local use 612 (EXP/LU) assignment (of the form 'xxxx01'). 614 However, pool-3 is allowed to be assigned for one of two reasons, 616 #1 - if the values in pool-1 are exhausted, or 618 #2 - if there is a justifiable reason for assigning a pool-3 DSCP 619 prior to pool-1's exhaustion. 621 1.4.5 Per-Hop Behavior (PHB) 623 In the end, the mechanisms described above are combined to form a 624 specified set of characteristics for handling different kinds of 625 traffic, depending on the needs of the application. This document 626 seeks to identify useful traffic aggregates and to specify what PHB 627 should be applied to them. 629 1.5 Key Service Concepts 631 While Differentiated Services is a general architecture that may be 632 used to implement a variety of services, three fundamental 633 forwarding behaviors have been defined and characterized for general 634 use. These are basic Default Forwarding (DF) behavior for elastic 635 traffic, the Assured Forwarding (AF) behavior, and the Expedited 636 Forwarding (EF) behavior for real-time (inelastic) traffic. The 637 facts that four code points are recommended for AF and that one code 638 point is recommended for EF are arbitrary choices, and the 639 architecture allows any reasonable number of AF and EF classes 640 simultaneously. The choice of four AF classes and one EF class in 641 the current document is also arbitrary, and operators MAY choose to 642 operate more or fewer of either. 644 The terms "elastic" and "real-time" are defined in [RFC1633], 645 Section 3.1, as a way of understanding broad-brush application 646 requirements. This document should be reviewed to obtain a broad 647 understanding of the issues in quality of service, just as [RFC2475] 648 should be reviewed to understand the data plane architecture used in 649 today's Internet. 651 1.5.1 Default Forwarding (DF) 653 The basic forwarding behaviors applied to any class of traffic are 654 those described in [RFC2474] and [RFC2309]. Best-effort service may 655 be summarized as "I will accept your packets" and is typically 656 configured with some bandwidth guarantee. Packets in transit may be 657 lost, reordered, duplicated, or delayed at random. Generally, 658 networks are engineered to limit this behavior, but changing traffic 659 loads can push any network into such a state. 661 Application traffic in the internet that uses default forwarding is 662 expected to be "elastic" in nature. By this, we mean that the 663 sender of traffic will adjust its transmission rate in response to 664 changes in available rate, loss, or delay. 666 For the basic best-effort service, a single DSCP value is provided 667 to identify the traffic, a queue to store it, and active queue 668 management to protect the network from it and to limit delays. 670 1.5.2 Assured Forwarding (AF) 672 The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled 673 on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss 674 Priority (CLP) capability. It is intended for networks that offer 675 average-rate Service Level Agreements (SLAs) (as FR and ATM networks 676 do). This is an enhanced best-effort service; traffic is expected 677 to be "elastic" in nature. The receiver will detect loss or 678 variation in delay in the network and provide feedback such that the 679 sender adjusts its transmission rate to approximate available 680 capacity. 682 For such behaviors, multiple DSCP values are provided (two or three, 683 perhaps more using local values) to identify the traffic, a common 684 queue to store the aggregate, and active queue management to protect 685 the network from it and to limit delays. Traffic is metered as it 686 enters the network, and traffic is variously marked depending on the 687 arrival rate of the aggregate. The premise is that it is normal for 688 users occasionally to use more capacity than their contract 689 stipulates, perhaps up to some bound. However, if traffic should be 690 marked or lost to manage the queue, this excess traffic will be 691 marked or lost first. 693 1.5.3. Expedited Forwarding (EF) 695 The intent of Expedited Forwarding PHB [RFC3246] is to provide a 696 building block for low-loss, low-delay, and low-jitter services. It 697 can be used to build an enhanced best-effort service: traffic 698 remains subject to loss due to line errors and reordering during 699 routing changes. However, using queuing techniques, the probability 700 of delay or variation in delay is minimized. For this reason, it is 701 generally used to carry voice and for transport of data information 702 that requires "wire like" behavior through the IP network. Voice is 703 an inelastic "real-time" application that sends packets at the rate 704 the codec produces them, regardless of availability of capacity. As 705 such, this service has the potential to disrupt or congest a network 706 if not controlled. It also has the potential for abuse. 708 To protect the network, at minimum one SHOULD police traffic at 709 various points to ensure that the design of a queue is not overrun, 710 and then the traffic SHOULD be given a low-delay queue (often using 711 priority, although it is asserted that a rate-based queue can do 712 this) to ensure that variation in delay is not an issue, to meet 713 application needs. 715 1.5.4 Class Selector (CS) 717 Class Selector, those DSCPs that end in zeros (xxx000), provide 718 support for historical codepoint definitions and PHB requirement. 719 The CS fields provide a limited backward compatibility with legacy 720 practice, as described in [RFC2474], Section 4. Backward 721 compatibility is addressed in two ways, 723 - First, there are per-hop behaviors that are already in widespread 724 use (e.g., those satisfying the IPv4 Precedence queuing 725 requirements specified in [RFC1812]), and 727 - this document will continue to permit their use in DS-compliant 728 networks. 730 In addition, there are some DSCPs that correspond to historical use 731 of the IP Precedence field, 733 - CS0 (000000) will remain 'Default Forwarding' (also known as 'Best 734 Effort') 736 - 11xxxx will remain for routing traffic 738 and will map to PHBs that meet the general requirements specified in 739 [RFC2474], Section 4.2.2.2. 741 No attempt is made to maintain backward compatibility with the "DTR" 742 or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in 743 [RFC0791] and [RFC1349]. 745 A DS-compliant network can be deployed exclusively by using one or 746 more CS-compliant PHB groups. Thus, for example, codepoint '011000' 747 would map to the same PHB as codepoint '011010'. 749 1.5.5 Admission Control 751 Admission control (including refusal when policy thresholds are 752 crossed) can ensure high-quality communication by ensuring the 753 availability of bandwidth to carry a load. Inelastic real-time 754 flows such as Voice over Internet Protocol (VoIP) (audio) or video 755 conferencing services can benefit from use of an admission control 756 mechanism, as generally the audio or video service is configured 757 with over-subscription, meaning that some users may not be able to 758 make a call during peak periods. 760 For VoIP (audio) service, a common approach is to use signaling 761 protocols such as SIP, H.323, H.248, MEGACO, along with Resource 762 Reservation Protocol (RSVP) to negotiate admittance and use of 763 network transport capabilities. When a user has been authorized to 764 send voice traffic, this admission procedure has verified that data 765 rates will be within the capacity of the network that it will use. 767 Many RTP voice and video payloads are inelastic and cannot react to 768 loss or delay in any substantive way. For these payload types, the 769 network needs to police at ingress to ensure that the voice traffic 770 stays within its negotiated bounds. Having thus assured a 771 predictable input rate, the network may use a priority queue to 772 ensure nominal delay and variation in delay. 774 1.5.5.1 Capacity Admitted (*-Admit) 776 This is a newer group of traffic types that started with RFC 5865 777 and the Voice-Admit service type. Voice-Admit is an EF class marking 778 but has capacity-admission always applied to it to ensure each of 779 these flows are managed through a network, though not necessarily on 780 an end-to-end basis. This depends on how many networks each flow 781 transits and the load on each transited network. There are a series 782 of new DSCPs proposed in [ID-DSCP], each specifying unique 783 characteristics necessitating a separate marking from what existing 784 before that document. 786 This document will import in four new '*-Admit' DSCPs from 787 [ID-DSCP], 2 others that are new but not capacity-admitted, one from 788 RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594. 789 This is discussed throughout the rest of this document. 791 1.6 What Changes are Proposed Here from RFC 4594? 793 Changing an entire network DiffServ configuration has proven to be a 794 painful experience for both individuals and companies. It is not 795 done very often, and for good reason. This effort is based on 796 experience learned since the publication of RFC 4594 (circa 2006). 797 Audio, once thought to be ok grouped with video, needs to be in 798 separate service classes. Collaboration has taken off, mostly 799 because of mobility, but also because of a worldwide recession that 800 has limited physical travel, and relying on people to do more with 801 their computers. With that in mind, there has been an explosion in 802 application development for the individual (seems everyone has an 803 "app-store"). The following set of bullets has this world - that 804 needs a robust layer 3 - in mind. 806 o Scope of document is changed to tighten it up for standards track 807 consideration. 809 o This document explicitly states there is a fundamental requirement 810 that a particular DSCP(s) be used for each service class, each 811 with a recommended set of applications to be used by that service 812 class - at least on that individual's externally facing (public) 813 interface. 815 o Created the Conversational group of service classes to focus on 816 realtime, mostly bidirectional communications (unless multicast is 817 used). 819 o "Realtime-Interactive" 820 Moved to (near) realtime TCP-based apps 822 Why the change? TCP based transports have proven, in certain 823 environments, to be a bidirectional realtime transport, e.g., for 824 multiplayer gaming and virtual desktops applications. 826 o "Audio" 827 Same as Telephony (which is now gone), adds Voice-Admit for 828 capacity-admitted traffic 830 Why the change? RFC 5865 (Voice-Admit) needed to be added to the 831 Audio service class. Video needed to be separate from audio, hence 832 the name change from Telephony (which includes video) to just audio. 834 o "Video" 835 NEW for video and audio/video conferencing, was in 836 Multimedia-Conferencing service classification 838 Why the change? Many networks are using the AF4X for video, but 839 others are throwing anything "multimedia" into the same service 840 class (like elastic TCP flows). Video has become so dominant that it 841 should be what mostly goes into one service class. 843 o "Hi-Res" 844 NEW for video and audio/video conferencing 846 Why the change? This entirely new service class is for local policy 847 based higher end video (think Telepresence). Without congestion, 848 this service class has the same treatment as Video, but if there is 849 any pushback from the network, Hi-Res (note: not married to the 850 name) has a better PHB. 852 o "Multimedia-Conferencing" 853 Now without audio or human video 855 Why the change? The change is taking bidirectional human audio and 856 video out of this service class. This is all about non-realtime 857 collaboration - even in conjunction with an audio and/or video flow. 859 o "Broadcast" 860 Remains the same, added CS3-Admit for capacity-admitted 862 Why the change? Removing the "-Video" from the name because there 863 are so many more flows that are Broadcast in realtime than video. 865 o "Low-Latency Data" 866 Remains the same, adds IM & Presence traffic explicitly 868 Why the change? Merely explicitly stating a place for some 869 additional traffic types that otherwise could go elsewhere. 871 o "Conversational Signaling" (A/V-Sig) 872 Was 'Signaling' 874 Why the change? This change is merely a renaming of a service class, 875 and acknowledgement that some of the previous authors inaccurate 876 beliefs that DSCPs were linearly ordered with those values having a 877 higher value definitely getting better treatment than lower values. 879 2. Service Differentiation 881 There are practical limits on the level of service differentiation 882 that should be offered in the IP networks. We believe we have 883 defined a practical approach in delivering service differentiation 884 by defining different service classes that networks may choose to 885 support in order to provide the appropriate level of behaviors and 886 performance needed by current and future applications and services. 887 The defined structure for providing services allows several 888 applications having similar traffic characteristics and performance 889 requirements to be grouped into the same service class. This 890 approach provides a lot of flexibility in providing the appropriate 891 level of service differentiation for current and new, yet unknown 892 applications without introducing significant changes to routers or 893 network configurations when a new traffic type is added to the 894 network. 896 2.1 Service Classes 898 Traffic flowing in a network can be classified in many different 899 ways. We have chosen to divide it into two groupings, network 900 control and user/subscriber traffic. To provide service 901 differentiation, different service classes are defined in each 902 grouping. The network control traffic group can further be divided 903 into two service classes (see Section 3 for detailed definition of 904 each service class): 906 o "Network Control" for routing and network control function. 908 o "OAM" (Operations, Administration, and Management) for network 909 configuration and management functions. 911 The user/subscriber traffic group is broken down into ten service 912 classes to provide service differentiation for all the different 913 types of applications/services (see Section 4 for detailed 914 definition of each service class): 916 o Conversational service group consists of three service classes: 918 - Audio, which includes both 'admitted' and 'unadmitted' audio 919 service classes, is for non-one way (i.e., generally 920 bidirectional) audio media packets between human users of 921 smaller size and at a constant delivery rate. 923 - Hi-Res Video, which includes both 'admitted' and 'unadmitted' 924 Hi-Res Video service classes, is for video traffic from higher 925 end endpoints between human users necessitating different 926 treatment that from desktop or video phone endpoints. This has 927 a clearly business differentiation, and not a technical 928 differentiation - as both Hi-Res-Video and Video will be 929 treated similarly on the wire when no congestion occurs. 931 - Video, which includes both 'admitted' and 'unadmitted' video 932 service classes, is for video traffic from lower end endpoints 933 between human users necessitating different treatment that 934 from higher end (i.e., Telepresence) endpoints. This has a 935 clearly business differentiation, and not a technical 936 differentiation - as both Hi-Res-Video and Video will be 937 treated similarly on the wire when no congestion occurs. 939 o Conversational Signaling service class is for peer-to-peer and 940 client-server signaling and control functions using protocols 941 such as SIP, H.323, H.248, and Media Gateway Control Protocol 942 (MGCP). This traffic needs to not be starved on the network. 944 Editor's note: RFC 4594 had this DSCP marking as CS5, but with 945 clearly different characteristics (i.e., no 946 sensitivity to jitter or (unreasonable) delay), this 947 DSCP has been moved to a more appropriate (new) 948 value, defined in [ID-DSCP]. 950 o Real-Time Interactive, which includes both 'admitted' and 951 'unadmitted' Realtime-Interactive service class, is for 952 bidirectional variable rate inelastic applications that require 953 low jitter and loss and very low delay, such as interactive 954 gaming applications that use RTP/UDP streams for game control 955 commands, and Virtualized Desktop applications between the user 956 and content source, typically in a centralized data center. 958 o Multimedia Conferencing, which includes both 'admitted' and 959 'unadmitted' multimedia conferencing service class, is for 960 applications that require minimal delay, but not like those of 961 realtime application requirements. This service class can be 962 bursty in nature, as well as not transmit packets for some time. 963 Applications such as presentation data or collaborative 964 application sharing will use this service class. 966 o Multimedia Streaming, which includes both 'admitted' and 967 'unadmitted' multimedia streaming service class, is for one-way 968 bufferable streaming media applications such as Video on Demand 969 (VOD) and webcasts. 971 o Broadcast, which includes both 'admitted' and 'unadmitted' 972 broadcast service class, is for inelastic streaming media 973 applications that may be of constant or variable rate, requiring 974 low jitter and very low packet loss, such as broadcast TV and 975 live events, video surveillance, and security. 977 o Low-Latency Data service class is for data processing 978 applications such as client/server interactions or Instant 979 Messaging (IM) and Presence data. 981 o Conversational Signaling (A/V-Sig) service class is for all 982 signaling messages, whether in-band (i.e., along the data path) 983 or out-of-band (separate from the data path), for the purposes of 984 setting up, maintaining, managing and terminating bi- or 985 multi-directional realtime sessions. 987 o High-Throughput Data service class is for store and forward 988 applications such as FTP and billing record transfer. 990 o Standard service class, commonly called best effort (BE), is for 991 traffic that has not been identified as requiring differentiated 992 treatment. 994 o Low-Priority Data service class, which some could call the 995 scavenger class, is for packet flows where bandwidth assurance is 996 not required. 998 2.2 Categorization of User Oriented Service Classes 1000 The ten defined user/subscriber service classes listed above can be 1001 grouped into a small number of application categories. For some 1002 application categories, it was felt that more than one service class 1003 was needed to provide service differentiation within that category 1004 due to the different traffic characteristic of the applications, 1005 control function, and the required flow behavior. Figure 1 provides 1006 a summary of service class grouping into four application categories. 1008 Application Control Category 1010 o The Conversational Signaling service class is intended to be used 1011 to control applications or user endpoints. Examples of protocols 1012 that would use this service class are SIP, XMPP or H.323 for 1013 voice and/or video over IP services. User signaling flows have 1014 similar performance requirements as Low-Latency Data, they 1015 require a separate DSCP to be distinguished other traffic and 1016 allow for a treatment that is unique. 1018 Media-Oriented Category 1020 Due to the vast number of new (in process of being deployed) and 1021 already-in-use media-oriented services in IP networks, seven service 1022 classes have been defined. 1024 o Audio service class is intended for Voice-over-IP (VoIP) 1025 services. It may also be used for other applications that meet 1026 the defined traffic characteristics and performance requirements. 1028 o Video service class is intended for Video over IP services. It 1029 may also be used for other applications that meet the defined 1030 traffic characteristics and performance requirements. 1032 o Hi-Res service class is intended for higher end video services 1033 that have the same traffic characteristics as the video service 1034 class, but have a business requirement(s) to be treated 1035 differently. One example of this is Telepresence video 1036 applications. 1038 o Realtime-Interactive service class is intended for inelastic 1039 applications such as desktop virtualization applications and for 1040 interactive gaming. 1042 o Multimedia Conferencing service class is for everything about or 1043 within video conferencing solutions that does not include the 1044 voice or (human) video components. Several examples are 1046 - the presentation data part of an IP conference (call). 1048 - the application sharing part of an IP conference (call). 1050 - the whiteboarding aspect of an IP conference (call). 1052 Each of the above can be part of a lower end web-conferencing 1053 application or part of a higher end Telepresence video 1054 conference. Each also has the ability to reduce their 1055 transmission rate on detection of congestion. These flows can 1056 therefore be classified as rate adaptive and most often more 1057 elastic than their voice and video counterparts. 1059 o Broadcast Video service class is to be used for inelastic traffic 1060 flows specifically with minimal buffering expected by the source 1061 or destination, which are intended for broadcast HDTV service, as 1062 well as for transport of live video (sports or concerts) and 1063 audio events. 1065 o Multimedia Streaming service class is to be used for elastic 1066 multimedia traffic flows where buffering is expected. This is 1067 the fundamental difference between the Broadcast and multimedia 1068 streaming service classes. Multimedia streaming content is 1069 typically stored before being transmitted. It is also buffered 1070 at the receiving end before being played out. The buffering is 1071 sufficiently large to accommodate any variation in transmission 1072 rate that is encountered in the network. Multimedia 1073 entertainment over IP delivery services that are being developed 1074 can generate both elastic and inelastic traffic flows; therefore, 1075 two service classes are defined to address this space, 1076 respectively: Multimedia Streaming and Broadcast Video. 1078 Data Category 1080 The data category is divided into three service classes. 1082 o Low-Latency Data for applications/services that require low delay 1083 or latency for bursty but short-lived flows. 1085 o High-Throughput Data for applications/services that require good 1086 throughput for long-lived bursty flows. High Throughput and 1087 Multimedia Steaming are close in their traffic flow 1088 characteristics with High Throughput being a bit more bursty and 1089 not as long-lived as Multimedia Streaming. 1091 o Low-Priority Data for applications or services that can tolerate 1092 short or long interruptions of packet flows. The Low-Priority 1093 Data service class can be viewed as "don't care" to some degree. 1095 Best-Effort Category 1097 o All traffic that is not differentiated in the network falls into 1098 this category and is mapped into the Standard service class. If 1099 a packet is marked with a DSCP value that is not supported in the 1100 network, it SHOULD be forwarded using the Standard service class. 1102 Figure 1, below, provides a grouping of the defined user/subscriber 1103 service classes into four categories, with indications of which ones 1104 use an independent flow for signaling or control; type of flow 1105 behavior (elastic, rate adaptive, or inelastic); and the last column 1106 provides end user Class of Service (CoS) rating as defined in ITU-T 1107 Recommendation G.1010. 1109 ----------------------------------------------------------------- 1110 | Application | Service | Signaled | Flow | G.1010 | 1111 | Categories | Class | | Behavior | Rating | 1112 |-------------+---------------+----------+-----------+------------| 1113 | Application | A/V Sig | Not | Inelastic | Responsive | 1114 | Control | |applicable| | | 1115 |-------------+---------------+----------+-----------+------------| 1116 | | Realtime | Yes | Inelastic | Interactive| 1117 | | Interactive | | | | 1118 | |---------------+----------+-----------+------------| 1119 | | Audio | Yes | Inelastic | Interactive| 1120 | |---------------+----------+-----------+------------| 1121 | | Video | Yes | Inelastic | Interactive| 1122 | |---------------+----------+-----------+------------| 1123 | | Hi-Res | Yes | Inelastic | Interactive| 1124 | |---------------+----------+-----------+------------| 1125 | Media- | Multimedia | Yes | Rate | Moderately | 1126 | Oriented | Conferencing| | Adaptive | Interactive| 1127 | |---------------+----------+-----------+------------| 1128 | | Broadcast | Yes | Inelastic | Responsive | 1129 | |---------------+----------+-----------+------------| 1130 | | Multimedia | Yes | Elastic | Timely | 1131 | | Streaming | | | | 1132 |-------------+---------------+----------+-----------+------------| 1133 | | Low-Latency | No | Elastic | Responsive | 1134 | | Data | | | | 1135 | |---------------+----------+-----------+------------| 1136 | Data | Conversational| No |Elastic or | Timely | 1137 | | Signaling | | Inelastic | | 1138 | |---------------+----------+-----------+------------| 1139 High- | No | Elastic | Timely | 1140 | |Throughput Data| | | | 1141 | |---------------+----------+-----------+------------| 1142 | | Low- | No | Elastic |Non-critical| 1143 | | Priority Data | | | | 1144 |-------------+---------------+----------+-----------+------------| 1145 | Best Effort | Standard | Not Specified |Non-critical| 1146 ----------------------------------------------------------------- 1148 Figure 1. User/Subscriber Service Classes Grouping 1150 Here is a short explanation of the end user CoS category as defined 1151 in ITU-T Recommendation G.1010. User oriented traffic is divided 1152 into four different categories, namely, interactive, responsive, 1153 timely, and non-critical. An example of interactive traffic is 1154 between two humans and is most sensitive to delay, loss, and jitter. 1155 Another example of interactive traffic is between two servers where 1156 very low delay and loss are needed. Responsive traffic is typically 1157 between a human and a server but can also be between two servers. 1158 Responsive traffic is less affected by jitter and can tolerate 1159 longer delays than interactive traffic. Timely traffic is either 1160 between servers or servers and humans and the delay tolerance is 1161 significantly longer than responsive traffic. Non-critical traffic 1162 is normally between servers/machines where delivery may be delay for 1163 period of time. 1165 2.3. Service Class Characteristics 1167 This document specifies what network administrators are to expect 1168 when configuring service classes identified by their differing 1169 characteristics. Figure 2 identifies these service classes along 1170 with their characteristics, as well as the tolerance to loss, delay 1171 and jitter for each service class. Properly engineered networks to 1172 these PHBs will achieve expected results. That said, not all of the 1173 identified service classes are expected in each operator's network. 1175 ------------------------------------------------------------------- 1177 |Service Class | | Tolerance to | 1178 | Name | Traffic Characteristics | Loss |Delay |Jitter| 1179 |===============+==============================+======+======+======| 1180 | Network |Variable size packets, mostly | | | | 1181 | Control |inelastic short messages, but | Low | Low | Yes | 1182 | |traffic can also burst (BGP) | | | | 1183 |---------------+------------------------------+------+------+------| 1184 | Realtime | Inelastic, mostly variable | Low | Very | Low | 1185 | Interactive | rate | | Low | | 1186 +---------------+------------------------------+------+------+------+ 1187 | | Fixed-size small packets, | Very | Very | Very | 1188 | Audio | inelastic | Low | Low | Low | 1189 | | | | | | 1190 +---------------+------------------------------+------+------+------+ 1191 | | Fixed-size small-large | Very | Very | Very | 1192 | Video | packets, inelastic | Low | Low | Low | 1193 | | | | | | 1194 +---------------+------------------------------+------+------+------+ 1195 | | Fixed-size small-large | Very | Very | Very | 1196 | Hi-Res A/V | packets, inelastic | Low | Low | Low | 1197 | | | | | | 1198 +---------------+------------------------------+------+------+------+ 1199 | Multimedia | Variable size packets, | Low | Low | Low | 1200 | Conferencing | constant transmit interval, | - | - | - | 1201 | | rate adaptive, reacts to loss|Medium|Medium|Medium| 1202 +---------------+------------------------------+------+------+------+ 1203 | Multimedia | Variable size packets, |Low - |Medium| High | 1204 | Streaming | elastic with variable rate |Medium| | | 1205 +---------------+------------------------------+------+------+------+ 1206 | Broadcast | Constant and variable rate, | Very |Medium| Low | 1207 | | inelastic, non-bursty flows | Low | | | 1208 +---------------+------------------------------+------+------+------+ 1209 | Low-Latency | Variable rate, bursty short- | Low |Low - | Yes | 1210 | Data | lived elastic flows | |Medium| | 1211 |---------------+------------------------------+------+------+------| 1212 |Conversational | Variable size packets, some | Low | Low | Yes | 1213 | Signaling | what bursty short-lived flows| | | | 1214 |---------------+------------------------------+------+------+------| 1215 | OAM | Variable size packets, | Low |Medium| Yes | 1216 | | elastic & inelastic flows | | | | 1217 |---------------+------------------------------+------+------+------| 1218 | High- | Variable rate, bursty long- | Low |Medium| Yes | 1219 |Throughput Data| lived elastic flows | |- High| | 1220 |---------------+------------------------------+------+------+------| 1221 | Standard | A bit of everything | Not Specified | 1222 |---------------+------------------------------+------+------+------| 1223 | Low-Priority | Non-real-time and elastic | High | High | Yes | 1224 | Data | | | | | 1225 ------------------------------------------------------------------- 1227 Figure 2. Service Class Characteristics 1229 Notes for Figure 2: A "Yes" in the jitter-tolerant column implies 1230 that received data is buffered at the endpoint and that a moderate 1231 level of server or network-induced variation in delay is not 1232 expected to affect the application. Applications that use TCP or 1233 SCTP as a transport are generally good examples. Routing protocols 1234 and peer-to-peer signaling also fall in this class; although loss 1235 can create problems in setting up calls, a moderate level of jitter 1236 merely makes call placement a little less predictable in duration. 1238 Service classes indicate the required traffic forwarding treatment 1239 in order to meet user, application, and/or network expectations. 1240 Section 3 defines the service classes that MAY be used for 1241 forwarding network control traffic, and Section 4 defines the 1242 service classes that MAY be used for forwarding user oriented 1243 traffic with examples of intended application types mapped into each 1244 service class. Note that the application types are only examples 1245 and are not meant to be all-inclusive or prescriptive. Also, note 1246 that the service class naming or ordering does not imply any 1247 priority ordering. They are simply reference names that are used in 1248 this document with associated QoS behaviors that are optimized for 1249 the particular application types they support. Network 1250 administrators MAY choose to assign different service class names to 1251 the service classes that they will support. Figure 3 defines the 1252 RECOMMENDED relationship between service classes and DS codepoint 1253 assignment with application examples. It is RECOMMENDED that this 1254 relationship be preserved end to end. 1256 +------------------------------------------------------------------+ 1257 | Service | DSCP | DSCP | Application | 1258 | Class Name | Name | Value | Examples | 1259 |===============+=========+=============+==========================| 1260 |Network Control| CS6&CS7 | 11xxxx | Network routing | 1261 |---------------+---------+-------------+--------------------------| 1262 | Realtime | CS5, | 101000, | Remote/Virtual Desktop | 1263 | Interactive |CS5-Admit| 101001 | and Interactive gaming | 1264 |---------------+---------+-------------+--------------------------| 1265 | Audio | EF | 101110 | Voice bearer | 1266 | |Voice-Admit| 101100 | | 1267 |---------------+---------+-------------+--------------------------| 1268 | Hi-Res A/V | CS4, | 100000, | Conversational Hi-Res | 1269 | |CS4-Admit| 100001 | Audio/Video bearer | 1270 |---------------+---------+-------------+--------------------------| 1271 | Video |AF41,AF42|100010,100100| Audio/Video conferencing | 1272 | | AF43 | 100110 | bearer | 1273 |---------------+---------+-------------+--------------------------| 1274 | Multimedia | MC, | 011101, | Presentation Data and | 1275 | Conferencing | MC-Admit| 100101 | App Sharing/Whiteboarding| 1276 |---------------+---------+-------------+--------------------------| 1277 | Multimedia |AF31,AF32|011010,011100| Streaming video and | 1278 | Streaming | AF33 | 011110 | audio on demand | 1279 |---------------+---------+-------------+--------------------------| 1280 | Broadcast | CS3, | 011000, | Broadcast TV, live events| 1281 | |CS3-Admit| 011001 | & video surveillance | 1282 |---------------+---------+-------------+--------------------------| 1283 | Low-Latency |AF21,AF22|010010,010100|Client/server trans., Web-| 1284 | Data | AF23 | 010110 |based ordering, IM/Pres | 1285 |---------------+---------+-------------+--------------------------| 1286 |Conversational | A/V-Sig | 010001 | Conversational signaling | 1287 | Signaling | | | | 1288 |---------------+---------+-------------+--------------------------| 1289 | OAM | CS2 | 010000 | OAM&P | 1290 |---------------+---------+-------------+--------------------------| 1291 |High-Throughput|AF11,AF12|001010,001100| Store and forward | 1292 | Data | AF13 | 001110 | applications | 1293 |---------------+---------+-------------+--------------------------| 1294 | Low-Priority | CS1 | 001000 | Any flow that has no BW | 1295 | Data | | | assurance | 1296 |------------------------------------------------------------------| 1297 | Best Effort | CS0 | 000000 | Undifferentiated | 1298 | | | | applications | 1299 +---------------+---------+-------------+--------------------------+ 1301 Figure 3. DSCP to Service Class Mapping 1303 Notes for Figure 3: 1305 o Default Forwarding (DF) and Class Selector 0 (CS0) (i.e., Best 1306 Effort) provide equivalent behavior and use the same DS 1307 codepoint, '000000'. 1309 o RFC 2474 identifies any DSCP with a value of 11xxxx to be for 1310 network control. This remains true, while it removes 12 DSCPs 1311 from the overall pool of 64 available DSCP values (the 4 that are 1312 x11 from this group are within pool 2 of RFC 2474, and remain as 1313 only experimentally assignable/useable). 1315 o All PHB names that say "-Admit" are to be used only when a 1316 capacity-admission protocol is utilized for that or each traffic 1317 flow. 1319 Changes from table 3 of RFC 4594 are as follows: 1321 o The old term "Signaling" was using CS5 (101000), now is 1322 exclusively for the "Conversational Signaling" service group 1323 using the DSCP name of "A/V-Sig" (010001), which is newly defined 1324 in [ID-DSCP]. This is because CS5 aggregates into the 101xxx 1325 aggregate when using layer 2 technologies such as 802.3 Ethernet, 1326 802.11 Wireless Ethernet MPLS, etc - each of which only have 3 1327 bits to mark with. A traffic type that can have very large 1328 packets and is not delay sensitive (within reason) is not 1329 appropriate for have a 101xxx marking. A REQUIRED behavior for 1330 this PHB is that it not be starved in any node. 1332 o "Conversational" is a new term to include all interactive audio 1333 and video. The Conversational service group consists of the audio 1334 service class, the video service class and the new Hi-Res service 1335 class. 1337 o "Audio" obsoletes the term "Telephony", which has generally not 1338 retained the "video" aspect within the IETF, where video is still 1339 commonly called out as a separate thing. Audio retains the 1340 nonadmitted traffic PHB of EF (101110), while capacity-admitted 1341 audio has been added via the RFC 5865 defined PHB Voice-Admit. 1343 o "Video" now is AF4x, with AF41 specifically for capacity-admitted 1344 video traffic, while AF42 and AF43 are nonadmitted video traffic. 1346 o "Hi-Res A/V", part of the Conversational service group, is 1347 created by [ID-DSCP] for an additional business differentiation 1348 interactive video marking for higher end traffic. It is within 1349 the 100xxx as CS4 (for nonadmitted traffic) and CS4-Admit 1350 (100001) (for capacity-admitted traffic). 1352 o "Realtime Interactive" is now using CS5 (for nonadmitted 1353 traffic), but adds a capacity-admitted DSCP CS5-Admit (101001). 1355 o "Multimedia Conferencing" is no longer using the AF4x DSCPs, 1356 rather it will use the new PHB MC (100101) (for 1357 capacity-admitted) and MC-Admit (011101) (for nonadmitted 1358 traffic). 1360 o "Multimedia Streaming" retains using AF3x, however, AF31 is now 1361 used for capacity-admitted traffic, while AF32/33 are 1362 nonadmitted. 1364 o "Broadcast" replaces "Broadcast Video" using CS3 (for nonadmitted 1365 traffic), and adds a capacity-admitted PHB CS3-Admit (011001). 1367 It is expected that network administrators will base their choice of 1368 the service classes that they will support on their need. 1370 Figure 4 provides a summary of DiffServ CoS mechanisms that MUST be 1371 used for the defined service classes that are further detailed in 1372 Sections 3 and 4 of this document. According to what 1373 applications/services need to be differentiated, network 1374 administrators MAY choose the service class(es) that need to be 1375 supported in their network. 1377 +-----------------------------------------------------------------+ 1378 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| 1379 | Class | | DS Edge | Used | | | 1380 |===============+=======+===================+=======+========+====| 1381 |Network Control|CS6/CS7| See Section 3.1 |RFC2474| Rate | Yes| 1382 |---------------+-------+-------------------+-------+--------+----| 1383 | Realtime | CS5, |Police using sr+bs |RFC2474| Rate | No | 1384 | Interactive | CS5- | | | | | 1385 | | Admit*| |[ID-DSCP]| | | 1386 |---------------+-------+-------------------+-------+--------+----| 1387 | | EF, |Police using sr+bs |RFC3246|Priority| No | 1388 | Audio |Voice- | | | | | 1389 | | Admit*| |RFC5865| | | 1390 |---------------+-------+-------------------+-------+--------+----| 1391 | | CS4, |Police using sr+bs |RFC2474|Priority| No | 1392 | Hi-Res A/V | CS4- | | | | | 1393 | | Admit*| |[ID-DSCP]| | | 1394 |---------------+-------+-------------------+-------+--------+----| 1395 | | AF41*,| Using two-rate, | | | Yes| 1396 | Video | AF42 |three-color marker |RFC2597| Rate | per| 1397 | | AF43 | (such as RFC 2698)| | |DSCP| 1398 |---------------+-------+-------------------+-------+--------+----| 1399 | Multimedia | MC, |Police using sr+bs|[ID-DSCP]| Rate | No | 1400 | Conferencing | MC- | | | | | 1401 | | Admit*| |[ID-DSCP]| | | 1402 |---------------+-------+-------------------+-------+--------+----| 1403 | Multimedia | AF31*,| Using two-rate, | | | Yes| 1404 | Streaming | AF32 |three-color marker |RFC2597| Rate | per| 1405 | | AF33 | (such as RFC 2698)| | |DSCP| 1406 |---------------+-------+-------------------+-------+--------+----| 1407 | Broadcast | CS3, |Police using sr+bs |RFC2474| Rate | No | 1408 | | CS3- | | | | | 1409 | | Admit*| |[ID-DSCP]| | | 1410 |---------------+-------+-------------------+-------+--------+----| 1411 | Low- | AF21 | Using single-rate,| | | Yes| 1412 | Latency | AF22 |three-color marker |RFC2597| Rate | per| 1413 | Data | AF23 | (such as RFC 2697)| | |DSCP| 1414 |---------------+-------+-------------------+-------+--------+----| 1415 |Conversational |AV-Sig |Police using sr+bs|[ID-DSCP]| Rate | No | 1416 | Signaling | | | | | | 1417 |---------------+-------+-------------------+-------+--------+----| 1418 | OAM | CS2 |Police using sr+bs |RFC2474| Rate | Yes| 1419 |---------------+-------+-------------------+-------+--------+----| 1420 | High- | AF11 | Using two-rate, | | | Yes| 1421 | Throughput | AF12 |three-color marker |RFC2597| Rate | per| 1422 | Data | AF13 | (such as RFC 2698)| | |DSCP| 1423 |---------------+-------+-------------------+-------+--------+----| 1424 | Standard | DF | Not applicable |RFC2474| Rate | Yes| 1425 |---------------+-------+-------------------+-------+--------+----| 1426 | Low-Priority | CS1 | Not applicable |RFC3662| Rate | Yes| 1427 | Data | | | | | | 1428 |---------------+-------+-------------------+-------+--------+----| 1430 Figure 4. Summary of CoS Mechanisms Used for Each Service Class 1432 * denotes each DSCP identified for capacity-admission traffic only. 1434 Notes for Figure 4: 1436 o Conditioning at DS edge means that traffic conditioning is 1437 performed at the edge of the DiffServ network where untrusted 1438 user devices are connected to two different administrative 1439 DiffServ networks. 1441 o "sr+bs" represents a policing mechanism that provides single rate 1442 with burst size control. 1444 o The single-rate, three-color marker (srTCM) behavior SHOULD be 1445 equivalent to RFC 2697, and the two-rate, three-color marker 1446 (trTCM) behavior SHOULD be equivalent to RFC 2698. 1448 o The PHB for Realtime-Interactive service class SHOULD be 1449 configured to provide high bandwidth assurance. It MAY be 1450 configured as another EF PHB (one capacity-admitted and one 1451 non-capacity-admitted, if both are to be used) that uses relaxed 1452 performance parameters and a rate scheduler. 1454 o The PHB for Multimedia Conferencing service class SHOULD be 1455 configured to provide high bandwidth assurance. It MAY be 1456 configured as another EF PHB (one capacity-admitted and one 1457 non-capacity-admitted, if both are to be used) that uses relaxed 1458 performance parameters and a rate scheduler. 1460 o The PHB for Broadcast service class SHOULD be configured to 1461 provide high bandwidth assurance. It MAY be configured as 1462 another EF PHB (one capacity-admitted and one 1463 non-capacity-admitted, if both are to be used) that uses relaxed 1464 performance parameters and a rate scheduler. 1466 2.4. Service Classes vs. Treatment Aggregates (from RFC 5127) 1468 There are misconceptions about the differences between RFC 4594 1469 specified service classes, and RFC 5127 specified treatment 1470 aggregates. Often the two are conflated, and more often the phrase 1471 service class is used to mean both definitions. Almost all of the 1472 text previous to this section is used in defining service classes, 1473 and how one service class is different than another service class 1474 (based on traffic characteristics of the applications). Treatment 1475 aggregates are groupings of service classes with similar, but not 1476 identical, traffic characteristics to give similar treatment from a 1477 SP's network. 1479 Below is taken from appendix of RFC 5127 as its recommended 1480 groupings of service classes into aggregates based in RFC 4594 1481 specified traffic characteristic expectations. 1483 +------------------------------------------------------------+ 1484 |Treatment |Treatment || DSCP | 1485 |Aggregate |Aggregate || | 1486 | |Behavior || | 1487 |==========+==========++=====================================| 1488 | Network | CS || CS6 | 1489 | Control |(RFC 2474)|| | 1490 |==========+==========++=====================================| 1491 | Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | 1492 | Time* |(RFC 3246)|| | 1493 |==========+==========++=====================================| 1494 | Assured | AF || CS2, AF31, AF21, AF11 | 1495 | Elastic |(RFC 2597)||-------------------------------------| 1496 | | || AF32, AF22, AF12 | 1497 | | ||-------------------------------------| 1498 | | || AF33, AF23, AF13 | 1499 |==========+==========++=====================================| 1500 | Elastic | Default || Default, (CS0) | 1501 | |(RFC 2474)||-------------------------------------| 1502 | | || CS1 | 1503 +------------------------------------------------------------+ 1505 Figure 5: RFC 5127 Defined Treatment Aggregate Behavior** 1507 *NOTE: The RFC 5865 created VOICE-ADMIT is absence from the above 1508 figure because VOICE-ADMIT was created far later than this 1509 recommendation was. VOICE-ADMIT is appropriate for the 1510 Realtime Traffic Aggregate. 1512 **NOTE: Figure 5 is directly from the appendix of RFC 5127 as that 1513 RFC's recommendation for configuration. This draft does not 1514 directly affect RFC 5127. That is left for an update to RFC 1515 5127 itself. Based on the WG's take on this draft, RFC 5127 1516 will necessitate an update to match this document's new 1517 service classes and additional DSCPs. The number of treatment 1518 aggregates are not expected to change in the RFC 5127 Update 1519 draft though, with the possible exception of a new treatment 1520 aggregate for capacity admitted flows; meaning there *might* 1521 be a 5th treatment aggregate proposed. 1523 Treatment Aggregates are designed to nicely fit into technologies 1524 that do not have many different treatment levels to use. Here are 3 1525 examples of technologies limited to an 8-value field, 1527 - MPLS with its 3 Traffic Class (TC) bits [RFC5462]. 1529 - IEEE LANs with its 8-value Priority Code Point (PCP) field, as 1530 part of the 802.1Q header spec [IEEE1Q]. 1532 - IEEE 802.1e, which defines QoS over Wi-Fi, also only defines 8 1533 levels (called User Priority or UP codes) [IEEE1E]. 1535 Treatment Aggregates are dependent on service classes to exist. 1536 Therefore many service classes can exist without the need to 1537 consider the use of treatment aggregates or their 8-value 1538 technologies. For example, a Layer 3 VPN can be all that is needed 1539 to transit traffic flows, regardless of desired treatment, between 1540 enterprise LAN campuses. From this reality, the number of treatment 1541 aggregates has no direct bearing on the number of service classes. 1543 2.4.1 Examples of Service Classes in Treatment Aggregates 1545 It is *not* expected that all traffic characteristics are to be 1546 experienced across an SP's network for any given customer. For 1547 example, if VOICE-ADMIT is added to the Realtime Treatment Aggregate 1548 in Figure 5, there are 8 different service classes within the 1549 Realtime Treatment Aggregate. It is not expected that all 8 service 1550 classes will be deployed by customer networks traversing SP 1551 networks. RFC 5127's Treatment Aggregates are a table to configure 1552 which service class goes into which treatment aggregate. If there 1553 are 8 services classes in the Realtime treatment aggregate, there is 1554 very little difference than if there were one service within that 1555 same Realtime treatment aggregate - it would still be necessary to 1556 configure that treatment aggregate. Thus, it becomes a question of 1557 not 1559 "how many service classes are there that go into treatment 1560 aggregates?" 1562 but 1564 "how many treatment aggregates have one or more services 1565 classes requiring configuration"? 1567 Of the 4 treatment aggregates shown in Figure 5, if there are 1568 existing service classes in only 3 of the aggregates, then only 3 1569 treatment aggregates are necessary. Of the 3 following examples, 1570 notice that examples 2 and 3 have the same number of treatment 1571 aggregates, but example 3 has more applications in their own 1572 service classes. 1574 Examples 2 and 3 are made under the following assumptions: 1576 - this draft's Service Classes and DSCP assignments are utilized. 1578 - the new AF-Sig DSCP in the Assured Elastic treatment aggregate. 1580 - the Audio, Video service classes are in the EF treatment 1581 aggregate. 1583 - the VOICE-ADMIT DSCP is in the EF treatment aggregate. 1585 2.4.1.1 Example 1 - Simple Voice Configuration/SLA 1587 For example 1, we have an SP running MPLS and has an SLA to deliver 1588 Network Control, Voice and everything else is Best Effort. The 1589 following table would apply to this configuration/SLA: 1591 +----------------+----------------+-----------+--------------+ 1592 | Applications | Service | DSCP(s) | Treatment | 1593 | | Class | | Aggregate | 1594 +================+================+===========+==============+ 1595 | Network | Network | CS6 | Network | 1596 | Control | Control | | Control | 1597 +----------------+----------------+-----------+--------------+ 1598 | Voice | Audio | EF | Realtime | 1599 +----------------+----------------+-----------+--------------+ 1600 | Everything | DF | Default | Elastic | 1601 | else | | (CS0) | | 1602 +----------------+----------------+-----------+--------------+ 1604 Figure 6. Example 1 Configuration 1606 Insert different treatments for this example 1607 (i.e., AQM, RED, WFQ, colors, etc from above charts) 1609 2.4.1.2 Example 2 - Voice/Video/Surveillance Configuration/SLA 1611 For example 1, we have an SP running MPLS and has an SLA to deliver 1612 Control, audio, video, surveillance, audio & video signaling, and 1613 everything else is BE 1615 +----------------+----------------+-----------+--------------+ 1616 | Applications | Service | DSCP(s) | Treatment | 1617 | | Class | | Aggregate | 1618 +================+================+===========+==============+ 1619 | Network | Network | CS6 | Network | 1620 | Control | Control | | Control | 1621 +----------------+----------------+-----------+--------------+ 1622 | Voice, video, | Audio, Video, | EF, AF42, | Realtime | 1623 | surveillance | Broadcast | CS3 | | 1624 +----------------+----------------+-----------+--------------+ 1625 | audio & video | Conversational | AV-Sig | Assured | 1626 | signaling | Signaling | | Elastic | 1627 +----------------+----------------+-----------+--------------+ 1628 | Everything | DF | Default | Elastic | 1629 | else | | (CS0) | | 1630 +----------------+----------------+-----------+--------------+ 1632 Figure 7. Example 2 Configuration 1634 Insert different treatments for this example 1635 (i.e., AQM, RED, WFQ, colors, etc from above charts) 1637 2.4.1.2 Example 3 - Complex CAC realtime/Surveillance/+apps 1638 Configuration/SLA 1640 For example 1, we have an SP running MPLS and has an SLA to deliver 1641 Control, voice, CAC voice, CAC video, streaming, signaling, LL 1642 data, Network Mgmt., and everything else is BE (including non-CAC 1643 video because it is not authorized or authenticated on network) 1645 +-------------------+-----------------+-----------+--------------+ 1646 | Applications | Service | DSCP(s) | Treatment | 1647 | | Class | | Aggregate | 1648 +===================+=================+===========+==============+ 1649 | Network | Network | CS6 | Network | 1650 | Control | Control | | Control | 1651 +-------------------+-----------------+-----------+--------------+ 1652 | Voice, CAC-Voice | Audio, Video, |Voice-Admit| Realtime | 1653 | CAC-video, | | EF, AF41 | | 1654 | surveillance | Broadcast | CS3 | | 1655 +-------------------+-----------------+-----------+--------------+ 1656 | audio & video | Conversational | AV-Sig | Assured | 1657 | signaling, | Signaling, Low- | AF21 | Elastic | 1658 | VOD (streaming), | Latency Data, | AF31 | | 1659 | Network Mgmt. | Multimedia | CS2 | | 1660 | | Streaming, | | | 1661 | | OAM | | | 1662 +-------------------+-----------------+-----------+--------------+ 1663 | Everything | DF | Default | Elastic | 1664 | else | | (CS0) | | 1665 +-------------------+-----------------+-----------+--------------+ 1667 Figure 8. Example 3 Configuration 1669 Insert different treatments for this example 1670 (i.e., AQM, RED, WFQ, colors, etc from above charts) 1672 3. Network Control Traffic 1674 Network control traffic is defined as packet flows that are 1675 essential for stable operation of an administered network, as well 1676 as the information exchanged between neighboring networks across a 1677 peering point where SLAs are in place. Network control traffic is 1678 different from user application control (signaling) that may be 1679 generated by some applications or services. Network control traffic 1680 is mostly between routers and network nodes (e.g., routing or mgmt 1681 protocols) that are used for operating, administering, controlling, 1682 or managing whole networks, network parts or just network segments. 1683 Network Control Traffic may be split into two service classes, i.e., 1684 Network Control and OAM. 1686 3.1. Current Practice in the Internet 1688 Based on today's routing protocols and network control procedures 1689 that are used in the Internet, we have determined that CS6 DSCP 1690 value SHOULD be used for routing and control and that CS7 DSCP value 1691 SHOULD be reserved for future use, specifically if needed for future 1692 routing or control protocols. Network administrators MAY use a 1693 Local/Experimental DSCP, any value that contains 11xx11; therefore, 1694 they may use a locally defined service class within their network to 1695 further differentiate their routing and control traffic. 1697 RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets: 1699 o Drop or remark 111xxx packets at ingress to DiffServ network 1700 domain. 1702 o 111xxx marked packets SHOULD NOT be sent across peering points. 1703 Exchange of control information across peering points SHOULD be 1704 done using CS6 DSCP and the Network Control service class. 1706 o any internally defined 11xxx1 values, valid within that network 1707 domain, be remarked to CS6 upon egress at network peering points. 1709 3.2. Network Control Service Class 1711 The Network Control service class is used for transmitting packets 1712 between network devices (routers) that require control (routing) 1713 information to be exchanged between similar devices within the 1714 administrative domain, as well as across a peering point between 1715 adjacent administrative domains. Traffic transmitted in this 1716 service class is very important as it keeps the network operational, 1717 and it needs to be forwarded in a timely manner. 1719 The Network Control service class SHOULD be configured using the 1720 DiffServ CS6 PHB, defined in [RFC2474]. This service class MUST be 1721 configured so that the traffic receives a minimum bandwidth 1722 guarantee, to ensure that the packets always receive timely service. 1723 The configured forwarding resources for Network Control service 1724 class MUST be such that the probability of packet drop under peak 1725 load is very low. The Network Control service class SHOULD be 1726 configured to use a Rate Queuing system such as defined in Section 1727 1.4.1.2 of this document. 1729 The following are examples of protocols and applications that MUST 1730 use the Network Control service class if present in a network: 1732 o Routing packet flows: OSPF, BGP, ISIS, RIP. 1734 o Control information exchange within and between different 1735 administrative domains across a peering point where SLAs are in 1736 place. 1738 o LSP setup using CR-LDP and RSVP-TE. 1740 The following protocols and applications MUST NOT use the Network 1741 Control service class: 1743 o User oriented traffic is not allowed to use this service class. 1745 By user oriented traffic, we mean packet flows that originate 1746 from user-controlled end points that are connected to the 1747 network. 1749 o even if originating from a server or a device acting on behalf 1750 of a user or endpoint, 1752 o even if it is application or in-band signaling to establish a 1753 connection wholly within a single network or across peering 1754 points of/to adjacent networks (e.g., creating a tunnel such 1755 as a VPN, or data path control signaling). 1757 The following are traffic characteristics of packet flows in the 1758 Network Control service class: 1760 o Mostly messages sent between routers and network servers. 1762 o Variable size packets, normally one packet at a time, but traffic 1763 can also burst (BGP, OSPF, etc). 1765 o IGMP, hen is used only for the normal multicast routing purpose. 1767 The REQUIRED DSCP marking is CS6 (Class Selector 6). 1769 RECOMMENDED Network Edge Conditioning: 1771 o At peering points (between two DiffServ networks) where SLAs are 1772 in place, CS6 marked packets MUST be policed, e.g., using a 1773 single rate with burst size (sr+bs) token bucket policer to keep 1774 the CS6 marked packet flows to within the traffic rate specified 1775 in the SLA. 1777 o CS6 marked packet flows from untrusted sources (for example, end 1778 user devices) MUST be dropped or remarked at ingress to the 1779 DiffServ network. What a network admin remarks this user oriented 1780 traffic to if a matter of local policy, and inspection of the 1781 packets can determine which application is used for proper 1782 marking to a more appropriate DSCP, such as from table 3. of this 1783 document. 1785 o Packets from users/subscribers are not permitted access to the 1786 Network Control service classes. 1788 The fundamental service offered to the Network Control service class 1789 is enhanced best-effort service with high bandwidth assurance. 1790 Since this service class is used to forward both elastic and 1791 inelastic flows, the service SHOULD be engineered so that the Active 1792 Queue Management (AQM) [RFC2309] is applied to CS6 marked packets. 1794 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1795 specifies a target queue depth, and the max-threshold specifies the 1796 queue depth above which all traffic is dropped or ECN marked. Thus, 1797 in this service class, the following inequality should hold in queue 1798 configurations: 1800 o min-threshold CS6 < max-threshold CS6 1802 o max-threshold CS6 <= memory assigned to the queue 1804 Note: Many other AQM algorithms exist and are used; they should be 1805 configured to achieve a similar result. 1807 3.3. OAM Service Class 1809 The OAM (Operations, Administration, and Management) service class 1810 is RECOMMENDED for OAM&P (Operations, Administration, and Management 1811 and Provisioning) using protocols such as Simple Network Management 1812 Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet, 1813 and Common Open Policy Service (COPS). Applications using this 1814 service class require a low packet loss but are relatively not 1815 sensitive to delay. This service class is configured to provide 1816 good packet delivery for intermittent flows. 1818 The OAM service class SHOULD use the Class Selector (CS) PHB defined 1819 in [RFC2474]. This service class SHOULD be configured to provide a 1820 minimum bandwidth assurance for CS2 marked packets to ensure that 1821 they get forwarded. The OAM service class SHOULD be configured to 1822 use a Rate Queuing system such as defined in Section 1.4.1.2 of this 1823 document. 1825 The following applications SHOULD use the OAM service class: 1827 o Provisioning and configuration of network elements. 1829 o Performance monitoring of network elements. 1831 o Any network operational alarms. 1833 The following are traffic characteristics: 1835 o Variable size packets. 1837 o Intermittent traffic flows. 1839 o Traffic may burst at times. 1841 o Both elastic and inelastic flows. 1843 o Traffic not sensitive to delays. 1845 RECOMMENDED DSCP marking: 1847 o All flows in this service class are marked with CS2 (Class 1848 Selector 2). 1850 Applications or IP end points SHOULD pre-mark their packets with CS2 1851 DSCP value. If the end point is not capable of setting the DSCP 1852 value, then the router topologically closest to the end point SHOULD 1853 perform Multifield (MF) Classification, as defined in [RFC2475]. 1855 RECOMMENDED conditioning performed at DiffServ network edge: 1857 o Packet flow marking (DSCP setting) from untrusted sources (end 1858 user devices) SHOULD be verified at ingress to DiffServ network 1859 using Multifield (MF) Classification methods, defined in 1860 [RFC2475]. 1862 o Packet flows from untrusted sources (end user devices) SHOULD be 1863 policed at ingress to DiffServ network, e.g., using single rate 1864 with burst size token bucket policer to ensure that the traffic 1865 stays within its negotiated or engineered bounds. 1867 o Packet flows from trusted sources (routers inside administered 1868 network) MAY not require policing. 1870 o Normally OAM&P CS2 marked packet flows are not allowed to flow 1871 across peering points. If that is the case, then CS2 marked 1872 packets SHOULD be policed (dropped) at both egress and ingress 1873 peering interfaces. 1875 The fundamental service offered to "OAM" traffic is enhanced 1876 best-effort service with controlled rate. The service SHOULD be 1877 engineered so that CS2 marked packet flows have sufficient bandwidth 1878 in the network to provide high assurance of delivery. Since this 1879 service class is used to forward both elastic and inelastic flows, 1880 the service SHOULD be engineered so that Active Queue Management 1881 [RFC2309] is applied to CS2 marked packets. 1883 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1884 specifies a target queue depth for each DSCP, and the max-threshold 1885 specifies the queue depth above which all traffic with such a DSCP 1886 is dropped or ECN marked. Thus, in this service class, the 1887 following inequality should hold in queue configurations: 1889 o min-threshold CS2 < max-threshold CS2 1891 o max-threshold CS2 <= memory assigned to the queue 1893 Note: Many other AQM algorithms exist and are used; they should be 1894 configured to achieve a similar result. 1896 4. User Oriented Traffic 1898 User oriented traffic is defined as packet flows between different 1899 users or subscribers, or from servers/nodes on behalf of a user. It 1900 is the traffic that is sent to or from end-terminals and that 1901 supports a very wide variety of applications and services, to 1902 include traffic about a user or application that assists a user 1903 communicate. User oriented traffic can be classified in many 1904 different ways. What we have articulated throughout this document is 1905 a series of non-exhaustive list of categories for classifying user 1906 oriented traffic. We differentiated user oriented traffic that is 1907 real-time versus non-real-time, elastic or rate-adaptive versus 1908 inelastic, sensitive versus insensitive to loss as well as 1909 considering whether the traffic is interactive vs. one way 1910 communication, its responsiveness, whether it requires timely 1911 delivery, and critical verses non-critical. In the final analysis, 1912 we used all of the above for service differentiation, mapping 1913 application types that seemed to have different sets of performance 1914 sensitivities, and requirements to different service classes. 1916 Network administrators can categorize their applications according 1917 to the type of behavior that they require and MAY choose to support 1918 all or a subset of the defined service classes. At the same time, 1919 we include a public facing default DSCP value, with its associated 1920 PHB, that is expected for each traffic type to ensure common or 1921 pervasive performance. Figure 3 provides some common applications 1922 and the forwarding service classes that best support them, based on 1923 their performance requirements. 1925 4.1. Conversational Service Class Group 1927 The Conversational Service Class Group consists of 3 different 1928 service classes, audio, video, and Hi-Res. We are describing the 1929 media sample, or bearer, packets for applications (e.g., RTP from 1930 [RFC3550]) that require bi-directional real-time, very low delay, 1931 very low jitter, and very low packet loss for relatively 1932 constant-rate traffic sources (inelastic traffic sources). It is 1933 RECOMMENDED that RTCP feedback use the same service class and be 1934 marked with the same DSCP as the bearer traffic for that (audio 1935 and/or video) call. This ensures comparable treatment within the 1936 network between endpoints. 1938 The signaling to set-up these bearer flows is part of the 1939 Conversational Signaling service group that will be discussed later 1940 in Section 4. The following 3 subsections will detail what is 1941 expected within each bearer service class. 1943 4.1.1 Audio Service Class 1945 This service class MUST be used for IP Audio service. 1947 The fundamental service offered to traffic in the Audio service 1948 class is minimum jitter, delay, and packet loss service up to a 1949 specified upper bound. There are two PHBs, both EF based, for the 1950 Audio service class: 1952 Nonadmitted Audio traffic - MUST use the EF DSCP [RFC3246], and 1953 is for traffic that has not had any capacity admission 1954 signaling performed for that flow or session. 1956 Capacity-Admitted Audio traffic - MUST use the Voice-Admit DSCP 1957 [RFC5865], and is for traffic that has had any capacity 1958 admission signaling performed for that flow or session, e.g., 1959 RSVP [RFC2205] or NSIS [RFC4080]. 1961 The capacity-admitted Audio traffic operation is similar to an ATM 1962 CBR service, which has guaranteed bandwidth and which, if it stays 1963 within the negotiated rate, experiences nominal delay and no loss. 1965 The nonadmitted Audio traffic, on the other hand, has had no such 1966 explicit guarantee, but has a favorable PHB ensuring high 1967 probability of delivery as well as nominal delay and no loss - 1968 implicitly assuming there is not too much like marked traffic 1969 between users within a flow. 1971 There are two typical scenarios in which audio calls are 1972 established, on the public open Internet using protocols such as 1973 SIP, XMPP or H.323, or in more managed networks like enterprises or 1974 certain service providers which offer a audio service with some 1975 feature benefits and take part in the call signaling. These SPs or 1976 enterprises also use protocols like SIP, XMPP, H.323, but also use 1977 H.248/MEGACO and MGCP. 1979 On the open Internet, typically there is no SP actively involved in 1980 the session set-up of calls, and therefore no servers providing 1981 assistance or features to help one user contact another user. Often, 1982 this traffic is marked or remarked with the DF (i.e., Best Effort) 1983 DSCP. 1985 In more managed networks in which one of more operators have active 1986 servers aiding the audio call set-up, where DiffServ can be used and 1987 preserved to differentiate traffic, networks are offering a service, 1988 therefore need to do some, or a lot of engineering to ensure that 1989 capacity offered to one or more applications does not exceed the 1990 load to the network. Otherwise, the operator will have unhappy 1991 users, at least for that application's usage. This is true for any 1992 application, but is especially true for inelastic applications in 1993 which the application is rigid in its delivery requirements. Audio 1994 bearer traffic is typically such an application, video is another 1995 such application, but we will get to video in the next subsection. 1997 When a user in a managed network has been authorized to send Audio 1998 traffic (i.e., call initiation via the operator's servers was not 1999 rejected), the call admission procedure should have verified that 2000 the newly admitted flow will be within the capacity of the Audio 2001 service class forwarding capability in the network. Capacity 2002 verification is a non-trivial thing, and can either be implicitly 2003 assumed by the call server(s) based on the operator's network 2004 design, or it can be explicitly signaled from an in-data-path 2005 signaling mechanism that verifies the capacity is available now for 2006 this call, for each call made within that network. In the latter 2007 case, those that do not have verifiable network capacity along the 2008 data path are rejected. An in between means method is for call 2009 servers to count calls between two or more endpoints. By 2010 topologically understanding where the caller and called party is and 2011 have configured a known maximum it will allow between the two 2012 locations. This is especially true over WAN links that have far less 2013 capacity than LAN links or core parts of a network. Network 2014 operators will need to understand the topology between any two 2015 callers to ensure the appropriate amount of bandwidth is available 2016 for an expected number of simultaneous audio calls. 2018 Once more than one bandwidth amount can be used for audio calls, for 2019 example - by allowing more than one codec with different bandwidths 2020 per codec for such calls, network engineering becomes more 2021 difficult. Since the inelastic nature of RTP payloads from this 2022 class do not react well to loss or significant delay in any 2023 substantive way, the Audio service class MUST forward packets as 2024 soon as possible. 2026 The Audio service class that does not have capacity admission 2027 performed in the data path MUST use the Expedited Forwarding (EF) 2028 PHB, as defined in [RFC3246], so that all packets are forwarded 2029 quickly. The Audio service class that does have capacity admission 2030 performed in the data path MUST use the Voice-Admit PHB, as defined 2031 in [RFC5865], so that all packets are forwarded quickly. The Audio 2032 service class SHOULD be configured to use a Priority Queuing system 2033 such as that defined in Section 1.4.1.1 of this document. 2035 The following applications SHOULD use the Audio service class: 2037 o VoIP (G.711, G.729, iLBC and other audio codecs). 2039 o Voice-band data over IP (modem, fax). 2041 o T.38 fax over IP. 2043 o Circuit emulation over IP, virtual wire, etc. 2045 o IP Virtual Private Network (VPN) service that specifies 2046 single-rate, mean network delay that is slightly longer then 2047 network propagation delay, very low jitter, and a very low packet 2048 loss. 2050 The following are traffic characteristics: 2052 o Mostly fixed-size packets for VoIP (30, 60, 70, 120 or 200 bytes 2053 in size). 2055 o Packets emitted at constant time intervals. 2057 o Admission control of new flows is provided by Audio call server, 2058 media gateway, gatekeeper, edge router, end terminal, access node 2059 or in-data-path signaling that provides flow admission control 2060 function. 2062 Applications or IP end points SHOULD pre-mark their packets with EF 2063 or Voice-Admit DSCP value, whichever is appropriate. If the end 2064 point is not capable of setting the DSCP value, then the router 2065 topologically closest to the end point SHOULD perform Multifield 2066 (MF) Classification, as defined in [RFC2475]. 2068 The RECOMMENDED DSCP marking is EF for nonadmitted audio flows, and 2069 Voice-Admit for capacity-admitted flows for the following 2070 applications: 2072 o VoIP (G.711, G.729 and other codecs). 2074 o Voice-band data over IP (modem and fax). 2076 o T.38 fax over IP. 2078 o Circuit emulation over IP, virtual wire, etc. 2080 RECOMMENDED Network Edge Conditioning: 2082 o Packet flow marking (DSCP setting) from untrusted sources (end 2083 user devices) SHOULD be verified at ingress to DiffServ network 2084 using Multifield (MF) Classification methods, defined in 2085 [RFC2475]. If untrusted, the network edge SHOULD know if 2086 capacity-admission has been applied, since the edge router will 2087 have taken part in the admission signaling; therefore will know 2088 whether EF or Voice-Admit is the proper marking for that flow. 2090 o Packet flows from untrusted sources (end user devices) SHOULD be 2091 policed at ingress to DiffServ network, e.g., using single rate 2092 with burst size token bucket policer to ensure that the Audio 2093 traffic stays within its negotiated bounds. 2095 o Policing is OPTIONAL for packet flows from trusted sources whose 2096 behavior is ensured via other means (e.g., administrative 2097 controls on those systems). 2099 o Policing of Audio packet flows across peering points where SLA is 2100 in place is OPTIONAL as Audio traffic will be controlled by 2101 admission control mechanism between peering points. 2103 The fundamental service offered to "Audio" traffic is enhanced 2104 best-effort service with controlled rate, very low delay, and very 2105 low loss. The service MUST be engineered so that EF marked packet 2106 flows have sufficient bandwidth in the network to provide guaranteed 2107 delivery. Otherwise, the service will have in place an explicit 2108 capacity-admission signaling protocol such as RSVP or NSIS and thus 2109 mark the packets within the flow as Voice-Admit. Normally traffic in 2110 this service class does not respond dynamically to packet loss. As 2111 such, Active Queue Management [RFC2309] SHOULD NOT be applied to EF 2112 marked packet flows. 2114 4.1.2 Video Service Class 2116 The Video service class is for bidirectional applications that 2117 require real-time service for both constant and rate-adaptive 2118 traffic. SIP and H.323/V2 (and later) versions of video 2119 conferencing equipment with constant and dynamic bandwidth 2120 adjustment are such applications. The traffic sources in this 2121 service class either have a fixed bandwidth requirement (e.g., 2122 MPEG2, etc.), or have the ability to dynamically change their 2123 transmission rate (e.g., MPEG4/H.264, etc.) based on feedback from 2124 the receiver. This feedback SHOULD be accomplished using RTCP 2125 [RFC3550]. One approach for this downspeeding has the receiver 2126 detect packet loss, thus signaling in an RTCP message to the source 2127 the indication of lost (or delayed or out of order) packets in 2128 transit. When necessary the source then selects a lower rate 2129 encoding codec. When available, the source merely sends less data, 2130 resulting in lower resolution of the same visual display. 2132 The Video service class is not for video downloads, webcasts, or 2133 single directional video or audio/video traffic of any kind. It is 2134 for human-to-human visual interaction between two users, or more if 2135 an MTP is used. 2137 Typical video conferencing configurations negotiate the setup of 2138 audio/video session using protocols such as SIP and H.323. Just as 2139 with networks that have audio traversing them, video typically 2140 traverses the same two types of networks: the open big "I" Internet, 2141 in which most every type of traffic is best effort (DF), or on a 2142 more managed network such as an enterprise or SP's managed network 2143 in which servers within either network take part in the call 2144 signaling, thereby offering the video service. 2146 When a user in a managed network has been authorized to send video 2147 traffic (i.e., call initiation via the operator's servers was not 2148 rejected), the call admission procedure should have verified that 2149 the newly admitted flow will be within the capacity of the video 2150 service class forwarding capability in the network. Capacity 2151 verification is a non-trivial thing, and can either be implicitly 2152 assumed by the call server(s) based on the operator's network 2153 design, or it can be explicitly signaled from an in-data-path 2154 signaling mechanism that verifies the capacity is available now for 2155 this call, for each call made within that network. In the latter 2156 case, those that do not have verifiable network capacity along the 2157 data path are rejected. An in between means method is for call 2158 servers to count calls between two or more endpoints. By 2159 topologically understanding where the caller and called party is and 2160 have configured a known maximum it will allow between the two 2161 locations. Video is larger in bandwidth than audio, and the 2162 difference can be significant. For example, for a single G.711 audio 2163 call that is 80kbps, an associated video bandwidth for the same 2164 call can easily be 4Mbps. This is especially true over WAN links 2165 that have far less capacity than LAN links or core parts of a 2166 network. Network operators will need to understand the topology 2167 between any two callers to ensure the appropriate amount of 2168 bandwidth is available for an expected number of simultaneous video 2169 and/or audio/video calls. 2171 Note that it is OPTIONALLY the case in these networks that the 2172 accompanying audio for the video call will be marked as the video is 2173 marked (i.e., using the same DSCP), but not always. One reason this 2174 has been done is for lip-sync. 2176 The Video service class MUST use the Assured Forwarding (AF) PHB, 2177 defined in [RFC2597]. This service class MUST be configured to 2178 provide a bandwidth assurance for AF41, AF42, and AF43 marked 2179 packets to ensure that they get forwarded. The Video service class 2180 SHOULD be configured to use a Rate Queuing system for AF42 and AF43 2181 traffic flows, such as that defined in Section 1.4.1.2 of this 2182 document. However, AF41 MUST be designated as the DSCP for use when 2183 capacity-admission signaling has been used, such as RSVP or NSIS, to 2184 guarantee delivery through the network. AF42 and AF43 will be used 2185 for non-admitted video calls, as well as overflows from AF41 sources 2186 that send more packets than they have negotiated bandwidth for that 2187 call. 2189 The following applications MUST use the Video service class: 2191 o SIP and H.323/V2 (and later) versions of video conferencing 2192 applications (interactive video). 2194 o Video conferencing applications with rate control or traffic 2195 content importance marking. 2197 o Interactive, time-critical, and mission-critical applications. 2199 NOTE with regards to the above bullet: this usage SHOULD be 2200 minimized, else the video traffic will suffer - unless this 2201 is engineered into the topology. 2203 The following are traffic characteristics: 2205 o Variable size packets (i.e., small to large in size). 2207 o The higher the resolution or change rate between each image, the 2208 higher the duration of large packets. 2210 o Usually constant inter-packet time interval. 2212 o Can be Variable rate in transmission. 2214 o Source is capable of reducing its transmission rate based on 2215 being told receiver is detecting packet loss (e.g., via RTCP). 2217 Applications or IP end points SHOULD pre-mark their packets with 2218 DSCP values as shown below. If the end point is not capable of 2219 setting the DSCP value, then the router topologically closest to the 2220 end point SHOULD perform Multifield (MF) Classification, as defined 2221 in [RFC2475] and mark all packets as AF4x. Note: In this case, the 2222 two-rate, three-color marker will be configured to operate in 2223 Color-Blind mode. 2225 Mandatory DSCP marking when performed by router closest to source: 2227 o AF41 = up to specified rate "A", which is dedicated to non-Hi-Res 2228 capacity-admitted video traffic. 2230 Note the audio of an A/V call can be marked AF41 as well. 2232 o AF42 = all non-Hi-Res video traffic marked AF41 in excess of 2233 specified rate "A", or new non-admitted video traffic but 2234 below specified rate "B". 2236 o AF43 = in excess of specified rate "B". 2238 o Where "A" < "B". 2240 Note: One might expect "A" to approximate the peak rates of sum of 2241 all admitted video flows, plus the sum of the mean rates and 2242 "B" to approximate the sum of the peak rates of those same two 2243 flows. 2245 Mandatory DSCP marking when performed by SIP or H.323/V2 2246 videoconferencing equipment: 2248 o AF41 = SIP or H.323 video conferencing audio stream RTP. 2250 o AF41 = SIP or H.323 video conferencing video control RTCP. 2252 o AF41 = SIP or H.323 video conferencing video stream up to 2253 specified rate "A". 2255 o AF42 = SIP or H.323 video conferencing video stream in excess of 2256 specified rate "A" but below specified rate "B". 2258 o AF42 = SIP or H.323 video conferencing video control RTCP, for 2259 those video streams that were generated using AF42. 2261 o AF43 = SIP or H.323 video conferencing video stream in excess of 2262 specified rate "B". 2264 o AF43 = SIP or H.323 video conferencing video control RTCP, for 2265 those video streams that were generated using AF43. 2267 o Where "A" < "B". 2269 Mandatory conditioning performed at DiffServ network edge: 2271 o The two-rate, three-color marker SHOULD be configured to provide 2272 the behavior as defined in trTCM [RFC2698]. 2274 o If packets are marked by trusted sources or a previously trusted 2275 DiffServ domain and the color marking is to be preserved, then 2276 the two-rate, three-color marker SHOULD be configured to operate 2277 in Color-Aware mode. 2279 o If the packet marking is not trusted or the color marking is not 2280 to be preserved, then the two-rate, three-color marker SHOULD be 2281 configured to operate in Color-Blind mode. 2283 The fundamental service offered to nonadmitted "Video" traffic is 2284 enhanced best-effort service with controlled rate and delay. The 2285 fundamental service offered to capacity-admitted "Video" traffic is 2286 a guaranteed service using in-data-path signaling to ensure expected 2287 delivery in a timely manner. For a non-admitted video conferencing 2288 service, if a 1% packet loss detected at the receiver triggers an 2289 encoding rate change, thus dropping to the next lower provisioned 2290 video encoding rate then Active Queue Management [RFC2309] SHOULD be 2291 used primarily to switch the video encoding rate under congestion, 2292 changing from high rate to lower rate, i.e., 1472 kbps to 768 kbps. 2293 This rule applies to all AF42 and 43 flows. The probability of loss 2294 of AF41 traffic MUST NOT exceed the probability of loss of AF42 2295 traffic, which in turn MUST NOT exceed the probability of loss of 2296 AF43 traffic. 2298 Capacity-admitted video service should not result in packet loss. 2299 However, administratively this MAY be allowed to cause a purposeful 2300 downspeeding event (i.e., a change in resolution or a change in 2301 codec) to occur due to congestion. 2303 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2304 specifies a target queue depth for each DSCP, and the max-threshold 2305 specifies the queue depth above which all traffic with such a DSCP 2306 is dropped or ECN marked. Thus, in this service class, the 2307 following inequality should hold in queue configurations: 2309 o min-threshold AF43 < max-threshold AF43 2311 o max-threshold AF43 <= min-threshold AF42 2313 o min-threshold AF42 < max-threshold AF42 2315 o max-threshold AF42 <= min-threshold AF41 2316 o min-threshold AF41 < max-threshold AF41 2318 o max-threshold AF41 <= memory assigned to the queue 2320 Note: This configuration tends to drop AF43 traffic before AF42 and 2321 AF42 before AF41. Many other AQM algorithms exist and are 2322 used; they should be configured to achieve a similar result. 2324 4.1.3 Hi-Res Service Class 2326 The Hi-Res service class is for higher end (i.e., deemed 'more 2327 important') bidirectional applications that require real-time 2328 service for both constant and rate-adaptive traffic. There are two 2329 PHBs, both EF based, for the Hi-Res video conferencing service 2330 class: 2332 Nonadmitted Hi-Res traffic - MUST use the CS4 DSCP [RFC2474], and 2333 is for traffic that has not had any capacity admission 2334 signaling performed for that flow or session. 2336 Capacity-Admitted Hi-Res traffic - MUST use the CS4-Admit DSCP 2337 [ID-DSCP], and is for traffic that has had any capacity 2338 admission signaling performed for that flow or session, e.g., 2339 RSVP [RFC2205] or NSIS [RFC4080]. 2341 The capacity-admitted Hi-Res video conferencing traffic operation is 2342 similar to an ATM CBR service, which has guaranteed bandwidth and 2343 which, if it stays within the negotiated rate, experiences nominal 2344 delay and no loss. 2346 SIP and H.323/V2 (and later) versions of video conferencing 2347 equipment with constant and dynamic bandwidth adjustment are such 2348 applications. The traffic sources in this service class either have 2349 a fixed bandwidth requirement (e.g., MPEG2), or have the ability to 2350 dynamically change their transmission rate (e.g., MPEG4/H.264) based 2351 on feedback from the receiver. This feedback SHOULD be accomplished 2352 using RTCP [RFC3550]. One approach for this downspeeding has the 2353 receiver detect packet loss, thus signaling in an RTCP message to 2354 the source the indication of lost (or delayed or out of order) 2355 packets in transit. When necessary the source then selects a lower 2356 rate encoding codec. When available, the source merely sends less 2357 data, resulting in lower resolution of the same visual display. 2359 The Hi-Res service class, as with the Video service class, is not 2360 for video downloads, webcasts, or single directional video or 2361 audio/video traffic of any kind. It is for human-to-human visual 2362 interaction between two users, or more if an video conference bridge 2363 is used. 2365 Typical Hi-Res video conferencing configurations negotiate the setup 2366 of audio/video session using protocols such as SIP and H.323. 2367 Hi-Res video conferencing is generally not over the big "I" 2368 Internet, rather nearly exclusively over more managed networks such 2369 as an enterprise or special purpose SP's managed network in which 2370 servers within either network take part in the call signaling, 2371 thereby offering the video service. In addition, typically this type 2372 of audio/video service has high business expectations for minimized 2373 packet loss, pixilation or other issues with the audio/video 2374 experience. In the recent past, entire T3s have been dedicated to a 2375 signal Hi-Res call; sometimes one T3 per site of a multi-site video 2376 conference. 2378 Hi-Res video conferencing often has larger in bandwidth than the 2379 typical video call. The audio portion can be increased as well, as 2380 stereo capabilities are often necessary to provide an in-room 2381 experience from a distance. The difference can be significant (or 2382 another step up from just a typical video service). For example, for 2383 a single G.711 audio call that is 80kbps, a Hi-Res conference 2384 usually runs G.722 wideband audio at 256kbps. Typical video delivery 2385 is up to 4Mbps, whereas a Hi-Res conference can have three 2386 1080p/30fps widescreen displays requiring at least 12Mbps, with a 2387 burst capability of much more. 2389 If there were no congestion on the wire, the expected treatment 2390 between a video service and a Hi-Res conference would be the same. 2391 However, it is typically the case that the Hi-Res conferencing flows 2392 have more rigid requirements for quality and business-wise, need to 2393 be experience far less errors than the regular video service on the 2394 same network. 2396 Note that it is likely the case in these networks that the 2397 accompanying audio to the Hi-Res video call will be marked as the 2398 Hi-Res video is marked (i.e., using the same DSCP. 2400 The Hi-Res service class MUST use the Class Selector 5 (CS4) PHB, 2401 defined in [RFC2474], for non-capacity-admitted conferences. While 2402 the capacity-admitted Hi-Res conferences MUST use the CS4-Admit PHB, 2403 defined in [ID-DSCP]. This service class MUST be configured to 2404 provide a bandwidth assurance for CS4 and CS4-Admit marked packets 2405 to ensure that they get forwarded. The Hi-Res service class SHOULD 2406 be configured to use a Priority Queuing system such as that defined 2407 in Section 1.4.1.1 of this document. Further, CS4-Admit will be 2408 designated as the DSCP for use when capacity-admission signaling has 2409 been used, such as RSVP or NSIS, to guarantee delivery through the 2410 network. CS4 will be used for non-admitted Hi-Res conferences, as 2411 well as overflows from CS4-Admit sources that send more packets than 2412 they have negotiated bandwidth for that call. 2414 The following applications MUST use the Hi-Res service class: 2416 o SIP and H.323/V2 (and later) versions of Hi-Res video 2417 conferencing applications (interactive Hi-Res video). 2419 o Video conferencing applications with rate control or traffic 2420 content importance marking. 2422 The following are traffic characteristics: 2424 o Variable size packets. 2426 o The higher the resolution or change rate between each image, the 2427 higher the duration of large packets. 2429 o Usually constant inter-packet time interval. 2431 o Can be Variable rate in transmission. 2433 o Source is capable of reducing its transmission rate based on 2434 being told receiver is detecting packet loss. 2436 Applications or IP end points SHOULD pre-mark their packets with 2437 DSCP values as shown below. If the end point is not capable of 2438 setting the DSCP value, then the router topologically closest to the 2439 end point SHOULD perform Multifield (MF) Classification, as defined 2440 in [RFC2475] and mark all packets as AF4x. 2442 Mandatory DSCP marking when performed by router closest to source: 2444 o CS4-Admit = up to specified rate "A", which is dedicated to 2445 capacity-admitted Hi-Res traffic. 2447 Note the audio of an A/V call can be marked CS4-Admit as well. 2449 o CS4 = all video traffic marked CS4-Admit in excess of specified 2450 rate "A", or new non-admitted video traffic but below 2451 specified rate "B". 2453 o Where "A" < "B". 2455 Note: One might expect "A" to approximate the peak rates of sum of 2456 all admitted video flows, plus the sum of the mean rates and 2457 "B" to approximate the sum of the peak rates of those same two 2458 flows. 2460 Mandatory DSCP marking when performed by SIP or H.323/V2 2461 videoconferencing equipment: 2463 o CS4-Admit = SIP or H.323 video conferencing audio stream RTP/UDP. 2465 o CS4-Admit = SIP or H.323 video conferencing video control 2466 RTCP/TCP. 2468 o CS4-Admit = SIP or H.323 video conferencing video stream up to 2469 specified rate "A". 2471 o CS4 = SIP or H.323 video conferencing video stream in excess of 2472 specified rate "A" but below specified rate "B". 2474 o Where "A" < "B". 2476 Mandatory conditioning performed at DiffServ network edge: 2478 o The two-rate, three-color marker SHOULD be configured to provide 2479 the behavior as defined in trTCM [RFC2698]. 2481 o If packets are marked by trusted sources or a previously trusted 2482 DiffServ domain and the color marking is to be preserved, then 2483 the two-rate, three-color marker SHOULD be configured to operate 2484 in Color-Aware mode. 2486 o If the packet marking is not trusted or the color marking is not 2487 to be preserved, then the two-rate, three-color marker SHOULD be 2488 configured to operate in Color-Blind mode. 2490 The fundamental service offered to nonadmitted "Hi-Res" traffic is 2491 enhanced best-effort service with controlled rate and delay. The 2492 fundamental service offered to capacity-admitted "Hi-Res" traffic is 2493 a guaranteed service using in-data-path signaling to ensure expected 2494 or timely delivery. Capacity-admitted video service SHOULD NOT 2495 result in packet loss. However, administratively this MAY be allowed 2496 to cause a purposeful downspeeding event (i.e., a change in 2497 resolution or a change in codec) to occur. 2499 4.2. Realtime-Interactive Service Class 2501 The Realtime-Interactive service class is for bidirectional 2502 applications that require low loss and jitter and very low delay for 2503 constant or variable rate inelastic traffic sources. Interactive 2504 gaming applications that do not have the ability to change encoding 2505 rates or to mark packets with different importance indications is 2506 one good example of such an application. Another set of 2507 applications is virtualized desktop applications in which a remote 2508 user has a keyboard, mouse and display monitor, but the desktop is 2509 virtualized with the memory/processor/applications back in a common 2510 data center, requiring near instantaneous feedback on the user's 2511 monitor of any changes caused by the application or an action by the 2512 user. Rich media protocols for voice and video MUST NOT use the 2513 Realtime-Interactive service class, but rather the appropriate 2514 service class from the Conversational service group discussed early 2515 in Section 4.1. 2517 The Realtime-Interactive service class will use two PHBs: 2519 Nonadmitted Realtime-Interactive traffic - MUST use the CS5 DSCP 2520 [RFC2474], and is for traffic that has not had any capacity 2521 admission signaling performed for that flow or session. 2523 Capacity-Admitted Realtime-Interactive traffic - MUST use the 2524 CS5-Admit DSCP [ID-DSCP], and is for traffic that has had any 2525 capacity admission signaling performed for that flow or 2526 session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. 2528 The capacity-admitted Realtime-Interactive traffic operation is 2529 similar to an ATM CBR service, which has guaranteed bandwidth and 2530 which, if it stays within the negotiated rate, experiences nominal 2531 delay and no loss. 2533 Either of the above service classes can be configured as EF based by 2534 using a relaxed performance parameter and a rate scheduler. 2536 When a user/endpoint has been authorized to start a new session 2537 (i.e., joins a networked game or logs onto a virtualized 2538 workstation), the admission procedure should have verified that the 2539 newly admitted data rates will be within the engineered capacity of 2540 the Realtime-Interactive service class. The bandwidth in the core 2541 network and the number of simultaneous Realtime-Interactive sessions 2542 that can be supported SHOULD be engineered to control traffic load 2543 for this service. 2545 This service class SHOULD be configured to provide a high assurance 2546 for bandwidth for CS5 PHB, defined in [RFC2474], or CS5-Admit 2547 [ID-DSCP] for guaranteed service through a capacity-admission 2548 signaling protocol. The Realtime-Interactive service class SHOULD be 2549 configured to use a Rate Queuing system such as that defined in 2550 Section 1.4.1.2 of this document. Note that either 2551 Realtime-Interactive PHB MAY be configured as another EF PHB, 2552 specifically CS5-Admit, that uses a relaxed performance parameter 2553 and a rate scheduler, in the priority queue as defined in Section 2554 1.4.1.1 of this document. 2556 The following applications MUST use the Realtime-Interactive service 2557 class: 2559 o Interactive gaming and control. 2561 o Remote Desktop applications 2563 o Virtualized Desktop applications. 2565 o Application server-to-application server non-bursty data transfer 2566 requiring very low delay. 2568 o Inelastic, interactive, time-critical, and mission-critical 2569 applications requiring very low delay. 2571 The following are traffic characteristics: 2573 o Variable size packets. 2575 o Variable rate, though sometimes bursty, which will require 2576 engineering of the network to accommodate. 2578 o Application is sensitive to delay variation between flows and 2579 sessions. 2581 o Lost packets, if any, are usually ignored by application. 2583 RECOMMENDED DSCP marking: 2585 o All non-admitted flows in this service class are marked with CS5 2586 (Class Selector 5). 2588 o All capacity-admitted flows in this service class are marked with 2589 CS5-Admit. 2591 Applications or IP end points SHOULD pre-mark their packets with CS5 2592 or CS5-Admit DSCP value, depending on whether a capacity-admission 2593 signaling protocol is used for a flow. If the end point is not 2594 capable of setting the DSCP value, then the router topologically 2595 closest to the end point SHOULD perform Multifield (MF) 2596 Classification, as defined in [RFC2475]. 2598 RECOMMENDED conditioning performed at DiffServ network edge: 2600 o Packet flow marking (DSCP setting) from untrusted sources (end 2601 user devices) SHOULD be verified at ingress to DiffServ network 2602 using Multifield (MF) Classification methods defined in 2603 [RFC2475]. 2605 o Packet flows from untrusted sources (end user devices) SHOULD be 2606 policed at ingress to DiffServ network, e.g., using single rate 2607 with burst size token bucket policer to ensure that the traffic 2608 stays within its negotiated or engineered bounds. 2610 o Packet flows from trusted sources (application servers inside 2611 administered network) MAY not require policing. 2613 o Policing of packet flows across peering points MUST adhere to the 2614 Service Level Agreement (SLA). 2616 The fundamental service offered to nonadmitted 2617 "Realtime-Interactive" traffic is enhanced best-effort service with 2618 controlled rate and delay. The fundamental service offered to 2619 capacity-admitted "Realtime-Interactive" traffic is a guaranteed 2620 service using in-data-path signaling to ensure expected or timely 2621 delivery. Capacity-admitted Realtime-Interactive service SHOULD NOT 2622 result in packet loss. The service SHOULD be engineered so that CS5 2623 marked packet flows have sufficient bandwidth in the network to 2624 provide high assurance of delivery. Normally, traffic in this 2625 service class does not respond dynamically to packet loss. As such, 2626 Active Queue Management [RFC2309] SHOULD NOT be applied to CS5 2627 marked packet flows. 2629 4.3. Multimedia Conferencing Service Class 2631 The Multimedia Conferencing service class is for applications that 2632 have a low to medium tolerance to delay, and are rate adaptive to 2633 lost packets in transit from sources. Presentation Data 2634 applications that are operational in conjunction with an audio/video 2635 conference is one good example of such an application. Another set 2636 of applications is application sharing or whiteboarding 2637 applications, also in conjunction to an A/V conference. In either 2638 case, the audio & video part of the flow MUST NOT use the Multimedia 2639 Conferencing service class, rather the more appropriate service 2640 class within the Conversational service group discussed earlier in 2641 Section 4.1. 2643 The Multimedia Conferencing service class will use two PHBs: 2645 Nonadmitted Multimedia Conferencing traffic - MUST use the (new) 2646 MC DSCP [ID-DSCP], and is for traffic that has not had any 2647 capacity admission signaling performed for that flow or 2648 session. 2650 Capacity-Admitted Multimedia Conferencing traffic - MUST use the 2651 (new) MC-Admit DSCP [ID-DSCP], and is for traffic that has 2652 had any capacity admission signaling performed for that flow 2653 or session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. 2655 The capacity-admitted Multimedia Conferencing traffic operation is 2656 similar to an ATM CBR service, which has guaranteed bandwidth and 2657 which, if it stays within the negotiated rate, experiences nominal 2658 delay and no loss. 2660 When a user/endpoint initiates a presentation data, application 2661 sharing or whiteboarding session, it will typically be part of an 2662 audio or audio/video conference such as web-conferencing or an 2663 existing Telepresence call. The authorization procedure SHOULD be 2664 controlled through the coordinated effort to bind the A/V call with 2665 the correct Multimedia Conferencing packet flow through some use of 2666 identifiers not in scope of this document. The managed network this 2667 flow traverse and the number of simultaneous Multimedia 2668 Conferencing sessions that can be supported SHOULD be engineered to 2669 control traffic load for this service. 2671 The non-capacity admitted Multimedia Conferencing service class 2672 SHOULD use the new MC PHB, defined in [ID-DSCP]. This service class 2673 SHOULD be configured to provide a high assurance for bandwidth for 2674 CS5 marked packets to ensure that they get forwarded. The 2675 Multimedia Conferencing service class SHOULD be configured to use a 2676 Rate Queuing system such as that defined in Section 1.4.1.2 of this 2677 document. Note that this service class MAY be configured as another 2678 EF PHB that uses a relaxed performance parameter, a rate scheduler, 2679 and MC-Admit DSCP value, which MUST use the priority queue as 2680 defined in Section 1.4.1.1 of this document. 2682 The following applications MUST use the Multimedia Conferencing 2683 service class: 2685 o Presentation Data applications, which can utilize vector 2686 graphics, raster graphics or video delivery. 2688 o Virtualized Desktop applications. 2690 o Application server-to-application server non-bursty data transfer 2691 requiring very low delay. 2693 The following are traffic characteristics: 2695 o Variable size packets. 2697 o Variable rate, though sometimes bursty, which will require 2698 engineering of the network to accommodate. 2700 o Application is sensitive to delay variation between flows and 2701 sessions. 2703 o Lost packets, if any, can be ignored by the application. 2705 RECOMMENDED DSCP marking: 2707 o All non-admitted flows in this service class are marked with the 2708 new MC DSCP. 2710 o All capacity-admitted flows in this service class are marked with 2711 MC-Admit. 2713 Applications or IP end points SHOULD pre-mark their packets with the 2714 MC DSCP value. If the end point is not capable of setting the DSCP 2715 value, then the router topologically closest to the end point SHOULD 2716 perform Multifield (MF) Classification, as defined in [RFC2475]. 2718 RECOMMENDED conditioning performed at DiffServ network edge: 2720 o Packet flow marking (DSCP setting) from untrusted sources (end 2721 user devices) SHOULD be verified at ingress to DiffServ network 2722 using Multifield (MF) Classification methods defined in 2723 [RFC2475]. 2725 o Packet flows from untrusted sources (end user devices) SHOULD be 2726 policed at ingress to DiffServ network, e.g., using single rate 2727 with burst size token bucket policer to ensure that the traffic 2728 stays within its negotiated or engineered bounds. 2730 o Packet flows from trusted sources (application servers inside 2731 administered network) MAY not require policing. 2733 o Policing of packet flows across peering points MUST adhere to the 2734 Service Level Agreement (SLA). 2736 The fundamental service offered to nonadmitted "Multimedia 2737 Conferencing" traffic is enhanced best-effort service with 2738 controlled rate and delay. The fundamental service offered to 2739 capacity-admitted "Multimedia Conferencing" traffic is a guaranteed 2740 service using in-data-path signaling to ensure expected or timely 2741 delivery. Capacity-admitted Multimedia Conferencing service SHOULD 2742 NOT result in packet loss. The service SHOULD be engineered so that 2743 Multimedia Conferencing marked packet flows have sufficient 2744 bandwidth in the network to provide high assurance of delivery. 2745 Normally, traffic in this service class does not respond dynamically 2746 to packet loss. As such, Active Queue Management [RFC2309] SHOULD 2747 NOT be applied to MC or MC-Admit marked packet flows. 2749 4.4. Multimedia Streaming Service Class 2751 The Multimedia Streaming service class is RECOMMENDED for 2752 applications that require near-real-time packet forwarding of 2753 variable rate elastic traffic sources that are not as delay 2754 sensitive as applications using the Broadcast service class. Such 2755 applications include streaming audio and video, some video (movies) 2756 on-demand applications, and non-interactive webcasts. In general, 2757 the Multimedia Streaming service class assumes that the traffic is 2758 buffered at the source/destination; therefore, it is less sensitive 2759 to delay and jitter. 2761 The Multimedia Streaming service class MUST use the Assured 2762 Forwarding (AF3x) PHB, defined in [RFC2597]. This service class 2763 MUST be configured to provide a minimum bandwidth assurance for 2764 AF31, AF32, and AF33 marked packets to ensure that they get 2765 forwarded. The Multimedia Streaming service class SHOULD be 2766 configured to use Rate Queuing system for AF32 and AF33 traffic 2767 flows, such as that defined in Section 1.4.1.2 of this document. 2768 However, AF31 MUST be designated as the DSCP for use when 2769 capacity-admission signaling has been used, such as RSVP or NSIS, to 2770 guarantee delivery through the network. AF32 and AF33 will be used 2771 for non-admitted streaming flows, as well as overflows from AF31 2772 sources that send more packets than they have negotiated bandwidth 2773 for that call. 2775 The following applications SHOULD use the Multimedia Streaming 2776 service class: 2778 o Buffered streaming audio (unicast). 2780 o Buffered streaming video (unicast). 2782 o Non-interactive Webcasts. 2784 o IP VPN service that specifies two rates and is less sensitive to 2785 delay and jitter. 2787 The following are traffic characteristics: 2789 o Variable size packets. 2791 o The higher the rate, the higher the density of large packets. 2793 o Variable rate. 2795 o Elastic flows. 2797 o Some bursting at start of flow from some applications, as well as 2798 an expected stepping up and down on the rate of the flow based on 2799 changes in resolution due to network conditions. 2801 Applications or IP end points SHOULD pre-mark their packets with 2802 DSCP values as shown below. If the end point is not capable of 2803 setting the DSCP value, then the router topologically closest to the 2804 end point SHOULD perform Multifield (MF) Classification, as defined 2805 in [RFC2475], and mark all packets as AF3x. Note: In this case, 2806 the two-rate, three-color marker will be configured to operate in 2807 Color-Blind mode. 2809 RECOMMENDED DSCP marking: 2811 o AF31 = up to specified rate "A". 2813 o AF32 = all traffic marked AF31 in excess of specified rate "A", 2814 or new AF32 traffic but below specified rate "B". 2816 o AF33 = in excess of specified rate "B". 2818 o Where "A" < "B". 2820 Note: One might expect "A" to approximate the peak rates of sum of 2821 all streaming flows, plus the sum of the mean rates and "B" to 2822 approximate the sum of the peak rates of those same two flows. 2824 RECOMMENDED conditioning performed at DiffServ network edge: 2826 o The two-rate, three-color marker SHOULD be configured to provide 2827 the behavior as defined in trTCM [RFC2698]. 2829 o If packets are marked by trusted sources or a previously trusted 2830 DiffServ domain and the color marking is to be preserved, then 2831 the two-rate, three-color marker SHOULD be configured to operate 2832 in Color-Aware mode. 2834 o If the packet marking is not trusted or the color marking is not 2835 to be preserved, then the two-rate, three-color marker SHOULD be 2836 configured to operate in Color-Blind mode. 2838 The fundamental service offered to nonadmitted "Multimedia 2839 Streaming" traffic is enhanced best-effort service with controlled 2840 rate and delay. The fundamental service offered to 2841 capacity-admitted "Multimedia Streaming" traffic is a guaranteed 2842 service using in-data-path signaling to ensure expected delivery in 2843 a reasonable manner. The service SHOULD be engineered so that AF31 2844 marked packet flows have sufficient bandwidth in the network to 2845 provide high assurance of delivery. Since the AF3x traffic is 2846 elastic and responds dynamically to packet loss, Active Queue 2847 Management [RFC2309] SHOULD be used primarily to reduce forwarding 2848 rate to the minimum assured rate at congestion points, unless AF31 2849 has had a capacity-admission signaling protocol applied to the flow, 2850 such as RSVP or NSIS. 2852 If a capacity-admission signaling protocol applied to the AF31 flow, 2853 which SHOULD be the case always, the AF31 PHB MAY be configured as 2854 another EF PHB that uses a relaxed performance parameter and a rate 2855 scheduler, in the priority queue as defined in Section 1.4.1.1 of 2856 this document. 2858 The probability of loss of AF31 traffic MUST NOT exceed the 2859 probability of loss of AF32 traffic, which in turn MUST NOT exceed 2860 the probability of loss of AF33. 2862 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2863 specifies a target queue depth for each DSCP, and the max-threshold 2864 specifies the queue depth above which all traffic with such a DSCP 2865 is dropped or ECN marked. Thus, in this service class, the 2866 following inequality MUST hold in queue configurations: 2868 o min-threshold AF33 < max-threshold AF33 2870 o max-threshold AF33 <= min-threshold AF32 2872 o min-threshold AF32 < max-threshold AF32 2874 o max-threshold AF32 <= min-threshold AF31 2876 o min-threshold AF31 < max-threshold AF31 2878 o max-threshold AF31 <= memory assigned to the queue 2880 Note#1: this confirmation MUST be modified if AF31 has a 2881 capacity-admission signaling protocol applied to those 2882 flows, and the above will only apply to AF32 and AF33, while 2883 AF31 (theoretically) has no packet loss. 2885 Note#2: This configuration tends to drop AF33 traffic before AF32 2886 and AF32 before AF31. Note: Many other AQM algorithms exist 2887 and are used; they SHOULD be configured to achieve a similar 2888 result. 2890 4.5. Broadcast Service Class 2892 The Broadcast service class is RECOMMENDED for applications that 2893 require near-real-time packet forwarding with very low packet loss 2894 of constant rate and variable rate inelastic traffic sources that 2895 are more delay sensitive than applications using the Multimedia 2896 Streaming service class. Such applications include broadcast TV, 2897 streaming of live audio and video events, some video-on-demand 2898 applications, and video surveillance. In general, the Broadcast 2899 service class assumes that the destination end point has a dejitter 2900 buffer, for video application usually a 2 - 8 video-frame buffer (66 2901 to several hundred of milliseconds), thus expecting far less 2902 buffering before play-out than Multimedia Streaming, which can 2903 buffer in the seconds to minutes (to hours). 2905 The Broadcast service class will use two PHBs: 2907 Nonadmitted Broadcast traffic - MUST use the CS3 DSCP [RFC2474], 2908 and is for traffic that has not had any capacity admission 2909 signaling performed for that flow or session. 2911 Capacity-Admitted Broadcast traffic - MUST use the CS3-Admit DSCP 2912 [ID-DSCP], and is for traffic that has had any capacity 2913 admission signaling performed for that flow or session, e.g., 2914 RSVP [RFC2205] or NSIS [RFC4080]. 2916 The capacity-admitted Broadcast traffic operation is similar to an 2917 ATM CBR service, which has guaranteed bandwidth and which, if it 2918 stays within the negotiated rate, experiences nominal delay and no 2919 loss. 2921 Either of the above service classes can be configured as EF based by 2922 using a relaxed performance parameter and a rate scheduler. 2924 When a user/endpoint initiates a new Broadcast session (i.e., starts 2925 an Internet radio application, starts a live Internet A/V event or a 2926 camera comes online to do video-surveillance), the admission 2927 procedure should be verified within the application that triggers 2928 the flow. The newly admitted data rates will SHOULD be within the 2929 engineered capacity of the Broadcast service class within that 2930 network. The bandwidth in the core network and the number of 2931 simultaneous Broadcast sessions that can be supported SHOULD be 2932 engineered to control traffic load for this service. 2934 This service class SHOULD be configured to provide high assurance 2935 for bandwidth for CS3 marked packets to ensure that they get 2936 forwarded. The Broadcast service class SHOULD be configured to use 2937 Rate Queuing system such as that defined in Section 1.4.1.2 of this 2938 document. Note that either Broadcast PHB MAY be configured as 2939 another EF PHB, specifically CS3-Admit, that uses a relaxed 2940 performance parameter and a rate scheduler, in the priority queue as 2941 defined in Section 1.4.1.1 of this document. 2943 The following applications SHOULD use the Broadcast service class: 2945 o Video surveillance and security (unicast). 2947 o TV broadcast including HDTV (likely multicast, but can be 2948 unicast). 2950 o Video on demand (unicast) with control (virtual DVD). 2952 o Streaming of live audio events (both unicast and multicast). 2954 o Streaming of live video events (both unicast and multicast). 2956 The following are traffic characteristics: 2958 o Variable size packets. 2960 o The higher the rate, the higher the density of large packets. 2962 o Mixture of variable rate and constant rate flows. 2964 o Fixed packet emission time intervals. 2966 o Inelastic flows. 2968 RECOMMENDED DSCP marking: 2970 o All non-admitted flows in this service class are marked with CS3 2971 (Class Selector 3). 2973 o All capacity-admitted flows in this service class are marked with 2974 CS3-Admit. 2976 o In some cases, such as those for security and video surveillance 2977 applications, it is NOT RECOMMENDED, but allowed to use a 2978 different DSCP marking. 2980 If so, then locally user definable (EXP/LU) codepoints in the 2981 range '011x11' MAY be used to provide unique traffic 2982 identification. The locally administrator definable (EXP/LU, 2983 from pool 2 of RFC 2474) codepoint(s) MAY be associated with the 2984 PHB that is used for CS3 or CS3-Admit traffic. Furthermore, 2985 depending on the network scenario, additional network edge 2986 conditioning policy MAY be needed for the EXP/LU codepoint(s) 2987 used. 2989 Applications or IP end points SHOULD pre-mark their packets with CS3 2990 or CS3-Admit DSCP value. If the end point is not capable of setting 2991 the DSCP value, then the router topologically closest to the end 2992 point SHOULD perform Multifield (MF) Classification, as defined in 2993 [RFC2475]. 2995 RECOMMENDED conditioning performed at DiffServ network edge: 2997 o Packet flow marking (DSCP setting) from untrusted sources (end 2998 user devices) SHOULD be verified at ingress to DiffServ network 2999 using Multifield (MF) Classification methods defined in 3000 [RFC2475]. 3002 o Packet flows from untrusted sources (end user devices) SHOULD be 3003 policed at ingress to DiffServ network, e.g., using single rate 3004 with burst size token bucket policer to ensure that the traffic 3005 stays within its negotiated or engineered bounds. 3007 o Packet flows from trusted sources (application servers inside 3008 administered network) MAY not require policing. 3010 o Policing of packet flows across peering points MUST be performed 3011 to the Service Level Agreement (SLA) of those peering entities. 3013 The fundamental service offered to "Broadcast" traffic is enhanced 3014 best-effort service with controlled rate and delay. The fundamental 3015 service offered to capacity-admitted "Broadcast" traffic is a 3016 guaranteed service using in-data-path signaling to ensure expected 3017 or timely delivery. Capacity-admitted Broadcast service SHOULD NOT 3018 result in packet loss. The service SHOULD be engineered so that CS3 3019 and CS3-Admit marked packet flows have sufficient bandwidth in the 3020 network to provide high assurance of delivery. Normally, traffic in 3021 this service class does not respond dynamically to packet loss. As 3022 such, Active Queue Management [RFC2309] SHOULD NOT be applied to 3023 CS3 marked packet flows. 3025 4.6. Low-Latency Data Service Class 3027 The Low-Latency Data service class is RECOMMENDED for elastic and 3028 responsive typically client-/server-based applications. 3029 Applications forwarded by this service class are those that require 3030 a relatively fast response and typically have asymmetrical bandwidth 3031 need, i.e., the client typically sends a short message to the server 3032 and the server responds with a much larger data flow back to the 3033 client. The most common example of this is when a user clicks a 3034 hyperlink (~ few dozen bytes) on a web page, resulting in a new web 3035 page to be loaded (Kbytes or MBs of data). This service class is 3036 configured to provide good response for TCP [RFC1633] short-lived 3037 flows that require real-time packet forwarding of variable rate 3038 traffic sources. 3040 The Low-Latency Data service class SHOULD use the Assured Forwarding 3041 (AF) PHB, defined in [RFC2597]. This service class SHOULD be 3042 configured to provide a minimum bandwidth assurance for AF21, AF22, 3043 and AF23 marked packets to ensure that they get forwarded. The 3044 Low-Latency Data service class SHOULD be configured to use a Rate 3045 Queuing system such as that defined in Section 1.4.1.2 of this 3046 document. 3048 The following applications SHOULD use the Low-Latency Data service 3049 class: 3051 o Client/server applications. 3053 o Systems Network Architecture (SNA) terminal to host transactions 3054 (SNA over IP using Data Link Switching (DLSw)). 3056 o Web-based transactions (E-commerce). 3058 o Credit card transactions. 3060 o Financial wire transfers. 3062 o Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN). 3064 o VPN service that supports Committed Information Rate (CIR) with 3065 up to two burst sizes. 3067 o Instant Messaging and Presence protocols (e.g., SIP, XMPP). 3069 The following are traffic characteristics: 3071 o Variable size packets. 3073 o Variable packet emission rate. 3075 o With packet bursts of TCP window size. 3077 o Short traffic bursts. 3079 o Source capable of reducing its transmission rate based on 3080 detection of packet loss at the receiver or through explicit 3081 congestion notification. 3083 Applications or IP end points SHOULD pre-mark their packets with 3084 DSCP values as shown below. If the end point is not capable of 3085 setting the DSCP value, then the router topologically closest to the 3086 end point SHOULD perform Multifield (MF) Classification, as defined 3087 in [RFC2475] and mark all packets as AF2x. Note: In this case, the 3088 single-rate, three-color marker will be configured to operate in 3089 Color-Blind mode. 3091 RECOMMENDED DSCP marking: 3093 o AF21 = flow stream with packet burst size up to "A" bytes. 3095 o AF22 = flow stream with packet burst size in excess of "A" but 3096 below "B" bytes. 3098 o AF23 = flow stream with packet burst size in excess of "B" bytes. 3100 o Where "A" < "B". 3102 RECOMMENDED conditioning performed at DiffServ network edge: 3104 o The single-rate, three-color marker SHOULD be configured to 3105 provide the behavior as defined in srTCM [RFC2697]. 3107 o If packets are marked by trusted sources or a previously trusted 3108 DiffServ domain and the color marking is to be preserved, then 3109 the single-rate, three-color marker SHOULD be configured to 3110 operate in Color-Aware mode. 3112 o If the packet marking is not trusted or the color marking is 3113 not to be preserved, then the single-rate, three-color marker 3114 SHOULD be configured to operate in Color-Blind mode. 3116 The fundamental service offered to "Low-Latency Data" traffic is 3117 enhanced best-effort service with controlled rate and delay. The 3118 service SHOULD be engineered so that AF21 marked packet flows have 3119 sufficient bandwidth in the network to provide high assurance of 3120 delivery. Since the AF2x traffic is elastic and responds 3121 dynamically to packet loss, Active Queue Management [RFC2309] SHOULD 3122 be used primarily to control TCP flow rates at congestion points by 3123 dropping packets from TCP flows that have large burst size. The 3124 probability of loss of AF21 traffic MUST NOT exceed the probability 3125 of loss of AF22 traffic, which in turn MUST NOT exceed the 3126 probability of loss of AF23. Explicit Congestion Notification (ECN) 3127 [RFC3168] MAY also be used with Active Queue Management. 3129 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3130 specifies a target queue depth for each DSCP, and the max-threshold 3131 specifies the queue depth above which all traffic with such a DSCP 3132 is dropped or ECN marked. Thus, in this service class, the 3133 following inequality should hold in queue configurations: 3135 o min-threshold AF23 < max-threshold AF23 3137 o max-threshold AF23 <= min-threshold AF22 3139 o min-threshold AF22 < max-threshold AF22 3141 o max-threshold AF22 <= min-threshold AF21 3142 o min-threshold AF21 < max-threshold AF21 3144 o max-threshold AF21 <= memory assigned to the queue 3146 Note: This configuration tends to drop AF23 traffic before AF22 and 3147 AF22 before AF21. Many other AQM algorithms exist and are 3148 used; they should be configured to achieve a similar result. 3150 4.7. Conversational Signaling Service Class 3152 The Signaling service class is MUST be limited to delay-sensitive 3153 signaling traffic only, and then only applying to signaling that 3154 involves the Conversational service group. Audio signaling includes 3155 signaling between IP phone and soft-switch, soft-client and 3156 soft-switch, and media gateway and soft-switch as well as 3157 peer-to-peer using various protocols. Video and Hi-Res signaling 3158 includes video endpoint to video endpoint, as well as to Media 3159 transfer Point (MTP), to call control server(S), etc. This service 3160 class is intended to be used for control of voice and video sessions 3161 and applications. Protocols using this service class require a 3162 relatively fast response, as there are typically several messages of 3163 different sizes sent for control of the session. This service class 3164 is configured to provide good response for short-lived, intermittent 3165 flows that require real-time packet forwarding. This is not the 3166 service class for Instant Messaging (IM), that's within the bounds 3167 of the Low-Latency Data service class. The Conversational Signaling 3168 service class MUST be configured so that the probability of packet 3169 drop or significant queuing delay under peak load is very low in IP 3170 network segments that provide this interface. 3172 The Conversational Signaling service class MUST use the new A/V-Sig 3173 PHB, defined in [ID-DSCP]. This service class MUST be configured to 3174 provide a minimum bandwidth assurance for A/V-Sig marked packets to 3175 ensure that they get forwarded. In other words, this service class 3176 MUST NOT be starved from transmission within a reasonable timeframe, 3177 given that the entire Conversational service group depends on these 3178 signaling messages successful delivery. Network engineering SHOULD 3179 be done to ensure there is roughly 1-4% available per node interface 3180 that audio and video traverse. Local conditions MUST be considered 3181 when determining exactly how much bandwidth is given to this service 3182 class. The Conversational Signaling service class SHOULD be 3183 configured to use a Rate Queuing system such as that defined in 3184 Section 1.4.1.2 of this document. 3186 The following applications SHOULD use the Conversational Signaling 3187 service class: 3189 o Peer-to-peer IP telephony signaling (e.g., SIP, H.323, XMPP). 3191 o Peer-to-peer signaling for multimedia applications (e.g., SIP, 3192 H.323, XMPP). 3194 o Peer-to-peer real-time control function. 3196 o Client-server IP telephony signaling using H.248, MEGACO, MGCP, 3197 IP encapsulated ISDN, or other proprietary protocols. 3199 o Signaling to control IPTV applications using protocols such as 3200 IGMP. 3202 o Signaling flows between high-capacity telephony call servers or 3203 soft switches using protocol such as SIP-T. Such high-capacity 3204 devices may control thousands of telephony (VoIP) calls. 3206 o Signaling for one-way video flows, such as RTSP [RFC2326]. 3208 o IGMP, when used for multicast session control such as channel 3209 changing in IPTV systems. 3211 o OPTIONALLY, this service class can be used for on-path 3212 reservation signaling for the traffic flows that will use the 3213 "admitted" DSCPs. The alternative is to have the on-path 3214 signaling (for reservations) use the DSCP within that service 3215 class. This provides a similar treatment of the signaling to the 3216 data flow, which might be desired. 3218 The following are traffic characteristics: 3220 o Variable size packets, normally one packet at a time. 3222 o Intermittent traffic flows. 3224 o Traffic may burst at times. 3226 o Delay-sensitive control messages sent between two end points. 3228 RECOMMENDED DSCP marking: 3230 o All flows in this service class are marked with A/V-Sig. 3232 Applications or IP end points SHOULD pre-mark their packets with 3233 A/V-Sig DSCP value. If the end point is not capable of setting the 3234 DSCP value, then the router topologically closest to the end point 3235 SHOULD perform Multifield (MF) Classification, as defined in 3236 [RFC2475]. 3238 RECOMMENDED conditioning performed at DiffServ network edge: 3240 o Packet flow marking (DSCP setting) from untrusted sources (end 3241 user devices) SHOULD be verified at ingress to DiffServ network 3242 using Multifield (MF) Classification methods defined in 3243 [RFC2475]. 3245 o Packet flows from untrusted sources (end user devices) SHOULD be 3246 policed at ingress to DiffServ network, e.g., using single rate 3247 with burst size token bucket policer to ensure that the traffic 3248 stays within its negotiated or engineered bounds. 3250 o Packet flows from trusted sources (application servers inside 3251 administered network) MAY not require policing. 3253 o Policing of packet flows across peering points in which each peer 3254 is participating in the call set-up MUST be performed to the 3255 Service Level Agreement (SLA). 3257 The fundamental service offered to "Conversational Signaling" 3258 traffic is enhanced best-effort service with controlled rate and 3259 delay. The service SHOULD be engineered so that A/V-Sig marked 3260 packet flows have sufficient bandwidth in the network to provide 3261 high assurance of delivery and low delay. Normally, traffic in this 3262 service class does not respond dynamically to packet loss. As such, 3263 Active Queue Management [RFC2309] SHOULD NOT be applied to A/V-Sig 3264 marked packet flows. 3266 4.8. High-Throughput Data Service Class 3268 The High-Throughput Data service class is RECOMMENDED for elastic 3269 applications that require timely packet forwarding of variable rate 3270 traffic sources and, more specifically, is configured to provide 3271 good throughput for TCP longer-lived flows. TCP [RFC1633] or a 3272 transport with a consistent Congestion Avoidance Procedure [RFC2581] 3273 [RFC3782] normally will drive as high a data rate as it can obtain 3274 over a long period of time. The FTP protocol is a common example, 3275 although one cannot definitively say that all FTP transfers are 3276 moving data in bulk. 3278 The High-Throughput Data service class SHOULD use the Assured 3279 Forwarding (AF) PHB, defined in [RFC2597]. This service class 3280 SHOULD be configured to provide a minimum bandwidth assurance for 3281 AF11, AF12, and AF13 marked packets to ensure that they are 3282 forwarded in a timely manner. The High-Throughput Data service 3283 class SHOULD be configured to use a Rate Queuing system such as that 3284 defined in Section 1.4.1.2 of this document. 3286 The following applications SHOULD use the High-Throughput Data 3287 service class: 3289 o Store and forward applications. 3291 o File transfer applications (e.g., FTP, HTTP, etc). 3293 o Email. 3295 o VPN service that supports two rates (committed information rate 3296 and excess or peak information rate). 3298 The following are traffic characteristics: 3300 o Variable size packets. 3302 o Variable packet emission rate. 3304 o Variable rate. 3306 o With packet bursts of TCP window size. 3308 o Source capable of reducing its transmission rate based on 3309 detection of packet loss at the receiver or through explicit 3310 congestion notification. 3312 Applications or IP end points SHOULD pre-mark their packets with 3313 DSCP values as shown below. If the end point is not capable of 3314 setting the DSCP value, then the router topologically closest to the 3315 end point SHOULD perform Multifield (MF) Classification, as defined 3316 in [RFC2475], and mark all packets as AF1x. Note: In this case, the 3317 two-rate, three-color marker will be configured to operate in 3318 Color-Blind mode. 3320 RECOMMENDED DSCP marking: 3322 o AF11 = up to specified rate "A". 3324 o AF12 = in excess of specified rate "A" but below specified rate 3325 "B". 3327 o AF13 = in excess of specified rate "B". 3329 o Where "A" < "B". 3331 RECOMMENDED conditioning performed at DiffServ network edge: 3333 o The two-rate, three-color marker SHOULD be configured to provide 3334 the behavior as defined in trTCM [RFC2698]. 3336 o If packets are marked by trusted sources or a previously trusted 3337 DiffServ domain and the color marking is to be preserved, then 3338 the two-rate, three-color marker SHOULD be configured to operate 3339 in Color-Aware mode. 3341 o If the packet marking is not trusted or the color marking is not 3342 to be preserved, then the two-rate, three-color marker SHOULD be 3343 configured to operate in Color-Blind mode. 3345 The fundamental service offered to "High-Throughput Data" traffic is 3346 enhanced best-effort service with a specified minimum rate. The 3347 service SHOULD be engineered so that AF11 marked packet flows have 3348 sufficient bandwidth in the network to provide assured delivery. It 3349 can be assumed that this class will consume any available bandwidth 3350 and that packets traversing congested links may experience higher 3351 queuing delays or packet loss. Since the AF1x traffic is elastic 3352 and responds dynamically to packet loss, Active Queue Management 3353 [RFC2309] SHOULD be used primarily to control TCP flow rates at 3354 congestion points by dropping packets from TCP flows that have 3355 higher rates first. The probability of loss of AF11 traffic MUST 3356 NOT exceed the probability of loss of AF12 traffic, which in turn 3357 MUST NOT exceed the probability of loss of AF13. In such a case, if 3358 one network customer is driving significant excess and another seeks 3359 to use the link, any losses will be experienced by the high-rate 3360 user, causing him to reduce his rate. Explicit Congestion 3361 Notification (ECN) [RFC3168] MAY also be used with Active Queue 3362 Management. 3364 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3365 specifies a target queue depth for each DSCP, and the max-threshold 3366 specifies the queue depth above which all traffic with such a DSCP 3367 is dropped or ECN marked. Thus, in this service class, the 3368 following inequality should hold in queue configurations: 3370 o min-threshold AF13 < max-threshold AF13 3372 o max-threshold AF13 <= min-threshold AF12 3374 o min-threshold AF12 < max-threshold AF12 3376 o max-threshold AF12 <= min-threshold AF11 3378 o min-threshold AF11 < max-threshold AF11 3380 o max-threshold AF11 <= memory assigned to the queue 3382 Note: This configuration tends to drop AF13 traffic before AF12 and 3383 AF12 before AF11. Many other AQM algorithms exist and are 3384 used; they should be configured to achieve a similar result. 3386 4.9. Standard Service Class 3388 The Standard service class is RECOMMENDED for traffic that has not 3389 been classified into one of the other supported forwarding service 3390 classes in the DiffServ network domain. This service class provides 3391 the Internet's "best-effort" forwarding behavior. This service 3392 class typically has minimum bandwidth guarantee. 3394 The Standard service class MUST use the Default Forwarding (DF) PHB, 3395 defined in [RFC2474], and SHOULD be configured to receive at least a 3396 small percentage of forwarding resources as a guaranteed minimum. 3397 This service class SHOULD be configured to use a Rate Queuing system 3398 such as that defined in Section 1.4.1.2 of this document. 3400 The following applications SHOULD use the Standard service class: 3402 o Network services, DNS, DHCP, BootP. 3404 o Any undifferentiated application/packet flow transported through 3405 the DiffServ enabled network. 3407 The following is a traffic characteristic: 3409 o Non-deterministic, mixture of everything. 3411 The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'. 3413 Network Edge Conditioning: 3415 There is no requirement that conditioning of packet flows be 3416 performed for this service class. 3418 The fundamental service offered to the Standard service class is 3419 best-effort service with active queue management to limit overall 3420 delay. Typical configurations SHOULD use random packet dropping to 3421 implement Active Queue Management [RFC2309] or Explicit Congestion 3422 Notification [RFC3168], and MAY impose a minimum or maximum rate on 3423 the queue. 3425 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3426 specifies a target queue depth, and the max-threshold specifies the 3427 queue depth above which all traffic is dropped or ECN marked. Thus, 3428 in this service class, the following inequality should hold in queue 3429 configurations: 3431 o min-threshold DF < max-threshold DF 3433 o max-threshold DF <= memory assigned to the queue 3435 Note: Many other AQM algorithms exist and are used; they should be 3436 configured to achieve a similar result. 3438 4.10. Low-Priority Data 3440 The Low-Priority Data service class serves applications that run 3441 over TCP [RFC0793] or a transport with consistent congestion 3442 avoidance procedures [RFC2581] [RFC3782] and that the user is 3443 willing to accept service without guarantees. This service class is 3444 specified in [RFC3662] and [QBSS]. 3446 The following applications MAY use the Low-Priority Data service 3447 class: 3449 o Any TCP based-application/packet flow transported through the 3450 DiffServ enabled network that does not require any bandwidth 3451 assurances. 3453 The following is a traffic characteristic: 3455 o Non-real-time and elastic. 3457 Network Edge Conditioning: 3459 There is no requirement that conditioning of packet flows be 3460 performed for this service class. 3462 The RECOMMENDED DSCP marking is CS1 (Class Selector 1). 3464 The fundamental service offered to the Low-Priority Data service 3465 class is best-effort service with zero bandwidth assurance. By 3466 placing it into a separate queue or class, it may be treated in a 3467 manner consistent with a specific Service Level Agreement. 3469 Typical configurations SHOULD use Explicit Congestion Notification 3470 [RFC3168] or random loss to implement Active Queue Management 3471 [RFC2309]. 3473 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3474 specifies a target queue depth, and the max-threshold specifies the 3475 queue depth above which all traffic is dropped or ECN marked. Thus, 3476 in this service class, the following inequality should hold in queue 3477 configurations: 3479 o min-threshold CS1 < max-threshold CS1 3481 o max-threshold CS1 <= memory assigned to the queue 3483 Note: Many other AQM algorithms exist and are used; they should be 3484 configured to achieve a similar result. 3486 5. Additional Information on Service Class Usage 3488 In this section, we provide additional information on how some 3489 specific applications should be configured to use the defined 3490 service classes. 3492 5.1. Mapping for NTP 3494 From tests that were performed, indications are that precise time 3495 distribution requires a very low packet delay variation (jitter) 3496 transport. Therefore, we suggest that the following guidelines for 3497 Network Time Protocol (NTP) be used: 3499 o When NTP is used for providing high-accuracy timing within an 3500 administrator's (carrier's) network or to end users/clients, the 3501 audio service class SHOULD be used, and NTP packets should be 3502 marked with EF DSCP value. 3504 o For applications that require "wall clock" timing accuracy, the 3505 Standard service class should be used, and packets should be 3506 marked with DF DSCP. 3508 5.2. VPN Service Mapping 3510 "Differentiated Services and Tunnels" [RFC2983] considers the 3511 interaction of DiffServ architecture with IP tunnels of various 3512 forms. Further to guidelines provided in RFC 2983, below are 3513 additional guidelines for mapping service classes that are supported 3514 in one part of the network into a VPN connection. This discussion 3515 is limited to VPNs that use DiffServ technology for traffic 3516 differentiation. 3518 o The DSCP value(s) that is/are used to represent a PHB or a PHB 3519 group SHOULD be the same for the networks at both ends of the VPN 3520 tunnel, unless remarking of DSCP is done as ingress/egress 3521 processing function of the tunnel. DSCP marking needs to be 3522 preserved along the tunnel, end to end. 3524 o The VPN MAY be configured to support one or more service classes. 3525 It is left up to the administrators of the two networks to agree 3526 on the level of traffic differentiation that will be provided in 3527 the network that supports VPN service. Service classes are then 3528 mapped into the supported VPN traffic forwarding behaviors that 3529 meet the traffic characteristics and performance requirements of 3530 the encapsulated service classes. 3532 o The traffic treatment in the network that is providing the VPN 3533 service needs to be such that the encapsulated service class or 3534 classes receive comparable behavior and performance in terms of 3535 delay, jitter, and packet loss and that they are within the 3536 limits of the service specified. 3538 o The DSCP value in the external header of the packet forwarded 3539 through the network providing the VPN service can be different 3540 from the DSCP value that is used end to end for service 3541 differentiation in the end network. 3543 o The guidelines for aggregation of two or more service classes 3544 into a single traffic forwarding treatment in the network that is 3545 providing the VPN service is for further study. 3547 6. Security Considerations 3549 This document discusses policy and describes a common policy 3550 configuration, for the use of a Differentiated Services Code Point 3551 by transports and applications. If implemented as described, it 3552 should require that the network do nothing that the network has not 3553 already allowed. If that is the case, no new security issues should 3554 arise from the use of such a policy. 3556 It is possible for the policy to be applied incorrectly, or for a 3557 wrong policy to be applied in the network for the defined service 3558 class. In that case, a policy issue exists that the network SHOULD 3559 detect, assess, and deal with. This is a known security issue in 3560 any network dependent on policy-directed behavior. 3562 A well-known flaw appears when bandwidth is reserved or enabled for 3563 a service (for example, voice and/or video transport) and another 3564 service or an attacking traffic stream uses it. This possibility is 3565 inherent in DiffServ technology, which depends on appropriate packet 3566 markings. When bandwidth reservation or a priority queuing system is 3567 used in a vulnerable network, the use of authentication and flow 3568 admission is recommended. To the author's knowledge, there is no 3569 known technical way to respond to an unauthenticated data stream 3570 using service that it is not intended to use, and such is the nature 3571 of the Internet. 3573 The use of a service class by a user is not an issue when the SLA 3574 between the user and the network permits him to use it, or to use it 3575 up to a stated rate. In such cases, simple policing is used in the 3576 Differentiated Services Architecture. Some service classes, such as 3577 Network Control, are not permitted to be used by users at all; such 3578 traffic should be dropped or remarked by ingress filters. Where 3579 service classes are available under the SLA only to an authenticated 3580 user rather than to the entire population of users, authentication 3581 and authorization services are required, such as those surveyed in 3582 [AUTHMECH]. 3584 7. Contributing Authors 3586 This section specifically calls out the authors of RFC 4594, from 3587 which this document is based on. 3589 Jozef Babiarz 3590 Nortel Networks 3592 Kwok Ho Chan 3593 Nortel Networks 3594 Email: khchan.work@gmail.com 3596 Fred Baker 3597 Cisco Systems 3598 EMail: fred@cisco.com 3600 Of note, two of the three mentioned authors above worked for Nortel 3601 Networks at the time of writing RFC 4594, a company that no longer 3602 exists. This author has not seen or heard from those two in many, 3603 many years or IETF meetings - as a result of not knowing their new 3604 email addresses (or phone numbers). 3606 While much of this document has been rewritten with either edited or 3607 brand new material, there are many short paragraphs that remain as 3608 they were from RFC 4594, as well as many sentences that were also 3609 left unchanged. Additionally, there were no new graphs, charts, 3610 diagrams, or tables introduced, meaning the first 4 tables within 3611 this document existed in RFC 4594, created by those authors. 3612 Presently, each of those tables contain modified and new 3613 information. The last 3 tables, specifically tables 5, 6, & 7 were 3614 removed because the examples section was removed. 3616 This author believes there must be proper credit given for all the 3617 contributions, including the framework this document retains from 3618 that RFC. Periodically, throughout this document, what was written 3619 remains the best way of conveying a thought, rule, or otherwise 3620 stated behavior or mechanism. Because RFC 4594 was rather large, 3621 there is no realistic way of identifying each part that was left 3622 untouched. Further, properly quoting that RFC and leaving those 3623 sentences embedded in this document would render this document 3624 highly unreadable. Another application could be used to show the 3625 changes, deletions and additions - but not one that the IETF accepts 3626 presently. 3628 This author has created this "Contributing Authors" section as a way 3629 of properly identifying those 3 individuals that provided text 3630 within this document. We will let the community judge if this is 3631 'good enough' (i.e., rough consensus), or if another way is better. 3633 8. Acknowledgements 3635 The author would like to thank Paul Jones, Glen Lavers, Mo Zanaty, 3636 David Benham, Michael Ramalho, Gorry Fairhurst, David Black, Brian 3637 Carpenter, Al Morton, Ruediger Geib and Shitanshu Shah for their 3638 comments and questions about this effort that ultimately helped 3639 shape this document. 3641 Below are the folks that were acknowledged in RFC 4594, and this 3642 author does not want to lose their recognition of contributions to 3643 the original effort. 3645 "The authors thank the TSVWG reviewers, David Black, Brian E. 3646 Carpenter, and Alan O'Neill for their review and input to this 3647 document. 3649 The authors acknowledge a great many inputs, most notably from 3650 Bruce Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois 3651 Audet, Morgan Littlewood, Robert Milne, John Shuler, Nalin 3652 Mistry, Al Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil 3653 Dickinson, Mike Fidler, and Shane Amante. Kimberly King, Joe 3654 Zebarth, and Alistair Munroe each did a thorough proofreading, 3655 and the document is better for their contributions." 3657 9. References 3659 9.1. Normative References 3661 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3662 September 1981. 3664 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 3665 793, September 1981. 3667 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 3668 Suite", RFC 1349, July 1992. 3670 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 3671 1812, June 1995. 3673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3674 Requirement Levels", BCP 14, RFC 2119, March 1997. 3676 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 3677 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 3678 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 3679 S., Wroclawski, J., and L. Zhang, "Recommendations on 3680 Queue Management and Congestion Avoidance in the 3681 Internet", RFC 2309, April 1998. 3683 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3684 "Definition of the Differentiated Services Field (DS 3685 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 3686 1998. 3688 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 3689 and W. Weiss, "An Architecture for Differentiated 3690 Service", RFC 2475, December 1998. 3692 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 3693 "Assured Forwarding PHB Group", RFC 2597, June 1999. 3695 [RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le 3696 Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. 3697 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 3698 Behavior)", RFC 3246, March 2002. 3700 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3701 Jacobson, "RTP: A Transport Protocol for Real-Time 3702 Applications", STD 64, RFC 3550, July 2003. 3704 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 3705 Per-Domain Behavior (PDB) for Differentiated Services", 3706 RFC 3662, December 2003. 3708 [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code 3709 Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, 3710 May 2010 3712 9.2. Informative References 3714 [AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms", 3715 Work in Progress, September 2005. 3717 [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 3718 Technical Report Proposed Service Definition, March 2001. 3720 [IEEE1Q] IEEE, 802.1Q Specification 3722 [IEEE1E] IEEE, 802.1E Wireless LAN User Priority Specification 3724 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated 3725 Services in the Internet Architecture: an Overview", RFC 3726 1633, June 1994. 3728 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 3729 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 3730 Functional Specification", RFC 2205, September 1997. 3732 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 3733 Control", RFC 2581, April 1999. 3735 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 3736 Marker", RFC 2697, September 1999. 3738 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 3739 Marker", RFC 2698, September 1999. 3741 [RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive 3742 Shaper for Differentiated Services", RFC 2963, October 3743 2000. 3745 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 3746 2983, October 2000. 3748 [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, 3749 November 2000. 3751 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 3752 Differentiated Services Per Domain Behaviors and Rules 3753 for their Specification", RFC 3086, April 2001. 3755 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3756 of Explicit Congestion Notification (ECN) to IP", RFC 3757 3168, September 2001. 3759 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 3760 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3761 3175, September 2001. 3763 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 3764 Informal Management Model for Diffserv Routers", RFC 3290, 3765 May 2002. 3767 [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno 3768 Modification to TCP's Fast Recovery Algorithm", RFC 3782, 3769 April 2004. 3771 [RFC5462] L. Andersson, R. Asati, "Multiprotocol Label Switching 3772 (MPLS) Label Stack Entry: EXP Field Renamed to Traffic Class 3773 Field", RFC 5462, February 2009 3775 Authors' Address 3777 James Polk 3778 3913 Treemont Circle 3779 Colleyville, Texas 76034 3781 Phone: +1.817.271.3552 3782 Email: jmpolk@cisco.com 3784 Appendix A - Changes 3786 Here is a list of all the changes that were captured during the 3787 editing process. This will not be a complete list, and others are 3788 free to point out what the authors missed, and we'll include that in 3789 the next release. 3791 A.1 Since Individual -02 to -03 3793 o Inserted section 1.6 to explain fundamentally what has changed 3794 since RFC 4594, and why changes are necessary. 3796 A.2 Since Individual -01 to -02 3798 o Added text to the Intro section on the justification from 3799 DiffServ Problem Statement draft, as to more of why this update 3800 is necessary. 3802 o Added text to the Intro section expanding on the concept of 3803 service classes vs. treatment aggregates (from RFC 5127). 3805 A.3 Since Individual -00 to -01 3807 o Added Section 2.4 which covers the conflation issues regarding 3808 the differences between service classes and treatment aggregates. 3810 o Added example operational configurations of treatment aggregates 3811 applied to this draft's new set of service classes and additional 3812 DSCPs. 3814 o Added references RFC 5865, RFC 5462, IEEE 802.1E and IEEE 802.1Q. 3816 A.4 Since RFC 4594 to Individual Update -00 3818 o rewrote Intro to emphasize current topics 3820 o Created a Conversational Service group, comprising the audio, 3821 video and Hi-Res service classes - because they have similar 3822 characteristics. 3824 o Incorporated the 6 new DSCPs from [ID-DSCP]. 3826 o moved the example section, en mass, to an appendix that might not 3827 be kept for this version. We're not sure it accomplishes what it 3828 needs to, and might not provide any real usefulness. 3830 o Moved 'Realtime-Interactive' service class to CS5, from CS4 3832 o Changed 'Broadcast Video' service class to 'Broadcast' service 3833 class 3835 o Changed AF4X to 'Video' service class, replacing 'Multimedia 3836 Conferencing' service class 3838 o Moved 'Multimedia Conferencing' service class to different DSCPs 3840 o Added the 'Hi-Res' service class 3842 o Removed section 5.1 on signaling choices. It has been included in 3843 the main body of the text. 3845 o Changed document title 3847 o ...