[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 rfc2721                                        
Internet Engineering Task Force                           Nevil Brownlee
INTERNET-DRAFT                                The University of Auckland
                                                          September 1998
                                                      Expires March 1999

                     RTFM: Applicability Statement


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.  This Internet Draft is a product of the
Realtime Traffic Flow Measurement Working Group of the IETF.

Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time.  It is not appropriate to use Internet Drafts as
reference material or to cite them other than as a "working draft" or
"work in progress."

To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


This document provides an overview covering all aspects of Realtime
Traffic Flow Measurement, including its area of applicability and its

INTERNET-DRAFT        RTFM: Applicability Statement       September 1998


  1 The RTFM Documents   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  2
  2 Brief Technical Specification (TS)  .  .  .  .  .  .  .  .  .  .  3
  3 Applicability Statement (AS)  .  .  .  .  .  .  .  .  .  .  .  .  4
  4 Limitations .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  5
  5 Security Considerations .  .  .  .  .  .  .  .  .  .  .  .  .  .  6
  6 Policy Considerations   .  .  .  .  .  .  .  .  .  .  .  .  .  .  6
  7 Soundness   .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  7
  8 Appendix A: WG Report on the Meter MIB .  .  .  .  .  .  .  .  .  8
  9 References  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  9
 10 Author's Address  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  9

1 The RTFM Documents

The RTFM Traffic Measurement System has been developed by the Realtime
Traffic Flow Measurement Working Group.  It is described in six other
documents (references [1] to [6]), as follows:

 [1] Internet Accounting: Background                  (Informational)

       Sets out the requirements for a usage reporting system for
       network traffic.  Sketches out the RTFM Architecture (meters,
       meter readers and managers) allowing for multiple meters
       and meter readers, with asynchronous reading from the meters.
       Proposes methods of classifying traffic flows, the need for
       flows to be bi-directional (with separate sets of counters
       for each direction) and the need for each packet to be counted
       in a single flow (the 'count in one bucket' principle).

 [2] RTFM Architecture                                (Informational)

       Defines the RTFM Architecture, giving descriptions of each
       component.  Explains how traffic flows are viewed as logical
       entities described in terms of their address-attribute values,
       so that each is defined by the attributes of its end-points.
       Gives a detailed description of the RTFM traffic meter, with
       full details of how flows are stored in the meter's flow table,
       and how packets are matched in accordance with rules stored in
       a ruleset.

Nevil Brownlee                                                  [Page 2]

INTERNET-DRAFT        RTFM: Applicability Statement       September 1998

 [3] RTFM Meter MIB                               (Proposed Standard)

       Describes the SNMP Management Information Base for an RTFM
       meter, including its flow table, rule table (storing the
       meter's rulesets) and the control tables used for managing
       a meter and reading flow data from it.

 [4] SRL: A Language for Describing Traffic Flows     (Informational)
            and Specifying Actions for Flow Groups

       An RTFM ruleset is an array of rules, used by the meter to
       decide which flows are of interest, which end-point is the
       flow source, and how much detail (i.e. what attribute values)
       must be saved for each flow.  SRL is a high-level language
       providing a clear, logical way to write rulesets.  It should
       also be useful for other applications which select flows
       and perform actions upon them, e.g. packet-marking gateways,
       RSVP policy agents, etc.

 [5] RTFM New Attributes                               (Experimental)

       There has been considerable interest from users in extending
       the RTFM Architecture so as to allow a meter to report on
       an increased number of flow-related measures.  This
       RFC documents work on specifying such measures (the 'new'
       attributes) and reports on experience of implementing them.

 [6] RTFM: Experiences with NeTraMet                  (Informational)

       NeTraMet is a free software implementation of the RTFM
       Architecture which has been available since 1993.  This RFC
       records RTFM implementation experience gained with NeTraMet
       up to late 1996.  One particularly important result is the
       realisation that groups of rules which test the same attribute
       using the same mask can be implemented as a single hashed
       comparison, allowing the meter to rapidly determine whether a
       packet belongs to one of a large number of networks.

2 Brief Technical Specification (TS)

RTFM provides for the measurement of network traffic 'flows,' i.e.

 - a method of specifying traffic flows within
      a network
 - a hierarchy of devices (meters, meter readers, managers)
      for measuring the specified flows
 - a mechanism for configuring meters and meter readers,
      and for collecting the flow data from remote meters

Nevil Brownlee                                                  [Page 3]

INTERNET-DRAFT        RTFM: Applicability Statement       September 1998

The RTFM Meter is designed so as to do as much data reduction work as
possible.  This minimizes the amount of data to be read and the amount
of processing needed to produce useful reports from it.

RTFM flow data can be used for a wide range of purposes, such as usage
accounting, long-term recording of network usage (classified by IP
address attributes) and real-time analysis of traffic flows at remote
metering points.

3 Applicability Statement (AS)

To use RTFM for collecting network traffic information one must first
consider where in the network traffic flows are to be measured.  Once
that is decided, an RTFM Meter must be installed at each chosen
measurement point.

At least one Meter Reader is needed to collect the measured data from
the meters, and a single Manager is needed to control the meters and
meter readers.

RTFM Meters may be single- or multi-user hosts running a meter program
(one such program is available as free software, a second is under
development at IBM Research).  Alternatively, meters could be run as
firmware in switches or routers.  A hybrid approach in which an RTFM
meter takes raw traffic data from a router provides another useful
implementation path.

RTFM Managers are programs running on a Unix host, communicating with
meters and meter readers via the network.  In principle any protocol
could be used for this, but current implementations use the RTFM Meter
MIB to store and access the flow data.  This will require networks using
RTFM to implement the IP protocol so as to send and receive SNMP
requests carried in UDP datagrams.

As indicated above, a meter must support SNMP over UDP. If it runs on a
dedicated host it must also respond to ARP requests.  To aid in
troubleshooting, it should respond to ICMP echo (ping) requests.  These
remarks also apply to RTFM Meter Readers and Managers.

(The paragraphs above describe the current implementations of RTFM. Its
architecture is not limited to having the meter be an SNMP agent - other
communication and storage methods could be used.  For example,
configuration data could be downloaded via FTP, data could be stored in
an SQL database and meter readers could get it via SQL requests.)

Nevil Brownlee                                                  [Page 4]

INTERNET-DRAFT        RTFM: Applicability Statement       September 1998

4 Limitations

Users of RTFM should note that installing meters, meter readers and
managers merely provides one with the capability to collect flow data.
Further installation work will be needed to develop configuration files
(RTFM rulesets) for each meter, data processing applications to analyse
the flow data, and various scripts, cron jobs, etc.  so as to create a
useful production-quality measurement system which suits a user's
particular needs.

One of the strengths of RTFM is its ability to collect flow data at
whatever level of detail (or 'granularity') is required.  It can be
tempting to simply collect 'all possible data,' but there are severe
resource constraints.  If one tries to save the complete
address-attribute value for all attributes of every possible flow a
'combinatorial explosion' of data may result, but the meter has only a
finite amount of memory for its flow table.  A better approach is to
save the minimum amount of data required to achieve the measurement
system goals.

For example, to collect usage data so as to bill subscribers identified
by their IP address one could just save the full IP address, nothing
more.  The RTFM meter would produce flow data for each subscriber IP
address, with PDU and Octet counts for data sent and received, which
would be the minimum needed to produce bills.  In practice one would
probably want to save at least part of the Destination IP address, which
would allow the production of usage logs showing subscriber activity
over time.

The simplest way to determine how much detail can be collected is to
create an initial ruleset which collects the minimum amount, then to
modify it step by step, gradually increasing the amount of information
saved for each flow.  An RTFM meter will provide some measures of its
own performance (e.g.  number of active flows, percentage idle processor
time, packets metered, packets not metered) allowing one to assess the
impact of each change to the ruleset.

If the network data rate is too high, i.e.  the meter reports that it
cannot meter all the packets even with the initial ruleset above, one
may be able to use other strategies.  For example one could

 - run the meter on a faster computer, e.g. move
      from a DOS PC to a Unix workstation, or perhaps use a
      meter implemented in firmware within a switch or router.

 - use sampling.  The Meter MIB allows one to specify that
      only every nth packet on an interface will be metered.
      This would probably not be acceptable for producing billing
      data, but might well be acceptable for traffic engineering

Nevil Brownlee                                                  [Page 5]

INTERNET-DRAFT        RTFM: Applicability Statement       September 1998

5 Security Considerations

These are discussed in detail in the Architecture and Meter MIB
documents.  In brief, an RTFM Meter is an SNMP agent which observes a
network and collects flow data from is.  Since it doesn't control the
network directly, it has no direct effect on network security.

On the other hand, the flow data may well be valuable - to the network
operator (as billing data) or to an attacker (who may wish to modify
that data, or the meter's ruleset(s).  It is therefore important to take
proper precautions to ensure that access to the meter and its data is
sufficiently secure.

For example, a meter port attached to a network should be passive, so
that it cannot respond to login attempts of any kind.  Control and data
connections to a meter should be via a secure management network.
Finally, suitable security should be established for the meter, as it
would be for any other SNMP agent.

6 Policy Considerations

When collecting traffic data, one must have well-defined operations
policies covering points such as:

 - Exactly what data is to be collected, at what level of detail?
 - How long will the data be kept?
 - What may the data be used for?
 - Who will be allowed to see the raw data?
 - May summaries of the data be shown to other people?

Policy issues such as these should normally be considered as part of an
organisation's Network Security Policy.

Other policy issues relating more directly to the traffic data are
essentially part of the measurement system design, such as:

 - How much time resolution is required for the data?
      (Less resolution allows longer collection intervals,
      but that requires more memory in the meters).

Nevil Brownlee                                                  [Page 6]

INTERNET-DRAFT        RTFM: Applicability Statement       September 1998

 - What level of hardware redundancy is needed?
      (A single meter and meter reader is generally enough.  For
      greater reliability, meters and meter readers can be duplicated).
 - Who is allowed to use the system?  (Approved users will need
      permissions to download rulesets to the meters, and to
      collect their data, possibly via their own meter readers).

7 Soundness

NeTraMet, the first implementation of the RTFM Architecture, has been in
use worldwide since 1994.  Currently there are many organisations, large
and small, using it to collect traffic data for billing purposes.

One example of these is Kawaihiko, the New Zealand Universities'
Network, which has seven RTFM meters located at sites throughout New
Zealand.  One of the sites is NZIX, the New Zealand Internet eXchange at
the University of Waikato, where Kawaihiko has a meter (attached to a
100baseT network) observing traffic flows across the exchange to each of
Kawaihiko's three international Internet Service Providers.  5-minute
Octet counts are collected from all the Kawaihiko meters by a single
meter reader at Auckland.  Traffic data from the meters is used to
determine the cost per month for each of the Kawaihiko sites.

It is difficult to estimate how many organisations are using RTFM
traffic measurement.  There are about 250 people on the NeTraMet mailing
list, which often carries questions like 'why doesn't this ruleset do
what I meant?'  Once new users have the system running, however, they
tend to simply use it without further comment.

>From time to time the list provides useful feedback.  For example, early
in 1998 there were two very significant user contributions:

 - Jacek Kowalski (Telstra, Melbourne) described an improved hash
      algorithm for NeTraMet's flow table, which provided almost an
      order of magnitude improvement in packet-handling performance.

 - Kevin Hoadley (JANET, U.K.) reported having problems with very
      large rulesets.  These were resolved, and better methods of
      downloading rules developed, allowing NeTraMet to work well
      for rulesets with more than 32,000 rules.

Perhaps one reason why there is little discussion of NeTraMet's use in
collecting billing data is that users may consider that the way collect
their data is a commercially sensitive matter.

We believe the fact that users are developing improvements to NeTraMet
and communicating them via the mailing list certainly demonstrates that
they are using it for real-world work!

Nevil Brownlee                                                  [Page 7]

INTERNET-DRAFT        RTFM: Applicability Statement       September 1998

8 Appendix A: WG Report on the Meter MIB

The Meter MIB (in its current form) was developed early in 1996.  It was
produced as an SNMPv2 MIB, following a number of detailed (and
continuing) discussions with David Perkins beginning at the Dallas IETF
meeting in December 1995.

There are two current implementations:

 - NeTraMet (Nevil Brownlee, The University of Auckland)

 - IBM Meter (Sig Handelman & Stephen Stibler, IBM Research, N.Y,
            Bert Wijnen provided further help with SNMP)

The NeTraMet meter is a stand-alone SNMP agent using an SNMPv2C
implementation derived from CMU SNMPv2.

The IBM meter runs as a sub-agent on an AIX system.  All the meter code
has been written by Stephen Stibler - it was not derived from the
NeTraMet code.  Stephen has found it useful to use nifty, one of
NeTraMet's manager/reader programs, to test the IBM meter.

As indicated above, there have only been two implementors to date, and
the Working Group consensus has been very strong.

The MIB has one unusual aspect:  the method used to read large amounts
of data from its Flow Table.  An earlier SNMPv1 version of the MIB was
in use from 1992 to 1997; it used opaque objects to read column slices
from the flow table for flows which had been active since a specified
time.  This was very non-standard (or at least very

With the change to SNMPv2 we were able to use 64-bit counters for PDUs
and Octets, RowStatus variables for control tables and GETBULK requests
to read rows from the flow table.  We also use the TimeFilter convention
from the RMON2 MIB to select flows to be read; this gives the meter MIB
a strong resemblance to RMON2.

The current MIB introduces a better way of reading large amounts of data
from the flow table.  This is the 'DataPackage' convention, which
specifies the attribute values to be read from a flow table row.  The
meter returns the values for each required attribute within a
BER-encoded sequence.  This means there is only one object identifier

Nevil Brownlee                                                  [Page 8]

INTERNET-DRAFT        RTFM: Applicability Statement       September 1998

for the whole sequence, greatly reducing the number of bytes required to
retrieve the data.  The combination of

  TimeFilter:  to select the flows to be read
  DataPackage: to select the attributes required for each flow
  GetBulk:     to read many flows with a single SNMP PDU

provides a very effective way to read flow data from a traffic meter.

9 References

    [1] Mills, C., Hirsch, G. and Ruth, G., "Internet Accounting
        Background", RFC 1272, Bolt Beranek and Newman Inc.,
        Meridian Technology Corporation, November 1991.

    [2] Brownlee, N., Mills, C., and Ruth, G., "Traffic Flow
        Measurement:  Architecture", RFC 2063, The University of
        Auckland, Bolt Beranek and Newman Inc., GTE Laboratories Inc,
        January 1997.

    [3] Brownlee, N., "Traffic Flow Measurement:  Meter MIB",
        RFC 2064, The University of Auckland, January 1997.

    [4] Brownlee, N., "SRL: A Language for Describing Traffic Flows
        and Specifying Actions for Flow Groups," Internet Draft,
        'Working draft' to become an Informational RFC,
        The University of Auckland.

    [5] Handelman, S.W., Brownlee, N., Ruth, G., Stibler, S.,
        "New  Attributes for Traffic Flow Measurment," Internet Draft,
        'Working draft' to become an Experimental RFC, IBM,
        The University of Auckland, GTE Laboratories Inc, IBM.

    [6] Brownlee, N., "Traffic Flow Measurement:  Experiences with
        NeTraMet," RFC 2123, The University of Auckland, March 1997.

10 Author's Address

    Nevil Brownlee
    Information Technology Systems & Services
    The University of Auckland

    Phone: +64 9 373 7599 x8941
    E-mail: n.brownlee@auckland.ac.nz

                                                      Expires March 1999

Nevil Brownlee                                                  [Page 9]