2.4.12 Remote Network Monitoring (rmonmib)

Last Modifield: 08/02/2002

Chair(s):

Operations and Management Area Director(s):

Operations and Management Area Advisor:

Technical Advisor(s):

Mailing Lists:

Description of Working Group:

The RMON MIB Working Group is chartered to define a set of managed objects for remote monitoring of networks. These objects will be the minimum necessary to provide the ability to monitor multiple network layers of traffic in remote networks; providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards.

The following list of features for this RMON has been previously discussed in relation to existing RMON functionality and is included to focus these RMON activities. It is recognized that other issues may be considered and that certain of the following issues may not be part of the final specification(s):

1. Application Performance Measurement

Monitoring support for the measurement and characterization of network application protocols, striving to measure an application user's experience as closely as possible. The RMON-2 MIB (RFC 2021) contains a protocol directory that will be used to identify applications for monitoring purposes.

While it is important to measure the performance of computing and network resources, these measurements don't give an insight to the actual service delivered to end-users. This end-user experience is best measured by the response-time and availability of application transactions because users interact directly with applications. This working group will create extensions to the RMON-2 MIB that will allow Application Performance Measurements to be retrieved with SNMP, no matter which technology is used to perform the measurements.

The goal of the working group is to provide a common framework and set of MIB objects, within the current RMON framework, for the identification and characterization of application responsiveness and availability, and the reporting of test results produced by such mechanisms. Common metrics and derived metrics will be characterized and reported in a manner consistent with the IP Performance Metrics Framework (RFC 2330).

It is an explicit non-goal of the working group to select one or more mechanisms as the preferred or standard RMON application performance measurement mechanism. However, it is possible that one or more standard mechanisms will be developed in the future, after significant implementation experience has been gained by the working group.

2. Differentiated Services Statistics Collection

Monitoring support for Differentiated Services (DS) statistics collection, for the purpose of DS codepoint usage analysis and possibly other statistics related to DS deployment and performance tuning.

3. Interface TopN Reporting

It is often too slow or difficult to determine the busiest ports in devices such as high port-density switches, using existing RMON mechanisms. New monitoring support is needed for quickly determining the most congested (highest utilized) physical ports and links in an RMON-capable device with multiple interfaces.

4. TR-RMON MIB Advancement

The Token Ring RMON MIB (RFC 1513) is ready for standards track advancement. An interoperability and deployment survey has already been completed, but the MIB must be updated in SMIv2 format before it can be advanced on the standards track.

5. Transport Performance Measurement

There is a need for standardized means to collect and report selectable performance metrics and statistics derived from the monitoring of network packets and transport protocol states. The monitoring covers both passive and active traffic generation sources. Monitoring support for the these measurements can provide a drill-down capability to provide insight into the performance of the lower-level transactions which comprise the overall performance of a network application.

The goal of the working group is to provide a common framework and set of MIB objects, within the current RMON framework, for the identification and characterization of transaction-level performance, and the reporting of test results produced by such mechanisms. Common metrics and derived statistics will be characterized and reported in a manner consistent with the IP Performance Metrics Framework (RFC 2330).

6. SMON MIB Advancement

The SMON MIB (RFC 2613) is ready for standards track advancement. An interoperability and deployment survey will be completed, and submitted to the IESG. It is possible that minor enhancements and corrections to RFC 2613 will be made, based on the survey findings and working group input.

7. RMON-2 MIB Advancement

The RMON-2 MIB (RFC 2021) is ready for standards track advancement. An interoperability and deployment survey will be completed, and submitted to the IESG. It is possible that minor enhancements and corrections to RFC 2021 will be made, based on the survey findings and working group input.

8. RMON PI Reference Advancement

The RMON Protocol Identifiers Reference (RFC 2895) is ready for standards track advancement. An interoperability and deployment survey will be completed, and submitted to the IESG. It is possible that minor enhancements and corrections to RFC 2895 will be made, based on the survey findings and working group input.

9. Synthetic Sources for Performance Monitoring

Mechanisms are needed for the remote control of synthetic packet sources and destinations, for the purpose of enhancing remote performance monitoring capabilities within IP networks and services. These mechanisms must utilize the RMON protocol directory for protocol encapsulation identification. Any interactions with the RMON Framework or dependencies on specific RMON MIB objects (if any) will be specified as well.

10. RMON Framework

Documentation is needed which clarifies the remote network monitoring framework, and describes the inter-relationships and dependencies between the various RMON MIB modules. A conceptual model is needed to help administrators and developers better understand data sources, the protocol directory, and the existing RMON statistical collections. Undocumented 'RMON folklore', as well as the limitations and appropriate application of various implementation techniques will also be addressed.

11. Real-time Application QoS Monitoring MIB

