ESF SNMP is a class implementation of the Simple Network Management Protocol (SNMP) protocols, and a Management Information Base (MIB) framework for the construction of vendor specific MIB databases. It is a C++ object-oriented framework that supports rapid application development and easy incorporation into a wide variety of computing environments. The modules are high-level building blocks that can be flexibly combined to construct a range of applications. They form part of a technology organization strategy to minimize the effort for application development and to maximize the reuse and cross project leveraging of an engineering investment.
The framework supports cross-platform and platform specific reuse. It can be used in real-time environments such as that provided by the ESF RTOS real-time kernel, or using other real-time environments, such as Windows CE, and also in general environments, such Windows NT and Linux. Although NT’s SNMP API supports SNMP packet transfer protocol, it has no special framework to build MIB’s. The NT implementation extends the Microsoft SNMP framework to include a MIB framework.

Management Information Base (MIB)
The Mib class provides general C++ class support for the “tree structured” database and the MIB access protocol specified by SNMP protocol. To minimize the amount of space required for object identifiers and to speed object lookup, the class supports the organization of the MIB database into “sub-trees”. All simple SNMP types are supported as well as non-volatile instances of them. The class performs Get, Set and GetNext operations. For quick, efficient data object lookup, an AVL tree C++ class is the core data object used to implement the MIB trees.
Class features include:
1) Easy extensibility.
2) No assumptions are made about the implementation of objects.
3) Support for “virtual objects”.
4) High performance – uses a balanced binary tree class, AvlTree to search for object names.
5) Memory efficiency - each object contains only the data it absolutely needs.
6) Support for abstract memory object to be used for memory allocation.
7) Support for aggregate objects.
8) Uniform interface - methods and error codes match those used by the Snmp class.
9) Easy to bind objects to variables in the system.

SNMP Protocols
These are OS and hardware independent classes that encapsulate the following aspects of SNMP:
• BER - the basic encoding rules.
• ASN1 - Abstract Syntax Notation encoding/decoding.
• Communities - SNMP community management
• SNMP Message - manages SNMP messaging protocol.
SNMP protocols are application protocols that interface to OS dependent network protocols via a simple abstract “Sockets” class interface that can be easily implemented using a standard sockets interface.

ASN1
An Asn1 class provides an implementation of the Abstract Syntax Notation One (ASN1) encoding/decoding using the basic encoding rules. Its features include:
1) Support for encoding and decoding of primitive objects of any type.
2) Support for encoding and decoding of constructed objects of any type.
3) Avoidance of buffer shifting and copying.
4) Support for an abstract buffer type.
5) Easy to use.
6) Practical limits on the tag field.
7) Practical limits on the size of integer.
8) Practical limits on the size of a sub-id size.
9) Practical limits on nesting levels of constructed objects.
10) No limits on the length of an octet string.
11) No limits on the length of an object identifier.
12) No limits on the length of the encoded object.
13) Support for both forms of definite length.
14) Practical limits on definite length size.
15) Support for indefinite length when decoding.
12) No generation of indefinite length when encoding.

Structure of Management Information (SMI)Using the Asn1 class, the Smi class implements the standard object types as specified in RFC 1155.

SNMP Messaging
The Snmp class provides an implementation of SNMP messaging level protocols. These are application protocols that interface to OS dependent network protocols via a simple abstract “Sockets” class interface that can be easily wrapped around a standard sockets interface.
Its features include:
1) Extensibility.
2) Supports different authentication schemes.
3) Performance - encoding/decoding in a single pass.
4) Efficient memory usage
5) No assumptions are mad about the transport layer interface.

SNMP Agent
The SnmpAgent class implements an SNMP version 2 agent using the SNMP protocols and MIB frameworks It includes a thread that uses the ESF RTOS kernel interface which, in addition to direct implementations, has been implemented using the thread services of a variety of OS’s. For Windows NT, the agent is an extension of the existing Windows NT agent that ties the existing NT agent to the MIB framework.

Example SNMP Agent and MIB Development
Following sections provides a rough outline for using the framework to implement a flexible, portable, object-oriented SNMP agent and vendor unique MIB. We use a detailed, but non-trivial, made-up example – the Acme, Inc. “Widget” product MIB. Each Widget is a module that monitors voltage and temperature and that generates SNMP traps when its monitored parameters go out of range. The MIB supports configuration and control for one or more Widget modules in the system. Each Widget is assumed to have a TCP/IP network connection. A computer of some sort runs the SNMP Agent with the vendor unique Widget MIB. The MIB interacts with each Widget using a “Widget Application Programming Interface”.

Step 1: Formally Define the MIB
Use Abstract Syntax Notation 1 (ASN1) to formally define your vendor unique management information. This unambiguously specifies to an SNMP manager the structures and types of information in your MIB and unambiguously specifies what you intend to implement. A good MIB has logical grouping and structuring of its data objects. It is also easy to expand.
The formal Acme Widget MIB example is specified in Appendix A of the manual. Because complex, nested data structures are not directly supported in SNMP, table entries (parameter groups) in this MIB are linked via table indexes. This simulates the association of data in a more complex data structure.

Step 2: Define an Instrumentation API
Define an application programming interface (API) to access or change management parameters. The implementation of the vendor unique MIB in step 3 will be easier if there is direct correspondence of this API to the format and organization of the parameters in the formal MIB. In SNMP lingo, the API is called the interface to the MIB “instrumentation”. The API is a well-defined interface that insulates the vendor specific MIB (developed in the next step) from low level driver details and OS specific service calls, making the vendor MIB platform independent. It also handles low-level errors, manages mutual exclusion, etc. It can also be used by management schemes other than SNMP to access the module management/monitoring data.
Note that the MIB and agent code can be tested independently with a simulation for the Instrumentation API.

Step 3: Implement a Vendor Unique MIB
Derive a vendor unique MIB class from the MIB framework’s Mib class and define your specific MIB objects to match the formal MIB. The result is a MIB that is flexible, search efficient (due to its balanced-binary tree foundations), and storage space efficient. Some features to note are:
- The full object-identifier is not stored for each MIB object. Each object is referenced to the root of its MIB sub-tree. In the MIB framework, an object’s full object-identifier is obtained by appending it’s sub-tree root referenced identifier to the identifier of the sub-tree itself. Total object identifier storage space is thus significantly reduced.
- The MIB can dynamically construct itself based on configuration variables from the Widget. For example, the number of rows in the MIB volt table depends on the number of monitored voltages obtained using e.g. a WidgetGetInfo() function.
- A framework is provided for SNMP trap monitoring.

Step 4: Implement the Instrumentation API of Step 2
Write the code that implements the instrumentation API of step 2. This may require platform device drivers for specific environmental sensing devices and interfacing to the appropriate OS services. Because ESF SNMP provides all other modules , you now have all elements to implement and test the complete agent.