idnits 2.17.1 draft-ietf-diffserv-af-06.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 101 lines == It seems as if not all pages are separated by form feeds - found 8 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) ** The abstract seems to contain references ([Blake]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 119: '... drop precedence MAY be defined for lo...' RFC 2119 keyword, line 121: '... A DS node SHOULD implement all four...' RFC 2119 keyword, line 122: '... in one AF class MUST be forwarded ind...' RFC 2119 keyword, line 123: '... i.e., a DS node MUST NOT aggregate tw...' RFC 2119 keyword, line 126: '... A DS node MUST allocate a configura...' (26 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [Bradner], but that reference does not seem to mention RFC 2119 either. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Blake' on line 376 looks like a reference -- Missing reference section? 'Clark' on line 382 looks like a reference -- Missing reference section? 'Bradner' on line 379 looks like a reference -- Missing reference section? 'Floyd' on line 386 looks like a reference -- Missing reference section? 'Nichols' on line 390 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Juha Heinanen 3 INTERNET DRAFT Telia Finland 4 Expires August 1999 Fred Baker 5 Cisco Systems 6 Walter Weiss 7 Lucent Technologies 8 John Wroclawski 9 MIT LCS 10 February, 1999 12 Assured Forwarding PHB Group 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Distribution of this memo is unlimited. 38 Copyright Notice 40 Copyright (C) The Internet Society (1998). All Rights Reserved. 42 Abstract 44 This document defines a general use Differentiated Services (DS) 45 [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). 46 The AF PHB group provides delivery of IP packets in four 47 independently forwarded AF classes. Within each AF class, an IP 48 packet can be assigned one of three different levels of drop 49 precedence. A DS node does not reorder IP packets of the same 50 microflow if they belong to the same AF class. 52 1. Purpose and Overview 54 There is a demand to provide assured forwarding of IP packets over 55 the Internet. In a typical application, a company uses the Internet 56 to interconnect its geographically distributed sites and wants an 57 assurance that IP packets within this intranet are forwarded with 58 high probability as long as the aggregate traffic from each site does 59 not exceed the subscribed information rate (profile). It is 60 desirable that a site may exceed the subscribed profile with the 61 understanding that the excess traffic is not delivered with as high 62 probability as the traffic that is within the profile. It is also 63 important that the network does not reorder packets that belong to 64 the same microflow no matter if they are in or out of the profile. 66 Assured Forwarding (AF) PHB group is a means for a provider DS domain 67 to offer different levels of forwarding assurances for IP packets 68 received from a customer DS domain. Four AF classes are defined, 69 where each AF class is in each DS node allocated a certain amount of 70 forwarding resources (buffer space and bandwidth). IP packets that 71 wish to use the services provided by the AF PHB group are assigned by 72 the customer or the provider DS domain into one or more of these AF 73 classes according to the services that the customer has subscribed 74 to. Further background about this capability and some ways to use it 75 may be found in [Clark]. 77 Within each AF class IP packets are marked (again by the customer or 78 the provider DS domain) with one of three possible drop precedence 79 values. In case of congestion, the drop precedence of a packet 80 determines the relative importance of the packet within the AF class. 81 A congested DS node tries to protect packets with a lower drop 82 precedence value from being lost by preferably discarding packets 83 with a higher drop precedence value. 85 In a DS node, the level of forwarding assurance of an IP packet thus 86 depends on (1) how much forwarding resources has been allocated to 87 the AF class that the packet belongs to, (2) what is the current load 88 of the AF class, and, in case of congestion within the class, (3) 89 what is the drop precedence of the packet. 91 For example, if traffic conditioning actions at the ingress of the 92 provider DS domain make sure that an AF class in the DS nodes is only 93 moderately loaded by packets with the lowest drop precedence value 94 and is not overloaded by packets with the two lowest drop precedence 95 values, then the AF class can offer a high level of forwarding 96 assurance for packets that are within the subscribed profile (i.e., 97 marked with the lowest drop precedence value) and offer up to two 98 lower levels of forwarding assurance for the excess traffic. 100 This document describes the AF PHB group. An otherwise DS-compliant 101 node is not required to implement this PHB group in order to be 102 considered DS-compliant, but when a DS-compliant node is said to 103 implement an AF PHB group, it must conform to the specification in 104 this document. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [Bradner]. 110 2. The AF PHB Group 112 Assured Forwarding (AF) PHB group provides forwarding of IP packets 113 in N independent AF classes. Within each AF class, an IP packet is 114 assigned one of M different levels of drop precedence. An IP packet 115 that belongs to an AF class i and has drop precedence j is marked 116 with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M. 117 Currently, four classes (N=4) with three levels of drop precedence in 118 each class (M=3) are defined for general use. More AF classes or 119 levels of drop precedence MAY be defined for local use. 121 A DS node SHOULD implement all four general use AF classes. Packets 122 in one AF class MUST be forwarded independently from packets in 123 another AF class, i.e., a DS node MUST NOT aggregate two or more AF 124 classes together. 126 A DS node MUST allocate a configurable, minimum amount of forwarding 127 resources (buffer space and bandwidth) to each implemented AF class. 128 Each class SHOULD be serviced in a manner to achieve the configured 129 service rate (bandwidth) over both small and large time scales. 131 An AF class MAY also be configurable to receive more forwarding 132 resources than the minimum when excess resources are available either 133 from other AF classes or from other PHB groups. This memo does not 134 specify how the excess resources should be allocated, but 135 implementations MUST specify what algorithms are actually supported 136 and how they can be parameterized. 138 Within an AF class, a DS node MUST NOT forward an IP packet with 139 smaller probability if it contains a drop precedence value p than if 140 it contains a drop precedence value q when p < q. Note that this 141 requirement can be fulfilled without needing to dequeue and discard 142 already-queued packets. 144 Within each AF class, a DS node MUST accept all three drop precedence 145 codepoints and they MUST yield at least two different levels of loss 146 probability. In some networks, particularly in enterprise networks, 147 where transient congestion is a rare and brief occurrence, it may be 148 reasonable for a DS node to implement only two different levels of 149 loss probability per AF class. While this may suffice for some 150 networks, three different levels of loss probability SHOULD be 151 supported in DS domains where congestion is a common occurrence. 153 If a DS node only implements two different levels of loss probability 154 for an AF class x, the codepoint AFx1 MUST yield the lower loss 155 probability and the codepoints AFx2 and AFx3 MUST yield the higher 156 loss probability. 158 A DS node MUST NOT reorder AF packets of the same microflow when they 159 belong to the same AF class regardless of their drop precedence. 160 There are no quantifiable timing requirements (delay or delay 161 variation) associated with the forwarding of AF packets. 163 The relationship between AF classes and other PHBs is described in 164 Section 7 of this memo. 166 The AF PHB group MAY be used to implement both end-to-end and domain 167 edge-to-domain edge services. 169 3. Traffic Conditioning Actions 171 A DS domain MAY at the edge of a domain control the amount of AF 172 traffic that enters or exits the domain at various levels of drop 173 precedence. Such traffic conditioning actions MAY include traffic 174 shaping, discarding of packets, increasing or decreasing the drop 175 precedence of packets, and reassigning of packets to other AF 176 classes. The traffic conditioning actions MUST NOT cause reordering 177 of packets of the same microflow. 179 4. Queueing and Discard Behavior 181 This section defines the queueing and discard behavior of the AF PHB 182 group. Other aspects of the PHB group's behavior are defined in 183 Section 2. 185 An AF implementation MUST attempt to minimize long-term congestion 186 within each class, while allowing short-term congestion resulting 187 from bursts. This requires an active queue management algorithm. An 188 example of such an algorithm is Random Early Drop (RED) [Floyd]. 189 This memo does not specify the use of a particular algorithm, but 190 does require that several properties hold. 192 An AF implementation MUST detect and respond to long-term congestion 193 within each class by dropping packets, while handling short-term 194 congestion (packet bursts) by queueing packets. This implies the 195 presence of a smoothing or filtering function that monitors the 196 instantaneous congestion level and computes a smoothed congestion 197 level. The dropping algorithm uses this smoothed congestion level to 198 determine when packets should be discarded. 200 The dropping algorithm MUST be insensitive to the short-term traffic 201 characteristics of the microflows using an AF class. That is, flows 202 with different short-term burst shapes but identical longer-term 203 packet rates should have packets discarded with essentially equal 204 probability. One way to achieve this is to use randomness within the 205 dropping function. 207 The dropping algorithm MUST treat all packets within a single class 208 and precedence level identically. This implies that for any given 209 smoothed congestion level, the discard rate of a particular 210 microflow's packets within a single precedence level will be 211 proportional to that flow's percentage of the total amount of traffic 212 passing through that precedence level. 214 The congestion indication feedback to the end nodes, and thus the 215 level of packet discard at each drop precedence in relation to 216 congestion, MUST be gradual rather than abrupt, to allow the overall 217 system to reach a stable operating point. One way to do this (RED) 218 uses two (configurable) smoothed congestion level thresholds. When 219 the smoothed congestion level is below the first threshold, no 220 packets of the relevant precedence are discarded. When the smoothed 221 congestion level is between the first and the second threshold, 222 packets are discarded with linearly increasing probability, ranging 223 from zero to a configurable value reached just prior to the second 224 threshold. When the smoothed congestion level is above the second 225 threshold, packets of the relevant precedence are discarded with 100% 226 probability. 228 To allow the AF PHB to be used in many different operating 229 environments, the dropping algorithm control parameters MUST be 230 independently configurable for each packet drop precedence and for 231 each AF class. 233 Within the limits above, this specification allows for a range of 234 packet discard behaviors. Inconsistent discard behaviors lead to 235 inconsistent end-to-end service semantics and limit the range of 236 possible uses of the AF PHB in a multi-vendor environment. As 237 experience is gained, future versions of this document may more 238 tightly define specific aspects of the desirable behavior. 240 5. Tunneling 242 When AF packets are tunneled, the PHB of the tunneling packet MUST 243 NOT reduce the forwarding assurance of the tunneled AF packet nor 244 cause reordering of AF packets belonging to the same microflow. 246 6. Recommended Codepoints 248 Recommended codepoints for the four general use AF classes are given 249 below. These codepoints do not overlap with any other general use PHB 250 groups. 252 The RECOMMENDED values of the AF codepoints are as follows: AF11 = 253 '001010', AF12 = '001100', AF13 = '001110', AF21 = '010010', AF22 = 254 '010100', AF23 = '010110', AF31 = '011010', AF32 = '011100', AF33 = 255 '011110', AF41 = '100010', AF42 = '100100', and AF43 = '100110'. The 256 table below summarizes the recommended AF codepoint values. 258 Class 1 Class 2 Class 3 Class 4 259 +----------+----------+----------+----------+ 260 Low Drop Prec | 001010 | 010010 | 011010 | 100010 | 261 Medium Drop Prec | 001100 | 010100 | 011100 | 100100 | 262 High Drop Prec | 001110 | 010110 | 011110 | 100110 | 263 +----------+----------+----------+----------+ 265 7. Interactions with Other PHB Groups 267 The AF codepoint mappings recommended above do not interfere with the 268 local use spaces nor the Class Selector codepoints recommended in 269 [Nichols]. The PHBs selected by those Class Selector codepoints may 270 thus coexist with the AF PHB group and retain the forwarding behavior 271 and relationships that was defined for them. In particular, the 272 Default PHB codepoint of '000000' may remain to be used for 273 conventional best effort traffic. Similarly, the codepoints '11x000' 274 may remain to be used for network control traffic. 276 The AF PHB group, in conjunction with edge traffic conditioning 277 actions that limit the amount of traffic in each AF class to a 278 (generally different) percentage of the class's allocated resources, 279 can be used to obtain the overall behavior implied by the Class 280 Selector PHBs. In this case it may be appropriate within a DS domain 281 to use some or all of the Class Selector codepoints as aliases of AF 282 codepoints. 284 In addition to the Class Selector PHBs, any other PHB groups may co- 285 exist with the AF PHB group within the same DS domain. However, any 286 AF PHB group implementation should document the following: 288 (a) Which, if any, other PHB groups may preempt the forwarding 289 resources specifically allocated to each AF PHB class. This 290 preemption MUST NOT happen in normal network operation, but may be 291 appropriate in certain unusual situations - for example, the '11x000' 292 codepoint may preempt AF forwarding resources, to give precedence to 293 unexpectedly high levels of network control traffic when required. 295 (b) How "excess" resources are allocated between the AF PHB group and 296 other implemented PHB groups. For example, once the minimum 297 allocations are given to each AF class, any remaining resources could 298 be allocated evenly between the AF classes and the Default PHB. In 299 an alternative example, any remaining resources could be allocated to 300 forwarding excess AF traffic, with resources devoted to the Default 301 PHB only when all AF demand is met. 303 This memo does not specify that any particular relationship hold 304 between AF PHB groups and other implemented PHB groups; it requires 305 only that whatever relationship is chosen be documented. 306 Implementations MAY allow either or both of these relationships to be 307 configurable. It is expected that this level of configuration 308 flexibility will prove valuable to many network administrators. 310 8. Security Implications 312 In order to protect itself against denial of service attacks, a 313 provider DS domain SHOULD limit the traffic entering the domain to 314 the subscribed profiles. Also, in order to protect a link to a 315 customer DS domain from denial of service attacks, the provider DS 316 domain SHOULD allow the customer DS domain to specify how the 317 resources of the link are allocated to AF packets. If a service 318 offering requires that traffic marked with an AF codepoint be limited 319 by such attributes as source or destination address, it is the 320 responsibility of the ingress node in a network to verify validity of 321 such attributes. 323 Other security considerations are covered in [Blake] and [Nichols]. 325 Appendix: Example Services 327 The AF PHB group could be used to implement, for example, the so- 328 called Olympic service, which consists of three service classes: 329 bronze, silver, and gold. Packets are assigned to these three 330 classes so that packets in the gold class experience lighter load 331 (and thus have greater probability for timely forwarding) than 332 packets assigned to the silver class. Same kind of relationship 333 exists between the silver class and the bronze class. If desired, 334 packets within each class may be further separated by giving them 335 either low, medium, or high drop precedence. 337 The bronze, silver, and gold service classes could in the network be 338 mapped to the AF classes 1, 2, and 3. Similarly, low, medium, and 339 high drop precedence may be mapped to AF drop precedence levels 1, 2, 340 or 3. 342 The drop precedence level of a packet could be assigned, for example, 343 by using a leaky bucket traffic policer, which has as its parameters 344 a rate and a size, which is the sum of two burst values: a committed 345 burst size and an excess burst size. A packet is assigned low drop 346 precedence if the number of tokens in the bucket is greater than the 347 excess burst size, medium drop precedence if the number of tokens in 348 the bucket is greater than zero, but at most the excess burst size, 349 and high drop precedence if the bucket is empty. It may also be 350 necessary to set an upper limit to the amount of high drop precedence 351 traffic from a customer DS domain in order to avoid the situation 352 where an avalanche of undeliverable high drop precedence packets from 353 one customer DS domain can deny service to possibly deliverable high 354 drop precedence packets from other domains. 356 Another way to assign the drop precedence level of a packet could be 357 to limit the user traffic of an Olympic service class to a given peak 358 rate and distribute it evenly across each level of drop precedence. 359 This would yield a proportional bandwidth service, which equally 360 apportions available capacity during times of congestion under the 361 assumption that customers with high bandwidth microflows have 362 subscribed to higher peak rates than customers with low bandwidth 363 microflows. 365 The AF PHB group could also be used to implement a loss and low 366 latency service using an over provisioned AF class, if the maximum 367 arrival rate to that class is known a priori in each DS node. 368 Specification of the required admission control services, however, is 369 beyond the scope of this document. If low loss is not an objective, 370 a low latency service could be implemented without over provisioning 371 by setting a low maximum limit to the buffer space available for an 372 AF class. 374 References 376 [Blake] Blake, Steve, et al., An Architecture for Differentiated 377 Services. RFC 2475, December 1998. 379 [Bradner] Bradner, S., Key words for use in RFCs to Indicate 380 Requirement Levels. RFC 2119, March 1997. 382 [Clark] Clark, D. and Fang, W., Explicit Allocation of Best Effort 383 Packet Delivery Service. IEEE/ACM Transactions on Networking, Volume 384 6, Number 4, August 1998, pp. 362-373. 386 [Floyd] Floyd, S., and Jacobson, V., Random Early Detection gateways 387 for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume 388 1, Number 4, August 1993, pp. 397-413. 390 [Nichols] Nichols, Kathleen, et al., Definition of the Differentiated 391 Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, 392 December 1998. 394 Author Information 396 Juha Heinanen 397 Telia Finland 398 Myyrmaentie 2 399 01600 Vantaa, Finland 400 Email: jh@telia.fi 402 Fred Baker 403 Cisco Systems 404 519 Lado Drive 405 Santa Barbara, California 93111 406 E-mail: fred@cisco.com 408 Walter Weiss 409 Lucent Technologies 410 300 Baker Avenue, Suite 100, 411 Concord, MA 01742-2168 412 E-mail: wweiss@lucent.com 414 John Wroclawski 415 MIT Laboratory for Computer Science 416 545 Technology Sq. 417 Cambridge, MA 02139 418 Email: jtw@lcs.mit.edu 420 Full Copyright Statement 422 Copyright (C) The Internet Society (1998). All Rights Reserved. 424 This document and translations of it may be copied and furnished to 425 others, and derivative works that comment on or otherwise explain it 426 or assist in its implementation may be prepared, copied, published 427 and distributed, in whole or in part, without restriction of any 428 kind, provided that the above copyright notice and this paragraph are 429 included on all such copies and derivative works. However, this 430 document itself may not be modified in any way, such as by removing 431 the copyright notice or references to the Internet Society or other 432 Internet organizations, except as needed for the purpose of 433 developing Internet standards in which case the procedures for 434 copyrights defined in the Internet Standards process must be 435 followed, or as required to translate it into languages other than 436 English. 438 The limited permissions granted above are perpetual and will not be 439 revoked by the Internet Society or its successors or assigns. 441 This document and the information contained herein is provided on an 442 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 443 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 444 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 445 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 446 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.