rfc2123.txt

RFC 的详细文档！

   interest.  If there are PushRule rules which test SourcePeerType (or
   DestPeerType), they specify which types are of interest.  If there
   are no such rules, every packet type is of interest.  The PC NeTraMet
   has a set of Boolean variables, one for each protocol it can handle.
   The values of these 'protocol' variables are determined when the
   meter begins running a new rule set.  For each incoming packet, the
   interrupt handler determines the Peer type.  If the protocol is not
   of interest, no further processing is done - the packet is simply
   ignored.  In a similar manner, if Adjacent addresses are never tested
   there is no point in copying them into the packet buffer slot.

   The overall effect of these optimisations is most noticeable for rule
   files which measure IP flows on a network segment which also carries
   a lot of traffic for other network protocols; this situation is
   common on multiprotocol Local Area networks.  On the Unix version of
   NeTraMet the Operating System does all the packet interrupt
   processing, and libpcap [8] delivers packet headers directly to
   NeTraMet.  The 'protocol' and 'adjacent address' optimisations are
   still performed, at the point when NeTraMet receives the packet
   headers from libpcap.

2.3.6 Observing meter reader activity

   The Architecture document [1] explains that a flow data record must
   be held in the meter until its data has been read by a meter reader.
   A meter must therefore have a reliable way of deciding when flow data
   has been read.  The problem is complicated by the fact that there may
   be more than one meter reader, and that meter readers collect their
   data asynchronously.












Brownlee                     Informational                     [Page 11]

RFC 2123                Traffic Flow Measurement              March 1997


   Early versions of NeTraMet solved this problem by having a single MIB
   variable which a meter reader could set to indicate that it was
   beginning a data collection.  In response to such an SNMP SET
   request, NeTraMet would update its 'collectors' table.  This had an
   entry for each meter reader, and variables recording the start time
   for the last two collections.  The most recent collection might still
   be in progress, but its start time provides a safe estimate of the
   time when the one before it actually finished.  Space used for flows
   which have been idle since the penultimate collection started can be
   recovered by the meter's garbage collector, as described below.

   The Meter MIB [2] specifies a more general table of meter reader
   information.  A meter reader wishing to collect data from a meter
   must inform the meter of its intention by creating a row in the
   table, then setting a LastTime variable in that row to indicate the
   start of a collection.  The meter handles such a SET request exactly
   as described above.  If there are multiple meter readers the meter
   can easily find the earliest time any of them started its penultimate
   collection, and may recover flows idle since then.  Should a meter
   reader fail, NeTraMet will eventually time out its entry in the meter
   reader info table, and delete it.  This avoids a situation where the
   meter can't recover flows until they have been collected by several
   meter readers, one of which has failed.

2.3.7 Meter memory management

   In principle, the size of the flow table (i.e. the maximum number of
   flows) could be changed dynamically.  This would involve allocating
   space for the flow table's new pointer array and copying the old
   pointers into it.  NeTraMet does not implement this.  Instead the
   maximum number of flows is set from the command line when it starts
   execution.  If no maximum is specified, a compile-time default number
   is used.

   Memory for flow data structures (i.e. 'flows') is allocated
   dynamically.  NeTraMet requests the C run-time system for blocks of
   several hundred flows, and links them into a free list.  When a new
   flow is needed NeTraMet gets memory space from the free list, then
   searches the flow table's pointer array for an unused flow pointer.
   In practice a 'last-allocated' index is used to point to the flow
   table, so a simple linear search suffices.  The flow index is saved
   in the flow's data record, and its other attribute values are set to
   zero.








Brownlee                     Informational                     [Page 12]

RFC 2123                Traffic Flow Measurement              March 1997


   To release a flow data record it must first be removed from any hash
   list it is part of - this is straightforward since those lists are
   circular.  The flow's entry in the flow table pointer array is then
   set to zero (NULL pointer), and its space is returned to the free
   list.

   Once a flow data record is created it could continue to exist
   indefinitely.  In time, however, the meter would run out of space.
   To deal with this problem NeTraMet uses an incremental garbage
   collector to reclaim memory.

   At regular intervals specified by a 'GarbageCollectInterval' variable
   the garbage collector procedure is invoked.  This searches through
   the flow table looking for flows which might be recovered.  To
   control the resources consumed by garbage collection there are limits
   on the number of in-use and idle flows which the garbage collector
   may inspect  these are set either when NeTraMet is started (as
   options on the command line) or dynamically by NeMaC (using variables
   in an Enterprise MIB for NeTraMet)

   To decide whether a flow can be recovered, the garbage collector
   considers how long it has been idle (no packets in either direction),
   and when its data was last collected.  If it has been collected by
   all known meter readers since its LastTime, its memory may be
   recovered.  This alogrithm is implemented using a variable called
   'GarbageCollectTime,' which normally contains the meter's UpTime when
   the penultimate collection (i.e. the one before last) was started.
   See the section on observing meter reader activity (above) for more
   details.

   Should flows not be collected often enough the meter could run out of
   space.  NeTraMet attempts to prevent this by having a low-priority
   background process check the percentage of flows active and compare
   it with the HighWaterMark MIB variable.  If the percentage of active
   flows is greater than the high-water mark, 'GarbageCollectTime' is
   incremented by the current value of the InactivityTimeout MIB
   variable.

   The Meter MIB [2] specifies that a meter should switch to using a
   'standby' rule set if the percentage of active flows rises above
   HighWaterMark.  In using NeTraMet to measure traffic flows to and
   from the University of Auckland it has not been difficult to create
   standby rules which are very similar to the 'production' rule file,
   differing only in that they push much less information about flows.
   This has, on several occasions, allowed the meter to continue running
   for one or two days after the meter reader failed.  When the meter
   reader restarted, it was able to collect all the accumulated flow
   data!



