net-snmp 1.2.1 → 1.2.5

package/ref/rfc/v1/rfc1067.txt

@@ -1,1851 +1,1851 @@
-
-
-
-
-
-
-Network Working Group                                            J. Case
-Request for Comments: 1067          University of Tennessee at Knoxville
-                                                                M. Fedor
-                                                          NYSERNet, Inc.
-                                                          M. Schoffstall
-                                        Rensselaer Polytechnic Institute
-                                                                J. Davin
-                                                           Proteon, Inc.
-                                                             August 1988
-
-
-                  A Simple Network Management Protocol
-
-                           Table of Contents
-
-   1. Status of this Memo ...................................    2
-   2. Introduction ..........................................    2
-   3. The SNMP Architecture .................................    4
-   3.1 Goals of the Architecture ............................    4
-   3.2 Elements of the Architecture .........................    4
-   3.2.1 Scope of Management Information ....................    5
-   3.2.2 Representation of Management Information ...........    5
-   3.2.3 Operations Supported on Management Information .....    6
-   3.2.4 Form and Meaning of Protocol Exchanges .............    7
-   3.2.5 Definition of Administrative Relationships .........    7
-   3.2.6 Form and Meaning of References to Managed Objects ..   11
-   3.2.6.1 Resolution of Ambiguous MIB References ...........   11
-   3.2.6.2 Resolution of References across MIB Versions......   11
-   3.2.6.3 Identification of Object Instances ...............   11
-   3.2.6.3.1 ifTable Object Type Names ......................   12
-   3.2.6.3.2 atTable Object Type Names ......................   12
-   3.2.6.3.3 ipAddrTable Object Type Names ..................   13
-   3.2.6.3.4 ipRoutingTable Object Type Names ...............   13
-   3.2.6.3.5 tcpConnTable Object Type Names .................   13
-   3.2.6.3.6 egpNeighTable Object Type Names ................   14
-   4. Protocol Specification ................................   15
-   4.1 Elements of Procedure ................................   16
-   4.1.1 Common Constructs ..................................   18
-   4.1.2 The GetRequest-PDU .................................   19
-   4.1.3 The GetNextRequest-PDU .............................   20
-   4.1.3.1 Example of Table Traversal .......................   22
-   4.1.4 The GetResponse-PDU ................................   23
-   4.1.5 The SetRequest-PDU .................................   24
-   4.1.6 The Trap-PDU .......................................   26
-   4.1.6.1 The coldStart Trap ...............................   27
-   4.1.6.2 The warmStart Trap ...............................   27
-   4.1.6.3 The linkDown Trap ................................   27
-   4.1.6.4 The linkUp Trap ..................................   27
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 1]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   4.1.6.5 The authenticationFailure Trap ...................   27
-   4.1.6.6 The egpNeighborLoss Trap .........................   27
-   4.1.6.7 The enterpriseSpecific Trap ......................   28
-   5. Definitions ...........................................   29
-   6. Acknowledgements ......................................   32
-   7. References ............................................   33
-
-1.  Status of this Memo
-
-   This memo defines a simple protocol by which management information
-   for a network element may be inspected or altered by logically remote
-   users.  In particular, together with its companion memos which
-   describe the structure of management information along with the
-   initial management information base, these documents provide a
-   simple, workable architecture and system for managing TCP/IP-based
-   internets and in particular the Internet.
-
-   This memo specifies a draft standard for the Internet community.
-   TCP/IP implementations in the Internet which are network manageable
-   are expected to adopt and implement this specification.
-
-   Distribution of this memo is unlimited.
-
-2.  Introduction
-
-   As reported in RFC 1052, IAB Recommendations for the Development of
-   Internet Network Management Standards [1], the Internet Activities
-   Board has directed the Internet Engineering Task Force (IETF) to
-   create two new working groups in the area of network management.  One
-   group is charged with the further specification and definition of
-   elements to be included in the Management Information Base (MIB).
-   The other is charged with defining the modifications to the Simple
-   Network Management Protocol (SNMP) to accommodate the short-term
-   needs of the network vendor and operations communities, and to align
-   with the output of the MIB working group.
-
-   The MIB working group has produced two memos, one which defines a
-   Structure for Management Information (SMI) [2] for use by the managed
-   objects contained in the MIB.  A second memo [3] defines the list of
-   managed objects.
-
-   The output of the SNMP Extensions working group is this memo, which
-   incorporates changes to the initial SNMP definition [4] required to
-   attain alignment with the output of the MIB working group.  The
-   changes should be minimal in order to be consistent with the IAB's
-   directive that the working groups be "extremely sensitive to the need
-   to keep the SNMP simple."  Although considerable care and debate has
-   gone into the changes to the SNMP which are reflected in this memo,
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 2]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   the resulting protocol is not backwardly-compatible with its
-   predecessor, the Simple Gateway Monitoring Protocol (SGMP) [5].
-   Although the syntax of the protocol has been altered, the original
-   philosophy, design decisions, and architecture remain intact.  In
-   order to avoid confusion, new UDP ports have been allocated for use
-   by the protocol described in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 3]
-
-RFC 1067                          SNMP                       August 1988
-
-
-3.  The SNMP Architecture
-
-   Implicit in the SNMP architectural model is a collection of network
-   management stations and network elements.  Network management
-   stations execute management applications which monitor and control
-   network elements.  Network elements are devices such as hosts,
-   gateways, terminal servers, and the like, which have management
-   agents responsible for performing the network management functions
-   requested by the network management stations.  The Simple Network
-   Management Protocol (SNMP) is used to communicate management
-   information between the network management stations and the agents in
-   the network elements.
-
-3.1.  Goals of the Architecture
-
-   The SNMP explicitly minimizes the number and complexity of management
-   functions realized by the management agent itself.  This goal is
-   attractive in at least four respects:
-
-      (1)  The development cost for management agent software
-           necessary to support the protocol is accordingly reduced.
-
-      (2)  The degree of management function that is remotely
-           supported is accordingly increased, thereby admitting
-           fullest use of internet resources in the management task.
-
-      (3)  The degree of management function that is remotely
-           supported is accordingly increased, thereby imposing the
-           fewest possible restrictions on the form and
-           sophistication of management tools.
-
-      (4)  Simplified sets of management functions are easily
-           understood and used by developers of network management
-           tools.
-
-   A second goal of the protocol is that the functional paradigm for
-   monitoring and control be sufficiently extensible to accommodate
-   additional, possibly unanticipated aspects of network operation and
-   management.
-
-   A third goal is that the architecture be, as much as possible,
-   independent of the architecture and mechanisms of particular hosts or
-   particular gateways.
-
-3.2.  Elements of the Architecture
-
-   The SNMP architecture articulates a solution to the network
-   management problem in terms of:
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 4]
-
-RFC 1067                          SNMP                       August 1988
-
-
-      (1)  the scope of the management information communicated by
-           the protocol,
-
-      (2)  the representation of the management information
-           communicated by the protocol,
-
-      (3)  operations on management information supported by the
-           protocol,
-
-      (4)  the form and meaning of exchanges among management
-           entities,
-
-      (5)  the definition of administrative relationships among
-           management entities, and
-
-      (6)  the form and meaning of references to management
-           information.
-
-3.2.1.  Scope of Management Information
-
-   The scope of the management information communicated by operation of
-   the SNMP is exactly that represented by instances of all non-
-   aggregate object types either defined in Internet-standard MIB or
-   defined elsewhere according to the conventions set forth in
-   Internet-standard SMI [2].
-
-   Support for aggregate object types in the MIB is neither required for
-   conformance with the SMI nor realized by the SNMP.
-
-3.2.2.  Representation of Management Information
-
-   Management information communicated by operation of the SNMP is
-   represented according to the subset of the ASN.1 language [6] that is
-   specified for the definition of non-aggregate types in the SMI.
-
-   The SGMP adopted the convention of using a well-defined subset of the
-   ASN.1 language [6].  The SNMP continues and extends this tradition by
-   utilizing a moderately more complex subset of ASN.1 for describing
-   managed objects and for describing the protocol data units used for
-   managing those objects.  In addition, the desire to ease eventual
-   transition to OSI-based network management protocols led to the
-   definition in the ASN.1 language of an Internet-standard Structure of
-   Management Information (SMI) [2] and Management Information Base
-   (MIB) [3].  The use of the ASN.1 language, was, in part, encouraged
-   by the successful use of ASN.1 in earlier efforts, in particular, the
-   SGMP.  The restrictions on the use of ASN.1 that are part of the SMI
-   contribute to the simplicity espoused and validated by experience
-   with the SGMP.
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 5]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   Also for the sake of simplicity, the SNMP uses only a subset of the
-   basic encoding rules of ASN.1 [7].  Namely, all encodings use the
-   definite-length form.  Further, whenever permissible, non-constructor
-   encodings are used rather than constructor encodings.  This
-   restriction applies to all aspects of ASN.1 encoding, both for the
-   top-level protocol data units and the data objects they contain.
-
-3.2.3.  Operations Supported on Management Information
-
-   The SNMP models all management agent functions as alterations or
-   inspections of variables.  Thus, a protocol entity on a logically
-   remote host (possibly the network element itself) interacts with the
-   management agent resident on the network element in order to retrieve
-   (get) or alter (set) variables.  This strategy has at least two
-   positive consequences:
-
-      (1)  It has the effect of limiting the number of essential
-           management functions realized by the management agent to
-           two: one operation to assign a value to a specified
-           configuration or other parameter and another to retrieve
-           such a value.
-
-      (2)  A second effect of this decision is to avoid introducing
-           into the protocol definition support for imperative
-           management commands:  the number of such commands is in
-           practice ever-increasing, and the semantics of such
-           commands are in general arbitrarily complex.
-
-   The strategy implicit in the SNMP is that the monitoring of network
-   state at any significant level of detail is accomplished primarily by
-   polling for appropriate information on the part of the monitoring
-   center(s).  A limited number of unsolicited messages (traps) guide
-   the timing and focus of the polling.  Limiting the number of
-   unsolicited messages is consistent with the goal of simplicity and
-   minimizing the amount of traffic generated by the network management
-   function.
-
-   The exclusion of imperative commands from the set of explicitly
-   supported management functions is unlikely to preclude any desirable
-   management agent operation.  Currently, most commands are requests
-   either to set the value of some parameter or to retrieve such a
-   value, and the function of the few imperative commands currently
-   supported is easily accommodated in an asynchronous mode by this
-   management model.  In this scheme, an imperative command might be
-   realized as the setting of a parameter value that subsequently
-   triggers the desired action.  For example, rather than implementing a
-   "reboot command," this action might be invoked by simply setting a
-   parameter indicating the number of seconds until system reboot.
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 6]
-
-RFC 1067                          SNMP                       August 1988
-
-
-3.2.4.  Form and Meaning of Protocol Exchanges
-
-   The communication of management information among management entities
-   is realized in the SNMP through the exchange of protocol messages.
-   The form and meaning of those messages is defined below in Section 4.
-
-   Consistent with the goal of minimizing complexity of the management
-   agent, the exchange of SNMP messages requires only an unreliable
-   datagram service, and every message is entirely and independently
-   represented by a single transport datagram.  While this document
-   specifies the exchange of messages via the UDP protocol [8], the
-   mechanisms of the SNMP are generally suitable for use with a wide
-   variety of transport services.
-
-3.2.5.  Definition of Administrative Relationships
-
-   The SNMP architecture admits a variety of administrative
-   relationships among entities that participate in the protocol.  The
-   entities residing at management stations and network elements which
-   communicate with one another using the SNMP are termed SNMP
-   application entities.  The peer processes which implement the SNMP,
-   and thus support the SNMP application entities, are termed protocol
-   entities.
-
-   A pairing of an SNMP agent with some arbitrary set of SNMP
-   application entities is called an SNMP community.  Each SNMP
-   community is named by a string of octets, that is called the
-   community name for said community.
-
-   An SNMP message originated by an SNMP application entity that in fact
-   belongs to the SNMP community named by the community component of
-   said message is called an authentic SNMP message.  The set of rules
-   by which an SNMP message is identified as an authentic SNMP message
-   for a particular SNMP community is called an authentication scheme.
-   An implementation of a function that identifies authentic SNMP
-   messages according to one or more authentication schemes is called an
-   authentication service.
-
-   Clearly, effective management of administrative relationships among
-   SNMP application entities requires authentication services that (by
-   the use of encryption or other techniques) are able to identify
-   authentic SNMP messages with a high degree of certainty.  Some SNMP
-   implementations may wish to support only a trivial authentication
-   service that identifies all SNMP messages as authentic SNMP messages.
-
-   For any network element, a subset of objects in the MIB that pertain
-   to that element is called a SNMP MIB view.  Note that the names of
-   the object types represented in a SNMP MIB view need not belong to a
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 7]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   single sub-tree of the object type name space.
-
-   An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
-   access mode.
-
-   A pairing of a SNMP access mode with a SNMP MIB view is called an
-   SNMP community profile.  A SNMP community profile represents
-   specified access privileges to variables in a specified MIB view. For
-   every variable in the MIB view in a given SNMP community profile,
-   access to that variable is represented by the profile according to
-   the following conventions:
-
-      (1)  if said variable is defined in the MIB with "Access:" of
-           "none," it is unavailable as an operand for any operator;
-
-      (2)  if said variable is defined in the MIB with "Access:" of
-           "read-write" or "write-only" and the access mode of the
-           given profile is READ-WRITE, that variable is available
-           as an operand for the get, set, and trap operations;
-
-      (3)  otherwise, the variable is available as an operand for
-           the get and trap operations.
-
-      (4)  In those cases where a "write-only" variable is an
-           operand used for the get or trap operations, the value
-           given for the variable is implementation-specific.
-
-   A pairing of a SNMP community with a SNMP community profile is called
-   a SNMP access policy. An access policy represents a specified
-   community profile afforded by the SNMP agent of a specified SNMP
-   community to other members of that community.  All administrative
-   relationships among SNMP application entities are architecturally
-   defined in terms of SNMP access policies.
-
-   For every SNMP access policy, if the network element on which the
-   SNMP agent for the specified SNMP community resides is not that to
-   which the MIB view for the specified profile pertains, then that
-   policy is called a SNMP proxy access policy. The SNMP agent
-   associated with a proxy access policy is called a SNMP proxy agent.
-   While careless definition of proxy access policies can result in
-   management loops, prudent definition of proxy policies is useful in
-   at least two ways:
-
-      (1)  It permits the monitoring and control of network elements
-           which are otherwise not addressable using the management
-           protocol and the transport protocol.  That is, a proxy
-           agent may provide a protocol conversion function allowing
-           a management station to apply a consistent management
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 8]
-
-RFC 1067                          SNMP                       August 1988
-
-
-           framework to all network elements, including devices such
-           as modems, multiplexors, and other devices which support
-           different management frameworks.
-
-      (2)  It potentially shields network elements from elaborate
-           access control policies.  For example, a proxy agent may
-           implement sophisticated access control whereby diverse
-           subsets of variables within the MIB are made accessible
-           to different management stations without increasing the
-           complexity of the network element.
-
-   By way of example, Figure 1 illustrates the relationship between
-   management stations, proxy agents, and management agents.  In this
-   example, the proxy agent is envisioned to be a normal Internet
-   Network Operations Center (INOC) of some administrative domain which
-   has a standard managerial relationship with a set of management
-   agents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                               [Page 9]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   +------------------+       +----------------+      +----------------+
-   |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
-   |                  |       |                |      |                |
-   |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
-   |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
-   |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
-   |                  |       |                |      |                |
-   +------------------+       +----------------+      +----------------+
-          /|\                      /|\                     /|\
-           |                        |                       |
-           |                        |                       |
-           |                       \|/                      |
-           |               +-----------------+              |
-           +-------------->| Region #3 INOC  |<-------------+
-                           |                 |
-                           |Domain=Region #3 |
-                           |CPU=super-mini-2 |
-                           |PCommunity=pub,  |
-                           |         slate   |
-                           |DCommunity=secret|
-           +-------------->|                 |<-------------+
-           |               +-----------------+              |
-           |                       /|\                      |
-           |                        |                       |
-           |                        |                       |
-          \|/                      \|/                     \|/
-   +-----------------+     +-----------------+       +-----------------+
-   |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
-   |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
-   |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
-   +-----------------+     +-----------------+       +-----------------+
-
-
-   Domain:  the administrative domain of the element
-   PCommunity:  the name of a community utilizing a proxy agent
-   DCommunity:  the name of a direct community
-
-
-                                 Figure 1
-                 Example Network Management Configuration
-
-
-
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 10]
-
-RFC 1067                          SNMP                       August 1988
-
-
-3.2.6.  Form and Meaning of References to Managed Objects
-
-   The SMI requires that the definition of a conformant management
-   protocol address:
-
-      (1)  the resolution of ambiguous MIB references,
-
-      (2)  the resolution of MIB references in the presence multiple
-           MIB versions, and
-
-      (3)  the identification of particular instances of object
-           types defined in the MIB.
-
-3.2.6.1.  Resolution of Ambiguous MIB References
-
-   Because the scope of any SNMP operation is conceptually confined to
-   objects relevant to a single network element, and because all SNMP
-   references to MIB objects are (implicitly or explicitly) by unique
-   variable names, there is no possibility that any SNMP reference to
-   any object type defined in the MIB could resolve to multiple
-   instances of that type.
-
-3.2.6.2.  Resolution of References across MIB Versions
-
-   The object instance referred to by any SNMP operation is exactly that
-   specified as part of the operation request or (in the case of a get-
-   next operation) its immediate successor in the MIB as a whole.  In
-   particular, a reference to an object as part of some version of the
-   Internet-standard MIB does not resolve to any object that is not part
-   of said version of the Internet-standard MIB, except in the case that
-   the requested operation is get-next and the specified object name is
-   lexicographically last among the names of all objects presented as
-   part of said version of the Internet-Standard MIB.
-
-3.2.6.3.  Identification of Object Instances
-
-   The names for all object types in the MIB are defined explicitly
-   either in the Internet-standard MIB or in other documents which
-   conform to the naming conventions of the SMI.  The SMI requires that
-   conformant management protocols define mechanisms for identifying
-   individual instances of those object types for a particular network
-   element.
-
-   Each instance of any object type defined in the MIB is identified in
-   SNMP operations by a unique name called its "variable name." In
-   general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
-   form x.y, where x is the name of a non-aggregate object type defined
-   in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 11]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   specific to the named object type, identifies the desired instance.
-
-   This naming strategy admits the fullest exploitation of the semantics
-   of the GetNextRequest-PDU (see Section 4), because it assigns names
-   for related variables so as to be contiguous in the lexicographical
-   ordering of all variable names known in the MIB.
-
-   The type-specific naming of object instances is defined below for a
-   number of classes of object types.  Instances of an object type to
-   which none of the following naming conventions are applicable are
-   named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
-   said object type in the MIB definition.
-
-   For example, suppose one wanted to identify an instance of the
-   variable sysDescr The object class for sysDescr is:
-
-             iso org dod internet mgmt mib system sysDescr
-              1   3   6     1      2    1    1       1
-
-   Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
-   appended an instance sub-identifier of 0.  That is, 1.3.6.1.2.1.1.1.0
-   identifies the one and only instance of sysDescr.
-
-3.2.6.3.1.  ifTable Object Type Names
-
-   The name of a subnet interface, s, is the OBJECT IDENTIFIER value of
-   the form i, where i has the value of that instance of the ifIndex
-   object type associated with s.
-
-   For each object type, t, for which the defined name, n, has a prefix
-   of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
-   the form n.s, where s is the name of the subnet interface about which
-   i represents information.
-
-   For example, suppose one wanted to identify the instance of the
-   variable ifType associated with interface 2.  Accordingly, ifType.2
-   would identify the desired instance.
-
-3.2.6.3.2.  atTable Object Type Names
-
-   The name of an AT-cached network address, x, is an OBJECT IDENTIFIER
-   of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar
-   "dot" notation) of the atNetAddress object type associated with x.
-
-   The name of an address translation equivalence e is an OBJECT
-   IDENTIFIER value of the form s.w, such that s is the value of that
-   instance of the atIndex object type associated with e and such that w
-   is the name of the AT-cached network address associated with e.
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 12]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   For each object type, t, for which the defined name, n, has a prefix
-   of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
-   the form n.y, where y is the name of the address translation
-   equivalence about which i represents information.
-
-   For example, suppose one wanted to find the physical address of an
-   entry in the address translation table (ARP cache) associated with an
-   IP address of 89.1.1.42 and interface 3.  Accordingly,
-   atPhysAddress.3.1.89.1.1.42 would identify the desired instance.
-
-3.2.6.3.3.  ipAddrTable Object Type Names
-
-   The name of an IP-addressable network element, x, is the OBJECT
-   IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the
-   familiar "dot" notation) of that instance of the ipAdEntAddr object
-   type associated with x.
-
-   For each object type, t, for which the defined name, n, has a prefix
-   of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER
-   of the form n.y, where y is the name of the IP-addressable network
-   element about which i represents information.
-
-   For example, suppose one wanted to find the network mask of an entry
-   in the IP interface table associated with an IP address of 89.1.1.42.
-   Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired
-   instance.
-
-3.2.6.3.4.  ipRoutingTable Object Type Names
-
-   The name of an IP route, x, is the OBJECT IDENTIFIER of the form
-   a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
-   notation) of that instance of the ipRouteDest object type associated
-   with x.
-
-   For each object type, t, for which the defined name, n, has a prefix
-   of ipRoutingEntry, an instance, i, of t is named by an OBJECT
-   IDENTIFIER of the form n.y, where y is the name of the IP route about
-   which i represents information.
-
-   For example, suppose one wanted to find the next hop of an entry in
-   the IP routing table associated  with the destination of 89.1.1.42.
-   Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired
-   instance.
-
-3.2.6.3.5.  tcpConnTable Object Type Names
-
-   The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form
-   a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 13]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   "dot" notation) of that instance of the tcpConnLocalAddress object
-   type associated with x and such that f.g.h.i is the value (in the
-   familiar "dot" notation) of that instance of the tcpConnRemoteAddress
-   object type associated with x and such that e is the value of that
-   instance of the tcpConnLocalPort object type associated with x and
-   such that j is the value of that instance of the tcpConnRemotePort
-   object type associated with x.
-
-   For each object type, t, for which the defined name, n, has a prefix
-   of  tcpConnEntry, an instance, i, of t is named by an OBJECT
-   IDENTIFIER of the form n.y, where y is the name of the TCP connection
-   about which i represents information.
-
-   For example, suppose one wanted to find the state of a TCP connection
-   between the local address of 89.1.1.42 on TCP port 21 and the remote
-   address of 10.0.0.51 on TCP port 2059.  Accordingly,
-   tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired
-   instance.
-
-3.2.6.3.6.  egpNeighTable Object Type Names
-
-   The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form
-   a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
-   notation) of that instance of the egpNeighAddr object type associated
-   with x.
-
-   For each object type, t, for which the defined name, n, has a prefix
-   of egpNeighEntry, an instance, i, of t is named by an OBJECT
-   IDENTIFIER of the form n.y, where y is the name of the EGP neighbor
-   about which i represents information.
-
-   For example, suppose one wanted to find the neighbor state for the IP
-   address of 89.1.1.42.  Accordingly, egpNeighState.89.1.1.42 would
-   identify the desired instance.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 14]
-
-RFC 1067                          SNMP                       August 1988
-
-
-4.  Protocol Specification
-
-   The network management protocol is an application protocol by which
-   the variables of an agent's MIB may be inspected or altered.
-
-   Communication among protocol entities is accomplished by the exchange
-   of messages, each of which is entirely and independently represented
-   within a single UDP datagram using the basic encoding rules of ASN.1
-   (as discussed in Section 3.2.2).  A message consists of a version
-   identifier, an SNMP community name, and a protocol data unit (PDU).
-   A protocol entity receives messages at UDP port 161 on the host with
-   which it is associated for all messages except for those which report
-   traps (i.e., all messages except those which contain the Trap-PDU).
-   Messages which report traps should be received on UDP port 162 for
-   further processing.  An implementation of this protocol need not
-   accept messages whose length exceeds 484 octets.  However, it is
-   recommended that implementations support larger datagrams whenever
-   feasible.
-
-   It is mandatory that all implementations of the SNMP support the five
-   PDUs: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU,
-   SetRequest-PDU, and Trap-PDU.
-
-    RFC1067-SNMP DEFINITIONS ::= BEGIN
-
-     IMPORTS
-          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
-                  FROM RFC1065-SMI;
-
-
-     -- top-level message
-
-             Message ::=
-                     SEQUENCE {
-                          version        -- version-1 for this RFC
-                             INTEGER {
-                                 version-1(0)
-                             },
-
-                         community      -- community name
-                             OCTET STRING,
-
-                         data           -- e.g., PDUs if trivial
-                             ANY        -- authentication is being used
-                     }
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 15]
-
-RFC 1067                          SNMP                       August 1988
-
-
-     -- protocol data units
-
-             PDUs ::=
-                     CHOICE {
-                         get-request
-                             GetRequest-PDU,
-
-                         get-next-request
-                             GetNextRequest-PDU,
-
-                         get-response
-                             GetResponse-PDU,
-
-                         set-request
-                             SetRequest-PDU,
-
-                         trap
-                             Trap-PDU
-                          }
-
-     -- the individual PDUs and commonly used
-     -- data types will be defined later
-
-     END
-
-
-4.1.  Elements of Procedure
-
-   This section describes the actions of a protocol entity implementing
-   the SNMP. Note, however, that it is not intended to constrain the
-   internal architecture of any conformant implementation.
-
-   In the text that follows, the term transport address is used.  In the
-   case of the UDP, a transport address consists of an IP address along
-   with a UDP port.  Other transport services may be used to support the
-   SNMP.  In these cases, the definition of a transport address should
-   be made accordingly.
-
-   The top-level actions of a protocol entity which generates a message
-   are as follows:
-
-        (1)  It first constructs the appropriate PDU, e.g., the
-             GetRequest-PDU, as an ASN.1 object.
-
-        (2)  It then passes this ASN.1 object along with a community
-             name its source transport address and the destination
-             transport address, to the service which implements the
-             desired authentication scheme.  This authentication
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 16]
-
-RFC 1067                          SNMP                       August 1988
-
-
-             service returns another ASN.1 object.
-
-        (3)  The protocol entity then constructs an ASN.1 Message
-             object, using the community name and the resulting ASN.1
-             object.
-
-        (4)  This new ASN.1 object is then serialized, using the basic
-             encoding rules of ASN.1, and then sent using a transport
-             service to the peer protocol entity.
-
-   Similarly, the top-level actions of a protocol entity which receives
-   a message are as follows:
-
-        (1)  It performs a rudimentary parse of the incoming datagram
-             to build an ASN.1 object corresponding to an ASN.1
-             Message object. If the parse fails, it discards the
-             datagram and performs no further actions.
-
-        (2)  It then verifies the version number of the SNMP message.
-             If there is a mismatch, it discards the datagram and
-             performs no further actions.
-
-        (3)  The protocol entity then passes the community name and
-             user data found in the ASN.1 Message object, along with
-             the datagram's source and destination transport addresses
-             to the service which implements the desired
-             authentication scheme.  This entity returns another ASN.1
-             object, or signals an authentication failure.  In the
-             latter case, the protocol entity notes this failure,
-             (possibly) generates a trap, and discards the datagram
-             and performs no further actions.
-
-        (4)  The protocol entity then performs a rudimentary parse on
-             the ASN.1 object returned from the authentication service
-             to build an ASN.1 object corresponding to an ASN.1 PDUs
-             object.  If the parse fails, it discards the datagram and
-             performs no further actions.  Otherwise, using the named
-             SNMP community, the appropriate profile is selected, and
-             the PDU is processed accordingly.  If, as a result of
-             this processing, a message is returned then the source
-             transport address that the response message is sent from
-             shall be identical to the destination transport address
-             that the original request message was sent to.
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 17]
-
-RFC 1067                          SNMP                       August 1988
-
-
-4.1.1.  Common Constructs
-
-   Before introducing the six PDU types of the protocol, it is
-   appropriate to consider some of the ASN.1 constructs used frequently:
-
-                  -- request/response information
-
-                  RequestID ::=
-                          INTEGER
-
-                  ErrorStatus ::=
-                          INTEGER {
-                              noError(0),
-                              tooBig(1),
-                              noSuchName(2),
-                              badValue(3),
-                              readOnly(4)
-                              genErr(5)
-                          }
-
-                  ErrorIndex ::=
-                          INTEGER
-
-
-                  -- variable bindings
-
-                  VarBind ::=
-                          SEQUENCE {
-                              name
-                                  ObjectName,
-
-                              value
-                                  ObjectSyntax
-                          }
-
-                  VarBindList ::=
-                          SEQUENCE OF
-                              VarBind
-
-
-   RequestIDs are used to distinguish among outstanding requests.  By
-   use of the RequestID, an SNMP application entity can correlate
-   incoming responses with outstanding requests.  In cases where an
-   unreliable datagram service is being used, the RequestID also
-   provides a simple means of identifying messages duplicated by the
-   network.
-
-   A non-zero instance of ErrorStatus is used to indicate that an
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 18]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   exception occurred while processing a request.  In these cases,
-   ErrorIndex may provide additional information by indicating which
-   variable in a list caused the exception.
-
-   The term variable refers to an instance of a managed object.  A
-   variable binding, or VarBind, refers to the pairing of the name of a
-   variable to the variable's value.  A VarBindList is a simple list of
-   variable names and corresponding values.  Some PDUs are concerned
-   only with the name of a variable and not its value (e.g., the
-   GetRequest-PDU).  In this case, the value portion of the binding is
-   ignored by the protocol entity.  However, the value portion must
-   still have valid ASN.1 syntax and encoding.  It is recommended that
-   the ASN.1 value NULL be used for the value portion of such bindings.
-
-4.1.2.  The GetRequest-PDU
-
-             The form of the GetRequest-PDU is:
-                  GetRequest-PDU ::=
-                      [0]
-                          IMPLICIT SEQUENCE {
-                              request-id
-                                  RequestID,
-
-                              error-status        -- always 0
-                                  ErrorStatus,
-
-                              error-index         -- always 0
-                                  ErrorIndex,
-
-                              variable-bindings
-                                  VarBindList
-                          }
-
-
-   The GetRequest-PDU is generated by a protocol entity only at the
-   request of its SNMP application entity.
-
-   Upon receipt of the GetRequest-PDU, the receiving protocol entity
-   responds according to any applicable rule in the list below:
-
-        (1)  If, for any object named in the variable-bindings field,
-             the object's name does not exactly match the name of some
-             object available for get operations in the relevant MIB
-             view, then the receiving entity sends to the originator
-             of the received message the GetResponse-PDU of identical
-             form, except that the value of the error-status field is
-             noSuchName, and the value of the error-index field is the
-             index of said object name component in the received
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 19]
-
-RFC 1067                          SNMP                       August 1988
-
-
-             message.
-
-        (2)  If, for any object named in the variable-bindings field,
-             the object is an aggregate type (as defined in the SMI),
-             then the receiving entity sends to the originator of the
-             received message the GetResponse-PDU of identical form,
-             except that the value of the error-status field is
-             noSuchName, and the value of the error-index field is the
-             index of said object name component in the received
-             message.
-
-        (3)  If the size of the GetResponse-PDU generated as described
-             below would exceed a local limitation, then the receiving
-             entity sends to the originator of the received message
-             the GetResponse-PDU of identical form, except that the
-             value of the error-status field is tooBig, and the value
-             of the error-index field is zero.
-
-        (4)  If, for any object named in the variable-bindings field,
-             the value of the object cannot be retrieved for reasons
-             not covered by any of the foregoing rules, then the
-             receiving entity sends to the originator of the received
-             message the GetResponse-PDU of identical form, except
-             that the value of the error-status field is genErr and
-             the value of the error-index field is the index of said
-             object name component in the received message.
-
-   If none of the foregoing rules apply, then the receiving protocol
-   entity sends to the originator of the received message the
-   GetResponse-PDU such that, for each object named in the variable-
-   bindings field of the received message, the corresponding component
-   of the GetResponse-PDU represents the name and value of that
-   variable.  The value of the error- status field of the GetResponse-
-   PDU is noError and the value of the error-index field is zero.  The
-   value of the request-id field of the GetResponse-PDU is that of the
-   received message.
-
-4.1.3.  The GetNextRequest-PDU
-
-   The form of the GetNextRequest-PDU is identical to that of the
-   GetRequest-PDU except for the indication of the PDU type.  In the
-   ASN.1 language:
-
-                  GetNextRequest-PDU ::=
-                      [1]
-                          IMPLICIT SEQUENCE {
-                              request-id
-                                  RequestID,
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 20]
-
-RFC 1067                          SNMP                       August 1988
-
-
-                              error-status        -- always 0
-                                  ErrorStatus,
-
-                              error-index         -- always 0
-                                  ErrorIndex,
-
-                              variable-bindings
-                                  VarBindList
-                          }
-
-
-   The GetNextRequest-PDU is generated by a protocol entity only at the
-   request of its SNMP application entity.
-
-   Upon receipt of the GetNextRequest-PDU, the receiving protocol entity
-   responds according to any applicable rule in the list below:
-
-        (1)  If, for any object name in the variable-bindings field,
-             that name does not lexicographically precede the name of
-             some object available for get operations in the relevant
-             MIB view, then the receiving entity sends to the
-             originator of the received message the GetResponse-PDU of
-             identical form, except that the value of the error-status
-             field is noSuchName, and the value of the error-index
-             field is the index of said object name component in the
-             received message.
-
-        (2)  If the size of the GetResponse-PDU generated as described
-             below would exceed a local limitation, then the receiving
-             entity sends to the originator of the received message
-             the GetResponse-PDU of identical form, except that the
-             value of the error-status field is tooBig, and the value
-             of the error-index field is zero.
-
-        (3)  If, for any object named in the variable-bindings field,
-             the value of the lexicographical successor to the named
-             object cannot be retrieved for reasons not covered by any
-             of the foregoing rules, then the receiving entity sends
-             to the originator of the received message the
-             GetResponse-PDU of identical form, except that the value
-             of the error-status field is genErr and the value of the
-             error-index field is the index of said object name
-             component in the received message.
-
-   If none of the foregoing rules apply, then the receiving protocol
-   entity sends to the originator of the received message the
-   GetResponse-PDU such that, for each name in the variable-bindings
-   field of the received message, the corresponding component of the
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 21]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   GetResponse-PDU represents the name and value of that object whose
-   name is, in the lexicographical ordering of the names of all objects
-   available for get operations in the relevant MIB view, together with
-   the value of the name field of the given component, the immediate
-   successor to that value.  The value of the error-status field of the
-   GetResponse-PDU is noError and the value of the errorindex field is
-   zero.  The value of the request-id field of the GetResponse-PDU is
-   that of the received message.
-
-4.1.3.1.  Example of Table Traversal
-
-   One important use of the GetNextRequest-PDU is the traversal of
-   conceptual tables of information within the MIB. The semantics of
-   this type of SNMP message, together with the protocol-specific
-   mechanisms for identifying individual instances of object types in
-   the MIB, affords  access to related objects in the MIB as if they
-   enjoyed a tabular organization.
-
-   By the SNMP exchange sketched below, an SNMP application entity might
-   extract the destination address and next hop gateway for each entry
-   in the routing table of a particular network element. Suppose that
-   this routing table has three entries:
-
-         Destination                     NextHop         Metric
-
-         10.0.0.99                       89.1.1.42       5
-         9.1.2.3                         99.0.0.3        3
-         10.0.0.51                       89.1.1.42       5
-
-
-   The management station sends to the SNMP agent a GetNextRequest-PDU
-   containing the indicated OBJECT IDENTIFIER values as the requested
-   variable names:
-
-   GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
-
-
-   The SNMP agent responds with a GetResponse-PDU:
-
-                 GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
-                         ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
-                         ( ipRouteMetric1.9.1.2.3 = 3 ))
-
-
-   The management station continues with:
-
-                 GetNextRequest ( ipRouteDest.9.1.2.3,
-                         ipRouteNextHop.9.1.2.3,
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 22]
-
-RFC 1067                          SNMP                       August 1988
-
-
-                         ipRouteMetric1.9.1.2.3 )
-
-
-   The SNMP agent responds:
-
-                 GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
-                         ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
-                         ( ipRouteMetric1.10.0.0.51 = 5 ))
-
-
-   The management station continues with:
-
-                 GetNextRequest ( ipRouteDest.10.0.0.51,
-                         ipRouteNextHop.10.0.0.51,
-                         ipRouteMetric1.10.0.0.51 )
-
-
-   The SNMP agent responds:
-
-                 GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
-                         ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
-                         ( ipRouteMetric1.10.0.0.99 = 5 ))
-
-
-   The management station continues with:
-
-                 GetNextRequest ( ipRouteDest.10.0.0.99,
-                         ipRouteNextHop.10.0.0.99,
-                         ipRouteMetric1.10.0.0.99 )
-
-
-   As there are no further entries in the table, the SNMP agent returns
-   those objects that are next in the lexicographical ordering of the
-   known object names.  This response signals the end of the routing
-   table to the management station.
-
-4.1.4.  The GetResponse-PDU
-
-   The form of the GetResponse-PDU is identical to that of the
-   GetRequest-PDU except for the indication of the PDU type.  In the
-   ASN.1 language:
-
-                  GetResponse-PDU ::=
-                      [2]
-                          IMPLICIT SEQUENCE {
-                              request-id
-                                  RequestID,
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 23]
-
-RFC 1067                          SNMP                       August 1988
-
-
-                              error-status
-                                  ErrorStatus,
-
-                              error-index
-                                  ErrorIndex,
-
-                              variable-bindings
-                                  VarBindList
-                          }
-
-
-   The GetResponse-PDU is generated by a protocol entity only upon
-   receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU,
-   as described elsewhere in this document.
-
-   Upon receipt of the GetResponse-PDU, the receiving protocol entity
-   presents its contents to its SNMP application entity.
-
-4.1.5.  The SetRequest-PDU
-
-   The form of the SetRequest-PDU is identical to that of the
-   GetRequest-PDU except for the indication of the PDU type.  In the
-   ASN.1 language:
-
-                  SetRequest-PDU ::=
-                      [3]
-                          IMPLICIT SEQUENCE {
-                              request-id
-                                  RequestID,
-
-                              error-status        -- always 0
-                                  ErrorStatus,
-
-                              error-index         -- always 0
-                                  ErrorIndex,
-
-                              variable-bindings
-                                  VarBindList
-                          }
-
-
-   The SetRequest-PDU is generated by a protocol entity only at the
-   request of its SNMP application entity.
-
-   Upon receipt of the SetRequest-PDU, the receiving entity responds
-   according to any applicable rule in the list below:
-
-        (1)  If, for any object named in the variable-bindings field,
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 24]
-
-RFC 1067                          SNMP                       August 1988
-
-
-             the object is not available for set operations in the
-             relevant MIB view, then the receiving entity sends to the
-             originator of the received message the GetResponse-PDU of
-             identical form, except that the value of the error-status
-             field is noSuchName, and the value of the error-index
-             field is the index of said object name component in the
-             received message.
-
-        (2)  If, for any object named in the variable-bindings field,
-             the contents of the value field does not, according to
-             the ASN.1 language, manifest a type, length, and value
-             that is consistent with that required for the variable,
-             then the receiving entity sends to the originator of the
-             received message the GetResponse-PDU of identical form,
-             except that the value of the error-status field is
-             badValue, and the value of the error-index field is the
-             index of said object name in the received message.
-
-        (3)  If the size of the Get Response type message generated as
-             described below would exceed a local limitation, then the
-             receiving entity sends to the originator of the received
-             message the GetResponse-PDU of identical form, except
-             that the value of the error-status field is tooBig, and
-             the value of the error-index field is zero.
-
-        (4)  If, for any object named in the variable-bindings field,
-             the value of the named object cannot be altered for
-             reasons not covered by any of the foregoing rules, then
-             the receiving entity sends to the originator of the
-             received message the GetResponse-PDU of identical form,
-             except that the value of the error-status field is genErr
-             and the value of the error-index field is the index of
-             said object name component in the received message.
-
-   If none of the foregoing rules apply, then for each object named in
-   the variable-bindings field of the received message, the
-   corresponding value is assigned to the variable.  Each variable
-   assignment specified by the SetRequest-PDU should be effected as if
-   simultaneously set with respect to all other assignments specified in
-   the same message.
-
-   The receiving entity then sends to the originator of the received
-   message the GetResponse-PDU of identical form except that the value
-   of the error-status field of the generated message is noError and the
-   value of the error-index field is zero.
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 25]
-
-RFC 1067                          SNMP                       August 1988
-
-
-4.1.6.  The Trap-PDU
-
-   The form of the Trap-PDU is:
-
-     Trap-PDU ::=
-         [4]
-
-              IMPLICIT SEQUENCE {
-                 enterprise          -- type of object generating
-                                     -- trap, see sysObjectID in [2]
-                     OBJECT IDENTIFIER,
-
-                 agent-addr          -- address of object generating
-                     NetworkAddress, -- trap
-
-                 generic-trap        -- generic trap type
-                     INTEGER {
-                         coldStart(0),
-                         warmStart(1),
-                         linkDown(2),
-                         linkUp(3),
-                         authenticationFailure(4),
-                         egpNeighborLoss(5),
-                         enterpriseSpecific(6)
-                     },
-
-                 specific-trap     -- specific code, present even
-                     INTEGER,      -- if generic-trap is not
-                                   -- enterpriseSpecific
-
-                 time-stamp        -- time elapsed between the last
-                   TimeTicks,      -- (re)initialization of the network
-                                   -- entity and the generation of the
-                                      trap
-
-                 variable-bindings   -- "interesting" information
-                      VarBindList
-             }
-
-
-   The Trap-PDU is generated by a protocol entity only at the request of
-   the SNMP application entity.  The means by which an SNMP application
-   entity selects the destination addresses of the SNMP application
-   entities is implementation-specific.
-
-   Upon receipt of the Trap-PDU, the receiving protocol entity presents
-   its contents to its SNMP application entity.
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 26]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   The significance of the variable-bindings component of the Trap-PDU
-   is implementation-specific.
-
-   Interpretations of the value of the generic-trap field are:
-
-4.1.6.1.  The coldStart Trap
-
-   A coldStart(0) trap signifies that the sending protocol entity is
-   reinitializing itself such that the agent's configuration or the
-   protocol entity implementation may be altered.
-
-4.1.6.2.  The warmStart Trap
-
-   A warmStart(1) trap signifies that the sending protocol entity is
-   reinitializing itself such that neither the agent configuration nor
-   the protocol entity implementation is altered.
-
-4.1.6.3.  The linkDown Trap
-
-   A linkDown(2) trap signifies that the sending protocol entity
-   recognizes a failure in one of the communication links represented in
-   the agent's configuration.
-
-   The Trap-PDU of type linkDown contains as the first element of its
-   variable-bindings, the name and value of the ifIndex instance for the
-   affected interface.
-
-4.1.6.4.  The linkUp Trap
-
-   A linkUp(3) trap signifies that the sending protocol entity
-   recognizes that one of the communication links represented in the
-   agent's configuration has come up.
-
-   The Trap-PDU of type linkUp contains as the first element of its
-   variable-bindings, the name and value of the ifIndex instance for the
-   affected interface.
-
-4.1.6.5.  The authenticationFailure Trap
-
-   An authenticationFailure(4) trap signifies that the sending protocol
-   entity is the addressee of a protocol message that is not properly
-   authenticated.  While implementations of the SNMP must be capable of
-   generating this trap, they must also be capable of suppressing the
-   emission of such traps via an implementation-specific mechanism.
-
-4.1.6.6.  The egpNeighborLoss Trap
-
-   An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 27]
-
-RFC 1067                          SNMP                       August 1988
-
-
-   the sending protocol entity was an EGP peer has been marked down and
-   the peer relationship no longer obtains.
-
-   The Trap-PDU of type egpNeighborLoss contains as the first element of
-   its variable-bindings, the name and value of the egpNeighAddr
-   instance for the affected neighbor.
-
-4.1.6.7.  The enterpriseSpecific Trap
-
-   A enterpriseSpecific(6) trap signifies that the sending protocol
-   entity recognizes that some enterprise-specific event has occurred.
-   The specific-trap field identifies the particular trap which
-   occurred.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 28]
-
-RFC 1067                          SNMP                       August 1988
-
-
-5.  Definitions
-
-     RFC1067-SNMP DEFINITIONS ::= BEGIN
-
-      IMPORTS
-          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
-              FROM RFC1065-SMI;
-
-
-          -- top-level message
-
-          Message ::=
-                  SEQUENCE {
-                      version          -- version-1 for this RFC
-                          INTEGER {
-                              version-1(0)
-                          },
-
-                      community        -- community name
-                          OCTET STRING,
-
-                      data             -- e.g., PDUs if trivial
-                          ANY          -- authentication is being used
-                  }
-
-
-          -- protocol data units
-
-          PDUs ::=
-                  CHOICE {
-                              get-request
-                                  GetRequest-PDU,
-
-                              get-next-request
-                                  GetNextRequest-PDU,
-
-                              get-response
-                                  GetResponse-PDU,
-
-                              set-request
-                                  SetRequest-PDU,
-
-                              trap
-                                  Trap-PDU
-                          }
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 29]
-
-RFC 1067                          SNMP                       August 1988
-
-
-          -- PDUs
-
-          GetRequest-PDU ::=
-              [0]
-                  IMPLICIT PDU
-
-          GetNextRequest-PDU ::=
-              [1]
-                  IMPLICIT PDU
-
-          GetResponse-PDU ::=
-              [2]
-                  IMPLICIT PDU
-
-          SetRequest-PDU ::=
-              [3]
-                  IMPLICIT PDU
-
-          PDU ::=
-                  SEQUENCE {
-                     request-id
-                          INTEGER,
-
-                      error-status      -- sometimes ignored
-                          INTEGER {
-                              noError(0),
-                              tooBig(1),
-                              noSuchName(2),
-                              badValue(3),
-                              readOnly(4),
-                              genErr(5)
-                          },
-
-                      error-index       -- sometimes ignored
-                         INTEGER,
-
-                      variable-bindings -- values are sometimes ignored
-                          VarBindList
-                  }
-
-          Trap-PDU ::=
-              [4]
-                 IMPLICIT SEQUENCE {
-                      enterprise        -- type of object generating
-                                        -- trap, see sysObjectID in [2]
-
-
-                          OBJECT IDENTIFIER,
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 30]
-
-RFC 1067                          SNMP                       August 1988
-
-
-                      agent-addr        -- address of object generating
-                          NetworkAddress, -- trap
-
-                      generic-trap      -- generic trap type
-                          INTEGER {
-                              coldStart(0),
-                              warmStart(1),
-                              linkDown(2),
-                              linkUp(3),
-                              authenticationFailure(4),
-                              egpNeighborLoss(5),
-                              enterpriseSpecific(6)
-                          },
-
-                      specific-trap  -- specific code, present even
-                          INTEGER,   -- if generic-trap is not
-                                     -- enterpriseSpecific
-
-                      time-stamp     -- time elapsed between the last
-                          TimeTicks, -- (re)initialization of the
-                                        network
-                                     -- entity and the generation of the
-                                        trap
-
-                       variable-bindings -- "interesting" information
-                          VarBindList
-                  }
-
-
-          -- variable bindings
-
-          VarBind ::=
-                  SEQUENCE {
-                      name
-                          ObjectName,
-
-                      value
-                          ObjectSyntax
-                  }
-
-         VarBindList ::=
-                  SEQUENCE OF
-                     VarBind
-
-         END
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 31]
-
-RFC 1067                          SNMP                       August 1988
-
-
-6.  Acknowledgements
-
-   This memo was influenced by the IETF SNMP Extensions working
-   group:
-
-             Karl Auerbach, Epilogue Technology
-             K. Ramesh Babu, Excelan
-             Amatzia Ben-Artzi, 3Com/Bridge
-             Lawrence Besaw, Hewlett-Packard
-             Jeffrey D. Case, University of Tennessee at Knoxville
-             Anthony Chung, Sytek
-             James Davidson, The Wollongong Group
-             James R. Davin, Proteon
-             Mark S. Fedor, NYSERNet
-             Phill Gross, The MITRE Corporation
-             Satish Joshi, ACC
-             Dan Lynch, Advanced Computing Environments
-             Keith McCloghrie, The Wollongong Group
-             Marshall T. Rose, The Wollongong Group (chair)
-             Greg Satz, cisco
-             Martin Lee Schoffstall, Rensselaer Polytechnic Institute
-             Wengyik Yeong, NYSERNet
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 32]
-
-RFC 1067                          SNMP                       August 1988
-
-
-7.  References
-
-   [1] Cerf, V., "IAB Recommendations for the Development of
-       Internet Network Management Standards", RFC 1052, IAB,
-       April 1988.
-
-   [2] Rose, M., and K. McCloghrie, "Structure and Identification
-       of Management Information for TCP/IP-based internets",
-       RFC 1065, TWG, August 1988.
-
-   [3] McCloghrie, K., and M. Rose, "Management Information Base
-       for Network Management of TCP/IP-based internets",
-       RFC 1066, TWG, August 1988.
-
-   [4] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
-       "A Simple Network Management Protocol", Internet
-       Engineering Task Force working note, Network Information
-       Center, SRI International, Menlo Park, California,
-       March 1988.
-
-   [5] Davin, J., J. Case, M. Fedor, and M. Schoffstall,
-       "A Simple Gateway Monitoring Protocol", RFC 1028,
-       Proteon, University of Tennessee at Knoxville,
-       Cornell University, and Rensselaer Polytechnic
-       Institute, November 1987.
-
-   [6] Information processing systems - Open Systems
-       Interconnection, "Specification of Abstract Syntax
-       Notation One (ASN.1)", International Organization for
-       Standardization, International Standard 8824,
-       December 1987.
-
-   [7] Information processing systems - Open Systems
-       Interconnection, "Specification of Basic Encoding Rules
-       for Abstract Notation One (ASN.1)", International
-       Organization for Standardization, International Standard
-       8825, December 1987.
-
-   [8] Postel, J., "User Datagram Protocol", RFC 768,
-       USC/Information Sciences Institute, November 1980.
-
-
-
-
-
-
-
-
-
-
-
-Case, Fedor, Schoffstall, & Davin                              [Page 33]
+
+
+
+
+
+
+Network Working Group                                            J. Case
+Request for Comments: 1067          University of Tennessee at Knoxville
+                                                                M. Fedor
+                                                          NYSERNet, Inc.
+                                                          M. Schoffstall
+                                        Rensselaer Polytechnic Institute
+                                                                J. Davin
+                                                           Proteon, Inc.
+                                                             August 1988
+
+
+                  A Simple Network Management Protocol
+
+                           Table of Contents
+
+   1. Status of this Memo ...................................    2
+   2. Introduction ..........................................    2
+   3. The SNMP Architecture .................................    4
+   3.1 Goals of the Architecture ............................    4
+   3.2 Elements of the Architecture .........................    4
+   3.2.1 Scope of Management Information ....................    5
+   3.2.2 Representation of Management Information ...........    5
+   3.2.3 Operations Supported on Management Information .....    6
+   3.2.4 Form and Meaning of Protocol Exchanges .............    7
+   3.2.5 Definition of Administrative Relationships .........    7
+   3.2.6 Form and Meaning of References to Managed Objects ..   11
+   3.2.6.1 Resolution of Ambiguous MIB References ...........   11
+   3.2.6.2 Resolution of References across MIB Versions......   11
+   3.2.6.3 Identification of Object Instances ...............   11
+   3.2.6.3.1 ifTable Object Type Names ......................   12
+   3.2.6.3.2 atTable Object Type Names ......................   12
+   3.2.6.3.3 ipAddrTable Object Type Names ..................   13
+   3.2.6.3.4 ipRoutingTable Object Type Names ...............   13
+   3.2.6.3.5 tcpConnTable Object Type Names .................   13
+   3.2.6.3.6 egpNeighTable Object Type Names ................   14
+   4. Protocol Specification ................................   15
+   4.1 Elements of Procedure ................................   16
+   4.1.1 Common Constructs ..................................   18
+   4.1.2 The GetRequest-PDU .................................   19
+   4.1.3 The GetNextRequest-PDU .............................   20
+   4.1.3.1 Example of Table Traversal .......................   22
+   4.1.4 The GetResponse-PDU ................................   23
+   4.1.5 The SetRequest-PDU .................................   24
+   4.1.6 The Trap-PDU .......................................   26
+   4.1.6.1 The coldStart Trap ...............................   27
+   4.1.6.2 The warmStart Trap ...............................   27
+   4.1.6.3 The linkDown Trap ................................   27
+   4.1.6.4 The linkUp Trap ..................................   27
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 1]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   4.1.6.5 The authenticationFailure Trap ...................   27
+   4.1.6.6 The egpNeighborLoss Trap .........................   27
+   4.1.6.7 The enterpriseSpecific Trap ......................   28
+   5. Definitions ...........................................   29
+   6. Acknowledgements ......................................   32
+   7. References ............................................   33
+
+1.  Status of this Memo
+
+   This memo defines a simple protocol by which management information
+   for a network element may be inspected or altered by logically remote
+   users.  In particular, together with its companion memos which
+   describe the structure of management information along with the
+   initial management information base, these documents provide a
+   simple, workable architecture and system for managing TCP/IP-based
+   internets and in particular the Internet.
+
+   This memo specifies a draft standard for the Internet community.
+   TCP/IP implementations in the Internet which are network manageable
+   are expected to adopt and implement this specification.
+
+   Distribution of this memo is unlimited.
+
+2.  Introduction
+
+   As reported in RFC 1052, IAB Recommendations for the Development of
+   Internet Network Management Standards [1], the Internet Activities
+   Board has directed the Internet Engineering Task Force (IETF) to
+   create two new working groups in the area of network management.  One
+   group is charged with the further specification and definition of
+   elements to be included in the Management Information Base (MIB).
+   The other is charged with defining the modifications to the Simple
+   Network Management Protocol (SNMP) to accommodate the short-term
+   needs of the network vendor and operations communities, and to align
+   with the output of the MIB working group.
+
+   The MIB working group has produced two memos, one which defines a
+   Structure for Management Information (SMI) [2] for use by the managed
+   objects contained in the MIB.  A second memo [3] defines the list of
+   managed objects.
+
+   The output of the SNMP Extensions working group is this memo, which
+   incorporates changes to the initial SNMP definition [4] required to
+   attain alignment with the output of the MIB working group.  The
+   changes should be minimal in order to be consistent with the IAB's
+   directive that the working groups be "extremely sensitive to the need
+   to keep the SNMP simple."  Although considerable care and debate has
+   gone into the changes to the SNMP which are reflected in this memo,
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 2]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   the resulting protocol is not backwardly-compatible with its
+   predecessor, the Simple Gateway Monitoring Protocol (SGMP) [5].
+   Although the syntax of the protocol has been altered, the original
+   philosophy, design decisions, and architecture remain intact.  In
+   order to avoid confusion, new UDP ports have been allocated for use
+   by the protocol described in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 3]
+
+RFC 1067                          SNMP                       August 1988
+
+
+3.  The SNMP Architecture
+
+   Implicit in the SNMP architectural model is a collection of network
+   management stations and network elements.  Network management
+   stations execute management applications which monitor and control
+   network elements.  Network elements are devices such as hosts,
+   gateways, terminal servers, and the like, which have management
+   agents responsible for performing the network management functions
+   requested by the network management stations.  The Simple Network
+   Management Protocol (SNMP) is used to communicate management
+   information between the network management stations and the agents in
+   the network elements.
+
+3.1.  Goals of the Architecture
+
+   The SNMP explicitly minimizes the number and complexity of management
+   functions realized by the management agent itself.  This goal is
+   attractive in at least four respects:
+
+      (1)  The development cost for management agent software
+           necessary to support the protocol is accordingly reduced.
+
+      (2)  The degree of management function that is remotely
+           supported is accordingly increased, thereby admitting
+           fullest use of internet resources in the management task.
+
+      (3)  The degree of management function that is remotely
+           supported is accordingly increased, thereby imposing the
+           fewest possible restrictions on the form and
+           sophistication of management tools.
+
+      (4)  Simplified sets of management functions are easily
+           understood and used by developers of network management
+           tools.
+
+   A second goal of the protocol is that the functional paradigm for
+   monitoring and control be sufficiently extensible to accommodate
+   additional, possibly unanticipated aspects of network operation and
+   management.
+
+   A third goal is that the architecture be, as much as possible,
+   independent of the architecture and mechanisms of particular hosts or
+   particular gateways.
+
+3.2.  Elements of the Architecture
+
+   The SNMP architecture articulates a solution to the network
+   management problem in terms of:
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 4]
+
+RFC 1067                          SNMP                       August 1988
+
+
+      (1)  the scope of the management information communicated by
+           the protocol,
+
+      (2)  the representation of the management information
+           communicated by the protocol,
+
+      (3)  operations on management information supported by the
+           protocol,
+
+      (4)  the form and meaning of exchanges among management
+           entities,
+
+      (5)  the definition of administrative relationships among
+           management entities, and
+
+      (6)  the form and meaning of references to management
+           information.
+
+3.2.1.  Scope of Management Information
+
+   The scope of the management information communicated by operation of
+   the SNMP is exactly that represented by instances of all non-
+   aggregate object types either defined in Internet-standard MIB or
+   defined elsewhere according to the conventions set forth in
+   Internet-standard SMI [2].
+
+   Support for aggregate object types in the MIB is neither required for
+   conformance with the SMI nor realized by the SNMP.
+
+3.2.2.  Representation of Management Information
+
+   Management information communicated by operation of the SNMP is
+   represented according to the subset of the ASN.1 language [6] that is
+   specified for the definition of non-aggregate types in the SMI.
+
+   The SGMP adopted the convention of using a well-defined subset of the
+   ASN.1 language [6].  The SNMP continues and extends this tradition by
+   utilizing a moderately more complex subset of ASN.1 for describing
+   managed objects and for describing the protocol data units used for
+   managing those objects.  In addition, the desire to ease eventual
+   transition to OSI-based network management protocols led to the
+   definition in the ASN.1 language of an Internet-standard Structure of
+   Management Information (SMI) [2] and Management Information Base
+   (MIB) [3].  The use of the ASN.1 language, was, in part, encouraged
+   by the successful use of ASN.1 in earlier efforts, in particular, the
+   SGMP.  The restrictions on the use of ASN.1 that are part of the SMI
+   contribute to the simplicity espoused and validated by experience
+   with the SGMP.
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 5]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   Also for the sake of simplicity, the SNMP uses only a subset of the
+   basic encoding rules of ASN.1 [7].  Namely, all encodings use the
+   definite-length form.  Further, whenever permissible, non-constructor
+   encodings are used rather than constructor encodings.  This
+   restriction applies to all aspects of ASN.1 encoding, both for the
+   top-level protocol data units and the data objects they contain.
+
+3.2.3.  Operations Supported on Management Information
+
+   The SNMP models all management agent functions as alterations or
+   inspections of variables.  Thus, a protocol entity on a logically
+   remote host (possibly the network element itself) interacts with the
+   management agent resident on the network element in order to retrieve
+   (get) or alter (set) variables.  This strategy has at least two
+   positive consequences:
+
+      (1)  It has the effect of limiting the number of essential
+           management functions realized by the management agent to
+           two: one operation to assign a value to a specified
+           configuration or other parameter and another to retrieve
+           such a value.
+
+      (2)  A second effect of this decision is to avoid introducing
+           into the protocol definition support for imperative
+           management commands:  the number of such commands is in
+           practice ever-increasing, and the semantics of such
+           commands are in general arbitrarily complex.
+
+   The strategy implicit in the SNMP is that the monitoring of network
+   state at any significant level of detail is accomplished primarily by
+   polling for appropriate information on the part of the monitoring
+   center(s).  A limited number of unsolicited messages (traps) guide
+   the timing and focus of the polling.  Limiting the number of
+   unsolicited messages is consistent with the goal of simplicity and
+   minimizing the amount of traffic generated by the network management
+   function.
+
+   The exclusion of imperative commands from the set of explicitly
+   supported management functions is unlikely to preclude any desirable
+   management agent operation.  Currently, most commands are requests
+   either to set the value of some parameter or to retrieve such a
+   value, and the function of the few imperative commands currently
+   supported is easily accommodated in an asynchronous mode by this
+   management model.  In this scheme, an imperative command might be
+   realized as the setting of a parameter value that subsequently
+   triggers the desired action.  For example, rather than implementing a
+   "reboot command," this action might be invoked by simply setting a
+   parameter indicating the number of seconds until system reboot.
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 6]
+
+RFC 1067                          SNMP                       August 1988
+
+
+3.2.4.  Form and Meaning of Protocol Exchanges
+
+   The communication of management information among management entities
+   is realized in the SNMP through the exchange of protocol messages.
+   The form and meaning of those messages is defined below in Section 4.
+
+   Consistent with the goal of minimizing complexity of the management
+   agent, the exchange of SNMP messages requires only an unreliable
+   datagram service, and every message is entirely and independently
+   represented by a single transport datagram.  While this document
+   specifies the exchange of messages via the UDP protocol [8], the
+   mechanisms of the SNMP are generally suitable for use with a wide
+   variety of transport services.
+
+3.2.5.  Definition of Administrative Relationships
+
+   The SNMP architecture admits a variety of administrative
+   relationships among entities that participate in the protocol.  The
+   entities residing at management stations and network elements which
+   communicate with one another using the SNMP are termed SNMP
+   application entities.  The peer processes which implement the SNMP,
+   and thus support the SNMP application entities, are termed protocol
+   entities.
+
+   A pairing of an SNMP agent with some arbitrary set of SNMP
+   application entities is called an SNMP community.  Each SNMP
+   community is named by a string of octets, that is called the
+   community name for said community.
+
+   An SNMP message originated by an SNMP application entity that in fact
+   belongs to the SNMP community named by the community component of
+   said message is called an authentic SNMP message.  The set of rules
+   by which an SNMP message is identified as an authentic SNMP message
+   for a particular SNMP community is called an authentication scheme.
+   An implementation of a function that identifies authentic SNMP
+   messages according to one or more authentication schemes is called an
+   authentication service.
+
+   Clearly, effective management of administrative relationships among
+   SNMP application entities requires authentication services that (by
+   the use of encryption or other techniques) are able to identify
+   authentic SNMP messages with a high degree of certainty.  Some SNMP
+   implementations may wish to support only a trivial authentication
+   service that identifies all SNMP messages as authentic SNMP messages.
+
+   For any network element, a subset of objects in the MIB that pertain
+   to that element is called a SNMP MIB view.  Note that the names of
+   the object types represented in a SNMP MIB view need not belong to a
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 7]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   single sub-tree of the object type name space.
+
+   An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
+   access mode.
+
+   A pairing of a SNMP access mode with a SNMP MIB view is called an
+   SNMP community profile.  A SNMP community profile represents
+   specified access privileges to variables in a specified MIB view. For
+   every variable in the MIB view in a given SNMP community profile,
+   access to that variable is represented by the profile according to
+   the following conventions:
+
+      (1)  if said variable is defined in the MIB with "Access:" of
+           "none," it is unavailable as an operand for any operator;
+
+      (2)  if said variable is defined in the MIB with "Access:" of
+           "read-write" or "write-only" and the access mode of the
+           given profile is READ-WRITE, that variable is available
+           as an operand for the get, set, and trap operations;
+
+      (3)  otherwise, the variable is available as an operand for
+           the get and trap operations.
+
+      (4)  In those cases where a "write-only" variable is an
+           operand used for the get or trap operations, the value
+           given for the variable is implementation-specific.
+
+   A pairing of a SNMP community with a SNMP community profile is called
+   a SNMP access policy. An access policy represents a specified
+   community profile afforded by the SNMP agent of a specified SNMP
+   community to other members of that community.  All administrative
+   relationships among SNMP application entities are architecturally
+   defined in terms of SNMP access policies.
+
+   For every SNMP access policy, if the network element on which the
+   SNMP agent for the specified SNMP community resides is not that to
+   which the MIB view for the specified profile pertains, then that
+   policy is called a SNMP proxy access policy. The SNMP agent
+   associated with a proxy access policy is called a SNMP proxy agent.
+   While careless definition of proxy access policies can result in
+   management loops, prudent definition of proxy policies is useful in
+   at least two ways:
+
+      (1)  It permits the monitoring and control of network elements
+           which are otherwise not addressable using the management
+           protocol and the transport protocol.  That is, a proxy
+           agent may provide a protocol conversion function allowing
+           a management station to apply a consistent management
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 8]
+
+RFC 1067                          SNMP                       August 1988
+
+
+           framework to all network elements, including devices such
+           as modems, multiplexors, and other devices which support
+           different management frameworks.
+
+      (2)  It potentially shields network elements from elaborate
+           access control policies.  For example, a proxy agent may
+           implement sophisticated access control whereby diverse
+           subsets of variables within the MIB are made accessible
+           to different management stations without increasing the
+           complexity of the network element.
+
+   By way of example, Figure 1 illustrates the relationship between
+   management stations, proxy agents, and management agents.  In this
+   example, the proxy agent is envisioned to be a normal Internet
+   Network Operations Center (INOC) of some administrative domain which
+   has a standard managerial relationship with a set of management
+   agents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 9]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   +------------------+       +----------------+      +----------------+
+   |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
+   |                  |       |                |      |                |
+   |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
+   |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
+   |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
+   |                  |       |                |      |                |
+   +------------------+       +----------------+      +----------------+
+          /|\                      /|\                     /|\
+           |                        |                       |
+           |                        |                       |
+           |                       \|/                      |
+           |               +-----------------+              |
+           +-------------->| Region #3 INOC  |<-------------+
+                           |                 |
+                           |Domain=Region #3 |
+                           |CPU=super-mini-2 |
+                           |PCommunity=pub,  |
+                           |         slate   |
+                           |DCommunity=secret|
+           +-------------->|                 |<-------------+
+           |               +-----------------+              |
+           |                       /|\                      |
+           |                        |                       |
+           |                        |                       |
+          \|/                      \|/                     \|/
+   +-----------------+     +-----------------+       +-----------------+
+   |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
+   |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
+   |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
+   +-----------------+     +-----------------+       +-----------------+
+
+
+   Domain:  the administrative domain of the element
+   PCommunity:  the name of a community utilizing a proxy agent
+   DCommunity:  the name of a direct community
+
+
+                                 Figure 1
+                 Example Network Management Configuration
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 10]
+
+RFC 1067                          SNMP                       August 1988
+
+
+3.2.6.  Form and Meaning of References to Managed Objects
+
+   The SMI requires that the definition of a conformant management
+   protocol address:
+
+      (1)  the resolution of ambiguous MIB references,
+
+      (2)  the resolution of MIB references in the presence multiple
+           MIB versions, and
+
+      (3)  the identification of particular instances of object
+           types defined in the MIB.
+
+3.2.6.1.  Resolution of Ambiguous MIB References
+
+   Because the scope of any SNMP operation is conceptually confined to
+   objects relevant to a single network element, and because all SNMP
+   references to MIB objects are (implicitly or explicitly) by unique
+   variable names, there is no possibility that any SNMP reference to
+   any object type defined in the MIB could resolve to multiple
+   instances of that type.
+
+3.2.6.2.  Resolution of References across MIB Versions
+
+   The object instance referred to by any SNMP operation is exactly that
+   specified as part of the operation request or (in the case of a get-
+   next operation) its immediate successor in the MIB as a whole.  In
+   particular, a reference to an object as part of some version of the
+   Internet-standard MIB does not resolve to any object that is not part
+   of said version of the Internet-standard MIB, except in the case that
+   the requested operation is get-next and the specified object name is
+   lexicographically last among the names of all objects presented as
+   part of said version of the Internet-Standard MIB.
+
+3.2.6.3.  Identification of Object Instances
+
+   The names for all object types in the MIB are defined explicitly
+   either in the Internet-standard MIB or in other documents which
+   conform to the naming conventions of the SMI.  The SMI requires that
+   conformant management protocols define mechanisms for identifying
+   individual instances of those object types for a particular network
+   element.
+
+   Each instance of any object type defined in the MIB is identified in
+   SNMP operations by a unique name called its "variable name." In
+   general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
+   form x.y, where x is the name of a non-aggregate object type defined
+   in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 11]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   specific to the named object type, identifies the desired instance.
+
+   This naming strategy admits the fullest exploitation of the semantics
+   of the GetNextRequest-PDU (see Section 4), because it assigns names
+   for related variables so as to be contiguous in the lexicographical
+   ordering of all variable names known in the MIB.
+
+   The type-specific naming of object instances is defined below for a
+   number of classes of object types.  Instances of an object type to
+   which none of the following naming conventions are applicable are
+   named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
+   said object type in the MIB definition.
+
+   For example, suppose one wanted to identify an instance of the
+   variable sysDescr The object class for sysDescr is:
+
+             iso org dod internet mgmt mib system sysDescr
+              1   3   6     1      2    1    1       1
+
+   Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
+   appended an instance sub-identifier of 0.  That is, 1.3.6.1.2.1.1.1.0
+   identifies the one and only instance of sysDescr.
+
+3.2.6.3.1.  ifTable Object Type Names
+
+   The name of a subnet interface, s, is the OBJECT IDENTIFIER value of
+   the form i, where i has the value of that instance of the ifIndex
+   object type associated with s.
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
+   the form n.s, where s is the name of the subnet interface about which
+   i represents information.
+
+   For example, suppose one wanted to identify the instance of the
+   variable ifType associated with interface 2.  Accordingly, ifType.2
+   would identify the desired instance.
+
+3.2.6.3.2.  atTable Object Type Names
+
+   The name of an AT-cached network address, x, is an OBJECT IDENTIFIER
+   of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar
+   "dot" notation) of the atNetAddress object type associated with x.
+
+   The name of an address translation equivalence e is an OBJECT
+   IDENTIFIER value of the form s.w, such that s is the value of that
+   instance of the atIndex object type associated with e and such that w
+   is the name of the AT-cached network address associated with e.
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 12]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
+   the form n.y, where y is the name of the address translation
+   equivalence about which i represents information.
+
+   For example, suppose one wanted to find the physical address of an
+   entry in the address translation table (ARP cache) associated with an
+   IP address of 89.1.1.42 and interface 3.  Accordingly,
+   atPhysAddress.3.1.89.1.1.42 would identify the desired instance.
+
+3.2.6.3.3.  ipAddrTable Object Type Names
+
+   The name of an IP-addressable network element, x, is the OBJECT
+   IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the
+   familiar "dot" notation) of that instance of the ipAdEntAddr object
+   type associated with x.
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER
+   of the form n.y, where y is the name of the IP-addressable network
+   element about which i represents information.
+
+   For example, suppose one wanted to find the network mask of an entry
+   in the IP interface table associated with an IP address of 89.1.1.42.
+   Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired
+   instance.
+
+3.2.6.3.4.  ipRoutingTable Object Type Names
+
+   The name of an IP route, x, is the OBJECT IDENTIFIER of the form
+   a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
+   notation) of that instance of the ipRouteDest object type associated
+   with x.
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of ipRoutingEntry, an instance, i, of t is named by an OBJECT
+   IDENTIFIER of the form n.y, where y is the name of the IP route about
+   which i represents information.
+
+   For example, suppose one wanted to find the next hop of an entry in
+   the IP routing table associated  with the destination of 89.1.1.42.
+   Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired
+   instance.
+
+3.2.6.3.5.  tcpConnTable Object Type Names
+
+   The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form
+   a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 13]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   "dot" notation) of that instance of the tcpConnLocalAddress object
+   type associated with x and such that f.g.h.i is the value (in the
+   familiar "dot" notation) of that instance of the tcpConnRemoteAddress
+   object type associated with x and such that e is the value of that
+   instance of the tcpConnLocalPort object type associated with x and
+   such that j is the value of that instance of the tcpConnRemotePort
+   object type associated with x.
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of  tcpConnEntry, an instance, i, of t is named by an OBJECT
+   IDENTIFIER of the form n.y, where y is the name of the TCP connection
+   about which i represents information.
+
+   For example, suppose one wanted to find the state of a TCP connection
+   between the local address of 89.1.1.42 on TCP port 21 and the remote
+   address of 10.0.0.51 on TCP port 2059.  Accordingly,
+   tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired
+   instance.
+
+3.2.6.3.6.  egpNeighTable Object Type Names
+
+   The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form
+   a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
+   notation) of that instance of the egpNeighAddr object type associated
+   with x.
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of egpNeighEntry, an instance, i, of t is named by an OBJECT
+   IDENTIFIER of the form n.y, where y is the name of the EGP neighbor
+   about which i represents information.
+
+   For example, suppose one wanted to find the neighbor state for the IP
+   address of 89.1.1.42.  Accordingly, egpNeighState.89.1.1.42 would
+   identify the desired instance.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 14]
+
+RFC 1067                          SNMP                       August 1988
+
+
+4.  Protocol Specification
+
+   The network management protocol is an application protocol by which
+   the variables of an agent's MIB may be inspected or altered.
+
+   Communication among protocol entities is accomplished by the exchange
+   of messages, each of which is entirely and independently represented
+   within a single UDP datagram using the basic encoding rules of ASN.1
+   (as discussed in Section 3.2.2).  A message consists of a version
+   identifier, an SNMP community name, and a protocol data unit (PDU).
+   A protocol entity receives messages at UDP port 161 on the host with
+   which it is associated for all messages except for those which report
+   traps (i.e., all messages except those which contain the Trap-PDU).
+   Messages which report traps should be received on UDP port 162 for
+   further processing.  An implementation of this protocol need not
+   accept messages whose length exceeds 484 octets.  However, it is
+   recommended that implementations support larger datagrams whenever
+   feasible.
+
+   It is mandatory that all implementations of the SNMP support the five
+   PDUs: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU,
+   SetRequest-PDU, and Trap-PDU.
+
+    RFC1067-SNMP DEFINITIONS ::= BEGIN
+
+     IMPORTS
+          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
+                  FROM RFC1065-SMI;
+
+
+     -- top-level message
+
+             Message ::=
+                     SEQUENCE {
+                          version        -- version-1 for this RFC
+                             INTEGER {
+                                 version-1(0)
+                             },
+
+                         community      -- community name
+                             OCTET STRING,
+
+                         data           -- e.g., PDUs if trivial
+                             ANY        -- authentication is being used
+                     }
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 15]
+
+RFC 1067                          SNMP                       August 1988
+
+
+     -- protocol data units
+
+             PDUs ::=
+                     CHOICE {
+                         get-request
+                             GetRequest-PDU,
+
+                         get-next-request
+                             GetNextRequest-PDU,
+
+                         get-response
+                             GetResponse-PDU,
+
+                         set-request
+                             SetRequest-PDU,
+
+                         trap
+                             Trap-PDU
+                          }
+
+     -- the individual PDUs and commonly used
+     -- data types will be defined later
+
+     END
+
+
+4.1.  Elements of Procedure
+
+   This section describes the actions of a protocol entity implementing
+   the SNMP. Note, however, that it is not intended to constrain the
+   internal architecture of any conformant implementation.
+
+   In the text that follows, the term transport address is used.  In the
+   case of the UDP, a transport address consists of an IP address along
+   with a UDP port.  Other transport services may be used to support the
+   SNMP.  In these cases, the definition of a transport address should
+   be made accordingly.
+
+   The top-level actions of a protocol entity which generates a message
+   are as follows:
+
+        (1)  It first constructs the appropriate PDU, e.g., the
+             GetRequest-PDU, as an ASN.1 object.
+
+        (2)  It then passes this ASN.1 object along with a community
+             name its source transport address and the destination
+             transport address, to the service which implements the
+             desired authentication scheme.  This authentication
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 16]
+
+RFC 1067                          SNMP                       August 1988
+
+
+             service returns another ASN.1 object.
+
+        (3)  The protocol entity then constructs an ASN.1 Message
+             object, using the community name and the resulting ASN.1
+             object.
+
+        (4)  This new ASN.1 object is then serialized, using the basic
+             encoding rules of ASN.1, and then sent using a transport
+             service to the peer protocol entity.
+
+   Similarly, the top-level actions of a protocol entity which receives
+   a message are as follows:
+
+        (1)  It performs a rudimentary parse of the incoming datagram
+             to build an ASN.1 object corresponding to an ASN.1
+             Message object. If the parse fails, it discards the
+             datagram and performs no further actions.
+
+        (2)  It then verifies the version number of the SNMP message.
+             If there is a mismatch, it discards the datagram and
+             performs no further actions.
+
+        (3)  The protocol entity then passes the community name and
+             user data found in the ASN.1 Message object, along with
+             the datagram's source and destination transport addresses
+             to the service which implements the desired
+             authentication scheme.  This entity returns another ASN.1
+             object, or signals an authentication failure.  In the
+             latter case, the protocol entity notes this failure,
+             (possibly) generates a trap, and discards the datagram
+             and performs no further actions.
+
+        (4)  The protocol entity then performs a rudimentary parse on
+             the ASN.1 object returned from the authentication service
+             to build an ASN.1 object corresponding to an ASN.1 PDUs
+             object.  If the parse fails, it discards the datagram and
+             performs no further actions.  Otherwise, using the named
+             SNMP community, the appropriate profile is selected, and
+             the PDU is processed accordingly.  If, as a result of
+             this processing, a message is returned then the source
+             transport address that the response message is sent from
+             shall be identical to the destination transport address
+             that the original request message was sent to.
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 17]
+
+RFC 1067                          SNMP                       August 1988
+
+
+4.1.1.  Common Constructs
+
+   Before introducing the six PDU types of the protocol, it is
+   appropriate to consider some of the ASN.1 constructs used frequently:
+
+                  -- request/response information
+
+                  RequestID ::=
+                          INTEGER
+
+                  ErrorStatus ::=
+                          INTEGER {
+                              noError(0),
+                              tooBig(1),
+                              noSuchName(2),
+                              badValue(3),
+                              readOnly(4)
+                              genErr(5)
+                          }
+
+                  ErrorIndex ::=
+                          INTEGER
+
+
+                  -- variable bindings
+
+                  VarBind ::=
+                          SEQUENCE {
+                              name
+                                  ObjectName,
+
+                              value
+                                  ObjectSyntax
+                          }
+
+                  VarBindList ::=
+                          SEQUENCE OF
+                              VarBind
+
+
+   RequestIDs are used to distinguish among outstanding requests.  By
+   use of the RequestID, an SNMP application entity can correlate
+   incoming responses with outstanding requests.  In cases where an
+   unreliable datagram service is being used, the RequestID also
+   provides a simple means of identifying messages duplicated by the
+   network.
+
+   A non-zero instance of ErrorStatus is used to indicate that an
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 18]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   exception occurred while processing a request.  In these cases,
+   ErrorIndex may provide additional information by indicating which
+   variable in a list caused the exception.
+
+   The term variable refers to an instance of a managed object.  A
+   variable binding, or VarBind, refers to the pairing of the name of a
+   variable to the variable's value.  A VarBindList is a simple list of
+   variable names and corresponding values.  Some PDUs are concerned
+   only with the name of a variable and not its value (e.g., the
+   GetRequest-PDU).  In this case, the value portion of the binding is
+   ignored by the protocol entity.  However, the value portion must
+   still have valid ASN.1 syntax and encoding.  It is recommended that
+   the ASN.1 value NULL be used for the value portion of such bindings.
+
+4.1.2.  The GetRequest-PDU
+
+             The form of the GetRequest-PDU is:
+                  GetRequest-PDU ::=
+                      [0]
+                          IMPLICIT SEQUENCE {
+                              request-id
+                                  RequestID,
+
+                              error-status        -- always 0
+                                  ErrorStatus,
+
+                              error-index         -- always 0
+                                  ErrorIndex,
+
+                              variable-bindings
+                                  VarBindList
+                          }
+
+
+   The GetRequest-PDU is generated by a protocol entity only at the
+   request of its SNMP application entity.
+
+   Upon receipt of the GetRequest-PDU, the receiving protocol entity
+   responds according to any applicable rule in the list below:
+
+        (1)  If, for any object named in the variable-bindings field,
+             the object's name does not exactly match the name of some
+             object available for get operations in the relevant MIB
+             view, then the receiving entity sends to the originator
+             of the received message the GetResponse-PDU of identical
+             form, except that the value of the error-status field is
+             noSuchName, and the value of the error-index field is the
+             index of said object name component in the received
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 19]
+
+RFC 1067                          SNMP                       August 1988
+
+
+             message.
+
+        (2)  If, for any object named in the variable-bindings field,
+             the object is an aggregate type (as defined in the SMI),
+             then the receiving entity sends to the originator of the
+             received message the GetResponse-PDU of identical form,
+             except that the value of the error-status field is
+             noSuchName, and the value of the error-index field is the
+             index of said object name component in the received
+             message.
+
+        (3)  If the size of the GetResponse-PDU generated as described
+             below would exceed a local limitation, then the receiving
+             entity sends to the originator of the received message
+             the GetResponse-PDU of identical form, except that the
+             value of the error-status field is tooBig, and the value
+             of the error-index field is zero.
+
+        (4)  If, for any object named in the variable-bindings field,
+             the value of the object cannot be retrieved for reasons
+             not covered by any of the foregoing rules, then the
+             receiving entity sends to the originator of the received
+             message the GetResponse-PDU of identical form, except
+             that the value of the error-status field is genErr and
+             the value of the error-index field is the index of said
+             object name component in the received message.
+
+   If none of the foregoing rules apply, then the receiving protocol
+   entity sends to the originator of the received message the
+   GetResponse-PDU such that, for each object named in the variable-
+   bindings field of the received message, the corresponding component
+   of the GetResponse-PDU represents the name and value of that
+   variable.  The value of the error- status field of the GetResponse-
+   PDU is noError and the value of the error-index field is zero.  The
+   value of the request-id field of the GetResponse-PDU is that of the
+   received message.
+
+4.1.3.  The GetNextRequest-PDU
+
+   The form of the GetNextRequest-PDU is identical to that of the
+   GetRequest-PDU except for the indication of the PDU type.  In the
+   ASN.1 language:
+
+                  GetNextRequest-PDU ::=
+                      [1]
+                          IMPLICIT SEQUENCE {
+                              request-id
+                                  RequestID,
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 20]
+
+RFC 1067                          SNMP                       August 1988
+
+
+                              error-status        -- always 0
+                                  ErrorStatus,
+
+                              error-index         -- always 0
+                                  ErrorIndex,
+
+                              variable-bindings
+                                  VarBindList
+                          }
+
+
+   The GetNextRequest-PDU is generated by a protocol entity only at the
+   request of its SNMP application entity.
+
+   Upon receipt of the GetNextRequest-PDU, the receiving protocol entity
+   responds according to any applicable rule in the list below:
+
+        (1)  If, for any object name in the variable-bindings field,
+             that name does not lexicographically precede the name of
+             some object available for get operations in the relevant
+             MIB view, then the receiving entity sends to the
+             originator of the received message the GetResponse-PDU of
+             identical form, except that the value of the error-status
+             field is noSuchName, and the value of the error-index
+             field is the index of said object name component in the
+             received message.
+
+        (2)  If the size of the GetResponse-PDU generated as described
+             below would exceed a local limitation, then the receiving
+             entity sends to the originator of the received message
+             the GetResponse-PDU of identical form, except that the
+             value of the error-status field is tooBig, and the value
+             of the error-index field is zero.
+
+        (3)  If, for any object named in the variable-bindings field,
+             the value of the lexicographical successor to the named
+             object cannot be retrieved for reasons not covered by any
+             of the foregoing rules, then the receiving entity sends
+             to the originator of the received message the
+             GetResponse-PDU of identical form, except that the value
+             of the error-status field is genErr and the value of the
+             error-index field is the index of said object name
+             component in the received message.
+
+   If none of the foregoing rules apply, then the receiving protocol
+   entity sends to the originator of the received message the
+   GetResponse-PDU such that, for each name in the variable-bindings
+   field of the received message, the corresponding component of the
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 21]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   GetResponse-PDU represents the name and value of that object whose
+   name is, in the lexicographical ordering of the names of all objects
+   available for get operations in the relevant MIB view, together with
+   the value of the name field of the given component, the immediate
+   successor to that value.  The value of the error-status field of the
+   GetResponse-PDU is noError and the value of the errorindex field is
+   zero.  The value of the request-id field of the GetResponse-PDU is
+   that of the received message.
+
+4.1.3.1.  Example of Table Traversal
+
+   One important use of the GetNextRequest-PDU is the traversal of
+   conceptual tables of information within the MIB. The semantics of
+   this type of SNMP message, together with the protocol-specific
+   mechanisms for identifying individual instances of object types in
+   the MIB, affords  access to related objects in the MIB as if they
+   enjoyed a tabular organization.
+
+   By the SNMP exchange sketched below, an SNMP application entity might
+   extract the destination address and next hop gateway for each entry
+   in the routing table of a particular network element. Suppose that
+   this routing table has three entries:
+
+         Destination                     NextHop         Metric
+
+         10.0.0.99                       89.1.1.42       5
+         9.1.2.3                         99.0.0.3        3
+         10.0.0.51                       89.1.1.42       5
+
+
+   The management station sends to the SNMP agent a GetNextRequest-PDU
+   containing the indicated OBJECT IDENTIFIER values as the requested
+   variable names:
+
+   GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
+
+
+   The SNMP agent responds with a GetResponse-PDU:
+
+                 GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
+                         ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
+                         ( ipRouteMetric1.9.1.2.3 = 3 ))
+
+
+   The management station continues with:
+
+                 GetNextRequest ( ipRouteDest.9.1.2.3,
+                         ipRouteNextHop.9.1.2.3,
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 22]
+
+RFC 1067                          SNMP                       August 1988
+
+
+                         ipRouteMetric1.9.1.2.3 )
+
+
+   The SNMP agent responds:
+
+                 GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
+                         ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
+                         ( ipRouteMetric1.10.0.0.51 = 5 ))
+
+
+   The management station continues with:
+
+                 GetNextRequest ( ipRouteDest.10.0.0.51,
+                         ipRouteNextHop.10.0.0.51,
+                         ipRouteMetric1.10.0.0.51 )
+
+
+   The SNMP agent responds:
+
+                 GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
+                         ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
+                         ( ipRouteMetric1.10.0.0.99 = 5 ))
+
+
+   The management station continues with:
+
+                 GetNextRequest ( ipRouteDest.10.0.0.99,
+                         ipRouteNextHop.10.0.0.99,
+                         ipRouteMetric1.10.0.0.99 )
+
+
+   As there are no further entries in the table, the SNMP agent returns
+   those objects that are next in the lexicographical ordering of the
+   known object names.  This response signals the end of the routing
+   table to the management station.
+
+4.1.4.  The GetResponse-PDU
+
+   The form of the GetResponse-PDU is identical to that of the
+   GetRequest-PDU except for the indication of the PDU type.  In the
+   ASN.1 language:
+
+                  GetResponse-PDU ::=
+                      [2]
+                          IMPLICIT SEQUENCE {
+                              request-id
+                                  RequestID,
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 23]
+
+RFC 1067                          SNMP                       August 1988
+
+
+                              error-status
+                                  ErrorStatus,
+
+                              error-index
+                                  ErrorIndex,
+
+                              variable-bindings
+                                  VarBindList
+                          }
+
+
+   The GetResponse-PDU is generated by a protocol entity only upon
+   receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU,
+   as described elsewhere in this document.
+
+   Upon receipt of the GetResponse-PDU, the receiving protocol entity
+   presents its contents to its SNMP application entity.
+
+4.1.5.  The SetRequest-PDU
+
+   The form of the SetRequest-PDU is identical to that of the
+   GetRequest-PDU except for the indication of the PDU type.  In the
+   ASN.1 language:
+
+                  SetRequest-PDU ::=
+                      [3]
+                          IMPLICIT SEQUENCE {
+                              request-id
+                                  RequestID,
+
+                              error-status        -- always 0
+                                  ErrorStatus,
+
+                              error-index         -- always 0
+                                  ErrorIndex,
+
+                              variable-bindings
+                                  VarBindList
+                          }
+
+
+   The SetRequest-PDU is generated by a protocol entity only at the
+   request of its SNMP application entity.
+
+   Upon receipt of the SetRequest-PDU, the receiving entity responds
+   according to any applicable rule in the list below:
+
+        (1)  If, for any object named in the variable-bindings field,
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 24]
+
+RFC 1067                          SNMP                       August 1988
+
+
+             the object is not available for set operations in the
+             relevant MIB view, then the receiving entity sends to the
+             originator of the received message the GetResponse-PDU of
+             identical form, except that the value of the error-status
+             field is noSuchName, and the value of the error-index
+             field is the index of said object name component in the
+             received message.
+
+        (2)  If, for any object named in the variable-bindings field,
+             the contents of the value field does not, according to
+             the ASN.1 language, manifest a type, length, and value
+             that is consistent with that required for the variable,
+             then the receiving entity sends to the originator of the
+             received message the GetResponse-PDU of identical form,
+             except that the value of the error-status field is
+             badValue, and the value of the error-index field is the
+             index of said object name in the received message.
+
+        (3)  If the size of the Get Response type message generated as
+             described below would exceed a local limitation, then the
+             receiving entity sends to the originator of the received
+             message the GetResponse-PDU of identical form, except
+             that the value of the error-status field is tooBig, and
+             the value of the error-index field is zero.
+
+        (4)  If, for any object named in the variable-bindings field,
+             the value of the named object cannot be altered for
+             reasons not covered by any of the foregoing rules, then
+             the receiving entity sends to the originator of the
+             received message the GetResponse-PDU of identical form,
+             except that the value of the error-status field is genErr
+             and the value of the error-index field is the index of
+             said object name component in the received message.
+
+   If none of the foregoing rules apply, then for each object named in
+   the variable-bindings field of the received message, the
+   corresponding value is assigned to the variable.  Each variable
+   assignment specified by the SetRequest-PDU should be effected as if
+   simultaneously set with respect to all other assignments specified in
+   the same message.
+
+   The receiving entity then sends to the originator of the received
+   message the GetResponse-PDU of identical form except that the value
+   of the error-status field of the generated message is noError and the
+   value of the error-index field is zero.
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 25]
+
+RFC 1067                          SNMP                       August 1988
+
+
+4.1.6.  The Trap-PDU
+
+   The form of the Trap-PDU is:
+
+     Trap-PDU ::=
+         [4]
+
+              IMPLICIT SEQUENCE {
+                 enterprise          -- type of object generating
+                                     -- trap, see sysObjectID in [2]
+                     OBJECT IDENTIFIER,
+
+                 agent-addr          -- address of object generating
+                     NetworkAddress, -- trap
+
+                 generic-trap        -- generic trap type
+                     INTEGER {
+                         coldStart(0),
+                         warmStart(1),
+                         linkDown(2),
+                         linkUp(3),
+                         authenticationFailure(4),
+                         egpNeighborLoss(5),
+                         enterpriseSpecific(6)
+                     },
+
+                 specific-trap     -- specific code, present even
+                     INTEGER,      -- if generic-trap is not
+                                   -- enterpriseSpecific
+
+                 time-stamp        -- time elapsed between the last
+                   TimeTicks,      -- (re)initialization of the network
+                                   -- entity and the generation of the
+                                      trap
+
+                 variable-bindings   -- "interesting" information
+                      VarBindList
+             }
+
+
+   The Trap-PDU is generated by a protocol entity only at the request of
+   the SNMP application entity.  The means by which an SNMP application
+   entity selects the destination addresses of the SNMP application
+   entities is implementation-specific.
+
+   Upon receipt of the Trap-PDU, the receiving protocol entity presents
+   its contents to its SNMP application entity.
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 26]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   The significance of the variable-bindings component of the Trap-PDU
+   is implementation-specific.
+
+   Interpretations of the value of the generic-trap field are:
+
+4.1.6.1.  The coldStart Trap
+
+   A coldStart(0) trap signifies that the sending protocol entity is
+   reinitializing itself such that the agent's configuration or the
+   protocol entity implementation may be altered.
+
+4.1.6.2.  The warmStart Trap
+
+   A warmStart(1) trap signifies that the sending protocol entity is
+   reinitializing itself such that neither the agent configuration nor
+   the protocol entity implementation is altered.
+
+4.1.6.3.  The linkDown Trap
+
+   A linkDown(2) trap signifies that the sending protocol entity
+   recognizes a failure in one of the communication links represented in
+   the agent's configuration.
+
+   The Trap-PDU of type linkDown contains as the first element of its
+   variable-bindings, the name and value of the ifIndex instance for the
+   affected interface.
+
+4.1.6.4.  The linkUp Trap
+
+   A linkUp(3) trap signifies that the sending protocol entity
+   recognizes that one of the communication links represented in the
+   agent's configuration has come up.
+
+   The Trap-PDU of type linkUp contains as the first element of its
+   variable-bindings, the name and value of the ifIndex instance for the
+   affected interface.
+
+4.1.6.5.  The authenticationFailure Trap
+
+   An authenticationFailure(4) trap signifies that the sending protocol
+   entity is the addressee of a protocol message that is not properly
+   authenticated.  While implementations of the SNMP must be capable of
+   generating this trap, they must also be capable of suppressing the
+   emission of such traps via an implementation-specific mechanism.
+
+4.1.6.6.  The egpNeighborLoss Trap
+
+   An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 27]
+
+RFC 1067                          SNMP                       August 1988
+
+
+   the sending protocol entity was an EGP peer has been marked down and
+   the peer relationship no longer obtains.
+
+   The Trap-PDU of type egpNeighborLoss contains as the first element of
+   its variable-bindings, the name and value of the egpNeighAddr
+   instance for the affected neighbor.
+
+4.1.6.7.  The enterpriseSpecific Trap
+
+   A enterpriseSpecific(6) trap signifies that the sending protocol
+   entity recognizes that some enterprise-specific event has occurred.
+   The specific-trap field identifies the particular trap which
+   occurred.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 28]
+
+RFC 1067                          SNMP                       August 1988
+
+
+5.  Definitions
+
+     RFC1067-SNMP DEFINITIONS ::= BEGIN
+
+      IMPORTS
+          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
+              FROM RFC1065-SMI;
+
+
+          -- top-level message
+
+          Message ::=
+                  SEQUENCE {
+                      version          -- version-1 for this RFC
+                          INTEGER {
+                              version-1(0)
+                          },
+
+                      community        -- community name
+                          OCTET STRING,
+
+                      data             -- e.g., PDUs if trivial
+                          ANY          -- authentication is being used
+                  }
+
+
+          -- protocol data units
+
+          PDUs ::=
+                  CHOICE {
+                              get-request
+                                  GetRequest-PDU,
+
+                              get-next-request
+                                  GetNextRequest-PDU,
+
+                              get-response
+                                  GetResponse-PDU,
+
+                              set-request
+                                  SetRequest-PDU,
+
+                              trap
+                                  Trap-PDU
+                          }
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 29]
+
+RFC 1067                          SNMP                       August 1988
+
+
+          -- PDUs
+
+          GetRequest-PDU ::=
+              [0]
+                  IMPLICIT PDU
+
+          GetNextRequest-PDU ::=
+              [1]
+                  IMPLICIT PDU
+
+          GetResponse-PDU ::=
+              [2]
+                  IMPLICIT PDU
+
+          SetRequest-PDU ::=
+              [3]
+                  IMPLICIT PDU
+
+          PDU ::=
+                  SEQUENCE {
+                     request-id
+                          INTEGER,
+
+                      error-status      -- sometimes ignored
+                          INTEGER {
+                              noError(0),
+                              tooBig(1),
+                              noSuchName(2),
+                              badValue(3),
+                              readOnly(4),
+                              genErr(5)
+                          },
+
+                      error-index       -- sometimes ignored
+                         INTEGER,
+
+                      variable-bindings -- values are sometimes ignored
+                          VarBindList
+                  }
+
+          Trap-PDU ::=
+              [4]
+                 IMPLICIT SEQUENCE {
+                      enterprise        -- type of object generating
+                                        -- trap, see sysObjectID in [2]
+
+
+                          OBJECT IDENTIFIER,
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 30]
+
+RFC 1067                          SNMP                       August 1988
+
+
+                      agent-addr        -- address of object generating
+                          NetworkAddress, -- trap
+
+                      generic-trap      -- generic trap type
+                          INTEGER {
+                              coldStart(0),
+                              warmStart(1),
+                              linkDown(2),
+                              linkUp(3),
+                              authenticationFailure(4),
+                              egpNeighborLoss(5),
+                              enterpriseSpecific(6)
+                          },
+
+                      specific-trap  -- specific code, present even
+                          INTEGER,   -- if generic-trap is not
+                                     -- enterpriseSpecific
+
+                      time-stamp     -- time elapsed between the last
+                          TimeTicks, -- (re)initialization of the
+                                        network
+                                     -- entity and the generation of the
+                                        trap
+
+                       variable-bindings -- "interesting" information
+                          VarBindList
+                  }
+
+
+          -- variable bindings
+
+          VarBind ::=
+                  SEQUENCE {
+                      name
+                          ObjectName,
+
+                      value
+                          ObjectSyntax
+                  }
+
+         VarBindList ::=
+                  SEQUENCE OF
+                     VarBind
+
+         END
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 31]
+
+RFC 1067                          SNMP                       August 1988
+
+
+6.  Acknowledgements
+
+   This memo was influenced by the IETF SNMP Extensions working
+   group:
+
+             Karl Auerbach, Epilogue Technology
+             K. Ramesh Babu, Excelan
+             Amatzia Ben-Artzi, 3Com/Bridge
+             Lawrence Besaw, Hewlett-Packard
+             Jeffrey D. Case, University of Tennessee at Knoxville
+             Anthony Chung, Sytek
+             James Davidson, The Wollongong Group
+             James R. Davin, Proteon
+             Mark S. Fedor, NYSERNet
+             Phill Gross, The MITRE Corporation
+             Satish Joshi, ACC
+             Dan Lynch, Advanced Computing Environments
+             Keith McCloghrie, The Wollongong Group
+             Marshall T. Rose, The Wollongong Group (chair)
+             Greg Satz, cisco
+             Martin Lee Schoffstall, Rensselaer Polytechnic Institute
+             Wengyik Yeong, NYSERNet
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 32]
+
+RFC 1067                          SNMP                       August 1988
+
+
+7.  References
+
+   [1] Cerf, V., "IAB Recommendations for the Development of
+       Internet Network Management Standards", RFC 1052, IAB,
+       April 1988.
+
+   [2] Rose, M., and K. McCloghrie, "Structure and Identification
+       of Management Information for TCP/IP-based internets",
+       RFC 1065, TWG, August 1988.
+
+   [3] McCloghrie, K., and M. Rose, "Management Information Base
+       for Network Management of TCP/IP-based internets",
+       RFC 1066, TWG, August 1988.
+
+   [4] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
+       "A Simple Network Management Protocol", Internet
+       Engineering Task Force working note, Network Information
+       Center, SRI International, Menlo Park, California,
+       March 1988.
+
+   [5] Davin, J., J. Case, M. Fedor, and M. Schoffstall,
+       "A Simple Gateway Monitoring Protocol", RFC 1028,
+       Proteon, University of Tennessee at Knoxville,
+       Cornell University, and Rensselaer Polytechnic
+       Institute, November 1987.
+
+   [6] Information processing systems - Open Systems
+       Interconnection, "Specification of Abstract Syntax
+       Notation One (ASN.1)", International Organization for
+       Standardization, International Standard 8824,
+       December 1987.
+
+   [7] Information processing systems - Open Systems
+       Interconnection, "Specification of Basic Encoding Rules
+       for Abstract Notation One (ASN.1)", International
+       Organization for Standardization, International Standard
+       8825, December 1987.
+
+   [8] Postel, J., "User Datagram Protocol", RFC 768,
+       USC/Information Sciences Institute, November 1980.
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 33]