In the SNMP model there is a software component residing on the network device that collects the related information about that device into a well-defined structure. This software component is referred to as the agent. The agent is responsible for responding to queries and carrying out requests to the network device. The counterpart of the agent is the software component that issues requests. Typically, the results of the requests are passed on to some sort of user interface that allows administrators to view data on the queried device. This component is referred to as the manager or management console. Keep in mind that typically the agent software and the manager software are running on different networking components and are communicating via the network and a common protocol.
The data instrument by the SNMP agent is organized into collective units that are termed management information bases or MIBs for short. MIBs are described via a precise definition language called Abstract Syntax Notation. Abstract Syntax Notation is a complete topic of its own and could not be adequately described in the context of this paper, but think of Abstract Syntax Notation as a compiled language like COBOL, FORTRAN or C. It makes possible the definition of data types and structures and arrays of structures of information on the managed device. Fundamentally, MIBs define the following for every entity in the agent:
The manager component of SNMP uses MIBs to relate the structure of the data available at the agent to the SNMP user. Simply put, a SNMP manager console can describe the data available on the SNMP agent because it uses the MIB that defines that data to describe it to the user. It is because of this relationship between agents, MIBs and managers that agents created today can work with management consoles that were written years ago.
Throughout this paper we will be discussing object names, often referring to as OIDs, or a MIB view as part of the OID namespace. An OID is a unique identifier assigned to a specific object. The identifier consists of a sequence of numbers that identify the source of the object as well as the object itself. This sequence of numbers is variable in length, so in addition to the sequence of numbers, there is a length field. OIDs are organized in a tree-like structure and the sequence of numbers identifies the various branches of the subtree that a given object comes from. The root of the tree is the ISO (International Standards Organization) trunk. Its value is 1. Each branch above the root (or below, depending on your perspective) further identifies the source of the given object. All SNMP objects are members of the subtree identified by iso.org.dod.internet or 1.3.6.l. Each additional component in this dotted notation further defines the exact location of an object. The numbers for each subtree are assigned by the IETF to ensure that all branches are unique.
The example in Figure 1.1 on the following page illustrates the OID values for the Toaster MIB. The Toaster MIB is an example MIB generated for the purposes of illustration; we will refer to it often throughout the course of this paper.
To reference the ModelNumber object instance in a Toaster MIB on a network device you would specify 1.3.6.1.4.1.12.2.2.0 as the OID. The zero is appended to indicate that this a specific instance of this object.
Another data structure we will reference often in this paper is a VarBind. A VarBind consists of an OID and a value structure. The value structure of a VarBind is a two-part structure that consists of a value type and a value. The value type field identifies what type of variable the value field represents. Some examples of value types are Integer, Octet, Octet String, and Gauge. In the structure definition below the value component is referred to as an AsnObjectSyntax, which is a union of all the possible SNMP data types and a value type.
typedef struct vb {
AsnObjectName name;
AsnObjectSyntax value;
} RFC1157VarBind;