As per Relevance of the word aggregation, we have this rfc below:
Network Working Group M.
Request For Comments: 1857 Pittsburgh Supercomputing
Obsoletes: 1404 October 1995
Category:
A Model for Common Operational
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This memo describes a model for operational statistics in
Internet. It gives recommendations for metrics, measurements
polling periods and presentation formats and defines a format for
exchange of operational statistics
The author would like to thank the members of the
Statistics Working Group of the IETF whose efforts made this
possible, particularly Bernhard Stockman, author of RFC 1404,
Nevil Brownlee, who produced the revised BNF description of
model. Wherever possible, their text has been changed as little
feasible
Table of
1. Introduction ............................................. 2
2. The Model ................................................ 5
2.1 Metrics and Polling Periods .............................. 5
2.2 Format for Storing Collected Data ........................ 6
2.3 Reports .................................................. 6
2.4 Security Issues .......................................... 6
3. Categorization of Metrics ................................ 7
3.1 Overview ................................................. 7
3.2 Categorization of Metrics Based on Measurement Areas ..... 7
3.2.1 Utilization Metrics ...................................... 7
3.2.2 Performance Metrics ...................................... 7
3.2.3 Availability Metrics ..................................... 8
3.2.4 Stability Metrics ........................................ 8
3.3 Categorization Based on Availability of Metrics .......... 8
3.3.1 Per Interface Variables Already in Standard MIB .......... 8
3.3.2 Per Interface Variables in Private Enterprise MIB ........ 9
3.3.3 Per interface Variables Needing High Resolution Polling .. 9
Lambert Informational [Page 1]
RFC 1857 Operational Statistics October 1995
3.3.4 Per Interface Variables not in any MIB ................... 9
3.3.5 Per Node Variables ....................................... 9
3.3.6 Metrics not being Retrievable with SNMP ................. 10
3.4 Recommended Metrics ..................................... 10
4. Polling Frequencies ..................................... 10
4.1 Variables Needing High Resolution Polling ............... 11
4.2 Variables not Needing High Resolution Polling ........... 11
5. Pre-Processing of Raw Statistical Data .................. 11
5.1 Optimizing and Concentrating Data to Resources .......... 11
5.2 Aggregation of Data ..................................... 12
6. Storing of Statistical Data ............................. 12
6.1 The Storage Format ...................................... 13
6.1.1 The Label Section ....................................... 14
6.1.2 The Device Section ...................................... 15
6.1.3 The Data Section ........................................ 17
6.2 Storage Requirement Estimations ......................... 17
7. Report Formats .......................................... 18
7.1 Report Types and Contents ............................... 18
7.2 Contents of the Reports ................................. 19
7.2.1 Offered Load by Link .................................... 19
7.2.2 Offered Load by Customer ................................ 19
7.2.3 Resource Utilization Reporting .......................... 20
7.2.3.1 Utilization as Maximum Peak Behavior .................... 20
7.2.3.2 Utilization as Frequency Distribution of Peaks .......... 20
8. Considerations for Future Development ................... 20
8.1 A Client/Server Based Statistical Exchange System ....... 21
8.2 Inclusion of Variables not in the Internet Standard MIB . 21
8.3 Detailed Resource Utilization Statistics ................ 21
Appendix A Some formulas for statistical aggregation ........... 22
Appendix B An example .......................................... 24
Security Considerations ......................................... 27
Author's Address ................................................ 27
1.
Many network administrations commonly collect and archive
management metrics that indicate network utilization, growth
reliability. The primary goals of this activity are to
near-term problem isolation and longer-term network planning
the organization. There is also the broader goal of
problem isolation and network planning among network administrations
This broader goal is likely to become increasingly important as
Internet continues to grow, particularly as the number of
service providers expands and the quality of service
providers becomes more of a concern
Lambert Informational [Page 2]
RFC 1857 Operational Statistics October 1995
There exist a variety of network management tools for the
and presentation of network management metrics. However,
kinds of measurement and presentation techniques make it
to compare data among networks. In addition, there is not
agreement on what metrics should be regularly collected or how
should be displayed
There needs to be an agreed-upon model
1) A minimal set of common network management metrics to
the goals stated above
2) Tools for collecting these metrics
3) A common interchange format to facilitate the usage of
data by common presentation tools
4) Common presentation formats
Under this Operational Statistics model, collection tools
collect and store data to be retrieved later in a given format
presentation tools displaying the data in a predefined way. (
figure below.)
Lambert Informational [Page 3]
RFC 1857 Operational Statistics October 1995
The Operational Statistics
(Collection of common metrics, by commonly available tools, stored
a common format, displayed in common formats by commonly
presentation tools.)
!-----------------------!
! Network !
!---+---------------+---!
/ \
/ \
/ \
--------+------ ----+---------
! New ! ! Old !
! Collection ! ! Collection !
! Tool ! ! Tool !
!---------+---! !------+-----!
\ !
\ !-------+--------!
\ ! Post-Processor !
\ !--+-------------!
\ /
\ /
\ /
!--+-------+---!
! Common !
! Statistics !
! Database !
!-+--------+---!
/ \
/ \
/ \
/ !-+-------------!
/ ! Pre-Processor !
/ !-------+-------!
!-----------+--! !
! New ! !-------+-------!
! Presentation ! ! Old !
! Tool ! ! Presentation !
!---------+----! ! Tool !
\ !--+------------!
\ /
\ /
!-+---------------+-!
! Graphical Output !
! (e.g., to paper !
! or X Window) !
!-------------------!
Lambert Informational [Page 4]
RFC 1857 Operational Statistics October 1995
This memo gives an overview of this model for common
statistics. The model defines the gathering, storing and
of network operational statistics and classifies the types
information that should be available at each network operation
(NOC) conforming to this model
The model defines a minimal set of metrics and discusses how
metrics should be gathered and stored. It gives recommendations
the content and layout of statistical reports which make possible
easy comparison of network statistics among NOCs
The primary purpose of this model is to define mechanisms by
NOCs could share most effectively their operational statistics.
intent of this model is to specify a baseline capability that
conforming to the model may support with minimal development
and minimal ongoing effort
2. The
The model defines three areas of interest on which all
concepts are based
1) The definition of a minimal set of metrics to be gathered
2) The definition of a format for storing collected
data
3) The definition of methods and formats for generating reports
The model indicates that old tools currently in use could
retrofitted into the new paradigm. This could be done by
conversion filters between old and new tools. In this sense
model intends to advocate the development of freely
software for use by participating NOCs
One basic idea of the model is that statistical data stored at
place could be retrieved and displayed at some other place
2.1. Metrics and Polling
Here the value is 0.
The intent here is to define a minimal set of metrics that could
gathered easily using standard SNMP-based network management tools
Thus, these metrics should be available as variables in the
Standard MIB
Lambert Informational [Page 5]
RFC 1857 Operational Statistics October 1995
If the Internet Standard MIB were changed, this minimal set
metrics should be reconsidered, as there are many metrics
as important, but not currently defined in the standard MIB
Some metrics which are highly desirable to collect are probably
retrievable using SNMP. Therefore, tools and methods for
such metrics should be defined explicitly if such metrics are to
considered. This is, however, outside of the scope of this memo
2.2. Format for Storing Collected
A format for storing data is defined. The intent is to
redundant information by using a single header structure wherein
information relevant to a certain set of statistical data is stored
This header section will give information about when and where
corresponding statistical data were collected
2.3.
Some basic classes of reports are suggested, addressing
views of network behavior. Reports of total octets and packets
some time period are regarded as essential to give an overall view
the traffic flow in a network. Differentiation between
and protocols is regarded as needed to give ideas on which type
traffic is dominant. Reports on resource utilization
recommended
The time period which a report spans may vary depending on
intent. In engineering and operations daily or weekly reports may
sufficient, whereas for capacity planning there may be a need
longer-term reports
2.4. Security
There are legal, ethical and political concerns about data sharing
People, in particular Network Service Providers, are concerned
showing data that may make one of their networks look bad
For this reason there is a need to insure integrity, conformity
confidentiality of the shared data. To be useful, the same
should be collected from all involved sites and it should
collected at the same interval
Lambert Informational [Page 6]
RFC 1857 Operational Statistics October 1995
3. Categorization of
3.1.
This section gives a classification of metrics with regard to
and ease of retrieval. A recommendation of a minimal set of
is given. This section also gives some hints on metrics to
considered for future inclusion when available in the
management environment. Finally some thoughts on storage
are presented
3.2. Categorization of Metrics Based on Measurement
The metrics used in evaluating network traffic could be
into (at least) four major categories
o Utilization
o Performance
o Availability
o Stability
3.2.1. Utilization
This category describes different aspects of the total traffic
forwarded through the network. Possible metrics include
o Total input and output packets and
o Various peak
o Per protocol and per application
3.2.2. Performance
These metrics relate to quality of service issues such as delays
congestion situations. Possible metrics include
o RTT metrics on different protocol
o Number of collisions on a bus
o Number of ICMP Source Quench
o Number of packets
Lambert Informational [Page 7]
RFC 1857 Operational Statistics October 1995
3.2.3. Availability
These metrics could be viewed as gauging long term accessibility
different protocol layers. Possible metrics include
o Line availability as percentage
o Route
o Application
3.2.4. Stability
These metrics describe short-term fluctuations in the network
degrade the service level. Changes in traffic patterns also could
recognized using these metrics. Possible metrics include
o Number of fast line status
o Number of fast route changes (also known as route flapping
o Number of routes per interface in the
o Next hop count
o Short term ICMP
3.3. Categorization Based on Availability of
To be able to retrieve metrics, the corresponding variables must
accessible at every network object which is part of the
domain for which statistics are being collected
Some metrics are easily retrievable because they are defined
variables in the Internet Standard MIB. Other metrics may
retrievable because they are part of some vendor's private
MIB subtree. Finally, some metrics are considered irretrievable
either because they are not possible to include in the SNMP
or because their measurement would require extensive polling (
the network with management traffic).
The metrics categorized below could each be judged as important
evaluating network behavior. This list may serve as a basis
revisiting the decisions on which metrics are to be regarded
reasonable and desirable to collect. If the availability of
metrics listed below changes, these decisions may change
3.3.1. Per Interface Variables Already in Internet Standard MIB (
easy to retrieve
ifInUcastPkts (unicast packets in
ifOutUcastPkts (unicast packets out
ifInNUcastPkts (non-unicast packets
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 (
could sometimes be retrievable
discarded packets
discarded packets
congestion events
congestion events
aggregate
interface
3.3.3. Per Interface Variables Needing High Resolution Polling (
is hard due to resulting network load
interface queue
seconds missing
interface
route
interface next hop
3.3.4. Per Interface Variables not in any Known MIB (thus
to retrieve using SNMP but possible to include in a MIB
link layer packets
link layer packets
link layer octets
link layer octets
packet interarrival
packet size
3.3.5. Per Node Variables (not categorized here
per-protocol packets
per-protocol packets
per-protocol octets
per-protocol octets
packets discarded
packets discarded
packet size
system
poll delta
reboot
Lambert Informational [Page 9]
RFC 1857 Operational Statistics October 1995
3.3.6. Metrics not Retrievable with
delays (RTTs) on different protocol
application layer
peak behavior
3.4. Recommended
A large number of metrics could be considered for collection in
process of doing network statistics. To facilitate general
for this model, there is a need to define a minimal set of
that are both essential and retrievable in a majority of today'
network objects. General retrievability is equated with presence
the Internet Standard MIB
The following metrics from the Internet Standard MIB were chosen
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
The purpose of polling at specified intervals is to gather
to serve as a basis for trend and capacity planning. From
operational data it should be possible to derive engineering
management data. It should be noted that all polling and
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
To be able to detect peak behavior, it is recommended that a
of 1 minute (60 seconds) at a maximum be used in gathering
data. The metrics to be collected at this frequency are
for each
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.
initial polling frequency value will be part of the
statistical data as described in section 6.1.2 below
4.2. Variables not Needing High Resolution
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
specified, but it is recommended that the period chosen be an
multiple of 60 seconds
5. Pre-Processing of Raw Statistical
5.1. Optimizing and Concentrating Data to
To avoid storing redundant data in what might be a shared
system, it is desirable to preprocess the raw data. For example, if
link is down there is no need to continuously store a counter
is not changing. The use of the variables sysUpTime and
Lambert Informational [Page 11]
RFC 1857 Operational Statistics October 1995
makes it possible not to have to continuously store data
from links and nodes where no traffic has been transmitted for
period of time
Another aspect of processing is to decouple the data from the
interface being polled. The intent should be to convert such
into the resource of interest as, for example, the traffic on a
link. Changes of interface in a gateway for a given link should
be visible in the resulting data
5.2. Aggregation of
At many sites, the volume of data generated by a polling period of 1
minute will make aggregation of the stored data desirable if
necessary
Aggregation here refers to the replacement of data values on a
of time intervals by some function of the values over the union
the intervals. Either raw data or shorter-term aggregates may
aggregated. Note that aggregation reduces the amount of data,
also reduces the available information
In this model, the function used for the aggregation is either
arithmetic mean or the maximum, depending on whether it is desired
track the average or peak value of a variable
Details of the layout of the aggregated entries in the data file
given in section 6.1.3.
Suggestions for aggregation periods
Over
24 hour period aggregate to 15 minutes
1 month period aggregate to 1 hour
1 year period aggregate to 1
6. Storing of Statistical
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
the intent of minimizing redundant information and thus
storage requirements. If a client server based model for
remote statistical data were later developed, the specified
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,
would not necessarily be used for actual data storage. That
its goal is to provide complete, self-contained, portable files
rather than to describe a full database for storing them
6.1. The Storage
All white space (including tabs, line feeds and carriage returns
within a file is ignored. In addition all text from a # symbol
the following end of line (inclusive) is also ignored
stat-data ::= [ ]
stat-section ::= | |
A data file must contain at least one device section and at least
label section. At least one data section must be associated
each label section. A device section must precede any data
which uses tags defined within it
A data section may appear in the file (in which case it is called
internal data section and is preceded by a label section) or
another file (in which case it is called an external data section
is specified in an external label section). Such an external
may contain one and only one data section
A label section indicates the start and finish times for
associated data section or sections, and a list of the names of
tags they contain. Within a data file there is an ordering of
sections. This depends only upon their relative position in
file. All internal data sections associated with the first
record must precede those associated with the second label record
and so on
Here are some examples of valid data files
Both these files start with a label section giving the times
tag-name lists for the device and data sections which follow
This file begins with a device section (which specifies tags used
its data sections) then has three 'external' label sections, each
which points to a separate data section. The data sections need
use all the tags defined in the device section; this is indicated
Lambert Informational [Page 13]
RFC 1857 Operational Statistics October 1995
the tag-name lists in their label sections
..
In this example default-dev is a full device section, including
complete tag-table, with initial polling and aggregation
specified for each variable in each variable-field. There is
label or data for default-dev--it is there purely to provide
tag-list information. Dev-1, dev-2, ... are device sections for
series of different devices. They each have their description
(network-name, router-name, etc), but no tag-table. Instead
rely on using the tag-table from default-device. A default-
record, if present, must be the first item in the data file
Label-1, label-2, etc. are label sections which point to
containing data sections for each device
6.1.1. The Label
label-section ::= BEGIN_LABEL location>
END_
data-location ::= |
tag-name-list ::= [ ]
The label section gives the start and stop times for
corresponding data section (or sections) and a list of the tags
uses. If a data location is given it specifies the name of a
containing its data section; otherwise the data section follows
this file
start-time ::=
stop-time ::=
data-file-name ::=
time-string ::=
year ::=
month ::= 01..12
day ::= 01..31
hour ::= 00..23
minute ::= 00..59
second ::=
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
seconds, as is done (for example) by ntp. If a time-zone
during a data file--e.g. because daylight savings time
ended--this should be recorded by ending the current data section
writing a device section with the new time-zone and starting a
data section
6.1.2. The Device
device-section ::= BEGIN_DEVICE END_
device-field ::=
<optional-tag-table
optional-tag-table ::= |
network-name ::=
router-name ::=
link-name ::=
bw-value ::=
proto-type ::= IP | DECNET | X.25 | CLNS | IPX |
proto-addr ::=
time-zone ::= [+|-] [00..13] [00..59]
tag-table ::= [ ]
tag-desc ::= <variable-field-list
tag ::=
tag-class ::= total |
variable-field-list ::= <variable-field
[ <variable-field> ]
variable-field ::= <variable-name>
<aggregation-period
variable-name ::=
initial-polling-period ::=
aggregation-period ::=
The network-name is a human readable string indicating to
network the logged data belong
The router-name is given as an ASCII string, allowing for
other than IP domain names (which are names of interfaces,
routers).
The link-name is a human readable string indicating the
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
as a floating-point number, e.g. 1536000 or 1.536e6. A zero
indicates that the actual bandwidth is unknown; one instance of
would be a Frame Relay link with Committed Information Rate
from Burst Rate
The proto-type field describes to which network architecture
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
interface being logged. The actual form of this address is
on the protocol type as indicated in the proto-type field.
Internet connected interfaces the dotted-quad notation should
used
The time-zone indicates the time difference that should be added
the time-stamp in the data-section to give the local time for
logged interface. Note that the range for time-zone is sufficient
allow for all possibilities, not just those which fall on 30-
multiples
The tag-table lists all variables being polled. Variable names
the fully qualified Internet MIB names. The table may
multiple tags. Each tag must be associated with only one polling
aggregation period. If variables are being polled or aggregated
different periods, a separate tag in the table must be used for
period
As variables may be polled with different polling periods within
same set of logged data, there is a need to explicitly associate
polling period with each variable. After processing, the
period covered may have changed compared to the initial
period and this should be noted in the aggregation period field.
initial polling period and aggregation period are given in seconds
Original data values, and data values which have been aggregated
adding them together, will have a tag-class of 'total.' Data
which have been aggregated by finding the maximum over an
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
would have difficulty distinguishing between a variable
(continuing the variable-field list for this tag) or a tag (
the next tag of the tag table). To make the distinction clearer to
human reader one should use different kinds of brackets for each,
example {} for the tag-table list and [] for the variable-
Lambert Informational [Page 16]
RFC 1857 Operational Statistics October 1995
lists
6.1.3. The Data
data-section ::= BEGIN_DATA
[ ] END_
data-field ::=
delta-val-list ::= LEFT [ ]
poll-delta ::=
delta-val ::=
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;
should be a one-to-one mapping betwen variables and values.
data-field begins with the timestamp for this poll followed by
tag defining the polled variables followed by a polling delta
giving the period of time in seconds since the previous poll.
variable values are stored as delta values for counters and
absolute values for non-counter values such as OperStatus.
timestamp is in UTC and the time-zone field in the device section
used to compute the local time for the device being logged
Comma, semicolon or colon may be used as a field separator.
one would use commas within a line, semicolon at the end of a
and a colon after keywords such as BEGIN_LABEL
Parentheses (), brackets [] or braces {} may be used as LEFT
RIGHT brackets around tag-name, tag-table and delta-val lists.
should be used in corresponding pairs, although combinations such
(], [} etc. are syntactically valid
6.2. Storage Requirement
The header sections are not counted in this example. Assuming
the maximum polling intensity is used for all 12
variables, that the size in ASCII of each variable is eight bytes
that there are no timestamps which are fractional seconds,
following calculations will give an estimate of storage
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
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
1 min 15 min 1 hour 1
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
672*242 = 163 kB
For each month 24*30 = 720 entries are stored with a total size
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
This section suggests some report formats and defines the metrics
be used in such reports
7.1. Report Types and
There are longer-term needs for monthly and yearly reports
long-term tendencies in the network. There are short-term
reports giving information about medium-term changes in
Lambert Informational [Page 18]
RFC 1857 Operational Statistics October 1995
behavior which could serve as input to the medium-term
approach. Finally, there are daily reports giving the
overviews needed in the daily operations of a network
These reports should give information on
Offered Load Total traffic at external
Offered Load Segmented by "Customer
Offered Load Segmented protocol/application
Resource Utilization Link/
7.2. Content of the
7.2.1. Offered Load by
Metric categories: input octets per external
output octets per external
input packets per external
output packets per external
The intent is to visualize the overall trend of network traffic
each connected external interface. This could be done as a bar-
giving the totals for each of the four metric categories. Based
the time period selected this could be done on a hourly, daily
monthly or yearly basis
7.2.2. Offered Load by
Metric categories: input octets per
output octets per
input packets per
output packets per
The recommendation here is to sort the offered load (in
order) by customer. Plot the function F(n), where F(n) is
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
customers
The definition of what is meant by a "customer" has to be
locally at the site where the statistics are being gathered
A cumulative plot could be useful as an overview of how traffic
distributed among users since it enables one to quickly pick off
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
bar chart is to compute both the average value over some period
the peak value during the same period. The average and peak
are then displayed in the same bar
7.2.3. Resource Utilization
7.2.3.1. Utilization as Maximum Peak
Link utilization is used to capture information on network loading
The polling interval must be small enough to be significant
respect to variations in human activity, since this is the
that drives variations in network loading. On the other hand,
is no need to make it smaller than an interval over which
delay would notably impact productivity. For this reason, 30
is a good estimate of the time at which people remain in one
and over which prolonged high delay will affect their productivity
To track 30 minute variations, there is a need to sample twice
frequently, i.e., every 15 minutes. Use of the polling period of 10
minutes recommended above should be sufficient to capture
in utilization
A possible format for reporting utilizations seen as peak
is to use a method of combining averages and peak measurements
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
diagram were totals on an hourly basis then the peak would be
maximum ten-minute period in each hour
By combining the average and the maximum values for a certain
period, it should be possible to detect line utilization
bottlenecks due to temporary high loads
7.2.3.2. Utilization Visualized as a Frequency Distribution of
Another way of visualizing line utilization is to put the ten-
samples in a histogram showing the relative frequency among
samples versus the load
8. Considerations for Future
This memo is the first effort at formalizing a common basis
operational statistics. One major guideline in this work has been
keep the model simple to facilitate the easy integration of
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
the scope and usability of the model
8.1. A Client/Server Based Statistical Exchange
A possible path for development could be the definition of
client/server based architecture for providing Internet access
operational statistics. Such an architecture envisions that each
install a server which provides locally collected information in
variety of forms for clients
Using a query language, the client should be able to define
network object, the interface, the metrics and the time period to
provided. Using a TCP-based protocol, the server will transmit
requested data. Once these data are received by the client,
could be processed and presented by a variety of tools.
possibility is to have an X-Window based tool that displays
diagrams from data, supporting such diagrams being fed into the X
Window tool directly from the statistical server.
complementary method would be to generate PostScript output to
the diagrams. In all cases it should be possible to store
retrieved data locally for later processing
The client/server approach is discussed further by Henry Clark
RFC 1856.
8.2. Inclusion of Variables not in the Internet Standard
As has been pointed out above in the categorization of metrics,
are metrics which certainly could have been recommended if they
available in the Internet Standard MIB. To facilitate the
of such metrics in the set of recommended metrics, it will
necessary to specify a subtree in the Internet Standard
containing variables judged necessary in the scope of
operational statistics
8.3. Detailed Resource Utilization
One area of interest not covered in the above description of
and presentation formats is to present statistics on detailed
of the traffic flows. Such views could include statistics on a
application basis and on a per protocol basis. Today such metrics
not part of the Internet Standard MIB. Tools like the NSF NNStat
being used to gather information of this kind. A possible way
achieve such data could be to define an NNStat MIB or to include
variables in the above suggested operational statistics MIB subtree
Lambert Informational [Page 21]
RFC 1857 Operational Statistics October 1995
APPENDIX
Some formulas for statistical
The following naming conventions are used
For poll values poll(n)_
n = Polling or aggregation
j = Entry
poll(900)_j is thus the 15 minute total value
For peak values peak(n,m)_
n = Period over which the peak is
m = The peak period
j = Entry
peak(3600,900)_j is thus the maximum 15 minute period calculated
1 hour
Assume a polling over 24 hour period giving 1440 logged entries
=========================
Without any aggregation we
poll(60)_1
......
poll(60)_1440
========================
15 minute aggregation will give 96 entries of total
poll(900)_1
....
poll(900)_96
j=(n+14)
poll(900)_k = SUM poll(60)_j n=1,16,31,...1426
j=n k=1,2,....,96
There will also be 96 one-minute peak values
Lambert Informational [Page 22]
RFC 1857 Operational Statistics October 1995
j=(n+14)
peak(900,60)_k = MAX poll(60)_j n=1,16,31,....,1426
j=n k=1,2,....,96
=======================
The next aggregation step is from 15 minutes to 1 hour. This
24 totals
j=(n+3)
poll(3600)_k = SUM poll(900)_j n=1,5,9,.....,93
j=n k=1,2,....,24
and 24 one-minute peaks calculated over each hour
j=(n+3)
peak (3600,60)_k = MAX peak(900,60)_j n=1,5,9,.....,93
j=n k=1,2,....24
and finally 24 15-minute peaks calculated over each hour
j=(n+3)
peak (3600,900) = MAX poll(900)_j n=1,5,9,.....,93
j=
===================
The next aggregation step is from 1 hour to 24 hours. For each
with 1440 entries as above this will
j=(n+23)
poll(86400)_k = SUM poll(3600)_j n=1,25,51,.......
j=n k=1,2............
j=(n+23)
peak(86400,60)_k = MAX peak(3600,60)_j n=1,25,51,....
j=n k=1,2.........
which gives the busiest 1 minute period over 24 hours
j=(n+23)
peak(86400,900)_k = MAX peak(3600,900)_j n=1,25,51,....
j=n k=1,2,........
which gives the busiest 15 minute period over 24 hours
j=(n+23)
Lambert Informational [Page 23]
RFC 1857 Operational Statistics October 1995
peak(86400,3600)_k = MAX poll(3600)_j n=1,25,51,....
j=n k=1,2,........
which gives the busiest 1 hour period over 24 hours
===================
There will probably be a difference between the three peak values
the final 24 hour aggregation. A smaller peak period will give
values than a longer one, i.e., if adjusted to be
comparable
poll(86400)/3600 < peak(86400,3600) < peak(86400,900)*4
< peak(86400,60)*60
APPENDIX
An
Assuming below data storage
BEGIN_DEVICE
...
{
UNI-1,total: [ifInOctet, 60, 60,ifOutOctet, 60, 60];
BRD-1,total: [ifInNUcastPkts,300,300,ifOutNUcastPkts,300,300]
}
...
which
BEGIN_DATA
19920730000000,UNI-1,60:(val1-1,val2-1);
19920730000060,UNI-1,60:(val1-2,val2-2);
19920730000120,UNI-1,60:(val1-3,val2-3);
19920730000180,UNI-1,60:(val1-4,val2-4);
19920730000240,UNI-1,60:(val1-5,val2-5);
19920730000300,UNI-1,60:(val1-6,val2-6);
19920730000300,BRD-1,300:(val1-7,val2-7);
19920730000360,UNI-1,60:(val1-8,val2-8);
...
Aggregation to 15 minutes
BEGIN_DEVICE
...
Lambert Informational [Page 24]
RFC 1857 Operational Statistics October 1995
{
UNI-1,total: [ifInOctet, 60,900,ifOutOctet, 60,900];
BRD-1,total: [ifInNUcastPkts,300,900,ifOutNUcastPkts,300,900];
UNI-2,peak: [ifInOctet, 60,900,ifOutOctet, 60,900];
BRD-2,peak: [ifInNUcastPkts,300,900,ifOutNUcastPkts,300,900]
}
...
where UNI-1 is the 15 minute
BRD-1 is the 15 minute
UNI-2 is the 1 minute peak over 15 minute (peak = peak(1))
BRD-2 is the 5 minute peak over 15 minute (peak = peak(1))
which
BEGIN_DATA
19920730000900,UNI-1,900:(tot-val1,tot-val2);
19920730000900,BRD-1,900:(tot-val1,tot-val2);
19920730000900,UNI-2,900:(peak(1)-val1,peak(1)-val2);
19920730000900,BRD-2,900:(peak(1)-val1,peak(1)-val2);
19920730001800,UNI-1,900:(tot-val1,tot-val2);
19920730001800,BRD-1,900:(tot-val1,tot-val2);
19920730001800,UNI-2,900:(peak(1)-val1,peak(1)-val2);
19920730001800,BRD-2,900:(peak(1)-val1,peak(1)-val2);
...
Next aggregation step to 1 hour generates
BEGIN_DEVICE
...
{
UNI-1,total: [ifInOctet, 60,3600,ifOutOctet, 60,3600];
BRD-1,total: [ifInNUcastPkts,300,3600,ifOutNUcastPkts,300,3600];
UNI-2,peak: [ifInOctet, 60,3600,ifOutOctet, 60,3600];
BRD-2,peak: [ifInNUcastPkts,300, 900,ifOutNUcastPkts,300, 900];
UNI-3,peak: [ifInOctet, 900,3600,ifOutOctet, 900,3600];
BRD-3,peak: [ifInNUcastPkts,900,3600,ifOutNUcastPkts,900,3600]
}
UNI-1 is the one hour
BRD-1 is the one hour
UNI-2 is the 1 minute peak over 1 hour (peak of peak = peak(2))
BRD-2 is the 5 minute peak over 1 hour (peak of peak = peak(2))
UNI-3 is the 15 minute peak over 1 hour (peak = peak(1))
BRD-3 is the 15 minute peak over 1 hour (peak = peak(1))
Lambert Informational [Page 25]
RFC 1857 Operational Statistics October 1995
which
BEGIN_DATA
19920730003600,UNI-1,3600:(tot-val1,tot-val2);
19920730003600,BRD-1,3600:(tot-val1,tot-val2);
19920730003600,UNI-2,3600:(peak(2)-val1,peak(2)-val2);
19920730003600,BRD-2,3600:(peak(2)-val1,peak(2)-val2);
19920730003600,UNI-3,3600:(peak(1)-val1,peak(1)-val2);
19920730003600,BRD-3,3600:(peak(1)-val1,peak(1)-val2);
19920730007200,UNI-1,3600:(tot-val1,tot-val2);
19920730007200,BRD-1,3600:(tot-val1,tot-val2);
19920730007200,UNI-2,3600:(peak(2)-val1,peak(2)-val2);
19920730007200,BRD-2,3600:(peak(2)-val1,peak(2)-val2);
19920730007200,UNI-3,3600:(peak(1)-val1,peak(1)-val2);
19920730007200,BRD-3,3600:(peak(1)-val1,peak(1)-val2);
...
Finally aggregation step to 1 day generates
BEGIN_DEVICE
...
{
UNI-1,total: [ifInOctet, 60,86400,ifOutOctet, 60,86400];
BRD-1,total: [ifInNUcastPkts, 300,86400,ifOutNUcastPkts, 300,86400];
UNI-2,peak: [ifInOctet, 60,86400,ifOutOctet, 60,86400];
BRD-2,peak: [ifInNUcastPkts, 300, 900,ifOutNUcastPkts, 300, 900];
UNI-3,peak: [ifInOctet, 900,86400,ifOutOctet, 900,86400];
BRD-3,peak: [ifInNUcastPkts, 900,86400,ifOutNUcastPkts, 900,86400];
UNI-4,peak: [ifInOctet, 3600,86400,ifOutOctet, 3600,86400];
BRD-4,peak: [ifInNUcastPkts,3600,86400,ifOutNUcastPkts,3600,86400]
}
...
UNI-1 is the 24 hour
BRD-1 is the 24 hour
UNI-2 is the 1 minute peak over 24
(peak of peak of peak = peak(3))
UNI-3 is the 15 minute peak over 24 hour (peak of peak = peak(2))
UNI-4 is the 1 hour peak over 24 hour (peak = peak(1))
BRD-2 is the 5 minute peak over 24
(peak of peak of peak = peak(3))
BRD-3 is the 15 minute peak over 24 hour (peak of peak = peak(2))
BRD-4 is the 1 hour peak over 24 hour (peak = peak(1))
which
Lambert Informational [Page 26]
RFC 1857 Operational Statistics October 1995
BEGIN_DATA
19920730086400,UNI-1,86400:(tot-val1,tot-val2);
19920730086400,BRD-1,86400:(tot-val1,tot-val2);
19920730086400,UNI-2,86400:(peak(3)-val1,peak(3)-val2);
19920730086400,BRD-2,86400:(peak(3)-val1,peak(3)-val2);
19920730086400,UNI-3,86400:(peak(2)-val1,peak(2)-val2);
19920730086400,BRD-3,86400:(peak(2)-val1,peak(2)-val2);
19920730086400,UNI-4,86400:(peak(1)-val1,peak(1)-val2);
19920730086400,BRD-4,86400:(peak(1)-val1,peak(1)-val2);
19920730172800,UNI-1,86400:(tot-val1,tot-val2);
19920730172800,BRD-1,86400:(tot-val1,tot-val2);
19920730172800,UNI-2,86400:(peak(3)-val1,peak(3)-val2);
19920730172800,BRD-2,86400:(peak(3)-val1,peak(3)-val2);
19920730172800,UNI-3,86400:(peak(2)-val1,peak(2)-val2);
19920730172800,UNI-3,86400:(peak(2)-val1,peak(2)-val2);
19920730172800,UNI-4,86400:(peak(1)-val1,peak(1)-val2);
19920730172800,BRD-4,86400:(peak(1)-val1,peak(1)-val2);
...
Security
Security issues are discussed in Section 2.4.
Author's
Michael H.
Pittsburgh Supercomputing
4400 Fifth
Pittsburgh, PA 15213
Phone: +1 412 268-4960
Fax: +1 412 268-8200
EMail: lambert@psc.
Lambert Informational [Page 27]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
