DMH Software

The SNMP Agent Model and Architecture

Table of Content

• SNMP Architecture
• Main Components
• Model of Operation
• Integrating the SNMP Agent
• Processing a PDU
• System Services
• MIB Development.

The SNMP Protocol

The Simple Network Management Protocol (SNMP) is today a de-facto industry standard for monitoring and management of devices on data communication networks, telecommunication systems and other globally reachable devices. Practically every organization dealing with computers and related devices expects to be able to centrally monitor, diagnose and configure each such device across local and wide area networks. SNMP is the protocol that enables this interaction.

In order for a device to respond to SNMP requests it must be equipped with the software that enables it to properly interpret an SNMP request, perform the actions required by that request and produce an SNMP reply. The SNMP Agent software is typically a subsystem software module residing in a network-entity.

The following figure shows a typical system composed of a native application and its managed objects. We can see how SNMP interacts with those objects, making them accessible to a central SNMP manager through the network.

The collection of related objects implemented by a system is called a MIB: Management Information Base. A MIB is defined as a specification in a formal language called ASN.1. MIB-II is the most basic and most popular MIB; all SNMP agents implement parts of MIB II. Examples of other MIB's are:

• Ethernet MIB, which focuses on Ethernet interfaces
• Bridge MIB, which defines objects for the management of 802.1D bridges
• RMON MIB, which allows sophisticated line monitoring activities to be performed remotely and reported to a central application via SNMP.

Back to Table of Content

SNMP Agent Architecture

The SNMP portable agent provides the basic software components implementing the SNMP protocol and MIB II. The system also provides tools for easy development of additional MIB's, namely the SNMP MIB compiler, which produces 'C' files from an ASN.1 definition, and the SNMP kernel services that interact with MIB modules.

Main Components

1. The SNMP kernel. This is the heart of SNMP. It processes incoming requests, identifies the various parts of a request, check for proper command syntax, and eventually interacts with the MIB modules to retrieve or modify the value of a requested object. The kernel interacts with the underlying datagram services subsystem (usually UDP/IP) for reception and transmission of SNMP datagrams.



2. MIB-II: In general, all MIB's interacting with the SNMP kernel are 'C' modules produced by a MIB compiler (part of the SNMP developing environment). The MIB compiler accepts as input an ASN.1 MIB definition, and produces as output a 'C' file with code implementing the given MIB. In the case of the MIB-II module, this is a set of files produced from the MIB-II ASN.1 definition, plus additional code added by DMH Software to facilitate the integration of MIB-II with the host-system.



3. Additional MIB's: Additional MIB's can easily be added to the system as explained in the section "Adding Additional MIB's". The process involves compiling the ASN.1 files defining the MIB's, inserting user code in the appropriate sections within the produced 'C' files, and providing the API services as needed. Note that, as SNMP supports dynamic registration of MIB objects, there is no change to be done to the SNMP kernel in order to support additional MIB's (each MIB implementation file includes the code for dynamic registration of the objects implemented in that file).



4. Datagram Services: An SNMP agent requires the services of a datagram module for reception and transmission of SNMP datagrams. Usually this module is UDP/IP (the User Datagram Protocol, see [13]), using UDP port 161; there exist implementations over other transport protocols, although these are less popular due to interoperability restrictions. SNMP is designed for integration with any datagram services module, as explained in the section "Integrating with the Underlying Datagram Services".



5. MIB API (Application Interface): This is system specific code required to satisfy the requirements of MIB-II and other MIB's as those are added to the system. For example, in order to retrieve the object sysUpTime, SNMP looks for an API function called GetTimeTicks in the MIB API library provided by the host-system. In the section on "Implementing MIB-II objects" we detail how to implement the API module to fulfill the requirements of MIB-II objects. API modules for additional MIB's are specific to the MIB application; however, the section on "Adding Additional MIB's" provides examples of such API modules.



6. Basic Services: These are services needed by the SNMP kernel and the MIB modules regarding memory allocation, string formatting, memory copying, and console I/O for error reporting. Most systems already include services such as malloc and sprintf.

Back to Table of Content

Model of Operation

Following is a procedural description of the handling of an SNMP command from the moment it is received by the Agent, to the production and sending of a response to the requester.

1. SNMP request is sent by a Manager. An SNMP request PDU is made by a manager and sent to the IP address of the Agent network entity. By definition, the destination port of the UDP datagram encapsulating the SNMP PDU, is SNMP_AGENT_PORT (161).



2. Agent receives UDP datagram. The Agent receives the UDP datagram and checks the UDP destination port. If the destination port is SNMP_AGENT_PORT (161) the entry point function that processes the inbound SNMP request, "SnRcvDatagram()" is called. This function will process the SNMP request, build an SNMP reply and send it back to the requester. (Other UDP ports represent other applications such as TFTP, BOOTP, etc.).



3. ASN.1/BER Parsing. The ASN.1/BER parser parsers the encoded request and creates an SNMP PDU with a Variables link list in actual representation.



4. Handle Authentication and Privacy. Depending on whether an SNMPv1, SNMPv2c or SNMPv3 Messgae is being processed, several degrees of security are available, including privacy protocols (encription) and authentication protocols. In SNMPv1 and SNMPv2c there is a trivial authentication mechanism called community names.



5. Search the MIB tree. SNMP maintains a MIB data structure with information on every SNMP object maintained by the system (e.g., registered to SNMP). Such information includes object name, type, associated access function, optional instance function, and the like. The SNMP kernel now searches the MIB tree to find an entry for the requested object (if this is a get-next request, the 'next' object is retrieved, or, for tables, a similar object with a 'next' instance value is retrieved). Note that only a subset of the whole MIB is “visible” to a given client application, based on the so called “MIB view”.



