doc/rfc/rfc1448.txt

   1
   2
   3
   4           Network Working Group                                  J. Case
   5           Request for Comments: 1448                 SNMP Research, Inc.
   6                                                            K. McCloghrie
   7                                                       Hughes LAN Systems
   8                                                                  M. Rose
   9                                             Dover Beach Consulting, Inc.
  10                                                            S. Waldbusser
  11                                               Carnegie Mellon University
  12                                                               April 1993
  13
  14
  15                                Protocol Operations
  16                                for version 2 of the
  17                    Simple Network Management Protocol (SNMPv2)
  18
  19
  20           Status of this Memo
  21
  22           This RFC specifes an IAB standards track protocol for the
  23           Internet community, and requests discussion and suggestions
  24           for improvements.  Please refer to the current edition of the
  25           "IAB Official Protocol Standards" for the standardization
  26           state and status of this protocol.  Distribution of this memo
  27           is unlimited.
  28
  29
  30           Table of Contents
  31
  32           1 Introduction ..........................................    2
  33           1.1 A Note on Terminology ...............................    2
  34           2 Overview ..............................................    3
  35           2.1 Roles of Protocol Entities ..........................    3
  36           2.2 Management Information ..............................    3
  37           2.3 Access to Management Information ....................    4
  38           2.4 Retransmission of Requests ..........................    4
  39           2.5 Message Sizes .......................................    5
  40           2.6 Transport Mappings ..................................    6
  41           3 Definitions ...........................................    7
  42           4 Protocol Specification ................................   12
  43           4.1 Common Constructs ...................................   12
  44           4.2 PDU Processing ......................................   12
  45           4.2.1 The GetRequest-PDU ................................   13
  46           4.2.2 The GetNextRequest-PDU ............................   15
  47           4.2.2.1 Example of Table Traversal ......................   16
  48           4.2.3 The GetBulkRequest-PDU ............................   18
  49           4.2.3.1 Another Example of Table Traversal ..............   21
  50           4.2.4 The Response-PDU ..................................   22
  51           4.2.5 The SetRequest-PDU ................................   23
  52           4.2.6 The SNMPv2-Trap-PDU ...............................   26
  53           4.2.7 The InformRequest-PDU .............................   27
  54
  55
  56
  57
  58
  59           Case, McCloghrie, Rose & Waldbusser                   [Page i]
  60 \f
  61
  62
  63
  64
  65           RFC 1448        Protocol Operations for SNMPv2      April 1993
  66
  67
  68           5 Acknowledgements ......................................   29
  69           6 References ............................................   33
  70           7 Security Considerations ...............................   35
  71           8 Authors' Addresses ....................................   35
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114
 115
 116
 117
 118           Case, McCloghrie, Rose & Waldbusser                   [Page 1]
 119 \f
 120
 121
 122
 123
 124           RFC 1448        Protocol Operations for SNMPv2      April 1993
 125
 126
 127           1.  Introduction
 128
 129           A network management system contains: several (potentially
 130           many) nodes, each with a processing entity, termed an agent,
 131           which has access to management instrumentation; at least one
 132           management station; and, a management protocol, used to convey
 133           management information between the agents and management
 134           stations.  Operations of the protocol are carried out under an
 135           administrative framework which defines both authentication and
 136           authorization policies.
 137
 138           Network management stations execute management applications
 139           which monitor and control network elements.  Network elements
 140           are devices such as hosts, routers, terminal servers, etc.,
 141           which are monitored and controlled through access to their
 142           management information.
 143
 144           Management information is viewed as a collection of managed
 145           objects, residing in a virtual information store, termed the
 146           Management Information Base (MIB).  Collections of related
 147           objects are defined in MIB modules.  These modules are written
 148           using a subset of OSI's Abstract Syntax Notation One (ASN.1)
 149           [1], termed the Structure of Management Information (SMI) [2].
 150
 151           The management protocol, version 2 of the Simple Network
 152           Management Protocol, provides for the exchange of messages
 153           which convey management information between the agents and the
 154           management stations.  The form of these messages is a message
 155           "wrapper" which encapsulates a Protocol Data Unit (PDU).  The
 156           form and meaning of the "wrapper" is determined by an
 157           administrative framework which defines both authentication and
 158           authorization policies.
 159
 160           It is the purpose of this document, Protocol Operations for
 161           SNMPv2, to define the operations of the protocol with respect
 162           to the sending and receiving of the PDUs.
 163
 164
 165           1.1.  A Note on Terminology
 166
 167           For the purpose of exposition, the original Internet-standard
 168           Network Management Framework, as described in RFCs 1155, 1157,
 169           and 1212, is termed the SNMP version 1 framework (SNMPv1).
 170           The current framework is termed the SNMP version 2 framework
 171           (SNMPv2).
 172
 173
 174
 175
 176
 177           Case, McCloghrie, Rose & Waldbusser                   [Page 2]
 178 \f
 179
 180
 181
 182
 183           RFC 1448        Protocol Operations for SNMPv2      April 1993
 184
 185
 186           2.  Overview
 187
 188           2.1.  Roles of Protocol Entities
 189
 190           A SNMPv2 entity may operate in a manager role or an agent
 191           role.
 192
 193           A SNMPv2 entity acts in an agent role when it performs SNMPv2
 194           management operations in response to received SNMPv2 protocol
 195           messages (other than an inform notification) or when it sends
 196           trap notifications.
 197
 198           A SNMPv2 entity acts in a manager role when it initiates
 199           SNMPv2 management operations by the generation of SNMPv2
 200           protocol messages or when it performs SNMPv2 management
 201           operations in response to received trap or inform
 202           notifications.
 203
 204           A SNMPv2 entity may support either or both roles, as dictated
 205           by its implementation and configuration.  Further, a SNMPv2
 206           entity can also act in the role of a proxy agent, in which it
 207           appears to be acting in an agent role, but satisfies
 208           management requests by acting in a manager role with a remote
 209           entity.  The use of proxy agents and the transparency
 210           principle that defines their behavior is described in [3].
 211
 212
 213           2.2.  Management Information
 214
 215           The term, variable, refers to an instance of a non-aggregate
 216           object type defined according to the conventions set forth in
 217           the SMI [2] or the textual conventions based on the SMI [4].
 218           The term, variable binding, normally refers to the pairing of
 219           the name of a variable and its associated value.  However, if
 220           certain kinds of exceptional conditions occur during
 221           processing of a retrieval request, a variable binding will
 222           pair a name and an indication of that exception.
 223
 224           A variable-binding list is a simple list of variable bindings.
 225
 226           The name of a variable is an OBJECT IDENTIFIER which is the
 227           concatenation of the OBJECT IDENTIFIER of the corresponding
 228           object-type together with an OBJECT IDENTIFIER fragment
 229           identifying the instance.  The OBJECT IDENTIFIER of the
 230           corresponding object-type is called the OBJECT IDENTIFIER
 231
 232
 233
 234
 235
 236           Case, McCloghrie, Rose & Waldbusser                   [Page 3]
 237 \f
 238
 239
 240
 241
 242           RFC 1448        Protocol Operations for SNMPv2      April 1993
 243
 244
 245           prefix of the variable.
 246
 247
 248           2.3.  Access to Management Information
 249
 250           Three types of access to management information are provided
 251           by the protocol.  One type is a request-response interaction,
 252           in which a SNMPv2 entity, acting in a manager role, sends a
 253           request to a SNMPv2 entity, acting in an agent role, and the
 254           latter SNMPv2 entity then responds to the request.  This type
 255           is used to retrieve or modify management information
 256           associated with the managed device.
 257
 258           A second type is also a request-response interaction, in which
 259           a SNMPv2 entity, acting in a manager role, sends a request to
 260           a SNMPv2 entity, also acting in a manager role, and the latter
 261           SNMPv2 entity then responds to the request.  This type is used
 262           to notify a SNMPv2 entity, acting in a manager role, of
 263           management information associated with another SNMPv2 entity,
 264           also acting in a manager role.
 265
 266           The third type of access is an unconfirmed interaction, in
 267           which a SNMPv2 entity, acting in an agent role, sends a
 268           unsolicited message, termed a trap, to a SNMPv2 entity, acting
 269           in a manager role, and no response is returned.  This type is
 270           used to notify a SNMPv2 entity, acting in a manager role, of
 271           an exceptional situation, which has resulted in changes to
 272           management information associated with the managed device.
 273
 274
 275           2.4.  Retransmission of Requests
 276
 277           For all types of request in this protocol, the receiver is
 278           required under normal circumstances, to generate and transmit
 279           a response to the originator of the request.  Whether or not a
 280           request should be retransmitted if no corresponding response
 281           is received in an appropriate time interval, is at the
 282           discretion of the application originating the request.  This
 283           will normally depend on the urgency of the request.  However,
 284           such an application needs to act responsibly in respect to the
 285           frequency and duration of re-transmissions.
 286
 287
 288
 289
 290
 291
 292
 293
 294
 295           Case, McCloghrie, Rose & Waldbusser                   [Page 4]
 296 \f
 297
 298
 299
 300
 301           RFC 1448        Protocol Operations for SNMPv2      April 1993
 302
 303
 304           2.5.  Message Sizes
 305
 306           The maximum size of a SNMPv2 message is limited the minimum
 307           of:
 308
 309           (1)  the maximum message size which the destination SNMPv2
 310                entity can accept; and,
 311
 312           (2)  the maximum message size which the source SNMPv2 entity
 313                can generate.
 314
 315           The former is indicated by partyMaxMessageSize[5] of the
 316           destination party.  The latter is imposed by implementation-
 317           specific local constraints.
 318
 319           Each transport mapping for the SNMPv2 indicates the minimum
 320           message size which a SNMPv2 implementation must be able to
 321           produce or consume.  Although implementations are encouraged
 322           to support larger values whenever possible, a conformant
 323           implementation must never generate messages larger than
 324           allowed by the receiving SNMPv2 entity.
 325
 326           One of the aims of the GetBulkRequest-PDU, specified in this
 327           protocol, is to minimize the number of protocol exchanges
 328           required to retrieve a large amount of management information.
 329           As such, this PDU type allows a SNMPv2 entity acting in a
 330           manager role to request that the response be as large as
 331           possible given the constraints on message sizes.  These
 332           constraints include the limits on the size of messages which
 333           the SNMPv2 entity acting in an agent role can generate, and
 334           the SNMPv2 entity acting in a manager role can receive.
 335
 336           However, it is possible that such maximum sized messages may
 337           be larger than the Path MTU of the path across the network
 338           traversed by the messages.  In this situation, such messages
 339           are subject to fragmentation.  Fragmentation is generally
 340           considered to be harmful [6], since among other problems, it
 341           leads to a decrease in the reliability of the transfer of the
 342           messages.  Thus, a SNMPv2 entity which sends a
 343           GetBulkRequest-PDU must take care to set its parameters
 344           accordingly, so as to reduce the risk of fragmentation.  In
 345           particular, under conditions of network stress, only small
 346           values should be used for max-repetitions.
 347
 348
 349
 350
 351
 352
 353
 354           Case, McCloghrie, Rose & Waldbusser                   [Page 5]
 355 \f
 356
 357
 358
 359
 360           RFC 1448        Protocol Operations for SNMPv2      April 1993
 361
 362
 363           2.6.  Transport Mappings
 364
 365           It is important to note that the exchange of SNMPv2 messages
 366           requires only an unreliable datagram service, with every
 367           message being entirely and independently contained in a single
 368           transport datagram.  Specific transport mappings and encoding
 369           rules are specified elsewhere [7].  However, the preferred
 370           mapping is the use of the User Datagram Protocol [8].
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394
 395
 396
 397
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413           Case, McCloghrie, Rose & Waldbusser                   [Page 6]
 414 \f
 415
 416
 417
 418
 419           RFC 1448        Protocol Operations for SNMPv2      April 1993
 420
 421
 422           3.  Definitions
 423
 424                SNMPv2-PDU DEFINITIONS ::= BEGIN
 425
 426                IMPORTS
 427                    ObjectName, ObjectSyntax, Integer32
 428                        FROM SNMPv2-SMI;
 429
 430
 431                -- protocol data units
 432
 433                PDUs ::=
 434                    CHOICE {
 435                        get-request
 436                            GetRequest-PDU,
 437
 438                        get-next-request
 439                            GetNextRequest-PDU,
 440
 441                        get-bulk-request
 442                            GetBulkRequest-PDU,
 443
 444                        response
 445                            Response-PDU,
 446
 447                        set-request
 448                            SetRequest-PDU,
 449
 450                        inform-request
 451                            InformRequest-PDU,
 452
 453                        snmpV2-trap
 454                            SNMPv2-Trap-PDU
 455                    }
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 468
 469
 470
 471
 472           Case, McCloghrie, Rose & Waldbusser                   [Page 7]
 473 \f
 474
 475
 476
 477
 478           RFC 1448        Protocol Operations for SNMPv2      April 1993
 479
 480
 481                -- PDUs
 482
 483                GetRequest-PDU ::=
 484                    [0]
 485                        IMPLICIT PDU
 486
 487                GetNextRequest-PDU ::=
 488                    [1]
 489                        IMPLICIT PDU
 490
 491                Response-PDU ::=
 492                    [2]
 493                        IMPLICIT PDU
 494
 495                SetRequest-PDU ::=
 496                    [3]
 497                        IMPLICIT PDU
 498
 499                -- [4] is obsolete
 500
 501                GetBulkRequest-PDU ::=
 502                    [5]
 503                        IMPLICIT BulkPDU
 504
 505                InformRequest-PDU ::=
 506                    [6]
 507                        IMPLICIT PDU
 508
 509                SNMPv2-Trap-PDU ::=
 510                    [7]
 511                        IMPLICIT PDU
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531           Case, McCloghrie, Rose & Waldbusser                   [Page 8]
 532 \f
 533
 534
 535
 536
 537           RFC 1448        Protocol Operations for SNMPv2      April 1993
 538
 539
 540                max-bindings
 541                    INTEGER ::= 2147483647
 542
 543                PDU ::=
 544                    SEQUENCE {
 545                        request-id
 546                            Integer32,
 547
 548                        error-status            -- sometimes ignored
 549                            INTEGER {
 550                                noError(0),
 551                                tooBig(1),
 552                                noSuchName(2),   -- for proxy compatibility
 553                                badValue(3),     -- for proxy compatibility
 554                                readOnly(4),     -- for proxy compatibility
 555                                genErr(5),
 556                                noAccess(6),
 557                                wrongType(7),
 558                                wrongLength(8),
 559                                wrongEncoding(9),
 560                                wrongValue(10),
 561                                noCreation(11),
 562                                inconsistentValue(12),
 563                                resourceUnavailable(13),
 564                                commitFailed(14),
 565                                undoFailed(15),
 566                                authorizationError(16),
 567                                notWritable(17),
 568                                inconsistentName(18)
 569                            },
 570
 571                        error-index            -- sometimes ignored
 572                            INTEGER (0..max-bindings),
 573
 574                        variable-bindings   -- values are sometimes ignored
 575                            VarBindList
 576                    }
 577
 578
 579
 580
 581
 582
 583
 584
 585
 586
 587
 588
 589
 590           Case, McCloghrie, Rose & Waldbusser                   [Page 9]
 591 \f
 592
 593
 594
 595
 596           RFC 1448        Protocol Operations for SNMPv2      April 1993
 597
 598
 599                BulkPDU ::=                     -- MUST be identical in
 600                    SEQUENCE {                  -- structure to PDU
 601                        request-id
 602                            Integer32,
 603
 604                        non-repeaters
 605                            INTEGER (0..max-bindings),
 606
 607                        max-repetitions
 608                            INTEGER (0..max-bindings),
 609
 610                        variable-bindings       -- values are ignored
 611                            VarBindList
 612                    }
 613
 614
 615
 616
 617
 618
 619
 620
 621
 622
 623
 624
 625
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649           Case, McCloghrie, Rose & Waldbusser                  [Page 10]
 650 \f
 651
 652
 653
 654
 655           RFC 1448        Protocol Operations for SNMPv2      April 1993
 656
 657
 658                -- variable binding
 659
 660                VarBind ::=
 661                    SEQUENCE {
 662                        name
 663                            ObjectName,
 664
 665                        CHOICE {
 666                            value
 667                                ObjectSyntax,
 668
 669                            unSpecified         -- in retrieval requests
 670                                    NULL,
 671
 672                                                -- exceptions in responses
 673                            noSuchObject[0]
 674                                    IMPLICIT NULL,
 675
 676                            noSuchInstance[1]
 677                                    IMPLICIT NULL,
 678
 679                            endOfMibView[2]
 680                                    IMPLICIT NULL
 681                        }
 682                    }
 683
 684
 685                -- variable-binding list
 686
 687                VarBindList ::=
 688                    SEQUENCE (SIZE (0..max-bindings)) OF
 689                        VarBind
 690
 691
 692                END
 693
 694
 695
 696
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708           Case, McCloghrie, Rose & Waldbusser                  [Page 11]
 709 \f
 710
 711
 712
 713
 714           RFC 1448        Protocol Operations for SNMPv2      April 1993
 715
 716
 717           4.  Protocol Specification
 718
 719
 720           4.1.  Common Constructs
 721
 722           The value of the request-id field in a Response-PDU takes the
 723           value of the request-id field in the request PDU to which it
 724           is a response.  By use of the request-id value, a SNMPv2
 725           application can distinguish the (potentially multiple)
 726           outstanding requests, and thereby correlate incoming responses
 727           with outstanding requests.  In cases where an unreliable
 728           datagram service is used, the request-id also provides a
 729           simple means of identifying messages duplicated by the
 730           network.  Use of the same request-id on a retransmission of a
 731           request allows the response to either the original
 732           transmission or the retransmission to satisfy the request.
 733           However, in order to calculate the round trip time for
 734           transmission and processing of a request-response transaction,
 735           the SNMPv2 application needs to use a different request-id
 736           value on a retransmitted request.  The latter strategy is
 737           recommended for use in the majority of situations.
 738
 739           A non-zero value of the error-status field in a Response-PDU
 740           is used to indicate that an exception occurred to prevent the
 741           processing of the request.  In these cases, a non-zero value
 742           of the Response-PDU's error-index field provides additional
 743           information by identifying which variable binding in the list
 744           caused the exception.  A variable binding is identified by its
 745           index value.  The first variable binding in a variable-binding
 746           list is index one, the second is index two, etc.
 747
 748           SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128
 749           sub-identifiers, where each sub-identifier has a maximum value
 750           of 2**32-1.
 751
 752
 753           4.2.  PDU Processing
 754
 755           It is mandatory that all SNMPv2 entities acting in an agent
 756           role be able to generate the following PDU types: Response-PDU
 757           and SNMPv2-Trap-PDU; further, all such implementations must be
 758           able to receive the following PDU types: GetRequest-PDU,
 759           GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU.
 760
 761
 762
 763
 764
 765
 766
 767           Case, McCloghrie, Rose & Waldbusser                  [Page 12]
 768 \f
 769
 770
 771
 772
 773           RFC 1448        Protocol Operations for SNMPv2      April 1993
 774
 775
 776           It is mandatory that all SNMPv2 entities acting in a manager
 777           role be able to generate the following PDU types: GetRequest-
 778           PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
 779           InformRequest-PDU, and Response-PDU; further, all such
 780           implementations must be able to receive the following PDU
 781           types: Response-PDU, SNMPv2-Trap-PDU, InformRequest-PDU;
 782
 783           In the elements of procedure below, any field of a PDU which
 784           is not referenced by the relevant procedure is ignored by the
 785           receiving SNMPv2 entity.  However, all components of a PDU,
 786           including those whose values are ignored by the receiving
 787           SNMPv2 entity, must have valid ASN.1 syntax and encoding.  For
 788           example, some PDUs (e.g., the GetRequest-PDU) are concerned
 789           only with the name of a variable and not its value.  In this
 790           case, the value portion of the variable binding is ignored by
 791           the receiving SNMPv2 entity.  The unSpecified value is defined
 792           for use as the value portion of such bindings.
 793
 794           For all generated PDUs, the message "wrapper" to encapsulate
 795           the PDU is generated and transmitted as specified in [3].  The
 796           size of a message is limited only by constraints on the
 797           maximum message size, either a local limitation or the limit
 798           associated with the message's destination party, i.e., it is
 799           not limited by the number of variable bindings.
 800
 801           On receiving a management communication, the procedures
 802           defined in Section 3.2 of [3] are followed.  If these
 803           procedures indicate that the PDU contained within the message
 804           "wrapper" is to be processed, then the SNMPv2 context
 805           associated with the PDU defines the object resources which are
 806           visible to the operation.
 807
 808
 809           4.2.1.  The GetRequest-PDU
 810
 811           A GetRequest-PDU is generated and transmitted at the request
 812           of a SNMPv2 application.
 813
 814           Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity
 815           processes each variable binding in the variable-binding list
 816           to produce a Response-PDU.  All fields of the Response-PDU
 817           have the same values as the corresponding fields of the
 818           received request except as indicated below.  Each variable
 819           binding is processed as follows:
 820
 821
 822
 823
 824
 825
 826           Case, McCloghrie, Rose & Waldbusser                  [Page 13]
 827 \f
 828
 829
 830
 831
 832           RFC 1448        Protocol Operations for SNMPv2      April 1993
 833
 834
 835           (1)  If the variable binding's name does not have an OBJECT
 836                IDENTIFIER prefix which exactly matches the OBJECT
 837                IDENTIFIER prefix of any variable accessible by this
 838                request, then its value field is set to `noSuchObject'.
 839
 840           (2)  Otherwise, if the variable binding's name does not
 841                exactly match the name of a variable accessible by this
 842                request, then its value field is set to `noSuchInstance'.
 843
 844           (3)  Otherwise, the variable binding's value field is set to
 845                the value of the named variable.
 846
 847           If the processing of any variable binding fails for a reason
 848           other than listed above, then the Response-PDU is re-formatted
 849           with the same values in its request-id and variable-bindings
 850           fields as the received GetRequest-PDU, with the value of its
 851           error-status field set to `genErr', and the value of its
 852           error-index field is set to the index of the failed variable
 853           binding.
 854
 855           Otherwise, the value of the Response-PDU's error-status field
 856           is set to `noError', and the value of its error-index field is
 857           zero.
 858
 859           The generated Response-PDU is then encapsulated into a
 860           message.  If the size of the resultant message is less than or
 861           equal to both a local constraint and the maximum message size
 862           of the request's source party, it is transmitted to the
 863           originator of the GetRequest-PDU.
 864
 865           Otherwise, an alternate Response-PDU is generated.  This
 866           alternate Response-PDU is formatted with the same value in its
 867           request-id field as the received GetRequest-PDU, with the
 868           value of its error-status field set to `tooBig', the value of
 869           its error-index field set to zero, and an empty variable-
 870           bindings field.  This alternate Response-PDU is then
 871           encapsulated into a message.  If the size of the resultant
 872           message is less than or equal to both a local constraint and
 873           the maximum message size of the request's source party, it is
 874           transmitted to the originator of the GetRequest-PDU.
 875           Otherwise, the resultant message is discarded.
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885           Case, McCloghrie, Rose & Waldbusser                  [Page 14]
 886 \f
 887
 888
 889
 890
 891           RFC 1448        Protocol Operations for SNMPv2      April 1993
 892
 893
 894           4.2.2.  The GetNextRequest-PDU
 895
 896           A GetNextRequest-PDU is generated and transmitted at the
 897           request of a SNMPv2 application.
 898
 899           Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2
 900           entity processes each variable binding in the variable-binding
 901           list to produce a Response-PDU.  All fields of the Response-
 902           PDU have the same values as the corresponding fields of the
 903           received request except as indicated below.  Each variable
 904           binding is processed as follows:
 905
 906           (1)  The variable is located which is in the lexicographically
 907                ordered list of the names of all variables which are
 908                accessible by this request and whose name is the first
 909                lexicographic successor of the variable binding's name in
 910                the incoming GetNextRequest-PDU.  The corresponding
 911                variable binding's name and value fields in the
 912                Response-PDU are set to the name and value of the located
 913                variable.
 914
 915           (2)  If the requested variable binding's name does not
 916                lexicographically precede the name of any variable
 917                accessible by this request, i.e., there is no
 918                lexicographic successor, then the corresponding variable
 919                binding produced in the Response-PDU has its value field
 920                set to 'endOfMibView', and its name field set to the
 921                variable binding's name in the request.
 922
 923           If the processing of any variable binding fails for a reason
 924           other than listed above, then the Response-PDU is re-formatted
 925           with the same values in its request-id and variable-bindings
 926           fields as the received GetNextRequest-PDU, with the value of
 927           its error-status field set to `genErr', and the value of its
 928           error-index field is set to the index of the failed variable
 929           binding.
 930
 931           Otherwise, the value of the Response-PDU's error-status field
 932           is set to `noError', and the value of its error-index field is
 933           zero.
 934
 935           The generated Response-PDU is then encapsulated into a
 936           message.  If the size of the resultant message is less than or
 937           equal to both a local constraint and the maximum message size
 938           of the request's source party, it is transmitted to the
 939
 940
 941
 942
 943
 944           Case, McCloghrie, Rose & Waldbusser                  [Page 15]
 945 \f
 946
 947
 948
 949
 950           RFC 1448        Protocol Operations for SNMPv2      April 1993
 951
 952
 953           originator of the GetNextRequest-PDU.
 954
 955           Otherwise, an alternate Response-PDU is generated.  This
 956           alternate Response-PDU is formatted with the same values in
 957           its request-id field as the received GetNextRequest-PDU, with
 958           the value of its error-status field set to `tooBig', the value
 959           of its error-index field set to zero, and an empty variable-
 960           bindings field.  This alternate Response-PDU is then
 961           encapsulated into a message.  If the size of the resultant
 962           message is less than or equal to both a local constraint and
 963           the maximum message size of the request's source party, it is
 964           transmitted to the originator of the GetNextRequest-PDU.
 965           Otherwise, the resultant message is discarded.
 966
 967
 968           4.2.2.1.  Example of Table Traversal
 969
 970           An important use of the GetNextRequest-PDU is the traversal of
 971           conceptual tables of information within a MIB.  The semantics
 972           of this type of request, together with the method of
 973           identifying individual instances of objects in the MIB,
 974           provides access to related objects in the MIB as if they
 975           enjoyed a tabular organization.
 976
 977           In the protocol exchange sketched below, a SNMPv2 application
 978           retrieves the media-dependent physical address and the
 979           address-mapping type for each entry in the IP net-to-media
 980           Address Translation Table [9] of a particular network element.
 981           It also retrieves the value of sysUpTime [9], at which the
 982           mappings existed.  Suppose that the agent's IP net-to-media
 983           table has three entries:
 984
 985             Interface-Number  Network-Address  Physical-Address  Type
 986
 987                    1            10.0.0.51     00:00:10:01:23:45  static
 988                    1             9.2.3.4      00:00:10:54:32:10  dynamic
 989                    2            10.0.0.15     00:00:10:98:76:54  dynamic
 990
 991           The SNMPv2 entity acting in a manager role begins by sending a
 992           GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER
 993           values as the requested variable names:
 994
 995               GetNextRequest ( sysUpTime,
 996                                ipNetToMediaPhysAddress,
 997                                ipNetToMediaType )
 998
 999
