idnits 2.17.1 draft-ietf-diffserv-header-02.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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([ARCH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 116 has weird spacing: '...ntended to pr...' -- 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 (August 1998) is 9385 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. 'ARCH' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'CLARK' -- Possible downref: Non-RFC (?) normative reference: ref. 'CONS' -- Possible downref: Non-RFC (?) normative reference: ref. 'DRR' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP' -- 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. 'RPS' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Kathleen Nichols 2 Diffserv Working Group Bay Networks 3 Expires: February 1999 Steven Blake 4 Torrent Networking Technologies 5 Fred Baker 6 Cisco Systems 7 David L. Black 8 The Open Group 9 August 1998 11 Definition of the Differentiated Services Field (DS Field) 12 in the IPv4 and IPv6 Headers 14 16 Status of This Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Copyright Notice 36 Copyright (C) The Internet Society (1998). All Rights Reserved. 38 Abstract 40 Differentiated services enhancements to the IP protocol are intended 41 to enable scalable service discrimination in the Internet without the 42 need for per-flow state and signaling at every hop. A variety of 43 services may be built from a small, well-defined set of building 44 blocks which are deployed in network nodes. The services may be 45 either end-to-end or intra-domain; they include both those that can 46 satisfy quantitative performance requirements (e.g., peak bandwidth) 47 and those based on relative performance (e.g., "class" 48 differentiation). Services can be constructed by a combination of: 50 - setting bits in an IP header field at network boundaries 51 (autonomous system boundaries, internal administrative boundaries, 53 Nichols, et. al. Expires: February 1999 [Page 1] 54 or hosts), 55 - using those bits to determine how packets are forwarded by the 56 nodes inside the network, and 57 - conditioning the marked packets at network boundaries in accordance 58 with the requirements or rules of each service. 60 The requirements or rules of each service must be set through 61 administrative policy mechanisms which are outside the scope of this 62 document. A differentiated services-compliant network node includes a 63 classifier that selects packets based on the value of the DS field 64 and is capable of delivering the specific packet forwarding treatment 65 indicated by the DS field value. Setting of the DS field and 66 conditioning of the temporal behavior of marked packets need only be 67 performed at network boundaries and may vary in complexity. 69 This document defines the IP header field, called the DS (for 70 differentiated services) field. In IPv4, it defines the layout of 71 the TOS octet; in IPv6, the Traffic Class octet. In addition, a base 72 set of packet forwarding treatments, or per-hop behaviors, is 73 defined. 75 For a more complete understanding of differentiated services, see 76 also the differentiated services architecture [ARCH]. 78 Table of Contents 80 1. Introduction ................................................. 3 81 2. Terminology Used in This Document ............................ 5 82 3. Differentiated Services Field Definition ..................... 7 83 4. Historical Codepoint Definitions and PHB Requirements ........ 8 84 4.1 A Default PHB ............................................. 9 85 4.2 Once and Future IP Precedence Field Use ................... 9 86 4.2.1 IP Precedence History and Evolution in Brief .......... 10 87 4.2.2 Subsuming IP Precedence into Class Selector .......... 10 88 Codepoints 89 4.2.2.1 The Class Selector Codepoints ..................... 11 90 4.2.2.2 The Class Selector PHB Requirements ............... 11 91 4.2.2.3 Using the Class Selector PHB Requirements ......... 11 92 for IP Precedence Compatibility 93 4.2.2.4 Example Mechanisms for Implementing Class ......... 12 94 Selector Compliant PHB Groups 95 4.3 Summary ................................................... 12 96 5. Per-Hop Behavior Standardization Guidelines .................. 12 97 6. IANA Considerations .......................................... 14 98 7. Security Considerations ...................................... 14 99 7.1 Theft and Denial of Service ............................... 14 100 7.2 IPsec and Tunneling Interactions .......................... 15 101 8. Acknowledgments .............................................. 16 102 9. References ................................................... 16 103 Appendix A. Examples of Class Selector Compliant PHB ............ 17 104 Implementations 105 A.1 Priority Queues ........................................... 17 107 Nichols, et. al. Expires: February 1999 [Page 2] 108 A.2 Round Robin Queueing ...................................... 18 109 A.3 Virtual Circuit or Virtual Channel Selection .............. 18 110 A.4 Priority Buffer Management ................................ 19 111 Authors' Addresses ............................................... 19 112 Full Copyright Statement ......................................... 20 114 1. Introduction 116 Differentiated services are intended to provide a framework and 117 building blocks to enable deployment of scalable service 118 discrimination in the Internet. The differentiated services approach 119 aims to speed deployment by separating the architecture into two 120 major components, one of which is fairly well-understood and the 121 other of which is just beginning to be understood. In this, we are 122 guided by the original design of the Internet where the decision was 123 made to separate the forwarding and routing components. Packet 124 forwarding is the relatively simple task that needs to be performed 125 on a per-packet basis as quickly as possible. Forwarding uses the 126 packet header to find an entry in a routing table that determines the 127 packet's output interface. Routing sets the entries in that table 128 and may need to reflect a range of transit and other policies as well 129 as to keep track of route failures. Routing tables are maintained as 130 a background process to the forwarding task. Further, routing is the 131 more complex task and it has continued to evolve over the past 20 132 years. 134 Analogously, the differentiated services architecture contains two 135 main components. One is the fairly well-understood behavior in the 136 forwarding path and the other is the more complex and still emerging 137 background policy and allocation component that configures parameters 138 used in the forwarding path. The forwarding path behaviors include 139 the differential treatment an individual packet receives, as 140 implemented by queue service disciplines and/or queue management 141 disciplines. These per-hop behaviors are useful and required in 142 network nodes to deliver differentiated treatment of packets no 143 matter how we construct end-to-end or intra-domain services. Our 144 focus is on the general semantics of the behaviors rather than the 145 specific mechanisms used to implement them since these behaviors will 146 evolve less rapidly than the mechanisms. 148 Per-hop behaviors and mechanisms to select them on a per-packet basis 149 can be deployed in network nodes today and it is this aspect of the 150 differentiated services architecture that is being addressed first. 151 In addition, the forwarding path may require that some monitoring, 152 policing, and shaping be done on the network traffic designated for 153 "special" treatment in order to enforce requirements associated with 154 the delivery of the special treatment. Mechanisms for this kind of 155 traffic conditioning are also fairly well-understood. The wide 156 deployment of such traffic conditioners is also important to enable 157 the construction of services, though their actual use in constructing 158 services may evolve over time. 160 Nichols, et. al. Expires: February 1999 [Page 3] 161 The configuration of network elements with respect to which packets 162 get special treatment and what kinds of rules are to be applied to 163 the use of resources is much less well-understood. Nevertheless, 164 it is possible to deploy useful differentiated services in networks 165 by using simple policies and static configurations. As described in 166 [ARCH], there are a number of ways to compose per-hop behaviors and 167 traffic conditioners to create services. In the process, additional 168 experience is gained that will guide more complex policies and 169 allocations. The basic behaviors in the forwarding path can remain 170 the same while this component of the architecture evolves. 171 Experiences with the construction of such services will continue for 172 some time, thus we avoid standardizing this construction as it is 173 premature. Further, much of the details of service construction are 174 covered by legal agreements between different business entities and 175 we avoid this as it is very much outside the scope of the IETF. 177 This document concentrates on the forwarding path component. In the 178 packet forwarding path, differentiated services are realized by 179 mapping the codepoint contained in a field in the IP packet header to 180 a particular forwarding treatment, or per-hop behavior (PHB), at each 181 network node along its path. The codepoints may be chosen from a set 182 of mandatory values defined later in this document, from a set of 183 recommended values to be defined in future documents, or may have 184 purely local meaning. PHBs are expected to be implemented by 185 employing a range of queue service and/or queue management 186 disciplines on a network node's output interface queue: for example 187 weighted round-robin (WRR) queue servicing or drop-preference queue 188 management. 190 Marking is performed by traffic conditioners at network boundaries, 191 including the edges of the network (first-hop router or source host) 192 and administrative boundaries. Traffic conditioners may include the 193 primitives of marking, metering, policing and shaping (these 194 mechanisms are described in [ARCH]). Services are realized by the 195 use of particular packet classification and traffic conditioning 196 mechanisms at boundaries coupled with the concatenation of per-hop 197 behaviors along the transit path of the traffic. A goal of the 198 differentiated services architecture is to specify these building 199 blocks for future extensibility, both of the number and type of the 200 building blocks and of the services built from them. 202 Terminology used in this draft is defined in Sec. 2. The 203 differentiated services field definition (DS field) is given in Sec. 204 3. In Sec. 4, we discuss the desire for partial backwards 205 compatibility with current use of the IPv4 Precedence field. As a 206 solution, we introduce Class Selector Codepoints and Class Selector 207 Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior 208 standardization. Sec. 6 discusses guidelines for allocation of 209 codepoints. Sec. 7 covers security considerations. We present 210 examples of Class Selector Compliant PHB implementations in the 211 Appendix. 213 Nichols, et. al. Expires: February 1999 [Page 4] 214 This document is a concise description of the DS field and its uses. 215 It is intended to be read along with the differentiated services 216 architecture [ARCH]. 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in [RFC2119]. 222 2. Terminology Used in This Document 224 Behavior Aggregate: a collection of packets with the same codepoint 225 crossing a link in a particular direction. The terms "aggregate" and 226 "behavior aggregate" are used interchangeably in this document. 228 Classifier: an entity which selects packets based on the content of 229 packet headers according to defined rules. 231 Class Selector Codepoint: any of the eight codepoints in the range 232 'xxx000' (where 'x' may equal '0' or '1'). Class Selector Codepoints 233 are discussed in Sec. 4.2.2. 235 Class Selector Compliant PHB: a per-hop behavior satisfying the Class 236 Selector PHB Requirements specified in Sec. 4.2.2.2. 238 Codepoint: a specific value of the DSCP portion of the DS field. 239 Recommended codepoints SHOULD map to specific, standardized PHBs. 240 Multiple codepoints MAY map to the same PHB. 242 Differentiated Services Boundary: the edge of a DS domain, where 243 classifiers and traffic conditioners are likely to be deployed. A 244 differentiated services boundary can be further sub-divided into 245 ingress and egress nodes, where the ingress/egress nodes are the 246 downstream/upstream nodes of a boundary link in a given traffic 247 direction. A differentiated services boundary typically is found at 248 the ingress to the first-hop differentiated services-compliant router 249 (or network node) a host's packets traverse, or at the egress of the 250 last-hop differentiated services-compliant router or network node 251 packets traverse before arriving at a host. This is sometimes 252 referred to as the boundary at a leaf router. A differentiated 253 services boundary might be co-located with a host, subject to local 254 policy. Also DS boundary. 256 Differentiated Services-Compliant: in compliance with the 257 requirements specified in this document. 259 Differentiated Services Domain: a contiguous portion of the Internet 260 over which a consistent set of differentiated services policies are 261 administered in a coordinated fashion. A differentiated services 262 domain can represent different administrative domains or autonomous 263 systems, different trust regions, different network technologies 264 (e.g., cell/frame), hosts and routers, etc. Also DS domain. 266 Nichols, et. al. Expires: February 1999 [Page 5] 267 Differentiated Services Field: the IPv4 header TOS octet or the 268 IPv6 Traffic Class octet when interpreted in conformance with the 269 definition given in this document. Also DS field. 271 Mechanism: The implementation of a per-hop behavior according to a 272 particular algorithm. 274 Microflow: a single instance of an application-to-application flow of 275 packets which is identified by source address, destination address, 276 protocol id, and source port, destination port (where applicable). 278 Per-hop Behavior (PHB): a description of the externally observable 279 forwarding treatment applied at a differentiated services-compliant 280 node to a behavior aggregate. The description of a PHB SHOULD 281 be sufficiently detailed to allow the construction of predictable 282 services. 284 Per-hop Behavior Group: a set of one or more PHBs that can only be 285 meaningfully specified and implemented simultaneously, due to a 286 common constraint applying to all PHBs in the set such as a queue 287 servicing or queue management policy. Also PHB Group. 289 Traffic Conditioning: control functions that can be applied to a 290 behavior aggregate, application flow, or other operationally useful 291 subset of traffic, e.g., routing updates. These MAY include 292 metering, policing, shaping, and packet marking. Traffic 293 conditioning is used to enforce service level agreements between 294 domains and to condition traffic to receive a differentiated service 295 within a domain by marking packets with the appropriate codepoint in 296 the DS field and by monitoring and altering the temporal 297 characteristics of the aggregate where necessary. 299 Traffic Conditioner: an entity which performs traffic conditioning 300 functions and which MAY contain meters, policers, shapers, and 301 markers. Traffic conditioners are typically deployed in DS boundary 302 nodes only. 304 Service: a description of the overall treatment of a customer's 305 traffic across a particular domain, across a set of interconnected 306 DS domains, or end-to-end. Service descriptions are covered by 307 administrative policy and services are constructed by applying 308 traffic conditioning to create behavior aggregates which experience a 309 known PHB at each node within the DS domain. Multiple services can 310 be supported by a single per-hop behavior used in concert with a 311 range of traffic conditioners. 313 To summarize, classifiers and traffic conditioners are used to 314 select which packets are to be added to behavior aggregates. 315 Aggregates receive differentiated treatment in a DS domain and 316 traffic conditioners MAY alter the temporal characteristics of the 317 aggregate to conform to some requirements. A packet's DS field is 318 used to designate the packet's behavior aggregate and is subsequently 320 Nichols, et. al. Expires: February 1999 [Page 6] 321 used to determine which forwarding treatment the packet receives. A 322 DS field classifier which can select a differential output queue 323 servicing discipline (or PHB) based on the codepoint in the DS field 324 SHOULD be included in all network nodes in a DS domain. The 325 classifiers and traffic conditioners at DS boundaries are configured 326 in accordance with some service specification, a matter of 327 administrative policy outside the scope of this document. 329 Additional differentiated services definitions are given in [ARCH]. 331 3. Differentiated Services Field Definition 333 A new header field, called the DS field, is defined, which is 334 intended to supersede the existing definitions of the IPv4 TOS octet 335 [RFC791] and the IPv6 Traffic Class octet [IPv6]. 337 Six bits of the DS field are used as a codepoint (DSCP) to select the 338 PHB a packet experiences at each node. A two-bit currently unused 339 (CU) field is reserved and may be assigned later, e.g., for explicit 340 congestion notification. The value of the CU bits are ignored by 341 differentiated services-compliant nodes when determining the per-hop 342 behavior to apply to a received packet. 344 The DS field structure is presented below: 346 0 1 2 3 4 5 6 7 347 +---+---+---+---+---+---+---+---+ 348 | DSCP | CU | 349 +---+---+---+---+---+---+---+---+ 351 DSCP: differentiated services codepoint 352 CU: currently unused 354 Implementors should note that the DSCP field is six bits wide. DS- 355 compliant nodes MUST select PHBs by matching against the entire 6- 356 bit DSCP field, e.g., by treating the value of the field as a table 357 index which is used to select a particular packet handling mechanism 358 which has been implemented in that device. The DSCP field is defined 359 as an unstructured field to facilitate the definition of future per- 360 hop behaviors. 362 With some exceptions noted below, the mapping of codepoints to PHBs 363 MUST be configurable. A DS-compliant node MUST support the logical 364 equivalent of a configurable mapping table from codepoints to PHBs. 365 PHB specifications MUST include a recommended default codepoint, but 366 operators MAY choose to use different codepoints, either in addition 367 to or in place of the recommended default. Note that if operators do 368 so choose, re-marking of DS fields will be necessary at 369 administrative boundaries even if the same PHBs are implemented on 371 Nichols, et. al. Expires: February 1999 [Page 7] 372 both sides of the boundary. See [ARCH] for further discussion of re- 373 marking. The recommended default codepoint for a PHB MUST be unique 374 for codepoints in the standard space (see Sec. 6). 376 The exceptions to general configurability are for codepoints 'xxx000' 377 and are noted in Secs. 4.2.2 and 4.3. 379 Packets received with an unrecognized codepoint SHOULD be forwarded 380 as if they were marked for the Default behavior (see Sec. 4). Such 381 packets MUST NOT cause the network node to crash. 383 The structure of the DS field shown above is incompatible with the 384 existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The 385 presumption is that DS domains protect themselves by deploying re- 386 marking boundary nodes, as should networks using the RFC 791 387 Precedence designations. Correct operational procedure SHOULD follow 388 [RFC791], which states: "If the actual use of these precedence 389 designations is of concern to a particular network, it is the 390 responsibility of that network to control the access to, and use of, 391 those precedence designations." Validating the value of the DS field 392 at DS boundaries is sensible in any case since an upstream node can 393 easily set it to any random value. DS domains which are not suitably 394 isolated by a re-marking boundary node may deliver unpredictable 395 service. 397 Nodes MAY rewrite the DS field as needed to provide a desired local 398 or end-to-end service. Specifications of DS field translations at 399 DS boundaries are the subject of service level agreements between 400 providers and users, and are outside the scope of this document. 401 Standardized PHBs allow providers to build their services from a 402 well-known set of packet forwarding treatments that can be expected 403 to be present in the equipment of many vendors. 405 4. Historical Codepoint Definitions and PHB Requirements 407 The DS field will have a limited backwards compatibility with current 408 practice, as described in this section. Backwards compatibility is 409 addressed in two ways. First, there are per-hop behaviors that are 410 already in widespread use (e.g., those satisfying the IPv4 Precedence 411 queueing requirements specified in [RFC1812]), and we wish to permit 412 their continued use in DS-compliant nodes. In addition, there are 413 some codepoints that correspond to historical use of the IP 414 Precedence field and we reserve these codepoints to map to PHBs that 415 meet the general requirements specified in Sec. 4.2.2.2, though the 416 specific differentiated services PHBs mapped to by those codepoints 417 MAY have additional specifications. 419 No attempt is made to maintain backwards compatibility with the "DTR" 420 or TOS bits of the IPv4 TOS octet, as defined in [RFC791, RFC1349]. 422 Nichols, et. al. Expires: February 1999 [Page 8] 423 4.1 A Default PHB 425 A "default" PHB MUST be available in a DS-compliant node. This is 426 the common, best-effort forwarding behavior available in existing 427 routers as standardized in [RFC1812]. When no other agreements are 428 in place, it is assumed that packets belong to this aggregate. Such 429 packets MAY be sent into a network without adhering to any particular 430 rules and the network will deliver as many of these packets as 431 possible and as soon as possible, subject to other resource policy 432 constraints. A reasonable implementation of this PHB would be a 433 queueing discipline that sends packets of this aggregate whenever the 434 output link is not required to satisfy another PHB. A reasonable 435 policy for constructing services would ensure that the aggregate was 436 not "starved". This could be enforced by a mechanism in each node 437 that reserves some minimal resources (e.g, buffers, bandwidth) for 438 Default behavior aggregates. This permits senders that are not 439 differentiated services-aware to continue to use the network in the 440 same manner as today. The impact of the introduction of 441 differentiated services into a domain on the service expectations of 442 its customers and peers is a complex matter involving policy 443 decisions by the domain and is outside the scope of this document. 444 The RECOMMENDED codepoint for the Default PHB is the bit pattern 445 '000000'; the value '000000' MUST map to a PHB that meets these 446 specifications. The codepoint chosen for Default behavior is 447 compatible with existing practice [RFC791, RFC1349]. Where a 448 codepoint is not mapped to a standardized or local use PHB, it SHOULD 449 be mapped to the Default PHB. 451 A "default" PHB MUST be available in a DS-compliant node. This is 452 A packet initially marked for the Default behavior MAY be re-marked 453 with another codepoint as it passes a boundary into a DS domain so 454 that it will be forwarded using a different PHB within that domain, 455 possibly subject to some negotiated agreement between the peering 456 domains. 458 4.2 Once and Future IP Precedence Field Use 460 We wish to maintain some form of backward compatibility with present 461 uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet. 462 Routers exist that use the IP Precedence field to select different 463 per-hop forwarding treatments quite similarly to the use proposed 464 here for the DSCP field. Thus, a simple prototype differentiated 465 services architecture can be quickly deployed by appropriately 466 configuring these routers. Further, IP systems today understand the 467 location of the IP Precedence field, and thus if these bits are used 468 in a similar manner as DS-compliant equipment is deployed, 469 significant failures are not likely during early deployment. In 470 other words, strict DS-compliance need not be ubiquitous even within 471 a single service provider's network if bits 0-2 of the DSCP field 472 are employed in a manner similar to, or subsuming, the deployed uses 473 of the IP Precedence field. 475 Nichols, et. al. Expires: February 1999 [Page 9] 476 4.2.1 IP Precedence History and Evolution in Brief 478 The IP Precedence field is something of a forerunner of the DS field. 479 IP Precedence, and the IP Precedence Field, were first defined in 480 [RFC791]. The values that the three-bit IP Precedence Field might 481 take were assigned to various uses, including network control 482 traffic, routing traffic, and various levels of privilege. The least 483 level of privilege was deemed "routine traffic". In [RFC791], the 484 notion of Precedence was defined broadly as " An independent measure 485 of the importance of this datagram." Not all values of the IP 486 Precedence field were assumed to have meaning across boundaries, for 487 instance "The Network Control precedence designation is intended to 488 be used within a network only. The actual use and control of that 489 designation is up to each network." [RFC791] 491 Although early BBN IMPs implemented the Precedence feature, early 492 commercial routers and UNIX IP forwarding code generally did not. As 493 networks became more complex and customer requirements grew, 494 commercial router vendors developed ways to implement various kinds 495 of queueing services including priority queueing, which were 496 generally based on policies encoded in filters in the routers, which 497 examined IP addresses, IP protocol numbers, TCP or UDP ports, and 498 other header fields. IP Precedence was and is among the options such 499 filters can examine. 501 In short, IP Precedence is widely deployed and widely used, if not in 502 exactly the manner intended in [RFC791]. This was recognized in 503 [RFC1122], which states that while the use of the IP Precedence field 504 is valid, the specific assignment of the priorities in [RFC791] were 505 merely historical. 507 4.2.2 Subsuming IP Precedence into Class Selector Codepoints 509 A specification of the packet forwarding treatments selected by the 510 IP Precedence field today would have to be quite general; probably 511 not specific enough to build predictable services from in the 512 differentiated services framework. To preserve partial backwards 513 compatibility with known current uses of the IP Precedence field 514 without sacrificing future flexibility, we have taken the approach of 515 describing minimum requirements on a set of PHBs that are compatible 516 with most of the deployed forwarding treatments selected by the IP 517 Precedence field. In addition, we give a set of codepoints that MUST 518 map to PHBs meeting these minimum requirements. The PHBs mapped to 519 by these codepoints MAY have a more detailed list of specifications 520 in addition to the required ones stated here. Other codepoints MAY 521 map to these same PHBs. We refer to this set of codepoints as the 522 Class Selector Codepoints, and the minimum requirements for PHBs that 523 these codepoints may map to are called the Class Selector PHB 524 Requirements. 526 4.2.2.1 The Class Selector Codepoints 528 The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU 529 subfield unspecified, are reserved as a set of Class Selector 530 Codepoints. PHBs which are mapped to by these codepoints MUST 531 satisfy the Class Selector PHB requirements in addition to preserving 532 the Default PHB requirement on codepoint '000000' (Sec. 4.1). 534 4.2.2.2 The Class Selector PHB Requirements 536 We refer to a Class Selector Codepoint with a larger numerical value 537 than another Class Selector Codepoint as having a higher relative 538 order while a Class Selector Codepoint with a smaller numerical value 539 than another Class Selector Codepoint is said to have a lower 540 relative order. The set of PHBs mapped to by the eight Class 541 Selector Codepoints MUST yield at least two independently forwarded 542 classes of traffic, and PHBs selected by a Class Selector Codepoint 543 SHOULD give packets a probability of timely forwarding that is not 544 lower than that given to packets marked with a Class Selector 545 codepoint of lower relative order, assuming roughly equivalent loads 546 for each behavior aggregate. A discarded packet is considered to be 547 an extreme case of untimely forwarding. In addition, PHBs selected 548 by codepoint '11x000' MUST give packets a preferential forwarding 549 treatment by comparison to the PHB selected by codepoint '000000' to 550 preserve the common usage of IP Precedence values '110' and '111' for 551 routing traffic. 553 Where the relative loads of two or more Class Selector behavior 554 aggregates are not roughly equivalent, the relative ordering of the 555 observed forwarding behaviors is dependent on details of the PHB 556 specification that are not defined here. A discarded packet is 557 considered to be an extreme case of untimely forwarding. 559 Further, PHBs selected by distinct Class Selector Codepoints SHOULD 560 be independently forwarded; that is, packets marked with different 561 Class Selector Codepoints MAY be re-ordered. A network node MAY 562 enforce limits on the amount of the node's resources that can be 563 utilized by each of these PHBs. 565 PHB groups whose specification satisfy these requirements are 566 referred to as Class Selector Compliant PHBs. 568 The Class Selector PHB Requirements on codepoint '000000' are 569 compatible with those listed for the Default PHB in Sec. 4.1. 571 4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence 572 Compatibility 574 A DS-compliant network node can be deployed with a set of one or more 575 Class Selector Compliant PHB groups. This document states that the 576 set of codepoints 'xxx000' MUST map to such a set of PHBs. As it is 577 also possible to map multiple codepoints to the same PHB, the vendor 578 or the network administrator MAY configure the network node to map 579 codepoints to PHBs irrespective of bits 3-5 of the DSCP field to 580 yield a network that is compatible with historical IP Precedence use. 581 Thus, for example, codepoint '011010' would map to the same PHB as 582 codepoint '011000'. 584 4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant 585 PHB Groups 587 Class Selector Compliant PHBs can be realized by a variety of 588 mechanisms, including strict priority queueing, weighted fair 589 queueing (WFQ), WRR, or variants [RPS, HPFQA, DRR], or Class-Based 590 Queuing [CBQ]. The distinction between PHBs and mechanisms is 591 described in more detail in Sec. 5. 593 It is important to note that these mechanisms might be available 594 through other PHBs (standardized or not) that are available in a 595 particular vendor's equipment. For example, future documents may 596 standardize a Strict Priority Queueing PHB group for a set of 597 recommended codepoints. A network administrator might configure 598 those routers to select the Strict Priority Queueing PHBs with 599 codepoints 'xxx000' in conformance with the requirements of this 600 document. 602 As a further example, another vendor might employ a CBQ mechanism in 603 its routers. The CBQ mechanism could be used to implement the Strict 604 Priority Queueing PHBs as well as a set of Class Selector Compliant 605 PHBs with a wider range of features than would be available in a set 606 of PHBs that did no more than meet the minimum Class Selector PHB 607 requirements. More examples are given in the Appendix. 609 4.3 Summary 611 This document defines codepoints 'xxx000' as the Class Selector 612 codepoints, where PHBs selected by these codepoints MUST meet the 613 Class Selector PHB Requirements described in Sec. 4.2.2.2. This is 614 done to preserve a useful level of backward compatibility with 615 current uses of the IP Precedence field in the Internet without 616 unduly limiting future flexibility. In addition, codepoint '000000' 617 is used as the Default PHB value for the Internet and, as such, is 618 not configurable. The remaining seven non-zero Class Selector 619 codepoints are configurable only to the extent that they map to PHBs 620 that meet the requirements in Sec. 4.2.2.2. 622 5. Per-Hop Behavior Standardization Guidelines 624 The behavioral characteristics of a PHB are to be standardized, and 625 not the particular algorithms or the mechanisms used to implement 626 them. A node may have a (possibly large) set of parameters that can 627 be used to control how packets are scheduled onto an output interface 628 (e.g., N separate queues with settable priorities, queue lengths, 629 round-robin weights, drop algorithm, drop preference weights and 630 thresholds, etc). To illustrate the distinction between a PHB and a 631 mechanism, we point out that Class Selector Compliant PHBs might be 632 implemented by several mechanisms, including: strict priority 633 queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in 634 isolation or in combination (see Appendix). 636 PHBs may be specified individually, or as a group (a single PHB is a 637 special case of a PHB group). A PHB group usually consists of a set 638 two or more PHBs that can only be meaningfully specified and 639 implemented simultaneously, due to a common constraint applying to 640 each PHB within the group, such as a queue servicing or queue 641 management policy. A PHB group specification SHOULD describe 642 conditions under which a packet might be re-marked to select another 643 PHB within the group. It is RECOMMENDED that PHB implementations do 644 not introduce any packet re-ordering within a microflow. PHB group 645 specifications MUST identify any possible packet re-ordering 646 implications which may occur for each individual PHB, and which may 647 occur if different packets within a microflow are marked for 648 different PHBs within the group. 650 Only those per-hop behaviors that are not described by an existing 651 PHB standard, and have been implemented, deployed, and shown to be 652 useful, SHOULD be standardized. Since current experience with 653 differentiated services is quite limited, it is premature to 654 hypothesize the exact specification of these per-hop behaviors. 656 Each standardized PHB MUST have an associated RECOMMENDED codepoint, 657 allocated out of a space of 32 codepoints (see Sec. 6). This 658 specification has left room in the codepoint space to allow for 659 evolution, thus the defined space ('xxx000') is intentionally sparse. 661 Network equipment vendors are free to offer whatever parameters and 662 capabilities are deemed useful or marketable. When a particular, 663 standardized PHB is implemented in a node, a vendor MAY use any 664 algorithm that satisfies the definition of the PHB according to the 665 standard. The node's capabilities and its particular configuration 666 determine the different ways that packets can be treated. 668 Service providers are not required to use the same node mechanisms 669 or configurations to enable service differentiation within their 670 networks, and are free to configure the node parameters in whatever 671 way that is appropriate for their service offerings and traffic 672 engineering objectives. Over time certain common per-hop behaviors 673 are likely to evolve (i.e., ones that are particularly useful for 674 implementing end-to-end services) and these MAY be associated with 675 particular EXP/LU PHB codepoints in the DS field, allowing use across 676 domain boundaries (see Sec. 6). These PHBs are candidates for future 677 standardization. 679 6. IANA Considerations 681 The DSCP field within the DS field is capable of conveying 64 682 distinct codepoints. The codepoint space is divided into three pools 683 for the purpose of codepoint assignment and management: a pool of 32 684 RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as 685 defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved for 686 experimental or Local Use (EXP/LU) as defined in [CONS], and a pool 687 of 16 codepoints (Pool 3) which are initially available for 688 experimental or local use, but which should be preferentially 689 utilized for standardized assignments if Pool 1 is ever exhausted. 690 The pools are defined in the following table (where 'x' refers to 691 either '0' or '1'): 693 Pool Codepoint space Assignment Policy 694 ---- --------------- ----------------- 696 1 xxxxx0 Standards Action 697 2 xxxx11 EXP/LU 698 3 xxxx01 EXP/LU (*) 700 (*) may be utilized for future Standards Action allocations as 701 necessary 703 This document assigns eight RECOMMENDED codepoints ('xxx000') which 704 are drawn from Pool 1 above. These codepoints MUST be mapped, not to 705 specific PHBs, but to PHBs that meet "at least" the requirements set 706 forth in Sec. 4.2.2.2 to provide a minimal level of backwards 707 compatibility with IP Precedence as defined in [RFC791] and as 708 deployed in some current equipment. 710 7. Security Considerations 712 This section considers security issues raised by the introduction of 713 differentiated services, primarily the potential for denial-of- 714 service attacks, and the related potential for theft of service by 715 unauthorized traffic (Section 7.1). Section 7.2 addresses the 716 operation of differentiated services in the presence of IPsec 717 including its interaction with IPsec tunnel mode and other tunneling 718 protocols. More extensive treatment of the security concerns raised 719 by the overall differentiated services architecture are discussed in 720 [ARCH]. 722 7.1 Theft and Denial of Service 724 The primary goal of differentiated services is to allow different 725 levels of service to be provided for traffic streams on a common 726 network infrastructure. A variety of techniques may be used to 727 achieve this, but the end result will be that some packets receive 728 different (e.g., better) service than others. The mapping of network 729 traffic to the specific behaviors that result in different (e.g., 730 better or worse) service is indicated primarily by the DS codepoint, 731 and hence an adversary may be able to obtain better service by 732 modifying the codepoint to values indicating behaviors used for 733 enhanced services or by injecting packets with such codepoint values. 734 Taken to its limits, such theft of service becomes a denial-of- 735 service attack when the modified or injected traffic depletes the 736 resources available to forward it and other traffic streams. 738 The defense against this class of theft- and denial-of-service 739 attacks consists of the combination of traffic conditioning at 740 network boundaries with security and integrity of the network 741 infrastructure within a DS domain. Network boundary nodes MUST 742 ensure that all traffic entering the domain is marked with codepoint 743 values appropriate to the traffic and the domain, remarking the 744 traffic with new codepoint values if necessary. These DS boundary 745 nodes are the primary line of defense against theft- and denial-of- 746 service attacks based on modified codepoints, as success of any such 747 attack indicates that the codepoints used by the attacking traffic 748 were inappropriate. An important instance of a boundary node is that 749 any traffic-originating node within a DS domain is the initial 750 boundary node for that traffic. Interior nodes in a DS domain rely 751 on DS codepoints to associate traffic with the forwarding PHBs, and 752 are not required to check codepoint values before using them. As a 753 result, the interior nodes depend on the correct operation of the DS 754 domain to prevent the arrival of traffic with inappropriate 755 codepoints that would disrupt operation of the domain. 757 7.2 IPsec and Tunnelling Interactions 759 The IPsec protocol, as defined in [ESP, AH], does not include the IP 760 header's DS field in any of its cryptographic calculations (in the 761 case of tunnel mode, it is the outer IP header's DS field that is not 762 included). Hence modification of the DS field by a network node has 763 no effect on IPsec's end-to-end security, because it cannot cause any 764 IPsec integrity check to fail. As a consequence, IPsec does not 765 provide any defense against an adversary's modification of the DS 766 field (i.e., a man-in-the-middle attack), as the adversary's 767 modification will also have no effect on IPsec's end-to-end security. 769 IPsec's tunnel mode provides security for the encapsulated IP 770 header's DS field. A tunnel mode IPsec packet contains two IP 771 headers: an outer header supplied by the tunnel ingress node and an 772 encapsulated inner header supplied by the original source of the 773 packet. When an IPsec tunnel is hosted (in whole or in part) on a 774 differentiated services network, the intermediate network nodes 775 operate on the DS field in the outer header. At the tunnel egress 776 node, IPsec processing includes removing the outer header and 777 forwarding the packet (if required) using the inner header. The 778 IPsec protocol REQUIRES that the inner header's DS field not be 779 changed by this decapsulation processing to ensure that modifications 780 to the DS field cannot be used to launch theft- or denial-of-service 781 attacks across an IPsec tunnel endpoint. This document makes no 782 change to that requirement. If the inner IP header has not been 783 processed by a DS boundary node for the tunnel egress node's DS 784 domain, the tunnel egress node is the boundary node for traffic 785 exiting the tunnel, and hence MUST ensure that the resulting traffic 786 has appropriate DS codepoints. 788 When IPsec tunnel egress decapsulation processing includes a 789 sufficiently strong cryptographic integrity check of the encapsulated 790 packet (where sufficiency is determined by local security policy), 791 the tunnel egress node can safely assume that the DS field in the 792 inner header has the same value as it had at the tunnel ingress node. 793 An important consequence is that otherwise insecure links within a DS 794 domain can be secured by a sufficiently strong IPsec tunnel. This 795 analysis and its implications apply to any tunneling protocol that 796 performs integrity checks, but the level of assurance of the inner 797 header's DS field depends on the strength of the integrity check 798 performed by the tunneling protocol. In the absence of sufficient 799 assurance for a tunnel that may transit nodes outside the current DS 800 domain (or is otherwise vulnerable), the encapsulated packet MUST be 801 treated as if it had arrived at a boundary from outside the DS 802 domain. 804 8. Acknowledgements 806 The authors would like to acknowledge the Differentiated Services 807 Working Group for discussions which helped shape this document. 809 9. References 811 [AH] S. Kent and R. Atkinson, "IP Authentication Header", 812 Internet Draft , 813 July 1998. 815 [ARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and 816 W. Weiss, "An Architecture for Differentiated Services", 817 Internet Draft , 818 August 1998. 820 [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource 821 Management Models for Packet Networks", IEEE/ACM 822 Transactions on Networking, Vol. 3 no. 4, pp. 365-386, 823 August 1995. 825 [CLARK] D. Clark and W. Fang, "Explicit Allocation of Best 826 Effort Packet Delivery Service", 827 http://diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf 829 [CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an 830 IANA Considerations Section in RFCs", Internet Draft 831 , May 1998. 833 [DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing 834 using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995. 836 [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security 837 Payload (ESP)", Internet Draft 838 , July 1998. 840 [HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair 841 Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996. 843 [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 844 (IPv6) Specification", Internet Draft 845 , November 1997. 847 [RFC791] Information Sciences Institute, "Internet Protocol", 848 Internet RFC 791, September 1981. 850 [RFC1122] R. T. Braden, "Requirements for Internet hosts - 851 communication layers", Internet RFC 1122, October 1989. 853 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol 854 Suite", Internet RFC 1349, July 1992. 856 [RFC1812] F. Baker, editor, "Requirements for IP Version 4 857 Routers", Internet RFC 1812, June 1995. 859 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 860 Requirement Levels", Internet RFC 2119, March 1997. 862 [RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: 863 A Design Methodology for Fair Queueing Algorithms", IEEE/ 864 ACM Trans. on Networking, April 1998. 866 Appendix. Examples of Class Selector Compliant PHB Implementations 868 This appendix shows how four different mechanisms can be used to 869 implement Class Selector Compliant PHBs. 871 A.1 Priority Queues 873 This approach employs eight queues where each of the eight codepoints 874 maps to a different queue. Queues are serviced in priority order so 875 that each queue, from the perspective of the next lower priority 876 queue, implements a "low loss, low delay" forwarding behavior. As an 877 alternative, one can employ four queues, where bits 0 and 1 of the 878 codepoint are used to select the queue. Bit 2 of the codepoint is 879 used as a drop preference within the queue. RED is used within the 880 queues according to its usual parameters, but with in-profile traffic 881 having a higher min-threshold and max-threshold than out-of-profile 882 traffic, and therefore experiencing a higher probability of timely 883 delivery [CLARK]. Out-of-profile traffic should consider the 884 presence of lower order in-profile traffic in the calculation of drop 885 probability. 887 The strength of this second approach is that packet order is 888 maintained within each precedence queue, but higher ordered traffic 889 may be sent before lower ordered traffic (since lower ordered traffic 890 within a queue may be dropped). It has a weakness, however, in that 891 apart from admission control and policing, it affords lower 892 precedence traffic no assurance of eventual transmission. 894 A.2 Weighted Link-Share Queueing 896 Like the previous example, this approach employs a queue per 897 codepoint, but each queue is emptied at some non-zero rate, in round- 898 robin order by means of some appropriate algorithm [HPFQA, RPS, DRR], 899 rather than being given simple priority service. 901 The strength of this approach is that higher ordered traffic is, on 902 average, queued for a shorter duration than lower ordered traffic, 903 assuming roughly equivalent relative loads for each order. It also 904 avoids the lockout issue that priority queuing systems may 905 experience. A counter-intuitive scenario can occur, however, if a 906 high rate queue is heavily utilized while a lower rate queue is 907 under-utilized; a packet directed to the lower rate queue can 908 actually be better protected from loss and variation in delay when 909 placed in an empty or very short queue. 911 A.3 Virtual Circuit or Virtual Channel Selection 913 The difference between this approach and Weighted Link-Share Queuing 914 is somewhat academic. If one has a serial line to a routing 915 neighbor, and manages the link using a link sharing algorithm, the 916 link sharing algorithm in some sense emulates the way the line would 917 behave if it were in reality a number of different lines, or if it 918 were one channelized line. In a virtual circuit selection model, the 919 emulation becomes reality - one deploys a set of rate-limited VCs to 920 a routing neighbor, and uses them in the same way one would otherwise 921 have used round-robin queues. 923 The strengths and weaknesses are very similar to those of Weighted 924 Link-Share Queuing, except that this allows one to capitalize on the 925 capabilities of a link layer such as ATM or Frame Relay. 927 A.4 Priority Buffer Management 929 This approach assigns buffer occupancy thresholds for each codepoint, 930 with the threshold for a higher ordered codepoint being no lower than 931 the threshold for a lower ordered codepoint. Under link congestion, 932 packets marked with a lower ordered codepoint are discard before 933 those packets marked with a higher ordered codepoint. The 934 thresholding mechanism might be deterministic, or based on average 935 queue occupancies and statistical discard probability weighting 936 functions [CLARK]. 938 Authors' Addresses 940 Kathleen Nichols 941 Bay Networks Architecture Lab 942 4401 Great America Parkway 943 SC01-04 944 Santa Clara, CA 95052-8185 945 Phone: +1-408-495-3252 946 Fax: +1-408-495-1299 947 E-mail: knichols@baynetworks.com 949 Steven Blake 950 Torrent Networking Technologies 951 2221 Broadbirch Drive 952 Silver Spring, MD 20904 953 Phone: +1-301-625-1600 954 E-mail: slblake@torrentnet.com 956 Fred Baker 957 Cisco Systems 958 519 Lado Drive 959 Santa Barbara, California 93111 960 Phone: +1-408-526-4257 961 E-mail: fred@cisco.com 963 David L. Black 964 The Open Group 965 11 Cambridge Center 966 Cambridge, MA 02142 967 Phone: +1-617-621-7347 968 E-mail: d.black@opengroup.org 970 Full Copyright Statement 972 Copyright (C) The Internet Society (1998). All Rights Reserved. 974 This document and translations of it may be copied and furnished to 975 others, and derivative works that comment on or otherwise explain it 976 or assist in its implementation may be prepared, copied, published 977 and distributed, in whole or in part, without restriction of any 978 kind, provided that the above copyright notice and this paragraph are 979 included on all such copies and derivative works. However, this 980 document itself may not be modified in any way, such as by removing 981 the copyright notice or references to the Internet Society or other 982 Internet organizations, except as needed for the purpose of 983 developing Internet standards in which case the procedures for 984 copyrights defined in the Internet Standards process must be 985 followed, or as required to translate it into languages other than 986 English. 988 The limited permissions granted above are perpetual and will not be 989 revoked by the Internet Society or its successors or assigns. 991 This document and the information contained herein is provided on an 992 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 993 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 994 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 995 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 996 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.