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