rfc2722.txt

中、英文RFC文档大全打包下载完全版 .

   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.

   'NoMatch' 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).

   When writing rule sets one must remember that the meter will normally
   try to match each packet in the reverse direction if the forward
   match does not succeed.  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.  An example of such a language is
   described in the 'SRL' document [RTFM-SRL]. Another approach would be
   to write a 'rule set consistency checker' program, which could detect
   problems in hand-written rule sets.




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


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

   Occasionally there can be situations when a rule set needs to know
   the direction in which a packet is being matched.  Consider, for
   example, a rule set which wants to save some attribute values (source
   and destination addresses perhaps) for any 'unusual' packets.  The
   rule set will contain a sequence of tests for all the 'usual' source
   addresses, follwed by a rule which will execute a 'NoMatch' action.
   If the match fails in the S->D direction, the NoMatch action will
   cause it to be retried.  If it fails in the D->S direction, the
   packet can be counted as an 'unusual' packet.

   To count such an 'unusual' packet we need to know the matching
   direction: the MatchingStoD attribute provides this.  To use it, one
   follows the source address tests with a rule which tests whether the
   matching direction is S->D (MatchingStoD value is 1).  If so, a
   'NoMatch' action is executed.  Otherwise, the packet has failed to
   match in both directions; we can save whatever attribute values are
   of interest and count the 'unusual' packet.

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.

   Rule set 1 (the first entry in the rule set table) 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.

   A meter also maintains an array of 'tasks', which specify what rule
   sets the meter is running.  Each task has a 'current' rule set (the
   one which it normally uses), and a 'standby' rule set (which will be
   used when the overall traffic level is unusually high).  If a task 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 an instruction for the Packet Matching
   Engine, i.e. it is an instruction for a Virtual Machine.  PME
   instructions have five component fields, forming two logical groups
   as follows:

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




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


   The test group allows PME to test the value of an attribute.  This is
   done by ANDing the attribute value with the mask and comparing the
   result with the value field.  Note that there is no explicit
   provision to test a range, although this can be done where the range
   can be covered by a mask, e.g. attribute value less than 2048.

   The PME maintains a Boolean indicator called the 'test indicator',
   which determines whether or not a rule's test is performed.  The test
   indicator is initially set (true).

   The action group specifies what action may be performed when the rule
   is executed.  Opcodes contain two flags: 'goto' and 'test', as
   detailed in the table below.  Execution begins with rule 1, the first
   in the rule set.  It proceeds as follows:

      If the test indicator is true:
         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 NoMatch.

      If the test indicator is false, or the test (above) succeeded:
         Set the test indicator to this opcode'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, NoMatch, Count,
               CountPkt).
         Perform the action.

   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.  Note that when the Ignore, NoMatch, Count and CountPkt
   actions are performed, PME execution is terminated regardless of
   whether the PME is executing a subroutine ('return' stack is non-
   empty) or not.

   The second data structure, 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
   number, mask and value information from the pattern queue in the
   order it was enqueued.



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


   An attribute number identifies the attribute actually used in a test.
   It will usually be the rule's attribute field, unless the attribute
   is a 'meter variable'.  Details of meter variables are given after
   the table of opcode actions below.

   The opcodes are:

            opcode         goto    test

         1  Ignore           0       -
         2  NoMatch          0       -
         3  Count            0       -
         4  CountPkt         0       -
         5  Return           0       0
         6  Gosub            1       1
         7  GosubAct         1       0
         8  Assign           1       1
         9  AssignAct        1       0
        10  Goto             1       1
        11  GotoAct          1       0
        12  PushRuleTo       1       1
        13  PushRuleToAct    1       0
        14  PushPktTo        1       1
        15  PushPktToAct     1       0
        16  PopTo            1       1
        17  PopToAct         1       0

   The actions they perform are:

   Ignore:         Stop matching, return from the match() function
                   indicating that the packet is to be ignored.

   NoMatch:        Stop matching, return from the match() function
                   indicating failure.

   Count:          Stop matching.  Save this rule's attribute number,
                   mask and value in the PME's pattern queue, then
                   construct a flow key for the flow to which this
                   packet belongs.  Return from the match() function
                   indicating success.  The meter will use the flow
                   key to search for the flow record for this
                   packet's flow.

   CountPkt:       As for Count, except that the masked value from
                   the packet header (as it would have been used in
                   the rule's test) is saved in the PME's pattern
                   queue instead of the rule's value.




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


   Gosub:          Call a rule-matching subroutine.  Push the current
                   rule number on the PME's return stack, set the
                   test indicator then goto the specified rule.

   GosubAct:       Same as Gosub, except that the test indicator is
                   cleared before going to the specified rule.

   Return:         Return from a rule-matching subroutine.  Pop the
                   number of the calling gosub rule from the PME's
                   'return' stack and add this rule's parameter value
                   to it to determine the 'target' rule.  Clear the
                   test indicator then goto the target rule.

                   A subroutine call appears in a rule set as a Gosub
                   rule followed by a small group of following rules.
                   Since a Return action clears the test flag, the
                   action of one of these 'following' rules will be
                   executed; this allows the subroutine to return a
                   result (in addition to any information it may save
                   in the PME's pattern queue).

   Assign:         Set the attribute specified in this rule to the
                   parameter value specified for this rule.  Set the
                   test indicator then goto the specified rule.

   AssignAct:      Same as Assign, except that the test indicator
                   is cleared before going to the specified rule.

   Goto:           Set the test indicator then goto the
                   specified rule.

   GotoAct:        Clear the test indicator then goto the specified
                   rule.

   PushRuleTo:     Save this rule's attribute number, mask and value
                   in the PME's pattern queue. Set the test
                   indicator then goto the specified rule.

   PushRuleToAct:  Same as PushRuleTo, except that the test indicator
                   is cleared before going to the specified rule.

                   PushRuleTo actions may be used to save the value
                   and mask used in a test, or (if the test is not
                   performed) to save an arbitrary value and mask.







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


   PushPktTo:      Save this rule's attribute number, mask, and the
                   masked value from the packet header (as it would
                   have been used in the rule's test), in the PME's
                   pattern queue.  Set the test indicator then goto
                   the specified rule.

   PushPktToAct:   Same as PushPktTo, except that the test indicator
                   is cleared before going to the specified rule.

                   PushPktTo actions may be used to save a value from