rfc2722.txt

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

   is supplied here in parentheses for completeness.

   Alternatively, the above could be achieved by running two rule sets
   (A and B), as follows:

           Bucket 1:  Packets which came in interface 1;
                      counted by rule set A.





Brownlee, et al.             Informational                     [Page 16]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999


           Bucket 2:  Packets which were sourced by IP address a.b.c.d;
                      counted by rule set B.

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

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, executes the rules in the current rule set as
       described in section 4.3 below, and returns instructions on what
       to do with the packet.

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




Brownlee, et al.             Informational                     [Page 17]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999


     - 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 data fields (e.g. 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 |
                     |                        +--------+---------+
                     |                                 |
                     |                                 |
             +-------*--------+    'match key'  +------*-------+
             |    Packet      |---------------->|    Packet    |
             |   Processor    |                 |   Matching   |
             |                |<----------------|    Engine    |
             +--+----------+--+  'flow key'     +--------------+
                |          |
                |          |
         Ignore *          | Count (via 'flow key')
                           |
                        +--*--------------+
                        | 'Search' index  |
                        +--------+--------+
                                 |
                        +--------*--------+
                        |                 |
                        |   Flow Table    |
                        |                 |
                        +--------+--------+
                                 |
                        +--------*--------+
                        | 'Collect' index |
                        +--------+--------+
                                 |
                                 *
                            Meter Reader

   The discussion above assumes that a meter will only be running a
   single rule set.  A meter may, however, run several rule sets
   concurrently.  To do this the meter maintains a table of current
   rulesets.  The packet processor matches each packet against every




Brownlee, et al.             Informational                     [Page 18]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999


   current ruleset, producing a single flow table containing flows from
   all the rule sets.  One way to implement this is to use the Rule Set
   Number attribute in each flow as part of the flow key.

   A packet may only be counted once in a rule set (as explained in
   section 3.3 above), but it may be counted in any of the current
   rulesets.  The overall effect of doing this is somewhat similar to
   running several independent meters, one for each rule set.

4.2  Flow Table

   Every traffic meter maintains 'flow table', i.e. a table of TRAFFIC
   FLOW RECORDS for flows seen by the meter.  Details of how the flow
   table is maintained are given in section 4.5 below.  A flow record
   contains attribute values for its flow, including:

     - Addresses for the flow's source and destination.  These include
       addresses and masks for various network layers (extracted from
       the packet header), and the identity of the interface on which
       the packet was observed.

     - First and last times when packets were seen for this flow.

     - Counts for 'forward' (source to destination) and 'backward'
       (destination to source) components of the flow's traffic.

     - Other attributes, e.g. state of the flow record (discussed
       below).

   The state of a flow record may be:

     - INACTIVE: The flow record is not being used by the meter.

     - CURRENT: The record is in use and describes a flow which belongs
       to the 'current flow set', i.e. the set of flows recently seen by
       the meter.

     - IDLE: The record is in use and the flow which it describes is
       part of the current flow set.  In addition, no packets belonging
       to this flow have been seen for a period specified by the meter's
       InactivityTime variable.










Brownlee, et al.             Informational                     [Page 19]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999


4.3  Packet Handling, Packet Matching

   Each packet header received by the traffic meter program is processed
   as follows:

     - Extract attribute values from the packet header and use them to
       create a MATCH KEY for the packet.

     - Match the packet's key against the current rule set, as explained
       in detail below.

   The rule set specifies whether the packet is to be counted or
   ignored.  If it is to be counted the matching process produces a FLOW
   KEY for the flow to which the packet belongs.  This flow key is used
   to find the flow's record in the flow table; if a record does not yet
   exist for this flow, a new flow record may be created.  The data for
   the matching flow record can then be updated.

   For example, the rule set could specify that packets to or from any
   host in IP network 130.216 are to be counted.  It could also specify
   that flow records are to be created for every pair of 24-bit (Class
   C) subnets within network 130.216.

   Each packet's match key is passed to the meter's PATTERN MATCHING
   ENGINE (PME) for matching.  The PME is a Virtual Machine which uses a
   set of instructions called RULES, i.e. a RULE SET is a program for
   the PME. A packet's match key contains source (S) and destination (D)
   interface identities, address values and masks.

   If measured flows were unidirectional, i.e. only counted packets
   travelling in one direction, the matching process would be simple.
   The PME would be called once to match the packet.  Any flow key
   produced by a successful match would be used to find the flow's
   record in the flow table, and that flow's counters would be updated.

   Flows are, however, bidirectional, reflecting the forward and reverse
   packets of a protocol interchange or 'session'.  Maintaining two sets
   of counters in the meter's flow record makes the resulting flow data
   much simpler to handle, since analysis programs do not have to gather
   together the 'forward' and 'reverse' components of sessions.
   Implementing bi-directional flows is, of course, more difficult for
   the meter, since it must decide whether a packet is a 'forward'
   packet or a 'reverse' one.  To make this decision the meter will
   often need to invoke the PME twice, once for each possible packet
   direction.






Brownlee, et al.             Informational                     [Page 20]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999


   The diagram below describes the algorithm used by the traffic meter
   to process each packet.  Flow through the diagram is from left to
   right and top to bottom, i.e. from the top left corner to the bottom
   right corner.  S indicates the flow's source address (i.e. its set of
   source address attribute values) from the packet header, and D
   indicates its destination address.

   There are several cases to consider.  These are:

     - The packet is recognised as one which is TO BE IGNORED.

     - The packet would MATCH IN EITHER DIRECTION.  One situation in
       which this could happen would be a rule set which matches flows
       within network X (Source = X, Dest = X) but specifies that flows
       are to be created for each subnet within network X, say subnets y
       and z.  If, for example a packet is seen for y->z, the meter must
       check that flow z->y is not already current before creating y->z.

     - The packet MATCHES IN ONE DIRECTION ONLY.  If its flow is already
       current, its forward or reverse counters are incremented.
       Otherwise it is added to the flow table and then counted.

                   Ignore
   --- match(S->D) -------------------------------------------------+
        | Suc   | NoMatch                                           |
        |       |          Ignore                                   |
        |      match(D->S) -----------------------------------------+
        |       | Suc   | NoMatch                                   |
        |       |       |                                           |
        |       |       +-------------------------------------------+
        |       |                                                   |
        |       |             Suc                                   |
        |      current(D->S) ---------- count(D->S,r) --------------+
        |       | Fail                                              |
        |       |                                                   |
        |      create(D->S) ----------- count(D->S,r) --------------+
        |                                                           |
        |             Suc                                           |
       current(S->D) ------------------ count(S->D,f) --------------+
        | Fail                                                      |
        |             Suc                                           |
       current(D->S) ------------------ count(D->S,r) --------------+
        | Fail                                                      |
        |                                                           |
       create(S->D) ------------------- count(S->D,f) --------------+
                                                                    |
                                                                    *




Brownlee, et al.             Informational                     [Page 21]

RFC 2722         Traffic Flow Measurement: Architecture     October 1999