Subject: Architecture Extension for RTFM

From: Nevil Brownlee <[email-masked]>
Date: Mon, 11 Sep 2000 15:12:55 +1200 (New Zealand Standard Time)

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.

---------------------------------------------------------------------