idnits 2.17.1 draft-polk-tsvwg-rfc4594-update-00.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 67 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 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 860 has weird spacing: '...ly. One examp...' == Line 2508 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). -- The document date (Mar 5, 2012) is 4428 days in the past. Is this intentional? -- 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: 'RFC5865' is mentioned on line 1644, but not defined == Missing Reference: 'ID-DSCP' is mentioned on line 3399, but not defined == Missing Reference: 'RFC4594' is mentioned on line 207, but not defined == Missing Reference: 'RFC3550' is mentioned on line 1967, but not defined == Missing Reference: 'RFC2326' is mentioned on line 2820, but not defined ** Obsolete undefined reference: RFC 2326 (Obsoleted by RFC 7826) == Unused Reference: 'RFC2996' is defined on line 3348, but no explicit reference was found in the text == Unused Reference: 'RFC3175' is defined on line 3359, 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: 6 errors (**), 0 flaws (~~), 15 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network WG James Polk 3 Internet-Draft Cisco 4 Intended status: Standards Track (PS) Mar 5, 2012 5 Obsoletes: RFC 4594 6 Updates: RFC 5865 7 Expires: Sept 5, 2012 9 Standard Configuration of DiffServ Service Classes 10 draft-polk-tsvwg-rfc4594-update-00.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 September 5, 2012. 40 Copyright Notice 42 Copyright (c) 2011 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 .....................................6 59 1.2. Expected Use in the Network ...............................6 60 1.3. Service Class Definition ..................................7 61 1.4. Key Differentiated Services Concepts ......................8 62 1.4.1. Queuing ............................................8 63 1.4.1.1. Priority Queuing ..........................9 64 1.4.1.2. Rate Queuing ..............................9 65 1.4.2. Active Queue Management ............................9 66 1.4.3. Traffic Conditioning ..............................10 67 1.4.4. Differentiated Services Code Point (DSCP) .........11 68 1.4.5. Per-Hop Behavior (PHB) ............................11 69 1.5. Key Service Concepts .....................................11 70 1.5.1. Default Forwarding (DF) ...........................12 71 1.5.2. Assured Forwarding (AF) ...........................12 72 1.5.3. Expedited Forwarding (EF) .........................12 73 1.5.4. Class Selector (CS) ...............................13 74 1.5.5. Admission Control .................................14 75 2. Service Differentiation .......................................14 76 2.1. Service Classes ..........................................15 77 2.2. Categorization of User Oriented Service Classes ..........17 78 2.3. Service Class Characteristics ............................20 79 3. Network Control Traffic .......................................26 80 3.1. Current Practice in the Internet .........................26 81 3.2. Network Control Service Class ............................26 82 3.3. OAM Service Class ........................................28 83 4. User Oriented Traffic .........................................30 84 4.1. Conversational Service Class Group .......................31 85 4.1.1 Audio Service Class ................................31 86 4.1.1 Video Service Class ................................34 87 4.1.1 Hi-Res Service Class ...............................38 88 4.2. Realtime-Interactive Service Class .......................42 89 4.3. Multimedia Conferencing Service Class ....................44 90 4.4. Multimedia Streaming Service Class .......................46 91 4.5. Broadcast Video Service Class ............................49 92 4.6. Low-Latency Data Service Class ...........................52 93 4.7. Conversational Signaling Service Class ...................54 94 4.8. High-Throughput Data Service Class .......................56 95 4.9. Standard Service Class ...................................59 96 4.10. Low-Priority Data .......................................60 97 5. Additional Information on Service Class Usage .................61 98 5.1. Mapping for NTP ..........................................61 99 5.2. VPN Service Mapping ......................................61 100 6. Security Considerations .......................................62 101 7. Contributing Authors ..........................................63 102 8. Acknowledgements ..............................................64 103 9. References ....................................................64 104 9.1. Normative References .....................................64 105 9.2. Informative References ...................................65 106 Author's Address .................................................66 107 Appendix A - Changes .............................................66 109 1. Introduction 111 Differentiated Services [RFC2474][RFC2475] provides the ability to 112 mark/label/classify IP packets differently to distinguish how 113 individual packets need to be treated differently through (or 114 throughout) a network on a per hop basis. Local administrators are 115 who configuration each router for which Differentiated Services Code 116 Points (DSCP) are to be treated differently, which are to be 117 ignored (i.e., no differentiated treatment), and which DSCPs are to 118 have their packets remarked (to different DSCPs) as they pass 119 through a router. Local administrators are also who assign which 120 applications, or traffic types, should use which DSCPs to receive 121 the treatment the administrators expect within their network. 123 What most people fail to understand is that DSCPs provide a per hop 124 behavior (PHB) through that router, but not the previous or next 125 router. In this way of understanding PHB markings, one can 126 understand that Differentiated Services (Diffserv) is not a Quality 127 of Service (QoS) mechanism, but rather a Classification of Service 128 (CoS) mechanism. 130 For instance, there are 64 possible DSCP values, i.e., using 6 bits 131 of the old Type of Service (TOS) byte [RFC0791]. Each can be 132 configured locally to have greater or less treatment relative to any 133 other DSCP with two exceptions*. 135 * Expedited Forwarding (EF) [RFC3246] DSCPs have a treatment 136 requirement that any packet marked within an EF class has to be 137 the next packet transmitted out its egress interface. If there 138 are more than one EF marked packet in the queue, obviously the 139 queue sets the order they are transmitted. Further, if there 140 are more than one EF DSCP, local configuration determines if 141 each are treated the same or differently relate to each other 142 EF DSCP. Currently, there are two Expedited Forwarding DSCPs: 143 EF (101110) [RFC3246] and VOICE-ADMIT (101100) [RFC5865]. 145 * Class Selector 6 (CS6) [RFC2474] is for routing protocol 146 traffic. There are deemed important because if the network does 147 not transmit and receive its routing protocol traffic in a 148 timely manner, the network stops operating properly. 150 Not all are configured to mean anything other than best effort 151 forwarding by local administrators of a network. Let us say there 152 are 5 DSCPs configured within network A. Network A's administrator 153 chooses and configures which order (obeying the two exceptions noted 154 above) which application packets are treated differently than any 155 other packets within that network (A). The DSCPs are not fixed to a 156 linear order for relative priority on a per hop basis. Further, and 157 this is often the case, there might be packets with the same DSCP 158 arriving at multiple interfaces of a node, each egressing that node 159 out the same interface. At ingress to this node, everything was 160 fine, with no poor behavior or noticeably excessive amount of 161 packets with the same DSCP. However, at the egress interface, there 162 might not be enough capacity to satisfy the load, thus the departing 163 packets transmit at their maximum rate for that DSCP, but have 164 additional latency due to the overload within that one node. This is 165 called fan-in (congestion or problem). By itself, DiffServ will not 166 remedy this problem for the application that is intolerant to added 167 latency because DiffServ only functions within 1 node at a time. 169 An additional mechanism is needed to ensure each flow or session 170 receives the amount of packets at its destination that the 171 application requires to perform properly; a mechanism such as 172 IntServ, by way of RSVP [RFC2205] or NSIS [RFC4080]. With this added 173 capability to be session aware, something DiffServ is not, the 174 packets transmitted within a single session have a very good 175 probability of arriving in such a way the receiving application can 176 make full use of each. That said, signaling reservations for each 177 session or flow adds complexity, which creates more work for those 178 who maintain and administer such a network. Adding bandwidth and 179 using DiffServ marking is an easier pill to swallow. The deployment 180 of not few, but more and more audio and (particularly bandwidth 181 hogging) video codecs and their respective application rigidity has 182 caused some to conclude that throwing bandwidth at the problem is no 183 longer acceptable. 185 With this in mind, this document incorporates five of the six new 186 DSCPs from [ID-DSCP] identified as capacity-admitted DSCPs for most 187 of the service classes in this document. As explained in [ID-DSCP], 188 the five new capacity-admitted DSCPs are from Pool 3. [ID-DSCP] goes 189 further to explain that may layer 2 technologies fewer bits for 190 marking and prioritization. Instead of six bits like DiffServ, they 191 have three bits, which yields a maximum of 8 values, which tend to 192 line up quite will with the TOS field values. Thus, aggregation of 193 DSCPs is typically accomplished by simply ignoring or reducing the 194 number of bits used to the most significant ones available, such as 196 EF is 101110, at layer 2 this is merely 101; 198 Broadcast is 011000, at layer 2 this is merely 011. 200 This document is originally built upon the RFC 4594 effort, while 201 updating some of the usages and expanding the scope for newer 202 applications that are in use today. 204 Service class definitions are based on the different traffic 205 characteristics and required performance of the 206 applications/services. There are a greater number of service classes 207 in this document than there were when RFC 4594 [RFC4594] was 208 published (the RFC this document intends to obsolete). The required 209 performance of applications/services has also changed since the 210 publication of RFC 4594, specifically in the area of conversational 211 real time communications. As a result, this document has a greater 212 number of real time applications with more granular set of DSCPs due 213 to their different required performances. Like RFC 4594 before, this 214 approach allows those applications with similar traffic 215 characteristics and performance requirements to be placed in the 216 same service class. 218 The notion of traffic characteristics and required performance is a 219 per application concept, therefore the label name of each service 220 class remains the same on an end-to-end basis, even if we understand 221 that Diffserv is only a PHB and cannot guarantee anything, even 222 packet delivery at the intended destination node. That said, 223 several applications can be configured to have the same DSCP, or 224 each have different DSCPs that have the same treatment per hop 225 within a network. 227 Since RFC 4594 was first published, a new concept has been 228 introduced that will appear throughout this document, including DSCP 229 assignments -- the idea of "admitted" traffic, initially introduced 230 into Diffserv within RFC 5865 [RFC5865]. The VOICE-ADMIT Expedited 231 Forwarding class differentiates itself from the EF Expedited 232 Forwarding by having the packets marked be for admitted traffic. 233 This concept of "admitted" traffic is spread throughout the real 234 time traffic classes. 236 Thus, the document flow is as follows: 238 o maintain the general format of RFC 4594; 240 o augment the content with the concept of capacity-admission; 242 o incorporate much more video into this document, as it has become 243 a dominant application in enterprises and other managed networks, 244 as well as on the open public Internet; 246 o reduce the discussion on voice and its examples; 248 o articulate the subtle differences learned since RFC 4594 was 249 published. 251 The goal here is to provide a standard configuration for DiffServ 252 DSCP assignments and expected PHBs for enterprises and other managed 253 networks, as well as towards the public Internet with specific 254 traffic characteristics per Service class/DSCP, and example 255 applications shown for each. 257 This document describes service classes configured with Diffserv and 258 recommends how they can be used and how to construct them using 259 Differentiated Services Code Points (DSCPs), traffic conditioners, 260 Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) 261 mechanisms. There is no intrinsic requirement that particular 262 DSCPs, traffic conditioners, PHBs, and AQM be used for a certain 263 service class, but as a policy and for interoperability it is useful 264 to apply them consistently. 266 We differentiate services and their characteristics in Section 2. 267 Network control traffic, as well as user oriented traffic are 268 discussed in Sections 3 and 4, respectively. We analyze the security 269 considerations in Section 6. Section 7 offers a tribute to the 270 authors of RFC 4594, from which this document is based. It is in its 271 own section, and not part of the normal acknowledgements portion of 272 each IETF document. 274 1.1. Requirements Notation 276 The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL 277 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 278 in this document are to be interpreted as described in [RFC2119]. 280 1.2. Expected Use in the Network 282 In the Internet today, corporate LANs and ISP WANs are increasingly 283 utilized, to the point in which network congestion is affecting 284 performance of applications. For this reason, congestion, loss, and 285 variation in delay within corporate LANs and ISP backbones is 286 becoming known to the users collectively as "the network is slow for 287 this application" or just "right now" or "for today". Users do not 288 directly detect network congestion. They react to applications that 289 run slow, or to downloads that take too long in their mind(s). The 290 explosion of video traffic on the internet recently has cause much 291 of this, and is often the application the user is using when they 292 have this slowness. 294 In the past, application slowness occurred for three very good 295 reasons. 297 o the networks the user oriented traffic traverses moves through 298 cycles of bandwidth boom and bandwidth bust, the latter of which 299 become apparent with the periodic deployment of new 300 bandwidth-hungry applications. 302 o In access networks, the state is often different. This may be 303 because throughput rates are artificially limited or 304 over-subscribed, or because of access network design trade-offs. 306 o Other characteristics, such as database design on web servers 307 (that may create contention points, e.g., in filestore) and 308 configuration of firewalls and routers, often look externally 309 like a bandwidth limitation. 311 The intent of this document is to provide a standardized marking, 312 plus a conditioning and packet treatment strategy so that it can be 313 configured and put into service on any link that is itself 314 congested. 316 1.3. Service Class Definition 318 A "service class" represents a similar set of traffic 319 characteristics for delay, loss, and jitter as packets traverse 320 routers in a network. For example, "High-Throughput Data" service 321 class for store-and-forward applications, or a "Broadcast" service 322 class for minimally time-shifted IPTV or Internet radio broadcasts. 323 Such a service class may be defined locally in a Differentiated 324 Services (DS) domain, or across multiple DS domains, possibly 325 extending end to end. A goal of this document is to have most/all 326 networks assign the same type of traffic the same for consistency. 328 A service class is a naming convention which is defined as a word, 329 phrase or initialism/acronym representing a set of necessary traffic 330 characteristics of a certain type of data flow. The necessary 331 characteristics of these traffic flows can be realized by the use of 332 defined per-hop behavior that started with [RFC2474]. The actual 333 specification of the expected treatment of a traffic aggregate 334 within a domain may also be defined as a per-domain behavior (PDB) 335 [RFC3086]. 337 Each domain will locally choose to 339 o implement one or more service classes with traffic 340 characteristics as defined here, or 342 o implement one or more service classes with similar traffic 343 characteristics as defined here, or 345 o implement one or more service classes with similar traffic 346 characteristics as defined here and to aggregate one or more 347 service classes to reduce the number of unique DSCPs within their 348 network, or 350 o implement one or more non-standard service classes with traffic 351 characteristics not as defined here, or 353 o not use Diffserv within their domain. 355 For example, low delay, low loss, and minimal jitter may be realized 356 using the EF PHB, or with an over-provisioned AF PHB. This must be 357 done with care as it may disrupt the end-to-end performance required 358 by the applications/services. If the packet sizes are similar within 359 an application, but different between two applications, say small 360 voice packets and large video packets, these two applications may 361 not realize optimum results if merged into the same aggregate if 362 there are any bottlenecks in the network. We provide for this 363 flexibility on a per hop or per domain basis within this document. 365 This document provides standardized markings for traffic with 366 similar characteristics, and usage expectations for PHBs for 367 specific service classes for their consistent implementation. 369 The Default Forwarding "Standard" service class is REQUIRED; all 370 other service classes are OPTIONAL. That said, each service class 371 lists traffic characteristics that are expected when using that type 372 of traffic. It is RECOMMENDED that applications and protocols that 373 fit a certain traffic characteristic use the appropriate service 374 class mark, i.e., the DSCP, for consistent behavior. It is expected 375 that network administrators will base their endpoint application and 376 router configuration choices on the level of service differentiation 377 they require to meet the needs of their customers (i.e., their 378 end-users). 380 1.4. Key Differentiated Services Concepts 382 In order to fully understand this document, a reader needs to 383 familiarize themselves with the principles of the Differentiated 384 Services Architecture [RFC2474]. We summarize some key concepts 385 here only to provide convenience for the reader, the referenced RFCs 386 providing the authoritative definitions. 388 1.4.1. Queuing 390 A queue is a data structure that holds packets that are awaiting 391 transmission. A router interface can only transmit one packet at a 392 time, however fast the interface speed is. If there is only 1 queue 393 at an interface, the packets are transmitted in the order they are 394 received into that queue - called FIFO, or "first in, first out". 395 Sometimes there is a lag in the time between a packets arrives in 396 the queue and when it is transmitted. This delay might be due to 397 lack of bandwidth, or if there are multiple queues on that 398 interface, because a packet is low in priority relative to other 399 packets that are awaiting to transmit. The scheduler is the system 400 entity that chooses which packet is next in line for transmission 401 when more than one packet are awaiting transmission out the same 402 router interface. 404 1.4.1.1 Priority Queuing 406 A priority queuing system is a combination of a set of queues and a 407 scheduler that empties the queues (of packets) in priority sequence. 408 When asked for a packet, the scheduler inspects the highest 409 priority queue and, if there is data present, returns a packet from 410 that queue. Failing that, it inspects the next highest priority 411 queue, and so on. A freeway onramp with a stoplight for one lane 412 that allows vehicles in the high-occupancy-vehicle lane to pass is 413 an example of a priority queuing system; the high-occupancy-vehicle 414 lane represents the "queue" having priority. 416 In a priority queuing system, a packet in the highest priority queue 417 will experience a readily calculated delay. This is proportional to 418 the amount of data remaining to be serialized when the packet 419 arrived plus the volume of the data already queued ahead of it in 420 the same queue. The technical reason for using a priority queue 421 relates exactly to this fact: it limits delay and variations in 422 delay and should be used for traffic that has that requirement. 424 A priority queue or queuing system needs to avoid starvation of 425 lower-priority queues. This may be achieved through a variety of 426 means, such as admission control, rate control, or network 427 engineering. 429 1.4.1.2. Rate Queuing 431 Similarly, a rate-based queuing system is a combination of a set of 432 queues and a scheduler that empties each at a specified rate. An 433 example of a rate-based queuing system is a road intersection with a 434 stoplight. The stoplight acts as a scheduler, giving each lane a 435 certain opportunity to pass traffic through the intersection. 437 In a rate-based queuing system, such as Weighted Fair Queuing (WFQ) 438 or Weighted Round Robin (WRR), the delay that a packet in any given 439 queue will experience depends on the parameters and occupancy of its 440 queue and the parameters and occupancy of the queues it is competing 441 with. A queue whose traffic arrival rate is much less than the rate 442 at which it lets traffic depart will tend to be empty, and packets 443 in it will experience nominal delays. A queue whose traffic arrival 444 rate approximates or exceeds its departure rate will tend not to be 445 empty, and packets in it will experience greater delay. Such a 446 scheduler can impose a minimum rate, a maximum rate, or both, on any 447 queue it touches. 449 1.4.2 Active Queue Management 451 Active Queue Management, or AQM, is a generic name for any of a 452 variety of procedures that use packet dropping or marking to manage 453 the depth of a queue. The canonical example of such a procedure is 454 Random Early Detection (RED), in that a queue is assigned a minimum 455 and maximum threshold, and the queuing algorithm maintains a moving 456 average of the queue depth. While the mean queue depth exceeds the 457 maximum threshold, all arriving traffic is dropped. While the mean 458 queue depth exceeds the minimum threshold but not the maximum 459 threshold, a randomly selected subset of arriving traffic is marked 460 or dropped. This marking or dropping of traffic is intended to 461 communicate with the sending system, causing its congestion 462 avoidance algorithms to kick in. As a result of this behavior, it 463 is reasonable to expect that TCP's cyclic behavior is desynchronized 464 and that the mean queue depth (and therefore delay) should normally 465 approximate the minimum threshold. 467 A variation of the algorithm is applied in Assured Forwarding PHB 468 [RFC2597], in that the behavior aggregate consists of traffic with 469 multiple DSCP marks, which are intermingled in a common queue. 470 Different minima and maxima are configured for the several DSCPs 471 separately, such that traffic that exceeds a stated rate at ingress 472 is more likely to be dropped or marked than traffic that is within 473 its contracted rate. 475 1.4.3 Traffic Conditioning 477 In addition, at the first router in a network that a packet crosses, 478 arriving traffic may be measured and dropped or marked according to 479 a policy, or perhaps shaped on network ingress, as in "A Rate 480 Adaptive Shaper for Differentiated Services" [RFC2963]. This may be 481 used to bias feedback loops, as is done in "Assured Forwarding PHB" 482 [RFC2597], or to limit the amount of traffic in a system, as is done 483 in "Expedited Forwarding PHB" [RFC3246]. Such measurement 484 procedures are collectively referred to as "traffic conditioners". 485 Traffic conditioners are normally built using token bucket meters, 486 for example with a committed rate and burst size, as in Section 487 1.5.3 of the DiffServ Model [RFC3290]. The Assured Forwarding PHB 488 [RFC2597] uses a variation on a meter with multiple rate and burst 489 size measurements to test and identify multiple levels of 490 conformance. 492 Multiple rates and burst sizes can be realized using multiple levels 493 of token buckets or more complex token buckets; these are 494 implementation details. The following are some traffic conditioners 495 that may be used in deployment of differentiated services: 497 o For Class Selector (CS) PHBs, a single token bucket meter to 498 provide a rate plus burst size control. 500 o For Expedited Forwarding (EF) PHB, a single token bucket meter to 501 provide a rate plus burst size control. 503 o For Assured Forwarding (AF) PHBs, usually two token bucket meters 504 configured to provide behavior as outlined in "Two Rate Three 505 Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color 506 Marker (srTCM)" [RFC2697]. The two-rate, three-color marker is 507 used to enforce two rates, whereas the single-rate, three-color 508 marker is used to enforce a committed rate with two burst 509 lengths. 511 1.4.4 Differentiated Services Code Point (DSCP) 513 The DSCP is a number in the range 0..63 that is placed into an IP 514 packet to mark it according to the class of traffic it belongs in. 515 These are divided into 3 groups, or pools, defined in RFC 2474, 516 arranged as follows: 518 o Pool-1 has 32 values designated for standards assignment (of the 519 form 'xxxxx0'). 521 o Pool-2 has 16 values designated for experimental or local use 522 only (EXP/LU) assignment (of the form 'xxxx11'). 524 o Pool-3 has 16 values designated for experimental or local use 525 (EXP/LU) assignment (of the form 'xxxx01'). 527 However, pool-3 is allowed to be assigned for one of two reasons, 529 #1 - if the values in pool-1 are exhausted, or 531 #2 - if there is a justifiable reason for assigning a pool-3 DSCP 532 prior to pool-1's exhaustion. 534 1.4.5 Per-Hop Behavior (PHB) 536 In the end, the mechanisms described above are combined to form a 537 specified set of characteristics for handling different kinds of 538 traffic, depending on the needs of the application. This document 539 seeks to identify useful traffic aggregates and to specify what PHB 540 should be applied to them. 542 1.5 Key Service Concepts 544 While Differentiated Services is a general architecture that may be 545 used to implement a variety of services, three fundamental 546 forwarding behaviors have been defined and characterized for general 547 use. These are basic Default Forwarding (DF) behavior for elastic 548 traffic, the Assured Forwarding (AF) behavior, and the Expedited 549 Forwarding (EF) behavior for real-time (inelastic) traffic. The 550 facts that four code points are recommended for AF and that one code 551 point is recommended for EF are arbitrary choices, and the 552 architecture allows any reasonable number of AF and EF classes 553 simultaneously. The choice of four AF classes and one EF class in 554 the current document is also arbitrary, and operators MAY choose to 555 operate more or fewer of either. 557 The terms "elastic" and "real-time" are defined in [RFC1633], 558 Section 3.1, as a way of understanding broad-brush application 559 requirements. This document should be reviewed to obtain a broad 560 understanding of the issues in quality of service, just as [RFC2475] 561 should be reviewed to understand the data plane architecture used in 562 today's Internet. 564 1.5.1 Default Forwarding (DF) 566 The basic forwarding behaviors applied to any class of traffic are 567 those described in [RFC2474] and [RFC2309]. Best-effort service may 568 be summarized as "I will accept your packets" and is typically 569 configured with some bandwidth guarantee. Packets in transit may be 570 lost, reordered, duplicated, or delayed at random. Generally, 571 networks are engineered to limit this behavior, but changing traffic 572 loads can push any network into such a state. 574 Application traffic in the internet that uses default forwarding is 575 expected to be "elastic" in nature. By this, we mean that the 576 sender of traffic will adjust its transmission rate in response to 577 changes in available rate, loss, or delay. 579 For the basic best-effort service, a single DSCP value is provided 580 to identify the traffic, a queue to store it, and active queue 581 management to protect the network from it and to limit delays. 583 1.5.2 Assured Forwarding (AF) 585 The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled 586 on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss 587 Priority (CLP) capability. It is intended for networks that offer 588 average-rate Service Level Agreements (SLAs) (as FR and ATM networks 589 do). This is an enhanced best-effort service; traffic is expected 590 to be "elastic" in nature. The receiver will detect loss or 591 variation in delay in the network and provide feedback such that the 592 sender adjusts its transmission rate to approximate available 593 capacity. 595 For such behaviors, multiple DSCP values are provided (two or three, 596 perhaps more using local values) to identify the traffic, a common 597 queue to store the aggregate, and active queue management to protect 598 the network from it and to limit delays. Traffic is metered as it 599 enters the network, and traffic is variously marked depending on the 600 arrival rate of the aggregate. The premise is that it is normal for 601 users occasionally to use more capacity than their contract 602 stipulates, perhaps up to some bound. However, if traffic should be 603 marked or lost to manage the queue, this excess traffic will be 604 marked or lost first. 606 1.5.3. Expedited Forwarding (EF) 608 The intent of Expedited Forwarding PHB [RFC3246] is to provide a 609 building block for low-loss, low-delay, and low-jitter services. It 610 can be used to build an enhanced best-effort service: traffic 611 remains subject to loss due to line errors and reordering during 612 routing changes. However, using queuing techniques, the probability 613 of delay or variation in delay is minimized. For this reason, it is 614 generally used to carry voice and for transport of data information 615 that requires "wire like" behavior through the IP network. Voice is 616 an inelastic "real-time" application that sends packets at the rate 617 the codec produces them, regardless of availability of capacity. As 618 such, this service has the potential to disrupt or congest a network 619 if not controlled. It also has the potential for abuse. 621 To protect the network, at minimum one SHOULD police traffic at 622 various points to ensure that the design of a queue is not overrun, 623 and then the traffic SHOULD be given a low-delay queue (often using 624 priority, although it is asserted that a rate-based queue can do 625 this) to ensure that variation in delay is not an issue, to meet 626 application needs. 628 1.5.4 Class Selector (CS) 630 Class Selector, those DSCPs that end in zeros (xxx000), provide 631 support for historical codepoint definitions and PHB requirement. 632 The CS fields provide a limited backward compatibility with legacy 633 practice, as described in [RFC2474], Section 4. Backward 634 compatibility is addressed in two ways, 636 - First, there are per-hop behaviors that are already in widespread 637 use (e.g., those satisfying the IPv4 Precedence queuing 638 requirements specified in [RFC1812]), and 640 - this document will continue to permit their use in DS-compliant 641 networks. 643 In addition, there are some DSCPs that correspond to historical use 644 of the IP Precedence field, 646 - CS0 (000000) will remain 'Default Forwarding' (also know as 'Best 647 Effort') 649 - 11xxxx will remain for routing traffic 651 and will map to PHBs that meet the general requirements specified in 652 [RFC2474], Section 4.2.2.2. 654 No attempt is made to maintain backward compatibility with the "DTR" 655 or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in 656 [RFC0791] and [RFC1349]. 658 A DS-compliant network can be deployed exclusively by using one or 659 more CS-compliant PHB groups. Thus, for example, codepoint '011000' 660 would map to the same PHB as codepoint '011010'. 662 1.5.5 Admission Control 664 Admission control (including refusal when policy thresholds are 665 crossed) can ensure high-quality communication by ensuring the 666 availability of bandwidth to carry a load. Inelastic real-time 667 flows such as Voice over Internet Protocol (VoIP) (audio) or video 668 conferencing services can benefit from use of an admission control 669 mechanism, as generally the audio or video service is configured 670 with over-subscription, meaning that some users may not be able to 671 make a call during peak periods. 673 For VoIP (audio) service, a common approach is to use signaling 674 protocols such as SIP, H.323, H.248, MEGACO, along with Resource 675 Reservation Protocol (RSVP) to negotiate admittance and use of 676 network transport capabilities. When a user has been authorized to 677 send voice traffic, this admission procedure has verified that data 678 rates will be within the capacity of the network that it will use. 679 Many RTP voice and video payloads are inelastic and cannot react to 680 loss or delay in any substantive way. For these payload types, the 681 network needs to police at ingress to ensure that the voice traffic 682 stays within its negotiated bounds. Having thus assured a 683 predictable input rate, the network may use a priority queue to 684 ensure nominal delay and variation in delay. 686 1.5.5.1 Capacity Admitted (*-Admit) 688 This is a newer group of traffic types that started with RFC 5865 689 and the Voice-Admit service type. Voice-Admit is an EF class marking 690 but has capacity-admission always applied to it to ensure each of 691 these flows are managed through a network, though not necessarily on 692 an end-to-end basis. This depends on how many networks each flow 693 transits and the load on each transited network. There are a series 694 of new DSCPs proposed in [ID-DSCP], each specifying unique 695 characteristics necessitating a separate marking from what existing 696 before that document. 698 This document will import in four new '*-Admit' DSCPs from 699 [ID-DSCP], 2 others that are new but not capacity-admitted, one from 700 RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594. 701 This is discussed throughout the rest of this document. 703 2. Service Differentiation 705 There are practical limits on the level of service differentiation 706 that should be offered in the IP networks. We believe we have 707 defined a practical approach in delivering service differentiation 708 by defining different service classes that networks may choose to 709 support in order to provide the appropriate level of behaviors and 710 performance needed by current and future applications and services. 712 The defined structure for providing services allows several 713 applications having similar traffic characteristics and performance 714 requirements to be grouped into the same service class. This 715 approach provides a lot of flexibility in providing the appropriate 716 level of service differentiation for current and new, yet unknown 717 applications without introducing significant changes to routers or 718 network configurations when a new traffic type is added to the 719 network. 721 2.1 Service Classes 723 Traffic flowing in a network can be classified in many different 724 ways. We have chosen to divide it into two groupings, network 725 control and user/subscriber traffic. To provide service 726 differentiation, different service classes are defined in each 727 grouping. The network control traffic group can further be divided 728 into two service classes (see Section 3 for detailed definition of 729 each service class): 731 o "Network Control" for routing and network control function. 733 o "OAM" (Operations, Administration, and Management) for network 734 configuration and management functions. 736 The user/subscriber traffic group is broken down into ten service 737 classes to provide service differentiation for all the different 738 types of applications/services (see Section 4 for detailed 739 definition of each service class): 741 o Conversational service group consists of five service classes: 743 - Audio, which includes both 'admitted' and 'unadmitted' audio 744 service classes, is for non-one way (i.e., generally 745 bidirectional) audio media packets between human users of 746 smaller size and at a constant delivery rate. 748 - Hi-Res Video, which includes both 'admitted' and 'unadmitted' 749 Hi-Res Video service classes, is for video traffic from higher 750 end endpoints between human users necessitating different 751 treatment that from desktop or video phone endpoints. This has 752 a clearly business differentiation, and not a technical 753 differentiation - as both Hi-Res-Video and Video will be 754 treated similarly on the wire when no congestion occurs. 756 - Video, which includes both 'admitted' and 'unadmitted' video 757 service classes, is for video traffic from lower end endpoints 758 between human users necessitating different treatment that 759 from higher end (i.e., Telepresence) endpoints. This has a 760 clearly business differentiation, and not a technical 761 differentiation - as both Hi-Res-Video and Video will be 762 treated similarly on the wire when no congestion occurs. 764 o Conversational Signaling service class is for peer-to-peer and 765 client-server signaling and control functions using protocols 766 such as SIP, H.323, H.248, and Media Gateway Control Protocol 767 (MGCP). This traffic needs to not be starved on the network. 769 Editor's note: RFC 4594 had this DSCP marking as CS5, but with 770 clearly different characteristics (i.e., no 771 sensitivity to jitter or (unreasonable) delay), this 772 DSCP has been moved to a more appropriate (new) 773 value, defined in [ID-DSCP]. 775 o Real-Time Interactive, which includes both 'admitted' and 776 'unadmitted' Realtime-Interactive service class, is for 777 bidirectional variable rate inelastic applications that require 778 low jitter and loss and very low delay, such as interactive 779 gaming applications that use RTP/UDP streams for game control 780 commands, and Virtualized Desktop applications between the user 781 and content source, typically in a centralized data center. 783 o Multimedia Conferencing, which includes both 'admitted' and 784 'unadmitted' multimedia conferencing service class, is for 785 applications that require minimal delay, but not like those of 786 realtime application requirements. This service class can be 787 bursty in nature, as well as not transmit packets for some time. 788 Applications such as presentation data or collaborative 789 application sharing will use this service class. 791 o Multimedia Streaming, which includes both 'admitted' and 792 'unadmitted' multimedia streaming service class, is for one-way 793 bufferable streaming media applications such as Video on Demand 794 (VOD) and webcasts. 796 o Broadcast, which includes both 'admitted' and 'unadmitted' 797 broadcast service class, is for inelastic streaming media 798 applications that may be of constant or variable rate, requiring 799 low jitter and very low packet loss, such as broadcast TV and 800 live events, video surveillance, and security. 802 o Low-Latency Data service class is for data processing 803 applications such as client/server interactions or Instant 804 Messaging (IM) and Presence data. 806 o Conversational Signaling (A/V-Sig) service class is for all 807 signaling messages, whether in-band (i.e., along the data path) 808 or out-of-band (separate from the data path), for the purposes of 809 setting up, maintaining, managing and terminating bi- or 810 multi-directional realtime sessions. 812 o High-Throughput Data service class is for store and forward 813 applications such as FTP and billing record transfer. 815 o Standard service class, commonly called best effort (BE), is for 816 traffic that has not been identified as requiring differentiated 817 treatment. 819 o Low-Priority Data service class, which some could call the 820 scavenger class, is for packet flows where bandwidth assurance is 821 not required. 823 2.2 Categorization of User Oriented Service Classes 825 The ten defined user/subscriber service classes listed above can be 826 grouped into a small number of application categories. For some 827 application categories, it was felt that more than one service class 828 was needed to provide service differentiation within that category 829 due to the different traffic characteristic of the applications, 830 control function, and the required flow behavior. Figure 1 provides 831 a summary of service class grouping into four application categories. 833 Application Control Category 835 o The Conversational Signaling service class is intended to be used 836 to control applications or user endpoints. Examples of protocols 837 that would use this service class are SIP, XMPP or H.323 for 838 voice and/or video over IP services. User signaling flows have 839 similar performance requirements as Low-Latency Data, they 840 require a separate DSCP to be distinguished other traffic and 841 allow for a treatment that is unique. 843 Media-Oriented Category 845 Due to the vast number of new (in process of being deployed) and 846 already-in-use media-oriented services in IP networks, seven service 847 classes have been defined. 849 o Audio service class is intended for Voice-over-IP (VoIP) 850 services. It may also be used for other applications that meet 851 the defined traffic characteristics and performance requirements. 853 o Video service class is intended for Video over IP services. It 854 may also be used for other applications that meet the defined 855 traffic characteristics and performance requirements. 857 o Hi-Res service class is intended for higher end video services 858 that have the same traffic characteristics as the video service 859 class, but have a business requirement(s) to be treated 860 differently. One example of this is Telepresence video 861 applications. 863 o Realtime-Interactive service class is intended for inelastic 864 applications such as desktop virtualization applications and for 865 interactive gaming. 867 o Multimedia Conferencing service class is for everything about or 868 within video conferencing solutions that does not include the 869 voice or (human) video components. Several examples are 871 - the presentation data part of an IP conference (call). 873 - the application sharing part of an IP conference (call). 875 - the whiteboarding aspect of an IP conference (call). 877 Each of the above can be part of a lower end web-conferencing 878 application or part of a higher end Telepresence video 879 conference. Each also has the ability to reduce their 880 transmission rate on detection of congestion. These flows can 881 therefore be classified as rate adaptive and most often more 882 elastic than their voice and video counterparts. 884 o Broadcast Video service class is to be used for inelastic traffic 885 flows specifically with minimal buffering expected by the source 886 or destination, which are intended for broadcast HDTV service, as 887 well as for transport of live video (sports or concerts) and 888 audio events. 890 o Multimedia Streaming service class is to be used for elastic 891 multimedia traffic flows where buffering is expected. This is 892 the fundamental difference between the Broadcast and multimedia 893 streaming service classes. Multimedia streaming content is 894 typically stored before being transmitted. It is also buffered 895 at the receiving end before being played out. The buffering is 896 sufficiently large to accommodate any variation in transmission 897 rate that is encountered in the network. Multimedia 898 entertainment over IP delivery services that are being developed 899 can generate both elastic and inelastic traffic flows; therefore, 900 two service classes are defined to address this space, 901 respectively: Multimedia Streaming and Broadcast Video. 903 Data Category 905 The data category is divided into three service classes. 907 o Low-Latency Data for applications/services that require low delay 908 or latency for bursty but short-lived flows. 910 o High-Throughput Data for applications/services that require good 911 throughput for long-lived bursty flows. High Throughput and 912 Multimedia Steaming are close in their traffic flow 913 characteristics with High Throughput being a bit more bursty and 914 not as long-lived as Multimedia Streaming. 916 o Low-Priority Data for applications or services that can tolerate 917 short or long interruptions of packet flows. The Low-Priority 918 Data service class can be viewed as "don't care" to some degree. 920 Best-Effort Category 922 o All traffic that is not differentiated in the network falls into 923 this category and is mapped into the Standard service class. If 924 a packet is marked with a DSCP value that is not supported in the 925 network, it SHOULD be forwarded using the Standard service class. 927 Figure 1, below, provides a grouping of the defined user/subscriber 928 service classes into four categories, with indications of which ones 929 use an independent flow for signaling or control; type of flow 930 behavior (elastic, rate adaptive, or inelastic); and the last column 931 provides end user Class of Service (CoS) rating as defined in ITU-T 932 Recommendation G.1010. 934 +-----------------------------------------------------------------+ 935 | Application | Service | Signaled | Flow | G.1010 | 936 | Categories | Class | | Behavior | Rating | 937 |-------------+---------------+----------+-----------+------------| 938 | Application | A/V Sig | Not | Inelastic | Responsive | 939 | Control | |applicable| | | 940 |-------------+---------------+----------+-----------+------------| 941 | | Real-Time | Yes | Inelastic | Interactive| 942 | | Interactive | | | | 943 | |---------------+----------+-----------+------------| 944 | | Audio | Yes | Inelastic | Interactive| 945 | |---------------+----------+-----------+------------| 946 | | Video | Yes | Inelastic | Interactive| 947 | |---------------+----------+-----------+------------| 948 | | Hi-Res | Yes | Inelastic | Interactive| 949 | |---------------+----------+-----------+------------| 950 | Media- | Multimedia | Yes | Rate | Moderately | 951 | Oriented | Conferencing| | Adaptive | Interactive| 952 | |---------------+----------+-----------+------------| 953 | | Broadcast | Yes | Inelastic | Responsive | 954 | |---------------+----------+-----------+------------| 955 | | Multimedia | Yes | Elastic | Timely | 956 | | Streaming | | | | 957 |-------------+---------------+----------+-----------+------------| 958 | | Low-Latency | No | Elastic | Responsive | 959 | | Data | | | | 960 | |---------------+----------+-----------+------------| 961 | Data | High- | No | Elastic | Timely | 962 | |Throughput Data| | | | 963 | |---------------+----------+-----------+------------| 964 | | Low- | No | Elastic |Non-critical| 965 | | Priority Data | | | | 966 |-------------+---------------+----------+-----------+------------| 967 | Best Effort | Standard | Not Specified |Non-critical| 968 +-----------------------------------------------------------------+ 969 Figure 1. User/Subscriber Service Classes Grouping 971 Here is a short explanation of the end user CoS category as defined 972 in ITU-T Recommendation G.1010. User oriented traffic is divided 973 into four different categories, namely, interactive, responsive, 974 timely, and non-critical. An example of interactive traffic is 975 between two humans and is most sensitive to delay, loss, and jitter. 976 Another example of interactive traffic is between two servers where 977 very low delay and loss are needed. Responsive traffic is typically 978 between a human and a server but can also be between two servers. 979 Responsive traffic is less affected by jitter and can tolerate 980 longer delays than interactive traffic. Timely traffic is either 981 between servers or servers and humans and the delay tolerance is 982 significantly longer than responsive traffic. Non-critical traffic 983 is normally between servers/machines where delivery may be delay for 984 period of time. 986 2.3. Service Class Characteristics 988 This document specifies what network administrators are to expect 989 when configuring service classes identified by their differing 990 characteristics. Figure 2 identifies these service classes along 991 with their characteristics, as well as the tolerance to loss, delay 992 and jitter for each service class. Properly engineered networks to 993 these PHBs will achieve expected results. That said, not all of the 994 identified service classes are expected in each operator's network. 996 +-------------------------------------------------------------------+ 997 |Service Class | | Tolerance to | 998 | Name | Traffic Characteristics | Loss |Delay |Jitter| 999 |===============+==============================+======+======+======| 1000 | Network |Variable size packets, mostly | | | | 1001 | Control |inelastic short messages, but | Low | Low | Yes | 1002 | |traffic can also burst (BGP) | | | | 1003 |---------------+------------------------------+------+------+------| 1004 | Real-Time | Inelastic, mostly variable | Low | Very | Low | 1005 | Interactive | rate | | Low | | 1006 +---------------+------------------------------+------+------+------+ 1007 | | Fixed-size small packets, | Very | Very | Very | 1008 | Audio | inelastic | Low | Low | Low | 1009 | | | | | | 1010 +---------------+------------------------------+------+------+------+ 1011 | | Fixed-size small-large | Very | Very | Very | 1012 | Video | packets, inelastic | Low | Low | Low | 1013 | | | | | | 1014 +---------------+------------------------------+------+------+------+ 1015 | | Fixed-size small-large | Very | Very | Very | 1016 | Hi-Res A/V | packets, inelastic | Low | Low | Low | 1017 | | | | | | 1018 +---------------+------------------------------+------+------+------+ 1019 | Multimedia | Variable size packets, | Low | Low | Low | 1020 | Conferencing | constant transmit interval, | - | - | - | 1021 | | rate adaptive, reacts to loss|Medium|Medium|Medium| 1022 +---------------+------------------------------+------+------+------+ 1023 | Multimedia | Variable size packets, |Low - |Medium| High | 1024 | Streaming | elastic with variable rate |Medium| | | 1025 +---------------+------------------------------+------+------+------+ 1026 | Broadcast | Constant and variable rate, | Very |Medium| Low | 1027 | | inelastic, non-bursty flows | Low | | | 1028 +---------------+------------------------------+------+------+------+ 1029 | Low-Latency | Variable rate, bursty short- | Low |Low - | Yes | 1030 | Data | lived elastic flows | |Medium| | 1031 |---------------+------------------------------+------+------+------+ 1032 |Conversational | Variable size packets, some | Low | Low | Yes | 1033 | Signaling | what bursty short-lived flows| | | | 1034 |---------------+------------------------------+------+------+------+ 1035 | OAM | Variable size packets, | Low |Medium| Yes | 1036 | | elastic & inelastic flows | | | | 1037 |---------------+------------------------------+------+------+------+ 1038 | High- | Variable rate, bursty long- | Low |Medium| Yes | 1039 |Throughput Data| lived elastic flows | |- High| | 1040 |---------------+------------------------------+------+------+------+ 1041 | Standard | A bit of everything | Not Specified | 1042 |---------------+------------------------------+------+------+------+ 1043 | Low-Priority | Non-real-time and elastic | High | High | Yes | 1044 | Data | | | | | 1045 +-------------------------------------------------------------------+ 1047 Figure 2. Service Class Characteristics 1049 Notes for Figure 2: A "Yes" in the jitter-tolerant column implies 1050 that received data is buffered at the endpoint and that a moderate 1051 level of server or network-induced variation in delay is not 1052 expected to affect the application. Applications that use TCP or 1053 SCTP as a transport are generally good examples. Routing protocols 1054 and peer-to-peer signaling also fall in this class; although loss 1055 can create problems in setting up calls, a moderate level of jitter 1056 merely makes call placement a little less predictable in duration. 1058 Service classes indicate the required traffic forwarding treatment 1059 in order to meet user, application, and/or network expectations. 1060 Section 3 defines the service classes that MAY be used for 1061 forwarding network control traffic, and Section 4 defines the 1062 service classes that MAY be used for forwarding user oriented 1063 traffic with examples of intended application types mapped into each 1064 service class. Note that the application types are only examples 1065 and are not meant to be all-inclusive or prescriptive. Also, note 1066 that the service class naming or ordering does not imply any 1067 priority ordering. They are simply reference names that are used in 1068 this document with associated QoS behaviors that are optimized for 1069 the particular application types they support. Network 1070 administrators MAY choose to assign different service class names to 1071 the service classes that they will support. Figure 3 defines the 1072 RECOMMENDED relationship between service classes and DS codepoint 1073 assignment with application examples. It is RECOMMENDED that this 1074 relationship be preserved end to end. 1076 +------------------------------------------------------------------+ 1077 | Service | DSCP | DSCP | Application | 1078 | Class Name | Name | Value | Examples | 1079 |===============+=========+=============+==========================| 1080 |Network Control| CS6&CS7 | 11xxxx | Network routing | 1081 |---------------+---------+-------------+--------------------------| 1082 | Real-Time | CS5, | 101000, | Remote/Virtual Desktop | 1083 | Interactive |CS5-Admit| 101001 | and Interactive gaming | 1084 |---------------+---------+-------------+--------------------------| 1085 | Audio | EF | 101110 | Voice bearer | 1086 | |Voice-Admit| 101100 | | 1087 |---------------+---------+-------------+--------------------------| 1088 | Hi-Res A/V | CS4, | 100000, | Conversational Hi-Res | 1089 | |CS4-Admit| 100001 | Audio/Video bearer | 1090 |---------------+---------+-------------+--------------------------| 1091 | Video |AF41,AF42|100010,100100| Audio/Video conferencing | 1092 | | AF43 | 100110 | bearer | 1093 |---------------+---------+-------------+--------------------------| 1094 | Multimedia | MC, | 011101, | Presentation Data and | 1095 | Conferencing | MC-Admit| 100101 | App Sharing/Whiteboarding| 1096 |---------------+---------+-------------+--------------------------| 1097 | Multimedia |AF31,AF32|011010,011100| Streaming video and | 1098 | Streaming | AF33 | 011110 | audio on demand | 1099 |---------------+---------+-------------+--------------------------| 1100 | Broadcast | CS3, | 011000, | Broadcast TV, live events| 1101 | |CS3-Admit| 011001 | & video surveillance | 1102 |---------------+---------+-------------+--------------------------| 1103 | Low-Latency |AF21,AF22|010010,010100|Client/server trans., Web-| 1104 | Data | AF23 | 010110 |based ordering, IM/Pres | 1105 |---------------+---------+-------------+--------------------------| 1106 |Conversational | A/V-Sig | 010001 | Conversational signaling | 1107 | Signaling | | | | 1108 |---------------+---------+-------------+--------------------------| 1109 | OAM | CS2 | 010000 | OAM&P | 1110 |---------------+---------+-------------+--------------------------| 1111 |High-Throughput|AF11,AF12|001010,001100| Store and forward | 1112 | Data | AF13 | 001110 | applications | 1113 |---------------+---------+-------------+--------------------------| 1114 | Low-Priority | CS1 | 001000 | Any flow that has no BW | 1115 | Data | | | assurance | 1116 |------------------------------------------------------------------| 1117 | Best Effort | CS0 | 000000 | Undifferentiated | 1118 | | | | applications | 1119 +---------------+---------+-------------+--------------------------+ 1121 Figure 3. DSCP to Service Class Mapping 1123 Notes for Figure 3: 1125 o Default Forwarding (DF) and Class Selector 0 (CS0) (i.e., Best 1126 Effort) provide equivalent behavior and use the same DS 1127 codepoint, '000000'. 1129 o RFC 2474 identifies any DSCP with a value of 11xxxxx to be for 1130 network control. This remains true, while it removes 12 DSCPs 1131 from the overall pool of 64 available DSCP values (the 4 that are 1132 x11 from this group are within pool 2 of RFC 2474, and remain as 1133 only experimentally assignable/useable). 1135 o All PHB names that say "-Admit" are to be used only when a 1136 capacity-admission protocol is utilized for that or each traffic 1137 flow. 1139 Changes from table 3 of RFC 4594 are as follows: 1141 o The old term "Signaling" was using CS5 (101000), now is 1142 exclusively for the "Conversational Signaling" service group 1143 using the DSCP name of "A/V-Sig" (010001), which is newly defined 1144 in [ID-DSCP]. This is because CS5 aggregates into the 101xxx 1145 aggregate when using layer 2 technologies such as 802.3 Ethernet, 1146 802.11 Wireless Ethernet MPLS, etc - each of which only have 3 1147 bits to mark with. A traffic type that can have very large 1148 packets and is not delay sensitive (within reason) is not 1149 appropriate for have a 101xxx marking. A REQUIRED behavior for 1150 this PHB is that it not be starved in any node. 1152 o "Conversational" is a new term to include all interactive audio 1153 and video. The Conversational service group consists of the audio 1154 service class, the video service class and the new Hi-Res service 1155 class. 1157 o "Audio" obsoletes the term "Telephony", which has generally not 1158 retained the "video" aspect within the IETF, where video is still 1159 commonly called out as a separate thing. Audio retains the 1160 nonadmitted traffic PHB of EF (101110), while capacity-admitted 1161 audio has been added via the RFC 5865 defined PHB Voice-Admit. 1163 o "Video" now is AF4x, with AF41 specifically for capacity-admitted 1164 video traffic, while AF42 and AF43 are nonadmitted video traffic. 1166 o "Hi-Res A/V", part of the Conversational service group, is 1167 created by [ID-DSCP] for an additional business differentiation 1168 interactive video marking for higher end traffic. It is within 1169 the 100xxx as CS4 (for nonadmitted traffic) and CS4-Admit 1170 (100001) (for capacity-admitted traffic). 1172 o "Realtime Interactive" is now using CS5 (for nonadmitted 1173 traffic), but adds a capacity-admitted DSCP CS5-Admit (101001). 1175 o "Multimedia Conferencing" is no longer using the AF4x DSCPs, 1176 rather it will use the new PHB MC (100101) (for 1177 capacity-admitted) and MC-Admit (011101) (for nonadmitted 1178 traffic). 1180 o "Multimedia Streaming" retains using AF3x, however, AF31 is now 1181 used for capacity-admitted traffic, while AF32/33 are 1182 nonadmitted. 1184 o "Broadcast" replaces "Broadcast Video" using CS3 (for nonadmitted 1185 traffic), and adds a capacity-admitted PHB CS3-Admit (011001). 1187 It is expected that network administrators will base their choice of 1188 the service classes that they will support on their need. 1190 Figure 4 provides a summary of DiffServ CoS mechanisms that MUST be 1191 used for the defined service classes that are further detailed in 1192 Sections 3 and 4 of this document. According to what 1193 applications/services need to be differentiated, network 1194 administrators MAY choose the service class(es) that need to be 1195 supported in their network. 1197 +-----------------------------------------------------------------+ 1198 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| 1199 | Class | | DS Edge | Used | | | 1200 |===============+=======+===================+=======+========+====| 1201 |Network Control|CS6/CS7| See Section 3.1 |RFC2474| Rate | Yes| 1202 |---------------+-------+-------------------+-------+--------+----| 1203 | Real-Time | CS5, |Police using sr+bs |RFC2474| Rate | No | 1204 | Interactive | CS5- | | | | | 1205 | | Admit*| |[ID-DSCP]| | | 1206 |---------------+-------+-------------------+-------+--------+----| 1207 | | EF, |Police using sr+bs |RFC3246|Priority| No | 1208 | Audio |Voice- | | | | | 1209 | | Admit*| |RFC5865| | | 1210 |---------------+-------+-------------------+-------+--------+----| 1211 | | CS4, |Police using sr+bs |RFC2474|Priority| No | 1212 | Hi-Res A/V | CS4- | | | | | 1213 | | Admit*| |[ID-DSCP]| | | 1214 |---------------+-------+-------------------+-------+--------+----| 1215 | | AF41*,| Using two-rate, | | | Yes| 1216 | Video | AF42 |three-color marker |RFC2597| Rate | per| 1217 | | AF43 | (such as RFC 2698)| | |DSCP| 1218 |---------------+-------+-------------------+-------+--------+----| 1219 | Multimedia | MC, |Police using sr+bs|[ID-DSCP]| Rate | No | 1220 | Conferencing | MC- | | | | | 1221 | | Admit*| |[ID-DSCP]| | | 1222 |---------------+-------+-------------------+-------+--------+----| 1223 | Multimedia | AF31*,| Using two-rate, | | | Yes| 1224 | Streaming | AF32 |three-color marker |RFC2597| Rate | per| 1225 | | AF33 | (such as RFC 2698)| | |DSCP| 1226 |---------------+-------+-------------------+-------+--------+----| 1227 | Broadcast | CS3, |Police using sr+bs |RFC2474| Rate | No | 1228 | | CS3- | | | | | 1229 | | Admit*| |[ID-DSCP]| | | 1230 |---------------+-------+-------------------+-------+--------+----| 1231 | Low- | AF21 | Using single-rate,| | | Yes| 1232 | Latency | AF22 |three-color marker |RFC2597| Rate | per| 1233 | Data | AF23 | (such as RFC 2697)| | |DSCP| 1234 |---------------+-------+-------------------+-------+--------+----| 1235 |Conversational |AV-Sig |Police using sr+bs|[ID-DSCP]| Rate | No | 1236 | Signaling | | | | | | 1237 |---------------+-------+-------------------+-------+--------+----| 1238 | OAM | CS2 |Police using sr+bs |RFC2474| Rate | Yes| 1239 |---------------+-------+-------------------+-------+--------+----| 1240 | High- | AF11 | Using two-rate, | | | Yes| 1241 | Throughput | AF12 |three-color marker |RFC2597| Rate | per| 1242 | Data | AF13 | (such as RFC 2698)| | |DSCP| 1243 |---------------+-------+-------------------+-------+--------+----| 1244 | Standard | DF | Not applicable |RFC2474| Rate | Yes| 1245 |---------------+-------+-------------------+-------+--------+----| 1246 | Low-Priority | CS1 | Not applicable |RFC3662| Rate | Yes| 1247 | Data | | | | | | 1248 |---------------+-------+-------------------+-------+--------+----| 1250 Figure 4. Summary of CoS Mechanisms Used for Each Service Class 1252 * denotes each DSCP identified for capacity-admission traffic only. 1254 Notes for Figure 4: 1256 o Conditioning at DS edge means that traffic conditioning is 1257 performed at the edge of the DiffServ network where untrusted 1258 user devices are connected to two different administrative 1259 DiffServ networks. 1261 o "sr+bs" represents a policing mechanism that provides single rate 1262 with burst size control. 1264 o The single-rate, three-color marker (srTCM) behavior SHOULD be 1265 equivalent to RFC 2697, and the two-rate, three-color marker 1266 (trTCM) behavior SHOULD be equivalent to RFC 2698. 1268 o The PHB for Realtime-Interactive service class SHOULD be 1269 configured to provide high bandwidth assurance. It MAY be 1270 configured as another EF PHB (one capacity-admitted and one 1271 non-capacity-admitted, if both are to be used) that uses relaxed 1272 performance parameters and a rate scheduler. 1274 o The PHB for Multimedia Conferencing service class SHOULD be 1275 configured to provide high bandwidth assurance. It MAY be 1276 configured as another EF PHB (one capacity-admitted and one 1277 non-capacity-admitted, if both are to be used) that uses relaxed 1278 performance parameters and a rate scheduler. 1280 o The PHB for Broadcast service class SHOULD be configured to 1281 provide high bandwidth assurance. It MAY be configured as 1282 another EF PHB (one capacity-admitted and one 1283 non-capacity-admitted, if both are to be used) that uses relaxed 1284 performance parameters and a rate scheduler. 1286 3. Network Control Traffic 1288 Network control traffic is defined as packet flows that are 1289 essential for stable operation of an administered network, as well 1290 as the information exchanged between neighboring networks across a 1291 peering point where SLAs are in place. Network control traffic is 1292 different from user application control (signaling) that may be 1293 generated by some applications or services. Network control traffic 1294 is mostly between routers and network nodes (e.g., routing or mgmt 1295 protocols) that are used for operating, administering, controlling, 1296 or managing whole networks, network parts or just network segments. 1297 Network Control Traffic may be split into two service classes, i.e., 1298 Network Control and OAM. 1300 3.1. Current Practice in the Internet 1302 Based on today's routing protocols and network control procedures 1303 that are used in the Internet, we have determined that CS6 DSCP 1304 value SHOULD be used for routing and control and that CS7 DSCP value 1305 SHOULD be reserved for future use, specifically if needed for future 1306 routing or control protocols. Network administrators MAY use a 1307 Local/Experimental DSCP, any value that contains 11xx11; therefore, 1308 they may use a locally defined service class within their network to 1309 further differentiate their routing and control traffic. 1311 RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets: 1313 o Drop or remark 111xxx packets at ingress to DiffServ network 1314 domain. 1316 o 111xxx marked packets SHOULD NOT be sent across peering points. 1317 Exchange of control information across peering points SHOULD be 1318 done using CS6 DSCP and the Network Control service class. 1320 o any internally defined 11xxx1 values, valid within that network 1321 domain, be remarked to CS6 upon egress at network peering points. 1323 3.2. Network Control Service Class 1325 The Network Control service class is used for transmitting packets 1326 between network devices (routers) that require control (routing) 1327 information to be exchanged between similar devices within the 1328 administrative domain, as well as across a peering point between 1329 adjacent administrative domains. Traffic transmitted in this 1330 service class is very important as it keeps the network operational, 1331 and it needs to be forwarded in a timely manner. 1333 The Network Control service class SHOULD be configured using the 1334 DiffServ CS6 PHB, defined in [RFC2474]. This service class MUST be 1335 configured so that the traffic receives a minimum bandwidth 1336 guarantee, to ensure that the packets always receive timely service. 1337 The configured forwarding resources for Network Control service 1338 class MUST be such that the probability of packet drop under peak 1339 load is very low. The Network Control service class SHOULD be 1340 configured to use a Rate Queuing system such as defined in Section 1341 1.4.1.2 of this document. 1343 The following are examples of protocols and applications that MUST 1344 use the Network Control service class if present in a network: 1346 o Routing packet flows: OSPF, BGP, ISIS, RIP. 1348 o Control information exchange within and between different 1349 administrative domains across a peering point where SLAs are in 1350 place. 1352 o LSP setup using CR-LDP and RSVP-TE. 1354 The following protocols and applications MUST NOT use the Network 1355 Control service class: 1357 o User oriented traffic is not allowed to use this service class. 1358 By user oriented traffic, we mean packet flows that originate 1359 from user-controlled end points that are connected to the 1360 network. 1362 o even if originating from a server or a device acting on behalf 1363 of a user or endpoint, 1365 o even if it is application or in-band signaling to establish a 1366 connection wholly within a single network or across peering 1367 points of/to adjacent networks (e.g., creating a tunnel such 1368 as a VPN, or data path control signaling). 1370 The following are traffic characteristics of packet flows in the 1371 Network Control service class: 1373 o Mostly messages sent between routers and network servers. 1375 o Variable size packets, normally one packet at a time, but traffic 1376 can also burst (BGP, OSPF, etc). 1378 o IGMP, hen is used only for the normal multicast routing purpose. 1380 The REQUIRED DSCP marking is CS6 (Class Selector 6). 1382 RECOMMENDED Network Edge Conditioning: 1384 o At peering points (between two DiffServ networks) where SLAs are 1385 in place, CS6 marked packets MUST be policed, e.g., using a 1386 single rate with burst size (sr+bs) token bucket policer to keep 1387 the CS6 marked packet flows to within the traffic rate specified 1388 in the SLA. 1390 o CS6 marked packet flows from untrusted sources (for example, end 1391 user devices) MUST be dropped or remarked at ingress to the 1392 DiffServ network. What a network admin remarks this user oriented 1393 traffic to if a matter of local policy, and inspection of the 1394 packets can determine which application is used for proper 1395 marking to a more appropriate DSCP, such as from table 3. of this 1396 document. 1398 o Packets from users/subscribers are not permitted access to the 1399 Network Control service classes. 1401 The fundamental service offered to the Network Control service class 1402 is enhanced best-effort service with high bandwidth assurance. 1403 Since this service class is used to forward both elastic and 1404 inelastic flows, the service SHOULD be engineered so that the Active 1405 Queue Management (AQM) [RFC2309] is applied to CS6 marked packets. 1407 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1408 specifies a target queue depth, and the max-threshold specifies the 1409 queue depth above which all traffic is dropped or ECN marked. Thus, 1410 in this service class, the following inequality should hold in queue 1411 configurations: 1413 o min-threshold CS6 < max-threshold CS6 1415 o max-threshold CS6 <= memory assigned to the queue 1417 Note: Many other AQM algorithms exist and are used; they should be 1418 configured to achieve a similar result. 1420 3.3. OAM Service Class 1422 The OAM (Operations, Administration, and Management) service class 1423 is RECOMMENDED for OAM&P (Operations, Administration, and Management 1424 and Provisioning) using protocols such as Simple Network Management 1425 Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet, 1426 and Common Open Policy Service (COPS). Applications using this 1427 service class require a low packet loss but are relatively not 1428 sensitive to delay. This service class is configured to provide 1429 good packet delivery for intermittent flows. 1431 The OAM service class SHOULD use the Class Selector (CS) PHB defined 1432 in [RFC2474]. This service class SHOULD be configured to provide a 1433 minimum bandwidth assurance for CS2 marked packets to ensure that 1434 they get forwarded. The OAM service class SHOULD be configured to 1435 use a Rate Queuing system such as defined in Section 1.4.1.2 of this 1436 document. 1438 The following applications SHOULD use the OAM service class: 1440 o Provisioning and configuration of network elements. 1442 o Performance monitoring of network elements. 1444 o Any network operational alarms. 1446 The following are traffic characteristics: 1448 o Variable size packets. 1450 o Intermittent traffic flows. 1452 o Traffic may burst at times. 1454 o Both elastic and inelastic flows. 1456 o Traffic not sensitive to delays. 1458 RECOMMENDED DSCP marking: 1460 o All flows in this service class are marked with CS2 (Class 1461 Selector 2). 1463 Applications or IP end points SHOULD pre-mark their packets with CS2 1464 DSCP value. If the end point is not capable of setting the DSCP 1465 value, then the router topologically closest to the end point SHOULD 1466 perform Multifield (MF) Classification, as defined in [RFC2475]. 1468 RECOMMENDED conditioning performed at DiffServ network edge: 1470 o Packet flow marking (DSCP setting) from untrusted sources (end 1471 user devices) SHOULD be verified at ingress to DiffServ network 1472 using Multifield (MF) Classification methods, defined in 1473 [RFC2475]. 1475 o Packet flows from untrusted sources (end user devices) SHOULD be 1476 policed at ingress to DiffServ network, e.g., using single rate 1477 with burst size token bucket policer to ensure that the traffic 1478 stays within its negotiated or engineered bounds. 1480 o Packet flows from trusted sources (routers inside administered 1481 network) MAY not require policing. 1483 o Normally OAM&P CS2 marked packet flows are not allowed to flow 1484 across peering points. If that is the case, then CS2 marked 1485 packets SHOULD be policed (dropped) at both egress and ingress 1486 peering interfaces. 1488 The fundamental service offered to "OAM" traffic is enhanced 1489 best-effort service with controlled rate. The service SHOULD be 1490 engineered so that CS2 marked packet flows have sufficient bandwidth 1491 in the network to provide high assurance of delivery. Since this 1492 service class is used to forward both elastic and inelastic flows, 1493 the service SHOULD be engineered so that Active Queue Management 1494 [RFC2309] is applied to CS2 marked packets. 1496 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1497 specifies a target queue depth for each DSCP, and the max-threshold 1498 specifies the queue depth above which all traffic with such a DSCP 1499 is dropped or ECN marked. Thus, in this service class, the 1500 following inequality should hold in queue configurations: 1502 o min-threshold CS2 < max-threshold CS2 1504 o max-threshold CS2 <= memory assigned to the queue 1506 Note: Many other AQM algorithms exist and are used; they should be 1507 configured to achieve a similar result. 1509 4. User Oriented Traffic 1511 User oriented traffic is defined as packet flows between different 1512 users or subscribers, or from servers/nodes on behalf of a user. It 1513 is the traffic that is sent to or from end-terminals and that 1514 supports a very wide variety of applications and services, to 1515 include traffic about a user or application that assists a user 1516 communicate. User oriented traffic can be classified in many 1517 different ways. What we have articulated throughout this document is 1518 a series of non-exhaustive list of categories for classifying user 1519 oriented traffic. We differentiated user oriented traffic that is 1520 real-time versus non-real-time, elastic or rate-adaptive versus 1521 inelastic, sensitive versus insensitive to loss as well as 1522 considering whether the traffic is interactive vs. one way 1523 communication, its responsiveness, whether it requires timely 1524 delivery, and critical verses non-critical. In the final analysis, 1525 we used all of the above for service differentiation, mapping 1526 application types that seemed to have different sets of performance 1527 sensitivities, and requirements to different service classes. 1529 Network administrators can categorize their applications according 1530 to the type of behavior that they require and MAY choose to support 1531 all or a subset of the defined service classes. At the same time, 1532 we include a public facing default DSCP value, with its associated 1533 PHB, that is expected for each traffic type to ensure common or 1534 pervasive performance. Figure 3 provides some common applications 1535 and the forwarding service classes that best support them, based on 1536 their performance requirements. 1538 4.1. Conversational Service Class Group 1540 The Conversational Service Class Group consists of 3 different 1541 service classes, audio, video, and Hi-Res. We are describing the 1542 media sample, or bearer, packets for applications (e.g., RTP from 1543 [RFC3550]) that require bi-directional real-time, very low delay, 1544 very low jitter, and very low packet loss for relatively 1545 constant-rate traffic sources (inelastic traffic sources). It is 1546 RECOMMENDED that RTCP feedback use the same service class and be 1547 marked with the same DSCP as the bearer traffic for that (audio 1548 and/or video) call. This ensures comparable treatment within the 1549 network between endpoints. 1551 The signaling to set-up these bearer flows is part of the 1552 Conversational Signaling service group that will be discussed later 1553 in Section 4. The following 3 subsections will detail what is 1554 expected within each bearer service class. 1556 4.1.1 Audio Service Class 1558 This service class MUST be used for IP Audio service. 1560 The fundamental service offered to traffic in the Audio service 1561 class is minimum jitter, delay, and packet loss service up to a 1562 specified upper bound. There are two PHBs, both EF based, for the 1563 Audio service class: 1565 Nonadmitted Audio traffic - MUST use the EF DSCP [RFC3246], and 1566 is for traffic that has not had any capacity admission 1567 signaling performed for that flow or session. 1569 Capacity-Admitted Audio traffic - MUST use the Voice-Admit DSCP 1570 [RFC5865], and is for traffic that has had any capacity 1571 admission signaling performed for that flow or session, e.g., 1572 RSVP [RFC2205] or NSIS [RFC4080]. 1574 The capacity-admitted Audio traffic operation is similar to an ATM 1575 CBR service, which has guaranteed bandwidth and which, if it stays 1576 within the negotiated rate, experiences nominal delay and no loss. 1578 The nonadmitted Audio traffic, on the other hand, has had no such 1579 explicit guarantee, but has a favorable PHB ensuring high 1580 probability of delivery as well as nominal delay and no loss - 1581 implicitly assuming there is not too much like marked traffic 1582 between users within a flow. 1584 There are two typical scenarios in which audio calls are 1585 established, on the public open Internet using protocols such as 1586 SIP, XMPP or H.323, or in more managed networks like enterprises or 1587 certain service providers which offer a audio service with some 1588 feature benefits and take part in the call signaling. These SPs or 1589 enterprises also use protocols like SIP, XMPP, H.323, but also use 1590 H.248/MEGACO and MGCP. 1592 On the open Internet, typically there is no SP actively involved in 1593 the session set-up of calls, and therefore no servers providing 1594 assistance or features to help one user contact another user. Often, 1595 this traffic is marked or remarked with the DF (i.e., Best Effort) 1596 DSCP. 1598 In more managed networks in which one of more operators have active 1599 servers aiding the audio call set-up, where DiffServ can be used and 1600 preserved to differentiate traffic, networks are offering a service, 1601 therefore need to do some, or a lot of engineering to ensure that 1602 capacity offered to one or more applications does not exceed the 1603 load to the network. Otherwise, the operator will have unhappy 1604 users, at least for that application's usage. This is true for any 1605 application, but is especially true for inelastic applications in 1606 which the application is rigid in its delivery requirements. Audio 1607 bearer traffic is typically such an application, video is another 1608 such application, but we will get to video in the next subsection. 1610 When a user in a managed network has been authorized to send Audio 1611 traffic (i.e., call initiation via the operator's servers was not 1612 rejected), the call admission procedure should have verified that 1613 the newly admitted flow will be within the capacity of the Audio 1614 service class forwarding capability in the network. Capacity 1615 verification is a non-trivial thing, and can either be implicitly 1616 assumed by the call server(s) based on the operator's network 1617 design, or it can be explicitly signaled from an in-data-path 1618 signaling mechanism that verifies the capacity is available now for 1619 this call, for each call made within that network. In the latter 1620 case, those that do not have verifiable network capacity along the 1621 data path are rejected. An in between means method is for call 1622 servers to count calls between two or more endpoints. By 1623 topologically understanding where the caller and called party is and 1624 have configured a known maximum it will allow between the two 1625 locations. This is especially true over WAN links that have far less 1626 capacity than LAN links or core parts of a network. Network 1627 operators will need to understand the topology between any two 1628 callers to ensure the appropriate amount of bandwidth is available 1629 for an expected number of simultaneous audio calls. 1631 Once more than one bandwidth amount can be used for audio calls, for 1632 example - by allowing more than one codec with different bandwidths 1633 per codec for such calls, network engineering becomes more 1634 difficult. Since the inelastic nature of RTP payloads from this 1635 class do not react well to loss or significant delay in any 1636 substantive way, the Audio service class MUST forward packets as 1637 soon as possible. 1639 The Audio service class that does not have capacity admission 1640 performed in the data path MUST use the Expedited Forwarding (EF) 1641 PHB, as defined in [RFC3246], so that all packets are forwarded 1642 quickly. The Audio service class that does have capacity admission 1643 performed in the data path MUST use the Voice-Admit PHB, as defined 1644 in [RFC5865], so that all packets are forwarded quickly. The Audio 1645 service class SHOULD be configured to use a Priority Queuing system 1646 such as that defined in Section 1.4.1.1 of this document. 1648 The following applications SHOULD use the Audio service class: 1650 o VoIP (G.711, G.729, iLBC and other audio codecs). 1652 o Voice-band data over IP (modem, fax). 1654 o T.38 fax over IP. 1656 o Circuit emulation over IP, virtual wire, etc. 1658 o IP Virtual Private Network (VPN) service that specifies 1659 single-rate, mean network delay that is slightly longer then 1660 network propagation delay, very low jitter, and a very low packet 1661 loss. 1663 The following are traffic characteristics: 1665 o Mostly fixed-size packets for VoIP (30, 60, 70, 120 or 200 bytes 1666 in size). 1668 o Packets emitted at constant time intervals. 1670 o Admission control of new flows is provided by Audio call server, 1671 media gateway, gatekeeper, edge router, end terminal, access node 1672 or in-data-path signaling that provides flow admission control 1673 function. 1675 Applications or IP end points SHOULD pre-mark their packets with EF 1676 or Voice-Admit DSCP value, whichever is appropriate. If the end 1677 point is not capable of setting the DSCP value, then the router 1678 topologically closest to the end point SHOULD perform Multifield 1679 (MF) Classification, as defined in [RFC2475]. 1681 The RECOMMENDED DSCP marking is EF for nonadmitted audio flows, and 1682 Voice-Admit for capacity-admitted flows for the following 1683 applications: 1685 o VoIP (G.711, G.729 and other codecs). 1687 o Voice-band data over IP (modem and fax). 1689 o T.38 fax over IP. 1691 o Circuit emulation over IP, virtual wire, etc. 1693 RECOMMENDED Network Edge Conditioning: 1695 o Packet flow marking (DSCP setting) from untrusted sources (end 1696 user devices) SHOULD be verified at ingress to DiffServ network 1697 using Multifield (MF) Classification methods, defined in 1698 [RFC2475]. If untrusted, the network edge SHOULD know if 1699 capacity-admission has been applied, since the edge router will 1700 have taken part in the admission signaling; therefore will know 1701 whether EF or Voice-Admit is the proper marking for that flow. 1703 o Packet flows from untrusted sources (end user devices) SHOULD be 1704 policed at ingress to DiffServ network, e.g., using single rate 1705 with burst size token bucket policer to ensure that the Audio 1706 traffic stays within its negotiated bounds. 1708 o Policing is OPTIONAL for packet flows from trusted sources whose 1709 behavior is ensured via other means (e.g., administrative 1710 controls on those systems). 1712 o Policing of Audio packet flows across peering points where SLA is 1713 in place is OPTIONAL as Audio traffic will be controlled by 1714 admission control mechanism between peering points. 1716 The fundamental service offered to "Audio" traffic is enhanced 1717 best-effort service with controlled rate, very low delay, and very 1718 low loss. The service MUST be engineered so that EF marked packet 1719 flows have sufficient bandwidth in the network to provide guaranteed 1720 delivery. Otherwise, the service will have in place an explicit 1721 capacity-admission signaling protocol such as RSVP or NSIS and thus 1722 mark the packets within the flow as Voice-Admit. Normally traffic in 1723 this service class does not respond dynamically to packet loss. As 1724 such, Active Queue Management [RFC2309] SHOULD NOT be applied to EF 1725 marked packet flows. 1727 4.1.2 Video Service Class 1729 The Video service class is for bidirectional applications that 1730 require real-time service for both constant and rate-adaptive 1731 traffic. SIP and H.323/V2 (and later) versions of video 1732 conferencing equipment with constant and dynamic bandwidth 1733 adjustment are such applications. The traffic sources in this 1734 service class either have a fixed bandwidth requirement (e.g., 1735 MPEG2, etc.), or have the ability to dynamically change their 1736 transmission rate (e.g., MPEG4/H.264, etc.) based on feedback from 1737 the receiver. This feedback SHOULD be accomplished using RTCP 1738 [RFC3550]. One approach for this downspeeding has the receiver 1739 detect packet loss, thus signaling in an RTCP message to the source 1740 the indication of lost (or delayed or out of order) packets in 1741 transit. When necessary the source then selects a lower rate 1742 encoding codec. When available, the source merely sends less data, 1743 resulting in lower resolution of the same visual display. 1745 The Video service class is not for video downloads, webcasts, or 1746 single directional video or audio/video traffic of any kind. It is 1747 for human-to-human visual interaction between two users, or more if 1748 an MTP is used. 1750 Typical video conferencing configurations negotiate the setup of 1751 audio/video session using protocols such as SIP and H.323. Just as 1752 with networks that have audio traversing them, video typically 1753 traverses the same two types of networks: the open big "I" Internet, 1754 in which most every type of traffic is best effort (DF), or on a 1755 more managed network such as an enterprise or SP's managed network 1756 in which servers within either network take part in the call 1757 signaling, thereby offering the video service. 1759 When a user in a managed network has been authorized to send video 1760 traffic (i.e., call initiation via the operator's servers was not 1761 rejected), the call admission procedure should have verified that 1762 the newly admitted flow will be within the capacity of the video 1763 service class forwarding capability in the network. Capacity 1764 verification is a non-trivial thing, and can either be implicitly 1765 assumed by the call server(s) based on the operator's network 1766 design, or it can be explicitly signaled from an in-data-path 1767 signaling mechanism that verifies the capacity is available now for 1768 this call, for each call made within that network. In the latter 1769 case, those that do not have verifiable network capacity along the 1770 data path are rejected. An in between means method is for call 1771 servers to count calls between two or more endpoints. By 1772 topologically understanding where the caller and called party is and 1773 have configured a known maximum it will allow between the two 1774 locations. Video is larger in bandwidth than audio, and the 1775 difference can be significant. For example, for a single G.711 audio 1776 call that is 80kbps, an associated video bandwidth for the same 1777 call can easily be 4Mbps. This is especially true over WAN links 1778 that have far less capacity than LAN links or core parts of a 1779 network. Network operators will need to understand the topology 1780 between any two callers to ensure the appropriate amount of 1781 bandwidth is available for an expected number of simultaneous video 1782 and/or audio/video calls. 1784 Note that it is OPTIONALLY the case in these networks that the 1785 accompanying audio for the video call will be marked as the video is 1786 marked (i.e., using the same DSCP), but not always. One reason this 1787 has been done is for lip-sync. 1789 The Video service class MUST use the Assured Forwarding (AF) PHB, 1790 defined in [RFC2597]. This service class MUST be configured to 1791 provide a bandwidth assurance for AF41, AF42, and AF43 marked 1792 packets to ensure that they get forwarded. The Video service class 1793 SHOULD be configured to use a Rate Queuing system for AF42 and AF43 1794 traffic flows, such as that defined in Section 1.4.1.2 of this 1795 document. However, AF41 MUST be designated as the DSCP for use when 1796 capacity-admission signaling has been used, such as RSVP or NSIS, to 1797 guarantee delivery through the network. AF42 and AF43 will be used 1798 for non-admitted video calls, as well as overflows from AF41 sources 1799 that send more packets than they have negotiated bandwidth for that 1800 call. 1802 The following applications MUST use the Video service class: 1804 o SIP and H.323/V2 (and later) versions of video conferencing 1805 applications (interactive video). 1807 o Video conferencing applications with rate control or traffic 1808 content importance marking. 1810 o Interactive, time-critical, and mission-critical applications. 1812 NOTE with regards to the above bullet: this usage SHOULD be 1813 minimized, else the video traffic will suffer - unless this 1814 is engineered into the topology. 1816 The following are traffic characteristics: 1818 o Variable size packets (i.e., small to large in size). 1820 o The higher the resolution or change rate between each image, the 1821 higher the duration of large packets. 1823 o Usually constant inter-packet time interval. 1825 o Can be Variable rate in transmission. 1827 o Source is capable of reducing its transmission rate based on 1828 being told receiver is detecting packet loss (e.g., via RTCP). 1830 Applications or IP end points SHOULD pre-mark their packets with 1831 DSCP values as shown below. If the end point is not capable of 1832 setting the DSCP value, then the router topologically closest to the 1833 end point SHOULD perform Multifield (MF) Classification, as defined 1834 in [RFC2475] and mark all packets as AF4x. Note: In this case, the 1835 two-rate, three-color marker will be configured to operate in 1836 Color-Blind mode. 1838 Mandatory DSCP marking when performed by router closest to source: 1840 o AF41 = up to specified rate "A", which is dedicated to non-Hi-Res 1841 capacity-admitted video traffic. 1843 Note the audio of an A/V call can be marked AF41 as well. 1845 o AF42 = all non-Hi-Res video traffic marked AF41 in excess of 1846 specified rate "A", or new non-admitted video traffic but 1847 below specified rate "B". 1849 o AF43 = in excess of specified rate "B". 1851 o Where "A" < "B". 1853 Note: One might expect "A" to approximate the peak rates of sum of 1854 all admitted video flows, plus the sum of the mean rates and 1855 "B" to approximate the sum of the peak rates of those same two 1856 flows. 1858 Mandatory DSCP marking when performed by SIP or H.323/V2 1859 videoconferencing equipment: 1861 o AF41 = SIP or H.323 video conferencing audio stream RTP. 1863 o AF41 = SIP or H.323 video conferencing video control RTCP. 1865 o AF41 = SIP or H.323 video conferencing video stream up to 1866 specified rate "A". 1868 o AF42 = SIP or H.323 video conferencing video stream in excess of 1869 specified rate "A" but below specified rate "B". 1871 o AF42 = SIP or H.323 video conferencing video control RTCP, for 1872 those video streams that were generated using AF42. 1874 o AF43 = SIP or H.323 video conferencing video stream in excess of 1875 specified rate "B". 1877 o AF43 = SIP or H.323 video conferencing video control RTCP, for 1878 those video streams that were generated using AF43. 1880 o Where "A" < "B". 1882 Mandatory conditioning performed at DiffServ network edge: 1884 o The two-rate, three-color marker SHOULD be configured to provide 1885 the behavior as defined in trTCM [RFC2698]. 1887 o If packets are marked by trusted sources or a previously trusted 1888 DiffServ domain and the color marking is to be preserved, then 1889 the two-rate, three-color marker SHOULD be configured to operate 1890 in Color-Aware mode. 1892 o If the packet marking is not trusted or the color marking is not 1893 to be preserved, then the two-rate, three-color marker SHOULD be 1894 configured to operate in Color-Blind mode. 1896 The fundamental service offered to nonadmitted "Video" traffic is 1897 enhanced best-effort service with controlled rate and delay. The 1898 fundamental service offered to capacity-admitted "Video" traffic is 1899 a guaranteed service using in-data-path signaling to ensure expected 1900 delivery in a timely manner. For a non-admitted video conferencing 1901 service, if a 1% packet loss detected at the receiver triggers an 1902 encoding rate change, thus dropping to the next lower provisioned 1903 video encoding rate then Active Queue Management [RFC2309] SHOULD be 1904 used primarily to switch the video encoding rate under congestion, 1905 changing from high rate to lower rate, i.e., 1472 kbps to 768 kbps. 1906 This rule applies to all AF42 and 43 flows. The probability of loss 1907 of AF41 traffic MUST NOT exceed the probability of loss of AF42 1908 traffic, which in turn MUST NOT exceed the probability of loss of 1909 AF43 traffic. 1911 Capacity-admitted video service should not result in packet loss. 1912 However, administratively this MAY be allowed to cause a purposeful 1913 downspeeding event (i.e., a change in resolution or a change in 1914 codec) to occur due to congestion. 1916 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1917 specifies a target queue depth for each DSCP, and the max-threshold 1918 specifies the queue depth above which all traffic with such a DSCP 1919 is dropped or ECN marked. Thus, in this service class, the 1920 following inequality should hold in queue configurations: 1922 o min-threshold AF43 < max-threshold AF43 1924 o max-threshold AF43 <= min-threshold AF42 1926 o min-threshold AF42 < max-threshold AF42 1928 o max-threshold AF42 <= min-threshold AF41 1930 o min-threshold AF41 < max-threshold AF41 1932 o max-threshold AF41 <= memory assigned to the queue 1934 Note: This configuration tends to drop AF43 traffic before AF42 and 1935 AF42 before AF41. Many other AQM algorithms exist and are 1936 used; they should be configured to achieve a similar result. 1938 4.1.3 Hi-Res Service Class 1940 The Hi-Res service class is for higher end (i.e., deemed 'more 1941 important') bidirectional applications that require real-time 1942 service for both constant and rate-adaptive traffic. There are two 1943 PHBs, both EF based, for the Hi-Res video conferencing service 1944 class: 1946 Nonadmitted Hi-Res traffic - MUST use the CS4 DSCP [RFC2474], and 1947 is for traffic that has not had any capacity admission 1948 signaling performed for that flow or session. 1950 Capacity-Admitted Hi-Res traffic - MUST use the CS4-Admit DSCP 1952 [ID-DSCP], and is for traffic that has had any capacity 1953 admission signaling performed for that flow or session, e.g., 1954 RSVP [RFC2205] or NSIS [RFC4080]. 1956 The capacity-admitted Hi-Res video conferencing traffic operation is 1957 similar to an ATM CBR service, which has guaranteed bandwidth and 1958 which, if it stays within the negotiated rate, experiences nominal 1959 delay and no loss. 1961 SIP and H.323/V2 (and later) versions of video conferencing 1962 equipment with constant and dynamic bandwidth adjustment are such 1963 applications. The traffic sources in this service class either have 1964 a fixed bandwidth requirement (e.g., MPEG2), or have the ability to 1965 dynamically change their transmission rate (e.g., MPEG4/H.264) based 1966 on feedback from the receiver. This feedback SHOULD be accomplished 1967 using RTCP [RFC3550]. One approach for this downspeeding has the 1968 receiver detect packet loss, thus signaling in an RTCP message to 1969 the source the indication of lost (or delayed or out of order) 1970 packets in transit. When necessary the source then selects a lower 1971 rate encoding codec. When available, the source merely sends less 1972 data, resulting in lower resolution of the same visual display. 1974 The Hi-Res service class, as with the Video service class, is not 1975 for video downloads, webcasts, or single directional video or 1976 audio/video traffic of any kind. It is for human-to-human visual 1977 interaction between two users, or more if an MTP is used. 1979 Typical Hi-Res video conferencing configurations negotiate the setup 1980 of audio/video session using protocols such as SIP and H.323. 1981 Hi-Res video conferencing is generally not over the big "I" 1982 Internet, rather nearly exclusively over more managed networks such 1983 as an enterprise or special purpose SP's managed network in which 1984 servers within either network take part in the call signaling, 1985 thereby offering the video service. In addition, typically this type 1986 of audio/video service has high business expectations for minimized 1987 packet loss, pixilation or other issues with the audio/video 1988 experience. In the recent past, entire T3s have been dedicated to a 1989 signal Hi-Res call; sometimes one T3 per site of a multi-site video 1990 conference. 1992 Hi-Res video conferencing often has larger in bandwidth than the 1993 typical video call. The audio portion can be increased as well, as 1994 stereo capabilities are often necessary to provide an in-room 1995 experience from a distance. The difference can be significant (or 1996 another step up from just a typical video service). For example, for 1997 a single G.711 audio call that is 80kbps, a Hi-Res conference 1998 usually runs G.722 wideband audio at 256kbps. Typical video delivery 1999 is up to 4Mbps, whereas a Hi-Res conference can have three 2000 1080p/30fps widescreen displays requiring at least 12Mbps, with a 2001 burst capability of much more. 2003 If there were no congestion on the wire, the expected treatment 2004 between a video service and a Hi-Res conference would be the same. 2005 However, it is typically the case that the Hi-Res conferencing flows 2006 have more rigid requirements for quality and business-wise, need to 2007 be experience far less errors than the regular video service on the 2008 same network. 2010 Note that it is likely the case in these networks that the 2011 accompanying audio to the Hi-Res video call will be marked as the 2012 Hi-Res video is marked (i.e., using the same DSCP. 2014 The Hi-Res service class MUST use the Class Selector 5 (CS4) PHB, 2015 defined in [RFC2474], for non-capacity-admitted conferences. While 2016 the capacity-admitted Hi-Res conferences MUST use the CS4-Admit PHB, 2017 defined in [ID-DSCP]. This service class MUST be configured to 2018 provide a bandwidth assurance for CS4 and CS4-Admit marked packets 2019 to ensure that they get forwarded. The Hi-Res service class SHOULD 2020 be configured to use a Priority Queuing system such as that defined 2021 in Section 1.4.1.1 of this document. Further, CS4-Admit will be 2022 designated as the DSCP for use when capacity-admission signaling has 2023 been used, such as RSVP or NSIS, to guarantee delivery through the 2024 network. CS4 will be used for non-admitted Hi-Res conferences, as 2025 well as overflows from CS4-Admit sources that send more packets than 2026 they have negotiated bandwidth for that call. 2028 The following applications MUST use the Hi-Res service class: 2030 o SIP and H.323/V2 (and later) versions of Hi-Res video 2031 conferencing applications (interactive Hi-Res video). 2033 o Video conferencing applications with rate control or traffic 2034 content importance marking. 2036 The following are traffic characteristics: 2038 o Variable size packets. 2040 o The higher the resolution or change rate between each image, the 2041 higher the duration of large packets. 2043 o Usually constant inter-packet time interval. 2045 o Can be Variable rate in transmission. 2047 o Source is capable of reducing its transmission rate based on 2048 being told receiver is detecting packet loss. 2050 Applications or IP end points SHOULD pre-mark their packets with 2051 DSCP values as shown below. If the end point is not capable of 2052 setting the DSCP value, then the router topologically closest to the 2053 end point SHOULD perform Multifield (MF) Classification, as defined 2054 in [RFC2475] and mark all packets as AF4x. 2056 Mandatory DSCP marking when performed by router closest to source: 2058 o CS4-Admit = up to specified rate "A", which is dedicated to 2059 capacity-admitted Hi-Res traffic. 2061 Note the audio of an A/V call can be marked CS4-Admit as well. 2063 o CS4 = all video traffic marked CS4-Admit in excess of specified 2064 rate "A", or new non-admitted video traffic but below 2065 specified rate "B". 2067 o Where "A" < "B". 2069 Note: One might expect "A" to approximate the peak rates of sum of 2070 all admitted video flows, plus the sum of the mean rates and 2071 "B" to approximate the sum of the peak rates of those same two 2072 flows. 2074 Mandatory DSCP marking when performed by SIP or H.323/V2 2075 videoconferencing equipment: 2077 o CS4-Admit = SIP or H.323 video conferencing audio stream RTP/UDP. 2079 o CS4-Admit = SIP or H.323 video conferencing video control 2080 RTCP/TCP. 2082 o CS4-Admit = SIP or H.323 video conferencing video stream up to 2083 specified rate "A". 2085 o CS4 = SIP or H.323 video conferencing video stream in excess of 2086 specified rate "A" but below specified rate "B". 2088 o Where "A" < "B". 2090 Mandatory conditioning performed at DiffServ network edge: 2092 o The two-rate, three-color marker SHOULD be configured to provide 2093 the behavior as defined in trTCM [RFC2698]. 2095 o If packets are marked by trusted sources or a previously trusted 2096 DiffServ domain and the color marking is to be preserved, then 2097 the two-rate, three-color marker SHOULD be configured to operate 2098 in Color-Aware mode. 2100 o If the packet marking is not trusted or the color marking is not 2101 to be preserved, then the two-rate, three-color marker SHOULD be 2102 configured to operate in Color-Blind mode. 2104 The fundamental service offered to nonadmitted "Hi-Res" traffic is 2105 enhanced best-effort service with controlled rate and delay. The 2106 fundamental service offered to capacity-admitted "Hi-Res" traffic is 2107 a guaranteed service using in-data-path signaling to ensure expected 2108 or timely delivery. Capacity-admitted video service SHOULD NOT 2109 result in packet loss. However, administratively this MAY be allowed 2110 to cause a purposeful downspeeding event (i.e., a change in 2111 resolution or a change in codec) to occur. 2113 4.2. Realtime-Interactive Service Class 2115 The Realtime-Interactive service class is for bidirectional 2116 applications that require low loss and jitter and very low delay for 2117 constant or variable rate inelastic traffic sources. Interactive 2118 gaming applications that do not have the ability to change encoding 2119 rates or to mark packets with different importance indications is 2120 one good example of such an application. Another set of 2121 applications is virtualized desktop applications in which a remote 2122 user has a keyboard, mouse and display monitor, but the desktop is 2123 virtualized with the memory/processor/applications back in a common 2124 data center, requiring near instantaneous feedback on the user's 2125 monitor of any changes caused by the application or an action by the 2126 user. Rich media protocols for voice and video MUST NOT use the 2127 Realtime-Interactive service class, but rather the appropriate 2128 service class from the Conversational service group discussed early 2129 in Section 4.1. 2131 The Realtime-Interactive service class will use two PHBs: 2133 Nonadmitted Realtime-Interactive traffic - MUST use the CS5 DSCP 2134 [RFC2474], and is for traffic that has not had any capacity 2135 admission signaling performed for that flow or session. 2137 Capacity-Admitted Realtime-Interactive traffic - MUST use the 2138 CS5-Admit DSCP [ID-DSCP], and is for traffic that has had any 2139 capacity admission signaling performed for that flow or 2140 session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. 2142 The capacity-admitted Realtime-Interactive traffic operation is 2143 similar to an ATM CBR service, which has guaranteed bandwidth and 2144 which, if it stays within the negotiated rate, experiences nominal 2145 delay and no loss. 2147 Either of the above service classes can be configured as EF based by 2148 using a relaxed performance parameter and a rate scheduler. 2150 When a user/endpoint has been authorized to start a new session 2151 (i.e., joins a networked game or logs onto a virtualized 2152 workstation), the admission procedure should have verified that the 2153 newly admitted data rates will be within the engineered capacity of 2154 the Realtime-Interactive service class. The bandwidth in the core 2155 network and the number of simultaneous Realtime-Interactive sessions 2156 that can be supported SHOULD be engineered to control traffic load 2157 for this service. 2159 This service class SHOULD be configured to provide a high assurance 2160 for bandwidth for CS5 PHB, defined in [RFC2474], or CS5-Admit 2161 [ID-DSCP] for guaranteed service through a capacity-admission 2162 signaling protocol. The Realtime-Interactive service class SHOULD be 2163 configured to use a Rate Queuing system such as that defined in 2164 Section 1.4.1.2 of this document. Note that either 2165 Realtime-Interactive PHB MAY be configured as another EF PHB, 2166 specifically CS5-Admit, that uses a relaxed performance parameter 2167 and a rate scheduler, in the priority queue as defined in Section 2168 1.4.1.1 of this document. 2170 The following applications MUST use the Realtime-Interactive service 2171 class: 2173 o Interactive gaming and control. 2175 o Remote Desktop applications 2177 o Virtualized Desktop applications. 2179 o Application server-to-application server non-bursty data transfer 2180 requiring very low delay. 2182 o Inelastic, interactive, time-critical, and mission-critical 2183 applications requiring very low delay. 2185 The following are traffic characteristics: 2187 o Variable size packets. 2189 o Variable rate, though sometimes bursty, which will require 2190 engineering of the network to accommodate. 2192 o Application is sensitive to delay variation between flows and 2193 sessions. 2195 o Lost packets, if any, are usually ignored by application. 2197 RECOMMENDED DSCP marking: 2199 o All non-admitted flows in this service class are marked with CS5 2200 (Class Selector 5). 2202 o All capacity-admitted flows in this service class are marked with 2203 CS5-Admit. 2205 Applications or IP end points SHOULD pre-mark their packets with CS5 2206 or CS5-Admit DSCP value, depending on whether a capacity-admission 2207 signaling protocol is used for a flow. If the end point is not 2208 capable of setting the DSCP value, then the router topologically 2209 closest to the end point SHOULD perform Multifield (MF) 2210 Classification, as defined in [RFC2475]. 2212 RECOMMENDED conditioning performed at DiffServ network edge: 2214 o Packet flow marking (DSCP setting) from untrusted sources (end 2215 user devices) SHOULD be verified at ingress to DiffServ network 2216 using Multifield (MF) Classification methods defined in 2217 [RFC2475]. 2219 o Packet flows from untrusted sources (end user devices) SHOULD be 2220 policed at ingress to DiffServ network, e.g., using single rate 2221 with burst size token bucket policer to ensure that the traffic 2222 stays within its negotiated or engineered bounds. 2224 o Packet flows from trusted sources (application servers inside 2225 administered network) MAY not require policing. 2227 o Policing of packet flows across peering points MUST adhere to the 2228 Service Level Agreement (SLA). 2230 The fundamental service offered to nonadmitted 2231 "Realtime-Interactive" traffic is enhanced best-effort service with 2232 controlled rate and delay. The fundamental service offered to 2233 capacity-admitted "Realtime-Interactive" traffic is a guaranteed 2234 service using in-data-path signaling to ensure expected or timely 2235 delivery. Capacity-admitted Realtime-Interactive service SHOULD NOT 2236 result in packet loss. The service SHOULD be engineered so that CS5 2237 marked packet flows have sufficient bandwidth in the network to 2238 provide high assurance of delivery. Normally, traffic in this 2239 service class does not respond dynamically to packet loss. As such, 2240 Active Queue Management [RFC2309] SHOULD NOT be applied to CS5 2241 marked packet flows. 2243 4.3. Multimedia Conferencing Service Class 2245 The Multimedia Conferencing service class is for applications that 2246 have a low to medium tolerance to delay, and are rate adaptive to 2247 lost packets in transit from sources. Presentation Data 2248 applications that are operational in conjunction with an audio/video 2249 conference is one good example of such an application. Another set 2250 of applications is application sharing or whiteboarding 2251 applications, also in conjunction to an A/V conference. In either 2252 case, the audio & video part of the flow MUST NOT use the Multimedia 2253 Conferencing service class, rather the more appropriate service 2254 class within the Conversational service group discussed earlier in 2255 Section 4.1. 2257 The Multimedia Conferencing service class will use two PHBs: 2259 Nonadmitted Multimedia Conferencing traffic - MUST use the (new) 2260 MC DSCP [ID-DSCP], and is for traffic that has not had any 2261 capacity admission signaling performed for that flow or 2262 session. 2264 Capacity-Admitted Multimedia Conferencing traffic - MUST use the 2265 (new) MC-Admit DSCP [ID-DSCP], and is for traffic that has 2266 had any capacity admission signaling performed for that flow 2267 or session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. 2269 The capacity-admitted Multimedia Conferencing traffic operation is 2270 similar to an ATM CBR service, which has guaranteed bandwidth and 2271 which, if it stays within the negotiated rate, experiences nominal 2272 delay and no loss. 2274 When a user/endpoint initiates a presentation data, application 2275 sharing or whiteboarding session, it will typically be part of an 2276 audio or audio/video conference such as web-conferencing or an 2277 existing Telepresence call. The authorization procedure SHOULD be 2278 controlled through the coordinated effort to bind the A/V call with 2279 the correct Multimedia Conferencing packet flow through some use of 2280 identifiers not in scope of this document. The managed network this 2281 flow traverse and the number of simultaneous Multimedia 2282 Conferencing sessions that can be supported SHOULD be engineered to 2283 control traffic load for this service. 2285 The non-capacity admitted Multimedia Conferencing service class 2286 SHOULD use the new MC PHB, defined in [ID-DSCP]. This service class 2287 SHOULD be configured to provide a high assurance for bandwidth for 2288 CS5 marked packets to ensure that they get forwarded. The 2289 Multimedia Conferencing service class SHOULD be configured to use a 2290 Rate Queuing system such as that defined in Section 1.4.1.2 of this 2291 document. Note that this service class MAY be configured as another 2292 EF PHB that uses a relaxed performance parameter, a rate scheduler, 2293 and MC-Admit DSCP value, which MUST use the priority queue as 2294 defined in Section 1.4.1.1 of this document. 2296 The following applications MUST use the Multimedia Conferencing 2297 service class: 2299 o Presentation Data applications, which can utilize vector 2300 graphics, raster graphics or video delivery. 2302 o Virtualized Desktop applications. 2304 o Application server-to-application server non-bursty data transfer 2305 requiring very low delay. 2307 The following are traffic characteristics: 2309 o Variable size packets. 2311 o Variable rate, though sometimes bursty, which will require 2312 engineering of the network to accommodate. 2314 o Application is sensitive to delay variation between flows and 2315 sessions. 2317 o Lost packets, if any, can be ignored by the application. 2319 RECOMMENDED DSCP marking: 2321 o All non-admitted flows in this service class are marked with the 2322 new MC DSCP. 2324 o All capacity-admitted flows in this service class are marked with 2325 MC-Admit. 2327 Applications or IP end points SHOULD pre-mark their packets with the 2328 MC DSCP value. If the end point is not capable of setting the DSCP 2329 value, then the router topologically closest to the end point SHOULD 2330 perform Multifield (MF) Classification, as defined in [RFC2475]. 2332 RECOMMENDED conditioning performed at DiffServ network edge: 2334 o Packet flow marking (DSCP setting) from untrusted sources (end 2335 user devices) SHOULD be verified at ingress to DiffServ network 2336 using Multifield (MF) Classification methods defined in 2337 [RFC2475]. 2339 o Packet flows from untrusted sources (end user devices) SHOULD be 2340 policed at ingress to DiffServ network, e.g., using single rate 2341 with burst size token bucket policer to ensure that the traffic 2342 stays within its negotiated or engineered bounds. 2344 o Packet flows from trusted sources (application servers inside 2345 administered network) MAY not require policing. 2347 o Policing of packet flows across peering points MUST adhere to the 2348 Service Level Agreement (SLA). 2350 The fundamental service offered to nonadmitted "Multimedia 2351 Conferencing" traffic is enhanced best-effort service with 2352 controlled rate and delay. The fundamental service offered to 2353 capacity-admitted "Multimedia Conferencing" traffic is a guaranteed 2354 service using in-data-path signaling to ensure expected or timely 2355 delivery. Capacity-admitted Multimedia Conferencing service SHOULD 2356 NOT result in packet loss. The service SHOULD be engineered so that 2357 Multimedia Conferencing marked packet flows have sufficient 2358 bandwidth in the network to provide high assurance of delivery. 2359 Normally, traffic in this service class does not respond dynamically 2360 to packet loss. As such, Active Queue Management [RFC2309] SHOULD 2361 NOT be applied to MC or MC-Admit marked packet flows. 2363 4.4. Multimedia Streaming Service Class 2364 The Multimedia Streaming service class is RECOMMENDED for 2365 applications that require near-real-time packet forwarding of 2366 variable rate elastic traffic sources that are not as delay 2367 sensitive as applications using the Broadcast service class. Such 2368 applications include streaming audio and video, some video (movies) 2369 on-demand applications, and non-interactive webcasts. In general, 2370 the Multimedia Streaming service class assumes that the traffic is 2371 buffered at the source/destination; therefore, it is less sensitive 2372 to delay and jitter. 2374 The Multimedia Streaming service class MUST use the Assured 2375 Forwarding (AF3x) PHB, defined in [RFC2597]. This service class 2376 MUST be configured to provide a minimum bandwidth assurance for 2377 AF31, AF32, and AF33 marked packets to ensure that they get 2378 forwarded. The Multimedia Streaming service class SHOULD be 2379 configured to use Rate Queuing system for AF32 and AF33 traffic 2380 flows, such as that defined in Section 1.4.1.2 of this document. 2381 However, AF31 MUST be designated as the DSCP for use when 2382 capacity-admission signaling has been used, such as RSVP or NSIS, to 2383 guarantee delivery through the network. AF32 and AF33 will be used 2384 for non-admitted streaming flows, as well as overflows from AF31 2385 sources that send more packets than they have negotiated bandwidth 2386 for that call. 2388 The following applications SHOULD use the Multimedia Streaming 2389 service class: 2391 o Buffered streaming audio (unicast). 2393 o Buffered streaming video (unicast). 2395 o Non-interactive Webcasts. 2397 o IP VPN service that specifies two rates and is less sensitive to 2398 delay and jitter. 2400 The following are traffic characteristics: 2402 o Variable size packets. 2404 o The higher the rate, the higher the density of large packets. 2406 o Variable rate. 2408 o Elastic flows. 2410 o Some bursting at start of flow from some applications, as well as 2411 an expected stepping up and down on the rate of the flow based on 2412 changes in resolution due to network conditions. 2414 Applications or IP end points SHOULD pre-mark their packets with 2415 DSCP values as shown below. If the end point is not capable of 2416 setting the DSCP value, then the router topologically closest to the 2417 end point SHOULD perform Multifield (MF) Classification, as defined 2418 in [RFC2475], and mark all packets as AF3x. Note: In this case, 2419 the two-rate, three-color marker will be configured to operate in 2420 Color-Blind mode. 2422 RECOMMENDED DSCP marking: 2424 o AF31 = up to specified rate "A". 2426 o AF32 = all traffic marked AF31 in excess of specified rate "A", 2427 or new AF32 traffic but below specified rate "B". 2429 o AF33 = in excess of specified rate "B". 2431 o Where "A" < "B". 2433 Note: One might expect "A" to approximate the peak rates of sum of 2434 all streaming flows, plus the sum of the mean rates and "B" to 2435 approximate the sum of the peak rates of those same two flows. 2437 RECOMMENDED conditioning performed at DiffServ network edge: 2439 o The two-rate, three-color marker SHOULD be configured to provide 2440 the behavior as defined in trTCM [RFC2698]. 2442 o If packets are marked by trusted sources or a previously trusted 2443 DiffServ domain and the color marking is to be preserved, then 2444 the two-rate, three-color marker SHOULD be configured to operate 2445 in Color-Aware mode. 2447 o If the packet marking is not trusted or the color marking is not 2448 to be preserved, then the two-rate, three-color marker SHOULD be 2449 configured to operate in Color-Blind mode. 2451 The fundamental service offered to nonadmitted "Multimedia 2452 Streaming" traffic is enhanced best-effort service with controlled 2453 rate and delay. The fundamental service offered to 2454 capacity-admitted "Multimedia Streaming" traffic is a guaranteed 2455 service using in-data-path signaling to ensure expected delivery in 2456 a reasonable manner. The service SHOULD be engineered so that AF31 2457 marked packet flows have sufficient bandwidth in the network to 2458 provide high assurance of delivery. Since the AF3x traffic is 2459 elastic and responds dynamically to packet loss, Active Queue 2460 Management [RFC2309] SHOULD be used primarily to reduce forwarding 2461 rate to the minimum assured rate at congestion points, unless AF31 2462 has had a capacity-admission signaling protocol applied to the flow, 2463 such as RSVP or NSIS. 2465 If a capacity-admission signaling protocol applied to the AF31 flow, 2466 which SHOULD be the case always, the AF31 PHB MAY be configured as 2467 another EF PHB that uses a relaxed performance parameter and a rate 2468 scheduler, in the priority queue as defined in Section 1.4.1.1 of 2469 this document. 2471 The probability of loss of AF31 traffic MUST NOT exceed the 2472 probability of loss of AF32 traffic, which in turn MUST NOT exceed 2473 the probability of loss of AF33. 2475 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2476 specifies a target queue depth for each DSCP, and the max-threshold 2477 specifies the queue depth above which all traffic with such a DSCP 2478 is dropped or ECN marked. Thus, in this service class, the 2479 following inequality MUST hold in queue configurations: 2481 o min-threshold AF33 < max-threshold AF33 2483 o max-threshold AF33 <= min-threshold AF32 2485 o min-threshold AF32 < max-threshold AF32 2487 o max-threshold AF32 <= min-threshold AF31 2489 o min-threshold AF31 < max-threshold AF31 2491 o max-threshold AF31 <= memory assigned to the queue 2493 Note#1: this confirmation MUST be modified if AF31 has a 2494 capacity-admission signaling protocol applied to those 2495 flows, and the above will only apply to AF32 and AF33, while 2496 AF31 (theoretically) has no packet loss. 2498 Note#2: This configuration tends to drop AF33 traffic before AF32 2499 and AF32 before AF31. Note: Many other AQM algorithms exist 2500 and are used; they SHOULD be configured to achieve a similar 2501 result. 2503 4.5. Broadcast Service Class 2505 The Broadcast service class is RECOMMENDED for applications that 2506 require near-real-time packet forwarding with very low packet loss 2507 of constant rate and variable rate inelastic traffic sources that 2508 are more delay sensitive than applications using the Multimedia 2509 Streaming service class. Such applications include broadcast TV, 2510 streaming of live audio and video events, some video-on-demand 2511 applications, and video surveillance. In general, the Broadcast 2512 service class assumes that the destination end point has a dejitter 2513 buffer, for video application usually a 2 - 8 video-frame buffer (66 2514 to several hundred of milliseconds), thus expecting far less 2515 buffering before play-out than Multimedia Streaming, which can 2516 buffer in the seconds to minutes (to hours). 2518 The Broadcast service class will use two PHBs: 2520 Nonadmitted Broadcast traffic - MUST use the CS3 DSCP [RFC2474], 2521 and is for traffic that has not had any capacity admission 2522 signaling performed for that flow or session. 2524 Capacity-Admitted Broadcast traffic - MUST use the CS3-Admit DSCP 2525 [ID-DSCP], and is for traffic that has had any capacity 2526 admission signaling performed for that flow or session, e.g., 2527 RSVP [RFC2205] or NSIS [RFC4080]. 2529 The capacity-admitted Broadcast traffic operation is similar to an 2530 ATM CBR service, which has guaranteed bandwidth and which, if it 2531 stays within the negotiated rate, experiences nominal delay and no 2532 loss. 2534 Either of the above service classes can be configured as EF based by 2535 using a relaxed performance parameter and a rate scheduler. 2537 When a user/endpoint initiates a new Broadcast session (i.e., starts 2538 an Internet radio application, starts a live Internet A/V event or a 2539 camera comes online to do video-surveillance), the admission 2540 procedure should be verified within the application that triggers 2541 the flow. The newly admitted data rates will SHOULD be within the 2542 engineered capacity of the Broadcast service class within that 2543 network. The bandwidth in the core network and the number of 2544 simultaneous Broadcast sessions that can be supported SHOULD be 2545 engineered to control traffic load for this service. 2547 This service class SHOULD be configured to provide high assurance 2548 for bandwidth for CS3 marked packets to ensure that they get 2549 forwarded. The Broadcast service class SHOULD be configured to use 2550 Rate Queuing system such as that defined in Section 1.4.1.2 of this 2551 document. Note that either Broadcast PHB MAY be configured as 2552 another EF PHB, specifically CS3-Admit, that uses a relaxed 2553 performance parameter and a rate scheduler, in the priority queue as 2554 defined in Section 1.4.1.1 of this document. 2556 The following applications SHOULD use the Broadcast service class: 2558 o Video surveillance and security (unicast). 2560 o TV broadcast including HDTV (likely multicast, but can be 2561 unicast). 2563 o Video on demand (unicast) with control (virtual DVD). 2565 o Streaming of live audio events (both unicast and multicast). 2567 o Streaming of live video events (both unicast and multicast). 2569 The following are traffic characteristics: 2571 o Variable size packets. 2573 o The higher the rate, the higher the density of large packets. 2575 o Mixture of variable rate and constant rate flows. 2577 o Fixed packet emission time intervals. 2579 o Inelastic flows. 2581 RECOMMENDED DSCP marking: 2583 o All non-admitted flows in this service class are marked with CS3 2584 (Class Selector 3). 2586 o All capacity-admitted flows in this service class are marked with 2587 CS3-Admit. 2589 o In some cases, such as those for security and video surveillance 2590 applications, it is NOT RECOMMENDED, but allowed to use a 2591 different DSCP marking. 2593 If so, then locally user definable (EXP/LU) codepoints in the 2594 range '011x11' MAY be used to provide unique traffic 2595 identification. The locally administrator definable (EXP/LU, 2596 from pool 2 of RFC 2474) codepoint(s) MAY be associated with the 2597 PHB that is used for CS3 or CS3-Admit traffic. Furthermore, 2598 depending on the network scenario, additional network edge 2599 conditioning policy MAY be needed for the EXP/LU codepoint(s) 2600 used. 2602 Applications or IP end points SHOULD pre-mark their packets with CS3 2603 or CS3-Admit DSCP value. If the end point is not capable of setting 2604 the DSCP value, then the router topologically closest to the end 2605 point SHOULD perform Multifield (MF) Classification, as defined in 2606 [RFC2475]. 2608 RECOMMENDED conditioning performed at DiffServ network edge: 2610 o Packet flow marking (DSCP setting) from untrusted sources (end 2611 user devices) SHOULD be verified at ingress to DiffServ network 2612 using Multifield (MF) Classification methods defined in 2613 [RFC2475]. 2615 o Packet flows from untrusted sources (end user devices) SHOULD be 2616 policed at ingress to DiffServ network, e.g., using single rate 2617 with burst size token bucket policer to ensure that the traffic 2618 stays within its negotiated or engineered bounds. 2620 o Packet flows from trusted sources (application servers inside 2621 administered network) MAY not require policing. 2623 o Policing of packet flows across peering points MUST be performed 2624 to the Service Level Agreement (SLA) of those peering entities. 2626 The fundamental service offered to "Broadcast" traffic is enhanced 2627 best-effort service with controlled rate and delay. The fundamental 2628 service offered to capacity-admitted "Broadcast" traffic is a 2629 guaranteed service using in-data-path signaling to ensure expected 2630 or timely delivery. Capacity-admitted Broadcast service SHOULD NOT 2631 result in packet loss. The service SHOULD be engineered so that CS3 2632 and CS3-Admit marked packet flows have sufficient bandwidth in the 2633 network to provide high assurance of delivery. Normally, traffic in 2634 this service class does not respond dynamically to packet loss. As 2635 such, Active Queue Management [RFC2309] SHOULD NOT be applied to 2636 CS3 marked packet flows. 2638 4.6. Low-Latency Data Service Class 2640 The Low-Latency Data service class is RECOMMENDED for elastic and 2641 responsive typically client-/server-based applications. 2642 Applications forwarded by this service class are those that require 2643 a relatively fast response and typically have asymmetrical bandwidth 2644 need, i.e., the client typically sends a short message to the server 2645 and the server responds with a much larger data flow back to the 2646 client. The most common example of this is when a user clicks a 2647 hyperlink (~ few dozen bytes) on a web page, resulting in a new web 2648 page to be loaded (Kbytes or MBs of data). This service class is 2649 configured to provide good response for TCP [RFC1633] short-lived 2650 flows that require real-time packet forwarding of variable rate 2651 traffic sources. 2653 The Low-Latency Data service class SHOULD use the Assured Forwarding 2654 (AF) PHB, defined in [RFC2597]. This service class SHOULD be 2655 configured to provide a minimum bandwidth assurance for AF21, AF22, 2656 and AF23 marked packets to ensure that they get forwarded. The 2657 Low-Latency Data service class SHOULD be configured to use a Rate 2658 Queuing system such as that defined in Section 1.4.1.2 of this 2659 document. 2661 The following applications SHOULD use the Low-Latency Data service 2662 class: 2664 o Client/server applications. 2666 o Systems Network Architecture (SNA) terminal to host transactions 2667 (SNA over IP using Data Link Switching (DLSw)). 2669 o Web-based transactions (E-commerce). 2671 o Credit card transactions. 2673 o Financial wire transfers. 2675 o Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN). 2677 o VPN service that supports Committed Information Rate (CIR) with 2678 up to two burst sizes. 2680 o Instant Messaging and Presence protocols (e.g., SIP, XMPP). 2682 The following are traffic characteristics: 2684 o Variable size packets. 2686 o Variable packet emission rate. 2688 o With packet bursts of TCP window size. 2690 o Short traffic bursts. 2692 o Source capable of reducing its transmission rate based on 2693 detection of packet loss at the receiver or through explicit 2694 congestion notification. 2696 Applications or IP end points SHOULD pre-mark their packets with 2697 DSCP values as shown below. If the end point is not capable of 2698 setting the DSCP value, then the router topologically closest to the 2699 end point SHOULD perform Multifield (MF) Classification, as defined 2700 in [RFC2475] and mark all packets as AF2x. Note: In this case, the 2701 single-rate, three-color marker will be configured to operate in 2702 Color-Blind mode. 2704 RECOMMENDED DSCP marking: 2706 o AF21 = flow stream with packet burst size up to "A" bytes. 2708 o AF22 = flow stream with packet burst size in excess of "A" but 2709 below "B" bytes. 2711 o AF23 = flow stream with packet burst size in excess of "B" bytes. 2713 o Where "A" < "B". 2715 RECOMMENDED conditioning performed at DiffServ network edge: 2717 o The single-rate, three-color marker SHOULD be configured to 2718 provide the behavior as defined in srTCM [RFC2697]. 2720 o If packets are marked by trusted sources or a previously trusted 2721 DiffServ domain and the color marking is to be preserved, then 2722 the single-rate, three-color marker SHOULD be configured to 2723 operate in Color-Aware mode. 2725 o If the packet marking is not trusted or the color marking is 2726 not to be preserved, then the single-rate, three-color marker 2727 SHOULD be configured to operate in Color-Blind mode. 2729 The fundamental service offered to "Low-Latency Data" traffic is 2730 enhanced best-effort service with controlled rate and delay. The 2731 service SHOULD be engineered so that AF21 marked packet flows have 2732 sufficient bandwidth in the network to provide high assurance of 2733 delivery. Since the AF2x traffic is elastic and responds 2734 dynamically to packet loss, Active Queue Management [RFC2309] SHOULD 2735 be used primarily to control TCP flow rates at congestion points by 2736 dropping packets from TCP flows that have large burst size. The 2737 probability of loss of AF21 traffic MUST NOT exceed the probability 2738 of loss of AF22 traffic, which in turn MUST NOT exceed the 2739 probability of loss of AF23. Explicit Congestion Notification (ECN) 2740 [RFC3168] MAY also be used with Active Queue Management. 2742 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2743 specifies a target queue depth for each DSCP, and the max-threshold 2744 specifies the queue depth above which all traffic with such a DSCP 2745 is dropped or ECN marked. Thus, in this service class, the 2746 following inequality should hold in queue configurations: 2748 o min-threshold AF23 < max-threshold AF23 2750 o max-threshold AF23 <= min-threshold AF22 2752 o min-threshold AF22 < max-threshold AF22 2754 o max-threshold AF22 <= min-threshold AF21 2756 o min-threshold AF21 < max-threshold AF21 2758 o max-threshold AF21 <= memory assigned to the queue 2760 Note: This configuration tends to drop AF23 traffic before AF22 and 2761 AF22 before AF21. Many other AQM algorithms exist and are 2762 used; they should be configured to achieve a similar result. 2764 4.7. Conversational Signaling Service Class 2766 The Signaling service class is MUST be limited to delay-sensitive 2767 signaling traffic only, and then only applying to signaling that 2768 involves the Conversational service group. Audio signaling includes 2769 signaling between IP phone and soft-switch, soft-client and 2770 soft-switch, and media gateway and soft-switch as well as 2771 peer-to-peer using various protocols. Video and Hi-Res signaling 2772 includes video endpoint to video endpoint, as well as to Media 2773 transfer Point (MTP), to call control server(S), etc. This service 2774 class is intended to be used for control of voice and video sessions 2775 and applications. Protocols using this service class require a 2776 relatively fast response, as there are typically several messages of 2777 different sizes sent for control of the session. This service class 2778 is configured to provide good response for short-lived, intermittent 2779 flows that require real-time packet forwarding. This is not the 2780 service class for Instant Messaging (IM), that's within the bounds 2781 of the Low-Latency Data service class. The Conversational Signaling 2782 service class MUST be configured so that the probability of packet 2783 drop or significant queuing delay under peak load is very low in IP 2784 network segments that provide this interface. 2786 The Conversational Signaling service class MUST use the new A/V-Sig 2787 PHB, defined in [ID-DSCP]. This service class MUST be configured to 2788 provide a minimum bandwidth assurance for A/V-Sig marked packets to 2789 ensure that they get forwarded. In other words, this service class 2790 MUST NOT be starved from transmission within a reasonable timeframe, 2791 given that the entire Conversational service group depends on these 2792 signaling messages successful delivery. Network engineering SHOULD 2793 be done to ensure there is roughly 1-4% available per node interface 2794 that audio and video traverse. Local conditions MUST be considered 2795 when determining exactly how much bandwidth is given to this service 2796 class. The Conversational Signaling service class SHOULD be 2797 configured to use a Rate Queuing system such as that defined in 2798 Section 1.4.1.2 of this document. 2800 The following applications SHOULD use the Conversational Signaling 2801 service class: 2803 o Peer-to-peer conversational signaling (e.g., SIP, H.323, XMPP). 2805 o Peer-to-peer signaling for multimedia applications (e.g., SIP, 2806 H.323, XMPP). 2808 o Peer-to-peer real-time control function. 2810 o Client-server conversational signaling using H.248, MEGACO, MGCP, 2811 IP encapsulated ISDN, or other proprietary protocols. 2813 o Signaling to control IPTV applications using protocols such as 2814 IGMP. 2816 o Signaling flows between high-capacity voice call servers or 2817 soft switches using protocol such as SIP-T. Such high-capacity 2818 devices may control thousands of voice (VoIP) calls. 2820 o Signaling for one-way video flows, such as RTSP [RFC2326]. 2822 o IGMP, when used for multicast session control such as channel 2823 changing in IPTV systems. 2825 o OPTIONALLY, this service class can be used for on-path 2826 reservation signaling for the traffic flows that will use the 2827 "admitted" DSCPs. The alternative is to have the on-path 2828 signaling (for reservations) use the DSCP within that service 2829 class. This provides a similar treatment of the signaling to the 2830 data flow, which might be desired. 2832 The following are traffic characteristics: 2834 o Variable size packets, normally one packet at a time. 2836 o Intermittent traffic flows. 2838 o Traffic may burst at times. 2840 o Delay-sensitive control messages sent between two end points. 2842 RECOMMENDED DSCP marking: 2844 o All flows in this service class are marked with A/V-Sig. 2846 Applications or IP end points SHOULD pre-mark their packets with 2847 A/V-Sig DSCP value. If the end point is not capable of setting the 2848 DSCP value, then the router topologically closest to the end point 2849 SHOULD perform Multifield (MF) Classification, as defined in 2850 [RFC2475]. 2852 RECOMMENDED conditioning performed at DiffServ network edge: 2854 o Packet flow marking (DSCP setting) from untrusted sources (end 2855 user devices) SHOULD be verified at ingress to DiffServ network 2856 using Multifield (MF) Classification methods defined in 2857 [RFC2475]. 2859 o Packet flows from untrusted sources (end user devices) SHOULD be 2860 policed at ingress to DiffServ network, e.g., using single rate 2861 with burst size token bucket policer to ensure that the traffic 2862 stays within its negotiated or engineered bounds. 2864 o Packet flows from trusted sources (application servers inside 2865 administered network) MAY not require policing. 2867 o Policing of packet flows across peering points in which each peer 2868 is participating in the call set-up MUST be performed to the 2869 Service Level Agreement (SLA). 2871 The fundamental service offered to "Conversational Signaling" 2872 traffic is enhanced best-effort service with controlled rate and 2873 delay. The service SHOULD be engineered so that A/V-Sig marked 2874 packet flows have sufficient bandwidth in the network to provide 2875 high assurance of delivery and low delay. Normally, traffic in this 2876 service class does not respond dynamically to packet loss. As such, 2877 Active Queue Management [RFC2309] SHOULD NOT be applied to A/V-Sig 2878 marked packet flows. 2880 4.8. High-Throughput Data Service Class 2881 The High-Throughput Data service class is RECOMMENDED for elastic 2882 applications that require timely packet forwarding of variable rate 2883 traffic sources and, more specifically, is configured to provide 2884 good throughput for TCP longer-lived flows. TCP [RFC1633] or a 2885 transport with a consistent Congestion Avoidance Procedure [RFC2581] 2886 [RFC3782] normally will drive as high a data rate as it can obtain 2887 over a long period of time. The FTP protocol is a common example, 2888 although one cannot definitively say that all FTP transfers are 2889 moving data in bulk. 2891 The High-Throughput Data service class SHOULD use the Assured 2892 Forwarding (AF) PHB, defined in [RFC2597]. This service class 2893 SHOULD be configured to provide a minimum bandwidth assurance for 2894 AF11, AF12, and AF13 marked packets to ensure that they are 2895 forwarded in a timely manner. The High-Throughput Data service 2896 class SHOULD be configured to use a Rate Queuing system such as that 2897 defined in Section 1.4.1.2 of this document. 2899 The following applications SHOULD use the High-Throughput Data 2900 service class: 2902 o Store and forward applications. 2904 o File transfer applications (e.g., FTP, HTTP, etc). 2906 o Email. 2908 o VPN service that supports two rates (committed information rate 2909 and excess or peak information rate). 2911 The following are traffic characteristics: 2913 o Variable size packets. 2915 o Variable packet emission rate. 2917 o Variable rate. 2919 o With packet bursts of TCP window size. 2921 o Source capable of reducing its transmission rate based on 2922 detection of packet loss at the receiver or through explicit 2923 congestion notification. 2925 Applications or IP end points SHOULD pre-mark their packets with 2926 DSCP values as shown below. If the end point is not capable of 2927 setting the DSCP value, then the router topologically closest to the 2928 end point SHOULD perform Multifield (MF) Classification, as defined 2929 in [RFC2475], and mark all packets as AF1x. Note: In this case, the 2930 two-rate, three-color marker will be configured to operate in 2931 Color-Blind mode. 2933 RECOMMENDED DSCP marking: 2935 o AF11 = up to specified rate "A". 2937 o AF12 = in excess of specified rate "A" but below specified rate 2938 "B". 2940 o AF13 = in excess of specified rate "B". 2942 o Where "A" < "B". 2944 RECOMMENDED conditioning performed at DiffServ network edge: 2946 o The two-rate, three-color marker SHOULD be configured to provide 2947 the behavior as defined in trTCM [RFC2698]. 2949 o If packets are marked by trusted sources or a previously trusted 2950 DiffServ domain and the color marking is to be preserved, then 2951 the two-rate, three-color marker SHOULD be configured to operate 2952 in Color-Aware mode. 2954 o If the packet marking is not trusted or the color marking is not 2955 to be preserved, then the two-rate, three-color marker SHOULD be 2956 configured to operate in Color-Blind mode. 2958 The fundamental service offered to "High-Throughput Data" traffic is 2959 enhanced best-effort service with a specified minimum rate. The 2960 service SHOULD be engineered so that AF11 marked packet flows have 2961 sufficient bandwidth in the network to provide assured delivery. It 2962 can be assumed that this class will consume any available bandwidth 2963 and that packets traversing congested links may experience higher 2964 queuing delays or packet loss. Since the AF1x traffic is elastic 2965 and responds dynamically to packet loss, Active Queue Management 2966 [RFC2309] SHOULD be used primarily to control TCP flow rates at 2967 congestion points by dropping packets from TCP flows that have 2968 higher rates first. The probability of loss of AF11 traffic MUST 2969 NOT exceed the probability of loss of AF12 traffic, which in turn 2970 MUST NOT exceed the probability of loss of AF13. In such a case, if 2971 one network customer is driving significant excess and another seeks 2972 to use the link, any losses will be experienced by the high-rate 2973 user, causing him to reduce his rate. Explicit Congestion 2974 Notification (ECN) [RFC3168] MAY also be used with Active Queue 2975 Management. 2977 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2978 specifies a target queue depth for each DSCP, and the max-threshold 2979 specifies the queue depth above which all traffic with such a DSCP 2980 is dropped or ECN marked. Thus, in this service class, the 2981 following inequality should hold in queue configurations: 2983 o min-threshold AF13 < max-threshold AF13 2984 o max-threshold AF13 <= min-threshold AF12 2986 o min-threshold AF12 < max-threshold AF12 2988 o max-threshold AF12 <= min-threshold AF11 2990 o min-threshold AF11 < max-threshold AF11 2992 o max-threshold AF11 <= memory assigned to the queue 2994 Note: This configuration tends to drop AF13 traffic before AF12 and 2995 AF12 before AF11. Many other AQM algorithms exist and are 2996 used; they should be configured to achieve a similar result. 2998 4.9. Standard Service Class 3000 The Standard service class is RECOMMENDED for traffic that has not 3001 been classified into one of the other supported forwarding service 3002 classes in the DiffServ network domain. This service class provides 3003 the Internet's "best-effort" forwarding behavior. This service 3004 class typically has minimum bandwidth guarantee. 3006 The Standard service class MUST use the Default Forwarding (DF) PHB, 3007 defined in [RFC2474], and SHOULD be configured to receive at least a 3008 small percentage of forwarding resources as a guaranteed minimum. 3009 This service class SHOULD be configured to use a Rate Queuing system 3010 such as that defined in Section 1.4.1.2 of this document. 3012 The following applications SHOULD use the Standard service class: 3014 o Network services, DNS, DHCP, BootP. 3016 o Any undifferentiated application/packet flow transported through 3017 the DiffServ enabled network. 3019 The following is a traffic characteristic: 3021 o Non-deterministic, mixture of everything. 3023 The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'. 3025 Network Edge Conditioning: 3027 There is no requirement that conditioning of packet flows be 3028 performed for this service class. 3030 The fundamental service offered to the Standard service class is 3031 best-effort service with active queue management to limit overall 3032 delay. Typical configurations SHOULD use random packet dropping to 3033 implement Active Queue Management [RFC2309] or Explicit Congestion 3034 Notification [RFC3168], and MAY impose a minimum or maximum rate on 3035 the queue. 3037 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3038 specifies a target queue depth, and the max-threshold specifies the 3039 queue depth above which all traffic is dropped or ECN marked. Thus, 3040 in this service class, the following inequality should hold in queue 3041 configurations: 3043 o min-threshold DF < max-threshold DF 3045 o max-threshold DF <= memory assigned to the queue 3047 Note: Many other AQM algorithms exist and are used; they should be 3048 configured to achieve a similar result. 3050 4.10. Low-Priority Data 3052 The Low-Priority Data service class serves applications that run 3053 over TCP [RFC0793] or a transport with consistent congestion 3054 avoidance procedures [RFC2581] [RFC3782] and that the user is 3055 willing to accept service without guarantees. This service class is 3056 specified in [RFC3662] and [QBSS]. 3058 The following applications MAY use the Low-Priority Data service 3059 class: 3061 o Any TCP based-application/packet flow transported through the 3062 DiffServ enabled network that does not require any bandwidth 3063 assurances. 3065 The following is a traffic characteristic: 3067 o Non-real-time and elastic. 3069 Network Edge Conditioning: 3071 There is no requirement that conditioning of packet flows be 3072 performed for this service class. 3074 The RECOMMENDED DSCP marking is CS1 (Class Selector 1). 3076 The fundamental service offered to the Low-Priority Data service 3077 class is best-effort service with zero bandwidth assurance. By 3078 placing it into a separate queue or class, it may be treated in a 3079 manner consistent with a specific Service Level Agreement. 3081 Typical configurations SHOULD use Explicit Congestion Notification 3082 [RFC3168] or random loss to implement Active Queue Management 3083 [RFC2309]. 3085 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3086 specifies a target queue depth, and the max-threshold specifies the 3087 queue depth above which all traffic is dropped or ECN marked. Thus, 3088 in this service class, the following inequality should hold in queue 3089 configurations: 3091 o min-threshold CS1 < max-threshold CS1 3093 o max-threshold CS1 <= memory assigned to the queue 3095 Note: Many other AQM algorithms exist and are used; they should be 3096 configured to achieve a similar result. 3098 5. Additional Information on Service Class Usage 3100 In this section, we provide additional information on how some 3101 specific applications should be configured to use the defined 3102 service classes. 3104 5.1. Mapping for NTP 3106 From tests that were performed, indications are that precise time 3107 distribution requires a very low packet delay variation (jitter) 3108 transport. Therefore, we suggest that the following guidelines for 3109 Network Time Protocol (NTP) be used: 3111 o When NTP is used for providing high-accuracy timing within an 3112 administrator's (carrier's) network or to end users/clients, the 3113 audio service class SHOULD be used, and NTP packets should be 3114 marked with EF DSCP value. 3116 o For applications that require "wall clock" timing accuracy, the 3117 Standard service class should be used, and packets should be 3118 marked with DF DSCP. 3120 5.2. VPN Service Mapping 3122 "Differentiated Services and Tunnels" [RFC2983] considers the 3123 interaction of DiffServ architecture with IP tunnels of various 3124 forms. Further to guidelines provided in RFC 2983, below are 3125 additional guidelines for mapping service classes that are supported 3126 in one part of the network into a VPN connection. This discussion 3127 is limited to VPNs that use DiffServ technology for traffic 3128 differentiation. 3130 o The DSCP value(s) that is/are used to represent a PHB or a PHB 3131 group SHOULD be the same for the networks at both ends of the VPN 3132 tunnel, unless remarking of DSCP is done as ingress/egress 3133 processing function of the tunnel. DSCP marking needs to be 3134 preserved along the tunnel, end to end. 3136 o The VPN MAY be configured to support one or more service classes. 3137 It is left up to the administrators of the two networks to agree 3138 on the level of traffic differentiation that will be provided in 3139 the network that supports VPN service. Service classes are then 3140 mapped into the supported VPN traffic forwarding behaviors that 3141 meet the traffic characteristics and performance requirements of 3142 the encapsulated service classes. 3144 o The traffic treatment in the network that is providing the VPN 3145 service needs to be such that the encapsulated service class or 3146 classes receive comparable behavior and performance in terms of 3147 delay, jitter, and packet loss and that they are within the 3148 limits of the service specified. 3150 o The DSCP value in the external header of the packet forwarded 3151 through the network providing the VPN service can be different 3152 from the DSCP value that is used end to end for service 3153 differentiation in the end network. 3155 o The guidelines for aggregation of two or more service classes 3156 into a single traffic forwarding treatment in the network that is 3157 providing the VPN service is for further study. 3159 6. Security Considerations 3161 This document discusses policy and describes a common policy 3162 configuration, for the use of a Differentiated Services Code Point 3163 by transports and applications. If implemented as described, it 3164 should require that the network do nothing that the network has not 3165 already allowed. If that is the case, no new security issues should 3166 arise from the use of such a policy. 3168 It is possible for the policy to be applied incorrectly, or for a 3169 wrong policy to be applied in the network for the defined service 3170 class. In that case, a policy issue exists that the network SHOULD 3171 detect, assess, and deal with. This is a known security issue in 3172 any network dependent on policy-directed behavior. 3174 A well-known flaw appears when bandwidth is reserved or enabled for 3175 a service (for example, voice and/or video transport) and another 3176 service or an attacking traffic stream uses it. This possibility is 3177 inherent in DiffServ technology, which depends on appropriate packet 3178 markings. When bandwidth reservation or a priority queuing system is 3179 used in a vulnerable network, the use of authentication and flow 3180 admission is recommended. To the author's knowledge, there is no 3181 known technical way to respond to an unauthenticated data stream 3182 using service that it is not intended to use, and such is the nature 3183 of the Internet. 3185 The use of a service class by a user is not an issue when the SLA 3186 between the user and the network permits him to use it, or to use it 3187 up to a stated rate. In such cases, simple policing is used in the 3188 Differentiated Services Architecture. Some service classes, such as 3189 Network Control, are not permitted to be used by users at all; such 3190 traffic should be dropped or remarked by ingress filters. Where 3191 service classes are available under the SLA only to an authenticated 3192 user rather than to the entire population of users, authentication 3193 and authorization services are required, such as those surveyed in 3194 [AUTHMECH]. 3196 7. Contributing Authors 3198 This section specifically calls out the authors of RFC 4594, from 3199 which this document is based on. 3201 Jozef Babiarz 3202 Nortel Networks 3204 Kwok Ho Chan 3205 Nortel Networks 3207 Fred Baker 3208 Cisco Systems 3209 EMail: fred@cisco.com 3211 Of note, two of the three mentioned authors above worked for Nortel 3212 Networks at the time of writing RFC 4594, a company that no longer 3213 exists. This author has not seen or heard from those two in many, 3214 many years or IETF meetings - as a result of not knowing their new 3215 email addresses (or phone numbers). 3217 While much of this document has been rewritten with either edited or 3218 brand new material, there are many short paragraphs that remain as 3219 they were from RFC 4594, as well as many sentences that were also 3220 left unchanged. Additionally, there were no new graphs, charts, 3221 diagrams, or tables introduced, meaning the first 4 tables within 3222 this document existed in RFC 4594, created by those authors. 3223 Presently, each of those tables contain modified and new 3224 information. The last 3 tables, specifically tables 5, 6, & 7 were 3225 removed because the examples section was removed. 3227 This author believes there must be proper credit given for all the 3228 contributions, including the framework this document retains from 3229 that RFC. Periodically, throughout this document, what was written 3230 remains the best way of conveying a thought, rule, or otherwise 3231 stated behavior or mechanism. Because RFC 4594 was rather large, 3232 there is no realistic way of identifying each part that was left 3233 untouched. Further, properly quoting that RFC and leaving those 3234 sentences embedded in this document would render this document 3235 highly unreadable. Another application could be used to show the 3236 changes, deletions and additions - but not one that the IETF accepts 3237 presently. 3239 This author has created this "Contributing Authors" section as a way 3240 of properly identifying those 3 individuals that provided text 3241 within this document. We will let the community judge if this is 3242 'good enough' (i.e., rough consensus), or if another way is better. 3244 8. Acknowledgements 3246 To this document, you can have your name here if you comment or 3247 contribute to this effort to make it better. We than you in advance. 3249 The author would like to thank Paul Jones, Glen Lavers, Mo Zanaty, 3250 David Benham, and Michael Ramalho for their comments and questions 3251 about this effort that ultimately helped shape this document. 3253 Below are the folks that were acknowledged in RFC 4594, and this 3254 author does not want to lose their recognition of contributions to 3255 the original effort. 3257 "The authors thank the TSVWG reviewers, David Black, Brian E. 3258 Carpenter, and Alan O'Neill for their review and input to this 3259 document. 3261 The authors acknowledge a great many inputs, most notably from 3262 Bruce Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois 3263 Audet, Morgan Littlewood, Robert Milne, John Shuler, Nalin 3264 Mistry, Al Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil 3265 Dickinson, Mike Fidler, and Shane Amante. Kimberly King, Joe 3266 Zebarth, and Alistair Munroe each did a thorough proofreading, 3267 and the document is better for their contributions." 3269 9. References 3271 9.1. Normative References 3273 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3274 September 1981. 3276 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 3277 793, September 1981. 3279 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 3280 Suite", RFC 1349, July 1992. 3282 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 3283 1812, June 1995. 3285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3286 Requirement Levels", BCP 14, RFC 2119, March 1997. 3288 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 3289 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 3290 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 3291 S., Wroclawski, J., and L. Zhang, "Recommendations on 3292 Queue Management and Congestion Avoidance in the 3293 Internet", RFC 2309, April 1998. 3295 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3296 "Definition of the Differentiated Services Field (DS 3297 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 3298 1998. 3300 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 3301 and W. Weiss, "An Architecture for Differentiated 3302 Service", RFC 2475, December 1998. 3304 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 3305 "Assured Forwarding PHB Group", RFC 2597, June 1999. 3307 [RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le 3308 Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. 3309 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 3310 Behavior)", RFC 3246, March 2002. 3312 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 3313 Per-Domain Behavior (PDB) for Differentiated Services", 3314 RFC 3662, December 2003. 3316 9.2. Informative References 3318 [AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms", 3319 Work in Progress, September 2005. 3321 [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 3322 Technical Report Proposed Service Definition, March 2001. 3324 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated 3325 Services in the Internet Architecture: an Overview", RFC 3326 1633, June 1994. 3328 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 3329 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 3330 Functional Specification", RFC 2205, September 1997. 3332 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 3333 Control", RFC 2581, April 1999. 3335 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 3336 Marker", RFC 2697, September 1999. 3338 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 3339 Marker", RFC 2698, September 1999. 3341 [RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive 3342 Shaper for Differentiated Services", RFC 2963, October 3343 2000. 3345 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 3346 2983, October 2000. 3348 [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, 3349 November 2000. 3351 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 3352 Differentiated Services Per Domain Behaviors and Rules 3353 for their Specification", RFC 3086, April 2001. 3355 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3356 of Explicit Congestion Notification (ECN) to IP", RFC 3357 3168, September 2001. 3359 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 3360 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3361 3175, September 2001. 3363 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 3364 Informal Management Model for Diffserv Routers", RFC 3290, 3365 May 2002. 3367 [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno 3368 Modification to TCP's Fast Recovery Algorithm", RFC 3782, 3369 April 2004. 3371 [RFC4080] R. Hancock, G. Karagiannis, J. Loughney, S. Van den 3372 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 3373 4080, June 2005 3375 Authors' Address 3377 James Polk 3378 3913 Treemont Circle 3379 Colleyville, Texas 76034 3381 Phone: +1.817.271.3552 3382 Email: jmpolk@cisco.com 3384 Appendix A - Changes 3386 Here is a list of all the changes that were captured during the 3387 editing process. This will not be a complete list, and others are 3388 free to point out what the authors missed, and we'll include that in 3389 the next release. 3391 A.1 Since RFC 4594 to Individual -00 3393 o rewrote Intro to emphasize current topics 3395 o Created a Conversational Service group, comprising the audio, 3396 video and Hi-Res service classes - because they have similar 3397 characteristics. 3399 o Incorporated the 6 new DSCPs from [ID-DSCP]. 3401 o moved the example section, en mass, to an appendix that might not 3402 be kept for this version. We're not sure it accomplishes what it 3403 needs to, and might not provide any real usefulness. 3405 o Moved 'Realtime-Interactive' service class to CS5, from CS4 3407 o Changed 'Broadcast Video' service class to 'Broadcast' service 3408 class 3410 o Changed AF4X to 'Video' service class, replacing 'Multimedia 3411 Conferencing' service class 3413 o Moved 'Multimedia Conferencing' service class to different DSCPs 3415 o Added the 'Hi-Res' service class 3417 o Removed section 5.1 on signaling choices. It has been included in 3418 the main body of the text. 3420 o Changed document title 3422 o removed the last 3 tables, as they were part of the examples 3423 section that is no longer within this document.