Brownlee                     Informational                     [Page 13]

RFC 2123                Traffic Flow Measurement              March 1997


   The MIB also specifies that the meter should take some action when
   the active flow percentage rises above its FloodMark value.  If this
   were not done, the meter could spend a rapidly increasing proportion
   of its time garbage collecting, to the point where its ability to
   respond to requests from its manager would be compromised.  NeTraMet
   switches to the default rule set when its FloodMark is reached.

   A potentially large number of new flows may be created when the meter
   switches to a standby rule set.  It is important to set a
   HighWaterMark so as to allow enough flow table space for this.  In
   practice, a HighWaterMark of 65% and a FloodMark of 95% seem to work
   well.

2.4 Data collection

   As explained above, a meter reader wishing to collect flows begins
   each collection by setting the LastTime variable in its
   ReaderInfoTable row, then works its way through the flow table
   collecting data.  A number of algorithms can be used to examine the
   flow table; these are presented below.

   The simplest approach is a linear scan of the table, reading the
   LastTime variable for each row.  If the read fails the row is
   inactive.  If it succeeds, it is of interest if its LastTime value is
   greater than the time of the last collection.  Although this method
   is simple it is also rather slow, requiring an SNMP GET request for
   every possible flow; this renders it impractical.

   Early versions of NeTraMet used two 'windows' into the flow table to
   find flows which were of interest.  Both windows were SNMP tables,
   indexed by a variable which specified a time.  A succession of
   GETNEXT requests on one of these windows allowed NeMaC (the meter
   reader) to find the flow indices for all flows which had been active
   since the specified time.  The two windows were the ActivityTime
   window (which located active flows), and the CreateTime window (which
   located new flows).  Knowing the index of an active flow, the meter
   reader can GET the values for all the attributes of interest.  NeMaC
   allows the user to specify which these are, rather than simply read
   all the attributes.

   Having the two windows allowed NeMaC to read attributes which remain
   constant - such as the flow's address attributes - when the flow is
   created, but to only read attributes which change with time - such as
   its packet and byte counts - during later collections.  Experience
   has shown, however, that many flows have rather short lifetimes; one
   effect of this is that the improved efficiency of using two windows
   does not result in any worthwhile improvement in collection
   performance.



Brownlee                     Informational                     [Page 14]

RFC 2123                Traffic Flow Measurement              March 1997


   The current version of the Meter MIB [2] uses a TimeFilter variable
   in the flow table entries.  This can be used with GETNEXT requests to
   find all flows which have been active since a specified time
   directly, without requiring the extra 'window' SNMP variables.  It
   can be combined with SNMPv2's GETBULK request to further reduce the
   number of SNMP packets needed for each collection; I have yet to
   implement this in NeTraMet.

   A disadvantage of using SNMP to collect data from the meter is that
   SNMP packets impose a high overhead.  For example, if we wish to read
   an Integer32 variable (four bytes of data), it will be returned with
   its object identifier, type and length, i.e. at least ten bytes of
   superfluous data.  One way to reduce this overhead is to use an
   Opaque object to return a collection of data.  NeTraMet uses this
   approach to retrieve 'column activity data' from the meter, as
   follows.

   Each packet of column activity data contains data values for a
   specified attribute, and each value is preceded by its flow number.
   The flow table can be regarded as a two-dimensional array, with a
   column for each flow attribute.  Column activity data objects allow
   the meter reader to read columns of the flow table, so as to collect
   only those attributes specified by the user.  The actual
   implementation is complicated by the fact that since the flow table
   is read column by column, rows can become active after the first
   column has been read.  NeMaC reads the widest columns (those with
   greatest size in bytes, e.g. PeerAddress) first, and ignores any rows
   which appear in later columns.  Newly active rows will, of course, be
   read in the next collection.

   Using Opaque objects in this way dramatically reduces the number of
   SNMP packets required to read a meter.  This has proved worthwhile in
   situations where the number of flows is large (for example on busy
   LANs), and where the meter(s) are physically dispersed over slow WAN
   links.  It has the disadvantage that general-purpose MIB browsers
   cannot understand the column activity variables, but this seems a
   small price to pay for the improved data collection performance.

2.5 Restarting a meter

   If a meter fails, for example because of a power failure, it will
   restart and begin running rule set 1, the default rule set which is
   built into the meter.  Its manager must recognise that this has
   happened, and respond with some suitable action.

   NeMaC allows the user to specify a 'keepalive' interval.  After every
   such interval NeMaC reads the meter's sysUptime and compares it with
   the last sysUptime.  If the new sysUptime is less than the last one,



Brownlee                     Informational                     [Page 15]

RFC 2123                Traffic Flow Measurement              March 1997


   NeMaC decides that the meter has restarted.  It downloads the meter's
   backup rule set and production rule set, then requests the meter to
   start running the production rule set.  In normal use we use a
   keepalive interval of five minutes and a collection interval of 15
   minutes.  If a meter restarts, we lose up to five minutes data before
   the rules sets are downloaded.

   Having the meter run the default rule set on startup is part of the
   Traffic Flow Measurement Architecture [1], in keeping with the notion
   that meters are very simple devices which do not have disk storage.
   Since disks are now very cheap, it may be worth considering whether
   the architecture should allow a meter to save its configuration
   (including rule sets) on disk.

2.6 Performance

   The PC version of the meter, NeTraMet, continually measures how much
   processor time is being used.  Whenever there is no incoming packet