[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIB objects vs OPs
That is a very good summary. Thank you. Among the MIB-based
retrieval mechanisms there was the initial Aggregate-MIB proposal
too. While the BulkData proposal does provide a solution for large
chunks of data in a rather offline manner, the Aggregate-MIB
attemts to address the problems of a (potentially large) number
of MO-instances in an online manner.
The essence is that we do need to have better data retrieval
mechanisms. I am not sure that there is one solution that solves
all the problems.
David T. Perkins wrote:
> At the Salt Lake City IETF, the issue of using MIB definitions vs
> new operations came up. The room was polled, and there were pluses
> and minuses for each approach.
> Here is a summary (and if I've forgotten any, let me know):
> Efficiently retrieval of a large quantity of regularly organized
> data from an agent. We are not talking about a "one-time" walk
> to "discover" existence and values attributes. This retrieval of
> status and statistics at predetermined intervals. (Glenn added a
> new twist in that he wanted a time series of values for a small
> set of instances at a measurement rate that is not possible using
> existing SNMP operations. But, it is really the same problem.)
> Current SNMP operations either cannot retrieve all of the data
> between desired measurement cycle, or create an unsupportable
> load on the network.
> Key Observation:
> Since the data has a regular organization (that is, it is the
> values of fixed columns of a table, with either all instances
> or a predetermined set of instances), there is much redundancy
> in the operands of existing SNMP operations. In particular, the
> OIDs that identify instances have the same prefix value for all
> instances of a column and have the same suffix value for all
> columns of a row. And the OID values consume much more space
> than the measured values.
> All solutions involve elimination of the redundant information.
> When this is done, then for not available instances, there must
> be a solution to keep the data regular. (This is called plugging
> An SNMP operation has the following benefits:
> 1) a management app that is already using SNMP request/response
> operations doesn't need to add support for another mechanism.
> The model is very simple. Request the data (chunks at a time)
> until all is retrieved, then "sleep" until the next poll cycle.
> 2) the existing SNMP security mechanisms can be used as is. Thus,
> no new work is needed to make different security mechanisms to
> work together. That is, a single set of rules via VACM need
> be set up to authorize access to the retrieved data.
> 3) most likely the existing routines that are used by the SNMP
> agent to access management can be used unmodified to support
> the new operation.
> And the problems:
> 1) new operations mean that new agent and manager SNMP engines
> must be created. This requires that vendors of this technology
> update their code before it will be available to device
> vendors and management app developers.
> 2) the addition of operations is only "architecturally" supported
> in SNMPv3. Many devices currently only support SNMPv1. Requiring
> a move to SNMPv3 to add support for the new operation is a
> high price to pay for the functionality.
> 3) using a connectionless transport with a "small" maximum message
> size prohibits streaming back a large response (it is effectively
> TCP with a window size of 1). The result is less time to send the
> data, but it may not be short enough if the polling cycle is short
> or the ammount of data is large.
> A MIB-based approach has the following benefits:
> 1) It can be done without modifying the SNMP engine of the agent
> or manager, and, thus, can be done independently of the SNMP
> technology vendor.
> 2) It is not restricted to using SNMP to retrieve the data, and thus
> a TCP connection can be used, which provides the best performance
> in returning a large amount of data.
> 3) It is independent of the version of SNMP, and, thus, can be used
> by agents that support only SNMPv1.
> And the problems:
> 1) It requires another communication mechanism to be used by the
> management app to retrieve the data. This could be an existing
> one like FTP (or HTTP). But this involves coordination of the
> management app with this other service including setting up
> security. This typically has porting issues.
> 2) It requires another communication mechanism to be provided by
> the managed system. This may be extra code. Security needs to
> be worked out.
> 3) Details of the encodings of data through the other communication
> mechanism need to be worked out.
> 4) Details of the authorization for access to the returned data
> need to be worked out.
> 5) Details of management of the other communication mechanism needs
> to be worked out, such as is the connection long lived, or established
> and terminated for each retrieval operation.
> That's about it.
> Hope this helps...
> /david t. perkins