1000
1001
1002
1003           Case, McCloghrie, Rose & Waldbusser                  [Page 16]
1004 \f
1005
1006
1007
1008
1009           RFC 1448        Protocol Operations for SNMPv2      April 1993
1010
1011
1012           The SNMPv2 entity acting in an agent role responds with a
1013           Response-PDU:
1014
1015               Response (( sysUpTime.0 =  "123456" ),
1016                         ( ipNetToMediaPhysAddress.1.9.2.3.4 =
1017                                                    "000010543210" ),
1018                         ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ))
1019
1020           The SNMPv2 entity acting in a manager role continues with:
1021
1022               GetNextRequest ( sysUpTime,
1023                                ipNetToMediaPhysAddress.1.9.2.3.4,
1024                                ipNetToMediaType.1.9.2.3.4 )
1025
1026           The SNMPv2 entity acting in an agent role responds with:
1027
1028               Response (( sysUpTime.0 =  "123461" ),
1029                         ( ipNetToMediaPhysAddress.1.10.0.0.51 =
1030                                                     "000010012345" ),
1031                         ( ipNetToMediaType.1.10.0.0.51 =  "static" ))
1032
1033           The SNMPv2 entity acting in a manager role continues with:
1034
1035               GetNextRequest ( sysUpTime,
1036                                ipNetToMediaPhysAddress.1.10.0.0.51,
1037                                ipNetToMediaType.1.10.0.0.51 )
1038
1039           The SNMPv2 entity acting in an agent role responds with:
1040
1041               Response (( sysUpTime.0 =  "123466" ),
1042                         ( ipNetToMediaPhysAddress.2.10.0.0.15 =
1043                                                      "000010987654" ),
1044                         ( ipNetToMediaType.2.10.0.0.15 =  "dynamic" ))
1045
1046           The SNMPv2 entity acting in a manager role continues with:
1047
1048               GetNextRequest ( sysUpTime,
1049                                ipNetToMediaPhysAddress.2.10.0.0.15,
1050                                ipNetToMediaType.2.10.0.0.15 )
1051
1052           As there are no further entries in the table, the SNMPv2
1053           entity acting in an agent role responds with the variables
1054           that are next in the lexicographical ordering of the
1055           accessible object names, for example:
1056
1057
1058
1059
1060
1061
1062           Case, McCloghrie, Rose & Waldbusser                  [Page 17]
1063 \f
1064
1065
1066
1067
1068           RFC 1448        Protocol Operations for SNMPv2      April 1993
1069
1070
1071               Response (( sysUpTime.0 =  "123471" ),
1072                         ( ipNetToMediaNetAddress.1.9.2.3.4 =
1073                                                          "9.2.3.4" ),
1074                         ( ipRoutingDiscards.0 =  "2" ))
1075
1076           This response signals the end of the table to the SNMPv2
1077           entity acting in a manager role.
1078
1079
1080           4.2.3.  The GetBulkRequest-PDU
1081
1082           A GetBulkRequest-PDU is generated and transmitted at the
1083           request of a SNMPv2 application.  The purpose of the
1084           GetBulkRequest-PDU is to request the transfer of a potentially
1085           large amount of data, including, but not limited to, the
1086           efficient and rapid retrieval of large tables.
1087
1088           Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2
1089           entity processes each variable binding in the variable-binding
1090           list to produce a Response-PDU with its request-id field
1091           having the same value as in the request.  Processing begins by
1092           examining the values in the non-repeaters and max-repetitions
1093           fields.  If the value in the non-repeaters field is less than
1094           zero, then the value of the field is set to zero.  Similarly,
1095           if the value in the max-repetitions field is less than zero,
1096           then the value of the field is set to zero.
1097
1098           For the GetBulkRequest-PDU type, the successful processing of
1099           each variable binding in the request generates zero or more
1100           variable bindings in the Response-PDU.  That is, the one-to-
1101           one mapping between the variable bindings of the GetRequest-
1102           PDU, GetNextRequest-PDU, and SetRequest-PDU types and the
1103           resultant Response-PDUs does not apply for the mapping between
1104           the variable bindings of a GetBulkRequest-PDU and the
1105           resultant Response-PDU.
1106
1107           The values of the non-repeaters and max-repetitions fields in
1108           the request specify the processing requested.  One variable
1109           binding in the Response-PDU is requested for the first N
1110           variable bindings in the request and M variable bindings are
1111           requested for each of the R remaining variable bindings in the
1112           request.  Consequently, the total number of requested variable
1113           bindings communicated by the request is given by N + (M * R),
1114           where N is the minimum of: a) the value of the non-repeaters
1115           field in the request, and b) the number of variable bindings
1116
1117
1118
1119
1120
1121           Case, McCloghrie, Rose & Waldbusser                  [Page 18]
1122 \f
1123
1124
1125
1126
1127           RFC 1448        Protocol Operations for SNMPv2      April 1993
1128
1129
1130           in the request; M is the value of the max-repetitions field in
1131           the request; and R is the maximum of: a) number of variable
1132           bindings in the request - N, and b)  zero.
1133
1134           The receiving SNMPv2 entity produces a Response-PDU with up to
1135           the total number of requested variable bindings communicated
1136           by the request.  The request-id shall have the same value as
1137           the received GetBulkRequest-PDU.
1138
1139           If N is greater than zero, the first through the (N)-th
1140           variable bindings of the Response-PDU are each produced as
1141           follows:
1142
1143           (1)  The variable is located which is in the lexicographically
1144                ordered list of the names of all variables which are
1145                accessible by this request and whose name is the first
1146                lexicographic successor of the variable binding's name in
1147                the incoming GetBulkRequest-PDU.  The corresponding
1148                variable binding's name and value fields in the
1149                Response-PDU are set to the name and value of the located
1150                variable.
1151
1152           (2)  If the requested variable binding's name does not
1153                lexicographically precede the name of any variable
1154                accessible by this request, i.e., there is no
1155                lexicographic successor, then the corresponding variable
1156                binding produced in the Response-PDU has its value field
1157                set to `endOfMibView', and its name field set to the
1158                variable binding's name in the request.
1159
1160           If M and R are non-zero, the (N + 1)-th and subsequent
1161           variable bindings of the Response-PDU are each produced in a
1162           similar manner.  For each iteration i, such that i is greater
1163           than zero and less than or equal to M, and for each repeated
1164           variable, r, such that r is greater than zero and less than or
1165           equal to R, the (N + ( (i-1) * R ) + r)-th variable binding of
1166           the Response-PDU is produced as follows:
1167
1168           (1)  The variable which is in the lexicographically ordered
1169                list of the names of all variables which are accessible
1170                by this request and whose name is the (i)-th
1171                lexicographic successor of the (N + r)-th variable
1172                binding's name in the incoming GetBulkRequest-PDU is
1173                located and the variable binding's name and value fields
1174                are set to the name and value of the located variable.
1175
1176
1177
1178
1179
1180           Case, McCloghrie, Rose & Waldbusser                  [Page 19]
1181 \f
1182
1183
1184
1185
1186           RFC 1448        Protocol Operations for SNMPv2      April 1993
1187
1188
1189           (2)  If there is no (i)-th lexicographic successor, then the
1190                corresponding variable binding produced in the Response-
1191                PDU has its value field set to `endOfMibView', and its
1192                name field set to either the last lexicographic
1193                successor, or if there are no lexicographic successors,
1194                to the (N + r)-th variable binding's name in the request.
1195
1196           While the maximum number of variable bindings in the
1197           Response-PDU is bounded by N + (M * R), the response may be
1198           generated with a lesser number of variable bindings (possibly
1199           zero) for either of two reasons.
1200
1201           (1)  If the size of the message encapsulating the Response-PDU
1202                containing the requested number of variable bindings
1203                would be greater than either a local constraint or the
1204                maximum message size of the request's source party, then
1205                the response is generated with a lesser number of
1206                variable bindings.  This lesser number is the ordered set
1207                of variable bindings with some of the variable bindings
1208                at the end of the set removed, such that the size of the
1209                message encapsulating the Response-PDU is approximately
1210                equal to but no greater than the minimum of the local
1211                constraint and the maximum message size of the request's
1212                source party.  Note that the number of variable bindings
1213                removed has no relationship to the values of N, M, or R.
1214
1215           (2)  The response may also be generated with a lesser number
1216                of variable bindings if for some value of iteration i,
1217                such that i is greater than zero and less than or equal
1218                to M, that all of the generated variable bindings have
1219                the value field set to the `endOfMibView'.  In this case,
1220                the variable bindings may be truncated after the (N + (i
1221                * R))-th variable binding.
1222
1223           If the processing of any variable binding fails for a reason
1224           other than listed above, then the Response-PDU is re-formatted
1225           with the same values in its request-id and variable-bindings
1226           fields as the received GetBulkRequest-PDU, with the value of
1227           its error-status field set to `genErr', and the value of its
1228           error-index field is set to the index of the failed variable
1229           binding.
1230
1231           Otherwise, the value of the Response-PDU's error-status field
1232           is set to `noError', and the value of its error-index field to
1233           zero.
1234
1235
1236
1237
1238
1239           Case, McCloghrie, Rose & Waldbusser                  [Page 20]
1240 \f
1241
1242
1243
1244
1245           RFC 1448        Protocol Operations for SNMPv2      April 1993
1246
1247
1248           The generated Response-PDU (possibly with an empty variable-
1249           bindings field) is then encapsulated into a message.  If the
1250           size of the resultant message is less than or equal to both a
1251           local constraint and the maximum message size of the request's
1252           source party, it is transmitted to the originator of the
1253           GetBulkRequest-PDU.  Otherwise, the resultant message is
1254           discarded.
1255
1256
1257           4.2.3.1.  Another Example of Table Traversal
1258
1259           This example demonstrates how the GetBulkRequest-PDU can be
1260           used as an alternative to the GetNextRequest-PDU.  The same
1261           traversal of the IP net-to-media table as shown in Section
1262           4.2.2.1 is achieved with fewer exchanges.
1263
1264           The SNMPv2 entity acting in a manager role begins by sending a
1265           GetBulkRequest-PDU with the modest max-repetitions value of 2,
1266           and containing the indicated OBJECT IDENTIFIER values as the
1267           requested variable names:
1268
1269               GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
1270                               ( sysUpTime,
1271                                 ipNetToMediaPhysAddress,
1272                                 ipNetToMediaType )
1273
1274           The SNMPv2 entity acting in an agent role responds with a
1275           Response-PDU:
1276
1277               Response (( sysUpTime.0 =  "123456" ),
1278                         ( ipNetToMediaPhysAddress.1.9.2.3.4 =
1279                                                    "000010543210" ),
1280                         ( ipNetToMediaType.1.9.2.3.4 =  "dynamic" ),
1281                         ( ipNetToMediaPhysAddress.1.10.0.0.51 =
1282                                                     "000010012345" ),
1283                         ( ipNetToMediaType.1.10.0.0.51 =  "static" ))
1284
1285           The SNMPv2 entity acting in a manager role continues with:
1286
1287               GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
1288                               ( sysUpTime,
1289                                 ipNetToMediaPhysAddress.1.10.0.0.51,
1290                                 ipNetToMediaType.1.10.0.0.51 )
1291
1292
1293
1294
1295
1296
1297
1298           Case, McCloghrie, Rose & Waldbusser                  [Page 21]
1299 \f
1300
1301
1302
1303
1304           RFC 1448        Protocol Operations for SNMPv2      April 1993
1305
1306
1307           The SNMPv2 entity acting in an agent role responds with:
1308
1309               Response (( sysUpTime.0 =  "123466" ),
1310                         ( ipNetToMediaPhysAddress.2.10.0.0.15 =
1311                                                    "000010987654" ),
1312                         ( ipNetToMediaType.2.10.0.0.15 =
1313                                                         "dynamic" ),
1314                         ( ipNetToMediaNetAddress.1.9.2.3.4 =
1315                                                         "9.2.3.4" ),
1316                         ( ipRoutingDiscards.0 =  "2" ))
1317
1318           This response signals the end of the table to the SNMPv2
1319           entity acting in a manager role.
1320
1321
1322           4.2.4.  The Response-PDU
1323
1324           The Response-PDU is generated by a SNMPv2 entity only upon
1325           receipt of a GetRequest-PDU, GetNextRequest-PDU,
1326           GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU, as
1327           described elsewhere in this document.
1328
1329           If the error-status field of the Response-PDU is non-zero, the
1330           value fields of the variable bindings in the variable binding
1331           list are ignored.
1332
1333           If both the error-status field and the error-index field of
1334           the Response-PDU are non-zero, then the value of the error-
1335           index field is the index of the variable binding (in the
1336           variable-binding list of the corresponding request) for which
1337           the request failed.  The first variable binding in a request's
1338           variable-binding list is index one, the second is index two,
1339           etc.
1340
1341           A compliant SNMPv2 entity acting in a manager role must be
1342           able to properly receive and handle a Response-PDU with an
1343           error-status field equal to `noSuchName', `badValue', or
1344           `readOnly'.  (See Section 3.1.2 of [10].)
1345
1346           Upon receipt of a Response-PDU, the receiving SNMPv2 entity
1347           presents its contents to the SNMPv2 application which
1348           generated the request with the same request-id value.
1349
1350
1351
1352
1353
1354
1355
1356
1357           Case, McCloghrie, Rose & Waldbusser                  [Page 22]
1358 \f
1359
1360
1361
1362
1363           RFC 1448        Protocol Operations for SNMPv2      April 1993
1364
1365
1366           4.2.5.  The SetRequest-PDU
1367
1368           A SetRequest-PDU is generated and transmitted at the request
1369           of a SNMPv2 application.
1370
1371           Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity
1372           determines the size of a message encapsulating a Response-PDU
1373           with the same values in its request-id, error-status, error-
1374           index and variable-bindings fields as the received
1375           SetRequest-PDU.  If the determined message size is greater
1376           than either a local constraint or the maximum message size of
1377           the request's source party, then an alternate Response-PDU is
1378           generated, transmitted to the originator of the SetRequest-
1379           PDU, and processing of the SetRequest-PDU terminates
1380           immediately thereafter.  This alternate Response-PDU is
1381           formatted with the same values in its request-id field as the
1382           received SetRequest-PDU, with the value of its error-status
1383           field set to `tooBig', the value of its error-index field set
1384           to zero, and an empty variable-bindings field.  This alternate
1385           Response-PDU is then encapsulated into a message.  If the size
1386           of the resultant message is less than or equal to both a local
1387           constraint and the maximum message size of the request's
1388           source party, it is transmitted to the originator of the
1389           SetRequest-PDU.  Otherwise, the resultant message is
1390           discarded.  Regardless, processing of the SetRequest-PDU
1391           terminates.
1392
1393           Otherwise, the receiving SNMPv2 entity processes each variable
1394           binding in the variable-binding list to produce a Response-
1395           PDU.  All fields of the Response-PDU have the same values as
1396           the corresponding fields of the received request except as
1397           indicated below.
1398
1399           The variable bindings are conceptually processed as a two
1400           phase operation.  In the first phase, each variable binding is
1401           validated; if all validations are successful, then each
1402           variable is altered in the second phase.  Of course,
1403           implementors are at liberty to implement either the first, or
1404           second, or both, of the these conceptual phases as multiple
1405           implementation phases.  Indeed, such multiple implementation
1406           phases may be necessary in some cases to ensure consistency.
1407
1408           The following validations are performed in the first phase on
1409           each variable binding until they are all successful, or until
1410           one fails:
1411
1412
1413
1414
1415
1416           Case, McCloghrie, Rose & Waldbusser                  [Page 23]
1417 \f
1418
1419
1420
1421
1422           RFC 1448        Protocol Operations for SNMPv2      April 1993
1423
1424
1425           (1)  If the variable binding's name specifies a variable which
1426                is not accessible by this request, then the value of the
1427                Response-PDU's error-status field is set to `noAccess',
1428                and the value of its error-index field is set to the
1429                index of the failed variable binding.
1430
1431           (2)  Otherwise, if the variable binding's name specifies a
1432                variable which does not exist and could not ever be
1433                created, then the value of the Response-PDU's error-
1434                status field is set to `noCreation', and the value of its
1435                error-index field is set to the index of the failed
1436                variable binding.
1437
1438           (3)  Otherwise, if the variable binding's name specifies a
1439                variable which exists but can not be modified no matter
1440                what new value is specified, then the value of the
1441                Response-PDU's error-status field is set to
1442                `notWritable', and the value of its error-index field is
1443                set to the index of the failed variable binding.
1444
1445           (4)  Otherwise, if the variable binding's value field
1446                specifies, according to the ASN.1 language, a type which
1447                is inconsistent with that required for the variable, then
1448                the value of the Response-PDU's error-status field is set
1449                to `wrongType', and the value of its error-index field is
1450                set to the index of the failed variable binding.
1451
1452           (5)  Otherwise, if the variable binding's value field
1453                specifies, according to the ASN.1 language, a length
1454                which is inconsistent with that required for the
1455                variable, then the value of the Response-PDU's error-
1456                status field is set to `wrongLength', and the value of
1457                its error-index field is set to the index of the failed
1458                variable binding.
1459
1460           (6)  Otherwise, if the variable binding's value field contains
1461                an ASN.1 encoding which is inconsistent with that field's
1462                ASN.1 tag, then: the value of the Response-PDU's error-
1463                status field is set to `wrongEncoding', and the value of
1464                its error-index field is set to the index of the failed
1465                variable binding.
1466
1467           (7)  Otherwise, if the variable binding's value field
1468                specifies a value which could under no circumstances be
1469                assigned to the variable, then: the value of the
1470
1471
1472
1473
1474
1475           Case, McCloghrie, Rose & Waldbusser                  [Page 24]
1476 \f
1477
1478
1479
1480
1481           RFC 1448        Protocol Operations for SNMPv2      April 1993
1482
1483
1484                Response-PDU's error-status field is set to `wrongValue',
1485                and the value of its error-index field is set to the
1486                index of the failed variable binding.
1487
1488           (8)  Otherwise, if the variable binding's name specifies a
1489                variable which does not exist but can not be created not
1490                under the present circumstances (even though it could be
1491                created under other circumstances), then the value of the
1492                Response-PDU's error-status field is set to
1493                `inconsistentName', and the value of its error-index
1494                field is set to the index of the failed variable binding.
1495
1496           (9)  Otherwise, if the variable binding's value field
1497                specifies a value that could under other circumstances be
1498                assigned to the variable, but is presently inconsistent,
1499                then the value of the Response-PDU's error-status field
1500                is set to `inconsistentValue', and the value of its
1501                error-index field is set to the index of the failed
1502                variable binding.
1503
1504           (10) Otherwise, if the assignment of the value specified by
1505                the variable binding's value field to the specified
1506                variable requires the allocation of a resource which is
1507                presently unavailable, then: the value of the Response-
1508                PDU's error-status field is set to `resourceUnavailable',
1509                and the value of its error-index field is set to the
1510                index of the failed variable binding.
1511
1512           (11) If the processing of the variable binding fails for a
1513                reason other than listed above, then the value of the
1514                Response-PDU's error-status field is set to `genErr', and
1515                the value of its error-index field is set to the index of
1516                the failed variable binding.
1517
1518           (12) Otherwise, the validation of the variable binding
1519                succeeds.
1520
1521           At the end of the first phase, if the validation of all
1522           variable bindings succeeded, then:
1523
1524           The value of the Response-PDU's error-status field is set to
1525           `noError' and the value of its error-index field is zero.
1526
1527           For each variable binding in the request, the named variable
1528           is created if necessary, and the specified value is assigned
1529
1530
1531
1532
1533
1534           Case, McCloghrie, Rose & Waldbusser                  [Page 25]
1535 \f
1536
1537
1538
1539
1540           RFC 1448        Protocol Operations for SNMPv2      April 1993
1541
1542
1543           to it.  Each of these variable assignments occurs as if
1544           simultaneously with respect to all other assignments specified
1545           in the same request.  However, if the same variable is named
1546           more than once in a single request, with different associated
1547           values, then the actual assignment made to that variable is
1548           implementation-specific.
1549
1550           If any of these assignments fail (even after all the previous
1551           validations), then all other assignments are undone, and the
1552           Response-PDU is modified to have the value of its error-status
1553           field set to `commitFailed', and the value of its error-index
1554           field set to the index of the failed variable binding.
1555
1556           If and only if it is not possible to undo all the assignments,
1557           then the Response-PDU is modified to have the value of its
1558           error-status field set to `undoFailed', and the value of its
1559           error-index field is set to zero.  Note that implementations
1560           are strongly encouraged to take all possible measures to avoid
1561           use of either `commitFailed' or `undoFailed' - these two
1562           error-status codes are not to be taken as license to take the
1563           easy way out in an implementation.
1564
1565           Finally, the generated Response-PDU is encapsulated into a
1566           message, and transmitted to the originator of the SetRequest-
1567           PDU.
1568
1569
1570           4.2.6.  The SNMPv2-Trap-PDU
1571
1572           A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2
1573           entity acting in an agent role when an exceptional situation
1574           occurs.
1575
1576           The destination(s) to which a SNMPv2-Trap-PDU is sent is
1577           determined by consulting the aclTable [5] to find all entries
1578           satisfying the following conditions:
1579
1580           (1)  The value of aclSubject refers to the SNMPv2 entity.
1581
1582           (2)  The value of aclPrivileges allows for the SNMPv2-Trap-
1583                PDU.
1584
1585           (3)  aclResources refers to a SNMPv2 context denoting local
1586                object resources, and the notification's administratively
1587                assigned name is present in the corresponding MIB view.
1588
1589
1590
1591
1592
1593           Case, McCloghrie, Rose & Waldbusser                  [Page 26]
1594 \f
1595
1596
1597
1598
1599           RFC 1448        Protocol Operations for SNMPv2      April 1993
1600
1601
1602                (That is, the set of entries in the viewTable [5] for
1603                which the instance of viewIndex has the same value as the
1604                aclResources's contextViewIndex, define a MIB view which
1605                contains the notification's administratively assigned
1606                name.)
1607
1608           (4)  If the OBJECTS clause is present in the invocation of the
1609                corresponding NOTIFICATION-TYPE macro, then the
1610                correspondent variables are all present in the MIB view
1611                corresponding to aclResource.
1612
1613           Then, for each entry satisfying these conditions, a SNMPv2-
1614           Trap-PDU is sent from aclSubject with context aclResources to
1615           aclTarget.  The instance of snmpTrapNumbers [11] corresponding
1616           to aclTarget is incremented, and is used as the request-id
1617           field of the SNMPv2-Trap-PDU.  Then, the variable-bindings
1618           field are constructed as:
1619
1620           (1)  The first variable is sysUpTime.0 [9].
1621
1622           (2)  The second variable is snmpTrapOID.0 [11], which contains
1623                the administratively assigned name of the notification.
1624
1625           (3)  If the OBJECTS clause is present in the invocation of the
1626                corresponding NOTIFICATION-TYPE macro, then each
1627                corresponding variable is copied, in order, to the
1628                variable-bindings field.
1629
1630           (4)  At the option of the SNMPv2 entity acting in an agent
1631                role, additional variables may follow in the variable-
1632                bindings field.
1633
1634
1635           4.2.7.  The InformRequest-PDU
1636
1637           An InformRequest-PDU is generated and transmitted at the
1638           request an application in a SNMPv2 entity acting in a manager
1639           role, that wishes to notify another application (in a SNMPv2
1640           entity also acting in a manager role) of information in the
1641           MIB View of a party local to the sending application.
1642
1643           The destination(s) to which an InformRequest-PDU is sent is
1644           determined by inspecting the snmpEventNotifyTable [12], or as
1645           specified by the requesting application.  The first two
1646           variable bindings in the variable binding list of an
1647
1648
1649
1650
1651
1652           Case, McCloghrie, Rose & Waldbusser                  [Page 27]
1653 \f
1654
1655
1656
1657
1658           RFC 1448        Protocol Operations for SNMPv2      April 1993
1659
1660
1661           InformRequest-PDU are sysUpTime.0 [9] and snmpEventID.i [12]
1662           respectively.  If the OBJECTS clause is present in the
1663           invocation of the corresponding NOTIFICATION-TYPE macro, then
1664           each corresponding variable, as instantiated by this
1665           notification, is copied, in order, to the variable-bindings
1666           field.
1667
1668           Upon receipt of an InformRequest-PDU, the receiving SNMPv2
1669           entity determines the size of a message encapsulating a
1670           Response-PDU with the same values in its request-id, error-
1671           status, error-index and variable-bindings fields as the
1672           received InformRequest-PDU.  If the determined message size is
1673           greater than either a local constraint or the maximum message
1674           size of the request's source party, then an alternate
1675           Response-PDU is generated, transmitted to the originator of
1676           the InformRequest-PDU, and processing of the InformRequest-PDU
1677           terminates immediately thereafter.  This alternate Response-
1678           PDU is formatted with the same values in its request-id field
1679           as the received InformRequest-PDU, with the value of its
1680           error-status field set to `tooBig', the value of its error-
1681           index field set to zero, and an empty variable-bindings field.
1682           This alternate Response-PDU is then encapsulated into a
1683           message.  If the size of the resultant message is less than or
1684           equal to both a local constraint and the maximum message size
1685           of the request's source party, it is transmitted to the
1686           originator of the InformRequest-PDU.  Otherwise, the resultant
1687           message is discarded.  Regardless, processing of the
1688           InformRequest-PDU terminates.
1689
1690           Otherwise, the receiving SNMPv2 entity:
1691
1692           (1)  presents its contents to the appropriate SNMPv2
1693                application;
1694
1695           (2)  generates a Response-PDU with the same values in its
1696                request-id and variable-bindings fields as the received
1697                InformRequest-PDU, with the value of its error-status
1698                field is set to `noError' and the value of its error-
1699                index field is zero; and
1700
1701           (3)  transmits the generated Response-PDU to the originator of
1702                the InformRequest-PDU.
1703
1704
1705
1706
1707
1708
1709
1710
1711           Case, McCloghrie, Rose & Waldbusser                  [Page 28]
1712 \f
1713
1714
1715
1716
1717           RFC 1448        Protocol Operations for SNMPv2      April 1993
1718
1719
1720           5.  Acknowledgements
1721
1722           This document is based, in part, on RFC 1157.  The mechanism
1723           for bulk retrieval is influenced by many experiments,
1724           including RFC1187 and also Greg Satz's work on SNMP over TCP.
1725
1726           Finally, the comments of the SNMP version 2 working group are
1727           gratefully acknowledged:
1728
1729                Beth Adams, Network Management Forum
1730                Steve Alexander, INTERACTIVE Systems Corporation
1731                David Arneson, Cabletron Systems
1732                Toshiya Asaba
1733                Fred Baker, ACC
1734                Jim Barnes, Xylogics, Inc.
1735                Brian Bataille
1736                Andy Bierman, SynOptics Communications, Inc.
1737                Uri Blumenthal, IBM Corporation
1738                Fred Bohle, Interlink
1739                Jack Brown
1740                Theodore Brunner, Bellcore
1741                Stephen F. Bush, GE Information Services
1742                Jeffrey D. Case, University of Tennessee, Knoxville
1743                John Chang, IBM Corporation
1744                Szusin Chen, Sun Microsystems
1745                Robert Ching
1746                Chris Chiotasso, Ungermann-Bass
1747                Bobby A. Clay, NASA/Boeing
1748                John Cooke, Chipcom
1749                Tracy Cox, Bellcore
1750                Juan Cruz, Datability, Inc.
1751                David Cullerot, Cabletron Systems
1752                Cathy Cunningham, Microcom
1753                James R. (Chuck) Davin, Bellcore
1754                Michael Davis, Clearpoint
1755                Mike Davison, FiberCom
1756                Cynthia DellaTorre, MITRE
1757                Taso N. Devetzis, Bellcore
1758                Manual Diaz, DAVID Systems, Inc.
1759                Jon Dreyer, Sun Microsystems
1760                David Engel, Optical Data Systems
1761                Mike Erlinger, Lexcel
1762                Roger Fajman, NIH
1763                Daniel Fauvarque, Sun Microsystems
1764                Karen Frisa, CMU
1765
1766
1767
1768
1769
1770           Case, McCloghrie, Rose & Waldbusser                  [Page 29]
1771 \f
1772
1773
1774
1775
1776           RFC 1448        Protocol Operations for SNMPv2      April 1993
1777
1778
1779                Shari Galitzer, MITRE
1780                Shawn Gallagher, Digital Equipment Corporation
1781                Richard Graveman, Bellcore
1782                Maria Greene, Xyplex, Inc.
1783                Michel Guittet, Apple
1784                Robert Gutierrez, NASA
1785                Bill Hagerty, Cabletron Systems
1786                Gary W. Haney, Martin Marietta Energy Systems
1787                Patrick Hanil, Nokia Telecommunications
1788                Matt Hecht, SNMP Research, Inc.
1789                Edward A. Heiner, Jr., Synernetics Inc.
1790                Susan E. Hicks, Martin Marietta Energy Systems
1791                Geral Holzhauer, Apple
1792                John Hopprich, DAVID Systems, Inc.
1793                Jeff Hughes, Hewlett-Packard
1794                Robin Iddon, Axon Networks, Inc.
1795                David Itusak
1796                Kevin M. Jackson, Concord Communications, Inc.
1797                Ole J. Jacobsen, Interop Company
1798                Ronald Jacoby, Silicon Graphics, Inc.
1799                Satish Joshi, SynOptics Communications, Inc.
1800                Frank Kastenholz, FTP Software
1801                Mark Kepke, Hewlett-Packard
1802                Ken Key, SNMP Research, Inc.
1803                Zbiginew Kielczewski, Eicon
1804                Jongyeoi Kim
1805                Andrew Knutsen, The Santa Cruz Operation
1806                Michael L. Kornegay, VisiSoft
1807                Deirdre C. Kostik, Bellcore
1808                Cheryl Krupczak, Georgia Tech
1809                Mark S. Lewis, Telebit
1810                David Lin
1811                David Lindemulder, AT&T/NCR
1812                Ben Lisowski, Sprint
1813                David Liu, Bell-Northern Research
1814                John Lunny, The Wollongong Group
1815                Robert C. Lushbaugh Martin, Marietta Energy Systems
1816                Michael Luufer, BBN
1817                Carl Madison, Star-Tek, Inc.
1818                Keith McCloghrie, Hughes LAN Systems
1819                Evan McGinnis, 3Com Corporation
1820                Bill McKenzie, IBM Corporation
1821                Donna McMaster, SynOptics Communications, Inc.
1822                John Medicke, IBM Corporation
1823                Doug Miller, Telebit
1824
1825
1826
1827
1828
1829           Case, McCloghrie, Rose & Waldbusser                  [Page 30]
1830 \f
1831
1832
1833
1834
1835           RFC 1448        Protocol Operations for SNMPv2      April 1993
1836
1837
1838                Dave Minnich, FiberCom
1839                Mohammad Mirhakkak, MITRE
1840                Rohit Mital, Protools
1841                George Mouradian, AT&T Bell Labs
1842                Patrick Mullaney, Cabletron Systems
1843                Dan Myers, 3Com Corporation
1844                Rina Nathaniel, Rad Network Devices Ltd.
1845                Hien V. Nguyen, Sprint
1846                Mo Nikain
1847                Tom Nisbet
1848                William B. Norton, MERIT
1849                Steve Onishi, Wellfleet Communications, Inc.
1850                David T. Perkins, SynOptics Communications, Inc.
1851                Carl Powell, BBN
1852                Ilan Raab, SynOptics Communications, Inc.
1853                Richard Ramons, AT&T
1854                Venkat D. Rangan, Metric Network Systems, Inc.
1855                Louise Reingold, Sprint
1856                Sam Roberts, Farallon Computing, Inc.
1857                Kary Robertson, Concord Communications, Inc.
1858                Dan Romascanu, Lannet Data Communications Ltd.
1859                Marshall T. Rose, Dover Beach Consulting, Inc.
1860                Shawn A. Routhier, Epilogue Technology Corporation
1861                Chris Rozman
1862                Asaf Rubissa, Fibronics
1863                Jon Saperia, Digital Equipment Corporation
1864                Michael Sapich
1865                Mike Scanlon, Interlan
1866                Sam Schaen, MITRE
1867                John Seligson, Ultra Network Technologies
1868                Paul A. Serice, Corporation for Open Systems
1869                Chris Shaw, Banyan Systems
1870                Timon Sloane
1871                Robert Snyder, Cisco Systems
1872                Joo Young Song
1873                Roy Spitier, Sprint
1874                Einar Stefferud, Network Management Associates
1875                John Stephens, Cayman Systems, Inc.
1876                Robert L. Stewart, Xyplex, Inc. (chair)
1877                Kaj Tesink, Bellcore
1878                Dean Throop, Data General
1879                Ahmet Tuncay, France Telecom-CNET
1880                Maurice Turcotte, Racal Datacom
1881                Warren Vik, INTERACTIVE Systems Corporation
1882                Yannis Viniotis
1883
1884
1885
1886
1887
1888           Case, McCloghrie, Rose & Waldbusser                  [Page 31]
1889 \f
1890
1891
1892
1893
1894           RFC 1448        Protocol Operations for SNMPv2      April 1993
1895
1896
1897                Steven L. Waldbusser, Carnegie Mellon Universitty
1898                Timothy M. Walden, ACC
1899                Alice Wang, Sun Microsystems
1900                James Watt, Newbridge
1901                Luanne Waul, Timeplex
1902                Donald E. Westlake III, Digital Equipment Corporation
1903                Gerry White
1904                Bert Wijnen, IBM Corporation
1905                Peter Wilson, 3Com Corporation
1906                Steven Wong, Digital Equipment Corporation
1907                Randy Worzella, IBM Corporation
1908                Daniel Woycke, MITRE
1909                Honda Wu
1910                Jeff Yarnell, Protools
1911                Chris Young, Cabletron
1912                Kiho Yum, 3Com Corporation
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947           Case, McCloghrie, Rose & Waldbusser                  [Page 32]
1948 \f
1949
1950
1951
1952
1953           RFC 1448        Protocol Operations for SNMPv2      April 1993
1954
1955
1956           6.  References
1957
1958           [1]  Information processing systems - Open Systems
1959                Interconnection - Specification of Abstract Syntax
1960                Notation One (ASN.1), International Organization for
1961                Standardization.  International Standard 8824, (December,
1962                1987).
1963
1964           [2]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
1965                "Structure of Management Information for version 2 of the
1966                Simple Network Management Protocol (SNMPv2)", RFC 1442,
1967                SNMP Research, Inc., Hughes LAN Systems, Dover Beach
1968                Consulting, Inc., Carnegie Mellon University, April 1993.
1969
1970           [3]  Galvin, J., and McCloghrie, K., "Administrative Model for
1971                version 2 of the Simple Network Management Protocol
1972                (SNMPv2)", RFC 1445, Trusted Information Systems, Hughes
1973                LAN Systems, April 1993.
1974
1975           [4]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
1976                "Textual Conventions for version 2 of the the Simple
1977                Network Management Protocol (SNMPv2)", RFC 1443, SNMP
1978                Research, Inc., Hughes LAN Systems, Dover Beach
1979                Consulting, Inc., Carnegie Mellon University, April 1993.
1980
1981           [5]  McCloghrie, K., and Galvin, J., "Party MIB for version 2
1982                of the Simple Network Management Protocol (SNMPv2)", RFC
1983                1447, Hughes LAN Systems, Trusted Information Systems,
1984                April 1993.
1985
1986           [6]  C. Kent, J. Mogul, Fragmentation Considered Harmful,
1987                Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).
1988
1989           [7]  Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
1990                "Transport Mappings for version 2 of the Simple Network
1991                Management Protocol (SNMPv2)", RFC 1449, SNMP Research,
1992                Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
1993                Carnegie Mellon University, April 1993.
1994
1995           [8]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
1996                USC/Information Sciences Institute, August 1980.
1997
1998           [9]  McCloghrie, K., and Rose, M., "Management Information
1999                Base for Network Management of TCP/IP-based internets:
2000                MIB-II", STD 17, RFC 1213, March 1991.
2001
2002
2003
2004
2005
2006           Case, McCloghrie, Rose & Waldbusser                  [Page 33]
2007 \f
2008
2009
2010
2011
2012           RFC 1448        Protocol Operations for SNMPv2      April 1993
2013
2014
2015           [10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
2016                "Coexistence between version 1 and version 2 of the
2017                Internet-standard Network Management Framework", RFC
2018                1452, SNMP Research, Inc., Hughes LAN Systems, Dover
2019                Beach Consulting, Inc., Carnegie Mellon University, April
2020                1993.
2021
2022           [11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
2023                "Management Information Base for version 2 of the Simple
2024                Network Management Protocol (SNMPv2)", RFC 1450, SNMP
2025                Research, Inc., Hughes LAN Systems, Dover Beach
2026                Consulting, Inc., Carnegie Mellon University, April 1993.
2027
2028           [12] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
2029                "Manager-to-Manager Management Information Base", RFC
2030                1451, SNMP Research, Inc., Hughes LAN Systems, Dover
2031                Beach Consulting, Inc., Carnegie Mellon University, April
2032                1993.
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065           Case, McCloghrie, Rose & Waldbusser                  [Page 34]
2066 \f
2067
2068
2069
2070
2071           RFC 1448        Protocol Operations for SNMPv2      April 1993
2072
2073
2074           7.  Security Considerations
2075
2076           Security issues are not discussed in this memo.
2077
2078
2079           8.  Authors' Addresses
2080
2081                Jeffrey D. Case
2082                SNMP Research, Inc.
2083                3001 Kimberlin Heights Rd.
2084                Knoxville, TN  37920-9716
2085                US
2086
2087                Phone: +1 615 573 1434
2088                Email: case@snmp.com
2089
2090
2091                Keith McCloghrie
2092                Hughes LAN Systems
2093                1225 Charleston Road
2094                Mountain View, CA  94043
2095                US
2096
2097                Phone: +1 415 966 7934
2098                Email: kzm@hls.com
2099
2100
2101                Marshall T. Rose
2102                Dover Beach Consulting, Inc.
2103                420 Whisman Court
2104                Mountain View, CA  94043-2186
2105                US
2106
2107                Phone: +1 415 968 1052
2108                Email: mrose@dbc.mtview.ca.us
2109
2110                Steven Waldbusser
2111                Carnegie Mellon University
2112                4910 Forbes Ave
2113                Pittsburgh, PA  15213
2114                US
2115
2116                Phone: +1 412 268 6628
2117                Email: waldbusser@cmu.edu
2118
2119
2120
2121
2122
2123
2124           Case, McCloghrie, Rose & Waldbusser                  [Page 35]
2125 \f