Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4502

Remote Network Monitoring Management Information Base Version 2

Pages: 142
Draft Standard
Obsoletes:  2021
Updates:  3273
Part 1 of 5 – Pages 1 to 11
None   None   Next

Top   ToC   RFC4502 - Page 1
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).


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.
Top   ToC   RFC4502 - Page 2

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 ..................................140

1. 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
Top   ToC   RFC4502 - Page 3
   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.
Top   ToC   RFC4502 - Page 4
   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
Top   ToC   RFC4502 - Page 5
      - 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

      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.
Top   ToC   RFC4502 - Page 6
         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.
Top   ToC   RFC4502 - Page 7

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
Top   ToC   RFC4502 - Page 8
   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 active.
Top   ToC   RFC4502 - Page 9
   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.
Top   ToC   RFC4502 - Page 10
   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.
Top   ToC   RFC4502 - Page 11
   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 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)

Next Section