Previous Table of Contents Next


5.4 SNMPv2 Conformance Statements

The Conformance Statements are used to define acceptable lower bounds of implementation, along with the actual level of implementation for SNMPv2 that is achieved by the device. The Conformance Statements document, RFC 1904 [5-5], defines the notations, along with ASN.1 macros, that are used for these purposes. Two kinds of notations are used:

  Compliance statements, which describe requirements for agents with respect to object definitions. The MODULE-COMPLIANCE macro is used to convey a minimum set of requirements with respect to implementation of one or more MIB modules. In other words, the MODULE-COMPLIANCE macro conveys a minimum conformance specification, including objects and groups required, which may come from different MIB modules.
  Capability statements, which describe the capabilities of agents with respect to object definitions. The AGENT-CAPABILITIES macro describes the capabilities of an SNMPv2 agent. It defines the MIB modules, objects, and values implemented within the agent. A description of the precise level of support that an agent claims is bound to the instance of the sysORID object. (See the SNMPv2 MIB, RFC 1907, for a complete definition of the sysORID object and other objects that convey object resource information.)

The Conformance Statements also define two other ASN.1 macros. The OBJECT-GROUP macro defines collections of related, managed objects. Similarly, collections of notifications may be grouped using the NOTIFICATION-GROUP macro.

5.5 SNMPv2 Protocol Operations

When it comes to processing protocol messages, an SNMPv2 entity may act as an agent, a manager, or both. The entity acts as an agent when it responds to protocol messages (other than the Inform notification, which is reserved for managers) or when it sends Trap notifications. The entity acts as a manager when it initiates protocol messages or responds to Trap or Inform notifications. The entity may also act as a proxy agent.

SNMPv2 provides three types of access to network management information: these types are determined by the network management entity’s role and relate to the Manager-to-Manager capabilities. The first type of interaction, called request-response, is where an SNMPv2 manager sends a request to an SNMPv2 agent, which responds. The second type of interaction is a request-response where both entities are SNMPv2 managers. The third type is an unconfirmed interaction, where an SNMPv2 agent sends an unsolicited message, or trap, to the manager and no response is returned.

SNMPv2 has significantly enhanced the PDUs that convey this management information (see Figure 5-2). SNMPv2 offers new PDUs and adds error codes and exception responses. The latter allows a management application to easily determine why a management operation failed.


Figure 5-2.  SNMPv2 PDU structure

5.5.1 SNMPv2 PDUs

SNMPv2 defines eight PDU types, of which three are new: the GetBulkRequest, the InformRequest, and the Report. In addition, the SNMPv2-Trap PDU format has been revised from the SNMPv1 Trap to conform to the format and structure of the other PDUs (recall that in SNMPv1, the Trap PDU had a unique format).

The following is a list of all the SNMPv2 PDUs, along with their assigned tag numbers:

PDU/Tag Number Description

GetRequest [0] Retrieves values of objects listed within the variable bindings field.
GetNextRequest [1] Retrieves values of objects that are the lexicographical successors of the variables, up to the end of the MIB view of this request.
Response [2] Generated in response to a GetRequest, GetNextRequest, GetBulkRequest, SetRequest, or InformRequest PDU.
SetRequest [3] Establishes the value of a variable.
GetBulkRequest [5] Retrieves a large amount of data, such as the contents of a large table.
InformRequest [6] Allows one manager to communicate information in its MIB view to another manager.
SNMPv2-Trap [7] Used by an SNMPv2 agent to provide information regarding an exceptional condition. The Trap PDU, defined for SNMPv1 with tag [4], is now considered obsolete. The Coexistence document, RFC 1908, discusses conversion from the Trap PDU to the SNMPv2-Trap PDU.
Report [8] Included in SNMPv2, but its usage is not defined in RFC 1905. It is expected that any Administrative Framework that makes use of this PDU would define its usage and semantics (see RFC 1905, page 6).

The PDUs that the SNMPv2 entity generates or receives depend on the entity’s role as an agent or manager:

SNMPv2 PDU Agent Generate Agent Receive Manager Generate Manager Receive

GetRequest x x
GetNextRequest x x
Response x x x
SetRequest x x
GetBulkRequest x x
InformRequest x x
SNMPv2-Trap x x


Previous Table of Contents Next