rfc2123.txt

RFC 的详细文档！

   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.




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 F