Re: [lisp-snmp] Changing the representation of OIDs

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi, John

Thank you for your suggestion and I took some time to finish it. Now ...

May I introduce a new feature on ASN.1 trunk: the SIMPLE-OID class.

A SIMPLE-OID is a special ASN.1 object ID which have less slots than a  
normal OBJECT-ID:

(defclass base-oid (asn.1-type)
   ((parent      :type object-id
                 :reader oid-parent
                 :initarg :parent)))

(defclass simple-oid (base-oid)
   ((values      :type list
                 :reader oid-number-list
                 :initarg :values)
    (length      :type fixnum
                 :reader oid-length))
   (:documentation "A simple OID implementation"))

I still use a LIST to hold the oid number list because this can best  
fit most of exist code.

A SIMPLE-OID instance can be BER encoded the same with normal OBJECT- 
ID instances. And below is some new feature when OID function is called:

ASN.1 21 > (oid "sysDescr")
#<OBJECT-ID SNMPv2-MIB::sysDescr (1) [0]>

ASN.1 22 > (oid "sysDescr.0")
#<SIMPLE-OID SNMPv2-MIB::sysDescr.0>

ASN.1 23 > (oid-number-list (oid "sysDescr"))
(1 3 6 1 2 1 1 1)

ASN.1 24 > (oid '(1 3 6 1 2 1 1 1))
#<OBJECT-ID SNMPv2-MIB::sysDescr (1) [0]>

ASN.1 25 > (oid '(1 3 6 1 2 1 1 1 0))
#<SIMPLE-OID SNMPv2-MIB::sysDescr.0>

You can see, for (OID "sysDescr.0") and (OID '(1 3 6 1 2 1 1 1 0)) ,  
it returns a SIMPLE-OID instance instead of OBJECT-ID now. The rule  
is: if the object id ends with unnamed number lists, a SIMPLE-OID will  
return instead. I think lots of work can be saved here.

Now a full SNMP-WALK on (OID "system") may look like this:

CL-USER 19 > (snmp:snmp-walk "localhost" "system")
((#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysDescr.0>
   "Darwin binghe-pro.local 9.6.2 Darwin Kernel Version 9.6.2: Tue Jan  
13 20:42:22 PST 2009; root:xnu-1228.9.80~1/RELEASE_I386 i386")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysObjectID.0> #<ASN.1:OBJECT-ID NET- 
SNMP-TC::unknown (255) [0]>)
  (#<ASN.1:OBJECT-ID DISMAN-EVENT-MIB::sysUpTimeInstance (0) [0]>  
#<ASN.1:TIMETICKS (43192102) 119:58:41.02>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysContact.0> "Administrator <pos...@ex... 
 >")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysName.0> "binghe-pro.local")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysLocation.0> "Right here, right  
now.")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysServices.0> 76)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORLastChange.0> #<ASN.1:TIMETICKS  
(66) 0:00:00.66>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORID.1> #<ASN.1:OBJECT-ID SNMP- 
FRAMEWORK-MIB::snmpFrameworkMIBCompliance (1) [0]>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORID.2> #<ASN.1:OBJECT-ID SNMP- 
MPD-MIB::snmpMPDCompliance (1) [0]>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORID.3> #<ASN.1:OBJECT-ID SNMP- 
USER-BASED-SM-MIB::usmMIBCompliance (1) [0]>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORID.4> #<ASN.1:OBJECT-ID SNMPv2- 
MIB::snmpMIB (1) [2]>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORID.5> #<ASN.1:OBJECT-ID TCP- 
MIB::tcpMIB (49) [1]>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORID.6> #<ASN.1:OBJECT-ID IP- 
MIB::ip (4) [38]>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORID.7> #<ASN.1:OBJECT-ID UDP- 
MIB::udpMIB (50) [1]>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORID.8> #<ASN.1:OBJECT-ID SNMP- 
VIEW-BASED-ACM-MIB::vacmBasicGroup (1) [0]>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORDescr.1> "The SNMP Management  
Architecture MIB.")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORDescr.2> "The MIB for Message  
Processing and Dispatching.")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORDescr.3> "The management  
information definitions for the SNMP User-based Security Model.")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORDescr.4> "The MIB module for  
SNMPv2 entities")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORDescr.5> "The MIB module for  
managing TCP implementations")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORDescr.6> "The MIB module for  
managing IP and ICMP implementations")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORDescr.7> "The MIB module for  
managing UDP implementations")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORDescr.8> "View-based Access  
Control Model for SNMP.")
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORUpTime.1> #<ASN.1:TIMETICKS  
(65) 0:00:00.65>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORUpTime.2> #<ASN.1:TIMETICKS  
(65) 0:00:00.65>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORUpTime.3> #<ASN.1:TIMETICKS  
(65) 0:00:00.65>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORUpTime.4> #<ASN.1:TIMETICKS  
(66) 0:00:00.66>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORUpTime.5> #<ASN.1:TIMETICKS  
(66) 0:00:00.66>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORUpTime.6> #<ASN.1:TIMETICKS  
(66) 0:00:00.66>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORUpTime.7> #<ASN.1:TIMETICKS  
(66) 0:00:00.66>)
  (#<ASN.1:SIMPLE-OID SNMPv2-MIB::sysORUpTime.8> #<ASN.1:TIMETICKS  
(66) 0:00:00.66>))

You can see, as a "key", almost all OIDs are returned as SIMPLE-OID,  
but those OIDs as a "value", we still use original OBJECT-ID.

All my work for this feature has been commited on cl-net-snmp SVN (ASN. 
1 trunk, r762), you can find the diff here:

http://cl-net-snmp.svn.sourceforge.net/viewvc/cl-net-snmp?view=rev&revision=762

Due to its big change, this work won't appear in ASN.1 4.x

Hope you like it, and more comments are welcome.

Regards,

Chun Tian (binghe)

在 2009-5-1，14:08， John Fremlin 写道：

> Dear Chin Tian,
>
> Thanks for your rapid response.
>
> We seem to have reduced the memory usage significantly. Hopefully we
> will be demonstrably more efficient now too!
>
> However, according to SBCL, still the largest amount of consing is  
> going
> on in the object-id code.
>
> The problem is that there are many OIDs like this
>
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.7.1.1.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.7.1.2.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.7.1.3.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.7.1.4.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.7.1.5.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.8.1.1.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.8.1.2.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.8.1.3.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.8.1.4.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.8.1.5.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.8.1.6.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.8.1.7.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.8.1.8.127 = 255
> localhost -- NET-SNMP-AGENT-MIB::nsModuleTimeout. 
> 0.11.1.3.6.1.2.1.25.3.8.1.9.127 = 255
>
> Each step along the OID after the last known one
> (NET-SNMP-AGENT-MIB::nsModuleTimeout) causes a new instance of class
> object-id to be created.
>
> This is quite unnecessary.
>
> As I mentioned before, I rather like the idea of being able to pass
> around simple-vectors of integers as OIDs. Is there a limit to the  
> size
> of the integers in an OID's number list? (I.e. could we use simple
> arrays of fixnum.)
>
> This would mean that an OID could be of two kinds, either an actual
> instance of object-id or a vector.
>
> Alternatively we could make a defclass like this (rough sketch)
>
> (defclass object-id-unknown ()
>          ((parent) ; pointer to parent full oid
>           (values :type 'simple-vector)))
>
> At the same time I'd like to turn the number-list into a vector as a
> list is rather wasteful.
>
> What do you think?
>
> Would you accept a patch for either of the two approaches?
>
> [...]
>