Internet Engineering Task Force Kathleen Nichols, editor INTERNET-DRAFT Bay Networks Architecture Lab Expires: August 1998 Steven Blake, editor IBM Microelectronics February 1998 Differentiated Services Operational Model and Definitions 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 learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (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. The differentiated services approach to providing quality of service in networks employs a small, well- defined set of building blocks from which a variety of services may be built. The services may be either end-to-end or intra-domain. A wide range of services can be provided by a combination of: - setting bits in the TOS octet at network edges and administrative boundaries, - using those bits to determine how packets are treated by the routers inside the network, and - conditioning the marked packets at network boundaries in accordance with the requirements of each service. A differentiated-services-capable network node includes a classifier that selects packets based on the TOS octet and is capable of delivering the treatment corresponding to that marking of the TOS octet. Setting of the TOS octet and other conditioning of the Nichols, et. al. Expires: August 1998 [Page 1] INTERNET-DRAFT Differentiated Services February 1998 dynamic behavior of marked packets need only be performed at network boundaries and may vary in complexity. This draft presents a differentiated services definition of the TOS octet and the operational model behind that definition. Authors This document is the result of a collaborative effort among the following individuals: Fred Baker, Steve Blake, Scott Bradner, Scott Brim, Brian Carpenter, Dave Clark, Eric Crawley, Bruce Davie, Juha Heinanen, Geoff Huston, Van Jacobson, Jim Luciani, Kathleen Nichols, Mike O'Dell, John Wroclawski, and Lixia Zhang. 0. Discussion of this draft We have set up a public mailing list for discussions of this draft and for other differentiated services BOF issues. The list is: diff-serv@baynetworks.com. To subscribe send mail to majordomo@baynetworks.com with the line "subscribe diff-serv" in the body. A browsable archive for this mailing list is at http://www-nrg.ee.lbl.gov/diff-serv-arch and the archive can be downloaded from ftp://ftp.ee.lbl.gov/diff-serv-arch/. Please use this mailing list rather than others for the discussion of differentiated services. 1. Introduction The TOS octet is used to mark a packet to receive a particular per- hop behavior. Marking is performed by traffic conditioners at network boundaries, including the edges of the network (first hop router/switch) and administrative boundaries. Traffic conditioners may include the primitives of classification, marking, policing and shaping. Service classes can be specified by the use of particular traffic conditioning at boundaries coupled with particular per-hop behaviors. 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. A number of recent Internet Drafts have suggested various encodings of the TOS byte to get specific behavior from network nodes on a per- hop basis [Ellesson, Ferguson, Heinanen, SIMA] and others have discussed the behaviors required from the network [Clark, 2BIT]. All of these have made important points about the kinds of per-hop behaviors that are considered in this note. In selecting the TOS octet definition and specifying per-hop behaviors to attach to particular bit-patterns, we have been influenced by all these drafts and the thoughtful work of their authors. Nichols, et. al. Expires: August 1998 [Page 2] INTERNET-DRAFT Differentiated Services February 1998 We define terminology used in this draft in Sec. 2 and propose a differentiated services definition for the TOS octet in Sec. 3. In Sec. 4, we present an operational model for the assignment of per-hop behaviors and propose two specific per-hop behaviors for standardization. Sec. 5 describes primitives that can be used for traffic conditioning. Sec. 6 discusses service allocation and deployment and Sec. 7 covers some security considerations. We present additional discussion of the TOS octet definition in Appendix A and in Appendix B present some example services that can be built from these differentiated services primitives. 2. Terminology used in this document Service: The description of what is sold to a customer, specified either end-to-end or within an Autonomous System (e.g., an ISP or campus). We use the phrase "sold to a customer" loosely enough to encompass any AS's allocation of network service to a user or application. Per-hop Behavior: The forwarding behavior a packet receives at a given network node. It may be expressed in terms that can strongly suggest a particular algorithm or implementation but leaves the specific choice to the implementor. To compose predictable services, per-hop behaviors probably need to be available in all routers in a differentiated-services-capable network. Mechanism: The implementation of a behavior. 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. DS byte: the IP header TOS octet when configured in conformance with the definition given in this document. Differentiated services behavior aggregate: a collection of packets with the same DS byte pattern crossing a boundary in a particular direction. The terms "aggregate" and "behavior aggregate" will be used interchangeably in this document. 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 see or at the egress of the last-hop differentiated-services-aware router or network node packets see 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 Nichols, et. al. Expires: August 1998 [Page 3] INTERNET-DRAFT Differentiated Services February 1998 a host, subject to local policy. Traffic conditioning primitives: functions that can be applied to a behavior aggregate, flow, or other operationally useful subset of traffic, e.g., routing updates. These include policing, shaping, header classification, and packet marking. Again, these may be described in terms that can strongly suggest a particular algorithm or implementation but no specific choice of implementation is given. With the exception of a DS byte classifier at the packet forwarding engine, traffic conditioning primitives need not be implemented in all network nodes in a differentiated-services-capable network, instead appearing primarily at boundaries. To summarize, the TOS octet is used as a DS byte 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. A Differentiated Services Definition of the TOS Octet We propose to redefine the structure for the 8-bit IPv4 TOS field [RFC791] and the 8-bit IPv6 Class field [IPv6], and re-label the field as the "DS byte". The new structure is presented below: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ |IN | PHB | CU | +---+---+---+---+---+---+---+---+ IN: in (1) or out (0) of profile PHB: per-hop behavior CU: currently unused (reserved) We have been influenced by [Ellesson] and by Dave Clark's talk at the int-serv WG December 8, 1997 meeting. Adopting key elements of Clark's framework, though not the exact terminology or bit-patterns, we use five bits to define the per-hop behavior (PHB) the packet experiences and one bit (IN) to identify whether the packet may be in- or out-of-profile with respect to some traffic policy measured at a network boundary. We also reserve a two-bit CU, or currently unused, field that may be assigned later, e.g., for explicit congestion notification [ECN]. Hosts SHOULD set the CU bits to zeroes, and traffic conditioners and routers SHOULD ignore their value. The IN indicator parameter may be used to mark packets for a higher Nichols, et. al. Expires: August 1998 [Page 4] INTERNET-DRAFT Differentiated Services February 1998 level of service (e.g., lower loss probability) within whatever share of router interface resources (e.g., buffers, bandwidth) are associated with a particular per-hop behavior. Router implementations SHOULD treat the 5-bit PHB field as an index to be used in selecting 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, implementations should treat it as an unstructured field. The structure of the DS byte shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The use of bit 7 as a "DiffServ semantics" indicator was contemplated, but the authors believe that there exists deployed equipment which does not test bit 7, thereby making it impossible to simultaneously support two sets of semantics within the same network. Therefore, to maintain compatibility with IPv4 hosts and networks which utilize the existing TOS semantics, a differentiated services-enabled network MUST remark the TOS value of packets arriving at a boundary entry node to some acceptable value within the new semantics, and MAY remark (e.g., by zeroing) on exit at a boundary to a network supporting the existing semantics. Validating the value of the TOS octet at network boundaries is sensible in any case since an upstream node can easily set them to any random value. Differentiated- services-enabled networks which are not suitably isolated by a remarking boundary node may deliver unpredictable service. 4. Operational Model 4.1 Per-Hop Behaviors The differentiated services model is that a router has 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). Router vendors are free to offer whatever parameters and capabilities they feel are useful or marketable. An ISP is free to configure those parameters in whatever way they feel is appropriate for their service offerings and traffic engineering objectives. The router's capabilities and its particular configuration determine the different ways packets can be treated. The DS byte then selects which treatment a particular packet receives. For example, an ISP may configure eight weighted round robin queues in its routers and use the DS byte to select which queue (from zero, for smallest weight to seven, for largest weight or share of output link) a packet is placed for servicing. Another ISP might configure a single queue with multiple drop priorities and use the DS byte to select the drop preference (from zero, most likely to drop to seven, least likely to drop) for packets in that queue. Another might configure four queues Nichols, et. al. Expires: August 1998 [Page 5] INTERNET-DRAFT Differentiated Services February 1998 with two levels of drop preference in each. There is no requirement that different ISPs use the same router mechanisms or configuration or that any value of the DS byte map to a particular packet forwarding behavior (other than the behaviors described below and the general guidelines given in Appendix A). However, to the extent that the per-hop behaviors are used to implement end-to-end services (see Appendix B for examples), it may be undesirable for the "same" per-hop behavior to be selected by different DS byte values in different ISPs. For example, consider ISP A and ISP B both offering a low jitter, guaranteed rate, premium service. If ISP A uses a PHB of 3 to select an appropriate router mechanism while ISP B uses a PHB of 7, packets that use this service and transit A to B must have the PHB field of their DS byte rewritten from 3 to 7. Since the per-hop behaviors on each side must be functionally equivalent, this is simply useless work that has to be done in the forwarding path of a busy border router. To avoid this, we expect that over time certain common per-hop behaviors will evolve (ones that are particularly useful for implementing end-to-end services) and that these will be associated with particular code points in the DS byte. However, since our current experience with diffserv is quite limited, it is premature to hypothesize the exact specification of these code points and we have simply left room in the code space to allow for evolution, thus the defined space of the PHB field is intentionally sparse. But we do not suggest that PHB patterns be selected and assigned without adherence to a larger context. For more on the rationale of selecting and using PHBs, see Appendix A. Only those per-hop behaviors that have both some degree of orthogonality and have been implemented, deployed, and shown to be useful should be standardized. Two per-hop behaviors are already in widespread use and we propose them for standardization: Default (DE) is the common, best-effort forwarding available in today's internet and already standardized in RFC-1812. Expedited Forwarding (EF) is a "high priority" behavior typically used for network control traffic such as routing updates. The code points chosen for these are compatible with existing practice: PHB field value Behavior name --------------- ------------- 00000 Default (DE) 11100 Expedited Forwarding (EF) and are defined as follows: Nichols, et. al. Expires: August 1998 [Page 6] INTERNET-DRAFT Differentiated Services February 1998 Default: an incoming packet goes to the tail of a queue that is serviced in FIFO order when the output link is free. Thus if a continuous stream of DE-marked packets is sent into a device, packets that emerge will emerge in the same order they entered. It is not required that all arriving packets are seen at the output, but it is required that the aggregate of packets with this marking are not completely starved. Delay requirements are as soon as possible, and the corresponding bandwidth requirements are as much as possible (subject to the other constraints of the router's scheduling system) [CCBES]. The Default behavior is designed to closely approximate the best-effort behavior of existing routers. Expedited Forwarding: an EF-marked packet goes to the tail of a queue that is expected to be relatively short and which always gets the next opportunity to send a packet (possibly subject to some rate regulator policy which prevents starvation of the Default queue). Thus, when an EF-marked packet is sent into a device, that packet should emerge at the output within a very small number of packet times. The expedited forwarding behavior may be used to implement services requiring low delay and low jitter, and may also be useful for network control traffic. Even though the above behaviors have been encoded in 3 bits, implementors should note that the PHB field is 5 bits wide and routers MUST identify both the DE and EF PHBs by matching against the entire 5-bit PHB field. Packets received with an unrecognized PHB value SHOULD be handled as if they were marked for DE. Note that precise definitions of PHBs can be unwieldy and unclear. For this reason, the PHBs above are described as the output of an example algorithm. However, PHBs should be standardized, not the algorithms or the mechanisms used to implement them. To illustrate the distinction between PHB and mechanism, we point out that the EF PHB can be implemented by several mechanisms, including: a strict priority queue, WFQ or variants [HPFQA], weighted round-robin with a large weight for the EF queue, or CBQ [CBQ]. 4.2 The "In Profile" bit Packets marked with the IN bit set should experience a probability of loss or congestion indication which is always less than or equal to that experienced by packets with the IN bit cleared. When the IN bit is used, RIO [Clark] or another drop preference or congestion indication mechanism may be used to implement its use. The requirements on a drop preference mechanism may be specific to each per-hop behavior, but the general requirements include: (1) there should be no packet reordering between packets marked for this behavior; (2) The *average* (real or virtual) queue occupancy should be used in the drop or congestion notification calculation, in a way that maximizes the router's chances of selecting a non-preferred packet to drop or notify of congestion. Nichols, et. al. Expires: August 1998 [Page 7] INTERNET-DRAFT Differentiated Services February 1998 In the absence of traffic profiles, we suggest the IN bit should be set to zero for Default traffic. With traffic profiles, the IN bit can be used to provide further service differentiation of DE-marked packets; for example, it can be used to implement the Assured service described in [Clark]. Use of the IN bit in combination with the EF PHB is a subject of further research; at this time, all packets marked EF should have the IN bit set. A pattern of 0.EF.CU will be considered undefined. The use of the IN bit as an in-profile indicator with the EF PHB is problematic for two reasons. First, the delay and jitter behavior of EF-marked packets is sensitive to the relative load of EF-marked packets on a link; service allocation policies and traffic conditioners are used to ensure that this load is small enough to permit the desired low-delay behavior to be realized. Secondly, out- of-profile EF-marked packets receive priority relative to DE-marked packets; excessive out-of-profile EF-marked packets may degrade the service of the DE-marked aggregate beyond what is assumed in the domain's service allocation policy. 5. Example Traffic Conditioners for Boundaries Recall from Sec. 2 that traffic conditioners are composed of one or more primitives: classifiers, markers, policers, and shapers. Traffic conditioners prepare behavior aggregates for differentiated services. The primitives are defined as: Classifiers: select packets based on some portion of their packet header and steer packets matching some classifier rule to another traffic conditioner for further processing. Classifiers are of two types: multi-field (MF) classifiers which can classify on the DS byte as well as any one of a number of header fields (like a RSVP classifier) and behavior aggregate (BA) classifiers which classify only on patterns in the DS byte. Markers: set the DS byte to a particular bit pattern, adding the marked packets to a particular differentiated services behavior aggregate. Policers: monitor the the dynamic behavior of the packets steered to them by a classifier and take an action (usually remarking or dropping packets) based on the relationship of measured properties of the packet stream to configured properties (e.g., rate and burst). Policers are generally placed after either type of classifier: after MF classifiers (e.g., at a host/network or site/provider boundary) or after BA classifiers (e.g., at a provider/provider boundary). Shapers: cause conformance to some configured traffic properties (e.g., token bucket). Like policers, shapers are generally placed after either type of classifier. Only one of the two primitives, policers or shapers, would be expected to appear in the same traffic Nichols, et. al. Expires: August 1998 [Page 8] INTERNET-DRAFT Differentiated Services February 1998 conditioner. Although it is probably not necessary to standardize traffic conditioners or the primitives that compose them, traffic conditioners are required to instantiate services, and to enforce service allocation policies. The only conditioning that is required for packets of a differentiated services aggregate is to set the DS byte appropriately. Thus, the simplest traffic conditioner consists of only a packet marker that sets the DS byte of every packet on its interface to a particular pattern for a particular per-hop behavior. If the service being offered requires additional rule conformance, then other primitives must be added to the traffic conditioner. Another simple traffic conditioner might use an MF classifier to select packets with a particular source-destination pair and a marker to set these packets' DS byte to for a particular per-hop behavior. There are a number of ways to condition traffic at boundaries; see [Clark], [SIMA], and [2BIT]. We expect that many more might evolve as differentiated services is widely deployed. Applications SHOULD be aware that the value of the DS byte may be modified at each network boundary (possibly subject to some negotiated policy). The value of the DS byte does not have end-to- end integrity; security and transport protocol checksums MUST not include this field. 6. Service Allocation and Deployment As differentiated services are deployed, there will be concerns about service allocation and also about partial deployment. The allocation of differentiated services does not require standardization or uniformity. The differentiated services architecture leads quite naturally to a control structure where decisions about the rate of each type of marked packet are made on a per-domain basis. Since traffic carried on a link between two domains can now be classified into a small set of possibilities, it should be relatively straightforward to write down a bilateral agreement between any two domains. Differentiated services does not require end-to-end signaling, but permits each domain to develop allocations of its intra-domain traffic according to rules and processes that are as simple or complex as desired. Inter-domain agreements can be as simple as a list of the different packet markings and a maximum rate permitted for each. Thus, it is not necessary to standardize a service allocation strategy to deploy differentiated services. We expect that a number of allocation methods will be tried within different domains: aggregated RSVP [AIISS, GBH], Bandwidth Brokers [2BIT], human configuration by a network manager. Reports of experiences with different intra-domain allocation methods should prove valuable during early deployment. Further, we expect the nature of the bilateral inter-domain agreements to evolve as experience is with differentiated services is gained. Again, reports Nichols, et. al. Expires: August 1998 [Page 9] INTERNET-DRAFT Differentiated Services February 1998 on experience will do much to advance the field. Differentiated services are realized by the concatenation of per-hop behaviors along the transit path of a packet; therefore, the treatment experienced by a behavior aggregate along a particular path is unpredictable if some of the nodes along that path do not recognize and implement the proposed per-hop behaviors. Note however that the behavior of a router on a lightly loaded, high-speed link which does not implement a set of per-hop behaviors may be indistinguishable from that of a router which does (since the proposed per-hop behaviors are work-conserving). The choice of those nodes upon which to implement the proposed per-hop behaviors is subject to a domain's traffic engineering policy. Experiences with early deployment of differentiated services should be shared, creating a body of work that the community can draw upon when deploying differentiated services in a domain or when automating a formerly manual process of allocation. Ultimately, we expect that at least some differentiated services will enlist the use of automated inter-domain messaging to provide more flexibility. Selecting and developing the best approach is a topic for research. Though, ultimately, we may need a standard format for these messages, this should not be an IETF topic in the near-term. 7. Security Considerations Wide-spread deployment of IP Security obscures the IP- and transport- header fields which are frequently used to enable packet classification for service differentiation. Use of the DS byte offers an alternative means of classification for differentiated services, thereby eliminating a disincentive to the deployment of IP Security (especially within virtual private networks using ESP in tunnel-mode [ESP]). Because the differentiated services per-hop behaviors introduce service bias, new denial-of-service attacks may be introduced. As an example, unauthorized use of the EF PHB or IN bit may result in service degradation to other traffic flows. Furthermore, an attack on the differentiated services authorization, signaling, or configuration mechanisms may permit theft-of-service or may enable a severe denial-of-service attack. As a consequence, authorization, signaling, and configuration mechanisms must be strongly protected (e.g., by authentication). Non-default per-hop behaviors should always be controlled at a network boundary via some traffic conditioner (classifier, marker, policer/shaper). The IP Security Authentication Header (AH) does not cover the IPv4 TOS octet 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 Nichols, et. al. Expires: August 1998 [Page 10] INTERNET-DRAFT Differentiated Services February 1998 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. 8. Acknowledgements In addition to the co-authors of this document, valuable input was received from Jim Boyle and Sally Floyd. 9. References [AH] S. Kent and R. Atkinson, "IP Authentication Header", Internet Draft , October 1997. [AIISS] S. Berson and S. Vincent, "Aggregation of Internet Integrated Services State", Internet Draft , November 1997. [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. [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. [Clark] D. Clark and J. Wroclawski, "An Approach to Service Allocation in the Internet", Internet Draft , July 1997. [ECN] K. Ramakrishnan and S. Floyd, "A Proposal to Add Explicit Congestion Notification (ECN) to IPv6 and to TCP", Internet Draft , November 1997. [Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format and Semantics of the TOS Byte and Traffic Class Byte in IPv4 and IPv6", Internet Draft , November 1997. [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security Payload", Internet Draft , October 1997. Nichols, et. al. Expires: August 1998 [Page 11] INTERNET-DRAFT Differentiated Services February 1998 [Ferguson] P. Ferguson, "Simple Differential Services: IP TOS and Precedence, Delay Indication, and Drop Preference, Internet Draft , November 1997. [GBH] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP- based QoS Requests", Internet Draft , November 1997. [Heinanen] J. Heinanen, "Use of the IPv4 TOS Octet to Support Differentiated Services", Internet Draft , November 1997. [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. [SIMA] K. Kilkki, "Simple Integrated Media Access (SIMA)", Internet Draft , June 1997. [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", Internet Draft , November 1997. Appendix A. Proposed Interpretation of the Three Most-Significant Bits of the PHB Field In this document, we have proposed two particular PHBs. Observant readers will note that the numerical value of the PHB field assigned to the Expedited Forwarding behavior is greater than that assigned to the Default behavior. This is compatible with the interpretation of the three most-significant bits of the PHB field (bits 1, 2, and 3 of the DS byte as shown in Sec. 3) as a "weight" or "traffic precedence" relative to some dimension of quality of service (e.g., delay, throughput, or loss). We propose that implementors use bits 1, 2, and 3 as a weight parameter to enable experiments using multi-level priority (of loss, delay, and/or throughput), subject to the requirement that bits 4 and 5 of the DS byte have the value zero. The associated weight (e.g., increased delay priority, increased link share, decreased loss probability) should increase in the order of Nichols, et. al. Expires: August 1998 [Page 12] INTERNET-DRAFT Differentiated Services February 1998 increasing numerical value of bits 1, 2, and 3. The interpretation of bits 1, 2, and 3 when the value of bits 4 and 5 is not equal to zero is not defined. Because this proposal does not specify the specific QoS metric which is affected by this three bit weight, implementation of any particular differentiated service using this parameter is dependent on each router's interpretation and implementation of the weight. Potential behaviors which could utilize this weight field include multi-level delay priority, multi-level discard priority, or multiple link shares (where the share of a link increases in the order of increasing weight). Appendix B. Service Examples in this Framework We propose standardizing ONLY a new meaning for the TOS octet and particular per-hop behaviors associated with certain TOS octet patterns. These will provide predictable building blocks from which a variety of services might be built. There is thus no need to standardize the services as these are realized by combining traffic conditioners at boundaries with per-hop behaviors. To illustrate this, we present some example services implemented in our framework. 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 any of the services; the choice is up to the customer. Service: Best Effort Service definition: "like today" (as soon as possible; as much as possible [CCBES]). Who/how to use this: The basic service of the Internet, what one gets when merely buying connectivity. Service: Premium 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 Nichols, et. al. Expires: August 1998 [Page 13] INTERNET-DRAFT Differentiated Services February 1998 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. Service name: Assured Service definition: Assured service is characterized by a rate and burst profile [Clark]. Behavior aggregates that conform to their profile are unlikely to experience dropped packets. Packets sent that are out-of-profile are serviced with a higher drop preference, but are not reordered with respect to in-profile packets. At the network edge, an assured behavior aggregate is marked for DE, the IN bit is set, and it is policed to a configured rate and burst size. A policer for assured service clears the IN bit of packets which exceed the configured rate, thus tagging them as "out-of-profile". The IN bit is only used if there is congestion on a link, then "out" packets are dropped with higher probability than "in" packets. The sum of the Assured rates along with all other reserved rates at a domain ingress should be less than the total available rate. Packets must remain marked for DE as reordering is prohibited. Who/how to use this: fixed file transfer size in desired time, "better effort", certain adaptive applications. Though we believe it is too early to standardize more than the EF and DE PHBs, we describe a service that can be delivered with a "link share" interpretation of bits 1, 2, and 3 of the DS byte as described in Appendix A. Service name: Olympic Service definition: Olympic service provides three levels of service, gold, silver, and bronze, in decreasing order of congested link shares. Deployment of this service requires the implementation of a rate-based link share scheduler behavior at each hop [HPFQA, CBQ]. The particular link share associated with a packet could be selected as suggested in Appendix A. When encountering a congested link, packets with "Olympic gold" service will get a larger share of the link than packets sent using the "Olympic silver" service which gets a larger share of the link than packets sent using the "Olympic bronze" service. When there are no packet flows of gold or silver (or other higher serviced flows), bronze packet flows may utilize the entire output link. This service classifies flows at a boundary, marking packets for link share (e.g., by setting the "weight" parameter in bits 1, 2, and 3) and setting the IN bit. The weight parameter could be set to i for gold flow packets, i-1 for silver flow packets, and i-2 for bronze flow packets, where 2 < i < 7. Classification should be uniform across a single TCP flow or packet reordering may result. The exact method of service discrimination Nichols, et. al. Expires: August 1998 [Page 14] INTERNET-DRAFT Differentiated Services February 1998 among the parameters is not specified, but would presumably be selected so as to make a perceptible difference to customers. For example, if the mechanism implementing link sharing has four weighted round robin queues with RIO droppers in each queue, a configuration might be 60% for gold, 30% for silver, 10% for bronze. These are the percentages each aggregate gets when the link is congested, but an alternate specification is that silver would get three times as large a share of service as bronze and gold would get twice the service of silver (it is also possible to have a "hidden" majority share reserved for EF traffic). Lengths of each queue might also be adjusted to meet certain requirements (this is a configuration option which would not be standardized). Customers do not specify a particular traffic profile, flows are not admission-controlled, and flows are not shaped or policed in any way. Who/how use this: for customer discrimination within an ISP, corporate, or campus domain. Editors' Addresses 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 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 Nichols, et. al. Expires: August 1998 [Page 15]