idnits 2.17.1 draft-ietf-snmpv2-proto-ds-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 26 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 314: '... -- MUST be identical in...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 344, but not defined == Unused Reference: '12' is defined on line 1149, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Protocol Operations 2 for Version 2 of the 3 Simple Network Management Protocol (SNMPv2) 5 31 May 1995 | 7 draft-ietf-snmpv2-proto-ds-02.txt | 9 Jeffrey D. Case 10 SNMP Research, Inc. 11 case@snmp.com 13 Keith McCloghrie 14 Cisco Systems, Inc. 15 kzm@cisco.com 17 Marshall T. Rose 18 Dover Beach Consulting, Inc. 19 mrose@dbc.mtview.ca.us 21 Steven Waldbusser 22 Carnegie Mellon University 23 waldbusser@cmu.edu 25 Status of this Memo 27 This document is an Internet-Draft. Internet-Drafts are working 28 documents of the Internet Engineering Task Force (IETF), its areas, and 29 its working groups. Note that other groups may also distribute working 30 documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet- Drafts as reference material 35 or to cite them other than as ``work in progress.'' 37 To learn the current status of any Internet-Draft, please check the 38 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 39 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 40 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 42 1. Introduction 44 A management system contains: several (potentially many) nodes, each 45 with a processing entity, termed an agent, which has access to 46 management instrumentation; at least one management station; and, a 47 management protocol, used to convey management information between the 48 agents and management stations. Operations of the protocol are carried 49 out under an administrative framework which defines authentication, 50 authorization, access control, and privacy policies. 52 Management stations execute management applications which monitor and 53 control managed elements. Managed elements are devices such as hosts, 54 routers, terminal servers, etc., which are monitored and controlled via 55 access to their management information. 57 Management information is viewed as a collection of managed objects, 58 residing in a virtual information store, termed the Management 59 Information Base (MIB). Collections of related objects are defined in 60 MIB modules. These modules are written using a subset of OSI's Abstract 61 Syntax Notation One (ASN.1) [1], termed the Structure of Management 62 Information (SMI) [2]. 64 The management protocol, version 2 of the Simple Network Management 65 Protocol, provides for the exchange of messages which convey management 66 information between the agents and the management stations. The form of 67 these messages is a message "wrapper" which encapsulates a Protocol Data 68 Unit (PDU). The form and meaning of the "wrapper" is determined by an 69 administrative framework which defines both authentication and 70 authorization policies. 72 It is the purpose of this document, Protocol Operations for SNMPv2, to 73 define the operations of the protocol with respect to the sending and 74 receiving of the PDUs. 76 1.1. A Note on Terminology 78 For the purpose of exposition, the original Internet-standard Network 79 Management Framework, as described in RFCs 1155, 1157, and 1212, is 80 termed the SNMP version 1 framework (SNMPv1). The current framework is 81 termed the SNMP version 2 framework (SNMPv2). 83 2. Overview - 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 management 90 operations in response to received SNMPv2 protocol messages (other than 91 an inform notification) or when it sends trap notifications. 93 A SNMPv2 entity acts in a manager role when it initiates SNMPv2 94 management operations by the generation of SNMPv2 protocol messages or 95 when it performs SNMPv2 management operations in response to received 96 trap or inform notifications. 98 A SNMPv2 entity may support either or both roles, as dictated by its 99 implementation and configuration. Further, a SNMPv2 entity can also act 100 in the role of a proxy agent, in which it appears to be acting in an 101 agent role, but satisfies management requests by acting in a manager 102 role with a remote entity. The use of proxy agents and the transparency 103 principle that defines their behavior is described in [3]. 105 2.2. Management Information 107 The term, variable, refers to an instance of a non-aggregate object type 108 defined according to the conventions set forth in the SMI [2] or the 109 textual conventions based on the SMI [4]. The term, variable binding, 110 normally refers to the pairing of the name of a variable and its 111 associated value. However, if certain kinds of exceptional conditions 112 occur during processing of a retrieval request, a variable binding will 113 pair a name and an indication of that exception. 115 A variable-binding list is a simple list of variable bindings. 117 The name of a variable is an OBJECT IDENTIFIER which is the 118 concatenation of the OBJECT IDENTIFIER of the corresponding object-type 119 together with an OBJECT IDENTIFIER fragment identifying the instance. 120 The OBJECT IDENTIFIER of the corresponding object-type is called the 121 OBJECT IDENTIFIER prefix of the variable. 123 2.3. Access to Management Information 125 Three types of access to management information are provided by the 126 protocol. One type is a request-response interaction, in which a SNMPv2 127 entity, acting in a manager role, sends a request to a SNMPv2 entity, 128 acting in an agent role, and the latter SNMPv2 entity then responds to 129 the request. This type is used to retrieve or modify management 130 information associated with the managed device. 132 A second type is also a request-response interaction, in which a SNMPv2 133 entity, acting in a manager role, sends a request to a SNMPv2 entity, 134 also acting in a manager role, and the latter SNMPv2 entity then 135 responds to the request. This type is used to notify a SNMPv2 entity, 136 acting in a manager role, of management information associated with 137 another SNMPv2 entity, also acting in a manager role. 139 The third type of access is an unconfirmed interaction, in which a 140 SNMPv2 entity, acting in an agent role, sends a unsolicited message, 141 termed a trap, to a SNMPv2 entity, acting in a manager role, and no 142 response is returned. This type is used to notify a SNMPv2 entity, 143 acting in a manager role, of an exceptional situation, which has 144 resulted in changes to management information associated with the 145 managed device. 147 2.4. Retransmission of Requests 149 For all types of request in this protocol, the receiver is required 150 under normal circumstances, to generate and transmit a response to the 151 originator of the request. Whether or not a request should be 152 retransmitted if no corresponding response is received in an appropriate 153 time interval, is at the discretion of the application originating the 154 request. This will normally depend on the urgency of the request. 155 However, such an application needs to act responsibly in respect to the 156 frequency and duration of re-transmissions. 158 2.5. Message Sizes 160 The maximum size of a SNMPv2 message is limited the minimum of: 162 (1) the maximum message size which the destination SNMPv2 entity can 163 accept; and, 165 (2) the maximum message size which the source SNMPv2 entity can 166 generate. 168 The former is indicated by partyMaxMessageSize[5] of the destination 169 party. The latter is imposed by implementation-specific local 170 constraints. 172 Each transport mapping for the SNMPv2 indicates the minimum message size 173 which a SNMPv2 implementation must be able to produce or consume. 174 Although implementations are encouraged to support larger values 175 whenever possible, a conformant implementation must never generate 176 messages larger than allowed by the receiving SNMPv2 entity. 178 One of the aims of the GetBulkRequest-PDU, specified in this protocol, 179 is to minimize the number of protocol exchanges required to retrieve a 180 large amount of management information. As such, this PDU type allows a 181 SNMPv2 entity acting in a manager role to request that the response be 182 as large as possible given the constraints on message sizes. These 183 constraints include the limits on the size of messages which the SNMPv2 184 entity acting in an agent role can generate, and the SNMPv2 entity 185 acting in a manager role can receive. 187 However, it is possible that such maximum sized messages may be larger 188 than the Path MTU of the path across the network traversed by the 189 messages. In this situation, such messages are subject to 190 fragmentation. Fragmentation is generally considered to be harmful [6], 191 since among other problems, it leads to a decrease in the reliability of 192 the transfer of the messages. Thus, a SNMPv2 entity which sends a 193 GetBulkRequest-PDU must take care to set its parameters accordingly, so 194 as to reduce the risk of fragmentation. In particular, under conditions 195 of network stress, only small values should be used for max-repetitions. 197 2.6. Transport Mappings 199 It is important to note that the exchange of SNMPv2 messages requires 200 only an unreliable datagram service, with every message being entirely 201 and independently contained in a single transport datagram. Specific 202 transport mappings and encoding rules are specified elsewhere [7]. 203 However, the preferred mapping is the use of the User Datagram Protocol 204 [8]. 206 3. Definitions 208 SNMPv2-PDU DEFINITIONS ::= BEGIN 210 IMPORTS 211 ObjectName, ObjectSyntax, Integer32 212 FROM SNMPv2-SMI; 214 -- protocol data units 216 PDUs ::= 217 CHOICE { 218 get-request 219 GetRequest-PDU, 221 get-next-request 222 GetNextRequest-PDU, 224 get-bulk-request 225 GetBulkRequest-PDU, 227 response 228 Response-PDU, 230 set-request 231 SetRequest-PDU, 233 inform-request 234 InformRequest-PDU, 236 snmpV2-trap 237 SNMPv2-Trap-PDU 238 } 240 -- PDUs 242 GetRequest-PDU ::= 243 [0] 244 IMPLICIT PDU 246 GetNextRequest-PDU ::= 247 [1] 248 IMPLICIT PDU 250 Response-PDU ::= 251 [2] 252 IMPLICIT PDU 254 SetRequest-PDU ::= 255 [3] 256 IMPLICIT PDU 258 -- [4] is obsolete 260 GetBulkRequest-PDU ::= 261 [5] 262 IMPLICIT BulkPDU 264 InformRequest-PDU ::= 265 [6] 266 IMPLICIT PDU 268 SNMPv2-Trap-PDU ::= 269 [7] 270 IMPLICIT PDU 272 -- defined in reference [3] 273 -- Report-PDU ::= 274 -- [8] 275 -- IMPLICIT PDU 276 max-bindings 277 INTEGER ::= 2147483647 279 PDU ::= 280 SEQUENCE { 281 request-id 282 Integer32, 284 error-status -- sometimes ignored 285 INTEGER { 286 noError(0), 287 tooBig(1), 288 noSuchName(2), -- for proxy compatibility 289 badValue(3), -- for proxy compatibility 290 readOnly(4), -- for proxy compatibility 291 genErr(5), 292 noAccess(6), 293 wrongType(7), 294 wrongLength(8), 295 wrongEncoding(9), 296 wrongValue(10), 297 noCreation(11), 298 inconsistentValue(12), 299 resourceUnavailable(13), 300 commitFailed(14), 301 undoFailed(15), 302 authorizationError(16), 303 notWritable(17), 304 inconsistentName(18) 305 }, 307 error-index -- sometimes ignored 308 INTEGER (0..max-bindings), 310 variable-bindings -- values are sometimes ignored 311 VarBindList 312 } 314 BulkPDU ::= -- MUST be identical in 315 SEQUENCE { -- structure to PDU 316 request-id 317 Integer32, 319 non-repeaters 320 INTEGER (0..max-bindings), 322 max-repetitions 323 INTEGER (0..max-bindings), 325 variable-bindings -- values are ignored 326 VarBindList 327 } 329 -- variable binding 331 VarBind ::= 332 SEQUENCE { 333 name 334 ObjectName, 336 CHOICE { 337 value 338 ObjectSyntax, 340 unSpecified -- in retrieval requests 341 NULL, 343 -- exceptions in responses 344 noSuchObject[0] 345 IMPLICIT NULL, 347 noSuchInstance[1] 348 IMPLICIT NULL, 350 endOfMibView[2] 351 IMPLICIT NULL 352 } 353 } 355 -- variable-binding list 357 VarBindList ::= 358 SEQUENCE (SIZE (0..max-bindings)) OF 359 VarBind 361 END 363 4. Protocol Specification 365 4.1. Common Constructs 367 The value of the request-id field in a Response-PDU takes the value of 368 the request-id field in the request PDU to which it is a response. By 369 use of the request-id value, a SNMPv2 application can distinguish the 370 (potentially multiple) outstanding requests, and thereby correlate 371 incoming responses with outstanding requests. In cases where an 372 unreliable datagram service is used, the request-id also provides a 373 simple means of identifying messages duplicated by the network. Use of 374 the same request-id on a retransmission of a request allows the response 375 to either the original transmission or the retransmission to satisfy the 376 request. However, in order to calculate the round trip time for 377 transmission and processing of a request-response transaction, the 378 SNMPv2 application needs to use a different request-id value on a 379 retransmitted request. The latter strategy is recommended for use in 380 the majority of situations. 382 A non-zero value of the error-status field in a Response-PDU is used to 383 indicate that an exception occurred to prevent the processing of the 384 request. In these cases, a non-zero value of the Response-PDU's error- 385 index field provides additional information by identifying which 386 variable binding in the list caused the exception. A variable binding 387 is identified by its index value. The first variable binding in a 388 variable-binding list is index one, the second is index two, etc. 390 SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128 sub- 391 identifiers, where each sub-identifier has a maximum value of 2**32-1. 393 4.2. PDU Processing 395 It is mandatory that all SNMPv2 entities acting in an agent role be able 396 to generate the following PDU types: Response-PDU and SNMPv2-Trap-PDU; 397 further, all such implementations must be able to receive the following 398 PDU types: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, and 399 SetRequest-PDU. 401 It is mandatory that all SNMPv2 entities acting in a manager role be 402 able to generate the following PDU types: GetRequest-PDU, 403 GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, InformRequest- 404 PDU, and Response-PDU; further, all such implementations must be able to 405 receive the following PDU types: Response-PDU, SNMPv2-Trap-PDU, 406 InformRequest-PDU; 408 In the elements of procedure below, any field of a PDU which is not 409 referenced by the relevant procedure is ignored by the receiving SNMPv2 410 entity. However, all components of a PDU, including those whose values 411 are ignored by the receiving SNMPv2 entity, must have valid ASN.1 syntax 412 and encoding. For example, some PDUs (e.g., the GetRequest-PDU) are 413 concerned only with the name of a variable and not its value. In this 414 case, the value portion of the variable binding is ignored by the 415 receiving SNMPv2 entity. The unSpecified value is defined for use as 416 the value portion of such bindings. 418 For all generated PDUs, the message "wrapper" to encapsulate the PDU is 419 generated and transmitted as specified in [3]. While the definition of 420 "max-bindings" does impose an upper-bound on the number of variable 421 bindings, in practice, the size of a message is limited only by 422 constraints on the maximum message size, either a local limitation or 423 the limit associated with the message's destination party, i.e., it is 424 not limited by the number of variable bindings. 426 On receiving a management communication, the procedures defined in 427 Section 3.2 of [3] are followed. If these procedures indicate that the 428 PDU contained within the message "wrapper" is to be processed, then the 429 SNMPv2 context associated with the PDU defines the object resources 430 which are visible to the operation. 432 4.2.1. The GetRequest-PDU 434 A GetRequest-PDU is generated and transmitted at the request of a SNMPv2 435 application. 437 Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity processes 438 each variable binding in the variable-binding list to produce a 439 Response-PDU. All fields of the Response-PDU have the same values as 440 the corresponding fields of the received request except as indicated 441 below. Each variable binding is processed as follows: 443 (1) If the variable binding's name exactly matches the name of a 444 variable accessible by this request, then the variable binding's 445 value field is set to the value of the named variable. 447 (2) Otherwise, if the variable binding's name does not have an OBJECT 448 IDENTIFIER prefix which exactly matches the OBJECT IDENTIFIER 449 prefix of any (potential) variable accessible by this request, then 450 its value field is set to `noSuchObject'. 452 (3) Otherwise, the variable binding's value field is set to to 453 `noSuchInstance'. 455 If the processing of any variable binding fails for a reason other than 456 listed above, then the Response-PDU is re-formatted with the same values 457 in its request-id and variable-bindings fields as the received 458 GetRequest-PDU, with the value of its error-status field set to 459 `genErr', and the value of its error-index field is set to the index of 460 the failed variable binding. 462 Otherwise, the value of the Response-PDU's error-status field is set to 463 `noError', and the value of its error-index field is zero. 465 The generated Response-PDU is then encapsulated into a message. If the 466 size of the resultant message is less than or equal to both a local 467 constraint and the maximum message size of the request's source party, 468 it is transmitted to the originator of the GetRequest-PDU. 470 Otherwise, an alternate Response-PDU is generated. This alternate 471 Response-PDU is formatted with the same value in its request-id field as 472 the received GetRequest-PDU, with the value of its error-status field 473 set to `tooBig', the value of its error-index field set to zero, and an 474 empty variable-bindings field. This alternate Response-PDU is then 475 encapsulated into a message. If the size of the resultant message is 476 less than or equal to both a local constraint and the maximum message 477 size of the request's source party, it is transmitted to the originator 478 of the GetRequest-PDU. Otherwise, the snmpStatsSilentDrops [11] counter 479 is incremented and the resultant message is discarded. 481 4.2.2. The GetNextRequest-PDU 483 A GetNextRequest-PDU is generated and transmitted at the request of a 484 SNMPv2 application. 486 Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2 entity 487 processes each variable binding in the variable-binding list to produce 488 a Response-PDU. All fields of the Response-PDU have the same values as 489 the corresponding fields of the received request except as indicated 490 below. Each variable binding is processed as follows: 492 (1) The variable is located which is in the lexicographically ordered 493 list of the names of all variables which are accessible by this 494 request and whose name is the first lexicographic successor of the 495 variable binding's name in the incoming GetNextRequest-PDU. The 496 corresponding variable binding's name and value fields in the 497 Response-PDU are set to the name and value of the located variable. 499 (2) If the requested variable binding's name does not lexicographically 500 precede the name of any variable accessible by this request, i.e., 501 there is no lexicographic successor, then the corresponding 502 variable binding produced in the Response-PDU has its value field 503 set to `endOfMibView', and its name field set to the variable 504 binding's name in the request. 506 If the processing of any variable binding fails for a reason other than 507 listed above, then the Response-PDU is re-formatted with the same values 508 in its request-id and variable-bindings fields as the received 509 GetNextRequest-PDU, with the value of its error-status field set to 510 `genErr', and the value of its error-index field is set to the index of 511 the failed variable binding. 513 Otherwise, the value of the Response-PDU's error-status field is set to 514 `noError', and the value of its error-index field is zero. 516 The generated Response-PDU is then encapsulated into a message. If the 517 size of the resultant message is less than or equal to both a local 518 constraint and the maximum message size of the request's source party, 519 it is transmitted to the originator of the GetNextRequest-PDU. 521 Otherwise, an alternate Response-PDU is generated. This alternate 522 Response-PDU is formatted with the same values in its request-id field 523 as the received GetNextRequest-PDU, with the value of its error-status 524 field set to `tooBig', the value of its error-index field set to zero, 525 and an empty variable-bindings field. This alternate Response-PDU is 526 then encapsulated into a message. If the size of the resultant message 527 is less than or equal to both a local constraint and the maximum message 528 size of the request's source party, it is transmitted to the originator 529 of the GetNextRequest-PDU. Otherwise, the snmpStatsSilentDrops [11] 530 counter is incremented and the resultant message is discarded. 532 4.2.2.1. Example of Table Traversal 534 An important use of the GetNextRequest-PDU is the traversal of 535 conceptual tables of information within a MIB. The semantics of this 536 type of request, together with the method of identifying individual 537 instances of objects in the MIB, provides access to related objects in 538 the MIB as if they enjoyed a tabular organization. 540 In the protocol exchange sketched below, a SNMPv2 application retrieves 541 the media-dependent physical address and the address-mapping type for 542 each entry in the IP net-to-media Address Translation Table [9] of a 543 particular network element. It also retrieves the value of sysUpTime 544 [11], at which the mappings existed. Suppose that the agent's IP net- 545 to-media table has three entries: 547 Interface-Number Network-Address Physical-Address Type 549 1 10.0.0.51 00:00:10:01:23:45 static 550 1 9.2.3.4 00:00:10:54:32:10 dynamic 551 2 10.0.0.15 00:00:10:98:76:54 dynamic 553 The SNMPv2 entity acting in a manager role begins by sending a 554 GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values as 555 the requested variable names: 557 GetNextRequest ( sysUpTime, 558 ipNetToMediaPhysAddress, 559 ipNetToMediaType ) 561 The SNMPv2 entity acting in an agent role responds with a Response-PDU: 563 Response (( sysUpTime.0 = "123456" ), 564 ( ipNetToMediaPhysAddress.1.9.2.3.4 = 565 "000010543210" ), 566 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" )) 568 The SNMPv2 entity acting in a manager role continues with: 570 GetNextRequest ( sysUpTime, 571 ipNetToMediaPhysAddress.1.9.2.3.4, 572 ipNetToMediaType.1.9.2.3.4 ) 574 The SNMPv2 entity acting in an agent role responds with: 576 Response (( sysUpTime.0 = "123461" ), 577 ( ipNetToMediaPhysAddress.1.10.0.0.51 = 578 "000010012345" ), 579 ( ipNetToMediaType.1.10.0.0.51 = "static" )) 581 The SNMPv2 entity acting in a manager role continues with: 583 GetNextRequest ( sysUpTime, 584 ipNetToMediaPhysAddress.1.10.0.0.51, 585 ipNetToMediaType.1.10.0.0.51 ) 587 The SNMPv2 entity acting in an agent role responds with: 589 Response (( sysUpTime.0 = "123466" ), 590 ( ipNetToMediaPhysAddress.2.10.0.0.15 = 591 "000010987654" ), 592 ( ipNetToMediaType.2.10.0.0.15 = "dynamic" )) 594 The SNMPv2 entity acting in a manager role continues with: 596 GetNextRequest ( sysUpTime, 597 ipNetToMediaPhysAddress.2.10.0.0.15, 598 ipNetToMediaType.2.10.0.0.15 ) 600 As there are no further entries in the table, the SNMPv2 entity acting 601 in an agent role responds with the variables that are next in the 602 lexicographical ordering of the accessible object names, for example: 604 Response (( sysUpTime.0 = "123471" ), 605 ( ipNetToMediaNetAddress.1.9.2.3.4 = 606 "9.2.3.4" ), 607 ( ipRoutingDiscards.0 = "2" )) 609 This response signals the end of the table to the SNMPv2 entity acting 610 in a manager role. 612 4.2.3. The GetBulkRequest-PDU 614 A GetBulkRequest-PDU is generated and transmitted at the request of a 615 SNMPv2 application. The purpose of the GetBulkRequest-PDU is to request 616 the transfer of a potentially large amount of data, including, but not 617 limited to, the efficient and rapid retrieval of large tables. 619 Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2 entity 620 processes each variable binding in the variable-binding list to produce 621 a Response-PDU with its request-id field having the same value as in the 622 request. Processing begins by examining the values in the non-repeaters 623 and max-repetitions fields. If the value in the non-repeaters field is 624 less than zero, then the value of the field is set to zero. Similarly, 625 if the value in the max-repetitions field is less than zero, then the 626 value of the field is set to zero. 628 For the GetBulkRequest-PDU type, the successful processing of each 629 variable binding in the request generates zero or more variable bindings 630 in the Response-PDU. That is, the one-to-one mapping between the 631 variable bindings of the GetRequest-PDU, GetNextRequest-PDU, and 632 SetRequest-PDU types and the resultant Response-PDUs does not apply for 633 the mapping between the variable bindings of a GetBulkRequest-PDU and 634 the resultant Response-PDU. 636 The values of the non-repeaters and max-repetitions fields in the 637 request specify the processing requested. One variable binding in the 638 Response-PDU is requested for the first N variable bindings in the 639 request and M variable bindings are requested for each of the R 640 remaining variable bindings in the request. Consequently, the total 641 number of requested variable bindings communicated by the request is 642 given by N + (M * R), where N is the minimum of: a) the value of the 643 non-repeaters field in the request, and b) the number of variable 644 bindings in the request; M is the value of the max-repetitions field in 645 the request; and R is the maximum of: a) number of variable bindings in 646 the request - N, and b) zero. 648 The receiving SNMPv2 entity produces a Response-PDU with up to the total 649 number of requested variable bindings communicated by the request. The 650 request-id shall have the same value as the received GetBulkRequest-PDU. 652 If N is greater than zero, the first through the (N)-th variable 653 bindings of the Response-PDU are each produced as follows: 655 (1) The variable is located which is in the lexicographically ordered 656 list of the names of all variables which are accessible by this 657 request and whose name is the first lexicographic successor of the 658 variable binding's name in the incoming GetBulkRequest-PDU. The 659 corresponding variable binding's name and value fields in the 660 Response-PDU are set to the name and value of the located variable. 662 (2) If the requested variable binding's name does not lexicographically 663 precede the name of any variable accessible by this request, i.e., 664 there is no lexicographic successor, then the corresponding 665 variable binding produced in the Response-PDU has its value field 666 set to `endOfMibView', and its name field set to the variable 667 binding's name in the request. 669 If M and R are non-zero, the (N + 1)-th and subsequent variable bindings 670 of the Response-PDU are each produced in a similar manner. For each 671 iteration i, such that i is greater than zero and less than or equal to 672 M, and for each repeated variable, r, such that r is greater than zero 673 and less than or equal to R, the (N + ( (i-1) * R ) + r)-th variable 674 binding of the Response-PDU is produced as follows: 676 (1) The variable which is in the lexicographically ordered list of the 677 names of all variables which are accessible by this request and 678 whose name is the (i)-th lexicographic successor of the (N + r)-th 679 variable binding's name in the incoming GetBulkRequest-PDU is 680 located and the variable binding's name and value fields are set to 681 the name and value of the located variable. 683 (2) If there is no (i)-th lexicographic successor, then the 684 corresponding variable binding produced in the Response-PDU has its 685 value field set to `endOfMibView', and its name field set to either 686 the last lexicographic successor, or if there are no lexicographic 687 successors, to the (N + r)-th variable binding's name in the 688 request. 690 While the maximum number of variable bindings in the Response-PDU is 691 bounded by N + (M * R), the response may be generated with a lesser 692 number of variable bindings (possibly zero) for either of three reasons. 694 (1) If the size of the message encapsulating the Response-PDU 695 containing the requested number of variable bindings would be 696 greater than either a local constraint or the maximum message size 697 of the request's source party, then the response is generated with 698 a lesser number of variable bindings. This lesser number is the 699 ordered set of variable bindings with some of the variable bindings 700 at the end of the set removed, such that the size of the message 701 encapsulating the Response-PDU is approximately equal to but no 702 greater than the minimum of the local constraint and the maximum 703 message size of the request's source party. Note that the number 704 of variable bindings removed has no relationship to the values of 705 N, M, or R. 707 (2) The response may also be generated with a lesser number of variable 708 bindings if for some value of iteration i, such that i is greater 709 than zero and less than or equal to M, that all of the generated 710 variable bindings have the value field set to the `endOfMibView'. 711 In this case, the variable bindings may be truncated after the (N + 712 (i * R))-th variable binding. 714 (3) In the event that the processing of a request with many repetitions 715 requires a significantly greater amount of processing time than a 716 normal request, then an agent may terminate the request with less 717 than the full number of repetitions, providing at least one 718 repetition is completed. 720 If the processing of any variable binding fails for a reason other than 721 listed above, then the Response-PDU is re-formatted with the same values 722 in its request-id and variable-bindings fields as the received 723 GetBulkRequest-PDU, with the value of its error-status field set to 724 `genErr', and the value of its error-index field is set to the index of 725 the variable binding in the original request which corresponds to the 726 failed variable binding. 728 Otherwise, the value of the Response-PDU's error-status field is set to 729 `noError', and the value of its error-index field to zero. 731 The generated Response-PDU (possibly with an empty variable-bindings 732 field) is then encapsulated into a message. If the size of the 733 resultant message is less than or equal to both a local constraint and 734 the maximum message size of the request's source party, it is 735 transmitted to the originator of the GetBulkRequest-PDU. Otherwise, the 736 snmpStatsSilentDrops [11] counter is incremented and the resultant 737 message is discarded. 739 4.2.3.1. Another Example of Table Traversal 741 This example demonstrates how the GetBulkRequest-PDU can be used as an 742 alternative to the GetNextRequest-PDU. The same traversal of the IP 743 net-to-media table as shown in Section 4.2.2.1 is achieved with fewer 744 exchanges. 746 The SNMPv2 entity acting in a manager role begins by sending a 747 GetBulkRequest-PDU with the modest max-repetitions value of 2, and 748 containing the indicated OBJECT IDENTIFIER values as the requested 749 variable names: 751 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] 752 ( sysUpTime, 753 ipNetToMediaPhysAddress, 754 ipNetToMediaType ) 756 The SNMPv2 entity acting in an agent role responds with a Response-PDU: 758 Response (( sysUpTime.0 = "123456" ), 759 ( ipNetToMediaPhysAddress.1.9.2.3.4 = 760 "000010543210" ), 761 ( ipNetToMediaType.1.9.2.3.4 = "dynamic" ), 762 ( ipNetToMediaPhysAddress.1.10.0.0.51 = 763 "000010012345" ), 764 ( ipNetToMediaType.1.10.0.0.51 = "static" )) 766 The SNMPv2 entity acting in a manager role continues with: 768 GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] 769 ( sysUpTime, 770 ipNetToMediaPhysAddress.1.10.0.0.51, 771 ipNetToMediaType.1.10.0.0.51 ) 773 The SNMPv2 entity acting in an agent role responds with: 775 Response (( sysUpTime.0 = "123466" ), 776 ( ipNetToMediaPhysAddress.2.10.0.0.15 = 777 "000010987654" ), 778 ( ipNetToMediaType.2.10.0.0.15 = 779 "dynamic" ), 780 ( ipNetToMediaNetAddress.1.9.2.3.4 = 781 "9.2.3.4" ), 782 ( ipRoutingDiscards.0 = "2" )) 784 This response signals the end of the table to the SNMPv2 entity acting 785 in a manager role. 787 4.2.4. The Response-PDU 789 The Response-PDU is generated by a SNMPv2 entity only upon receipt of a 790 GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, 791 or InformRequest-PDU, as described elsewhere in this document. 793 If the error-status field of the Response-PDU is non-zero, the value 794 fields of the variable bindings in the variable binding list are 795 ignored. 797 If both the error-status field and the error-index field of the 798 Response-PDU are non-zero, then the value of the error-index field is 799 the index of the variable binding (in the variable-binding list of the 800 corresponding request) for which the request failed. The first variable 801 binding in a request's variable-binding list is index one, the second is 802 index two, etc. 804 A compliant SNMPv2 entity acting in a manager role must be able to 805 properly receive and handle a Response-PDU with an error-status field 806 equal to `noSuchName', `badValue', or `readOnly'. (See Section 3.1.2 of 807 [10].) 809 Upon receipt of a Response-PDU, the receiving SNMPv2 entity presents its 810 contents to the SNMPv2 application which generated the request with the 811 same request-id value. 813 4.2.5. The SetRequest-PDU 815 A SetRequest-PDU is generated and transmitted at the request of a SNMPv2 816 application. 818 Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity determines 819 the size of a message encapsulating a Response-PDU having the same 820 values in its request-id and variable-bindings fields as the received 821 SetRequest-PDU, and the largest possible sizes of the error-status and 822 error-index fields. If the determined message size is greater than 823 either a local constraint or the maximum message size of the request's 824 source party, then an alternate Response-PDU is generated, transmitted 825 to the originator of the SetRequest-PDU, and processing of the 826 SetRequest-PDU terminates immediately thereafter. This alternate 827 Response-PDU is formatted with the same values in its request-id field 828 as the received SetRequest-PDU, with the value of its error-status field 829 set to `tooBig', the value of its error-index field set to zero, and an 830 empty variable-bindings field. This alternate Response-PDU is then 831 encapsulated into a message. If the size of the resultant message is 832 less than or equal to both a local constraint and the maximum message 833 size of the request's source party, it is transmitted to the originator 834 of the SetRequest-PDU. Otherwise, the snmpStatsSilentDrops [11] counter 835 is incremented and the resultant message is discarded. Regardless, 836 processing of the SetRequest-PDU terminates. 838 Otherwise, the receiving SNMPv2 entity processes each variable binding 839 in the variable-binding list to produce a Response-PDU. All fields of 840 the Response-PDU have the same values as the corresponding fields of the 841 received request except as indicated below. 843 The variable bindings are conceptually processed as a two phase 844 operation. In the first phase, each variable binding is validated; if 845 all validations are successful, then each variable is altered in the 846 second phase. Of course, implementors are at liberty to implement 847 either the first, or second, or both, of the these conceptual phases as 848 multiple implementation phases. Indeed, such multiple implementation 849 phases may be necessary in some cases to ensure consistency. 851 The following validations are performed in the first phase on each 852 variable binding until they are all successful, or until one fails: 854 (1) If the variable binding's name specifies an existing or non- 855 existent variable to which this request is/would be denied access | 856 because it is/would not be in the appropriate MIB view, | 857 then the value of the Response-PDU's error-status field is set to 858 `noAccess', and the value of its error-index field is set to the 859 index of the failed variable binding. 861 (2) Otherwise, if there are no variables which share the same OBJECT 862 IDENTIFIER prefix as the variable binding's name, and which are 863 able to be created or modified no matter what new value is 864 specified, then the value of the Response-PDU's error-status field 865 is set to `notWritable', and the value of its error-index field is 866 set to the index of the failed variable binding. 868 (3) Otherwise, if the variable binding's value field specifies, 869 according to the ASN.1 language, a type which is inconsistent with 870 that required for all variables which share the same OBJECT 871 IDENTIFIER prefix as the variable binding's name, then the value of 872 the Response-PDU's error-status field is set to `wrongType', and 873 the value of its error-index field is set to the index of the 874 failed variable binding. 876 (4) Otherwise, if the variable binding's value field specifies, 877 according to the ASN.1 language, a length which is inconsistent 878 with that required for all variables which share the same OBJECT 879 IDENTIFIER prefix as the variable binding's name, then the value of 880 the Response-PDU's error-status field is set to `wrongLength', and 881 the value of its error-index field is set to the index of the 882 failed variable binding. 884 (5) Otherwise, if the variable binding's value field contains an ASN.1 885 encoding which is inconsistent with that field's ASN.1 tag, then 886 the value of the Response-PDU's error-status field is set to 887 `wrongEncoding', and the value of its error-index field is set to 888 the index of the failed variable binding. (Note that not all 889 implementation strategies will generate this error.) 891 (6) Otherwise, if the variable binding's value field specifies a value 892 which could under no circumstances be assigned to the variable, 893 then the value of the Response-PDU's error-status field is set to 894 `wrongValue', and the value of its error-index field is set to the 895 index of the failed variable binding. 897 (7) Otherwise, if the variable binding's name specifies a variable 898 which does not exist and could not ever be created (even though 899 some variables sharing the same OBJECT IDENTIFIER prefix might 900 under some circumstances be able to be created), then the value of 901 the Response-PDU's error-status field is set to `noCreation', and 902 the value of its error-index field is set to the index of the 903 failed variable binding. 905 (8) Otherwise, if the variable binding's name specifies a variable 906 which does not exist but can not be created under the present 907 circumstances (even though it could be created under other 908 circumstances), then the value of the Response-PDU's error-status 909 field is set to `inconsistentName', and the value of its error- 910 index field is set to the index of the failed variable binding. 912 (9) Otherwise, if the variable binding's name specifies a variable + 913 which exists but can not be modified no matter what new value is + 914 specified, then the value of the Response-PDU's error-status field + 915 is set to `notWritable', and the value of its error-index field is + 916 set to the index of the failed variable binding. + 918 (10) + 919 Otherwise, if the variable binding's value field specifies a value | 920 that could under other circumstances be held by the variable, but | 921 is presently inconsistent or otherwise unable to be assigned to the | 922 variable, then the value of the Response-PDU's | 923 error-status field is set to `inconsistentValue', and the value of 924 its error-index field is set to the index of the failed variable 925 binding. 927 (11) When, during the above steps, the assignment of the value specified 928 by the variable binding's value field to the specified variable 929 requires the allocation of a resource which is presently 930 unavailable, then the value of the Response-PDU's error-status 931 field is set to `resourceUnavailable', and the value of its error- 932 index field is set to the index of the failed variable binding. 934 (12) If the processing of the variable binding fails for a reason other 935 than listed above, then the value of the Response-PDU's error- 936 status field is set to `genErr', and the value of its error-index 937 field is set to the index of the failed variable binding. 939 (13) Otherwise, the validation of the variable binding succeeds. 941 At the end of the first phase, if the validation of all variable 942 bindings succeeded, then the value of the Response-PDU's error-status 943 field is set to `noError' and the value of its error-index field is 944 zero, and processing continues as follows. 946 For each variable binding in the request, the named variable is created 947 if necessary, and the specified value is assigned to it. Each of these 948 variable assignments occurs as if simultaneously with respect to all 949 other assignments specified in the same request. However, if the same 950 variable is named more than once in a single request, with different 951 associated values, then the actual assignment made to that variable is 952 implementation-specific. 954 If any of these assignments fail (even after all the previous 955 validations), then all other assignments are undone, and the Response- 956 PDU is modified to have the value of its error-status field set to 957 `commitFailed', and the value of its error-index field set to the index 958 of the failed variable binding. 960 If and only if it is not possible to undo all the assignments, then the 961 Response-PDU is modified to have the value of its error-status field set 962 to `undoFailed', and the value of its error-index field is set to zero. 963 Note that implementations are strongly encouraged to take all possible 964 measures to avoid use of either `commitFailed' or `undoFailed' - these 965 two error-status codes are not to be taken as license to take the easy 966 way out in an implementation. 968 Finally, the generated Response-PDU is encapsulated into a message, and 969 transmitted to the originator of the SetRequest-PDU. 971 4.2.6. The SNMPv2-Trap-PDU 973 A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2 entity acting 974 in an agent role when an exceptional situation occurs. 976 The destination(s) to which a SNMPv2-Trap-PDU is sent is determined by 977 consulting the acTable [5] to find all entries satisfying the following 978 conditions: 980 (1) The value of acTarget refers to the generating SNMPv2 entity. 982 (2) The value of acPrivileges allows for the SNMPv2-Trap-PDU. 984 (3) The value of acContext refers to a SNMPv2 context denoting local 985 management information. 987 (4) The notification's administratively assigned name is present in the 988 corresponding MIB view. (That is, the set of entries in the 989 viewTable [5] for which the instance of viewIndex has the same 990 value as acReadViewIndex, define a MIB view which contains the 991 notification's administratively assigned name.) 993 (5) If the OBJECTS clause is present in the invocation of the 994 corresponding NOTIFICATION-TYPE macro, then the correspondent 995 variables are all present in the MIB view corresponding to 996 acReadViewIndex. 998 (6) For any additional variables which the generating SNMPv2 entity 999 chooses to include within this SNMPv2-Trap-PDU, then these 1000 variables are all present in the MIB view corresponding to 1001 acReadViewIndex. 1003 Then, for each entry satisfying these conditions, a SNMPv2-Trap-PDU is 1004 sent from acTarget with context acContext to acSubject. The instance of 1005 snmpTrapNumbers [11] corresponding to acSubject is incremented, and is 1006 used as the request-id field of the SNMPv2-Trap-PDU. Then, the 1007 variable-bindings field are constructed as: 1009 (1) The first variable is sysUpTime.0 [11]. 1011 (2) The second variable is snmpTrapOID.0 [11], which contains the 1012 administratively assigned name of the notification. 1014 (3) If the OBJECTS clause is present in the invocation of the 1015 corresponding NOTIFICATION-TYPE macro, then each corresponding 1016 variable is copied, in order, to the variable-bindings field. 1018 (4) If any additional variables are being included (at the option of 1019 the generating SNMPv2 entity), then each is copied to the 1020 variable-bindings field. 1022 4.2.7. The InformRequest-PDU 1024 An InformRequest-PDU is generated and transmitted at the request an 1025 application in a SNMPv2 entity acting in a manager role, that wishes to 1026 notify another application (in a SNMPv2 entity also acting in a manager 1027 role) of information in a MIB View local to the sending application. 1029 The destination(s) to which an InformRequest-PDU is sent is specified by 1030 the requesting application. The first two variable bindings in the 1031 variable binding list of an InformRequest-PDU are sysUpTime.0 [11] and 1032 snmpTrapOID.0 [11] respectively. If the OBJECTS clause is present in 1033 the invocation of the corresponding NOTIFICATION-TYPE macro, then each 1034 corresponding variable, as instantiated by this notification, is copied, 1035 in order, to the variable-bindings field. 1037 Upon receipt of an InformRequest-PDU, the receiving SNMPv2 entity 1038 determines the size of a message encapsulating a Response-PDU with the 1039 same values in its request-id, error-status, error-index and variable- 1040 bindings fields as the received InformRequest-PDU. If the determined 1041 message size is greater than either a local constraint or the maximum 1042 message size of the request's source party, then an alternate Response- 1043 PDU is generated, transmitted to the originator of the InformRequest- 1044 PDU, and processing of the InformRequest-PDU terminates immediately 1045 thereafter. This alternate Response-PDU is formatted with the same 1046 values in its request-id field as the received InformRequest-PDU, with 1047 the value of its error-status field set to `tooBig', the value of its 1048 error-index field set to zero, and an empty variable-bindings field. 1049 This alternate Response-PDU is then encapsulated into a message. If the 1050 size of the resultant message is less than or equal to both a local 1051 constraint and the maximum message size of the request's source party, 1052 it is transmitted to the originator of the InformRequest-PDU. 1053 Otherwise, the snmpStatsSilentDrops [11] counter is incremented and the 1054 resultant message is discarded. Regardless, processing of the 1055 InformRequest-PDU terminates. 1057 Otherwise, the receiving SNMPv2 entity: 1059 (1) presents its contents to the appropriate SNMPv2 application; 1061 (2) generates a Response-PDU with the same values in its request-id and 1062 variable-bindings fields as the received InformRequest-PDU, with 1063 the value of its error-status field is set to `noError' and the 1064 value of its error-index field is zero; and 1066 (3) transmits the generated Response-PDU to the originator of the 1067 InformRequest-PDU. 1069 5. Acknowledgements 1071 The authors wish to acknowledge the contributions of the SNMPv2 Working 1072 Group in general. In particular, the following individuals 1074 Dave Arneson (Cabletron), 1075 Uri Blumenthal (IBM), 1076 Doug Book (Chipcom), 1077 Maria Greene (Ascom Timeplex), 1078 Deirdre Kostik (Bellcore), 1079 Dave Harrington (Cabletron), 1080 Jeff Johnson (Cisco Systems), 1081 Brian O'Keefe (Hewlett Packard), 1082 Dave Perkins (Bay Networks), 1083 Randy Presuhn (Peer Networks), 1084 Shawn Routhier (Epilogue), 1085 Bob Stewart (Cisco Systems), 1086 Kaj Tesink (Bellcore). 1088 deserve special thanks for their contributions. 1090 6. References 1092 [1] Information processing systems - Open Systems Interconnection - 1093 Specification of Abstract Syntax Notation One (ASN.1), 1094 International Organization for Standardization. International 1095 Standard 8824, (December, 1987). 1097 [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure 1098 of Management Information for Version 2 of the Simple Network 1099 Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., 1100 Cisco Systems, Dover Beach Consulting, Inc., Carnegie Mellon 1101 University, May 1995. | 1103 [3] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., 1104 "Administrative Infrastructure for Version 2 of the Simple Network 1105 Management Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., 1106 Trusted Information Systems, Cisco Systems, Dover Beach Consulting, 1107 Inc., Carnegie Mellon University, May 1995. | 1109 [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Textual 1110 Conventions for Version 2 of the the Simple Network Management 1111 Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco 1112 Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, | 1113 May 1995. | 1115 [5] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S., 1116 "Party MIB for Version 2 of the Simple Network Management Protocol 1117 (SNMPv2)", Internet Draft, SNMP Research, Inc., Trusted Information 1118 Systems, Cisco Systems, Dover Beach Consulting, Inc., Carnegie 1119 Mellon University, May 1995. | 1121 [6] C. Kent, J. Mogul, Fragmentation Considered Harmful, Proceedings, 1122 ACM SIGCOMM '87, Stowe, VT, (August 1987). 1124 [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport 1125 Mappings for Version 2 of the Simple Network Management Protocol 1126 (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, 1127 Dover Beach Consulting, Inc., Carnegie Mellon University, May 1995. | 1129 [8] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1130 USC/Information Sciences Institute, August 1980. 1132 [9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "SNMPv2 1133 Management Information Base for the Internet Protocol", Internet 1134 Draft, SNMP Research, Inc., Cisco Systems, Dover Beach Consulting, 1135 Inc., Carnegie Mellon University, May 1995. | 1137 [10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., 1138 "Coexistence between Version 1 and Version 2 of the Internet- 1139 standard Network Management Framework", Internet Draft, SNMP 1140 Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., 1141 Carnegie Mellon University, May 1995. | 1143 [11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management 1144 Information Base for Version 2 of the Simple Network Management 1145 Protocol (SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco 1146 Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, | 1147 May 1995. | 1149 [12] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Manager- 1150 to-Manager Management Information Base", Internet Draft, SNMP 1151 Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., 1152 Carnegie Mellon University, May 1995. | 1154 7. Security Considerations 1156 Security issues are not discussed in this memo. 1158 8. Authors' Addresses 1160 Jeffrey D. Case 1161 SNMP Research, Inc. 1162 3001 Kimberlin Heights Rd. 1163 Knoxville, TN 37920-9716 1164 US 1166 Phone: +1 615 573 1434 1167 Email: case@snmp.com 1169 Keith McCloghrie 1170 Cisco Systems, Inc. 1171 170 West Tasman Drive, 1172 San Jose CA 95134-1706. 1174 Phone: +1 408 526 5260 1175 Email: kzm@cisco.com 1177 Marshall T. Rose 1178 Dover Beach Consulting, Inc. 1179 420 Whisman Court 1180 Mountain View, CA 94043-2186 1181 US 1183 Phone: +1 415 968 1052 1184 Email: mrose@dbc.mtview.ca.us 1186 Steven Waldbusser 1187 Carnegie Mellon University 1188 5000 Forbes Ave 1189 Pittsburgh, PA 15213 1190 US 1192 Phone: +1 412 268 6628 1193 Email: waldbusser@cmu.edu 1195 Table of Contents 1197 1 Introduction .................................................... 3 1198 1.1 A Note on Terminology ......................................... 3 1199 2 Overview ........................................................ 4 1200 2.1 Roles of Protocol Entities .................................... 4 1201 2.2 Management Information ........................................ 4 1202 2.3 Access to Management Information .............................. 5 1203 2.4 Retransmission of Requests .................................... 5 1204 2.5 Message Sizes ................................................. 5 1205 2.6 Transport Mappings ............................................ 6 1206 3 Definitions ..................................................... 7 1207 4 Protocol Specification .......................................... 12 1208 4.1 Common Constructs ............................................. 12 1209 4.2 PDU Processing ................................................ 12 1210 4.2.1 The GetRequest-PDU .......................................... 13 1211 4.2.2 The GetNextRequest-PDU ...................................... 14 1212 4.2.2.1 Example of Table Traversal ................................ 15 1213 4.2.3 The GetBulkRequest-PDU ...................................... 17 1214 4.2.3.1 Another Example of Table Traversal ........................ 20 1215 4.2.4 The Response-PDU ............................................ 21 1216 4.2.5 The SetRequest-PDU .......................................... 22 1217 4.2.6 The SNMPv2-Trap-PDU ......................................... 25 1218 4.2.7 The InformRequest-PDU ....................................... 27 1219 5 Acknowledgements ................................................ 29 1220 6 References ...................................................... 29 1221 7 Security Considerations ......................................... 31 1222 8 Authors' Addresses .............................................. 31