rfc1404.txt

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

    minute      ::= 00 | ... | 59
    second      ::= 00 | ... | 59
    digit       ::=  0 | ... | 9

    ascii-string ::= same as MIB II definition of <ascii-string>

   The times defines start and stop times for the related set of logged
   data. The time is in UTC.

6.1.2 The Device Section

    device-section ::= "BEGIN_DEVICE" <FS>
                       <device-field> <FS>
                       "END_DEVICE"

    device-field   ::= <networkname><FS><routername><FS><linkname><FS>
                       <bw-value><FS><bw-sort><FS><proto-type><FS>
                       <proto-addr><FS><time-zone><FS><tag-table>
                       [<tag-table>]


    networkname    ::= <ascii-string>
    routername     ::= <fully qualified domain name>
    linkname       ::= <ascii-string>



Stockman                                                       [Page 14]

RFC 1404                 Operational Statistics             January 1993


    bw-value       ::= <actual bandwidth value>
    bw-sort        ::= "bps" | "Kbps" | "Mbps" | "Gbps" | "Tbps"
    proto-type     ::= "IP" | "DECNET" | "X.25" | "CLNS"
    proto-addr     ::= <network-address depending on proto-type>
    timezone       ::= <"+" | "-"><00 | ... | 12><00 | 30>
    tag-table      ::= <tag><FS><tag-class><FS><variable-field>
                       [<FS><variable-field>]
    tag-class      ::= "total" | "peak"
    variable-field ::= <variable-name> <FS> <initial-polling-period><FS>
                       <aggregation-period>
    tag            ::= <ascii-string>
    variable-name  ::= <ascii-string>

    initial-polling-period ::= <digit>[<digit>]
    aggregation-period     ::= <digit>[<digit>]

   The network name is a human readable string indicating to which
   network the logged data belong.

   The routername is the fully qualified name relevant for the network
   architecture where the router is installed.

   The linkname is a human readable string indicating the the
   connectivity of the link where from the logged data is gathered.

   The bandwidth should be the numerical value followed by the sort
   being used. Valid sorts are bps, Kbps, Mbps, Tbps.

   The prototype filed describes to which network architecture the
   interface being logged is connected. Valid types are IP, DECNET, X.25
   and CLNP.

   The network address is the unique numeric address of the interface
   being logged. The actual form of this address is dependent of the
   protocol type as indicated in the proto-type field. For Internet
   connected interfaces the "three-dot" notation should be used.

   The time-zone indicates the timedifference that should be added to
   the timestamp in the datasection to give the local time for the
   logged interface.

   The tag-table lists all the variables being polled. Variable names
   are the fully qualified Internet MIB names. The table may contain
   multiple tags. Each tag must be associated with only one polling and
   aggregation period. If variables are being polled or aggregated at
   different periods one separate tag in the table has to be used for
   each period.




Stockman                                                       [Page 15]

RFC 1404                 Operational Statistics             January 1993


   As variables may be polled with different polling periods within the
   same set of logged data, there is a need to explicitly associate a
   polling period with each variable. After being processed the actual
   period covered may have changed as compared to the initial polling
   period and this should be noted in the aggregation period field.  The
   initial polling period and aggregation period should be given in
   seconds.

   As aggregation also means the computation of the max value for the
   previously polled data, the aggregation process have to extend the
   tag table to include these maximum values. This could be done in
   different ways. The variable field for the aggregated variables is
   extended to also include the peak values from the previous period.
   Another possibility is to create new tags for the peak values. To be
   able to differentiate between polled raw data, aggregated total and
   aggregated peak values some kind of unique naming of such entities
   has to be implemented.

