Current Meeting Report
Slides


2.3.15 Remote Network Monitoring (rmonmib)

NOTE: This charter is a snapshot of the 53rd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date. Last Modified: 11-Jan-02
Chair(s):
Andy Bierman <abierman@cisco.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Technical Advisor(s):
Steven Waldbusser <waldbusser@nextbeacon.com>
Matthew Zekauskas <matt@advanced.org>
Mailing Lists:
General Discussion:rmonmib@ietf.org
To Subscribe: http://www.ietf.org/mailman/listinfo/rmonmib
Archive: www.ietf.org/mail-archive/working-groups/rmonmib/current/maillist.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.

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
Nov 01   Call for RMON-2 Implementation reports
Nov 01   Call for RMON-PI Implementation reports
Done   Submit initial Internet-Draft for Synthetic Sources for Performance Monitoring
Nov 01   Submit initial Internet-Draft for the RMON Framework
Dec 01   Complete RMON-PI Implementation Report
Dec 01   Begin WG Last Call for Transport Performance Measurement
Dec 01   Submit Final SMON Implementation Report to IESG
Dec 01   Complete SMON Implementation Report
Dec 01   Complete RMON-2 Implementation Report
Dec 01   Submit Final RMON-PI Implementation Report to IESG
Jan 02   Submit Final RMON-2 Implementation Report to IESG
Done   Submit Final Draft of TR-RMON MIB in SMIv2 Format
Internet-Drafts:
Request For Comments:
RFCStatusTitle
RFC2021PSRemote Network Monitoring Management Information Base Version 2 using SMIv2
RFC2613PSRemote Network Monitoring MIB Extensions for Switch Networks Version 1.0
RFC2819S Remote Network Monitoring Management Information Base
RFC2895PSRemote Network Monitoring MIB Protocol Identifier Reference
RFC2896 Remote Network Monitoring MIB Protocol Identifier Macros
RFC3144PSRemote Monitoring MIB Extensions for Interface Parameters Monitoring

Current Meeting Report

RMONMIB WG Meeting Minutes
March 20, 2002
Minutes by Andy Bierman

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

(A) draft-ietf-rmonmib-apm-mib-06.txt
(B) draft-ietf-rmonmib-appverbs-03.txt
(C) draft-ietf-rmonmib-hc-alarm-mib-00.txt
(D) draft-ietf-rmonmib-sspm-mib-01.txt
(E) draft-ietf-rmonmib-tpm-mib-05.txt

Minutes
-------

1) Application Performance Measurement MIB (A)

The latest version of the APM-MIB was discussed by the group. The following issues were raised, and some additional changes were approved.

The RMONMIB WG contact information must be added to the CONTACT-INFO clause in the MODULE-IDENTITY macro.

A clarification to the apmHttpIgnoreUnregisteredURLs description is needed to help developers properly implement this object.

A new object called 'apmHttp5xxIsFailure' was discussed, which would be similar to the 'apmHttp4xxIsFailure' object for HTTP server errors. Althouth there are some corner cases which might be interesting to support, the group decided not to add this new object.

A OwnerString object will be added to the apmHttpFilterTable.

A new textual convention is needed, called DataSourceOrZero, because objects in the APM-MIB that currently use DataSource extend the semantics by defining semantics for the value { 0 0 }.
This is illegal in the SMI, since DataSource must be a value of the form 'ifIndex.I'.

The 'apmReportControlInsertsDenied' object has a syntax of Unsigned32, yet it appears to be a simple counter that can never go backward in value. The type Counter32 should be used for counters, or Gauge32 used if counter semantics are not appropriate. The type Unsigned32 is not correct.

The 'apmReportControlReportNumber' object has a syntax of Unsigned32, yet when this object is copied into the aprmReportEntry as the apmReportIndex, the syntax changes to 'Integer32 (0..2147483647)'. Both these objects need the exact same syntax.

Some new textual conventions are needed instead of embedding semantics in OBJECT-TYPE macros. These semantics are either needed right away in other RMON MIBs (such as TPM-MIB or SSPM-MIB) or may be needed in the future. They include:
- apmAppDirectoryResponsivenessType object
- apmHttpFilterMatchType
- apmNameClientID
- apmReportControlAggregationType

2) Transport Performance Metrics MIB (E)

The latest version of the TPM-MIB was discussed by the group. The following issues were raised, and some additional changes were approved.

The new indexing of the tpmExcpReportEntry will not work and will be changed back to the indexing found in the -04 version of this MIB.

The MIB objects related to the clock used for TPM measurements overlap with objects found in draft-stephan-ippm-mib-01.txt (IPPM-MIB), which will soon be converted to a WG draft of the IPPM WG. The two MIBs will be examined to determine if there is enough commonality to justify a separate MIB module. Since TPM-MIB is almost done, and IPPM-MIB is just starting, this MIB module should be contained in the TPM-MIB draft.

The TPM control table linkage to the APM MIB was discussed. It was decided that the TPM-MIB compliance for APM-MIB objects should state that the APM-MIB data tables associated with the APM-MIB control tables are not required for TPM-MIB conformance.

There will be text added to the TPM-MIB explaining how the statistics based metric measurements in the TPM-MIB can be correlated with the bin-based measurements in the APM-MIB.

