RFC 4502
Remote Network Monitoring Management Information Base Version 2
Network Working Group S. Waldbusser Request for Comments: 4502 May 2006 Obsoletes: 2021 Updates: 3273 Category: Standards Track Remote Network Monitoring Management Information Base Version 2 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 Notice Copyright (C) The Internet Society (2006).Abstract
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 ......................2 2. Overview ........................................................2 2.1. Remote Network Management Goals ............................3 2.2. Structure of MIB ...........................................4 3. Control of Remote Network Monitoring Devices ....................6 3.1. Resource Sharing among Multiple Management Stations ........7 3.2. Row Addition among Multiple Management Stations ............8 4. Conventions .....................................................9 5. RMON 2 Conventions .............................................10 5.1. Usage of the Term Application Level .......................10 5.2. Protocol Directory and Limited Extensibility ..............10 5.3. Errors in Packets .........................................11 6. Definitions ....................................................11 7. Security Considerations .......................................130 8. Appendix - TimeFilter Implementation Notes ....................132 9. Changes since RFC 2021 ........................................138 10. Acknowledgements .............................................140 11. References ...................................................140 11.1. Normative References ....................................140 11.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 [RFC2580].2. Overview
The RMON2 MIB defines objects that provide RMON analysis up to the application layer. 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 these functions.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 the problem.
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
resources concurrently.
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
the nlMatrixDSTable.
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
following:
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:
Bit Definition
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 the following: 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 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 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 discretion.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 active.
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.4. 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 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 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
MIB.
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
protocols.
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 protocols.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 error. 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 statistics counted.
(page 11 continued on part 2)