6.1.3 The Data Section

    data-section    ::= "BEGIN_DATA"<FS>
                        <data-field><LF>
                        "END_DATA"

    data-field      ::= <timestamp><FS><tag><FS>
                        <poll-delta><FS><delta-val>
                        [<FS><delta-val>]

    poll-delta  ::= <digit> [<digit>]
    tag         ::= <ascii-string>
    delta-value ::= <digit> [<digit>]
    timestamp   ::= <year><month><day><hour><minute><second>
    year        ::= <digit><digit><digit><digit>
    month       ::= 01 | ... | 12
    hour        ::= 00 | ... | 23
    minute      ::= 00 | ... | 59
    second      ::= 00 | ... | 59
    digit       ::=  0 | ... | 9

   The datafield contains the polled data from a set of variables as
   defined by the corresponding tag field. Each data field begins with
   the timestamp for this poll followed by the tag defining the polled
   variables followed by a polling delta value giving the period of time
   in seconds since the previous poll. The variable values are stored as
   delta values for counters and as absolute values for non-counter
   values such as OperStatus. The timestamp is in UTC and the time-zone
   field in the device section is used to compute the local time for the
   device being logged.



Stockman                                                       [Page 16]

RFC 1404                 Operational Statistics             January 1993


6.2 Storage Requirement Estimations

   The header sections are not counted in this example.  Assuming the
   the maximum polling intensity is used for all the 12 recommended
   variables and assuming the size in ascii of each variable is 8 bytes
   will give the below calculations based on one year of storing and
   aggregating statistical data.

   Assuming that data is saved according to the below scheme

        1 minute non-aggregated           saved 1 day.
        15 minute aggregation period      saved 1 week.
        1 hour aggregation period         saved 1 month.
        1 day aggregation period          saved 1 year.

   this will give:

   Size of one entry for each aggregation period:


                                 Aggregation periods

                      1 min       15 min      1 hour     1 day

    Timestamp           14          14          14         14
    Tag                  5           5           5          5
    Poll-Delta           2           3           4          5
    Total values        96          96          96         96
    Peak values          0          96         192        288
    Field separators    14          28          42         56

    Total entry size   131         242         353        464

   For each day 60*24 = 1440 entries with a total size of 1440*131 = 187
   Kbytes.

   For each weak 4*24*7 = 672 entries are stored with a total size of
   672*242 = 163 Kbytes

   For each month 24*30 = 720 entries are stored with a total size of
   720*353 = 254 Kbytes

   For each year 365 entries are stored with a total size of 365*464 =
   169 Kbytes.

   Grand total estimated storage for during one year = 773 Kbytes.





Stockman                                                       [Page 17]

RFC 1404                 Operational Statistics             January 1993


7. Report Formats

   This section suggest some report formats and defines the metrics to
   be used in such reports.

7.1 Report Types and Contents

   There is the longer term needs for monthly and yearly reports showing
   the long term tendencies in the network. There are the short term
   weekly reports giving indications on the medium term changes in the
   network behavior which could serve as input in the medium term
   engineering approach.  Finally there is the daily reports giving
   instantaneous overviews needed in the daily operations of a network.

   These reports should give information on:

      Offered Load              Total traffic at external interfaces.
      Offered Load              Segmented by "Customer".
      Offered Load              Segmented protocol/application.

      Resource Utilization      Link/Router.

7.2 Contents of the Reports

7.2.1 Offered Load by Link

    Metric categories: input  octets  per external interface
                       output octets  per external interface
                       input  packets per external interface
                       output packets per external interface

   The intention is to visualize the overall trend of network traffic on
   each connected external interface. This could be done as a bar-chart
   giving the totals for each of the four metric categories.  Based on
   the time period selected this could be done on a hourly, daily,
   monthly or yearly basis.

7.2.2 Offered Load by Customer

    Metric categories: input  octets  per customer
                       output octets  per customer
                       input  packets per customer
                       output packets per customer

   The recommendation is here to sort the offered load (in decreasing
   order) by customer. Plot the function F(n), where F(n) is percentage
   of total traffic offered to the top n customers or the function f(n)
   where f is the percentage of traffic offered by the n'th ranked



Stockman                                                       [Page 18]

