rfc2721.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


RFC 2721             RTFM: Applicability Statement          October 1999


   Meters may, like any other network component, be subjected to Denial
   of Service and other attacks.  These are outside the RTFM
   Architecture - countermeasures for them are available, but are also
   outside RTFM.

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 implies longer collection intervals, but that may
     require more memory in the meters to hold flow data between
     collections).

   - 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



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


   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.

























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


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
   application-specific).

   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 for the whole sequence, greatly reducing the number of
   bytes required to retrieve the data.  The combination of






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


   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

   [ACT-BKG]  Mills, C., Hirsch, G. and G. Ruth, "Internet Accounting
              Background", RFC 1272, November 1991.

   [RTFM-ARC] Brownlee, N., Mills, C. and G. Ruth, "Traffic Flow
              Measurement: Architecture", RFC 2722, October 1999.

   [RTFM-MIB] Brownlee, N., "Traffic Flow Measurement: Meter MIB", RFC
              2720, October 1999.

   [RTFM-NEW] Handelman, S., Stibler, S., Brownlee, N. and G. Ruth,
              "RTFM: New Attributes for Traffic Flow Measurement", RFC
              2724, October 1999.

   [RTFM-NTM] Brownlee, N., "Traffic Flow Measurement: Experiences with
              NeTraMet", RFC 2123, March 1997.

   [RTFM-SRL] Brownlee, N., "SRL: A Language for Describing Traffic
              Flows and Specifying Actions for Flow Groups", RFC 2723,
              October 1999.

10  Author's Address

   Nevil Brownlee
   Information Technology Systems & Services
   The University of Auckland
   Private Bag 92-019
   Auckland, New Zealand

   Phone: [phone] x8941
   EMail: [e-mail]













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


11  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Brownlee                     Informational                     [Page 10]