rfc2063.txt

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

   (and stored) at a meter can be regulated by changing the granularity
   of the accountable entity, the attributes, or the time intervals.
   Flows are like an adjustable pipe - many fine-granularity streams can
   carry the data with each stream measured individually, or data can be
   bundled in one coarse-granularity pipe.

   Flow granularity is controlled by adjusting the level of detail at
   which the following are reported:

  - The accountable entity (address attributes, discussed above).

  - The categorisation of packets (other attributes, discussed below).

  - The lifetime/duration of flows (the reporting interval needs to be
    short enough to measure them with sufficient precision).








Brownlee, et. al.             Experimental                     [Page 11]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   The set of rules controlling the determination of each packet's
   accountable entity is known as the meter's CURRENT RULE SET. As will
   be shown, the meter's current rule set forms an integral part of the
   reported information, i.e.  the recorded usage information cannot be
   properly interpreted without a definition of the rules used to
   collect that information.

   Settings for these granularity factors may vary from meter to meter.
   They are determined by the meter's current rule set, so they will
   change if network Operations personnel reconfigure the meter to use a
   new rule set.  It is expected that the collection rules will change
   rather infrequently; nonetheless, the rule set in effect at any time
   must be identifiable via a RULE SET ID. Granularity of accountable
   entities is further specified by additional ATTRIBUTES. These
   attributes include:

     - Meter variables such as the index of the flow's record in the flow
       table and the rule set id for the rules which the meter was running
       while the flow was observed.  The values of these attributes
       provide a way of distinguishing flows observed by a meter at
       different times.

     - Attributes which record information derived from other attribute
       values.  Six of these are defined (SourceClass, DestClass,
       FlowClass, SourceKind, DestKind, FlowKind), and their meaning is
       determined by the meter's rule set.  For example, one could have a
       subroutine in the rule set which determined whether a source or
       destination peer address was a member of an arbitrary list of
       networks, and set SourceClass/DestClass to one if the source/dest
       peer address was in the list or to zero otherwise.

     - Administratively specified attributes such as Quality Of Service
       and Priority, etc.  These are not defined at this time.

     - Higher-layer (especially application-level) attributes.  These are
       not defined at this time.

   Settings for these granularity factors may vary from meter to meter.
   They are determined by the meter's current rule set, so they will
   change if network Operations personnel reconfigure the meter to use a
   new rule set.

   The LIFETIME of a flow is the time interval which began when the
   meter observed the first packet belonging to the flow and ended when
   it saw the last packet.  Flow lifetimes are very variable, but many -
   if not most - are rather short.  A meter cannot measure lifetimes
   directly; instead a meter reader collects usage data for flows which
   have been active since the last collection, and an analysis



Brownlee, et. al.             Experimental                     [Page 12]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   application may compare the data from each collection so as to
   determine when each flow actually stopped.

   The meter does, however, need to reclaim memory (i.e.  records in the
   flow table) being held by idle flows.  The meter configuration
   includes a variable called InactivityTimeout, which specifies the
   minimum time a meter must wait before recovering the flow's record.
   In addition, before recovering a flow record the meter must be sure
   that the flow's data has been collected by at least one meter reader.

   These 'lifetime' issues are considered further in the section on
   meter readers (below).  A complete list of the attributes currently
   defined is given in Appendix C later in this document.

3.3 Rolling Counters, Timestamps, Report-in-One-Bucket-Only

   Once an usage record is sent, the decision needs to be made whether
   to clear any existing flow records or to maintain them and add to
   their counts when recording subsequent traffic on the same flow.  The
   second method, called rolling counters, is recommended and has
   several advantages.  Its primary advantage is that it provides
   greater reliability - the system can now often survive the loss of
   some usage records, such as might occur if a meter reader failed and
   later restarted.  The next usage record will very often contain yet
   another reading of many of the same flow buckets which were in the
   lost usage record.  The 'continuity' of data provided by rolling
   counters can also supply information used for "sanity" checks on the
   data itself, to guard against errors in calculations.

   The use of rolling counters does introduce a new problem:  how to
   distinguish a follow-on flow record from a new flow record.  Consider
   the following example.


                         CONTINUING FLOW        OLD FLOW, then NEW FLOW

                         start time = 1            start time = 1
   Usage record N:       flow count = 2000      flow count = 2000 (done)

                         start time = 1            start time = 5
   Usage record N+1:     flow count = 3000      new flow count = 1000

   Total count:                 3000                    3000


   In the continuing flow case, the same flow was reported when its
   count was 2000, and again at 3000:  the total count to date is 3000.
   In the OLD/NEW case, the old flow had a count of 2000.  Its record



