4. PROTOCOL SPECIFICATION
RFC1157-SNMP DEFINITIONS ::= BEGIN
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., get, set, getnext
ANY -- implementation-specific;
-- e.g., BindingList for
-- bind request
}
-- PDUs
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}
-- the individual PDUs and their syntax
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- sometimes ignored
ErrorStatus,
error-index -- sometimes ignored
ErrorIndex,
variable-bindings -- values are ignored
VarBindList
}
GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object
-- generating
-- trap
OBJECT IDENTIFIER,
agent-addr -- address of object
-- generating trap
NetworkAddress,
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present
-- even if generic-trap
-- is not equal to 6
INTEGER,
time-stamp -- time elapsed between
-- agent start-up and
-- trap generation
TimeTicks,
variable-bindings -- "interesting" info
VarBindList
}
RequestID ::=
INTEGER
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
}
ErrorIndex ::=
INTEGER
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
END
4.1. Elements of Procedure
The SNMP messages are sent to the well-known port number (UDP port 161) on the destination element. A SNMP entity (either an agent or a manager) receives messages at this port. Management requests are received by the agent, and management traps are received by the manager. The well-known port number for traps is the UDP port 162.
When a management station issues a request to an agent, it must copy the state of the "well-known" values into the corresponding fields of the request. The agent receiving the request will check the community name in the message, and if the authentication fails, it may optionally send an authentication trap.
The SNMP protocol entity acting in an agent role must be prepared to accept, on the well-known port, messages with a maximum acceptable length of 484 octets, and should be prepared to accept messages of at least 1024 octets.
The SNMP protocol entity acting in a manager role must be prepared to accept, on the well-known port for traps, messages with a maximum acceptable length of 484 octets, and should be prepared to accept messages of at least 1024 octets.
4.1.1. The Request/Response Operations
The following describes the procedure for generating and processing the get-request, get-next-request, get-response, and set-request operations.
4.1.1.1. Generating a Retrieval Request
When generating a retrieval request, the requesting SNMP entity (typically a manager) selects a value for the request-id field. This value, together with the source and destination transport addresses, enables the requesting protocol entity to match its incoming responses with outstanding requests. The error-status and error-index fields are set to zero. The variable-bindings field is set to the list of variables for which values are desired.
4.1.1.2. Receiving a Retrieval Request
Upon receiving a retrieval request, the receiving SNMP entity (typically an agent) determines the size of the response. If the size of the get-response PDU that would be generated exceeds the maximum acceptable length for the source transport, the receiving entity sends a get-response PDU with error-status of tooBig, error-index of zero, and the value field of all bound variables set to null.
Otherwise, for each object in the variable-bindings field, the receiving entity:
-
fetches the value of the named object, in the event that the object's name corresponds to an actual instance of the object, and that object is accessible; or
-
fails to find the named object, in the event that the name does not correspond to an actual instance of the object; or
-
finds that the named object exists, but that access to the object is forbidden.
In the first case, the name and value of the object are included in the variable-bindings field of the get-response PDU. In the second case, the name of the object is included, along with an indication that the object does not exist (i.e., the value field of the binding is set to null, but the type is not). In the third case, the name of the object is included, along with an indication that the named object exists, but that it is not accessible. The receiving entity then sets the error-status field of the get-response PDU to noError and the error-index field to zero.
If an object named in the variable-bindings field does not exist, the receiving entity sets the error-status field to noSuchName and the error-index field to the index of the failed object in the variable-bindings list. If an object named in the variable-bindings field exists but is not accessible, the receiving entity sets the error-status field to readOnly and the error-index field to the index of the failed object. In both cases, the value field of all bindings is set to null.
4.1.1.3. Generating a Set Request
When generating a set-request, the requesting SNMP entity (typically a manager) selects a value for the request-id field. The error-status and error-index fields are set to zero. The variable-bindings field is set to the list of variables whose values are to be modified.
4.1.1.4. Receiving a Set Request
Upon receiving a set-request, the receiving SNMP entity (typically an agent) first validates the operation as a whole. It checks that all variables named in the variable-bindings field exist and are accessible, and that the type and length of each value is consistent with the object's definition. If any check fails, the agent does not modify the values of any of the variables, and returns a get-response PDU with the appropriate error-status (noSuchName or badValue) and error-index set to the index of the failed variable.
If all checks succeed, the agent performs the set operation, modifying the values of the named variables. It then sends a get-response PDU with error-status of noError and error-index of zero, and includes the new values in the variable-bindings field.
If an error occurs during the set operation, the agent sends a get-response PDU with error-status of genErr and error-index set to the index of the variable at which the error was detected.
4.1.1.5. Receiving a Get Response
When a get-response is received by the requesting SNMP entity (typically a manager), it matches the message to an outstanding request using the request-id and the source transport address. It then processes the variable-bindings field according to the error-status and error-index fields. If the error-status is noError, the values are assigned to the corresponding local variables. Otherwise, the manager takes action appropriate to the indicated error.
4.1.2. The GetNextRequest-PDU
The semantics of the get-next-request PDU are similar to those of the get-request PDU, except that the variable named in the variable-bindings field of the request is that whose name is lexicographically next (in the MIB view) to the named variable. The get-next-request and get-response PDUs provide a means to "walk" the MIB, retrieving the values of a sequence of variables without knowing their exact names in advance.
4.1.3. The Trap Operation
Traps are asynchronous notifications sent by an agent to a manager. The agent generates a trap PDU when a significant event occurs, such as a cold or warm start, a link going down or up, an authentication failure, or the loss of an EGP neighbor. The trap PDU contains the enterprise, agent-addr, generic-trap, specific-trap, time-stamp, and variable-bindings fields. Because traps are unconfirmed, the agent does not expect any response from the manager.
Return: RFC 1157 Home