idnits 2.17.1 draft-nichols-dsopdef-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 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 == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 59 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** 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 201: '... congestion notification [ECN]. Hosts SHOULD set the CU bits to...' RFC 2119 keyword, line 202: '...ioners and routers SHOULD ignore their...' RFC 2119 keyword, line 212: '... implementations SHOULD treat the 5-bi...' RFC 2119 keyword, line 227: '... MUST remark the TOS value of packet...' RFC 2119 keyword, line 228: '...alue within the new semantics, and MAY...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 267 has weird spacing: '...nt that the p...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Applications SHOULD be aware that the value of the DS byte may be modified at each network boundary (possibly subject to some negotiated policy). The value of the DS byte does not have end-to-end integrity; security and transport protocol checksums MUST not include this field. -- 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 (February 1998) is 9565 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AH' -- Possible downref: Non-RFC (?) normative reference: ref. 'AIISS' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'CCBES' -- Possible downref: Non-RFC (?) normative reference: ref. 'Clark' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECN' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ellesson' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP' -- Possible downref: Non-RFC (?) normative reference: ref. 'Ferguson' -- Possible downref: Non-RFC (?) normative reference: ref. 'GBH' -- Possible downref: Non-RFC (?) normative reference: ref. 'Heinanen' -- Possible downref: Non-RFC (?) normative reference: ref. 'HPFQA' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' ** Obsolete normative reference: RFC 1349 (Obsoleted by RFC 2474) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIMA' -- Possible downref: Non-RFC (?) normative reference: ref. '2BIT' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Kathleen Nichols, editor 3 INTERNET-DRAFT Bay Networks Architecture Lab 4 Expires: August 1998 Steven Blake, editor 5 IBM Microelectronics 7 February 1998 9 Differentiated Services Operational Model and Definitions 11 13 Status of This Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 Differentiated services are intended to provide scalable service 34 discrimination in the Internet without the need for per-flow state 35 and signaling at every hop. The differentiated services approach to 36 providing quality of service in networks employs a small, well- 37 defined set of building blocks from which a variety of services may 38 be built. The services may be either end-to-end or intra-domain. A 39 wide range of services can be provided by a combination of: 41 - setting bits in the TOS octet at network edges and administrative 42 boundaries, 43 - using those bits to determine how packets are treated by the 44 routers inside the network, and 45 - conditioning the marked packets at network boundaries in accordance 46 with the requirements of each service. 48 A differentiated-services-capable network node includes a classifier 49 that selects packets based on the TOS octet and is capable of 50 delivering the treatment corresponding to that marking of the TOS 51 octet. Setting of the TOS octet and other conditioning of the 53 Nichols, et. al. Expires: August 1998 [Page 1] 54 dynamic behavior of marked packets need only be performed at network 55 boundaries and may vary in complexity. This draft presents a 56 differentiated services definition of the TOS octet and the 57 operational model behind that definition. 59 Authors 61 This document is the result of a collaborative effort among the 62 following individuals: Fred Baker, Steve Blake, Scott Bradner, Scott 63 Brim, Brian Carpenter, Dave Clark, Eric Crawley, Bruce Davie, Juha 64 Heinanen, Geoff Huston, Van Jacobson, Jim Luciani, Kathleen Nichols, 65 Mike O'Dell, John Wroclawski, and Lixia Zhang. 67 0. Discussion of this draft 69 We have set up a public mailing list for discussions of this draft 70 and for other differentiated services BOF issues. The list is: 71 diff-serv@baynetworks.com. To subscribe send mail to 72 majordomo@baynetworks.com with the line "subscribe diff-serv" in the 73 body. A browsable archive for this mailing list is at 74 http://www-nrg.ee.lbl.gov/diff-serv-arch and the archive can be 75 downloaded from ftp://ftp.ee.lbl.gov/diff-serv-arch/. Please use 76 this mailing list rather than others for the discussion of 77 differentiated services. 79 1. Introduction 81 The TOS octet is used to mark a packet to receive a particular per- 82 hop behavior. Marking is performed by traffic conditioners at 83 network boundaries, including the edges of the network (first hop 84 router/switch) and administrative boundaries. Traffic conditioners 85 may include the primitives of classification, marking, policing and 86 shaping. Service classes can be specified by the use of particular 87 traffic conditioning at boundaries coupled with particular per-hop 88 behaviors. A goal of the differentiated services architecture is to 89 specify these building blocks for future extensibility, both of the 90 number and type of the building blocks and of the services built from 91 them. 93 A number of recent Internet Drafts have suggested various encodings 94 of the TOS byte to get specific behavior from network nodes on a per- 95 hop basis [Ellesson, Ferguson, Heinanen, SIMA] and others have 96 discussed the behaviors required from the network [Clark, 2BIT]. All 97 of these have made important points about the kinds of per-hop 98 behaviors that are considered in this note. In selecting the TOS 99 octet definition and specifying per-hop behaviors to attach to 100 particular bit-patterns, we have been influenced by all these drafts 101 and the thoughtful work of their authors. 103 Nichols, et. al. Expires: August 1998 [Page 2] 104 We define terminology used in this draft in Sec. 2 and propose a 105 differentiated services definition for the TOS octet in Sec. 3. In 106 Sec. 4, we present an operational model for the assignment of per-hop 107 behaviors and propose two specific per-hop behaviors for 108 standardization. Sec. 5 describes primitives that can be used for 109 traffic conditioning. Sec. 6 discusses service allocation and 110 deployment and Sec. 7 covers some security considerations. We 111 present additional discussion of the TOS octet definition in Appendix 112 A and in Appendix B present some example services that can be built 113 from these differentiated services primitives. 115 2. Terminology used in this document 117 Service: The description of what is sold to a customer, specified 118 either end-to-end or within an Autonomous System (e.g., an ISP or 119 campus). We use the phrase "sold to a customer" loosely enough to 120 encompass any AS's allocation of network service to a user or 121 application. 123 Per-hop Behavior: The forwarding behavior a packet receives at a 124 given network node. It may be expressed in terms that can strongly 125 suggest a particular algorithm or implementation but leaves the 126 specific choice to the implementor. To compose predictable services, 127 per-hop behaviors probably need to be available in all routers in a 128 differentiated-services-capable network. 130 Mechanism: The implementation of a behavior. 132 Boundary: Where two network "clouds" are linked; the "clouds" can 133 represent different administrative domains or autonomous systems, 134 different trust regions, different network technologies (e.g., cell/ 135 frame), hosts and routers, etc. A boundary can be further sub- 136 divided into exit and entry nodes, where the exit/entry nodes are the 137 upstream/downstream nodes of a boundary link in a given traffic 138 direction. 140 DS byte: the IP header TOS octet when configured in conformance with 141 the definition given in this document. 143 Differentiated services behavior aggregate: a collection of packets 144 with the same DS byte pattern crossing a boundary in a particular 145 direction. The terms "aggregate" and "behavior aggregate" will be 146 used interchangeably in this document. 148 Network edge: refers to a particular boundary node, the edge of the 149 differentiated-services-compliant area. This typically is at the 150 ingress to the first-hop differentiated-services-aware router (or 151 network node) a host's packets see or at the egress of the last-hop 152 differentiated-services-aware router or network node packets see 153 before arriving at a host. This is sometimes referred to as the 154 boundary at a leaf router. The network edge might be co-located with 156 Nichols, et. al. Expires: August 1998 [Page 3] 157 a host, subject to local policy. 159 Traffic conditioning primitives: functions that can be applied to a 160 behavior aggregate, flow, or other operationally useful subset of 161 traffic, e.g., routing updates. These include policing, shaping, 162 header classification, and packet marking. Again, these may be 163 described in terms that can strongly suggest a particular algorithm 164 or implementation but no specific choice of implementation is given. 165 With the exception of a DS byte classifier at the packet forwarding 166 engine, traffic conditioning primitives need not be implemented in 167 all network nodes in a differentiated-services-capable network, 168 instead appearing primarily at boundaries. 170 To summarize, the TOS octet is used as a DS byte to designate 171 behaviors. A DS byte classifier and per-hop behaviors based on those 172 classifications are required in all network nodes of a 173 differentiated-services-capable network. More extensive traffic 174 conditioners may appear at boundaries. Multiple services can be 175 supported by a single per-hop behavior used in concert with a range 176 of traffic conditioners. 178 3. A Differentiated Services Definition of the TOS Octet 180 We propose to redefine the structure for the 8-bit IPv4 TOS field 181 [RFC791] and the 8-bit IPv6 Class field [IPv6], and re-label the 182 field as the "DS byte". The new structure is presented below: 184 0 1 2 3 4 5 6 7 185 +---+---+---+---+---+---+---+---+ 186 |IN | PHB | CU | 187 +---+---+---+---+---+---+---+---+ 189 IN: in (1) or out (0) of profile 190 PHB: per-hop behavior 191 CU: currently unused (reserved) 193 We have been influenced by [Ellesson] and by Dave Clark's talk at the 194 int-serv WG December 8, 1997 meeting. Adopting key elements of 195 Clark's framework, though not the exact terminology or bit-patterns, 196 we use five bits to define the per-hop behavior (PHB) the packet 197 experiences and one bit (IN) to identify whether the packet may be 198 in- or out-of-profile with respect to some traffic policy measured at 199 a network boundary. We also reserve a two-bit CU, or currently 200 unused, field that may be assigned later, e.g., for explicit 201 congestion notification [ECN]. Hosts SHOULD set the CU bits to 202 zeroes, and traffic conditioners and routers SHOULD ignore their 203 value. 205 The IN indicator parameter may be used to mark packets for a higher 207 Nichols, et. al. Expires: August 1998 [Page 4] 208 level of service (e.g., lower loss probability) within whatever share 209 of router interface resources (e.g., buffers, bandwidth) are 210 associated with a particular per-hop behavior. 212 Router implementations SHOULD treat the 5-bit PHB field as an index 213 to be used in selecting a particular packet handling mechanism which 214 has been implemented in that device. Although the IANA may assume 215 some structure within the PHB field when assigning values for new 216 per-hop behaviors, implementations should treat it as an unstructured 217 field. 219 The structure of the DS byte shown above is incompatible with the 220 existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The 221 use of bit 7 as a "DiffServ semantics" indicator was contemplated, 222 but the authors believe that there exists deployed equipment which 223 does not test bit 7, thereby making it impossible to simultaneously 224 support two sets of semantics within the same network. Therefore, to 225 maintain compatibility with IPv4 hosts and networks which utilize the 226 existing TOS semantics, a differentiated services-enabled network 227 MUST remark the TOS value of packets arriving at a boundary entry 228 node to some acceptable value within the new semantics, and MAY 229 remark (e.g., by zeroing) on exit at a boundary to a network 230 supporting the existing semantics. Validating the value of the TOS 231 octet at network boundaries is sensible in any case since an upstream 232 node can easily set them to any random value. Differentiated- 233 services-enabled networks which are not suitably isolated by a 234 remarking boundary node may deliver unpredictable service. 236 4. Operational Model 238 4.1 Per-Hop Behaviors 240 The differentiated services model is that a router has a (possibly 241 large) set of parameters that can be used to control how packets are 242 scheduled onto an output interface (e.g., N separate queues with 243 settable priorities, queue lengths, round-robin weights, drop 244 algorithm, drop preference weights and thresholds, etc). Router 245 vendors are free to offer whatever parameters and capabilities they 246 feel are useful or marketable. An ISP is free to configure those 247 parameters in whatever way they feel is appropriate for their service 248 offerings and traffic engineering objectives. The router's 249 capabilities and its particular configuration determine the different 250 ways packets can be treated. The DS byte then selects which 251 treatment a particular packet receives. For example, an ISP may 252 configure eight weighted round robin queues in its routers and use 253 the DS byte to select which queue (from zero, for smallest weight to 254 seven, for largest weight or share of output link) a packet is placed 255 for servicing. Another ISP might configure a single queue with 256 multiple drop priorities and use the DS byte to select the drop 257 preference (from zero, most likely to drop to seven, least likely to 258 drop) for packets in that queue. Another might configure four queues 260 Nichols, et. al. Expires: August 1998 [Page 5] 261 with two levels of drop preference in each. There is no requirement 262 that different ISPs use the same router mechanisms or configuration 263 or that any value of the DS byte map to a particular packet 264 forwarding behavior (other than the behaviors described below and the 265 general guidelines given in Appendix A). 267 However, to the extent that the per-hop behaviors are used to 268 implement end-to-end services (see Appendix B for examples), it may 269 be undesirable for the "same" per-hop behavior to be selected by 270 different DS byte values in different ISPs. For example, consider 271 ISP A and ISP B both offering a low jitter, guaranteed rate, premium 272 service. If ISP A uses a PHB of 3 to select an appropriate router 273 mechanism while ISP B uses a PHB of 7, packets that use this service 274 and transit A to B must have the PHB field of their DS byte rewritten 275 from 3 to 7. Since the per-hop behaviors on each side must be 276 functionally equivalent, this is simply useless work that has to be 277 done in the forwarding path of a busy border router. To avoid this, 278 we expect that over time certain common per-hop behaviors will evolve 279 (ones that are particularly useful for implementing end-to-end 280 services) and that these will be associated with particular code 281 points in the DS byte. However, since our current experience with 282 diffserv is quite limited, it is premature to hypothesize the exact 283 specification of these code points and we have simply left room in 284 the code space to allow for evolution, thus the defined space of the 285 PHB field is intentionally sparse. But we do not suggest that PHB 286 patterns be selected and assigned without adherence to a larger 287 context. For more on the rationale of selecting and using PHBs, see 288 Appendix A. 290 Only those per-hop behaviors that have both some degree of 291 orthogonality and have been implemented, deployed, and shown to be 292 useful should be standardized. 294 Two per-hop behaviors are already in widespread use and we propose 295 them for standardization: Default (DE) is the common, best-effort 296 forwarding available in today's internet and already standardized in 297 RFC-1812. Expedited Forwarding (EF) is a "high priority" behavior 298 typically used for network control traffic such as routing updates. 299 The code points chosen for these are compatible with existing 300 practice: 302 PHB field value Behavior name 303 --------------- ------------- 305 00000 Default (DE) 306 11100 Expedited Forwarding (EF) 308 and are defined as follows: 310 Nichols, et. al. Expires: August 1998 [Page 6] 311 Default: an incoming packet goes to the tail of a queue that is 312 serviced in FIFO order when the output link is free. Thus if a 313 continuous stream of DE-marked packets is sent into a device, packets 314 that emerge will emerge in the same order they entered. It is not 315 required that all arriving packets are seen at the output, but it is 316 required that the aggregate of packets with this marking are not 317 completely starved. Delay requirements are as soon as possible, and 318 the corresponding bandwidth requirements are as much as possible 319 (subject to the other constraints of the router's scheduling system) 320 [CCBES]. The Default behavior is designed to closely approximate the 321 best-effort behavior of existing routers. 323 Expedited Forwarding: an EF-marked packet goes to the tail of a queue 324 that is expected to be relatively short and which always gets the 325 next opportunity to send a packet (possibly subject to some rate 326 regulator policy which prevents starvation of the Default queue). 327 Thus, when an EF-marked packet is sent into a device, that packet 328 should emerge at the output within a very small number of packet 329 times. The expedited forwarding behavior may be used to implement 330 services requiring low delay and low jitter, and may also be useful 331 for network control traffic. 333 Even though the above behaviors have been encoded in 3 bits, 334 implementors should note that the PHB field is 5 bits wide and 335 routers MUST identify both the DE and EF PHBs by matching against the 336 entire 5-bit PHB field. Packets received with an unrecognized PHB 337 value SHOULD be handled as if they were marked for DE. 339 Note that precise definitions of PHBs can be unwieldy and unclear. 340 For this reason, the PHBs above are described as the output of an 341 example algorithm. However, PHBs should be standardized, not the 342 algorithms or the mechanisms used to implement them. To illustrate 343 the distinction between PHB and mechanism, we point out that the EF 344 PHB can be implemented by several mechanisms, including: a strict 345 priority queue, WFQ or variants [HPFQA], weighted round-robin with a 346 large weight for the EF queue, or CBQ [CBQ]. 348 4.2 The "In Profile" bit 350 Packets marked with the IN bit set should experience a probability of 351 loss or congestion indication which is always less than or equal to 352 that experienced by packets with the IN bit cleared. When the IN bit 353 is used, RIO [Clark] or another drop preference or congestion 354 indication mechanism may be used to implement its use. The 355 requirements on a drop preference mechanism may be specific to each 356 per-hop behavior, but the general requirements include: (1) there 357 should be no packet reordering between packets marked for this 358 behavior; (2) The *average* (real or virtual) queue occupancy should 359 be used in the drop or congestion notification calculation, in a way 360 that maximizes the router's chances of selecting a non-preferred 361 packet to drop or notify of congestion. 363 Nichols, et. al. Expires: August 1998 [Page 7] 364 In the absence of traffic profiles, we suggest the IN bit should be 365 set to zero for Default traffic. With traffic profiles, the IN bit 366 can be used to provide further service differentiation of DE-marked 367 packets; for example, it can be used to implement the Assured service 368 described in [Clark]. 370 Use of the IN bit in combination with the EF PHB is a subject of 371 further research; at this time, all packets marked EF should have the 372 IN bit set. A pattern of 0.EF.CU will be considered undefined. The 373 use of the IN bit as an in-profile indicator with the EF PHB is 374 problematic for two reasons. First, the delay and jitter behavior of 375 EF-marked packets is sensitive to the relative load of EF-marked 376 packets on a link; service allocation policies and traffic 377 conditioners are used to ensure that this load is small enough to 378 permit the desired low-delay behavior to be realized. Secondly, out- 379 of-profile EF-marked packets receive priority relative to DE-marked 380 packets; excessive out-of-profile EF-marked packets may degrade the 381 service of the DE-marked aggregate beyond what is assumed in the 382 domain's service allocation policy. 384 5. Example Traffic Conditioners for Boundaries 386 Recall from Sec. 2 that traffic conditioners are composed of one or 387 more primitives: classifiers, markers, policers, and shapers. 388 Traffic conditioners prepare behavior aggregates for differentiated 389 services. The primitives are defined as: 391 Classifiers: select packets based on some portion of their packet 392 header and steer packets matching some classifier rule to another 393 traffic conditioner for further processing. Classifiers are of two 394 types: multi-field (MF) classifiers which can classify on the DS byte 395 as well as any one of a number of header fields (like a RSVP 396 classifier) and behavior aggregate (BA) classifiers which classify 397 only on patterns in the DS byte. 399 Markers: set the DS byte to a particular bit pattern, adding the 400 marked packets to a particular differentiated services behavior 401 aggregate. 403 Policers: monitor the the dynamic behavior of the packets steered to 404 them by a classifier and take an action (usually remarking or 405 dropping packets) based on the relationship of measured properties of 406 the packet stream to configured properties (e.g., rate and burst). 407 Policers are generally placed after either type of classifier: after 408 MF classifiers (e.g., at a host/network or site/provider boundary) 409 or after BA classifiers (e.g., at a provider/provider boundary). 411 Shapers: cause conformance to some configured traffic properties 412 (e.g., token bucket). Like policers, shapers are generally placed 413 after either type of classifier. Only one of the two primitives, 414 policers or shapers, would be expected to appear in the same traffic 416 Nichols, et. al. Expires: August 1998 [Page 8] 417 conditioner. 419 Although it is probably not necessary to standardize traffic 420 conditioners or the primitives that compose them, traffic 421 conditioners are required to instantiate services, and to enforce 422 service allocation policies. The only conditioning that is required 423 for packets of a differentiated services aggregate is to set the DS 424 byte appropriately. Thus, the simplest traffic conditioner consists 425 of only a packet marker that sets the DS byte of every packet on its 426 interface to a particular pattern for a particular per-hop behavior. 427 If the service being offered requires additional rule conformance, 428 then other primitives must be added to the traffic conditioner. 429 Another simple traffic conditioner might use an MF classifier to 430 select packets with a particular source-destination pair and a marker 431 to set these packets' DS byte to for a particular per-hop behavior. 432 There are a number of ways to condition traffic at boundaries; see 433 [Clark], [SIMA], and [2BIT]. We expect that many more might evolve 434 as differentiated services is widely deployed. 436 Applications SHOULD be aware that the value of the DS byte may be 437 modified at each network boundary (possibly subject to some 438 negotiated policy). The value of the DS byte does not have end-to- 439 end integrity; security and transport protocol checksums MUST not 440 include this field. 442 6. Service Allocation and Deployment 444 As differentiated services are deployed, there will be concerns about 445 service allocation and also about partial deployment. The allocation 446 of differentiated services does not require standardization or 447 uniformity. The differentiated services architecture leads quite 448 naturally to a control structure where decisions about the rate of 449 each type of marked packet are made on a per-domain basis. Since 450 traffic carried on a link between two domains can now be classified 451 into a small set of possibilities, it should be relatively 452 straightforward to write down a bilateral agreement between any two 453 domains. Differentiated services does not require end-to-end 454 signaling, but permits each domain to develop allocations of its 455 intra-domain traffic according to rules and processes that are as 456 simple or complex as desired. Inter-domain agreements can be as 457 simple as a list of the different packet markings and a maximum rate 458 permitted for each. Thus, it is not necessary to standardize a 459 service allocation strategy to deploy differentiated services. 461 We expect that a number of allocation methods will be tried within 462 different domains: aggregated RSVP [AIISS, GBH], Bandwidth Brokers 463 [2BIT], human configuration by a network manager. Reports of 464 experiences with different intra-domain allocation methods should 465 prove valuable during early deployment. Further, we expect the 466 nature of the bilateral inter-domain agreements to evolve as 467 experience is with differentiated services is gained. Again, reports 469 Nichols, et. al. Expires: August 1998 [Page 9] 470 on experience will do much to advance the field. 472 Differentiated services are realized by the concatenation of per-hop 473 behaviors along the transit path of a packet; therefore, the 474 treatment experienced by a behavior aggregate along a particular path 475 is unpredictable if some of the nodes along that path do not 476 recognize and implement the proposed per-hop behaviors. Note however 477 that the behavior of a router on a lightly loaded, high-speed link 478 which does not implement a set of per-hop behaviors may be 479 indistinguishable from that of a router which does (since the 480 proposed per-hop behaviors are work-conserving). The choice of those 481 nodes upon which to implement the proposed per-hop behaviors is 482 subject to a domain's traffic engineering policy. 484 Experiences with early deployment of differentiated services should 485 be shared, creating a body of work that the community can draw upon 486 when deploying differentiated services in a domain or when automating 487 a formerly manual process of allocation. Ultimately, we expect that 488 at least some differentiated services will enlist the use of 489 automated inter-domain messaging to provide more flexibility. 490 Selecting and developing the best approach is a topic for research. 491 Though, ultimately, we may need a standard format for these messages, 492 this should not be an IETF topic in the near-term. 494 7. Security Considerations 496 Wide-spread deployment of IP Security obscures the IP- and transport- 497 header fields which are frequently used to enable packet 498 classification for service differentiation. Use of the DS byte 499 offers an alternative means of classification for differentiated 500 services, thereby eliminating a disincentive to the deployment of IP 501 Security (especially within virtual private networks using ESP in 502 tunnel-mode [ESP]). 504 Because the differentiated services per-hop behaviors introduce 505 service bias, new denial-of-service attacks may be introduced. As an 506 example, unauthorized use of the EF PHB or IN bit may result in 507 service degradation to other traffic flows. Furthermore, an attack 508 on the differentiated services authorization, signaling, or 509 configuration mechanisms may permit theft-of-service or may enable a 510 severe denial-of-service attack. As a consequence, authorization, 511 signaling, and configuration mechanisms must be strongly protected 512 (e.g., by authentication). Non-default per-hop behaviors should 513 always be controlled at a network boundary via some traffic 514 conditioner (classifier, marker, policer/shaper). 516 The IP Security Authentication Header (AH) does not cover the IPv4 517 TOS octet in the integrity check value computation [AH]. This 518 behavior is in fact essential for the deployment of differentiated 519 services since the value of the DS byte may be changed in transit so 520 that the source host does not know what value will be delivered to 521 the destination host. Also, since the network is free to ignore the 522 DS byte, end-to-end integrity of a DS byte value does not guarantee 523 that a differentiated service has been delivered. Separate 524 measurement and assurance mechanisms are needed to ensure that any 525 negotiated differentiated services are being provided. 527 8. Acknowledgements 529 In addition to the co-authors of this document, valuable input was 530 received from Jim Boyle and Sally Floyd. 532 9. References 534 [AH] S. Kent and R. Atkinson, "IP Authentication Header", 535 Internet Draft , 536 October 1997. 538 [AIISS] S. Berson and S. Vincent, "Aggregation of Internet 539 Integrated Services State", Internet Draft 540 , November 1997. 542 [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource 543 Management Models for Packet Networks", IEEE/ACM 544 Transactions on Networking, Vol. 3 no. 4, pp. 365-386, 545 August 1995. 547 [CCBES] C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang, 548 "Congestion Control for Best-Effort Service: Why We Need 549 a New Paradigm", IEEE Network, Vol. 10, no. 1, January 550 1996. 552 [Clark] D. Clark and J. Wroclawski, "An Approach to Service 553 Allocation in the Internet", Internet Draft 554 , July 1997. 556 [ECN] K. Ramakrishnan and S. Floyd, "A Proposal to Add Explicit 557 Congestion Notification (ECN) to IPv6 and to TCP", 558 Internet Draft , November 1997. 560 [Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format and 561 Semantics of the TOS Byte and Traffic Class Byte in IPv4 562 and IPv6", Internet Draft , 563 November 1997. 565 [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security 566 Payload", Internet Draft 567 , October 1997. 569 [Ferguson] P. Ferguson, "Simple Differential Services: IP TOS and 570 Precedence, Delay Indication, and Drop Preference, 571 Internet Draft , 572 November 1997. 574 [GBH] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP- 575 based QoS Requests", Internet Draft 576 , November 1997. 578 [Heinanen] J. Heinanen, "Use of the IPv4 TOS Octet to Support 579 Differentiated Services", Internet Draft 580 , November 1997. 582 [HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair 583 Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996. 585 [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 586 (IPv6) Specification", Internet Draft 587 , November 1997. 589 [RFC791] Information Sciences Institute, "Internet Protocol", 590 Internet RFC 791, September 1981. 592 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol 593 Suite", Internet RFC 1349, July 1992. 595 [SIMA] K. Kilkki, "Simple Integrated Media Access (SIMA)", 596 Internet Draft , 597 June 1997. 599 [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit 600 Differentiated Services Architecture for the Internet", 601 Internet Draft , 602 November 1997. 604 Appendix A. Proposed Interpretation of the Three Most-Significant Bits 605 of the PHB Field 607 In this document, we have proposed two particular PHBs. Observant 608 readers will note that the numerical value of the PHB field assigned 609 to the Expedited Forwarding behavior is greater than that assigned to 610 the Default behavior. This is compatible with the interpretation of 611 the three most-significant bits of the PHB field (bits 1, 2, and 3 of 612 the DS byte as shown in Sec. 3) as a "weight" or "traffic precedence" 613 relative to some dimension of quality of service (e.g., delay, 614 throughput, or loss). We propose that implementors use bits 1, 2, 615 and 3 as a weight parameter to enable experiments using multi-level 616 priority (of loss, delay, and/or throughput), subject to the 617 requirement that bits 4 and 5 of the DS byte have the value zero. 618 The associated weight (e.g., increased delay priority, increased link 619 share, decreased loss probability) should increase in the order of 620 increasing numerical value of bits 1, 2, and 3. The interpretation 621 of bits 1, 2, and 3 when the value of bits 4 and 5 is not equal to 622 zero is not defined. 624 Because this proposal does not specify the specific QoS metric which 625 is affected by this three bit weight, implementation of any 626 particular differentiated service using this parameter is dependent 627 on each router's interpretation and implementation of the weight. 628 Potential behaviors which could utilize this weight field include 629 multi-level delay priority, multi-level discard priority, or multiple 630 link shares (where the share of a link increases in the order of 631 increasing weight). 633 Appendix B. Service Examples in this Framework 635 We propose standardizing ONLY a new meaning for the TOS octet and 636 particular per-hop behaviors associated with certain TOS octet 637 patterns. These will provide predictable building blocks from which 638 a variety of services might be built. There is thus no need to 639 standardize the services as these are realized by combining traffic 640 conditioners at boundaries with per-hop behaviors. To illustrate 641 this, we present some example services implemented in our framework. 642 We do not attempt to define "quality of service" for applications nor 643 do we make assumptions about what service a particular application 644 might use. Thus, although we give some example uses, we do not 645 characterize the services as being "for real-time video" or "for file 646 transfer data". Instead, we characterize a service by the type of 647 performance packets of that service can expect from the network. Any 648 IP application can utilize any of the services; the choice is up to 649 the customer. 651 Service: Best Effort 652 Service definition: "like today" (as soon as possible; as much as 653 possible [CCBES]). 655 Who/how to use this: The basic service of the Internet, what one gets 656 when merely buying connectivity. 658 Service: Premium 659 Service definition: Premium service is a peak-limited, extremely low- 660 delay service, resembling a leased line [2BIT]. At the network edge, 661 where a Premium aggregate is first created, it must be either shaped 662 or policed to a rate with no more than a two-packet burst. A policer 663 for Premium service is set to drop packets which exceed the 664 configured peak rate. For this service, the peak rate of the Premium 665 aggregate across any boundary must be specified and the rate must be 666 smaller than the link capacity (in practice, it is expected to be a 667 good deal less than the link capacity). Policing to this rate is 668 expected at the ingress of any domain and the policing action taken 669 may be one of two possibilities only: 1) drop the over-rate packet 670 and 2) hold the over-rate packet until it will be in compliance with 671 the peak rate (shaping). 673 Who/how to use this: Voice-over-IP "trunk", videoconference, fixed 674 size transfer in fixed time, virtual leased line, low delay 675 applications. 677 Service name: Assured 678 Service definition: Assured service is characterized by a rate and 679 burst profile [Clark]. Behavior aggregates that conform to their 680 profile are unlikely to experience dropped packets. Packets sent 681 that are out-of-profile are serviced with a higher drop preference, 682 but are not reordered with respect to in-profile packets. At the 683 network edge, an assured behavior aggregate is marked for DE, the IN 684 bit is set, and it is policed to a configured rate and burst size. A 685 policer for assured service clears the IN bit of packets which exceed 686 the configured rate, thus tagging them as "out-of-profile". The IN 687 bit is only used if there is congestion on a link, then "out" packets 688 are dropped with higher probability than "in" packets. The sum of 689 the Assured rates along with all other reserved rates at a domain 690 ingress should be less than the total available rate. Packets must 691 remain marked for DE as reordering is prohibited. 693 Who/how to use this: fixed file transfer size in desired time, 694 "better effort", certain adaptive applications. 696 Though we believe it is too early to standardize more than the EF and 697 DE PHBs, we describe a service that can be delivered with a "link 698 share" interpretation of bits 1, 2, and 3 of the DS byte as described 699 in Appendix A. 701 Service name: Olympic 702 Service definition: Olympic service provides three levels of service, 703 gold, silver, and bronze, in decreasing order of congested link 704 shares. Deployment of this service requires the implementation of 705 a rate-based link share scheduler behavior at each hop [HPFQA, CBQ]. 706 The particular link share associated with a packet could be selected 707 as suggested in Appendix A. When encountering a congested link, 708 packets with "Olympic gold" service will get a larger share of the 709 link than packets sent using the "Olympic silver" service which gets 710 a larger share of the link than packets sent using the "Olympic 711 bronze" service. When there are no packet flows of gold or silver 712 (or other higher serviced flows), bronze packet flows may utilize the 713 entire output link. This service classifies flows at a boundary, 714 marking packets for link share (e.g., by setting the "weight" 715 parameter in bits 1, 2, and 3) and setting the IN bit. The weight 716 parameter could be set to i for gold flow packets, i-1 for silver 717 flow packets, and i-2 for bronze flow packets, where 2 < i < 7. 718 Classification should be uniform across a single TCP flow or packet 719 reordering may result. The exact method of service discrimination 720 among the parameters is not specified, but would presumably be 721 selected so as to make a perceptible difference to customers. For 722 example, if the mechanism implementing link sharing has four weighted 723 round robin queues with RIO droppers in each queue, a configuration 724 might be 60% for gold, 30% for silver, 10% for bronze. These are the 725 percentages each aggregate gets when the link is congested, but an 726 alternate specification is that silver would get three times as large 727 a share of service as bronze and gold would get twice the service of 728 silver (it is also possible to have a "hidden" majority share 729 reserved for EF traffic). Lengths of each queue might also be 730 adjusted to meet certain requirements (this is a configuration option 731 which would not be standardized). Customers do not specify a 732 particular traffic profile, flows are not admission-controlled, and 733 flows are not shaped or policed in any way. 735 Who/how use this: for customer discrimination within an ISP, 736 corporate, or campus domain. 738 Editors' Addresses 740 Kathleen Nichols 741 Bay Networks Architecture Lab 742 4401 Great America Parkway 743 SC01-04 744 Santa Clara, CA 95052-8185 745 Phone: +1-408-495-3252 746 Fax: +1-408-495-1299 747 E-mail: knichols@baynetworks.com 749 Steven Blake 750 IBM Microelectronics 751 C5BA 660/HH007 752 800 Park Offices Drive 753 Research Triangle Park, NC 27709 754 Phone: +1-919-254-2030 755 Fax: +1-919-254-3047 756 E-mail: slblake@raleigh.ibm.com