Skip to main content

2. Overview

SNMP entities supporting command generator or notification receiver applications (traditionally called "managers") communicate with SNMP entities supporting command responder or notification originator applications (traditionally called "agents"). The purpose of this protocol is to convey management information and operations.

2.1. Management Information​

The term "variable" refers to an instance of a non-aggregate object type defined according to the conventions set forth in the SMI [RFC2578] or the textual conventions based on the SMI [RFC2579]. The term "variable binding" normally refers to the pairing of the name of a variable and its associated value. However, if certain kinds of exceptional conditions occur during processing of a retrieval request, a variable binding will pair a name and an indication of that exception.

A variable-binding list is a simple list of variable bindings.

The name of a variable is an OBJECT IDENTIFIER which is the concatenation of the OBJECT IDENTIFIER of the corresponding object type together with an OBJECT IDENTIFIER fragment identifying the instance. The OBJECT IDENTIFIER of the corresponding object type is called the OBJECT IDENTIFIER prefix of the variable.

2.2. Retransmission of Requests​

For all types of request in this protocol, the receiver is required under normal circumstances to generate and transmit a response to the originator of the request. Whether the request should be retransmitted if a corresponding response is not received within an appropriate time interval is at the discretion of the application originating the request. This will normally depend on the urgency of the request. Such an application needs, however, to act responsibly in respect to the frequency and duration of re-transmissions. See BCP 41 [RFC2914] for a discussion of relevant congestion control principles.

2.3. Message Sizes​

The maximum size of an SNMP message is limited to the minimum of:

(1) the maximum message size which the destination SNMP entity can accept; and,

(2) the maximum message size which the source SNMP entity can generate.

The former may be known on a per-recipient basis; and in the absence of such knowledge, is indicated by the transport domain to be used when sending the message. The latter is imposed by implementation-specific local constraints.

Each transport mapping for SNMP indicates the minimum message size which an SNMP implementation must be capable of producing or consuming. Although implementations are encouraged to support larger values whenever possible, a conforming implementation must never generate messages larger than allowed by the receiving SNMP entity.

One of the aims of the GetBulkRequest-PDU, specified in this document, is to minimize the number of protocol exchanges required to retrieve a large amount of management information. Thus, this PDU type allows an SNMP entity supporting command generator applications to request that the response be as large as possible, within the constraints on message size.

These constraints include the limits on the sizes of messages which the SNMP entity supporting command generator applications can generate or receive, and the limits on the sizes of messages which the SNMP entity supporting command responder applications can generate or receive. The size of any response to a request is limited by the minimum of these two constraints.

2.4. Transport Mappings​

It is a purpose of SNMP to be, as much as possible, independent of the architecture and mechanisms of particular transport services. The abstract service interfaces provided by the SNMP architecture [RFC3411] support the mapping of the protocol onto different transport services. These mappings are described in [RFC3417].

2.5. SMIv2 Data Type Mappings​

The syntax of the various PDUs described in this document is specified using the ASN.1 Basic Encoding Rules (BER). However, the SNMP protocol makes extensive use of the SMIv2 [RFC2578], which itself is defined using ASN.1 [ASN1]. The SMIv2 defines a subset of ASN.1 types to be used for defining information modules. For some of these SMIv2-defined types, the standard ASN.1 encoding rules do not provide an unambiguous representation. In such cases, the SMIv2 itself specifies the representation to be used. In particular, this applies to the following types:

  • Counter32
  • Counter64
  • Gauge32
  • TimeTicks
  • Opaque
  • IpAddress

For details on how SMIv2 types are encoded, see [RFC2578].

Last updated on