Internet-Draft EF RESOLVE DESIGN TEAM (Grenville Armitage) (Alessio Casati) (Jon Crowcroft) (Joel Halpern) (Brijesh Kumar) (John Schnizlein) November 12th, 2000 A revised expression of the Expedited Forwarding PHB Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document was submitted to the IETF Differentiated Services (DiffServ) WG. Publication of this document does not imply acceptance by the DiffServ WG of any ideas expressed within. Comments should be submitted to the diffserv@ietf.org mailing list. Distribution of this memo is unlimited. Abstract RFC 2598 is the DiffServ working group's current standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB) [1]. As part of the DiffServ working group's ongoing refinement of the EF PHB, additional issues were raised with the text in RFC 2598 [2]. An 'EF design team' was formed after the Pittsburgh IETF meeting EFRESOLVE. Expires May 16, 2000 [Page 1] Internet Draft Nov. 16, 2000 to synthesize a new expression of the EF PHB. This Internet Draft captures our feedback to the DiffServ WG on a proposed revision to the EF PHB definition. A formal revision to RFC 2598 will be derived from this document. Specification of Requirements 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 RFC 2119 [3]. 1 Introduction RFC 2598 is the Differentiated Services (DiffServ) working group's current standards track definition of the Expedited Forwarding (EF) Per Hop Behavior (PHB) [1]. As part of the DiffServ working group's ongoing refinement of the EF PHB, additional issues were raised with the text in RFC 2598 [2]. An 'EF design team' was formed after the Pittsburgh IETF meeting to synthesize a new expression of the EF PHB. This Internet Draft captures our feedback to the DiffServ WG on a proposed revision to the EF PHB definition. A formal revision to RFC 2598 will be derived from this document. Section 2 covers the minimum, necessary and sufficient description of what qualifies as 'EF' behavior from a single node. Section 3 then discusses a number of issues and assumptions made to support the definition in section 2. 2. Definition of Expedited Forwarding For a traffic stream not exceeding a configured rate the goal of the EF PHB is a strict bound on the delay variation of packets through a hop. When a DS-compliant node claims to implement the EF PHB, the implementation MUST conform to the specification given in this document. However, the EF PHB is not a mandatory part of the Differentiated Services architecture - a node is NOT REQUIRED to implement the EF PHB in order to be considered DS-compliant. This section will begin with the goals and necessary boundary conditions for EF behavior, then provide a descriptive definition of EF behavior itself, discuss what it means to conform to the EF definition, and assign the default EF code point. 2.1 Goal and Scope of EF EFRESOLVE. Expires May 16, 2000 [Page 2] Internet Draft Nov. 16, 2000 For a traffic stream not exceeding a configured rate the goal of the EF PHB is a strict bound on the delay variation of packets through a hop. Traffic MUST be policed and/or shaped at the source edge (for example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in order to get such a bound. However, specific policing and/or shaping rules are outside the scope of the EF PHB definition. Such rules MUST be defined in any per-domain behaviors (PDBs) composed from the EF PHB. A device (hop) delivers EF behavior to appropriately marked traffic received on one or more interfaces (marking is specified in section 2.4). A device SHALL deliver the EF behavior on an interface to EF marked traffic meeting (i.e. less than or equal) a certain arrival rate limit R. If more EF traffic arrives than is acceptable, the device is NOT REQUIRED to deliver the EF behavior. However, although the original source of EF traffic will be shaped, aggregation and upstream jitter ensure that the traffic arriving at any given hop cannot be assumed to be so shaped. Thus an EF implementation SHOULD have some tolerance for burstiness - the ability to provide EF behavior even when the arrival rate exceeds the rate limit R. Different EF implementations are free to exhibit different tolerance to burstiness. (Burstiness MAY be characterized in terms of the number of back-to-back wire-rate packets to which the hop can deliver EF behavior. However, since the goal of characterizing burstiness is to allow useful comparison of EF implementations, vendors and users of EF implementations MAY choose to utilize other burstiness metrics.) The EF PHB definition does NOT mandate or recommend any particular method for achieving EF behavior. Rather, the EF PHB definition identifies parameters that bound the operating range(s) over which an implementation can deliver EF behavior. Implementors characterize their implementations using these parameters, while network designers and testers use these parameters to assess the utility of different EF implementations. 2.2 Description of EF behavior For simplicity the definition will be explained using an example where traffic arrives on only one interface and is destined for another (single) interface. The crux of this definition is that the difference in time between EFRESOLVE. Expires May 16, 2000 [Page 3] Internet Draft Nov. 16, 2000 when a packet might have been delivered, and when it is delivered, will never exceed a specifiable bound. Given an acceptable (not exceeding arrival rate limit R) stream of EF packets arriving on an interface: There is a time sequence E(i) when these packets would be delivered at the output interface in the absence of competing traffic. That is, E(i) are the earliest times that the packets could be delivered by the device. In the presence of competing traffic, the packets will be delayed to some later time D(i). Competing traffic includes all EF traffic arriving at the device on other ports, and all non-EF traffic arriving at the device on any port. EF is defined as the behavior which ensures, for all i, that: D(i) - E(i) <= S * MTU/R. MTU is the maximum transmission unit (packet size) of the output. R is the arrival rate that the EF device is prepared to accept on this interface. Note that D(i) and E(i) simply refer to the times of what can be thought of as "the same packet" under the two treatments (with and without competing traffic). The score, S, is a characteristic of the device at the rate, R, in order to meet this defined bound. This score, preferably a small constant, depends on the scheduling mechanism and configuration of the device. 2.3 Conformance to EF behavior An implementation need not conform to the EF specification over an arbitrary range of parameter values. Instead, implementations MUST specify the rates, R, and scores S, for which they claim conformance with the EF definition in section 2.2, and the implementation- specific configuration parameters needed to deliver conformant behavior. An implementation SHOULD document the traffic burstiness it can tolerate while still providing EF behavior. The score, S, and configuration parameters depend on the implementation error from an ideal scheduler. Discussion of the ability of any particular scheduler to provide EF behavior, and the EFRESOLVE. Expires May 16, 2000 [Page 4] Internet Draft Nov. 16, 2000 conditions under which it might do so, is outside the scope of this document. The implementor MAY define additional constraints on the range of configurations in which EF behavior is delivered. These constraints MAY include limits on the total EF traffic across the device, or total EF traffic targetted at a given interface from all inputs. This document does not specify any requirements on an EF implementation's values for R, S, or tolerable burstiness. These parameters will be bounded by real-world considerations such as the actual network being designed and the desired PDB. 2.4 Marking for EF behavior One or more DiffServ codepoint (DSCP) values may be used to indicate a requirement for EF behavior [4]. By default a DSCP of 101110 indicates that EF PHB is required. 3. Discussion This section discusses some issues that might not be immediately obvious from the definition in section 2. 3.1 Mutability Packets marked for EF PHB MAY be remarked at a DS domain boundary only to other codepoints that satisfy the EF PHB. Packets marked for EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS domain. 3.2 Tunneling When EF packets are tunneled, the tunneling packets must be marked as EF. 3.3 Interaction with other PHBs Other PHBs and PHB groups may be deployed in the same DS node or domain with the EF PHB as long as the requirement of section 2 is met. 3.4 Output Rate not specified The definition of EF behavior given in section 2 is quite explicitly given in terms of input rate R and output delay variation D(i) - EFRESOLVE. Expires May 16, 2000 [Page 5] Internet Draft Nov. 16, 2000 E(i). A scheduler's output rate does not need to be specified, since it will be whatever is needed to achieve the target delay variation bounds. 3.5 Jitter Jitter is not the bounded parameter in EF behavior. Jitter can be understood in a number of ways, for example the variability in inter- packet times from one inter-packet interval to the next. However, EF behavior aims to bound a related but different parameter - the variation in delay between the time packets would ideally depart, E(i), and when they would depart in the presence of competing traffic, D(i). 3.6 Multiple Inputs and/or Multiple Outputs The definition of 'competing traffic' in section 2.2 covers both the single input/single output case and the more general case where EF traffic is converging on a single output port from multiple input ports. When evaluating the ability of an EF device to offer EF behavior to traffic arriving on one port, EF traffic arriving on other ports is factored in as competing traffic. When considering EF traffic from a single input that is leaving via multiple ports, it is clear that the behavior is no worse than if all of the traffic could be leaving through each one of those ports individually (subject to limits on how much is permitted). 3.7 Fragmentation and Rate Where an ingress link has an MTU higher than that of an egress link, it is conceivable packets may be fragmented as they pass through a Diffserv hop. However, the unpredictability of fragmentation is significantly counter to the goal of providing controllable QoS. Therefore we assume that fragmentation of EF packets is being avoided (either through some form of Path MTU discovery, or configuration), and does not need to be specifically considered in the EF behavior definition. 3.8 Interference with other traffic If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic. This will be reflected in the EF device's burst tolerance described in section 2.1. 3.9 Micro flow awareness EFRESOLVE. Expires May 16, 2000 [Page 6] Internet Draft Nov. 16, 2000 Some EF implementations may choose to provide queuing and scheduling at a finer granularity (for example, per micro flow) than is indicated solely by the packet's DSCP. Such behavior is NOT precluded by the EF PHB definition. However, such behavior is also NOT part of the EF PHB definition. Vendors are free to characterize and publicize the additional per micro flow capabilities of their EF implementations as they see fit. 3.10 Arrival rate 'R' In the absence of additional information, R is assumed to be limited by the slowest interface on the device. In addition, an EF device may be characterized by different values of R for different traffic flow scenarios (for example, for traffic aimed at different ports, total incoming R, and possibly total per output port incoming R across all incoming interfaces). 4. IANA Considerations This document allocates one codepoint, 101110, in Pool 1 of the code space defined by [4]. 5. Conclusion. This document defines EF behavior in terms of a bound on delay variation for traffic streams that are rate shaped on ingress to a DS domain. Two parameters - capped arrival rate (R) and a 'score' (S) are defined and related to the target delay variation bound. All claims of EF 'conformance' for specific implementations of EF behavior are made with respect to particular values for R, S, and the implementation's ability to tolerate small amounts of burstiness in the arriving EF traffic stream. Security Considerations To protect itself against denial of service attacks, the edge of a DS domain MUST strictly police all EF marked packets to a rate negotiated with the adjacent upstream domain (for example, some value less than or equal to the capped arrival rate R). Packets in excess of the negotiated rate MUST be dropped. If two adjacent domains have not negotiated an EF rate, the downstream domain MUST use 0 as the rate (i.e., drop all EF marked packets). Since PDBs constructed from the EF PHB will require that the upstream domain police and shape EF marked traffic to meet the rate negotiated with the downstream domain, the downstream domain's policer should EFRESOLVE. Expires May 16, 2000 [Page 7] Internet Draft Nov. 16, 2000 never have to drop packets. Thus these drops SHOULD be noted (e.g., via SNMP traps) as possible security violations or serious misconfiguration. Overflow events on an EF queue MAY also be logged as indicating possible denial of service attacks or serious network misconfiguration. Acknowledgments This draft is the product of the EF Resolve design team, and builds almost entirely on the works of V. Jacobson, K. Nichols, K. Poduri [1] and A. Charny, F. Baker, J. Bennett, K. Benson, J.-Y. Le Boudec, A. Chiu, W. Courtney, B. Davie, S. Davari, V. Firou, C. Kalmanek, K.K. Ramakrishnan, and D. Stiliadis [2]. Non-contentious text (such as the use of EF with tunnels, the security considerations, etc) were drawn directly from RFC 2598. EF Design Team Members Grenville Armitage Rm A234, 3180 Porter Drive Palo Alto, CA 94061 email: gja@lucent.com Brian E. Carpenter (team observer, WG co-chair) IBM iCAIR, Suite 150 1890 Maple Avenue Evanston IL 60201, USA email: brian@icair.org Alessio Casati Lucent Technologies Swindon, WI SN5 7DJ United Kingdom email: acasati@lucent.com Jon Crowcroft Department of Computer Science University College London Gower Street, London WC1E 6BT, UK email: J.Crowcroft@cs.ucl.ac.uk Joel M. Halpern Longitude Systems, Inc. 15000 Conference Center Drive EFRESOLVE. Expires May 16, 2000 [Page 8] Internet Draft Nov. 16, 2000 Chantilly, VA 20151 email: joel@longsys.com Brijesh Kumar Ennovate Networks email: bkumar@ennovatenetworks.com John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744 email: john.schnizlein@cisco.com Intellectual Properties Considerations References [1] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999 [2] A Charny, ed. "EF PHB Redefined", INTERNET DRAFT (work in progress), July 2000 [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997 [4] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [5] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. EFRESOLVE. Expires May 16, 2000 [Page 9]