INTERNET-DRAFT Kathleen Nichols Diffserv Working Group Bay Networks Architecture Lab Expires: November 1998 Steven Blake IBM Microelectronics May 1998 Definition of the Differentiated Services Field (DS Byte) in the IPv4 and IPv6 Headers Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract Differentiated services are intended to provide scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop. A variety of services may be built from a small, well-defined set of building blocks which are deployed in network nodes. The services may be either end-to-end or intra- domain. Services can be provided by a combination of: - setting bits in an IP header field at network edges and administrative boundaries, - using those bits to determine how packets are forwarded by the routers inside the network, and - conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service. This document defines the IP header field, called the DS (for differentiated services) byte. In IPv4, it takes the place of the TOS octet; in IPv6, it takes the place of the Traffic Class octet. A differentiated services-capable network node includes a classifier Nichols, Blake Expires: November 1998 [Page 1] INTERNET-DRAFT Differentiated Services May 1998 that selects packets based on the value of the DS byte and is capable of delivering the specific packet forwarding treatment corresponding to that value. This document defines two packet forwarding treatments, or per-hop behaviors. Setting of the DS byte and other conditioning of the dynamic behavior of marked packets need only be performed at network boundaries and may vary in complexity. For a more complete understanding of differentiated services, this document should be read along with its companion documents, the differentiated services architecture [ARCH], the differentiated services framework [FWK], and other documents which specify additional per-hop behaviors, such as [Baker]. 1. Introduction The DS byte is used to mark a packet to receive a particular forwarding treatment, or per-hop behavior, on nodes along its path. Marking is performed by traffic conditioners at network boundaries, including the edges of the network (first hop router or source host) and administrative boundaries. Traffic conditioners may include the primitives of classification, marking, policing and shaping (these mechanisms are described in [ARCH]). Services are realized by the use of particular traffic conditioning at boundaries coupled with the concatenation of per-hop behaviors along the transit path of the traffic (services are discussed in [FWK]). A goal of the differentiated services architecture is to specify these building blocks for future extensibility, both of the number and type of the building blocks and of the services built from them. Terminology used in this draft is defined in Sec. 2. The differentiated services byte definition (DS byte) is given in Sec. 3. In Sec. 4, two specific per-hop behaviors are defined. Sec. 5 presents guidelines for per-hop behavior standardization. Sec. 6 discusses guidelines for allocation of per-hop behavior codepoints. Sec. 7 covers security considerations. We present two example services which can be built from these differentiated services primitives in the Appendix. This document is a concise description of the DS byte and its uses. It is intended to be read along with its companion documents, the differentiated services architecture [ARCH], the differentiated services framework [FWK], and other documents which specify additional per-hop behaviors, such as [Baker]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Nichols, Blake Expires: November 1998 [Page 2] INTERNET-DRAFT Differentiated Services May 1998 2. Terminology Used in This Document Behavior aggregate: a collection of packets with the same codepoint crossing a boundary in a particular direction. The terms "aggregate" and "behavior aggregate" are used interchangeably in this document. Boundary: Where two network "clouds" are linked; the "clouds" can represent different administrative domains or autonomous systems, different trust regions, different network technologies (e.g., cell/ frame), hosts and routers, etc. A boundary can be further sub- divided into exit and entry nodes, where the exit/entry nodes are the upstream/downstream nodes of a boundary link in a given traffic direction. Codepoint: a specific value of the PHB field in the DS byte. DS byte: the IPv4 header TOS octet or the IPv6 Traffic Class octet when interpreted in conformance with the definition given in this document. Mechanism: The implementation of a per-hop behavior according to a particular algorithm. Network edge: refers to a particular boundary node, the edge of the differentiated services-compliant area. This typically is at the ingress to the first-hop differentiated services-aware router (or network node) a host's packets traverse, or at the egress of the last-hop differentiated services-aware router or network node packets traverse before arriving at a host. This is sometimes referred to as the boundary at a leaf router. The network edge might be co-located with a host, subject to local policy. Per-hop Behavior: a description of the externally observable forwarding treatment applied at a differentiated services-enabled node to a behavior aggregate. Service: a description of the overall treatment of a customer's traffic within a particular domain or end-to-end. Traffic conditioner: an entity which performs traffic conditioning functions and which may contain header classifiers, meters, policers, shapers, and markers. Traffic conditioners are typically deployed in boundary nodes only. Traffic conditioning: control functions that can be applied to a behavior aggregate, application flow, or other operationally useful subset of traffic, e.g., routing updates. These may include header classification, metering, policing, shaping, and packet marking. Traffic conditioning is used to enforce service level agreements between domains and to condition traffic to receive a differentiated service within a domain. Nichols, Blake Expires: November 1998 [Page 3] INTERNET-DRAFT Differentiated Services May 1998 To summarize, the DS byte is used to designate behaviors. A DS byte classifier and per-hop behaviors based on those classifications are required in all network nodes of a differentiated services-capable network. More extensive traffic conditioners may appear at boundaries. Multiple services can be supported by a single per-hop behavior used in concert with a range of traffic conditioners. 3. Differentiated Services Byte Definition A new header field, called the DS byte, is defined. The DS byte then overrides existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]. Six bits of the DS byte are used to define the per-hop behavior (PHB) a packet experiences. A two-bit currently unused (CU) field is reserved and may be assigned later, e.g., for explicit congestion notification [ECN]. The value of the CU bits MUST be ignored by differentiated services-compliant nodes when determining the per-hop behavior to apply to a received packet. The DS byte structure is presented below: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | PHB | CU | +---+---+---+---+---+---+---+---+ PHB: per-hop behavior CU: currently unused Implementors should note that the PHB field is 6 bits wide. Routers MUST identify PHBs by matching against the entire 6-bit PHB field, e.g., by treating the value or "codepoint" of the PHB field as a table index or a switch/case statement variable which is used to select a particular packet handling mechanism which has been implemented in that device. Although the IANA may assume some structure within the PHB field when assigning values for new per-hop behaviors, we define it as an unstructured field to facilitate the definition of future per-hop behaviors. Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior (see Sec. 4). The structure of the DS byte shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The presumption is that differentiated services-aware networks protect themselves by deploying re-marking boundary nodes, as should networks using the RFC 791 Precedence designations. Correct operational procedure should follow [RFC791], which states: "If the actual use of Nichols, Blake Expires: November 1998 [Page 4] INTERNET-DRAFT Differentiated Services May 1998 these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." Validating the value of the DS byte at network boundaries is sensible in any case since an upstream node can easily set it to any random value. Differentiated services-enabled networks which are not suitably isolated by a re-marking boundary node may deliver unpredictable service. A companion document [Baker] describes how a minimal necessary amount of compatibility with RFC 791 Precedence can be maintained under use of the DS byte. 4. Initial Per-Hop Behavior Definitions Two per-hop behaviors are already in widespread use and we propose them for standardization: Default (DE) is the common, best-effort forwarding behavior available in existing routers and is already standardized in [RFC1812]. Expedited Forwarding (EF) is a "high priority" forwarding behavior such as might be used for delay sensitive traffic such as audio and video. The codepoints for these two behaviors are shown below: Codepoint Behavior name --------- ------------- 000000 Default (DE) 000010 Expedited Forwarding (EF) and the behaviors are defined as follows: Default: a DE-marked packet is queued for an outgoing interface according to the availability of buffer resources and according to any active queue management policy that may be implemented [ACTIVE]. It is not required that all arriving packets are seen at the output, but it is RECOMMENDED that the aggregate of packets with this marking not be completely starved. Forwarding requirements are as soon as possible, and the corresponding output bandwidth requirements are as much as possible, subject to the other constraints of the router's scheduling and buffer management sub-systems [CCBES]. The Default behavior is intended to closely approximate the best-effort behavior of existing routers. The codepoint chosen for Default behavior is compatible with existing practice [RFC791, RFC1349]. A packet originating from a node and marked for the Default behavior may be re-marked with another PHB codepoint at a downstream network boundary to enable preferential forwarding within that network, possibly subject to some negotiated agreement. Expedited Forwarding: for traffic levels of EF-marked packets which are a small fraction of the link rate of an outgoing interface, the Nichols, Blake Expires: November 1998 [Page 5] INTERNET-DRAFT Differentiated Services May 1998 implementation of Expedited Forwarding should exhibit the following behavioral characteristics: low absolute delay, low delay variation, and extremely low loss, irrespective of the rate of non-EF-marked traffic which is forwarded through that same outgoing interface. The delay and loss characteristics should be similar to that observed by a single packet traversing an otherwise idle router, and should not vary significantly as the rate of non-EF-marked traffic is increased. The maximum rate of EF-marked traffic which can be forwarded on an outgoing link while satisfying the desired behavioral characteristics is implementation-dependent. The Expedited Forwarding behavior can be realized by a variety of mechanisms, including strict priority queueing, WFQ or variants [HPFQA], weighted round-robin queueing with a large weight for the EF queue, or CBQ [CBQ]. The Expedited Forwarding behavior may be used to implement services requiring low delay and low jitter. Service guarantees for this class of traffic SHOULD depend on conformance to some rate and burstiness constraints which are enforced by traffic conditioners at network boundaries, possibly subject to some negotiated agreement. EF-marked aggregates which are in excess of these constraints may have some or all of their packets delayed (by a shaper) or discarded. Note that conforming implementations will commonly employ separate scheduler queues for DE- and EF-marked packets. Thus it should be expected that packet streams which include both DE- and EF-marked packets may suffer packet reordering when traversing a conforming router. 5. Per-Hop Behavior Standardization Guidelines Thirty-two PHB codepoints are reserved for standardization, and 32 codepoints are reserved for experimental or local use (EXP/LU) (see Sec. 6 for further details). The behavioral characteristics of a PHB are to be standardized, and not the algorithms or the mechanisms used to implement them. A router may have a (possibly large) set of parameters that can be used to control how packets are scheduled onto an output interface (e.g., N separate queues with settable priorities, queue lengths, round- robin weights, drop algorithm, drop preference weights and thresholds, etc). To illustrate the distinction between a PHB and a mechanism, we point out that the EF PHB might be implemented by several mechanisms, including: strict priority queueing, WFQ or variants [HPFQA], weighted round-robin queueing with a large weight for the EF queue, or CBQ [CBQ]. Router vendors are free to offer whatever parameters and capabilities are deemed useful or marketable. When a particular, standardized PHB is implemented in a router, a vendor may use any algorithm that satisfies the definition of the PHB according to the standard. The router's capabilities and its particular configuration determine the Nichols, Blake Expires: November 1998 [Page 6] INTERNET-DRAFT Differentiated Services May 1998 different ways that packets can be treated. Service providers are not required to use the same router mechanisms or configurations to enable service differentiation within their networks, and are free to configure the router parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives. Over time certain common per-hop behaviors are likely to evolve (i.e., ones that are particularly useful for implementing end-to-end services) and these may be associated with particular EXP/LU PHB codepoints in the DS byte, allowing use across domain boundaries (see Sec. 6). These PHBs are candidates for future standardization. Only those per-hop behaviors that are not described by an existing PHB standard, and have been implemented, deployed, and shown to be useful, should be standardized. Since current experience with differentiated services is quite limited, it is premature to hypothesize the exact specification of these per-hop behaviors. This specification has left room in the codepoint space to allow for evolution, thus the defined space is intentionally sparse. 6. IANA Considerations The PHB field in the DS byte is capable of conveying 64 distinct codepoints. The codepoint space is divided into three pools for the purpose of codepoint assignment and management: a pool of 32 codepoints (Pool 1) to be assigned by Standards Action as defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved for experimental or Local Use (EXP/LU) as defined in [CONS], and a pool of 16 codepoints (Pool 3) which are initially available for experimental or local use, but which should be preferentially utilized for standardized assignments if Pool 1 is ever exhausted. The pools are defined in the following table (where 'x' refers to either '0' or '1'): Pool Codepoint space Assignment Policy ---- --------------- ----------------- 1 xxxxx0 Standards Action 2 xxxx11 EXP/LU 3 xxxx01 EXP/LU (*) (*) may be utilized for future Standards Action allocations as necessary This document defines two per-hop behaviors for standardization, and recommends the assignment of two codepoints (000000 and 000010) which are drawn from Pool 1 above. Nichols, Blake Expires: November 1998 [Page 7] INTERNET-DRAFT Differentiated Services May 1998 The IANA should note that a companion document may recommend assignment of the codepoint space xxxx00 within Pool 1 for use by per-hop behaviors which provide a minimal level of backwards compatibility with IP Precedence as defined in [RFC791]. 7. Security Considerations The IP Security Authentication Header (AH) does not cover the IPv4 TOS octet or the IPv6 Traffic Class field in the integrity check value computation [AH]. This behavior is in fact essential for the deployment of differentiated services since the value of the DS byte may be changed in transit so that the source host does not know what value will be delivered to the destination host. Also, since the network is free to ignore the DS byte, end-to-end integrity of a DS byte value does not guarantee that a differentiated service has been delivered. Separate measurement and assurance mechanisms are needed to ensure that any negotiated differentiated services are being provided. Packets marked for Expedited Forwarding receive priority service relative to packets with other markings. The rate of EF-marked packets MUST be regulated to prevent starvation of other traffic. EF-marked traffic received across a boundary link SHOULD be authenticated (e.g., either by IPsec, by header classification, or by aggregate policing). Additional security issues of the general differentiated services architecture are discussed in [ARCH]. 8. Acknowledgements The authors would like to acknowledge the Differentiated Services Working Group for discussions which helped shape this document. 9. References [ACTIVE] B. Braden, et. al., "Recommendations on Queue Management and Congestion Avoidance in the Internet", Internet RFC 2309, April 1998. [AH] S. Kent and R. Atkinson, "IP Authentication Header", Internet Draft , March 1998. [ARCH] Differentiated Services Architecture Document (work in preparation). Nichols, Blake Expires: November 1998 [Page 8] INTERNET-DRAFT Differentiated Services May 1998 [Baker] F. Baker, S. Brim, T. Li, F. Kastenholz, S. Jagannath, and J. Renwick, "IP Precedence in Differentiated Services Using the Assured Service", Internet Draft , April 1998. [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3 no. 4, pp. 365-386, August 1995. [CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", Internet Draft , March 1998. [CCBES] C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang, "Congestion Control for Best-Effort Service: Why We Need a New Paradigm", IEEE Network, Vol. 10, no. 1, January 1996. [ECN] K. Ramakrishnan and S. Floyd, "A Proposal to Add Explicit Congestion Notification (ECN) to IPv6 and to TCP", Internet Draft , November 1997. [FWK] Differentiated Services Framework Document (work in preparation). [HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996. [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", Internet Draft , November 1997. [RFC791] Information Sciences Institute, "Internet Protocol", Internet RFC 791, September 1981. [RFC1349] P. Almquist, "Type of Service in the Internet Protocol Suite", Internet RFC 1349, July 1992. [RFC1812] F. Baker, editor, "Requirements for IP Version 4 Routers", Internet RFC 1812, June 1995. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", http://www-nrg.ee.lbl.gov/papers/2bitarch.pdf. Nichols, Blake Expires: November 1998 [Page 9] INTERNET-DRAFT Differentiated Services May 1998 Appendix A. Service Examples in this Framework We present two example services which may be implemented using the per-hop behaviors defined in this document. We do not attempt to define "quality of service" for applications nor do we make assumptions about what service a particular application might use. Thus, although we give some example uses, we do not characterize the services as being "for real-time video" or "for file transfer data". Instead, we characterize a service by the type of performance packets of that service can expect from the network. Any IP application can utilize either of these services; the choice is up to the customer. Service: Best Effort PHBs used: Default Service definition: "like today" (as soon as possible; as much as possible [CCBES]). At the network edge, packets of the Best Effort aggregate should be marked with the Default PHB (though this is also the forwarding treatment that a packet with an unknown marking should receive). This might be accomplished by marking all packets at the network edge for the Default PHB which can be changed if the packet header matches an multi-field classifier set up at the network edge. Who/how to use this: The basic service of the Internet, what one gets when merely buying connectivity. Service: Premium PHBs used: Expedited Forwarding Service definition: Premium service is a peak-limited, extremely low- delay service, resembling a leased line [2BIT]. At the network edge, where a Premium aggregate is first created, it must be either shaped or policed to a rate with no more than a two-packet burst. A policer for Premium service is set to drop packets which exceed the configured peak rate. For this service, the peak rate of the Premium aggregate across any boundary must be specified and the rate must be smaller than the link capacity (in practice, it is expected to be a good deal less than the link capacity). Policing to this rate is expected at the ingress of any domain and the policing action taken may be one of two possibilities only: 1) drop the over-rate packet and 2) hold the over-rate packet until it will be in compliance with the peak rate (shaping). Who/how to use this: Voice-over-IP "trunk", videoconference, fixed size transfer in fixed time, virtual leased line, low delay applications. Nichols, Blake Expires: November 1998 [Page 10] INTERNET-DRAFT Differentiated Services May 1998 Authors' Addresses Steven Blake IBM Microelectronics C5BA 660/HH007 800 Park Offices Drive Research Triangle Park, NC 27709 Phone: +1-919-254-2030 Fax: +1-919-254-3047 E-mail: slblake@raleigh.ibm.com Kathleen Nichols Bay Networks Architecture Lab 4401 Great America Parkway SC01-04 Santa Clara, CA 95052-8185 Phone: +1-408-495-3252 Fax: +1-408-495-1299 E-mail: knichols@baynetworks.com Nichols, Blake Expires: November 1998 [Page 11]