rfc2724.txt

RFC 的详细文档！

   These distribution parameters will need to be stored in the meter so
   that they are available for building the distribution.  They will
   also need to be read from the meter and saved together with the other
   flow data.

3.3  Reading Distributions

   Since RTFM flows are bi-directional, each distribution-valued
   quantity (e.g. packet size, bit rate, etc.)  will actually need two
   sets of counters, one for packets travelling in each direction.  It
   is tempting to regard these as components of a single 'distribution',
   but in many cases only one of the two directions will be of interest;
   it seems better to keep them in separate distributions.  This is
   similar to the old-style counter-valued attributes such as toOctets
   and fromOctets.

   A distribution should be read by a meter reader as a single,
   structured object.  The components of a distribution object are:

      -  'mask' and 'value' fields from the rule which created the
         distribution

      -  sequence of counters ('buckets' + overflow)

   These can be easily collected into a BER-encoded octet string, and
   would be read and referred to as a 'distribution'.

4  Extensions to the Rules Table, Attribute Numbers

   The Rules Table of "old-style" attributes will be extended for the
   new flow types.  A list of actions, and keywords, such as
   "ToBitRate", "ToPacketSize", etc.  will be developed and used to
   inform an RTFM meter to collect a set of extended values for a
   particular flow (or set of flows).

   Note:  An implementation suggestion.

      Value 65 is used for 'Distributions', which has one bit set for
      each distribution-valued attribute present for the flow, using bit
      0 for attribute 66, bit 1 for attribute 67, etc.

   Here are ten possible distribution-valued attributes numbered
   according to RTFM WG consensus at the 1997 meeting in Munich:

      ToPacketSize(66)         size of PDUs in bytes (i.e. number
      FromPacketSize(67)         of bytes actually transmitted)





Handelman, et al.             Experimental                     [Page 13]

RFC 2724                  RTFM: New Attributes              October 1999


      ToInterarrivalTime(68)   microseconds between successive packets
      FromInterarrivalTime(69)   travelling in the same direction

      ToTurnaroundTime(70)     microseconds between successive packets
      FromTurnaroundTime(71)     travelling in opposite directions

      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

      (76 .. 97)               other distributions

   It seems reasonable to allocate a further group of numbers for the
   IIS attributes described above:

      QoSService(98)
      QoSStyle(99)
      QoSRate(100)
      QoSSlackTerm(101)
      QoSTokenBucketRate(102)
      QoSTokenBucketSize(103)
      QoSPeakDataRate(104)
      QoSMinPolicedUnit(105)
      QoSMaxPolicedUnit(106)

   The following attributes have also been implemented in NetFlowMet, a
   version of the RTFM traffic meter:

      MeterID(112)      Integer identifying the router producing
                           NetFlow data (needed when NetFlowMet takes
                           data from several routers)
      SourceASN(113)    Autonomous System Number for flow's source
      SourcePrefix(114) CIDR width used by router for determining
                           flow's source network
      DestASN(115)      Autonomous System Number for flow's destination
      DestPrefix(116)   CIDR width used by router for determining
                           flow's destination network

   Some of the above, e.g. SourceASN and DestASN, might sensibly be
   allocated attribute numbers below 64, making them part of the 'base'
   RTFM meter attributes.








Handelman, et al.             Experimental                     [Page 14]

RFC 2724                  RTFM: New Attributes              October 1999


   To support use of the RTFM meter as an 'Edge Device' for implementing
   Differentiated Services, and/or for metering traffic carried via such
   services, one more attribute will be useful:

      DSCodePoint(118)  DS Code Point (6 bits) for packets in this flow

   Since the DS Code Point is a single field within a packet's IP
   header, it is not possible to have both Source- and Dest-CodePoint
   attributes.  Possible uses of DSCodePoint include aggregating flows
   using the same Code Points, and separating flows having the same
   end-point addresses but using different Code Points.

5  Security Considerations

   The attributes considered in this document represent properties of
   traffic flows; they do not present any security issues in themselves.
   The attributes may, however, be used in measuring the behaviour of
   traffic flows, and the collected traffic flow data could be of
   considerable value.  Suitable precautions should be taken to keep
   such data safe.































Handelman, et al.             Experimental                     [Page 15]

RFC 2724                  RTFM: New Attributes              October 1999


6  References

   [C-B-P]     Claffy, K., Braun, H-W, Polyzos, G., "A Parameterizable
               Methodology for Internet Traffic Flow Profiling," IEEE
               Journal on Selected Areas in Communications, Vol. 13, No.
               8, October 1995.

   [GUAR-QOS]  Shenker, S., Partridge, C. and R. Guerin, "Specification
               of Guaranteed Quality of Service", RFC 2212, September
               1997.

   [IIS-ACCT]  Maiocchi, S: "NeTraMet & NeMaC for IIS Accounting:
               Users' Guide", CEFRIEL, Milan, 5 May 1998.  (See also
               http://www.cefriel.it/ntw)

   [IIS-RSVP]  Wroclawski, J., "The Use of RSVP with IETF Integrated
               Services", RFC 2210, September 1997.

   [IPPM-FRM]  Paxson, V., Almes, G., Mahdavi, J. and  Mathis, M.,
               "Framework for IP Performance Metrics", RFC 2330, May
               1998.

   [RMON-MIB]  Waldbusser, S., "Remote Network Monitoring Management
               Information Base", RFC 1757, February 1995.

   [RMON2-MIB] Waldbusser, S., "Remote Network Monitoring Management
               Information Base Version 2 using SMIv2", RFC 2021,
               January 1997.

   [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.

















Handelman, et al.             Experimental                     [Page 16]

RFC 2724                  RTFM: New Attributes              October 1999


7  Authors' Addresses

   Sig Handelman
   IBM Research Division
   T.J. Watson Research Center
   P.O. Box 704
   Yorktown Heights, NY 10598

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


   Stephen Stibler
   IBM Research Division
   T.J. Watson Research Center
   P.O. Box 704
   Yorktown Heights, NY 10598

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


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

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


   Greg Ruth
   GTE Internteworking
   3 Van de Graaff Drive
   P.O. Box 3073
   Burlington, MA 01803, U.S.A.

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











Handelman, et al.             Experimental                     [Page 17]

RFC 2724                  RTFM: New Attributes              October 1999


8.  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.



















Handelman, et al.             Experimental                     [Page 18]