rfc2063.txt

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

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


4.2 Flow Table

   Every traffic meter maintains a table of TRAFFIC FLOW RECORDS for
   flows seen by the meter.  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), and the number 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.

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 counts
   for the matching flow record can then be incremented.



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


   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 an interface number, source
   address (S) and destination address (D) values.  It does not,
   however, contain any attribute masks for its attributes, only their
   values.

   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.

   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, 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 MATCHES IN BOTH DIRECTIONS. 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.




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


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

   The algorithm uses four functions, as follows:

match(A->B) implements the PME.  It uses the meter's current rule set
   to match the attribute values in the packet's match key.  A->B means
   that the assumed source address is A and destination address B, i.e.
   that the packet was travelling from A to B.  match() returns one of
   three results:

   'Ignore' means that the packet was matched but this flow is not
            to be counted.

   'Fail' means that the packet did not match.  It might, however
            match with its direction reversed, i.e. from B to A.

   'Suc'  means that the packet did match, i.e. it belongs to a flow
            which is to be counted.

current(A->B) succeeds if the flow A-to-B is current - i.e. has
   a record in the flow table whose state is Current - and fails
   otherwise.

create(A->B) adds the flow A-to-B to the flow table, setting the
   value for attributes - such as addresses - which remain constant,
   and zeroing the flow's counters.

count(A->B,f) increments the 'forward' counters for flow A-to-B.
count(A->B,r) increments the 'reverse' counters for flow A-to-B.
   'Forward' here means the counters for packets travelling from
   A to B.  Note that count(A->B,f) is identical to count(B->A,r).


















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


                    Ignore
    --- match(S->D) -------------------------------------------------+
         | Suc   | Fail                                              |
         |       |          Ignore                                   |
         |      match(D->S) -----------------------------------------+
         |       | Suc   | Fail                                      |
         |       |       |                                           |
         |       |       +-------------------------------------------+
         |       |                                                   |
         |       |             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) --------------+
                                                                     |
                                                                     *

   When writing rule sets one must remember that the meter will normally
   try to match each packet in both directions.  It is particularly
   important that the rule set does not contain inconsistencies which
   will upset this process.

   Consider, for example, a rule set which counts packets from source
   network A to destination network B, but which ignores packets from
   source network B. This is an obvious example of an inconsistent rule
   set, since packets from network B should be counted as reverse
   packets for the A-to-B flow.

   This problem could be avoided by devising a language for specifying
   rule files and writing a compiler for it, thus making it much easier
   to produce correct rule sets.  Another approach would be to write a
   'rule set consistency checker' program, which could detect problems
   in hand-written rule sets.

   In the short term the best way to avoid these problems is to write
   rule sets which only clasify flows in the forward direction, and rely
   on the meter to handle reverse-travelling packets.





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


4.4 Rules and Rule Sets

   A rule set is an array of rules.  Rule sets are held within a meter
   as entries in an array of rule sets.  One member of this array is the
   CURRENT RULE SET, in that it is the one which is currently being used
   by the meter to classify incoming packets.

   Rule set 1 is built in to the meter and cannot be changed.  It is run
   when the meter is started up, and provides a very coarse reporting
   granularity; it is mainly useful for verifying that the meter is
   running, before a 'useful' rule set is downloaded to it.

   If the meter is instructed to use rule set 0, it will cease
   measuring; all packets will be ignored until another (non-zero) rule
   set is made current.

   Each rule in a rule set is structured as follows:


   +-------- test ---------+    +---- action -----+
   attribute & mask = value:    opcode,  parameter;


   Opcodes contain two flags:  'goto' and 'test.'  The PME maintains a
   Boolean indicator called the 'test indicator,' which is initially set
   (on).  Execution begins with rule 1, the first in the rule set.  It
   proceeds as follows:

   If the test indicator is on:
      Perform the test, i.e. AND the attribute value with the
         mask and compare it with the value.
      If these are equal the test has succeeded; perform the
         rule's action (below).
      If the test fails execute the next rule in the rule set.
      If there are no more rules in the rule set, return from the
         match() function indicating failure.

   If the test indicator is off, or the test (above) succeeded:
      Set the test indicator to this rule's test flag value.
      Determine the next rule to execute.
         If the opcode has its goto flag set, its parameter value
            specifies the number of the next rule.
         Opcodes which don't have their goto flags set either
            determine the next rule in special ways (Return),
            or they terminate execution (Ignore, Fail, Count,
            CountPkt).
      Perform the action.




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


   The PME maintains two 'history' data structures.  The first, the
   'return' stack, simply records the index (i.e.  1-origin rule number)
   of each Gosub rule as it is executed; Return rules pop their Gosub
   rule index.  The second, the 'pattern' queue, is used to save
   information for later use in building a flow key.  A flow key is
   built by zeroing all its attribute values, then copying attribute and