tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4502

Draft STD
Pages: 142
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: RMONMIB

Remote Network Monitoring Management Information Base Version 2

Part 1 of 5, p. 1 to 11
None       Next RFC Part

Obsoletes:    2021
Updates:    3273

Top       ToC       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       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

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

Top      ToC       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       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

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.

Top      ToC       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

   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 RFC Part