idnits 2.17.1 draft-ietf-diffserv-header-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 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. ** 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 109 has weird spacing: '...ntended to pr...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 (October 1998) is 9319 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. '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' -- Possible downref: Non-RFC (?) normative reference: ref. 'RPS' Summary: 7 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 Cisco Systems 3 Expires: April 1999 Steven Blake 4 Torrent Networking Technologies 5 Fred Baker 6 Cisco Systems 7 David L. Black 8 EMC Corporation 9 October 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 Internet protocol are 41 intended to enable scalable service discrimination in the Internet 42 without the need for per-flow state and signaling at every hop. A 43 variety of services may be built from a small, well-defined set of 44 building blocks which are deployed in network nodes. The services 45 may be either end-to-end or intra-domain; they include both those 46 that can satisfy quantitative performance requirements (e.g., peak 47 bandwidth) 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: April 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 63 a 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 .......................................... 13 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 Authors' Addresses ............................................... 17 104 Full Copyright Statement ......................................... 18 106 Nichols, et. al. Expires: April 1999 [Page 2] 107 1. Introduction 109 Differentiated services are intended to provide a framework and 110 building blocks to enable deployment of scalable service 111 discrimination in the Internet. The differentiated services approach 112 aims to speed deployment by separating the architecture into two 113 major components, one of which is fairly well-understood and the 114 other of which is just beginning to be understood. In this, we are 115 guided by the original design of the Internet where the decision was 116 made to separate the forwarding and routing components. Packet 117 forwarding is the relatively simple task that needs to be performed 118 on a per-packet basis as quickly as possible. Forwarding uses the 119 packet header to find an entry in a routing table that determines the 120 packet's output interface. Routing sets the entries in that table 121 and may need to reflect a range of transit and other policies as well 122 as to keep track of route failures. Routing tables are maintained as 123 a background process to the forwarding task. Further, routing is the 124 more complex task and it has continued to evolve over the past 20 125 years. 127 Analogously, the differentiated services architecture contains two 128 main components. One is the fairly well-understood behavior in the 129 forwarding path and the other is the more complex and still emerging 130 background policy and allocation component that configures parameters 131 used in the forwarding path. The forwarding path behaviors include 132 the differential treatment an individual packet receives, as 133 implemented by queue service disciplines and/or queue management 134 disciplines. These per-hop behaviors are useful and required in 135 network nodes to deliver differentiated treatment of packets no 136 matter how we construct end-to-end or intra-domain services. Our 137 focus is on the general semantics of the behaviors rather than the 138 specific mechanisms used to implement them since these behaviors will 139 evolve less rapidly than the mechanisms. 141 Per-hop behaviors and mechanisms to select them on a per-packet basis 142 can be deployed in network nodes today and it is this aspect of the 143 differentiated services architecture that is being addressed first. 144 In addition, the forwarding path may require that some monitoring, 145 policing, and shaping be done on the network traffic designated for 146 "special" treatment in order to enforce requirements associated with 147 the delivery of the special treatment. Mechanisms for this kind of 148 traffic conditioning are also fairly well-understood. The wide 149 deployment of such traffic conditioners is also important to enable 150 the construction of services, though their actual use in constructing 151 services may evolve over time. 153 The configuration of network elements with respect to which packets 154 get special treatment and what kinds of rules are to be applied to 155 the use of resources is much less well-understood. Nevertheless, 156 it is possible to deploy useful differentiated services in networks 157 by using simple policies and static configurations. As described in 158 [ARCH], there are a number of ways to compose per-hop behaviors and 160 Nichols, et. al. Expires: April 1999 [Page 3] 161 traffic conditioners to create services. In the process, additional 162 experience is gained that will guide more complex policies and 163 allocations. The basic behaviors in the forwarding path can remain 164 the same while this component of the architecture evolves. 165 Experiences with the construction of such services will continue for 166 some time, thus we avoid standardizing this construction as it is 167 premature. Further, much of the details of service construction are 168 covered by legal agreements between different business entities and 169 we avoid this as it is very much outside the scope of the IETF. 171 This document concentrates on the forwarding path component. In the 172 packet forwarding path, differentiated services are realized by 173 mapping the codepoint contained in a field in the IP packet header to 174 a particular forwarding treatment, or per-hop behavior (PHB), at each 175 network node along its path. The codepoints may be chosen from a set 176 of mandatory values defined later in this document, from a set of 177 recommended values to be defined in future documents, or may have 178 purely local meaning. PHBs are expected to be implemented by 179 employing a range of queue service and/or queue management 180 disciplines on a network node's output interface queue: for example 181 weighted round-robin (WRR) queue servicing or drop-preference queue 182 management. 184 Marking is performed by traffic conditioners at network boundaries, 185 including the edges of the network (first-hop router or source host) 186 and administrative boundaries. Traffic conditioners may include the 187 primitives of marking, metering, policing and shaping (these 188 mechanisms are described in [ARCH]). Services are realized by the 189 use of particular packet classification and traffic conditioning 190 mechanisms at boundaries coupled with the concatenation of per-hop 191 behaviors along the transit path of the traffic. A goal of the 192 differentiated services architecture is to specify these building 193 blocks for future extensibility, both of the number and type of the 194 building blocks and of the services built from them. 196 Terminology used in this draft is defined in Sec. 2. The 197 differentiated services field definition (DS field) is given in Sec. 198 3. In Sec. 4, we discuss the desire for partial backwards 199 compatibility with current use of the IPv4 Precedence field. As a 200 solution, we introduce Class Selector Codepoints and Class Selector 201 Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior 202 standardization. Sec. 6 discusses guidelines for allocation of 203 codepoints. Sec. 7 covers security considerations. 205 This document is a concise description of the DS field and its uses. 206 It is intended to be read along with the differentiated services 207 architecture [ARCH]. 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in [RFC2119]. 213 Nichols, et. al. Expires: April 1999 [Page 4] 214 2. Terminology Used in This Document 216 Behavior Aggregate: a collection of packets with the same codepoint 217 crossing a link in a particular direction. The terms "aggregate" and 218 "behavior aggregate" are used interchangeably in this document. 220 Classifier: an entity which selects packets based on the content of 221 packet headers according to defined rules. 223 Class Selector Codepoint: any of the eight codepoints in the range 224 'xxx000' (where 'x' may equal '0' or '1'). Class Selector Codepoints 225 are discussed in Sec. 4.2.2. 227 Class Selector Compliant PHB: a per-hop behavior satisfying the Class 228 Selector PHB Requirements specified in Sec. 4.2.2.2. 230 Codepoint: a specific value of the DSCP portion of the DS field. 231 Recommended codepoints SHOULD map to specific, standardized PHBs. 232 Multiple codepoints MAY map to the same PHB. 234 Differentiated Services Boundary: the edge of a DS domain, where 235 classifiers and traffic conditioners are likely to be deployed. A 236 differentiated services boundary can be further sub-divided into 237 ingress and egress nodes, where the ingress/egress nodes are the 238 downstream/upstream nodes of a boundary link in a given traffic 239 direction. A differentiated services boundary typically is found at 240 the ingress to the first-hop differentiated services-compliant router 241 (or network node) that a host's packets traverse, or at the egress of 242 the last-hop differentiated services-compliant router or network node 243 that packets traverse before arriving at a host. This is sometimes 244 referred to as the boundary at a leaf router. A differentiated 245 services boundary may be co-located with a host, subject to local 246 policy. Also DS boundary. 248 Differentiated Services-Compliant: in compliance with the 249 requirements specified in this document. Also DS-compliant. 251 Differentiated Services Domain: a contiguous portion of the Internet 252 over which a consistent set of differentiated services policies are 253 administered in a coordinated fashion. A differentiated services 254 domain can represent different administrative domains or autonomous 255 systems, different trust regions, different network technologies 256 (e.g., cell/frame), hosts and routers, etc. Also DS domain. 258 Differentiated Services Field: the IPv4 header TOS octet or the 259 IPv6 Traffic Class octet when interpreted in conformance with the 260 definition given in this document. Also DS field. 262 Mechanism: The implementation of one or more per-hop behaviors 263 according to a particular algorithm. 265 Microflow: a single instance of an application-to-application flow of 267 Nichols, et. al. Expires: April 1999 [Page 5] 268 packets which is identified by source address, destination address, 269 protocol id, and source port, destination port (where applicable). 271 Per-hop Behavior (PHB): a description of the externally observable 272 forwarding treatment applied at a differentiated services-compliant 273 node to a behavior aggregate. The description of a PHB SHOULD 274 be sufficiently detailed to allow the construction of predictable 275 services, as documented in [ARCH]. 277 Per-hop Behavior Group: a set of one or more PHBs that can only be 278 meaningfully specified and implemented simultaneously, due to a 279 common constraint applying to all PHBs in the set such as a queue 280 servicing or queue management policy. Also PHB Group. 282 Traffic Conditioning: control functions that can be applied to a 283 behavior aggregate, application flow, or other operationally useful 284 subset of traffic, e.g., routing updates. These MAY include 285 metering, policing, shaping, and packet marking. Traffic 286 conditioning is used to enforce service level agreements between 287 domains and to condition traffic to receive a differentiated service 288 within a domain by marking packets with the appropriate codepoint in 289 the DS field and by monitoring and altering the temporal 290 characteristics of the aggregate where necessary. See [ARCH]. 292 Traffic Conditioner: an entity that performs traffic conditioning 293 functions and which MAY contain meters, policers, shapers, and 294 markers. Traffic conditioners are typically deployed in DS boundary 295 nodes (i.e., not in interior nodes of a DS domain). 297 Service: a description of the overall treatment of (a subset of) a 298 customer's traffic across a particular domain, across a set of 299 interconnected DS domains, or end-to-end. Service descriptions are 300 covered by administrative policy and services are constructed by 301 applying traffic conditioning to create behavior aggregates which 302 experience a known PHB at each node within the DS domain. Multiple 303 services can be supported by a single per-hop behavior used in 304 concert with a range of traffic conditioners. 306 To summarize, classifiers and traffic conditioners are used to select 307 which packets are to be added to behavior aggregates. Aggregates 308 receive differentiated treatment in a DS domain and traffic 309 conditioners MAY alter the temporal characteristics of the aggregate 310 to conform to some requirements. A packet's DS field is used to 311 designate the packet's behavior aggregate and is subsequently used to 312 determine which forwarding treatment the packet receives. A behavior 313 aggregate classifier which can select a PHB, for example a 314 differential output queue servicing discipline, based on the 315 codepoint in the DS field SHOULD be included in all network nodes in 316 a DS domain. The classifiers and traffic conditioners at DS 317 boundaries are configured in accordance with some service 318 specification, a matter of administrative policy outside the scope of 319 this document. 321 Nichols, et. al. Expires: April 1999 [Page 6] 322 Additional differentiated services definitions are given in [ARCH]. 324 3. Differentiated Services Field Definition 326 A replacement header field, called the DS field, is defined, which is 327 intended to supersede the existing definitions of the IPv4 TOS octet 328 [RFC791] and the IPv6 Traffic Class octet [IPv6]. 330 Six bits of the DS field are used as a codepoint (DSCP) to select the 331 PHB a packet experiences at each node. A two-bit currently unused 332 (CU) field is reserved and its definition and interpretation are 333 outside the scope of this document. The value of the CU bits are 334 ignored by differentiated services-compliant nodes when determining 335 the per-hop behavior to apply to a received packet. 337 The DS field structure is presented below: 339 0 1 2 3 4 5 6 7 340 +---+---+---+---+---+---+---+---+ 341 | DSCP | CU | 342 +---+---+---+---+---+---+---+---+ 344 DSCP: differentiated services codepoint 345 CU: currently unused 347 In a DSCP value notation 'xxxxxx' (where 'x' may equal '0' or '1') 348 used in this document, the left-most bit signifies bit 0 of the DS 349 field (as shown above), and the right-most bit signifies bit 5. 351 Implementors should note that the DSCP field is six bits wide. DS- 352 compliant nodes MUST select PHBs by matching against the entire 6- 353 bit DSCP field, e.g., by treating the value of the field as a table 354 index which is used to select a particular packet handling mechanism 355 which has been implemented in that device. The value of the CU field 356 MUST be ignored by PHB selection. The DSCP field is defined as an 357 unstructured field to facilitate the definition of future per-hop 358 behaviors. 360 With some exceptions noted below, the mapping of codepoints to PHBs 361 MUST be configurable. A DS-compliant node MUST support the logical 362 equivalent of a configurable mapping table from codepoints to PHBs. 363 PHB specifications MUST include a recommended default codepoint, 364 which MUST be unique for codepoints in the standard space (see Sec. 365 6). Implementations should support the recommended codepoint-to-PHB 366 mappings in their default configuration. Operators may choose to use 367 different codepoints for a PHB, either in addition to or in place of 368 the recommended default. Note that if operators do so choose, re- 369 marking of DS fields may be necessary at administrative boundaries 370 even if the same PHBs are implemented on both sides of the boundary. 372 Nichols, et. al. Expires: April 1999 [Page 7] 373 See [ARCH] for further discussion of re-marking. 375 The exceptions to general configurability are for codepoints 'xxx000' 376 and are noted in Secs. 4.2.2 and 4.3. 378 Packets received with an unrecognized codepoint SHOULD be forwarded 379 as if they were marked for the Default behavior (see Sec. 4), and 380 their codepoints should not be changed. Such packets MUST NOT cause 381 the network node to malfunction. 383 The structure of the DS field shown above is incompatible with the 384 existing definition of the IPv4 TOS octet in [RFC791]. 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 that are not isolated 394 by suitably configured boundary nodes 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]. 422 Nichols, et. al. Expires: April 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]. Where a codepoint is 448 not mapped to a standardized or local use PHB, it SHOULD be mapped to 449 the Default PHB. 451 A packet initially marked for the Default behavior MAY be re-marked 452 with another codepoint as it passes a boundary into a DS domain so 453 that it will be forwarded using a different PHB within that domain, 454 possibly subject to some negotiated agreement between the peering 455 domains. 457 4.2 Once and Future IP Precedence Field Use 459 We wish to maintain some form of backward compatibility with present 460 uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet. 461 Routers exist that use the IP Precedence field to select different 462 per-hop forwarding treatments in a similar way to the use proposed 463 here for the DSCP field. Thus, a simple prototype differentiated 464 services architecture can be quickly deployed by appropriately 465 configuring these routers. Further, IP systems today understand the 466 location of the IP Precedence field, and thus if these bits are used 467 in a similar manner as DS-compliant equipment is deployed, 468 significant failures are not likely during early deployment. In 469 other words, strict DS-compliance need not be ubiquitous even within 470 a single service provider's network if bits 0-2 of the DSCP field 471 are employed in a manner similar to, or subsuming, the deployed uses 472 of the IP Precedence field. 474 Nichols, et. al. Expires: April 1999 [Page 9] 475 4.2.1 IP Precedence History and Evolution in Brief 477 The IP Precedence field is something of a forerunner of the DS field. 478 IP Precedence, and the IP Precedence Field, were first defined in 479 [RFC791]. The values that the three-bit IP Precedence Field might 480 take were assigned to various uses, including network control 481 traffic, routing traffic, and various levels of privilege. The least 482 level of privilege was deemed "routine traffic". In [RFC791], the 483 notion of Precedence was defined broadly as "An independent measure 484 of the importance of this datagram." Not all values of the IP 485 Precedence field were assumed to have meaning across boundaries, for 486 instance "The Network Control precedence designation is intended to 487 be used within a network only. The actual use and control of that 488 designation is up to each network." [RFC791] 490 Although early BBN IMPs implemented the Precedence feature, early 491 commercial routers and UNIX IP forwarding code generally did not. As 492 networks became more complex and customer requirements grew, 493 commercial router vendors developed ways to implement various kinds 494 of queueing services including priority queueing, which were 495 generally based on policies encoded in filters in the routers, which 496 examined IP addresses, IP protocol numbers, TCP or UDP ports, and 497 other header fields. IP Precedence was and is among the options such 498 filters can examine. 500 In short, IP Precedence is widely deployed and widely used, if not in 501 exactly the manner intended in [RFC791]. This was recognized in 502 [RFC1122], which states that while the use of the IP Precedence field 503 is valid, the specific assignment of the priorities in [RFC791] were 504 merely historical. 506 4.2.2 Subsuming IP Precedence into Class Selector Codepoints 508 A specification of the packet forwarding treatments selected by the 509 IP Precedence field today would have to be quite general; probably 510 not specific enough to build predictable services from in the 511 differentiated services framework. To preserve partial backwards 512 compatibility with known current uses of the IP Precedence field 513 without sacrificing future flexibility, we have taken the approach of 514 describing minimum requirements on a set of PHBs that are compatible 515 with most of the deployed forwarding treatments selected by the IP 516 Precedence field. In addition, we give a set of codepoints that MUST 517 map to PHBs meeting these minimum requirements. The PHBs mapped to 518 by these codepoints MAY have a more detailed list of specifications 519 in addition to the required ones stated here. Other codepoints MAY 520 map to these same PHBs. We refer to this set of codepoints as the 521 Class Selector Codepoints, and the minimum requirements for PHBs that 522 these codepoints may map to are called the Class Selector PHB 523 Requirements. 525 4.2.2.1 The Class Selector Codepoints 527 A specification of the packet forwarding treatments selected by the 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, under reasonable operating 546 conditions and traffic loads. A discarded packet is considered to be 547 an extreme case of untimely forwarding. In addition, PHBs selected 548 by codepoints '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 Further, PHBs selected by distinct Class Selector Codepoints SHOULD 554 be independently forwarded; that is, packets marked with different 555 Class Selector Codepoints MAY be re-ordered. A network node MAY 556 enforce limits on the amount of the node's resources that can be 557 utilized by each of these PHBs. 559 PHB groups whose specification satisfy these requirements are 560 referred to as Class Selector Compliant PHBs. 562 The Class Selector PHB Requirements on codepoint '000000' are 563 compatible with those listed for the Default PHB in Sec. 4.1. 565 4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence 566 Compatibility 568 A DS-compliant network node can be deployed with a set of one or more 569 Class Selector Compliant PHB groups. This document states that the 570 set of codepoints 'xxx000' MUST map to such a set of PHBs. As it is 571 also possible to map multiple codepoints to the same PHB, the vendor 572 or the network administrator MAY configure the network node to map 573 codepoints to PHBs irrespective of bits 3-5 of the DSCP field to 574 yield a network that is compatible with historical IP Precedence use. 575 Thus, for example, codepoint '011010' would map to the same PHB as 576 codepoint '011000'. 578 4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant 579 PHB Groups 581 Class Selector Compliant PHBs can be realized by a variety of 582 mechanisms, including strict priority queueing, weighted fair 583 queueing (WFQ), WRR, or variants [RPS, HPFQA, DRR], or Class-Based 584 Queuing [CBQ]. The distinction between PHBs and mechanisms is 585 described in more detail in Sec. 5. 587 It is important to note that these mechanisms might be available 588 through other PHBs (standardized or not) that are available in a 589 particular vendor's equipment. For example, future documents may 590 standardize a Strict Priority Queueing PHB group for a set of 591 recommended codepoints. A network administrator might configure 592 those routers to select the Strict Priority Queueing PHBs with 593 codepoints 'xxx000' in conformance with the requirements of this 594 document. 596 As a further example, another vendor might employ a CBQ mechanism in 597 its routers. The CBQ mechanism could be used to implement the Strict 598 Priority Queueing PHBs as well as a set of Class Selector Compliant 599 PHBs with a wider range of features than would be available in a set 600 of PHBs that did no more than meet the minimum Class Selector PHB 601 requirements. 603 4.3 Summary 605 This document defines codepoints 'xxx000' as the Class Selector 606 codepoints, where PHBs selected by these codepoints MUST meet the 607 Class Selector PHB Requirements described in Sec. 4.2.2.2. This is 608 done to preserve a useful level of backward compatibility with 609 current uses of the IP Precedence field in the Internet without 610 unduly limiting future flexibility. In addition, codepoint '000000' 611 is used as the Default PHB value for the Internet and, as such, is 612 not configurable. The remaining seven non-zero Class Selector 613 codepoints are configurable only to the extent that they map to PHBs 614 that meet the requirements in Sec. 4.2.2.2. 616 5. Per-Hop Behavior Standardization Guidelines 618 The behavioral characteristics of a PHB are to be standardized, and 619 not the particular algorithms or the mechanisms used to implement 620 them. A node may have a (possibly large) set of parameters that can 621 be used to control how packets are scheduled onto an output interface 622 (e.g., N separate queues with settable priorities, queue lengths, 623 round-robin weights, drop algorithm, drop preference weights and 624 thresholds, etc). To illustrate the distinction between a PHB and a 625 mechanism, we point out that Class Selector Compliant PHBs might be 626 implemented by several mechanisms, including: strict priority 627 queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in 628 isolation or in combination. 630 PHBs may be specified individually, or as a group (a single PHB is a 631 special case of a PHB group). A PHB group usually consists of a set 632 two or more PHBs that can only be meaningfully specified and 633 implemented simultaneously, due to a common constraint applying to 634 each PHB within the group, such as a queue servicing or queue 635 management policy. A PHB group specification SHOULD describe 636 conditions under which a packet might be re-marked to select another 637 PHB within the group. It is RECOMMENDED that PHB implementations do 638 not introduce any packet re-ordering within a microflow. PHB group 639 specifications MUST identify any possible packet re-ordering 640 implications which may occur for each individual PHB, and which may 641 occur if different packets within a microflow are marked for 642 different PHBs within the group. 644 Only those per-hop behaviors that are not described by an existing 645 PHB standard, and have been implemented, deployed, and shown to be 646 useful, SHOULD be standardized. Since current experience with 647 differentiated services is quite limited, it is premature to 648 hypothesize the exact specification of these per-hop behaviors. 650 Each standardized PHB MUST have an associated RECOMMENDED codepoint, 651 allocated out of a space of 32 codepoints (see Sec. 6). This 652 specification has left room in the codepoint space to allow for 653 evolution, thus the defined space ('xxx000') is intentionally sparse. 655 Network equipment vendors are free to offer whatever parameters and 656 capabilities are deemed useful or marketable. When a particular, 657 standardized PHB is implemented in a node, a vendor MAY use any 658 algorithm that satisfies the definition of the PHB according to the 659 standard. The node's capabilities and its particular configuration 660 determine the different ways that packets can be treated. 662 Service providers are not required to use the same node mechanisms 663 or configurations to enable service differentiation within their 664 networks, and are free to configure the node parameters in whatever 665 way that is appropriate for their service offerings and traffic 666 engineering objectives. Over time certain common per-hop behaviors 667 are likely to evolve (i.e., ones that are particularly useful for 668 implementing end-to-end services) and these MAY be associated with 669 particular EXP/LU PHB codepoints in the DS field, allowing use across 670 domain boundaries (see Sec. 6). These PHBs are candidates for future 671 standardization. 673 It is RECOMMENDED that standardized PHBs be specified in accordance 674 with the guidelines set out in [ARCH]. 676 6. IANA Considerations 678 The DSCP field within the DS field is capable of conveying 64 679 distinct codepoints. The codepoint space is divided into three pools 680 for the purpose of codepoint assignment and management: a pool of 32 681 RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as 682 defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved 683 for experimental or Local Use (EXP/LU) as defined in [CONS], and a 684 pool of 16 codepoints (Pool 3) which are initially available for 685 experimental or local use, but which should be preferentially 686 utilized for standardized assignments if Pool 1 is ever exhausted. 687 The pools are defined in the following table (where 'x' refers to 688 either '0' or '1'): 690 Pool Codepoint space Assignment Policy 691 ---- --------------- ----------------- 693 1 xxxxx0 Standards Action 694 2 xxxx11 EXP/LU 695 3 xxxx01 EXP/LU (*) 697 (*) may be utilized for future Standards Action allocations as 698 necessary 700 This document assigns eight RECOMMENDED codepoints ('xxx000') which 701 are drawn from Pool 1 above. These codepoints MUST be mapped, not to 702 specific PHBs, but to PHBs that meet "at least" the requirements set 703 forth in Sec. 4.2.2.2 to provide a minimal level of backwards 704 compatibility with IP Precedence as defined in [RFC791] and as 705 deployed in some current equipment. 707 7. Security Considerations 709 This section considers security issues raised by the introduction of 710 differentiated services, primarily the potential for denial-of- 711 service attacks, and the related potential for theft of service by 712 unauthorized traffic (Section 7.1). Section 7.2 addresses the 713 operation of differentiated services in the presence of IPsec 714 including its interaction with IPsec tunnel mode and other tunnelling 715 protocols. See [ARCH] for more extensive treatment of the security 716 concerns raised by the overall differentiated services architecture. 718 7.1 Theft and Denial of Service 720 The primary goal of differentiated services is to allow different 721 levels of service to be provided for traffic streams on a common 722 network infrastructure. A variety of techniques may be used to 723 achieve this, but the end result will be that some packets receive 724 different (e.g., better) service than others. The mapping of network 725 traffic to the specific behaviors that result in different (e.g., 726 better or worse) service is indicated primarily by the DS codepoint, 727 and hence an adversary may be able to obtain better service by 728 modifying the codepoint to values indicating behaviors used for 729 enhanced services or by injecting packets with such codepoint values. 730 Taken to its limits, such theft of service becomes a denial-of- 731 service attack when the modified or injected traffic depletes the 732 resources available to forward it and other traffic streams. 734 The defense against this class of theft- and denial-of-service 735 attacks consists of the combination of traffic conditioning at DS 736 domain boundaries with security and integrity of the network 737 infrastructure within a DS domain. DS domain boundary nodes MUST 738 ensure that all traffic entering the domain is marked with codepoint 739 values appropriate to the traffic and the domain, remarking the 740 traffic with new codepoint values if necessary. These DS boundary 741 nodes are the primary line of defense against theft- and denial-of- 742 service attacks based on modified codepoints, as success of any such 743 attack indicates that the codepoints used by the attacking traffic 744 were inappropriate. An important instance of a boundary node is that 745 any traffic-originating node within a DS domain is the initial 746 boundary node for that traffic. Interior nodes in a DS domain rely 747 on DS codepoints to associate traffic with the forwarding PHBs, and 748 are NOT REQUIRED to check codepoint values before using them. As a 749 result, the interior nodes depend on the correct operation of the DS 750 domain boundary nodes to prevent the arrival of traffic with 751 inappropriate codepoints or in excess of provisioned levels that 752 would disrupt operation of the domain. 754 7.2 IPsec and Tunnelling Interactions 756 The IPsec protocol, as defined in [ESP, AH], does not include the IP 757 header's DS field in any of its cryptographic calculations (in the 758 case of tunnel mode, it is the outer IP header's DS field that is not 759 included). Hence modification of the DS field by a network node has 760 no effect on IPsec's end-to-end security, because it cannot cause any 761 IPsec integrity check to fail. As a consequence, IPsec does not 762 provide any defense against an adversary's modification of the DS 763 field (i.e., a man-in-the-middle attack), as the adversary's 764 modification will also have no effect on IPsec's end-to-end security. 766 IPsec's tunnel mode provides security for the encapsulated IP 767 header's DS field. A tunnel mode IPsec packet contains two IP 768 headers: an outer header supplied by the tunnel ingress node and an 769 encapsulated inner header supplied by the original source of the 770 packet. When an IPsec tunnel is hosted (in whole or in part) on a 771 differentiated services network, the intermediate network nodes 772 operate on the DS field in the outer header. At the tunnel egress 773 node, IPsec processing includes removing the outer header and 774 forwarding the packet (if required) using the inner header. The 775 IPsec protocol REQUIRES that the inner header's DS field not be 776 changed by this decapsulation processing to ensure that modifications 777 to the DS field cannot be used to launch theft- or denial-of-service 778 attacks across an IPsec tunnel endpoint. This document makes no 779 change to that requirement. If the inner IP header has not been 780 processed by a DS boundary node for the tunnel egress node's DS 781 domain, the tunnel egress node is the boundary node for traffic 782 exiting the tunnel, and hence MUST ensure that the resulting traffic 783 has appropriate DS codepoints. 785 When IPsec tunnel egress decapsulation processing includes a 786 sufficiently strong cryptographic integrity check of the encapsulated 787 packet (where sufficiency is determined by local security policy), 788 the tunnel egress node can safely assume that the DS field in the 789 inner header has the same value as it had at the tunnel ingress node. 790 An important consequence is that otherwise insecure links within a DS 791 domain can be secured by a sufficiently strong IPsec tunnel. This 792 analysis and its implications apply to any tunnelling protocol that 793 performs integrity checks, but the level of assurance of the inner 794 header's DS field depends on the strength of the integrity check 795 performed by the tunnelling protocol. In the absence of sufficient 796 assurance for a tunnel that may transit nodes outside the current DS 797 domain (or is otherwise vulnerable), the encapsulated packet MUST be 798 treated as if it had arrived at a boundary from outside the DS 799 domain. 801 8. Acknowledgements 803 The authors would like to acknowledge the Differentiated Services 804 Working Group for discussions which helped shape this document. 806 9. References 808 [AH] S. Kent and R. Atkinson, "IP Authentication Header", 809 Internet Draft , 810 July 1998. 812 [ARCH] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and 813 W. Weiss, "An Architecture for Differentiated Services", 814 Internet Draft , 815 October 1998. 817 [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource 818 Management Models for Packet Networks", IEEE/ACM 819 Transactions on Networking, Vol. 3 no. 4, pp. 365-386, 820 August 1995. 822 [CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an 823 IANA Considerations Section in RFCs", Internet Draft 824 , September 1998. 826 [DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing 827 using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995. 829 [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security 830 Payload (ESP)", Internet Draft 831 , July 1998. 833 [HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair 834 Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996. 836 [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 837 (IPv6) Specification", Internet Draft 838 , November 1997. 840 [RFC791] Information Sciences Institute, "Internet Protocol", 841 Internet RFC 791, September 1981. 843 [RFC1122] R. T. Braden, "Requirements for Internet hosts - 844 communication layers", Internet RFC 1122, October 1989. 846 [RFC1812] F. Baker, editor, "Requirements for IP Version 4 847 Routers", Internet RFC 1812, June 1995. 849 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 850 Requirement Levels", Internet RFC 2119, March 1997. 852 [RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: 853 A Design Methodology for Fair Queueing Algorithms", IEEE/ 854 ACM Trans. on Networking, April 1998. 856 Authors' Addresses 858 Kathleen Nichols 859 Cisco Systems 860 170 West Tasman Drive 861 San Jose, CA 95134-1706 862 Phone: +1-408-525-4857 863 E-mail: kmn@cisco.com 865 Steven Blake 866 Torrent Networking Technologies 867 3000 Aerial Center, Suite 140 868 Morrisville, NC 27560 869 Phone: +1-919-468-8466 x232 870 E-mail: slblake@torrentnet.com 872 Fred Baker 873 Cisco Systems 874 519 Lado Drive 875 Santa Barbara, CA 93111 876 Phone: +1-408-526-4257 877 E-mail: fred@cisco.com 878 David L. Black 879 EMC Corporation 880 35 Parkwood Drive 881 Hopkinton, MA 01748 882 Phone: +1-508-435-1000 x76140 883 E-mail: black_david@emc.com 885 Full Copyright Statement 887 Copyright (C) The Internet Society (1998). All Rights Reserved. 889 This document and translations of it may be copied and furnished to 890 others, and derivative works that comment on or otherwise explain it 891 or assist in its implementation may be prepared, copied, published 892 and distributed, in whole or in part, without restriction of any 893 kind, provided that the above copyright notice and this paragraph are 894 included on all such copies and derivative works. However, this 895 document itself may not be modified in any way, such as by removing 896 the copyright notice or references to the Internet Society or other 897 Internet organizations, except as needed for the purpose of 898 developing Internet standards in which case the procedures for 899 copyrights defined in the Internet Standards process must be 900 followed, or as required to translate it into languages other than 901 English. 903 The limited permissions granted above are perpetual and will not be 904 revoked by the Internet Society or its successors or assigns. 906 This document and the information contained herein is provided on an 907 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 908 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 909 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 910 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 911 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.