rfc1857.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,516 行 · 第 1/4 页

   The label section gives the start and stop times for its
   corresponding data section (or sections) and a list of the tags it
   uses.  If a data location is given it specifies the name of a file
   containing its data section; otherwise the data section follows in
   this file.

   start-time       ::= <time-string>
   stop-time        ::= <time-string>
   data-file-name   ::= <ASCII-string>

   time-string      ::= <year><month><day><hour><minute><second>

   year             ::= <digit><digit><digit><digit>
   month            ::= 01..12
   day              ::= 01..31
   hour             ::= 00..23
   minute           ::= 00..59
   second           ::= <float>

   The start-time and stop-time are specified in UTC.






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


   A maximum of 60.0 is specified for 'seconds' so as to allow for leap
   seconds, as is done (for example) by ntp. If a time-zone changes
   during a data file--e.g.  because daylight savings time has
   ended--this should be recorded by ending the current data section,
   writing a device section with the new time-zone and starting a new
   data section.

6.1.2.  The Device Section

   device-section  ::= BEGIN_DEVICE <FS> <device-field> <FS> END_DEVICE
   device-field   ::= <network-name><FS><router-name><FS><link-name<FS>
                          <bw-value><FS><proto-type><FS><proto-addr><FS>
                          <time-zone> <optional-tag-table>
   optional-tag-table  ::= <FS> <tag-table> | <empty>

   network-name    ::= <ASCII-string>
   router-name     ::= <ASCII-string>
   link-name       ::= <ASCII-string>
   bw-value        ::= <float>
   proto-type      ::= IP | DECNET | X.25 | CLNS | IPX | AppleTalk
   proto-addr      ::= <ASCII-string>
   time-zone       ::= [+|-] [00..13] [00..59]

   tag-table       ::= <LEFT> <tag-desc> [ <FS> <tag-desc> ] <RIGHT>
   tag-desc        ::= <tag> <FS> <tag-class> <FS> <variable-field-list>

   tag             ::= <ASCII-string>
   tag-class       ::= total | peak

   variable-field-list    ::= <LEFT> <variable-field>
                                 [ <FS> <variable-field> ] <RIGHT>
   variable-field         ::= <variable-name><FS><initial-polling-period>
                                 <FS> <aggregation-period>

   variable-name          ::= <ASCII-string>
   initial-polling-period ::= <integer>
   aggregation-period     ::= <integer>

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

   The router-name is given as an ASCII string, allowing for styles
   other than IP domain names (which are names of interfaces, not
   routers).

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




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


   The units for bandwidth (bw-value) are bits per second, and are given
   as a floating-point number, e.g. 1536000 or 1.536e6.  A zero value
   indicates that the actual bandwidth is unknown; one instance of this
   would be a Frame Relay link with Committed Information Rate different
   from Burst Rate.

   The proto-type field describes to which network architecture the
   interface being logged is connected.  Valid types are IP, DECNET,
   X.25, CLNS, IPX and AppleTalk.

   The network address (proto-addr) is the unique numeric address of the
   interface being logged. The actual form of this address is dependent
   on the protocol type as indicated in the proto-type field. For
   Internet connected interfaces the dotted-quad notation should be
   used.

   The time-zone indicates the time difference that should be added to
   the time-stamp in the data-section to give the local time for the
   logged interface.  Note that the range for time-zone is sufficient to
   allow for all possibilities, not just those which fall on 30-minute
   multiples.

   The tag-table lists all 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, a separate tag in the table must be used for each
   period.

   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 processing, the actual
   period covered may have changed compared to the initial polling
   period and this should be noted in the aggregation period field.  The
   initial polling period and aggregation period are given in seconds.

   Original data values, and data values which have been aggregated by
   adding them together, will have a tag-class of 'total.'  Data values
   which have been aggregated by finding the maximum over an aggregation
   time interval will have a tag-class of 'peak.'

   The tag-table and variable-field-lists are enclosed in brackets,
   making the extent of each obvious.  Without the brackets a parser
   would have difficulty distinguishing between a variable name
   (continuing the variable-field list for this tag) or a tag (starting
   the next tag of the tag table).  To make the distinction clearer to a
   human reader one should use different kinds of brackets for each, for
   example {} for the tag-table list and [] for the variable-field



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


   lists.

6.1.3.  The Data Section

   data-section     ::= BEGIN_DATA <FS> <data-field>
                           [ <FS> <data-field> ] <FS> END_DATA
   data-field       ::= <time-string> <FS> <tag> <FS>
                           <poll-delta> <FS> <delta-val-list>

   delta-val-list   ::= LEFT <delta-val> [ <FS> <delta-val> ] RIGHT

   poll-delta       ::= <integer>
   delta-val        ::= <integer>

   FS            ::= , | ; | :
   LEFT          ::= ( | [ | {
   RIGHT         ::= ) | ] | }

   A data-field contains values for each variable in the specified tag.
   A new data field should be written for each separate poll; there
   should be a one-to-one mapping betwen variables and values.  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.

   Comma, semicolon or colon may be used as a field separator.  Normally
   one would use commas within a line, semicolon at the end of a line
   and a colon after keywords such as BEGIN_LABEL.

   Parentheses (), brackets [] or braces {} may be used as LEFT and
   RIGHT brackets around tag-name, tag-table and delta-val lists.  These
   should be used in corresponding pairs, although combinations such as
   (], [} etc. are syntactically valid.

6.2.  Storage Requirement Estimations

   The header sections are not counted in this example.  Assuming that
   the maximum polling intensity is used for all 12 recommended
   variables, that the size in ASCII of each variable is eight bytes and
   that there are no timestamps which are fractional seconds, the
   following calculations will give an estimate of storage requirements
   for one year of storing and aggregating statistical data.





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


   Assuming that data is saved according to the scheme

           1 minute non-aggregated           saved 1 day,
           15 minute aggregation period      saved 1 week,
           1 hour aggregation period         saved 1 month and
           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 = 189
   kB.

   For each week 4*24*7 = 672 entries are stored with a total size of
   672*242 = 163 kB.

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

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

   Grand total estimated storage for during one year = 775 kB.

7.  Report Formats

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

7.1.  Report Types and Contents

   There are longer-term needs for monthly and yearly reports showing
   long-term tendencies in the network. There are short-term weekly
   reports giving information about medium-term changes in network



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


   behavior which could    serve as input to the medium-term engineering
   approach.  Finally, there are daily reports giving the 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.  Content 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 intent 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 here is 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 nth ranked
   customers.

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

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





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


   A method of displaying both average and peak behaviors in the same
   bar chart 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

   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 variations in network loading. 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 of 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. Use of the polling period of 10
   minutes recommended above should be sufficient to capture variations
   in utilization.

   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 were totals on an hourly basis then the peak would be the
   maximum ten-minute period in each hour.

   By combining the average and the maximum values for a certain time
   period, it should 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 ten-minute
   samples in a histogram showing the relative frequency among the
   samples versus the load.

8.  Considerations for Future Development

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





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


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

8.1.  A Client/Server Based Statistical Exchange System

   A possible path for 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
   install a server which provides locally collected information in a
   variety of forms for clients.