Skip to main content

3. Elements Of Procedure

The following sections describe the procedures followed by each type of application when generating messages for transmission or when processing received messages. Applications communicate with the Dispatcher using the abstract service interfaces defined in [RFC3411].

3.1. Command Generator Applications​

A command generator initiates an SNMP request by calling the Dispatcher using the sendPdu abstract service interface, providing the transport domain and address, message processing model, security model, security name, security level, context engine ID and context name of the target, the PDU to send, and an indication of whether a response is expected. If the PDU is successfully sent, a sendPduHandle is returned which the command generator stores so it can correlate a response to the original request.

The Dispatcher is responsible for delivering a response to a particular request to the correct command generator application, using the processResponsePdu abstract service interface.

The procedure when a command generator receives a message is as follows:

  1. If the received values of messageProcessingModel, securityModel, securityName, contextEngineID, contextName, and pduVersion are not all equal to the values used in the original request, the response is discarded.

  2. The operation type, request-id, error-status, error-index, and variable-bindings are extracted from the PDU and saved. If the request-id is not equal to the value used in the original request, the response is discarded.

  3. At this point, it is up to the application to take an appropriate action. The specific action is implementation dependent. If the statusInformation indicates that the request failed, an appropriate action might be to attempt to transmit the request again, or to notify the person operating the application that a failure occurred.

3.2. Command Responder Applications​

Before a command responder application can process messages, it must first associate itself with an SNMP engine using the registerContextEngineID abstract service interface, and may disassociate using the unregisterContextEngineID abstract service interface. Note that if another command responder application is already registered with an SNMP engine, any further attempts to register with the same contextEngineID and pduType will be denied.

Once the command responder has registered with the SNMP engine, it waits to receive SNMP messages using the processPdu abstract service interface. The procedure when a message is received is as follows:

  1. The operation type is determined from the ASN.1 tag value associated with the PDU parameter.

  2. The request-id is extracted from the PDU and saved.

  3. Any PDU type specific parameters are extracted from the PDU and saved (for example, for an SNMPv2 GetBulk PDU, the non-repeaters and max-repetitions values are extracted).

  4. The variable-bindings are extracted from the PDU and saved.

  5. The management operation represented by the PDU type is performed with respect to the relevant MIB view within the context named by the contextName. The relevant MIB view is determined by the securityLevel, securityModel, contextName, securityName, and the class of the PDU type. To determine whether a particular object instance is within the relevant MIB view, the isAccessAllowed abstract service interface is called. If access is not allowed, the appropriate error handling is performed. If the context is unknown or unavailable, the snmpUnknownContexts or snmpUnavailableContexts counter is incremented as appropriate.

  6. The Dispatcher is called to generate a response or report message using the returnResponsePdu abstract service interface. Note that a command responder application should always call returnResponsePdu, even in the event of an error such as a resource allocation error.

3.3. Notification Originator Applications​

A notification originator application generates SNMP messages containing Notification-Class PDUs (for example, SNMPv2-Trap PDUs or Inform PDUs). Notification originator applications require a mechanism for identifying the management targets to which notifications should be sent. If an implementation makes the configuration of management targets SNMP manageable, it MUST use the SNMP-TARGET-MIB module described in this document.

When a notification originator wishes to generate a notification, it must first determine in which context the information to be conveyed exists, i.e., the contextEngineID and contextName. It must then determine the set of management targets to which the notification should be sent.

Once the application has determined this information, the following procedure is performed for each management target:

  1. Any appropriate filtering mechanisms are applied to determine whether the notification should be sent to the management target. If such filtering determines the notification should not be sent, processing continues with the next management target.

  2. The appropriate set of variable-bindings is retrieved from local MIB instrumentation within the relevant MIB view, using the isAccessAllowed abstract service interface (with a Notification-Class viewType). If access is not allowed, the notification is not sent.

  3. The NOTIFICATION-TYPE OBJECT IDENTIFIER of the notification (the value of the variable binding whose name is snmpTrapOID.0) is checked using isAccessAllowed. If access is not allowed, the notification is not sent.

  4. A PDU is constructed using a locally unique request-id, a PDU type as determined by the implementation, an error-status and error-index value of 0, and the retrieved variable-bindings.

  5. If the notification contains an Unconfirmed-Class PDU, the Dispatcher is called using the sendPdu abstract service interface, with expectResponse indicating that no response is expected.

  6. If the notification contains a Confirmed-Class PDU, the Dispatcher is called using sendPdu with expectResponse indicating that a response is expected. The application caches information about the management target, and if a response is received within an appropriate time interval, the notification is considered acknowledged. Otherwise, the notification is retransmitted up to the retry count. If the retry count is exceeded, the acknowledgement is considered to have failed.

Responses to Confirmed-Class PDU notifications are received via the processResponsePdu abstract service interface. To summarize, a notification originator determines the targets to which the notification should be sent, applies any required filtering, and determines which targets are authorized to receive the notification.

3.4. Notification Receiver Applications​

Notification receiver applications receive SNMP Notification messages from the Dispatcher. Before any messages can be received, the notification receiver must register with the Dispatcher using the registerContextEngineID abstract service interface, using an undefined 'wildcard' contextEngineID value and the pduType of the notifications it wishes to receive.

Once registered, messages are received using the processPdu abstract service interface. When an Unconfirmed-Class PDU is delivered, the application extracts the SNMP operation type, request-id, error-status, error-index, and variable-bindings, after which processing depends on the particular implementation.

