NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 30-Sep-99
Andy Bierman <firstname.lastname@example.org>
Operations and Management Area Director(s):
Randy Bush <email@example.com>
Bert Wijnen <firstname.lastname@example.org>
Operations and Management Area Advisor:
Bert Wijnen <email@example.com>
Steven Waldbusser <firstname.lastname@example.org>
To Subscribe: email@example.com
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 working group will consider existing MIB modules that define objects which support similar management, e.g., RFC 1271 and RFC 1513 and efforts in other areas, e.g., the accounting and operational statistics activities. It is possible that this RMON will not be backwards compatible with existing RMON RFCs, but the reasons for any such incompatibility will be well documented.
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:
1) Additional Protocol Identifier macros will be added to the Protocol Identifiers Specification to broaden protocol decode support in RMON-2.
2) Monitoring support will be improved for high-speed interfaces, for which octet and/or packet counters can possibly wrap in less than one hour. Packet capture support for high speed interfaces will also be considered.
3) RMON probe configuration capability, especially for switch-based RMON implementations, will be improved.
4) Configuration and monitoring of full-duplex ethernet interfaces will be considered and/or clarified.
5) Monitoring instrumentation for IEEE 802.1Q VLAN-based network traffic will be considered.
Goals and Milestones:
Activation of working group, call for suggested MIB modules.
Submit initial Internet-Drafts for Protocol Identifier and High Capacity RMON functionality.
Submit initial draft for configuration extensions and other functionality.
Submit Internet drafts to IESG for standards track action.
Request For Comments:
Remote Network Monitoring Management Information Base
Remote Network Monitoring Management Information Base Version 2 using SMIv2
Remote Network Monitoring MIB Protocol Identifiers
Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0
RMONMIB WG Meeting Minutes
46th IETF Washington, D.C., USA
November 10, 1999
Minutes by Andy Bierman and Russell Dietz
1) Completion of current WG charter: I-D advancement (20 min)
- status of WG Last Calls (I-Ds A - F), pending IESG Last Calls
2) Mailing List Issues (20 min)
- MIB issues raised on firstname.lastname@example.org since the last WG meeting
3) Presentation and discussion of functional requirements of work items in the proposed charter extension (60 min)
4) Discuss updated proposal for new WG charter; Refine list of deliverables, assign editors, and establish schedules (20 min)
The updated charter text can be found at: ftp://ftpeng.cisco.com/ftp/rmonmib/rmon_charter_nov99.txt
1) WG Status
The WG Chair presented a status summary of the I-Ds before the WG.
The TCs defined in the HC-RMON MIB are based on Counter64, but the 'delta' and 'wrap' semantics of the Counter64 base type are not inherited by these TCs. This is not strictly legal in SMIv2.
The NMRG recommended a 'temporary' set of TCs to allow the HC-RMON based drafts (B - D) to be published. The HC-RMON MIB (B) will be republished, with the TCs removed. The TCs in a new HC-DATA RFC (TBD) will be referenced instead. The MIB objects in the HC-RMON MIB which are defined with these TCs may have to be deprecated in the future, and replaced with new objects with a different ASN.1 encoding, but the same syntax.
1.2) Standards Track Advancement
The RMON-1 MIB in SMIv2 format (A) has been reviewed by the WG and forwarded to the Area Director for IESG action. The WG is requesting that this MIB be published as a Full Standard.
The RMON Protocol Identifier Reference (E) has been reviewed by the WG and forwarded to the Area Director for IESG action. The WG is requesting that this MIB be published as a Proposed Standard.
The RMON Protocol Identifier Macros document (F) has been reviewed by the WG and forwarded to the Area Director for IESG action. The WG is requesting that this MIB be published as an Informational RFC.
1.3) RFC 1513 Advancement
The WG Editor agreed to update the Token Ring RMON MIB (RFC 1513) in SMIv2 format. The updated document will be subject to a 2 week WG Last Call, and then forwarded to the Area Director for publication consideration. This is not a chartered work item, so it is considered a low priority task.
1.4) Completion of the current WG charter
Except for minor editing changes in the HC-RMON draft, the current RMONMIB WG charter is completed.
2) Mailing list issues
2.1) SMON Interoperability Testing
The WG was polled for interest in an SMON MIB bakeoff-style Interoperability Test. There was limited interest (about 6 hands) at this time, so the WG is not going to pursue an SMON test event in the near future.
2.2) Interest in an Interim Meeting
The WG was polled for interest in an interim meeting in January 2000 to discuss Application Performance Measurement (APM), one of the work items on the new charter proposal. There was significant interest in an interim meeting - about 12 to 14 people indicated they would attend a 2 day interim meeting.
The WG will likely hold a two day interim meeting on January 10-11, 2000. The meeting will be in or near Boston, MA, USA. Details will be announced later on the WG mailing list.
2.3) Counter64 alarmTable Support
There have been requests for a 64-bit alarmValue object to return all possible values when alarmVariable points to a Counter64-based MIB object. The WG decided this is not important enough to work on at this time. The workaround is to set alarmInterval to a low enough value, so that the difference between two polls of the same Counter64 object cannot reach 2^^32.
2.4) Bugfixes in RMON document
Some minor edits to the RMON-1 MIB (A) will be required to fix some minor MIB compiler warnings, (e.g. OwnerString defined in terms of the DisplayString TC instead of OCTET STRING base type). This new version will be produced by the WG Editor, and will not be subject to another WG Last Call. The edits were discussed and agreed upon in the WG meeting.
2.5) usrHistory Range Overflow
There is a corner-case for the usrHistoryTable (from RFC 2021) in which the usrHistoryAbsValue and usrHistoryValStatus pair cannot properly represent a delta poll value. If the last sample was the maximum negative value and the next poll is the maximum positive value, then the resulting delta poll value will be too large to be represented in the usrHistoryTable.
The WG decided that if the agent detects this situation, the usrHistoryStatus should be set to 'valueNotAvailable(1)', and the usrHistoryValue set to zero. The same situation occurs with the HC-usrHistoryTable in the HC-RMON MIB (B).
2.6) Dynamic History Bucket Resizing
The WG decided at the last Santa Clara Interim that the etherHistory and usrHistory bucketsRequested would not require 'dynamic' bucket changes, e.g., the agent does not have to allow changes to the usrHistoryControlBucketsRequested object while the associated usrHistoryControlStatus object is equal to 'active(1)'. RFC 2021 does not reflect this decision, and it should be updated the next time the RMON-2 MIB is re-published.
2.7) NetBEUI encaps in RMON-2 NL/AL tables
A question came up on the mailing list regarding the proper RMON protocol identifier and NL/AL representation for protocols without a proper network layer. The WG decided this issue awhile ago. For RMON-2 purposes, the network protocol should indicate the MAC layer (e.g., ether2), and MAC addresses should be used in the NL address objects.
3) Presentations on the APM work item
Presentations addressing the functional requirements of application performance measurement were made by the following people:
- Steve Waldbusser
- Russell Dietz
- Albin Warth
The slides from these presentations have been submitted with the WG meeting minutes, and they will also be posted on the WG ftp site at ftp://ftpeng.cisco.com/ftp/rmonmib/
4) New WG Charter
4.1) Charter text discussion
After some debate, the WG decided not to add text about active vs. passive APM techniques, or to add text about transport layer vs. application layer monitoring.
A new version with minor edits already been posted to the WG mailing list, reviewed by the WG, and sent to the Area Directors for consideration. The following changes were made:
- the work item name 'Persistent Label' was changed to 'User Name'
- A statement about APM methods already available deleted
- phrase 'network service level' replaced with 'application performance measurement'
4.2) Poll for authorship interest in each work item
Each work item is listed along with the number of people present at the WG meeting who indicated an interest in authoring document(s) related to that work item.
- Application Performance Measurement (12+) (TBD) Some drafts have already been submitted, and the WG Editor has also expressed interest in this work item. All potential authors are encouraged to write drafts for WG consideration ASAP.
- User Name to Address Mapping (3) Steve Waldbusser, Russell Dietz, Andy Bierman
- DiffServ Statistics Collection (2) Andy Bierman, Dan Romascanu
- Protocol Directory Optimization (3) Andy Bierman, Russell Dietz, Chris Bucci
- Protocol Directory Application Wildcarding (2) Russell Dietz, Chris Bucci
- Per-Interface TopN Reporting (2) Dan Romascanu, Andy Bierman
- Frame Relay DataSources issues (1) Robert Steinberger
4.3) 2 Week Timer on some work items
The following work items will be dropped from the charter proposal unless some significant progress (I-D or email) is made in the next two weeks.
- Protocol Directory Optimizations
- Protocol Directory Wildcarding
Note that 'Frame Relay DataSources' was on this list, but an email was sent to the mailing list on 11-nov-99 which constitutes significant progress on this work item.
Application and Service Performance Measurement
Common Metrics for Application Performance Measurement (APM)