Skip to main content

3. Elements Of Procedure

The following sections describe the procedures followed by each of the five types of SNMP applications when generating and processing SNMP messages.

3.1. Command Generator Applications​

A command generator application makes use of the SNMP message processing subsystem to pass SNMP messages to a remote SNMP application.

The command generator must be capable of determining the transport domain and transport address of the remote application. The method by which this is accomplished is implementation dependent and outside the scope of this document.

The command generator must be capable of determining the appropriate SNMP message parameters (message processing model, security model, security level, and security name) to use when communicating with the remote application. The method by which this is accomplished is implementation dependent and outside the scope of this document.

3.1.1. Generating a Command Request​

To send an SNMP command request, the command generator application:

  1. Uses its local configuration information to determine:

    • Transport domain and transport address
    • Message processing model
    • Security model
    • Security name
    • Security level
    • Context engine ID (contextEngineID)
    • Context name (contextName)
    • The appropriate PDU (GetRequest, GetNextRequest, GetBulkRequest, or SetRequest)

  2. Invokes the message processing subsystem's send PDU primitive, passing:

    • Transport domain and transport address
    • Message processing model
    • Security model
    • Security name
    • Security level
    • contextEngineID
    • contextName
    • PDU

  3. The message processing subsystem returns a status indication. If an error is returned, the command generator should handle the error appropriately.

3.1.2. Processing a Response​

When a command generator receives a response:

  1. The message processing subsystem invokes the command generator's receive PDU primitive, passing:

    • Message processing model
    • Security model
    • Security name
    • Security level
    • contextEngineID
    • contextName
    • PDU
    • Maximum size (maxSizeResponseScopedPDU)
    • Status information

  2. The command generator verifies that the response matches an outstanding request (via request-id).

  3. The command generator checks the error-status in the response. If the error-status field is non-zero, an error occurred.

  4. The command generator processes the variable-bindings list in the response.

3.1.3. Timeouts and Retries​

If no response is received within a reasonable amount of time, the command generator may retransmit the request. The number of retries and timeout values are determined by local configuration or policy.

For reliable transport protocols (such as TCP), the transport layer itself may provide retransmission. In such cases, application-layer retries may be unnecessary or inappropriate.

3.2. Command Responder Applications​

A command responder application receives SNMP command requests and generates appropriate responses.

3.2.1. Processing a Request​

When a command responder receives a request:

  1. The message processing subsystem invokes the command responder's receive PDU primitive, passing:

    • Message processing model
    • Security model
    • Security name
    • Security level
    • contextEngineID
    • contextName
    • PDU
    • Maximum size (maxSizeResponseScopedPDU)
    • Status information

  2. The command responder verifies that the contextEngineID identifies the local SNMP engine. If not, the request is discarded.

  3. The command responder uses the access control subsystem (such as VACM defined in RFC 3415) to determine whether the security name is authorized to perform the requested operation.

  4. The command responder processes the PDU:

    • GetRequest: Retrieves values of requested MIB objects
    • GetNextRequest: Retrieves the next MIB object lexicographically following the requested object name
    • GetBulkRequest: Performs an optimized multi-variable retrieval
    • SetRequest: Modifies the values of specified MIB objects

  5. The command responder constructs a response PDU containing:

    • The same request-id as the request
    • Error-status (noError or an appropriate error code)
    • Error-index (if an error occurred, indicates which variable-binding caused the error)
    • Variable-bindings list (for Get operations, contains retrieved values; for Set operations, contains the set variables)

3.2.2. Generating a Response​

The command responder generates a response by:

  1. Constructing a Response-PDU with the appropriate error-status, error-index, and variable-bindings list.

  2. Invoking the message processing subsystem's return response PDU primitive, passing:

    • Message processing model (same as request)
    • Security model (same as request)
    • Security name (same as request)
    • Security level (same as request)
    • contextEngineID (same as request)
    • contextName (same as request)
    • PDU (the response PDU)
    • Maximum size (the maxSizeResponseScopedPDU from the request)
    • State reference (obtained from request processing)

  3. The message processing subsystem handles the formatting and transmission of the response message.

3.2.3. Error Handling​

If an error occurs while processing the request, the command responder must set an appropriate error-status in the response PDU:

  • tooBig: Response message is too large to be transmitted within maximum message size constraints
  • noSuchName: Requested object does not exist (SNMPv1 only)
  • badValue: The value supplied is inappropriate for the requested operation (SNMPv1 only)
  • readOnly: Attempted to modify a read-only object
  • genErr: A general error occurred
  • noAccess: Access denied (SNMPv2 and later)
  • wrongType: The variable has the wrong type (SNMPv2 and later)
  • wrongLength: The value has the wrong length (SNMPv2 and later)
  • wrongEncoding: The value has the wrong encoding (SNMPv2 and later)
  • wrongValue: The value is incorrect (SNMPv2 and later)
  • noCreation: Creation is not allowed (SNMPv2 and later)
  • inconsistentValue: The value is inconsistent (SNMPv2 and later)
  • resourceUnavailable: Resources are unavailable (SNMPv2 and later)
  • commitFailed: Commit failed (SNMPv2 and later)
  • undoFailed: Undo failed (SNMPv2 and later)
  • authorizationError: Authorization error (SNMPv2 and later)
  • notWritable: The object is not writable (SNMPv2 and later)
  • inconsistentName: The name is inconsistent (SNMPv2 and later)

3.3. Notification Originator Applications​

A notification originator application generates SNMP notification messages (traps or inform requests).

3.3.1. Generating a Notification​

