[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIB objects vs OPs
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.
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
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