rfc2063.txt

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

   mask information from the pattern stack in the order it was enqueued.

   The opcodes are:

         opcode         goto    test

      1  Ignore           0       -
      2  Fail             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

   The actions they perform are:

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

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

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

   CountPkt:       As for Count, except that the masked value from
                   the packet is saved in the PME's pattern queue
                   instead of the rule's value.




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


   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
                   value specified in 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 name, 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.             Experimental                     [Page 23]

RFC 2063         Traffic Flow Measurement: Architecture     January 1997


   PushPktTo:      Save this rule's attribute name, mask, together
                   with the masked value from the packet, 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
                   the packet using a specified mask.  The test in
                   PushPktTo rules will almost never be executed.

   As well as the attributes applying directly to packets (such as
   SourcePeerAddress, DestTransAddress, etc.)  the PME implements
   several further attribtes.  These are:

   Null:       Tests performed on the Null attribute always succeed.

   v1 .. v5:   v1, v2, v3, v4 and v5 are 'meter variables.'  They
               provide a way to pass parameters into rule-matching
               subroutines.  Each may hold the name of a normal
               attribute; its value is set by an Assign action.
               When a meter variable appears as the attribute of a
               rule, its value specifies the actual attribute to be
               tested.  For example, if v1 had been assigned
               SourcePeerAddress as its value, a rule with v1 as its
               attribute would actually test SourcePeerAddress.

   SourceClass, DestClass, FlowClass,
   SourceKind, DestKind, FlowKind:
               These six attributes may be set by executing PushRuleto
               actions.  They allow the PME to save (in flow records)
               information which has been built up during matching.
               Since their values are only defined when matching is
               complete (and the flow key is built) their values may
               not be tested in rules.

4.5 Maintaining the Flow Table

   The flow table may be thought of as a 1-origin array of flow records.
   (A particular implementation may, of course, use whatever data
   structure is most suitable).  When the meter starts up there are no
   known flows; all the flow records are in the 'inactive' state.

   Each time a packet is seen for a flow which is not in the current
   flow set a flow record is set up for it; the state of such a record
   is 'current.'  When selecting a record for the new flow the meter
   searches the flow table for a 'inactive' record - there is no



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


   particular significance in the ordering of records within the table.

   Flow data may be collected by a 'meter reader' at any time.  There is
   no requirement for collections to be synchronized.  The reader may
   collect the data in any suitable manner, for example it could upload
   a copy of the whole flow table using a file transfer protocol, or it
   could read the records in the current flow set row by row using a
   suitable data transfer protocol.

   The meter keeps information about collections, in particular it
   maintains a LastCollectTime variable which remembers the time the
   last collection was made.  A second variable, InactivityTime,
   specifies the minimum time the meter will wait before considering
   that a flow is idle.

   The meter must recover records used for idle flows, if only to
   prevent it running out of flow records.  Recovered flow records are
   returned to the 'inactive' state.  A variety of recovery strategies
   are possible, including the following:

   One possible recovery strategy is to recover idle flow records as
   soon as possible after their data has been collected.  To implement
   this the meter could run a background process which scans the flow
   table looking for 'current' flows whose 'last packet' time is earlier
   than the meter's LastCollectTime.  This would be suitable for use
   when one was interested in measuring flow lifetimes.

   Another recovery strategy is to leave idle flows alone as long as
   possible, which would be suitable if one was only interested in
   measuring total traffic volumes.  It could be implemented by having
   the meter search for collected idle flows only when it ran out of
   'inactive' flow records.

   One further factor a meter should consider before recovering a flow
   is the number of meter readers which have collected the flow's data.
   If there are multiple meter readers operating, network Operations
   personnel should be able to specify the minimum number of meters - or
   perhaps a specific list of meters - which should collect a flow's
   data before its memory can be recovered.  This issue will be further
   developed in the future.

4.6 Handling Increasing Traffic Levels

   Under normal conditions the meter reader specifies which set of usage
   records it wants to collect, and the meter provides them.

   If memory usage rises above the high-water mark the meter should
   switch to a STANDBY RULE SET so as to increase the granularity of



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


   flow collection and decrease the rate at which new flows are created.
   When the manager, usually as part of a regular poll, becomes aware
   that the meter is using its standby rule set, it could decrease the
   interval between collections.  The meter should also increase its
   efforts to recover flow memory so as to reduce the number of idle
   flows in memory.  When the situation returns to normal, the manager
   may request the meter to switch back to its normal rule set.

5 Meter Readers

   Usage data is accumulated by a meter (e.g.  in a router) as memory
   permits.  It is collected at regular reporting intervals by meter
   readers, as specified by a manager.  The collected data is recorded
   in a disk file called a FLOW DATA FILE, as a sequence of USAGE
   RECORDS.

   The following sections describe the contents of usage records and
   flow data files.  Note, however, that at this stage the details of
   such records and files is not specified in the architecture.
   Specifying a common format for them would be a worthwhile future
   development.

5.1 Identifying Flows in Flow Records

   Once a packet has been classified and is ready to be counted, an
   appropriate flow data record must already exist in the flow table;
   otherwise one must be created.  The flow record has a flexible format
   where unnecessary identification attributes may be omitted.  The
   determination of which attributes of the flow record to use, and of
   what values to put in them, is specified by the current rule set.

   Note that the combination of start time, rule set id and subscript
   (row number in the flow table) provide a unique flow identifier,
   regardless of the values of its other attributes.

   The current rule set may specify additional information, e.g.  a
   computed attribute value such as FlowKind, which is to be placed in
   the attribute section of the usage record.  That is, if a particular
   flow is matched by the rule set, then the corresponding flow record
   should be marked not only with the qualifying identification
   attributes, but also with the additional information.  Using this
   feature, several flows may each carry the same FlowKind value, so
   that the resulting usage records can be used in post-processing or
   between meter reader and meter as a criterion for collection.







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


5.2 Usage Records, Flow Data Files

   The collected usage data will be stored in flow data files on the
   meter reader, one file for each meter.  As well as containing the
   measured usage data, flow data files must contain information
   uniquely identifiying the meter from which it was collected.

   A USAGE RECORD contains the descriptions of and values for one or
   more flows.  Quantities are counted in terms of number of packets and
   number of bytes per flow.  Each usage record contains the entity
   identifier of the meter (a network address), a time stamp and a list
   of reported flows (FLOW DATA RECORDS). A meter reader will build up a
   file of usage records by regularly collecting flow data from a meter,
   using this data to build usage records and concatenating them to the
   tail of a file.  Such a file is called a FLOW DATA FILE.

   A usage record contains the following information in some form:

   +-------------------------------------------------------------------+
   |    RECORD IDENTIFIERS:                                            |
   |      Meter Id (& digital signature if required)                   |
   |      Timestamp