12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120220320420520620720820921021121221321421521621721821922022122222322422522622722822923023123223323423523623723823924024124224324424524624724824925025125225325425525625725825926026126226326426526626726826927027127227327427527627727827928028128228328428528628728828929029129229329429529629729829930030130230330430530630730830931031131231331431531631731831932032132232332432532632732832933033133233333433533633733833934034134234334434534634734834935035135235335435535635735835936036136236336436536636736836937037137237337437537637737837938038138238338438538638738838939039139239339439539639739839940040140240340440540640740840941041141241341441541641741841942042142242342442542642742842943043143243343443543643743843944044144244344444544644744844945045145245345445545645745845946046146246346446546646746846947047147247347447547647747847948048148248348448548648748848949049149249349449549649749849950050150250350450550650750850951051151251351451551651751851952052152252352452552652752852953053153253353453553653753853954054154254354454554654754854955055155255355455555655755855956056156256356456556656756856957057157257357457557657757857958058158258358458558658758858959059159259359459559659759859960060160260360460560660760860961061161261361461561661761861962062162262362462562662762862963063163263363463563663763863964064164264364464564664764864965065165265365465565665765865966066166266366466566666766866967067167267367467567667767867968068168268368468568668768868969069169269369469569669769869970070170270370470570670770870971071171271371471571671771871972072172272372472572672772872973073173273373473573673773873974074174274374474574674774874975075175275375475575675775875976076176276376476576676776876977077177277377477577677777877978078178278378478578678778878979079179279379479579679779879980080180280380480580680780880981081181281381481581681781881982082182282382482582682782882983083183283383483583683783883984084184284384484584684784884985085185285385485585685785885986086186286386486586686786886987087187287387487587687787887988088188288388488588688788888989089189289389489589689789889990090190290390490590690790890991091191291391491591691791891992092192292392492592692792892993093193293393493593693793893994094194294394494594694794894995095195295395495595695795895996096196296396496596696796896997097197297397497597697797897998098198298398498598698798898999099199299399499599699799899910001001100210031004100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028102910301031103210331034103510361037103810391040104110421043104410451046104710481049105010511052105310541055105610571058105910601061106210631064106510661067106810691070107110721073107410751076107710781079108010811082108310841085108610871088108910901091109210931094109510961097109810991100110111021103110411051106110711081109111011111112111311141115111611171118111911201121112211231124112511261127112811291130113111321133113411351136113711381139114011411142114311441145114611471148114911501151115211531154115511561157115811591160116111621163116411651166116711681169117011711172117311741175117611771178117911801181118211831184118511861187118811891190119111921193119411951196119711981199120012011202120312041205120612071208120912101211121212131214121512161217121812191220122112221223122412251226122712281229123012311232123312341235123612371238123912401241124212431244124512461247124812491250125112521253125412551256125712581259126012611262126312641265126612671268126912701271127212731274127512761277127812791280128112821283128412851286128712881289129012911292129312941295129612971298129913001301130213031304130513061307130813091310131113121313131413151316131713181319132013211322132313241325132613271328132913301331133213331334133513361337133813391340134113421343134413451346134713481349135013511352135313541355135613571358135913601361136213631364136513661367136813691370137113721373137413751376137713781379138013811382138313841385138613871388138913901391139213931394139513961397139813991400140114021403140414051406140714081409141014111412141314141415141614171418141914201421142214231424142514261427142814291430143114321433143414351436143714381439144014411442144314441445144614471448144914501451145214531454145514561457145814591460146114621463146414651466146714681469147014711472147314741475147614771478147914801481148214831484148514861487148814891490149114921493149414951496149714981499150015011502150315041505150615071508150915101511151215131514151515161517151815191520152115221523152415251526152715281529153015311532153315341535153615371538153915401541154215431544154515461547154815491550155115521553155415551556155715581559156015611562156315641565156615671568156915701571157215731574157515761577157815791580158115821583158415851586158715881589159015911592159315941595159615971598159916001601160216031604160516061607160816091610161116121613161416151616161716181619162016211622162316241625162616271628162916301631163216331634163516361637163816391640164116421643164416451646164716481649165016511652165316541655165616571658165916601661166216631664166516661667166816691670167116721673167416751676167716781679168016811682168316841685168616871688168916901691169216931694169516961697169816991700170117021703170417051706170717081709171017111712171317141715171617171718171917201721172217231724172517261727172817291730173117321733173417351736173717381739 |
-
-
-
-
-
-
- Network Working Group Editor of this version:
- Request for Comments: 3416 R. Presuhn
- STD: 62 BMC Software, Inc.
- Obsoletes: 1905 Authors of previous version:
- Category: Standards Track J. Case
- SNMP Research, Inc.
- K. McCloghrie
- Cisco Systems, Inc.
- M. Rose
- Dover Beach Consulting, Inc.
- S. Waldbusser
- International Network Services
- December 2002
-
-
- Version 2 of the Protocol Operations for
- the Simple Network Management Protocol (SNMP)
-
- 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.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- Abstract
-
- This document defines version 2 of the protocol operations for the
- Simple Network Management Protocol (SNMP). It defines the syntax and
- elements of procedure for sending, receiving, and processing SNMP
- PDUs. This document obsoletes RFC 1905.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 1]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- Table of Contents
-
- 1. Introduction ................................................ 3
- 2. Overview .................................................... 4
- 2.1. Management Information .................................... 4
- 2.2. Retransmission of Requests ................................ 4
- 2.3. Message Sizes ............................................. 4
- 2.4. Transport Mappings ........................................ 5
- 2.5. SMIv2 Data Type Mappings .................................. 6
- 3. Definitions ................................................. 6
- 4. Protocol Specification ...................................... 9
- 4.1. Common Constructs ......................................... 9
- 4.2. PDU Processing ............................................ 10
- 4.2.1. The GetRequest-PDU ...................................... 10
- 4.2.2. The GetNextRequest-PDU .................................. 11
- 4.2.2.1. Example of Table Traversal ............................ 12
- 4.2.3. The GetBulkRequest-PDU .................................. 14
- 4.2.3.1. Another Example of Table Traversal .................... 17
- 4.2.4. The Response-PDU ........................................ 18
- 4.2.5. The SetRequest-PDU ...................................... 19
- 4.2.6. The SNMPv2-Trap-PDU ..................................... 22
- 4.2.7. The InformRequest-PDU ................................... 23
- 5. Notice on Intellectual Property ............................. 24
- 6. Acknowledgments ............................................. 24
- 7. Security Considerations ..................................... 26
- 8. References .................................................. 26
- 8.1. Normative References ...................................... 26
- 8.2. Informative References .................................... 27
- 9. Changes from RFC 1905 ....................................... 28
- 10. Editor's Address ........................................... 30
- 11. Full Copyright Statement ................................... 31
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 2]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- 1. Introduction
-
- The SNMP Management Framework at the time of this writing consists of
- five major components:
-
- - An overall architecture, described in STD 62, RFC 3411
- [RFC3411].
-
- - Mechanisms for describing and naming objects and events for the
- purpose of management. The first version of this Structure of
- Management Information (SMI) is called SMIv1 and described in
- STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
- 1215 [RFC1215]. The second version, called SMIv2, is described
- in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and
- STD 58, RFC 2580 [RFC2580].
-
- - Message protocols for transferring management information. The
- first version of the SNMP message protocol is called SNMPv1 and
- described in STD 15, RFC 1157 [RFC1157]. A second version of
- the SNMP message protocol, which is not an Internet standards
- track protocol, is called SNMPv2c and described in RFC 1901
- [RFC1901] and STD 62, RFC 3417 [RFC3417]. The third version of
- the message protocol is called SNMPv3 and described in STD 62,
- RFC 3417 [RFC3417], RFC 3412 [RFC3412] and RFC 3414 [RFC3414].
-
- - Protocol operations for accessing management information. The
- first set of protocol operations and associated PDU formats is
- described in STD 15, RFC 1157 [RFC1157]. A second set of
- protocol operations and associated PDU formats is described in
- this document.
-
- - A set of fundamental applications described in STD 62, RFC 3413
- [RFC3413] and the view-based access control mechanism described
- in STD 62, RFC 3415 [RFC3415].
-
- A more detailed introduction to the SNMP Management Framework at the
- time of this writing can be found in RFC 3410 [RFC3410].
-
- Managed objects are accessed via a virtual information store, termed
- the Management Information Base or MIB. Objects in the MIB are
- defined using the mechanisms defined in the SMI.
-
- This document, Version 2 of the Protocol Operations for the Simple
- Network Management Protocol, defines the operations of the protocol
- with respect to the sending and receiving of PDUs to be carried by
- the message protocol.
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 3]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- 2. Overview
-
- SNMP entities supporting command generator or notification receiver
- applications (traditionally called "managers") communicate with SNMP
- entities supporting command responder or notification originator
- applications (traditionally called "agents"). The purpose of this
- protocol is the transport of management information and operations.
-
- 2.1. 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
- [RFC2578] or the textual conventions based on the SMI [RFC2579]. The
- term "variable binding" normally refers to the pairing of the name of
- a variable and 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.2. 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. See
- BCP 41 [RFC2914] for discussion of relevant congestion control
- principles.
-
- 2.3. Message Sizes
-
- The maximum size of an SNMP message is limited to the minimum of:
-
- (1) the maximum message size which the destination SNMP entity can
- accept; and,
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 4]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- (2) the maximum message size which the source SNMP 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 SNMP indicates the minimum message
- size which a SNMP 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 SNMP 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 an SNMP entity supporting command generator applications
- 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 SNMP entity supporting command
- responder applications can generate, and the SNMP entity supporting
- command generator applications 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
- [FRAG], since among other problems, it leads to a decrease in the
- reliability of the transfer of the messages. Thus, an SNMP 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.4. Transport Mappings
-
- It is important to note that the exchange of SNMP 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 [RFC3417]. However, the preferred mapping is the use of
- the User Datagram Protocol [RFC768].
-
-
-
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 5]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- 2.5. SMIv2 Data Type Mappings
-
- The SMIv2 [RFC2578] defines 11 base types (INTEGER, OCTET STRING,
- OBJECT IDENTIFIER, Integer32, IpAddress, Counter32, Gauge32,
- Unsigned32, TimeTicks, Opaque, Counter64) and the BITS construct.
- The SMIv2 base types are mapped to the corresponding selection type
- in the SimpleSyntax and ApplicationSyntax choices of the ASN.1 SNMP
- protocol definition. Note that the INTEGER and Integer32 SMIv2 base
- types are mapped to the integer-value selection type of the
- SimpleSyntax choice. Similarly, the Gauge32 and Unsigned32 SMIv2
- base types are mapped to the unsigned-integer-value selection type of
- the ApplicationSyntax choice.
-
- The SMIv2 BITS construct is mapped to the string-value selection type
- of the SimpleSyntax choice. A BITS value is encoded as an OCTET
- STRING, in which all the named bits in (the definition of) the
- bitstring, commencing with the first bit and proceeding to the last
- bit, are placed in bits 8 (high order bit) to 1 (low order bit) of
- the first octet, followed by bits 8 to 1 of each subsequent octet in
- turn, followed by as many bits as are needed of the final subsequent
- octet, commencing with bit 8. Remaining bits, if any, of the final
- octet are set to zero on generation and ignored on receipt.
-
- 3. Definitions
-
- The PDU syntax is defined using ASN.1 notation [ASN1].
-
- SNMPv2-PDU DEFINITIONS ::= BEGIN
-
- ObjectName ::= OBJECT IDENTIFIER
-
- ObjectSyntax ::= CHOICE {
- simple SimpleSyntax,
- application-wide ApplicationSyntax }
-
- SimpleSyntax ::= CHOICE {
- integer-value INTEGER (-2147483648..2147483647),
- string-value OCTET STRING (SIZE (0..65535)),
- objectID-value OBJECT IDENTIFIER }
-
- ApplicationSyntax ::= CHOICE {
- ipAddress-value IpAddress,
- counter-value Counter32,
- timeticks-value TimeTicks,
- arbitrary-value Opaque,
- big-counter-value Counter64,
- unsigned-integer-value Unsigned32 }
-
-
-
-
- Presuhn, et al. Standards Track [Page 6]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4))
-
- Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295)
-
- Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295)
-
- Gauge32 ::= Unsigned32
-
- TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)
-
- Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING
-
- Counter64 ::= [APPLICATION 6]
- IMPLICIT INTEGER (0..18446744073709551615)
-
- -- 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 ::= [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 defined
- -- in this document. Any SNMP administrative framework making
- -- use of this PDU must define its usage and semantics.
-
-
-
- Presuhn, et al. Standards Track [Page 7]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- Report-PDU ::= [8] IMPLICIT PDU
-
- max-bindings INTEGER ::= 2147483647
-
- PDU ::= SEQUENCE {
- request-id INTEGER (-214783648..214783647),
-
- 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),
- 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 INTEGER (-214783648..214783647),
- non-repeaters INTEGER (0..max-bindings),
- max-repetitions INTEGER (0..max-bindings),
-
- variable-bindings -- values are ignored
- VarBindList
- }
-
- -- variable binding
-
-
-
- Presuhn, et al. Standards Track [Page 8]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- VarBind ::= SEQUENCE {
- name ObjectName,
-
- CHOICE {
- value ObjectSyntax,
- unSpecified NULL, -- in retrieval requests
-
- -- 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, an 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 application needs to use a different request-id
- value on a retransmitted request. The latter strategy is recommended
- for use in the majority of situations.
-
- A non-zero value of the error-status field in a Response-PDU is used
- to indicate that an error 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 error. 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.
-
-
-
-
- Presuhn, et al. Standards Track [Page 9]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- SNMP 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
-
- In the elements of procedure below, any field of a PDU which is not
- referenced by the relevant procedure is ignored by the receiving SNMP
- entity. However, all components of a PDU, including those whose
- values are ignored by the receiving SNMP 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 SNMP 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. The definition of
- "max-bindings" imposes an upper bound on the number of variable
- bindings. In practice, the size of a message is also limited by
- constraints on the maximum message size. A compliant implementation
- must support as many variable bindings in a PDU or BulkPDU as fit
- into the overall maximum message size limit of the SNMP engine, but
- no more than 2147483647 variable bindings.
-
- 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 an
- application.
-
- Upon receipt of a GetRequest-PDU, the receiving SNMP 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.
-
-
-
-
- Presuhn, et al. Standards Track [Page 10]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- (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
- 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
- [RFC3418] 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
- an application.
-
- Upon receipt of a GetNextRequest-PDU, the receiving SNMP 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
-
-
-
- Presuhn, et al. Standards Track [Page 11]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- 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.
-
- 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 [RFC3418] 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.
-
-
-
- Presuhn, et al. Standards Track [Page 12]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- In the protocol exchange sketched below, an application retrieves the
- media-dependent physical address and the address-mapping type for
- each entry in the IP net-to-media Address Translation Table [RFC1213]
- of a particular network element. It also retrieves the value of
- sysUpTime [RFC3418], at which the mappings existed. Suppose that the
- command responder'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 SNMP entity supporting a command generator application begins by
- sending a GetNextRequest-PDU containing the indicated OBJECT
- IDENTIFIER values as the requested variable names:
-
- GetNextRequest ( sysUpTime,
- ipNetToMediaPhysAddress,
- ipNetToMediaType )
-
- The SNMP entity supporting a command responder application responds
- with a Response-PDU:
-
- Response (( sysUpTime.0 = "123456" ),
- ( ipNetToMediaPhysAddress.1.9.2.3.4 = "000010543210" ),
- ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ))
-
- The SNMP entity supporting the command generator application
- continues with:
-
- GetNextRequest ( sysUpTime,
- ipNetToMediaPhysAddress.1.9.2.3.4,
- ipNetToMediaType.1.9.2.3.4 )
-
- The SNMP entity supporting the command responder application responds
- with:
-
- Response (( sysUpTime.0 = "123461" ),
- ( ipNetToMediaPhysAddress.1.10.0.0.51 = "000010012345" ),
- ( ipNetToMediaType.1.10.0.0.51 = "static" ))
-
- The SNMP entity supporting the command generator application
- continues with:
-
- GetNextRequest ( sysUpTime,
- ipNetToMediaPhysAddress.1.10.0.0.51,
- ipNetToMediaType.1.10.0.0.51 )
-
-
-
- Presuhn, et al. Standards Track [Page 13]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- The SNMP entity supporting the command responder application responds
- with:
-
- Response (( sysUpTime.0 = "123466" ),
- ( ipNetToMediaPhysAddress.2.10.0.0.15 = "000010987654" ),
- ( ipNetToMediaType.2.10.0.0.15 = "dynamic" ))
-
- The SNMP entity supporting the command generator application
- 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 SNMP entity
- supporting the command responder application 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" ))
-
- Note how, having reached the end of the column for
- ipNetToMediaPhysAddress, the second variable binding from the command
- responder application has now "wrapped" to the first row in the next
- column. Furthermore, note how, having reached the end of the
- ipNetToMediaTable for the third variable binding, the command
- responder application has responded with the next available object,
- which is outside that table. This response signals the end of the
- table to the command generator application.
-
- 4.2.3. The GetBulkRequest-PDU
-
- A GetBulkRequest-PDU is generated and transmitted at the request of
- an 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 SNMP 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.
-
- 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-
-
-
-
- Presuhn, et al. Standards Track [Page 14]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- 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 SNMP 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 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:
-
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 15]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- (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.
-
- (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
- "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 a command responder
- application may terminate the request with less than the full
- number of repetitions, providing at least one repetition is
- completed.
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 16]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- 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 [RFC3418] 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 SNMP entity supporting the command generator application 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 )
-
- The SNMP entity supporting the command responder application 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" ))
-
-
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 17]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- The SNMP entity supporting the command generator application
- continues with:
-
- GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
- ( sysUpTime,
- ipNetToMediaPhysAddress.1.10.0.0.51,
- ipNetToMediaType.1.10.0.0.51 )
-
- The SNMP entity supporting the command responder application 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" ))
-
- Note how, as in the first example, the variable bindings in the
- response indicate that the end of the table has been reached. The
- fourth variable binding does so by returning information from the
- next available column; the fifth variable binding does so by
- returning information from the first available object
- lexicographically following the table. This response signals the end
- of the table to the command generator application.
-
- 4.2.4. The Response-PDU
-
- The Response-PDU is generated by an SNMP 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.
-
- A compliant SNMP entity supporting a command generator application
- must be able to properly receive and handle a Response-PDU with an
- error-status field equal to "noSuchName", "badValue", or "readOnly".
- (See sections 1.3 and 4.3 of [RFC2576].)
-
-
-
-
- Presuhn, et al. Standards Track [Page 18]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- Upon receipt of a Response-PDU, the receiving SNMP entity presents
- its contents to the application which generated the request with the
- same request-id value. For more details, see [RFC3412].
-
- 4.2.5. The SetRequest-PDU
-
- A SetRequest-PDU is generated and transmitted at the request of an
- application.
-
- Upon receipt of a SetRequest-PDU, the receiving SNMP 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 [RFC3418] counter is incremented and the resultant
- message is discarded. Regardless, processing of the SetRequest-PDU
- terminates.
-
- Otherwise, the receiving SNMP 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.
-
-
-
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 19]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- 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.
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 20]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- (7) Otherwise, if the variable binding's name specifies a variable
- which does not exist and could not ever be created (even though
- 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.
-
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 21]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- 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
- 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
-
- An SNMPv2-Trap-PDU is generated and transmitted by an SNMP entity on
- behalf of a notification originator application. The SNMPv2-Trap-PDU
- is often used to notify a notification receiver application at a
- logically remote SNMP entity that an event has occurred or that a
- condition is present. There is no confirmation associated with this
- notification delivery mechanism.
-
- The destination(s) to which an SNMPv2-Trap-PDU is sent is determined
- in an implementation-dependent fashion by the SNMP entity. The first
- two variable bindings in the variable binding list of an SNMPv2-
- Trap-PDU are sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418]
- 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,
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 22]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- to the variable-bindings field. If any additional variables are
- being included (at the option of the generating SNMP entity), then
- each is copied to the variable-bindings field.
-
- 4.2.7. The InformRequest-PDU
-
- An InformRequest-PDU is generated and transmitted by an SNMP entity
- on behalf of a notification originator application. The
- InformRequest-PDU is often used to notify a notification receiver
- application that an event has occurred or that a condition is
- present. This is a confirmed notification delivery mechanism,
- although there is, of course, no guarantee of delivery.
-
- The destination(s) to which an InformRequest-PDU is sent is specified
- by the notification originator application. The first two variable
- bindings in the variable binding list of an InformRequest-PDU are
- sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418] 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 SNMP entity), then each is
- copied to the variable-bindings field.
-
- Upon receipt of an InformRequest-PDU, the receiving SNMP 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 [RFC3418] counter
- is incremented and the resultant message is discarded. Regardless,
- processing of the InformRequest-PDU terminates.
-
- Otherwise, the receiving SNMP entity:
-
- (1) presents its contents to the appropriate application;
-
-
-
-
- Presuhn, et al. Standards Track [Page 23]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- (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 set to "noError" and
- the value of its error-index field set to zero; and
-
- (3) transmits the generated Response-PDU to the originator of the
- InformRequest-PDU.
-
- 5. Notice on Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
- 6. Acknowledgments
-
- This document is the product of the SNMPv3 Working Group. Some
- special thanks are in order to the following Working Group members:
-
- Randy Bush
- Jeffrey D. Case
- Mike Daniele
- Rob Frye
- Lauren Heintz
- Keith McCloghrie
- Russ Mundy
- David T. Perkins
- Randy Presuhn
- Aleksey Romanov
- Juergen Schoenwaelder
- Bert Wijnen
-
-
-
-
- Presuhn, et al. Standards Track [Page 24]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- This version of the document, edited by Randy Presuhn, was initially
- based on the work of a design team whose members were:
-
- Jeffrey D. Case
- Keith McCloghrie
- David T. Perkins
- Randy Presuhn
- Juergen Schoenwaelder
-
- The previous versions of this document, edited by Keith McCloghrie,
- was the result of significant work by four major contributors:
-
- Jeffrey D. Case
- Keith McCloghrie
- Marshall T. Rose
- Steven Waldbusser
-
- Additionally, the contributions of the SNMPv2 Working Group to the
- previous versions are also acknowledged. In particular, a special
- thanks is extended for the contributions of:
-
- Alexander I. Alten
- Dave Arneson
- Uri Blumenthal
- Doug Book
- Kim Curran
- Jim Galvin
- Maria Greene
- Iain Hanson
- Dave Harrington
- Nguyen Hien
- Jeff Johnson
- Michael Kornegay
- Deirdre Kostick
- David Levi
- Daniel Mahoney
- Bob Natale
- Brian O'Keefe
- Andrew Pearson
- Dave Perkins
- Randy Presuhn
- Aleksey Romanov
- Shawn Routhier
- Jon Saperia
- Juergen Schoenwaelder
- Bob Stewart
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 25]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- Kaj Tesink
- Glenn Waters
- Bert Wijnen
-
- 7. Security Considerations
-
- The protocol defined in this document by itself does not provide a
- secure environment. Even if the network itself is secure (for
- example by using IPSec), there is no control as to who on the secure
- network is allowed access to management information.
-
- It is recommended that the implementors consider the security
- features as provided by the SNMPv3 framework. Specifically, the use
- of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the
- View-based Access Control Model STD 62, RFC 3415 [RFC3415] is
- recommended.
-
- It is then a customer/user responsibility to ensure that the SNMP
- entity is properly configured so that:
-
- - only those principals (users) having legitimate rights can
- access or modify the values of any MIB objects supported by
- that entity;
-
- - the occurrence of particular events on the entity will be
- communicated appropriately;
-
- - the entity responds appropriately and with due credence to
- events and information that have been communicated to it.
-
- 8. References
-
- 8.1. Normative References
-
- [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
- August 1980.
-
- [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
- Rose, M. and S. Waldbusser, "Structure of Management
- Information Version 2 (SMIv2)", STD 58, RFC 2578, April
- 1999.
-
- [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
- Rose, M. and S. Waldbusser, "Textual Conventions for
- SMIv2", STD 58, RFC 2579, April 1999.
-
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 26]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
- Rose, M. and S. Waldbusser, "Conformance Statements for
- SMIv2", STD 58, RFC 2580, April 1999.
-
- [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An
- Architecture for Describing Simple Network Management
- Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
- December 2002.
-
- [RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen,
- "Message Processing and Dispatching for the Simple
- Network Management Protocol (SNMP)", STD 62, RFC 3412,
- December 2002.
-
- [RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network
- Management Protocol (SNMP) Applications", STD 62, RFC
- 3413, December 2002.
-
- [RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security
- Model (USM) for Version 3 of the Simple Network
- Management Protocol (SNMPv3)", STD 62, RFC 3414, December
- 2002.
-
- [RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
- Access Control Model (VACM) for the Simple Network
- Management Protocol (SNMP)", STD 62, RFC 3415, December
- 2002.
-
- [RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
- Waldbusser, "Transport Mappings for the Simple Network
- Management Protocol", STD 62, RFC 3417, December 2002.
-
- [RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
- Waldbusser, "Management Information Base (MIB) for the
- Simple Network Management Protocol (SNMP)", STD 62, RFC
- 3418, December 2002.
-
- [ASN1] Information processing systems - Open Systems
- Interconnection - Specification of Abstract Syntax
- Notation One (ASN.1), International Organization for
- Standardization. International Standard 8824, December
- 1987.
-
- 8.2. Informative References
-
- [FRAG] Kent, C. and J. Mogul, "Fragmentation Considered
- Harmful," Proceedings, ACM SIGCOMM '87, Stowe, VT, August
- 1987.
-
-
-
- Presuhn, et al. Standards Track [Page 27]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
- of Management Information for TCP/IP-based Internets",
- STD 16, RFC 1155, May 1990.
-
- [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
- "Simple Network Management Protocol", STD 15, RFC 1157,
- May 1990.
-
- [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
- STD 16, RFC 1212, March 1991.
-
- [RFC1213] 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.
-
- [RFC1215] Rose, M., "A Convention for Defining Traps for use with
- the SNMP", RFC 1215, March 1991.
-
- [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
- "Introduction to Community-based SNMPv2", RFC 1901,
- January 1996.
-
- [RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen,
- "Coexistence between Version 1, Version 2, and Version 3
- of the Internet-Standard Network Management Framework",
- RFC 2576, March 2000.
-
- [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
- MIB", RFC 2863, June 2000.
-
- [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
- 2914, September 2000.
-
- [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
- "Introduction and Applicability Statements for Internet-
- Standard Management Framework", RFC 3410, December 2002.
-
- 9. Changes from RFC 1905
-
- These are the changes from RFC 1905:
-
- - Corrected spelling error in copyright statement;
-
- - Updated copyright date;
-
- - Updated with new editor's name and contact information;
-
- - Added notice on intellectual property;
-
-
-
- Presuhn, et al. Standards Track [Page 28]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- - Cosmetic fixes to layout and typography;
-
- - Added table of contents;
-
- - Title changed;
-
- - Updated document headers and footers;
-
- - Deleted the old clause 2.3, entitled "Access to Management
- Information";
-
- - Changed the way in which request-id was defined, though with
- the same ultimate syntax and semantics, to avoid coupling with
- SMI. This does not affect the protocol in any way;
-
- - Replaced the word "exception" with the word "error" in the old
- clause 4.1. This does not affect the protocol in any way;
-
- - Deleted the first two paragraphs of the old clause 4.2;
-
- - Clarified the maximum number of variable bindings that an
- implementation must support in a PDU. This does not affect the
- protocol in any way;
-
- - Replaced occurrences of "SNMPv2 application" with
- "application";
-
- - Deleted three sentences in old clause 4.2.3 describing the
- handling of an impossible situation. This does not affect the
- protocol in any way;
-
- - Clarified the use of the SNMPv2-Trap-Pdu in the old clause
- 4.2.6. This does not affect the protocol in any way;
-
- - Aligned description of the use of the InformRequest-Pdu in old
- clause 4.2.7 with the architecture. This does not affect the
- protocol in any way;
-
- - Updated references;
-
- - Re-wrote introduction clause;
-
- - Replaced manager/agent/SNMPv2 entity terminology with
- terminology from RFC 2571. This does not affect the protocol
- in any way;
-
- - Eliminated IMPORTS from the SMI, replaced with equivalent in-
- line ASN.1. This does not affect the protocol in any way;
-
-
-
- Presuhn, et al. Standards Track [Page 29]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- - Added notes calling attention to two different manifestations
- of reaching the end of a table in the table walk examples;
-
- - Added content to security considerations clause;
-
- - Updated ASN.1 comment on use of Report-PDU. This does not
- affect the protocol in any way;
-
- - Updated acknowledgments section;
-
- - Included information on handling of BITS;
-
- - Deleted spurious comma in ASN.1 definition of PDUs;
-
- - Added abstract;
-
- - Made handling of additional variable bindings in informs
- consistent with that for traps. This was a correction of an
- editorial oversight, and reflects implementation practice;
-
- - Added reference to RFC 2914.
-
- 10. Editor's Address
-
- Randy Presuhn
- BMC Software, Inc.
- 2141 North First Street
- San Jose, CA 95131
- USA
-
- Phone: +1 408 546 1006
- EMail: randy_presuhn@bmc.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 30]
-
- RFC 3416 Protocol Operations for SNMP December 2002
-
-
- 11. Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
- Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Presuhn, et al. Standards Track [Page 31]
|