The protocol classification known as 'Capital WEB' was discussed. There is currently no definition for this meta-protocol identifier. Some people think this meta-protocol should be identified in the RMON-2 protocol directory and others think it should be defined as a user application in the APM-MIB 'apmUserDefinedAppTable', since the concept only applies to APM-MIB and TPM-MIB, and not to RMON-2 functions. This meta-protocol represents the total packets and octets needed to transfer an entire WEB page and all the subordinate links embedded in that WEB page. This meta-protocol is the collection of multiple protocols (such as dns and http), and would cause protocols to be double counted in RMON-2 tables. It is also dependent on the host endpoint addresses for a given transaction, which may include multiple server addresses and one client address (e.g., some of the embedded links in the overall WEB page identify different servers in the same domain or even other domains). These properties make 'Capital WEB' inappropriate for inclusion in RMON-2 data tables. It is also possible that such data contained in APM or TPM reports will be inaccurate and misleading for the same reasons. Steve Waldbusser will post a PI macro definition for Capital WEB that will be rooted under the 'ianaAssigned' branch of the RMON protocol identifier tree.

3) Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms. (D)

The latest version of the SSPM-MIB was discussed by the group.
The following issues were raised, and some additional changes were approved.

The 'sspmSourceFrequency' object has a granularity of MicroSeconds. There is some concern that low settings for this object will contribute to network congestion or even denial of service attacks, by flooding the network with test packets. It was decided that the granularity should not change (e.g., to milli-seconds) but instead an agent may enforce a lower bound by rejecting set requests to this object below this value.

TBD: should another read-only object expressing this lower bound be added to the MIB?

The 'sspmSourceSamplingDistribution' object was discussed, and the issue of additional distribution types was considered. Enumerations for 'exponential' and 'linear' have been requested on the mailing list. There was no resolution on whether these additional modes should be added, and this issue will be discussed further on the mailing list.

The 'sspmSourcePacketFillType' object does not specify how often the URL specified in the 'sspmSourcePacketFillValue' object is checked if this object is set to 'url(3)'.

It was decided that this URL is retrieved only once, when the associated 'sspmSourceStatus' object is set to active.

The 'sspmApplLayerExtentionPassword' object was discussed and it was decided that the conformance section will reflect that this is an optional object, in order to reduce concerns in some environments about exposing real account passwords in MIB objects.

The 'sspmSourceDestAddressType' object was discussed and it was decided that this object should not be limited to ipV4 only. The authors will consider if any additional objects are needed to also support ipv6.

The source table parameter extension objects found in the sspmLinkLayerExtentionTable and SspmApplLayerExtentionTable were discussed. These objects can be added to the sspmSourceTable instead of being contained in additional tables with their own RowStatus objects (to reduce row creation complexity). The syntax and/or description clauses will be modified to indicate if the object is actually used for a given entry (e.g., zero-length string indicates object is not used).

The structure of the MIB was discussed briefly, and an optimization for reuse was proposed. Currently, the sspmSourceTable contains the destination address and the sspmSinkTable contains a source address, requiring separate entries for every source/destination address pair. Instead, the source and sink tables should be address-pair independent, and a third table used to pair a source and sink entry, and activate the actual test traffic. This will allow individual source and sink entries to be reused when the same test trafic is sent from one source to multiple destinations.

4) Remote Monitoring MIB Extensions for High Capacity Alarms (C)

The latest version of the HC-ALARM-MIB was discussed by the group. The following issues were raised, and some additional changes were approved.

The MIB currently suggests that each hcAlarmEntry should be saved in non-volatile storage by the agent. The group decided a StorageType object should be added to the hcAlarmEntry instead.

The hcAlarmVariable object was discussed regarding the requirement that the agent must return an error if the object is set to an object instance that cannot be accessed by the agent (e.g., the object doesn't exist or the instance doesn't exist). The group decided this restriction should be reversed. The agent must accept any well-formed OBJECT IDENTIFIER for this object. If the object is not valid at each polling interval the hcAlarmValueStatus instance will be set to valueNotAvailable(1).

The group agreed to add an hcAlarmValueFailed counter to the hcAlarmEntry to let an NMS know how often the hcAlarmVariable object could not be accessed.

The group decided an additional counter for the number of times the hcAlarmVariable object instance wrapped was not needed.

The group decided to add an additional BITS scalar object to identify the hcAlarmTable capabilities (ala probeCapabilities found in RMON-2) supported by the agent.

5) Remote Network Monitoring MIB Protocol Identifier Reference Extensions (B)

The group discussed the changes to the latest APP-VERB document. There was a suggestion for some additional clarifying text for the range of protocol verb enumeration values, but the document will not be re-issued for this additional sentence. This work item is now completed and the IESG will consider it for publication.

6) SMON, RMON-2, and RMON-PI Advancement

The group was urged to complete implementation reports for RFC 2613, 2021, and 2074 as soon as possible. Survey emails were sent to the mailing list in March, which should be completed and sent to the WG Chair and/or the WG mailing list. These reports are needed to advance these documents from Proposed Standard to Draft Standard status.

7) Real-time Application Quality of Service Monitoring MIB
(draft-siddiqui-rmonmib-raqmon-mib-01.txt)

The RAQMON MIB was not on the agenda, but was discussed at the end of the meeting, after all official business was completed. The main issue discussed was the specification of two usage cases for conveying QoS metrics from an endpoint device to the RAQMON-MIB agent (e.g., collector). These statistics will be encoded as an OCTET STRING. For endpoints which contain an SNMP engine, the OCTET STRING should be encoded in a Notification as sent to the collector.

For endpoints which support RTCP, a special application payload (type TBD) should be sent to the collector.

There is a great deal of interest in the WG to get this work started as soon as possible.

Slides

Agenda
Transport Performance Monitoring MIB
'draft-ietf-rmonmib-sspm-mib-01'