To send an SNMP notification, the notification originator:

  1. Determines the set of management targets that should receive this notification. This is typically done by consulting the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB.

  2. For each selected management target:

    a. Determines the transport domain and transport address

    b. Determines the SNMP message parameters:

    • Message processing model
    • Security model
    • Security name
    • Security level

    c. Determines the notification type (trap or inform)

    d. Constructs the appropriate PDU:

    • SNMPv2-Trap-PDU: For unconfirmed notifications
    • InformRequest-PDU: For confirmed notifications

    e. The PDU should contain:

    • sysUpTime.0 variable (time since engine started)
    • snmpTrapOID.0 variable (object identifier of the notification)
    • Additional variable-bindings for the notification

    f. Invokes the message processing subsystem's send PDU primitive

3.3.2. Processing a Response to an Inform Request​

If the notification type is inform (InformRequest-PDU), the notification originator must wait for a response:

  1. If a response is received within the timeout period:

    • Verify that the response matches the outstanding inform request (via request-id)
    • Check the error-status
    • Confirm that the notification was successfully delivered

  2. If no response is received within the timeout period:

    • Depending on the configured retry policy, may retransmit the inform request
    • Or, log the failure locally and abandon this delivery attempt

  3. For traps (SNMPv2-Trap-PDU), no response is expected, so the notification originator completes immediately after sending.

3.4. Notification Receiver Applications​

A notification receiver application receives SNMP notification messages.

3.4.1. Processing a Received Notification​

When a notification receiver receives a notification:

  1. The message processing subsystem invokes the notification receiver's receive PDU primitive, passing:

    • Message processing model
    • Security model
    • Security name
    • Security level
    • contextEngineID
    • contextName
    • PDU
    • Maximum size
    • Status information

  2. The notification receiver extracts the notification information:

    • sysUpTime.0 (timestamp)
    • snmpTrapOID.0 (notification type)
    • Additional variable-bindings (notification data)

  3. The notification receiver processes the notification according to local policy:

    • Log to a log file
    • Display an alert
    • Trigger an automated response action
    • Forward to other management systems

3.4.2. Responding to an Inform Request​

If an InformRequest-PDU is received, the notification receiver must generate a response:

  1. Construct a Response-PDU containing:

    • The same request-id as the request
    • Error-status (typically noError)
    • Error-index (typically 0)
    • Variable-bindings list (typically the same as in the request)

  2. Invoke the message processing subsystem's return response PDU primitive to send the response.

For SNMPv2-Trap-PDU, no response is generated.

3.5. Proxy Forwarder Applications​

A proxy forwarder application forwards SNMP messages between SNMP entities. Proxy forwarders can perform protocol translation, security translation, or management information view translation.

A proxy forwarder application performs two types of forwarding:

  1. Request Forwarding: Forwarding command requests and their responses
  2. Notification Forwarding: Forwarding notification messages

3.5.1. Request Forwarding​

When a proxy forwarder receives a command request:

  1. The message processing subsystem invokes the proxy forwarder's receive PDU primitive, passing the request parameters.

  2. The proxy forwarder uses the SNMP-PROXY-MIB to determine how to forward the request:

    a. Consults the snmpProxyTable, using the received parameters as a key:

    • contextEngineID
    • contextName
    • Transport domain and transport address
    • PDU type

    b. If a matching entry is found, extracts the forwarding parameters:

    • Target transport domain and transport address
    • Target message processing model
    • Target security model
    • Target security name
    • Target security level
    • Target contextEngineID
    • Target contextName

  3. The proxy forwarder may need to modify the PDU to accommodate the target SNMP version. For example:

    • SNMPv2 to SNMPv1: Convert error-status codes
    • SNMPv1 to SNMPv2: Convert trap PDU format

  4. The proxy forwarder invokes the message processing subsystem's send PDU primitive to forward the modified request to the target.

  5. When a response is received from the target:

    a. May need to modify the response PDU again to accommodate the original requester's SNMP version

    b. Invokes the message processing subsystem's return response PDU primitive to forward the response back to the original requester

3.5.2. Notification Forwarding​

When a proxy forwarder receives a notification:

  1. The message processing subsystem invokes the proxy forwarder's receive PDU primitive, passing the notification parameters.

  2. The proxy forwarder uses the SNMP-PROXY-MIB to determine how to forward the notification:

    a. Consults the snmpProxyTable, using the received parameters as a key

    b. If a matching entry is found, extracts the forwarding parameters

  3. The proxy forwarder may need to modify the notification PDU:

    • SNMPv1 trap to SNMPv2 trap: Convert PDU format and variable-bindings
    • SNMPv2 trap to SNMPv1 trap: Convert PDU format

  4. The proxy forwarder invokes the message processing subsystem's send PDU primitive to forward the notification to the target.

  5. If the original notification was an InformRequest-PDU and the forwarded notification is also an InformRequest-PDU:

    a. Wait for a response from the target

    b. When the response is received, forward the response back to the original notification originator

3.5.3. Special Considerations for Proxy Forwarders​

Proxy forwarders must handle several special cases:

  1. PDU Size Adjustment: If the target supports a smaller maximum message size than the original request, the proxy forwarder may need to return a tooBig error or split the request.

  2. Context Translation: The proxy forwarder may need to map between different contextEngineIDs and contextNames.

  3. Access Control: The proxy forwarder applies its own access control policies in addition to any access control at the target command responder.

  4. Error Mapping: When translating between SNMP versions, error codes may need to be mapped. For example, an SNMPv2 noAccess error may need to be mapped to genErr in SNMPv1.

  5. Timeouts and Retries: The proxy forwarder may need to implement its own timeout and retry mechanism for forwarded requests, independent of the original requester's timeout.

  6. Notification Filtering: For notification forwarding, the proxy forwarder can apply filtering rules to selectively forward specific types of notifications.

Last updated on