rfc2123.txt

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

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


   The following rule set demonstrates the use of a subroutine ..

     #  Rule specification file to tally IP packets in three groups:
     #     UA to AIT, UA to elsewhere, AIT to elsewhere
     #
     #     -------+-------------------+-----------------+--------
     #            |                   |                 |
     #       +----+-----+        +----+-----+        +---+---+
     #       |   UA     |        |   AIT    |        | meter |
     #       +-+-+-+-+--+        +-+-+-+-+--+        +-------+
     #
       SourcePeerType & 255 = IP:      PushtoAct, ip_pkt;
       Null & 0 = 0:                   Ignore, 0;
     #
     ip_pkt:
       v1 & 0 = SourcePeerAddress:  AssignAct, Next;
       Null & 0 = 0:  Gosub, classify;
         Null & 0 = 0:  GotoAct, from_ua;    # 1 ua
         Null & 0 = 0:  GotoAct, from_ait;   # 2 ait
         Null & 0 = 0:  NoMatch, 0;          # 3 other
     #
     from_ua:
       v1 & 0 = DestPeerAddress:  AssignAct, Next;
       Null & 0 = 0:  Gosub, classify;
         Null & 0 = 0:  Ignore, 0;            # 1 ua-ua
         Null & 0 = 0:  GotoAct, ok_pkt;      # 2 ua-ait
         Null & 0 = 0:  Gotoact, ok_pkt;      # 3 ua-other
     #
     from_ait:
       v1 & 0 = DestPeerAddress:  AssignAct, Next;
       Null & 0 = 0:  Gosub, classify;
         Null & 0 = 0:  NoMatch, 0;           # 1 ait-ua
         Null & 0 = 0:  Ignore, 0;            # 2 ait-ait
         Null & 0 = 0:  GotoAct, ok_pkt;      # 3 ait-other
     #
     ok_pkt:
       Null & 0 = 0:                   Count, 0;

   The subroutine begins at the rule labelled classify (shown below).
   It returns to the first, second or third rule after the invoking
   Gosub rule, depending on whether the tested PeerAddress is in the UA,
   AIT, or 'other' group of networks.  In the listing below only one
   network is tested in each of the groups - it is trivial to add more
   rules (one per network) into either of the first two groups.  In this
   example the subroutine Pushes the network number from the packet into
   the tested attribute before returning.





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


   The first invocation of classify (above) begins at the rule labelled
   ip_pkt.  It Assigns SourcePeerAddress to V1 then executes a Gosub
   action.  Classify returns to one of the three following rules.  They
   will Goto from_ua or from_ait if the packet came from the UA or AIT
   groups, otherwise the PME will retry the match.  This means that
   matched flows will have a UA or AIT network as their source, and
   flows between other networks will be ignored.

   The next two invocations of 'classify' test the packet's
   DestPeerAddress.  Packets from AIT to UA are Retried, forcing them to
   be counted as AU to AIT flows.  Packets from UA to UA are ignored, as
   are packets from AIT to AIT.

     classify:
       v1 & 255.255.0.0 = 130.216.0.0:  GotoAct, ua;   # ua
       v1 & 255.255.0.0 = 156.62.0.0:   GotoAct, ait;  # ait
       Null & 0 = 0:                    Return, 3;     # other
     ua:
       v1 & 255.255.0.0 = 0:            PushPkttoAct, Next;
       Null & 0 = 0:                    Return, 1;
     ait:
       v1 & 255.255.0.0 = 0:            PushPkttoAct, Next;
       Null & 0 = 0:                    Return, 2;

