rfc2724.txt

RFC 的详细文档！


RFC 2724                  RTFM: New Attributes              October 1999


      -  As a distribution, i.e. in an array of 'buckets'.  This method
         is a compact representation of the data, with the values being
         stored as counters between a minimum and maximum, with defined
         steps in each bucket.  This fits the RTFM goal of compact data
         storage.

      -  As a sequence of single values.  This saves all the
         information, but does not fit well with the RTFM goal of doing
         as much data reduction as possible within the meter.

   Studies which would be limited by the use of distributions might well
   use packet traces instead.

   A method for specifying the distribution parameters, and for encoding
   the distribution so that it can be easily read, is described in
   section 3.2.

2.3  Packet Traces

   The simplest way of collecting a trace in the meter would be to have
   a new attribute called, say, "PacketTrace". This could be a table,
   with a column for each property of interest.  For example, one could
   trace:

      -  Packet Arrival time (TimeTicks from sysUpTime, or microseconds
         from FirstTime for the flow).

      -  Packet Direction (Forward or Backward)

      -  Packet Sequence number (for protocols with sequence numbers)

      -  Packet Flags (for TCP at least)

   Note:  The following implementation proposal is for the user who is
   familiar with the writing of rule sets for the RTFM Meter.

      To add a row to the table, we only need a rule which PushPkts the
      PacketTrace attribute.  To use this, one would write a rule set
      which selected out a small number of flows of interest, with a
      'PushPkt PacketTrace' rule for each of them.  A MaxTraceRows
      default value of 2000 would be enough to allow a Meter Reader to
      read one-second ping traces every 10 minutes or so.  More
      realistically, a MaxTraceRows of 500 would be enough for one-
      minute pings, read once each hour.

   Packet traces are already implemented by the RMON MIB [RMON-MIB,
   RMON2-MIB], in the Packet Capture Group.  They are therefore a low
   priority for RTFM.



Handelman, et al.             Experimental                      [Page 7]

RFC 2724                  RTFM: New Attributes              October 1999


2.4  Aggregate Attributes

   RTFM's "old-style" flow attributes count the bytes and packets for
   packets which match the rule set for an individual flow.  In addition
   to these totals, for example, RTFM could calculate Packet Size
   statistics.  This data can be stored as distributions, though it may
   sometimes be sufficient to simply keep a maximum value.

   As an example, consider Packet Size.  RTFM's packet flows can be
   examined to determine the maximum packet size found in a flow.  This
   will give the Network Operator an indication of the MTU being used in
   a flow.  It will also give an indication of the sensitivity to loss
   of a flow, for losing large packets causes more data to be
   retransmitted.

   Note that aggregate attributes are a simple extension of the 'old-
   style' attributes; their values are never reset.  For example, an
   array of counters could hold a 'packet size' distribution.  The
   counters continue to increase, a meter reader will collect their
   values at regular intervals, and an analysis application will compute
   and display distributions of the packet size for each collection
   interval.

2.5  Group Attributes

   The notion of group attributes is to keep simple statistics for
   measures that involve more than one packet.  This section describes
   some group attributes which it is feasible to implement in a traffic
   meter, and which seem interesting and useful.

   Short-term bit rate - The data could also be recorded as the maximum
   and minimum data rate of the flow, found over specific time periods
   during the lifetime of a flow; this is a special kind of
   'distribution'.  Bit rate could be used to define the throughput of a
   flow, and if the RTFM flow is defined to be the sum of all traffic in
   a network, one can find the throughput of the network.

   If we are interested in '10-second' forward data rates, the meter
   might compute this for each flow of interest as follows:

      -  maintain an array of counters to hold the flow's 10-second data
         rate distribution.

      -  every 10 seconds, compute and save 10-second octet count, and
         save a copy of the flow's forward octet counter.






Handelman, et al.             Experimental                      [Page 8]

