[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Eos -Aggregate MIB proposal
To address SNMP's "inefficient" data retrieval we have
proposed an MO aggregation approach. This is a simple MIB
based approach that allows manager applications to program
agents - define MOs of interest in terms of pre-defined MOs.
The manager defines an aggregate-MO instance in terms of
constituent MO instances the manager is interested in. Then
the manager does a 'get' on the aggregated-MO instance and
receives a string which can be decoded into the values of
the constituent MO-Instances.
The document, draft-glenn-mo-aggr-mib-02.txt, has been posted
on 7th September, 2002, and should be in the archives shortly.
It deals with aggregation of MO instances at the same time
instant (well, as far as the manager is concerned - it is the
values of the MO instances from one snapshot of the target
system). [The document is also available http://www.cysol.co.jp/
The changes since the presentation at the last Yokohama-IETF
are - an 'aggrErrorRec' 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 elements of the aggregated data. The
'moIndex' represents the position of the problematic MO instance
in the aggregated-MO value and moError represents the error
[Note: only exceptions are represented in aggrErrorRec]
There are Pros and Cons of the AggrMIB approach. The advantage
of the AggrMIB 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. The aggregation does
not depend on MOs of a single row, MOs in the same Table or even
MOs in the same MIB.
There is a price to be paid for the advantage:
At the agent end - servicing the aggregate MOs. (Not a big
At the manager end -
o The manager needs to program the agent to serve the
desired aggregate MO - a string of sets will be required.
o The manager needs to decode the BER-encoded value strings
and match the values to the ordered list of MOinstances.
o The manager will also need to decode the aggrErrorRec and
figure out which of the values are in error and what is
Considering the cost and the benefits - the cost seems insignificant.
Applications are doing much smarter things these days. A simple API
can handle the decoding aspect in a generic manner.
So, how does this relate to and compare with other proposals ?
Managed Object Aggregation produces the best OID compression that
can be achieved. (It just suppresses all but one of the OIDs !)
BUT, considering the overhead of the 'set's that are required to
set-up the aggregate MOs it would be a BAD idea to use aggregate
MOs for one time retrievals. The advantages of aggregation hold
in the case of multiple retrievals. [Jurgens OID coompression has
an edge here. It doesn't require any sets. But the degree of
compression that can be achieved depends on the constituent MO
instances. It does not suppress OIDs - just replaces them with
smaller OIDs ]
Wes's proposal (draft-hardaker-eos-oops-00.txt) provides much more
functionality in terms of online filters and stuff. I think that it
is high time that our applications could use such table manipulation
features. AggrMIB does not support filtering. But the oops approach
will probably not work as efficiently when the filters are not simple
e.g. when the target objects are in different tables.
As far as OID compression is concerned - AggrMIB is still better.
The Disman-Expression-MIB probably comes closest to the approach
of AggrMIB. Using the Expression-MIB, new MOs may be defined as
expressions of other MOs. However, no aggregation operator is
defined (the concatenation operator is available only for MOs of
type octet-string or Object Identifier)
If the expression MIB instrumentation is on a mid-level manager
it rould make good use of the AggrMIB on the target agent to fetch
all the MO instances pertaining to an expression at one go.
Let me have your comments