3.4 More complicated rule sets

   The next example demonstrates a way of grouping IP flows together
   depending on their Transport Address, i.e. their IP port number.
   Simply Pushing every flow's SourceTransAddress and DestTransAddress
   would produce a large number of flows, most of which differ only in
   one of their transport addresses (the one which is not a well-known
   port).

   Instead we Push the well-known port number into each flow's
   SourceTransAddress; its DestTransAddress will be zero by default.

     SourcePeerType & 255 = dummy:      Ignore, 0;
     SourcePeerType & 255 = IP:         Pushto, IP_pkt;
     Null & 0 = 0:   GotoAct, Next;
     SourcePeerType & 255 = 0:      PushPkttoAct, Next;
     Null & 0 = 0:  Count, 0;  # Count others by protocol type
  #
  IP_pkt:
    SourceTransType & 255 = tcp:    Pushto, tcp_udp;
    SourceTransType & 255 = udp:    Pushto, tcp_udp;
    SourceTransType & 255 = icmp:   CountPkt, 0;
    SourceTransType & 255 = ospf:   CountPkt, 0;
    Null & 0 = 0:  GotoAct, c_unknown;  #  Unknown transport type



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


  #
  tcp_udp:
  s_domain:
    SourceTransAddress & 255.255 = domain:  PushtoAct, c_well_known;
  s_ftp:
    SourceTransAddress & 255.255 = ftp:     PushtoAct, c_well_known;
  s_imap:
    SourceTransAddress & 255.255 = 113:     PushtoAct, c_well_known;
  s_nfs
    SourceTransAddress & 255.255 = 2049:    PushtoAct, c_well_known;
  s_pop:
    SourceTransAddress & 255.255 = 110:     PushtoAct, c_well_known;
  s_smtp:
    SourceTransAddress & 255.255 = smtp:    PushtoAct, c_well_known;
  s_telnet:
    SourceTransAddress & 255.255 = telnet:  PushtoAct, c_well_known;
  s_www:
    SourceTransAddress & 255.255 = www:     PushtoAct, c_well_known;
  s_xwin
    SourceTransAddress & 255.255 = 6000:    PushtoAct, c_well_known;
  #
    DestTransAddress & 255.255 = domain:    GotoAct, s_domain;
    DestTransAddress & 255.255 = ftp:       GotoAct, s_ftp;
    DestTransAddress & 255.255 = 113:       GotoAct, s_imap;
    DestTransAddress & 255.255 = 2049:      GotoAct, s_nfs;
    DestTransAddress & 255.255 = 110:       GotoAct, s_pop;
    DestTransAddress & 255.255 = smtp:      GotoAct, s_smtp;
    DestTransAddress & 255.255 = telnet:    GotoAct, s_telnet;
    DestTransAddress & 255.255 = www:       GotoAct, s_www;
    DestTransAddress & 255.255 = 6000:      GotoAct, s_xwin;
  #
    Null & 0 = 0:  GotoAct, c_unknown;  #  'Unusual' port
  #
  c_unknown:
    SourceTransType    & 255 = 0:     PushPkttoAct, Next;
    DestTransType      & 255 = 0:     PushPkttoAct, Next;
    SourceTransAddress & 255.255 = 0: PushPkttoAct, Next;
    DestTransAddress   & 255.255 = 0: CountPkt, 0;
  #
  c_well_known:
    Null & 0 = 0:  Count, 0
  #

   The first few rules ignore dummy packets, select IP packets for
   further processing, and count packets for other protocols in a single
   flow for each PeerType.  TCP and UDP packets cause the PME to Push
   their TransType and Goto tcp_udp.  ICMP and OSPF packets are counted
   in flows which have only their TransType Pushed.



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


   At tcp_udp the packets' SourceTransAddress is tested to see whether
   it is included in a set of 'interesting' port numbers.  If it is, the
   port number is pushed from the rule into the SourceTransAddress
   attribute, and the packet is counted at c_well_known.  (NeMaC accepts
   Pushto as a synonym for PushRuleto).

   This testing is repeated for the packet's DestTransAddress; if one of
   these tests succeeds the PME Goes to the corresponding rule above and
   Pushes the port number into the flow's SourceTransAddress.  If these
   tests fail the packet is counted at c_unknown, where all the flow's
   Trans attributes are pushed.  For production use more well-known
   ports would need to be included in the tests above - c_unknown is
   intended only for little-used exception flows!

   Note that these rules only Push a value into a flow's
   SourceTransAddress, and they don't contain any NoMatch actions.  They
   therefore don't specify a packet's direction, and they could be used
   in other rule sets to group together flows for well-known ports.

   The last example (below) meters flows from a remote router, and
   demonstrates another approach to grouping well-known ports.

    SourceAdjacentAddress & FF-FF-FF-FF-FF-FF =
        00-60-3E-10-E0-A1:  Goto, gateway;  # tmkr2 router
    DestAdjacentAddress & FF-FF-FF-FF-FF-FF = 00-60-3E-10-E0-A1:
        Goto, gateway;  # Source is tmkr2
    Null & 0 = 0:  Ignore, 0;
  #
  gateway:
    SourcePeerType & 255 = IP:  GotoAct, IP_pkt;
    Null & 0 = 0:  GotoAct, Next;
    SourcePeerType & 255 = 0:  CountPkt, 0;
  #
  IP_pkt:
    SourceTransType & 255 = tcp:    PushRuleto, tcp_udp;
    SourceTransType & 255 = udp:    PushRuleto, tcp_udp;
    Null & 0 = 0:  GotoAct, not_wkp;  #  Unknown transport type
  #
  tcp_udp:
    SourceTransAddress & FC-00 = 0:  GotoAct, well_known_port;
    DestTransAddress & FC-00 = 0:  NoMatch, 0;
    Null & 0 = 0:  GotoAct, not_wkp;
  #
  not_wkp:
    DestTransAddress   & 255.255       = 0: PushPkttoAct, Next;
  well_known_port:
    SourcePeerType     & 255           = 0: PushPkttoAct, Next;
    DestPeerType       & 255           = 0: PushPkttoAct, Next;



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


    SourcePeerAddress  & 255.255.255.0 = 0: PushPkttoAct, Next;
    DestPeerAddress    & 255.255.255.0 = 0: PushPkttoAct, Next;
    SourceTransType    & 255           = 0: PushPkttoAct, Next;
    DestTransType      & 255           = 0: PushPkttoAct, Next;
    SourceTransAddress & 255.255       = 0: CountPkt, 0;

   The first group of rules test incoming packet's AdjacentAddresses to
   see whether they belong to a flow with an end point at the specified
   router.  Any which don't are ignored.  Non-IP packets are counted in
   flows which only have their PeerType Pushed; these will produce one
   flow for each non-IP protocol.  IP packets with TransTypes other than
   UDP and TCP are counted at not_wkp, where all their address
   attributes are pushed.

   The high-order six bits of SourceTransAddress for UDP and TCP packets
   are compared with zero.  If this succeeds their source port number is
   less than 1024, so they are from a well-known port.  The port number
   is pushed from the rule into the flow's SourceTransAddress attribute,
   and the packet is counted at well_known_port.  If the test fails, it
   is repeated on the packet's DestTransAddress.  If the destination is
   a well-known port the match is Retried, and will succeed with the
   well-known port as the flow's source.

   If later analysis were to show that a high proportion of the observed
   flows were from non-well-known ports, further pairs of rules could be
   added to perform a test in each direction for other heavily-used
   ports.

4 Flow data files

   Although the Architecture document [1] specifies - in great detail -
   how the Traffic Flow Meter works, and how a meter reader should
   collect flow data from a meter, it does not say anything about how
   the collected data should be stored.  NeMaC uses a simple, self-
   documenting file format, which has proved to be very effective in
   use.

   There are two kinds of records in a flow data file:  flow records and
   information records.  Each flow record is simply a sequence of
   attribute values with separators (these can be specified in a NeMaC
   rule file) or spaces between them, terminated by a newline.

   Information records all start with a cross-hatch.  The file's first
   record begins with ##, and identifies the file as being a file of
   data from NeTraMet.  It records NeMaC's parameters and the time this
   collection was started.  The file's second record begins with
   #Format: and is a copy of the Format statement used by NeMaC to
   collect the data.



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


   The rest of the file is a sequence of collected data sets.  Each of
   these starts with a #Time:  record, giving the time-of-day the
   collection was started, the meter name, and the range of meter times
   this collection represents.  These from and to times are meter
   UpTimes, i.e. they are times in hundredths of seconds since the meter
   commenced operation.  Most anal