idnits 2.17.1 draft-ietf-diffserv-af-03.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 Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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 113: '... drop precedence MAY be defined for lo...' RFC 2119 keyword, line 115: '... A DS node MUST allocate forwarding ...' RFC 2119 keyword, line 120: '... precedence p MUST NOT be forwarded ...' RFC 2119 keyword, line 123: '... A DS node MUST NOT reorder AF packe...' RFC 2119 keyword, line 128: '...The AF PHB group MAY be used to implem...' (18 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 281 looks like a reference -- Missing reference section? 'Bradner' on line 285 looks like a reference -- Missing reference section? 'Floyd' on line 288 looks like a reference -- Missing reference section? 'Nichols' on line 292 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 6 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 May 1999 Fred Baker 5 Cisco Systems 6 Walter Weiss 7 Lucent Technologies 8 John Wroclawski 9 MIT LCS 10 November, 1998 12 Assured Forwarding PHB Group 13 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Copyright Notice 35 Copyright (C) The Internet Society (1998). All Rights Reserved. 37 Abstract 39 This document defines a general use Differentiated Services (DS) 40 [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). 41 The AF PHB group provides delivery of IP packets in four 42 independently forwarded AF classes. Within each AF class, an IP 43 packet can be assigned one of three different levels of drop 44 precedence. A DS node does not reorder IP packets of the same 45 microflow if they belong to the same AF class. 47 1. Purpose and Overview 49 There is a demand to provide assured forwarding of IP packets over 50 the Internet. In a typical application, a company uses the Internet 51 to interconnect its geographically distributed sites and wants an 52 assurance that IP packets within this intranet are forwarded with 53 high probability as long as the aggregate traffic from each site does 54 not exceed the subscribed information rate (profile). It is 55 desirable that a site may exceed the subscribed profile with the 56 understanding that the excess traffic is not delivered with as high 57 probability as the traffic that is within the profile. It is also 58 important that the network does not reorder packets that belong to 59 the same microflow no matter if they are in or out of the profile. 61 Assured Forwarding (AF) PHB group is a means for a provider DS domain 62 to offer different levels of forwarding assurances for IP packets 63 received from a customer DS domain. Four AF classes are defined, 64 where each AF class is in each DS node allocated a certain amount of 65 forwarding resources (buffer space and bandwidth). IP packets that 66 wish to use the services provided by the AF PHB group are assigned by 67 the customer or the provider DS domain into one or more of these AF 68 classes according to the services that the customer has subscribed 69 to. 71 Within each AF class IP packets are marked (again by the customer or 72 the provider DS domain) with one of three possible drop precedence 73 values. In case of congestion, the drop precedence of a packet 74 determines the relative importance of the packet within the AF class. 75 A congested DS node tries to protect packets with a lower drop 76 precedence value from being lost by preferably discarding packets 77 with a higher drop precedence value. 79 In a DS node, the level of forwarding assurance of an IP packet thus 80 depends on (1) how much forwarding resources has been allocated to 81 the AF class that the packet belongs to, (2) what is the current load 82 of the AF class, and, in case of congestion, (3) what is the drop 83 precedence of the packet. 85 For example, if traffic conditioning actions at the ingress of the 86 provider DS domain make sure that an AF class in the DS nodes is only 87 moderately loaded by packets with the lowest drop precedence value 88 and is not overloaded by packets with the two lowest drop precedence 89 values, then the AF class can offer a high level of forwarding 90 assurance for packets that are within the subscribed profile and 91 offer up to two lower levels of forwarding assurance for the excess 92 traffic. 94 This document describes the AF PHB group. An otherwise DS-compliant 95 node is not required to implement this PHB group in order to be 96 considered DS-compliant, but when a DS-compliant node is said to 97 implement an AF PHB group, it must conform to the specification in 98 this document. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [Bradner]. 104 2. The AF PHB Group 106 Assured Forwarding (AF) PHB group provides forwarding of IP packets 107 in N independent AF classes. Within each AF class, an IP packet is 108 assigned one of M different levels of drop precedence. An IP packet 109 that belongs to an AF class i and has drop precedence j is marked 110 with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M. 111 Currently, four classes (N=4) with three levels of drop precedence in 112 each class (M=3) are defined for general use. More AF classes or 113 levels of drop precedence MAY be defined for local use. 115 A DS node MUST allocate forwarding resources (buffer space and 116 bandwidth) to AF classes so that, under reasonable operating 117 conditions and traffic loads, packets of an AF class x do not have 118 higher probability of timely forwarding than packets of an AF class y 119 if x < y. Similarly, within an AF class, an IP packet with drop 120 precedence p MUST NOT be forwarded with smaller probability than an 121 IP packet with drop precedence q if p < q. 123 A DS node MUST NOT reorder AF packets of the same microflow when they 124 belong to the same AF class regardless of their drop precedence. 125 There are no quantifiable timing requirements (delay or delay 126 variation) associated with the forwarding of AF packets. 128 The AF PHB group MAY be used to implement both end-to-end and domain 129 edge-to-domain edge services. 131 3. Traffic Conditioning Actions 133 A DS domain MAY at the edge of a domain control the amount of AF 134 traffic that enters or exists the domain at various levels of drop 135 precedence. Such traffic conditioning actions MAY include traffic 136 shaping, discarding of packets, increasing or decreasing the drop 137 precedence of packets, and reassigning of packets to other AF 138 classes. The traffic conditioning actions MUST NOT cause reordering 139 of packets of the same microflow. 141 4. Queueing and Discard Behavior 143 A DS node SHOULD implement all four general use AF classes. Packets 144 in one AF class MUST be forwarded independently from packets in 145 another AF class, i.e., a DS node MUST NOT aggregate two or more AF 146 classes together. 148 Within each AF class, a DS node MUST accept all three drop precedence 149 codepoints and they MUST yield at least two different levels of loss 150 probability. In some networks, particularly in enterprise networks, 151 where transient congestion is a rare and brief occurrence, it may be 152 reasonable for a DS node to implement only two different levels of 153 loss probability. While this may suffice for some networks, three 154 different levels of loss probability SHOULD be supported in DS 155 domains where congestion is a common occurrence. 157 If a DS node only implements two different levels of loss probability 158 for an AF class x, the codepoint AFx1 MUST yield the lower loss 159 probability and the codepoints AFx2 and AFx3 MUST yield the higher 160 loss probability. 162 Inconsistent discard behaviors lead to inconsistent end-to-end 163 service semantics. It is RECOMMENDED that the discard mechanism is 164 based on a RED-like [Floyd] algorithm. In any case, the discard 165 control parameters for each precedence within an AF class MUST be 166 separately configurable. In the case of the RED algorithm, this means 167 that the start-drop and hard-drop thresholds for each precedence 168 within a class must be separately configurable. Future versions of 169 this document may say more about specific aspects of the desirable 170 behavior. 172 5. Tunneling 174 When AF packets are tunneled, the PHB of the tunneling packet MUST 175 NOT reduce the forwarding assurance of the tunneled AF packet nor 176 cause reordering of AF packets belonging to the same microflow. 178 6. Recommended Codepoints 180 It is RECOMMENDED that the AF codepoints AF11, AF21, AF31, and AF41, 181 i.e., the codepoints that denote the lowest drop precedence in each 182 AF class, are mapped to the Class Selector [Nichols] codepoints 183 '010000', '011000', '100000', '101000'. This is done in order to 184 save DS code space, because the forwarding rules associated with 185 these AF codepoints are consistent and compatible with the forwarding 186 rules of the corresponding Class Selector codepoints. 188 The RECOMMENDED values of the remaining AF codepoints are as follows: 190 AF12 = '010010', AF13 = '010100', AF22 = '011010', AF23 = '011100', 191 AF32 = '100010', AF33 = '100100', AF42 = '101010', and AF43 = 192 '101100'. The table below summarizes the recommended AF codepoint 193 values. 195 Class 1 Class 2 Class 3 Class 4 196 +----------+----------+----------+----------+ 197 Low Drop Prec | 010000 | 011000 | 100000 | 101000 | 198 Medium Drop Prec | 010010 | 011010 | 100010 | 101010 | 199 High Drop Prec | 010100 | 011100 | 100100 | 101100 | 200 +----------+----------+----------+----------+ 202 7. Interactions with Other PHB Groups 204 The AF codepoint mappings recommended above do not interfere with the 205 local use spaces nor use the Class Selector codepoints '00x000' and 206 '11x000'. The PHBs selected by those Class Selector codepoints may 207 thus coexist with the AF PHB group, and retain the forwarding 208 behavior and relationships that was defined for them in [Nichols]. 209 In particular, the Default PHB codepoint of '000000' may remain to be 210 used for conventional best effort traffic. Similarly, the codepoints 211 '11x000' may remain to be used for network control traffic. 213 In addition to the Class Selector PHBs, any other PHB groups may co- 214 exist with the AF group within the same DS domain provided that the 215 other PHB groups don't preempt the resources allocated to the AF 216 classes. 218 8. Security Implications 220 In order to protect itself against denial of service attacks, a 221 provider DS domain SHOULD limit the traffic entering the domain to 222 the subscribed profiles. Also, in order to protect a link to a 223 customer DS domain from denial of service attacks, the provider DS 224 domain SHOULD allow the customer DS domain to specify how the 225 resources of the link are allocated to AF packets. If a service 226 offering requires that traffic marked with an AF codepoint be limited 227 by such attributes as source or destination address, it is the 228 responsibility of the ingress node in a network to verify validity of 229 such attributes. 231 Other security considerations are covered in [Blake] and [Nichols]. 233 Appendix: Example Services 235 The AF PHB group could be used to implement, for example, the so- 236 called Olympic service, which consists of three service classes: 237 bronze, silver, and gold. Packets are assigned to these three 238 classes so that packets in the gold class experience lighter load 239 (and thus have greater probability for timely forwarding) than 240 packets assigned to the silver class. Same kind of relationship 241 exists between the silver class and the bronze class. If desired, 242 packets within each class may be further separated by giving them 243 either low, medium, or high drop precedence. 245 The bronze, silver, and gold service classes could in the network be 246 mapped to the AF classes 1, 2, and 3. Similarly, low, medium, and 247 high drop precedence may be mapped to AF drop precedence levels 1, 2, 248 or 3. 250 The drop precedence level of a packet could be assigned, for example, 251 by using a leaky bucket traffic policer, which has as its parameters 252 a rate and two burst sizes: a committed burst and an excess burst. 253 If a packet falls within the committed burst, it is assigned low drop 254 precedence. If a packet falls between the committed burst and the 255 excess burst, it is assigned medium drop precedence. And finally, if 256 the packet falls out of the excess burst, it is assigned high drop 257 precedence. It may also be necessary to set an upper limit to the 258 amount of high drop precedence traffic from a customer DS domain in 259 order to avoid the situation where an avalanche of undeliverable high 260 drop precedence packets from one customer DS domain can deny service 261 to possibly deliverable high drop precedence packets from other 262 domains. 264 Another way to assign the drop precedence level of a packet could be 265 to limit the user traffic of an Olympic service class to a given peak 266 rate and distribute it evenly across each level of drop precedence. 267 This would yield a proportional bandwidth service, which equally 268 apportions available capacity during times of congestion under the 269 assumption that customers with high bandwidth microflows have 270 subscribed to higher peak rates than customers with low bandwidth 271 microflows. 273 The AF PHB group could also be used to implement a low loss, low 274 delay, and low jitter service using an over provisioned AF class, if 275 the maximum arrival rate to that class is known a priori in each DS 276 node. Specification of the required admission control services, 277 however, is beyond the scope of this document. 279 References 281 [Blake] Blake, Steve, et al., An Architecture for Differentiated 282 Services. Internet draft draft-ietf-diffserv-arch-01.txt, August 283 1998. 285 [Bradner] Bradner, S., Key words for use in RFCs to Indicate 286 Requirement Levels. Internet RFC 2119, March 1997. 288 [Floyd] Floyd, S., and Jacobson, V., Random Early Detection gateways 289 for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume 290 1, Number 4, August 1993, pp. 397-413. 292 [Nichols] Nichols, Kathleen, et al., Definition of the Differentiated 293 Services Field (DS Field) in the IPv4 and IPv6 Headers. Internet 294 draft draft-ietf-diffserv-header-02.txt, August 1998. 296 Author Information 298 Juha Heinanen 299 Telia Finland 300 Myyrmaentie 2 301 01600 Vantaa, Finland 302 Email: jh@telia.fi 304 Fred Baker 305 Cisco Systems 306 519 Lado Drive 307 Santa Barbara, California 93111 308 E-mail: fred@cisco.com 310 Walter Weiss 311 Lucent Technologies 312 300 Baker Avenue, Suite 100, 313 Concord, MA 01742-2168 314 E-mail: wweiss@lucent.com 316 John Wroclawski 317 MIT Laboratory for Computer Science 318 545 Technology Sq. 319 Cambridge, MA 02139 320 Email: jtw@lcs.mit.edu 322 Full Copyright Statement 324 Copyright (C) The Internet Society (1998). All Rights Reserved. 326 This document and translations of it may be copied and furnished to 327 others, and derivative works that comment on or otherwise explain it 328 or assist in its implementation may be prepared, copied, published 329 and distributed, in whole or in part, without restriction of any 330 kind, provided that the above copyright notice and this paragraph are 331 included on all such copies and derivative works. However, this 332 document itself may not be modified in any way, such as by removing 333 the copyright notice or references to the Internet Society or other 334 Internet organizations, except as needed for the purpose of 335 developing Internet standards in which case the procedures for 336 copyrights defined in the Internet Standards process must be 337 followed, or as required to translate it into languages other than 338 English. 340 The limited permissions granted above are perpetual and will not be 341 revoked by the Internet Society or its successors or assigns. 343 This document and the information contained herein is provided on an 344 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 345 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 346 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 347 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 348 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.