Network Working Group
`Request for Comments: 1271
`
`S. Waldbusser
`Carnegie Mellon University
`November 1991
`
`Remote Network Monitoring Management Information Base
`
`Status of this Memo
`
` This memo is an extension to the SNMP MIB. This RFC specifies an IAB
` standards track protocol for the Internet community, and requests
` discussion and suggestions for improvements. Please refer to the
` current edition of the "IAB Official Protocol Standards" for the
` standardization state and status of this protocol. Distribution of
` this memo is unlimited.
`
`Table of Contents
`
`1. Abstract .............................................. 2
`2. The Network Management Framework....................... 2
`3. Objects ............................................... 2
` 3.1 Format of Definitions ................................ 3
`4. Overview .............................................. 3
` 4.1 Remote Network Management Goals ...................... 3
` 4.2 Textual Conventions .................................. 5
` 4.3 Structure of MIB ..................................... 5
` 4.3.1 The Statistics Group ............................... 6
` 4.3.2 The History Group .................................. 6
` 4.3.3 The Alarm Group .................................... 6
` 4.3.4 The Host Group ..................................... 6
` 4.3.5 The HostTopN Group ................................. 6
` 4.3.6 The Matrix Group ................................... 7
` 4.3.7 The Filter Group ................................... 7
` 4.3.8 The Packet Capture Group ........................... 7
` 4.3.9 The Event Group .................................... 7
`5. Control of Remote Network Monitoring Devices .......... 7
` 5.1 Resource Sharing Among Multiple Management Stations .. 8
` 5.2 Row Addition Among Multiple Management Stations ...... 9
`6. Definitions ........................................... 10
`7. Acknowledgments ....................................... 80
`8. References ............................................ 80
` Security Considerations................................... 81
` Author’s Address.......................................... 81
`
`Remote Network Monitoring Working Group
`
`[Page 1]
`
`Petitioners' EX1022 Page 1
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
`1. Abstract
`
` This memo defines a portion of the Management Information Base (MIB)
` for use with network management protocols in TCP/IP-based internets.
` In particular, it defines objects for managing remote network
` monitoring devices.
`
`2. The Network Management Framework
`
` The Internet-standard Network Management Framework consists of three
` components. They are:
`
` RFC 1155 which defines the SMI, the mechanisms used for describing
` and naming objects for the purpose of management. RFC 1212
` defines a more concise description mechanism, which is wholly
` consistent with the SMI.
`
` RFC 1156 which defines MIB-I, the core set of managed objects for
` the Internet suite of protocols. RFC 1213, defines MIB-II, an
` evolution of MIB-I based on implementation experience and new
` operational requirements.
`
` RFC 1157 which defines the SNMP, the protocol used for network
` access to managed objects.
`
` The Framework permits new objects to be defined for the purpose of
` experimentation and evaluation.
`
`3. Objects
`
` Managed objects are accessed via a virtual information store, termed
` the Management Information Base or MIB. Objects in the MIB are
` defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
` defined in the SMI. In particular, each object has a name, a syntax,
` and an encoding. The name is an object identifier, an
` administratively assigned name, which specifies an object type. The
` object type together with an object instance serves to uniquely
` identify a specific instantiation of the object. For human
` convenience, we often use a textual string, termed the OBJECT
` DESCRIPTOR, to also refer to the object type.
`
` The syntax of an object type defines the abstract data structure
` corresponding to that object type. The ASN.1 language is used for
` this purpose. However, the SMI [3] purposely restricts the ASN.1
` constructs which may be used. These restrictions are explicitly made
` for simplicity.
`
` The encoding of an object type is simply how that object type
`
`Remote Network Monitoring Working Group [Page 2]
`
`Petitioners' EX1022 Page 2
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` is represented using the object type’s syntax. Implicitly
` tied to the notion of an object type’s syntax and encoding is
` how the object type is represented when being transmitted on
` the network.
`
` The SMI specifies the use of the basic encoding rules of ASN.1 [8],
` subject to the additional requirements imposed by the SNMP.
`
`3.1. Format of Definitions
`
` Section 6 contains the specification of all object types
` contained in this MIB module. The object types are defined
` using the conventions defined in the SMI, as amended by the
` extensions specified in [9,10].
`
`4. Overview
`
` Remote network monitoring devices are instruments that exist for the
` purpose of managing a network. Often these remote probes are
` stand-alone devices and devote significant internal resources for the
` sole purpose of managing a network. An organization may employ many
` of these devices, one per network segment, to manage its internet. In
` addition, these devices may be used for a network management service
` provider to access a client network, often geographically remote.
`
` While many of the objects in this document are suitable for the
` management of any type of network, there are some which are specific
` to managing Ethernet networks. The design of this MIB allows similar
` objects to be defined for other network types. It is intended that
` future versions of this document will define extensions for other
` network types such as Token Ring and FDDI.
`
`4.1. Remote Network Management Goals
`
` o Offline Operation
` There are sometimes conditions when a management
` station will not be in constant contact with its
` remote monitoring devices. This is sometimes by
` design in an attempt to lower communications costs
` (especially when communicating over a WAN or
` dialup link), or by accident as network failures
` affect the communications between the management
` station and the probe.
`
` For this reason, this MIB allows a probe to be
` configured to perform diagnostics and to collect
` statistics continuously, even when communication with
` the management station may not be possible or
`
`Remote Network Monitoring Working Group [Page 3]
`
`Petitioners' EX1022 Page 3
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` efficient. The probe may then attempt to notify
` the management station when an exceptional condition
` occurs. Thus, even in circumstances where
` communication between management station and probe is
` not continuous, fault, performance, and configuration
` information may be continuously accumulated and
` communicated to the management station conveniently
` and efficiently.
`
` o Preemptive Monitoring
` Given the resources available on the monitor, it
` is potentially helpful for it continuously to run
` diagnostics and to log network performance. The
` monitor is always available at the onset of any
` failure. It can notify the management station of the
` failure and can store historical statistical
` information about the failure. This historical
` information can be played back by the management
` station in an attempt to perform further diagnosis
` into the cause of the problem.
`
` o Problem Detection and Reporting
` The monitor can be configured to recognize
` conditions, most notably error conditions, and
` continuously to check for them. When one of these
` conditions occurs, the event may be logged, and
` management stations may be notified in a number of
` ways.
`
` o Value Added Data
` Because a remote monitoring device represents a
` network resource dedicated exclusively to network
` management functions, and because it is located
` directly on the monitored portion of the network, the
` remote network monitoring device has the opportunity
` to add significant value to the data it collects.
` For instance, by highlighting those hosts on the
` network that generate the most traffic or errors, the
` probe can give the management station precisely the
` information it needs to solve a class of problems.
`
` o Multiple Managers
` An organization may have multiple management stations
` for different units of the organization, for different
` functions (e.g. engineering and operations), and in an
` attempt to provide disaster recovery. Because
` environments with multiple management stations are
` common, the remote network monitoring device has to
`
`Remote Network Monitoring Working Group [Page 4]
`
`Petitioners' EX1022 Page 4
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` deal with more than own management station,
` potentially using its resources concurrently.
`
`4.2. Textual Conventions
`
` Two new data types are introduced as a textual convention in this MIB
` document. These textual conventions enhance the readability of the
` specification and can ease comparison with other specifications if
` appropriate. It should be noted that the introduction of the these
` textual conventions has no effect on either the syntax nor the
` semantics of any managed objects. The use of these is merely an
` artifact of the explanatory method used. Objects defined in terms of
` one of these methods are always encoded by means of the rules that
` define the primitive type. Hence, no changes to the SMI or the SNMP
` are necessary to accommodate these textual conventions which are
` adopted merely for the convenience of readers and writers in pursuit
` of the elusive goal of clear, concise, and unambiguous MIB documents.
`
` The new data types are: OwnerString and EntryStatus.
`
`4.3. Structure of MIB
`
` The objects are arranged into the following groups:
`
` - statistics
`
` - history
`
` - alarm
`
` - host
`
` - hostTopN
`
` - matrix
`
` - filter
`
` - packet capture
`
` - event
`
` These groups are the basic unit of conformance. If a remote
` monitoring device implements a group, then it must implement all
` objects in that group. For example, a managed agent that implements
` the host group must implement the hostControlTable, the hostTable and
` the hostTimeTable.
`
`Remote Network Monitoring Working Group [Page 5]
`
`Petitioners' EX1022 Page 5
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` All groups in this MIB are optional. Implementations of this MIB
` must also implement the system and interfaces group of MIB-II [6].
` MIB-II may also mandate the implementation of additional groups.
`
` These groups are defined to provide a means of assigning object
` identifiers, and to provide a method for managed agents to know which
` objects they must implement.
`
`4.3.1. The Statistics Group
`
` The statistics group contains statistics measured by the probe for
` each monitored interface on this device. This group currently
` consists of the etherStatsTable but in the future will contain tables
` for other media types including Token Ring and FDDI.
`
`4.3.2. The History Group
`
` The history group records periodic statistical samples from a network
` and stores them for later retrieval. This group currently consists
` of the historyControlTable and the etherHistoryTable. In future
` versions of the MIB, this group may contain tables for other media
` types including Token Ring and FDDI.
`
`4.3.3. The Alarm Group
`
` The alarm group periodically takes statistical samples from variables
` in the probe and compares them to previously configured thresholds.
` If the monitored variable crosses a threshold, an event is generated.
` A hysteresis mechanism is implemented to limit the generation of
` alarms. This group consists of the alarmTable and requires the
` implementation of the event group.
`
`4.3.4. The Host Group
`
` The host group contains statistics associated with each host
` discovered on the network. This group discovers hosts on the network
` by keeping a list of source and destination MAC Addresses seen in
` good packets promiscuously received from the network. This group
` consists of the hostControlTable, the hostTable, and the
` hostTimeTable.
`
`4.3.5. The HostTopN Group
`
` The hostTopN group is used to prepare reports that describe the hosts
` that top a list ordered by one of their statistics. The available
` statistics are samples of one of their base statistics over an
` interval specified by the management station. Thus, these statistics
` are rate based. The management station also selects how many such
`
`Remote Network Monitoring Working Group [Page 6]
`
`Petitioners' EX1022 Page 6
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` hosts are reported. This group consists of the hostTopNControlTable
` and the hostTopNTable, and requires the implementation of the host
` group.
`
`4.3.6. The Matrix Group
`
` The matrix group stores statistics for conversations between sets of
` two addresses. As the device detects a new conversation, it creates
` a new entry in its tables. This group consists of the
` matrixControlTable, the matrixSDTable and the matrixDSTable.
`
`4.3.7. The Filter Group
`
` The filter group allows packets to be matched by a filter equation.
` These matched packets form a data stream that may be captured or may
` generate events. This group consists of the filterTable and the
` channelTable.
`
`4.3.8. The Packet Capture Group
`
` The Packet Capture group allows packets to be captured after they
` flow through a channel. This group consists of the
` bufferControlTable and the captureBufferTable, and requires the
` implementation of the filter group.
`
`4.3.9. The Event Group
`
` The event group controls the generation and notification of events
` from this device. This group consists of the eventTable and the
` logTable.
`
`5. Control of Remote Network Monitoring Devices
`
` Due to the complex nature of the available functions in these
` devices, the functions often need user configuration. In many cases,
` the function requires parameters to be set up for a data collection
` operation. The operation can proceed only after these parameters are
` fully set up.
`
` Many functional groups in this MIB have one or more tables in which
` to set up control parameters, and one or more data tables in which to
` place the results of the operation. The control tables are typically
` read-write in nature, while the data tables are typically read-only.
` Because the parameters in the control table often describe resulting
` data in the data table, many of the parameters can be modified only
` when the control entry is invalid. Thus, the method for modifying
` these parameters is to invalidate the control entry, causing its
` deletion and the deletion of any associated data entries, and then
`
`Remote Network Monitoring Working Group [Page 7]
`
`Petitioners' EX1022 Page 7
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` create a new control entry with the proper parameters. Deleting the
` control entry also gives a convenient method for reclaiming the
` resources used by the associated data.
`
` Some objects in this MIB provide a mechanism to execute an action on
` the remote monitoring device. These objects may execute an action as
` a result of a change in the state of the object. For those objects
` in this MIB, a request to set an object to the same value as it
` currently holds would thus cause no action to occur.
`
` To facilitate control by multiple managers, resources have to be
` shared among the managers. These resources are typically the memory
` and computation resources that a function requires.
`
`5.1. Resource Sharing Among Multiple Management Stations
`
` When multiple management stations wish to use functions that compete
` for a finite amount of resources on a device, a method to facilitate
` this sharing of resources is required. Potential conflicts include:
`
` o Two management stations wish to simultaneously use
` resources that together would exceed the capability of
` the device.
`
` o A management station uses a significant amount of
` resources for a long period of time.
`
` o A management station uses resources and then crashes,
` forgetting to free the resources so others may
` use them.
`
` A mechanism is provided for each management station initiated
` function in this MIB to avoid these conflicts and to help resolve
` them when they occur. Each function has a label identifying the
` initiator (owner) of the function. This label is set by the
` initiator to provide for the following possibilities:
`
` o A management station may recognize resources it owns
` and no longer needs.
`
` o A network operator can find the management station that
` owns the resource and negotiate for it to be freed.
`
` o A network operator may decide to unilaterally free
` resources another network operator has reserved.
`
` o Upon initialization, a management station may recognize
` resources it had reserved in the past. With this
`
`Remote Network Monitoring Working Group [Page 8]
`
`Petitioners' EX1022 Page 8
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` information it may free the resources if it no longer
` needs them.
`
` Management stations and probes should support any format of the owner
` string dictated by the local policy of the organization. It is
` suggested that this name contain one or more of the following: IP
` address, management station name, network manager’s name, location,
` or phone number. This information will help users to share the
` resources more effectively.
`
` There is often default functionality that the device wishes to set
` up. The resources associated with this functionality are then owned
` by the device itself. In this case, the device will set the relevant
` owner object to a string starting with ’monitor’. Indiscriminate
` modification of the monitor-owned configuration by network management
` stations is discouraged. In fact, a network management station
` should only modify these objects under the direction of the
` administrator of the probe, often the network administrator.
`
` When a network management station wishes to utilize a function in a
` monitor, it is encouraged to first scan the control table of that
` function to find an instance with similar parameters to share. This
` is especially true for those instances owned by the monitor, which
` can be assumed to change infrequently. If a management station
` decides to share an instance owned by another management station, it
` should understand that the management station that owns the instance
` may indiscriminately modify or delete it.
`
`5.2. Row Addition Among Multiple Management Stations
`
` The addition of new rows is achieved using the method described in
` [9]. In this MIB, rows are often added to a table in order to
` configure a function. This configuration usually involves parameters
` that control the operation of the function. The agent must check
` these parameters to make sure they are appropriate given restrictions
` defined in this MIB as well as any implementation specific
` restrictions such as lack of resources. The agent implementor may be
` confused as to when to check these parameters and when to signal to
` the management station that the parameters are invalid. There are
` two opportunities:
`
` o When the management station sets each parameter object.
`
` o When the management station sets the entry status object
` to valid.
`
` If the latter is chosen, it would be unclear to the management
` station which of the several parameters was invalid and caused the
`
`Remote Network Monitoring Working Group [Page 9]
`
`Petitioners' EX1022 Page 9
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` badValue error to be emitted. Thus, wherever possible, the
` implementor should choose the former as it will provide more
` information to the management station.
`
` A problem can arise when multiple management stations attempt to set
` configuration information simultaneously using SNMP. When this
` involves the addition of a new conceptual row in the same control
` table, the managers may collide, attempting to create the same entry.
` To guard against these collisions, each such control entry contains a
` status object with special semantics that help to arbitrate among the
` managers. If an attempt is made with the row addition mechanism to
` create such a status object and that object already exists, an error
` is returned. When more than one manager simultaneously attempts to
` create the same conceptual row, only the first will succeed. The
` others will receive an error.
`
`6. Definitions
`
` RFC1271-MIB DEFINITIONS ::= BEGIN
`
` IMPORTS
` Counter FROM RFC1155-SMI
` DisplayString FROM RFC1158-MIB
` mib-2 FROM RFC1213-MIB
` OBJECT-TYPE FROM RFC-1212;
`
` -- This MIB module uses the extended OBJECT-TYPE macro as
` -- defined in [9].
`
` -- Remote Network Monitoring MIB
`
` rmon OBJECT IDENTIFIER ::= { mib-2 16 }
`
` -- textual conventions
`
` OwnerString ::= DisplayString
` -- This data type is used to model an administratively
` -- assigned name of the owner of a resource. This
` -- information is taken from the NVT ASCII character set.
` -- It is suggested that this name contain one or more
` -- of the following:
` -- IP address, management station name, network manager’s
` -- name, location, or phone number.
` -- In some cases the agent itself will be the owner of
` -- an entry. In these cases, this string shall be set
` -- to a string starting with ’monitor’.
`
`Remote Network Monitoring Working Group [Page 10]
`
`Petitioners' EX1022 Page 10
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` --
` -- SNMP access control is articulated entirely in terms of
` -- the contents of MIB views; access to a particular SNMP
` -- object instance depends only upon its presence or
` -- absence in a particular MIB view and never upon its
` -- value or the value of related object instances. Thus,
` -- objects of this type afford resolution of resource
` -- contention only among cooperating managers; they
` -- realize no access control function with respect
` -- to uncooperative parties.
` --
` -- By convention, objects with this syntax are declared
` -- as having
` --
` -- SIZE (0..127)
`
` EntryStatus ::= INTEGER
` { valid(1),
` createRequest(2),
` underCreation(3),
` invalid(4)
` }
`
` -- The status of a table entry.
` --
` -- Setting this object to the value invalid(4) has the
` -- effect of invalidating the corresponding entry.
` -- That is, it effectively disassociates the mapping
` -- identified with said entry.
` -- It is an implementation-specific matter as to whether
` -- the agent removes an invalidated entry from the table.
` -- Accordingly, management stations must be prepared to
` -- receive tabular information from agents that corresponds
` -- to entries currently not in use. Proper
` -- interpretation of such entries requires examination
` -- of the relevant EntryStatus object.
` --
` -- An existing instance of this object cannot be set to
` -- createRequest(2). This object may only be set to
` -- createRequest(2) when this instance is created. When
` -- this object is created, the agent may wish to create
` -- supplemental object instances to complete a conceptual
` -- row in this table. Immediately after completing the
` -- create operation, the agent must set this object to
` -- underCreation(3).
` --
` -- Entries shall exist in the underCreation(3) state until
`
`Remote Network Monitoring Working Group [Page 11]
`
`Petitioners' EX1022 Page 11
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` -- the management station is finished configuring the
` -- entry and sets this object to valid(1) or aborts,
` -- setting this object to invalid(4). If the agent
` -- determines that an entry has been in the
` -- underCreation(3) state for an abnormally long time,
` -- it may decide that the management station has
` -- crashed. If the agent makes this decision,
` -- it may set this object to invalid(4) to reclaim the
` -- entry. A prudent agent will understand that the
` -- management station may need to wait for human input
` -- and will allow for that possibility in its
` -- determination of this abnormally long period.
`
` statistics OBJECT IDENTIFIER ::= { rmon 1 }
` history OBJECT IDENTIFIER ::= { rmon 2 }
` alarm OBJECT IDENTIFIER ::= { rmon 3 }
` hosts OBJECT IDENTIFIER ::= { rmon 4 }
` hostTopN OBJECT IDENTIFIER ::= { rmon 5 }
` matrix OBJECT IDENTIFIER ::= { rmon 6 }
` filter OBJECT IDENTIFIER ::= { rmon 7 }
` capture OBJECT IDENTIFIER ::= { rmon 8 }
` event OBJECT IDENTIFIER ::= { rmon 9 }
`
` -- The Statistics Group
` --
` -- Implementation of the Statistics group is optional.
` --
` -- The statistics group contains statistics measured by the
` -- probe for each monitored interface on this device. These
` -- statistics take the form of free running counters that
` -- start from zero when a valid entry is created.
` --
` -- This group currently has statistics defined only for
` -- Ethernet interfaces. Each etherStatsEntry contains
` -- statistics for one Ethernet interface. The probe must
` -- create one etherStats entry for each monitored Ethernet
` -- interface on the device.
`
` etherStatsTable OBJECT-TYPE
` SYNTAX SEQUENCE OF EtherStatsEntry
` ACCESS not-accessible
` STATUS mandatory
` DESCRIPTION
` "A list of Ethernet statistics entries."
` ::= { statistics 1 }
`
`Remote Network Monitoring Working Group [Page 12]
`
`Petitioners' EX1022 Page 12
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` etherStatsEntry OBJECT-TYPE
` SYNTAX EtherStatsEntry
` ACCESS not-accessible
` STATUS mandatory
` DESCRIPTION
` "A collection of statistics kept for a particular
` Ethernet interface."
` INDEX { etherStatsIndex }
` ::= { etherStatsTable 1 }
`
` EtherStatsEntry ::= SEQUENCE {
` etherStatsIndex INTEGER (1..65535),
` etherStatsDataSource OBJECT IDENTIFIER,
` etherStatsDropEvents Counter,
` etherStatsOctets Counter,
` etherStatsPkts Counter,
` etherStatsBroadcastPkts Counter,
` etherStatsMulticastPkts Counter,
` etherStatsCRCAlignErrors Counter,
` etherStatsUndersizePkts Counter,
` etherStatsOversizePkts Counter,
` etherStatsFragments Counter,
` etherStatsJabbers Counter,
` etherStatsCollisions Counter,
` etherStatsPkts64Octets Counter,
` etherStatsPkts65to127Octets Counter,
` etherStatsPkts128to255Octets Counter,
` etherStatsPkts256to511Octets Counter,
` etherStatsPkts512to1023Octets Counter,
` etherStatsPkts1024to1518Octets Counter,
` etherStatsOwner OwnerString,
` etherStatsStatus INTEGER
` }
`
` etherStatsIndex OBJECT-TYPE
` SYNTAX INTEGER (1..65535)
` ACCESS read-only
` STATUS mandatory
` DESCRIPTION
` "The value of this object uniquely identifies this
` etherStats entry."
` ::= { etherStatsEntry 1 }
`
` etherStatsDataSource OBJECT-TYPE
` SYNTAX OBJECT IDENTIFIER
` ACCESS read-write
` STATUS mandatory
` DESCRIPTION
`
`Remote Network Monitoring Working Group [Page 13]
`
`Petitioners' EX1022 Page 13
`
`

`
`
`RFC 1271 Remote Network Monitoring MIB November 1991
`
` "This object identifies the source of the data that
` this etherStats entry is configured to analyze. This
` source can be any ethernet interface on this device.
` In order to identify a particular interface, this
` object shall identify the instance of the ifIndex
` object, defined in [4,6], for the desired interface.
` For example, if an entry were to receive data from
` interface #1, this object would be set to ifIndex.1.
`
` The statistics in this group reflect all packets
` on the local network segment attached to the
` identified interface.
`
` This object may not be modified if the associated
` etherStatsStatus object is equal to valid(1)."
` ::= { etherStatsEntry 2 }
`
` etherStatsDropEven