Internet Draft D. McDysan Document: draft-mcdysan-diffserv-consistent- L. Yao meter-00.txt X. Shi Expires: January 2002 WorldCom July 2001 Consistent Metering in Diffserv Traffic Conditioning 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. Conventions used in this document 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 [1]. Abstract Metering is typically performed at the edge of a Diffserv-aware network where customer traffic is checked for conformance or else where networks interconnect using shaping/policing as a practical matter in IP networks. This document describes the importance of the consistent metering in Diffserv traffic conditioning. This document also proposes the concepts and the associated details to be adapted by Diffserv informal model [DIFFSERV-MODEL] to achieve the desired consistency. 1. Introduction McDysan Expires January 2002 [Page 1] Internet Draft draft-mcdysan-diffserv-consistent July 2001 -meter-00.txt The Diffserv architecture requires the use of traffic conditioning components at the edge of a Diffserv network or between inter-domain Diffserv networks. Meters are typically used to check the conformance of the received traffic to a pre-configured traffic profile (e.g. token bucket (r,b)) before performing the traffic conditioning actions (i.e. marking, dropping or scheduling) on the traffic. It is generally required by service providers that two consecutive traffic conditioning components provisioned according to the same traffic profile perform conformance checking consistently. For example, if the customer traffic has been shaped according to a traffic profile, the shaped traffic must appear conforming to a following policer using the same traffic profile. This document reviews multiple definitions of meters, and describes why the consistent conformance checking with meters is desirable from service providers' point of view and how to achieve the consistent metering. 2. Multiple Definitions of Meters A meter, according to [DIFFSERV-MODEL] section 5, measures the rate at which packets pass it, compares this rate to some set of traffic profiles and produces one or more conformance levels. [DIFFSERV-MODEL] defines five types of meters - Average Rate Meter: It measures the average rate at which packets are submitted to it over a specified time interval. It has the parameters: average rate (in kbps) and average sampling interval (in msec). - Exponential Weighted Moving Average (EWMA) Meter: It uses a simple IIR low-pass filter to control the measurement of average rate. In addition to average rate and average sampling interval, it has a gain parameter (0|Policer| |Shaper|------>|Policer| |Shaper| | +------| +-------+ +------+ +-------+ +------+ | | | | | | | | | | | | +-------------+ +----------------+ +----------------+ Figure 1. Customer-ISP and ISP-ISP Traffic Conditioning 4. How to Achieve Consistent Metering This paper proposes that the Diffserv informal model include guidelines for configurations such as those shown in Figure 1 where shapers and policers use different metering algorithms. This section gives a simple example for a case when the same algorithm is used with the same rate and burst parameters. [DIFFSERV-MIB] and [DIFFSERV-PIB] collects many of the parameters for meter interpretations into a MIB and a PIB, respectively. For typical token bucket meters, one parameter that is important for consistent conformance checking in the contexts cited above is the token bucket update interval, repeated below from [DIFFSERV-MIB] and [DIFFSERV-PIB]: diffServTBMeterInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS ômicrosecondsö MAX-ACCESS read-create STATUS current DESCRIPTION "The time interval used with the token bucket. For: 1. Average Rate Meter, [DIFFSERV-MODEL] section 5.2.1, - Delta. 2. Simple Token Bucket Meter, [DIFFSERV-MODEL] McDysan Expires January 2002 [Page 3] Internet Draft draft-mcdysan-diffserv-consistent July 2001 -meter-00.txt section 5.1, - time interval t. 3. RFC 2859 TSWTCM, - AVG_INTERVAL. 4.RFC 2697 srTCM, RFC 2698 trTCM, - token bucket update time interval." ::= { diffServTBParamEntry 5 } qosTBparamInterval OBJECT-TYPE SYNTAX Unsigned32 UNITS "microseconds" STATUS current DESCRIPTION "The time interval used with the token bucket. For: 1. Average Rate Meter, [DIFFSERV-MODEL] section 5.2.1, - Delta. 2. Simple Token Bucket Meter, [DIFFSERV-MODEL] section 5.1, - time interval t. 3. RFC 2859 TSWTCM, - AVG_INTERVAL. 4.RFC 2697 srTCM, RFC 2698 trTCM, - token bucket update time interval." ::= { qosTBParamEntry 5 } The update interval together with token rate determines how often and how many tokens can be added into the token bucket with the bucket depth as the upper limit of number of tokens in the bucket. For example, for a token bucket of (r,b) and a update interval of t, the number of tokens are added into the bucket at every t sec is given by r*t. To achieve consistent conformance checking with the periodical token update, all the meters along the forwarding path of the customer traffic should use an update interval such that r*t is less than the smallest packet size. Note that, another way to achieve consistence metering is to use event-driven token update (e.g. per-packet arrival event) instead of periodical token update. 5. Security Considerations Inconsistent metering in Diffserv traffic conditioning may result in a theft of service attack on a Diffserv network. This is because service providers may have to turn off policing or configure policers at the ingress of their Diffserv networks very loosely against customers' traffic profiles in order to avoid excessively dropping of customer traffic. Therefore, customers may be able to send traffic well above their subscribed transmission rate and/or burst size. 6. References [RFC2697] J. Heinanen, and R. Guerin, " A Single Rate Three Color Marker ", RFC 2697, September 1999 [RFC2698] J. Heinanen, and R. Guerin, " A Two Rate Three Color Marker ", RFC 2698, September 1999 McDysan Expires January 2002 [Page 4] Internet Draft draft-mcdysan-diffserv-consistent July 2001 -meter-00.txt [RFC2859] W. Fang, et al., ôA Time Sliding Window Three Colour Marker (TSWTCM)ö, RFC 2859 [DIFFSERV-MIB] F. Baker, K. Chan and A. Smith, " Management Information Base for the Differentiated Services Architecture", draft-ietf-diffserv-mib-09.txt, work in progress [DIFFSERV-MODEL] Y. Bernet, S. Blake, D. Grossman, and A. Smith " An Informal Management Model for Diffserv Routers ", draft-ietf- diffserv-model-06.txt, work in progress [DIFFSERV-PIB] M. Fine, and K. McCloghrie, etc., " Differentiated Services Quality of Service Policy Information Base ", draft-ietf- diffserv-pib-03.txt, work in progress Author's Addresses David E. McDysan WorldCom 22001 Loudoun County Parkway Ashburn, VA Email: dave.mcdysan@wcom.com Lei Yao WorldCom 22001 Loudoun County Parkway Ashburn, VA 20147 Email: lei.yao@wcom.com Xiyan Shi WorldCom 22001 Loudoun County Parkway Ashburn, VA 20147 Email: shi@mci.net McDysan Expires January 2002 [Page 5]