Connected: An Internet Encyclopedia
RFC 1905 - 4.1. Common Constructs

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1905
Up: 4. Protocol Specification
Prev: 4. Protocol Specification
Next: 4.2. PDU Processing

### 4.1. Common Constructs

The value of the request-id field in a Response-PDU takes the value of the request-id field in the request PDU to which it is a response. By use of the request-id value, a SNMPv2 application can distinguish the (potentially multiple) outstanding requests, and thereby correlate incoming responses with outstanding requests. In cases where an unreliable datagram service is used, the request-id also provides a simple means of identifying messages duplicated by the network. Use of the same request-id on a retransmission of a request allows the response to either the original transmission or the retransmission to satisfy the request. However, in order to calculate the round trip time for transmission and processing of a request-response transaction, the SNMPv2 application needs to use a different request-id value on a retransmitted request. The latter strategy is recommended for use in the majority of situations.

A non-zero value of the error-status field in a Response-PDU is used to indicate that an exception occurred to prevent the processing of the request. In these cases, a non-zero value of the Response-PDU's error-index field provides additional information by identifying which variable binding in the list caused the exception. A variable binding is identified by its index value. The first variable binding in a variable-binding list is index one, the second is index two, etc.

SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128 sub- identifiers, where each sub-identifier has a maximum value of 2**32- 1.

Next: 4.2. PDU Processing

Connected: An Internet Encyclopedia
RFC 1905 - 4.1. Common Constructs