There is a need to extend the RMON framework to monitor end devices such as IP Phones, pagers, Instant Message Clients, Cell Phones, and PDA devices. An end-to-end user experience of the quality of service (QoS) and performance for such an application is a combination of device performance and transport network performance. Monitoring should be performed at the application layer that reflects a specific end user experience on a particular IP end point, reflecting specific transport network performance

There is a need to extend the RMON framework to monitor end devices such as IP Phones, pagers, Instant Message Clients, Cell Phones, and PDA devices. An end-to-end user experience of the quality of service (QoS) and performance for such an application is a combination of device performance and transport network performance. Monitoring should be performed at the application layer that reflects a specific end user experience on a particular IP end point, reflecting specific transport network performance.

This working group will extend the RMON Framework to allow Real-time Application QoS information of these types of end devices to be retrieved with SNMP, independent of the technology used to perform the measurements.

The WG will define a common framework and set of MIB objects, within the current RMON framework, for the identification and characterization of application QoS parameters, and the reporting of the on-going measurement reports produced by these mechanisms. Common metrics and derived metrics will be characterized and reported in a manner consistent with the IP Performance Metrics Framework (RFC 2330).

The WG will also define a set of RAQMON Application level QoS PDUs to have common formats of reporting statistics between a RAQMON Data Source and a RAQMON Report Collector. These Common RAQMON PDUs will be transported over existing protocols, such as RTCP or SNMP.

The measurement methodology is out of the scope of the RAQMON work and will be in conformance with the IPPM WG recommendations, and also may take into account considerations from application-specific (IM and telephony) WGs as needed. This WG will consider the cases for transport of RAQMON PDUs, including how RTCP might be used and still meet security/privacy goals.

Security aspects related to RAQMON reports will be cognizant of privacy and anonymity issues while being responsive to the needs of measurement applications.

Goals and Milestones:

Internet-Drafts:

Request For Comments:

OPS Area
RMONMIB WG Meeting Minutes
IETF #55
November 18, 2002
Minutes by Andy Bierman

Review Material
---------------

(A) draft-ietf-rmonmib-framework-02.txt
(B) 
draft-siddiqui-rmonmib-raqmon-framework-00.txt
(C) 
draft-siddiqui-rmonmib-raqmon-pdu-00.txt
(D) 
draft-siddiqui-rmonmib-raqmon-mib-02.txt
(E) draft-bakke-dhc-snmp-trap-01.txt

Minutes
-------

1. RFC 2613 Advancement

The implementation report for the SMON MIB was presented and 
advancement of this MIB was discussed by the group.  All MIB objects in RFC 
2613 have been implemented by at least two independent development 
efforts.  The RMONMIB WG believes the requirements for advancement of the 
MIB in RFC 2613 to Draft Standard have been met.

Two minor issues did arise:

  1) smonDataSource values
     Not all possible values of the smonDataSource object have been 
implemented by at least two developers.  This is not considered a 
significant issue because each mode is specific to a different hardware 
platform environment, and different vendors used the values 
appropriate for their hardware platform(s).

  2) portCopy modes
     The portCopyTable can be populated in three different ways (using the 
same MIB objects).  The difference in each mode is related to 
associated rows in the portCopyTable.  For example, the 'N:1' mode 
implies there are at least two rows in the table with the same port copy 
destination.  Not all possible modes have been implemented by at least two 
developers. This is not considered a significant issue because all MIB 
objects in this table have been implemented in a consistent and 
interoperable manner by at least two developers.  The 'N:1' and 'N:M' 
modes are dependent on the capabilities of the hardware platform.

2. RFC 2074 Advancement

The implementation report for the RMON Protocol Identifiers was 
presented and advancement of this document was discussed by the group. RFC 
2074 defines the Protocol Identifier macro format and is used for the 
index structure of the RMON protocol directory defined in RFC 2021.  MIB 
walks of the protocolDirTable for multiple independent 
implementations indicate consistent representation of protocol 
encapsulations.  In addition, multiple independent software tools have been 
developed which parse the RMON protocol identifier macro. These tools are 
used to assist in the protocol decode engine development for an RMON-2 
agent.  The RMONMIB WG believes the requirements for advancement of the 
Protocol Identifier Macro specification in RFC 2074 to Draft Standard have 
been met.

At least two independent implementations of all RMON protocol 
identifier features exist, however there is one minor feature that was not 
fully verified by the implementation reports. Only one returned survey 
indicated that all protocol parameters were implemented.  These 
parameters identify protocol decoding capabilities that are 
considered to be beyond the core feature set of RMON-2 agents.

3. RFC 2021 Advancement

The implementation report for the RMON-2 MIB was presented and 
advancement of this MIB was discussed by the group.
The primary statistical object groups seem to be widely 
implemented.
There were some implementation issues raised, such as:
   - dropped frames counters not always correct due to limitations in the HW 