When a Confirmed-Class PDU is received, the notification receiver application follows the following procedure:

  1. The PDU type, request-id, error-status, error-index, and variable-bindings are extracted from the PDU.

  2. A Response-Class PDU is constructed using the extracted request-id and variable-bindings, and with error-status and error-index both set to 0.

  3. The Dispatcher is called to generate a response message using the returnResponsePdu abstract service interface.

  4. After this, processing depends on the particular implementation.

3.5. Proxy Forwarder Applications​

A proxy forwarder application deals with forwarding SNMP messages. There are four basic types of messages which a proxy forwarder may need to forward, grouped according to the class of PDU type contained in a message:

  • Those containing Read-Class or Write-Class PDU types (for example, Get, GetNext, GetBulk, and Set).
  • Those containing Notification-Class PDU types (for example, SNMPv2-Trap and Inform).
  • Those containing a Response-Class PDU type, forwarded as a result of receiving a response to a previously forwarded message.
  • Those containing Internal-Class PDU types (for example, a Report PDU), forwarded as a result of receiving an Internal-Class PDU in response to a previously forwarded message.

When forwarding messages, a proxy forwarder must perform a translation of incoming management target information into outgoing management target information. If a proxy forwarder makes the contents of its translation table SNMP manageable, it MUST use the SNMP-PROXY-MIB module defined in this document.

3.5.1. Request Forwarding​

There are two phases for request forwarding: passing the incoming request through the proxy application, then passing the resulting response back.

3.5.1.1. Processing an Incoming Request​

A proxy forwarder that wishes to forward request messages must first register with the Dispatcher using the registerContextEngineID abstract service interface, for each contextEngineID and pduType for which it wishes to forward messages. It should never register a contextEngineID equal to the snmpEngineID of its own SNMP engine.

The following procedure is used:

  1. A message is received using the processPdu abstract service interface. The incoming management target information is translated into outgoing management target information. The translation should result in a single management target.

  2. If appropriate outgoing management target information cannot be found, the proxy forwarder increments the snmpProxyDrops counter [RFC1907], and calls the Dispatcher using returnResponsePdu with an error indication. Processing of the message stops at this point.

  3. A new PDU is constructed with a unique request-id. The remainder of the new PDU is identical to the received PDU, unless the incoming and outgoing SNMP versions support different PDU versions, in which case a translation may be needed (a method is described in [RFC2576]).

  4. The proxy forwarder calls the Dispatcher using the sendPdu abstract service interface to generate the forwarded message, with expectResponse indicating that a response is expected. If the sendPdu call is unsuccessful, the proxy forwarder performs the steps described in (2) above.

  5. The proxy forwarder caches information to match an incoming response to the forwarded request, including the sendPduHandle, request-id, contextEngineID, contextName, stateReference, and incoming/outgoing management target information.

  6. Processing of the request stops until a response is received or an appropriate time interval expires.

3.5.1.2. Processing an Incoming Response​

The following procedure is used when an incoming response is received:

  1. The response is received using the processResponsePdu interface. The proxy forwarder matches the received parameters against its cache of pending forwarded requests. If no entry can be found, processing of the response is halted.

  2. The cache information is extracted and removed from the cache.

  3. A new Response-Class PDU is constructed using the request-id from the original forwarded request, with all other values identical to the received Response-Class PDU (translated if the SNMP versions differ).

  4. The proxy forwarder calls the Dispatcher using the returnResponsePdu abstract service interface to deliver the response back to the original requester.

3.5.1.3. Processing an Incoming Internal-Class PDU​

The following procedure is used when an incoming Internal-Class PDU is received:

  1. The Internal-Class PDU is received using the processResponsePdu interface, and matched against the cache of pending forwarded requests. If no entry is found, processing is halted.

  2. The cache information is extracted and removed.

  3. If the original incoming management target indicates an SNMP version which does not support Report PDUs, processing is halted.

  4. The proxy forwarder calls the Dispatcher using returnResponsePdu, with the statusInformation containing values specific to the Internal-Class PDU type.

3.5.2. Notification Forwarding​

A proxy forwarder receives notifications using the processPdu abstract service interface. The following procedure is used when a notification is received:

  1. The incoming management target information is translated into outgoing management target information. The translation may result in multiple management targets.

  2. If appropriate outgoing management target information cannot be found and the notification was an Unconfirmed-Class PDU, processing is halted. If it was a Confirmed-Class PDU, the proxy forwarder increments the snmpProxyDrops object and calls returnResponsePdu with an error indication.

  3. The proxy forwarder generates a notification using the procedures described for Notification Originators, with the following exceptions: the contextEngineID and contextName from the original notification are used; the previously determined outgoing management targets are used; no filtering mechanisms are applied; and the variable-bindings from the original notification are used, with no access-control applied.

  4. If the original notification contains an Unconfirmed-Class PDU, processing is now completed. Otherwise it must contain a Confirmed-Class PDU, and processing continues.

  5. If the forwarded notifications included any Confirmed-Class PDUs, processing continues when the Notification Originator procedures determine that either none have been successfully acknowledged (in which case processing is halted), or at least one has been acknowledged.

  6. A Response-Class PDU is constructed using the request-id and variable-bindings from the original received Notification-Class PDU, with error-status and error-index of 0.

  7. The Dispatcher is called using the returnResponsePdu abstract service interface to generate the response.