RFC 1404                 Operational Statistics             January 1993


   customers.

   The definition of what should be meant by a customer has to be done
   locally at the site where the statistics are being gathered.

   The cumulative could be useful as an overview of how the traffic is
   distributed among users since it enables to quickly pick off what
   fraction of of the traffic comes from what number of "users."

   A method of displaying both average and peak-behaviors in the same
   bar-diagram is to compute both the average value over some period and
   the peak value during the same period. The average and peak values
   are then displayed in the same bar.

7.2.3 Resource Utilization Reporting

7.2.3.1 Utilization as Maximum Peak Behavior

   The link utilization is used to capture information on network
   loading.  The polling interval must be small enough to be significant
   with respect to variations in human activity since this is the
   activity that drives loading in network variation. On the other hand,
   there is no need to make it smaller than an interval over which
   excessive delay would notably impact productivity. For this reason 30
   minutes is a good estimate the time at which people remain in one
   activity and over which prolonged high delay will affect their
   productivity.  To track 30 minute variations, there is a need to
   sample twice as frequently, i.e., every 15 minutes. Using above
   recommended polling period of 10 minutes this will hence be
   sufficient to capture variations in utilizations.

   A possible format for reporting utilizations seen as peak behaviors
   is to use a method of combining averages and peak measurements onto
   the same diagram. Compare for example peak-meters on audio-equipment.
   If for example a diagram contains the daily totals for some period,
   then the peaks would be the most busy hour during each day. If the
   diagram was totals on hourly basis then the peak would be the maximum
   10 minutes period for each hour.

   By combining the average and the maximum values for a certain
   timeperiod it will be possible to detect line utilization and
   bottlenecks due to temporary high loads.

7.2.3.2 Utilization Visualized as a Frequency Distribution of Peaks

   Another way of visualizing line utilization is to put the 10 minutes
   samples in a histogram showing the relative frequency among the
   samples vs. the load.



Stockman                                                       [Page 19]

RFC 1404                 Operational Statistics             January 1993


8. Considerations for Future Development

   This memo is the first effort in formalizing a common basis for
   operational statistics. One major guideline in this work has been to
   keep the model simple to facilitate for vendors and NOCs to easily
   integrate this model in their operational tools.

   There are, however, some ideas that could be progressed further to
   expand the scope and usability of the model.

8.1 A Client/Server Based Statistical Exchange System

   A possible way of development could be the definition of a
   client/server based architecture for providing Internet access to
   operational statistics. Such an architecture envisions that each NOC
   should install a server who provides locally collected information in
   a variety of forms for clients.

   Using a query language the client should be able to define the
   network object, the interface, the metrics and the time period to be
   provided.  Using a TCP based protocol the server will transmit the
   requested data.  Once these data is received by the client they could
   be processed and presented by a variety of tools needed. One
   possibility is to have an X-Window based tool that displays defined
   diagrams from data, supporting such types of diagrams being feed into
   the X-window tool directly from the statistical server. Another
   complementary method would be to generate PostScript output to be
   able to print the diagrams. In all cases there should be the
   possibility to store the retrieved data locally for later processing.

8.2 Inclusion of Variables not in the Internet Standard MIB

   As has been pointed out above in the categorization of metrics there
   are metrics which certainly could have been recommended if being
   available in the Internet Standard MIB. To facilitate for such
   metrics to be part of the set of recommended metrics it will be
   necessary to specify a subtree in the Internet Standard MIB
   containing variables judged necessary in the scope of performing
   operational statistics.

8.3 Detailed Resource Utilization Statistics

   One area of interest not covered in the above description of metrics
   and presentation formats is to present statistics on detailed views
   of the traffic flows. Such views could include statistics on a per
   application basis and on a per protocol basis. Today such metrics are
   not part of the Internet Standard MIB. Tools like the NSF NNStat are
   being used to gather information of this kind. A possible way to



Stockman                                                       [Page 20]

RFC 1404                 Operational Statistics             January 1993


   achieve such data could be to define a NNStat MIB or to include such
   variables in the above suggested operational statistics MIB subtree.

APPENDIX A

    Some formulas for statistical aggregation

    The following naming conventions are being used:


        For poll values poll(n)_j