CURRENT_MEETING_REPORT_ Reported by Russell Dietz/Technically Elite Concepts Minutes of the Remote LAN Monitoring Working Group (RMONMIB) TUESDAY, 6 DECEMBER 1994 - FIRST SESSION Agenda (for both meetings): o Summary of interim meeting progress o Bashing of interim meeting progress o Network-layer host/matrix tables o New presentation Packet filtering Packet generation The chair presented a summary of results from the interim meeting that was held in Santa Clara on 21 November and 22 November 1994. The results took the form of the following listed items. o Items to be included for RMON-II - Statistical sampling - Network layer host/matrix - Connectivity tests - User-defined history collection - Rule-based packet filtering - Probe configuration o Items still to be considered for RMON-II - Duplicate address detection (50%) - Address change detection (50%) o Items excluded for consideration from RMON-II - Connection monitoring - Transaction response timing - Per-host protocol distribution - Raw packet generation - Long term capacity planning - Packet grep - Channel logic - Accounting group Meter MIB The following features were included instead of dropped (and one feature missed): 1. Per host protocol distribution 2. RMON agent configuration 3. Port to physical address mapping 4. Consideration for hardware implementation on high-speed networks The floor was then opened for general ``bashing'' of the interim meeting lists. Probe Configuration There was some discussion on the need for the RMONMIB Working Group to address the issue of Probe/Agent Configuration. The general consensus was that there may be a need for this, however the working group must make sure that the configuration sections of the RMON MIB do not duplicate the efforts of other working groups in the Network Management Area. The working group will continue discussion of this problem. The proposed solution is to create an optional group from objects in the Hewlett-Packard/AXON Aspen MIB. Hewlett-Packard, AXON and Technically Elite have implemented the Aspen MIB for agent configuration. Per-interface Protocol Distribution The group decided to add Protocol Distribution tables in both the dataSource and host/matrix table style. Many agreed that while the number of rows in these tables could grow very fast, that this would be no different than the current resource usage of the host and matrix tables on a large feed or backbone in any network connected to the Internet. The consensus was that RMON-II should consider both per dataSource Protocol Tables and host/matrix protocol tables. The working group will need to make sure that these protocol tables are interoperable. It was also agreed that the ``soft'' counters outlined in the AXON ECAM MIB should be removed because of the inability to develop a MIB that would be able to interoperate and provide the data in the counters. The ECAM MIB was presented in detail in the second meeting. Port Mapping A proposal from Lannet for mapping physical connections (ports) to physical addresses (MAC). A presentation and further discussion was deferred to the second meeting. RMON-II Compatibility With RFC 1271 During the interim meeting, the general consensus was that the new RMON-II MIB will not break the existing tables, and that the working group will not depreciate any existing tables. The consensus in the working group meeting also wanted to prevent the ``breakage'' of existing RMON client applications. However, the working group decided to agree that ``every effort will be made not to break the existing MIB.'' This was due to some concern over hardware implementation considerations. It was agreed that no changes are locked out at this time, but specific proposals need to be made before this issue can be addressed. The working group also agreed that existing tables will continue to use EntryStatus, and new tables will use the RowStatus TC. This will keep existing applications working, while assisting in the migration to SNMP V2 SMI incorporation. There was then some discussion on adding a timestamp to the host and matrix tables. This timestamp would tell the manager application that the table had ``changed state.'' It was then suggested that the same timestamp be included in every table. The working group decided that there was enough interest to look into this further as part of RMON-II. Statistical Sampling The working group then discussed the statistical sampling item. The general consensus, at first, was that this could should not be implemented since it is only a ``sampled'' view of the network traffic. However, Steve Britt of Hewlett-Packard, stated that the data has proven useful to the Hewlett-Packard EASE product in long term trend analysis. In addition, the working group discussed the usefulness of the technology in faster (100Mb) networks. The working group discussed the issue of the Hewlett-Packard patent on this analysis. Steve stated that Hewlett-Packard would be willing to release the patent on the areas which the new RMON-II MIB would cover for statistical sampling. Connectivity Tests The working group discussed the usefulness of connectivity tests. This is similar to a ``ping'' MIB. It was presented that during the interim meeting the consensus was the these tests would be better than a simple packet generation engine. Limited to the number of basic protocols on-line. User-Defined History Collection The chair had posted a MIB that allows manager-defined counters from within a MIB-view, in a similar fashion to the current history table. Some concerns were raised as to if RMON-II should be able to collect this data. A consensus was reached that the current alarm table allowed for this feature on a single OID basis, therefore the working group should consider this ``collection'' of counters an extension of that functionality. Duplicate Address Detection There were concerns over the rules for adding an entry to a DuplicateAddressTable (i.e., some false triggers can occur) Mapping of physical to network address via ``Protocol'' may help detect this condition. Mapping of Physical to Network Address Several members of the working group expressed a need for mapping of the physical and network layer addresses. The need for a separate table from the network layer host table was discussed. No general consensus was made during the meeting, other than this feature would be provided as part of the network layer tables. Channel Logic This feature (extended logic for the filter-set) would be required if we are going to enable the both the ``old'' filter tables and the ``new'' rule-based filters. Changes to the channelTable will be considered as part of the new filtering framework. Raw-Packet Generation The working group discussed the issues behind the removal of packet generation from the consideration list for RMON-II. Several members of the working group protested the removal of this feature stating that ``this is a desired tool for troubleshooting network problems.'' The feeling at the interim meeting was that users would have serious security concerns with a device that could generate any packet to anyone on the network, if someone were to ``break into'' the RMON-II agent. Hardware Statistics There was great concern expressed over the fact that there had was no mention of a need for changes to the current RMON framework that would enable more cost effective hardware-based RMON solutions. It was noted that there had not been any recent proposals as to what areas of the RMON MIB, with the exception the channelAcceptType, that required changes for hardware-based RMON. It was agreed that the working group would add this item to the ``In'' list and await proposals for change requirements. TUESDAY, 6 DECEMBER 1994 - SECOND SESSION Agenda: o Straw Poll on proposed feature set o Presentations--specific feature proposals Feature Set Straw Poll A strawpoll regarding the RMON-II feature list was taken: (Percentage that agreed with the status.) o In - Statistical sampling (50%) - Network layer host/matrix (95%) - Protocol distribution host/matrix (95%) - Connectivity tests (50%) - User-defined history collection (80%) - Rule-based packet filtering (50%) - Probe configuration (50%) - SNMP V2 SMI (90%) - Hardware friendly RMON (50%) o Possible - Duplicate address detection (25%) - Address change detection (25%) There was no strong objection to changing the status of any item on the `removed' or motion to do so. RMON-II Framework A motion to discuss RMON-II framework was made, but was deferred to the mailing list by the chair, because of time limitations. (several people had prepared presentations of specific features.) The working group has to address this issue as soon as the feature set is stabilized. PREPARED PRESENTATIONS Port Mapping - Dan Romascanu Dan presented a MIB fragment that was posted to the mailing list for review. This MIB would extend the current hostTable and provide linkage between physical port and MAC address for each host. The proposal was optimized by using a single OID in which the object portion identified the physical port type, and the instance portion (N components) represented the specific port value. The working group reached a consensus that this should be reviewed for inclusion in RMON-II. NETscout - Anil Singhal Anil presented an application model for logical filters (higher layer) and HostDetail (added host stats). The features included: o Physical probe - RMON o Virtual probe - (DomainView - a domain or collection of probes) o Logical filters - protocol family - enumerated type - single filter for SAP, Etype SNAP and others o TransportID - octet string - just after the family in the frame. Host address. Address direction. o Host Detail - DeviceType, MacAddress, AddressChangeCount, FirstPacketTime, LastPacketTime InRemote, OutRemote There was no motion to add any specific MIB objects or problem statements to the RMON-II feature list. Hewlett-Packard Statistical Sampling - EASE - Steve Britt Sampling provides measurement for looking at network traffic. EASE Application feature summary: o Cost, timeliness, accuracy, salability, security o Random sample count - every so many packets o 1,000,000 random of .25% (2500) o 1,000 from node M o Random samples that can handle higher speed networks A proposal was made to provide a flag in RMON tables to know that this is sampled. Another idea was to use dataSource to designate a `sampled interface.' No consensus for either. There was no consensus reached on how statistical sampling should be implemented in RMON-II. This will be considered just one of (possibly) several ideas to reduce the cost of RMON on high-speed networks. ECAM - Robin Iddon The ECAM MIB provides statistics for an arbitrary number of user-specified protocols in a consistent table format. There are two ways a protocol can be specified by the user and data collected for that protocol: o Protocol directory -- a globally enumerated (hard-wired) list of well-known protocols identifiers is created. A control table configures which protocols should be collected by the probe on each interface. A specific identifier is used in the data table index. Data tables such as those in the statistics, host, and matrix groups can be created with this additional index. o User defined protocols -- a channel could be used as the data source for statistics collection. Existing RMON tables (hostTable, matrixSD/DS) could use a channel by setting the dataSource top channelIndex.N The framework for higher-layer statistics is of primary concern for the working group at this time. There was general consensus to pursue both models. It was agreed that only basic counters could be provided in an interoperable way--it would be too difficult to generically identify ``interesting things to count'' in each protocol. ARGUS 1.3 - Chas DiFatta ARGUS provides logging of transactions for connections in a TCP network. Agent would create a table of history-based TCP connections and implement the TCP connection state machine to determine the true status of each TCP connection. State tracking is a problem--it was suggested that the probe just report the TCP events that are observed. There was also concern about the size of log tables on embedded probes without disk storage. There was no consensus to add this feature to RMON at this time or specific suggestions on how to integrate this application into the RMON MIB. For information about freely-available ARGUS software contact: argus@sei.cmu.edu. TCP/IP Connection Monitoring After the Argues presentation, there was a great deal of discussion on the usefulness of this type of network monitoring in general on RMON probes. There was no consensus reached on inclusion of this feature in RMON-II. Interim Meetings (Not Discussed) The working group needs to finalize any interim meetings at least 30 days before a meeting is to be held. A city easily accessible by air-travel (i.e., major hub) should be chosen, which is not anywhere near the last or next IETF (i.e., either US coast). This issue needs further discussion on the mailing list. RMON Schedules (Not Discussed) The working group needs to identify some milestones not specified in the charter. A date of 1 January 1995 has been set as the cutoff for new problems to solve. There has not been a cutoff date set for new solution proposals. Before solution proposals can be considered in detail, a framework for the new features must be designed. New groups, rules for dataSource, filtering framework, `hardware friendliness,' and RMON-1 integration must be considered before we start churning out MIB objects. A target date for framework completion has not been set.