rfc2721.txt

RFC 的详细文档！

Network Working Group                                        N. Brownlee
Request for Comments: 2721                    The University of Auckland
Category: Informational                                     October 1999


                     RTFM: Applicability Statement

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

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

Table of Contents

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















Brownlee                     Informational                      [Page 1]

RFC 2721             RTFM: Applicability Statement          October 1999


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, as follows:

   [ACT-BKG] 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).

   [RTFM-ARC] 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.

   [RTFM-MIB] 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.

   [RTFM-SRL] SRL: A Language for Describing Traffic     (Informational)
              Flows 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.







Brownlee                     Informational                      [Page 2]

RFC 2721             RTFM: Applicability Statement          October 1999


   [RTFM-NEW] 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.

   [RTFM-NTM] 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

   RTFM provides high time resolution for flow first- and last-packet
   times.  Counters for long-duration flows may be read at intervals
   determined by a manager.  The RTFM Meter is designed so as to do as
   much data reduction work as possible, which 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.




Brownlee                     Informational                      [Page 3]

RFC 2721             RTFM: Applicability Statement          October 1999


   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 host, communicating with
   meters and meter readers via the network.  For this purpose meters
   are SNMP agents implementing the RTFM Meter MIB, and managers are
   SNMP clients using the Meter MIB to store and access the flow data.

4  Limitations

   RTFM is designed to measure traffic flows for traffic passing a point
   in a network.  If packets for a flow pass the metering point in both
   directions the meter will match them up, providing counters for each
   direction.  If packets only pass in one direction the meter can only
   provide counts for that direction.

   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 very
   large amount of data may be produced rapidly, 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



Brownlee                     Informational                      [Page 4]

RFC 2721             RTFM: Applicability Statement          October 1999


   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 ought to provide some
   measures of its own performance (e.g. number of active flows,
   percentage idle processor time, packets metered, packets not
   metered).  Such measures will be implementation-specific, but should
   allow a user 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
     workstation, or perhaps use a meter implemented in firmware within
     a switch or router.

   - use sampling.  The details of such sampling are not defined within
     the RTFM Architecture, but the Meter MIB provides one simple method
     by allowing 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 purposes.

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 it.  Since it doesn't control the
   network directly, it has no direct effect on network security.

   On the other hand, the flow data itself 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.






Brownlee                     Informational                      [Page 5]