Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/rmonmib/rmonmib-minutes-91mar.txt

Text File | 1993-02-17 | 11.6 KB | 305 lines

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         [e-mail]
William Barns            [e-mail]
Steve Bostock            [e-mail]
Kurt Dobbins             [e-mail]
Bill Durham              [e-mail]
Gary Ellis               [e-mail]
Fred Engel               [e-mail]
Mike Erlinger            [e-mail]
Bill Fardy               [e-mail]
Martin Gray              [e-mail]
Mike Janson              [e-mail]
Kenneth Key              [e-mail]
Cheryl Krupczak          [e-mail]
Donna McMaster           [e-mail]
Lynn Monsanto            [e-mail]
David Perkins            [e-mail]
Ron Poppen-Chambers      [e-mail]
Rehmi Post               [e-mail]
Ron Roberts              [e-mail]
Kary Robertson           [e-mail]
Jonathan Saperia         [e-mail]
Greg Satz                [e-mail]
Mark Schaefer            [e-mail]
Dror Shindelman          [e-mail]
Anil Singhal
Sudhanshu Verma          [e-mail]
Steven Waldbusser        [e-mail]
Steve Witten
Wing Fai Wong            [e-mail]



                                   6