7 Network Working Group SNMPv2 Working Group
8 Request for Comments: 1905 J. Case
9 Obsoletes: 1448 SNMP Research, Inc.
10 Category: Standards Track K. McCloghrie
13 Dover Beach Consulting, Inc.
15 International Network Services
21 Simple Network Management Protocol (SNMPv2)
25 This document specifies an Internet standards track protocol for the
26 Internet community, and requests discussion and suggestions for
27 improvements. Please refer to the current edition of the "Internet
28 Official Protocol Standards" (STD 1) for the standardization state
29 and status of this protocol. Distribution of this memo is unlimited.
33 A management system contains: several (potentially many) nodes, each
34 with a processing entity, termed an agent, which has access to
35 management instrumentation; at least one management station; and, a
36 management protocol, used to convey management information between
37 the agents and management stations. Operations of the protocol are
38 carried out under an administrative framework which defines
39 authentication, authorization, access control, and privacy policies.
41 Management stations execute management applications which monitor and
42 control managed elements. Managed elements are devices such as
43 hosts, routers, terminal servers, etc., which are monitored and
44 controlled via access to their management information.
46 Management information is viewed as a collection of managed objects,
47 residing in a virtual information store, termed the Management
48 Information Base (MIB). Collections of related objects are defined
49 in MIB modules. These modules are written using a subset of OSI's
50 Abstract Syntax Notation One (ASN.1) [1], termed the Structure of
51 Management Information (SMI) [2].
58 SNMPv2 Working Group Standards Track [Page 1]
60 RFC 1905 Protocol Operations for SNMPv2 January 1996
63 The management protocol, version 2 of the Simple Network Management
64 Protocol, provides for the exchange of messages which convey
65 management information between the agents and the management
66 stations. The form of these messages is a message "wrapper" which
67 encapsulates a Protocol Data Unit (PDU). The form and meaning of the
68 "wrapper" is determined by an administrative framework which defines
69 both authentication and authorization policies.
71 It is the purpose of this document, Protocol Operations for SNMPv2,
72 to define the operations of the protocol with respect to the sending
73 and receiving of the PDUs.
75 1.1. A Note on Terminology
77 For the purpose of exposition, the original Internet-standard Network
78 Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD
79 15), and 1212 (STD 16), is termed the SNMP version 1 framework
80 (SNMPv1). The current framework is termed the SNMP version 2
85 2.1. Roles of Protocol Entities
87 A SNMPv2 entity may operate in a manager role or an agent role.
89 A SNMPv2 entity acts in an agent role when it performs SNMPv2
90 management operations in response to received SNMPv2 protocol
91 messages (other than an inform notification) or when it sends trap
94 A SNMPv2 entity acts in a manager role when it initiates SNMPv2
95 management operations by the generation of SNMPv2 protocol messages
96 or when it performs SNMPv2 management operations in response to
97 received trap or inform notifications.
99 A SNMPv2 entity may support either or both roles, as dictated by its
100 implementation and configuration. Further, a SNMPv2 entity can also
101 act in the role of a proxy agent, in which it appears to be acting in
102 an agent role, but satisfies management requests by acting in a
103 manager role with a remote entity.
105 2.2. Management Information
107 The term, variable, refers to an instance of a non-aggregate object
108 type defined according to the conventions set forth in the SMI [2] or
109 the textual conventions based on the SMI [3]. The term, variable
110 binding, normally refers to the pairing of the name of a variable and
114 SNMPv2 Working Group Standards Track [Page 2]
116 RFC 1905 Protocol Operations for SNMPv2 January 1996
119 its associated value. However, if certain kinds of exceptional
120 conditions occur during processing of a retrieval request, a variable
121 binding will pair a name and an indication of that exception.
123 A variable-binding list is a simple list of variable bindings.
125 The name of a variable is an OBJECT IDENTIFIER which is the
126 concatenation of the OBJECT IDENTIFIER of the corresponding object-
127 type together with an OBJECT IDENTIFIER fragment identifying the
128 instance. The OBJECT IDENTIFIER of the corresponding object-type is
129 called the OBJECT IDENTIFIER prefix of the variable.
131 2.3. Access to Management Information
133 Three types of access to management information are provided by the
134 protocol. One type is a request-response interaction, in which a
135 SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2
136 entity, acting in an agent role, and the latter SNMPv2 entity then
137 responds to the request. This type is used to retrieve or modify
138 management information associated with the managed device.
140 A second type is also a request-response interaction, in which a
141 SNMPv2 entity, acting in a manager role, sends a request to a SNMPv2
142 entity, also acting in a manager role, and the latter SNMPv2 entity
143 then responds to the request. This type is used to notify a SNMPv2
144 entity, acting in a manager role, of management information
145 associated with another SNMPv2 entity, also acting in a manager role.
147 The third type of access is an unconfirmed interaction, in which a
148 SNMPv2 entity, acting in an agent role, sends a unsolicited message,
149 termed a trap, to a SNMPv2 entity, acting in a manager role, and no
150 response is returned. This type is used to notify a SNMPv2 entity,
151 acting in a manager role, of an exceptional situation, which has
152 resulted in changes to management information associated with the
155 2.4. Retransmission of Requests
157 For all types of request in this protocol, the receiver is required
158 under normal circumstances, to generate and transmit a response to
159 the originator of the request. Whether or not a request should be
160 retransmitted if no corresponding response is received in an
161 appropriate time interval, is at the discretion of the application
162 originating the request. This will normally depend on the urgency of
163 the request. However, such an application needs to act responsibly
164 in respect to the frequency and duration of re-transmissions.
170 SNMPv2 Working Group Standards Track [Page 3]
172 RFC 1905 Protocol Operations for SNMPv2 January 1996
177 The maximum size of a SNMPv2 message is limited to the minimum of:
179 (1) the maximum message size which the destination SNMPv2 entity can
182 (2) the maximum message size which the source SNMPv2 entity can
185 The former may be known on a per-recipient basis; and in the absence
186 of such knowledge, is indicated by transport domain used when sending
187 the message. The latter is imposed by implementation-specific local
190 Each transport mapping for the SNMPv2 indicates the minimum message
191 size which a SNMPv2 implementation must be able to produce or
192 consume. Although implementations are encouraged to support larger
193 values whenever possible, a conformant implementation must never
194 generate messages larger than allowed by the receiving SNMPv2 entity.
196 One of the aims of the GetBulkRequest-PDU, specified in this
197 protocol, is to minimize the number of protocol exchanges required to
198 retrieve a large amount of management information. As such, this PDU
199 type allows a SNMPv2 entity acting in a manager role to request that
200 the response be as large as possible given the constraints on message
201 sizes. These constraints include the limits on the size of messages
202 which the SNMPv2 entity acting in an agent role can generate, and the
203 SNMPv2 entity acting in a manager role can receive.
205 However, it is possible that such maximum sized messages may be
206 larger than the Path MTU of the path across the network traversed by
207 the messages. In this situation, such messages are subject to
208 fragmentation. Fragmentation is generally considered to be harmful
209 [4], since among other problems, it leads to a decrease in the
210 reliability of the transfer of the messages. Thus, a SNMPv2 entity
211 which sends a GetBulkRequest-PDU must take care to set its parameters
212 accordingly, so as to reduce the risk of fragmentation. In
213 particular, under conditions of network stress, only small values
214 should be used for max-repetitions.
216 2.6. Transport Mappings
218 It is important to note that the exchange of SNMPv2 messages requires
219 only an unreliable datagram service, with every message being
220 entirely and independently contained in a single transport datagram.
221 Specific transport mappings and encoding rules are specified
222 elsewhere [5]. However, the preferred mapping is the use of the User
226 SNMPv2 Working Group Standards Track [Page 4]
228 RFC 1905 Protocol Operations for SNMPv2 January 1996
231 Datagram Protocol [6].
235 SNMPv2-PDU DEFINITIONS ::= BEGIN
238 ObjectName, ObjectSyntax, Integer32
242 -- protocol data units
278 GetNextRequest-PDU ::=
282 SNMPv2 Working Group Standards Track [Page 5]
284 RFC 1905 Protocol Operations for SNMPv2 January 1996
300 GetBulkRequest-PDU ::=
304 InformRequest-PDU ::=
312 -- Usage and precise semantics of Report-PDU are not presently
313 -- defined. Any SNMP administrative framework making use of
314 -- this PDU must define its usage and semantics.
320 INTEGER ::= 2147483647
327 error-status -- sometimes ignored
331 noSuchName(2), -- for proxy compatibility
332 badValue(3), -- for proxy compatibility
333 readOnly(4), -- for proxy compatibility
338 SNMPv2 Working Group Standards Track [Page 6]
340 RFC 1905 Protocol Operations for SNMPv2 January 1996
349 inconsistentValue(12),
350 resourceUnavailable(13),
353 authorizationError(16),
358 error-index -- sometimes ignored
359 INTEGER (0..max-bindings),
361 variable-bindings -- values are sometimes ignored
366 BulkPDU ::= -- MUST be identical in
367 SEQUENCE { -- structure to PDU
372 INTEGER (0..max-bindings),
375 INTEGER (0..max-bindings),
377 variable-bindings -- values are ignored
394 SNMPv2 Working Group Standards Track [Page 7]
396 RFC 1905 Protocol Operations for SNMPv2 January 1996
401 unSpecified -- in retrieval requests
404 -- exceptions in responses
417 -- variable-binding list
420 SEQUENCE (SIZE (0..max-bindings)) OF
427 4. Protocol Specification
429 4.1. Common Constructs
431 The value of the request-id field in a Response-PDU takes the value
432 of the request-id field in the request PDU to which it is a response.
433 By use of the request-id value, a SNMPv2 application can distinguish
434 the (potentially multiple) outstanding requests, and thereby
435 correlate incoming responses with outstanding requests. In cases
436 where an unreliable datagram service is used, the request-id also
437 provides a simple means of identifying messages duplicated by the
438 network. Use of the same request-id on a retransmission of a request
439 allows the response to either the original transmission or the
440 retransmission to satisfy the request. However, in order to
441 calculate the round trip time for transmission and processing of a
442 request-response transaction, the SNMPv2 application needs to use a
443 different request-id value on a retransmitted request. The latter
444 strategy is recommended for use in the majority of situations.
450 SNMPv2 Working Group Standards Track [Page 8]
452 RFC 1905 Protocol Operations for SNMPv2 January 1996
455 A non-zero value of the error-status field in a Response-PDU is used
456 to indicate that an exception occurred to prevent the processing of
457 the request. In these cases, a non-zero value of the Response-PDU's
458 error-index field provides additional information by identifying
459 which variable binding in the list caused the exception. A variable
460 binding is identified by its index value. The first variable binding
461 in a variable-binding list is index one, the second is index two,
464 SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128 sub-
465 identifiers, where each sub-identifier has a maximum value of 2**32-
470 It is mandatory that all SNMPv2 entities acting in an agent role be
471 able to generate the following PDU types: Response-PDU and SNMPv2-
472 Trap-PDU; further, all such implementations must be able to receive
473 the following PDU types: GetRequest-PDU, GetNextRequest-PDU,
474 GetBulkRequest-PDU, and SetRequest-PDU.
476 It is mandatory that all SNMPv2 entities acting in a manager role be
477 able to generate the following PDU types: GetRequest-PDU,
478 GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
479 InformRequest-PDU, and Response-PDU; further, all such
480 implementations must be able to receive the following PDU types:
481 Response-PDU, SNMPv2-Trap-PDU,
485 In the elements of procedure below, any field of a PDU which is not
486 referenced by the relevant procedure is ignored by the receiving
487 SNMPv2 entity. However, all components of a PDU, including those
488 whose values are ignored by the receiving SNMPv2 entity, must have
489 valid ASN.1 syntax and encoding. For example, some PDUs (e.g., the
490 GetRequest-PDU) are concerned only with the name of a variable and
491 not its value. In this case, the value portion of the variable
492 binding is ignored by the receiving SNMPv2 entity. The unSpecified
493 value is defined for use as the value portion of such bindings.
495 On generating a management communication, the message "wrapper" to
496 encapsulate the PDU is generated according to the "Elements of
497 Procedure" of the administrative framework in use is followed. While
498 the definition of "max-bindings" does impose an upper-bound on the
499 number of variable bindings, in practice, the size of a message is
500 limited only by constraints on the maximum message size -- it is not
501 limited by the number of variable bindings.
506 SNMPv2 Working Group Standards Track [Page 9]
508 RFC 1905 Protocol Operations for SNMPv2 January 1996
511 On receiving a management communication, the "Elements of Procedure"
512 of the administrative framework in use is followed, and if those
513 procedures indicate that the operation contained within the message
514 is to be performed locally, then those procedures also indicate the
515 MIB view which is visible to the operation.
517 4.2.1. The GetRequest-PDU
519 A GetRequest-PDU is generated and transmitted at the request of a
522 Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity
523 processes each variable binding in the variable-binding list to
524 produce a Response-PDU. All fields of the Response-PDU have the same
525 values as the corresponding fields of the received request except as
526 indicated below. Each variable binding is processed as follows:
528 (1) If the variable binding's name exactly matches the name of a
529 variable accessible by this request, then the variable binding's
530 value field is set to the value of the named variable.
532 (2) Otherwise, if the variable binding's name does not have an OBJECT
533 IDENTIFIER prefix which exactly matches the OBJECT IDENTIFIER
534 prefix of any (potential) variable accessible by this request, then
535 its value field is set to `noSuchObject'.
537 (3) Otherwise, the variable binding's value field is set to
540 If the processing of any variable binding fails for a reason other
541 than listed above, then the Response-PDU is re-formatted with the
542 same values in its request-id and variable-bindings fields as the
543 received GetRequest-PDU, with the value of its error-status field set
544 to `genErr', and the value of its error-index field is set to the
545 index of the failed variable binding.
547 Otherwise, the value of the Response-PDU's error-status field is set
548 to `noError', and the value of its error-index field is zero.
550 The generated Response-PDU is then encapsulated into a message. If
551 the size of the resultant message is less than or equal to both a
552 local constraint and the maximum message size of the originator, it
553 is transmitted to the originator of the GetRequest-PDU.
555 Otherwise, an alternate Response-PDU is generated. This alternate
556 Response-PDU is formatted with the same value in its request-id field
557 as the received GetRequest-PDU, with the value of its error-status
558 field set to `tooBig', the value of its error-index field set to
562 SNMPv2 Working Group Standards Track [Page 10]
564 RFC 1905 Protocol Operations for SNMPv2 January 1996
567 zero, and an empty variable-bindings field. This alternate
568 Response-PDU is then encapsulated into a message. If the size of the
569 resultant message is less than or equal to both a local constraint
570 and the maximum message size of the originator, it is transmitted to
571 the originator of the GetRequest-PDU. Otherwise, the snmpSilentDrops
572 [9] counter is incremented and the resultant message is discarded.
574 4.2.2. The GetNextRequest-PDU
576 A GetNextRequest-PDU is generated and transmitted at the request of a
579 Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2 entity
580 processes each variable binding in the variable-binding list to
581 produce a Response-PDU. All fields of the Response-PDU have the same
582 values as the corresponding fields of the received request except as
583 indicated below. Each variable binding is processed as follows:
585 (1) The variable is located which is in the lexicographically ordered
586 list of the names of all variables which are accessible by this
587 request and whose name is the first lexicographic successor of the
588 variable binding's name in the incoming GetNextRequest-PDU. The
589 corresponding variable binding's name and value fields in the
590 Response-PDU are set to the name and value of the located variable.
592 (2) If the requested variable binding's name does not lexicographically
593 precede the name of any variable accessible by this request, i.e.,
594 there is no lexicographic successor, then the corresponding
595 variable binding produced in the Response-PDU has its value field
596 set to `endOfMibView', and its name field set to the variable
597 binding's name in the request.
599 If the processing of any variable binding fails for a reason other
600 than listed above, then the Response-PDU is re-formatted with the
601 same values in its request-id and variable-bindings fields as the
602 received GetNextRequest-PDU, with the value of its error-status field
603 set to `genErr', and the value of its error-index field is set to the
604 index of the failed variable binding.
606 Otherwise, the value of the Response-PDU's error-status field is set
607 to `noError', and the value of its error-index field is zero.
609 The generated Response-PDU is then encapsulated into a message. If
610 the size of the resultant message is less than or equal to both a
611 local constraint and the maximum message size of the originator, it
612 is transmitted to the originator of the GetNextRequest-PDU.
618 SNMPv2 Working Group Standards Track [Page 11]
620 RFC 1905 Protocol Operations for SNMPv2 January 1996
623 Otherwise, an alternate Response-PDU is generated. This alternate
624 Response-PDU is formatted with the same values in its request-id
625 field as the received GetNextRequest-PDU, with the value of its
626 error-status field set to `tooBig', the value of its error-index
627 field set to zero, and an empty variable-bindings field. This
628 alternate Response-PDU is then encapsulated into a message. If the
629 size of the resultant message is less than or equal to both a local
630 constraint and the maximum message size of the originator, it is
631 transmitted to the originator of the GetNextRequest-PDU. Otherwise,
632 the snmpSilentDrops [9] counter is incremented and the resultant
633 message is discarded.
635 4.2.2.1. Example of Table Traversal
637 An important use of the GetNextRequest-PDU is the traversal of
638 conceptual tables of information within a MIB. The semantics of this
639 type of request, together with the method of identifying individual
640 instances of objects in the MIB, provides access to related objects
641 in the MIB as if they enjoyed a tabular organization.
643 In the protocol exchange sketched below, a SNMPv2 application
644 retrieves the media-dependent physical address and the address-
645 mapping type for each entry in the IP net-to-media Address
646 Translation Table [7] of a particular network element. It also
647 retrieves the value of sysUpTime [9], at which the mappings existed.
648 Suppose that the agent's IP net-to-media table has three entries:
650 Interface-Number Network-Address Physical-Address Type
652 1 10.0.0.51 00:00:10:01:23:45 static
653 1 9.2.3.4 00:00:10:54:32:10 dynamic
654 2 10.0.0.15 00:00:10:98:76:54 dynamic
656 The SNMPv2 entity acting in a manager role begins by sending a
657 GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values
658 as the requested variable names:
660 GetNextRequest ( sysUpTime,
661 ipNetToMediaPhysAddress,
664 The SNMPv2 entity acting in an agent role responds with a Response-
667 Response (( sysUpTime.0 = "123456" ),
668 ( ipNetToMediaPhysAddress.1.9.2.3.4 =
670 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ))
674 SNMPv2 Working Group Standards Track [Page 12]
676 RFC 1905 Protocol Operations for SNMPv2 January 1996
679 The SNMPv2 entity acting in a manager role continues with:
681 GetNextRequest ( sysUpTime,
682 ipNetToMediaPhysAddress.1.9.2.3.4,
683 ipNetToMediaType.1.9.2.3.4 )
685 The SNMPv2 entity acting in an agent role responds with:
687 Response (( sysUpTime.0 = "123461" ),
688 ( ipNetToMediaPhysAddress.1.10.0.0.51 =
690 ( ipNetToMediaType.1.10.0.0.51 = "static" ))
692 The SNMPv2 entity acting in a manager role continues with:
694 GetNextRequest ( sysUpTime,
695 ipNetToMediaPhysAddress.1.10.0.0.51,
696 ipNetToMediaType.1.10.0.0.51 )
698 The SNMPv2 entity acting in an agent role responds with:
700 Response (( sysUpTime.0 = "123466" ),
701 ( ipNetToMediaPhysAddress.2.10.0.0.15 =
703 ( ipNetToMediaType.2.10.0.0.15 = "dynamic" ))
705 The SNMPv2 entity acting in a manager role continues with:
707 GetNextRequest ( sysUpTime,
708 ipNetToMediaPhysAddress.2.10.0.0.15,
709 ipNetToMediaType.2.10.0.0.15 )
711 As there are no further entries in the table, the SNMPv2 entity
712 acting in an agent role responds with the variables that are next in
713 the lexicographical ordering of the accessible object names, for
716 Response (( sysUpTime.0 = "123471" ),
717 ( ipNetToMediaNetAddress.1.9.2.3.4 =
719 ( ipRoutingDiscards.0 = "2" ))
721 This response signals the end of the table to the SNMPv2 entity
722 acting in a manager role.
730 SNMPv2 Working Group Standards Track [Page 13]
732 RFC 1905 Protocol Operations for SNMPv2 January 1996
735 4.2.3. The GetBulkRequest-PDU
737 A GetBulkRequest-PDU is generated and transmitted at the request of a
738 SNMPv2 application. The purpose of the GetBulkRequest-PDU is to
739 request the transfer of a potentially large amount of data,
740 including, but not limited to, the efficient and rapid retrieval of
743 Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2 entity
744 processes each variable binding in the variable-binding list to
745 produce a Response-PDU with its request-id field having the same
746 value as in the request. Processing begins by examining the values
747 in the non-repeaters and max-repetitions fields. If the value in the
748 non-repeaters field is less than zero, then the value of the field is
749 set to zero. Similarly, if the value in the max-repetitions field is
750 less than zero, then the value of the field is set to zero.
752 For the GetBulkRequest-PDU type, the successful processing of each
753 variable binding in the request generates zero or more variable
754 bindings in the Response-PDU. That is, the one-to-one mapping
755 between the variable bindings of the GetRequest-PDU, GetNextRequest-
756 PDU, and SetRequest-PDU types and the resultant Response-PDUs does
757 not apply for the mapping between the variable bindings of a
758 GetBulkRequest-PDU and the resultant Response-PDU.
760 The values of the non-repeaters and max-repetitions fields in the
761 request specify the processing requested. One variable binding in
762 the Response-PDU is requested for the first N variable bindings in
763 the request and M variable bindings are requested for each of the R
764 remaining variable bindings in the request. Consequently, the total
765 number of requested variable bindings communicated by the request is
766 given by N + (M * R), where N is the minimum of: a) the value of the
767 non-repeaters field in the request, and b) the number of variable
768 bindings in the request; M is the value of the max-repetitions field
769 in the request; and R is the maximum of: a) number of variable
770 bindings in the request - N, and b) zero.
772 The receiving SNMPv2 entity produces a Response-PDU with up to the
773 total number of requested variable bindings communicated by the
774 request. The request-id shall have the same value as the received
777 If N is greater than zero, the first through the (N)-th variable
778 bindings of the Response-PDU are each produced as follows:
780 (1) The variable is located which is in the lexicographically ordered
781 list of the names of all variables which are accessible by this
782 request and whose name is the first lexicographic successor of the
786 SNMPv2 Working Group Standards Track [Page 14]
788 RFC 1905 Protocol Operations for SNMPv2 January 1996
791 variable binding's name in the incoming GetBulkRequest-PDU. The
792 corresponding variable binding's name and value fields in the
793 Response-PDU are set to the name and value of the located variable.
795 (2) If the requested variable binding's name does not lexicographically
796 precede the name of any variable accessible by this request, i.e.,
797 there is no lexicographic successor, then the corresponding
798 variable binding produced in the Response-PDU has its value field
799 set to `endOfMibView', and its name field set to the variable
800 binding's name in the request.
802 If M and R are non-zero, the (N + 1)-th and subsequent variable
803 bindings of the Response-PDU are each produced in a similar manner.
804 For each iteration i, such that i is greater than zero and less than
805 or equal to M, and for each repeated variable, r, such that r is
806 greater than zero and less than or equal to R, the (N + ( (i-1) * R )
807 + r)-th variable binding of the Response-PDU is produced as follows:
809 (1) The variable which is in the lexicographically ordered list of the
810 names of all variables which are accessible by this request and
811 whose name is the (i)-th lexicographic successor of the (N + r)-th
812 variable binding's name in the incoming GetBulkRequest-PDU is
813 located and the variable binding's name and value fields are set to
814 the name and value of the located variable.
816 (2) If there is no (i)-th lexicographic successor, then the
817 corresponding variable binding produced in the Response-PDU has its
818 value field set to `endOfMibView', and its name field set to either
819 the last lexicographic successor, or if there are no lexicographic
820 successors, to the (N + r)-th variable binding's name in the
823 While the maximum number of variable bindings in the Response-PDU is
824 bounded by N + (M * R), the response may be generated with a lesser
825 number of variable bindings (possibly zero) for either of three
828 (1) If the size of the message encapsulating the Response-PDU
829 containing the requested number of variable bindings would be
830 greater than either a local constraint or the maximum message size
831 of the originator, then the response is generated with a lesser
832 number of variable bindings. This lesser number is the ordered set
833 of variable bindings with some of the variable bindings at the end
834 of the set removed, such that the size of the message encapsulating
835 the Response-PDU is approximately equal to but no greater than
836 either a local constraint or the maximum message size of the
837 originator. Note that the number of variable bindings removed has
838 no relationship to the values of N, M, or R.
842 SNMPv2 Working Group Standards Track [Page 15]
844 RFC 1905 Protocol Operations for SNMPv2 January 1996
847 (2) The response may also be generated with a lesser number of variable
848 bindings if for some value of iteration i, such that i is greater
849 than zero and less than or equal to M, that all of the generated
850 variable bindings have the value field set to the `endOfMibView'.
851 In this case, the variable bindings may be truncated after the (N +
852 (i * R))-th variable binding.
854 (3) In the event that the processing of a request with many repetitions
855 requires a significantly greater amount of processing time than a
856 normal request, then an agent may terminate the request with less
857 than the full number of repetitions, providing at least one
858 repetition is completed.
860 If the processing of any variable binding fails for a reason other
861 than listed above, then the Response-PDU is re-formatted with the
862 same values in its request-id and variable-bindings fields as the
863 received GetBulkRequest-PDU, with the value of its error-status field
864 set to `genErr', and the value of its error-index field is set to the
865 index of the variable binding in the original request which
866 corresponds to the failed variable binding.
868 Otherwise, the value of the Response-PDU's error-status field is set
869 to `noError', and the value of its error-index field to zero.
871 The generated Response-PDU (possibly with an empty variable-bindings
872 field) is then encapsulated into a message. If the size of the
873 resultant message is less than or equal to both a local constraint
874 and the maximum message size of the originator, it is transmitted to
875 the originator of the GetBulkRequest-PDU. Otherwise, the
876 snmpSilentDrops [9] counter is incremented and the resultant message
879 4.2.3.1. Another Example of Table Traversal
881 This example demonstrates how the GetBulkRequest-PDU can be used as
882 an alternative to the GetNextRequest-PDU. The same traversal of the
883 IP net-to-media table as shown in Section 4.2.2.1 is achieved with
886 The SNMPv2 entity acting in a manager role begins by sending a
887 GetBulkRequest-PDU with the modest max-repetitions value of 2, and
888 containing the indicated OBJECT IDENTIFIER values as the requested
891 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
893 ipNetToMediaPhysAddress,
898 SNMPv2 Working Group Standards Track [Page 16]
900 RFC 1905 Protocol Operations for SNMPv2 January 1996
903 The SNMPv2 entity acting in an agent role responds with a Response-PDU:
905 Response (( sysUpTime.0 = "123456" ),
906 ( ipNetToMediaPhysAddress.1.9.2.3.4 =
908 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ),
909 ( ipNetToMediaPhysAddress.1.10.0.0.51 =
911 ( ipNetToMediaType.1.10.0.0.51 = "static" ))
913 The SNMPv2 entity acting in a manager role continues with:
915 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
917 ipNetToMediaPhysAddress.1.10.0.0.51,
918 ipNetToMediaType.1.10.0.0.51 )
920 The SNMPv2 entity acting in an agent role responds with:
922 Response (( sysUpTime.0 = "123466" ),
923 ( ipNetToMediaPhysAddress.2.10.0.0.15 =
925 ( ipNetToMediaType.2.10.0.0.15 =
927 ( ipNetToMediaNetAddress.1.9.2.3.4 =
929 ( ipRoutingDiscards.0 = "2" ))
931 This response signals the end of the table to the SNMPv2 entity
932 acting in a manager role.
934 4.2.4. The Response-PDU
936 The Response-PDU is generated by a SNMPv2 entity only upon receipt of
937 a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU,
938 SetRequest-PDU, or InformRequest-PDU, as described elsewhere in this
941 If the error-status field of the Response-PDU is non-zero, the value
942 fields of the variable bindings in the variable binding list are
945 If both the error-status field and the error-index field of the
946 Response-PDU are non-zero, then the value of the error-index field is
947 the index of the variable binding (in the variable-binding list of
948 the corresponding request) for which the request failed. The first
949 variable binding in a request's variable-binding list is index one,
950 the second is index two, etc.
954 SNMPv2 Working Group Standards Track [Page 17]
956 RFC 1905 Protocol Operations for SNMPv2 January 1996
959 A compliant SNMPv2 entity acting in a manager role must be able to
960 properly receive and handle a Response-PDU with an error-status field
961 equal to `noSuchName', `badValue', or `readOnly'. (See Section 3.1.2
964 Upon receipt of a Response-PDU, the receiving SNMPv2 entity presents
965 its contents to the SNMPv2 application which generated the request
966 with the same request-id value.
968 4.2.5. The SetRequest-PDU
970 A SetRequest-PDU is generated and transmitted at the request of a
973 Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity
974 determines the size of a message encapsulating a Response-PDU having
975 the same values in its request-id and variable-bindings fields as the
976 received SetRequest-PDU, and the largest possible sizes of the
977 error-status and error-index fields. If the determined message size
978 is greater than either a local constraint or the maximum message size
979 of the originator, then an alternate Response-PDU is generated,
980 transmitted to the originator of the SetRequest-PDU, and processing
981 of the SetRequest-PDU terminates immediately thereafter. This
982 alternate Response-PDU is formatted with the same values in its
983 request-id field as the received SetRequest-PDU, with the value of
984 its error-status field set to `tooBig', the value of its error-index
985 field set to zero, and an empty variable-bindings field. This
986 alternate Response-PDU is then encapsulated into a message. If the
987 size of the resultant message is less than or equal to both a local
988 constraint and the maximum message size of the originator, it is
989 transmitted to the originator of the SetRequest-PDU. Otherwise, the
990 snmpSilentDrops [9] counter is incremented and the resultant message
991 is discarded. Regardless, processing of the SetRequest-PDU
994 Otherwise, the receiving SNMPv2 entity processes each variable
995 binding in the variable-binding list to produce a Response-PDU. All
996 fields of the Response-PDU have the same values as the corresponding
997 fields of the received request except as indicated below.
999 The variable bindings are conceptually processed as a two phase
1000 operation. In the first phase, each variable binding is validated;
1001 if all validations are successful, then each variable is altered in
1002 the second phase. Of course, implementors are at liberty to
1003 implement either the first, or second, or both, of these conceptual
1004 phases as multiple implementation phases. Indeed, such multiple
1005 implementation phases may be necessary in some cases to ensure
1010 SNMPv2 Working Group Standards Track [Page 18]
1012 RFC 1905 Protocol Operations for SNMPv2 January 1996
1015 The following validations are performed in the first phase on each
1016 variable binding until they are all successful, or until one fails:
1018 (1) If the variable binding's name specifies an existing or non-
1019 existent variable to which this request is/would be denied access
1020 because it is/would not be in the appropriate MIB view, then the
1021 value of the Response-PDU's error-status field is set to
1022 `noAccess', and the value of its error-index field is set to the
1023 index of the failed variable binding.
1025 (2) Otherwise, if there are no variables which share the same OBJECT
1026 IDENTIFIER prefix as the variable binding's name, and which are
1027 able to be created or modified no matter what new value is
1028 specified, then the value of the Response-PDU's error-status field
1029 is set to `notWritable', and the value of its error-index field is
1030 set to the index of the failed variable binding.
1032 (3) Otherwise, if the variable binding's value field specifies,
1033 according to the ASN.1 language, a type which is inconsistent with
1034 that required for all variables which share the same OBJECT
1035 IDENTIFIER prefix as the variable binding's name, then the value of
1036 the Response-PDU's error-status field is set to `wrongType', and
1037 the value of its error-index field is set to the index of the
1038 failed variable binding.
1040 (4) Otherwise, if the variable binding's value field specifies,
1041 according to the ASN.1 language, a length which is inconsistent
1042 with that required for all variables which share the same OBJECT
1043 IDENTIFIER prefix as the variable binding's name, then the value of
1044 the Response-PDU's error-status field is set to `wrongLength', and
1045 the value of its error-index field is set to the index of the
1046 failed variable binding.
1048 (5) Otherwise, if the variable binding's value field contains an ASN.1
1049 encoding which is inconsistent with that field's ASN.1 tag, then
1050 the value of the Response-PDU's error-status field is set to
1051 `wrongEncoding', and the value of its error-index field is set to
1052 the index of the failed variable binding. (Note that not all
1053 implementation strategies will generate this error.)
1055 (6) Otherwise, if the variable binding's value field specifies a value
1056 which could under no circumstances be assigned to the variable,
1057 then the value of the Response-PDU's error-status field is set to
1058 `wrongValue', and the value of its error-index field is set to the
1059 index of the failed variable binding.
1061 (7) Otherwise, if the variable binding's name specifies a variable
1062 which does not exist and could not ever be created (even though
1066 SNMPv2 Working Group Standards Track [Page 19]
1068 RFC 1905 Protocol Operations for SNMPv2 January 1996
1071 some variables sharing the same OBJECT IDENTIFIER prefix might
1072 under some circumstances be able to be created), then the value of
1073 the Response-PDU's error-status field is set to `noCreation', and
1074 the value of its error-index field is set to the index of the
1075 failed variable binding.
1077 (8) Otherwise, if the variable binding's name specifies a variable
1078 which does not exist but can not be created under the present
1079 circumstances (even though it could be created under other
1080 circumstances), then the value of the Response-PDU's error-status
1081 field is set to `inconsistentName', and the value of its error-
1082 index field is set to the index of the failed variable binding.
1084 (9) Otherwise, if the variable binding's name specifies a variable
1085 which exists but can not be modified no matter what new value is
1086 specified, then the value of the Response-PDU's error-status field
1087 is set to `notWritable', and the value of its error-index field is
1088 set to the index of the failed variable binding.
1090 (10) Otherwise, if the variable binding's value field specifies a value
1091 that could under other circumstances be held by the variable, but
1092 is presently inconsistent or otherwise unable to be assigned to the
1093 variable, then the value of the Response-PDU's error-status field
1094 is set to `inconsistentValue', and the value of its error-index
1095 field is set to the index of the failed variable binding.
1097 (11) When, during the above steps, the assignment of the value specified
1098 by the variable binding's value field to the specified variable
1099 requires the allocation of a resource which is presently
1100 unavailable, then the value of the Response-PDU's error-status
1101 field is set to `resourceUnavailable', and the value of its error-
1102 index field is set to the index of the failed variable binding.
1104 (12) If the processing of the variable binding fails for a reason other
1105 than listed above, then the value of the Response-PDU's error-
1106 status field is set to `genErr', and the value of its error-index
1107 field is set to the index of the failed variable binding.
1109 (13) Otherwise, the validation of the variable binding succeeds.
1111 At the end of the first phase, if the validation of all variable
1112 bindings succeeded, then the value of the Response-PDU's error-status
1113 field is set to `noError' and the value of its error-index field is
1114 zero, and processing continues as follows.
1116 For each variable binding in the request, the named variable is
1117 created if necessary, and the specified value is assigned to it.
1118 Each of these variable assignments occurs as if simultaneously with
1122 SNMPv2 Working Group Standards Track [Page 20]
1124 RFC 1905 Protocol Operations for SNMPv2 January 1996
1127 respect to all other assignments specified in the same request.
1128 However, if the same variable is named more than once in a single
1129 request, with different associated values, then the actual assignment
1130 made to that variable is implementation-specific.
1132 If any of these assignments fail (even after all the previous
1133 validations), then all other assignments are undone, and the
1134 Response-PDU is modified to have the value of its error-status field
1135 set to `commitFailed', and the value of its error-index field set to
1136 the index of the failed variable binding.
1138 If and only if it is not possible to undo all the assignments, then
1139 the Response-PDU is modified to have the value of its error-status
1140 field set to `undoFailed', and the value of its error-index field is
1141 set to zero. Note that implementations are strongly encouraged to
1142 take all possible measures to avoid use of either `commitFailed' or
1143 `undoFailed' - these two error-status codes are not to be taken as
1144 license to take the easy way out in an implementation.
1146 Finally, the generated Response-PDU is encapsulated into a message,
1147 and transmitted to the originator of the SetRequest-PDU.
1149 4.2.6. The SNMPv2-Trap-PDU
1151 A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity
1152 acting in an agent role when an exceptional situation occurs.
1154 The destination(s) to which a SNMPv2-Trap-PDU is sent is determined
1155 in an implementation-dependent fashion by the SNMPv2 entity. The
1156 first two variable bindings in the variable binding list of an
1157 SNMPv2-Trap-PDU are sysUpTime.0 [9] and snmpTrapOID.0 [9]
1158 respectively. If the OBJECTS clause is present in the invocation of
1159 the corresponding NOTIFICATION-TYPE macro, then each corresponding
1160 variable, as instantiated by this notification, is copied, in order,
1161 to the variable-bindings field. If any additional variables are
1162 being included (at the option of the generating SNMPv2 entity), then
1163 each is copied to the variable-bindings field.
1165 4.2.7. The InformRequest-PDU
1167 An InformRequest-PDU is generated and transmitted at the request of
1168 an application in a SNMPv2 entity acting in a manager role, that
1169 wishes to notify another application (in a SNMPv2 entity also acting
1170 in a manager role) of information in a MIB view which is remote to
1171 the receiving application.
1173 The destination(s) to which an InformRequest-PDU is sent is specified
1174 by the requesting application. The first two variable bindings in
1178 SNMPv2 Working Group Standards Track [Page 21]
1180 RFC 1905 Protocol Operations for SNMPv2 January 1996
1183 the variable binding list of an InformRequest-PDU are sysUpTime.0 [9]
1184 and snmpTrapOID.0 [9] respectively. If the OBJECTS clause is present
1185 in the invocation of the corresponding NOTIFICATION-TYPE macro, then
1186 each corresponding variable, as instantiated by this notification, is
1187 copied, in order, to the variable-bindings field.
1189 Upon receipt of an InformRequest-PDU, the receiving SNMPv2 entity
1190 determines the size of a message encapsulating a Response-PDU with
1191 the same values in its request-id, error-status, error-index and
1192 variable-bindings fields as the received InformRequest-PDU. If the
1193 determined message size is greater than either a local constraint or
1194 the maximum message size of the originator, then an alternate
1195 Response-PDU is generated, transmitted to the originator of the
1196 InformRequest-PDU, and processing of the InformRequest-PDU terminates
1197 immediately thereafter. This alternate Response-PDU is formatted
1198 with the same values in its request-id field as the received
1199 InformRequest-PDU, with the value of its error-status field set to
1200 `tooBig', the value of its error-index field set to zero, and an
1201 empty variable-bindings field. This alternate Response-PDU is then
1202 encapsulated into a message. If the size of the resultant message is
1203 less than or equal to both a local constraint and the maximum message
1204 size of the originator, it is transmitted to the originator of the
1205 InformRequest-PDU. Otherwise, the snmpSilentDrops [9] counter is
1206 incremented and the resultant message is discarded. Regardless,
1207 processing of the InformRequest-PDU terminates.
1209 Otherwise, the receiving SNMPv2 entity:
1211 (1) presents its contents to the appropriate SNMPv2 application;
1213 (2) generates a Response-PDU with the same values in its request-id and
1214 variable-bindings fields as the received InformRequest-PDU, with
1215 the value of its error-status field is set to `noError' and the
1216 value of its error-index field is zero; and
1218 (3) transmits the generated Response-PDU to the originator of the
1221 5. Security Considerations
1223 Security issues are not discussed in this memo.
1234 SNMPv2 Working Group Standards Track [Page 22]
1236 RFC 1905 Protocol Operations for SNMPv2 January 1996
1243 170 West Tasman Drive
1244 San Jose, CA 95134-1706
1247 Phone: +1 408 526 5260
1248 EMail: kzm@cisco.com
1252 This document is the result of significant work by the four major
1255 Jeffrey D. Case (SNMP Research, case@snmp.com)
1256 Keith McCloghrie (Cisco Systems, kzm@cisco.com)
1257 Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
1258 Steven Waldbusser (International Network Services, stevew@uni.ins.com)
1260 In addition, the contributions of the SNMPv2 Working Group are
1261 acknowledged. In particular, a special thanks is extended for the
1264 Alexander I. Alten (Novell)
1265 Dave Arneson (Cabletron)
1266 Uri Blumenthal (IBM)
1268 Kim Curran (Bell-Northern Research)
1269 Jim Galvin (Trusted Information Systems)
1270 Maria Greene (Ascom Timeplex)
1271 Iain Hanson (Digital)
1272 Dave Harrington (Cabletron)
1274 Jeff Johnson (Cisco Systems)
1275 Michael Kornegay (Object Quest)
1276 Deirdre Kostick (AT&T Bell Labs)
1277 David Levi (SNMP Research)
1278 Daniel Mahoney (Cabletron)
1279 Bob Natale (ACE*COMM)
1280 Brian O'Keefe (Hewlett Packard)
1281 Andrew Pearson (SNMP Research)
1282 Dave Perkins (Peer Networks)
1283 Randy Presuhn (Peer Networks)
1284 Aleksey Romanov (Quality Quorum)
1285 Shawn Routhier (Epilogue)
1286 Jon Saperia (BGS Systems)
1290 SNMPv2 Working Group Standards Track [Page 23]
1292 RFC 1905 Protocol Operations for SNMPv2 January 1996
1295 Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
1296 Kaj Tesink (Bellcore)
1297 Glenn Waters (Bell-Northern Research)
1302 [1] Information processing systems - Open Systems Interconnection -
1303 Specification of Abstract Syntax Notation One (ASN.1),
1304 International Organization for Standardization. International
1305 Standard 8824, (December, 1987).
1307 [2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
1308 S. Waldbusser, "Structure of Management Information for Version 2
1309 of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
1312 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
1313 S. Waldbusser, "Textual Conventions for Version 2 of the Simple
1314 Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
1316 [4] Kent, C., and J. Mogul, Fragmentation Considered Harmful,
1317 Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).
1319 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
1320 S. Waldbusser, "Transport Mappings for Version 2 of the Simple
1321 Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
1323 [6] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
1324 USC/Information Sciences Institute, August 1980.
1326 [7] McCloghrie, K., and M. Rose, Editors, "Management Information
1327 Base for Network Management of TCP/IP-based internets:
1328 MIB-II", STD 17, RFC 1213, March 1991.
1330 [8] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
1331 S. Waldbusser, "Coexistence between Version 1 and Version 2
1332 of the Internet-standard Network Management Framework", RFC 1908,
1335 [9] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
1336 S. Waldbusser, "Management Information Base for Version 2 of the
1337 Simple Network Management Protocol (SNMPv2)", RFC 1907,
1346 SNMPv2 Working Group Standards Track [Page 24]