Internet Draft Remote Network Monitoring MIB May 1, 1995 Remote Network Monitoring Management Information Base May 1, 1995 Editor: Steven Waldbusser waldbusser@cmu.edu 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, venera.isi.edu, or munnari.oz.au. 2. Abstract This memo defines an experimental 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. Steven Waldbusser Expires Nov 1, 1995 [Page 1] Internet Draft Remote Network Monitoring MIB May 1, 1995 This memo does not specify a standard for the Internet community. Steven Waldbusser Expires Nov 1, 1995 [Page 2] Internet Draft Remote Network Monitoring MIB May 1, 1995 3. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: RFC 1155[1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1212[2] defines a more concise description mechanism, which is wholly consistent with the SMI. RFC 1213[3] which defines MIB-II, the core set of managed objects for the Internet suite of protocols. RFC 1157[4] 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. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Within a given MIB module, objects are defined using RFC 1212's OBJECT-TYPE macro. At a minimum, each object has a name, a syntax, an access-level, and an implementation-status. 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[5] language is used for this purpose. However, RFC 1155 purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The access-level of an object type defines whether it makes "protocol sense" to read and/or write the value of an instance of the object type. (This access-level is independent of any administrative authorization policy.) The implementation-status of an object type indicates whether the object is mandatory, optional, obsolete, or deprecated. Steven Waldbusser Expires Nov 1, 1995 [Page 3] Internet Draft Remote Network Monitoring MIB May 1, 1995 4. Overview Remote network monitoring devices, often called monitors or probes, 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. The objects defined in this document are intended as an interface between an RMON agent and an RMON management application and are not intended for direct manipulation by humans. While some users may tolerate the direct display of some of these objects, few will tolerate the complexity of manually manipulating objects to accomplish row creation. These functions should be handled by the management application. 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 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 Steven Waldbusser Expires Nov 1, 1995 [Page 4] Internet Draft Remote Network Monitoring MIB May 1, 1995 and efficiently. o Proactive 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 deal with more than own management station, potentially using its resources concurrently. Steven Waldbusser Expires Nov 1, 1995 [Page 5] Internet Draft Remote Network Monitoring MIB May 1, 1995 4.2. Structure of MIB The objects are arranged into the following groups: - protocol directory - protocol distribution - address mapping - network layer host - network layer matrix 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 network layer matrix group must implement the nlMatrixSDTable and the nlMatrixDSTable. 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. Steven Waldbusser Expires Nov 1, 1995 [Page 6] Internet Draft Remote Network Monitoring MIB May 1, 1995 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 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. Steven Waldbusser Expires Nov 1, 1995 [Page 7] Internet Draft Remote Network Monitoring MIB May 1, 1995 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 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 or the administrator of the probe (often the network administrator) wishes to set up. The resources associated with this functionality are then owned by the device itself or by the network administrator, and are intended to be long-lived. In this case, the device or the administrator 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. Resources on a probe are scarce and are typically allocated Steven Waldbusser Expires Nov 1, 1995 [Page 8] Internet Draft Remote Network Monitoring MIB May 1, 1995 when control rows are created by an application. Since many applications may be using a probe simultaneously, indiscriminate allocation of resources to particular applications is very likely to cause resource shortages in the probe. 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. It should be noted that a management application should have the most trust in a monitor-owned row because it should be changed very infrequently. A row owned by the management application is less long-lived because a network administrator is more likely to re-assign resources from a row that is in use by one user than from a monitor-owned row that is potentially in use by many users. A row owned by another application would be even less long-lived because the other application may delete or modify that row completely at its discretion. 5.2. Row Addition Among Multiple Management Stations The addition of new rows is achieved using the method described in RFC 1212 [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 Steven Waldbusser Expires Nov 1, 1995 [Page 9] Internet Draft Remote Network Monitoring MIB May 1, 1995 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 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. When a manager wishes to create a new control entry, it needs to choose an index for that row. It may choose this index in a variety of ways, hopefully minimizing the chances that the index is in use by another manager. If the index is in use, the mechanism mentioned previously will guard against collisions. Examples of schemes to choose index values include random selection or scanning the control table looking for the first unused index. Because index values may be any valid value in the range and they are chosen by the manager, the agent must allow a row to be created with any unused index value if it has the resources to create a new row. Some tables in this MIB reference other tables within this MIB. When creating or deleting entries in these tables, it is generally allowable for dangling references to exist. There is no defined order for creating or deleting entries in these tables. Steven Waldbusser Expires Nov 1, 1995 [Page 10] Internet Draft Remote Network Monitoring MIB May 1, 1995 6. Conventions The following conventions are used throughout the RMON MIB and its companion documents. Good Packets Good packets are error-free packets that have a valid frame length. For example, on Ethernet, good packets are error-free packets that are between 64 octets long and 1518 octets long. They follow the form defined in IEEE 802.3 section 3.2.all. Bad Packets Bad packets are packets that have proper framing and are therefore recognized as packets, but contain errors within the packet or have an invalid length. For example, on Ethernet, bad packets have a valid preamble and SFD, but have a bad CRC, or are either shorter than 64 octets or longer than 1518 octets. Steven Waldbusser Expires Nov 1, 1995 [Page 11] Internet Draft Remote Network Monitoring MIB May 1, 1995 7. Definitions RMON2-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, TimeTicks, NOTIFICATION-TYPE, OBJECT-IDENTITY, zeroDotZero FROM SNMPv2-SMI TEXTUAL-CONVENTION, RowStatus, DisplayString, MacAddress FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF mib-2 FROM RFC1213-MIB rmon, OwnerString FROM RFC1757-MIB; -- Remote Network Monitoring MIB rmon MODULE-IDENTITY LAST-UPDATED "9505010000Z" ORGANIZATION "IETF RMON MIB Working Group" CONTACT-INFO "Andy Bierman (WG Chair) Postal: Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 8951 Email: abierman@cisco.com Steve Waldbusser (WG Editor) Postal: Phone: Email: " DESCRIPTION "The MIB module for managing remote monitoring device implementations. This MIB module augments the original RMON MIB as specified in RFC 1757." ::= { mib-2 16 } protocolDir OBJECT IDENTIFIER ::= { rmon 11 } protocolDist OBJECT IDENTIFIER ::= { rmon 12 } addressMap OBJECT IDENTIFIER ::= { rmon 13 } Steven Waldbusser Expires Nov 1, 1995 [Page 12] Internet Draft Remote Network Monitoring MIB May 1, 1995 nlHost OBJECT IDENTIFIER ::= { rmon 14 } nlMatrix OBJECT IDENTIFIER ::= { rmon 15 } Steven Waldbusser Expires Nov 1, 1995 [Page 13] Internet Draft Remote Network Monitoring MIB May 1, 1995 -- Textual Conventions ProtocolCollectionState ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents the data collection state for a particular protocol, enabled by setting instances of objects of this type to on(2). Collection is disabled by setting instances of objects of this type to off(1). A probe should retain statistics for all protocols specified in the related collection control table, even if the protocol collection state is 'off(1)'. A probe should remove entries in the relevant data collection table if the associated protocol control entry or collection control entry is deleted. " SYNTAX INTEGER { off(1), on(2) } TimeFilter ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Represents a value of sysUpTime to be used as an an index component in data data tables. Only data entries which have changed since the specified TimeFilter index value are returned in SNMP retrieval operations. ... [??? Need to describe this in more detail... I'm punting on this one...Jeanne and Robin can fill in the blanks ???] " SYNTAX TimeTicks Steven Waldbusser Expires Nov 1, 1995 [Page 14] Internet Draft Remote Network Monitoring MIB May 1, 1995 protocolDirTable OBJECT-TYPE SYNTAX SEQUENCE OF ProtocolDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the protocols that this agent has the capability to decode and count. There is one entry in this table for each such protocol. These protocols represent different network layer, transport layer, and higher-layer protocols. The agent should boot up with this table preconfigured with those protocols that it knows about and wishes to monitor." ::= { protocolDist 1 } protocolDirEntry OBJECT-TYPE SYNTAX ProtocolDirEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists the protocols that this agent has the capability to decode and count. There is one entry in this table for each such protocol. These protocols represent different network layer, transport layer, and higher-layer protocols. The agent should boot up with this table preconfigured with those protocols that it knows about and wishes to monitor." INDEX { protocolDirID } ::= { protocolDirTable 1 } ProtocolDirEntry ::= SEQUENCE { protocolDirID OBJECT IDENTIFIER, protocolDirParentID OBJECT IDENTIFIER, protocolDirIndex Integer32, protocolDirDescr DisplayString, protocolDirOwner OwnerString, protocolDirStatus RowStatus } protocolDirID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique identifier for a particular protocol. Standard object identifiers will be defined in a manner such that they Steven Waldbusser Expires Nov 1, 1995 [Page 15] Internet Draft Remote Network Monitoring MIB May 1, 1995 can often be used as specifications for new protocols - i.e. a tree-structured assignment mechanism that matches the protocol encapsulation "tree" and which has algorithmic assignment mechanisms for certain subtrees. For example: protocolDir.assignments.ethernet -- children of ethernet will have values representing the -- two byte ethertype value of an ethernet protocol. Some -- well-known ones are defined below. protocolDir.assignments.ethernet.ip -- children of ip will have values representing the -- one byte value of an ip protocol. Some -- well-known ones are defined below. ... protocolDir.assignments.ethernet.ip.udp.dns Despite the algorithmic mechanism, the probe will only place entries in here for those protocols it chooses to collect. In other words, it need not populate this table with all of the possible ethernet protocol types, nor need it create them on the fly when it sees them. Whether or not it does these things is a matter of product definition (cost/benefit, usability), and is up to the designer of the product. If an entry is written to this table with a protocolID that the agent doesn't understand, either directly or algorithmicly, the SET request will be rejected with an inconsistentName or badValue (for SNMPv1) error." ::= { protocolDirEntry 1 } protocolDirParentID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "The parent protocol that this protocol entry is encapsulated within. If there is no parent protocol (i.e. for ethernet), this value shall be { 0 0 }." ::= { protocolDirEntry 2 } protocolDirIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) Steven Waldbusser Expires Nov 1, 1995 [Page 16] Internet Draft Remote Network Monitoring MIB May 1, 1995 MAX-ACCESS read-only STATUS current DESCRIPTION "The locally arbitrary, but unique identifier associated with this protocolDir entry. The value for each supported protocol must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization. The specific value is meaningful only within a given SNMP entity. A protocolDirIndex may not be re-used until the next agent-restart, in the event the protocol directory entry is deleted." ::= { protocolDirEntry 3 } protocolDirDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (1..64)) MAX-ACCESS read-create STATUS current DESCRIPTION "A textual description of the protocol encapsulation. A probe may choose to describe only a subset of the entire encapsulation (e.g. only the highest layer). This object may not be modified if the associated protocolDirStatus object is equal to active(1)." ::= { protocolDirEntry 4 } protocolDirOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The owner of this protocol directory entry." ::= { protocolDirEntry 5 } protocolDirStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this protocol directory entry. A protocol is not qualified for activation until instances of Steven Waldbusser Expires Nov 1, 1995 [Page 17] Internet Draft Remote Network Monitoring MIB May 1, 1995 all columns of its protocolDirEntry row have an appropriate value. In particular, one or more management set operations are required to configure the protocol entry: a value must be written to the protocolDirDescr object. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the protocolDirStatus column is `notReady'. For those columnar objects which permit write-access (after their initial creation), their value in an existing conceptual row can be changed irrespective of the value of protocolDirStatus for that row." ::= { protocolDirEntry 6 } protocolAssignments OBJECT IDENTIFIER ::= { protocolDir 2 } -- -- Protocol Distribution Group (protocolDist) -- -- Controls basic segment-level data collection. -- protocolDistControlTable, -- protocolDistStatsTable protocolDistControlTable OBJECT-TYPE SYNTAX SEQUENCE OF ProtocolDistControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls the setup of protocol type distribution statistics tables. Rationale: This table controls collection of very basic statistics for any or all of the protocols detected on a given interface. An NMS can use this table to quickly determine bandwidth allocation utilized by different protocols. A media-specific statistics collection could also be configured (e.g. etherStats, trPStats) to easily obtain total frame, octet, and droppedEvents for the same interface." ::= { protocolDist 1 } Steven Waldbusser Expires Nov 1, 1995 [Page 18] Internet Draft Remote Network Monitoring MIB May 1, 1995 protocolDistControlEntry OBJECT-TYPE SYNTAX ProtocolDistControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Controls the setup of protocol type distribution statistics tables." INDEX { protocolDistControlIndex } ::= { protocolDistControlTable 1 } ProtocolDistControlEntry ::= SEQUENCE { protocolDistControlIndex Integer32 (1..65535), protocolDistControlDataSource OBJECT IDENTIFIER, protocolDistControlDroppedFrames Counter32, protocolDistControlOwner OwnerString, protocolDistControlStatus RowStatus } protocolDistControlIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this protocolDistControlEntry." ::= { protocolDistControlEntry 1 } protocolDistControlDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the source of the data that this protocolDistControlEntry entry is configured to analyze. This source can be any interface on this device. 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 protocolDistControlStatus object is equal to active(1)." ::= { protocolDistControlEntry 2 } protocolDistControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Steven Waldbusser Expires Nov 1, 1995 [Page 19] Internet Draft Remote Network Monitoring MIB May 1, 1995 STATUS current DESCRIPTION "The total number of frames which were received by the probe and therefore not accounted for in the *StatsDropEvents, but for which the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. Note that this number is the exact number of frames dropped; it must be set as accurately as possible by the probe." ::= { protocolDistControlEntry 3 } protocolDistControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The owner of this entry." ::= { protocolDistControlEntry 4 } protocolDistControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this row. An entry is not qualified for activation until instances of all columns of its protocolDistControlEntry row have an appropriate value. In particular, one or more management set operations are required to configure the entry: a value must be written to the protocolDistControlDataSource object. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the protocolDistControlStatus column is `notReady'. For those columnar objects which permit write-access (after their initial creation), their value in an existing conceptual row can be changed irrespective of the value of protocolDistControlStatus for that row." ::= { protocolDistControlEntry 5 } Steven Waldbusser Expires Nov 1, 1995 [Page 20] Internet Draft Remote Network Monitoring MIB May 1, 1995 -- per interface protocol distribution statistics table protocolDistStatsTable OBJECT-TYPE SYNTAX SEQUENCE OF ProtocolDistStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry is made in this table for every entry in the protocolDirTable. Counters are updated in this table for every protocol type that is encountered when parsing a packet." ::= { protocolDist 2 } protocolDistStatsEntry OBJECT-TYPE SYNTAX ProtocolDistStatsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry is made in this table for every entry in the protocolDirTable. Counters are updated in this table for every protocol type that is encountered when parsing a packet. The index is composed of the protocolDistControlIndex of the associated protocolDistControlEntry and the protocolDirID of the associated protocol that this entry represents." INDEX { protocolDistControlIndex, protocolDirID } ::= { protocolDistStatsTable 1 } ProtocolDistStatsEntry ::= SEQUENCE { protocolDistStatsPkts Counter32, protocolDistStatsOctets Counter32 } protocolDistStatsPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets received for this protocol." ::= { protocolDistStatsEntry 1 } protocolDistStatsOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only Steven Waldbusser Expires Nov 1, 1995 [Page 21] Internet Draft Remote Network Monitoring MIB May 1, 1995 STATUS current DESCRIPTION "The number of octets received for this protocol." ::= { protocolDistStatsEntry 2 } Steven Waldbusser Expires Nov 1, 1995 [Page 22] Internet Draft Remote Network Monitoring MIB May 1, 1995 -- -- Address Map Group (addressMap) -- -- network layer address map table -- addressMapControlTable -- addressMapTable -- addressMapControlTable OBJECT-TYPE SYNTAX SEQUENCE OF AddressMapControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table to control the collection of network layer address to physical address to interface mappings. This is not like the typical RMON controlTable/dataTable in which each entry creates its own data table. Each entry in this table enables the discovery of addresses on a new interface and the placement of address mappings into the central addressMapTable." ::= { addressMap 1 } addressMapControlEntry OBJECT-TYPE SYNTAX AddressMapControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { addressMapControlIndex } ::= { addressMapControlTable 1 } AddressMapControlEntry ::= SEQUENCE { addressMapControlIndex Integer32 (1..65535), addressMapControlDataSource Integer32, addressMapDroppedFrames Counter32, addressMapControlOwner OwnerString, addressMapControlStatus RowStatus } addressMapControlIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for this entry in the addressMapControlTable." Steven Waldbusser Expires Nov 1, 1995 [Page 23] Internet Draft Remote Network Monitoring MIB May 1, 1995 ::= { addressMapControlEntry 1 } addressMapControlDataSource OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-create STATUS current DESCRIPTION "This object identifies the source of the data that this addressMapControlEntry entry is configured to analyze. This source can be any interface on this device. Note that due to a relaxation of rules in the interfaces MIB [XXX], repeater ports may now be represented as interfaces and can thus be monitored with this mechanism. 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." ::= { addressMapControlEntry 2 } addressMapControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames which were received by the probe and therefore not accounted for in the *StatsDropEvents, but for which the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. Note that this number is the exact number of frames dropped; it must be set as accurately as possible by the probe." ::= { addressMapControlEntry 3 } addressMapControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The owner of this addressMap control entry." ::= { addressMapControlEntry 4 } Steven Waldbusser Expires Nov 1, 1995 [Page 24] Internet Draft Remote Network Monitoring MIB May 1, 1995 addressMapControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this addressMap control entry. An entry is not qualified for activation until instances of all columns of its addressMapControlEntry row have an appropriate value. In particular, one or more management set operations are required to configure the entry: a value must be written to the addressMapControlDataSource object. Until instances of all corresponding columns are appropriately configured, the value of the corresponding instance of the addressMapControlStatus column is `notReady'. For those columnar objects which permit write-access (after their initial creation), their value in an existing conceptual row can be changed irrespective of the value of addressMapControlStatus for that row." ::= { addressMapControlEntry 5 } addressMapTable OBJECT-TYPE SYNTAX SEQUENCE OF AddressMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of network layer address to physical address to interface mappings." ::= { addressMap 2 } addressMapEntry OBJECT-TYPE SYNTAX AddressMapEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of network layer address to physical address to interface mappings. The probe will only populate this table for network layer protocols in the protocol directory table, but must do so for Steven Waldbusser Expires Nov 1, 1995 [Page 25] Internet Draft Remote Network Monitoring MIB May 1, 1995 all network layer protocols (issue: what is a network layer protocol anyway? IP in IP?)" INDEX { protocolDirIndex, addressMapNetworkAddress } ::= { addressMapTable 1 } AddressMapEntry ::= SEQUENCE { addressMapNetworkAddress OCTET STRING, addressMapPhysicalAddress OCTET STRING, addressMapIfIndex Integer32, addressMapLastChange TimeTicks } addressMapNetworkAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this relation. This is represented as an octet string with specific semantics and length as identified by the protocolDirIndex component. For example, if the protocolDirIndex indicates an encapsulation of ip, this object is encoded as the 4 octets of the ip address, in network byte order. " ::= { addressMapEntry 1 } addressMapPhysicalAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The last physical address on which the associated network address was seen." ::= { addressMapEntry 2 } addressMapIfIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The last interface on which the associated network address was seen. Steven Waldbusser Expires Nov 1, 1995 [Page 26] Internet Draft Remote Network Monitoring MIB May 1, 1995 Note that due to a relaxation of rules in the interfaces MIB [XXX], repeater ports may now be represented as interfaces and can thus be monitored with this mechanism." ::= { addressMapEntry 3 } addressMapLastChange OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this entry was created or the values of the physical address or ifIndex changed." ::= { addressMapEntry 4 } nlhostControlTable OBJECT-TYPE SYNTAX SEQUENCE OF NlHostControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of network layer host table control entries. These entries will enable the collection of a host table indexed by network addresses." ::= { nlHost 1 } nlHostControlEntry OBJECT-TYPE SYNTAX NlHostControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of parameters that set up the discovery of hosts on a particular interface and the collection of statistics about these hosts." INDEX { nlHostControlIndex } ::= { nlHostControlTable 1 } NlHostControlEntry ::= SEQUENCE { nlHostControlIndex Integer32 (1..65535), nlHostControlDataSource OBJECT IDENTIFIER, nlHostControlDroppedFrames Counter32, nlHostControlTableSize Integer32, nlHostControlLastDeleteTime TimeTicks, nlHostControlOwner OwnerString, nlHostControlStatus Integer32 Steven Waldbusser Expires Nov 1, 1995 [Page 27] Internet Draft Remote Network Monitoring MIB May 1, 1995 } nlHostControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the nlHostControl table. Each such entry defines a function that discovers hosts on a particular interface and places statistics about them in the nlHostTable on behalf of this nlHostControlEntry." ::= { nlHostControlEntry 1 } nlHostControlDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies the source of the data for this instance of the host function. This source can be any 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 nlHostControlStatus object is equal to valid(1)." ::= { nlHostControlEntry 2 } nlHostControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames which were received by the probe and therefore not accounted for in the *StatsDropEvents, but for which the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe Steven Waldbusser Expires Nov 1, 1995 [Page 28] Internet Draft Remote Network Monitoring MIB May 1, 1995 is out of some resources and decides to shed load from this collection. Note that this number is the exact number of frames dropped; it must be set as accurately as possible by the probe." ::= { nlHostControlEntry 3 } nlHostControlTableSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of nlHostEntries in the nlHostTable associated with this nlHostControlEntry." ::= { nlHostControlEntry 4 } nlHostControlLastDeleteTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last entry was deleted from the portion of the nlHostTable associated with this nlHostControlEntry. If no deletions have occurred, this value shall be zero." ::= { nlHostControlEntry 5 } nlHostControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-write STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { nlHostControlEntry 6 } nlHostControlStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-write STATUS current DESCRIPTION "The status of this nlHostControl entry. If this object is not equal to valid(1), all Steven Waldbusser Expires Nov 1, 1995 [Page 29] Internet Draft Remote Network Monitoring MIB May 1, 1995 associated entries in the nlHostTable, shall be deleted by the agent." ::= { nlHostControlEntry 7 } nlHostTable OBJECT-TYPE SYNTAX SEQUENCE OF NlHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of nlHost entries. Each such entry defines statistics for packets from and to a particular network address." ::= { nlHost 2 } nlHostEntry OBJECT-TYPE SYNTAX NlHostEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics for a particular host that has been discovered on an interface of this device. The probe will only populate this table for network layer protocols in the protocol directory table, but must do so for all network layer protocols (issue: what is a network layer protocol anyway? IP in IP?)" INDEX { nlHostControlIndex, protocolDirIndex, nlHostAddress } ::= { nlHostTable 1 } NlHostEntry ::= SEQUENCE { nlHostAddress OCTET STRING, nlHostInPkts Counter32, nlHostOutPkts Counter32, nlHostInOctets Counter32, nlHostOutOctets Counter32, nlHostOutErrors Counter32, nlHostOutBroadcastPkts Counter32, nlHostOutMulticastPkts Counter32 } nlHostAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION Steven Waldbusser Expires Nov 1, 1995 [Page 30] Internet Draft Remote Network Monitoring MIB May 1, 1995 "The network address for this nlHostEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirIndex component. For example, if the protocolDirIndex indicates an encapsulation of ip, this object is encoded as the 4 octets of the ip address, in network byte order. " ::= { nlHostEntry 1 } nlHostInPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets without errors transmitted to this address since it was added to the nlHostTable." ::= { nlHostEntry 2 } nlHostOutPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets including errors transmitted by this address since it was added to the nlHostTable." ::= { nlHostEntry 3 } nlHostInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets transmitted to this address since it was added to the nlHostTable (excluding framing bits but including FCS octets), except for those octets in packets that contained errors." ::= { nlHostEntry 4 } nlHostOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION Steven Waldbusser Expires Nov 1, 1995 [Page 31] Internet Draft Remote Network Monitoring MIB May 1, 1995 "The number of octets transmitted by this address since it was added to the nlHostTable (excluding framing bits but including FCS octets), including those octets in packets that contained errors." ::= { nlHostEntry 5 } nlHostOutErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of error packets transmitted by this address since this host was added to the nlHostTable." ::= { nlHostEntry 6 } nlHostOutBroadcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets transmitted by this address that were directed to the broadcast address since this host was added to the nlHostTable." ::= { nlHostEntry 7 } nlHostOutMulticastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of good packets transmitted by this address that were directed to a multicast address since this host was added to the nlHostTable. Note that this number does not include packets directed to the broadcast address." ::= { nlHostEntry 8 } nlMatrixControlTable OBJECT-TYPE SYNTAX SEQUENCE OF NlMatrixControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of information entries for the traffic matrix on each interface." ::= { nlMatrix 1 } Steven Waldbusser Expires Nov 1, 1995 [Page 32] Internet Draft Remote Network Monitoring MIB May 1, 1995 nlMatrixControlEntry OBJECT-TYPE SYNTAX NlMatrixControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a traffic matrix on a particular interface." INDEX { nlMatrixControlIndex } ::= { nlMatrixControlTable 1 } NlMatrixControlEntry ::= SEQUENCE { nlMatrixControlIndex Integer32 (1..65535), nlMatrixControlDataSource OBJECT IDENTIFIER, nlMatrixControlDroppedFrames Counter32, nlMatrixControlTableSize Integer32, nlMatrixControlLastDeleteTime TimeTicks, nlMatrixControlOwner OwnerString, nlMatrixControlStatus Integer32 } nlMatrixControlIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "An index that uniquely identifies an entry in the nlMatrixControl table. Each such entry defines a function that discovers conversations on a particular interface and places statistics about them in the nlMatrixSDTable and the nlMatrixDSTable on behalf of this nlMatrixControlEntry." ::= { nlMatrixControlEntry 1 } nlMatrixControlDataSource OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "This object identifies the source of the data from which this entry creates a traffic matrix. This source can be any 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 Steven Waldbusser Expires Nov 1, 1995 [Page 33] Internet Draft Remote Network Monitoring MIB May 1, 1995 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 nlMatrixControlStatus object is equal to valid(1)." ::= { nlMatrixControlEntry 2 } nlMatrixControlDroppedFrames OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of frames which were received by the probe and therefore not accounted for in the *StatsDropEvents, but for which the probe chose not to count for this entry for whatever reason. Most often, this event occurs when the probe is out of some resources and decides to shed load from this collection. Note that this number is the exact number of frames dropped; it must be set as accurately as possible by the probe." ::= { nlMatrixControlEntry 3 } nlMatrixControlTableSize OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of nlMatrixSDEntries in the nlMatrixSDTable for this interface. This must also be the value of the number of entries in the nlMatrixDSTable for this interface." ::= { nlMatrixControlEntry 4 } nlMatrixControlLastDeleteTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last entry was deleted from the portion of the nlMatrixSDTable Steven Waldbusser Expires Nov 1, 1995 [Page 34] Internet Draft Remote Network Monitoring MIB May 1, 1995 or nlMatrixDSTable associated with this nlMatrixControlEntry. If no deletions have occurred, this value shall be zero." ::= { nlMatrixControlEntry 5 } nlMatrixControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-write STATUS current DESCRIPTION "The entity that configured this entry and is therefore using the resources assigned to it." ::= { nlMatrixControlEntry 6 } nlMatrixControlStatus OBJECT-TYPE SYNTAX EntryStatus MAX-ACCESS read-write STATUS current DESCRIPTION "The status of this nlMatrixControl entry. If this object is not equal to valid(1), all associated entries in the nlMatrixSDTable and the nlMatrixDSTable shall be deleted by the agent." ::= { nlMatrixControlEntry 7 } nlMatrixSDTable OBJECT-TYPE SYNTAX SEQUENCE OF NlMatrixSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of traffic nlMatrix entries indexed by source and destination network-level address." ::= { nlMatrix 2 } nlMatrixSDEntry OBJECT-TYPE SYNTAX NlMatrixSDEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics for communications between two addresses on a particular interface. The probe will only populate this table for network layer Steven Waldbusser Expires Nov 1, 1995 [Page 35] Internet Draft Remote Network Monitoring MIB May 1, 1995 protocols in the protocol directory table, but must do so for all network layer protocols (issue: what is a network layer protocol anyway? IP in IP?)" INDEX { nlMatrixSDIndex, protocolDirIndex, nlMatrixSDSourceAddress, nlMatrixSDDestAddress } ::= { nlMatrixSDTable 1 } NlMatrixSDEntry ::= SEQUENCE { nlMatrixSDAddressType Integer32, nlMatrixSDSourceAddress OCTET STRING, nlMatrixSDDestAddress OCTET STRING, nlMatrixSDIndex Integer32 (1..65535), nlMatrixSDPkts Counter32, nlMatrixSDOctets Counter32, nlMatrixSDErrors Counter32 } nlMatrixSDSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The type of network source address for this nlMatrixSDEntry. If the network address type is ip(1), this object is encoded as the 4 octets of the ip address, in network byte order. If the network address type is ..." ::= { nlMatrixSDEntry 1 } nlMatrixSDDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The type of network destination address for this nlMatrixSDEntry. If the network address type is ip(1), this object is encoded as the 4 octets of the ip address, in network byte order. If the network address type is ..." ::= { nlMatrixSDEntry 2 } nlMatrixSDIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) Steven Waldbusser Expires Nov 1, 1995 [Page 36] Internet Draft Remote Network Monitoring MIB May 1, 1995 MAX-ACCESS read-only STATUS current DESCRIPTION "The set of collected matrix statistics of which this entry is a part. The set of matrix statistics identified by a particular value of this index is associated with the same nlMatrixControlEntry as identified by the same value of nlMatrixControlIndex." ::= { nlMatrixSDEntry 3 } nlMatrixSDPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets transmitted from the source address to the destination address (this number includes error packets)." ::= { nlMatrixSDEntry 4 } nlMatrixSDOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets (excluding framing bits but including FCS octets) contained in all packets transmitted from the source address to the destination address." ::= { nlMatrixSDEntry 5 } nlMatrixSDErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of error packets transmitted from the source address to the destination address." ::= { nlMatrixSDEntry 6 } -- Traffic matrix tables from destination to source nlMatrixDSTable OBJECT-TYPE SYNTAX SEQUENCE OF NlMatrixDSEntry Steven Waldbusser Expires Nov 1, 1995 [Page 37] Internet Draft Remote Network Monitoring MIB May 1, 1995 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of traffic matrix entries indexed by destination and source network-level address." ::= { nlMatrix 3 } nlMatrixDSEntry OBJECT-TYPE SYNTAX NlMatrixDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A collection of statistics for communications between two address on a particular interface. The probe will only populate this table for network layer protocols in the protocol directory table, but must do so for all network layer protocols (issue: what is a network layer protocol anyway? IP in IP?)" INDEX { nlMatrixDSIndex, protocolDirIndex, nlMatrixDSDestAddress, nlMatrixDSSourceAddress } ::= { nlMatrixDSTable 1 } NlMatrixDSEntry ::= SEQUENCE { nlMatrixDSAddressType Integer32, nlMatrixDSSourceAddress OCTET STRING, nlMatrixDSDestAddress OCTET STRING, nlMatrixDSIndex Integer32 (1..65535), nlMatrixDSPkts Counter32, nlMatrixDSOctets Counter32, nlMatrixDSErrors Counter32 } nlMatrixDSSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The type of network source address for this nlMatrixDSEntry. If the network address type is ip(1), this object is encoded as the 4 octets of the ip address, in network byte order. If the network address type is ..." ::= { nlMatrixDSEntry 1 } Steven Waldbusser Expires Nov 1, 1995 [Page 38] Internet Draft Remote Network Monitoring MIB May 1, 1995 nlMatrixDSDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The type of network destination address for this nlMatrixDSEntry. If the network address type is ip(1), this object is encoded as the 4 octets of the ip address, in network byte order. If the network address type is ..." ::= { nlMatrixDSEntry 2 } nlMatrixDSIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The set of collected matrix statistics of which this entry is a part. The set of matrix statistics identified by a particular value of this index is associated with the same nlMatrixControlEntry as identified by the same value of nlMatrixControlIndex." ::= { nlMatrixDSEntry 3 } nlMatrixDSPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets transmitted from the source address to the destination address (this number includes error packets)." ::= { nlMatrixDSEntry 4 } nlMatrixDSOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets (excluding framing bits but including FCS octets) contained in all packets transmitted from the source address to the destination address." ::= { nlMatrixDSEntry 5 } Steven Waldbusser Expires Nov 1, 1995 [Page 39] Internet Draft Remote Network Monitoring MIB May 1, 1995 nlMatrixDSErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of error packets transmitted from the source address to the destination address." ::= { nlMatrixDSEntry 6 } END Steven Waldbusser Expires Nov 1, 1995 [Page 40] Internet Draft Remote Network Monitoring MIB May 1, 1995 8. Acknowledgments This document was produced by the IETF Remote Network Monitoring Working Group. Steven Waldbusser Expires Nov 1, 1995 [Page 41] Internet Draft Remote Network Monitoring MIB May 1, 1995 9. References [1] V. Cerf, IAB Recommendations for the Development of Internet Network Management Standards. Internet Working Group Request for Comments 1052. Network Information Center, SRI International, Menlo Park, California, (April, 1988). [2] V. Cerf, Report of the Second Ad Hoc Network Management Review Group, Internet Working Group Request for Comments 1109. Network Information Center, SRI International, Menlo Park, California, (August, 1989). [3] M.T. Rose and K. McCloghrie, Structure and Identification of Management Information for TCP/IP-based internets, Internet Working Group Request for Comments 1155. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [4] K. McCloghrie and M.T. Rose, Management Information Base for Network Management of TCP/IP-based internets: MIB-II, Internet Working Group Request for Comments 1213 Network Information Center, SRI International, Menlo Park, California, (March, 1991). [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, Simple Network Management Protocol, Internet Working Group Request for Comments 1157. Network Information Center, SRI International, Menlo Park, California, (May, 1990). [6] K. McCloghrie and F. Kastenholz, Evolution of the Interfaces Group of MIB-II, Internet Working Group Request for Comments 1573. Network Information Center, SRI International, Menlo Park, California, (Jan, 1994). [7] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [8] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Steven Waldbusser Expires Nov 1, 1995 [Page 42] Internet Draft Remote Network Monitoring MIB May 1, 1995 Organization for Standardization. International Standard 8825, (December, 1987). [9] M.T. Rose, K. McCloghrie, Editors, Concise MIB Definitions, Internet Working Group Request for Comments 1212. Network Information Center, SRI International, Menlo Park, California, (March, 1991). [10] M.T. Rose, Editor, A Convention for Defining Traps for use with the SNMP, Internet Working Group Request for Comments 1215. Network Information Center, SRI International, Menlo Park, California, (March, 1991). Steven Waldbusser Expires Nov 1, 1995 [Page 43] Internet Draft Remote Network Monitoring MIB May 1, 1995 Table of Contents 1 Status of this Memo ................................... 1 2 Abstract .............................................. 1 3 The Network Management Framework ...................... 3 4 Overview .............................................. 4 4.1 Remote Network Management Goals ..................... 4 4.2 Structure of MIB .................................... 6 5 Control of Remote Network Monitoring Devices .......... 7 5.1 Resource Sharing Among Multiple Management Sta- tions .............................................. 7 5.2 Row Addition Among Multiple Management Stations ..... 9 6 Conventions ........................................... 11 7 Definitions ........................................... 12 8 Acknowledgments ....................................... 41 9 References ............................................ 42 Steven Waldbusser Expires Nov 1, 1995 [Page 44]