Network Working Group S. Waldbusser
Request for Comments: 4502 May 2006
Category: Standards Track
Remote Network Monitoring
Management Information Base
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2006).
This document 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.
This document obsoletes RFC 2021, updates RFC 3273, and contains a
new version of the RMON2-MIB module.
Table of Contents
1. The Internet-Standard Management Framework ......................22. Overview ........................................................22.1. Remote Network Management Goals ............................32.2. Structure of MIB ...........................................43. Control of Remote Network Monitoring Devices ....................63.1. Resource Sharing among Multiple Management Stations ........73.2. Row Addition among Multiple Management Stations ............84. Conventions .....................................................95. RMON 2 Conventions .............................................105.1. Usage of the Term Application Level .......................105.2. Protocol Directory and Limited Extensibility ..............105.3. Errors in Packets .........................................116. Definitions ....................................................117. Security Considerations .......................................1308. Appendix - TimeFilter Implementation Notes ....................1329. Changes since RFC 2021 ........................................13810. Acknowledgements .............................................14011. References ...................................................14011.1. Normative References ....................................14011.2. Informative References ..................................1401. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
The RMON2 MIB defines objects that provide RMON analysis up to the
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, which is often geographically remote.
The objects defined in this document are intended to serve 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. The management application should handle
2.1. Remote Network Management Goals
o Offline Operation
There are times when a management station will not be in constant
contact with its remote monitoring devices. This sometimes occurs
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 the 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 Proactive Monitoring
Given the resources available on the monitor, it is potentially
helpful for it to run diagnostics continuously 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 of the cause of
o Problem Detection and Reporting
The monitor can be configured to recognize conditions, most
notably error conditions, and to check for them continuously.
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 order to provide
disaster recovery. Because environments with multiple management
stations are common, the remote network monitoring device has to
deal with more than one management station, potentially using its
2.2. Structure of MIB
The objects are arranged into the following groups:
- protocol directory
- protocol distribution
- address mapping
- network layer host
- network layer matrix
- application layer host
- application layer matrix
- user history
- probe configuration
These groups are the basic units 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
Implementations of this MIB must also implement the IF-MIB [RFC2863].
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.
This document also contains AUGMENTing tables to extend some tables
defined in the RMON MIB [RFC2819]. These extensions include the
1) Adding the DroppedFrames and LastCreateTime conventions to each
table defined in the RMON MIB.
2) Augmenting the RMON filter table with a mechanism that allows
filtering based on an offset from the beginning of a particular
protocol, even if the protocol headers are of variable length.
3) Augmenting the RMON filter and capture status bits with
additional bits for WAN media and generic media. These bits
are defined here as follows:
6 For WAN media, this bit is set for packets
coming from one direction and cleared for
packets coming from the other direction.
It is an implementation-specific matter
as to which bit is assigned to which
direction, but it must be consistent for
all packets received by the agent. If
the agent knows which end of the link is
"local" and which end is "network", the bit
should be set for packets from the "local"
side and should be cleared for packets from
the "network" side.
7 For any media, this bit is set for any packet
with a physical layer error. This bit may be
set in addition to other media-specific bits
that denote the same condition.
8 For any media, this bit is set for any packet
that is too short for the media. This bit may
be set in addition to other media-specific
bits that denote the same condition.
9 For any media, this bit is set for any packet
that is too long for the media. This bit may
be set in addition to other media-specific bits
that denote the same condition.
These enhancements are implemented by RMON-2 probes that also
implement RMON and do not add any requirements to probes that are
compliant to just RMON.
3. 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 that parameters 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 not active. Thus, the method for modifying
these parameters is to deactivate the entry, perform the SNMP Set
operations to modify the entry, and then reactivate the entry.
Deleting the control entry causes the deletion of any associated data
entries, which 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.
3.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 use resources simultaneously
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 that others may use them.
The OwnerString 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
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 unilaterally to 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 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 they
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 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 first to 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.
Note 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 reassign resources from a row
that is in use by one user than those 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
3.2. Row Addition among Multiple Management Stations
The addition of new rows is achieved using the RowStatus Textual
Convention [RFC2579]. 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 the 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 row status object to
If the latter option 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 option, 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 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.
In the RMON MIB [RFC2819], the EntryStatus textual convention was
introduced to provide this mutual exclusion function. Since then,
this function was added to the SNMP framework as the RowStatus
textual convention. The RowStatus textual convention is used for the
definition of all new tables.
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 while looking for the first unused index. Because index values
may be any valid value in the range and 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.
The following conventions are used throughout the RMON MIB and its
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 and 1518 octets long. They
follow the form defined in IEEE 802.3 section 3.2.all.
Bad packets are packets that have proper framing and are therefore
recognized as packets, but that 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 they are
either shorter than 64 octets or longer than 1518 octets.
5. RMON 2 Conventions
The following practices and conventions are introduced in the RMON 2
5.1. Usage of the Term "Application Level"
There are many cases in this MIB where the term "Application Level"
is used to describe a class of protocols or a capability. This does
not typically mean a protocol that is an OSI Layer 7 protocol.
Rather, it is used to identify a class of protocols that is not
limited to MAC-layer and network-layer protocols, but can also
include transport, session, presentation, and application-layer
5.2. Protocol Directory and Limited Extensibility
Every RMON 2 implementation will have the capability to parse certain
types of packets and identify their protocol type at multiple levels.
The protocol directory presents an inventory of protocol types the
probe is capable of monitoring and allows the addition, deletion, and
configuration of protocol types in this list.
One concept deserves special attention: the "limited extensibility"
of the protocol directory table. Using the RMON 2 model, protocols
are detected by static software that has been written at
implementation time. Therefore, as a matter of configuration, an
implementation cannot suddenly learn how to parse new packet types.
However, an implementation may be written such that the software
knows where the demultiplexing field is for a particular protocol,
and it can be written in such a way that the decoding of the next
layer up is table driven. This works when the code has been written
to accommodate it and can be extended no more than one level higher.
This extensibility is called "limited extensibility" to highlight
these limitations. However, this can be a very useful tool.
For example, suppose that an implementation has C code that
understands how to decode IP packets on any of several ethernet
encapsulations, and also knows how to interpret the IP protocol field
to recognize UDP packets and how to decode the UDP port number
fields. That implementation may be table driven so that among the
many different UDP port numbers possible, it is configured to
recognize 161 as SNMP, port 53 as DNS, and port 69 as TFTP. The
limited extensibility of the protocol directory table would allow an
SNMP operation to create an entry that would create an additional
table mapping for UDP that would recognize UDP port 123 as NTP and
begin counting such packets.
This limited extensibility is an option that an implementation can
choose to allow or disallow for any protocol that has child
5.3. Errors in Packets
Packets with link-level errors are not counted anywhere in this MIB
because most variables in this MIB require the decoding of the
contents of the packet, which is meaningless if there is a link-level
Packets in which protocol errors are detected are counted for all
protocols below the layer in which the error was encountered. The
implication of this is that packets in which errors are detected at
the network-layer are not counted anywhere in this MIB, while packets
with errors detected at the transport layer may have network-layer