RFC 2724                  RTFM: New Attributes              October 1999


   To achieve this, the meter will have to keep a list of aggregate
   flows and the intervals at which they require processing.  Careful
   programming is needed to achieve this, but provided the meter is not
   asked to do it for very large numbers of flows, it has been
   successfully implemented.

   Inter-arrival times.  The Meter knows the time that it encounters
   each individual packet.  Statistics can be kept to record the inter-
   arrival times of the packets, which would give an indication of the
   jitter found in the Flow.

   Turn-around statistics.  Sine the Meter knows the time that it
   encounters each individual packet, it can produce statistics of the
   time intervals between packets in opposite directions are observed on
   the network.  For protocols such as SNMP (where every packet elicits
   an answering packet) this gives a good indication of turn-around
   times.

   Subflow analysis.  Since the choice of flow endpoints is controlled
   by the meter's rule set, it is easy to define an aggregate flow, e.g.
   "all the TCP streams between hosts A and B."  Preliminary
   implementation work suggests that - at least for this case - it
   should be possible for the meter to maintain a table of information
   about all the active streams.  This could be used to produce at least
   the following attributes:

      -  Number of streams, e.g. streams active for n-second intervals.
         Determined for TCP and UDP using source-dest port number pairs.

      -  Number of TCP bytes, determined by taking difference of TCP
         sequence numbers for each direction of the aggreagate flow.

   IIS attributes.  Work at CEFRIEL [IIS-ACCT] has produced a traffic
   meter with a rule set modified 'on the fly' so as to maintain a list
   of RSVP-reserved flows.  For such flows the following attributes have
   been implemented (these quantities are defined in [GUAR-QOS]):















Handelman, et al.             Experimental                      [Page 9]

RFC 2724                  RTFM: New Attributes              October 1999


      - QoSService:          Service class for the flow
                               (guaranteed, controlled load)
      - QoSStyle:            Reservation setup style
                               (wildcard filter, fixed filter,
                               shared explicit)
      - QoSRate:             [byte/s] rate for flows with
                               guaranteed service
      - QoSSlackTerm:        [microseconds] Slack Term QoS parameter
                               for flows with guaranteed service
      - QoSTokenBucketRate:  [byte/s] Token Bucket Rate QoS parameter
                               for flows with guaranteed or
                               controlled load service

      The following are also being considered:

      - QoSTokenBucketSize:  [byte] Size of Token Bucket

      - QoSPeakDataRate:     [byte/s] Maximum rate for incoming data

      - QoSMinPolicedUnit:   [byte] IP datagrams less than this are
                               counted as being this size
      - QoSMaxDatagramSize:  [byte] Size of biggest datagram which
                               conforms to the traffic specification
2.6  Actions on Exceptions

   Some users of RTFM have requested the ability to mark flows as having
   High Watermarks.  The existence of abnormal service conditions, such
   as non-ending flow, a flow that exceeds a given limit in traffic
   (e.g. a flow that is exhausting the capacity of the line that carries
   it) would cause an ALERT to be sent to the Meter Reader for
   forwarding to the Manager.  Operations Support could define service
   situations in many different environments.  This is an area for
   further discussion on Alert and Trap handling.

3  Extensions to the 'Basic' RTFM Meter

   The Working Group has agreed that the basic RTFM Meter will not be
   altered by the addition of the new attributes of this document.  This
   section describes the extensions needed to implement the new
   attributes.

3.1  Flow table extensions

   The architecture of RTFM has defined the structure of flows, and this
   memo does not change that structure.  The flow table could have
   ancillary tables called "Distribution Tables" and "Trace Tables,"





Handelman, et al.             Experimental                     [Page 10]

RFC 2724                  RTFM: New Attributes              October 1999


   these would contain rows of values and or actions as defined above.
   Each entry in these tables would be marked with the number of its
   corresponding flow in the RTFM flow table.

   Note:  The following section is for the user who is familiar with the
   writing of rule sets for the RTFM Meter.

      In order to identify the data in a Packet Flow Table, the
      attribute name could be pushed into a string at the head of each
      row.  For example, if a table entry has "To Bit Rate" for a
      particular flow, the "ToBitRate" string would be found at the head
      of the row.  (An alternative method would be to code an
      identification value for each extended attribute and push that
      value into the head of the row.)  See section 4.  for an inital
      set of ten extended flow attributes.

