JacobsSNMP Siarhei Kuryla Networks and Distributed Systems seminar May 10, 2010
Simple Network Management Protocol protocol for exchange of management information; exposes management data in the form of variables on the managed systems; variables are are organized in hierarchies defined by management information bases (MIBs); SNMPv1, SNMPv2c (extended operation set), SNMPv3 (added security).
Simple Network Management Protocol - Operations Get - retrieves the value of a variable or list of variables; Set - sets the value of a variable or list of variables; GetNext - retrieves the value of the the lexicographically next variable in the MIB; GetBulk - multiple iterations of GetNext; Trap - asynchronous notification from agent to manager; Inform - acknowledged asynchronous notification;
Simple Network Management Protocol - 6LoWPAN network management functionality is critical for 6LoWPANs; the SNMP protocol is datagram-oriented; the implementation of SNMP can be very lightweight;
Related work - LoWPAN Network Management Protocol SNMP is supported on the IPv6 network size only; uses a gateway to translate the incoming SNMP request to a simplified internal format; the gateway is responsible for objects whose values are constant for the whole network;
Related work - 6LoWPAN-SNMP optimized SNMP header field size; compressed Object Identifiers; introduces a few new operations (periodic get request, broadcast get request); compatibility is achieved by a proxy located on the gateway.
Related work - Advantages and disadvantages efficiency - reduced overhead on the network; compatibility issue - the translator on the gateway is required; gateway overhead - gateway stores some information and accomplishes the conversion between protocols; duplicated implementation of the protocol - we have to reimplement similar protocol operations;
Proposed work SNMPv1 implementation of Contiki OS; evaluation of the implementation; support of a set of standard MIBs; support of SNMPv3 with one of the security models;
Targeted Hardware AVR Raven Board: 2 microcontrollers; 16K of RAM (Contiki OS + WebServer = 11 kb); 128K of ROM (Contiki OS + WebServer = 55 kb);
JacobsSNMP Implementation supports SNMPv1 (Trap is not included); provides an API to implement custom MIBs; SNMP messages up to 484-byte length; available at http://code.google.com/p/jacobs-snmp/
MIB API both scalar and tabular MIB objects are supported; number of rows in a tabular object can be changed at runtime; add scalar() & add table: oid (e.g., 1.3.6.1.2.1.1.0); value type; default value; flags (e.g., readonly); get value function (optional); set value function (optional); optional get next oid function (only for tables);
JacobsSNMP Memory footprint ROM usage: 9 kb RAM usage: incoming SNMP request processing; MIB objects; + stack size;
RAM for SNMP request processing response buffer (484 bytes); message t structure BER-decoded SNMP message: size(message t) = 17 + 13 variable binding number; an SNMP message in the worst case may contain 65 variable bindings => max(message t) = 17 + 13 65 = 892; BER encoded OIDs are not copied; string values are not copied; 484 + 892 = 1376 bytes are required for request processing in the worst case;
RAM for an MIB object MIB object: (20 + OID + S) bytes (S - length of string value, OID - length of BER encoded oid); use flash memory to store the OID object: (20 + S + OID) (4 + OID) = (16 + S) bytes; use an array instead of a list to store the MIB: (16 + S) 2 = 14 + S bytes; disable tabular objects in the MIB: (14 + S) 2 = 12 + S bytes;
MIBs to support SNMPv2-MIB - describes the behavior of an SNMP entity; IF-MIB - network interface information; ENTITY-SENSOR-MIB - temperature sensor; 6LoWPAN-MIB (draft) - 6LoWPAN management functions;
Implementation evaluation What can we evaluate? RAM and ROM usage estimation; Request-response latency? Stack and heap usage experimental analysis?
Further plans SNMPv3 implementation with USM security model;
Thank you! Questions?