idnits 2.17.1 draft-ietf-diffserv-af-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: ---------------------------------------------------------------------------- ** 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 106: '... drop precedence MAY be defined for lo...' RFC 2119 keyword, line 108: '... A DS node MUST allocate forwarding ...' RFC 2119 keyword, line 112: '... MUST NOT be delivered with smaller ...' RFC 2119 keyword, line 115: '... A DS node MUST NOT reorder AF packe...' RFC 2119 keyword, line 120: '...The AF PHB group MAY be used to implem...' (16 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 263 looks like a reference -- Missing reference section? 'Bradner' on line 267 looks like a reference -- Missing reference section? 'Floyd' on line 270 looks like a reference -- Missing reference section? 'Nichols' on line 274 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 April 1999 Fred Baker 5 Cisco Systems 6 Walter Weiss 7 Lucent Technologies 8 John Wroclawski 9 MIT LCS 10 October, 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), ds.internic.net (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 proposes 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 offer assured delivery of IP packets over the 50 Internet. In a typical application, a company uses the Internet to 51 connect its geographically distributed sites and wants an assurance 52 that IP packets within this intranet are delivered with high 53 probability as long as the aggregate traffic from each site does not 54 exceed the subscribed information rate (profile). It is desirable 55 that a site may exceed the subscribed profile with the understanding 56 that the excess traffic is not delivered with as high a probability 57 as the traffic that is within the profile. It is also important that 58 the network does not reorder packets that belong to the same 59 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 delivery 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, bandwidth). IP packets that wish 66 to use the services provided by the AF PHB group are assigned by the 67 customer or the provider DS domain into one or more of these AF 68 classes according to the subscribed services. 70 Within each AF class IP packets are marked (again by the customer or 71 the provider DS domain) with one of three possible drop precedence 72 values. In case of congestion, the drop precedence of a packet 73 determines the relative importance of the packet within the AF class. 74 A congested DS node tries to protect packets with a lower drop 75 precedence value from being lost by preferably discarding packets 76 with a higher drop precedence value. 78 In a DS node, the level of delivery assurance of an IP packet thus 79 depends on (1) how much forwarding resources has been allocated to 80 the AF class that the packet belongs to, (2) what is the current load 81 of the AF class, and, in case of congestion, (3) what is the drop 82 precedence of the packet. 84 For example, if traffic conditioning actions at the ingress of the 85 provider DS domain make sure that an AF class in the DS nodes is only 86 moderately loaded by packets with the lowest drop precedence value 87 and is not overloaded by packets with the two lowest drop precedence 88 values, then the AF class can offer a high level of delivery 89 assurance for packets that are within the subscribed profile and 90 offer up to two lower levels of delivery assurance for the excess 91 traffic. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [Bradner]. 97 2. The AF PHB Group 99 Assured Forwarding (AF) PHB group provides delivery of IP packets in 100 N independent AF classes. Within each AF class, an IP packet is 101 assigned one of M different levels of drop precedence. An IP packet 102 that belongs to an AF class i and has drop precedence j is marked 103 with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M. At 104 this point, four classes (N=4) with three drop precedences in each 105 class (M=3) are defined for general use. More AF classes or levels 106 of drop precedence MAY be defined for local use. 108 A DS node MUST allocate forwarding resources (buffer space and 109 bandwidth) to AF classes so that, relative to the loads, an AF class 110 x has no more forwarding resources than an AF class y if x < y. 111 Similarly, within an AF class, an IP packet with drop precedence p 112 MUST NOT be delivered with smaller probability than an IP packet with 113 drop precedence q if p < q. 115 A DS node MUST NOT reorder AF packets of the same microflow when they 116 belong to the same AF class regardless of their drop precedence. 117 There are no timing requirements (delay or delay variation) 118 associated with the forwarding of AF packets. 120 The AF PHB group MAY be used to implement both end-to-end and domain 121 edge-to-domain edge services. 123 3. Traffic Conditioning Actions 125 A DS domain MAY at the edge of a domain control the amount of AF 126 traffic that enters or exists the domain at various levels of drop 127 precedence. The traffic conditioning actions MAY include discarding 128 of packets, increasing or decreasing the drop precedence of packets, 129 and reassigning of packets to other AF classes. The latter action 130 MUST NOT distribute packets of the same microflow to more than one AF 131 class. 133 4. Queueing and Discard Behavior 135 A DS node SHOULD implement all four general use AF classes. Packets 136 in one AF class MUST be forwarded independently from packets in 137 another AF class, i.e., a DS node MUST NOT aggregate two or more AF 138 classes together. 140 Within each AF class, the three drop precedence codepoints MUST yield 141 at least two different levels of loss probability. In some networks, 142 particularly in enterprise networks, where transient congestion is a 143 rare and brief occurrence, it may be reasonable for a DS node to 144 support only two different levels of loss probability. While this 145 may suffice for some networks, three different levels of loss 146 probability SHOULD be supported in DS domains where congestion is a 147 common occurrence. 149 If a DS node only implements two different levels of loss probability 150 for an AF class x, the codepoint AFx1 MUST yield the lower loss 151 probability and the codepoints AFx2 and AFx3 MUST yield the higher 152 loss probability. 154 Inconsistent discard behaviors lead to inconsistent end-to-end 155 service semantics. It is RECOMMENDED that the discard mechanism is 156 based on a RED-like [Floyd] algorithm with three configurable levels 157 of drop precedence and a configurable averaging function (interval). 158 Future versions of this document may say more about specific aspects 159 of the desirable behavior. 161 5. Tunneling 163 When AF packets are tunneled, the PHB of the tunneling packet MUST 164 NOT reduce the delivery assurance of the tunneled AF packet nor cause 165 reordering of AF packets belonging to the same microflow. 167 6. Recommended Codepoints 169 It is RECOMMENDED that the AF codepoints AF11, AF21, AF31, and AF41, 170 i.e., the codepoints that denote the lowest drop precedence in each 171 AF class, are mapped to the Class Selector [Nichols] codepoints 172 '010000', '011000', '100000', '101000'. This is done in order to 173 save DS code space, because the forwarding rules associated with 174 these AF codepoints are consistent and compatible with the forwarding 175 rules of the corresponding Class Selector codepoints. 177 The RECOMMENDED values of the remaining AF codepoints are as follows: 178 AF12 = '010010', AF13 = '010100', AF22 = '011010', AF23 = '011100', 179 AF32 = '100010', AF33 = '100100', AF42 = '101010', and AF43 = 180 '101100'. The table below summarizes the recommended AF codepoint 181 values. 183 Class 1 Class 2 Class 3 Class 4 184 +----------+----------+----------+----------+ 185 Low Drop Pref | 010000 | 011000 | 100000 | 101000 | 186 Medium Drop Pref | 010010 | 011010 | 100010 | 101010 | 187 High Drop Pref | 010100 | 011100 | 100100 | 101100 | 188 +----------+----------+----------+----------+ 190 7. Interactions with Other PHB Groups 192 The AF codepoint mappings recommended above do not interfere with the 193 local use spaces nor use the Class Selector codepoints '00x000' and 194 '11x000'. The PHBs selected by those Class Selector codepoints may 195 thus coexist with the AF PHB group, and retain the forwarding 196 behavior and relationships that was defined for them in [Nichols]. 197 In particular, the Default PHB codepoint of '000000' may remain to be 198 used for conventional best effort traffic. Similarly, the codepoints 199 '11x000' may remain to be used for network control traffic. 201 In addition to the Class Selector PHBs, any other PHB groups may co- 202 exist with the AF group within the same DS domain provided that the 203 other PHB groups don't preempt the resources allocated to the AF 204 classes. 206 8. Security Implications 208 In order to protect itself against denial of service attacks, a 209 provider DS domain SHOULD limit the traffic entering the domain to 210 the subscribed profiles. Also, in order to protect a link to a 211 customer DS domain from denial of service attacks, the provider DS 212 domain SHOULD allow the customer DS domain to specify how the 213 resources of the link are allocated to AF packets. If a service 214 offering requires that traffic marked with an AF codepoint be limited 215 by such attributes as source or destination address, it is the 216 responsibility of the ingress node in a network to verify validity of 217 such attributes. 219 Other security considerations are covered in [Blake] and [Nichols]. 221 Appendix: Example Services 223 The AF PHB group may be used to implement, for example, the so-called 224 Olympic service, which consists of three service classes: bronze, 225 silver, and gold. Packets are assigned to these three classes so 226 that packets in the gold class experience lighter load (and thus have 227 greater probability for timely delivery) than packets assigned to the 228 silver class. Same kind of relationship exists between the silver 229 class and the bronze class. If desired, packets within each class 230 may be further separated by giving them either low, medium, or high 231 drop precedence. 233 The bronze, silver, and gold service classes may in the network be 234 mapped to the AF classes 1, 2, and 3. Similarly, low, medium, and 235 high drop precedence may be mapped to AF drop precedence indexes 1, 236 2, or 3. 238 The drop precedence level of a packet may be assigned, for example, 239 by using a dual leaky bucket traffic policer, which has as its 240 parameters a rate and two burst sizes: a committed burst and an 241 excess burst. If a packet falls within the committed burst, it is 242 assigned low drop precedence. If a packet falls between the 243 committed burst and the excess burst, it is assigned medium drop 244 precedence. And finally, if the packet falls out of the excess burst, 245 it is assigned high drop precedence. 247 Another possibility would be to limit the user traffic of an Olympic 248 service class to a given peak rate and distribute it evenly across 249 each level of drop precedence. This would yield a proportional 250 bandwidth service, which equally apportions available capacity during 251 times of congestion under the assumption that customers with high 252 bandwidth microflows have subscribed to higher peak rates than 253 customers with low bandwidth microflows. 255 The AF PHB group could also be used to implement a low loss, low 256 delay, and low jitter service using an over provisioned AF class, if 257 the maximum arrival rate to that class is known a priori in each DS 258 node. Specification of the required admission control services, 259 however, is beyond the scope of this document. 261 References 263 [Blake] Blake, Steve, et al., An Architecture for Differentiated 264 Services. Internet draft draft-ietf-diffserv-arch-01.txt, August 265 1998. 267 [Bradner] Bradner, S., Key words for use in RFCs to Indicate 268 Requirement Levels. Internet RFC 2119, March 1997. 270 [Floyd] Floyd, S., and Jacobson, V., Random Early Detection gateways 271 for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume 272 1, Number 4, August 1993, pp. 397-413. 274 [Nichols] Nichols, Kathleen, et al., Definition of the Differentiated 275 Services Field (DS Field) in the IPv4 and IPv6 Headers. Internet 276 draft draft-ietf-diffserv-header-02.txt, August 1998. 278 Author Information 280 Juha Heinanen 281 Telia Finland 282 Myyrmaentie 2 283 01600 Vantaa, Finland 284 Email: jh@telia.fi 285 Fred Baker 286 Cisco Systems 287 519 Lado Drive 288 Santa Barbara, California 93111 289 E-mail: fred@cisco.com 291 Walter Weiss 292 Lucent Technologies 293 300 Baker Avenue, Suite 100, 294 Concord, MA 01742-2168 295 E-mail: wweiss@lucent.com 297 John Wroclawski 298 MIT Laboratory for Computer Science 299 545 Technology Sq. 300 Cambridge, MA 02139 301 Email: jtw@lcs.mit.edu 303 Full Copyright Statement 305 Copyright (C) The Internet Society (1998). All Rights Reserved. 307 This document and translations of it may be copied and furnished to 308 others, and derivative works that comment on or otherwise explain it 309 or assist in its implementation may be prepared, copied, published 310 and distributed, in whole or in part, without restriction of any 311 kind, provided that the above copyright notice and this paragraph are 312 included on all such copies and derivative works. However, this 313 document itself may not be modified in any way, such as by removing 314 the copyright notice or references to the Internet Society or other 315 Internet organizations, except as needed for the purpose of 316 developing Internet standards in which case the procedures for 317 copyrights defined in the Internet Standards process must be 318 followed, or as required to translate it into languages other than 319 English. 321 The limited permissions granted above are perpetual and will not be 322 revoked by the Internet Society or its successors or assigns. 324 This document and the information contained herein is provided on an 325 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 326 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 327 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 328 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 329 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.