rfc2123.txt

<VC++网络游戏建摸与实现>源代码

   one percent of the processor time on a SPARC 10 system running
   Solaris.

3 Writing rule sets

   The Traffic Meter provides a versatile device for measuring a user-
   specified set of traffic flows, and performing useful data reduction
   on them.  This data reduction capability not only minimises the
   volume of data to be collected by meter readers, but also simplifies
   the later processing of traffic flow data.





Brownlee                     Informational                     [Page 16]

RFC 2123                Traffic Flow Measurement              March 1997


   The flows of interest, and the processing to be performed, are
   specified in a 'rule set' which is downloaded to the meter (NeTraMet)
   by the manager (NeMaC). This section explains what is involved in
   writing rule sets.

   NeTraMet is limited to metering packets observed on a network
   segment.  This means that for all the observed flows, Source and Dest
   Type attributes (e.g. SourcePeerType and DestPeerType) have the same
   value.

   The NeTraMet implementation uses single variables in its flow data
   structure for AdjacentType, SourceType and TransType.  Nonetheless,
   the rule sets discussed below push values for both Source and Dest
   Type attributes; this make sure that packet matching works properly
   with the directions reversed, even for a meter which allows Source
   and Dest Type values to be different.

3.1 Rule set to observe all flows

   NeMaC reads rule sets from text files which contain the rules, the
   set number which the meter (and meter reader) will identify them by,
   and a 'format,' i.e. a list specifying which attributes the meter
   reader should collect and write to the flow data file.  The #
   character indicates the start of a comment; NeMaC ignores the rest of
   the line.

     SET 2
     #
     RULES
     #
       SourcePeerType & 255 = Dummy:   Ignore, 0;
       Null & 0 = 0:  GotoAct, Next;
     #
       SourcePeerType     & 255             = 0: PushPkttoAct, Next;
       DestPeerType       & 255             = 0: PushPkttoAct, Next;
       SourcePeerAddress  & 255.255.255.255 = 0: PushPkttoAct, Next;
       DestPeerAddress    & 255.255.255.255 = 0: PushPkttoAct, Next;
       SourceTransType    & 255             = 0: PushPkttoAct, Next;
       DestTransType      & 255             = 0: PushPkttoAct, Next;
       SourceTransAddress & 255.255         = 0: PushPkttoAct, Next;
       DestTransAddress   & 255.255         = 0: CountPkt, 0;
     #
     FORMAT FlowRuleSet FlowIndex FirstTime "  "
        SourcePeerType SourcePeerAddress DestPeerAddress "  "
        SourceTransType SourceTransAddress DestTransAddress "  "
        ToPDUs FromPDUs "  " ToOctets FromOctets;





Brownlee                     Informational                     [Page 17]

RFC 2123                Traffic Flow Measurement              March 1997


   The first rule tests the incoming packet's SourcePeerType to see
   whether it is 'dummy.'  If it is, the packet is ignored, otherwise
   the next rule is executed.

   The second rule tests the Null attribute.  Such a test always
   succeeds, so the rule simply jumps to the action of the next rule.
   (The keyword 'next' is converted by NeMaC into the number of the
   following rule.)

   The third rule pushes the packet's SourcePeerType value, then jumps
   to the action of the next rule.  The user does not know in advance
   what the value of PushPkt rules will be, which is why the value
   appearing in them is always zero.  The user must take care not to
   write rule sets which try to perform the test in a PushPkt rule.
   This is a very common error in a rule set, so NeMaC tests for it and
   displays an error message.

   The following rules push a series of attribute values from the
   packet, and the last rule also Counts the packet, i.e. it tells the
   Packet Matching Engine (PME) that the packet has been successfully
   matched.  The PME responds by searching the flow table to see whether
   the flow is already current (i.e. in the table), creating a new flow
   data record for it should this be necessary, and incrementing its
   packet and byte counters.

   Overall this rule set simply classifies the packet (i.e. decides
   whether or not it is to be counted), then pushes all the Peer and
   Transport attribute values for it.  It makes no attempt to specify a
   direction for the flow - this is left to the PME, as described in
   [1].  The resulting flow data file will have each flow's source and
   destination addresses in the order of the first packet the meter
   observed for the flow.

3.2 Specifying flow direction, using computed attributes

   As indicated above, the Packet Matching Engine will reliably
   determine the flow, and the direction within that flow, for every
   packet seen by a meter.  If the rule set does not specify a direction
   for the flow, the PME simply assumes that the first packet observed
   for a flow is travelling forward, i.e. from source to destination.
   In later analysis of the flow data, however, one is usually
   interested in traffic to or from a particular source.

   One can achieve this in a simple manner by writing a rule set to
   specify the source for flows.  All that is required is to have rules
   which succeed if the packet is travelling in the required direction,
   and which execute a 'Fail' action otherwise.  This is demonstrated in
   the following two examples.



Brownlee                     Informational                     [Page 18]

