idnits 2.17.1 draft-polk-tsvwg-rfc4594-update-01.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 71 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 862 has weird spacing: '...ly. One examp...' == Line 2710 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 (July 16, 2012) is 4303 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: 'RFC4080' is mentioned on line 2729, but not defined == Missing Reference: 'ID-DSCP' is mentioned on line 3618, but not defined == Missing Reference: 'RFC4594' is mentioned on line 210, but not defined == Missing Reference: 'RFC3550' is mentioned on line 2168, but not defined == Missing Reference: 'RFC2326' is mentioned on line 3022, but not defined ** Obsolete undefined reference: RFC 2326 (Obsoleted by RFC 7826) == Unused Reference: 'RFC2996' is defined on line 3557, but no explicit reference was found in the text == Unused Reference: 'RFC3175' is defined on line 3568, 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, ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track (PS) July 16, 2012 5 Obsoletes: RFC 4594 6 Updates: RFC 5865 7 Expires: January 16, 2013 9 Standard Configuration of DiffServ Service Classes 10 draft-polk-tsvwg-rfc4594-update-01.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 January 16, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction ...................................................3 58 1.1. Requirements Notation .....................................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 2.4. Service Classes vs. Treatment Aggregate (from RFC 5127)...26 80 2.4.1 Examples of Service Classes in Treatment Aggregates...27 81 3. Network Control Traffic .......................................30 82 3.1. Current Practice in the Internet .........................30 83 3.2. Network Control Service Class ............................30 84 3.3. OAM Service Class ........................................32 85 4. User Oriented Traffic .........................................34 86 4.1. Conversational Service Class Group .......................35 87 4.1.1 Audio Service Class ..................................35 88 4.1.2 Video Service Class ..................................38 89 4.1.3 Hi-Res Service Class .................................42 90 4.2. Realtime-Interactive Service Class ...................... 46 91 4.3. Multimedia Conferencing Service Class ....................48 92 4.4. Multimedia Streaming Service Class .......................50 93 4.5. Broadcast Video Service Class ............................53 94 4.6. Low-Latency Data Service Class ...........................56 95 4.7. Conversational Signaling Service Class ...................58 96 4.8. High-Throughput Data Service Class .......................60 97 4.9. Standard Service Class ...................................63 98 4.10. Low-Priority Data .......................................64 99 5. Additional Information on Service Class Usage .................65 100 5.1. Mapping for NTP ..........................................65 101 5.2. VPN Service Mapping ......................................65 103 6. Security Considerations .......................................66 104 7. Contributing Authors ..........................................67 105 8. Acknowledgements ..............................................68 106 9. References ....................................................68 107 9.1. Normative References .....................................68 108 9.2. Informative References ...................................69 109 Author's Address .................................................70 110 Appendix A - Changes .............................................71 112 1. Introduction 114 Differentiated Services [RFC2474][RFC2475] provides the ability to 115 mark/label/classify IP packets differently to distinguish how 116 individual packets need to be treated differently through (or 117 throughout) a network on a per hop basis. Local administrators are 118 who configuration each router for which Differentiated Services Code 119 Points (DSCP) are to be treated differently, which are to be 120 ignored (i.e., no differentiated treatment), and which DSCPs are to 121 have their packets remarked (to different DSCPs) as they pass 122 through a router. Local administrators are also who assign which 123 applications, or traffic types, should use which DSCPs to receive 124 the treatment the administrators expect within their network. 126 What most people fail to understand is that DSCPs provide a per hop 127 behavior (PHB) through that router, but not the previous or next 128 router. In this way of understanding PHB markings, one can 129 understand that Differentiated Services (DiffServ) is not a Quality 130 of Service (QoS) mechanism, but rather a Classification of Service 131 (CoS) mechanism. 133 For instance, there are 64 possible DSCP values, i.e., using 6 bits 134 of the old Type of Service (TOS) byte [RFC0791]. Each can be 135 configured locally to have greater or less treatment relative to any 136 other DSCP with two exceptions*. 138 * Expedited Forwarding (EF) [RFC3246] DSCPs have a treatment 139 requirement that any packet marked within an EF class has to be 140 the next packet transmitted out its egress interface. If there 141 are more than one EF marked packet in the queue, obviously the 142 queue sets the order they are transmitted. Further, if there 143 are more than one EF DSCP, local configuration determines if 144 each are treated the same or differently relate to each other 145 EF DSCP. Currently, there are two Expedited Forwarding DSCPs: 146 EF (101110) [RFC3246] and VOICE-ADMIT (101100) [RFC5865]. 148 * Class Selector 6 (CS6) [RFC2474] is for routing protocol 149 traffic. There are deemed important because if the network does 150 not transmit and receive its routing protocol traffic in a 151 timely manner, the network stops operating properly. 153 Not all are configured to mean anything other than best effort 154 forwarding by local administrators of a network. Let us say there 155 are 5 DSCPs configured within network A. Network A's administrator 156 chooses and configures which order (obeying the two exceptions noted 157 above) which application packets are treated differently than any 158 other packets within that network (A). The DSCPs are not fixed to a 159 linear order for relative priority on a per hop basis. Further, and 160 this is often the case, there might be packets with the same DSCP 161 arriving at multiple interfaces of a node, each egressing that node 162 out the same interface. At ingress to this node, everything was 163 fine, with no poor behavior or noticeably excessive amount of 164 packets with the same DSCP. However, at the egress interface, there 165 might not be enough capacity to satisfy the load, thus the departing 166 packets transmit at their maximum rate for that DSCP, but have 167 additional latency due to the overload within that one node. This is 168 called fan-in (congestion or problem). By itself, DiffServ will not 169 remedy this problem for the application that is intolerant to added 170 latency because DiffServ only functions within 1 node at a time. 172 An additional mechanism is needed to ensure each flow or session 173 receives the amount of packets at its destination that the 174 application requires to perform properly; a mechanism such as 175 IntServ, by way of RSVP [RFC2205] or NSIS [RFC4080]. With this added 176 capability to be session aware, something DiffServ is not, the 177 packets transmitted within a single session have a very good 178 probability of arriving in such a way the receiving application can 179 make full use of each. That said, signaling reservations for each 180 session or flow adds complexity, which creates more work for those 181 who maintain and administer such a network. Adding bandwidth and 182 using DiffServ marking is an easier pill to swallow. The deployment 183 of not few, but more and more audio and (particularly bandwidth 184 hogging) video codecs and their respective application rigidity has 185 caused some to conclude that throwing bandwidth at the problem is no 186 longer acceptable. 188 With this in mind, this document incorporates five of the six new 189 DSCPs from [ID-DSCP] identified as capacity-admitted DSCPs for most 190 of the service classes in this document. As explained in [ID-DSCP], 191 the five new capacity-admitted DSCPs are from Pool 3. [ID-DSCP] goes 192 further to explain that may layer 2 technologies fewer bits for 193 marking and prioritization. Instead of six bits like DiffServ, they 194 have three bits, which yields a maximum of 8 values, which tend to 195 line up quite will with the TOS field values. Thus, aggregation of 196 DSCPs is typically accomplished by simply ignoring or reducing the 197 number of bits used to the most significant ones available, such as 199 EF is 101110, at layer 2 this is merely 101; 201 Broadcast is 011000, at layer 2 this is merely 011. 203 This document is originally built upon the RFC 4594 effort, while 204 updating some of the usages and expanding the scope for newer 205 applications that are in use today. 207 Service class definitions are based on the different traffic 208 characteristics and required performance of the 209 applications/services. There are a greater number of service classes 210 in this document than there were when RFC 4594 [RFC4594] was 211 published (the RFC this document intends to obsolete). The required 212 performance of applications/services has also changed since the 213 publication of RFC 4594, specifically in the area of conversational 214 real time communications. As a result, this document has a greater 215 number of real time applications with more granular set of DSCPs due 216 to their different required performances. Like RFC 4594 before, this 217 approach allows those applications with similar traffic 218 characteristics and performance requirements to be placed in the 219 same service class. 221 The notion of traffic characteristics and required performance is a 222 per application concept, therefore the label name of each service 223 class remains the same on an end-to-end basis, even if we understand 224 that DiffServ is only a PHB and cannot guarantee anything, even 225 packet delivery at the intended destination node. That said, 226 several applications can be configured to have the same DSCP, or 227 each have different DSCPs that have the same treatment per hop 228 within a network. 230 Since RFC 4594 was first published, a new concept has been 231 introduced that will appear throughout this document, including DSCP 232 assignments -- the idea of "admitted" traffic, initially introduced 233 into DiffServ within RFC 5865 [RFC5865]. The VOICE-ADMIT Expedited 234 Forwarding class differentiates itself from the EF Expedited 235 Forwarding by having the packets marked be for admitted traffic. 236 This concept of "admitted" traffic is spread throughout the real 237 time traffic classes. 239 Thus, the document flow is as follows: 241 o maintain the general format of RFC 4594; 243 o augment the content with the concept of capacity-admission; 245 o incorporate much more video into this document, as it has become 246 a dominant application in enterprises and other managed networks, 247 as well as on the open public Internet; 249 o reduce the discussion on voice and its examples; 251 o articulate the subtle differences learned since RFC 4594 was 252 published. 254 The goal here is to provide a standard configuration for DiffServ 255 DSCP assignments and expected PHBs for enterprises and other managed 256 networks, as well as towards the public Internet with specific 257 traffic characteristics per Service class/DSCP, and example 258 applications shown for each. 260 This document describes service classes configured with DiffServ and 261 recommends how they can be used and how to construct them using 262 Differentiated Services Code Points (DSCPs), traffic conditioners, 263 Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) 264 mechanisms. There is no intrinsic requirement that particular 265 DSCPs, traffic conditioners, PHBs, and AQM be used for a certain 266 service class, but as a policy and for interoperability it is useful 267 to apply them consistently. 269 We differentiate services and their characteristics in Section 2. 270 Network control traffic, as well as user oriented traffic are 271 discussed in Sections 3 and 4, respectively. We analyze the security 272 considerations in Section 6. Section 7 offers a tribute to the 273 authors of RFC 4594, from which this document is based. It is in its 274 own section, and not part of the normal acknowledgements portion of 275 each IETF document. 277 1.1. Requirements Notation 279 The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL 280 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 281 in this document are to be interpreted as described in [RFC2119]. 283 1.2. Expected Use in the Network 285 In the Internet today, corporate LANs and ISP WANs are increasingly 286 utilized, to the point in which network congestion is affecting 287 performance of applications. For this reason, congestion, loss, and 288 variation in delay within corporate LANs and ISP backbones is 289 becoming known to the users collectively as "the network is slow for 290 this application" or just "right now" or "for today". Users do not 291 directly detect network congestion. They react to applications that 292 run slow, or to downloads that take too long in their mind(s). The 293 explosion of video traffic on the internet recently has cause much 294 of this, and is often the application the user is using when they 295 have this slowness. 297 In the past, application slowness occurred for three very good 298 reasons. 300 o the networks the user oriented traffic traverses moves through 301 cycles of bandwidth boom and bandwidth bust, the latter of which 302 become apparent with the periodic deployment of new 303 bandwidth-hungry applications. 305 o In access networks, the state is often different. This may be 306 because throughput rates are artificially limited or 307 over-subscribed, or because of access network design trade-offs. 309 o Other characteristics, such as database design on web servers 310 (that may create contention points, e.g., in filestore) and 311 configuration of firewalls and routers, often look externally 312 like a bandwidth limitation. 314 The intent of this document is to provide a standardized marking, 315 plus a conditioning and packet treatment strategy so that it can be 316 configured and put into service on any link that is itself 317 congested. 319 1.3. Service Class Definition 321 A "service class" represents a similar set of traffic 322 characteristics for delay, loss, and jitter as packets traverse 323 routers in a network. For example, "High-Throughput Data" service 324 class for store-and-forward applications, or a "Broadcast" service 325 class for minimally time-shifted IPTV or Internet radio broadcasts. 326 Such a service class may be defined locally in a Differentiated 327 Services (DS) domain, or across multiple DS domains, possibly 328 extending end to end. A goal of this document is to have most/all 329 networks assign the same type of traffic the same for consistency. 331 A service class is a naming convention which is defined as a word, 332 phrase or initialism/acronym representing a set of necessary traffic 333 characteristics of a certain type of data flow. The necessary 334 characteristics of these traffic flows can be realized by the use of 335 defined per-hop behavior that started with [RFC2474]. The actual 336 specification of the expected treatment of a traffic aggregate 337 within a domain may also be defined as a per-domain behavior (PDB) 338 [RFC3086]. 340 Each domain will locally choose to 342 o implement one or more service classes with traffic 343 characteristics as defined here, or 345 o implement one or more service classes with similar traffic 346 characteristics as defined here, or 348 o implement one or more service classes with similar traffic 349 characteristics as defined here and to aggregate one or more 350 service classes to reduce the number of unique DSCPs within their 351 network, or 353 o implement one or more non-standard service classes with traffic 354 characteristics not as defined here, or 356 o not use DiffServ within their domain. 358 For example, low delay, low loss, and minimal jitter may be realized 359 using the EF PHB, or with an over-provisioned AF PHB. This must be 360 done with care as it may disrupt the end-to-end performance required 361 by the applications/services. If the packet sizes are similar within 362 an application, but different between two applications, say small 363 voice packets and large video packets, these two applications may 364 not realize optimum results if merged into the same aggregate if 365 there are any bottlenecks in the network. We provide for this 366 flexibility on a per hop or per domain basis within this document. 368 This document provides standardized markings for traffic with 369 similar characteristics, and usage expectations for PHBs for 370 specific service classes for their consistent implementation. 372 The Default Forwarding "Standard" service class is REQUIRED; all 373 other service classes are OPTIONAL. That said, each service class 374 lists traffic characteristics that are expected when using that type 375 of traffic. It is RECOMMENDED that applications and protocols that 376 fit a certain traffic characteristic use the appropriate service 377 class mark, i.e., the DSCP, for consistent behavior. It is expected 378 that network administrators will base their endpoint application and 379 router configuration choices on the level of service differentiation 380 they require to meet the needs of their customers (i.e., their 381 end-users). 383 1.4. Key Differentiated Services Concepts 385 In order to fully understand this document, a reader needs to 386 familiarize themselves with the principles of the Differentiated 387 Services Architecture [RFC2474]. We summarize some key concepts 388 here only to provide convenience for the reader, the referenced RFCs 389 providing the authoritative definitions. 391 1.4.1. Queuing 393 A queue is a data structure that holds packets that are awaiting 394 transmission. A router interface can only transmit one packet at a 395 time, however fast the interface speed is. If there is only 1 queue 396 at an interface, the packets are transmitted in the order they are 397 received into that queue - called FIFO, or "first in, first out". 398 Sometimes there is a lag in the time between a packets arrives in 399 the queue and when it is transmitted. This delay might be due to 400 lack of bandwidth, or if there are multiple queues on that 401 interface, because a packet is low in priority relative to other 402 packets that are awaiting to transmit. The scheduler is the system 403 entity that chooses which packet is next in line for transmission 404 when more than one packet are awaiting transmission out the same 405 router interface. 407 1.4.1.1 Priority Queuing 409 A priority queuing system is a combination of a set of queues and a 410 scheduler that empties the queues (of packets) in priority sequence. 411 When asked for a packet, the scheduler inspects the highest 412 priority queue and, if there is data present, returns a packet from 413 that queue. Failing that, it inspects the next highest priority 414 queue, and so on. A freeway onramp with a stoplight for one lane 415 that allows vehicles in the high-occupancy-vehicle lane to pass is 416 an example of a priority queuing system; the high-occupancy-vehicle 417 lane represents the "queue" having priority. 419 In a priority queuing system, a packet in the highest priority queue 420 will experience a readily calculated delay. This is proportional to 421 the amount of data remaining to be serialized when the packet 422 arrived plus the volume of the data already queued ahead of it in 423 the same queue. The technical reason for using a priority queue 424 relates exactly to this fact: it limits delay and variations in 425 delay and should be used for traffic that has that requirement. 427 A priority queue or queuing system needs to avoid starvation of 428 lower-priority queues. This may be achieved through a variety of 429 means, such as admission control, rate control, or network 430 engineering. 432 1.4.1.2. Rate Queuing 434 Similarly, a rate-based queuing system is a combination of a set of 435 queues and a scheduler that empties each at a specified rate. An 436 example of a rate-based queuing system is a road intersection with a 437 stoplight. The stoplight acts as a scheduler, giving each lane a 438 certain opportunity to pass traffic through the intersection. 440 In a rate-based queuing system, such as Weighted Fair Queuing (WFQ) 441 or Weighted Round Robin (WRR), the delay that a packet in any given 442 queue will experience depends on the parameters and occupancy of its 443 queue and the parameters and occupancy of the queues it is competing 444 with. A queue whose traffic arrival rate is much less than the rate 445 at which it lets traffic depart will tend to be empty, and packets 446 in it will experience nominal delays. A queue whose traffic arrival 447 rate approximates or exceeds its departure rate will tend not to be 448 empty, and packets in it will experience greater delay. Such a 449 scheduler can impose a minimum rate, a maximum rate, or both, on any 450 queue it touches. 452 1.4.2 Active Queue Management 454 Active Queue Management, or AQM, is a generic name for any of a 455 variety of procedures that use packet dropping or marking to manage 456 the depth of a queue. The canonical example of such a procedure is 457 Random Early Detection (RED), in that a queue is assigned a minimum 458 and maximum threshold, and the queuing algorithm maintains a moving 459 average of the queue depth. While the mean queue depth exceeds the 460 maximum threshold, all arriving traffic is dropped. While the mean 461 queue depth exceeds the minimum threshold but not the maximum 462 threshold, a randomly selected subset of arriving traffic is marked 463 or dropped. This marking or dropping of traffic is intended to 464 communicate with the sending system, causing its congestion 465 avoidance algorithms to kick in. As a result of this behavior, it 466 is reasonable to expect that TCP's cyclic behavior is desynchronized 467 and that the mean queue depth (and therefore delay) should normally 468 approximate the minimum threshold. 470 A variation of the algorithm is applied in Assured Forwarding PHB 471 [RFC2597], in that the behavior aggregate consists of traffic with 472 multiple DSCP marks, which are intermingled in a common queue. 473 Different minima and maxima are configured for the several DSCPs 474 separately, such that traffic that exceeds a stated rate at ingress 475 is more likely to be dropped or marked than traffic that is within 476 its contracted rate. 478 1.4.3 Traffic Conditioning 480 In addition, at the first router in a network that a packet crosses, 481 arriving traffic may be measured and dropped or marked according to 482 a policy, or perhaps shaped on network ingress, as in "A Rate 483 Adaptive Shaper for Differentiated Services" [RFC2963]. This may be 484 used to bias feedback loops, as is done in "Assured Forwarding PHB" 485 [RFC2597], or to limit the amount of traffic in a system, as is done 486 in "Expedited Forwarding PHB" [RFC3246]. Such measurement 487 procedures are collectively referred to as "traffic conditioners". 488 Traffic conditioners are normally built using token bucket meters, 489 for example with a committed rate and burst size, as in Section 490 1.5.3 of the DiffServ Model [RFC3290]. The Assured Forwarding PHB 491 [RFC2597] uses a variation on a meter with multiple rate and burst 492 size measurements to test and identify multiple levels of 493 conformance. 495 Multiple rates and burst sizes can be realized using multiple levels 496 of token buckets or more complex token buckets; these are 497 implementation details. The following are some traffic conditioners 498 that may be used in deployment of differentiated services: 500 o For Class Selector (CS) PHBs, a single token bucket meter to 501 provide a rate plus burst size control. 503 o For Expedited Forwarding (EF) PHB, a single token bucket meter to 504 provide a rate plus burst size control. 506 o For Assured Forwarding (AF) PHBs, usually two token bucket meters 507 configured to provide behavior as outlined in "Two Rate Three 508 Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color 509 Marker (srTCM)" [RFC2697]. The two-rate, three-color marker is 510 used to enforce two rates, whereas the single-rate, three-color 511 marker is used to enforce a committed rate with two burst 512 lengths. 514 1.4.4 Differentiated Services Code Point (DSCP) 516 The DSCP is a number in the range 0..63 that is placed into an IP 517 packet to mark it according to the class of traffic it belongs in. 518 These are divided into 3 groups, or pools, defined in RFC 2474, 519 arranged as follows: 521 o Pool-1 has 32 values designated for standards assignment (of the 522 form 'xxxxx0'). 524 o Pool-2 has 16 values designated for experimental or local use 525 only (EXP/LU) assignment (of the form 'xxxx11'). 527 o Pool-3 has 16 values designated for experimental or local use 528 (EXP/LU) assignment (of the form 'xxxx01'). 530 However, pool-3 is allowed to be assigned for one of two reasons, 532 #1 - if the values in pool-1 are exhausted, or 534 #2 - if there is a justifiable reason for assigning a pool-3 DSCP 535 prior to pool-1's exhaustion. 537 1.4.5 Per-Hop Behavior (PHB) 539 In the end, the mechanisms described above are combined to form a 540 specified set of characteristics for handling different kinds of 541 traffic, depending on the needs of the application. This document 542 seeks to identify useful traffic aggregates and to specify what PHB 543 should be applied to them. 545 1.5 Key Service Concepts 547 While Differentiated Services is a general architecture that may be 548 used to implement a variety of services, three fundamental 549 forwarding behaviors have been defined and characterized for general 550 use. These are basic Default Forwarding (DF) behavior for elastic 551 traffic, the Assured Forwarding (AF) behavior, and the Expedited 552 Forwarding (EF) behavior for real-time (inelastic) traffic. The 553 facts that four code points are recommended for AF and that one code 554 point is recommended for EF are arbitrary choices, and the 555 architecture allows any reasonable number of AF and EF classes 556 simultaneously. The choice of four AF classes and one EF class in 557 the current document is also arbitrary, and operators MAY choose to 558 operate more or fewer of either. 560 The terms "elastic" and "real-time" are defined in [RFC1633], 561 Section 3.1, as a way of understanding broad-brush application 562 requirements. This document should be reviewed to obtain a broad 563 understanding of the issues in quality of service, just as [RFC2475] 564 should be reviewed to understand the data plane architecture used in 565 today's Internet. 567 1.5.1 Default Forwarding (DF) 569 The basic forwarding behaviors applied to any class of traffic are 570 those described in [RFC2474] and [RFC2309]. Best-effort service may 571 be summarized as "I will accept your packets" and is typically 572 configured with some bandwidth guarantee. Packets in transit may be 573 lost, reordered, duplicated, or delayed at random. Generally, 574 networks are engineered to limit this behavior, but changing traffic 575 loads can push any network into such a state. 577 Application traffic in the internet that uses default forwarding is 578 expected to be "elastic" in nature. By this, we mean that the 579 sender of traffic will adjust its transmission rate in response to 580 changes in available rate, loss, or delay. 582 For the basic best-effort service, a single DSCP value is provided 583 to identify the traffic, a queue to store it, and active queue 584 management to protect the network from it and to limit delays. 586 1.5.2 Assured Forwarding (AF) 588 The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled 589 on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss 590 Priority (CLP) capability. It is intended for networks that offer 591 average-rate Service Level Agreements (SLAs) (as FR and ATM networks 592 do). This is an enhanced best-effort service; traffic is expected 593 to be "elastic" in nature. The receiver will detect loss or 594 variation in delay in the network and provide feedback such that the 595 sender adjusts its transmission rate to approximate available 596 capacity. 598 For such behaviors, multiple DSCP values are provided (two or three, 599 perhaps more using local values) to identify the traffic, a common 600 queue to store the aggregate, and active queue management to protect 601 the network from it and to limit delays. Traffic is metered as it 602 enters the network, and traffic is variously marked depending on the 603 arrival rate of the aggregate. The premise is that it is normal for 604 users occasionally to use more capacity than their contract 605 stipulates, perhaps up to some bound. However, if traffic should be 606 marked or lost to manage the queue, this excess traffic will be 607 marked or lost first. 609 1.5.3. Expedited Forwarding (EF) 611 The intent of Expedited Forwarding PHB [RFC3246] is to provide a 612 building block for low-loss, low-delay, and low-jitter services. It 613 can be used to build an enhanced best-effort service: traffic 614 remains subject to loss due to line errors and reordering during 615 routing changes. However, using queuing techniques, the probability 616 of delay or variation in delay is minimized. For this reason, it is 617 generally used to carry voice and for transport of data information 618 that requires "wire like" behavior through the IP network. Voice is 619 an inelastic "real-time" application that sends packets at the rate 620 the codec produces them, regardless of availability of capacity. As 621 such, this service has the potential to disrupt or congest a network 622 if not controlled. It also has the potential for abuse. 624 To protect the network, at minimum one SHOULD police traffic at 625 various points to ensure that the design of a queue is not overrun, 626 and then the traffic SHOULD be given a low-delay queue (often using 627 priority, although it is asserted that a rate-based queue can do 628 this) to ensure that variation in delay is not an issue, to meet 629 application needs. 631 1.5.4 Class Selector (CS) 633 Class Selector, those DSCPs that end in zeros (xxx000), provide 634 support for historical codepoint definitions and PHB requirement. 635 The CS fields provide a limited backward compatibility with legacy 636 practice, as described in [RFC2474], Section 4. Backward 637 compatibility is addressed in two ways, 639 - First, there are per-hop behaviors that are already in widespread 640 use (e.g., those satisfying the IPv4 Precedence queuing 641 requirements specified in [RFC1812]), and 643 - this document will continue to permit their use in DS-compliant 644 networks. 646 In addition, there are some DSCPs that correspond to historical use 647 of the IP Precedence field, 649 - CS0 (000000) will remain 'Default Forwarding' (also know as 'Best 650 Effort') 652 - 11xxxx will remain for routing traffic 654 and will map to PHBs that meet the general requirements specified in 655 [RFC2474], Section 4.2.2.2. 657 No attempt is made to maintain backward compatibility with the "DTR" 658 or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in 659 [RFC0791] and [RFC1349]. 661 A DS-compliant network can be deployed exclusively by using one or 662 more CS-compliant PHB groups. Thus, for example, codepoint '011000' 663 would map to the same PHB as codepoint '011010'. 665 1.5.5 Admission Control 667 Admission control (including refusal when policy thresholds are 668 crossed) can ensure high-quality communication by ensuring the 669 availability of bandwidth to carry a load. Inelastic real-time 670 flows such as Voice over Internet Protocol (VoIP) (audio) or video 671 conferencing services can benefit from use of an admission control 672 mechanism, as generally the audio or video service is configured 673 with over-subscription, meaning that some users may not be able to 674 make a call during peak periods. 676 For VoIP (audio) service, a common approach is to use signaling 677 protocols such as SIP, H.323, H.248, MEGACO, along with Resource 678 Reservation Protocol (RSVP) to negotiate admittance and use of 679 network transport capabilities. When a user has been authorized to 680 send voice traffic, this admission procedure has verified that data 681 rates will be within the capacity of the network that it will use. 682 Many RTP voice and video payloads are inelastic and cannot react to 683 loss or delay in any substantive way. For these payload types, the 684 network needs to police at ingress to ensure that the voice traffic 685 stays within its negotiated bounds. Having thus assured a 686 predictable input rate, the network may use a priority queue to 687 ensure nominal delay and variation in delay. 689 1.5.5.1 Capacity Admitted (*-Admit) 691 This is a newer group of traffic types that started with RFC 5865 692 and the Voice-Admit service type. Voice-Admit is an EF class marking 693 but has capacity-admission always applied to it to ensure each of 694 these flows are managed through a network, though not necessarily on 695 an end-to-end basis. This depends on how many networks each flow 696 transits and the load on each transited network. There are a series 697 of new DSCPs proposed in [ID-DSCP], each specifying unique 698 characteristics necessitating a separate marking from what existing 699 before that document. 701 This document will import in four new '*-Admit' DSCPs from 702 [ID-DSCP], 2 others that are new but not capacity-admitted, one from 703 RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594. 704 This is discussed throughout the rest of this document. 706 2. Service Differentiation 708 There are practical limits on the level of service differentiation 709 that should be offered in the IP networks. We believe we have 710 defined a practical approach in delivering service differentiation 711 by defining different service classes that networks may choose to 712 support in order to provide the appropriate level of behaviors and 713 performance needed by current and future applications and services. 714 The defined structure for providing services allows several 715 applications having similar traffic characteristics and performance 716 requirements to be grouped into the same service class. This 717 approach provides a lot of flexibility in providing the appropriate 718 level of service differentiation for current and new, yet unknown 719 applications without introducing significant changes to routers or 720 network configurations when a new traffic type is added to the 721 network. 723 2.1 Service Classes 725 Traffic flowing in a network can be classified in many different 726 ways. We have chosen to divide it into two groupings, network 727 control and user/subscriber traffic. To provide service 728 differentiation, different service classes are defined in each 729 grouping. The network control traffic group can further be divided 730 into two service classes (see Section 3 for detailed definition of 731 each service class): 733 o "Network Control" for routing and network control function. 735 o "OAM" (Operations, Administration, and Management) for network 736 configuration and management functions. 738 The user/subscriber traffic group is broken down into ten service 739 classes to provide service differentiation for all the different 740 types of applications/services (see Section 4 for detailed 741 definition of each service class): 743 o Conversational service group consists of three service classes: 745 - Audio, which includes both 'admitted' and 'unadmitted' audio 746 service classes, is for non-one way (i.e., generally 747 bidirectional) audio media packets between human users of 748 smaller size and at a constant delivery rate. 750 - Hi-Res Video, which includes both 'admitted' and 'unadmitted' 751 Hi-Res Video service classes, is for video traffic from higher 752 end endpoints between human users necessitating different 753 treatment that from desktop or video phone endpoints. This has 754 a clearly business differentiation, and not a technical 755 differentiation - as both Hi-Res-Video and Video will be 756 treated similarly on the wire when no congestion occurs. 758 - Video, which includes both 'admitted' and 'unadmitted' video 759 service classes, is for video traffic from lower end endpoints 760 between human users necessitating different treatment that 761 from higher end (i.e., Telepresence) endpoints. This has a 762 clearly business differentiation, and not a technical 763 differentiation - as both Hi-Res-Video and Video will be 764 treated similarly on the wire when no congestion occurs. 766 o Conversational Signaling service class is for peer-to-peer and 767 client-server signaling and control functions using protocols 768 such as SIP, H.323, H.248, and Media Gateway Control Protocol 769 (MGCP). This traffic needs to not be starved on the network. 771 Editor's note: RFC 4594 had this DSCP marking as CS5, but with 772 clearly different characteristics (i.e., no 773 sensitivity to jitter or (unreasonable) delay), this 774 DSCP has been moved to a more appropriate (new) 775 value, defined in [ID-DSCP]. 777 o Real-Time Interactive, which includes both 'admitted' and 778 'unadmitted' Realtime-Interactive service class, is for 779 bidirectional variable rate inelastic applications that require 780 low jitter and loss and very low delay, such as interactive 781 gaming applications that use RTP/UDP streams for game control 782 commands, and Virtualized Desktop applications between the user 783 and content source, typically in a centralized data center. 785 o Multimedia Conferencing, which includes both 'admitted' and 786 'unadmitted' multimedia conferencing service class, is for 787 applications that require minimal delay, but not like those of 788 realtime application requirements. This service class can be 789 bursty in nature, as well as not transmit packets for some time. 790 Applications such as presentation data or collaborative 791 application sharing will use this service class. 793 o Multimedia Streaming, which includes both 'admitted' and 794 'unadmitted' multimedia streaming service class, is for one-way 795 bufferable streaming media applications such as Video on Demand 796 (VOD) and webcasts. 798 o Broadcast, which includes both 'admitted' and 'unadmitted' 799 broadcast service class, is for inelastic streaming media 800 applications that may be of constant or variable rate, requiring 801 low jitter and very low packet loss, such as broadcast TV and 802 live events, video surveillance, and security. 804 o Low-Latency Data service class is for data processing 805 applications such as client/server interactions or Instant 806 Messaging (IM) and Presence data. 808 o Conversational Signaling (A/V-Sig) service class is for all 809 signaling messages, whether in-band (i.e., along the data path) 810 or out-of-band (separate from the data path), for the purposes of 811 setting up, maintaining, managing and terminating bi- or 812 multi-directional realtime sessions. 814 o High-Throughput Data service class is for store and forward 815 applications such as FTP and billing record transfer. 817 o Standard service class, commonly called best effort (BE), is for 818 traffic that has not been identified as requiring differentiated 819 treatment. 821 o Low-Priority Data service class, which some could call the 822 scavenger class, is for packet flows where bandwidth assurance is 823 not required. 825 2.2 Categorization of User Oriented Service Classes 827 The ten defined user/subscriber service classes listed above can be 828 grouped into a small number of application categories. For some 829 application categories, it was felt that more than one service class 830 was needed to provide service differentiation within that category 831 due to the different traffic characteristic of the applications, 832 control function, and the required flow behavior. Figure 1 provides 833 a summary of service class grouping into four application categories. 835 Application Control Category 837 o The Conversational Signaling service class is intended to be used 838 to control applications or user endpoints. Examples of protocols 839 that would use this service class are SIP, XMPP or H.323 for 840 voice and/or video over IP services. User signaling flows have 841 similar performance requirements as Low-Latency Data, they 842 require a separate DSCP to be distinguished other traffic and 843 allow for a treatment that is unique. 845 Media-Oriented Category 847 Due to the vast number of new (in process of being deployed) and 848 already-in-use media-oriented services in IP networks, seven service 849 classes have been defined. 851 o Audio service class is intended for Voice-over-IP (VoIP) 852 services. It may also be used for other applications that meet 853 the defined traffic characteristics and performance requirements. 855 o Video service class is intended for Video over IP services. It 856 may also be used for other applications that meet the defined 857 traffic characteristics and performance requirements. 859 o Hi-Res service class is intended for higher end video services 860 that have the same traffic characteristics as the video service 861 class, but have a business requirement(s) to be treated 862 differently. One example of this is Telepresence video 863 applications. 865 o Realtime-Interactive service class is intended for inelastic 866 applications such as desktop virtualization applications and for 867 interactive gaming. 869 o Multimedia Conferencing service class is for everything about or 870 within video conferencing solutions that does not include the 871 voice or (human) video components. Several examples are 873 - the presentation data part of an IP conference (call). 875 - the application sharing part of an IP conference (call). 877 - the whiteboarding aspect of an IP conference (call). 879 Each of the above can be part of a lower end web-conferencing 880 application or part of a higher end Telepresence video 881 conference. Each also has the ability to reduce their 882 transmission rate on detection of congestion. These flows can 883 therefore be classified as rate adaptive and most often more 884 elastic than their voice and video counterparts. 886 o Broadcast Video service class is to be used for inelastic traffic 887 flows specifically with minimal buffering expected by the source 888 or destination, which are intended for broadcast HDTV service, as 889 well as for transport of live video (sports or concerts) and 890 audio events. 892 o Multimedia Streaming service class is to be used for elastic 893 multimedia traffic flows where buffering is expected. This is 894 the fundamental difference between the Broadcast and multimedia 895 streaming service classes. Multimedia streaming content is 896 typically stored before being transmitted. It is also buffered 897 at the receiving end before being played out. The buffering is 898 sufficiently large to accommodate any variation in transmission 899 rate that is encountered in the network. Multimedia 900 entertainment over IP delivery services that are being developed 901 can generate both elastic and inelastic traffic flows; therefore, 902 two service classes are defined to address this space, 903 respectively: Multimedia Streaming and Broadcast Video. 905 Data Category 907 The data category is divided into three service classes. 909 o Low-Latency Data for applications/services that require low delay 910 or latency for bursty but short-lived flows. 912 o High-Throughput Data for applications/services that require good 913 throughput for long-lived bursty flows. High Throughput and 914 Multimedia Steaming are close in their traffic flow 915 characteristics with High Throughput being a bit more bursty and 916 not as long-lived as Multimedia Streaming. 918 o Low-Priority Data for applications or services that can tolerate 919 short or long interruptions of packet flows. The Low-Priority 920 Data service class can be viewed as "don't care" to some degree. 922 Best-Effort Category 924 o All traffic that is not differentiated in the network falls into 925 this category and is mapped into the Standard service class. If 926 a packet is marked with a DSCP value that is not supported in the 927 network, it SHOULD be forwarded using the Standard service class. 929 Figure 1, below, provides a grouping of the defined user/subscriber 930 service classes into four categories, with indications of which ones 931 use an independent flow for signaling or control; type of flow 932 behavior (elastic, rate adaptive, or inelastic); and the last column 933 provides end user Class of Service (CoS) rating as defined in ITU-T 934 Recommendation G.1010. 936 +-----------------------------------------------------------------+ 937 | Application | Service | Signaled | Flow | G.1010 | 938 | Categories | Class | | Behavior | Rating | 939 |-------------+---------------+----------+-----------+------------| 940 | Application | A/V Sig | Not | Inelastic | Responsive | 941 | Control | |applicable| | | 942 |-------------+---------------+----------+-----------+------------| 943 | | Real-Time | Yes | Inelastic | Interactive| 944 | | Interactive | | | | 945 | |---------------+----------+-----------+------------| 946 | | Audio | Yes | Inelastic | Interactive| 947 | |---------------+----------+-----------+------------| 948 | | Video | Yes | Inelastic | Interactive| 949 | |---------------+----------+-----------+------------| 950 | | Hi-Res | Yes | Inelastic | Interactive| 951 | |---------------+----------+-----------+------------| 952 | Media- | Multimedia | Yes | Rate | Moderately | 953 | Oriented | Conferencing| | Adaptive | Interactive| 954 | |---------------+----------+-----------+------------| 955 | | Broadcast | Yes | Inelastic | Responsive | 956 | |---------------+----------+-----------+------------| 957 | | Multimedia | Yes | Elastic | Timely | 958 | | Streaming | | | | 959 |-------------+---------------+----------+-----------+------------| 960 | | Low-Latency | No | Elastic | Responsive | 961 | | Data | | | | 962 | |---------------+----------+-----------+------------| 963 | Data | Conversational| No |Elastic or | Timely | 964 | | Signaling | | Inelastic | | 965 | |---------------+----------+-----------+------------| 966 | | High- | No | Elastic | Timely | 967 | |Throughput Data| | | | 968 | |---------------+----------+-----------+------------| 969 | | Low- | No | Elastic |Non-critical| 970 | | Priority Data | | | | 971 |-------------+---------------+----------+-----------+------------| 972 | Best Effort | Standard | Not Specified |Non-critical| 973 +-----------------------------------------------------------------+ 975 Figure 1. User/Subscriber Service Classes Grouping 977 Here is a short explanation of the end user CoS category as defined 978 in ITU-T Recommendation G.1010. User oriented traffic is divided 979 into four different categories, namely, interactive, responsive, 980 timely, and non-critical. An example of interactive traffic is 981 between two humans and is most sensitive to delay, loss, and jitter. 982 Another example of interactive traffic is between two servers where 983 very low delay and loss are needed. Responsive traffic is typically 984 between a human and a server but can also be between two servers. 985 Responsive traffic is less affected by jitter and can tolerate 986 longer delays than interactive traffic. Timely traffic is either 987 between servers or servers and humans and the delay tolerance is 988 significantly longer than responsive traffic. Non-critical traffic 989 is normally between servers/machines where delivery may be delay for 990 period of time. 992 2.3. Service Class Characteristics 994 This document specifies what network administrators are to expect 995 when configuring service classes identified by their differing 996 characteristics. Figure 2 identifies these service classes along 997 with their characteristics, as well as the tolerance to loss, delay 998 and jitter for each service class. Properly engineered networks to 999 these PHBs will achieve expected results. That said, not all of the 1000 identified service classes are expected in each operator's network. 1002 +-------------------------------------------------------------------+ 1003 |Service Class | | Tolerance to | 1004 | Name | Traffic Characteristics | Loss |Delay |Jitter| 1005 |===============+==============================+======+======+======| 1006 | Network |Variable size packets, mostly | | | | 1007 | Control |inelastic short messages, but | Low | Low | Yes | 1008 | |traffic can also burst (BGP) | | | | 1009 |---------------+------------------------------+------+------+------| 1010 | Real-Time | Inelastic, mostly variable | Low | Very | Low | 1011 | Interactive | rate | | Low | | 1012 +---------------+------------------------------+------+------+------+ 1013 | | Fixed-size small packets, | Very | Very | Very | 1014 | Audio | inelastic | Low | Low | Low | 1015 | | | | | | 1016 +---------------+------------------------------+------+------+------+ 1017 | | Fixed-size small-large | Very | Very | Very | 1018 | Video | packets, inelastic | Low | Low | Low | 1019 | | | | | | 1020 +---------------+------------------------------+------+------+------+ 1021 | | Fixed-size small-large | Very | Very | Very | 1022 | Hi-Res A/V | packets, inelastic | Low | Low | Low | 1023 | | | | | | 1024 +---------------+------------------------------+------+------+------+ 1025 | Multimedia | Variable size packets, | Low | Low | Low | 1026 | Conferencing | constant transmit interval, | - | - | - | 1027 | | rate adaptive, reacts to loss|Medium|Medium|Medium| 1028 +---------------+------------------------------+------+------+------+ 1029 | Multimedia | Variable size packets, |Low - |Medium| High | 1030 | Streaming | elastic with variable rate |Medium| | | 1031 +---------------+------------------------------+------+------+------+ 1032 | Broadcast | Constant and variable rate, | Very |Medium| Low | 1033 | | inelastic, non-bursty flows | Low | | | 1034 +---------------+------------------------------+------+------+------+ 1035 | Low-Latency | Variable rate, bursty short- | Low |Low - | Yes | 1036 | Data | lived elastic flows | |Medium| | 1037 |---------------+------------------------------+------+------+------| 1038 |Conversational | Variable size packets, some | Low | Low | Yes | 1039 | Signaling | what bursty short-lived flows| | | | 1040 |---------------+------------------------------+------+------+------| 1041 | OAM | Variable size packets, | Low |Medium| Yes | 1042 | | elastic & inelastic flows | | | | 1043 |---------------+------------------------------+------+------+------| 1044 | High- | Variable rate, bursty long- | Low |Medium| Yes | 1045 |Throughput Data| lived elastic flows | |- High| | 1046 |---------------+------------------------------+------+------+------| 1047 | Standard | A bit of everything | Not Specified | 1048 |---------------+------------------------------+------+------+------| 1049 | Low-Priority | Non-real-time and elastic | High | High | Yes | 1050 | Data | | | | | 1051 +-------------------------------------------------------------------+ 1053 Figure 2. Service Class Characteristics 1055 Notes for Figure 2: A "Yes" in the jitter-tolerant column implies 1056 that received data is buffered at the endpoint and that a moderate 1057 level of server or network-induced variation in delay is not 1058 expected to affect the application. Applications that use TCP or 1059 SCTP as a transport are generally good examples. Routing protocols 1060 and peer-to-peer signaling also fall in this class; although loss 1061 can create problems in setting up calls, a moderate level of jitter 1062 merely makes call placement a little less predictable in duration. 1064 Service classes indicate the required traffic forwarding treatment 1065 in order to meet user, application, and/or network expectations. 1066 Section 3 defines the service classes that MAY be used for 1067 forwarding network control traffic, and Section 4 defines the 1068 service classes that MAY be used for forwarding user oriented 1069 traffic with examples of intended application types mapped into each 1070 service class. Note that the application types are only examples 1071 and are not meant to be all-inclusive or prescriptive. Also, note 1072 that the service class naming or ordering does not imply any 1073 priority ordering. They are simply reference names that are used in 1074 this document with associated QoS behaviors that are optimized for 1075 the particular application types they support. Network 1076 administrators MAY choose to assign different service class names to 1077 the service classes that they will support. Figure 3 defines the 1078 RECOMMENDED relationship between service classes and DS codepoint 1079 assignment with application examples. It is RECOMMENDED that this 1080 relationship be preserved end to end. 1082 +------------------------------------------------------------------+ 1083 | Service | DSCP | DSCP | Application | 1084 | Class Name | Name | Value | Examples | 1085 |===============+=========+=============+==========================| 1086 |Network Control| CS6&CS7 | 11xxxx | Network routing | 1087 |---------------+---------+-------------+--------------------------| 1088 | Real-Time | CS5, | 101000, | Remote/Virtual Desktop | 1089 | Interactive |CS5-Admit| 101001 | and Interactive gaming | 1090 |---------------+---------+-------------+--------------------------| 1091 | Audio | EF | 101110 | Voice bearer | 1092 | |Voice-Admit| 101100 | | 1093 |---------------+---------+-------------+--------------------------| 1094 | Hi-Res A/V | CS4, | 100000, | Conversational Hi-Res | 1095 | |CS4-Admit| 100001 | Audio/Video bearer | 1096 |---------------+---------+-------------+--------------------------| 1097 | Video |AF41,AF42|100010,100100| Audio/Video conferencing | 1098 | | AF43 | 100110 | bearer | 1099 |---------------+---------+-------------+--------------------------| 1100 | Multimedia | MC, | 011101, | Presentation Data and | 1101 | Conferencing | MC-Admit| 100101 | App Sharing/Whiteboarding| 1102 |---------------+---------+-------------+--------------------------| 1103 | Multimedia |AF31,AF32|011010,011100| Streaming video and | 1104 | Streaming | AF33 | 011110 | audio on demand | 1105 |---------------+---------+-------------+--------------------------| 1106 | Broadcast | CS3, | 011000, | Broadcast TV, live events| 1107 | |CS3-Admit| 011001 | & video surveillance | 1108 |---------------+---------+-------------+--------------------------| 1109 | Low-Latency |AF21,AF22|010010,010100|Client/server trans., Web-| 1110 | Data | AF23 | 010110 |based ordering, IM/Pres | 1111 |---------------+---------+-------------+--------------------------| 1112 |Conversational | A/V-Sig | 010001 | Conversational signaling | 1113 | Signaling | | | | 1114 |---------------+---------+-------------+--------------------------| 1115 | OAM | CS2 | 010000 | OAM&P | 1116 |---------------+---------+-------------+--------------------------| 1117 |High-Throughput|AF11,AF12|001010,001100| Store and forward | 1118 | Data | AF13 | 001110 | applications | 1119 |---------------+---------+-------------+--------------------------| 1120 | Low-Priority | CS1 | 001000 | Any flow that has no BW | 1121 | Data | | | assurance | 1122 |------------------------------------------------------------------| 1123 | Best Effort | CS0 | 000000 | Undifferentiated | 1124 | | | | applications | 1125 +---------------+---------+-------------+--------------------------+ 1127 Figure 3. DSCP to Service Class Mapping 1129 Notes for Figure 3: 1131 o Default Forwarding (DF) and Class Selector 0 (CS0) (i.e., Best 1132 Effort) provide equivalent behavior and use the same DS 1133 codepoint, '000000'. 1135 o RFC 2474 identifies any DSCP with a value of 11xxxx to be for 1136 network control. This remains true, while it removes 12 DSCPs 1137 from the overall pool of 64 available DSCP values (the 4 that are 1138 x11 from this group are within pool 2 of RFC 2474, and remain as 1139 only experimentally assignable/useable). 1141 o All PHB names that say "-Admit" are to be used only when a 1142 capacity-admission protocol is utilized for that or each traffic 1143 flow. 1145 Changes from table 3 of RFC 4594 are as follows: 1147 o The old term "Signaling" was using CS5 (101000), now is 1148 exclusively for the "Conversational Signaling" service group 1149 using the DSCP name of "A/V-Sig" (010001), which is newly defined 1150 in [ID-DSCP]. This is because CS5 aggregates into the 101xxx 1151 aggregate when using layer 2 technologies such as 802.3 Ethernet, 1152 802.11 Wireless Ethernet MPLS, etc - each of which only have 3 1153 bits to mark with. A traffic type that can have very large 1154 packets and is not delay sensitive (within reason) is not 1155 appropriate for have a 101xxx marking. A REQUIRED behavior for 1156 this PHB is that it not be starved in any node. 1158 o "Conversational" is a new term to include all interactive audio 1159 and video. The Conversational service group consists of the audio 1160 service class, the video service class and the new Hi-Res service 1161 class. 1163 o "Audio" obsoletes the term "Telephony", which has generally not 1164 retained the "video" aspect within the IETF, where video is still 1165 commonly called out as a separate thing. Audio retains the 1166 nonadmitted traffic PHB of EF (101110), while capacity-admitted 1167 audio has been added via the RFC 5865 defined PHB Voice-Admit. 1169 o "Video" now is AF4x, with AF41 specifically for capacity-admitted 1170 video traffic, while AF42 and AF43 are nonadmitted video traffic. 1172 o "Hi-Res A/V", part of the Conversational service group, is 1173 created by [ID-DSCP] for an additional business differentiation 1174 interactive video marking for higher end traffic. It is within 1175 the 100xxx as CS4 (for nonadmitted traffic) and CS4-Admit 1176 (100001) (for capacity-admitted traffic). 1178 o "Realtime Interactive" is now using CS5 (for nonadmitted 1179 traffic), but adds a capacity-admitted DSCP CS5-Admit (101001). 1181 o "Multimedia Conferencing" is no longer using the AF4x DSCPs, 1182 rather it will use the new PHB MC (100101) (for 1183 capacity-admitted) and MC-Admit (011101) (for nonadmitted 1184 traffic). 1186 o "Multimedia Streaming" retains using AF3x, however, AF31 is now 1187 used for capacity-admitted traffic, while AF32/33 are 1188 nonadmitted. 1190 o "Broadcast" replaces "Broadcast Video" using CS3 (for nonadmitted 1191 traffic), and adds a capacity-admitted PHB CS3-Admit (011001). 1193 It is expected that network administrators will base their choice of 1194 the service classes that they will support on their need. 1196 Figure 4 provides a summary of DiffServ CoS mechanisms that MUST be 1197 used for the defined service classes that are further detailed in 1198 Sections 3 and 4 of this document. According to what 1199 applications/services need to be differentiated, network 1200 administrators MAY choose the service class(es) that need to be 1201 supported in their network. 1203 +-----------------------------------------------------------------+ 1204 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| 1205 | Class | | DS Edge | Used | | | 1206 |===============+=======+===================+=======+========+====| 1207 |Network Control|CS6/CS7| See Section 3.1 |RFC2474| Rate | Yes| 1208 |---------------+-------+-------------------+-------+--------+----| 1209 | Real-Time | CS5, |Police using sr+bs |RFC2474| Rate | No | 1210 | Interactive | CS5- | | | | | 1211 | | Admit*| |[ID-DSCP]| | | 1212 |---------------+-------+-------------------+-------+--------+----| 1213 | | EF, |Police using sr+bs |RFC3246|Priority| No | 1214 | Audio |Voice- | | | | | 1215 | | Admit*| |RFC5865| | | 1216 |---------------+-------+-------------------+-------+--------+----| 1217 | | CS4, |Police using sr+bs |RFC2474|Priority| No | 1218 | Hi-Res A/V | CS4- | | | | | 1219 | | Admit*| |[ID-DSCP]| | | 1220 |---------------+-------+-------------------+-------+--------+----| 1221 | | AF41*,| Using two-rate, | | | Yes| 1222 | Video | AF42 |three-color marker |RFC2597| Rate | per| 1223 | | AF43 | (such as RFC 2698)| | |DSCP| 1224 |---------------+-------+-------------------+-------+--------+----| 1225 | Multimedia | MC, |Police using sr+bs|[ID-DSCP]| Rate | No | 1226 | Conferencing | MC- | | | | | 1227 | | Admit*| |[ID-DSCP]| | | 1228 |---------------+-------+-------------------+-------+--------+----| 1229 | Multimedia | AF31*,| Using two-rate, | | | Yes| 1230 | Streaming | AF32 |three-color marker |RFC2597| Rate | per| 1231 | | AF33 | (such as RFC 2698)| | |DSCP| 1232 |---------------+-------+-------------------+-------+--------+----| 1233 | Broadcast | CS3, |Police using sr+bs |RFC2474| Rate | No | 1234 | | CS3- | | | | | 1235 | | Admit*| |[ID-DSCP]| | | 1236 |---------------+-------+-------------------+-------+--------+----| 1237 | Low- | AF21 | Using single-rate,| | | Yes| 1238 | Latency | AF22 |three-color marker |RFC2597| Rate | per| 1239 | Data | AF23 | (such as RFC 2697)| | |DSCP| 1240 |---------------+-------+-------------------+-------+--------+----| 1241 |Conversational |AV-Sig |Police using sr+bs|[ID-DSCP]| Rate | No | 1242 | Signaling | | | | | | 1243 |---------------+-------+-------------------+-------+--------+----| 1244 | OAM | CS2 |Police using sr+bs |RFC2474| Rate | Yes| 1245 |---------------+-------+-------------------+-------+--------+----| 1246 | High- | AF11 | Using two-rate, | | | Yes| 1247 | Throughput | AF12 |three-color marker |RFC2597| Rate | per| 1248 | Data | AF13 | (such as RFC 2698)| | |DSCP| 1249 |---------------+-------+-------------------+-------+--------+----| 1250 | Standard | DF | Not applicable |RFC2474| Rate | Yes| 1251 |---------------+-------+-------------------+-------+--------+----| 1252 | Low-Priority | CS1 | Not applicable |RFC3662| Rate | Yes| 1253 | Data | | | | | | 1254 +---------------+-------+-------------------+-------+--------+----+ 1256 Figure 4. Summary of CoS Mechanisms Used for Each Service Class 1258 * denotes each DSCP identified for capacity-admission traffic only. 1260 Notes for Figure 4: 1262 o Conditioning at DS edge means that traffic conditioning is 1263 performed at the edge of the DiffServ network where untrusted 1264 user devices are connected to two different administrative 1265 DiffServ networks. 1267 o "sr+bs" represents a policing mechanism that provides single rate 1268 with burst size control. 1270 o The single-rate, three-color marker (srTCM) behavior SHOULD be 1271 equivalent to RFC 2697, and the two-rate, three-color marker 1272 (trTCM) behavior SHOULD be equivalent to RFC 2698. 1274 o The PHB for Realtime-Interactive 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 Multimedia Conferencing service class SHOULD be 1281 configured to provide high bandwidth assurance. It MAY be 1282 configured as 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 o The PHB for Broadcast service class SHOULD be configured to 1287 provide high bandwidth assurance. It MAY be configured as 1288 another EF PHB (one capacity-admitted and one 1289 non-capacity-admitted, if both are to be used) that uses relaxed 1290 performance parameters and a rate scheduler. 1292 2.4. Service Classes vs. Treatment Aggregates (from RFC 5127) 1294 There are misconceptions about the differences between RFC 4594 1295 specified service classes, and RFC 5127 specified treatment 1296 aggregates. Often the two are conflated, and more often the phrase 1297 service class is used to mean both definitions. Almost all of the 1298 text previous to this section is used in defining service classes, 1299 and how one service class is different than another service class 1300 (based on traffic characteristics of the applications). Treatment 1301 aggregates are groupings of service classes with similar, but not 1302 identical, traffic characteristics to give similar treatment from a 1303 SP's network. 1305 Below is taken from appendix of RFC 5127 as its recommended 1306 groupings of service classes into aggregates based in RFC 4594 1307 specified traffic characteristic expectations. 1309 +------------------------------------------------------------+ 1310 |Treatment |Treatment || DSCP | 1311 |Aggregate |Aggregate || | 1312 | |Behavior || | 1313 |==========+==========++=====================================| 1314 | Network | CS || CS6 | 1315 | Control |(RFC 2474)|| | 1316 |==========+==========++=====================================| 1317 | Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | 1318 | Time* |(RFC 3246)|| | 1319 |==========+==========++=====================================| 1320 | Assured | AF || CS2, AF31, AF21, AF11 | 1321 | Elastic |(RFC 2597)||-------------------------------------| 1322 | | || AF32, AF22, AF12 | 1323 | | ||-------------------------------------| 1324 | | || AF33, AF23, AF13 | 1325 |==========+==========++=====================================| 1326 | Elastic | Default || Default, (CS0) | 1327 | |(RFC 2474)||-------------------------------------| 1328 | | || CS1 | 1329 +------------------------------------------------------------+ 1330 Figure 5: RFC 5127 Defined Treatment Aggregate Behavior** 1332 *NOTE: The RFC 5865 created VOICE-ADMIT is absence from the above 1333 figure because VOICE-ADMIT was created far later than this 1334 recommendation was. VOICE-ADMIT is appropriate for the 1335 Realtime Traffic Aggregate. 1337 **NOTE: Figure 5 is directly from the appendix of RFC 5127 as that 1338 RFC's recommendation for configuration. This draft does not 1339 directly affect RFC 5127. That is left for an update to RFC 1340 5127 itself. Based on the WG's take on this draft, RFC 5127 1341 will necessitate an update to match this document's new 1342 service classes and additional DSCPs. The number of treatment 1343 aggregates are not expected to change in the RFC 5127 Update 1344 draft though, with the possible exception of a new treatment 1345 aggregate for capacity admitted flows; meaning there *might* 1346 be a 5th treatment aggregate proposed. 1348 Treatment Aggregates are designed to nicely fit into technologies 1349 that do not have many different treatment levels to use. Here are 3 1350 examples of technologies limited to an 8-value field, 1352 - MPLS with its 3 Traffic Class (TC) bits [RFC5462]. 1354 - IEEE LANs with its 8-value Priority Code Point (PCP) field, as 1355 part of the 802.1Q header spec [IEEE1Q]. 1357 - IEEE 802.1e, which defines QoS over Wi-Fi, also only defines 8 1358 levels (called User Priority or UP codes) [IEEE1E]. 1360 Treatment Aggregates are dependent on service classes to exist. 1361 Therefore many service classes can exist without the need to 1362 consider the use of treatment aggregates or their 8-value 1363 technologies. For example, a Layer 3 VPN can be all that is needed 1364 to transit traffic flows, regardless of desired treatment, between 1365 enterprise LAN campuses. From this reality, the number of treatment 1366 aggregates has no direct bearing on the number of service classes. 1368 2.4.1 Examples of Service Classes in Treatment Aggregates 1370 It is *not* expected that all traffic characteristics are to be 1371 experienced across an SP's network for any given customer. For 1372 example, if VOICE-ADMIT is added to the Realtime Treatment Aggregate 1373 in Figure 5, there are 8 different service classes within the 1374 Realtime Treatment Aggregate. It is not expected that all 8 service 1375 classes will be deployed by customer networks traversing SP 1376 networks. RFC 5127's Treatment Aggregates are a table to configure 1377 which service class goes into which treatment aggregate. If there 1378 are 8 services classes in the Realtime treatment aggregate, there is 1379 very little difference than if there were one service within that 1380 same Realtime treatment aggregate - it would still be necessary to 1381 configure that treatment aggregate. Thus, it becomes a question of 1382 not 1384 "how many service classes are there that go into treatment 1385 aggregates?" 1387 but 1389 "how many treatment aggregates have one or more services 1390 classes requiring configuration"? 1392 Of the 4 treatment aggregates shown in Figure 5, if there are 1393 existing service classes in only 3 of the aggregates, then only 3 1394 treatment aggregates are necessary. Of the 3 following examples, 1395 notice that examples 2 and 3 have the same number of treatment 1396 aggregates, but example 3 has more applications in their own 1397 service classes. 1399 Examples 2 and 3 are made under the following assumptions: 1401 - this draft's Service Classes and DSCP assignments are utilized. 1403 - the new AF-Sig DSCP in the Assured Elastic treatment aggregate. 1405 - the Audio, Video service classes are in the EF treatment 1406 aggregate. 1408 - the VOICE-ADMIT DSCP is in the EF treatment aggregate. 1410 2.4.1.1 Example 1 - Simple Voice Configuration/SLA 1412 For example 1, we have an SP running MPLS and has an SLA to deliver 1413 Network Control, Voice and everything else is Best Effort. The 1414 following table would apply to this configuration/SLA: 1416 +----------------+----------------+-----------+--------------+ 1417 | Applications | Service | DSCP(s) | Treatment | 1418 | | Class | | Aggregate | 1419 +================+================+===========+==============+ 1420 | Network | Network | CS6 | Network | 1421 | Control | Control | | Control | 1422 +----------------+----------------+-----------+--------------+ 1423 | Voice | Audio | EF | Realtime | 1424 +----------------+----------------+-----------+--------------+ 1425 | Everything | DF | Default | Elastic | 1426 | else | | (CS0) | | 1427 +----------------+----------------+-----------+--------------+ 1429 Figure 6. Example 1 Configuration 1431 2.4.1.2 Example 2 - Voice/Video/Surveillance Configuration/SLA 1433 For example 1, we have an SP running MPLS and has an SLA to deliver 1434 Control, audio, video, surveillance, audio & video signaling, and 1435 everything else is BE 1437 +----------------+----------------+-----------+--------------+ 1438 | Applications | Service | DSCP(s) | Treatment | 1439 | | Class | | Aggregate | 1440 +================+================+===========+==============+ 1441 | Network | Network | CS6 | Network | 1442 | Control | Control | | Control | 1443 +----------------+----------------+-----------+--------------+ 1444 | Voice, video, | Audio, Video, | EF, AF42, | Realtime | 1445 | surveillance | Broadcast | CS3 | | 1446 +----------------+----------------+-----------+--------------+ 1447 | audio & video | Conversational | AV-Sig | Assured | 1448 | signaling | Signaling | | Elastic | 1449 +----------------+----------------+-----------+--------------+ 1450 | Everything | DF | Default | Elastic | 1451 | else | | (CS0) | | 1452 +----------------+----------------+-----------+--------------+ 1454 Figure 7. Example 2 Configuration 1456 2.4.1.2 Example 3 - Complex CAC realtime/Surveillance/+apps 1457 Configuration/SLA 1459 For example 1, we have an SP running MPLS and has an SLA to deliver 1460 Control, voice, CAC voice, CAC video, streaming, signaling, LL 1461 data, Network Mgmt., and everything else is BE (including non-CAC 1462 video because it is not authorized or authenticated on network) 1464 +-------------------+-----------------+-----------+--------------+ 1465 | Applications | Service | DSCP(s) | Treatment | 1466 | | Class | | Aggregate | 1467 +===================+=================+===========+==============+ 1468 | Network | Network | CS6 | Network | 1469 | Control | Control | | Control | 1470 +-------------------+-----------------+-----------+--------------+ 1471 | Voice, CAC-Voice | Audio, Video, |Voice-Admit| Realtime | 1472 | CAC-video, | | EF, AF41 | | 1473 | surveillance | Broadcast | CS3 | | 1474 +-------------------+-----------------+-----------+--------------+ 1475 | audio & video | Conversational | AV-Sig | Assured | 1476 | signaling, | Signaling, Low- | AF21 | Elastic | 1477 | VOD (streaming), | Latency Data, | AF31 | | 1478 | Network Mgmt. | Multimedia | CS2 | | 1479 | | Streaming, | | | 1480 | | OAM | | | 1481 +-------------------+-----------------+-----------+--------------+ 1482 | Everything | DF | Default | Elastic | 1483 | else | | (CS0) | | 1484 +-------------------+-----------------+-----------+--------------+ 1486 Figure 8. Example 3 Configuration 1488 3. Network Control Traffic 1490 Network control traffic is defined as packet flows that are 1491 essential for stable operation of an administered network, as well 1492 as the information exchanged between neighboring networks across a 1493 peering point where SLAs are in place. Network control traffic is 1494 different from user application control (signaling) that may be 1495 generated by some applications or services. Network control traffic 1496 is mostly between routers and network nodes (e.g., routing or mgmt 1497 protocols) that are used for operating, administering, controlling, 1498 or managing whole networks, network parts or just network segments. 1499 Network Control Traffic may be split into two service classes, i.e., 1500 Network Control and OAM. 1502 3.1. Current Practice in the Internet 1504 Based on today's routing protocols and network control procedures 1505 that are used in the Internet, we have determined that CS6 DSCP 1506 value SHOULD be used for routing and control and that CS7 DSCP value 1507 SHOULD be reserved for future use, specifically if needed for future 1508 routing or control protocols. Network administrators MAY use a 1509 Local/Experimental DSCP, any value that contains 11xx11; therefore, 1510 they may use a locally defined service class within their network to 1511 further differentiate their routing and control traffic. 1513 RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets: 1515 o Drop or remark 111xxx packets at ingress to DiffServ network 1516 domain. 1518 o 111xxx marked packets SHOULD NOT be sent across peering points. 1519 Exchange of control information across peering points SHOULD be 1520 done using CS6 DSCP and the Network Control service class. 1522 o any internally defined 11xxx1 values, valid within that network 1523 domain, be remarked to CS6 upon egress at network peering points. 1525 3.2. Network Control Service Class 1527 The Network Control service class is used for transmitting packets 1528 between network devices (routers) that require control (routing) 1529 information to be exchanged between similar devices within the 1530 administrative domain, as well as across a peering point between 1531 adjacent administrative domains. Traffic transmitted in this 1532 service class is very important as it keeps the network operational, 1533 and it needs to be forwarded in a timely manner. 1535 The Network Control service class SHOULD be configured using the 1536 DiffServ CS6 PHB, defined in [RFC2474]. This service class MUST be 1537 configured so that the traffic receives a minimum bandwidth 1538 guarantee, to ensure that the packets always receive timely service. 1539 The configured forwarding resources for Network Control service 1540 class MUST be such that the probability of packet drop under peak 1541 load is very low. The Network Control service class SHOULD be 1542 configured to use a Rate Queuing system such as defined in Section 1543 1.4.1.2 of this document. 1545 The following are examples of protocols and applications that MUST 1546 use the Network Control service class if present in a network: 1548 o Routing packet flows: OSPF, BGP, ISIS, RIP. 1550 o Control information exchange within and between different 1551 administrative domains across a peering point where SLAs are in 1552 place. 1554 o LSP setup using CR-LDP and RSVP-TE. 1556 The following protocols and applications MUST NOT use the Network 1557 Control service class: 1559 o User oriented traffic is not allowed to use this service class. 1560 By user oriented traffic, we mean packet flows that originate 1561 from user-controlled end points that are connected to the 1562 network. 1564 o even if originating from a server or a device acting on behalf 1565 of a user or endpoint, 1567 o even if it is application or in-band signaling to establish a 1568 connection wholly within a single network or across peering 1569 points of/to adjacent networks (e.g., creating a tunnel such 1570 as a VPN, or data path control signaling). 1572 The following are traffic characteristics of packet flows in the 1573 Network Control service class: 1575 o Mostly messages sent between routers and network servers. 1577 o Variable size packets, normally one packet at a time, but traffic 1578 can also burst (BGP, OSPF, etc). 1580 o IGMP, hen is used only for the normal multicast routing purpose. 1582 The REQUIRED DSCP marking is CS6 (Class Selector 6). 1584 RECOMMENDED Network Edge Conditioning: 1586 o At peering points (between two DiffServ networks) where SLAs are 1587 in place, CS6 marked packets MUST be policed, e.g., using a 1588 single rate with burst size (sr+bs) token bucket policer to keep 1589 the CS6 marked packet flows to within the traffic rate specified 1590 in the SLA. 1592 o CS6 marked packet flows from untrusted sources (for example, end 1593 user devices) MUST be dropped or remarked at ingress to the 1594 DiffServ network. What a network admin remarks this user oriented 1595 traffic to if a matter of local policy, and inspection of the 1596 packets can determine which application is used for proper 1597 marking to a more appropriate DSCP, such as from table 3. of this 1598 document. 1600 o Packets from users/subscribers are not permitted access to the 1601 Network Control service classes. 1603 The fundamental service offered to the Network Control service class 1604 is enhanced best-effort service with high bandwidth assurance. 1605 Since this service class is used to forward both elastic and 1606 inelastic flows, the service SHOULD be engineered so that the Active 1607 Queue Management (AQM) [RFC2309] is applied to CS6 marked packets. 1609 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1610 specifies a target queue depth, and the max-threshold specifies the 1611 queue depth above which all traffic is dropped or ECN marked. Thus, 1612 in this service class, the following inequality should hold in queue 1613 configurations: 1615 o min-threshold CS6 < max-threshold CS6 1617 o max-threshold CS6 <= memory assigned to the queue 1619 Note: Many other AQM algorithms exist and are used; they should be 1620 configured to achieve a similar result. 1622 3.3. OAM Service Class 1624 The OAM (Operations, Administration, and Management) service class 1625 is RECOMMENDED for OAM&P (Operations, Administration, and Management 1626 and Provisioning) using protocols such as Simple Network Management 1627 Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet, 1628 and Common Open Policy Service (COPS). Applications using this 1629 service class require a low packet loss but are relatively not 1630 sensitive to delay. This service class is configured to provide 1631 good packet delivery for intermittent flows. 1633 The OAM service class SHOULD use the Class Selector (CS) PHB defined 1634 in [RFC2474]. This service class SHOULD be configured to provide a 1635 minimum bandwidth assurance for CS2 marked packets to ensure that 1636 they get forwarded. The OAM service class SHOULD be configured to 1637 use a Rate Queuing system such as defined in Section 1.4.1.2 of this 1638 document. 1640 The following applications SHOULD use the OAM service class: 1642 o Provisioning and configuration of network elements. 1644 o Performance monitoring of network elements. 1646 o Any network operational alarms. 1648 The following are traffic characteristics: 1650 o Variable size packets. 1652 o Intermittent traffic flows. 1654 o Traffic may burst at times. 1656 o Both elastic and inelastic flows. 1658 o Traffic not sensitive to delays. 1660 RECOMMENDED DSCP marking: 1662 o All flows in this service class are marked with CS2 (Class 1663 Selector 2). 1665 Applications or IP end points SHOULD pre-mark their packets with CS2 1666 DSCP value. If the end point is not capable of setting the DSCP 1667 value, then the router topologically closest to the end point SHOULD 1668 perform Multifield (MF) Classification, as defined in [RFC2475]. 1670 RECOMMENDED conditioning performed at DiffServ network edge: 1672 o Packet flow marking (DSCP setting) from untrusted sources (end 1673 user devices) SHOULD be verified at ingress to DiffServ network 1674 using Multifield (MF) Classification methods, defined in 1675 [RFC2475]. 1677 o Packet flows from untrusted sources (end user devices) SHOULD be 1678 policed at ingress to DiffServ network, e.g., using single rate 1679 with burst size token bucket policer to ensure that the traffic 1680 stays within its negotiated or engineered bounds. 1682 o Packet flows from trusted sources (routers inside administered 1683 network) MAY not require policing. 1685 o Normally OAM&P CS2 marked packet flows are not allowed to flow 1686 across peering points. If that is the case, then CS2 marked 1687 packets SHOULD be policed (dropped) at both egress and ingress 1688 peering interfaces. 1690 The fundamental service offered to "OAM" traffic is enhanced 1691 best-effort service with controlled rate. The service SHOULD be 1692 engineered so that CS2 marked packet flows have sufficient bandwidth 1693 in the network to provide high assurance of delivery. Since this 1694 service class is used to forward both elastic and inelastic flows, 1695 the service SHOULD be engineered so that Active Queue Management 1696 [RFC2309] is applied to CS2 marked packets. 1698 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1699 specifies a target queue depth for each DSCP, and the max-threshold 1700 specifies the queue depth above which all traffic with such a DSCP 1701 is dropped or ECN marked. Thus, in this service class, the 1702 following inequality should hold in queue configurations: 1704 o min-threshold CS2 < max-threshold CS2 1706 o max-threshold CS2 <= memory assigned to the queue 1708 Note: Many other AQM algorithms exist and are used; they should be 1709 configured to achieve a similar result. 1711 4. User Oriented Traffic 1713 User oriented traffic is defined as packet flows between different 1714 users or subscribers, or from servers/nodes on behalf of a user. It 1715 is the traffic that is sent to or from end-terminals and that 1716 supports a very wide variety of applications and services, to 1717 include traffic about a user or application that assists a user 1718 communicate. User oriented traffic can be classified in many 1719 different ways. What we have articulated throughout this document is 1720 a series of non-exhaustive list of categories for classifying user 1721 oriented traffic. We differentiated user oriented traffic that is 1722 real-time versus non-real-time, elastic or rate-adaptive versus 1723 inelastic, sensitive versus insensitive to loss as well as 1724 considering whether the traffic is interactive vs. one way 1725 communication, its responsiveness, whether it requires timely 1726 delivery, and critical verses non-critical. In the final analysis, 1727 we used all of the above for service differentiation, mapping 1728 application types that seemed to have different sets of performance 1729 sensitivities, and requirements to different service classes. 1731 Network administrators can categorize their applications according 1732 to the type of behavior that they require and MAY choose to support 1733 all or a subset of the defined service classes. At the same time, 1734 we include a public facing default DSCP value, with its associated 1735 PHB, that is expected for each traffic type to ensure common or 1736 pervasive performance. Figure 3 provides some common applications 1737 and the forwarding service classes that best support them, based on 1738 their performance requirements. 1740 4.1. Conversational Service Class Group 1742 The Conversational Service Class Group consists of 3 different 1743 service classes, audio, video, and Hi-Res. We are describing the 1744 media sample, or bearer, packets for applications (e.g., RTP from 1745 [RFC3550]) that require bi-directional real-time, very low delay, 1746 very low jitter, and very low packet loss for relatively 1747 constant-rate traffic sources (inelastic traffic sources). It is 1748 RECOMMENDED that RTCP feedback use the same service class and be 1749 marked with the same DSCP as the bearer traffic for that (audio 1750 and/or video) call. This ensures comparable treatment within the 1751 network between endpoints. 1753 The signaling to set-up these bearer flows is part of the 1754 Conversational Signaling service group that will be discussed later 1755 in Section 4. The following 3 subsections will detail what is 1756 expected within each bearer service class. 1758 4.1.1 Audio Service Class 1760 This service class MUST be used for IP Audio service. 1762 The fundamental service offered to traffic in the Audio service 1763 class is minimum jitter, delay, and packet loss service up to a 1764 specified upper bound. There are two PHBs, both EF based, for the 1765 Audio service class: 1767 Nonadmitted Audio traffic - MUST use the EF DSCP [RFC3246], and 1768 is for traffic that has not had any capacity admission 1769 signaling performed for that flow or session. 1771 Capacity-Admitted Audio traffic - MUST use the Voice-Admit DSCP 1772 [RFC5865], and is for traffic that has had any capacity 1773 admission signaling performed for that flow or session, e.g., 1774 RSVP [RFC2205] or NSIS [RFC4080]. 1776 The capacity-admitted Audio traffic operation is similar to an ATM 1777 CBR service, which has guaranteed bandwidth and which, if it stays 1778 within the negotiated rate, experiences nominal delay and no loss. 1780 The nonadmitted Audio traffic, on the other hand, has had no such 1781 explicit guarantee, but has a favorable PHB ensuring high 1782 probability of delivery as well as nominal delay and no loss - 1783 implicitly assuming there is not too much like marked traffic 1784 between users within a flow. 1786 There are two typical scenarios in which audio calls are 1787 established, on the public open Internet using protocols such as 1788 SIP, XMPP or H.323, or in more managed networks like enterprises or 1789 certain service providers which offer a audio service with some 1790 feature benefits and take part in the call signaling. These SPs or 1791 enterprises also use protocols like SIP, XMPP, H.323, but also use 1792 H.248/MEGACO and MGCP. 1794 On the open Internet, typically there is no SP actively involved in 1795 the session set-up of calls, and therefore no servers providing 1796 assistance or features to help one user contact another user. Often, 1797 this traffic is marked or remarked with the DF (i.e., Best Effort) 1798 DSCP. 1800 In more managed networks in which one of more operators have active 1801 servers aiding the audio call set-up, where DiffServ can be used and 1802 preserved to differentiate traffic, networks are offering a service, 1803 therefore need to do some, or a lot of engineering to ensure that 1804 capacity offered to one or more applications does not exceed the 1805 load to the network. Otherwise, the operator will have unhappy 1806 users, at least for that application's usage. This is true for any 1807 application, but is especially true for inelastic applications in 1808 which the application is rigid in its delivery requirements. Audio 1809 bearer traffic is typically such an application, video is another 1810 such application, but we will get to video in the next subsection. 1812 When a user in a managed network has been authorized to send Audio 1813 traffic (i.e., call initiation via the operator's servers was not 1814 rejected), the call admission procedure should have verified that 1815 the newly admitted flow will be within the capacity of the Audio 1816 service class forwarding capability in the network. Capacity 1817 verification is a non-trivial thing, and can either be implicitly 1818 assumed by the call server(s) based on the operator's network 1819 design, or it can be explicitly signaled from an in-data-path 1820 signaling mechanism that verifies the capacity is available now for 1821 this call, for each call made within that network. In the latter 1822 case, those that do not have verifiable network capacity along the 1823 data path are rejected. An in between means method is for call 1824 servers to count calls between two or more endpoints. By 1825 topologically understanding where the caller and called party is and 1826 have configured a known maximum it will allow between the two 1827 locations. This is especially true over WAN links that have far less 1828 capacity than LAN links or core parts of a network. Network 1829 operators will need to understand the topology between any two 1830 callers to ensure the appropriate amount of bandwidth is available 1831 for an expected number of simultaneous audio calls. 1833 Once more than one bandwidth amount can be used for audio calls, for 1834 example - by allowing more than one codec with different bandwidths 1835 per codec for such calls, network engineering becomes more 1836 difficult. Since the inelastic nature of RTP payloads from this 1837 class do not react well to loss or significant delay in any 1838 substantive way, the Audio service class MUST forward packets as 1839 soon as possible. 1841 The Audio service class that does not have capacity admission 1842 performed in the data path MUST use the Expedited Forwarding (EF) 1843 PHB, as defined in [RFC3246], so that all packets are forwarded 1844 quickly. The Audio service class that does have capacity admission 1845 performed in the data path MUST use the Voice-Admit PHB, as defined 1846 in [RFC5865], so that all packets are forwarded quickly. The Audio 1847 service class SHOULD be configured to use a Priority Queuing system 1848 such as that defined in Section 1.4.1.1 of this document. 1850 The following applications SHOULD use the Audio service class: 1852 o VoIP (G.711, G.729, iLBC and other audio codecs). 1854 o Voice-band data over IP (modem, fax). 1856 o T.38 fax over IP. 1858 o Circuit emulation over IP, virtual wire, etc. 1860 o IP Virtual Private Network (VPN) service that specifies 1861 single-rate, mean network delay that is slightly longer then 1862 network propagation delay, very low jitter, and a very low packet 1863 loss. 1865 The following are traffic characteristics: 1867 o Mostly fixed-size packets for VoIP (30, 60, 70, 120 or 200 bytes 1868 in size). 1870 o Packets emitted at constant time intervals. 1872 o Admission control of new flows is provided by Audio call server, 1873 media gateway, gatekeeper, edge router, end terminal, access node 1874 or in-data-path signaling that provides flow admission control 1875 function. 1877 Applications or IP end points SHOULD pre-mark their packets with EF 1878 or Voice-Admit DSCP value, whichever is appropriate. If the end 1879 point is not capable of setting the DSCP value, then the router 1880 topologically closest to the end point SHOULD perform Multifield 1881 (MF) Classification, as defined in [RFC2475]. 1883 The RECOMMENDED DSCP marking is EF for nonadmitted audio flows, and 1884 Voice-Admit for capacity-admitted flows for the following 1885 applications: 1887 o VoIP (G.711, G.729 and other codecs). 1889 o Voice-band data over IP (modem and fax). 1891 o T.38 fax over IP. 1893 o Circuit emulation over IP, virtual wire, etc. 1895 RECOMMENDED Network Edge Conditioning: 1897 o Packet flow marking (DSCP setting) from untrusted sources (end 1898 user devices) SHOULD be verified at ingress to DiffServ network 1899 using Multifield (MF) Classification methods, defined in 1900 [RFC2475]. If untrusted, the network edge SHOULD know if 1901 capacity-admission has been applied, since the edge router will 1902 have taken part in the admission signaling; therefore will know 1903 whether EF or Voice-Admit is the proper marking for that flow. 1905 o Packet flows from untrusted sources (end user devices) SHOULD be 1906 policed at ingress to DiffServ network, e.g., using single rate 1907 with burst size token bucket policer to ensure that the Audio 1908 traffic stays within its negotiated bounds. 1910 o Policing is OPTIONAL for packet flows from trusted sources whose 1911 behavior is ensured via other means (e.g., administrative 1912 controls on those systems). 1914 o Policing of Audio packet flows across peering points where SLA is 1915 in place is OPTIONAL as Audio traffic will be controlled by 1916 admission control mechanism between peering points. 1918 The fundamental service offered to "Audio" traffic is enhanced 1919 best-effort service with controlled rate, very low delay, and very 1920 low loss. The service MUST be engineered so that EF marked packet 1921 flows have sufficient bandwidth in the network to provide guaranteed 1922 delivery. Otherwise, the service will have in place an explicit 1923 capacity-admission signaling protocol such as RSVP or NSIS and thus 1924 mark the packets within the flow as Voice-Admit. Normally traffic in 1925 this service class does not respond dynamically to packet loss. As 1926 such, Active Queue Management [RFC2309] SHOULD NOT be applied to EF 1927 marked packet flows. 1929 4.1.2 Video Service Class 1931 The Video service class is for bidirectional applications that 1932 require real-time service for both constant and rate-adaptive 1933 traffic. SIP and H.323/V2 (and later) versions of video 1934 conferencing equipment with constant and dynamic bandwidth 1935 adjustment are such applications. The traffic sources in this 1936 service class either have a fixed bandwidth requirement (e.g., 1937 MPEG2, etc.), or have the ability to dynamically change their 1938 transmission rate (e.g., MPEG4/H.264, etc.) based on feedback from 1939 the receiver. This feedback SHOULD be accomplished using RTCP 1940 [RFC3550]. One approach for this downspeeding has the receiver 1941 detect packet loss, thus signaling in an RTCP message to the source 1942 the indication of lost (or delayed or out of order) packets in 1943 transit. When necessary the source then selects a lower rate 1944 encoding codec. When available, the source merely sends less data, 1945 resulting in lower resolution of the same visual display. 1947 The Video service class is not for video downloads, webcasts, or 1948 single directional video or audio/video traffic of any kind. It is 1949 for human-to-human visual interaction between two users, or more if 1950 an MTP is used. 1952 Typical video conferencing configurations negotiate the setup of 1953 audio/video session using protocols such as SIP and H.323. Just as 1954 with networks that have audio traversing them, video typically 1955 traverses the same two types of networks: the open big "I" Internet, 1956 in which most every type of traffic is best effort (DF), or on a 1957 more managed network such as an enterprise or SP's managed network 1958 in which servers within either network take part in the call 1959 signaling, thereby offering the video service. 1961 When a user in a managed network has been authorized to send video 1962 traffic (i.e., call initiation via the operator's servers was not 1963 rejected), the call admission procedure should have verified that 1964 the newly admitted flow will be within the capacity of the video 1965 service class forwarding capability in the network. Capacity 1966 verification is a non-trivial thing, and can either be implicitly 1967 assumed by the call server(s) based on the operator's network 1968 design, or it can be explicitly signaled from an in-data-path 1969 signaling mechanism that verifies the capacity is available now for 1970 this call, for each call made within that network. In the latter 1971 case, those that do not have verifiable network capacity along the 1972 data path are rejected. An in between means method is for call 1973 servers to count calls between two or more endpoints. By 1974 topologically understanding where the caller and called party is and 1975 have configured a known maximum it will allow between the two 1976 locations. Video is larger in bandwidth than audio, and the 1977 difference can be significant. For example, for a single G.711 audio 1978 call that is 80kbps, an associated video bandwidth for the same 1979 call can easily be 4Mbps. This is especially true over WAN links 1980 that have far less capacity than LAN links or core parts of a 1981 network. Network operators will need to understand the topology 1982 between any two callers to ensure the appropriate amount of 1983 bandwidth is available for an expected number of simultaneous video 1984 and/or audio/video calls. 1986 Note that it is OPTIONALLY the case in these networks that the 1987 accompanying audio for the video call will be marked as the video is 1988 marked (i.e., using the same DSCP), but not always. One reason this 1989 has been done is for lip-sync. 1991 The Video service class MUST use the Assured Forwarding (AF) PHB, 1992 defined in [RFC2597]. This service class MUST be configured to 1993 provide a bandwidth assurance for AF41, AF42, and AF43 marked 1994 packets to ensure that they get forwarded. The Video service class 1995 SHOULD be configured to use a Rate Queuing system for AF42 and AF43 1996 traffic flows, such as that defined in Section 1.4.1.2 of this 1997 document. However, AF41 MUST be designated as the DSCP for use when 1998 capacity-admission signaling has been used, such as RSVP or NSIS, to 1999 guarantee delivery through the network. AF42 and AF43 will be used 2000 for non-admitted video calls, as well as overflows from AF41 sources 2001 that send more packets than they have negotiated bandwidth for that 2002 call. 2004 The following applications MUST use the Video service class: 2006 o SIP and H.323/V2 (and later) versions of video conferencing 2007 applications (interactive video). 2009 o Video conferencing applications with rate control or traffic 2010 content importance marking. 2012 o Interactive, time-critical, and mission-critical applications. 2014 NOTE with regards to the above bullet: this usage SHOULD be 2015 minimized, else the video traffic will suffer - unless this 2016 is engineered into the topology. 2018 The following are traffic characteristics: 2020 o Variable size packets (i.e., small to large in size). 2022 o The higher the resolution or change rate between each image, the 2023 higher the duration of large packets. 2025 o Usually constant inter-packet time interval. 2027 o Can be Variable rate in transmission. 2029 o Source is capable of reducing its transmission rate based on 2030 being told receiver is detecting packet loss (e.g., via RTCP). 2032 Applications or IP end points SHOULD pre-mark their packets with 2033 DSCP values as shown below. If the end point is not capable of 2034 setting the DSCP value, then the router topologically closest to the 2035 end point SHOULD perform Multifield (MF) Classification, as defined 2036 in [RFC2475] and mark all packets as AF4x. Note: In this case, the 2037 two-rate, three-color marker will be configured to operate in 2038 Color-Blind mode. 2040 Mandatory DSCP marking when performed by router closest to source: 2042 o AF41 = up to specified rate "A", which is dedicated to non-Hi-Res 2043 capacity-admitted video traffic. 2045 Note the audio of an A/V call can be marked AF41 as well. 2047 o AF42 = all non-Hi-Res video traffic marked AF41 in excess of 2048 specified rate "A", or new non-admitted video traffic but 2049 below specified rate "B". 2051 o AF43 = in excess of specified rate "B". 2053 o Where "A" < "B". 2055 Note: One might expect "A" to approximate the peak rates of sum of 2056 all admitted video flows, plus the sum of the mean rates and 2057 "B" to approximate the sum of the peak rates of those same two 2058 flows. 2060 Mandatory DSCP marking when performed by SIP or H.323/V2 2061 videoconferencing equipment: 2063 o AF41 = SIP or H.323 video conferencing audio stream RTP. 2065 o AF41 = SIP or H.323 video conferencing video control RTCP. 2067 o AF41 = SIP or H.323 video conferencing video stream up to 2068 specified rate "A". 2070 o AF42 = SIP or H.323 video conferencing video stream in excess of 2071 specified rate "A" but below specified rate "B". 2073 o AF42 = SIP or H.323 video conferencing video control RTCP, for 2074 those video streams that were generated using AF42. 2076 o AF43 = SIP or H.323 video conferencing video stream in excess of 2077 specified rate "B". 2079 o AF43 = SIP or H.323 video conferencing video control RTCP, for 2080 those video streams that were generated using AF43. 2082 o Where "A" < "B". 2084 Mandatory conditioning performed at DiffServ network edge: 2086 o The two-rate, three-color marker SHOULD be configured to provide 2087 the behavior as defined in trTCM [RFC2698]. 2089 o If packets are marked by trusted sources or a previously trusted 2090 DiffServ domain and the color marking is to be preserved, then 2091 the two-rate, three-color marker SHOULD be configured to operate 2092 in Color-Aware mode. 2094 o If the packet marking is not trusted or the color marking is not 2095 to be preserved, then the two-rate, three-color marker SHOULD be 2096 configured to operate in Color-Blind mode. 2098 The fundamental service offered to nonadmitted "Video" traffic is 2099 enhanced best-effort service with controlled rate and delay. The 2100 fundamental service offered to capacity-admitted "Video" traffic is 2101 a guaranteed service using in-data-path signaling to ensure expected 2102 delivery in a timely manner. For a non-admitted video conferencing 2103 service, if a 1% packet loss detected at the receiver triggers an 2104 encoding rate change, thus dropping to the next lower provisioned 2105 video encoding rate then Active Queue Management [RFC2309] SHOULD be 2106 used primarily to switch the video encoding rate under congestion, 2107 changing from high rate to lower rate, i.e., 1472 kbps to 768 kbps. 2108 This rule applies to all AF42 and 43 flows. The probability of loss 2109 of AF41 traffic MUST NOT exceed the probability of loss of AF42 2110 traffic, which in turn MUST NOT exceed the probability of loss of 2111 AF43 traffic. 2113 Capacity-admitted video service should not result in packet loss. 2114 However, administratively this MAY be allowed to cause a purposeful 2115 downspeeding event (i.e., a change in resolution or a change in 2116 codec) to occur due to congestion. 2118 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2119 specifies a target queue depth for each DSCP, and the max-threshold 2120 specifies the queue depth above which all traffic with such a DSCP 2121 is dropped or ECN marked. Thus, in this service class, the 2122 following inequality should hold in queue configurations: 2124 o min-threshold AF43 < max-threshold AF43 2126 o max-threshold AF43 <= min-threshold AF42 2128 o min-threshold AF42 < max-threshold AF42 2130 o max-threshold AF42 <= min-threshold AF41 2132 o min-threshold AF41 < max-threshold AF41 2134 o max-threshold AF41 <= memory assigned to the queue 2136 Note: This configuration tends to drop AF43 traffic before AF42 and 2137 AF42 before AF41. Many other AQM algorithms exist and are 2138 used; they should be configured to achieve a similar result. 2140 4.1.3 Hi-Res Service Class 2142 The Hi-Res service class is for higher end (i.e., deemed 'more 2143 important') bidirectional applications that require real-time 2144 service for both constant and rate-adaptive traffic. There are two 2145 PHBs, both EF based, for the Hi-Res video conferencing service 2146 class: 2148 Nonadmitted Hi-Res traffic - MUST use the CS4 DSCP [RFC2474], and 2149 is for traffic that has not had any capacity admission 2150 signaling performed for that flow or session. 2152 Capacity-Admitted Hi-Res traffic - MUST use the CS4-Admit DSCP 2153 [ID-DSCP], and is for traffic that has had any capacity 2154 admission signaling performed for that flow or session, e.g., 2155 RSVP [RFC2205] or NSIS [RFC4080]. 2157 The capacity-admitted Hi-Res video conferencing traffic operation is 2158 similar to an ATM CBR service, which has guaranteed bandwidth and 2159 which, if it stays within the negotiated rate, experiences nominal 2160 delay and no loss. 2162 SIP and H.323/V2 (and later) versions of video conferencing 2163 equipment with constant and dynamic bandwidth adjustment are such 2164 applications. The traffic sources in this service class either have 2165 a fixed bandwidth requirement (e.g., MPEG2), or have the ability to 2166 dynamically change their transmission rate (e.g., MPEG4/H.264) based 2167 on feedback from the receiver. This feedback SHOULD be accomplished 2168 using RTCP [RFC3550]. One approach for this downspeeding has the 2169 receiver detect packet loss, thus signaling in an RTCP message to 2170 the source the indication of lost (or delayed or out of order) 2171 packets in transit. When necessary the source then selects a lower 2172 rate encoding codec. When available, the source merely sends less 2173 data, resulting in lower resolution of the same visual display. 2175 The Hi-Res service class, as with the Video service class, is not 2176 for video downloads, webcasts, or single directional video or 2177 audio/video traffic of any kind. It is for human-to-human visual 2178 interaction between two users, or more if an video conference bridge 2179 is used. 2181 Typical Hi-Res video conferencing configurations negotiate the setup 2182 of audio/video session using protocols such as SIP and H.323. 2183 Hi-Res video conferencing is generally not over the big "I" 2184 Internet, rather nearly exclusively over more managed networks such 2185 as an enterprise or special purpose SP's managed network in which 2186 servers within either network take part in the call signaling, 2187 thereby offering the video service. In addition, typically this type 2188 of audio/video service has high business expectations for minimized 2189 packet loss, pixilation or other issues with the audio/video 2190 experience. In the recent past, entire T3s have been dedicated to a 2191 signal Hi-Res call; sometimes one T3 per site of a multi-site video 2192 conference. 2194 Hi-Res video conferencing often has larger in bandwidth than the 2195 typical video call. The audio portion can be increased as well, as 2196 stereo capabilities are often necessary to provide an in-room 2197 experience from a distance. The difference can be significant (or 2198 another step up from just a typical video service). For example, for 2199 a single G.711 audio call that is 80kbps, a Hi-Res conference 2200 usually runs G.722 wideband audio at 256kbps. Typical video delivery 2201 is up to 4Mbps, whereas a Hi-Res conference can have three 2202 1080p/30fps widescreen displays requiring at least 12Mbps, with a 2203 burst capability of much more. 2205 If there were no congestion on the wire, the expected treatment 2206 between a video service and a Hi-Res conference would be the same. 2207 However, it is typically the case that the Hi-Res conferencing flows 2208 have more rigid requirements for quality and business-wise, need to 2209 be experience far less errors than the regular video service on the 2210 same network. 2212 Note that it is likely the case in these networks that the 2213 accompanying audio to the Hi-Res video call will be marked as the 2214 Hi-Res video is marked (i.e., using the same DSCP. 2216 The Hi-Res service class MUST use the Class Selector 5 (CS4) PHB, 2217 defined in [RFC2474], for non-capacity-admitted conferences. While 2218 the capacity-admitted Hi-Res conferences MUST use the CS4-Admit PHB, 2219 defined in [ID-DSCP]. This service class MUST be configured to 2220 provide a bandwidth assurance for CS4 and CS4-Admit marked packets 2221 to ensure that they get forwarded. The Hi-Res service class SHOULD 2222 be configured to use a Priority Queuing system such as that defined 2223 in Section 1.4.1.1 of this document. Further, CS4-Admit will be 2224 designated as the DSCP for use when capacity-admission signaling has 2225 been used, such as RSVP or NSIS, to guarantee delivery through the 2226 network. CS4 will be used for non-admitted Hi-Res conferences, as 2227 well as overflows from CS4-Admit sources that send more packets than 2228 they have negotiated bandwidth for that call. 2230 The following applications MUST use the Hi-Res service class: 2232 o SIP and H.323/V2 (and later) versions of Hi-Res video 2233 conferencing applications (interactive Hi-Res video). 2235 o Video conferencing applications with rate control or traffic 2236 content importance marking. 2238 The following are traffic characteristics: 2240 o Variable size packets. 2242 o The higher the resolution or change rate between each image, the 2243 higher the duration of large packets. 2245 o Usually constant inter-packet time interval. 2247 o Can be Variable rate in transmission. 2249 o Source is capable of reducing its transmission rate based on 2250 being told receiver is detecting packet loss. 2252 Applications or IP end points SHOULD pre-mark their packets with 2253 DSCP values as shown below. If the end point is not capable of 2254 setting the DSCP value, then the router topologically closest to the 2255 end point SHOULD perform Multifield (MF) Classification, as defined 2256 in [RFC2475] and mark all packets as AF4x. 2258 Mandatory DSCP marking when performed by router closest to source: 2260 o CS4-Admit = up to specified rate "A", which is dedicated to 2261 capacity-admitted Hi-Res traffic. 2263 Note the audio of an A/V call can be marked CS4-Admit as well. 2265 o CS4 = all video traffic marked CS4-Admit in excess of specified 2266 rate "A", or new non-admitted video traffic but below 2267 specified rate "B". 2269 o Where "A" < "B". 2271 Note: One might expect "A" to approximate the peak rates of sum of 2272 all admitted video flows, plus the sum of the mean rates and 2273 "B" to approximate the sum of the peak rates of those same two 2274 flows. 2276 Mandatory DSCP marking when performed by SIP or H.323/V2 2277 videoconferencing equipment: 2279 o CS4-Admit = SIP or H.323 video conferencing audio stream RTP/UDP. 2281 o CS4-Admit = SIP or H.323 video conferencing video control 2282 RTCP/TCP. 2284 o CS4-Admit = SIP or H.323 video conferencing video stream up to 2285 specified rate "A". 2287 o CS4 = SIP or H.323 video conferencing video stream in excess of 2288 specified rate "A" but below specified rate "B". 2290 o Where "A" < "B". 2292 Mandatory conditioning performed at DiffServ network edge: 2294 o The two-rate, three-color marker SHOULD be configured to provide 2295 the behavior as defined in trTCM [RFC2698]. 2297 o If packets are marked by trusted sources or a previously trusted 2298 DiffServ domain and the color marking is to be preserved, then 2299 the two-rate, three-color marker SHOULD be configured to operate 2300 in Color-Aware mode. 2302 o If the packet marking is not trusted or the color marking is not 2303 to be preserved, then the two-rate, three-color marker SHOULD be 2304 configured to operate in Color-Blind mode. 2306 The fundamental service offered to nonadmitted "Hi-Res" traffic is 2307 enhanced best-effort service with controlled rate and delay. The 2308 fundamental service offered to capacity-admitted "Hi-Res" traffic is 2309 a guaranteed service using in-data-path signaling to ensure expected 2310 or timely delivery. Capacity-admitted video service SHOULD NOT 2311 result in packet loss. However, administratively this MAY be allowed 2312 to cause a purposeful downspeeding event (i.e., a change in 2313 resolution or a change in codec) to occur. 2315 4.2. Realtime-Interactive Service Class 2317 The Realtime-Interactive service class is for bidirectional 2318 applications that require low loss and jitter and very low delay for 2319 constant or variable rate inelastic traffic sources. Interactive 2320 gaming applications that do not have the ability to change encoding 2321 rates or to mark packets with different importance indications is 2322 one good example of such an application. Another set of 2323 applications is virtualized desktop applications in which a remote 2324 user has a keyboard, mouse and display monitor, but the desktop is 2325 virtualized with the memory/processor/applications back in a common 2326 data center, requiring near instantaneous feedback on the user's 2327 monitor of any changes caused by the application or an action by the 2328 user. Rich media protocols for voice and video MUST NOT use the 2329 Realtime-Interactive service class, but rather the appropriate 2330 service class from the Conversational service group discussed early 2331 in Section 4.1. 2333 The Realtime-Interactive service class will use two PHBs: 2335 Nonadmitted Realtime-Interactive traffic - MUST use the CS5 DSCP 2336 [RFC2474], and is for traffic that has not had any capacity 2337 admission signaling performed for that flow or session. 2339 Capacity-Admitted Realtime-Interactive traffic - MUST use the 2340 CS5-Admit DSCP [ID-DSCP], and is for traffic that has had any 2341 capacity admission signaling performed for that flow or 2342 session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. 2344 The capacity-admitted Realtime-Interactive traffic operation is 2345 similar to an ATM CBR service, which has guaranteed bandwidth and 2346 which, if it stays within the negotiated rate, experiences nominal 2347 delay and no loss. 2349 Either of the above service classes can be configured as EF based by 2350 using a relaxed performance parameter and a rate scheduler. 2352 When a user/endpoint has been authorized to start a new session 2353 (i.e., joins a networked game or logs onto a virtualized 2354 workstation), the admission procedure should have verified that the 2355 newly admitted data rates will be within the engineered capacity of 2356 the Realtime-Interactive service class. The bandwidth in the core 2357 network and the number of simultaneous Realtime-Interactive sessions 2358 that can be supported SHOULD be engineered to control traffic load 2359 for this service. 2361 This service class SHOULD be configured to provide a high assurance 2362 for bandwidth for CS5 PHB, defined in [RFC2474], or CS5-Admit 2363 [ID-DSCP] for guaranteed service through a capacity-admission 2364 signaling protocol. The Realtime-Interactive service class SHOULD be 2365 configured to use a Rate Queuing system such as that defined in 2366 Section 1.4.1.2 of this document. Note that either 2367 Realtime-Interactive PHB MAY be configured as another EF PHB, 2368 specifically CS5-Admit, that uses a relaxed performance parameter 2369 and a rate scheduler, in the priority queue as defined in Section 2370 1.4.1.1 of this document. 2372 The following applications MUST use the Realtime-Interactive service 2373 class: 2375 o Interactive gaming and control. 2377 o Remote Desktop applications 2379 o Virtualized Desktop applications. 2381 o Application server-to-application server non-bursty data transfer 2382 requiring very low delay. 2384 o Inelastic, interactive, time-critical, and mission-critical 2385 applications requiring very low delay. 2387 The following are traffic characteristics: 2389 o Variable size packets. 2391 o Variable rate, though sometimes bursty, which will require 2392 engineering of the network to accommodate. 2394 o Application is sensitive to delay variation between flows and 2395 sessions. 2397 o Lost packets, if any, are usually ignored by application. 2399 RECOMMENDED DSCP marking: 2401 o All non-admitted flows in this service class are marked with CS5 2402 (Class Selector 5). 2404 o All capacity-admitted flows in this service class are marked with 2405 CS5-Admit. 2407 Applications or IP end points SHOULD pre-mark their packets with CS5 2408 or CS5-Admit DSCP value, depending on whether a capacity-admission 2409 signaling protocol is used for a flow. If the end point is not 2410 capable of setting the DSCP value, then the router topologically 2411 closest to the end point SHOULD perform Multifield (MF) 2412 Classification, as defined in [RFC2475]. 2414 RECOMMENDED conditioning performed at DiffServ network edge: 2416 o Packet flow marking (DSCP setting) from untrusted sources (end 2417 user devices) SHOULD be verified at ingress to DiffServ network 2418 using Multifield (MF) Classification methods defined in 2419 [RFC2475]. 2421 o Packet flows from untrusted sources (end user devices) SHOULD be 2422 policed at ingress to DiffServ network, e.g., using single rate 2423 with burst size token bucket policer to ensure that the traffic 2424 stays within its negotiated or engineered bounds. 2426 o Packet flows from trusted sources (application servers inside 2427 administered network) MAY not require policing. 2429 o Policing of packet flows across peering points MUST adhere to the 2430 Service Level Agreement (SLA). 2432 The fundamental service offered to nonadmitted 2433 "Realtime-Interactive" traffic is enhanced best-effort service with 2434 controlled rate and delay. The fundamental service offered to 2435 capacity-admitted "Realtime-Interactive" traffic is a guaranteed 2436 service using in-data-path signaling to ensure expected or timely 2437 delivery. Capacity-admitted Realtime-Interactive service SHOULD NOT 2438 result in packet loss. The service SHOULD be engineered so that CS5 2439 marked packet flows have sufficient bandwidth in the network to 2440 provide high assurance of delivery. Normally, traffic in this 2441 service class does not respond dynamically to packet loss. As such, 2442 Active Queue Management [RFC2309] SHOULD NOT be applied to CS5 2443 marked packet flows. 2445 4.3. Multimedia Conferencing Service Class 2447 The Multimedia Conferencing service class is for applications that 2448 have a low to medium tolerance to delay, and are rate adaptive to 2449 lost packets in transit from sources. Presentation Data 2450 applications that are operational in conjunction with an audio/video 2451 conference is one good example of such an application. Another set 2452 of applications is application sharing or whiteboarding 2453 applications, also in conjunction to an A/V conference. In either 2454 case, the audio & video part of the flow MUST NOT use the Multimedia 2455 Conferencing service class, rather the more appropriate service 2456 class within the Conversational service group discussed earlier in 2457 Section 4.1. 2459 The Multimedia Conferencing service class will use two PHBs: 2461 Nonadmitted Multimedia Conferencing traffic - MUST use the (new) 2462 MC DSCP [ID-DSCP], and is for traffic that has not had any 2463 capacity admission signaling performed for that flow or 2464 session. 2466 Capacity-Admitted Multimedia Conferencing traffic - MUST use the 2467 (new) MC-Admit DSCP [ID-DSCP], and is for traffic that has 2468 had any capacity admission signaling performed for that flow 2469 or session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. 2471 The capacity-admitted Multimedia Conferencing traffic operation is 2472 similar to an ATM CBR service, which has guaranteed bandwidth and 2473 which, if it stays within the negotiated rate, experiences nominal 2474 delay and no loss. 2476 When a user/endpoint initiates a presentation data, application 2477 sharing or whiteboarding session, it will typically be part of an 2478 audio or audio/video conference such as web-conferencing or an 2479 existing Telepresence call. The authorization procedure SHOULD be 2480 controlled through the coordinated effort to bind the A/V call with 2481 the correct Multimedia Conferencing packet flow through some use of 2482 identifiers not in scope of this document. The managed network this 2483 flow traverse and the number of simultaneous Multimedia 2484 Conferencing sessions that can be supported SHOULD be engineered to 2485 control traffic load for this service. 2487 The non-capacity admitted Multimedia Conferencing service class 2488 SHOULD use the new MC PHB, defined in [ID-DSCP]. This service class 2489 SHOULD be configured to provide a high assurance for bandwidth for 2490 CS5 marked packets to ensure that they get forwarded. The 2491 Multimedia Conferencing service class SHOULD be configured to use a 2492 Rate Queuing system such as that defined in Section 1.4.1.2 of this 2493 document. Note that this service class MAY be configured as another 2494 EF PHB that uses a relaxed performance parameter, a rate scheduler, 2495 and MC-Admit DSCP value, which MUST use the priority queue as 2496 defined in Section 1.4.1.1 of this document. 2498 The following applications MUST use the Multimedia Conferencing 2499 service class: 2501 o Presentation Data applications, which can utilize vector 2502 graphics, raster graphics or video delivery. 2504 o Virtualized Desktop applications. 2506 o Application server-to-application server non-bursty data transfer 2507 requiring very low delay. 2509 The following are traffic characteristics: 2511 o Variable size packets. 2513 o Variable rate, though sometimes bursty, which will require 2514 engineering of the network to accommodate. 2516 o Application is sensitive to delay variation between flows and 2517 sessions. 2519 o Lost packets, if any, can be ignored by the application. 2521 RECOMMENDED DSCP marking: 2523 o All non-admitted flows in this service class are marked with the 2524 new MC DSCP. 2526 o All capacity-admitted flows in this service class are marked with 2527 MC-Admit. 2529 Applications or IP end points SHOULD pre-mark their packets with the 2530 MC DSCP value. If the end point is not capable of setting the DSCP 2531 value, then the router topologically closest to the end point SHOULD 2532 perform Multifield (MF) Classification, as defined in [RFC2475]. 2534 RECOMMENDED conditioning performed at DiffServ network edge: 2536 o Packet flow marking (DSCP setting) from untrusted sources (end 2537 user devices) SHOULD be verified at ingress to DiffServ network 2538 using Multifield (MF) Classification methods defined in 2539 [RFC2475]. 2541 o Packet flows from untrusted sources (end user devices) SHOULD be 2542 policed at ingress to DiffServ network, e.g., using single rate 2543 with burst size token bucket policer to ensure that the traffic 2544 stays within its negotiated or engineered bounds. 2546 o Packet flows from trusted sources (application servers inside 2547 administered network) MAY not require policing. 2549 o Policing of packet flows across peering points MUST adhere to the 2550 Service Level Agreement (SLA). 2552 The fundamental service offered to nonadmitted "Multimedia 2553 Conferencing" traffic is enhanced best-effort service with 2554 controlled rate and delay. The fundamental service offered to 2555 capacity-admitted "Multimedia Conferencing" traffic is a guaranteed 2556 service using in-data-path signaling to ensure expected or timely 2557 delivery. Capacity-admitted Multimedia Conferencing service SHOULD 2558 NOT result in packet loss. The service SHOULD be engineered so that 2559 Multimedia Conferencing marked packet flows have sufficient 2560 bandwidth in the network to provide high assurance of delivery. 2561 Normally, traffic in this service class does not respond dynamically 2562 to packet loss. As such, Active Queue Management [RFC2309] SHOULD 2563 NOT be applied to MC or MC-Admit marked packet flows. 2565 4.4. Multimedia Streaming Service Class 2566 The Multimedia Streaming service class is RECOMMENDED for 2567 applications that require near-real-time packet forwarding of 2568 variable rate elastic traffic sources that are not as delay 2569 sensitive as applications using the Broadcast service class. Such 2570 applications include streaming audio and video, some video (movies) 2571 on-demand applications, and non-interactive webcasts. In general, 2572 the Multimedia Streaming service class assumes that the traffic is 2573 buffered at the source/destination; therefore, it is less sensitive 2574 to delay and jitter. 2576 The Multimedia Streaming service class MUST use the Assured 2577 Forwarding (AF3x) PHB, defined in [RFC2597]. This service class 2578 MUST be configured to provide a minimum bandwidth assurance for 2579 AF31, AF32, and AF33 marked packets to ensure that they get 2580 forwarded. The Multimedia Streaming service class SHOULD be 2581 configured to use Rate Queuing system for AF32 and AF33 traffic 2582 flows, such as that defined in Section 1.4.1.2 of this document. 2583 However, AF31 MUST be designated as the DSCP for use when 2584 capacity-admission signaling has been used, such as RSVP or NSIS, to 2585 guarantee delivery through the network. AF32 and AF33 will be used 2586 for non-admitted streaming flows, as well as overflows from AF31 2587 sources that send more packets than they have negotiated bandwidth 2588 for that call. 2590 The following applications SHOULD use the Multimedia Streaming 2591 service class: 2593 o Buffered streaming audio (unicast). 2595 o Buffered streaming video (unicast). 2597 o Non-interactive Webcasts. 2599 o IP VPN service that specifies two rates and is less sensitive to 2600 delay and jitter. 2602 The following are traffic characteristics: 2604 o Variable size packets. 2606 o The higher the rate, the higher the density of large packets. 2608 o Variable rate. 2610 o Elastic flows. 2612 o Some bursting at start of flow from some applications, as well as 2613 an expected stepping up and down on the rate of the flow based on 2614 changes in resolution due to network conditions. 2616 Applications or IP end points SHOULD pre-mark their packets with 2617 DSCP values as shown below. If the end point is not capable of 2618 setting the DSCP value, then the router topologically closest to the 2619 end point SHOULD perform Multifield (MF) Classification, as defined 2620 in [RFC2475], and mark all packets as AF3x. Note: In this case, 2621 the two-rate, three-color marker will be configured to operate in 2622 Color-Blind mode. 2624 RECOMMENDED DSCP marking: 2626 o AF31 = up to specified rate "A". 2628 o AF32 = all traffic marked AF31 in excess of specified rate "A", 2629 or new AF32 traffic but below specified rate "B". 2631 o AF33 = in excess of specified rate "B". 2633 o Where "A" < "B". 2635 Note: One might expect "A" to approximate the peak rates of sum of 2636 all streaming flows, plus the sum of the mean rates and "B" to 2637 approximate the sum of the peak rates of those same two flows. 2639 RECOMMENDED conditioning performed at DiffServ network edge: 2641 o The two-rate, three-color marker SHOULD be configured to provide 2642 the behavior as defined in trTCM [RFC2698]. 2644 o If packets are marked by trusted sources or a previously trusted 2645 DiffServ domain and the color marking is to be preserved, then 2646 the two-rate, three-color marker SHOULD be configured to operate 2647 in Color-Aware mode. 2649 o If the packet marking is not trusted or the color marking is not 2650 to be preserved, then the two-rate, three-color marker SHOULD be 2651 configured to operate in Color-Blind mode. 2653 The fundamental service offered to nonadmitted "Multimedia 2654 Streaming" traffic is enhanced best-effort service with controlled 2655 rate and delay. The fundamental service offered to 2656 capacity-admitted "Multimedia Streaming" traffic is a guaranteed 2657 service using in-data-path signaling to ensure expected delivery in 2658 a reasonable manner. The service SHOULD be engineered so that AF31 2659 marked packet flows have sufficient bandwidth in the network to 2660 provide high assurance of delivery. Since the AF3x traffic is 2661 elastic and responds dynamically to packet loss, Active Queue 2662 Management [RFC2309] SHOULD be used primarily to reduce forwarding 2663 rate to the minimum assured rate at congestion points, unless AF31 2664 has had a capacity-admission signaling protocol applied to the flow, 2665 such as RSVP or NSIS. 2667 If a capacity-admission signaling protocol applied to the AF31 flow, 2668 which SHOULD be the case always, the AF31 PHB MAY be configured as 2669 another EF PHB that uses a relaxed performance parameter and a rate 2670 scheduler, in the priority queue as defined in Section 1.4.1.1 of 2671 this document. 2673 The probability of loss of AF31 traffic MUST NOT exceed the 2674 probability of loss of AF32 traffic, which in turn MUST NOT exceed 2675 the probability of loss of AF33. 2677 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2678 specifies a target queue depth for each DSCP, and the max-threshold 2679 specifies the queue depth above which all traffic with such a DSCP 2680 is dropped or ECN marked. Thus, in this service class, the 2681 following inequality MUST hold in queue configurations: 2683 o min-threshold AF33 < max-threshold AF33 2685 o max-threshold AF33 <= min-threshold AF32 2687 o min-threshold AF32 < max-threshold AF32 2689 o max-threshold AF32 <= min-threshold AF31 2691 o min-threshold AF31 < max-threshold AF31 2693 o max-threshold AF31 <= memory assigned to the queue 2695 Note#1: this confirmation MUST be modified if AF31 has a 2696 capacity-admission signaling protocol applied to those 2697 flows, and the above will only apply to AF32 and AF33, while 2698 AF31 (theoretically) has no packet loss. 2700 Note#2: This configuration tends to drop AF33 traffic before AF32 2701 and AF32 before AF31. Note: Many other AQM algorithms exist 2702 and are used; they SHOULD be configured to achieve a similar 2703 result. 2705 4.5. Broadcast Service Class 2707 The Broadcast service class is RECOMMENDED for applications that 2708 require near-real-time packet forwarding with very low packet loss 2709 of constant rate and variable rate inelastic traffic sources that 2710 are more delay sensitive than applications using the Multimedia 2711 Streaming service class. Such applications include broadcast TV, 2712 streaming of live audio and video events, some video-on-demand 2713 applications, and video surveillance. In general, the Broadcast 2714 service class assumes that the destination end point has a dejitter 2715 buffer, for video application usually a 2 - 8 video-frame buffer (66 2716 to several hundred of milliseconds), thus expecting far less 2717 buffering before play-out than Multimedia Streaming, which can 2718 buffer in the seconds to minutes (to hours). 2720 The Broadcast service class will use two PHBs: 2722 Nonadmitted Broadcast traffic - MUST use the CS3 DSCP [RFC2474], 2723 and is for traffic that has not had any capacity admission 2724 signaling performed for that flow or session. 2726 Capacity-Admitted Broadcast traffic - MUST use the CS3-Admit DSCP 2727 [ID-DSCP], and is for traffic that has had any capacity 2728 admission signaling performed for that flow or session, e.g., 2729 RSVP [RFC2205] or NSIS [RFC4080]. 2731 The capacity-admitted Broadcast traffic operation is similar to an 2732 ATM CBR service, which has guaranteed bandwidth and which, if it 2733 stays within the negotiated rate, experiences nominal delay and no 2734 loss. 2736 Either of the above service classes can be configured as EF based by 2737 using a relaxed performance parameter and a rate scheduler. 2739 When a user/endpoint initiates a new Broadcast session (i.e., starts 2740 an Internet radio application, starts a live Internet A/V event or a 2741 camera comes online to do video-surveillance), the admission 2742 procedure should be verified within the application that triggers 2743 the flow. The newly admitted data rates will SHOULD be within the 2744 engineered capacity of the Broadcast service class within that 2745 network. The bandwidth in the core network and the number of 2746 simultaneous Broadcast sessions that can be supported SHOULD be 2747 engineered to control traffic load for this service. 2749 This service class SHOULD be configured to provide high assurance 2750 for bandwidth for CS3 marked packets to ensure that they get 2751 forwarded. The Broadcast service class SHOULD be configured to use 2752 Rate Queuing system such as that defined in Section 1.4.1.2 of this 2753 document. Note that either Broadcast PHB MAY be configured as 2754 another EF PHB, specifically CS3-Admit, that uses a relaxed 2755 performance parameter and a rate scheduler, in the priority queue as 2756 defined in Section 1.4.1.1 of this document. 2758 The following applications SHOULD use the Broadcast service class: 2760 o Video surveillance and security (unicast). 2762 o TV broadcast including HDTV (likely multicast, but can be 2763 unicast). 2765 o Video on demand (unicast) with control (virtual DVD). 2767 o Streaming of live audio events (both unicast and multicast). 2769 o Streaming of live video events (both unicast and multicast). 2771 The following are traffic characteristics: 2773 o Variable size packets. 2775 o The higher the rate, the higher the density of large packets. 2777 o Mixture of variable rate and constant rate flows. 2779 o Fixed packet emission time intervals. 2781 o Inelastic flows. 2783 RECOMMENDED DSCP marking: 2785 o All non-admitted flows in this service class are marked with CS3 2786 (Class Selector 3). 2788 o All capacity-admitted flows in this service class are marked with 2789 CS3-Admit. 2791 o In some cases, such as those for security and video surveillance 2792 applications, it is NOT RECOMMENDED, but allowed to use a 2793 different DSCP marking. 2795 If so, then locally user definable (EXP/LU) codepoints in the 2796 range '011x11' MAY be used to provide unique traffic 2797 identification. The locally administrator definable (EXP/LU, 2798 from pool 2 of RFC 2474) codepoint(s) MAY be associated with the 2799 PHB that is used for CS3 or CS3-Admit traffic. Furthermore, 2800 depending on the network scenario, additional network edge 2801 conditioning policy MAY be needed for the EXP/LU codepoint(s) 2802 used. 2804 Applications or IP end points SHOULD pre-mark their packets with CS3 2805 or CS3-Admit DSCP value. If the end point is not capable of setting 2806 the DSCP value, then the router topologically closest to the end 2807 point SHOULD perform Multifield (MF) Classification, as defined in 2808 [RFC2475]. 2810 RECOMMENDED conditioning performed at DiffServ network edge: 2812 o Packet flow marking (DSCP setting) from untrusted sources (end 2813 user devices) SHOULD be verified at ingress to DiffServ network 2814 using Multifield (MF) Classification methods defined in 2815 [RFC2475]. 2817 o Packet flows from untrusted sources (end user devices) SHOULD be 2818 policed at ingress to DiffServ network, e.g., using single rate 2819 with burst size token bucket policer to ensure that the traffic 2820 stays within its negotiated or engineered bounds. 2822 o Packet flows from trusted sources (application servers inside 2823 administered network) MAY not require policing. 2825 o Policing of packet flows across peering points MUST be performed 2826 to the Service Level Agreement (SLA) of those peering entities. 2828 The fundamental service offered to "Broadcast" traffic is enhanced 2829 best-effort service with controlled rate and delay. The fundamental 2830 service offered to capacity-admitted "Broadcast" traffic is a 2831 guaranteed service using in-data-path signaling to ensure expected 2832 or timely delivery. Capacity-admitted Broadcast service SHOULD NOT 2833 result in packet loss. The service SHOULD be engineered so that CS3 2834 and CS3-Admit marked packet flows have sufficient bandwidth in the 2835 network to provide high assurance of delivery. Normally, traffic in 2836 this service class does not respond dynamically to packet loss. As 2837 such, Active Queue Management [RFC2309] SHOULD NOT be applied to 2838 CS3 marked packet flows. 2840 4.6. Low-Latency Data Service Class 2842 The Low-Latency Data service class is RECOMMENDED for elastic and 2843 responsive typically client-/server-based applications. 2844 Applications forwarded by this service class are those that require 2845 a relatively fast response and typically have asymmetrical bandwidth 2846 need, i.e., the client typically sends a short message to the server 2847 and the server responds with a much larger data flow back to the 2848 client. The most common example of this is when a user clicks a 2849 hyperlink (~ few dozen bytes) on a web page, resulting in a new web 2850 page to be loaded (Kbytes or MBs of data). This service class is 2851 configured to provide good response for TCP [RFC1633] short-lived 2852 flows that require real-time packet forwarding of variable rate 2853 traffic sources. 2855 The Low-Latency Data service class SHOULD use the Assured Forwarding 2856 (AF) PHB, defined in [RFC2597]. This service class SHOULD be 2857 configured to provide a minimum bandwidth assurance for AF21, AF22, 2858 and AF23 marked packets to ensure that they get forwarded. The 2859 Low-Latency Data service class SHOULD be configured to use a Rate 2860 Queuing system such as that defined in Section 1.4.1.2 of this 2861 document. 2863 The following applications SHOULD use the Low-Latency Data service 2864 class: 2866 o Client/server applications. 2868 o Systems Network Architecture (SNA) terminal to host transactions 2869 (SNA over IP using Data Link Switching (DLSw)). 2871 o Web-based transactions (E-commerce). 2873 o Credit card transactions. 2875 o Financial wire transfers. 2877 o Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN). 2879 o VPN service that supports Committed Information Rate (CIR) with 2880 up to two burst sizes. 2882 o Instant Messaging and Presence protocols (e.g., SIP, XMPP). 2884 The following are traffic characteristics: 2886 o Variable size packets. 2888 o Variable packet emission rate. 2890 o With packet bursts of TCP window size. 2892 o Short traffic bursts. 2894 o Source capable of reducing its transmission rate based on 2895 detection of packet loss at the receiver or through explicit 2896 congestion notification. 2898 Applications or IP end points SHOULD pre-mark their packets with 2899 DSCP values as shown below. If the end point is not capable of 2900 setting the DSCP value, then the router topologically closest to the 2901 end point SHOULD perform Multifield (MF) Classification, as defined 2902 in [RFC2475] and mark all packets as AF2x. Note: In this case, the 2903 single-rate, three-color marker will be configured to operate in 2904 Color-Blind mode. 2906 RECOMMENDED DSCP marking: 2908 o AF21 = flow stream with packet burst size up to "A" bytes. 2910 o AF22 = flow stream with packet burst size in excess of "A" but 2911 below "B" bytes. 2913 o AF23 = flow stream with packet burst size in excess of "B" bytes. 2915 o Where "A" < "B". 2917 RECOMMENDED conditioning performed at DiffServ network edge: 2919 o The single-rate, three-color marker SHOULD be configured to 2920 provide the behavior as defined in srTCM [RFC2697]. 2922 o If packets are marked by trusted sources or a previously trusted 2923 DiffServ domain and the color marking is to be preserved, then 2924 the single-rate, three-color marker SHOULD be configured to 2925 operate in Color-Aware mode. 2927 o If the packet marking is not trusted or the color marking is 2928 not to be preserved, then the single-rate, three-color marker 2929 SHOULD be configured to operate in Color-Blind mode. 2931 The fundamental service offered to "Low-Latency Data" traffic is 2932 enhanced best-effort service with controlled rate and delay. The 2933 service SHOULD be engineered so that AF21 marked packet flows have 2934 sufficient bandwidth in the network to provide high assurance of 2935 delivery. Since the AF2x traffic is elastic and responds 2936 dynamically to packet loss, Active Queue Management [RFC2309] SHOULD 2937 be used primarily to control TCP flow rates at congestion points by 2938 dropping packets from TCP flows that have large burst size. The 2939 probability of loss of AF21 traffic MUST NOT exceed the probability 2940 of loss of AF22 traffic, which in turn MUST NOT exceed the 2941 probability of loss of AF23. Explicit Congestion Notification (ECN) 2942 [RFC3168] MAY also be used with Active Queue Management. 2944 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2945 specifies a target queue depth for each DSCP, and the max-threshold 2946 specifies the queue depth above which all traffic with such a DSCP 2947 is dropped or ECN marked. Thus, in this service class, the 2948 following inequality should hold in queue configurations: 2950 o min-threshold AF23 < max-threshold AF23 2952 o max-threshold AF23 <= min-threshold AF22 2954 o min-threshold AF22 < max-threshold AF22 2956 o max-threshold AF22 <= min-threshold AF21 2958 o min-threshold AF21 < max-threshold AF21 2960 o max-threshold AF21 <= memory assigned to the queue 2962 Note: This configuration tends to drop AF23 traffic before AF22 and 2963 AF22 before AF21. Many other AQM algorithms exist and are 2964 used; they should be configured to achieve a similar result. 2966 4.7. Conversational Signaling Service Class 2968 The Signaling service class is MUST be limited to delay-sensitive 2969 signaling traffic only, and then only applying to signaling that 2970 involves the Conversational service group. Audio signaling includes 2971 signaling between IP phone and soft-switch, soft-client and 2972 soft-switch, and media gateway and soft-switch as well as 2973 peer-to-peer using various protocols. Video and Hi-Res signaling 2974 includes video endpoint to video endpoint, as well as to Media 2975 transfer Point (MTP), to call control server(S), etc. This service 2976 class is intended to be used for control of voice and video sessions 2977 and applications. Protocols using this service class require a 2978 relatively fast response, as there are typically several messages of 2979 different sizes sent for control of the session. This service class 2980 is configured to provide good response for short-lived, intermittent 2981 flows that require real-time packet forwarding. This is not the 2982 service class for Instant Messaging (IM), that's within the bounds 2983 of the Low-Latency Data service class. The Conversational Signaling 2984 service class MUST be configured so that the probability of packet 2985 drop or significant queuing delay under peak load is very low in IP 2986 network segments that provide this interface. 2988 The Conversational Signaling service class MUST use the new A/V-Sig 2989 PHB, defined in [ID-DSCP]. This service class MUST be configured to 2990 provide a minimum bandwidth assurance for A/V-Sig marked packets to 2991 ensure that they get forwarded. In other words, this service class 2992 MUST NOT be starved from transmission within a reasonable timeframe, 2993 given that the entire Conversational service group depends on these 2994 signaling messages successful delivery. Network engineering SHOULD 2995 be done to ensure there is roughly 1-4% available per node interface 2996 that audio and video traverse. Local conditions MUST be considered 2997 when determining exactly how much bandwidth is given to this service 2998 class. The Conversational Signaling service class SHOULD be 2999 configured to use a Rate Queuing system such as that defined in 3000 Section 1.4.1.2 of this document. 3002 The following applications SHOULD use the Conversational Signaling 3003 service class: 3005 o Peer-to-peer IP telephony signaling (e.g., SIP, H.323, XMPP). 3007 o Peer-to-peer signaling for multimedia applications (e.g., SIP, 3008 H.323, XMPP). 3010 o Peer-to-peer real-time control function. 3012 o Client-server IP telephony signaling using H.248, MEGACO, MGCP, 3013 IP encapsulated ISDN, or other proprietary protocols. 3015 o Signaling to control IPTV applications using protocols such as 3016 IGMP. 3018 o Signaling flows between high-capacity telephony call servers or 3019 soft switches using protocol such as SIP-T. Such high-capacity 3020 devices may control thousands of telephony (VoIP) calls. 3022 o Signaling for one-way video flows, such as RTSP [RFC2326]. 3024 o IGMP, when used for multicast session control such as channel 3025 changing in IPTV systems. 3027 o OPTIONALLY, this service class can be used for on-path 3028 reservation signaling for the traffic flows that will use the 3029 "admitted" DSCPs. The alternative is to have the on-path 3030 signaling (for reservations) use the DSCP within that service 3031 class. This provides a similar treatment of the signaling to the 3032 data flow, which might be desired. 3034 The following are traffic characteristics: 3036 o Variable size packets, normally one packet at a time. 3038 o Intermittent traffic flows. 3040 o Traffic may burst at times. 3042 o Delay-sensitive control messages sent between two end points. 3044 RECOMMENDED DSCP marking: 3046 o All flows in this service class are marked with A/V-Sig. 3048 Applications or IP end points SHOULD pre-mark their packets with 3049 A/V-Sig DSCP value. If the end point is not capable of setting the 3050 DSCP value, then the router topologically closest to the end point 3051 SHOULD perform Multifield (MF) Classification, as defined in 3052 [RFC2475]. 3054 RECOMMENDED conditioning performed at DiffServ network edge: 3056 o Packet flow marking (DSCP setting) from untrusted sources (end 3057 user devices) SHOULD be verified at ingress to DiffServ network 3058 using Multifield (MF) Classification methods defined in 3059 [RFC2475]. 3061 o Packet flows from untrusted sources (end user devices) SHOULD be 3062 policed at ingress to DiffServ network, e.g., using single rate 3063 with burst size token bucket policer to ensure that the traffic 3064 stays within its negotiated or engineered bounds. 3066 o Packet flows from trusted sources (application servers inside 3067 administered network) MAY not require policing. 3069 o Policing of packet flows across peering points in which each peer 3070 is participating in the call set-up MUST be performed to the 3071 Service Level Agreement (SLA). 3073 The fundamental service offered to "Conversational Signaling" 3074 traffic is enhanced best-effort service with controlled rate and 3075 delay. The service SHOULD be engineered so that A/V-Sig marked 3076 packet flows have sufficient bandwidth in the network to provide 3077 high assurance of delivery and low delay. Normally, traffic in this 3078 service class does not respond dynamically to packet loss. As such, 3079 Active Queue Management [RFC2309] SHOULD NOT be applied to A/V-Sig 3080 marked packet flows. 3082 4.8. High-Throughput Data Service Class 3083 The High-Throughput Data service class is RECOMMENDED for elastic 3084 applications that require timely packet forwarding of variable rate 3085 traffic sources and, more specifically, is configured to provide 3086 good throughput for TCP longer-lived flows. TCP [RFC1633] or a 3087 transport with a consistent Congestion Avoidance Procedure [RFC2581] 3088 [RFC3782] normally will drive as high a data rate as it can obtain 3089 over a long period of time. The FTP protocol is a common example, 3090 although one cannot definitively say that all FTP transfers are 3091 moving data in bulk. 3093 The High-Throughput Data service class SHOULD use the Assured 3094 Forwarding (AF) PHB, defined in [RFC2597]. This service class 3095 SHOULD be configured to provide a minimum bandwidth assurance for 3096 AF11, AF12, and AF13 marked packets to ensure that they are 3097 forwarded in a timely manner. The High-Throughput Data service 3098 class SHOULD be configured to use a Rate Queuing system such as that 3099 defined in Section 1.4.1.2 of this document. 3101 The following applications SHOULD use the High-Throughput Data 3102 service class: 3104 o Store and forward applications. 3106 o File transfer applications (e.g., FTP, HTTP, etc). 3108 o Email. 3110 o VPN service that supports two rates (committed information rate 3111 and excess or peak information rate). 3113 The following are traffic characteristics: 3115 o Variable size packets. 3117 o Variable packet emission rate. 3119 o Variable rate. 3121 o With packet bursts of TCP window size. 3123 o Source capable of reducing its transmission rate based on 3124 detection of packet loss at the receiver or through explicit 3125 congestion notification. 3127 Applications or IP end points SHOULD pre-mark their packets with 3128 DSCP values as shown below. If the end point is not capable of 3129 setting the DSCP value, then the router topologically closest to the 3130 end point SHOULD perform Multifield (MF) Classification, as defined 3131 in [RFC2475], and mark all packets as AF1x. Note: In this case, the 3132 two-rate, three-color marker will be configured to operate in 3133 Color-Blind mode. 3135 RECOMMENDED DSCP marking: 3137 o AF11 = up to specified rate "A". 3139 o AF12 = in excess of specified rate "A" but below specified rate 3140 "B". 3142 o AF13 = in excess of specified rate "B". 3144 o Where "A" < "B". 3146 RECOMMENDED conditioning performed at DiffServ network edge: 3148 o The two-rate, three-color marker SHOULD be configured to provide 3149 the behavior as defined in trTCM [RFC2698]. 3151 o If packets are marked by trusted sources or a previously trusted 3152 DiffServ domain and the color marking is to be preserved, then 3153 the two-rate, three-color marker SHOULD be configured to operate 3154 in Color-Aware mode. 3156 o If the packet marking is not trusted or the color marking is not 3157 to be preserved, then the two-rate, three-color marker SHOULD be 3158 configured to operate in Color-Blind mode. 3160 The fundamental service offered to "High-Throughput Data" traffic is 3161 enhanced best-effort service with a specified minimum rate. The 3162 service SHOULD be engineered so that AF11 marked packet flows have 3163 sufficient bandwidth in the network to provide assured delivery. It 3164 can be assumed that this class will consume any available bandwidth 3165 and that packets traversing congested links may experience higher 3166 queuing delays or packet loss. Since the AF1x traffic is elastic 3167 and responds dynamically to packet loss, Active Queue Management 3168 [RFC2309] SHOULD be used primarily to control TCP flow rates at 3169 congestion points by dropping packets from TCP flows that have 3170 higher rates first. The probability of loss of AF11 traffic MUST 3171 NOT exceed the probability of loss of AF12 traffic, which in turn 3172 MUST NOT exceed the probability of loss of AF13. In such a case, if 3173 one network customer is driving significant excess and another seeks 3174 to use the link, any losses will be experienced by the high-rate 3175 user, causing him to reduce his rate. Explicit Congestion 3176 Notification (ECN) [RFC3168] MAY also be used with Active Queue 3177 Management. 3179 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3180 specifies a target queue depth for each DSCP, and the max-threshold 3181 specifies the queue depth above which all traffic with such a DSCP 3182 is dropped or ECN marked. Thus, in this service class, the 3183 following inequality should hold in queue configurations: 3185 o min-threshold AF13 < max-threshold AF13 3186 o max-threshold AF13 <= min-threshold AF12 3188 o min-threshold AF12 < max-threshold AF12 3190 o max-threshold AF12 <= min-threshold AF11 3192 o min-threshold AF11 < max-threshold AF11 3194 o max-threshold AF11 <= memory assigned to the queue 3196 Note: This configuration tends to drop AF13 traffic before AF12 and 3197 AF12 before AF11. Many other AQM algorithms exist and are 3198 used; they should be configured to achieve a similar result. 3200 4.9. Standard Service Class 3202 The Standard service class is RECOMMENDED for traffic that has not 3203 been classified into one of the other supported forwarding service 3204 classes in the DiffServ network domain. This service class provides 3205 the Internet's "best-effort" forwarding behavior. This service 3206 class typically has minimum bandwidth guarantee. 3208 The Standard service class MUST use the Default Forwarding (DF) PHB, 3209 defined in [RFC2474], and SHOULD be configured to receive at least a 3210 small percentage of forwarding resources as a guaranteed minimum. 3211 This service class SHOULD be configured to use a Rate Queuing system 3212 such as that defined in Section 1.4.1.2 of this document. 3214 The following applications SHOULD use the Standard service class: 3216 o Network services, DNS, DHCP, BootP. 3218 o Any undifferentiated application/packet flow transported through 3219 the DiffServ enabled network. 3221 The following is a traffic characteristic: 3223 o Non-deterministic, mixture of everything. 3225 The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'. 3227 Network Edge Conditioning: 3229 There is no requirement that conditioning of packet flows be 3230 performed for this service class. 3232 The fundamental service offered to the Standard service class is 3233 best-effort service with active queue management to limit overall 3234 delay. Typical configurations SHOULD use random packet dropping to 3235 implement Active Queue Management [RFC2309] or Explicit Congestion 3236 Notification [RFC3168], and MAY impose a minimum or maximum rate on 3237 the queue. 3239 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3240 specifies a target queue depth, and the max-threshold specifies the 3241 queue depth above which all traffic is dropped or ECN marked. Thus, 3242 in this service class, the following inequality should hold in queue 3243 configurations: 3245 o min-threshold DF < max-threshold DF 3247 o max-threshold DF <= memory assigned to the queue 3249 Note: Many other AQM algorithms exist and are used; they should be 3250 configured to achieve a similar result. 3252 4.10. Low-Priority Data 3254 The Low-Priority Data service class serves applications that run 3255 over TCP [RFC0793] or a transport with consistent congestion 3256 avoidance procedures [RFC2581] [RFC3782] and that the user is 3257 willing to accept service without guarantees. This service class is 3258 specified in [RFC3662] and [QBSS]. 3260 The following applications MAY use the Low-Priority Data service 3261 class: 3263 o Any TCP based-application/packet flow transported through the 3264 DiffServ enabled network that does not require any bandwidth 3265 assurances. 3267 The following is a traffic characteristic: 3269 o Non-real-time and elastic. 3271 Network Edge Conditioning: 3273 There is no requirement that conditioning of packet flows be 3274 performed for this service class. 3276 The RECOMMENDED DSCP marking is CS1 (Class Selector 1). 3278 The fundamental service offered to the Low-Priority Data service 3279 class is best-effort service with zero bandwidth assurance. By 3280 placing it into a separate queue or class, it may be treated in a 3281 manner consistent with a specific Service Level Agreement. 3283 Typical configurations SHOULD use Explicit Congestion Notification 3284 [RFC3168] or random loss to implement Active Queue Management 3285 [RFC2309]. 3287 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3288 specifies a target queue depth, and the max-threshold specifies the 3289 queue depth above which all traffic is dropped or ECN marked. Thus, 3290 in this service class, the following inequality should hold in queue 3291 configurations: 3293 o min-threshold CS1 < max-threshold CS1 3295 o max-threshold CS1 <= memory assigned to the queue 3297 Note: Many other AQM algorithms exist and are used; they should be 3298 configured to achieve a similar result. 3300 5. Additional Information on Service Class Usage 3302 In this section, we provide additional information on how some 3303 specific applications should be configured to use the defined 3304 service classes. 3306 5.1. Mapping for NTP 3308 From tests that were performed, indications are that precise time 3309 distribution requires a very low packet delay variation (jitter) 3310 transport. Therefore, we suggest that the following guidelines for 3311 Network Time Protocol (NTP) be used: 3313 o When NTP is used for providing high-accuracy timing within an 3314 administrator's (carrier's) network or to end users/clients, the 3315 audio service class SHOULD be used, and NTP packets should be 3316 marked with EF DSCP value. 3318 o For applications that require "wall clock" timing accuracy, the 3319 Standard service class should be used, and packets should be 3320 marked with DF DSCP. 3322 5.2. VPN Service Mapping 3324 "Differentiated Services and Tunnels" [RFC2983] considers the 3325 interaction of DiffServ architecture with IP tunnels of various 3326 forms. Further to guidelines provided in RFC 2983, below are 3327 additional guidelines for mapping service classes that are supported 3328 in one part of the network into a VPN connection. This discussion 3329 is limited to VPNs that use DiffServ technology for traffic 3330 differentiation. 3332 o The DSCP value(s) that is/are used to represent a PHB or a PHB 3333 group SHOULD be the same for the networks at both ends of the VPN 3334 tunnel, unless remarking of DSCP is done as ingress/egress 3335 processing function of the tunnel. DSCP marking needs to be 3336 preserved along the tunnel, end to end. 3338 o The VPN MAY be configured to support one or more service classes. 3339 It is left up to the administrators of the two networks to agree 3340 on the level of traffic differentiation that will be provided in 3341 the network that supports VPN service. Service classes are then 3342 mapped into the supported VPN traffic forwarding behaviors that 3343 meet the traffic characteristics and performance requirements of 3344 the encapsulated service classes. 3346 o The traffic treatment in the network that is providing the VPN 3347 service needs to be such that the encapsulated service class or 3348 classes receive comparable behavior and performance in terms of 3349 delay, jitter, and packet loss and that they are within the 3350 limits of the service specified. 3352 o The DSCP value in the external header of the packet forwarded 3353 through the network providing the VPN service can be different 3354 from the DSCP value that is used end to end for service 3355 differentiation in the end network. 3357 o The guidelines for aggregation of two or more service classes 3358 into a single traffic forwarding treatment in the network that is 3359 providing the VPN service is for further study. 3361 6. Security Considerations 3363 This document discusses policy and describes a common policy 3364 configuration, for the use of a Differentiated Services Code Point 3365 by transports and applications. If implemented as described, it 3366 should require that the network do nothing that the network has not 3367 already allowed. If that is the case, no new security issues should 3368 arise from the use of such a policy. 3370 It is possible for the policy to be applied incorrectly, or for a 3371 wrong policy to be applied in the network for the defined service 3372 class. In that case, a policy issue exists that the network SHOULD 3373 detect, assess, and deal with. This is a known security issue in 3374 any network dependent on policy-directed behavior. 3376 A well-known flaw appears when bandwidth is reserved or enabled for 3377 a service (for example, voice and/or video transport) and another 3378 service or an attacking traffic stream uses it. This possibility is 3379 inherent in DiffServ technology, which depends on appropriate packet 3380 markings. When bandwidth reservation or a priority queuing system is 3381 used in a vulnerable network, the use of authentication and flow 3382 admission is recommended. To the author's knowledge, there is no 3383 known technical way to respond to an unauthenticated data stream 3384 using service that it is not intended to use, and such is the nature 3385 of the Internet. 3387 The use of a service class by a user is not an issue when the SLA 3388 between the user and the network permits him to use it, or to use it 3389 up to a stated rate. In such cases, simple policing is used in the 3390 Differentiated Services Architecture. Some service classes, such as 3391 Network Control, are not permitted to be used by users at all; such 3392 traffic should be dropped or remarked by ingress filters. Where 3393 service classes are available under the SLA only to an authenticated 3394 user rather than to the entire population of users, authentication 3395 and authorization services are required, such as those surveyed in 3396 [AUTHMECH]. 3398 7. Contributing Authors 3400 This section specifically calls out the authors of RFC 4594, from 3401 which this document is based on. 3403 Jozef Babiarz 3404 Nortel Networks 3406 Kwok Ho Chan 3407 Nortel Networks 3408 Email: khchan.work@gmail.com 3410 Fred Baker 3411 Cisco Systems 3412 EMail: fred@cisco.com 3414 Of note, two of the three mentioned authors above worked for Nortel 3415 Networks at the time of writing RFC 4594, a company that no longer 3416 exists. This author has not seen or heard from those two in many, 3417 many years or IETF meetings - as a result of not knowing their new 3418 email addresses (or phone numbers). 3420 While much of this document has been rewritten with either edited or 3421 brand new material, there are many short paragraphs that remain as 3422 they were from RFC 4594, as well as many sentences that were also 3423 left unchanged. Additionally, there were no new graphs, charts, 3424 diagrams, or tables introduced, meaning the first 4 tables within 3425 this document existed in RFC 4594, created by those authors. 3426 Presently, each of those tables contain modified and new 3427 information. The last 3 tables, specifically tables 5, 6, & 7 were 3428 removed because the examples section was removed. 3430 This author believes there must be proper credit given for all the 3431 contributions, including the framework this document retains from 3432 that RFC. Periodically, throughout this document, what was written 3433 remains the best way of conveying a thought, rule, or otherwise 3434 stated behavior or mechanism. Because RFC 4594 was rather large, 3435 there is no realistic way of identifying each part that was left 3436 untouched. Further, properly quoting that RFC and leaving those 3437 sentences embedded in this document would render this document 3438 highly unreadable. Another application could be used to show the 3439 changes, deletions and additions - but not one that the IETF accepts 3440 presently. 3442 This author has created this "Contributing Authors" section as a way 3443 of properly identifying those 3 individuals that provided text 3444 within this document. We will let the community judge if this is 3445 'good enough' (i.e., rough consensus), or if another way is better. 3447 8. Acknowledgements 3449 The author would like to thank Paul Jones, Glen Lavers, Mo Zanaty, 3450 David Benham, Michael Ramalho, Gorry Fairhurst and David Black for 3451 their comments and questions about this effort that ultimately 3452 helped shape this document. 3454 Below are the folks that were acknowledged in RFC 4594, and this 3455 author does not want to lose their recognition of contributions to 3456 the original effort. 3458 "The authors thank the TSVWG reviewers, David Black, Brian E. 3459 Carpenter, and Alan O'Neill for their review and input to this 3460 document. 3462 The authors acknowledge a great many inputs, most notably from 3463 Bruce Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois 3464 Audet, Morgan Littlewood, Robert Milne, John Shuler, Nalin 3465 Mistry, Al Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil 3466 Dickinson, Mike Fidler, and Shane Amante. Kimberly King, Joe 3467 Zebarth, and Alistair Munroe each did a thorough proofreading, 3468 and the document is better for their contributions." 3470 9. References 3472 9.1. Normative References 3474 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3475 September 1981. 3477 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 3478 793, September 1981. 3480 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 3481 Suite", RFC 1349, July 1992. 3483 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 3484 1812, June 1995. 3486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3487 Requirement Levels", BCP 14, RFC 2119, March 1997. 3489 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 3490 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 3491 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 3492 S., Wroclawski, J., and L. Zhang, "Recommendations on 3493 Queue Management and Congestion Avoidance in the 3494 Internet", RFC 2309, April 1998. 3496 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3497 "Definition of the Differentiated Services Field (DS 3498 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 3499 1998. 3501 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 3502 and W. Weiss, "An Architecture for Differentiated 3503 Service", RFC 2475, December 1998. 3505 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 3506 "Assured Forwarding PHB Group", RFC 2597, June 1999. 3508 [RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le 3509 Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. 3510 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 3511 Behavior)", RFC 3246, March 2002. 3513 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 3514 Per-Domain Behavior (PDB) for Differentiated Services", 3515 RFC 3662, December 2003. 3517 [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code 3518 Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, 3519 May 2010 3521 9.2. Informative References 3523 [AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms", 3524 Work in Progress, September 2005. 3526 [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 3527 Technical Report Proposed Service Definition, March 2001. 3529 [IEEE1Q] IEEE, 802.1Q Specification 3531 [IEEE1E] IEEE, 802.1E Wireless LAN User Priority Specification 3533 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated 3534 Services in the Internet Architecture: an Overview", RFC 3535 1633, June 1994. 3537 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 3538 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 3539 Functional Specification", RFC 2205, September 1997. 3541 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 3542 Control", RFC 2581, April 1999. 3544 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 3545 Marker", RFC 2697, September 1999. 3547 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 3548 Marker", RFC 2698, September 1999. 3550 [RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive 3551 Shaper for Differentiated Services", RFC 2963, October 3552 2000. 3554 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 3555 2983, October 2000. 3557 [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, 3558 November 2000. 3560 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 3561 Differentiated Services Per Domain Behaviors and Rules 3562 for their Specification", RFC 3086, April 2001. 3564 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3565 of Explicit Congestion Notification (ECN) to IP", RFC 3566 3168, September 2001. 3568 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 3569 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3570 3175, September 2001. 3572 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 3573 Informal Management Model for Diffserv Routers", RFC 3290, 3574 May 2002. 3576 [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno 3577 Modification to TCP's Fast Recovery Algorithm", RFC 3782, 3578 April 2004. 3580 [RFC5462] L. Andersson, R. Asati, "Multiprotocol Label Switching 3581 (MPLS) Label Stack Entry: EXP Field Renamed to Traffic Class 3582 Field", RFC 5462, February 2009 3584 Authors' Address 3586 James Polk 3587 3913 Treemont Circle 3588 Colleyville, Texas 76034 3590 Phone: +1.817.271.3552 3591 Email: jmpolk@cisco.com 3592 Appendix A - Changes 3594 Here is a list of all the changes that were captured during the 3595 editing process. This will not be a complete list, and others are 3596 free to point out what the authors missed, and we'll include that in 3597 the next release. 3599 A.1 Since Individual -00 to -01 3601 o Added Section 2.4 which covers the conflation issues regarding 3602 the differences between service classes and treatment aggregates. 3604 o Added example operational configurations of treatment aggregates 3605 applied to this draft's new set of service classes and additional 3606 DSCPs. 3608 o Added references RFC 5865, RFC 5462, IEEE 802.1E and IEEE 802.1Q. 3610 A.2 Since RFC 4594 to Individual Update -00 3612 o rewrote Intro to emphasize current topics 3614 o Created a Conversational Service group, comprising the audio, 3615 video and Hi-Res service classes - because they have similar 3616 characteristics. 3618 o Incorporated the 6 new DSCPs from [ID-DSCP]. 3620 o moved the example section, en mass, to an appendix that might not 3621 be kept for this version. We're not sure it accomplishes what it 3622 needs to, and might not provide any real usefulness. 3624 o Moved 'Realtime-Interactive' service class to CS5, from CS4 3626 o Changed 'Broadcast Video' service class to 'Broadcast' service 3627 class 3629 o Changed AF4X to 'Video' service class, replacing 'Multimedia 3630 Conferencing' service class 3632 o Moved 'Multimedia Conferencing' service class to different DSCPs 3634 o Added the 'Hi-Res' service class 3636 o Removed section 5.1 on signaling choices. It has been included in 3637 the main body of the text. 3639 o Changed document title