or device driver.
   - resource limitations constrain number of control entries that may be 
created and/or number of related protocol entries in the 
protocolDirTable.
   - flexible configuration of the protocol directory and complex 
protocol encapsulation representation makes agent implementation too 
complicated.

None of these issues are considered critical, but they do indicate that the 
RMON-2 design and functional requirements are too complicated in some 
areas.

There are several secondary statistical objects and configuration 
objects which are not widely implemented.  The lack of 
implementation experience for these objects indicates that they are not 
widely useful or applicable to current market requirements for RMON-2 
agent technology.

A significant design flaw was exposed in the process of collecting 
implementation reports.  The defined behavior of the TimeFilter textual 
convention (used in many statistical data tables) is quite 
sub-optimal for SNMP GetNext and GetBulk protocol operations.  
Basically, TimeFilter causes simple mibwalks to continue without end, and 
GetBulk response PDUs to contain lots of duplicate information.  As a 
result, many vendors have relaxed the specification for TimeFilter and 
automatically 'wrap' the lexinext retrieval of tables that include a 
TimeFilter index, such that duplicate entries are not returned.  There is no 
benefit whatsoever to the official behavior of the TimeFilter.

The RMONMIB WG has decided that an attempt should be made to fix the 
TimeFilter specification such that duplicate entries are not returned by the 
agent during lexinext retrieval of a table that uses a TimeFilter index.

Due to the numerous unimplemented MIB objects and the problem with tables 
using a TimeFilter index, the RMONMIB WG believes that RFC 2021 is not 
ready for advancement at this time.  The RMONMIB WG will attempt to fix the 
TimeFilter issues and cycle the RMON-2 MIB at Proposed Standard.

4. RMON Framework

The RMON Framework draft (A) was discussed by the group.  Some minor 
issues remain which should be resolved before a WG Last Call for this 
document can begin.

Some minor issues were resolved at the meeting:
  - an overview of the RAQMON work should be included
  - change the term 'standards' to 'documents'
  - tips on RMON usage should be done, but this should be in a separate 
document (perhaps an Applicability Statement)
  - the document title should change from 'RMON Framework' to 
something like 'An Introduction to the RMON MIB Modules'

There are some problems with the diagram showing the relationship 
between different RMON MIB modules, such as:
    - TPM not just at application layer
    - SSPM looks like RMON-1 is supported but that's not true

Some solutions were discussed, such as:
    - could change diagram or use table approach instead
    - could use 2 tables: metrics and bucketization

The criteria for classification was discussed. Perhaps the concept of 
bucketization really means "is the protocol directory supported?"  
Perhaps the classification reflect monitoring requirements, and can be 
divided into three groups:
   - L2 only: RMON-1
   - Protocol decode required: RMON-2, DSMON
   - Flow decode required: APM, TPM

The issues with this diagram will be resolved by the document authors.  A 
new version of the document addressing all known issues will be 
published soon.

5. RAQMON

The three RAQMON drafts (B,C,D) were discussed by the group, and some 
issues were raised.  These drafts will be reissues as WG baseline drafts 
soon.

The RAQMON Data Source (RDS) can choose to send data formatted as an SNMP 
notification.  There is some concern about how the RDS notification 
receiver list is configured.  An RDS is not likely to have a command 
responder application supporting the standard MIBs for this purpose.  
There is interest in using the mechanism defined in the draft 'DHCP 
Option for SNMP Notification' (E) for this purpose.

The RAQMON Framework draft (B) does not make a clear distinction between one 
way delay and round trip delay.  The draft needs to be more specific about 
metric methodology details.

An issue was raised about the way metrics are defined for inclusion in the 
RAQMON report.  Currently the draft defines a hard-wired list of 
possible metrics and a bit-mask in each report to identify which metrics are 
actually present.  There is interest in using a different approach which 
allows for an open list of metrics.  The RDS would need to send (at least 
once) the list of metrics supported. This requires that the metrics be 
registered (possibly with IANA) and identified somehow (possibly OBJECT 
IDENTIFIERs).  If this approach was used, it is likely that the 
Application Specific form of the RAQMON PDU would not be needed.

There is some ambiguity about the interval of aggregation for RAQMON data. Is 
this data cumulative or not. E.g., does the RDS send data for interval 0 to 
1, then 0 to 2, then 0 to 3, or does it send data for interval 0 to 1, then 1 
to 2, then 2 to 3?  This behavior needs to be specified more clearly in the 
draft.

A number of minor open issues with the RAQMON MIB (D) were discussed.  
Refer to the RAQMON MIB slides for more details on this subject.  An 
issues list has been started on the WG mailing list, and the WG will 
address these issues on the mailing list over time.

• Presentation 0

• Presentation 1

• Presentation 2

• Presentation 3