doc/rfc/rfc1157.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            J. Case
   8 Request for Comments:  1157                                SNMP Research
   9 Obsoletes:  RFC 1098                                            M. Fedor
  10                                        Performance Systems International
  11                                                           M. Schoffstall
  12                                        Performance Systems International
  13                                                                 J. Davin
  14                                      MIT Laboratory for Computer Science
  15                                                                 May 1990
  16
  17
  18               A Simple Network Management Protocol (SNMP)
  19
  20                            Table of Contents
  21
  22    1. Status of this Memo ...................................    2
  23    2. Introduction ..........................................    2
  24    3. The SNMP Architecture .................................    5
  25    3.1 Goals of the Architecture ............................    5
  26    3.2 Elements of the Architecture .........................    5
  27    3.2.1 Scope of Management Information ....................    6
  28    3.2.2 Representation of Management Information ...........    6
  29    3.2.3 Operations Supported on Management Information .....    7
  30    3.2.4 Form and Meaning of Protocol Exchanges .............    8
  31    3.2.5 Definition of Administrative Relationships .........    8
  32    3.2.6 Form and Meaning of References to Managed Objects ..   12
  33    3.2.6.1 Resolution of Ambiguous MIB References ...........   12
  34    3.2.6.2 Resolution of References across MIB Versions......   12
  35    3.2.6.3 Identification of Object Instances ...............   12
  36    3.2.6.3.1 ifTable Object Type Names ......................   13
  37    3.2.6.3.2 atTable Object Type Names ......................   13
  38    3.2.6.3.3 ipAddrTable Object Type Names ..................   14
  39    3.2.6.3.4 ipRoutingTable Object Type Names ...............   14
  40    3.2.6.3.5 tcpConnTable Object Type Names .................   14
  41    3.2.6.3.6 egpNeighTable Object Type Names ................   15
  42    4. Protocol Specification ................................   16
  43    4.1 Elements of Procedure ................................   17
  44    4.1.1 Common Constructs ..................................   19
  45    4.1.2 The GetRequest-PDU .................................   20
  46    4.1.3 The GetNextRequest-PDU .............................   21
  47    4.1.3.1 Example of Table Traversal .......................   23
  48    4.1.4 The GetResponse-PDU ................................   24
  49    4.1.5 The SetRequest-PDU .................................   25
  50    4.1.6 The Trap-PDU .......................................   27
  51    4.1.6.1 The coldStart Trap ...............................   28
  52    4.1.6.2 The warmStart Trap ...............................   28
  53    4.1.6.3 The linkDown Trap ................................   28
  54    4.1.6.4 The linkUp Trap ..................................   28
  55
  56
  57
  58 Case, Fedor, Schoffstall, & Davin                               [Page 1]
  59 \f
  60 RFC 1157                          SNMP                          May 1990
  61
  62
  63    4.1.6.5 The authenticationFailure Trap ...................   28
  64    4.1.6.6 The egpNeighborLoss Trap .........................   28
  65    4.1.6.7 The enterpriseSpecific Trap ......................   29
  66    5. Definitions ...........................................   30
  67    6. Acknowledgements ......................................   33
  68    7. References ............................................   34
  69    8. Security Considerations................................   35
  70    9. Authors' Addresses.....................................   35
  71
  72 1.  Status of this Memo
  73
  74    This RFC is a re-release of RFC 1098, with a changed "Status of this
  75    Memo" section plus a few minor typographical corrections.  This memo
  76    defines a simple protocol by which management information for a
  77    network element may be inspected or altered by logically remote
  78    users.  In particular, together with its companion memos which
  79    describe the structure of management information along with the
  80    management information base, these documents provide a simple,
  81    workable architecture and system for managing TCP/IP-based internets
  82    and in particular the Internet.
  83
  84    The Internet Activities Board recommends that all IP and TCP
  85    implementations be network manageable.  This implies implementation
  86    of the Internet MIB (RFC-1156) and at least one of the two
  87    recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
  88    It should be noted that, at this time, SNMP is a full Internet
  89    standard and CMOT is a draft standard.  See also the Host and Gateway
  90    Requirements RFCs for more specific information on the applicability
  91    of this standard.
  92
  93    Please refer to the latest edition of the "IAB Official Protocol
  94    Standards" RFC for current information on the state and status of
  95    standard Internet protocols.
  96
  97    Distribution of this memo is unlimited.
  98
  99 2.  Introduction
 100
 101    As reported in RFC 1052, IAB Recommendations for the Development of
 102    Internet Network Management Standards [1], a two-prong strategy for
 103    network management of TCP/IP-based internets was undertaken.  In the
 104    short-term, the Simple Network Management Protocol (SNMP) was to be
 105    used to manage nodes in the Internet community.  In the long-term,
 106    the use of the OSI network management framework was to be examined.
 107    Two documents were produced to define the management information: RFC
 108    1065, which defined the Structure of Management Information (SMI)
 109    [2], and RFC 1066, which defined the Management Information Base
 110    (MIB) [3].  Both of these documents were designed so as to be
 111
 112
 113
 114 Case, Fedor, Schoffstall, & Davin                               [Page 2]
 115 \f
 116 RFC 1157                          SNMP                          May 1990
 117
 118
 119    compatible with both the SNMP and the OSI network management
 120    framework.
 121
 122    This strategy was quite successful in the short-term: Internet-based
 123    network management technology was fielded, by both the research and
 124    commercial communities, within a few months.  As a result of this,
 125    portions of the Internet community became network manageable in a
 126    timely fashion.
 127
 128    As reported in RFC 1109, Report of the Second Ad Hoc Network
 129    Management Review Group [4], the requirements of the SNMP and the OSI
 130    network management frameworks were more different than anticipated.
 131    As such, the requirement for compatibility between the SMI/MIB and
 132    both frameworks was suspended.  This action permitted the operational
 133    network management framework, the SNMP, to respond to new operational
 134    needs in the Internet community by producing documents defining new
 135    MIB items.
 136
 137    The IAB has designated the SNMP, SMI, and the initial Internet MIB to
 138    be full "Standard Protocols" with "Recommended" status.  By this
 139    action, the IAB recommends that all IP and TCP implementations be
 140    network manageable and that the implementations that are network
 141    manageable are expected to adopt and implement the SMI, MIB, and
 142    SNMP.
 143
 144    As such, the current network management framework for TCP/IP- based
 145    internets consists of:  Structure and Identification of Management
 146    Information for TCP/IP-based Internets, which describes how managed
 147    objects contained in the MIB are defined as set forth in RFC 1155
 148    [5]; Management Information Base for Network Management of TCP/IP-
 149    based Internets, which describes the managed objects contained in the
 150    MIB as set forth in RFC 1156 [6]; and, the Simple Network Management
 151    Protocol, which defines the protocol used to manage these objects, as
 152    set forth in this memo.
 153
 154    As reported in RFC 1052, IAB Recommendations for the Development of
 155    Internet Network Management Standards [1], the Internet Activities
 156    Board has directed the Internet Engineering Task Force (IETF) to
 157    create two new working groups in the area of network management.  One
 158    group was charged with the further specification and definition of
 159    elements to be included in the Management Information Base (MIB).
 160    The other was charged with defining the modifications to the Simple
 161    Network Management Protocol (SNMP) to accommodate the short-term
 162    needs of the network vendor and operations communities, and to align
 163    with the output of the MIB working group.
 164
 165    The MIB working group produced two memos, one which defines a
 166    Structure for Management Information (SMI) [2] for use by the managed
 167
 168
 169
 170 Case, Fedor, Schoffstall, & Davin                               [Page 3]
 171 \f
 172 RFC 1157                          SNMP                          May 1990
 173
 174
 175    objects contained in the MIB.  A second memo [3] defines the list of
 176    managed objects.
 177
 178    The output of the SNMP Extensions working group is this memo, which
 179    incorporates changes to the initial SNMP definition [7] required to
 180    attain alignment with the output of the MIB working group.  The
 181    changes should be minimal in order to be consistent with the IAB's
 182    directive that the working groups be "extremely sensitive to the need
 183    to keep the SNMP simple."  Although considerable care and debate has
 184    gone into the changes to the SNMP which are reflected in this memo,
 185    the resulting protocol is not backwardly-compatible with its
 186    predecessor, the Simple Gateway Monitoring Protocol (SGMP) [8].
 187    Although the syntax of the protocol has been altered, the original
 188    philosophy, design decisions, and architecture remain intact.  In
 189    order to avoid confusion, new UDP ports have been allocated for use
 190    by the protocol described in this memo.
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Case, Fedor, Schoffstall, & Davin                               [Page 4]
 227 \f
 228 RFC 1157                          SNMP                          May 1990
 229
 230
 231 3.  The SNMP Architecture
 232
 233    Implicit in the SNMP architectural model is a collection of network
 234    management stations and network elements.  Network management
 235    stations execute management applications which monitor and control
 236    network elements.  Network elements are devices such as hosts,
 237    gateways, terminal servers, and the like, which have management
 238    agents responsible for performing the network management functions
 239    requested by the network management stations.  The Simple Network
 240    Management Protocol (SNMP) is used to communicate management
 241    information between the network management stations and the agents in
 242    the network elements.
 243
 244 3.1.  Goals of the Architecture
 245
 246    The SNMP explicitly minimizes the number and complexity of management
 247    functions realized by the management agent itself.  This goal is
 248    attractive in at least four respects:
 249
 250       (1)  The development cost for management agent software
 251            necessary to support the protocol is accordingly reduced.
 252
 253       (2)  The degree of management function that is remotely
 254            supported is accordingly increased, thereby admitting
 255            fullest use of internet resources in the management task.
 256
 257       (3)  The degree of management function that is remotely
 258            supported is accordingly increased, thereby imposing the
 259            fewest possible restrictions on the form and
 260            sophistication of management tools.
 261
 262       (4)  Simplified sets of management functions are easily
 263            understood and used by developers of network management
 264            tools.
 265
 266    A second goal of the protocol is that the functional paradigm for
 267    monitoring and control be sufficiently extensible to accommodate
 268    additional, possibly unanticipated aspects of network operation and
 269    management.
 270
 271    A third goal is that the architecture be, as much as possible,
 272    independent of the architecture and mechanisms of particular hosts or
 273    particular gateways.
 274
 275 3.2.  Elements of the Architecture
 276
 277    The SNMP architecture articulates a solution to the network
 278    management problem in terms of:
 279
 280
 281
 282 Case, Fedor, Schoffstall, & Davin                               [Page 5]
 283 \f
 284 RFC 1157                          SNMP                          May 1990
 285
 286
 287       (1)  the scope of the management information communicated by
 288            the protocol,
 289
 290       (2)  the representation of the management information
 291            communicated by the protocol,
 292
 293       (3)  operations on management information supported by the
 294            protocol,
 295
 296       (4)  the form and meaning of exchanges among management
 297            entities,
 298
 299       (5)  the definition of administrative relationships among
 300            management entities, and
 301
 302       (6)  the form and meaning of references to management
 303            information.
 304
 305 3.2.1.  Scope of Management Information
 306
 307    The scope of the management information communicated by operation of
 308    the SNMP is exactly that represented by instances of all non-
 309    aggregate object types either defined in Internet-standard MIB or
 310    defined elsewhere according to the conventions set forth in
 311    Internet-standard SMI [5].
 312
 313    Support for aggregate object types in the MIB is neither required for
 314    conformance with the SMI nor realized by the SNMP.
 315
 316 3.2.2.  Representation of Management Information
 317
 318    Management information communicated by operation of the SNMP is
 319    represented according to the subset of the ASN.1 language [9] that is
 320    specified for the definition of non-aggregate types in the SMI.
 321
 322    The SGMP adopted the convention of using a well-defined subset of the
 323    ASN.1 language [9].  The SNMP continues and extends this tradition by
 324    utilizing a moderately more complex subset of ASN.1 for describing
 325    managed objects and for describing the protocol data units used for
 326    managing those objects.  In addition, the desire to ease eventual
 327    transition to OSI-based network management protocols led to the
 328    definition in the ASN.1 language of an Internet-standard Structure of
 329    Management Information (SMI) [5] and Management Information Base
 330    (MIB) [6].  The use of the ASN.1 language, was, in part, encouraged
 331    by the successful use of ASN.1 in earlier efforts, in particular, the
 332    SGMP.  The restrictions on the use of ASN.1 that are part of the SMI
 333    contribute to the simplicity espoused and validated by experience
 334    with the SGMP.
 335
 336
 337
 338 Case, Fedor, Schoffstall, & Davin                               [Page 6]
 339 \f
 340 RFC 1157                          SNMP                          May 1990
 341
 342
 343    Also for the sake of simplicity, the SNMP uses only a subset of the
 344    basic encoding rules of ASN.1 [10].  Namely, all encodings use the
 345    definite-length form.  Further, whenever permissible, non-constructor
 346    encodings are used rather than constructor encodings.  This
 347    restriction applies to all aspects of ASN.1 encoding, both for the
 348    top-level protocol data units and the data objects they contain.
 349
 350 3.2.3.  Operations Supported on Management Information
 351
 352    The SNMP models all management agent functions as alterations or
 353    inspections of variables.  Thus, a protocol entity on a logically
 354    remote host (possibly the network element itself) interacts with the
 355    management agent resident on the network element in order to retrieve
 356    (get) or alter (set) variables.  This strategy has at least two
 357    positive consequences:
 358
 359       (1)  It has the effect of limiting the number of essential
 360            management functions realized by the management agent to
 361            two:  one operation to assign a value to a specified
 362            configuration or other parameter and another to retrieve
 363            such a value.
 364
 365       (2)  A second effect of this decision is to avoid introducing
 366            into the protocol definition support for imperative
 367            management commands:  the number of such commands is in
 368            practice ever-increasing, and the semantics of such
 369            commands are in general arbitrarily complex.
 370
 371    The strategy implicit in the SNMP is that the monitoring of network
 372    state at any significant level of detail is accomplished primarily by
 373    polling for appropriate information on the part of the monitoring
 374    center(s).  A limited number of unsolicited messages (traps) guide
 375    the timing and focus of the polling.  Limiting the number of
 376    unsolicited messages is consistent with the goal of simplicity and
 377    minimizing the amount of traffic generated by the network management
 378    function.
 379
 380    The exclusion of imperative commands from the set of explicitly
 381    supported management functions is unlikely to preclude any desirable
 382    management agent operation.  Currently, most commands are requests
 383    either to set the value of some parameter or to retrieve such a
 384    value, and the function of the few imperative commands currently
 385    supported is easily accommodated in an asynchronous mode by this
 386    management model.  In this scheme, an imperative command might be
 387    realized as the setting of a parameter value that subsequently
 388    triggers the desired action.  For example, rather than implementing a
 389    "reboot command," this action might be invoked by simply setting a
 390    parameter indicating the number of seconds until system reboot.
 391
 392
 393
 394 Case, Fedor, Schoffstall, & Davin                               [Page 7]
 395 \f
 396 RFC 1157                          SNMP                          May 1990
 397
 398
 399 3.2.4.  Form and Meaning of Protocol Exchanges
 400
 401    The communication of management information among management entities
 402    is realized in the SNMP through the exchange of protocol messages.
 403    The form and meaning of those messages is defined below in Section 4.
 404
 405    Consistent with the goal of minimizing complexity of the management
 406    agent, the exchange of SNMP messages requires only an unreliable
 407    datagram service, and every message is entirely and independently
 408    represented by a single transport datagram.  While this document
 409    specifies the exchange of messages via the UDP protocol [11], the
 410    mechanisms of the SNMP are generally suitable for use with a wide
 411    variety of transport services.
 412
 413 3.2.5.  Definition of Administrative Relationships
 414
 415    The SNMP architecture admits a variety of administrative
 416    relationships among entities that participate in the protocol.  The
 417    entities residing at management stations and network elements which
 418    communicate with one another using the SNMP are termed SNMP
 419    application entities.  The peer processes which implement the SNMP,
 420    and thus support the SNMP application entities, are termed protocol
 421    entities.
 422
 423    A pairing of an SNMP agent with some arbitrary set of SNMP
 424    application entities is called an SNMP community.  Each SNMP
 425    community is named by a string of octets, that is called the
 426    community name for said community.
 427
 428    An SNMP message originated by an SNMP application entity that in fact
 429    belongs to the SNMP community named by the community component of
 430    said message is called an authentic SNMP message.  The set of rules
 431    by which an SNMP message is identified as an authentic SNMP message
 432    for a particular SNMP community is called an authentication scheme.
 433    An implementation of a function that identifies authentic SNMP
 434    messages according to one or more authentication schemes is called an
 435    authentication service.
 436
 437    Clearly, effective management of administrative relationships among
 438    SNMP application entities requires authentication services that (by
 439    the use of encryption or other techniques) are able to identify
 440    authentic SNMP messages with a high degree of certainty.  Some SNMP
 441    implementations may wish to support only a trivial authentication
 442    service that identifies all SNMP messages as authentic SNMP messages.
 443
 444    For any network element, a subset of objects in the MIB that pertain
 445    to that element is called a SNMP MIB view.  Note that the names of
 446    the object types represented in a SNMP MIB view need not belong to a
 447
 448
 449
 450 Case, Fedor, Schoffstall, & Davin                               [Page 8]
 451 \f
 452 RFC 1157                          SNMP                          May 1990
 453
 454
 455    single sub-tree of the object type name space.
 456
 457    An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
 458    access mode.
 459
 460    A pairing of a SNMP access mode with a SNMP MIB view is called an
 461    SNMP community profile.  A SNMP community profile represents
 462    specified access privileges to variables in a specified MIB view. For
 463    every variable in the MIB view in a given SNMP community profile,
 464    access to that variable is represented by the profile according to
 465    the following conventions:
 466
 467       (1)  if said variable is defined in the MIB with "Access:" of
 468            "none," it is unavailable as an operand for any operator;
 469
 470       (2)  if said variable is defined in the MIB with "Access:" of
 471            "read-write" or "write-only" and the access mode of the
 472            given profile is READ-WRITE, that variable is available
 473            as an operand for the get, set, and trap operations;
 474
 475       (3)  otherwise, the variable is available as an operand for
 476            the get and trap operations.
 477
 478       (4)  In those cases where a "write-only" variable is an
 479            operand used for the get or trap operations, the value
 480            given for the variable is implementation-specific.
 481
 482    A pairing of a SNMP community with a SNMP community profile is called
 483    a SNMP access policy. An access policy represents a specified
 484    community profile afforded by the SNMP agent of a specified SNMP
 485    community to other members of that community.  All administrative
 486    relationships among SNMP application entities are architecturally
 487    defined in terms of SNMP access policies.
 488
 489    For every SNMP access policy, if the network element on which the
 490    SNMP agent for the specified SNMP community resides is not that to
 491    which the MIB view for the specified profile pertains, then that
 492    policy is called a SNMP proxy access policy. The SNMP agent
 493    associated with a proxy access policy is called a SNMP proxy agent.
 494    While careless definition of proxy access policies can result in
 495    management loops, prudent definition of proxy policies is useful in
 496    at least two ways:
 497
 498       (1)  It permits the monitoring and control of network elements
 499            which are otherwise not addressable using the management
 500            protocol and the transport protocol.  That is, a proxy
 501            agent may provide a protocol conversion function allowing
 502            a management station to apply a consistent management
 503
 504
 505
 506 Case, Fedor, Schoffstall, & Davin                               [Page 9]
 507 \f
 508 RFC 1157                          SNMP                          May 1990
 509
 510
 511            framework to all network elements, including devices such
 512            as modems, multiplexors, and other devices which support
 513            different management frameworks.
 514
 515       (2)  It potentially shields network elements from elaborate
 516            access control policies.  For example, a proxy agent may
 517            implement sophisticated access control whereby diverse
 518            subsets of variables within the MIB are made accessible
 519            to different management stations without increasing the
 520            complexity of the network element.
 521
 522    By way of example, Figure 1 illustrates the relationship between
 523    management stations, proxy agents, and management agents.  In this
 524    example, the proxy agent is envisioned to be a normal Internet
 525    Network Operations Center (INOC) of some administrative domain which
 526    has a standard managerial relationship with a set of management
 527    agents.
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Case, Fedor, Schoffstall, & Davin                              [Page 10]
 563 \f
 564 RFC 1157                          SNMP                          May 1990
 565
 566
 567    +------------------+       +----------------+      +----------------+
 568    |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
 569    |                  |       |                |      |                |
 570    |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
 571    |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
 572    |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
 573    |                  |       |                |      |                |
 574    +------------------+       +----------------+      +----------------+
 575           /|\                      /|\                     /|\
 576            |                        |                       |
 577            |                        |                       |
 578            |                       \|/                      |
 579            |               +-----------------+              |
 580            +-------------->| Region #3 INOC  |<-------------+
 581                            |                 |
 582                            |Domain=Region #3 |
 583                            |CPU=super-mini-2 |
 584                            |PCommunity=pub,  |
 585                            |         slate   |
 586                            |DCommunity=secret|
 587            +-------------->|                 |<-------------+
 588            |               +-----------------+              |
 589            |                       /|\                      |
 590            |                        |                       |
 591            |                        |                       |
 592           \|/                      \|/                     \|/
 593    +-----------------+     +-----------------+       +-----------------+
 594    |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
 595    |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
 596    |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
 597    +-----------------+     +-----------------+       +-----------------+
 598
 599
 600    Domain:  the administrative domain of the element
 601    PCommunity:  the name of a community utilizing a proxy agent
 602    DCommunity:  the name of a direct community
 603
 604
 605                                  Figure 1
 606                  Example Network Management Configuration
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Case, Fedor, Schoffstall, & Davin                              [Page 11]
 619 \f
 620 RFC 1157                          SNMP                          May 1990
 621
 622
 623 3.2.6.  Form and Meaning of References to Managed Objects
 624
 625    The SMI requires that the definition of a conformant management
 626    protocol address:
 627
 628       (1)  the resolution of ambiguous MIB references,
 629
 630       (2)  the resolution of MIB references in the presence multiple
 631            MIB versions, and
 632
 633       (3)  the identification of particular instances of object
 634            types defined in the MIB.
 635
 636 3.2.6.1.  Resolution of Ambiguous MIB References
 637
 638    Because the scope of any SNMP operation is conceptually confined to
 639    objects relevant to a single network element, and because all SNMP
 640    references to MIB objects are (implicitly or explicitly) by unique
 641    variable names, there is no possibility that any SNMP reference to
 642    any object type defined in the MIB could resolve to multiple
 643    instances of that type.
 644
 645 3.2.6.2.  Resolution of References across MIB Versions
 646
 647    The object instance referred to by any SNMP operation is exactly that
 648    specified as part of the operation request or (in the case of a get-
 649    next operation) its immediate successor in the MIB as a whole.  In
 650    particular, a reference to an object as part of some version of the
 651    Internet-standard MIB does not resolve to any object that is not part
 652    of said version of the Internet-standard MIB, except in the case that
 653    the requested operation is get-next and the specified object name is
 654    lexicographically last among the names of all objects presented as
 655    part of said version of the Internet-Standard MIB.
 656
 657 3.2.6.3.  Identification of Object Instances
 658
 659    The names for all object types in the MIB are defined explicitly
 660    either in the Internet-standard MIB or in other documents which
 661    conform to the naming conventions of the SMI.  The SMI requires that
 662    conformant management protocols define mechanisms for identifying
 663    individual instances of those object types for a particular network
 664    element.
 665
 666    Each instance of any object type defined in the MIB is identified in
 667    SNMP operations by a unique name called its "variable name." In
 668    general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
 669    form x.y, where x is the name of a non-aggregate object type defined
 670    in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
 671
 672
 673
 674 Case, Fedor, Schoffstall, & Davin                              [Page 12]
 675 \f
 676 RFC 1157                          SNMP                          May 1990
 677
 678
 679    specific to the named object type, identifies the desired instance.
 680
 681    This naming strategy admits the fullest exploitation of the semantics
 682    of the GetNextRequest-PDU (see Section 4), because it assigns names
 683    for related variables so as to be contiguous in the lexicographical
 684    ordering of all variable names known in the MIB.
 685
 686    The type-specific naming of object instances is defined below for a
 687    number of classes of object types.  Instances of an object type to
 688    which none of the following naming conventions are applicable are
 689    named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
 690    said object type in the MIB definition.
 691
 692    For example, suppose one wanted to identify an instance of the
 693    variable sysDescr The object class for sysDescr is:
 694
 695              iso org dod internet mgmt mib system sysDescr
 696               1   3   6     1      2    1    1       1
 697
 698    Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
 699    appended an instance sub-identifier of 0.  That is, 1.3.6.1.2.1.1.1.0
 700    identifies the one and only instance of sysDescr.
 701
 702 3.2.6.3.1.  ifTable Object Type Names
 703
 704    The name of a subnet interface, s, is the OBJECT IDENTIFIER value of
 705    the form i, where i has the value of that instance of the ifIndex
 706    object type associated with s.
 707
 708    For each object type, t, for which the defined name, n, has a prefix
 709    of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
 710    the form n.s, where s is the name of the subnet interface about which
 711    i represents information.
 712
 713    For example, suppose one wanted to identify the instance of the
 714    variable ifType associated with interface 2.  Accordingly, ifType.2
 715    would identify the desired instance.
 716
 717 3.2.6.3.2.  atTable Object Type Names
 718
 719    The name of an AT-cached network address, x, is an OBJECT IDENTIFIER
 720    of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar
 721    "dot" notation) of the atNetAddress object type associated with x.
 722
 723    The name of an address translation equivalence e is an OBJECT
 724    IDENTIFIER value of the form s.w, such that s is the value of that
 725    instance of the atIndex object type associated with e and such that w
 726    is the name of the AT-cached network address associated with e.
 727
 728
 729
 730 Case, Fedor, Schoffstall, & Davin                              [Page 13]
 731 \f
 732 RFC 1157                          SNMP                          May 1990
 733
 734
 735    For each object type, t, for which the defined name, n, has a prefix
 736    of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
 737    the form n.y, where y is the name of the address translation
 738    equivalence about which i represents information.
 739
 740    For example, suppose one wanted to find the physical address of an
 741    entry in the address translation table (ARP cache) associated with an
 742    IP address of 89.1.1.42 and interface 3.  Accordingly,
 743    atPhysAddress.3.1.89.1.1.42 would identify the desired instance.
 744
 745 3.2.6.3.3.  ipAddrTable Object Type Names
 746
 747    The name of an IP-addressable network element, x, is the OBJECT
 748    IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the
 749    familiar "dot" notation) of that instance of the ipAdEntAddr object
 750    type associated with x.
 751
 752    For each object type, t, for which the defined name, n, has a prefix
 753    of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER
 754    of the form n.y, where y is the name of the IP-addressable network
 755    element about which i represents information.
 756
 757    For example, suppose one wanted to find the network mask of an entry
 758    in the IP interface table associated with an IP address of 89.1.1.42.
 759    Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired
 760    instance.
 761
 762 3.2.6.3.4.  ipRoutingTable Object Type Names
 763
 764    The name of an IP route, x, is the OBJECT IDENTIFIER of the form
 765    a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
 766    notation) of that instance of the ipRouteDest object type associated
 767    with x.
 768
 769    For each object type, t, for which the defined name, n, has a prefix
 770    of ipRoutingEntry, an instance, i, of t is named by an OBJECT
 771    IDENTIFIER of the form n.y, where y is the name of the IP route about
 772    which i represents information.
 773
 774    For example, suppose one wanted to find the next hop of an entry in
 775    the IP routing table associated  with the destination of 89.1.1.42.
 776    Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired
 777    instance.
 778
 779 3.2.6.3.5.  tcpConnTable Object Type Names
 780
 781    The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form
 782    a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar
 783
 784
 785
 786 Case, Fedor, Schoffstall, & Davin                              [Page 14]
 787 \f
 788 RFC 1157                          SNMP                          May 1990
 789
 790
 791    "dot" notation) of that instance of the tcpConnLocalAddress object
 792    type associated with x and such that f.g.h.i is the value (in the
 793    familiar "dot" notation) of that instance of the tcpConnRemoteAddress
 794    object type associated with x and such that e is the value of that
 795    instance of the tcpConnLocalPort object type associated with x and
 796    such that j is the value of that instance of the tcpConnRemotePort
 797    object type associated with x.
 798
 799    For each object type, t, for which the defined name, n, has a prefix
 800    of  tcpConnEntry, an instance, i, of t is named by an OBJECT
 801    IDENTIFIER of the form n.y, where y is the name of the TCP connection
 802    about which i represents information.
 803
 804    For example, suppose one wanted to find the state of a TCP connection
 805    between the local address of 89.1.1.42 on TCP port 21 and the remote
 806    address of 10.0.0.51 on TCP port 2059.  Accordingly,
 807    tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired
 808    instance.
 809
 810 3.2.6.3.6.  egpNeighTable Object Type Names
 811
 812    The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form
 813    a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
 814    notation) of that instance of the egpNeighAddr object type associated
 815    with x.
 816
 817    For each object type, t, for which the defined name, n, has a prefix
 818    of egpNeighEntry, an instance, i, of t is named by an OBJECT
 819    IDENTIFIER of the form n.y, where y is the name of the EGP neighbor
 820    about which i represents information.
 821
 822    For example, suppose one wanted to find the neighbor state for the IP
 823    address of 89.1.1.42.  Accordingly, egpNeighState.89.1.1.42 would
 824    identify the desired instance.
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Case, Fedor, Schoffstall, & Davin                              [Page 15]
 843 \f
 844 RFC 1157                          SNMP                          May 1990
 845
 846
 847 4.  Protocol Specification
 848
 849    The network management protocol is an application protocol by which
 850    the variables of an agent's MIB may be inspected or altered.
 851
 852    Communication among protocol entities is accomplished by the exchange
 853    of messages, each of which is entirely and independently represented
 854    within a single UDP datagram using the basic encoding rules of ASN.1
 855    (as discussed in Section 3.2.2).  A message consists of a version
 856    identifier, an SNMP community name, and a protocol data unit (PDU).
 857    A protocol entity receives messages at UDP port 161 on the host with
 858    which it is associated for all messages except for those which report
 859    traps (i.e., all messages except those which contain the Trap-PDU).
 860    Messages which report traps should be received on UDP port 162 for
 861    further processing.  An implementation of this protocol need not
 862    accept messages whose length exceeds 484 octets.  However, it is
 863    recommended that implementations support larger datagrams whenever
 864    feasible.
 865
 866    It is mandatory that all implementations of the SNMP support the five
 867    PDUs:  GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU,
 868    SetRequest-PDU, and Trap-PDU.
 869
 870     RFC1157-SNMP DEFINITIONS ::= BEGIN
 871
 872      IMPORTS
 873           ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
 874                   FROM RFC1155-SMI;
 875
 876
 877      -- top-level message
 878
 879              Message ::=
 880                      SEQUENCE {
 881                           version        -- version-1 for this RFC
 882                              INTEGER {
 883                                  version-1(0)
 884                              },
 885
 886                          community      -- community name
 887                              OCTET STRING,
 888
 889                          data           -- e.g., PDUs if trivial
 890                              ANY        -- authentication is being used
 891                      }
 892
 893
 894
 895
 896
 897
 898 Case, Fedor, Schoffstall, & Davin                              [Page 16]
 899 \f
 900 RFC 1157                          SNMP                          May 1990
 901
 902
 903      -- protocol data units
 904
 905              PDUs ::=
 906                      CHOICE {
 907                          get-request
 908                              GetRequest-PDU,
 909
 910                          get-next-request
 911                              GetNextRequest-PDU,
 912
 913                          get-response
 914                              GetResponse-PDU,
 915
 916                          set-request
 917                              SetRequest-PDU,
 918
 919                          trap
 920                              Trap-PDU
 921                           }
 922
 923      -- the individual PDUs and commonly used
 924      -- data types will be defined later
 925
 926      END
 927
 928
 929 4.1.  Elements of Procedure
 930
 931    This section describes the actions of a protocol entity implementing
 932    the SNMP. Note, however, that it is not intended to constrain the
 933    internal architecture of any conformant implementation.
 934
 935    In the text that follows, the term transport address is used.  In the
 936    case of the UDP, a transport address consists of an IP address along
 937    with a UDP port.  Other transport services may be used to support the
 938    SNMP.  In these cases, the definition of a transport address should
 939    be made accordingly.
 940
 941    The top-level actions of a protocol entity which generates a message
 942    are as follows:
 943
 944         (1)  It first constructs the appropriate PDU, e.g., the
 945              GetRequest-PDU, as an ASN.1 object.
 946
 947         (2)  It then passes this ASN.1 object along with a community
 948              name its source transport address and the destination
 949              transport address, to the service which implements the
 950              desired authentication scheme.  This authentication
 951
 952
 953
 954 Case, Fedor, Schoffstall, & Davin                              [Page 17]
 955 \f
 956 RFC 1157                          SNMP                          May 1990
 957
 958
 959              service returns another ASN.1 object.
 960
 961         (3)  The protocol entity then constructs an ASN.1 Message
 962              object, using the community name and the resulting ASN.1
 963              object.
 964
 965         (4)  This new ASN.1 object is then serialized, using the basic
 966              encoding rules of ASN.1, and then sent using a transport
 967              service to the peer protocol entity.
 968
 969    Similarly, the top-level actions of a protocol entity which receives
 970    a message are as follows:
 971
 972         (1)  It performs a rudimentary parse of the incoming datagram
 973              to build an ASN.1 object corresponding to an ASN.1
 974              Message object. If the parse fails, it discards the
 975              datagram and performs no further actions.
 976
 977         (2)  It then verifies the version number of the SNMP message.
 978              If there is a mismatch, it discards the datagram and
 979              performs no further actions.
 980
 981         (3)  The protocol entity then passes the community name and
 982              user data found in the ASN.1 Message object, along with
 983              the datagram's source and destination transport addresses
 984              to the service which implements the desired
 985              authentication scheme.  This entity returns another ASN.1
 986              object, or signals an authentication failure.  In the
 987              latter case, the protocol entity notes this failure,
 988              (possibly) generates a trap, and discards the datagram
 989              and performs no further actions.
 990
 991         (4)  The protocol entity then performs a rudimentary parse on
 992              the ASN.1 object returned from the authentication service
 993              to build an ASN.1 object corresponding to an ASN.1 PDUs
 994              object.  If the parse fails, it discards the datagram and
 995              performs no further actions.  Otherwise, using the named
 996              SNMP community, the appropriate profile is selected, and
 997              the PDU is processed accordingly.  If, as a result of
 998              this processing, a message is returned then the source
 999              transport address that the response message is sent from
