Previous | Table of Contents | Next |
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:
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.
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 entitys 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
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 entitys 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 |