idnits 2.17.1 draft-ietf-ieprep-packet-marking-policy-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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 55 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 22, 2002) is 7942 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: '18' is defined on line 689, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 704, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 715, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 734, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 737, 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 3198 (ref. '18') -- Possible downref: Non-RFC (?) normative reference: ref. '20' Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Expires: January 20, 2003 July 22, 2002 6 Recommended Packet Marking Policy 7 draft-ietf-ieprep-packet-marking-policy-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on January 20, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This paper summarizes a recommended correlation of applications to 39 Differentiated Service Code Points. There is no intrinsic 40 requirement that individual DSCPs correspond to given applications, 41 but as a policy it is useful if they can be applied consistently. 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [3]. 47 1. Introduction 49 This paper summarizes a recommended correlation of applications to 50 Differentiated Service Code Points. There is no intrinsic 51 requirement that individual DSCPs correspond to given applications, 52 but as a policy it is useful if they can be applied consistently. 54 1.1 Expected use in the network 56 In the Internet today, corporate LANs and ISP WANs are generally not 57 heavily utilized - they are commonly 10% utilized at most. For this 58 reason, congestion, loss, and variation in delay within corporate 59 LANs and ISP backbones is virtually unknown. This clashes with user 60 perceptions, for three very good reasons. 62 o The industry moves through cycles of bandwidth boom and bandwidth 63 bust, depending on prevailing market conditions and the periodic 64 deployment of new bandwidth-hungry applications. 66 o In access networks, the state is often different. This may be 67 because throughput rates are artificially limited, or because of 68 access network design trade-offs. 70 o Other characteristics, such as database design on web servers 71 (which may create contention points, e.g. in filestore), and 72 configuration of firewalls and routers, often look externally like 73 a bandwidth limitation. 75 The intent of this document is to provide a consistent marking 76 strategy so that it can be configured and put into service on any 77 link which finds itself congested, typically access links. 79 1.2 Key Differentiated Services concepts 81 The reader must be familiar with the principles of the Differentiated 82 Services Architecture [8]. However, we recapitulate key concepts 83 here so save searching. 85 1.2.1 Queue or Class 87 A queue or class is a data structure that holds traffic that is 88 awaiting transmission. The traffic will be delayed while in the 89 queue, possibly due to lack of bandwidth, or because it is low in 90 priority. There are a number of ways to implement a queue; in some 91 of these, it is more natural to discuss "classes in a queuing system" 92 rather than "a set of queues and a scheduler". In the literature, as 93 a result, the concepts are used somewhat interchangeably. 95 A simple model of a queuing system, however, is a set of data 96 structures for packet data, which we will call queues or classes, and 97 a mechanism for selecting the next packet from among them, which we 98 call a scheduler. 100 1.2.1.1 Priority Queue 102 A priority queuing system is a combination of a set of queues and a 103 scheduler that empties them in priority sequence. When asked for a 104 packet, the scheduler inspects the first queue, and if there is data 105 present returns a packet from that queue. Failing that, it inspects 106 the second queue, and so on. A freeway onramp with a stoplight for 107 one lane, but which allows vehicles in the high occupancy vehicle 108 lane to pass, is an example of a priority queuing system; the high 109 occupancy vehicle lane represents the "queue" having priority. 111 In a priority queuing system, a packet in the highest priority queue 112 will experience a readily calculated delay - it is proportional to 113 the amount of data remaining to be serialized when the packet arrived 114 plus the volume of the data already queued ahead of it in the same 115 queue. The technical reason for using a priority queue relates 116 exactly to this fact: it limits variation in delay and delay, and 117 should be used for traffic which has that requirement. 119 1.2.1.2 Rate Queues 121 Similarly, a rate-based queuing system is a combination of a set of 122 queues and a scheduler that empties each at a specified rate. An 123 example of a rate based queuing system is a road intersection with a 124 stoplight - the stoplight acts as a scheduler, giving each lane a 125 certain opportunity to pass traffic through the intersection. 127 In a rate-based queuing system, such as WFQ [27][26] or WRR [28], the 128 delay that a packet in any given queue will experience is dependant 129 on the parameters and occupancy of its queue and the parameters and 130 occupancy of the queues it is competing with. A queue whose traffic 131 arrival rate is much less than the rate at which it lets traffic 132 depart will tend to be empty, and packets in it will experience 133 nominal delays. A packet whose arrival rate approximates or exceeds 134 its departure rate will tend to be full, and packets in it will 135 experience greater delay. Such a scheduler can impose a minimum 136 rate, a maximum rate, or both, on any queue it touches. 138 1.2.2 Active Queue Management 140 "Active queue management" or AQM is a generic name for any of a 141 variety of procedures that use packet dropping or marking to manage 142 the depth of a queue. The canonical example of such a procedure is 143 Random Early Detection [25], in which a queue is assigned a minimum 144 and maximum threshold, and the queuing algorithm maintains a moving 145 average of the queue depth. While the mean queue depth exceeds the 146 maximum threshold, all arriving traffic is dropped. While the mean 147 queue depth exceeds the minimum threshold but not the maximum 148 threshold, a randomly selected subset of arriving traffic is marked 149 or dropped. This marking or dropping of traffic is intended to 150 communicate with the sending system, causing its congestion avoidance 151 algorithms to kick in. As a result of this behavior, it is 152 reasonable to expect that TCP's cyclic behavior is desynchronized, 153 and the mean queue depth (and therefore delay) should normally 154 approximate the minimum threshold. 156 A variation of the algorithm is applied in Assured Forwarding [11], 157 in which the behavior aggregate consists of traffic with multiple 158 DSCP marks, which are intermingled in a common queue. Different 159 minima and maxima are configured for the several DSCPs separately, 160 such that traffic which exceeds a stated rate at ingress is more 161 likely to be dropped or marked than traffic which was within its 162 contracted rate. 164 1.2.3 Conditioning of traffic 166 Additionally, at the first router in a network that a packet crosses, 167 arriving traffic may be measured, and dropped or marked according to 168 a policy, or perhaps shaped on network ingress as in [23]. This may 169 be used to bias feedback loops, such as is done in Assured Forwarding 170 [11], or to limit the amount of traffic in a system, as is done in 171 Expedited Forwarding [19]. Such measurement procedures are 172 collectively referred to as "traffic conditioners". 174 1.2.4 Differentiated Services Code Point (DSCP) 176 The DSCP is a number in the range 0..63, which is placed into an IP 177 packet to mark it according to the class of traffic it belongs in. 178 Half of these values are earmarked for standardized services, and 179 half of them are available for local definition. 181 1.2.5 Per Hop Behavior (PHB) 183 In the end, the facilities just described are combined to form a 184 specified set of characteristics for handling different kinds of 185 traffic, depending on the needs of the application. This document 186 seeks to identify useful traffic aggregates and specify what PHB 187 should be applied to them. 189 1.3 Key Service concepts 191 While Differentiated Services is a general architecture that may be 192 used to implement a variety of services, three fundamental services 193 have been defined and characterized for general use. These are basic 194 service for elastic traffic, the Assured Forwarding service, and the 195 Expedited Forwarding service for real-time (inelastic) traffic. 197 The terms "elastic" and "real-time" are defined in RFC 1633 [2] 198 section 3.1, as a way of understanding broad brush application 199 requirements. This document should be reviewed to obtain a broad 200 understanding of the issues in quality of service, just as RFC 2475 201 [8] should be reviewed to understand the data plane architecture used 202 in today's Internet. 204 1.3.1 Best Effort Service 206 The basic services applied to any class of traffic are those 207 described in [7] and [6]. Best Effort Service may be summarized as 208 "I will accept your packets", with no further guarantees. Packets in 209 transit may be lost, reordered, duplicated, or delayed at random. 210 Generally, networks are engineered to limit this behavior, but 211 changing traffic loads can push any network into such a state. 213 Application traffic in the internet is expected to be "elastic" in 214 nature. By this, we mean that the receiver will detect loss or 215 variation in delay in the network and provide feedback such that the 216 sender adjusts its transmission rate to approximate available 217 capacity. 219 For basic best effort service classes, we provide a single DSCP value 220 to identify the traffic, a queue or class to store it, and active 221 queue management to protect the network from it and to limit delays. 222 The interesting thing is that by giving that queue a higher minimum 223 rate than its measured arrival rate, we can effectively limit the 224 deleterious effects of congestion on a given class of traffic, 225 transfering them to another class that is perhaps better able to 226 absorb the impact or is considered to be of lower value to the 227 network administration. So, for example, if it is important to 228 service database exchange or transaction traffic in a timely fashion, 229 isolating the traffic into a queue and giving it a relatively high 230 minimum rate will accomplish that. 232 1.3.2 Assured Forwarding (AF) 234 The Assured Forwarding [11] service is explicitly modeled on Frame 235 Relay's DE flag or ATM's CLP capability, and is intended for networks 236 which (as those do) offer average-rate SLAs. This is an enhanced 237 Best Effort service; traffic is expected to be "elastic" in nature. 238 By this, we mean that the receiver will detect loss or variation in 239 delay in the network and provide feedback such that the sender 240 adjusts its transmission rate to approximate available capacity. 242 For such classes, we provide a multiple DSCP values (two or three, 243 perhaps more using local values) to identify the traffic, a common 244 queue or class to store the aggregate, and active queue management to 245 protect the network from it and to limit delays. We meter traffic as 246 it enters the network, and traffic is variously marked depending on 247 the arrival rate of the aggregate. The premise is that it is normal 248 for users to occasionally use more capacity than their contract 249 stipulates, perhaps up to some bound. However, if traffic must be 250 lost or marked to manage the queue, this excess traffic will be 251 marked or lost first. 253 1.3.3 Expedited Forwarding (EF) 255 Expedited Forwarding [19] was originally proposed as a way to 256 implement a virtual wire, and can be used in such a manner. It is an 257 enhanced best effort service: traffic remains subject to loss due to 258 line errors and reordering during routing changes. However, using 259 queuing techniques, the probability of delay or variation in delay is 260 minimized. For this reason, it is generally used as the way to carry 261 voice, and perhaps video. Voice and video are inelastic "real-time" 262 applications - they send packets at the rate the codec produces them, 263 regardless of availability of capacity. As such, this service has 264 the potential to disrupt or congest a network if not controlled. It 265 also has the potential for abuse. 267 To protect the network, at minimum one must police traffic at various 268 points to ensure that the design of a queue is not over-run, and then 269 the traffic must be given a low delay queue (often using priority, 270 although it is asserted that a rate-based queue can do this) to 271 ensure that variation in delay is not an issue, to meet application 272 needs. 274 There is controversy regarding the place of signaling. Call 275 Admission Control, including call refusal when policy thresholds are 276 crossed, can assure high quality communication by ensuring the 277 availability of bandwidth to carry a load. For this purpose, RSVP 278 [4][13] was designed. However, there is concern with the scalability 279 [5] of that solution, and in large networks, aggregation [15] of 280 sessions is appropriate. 282 2. Specified Traffic Classes 284 Figure A shows eleven classes of traffic that are commonly specified 285 in enterprise networks or on access links. It is not mandatory to 286 configure any of them; common experience is that a small subset is 287 useful in any given network configuration. This specification 288 recommends that if such a service is deployed, it be deployed in a 289 manner consistent with this table. 291 +=====+======+====================+=====================+==============+ 292 |PHB | DSCP | DSCP | Reference | Intended protocols | Configuration| 293 +=====+======+========+===========+=====================+==============+ 294 |EF | EF | 101110 | RFC 3246 | Interactive Voice |RSVP Admission| 295 | | | | | |Priority queue| 296 +-----+------+--------+-----------+---------------------+--------------+ 297 |AF1 | AF11 | 001010 | RFC 2597 | Bulk transfers, web,| drop or mark | 298 | | AF12 | 001100 | | general data service| AF13 <= AF12 | 299 | | AF13 | 001110 | | | <= AF11,| 300 | | | | | possible guaranteed minimum rate| 301 | | | | | possible guaranteed maximum rate| 302 +-----+------+--------+-----------+---------------------+--------------+ 303 |AF2 | AF21 | 010010 | RFC 2597 | ERP Database access,| drop or mark | 304 | | AF22 | 010100 | | transaction services| AF23 <= AF22 | 305 | | AF23 | 010110 | | interactive traffic | <= AF21,| 306 | | | | | possible guaranteed minimum rate| 307 | | | | | possible guaranteed maximum rate| 308 +-----+------+--------+-----------+---------------------+--------------+ 309 |AF3 | AF31 | 011010 | RFC 2597 | Locally defined | drop or mark | 310 | | AF32 | 011100 | | mission-critical | AF33 <= AF32 | 311 | | AF33 | 011110 | | applications | <= AF31,| 312 | | | | | possible guaranteed minimum rate| 313 | | | | | possible guaranteed maximum rate| 314 +-----+------+--------+-----------+---------------------+--------------+ 315 |AF4 | AF41 | 100010 | RFC 2597 | Interactive video, | drop or mark | 316 | | AF42 | 100100 | | associated voice | AF43 <= AF42 | 317 | | AF43 | 100110 | | | <= AF41,| 318 | | | | | possible guaranteed minimum rate| 319 | | | | | possible guaranteed maximum rate| 320 | | | | | Bandwidth Signaling| 321 +-----+------+--------+-----------+---------------------+--------------+ 322 |IP |Class6| 110000 | RFC 2474 | BGP, OSPF, etc | minimum rate | 323 |Routing | | section 4.2.2 |Deep Queue AQM| 324 +-----+------+--------+-----------+---------------------+--------------+ 325 |Streaming | 100000 | RFC 2474 | Often proprietary | minimum rate | 326 |Video|Class4| | section 4.2.2 | AQM | 327 +-----+------+--------+-----------+---------------------+--------------+ 328 +=====+======+====================+=====================+==============+ 329 |PHB | DSCP | DSCP | Reference | Intended protocols | Configuration| 330 +=====+======+========+===========+=====================+==============+ 331 | |Class3| 011000 | RFC 2474 | SIP, | minimum rate | 332 |Telephony | | section 4.2.2 H.245/H.225 |Deep Queue AQM| 333 |Signaling | | | | | 334 |voice/video | | | | | 335 +-----+------+--------+-----------+---------------------+--------------+ 336 | |Class2| 010000 | RFC 2474 | SNMP | minimum rate | 337 |Network | | section 4.2.2 | AQM | 338 |Management | | | | | 339 +-----+------+--------+-----------+---------------------+--------------+ 340 | |class1| 001000 |Internet II|User-selected service| AQM | 341 |Scavenger | | QBSS | | | 342 +-----+------+--------+-----------+---------------------+--------------+ 343 | |class0| 000000 | RFC 2474 | Unspecified traffic | minimum rate | 344 |Default | | section 4.1 | AQM | 345 +=====+======+========+===========+=====================+==============+ 347 Figure A: Summary of specified Differentiated Services classes 349 2.1 Voice on IP 351 The voice traffic class serves RTP voice. It is specified in [19]. 353 The fundamental service offered to voice traffic is best effort 354 service up to a specified upper bound with nominal delay. Operation 355 is in some respects similar to an ATM CBR VC. The ATM VC is 356 guaranteed its bandwidth, and if it stays within the negotiated rate 357 it experiences nominal loss and delay. EF traffic has a similar 358 guarantee. 360 Typical configurations negotiate the use of Voice on IP using 361 protocols such as SIP and RSVP. When a user has been authorized to 362 send voice traffic, this admission procedure has verified that data 363 rates will be within the capacity of the network that it will use. 364 Since RTP voice does not respond to loss or marking in any 365 substantive way, the network must police at ingress to ensure that 366 the voice traffic stays within its negotiated bounds. Having thus 367 assured a predictable input rate, the network may use a priority 368 queue to ensure nominal delay and variation in delay. 370 When used to give preferential service, the preferred systems or 371 sessions must be authenticated during the process of resource 372 assignment [12][22][16][17]. They may be given preferential access 373 in whatever manner is appropriate. 375 2.2 File Transfer Service 377 The File Transfer traffic class serves applications which run over 378 TCP [1] or a transport with a consistent congestion avoidance 379 procedure [9][10], and normally drive as high a data rate as they can 380 obtain over a long period of time. The FTP protocol is a common 381 example, although one cannot definitively say that all FTP transfers 382 are moving data in bulk. The PHB is specified in [11]. 384 The fundamental service offered to file transfer traffic is best 385 effort service with a specified minimum rate. One must assume that 386 this class will consume any available capacity, and on congested 387 links may experience queuing delay or loss. 389 Typical configurations use Explicit Congestion Notification [14] or 390 random loss to implement active queue management [6], and may impose 391 a minimum or maximum rate. In queues, the probability of loss of 392 AF11 traffic may not exceed the probability of loss of AF12 traffic, 393 which in turn may not exceed the probability of loss of AF13 traffic. 394 Ingress traffic conditioning passes traffic in the class up to some 395 specified threshold marked AF11, additional traffic up to some 396 secondary threshold marked as AF12, and potentially passes additional 397 traffic marked AF13. In such a case, if one network customer is 398 driving significant excess and another seeks to use the link, any 399 losses will be experienced by the high rate user, causing him to 400 reduce his rate. 402 When used to give preferential service, the preferred systems or 403 sessions must be authenticated, and ingress policing increases the 404 drop or mark probability of any authorized traffic, it must increase 405 the drop or mark probability of all unauthorized traffic. 407 2.3 Human-response Applications 409 The human response traffic class serves applications which run over 410 TCP [1] or a transport with a consistent congestion avoidance 411 procedure [9][10], and serve transaction, database access, or 412 interactive protocols. Such applications might include telnet, 413 common ERP applications, instant messaging, or other applications, 414 which hold a user waiting until they respond. The PHB is specified 415 in [11]. 417 The fundamental service offered to human response traffic is best 418 effort service with a specified minimum rate. The rate should be 419 specified significantly in excess of actual measured rates, in order 420 to ensure that this traffic experiences only nominal delay or loss. 422 Typical configurations use Explicit Congestion Notification [14] or 423 random loss to implement active queue management [6], and may impose 424 a minimum or maximum rate. In queues, the probability of loss of 425 AF21 traffic may not exceed the probability of loss of AF22 traffic, 426 which in turn may not exceed the probability of loss of AF23 traffic. 428 When used to give preferential service, the preferred systems or 429 sessions must be authenticated, and ingress policing increases the 430 drop or mark probability of any authorized traffic, it must increase 431 the drop or mark probability of all unauthorized traffic. 433 2.4 Mission Specific and Critical Applications 435 The mission-specific traffic class serves applications which run over 436 TCP [1] or a transport with a consistent congestion avoidance 437 procedure [9][10], and serve needs the network administrator deems to 438 need special support. For example, in a banking network, it might 439 support electronic banking protocols. The PHB is specified in [11]. 441 The fundamental service offered to mission critical traffic is best 442 effort service with a specified minimum rate. The rate should be 443 specified significantly in excess of actual measured rates, in order 444 to ensure that this traffic experiences only nominal delay or loss. 446 Typical configurations use Explicit Congestion Notification [14] or 447 random loss to implement active queue management [6], and may impose 448 a minimum or maximum rate. In queues, the probability of loss of 449 AF31 traffic may not exceed the probability of loss of AF32 traffic, 450 which in turn may not exceed the probability of loss of AF33 traffic. 452 When used to give preferential service, the preferred systems or 453 sessions must be authenticated, and ingress policing increases the 454 drop or mark probability of any authorized traffic, it must increase 455 the drop or mark probability of all unauthorized traffic. 457 2.5 Network Multimedia (video) 459 The Network Multimedia traffic class serves applications that carry 460 RTP data streams whose rate has been negotiated with the network 461 using a protocol such as RSVP [4]. If the mean rate is conceived as 462 Bc/frame interval and the difference between the mean and peak rate 463 is Be/frame interval, the first Bc packets in a frame are marked 464 AF41, the next Be packets are marked AF42, and any additional packets 465 may be summarily dropped, or marked AF43 and subjected to loss in any 466 but a queue of nominal depth. This PHB is specified in [11]. 468 The fundamental service offered to network multimedia traffic is best 469 effort service with controlled rate and delay. This traffic does not 470 respond to loss or marking, and can be severely compromise by loss or 471 delays that exceed its framing interval. It can be assumed, however, 472 to have been initially transmitted in a manner roughly comparable to 473 [23]. As such, active queue management [6] serves primarily to deal 474 with extreme cases; ingress traffic conditioning is depended on to 475 ensure rate compliance. In queues, the probability of loss of AF41 476 traffic may not exceed the probability of loss of AF42 traffic, which 477 in turn may not exceed the probability of loss of AF43 traffic if 478 any. 480 When used to give preferential service, the preferred systems or 481 sessions must be authenticated during the process of resource 482 assignment [12][22][16][17]. They may be given preferential access 483 in whatever manner is appropriate. 485 2.6 IP Routing Protocols 487 The IP Routing traffic class serves IP Routing Applications such as 488 BGP or OSPF. It is specified in [7]. 490 The fundamental service offered to routing traffic is best effort 491 service with minimal loss, even at the cost of delays on the order of 492 tens to hundreds of milliseconds. By placing it into a separate 493 queue or class to minimize loss, the routing it supports is helped to 494 converge. 496 Typical configurations use Explicit Congestion Notification [14] or 497 random loss to implement active queue management [6], and may impose 498 a minimum or maximum rate. 500 Preferential access is undefined for this traffic class. 502 2.7 Streaming Video 504 The streaming video traffic class serves applications like Windows 505 Media Player or RealAudio. These may use standard or proprietary 506 bulk transfer protocols, using TCP as a transport or application- 507 specific transports built on UDP, for buffering prior to playout. 508 The service model is specified in [7]. 510 The fundamental service offered to streaming video is best effort 511 service. By placing it into a separate queue or class, it may be 512 ensured minima or maxima consistent with a specific service level 513 agreement. 515 Typical configurations use Explicit Congestion Notification [14] or 516 random loss to implement active queue management [6], and may impose 517 a minimum or maximum rate. 519 Preferential access is undefined for this traffic class. 521 2.8 Telephony Signaling 523 The Telephony Signaling traffic class serves network control 524 applications like SIP and H.245/H.225 when used to route Voice on 525 IP, Video on IP, and related applications. It is specified in [7]. 527 The fundamental service offered to Telephony Signaling traffic is 528 best effort service with minimize loss. The reason for this is to 529 maximize the speed of such routing, and avoid the poor user 530 experience that results from loss of control traffic. By placing it 531 into a separate queue or class, it may be ensured minima or maxima 532 consistent with a specific service level agreement. 534 Typical configurations use Explicit Congestion Notification [14] or 535 random loss to implement active queue management [6], and may impose 536 a minimum or maximum rate. The AQM parameters are specified in such 537 a manner as to permit relatively deep queues to form temporarily. 539 Preferential access is undefined for this traffic class. 541 2.9 Network Management 543 The management traffic class serves applications that are necessary 544 to manage the network, such as SNMP servers, but which implement no 545 congestion avoidance procedure. It is specified in [7]. 547 The fundamental service offered to the network traffic class is best 548 effort service with minimization of loss. By placing it into a 549 separate queue or class, it may be ensured minima or maxima 550 consistent with a specific service level agreement. 552 Typical configurations use random loss to implement active queue 553 management [6], to maximize the utility of network management 554 applications while protecting the network in the event of an 555 overload. 557 Preferential access is undefined for this traffic class. 559 2.10 Scavenger class 561 The scavenger traffic class serves applications which run over TCP 562 [1] or a transport with a consistent congestion avoidance procedure 563 [9][10], and which the user is willing to accept service without 564 guarantees. It is specified in [20]. 566 The fundamental service offered to the scavenger traffic class is 567 best effort service. By placing it into a separate queue or class, 568 it may be treated in a manner consistent with a specific service 569 level agreement. 571 Typical configurations use Explicit Congestion Notification [14] or 572 random loss to implement active queue management [6]. It generally 573 does not impose a minimum or maximum rate, although it could. 575 Preferential access is undefined for this traffic class. 577 2.11 Default traffic class 579 The default traffic class serves applications which have not been 580 otherwise specified, but which run over TCP [1] or a transport with 581 a consistent congestion avoidance procedure [9][10]. It is specified 582 in [7]. 584 The fundamental service offered to the default traffic class is best 585 effort service with active queue management to limit over-all delay. 586 By placing it into a separate queue or class, it may be ensured 587 minima or maxima consistent with a specific service level agreement. 589 Typical configurations use Explicit Congestion Notification [14] or 590 random loss to implement active queue management [6], and may impose 591 a minimum or maximum rate on the queue. 593 Preferential access is undefined for this traffic class. 595 3. Security Considerations 597 This document discusses policy, and describes a common policy 598 configuration, for the use of a Differentiated Services Code Point by 599 transports and applications. If implemented as described, it should 600 ask the network to do nothing that the network has not already 601 allowed. If that is the case, no new security issues should arise 602 from the use of such a policy. 604 It is possible, however, for the policy to be applied incorrectly, or 605 for another policy to be applied, which would be incorrect in the 606 network. In that case, a policy issue exists which the network must 607 detect, assess, and deal with. This is a known security issue in any 608 network dependent on policy-directed behavior. 610 A well-known flaw applies when bandwidth is reserved or enabled for a 611 service (for example, voice transport) and another service or an 612 attacking traffic stream uses it. This possibility is inherent in 613 diffserv technology, which depends on appropriate packet markings. 614 When bandwidth reservation or a priority queuing system is used in a 615 vulnerable network, the use of a scheme such as RSVP Policy Marking 616 [12] and RSVP Identity [16] is important. To the author's knowledge, 617 there is no technical way to respond to an unauthenticated data 618 stream using service that it is not intended to use, and such is the 619 nature of the Internet. 621 4. Acknowledgements 623 The author acknowledges a great many inputs, most notably from Bruce 624 Davie, Dave Oran. Kimberly King and Alistair Munroe each did a 625 thorough proof-reading, and the document is better for it. 627 Normative References 629 [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 630 September 1981. 632 [2] Braden, B., Clark, D. and S. Shenker, "Integrated Services in 633 the Internet Architecture: an Overview", RFC 1633, June 1994. 635 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 636 Levels", BCP 14, RFC 2119, March 1997. 638 [4] Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource 639 ReSerVation Protocol (RSVP) -- Version 1 Functional 640 Specification", RFC 2205, September 1997. 642 [5] Baker, F., Krawczyk, J. and A. Sastry, "RSVP Management 643 Information Base using SMIv2", RFC 2206, September 1997. 645 [6] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., 646 Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, 647 C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. 648 and L. Zhang, "Recommendations on Queue Management and 649 Congestion Avoidance in the Internet", RFC 2309, April 1998. 651 [7] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of 652 the Differentiated Services Field (DS Field) in the IPv4 and 653 IPv6 Headers", RFC 2474, December 1998. 655 [8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. 656 Weiss, "An Architecture for Differentiated Services", RFC 2475, 657 December 1998. 659 [9] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 660 Control", RFC 2581, April 1999. 662 [10] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's 663 Fast Recovery Algorithm", RFC 2582, April 1999. 665 [11] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured 666 Forwarding PHB Group", RFC 2597, June 1999. 668 [12] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, 669 January 2000. 671 [13] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, 672 November 2000. 674 [14] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 675 Explicit Congestion Notification (ECN) to IP", RFC 3168, 676 September 2001. 678 [15] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, 679 "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, 680 September 2001. 682 [16] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 683 3181, October 2001. 685 [17] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 686 Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 687 3182, October 2001. 689 [18] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 690 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. 691 Waldbusser, "Terminology for Policy-Based Management", RFC 692 3198, November 2001. 694 [19] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., 695 Courtney, W., Davari, S., Firoiu, V. and D. Stiliadis, "An 696 Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 697 2002. 699 [20] , "QBone Scavenger Service (QBSS) Definition", Internet2 700 Technical Report Proposed Service Definition, March 2001. 702 Informative References 704 [21] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. 705 Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 706 2748, January 2000. 708 [22] Bernet, Y. and R. Pabbati, "Application and Sub Application 709 Identity Policy Element for Use with RSVP", RFC 2872, June 710 2000. 712 [23] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper for 713 Differentiated Services", RFC 2963, October 2000. 715 [24] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., 716 Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS 717 Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. 719 [25] Floyd, S. and V. Jacobson, "Random Early Detection Gateways for 720 Congestion Avoidance", IEEE/ACM Transactions on Networking , 721 August 1993. 723 [26] Zhang, L., "Virtual Clock: A New Traffic control Algorithm for 724 Packet Switching Networks", ACM SIGCOMM 1990, September 1990. 726 [27] Keshav, S., "On the Efficient Implementation of Fair Queueing", 727 Internetworking: Research and Experiences Vol 2, September 728 1991. 730 [28] Katevenis, M., Sidiropoulos, S. and C. Courcoubetis, "Weighted 731 Round-Robin Cell Multiplexing in a General Purpose ATM Switch 732 Chip", IEEE JSAC Vol. 9, No. 8, October 1991. 734 [29] "International Emergency Preparedness Scheme", ITU E.106, March 735 2000. 737 [30] "Service Description for an International Emergency Multimedia 738 Service (Draft)", ITU-T F.706, August 2001. 740 Author's Address 742 Fred Baker 743 Cisco Systems 744 1121 Via Del Rey 745 Santa Barbara, CA 93117 746 US 748 Phone: +1-408-526-4257 749 Fax: +1-413-473-2403 750 EMail: fred@cisco.com 752 Full Copyright Statement 754 Copyright (C) The Internet Society (2002). All Rights Reserved. 756 This document and translations of it may be copied and furnished to 757 others, and derivative works that comment on or otherwise explain it 758 or assist in its implementation may be prepared, copied, published 759 and distributed, in whole or in part, without restriction of any 760 kind, provided that the above copyright notice and this paragraph are 761 included on all such copies and derivative works. However, this 762 document itself may not be modified in any way, such as by removing 763 the copyright notice or references to the Internet Society or other 764 Internet organizations, except as needed for the purpose of 765 developing Internet standards in which case the procedures for 766 copyrights defined in the Internet Standards process must be 767 followed, or as required to translate it into languages other than 768 English. 770 The limited permissions granted above are perpetual and will not be 771 revoked by the Internet Society or its successors or assigns. 773 This document and the information contained herein is provided on an 774 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 775 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 776 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 777 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 778 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 780 Acknowledgement 782 Funding for the RFC Editor function is currently provided by the 783 Internet Society.