3.2  Specifying Distributions in RuleSets

   At first sight it would seem neccessary to add extra features to the
   RTFM Meter architecture to support distributions.  This, however, is
   not neccessarily the case.

   What is actually needed is a way to specify, in a ruleset, the
   distribution parameters.  These include the number of counters, the
   lower and upper bounds of the distribution, whether it is linear or
   logarithmic, and any other details (e.g. the time interval for
   short-term rate attributes).

   Any attribute which is distribution-valued needs to be allocated a
   RuleAttributeNumber value.  These will be chosen so as to extend the
   list already in the RTFM Meter MIB document [RTFM-MIB].

   Since distribution attributes are multi-valued it does not make sense
   to test them.  This means that a PushPkt (or PushPkttoAct) action
   must be executed to add a new value to the distribution.  The old-
   style attributes use the 'mask' field to specify which bits of the
   value are required, but again, this is not the case for
   distributions.  Lastly, the MatchedValue ('value') field of a PushPkt
   rule is never used.  Overall, therefore, the 'mask' and 'value'
   fields in the PushPkt rule are available to specify distribution
   parameters.

   Both these fields are at least six bytes long, the size of a MAC
   address.  All we have to do is specify how these bytes should be
   used!  As a starting point, the following is proposed (bytes are
   numbered left-to-right.





Handelman, et al.             Experimental                     [Page 11]

RFC 2724                  RTFM: New Attributes              October 1999


   Mask bytes:
        1    Transform        1 = linear, 2 = logarithmic
        2    Scale Factor     Power of 10 multiplier for Limits
                                  and Counts
      3-4    Lower Limit      Highest value for first bucket
      5-6    Upper Limit      Highest value for last bucket

   Value bytes:
        1    Buckets          Number of buckets.  Does not include
                                  the 'overflow' bucket
        2    Parameter-1      } Parameter use depends
      3-4    Parameter-2      } on distribution-valued
      5-6    Parameter-3      } attribute

   For example, experiments with NeTraMet have used the following rules:

     FromPacketSize     & 1.0.25!1500 = 60.0!0:   PushPkttoAct, Next;

     ToInterArrivalTime &  2.3.1!1800 = 60.0.0!0: PushPkttoAct, Next;

     FromBitRate        & 2.3.1!10000 = 60.5.0!0: PushPkttoAct, Next;

   In these mask and value fields a dot indicates that the preceding
   number is a one-byte integer, the exclamation marks indicate that the
   preceding number is a two-byte integer, and the last number is two
   bytes wide since this was the width of the preceding field.  (Note
   that this convention follows that for IP addresses - 130.216 means
   130.216.0.0).

   The first rule specifies that a distribution of packet sizes is to be
   built.  It uses an array of 60 buckets, storing values from 1 to 1500
   bytes (i.e. linear steps of 25 bytes each bucket).  Any packets with
   size greater than 1500 will be counted in the 'overflow' bucket,
   hence there are 61 counters for the distribution.

   The second rule specifies an interarrival-time distribution, using a
   logarithmic scale for an array of 60 counters (and an overflow
   bucket) for rates from 1 ms to 1.8 s.  Arrival times are measured in
   microseconds, hence the scale factor of 3 indicates that the limits
   are given in milliseconds.

   The third rule specifies a bit-rate distribution, with the rate being
   calculated every 5 seconds (parameter 1).  A logarithmic array of 60
   counters (and an overflow bucket) are used for rates from 1 kbps to
   10 Mbps.  The scale factor of 3 indicates that the limits are given
   in thousands of bits per second (rates are measured in bps).





Handelman, et al.             Experimental                     [Page 12]

RFC 2724                  RTFM: New Attributes              October 1999