CURRENT_MEETING_REPORT_ Reported by Michael Erlinger/Micro Technology Remote LAN Monitoring Minutes Three separate meetings were held with the primary Agenda to review the RLANMIB MIB proposed by Steve Waldbusser. The MIB had been distributed to the mail list and copies were available at the meeting. The driving focus of the current MIB is to quickly get a consensus on an RLANMIB that can act as a standard. For this reason, various issues have been moved to future MIBs. In general the MIB document should have more verbiage describing the MIB and the general philosophy that was followed. Memory management and table size issues were discussed at length. The only consensus reached is that memory management is a problem and that the various probes will find their own way to control memory. A philosophic question was raised and not debated: What is the difference between a monitor and an analyzer? This needs to be discussed more to better decide on the RLANMIB. During the discussions about multiple managers and table ownership, the point was made that the probabil- ity of multiple manager collisions was in fact quite high, since access to probe tables is often the result of network problems (during which more than one manager may rush to fix). MIB development needs to recognize this point. It was decided that a RLANMIB meeting should be held prior to the next IETF. The date of this meeting will be decided after a new version of the MIB document is made available to the mailing list. The Chair will be responsible for choosing the date and location. A few general points were discussed as foundation principles for the RLANMIB: o Probes will be used simultaneous by more than one network management station. o Probe resources will be a constant concern, a method must be found that would allow a probe to determine which dynamic tables, in particular those associated with a NMS, can be deleted. o Accepting the simultaneous use of the probe, the MIB should insure the isolated use by each NMS. o Accepting the simultaneous use of the probe, the MIB should allow for the sharing of use by each NMS. 1 MIB Review Etherstats Table Various entries are the same as other MIBs, (ethernet), while other entries are new. Two justifications for this approach: 1. Probes have the primary task of monitoring so the additional resources should not be a concern; 2. Probes operate in promiscuous mode, so they will produce different values. MIB should spell out whether good and/or bad packets are included in a count. In general this information should be added to all counter descriptions. MIB should spell out that: All counts exclude framing - start with destination address and continue through CRC. In particular, all packets are included in each bucket because segment utilization includes both good and bad packets. Etherstats Counters `64 64--1518 ~1518 |------------------------------------------------------------ CRC | collision crc/align jabber error | fragments |------------------------------------------------------------- NONE | runt good oversize It was noted that the etherSTatsPkts64Octets counter was missing -- to be added in next version. Inclusive or exclusive will be added to text describing various packet counters. Etherhistory Table 2 Circular rollover: when the N buckets are full you continue to have only N buckets, loosing the oldest bucket. Interval change semantics: It is viewed that a change in interval is the same as deleting the current control entry and starting a new one, i.e., the existing N buckets are lost and a new N buckets with the current interval are allowed to exist in the system (actual allocation of buckets is an agent task). Change # of buckets semantics: Changing the number of buckets should not invalidate the current buckets. This will be explained in the document. In particular, changing to a greater number of buckets, just adds more buckets to that history sequence. Reducing the number of buckets deletes the oldest buckets until the required number are left. What about time stamping the bucket contents? Adding an end time to the bucket has little meaning because granularity is probably 1 sec and is thus not very meaningful. Buckets are not real-time. Finally, could use the start time of the next bucket as the end time of the current bucket. Discussion of starting a table entry: The entry starts when the VALID is set. Valid could be set in the same PDU as all the other entries because a set is viewed as an atomic operation. How to determine if probe lost data: Use dropevents to determine if probe lost some events. Utilization will be changed from tenths of a percent to hundredths of a percent. Utilization discussion: Because everyone determines utilization differently (some use various hardware tests), it was decided that the utilization value is a standard way of presenting a non-standard value. A request was made for max available history buckets counter (etherHistory 3??). Someone said this is necessary in all dynamic tables and quite useful for the management station user interface Ether Host Tables The etherhostorder table will be ordered by time of 1st transmission -- still 1 to N. Much discussion and much debate about the problem of deleting stations from the table and still maintaining the ordering. This is an open issue which must be explained in the document. The host table ordered by natural index is being used to serve two purposes: fast download of the whole table and new station detection. The first requires a con- tiguous index space (necessitating renumbering) and the second requires monotonically increasing indices. The resolution was to create two tables instead of one (although Steve said he would try to figure out a way to shrink them back into one table). 3 Table deletion: It was decided that most tables need a deletion capability and that the MAC address is the most secure way to do deletion. Other indices may actually change. After much debate about the TOP N table, it was decided that there are three options: 1. Leave the table as it currently is; 2. Nuke the whole idea; 3. Expand the table to a series of tables -- a control table that describes each of the actual top N tables. Some discussion about probe reaction when a table that is already ``valid'' is set to ``valid''. It was decided that the proper agent action is ``no-op''. Ether Traffic Matrix Tables Change ``etherSDTableSize'' to ``etherMatrixTableSize'' The Filter table again raised the issue of NMS control of specific tables and the Probe/Agent's ability to garbage collect. The idea of a X.Y index for each dynamic NMS related table was discussed. A central table would exist in which each NMS specified its own unique X value. The NMS would also specify the time in sections for which X related tables should be maintained by the Agent. If the time decrements to 0, the Agent can reclaim all tables and table entries related to the NMS. The NMS can periodically restart the countdown clock. Thus, an NMS knows its own unique ID, can keep all its tables active (since it knows the time value entered into the station), the NMS can force deletion of all its tables by entering 0 into the time field, and yet the Agent can delete tables related to a particular NMS that is no longer active. Also, if this table includes the IP address or some other know NMS address, all NMSs can determine what other NMSs are using dynamic tables in the agent. Buffer Control Table Steve will add a variable to the buffer control table that holds the max available entries in the capture table. There was some discussion about how an agent would treat a set request in which either (or both) buffer- ControlCaptureSliceSize or bufferControlUsedBuffers were zero. Does this constitute a space reservation? Can the agent return BadValue? No resolution of this question. All state variables in control tables will have an Invalid state added (enfferControlState == stopWhenFull) implies that any filters which are supposed to ``turnOn'' that buffer, will not, once the buffer has reached the full state. 4 A variable should be added to the bufferControlTable containing the value of sysUpTime when the buffer was first turned on. The syntax of ``captureBufferPacketTime'' will be changed from TimeTicks to an integer containing the number of milliseconds since the buffer was turned on. Steve stated that the intent of the log table was to keep the most recent events (once it started wrapping). There was some discussion on numbering traps in the global environment. Steve will give it some more thought. We need to add a notificationIndex to the logTable. Notification Table A minimal time was spent discussing the Notification Table. Traps were referenced to the Notification Table, but not discussed in detail. Off Line Overhead associated with updating the etherhistory table. Steve will write up a mail message that will explain his approach to fast table dumping and the type of per- formance that he obtained. Topics for Later Discussion A table describing thresholds will be added at a later time, hopefully in the next version of the MIB. Deferred Topics Various topics are being deferred to RLANMIB 2 in the interest of expediently getting a RLANMIB 1 into test and evaluation. Peaks: Peaks are difficult especially in handling slid- ing time windows. If discrete time is used, then it is possible to miss peaks. In determining which type of peaks will be captured, e.g., utilization, broadcasts, etc., it was realized that peaks could double the size of the history table. Peaks should be time tagged, not just captured in the history table. Peaks really fall into the threshold area. The concept of protocol bitmasks for each station and protocol percentages for the segment were discussed at length. The consensus was to let this area go until RLANMIB 2. Questions that seemed open: protocols to be included in the bitmask; how far down the stack proto- col counting occurs; and general utilization of this feature. Attendees 5 William Anderson wda@mitre.org William Barns barns@gateway.mitre.org Steve Bostock steveb@novell.com Kurt Dobbins dobbins@ctron.com Bill Durham durham@MDC.COM Gary Ellis garye@hpspd.spd.hp.com Fred Engel engel@concord.com Mike Erlinger mike@mti.com Bill Fardy fardy@ctron.com Martin Gray mg@spider.co.uk Mike Janson mjanson@mot.com Kenneth Key key@cs.utk.gdy Cheryl Krupczak clefor@secola.columbia.ncr.com Donna McMaster dmcmaster@synoptics.com Lynn Monsanto monsanto@eng.sun.com David Perkins dave_perkins@3com.com Ron Poppen-Chambers rpc@hpcnd.cnd.hp.com Rehmi Post rehmi@ftp.com Ron Roberts roberts@jessica.stanford.edu Kary Robertson kr@concord.com.kr Jonathan Saperia saperia@decwrl.enet.dec.com Greg Satz satz@cisco.com Mark Schaefer schaefer@davidsys.com Dror Shindelman pbrenner@sparta.spartacus.com Anil Singhal Sudhanshu Verma verma@hpindbu.cup.hp.com Steven Waldbusser steven.waldbusser@andrew.cmu.edu Steve Witten Wing Fai Wong wfwong@malta.sbi.com 6