rfc1404.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

    - Number of ICMP Source Quench messages.
    - Number of packets dropped.
    - etc.

3.2.3 Availability Metrics

   This could be considered as the long term accessibility metrics on
   different protocol layers. Possible metrics are:






Stockman                                                        [Page 7]

RFC 1404                 Operational Statistics             January 1993


    - Line availability as percentage uptime.
    - Route availability
    - Application availability

3.2.4 Stability Metrics

   These metrics describes short term fluctuations in the network which
   degrades the service level. Also changes in traffic patterns could be
   recognized using these metrics.  Possible metrics are:

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

3.3 Categorization Based on Availability of Metrics

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

   Some metrics are easily retrievable as being defined as variables in
   the Internet Standard MIB while other metrics may be retrievable as
   being part of some vendor's private enterprise MIB subtree.  Finally
   some metrics are considered as impossible to retrieve due to not
   being possible to include in the SNMP concept or that the actual
   measurement of these metrics would require extensive polling and
   hence download the network with management traffic.

   The metrics being categorized below could each be judged as an
   important metric in evaluating network behaviors.  This list may
   serve for reconsider the decisions on which metric to be regarded as
   reasonable and desirable to collect. If the availability of below
   metrics changes these decisions may change.

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

        ifInUcastPkts   (unicast packet in)
        ifOutUcastPkts  (unicast packet out)
        ifInNUcastPkts  (non-unicasts packet in
        ifOutNUcastPkts (non-unicast packet out)
        ifInOctets      (octets in)
        ifOutOctets     (octets out)
        ifOperStatus    (line status)





Stockman                                                        [Page 8]

RFC 1404                 Operational Statistics             January 1993


3.3.2 Per Interface Variables in Internet Private Enterprise MIB
      (thus could sometimes be possible to retrieve)

        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 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
        sys uptime
        poll delta time
        reboot count








Stockman                                                        [Page 9]

RFC 1404                 Operational Statistics             January 1993


3.3.6 Metrics not being Retrievable with SNMP

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

3.4 Recommended Metrics

   A large amount of metrics could be regarded for gathering in the
   process of doing network statistics. To facilitate for this model to
   reach general consensus there is a need to define a minimal set of
   metrics that are both essential and also possible to retrieve in a
   majority of today network objects. As an indication of being
   generally retrievable the presence in the Internet Standard MIB is
   regarded as a mandatory requirement.

3.4.1 Chosen Metrics

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

   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)

   All of the above metrics are available in the Internet Standard MIB.
   However, there also other metrics which could be recommended such as
   the RTT metric which probably never will be in any MIB.  For such
   metrics other collection tools than SNMP have to be explicitly
   defined. The specification of such tools are outside scope of this
   memo.






Stockman                                                       [Page 10]

RFC 1404                 Operational Statistics             January 1993


4. Polling Frequencies

   The reason for the polling is to achieve statistics to serve as base
   for trend and capacity planning. From the operational data it shall
   be possible to derive engineering and management data. It shall be
   noted that all polling and saving values below are recommendation and
   not mandatory.

4.1 Variables Needing High Resolution Polling

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

   for each interface

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

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

4.2 Variables not Needing High Resolution Polling

   The other part 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)

   These variables could be gathered at a lower polling rate. No
   specific polling rate is mentioned but it is recommended that the
   period chosen is an even multiple of 60 seconds.




Stockman                                                       [Page 11]

RFC 1404                 Operational Statistics             January 1993


5. Pre-Processing of Raw Statistical Data

5.1 Optimizing and Concentrating Data to Resources

   To avoid redundant data being stored in commonly available storage
   there is a need for processing the raw data. For example if a link is
   down there is no need to continuous store a counter that is not
   changing. Using variables such as sysUpTime and Line Status there is
   the possibility of not continuously storing data collected from links
   and nodes where no traffic have been transmitted over some period of
   time.

   Another aspect of processing is to decouple the data from the raw
   interface being polled. The intention should be to convert such data
   into the resource being 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 provided data.

5.2 Aggregation of Data

   A polling period of 1 minute will create the need of aggregating
   stored data.  Aggregation here means that over a period with logged
   entries, a new aggregated entry is created by taking the first and
   last of the previously logged entries over some aggregation period
   and compute a new entry.

   Not to loose information on the peak values the aggregation also
   means that the peak value of the previous aggregation period is
   calculated and stored.

   This gives below layout of aggregated entries

   It is foreseen that over a relatively short period, polled data will
   be logged at the tightest polling period (1 minute).  Regularly these
   data will be pre-processed into the actual files being provided.

   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

   Aggregation is the computation of new average and maximum values for
   the aggregation period based on the previous aggregation period data.
   For each aggregation period the maximum, and average values are
   computed and stored. Also other aggregation period could be chosen



Stockman                                                       [Page 12]

RFC 1404                 Operational Statistics             January 1993


   when needed. The chosen aggregation period value will be stored
   together with the aggregated data as described below.

6. Storing of Statistical Data

   This section describes a format for storing of statistical data.  The
   goal is to facilitate for a common set of tools for the gathering,
   storing and analysis of statistical data. The format is defined with
   the intention to minimize redundant information and by this minimize
   required storage. If a client server based model for retrieving
   remote statistical data is later being developed, the specified
   storage format should be possible to used as the transmission
   protocol.

   The format is built up by three different sections within the
   statistical storage, a label section, a device section and a data
   section. The label section gives the start and end times for a given
   data section as well as the file where the actual data is stored.
   The device section specifies what is being logged in the
   corresponding data section.

   To facilitate for multiple data sections within one log-file, label
   sections, device sections and data sections may occur more than once.
   Each section type is delimited by a BEGIN-END pair.  Label and device
   sections could either be stored directly in the data-file or as
   separate files where the corresponding data-file is pointed out by
   the data-file entry in the label section.

   A data section must correspond to exactly one label section and one
   device section.  If more label sections and device sections each data
   section will belong to the label section and device section
   immediately prepending the data section if these sections are stored
   within the data-file. How files are physically arranged is outside
   the scope of the document.

6.1 The Storage Format

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

    FS ::= "," | <LF> | <LF> # any text here <LF>

   The file must start with a label specification followed by a device
   specification followed by a data section. If the storing of logged
   data is for some reason interrupted a new label specification should
   be inserted when the storing is restarted. If the device being logged
   is changed this should be indicated as a new label and a new device



Stockman                                                       [Page 13]

RFC 1404                 Operational Statistics             January 1993


   specification.

   It shall here be noted that the actual physical storage of data is a
   local decision and can vary a lot. There can be one data-file per
   interface or multiple interfaces logged within the same data-file.
   Label and device sections may be stored in a separate file as well as
   within the data-file.

6.1.1 The Label Section

    label-section ::=  "BEGIN_LABEL"  <FS>
                       <start_time>   <FS>
                       <stop_time>    <FS>
                       <data_file>    <FS>
                       "END_LABEL"


    start-time  ::= <time-string>
    end-time    ::= <time-string>
    file-name   ::= <ascii-string>
    time-string ::= <year><month><day><hour><minute><second>
    year        ::= <digit><digit><digit><digit>
    month       ::= 01 | ... | 12
    hour        ::= 00 | ... | 23