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

RE: OID compression tests.




> I think your idea could work well for local storage on the 
> manager side,
> and that would be an implementation issue, and wouldn't 
> require any changes
> to SNMP.

I believe  this particular solution is not very good for local storage as
well. My
feeling is that we should be able to compress OID's by 90%.

> One problem I see with this is that the manager and agent 
> would have to
> agree on the mapping in advance. This means there would have 
> to be either
> 	a) a machine parseable mib-oid mapping document 
> provided by the vendor
> 	b) a mib table on the agent providing the mapping
> 	c) a centralized authority (ala IANA) for all mibs.
> 
> (c) is unlikely, (b) would place to much burden on small 
> agents, both (a)
> and (b) would require the manager to maintain a separate 
> mapping for each
> agent or mib.
> 

Actually, it is possible to agree on a computable hash function F:OID ->
32bit 
(Here's a not-to-efficient example:  consider an OID to be a number in the
base 11 number system where "." is the eleventh digit, and take the modulo
2^32 of that number). Duplicates should be extremely rare per MIB.
Small agents can use small caches and calculate F when the cache misses
(which takes O(N) where N is the number of entries in the MIB. Very bad but
still, its a small agent...). Larger agents can keep a hash table and answer
requests in O(1) steps.

There is a catch though. Since getNext operations can accept *any* OID it is
impossible to use F(OID)
with getNext as it is defined now. One solution may be to require that, for
getNext operations, F(OID) must represent an OID which is
a prefix of an object instance.

Gideon.