2.4.13 Remote Network Monitoring (rmonmib)

Last Modified: 2004-02-18

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 #59
March 1, 2003
Minutes by Andy Bierman

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

(A) 
draft-ietf-rmonmib-raqmon-framework-05.txt
(B) draft-ietf-rmonmib-raqmon-pdu-05.txt
(C) draft-ietf-rmonmib-raqmon-mib-03.txt
(D) draft-ietf-rmonmib-pi-ipv6-00.txt
(E) draft-ietf-rmonmib-apm-mib-12.txt
(F) draft-ietf-rmonmib-tpm-mib-13.txt
(G) draft-ietf-rmonmib-sspm-mib-11.txt
(H) 
draft-ietf-rmonmib-rmon-oid-assignments-01.txt
(I) draft-ietf-rmonmib-rmon2-v2-01.txt

Agenda
------

  1) WG Document Status
  2) Real-time Application Quality of Service Monitoring

Minutes
-------

1) Working Group Document Status

The following work items have been completed by the WG, but not yet 
published as RFCs.

1.1) Advancement of RFC 2613 (SMON)

The WG is currently waiting for IESG action for advancement to Draft 
Standard.  This action is on hold because RFC 2613 has a normative 
reference to RFC 2021 (RMON-2).  It cannot advance until RMON-2 
advances to Draft Standard.

1.2) Advancement of RFC 2021 (RMON-2)

The current draft of the RMON-2 MIB (I) has been reviewed by the WG and 
completed WG Last Call without additional comments.  It has been 
forwarded to the AD for publication consideration as a Draft Standard.

1.3) APM-MIB

The APM MIB has been published as a proposed standard (RFC 3729).

1.4) TPM-MIB

The TPM-MIB is currently in IETF Last Call.

1.5) SSPM-MIB

The SSPM-MIB is currently in IETF Last Call.

1.6) IANA guidelines for the registry of rmon MIB modules

The IESG recently approved this document which clarifies OID 
assignment procedures for RMON MIB modules.  This document will be 
published soon as a proposed standard RFC.

1.7) Protocol Identifier Macros for IPv6

This document in an extension to RFC 2895 to support new 
encapsulation layers for IPv6.  The WG has completed work on this 
document and forwarded to the AD for publication consideration as an 
Informational RFC. Some additional clarifications (requested by the AD) 
regarding MPLS have been added since the WG meeting.

2) Real-time Application Quality of Service Monitoring

The RAQMON Framework (A), RAQMON PDU (B), and RAQMON MIB (C) documents were 
discussed together.  A presentation on these drafts was given, 
explaining the changes from the last versions, and open issues with each 
draft.  Refer to the slides for details on this presentation.

2.1) RAQMON Documentation Issues

- Number of documents

The group discussed whether the current document grouping is the most 
appropriate for RAQMON.  It was decided that the 3 documents are okay, but 
more work is still needed to completely remove redundancies between the 
documents.

- Framework document edits 
   - section 5.14: these should be running counters from the start of the 
application session, not delta counters from the last report PDU.
  - RFC 3611 is an informative reference, not normative
  - CPU utilization may be too simplistic for devices with multiple CPUs or 
specialized CPU-like HW. The group decided to leave the CPU 
utilization as-is, because it may still be useful for debugging. Add 
clarifying text for corner cases (beyond 1 CPU).
  - Randy Presuhn agreed to review the documents for readability and 
grammatical correctness.
  - RAQMON has a metric for total loss, but it should have local loss + 
network loss
    - split this into 2 metrics, and the RDS will fill out as 
appropriate (based on its data collection capabilities)
 - jitter data is not complete Need to know codec type, codec 
configuration; not just the payload type.
  
2.2) Fragmentation
    
RAQMON PDUs are expected to be about 400 bytes so the authors are not 
concerned about fragmentation.  However, if multiple sub-reports are 
included in the PDU, this assumption could be incorrect.  The "1 PDU every 2 
minutes" transmission limit placed on RDss could cause multiple reports to be 
combined if the RDS has more than one 'event' every 2 minutes to report.

There were no suggested changes to the document regarding this issue.
     
2.3) Use of RTCP as a RAQMON Transport

The use of RTCP as a transport protocol for RAQMON PDUs was discussed at 
length.  There is considerable concern that RTCP is not being used as 
intended or in a manner that is conformant with the RTCP standard.  For 
example, it is possible in many topologies for the rate-limiting 
mechanisms to be misapplied or ignored on the complete path between an RDS 
and an RRC.

Therefore, the RTCP protocol will not be used as a transport protocol for 
RAQMON PDUs.  All reference to the use of RTCP for this purpose will be 
removed from the documents.

2.4) Development of a new performance monitoring protocol

Now the WG must decide if it should create a new protocol for the 
transmission of RAQMON PDUs, or if the SNMP notification transport is good 
enough.

The IPFIX protocol is considered too heavyweight for IP phones and other 
intended platforms for RAQMON.
The WG needs to develop use cases that justify creation of a new 
protocol, and solution proposals would have to be generated by 
individual submission.  Any proposal must completely address all the 
interoperability, congestion, and security concerns that the IESG will 
raise during its review process.

2.5) MIB Issues

The following comments were noted regarding the RAQMON MIB:
  - Use InetAddressType/InetAddress instead of IPAddress
  - Use running counters instead of the delta since the last report 
packet.  
  - threshold mechanism is supposedly needed because the RAQMON 
instances are dynamic and not easy to monitor with existing threshold MIBs
  - Section 4: add a complete description of each table and the 
relationship between all the tables
  - Investigate the use of TPM-MIB instead of RAQMON-MIB for the 
collection of RAQMON PDU data.  
    - TPM has better statistical functions and thresholding but it is 
tightly coupled to APM and the RMON-2 protocol directory.
  - The rationale and use cases which justify the complex index 
structure (DateAndTime) in the MIB need to be explained in the 
document.

2.6) Issue Tracking

RAQMON issues need to be tracked and their status recorded. Status emails 
containing an issue list will be started and send to the WG mailing list 
periodically.

• Presentation 0

• Presentation 1