[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

EOS: Time-based Aggregate MIB proposal



Hi,

As an extension to the MO aggregation approach proposed in a
companion document (draft-glenn-mo-aggr-mo-02.txt) we are
proposing time-based aggregation of MOs.
The idea is simple - it uses a MIB-based approach to define a
time based aggregation object (TAgMO).
A user defines a TAgMO instance by specifying the MO instance
that needs to be sampled, the sampling interval and the desired
number of samples that will be included in one TAgMO instance.
The value of a TAgMO instance will include the timestamp
(sysuptime) at which the first sample was taken. With the
definitions done the user can do an SNMP 'get' on an instance
of the TAgMO to fetch the values of the constituent MO instance
sampled at the specified intervals.

The document -  draft-glenn-mo-taggr-mib-00.txt has been posted
on 7th September, 2002, and should be in the archives shortly.
It deals with aggregation of several samples of the same MO
instance sampled at user-defined intervals a user-defined
number of times. [The document is also available
http://www.cysol.co.jp/contrib/materials/
draft-glenn-mo-aggr-mib-02.txt]

The changes since the presentation at the last Yokohama-IETF
are - a 'tAggrErrorRec' object is added. This  takes care of
missing data and errors. It contains a list of <moIndex, moError>
tuples to indicate the exceptions that occured in fetching
the aggregated data. The moIndex represents the position of
the MO instance in the aggregated-MO value and moError
represents the error encountered.
  [Note: only exceptions are represented in tAggrErrorRec]

This tAggrMIB is most useful in getting information at regular
intervals (secs, decisecs, centisecs, millesecs.. ) albeit at
delay which is the lower bounded by the product of the sampling
interval and the number of samples in a TAgMO.
The advantage of the TAggrMIB approach is that it provides maximal
compression. A single OID of the aggregate MO instance suffices
instead of the OIDs of the constituent MO instances.

So, how does this relate to and compare with other proposals ?

The RMON-HistoryTable does record the time development of an
MO instance. But
   o for fetching the data one has to go through the standard
     laborious practice of using SNMP 'get's (or one of its variations)
     involving the OID and value of every instance of the object.
    (That is what we are complaining about!)
     There is NO savings on Bandwidth, no compression.
   o the smallest interval is limited to 1 sec .


Let me have your comments.

     Glenn