Brownlee, et. al.             Experimental                     [Page 13]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   was then stopped (perhaps because of temporary idleness, or MAX
   LIFETIME policy), but then more traffic with the same characteristics
   arrived so a new flow record was started and it quickly reached a
   count of 1000.  The total flow count from both the old and new
   records is 3000.

   The flow START TIMESTAMP attribute is sufficient to resolve this.  In
   the example above, the CONTINUING FLOW flow record in the second
   usage record has an old FLOW START timestamp, while the NEW FLOW
   contains a recent FLOW START timestamp.

   Each packet is counted in one and only one flow, so as to avoid
   multiple counting of a single packet.  The record of a single flow is
   informally called a "bucket." If multiple, sometimes overlapping,
   records of usage information are required (aggregate, individual,
   etc), the network manager should collect the counts in sufficiently
   detailed granularity so that aggregate and combination counts can be
   reconstructed in post-processing of the raw usage data.

   For example, consider a meter from which it is required to record
   both 'total packets coming in interface #1' and 'total packets
   arriving from any interface sourced by IP address = a.b.c.d.'
   Although a bucket can be declared for each case, it is not clear how
   to handle a packet which satisfies both criteria.  It must only be
   counted once.  By default it will be counted in the first bucket for
   which it qualifies, and not in the other bucket.  Further, it is not
   possible to reconstruct this information by post-processing.  The
   solution in this case is to define not two, but THREE buckets, each
   one collecting a unique combination of the two criteria:

        Bucket 1:  Packets which came in interface 1,
                   AND were sourced by IP address a.b.c.d

        Bucket 2:  Packets which came in interface 1,
                   AND were NOT sourced by IP address a.b.c.d

        Bucket 3:  Packets which did NOT come in interface 1,
                   AND were sourced by IP address a.b.c.d

       (Bucket 4:  Packets which did NOT come in interface 1,
                   AND NOT sourced by IP address a.b.c.d)

   The desired information can now be reconstructed by post-processing.
   "Total packets coming in interface 1" can be found by adding buckets
   1 & 2, and "Total packets sourced by IP address a.b.c.d" can be found
   by adding buckets 1 & 3.  Note that in this case bucket 4 is not
   explicitly required since its information is not of interest, but it
   is supplied here in parentheses for completeness.



Brownlee, et. al.             Experimental                     [Page 14]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


4 Meters

   A traffic flow meter is a device for collecting data about traffic
   flows at a given point within a network; we will call this the
   METERING POINT.  The header of every packet passing the network
   metering point is offered to the traffic meter program.

   A meter could be implemented in various ways, including:

  - A dedicated small host, connected to a LAN (so that it can see all
    packets as they pass by) and running a 'traffic meter' program.
    The metering point is the LAN segment to which the meter is
    attached.

  - A multiprocessing system with one or more network interfaces, with
    drivers enabling a traffic meter program to see packets.  In this
    case the system provides multiple metering points - traffic flows
    on any subset of its network interfaces can be measured.

  - A packet-forwarding device such as a router or switch.  This is
    similar to (b) except that every received packet should also be
    forwarded, usually on a different interface.

   The discussion in the following sections assumes that a meter may
   only run a single rule set.  It is, however, possible for a meter to
   run several rule sets concurrently, matching each packet against
   every active rule set and producing a single flow table with flows
   from all the active rule sets.  The overall effect of doing this
   would be similar to running several independent meters, one for each
   rule set.

4.1 Meter Structure

   An outline of the meter's structure is given in the following
   diagram.

   Briefly, the meter works as follows:

  - Incoming packet headers arrive at the top left of the diagram and
    are passed to the PACKET PROCESSOR.

  - The packet processor passes them to the Packet Matching Engine
    (PME) where they are classified.

  - The PME is a Virtual Machine running a pattern matching program
    contained in the CURRENT RULE SET. It is invoked by the Packet
    Processor, and returns instructions on what to do with the packet.




Brownlee, et. al.             Experimental                     [Page 15]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


  - Some packets are classified as 'to be ignored.'  They are discarded
    by the Packet Processor.

  - Other packets are matched by the PME, which returns a FLOW KEY
    describing the flow to which the packet belongs.

  - The flow key is used to locate the flow's entry in the FLOW TABLE;
    a new entry is created when a flow is first seen.  The entry's
    packet and byte counters are updated.

  - A meter reader may collect data from the flow table at any time.
    It may use the 'collect' index to locate the flows to be collected
    within the flow table.



                  packet                +------------------+
                  header                | Current Rule Set |
                    |                   +--------+---------+
                    |                            |
           +--------*---------+       +----------*-------------+
           | Packet Processor |<----->| Packet Matching Engine |
           +--+------------+--+       +------------------------+
              |            |
       Ignore *            | Count via flow key
                           |
                        +--*--------------+
                        | 'Search' index  |
                        +--------+--------+
                                 |
                        +--------*--------+
                        |                 |
                        |   Flow Table    |
                        |                 |
                        +--------+--------+
                                 |
                        +--------*--------+
                        | 'Collect' index |
                        +--------+--------+
                                 |
                                 *
                            Meter Reader