idnits 2.17.1 draft-polk-tsvwg-rfc4594-update-02.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 74 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 6 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 2809 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 (Oct 22, 2012) is 4197 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 2828, but not defined == Missing Reference: 'ID-DSCP' is mentioned on line 3733, but not defined == Missing Reference: 'RFC5127' is mentioned on line 255, but not defined == Missing Reference: 'RFC4594' is mentioned on line 291, but not defined == Missing Reference: 'RFC2326' is mentioned on line 3121, but not defined ** Obsolete undefined reference: RFC 2326 (Obsoleted by RFC 7826) == Unused Reference: 'RFC2996' is defined on line 3662, but no explicit reference was found in the text == Unused Reference: 'RFC3175' is defined on line 3673, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1349 (Obsoleted by RFC 2474) ** Obsolete normative reference: RFC 2309 (Obsoleted by RFC 7567) ** Obsolete normative reference: RFC 3662 (Obsoleted by RFC 8622) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 3782 (Obsoleted by RFC 6582) Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network WG James Polk, ed. 3 Internet-Draft Cisco 4 Intended status: Standards Track (PS) Oct 22, 2012 5 Obsoletes: RFC 4594 6 Updates: RFC 5865 7 Expires: April 22, 2013 9 Standard Configuration of DiffServ Service Classes 10 draft-polk-tsvwg-rfc4594-update-02.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 April 22, 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 .....................................8 59 1.2. Expected Use in the Network ...............................8 60 1.3. Service Class Definition ..................................8 61 1.4. Key Differentiated Services Concepts .....................10 62 1.4.1. Queuing .............................................10 63 1.4.1.1. Priority Queuing ...........................10 64 1.4.1.2. Rate Queuing ...............................11 65 1.4.2. Active Queue Management .............................11 66 1.4.3. Traffic Conditioning ................................12 67 1.4.4. Differentiated Services Code Point (DSCP) ...........12 68 1.4.5. Per-Hop Behavior (PHB) ..............................13 69 1.5. Key Service Concepts .....................................13 70 1.5.1. Default Forwarding (DF) .............................13 71 1.5.2. Assured Forwarding (AF) .............................14 72 1.5.3. Expedited Forwarding (EF) ...........................14 73 1.5.4. Class Selector (CS) .................................15 74 1.5.5. Admission Control ...................................15 75 2. Service Differentiation .......................................16 76 2.1. Service Classes ..........................................16 77 2.2. Categorization of User Oriented Service Classes ..........18 78 2.3. Service Class Characteristics ............................22 79 2.4. Service Classes vs. Treatment Aggregate (from RFC 5127)...27 80 2.4.1 Examples of Service Classes in Treatment Aggregates...29 81 3. Network Control Traffic .......................................31 82 3.1. Current Practice in the Internet .........................32 83 3.2. Network Control Service Class ............................32 84 3.3. OAM Service Class ........................................34 85 4. User Oriented Traffic .........................................36 86 4.1. Conversational Service Class Group .......................36 87 4.1.1 Audio Service Class ..................................37 88 4.1.2 Video Service Class ..................................40 89 4.1.3 Hi-Res Service Class .................................44 90 4.2. Realtime-Interactive Service Class ...................... 47 91 4.3. Multimedia Conferencing Service Class ....................50 92 4.4. Multimedia Streaming Service Class .......................52 93 4.5. Broadcast Video Service Class ............................55 94 4.6. Low-Latency Data Service Class ...........................58 95 4.7. Conversational Signaling Service Class ...................60 96 4.8. High-Throughput Data Service Class .......................62 97 4.9. Standard Service Class ...................................65 98 4.10. Low-Priority Data .......................................66 99 5. Additional Information on Service Class Usage .................67 100 5.1. Mapping for NTP ..........................................67 101 5.2. VPN Service Mapping ......................................67 103 6. Security Considerations .......................................68 104 7. Contributing Authors ..........................................68 105 8. Acknowledgements ..............................................69 106 9. References ....................................................70 107 9.1. Normative References .....................................70 108 9.2. Informative References ...................................71 109 Author's Address .................................................72 110 Appendix A - Changes .............................................72 112 1. Introduction 114 Differentiated Services [RFC2474][RFC2475] provides the ability to 115 mark/label/classify IP packets differently to distinguish how 116 individual packets need to be treated differently through (or 117 throughout) a network on a per hop basis. Local administrators are 118 who configure each router for which Differentiated Services Code 119 Points (DSCP) are to be treated differently, which are to be 120 ignored (i.e., no differentiated treatment), and which DSCPs are to 121 have their packets remarked (to different DSCPs) as they pass 122 through a router. Local administrators are also who assign which 123 applications, or traffic types, should use which DSCPs to receive 124 the treatment the administrators expect within their network. 126 What most people fail to understand is that DSCPs provide a per hop 127 behavior (PHB) through that router, but not the previous or next 128 router. In this way of understanding PHB markings, one can 129 understand that Differentiated Services (DiffServ) is not a Quality 130 of Service (QoS) mechanism, but rather a Classification of Service 131 (CoS) mechanism. 133 For instance, there are 64 possible DSCP values, i.e., using 6 bits 134 of the old Type of Service (TOS) byte [RFC0791]. Each can be 135 configured locally to have greater or less treatment relative to any 136 other DSCP with two exceptions*. 138 * Expedited Forwarding (EF) [RFC3246] DSCPs have a treatment 139 requirement that any packet marked within an EF class has to be 140 the next packet transmitted out its egress interface. If there 141 are more than one EF marked packet in the queue, obviously the 142 queue sets the order they are transmitted. Further, if there 143 are more than one EF DSCP, local configuration determines if 144 each are treated the same or differently relate to each other 145 EF DSCP. Currently, there are two Expedited Forwarding DSCPs: 146 EF (101110) [RFC3246] and VOICE-ADMIT (101100) [RFC5865]. 148 * Class Selector 6 (CS6) [RFC2474] is for routing protocol 149 traffic. There are deemed important because if the network does 150 not transmit and receive its routing protocol traffic in a 151 timely manner, the network stops operating properly. 153 Not all are configured to mean anything other than best effort 154 forwarding by local administrators of a network. Let us say there 155 are 5 DSCPs configured within network A. Network A's administrator 156 chooses and configures which order (obeying the two exceptions noted 157 above) which application packets are treated differently than any 158 other packets within that network (A). The DSCPs are not fixed to a 159 linear order for relative priority on a per hop basis. Further, and 160 this is often the case, there might be packets with the same DSCP 161 arriving at multiple interfaces of a node, each egressing that node 162 out the same interface. At ingress to this node, everything was 163 fine, with no poor behavior or noticeably excessive amount of 164 packets with the same DSCP. However, at the egress interface, there 165 might not be enough capacity to satisfy the load, thus the departing 166 packets transmit at their maximum rate for that DSCP, but have 167 additional latency due to the overload within that one node. This is 168 called fan-in congestion (or problem). By itself, DiffServ will not 169 remedy this problem for the application that is intolerant to added 170 latency because DiffServ only functions within 1 node at a time. 172 An additional mechanism is needed to ensure each flow or session 173 receives the amount of packets at its destination that the 174 application requires to perform properly; a mechanism such as 175 IntServ, by way of RSVP [RFC2205] or NSIS [RFC4080]. With this added 176 capability to be session aware, something DiffServ is not, the 177 packets transmitted within a single session have a very good 178 probability of arriving in such a way the receiving application can 179 make full use of each. That said, signaling reservations for each 180 session or flow adds complexity, which creates more work for those 181 who maintain and administer such a network. Adding bandwidth and 182 using DiffServ marking is an easier pill to swallow. The deployment 183 of not few, but more and more audio and (particularly bandwidth 184 hogging) video codecs and their respective application rigidity has 185 caused some to conclude that throwing bandwidth at the problem is no 186 longer acceptable. 188 With this in mind, this document incorporates five of the six new 189 DSCPs from [ID-DSCP] identified as capacity-admitted DSCPs for most 190 of the service classes in this document. As explained in [ID-DSCP], 191 the five new capacity-admitted DSCPs are from Pool 3. [ID-DSCP] goes 192 further to explain that many layer 2 technologies use fewer bits for 193 marking and prioritization. Instead of six bits like DiffServ, they 194 have three bits, which yields a maximum of 8 values, which tend to 195 line up quite will with the TOS field values. Thus, aggregation of 196 DSCPs is typically accomplished by simply ignoring or reducing the 197 number of bits used to the most significant ones available, such as 199 EF is 101110, at layer 2 this is merely 101; 201 Broadcast is 011000, at layer 2 this is merely 011. 203 However, that was not a premise DiffServ was built upon, to merely 204 reduce the number of bits. In other words, within DiffServ, XXX is 205 not the same as XXX000 (where XXX is the same binary value in both 206 cases). 208 This document is originally built upon the RFC 4594 effort, while 209 updating some of the usages and expanding the scope for newer 210 applications that are in use today. The idea in RFC 4594 remains 211 true here, to define a set of service classes, each having unique 212 traffic characteristics, and assigning one or more DSCPs to each 213 service class. As much as the focus could be on the DSCP values, it 214 is not. The focus of this document is the unique traffic 215 characteristics of each service class. 217 There are many services classes defined in this document, not all 218 will be used in each network at any period of time. This consistency 219 packet markings we talk about is for several reasons, including in a 220 network that does not currently implement a certain service class 221 because they do not have that type of traffic in their network, or 222 that the network merely gives that traffic best effort service. 223 Having a solid guideline to know where to progress or reconfigure a 224 network and endpoints to, say from best effort for a particular 225 traffic type, is a very good thing to do more uniformly than not. A 226 fair amount of burden is placed at DS boundaries needing to keep up 227 with which markings turn into which other markings at both ingress 228 and egress to a network. The same holds true for application 229 developers choosing a default DSCP for their application, lacking a 230 guideline means everyone picks for themselves - and usually with a 231 highly inflated sense of self importance for their application or 232 service. 234 Another point to make is that there are 20+ service classes defined 235 within the IETF, and that is far too many for most service providers 236 to manage effectively. So, they have formed groups around certain 237 aggregation solutions of service classes. One such aggregation group 238 is based on RFC 5127, which defines what it calls a treatment 239 aggregate, which is taking RFC 4594's service classes and placing 240 them each into one of four treatment aggregates for service 241 providers to handle as a group. SG12 within the ITU-T has an 242 alternative that has nine aggregate groups, so there is work to be 243 done to harmonize aggregates of service classes. This discussion is 244 articulated more in section 2.4. At the end of Section 2.4 we have 245 introduced a series of example configurations which provide examples 246 of how only a few service classes - yet still most treatment 247 aggregates - can be configured in example networks. 249 Does RFC 4594 need updating? That document is an informational 250 guideline on how networks can or should mark certain packet flows 251 with differing traffic characteristics using DiffServ. There are 252 several reasons why this informational RFC lacks the necessary 253 clarity and strength to reach widespread adoption: 255 o confusion between RFC 4594 and RFC 5127 [RFC5127], the latter of 256 which is for aggregating many 6-bit DSCP values into a 3-bit (8 257 value) field used specifically by service provider (SP) networks. 259 o some believe both RFCs are for SPs, while others ignore RFC 5127 260 and use RFC 4594 as if it were standards track or BCP. 262 o some believe RFC 5127 is for SPs only, and want RFC 4594 to 263 reduce the number of DSCPs within its guidelines to recommend 264 using only 3 or 4 DSCPs. This seems to stem from a manageability 265 and operational perspective. 267 o some know RFC 4594 is informational and do not follow its 268 guidelines specifically because it is informational. 270 o some use DSCP values that are not defined within RFC 4594, making 271 mapping between different networks using similar or identical 272 application flows difficult. 274 o some believe enterprise networks should not use either RFC except 275 at the edge of their networks, where they directly connect to SP 276 networks. 278 o some argue that the services classes guidance per class is too 279 broad and are therefore not sure in which service class a 280 particular application is to reside. 282 o time has shown that video has become a dominant application on 283 the Internet, and many believe it now requires to be treated 284 uniquely in environments that want to. Video also does not always 285 plan nice with audio, so knowing the two use the same transport 286 (RTP) [RFC3550], a means of separation is in order. 288 Service class definitions are based on the different traffic 289 characteristics and required performance of the 290 applications/services. There are a greater number of service classes 291 in this document than there were when RFC 4594 [RFC4594] was 292 published (the RFC this document intends to obsolete). The required 293 performance of applications/services has also changed since the 294 publication of RFC 4594, specifically in the area of conversational 295 real time communications. As a result, this document has a greater 296 number of real time applications with more granular set of DSCPs due 297 to their different required performances. Like RFC 4594 before, this 298 approach allows those applications with similar traffic 299 characteristics and performance requirements to be placed in the 300 same service class. 302 The notion of traffic characteristics and required performance is a 303 per application concept, therefore the label name of each service 304 class remains the same on an end-to-end basis, even if we understand 305 that DiffServ is only a PHB and cannot guarantee anything, even 306 packet delivery at the intended destination node. That said, 307 several applications can be configured to have the same DSCP, or 308 each have different DSCPs that have the same treatment per hop 309 within a network. 311 Since RFC 4594 was first published, a new concept has been 312 introduced that will appear throughout this document, including DSCP 313 assignments -- the idea of "admitted" traffic, initially introduced 314 into DiffServ within RFC 5865 [RFC5865]. The VOICE-ADMIT Expedited 315 Forwarding class differentiates itself from the EF Expedited 316 Forwarding by having the packets marked be for admitted traffic. 317 This concept of "admitted" traffic is spread throughout the real 318 time traffic classes. 320 Thus, the document flow is as follows: 322 o maintain the general format of RFC 4594; 324 o augment the content with the concept of capacity-admission; 326 o incorporate much more video into this document, as it has become 327 a dominant application in enterprises and other managed networks, 328 as well as on the open public Internet; 330 o reduce the discussion on voice and its examples; 332 o articulate the subtle differences learned since RFC 4594 was 333 published. 335 The goal here is to provide a standard configuration for DiffServ 336 DSCP assignments and expected PHBs for enterprises and other managed 337 networks, as well as towards the public Internet with specific 338 traffic characteristics per Service class/DSCP, and example 339 applications shown for each. 341 This document describes service classes configured with DiffServ and 342 defines how they can be used and how to construct them using 343 Differentiated Services Code Points (DSCPs), and recommends how to 344 construct them using traffic conditioners, Per-Hop Behaviors (PHBs), 345 and Active Queue Management (AQM) mechanisms. There is no intrinsic 346 requirement that particular traffic conditioners, PHBs, and AQM be 347 used for a certain service class, but as a policy and for 348 interoperability it is useful to apply them consistently. This 349 document explicitly states there is a fundamental requirement that a 350 particular DSCP or DSCPs be used for each service class. 352 We differentiate services and their characteristics in Section 2. 353 Network control traffic, as well as user oriented traffic are 354 discussed in Sections 3 and 4, respectively. We analyze the security 355 considerations in Section 6. Section 7 offers a tribute to the 356 authors of RFC 4594, from which this document is based. It is in its 357 own section, and not part of the normal acknowledgements portion of 358 each IETF document. 360 1.1. Requirements Notation 362 The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL 363 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 364 in this document are to be interpreted as described in [RFC2119] 365 when they appear in ALL CAPS. These words may also appear in this 366 document in lower case as plain English words, absent their 367 normative meanings. 369 1.2. Expected Use in the Network 371 In the Internet today, corporate LANs and ISP WANs are increasingly 372 utilized, to the point in which network congestion is affecting 373 performance of applications. For this reason, congestion, loss, and 374 variation in delay within corporate LANs and ISP backbones is 375 becoming known to the users collectively as "the network is slow for 376 this application" or just "right now" or "for today". Users do not 377 directly detect network congestion. They react to applications that 378 run slow, or to downloads that take too long in their mind(s). The 379 explosion of video traffic on the internet recently has cause much 380 of this, and is often the application the user is using when they 381 have this slowness. 383 In the past, application slowness occurred for three very good 384 reasons. 386 o the networks the user oriented traffic traverses moves through 387 cycles of bandwidth boom and bandwidth bust, the latter of which 388 become apparent with the periodic deployment of new 389 bandwidth-hungry applications. 391 o In access networks, the state is often different. This may be 392 because throughput rates are artificially limited or 393 over-subscribed, or because of access network design trade-offs. 395 o Other characteristics, such as database design on web servers 396 (that may create contention points, e.g., in filestore) and 397 configuration of firewalls and routers, often look externally 398 like a bandwidth limitation. 400 The intent of this document is to provide a standardized marking, 401 plus a conditioning and packet treatment strategy so that it can be 402 configured and put into service on any link that is itself 403 congested. 405 1.3. Service Class Definition 407 A "service class" represents a similar set of traffic 408 characteristics for delay, loss, and jitter as packets traverse 409 routers in a network. For example, "High-Throughput Data" service 410 class for store-and-forward applications, or a "Broadcast" service 411 class for minimally time-shifted IPTV or Internet radio broadcasts. 412 Such a service class may be defined locally in a Differentiated 413 Services (DS) domain, or across multiple DS domains, possibly 414 extending end to end. A goal of this document is to have most/all 415 networks assign the same type of traffic the same for consistency. 417 A service class is a naming convention which is defined as a word, 418 phrase or initialism/acronym representing a set of necessary traffic 419 characteristics of a certain type of data flow. The necessary 420 characteristics of these traffic flows can be realized by the use of 421 defined per-hop behavior that started with [RFC2474]. The actual 422 specification of the expected treatment of a traffic aggregate 423 within a domain may also be defined as a per-domain behavior (PDB) 424 [RFC3086]. 426 Each domain will locally choose to 428 o implement one or more service classes with traffic 429 characteristics as defined here, or 431 o implement one or more service classes with similar traffic 432 characteristics as defined here, or 434 o implement one or more service classes with similar traffic 435 characteristics as defined here and to aggregate one or more 436 service classes to reduce the number of unique DSCPs within their 437 network, or 439 o implement one or more non-standard service classes with traffic 440 characteristics not as defined here, or 442 o not use DiffServ within their domain. 444 For example, low delay, low loss, and minimal jitter may be realized 445 using the EF PHB, or with an over-provisioned AF PHB. This must be 446 done with care as it may disrupt the end-to-end performance required 447 by the applications/services. If the packet sizes are similar within 448 an application, but different between two applications, say small 449 voice packets and large video packets, these two applications may 450 not realize optimum results if merged into the same aggregate if 451 there are any bottlenecks in the network. We provide for this 452 flexibility on a per hop or per domain basis within this document. 454 This document provides standardized markings for traffic with 455 similar characteristics, and usage expectations for PHBs for 456 specific service classes for their consistent implementation. 458 The Default Forwarding "Standard" service class is REQUIRED; all 459 other service classes are OPTIONAL. That said, each service class 460 lists traffic characteristics that are expected when using that type 461 of traffic. It is RECOMMENDED that applications and protocols that 462 fit a certain traffic characteristic use the appropriate service 463 class mark, i.e., the DSCP, for consistent behavior. It is expected 464 that network administrators will base their endpoint application and 465 router configuration choices on the level of service differentiation 466 they require to meet the needs of their customers (i.e., their 467 end-users). 469 1.4. Key Differentiated Services Concepts 471 In order to fully understand this document, a reader needs to 472 familiarize themselves with the principles of the Differentiated 473 Services Architecture [RFC2474]. We summarize some key concepts 474 here only to provide convenience for the reader, the referenced RFCs 475 providing the authoritative definitions. 477 1.4.1. Queuing 479 A queue is a data structure that holds packets that are awaiting 480 transmission. A router interface can only transmit one packet at a 481 time, however fast the interface speed is. If there is only 1 queue 482 at an interface, the packets are transmitted in the order they are 483 received into that queue - called FIFO, or "first in, first out". 484 Sometimes there is a lag in the time between a packets arrives in 485 the queue and when it is transmitted. This delay might be due to 486 lack of bandwidth, or if there are multiple queues on that 487 interface, because a packet is low in priority relative to other 488 packets that are awaiting to transmit. The scheduler is the system 489 entity that chooses which packet is next in line for transmission 490 when more than one packet are awaiting transmission out the same 491 router interface. 493 1.4.1.1 Priority Queuing 495 A priority queuing system is a combination of a set of queues and a 496 scheduler that empties the queues (of packets) in priority sequence. 497 When asked for a packet, the scheduler inspects the highest 498 priority queue and, if there is data present, returns a packet from 499 that queue. Failing that, it inspects the next highest priority 500 queue, and so on. A freeway onramp with a stoplight for one lane 501 that allows vehicles in the high-occupancy-vehicle lane to pass is 502 an example of a priority queuing system; the high-occupancy-vehicle 503 lane represents the "queue" having priority. 505 In a priority queuing system, a packet in the highest priority queue 506 will experience a readily calculated delay. This is proportional to 507 the amount of data remaining to be serialized when the packet 508 arrived plus the volume of the data already queued ahead of it in 509 the same queue. The technical reason for using a priority queue 510 relates exactly to this fact: it limits delay and variations in 511 delay and should be used for traffic that has that requirement. 513 A priority queue or queuing system needs to avoid starvation of 514 lower-priority queues. This may be achieved through a variety of 515 means, such as admission control, rate control, or network 516 engineering. 518 1.4.1.2. Rate Queuing 520 Similarly, a rate-based queuing system is a combination of a set of 521 queues and a scheduler that empties each at a specified rate. An 522 example of a rate-based queuing system is a road intersection with a 523 stoplight. The stoplight acts as a scheduler, giving each lane a 524 certain opportunity to pass traffic through the intersection. 526 In a rate-based queuing system, such as Weighted Fair Queuing (WFQ) 527 or Weighted Round Robin (WRR), the delay that a packet in any given 528 queue will experience depends on the parameters and occupancy of its 529 queue and the parameters and occupancy of the queues it is competing 530 with. A queue whose traffic arrival rate is much less than the rate 531 at which it lets traffic depart will tend to be empty, and packets 532 in it will experience nominal delays. A queue whose traffic arrival 533 rate approximates or exceeds its departure rate will tend not to be 534 empty, and packets in it will experience greater delay. Such a 535 scheduler can impose a minimum rate, a maximum rate, or both, on any 536 queue it touches. 538 1.4.2 Active Queue Management 540 Active Queue Management, or AQM, is a generic name for any of a 541 variety of procedures that use packet dropping or marking to manage 542 the depth of a queue. The canonical example of such a procedure is 543 Random Early Detection (RED), in that a queue is assigned a minimum 544 and maximum threshold, and the queuing algorithm maintains a moving 545 average of the queue depth. While the mean queue depth exceeds the 546 maximum threshold, all arriving traffic is dropped. While the mean 547 queue depth exceeds the minimum threshold but not the maximum 548 threshold, a randomly selected subset of arriving traffic is marked 549 or dropped. This marking or dropping of traffic is intended to 550 communicate with the sending system, causing its congestion 551 avoidance algorithms to kick in. As a result of this behavior, it 552 is reasonable to expect that TCP's cyclic behavior is desynchronized 553 and that the mean queue depth (and therefore delay) should normally 554 approximate the minimum threshold. 556 A variation of the algorithm is applied in Assured Forwarding PHB 557 [RFC2597], in that the behavior aggregate consists of traffic with 558 multiple DSCP marks, which are intermingled in a common queue. 559 Different minima and maxima are configured for the several DSCPs 560 separately, such that traffic that exceeds a stated rate at ingress 561 is more likely to be dropped or marked than traffic that is within 562 its contracted rate. 564 1.4.3 Traffic Conditioning 566 In addition, at the first router in a network that a packet crosses, 567 arriving traffic may be measured and dropped or marked according to 568 a policy, or perhaps shaped on network ingress, as in "A Rate 569 Adaptive Shaper for Differentiated Services" [RFC2963]. This may be 570 used to bias feedback loops, as is done in "Assured Forwarding PHB" 571 [RFC2597], or to limit the amount of traffic in a system, as is done 572 in "Expedited Forwarding PHB" [RFC3246]. Such measurement 573 procedures are collectively referred to as "traffic conditioners". 574 Traffic conditioners are normally built using token bucket meters, 575 for example with a committed rate and burst size, as in Section 576 1.5.3 of the DiffServ Model [RFC3290]. The Assured Forwarding PHB 577 [RFC2597] uses a variation on a meter with multiple rate and burst 578 size measurements to test and identify multiple levels of 579 conformance. 581 Multiple rates and burst sizes can be realized using multiple levels 582 of token buckets or more complex token buckets; these are 583 implementation details. The following are some traffic conditioners 584 that may be used in deployment of differentiated services: 586 o For Class Selector (CS) PHBs, a single token bucket meter to 587 provide a rate plus burst size control. 589 o For Expedited Forwarding (EF) PHB, a single token bucket meter to 590 provide a rate plus burst size control. 592 o For Assured Forwarding (AF) PHBs, usually two token bucket meters 593 configured to provide behavior as outlined in "Two Rate Three 594 Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color 595 Marker (srTCM)" [RFC2697]. The two-rate, three-color marker is 596 used to enforce two rates, whereas the single-rate, three-color 597 marker is used to enforce a committed rate with two burst 598 lengths. 600 1.4.4 Differentiated Services Code Point (DSCP) 602 The DSCP is a number in the range 0..63 that is placed into an IP 603 packet to mark it according to the class of traffic it belongs in. 604 These are divided into 3 groups, or pools, defined in RFC 2474, 605 arranged as follows: 607 o Pool-1 has 32 values designated for standards assignment (of the 608 form 'xxxxx0'). 610 o Pool-2 has 16 values designated for experimental or local use 611 only (EXP/LU) assignment (of the form 'xxxx11'). 613 o Pool-3 has 16 values designated for experimental or local use 614 (EXP/LU) assignment (of the form 'xxxx01'). 616 However, pool-3 is allowed to be assigned for one of two reasons, 618 #1 - if the values in pool-1 are exhausted, or 620 #2 - if there is a justifiable reason for assigning a pool-3 DSCP 621 prior to pool-1's exhaustion. 623 1.4.5 Per-Hop Behavior (PHB) 625 In the end, the mechanisms described above are combined to form a 626 specified set of characteristics for handling different kinds of 627 traffic, depending on the needs of the application. This document 628 seeks to identify useful traffic aggregates and to specify what PHB 629 should be applied to them. 631 1.5 Key Service Concepts 633 While Differentiated Services is a general architecture that may be 634 used to implement a variety of services, three fundamental 635 forwarding behaviors have been defined and characterized for general 636 use. These are basic Default Forwarding (DF) behavior for elastic 637 traffic, the Assured Forwarding (AF) behavior, and the Expedited 638 Forwarding (EF) behavior for real-time (inelastic) traffic. The 639 facts that four code points are recommended for AF and that one code 640 point is recommended for EF are arbitrary choices, and the 641 architecture allows any reasonable number of AF and EF classes 642 simultaneously. The choice of four AF classes and one EF class in 643 the current document is also arbitrary, and operators MAY choose to 644 operate more or fewer of either. 646 The terms "elastic" and "real-time" are defined in [RFC1633], 647 Section 3.1, as a way of understanding broad-brush application 648 requirements. This document should be reviewed to obtain a broad 649 understanding of the issues in quality of service, just as [RFC2475] 650 should be reviewed to understand the data plane architecture used in 651 today's Internet. 653 1.5.1 Default Forwarding (DF) 655 The basic forwarding behaviors applied to any class of traffic are 656 those described in [RFC2474] and [RFC2309]. Best-effort service may 657 be summarized as "I will accept your packets" and is typically 658 configured with some bandwidth guarantee. Packets in transit may be 659 lost, reordered, duplicated, or delayed at random. Generally, 660 networks are engineered to limit this behavior, but changing traffic 661 loads can push any network into such a state. 663 Application traffic in the internet that uses default forwarding is 664 expected to be "elastic" in nature. By this, we mean that the 665 sender of traffic will adjust its transmission rate in response to 666 changes in available rate, loss, or delay. 668 For the basic best-effort service, a single DSCP value is provided 669 to identify the traffic, a queue to store it, and active queue 670 management to protect the network from it and to limit delays. 672 1.5.2 Assured Forwarding (AF) 674 The Assured Forwarding PHB [RFC2597] behavior is explicitly modeled 675 on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss 676 Priority (CLP) capability. It is intended for networks that offer 677 average-rate Service Level Agreements (SLAs) (as FR and ATM networks 678 do). This is an enhanced best-effort service; traffic is expected 679 to be "elastic" in nature. The receiver will detect loss or 680 variation in delay in the network and provide feedback such that the 681 sender adjusts its transmission rate to approximate available 682 capacity. 684 For such behaviors, multiple DSCP values are provided (two or three, 685 perhaps more using local values) to identify the traffic, a common 686 queue to store the aggregate, and active queue management to protect 687 the network from it and to limit delays. Traffic is metered as it 688 enters the network, and traffic is variously marked depending on the 689 arrival rate of the aggregate. The premise is that it is normal for 690 users occasionally to use more capacity than their contract 691 stipulates, perhaps up to some bound. However, if traffic should be 692 marked or lost to manage the queue, this excess traffic will be 693 marked or lost first. 695 1.5.3. Expedited Forwarding (EF) 697 The intent of Expedited Forwarding PHB [RFC3246] is to provide a 698 building block for low-loss, low-delay, and low-jitter services. It 699 can be used to build an enhanced best-effort service: traffic 700 remains subject to loss due to line errors and reordering during 701 routing changes. However, using queuing techniques, the probability 702 of delay or variation in delay is minimized. For this reason, it is 703 generally used to carry voice and for transport of data information 704 that requires "wire like" behavior through the IP network. Voice is 705 an inelastic "real-time" application that sends packets at the rate 706 the codec produces them, regardless of availability of capacity. As 707 such, this service has the potential to disrupt or congest a network 708 if not controlled. It also has the potential for abuse. 710 To protect the network, at minimum one SHOULD police traffic at 711 various points to ensure that the design of a queue is not overrun, 712 and then the traffic SHOULD be given a low-delay queue (often using 713 priority, although it is asserted that a rate-based queue can do 714 this) to ensure that variation in delay is not an issue, to meet 715 application needs. 717 1.5.4 Class Selector (CS) 719 Class Selector, those DSCPs that end in zeros (xxx000), provide 720 support for historical codepoint definitions and PHB requirement. 721 The CS fields provide a limited backward compatibility with legacy 722 practice, as described in [RFC2474], Section 4. Backward 723 compatibility is addressed in two ways, 725 - First, there are per-hop behaviors that are already in widespread 726 use (e.g., those satisfying the IPv4 Precedence queuing 727 requirements specified in [RFC1812]), and 729 - this document will continue to permit their use in DS-compliant 730 networks. 732 In addition, there are some DSCPs that correspond to historical use 733 of the IP Precedence field, 735 - CS0 (000000) will remain 'Default Forwarding' (also know as 'Best 736 Effort') 738 - 11xxxx will remain for routing traffic 740 and will map to PHBs that meet the general requirements specified in 741 [RFC2474], Section 4.2.2.2. 743 No attempt is made to maintain backward compatibility with the "DTR" 744 or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in 745 [RFC0791] and [RFC1349]. 747 A DS-compliant network can be deployed exclusively by using one or 748 more CS-compliant PHB groups. Thus, for example, codepoint '011000' 749 would map to the same PHB as codepoint '011010'. 751 1.5.5 Admission Control 753 Admission control (including refusal when policy thresholds are 754 crossed) can ensure high-quality communication by ensuring the 755 availability of bandwidth to carry a load. Inelastic real-time 756 flows such as Voice over Internet Protocol (VoIP) (audio) or video 757 conferencing services can benefit from use of an admission control 758 mechanism, as generally the audio or video service is configured 759 with over-subscription, meaning that some users may not be able to 760 make a call during peak periods. 762 For VoIP (audio) service, a common approach is to use signaling 763 protocols such as SIP, H.323, H.248, MEGACO, along with Resource 764 Reservation Protocol (RSVP) to negotiate admittance and use of 765 network transport capabilities. When a user has been authorized to 766 send voice traffic, this admission procedure has verified that data 767 rates will be within the capacity of the network that it will use. 769 Many RTP voice and video payloads are inelastic and cannot react to 770 loss or delay in any substantive way. For these payload types, the 771 network needs to police at ingress to ensure that the voice traffic 772 stays within its negotiated bounds. Having thus assured a 773 predictable input rate, the network may use a priority queue to 774 ensure nominal delay and variation in delay. 776 1.5.5.1 Capacity Admitted (*-Admit) 778 This is a newer group of traffic types that started with RFC 5865 779 and the Voice-Admit service type. Voice-Admit is an EF class marking 780 but has capacity-admission always applied to it to ensure each of 781 these flows are managed through a network, though not necessarily on 782 an end-to-end basis. This depends on how many networks each flow 783 transits and the load on each transited network. There are a series 784 of new DSCPs proposed in [ID-DSCP], each specifying unique 785 characteristics necessitating a separate marking from what existing 786 before that document. 788 This document will import in four new '*-Admit' DSCPs from 789 [ID-DSCP], 2 others that are new but not capacity-admitted, one from 790 RFC 5865, and change the existing usage of 2 DSCPs from RFC 4594. 791 This is discussed throughout the rest of this document. 793 2. Service Differentiation 795 There are practical limits on the level of service differentiation 796 that should be offered in the IP networks. We believe we have 797 defined a practical approach in delivering service differentiation 798 by defining different service classes that networks may choose to 799 support in order to provide the appropriate level of behaviors and 800 performance needed by current and future applications and services. 801 The defined structure for providing services allows several 802 applications having similar traffic characteristics and performance 803 requirements to be grouped into the same service class. This 804 approach provides a lot of flexibility in providing the appropriate 805 level of service differentiation for current and new, yet unknown 806 applications without introducing significant changes to routers or 807 network configurations when a new traffic type is added to the 808 network. 810 2.1 Service Classes 812 Traffic flowing in a network can be classified in many different 813 ways. We have chosen to divide it into two groupings, network 814 control and user/subscriber traffic. To provide service 815 differentiation, different service classes are defined in each 816 grouping. The network control traffic group can further be divided 817 into two service classes (see Section 3 for detailed definition of 818 each service class): 820 o "Network Control" for routing and network control function. 822 o "OAM" (Operations, Administration, and Management) for network 823 configuration and management functions. 825 The user/subscriber traffic group is broken down into ten service 826 classes to provide service differentiation for all the different 827 types of applications/services (see Section 4 for detailed 828 definition of each service class): 830 o Conversational service group consists of three service classes: 832 - Audio, which includes both 'admitted' and 'unadmitted' audio 833 service classes, is for non-one way (i.e., generally 834 bidirectional) audio media packets between human users of 835 smaller size and at a constant delivery rate. 837 - Hi-Res Video, which includes both 'admitted' and 'unadmitted' 838 Hi-Res Video service classes, is for video traffic from higher 839 end endpoints between human users necessitating different 840 treatment that from desktop or video phone endpoints. This has 841 a clearly business differentiation, and not a technical 842 differentiation - as both Hi-Res-Video and Video will be 843 treated similarly on the wire when no congestion occurs. 845 - Video, which includes both 'admitted' and 'unadmitted' video 846 service classes, is for video traffic from lower end endpoints 847 between human users necessitating different treatment that 848 from higher end (i.e., Telepresence) endpoints. This has a 849 clearly business differentiation, and not a technical 850 differentiation - as both Hi-Res-Video and Video will be 851 treated similarly on the wire when no congestion occurs. 853 o Conversational Signaling service class is for peer-to-peer and 854 client-server signaling and control functions using protocols 855 such as SIP, H.323, H.248, and Media Gateway Control Protocol 856 (MGCP). This traffic needs to not be starved on the network. 858 Editor's note: RFC 4594 had this DSCP marking as CS5, but with 859 clearly different characteristics (i.e., no 860 sensitivity to jitter or (unreasonable) delay), this 861 DSCP has been moved to a more appropriate (new) 862 value, defined in [ID-DSCP]. 864 o Real-Time Interactive, which includes both 'admitted' and 865 'unadmitted' Realtime-Interactive service class, is for 866 bidirectional variable rate inelastic applications that require 867 low jitter and loss and very low delay, such as interactive 868 gaming applications that use RTP/UDP streams for game control 869 commands, and Virtualized Desktop applications between the user 870 and content source, typically in a centralized data center. 872 o Multimedia Conferencing, which includes both 'admitted' and 873 'unadmitted' multimedia conferencing service class, is for 874 applications that require minimal delay, but not like those of 875 realtime application requirements. This service class can be 876 bursty in nature, as well as not transmit packets for some time. 877 Applications such as presentation data or collaborative 878 application sharing will use this service class. 880 o Multimedia Streaming, which includes both 'admitted' and 881 'unadmitted' multimedia streaming service class, is for one-way 882 bufferable streaming media applications such as Video on Demand 883 (VOD) and webcasts. 885 o Broadcast, which includes both 'admitted' and 'unadmitted' 886 broadcast service class, is for inelastic streaming media 887 applications that may be of constant or variable rate, requiring 888 low jitter and very low packet loss, such as broadcast TV and 889 live events, video surveillance, and security. 891 o Low-Latency Data service class is for data processing 892 applications such as client/server interactions or Instant 893 Messaging (IM) and Presence data. 895 o Conversational Signaling (A/V-Sig) service class is for all 896 signaling messages, whether in-band (i.e., along the data path) 897 or out-of-band (separate from the data path), for the purposes of 898 setting up, maintaining, managing and terminating bi- or 899 multi-directional realtime sessions. 901 o High-Throughput Data service class is for store and forward 902 applications such as FTP and billing record transfer. 904 o Standard service class, commonly called best effort (BE), is for 905 traffic that has not been identified as requiring differentiated 906 treatment. 908 o Low-Priority Data service class, which some could call the 909 scavenger class, is for packet flows where bandwidth assurance is 910 not required. 912 2.2 Categorization of User Oriented Service Classes 914 The ten defined user/subscriber service classes listed above can be 915 grouped into a small number of application categories. For some 916 application categories, it was felt that more than one service class 917 was needed to provide service differentiation within that category 918 due to the different traffic characteristic of the applications, 919 control function, and the required flow behavior. Figure 1 provides 920 a summary of service class grouping into four application categories. 922 Application Control Category 924 o The Conversational Signaling service class is intended to be used 925 to control applications or user endpoints. Examples of protocols 926 that would use this service class are SIP, XMPP or H.323 for 927 voice and/or video over IP services. User signaling flows have 928 similar performance requirements as Low-Latency Data, they 929 require a separate DSCP to be distinguished other traffic and 930 allow for a treatment that is unique. 932 Media-Oriented Category 934 Due to the vast number of new (in process of being deployed) and 935 already-in-use media-oriented services in IP networks, seven service 936 classes have been defined. 938 o Audio service class is intended for Voice-over-IP (VoIP) 939 services. It may also be used for other applications that meet 940 the defined traffic characteristics and performance requirements. 942 o Video service class is intended for Video over IP services. It 943 may also be used for other applications that meet the defined 944 traffic characteristics and performance requirements. 946 o Hi-Res service class is intended for higher end video services 947 that have the same traffic characteristics as the video service 948 class, but have a business requirement(s) to be treated 949 differently. One example of this is Telepresence video 950 applications. 952 o Realtime-Interactive service class is intended for inelastic 953 applications such as desktop virtualization applications and for 954 interactive gaming. 956 o Multimedia Conferencing service class is for everything about or 957 within video conferencing solutions that does not include the 958 voice or (human) video components. Several examples are 960 - the presentation data part of an IP conference (call). 962 - the application sharing part of an IP conference (call). 964 - the whiteboarding aspect of an IP conference (call). 966 Each of the above can be part of a lower end web-conferencing 967 application or part of a higher end Telepresence video 968 conference. Each also has the ability to reduce their 969 transmission rate on detection of congestion. These flows can 970 therefore be classified as rate adaptive and most often more 971 elastic than their voice and video counterparts. 973 o Broadcast Video service class is to be used for inelastic traffic 974 flows specifically with minimal buffering expected by the source 975 or destination, which are intended for broadcast HDTV service, as 976 well as for transport of live video (sports or concerts) and 977 audio events. 979 o Multimedia Streaming service class is to be used for elastic 980 multimedia traffic flows where buffering is expected. This is 981 the fundamental difference between the Broadcast and multimedia 982 streaming service classes. Multimedia streaming content is 983 typically stored before being transmitted. It is also buffered 984 at the receiving end before being played out. The buffering is 985 sufficiently large to accommodate any variation in transmission 986 rate that is encountered in the network. Multimedia 987 entertainment over IP delivery services that are being developed 988 can generate both elastic and inelastic traffic flows; therefore, 989 two service classes are defined to address this space, 990 respectively: Multimedia Streaming and Broadcast Video. 992 Data Category 994 The data category is divided into three service classes. 996 o Low-Latency Data for applications/services that require low delay 997 or latency for bursty but short-lived flows. 999 o High-Throughput Data for applications/services that require good 1000 throughput for long-lived bursty flows. High Throughput and 1001 Multimedia Steaming are close in their traffic flow 1002 characteristics with High Throughput being a bit more bursty and 1003 not as long-lived as Multimedia Streaming. 1005 o Low-Priority Data for applications or services that can tolerate 1006 short or long interruptions of packet flows. The Low-Priority 1007 Data service class can be viewed as "don't care" to some degree. 1009 Best-Effort Category 1011 o All traffic that is not differentiated in the network falls into 1012 this category and is mapped into the Standard service class. If 1013 a packet is marked with a DSCP value that is not supported in the 1014 network, it SHOULD be forwarded using the Standard service class. 1016 Figure 1, below, provides a grouping of the defined user/subscriber 1017 service classes into four categories, with indications of which ones 1018 use an independent flow for signaling or control; type of flow 1019 behavior (elastic, rate adaptive, or inelastic); and the last column 1020 provides end user Class of Service (CoS) rating as defined in ITU-T 1021 Recommendation G.1010. 1023 ----------------------------------------------------------------- 1024 | Application | Service | Signaled | Flow | G.1010 | 1025 | Categories | Class | | Behavior | Rating | 1026 |-------------+---------------+----------+-----------+------------| 1027 | Application | A/V Sig | Not | Inelastic | Responsive | 1028 | Control | |applicable| | | 1029 |-------------+---------------+----------+-----------+------------| 1030 | | Realtime | Yes | Inelastic | Interactive| 1031 | | Interactive | | | | 1032 | |---------------+----------+-----------+------------| 1033 | | Audio | Yes | Inelastic | Interactive| 1034 | |---------------+----------+-----------+------------| 1035 | | Video | Yes | Inelastic | Interactive| 1036 | |---------------+----------+-----------+------------| 1037 | | Hi-Res | Yes | Inelastic | Interactive| 1038 | |---------------+----------+-----------+------------| 1039 | Media- | Multimedia | Yes | Rate | Moderately | 1040 | Oriented | Conferencing| | Adaptive | Interactive| 1041 | |---------------+----------+-----------+------------| 1042 | | Broadcast | Yes | Inelastic | Responsive | 1043 | |---------------+----------+-----------+------------| 1044 | | Multimedia | Yes | Elastic | Timely | 1045 | | Streaming | | | | 1046 |-------------+---------------+----------+-----------+------------| 1047 | | Low-Latency | No | Elastic | Responsive | 1048 | | Data | | | | 1049 | |---------------+----------+-----------+------------| 1050 | Data | Conversational| No |Elastic or | Timely | 1051 | | Signaling | | Inelastic | | 1052 | |---------------+----------+-----------+------------| 1053 High- | No | Elastic | Timely | 1054 | |Throughput Data| | | | 1055 | |---------------+----------+-----------+------------| 1056 | | Low- | No | Elastic |Non-critical| 1057 | | Priority Data | | | | 1058 |-------------+---------------+----------+-----------+------------| 1059 | Best Effort | Standard | Not Specified |Non-critical| 1060 ----------------------------------------------------------------- 1062 Figure 1. User/Subscriber Service Classes Grouping 1064 Here is a short explanation of the end user CoS category as defined 1065 in ITU-T Recommendation G.1010. User oriented traffic is divided 1066 into four different categories, namely, interactive, responsive, 1067 timely, and non-critical. An example of interactive traffic is 1068 between two humans and is most sensitive to delay, loss, and jitter. 1069 Another example of interactive traffic is between two servers where 1070 very low delay and loss are needed. Responsive traffic is typically 1071 between a human and a server but can also be between two servers. 1072 Responsive traffic is less affected by jitter and can tolerate 1073 longer delays than interactive traffic. Timely traffic is either 1074 between servers or servers and humans and the delay tolerance is 1075 significantly longer than responsive traffic. Non-critical traffic 1076 is normally between servers/machines where delivery may be delay for 1077 period of time. 1079 2.3. Service Class Characteristics 1081 This document specifies what network administrators are to expect 1082 when configuring service classes identified by their differing 1083 characteristics. Figure 2 identifies these service classes along 1084 with their characteristics, as well as the tolerance to loss, delay 1085 and jitter for each service class. Properly engineered networks to 1086 these PHBs will achieve expected results. That said, not all of the 1087 identified service classes are expected in each operator's network. 1089 ------------------------------------------------------------------- 1090 |Service Class | | Tolerance to | 1091 | Name | Traffic Characteristics | Loss |Delay |Jitter| 1092 |===============+==============================+======+======+======| 1093 | Network |Variable size packets, mostly | | | | 1094 | Control |inelastic short messages, but | Low | Low | Yes | 1095 | |traffic can also burst (BGP) | | | | 1096 |---------------+------------------------------+------+------+------| 1097 | Realtime | Inelastic, mostly variable | Low | Very | Low | 1098 | Interactive | rate | | Low | | 1099 +---------------+------------------------------+------+------+------+ 1100 | | Fixed-size small packets, | Very | Very | Very | 1101 | Audio | inelastic | Low | Low | Low | 1102 | | | | | | 1103 +---------------+------------------------------+------+------+------+ 1104 | | Fixed-size small-large | Very | Very | Very | 1105 | Video | packets, inelastic | Low | Low | Low | 1106 | | | | | | 1107 +---------------+------------------------------+------+------+------+ 1108 | | Fixed-size small-large | Very | Very | Very | 1109 | Hi-Res A/V | packets, inelastic | Low | Low | Low | 1110 | | | | | | 1111 +---------------+------------------------------+------+------+------+ 1112 | Multimedia | Variable size packets, | Low | Low | Low | 1113 | Conferencing | constant transmit interval, | - | - | - | 1114 | | rate adaptive, reacts to loss|Medium|Medium|Medium| 1115 +---------------+------------------------------+------+------+------+ 1116 | Multimedia | Variable size packets, |Low - |Medium| High | 1117 | Streaming | elastic with variable rate |Medium| | | 1118 +---------------+------------------------------+------+------+------+ 1119 | Broadcast | Constant and variable rate, | Very |Medium| Low | 1120 | | inelastic, non-bursty flows | Low | | | 1121 +---------------+------------------------------+------+------+------+ 1122 | Low-Latency | Variable rate, bursty short- | Low |Low - | Yes | 1123 | Data | lived elastic flows | |Medium| | 1124 |---------------+------------------------------+------+------+------| 1125 |Conversational | Variable size packets, some | Low | Low | Yes | 1126 | Signaling | what bursty short-lived flows| | | | 1127 |---------------+------------------------------+------+------+------| 1128 | OAM | Variable size packets, | Low |Medium| Yes | 1129 | | elastic & inelastic flows | | | | 1130 |---------------+------------------------------+------+------+------| 1131 | High- | Variable rate, bursty long- | Low |Medium| Yes | 1132 |Throughput Data| lived elastic flows | |- High| | 1133 |---------------+------------------------------+------+------+------| 1134 | Standard | A bit of everything | Not Specified | 1135 |---------------+------------------------------+------+------+------| 1136 | Low-Priority | Non-real-time and elastic | High | High | Yes | 1137 | Data | | | | | 1138 ------------------------------------------------------------------- 1140 Figure 2. Service Class Characteristics 1142 Notes for Figure 2: A "Yes" in the jitter-tolerant column implies 1143 that received data is buffered at the endpoint and that a moderate 1144 level of server or network-induced variation in delay is not 1145 expected to affect the application. Applications that use TCP or 1146 SCTP as a transport are generally good examples. Routing protocols 1147 and peer-to-peer signaling also fall in this class; although loss 1148 can create problems in setting up calls, a moderate level of jitter 1149 merely makes call placement a little less predictable in duration. 1151 Service classes indicate the required traffic forwarding treatment 1152 in order to meet user, application, and/or network expectations. 1153 Section 3 defines the service classes that MAY be used for 1154 forwarding network control traffic, and Section 4 defines the 1155 service classes that MAY be used for forwarding user oriented 1156 traffic with examples of intended application types mapped into each 1157 service class. Note that the application types are only examples 1158 and are not meant to be all-inclusive or prescriptive. Also, note 1159 that the service class naming or ordering does not imply any 1160 priority ordering. They are simply reference names that are used in 1161 this document with associated QoS behaviors that are optimized for 1162 the particular application types they support. Network 1163 administrators MAY choose to assign different service class names to 1164 the service classes that they will support. Figure 3 defines the 1165 RECOMMENDED relationship between service classes and DS codepoint 1166 assignment with application examples. It is RECOMMENDED that this 1167 relationship be preserved end to end. 1169 +------------------------------------------------------------------+ 1170 | Service | DSCP | DSCP | Application | 1171 | Class Name | Name | Value | Examples | 1172 |===============+=========+=============+==========================| 1173 |Network Control| CS6&CS7 | 11xxxx | Network routing | 1174 |---------------+---------+-------------+--------------------------| 1175 | Realtime | CS5, | 101000, | Remote/Virtual Desktop | 1176 | Interactive |CS5-Admit| 101001 | and Interactive gaming | 1177 |---------------+---------+-------------+--------------------------| 1178 | Audio | EF | 101110 | Voice bearer | 1179 | |Voice-Admit| 101100 | | 1180 |---------------+---------+-------------+--------------------------| 1181 | Hi-Res A/V | CS4, | 100000, | Conversational Hi-Res | 1182 | |CS4-Admit| 100001 | Audio/Video bearer | 1183 |---------------+---------+-------------+--------------------------| 1184 | Video |AF41,AF42|100010,100100| Audio/Video conferencing | 1185 | | AF43 | 100110 | bearer | 1186 |---------------+---------+-------------+--------------------------| 1187 | Multimedia | MC, | 011101, | Presentation Data and | 1188 | Conferencing | MC-Admit| 100101 | App Sharing/Whiteboarding| 1189 |---------------+---------+-------------+--------------------------| 1190 | Multimedia |AF31,AF32|011010,011100| Streaming video and | 1191 | Streaming | AF33 | 011110 | audio on demand | 1192 |---------------+---------+-------------+--------------------------| 1193 | Broadcast | CS3, | 011000, | Broadcast TV, live events| 1194 | |CS3-Admit| 011001 | & video surveillance | 1195 |---------------+---------+-------------+--------------------------| 1196 | Low-Latency |AF21,AF22|010010,010100|Client/server trans., Web-| 1197 | Data | AF23 | 010110 |based ordering, IM/Pres | 1198 |---------------+---------+-------------+--------------------------| 1199 |Conversational | A/V-Sig | 010001 | Conversational signaling | 1200 | Signaling | | | | 1201 |---------------+---------+-------------+--------------------------| 1202 | OAM | CS2 | 010000 | OAM&P | 1203 |---------------+---------+-------------+--------------------------| 1204 |High-Throughput|AF11,AF12|001010,001100| Store and forward | 1205 | Data | AF13 | 001110 | applications | 1206 |---------------+---------+-------------+--------------------------| 1207 | Low-Priority | CS1 | 001000 | Any flow that has no BW | 1208 | Data | | | assurance | 1209 |------------------------------------------------------------------| 1210 | Best Effort | CS0 | 000000 | Undifferentiated | 1211 | | | | applications | 1212 +---------------+---------+-------------+--------------------------+ 1214 Figure 3. DSCP to Service Class Mapping 1216 Notes for Figure 3: 1218 o Default Forwarding (DF) and Class Selector 0 (CS0) (i.e., Best 1219 Effort) provide equivalent behavior and use the same DS 1220 codepoint, '000000'. 1222 o RFC 2474 identifies any DSCP with a value of 11xxxx to be for 1223 network control. This remains true, while it removes 12 DSCPs 1224 from the overall pool of 64 available DSCP values (the 4 that are 1225 x11 from this group are within pool 2 of RFC 2474, and remain as 1226 only experimentally assignable/useable). 1228 o All PHB names that say "-Admit" are to be used only when a 1229 capacity-admission protocol is utilized for that or each traffic 1230 flow. 1232 Changes from table 3 of RFC 4594 are as follows: 1234 o The old term "Signaling" was using CS5 (101000), now is 1235 exclusively for the "Conversational Signaling" service group 1236 using the DSCP name of "A/V-Sig" (010001), which is newly defined 1237 in [ID-DSCP]. This is because CS5 aggregates into the 101xxx 1238 aggregate when using layer 2 technologies such as 802.3 Ethernet, 1239 802.11 Wireless Ethernet MPLS, etc - each of which only have 3 1240 bits to mark with. A traffic type that can have very large 1241 packets and is not delay sensitive (within reason) is not 1242 appropriate for have a 101xxx marking. A REQUIRED behavior for 1243 this PHB is that it not be starved in any node. 1245 o "Conversational" is a new term to include all interactive audio 1246 and video. The Conversational service group consists of the audio 1247 service class, the video service class and the new Hi-Res service 1248 class. 1250 o "Audio" obsoletes the term "Telephony", which has generally not 1251 retained the "video" aspect within the IETF, where video is still 1252 commonly called out as a separate thing. Audio retains the 1253 nonadmitted traffic PHB of EF (101110), while capacity-admitted 1254 audio has been added via the RFC 5865 defined PHB Voice-Admit. 1256 o "Video" now is AF4x, with AF41 specifically for capacity-admitted 1257 video traffic, while AF42 and AF43 are nonadmitted video traffic. 1259 o "Hi-Res A/V", part of the Conversational service group, is 1260 created by [ID-DSCP] for an additional business differentiation 1261 interactive video marking for higher end traffic. It is within 1262 the 100xxx as CS4 (for nonadmitted traffic) and CS4-Admit 1263 (100001) (for capacity-admitted traffic). 1265 o "Realtime Interactive" is now using CS5 (for nonadmitted 1266 traffic), but adds a capacity-admitted DSCP CS5-Admit (101001). 1268 o "Multimedia Conferencing" is no longer using the AF4x DSCPs, 1269 rather it will use the new PHB MC (100101) (for 1270 capacity-admitted) and MC-Admit (011101) (for nonadmitted 1271 traffic). 1273 o "Multimedia Streaming" retains using AF3x, however, AF31 is now 1274 used for capacity-admitted traffic, while AF32/33 are 1275 nonadmitted. 1277 o "Broadcast" replaces "Broadcast Video" using CS3 (for nonadmitted 1278 traffic), and adds a capacity-admitted PHB CS3-Admit (011001). 1280 It is expected that network administrators will base their choice of 1281 the service classes that they will support on their need. 1283 Figure 4 provides a summary of DiffServ CoS mechanisms that MUST be 1284 used for the defined service classes that are further detailed in 1285 Sections 3 and 4 of this document. According to what 1286 applications/services need to be differentiated, network 1287 administrators MAY choose the service class(es) that need to be 1288 supported in their network. 1290 +-----------------------------------------------------------------+ 1291 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| 1292 | Class | | DS Edge | Used | | | 1293 |===============+=======+===================+=======+========+====| 1294 |Network Control|CS6/CS7| See Section 3.1 |RFC2474| Rate | Yes| 1295 |---------------+-------+-------------------+-------+--------+----| 1296 | Realtime | CS5, |Police using sr+bs |RFC2474| Rate | No | 1297 | Interactive | CS5- | | | | | 1298 | | Admit*| |[ID-DSCP]| | | 1299 |---------------+-------+-------------------+-------+--------+----| 1300 | | EF, |Police using sr+bs |RFC3246|Priority| No | 1301 | Audio |Voice- | | | | | 1302 | | Admit*| |RFC5865| | | 1303 |---------------+-------+-------------------+-------+--------+----| 1304 | | CS4, |Police using sr+bs |RFC2474|Priority| No | 1305 | Hi-Res A/V | CS4- | | | | | 1306 | | Admit*| |[ID-DSCP]| | | 1307 |---------------+-------+-------------------+-------+--------+----| 1308 | | AF41*,| Using two-rate, | | | Yes| 1309 | Video | AF42 |three-color marker |RFC2597| Rate | per| 1310 | | AF43 | (such as RFC 2698)| | |DSCP| 1311 |---------------+-------+-------------------+-------+--------+----| 1312 | Multimedia | MC, |Police using sr+bs|[ID-DSCP]| Rate | No | 1313 | Conferencing | MC- | | | | | 1314 | | Admit*| |[ID-DSCP]| | | 1315 |---------------+-------+-------------------+-------+--------+----| 1316 | Multimedia | AF31*,| Using two-rate, | | | Yes| 1317 | Streaming | AF32 |three-color marker |RFC2597| Rate | per| 1318 | | AF33 | (such as RFC 2698)| | |DSCP| 1319 |---------------+-------+-------------------+-------+--------+----| 1320 | Broadcast | CS3, |Police using sr+bs |RFC2474| Rate | No | 1321 | | CS3- | | | | | 1322 | | Admit*| |[ID-DSCP]| | | 1323 |---------------+-------+-------------------+-------+--------+----| 1324 | Low- | AF21 | Using single-rate,| | | Yes| 1325 | Latency | AF22 |three-color marker |RFC2597| Rate | per| 1326 | Data | AF23 | (such as RFC 2697)| | |DSCP| 1327 |---------------+-------+-------------------+-------+--------+----| 1328 |Conversational |AV-Sig |Police using sr+bs|[ID-DSCP]| Rate | No | 1329 | Signaling | | | | | | 1330 |---------------+-------+-------------------+-------+--------+----| 1331 | OAM | CS2 |Police using sr+bs |RFC2474| Rate | Yes| 1332 |---------------+-------+-------------------+-------+--------+----| 1333 | High- | AF11 | Using two-rate, | | | Yes| 1334 | Throughput | AF12 |three-color marker |RFC2597| Rate | per| 1335 | Data | AF13 | (such as RFC 2698)| | |DSCP| 1336 |---------------+-------+-------------------+-------+--------+----| 1337 | Standard | DF | Not applicable |RFC2474| Rate | Yes| 1338 |---------------+-------+-------------------+-------+--------+----| 1339 | Low-Priority | CS1 | Not applicable |RFC3662| Rate | Yes| 1340 | Data | | | | | | 1341 |---------------+-------+-------------------+-------+--------+----| 1343 Figure 4. Summary of CoS Mechanisms Used for Each Service Class 1345 * denotes each DSCP identified for capacity-admission traffic only. 1347 Notes for Figure 4: 1349 o Conditioning at DS edge means that traffic conditioning is 1350 performed at the edge of the DiffServ network where untrusted 1351 user devices are connected to two different administrative 1352 DiffServ networks. 1354 o "sr+bs" represents a policing mechanism that provides single rate 1355 with burst size control. 1357 o The single-rate, three-color marker (srTCM) behavior SHOULD be 1358 equivalent to RFC 2697, and the two-rate, three-color marker 1359 (trTCM) behavior SHOULD be equivalent to RFC 2698. 1361 o The PHB for Realtime-Interactive service class SHOULD be 1362 configured to provide high bandwidth assurance. It MAY be 1363 configured as another EF PHB (one capacity-admitted and one 1364 non-capacity-admitted, if both are to be used) that uses relaxed 1365 performance parameters and a rate scheduler. 1367 o The PHB for Multimedia Conferencing service class SHOULD be 1368 configured to provide high bandwidth assurance. It MAY be 1369 configured as another EF PHB (one capacity-admitted and one 1370 non-capacity-admitted, if both are to be used) that uses relaxed 1371 performance parameters and a rate scheduler. 1373 o The PHB for Broadcast service class SHOULD be configured to 1374 provide high bandwidth assurance. It MAY be configured as 1375 another EF PHB (one capacity-admitted and one 1376 non-capacity-admitted, if both are to be used) that uses relaxed 1377 performance parameters and a rate scheduler. 1379 2.4. Service Classes vs. Treatment Aggregates (from RFC 5127) 1381 There are misconceptions about the differences between RFC 4594 1382 specified service classes, and RFC 5127 specified treatment 1383 aggregates. Often the two are conflated, and more often the phrase 1384 service class is used to mean both definitions. Almost all of the 1385 text previous to this section is used in defining service classes, 1386 and how one service class is different than another service class 1387 (based on traffic characteristics of the applications). Treatment 1388 aggregates are groupings of service classes with similar, but not 1389 identical, traffic characteristics to give similar treatment from a 1390 SP's network. 1392 Below is taken from appendix of RFC 5127 as its recommended 1393 groupings of service classes into aggregates based in RFC 4594 1394 specified traffic characteristic expectations. 1396 +------------------------------------------------------------+ 1397 |Treatment |Treatment || DSCP | 1398 |Aggregate |Aggregate || | 1399 | |Behavior || | 1400 |==========+==========++=====================================| 1401 | Network | CS || CS6 | 1402 | Control |(RFC 2474)|| | 1403 |==========+==========++=====================================| 1404 | Real- | EF || EF, CS5, AF41, AF42, AF43, CS4, CS3 | 1405 | Time* |(RFC 3246)|| | 1406 |==========+==========++=====================================| 1407 | Assured | AF || CS2, AF31, AF21, AF11 | 1408 | Elastic |(RFC 2597)||-------------------------------------| 1409 | | || AF32, AF22, AF12 | 1410 | | ||-------------------------------------| 1411 | | || AF33, AF23, AF13 | 1412 |==========+==========++=====================================| 1413 | Elastic | Default || Default, (CS0) | 1414 | |(RFC 2474)||-------------------------------------| 1415 | | || CS1 | 1416 +------------------------------------------------------------+ 1418 Figure 5: RFC 5127 Defined Treatment Aggregate Behavior** 1420 *NOTE: The RFC 5865 created VOICE-ADMIT is absence from the above 1421 figure because VOICE-ADMIT was created far later than this 1422 recommendation was. VOICE-ADMIT is appropriate for the 1423 Realtime Traffic Aggregate. 1425 **NOTE: Figure 5 is directly from the appendix of RFC 5127 as that 1426 RFC's recommendation for configuration. This draft does not 1427 directly affect RFC 5127. That is left for an update to RFC 1428 5127 itself. Based on the WG's take on this draft, RFC 5127 1429 will necessitate an update to match this document's new 1430 service classes and additional DSCPs. The number of treatment 1431 aggregates are not expected to change in the RFC 5127 Update 1432 draft though, with the possible exception of a new treatment 1433 aggregate for capacity admitted flows; meaning there *might* 1434 be a 5th treatment aggregate proposed. 1436 Treatment Aggregates are designed to nicely fit into technologies 1437 that do not have many different treatment levels to use. Here are 3 1438 examples of technologies limited to an 8-value field, 1440 - MPLS with its 3 Traffic Class (TC) bits [RFC5462]. 1442 - IEEE LANs with its 8-value Priority Code Point (PCP) field, as 1443 part of the 802.1Q header spec [IEEE1Q]. 1445 - IEEE 802.1e, which defines QoS over Wi-Fi, also only defines 8 1446 levels (called User Priority or UP codes) [IEEE1E]. 1448 Treatment Aggregates are dependent on service classes to exist. 1449 Therefore many service classes can exist without the need to 1450 consider the use of treatment aggregates or their 8-value 1451 technologies. For example, a Layer 3 VPN can be all that is needed 1452 to transit traffic flows, regardless of desired treatment, between 1453 enterprise LAN campuses. From this reality, the number of treatment 1454 aggregates has no direct bearing on the number of service classes. 1456 2.4.1 Examples of Service Classes in Treatment Aggregates 1458 It is *not* expected that all traffic characteristics are to be 1459 experienced across an SP's network for any given customer. For 1460 example, if VOICE-ADMIT is added to the Realtime Treatment Aggregate 1461 in Figure 5, there are 8 different service classes within the 1462 Realtime Treatment Aggregate. It is not expected that all 8 service 1463 classes will be deployed by customer networks traversing SP 1464 networks. RFC 5127's Treatment Aggregates are a table to configure 1465 which service class goes into which treatment aggregate. If there 1466 are 8 services classes in the Realtime treatment aggregate, there is 1467 very little difference than if there were one service within that 1468 same Realtime treatment aggregate - it would still be necessary to 1469 configure that treatment aggregate. Thus, it becomes a question of 1470 not 1472 "how many service classes are there that go into treatment 1473 aggregates?" 1475 but 1477 "how many treatment aggregates have one or more services 1478 classes requiring configuration"? 1480 Of the 4 treatment aggregates shown in Figure 5, if there are 1481 existing service classes in only 3 of the aggregates, then only 3 1482 treatment aggregates are necessary. Of the 3 following examples, 1483 notice that examples 2 and 3 have the same number of treatment 1484 aggregates, but example 3 has more applications in their own 1485 service classes. 1487 Examples 2 and 3 are made under the following assumptions: 1489 - this draft's Service Classes and DSCP assignments are utilized. 1491 - the new AF-Sig DSCP in the Assured Elastic treatment aggregate. 1493 - the Audio, Video service classes are in the EF treatment 1494 aggregate. 1496 - the VOICE-ADMIT DSCP is in the EF treatment aggregate. 1498 2.4.1.1 Example 1 - Simple Voice Configuration/SLA 1500 For example 1, we have an SP running MPLS and has an SLA to deliver 1501 Network Control, Voice and everything else is Best Effort. The 1502 following table would apply to this configuration/SLA: 1504 +----------------+----------------+-----------+--------------+ 1505 | Applications | Service | DSCP(s) | Treatment | 1506 | | Class | | Aggregate | 1507 +================+================+===========+==============+ 1508 | Network | Network | CS6 | Network | 1509 | Control | Control | | Control | 1510 +----------------+----------------+-----------+--------------+ 1511 | Voice | Audio | EF | Realtime | 1512 +----------------+----------------+-----------+--------------+ 1513 | Everything | DF | Default | Elastic | 1514 | else | | (CS0) | | 1515 +----------------+----------------+-----------+--------------+ 1517 Figure 6. Example 1 Configuration 1519 Insert different treatments for this example 1520 (i.e., AQM, RED, WFQ, colors, etc from above charts) 1522 2.4.1.2 Example 2 - Voice/Video/Surveillance Configuration/SLA 1524 For example 1, we have an SP running MPLS and has an SLA to deliver 1525 Control, audio, video, surveillance, audio & video signaling, and 1526 everything else is BE 1528 +----------------+----------------+-----------+--------------+ 1529 | Applications | Service | DSCP(s) | Treatment | 1530 | | Class | | Aggregate | 1531 +================+================+===========+==============+ 1532 | Network | Network | CS6 | Network | 1533 | Control | Control | | Control | 1534 +----------------+----------------+-----------+--------------+ 1535 | Voice, video, | Audio, Video, | EF, AF42, | Realtime | 1536 | surveillance | Broadcast | CS3 | | 1537 +----------------+----------------+-----------+--------------+ 1538 | audio & video | Conversational | AV-Sig | Assured | 1539 | signaling | Signaling | | Elastic | 1540 +----------------+----------------+-----------+--------------+ 1541 | Everything | DF | Default | Elastic | 1542 | else | | (CS0) | | 1543 +----------------+----------------+-----------+--------------+ 1545 Figure 7. Example 2 Configuration 1547 Insert different treatments for this example 1548 (i.e., AQM, RED, WFQ, colors, etc from above charts) 1550 2.4.1.2 Example 3 - Complex CAC realtime/Surveillance/+apps 1551 Configuration/SLA 1553 For example 1, we have an SP running MPLS and has an SLA to deliver 1554 Control, voice, CAC voice, CAC video, streaming, signaling, LL 1555 data, Network Mgmt., and everything else is BE (including non-CAC 1556 video because it is not authorized or authenticated on network) 1558 +-------------------+-----------------+-----------+--------------+ 1559 | Applications | Service | DSCP(s) | Treatment | 1560 | | Class | | Aggregate | 1561 +===================+=================+===========+==============+ 1562 | Network | Network | CS6 | Network | 1563 | Control | Control | | Control | 1564 +-------------------+-----------------+-----------+--------------+ 1565 | Voice, CAC-Voice | Audio, Video, |Voice-Admit| Realtime | 1566 | CAC-video, | | EF, AF41 | | 1567 | surveillance | Broadcast | CS3 | | 1568 +-------------------+-----------------+-----------+--------------+ 1569 | audio & video | Conversational | AV-Sig | Assured | 1570 | signaling, | Signaling, Low- | AF21 | Elastic | 1571 | VOD (streaming), | Latency Data, | AF31 | | 1572 | Network Mgmt. | Multimedia | CS2 | | 1573 | | Streaming, | | | 1574 | | OAM | | | 1575 +-------------------+-----------------+-----------+--------------+ 1576 | Everything | DF | Default | Elastic | 1577 | else | | (CS0) | | 1578 +-------------------+-----------------+-----------+--------------+ 1580 Figure 8. Example 3 Configuration 1582 Insert different treatments for this example 1583 (i.e., AQM, RED, WFQ, colors, etc from above charts) 1585 3. Network Control Traffic 1587 Network control traffic is defined as packet flows that are 1588 essential for stable operation of an administered network, as well 1589 as the information exchanged between neighboring networks across a 1590 peering point where SLAs are in place. Network control traffic is 1591 different from user application control (signaling) that may be 1592 generated by some applications or services. Network control traffic 1593 is mostly between routers and network nodes (e.g., routing or mgmt 1594 protocols) that are used for operating, administering, controlling, 1595 or managing whole networks, network parts or just network segments. 1596 Network Control Traffic may be split into two service classes, i.e., 1597 Network Control and OAM. 1599 3.1. Current Practice in the Internet 1601 Based on today's routing protocols and network control procedures 1602 that are used in the Internet, we have determined that CS6 DSCP 1603 value SHOULD be used for routing and control and that CS7 DSCP value 1604 SHOULD be reserved for future use, specifically if needed for future 1605 routing or control protocols. Network administrators MAY use a 1606 Local/Experimental DSCP, any value that contains 11xx11; therefore, 1607 they may use a locally defined service class within their network to 1608 further differentiate their routing and control traffic. 1610 RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets: 1612 o Drop or remark 111xxx packets at ingress to DiffServ network 1613 domain. 1615 o 111xxx marked packets SHOULD NOT be sent across peering points. 1616 Exchange of control information across peering points SHOULD be 1617 done using CS6 DSCP and the Network Control service class. 1619 o any internally defined 11xxx1 values, valid within that network 1620 domain, be remarked to CS6 upon egress at network peering points. 1622 3.2. Network Control Service Class 1624 The Network Control service class is used for transmitting packets 1625 between network devices (routers) that require control (routing) 1626 information to be exchanged between similar devices within the 1627 administrative domain, as well as across a peering point between 1628 adjacent administrative domains. Traffic transmitted in this 1629 service class is very important as it keeps the network operational, 1630 and it needs to be forwarded in a timely manner. 1632 The Network Control service class SHOULD be configured using the 1633 DiffServ CS6 PHB, defined in [RFC2474]. This service class MUST be 1634 configured so that the traffic receives a minimum bandwidth 1635 guarantee, to ensure that the packets always receive timely service. 1636 The configured forwarding resources for Network Control service 1637 class MUST be such that the probability of packet drop under peak 1638 load is very low. The Network Control service class SHOULD be 1639 configured to use a Rate Queuing system such as defined in Section 1640 1.4.1.2 of this document. 1642 The following are examples of protocols and applications that MUST 1643 use the Network Control service class if present in a network: 1645 o Routing packet flows: OSPF, BGP, ISIS, RIP. 1647 o Control information exchange within and between different 1648 administrative domains across a peering point where SLAs are in 1649 place. 1651 o LSP setup using CR-LDP and RSVP-TE. 1653 The following protocols and applications MUST NOT use the Network 1654 Control service class: 1656 o User oriented traffic is not allowed to use this service class. 1657 By user oriented traffic, we mean packet flows that originate 1658 from user-controlled end points that are connected to the 1659 network. 1661 o even if originating from a server or a device acting on behalf 1662 of a user or endpoint, 1664 o even if it is application or in-band signaling to establish a 1665 connection wholly within a single network or across peering 1666 points of/to adjacent networks (e.g., creating a tunnel such 1667 as a VPN, or data path control signaling). 1669 The following are traffic characteristics of packet flows in the 1670 Network Control service class: 1672 o Mostly messages sent between routers and network servers. 1674 o Variable size packets, normally one packet at a time, but traffic 1675 can also burst (BGP, OSPF, etc). 1677 o IGMP, hen is used only for the normal multicast routing purpose. 1679 The REQUIRED DSCP marking is CS6 (Class Selector 6). 1681 RECOMMENDED Network Edge Conditioning: 1683 o At peering points (between two DiffServ networks) where SLAs are 1684 in place, CS6 marked packets MUST be policed, e.g., using a 1685 single rate with burst size (sr+bs) token bucket policer to keep 1686 the CS6 marked packet flows to within the traffic rate specified 1687 in the SLA. 1689 o CS6 marked packet flows from untrusted sources (for example, end 1690 user devices) MUST be dropped or remarked at ingress to the 1691 DiffServ network. What a network admin remarks this user oriented 1692 traffic to if a matter of local policy, and inspection of the 1693 packets can determine which application is used for proper 1694 marking to a more appropriate DSCP, such as from table 3. of this 1695 document. 1697 o Packets from users/subscribers are not permitted access to the 1698 Network Control service classes. 1700 The fundamental service offered to the Network Control service class 1701 is enhanced best-effort service with high bandwidth assurance. 1702 Since this service class is used to forward both elastic and 1703 inelastic flows, the service SHOULD be engineered so that the Active 1704 Queue Management (AQM) [RFC2309] is applied to CS6 marked packets. 1706 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1707 specifies a target queue depth, and the max-threshold specifies the 1708 queue depth above which all traffic is dropped or ECN marked. Thus, 1709 in this service class, the following inequality should hold in queue 1710 configurations: 1712 o min-threshold CS6 < max-threshold CS6 1714 o max-threshold CS6 <= memory assigned to the queue 1716 Note: Many other AQM algorithms exist and are used; they should be 1717 configured to achieve a similar result. 1719 3.3. OAM Service Class 1721 The OAM (Operations, Administration, and Management) service class 1722 is RECOMMENDED for OAM&P (Operations, Administration, and Management 1723 and Provisioning) using protocols such as Simple Network Management 1724 Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet, 1725 and Common Open Policy Service (COPS). Applications using this 1726 service class require a low packet loss but are relatively not 1727 sensitive to delay. This service class is configured to provide 1728 good packet delivery for intermittent flows. 1730 The OAM service class SHOULD use the Class Selector (CS) PHB defined 1731 in [RFC2474]. This service class SHOULD be configured to provide a 1732 minimum bandwidth assurance for CS2 marked packets to ensure that 1733 they get forwarded. The OAM service class SHOULD be configured to 1734 use a Rate Queuing system such as defined in Section 1.4.1.2 of this 1735 document. 1737 The following applications SHOULD use the OAM service class: 1739 o Provisioning and configuration of network elements. 1741 o Performance monitoring of network elements. 1743 o Any network operational alarms. 1745 The following are traffic characteristics: 1747 o Variable size packets. 1749 o Intermittent traffic flows. 1751 o Traffic may burst at times. 1753 o Both elastic and inelastic flows. 1755 o Traffic not sensitive to delays. 1757 RECOMMENDED DSCP marking: 1759 o All flows in this service class are marked with CS2 (Class 1760 Selector 2). 1762 Applications or IP end points SHOULD pre-mark their packets with CS2 1763 DSCP value. If the end point is not capable of setting the DSCP 1764 value, then the router topologically closest to the end point SHOULD 1765 perform Multifield (MF) Classification, as defined in [RFC2475]. 1767 RECOMMENDED conditioning performed at DiffServ network edge: 1769 o Packet flow marking (DSCP setting) from untrusted sources (end 1770 user devices) SHOULD be verified at ingress to DiffServ network 1771 using Multifield (MF) Classification methods, defined in 1772 [RFC2475]. 1774 o Packet flows from untrusted sources (end user devices) SHOULD be 1775 policed at ingress to DiffServ network, e.g., using single rate 1776 with burst size token bucket policer to ensure that the traffic 1777 stays within its negotiated or engineered bounds. 1779 o Packet flows from trusted sources (routers inside administered 1780 network) MAY not require policing. 1782 o Normally OAM&P CS2 marked packet flows are not allowed to flow 1783 across peering points. If that is the case, then CS2 marked 1784 packets SHOULD be policed (dropped) at both egress and ingress 1785 peering interfaces. 1787 The fundamental service offered to "OAM" traffic is enhanced 1788 best-effort service with controlled rate. The service SHOULD be 1789 engineered so that CS2 marked packet flows have sufficient bandwidth 1790 in the network to provide high assurance of delivery. Since this 1791 service class is used to forward both elastic and inelastic flows, 1792 the service SHOULD be engineered so that Active Queue Management 1793 [RFC2309] is applied to CS2 marked packets. 1795 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 1796 specifies a target queue depth for each DSCP, and the max-threshold 1797 specifies the queue depth above which all traffic with such a DSCP 1798 is dropped or ECN marked. Thus, in this service class, the 1799 following inequality should hold in queue configurations: 1801 o min-threshold CS2 < max-threshold CS2 1803 o max-threshold CS2 <= memory assigned to the queue 1805 Note: Many other AQM algorithms exist and are used; they should be 1806 configured to achieve a similar result. 1808 4. User Oriented Traffic 1810 User oriented traffic is defined as packet flows between different 1811 users or subscribers, or from servers/nodes on behalf of a user. It 1812 is the traffic that is sent to or from end-terminals and that 1813 supports a very wide variety of applications and services, to 1814 include traffic about a user or application that assists a user 1815 communicate. User oriented traffic can be classified in many 1816 different ways. What we have articulated throughout this document is 1817 a series of non-exhaustive list of categories for classifying user 1818 oriented traffic. We differentiated user oriented traffic that is 1819 real-time versus non-real-time, elastic or rate-adaptive versus 1820 inelastic, sensitive versus insensitive to loss as well as 1821 considering whether the traffic is interactive vs. one way 1822 communication, its responsiveness, whether it requires timely 1823 delivery, and critical verses non-critical. In the final analysis, 1824 we used all of the above for service differentiation, mapping 1825 application types that seemed to have different sets of performance 1826 sensitivities, and requirements to different service classes. 1828 Network administrators can categorize their applications according 1829 to the type of behavior that they require and MAY choose to support 1830 all or a subset of the defined service classes. At the same time, 1831 we include a public facing default DSCP value, with its associated 1832 PHB, that is expected for each traffic type to ensure common or 1833 pervasive performance. Figure 3 provides some common applications 1834 and the forwarding service classes that best support them, based on 1835 their performance requirements. 1837 4.1. Conversational Service Class Group 1839 The Conversational Service Class Group consists of 3 different 1840 service classes, audio, video, and Hi-Res. We are describing the 1841 media sample, or bearer, packets for applications (e.g., RTP from 1842 [RFC3550]) that require bi-directional real-time, very low delay, 1843 very low jitter, and very low packet loss for relatively 1844 constant-rate traffic sources (inelastic traffic sources). It is 1845 RECOMMENDED that RTCP feedback use the same service class and be 1846 marked with the same DSCP as the bearer traffic for that (audio 1847 and/or video) call. This ensures comparable treatment within the 1848 network between endpoints. 1850 The signaling to set-up these bearer flows is part of the 1851 Conversational Signaling service group that will be discussed later 1852 in Section 4. The following 3 subsections will detail what is 1853 expected within each bearer service class. 1855 4.1.1 Audio Service Class 1857 This service class MUST be used for IP Audio service. 1859 The fundamental service offered to traffic in the Audio service 1860 class is minimum jitter, delay, and packet loss service up to a 1861 specified upper bound. There are two PHBs, both EF based, for the 1862 Audio service class: 1864 Nonadmitted Audio traffic - MUST use the EF DSCP [RFC3246], and 1865 is for traffic that has not had any capacity admission 1866 signaling performed for that flow or session. 1868 Capacity-Admitted Audio traffic - MUST use the Voice-Admit DSCP 1869 [RFC5865], and is for traffic that has had any capacity 1870 admission signaling performed for that flow or session, e.g., 1871 RSVP [RFC2205] or NSIS [RFC4080]. 1873 The capacity-admitted Audio traffic operation is similar to an ATM 1874 CBR service, which has guaranteed bandwidth and which, if it stays 1875 within the negotiated rate, experiences nominal delay and no loss. 1877 The nonadmitted Audio traffic, on the other hand, has had no such 1878 explicit guarantee, but has a favorable PHB ensuring high 1879 probability of delivery as well as nominal delay and no loss - 1880 implicitly assuming there is not too much like marked traffic 1881 between users within a flow. 1883 There are two typical scenarios in which audio calls are 1884 established, on the public open Internet using protocols such as 1885 SIP, XMPP or H.323, or in more managed networks like enterprises or 1886 certain service providers which offer a audio service with some 1887 feature benefits and take part in the call signaling. These SPs or 1888 enterprises also use protocols like SIP, XMPP, H.323, but also use 1889 H.248/MEGACO and MGCP. 1891 On the open Internet, typically there is no SP actively involved in 1892 the session set-up of calls, and therefore no servers providing 1893 assistance or features to help one user contact another user. Often, 1894 this traffic is marked or remarked with the DF (i.e., Best Effort) 1895 DSCP. 1897 In more managed networks in which one of more operators have active 1898 servers aiding the audio call set-up, where DiffServ can be used and 1899 preserved to differentiate traffic, networks are offering a service, 1900 therefore need to do some, or a lot of engineering to ensure that 1901 capacity offered to one or more applications does not exceed the 1902 load to the network. Otherwise, the operator will have unhappy 1903 users, at least for that application's usage. This is true for any 1904 application, but is especially true for inelastic applications in 1905 which the application is rigid in its delivery requirements. Audio 1906 bearer traffic is typically such an application, video is another 1907 such application, but we will get to video in the next subsection. 1909 When a user in a managed network has been authorized to send Audio 1910 traffic (i.e., call initiation via the operator's servers was not 1911 rejected), the call admission procedure should have verified that 1912 the newly admitted flow will be within the capacity of the Audio 1913 service class forwarding capability in the network. Capacity 1914 verification is a non-trivial thing, and can either be implicitly 1915 assumed by the call server(s) based on the operator's network 1916 design, or it can be explicitly signaled from an in-data-path 1917 signaling mechanism that verifies the capacity is available now for 1918 this call, for each call made within that network. In the latter 1919 case, those that do not have verifiable network capacity along the 1920 data path are rejected. An in between means method is for call 1921 servers to count calls between two or more endpoints. By 1922 topologically understanding where the caller and called party is and 1923 have configured a known maximum it will allow between the two 1924 locations. This is especially true over WAN links that have far less 1925 capacity than LAN links or core parts of a network. Network 1926 operators will need to understand the topology between any two 1927 callers to ensure the appropriate amount of bandwidth is available 1928 for an expected number of simultaneous audio calls. 1930 Once more than one bandwidth amount can be used for audio calls, for 1931 example - by allowing more than one codec with different bandwidths 1932 per codec for such calls, network engineering becomes more 1933 difficult. Since the inelastic nature of RTP payloads from this 1934 class do not react well to loss or significant delay in any 1935 substantive way, the Audio service class MUST forward packets as 1936 soon as possible. 1938 The Audio service class that does not have capacity admission 1939 performed in the data path MUST use the Expedited Forwarding (EF) 1940 PHB, as defined in [RFC3246], so that all packets are forwarded 1941 quickly. The Audio service class that does have capacity admission 1942 performed in the data path MUST use the Voice-Admit PHB, as defined 1943 in [RFC5865], so that all packets are forwarded quickly. The Audio 1944 service class SHOULD be configured to use a Priority Queuing system 1945 such as that defined in Section 1.4.1.1 of this document. 1947 The following applications SHOULD use the Audio service class: 1949 o VoIP (G.711, G.729, iLBC and other audio codecs). 1951 o Voice-band data over IP (modem, fax). 1953 o T.38 fax over IP. 1955 o Circuit emulation over IP, virtual wire, etc. 1957 o IP Virtual Private Network (VPN) service that specifies 1958 single-rate, mean network delay that is slightly longer then 1959 network propagation delay, very low jitter, and a very low packet 1960 loss. 1962 The following are traffic characteristics: 1964 o Mostly fixed-size packets for VoIP (30, 60, 70, 120 or 200 bytes 1965 in size). 1967 o Packets emitted at constant time intervals. 1969 o Admission control of new flows is provided by Audio call server, 1970 media gateway, gatekeeper, edge router, end terminal, access node 1971 or in-data-path signaling that provides flow admission control 1972 function. 1974 Applications or IP end points SHOULD pre-mark their packets with EF 1975 or Voice-Admit DSCP value, whichever is appropriate. If the end 1976 point is not capable of setting the DSCP value, then the router 1977 topologically closest to the end point SHOULD perform Multifield 1978 (MF) Classification, as defined in [RFC2475]. 1980 The RECOMMENDED DSCP marking is EF for nonadmitted audio flows, and 1981 Voice-Admit for capacity-admitted flows for the following 1982 applications: 1984 o VoIP (G.711, G.729 and other codecs). 1986 o Voice-band data over IP (modem and fax). 1988 o T.38 fax over IP. 1990 o Circuit emulation over IP, virtual wire, etc. 1992 RECOMMENDED Network Edge Conditioning: 1994 o Packet flow marking (DSCP setting) from untrusted sources (end 1995 user devices) SHOULD be verified at ingress to DiffServ network 1996 using Multifield (MF) Classification methods, defined in 1997 [RFC2475]. If untrusted, the network edge SHOULD know if 1998 capacity-admission has been applied, since the edge router will 1999 have taken part in the admission signaling; therefore will know 2000 whether EF or Voice-Admit is the proper marking for that flow. 2002 o Packet flows from untrusted sources (end user devices) SHOULD be 2003 policed at ingress to DiffServ network, e.g., using single rate 2004 with burst size token bucket policer to ensure that the Audio 2005 traffic stays within its negotiated bounds. 2007 o Policing is OPTIONAL for packet flows from trusted sources whose 2008 behavior is ensured via other means (e.g., administrative 2009 controls on those systems). 2011 o Policing of Audio packet flows across peering points where SLA is 2012 in place is OPTIONAL as Audio traffic will be controlled by 2013 admission control mechanism between peering points. 2015 The fundamental service offered to "Audio" traffic is enhanced 2016 best-effort service with controlled rate, very low delay, and very 2017 low loss. The service MUST be engineered so that EF marked packet 2018 flows have sufficient bandwidth in the network to provide guaranteed 2019 delivery. Otherwise, the service will have in place an explicit 2020 capacity-admission signaling protocol such as RSVP or NSIS and thus 2021 mark the packets within the flow as Voice-Admit. Normally traffic in 2022 this service class does not respond dynamically to packet loss. As 2023 such, Active Queue Management [RFC2309] SHOULD NOT be applied to EF 2024 marked packet flows. 2026 4.1.2 Video Service Class 2028 The Video service class is for bidirectional applications that 2029 require real-time service for both constant and rate-adaptive 2030 traffic. SIP and H.323/V2 (and later) versions of video 2031 conferencing equipment with constant and dynamic bandwidth 2032 adjustment are such applications. The traffic sources in this 2033 service class either have a fixed bandwidth requirement (e.g., 2034 MPEG2, etc.), or have the ability to dynamically change their 2035 transmission rate (e.g., MPEG4/H.264, etc.) based on feedback from 2036 the receiver. This feedback SHOULD be accomplished using RTCP 2037 [RFC3550]. One approach for this downspeeding has the receiver 2038 detect packet loss, thus signaling in an RTCP message to the source 2039 the indication of lost (or delayed or out of order) packets in 2040 transit. When necessary the source then selects a lower rate 2041 encoding codec. When available, the source merely sends less data, 2042 resulting in lower resolution of the same visual display. 2044 The Video service class is not for video downloads, webcasts, or 2045 single directional video or audio/video traffic of any kind. It is 2046 for human-to-human visual interaction between two users, or more if 2047 an MTP is used. 2049 Typical video conferencing configurations negotiate the setup of 2050 audio/video session using protocols such as SIP and H.323. Just as 2051 with networks that have audio traversing them, video typically 2052 traverses the same two types of networks: the open big "I" Internet, 2053 in which most every type of traffic is best effort (DF), or on a 2054 more managed network such as an enterprise or SP's managed network 2055 in which servers within either network take part in the call 2056 signaling, thereby offering the video service. 2058 When a user in a managed network has been authorized to send video 2059 traffic (i.e., call initiation via the operator's servers was not 2060 rejected), the call admission procedure should have verified that 2061 the newly admitted flow will be within the capacity of the video 2062 service class forwarding capability in the network. Capacity 2063 verification is a non-trivial thing, and can either be implicitly 2064 assumed by the call server(s) based on the operator's network 2065 design, or it can be explicitly signaled from an in-data-path 2066 signaling mechanism that verifies the capacity is available now for 2067 this call, for each call made within that network. In the latter 2068 case, those that do not have verifiable network capacity along the 2069 data path are rejected. An in between means method is for call 2070 servers to count calls between two or more endpoints. By 2071 topologically understanding where the caller and called party is and 2072 have configured a known maximum it will allow between the two 2073 locations. Video is larger in bandwidth than audio, and the 2074 difference can be significant. For example, for a single G.711 audio 2075 call that is 80kbps, an associated video bandwidth for the same 2076 call can easily be 4Mbps. This is especially true over WAN links 2077 that have far less capacity than LAN links or core parts of a 2078 network. Network operators will need to understand the topology 2079 between any two callers to ensure the appropriate amount of 2080 bandwidth is available for an expected number of simultaneous video 2081 and/or audio/video calls. 2083 Note that it is OPTIONALLY the case in these networks that the 2084 accompanying audio for the video call will be marked as the video is 2085 marked (i.e., using the same DSCP), but not always. One reason this 2086 has been done is for lip-sync. 2088 The Video service class MUST use the Assured Forwarding (AF) PHB, 2089 defined in [RFC2597]. This service class MUST be configured to 2090 provide a bandwidth assurance for AF41, AF42, and AF43 marked 2091 packets to ensure that they get forwarded. The Video service class 2092 SHOULD be configured to use a Rate Queuing system for AF42 and AF43 2093 traffic flows, such as that defined in Section 1.4.1.2 of this 2094 document. However, AF41 MUST be designated as the DSCP for use when 2095 capacity-admission signaling has been used, such as RSVP or NSIS, to 2096 guarantee delivery through the network. AF42 and AF43 will be used 2097 for non-admitted video calls, as well as overflows from AF41 sources 2098 that send more packets than they have negotiated bandwidth for that 2099 call. 2101 The following applications MUST use the Video service class: 2103 o SIP and H.323/V2 (and later) versions of video conferencing 2104 applications (interactive video). 2106 o Video conferencing applications with rate control or traffic 2107 content importance marking. 2109 o Interactive, time-critical, and mission-critical applications. 2111 NOTE with regards to the above bullet: this usage SHOULD be 2112 minimized, else the video traffic will suffer - unless this 2113 is engineered into the topology. 2115 The following are traffic characteristics: 2117 o Variable size packets (i.e., small to large in size). 2119 o The higher the resolution or change rate between each image, the 2120 higher the duration of large packets. 2122 o Usually constant inter-packet time interval. 2124 o Can be Variable rate in transmission. 2126 o Source is capable of reducing its transmission rate based on 2127 being told receiver is detecting packet loss (e.g., via RTCP). 2129 Applications or IP end points SHOULD pre-mark their packets with 2130 DSCP values as shown below. If the end point is not capable of 2131 setting the DSCP value, then the router topologically closest to the 2132 end point SHOULD perform Multifield (MF) Classification, as defined 2133 in [RFC2475] and mark all packets as AF4x. Note: In this case, the 2134 two-rate, three-color marker will be configured to operate in 2135 Color-Blind mode. 2137 Mandatory DSCP marking when performed by router closest to source: 2139 o AF41 = up to specified rate "A", which is dedicated to non-Hi-Res 2140 capacity-admitted video traffic. 2142 Note the audio of an A/V call can be marked AF41 as well. 2144 o AF42 = all non-Hi-Res video traffic marked AF41 in excess of 2145 specified rate "A", or new non-admitted video traffic but 2146 below specified rate "B". 2148 o AF43 = in excess of specified rate "B". 2150 o Where "A" < "B". 2152 Note: One might expect "A" to approximate the peak rates of sum of 2153 all admitted video flows, plus the sum of the mean rates and 2154 "B" to approximate the sum of the peak rates of those same two 2155 flows. 2157 Mandatory DSCP marking when performed by SIP or H.323/V2 2158 videoconferencing equipment: 2160 o AF41 = SIP or H.323 video conferencing audio stream RTP. 2162 o AF41 = SIP or H.323 video conferencing video control RTCP. 2164 o AF41 = SIP or H.323 video conferencing video stream up to 2165 specified rate "A". 2167 o AF42 = SIP or H.323 video conferencing video stream in excess of 2168 specified rate "A" but below specified rate "B". 2170 o AF42 = SIP or H.323 video conferencing video control RTCP, for 2171 those video streams that were generated using AF42. 2173 o AF43 = SIP or H.323 video conferencing video stream in excess of 2174 specified rate "B". 2176 o AF43 = SIP or H.323 video conferencing video control RTCP, for 2177 those video streams that were generated using AF43. 2179 o Where "A" < "B". 2181 Mandatory conditioning performed at DiffServ network edge: 2183 o The two-rate, three-color marker SHOULD be configured to provide 2184 the behavior as defined in trTCM [RFC2698]. 2186 o If packets are marked by trusted sources or a previously trusted 2187 DiffServ domain and the color marking is to be preserved, then 2188 the two-rate, three-color marker SHOULD be configured to operate 2189 in Color-Aware mode. 2191 o If the packet marking is not trusted or the color marking is not 2192 to be preserved, then the two-rate, three-color marker SHOULD be 2193 configured to operate in Color-Blind mode. 2195 The fundamental service offered to nonadmitted "Video" traffic is 2196 enhanced best-effort service with controlled rate and delay. The 2197 fundamental service offered to capacity-admitted "Video" traffic is 2198 a guaranteed service using in-data-path signaling to ensure expected 2199 delivery in a timely manner. For a non-admitted video conferencing 2200 service, if a 1% packet loss detected at the receiver triggers an 2201 encoding rate change, thus dropping to the next lower provisioned 2202 video encoding rate then Active Queue Management [RFC2309] SHOULD be 2203 used primarily to switch the video encoding rate under congestion, 2204 changing from high rate to lower rate, i.e., 1472 kbps to 768 kbps. 2205 This rule applies to all AF42 and 43 flows. The probability of loss 2206 of AF41 traffic MUST NOT exceed the probability of loss of AF42 2207 traffic, which in turn MUST NOT exceed the probability of loss of 2208 AF43 traffic. 2210 Capacity-admitted video service should not result in packet loss. 2212 However, administratively this MAY be allowed to cause a purposeful 2213 downspeeding event (i.e., a change in resolution or a change in 2214 codec) to occur due to congestion. 2216 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2217 specifies a target queue depth for each DSCP, and the max-threshold 2218 specifies the queue depth above which all traffic with such a DSCP 2219 is dropped or ECN marked. Thus, in this service class, the 2220 following inequality should hold in queue configurations: 2222 o min-threshold AF43 < max-threshold AF43 2224 o max-threshold AF43 <= min-threshold AF42 2226 o min-threshold AF42 < max-threshold AF42 2228 o max-threshold AF42 <= min-threshold AF41 2230 o min-threshold AF41 < max-threshold AF41 2232 o max-threshold AF41 <= memory assigned to the queue 2234 Note: This configuration tends to drop AF43 traffic before AF42 and 2235 AF42 before AF41. Many other AQM algorithms exist and are 2236 used; they should be configured to achieve a similar result. 2238 4.1.3 Hi-Res Service Class 2240 The Hi-Res service class is for higher end (i.e., deemed 'more 2241 important') bidirectional applications that require real-time 2242 service for both constant and rate-adaptive traffic. There are two 2243 PHBs, both EF based, for the Hi-Res video conferencing service 2244 class: 2246 Nonadmitted Hi-Res traffic - MUST use the CS4 DSCP [RFC2474], and 2247 is for traffic that has not had any capacity admission 2248 signaling performed for that flow or session. 2250 Capacity-Admitted Hi-Res traffic - MUST use the CS4-Admit DSCP 2251 [ID-DSCP], and is for traffic that has had any capacity 2252 admission signaling performed for that flow or session, e.g., 2253 RSVP [RFC2205] or NSIS [RFC4080]. 2255 The capacity-admitted Hi-Res video conferencing traffic operation is 2256 similar to an ATM CBR service, which has guaranteed bandwidth and 2257 which, if it stays within the negotiated rate, experiences nominal 2258 delay and no loss. 2260 SIP and H.323/V2 (and later) versions of video conferencing 2261 equipment with constant and dynamic bandwidth adjustment are such 2262 applications. The traffic sources in this service class either have 2263 a fixed bandwidth requirement (e.g., MPEG2), or have the ability to 2264 dynamically change their transmission rate (e.g., MPEG4/H.264) based 2265 on feedback from the receiver. This feedback SHOULD be accomplished 2266 using RTCP [RFC3550]. One approach for this downspeeding has the 2267 receiver detect packet loss, thus signaling in an RTCP message to 2268 the source the indication of lost (or delayed or out of order) 2269 packets in transit. When necessary the source then selects a lower 2270 rate encoding codec. When available, the source merely sends less 2271 data, resulting in lower resolution of the same visual display. 2273 The Hi-Res service class, as with the Video service class, is not 2274 for video downloads, webcasts, or single directional video or 2275 audio/video traffic of any kind. It is for human-to-human visual 2276 interaction between two users, or more if an video conference bridge 2277 is used. 2279 Typical Hi-Res video conferencing configurations negotiate the setup 2280 of audio/video session using protocols such as SIP and H.323. 2281 Hi-Res video conferencing is generally not over the big "I" 2282 Internet, rather nearly exclusively over more managed networks such 2283 as an enterprise or special purpose SP's managed network in which 2284 servers within either network take part in the call signaling, 2285 thereby offering the video service. In addition, typically this type 2286 of audio/video service has high business expectations for minimized 2287 packet loss, pixilation or other issues with the audio/video 2288 experience. In the recent past, entire T3s have been dedicated to a 2289 signal Hi-Res call; sometimes one T3 per site of a multi-site video 2290 conference. 2292 Hi-Res video conferencing often has larger in bandwidth than the 2293 typical video call. The audio portion can be increased as well, as 2294 stereo capabilities are often necessary to provide an in-room 2295 experience from a distance. The difference can be significant (or 2296 another step up from just a typical video service). For example, for 2297 a single G.711 audio call that is 80kbps, a Hi-Res conference 2298 usually runs G.722 wideband audio at 256kbps. Typical video delivery 2299 is up to 4Mbps, whereas a Hi-Res conference can have three 2300 1080p/30fps widescreen displays requiring at least 12Mbps, with a 2301 burst capability of much more. 2303 If there were no congestion on the wire, the expected treatment 2304 between a video service and a Hi-Res conference would be the same. 2305 However, it is typically the case that the Hi-Res conferencing flows 2306 have more rigid requirements for quality and business-wise, need to 2307 be experience far less errors than the regular video service on the 2308 same network. 2310 Note that it is likely the case in these networks that the 2311 accompanying audio to the Hi-Res video call will be marked as the 2312 Hi-Res video is marked (i.e., using the same DSCP. 2314 The Hi-Res service class MUST use the Class Selector 5 (CS4) PHB, 2315 defined in [RFC2474], for non-capacity-admitted conferences. While 2316 the capacity-admitted Hi-Res conferences MUST use the CS4-Admit PHB, 2317 defined in [ID-DSCP]. This service class MUST be configured to 2318 provide a bandwidth assurance for CS4 and CS4-Admit marked packets 2319 to ensure that they get forwarded. The Hi-Res service class SHOULD 2320 be configured to use a Priority Queuing system such as that defined 2321 in Section 1.4.1.1 of this document. Further, CS4-Admit will be 2322 designated as the DSCP for use when capacity-admission signaling has 2323 been used, such as RSVP or NSIS, to guarantee delivery through the 2324 network. CS4 will be used for non-admitted Hi-Res conferences, as 2325 well as overflows from CS4-Admit sources that send more packets than 2326 they have negotiated bandwidth for that call. 2328 The following applications MUST use the Hi-Res service class: 2330 o SIP and H.323/V2 (and later) versions of Hi-Res video 2331 conferencing applications (interactive Hi-Res video). 2333 o Video conferencing applications with rate control or traffic 2334 content importance marking. 2336 The following are traffic characteristics: 2338 o Variable size packets. 2340 o The higher the resolution or change rate between each image, the 2341 higher the duration of large packets. 2343 o Usually constant inter-packet time interval. 2345 o Can be Variable rate in transmission. 2347 o Source is capable of reducing its transmission rate based on 2348 being told receiver is detecting packet loss. 2350 Applications or IP end points SHOULD pre-mark their packets with 2351 DSCP values as shown below. If the end point is not capable of 2352 setting the DSCP value, then the router topologically closest to the 2353 end point SHOULD perform Multifield (MF) Classification, as defined 2354 in [RFC2475] and mark all packets as AF4x. 2356 Mandatory DSCP marking when performed by router closest to source: 2358 o CS4-Admit = up to specified rate "A", which is dedicated to 2359 capacity-admitted Hi-Res traffic. 2361 Note the audio of an A/V call can be marked CS4-Admit as well. 2363 o CS4 = all video traffic marked CS4-Admit in excess of specified 2364 rate "A", or new non-admitted video traffic but below 2365 specified rate "B". 2367 o Where "A" < "B". 2369 Note: One might expect "A" to approximate the peak rates of sum of 2370 all admitted video flows, plus the sum of the mean rates and 2371 "B" to approximate the sum of the peak rates of those same two 2372 flows. 2374 Mandatory DSCP marking when performed by SIP or H.323/V2 2375 videoconferencing equipment: 2377 o CS4-Admit = SIP or H.323 video conferencing audio stream RTP/UDP. 2379 o CS4-Admit = SIP or H.323 video conferencing video control 2380 RTCP/TCP. 2382 o CS4-Admit = SIP or H.323 video conferencing video stream up to 2383 specified rate "A". 2385 o CS4 = SIP or H.323 video conferencing video stream in excess of 2386 specified rate "A" but below specified rate "B". 2388 o Where "A" < "B". 2390 Mandatory conditioning performed at DiffServ network edge: 2392 o The two-rate, three-color marker SHOULD be configured to provide 2393 the behavior as defined in trTCM [RFC2698]. 2395 o If packets are marked by trusted sources or a previously trusted 2396 DiffServ domain and the color marking is to be preserved, then 2397 the two-rate, three-color marker SHOULD be configured to operate 2398 in Color-Aware mode. 2400 o If the packet marking is not trusted or the color marking is not 2401 to be preserved, then the two-rate, three-color marker SHOULD be 2402 configured to operate in Color-Blind mode. 2404 The fundamental service offered to nonadmitted "Hi-Res" traffic is 2405 enhanced best-effort service with controlled rate and delay. The 2406 fundamental service offered to capacity-admitted "Hi-Res" traffic is 2407 a guaranteed service using in-data-path signaling to ensure expected 2408 or timely delivery. Capacity-admitted video service SHOULD NOT 2409 result in packet loss. However, administratively this MAY be allowed 2410 to cause a purposeful downspeeding event (i.e., a change in 2411 resolution or a change in codec) to occur. 2413 4.2. Realtime-Interactive Service Class 2415 The Realtime-Interactive service class is for bidirectional 2416 applications that require low loss and jitter and very low delay for 2417 constant or variable rate inelastic traffic sources. Interactive 2418 gaming applications that do not have the ability to change encoding 2419 rates or to mark packets with different importance indications is 2420 one good example of such an application. Another set of 2421 applications is virtualized desktop applications in which a remote 2422 user has a keyboard, mouse and display monitor, but the desktop is 2423 virtualized with the memory/processor/applications back in a common 2424 data center, requiring near instantaneous feedback on the user's 2425 monitor of any changes caused by the application or an action by the 2426 user. Rich media protocols for voice and video MUST NOT use the 2427 Realtime-Interactive service class, but rather the appropriate 2428 service class from the Conversational service group discussed early 2429 in Section 4.1. 2431 The Realtime-Interactive service class will use two PHBs: 2433 Nonadmitted Realtime-Interactive traffic - MUST use the CS5 DSCP 2434 [RFC2474], and is for traffic that has not had any capacity 2435 admission signaling performed for that flow or session. 2437 Capacity-Admitted Realtime-Interactive traffic - MUST use the 2438 CS5-Admit DSCP [ID-DSCP], and is for traffic that has had any 2439 capacity admission signaling performed for that flow or 2440 session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. 2442 The capacity-admitted Realtime-Interactive traffic operation is 2443 similar to an ATM CBR service, which has guaranteed bandwidth and 2444 which, if it stays within the negotiated rate, experiences nominal 2445 delay and no loss. 2447 Either of the above service classes can be configured as EF based by 2448 using a relaxed performance parameter and a rate scheduler. 2450 When a user/endpoint has been authorized to start a new session 2451 (i.e., joins a networked game or logs onto a virtualized 2452 workstation), the admission procedure should have verified that the 2453 newly admitted data rates will be within the engineered capacity of 2454 the Realtime-Interactive service class. The bandwidth in the core 2455 network and the number of simultaneous Realtime-Interactive sessions 2456 that can be supported SHOULD be engineered to control traffic load 2457 for this service. 2459 This service class SHOULD be configured to provide a high assurance 2460 for bandwidth for CS5 PHB, defined in [RFC2474], or CS5-Admit 2461 [ID-DSCP] for guaranteed service through a capacity-admission 2462 signaling protocol. The Realtime-Interactive service class SHOULD be 2463 configured to use a Rate Queuing system such as that defined in 2464 Section 1.4.1.2 of this document. Note that either 2465 Realtime-Interactive PHB MAY be configured as another EF PHB, 2466 specifically CS5-Admit, that uses a relaxed performance parameter 2467 and a rate scheduler, in the priority queue as defined in Section 2468 1.4.1.1 of this document. 2470 The following applications MUST use the Realtime-Interactive service 2471 class: 2473 o Interactive gaming and control. 2475 o Remote Desktop applications 2477 o Virtualized Desktop applications. 2479 o Application server-to-application server non-bursty data transfer 2480 requiring very low delay. 2482 o Inelastic, interactive, time-critical, and mission-critical 2483 applications requiring very low delay. 2485 The following are traffic characteristics: 2487 o Variable size packets. 2489 o Variable rate, though sometimes bursty, which will require 2490 engineering of the network to accommodate. 2492 o Application is sensitive to delay variation between flows and 2493 sessions. 2495 o Lost packets, if any, are usually ignored by application. 2497 RECOMMENDED DSCP marking: 2499 o All non-admitted flows in this service class are marked with CS5 2500 (Class Selector 5). 2502 o All capacity-admitted flows in this service class are marked with 2503 CS5-Admit. 2505 Applications or IP end points SHOULD pre-mark their packets with CS5 2506 or CS5-Admit DSCP value, depending on whether a capacity-admission 2507 signaling protocol is used for a flow. If the end point is not 2508 capable of setting the DSCP value, then the router topologically 2509 closest to the end point SHOULD perform Multifield (MF) 2510 Classification, as defined in [RFC2475]. 2512 RECOMMENDED conditioning performed at DiffServ network edge: 2514 o Packet flow marking (DSCP setting) from untrusted sources (end 2515 user devices) SHOULD be verified at ingress to DiffServ network 2516 using Multifield (MF) Classification methods defined in 2517 [RFC2475]. 2519 o Packet flows from untrusted sources (end user devices) SHOULD be 2520 policed at ingress to DiffServ network, e.g., using single rate 2521 with burst size token bucket policer to ensure that the traffic 2522 stays within its negotiated or engineered bounds. 2524 o Packet flows from trusted sources (application servers inside 2525 administered network) MAY not require policing. 2527 o Policing of packet flows across peering points MUST adhere to the 2528 Service Level Agreement (SLA). 2530 The fundamental service offered to nonadmitted 2531 "Realtime-Interactive" traffic is enhanced best-effort service with 2532 controlled rate and delay. The fundamental service offered to 2533 capacity-admitted "Realtime-Interactive" traffic is a guaranteed 2534 service using in-data-path signaling to ensure expected or timely 2535 delivery. Capacity-admitted Realtime-Interactive service SHOULD NOT 2536 result in packet loss. The service SHOULD be engineered so that CS5 2537 marked packet flows have sufficient bandwidth in the network to 2538 provide high assurance of delivery. Normally, traffic in this 2539 service class does not respond dynamically to packet loss. As such, 2540 Active Queue Management [RFC2309] SHOULD NOT be applied to CS5 2541 marked packet flows. 2543 4.3. Multimedia Conferencing Service Class 2545 The Multimedia Conferencing service class is for applications that 2546 have a low to medium tolerance to delay, and are rate adaptive to 2547 lost packets in transit from sources. Presentation Data 2548 applications that are operational in conjunction with an audio/video 2549 conference is one good example of such an application. Another set 2550 of applications is application sharing or whiteboarding 2551 applications, also in conjunction to an A/V conference. In either 2552 case, the audio & video part of the flow MUST NOT use the Multimedia 2553 Conferencing service class, rather the more appropriate service 2554 class within the Conversational service group discussed earlier in 2555 Section 4.1. 2557 The Multimedia Conferencing service class will use two PHBs: 2559 Nonadmitted Multimedia Conferencing traffic - MUST use the (new) 2560 MC DSCP [ID-DSCP], and is for traffic that has not had any 2561 capacity admission signaling performed for that flow or 2562 session. 2564 Capacity-Admitted Multimedia Conferencing traffic - MUST use the 2565 (new) MC-Admit DSCP [ID-DSCP], and is for traffic that has 2566 had any capacity admission signaling performed for that flow 2567 or session, e.g., RSVP [RFC2205] or NSIS [RFC4080]. 2569 The capacity-admitted Multimedia Conferencing traffic operation is 2570 similar to an ATM CBR service, which has guaranteed bandwidth and 2571 which, if it stays within the negotiated rate, experiences nominal 2572 delay and no loss. 2574 When a user/endpoint initiates a presentation data, application 2575 sharing or whiteboarding session, it will typically be part of an 2576 audio or audio/video conference such as web-conferencing or an 2577 existing Telepresence call. The authorization procedure SHOULD be 2578 controlled through the coordinated effort to bind the A/V call with 2579 the correct Multimedia Conferencing packet flow through some use of 2580 identifiers not in scope of this document. The managed network this 2581 flow traverse and the number of simultaneous Multimedia 2582 Conferencing sessions that can be supported SHOULD be engineered to 2583 control traffic load for this service. 2585 The non-capacity admitted Multimedia Conferencing service class 2586 SHOULD use the new MC PHB, defined in [ID-DSCP]. This service class 2587 SHOULD be configured to provide a high assurance for bandwidth for 2588 CS5 marked packets to ensure that they get forwarded. The 2589 Multimedia Conferencing service class SHOULD be configured to use a 2590 Rate Queuing system such as that defined in Section 1.4.1.2 of this 2591 document. Note that this service class MAY be configured as another 2592 EF PHB that uses a relaxed performance parameter, a rate scheduler, 2593 and MC-Admit DSCP value, which MUST use the priority queue as 2594 defined in Section 1.4.1.1 of this document. 2596 The following applications MUST use the Multimedia Conferencing 2597 service class: 2599 o Presentation Data applications, which can utilize vector 2600 graphics, raster graphics or video delivery. 2602 o Virtualized Desktop applications. 2604 o Application server-to-application server non-bursty data transfer 2605 requiring very low delay. 2607 The following are traffic characteristics: 2609 o Variable size packets. 2611 o Variable rate, though sometimes bursty, which will require 2612 engineering of the network to accommodate. 2614 o Application is sensitive to delay variation between flows and 2615 sessions. 2617 o Lost packets, if any, can be ignored by the application. 2619 RECOMMENDED DSCP marking: 2621 o All non-admitted flows in this service class are marked with the 2622 new MC DSCP. 2624 o All capacity-admitted flows in this service class are marked with 2625 MC-Admit. 2627 Applications or IP end points SHOULD pre-mark their packets with the 2628 MC DSCP value. If the end point is not capable of setting the DSCP 2629 value, then the router topologically closest to the end point SHOULD 2630 perform Multifield (MF) Classification, as defined in [RFC2475]. 2632 RECOMMENDED conditioning performed at DiffServ network edge: 2634 o Packet flow marking (DSCP setting) from untrusted sources (end 2635 user devices) SHOULD be verified at ingress to DiffServ network 2636 using Multifield (MF) Classification methods defined in 2637 [RFC2475]. 2639 o Packet flows from untrusted sources (end user devices) SHOULD be 2640 policed at ingress to DiffServ network, e.g., using single rate 2641 with burst size token bucket policer to ensure that the traffic 2642 stays within its negotiated or engineered bounds. 2644 o Packet flows from trusted sources (application servers inside 2645 administered network) MAY not require policing. 2647 o Policing of packet flows across peering points MUST adhere to the 2648 Service Level Agreement (SLA). 2650 The fundamental service offered to nonadmitted "Multimedia 2651 Conferencing" traffic is enhanced best-effort service with 2652 controlled rate and delay. The fundamental service offered to 2653 capacity-admitted "Multimedia Conferencing" traffic is a guaranteed 2654 service using in-data-path signaling to ensure expected or timely 2655 delivery. Capacity-admitted Multimedia Conferencing service SHOULD 2656 NOT result in packet loss. The service SHOULD be engineered so that 2657 Multimedia Conferencing marked packet flows have sufficient 2658 bandwidth in the network to provide high assurance of delivery. 2659 Normally, traffic in this service class does not respond dynamically 2660 to packet loss. As such, Active Queue Management [RFC2309] SHOULD 2661 NOT be applied to MC or MC-Admit marked packet flows. 2663 4.4. Multimedia Streaming Service Class 2665 The Multimedia Streaming service class is RECOMMENDED for 2666 applications that require near-real-time packet forwarding of 2667 variable rate elastic traffic sources that are not as delay 2668 sensitive as applications using the Broadcast service class. Such 2669 applications include streaming audio and video, some video (movies) 2670 on-demand applications, and non-interactive webcasts. In general, 2671 the Multimedia Streaming service class assumes that the traffic is 2672 buffered at the source/destination; therefore, it is less sensitive 2673 to delay and jitter. 2675 The Multimedia Streaming service class MUST use the Assured 2676 Forwarding (AF3x) PHB, defined in [RFC2597]. This service class 2677 MUST be configured to provide a minimum bandwidth assurance for 2678 AF31, AF32, and AF33 marked packets to ensure that they get 2679 forwarded. The Multimedia Streaming service class SHOULD be 2680 configured to use Rate Queuing system for AF32 and AF33 traffic 2681 flows, such as that defined in Section 1.4.1.2 of this document. 2682 However, AF31 MUST be designated as the DSCP for use when 2683 capacity-admission signaling has been used, such as RSVP or NSIS, to 2684 guarantee delivery through the network. AF32 and AF33 will be used 2685 for non-admitted streaming flows, as well as overflows from AF31 2686 sources that send more packets than they have negotiated bandwidth 2687 for that call. 2689 The following applications SHOULD use the Multimedia Streaming 2690 service class: 2692 o Buffered streaming audio (unicast). 2694 o Buffered streaming video (unicast). 2696 o Non-interactive Webcasts. 2698 o IP VPN service that specifies two rates and is less sensitive to 2699 delay and jitter. 2701 The following are traffic characteristics: 2703 o Variable size packets. 2705 o The higher the rate, the higher the density of large packets. 2707 o Variable rate. 2709 o Elastic flows. 2711 o Some bursting at start of flow from some applications, as well as 2712 an expected stepping up and down on the rate of the flow based on 2713 changes in resolution due to network conditions. 2715 Applications or IP end points SHOULD pre-mark their packets with 2716 DSCP values as shown below. If the end point is not capable of 2717 setting the DSCP value, then the router topologically closest to the 2718 end point SHOULD perform Multifield (MF) Classification, as defined 2719 in [RFC2475], and mark all packets as AF3x. Note: In this case, 2720 the two-rate, three-color marker will be configured to operate in 2721 Color-Blind mode. 2723 RECOMMENDED DSCP marking: 2725 o AF31 = up to specified rate "A". 2727 o AF32 = all traffic marked AF31 in excess of specified rate "A", 2728 or new AF32 traffic but below specified rate "B". 2730 o AF33 = in excess of specified rate "B". 2732 o Where "A" < "B". 2734 Note: One might expect "A" to approximate the peak rates of sum of 2735 all streaming flows, plus the sum of the mean rates and "B" to 2736 approximate the sum of the peak rates of those same two flows. 2738 RECOMMENDED conditioning performed at DiffServ network edge: 2740 o The two-rate, three-color marker SHOULD be configured to provide 2741 the behavior as defined in trTCM [RFC2698]. 2743 o If packets are marked by trusted sources or a previously trusted 2744 DiffServ domain and the color marking is to be preserved, then 2745 the two-rate, three-color marker SHOULD be configured to operate 2746 in Color-Aware mode. 2748 o If the packet marking is not trusted or the color marking is not 2749 to be preserved, then the two-rate, three-color marker SHOULD be 2750 configured to operate in Color-Blind mode. 2752 The fundamental service offered to nonadmitted "Multimedia 2753 Streaming" traffic is enhanced best-effort service with controlled 2754 rate and delay. The fundamental service offered to 2755 capacity-admitted "Multimedia Streaming" traffic is a guaranteed 2756 service using in-data-path signaling to ensure expected delivery in 2757 a reasonable manner. The service SHOULD be engineered so that AF31 2758 marked packet flows have sufficient bandwidth in the network to 2759 provide high assurance of delivery. Since the AF3x traffic is 2760 elastic and responds dynamically to packet loss, Active Queue 2761 Management [RFC2309] SHOULD be used primarily to reduce forwarding 2762 rate to the minimum assured rate at congestion points, unless AF31 2763 has had a capacity-admission signaling protocol applied to the flow, 2764 such as RSVP or NSIS. 2766 If a capacity-admission signaling protocol applied to the AF31 flow, 2767 which SHOULD be the case always, the AF31 PHB MAY be configured as 2768 another EF PHB that uses a relaxed performance parameter and a rate 2769 scheduler, in the priority queue as defined in Section 1.4.1.1 of 2770 this document. 2772 The probability of loss of AF31 traffic MUST NOT exceed the 2773 probability of loss of AF32 traffic, which in turn MUST NOT exceed 2774 the probability of loss of AF33. 2776 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 2777 specifies a target queue depth for each DSCP, and the max-threshold 2778 specifies the queue depth above which all traffic with such a DSCP 2779 is dropped or ECN marked. Thus, in this service class, the 2780 following inequality MUST hold in queue configurations: 2782 o min-threshold AF33 < max-threshold AF33 2784 o max-threshold AF33 <= min-threshold AF32 2786 o min-threshold AF32 < max-threshold AF32 2788 o max-threshold AF32 <= min-threshold AF31 2790 o min-threshold AF31 < max-threshold AF31 2792 o max-threshold AF31 <= memory assigned to the queue 2794 Note#1: this confirmation MUST be modified if AF31 has a 2795 capacity-admission signaling protocol applied to those 2796 flows, and the above will only apply to AF32 and AF33, while 2797 AF31 (theoretically) has no packet loss. 2799 Note#2: This configuration tends to drop AF33 traffic before AF32 2800 and AF32 before AF31. Note: Many other AQM algorithms exist 2801 and are used; they SHOULD be configured to achieve a similar 2802 result. 2804 4.5. Broadcast Service Class 2806 The Broadcast service class is RECOMMENDED for applications that 2807 require near-real-time packet forwarding with very low packet loss 2808 of constant rate and variable rate inelastic traffic sources that 2809 are more delay sensitive than applications using the Multimedia 2810 Streaming service class. Such applications include broadcast TV, 2811 streaming of live audio and video events, some video-on-demand 2812 applications, and video surveillance. In general, the Broadcast 2813 service class assumes that the destination end point has a dejitter 2814 buffer, for video application usually a 2 - 8 video-frame buffer (66 2815 to several hundred of milliseconds), thus expecting far less 2816 buffering before play-out than Multimedia Streaming, which can 2817 buffer in the seconds to minutes (to hours). 2819 The Broadcast service class will use two PHBs: 2821 Nonadmitted Broadcast traffic - MUST use the CS3 DSCP [RFC2474], 2822 and is for traffic that has not had any capacity admission 2823 signaling performed for that flow or session. 2825 Capacity-Admitted Broadcast traffic - MUST use the CS3-Admit DSCP 2826 [ID-DSCP], and is for traffic that has had any capacity 2827 admission signaling performed for that flow or session, e.g., 2828 RSVP [RFC2205] or NSIS [RFC4080]. 2830 The capacity-admitted Broadcast traffic operation is similar to an 2831 ATM CBR service, which has guaranteed bandwidth and which, if it 2832 stays within the negotiated rate, experiences nominal delay and no 2833 loss. 2835 Either of the above service classes can be configured as EF based by 2836 using a relaxed performance parameter and a rate scheduler. 2838 When a user/endpoint initiates a new Broadcast session (i.e., starts 2839 an Internet radio application, starts a live Internet A/V event or a 2840 camera comes online to do video-surveillance), the admission 2841 procedure should be verified within the application that triggers 2842 the flow. The newly admitted data rates will SHOULD be within the 2843 engineered capacity of the Broadcast service class within that 2844 network. The bandwidth in the core network and the number of 2845 simultaneous Broadcast sessions that can be supported SHOULD be 2846 engineered to control traffic load for this service. 2848 This service class SHOULD be configured to provide high assurance 2849 for bandwidth for CS3 marked packets to ensure that they get 2850 forwarded. The Broadcast service class SHOULD be configured to use 2851 Rate Queuing system such as that defined in Section 1.4.1.2 of this 2852 document. Note that either Broadcast PHB MAY be configured as 2853 another EF PHB, specifically CS3-Admit, that uses a relaxed 2854 performance parameter and a rate scheduler, in the priority queue as 2855 defined in Section 1.4.1.1 of this document. 2857 The following applications SHOULD use the Broadcast service class: 2859 o Video surveillance and security (unicast). 2861 o TV broadcast including HDTV (likely multicast, but can be 2862 unicast). 2864 o Video on demand (unicast) with control (virtual DVD). 2866 o Streaming of live audio events (both unicast and multicast). 2868 o Streaming of live video events (both unicast and multicast). 2870 The following are traffic characteristics: 2872 o Variable size packets. 2874 o The higher the rate, the higher the density of large packets. 2876 o Mixture of variable rate and constant rate flows. 2878 o Fixed packet emission time intervals. 2880 o Inelastic flows. 2882 RECOMMENDED DSCP marking: 2884 o All non-admitted flows in this service class are marked with CS3 2885 (Class Selector 3). 2887 o All capacity-admitted flows in this service class are marked with 2888 CS3-Admit. 2890 o In some cases, such as those for security and video surveillance 2891 applications, it is NOT RECOMMENDED, but allowed to use a 2892 different DSCP marking. 2894 If so, then locally user definable (EXP/LU) codepoints in the 2895 range '011x11' MAY be used to provide unique traffic 2896 identification. The locally administrator definable (EXP/LU, 2897 from pool 2 of RFC 2474) codepoint(s) MAY be associated with the 2898 PHB that is used for CS3 or CS3-Admit traffic. Furthermore, 2899 depending on the network scenario, additional network edge 2900 conditioning policy MAY be needed for the EXP/LU codepoint(s) 2901 used. 2903 Applications or IP end points SHOULD pre-mark their packets with CS3 2904 or CS3-Admit DSCP value. If the end point is not capable of setting 2905 the DSCP value, then the router topologically closest to the end 2906 point SHOULD perform Multifield (MF) Classification, as defined in 2907 [RFC2475]. 2909 RECOMMENDED conditioning performed at DiffServ network edge: 2911 o Packet flow marking (DSCP setting) from untrusted sources (end 2912 user devices) SHOULD be verified at ingress to DiffServ network 2913 using Multifield (MF) Classification methods defined in 2914 [RFC2475]. 2916 o Packet flows from untrusted sources (end user devices) SHOULD be 2917 policed at ingress to DiffServ network, e.g., using single rate 2918 with burst size token bucket policer to ensure that the traffic 2919 stays within its negotiated or engineered bounds. 2921 o Packet flows from trusted sources (application servers inside 2922 administered network) MAY not require policing. 2924 o Policing of packet flows across peering points MUST be performed 2925 to the Service Level Agreement (SLA) of those peering entities. 2927 The fundamental service offered to "Broadcast" traffic is enhanced 2928 best-effort service with controlled rate and delay. The fundamental 2929 service offered to capacity-admitted "Broadcast" traffic is a 2930 guaranteed service using in-data-path signaling to ensure expected 2931 or timely delivery. Capacity-admitted Broadcast service SHOULD NOT 2932 result in packet loss. The service SHOULD be engineered so that CS3 2933 and CS3-Admit marked packet flows have sufficient bandwidth in the 2934 network to provide high assurance of delivery. Normally, traffic in 2935 this service class does not respond dynamically to packet loss. As 2936 such, Active Queue Management [RFC2309] SHOULD NOT be applied to 2937 CS3 marked packet flows. 2939 4.6. Low-Latency Data Service Class 2941 The Low-Latency Data service class is RECOMMENDED for elastic and 2942 responsive typically client-/server-based applications. 2943 Applications forwarded by this service class are those that require 2944 a relatively fast response and typically have asymmetrical bandwidth 2945 need, i.e., the client typically sends a short message to the server 2946 and the server responds with a much larger data flow back to the 2947 client. The most common example of this is when a user clicks a 2948 hyperlink (~ few dozen bytes) on a web page, resulting in a new web 2949 page to be loaded (Kbytes or MBs of data). This service class is 2950 configured to provide good response for TCP [RFC1633] short-lived 2951 flows that require real-time packet forwarding of variable rate 2952 traffic sources. 2954 The Low-Latency Data service class SHOULD use the Assured Forwarding 2955 (AF) PHB, defined in [RFC2597]. This service class SHOULD be 2956 configured to provide a minimum bandwidth assurance for AF21, AF22, 2957 and AF23 marked packets to ensure that they get forwarded. The 2958 Low-Latency Data service class SHOULD be configured to use a Rate 2959 Queuing system such as that defined in Section 1.4.1.2 of this 2960 document. 2962 The following applications SHOULD use the Low-Latency Data service 2963 class: 2965 o Client/server applications. 2967 o Systems Network Architecture (SNA) terminal to host transactions 2968 (SNA over IP using Data Link Switching (DLSw)). 2970 o Web-based transactions (E-commerce). 2972 o Credit card transactions. 2974 o Financial wire transfers. 2976 o Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN). 2978 o VPN service that supports Committed Information Rate (CIR) with 2979 up to two burst sizes. 2981 o Instant Messaging and Presence protocols (e.g., SIP, XMPP). 2983 The following are traffic characteristics: 2985 o Variable size packets. 2987 o Variable packet emission rate. 2989 o With packet bursts of TCP window size. 2991 o Short traffic bursts. 2993 o Source capable of reducing its transmission rate based on 2994 detection of packet loss at the receiver or through explicit 2995 congestion notification. 2997 Applications or IP end points SHOULD pre-mark their packets with 2998 DSCP values as shown below. If the end point is not capable of 2999 setting the DSCP value, then the router topologically closest to the 3000 end point SHOULD perform Multifield (MF) Classification, as defined 3001 in [RFC2475] and mark all packets as AF2x. Note: In this case, the 3002 single-rate, three-color marker will be configured to operate in 3003 Color-Blind mode. 3005 RECOMMENDED DSCP marking: 3007 o AF21 = flow stream with packet burst size up to "A" bytes. 3009 o AF22 = flow stream with packet burst size in excess of "A" but 3010 below "B" bytes. 3012 o AF23 = flow stream with packet burst size in excess of "B" bytes. 3014 o Where "A" < "B". 3016 RECOMMENDED conditioning performed at DiffServ network edge: 3018 o The single-rate, three-color marker SHOULD be configured to 3019 provide the behavior as defined in srTCM [RFC2697]. 3021 o If packets are marked by trusted sources or a previously trusted 3022 DiffServ domain and the color marking is to be preserved, then 3023 the single-rate, three-color marker SHOULD be configured to 3024 operate in Color-Aware mode. 3026 o If the packet marking is not trusted or the color marking is 3027 not to be preserved, then the single-rate, three-color marker 3028 SHOULD be configured to operate in Color-Blind mode. 3030 The fundamental service offered to "Low-Latency Data" traffic is 3031 enhanced best-effort service with controlled rate and delay. The 3032 service SHOULD be engineered so that AF21 marked packet flows have 3033 sufficient bandwidth in the network to provide high assurance of 3034 delivery. Since the AF2x traffic is elastic and responds 3035 dynamically to packet loss, Active Queue Management [RFC2309] SHOULD 3036 be used primarily to control TCP flow rates at congestion points by 3037 dropping packets from TCP flows that have large burst size. The 3038 probability of loss of AF21 traffic MUST NOT exceed the probability 3039 of loss of AF22 traffic, which in turn MUST NOT exceed the 3040 probability of loss of AF23. Explicit Congestion Notification (ECN) 3041 [RFC3168] MAY also be used with Active Queue Management. 3043 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3044 specifies a target queue depth for each DSCP, and the max-threshold 3045 specifies the queue depth above which all traffic with such a DSCP 3046 is dropped or ECN marked. Thus, in this service class, the 3047 following inequality should hold in queue configurations: 3049 o min-threshold AF23 < max-threshold AF23 3051 o max-threshold AF23 <= min-threshold AF22 3053 o min-threshold AF22 < max-threshold AF22 3055 o max-threshold AF22 <= min-threshold AF21 3057 o min-threshold AF21 < max-threshold AF21 3059 o max-threshold AF21 <= memory assigned to the queue 3061 Note: This configuration tends to drop AF23 traffic before AF22 and 3062 AF22 before AF21. Many other AQM algorithms exist and are 3063 used; they should be configured to achieve a similar result. 3065 4.7. Conversational Signaling Service Class 3067 The Signaling service class is MUST be limited to delay-sensitive 3068 signaling traffic only, and then only applying to signaling that 3069 involves the Conversational service group. Audio signaling includes 3070 signaling between IP phone and soft-switch, soft-client and 3071 soft-switch, and media gateway and soft-switch as well as 3072 peer-to-peer using various protocols. Video and Hi-Res signaling 3073 includes video endpoint to video endpoint, as well as to Media 3074 transfer Point (MTP), to call control server(S), etc. This service 3075 class is intended to be used for control of voice and video sessions 3076 and applications. Protocols using this service class require a 3077 relatively fast response, as there are typically several messages of 3078 different sizes sent for control of the session. This service class 3079 is configured to provide good response for short-lived, intermittent 3080 flows that require real-time packet forwarding. This is not the 3081 service class for Instant Messaging (IM), that's within the bounds 3082 of the Low-Latency Data service class. The Conversational Signaling 3083 service class MUST be configured so that the probability of packet 3084 drop or significant queuing delay under peak load is very low in IP 3085 network segments that provide this interface. 3087 The Conversational Signaling service class MUST use the new A/V-Sig 3088 PHB, defined in [ID-DSCP]. This service class MUST be configured to 3089 provide a minimum bandwidth assurance for A/V-Sig marked packets to 3090 ensure that they get forwarded. In other words, this service class 3091 MUST NOT be starved from transmission within a reasonable timeframe, 3092 given that the entire Conversational service group depends on these 3093 signaling messages successful delivery. Network engineering SHOULD 3094 be done to ensure there is roughly 1-4% available per node interface 3095 that audio and video traverse. Local conditions MUST be considered 3096 when determining exactly how much bandwidth is given to this service 3097 class. The Conversational Signaling service class SHOULD be 3098 configured to use a Rate Queuing system such as that defined in 3099 Section 1.4.1.2 of this document. 3101 The following applications SHOULD use the Conversational Signaling 3102 service class: 3104 o Peer-to-peer IP telephony signaling (e.g., SIP, H.323, XMPP). 3106 o Peer-to-peer signaling for multimedia applications (e.g., SIP, 3107 H.323, XMPP). 3109 o Peer-to-peer real-time control function. 3111 o Client-server IP telephony signaling using H.248, MEGACO, MGCP, 3112 IP encapsulated ISDN, or other proprietary protocols. 3114 o Signaling to control IPTV applications using protocols such as 3115 IGMP. 3117 o Signaling flows between high-capacity telephony call servers or 3118 soft switches using protocol such as SIP-T. Such high-capacity 3119 devices may control thousands of telephony (VoIP) calls. 3121 o Signaling for one-way video flows, such as RTSP [RFC2326]. 3123 o IGMP, when used for multicast session control such as channel 3124 changing in IPTV systems. 3126 o OPTIONALLY, this service class can be used for on-path 3127 reservation signaling for the traffic flows that will use the 3128 "admitted" DSCPs. The alternative is to have the on-path 3129 signaling (for reservations) use the DSCP within that service 3130 class. This provides a similar treatment of the signaling to the 3131 data flow, which might be desired. 3133 The following are traffic characteristics: 3135 o Variable size packets, normally one packet at a time. 3137 o Intermittent traffic flows. 3139 o Traffic may burst at times. 3141 o Delay-sensitive control messages sent between two end points. 3143 RECOMMENDED DSCP marking: 3145 o All flows in this service class are marked with A/V-Sig. 3147 Applications or IP end points SHOULD pre-mark their packets with 3148 A/V-Sig DSCP value. If the end point is not capable of setting the 3149 DSCP value, then the router topologically closest to the end point 3150 SHOULD perform Multifield (MF) Classification, as defined in 3151 [RFC2475]. 3153 RECOMMENDED conditioning performed at DiffServ network edge: 3155 o Packet flow marking (DSCP setting) from untrusted sources (end 3156 user devices) SHOULD be verified at ingress to DiffServ network 3157 using Multifield (MF) Classification methods defined in 3158 [RFC2475]. 3160 o Packet flows from untrusted sources (end user devices) SHOULD be 3161 policed at ingress to DiffServ network, e.g., using single rate 3162 with burst size token bucket policer to ensure that the traffic 3163 stays within its negotiated or engineered bounds. 3165 o Packet flows from trusted sources (application servers inside 3166 administered network) MAY not require policing. 3168 o Policing of packet flows across peering points in which each peer 3169 is participating in the call set-up MUST be performed to the 3170 Service Level Agreement (SLA). 3172 The fundamental service offered to "Conversational Signaling" 3173 traffic is enhanced best-effort service with controlled rate and 3174 delay. The service SHOULD be engineered so that A/V-Sig marked 3175 packet flows have sufficient bandwidth in the network to provide 3176 high assurance of delivery and low delay. Normally, traffic in this 3177 service class does not respond dynamically to packet loss. As such, 3178 Active Queue Management [RFC2309] SHOULD NOT be applied to A/V-Sig 3179 marked packet flows. 3181 4.8. High-Throughput Data Service Class 3183 The High-Throughput Data service class is RECOMMENDED for elastic 3184 applications that require timely packet forwarding of variable rate 3185 traffic sources and, more specifically, is configured to provide 3186 good throughput for TCP longer-lived flows. TCP [RFC1633] or a 3187 transport with a consistent Congestion Avoidance Procedure [RFC2581] 3188 [RFC3782] normally will drive as high a data rate as it can obtain 3189 over a long period of time. The FTP protocol is a common example, 3190 although one cannot definitively say that all FTP transfers are 3191 moving data in bulk. 3193 The High-Throughput Data service class SHOULD use the Assured 3194 Forwarding (AF) PHB, defined in [RFC2597]. This service class 3195 SHOULD be configured to provide a minimum bandwidth assurance for 3196 AF11, AF12, and AF13 marked packets to ensure that they are 3197 forwarded in a timely manner. The High-Throughput Data service 3198 class SHOULD be configured to use a Rate Queuing system such as that 3199 defined in Section 1.4.1.2 of this document. 3201 The following applications SHOULD use the High-Throughput Data 3202 service class: 3204 o Store and forward applications. 3206 o File transfer applications (e.g., FTP, HTTP, etc). 3208 o Email. 3210 o VPN service that supports two rates (committed information rate 3211 and excess or peak information rate). 3213 The following are traffic characteristics: 3215 o Variable size packets. 3217 o Variable packet emission rate. 3219 o Variable rate. 3221 o With packet bursts of TCP window size. 3223 o Source capable of reducing its transmission rate based on 3224 detection of packet loss at the receiver or through explicit 3225 congestion notification. 3227 Applications or IP end points SHOULD pre-mark their packets with 3228 DSCP values as shown below. If the end point is not capable of 3229 setting the DSCP value, then the router topologically closest to the 3230 end point SHOULD perform Multifield (MF) Classification, as defined 3231 in [RFC2475], and mark all packets as AF1x. Note: In this case, the 3232 two-rate, three-color marker will be configured to operate in 3233 Color-Blind mode. 3235 RECOMMENDED DSCP marking: 3237 o AF11 = up to specified rate "A". 3239 o AF12 = in excess of specified rate "A" but below specified rate 3240 "B". 3242 o AF13 = in excess of specified rate "B". 3244 o Where "A" < "B". 3246 RECOMMENDED conditioning performed at DiffServ network edge: 3248 o The two-rate, three-color marker SHOULD be configured to provide 3249 the behavior as defined in trTCM [RFC2698]. 3251 o If packets are marked by trusted sources or a previously trusted 3252 DiffServ domain and the color marking is to be preserved, then 3253 the two-rate, three-color marker SHOULD be configured to operate 3254 in Color-Aware mode. 3256 o If the packet marking is not trusted or the color marking is not 3257 to be preserved, then the two-rate, three-color marker SHOULD be 3258 configured to operate in Color-Blind mode. 3260 The fundamental service offered to "High-Throughput Data" traffic is 3261 enhanced best-effort service with a specified minimum rate. The 3262 service SHOULD be engineered so that AF11 marked packet flows have 3263 sufficient bandwidth in the network to provide assured delivery. It 3264 can be assumed that this class will consume any available bandwidth 3265 and that packets traversing congested links may experience higher 3266 queuing delays or packet loss. Since the AF1x traffic is elastic 3267 and responds dynamically to packet loss, Active Queue Management 3268 [RFC2309] SHOULD be used primarily to control TCP flow rates at 3269 congestion points by dropping packets from TCP flows that have 3270 higher rates first. The probability of loss of AF11 traffic MUST 3271 NOT exceed the probability of loss of AF12 traffic, which in turn 3272 MUST NOT exceed the probability of loss of AF13. In such a case, if 3273 one network customer is driving significant excess and another seeks 3274 to use the link, any losses will be experienced by the high-rate 3275 user, causing him to reduce his rate. Explicit Congestion 3276 Notification (ECN) [RFC3168] MAY also be used with Active Queue 3277 Management. 3279 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3280 specifies a target queue depth for each DSCP, and the max-threshold 3281 specifies the queue depth above which all traffic with such a DSCP 3282 is dropped or ECN marked. Thus, in this service class, the 3283 following inequality should hold in queue configurations: 3285 o min-threshold AF13 < max-threshold AF13 3287 o max-threshold AF13 <= min-threshold AF12 3289 o min-threshold AF12 < max-threshold AF12 3291 o max-threshold AF12 <= min-threshold AF11 3293 o min-threshold AF11 < max-threshold AF11 3295 o max-threshold AF11 <= memory assigned to the queue 3297 Note: This configuration tends to drop AF13 traffic before AF12 and 3298 AF12 before AF11. Many other AQM algorithms exist and are 3299 used; they should be configured to achieve a similar result. 3301 4.9. Standard Service Class 3303 The Standard service class is RECOMMENDED for traffic that has not 3304 been classified into one of the other supported forwarding service 3305 classes in the DiffServ network domain. This service class provides 3306 the Internet's "best-effort" forwarding behavior. This service 3307 class typically has minimum bandwidth guarantee. 3309 The Standard service class MUST use the Default Forwarding (DF) PHB, 3310 defined in [RFC2474], and SHOULD be configured to receive at least a 3311 small percentage of forwarding resources as a guaranteed minimum. 3312 This service class SHOULD be configured to use a Rate Queuing system 3313 such as that defined in Section 1.4.1.2 of this document. 3315 The following applications SHOULD use the Standard service class: 3317 o Network services, DNS, DHCP, BootP. 3319 o Any undifferentiated application/packet flow transported through 3320 the DiffServ enabled network. 3322 The following is a traffic characteristic: 3324 o Non-deterministic, mixture of everything. 3326 The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000'. 3328 Network Edge Conditioning: 3330 There is no requirement that conditioning of packet flows be 3331 performed for this service class. 3333 The fundamental service offered to the Standard service class is 3334 best-effort service with active queue management to limit overall 3335 delay. Typical configurations SHOULD use random packet dropping to 3336 implement Active Queue Management [RFC2309] or Explicit Congestion 3337 Notification [RFC3168], and MAY impose a minimum or maximum rate on 3338 the queue. 3340 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3341 specifies a target queue depth, and the max-threshold specifies the 3342 queue depth above which all traffic is dropped or ECN marked. Thus, 3343 in this service class, the following inequality should hold in queue 3344 configurations: 3346 o min-threshold DF < max-threshold DF 3348 o max-threshold DF <= memory assigned to the queue 3349 Note: Many other AQM algorithms exist and are used; they should be 3350 configured to achieve a similar result. 3352 4.10. Low-Priority Data 3354 The Low-Priority Data service class serves applications that run 3355 over TCP [RFC0793] or a transport with consistent congestion 3356 avoidance procedures [RFC2581] [RFC3782] and that the user is 3357 willing to accept service without guarantees. This service class is 3358 specified in [RFC3662] and [QBSS]. 3360 The following applications MAY use the Low-Priority Data service 3361 class: 3363 o Any TCP based-application/packet flow transported through the 3364 DiffServ enabled network that does not require any bandwidth 3365 assurances. 3367 The following is a traffic characteristic: 3369 o Non-real-time and elastic. 3371 Network Edge Conditioning: 3373 There is no requirement that conditioning of packet flows be 3374 performed for this service class. 3376 The RECOMMENDED DSCP marking is CS1 (Class Selector 1). 3378 The fundamental service offered to the Low-Priority Data service 3379 class is best-effort service with zero bandwidth assurance. By 3380 placing it into a separate queue or class, it may be treated in a 3381 manner consistent with a specific Service Level Agreement. 3383 Typical configurations SHOULD use Explicit Congestion Notification 3384 [RFC3168] or random loss to implement Active Queue Management 3385 [RFC2309]. 3387 If RED [RFC2309] is used as an AQM algorithm, the min-threshold 3388 specifies a target queue depth, and the max-threshold specifies the 3389 queue depth above which all traffic is dropped or ECN marked. Thus, 3390 in this service class, the following inequality should hold in queue 3391 configurations: 3393 o min-threshold CS1 < max-threshold CS1 3395 o max-threshold CS1 <= memory assigned to the queue 3397 Note: Many other AQM algorithms exist and are used; they should be 3398 configured to achieve a similar result. 3400 5. Additional Information on Service Class Usage 3402 In this section, we provide additional information on how some 3403 specific applications should be configured to use the defined 3404 service classes. 3406 5.1. Mapping for NTP 3408 From tests that were performed, indications are that precise time 3409 distribution requires a very low packet delay variation (jitter) 3410 transport. Therefore, we suggest that the following guidelines for 3411 Network Time Protocol (NTP) be used: 3413 o When NTP is used for providing high-accuracy timing within an 3414 administrator's (carrier's) network or to end users/clients, the 3415 audio service class SHOULD be used, and NTP packets should be 3416 marked with EF DSCP value. 3418 o For applications that require "wall clock" timing accuracy, the 3419 Standard service class should be used, and packets should be 3420 marked with DF DSCP. 3422 5.2. VPN Service Mapping 3424 "Differentiated Services and Tunnels" [RFC2983] considers the 3425 interaction of DiffServ architecture with IP tunnels of various 3426 forms. Further to guidelines provided in RFC 2983, below are 3427 additional guidelines for mapping service classes that are supported 3428 in one part of the network into a VPN connection. This discussion 3429 is limited to VPNs that use DiffServ technology for traffic 3430 differentiation. 3432 o The DSCP value(s) that is/are used to represent a PHB or a PHB 3433 group SHOULD be the same for the networks at both ends of the VPN 3434 tunnel, unless remarking of DSCP is done as ingress/egress 3435 processing function of the tunnel. DSCP marking needs to be 3436 preserved along the tunnel, end to end. 3438 o The VPN MAY be configured to support one or more service classes. 3439 It is left up to the administrators of the two networks to agree 3440 on the level of traffic differentiation that will be provided in 3441 the network that supports VPN service. Service classes are then 3442 mapped into the supported VPN traffic forwarding behaviors that 3443 meet the traffic characteristics and performance requirements of 3444 the encapsulated service classes. 3446 o The traffic treatment in the network that is providing the VPN 3447 service needs to be such that the encapsulated service class or 3448 classes receive comparable behavior and performance in terms of 3449 delay, jitter, and packet loss and that they are within the 3450 limits of the service specified. 3452 o The DSCP value in the external header of the packet forwarded 3453 through the network providing the VPN service can be different 3454 from the DSCP value that is used end to end for service 3455 differentiation in the end network. 3457 o The guidelines for aggregation of two or more service classes 3458 into a single traffic forwarding treatment in the network that is 3459 providing the VPN service is for further study. 3461 6. Security Considerations 3463 This document discusses policy and describes a common policy 3464 configuration, for the use of a Differentiated Services Code Point 3465 by transports and applications. If implemented as described, it 3466 should require that the network do nothing that the network has not 3467 already allowed. If that is the case, no new security issues should 3468 arise from the use of such a policy. 3470 It is possible for the policy to be applied incorrectly, or for a 3471 wrong policy to be applied in the network for the defined service 3472 class. In that case, a policy issue exists that the network SHOULD 3473 detect, assess, and deal with. This is a known security issue in 3474 any network dependent on policy-directed behavior. 3476 A well-known flaw appears when bandwidth is reserved or enabled for 3477 a service (for example, voice and/or video transport) and another 3478 service or an attacking traffic stream uses it. This possibility is 3479 inherent in DiffServ technology, which depends on appropriate packet 3480 markings. When bandwidth reservation or a priority queuing system is 3481 used in a vulnerable network, the use of authentication and flow 3482 admission is recommended. To the author's knowledge, there is no 3483 known technical way to respond to an unauthenticated data stream 3484 using service that it is not intended to use, and such is the nature 3485 of the Internet. 3487 The use of a service class by a user is not an issue when the SLA 3488 between the user and the network permits him to use it, or to use it 3489 up to a stated rate. In such cases, simple policing is used in the 3490 Differentiated Services Architecture. Some service classes, such as 3491 Network Control, are not permitted to be used by users at all; such 3492 traffic should be dropped or remarked by ingress filters. Where 3493 service classes are available under the SLA only to an authenticated 3494 user rather than to the entire population of users, authentication 3495 and authorization services are required, such as those surveyed in 3496 [AUTHMECH]. 3498 7. Contributing Authors 3500 This section specifically calls out the authors of RFC 4594, from 3501 which this document is based on. 3503 Jozef Babiarz 3504 Nortel Networks 3506 Kwok Ho Chan 3507 Nortel Networks 3508 Email: khchan.work@gmail.com 3510 Fred Baker 3511 Cisco Systems 3512 EMail: fred@cisco.com 3514 Of note, two of the three mentioned authors above worked for Nortel 3515 Networks at the time of writing RFC 4594, a company that no longer 3516 exists. This author has not seen or heard from those two in many, 3517 many years or IETF meetings - as a result of not knowing their new 3518 email addresses (or phone numbers). 3520 While much of this document has been rewritten with either edited or 3521 brand new material, there are many short paragraphs that remain as 3522 they were from RFC 4594, as well as many sentences that were also 3523 left unchanged. Additionally, there were no new graphs, charts, 3524 diagrams, or tables introduced, meaning the first 4 tables within 3525 this document existed in RFC 4594, created by those authors. 3526 Presently, each of those tables contain modified and new 3527 information. The last 3 tables, specifically tables 5, 6, & 7 were 3528 removed because the examples section was removed. 3530 This author believes there must be proper credit given for all the 3531 contributions, including the framework this document retains from 3532 that RFC. Periodically, throughout this document, what was written 3533 remains the best way of conveying a thought, rule, or otherwise 3534 stated behavior or mechanism. Because RFC 4594 was rather large, 3535 there is no realistic way of identifying each part that was left 3536 untouched. Further, properly quoting that RFC and leaving those 3537 sentences embedded in this document would render this document 3538 highly unreadable. Another application could be used to show the 3539 changes, deletions and additions - but not one that the IETF accepts 3540 presently. 3542 This author has created this "Contributing Authors" section as a way 3543 of properly identifying those 3 individuals that provided text 3544 within this document. We will let the community judge if this is 3545 'good enough' (i.e., rough consensus), or if another way is better. 3547 8. Acknowledgements 3549 The author would like to thank Paul Jones, Glen Lavers, Mo Zanaty, 3550 David Benham, Michael Ramalho, Gorry Fairhurst, David Black, Brian 3551 Carpenter, Al Morton, Ruediger Geib and Shitanshu Shah for their 3552 comments and questions about this effort that ultimately helped 3553 shape this document. 3555 Below are the folks that were acknowledged in RFC 4594, and this 3556 author does not want to lose their recognition of contributions to 3557 the original effort. 3559 "The authors thank the TSVWG reviewers, David Black, Brian E. 3560 Carpenter, and Alan O'Neill for their review and input to this 3561 document. 3563 The authors acknowledge a great many inputs, most notably from 3564 Bruce Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois 3565 Audet, Morgan Littlewood, Robert Milne, John Shuler, Nalin 3566 Mistry, Al Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil 3567 Dickinson, Mike Fidler, and Shane Amante. Kimberly King, Joe 3568 Zebarth, and Alistair Munroe each did a thorough proofreading, 3569 and the document is better for their contributions." 3571 9. References 3573 9.1. Normative References 3575 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3576 September 1981. 3578 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 3579 793, September 1981. 3581 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 3582 Suite", RFC 1349, July 1992. 3584 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 3585 1812, June 1995. 3587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3588 Requirement Levels", BCP 14, RFC 2119, March 1997. 3590 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 3591 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 3592 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 3593 S., Wroclawski, J., and L. Zhang, "Recommendations on 3594 Queue Management and Congestion Avoidance in the 3595 Internet", RFC 2309, April 1998. 3597 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3598 "Definition of the Differentiated Services Field (DS 3599 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 3600 1998. 3602 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 3603 and W. Weiss, "An Architecture for Differentiated 3604 Service", RFC 2475, December 1998. 3606 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 3607 "Assured Forwarding PHB Group", RFC 2597, June 1999. 3609 [RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le 3610 Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. 3611 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 3612 Behavior)", RFC 3246, March 2002. 3614 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 3615 Jacobson, "RTP: A Transport Protocol for Real-Time 3616 Applications", STD 64, RFC 3550, July 2003. 3618 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 3619 Per-Domain Behavior (PDB) for Differentiated Services", 3620 RFC 3662, December 2003. 3622 [RFC5865] F. Baker, J. Polk, M. Dolly, "A Differentiated Services Code 3623 Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, 3624 May 2010 3626 9.2. Informative References 3628 [AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms", 3629 Work in Progress, September 2005. 3631 [QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2 3632 Technical Report Proposed Service Definition, March 2001. 3634 [IEEE1Q] IEEE, 802.1Q Specification 3636 [IEEE1E] IEEE, 802.1E Wireless LAN User Priority Specification 3638 [RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated 3639 Services in the Internet Architecture: an Overview", RFC 3640 1633, June 1994. 3642 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 3643 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 3644 Functional Specification", RFC 2205, September 1997. 3646 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 3647 Control", RFC 2581, April 1999. 3649 [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color 3650 Marker", RFC 2697, September 1999. 3652 [RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color 3653 Marker", RFC 2698, September 1999. 3655 [RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive 3656 Shaper for Differentiated Services", RFC 2963, October 3657 2000. 3659 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 3660 2983, October 2000. 3662 [RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, 3663 November 2000. 3665 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 3666 Differentiated Services Per Domain Behaviors and Rules 3667 for their Specification", RFC 3086, April 2001. 3669 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3670 of Explicit Congestion Notification (ECN) to IP", RFC 3671 3168, September 2001. 3673 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 3674 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3675 3175, September 2001. 3677 [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An 3678 Informal Management Model for Diffserv Routers", RFC 3290, 3679 May 2002. 3681 [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno 3682 Modification to TCP's Fast Recovery Algorithm", RFC 3782, 3683 April 2004. 3685 [RFC5462] L. Andersson, R. Asati, "Multiprotocol Label Switching 3686 (MPLS) Label Stack Entry: EXP Field Renamed to Traffic Class 3687 Field", RFC 5462, February 2009 3689 Authors' Address 3691 James Polk 3692 3913 Treemont Circle 3693 Colleyville, Texas 76034 3695 Phone: +1.817.271.3552 3696 Email: jmpolk@cisco.com 3698 Appendix A - Changes 3700 Here is a list of all the changes that were captured during the 3701 editing process. This will not be a complete list, and others are 3702 free to point out what the authors missed, and we'll include that in 3703 the next release. 3705 A.1 Since Individual -01 to -02 3707 o Added text to the Intro section on the justification from 3708 DiffServ Problem Statement draft, as to more of why this update 3709 is necessary. 3711 o Added text to the Intro section expanding on the concept of 3712 service classes vs. treatment aggregates (from RFC 5127). 3714 A.2 Since Individual -00 to -01 3716 o Added Section 2.4 which covers the conflation issues regarding 3717 the differences between service classes and treatment aggregates. 3719 o Added example operational configurations of treatment aggregates 3720 applied to this draft's new set of service classes and additional 3721 DSCPs. 3723 o Added references RFC 5865, RFC 5462, IEEE 802.1E and IEEE 802.1Q. 3725 A.3 Since RFC 4594 to Individual Update -00 3727 o rewrote Intro to emphasize current topics 3729 o Created a Conversational Service group, comprising the audio, 3730 video and Hi-Res service classes - because they have similar 3731 characteristics. 3733 o Incorporated the 6 new DSCPs from [ID-DSCP]. 3735 o moved the example section, en mass, to an appendix that might not 3736 be kept for this version. We're not sure it accomplishes what it 3737 needs to, and might not provide any real usefulness. 3739 o Moved 'Realtime-Interactive' service class to CS5, from CS4 3741 o Changed 'Broadcast Video' service class to 'Broadcast' service 3742 class 3744 o Changed AF4X to 'Video' service class, replacing 'Multimedia 3745 Conferencing' service class 3747 o Moved 'Multimedia Conferencing' service class to different DSCPs 3749 o Added the 'Hi-Res' service class 3751 o Removed section 5.1 on signaling choices. It has been included in 3752 the main body of the text. 3754 o Changed document title 3756 o ...