6. Evaluate the Instance. This is performed for tabular objects only: tabular objects are conceptual collections of rows in a table, which are addressed by a part of the SNMP variable name called instance. For each such object, SNMP calls an "instance evaluator" routine associated with that object, which searches application tables for a row matching a given input instance (or the next one in case of Get-Next commands). The information is then maintained in a static global variable to be then used by the object access routines (see below). Note that if several objects are requested within the same row of a given table, the instance function for that row is called only once, saving the system unnecessary work.



7. Object Access. Depending on the command a read or write operation is performed:
• For Get and Get-Next commands (and for Get-Bulk in SNMPv2c), the access routine returns the data representing the object value at this time, possibly using instance information evaluated by the instance function. The retrieved data is encoded into a response PDU.
• For Set commands, the access routine is called twice, first to test if a given input value is acceptable, and then to commit (e.g., to actually set an internal object to a given input value). In both cases instance information evaluated by the instance function might be used.



8. ASN.1/BER Build. The actual representation of the SNMP PDU consisting of the header and the Variable linked list is now encoded back to ASN.1/BER machine independent representation.
• In case of a Get PDU, the response contains the retrieved data with the original object names.
• In case of a Get-Next PDU, the response contains the retrieved data with the updated object names reflecting the 'next' object relative to the original input name.
• In case of a Set PDU, the response is contains the original names and data.
• In case of a processing error (if a response is at all generated), the response contains the original names and data, with an error code indicating what the error was (e.g., no such object...).



9. Add Authentication and Privacy. In SNMPv1 and SNMPv2c add the trivial community name. In SNMPv3, provide optional encription for privacy, and evaluate an authentication digest to ensure the destination can validate the response.



10. Send the reply. Finally the encoded, possibly secure ASN.1/BER data is encapsulated in a UDP datagram. The destination port is set to the UDP source port of the request. The UDP datagram is sent to the IP address of the requester.

Back to Table of Content

Integrating the SNMP Agent

In order to utilize the SNMP portable agent, it is required to make the agent aware of the actual system in which it is working. For example, different systems have different ways of calculating the current time or sending a datagram to the network. While some environments have standardized on an operating system such as UNIX, many developers are confronted with the need to support SNMP on less standardized embedded systems.

The integration process is based on a set of system specific services to be provided by the hosting system. These services are often available already, perhaps under a different name or syntax. Examples of such services are provided below. To facilitate the writing of the integration services, the SNMP agent tool-kit includes 'stub' functions for every required system-specific service, with detailed comments explaining the expected integration code.

The process of integrating the SNMP agent to most hosting systems is expected to last 1-2 weeks. In particular, if the optional DMH Software Software UDP/IP module is licensed along with SNMP, you can expect to complete the whole integration in under a week.

At the end of the integration process, your system will have full SNMP capability and MIB-II support, meaning that users can use an SNMP manager to monitor basic parameters of your devices.

Processing a PDU

• SnAgentProcessPdu - The hosting system calls this routine to have SNMP process an inbound datagram addressed to the SNMP agent port (UDP port 161).

Back to Table of Content

System Services

The following is a partial list of the main system services required by the SNMP Agent. A full specification of each system service can be found in the SNMP programmer's Manual.

MIB-II related services

• SnGetSysOid - Returns the object ID. of the current system.
• SnGetSysDescr- Returns a string describing the current system.
• SnGetSysContact, SnSetSysContact - Reads/Sets a string representing a user defined system contact.
• SnGetSysName, SnSetSysName - Reads/Sets a string representing a user defined system name.
• SnGetSysLocation, SnSetSysLocation - Reads/Sets a string representing a user defined system location.
• SnGetSysServices - Returns a value indicating the type of services this system implements, e.g., repeater, router, etc.
• SnGetIfNum - Returns the number of communication interfaces in the system.
• SnGetIfStats - Retrieves a structure consisting of current interface statistics for a given interface, such as number of packets received, octets transmitted, errors, and the like.
• SnSetIfAdminStatus - Forces an interface to go down or up.

Miscellaneous Services

• GetTimeTicks - Returns the time, in 1/100 seconds, since the system started.
• consoleMsg - Reports a message to a local console, for error reporting, tracing, and so on.

Back to Table of Content

MIB Development.

As implied in the architecture description, the MIB's are not strictly part of the SNMP kernel. Rather, code implementing diverse MIB's can be modularity added at any time.

Perhaps the main metric in the evaluation of an SNMP tool kit ought to be the ease of MIB addition - the reason is simple: while porting the basic kernel is done just once in the life of a project, adding MIB's is a constantly evolving process, as systems evolve over time with added functionality, which invariantly implies added MIB extensions.

The process of MIB addition is described below.

1. Identify a feature or related features of the host-system that should be monitored by or settable through SNMP. If such feature(s) are not implemented, implement them or specify their implementation.
2. Define and implement a set of Application Interface Routines (API) that the MIB module will use to access the new set of features to be managed.
3. Write a Management Information Base (MIB) that specifies the objects, tables, indices, operations, etc., regarding the new features.
4. Compile the MIB file using the SNMP MIB compiler. The result is a 'C' file as described below.
5. The next step involves adding application specific code to the compiler produced 'C' file. To facilitate this, the compiler inserts comments as shown where user code is required:

/* start user code */

/* end user code */