CDEV SNMP Interface - Request for Comment

Send comments to cdev@jlab.org

Objective

The goal of this project is to develop a CDEV wrapper around the Simple Network Management Protocol (SNMP) that will allow applications to easily obtain and modify information from SNMP devices.

SNMP

SNMP, the Simple Network Management Protocol, provides a method of remotely obtaining and setting control information on individual devices. The device that is being managed is called an SNMP Agent and must be running an SNMP daemon that maintains the database of control parameters. The applications that request information from the SNMP Agent are called SNMP Clients and must be running an SNMP client daemon that handles connections and message routing.

Supporting Documents

IEEE RFC-1098 A Simple Network Management Protocol

IEEE RFC-1155 Structure and Identification of Management Information for TCP/IP-based Internets

IEEE RFC-1156 Management Information Base for Network Management of TCP/IP-based Internets

HP SNMP++ C++ Based Application Programmers Interface for the Simple Network Management Protocol

Overview

SNMP provides the basic mechanisms for getting and setting information for supported devices. Unfortunately, the protocol is not as simple as its name would lead you to believe. The developer must follow a set of specific steps for encoding and decoding the data that will be sent/retrieved from a device. Even the interface names must be converted from a text string to a unique octet identifier that is understood by SNMP.

SNMP supports basic "get", "get next", and "set" functions that allow the caller to recursively obtain/modify pieces of information. The "trap" method, which sends a message to the caller when a value has been modified, is only supported by a small subset of the SNMP attributes supported by a device.

The capabilities provided by Hewlett-Packard's SNMP++ interface, a freeware distribution that has been ported to a number of platforms, simplify many of these problems, however, SNMP still provides no capability to actively monitor many of a device's attributes. In order to detect changes, an application must periodically "get" the value from the SNMP device. If many applications are interested in the same value, this can create an undesireable strain on the CPU being polled.

Proposal

We believe that by creating a CDEV server that will act as an intermediary between the SNMP devices and the applications many of these issues can be addressed. The server would receive monitor requests from multiple applications and then periodically poll the device for changes to that value. Applications would only be notified when a change had occured.

Applications would submit their requests exclusively in terms of attribute name, the server would maintain a conversion table and convert the attribute name to its corresponding octet string. The data values sent to or retrieved from the server would always be provided in the form of a character string, simplying the display of information and reducing the data identification and type conversion effort.

Implementation Details


    		• The service will use the standard device/message paradigm. The name of the physical SNMP device will be the cdev device name.


    		• The service will support the following messages either synchronously or asynchronously...

    get MIB

    		Downloads the Management Information Base table that was used to define a specific SNMP device.

    get hosts

    		Obtain a list of SNMP devices that are defined on an SNMP server.

    get entries

    		Obtain a list of all SNMP attributes that are defined for a specific SNMP device.

    get entry

    		Obtain all of the characteristics (octet identifier, data type, access mode, enumerated values) of a specific SNMP attribute that is defined for an SNMP device.

    get attr

    		Get a named attribute (attr) from the SNMP server. This is a one time request which will return the current value of the attribute.

    set attr

    		Set a named attribute (attr) using the SNMP server. This will submit a new value to the SNMP server for a specific device/ attribute pair. The server will then forward the message to the specific SNMP device. Because the "set" command requires the use of an authenticating "write community name", this value must be provided through the request's context data object. The write community string should be placed in the "community" tag of the context cdevData object.

    monitorOn attr

    		Installs a monitor on a named attribute (attr) through the SNMP server. The SNMP server will use a predefined poll rate to detect changes in the specified attribute and will inform the client whenever the value has changed. Because information such as packet and collision rates may change very quickly, the poll rate will be set to a reasonable level (1 minute) to reduce network traffic and CPU load.

    monitorOff attr

    		Removes a monitor from a named attribute (attr) that was previously installed using the monitorOn command.


    		• Because an SNMP device may have more than one interface of the same type (multiple network cards), the service will use the indexing operator [ ] to specify which attribute is being requested.

    For instance, if the device devhla4 has two network adapters, the developer obtain the address of the first adapter using the following request...

    devhla4 get ifAddress[0]

    The address of the second adapter can be obtained using this request...

    devhla4 get ifAddress[1]


    		• The Managament Information Base table that defines all of the attributes that are supported by a specific SNMP device will be submitted to or loaded by the SNMP server at start up. The SNMP server will use this table to authenticate each request. By validating request before they are sent to the device, the SNMP server can reduce time wasted in processing invalid requests and elliminate the timeouts that often occur because a request cannot be serviced.


    		• Because maintaining a CDEV DDL file with a list of rapidly changing SNMP devices and attributes may prove cumbersome, the SNMP server may be designed with an auto-directory service which allows the caller to populate the local DDL file with the data that is stored in the SNMP server. This approach may require some research to determine if it is feasible.