rfc1857.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,516 行 · 第 1/4 页

    o Number of ICMP Source Quench messages
    o Number of packets dropped












Lambert                      Informational                      [Page 7]

RFC 1857                 Operational Statistics             October 1995


3.2.3.  Availability Metrics

These metrics could be viewed as gauging long term accessibility on
different protocol layers. Possible metrics include:

    o Line availability as percentage uptime
    o Route availability
    o Application availability

3.2.4.  Stability Metrics

   These metrics describe short-term fluctuations in the network which
   degrade the service level.  Changes in traffic patterns also could be
   recognized using these metrics.  Possible metrics include:

    o Number of fast line status transitions
    o Number of fast route changes (also known as route flapping)
    o Number of routes per interface in the tables
    o Next hop count stability
    o Short term ICMP behavior

3.3.  Categorization Based on Availability of Metrics

   To be able to retrieve metrics, the corresponding variables must be
   accessible at every network object which is part of the management
   domain for which statistics are being collected.

   Some metrics are easily retrievable because they are defined as
   variables in the Internet Standard MIB.  Other metrics may be
   retrievable because they are part of some vendor's private enterprise
   MIB subtree.  Finally, some metrics are considered irretrievable,
   either because they are not possible to include in the SNMP concept
   or because their measurement would require extensive polling (loading
   the network with management traffic).

   The metrics categorized below could each be judged as important in
   evaluating network behavior.  This list may serve as a basis for
   revisiting the decisions on which metrics are to be regarded as
   reasonable and desirable to collect. If the availability of the
   metrics listed below changes, these decisions may change.

