INTERIM_MEETING_REPORT_ Reported by Andy Bierman/cisco Systems Minutes of the Remote LAN Monitoring Working Group (RMONMIB) RMONMIB held an interim meeting in Santa Clara, CA on 21-22 November 1994. The meeting was sponsored by Bay Networks, Inc. Meeting Materials o summary.grp -- Latest feature wish list (posted November 20) o summary.lng -- Latest collection of related e-mail on each feature listed in summary.grp (posted in 2 parts November 20) o rmon-mail-agenda -- Meeting agenda (posted November 9) o robin.txt -- Long list of comments from Robin Iddon on RMON2 features and the AXON ECAM MIB (posted November 15) o ecammib.my -- AXON ECAM MIB (posted November 15) o hpaxon.mib -- RMON Probe Configuration MIB (`Aspen MIB') (posted November 15) Executive Summary All potential additions, deletions, and modifications to RMON (made available to the working group) were discussed. An effort was made to understand the purpose, merits, and ramifications of each feature. The three highest priority features were (not in any order): o Network layer host/matrix tables o Per-segment protocol distribution o Packet filtering enhancements Framework highlights: o No changes will be made to the RMON MIBs (RFC 1271 and RFC 1513) that would break existing NMS applications. o New tables will be added to new groups, not to existing groups in RFC 1271. (Possibly create new MIB-MODULE?) o The capture and filter tables may be deprecated as a result of new work on the filters. o New objects may be added to existing tables as enhancements o The rules defining the acceptable use of the dataSource object will be changed to allow other OIDs than `ifIndex.N' o EntryStatus will be kept for all existing tables. New tables will use the RowStatus textual convention. o The deadline for new problem or feature proposals is January 1, 1995 The agenda posted to the mailing list was observed, with the following exception: instead of making three passes through the work-item list, a single pass was made in which discussion on each feature was unlimited. The interest level described for each feature reflects the opinions of the meeting attendees and the perceived interest seen on the mailing list, but it shall be considered the working consensus of the group unless otherwise altered by consensus gathered via e-mail or at the San Jose meetings. Detailed Summary The following areas were covered: A) New Monitoring Features B) Packet Filtering C) Enhancements D) Bug Fixes E) SNMPv2 Alignment F) Probe Configuration G) Hardware Considerations A) New Monitoring Features A1) Statistical analysis (sampled packet capture w/hardware counters) [ Sonia Panchen/Hewlett-Packard (presentation/no MIB) ] Summary: Sample stream of stats via a post filter (Hewlett-Packard EASE) Controlled Sample Rate. Count based sample--not time-based. Interest: Strong consensus to add this feature--it was observed that this addition could be useful for hardware considerations (item G1). Probable Implementation: The dataSource objects in existing control tables could be `pointed to' an ``statControlEntry'' that would indicate the ifIndex to monitor and the packet skip count. An additional mode could be provided via filter enhancements to allow channels to capture sampled packets (see ruled-based filters). This would allow NMS-based applications to utilize the raw sampled packet slices. A2) Duplicate address detection [ no work done ] Summary: Detection of duplicate network layer addresses for the same MAC address. It was noted that `false' duplicates would exist under some normal network conditions. If this was added, it would be limited to a `best effort' by the probe. Interest: Moderate consensus to support this. It is hoped that a table which provided MAC-NET address bindings would be enough to allow an NMS app to derive this feature. Probable Implementation: A table that contained MAC-NET bindings (per interface) A3) Address change detection [ MAC changes provided in Repeater MIB, so is this any net addr or IP only -- no work done ] Summary: Detection of MAC-NET address changes. It was determined that this feature is really part of item (A2). Interest: Moderate consensus to support this. This was seen as part of feature A2. Probable Implementation: A table that contained MAC-IP bindings (per interface) A4) Network layer HostTable [ Venkat Rangan/Hewlett-Packard (presentation, MIB provided) ] [ AXON ECAM MIB ] Summary: This is viewed as a very key feature of RMON-2. The feature is assumed to include a matrix table as well. A balance must be found between hard-wired protocol tables and generic tables. Implementation proposals from Hewlett-Packard, AXON, TU Delft, and Tech. Elite were discussed. The challenge is to provide enough extensibility and flexibility to support most protocols (layer 3 and above)--without future MIB changes--and still maintain high inter-operability and low complexity. Interest: Strong consensus to add. Probable Implementation: The group seemed to favor a model that used protocol-specific soft counters (e.g. ECAM MIB). A universal directory of protocol IDs would be needed, as well as a table of protocol IDs supported by the probe. No consensus was reached on the best way to define the soft counters for a given protocol, or the protocols to be supported. (This will be a major topic at the San Jose meeting) A5) Protocol-type distribution through all 7 layers of the ISO model [ In/Out/Errors or more? Per Host? Per Conversation? no MIB ] Summary: Provide protocol distribution statistics (octets, pkts, errors?) for the protocols seen on a given interface. Interest: Strong consensus to add. No consensus to provide per-host or per-conversation protocol distribution because of the possible data table explosion that could occur at this level of granularity. Probable Implementation: No consensus on an implementation A6) Consider how RMON could benefit network security for example: Using the RMON History to provide an accountability and audit trail through the Transport Layer. [ presentation on auditing was done in Toronto -- no MIB ] Summary: Monitor Connections in the Network. Open and Close of connections. Add a table to just provide the stats. Connections to/from a resource on the network. Interest: Consensus to delete -- feature dropped. Seen to be to expensive to implement on an RMON probe. Hopefully, data from item A4 can be used to help in this area. Probable Implementation: N/A A7) More performance metrics in RMON to meet the needs of the client-server environment. [ no examples, no MIB ] Summary: Monitor transaction response times Interest: Consensus to delete -- feature dropped. Seen to be to expensive to implement on an RMON probe. Probable Implementation: N/A A8) Proposal for host and matrix protocol distribution [ Richard Kooijman (examples, MIB) ] [ AXON ECAM MIB ] Summary: Per host and per-conversation protocol distribution Related to the tables in items A4 and A5 Interest: Consensus to delete -- feature dropped. Seen to be to expensive to implement on an RMON probe. Concern over data explosion. Probable Implementation: N/A A9) Packet generation [ Karl Auerbach/Timon Sloane, others (examples, MIBs) ] [ - range of ideas: ping MIB...send raw MAC frame including CRC ] Summary: Allow a mgmt app to specify a raw packet for transmission by the probe on a specified interface. An alternative would be to allow the NMS app to specify portions of the packet, or to retransmit packets from a capture buffer. Interest: No consensus to add--group very divided on this issue. Proponents want the ability to support any protocol, or any protocol without impact on the probe. Opponents are concerned about possible misconfiguration, intentional misuse, and security implications. If the real intent of this feature is to initiate transactions, then there would be a mechanism needed to capture, recognize, and report the results. The group has decided to drop this feature but will allow further discussion at the San Jose IETF to possibly reverse this decision. Probable Implementation: N/A (Timon Sloane's packet generation MIB if revived) A10) Connectivity Tests Summary: Generate `ping' tests to determine addresses and capture the results Such `Ping MIBs' have already been posted on different occasions. (Steve will provide a EchoTest MIB example to the working group.) Packet generation would be controlled by the probe. A mechanism to trigger generation with events is desired. Interest: Strong consensus to add, but some concern that this really does not belong in RMON, but it is unlikely to be present in any other standard MIB. Probable Implementation: TBD -- want to consider fielded implementations before writing a new ping MIB. A11) User-defined history collection [ Robin Iddon, no MIB ] [ combine historyControlTable and alarmTable functionality use historyControlTable plus bucketControlTable? variable-length buckets or fixed number of objects? want to fix alarmValue encoding problems and sample discontinuity problems? ] Summary: allow an NMS app to specify objects to be collected in history buckets. Interest: Strong consensus to add Probable Implementation: Combination of historyControlTable and alarmControlTable into a new control table, and a single data table. A12) Capacity Planning--long term monitoring [ no consensus, no MIB ] Summary probe would provide long-term (i.e., weeks, months) polling of specified variables such as net utilization. Interest: Strong consensus to drop -- feature could be provided by a user history table (A11) -- feature dropped Probable implementation: N/A B) Packet Filtering The question was posed if packet filter was really `broken' and the consensus was that it is sufficient for MAC layer monitoring, but is difficult (or impossible) to configure higher-layer filters. The current filter/channel mechanism is not considered `hardware-friendly,' requiring a software implementation. B1) Filtering beyond variable-length fields in the packet [ Karl Auerbach/Timon Sloane -- filter stack (MIB proposal from Richard Kooijman, filter spec from Karl) ] Summary: Rule-based filter mechanism would allow the filters to be more sophisticated, which should result in less filters needed to capture a given packet, and allow filters to be `protocol-aware.' Make MIB structure flexible to keep performance in check. Interest: Strong consensus to add some form of non-proprietary rule-based filtering. Probable Implementation: Consensus to investigate possible use of the Berkeley packet filter engine. B2) Change filter mechanism to allow for efficient hardware implementation [ no examples, no MIB ] Summary The current filter/channel mechanism is very difficult to implement on high speed networks (100 MBit+). Some sort of `stream-lined' filter should be defined to make make implementation more likely. Interest: Strong interest in supporting high-speed networks but no consensus on what can be done. Some interest in allowing filters to be shared more easily. Probable Implementation: An `extended-error' eventType with standardized log entries in the logTable (see item C2). No consensus on any mechanism to indicate the limits of `hardware-able' filters with MIB objects. B3) Pattern matching on sub-string anywhere in pkt (pkt-grep) [ no MIB ] Summary Provide a mechanism to recognize a pattern anywhere in a packet. Interest: Strong interest to drop this feature because it is too expensive to implement--even on 10 MBit networks --feature dropped Probable Implementation: N/A B4) New table allowing filters to be shared by different channels [ Richard Kooijman (examples, MIB) ] Summary: Agent implementations can be more efficient if filters could be shared by different channels. Need to include all operators (AND/OR) and filter exit. Problem of sharing ControlTable Entries. Could register access to ControlTable with renewal from client. Interest: Low consensus to fix this in the MIB, but the issue is not closed if new ideas emerge. There was some desire to create a `glue-table' that would control the `many-to-many' filter/channel logic needed to share filters with MIB objects. Probable Implementation: None proposed B5) Intermediate data table for Karl's filter-stack [ Karl Auerbach, alternate MIB by Richard Kooijman (MIB) ] Summary: Mechanism to make `intermediate-data' gathered while decoding packets available to management applications. This includes `interesting' offsets, checksums, etc. within the various headers in the packet. Interest: Strong consensus to delete because it would be too difficult to define the data semantics and not of enough use to management applications--feature dropped Probable Implementation: N/A B6) Operator-Based Filtering [ Richard Kooijman (examples, MIB) ] Summary: Channel logic is limited to the implied OR-ing of all filters associated with the channel. A mechanism to allow other logical operators (AND, XOR?) to combine filter results could be provided. Interest: Low interest in implementing this feature with parse-able text strings. It is hoped that new filtering changes will be flexible enough to handle this level of filter logic, without implementing it in the channel logic--feature dropped Probable Implementation: N/A B7) Filter Enhancements for WAN monitoring [ Jonathan White (example, MIB) ] Summary: (This item should really be in section C.) Add new status bits to the filterStatus object to indicate the direction of the packet on a WAN interface. Also desired general purpose (non-media specific) error bit definitions. Interest: Strong consensus to add a bit for WAN-packet direction. NMS applications need to check the monitored interface type (with ifType) to determine if this bit is relevant. There was some interest in defining some general error condition bits. Probable Implementation: Add a `WAN packet direction' bit to the filterStatus object semantics. C) Enhancements C1) Packet distribution in the history data tables [ from charter, no MIB] [ assumed proposal: add etherHistoryXXtoXXPkts to etherHistoryTable ] Summary: There is no packet-size distribution in the etherHistoryTable, but there is in the token ring history tables. Interest: Moderate to strong interest in adding this feature. Probable Implementation: Add the etherStatXXtoXXPkts objects to the etherHistoryTable C2) Standardize log table entries [ trap MIB had trap decode format specified ] Summary: The standard event trap types (risingEvent, fallingEvent) have no standard log entry definition. Interest: Strong interest in providing a standard encoding for the risingEvent and fallingEvent trap types that includes an ASCII version of the trap. There was little interest in reviving the packetMatch trap for this use. Probable Implementation: Compressed format of trap-encoding formats as specified in trap log MIBs previously posted to the mailing list. C3) Resolution of captureBufferPacketTime timestamp (mSec) [ scaling factor to get microSec resolution? ] Summary: The timestamp resolution of the captureBufferPacketTime object is in milli-seconds, which inhibits inter-packet timing information. 10 or 100 micro-second resolution would be more useful. Interest: Moderate interest to consider finer granularity in this object. There was some concern over the semantics of this object--whether it was time-stamped as soon as possible after reception (by hardware?) or when the packet was added to the capture buffer (consensus was ASAP after reception). No consensus to change the semantics of this object because the added utility was not worth the risk of breaking applications currently using this object. No consensus to add a new object --feature dropped Probable Implementation: N/A C4) Timestamp in MatrixControlTable of last status change [ some examples, no MIB ] Summary: An NMS application has no reliable way of knowing when data collection was started in certain RMON tables, A timestamp would make the following situations less of a problem: * multi-manager access to a single control table * interface change in agent causing data to be flushed Interest: Moderate consensus to support in the host and matrix groups. No interest in providing a time-of-day ASCII string. Probable Implementation: Add a sysUpTime-based timestamp object to the host and matrix control tables, indicating the time that data collection was started (or restarted). C5) Client/Server Trend Analysis [ Nevil Brownlee accounting MIB (presentation, no MIB) ] Summary: Implement the Accounting `Meter MIB' (draft-brownlee-acct-meter-mib-01.txt) within RMON. Interest: Some interest in the MIB, but not as a part of RMON. Consensus to follow activity of the Accounting group and leave this alone for the time--feature dropped Probable Implementation: N/A C6) Host to Physical Port Mapping [ Dan Romascanu/Lannet, Shay Naeh/ARMON (presentation, MIB) Summary: Addition to the hostTable to provide the physical port from which a packet was received. This feature is very specific to repeaters and bridges, but can provide some required data for topology discovery (PHYS-MAC bindings). There was considerable discussion on this issue. Some address tracking is provided in the Repeater MIB (RFC 1516), but the proposed mechanism provides the last port ID for each SA, instead of the last SA seen on each port. There was some concern that a different MIB should address topology discovery issues instead of using bits and pieces from various sources (current practice). (From discussion on RMON for switched VLANs: Switches - consider a 32 port switch. Need to look at a single view of all these 32 Collision Domains. How should RMON look at this implementation. If there is a single backplane which all the 32 ports move traffic onto, we must be able to view this information and provide monitoring data. Could use an `entity MIB' to identify placeholder objects such as real or virtual backplanes, then point dataSource at this OID--or the dataSource for this could come from the connection MIB (if ever completed) to link RMON control tables.) Interest: Moderate consensus to add. No consensus on a key implementation issue: number of identifier components for the physical port. (proposed # is 2, some want up to 4) Probable Implementation: Will be based on the proposed MIB fragment from Lannet and ARMON C7) EtherStats modifications for traffic characteristics including NetUtilization added to EtherStats [ Richard Kooijman (MIB) ] Summary: proposed MIB included timing characteristics added to the ethernet statistics group, and a network utilization object. A static netUtilization object would allow thresholds to be based on bandwidth utilization. Interest: Low interest in the timing aspect, but strong consensus to add 2 or 3 netUtilization objects to the etherStatsTable. Need consensus on the intervals: 1 sec, 5 sec, 1 min, 5 min Probable Implementation: Objects added to the etherStatsTable with similar semantics as the etherHistoryNetUtilization object--except the interval is specified. C8) Acceptable DataSource values [ Richard Kooijman (Beholder2) ] Summary: The dataSource OID pointer is currently restricted to a value of `ifIndex.N', where N represents a physical interface (ethernet or token ring). Proposal to allow other entities to be used as data sources, such as: * repeater ports (rptrPortGroupIndex.GROUP.PORT) The repeater instance is determined by checking the dataSource * channel ID (channelIndex.INDEX) Interest: Strong interest to expand the dataSource capabilities and to identify the rules for expansion in order to maintain inter-operability. There was strong consensus that SNMPv1 did not provide enough error codes to help an NMS `debug' resource-related problems. Open Issues: * How does NMS know the configuration capability of the device? * How does NMS know the resource impact of a specific configuration? Probable Implementation: for table redirection: * channelIndex.INDEX will be allowed, others are TBD for resource management issues: * new MIB objects: 2 gauges indicating percentage of current memory and CPU usage * Use the Event/Log mechanism for detailed errors on RMON agent genError and badValue. D) Bug Fixes D1) Align EtherStatsJabbers with IEEE/Repeater MIB definition Summary: The RMON definition of a jabber condition is incorrect. IEEE Jabber is any frame greater than 20ms - 115ms. RMON Jabber is frame longer than 1518 with bad FCS. To fix this, etherStatsJabbers could be left alone or deprecated, and an additional object would provide a jabber condition counter consistent with the Repeater MIB definition (rptrMonitorPortVeryLongEvents) Interest: No interest in changing because the gain would not be worth the effort. NMS applications should use the repeater MIB jabber counter for accuracy--feature dropped Probable Implementation: N/A D2) Separate ethernet-specific tables from `generic-RMON' Summary: RFC 1271 contains media-specific (etherStats, etherHistory) features among the mostly generic control tables. (filterPktStatus excluded). Proposal to split the ethernet-specific portions into a different document. Interest: No consensus that this is even a bug, bug strong consensus that it is not worth fixing in any case--feature dropped. Probable Implementation: N/A D3) EtherStatsCollisions inaccurate -- cannot be counted properly with hardware. Summary: Collision counter definition not really an accurate account of the collisions on a backplane. Interest: Moderate consensus that this is a problem. Strong consensus that it is not worth fixing--feature dropped. Probable Implementation: N/A E) SNMPv2 Alignment E1) RowStatus versus EntryStatus [ from charter, consensus to add ] Summary: The RowStatus textual convention for managing conceptual row creation, modification, and deletion is preferred over the RMON-specific EntryStatus. Proposal is to use RowStatus instead. Interest: Strong interest in using RowStatus for new tables. Probable Implementation: The RowStatus TC will be used for new tables. The objects already defined with the EntryStatus TC will be unchanged. E2) Support for SNMPv2 macros [ which ones? -- is this the same as E4 ] Summary: The RMON MIB uses the `old' SMI macros. Proposal to update the MIB with the appropriate macros from the SNMPv2 SMI. Interest: Mandatory for new MIB objects, but moderate consensus not to update RFC 1271 and RFC 1513. Probable Implementation: New MIB modules (not part of 1271 or 1513) will be defined with the SNMPv2 SMI macros. E3) Alarms/Events from M2M MIB [ from charter, consensus to add ] Summary: The Manager To Manager MIB (RFC 1451) provides a more robust implementation of alarms and events (but no logging) as defined in the RMON MIB. Proposal to deprecate the existing alarms and events groups and use the M2M MIB instead. Interest: Since the M2M MIB relies on SNMPv2, it cannot replace alarms and events in existing applications. Strong consensus not to deprecate the current solution. Some consensus to add text advising the use of the M2M MIB in SNMPv2 environments--feature dropped Probable Implementation: N/A E4) Align with SNMPv2 SMI [ from charter, consensus to add ] [ DUPLICATE OF E2 -- REMOVED ] F) Probe Configuration F1) RMON Probe Configuration including modem configuration [ AXON/Hewlett-Packard (MIB) -- for consideration as a separate document from the RMON-2 spec ] Summary: Many RMON probes have proprietary configuration MIBs to configure agent behavior. Proposal to create separate document or group within RMON MIB to help standardize agent configuration. Interest: * Strong interest in adding a trap destination table to RMON * No consensus to provide acknowledged traps or modem configuration. * Consensus not to overlap existing functionality in other standard MIBs. Probable Implementation: Determine interest from the NM area AD in: * creating a new working group to handle agent configuration, including out-of-band configuration * modifying the RS-232 MIB (RFC 1317), MIB-II (RFC 1213), and the Modem MIB (RFC # ??) to support agent configuration As a last resort, some probe configuration features will be developed by the RMONMIB Working Group, derived from the Hewlett-Packard/AXON MIB. F2) Probe Resource Capacity Table Summary: Many probes can be user-configured to allocate memory resources to specific tables. A table indicating the ``memory ration'' for each table (specified in KBytes or number of entries) and memory usage could help NMS apps better utilize RMON probe resources. Only the probe may create or delete entries and write access to the ration amount is optional. An additional gauge indicating total remaining RMON resources may also be useful. (Also CPU Usage gauge). Interest: No consensus that this could be effectively implemented--even as a read-only table--because of the different ways that RMON resources are managed in various applications --feature dropped Probable Implementation: N/A F3) Probe Reset Issues Summary: After a probe resets, all the NMS-configured control entries disappear, and must be re-configured by the NMS. There is no standard way to configure non-volatile storage usage of these tables. Interest: * Concern over limited NV-storage on a probe-- probe would have to prioritize which control entries to save or limit control entries to what could fit in NV-storage. * NMS may not want all entries restored after a reset. Moderate interest in adding a storage status object to each control row, (e.g. xxObject from the Party MIB?) There was concern over stale entries in the tables, left behind by sloppy or crashed NMS apps. Probable Implementation: * storage status object added to each control row: - other(1) - volatile(2) -- RAM - non-volatile(3) -- NVRAM - permanent(4) -- ROM * DEFVAL would be volatile(2). * Deleting a row via the Entry/Row-Status object deletes from all storage areas. G) Hardware Considerations G1) A concern on the extrapolation of dropped events as the speed of networks increase, i.e., 100BaseT [ what can the working group do about this? ] Summary: The RMON MIB is difficult to implement on high-speed networks. The working group needs to explore ways to make high-speed RMON implementation more cost-effective. There was concern whether RMON should try to provide logic-analyzer quality exception handling on high-speed networks (zero or few droppedEvents). Some items that may help: 1) statistical sampling to pre-filter data (this is not useful for exception handling) 2) stream-line packet filter specifications (see item B2) 3) remove packet size distribution counters from the etherStats group (i.e., keep the counter set limited to what common hardware can count) Interest: Moderate consensus that this is really a problem--line-speed monitoring (e.g. LA-quality) is not mandatory because networks rarely run at full utilization. New probe technology will keep up with increasing line-speeds (specifically 100 MB) Moderate Interest in suggestions 1 and 2 above. Strong consensus that high-speed and switched environments have to be supported. G2) Concern for distributed RMON Summary: RMON is difficult to implement in some `non-standard' environments, such as: * multiple sub-agents * multiple processors The RMON resources are usually interface-related, determined by the dataSource object--need to know the dataSource to pick correct sub-agent. Some suggestions to help solve this problem: * possibly add text to enforce dataSource to be set ASAP * possible DEFVAL for dataSource of ifIndex.1 * RowStatus==createAndGo, dataSource in first PDU ] Interest: There was no consensus that this was really a problem. There was no interest in changing any row creation semantics. --feature dropped Probable Implementation: N/A Summary of Proposed Changes/Additions to Existing Tables o Statistics: add network utilization objects to etherStatsTable (C7) o History: add packet-size distribution counters to etherHistoryTable (C1) o Host: add physical-port indication to hostTable (C6) add data-collection timestamp to hostControlTable (C4) o Matrix: add data-collection timestamp to matrixControlTable (C4) o Filter/capture: possibly add channelDescription object to hold NMS-supplied text string -- the filter group may be deprecated as a result of new work. Add a bit to the filterPktStatus to indicate WAN packet direction. (B7) o Event: define standard logEntry formats for risingEvent and fallingEvent trap-types. (C2)