idnits 2.17.1 draft-baker-diffserv-basic-classes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 2003) is 7471 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) -- Looks like a reference, but probably isn't: 'RFC-2119' on line 51 -- Looks like a reference, but probably isn't: 'RFC 1812' on line 400 -- Looks like a reference, but probably isn't: 'RFC 791' on line 407 == Unused Reference: '3' is defined on line 1520, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1553, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1567, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1585, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1589, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1594, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 1612, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 1615, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (ref. '1') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '2') ** Obsolete normative reference: RFC 2309 (ref. '6') (Obsoleted by RFC 7567) ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '8') ** Obsolete normative reference: RFC 2581 (ref. '9') (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2582 (ref. '10') (Obsoleted by RFC 3782) ** Downref: Normative reference to an Informational RFC: RFC 2697 (ref. '17') ** Downref: Normative reference to an Informational RFC: RFC 2698 (ref. '18') -- Possible downref: Non-RFC (?) normative reference: ref. '20' Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Fred Baker 2 draft-baker-diffserv-basic-classes-01.txt Cisco 3 Expires: April 2004 Jozef Babiarz 4 Kwok Ho Chan 5 Nortel Networks 6 October 2003 8 Configuration Guidelines for DiffServ 9 Service Classes 11 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This paper summarizes the recommended correlation between service 39 classes and their usage, with references to their corresponding 40 recommended Differentiated Service Code Points (DSCP), traffic 41 conditioners, Per-Hop Behaviors (PHB) and Active Queue Management 42 (AQM) mechanisms. There is no intrinsic requirement that particular 43 DSCPs, traffic conditioner PHBs and AQM be used for a certain 44 service class, but as a policy it is useful that they be applied 45 consistently across the network. 47 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 49 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 50 in this document are to be interpreted as described in [RFC-2119]. 52 Table of Contents 54 1. Introduction....................................................3 55 1.1 Expected use in the Network....................................3 56 1.2 Key Differentiated Services Concepts...........................4 57 1.2.1 Queuing......................................................4 58 1.2.1.1 Priority Queuing...........................................4 59 1.2.1.2 Rate Queuing...............................................4 60 1.2.2 Active Queue Management......................................5 61 1.2.3 Traffic Conditioning.........................................5 62 1.2.4 Differentiated Services Code Point (DSCP)....................6 63 1.2.5 Per-Hop Behavior (PHB).......................................6 64 1.3 Key Service Concepts...........................................6 65 1.3.1 Default Forwarding (DF)......................................7 66 1.3.2 Assured Forwarding (AF)......................................8 67 1.3.3 Expedited Forwarding (EF)....................................8 68 1.3.4 Class Selector (CS)..........................................9 69 1.3.5 Admission Control............................................9 70 1.3.6 Service Differentiation.....................................10 71 2. Traffic Categories and Service Classes.........................10 72 3. Network Control Traffic Category...............................14 73 3.1 Administration Service Class..................................14 74 3.2 Network Control Service Class.................................15 75 4. User Traffic Categories........................................16 76 4.1 Interactive Traffic Category..................................17 77 4.1.1 Telephony Service Class.....................................17 78 4.1.2 Multimedia Conferencing Service Class.......................20 79 4.2 Responsive Traffic Category...................................22 80 4.2.1 Multimedia Streaming Service Class..........................22 81 4.2.2 Low Latency Data Service Class..............................24 82 4.3 Timely Traffic Category.......................................26 83 4.3.1 High Throughput Data Service Class..........................26 84 4.3.2 Standard Service Class......................................28 85 4.4 Non-Critical Traffic Category.................................29 86 4.4.1 Low Priority Data Service Class.............................29 87 5. Mapping Applications to Service Classes........................29 88 6. Security Considerations........................................30 89 7. Acknowledgements...............................................31 90 8. Normative References...........................................31 91 9. Informative References.........................................32 92 10. Author's Address..............................................33 93 11. Full Copyright Statement......................................34 95 1. Introduction 97 This paper summarizes the recommended correlation between service 98 classes and their usage, with references to their corresponding 99 recommended Differentiated Service Code Points (DSCP), traffic 100 conditioners, Per-Hop Behaviors (PHB) and Active Queue Management 101 (AQM) mechanisms. There is no intrinsic requirement that particular 102 DSCPs, traffic conditioner PHBs and AQM be used for a certain 103 service class, but as a policy it is useful that they be applied 104 consistently across the network. 106 Service classes are defined, based on the different traffic 107 characteristics and required performance of the 108 applications/services. This approach allows us to map current and 109 future applications/services of similar traffic characteristic and 110 performance requirements into the same service class. With this 111 approach, a limited set of service classes is required. For 112 completeness, we have defined nine different service classes, two 113 for network operation/administration and seven for user/subscriber 114 applications/services. However, we expect that network 115 administrators will selectively choose the service classes that are 116 required in their network based on their needs. 118 1.1 Expected use in the Network 120 In the Internet today, corporate LANs and ISP WANs are generally not 121 heavily utilized - they are commonly 10% utilized at most. For this 122 reason, congestion, loss, and variation in delay within corporate 123 LANs and ISP backbones is virtually unknown. This clashes with user 124 perceptions, for three very good reasons. 126 - The industry moves through cycles of bandwidth boom and 127 bandwidth bust, depending on prevailing market conditions and 128 the periodic deployment of new bandwidth-hungry applications. 130 - In access networks, the state is often different. This may be 131 because throughput rates are artificially limited, or because of 132 access network design trade-offs. 134 - Other characteristics, such as database design on web servers 135 (which may create contention points, e.g. in filestore), and 136 configuration of firewalls and routers, often look externally 137 like a bandwidth limitation. 139 The intent of this document is to provide a consistent marking, 140 conditioning and packet treatment strategy so that it can be 141 configured and put into service on any link which finds itself 142 congested. 144 1.2 Key Differentiated Services Concepts 146 The reader must be familiar with the principles of the 147 Differentiated Services Architecture [8]. However, we recapitulate 148 key concepts here so save searching. 150 1.2.1 Queuing 152 A queue is a data structure that holds traffic that is awaiting 153 transmission. The traffic may be delayed while in the queue, 154 possibly due to lack of bandwidth, or because it is low in priority. 155 There are a number of ways to implement a queue; in some of these, 156 it is more natural to discuss "service classes in a queuing system" 157 rather than "a set of queues and a scheduler". In the literature, as 158 a result, the concepts are used somewhat interchangeably. 160 A simple model of a queuing system, however, is a set of data 161 structures for packet data, which we will call queues or service 162 classes and a mechanism for selecting the next packet from among 163 them, which we call a scheduler. 165 1.2.1.1 Priority Queuing 167 A priority queuing system is a combination of a set of queues and a 168 scheduler that empties them in priority sequence. When asked for a 169 packet, the scheduler inspects the highest priority queue, and if 170 there is data present returns a packet from that queue. Failing 171 that, it inspects the next highest priority queue, and so on. A 172 freeway onramp with a stoplight for one lane, but which allows 173 vehicles in the high occupancy vehicle lane to pass, is an example 174 of a priority queuing system; the high occupancy vehicle lane 175 represents the "queue" having priority. 177 In a priority queuing system, a packet in the highest priority queue 178 will experience a readily calculated delay - it is proportional to 179 the amount of data remaining to be serialized when the packet 180 arrived plus the volume of the data already queued ahead of it in 181 the same queue. The technical reason for using a priority queue 182 relates exactly to this fact: it limits delay and variations in 183 delay, and should be used for traffic which has that requirement. 185 A priority queue or queuing system needs to support rate and burst 186 size control mechanism(s) to provide starvation avoidance of lower 187 priority queues. 189 1.2.1.2 Rate Queuing 191 Similarly, a rate-based queuing system is a combination of a set of 192 queues and a scheduler that empties each at a specified rate. An 193 example of a rate based queuing system is a road intersection with a 194 stoplight - the stoplight acts as a scheduler, giving each lane a 195 certain opportunity to pass traffic through the intersection. 197 In a rate-based queuing system, such as WFQ[27][26] or WRR[28], the 198 delay that a packet in any given queue will experience is dependant 199 on the parameters and occupancy of its queue and the parameters and 200 occupancy of the queues it is competing with. A queue whose traffic 201 arrival rate is much less than the rate at which it lets traffic 202 depart will tend to be empty and packets in it will experience 203 nominal delays. A queue whose traffic arrival rate approximates or 204 exceeds its departure rate will tend to be not empty, and packets in 205 it will experience greater delay. Such a scheduler can impose a 206 minimum rate, a maximum rate, or both, on any queue it touches. 208 1.2.2 Active Queue Management 210 "Active queue management" or AQM is a generic name for any of a 211 variety of procedures that use packet dropping or marking to manage 212 the depth of a queue. The canonical example of such a procedure is 213 Random Early Detection [25], in which a queue is assigned a minimum 214 and maximum threshold, and the queuing algorithm maintains a moving 215 average of the queue depth. While the mean queue depth exceeds the 216 maximum threshold, all arriving traffic is dropped. While the mean 217 queue depth exceeds the minimum threshold but not the maximum 218 threshold, a randomly selected subset of arriving traffic is marked 219 or dropped. This marking or dropping of traffic is intended to 220 communicate with the sending system, causing its congestion 221 avoidance algorithms to kick in. As a result of this behavior, it is 222 reasonable to expect that TCP's cyclic behavior is desynchronized, 223 and the mean queue depth (and therefore delay) should normally 224 approximate the minimum threshold. 226 A variation of the algorithm is applied in Assured Forwarding [11], 227 in which the behavior aggregate consists of traffic with multiple 228 DSCP marks, which are intermingled in a common queue. Different 229 minima and maxima are configured for the several DSCPs separately, 230 such that traffic which exceeds a stated rate at ingress is more 231 likely to be dropped or marked than traffic which was within its 232 contracted rate. 234 1.2.3 Traffic Conditioning 236 Additionally, at the first router in a network that a packet 237 crosses, arriving traffic may be measured, and dropped or marked 238 according to a policy, or perhaps shaped on network ingress as in A 239 Rate Adaptive Shaper for Differentiated Services [23]. This may be 240 used to bias feedback loops, such as is done in Assured Forwarding 241 [11], or to limit the amount of traffic in a system, as is done in 242 Expedited Forwarding [19]. Such measurement procedures are 243 collectively referred to as "traffic conditioners". Two traffic 244 conditioners that are use in deployment of differentiated services 245 that use Assured Forwarding are the Two Rate Three Color Marker 246 (trTCM) [18] and the Single Rate Three Color Marker (srTCM) [17]. 248 Two Rate Three Color Marker: 249 The Two Rate Three Color Marker (trTCM) meters an IP packet stream 250 and marks its packets based on two rates, Peak Information Rate 251 (PIR) and Committed Information Rate (CIR), and their associated 252 burst sizes to be green, yellow, or red. A packet is marked red if 253 it exceeds the PIR. Otherwise it is marked either yellow or green 254 depending on whether it exceeds or doesn't exceed the CIR. The 255 trTCM is use to enforce committed rate separately from Peak 256 Information Rate. 258 Single Rate Three Color Marker: 259 The Single Rate Three Color Marker (srTCM) meters an IP packet 260 stream and marks its packets green, yellow, or red. Marking is 261 based on a Committed Information Rate (CIR) and two associated 262 burst sizes, a Committed Burst Size (CBS) and an Excess Burst Size 263 (EBS). A packet is marked green if it doesn't exceed the CBS, 264 yellow if it does exceed the CBS, but not the EBS and red 265 otherwise. The srTCM is used to enforce the committed rate and 266 burst length. 268 1.2.4 Differentiated Services Code Point (DSCP) 270 The DSCP is a number in the range 0..63, which is placed into an IP 271 packet to mark it according to the class of traffic it belongs in. 272 Half of these values are earmarked for standardized services, and 273 half of them are available for local definition. 275 1.2.5 Per-Hop Behavior (PHB) 277 In the end, the mechanisms described above are combined to form a 278 specified set of characteristics for handling different kinds of 279 traffic, depending on the needs of the application. This document 280 seeks to identify useful traffic aggregates and specify what PHB 281 should be applied to them. 283 1.3 Key Service Concepts 285 While Differentiated Services is a general architecture that may be 286 used to implement a variety of services, three fundamental services 287 have been defined and characterized for general use. These are basic 288 service for elastic traffic, the Assured Forwarding service, and the 289 Expedited Forwarding service for real-time (inelastic) traffic. 291 The terms "elastic" and "real-time" are defined in RFC 1633[2] 292 section 3.1, as a way of understanding broad brush application 293 requirements. This document should be reviewed to obtain a broad 294 understanding of the issues in quality of service, just as RFC 295 2475[8] should be reviewed to understand the data plane architecture 296 used in today's Internet. 298 The definition of "service class" is, a description of the overall 299 treatment of (or a subset of) a customer's traffic across a 300 particular domain, across a set of interconnected DiffServ Domain 301 (DS) domains, or end-to-end. Service descriptions are covered by 302 administrative policy and services are constructed by applying 303 traffic conditioning to create behavior aggregates which experience 304 a known PHB at each node within the DS domain. A service class 305 provides the specified end-to-end behaviors in the network which 306 will support one or more applications or a set of applications that 307 have similar traffic characteristics and performance requirements. 308 This concept allows grouping of applications of similar traffic 309 characteristics and performance requirements into a common 310 forwarding discipline called a "service class" that provides 311 consistent behavior in the administered network. (Service class 312 definition originates from RFC 2474 [7] section 2 definition of a 313 service) 315 1.3.1 Default Forwarding (DF) 317 The basic services applied to any class of traffic are those 318 described in RFC 2474[7] and RFC 2309[6]. Best Effort Service may be 319 summarized as "I will accept your packets", with no further 320 guarantees. Packets in transit may be lost, reordered, duplicated, 321 or delayed at random. Generally, networks are engineered to limit 322 this behavior, but changing traffic loads can push any network into 323 such a state. 325 Application traffic in the internet is expected to be "elastic" in 326 nature. By this, we mean that the receiver will detect loss or 327 variation in delay in the network and provide feedback such that the 328 sender adjusts its transmission rate to approximate available 329 capacity. 331 For basic best effort service, a single DSCP value is provided to 332 identify the traffic, a queue to store it, and active queue 333 management to protect the network from it and to limit delays. The 334 interesting thing is that by giving that queue a higher minimum rate 335 than its measured arrival rate, we can effectively limit the 336 deleterious effects of congestion on a given class of traffic, 337 transferring them to another class that is perhaps better able to 338 absorb the impact or is considered to be of lower value to the 339 network administration. So, for example, if it is important to 340 service database exchange or transaction traffic in a timely 341 fashion, isolating the traffic into a queue and giving it a 342 relatively high minimum rate will accomplish that. 344 Scavenger, or less than best effort, service can also be provided, 345 for applications with congestion avoidance capabilities and is 346 considered to be of lower value to the network administration then 347 best effort traffic. 349 1.3.2 Assured Forwarding (AF) 351 The Assured Forwarding RFC 2597[11] service is explicitly modeled on 352 Frame Relay's DE flag or ATM's CLP capability, and is intended for 353 networks which offer average-rate SLAs (as FR and ATM networks do). 354 This is an enhanced Best Effort service; traffic is expected to be 355 "elastic" in nature. The receiver will detect loss or variation in 356 delay in the network and provide feedback such that the sender 357 adjusts its transmission rate to approximate available capacity. 359 For such classes, multiple DSCP values are provided (two or three, 360 perhaps more using local values) to identify the traffic, a common 361 queue or class to store the aggregate and active queue management to 362 protect the network from it and to limit delays. Traffic is metered 363 as it enters the network, and traffic is variously marked depending 364 on the arrival rate of the aggregate. The premise is that it is 365 normal for users to occasionally use more capacity than their 366 contract stipulates, perhaps up to some bound. However, if traffic 367 must be lost or marked to manage the queue, this excess traffic will 368 be marked or lost first. 370 1.3.3 Expedited Forwarding (EF) 372 Expedited Forwarding RFC 3246[19] was originally proposed as a way 373 to implement a virtual wire, and can be used in such a manner. It is 374 an enhanced best effort service: traffic remains subject to loss due 375 to line errors and reordering during routing changes. However, using 376 queuing techniques, the probability of delay or variation in delay 377 is minimized. For this reason, it is generally used to carry voice 378 and for transport of data information that requires "wire like" 379 behavior through the IP network. Voice is an inelastic "real-time" 380 application that sends packets at the rate the codec produces them, 381 regardless of availability of capacity. As such, this service has 382 the potential to disrupt or congest a network if not controlled. It 383 also has the potential for abuse. 385 To protect the network, at minimum one must police traffic at 386 various points to ensure that the design of a queue is not over-run, 387 and then the traffic must be given a low delay queue (often using 388 priority, although it is asserted that a rate-based queue can do 389 this) to ensure that variation in delay is not an issue, to meet 390 application needs. 392 1.3.4 Class Selector (CS) 394 Class Selector provides support for historical codepoint definitions 395 and PHB requirement. The Class Selector DS field provides a limited 396 backward compatibility with legacy (pre Diffserv) practice, as 397 described in RFC 2474 [7] section 4. Backward compatibility is 398 addressed in two ways. First, there are per-hop behaviors that are 399 already in widespread use (e.g. those satisfying the IPv4 Precedence 400 queuing requirements specified in [RFC 1812]), and we wish to permit 401 their continued use in DS-compliant networks. In addition, there are 402 some codepoints that correspond to historical use of the IP 403 Precedence field and we reserve these codepoints to map to PHBs that 404 meet the general requirements specified in RFC 2474 Sec. 4.2.2.2. 406 No attempt is made to maintain backward compatibility with the "DTR" 407 or TOS bits of the IPv4 TOS octet, as defined in [RFC 791]. 409 A DS-compliant network can be deployed with a set of one or more 410 Class Selector Compliant PHB groups. As well, network administrator 411 may configure the network nodes to map codepoints to PHBs 412 irrespective of bits 3-5 of the DSCP field to yield a network that 413 is compatible with historical IP Precedence use. Thus, for example, 414 codepoint '011000' would map to the same PHB as codepoint '011010'. 416 1.3.5 Admission Control 418 Admission control including refusal when policy thresholds are 419 crossed, can assure high quality communication by ensuring the 420 availability of bandwidth to carry a load. Inelastic real-time flows 421 like VoIP (telephony) or video conferencing services can benefit 422 from use of admission control mechanism, as generally the telephony 423 service is configured with over subscription, meaning that some 424 user(s) may not be able to make a call during peak periods. 426 For VoIP (telephony) service, a common approach is to use signaling 427 protocols such as SIP, H.323, H.248, MEGACO, RSVP, etc. to negotiate 428 admittance and usage of network transport capabilites. When a user 429 has been authorized to send voice traffic, this admission procedure 430 has verified that data rates will be within the capacity of the 431 network that it will use. Since RTP voice does not respond to loss 432 or marking in any substantive way, the network must police at 433 ingress to ensure that the voice traffic stays within its negotiated 434 bounds. Having thus assured a predictable input rate, the network 435 may use a priority queue to ensure nominal delay and variation in 436 delay. 438 Another approach that may be used in small and bandwidth constrained 439 networks for limited number of flows is RSVP[4][13]. However, there 440 is concern with the Scalability [5] of this solution in large 441 networks and Aggregation [15] of sessions is considered to be a 442 requirement. 444 1.3.6 Service Differentiation 446 There are practical limits on the level of service differentiation 447 that should be offered in the IP networks. We believe we have 448 defined a practical approach in delivering service differentiation 449 by defining different service classes that networks may choose to 450 support to provide the appropriated level of behaviors and 451 performance needed by current and future applications and services. 452 The defined structure for providing services allows several 453 applications having similar traffic characteristics and performance 454 requirements to be grouped into one service class and therefore 455 forwarded by single queue in a router. Also we provide a method for 456 different application (flows) within a service class to have unique 457 DSCP marking so that different conditioning and policing polices may 458 be used for different flows, through the use of Class Selector (CS) 459 codepoints or locally defined DSCP (EXP/LU) values and associating 460 them with the standardized PHBs. This approach provides a lot of 461 flexibility in providing the appropriate level of service 462 differentiation for current and new yet unknown applications without 463 introducing significant changes to routers or network configurations 464 when new traffic type is added to the network. 466 2. Traffic Categories and Service Classes 468 This document divides traffic into five categories, one for network 469 control and four for user/subscriber traffic. The term "user" and 470 "subscriber" are used interchangeable in this document. Network 471 control traffic can further be divided into two service classes, 472 mainly flows that are critical, require lower delay or higher 473 probability of being serviced and normal network control flows. 474 User/subscriber traffic is broken down into four user traffic 475 categories, interactive, responsive, timely and non-critical as 476 defined by ITU-T Recommendation G.1010. These four user traffic 477 categories can further be subdivided into one or more different 478 service classes within each traffic category to provide further 479 behavior differentiation. End-to-end performance requirements for 480 these traffic categories and service classes are further defined in 481 ITU-T Recommendation Y.1541, Y.1540 and G.1010. Additionally, 482 network administrators may choose to define other service classes. 484 The service classes define the required treatment for the traffic in 485 order to meet user, application or network expectations. Section 3 486 in this document defines the service classes that may be used for 487 forwarding network control traffic and section 4 defines the service 488 classes that may be used for forwarding user traffic with examples 489 of intended application types mapped into each of their service 490 classes. Note that the application types are only examples and are 491 not meant to be all-inclusive. Also it should be noted that the 492 service class naming or ordering does not imply any priority 493 ordering. They are simply reference names that are used in this 494 document with associated QoS behaviors that are optimized for the 495 particular application types they support. Network administrators 496 may choose to assign different service class names, to the service 497 classes that they will support. Table 1 below defines the 498 relationship between service classes and DS codepoint(s) assignment 499 with application examples. 501 ------------------------------------------------------------------ 502 | Service | DSCP | DSCP | Application | 503 | Class name | name | value | Examples | 504 |===============+=========+=============+==========================| 505 |Administration | CS7 | 111000 | Heartbeats, SSH, Telnet | 506 |---------------+---------+-------------+--------------------------| 507 |Network Control| CS6 | 110000 | Network routing | 508 |---------------+---------+-------------+--------------------------| 509 | Telephony | EF,CS5 |101010,101000| IP Telephony | 510 |---------------+---------+-------------+--------------------------| 511 | Multimedia |AF41,AF42|100010,100100| Video conferencing | 512 | Conferencing | AF43 |100110 | Interactive gaming | 513 |---------------+---------+-------------+--------------------------| 514 | Multimedia |AF31,AF32|011010,011100|Broadcast TV, Pay per view| 515 | Streaming |AF33, CS4|011110,100000|Video surveillance | 516 |---------------+---------+-------------+--------------------------| 517 | Low Latency |AF21,AF22|010010,010100|Client/server transactions| 518 | Data |AF23, CS3|010110,011000|peer-to-peer signaling | 519 |---------------+---------+-------------+--------------------------| 520 |High Throughput|AF11,AF12|001010,001100|Store&forward applications| 521 | Data |AF13, CS2|001110,010000|Non-critcal OAM&P | 522 |---------------+---------+-------------+--------------------------| 523 | Standard | DF,(CS0)| 000000 | Undifferentiated | 524 | | | | applications | 525 |---------------+---------+-------------+--------------------------| 526 | Low Priority | CS1 | 001000 | Any flow that has no BW | 527 | Data | | | assurance | 528 ------------------------------------------------------------------ 529 Table 1: DSCP to Service Class Mapping 531 Note: The Class Selector 2,3 and 4 codepoints are aliases of AF11, 532 AF21 and AF31 codepoints respectfully. Class Selector 5 codepoint 533 is alias of EF codepoint. Default Forwarding and Class Selector 0 534 provide equivalent behavior and use the same DS codepoint. 536 Table 2 provides a summary of DiffServ QoS mechanisms used for the 537 nine different service classes that are further defined in Section 538 3 and 4 of this document. Based on what applications/service that 539 need to be differentiation, network administrators can choose the 540 service class(es) that needs to be supported in their network. 542 Example 1: 543 A network administrator determines that they need in their network 544 to provide three different levels of network performance (quality 545 of service) for the services that they will be offering to their 546 customers. They need to enable their network to provide reliable 547 VoIP (telephony) service, equivalent to PSTN. A low delay assured 548 bandwidth data service that customers will purchase plus access to 549 The Internet for basic connectivity. In this example, the network 550 administrator's needs are addressed with the deployment of the 551 following service classes: 552 - Standard service class for all traffic that will receive normal 553 (undifferentiated) forwarding treatment through their network. 554 - Telephony service class for VoIP (telephony) traffic. 555 - Low Latency Data service class for the differentiated data 556 service. 557 - Network Control service class for routing and control traffic 558 that is needed for reliable operation of the provider's network. 560 Example 2: 561 A network administrator determines that they need to support two 562 service classes for control and administration of their network 563 plus six levels of service differentiation for user traffic use the 564 following service classes: 565 - Administration 566 - Network Control 567 - Standard 568 - Telephony 569 - Low Latency Data 570 - High Throughput Data 571 - Multimedia Conferencing 572 - Multimedia Streaming 574 Example 3: 575 An enterprise network administrator determines that thy need to 576 provide seven levels of service differentiation for user traffic 577 plus one for running of their network. They would configure their 578 network to support the following service classes: 579 - Network Control 580 - Telephony 581 - Multimedia Conferencing 582 - Multimedia Streaming 583 - Low Latency Data 584 - High Throughput Data 585 - Standard 586 - Low Priority Data 588 It is expected that network administrators will choose the service 589 classes that they will support based on their need. Start off with 590 two or three service classes for user traffic and add others as the 591 need arises. 593 ------------------------------------------------------------------ 594 | Service | DSCP | Conditioning at | PHB | Queuing| AQM| 595 | Class | | DS Edge |Reference| | | 596 |===============+======+===================+=========+========+====| 597 |Administration | CS7 |Police using sr+bs | RFC2474 |Priority| No | 598 |---------------+------+-------------------+---------+--------+----| 599 |Network Control| CS6 |Police using sr+bs | RFC2474 | Rate | No | 600 |---------------+------+-------------------+---------+--------+----| 601 | Telephony |EF,CS5|Police using sr+bs | RFC3246 |Priority| No | 602 |---------------+------+-------------------+---------+--------+----| 603 | | AF41 | | | | Yes| 604 | Multimedia | AF42 | Using trTCM | RFC2597 | Rate | per| 605 | Conferencing | AF43 | (RFC2698) | | |DSCP| 606 |---------------+------+-------------------+---------+--------+----| 607 | | AF31 | Police using sr+bs| | | | 608 | |------+-------------------| | | Yes| 609 | Multimedia | AF32 | Police sum using | | Rate | per| 610 | Streaming | AF33 | sr+bs | RFC2597 | |DSCP| 611 | |------+-------------------| | |----| 612 | | CS4 |Police using sr+bs | | | No | 613 |---------------+------+-------------------+---------+--------+----| 614 | | AF21 | | | | Yes| 615 | Low | AF22 | Using srTCM | | | per| 616 | Latency | AF23 | (RFC 2697) | RFC2597 | Rate |DSCP| 617 | Data |------+-------------------| | |----| 618 | | CS3 |Police using sr+bs | | | No | 619 |---------------+------+-------------------+---------+--------+----| 620 | | AF11 | | | | Yes| 621 | High | AF12 | Using srTCM | | | per| 622 | Throughput | AF13 | (RFC 2697) | RFC2597 | Rate |DSCP| 623 | Data |------+-------------------| | |----| 624 | | CS2 |Police using sr+bs | | | No | 625 |---------------+------+-------------------+---------+--------+----| 626 | Standard | DF | Not applicable | RFC2474 | Rate | Yes| 627 |---------------+------+-------------------+---------+--------+----| 628 | Low Priority | CS1 | Not applicable | pdb-le | Rate | Yes| 629 | Data | | | -draft | | | 630 ------------------------------------------------------------------ 631 Table 2: Summary of QoS Mechanisms used for each Service Class 633 Note: Conditioning at DS edge, means that traffic conditioning is 634 performed at the edge of the DiffServ network where untrusted 635 user/devices are connected or between two DiffServ networks. 637 Note: "sr+bs" represents a policing mechanism that provides single 638 rate with burst size control. 640 3. Network Control Traffic Category 642 Network control traffic is defined as packet flows that are 643 essential for stable operation of the administered network as well 644 for information that may be exchanged between neighboring networks 645 across a peering point where SLAs are in place. Network control 646 traffic is different from user application control (signaling) that 647 may be generated by some applications or services. Network control 648 traffic is mostly between routers and network nodes that are used 649 for administering, controlling or managing the network segments and 650 the services that are provided in that network segment. A network 651 administrator may choose to split the network control traffic into 652 two service classes i.e., Administration and Network Control to 653 provide two different forwarding treatments or just support one 654 forwarding treatment for all network control flows. 656 3.1 Administration Service Class 658 The Administration service class is intended to be used for control 659 traffic that is within a single administrative network domain. If 660 such traffic does not get through, the administered network domain 661 may not function properly. Example of such type of traffic is 662 heartbeats between core network switches/routers. Such heartbeats 663 are used to determine if the next hop is reachable. If no heartbeat 664 is received within a specified time interval, then the sending 665 router assumes that the particular link or next hop node is 666 unreachable on a particular interface and subsequently reroutes the 667 traffic to a backup interface that can reach the next hop node. 668 This reroute is typically done in a time interval much shorter than 669 the time it would take for the routing protocol to determine that 670 the next hop node is unreachable. 672 The Administration service class uses the DiffServ Class Selector 673 (CS) PHB defined in RFC 2474 [7] and should be configured to receive 674 sufficed forwarding resources so that all packets are forwarded 675 quickly. The Administration service class should be configured to 676 use Priority Queuing system such as defined in Section 1.2.1.1 of 677 this document. 679 The following protocols and application should use the 680 Administration service class: 681 - Network administrator's telnet sessions from secure and trusted 682 terminals, Secure Shell (SSH) 683 - Protocol(s) that are transmitted between nodes within the 684 administered network for detecting of link and nodal failures 685 - Used for critical control traffic within an administrative 686 domain 687 - May be used for any control traffic that is forwarded within the 688 administered network domain such as NTP information that 689 requires very low delay variation (jitter) 690 - User traffic must not be mapped into this service class 691 - Inter-network domain (across peering points) control traffic 692 should not be mapped into this service class 694 Traffic characteristics of packet flows in the Administration 695 service class: 696 - Mostly messages between routers and network servers 697 - Typically small packet sizes, one packet at a time 698 - Packets require immediate forwarding 699 - No user-to-user traffic is allowed to use this service class 701 Recommended DSCP marking is CS7 (Class Selector 7) 703 Network edge conditioning: 704 - Drop or remark CS7 marked packets at ingress to DiffServ network 705 domain. 706 - Depending on policy within the administered network, CS7 marked 707 packets may be dropped or remarked to CS6 at egress of DiffServ 708 network or across peering points. 710 3.2 Network Control Service Class 712 The Network Control service class is used for transmitting packets 713 between network devices (routers, servers, etc.) that require 714 control information to be exchanged between different administrative 715 domains (across a peering point) and for non-critical network 716 control information exchange within one administrative domain. 717 Traffic transmitted in this service class is very important as it 718 keeps the network operational and needs to be forwarded in a timely 719 manner. 721 The Network Control service class uses the DiffServ Class Selector 722 (CS) PHB defined in RFC 2474 [7]. This service class is configured 723 so that the traffic receives a minimum bandwidth guarantee, to 724 ensure that the packets always receive timely service. The 725 configured forwarding resources for Network Control service class 726 should be such that the probability of packet drop under peak load 727 is very low in this service class. The Network Control service class 728 should be configured to use Rate Queuing system such as defined in 729 Section 1.2.1.2 of this document. 731 The following protocols and applications should use the Network 732 Control service class: 733 - Routing packet flows, OSPF, BGP, ISIS, RIP 734 - Policy management flows between nodes in the network, COPS, 735 RSVP-TE, etc. 736 - SIP-T signaling between high capacity telephony call servers or 737 soft switches. Such high capacity devices may control thousands 738 of telephony (VoIP) calls. 739 - Network services, DNS, DHCP, BootP, high priority OAM (SNMP) 740 like alarms, etc. 742 - Used for control information exchange within and between 743 different administrative domains across a peering point where 744 SLAs are in place. 745 - In 3GPP wireless solutions, used to transport UMTS 746 signaling/control information between wireless nodes 747 - User traffic must not be mapped into this service class 749 Traffic characteristics of packet flows in the Network Control 750 service class: 751 - Mostly messages between routers and network servers 752 - Ranging from 50 to 1,500 byte packet sizes, normally one packet 753 at a time but traffic can also burst (BGP) 754 - No user-to-user traffic is allowed to use this service class 756 Recommended DSCP marking is CS6 (Class Selector 6) 758 Network edge conditioning: 759 - At peering points (between two DiffServ networks) where SLAs are 760 in place, CS6 marked packets are policed using a single rate 761 with burst size (sr+bs) token bucket policer to keep the CS6 762 marked packet flows to within the traffic rate specified in the 763 SLA. 764 - CS6 marked packet flows from untrusted sources (end user 765 devices) are dropped or remarked at ingress to DiffServ network. 766 Packets from users are not permitted access to the Network 767 Control or Administration service classes. 769 If Administration service class is not supported, then the Network 770 Control service class is used for both normal network control 771 traffic and network administration traffic defined in this document 772 and packets marked with CS7 DSCP receive the same forwarding 773 treatment as CS6 marked packets. 775 4. User Traffic Categories 777 User traffic is divided into four different categories, namely, 778 interactive, responsive and timely. An example of interactive 779 traffic is between two humans and is most sensitive to delay, loss 780 and jitter. Another example of interactive traffic is between two 781 servers where very low delay and loss is needed. Responsive traffic 782 is typically between a human and a server but also can be between 783 two servers. Responsive traffic is less affected by jitter and can 784 tolerate longer delays than interactive traffic. Timely traffic is 785 either between servers or servers and humans and the delay tolerance 786 is significantly longer than responsive traffic. Non-critical 787 traffic is normal between servers/machines where delivery may be 788 delay for period of time. The Four traffic categories follow 789 methodology defined by ITU-T Recommendation Y.1541 and G.1010. 791 Network administrators can categorize their applications based on 792 the type of behavior that they require. Table 1 provides some 793 common applications and the forwarding service class that best 794 supports them based on their performance requirements. 796 In summary: 797 - Telephony service class is best suited for applications that 798 require very low delay and are of constant rate, such as IP 799 telephony (VoIP) and circuit emulation over IP applications. 800 - Multimedia Conferencing service class is best suited for 801 applications that require very low delay but are of variable 802 rate, such as video conferencing and interactive gaming. 803 - Multimedia Streaming service class is best suited for streaming 804 media applications such as broadcast TV, pay-per-view, video 805 surveillance and security, etc. 806 - Low Latency Data service class is best suited for interactive 807 client / server or client-to-client applications such as web- 808 based ordering, EPR application, peer-to-peer signaling, etc. 809 - High Throughput Data service class is best suited for store and 810 forward applications such as FTP, billing record transfer, etc. 811 - Standard service class is for traffic that has not bean 812 identified as requiring differentiated treatment and is normally 813 referred as best effort. 814 - Low Priority Data service class is intended for packet flows 815 where bandwidth assurance is not required. 817 Note, a network administrator may choose to support all or subsets 818 of the defined service classes and provide service differentiation 819 only to the applications/service that are mapped into them. 821 4.1 Interactive Traffic Category 823 Interactive traffic category can be further split into two service 824 classes, Telephony and Multimedia Conferencing to provide 825 differentiation based on the different behavior of source traffic 826 being forwarded. 828 4.1.1 Telephony Service Class 830 Used for applications that require real-time, low delay, very low 831 packet loss for relatively constant-rate traffic sources (inelastic 832 traffic sources). This forwarding class is used predominantly for IP 833 telephony services and provides the low latency, jitter and loss 834 required. 836 The fundamental service offered to traffic in the Telephony service 837 class is a higher priority service than best-effort up to a 838 specified upper bound with low delay and very low packet loss. 839 Operation is in some respect similar to an ATM CBR service, which 840 has guaranteed bandwidth and if it stays within the negotiated rate 841 it experiences nominal delay and no loss. The EF PHB has a similar 842 guarantee. 844 Typical configurations negotiate the setup of telephone calls over 845 IP using protocols such as H.248, MEGACO, H.323 or SIP. When a user 846 has been authorized to send telephony traffic, the call admission 847 procedure has verified that the newly admitted data rates will be 848 within the capacity of the Telephony service class forwarding 849 capability in the network that it will use. For VoIP (telephony) 850 service, the common approach is to use call admission control 851 performed by a telephony call server/gatekeeper using signaling 852 (SIP, H.323, H.248, MEGACO, etc.) on access points to the network. 853 The bandwidth in the core network and the number of simultaneous 854 VoIP sessions that can be supported needs to be engineered and 855 controlled so that there is no congestion for this service. Since 856 RTP telephony flows do not respond to loss or substantial delay in 857 any substantive way, the Telephony service class should forward 858 packet as soon as possible. 860 The Telephony service class uses Expedited Forwarding (EF) PHB as 861 defined in RFC 3246 [19] and must be configured to receive 862 guaranteed forwarding resources so that all packets are forwarded 863 quickly. The Telephony service class should be configured to use 864 Priority Queuing system such as defined in Section 1.2.1.1 of this 865 document. 867 Target applications for Telephony service class: 868 - VoIP (G.711, G.729 and other codecs) 869 - Telephony (trunk and/or stimulus) signaling between end device 870 (terminals/gateways) and the call server (H.248, MEGACO) 871 - Lawful Intercept 872 - Voice-band data over IP (modem, fax) 873 - T.38 fax over IP 874 - Circuit emulation over IP, virtual wire, etc. 875 - In wireless 3GPP applications, used to forward traffic that is 876 mapped into the UMTS Conversational Traffic Class 878 Traffic characteristics: 879 - Mostly fixed size packets for VoIP (60 or 70 or 120 or 200 bytes 880 in size) 881 - Packet emitted at constant time intervals 882 - Admission control of new flows is provided by telephony call 883 server, media gateway, gatekeeper, edge router or access node 884 that provides "middlebox" function. 886 Recommended DSCP marking EF for the following applications: 887 - VoIP (G.711, G.729 and other codecs) 888 - Lawful Intercept 889 - Voice-band data over IP (modem) 890 - Circuit emulation over IP, virtual wire, etc. 891 - Conversational UMTS Traffic Class 893 Recommended DSCP marking CS5 for the following applications: 895 - Telephony (trunk and/or stimulus) signaling between end device 896 (terminals/gateways) and the call server (H.248, MEGACO) 897 - T.38 fax over IP 899 Both EF and CS5 DS codepoints are mapped into the Telephony service 900 classes and used the Expedited Forwarding (EF) PHB. The CS5 DS 901 codepoint is aliased to the EF codepoint and packets marked with CS5 902 are forwarded using the EF PHB. 904 Network Edge Conditioning: 905 - Packet flows from untrusted sources (end user devices) must be 906 policed at ingress to DiffServ network using single rate with 907 burst size token bucket policer to ensure that the telephony 908 traffic stays within its negotiated bounds. 909 - Packet flows from trusted sources (media gateways inside 910 administered network) do not require policing. 911 - Policing of Telephony packet flows across peering points where 912 SLA is in place is not required as telephony traffic will be 913 controlled by admission control mechanism between peering 914 points. 916 Note: On low speed links (typically access links below 1Mbps), in 917 the attempt to minimize jitter/delay, it is recommended that 918 packetized audio streams are separated from processed telephony data 919 information flows like T.38 fax and telephony signaling and 920 forwarded using less stringent from delay/jitter perspective service 921 class. PCM voice when compressed produces very small packets i.e. 60 922 bytes in size were T.38 fax and signaling packets can be much 923 bigger. The serialization delay, therefore delay/jitter for the 924 larger T.38 fax and signaling packets can be significantly bigger 925 over low speed links then for 60 byte voice packets. For this reason 926 it is recommended that packetized voice packets receive a higher 927 priority forwarding treatment then the less sensitive from 928 delay/jitter perspective T.38 fax and telephony signaling packets. 929 PCM audio streams (voice) have a strict end-to-end delay constrain 930 and should use Priority Queuing system where as T.38 fax or 931 telephony signaling have a more liberal jitter/delay constrain and 932 should use Rate Queuing system on access links below 1 Mbps. 934 On higher speed links the difference in serialization delay is very 935 small, therefore both types of telephony packet flows are aggregated 936 in to a single forwarding service class to simplify network 937 engineering and use Priority Queuing system. As well, the forwarding 938 of voice packets and signaling packets with the same very low delay 939 forwarding service class minimizes delay as well as the difference 940 in delay between signaling and bearer path, therefore virtually 941 eliminating speech clipping and ring-clipping problems at start of 942 call when interfacing to PSTN. 944 4.1.2 Multimedia Conferencing Service Class 946 Used for applications that requires real-time and low delay for 947 variable rate elastic traffic source. The traffic sources 948 (applications) in this traffic class have the capability to change 949 their emitting rate based on feedback received from the receiving 950 end. Detection of packet loss by the receiver is sent using the 951 applications control stream to the transmitter as an indication of 952 possible congestion. The transmitter based on pre-configured 953 encoding rates (or transmitting rates) selects a lower rate for 954 transmission. 956 Typical video conferencing configurations negotiate the setup of 957 multimedia session using protocols such as H.323 or SIP. When a 958 user/end-point has been authorized to start a multimedia session the 959 admission procedure has verified that the newly admitted data rates 960 will be within the engineered capacity of the Multimedia 961 Conferencing service class. The bandwidth in the core network and 962 the number of simultaneous video conferencing sessions that can be 963 supported needs to be engineered to control traffic load for this 964 service. 966 The Multimedia Conferencing service class uses the Assured 967 Forwarding (AF) PHB defined in RFC 2597 [11]. This service class is 968 configured to provide a bandwidth assurance for AF41, AF42, and AF43 969 marked packets to ensure that they get forwarded. The Multimedia 970 Conferencing service class should be configured to use Rate Queuing 971 system such as defined in Section 1.2.1.2 of this document. 973 Target application for Multimedia Conferencing service class: 974 - Video conferencing (interactive video) 975 - Interactive gaming 976 - Server to server data transfer requiring very low delay 977 - IP VPN service that specifies two rates and mean network delay 978 that is slightly longer then network propagation delay. 979 Interactive, time critical and mission critical application 980 maybe encapsulated into this VPN service. 981 - In wireless 3GPP applications, used to forward traffic that is 982 mapped into the UMTS Interactive Traffic Class with Traffic 983 Handling Priority 1 (THP=1) 985 Traffic characteristics: 986 - Variable size packets (50 to 1500 bytes in size) 987 - Higher the rate, higher density of large packets 988 - Variable packet emission time 989 - Source capable of reducing its transmission rate based on 990 detection of packet loss at the receiver 992 Packet Marking: 993 - Interactive gaming packets are marked with AF41 994 - Video conferencing packets are marked with AF4x 995 - VPN service may be marked with AF4x depending on the service 996 characteristics 997 - Server to server data transfer with AF4x depending on the 998 service characteristics 999 - UMTS Interactive THP=1 packets are marked with AF4x 1001 Packet flows from video conferencing equipment may be marked at 1002 source by the video conferencing equipment or by the edge router 1003 using Two Rate Three Color Marked (trTCM) as specified in RFC 2698 1004 [18]. 1006 Example of DSCP marking when performed by video conferencing 1007 equipment: 1008 - AF41 = H.323 video conferencing audio stream RTP/UDP 1009 - AF41 = H.323 video conferencing video control RTCP/TCP 1010 - AF41 = H.323 video conferencing video stream below specified 1011 rate "A" 1012 - AF42 = H.323 video conferencing video stream between specified 1013 rate "A" and "B" 1014 - AF43 = H.323 video conferencing video stream above specified 1015 rate "B" 1016 - Where rate "B" is greater in magnitude than rate "A" 1018 Conditioning Performed at DiffServ Network Edge: 1019 The Two Rate Three Color Marker (trTCM) should be used as specified 1020 in RFC 2698 [18]. 1022 If packets are marked by the sources or previous DiffServ domain, 1023 then the trTCM should be configured to operate in Color-Aware mode. 1025 If the packets are not marked by the source or previous DiffServ 1026 domain, then the trTCM must be configured to operate in Color-Blind 1027 mode. 1029 The fundamental service offered to "Multimedia Conferencing" traffic 1030 is best effort service with controlled rate and delay. Some traffic 1031 in this service class may not respond dynamically to packet loss. 1032 For video conferencing service, typically a 1% packet loss detected 1033 at the receiver triggers encoding rate change, drop to next lower 1034 provisioned video encoding rate. As such, Active Queue Management 1035 [6] is used primarily to switch video encoding rate under 1036 congestion, change from high rate to lower rate i.e. 1472 kbps to 1037 768 kbps. The probability of loss of AF41 traffic may not exceed the 1038 probability of loss of AF42 traffic, which in turn may not exceed 1039 the probability of loss of AF43 traffic. 1041 4.2 Responsive Traffic Category 1043 Responsive traffic category can be further split into two service 1044 classes, Multimedia Streaming and Low Latency Data to provide 1045 differentiation based on the different behavior of source traffic 1046 being forwarded. 1048 4.2.1 Multimedia Streaming Service Class 1050 The Multimedia Streaming service class is used for applications that 1051 require near-real-time packet forwarding of variable rate traffic 1052 sources which are not as delay sensitive as applications using the 1053 Multimedia Conferencing service class. Such applications include 1054 broadcast TV, streaming audio and video, video (movies) on demand 1055 and surveillance video. In general, the Multimedia Streaming 1056 service class assumes that the traffic is buffered at the 1057 source/destination and therefore, is less sensitive to delay and 1058 jitter. 1060 The Multimedia Streaming service class uses the Assured Forwarding 1061 (AF) PHB defined in RFC 2597 [11]. This service class is configured 1062 to provide a minimum bandwidth assurance for AF31, AF32, AF33 and 1063 CS4 marked packets to ensure that they get forwarded. The Multimedia 1064 Streaming service class should be configured to use Rate Queuing 1065 system such as defined in Section 1.2.1.2 of this document. 1067 Target application for Multimedia Streaming service class: 1068 - Video surveillance and security (unicast) 1069 - TV broadcast including HDTV (multicast) 1070 - Pay per view movies and events (pre scheduled) 1071 - Video on demand (unicast) with control (virtual DVD) 1072 - Streaming audio (unicast) 1073 - Streaming video (unicast) 1074 - Web casts 1075 - VPN service that supports different levels of flow assurance 1076 - In wireless 3GPP applications, used to forward traffic that is 1077 mapped into the UMTS Streaming Traffic Class 1079 Traffic Characteristics: 1080 - Variable size packets (50 to 4196 bytes in size) 1081 - Higher the rate, higher density of large packets 1082 - Variable packet emission rate 1083 - Some bursting at start of flow from some applications 1084 - At about 2% packet loss, video session is usually terminated 1086 Both the AF3x and CS4 DS codepoints are mapped into the Multimedia 1087 Streaming service classes and used the Assured Forwarding (AF) PHB 1088 however, Active Queue Management (AQM) mechanism is not applied in 1089 the router(s) to CS4 market packets. 1091 Applications or end systems pre-mark their packets with DSCP values 1092 as shown in Table 3 below. If host is unable to pre-mark their 1093 packets, then marking is performed on the DiffServ edge router using 1094 MF classification. Due to the nature of the service, it is 1095 recommended that video surveillance and security flows are market 1096 with a different DSCP value so that traffic conditioning and 1097 policing policies can be different from other flows in the 1098 Multimedia Streaming service class. 1100 ------------------------------------------------------------------ 1101 | Applications | Protocol |DSCP| 1102 |------------------------------------+------------------------+----| 1103 |Video surveillance and security |For RTP/UDP payload and |CS4 | 1104 | (unicast) |RTSP/TCP control streams| | 1105 |------------------------------------+------------------------+----| 1106 |TV broadcast (multicast), pay per |For RTP/UDP payloads and| | 1107 |view movies and events (multicast) |RTSP/TCP control streams|AF31| 1108 |Video on demand(unicast)with control| | | 1109 |------------------------------------+------------------------+----| 1110 | | For RTP/UDP streams |AF33| 1111 | |------------------------+----| 1112 | Video clips (unicast), premium WEB | For RTP/TCP streams |AF32| 1113 | casts, etc. |------------------------+----| 1114 | | RTP/TCP or HTTP control|AF32| 1115 |------------------------------------+------------------------+----| 1116 | | For RTP/UDP streams |AF33| 1117 | |------------------------+----| 1118 | Audio streaming (unicast) | For RTP/TCP streams |AF32| 1119 | |------------------------+----| 1120 | |RTSP/TCP or HTTP control|AF31| 1121 |------------------------------------+------------------------+----| 1122 | VPN service that support different | |AF31| 1123 | levels of assurance |Implementation dependent|AF32| 1124 | | |AF33| 1125 |------------------------------------+------------------------+----| 1126 | | |AF31| 1127 | UMTS Streaming packets | GPRS tunnel over IP |AF32| 1128 | | |AF33| 1129 ------------------------------------------------------------------ 1130 Table 3: Example of DSCP marking for Multimedia Streaming 1132 Network Edge Conditioning: 1133 Packet flows from untrusted sources must be policed at the DiffServ 1134 network edge using single rate policers with a burst size control 1135 for AF31, AF32, AF33 and CS4 marked packets. Policing policy is 1136 based on the SLA for supported application(s). For the above 1137 defined applications, three single rate policers with burst size 1138 control should be provided; one for CS4 marked packets, another for 1139 AF31 marked packets and the third policer for AF32 and AF33 marked 1140 packets. Packet flows from trusted sources i.e. TV broadcast 1141 servers, etc. normally do not require policing. 1143 The fundamental service offered to "Multimedia Streaming" traffic is 1144 best effort service with controlled rate and delay. This traffic 1145 does not respond dynamically to packet loss. Packets marked with 1146 AF31 and CS4 DSCP requires very high assurance of delivery. Packets 1147 marked with AF32 and AF33 can generally tolerated up to 1% and 2% 1148 packet loss respectfully. As such, Active Queue Management [6] is 1149 used primarily to reduce the number of flows at congestion points by 1150 dropping packets from less important flows first before any AF31 and 1151 CS4 marked packets are dropped. The service should be provisioned so 1152 that CS4 and AF31 marked packet flows have high assurance for 1153 bandwidth in the network. The probability of loss of CS4 traffic may 1154 not exceed the probability of AF31 and AF31 traffic may not exceed 1155 the probability of loss of AF32 traffic, which in turn may not 1156 exceed the probability of loss of AF33. 1158 4.2.2 Low Latency Data Service Class 1160 The Low Latency Data service class is used for elastic and 1161 responsive typically client/server based applications. Applications 1162 forwarded by this service class are those requiring a relatively 1163 fast response and typically have asymmetrical bandwidth need, i.e. 1164 the client typically sends a short message to the server and the 1165 server responds with a much larger data flow back to the client. 1166 The most common example of this is when a user clicks a hyperlink 1167 (~few dozen bytes) on a web page resulting in a new web page to be 1168 loaded (Kbytes of data). This service class is configured to provide 1169 good response for TCP [1] short lived flows that require real-time 1170 packet forwarding of variable rate traffic sources. 1172 The Low Latency Data service class uses the Assured Forwarding (AF) 1173 PHB defined in RFC 2597 [11]. This service class is configured to 1174 provide a minimum bandwidth assurance for AF21, AF22 and AF23 marked 1175 packets to ensure that they get forwarded. The Low Latency Data 1176 service class should be configured to use Rate Queuing system such 1177 as defined in Section 1.2.1.2 of this document. 1179 Target applications for Low Latency Data service class: 1180 - Client / server applications 1181 - SNA terminal to host transactions (SNA over IP using DLSw) 1182 - Web based transactions (E-commerce) 1183 - Credit card transactions 1184 - Financial wire transfers 1185 - ERP applications (.e.g. SAP / BaaN) 1186 - Peer-to-peer signaling (SIP, H.323) 1187 - VPN service that supports CIR (Committed Information Rate) with 1188 up to two burst sizes 1189 - In wireless 3GPP applications, used to forward traffic that is 1190 mapped into the UMTS Interactive Traffic Class with Traffic 1191 Handling Priority 2 (THP=2) 1193 Traffic Characteristics: 1194 - Variable size packets (50 to 1500 bytes in size) 1195 - Variable packet emission rate 1196 - With packet bursts of TCP window size 1197 - Source capable of reducing its transmission rate based on 1198 detection of packet loss at the receiver or through explicit 1199 congestion notification. 1201 Both the AF2x and CS3 DS codepoints are mapped into the Low Latency 1202 Data service classes and use the Assured Forwarding (AF) PHB 1203 however, Active Queue Management (AQM) mechanism is not applied in 1204 router(s) to CS3 market packets. 1206 DSCP marking: 1207 - Peer-to-peer inelastic SIP, H.323 signaling packer flows are 1208 marked with CS3 1209 - Elastic TCP flows are marked with AF2x 1210 - VPN service may be marked with AF2x or CS3 depending on the 1211 service characteristics 1212 - UMTS Interactive THP=2 packets are marked with AF2x 1214 Marking of the DSCP may be performed by a host or by an edge router. 1216 Conditioning Performed at the DiffServ Network Edge: 1217 Conditioning may be performed on per-flow or on aggregated-flows 1218 depending on the configuration and service offered. Metering and 1219 (re)marking of flows is required at DiffServ edge node and on 1220 DiffServ boundary node. The Low Latency Data service class uses a 1221 Single Rate Three Color Marker (srTCM) conditioner for AF2x flows. 1223 Conditioning Requirements for AF2x marked packets: 1224 Conditioning of aggregated packet flows destined for the Low 1225 Latency Data service class must be performed at the DiffServ edge 1226 of the network. Furthermore, conditioning should be performed using 1227 Single Rate Three Color Marker (srTCM) as defined in RFC 2697 [17]. 1229 If the packets are not pre-marked then the srTCM must be configured 1230 to operate in the Color-Blind mode. 1232 If the packets are pre-marked by the source or previous network 1233 (boundary node) then the srTCM should be configured to operate in 1234 the Color-Aware mode. 1236 Conditioning Requirements for CS3 marked Packets: 1237 DiffServ edge and boundary nodes must police CS3 marked packets so 1238 both rate and burst size can be enforced. 1240 The fundamental service offered to "Low Latency Data" traffic is 1241 best effort service with controlled rate and delay. The service 1242 should be engineered so that AF21 and CS3 marked packet flows have 1243 sufficed bandwidth in the network to provide high assurance of 1244 delivery. Since this traffic is marked with AF2x DSCP is elastic and 1245 responds dynamically to packet loss, Active Queue Management [6] is 1246 used primarily to control TCP flow rates at congestion points by 1247 dropping packet from TCP flows where the burst length is high. The 1248 probability of loss of CS3 traffic may not exceed the probability of 1249 loss of AF21 and AF21 traffic may not exceed the probability of loss 1250 of AF22 traffic, which in turn may not exceed the probability of 1251 loss of AF23. Active queue management may also be implemented using 1252 Explicit Congestion Notification (ECN) [17] method as defined in RFC 1253 3168. 1255 4.3 Timely Traffic Category 1257 Timely traffic category can be further split into two service 1258 classes, High Throughput Data and Standard to provide 1259 differentiation based on the different behavior of source traffic 1260 being forwarded. 1262 4.3.1 High Throughput Data Service Class 1264 The High Throughput Data service class is configured to support 1265 elastic applications that require timely packet forwarding of 1266 variable rate traffic sources and more specifically is configured to 1267 provide good throughput for TCP longer lived flows. TCP[1] or a 1268 transport with a consistent Congestion Avoidance Procedure[9][10] 1269 normally will drive as high a data rate as it can obtain over a long 1270 period of time. The FTP protocol is a common example, although one 1271 cannot definitively say that all FTP transfers are moving data in 1272 bulk. 1274 The High Throughput Data service class uses the Assured Forwarding 1275 (AF) PHB defined in RFC 2597 [11]. This service class is configured 1276 to provide a minimum bandwidth assurance for AF11, AF12, AF13 and 1277 CS2 marked packets to ensure that they are forwarded. The High 1278 Throughput Data service class should be configured to use Rate 1279 Queuing system such as defined in Section 1.2.1.2 of this document. 1281 Target applications for High Throughput Data service class: 1282 - Store and forward applications 1283 - File transfer applications 1284 - Email 1285 - Non-critical OAM&P (Operation and Management and Provisioning) 1286 using SNMP, XML, etc. 1287 - VPN service that supports CIR (Committed Information Rate) with 1288 up to two burst sizes 1289 - In wireless 3GPP applications, used to forward traffic that is 1290 mapped into the UMTS Interactive Traffic Class with Traffic 1291 Handling Priority 3 (THP=3) 1293 Traffic Characteristics: 1294 - Variable size packets (50 to 1500 bytes in size) 1295 - Variable packet emission rate 1296 - With packet bursts of TCP window size 1297 - Source capable of reducing its transmission rate based on 1298 detection of packet loss at the receiver or through explicit 1299 congestion notification. 1301 Both the AF1x and CS2 DS codepoints are mapped into the High 1302 Throughput Data service classes and use the Assured Forwarding (AF) 1303 PHB however, Active Queue Management (AQM) mechanism is not applied 1304 in router(s) to CS2 market packets. 1306 DSCP marking: 1307 - Non-critical OAM&P (SNMP, XML, etc.) packets are marked with CS2 1308 - Elastic TCP flows are marked with AF1x 1309 - VPN service may be marked with AF1x or CS2 depending on the 1310 service characteristics 1311 - UMTS Interactive THP=3 packets are marked with AF1x 1313 Note: Since the performance requirements for non-critical OAM&P 1314 traffic can be met with the High Throughput Data service class and 1315 the amount of non-critical OAM&P traffic is normally very small, we 1316 recommend that non-critical OAM&P traffic be marked with CS2 DSCP 1317 and forwarded using the High Throughput Data service class. The 1318 marking of non-critical OAM&P traffic with CS2 DS codepoint is 1319 recommended so that different conditioning, policing and queue 1320 management policies can be used for non-critical OAM&P. 1322 Marking of the DSCP may be performed by a host or by an edge router. 1324 Conditioning Performed at the DiffServ Network Edge: 1325 Conditioning may be performed on per-flow or for aggregated flows 1326 depending on the configuration and the service offered. Metering 1327 and (re)marking of DSCP is required at the DiffServ edge node and 1328 on the DiffServ boundary node. The High Throughput Data service 1329 class uses a Single Rate Three Color Marker (srTCM) conditioner for 1330 AF1x flows and a single rate policer with a burst size limit for 1331 CS2 flows. 1333 Conditioning Requirements for AF1x marked Packets: 1334 Conditioning of aggregated packet flows destined for the High 1335 Throughput Data service class must be performed at the DiffServ 1336 edge of the network. Furthermore, conditioning should be performed 1337 as defined in RFC 2697 [17]. 1339 If the packets are not pre-marked, then the srTCM must be 1340 configured to operate in the Color-Blind mode. 1342 If the packets are pre-marked by the source or previous network 1343 (boundary node) the srTCM should be configured to operate in the 1344 Color-Aware mode. 1346 Conditioning Requirements for CS2 marked Packets: 1347 DiffServ edge and boundary nodes must police CS2 marked packets so 1348 both rate and burst size can be enforced. 1350 The fundamental service offered to "High Throughput Data" traffic is 1351 best effort service with a specified minimum rate. It can be assumed 1352 that this class will consume any available bandwidth, and packets 1353 traversing congested links may experience higher queuing delays 1354 and/or packet loss. 1356 Typical configurations use Explicit Congestion Notification [14] as 1357 defined in RFC 3168 or random packet dropping to implement Active 1358 Queue Management [6] and may impose a minimum or maximum rate. The 1359 probability of loss of AF11 traffic may not exceed the probability 1360 of loss of AF12 traffic, which in turn may not exceed the 1361 probability of loss of AF13 traffic. Ingress traffic conditioning 1362 passes traffic in the class up to some specified threshold marked as 1363 AF11, additional traffic up to some secondary threshold marked as 1364 AF12, and potentially passes additional traffic marked as AF13. In 1365 such a case, if one network customer is driving significant excess 1366 and another seeks to use the link, any losses will be experienced by 1367 the high rate user, causing him to reduce his rate. 1369 Packets marked with CS2 DSCP (OAM&P packets) should not be put 1370 through Active Queue Management [6] function. 1372 4.3.2 Standard Service Class 1374 The Standard service class is used for all traffic that has not been 1375 classified into one of the other supported forwarding service 1376 classes in the DiffServ network domain. This service class provides 1377 the Internet's "best effort" forwarding behavior. This service class 1378 typically has no bandwidth, delay, loss or jitter assurances. 1379 The Standard service class uses the Default Forwarding (DF) PHB 1380 defined in RFC 2474 [7] and should be configured to receive a small 1381 percentage of forwarding resources (at least 5%). This service class 1382 should be configured to use Rate Queuing system such as defined in 1383 Section 1.2.1.2 of this document. 1385 Target application for the Standard service class: 1386 - Any undifferentiated application/packet flow transported through 1387 the DiffServ enabled network 1388 - In wireless 3GPP applications, used to forward traffic that is 1389 mapped into the UMTS Background Traffic Class 1391 Traffic Characteristics: 1392 - Non deterministic, mixture of everything 1394 The DSCP marking is DF (Default Forwarding) 1396 Network Edge Conditioning: 1397 There is no requirement that conditioning of packet flows be 1398 performed for this service class. 1400 The fundamental service offered to the Standard service class is 1401 best effort service with active queue management to limit over-all 1402 delay. Typical configurations use Explicit Congestion Notification 1403 [14] or random packet dropping to implement Active Queue Management 1404 [6], and may impose a minimum or maximum rate on the queue. 1406 4.4 Non-Critical Traffic Category 1407 Non-critical traffic category currently has only one service class 1408 defined for differentiation from Standard traffic. When a need arise 1409 other service class could be defined in the future. 1411 4.4.1 Low Priority Data Service Class 1413 The Low Priority Data service class serves applications which run 1414 over TCP [1] or a transport with a consistent congestion avoidance 1415 procedure [9][10], and which the user is willing to accept service 1416 without guarantees. This service class is specified in [20]. 1418 Target application for the Low Priority Data service class: 1419 - Any TCP based application/packet flow transported through the 1420 DiffServ enabled network that does not require any bandwidth 1421 assurances. 1423 Traffic Characteristics: 1424 - Non real-time and elastic. 1426 The DSCP marking is CS1 (Class Selector 1) 1428 Network Edge Conditioning: 1429 There is no requirement that conditioning of packet flows be 1430 performed for this service class. 1432 The fundamental service offered to the Low Priority Data service 1433 class is best effort service with zero bandwidth assurance. By 1434 placing it into a separate queue or class, it may be treated in a 1435 manner consistent with a specific service level agreement. 1437 Typical configurations use Explicit Congestion Notification [14] or 1438 random loss to implement active queue management [6]. 1440 5. Mapping Applications to Service Classes 1442 Here we provide some examples for mapping different applications 1443 into the defined service classes. 1445 Mapping for Signaling: 1447 There are many different signaling protocols, ways that signaling is 1448 used and performance requirements from applications that are 1449 controlled by these protocols. Therefore we have determined that the 1450 different signaling protocols be mapped to service classes that best 1451 meet the objectives. The following mapping is recommended: 1452 - SIP and H.323 are forwarded using Low Latency Data service class 1453 - H.248 and MEGACO are forwarded using the Telephony service class 1454 - SIP-T signaling between call servers in carrier's network using 1455 Network Control service class. 1456 - RSVP signaling, depends on the application. If RSVP signaling is 1457 "on-path" as used in InServ or NSIS that it needs to be forward 1458 from the same queue (service class) as application data that it 1459 is controlling. If it is "off-path" not along the same path as 1460 applications data than, Low Latency Data service class should be 1461 used for RSVP signaling. 1463 Mapping for NTP: 1465 From tests that were performed, indications are that precise time 1466 distribution requires a very low packet delay variation (jitter) 1467 transport. Therefore we would suggest the following guidelines for 1468 NTP be used: 1469 - When NTP is used for providing high accuracy timing within 1470 administrator's (carrier's) network, the Administration service 1471 class should be used and NTP packets be marked with CS7 DSCP. 1472 - When NTP is used for providing high accuracy timing to end 1473 users/clients than the Telephony service class should be used 1474 and NTP packets be marked with CS5 DSCP. 1475 - For applications that require "wall clock" timing accuracy, the 1476 Standard service class should be used and packets should be 1477 marked with DF DSCP. 1479 6. Security Considerations 1481 This document discusses policy, and describes a common policy 1482 configuration, for the use of a Differentiated Services Code Point 1483 by transports and applications. If implemented as described, it 1484 should require the network to do nothing that the network has not 1485 already allowed. If that is the case, no new security issues should 1486 arise from the use of such a policy. 1488 It is possible for the policy to be applied incorrectly, or for a 1489 wrong policy to be applied in the network for the defined service 1490 class. In that case, a policy issue exists which the network must 1491 detect, assess, and deal with. This is a known security issue in any 1492 network dependent on policy directed behavior. 1494 A well known flaw appears when bandwidth is reserved or enabled for 1495 a service (for example, voice transport) and another service or an 1496 attacking traffic stream uses it. This possibility is inherent in 1497 DiffServ technology, which depends on appropriate packet markings. 1498 When bandwidth reservation or a priority queuing system is used in a 1499 vulnerable network, the use of authentication and flow admission is 1500 recommended. To the author's knowledge, there is no known technical 1501 way to respond to an unauthenticated data stream using service that 1502 it is not intended to use, and such is the nature of the Internet. 1504 7. Acknowledgements 1506 The authors acknowledge a great many inputs, most notably from Bruce 1507 Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet, 1508 Brian E Carpenter, Morgan Littlewood and Al Morton. Kimberly King, 1509 Joe Zebarth and Alistair Munroe each did a thorough proof-reading, 1510 and the document is better for their contributions. 1512 8. Normative References 1514 [1] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, RFC 793, 1515 September 1981. 1517 [2] BRADEN, B., CLARK, D. and S. SHENKER, "INTEGRATED SERVICES IN 1518 THE INTERNET ARCHITECTURE: AN OVERVIEW", RFC 1633, June 1994. 1520 [3] BRADNER, S., "KEY WORDS FOR USE IN RFCS TO INDICATE REQUIREMENT 1521 LEVELS", BCP 14, RFC 2119, March 1997. 1523 [4] ZHANG, L., BERSON, S., HERZOG, S. and S. JAMIN, "RESOURCE 1524 RESERVATION PROTOCOL (RSVP) -- VERSION 1 FUNCTIONAL SPECIFICATION", 1525 RFC 2205, September 1997. 1527 [5] BAKER, F., KRAWCZYK, J. and A. SASTRY, "RSVP MANAGEMENT 1528 INFORMATION BASE USING SMIV2", RFC 2206, September 1997. 1530 [6] BRADEN, B., CLARK, D., CROWCROFT, J., DAVIE, B., DEERING, S., 1531 ESTRIN, D., FLOYD, S., JACOBSON, V., MINSHALL, G., PARTRIDGE, C., 1532 PETERSON, L., RAMAKRISHNAN, K., SHENKER, S., WROCLAWSKI, J. and L. 1533 ZHANG, "RECOMMENDATIONS ON QUEUE MANAGEMENT AND CONGESTION AVOIDANCE 1534 IN THE INTERNET", RFC 2309, April 1998. 1536 [7] NICHOLS, K., BLAKE, S., BAKER, F. and D. BLACK, "DEFINITION OF 1537 THE DIFFERENTIATED SERVICES FIELD (DS FIELD) IN THE IPV4 AND IPV6 1538 HEADERS", RFC 2474, December 1998. 1540 [8] BLAKE, S., BLACK, D., CARLSON, M., DAVIES, E., WANG, Z. and W. 1541 WEISS, "AN ARCHITECTURE FOR DIFFERENTIATED SERVICES", RFC 2475, 1542 December 1998. 1544 [9] ALLMAN, M., PAXSON, V. and W. STEVENS, "TCP CONGESTION 1545 CONTROL", RFC 2581, April 1999. 1547 [10] FLOYD, S. and T. HENDERSON, "THE NEWRENO MODIFICATION TO TCP'S 1548 FAST RECOVERY ALGORITHM", RFC 2582, April 1999. 1550 [11] HEINANEN, J., BAKER, F., WEISS, W. and J. WROCLAWSKI, "ASSURED 1551 FORWARDING PHB GROUP", RFC 2597, June 1999. 1553 [12] HERZOG, S., "RSVP EXTENSIONS FOR POLICY CONTROL", RFC 2750, 1554 January 2000. 1556 [13] Bernet, Y., "FORMAT OF THE RSVP DCLASS OBJECT", RFC 2996, 1557 November 2000. 1559 [14] Ramakrishnan, K., Floyd, S. and D. Black, "THE ADDITION OF 1560 EXPLICIT CONGESTION NOTIFICATION (ECN) TO IP", RFC 3168, September 1561 2001. 1563 [15] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, 1564 "AGGREGATION OF RSVP FOR IPV4 AND IPV6 RESERVATIONS", RFC 3175, 1565 September 2001. 1567 [16] Herzog, S., "SIGNALED PREEMPTION PRIORITY POLICY ELEMENT", RFC 1568 3181, October 2001. 1570 [17] Heinanen, J. and Guerin, R. "A SINGLE RATE THREE COLOR MARKER", 1571 RFC 2697, September 1999. 1573 [18] Heinanen, J. and Guerin, R. "A TWO RATE THREE COLOR MARKER", 1574 RFC 2698, September 1999. 1576 [19] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., 1577 Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "AN EXPEDITED 1578 FORWARDING PHB (PER-HOP BEHAVIOR)", RFC 3246, March 2002. 1580 [20] "QBone Scavenger Service (QBSS) Definition", Internet2 1581 Technical Report Proposed Service Definition, March 2001. 1583 9. Informative References 1585 [21] DURHAM, D., BOYLE, J., COHEN, R., HERZOG, S., RAJAN, R. and A. 1586 SASTRY, "THE COPS (COMMON OPEN POLICY SERVICE) PROTOCOL", RFC 2748, 1587 January 2000. 1589 [22] Bernet, Y. and R. Pabbati, "APPLICATION AND SUB APPLICATION 1590 IDENTITY POLICY ELEMENT FOR USE WITH RSVP", RFC 2872, June 2000. 1591 [23] Bonaventure, O. and S. De Cnodder, "A RATE ADAPTIVE SHAPER FOR 1592 DIFFERENTIATED SERVICES", RFC 2963, October 2000. 1594 [24] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., 1595 Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS USAGE 1596 FOR POLICY PROVISIONING (COPS-PR)", RFC 3084, March 2001. 1598 [25] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for 1599 Congestion Avoidance", IEEE/ACM Transactions on Networking , August 1600 1993. 1602 [26] Zhang, L., "Virtual Clock: A New Traffic control Algorithm for 1603 Packet Switching Networks", ACM SIGCOMM 1990, September 1990. 1605 [27] Keshav, S., "On the Efficient Implementation of Fair Queueing", 1606 Internetworking: Research and Experiences Vol 2, September 1991. 1608 [28] Katevenis, M., Sidiropoulos, S. and C. Courcoubetis, "Weighted 1609 Round-Robin Cell Multiplexing in a General Purpose ATM Switch Chip", 1610 IEEE JSAC Vol. 9, No. 8, October 1991. 1612 [29] "International Emergency Preparedness Scheme", ITU E.106, March 1613 2000. 1615 [30] "Service Description for an International Emergency Multimedia 1616 Service (Draft)", ITU-T F.706, August 2001. 1618 10. Author's Address 1620 Jozef Babiarz 1621 Nortel Networks 1622 3500 Carling Avenue 1623 Ottawa, Ont. Canada 1624 K2H 8E9 1625 Phone: +1-613-763-6098 1626 Fax: +1-613-768-2231 1627 EMail: babiarz@nortelnetworks.com 1629 Fred Baker 1630 Cisco Systems 1631 1121 Via Del Rey 1632 Santa Barbara, CA 93117 USA 1633 Phone: +1-408-526-4257 1634 Fax: +1-413-473-2403 1635 EMail: fred@cisco.com 1637 Kwok Ho Chan 1638 Nortel Networks 1639 600 Technology Park Drive 1640 Billerica, MA 01821 USA 1641 Phone: +1-978-288-8175 1642 Fax: +1-978-288-4690 1643 EMail: khchan@nortelnetworks.com 1645 11. Full Copyright Statement 1647 Copyright (C) The Internet Society (2003). All Rights Reserved. 1648 This document and translations of it may be copied and furnished to 1649 others, and derivative works that comment on or otherwise explain it 1650 or assist in its implementation may be prepared, copied, published 1651 and distributed, in whole or in part, without restriction of any 1652 kind, provided that the above copyright notice and this paragraph 1653 are included on all such copies and derivative works. However, this 1654 document itself may not be modified in any way, such as by removing 1655 the copyright notice or references to the Internet Society or other 1656 Internet organizations, except as needed for the purpose of 1657 developing Internet standards in which case the procedures for 1658 copyrights defined in the Internet Standards process must be 1659 followed, or as required to translate it into languages other than 1660 English. 1662 The limited permissions granted above are perpetual and will not be 1663 revoked by the Internet Society or its successors or assigns. 1665 This document and the information contained herein is provided on an 1666 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1667 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1668 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1669 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1670 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1672 Acknowledgement 1674 Funding for the RFC Editor function is currently provided by the 1675 Internet Society.