Network Working Group
`Request for Comments: 1067
`
`J. Case
`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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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]
`
`Petitioners' EX1021 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
`
` I