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:
RFC | Status | Title |
|
RFC2021 | PS | Remote Network Monitoring Management Information Base
Version 2 using SMIv2 |
RFC2613 | PS | Remote Network Monitoring MIB Extensions for Switch
Networks Version 1.0 |
RFC2819 | S | Remote Network Monitoring Management Information Base |
RFC2895 | PS | Remote Network Monitoring MIB Protocol Identifier
Reference |
RFC2896 | | Remote Network Monitoring MIB Protocol Identifier
Macros |
RFC3144 | PS | Remote 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'