2.4.19 Remote Network Monitoring (rmonmib)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-14

Chair(s):
Andy Bierman <abierman@cisco.com>
Operations and Management Area Director(s):
Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Technical Advisor(s):
Steven Waldbusser <waldbusser@nextbeacon.com>
Matthew Zekauskas <matt@internet2.edu>
Mailing Lists:
General Discussion: rmonmib@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/rmonmib
Archive: http://www.ietf.org/mail-archive/web/rmonmib/index.html
Description of Working Group:
Steve Waldbusser is TA for SNMP/MIB related matters Matt Zekauskas is TA for Transport Retaled matters

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:
Done  Activation of working group, call for suggested MIB modules.
Done  Reach agreement on the functional scope of the charter, and finalize the document deliverables.
Done  Submit initial Internet-Draft for Differentiated Services Monitoring
Done  Submit initial Internet-Draft for Interface TopN Reporting
Done  Submit initial Internet-Draft for TR-RMON MIB in SMIv2 Format
Done  Begin Working Group Last Call for TR-RMON MIB in SMIv2 Format
Done  Submit initial Internet-Draft for Application Performance Metrics
Done  Begin Working Group Last Call for Differentiated Services Monitoring
Done  Begin Working Group Last Call for Interface TopN Reporting
Done  Submit Final Draft of Differentiated Services Monitoring to IESG for standards track action
Done  Begin Working Group Last Call for Application Performance Metrics
Done  Submit Final Draft of Application Performance Metrics to IESG for standards track action
Done  Submit Final Draft of Interface TopN Reporting to IESG for standards track action
Done  Call for MIB Modules for Synthetic Sources for Performance Monitoring
Done  Call for RMON-2 Implementation reports
Done  Call for RMON-PI Implementation reports
Done  Submit initial Internet-Draft for Synthetic Sources for Performance Monitoring
Done  Submit initial Internet-Draft for the RMON Framework
Done  Submit Final Draft of TR-RMON MIB in SMIv2 Format
Done  Complete RMON-PI Implementation Report
Done  Begin WG Last Call for Transport Performance Measurement
Done  Begin WG Last Call for Synthetic Sources for Performance Monitoring
Done  Submit Final RMON-2 Implementation Report to IESG
Done  Submit Final SMON Implementation Report to IESG
Done  Complete RMON-2 Implementation Report
Done  Submit Final RMON-PI Implementation Report to IESG
Done  Complete SMON Implementation Report
Done  Begin WG Last Call for RMON Framework
Done  Publish initial Internet-Draft for the Extensions to RMON Framework for RAQMON
Done  Publish initial Internet-Draft for the RAQMON PDU Types
Done  Submit Final Draft of Transport Performance Measurement to IESG for standards track action
Done  Submit Final Draft of Synthetic Sources for Performance Monitoring to IESG for standards track action
Done  Publish initial Internet-Draft for the RAQMON MIB
Done  Submit Final Draft of RMON Framework to IESG for standards track action
Done  Begin Working Group Last Call for the Extensions to RMON Framework for RAQMON document
Done  Begin Working Group Last Call for the RAQMON PDU Types document
Done  Begin Working Group Last Call for the RAQMON MIB document
Done  Submit initial draft for RMON Protocol Macros for IPv6
Dec 03  Submit the RAQMON PDU Types document to the IESG for publication consideration as a Proposed Standard
Dec 03  Submit the RAQMON MIB document to the IESG for publication consideration as a Proposed Standard
Done  Begin WG Last Call for RMON Protocol Macros for IPv6
Dec 03  Submit the Extensions to RMON Framework for RAQMON document to the IESG for publication consideration as an Informational RFC
Done  Submit final draft of RMON Protocol Macros for IPv6 to the IESG
Internet-Drafts:
  • - draft-ietf-rmonmib-tpm-mib-14.txt
  • - draft-ietf-rmonmib-sspm-mib-12.txt
  • - draft-ietf-rmonmib-raqmon-mib-04.txt
  • - draft-ietf-rmonmib-raqmon-framework-06.txt
  • - draft-ietf-rmonmib-raqmon-pdu-06.txt
  • - draft-ietf-rmonmib-rmon2-v2-01.txt
  • - draft-ietf-rmonmib-pi-ipv6-04.txt
    • Request For Comments:
    RFCStatusTitle
    RFC1271 PS Remote Network Monitoring Management Information Base
    RFC1757 DS Remote Network Monitoring Management Information Base
    RFC2021 PS Remote Network Monitoring Management Information Base Version 2 using SMIv2
    RFC2074 PS Remote Network Monitoring MIB Protocol Identifiers
    RFC2613 PS Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0
    RFC2819StandardRemote Network Monitoring Management Information Base
    RFC2895 PS Remote Network Monitoring MIB Protocol Identifier Reference
    RFC2896 I Remote Network Monitoring MIB Protocol Identifier Macros
    RFC3144 PS Remote Monitoring MIB Extensions for Interface Parameters Monitoring
    RFC3287 PS Remote Monitoring MIB Extensions for Differentiated Services
    RFC3273 PS Remote Network Monitoring Management Information Base for High Capacity Networks
    RFC3395 PS Remote Network Monitoring MIB Protocol Identifier Reference Extensions
    RFC3434 PS Remote Monitoring MIB Extensions for High Capacity Alarms
    RFC3577 I Introduction to the Remote Monitoring (RMON) Family of MIB Modules
    RFC3729StandardApplication Performance Measurement MIB
    RFC3737StandardIANA guidelines for the registry of rmon MIB modules

    Current Meeting Report
    OPS Area
    RMONMIB WG Meeting Minutes
    IETF #60
    August 2, 2004
    Minutes by Andy Bierman


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


    (A) draft-ietf-rmonmib-raqmon-framework-05.txt
    (B) draft-ietf-rmonmib-raqmon-pdu-06.txt
    (C) draft-ietf-rmonmib-raqmon-mib-04.txt
    (D) draft-ietf-rmonmib-pi-ipv6-04.txt
    (E) draft-ietf-rmonmib-tpm-mib-14.txt
    (F) draft-ietf-rmonmib-sspm-mib-12.txt
    (G) draft-ietf-rmonmib-rmon2-v2-01.txt
    (H) draft-siddiqui-rmonmib-raqmon-tcpsip-00.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) to DS

    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) to DS

    The current draft of the RMON-2 MIB (G) has been reviewed by Area Director and some minor edits have been identified. A new version of this document is expected within a month.

    1.4) TPM-MIB

    The TPM-MIB is currently in IETF Last Call. All 'AD Discuss' issues should now be resolved.

    1.5) SSPM-MIB

    The SSPM-MIB has been approved by the IESG and is now in the RFC Editor queue.

    1.6) IANA guidelines for the registry of rmon MIB modules

    This document has been published as RFC 3737.

    1.7) Protocol Identifier Macros for IPv6

    This document has been approved by the IESG and is now in the RFC Editor queue.

    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 Metric Collection and Reporting

    Some of the standard performance metrics defined in the basic RAQMON PDU were discussed in some detail.

    2.1.1) Jitter

    There is some disagreement within the WG as to the specific semantics of the jitter metric reporting in the RAQMON PDU (Framework, sec 5.13). Many algorithms are discussed in this section, but it is not clear what an implementation MUST, SHOULD, or MAY do for jitter measurement. The text needs to be rewritten to make this clear.

    The group discussed the granularity of the measurement, and whether separate report parameters are needed for the play-out buffer time and network-delay time. It was decided that two separate parameters should be provided in the report, but the RDS must have a mechanism to indicate how this metric is being reported (1 parameter indicating buffer+network, or two parameters indicating separate buffer and network values).

    2.1.2) One Way Delay

    There is some concern that many RDSs will not be capable of measuring OWD correctly. The group decided to leave this parameter in the basic report because it is useful. It is not mandatory for an RDS include this metric in RAQMON reports. If needed, an Applicability Statement could be written to specify which type of applications need to report this parameter.

    2.1.3) Discards vs. Drops

    The packet loss parameters (Framework, sec. 5.18 and 5.19) do not distinguish between lost packets and discarded packets. The group decided to separate these parameters in the same manner as jitter, and allow the RDS to report separate loss and discard parameters, or combined parameters. The RAQMON report must indicate what the RDS is measuring.

    2.1.4) CPU Utilization

    This parameter may be too simplistic to model some RDS HW correctly. The group discussed some alternatives, such as removing the parameter, allowing for multiple parameters (1 per CPU), or making the parameter optional. It was suggested that the value '-1' be used to indicate that the value is not available or not applicable. Instead, the RDS should simply omit this parameter from each RAQMON report if a value is not available.

    It was also suggested that a counter of the number of memory allocation failures was a more interesting parameter than memory utilization. The group agreed this was useful, but the WG should discuss this suggestion further on the mailing list before it is added to the RAQMON Basic PDU.

    2.2) RAQMON Conformance Issues

    The specific conformance requirements for a RAQMON RDS or RRC need to be clearly defined:

    - Currently, the RDS requirements section says an RDS MUST support all of the metrics in the BASIC PDU (Framework, sec. 2.1.2). This contradicts the consensus that an Applicability Statement should define mandatory report parameters for a given application class. - The RRC requirements (Framework, sec. 2.2.2, #1) state that at least one mapping must be supported. The WG needs to pick at least one mandatory-to-implement mapping (see sec. 2.3 below) - The RRC requirements (Framework, sec. 2.2.2, #2) state that a "end of report" timeout mechanism must be supported. The group agreed a mandatory configurable parameter be provided in the RAQMON MIB for this timeout value. - The RRC requirements (Framework, sec. 2.2.2, #3) state that the RAQMON MIB must be supported. The name of a specific RAQMON MIB MODULE-COMPLIANCE macro must be specified in this section. - The RAQMON PDU document mentions SNMP Informs, but not traps. The text should be changed to mention SNMP Notifications, without any RAQMON-specific conformance requirements. - The RAQMON PDU document (sec. 2.1) discusses SNMP implementation requirements, which include support for MIBs related to USM configuration. This section needs to be rewritten to discuss SNMP notification usage, not Inform usage. The USM requirement needs to be removed as well.

    2.3) Alternate transport bindings for RAQMON

    An individual submission (H) was discussed by the group. There was concern that the motivation and strategy for using TCP or SIP was not well explained in the draft. It was also agreed that SIP is not widely deployed in potential RAQMON data source devices. It was suggested that SNMP over TCP could be used, but one of the reasons for an alternate transport is to avoid the complexity of implementing SNMP.

    The group reached consensus that the TCP transport binding should be developed, and this binding is likely to be the most easily supported by potential RDS implementations of all the transport choices under consideration. The WG charter will need some minor modification. It will be noted that the WG attempted to reuse existing protocols (SNMP, RTCP, SIP) but none were found to be totally appropriate. The individual submission will be rewritten as an RMONMIB WG draft, and all references to the SIP bindings will be removed.

    2.3.1) Mandatory to implement application mapping

    The current RAQMON PDU draft (B) defines a RAQMON report delivery mechanism utilizing SNMP Notifications. All text related to RTCP transport of RAQMON PDUs has been removed, as per the WG decisions related to RTCP made at IETF #59.

    The group discussed the need to select an application mapping which is mandatory to implement on both RDS and RCC components. This decision does not have to be made right away, and it is possible that the RRC will be required to implement both the SNMP Notification and TCP bindings. The WG will also discuss the possibility of withdrawing the SNMP Notification binding because there is no evidence that any vendors want to implement it in RDS devices.

    Slides

    Agenda
    RAQMON document
    Alternate Transport Bindings for RAQMON