NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Andy Bierman <abierman@cisco.com>
Operations and Management Area Director(s):
Scott Bradner <sob@harvard.edu>
Michael O'Dell <mo@uu.net>
Deirdre Kostick <kostick@qsun.att.com>
Steven Waldbusser <waldbusser@ins.com>
General Discussion:rmonmib@cisco.com
To Subscribe: rmonmib-request@cisco.com
Archive: ftp://ftp.cisco.com/ftp/rmonmib/rmonmib
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:
· Protocol-type distribution through all seven layers of the ISO model. · Address mapping - Network Layer to Data Link (MAC) Layer and vice-versa. · Mechanisms that enable the detection of duplicate addresses or address changes. · The relationship of the Manager-to-Manager MIB in SNMPv2 and associated RMON alarm related activities. · Host Table for the Network Layer and the Transport Layer. · Provide a simple mechanism for the specification of event/trap destinations · Address the issue of the filter mechanism being constrained by bit-to-bit packet matching, which presents a problem with variable- length packets. · Consider how RMON could benefit network security, for example: using the RMON History to provide an accountability and audit trail up to the Transport Layer. · Provide performance metrics for the client-server environment. · Concerns of hardware implementation should be considered. For example, optimization of the filter and capture group could reduce the cost of the CPU and improve performance.Goals and Milestones:
· Remote Network Monitoring MIB Protocol Identifiers
· Remote Network Monitoring Management Information Base for High Capacity and Switched Networks
Request For Comments:
Minutes of the Remote Network Monitoring (RMONMIB) Working Group
Reported by: Andy BiermanI. Summary
The goal of the Memphis meeting was the resolution of all issues, to the greatest degree possible, related to current Working Group development.
The following I-Ds and all Working Group email since the last meeting were discussed:
draft-ietf-rmonmib-rmonprot-v2-00.txt (ID-1)draft-waterman-rmonmib-smon-00.txt (ID-2)draft-ietf-rmonmib-hcrmon-00.txt (ID-3)All issues were resolved, at least in principle. Some features are not documented yet in Working Group Internet Drafts, so actual resolution is pending such publication. The Working Group believes completed documents can be submitted to the IESG by August 1997.
The Working Group agreed to maintain the current document structure. The Working Group I-D version of ID-2 will reflect the scope agreed upon at the meeting. The title is not clear yet, but 'Switch Extensions for RMON' may be appropriate.
II. Detailed Agenda Resolution
The following functional components were discussed during the meetings. Individual resolutions represent WG consensus, but are subject to mailing list objection. This is a very detailed account, since every aspect of the work-in-progress was affected by Working Group decisions made at this meeting. These minutes also serve as editing instructions for the authors of the I-Ds listed above.
No new macros have been posted to the mailing list since the last meeting. The Working Group concluded this method of document completion is not working, and it is up to the document authors to work amongst themselves to complete the Protocol Identifiers (V2) I-D.
A new version of ID-1 is expected in one month, with new PI macros, the RFC 2074 edits, and sub-section headings within the PI section removed. An off-line phone conference will be planned to discuss potential work assignments.
B.2: SNMPv1 and SNMPv2C support
B.3: MIB Logistics -- Table format
The High Capacity RMON MIB (ID-3) and all related Working Group email was discussed in detail:
Too much boilerplate - some introduction text is copied from the RMON-2 MIB.
Left up to the Editor for change. Text must remain consistent with version in RFC 2021.
'SPARSE-AUGMENTS' needed instead of real AUGMENTS to allow for a probe with only some interfaces requiring 64-bit counters. The Working Group concluded that instantiating all columns in all rows would not be a burden on agents, and would make table retrieval easier for NMS applications.
None -- AUGMENTS clause remains. Consider adding text explaining that the agent must instantiate all columns for all configured rows in the augmented table, if any columns are needed out of this table. Add rules for mapping the 32-bit counter to these filler-columns.
Keep ID-2 and ID-3 separate.Action Item(Editor ID-3):Remove reference to switch-based RMON instrumentation. This functionality to be moved to Working Group version of ID-2.More Counter64 support.
The Working Group wants all etherStats packet-based counters to have 64-bit versions, as well as all appropriate topN and usrHistory tables.
Add missing etherStats extensions. Current SNMP SMI does not support topN or usrHistory (need Integer64, Unsigned64), so these functions will not be added at this time.
External port aggregation and internal collection-point monitoring were discussed together, but it was agreed that they are different problems that require different solutions. Discussion of internal collection-point monitoring is located in Sections E.2 and E.4.
Port aggregation allows an agent to potentially reduce DRAM and CPU collection requirements, and an NMS to reduce polling of redundant monitoring information.
C.1: Port Aggregation Mechanism
The ifStackTable will be used to represent an RMON port aggregation group. For example, suppose ifEntry.4, 5, 6, and 7 are to be monitored as one collection, and ifEntry.100 exists as a proprietary-virtual 'place-holder' interface, needed only for the following ifStackTable rows:
ifStackStatus.4.100 = active(1)ifStackStatus.5.100 = active(1)ifStackStatus.6.100 = active(1)ifStackStatus.7.100 = active(1)
An NMS would then set the appropriate RMON dataSource parameter to ifIndex.100 in order to monitor the just-configured port aggregation group.
[Editor’s Note: The Working Group did not fully consider this issue at the meeting wrt/ dynamic aggregation. For an N-port switch there are (2^^N) - 1 possible port aggregation permutations. If an interface is allowed to appear in 0 or 1 collections, then N top-level proprietary-virtual interfaces must be pre-configured. This issue is considered re-opened and deferred to the mailing list for discussion. The Working Group should consider how to define port aggregation groups dynamically such that the top-layer virtual interface does not actually have to be present in any IF-MIB tables before it can be used.]
Describe the agreed-upon ifStackTable-based port aggregation framework. Define the dataSource configuration MIB objects. Consider mechanisms for fully dynamic dataSource configuration.
C.3: Data Reduction Mechanisms
No available-dataSource-permutation mechanism will be considered for the ifStack-based aggregation feature at this time. No pre-collection filtering mechanisms will be defined either. All traffic from an identified interface is considered part of the dataSource. Individual VLANs may be identified as dataSources, pending outcome of the features defined in Section E.2. Monitoring on non-local ports is considered a distributed management function deferred to the DISMAN Working Group.
D: 100MB/Gigabit Ethernet Ports
D.1: High Capacity Counters for Fast Ethernet, Gigabit Ethernet
The high-speed counter support for these interfaces is discussed in Section B.
The Working Group agreed full-duplex and half-duplex interfaces must be representable by a single dataSource. See Section E.2 for functionality defined in this area.
The old network utilization formula defined in RFC 1757 is specific to 10MB Ethernet ports. Formulas for 100MB (half & full duplex) and GBit Ethernet ports should be defined.
Add appropriate framework text to define calculation formulas for specified ethernet port types.
D.4: High-speed packet capture
The RMON-1 packet capture feature utilizes a packet-arrival-time delta-filter with a granularity of milli-seconds. High speed interface monitoring would benefit from finer granularity monitoring. This feature extension must be backwardly compatible with the existing captureBufferPacketTime object defined in RMON-1.
Define mechanism to augment the captureBufferTable to include the microsecond component of the capture-time-delta.
Switch-related RMON features were discussed in general, and the SMON MIB (ID-2) in particular.
The Working Group will add some IEEE 802.1Q VLAN support to ID-2. It was determined that per-VLAN information is much more important in the etherStats group than any other RMON groups. Therefore, only VLAN identification, dataSource identification, and port-level statistics collection will be addressed at this time. The Working Group will consider per-VLAN-priority as well, but this feature is not required at this time.
Add VLAN encapsulation protocol identifier macros as required.
Consider adding text to ifStack-based dataSource feature explaining use of this mechanism to monitor VLANs. Consider additional mechanism to identify a VLAN itself (regardless of port) using the dataSource capabilities feature.
Add control table and data table for 802.1Q VLAN statistics, sparsely indexed by 12-bit VLAN ID. Consider proper values for dataSource parameter. Data columns are:
{ ucast, mcast, bcast } * { octets, packets }
Consider adding control table and data table of 802.1p statistics for a given dataSource, densely indexed by 3-bit 802.1p priority value. Consider proper values for dataSource parameter. Data columns are:
{ priority } * { octets, packets }
{ priority } * { ucast, mcast, bcast } * { octets, packets }
E.2: Switch Configuration Extensions
MIB objects to configure a copy-port function will be defined. The Working Group considered three levels of functionality:
1) 1 src port to 1 dst port 2) N src ports to 1 dst port3) M src ports to N dst ports
The Working Group will support Option Two, and may support Option Three in the future.A dataSource capabilities mechanism will also be defined, to allow an NMS to better determine probe-monitoring capabilities. Mechanisms to alert or prevent copy-port over-subscription problems were discussed, but no features were defined.
Define table allowing arbitrary number of src-portX-to-one-dst-port copy-traffic configurations. Consider adding support for full-duplex interfaces in the dataSource capabilities table(s). Consider extensions required to support level three copy-port functionality. Consider adding a dropEvents counter associated with the dst port to help an NMS detect over-subscription problems.
Define a dataSource capabilities function, identifying:
OID of dataSource
ProbeCapabilities bit-mask pertaining to this dataSource only. If present, this overrides the global bit-mask for this dataSource.
Indication of dataSource type { ifEntry, ifStack-aggregation, and entPhysicalEntry } Consider functionality needed for arbitrary aggregation of these base dataSource types.
Indication of promiscuous versus non-promiscuous monitoring capability of the dataSource
Indication of errored-frame monitoring capability; individual error conditions do not need to be identified.
Indication of { half-duplex-rx, half-duplex-tx, full-duplex-both } status for full-duplex ports
E.3: Switch-specific external instrumentation
The Working Group agreed that no additional functionality is required in this area, since port aggregation, dataSource extensions, and VLAN monitoring are addressed separately.
E.4: Switch-specific internal instrumentation
The dataSource mechanism in E.2 may support dataSources and dataSource aggregations not identified in the ifTable (e.g., a repeater port). The Entity MIB will be used to identify internal backplanes (and possibly other entPhysicalEntry types) as collection-points.
No new functionality will be considered in this area, but consider adding reference to Bridge MIB to identify statistics for number of forwarded versus dropped frames per-bridge-port in framework section for switch monitoring.
E.5: Per-Connection Statistics
TCP connection monitoring was discussed, but this work will not be pursued, since it is considered to be within the scope of the RTFM Working Group.
E.6: Switch-Specific Protocol Directory
The Working Group determined that no switch-specific protocol Directory replacements or extensions are required.
The Working Group may need an interim meeting to complete the current workload by August. Due to the amazing amount of material covered and resolved in 3.5 hours at the Memphis meeting, an interim meeting was not scheduled at this time. In the event the action items herein are not resolved by May 12, then an interim meeting will be announced around the June 10 time frame.
Completion of deliverables defined in the Summary section above.
Meeting location does not have to be outside the USA, since it will be held within two months of the Munich IETF (although the RMONMIB Working Group does not intend to meet in Munich). The Working Group will probably choose a non-hosted city, at an airport hub on or near the east coast of the USA. The cities suggested so far: Washington, DC or Boston
The Working Group discussed the following RMON-2 related issues:
Some TCs are defined in terms of other TCs1757 version of OwnerString TC now different (maybe obsolete), and perhaps the IF-MIB version or general TC-MIB replacement should be used instead.
No resolution was reached in either case, but the Working Group agreed that the capability to define TCs in terms of other TCs should be supported.
The ATM-RMON MIB counts ATM-specific cells and connections, using data structures similar to those found in RMON-1. The ATM Forum is standardizing this MIB, and a final vote is due soon on document af-nm-test-0080.000. The RMONMIB Working Group is requested to consider integration of frame-based monitoring of ATM interfaces with the cell-level mechanisms found in the ATM-RMON MIB.
Consider adding appropriate PI macros for AAL-5, LANE, and other ATM-related frame encapsulations.
1.
RMON Working Group Agenda/Meeting Summary