Last Modifield: 08/02/2002
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.
|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|
|AUG 02||Complete RMON-PI Implementation Report|
|AUG 02||Begin WG Last Call for Transport Performance Measurement|
|AUG 02||Begin WG Last Call for Synthetic Sources for Performance Monitoring|
|SEP 02||Submit Final RMON-2 Implementation Report to IESG|
|SEP 02||Submit Final SMON Implementation Report to IESG|
|SEP 02||Submit Final RMON-PI Implementation Report to IESG|
|SEP 02||Complete SMON Implementation Report|
|SEP 02||Begin WG Last Call for RMON Framework|
|SEP 02||Complete RMON-2 Implementation Report|
|OCT 02||Submit Final Draft of Transport Performance Measurement to IESG fro standards track action|
|OCT 02||Submit Final Draft of Synthetic Sources fro Performance Monitoring to IESG fro standards track action|
|OCT 02||Submit Final Draft of RMON Framework to IESG fro standards track action|
|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|
|RFC2819||Standard||Remote Network Monitoring Management Information Base|
|RFC2896||I||Remote Network Monitoring MIB Protocol Identifier Macros|
|RFC2895||PS||Remote Network Monitoring MIB Protocol Identifier Reference|
|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|
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.