Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)
RFC 1905
| Document | Type |
RFC - Draft Standard
(January 1996)
Obsoleted by RFC 3416
Obsoletes RFC 1448
|
|
|---|---|---|---|
| Authors | Dr. Jeff D. Case , Keith McCloghrie, Dr. Marshall T. Rose , Steven Waldbusser | ||
| Last updated | 2013-03-02 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | RFC 1905 (Draft Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
RFC 1905
Network Working Group SNMPv2 Working Group
Request for Comments: 1905 J. Case
Obsoletes: 1448 SNMP Research, Inc.
Category: Standards Track K. McCloghrie
Cisco Systems, Inc.
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
International Network Services
January 1996
Protocol Operations
for Version 2 of the
Simple Network Management Protocol (SNMPv2)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
1. Introduction
A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a
management protocol, used to convey management information between
the agents and management stations. Operations of the protocol are
carried out under an administrative framework which defines
authentication, authorization, access control, and privacy policies.
Management stations execute management applications which monitor and
control managed elements. Managed elements are devices such as
hosts, routers, terminal servers, etc., which are monitored and
controlled via access to their management information.
Management information is viewed as a collection of managed objects,
residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined
in MIB modules. These modules are written using a subset of OSI's
Abstract Syntax Notation One (ASN.1) [1], termed the Structure of
Management Information (SMI) [2].
SNMPv2 Working Group Standards Track [Page 1]
RFC 1905 Protocol Operations for SNMPv2 January 1996
The management protocol, version 2 of the Simple Network Management
Protocol, provides for the exchange of messages which convey
management information between the agents and the management
stations. The form of these messages is a message "wrapper" which
encapsulates a Protocol Data Unit (PDU). The form and meaning of the
"wrapper" is determined by an administrative framework which defines
both authentication and authorization policies.
It is the purpose of this document, Protocol Operations for SNMPv2,
to define the operations of the protocol with respect to the sending
and receiving of the PDUs.
1.1. A Note on Terminology
For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD
15), and 1212 (STD 16), is termed the SNMP version 1 framework
(SNMPv1). The current framework is termed the SNMP version 2
framework (SNMPv2).
2. Overview
2.1. Roles of Protocol Entities
A SNMPv2 entity may operate in a manager role or an agent role.
A SNMPv2 entity acts in an agent role when it performs SNMPv2
management operations in response to received SNMPv2 protocol
messages (other than an inform notification) or when it sends trap
notifications.
A SNMPv2 entity acts in a manager role when it initiates SNMPv2
management operations by the generation of SNMPv2 protocol messages
or when it performs SNMPv2 management operations in response to
received trap or inform notifications.
A SNMPv2 entity may support either or both roles, as dictated by its
implementation and configuration. Further, a SNMPv2 entity can also
act in the role of a proxy agent, in which it appears to be acting in
an agent role, but satisfies management requests by acting in a
manager role with a remote entity.
2.2. 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 [2] or
the textual conventions based on the SMI [3]. The term, variable
binding, normally refers to the pairing of the name of a variable and
SNMPv2 Working Group Standards Track [Page 2]
RFC 1905 Protocol Operations for SNMPv2 January 1996
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.3. Access to Management Information
Three types of access to management information are provided by the
protocol. One type is a request-response interaction, in which a
SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2
entity, acting in an agent role, and the latter SNMPv2 entity then
responds to the request. This type is used to retrieve or modify
management information associated with the managed device.
A second type is also a request-response interaction, in which a
SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2
entity, also acting in a manager role, and the latter SNMPv2 entity
then responds to the request. This type is used to notify a SNMPv2
entity, acting in a manager role, of management information
associated with another SNMPv2 entity, also acting in a manager role.
The third type of access is an unconfirmed interaction, in which a
SNMPv2 entity, acting in an agent role, sends a unsolicited message,
termed a trap, to a SNMPv2 entity, acting in a manager role, and no
response is returned. This type is used to notify a SNMPv2 entity,
acting in a manager role, of an exceptional situation, which has
resulted in changes to management information associated with the
managed device.
2.4. 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 or not a request should be
retransmitted if no corresponding response is received in an
appropriate time interval, is at the discretion of the application
originating the request. This will normally depend on the urgency of
the request. However, such an application needs to act responsibly
in respect to the frequency and duration of re-transmissions.
SNMPv2 Working Group Standards Track [Page 3]
RFC 1905 Protocol Operations for SNMPv2 January 1996
2.5. Message Sizes
The maximum size of a SNMPv2 message is limited to the minimum of:
(1) the maximum message size which the destination SNMPv2 entity can
accept; and,
(2) the maximum message size which the source SNMPv2 entity can
generate.
The former may be known on a per-recipient basis; and in the absence
of such knowledge, is indicated by transport domain used when sending
the message. The latter is imposed by implementation-specific local
constraints.
Each transport mapping for the SNMPv2 indicates the minimum message
size which a SNMPv2 implementation must be able to produce or
consume. Although implementations are encouraged to support larger
values whenever possible, a conformant implementation must never
generate messages larger than allowed by the receiving SNMPv2 entity.
One of the aims of the GetBulkRequest-PDU, specified in this
protocol, is to minimize the number of protocol exchanges required to
retrieve a large amount of management information. As such, this PDU
type allows a SNMPv2 entity acting in a manager role to request that
the response be as large as possible given the constraints on message
sizes. These constraints include the limits on the size of messages
which the SNMPv2 entity acting in an agent role can generate, and the
SNMPv2 entity acting in a manager role can receive.
However, it is possible that such maximum sized messages may be
larger than the Path MTU of the path across the network traversed by
the messages. In this situation, such messages are subject to
fragmentation. Fragmentation is generally considered to be harmful
[4], since among other problems, it leads to a decrease in the
reliability of the transfer of the messages. Thus, a SNMPv2 entity
which sends a GetBulkRequest-PDU must take care to set its parameters
accordingly, so as to reduce the risk of fragmentation. In
particular, under conditions of network stress, only small values
should be used for max-repetitions.
2.6. Transport Mappings
It is important to note that the exchange of SNMPv2 messages requires
only an unreliable datagram service, with every message being
entirely and independently contained in a single transport datagram.
Specific transport mappings and encoding rules are specified
elsewhere [5]. However, the preferred mapping is the use of the User
SNMPv2 Working Group Standards Track [Page 4]
RFC 1905 Protocol Operations for SNMPv2 January 1996
Datagram Protocol [6].
3. Definitions
SNMPv2-PDU DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, Integer32
FROM SNMPv2-SMI;
-- protocol data units
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-bulk-request
GetBulkRequest-PDU,
response
Response-PDU,
set-request
SetRequest-PDU,
inform-request
InformRequest-PDU,
snmpV2-trap
SNMPv2-Trap-PDU,
report
Report-PDU,
}
-- PDUs
GetRequest-PDU ::=
[0]
IMPLICIT PDU
GetNextRequest-PDU ::=
SNMPv2 Working Group Standards Track [Page 5]
RFC 1905 Protocol Operations for SNMPv2 January 1996
[1]
IMPLICIT PDU
Response-PDU ::=
[2]
IMPLICIT PDU
SetRequest-PDU ::=
[3]
IMPLICIT PDU
-- [4] is obsolete
GetBulkRequest-PDU ::=
[5]
IMPLICIT BulkPDU
InformRequest-PDU ::=
[6]
IMPLICIT PDU
SNMPv2-Trap-PDU ::=
[7]
IMPLICIT PDU
-- Usage and precise semantics of Report-PDU are not presently
-- defined. Any SNMP administrative framework making use of
-- this PDU must define its usage and semantics.
Report-PDU ::=
[8]
IMPLICIT PDU
max-bindings
INTEGER ::= 2147483647
PDU ::=
SEQUENCE {
request-id
Integer32,
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2), -- for proxy compatibility
badValue(3), -- for proxy compatibility
readOnly(4), -- for proxy compatibility
genErr(5),
SNMPv2 Working Group Standards Track [Page 6]
RFC 1905 Protocol Operations for SNMPv2 January 1996
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnavailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18)
},
error-index -- sometimes ignored
INTEGER (0..max-bindings),
variable-bindings -- values are sometimes ignored
VarBindList
}
BulkPDU ::= -- MUST be identical in
SEQUENCE { -- structure to PDU
request-id
Integer32,
non-repeaters
INTEGER (0..max-bindings),
max-repetitions
INTEGER (0..max-bindings),
variable-bindings -- values are ignored
VarBindList
}
-- variable binding
VarBind ::=
SEQUENCE {
name
ObjectName,
CHOICE {
value
SNMPv2 Working Group Standards Track [Page 7]
RFC 1905 Protocol Operations for SNMPv2 January 1996
ObjectSyntax,
unSpecified -- in retrieval requests
NULL,
-- exceptions in responses
noSuchObject[0]
IMPLICIT NULL,
noSuchInstance[1]
IMPLICIT NULL,
endOfMibView[2]
IMPLICIT NULL
}
}
-- variable-binding list
VarBindList ::=
SEQUENCE (SIZE (0..max-bindings)) OF
VarBind
END
4. Protocol Specification
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.
SNMPv2 Working Group Standards Track [Page 8]
RFC 1905 Protocol Operations for SNMPv2 January 1996
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.
4.2. PDU Processing
It is mandatory that all SNMPv2 entities acting in an agent role be
able to generate the following PDU types: Response-PDU and SNMPv2-
Trap-PDU; further, all such implementations must be able to receive
the following PDU types: GetRequest-PDU, GetNextRequest-PDU,
GetBulkRequest-PDU, and SetRequest-PDU.
It is mandatory that all SNMPv2 entities acting in a manager role be
able to generate the following PDU types: GetRequest-PDU,
GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
InformRequest-PDU, and Response-PDU; further, all such
implementations must be able to receive the following PDU types:
Response-PDU, SNMPv2-Trap-PDU,
InformRequest-PDU;
In the elements of procedure below, any field of a PDU which is not
referenced by the relevant procedure is ignored by the receiving
SNMPv2 entity. However, all components of a PDU, including those
whose values are ignored by the receiving SNMPv2 entity, must have
valid ASN.1 syntax and encoding. For example, some PDUs (e.g., the
GetRequest-PDU) are concerned only with the name of a variable and
not its value. In this case, the value portion of the variable
binding is ignored by the receiving SNMPv2 entity. The unSpecified
value is defined for use as the value portion of such bindings.
On generating a management communication, the message "wrapper" to
encapsulate the PDU is generated according to the "Elements of
Procedure" of the administrative framework in use is followed. While
the definition of "max-bindings" does impose an upper-bound on the
number of variable bindings, in practice, the size of a message is
limited only by constraints on the maximum message size -- it is not
limited by the number of variable bindings.
SNMPv2 Working Group Standards Track [Page 9]
RFC 1905 Protocol Operations for SNMPv2 January 1996
On receiving a management communication, the "Elements of Procedure"
of the administrative framework in use is followed, and if those
procedures indicate that the operation contained within the message
is to be performed locally, then those procedures also indicate the
MIB view which is visible to the operation.
4.2.1. The GetRequest-PDU
A GetRequest-PDU is generated and transmitted at the request of a
SNMPv2 application.
Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity
processes each variable binding in the variable-binding list to
produce a Response-PDU. All fields of the Response-PDU have the same
values as the corresponding fields of the received request except as
indicated below. Each variable binding is processed as follows:
(1) If the variable binding's name exactly matches the name of a
variable accessible by this request, then the variable binding's
value field is set to the value of the named variable.
(2) Otherwise, if the variable binding's name does not have an OBJECT
IDENTIFIER prefix which exactly matches the OBJECT IDENTIFIER
prefix of any (potential) variable accessible by this request, then
its value field is set to `noSuchObject'.
(3) Otherwise, the variable binding's value field is set to
`noSuchInstance'.
If the processing of any variable binding fails for a reason other
than listed above, then the Response-PDU is re-formatted with the
same values in its request-id and variable-bindings fields as the
received GetRequest-PDU, with the value of its error-status field set
to `genErr', and the value of its error-index field is set to the
index of the failed variable binding.
Otherwise, the value of the Response-PDU's error-status field is set
to `noError', and the value of its error-index field is zero.
The generated Response-PDU is then encapsulated into a message. If
the size of the resultant message is less than or equal to both a
local constraint and the maximum message size of the originator, it
is transmitted to the originator of the GetRequest-PDU.
Otherwise, an alternate Response-PDU is generated. This alternate
Response-PDU is formatted with the same value in its request-id field
as the received GetRequest-PDU, with the value of its error-status
field set to `tooBig', the value of its error-index field set to
SNMPv2 Working Group Standards Track [Page 10]
RFC 1905 Protocol Operations for SNMPv2 January 1996
zero, and an empty variable-bindings field. This alternate
Response-PDU is then encapsulated into a message. If the size of the
resultant message is less than or equal to both a local constraint
and the maximum message size of the originator, it is transmitted to
the originator of the GetRequest-PDU. Otherwise, the snmpSilentDrops
[9] counter is incremented and the resultant message is discarded.
4.2.2. The GetNextRequest-PDU
A GetNextRequest-PDU is generated and transmitted at the request of a
SNMPv2 application.
Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2 entity
processes each variable binding in the variable-binding list to
produce a Response-PDU. All fields of the Response-PDU have the same
values as the corresponding fields of the received request except as
indicated below. Each variable binding is processed as follows:
(1) The variable is located which is in the lexicographically ordered
list of the names of all variables which are accessible by this
request and whose name is the first lexicographic successor of the
variable binding's name in the incoming GetNextRequest-PDU. The
corresponding variable binding's name and value fields in the
Response-PDU are set to the name and value of the located variable.
(2) If the requested variable binding's name does not lexicographically
precede the name of any variable accessible by this request, i.e.,
there is no lexicographic successor, then the corresponding
variable binding produced in the Response-PDU has its value field
set to `endOfMibView', and its name field set to the variable
binding's name in the request.
If the processing of any variable binding fails for a reason other
than listed above, then the Response-PDU is re-formatted with the
same values in its request-id and variable-bindings fields as the
received GetNextRequest-PDU, with the value of its error-status field
set to `genErr', and the value of its error-index field is set to the
index of the failed variable binding.
Otherwise, the value of the Response-PDU's error-status field is set
to `noError', and the value of its error-index field is zero.
The generated Response-PDU is then encapsulated into a message. If
the size of the resultant message is less than or equal to both a
local constraint and the maximum message size of the originator, it
is transmitted to the originator of the GetNextRequest-PDU.
SNMPv2 Working Group Standards Track [Page 11]
RFC 1905 Protocol Operations for SNMPv2 January 1996
Otherwise, an alternate Response-PDU is generated. This alternate
Response-PDU is formatted with the same values in its request-id
field as the received GetNextRequest-PDU, with the value of its
error-status field set to `tooBig', the value of its error-index
field set to zero, and an empty variable-bindings field. This
alternate Response-PDU is then encapsulated into a message. If the
size of the resultant message is less than or equal to both a local
constraint and the maximum message size of the originator, it is
transmitted to the originator of the GetNextRequest-PDU. Otherwise,
the snmpSilentDrops [9] counter is incremented and the resultant
message is discarded.
4.2.2.1. Example of Table Traversal
An important use of the GetNextRequest-PDU is the traversal of
conceptual tables of information within a MIB. The semantics of this
type of request, together with the method of identifying individual
instances of objects in the MIB, provides access to related objects
in the MIB as if they enjoyed a tabular organization.
In the protocol exchange sketched below, a SNMPv2 application
retrieves the media-dependent physical address and the address-
mapping type for each entry in the IP net-to-media Address
Translation Table [7] of a particular network element. It also
retrieves the value of sysUpTime [9], at which the mappings existed.
Suppose that the agent's IP net-to-media table has three entries:
Interface-Number Network-Address Physical-Address Type
1 10.0.0.51 00:00:10:01:23:45 static
1 9.2.3.4 00:00:10:54:32:10 dynamic
2 10.0.0.15 00:00:10:98:76:54 dynamic
The SNMPv2 entity acting in a manager role begins by sending a
GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values
as the requested variable names:
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType )
The SNMPv2 entity acting in an agent role responds with a Response-
PDU:
Response (( sysUpTime.0 = "123456" ),
( ipNetToMediaPhysAddress.1.9.2.3.4 =
"000010543210" ),
( ipNetToMediaType.1.9.2.3.4 = "dynamic" ))
SNMPv2 Working Group Standards Track [Page 12]
RFC 1905 Protocol Operations for SNMPv2 January 1996
The SNMPv2 entity acting in a manager role continues with:
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.1.9.2.3.4,
ipNetToMediaType.1.9.2.3.4 )
The SNMPv2 entity acting in an agent role responds with:
Response (( sysUpTime.0 = "123461" ),
( ipNetToMediaPhysAddress.1.10.0.0.51 =
"000010012345" ),
( ipNetToMediaType.1.10.0.0.51 = "static" ))
The SNMPv2 entity acting in a manager role continues with:
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51 )
The SNMPv2 entity acting in an agent role responds with:
Response (( sysUpTime.0 = "123466" ),
( ipNetToMediaPhysAddress.2.10.0.0.15 =
"000010987654" ),
( ipNetToMediaType.2.10.0.0.15 = "dynamic" ))
The SNMPv2 entity acting in a manager role continues with:
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.2.10.0.0.15,
ipNetToMediaType.2.10.0.0.15 )
As there are no further entries in the table, the SNMPv2 entity
acting in an agent role responds with the variables that are next in
the lexicographical ordering of the accessible object names, for
example:
Response (( sysUpTime.0 = "123471" ),
( ipNetToMediaNetAddress.1.9.2.3.4 =
"9.2.3.4" ),
( ipRoutingDiscards.0 = "2" ))
This response signals the end of the table to the SNMPv2 entity
acting in a manager role.
SNMPv2 Working Group Standards Track [Page 13]
RFC 1905 Protocol Operations for SNMPv2 January 1996
4.2.3. The GetBulkRequest-PDU
A GetBulkRequest-PDU is generated and transmitted at the request of a
SNMPv2 application. The purpose of the GetBulkRequest-PDU is to
request the transfer of a potentially large amount of data,
including, but not limited to, the efficient and rapid retrieval of
large tables.
Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2 entity
processes each variable binding in the variable-binding list to
produce a Response-PDU with its request-id field having the same
value as in the request. Processing begins by examining the values
in the non-repeaters and max-repetitions fields. If the value in the
non-repeaters field is less than zero, then the value of the field is
set to zero. Similarly, if the value in the max-repetitions field is
less than zero, then the value of the field is set to zero.
For the GetBulkRequest-PDU type, the successful processing of each
variable binding in the request generates zero or more variable
bindings in the Response-PDU. That is, the one-to-one mapping
between the variable bindings of the GetRequest-PDU, GetNextRequest-
PDU, and SetRequest-PDU types and the resultant Response-PDUs does
not apply for the mapping between the variable bindings of a
GetBulkRequest-PDU and the resultant Response-PDU.
The values of the non-repeaters and max-repetitions fields in the
request specify the processing requested. One variable binding in
the Response-PDU is requested for the first N variable bindings in
the request and M variable bindings are requested for each of the R
remaining variable bindings in the request. Consequently, the total
number of requested variable bindings communicated by the request is
given by N + (M * R), where N is the minimum of: a) the value of the
non-repeaters field in the request, and b) the number of variable
bindings in the request; M is the value of the max-repetitions field
in the request; and R is the maximum of: a) number of variable
bindings in the request - N, and b) zero.
The receiving SNMPv2 entity produces a Response-PDU with up to the
total number of requested variable bindings communicated by the
request. The request-id shall have the same value as the received
GetBulkRequest-PDU.
If N is greater than zero, the first through the (N)-th variable
bindings of the Response-PDU are each produced as follows:
(1) The variable is located which is in the lexicographically ordered
list of the names of all variables which are accessible by this
request and whose name is the first lexicographic successor of the
SNMPv2 Working Group Standards Track [Page 14]
RFC 1905 Protocol Operations for SNMPv2 January 1996
variable binding's name in the incoming GetBulkRequest-PDU. The
corresponding variable binding's name and value fields in the
Response-PDU are set to the name and value of the located variable.
(2) If the requested variable binding's name does not lexicographically
precede the name of any variable accessible by this request, i.e.,
there is no lexicographic successor, then the corresponding
variable binding produced in the Response-PDU has its value field
set to `endOfMibView', and its name field set to the variable
binding's name in the request.
If M and R are non-zero, the (N + 1)-th and subsequent variable
bindings of the Response-PDU are each produced in a similar manner.
For each iteration i, such that i is greater than zero and less than
or equal to M, and for each repeated variable, r, such that r is
greater than zero and less than or equal to R, the (N + ( (i-1) * R )
+ r)-th variable binding of the Response-PDU is produced as follows:
(1) The variable which is in the lexicographically ordered list of the
names of all variables which are accessible by this request and
whose name is the (i)-th lexicographic successor of the (N + r)-th
variable binding's name in the incoming GetBulkRequest-PDU is
located and the variable binding's name and value fields are set to
the name and value of the located variable.
(2) If there is no (i)-th lexicographic successor, then the
corresponding variable binding produced in the Response-PDU has its
value field set to `endOfMibView', and its name field set to either
the last lexicographic successor, or if there are no lexicographic
successors, to the (N + r)-th variable binding's name in the
request.
While the maximum number of variable bindings in the Response-PDU is
bounded by N + (M * R), the response may be generated with a lesser
number of variable bindings (possibly zero) for either of three
reasons.
(1) If the size of the message encapsulating the Response-PDU
containing the requested number of variable bindings would be
greater than either a local constraint or the maximum message size
of the originator, then the response is generated with a lesser
number of variable bindings. This lesser number is the ordered set
of variable bindings with some of the variable bindings at the end
of the set removed, such that the size of the message encapsulating
the Response-PDU is approximately equal to but no greater than
either a local constraint or the maximum message size of the
originator. Note that the number of variable bindings removed has
no relationship to the values of N, M, or R.
SNMPv2 Working Group Standards Track [Page 15]
RFC 1905 Protocol Operations for SNMPv2 January 1996
(2) The response may also be generated with a lesser number of variable
bindings if for some value of iteration i, such that i is greater
than zero and less than or equal to M, that all of the generated
variable bindings have the value field set to the `endOfMibView'.
In this case, the variable bindings may be truncated after the (N +
(i * R))-th variable binding.
(3) In the event that the processing of a request with many repetitions
requires a significantly greater amount of processing time than a
normal request, then an agent may terminate the request with less
than the full number of repetitions, providing at least one
repetition is completed.
If the processing of any variable binding fails for a reason other
than listed above, then the Response-PDU is re-formatted with the
same values in its request-id and variable-bindings fields as the
received GetBulkRequest-PDU, with the value of its error-status field
set to `genErr', and the value of its error-index field is set to the
index of the variable binding in the original request which
corresponds to the failed variable binding.
Otherwise, the value of the Response-PDU's error-status field is set
to `noError', and the value of its error-index field to zero.
The generated Response-PDU (possibly with an empty variable-bindings
field) is then encapsulated into a message. If the size of the
resultant message is less than or equal to both a local constraint
and the maximum message size of the originator, it is transmitted to
the originator of the GetBulkRequest-PDU. Otherwise, the
snmpSilentDrops [9] counter is incremented and the resultant message
is discarded.
4.2.3.1. Another Example of Table Traversal
This example demonstrates how the GetBulkRequest-PDU can be used as
an alternative to the GetNextRequest-PDU. The same traversal of the
IP net-to-media table as shown in Section 4.2.2.1 is achieved with
fewer exchanges.
The SNMPv2 entity acting in a manager role begins by sending a
GetBulkRequest-PDU with the modest max-repetitions value of 2, and
containing the indicated OBJECT IDENTIFIER values as the requested
variable names:
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
( sysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType )
SNMPv2 Working Group Standards Track [Page 16]
RFC 1905 Protocol Operations for SNMPv2 January 1996
The SNMPv2 entity acting in an agent role responds with a Response-PDU:
Response (( sysUpTime.0 = "123456" ),
( ipNetToMediaPhysAddress.1.9.2.3.4 =
"000010543210" ),
( ipNetToMediaType.1.9.2.3.4 = "dynamic" ),
( ipNetToMediaPhysAddress.1.10.0.0.51 =
"000010012345" ),
( ipNetToMediaType.1.10.0.0.51 = "static" ))
The SNMPv2 entity acting in a manager role continues with:
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
( sysUpTime,
ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51 )
The SNMPv2 entity acting in an agent role responds with:
Response (( sysUpTime.0 = "123466" ),
( ipNetToMediaPhysAddress.2.10.0.0.15 =
"000010987654" ),
( ipNetToMediaType.2.10.0.0.15 =
"dynamic" ),
( ipNetToMediaNetAddress.1.9.2.3.4 =
"9.2.3.4" ),
( ipRoutingDiscards.0 = "2" ))
This response signals the end of the table to the SNMPv2 entity
acting in a manager role.
4.2.4. The Response-PDU
The Response-PDU is generated by a SNMPv2 entity only upon receipt of
a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU,
SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this
document.
If the error-status field of the Response-PDU is non-zero, the value
fields of the variable bindings in the variable binding list are
ignored.
If both the error-status field and the error-index field of the
Response-PDU are non-zero, then the value of the error-index field is
the index of the variable binding (in the variable-binding list of
the corresponding request) for which the request failed. The first
variable binding in a request's variable-binding list is index one,
the second is index two, etc.
SNMPv2 Working Group Standards Track [Page 17]
RFC 1905 Protocol Operations for SNMPv2 January 1996
A compliant SNMPv2 entity acting in a manager role must be able to
properly receive and handle a Response-PDU with an error-status field
equal to `noSuchName', `badValue', or `readOnly'. (See Section 3.1.2
of [8].)
Upon receipt of a Response-PDU, the receiving SNMPv2 entity presents
its contents to the SNMPv2 application which generated the request
with the same request-id value.
4.2.5. The SetRequest-PDU
A SetRequest-PDU is generated and transmitted at the request of a
SNMPv2 application.
Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity
determines the size of a message encapsulating a Response-PDU having
the same values in its request-id and variable-bindings fields as the
received SetRequest-PDU, and the largest possible sizes of the
error-status and error-index fields. If the determined message size
is greater than either a local constraint or the maximum message size
of the originator, then an alternate Response-PDU is generated,
transmitted to the originator of the SetRequest-PDU, and processing
of the SetRequest-PDU terminates immediately thereafter. This
alternate Response-PDU is formatted with the same values in its
request-id field as the received SetRequest-PDU, with the value of
its error-status field set to `tooBig', the value of its error-index
field set to zero, and an empty variable-bindings field. This
alternate Response-PDU is then encapsulated into a message. If the
size of the resultant message is less than or equal to both a local
constraint and the maximum message size of the originator, it is
transmitted to the originator of the SetRequest-PDU. Otherwise, the
snmpSilentDrops [9] counter is incremented and the resultant message
is discarded. Regardless, processing of the SetRequest-PDU
terminates.
Otherwise, the receiving SNMPv2 entity processes each variable
binding in the variable-binding list to produce a Response-PDU. All
fields of the Response-PDU have the same values as the corresponding
fields of the received request except as indicated below.
The variable bindings are conceptually processed as a two phase
operation. In the first phase, each variable binding is validated;
if all validations are successful, then each variable is altered in
the second phase. Of course, implementors are at liberty to
implement either the first, or second, or both, of these conceptual
phases as multiple implementation phases. Indeed, such multiple
implementation phases may be necessary in some cases to ensure
consistency.
SNMPv2 Working Group Standards Track [Page 18]
RFC 1905 Protocol Operations for SNMPv2 January 1996
The following validations are performed in the first phase on each
variable binding until they are all successful, or until one fails:
(1) If the variable binding's name specifies an existing or non-
existent variable to which this request is/would be denied access
because it is/would not be in the appropriate MIB view, then the
value of the Response-PDU's error-status field is set to
`noAccess', and the value of its error-index field is set to the
index of the failed variable binding.
(2) Otherwise, if there are no variables which share the same OBJECT
IDENTIFIER prefix as the variable binding's name, and which are
able to be created or modified no matter what new value is
specified, then the value of the Response-PDU's error-status field
is set to `notWritable', and the value of its error-index field is
set to the index of the failed variable binding.
(3) Otherwise, if the variable binding's value field specifies,
according to the ASN.1 language, a type which is inconsistent with
that required for all variables which share the same OBJECT
IDENTIFIER prefix as the variable binding's name, then the value of
the Response-PDU's error-status field is set to `wrongType', and
the value of its error-index field is set to the index of the
failed variable binding.
(4) Otherwise, if the variable binding's value field specifies,
according to the ASN.1 language, a length which is inconsistent
with that required for all variables which share the same OBJECT
IDENTIFIER prefix as the variable binding's name, then the value of
the Response-PDU's error-status field is set to `wrongLength', and
the value of its error-index field is set to the index of the
failed variable binding.
(5) Otherwise, if the variable binding's value field contains an ASN.1
encoding which is inconsistent with that field's ASN.1 tag, then
the value of the Response-PDU's error-status field is set to
`wrongEncoding', and the value of its error-index field is set to
the index of the failed variable binding. (Note that not all
implementation strategies will generate this error.)
(6) Otherwise, if the variable binding's value field specifies a value
which could under no circumstances be assigned to the variable,
then the value of the Response-PDU's error-status field is set to
`wrongValue', and the value of its error-index field is set to the
index of the failed variable binding.
(7) Otherwise, if the variable binding's name specifies a variable
which does not exist and could not ever be created (even though
SNMPv2 Working Group Standards Track [Page 19]
RFC 1905 Protocol Operations for SNMPv2 January 1996
some variables sharing the same OBJECT IDENTIFIER prefix might
under some circumstances be able to be created), then the value of
the Response-PDU's error-status field is set to `noCreation', and
the value of its error-index field is set to the index of the
failed variable binding.
(8) Otherwise, if the variable binding's name specifies a variable
which does not exist but can not be created under the present
circumstances (even though it could be created under other
circumstances), then the value of the Response-PDU's error-status
field is set to `inconsistentName', and the value of its error-
index field is set to the index of the failed variable binding.
(9) Otherwise, if the variable binding's name specifies a variable
which exists but can not be modified no matter what new value is
specified, then the value of the Response-PDU's error-status field
is set to `notWritable', and the value of its error-index field is
set to the index of the failed variable binding.
(10) Otherwise, if the variable binding's value field specifies a value
that could under other circumstances be held by the variable, but
is presently inconsistent or otherwise unable to be assigned to the
variable, then the value of the Response-PDU's error-status field
is set to `inconsistentValue', and the value of its error-index
field is set to the index of the failed variable binding.
(11) When, during the above steps, the assignment of the value specified
by the variable binding's value field to the specified variable
requires the allocation of a resource which is presently
unavailable, then the value of the Response-PDU's error-status
field is set to `resourceUnavailable', and the value of its error-
index field is set to the index of the failed variable binding.
(12) If the processing of the variable binding fails for a reason other
than listed above, then the value of the Response-PDU's error-
status field is set to `genErr', and the value of its error-index
field is set to the index of the failed variable binding.
(13) Otherwise, the validation of the variable binding succeeds.
At the end of the first phase, if the validation of all variable
bindings succeeded, then the value of the Response-PDU's error-status
field is set to `noError' and the value of its error-index field is
zero, and processing continues as follows.
For each variable binding in the request, the named variable is
created if necessary, and the specified value is assigned to it.
Each of these variable assignments occurs as if simultaneously with
SNMPv2 Working Group Standards Track [Page 20]
RFC 1905 Protocol Operations for SNMPv2 January 1996
respect to all other assignments specified in the same request.
However, if the same variable is named more than once in a single
request, with different associated values, then the actual assignment
made to that variable is implementation-specific.
If any of these assignments fail (even after all the previous
validations), then all other assignments are undone, and the
Response-PDU is modified to have the value of its error-status field
set to `commitFailed', and the value of its error-index field set to
the index of the failed variable binding.
If and only if it is not possible to undo all the assignments, then
the Response-PDU is modified to have the value of its error-status
field set to `undoFailed', and the value of its error-index field is
set to zero. Note that implementations are strongly encouraged to
take all possible measures to avoid use of either `commitFailed' or
`undoFailed' - these two error-status codes are not to be taken as
license to take the easy way out in an implementation.
Finally, the generated Response-PDU is encapsulated into a message,
and transmitted to the originator of the SetRequest-PDU.
4.2.6. The SNMPv2-Trap-PDU
A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity
acting in an agent role when an exceptional situation occurs.
The destination(s) to which a SNMPv2-Trap-PDU is sent is determined
in an implementation-dependent fashion by the SNMPv2 entity. The
first two variable bindings in the variable binding list of an
SNMPv2-Trap-PDU are sysUpTime.0 [9] and snmpTrapOID.0 [9]
respectively. If the OBJECTS clause is present in the invocation of
the corresponding NOTIFICATION-TYPE macro, then each corresponding
variable, as instantiated by this notification, is copied, in order,
to the variable-bindings field. If any additional variables are
being included (at the option of the generating SNMPv2 entity), then
each is copied to the variable-bindings field.
4.2.7. The InformRequest-PDU
An InformRequest-PDU is generated and transmitted at the request of
an application in a SNMPv2 entity acting in a manager role, that
wishes to notify another application (in a SNMPv2 entity also acting
in a manager role) of information in a MIB view which is remote to
the receiving application.
The destination(s) to which an InformRequest-PDU is sent is specified
by the requesting application. The first two variable bindings in
SNMPv2 Working Group Standards Track [Page 21]
RFC 1905 Protocol Operations for SNMPv2 January 1996
the variable binding list of an InformRequest-PDU are sysUpTime.0 [9]
and snmpTrapOID.0 [9] respectively. If the OBJECTS clause is present
in the invocation of the corresponding NOTIFICATION-TYPE macro, then
each corresponding variable, as instantiated by this notification, is
copied, in order, to the variable-bindings field.
Upon receipt of an InformRequest-PDU, the receiving SNMPv2 entity
determines the size of a message encapsulating a Response-PDU with
the same values in its request-id, error-status, error-index and
variable-bindings fields as the received InformRequest-PDU. If the
determined message size is greater than either a local constraint or
the maximum message size of the originator, then an alternate
Response-PDU is generated, transmitted to the originator of the
InformRequest-PDU, and processing of the InformRequest-PDU terminates
immediately thereafter. This alternate Response-PDU is formatted
with the same values in its request-id field as the received
InformRequest-PDU, with the value of its error-status field set to
`tooBig', the value of its error-index field set to zero, and an
empty variable-bindings field. This alternate Response-PDU is then
encapsulated into a message. If the size of the resultant message is
less than or equal to both a local constraint and the maximum message
size of the originator, it is transmitted to the originator of the
InformRequest-PDU. Otherwise, the snmpSilentDrops [9] counter is
incremented and the resultant message is discarded. Regardless,
processing of the InformRequest-PDU terminates.
Otherwise, the receiving SNMPv2 entity:
(1) presents its contents to the appropriate SNMPv2 application;
(2) generates a Response-PDU with the same values in its request-id and
variable-bindings fields as the received InformRequest-PDU, with
the value of its error-status field is set to `noError' and the
value of its error-index field is zero; and
(3) transmits the generated Response-PDU to the originator of the
InformRequest-PDU.
5. Security Considerations
Security issues are not discussed in this memo.
SNMPv2 Working Group Standards Track [Page 22]
RFC 1905 Protocol Operations for SNMPv2 January 1996
6. Editor's Address
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
US
Phone: +1 408 526 5260
EMail: kzm@cisco.com
7. Acknowledgements
This document is the result of significant work by the four major
contributors:
Jeffrey D. Case (SNMP Research, case@snmp.com)
Keith McCloghrie (Cisco Systems, kzm@cisco.com)
Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
Steven Waldbusser (International Network Services, stevew@uni.ins.com)
In addition, the contributions of the SNMPv2 Working Group are
acknowledged. In particular, a special thanks is extended for the
contributions of:
Alexander I. Alten (Novell)
Dave Arneson (Cabletron)
Uri Blumenthal (IBM)
Doug Book (Chipcom)
Kim Curran (Bell-Northern Research)
Jim Galvin (Trusted Information Systems)
Maria Greene (Ascom Timeplex)
Iain Hanson (Digital)
Dave Harrington (Cabletron)
Nguyen Hien (IBM)
Jeff Johnson (Cisco Systems)
Michael Kornegay (Object Quest)
Deirdre Kostick (AT&T Bell Labs)
David Levi (SNMP Research)
Daniel Mahoney (Cabletron)
Bob Natale (ACE*COMM)
Brian O'Keefe (Hewlett Packard)
Andrew Pearson (SNMP Research)
Dave Perkins (Peer Networks)
Randy Presuhn (Peer Networks)
Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue)
Jon Saperia (BGS Systems)
SNMPv2 Working Group Standards Track [Page 23]
RFC 1905 Protocol Operations for SNMPv2 January 1996
Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
Kaj Tesink (Bellcore)
Glenn Waters (Bell-Northern Research)
Bert Wijnen (IBM)
8. References
[1] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[4] Kent, C., and J. Mogul, Fragmentation Considered Harmful,
Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).
[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[6] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[7] McCloghrie, K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets:
MIB-II", STD 17, RFC 1213, March 1991.
[8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Coexistence between Version 1 and Version 2
of the Internet-standard Network Management Framework", RFC 1908,
January 1996.
[9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1907,
January 1996.
SNMPv2 Working Group Standards Track [Page 24]