1000              shall be identical to the destination transport address
1001              that the original request message was sent to.
1002
1003
1004
1005
1006
1007
1008
1009
1010 Case, Fedor, Schoffstall, & Davin                              [Page 18]
1011 \f
1012 RFC 1157                          SNMP                          May 1990
1013
1014
1015 4.1.1.  Common Constructs
1016
1017    Before introducing the six PDU types of the protocol, it is
1018    appropriate to consider some of the ASN.1 constructs used frequently:
1019
1020                   -- request/response information
1021
1022                   RequestID ::=
1023                           INTEGER
1024
1025                   ErrorStatus ::=
1026                           INTEGER {
1027                               noError(0),
1028                               tooBig(1),
1029                               noSuchName(2),
1030                               badValue(3),
1031                               readOnly(4)
1032                               genErr(5)
1033                           }
1034
1035                   ErrorIndex ::=
1036                           INTEGER
1037
1038
1039                   -- variable bindings
1040
1041                   VarBind ::=
1042                           SEQUENCE {
1043                               name
1044                                   ObjectName,
1045
1046                               value
1047                                   ObjectSyntax
1048                           }
1049
1050                   VarBindList ::=
1051                           SEQUENCE OF
1052                               VarBind
1053
1054
1055    RequestIDs are used to distinguish among outstanding requests.  By
1056    use of the RequestID, an SNMP application entity can correlate
1057    incoming responses with outstanding requests.  In cases where an
1058    unreliable datagram service is being used, the RequestID also
1059    provides a simple means of identifying messages duplicated by the
1060    network.
1061
1062    A non-zero instance of ErrorStatus is used to indicate that an
1063
1064
1065
1066 Case, Fedor, Schoffstall, & Davin                              [Page 19]
1067 \f
1068 RFC 1157                          SNMP                          May 1990
1069
1070
1071    exception occurred while processing a request.  In these cases,
1072    ErrorIndex may provide additional information by indicating which
1073    variable in a list caused the exception.
1074
1075    The term variable refers to an instance of a managed object.  A
1076    variable binding, or VarBind, refers to the pairing of the name of a
1077    variable to the variable's value.  A VarBindList is a simple list of
1078    variable names and corresponding values.  Some PDUs are concerned
1079    only with the name of a variable and not its value (e.g., the
1080    GetRequest-PDU).  In this case, the value portion of the binding is
1081    ignored by the protocol entity.  However, the value portion must
1082    still have valid ASN.1 syntax and encoding.  It is recommended that
1083    the ASN.1 value NULL be used for the value portion of such bindings.
1084
1085 4.1.2.  The GetRequest-PDU
1086
1087              The form of the GetRequest-PDU is:
1088                   GetRequest-PDU ::=
1089                       [0]
1090                           IMPLICIT SEQUENCE {
1091                               request-id
1092                                   RequestID,
1093
1094                               error-status        -- always 0
1095                                   ErrorStatus,
1096
1097                               error-index         -- always 0
1098                                   ErrorIndex,
1099
1100                               variable-bindings
1101                                   VarBindList
1102                           }
1103
1104
1105    The GetRequest-PDU is generated by a protocol entity only at the
1106    request of its SNMP application entity.
1107
1108    Upon receipt of the GetRequest-PDU, the receiving protocol entity
1109    responds according to any applicable rule in the list below:
1110
1111         (1)  If, for any object named in the variable-bindings field,
1112              the object's name does not exactly match the name of some
1113              object available for get operations in the relevant MIB
1114              view, then the receiving entity sends to the originator
1115              of the received message the GetResponse-PDU of identical
1116              form, except that the value of the error-status field is
1117              noSuchName, and the value of the error-index field is the
1118              index of said object name component in the received
1119
1120
1121
1122 Case, Fedor, Schoffstall, & Davin                              [Page 20]
1123 \f
1124 RFC 1157                          SNMP                          May 1990
1125
1126
1127              message.
1128
1129         (2)  If, for any object named in the variable-bindings field,
1130              the object is an aggregate type (as defined in the SMI),
1131              then the receiving entity sends to the originator of the
1132              received message the GetResponse-PDU of identical form,
1133              except that the value of the error-status field is
1134              noSuchName, and the value of the error-index field is the
1135              index of said object name component in the received
1136              message.
1137
1138         (3)  If the size of the GetResponse-PDU generated as described
1139              below would exceed a local limitation, then the receiving
1140              entity sends to the originator of the received message
1141              the GetResponse-PDU of identical form, except that the
1142              value of the error-status field is tooBig, and the value
1143              of the error-index field is zero.
1144
1145         (4)  If, for any object named in the variable-bindings field,
1146              the value of the object cannot be retrieved for reasons
1147              not covered by any of the foregoing rules, then the
1148              receiving entity sends to the originator of the received
1149              message the GetResponse-PDU of identical form, except
1150              that the value of the error-status field is genErr and
1151              the value of the error-index field is the index of said
1152              object name component in the received message.
1153
1154    If none of the foregoing rules apply, then the receiving protocol
1155    entity sends to the originator of the received message the
1156    GetResponse-PDU such that, for each object named in the variable-
1157    bindings field of the received message, the corresponding component
1158    of the GetResponse-PDU represents the name and value of that
1159    variable.  The value of the error- status field of the GetResponse-
1160    PDU is noError and the value of the error-index field is zero.  The
1161    value of the request-id field of the GetResponse-PDU is that of the
1162    received message.
1163
1164 4.1.3.  The GetNextRequest-PDU
1165
1166    The form of the GetNextRequest-PDU is identical to that of the
1167    GetRequest-PDU except for the indication of the PDU type.  In the
1168    ASN.1 language:
1169
1170                   GetNextRequest-PDU ::=
1171                       [1]
1172                           IMPLICIT SEQUENCE {
1173                               request-id
1174                                   RequestID,
1175
1176
1177
1178 Case, Fedor, Schoffstall, & Davin                              [Page 21]
1179 \f
1180 RFC 1157                          SNMP                          May 1990
1181
1182
1183                               error-status        -- always 0
1184                                   ErrorStatus,
1185
1186                               error-index         -- always 0
1187                                   ErrorIndex,
1188
1189                               variable-bindings
1190                                   VarBindList
1191                           }
1192
1193
1194    The GetNextRequest-PDU is generated by a protocol entity only at the
1195    request of its SNMP application entity.
1196
1197    Upon receipt of the GetNextRequest-PDU, the receiving protocol entity
1198    responds according to any applicable rule in the list below:
1199
1200         (1)  If, for any object name in the variable-bindings field,
1201              that name does not lexicographically precede the name of
1202              some object available for get operations in the relevant
1203              MIB view, then the receiving entity sends to the
1204              originator of the received message the GetResponse-PDU of
1205              identical form, except that the value of the error-status
1206              field is noSuchName, and the value of the error-index
1207              field is the index of said object name component in the
1208              received message.
1209
1210         (2)  If the size of the GetResponse-PDU generated as described
1211              below would exceed a local limitation, then the receiving
1212              entity sends to the originator of the received message
1213              the GetResponse-PDU of identical form, except that the
1214              value of the error-status field is tooBig, and the value
1215              of the error-index field is zero.
1216
1217         (3)  If, for any object named in the variable-bindings field,
1218              the value of the lexicographical successor to the named
1219              object cannot be retrieved for reasons not covered by any
1220              of the foregoing rules, then the receiving entity sends
1221              to the originator of the received message the
1222              GetResponse-PDU of identical form, except that the value
1223              of the error-status field is genErr and the value of the
1224              error-index field is the index of said object name
1225              component in the received message.
1226
1227    If none of the foregoing rules apply, then the receiving protocol
1228    entity sends to the originator of the received message the
1229    GetResponse-PDU such that, for each name in the variable-bindings
1230    field of the received message, the corresponding component of the
1231
1232
1233
1234 Case, Fedor, Schoffstall, & Davin                              [Page 22]
1235 \f
1236 RFC 1157                          SNMP                          May 1990
1237
1238
1239    GetResponse-PDU represents the name and value of that object whose
1240    name is, in the lexicographical ordering of the names of all objects
1241    available for get operations in the relevant MIB view, together with
1242    the value of the name field of the given component, the immediate
1243    successor to that value.  The value of the error-status field of the
1244    GetResponse-PDU is noError and the value of the errorindex field is
1245    zero.  The value of the request-id field of the GetResponse-PDU is
1246    that of the received message.
1247
1248 4.1.3.1.  Example of Table Traversal
1249
1250    One important use of the GetNextRequest-PDU is the traversal of
1251    conceptual tables of information within the MIB. The semantics of
1252    this type of SNMP message, together with the protocol-specific
1253    mechanisms for identifying individual instances of object types in
1254    the MIB, affords  access to related objects in the MIB as if they
1255    enjoyed a tabular organization.
1256
1257    By the SNMP exchange sketched below, an SNMP application entity might
1258    extract the destination address and next hop gateway for each entry
1259    in the routing table of a particular network element. Suppose that
1260    this routing table has three entries:
1261
1262          Destination                     NextHop         Metric
1263
1264          10.0.0.99                       89.1.1.42       5
1265          9.1.2.3                         99.0.0.3        3
1266          10.0.0.51                       89.1.1.42       5
1267
1268
1269    The management station sends to the SNMP agent a GetNextRequest-PDU
1270    containing the indicated OBJECT IDENTIFIER values as the requested
1271    variable names:
1272
1273    GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
1274
1275
1276    The SNMP agent responds with a GetResponse-PDU:
1277
1278                  GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
1279                          ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
1280                          ( ipRouteMetric1.9.1.2.3 = 3 ))
1281
1282
1283    The management station continues with:
1284
1285                  GetNextRequest ( ipRouteDest.9.1.2.3,
1286                          ipRouteNextHop.9.1.2.3,
1287
1288
1289
1290 Case, Fedor, Schoffstall, & Davin                              [Page 23]
1291 \f
1292 RFC 1157                          SNMP                          May 1990
1293
1294
1295                          ipRouteMetric1.9.1.2.3 )
1296
1297
1298    The SNMP agent responds:
1299
1300                  GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
1301                          ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
1302                          ( ipRouteMetric1.10.0.0.51 = 5 ))
1303
1304
1305    The management station continues with:
1306
1307                  GetNextRequest ( ipRouteDest.10.0.0.51,
1308                          ipRouteNextHop.10.0.0.51,
1309                          ipRouteMetric1.10.0.0.51 )
1310
1311
1312    The SNMP agent responds:
1313
1314                  GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
1315                          ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
1316                          ( ipRouteMetric1.10.0.0.99 = 5 ))
1317
1318
1319    The management station continues with:
1320
1321                  GetNextRequest ( ipRouteDest.10.0.0.99,
1322                          ipRouteNextHop.10.0.0.99,
1323                          ipRouteMetric1.10.0.0.99 )
1324
1325
1326    As there are no further entries in the table, the SNMP agent returns
1327    those objects that are next in the lexicographical ordering of the
1328    known object names.  This response signals the end of the routing
1329    table to the management station.
1330
1331 4.1.4.  The GetResponse-PDU
1332
1333    The form of the GetResponse-PDU is identical to that of the
1334    GetRequest-PDU except for the indication of the PDU type.  In the
1335    ASN.1 language:
1336
1337                   GetResponse-PDU ::=
1338                       [2]
1339                           IMPLICIT SEQUENCE {
1340                               request-id
1341                                   RequestID,
1342
1343
1344
1345
1346 Case, Fedor, Schoffstall, & Davin                              [Page 24]
1347 \f
1348 RFC 1157                          SNMP                          May 1990
1349
1350
1351                               error-status
1352                                   ErrorStatus,
1353
1354                               error-index
1355                                   ErrorIndex,
1356
1357                               variable-bindings
1358                                   VarBindList
1359                           }
1360
1361
1362    The GetResponse-PDU is generated by a protocol entity only upon
1363    receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU,
1364    as described elsewhere in this document.
1365
1366    Upon receipt of the GetResponse-PDU, the receiving protocol entity
1367    presents its contents to its SNMP application entity.
1368
1369 4.1.5.  The SetRequest-PDU
1370
1371    The form of the SetRequest-PDU is identical to that of the
1372    GetRequest-PDU except for the indication of the PDU type.  In the
1373    ASN.1 language:
1374
1375                   SetRequest-PDU ::=
1376                       [3]
1377                           IMPLICIT SEQUENCE {
1378                               request-id
1379                                   RequestID,
1380
1381                               error-status        -- always 0
1382                                   ErrorStatus,
1383
1384                               error-index         -- always 0
1385                                   ErrorIndex,
1386
1387                               variable-bindings
1388                                   VarBindList
1389                           }
1390
1391
1392    The SetRequest-PDU is generated by a protocol entity only at the
1393    request of its SNMP application entity.
1394
1395    Upon receipt of the SetRequest-PDU, the receiving entity responds
1396    according to any applicable rule in the list below:
1397
1398         (1)  If, for any object named in the variable-bindings field,
1399
1400
1401
1402 Case, Fedor, Schoffstall, & Davin                              [Page 25]
1403 \f
1404 RFC 1157                          SNMP                          May 1990
1405
1406
1407              the object is not available for set operations in the
1408              relevant MIB view, then the receiving entity sends to the
1409              originator of the received message the GetResponse-PDU of
1410              identical form, except that the value of the error-status
1411              field is noSuchName, and the value of the error-index
1412              field is the index of said object name component in the
1413              received message.
1414
1415         (2)  If, for any object named in the variable-bindings field,
1416              the contents of the value field does not, according to
1417              the ASN.1 language, manifest a type, length, and value
1418              that is consistent with that required for the variable,
1419              then the receiving entity sends to the originator of the
1420              received message the GetResponse-PDU of identical form,
1421              except that the value of the error-status field is
1422              badValue, and the value of the error-index field is the
1423              index of said object name in the received message.
1424
1425         (3)  If the size of the Get Response type message generated as
1426              described below would exceed a local limitation, then the
1427              receiving entity sends to the originator of the received
1428              message the GetResponse-PDU of identical form, except
1429              that the value of the error-status field is tooBig, and
1430              the value of the error-index field is zero.
1431
1432         (4)  If, for any object named in the variable-bindings field,
1433              the value of the named object cannot be altered for
1434              reasons not covered by any of the foregoing rules, then
1435              the receiving entity sends to the originator of the
1436              received message the GetResponse-PDU of identical form,
1437              except that the value of the error-status field is genErr
1438              and the value of the error-index field is the index of
1439              said object name component in the received message.
1440
1441    If none of the foregoing rules apply, then for each object named in
1442    the variable-bindings field of the received message, the
1443    corresponding value is assigned to the variable.  Each variable
1444    assignment specified by the SetRequest-PDU should be effected as if
1445    simultaneously set with respect to all other assignments specified in
1446    the same message.
1447
1448    The receiving entity then sends to the originator of the received
1449    message the GetResponse-PDU of identical form except that the value
1450    of the error-status field of the generated message is noError and the
1451    value of the error-index field is zero.
1452
1453
1454
1455
1456
1457
1458 Case, Fedor, Schoffstall, & Davin                              [Page 26]
1459 \f
1460 RFC 1157                          SNMP                          May 1990
1461
1462
1463 4.1.6.  The Trap-PDU
1464
1465    The form of the Trap-PDU is:
1466
1467      Trap-PDU ::=
1468          [4]
1469
1470               IMPLICIT SEQUENCE {
1471                  enterprise          -- type of object generating
1472                                      -- trap, see sysObjectID in [5]
1473                      OBJECT IDENTIFIER,
1474
1475                  agent-addr          -- address of object generating
1476                      NetworkAddress, -- trap
1477
1478                  generic-trap        -- generic trap type
1479                      INTEGER {
1480                          coldStart(0),
1481                          warmStart(1),
1482                          linkDown(2),
1483                          linkUp(3),
1484                          authenticationFailure(4),
1485                          egpNeighborLoss(5),
1486                          enterpriseSpecific(6)
1487                      },
1488
1489                  specific-trap     -- specific code, present even
1490                      INTEGER,      -- if generic-trap is not
1491                                    -- enterpriseSpecific
1492
1493                  time-stamp        -- time elapsed between the last
1494                    TimeTicks,      -- (re)initialization of the network
1495                                    -- entity and the generation of the
1496                                       trap
1497
1498                  variable-bindings   -- "interesting" information
1499                       VarBindList
1500              }
1501
1502
1503    The Trap-PDU is generated by a protocol entity only at the request of
1504    the SNMP application entity.  The means by which an SNMP application
1505    entity selects the destination addresses of the SNMP application
1506    entities is implementation-specific.
1507
1508    Upon receipt of the Trap-PDU, the receiving protocol entity presents
1509    its contents to its SNMP application entity.
1510
1511
1512
1513
1514 Case, Fedor, Schoffstall, & Davin                              [Page 27]
1515 \f
1516 RFC 1157                          SNMP                          May 1990
1517
1518
1519    The significance of the variable-bindings component of the Trap-PDU
1520    is implementation-specific.
1521
1522    Interpretations of the value of the generic-trap field are:
1523
1524 4.1.6.1.  The coldStart Trap
1525
1526    A coldStart(0) trap signifies that the sending protocol entity is
1527    reinitializing itself such that the agent's configuration or the
1528    protocol entity implementation may be altered.
1529
1530 4.1.6.2.  The warmStart Trap
1531
1532    A warmStart(1) trap signifies that the sending protocol entity is
1533    reinitializing itself such that neither the agent configuration nor
1534    the protocol entity implementation is altered.
1535
1536 4.1.6.3.  The linkDown Trap
1537
1538    A linkDown(2) trap signifies that the sending protocol entity
1539    recognizes a failure in one of the communication links represented in
1540    the agent's configuration.
1541
1542    The Trap-PDU of type linkDown contains as the first element of its
1543    variable-bindings, the name and value of the ifIndex instance for the
1544    affected interface.
1545
1546 4.1.6.4.  The linkUp Trap
1547
1548    A linkUp(3) trap signifies that the sending protocol entity
1549    recognizes that one of the communication links represented in the
1550    agent's configuration has come up.
1551
1552    The Trap-PDU of type linkUp contains as the first element of its
1553    variable-bindings, the name and value of the ifIndex instance for the
1554    affected interface.
1555
1556 4.1.6.5.  The authenticationFailure Trap
1557
1558    An authenticationFailure(4) trap signifies that the sending protocol
1559    entity is the addressee of a protocol message that is not properly
1560    authenticated.  While implementations of the SNMP must be capable of
1561    generating this trap, they must also be capable of suppressing the
1562    emission of such traps via an implementation-specific mechanism.
1563
1564 4.1.6.6.  The egpNeighborLoss Trap
1565
1566    An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
1567
1568
1569
1570 Case, Fedor, Schoffstall, & Davin                              [Page 28]
1571 \f
1572 RFC 1157                          SNMP                          May 1990
1573
1574
1575    the sending protocol entity was an EGP peer has been marked down and
1576    the peer relationship no longer obtains.
1577
1578    The Trap-PDU of type egpNeighborLoss contains as the first element of
1579    its variable-bindings, the name and value of the egpNeighAddr
1580    instance for the affected neighbor.
1581
1582 4.1.6.7.  The enterpriseSpecific Trap
1583
1584    A enterpriseSpecific(6) trap signifies that the sending protocol
1585    entity recognizes that some enterprise-specific event has occurred.
1586    The specific-trap field identifies the particular trap which
1587    occurred.
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626 Case, Fedor, Schoffstall, & Davin                              [Page 29]
1627 \f
1628 RFC 1157                          SNMP                          May 1990
1629
1630
1631 5.  Definitions
1632
1633      RFC1157-SNMP DEFINITIONS ::= BEGIN
1634
1635       IMPORTS
1636           ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
1637               FROM RFC1155-SMI;
1638
1639
1640           -- top-level message
1641
1642           Message ::=
1643                   SEQUENCE {
1644                       version          -- version-1 for this RFC
1645                           INTEGER {
1646                               version-1(0)
1647                           },
1648
1649                       community        -- community name
1650                           OCTET STRING,
1651
1652                       data             -- e.g., PDUs if trivial
1653                           ANY          -- authentication is being used
1654                   }
1655
1656
1657           -- protocol data units
1658
1659           PDUs ::=
1660                   CHOICE {
1661                               get-request
1662                                   GetRequest-PDU,
1663
1664                               get-next-request
1665                                   GetNextRequest-PDU,
1666
1667                               get-response
1668                                   GetResponse-PDU,
1669
1670                               set-request
1671                                   SetRequest-PDU,
1672
1673                               trap
1674                                   Trap-PDU
1675                           }
1676
1677
1678
1679
1680
1681
1682 Case, Fedor, Schoffstall, & Davin                              [Page 30]
1683 \f
1684 RFC 1157                          SNMP                          May 1990
1685
1686
1687           -- PDUs
1688
1689           GetRequest-PDU ::=
1690               [0]
1691                   IMPLICIT PDU
1692
1693           GetNextRequest-PDU ::=
1694               [1]
1695                   IMPLICIT PDU
1696
1697           GetResponse-PDU ::=
1698               [2]
1699                   IMPLICIT PDU
1700
1701           SetRequest-PDU ::=
1702               [3]
1703                   IMPLICIT PDU
1704
1705           PDU ::=
1706                   SEQUENCE {
1707                      request-id
1708                           INTEGER,
1709
1710                       error-status      -- sometimes ignored
1711                           INTEGER {
1712                               noError(0),
1713                               tooBig(1),
1714                               noSuchName(2),
1715                               badValue(3),
1716                               readOnly(4),
1717                               genErr(5)
1718                           },
1719
1720                       error-index       -- sometimes ignored
1721                          INTEGER,
1722
1723                       variable-bindings -- values are sometimes ignored
1724                           VarBindList
1725                   }
1726
1727           Trap-PDU ::=
1728               [4]
1729                  IMPLICIT SEQUENCE {
1730                       enterprise        -- type of object generating
1731                                         -- trap, see sysObjectID in [5]
1732
1733
1734                           OBJECT IDENTIFIER,
1735
1736
1737
1738 Case, Fedor, Schoffstall, & Davin                              [Page 31]
1739 \f
1740 RFC 1157                          SNMP                          May 1990
1741
1742
1743                       agent-addr        -- address of object generating
1744                           NetworkAddress, -- trap
1745
1746                       generic-trap      -- generic trap type
1747                           INTEGER {
1748                               coldStart(0),
1749                               warmStart(1),
1750                               linkDown(2),
1751                               linkUp(3),
1752                               authenticationFailure(4),
1753                               egpNeighborLoss(5),
1754                               enterpriseSpecific(6)
1755                           },
1756
1757                       specific-trap  -- specific code, present even
1758                           INTEGER,   -- if generic-trap is not
1759                                      -- enterpriseSpecific
1760
1761                       time-stamp     -- time elapsed between the last
1762                           TimeTicks, -- (re)initialization of the
1763                                         network
1764                                      -- entity and the generation of the
1765                                         trap
1766
1767                        variable-bindings -- "interesting" information
1768                           VarBindList
1769                   }
1770
1771
1772           -- variable bindings
1773
1774           VarBind ::=
1775                   SEQUENCE {
1776                       name
1777                           ObjectName,
1778
1779                       value
1780                           ObjectSyntax
1781                   }
1782
1783          VarBindList ::=
1784                   SEQUENCE OF
1785                      VarBind
1786
1787          END
1788
1789
1790
1791
1792
1793
1794 Case, Fedor, Schoffstall, & Davin                              [Page 32]
1795 \f
1796 RFC 1157                          SNMP                          May 1990
1797
1798
1799 6.  Acknowledgements
1800
1801    This memo was influenced by the IETF SNMP Extensions working
1802    group:
1803
1804              Karl Auerbach, Epilogue Technology
1805              K. Ramesh Babu, Excelan
1806              Amatzia Ben-Artzi, 3Com/Bridge
1807              Lawrence Besaw, Hewlett-Packard
1808              Jeffrey D. Case, University of Tennessee at Knoxville
1809              Anthony Chung, Sytek
1810              James Davidson, The Wollongong Group
1811              James R. Davin, MIT Laboratory for Computer Science
1812              Mark S. Fedor, NYSERNet
1813              Phill Gross, The MITRE Corporation
1814              Satish Joshi, ACC
1815              Dan Lynch, Advanced Computing Environments
1816              Keith McCloghrie, The Wollongong Group
1817              Marshall T. Rose, The Wollongong Group (chair)
1818              Greg Satz, cisco
1819              Martin Lee Schoffstall, Rensselaer Polytechnic Institute
1820              Wengyik Yeong, NYSERNet
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850 Case, Fedor, Schoffstall, & Davin                              [Page 33]
1851 \f
1852 RFC 1157                          SNMP                          May 1990
1853
1854
1855 7.  References
1856
1857    [1] Cerf, V., "IAB Recommendations for the Development of
1858        Internet Network Management Standards", RFC 1052, IAB,
1859        April 1988.
1860
1861    [2] Rose, M., and K. McCloghrie, "Structure and Identification
1862        of Management Information for TCP/IP-based internets",
1863        RFC 1065, TWG, August 1988.
1864
1865    [3] McCloghrie, K., and M. Rose, "Management Information Base
1866        for Network Management of TCP/IP-based internets",
1867        RFC 1066, TWG, August 1988.
1868
1869    [4] Cerf, V., "Report of the Second Ad Hoc Network Management
1870        Review Group", RFC 1109, IAB, August 1989.
1871
1872    [5] Rose, M., and K. McCloghrie, "Structure and Identification
1873        of Management Information for TCP/IP-based Internets",
1874        RFC 1155, Performance Systems International and Hughes LAN
1875        Systems, May 1990.
1876
1877    [6] McCloghrie, K., and M. Rose, "Management Information Base
1878        for Network Management of TCP/IP-based Internets",
1879        RFC 1156, Hughes LAN Systems and Performance Systems
1880        International, May 1990.
1881
1882    [7] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
1883        "A Simple Network Management Protocol", Internet
1884        Engineering Task Force working note, Network Information
1885        Center, SRI International, Menlo Park, California,
1886        March 1988.
1887
1888    [8] Davin, J., J. Case, M. Fedor, and M. Schoffstall,
1889        "A Simple Gateway Monitoring Protocol", RFC 1028,
1890        Proteon, University of Tennessee at Knoxville,
1891        Cornell University, and Rensselaer Polytechnic
1892        Institute, November 1987.
1893
1894    [9] Information processing systems - Open Systems
1895        Interconnection, "Specification of Abstract Syntax
1896        Notation One (ASN.1)", International Organization for
1897        Standardization, International Standard 8824,
1898        December 1987.
1899
1900   [10] Information processing systems - Open Systems
1901        Interconnection, "Specification of Basic Encoding Rules
1902        for Abstract Notation One (ASN.1)", International
1903
1904
1905
1906 Case, Fedor, Schoffstall, & Davin                              [Page 34]
1907 \f
1908 RFC 1157                          SNMP                          May 1990
1909
1910
1911        Organization for Standardization, International Standard
1912        8825, December 1987.
1913
1914   [11] Postel, J., "User Datagram Protocol", RFC 768,
1915        USC/Information Sciences Institute, November 1980.
1916
1917 Security Considerations
1918
1919    Security issues are not discussed in this memo.
1920
1921 Authors' Addresses
1922
1923    Jeffrey D. Case
1924    SNMP Research
1925    P.O. Box 8593
1926    Knoxville, TN 37996-4800
1927
1928    Phone:  (615) 573-1434
1929
1930    Email:  case@CS.UTK.EDU
1931
1932
1933    Mark Fedor
1934    Performance Systems International
1935    Rensselaer Technology Park
1936    125 Jordan Road
1937    Troy, NY 12180
1938
1939    Phone:  (518) 283-8860
1940
1941    Email:  fedor@patton.NYSER.NET
1942
1943
1944    Martin Lee Schoffstall
1945    Performance Systems International
1946    Rensselaer Technology Park
1947    165 Jordan Road
1948    Troy, NY 12180
1949
1950    Phone:  (518) 283-8860
1951
1952    Email:  schoff@NISC.NYSER.NET
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962 Case, Fedor, Schoffstall, & Davin                              [Page 35]
1963 \f
1964 RFC 1157                          SNMP                          May 1990
1965
1966
1967    James R. Davin
1968    MIT Laboratory for Computer Science, NE43-507
1969    545 Technology Square
1970    Cambridge, MA 02139
1971
1972    Phone:  (617) 253-6020
1973
1974    EMail:  jrd@ptt.lcs.mit.edu
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018 Case, Fedor, Schoffstall, & Davin                              [Page 36]
2019 \f