3.3.1.  Per Interface Variables Already in Internet Standard MIB (thus
        easy to retrieve)

           ifInUcastPkts   (unicast packets in)
           ifOutUcastPkts  (unicast packets out)
           ifInNUcastPkts  (non-unicast packets in
           ifOutNUcastPkts (non-unicast packets out)



Lambert                      Informational                      [Page 8]

RFC 1857                 Operational Statistics             October 1995


           ifInOctets      (octets in)
           ifOutOctets     (octets out)
           ifOperStatus    (line status)

3.3.2.  Per Interface Variables in Internet Private Enterprise MIB (thus
        could sometimes be retrievable)

           discarded packets in
           discarded packets out
           congestion events in
           congestion events out
           aggregate errors
           interface resets

3.3.3.  Per Interface Variables Needing High Resolution Polling (which
        is hard due to resulting network load)

           interface queue length
           seconds missing stats
           interface unavailable
           route changes
           interface next hop count


3.3.4.  Per Interface Variables not in any Known MIB (thus impossible
        to retrieve using SNMP but possible to include in a MIB)

           link layer packets in
           link layer packets out
           link layer octets in
           link layer octets out
           packet interarrival times
           packet size distribution

3.3.5.  Per Node Variables (not categorized here)

           per-protocol packets in
           per-protocol packets out
           per-protocol octets in
           per-protocol octets out
           packets discarded in
           packets discarded out
           packet size distribution
           system uptime
           poll delta time
           reboot count





Lambert                      Informational                      [Page 9]

RFC 1857                 Operational Statistics             October 1995


3.3.6.  Metrics not Retrievable with SNMP

           delays (RTTs) on different protocol layers
           application layer availabilities
           peak behavior metrics

3.4.  Recommended Metrics

   A large number of metrics could be considered for collection in the
   process of doing network statistics. To facilitate general consensus
   for this model, there is a need to define a minimal set of metrics
   that are both essential and retrievable in a majority of today's
   network objects.  General retrievability is equated with presence in
   the Internet Standard MIB.

   The following metrics from the Internet Standard MIB were chosen as
   being desirable and reasonable:

   For each interface:

           ifInOctets      (octets in)
           ifOutOctets     (octets out)
           ifInUcastPkts   (unicast packets in)
           ifOutUcastPkts  (unicast packets out)
           ifInNUcastPkts  (non-unicast packets in)
           ifOutNUcastPkts (non-unicast packets out)
           ifInDiscards    (in discards)
           ifOutDiscards   (out discards)
           ifOperStatus    (line status)

   For each node:

           ipForwDatagrams (IP forwards)
           ipInDiscards    (IP in discards)
           sysUpTime       (system uptime)

4.  Polling Frequencies

   The purpose of polling at specified intervals is to gather statistics
   to serve as a basis for trend and capacity planning. From the
   operational data it should be possible to derive engineering and
   management data. It should be noted that all polling and retention
   values given below are recommendations and are not mandatory.








Lambert                      Informational                     [Page 10]

RFC 1857                 Operational Statistics             October 1995


4.1.  Variables Needing High Resolution Polling

   To be able to detect peak behavior, it is recommended that a period
   of 1 minute (60 seconds) at a maximum be used in gathering traffic
   data. The metrics to be collected at this frequency are:

   for each interface

           ifInOctets      (octets in)
           ifOutOctets     (octets out)
           ifInUcastPkts   (unicast packets in)
           ifOutUcastPkts  (unicast packets out)

   If it is not possible to gather data at this high polling frequency,
   it is recommended that an exact multiple of 60 seconds be used. The
   initial polling frequency value will be part of the stored
   statistical data as described in section 6.1.2 below.

4.2.  Variables not Needing High Resolution Polling

   The remainder of the recommended variables to be gathered, i.e.,

   For each interface:

           ifInNUcastPkts  (non-unicast packets in)
           ifOutNUcastPkts (non-unicast packets out)
           ifInDiscards    (in discards)
           ifOutDiscards   (out discards)
           ifOperStatus    (line status)

   and for each node:

           ipForwDatagrams (IP forwards)
           ipInDiscards    (IP in discards)
           sysUpTime       (system uptime)

   could be collected at a lower polling rate. No polling rate is
   specified, but it is recommended that the period chosen be an exact
   multiple of 60 seconds.

5.  Pre-Processing of Raw Statistical Data

5.1.  Optimizing and Concentrating Data to Resources

   To avoid storing redundant data in what might be a shared file
   system, it is desirable to preprocess the raw data. For example, if a
   link is down there is no need to continuously store a counter which
   is not changing. The use of the variables sysUpTime and ifOperStatus



Lambert                      Informational                     [Page 11]

RFC 1857                 Operational Statistics             October 1995


   makes it possible not to have to continuously store data collected
   from links and nodes where no traffic has been transmitted for some
   period of time.

   Another aspect of processing is to decouple the data from the raw
   interface being polled. The intent should be to convert such data
   into the resource of interest as, for example, the traffic on a given
   link. Changes of interface in a gateway for a given link should not
   be visible in the resulting data.

5.2.  Aggregation of Data

   At many sites, the volume of data generated by a polling period of 1
   minute will make aggregation of the stored data desirable if not
   necessary.

   Aggregation here refers to the replacement of data values on a number
   of time intervals by some function of the values over the union of
   the intervals.  Either raw data or shorter-term aggregates may be
   aggregated.  Note that aggregation reduces the amount of data, but
   also reduces the available information.

   In this model, the function used for the aggregation is either the
   arithmetic mean or the maximum, depending on whether it is desired to
   track the average or peak value of a variable.

   Details of the layout of the aggregated entries in the data file are
   given in section 6.1.3.

   Suggestions for aggregation periods:

   Over a

           24 hour period        aggregate to 15 minutes,
           1 month period        aggregate to 1 hour,
           1 year period         aggregate to 1 day

6.  Storing of Statistical Data

   This section describes a format for the storage of statistical data.
   The goal is to facilitate a common set of tools for the gathering,
   storage and analysis of statistical data. The format is defined with
   the intent of minimizing redundant information and thus minimizing
   storage requirements. If a client server based model for retrieving
   remote statistical data were later developed, the specified storage
   format could be used as the transmission protocol.





Lambert                      Informational                     [Page 12]

RFC 1857                 Operational Statistics             October 1995


   This model is intended to define an interchange file format, which
   would not necessarily be used for actual data storage.  That means
   its goal is to provide complete, self-contained, portable files,
   rather than to describe a full database for storing them.

6.1.  The Storage Format

   All white space (including tabs, line feeds and carriage returns)
   within a file is ignored.  In addition all text from a # symbol to
   the following end of line (inclusive) is also ignored.

stat-data    ::= <stat-section> [ <FS> <stat-section> ]
stat-section ::= <device-section> | <label-section> | <data-section>

   A data file must contain at least one device section and at least one
   label section.  At least one data section must be associated with
   each label section.  A device section must precede any data section
   which uses tags defined within it.

   A data section may appear in the file (in which case it is called an
   internal data section and is preceded by a label section) or in
   another file (in which case it is called an external data section and
   is specified in an external label section).  Such an external file
   may contain one and only one data section.

   A label section indicates the start and finish times for its
   associated data section or sections, and a list of the names of the
   tags they contain.  Within a data file there is an ordering of label
   sections.  This depends only upon their relative position in the
   file.  All internal data sections associated with the first label
   record must precede those associated with the second label record,
   and so on.

   Here are some examples of valid data files:

       <label-s> <device-s> <data-s> <data-s>

       <label-s> <device-s> <data-s> <device-s> <data-s> <data-s>

   Both these files start with a label section giving the times and
   tag-name lists for the device and data sections which follow.

       <dev-s> <label-s> <label-s> <label-s>

   This file begins with a device section (which specifies tags used in
   its data sections) then has three 'external' label sections, each of
   which points to a separate data section.  The data sections need not
   use all the tags defined in the device section; this is indicated by



Lambert                      Informational                     [Page 13]

RFC 1857                 Operational Statistics             October 1995


   the tag-name    lists in their label sections.

      <default-dev> <dev-1> <label-1> <dev-2> <label-2> ..

   In this example default-dev is a full device section, including a
   complete tag-table, with initial polling and aggregation periods
   specified for each variable in each variable-field.  There is no
   label or data for default-dev--it is there purely to provide default
   tag-list information.  Dev-1, dev-2, ... are device sections for a
   series of different devices.  They each have their description fields
   (network-name, router-name, etc), but no tag-table.  Instead they
   rely on using the tag-table from default-device.  A default-dev
   record, if present, must be the first item in the data file.
   Label-1, label-2, etc. are label sections which point to files
   containing data sections for each device.

6.1.1.  The Label Section

   label-section    ::= BEGIN_LABEL <FS> <data-location> <FS>
                           <tag-name-list> <FS>
                           <start-time> <FS> <stop-time> <FS> END_LABEL
   data-location    ::= <data-file-name> | <empty>

   tag-name-list    ::= <LEFT> <tag> [ <FS> <tag> ] <RIGHT>