From owner-rtfm@auckland.ac.nz Mon Sep 11 02:07:11 2000 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA27026 for ; Mon, 11 Sep 2000 02:07:06 -0400 (EDT) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id PAA00546; Mon, 11 Sep 2000 15:12:49 +1200 (NZST) Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id PAA00518 for ; Mon, 11 Sep 2000 15:12:43 +1200 (NZST) From: Nevil Brownlee To: rtfm@auckland.ac.nz Subject: Architecture Extension for RTFM Message-ID: Date: Mon, 11 Sep 2000 15:12:55 +1200 (New Zealand Standard Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello all: At the informal RTFM get-together in Pittsburg last August I promised to produce an I-D describing the changes I believe are needed to the RTFM Architecture to support the new attributes which have proved useful in test implementations. My notes on this are appended below, I'd appreciate any comments, suggestions, etc., before I add the bioler-plate to make it look more like an I-D. Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P Implementing New Attributes: proposed new RTFM work item DRAFT notes for an I-D, Nevil Brownlee, Mon 11 Sep 00 1. Introduction RFC 2724 described a range of possibilities for extending the RTFM Architecture, by adding new types of attribute value, and by proposing new attributes which could be measured by an RTFM meter. The new attributes, particularly the distribution-values ones, have been implemented and used for several years now, and many of them have proved very useful. In addition, mailing-list discussions have shown the need for another attribute type, list-valued. There is now a clear need to extend the RTFM architecture to include these new attribute types, and the attributes which have proved useful. RFCs covering extensions to the Architecture and to the Meter MIB are therefore proposed as work items for a new RTFM Working Group. 2. New Attribute Types 2.1. Attribute type 'distribution-valued' A distribution value is used as a way of gathering a sample distribution for a specified metric. The distribution is stored in an array of 'buckets,' with the values being stored as counters between a minimum and maximum, with defined steps (either linear of logarithmic) for each bucket, together with one further 'overflow' bucket for values above the maximum. The counters are never reset, hence one can compute the difference between two consecutive distributions; such a 'difference distribution' describes the metric's behaviour in the interval between successive meter readings. As well as it's buckets, a distribution value must also hold the values of the parameters which specify the mapping of its values. RFC 2724 proposed the following parameters, with sizes (in bytes) chosen so as to fit within two six-byte fields (the minimum size for RTFM Address Attributes). Size Parameter Description 1 Transform 0 = null, 1 = linear, 2 = logarithmic 1 Scale Factor Power of 10 multiplier for limits and counts 2 Lower Limit Highest value for first bucket 2 Upper Limit Highest value for last bucket 1 Buckets Number of buckets. Does not include the 'overflow' bucket 1 Parameter-1 } Parameter use depends 2 Parameter-2 } on distribution-valued 2 Parameter-3 } attribute This set of parameters has worked very well in practice. Note that each bucket receives counts for values within a fixed range - there is no attempt to adjust the steps dynamically. This is a simple approach, but onew which has has proved to be very effective in use. The complete set of parameters and values (including the overflow bucket) can be retrived by a meter reader, allowing ananlysis software to compute whatever statistics are required to describe the distribution. Within an SNMP PDU a distribution appears as a sequence of integers. The first eight integers are the distribution parameters, these are followed by the bucket counters, and then the overflow counter. If a meter reader attempts to get a non-existent distribution value, e.g. from a flow whose ruleset never saved a particular distribution-valued attribute, the meter must return a null distribution, i.e. one which has Transform = 0 and Buckets = 0. Within as SNMP PDU a null distribution will be a sequence containing a single integer whose value is zero. Note that a separate distribution must be built for each direction of a flow; in this respect distribution-valued attributes (e.g. ToBitRate and FromBitRate distribution) are similar to simple counts (e.g. ToPDUs and FromPDUs). 2.2. Attribute type 'list-valued' All of the RTFM address attributes have values in each packet for both directions of their flow, e.g. every packet has values for both SourcePeerAddress and DestPeerAddress. The RTFM packet-matching algorithm depends on having both of these, so that they can be swapped when attempting a match in the reverse direction. Metrics such as DSCodePoint and NetFlow's NextHop have only one value in each packet, hence they can't be used in packet matching. However, we would like to determine what values of these metrics appear while the flow is active, for each of its two directions. To do this, we can build tables of (value, count) pairs, one for each direction of the flow. Each such table is a list-value, e.g. ToDSCodePoint is a list of the CodePoint values seen for a flow's Source->Destination packets, together with counts for each of those values. FromDSCodePoint is similar, but for a flow's Destination->Source packets. Within an SNMP PDU a list-value is a sequence of integers. The first integer gives the number of pairs in the list (zero if no values have been counted); it is followed by the actual (value, count) pairs. 3. New Attributes 3.1. Attributes from RFC 2724 - Distributions(65) Has bits set to indicate which distribution-valued attributes are present in the flow. *** Making SNMP GETs for non-existent distribution-valued attributes return null distributions removes the need for this attribute. + Packet sizes distributions: ToPacketSize(66) size of PDUs in bytes (i.e. number FromPacketSize(67) of bytes actually transmitted) + Inter-arrival time distributions for packets within a flow: ToInterarrivalTime(68) microseconds between successive packets FromInterarrivalTime(69) travelling in the same direction Inter-arrival times for packets travelling in the same direction are useful for determining variations in packet transit times. Note that they don't require any packet matching, all the meter has to do is to remember the arrival time (in microseconds) for the last packet in each direction, + Short-term bit- and packet-rate distributions: ToBitRate(72) short-term flow rate in bits per second FromBitRate(73) Parameter 1 = rate interval in seconds ToPDURate(74) short-term flow rate in PDUs per second FromPDURate(75) Parameter 1 = rate interval in seconds 10-second bit rates have proved very useful in observing the utilisation of busy links. They are particularly useful for links which allow short-term traffic bursts (e.g. Frame Relay links), since they provide a good indication of just how bursty the link's traffic is. + Autonomous System Numbers (integers): SourceASN(113) Autonomous System Number for flow's source DestASN(115) Autonomous System Number for flow's destination SourcePrefix(114) CIDR width used by router for determining flow's source network DestPrefix(116) CIDR width used by router for determining flow's destination network The need for ASN-based attributes originally came from RTFM meters using Cisco NetFlow data rather than simply observing packet headers. Other versions of the RTFM meter have supported these attributes by looking up ASNs in a table of data obtained from a router running BGP. + DS CodePoint list-values: ToDSCodePoint(118) DS Code Point (6 bits) for packets in this flow from source to destination FromDSCodePoint(119) DS Code Point (6 bits) for packets in this flow this flow from destination to source These attributes allow a meter to build tables showing which CodePoints are being used in each direction of flows. Other attributes discussed in RFC 2724 have not received sufficient implementation experience - they should not be included in these RTFM extensions. 3.2. Other possible new attributes The following areas of interest have been proposed on the mailing list and/or in test implementations of the RTFM meter: + Next-hop address list-values: ToNextHop FromNextHop These attributes would build tables of a router's next-hop addresses. They would be useful for verifying that routing was being performed correctly (i.e. as per the router configuration and routing table). + Packet Header Trace attribute: This was discussed at the RTFM informal meeting in Pittsburg last August. + Explicit Congestion Notification (ECN) attributes: A set of attributes for assessing the performance of Explicit Congestion Notification (RFC 2481) could be worth considering. ---------------------------------------------------------------------