idnits 2.17.1 draft-ietf-diffserv-header-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 37 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 884 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 15 instances of too long lines in the document, the longest one being 5 characters 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 7 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 75 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 (July 1998) is 9416 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) == Unused Reference: 'ACTIVE' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'CCBES' is defined on line 742, but no explicit reference was found in the text == Unused Reference: '2BIT' is defined on line 773, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2309 (ref. 'ACTIVE') (Obsoleted by RFC 7567) -- 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. 'CCBES' -- 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. '2BIT' Summary: 11 errors (**), 0 flaws (~~), 8 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: January 1999 Steven Blake 4 Torrent Networking Technologies 5 Fred Baker 6 Cisco Systems 7 David L. Black 8 The Open Group 10 July 1998 12 Definition of the Differentiated Services Field (DS Field) 13 in the IPv4 and IPv6 Headers 15 17 Status of This Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 To view the entire list of current Internet-Drafts, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 32 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 33 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 35 Copyright Notice 37 Copyright (C) The Internet Society (1998). All Rights Reserved. 39 Abstract 41 Differentiated services are intended to provide scalable service 42 discrimination in the Internet without the need for per-flow state 43 and signaling at every hop. A variety of services may be built from 44 a small, well-defined set of building blocks which are deployed in 45 network nodes. The services may be either end-to-end or intra- 46 domain. Services can be constructed by a combination of: 48 - setting bits in an IP header field at network boundaries and 49 administrative boundaries, 50 - using those bits to determine how packets are forwarded by the 51 nodes inside the network, and 52 - conditioning the marked packets at network boundaries in accordance 53 with the requirements or rules of each service. 55 The requirements or rules of each service must be set through 56 administrative policy mechanisms which are outside the scope of this 57 document. A differentiated services-compliant network node includes a 58 classifier that selects packets based on the value of the DS field 59 and is capable of delivering the specific packet forwarding treatment 60 indicated by the DS field value. Setting of the DS field and 61 conditioning of the temporal behavior of marked packets need only be 62 performed at network boundaries and may vary in complexity. 64 This document defines the IP header field, called the DS (for 65 differentiated services) field. In IPv4, it defines the layout of 66 the TOS octet; in IPv6, the Traffic Class octet. In addition, a base 67 set of packet forwarding treatments, or per-hop behaviors, is 68 defined. 70 For a more complete understanding of differentiated services, see 71 also the differentiated services architecture [ARCH]. 73 1. Introduction 75 Differentiated services are intended to provide a framework and 76 building blocks to enable deployment of scalable service 77 discrimination in the Internet. The differentiated services approach 78 aims to speed deployment by separating the architecture into two 79 major components, one of which is fairly well-understood and the 80 other of which is just beginning to be understood. In this, we are 81 guided by the original design of the Internet where the decision was 82 made to separate the forwarding and routing components. Packet 83 forwarding is the relatively simple task that needs to be done on a 84 per-packet basis as quickly as possible. Forwarding uses the packet 85 header to find an entry in a routing table that determines the 86 packet's output interface. Routing sets the entries in that table 87 and may need to reflect a range of transit and other policies as well 88 as to keep track of route failures. Routing tables are maintained as 89 a background process to the forwarding task. Further, routing is the 90 more complex task and it has continued to evolve over the past 20 91 years. 93 Analogously, the differentiated services architecture contains two 94 main components. One is the fairly well-understood behavior in the 95 forwarding path and the other is the more complex and still emerging 96 background policy and allocation component that configures parameters 97 used in the forwarding path. The forwarding path behaviors include 98 the differential treatment an individual packet receives, as 99 implemented by queueing service disciplines and/or queue management 100 disciplines. These per-hop behaviors are useful and required in 101 network nodes to deliver differentiated treatment of packets no 102 matter how we construct end-to-end or intra-domain services. These 103 behaviors and the mechanisms to select them on a per-packet basis can 104 be deployed in network nodes today and it is this aspect of the 105 differentiated services architecture that is being addressed first. 106 In addition, the forwarding path may require that some monitoring, 107 policing, and shaping be done on the network traffic designated for 108 "special" treatment in order to enforce requirements associated with 109 the delivery of the special treatment. Mechanisms for this kind of 110 traffic conditioning are also fairly well-understood. The wide 111 deployment of such traffic conditioners is also important to enable 112 the construction of services, though their actual use in constructing 113 services may evolve over time. 115 The configuration of network elements with respect to which packets 116 get special treatment and what kinds of rules are to be applied to 117 the use of resources is much less well-understood. Nevertheless, 118 it is possible to deploy useful differentiated services in networks 119 by using simple policies and static configurations. As described in 120 [ARCH], there are a number of ways to compose per-hop behaviors and 121 traffic conditioners to create services. In the process, additional 122 experience is gained that will guide more complex policies and 123 allocations. The basic behaviors in the forwarding path can remain 124 the same while this component of the architecture evolves. 125 Experiences with the construction of such services will continue for 126 some time, thus we avoid standardizing this construction as 127 premature. Further, much of the details of service construction are 128 covered by legal agreements between different business entities and 129 we avoid this as very much outside the scope of the IETF. 131 This document concentrates on the forwarding path component. In the 132 packet forwarding path, differentiated services are realized by 133 mapping the codepoint contained in a field in the IP packet header to 134 a particular forwarding treatment, or per-hop behavior (PHB), at each 135 network node along its path. The codepoints may be chosen from a set 136 of recommended values or may have purely local meaning. PHBs are 137 expected to be implemented by employing a range of queue service and/ 138 or queue management disciplines on a network node's output interface 139 queue, for example weighted round-robin queue servicing or drop- 140 preference queue management. 142 Marking is performed by traffic conditioners at network boundaries, 143 including the edges of the network (first hop router or source host) 144 and administrative boundaries. Traffic conditioners may include the 145 primitives of marking, metering, policing and shaping (these 146 mechanisms are described in [ARCH]). Services are realized by the 147 use of particular packet classification and traffic conditioning 148 mechanisms at boundaries coupled with the concatenation of per-hop 149 behaviors along the transit path of the traffic. A goal of the 150 differentiated services architecture is to specify these building 151 blocks for future extensibility, both of the number and type of the 152 building blocks and of the services built from them. 154 Terminology used in this draft is defined in Sec. 2. The 155 differentiated services field definition (DS field) is given in Sec. 156 3. In Sec. 4, we discuss the desire for partial backwards 157 compatibility with current use of the IP precedence field. As a 158 solution, we introduce Class Selector codepoints and Class Selector 159 Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior 160 standardization. Sec. 6 discusses guidelines for allocation of 161 codepoints. Sec. 7 covers security considerations. We present 162 examples of class selector compliant PHB implementations in the 163 Appendix. 165 This document is a concise description of the DS field and its uses. 166 It is intended to be read along with the differentiated services 167 architecture [ARCH]. 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 2. Terminology Used in This Document 175 Behavior aggregate: a collection of packets with the same codepoint 176 crossing a boundary in a particular direction. The terms "aggregate" 177 and "behavior aggregate" are used interchangeably in this document. 179 Boundary: the edge of a DS domain, where classifiers and traffic 180 conditioners are likely to be deployed. A boundary can be further 181 sub-divided into ingress and egress nodes, where the ingress/egress 182 nodes are the downstream/upstream nodes of a boundary link in a given 183 traffic direction. A boundary typically is found at the ingress to 184 the first-hop differentiated services-compliant router (or network 185 node) a host's packets traverse, or at the egress of the last-hop 186 differentiated services-compliant router or network node packets 187 traverse before arriving at a host. This is sometimes referred to as 188 the boundary at a leaf router. A boundary might be co-located with a 189 host, subject to local policy. 191 Classifier: an entity which selects packets based on the content of 192 packet headers according to defined rules. 194 Codepoint: a specific value of the DSCP portion of the DS field. 195 Recommended codepoints SHOULD map to specific, standardized PHBs. 196 Multiple codepoints MAY map to the same PHB. 198 Differentiated Service-compliant: in compliance with the requirements 199 specified in this document. 201 Differentiated Services domain: a contiguous portion of the Internet 202 over which a consistent set of differentiated services policies are 203 administered in a coordinated fashion. A differentiated services 204 domain can represent different administrative domains or autonomous 205 systems, different trust regions, different network technologies 206 (e.g., cell/ frame), hosts and routers, etc. Also DS domain. 208 Differentiated Services field: the IPv4 header TOS octet or the 209 IPv6 Traffic Class octet when interpreted in conformance with the 210 definition given in this document. Also DS field. 212 Mechanism: The implementation of a per-hop behavior according to a 213 particular algorithm. 215 Microflow: a single instance of an application-to-application flow of 216 packets which is identified by source address, source port, 217 destination address, destination port and protocol id. 219 Per-hop Behavior (PHB): a description of the externally observable 220 forwarding treatment applied at a differentiated services-compliant 221 node to a behavior aggregate. The description of a PHB should 222 be sufficiently detailed to allow the construction of predictable 223 services. 225 Traffic conditioning: control functions that can be applied to a 226 behavior aggregate, application flow, or other operationally useful 227 subset of traffic, e.g., routing updates. These may include 228 metering, policing, shaping, and packet marking. Traffic 229 conditioning is used to enforce service level agreements between 230 domains and to condition traffic to receive a differentiated service 231 within a domain by marking packets with the appropriate codepoint in 232 the DS field and by monitoring and altering the temporal 233 characteristics of the aggregate where necessary. 235 Traffic conditioner: an entity which performs traffic conditioning 236 functions and which may contain meters, policers, shapers, and 237 markers. Traffic conditioners are typically deployed in boundary 238 nodes only. 240 Service: a description of the overall treatment of a customer's 241 traffic within a particular domain, within a set of interconnected 242 DS domains, or end-to-end. Service descriptions are covered by 243 administrative policy and services are constructed by applying 244 traffic conditioning to create behavior aggregates which experience a 245 known PHB at each hop within the DS domain. Multiple services can be 246 supported by a single per-hop behavior used in concert with a range 247 of traffic conditioners. 249 To summarize, classifiers and traffic conditioners are used to select 250 which packets are to be added to behavior aggregates. Aggregates receive 251 differentiated treatment in a domain and may alter the temporal 252 characteristics of the aggregate to conform to some requirements. A 253 packet's DS field is used to designate the packet's behavior 254 aggregate and is subsequently used to determine which forwarding 255 treatment the packet receives. A DS field classifier which can 256 select a differential output queue servicing discipline (or PHB) 257 based on the codepoint in the DS field SHOULD be in all network 258 nodes of a differentiated services domain. The classifiers 259 and traffic conditioners are configured in accordance with some 260 service specification, a matter of administrative policy outside the 261 scope of this document. 263 Additional differentiated services definitions are in [ARCH]. 265 3. Differentiated Services Field Definition 267 A new header field, called the DS field, is defined, which is 268 intended to supersede the existing definitions of the IPv4 TOS octet 269 [RFC791] and the IPv6 Traffic Class octet [IPv6]. 271 Six bits of the DS field are used as a codepoint (DSCP) to select the 272 PHB a packet experiences at each node. A two-bit currently unused 273 (CU) field is reserved and may be assigned later, e.g., for explicit 274 congestion notification. The value of the CU bits MUST be 275 ignored by differentiated services-compliant nodes when determining 276 the per-hop behavior to apply to a received packet. 278 The DS field structure is presented below: 280 0 1 2 3 4 5 6 7 281 +---+---+---+---+---+---+---+---+ 282 | DSCP | CU | 283 +---+---+---+---+---+---+---+---+ 285 DSCP: differentiated services codepoint 286 CU: currently unused 288 Implementors should note that the DSCP field is six bits wide. DS- 289 compliant nodes MUST select PHBs by matching against the entire 6- 290 bit DSCP field, e.g., by treating the value of the field as a table 291 index which is used to select a particular packet handling mechanism 292 which has been implemented in that device. The DSCP field is defined 293 as an unstructured field to facilitate the definition of future per- 294 hop behaviors. 296 With some exceptions noted below, the mapping of codepoints to PHBs 297 MUST be configurable. A DS-compliant node MUST support the logical 298 equivalent of a configurable mapping table from codepoints to PHBs. 299 PHB specifications MUST include a recommended default codepoint, but 300 operators MAY choose to use different codepoints, either in addition 301 to or in place of the recommended default. Note that if operators do 302 so choose, re-marking of DS fields will be necessary at 303 administrative boundaries even if the same PHBs are implemented on 304 both sides of the boundary. See [ARCH] for further discussion of re- 305 marking. The recommended default codepoint for a PHB must be unique 306 for codepoints in the standard space (see Sec. 6). 308 The exceptions to configurability are for codepoints 'xxx000' and are 309 noted in Sec. 4. 311 Packets received with an unrecognized codepoint SHOULD be forwarded 312 as if they were marked for the Default behavior (see Sec. 4). Such 313 packets MUST NOT cause the network node to crash. 315 The structure of the DS field shown above is incompatible with the 316 existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The 317 presumption is that differentiated services domains protect 318 themselves by deploying re-marking boundary nodes, as should networks 319 using the RFC 791 Precedence designations. Correct operational 320 procedure should follow [RFC791], which states: "If the actual use of 321 these precedence designations is of concern to a particular network, 322 it is the responsibility of that network to control the access to, 323 and use of, those precedence designations." Validating the value of 324 the DS field at network boundaries is sensible in any case since an 325 upstream node can easily set it to any random value. Differentiated 326 services domains which are not suitably isolated by a re-marking 327 boundary node may deliver unpredictable service. 329 Nodes MAY rewrite the DS field as needed to provide a desired local 330 or end-to-end service. Specifications of DS field translations at 331 network boundaries are the subject of Service Level Agreements 332 between providers and users, and are outside the scope of this 333 document. Standardized PHBs allow providers to build their services 334 from a well-known set of packet forwarding treatments that can be 335 expected to be present in the equipment of many vendors. 337 4. Historical Codepoint Definitions and PHB Requirements 339 The DS field will have a limited backwards compatibility with current 340 practice, described in this section. Backwards compatibility is 341 addressed in two ways. First, per-hop behaviors that are 342 already in widespread use MUST be included in a DS-compliant 343 node. In addition, there are some codepoints that correspond to 344 historical use of the IP Precedence field and we reserve these 345 codepoints to map to PHBs that meet the general requirements 346 specified in [RFC791], though the specific differentiated services 347 PHBs mapped to by those codepoints MAY have additional 348 specifications. 350 4.1 A Default PHB 352 A "default" PHB MUST be available in a DS-compliant node. This is 353 the common, best-effort forwarding behavior available in existing 354 routers as standardized in [RFC1812]. When no other agreements are 355 in place, it is assumed that packets belong to this aggregate. Such 356 packets may be sent into a network without adhering to any particular 357 rules and the network will deliver as many of these packets as 358 possible and as soon as possible, subject to other resource policy 359 constraints. A reasonable implementation of this PHB would be a 360 queueing discipline that sends packets of this aggregate whenever the 361 output link is not required to satisfy another PHB. A reasonable 362 policy for constructing services would ensure that the aggregate was 363 not "starved" or else the network provider might become quite 364 unpopular. This permits senders that are not differentiated 365 services-aware to continue to use the network in the same manner as 366 today and to have the same kinds of expectations from the network 367 regarding service. The RECOMMENDED codpoint for the Default PHB is 368 the bit pattern '000000'; the value '000000' MUST map to a PHB that 369 meets these specifications. The codepoint chosen for Default 370 behavior is compatible with existing practice [RFC791, RFC1349]. 372 A packet initially marked for the Default behavior MAY be re-marked 373 with another codepoint as it passes a boundary into another DS domain 374 so that it will be forwarded using a different PHB within the domain, 375 possibly subject to some negotiated agreement between the peering 376 domains. 378 4.2 Once and Future IP Precedence Field Use 380 We wish to maintain some form of backward compatibility with present 381 uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet. 382 Routers exist that use the IP Precedence field to select different 383 per-hop forwarding treatments quite similarly to the use proposed 384 here for the DSCP field. Thus, a simple prototype diffserv 385 architecture can be quickly deployed by appropriately configuring 386 these routers. Further, IP systems today understand the location of 387 the IP Precedence field, and thus if these bits are used in a similar 388 manner as DS-compliant equipment is deployed, significant failures 389 are not likely during early deployment. In other words, strict DS- 390 compliance need not be ubiquitous even within a single service 391 provider's network if bits 0-2 of the DSCP field are employed in a 392 manner similar to, or subsuming, the deployed uses of the IP 393 Precedence field. 395 4.2.1 IP Precedence History and Evolution in Brief 397 The IP Precedence field is something of a forerunner of the DS field. 398 IP Precedence, and the IP Precedence Field, were first defined in 399 [RFC791]. The values that the three-bit IP Precedence Field might 400 take were assigned to various uses, including network control 401 traffic, routing traffic, and various levels of privilege. The least 402 level of privilege was deemed "routine traffic". In [RFC791], the 403 notion of Precedence was defined broadly as " An independent measure 404 of the importance of this datagram." Not all values of the IP 405 Precedence field were assumed to have meaning across boundaries, for 406 instance "The Network Control precedence designation is intended to 407 be used within a network only. The actual use and control of that 408 designation is up to each network." [RFC791] 410 Although early BBN IMPs implemented the service, early commercial 411 routers and UNIX IP forwarding code generally did not. As networks 412 became more complex and customer requirements grew, commercial 413 routers developed ways to implement various kinds of queueing 414 services including priority queueing, which were generally based on 415 policies encoded in filters in the routers, which looked at IP 416 addresses, IP protocol numbers, TCP or UDP ports, and other header 417 fields. IP Precedence was and is among the options such filters can 418 look at. 420 In short, IP Precedence is widely deployed and widely used, if not in 421 exactly the manner intended in [RFC791]. This was recognized in 422 [RFC1122], which states that while the use of the IP Precedence field 423 is valid, the specific assignment of the priorities in [RFC791] were 424 merely historical. 426 4.2.2 Subsuming IP Precedence into Class Selector Codepoints 428 A specification of the packet forwarding treatments selected by the 429 IP precedence field today would have to be quite general; probably 430 not specific enough to build predictable services from in the 431 differentiated services framework. To preserve partial backwards 432 compatibility with known current uses of the IP Precedence field 433 without sacrificing future flexibility, we have taken the approach of 434 describing minimum requirements on a set of PHBs that are compatible 435 with most of the existing forwarding treatments selected by the IP 436 Precedence field. In addition, we give a set of codepoints that MUST 437 map to PHBs meeting minimum requirements. The PHBs mapped to by 438 these codepoints MAY have a more detailed list of specifications in 439 addition to the required ones stated here. Other codepoints MAY map 440 to the same PHBs. We refer to this set of codepoints as the Class 441 Selector codepoints and the minimum requirements for PHBs that these 442 codepoints may map to are called the Class Selector PHB requirements. 444 4.2.2.1 The Class Selector Codepoints 446 The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU 447 subfield unspecified are reserved as a set of Class Selector Codepoints. 448 PHBs which are mapped to by these codepoints MUST meet the Class 449 Selector PHB requirements in addition to preserving the Default PHB 450 requirement on codepoint '000000'. 452 4.2.2.2 The Class Selector PHB Requirements 454 We refer to a Class Selector codepoint with a larger numerical value 455 than another Class Selector codepoint as having a higher relative 456 order while a Class Selector codepoint with a smaller numerical value 457 than another Class Selector codepoint is said to have a lower 458 relative order. PHBs selected by a Class Selector codepoint SHOULD 459 give packets a probability of timely forwarding that is not lower 460 than that given to packets marked with a Class Selector codepoint of 461 lower relative order. Although a particular packet marked with a 462 lower relative order Class Selector codepoint might be observed to be 463 forwarded earlier than a particular packet marked with a higher 464 relative order, sample observations that take place over a reasonable 465 period of network history will conform to this requirement. A 466 discarded packet is considered to be an extreme case of untimely 467 forwarding. 469 Further, PHBs selected by distinct Class Selector codepoints SHOULD 470 be independently forwarded; that is, packets marked with different 471 Class Selector codepoints MAY be reordered. A network node MAY have 472 limits on the amount of the node's resources that can be used by each 473 of these PHBs. 475 PHB groups whose specification meets these requirements are referred 476 to as Class Selector Compliant PHBs. 478 It is easy to see that the Class Selector PHB Requirements on 479 codepoint '000000' are compatible with those listed in Sec. 4.1 480 for the Default PHB. 482 4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence 483 Compatibility 485 A DS-compliant network node can be deployed with a set of one or more 486 Class Selector Compliant PHB groups. This document states that the 487 set of codepoints 'xxx000' MUST map to such a set of PHBs. As it is 488 also possible to map multiple codepoints to the same PHB, the vendor 489 or the network administrator might configure the network node to map 490 codepoints to PHBs irrespective of bits 3-5 of the DSCP field to 491 yield a network that is compatible with historical IP Precedence use. 492 Thus, for example, codepoint '011010' would map to the same PHB as 493 codepoint '011000'. 495 4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant 496 PHB Groups 498 Class Selector Compliant PHBs can be realized by a variety of 499 mechanisms, including strict priority queueing, WFQ or variants 500 [HPFQA], weighted round-robin queueing (WRR), or Class-Based Queuing 501 [CBQ]. The distinction between PHBs and mechanisms is described in 502 more detail in Sec. 5. 504 It is important to note that these mechanisms might be available 505 through other PHBs (standardized or not) that are available in a 506 particular vendor's equipment. For example, future documents may 507 standardize a Strict Priority Queueing PHB for a set of recommended 508 codepoints. A network administrator might configure those routers to 509 select the Strict Priority Queueing PHBs with codepoints 'xxx000' in 510 conformance with the requirements of this document. 512 As a further example, another vendor might employ a CBQ mechanism in 513 its routers. The CBQ mechanism could be used to implement the Strict 514 Priority Queueing PHBs as well as a set of Class Selector Compliant 515 PHBs with a wider range of features than would be availble in a set 516 of PHBs that did no more than meet the minimum Class Selector PHB 517 requirements. More examples are given in the Appendix. 519 4.3 Summary 521 This document defines codepoints 'xxx000' as the Class Selector 522 codepoints, where PHBs selected by these codepoints must meet the 523 Class Selector PHB Requirements described in Sec. 4.2.2.2. This is 524 done to preserve a useful level of backward compatibility with 525 current uses of the IP Precedence field in the Internet without 526 unduly limiting future flexibility. In addition, codepoint '000000' 527 is used as the Default PHB value for the Internet and, as such, is 528 not configurable. The remaining seven non-zero Class Selector 529 codepoints are configurable only to the extent that they map to PHBs 530 that meet the requirements in Sec. 4.2.2.2. 532 5. Per-Hop Behavior Standardization Guidelines 534 Thirty-two DS codepoints are reserved for standardization as 535 RECOMMENDED codepoints, and 32 codepoints are reserved for 536 experimental or local use (EXP/LU) (see Sec. 6 for further details). 538 Codepoint space Usage Policy 539 --------------- ------------ 541 xxxxx0 Reserved for RECOMMENDED codepoints 542 xxxxx1 EXP/LU 544 The behavioral characteristics of a PHB are to be standardized, and 545 not the algorithms or the mechanisms used to implement them. A 546 node may have a (possibly large) set of parameters that can be used 547 to control how packets are scheduled onto an output interface (e.g., 548 N separate queues with settable priorities, queue lengths, round- 549 robin weights, drop algorithm, drop preference weights and 550 thresholds, etc). To illustrate the distinction between a PHB and a 551 mechanism, we point out that Class Selector Compliant PHBs might be 552 implemented by several mechanisms, including: strict priority 553 queueing combined with WFQ or variants [HPFQA], weighted round-robin 554 queueing, or CBQ [CBQ]. 556 It is RECOMMENDED that PHB implementations do not introduce any 557 packet reordering within a microflow. Where PHBs are defined as a 558 group, their definitions MUST specify any possible packet re-ordering 559 implications which may occur if different packets within a microflow 560 are marked for different PHBs within the group. 562 Network equipment vendors are free to offer whatever parameters and 563 capabilities are deemed useful or marketable. When a particular, 564 standardized PHB is implemented in a node, a vendor may use any 565 algorithm that satisfies the definition of the PHB according to the 566 standard. The node's capabilities and its particular configuration 567 determine the different ways that packets can be treated. 569 Service providers are not required to use the same node mechanisms 570 or configurations to enable service differentiation within their 571 networks, and are free to configure the node parameters in whatever 572 way that is appropriate for their service offerings and traffic 573 engineering objectives. Over time certain common per-hop behaviors 574 are likely to evolve (i.e., ones that are particularly useful for 575 implementing end-to-end services) and these may be associated with 576 particular EXP/LU PHB codepoints in the DS field, allowing use across 577 domain boundaries (see Sec. 6). These PHBs are candidates for future 578 standardization. 580 Only those per-hop behaviors that are not described by an existing 581 PHB standard, and have been implemented, deployed, and shown to be 582 useful, should be standardized. Since current experience with 583 differentiated services is quite limited, it is premature to 584 hypothesize the exact specification of these per-hop behaviors. This 585 specification has left room in the codepoint space to allow for 586 evolution, thus the defined space is intentionally sparse. 588 6. IANA Considerations 590 The DSCP field in the DS field is capable of conveying 64 distinct 591 codepoints. The codepoint space is divided into three pools for the 592 purpose of codepoint assignment and management: a pool of 32 593 RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as 594 defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved for 595 experimental or Local Use (EXP/LU) as defined in [CONS], and a pool 596 of 16 codepoints (Pool 3) which are initially available for 597 experimental or local use, but which should be preferentially 598 utilized for standardized assignments if Pool 1 is ever exhausted. 599 The pools are defined in the following table (where 'x' refers to 600 either '0' or '1'): 602 Pool Codepoint space Assignment Policy 603 ---- --------------- ----------------- 605 1 xxxxx0 Standards Action 606 2 xxxx11 EXP/LU 607 3 xxxx01 EXP/LU (*) 609 (*) may be utilized for future Standards Action allocations as 610 necessary 612 This document defines the assignment of eight codepoints (xxx000) 613 which are drawn from Pool 1 above. These codepoints MUST be 614 mapped, not to specific PHBs, but to PHBs that meet "at least" the 615 requirements set out in Sec. 4.2.2.2 to provide a minimal level of 616 backwards compatibility with IP Precedence as defined in [RFC791] and 617 as deployed in some current equipment. 619 7. Security Considerations 621 This section considers security issues raised by the introduction of 622 differentiated services, primarily the potential for denial-of- 623 service attacks, and the related potential for theft of service by 624 unauthorized traffic (Section 7.1). Section 7.2 addresses the operation 625 of differentiated services in the presence of IPsec including its 626 interaction with IPsec tunnel mode and other tunnelling protocols. 627 More extensive treatment of the security concerns raised by the overall 628 differentiated services architecture are discussed in [ARCH]. 630 7.1 Theft and Denial of Service 632 The primary goal of differentiated services is to allow different 633 levels of service to be provided for traffic streams on a common 634 network infrastructure. A variety of techniques may be used to 635 achieve this, but the end result will be that some packets receive 636 different (e.g., better) service than others. The mapping of network 637 traffic to the specific behaviors that result in different (e.g., 638 better or worse) service is indicated primarily by the DS codepoint, 639 and hence an adversary may be able to obtain better service by 640 modifying the codepoint to values indicating behaviors used for 641 enhanced services or by injecting packets with such codepoint values. 642 Taken to its limits, such theft of service becomes a denial-of-service 643 attack when the modified or injected traffic depletes the resources 644 available to forward it and other traffic streams. 646 The defense against this class of theft- and denial-of-service attacks 647 consists of the combination of traffic conditioning at network boundaries 648 with security and integrity of the network infrastructure within a 649 DS domain. Network boundary nodes MUST ensure that all traffic entering 650 the domain has codepoint values appropriate to the traffic and the domain, 651 remarking the traffic with new codepoint values if necessary. 652 These boundary nodes are the primary line of defense against theft- 653 and denial-of-service attacks based on modified codepoints, as 654 success of any such attack indicates that the codepoints used 655 by the attacking traffic were inappropriate. An important instance of a 656 boundary node is that any traffic-originating node in a DS domain 657 is the initial boundary node for that traffic. Interior nodes 658 in a DS domain rely on DS codepoints to associate traffic with the 659 forwarding PHBs, and are not required to check codepoint values before 660 using them. As a result, the interior nodes depend on the correct 661 operation of the DS domain to prevent the arrival of traffic with 662 inappropriate codepoints that would disrupt operation of the domain. 664 7.2 IPsec and Tunnelling Interactions 666 The IPsec protocol, as defined in [ESP,AH], does not include the IP 667 header's DS field in any of its cryptographic calculations (in the 668 case of tunnel mode, it is the outer IP header's DS field that is not 669 included). Hence modification of the DS field by a network node has 670 no effect on IPsec's end-to-end security, because it cannot cause any 671 IPsec integrity check to fail. As a consequence, IPsec does not 672 provide any defense against an adversary's modification of the DS 673 field (i.e., a man-in-the-middle attack), as the adversary's 674 modification will also have no effect on IPsec's end-to-end security. 676 IPsec's tunnel mode provides security for the encapsulated IP 677 header's DS field. A tunnel mode IPsec packet contains two IP 678 headers: an outer header supplied by the tunnel ingress node and an 679 encapsulated inner header supplied by the original source of the 680 packet. When an IPsec tunnel is hosted (in whole or in part) on a 681 differentiated services network, the intermediate network nodes 682 operate on the DS field in the outer header. At the tunnel egress 683 node, IPsec processing includes removing the outer header and 684 forwarding the packet (if required) using the inner header. 685 The IPsec protocol REQUIRES that the inner header's DS field not 686 be changed by this decapsulation processing to ensure that modifications 687 to the DS field cannot be used to launch theft- or denial-of-service 688 attacks across an IPsec tunnel endpoint. This document makes no 689 change to that requirement. If the inner IP header has not been 690 processed by a boundary node for the tunnel egress node's DS domain, 691 the tunnel egress node is the boundary node for traffic exiting the 692 tunnel, and hence MUST ensure that the resulting traffic has 693 appropriate DS codepoints. 695 When IPsec tunnel egress decapsulation processing includes a 696 sufficiently strong cryptographic integrity check of the encapsulated 697 packet (where sufficiency is determined by local security policy), the 698 tunnel egress node can safely assume that the DS field in the inner 699 header has the same value as it had at the tunnel ingress node. 700 An important consequence is that otherwise insecure links 701 within a DS domain can be secured by a sufficiently strong 702 IPsec tunnel. This analysis and its implications apply to any 703 tunneling protocol that performs integrity checks, but the level 704 of assurance of the inner header's DS field depends on the strength 705 of the integrity check performed by the tunneling protocol. In 706 the absence of sufficient assurance for a tunnel that may transit 707 nodes outside the current DS domain (or is otherwise vulnerable), 708 the encapsulated packet MUST be treated as if it had arrived at a 709 boundary from outside the DS domain. 711 8. Acknowledgements 713 The authors would like to acknowledge the Differentiated Services 714 Working Group for discussions which helped shape this document. 716 9. References 718 [ACTIVE] B. Braden, et. al., "Recommendations on Queue Management 719 and Congestion Avoidance in the Internet", Internet RFC 720 2309, April 1998. 722 [AH] S. Kent and R. Atkinson, "IP Authentication Header", 723 Internet Draft , 724 July 1998. 726 [ARCH] Differentiated Services Architecture Document (work in 727 preparation). 729 [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource 730 Management Models for Packet Networks", IEEE/ACM 731 Transactions on Networking, Vol. 3 no. 4, pp. 365-386, 732 August 1995. 734 [CLARK] D. Clark and W. Fang, "Explicit Allocation of Best 735 Effort Packet Delivery Service", 736 http://diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf 738 [CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an 739 IANA Considerations Section in RFCs", Internet Draft 740 , March 1998. 742 [CCBES] C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang, 743 "Congestion Control for Best-Effort Service: Why We Need 744 a New Paradigm", IEEE Network, Vol. 10, no. 1, January 745 1996. 747 [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security 748 Payload (ESP)", Internet Draft 749 , July 1998. 751 [HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair 752 Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996. 754 [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 755 (IPv6) Specification", Internet Draft 756 , November 1997. 758 [RFC791] Information Sciences Institute, "Internet Protocol", 759 Internet RFC 791, September 1981. 761 [RFC1122] RFC 1122, "Requirements for Internet hosts - 762 communication layers". R.T. Braden. Oct-01-1989. 764 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol 765 Suite", Internet RFC 1349, July 1992. 767 [RFC1812] F. Baker, editor, "Requirements for IP Version 4 768 Routers", Internet RFC 1812, June 1995. 770 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 771 Requirement Levels", Internet RFC 2119, March 1997. 773 [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit 774 Differentiated Services Architecture for the Internet", 775 ftp://ftp.ee.lbl.gov/papers/dsarch.pdf. 777 Appendix. Examples of Class Selector Compliant PHB Implementations 779 This appendix shows how three different mechanisms can be used to 780 implement Class Selector Compliant PHBs. 782 A.1 Priority Queues 784 This approach employs eight queues where each of the eight codepoints 785 maps to a different queue. Queues are ranked in priority order so 786 that each queue, from the perspective of the next lower priority 787 queue, implements a "low loss, low delay" forwarding behavior. As an 788 alternative, one can employ four queues, where bits 0 and 1 of the 789 codepoint are used to select the queue. Bit 2 of the codepoint is 790 used as a drop preference within the queue. RED is used within the 791 queues according to its usual parameters, but with in-profile traffic 792 having a higher min-threshold and max-threshold than out-of-profile 793 traffic, and therefore experiencing a higher probability of timely 794 delivery. Out-of-profile traffic should consider the presence of 795 lower order in-profile traffic in the calculation of drop 796 probability [CLARK]. 798 The strength of this approach is that order is maintained within each 799 precedence queue, but higher ordered traffic may be sent before lower 800 ordered traffic. It has a weakness, however, in that apart from 801 admission control and policing, it affords lower precedence traffic 802 no assurance of eventual transmission. 804 A.2 Round Robin Queuing 806 Like the previous example, this approach employs a queue per 807 codepoint, but each queue is emptied at some non-zero rate, in round- 808 robin order, rather than being given simple priority service. 810 The strength of this approach is that higher ordered traffic is, on 811 average, queued for a shorter duration than lower ordered traffic. 812 It also avoids the lockout issue that priority queuing systems 813 experience. A counter-intuitive scenario can occur, however, if a 814 high rate queue is heavily utilized while a lower rate queue is 815 under-utilized; a packet directed to the lower rate queue can 816 actually be better protected from loss and variation in delay when 817 placed in an empty or very short queue. 819 A.3 Virtual Circuit or Virtual Channel Selection 821 The difference between this approach and Round Robin Queuing is 822 somewhat academic. If one has a serial line to a routing neighbor, 823 and manages the link using a load sharing algorithm, the load sharing 824 algorithm in some sense emulates the way the line would behave if it 825 were in reality a number of different lines, or if it were one 826 channelized line. In a virtual circuit selection model, the 827 emulation becomes reality - one deploys a set of rate-limited VCs to 828 a routing neighbor, and uses them in the same way one would otherwise 829 have used round-robin queues. 831 The strengths and weaknesses are very similar to those of Round Robin 832 Queuing, except that this allows one to capitalize on the 833 capabilities of a link layer such as ATM or Frame Relay. 835 Authors' Addresses 837 Kathleen Nichols 838 Bay Networks Architecture Lab 839 4401 Great America Parkway 840 SC01-04 841 Santa Clara, CA 95052-8185 842 Phone: +1-408-495-3252 843 Fax: +1-408-495-1299 844 E-mail: knichols@baynetworks.com 846 Steven Blake 847 Torrent Networking Technologies (effective 7/15) 848 E-mail: slblake@intercenter.net 850 Fred Baker 851 Cisco Systems 852 519 Lado Drive 853 Santa Barbara, California 93111 854 Phone: (408) 526-4257 855 Email: fred@cisco.com 857 David L. Black 858 The Open Group 859 11 Cambridge Center 860 Cambridge, MA 02142 861 Phone: (617) 621-7347 862 Email: d.black@opengroup.org