RFC 2123                Traffic Flow Measurement              March 1997


   (Note that early versions of NeMaC allowed 'Retry' as a synonym for
   'Fail.'  The current version also allows 'NoMatch,' which seems a
   better way to imply "fail, allowing PME to try a second match with
   directions reversed.")

     #  Count IP packets from network 130.216.0.0
     #
     SourcePeerType & 255 = IP: Pushto, ip_pkt;
     Null & 0 = 0: Ignore, 0;
     #
     ip_pkt:
       SourcePeerAddress & 255.255.0.0 = 130.216.0.0: Goto c_pkt;
       Null & 0 = 0: NoMatch, 0;
     #
     c_pkt:
       SourcePeerAddress & 255.255.255.255 = 0: PushPkttoAct, Next;
       DestPeerAddress & 255.255.255.255 = 0: CountPkt, 0;

   The rule labelled ip_pkt tests whether the packet came from network
   130.216.  If it did not, the test fails and the following rule
   executes a NoMatch action, causing the PME to retry the match with
   the directions reversed.  If the second match fails the packet did
   not have 130.216 as an end-point, and is ignored.

   The next rule set meters IP traffic on a network segment which
   connects two routers, g1 and g2.  It classifies flows into three
   groups - those travelling from g1 to g2, those whose source is g1 and
   those whose source is g2.























Brownlee                     Informational                     [Page 19]

RFC 2123                Traffic Flow Measurement              March 1997


     #  Count IP packets between two gateways
     #
     #     -------+-------------------+------------------+-------
     #            |                   |                  |
     #       +----+-----+        +----+-----+        +---+---+
     #       |   g1     |        |    g2    |        | meter |
     #       +-+-+-+-+--+        +-+-+-+-+--+        +-------+
     #
     SourcePeerType & 255 = IP: Pushto, ip_pkt;
     Null & 0 = 0: Ignore, 0;
     #
     ip_pkt:
       SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-80-48-81-0E-7C:
           Goto, s1;
       Null & 0 = 0: Goto, s2;
     s1:
       DestAdjacentAddress & FF-FF-FF-FF-FF-FF = 02-07-01-04-ED-4A
           GotoAct, g3;
       Null & 0 = 0: GotoAct, g1;
     s2:
       SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 02-07-01-04-ED-4A:
           Goto, s3;
       Null & 0 = 0: NoMatch, 0;
     s3:
       DestAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-80-48-81-0E-7C:
           NoMatch, 0;
       Null & 0 = 0: GotoAct, g2;
     #
     g1: FlowClass & 255 = 1:  PushtoAct, c_pkt;  # From g1
     g2: FlowClass & 255 = 2:  PushtoAct, c_pkt;  # From g2
     g3: FlowClass & 255 = 3:  PushtoAct, c_pkt;  # g1 to g2
     #
     c_pkt:
       SourceAdjacentAddress & FF-FF-FF-FF-FF-FF = 0:
           PushPkttoAct, Next;
       DestAdjacentAddress & FF-FF-FF-FF-FF-FF = 0: PushPkttoAct, Next;
       SourcePeerAddress & 255.255.255.255 = 0: PushPkttoAct, Next;
       DestPeerAddress & 255.255.255.255 = 0: PushPkttoAct, Next;
       Null & 0 = 0:  Count, 0

   The first two rules ignore non-IP packets.  The next two rules Goto
   s1 if the packet's source was g1, or to s2 otherwise.  The rule
   labelled s2 tests whether the packet's source was g2; if not a
   NoMatch action is executed, allowing the PME to try the match with
   the packet's direction reversed.  If the match fails on the second
   try the packet didn't come from (or go to) g1 or g2, and is ignored.





Brownlee                     Informational                     [Page 20]

RFC 2123                Traffic Flow Measurement              March 1997


   Packets which come from g1 are tested by the rule labelled s1, and
   the PME will Goto either g3 or g1.

   Packets which came from g2 are tested by the rule labelled s3.  If
   they are not going to g1 the PME will Goto g2.  If they are going to
   g1 a NoMatch action is executed - we want them counted as backward-
   travelling packets for the g1-g2 flow.

   The rules at g1, g2 and g3 push the value 1, 2 or 3 from their rule
   into the flow's FlowClass attribute.  This value can be used by an
   Analysis Application to separate the flows into the three groups of
   interest.  FlowClass is an example of a 'computed' attribute, i.e.
   one whose value is Pushed by the PME during rule matching.

   The remaining rules Push the values of other attributes required for
   later analysis, then Count the flow.

3.3 Subroutines

   Subroutines are implemented in the PME in much the same way as in
   BASIC.  A subroutine body is just a sequence of statements, supported
   by the GoSub and Return actions.  'GoSub' saves the PME's running
   environment and jumps to the first rule of the subroutine body.
   Subroutine calls may be nested as required - NeTraMet defines the
   maximum nesting at compile time.  'Return n' restores the environment
   and jumps to the action part of the nth rule after the Gosub, where n
   is the index value from the Return rule.

   The Return action provides a way of influencing the flow of control
   in a rule set, rather like a FORTRAN Computed Goto.  This is one way
   in which a subroutine can return a result.  The other way is by
   Pushing a value in either a computed attribute (as demonstrated in
   the preceding section), or in a flow attribute.

   One common use for a subroutine is to test whether a packet attribute
   matches one of a set of values.  Such a subroutine becomes much more
   useful if it can be used to test one of several attributes.  The PME
   architecture provides for this by using 'meter variables' to hold the
   names of the attributes to be tested.  The meter variables are called
   V1, V2, V3, V4 and V5, and the Assign action is provided to set their
   values.  If, for example, we need a subroutine to test either
   SourcePeerAddress or DestPeerAddress, we write its rules to test V1
   instead.  Before calling the subroutine we Assign SourcePeerAddress
   to V1; later tests of V1 are converted by the PME into tests on
   SourcePeerAddress.  Note that since meter variables may be reassigned
   in a subroutine, their values are part of the environment which must
   be saved by a Gosub action.