[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A Data collection MIB
Just as an aside, what is the status of this working group? The last
post prior to yours was Aug. 30, the EOS WG web page was last modified
Jul 31, and was suppose to shutdown or re-charter Oct. 01. Are any of
the previous proposals still being considered?
On Wed, 14 Nov 2001, Nalin Pai wrote:
> Hoping to kick off a discussion on a MIB idea that I have been playing
> around with for sometime now. I have been in touch with Bryan Levin
> and David Battle regarding merging this idea with theirs
> We thought it would be best to throw this open to eos.
> This MIB is intended to help periodic data retrievals, when the data
> itself is a set of discontiguous rows spread across multiple tables.
> Likely applications are performance and accounting applications.
> For e.g.
> The user wants to periodically fetch
> - ifInOctets, ifOutOctets from ifTable
> - ifHCInOctets, ifHCOutOctets from ifXTable
> - dot3StatsLateCollisions, dot3StatsSingleCollisionFrames from
> and is interested only in a set of interfaces, lets say
> having ifIndex
> The use of get-bulk to fetch the required object instances would be
> inefficient since a lot of unnecessary object instances would also be
> retrieved. Also since all 3 tables need not have the same number of
> rows, it again may not be possible to use a single get-bulk
> request to fetch rows from all 3 tables simultaneously.
> The other option is to use get-exact request PDUs specifying the
> exact instances *everytime* the user is interested in the data. Also
> this does not take advantage of any sequential ifIndex ranges.
> Both of the above options are not too efficient.
> The idea here is to design a MIB that has the following properties.
> 1) Allows user to specify objects (columns) of interest.
> The objects can belong to different tables, as long as they are
> semantically related.
> This is a one time operation.
> 2) Allows user to specify object instances of interest (rows)
> Multiple row instances can be specified for maximum flexibility.
> This is a one time operation.
> 3) Row instances can be single indexed or multi-indexed.
> 4) Has an access table which is more like a "view" that contains
> exactly what the user has requested. The user can then issue
> get-bulk requests on the access table to retrieve the data.
> 5) Supports a file transfer kind of a mechanism as defined in the
> current draft-ietf-eos-snmp-bulkdata-00.txt. This gives the
> flexibility of either using SNMP requests on the access table
> or populating a file which can then be transferred off the device.
> 6) The access table has a mechanism to indicate sparse object
> instances (holes). Holes would be plugged in with a dummy instance
> and the same would be indicated using a bit map for each row.
> This MIB according to me has the following advantages.
> 1) The access table will contain only those object instances that the
> user interested in. This will encourage use of get-bulks and make
> the use of a get-bulk PDU to retrieve discontiguous object instances
> more efficient.
> 2) The access table provides a conceptual view based
> on multiple MIB tables. Again the use of a get-bulk allows the user
> to retrieve objects from multiple tables as if they belong to the
> same table. For e.g the user is interested in retrieving objects
> for ethernet interfaces from the IF-MIB and the ETHER-LIKE-MIB.
> 3) Since the user will typically use a get-bulk to retrieve entries
> from the access table, MIB implementation optimizations can be
> done to increase efficiency of data access for frequently polled
> MIBS like IF-MIB etc.
> (For e.g by pre-fetching a set of rows, knowing that the get-bulk
> will require them)
> 4) It is possible to support sparse objects, by having a sparse object
> indicator for every row in the access table. This object is a bit
> map that indicates whether an object instance in the row is valid
> or not. By plugging NULL object instances with a dummy, we can
> avoid re-ordering and maintain row semantics.
> 5) When combined with the file transfer mechanism defined in
> draft-ietf-eos-snmp-bulkdata-00.txt, the user has the flexibility
> of using SNMP requests or file transfers to get the required data.
> I am attaching a rough and a basic MIB draft. It also contains some
> text recommending a way for NMS's to fetch data from the access table.
> I have not included the file transfer mechanism as supported by
> Hoping to receive responses.