CURRENT_MEETING_REPORT_
Reported by Edward Alcoff/Network Application Technology and Michael
Erlinger/Harvey Mudd College
Minutes of the Remote LAN Monitoring Working Group (RMONMIB)
Introduction
The goals for this meeting of the RMONMIB Working Group were to discuss
the advancement of RFC 1271 and to discuss the proposed charter for
RMON2.
Monday's session was devoted to RFC 1271 advancement. Tuesday's session
centered around a discussion of the charter for the next generation of
RMON (agreed to be designated RMON2---not RMONv2).
RFC 1271 Advancement
The issues concerning RFC 1271 advancement are:
1. A question was raised with regards to an RMON agent having to
capture a packet larger than 1518 bytes, and if so, then how much
larger?
Options included:
o bump the counter, but not capture (is this compliant)
o look at part of the packet (but not capture all of the packet)
It was the consensus of the group to leave it as currently stated.
There are numerous options depending on the particular chip
capabilities. Let the implementors do the right thing. Clarify
this better in RMON2.
2. The etherHistoryTable has approximately 12 counters while the
tokenRingMLHistoryTable has approximately 25 counters, which may
have different memory requirements should an RMON agent be required
to support both media types. The buckets granted may change, and
not be sufficient if going from Ethernet to Token Ring. The point
was made that this should not happen very often, and the action to
be taken should be straight forward and recoverable. The agent
should return ``badValue'' of the data source to the change request
(or ``resource unavailable''). A suggestion was made to allow the
value of the buckets granted to change. It was also mentioned that
this issue is a rehash or a previous debate with regards to an
agent changing interfaces.
Steve will add text to RFC 1271 to the effect ``If the agent knows
(of a change to the interface), then it is to `do the right thing,'
within its capabilities.''
3. On hearing one's own packets, it was deemed important that the
agent must account for everything it sends, but it may not be able
to ascertain the relative ordering of packets captured that
originate from that Mac. Should it just make a ``best effort''?
The choices were to add another bit to captureBufferPacketStatus,
add text to the RFC describing the problem, or do nothing.
It was the consensus of the group to add another bit to
captureBufferPacketStatus indicating that order of packets from
that Mac are a best guess. Also, noted that the bit is restricted
to packets from that Mac---prevents an agent from not maintaining
order in the buffer.
4. With the above changes RFC 1271 should be forwarded to the area
director with a recommendation of advancement to Draft Standard.
Steve committed to a date of 18 April for publication of the
revised draft.
The Next Generation of RMON - RMON2
The first part of the discussion made clear the notion that there is no
charter for such a working group. The results of the discussion would
be used to generate a charter for such a working group once the current
RMONMIB activities were concluded---namely the advancement of RFC 1271.
The chair presented the following issues:
o Time frame - strongly suggested that a Proposed RFC be readied
within the next 12 months.
o Requirements and problems needing to be solved.
o What will and will not be considered for RMON2.
o RMON2's relationship to the original RMON:
- new features
- old features to be reconsidered/redesigned
- backward compatibility not required
o The RMON2 development process, i.e., need for interim meetings of
the working group over and above IETF meetings.
o RMON2's relationship to SNMPv2.
The chair then asked if there were any participants that have done
extensions to RMON and would like to present these features for
inclusion in RMON2. The chair also solicited implementations from any
organization that have extended RMON.
The following list of features was created for RMON2 discussion and
inclusion in the proposed charter.
1. Statistical analysis that would be protocol independent and move up
the stack. (As a side note, it was later agreed that the RMON
Working Group would strive for protocol independence.)
2. Address mapping - Network Layer to Data Link (MAC) Layer and
vice-versa.
3. Duplicate and/or address change detection. Question asked on
whether or not this should be accomplished on the station?
4. The relationship of the Manager-to-Manager MIB in SNMPv2 and
associated RMON alarm tables. Suggestion was made to possibly
deprecate the older tables.
5. Provide a Host Table for the Network Layer, and perhaps the
Transport Layer.
6. Protocol-type distribution through all seven layers of the ISO
model; develop paradigm even if not feasible. A question was asked
on why this could not be done with the current filtering scheme;
the answer was that there would be a need to set up too many
filters and the processing would be inefficient.
7. Address the issue of the filter mechanism being constrained by
bit-to-bit packet matching, which presents a problem with
variable-length packets.
8. Consider how RMON could benefit network security, for example,
using the RMON History to provide an accountability and audit trail
through the Transport Layer. The security challenge here is to be
able to track connectionless protocols such as UDP. An audit trail
of port numbers, time and states would be very useful.
9. Noted that RMON for other physical layers should fall to other
working groups, such as the IFMIB Working Group, or be taken out of
the RMON Working Group and included in new working groups.
10. More performance metrics in RMON to meet the needs of the
client-server environment.
11. Concerns of hardware implementation should be considered. For
example, optimization of the filter and capture group would reduce
the cost of the CPU and improve performance.
12. Align the EtherStats and History Tables with IEEE and/or the
repeater MIB.
13. Align with SNMPv2.
The working group also discussed whether RFC 1271 should be divided into
a generic RMON and an Ethernet RMON. Consensus was reached on keeping
Ethernet and generic RMON within the same RFC.
Once RFC 1271, with modifications, is advanced to a Draft Standard, the
chair will create an RMON2 charter.
Attendees
Edward Alcoff oldera@nat.com
David Arneson arneson@ctron.com
Bashir Ashrafi bashraf@chipcom.com
Jim Barnes barnes@xylogics.com
Andy Bierman abierman@synoptics.com
Uri Blumenthal uri@watson.ibm.com
Tony Bogovic tjb@bellcore.com
Carter Bullard wcb@cert.org
Jeff Case case@snmp.com
Frank Ciotti frankc@telxon.com
Matt Crawford crawdad@fncent.fnal.gov
Roger Cyganer cygander@telebit.comm
Robert De Mong robert.Demong.amd.com
Russell Dietz Russell_Dietz@mcimail.com
Art Dong atos@cac.washington.edu
David Engel david@ods.com
Michael Erlinger mike@jarthur.claremont.edu
Louis Fernandez lff@sequent.com
John Flick johnf@hprnljf.rose.hp.com
Walter Guilarte guilarte@wg.com
Stuart Hale stu_hale@vnet.ibm.com
Daniel Hansen danh@ngc.com
Duane Harkness duaneh@atc.boeing.com
John Hopprich hopprich@davidsys.com
Jeff Hughes jeff@col.hp.com
Robin Iddon robini@cix.compulink.co.uk
Bent Jensen bent@cisco.com
Jeff Johnson jjohnson@cisco.com
Vince Jones 72077.1615@compuserve.com
Paul Kingsley pmk@hpcsos.col.hp.com
Richard Kooijman r.kooijman@et.tudelft.nl
Cheryl Krupczak cheryl@empiretech.com
Kenrick Kutzler kkutzler@synoptics.com
Welson Lin welsonl@nat.com
Faye Ly fly@synoptics.com
Carl Madison carl@zeus.st.3com.com
Evan McGinnis bem@3com.com
Dwayne McIntosh mcintosh@sleepy.ns.us.boeing.com
Jim McQuaid mcquaid@wg.com
Bob Morgan morgan@networking.stanford.edu
Kenneth Mueller ken@cmc.com
Robert Natale natale@acec.com
Roxanne Nisbet bsvnvgk@bell-atl.com
Bill Norton wbn@merit.edu
Richard Paine painer@ct.si.cs.boeing.com
Andrew Pearson pearson@snmp.com
David Perkins dperkins@synoptics.com
Randy Presuhn randy@peer.com
Venkat Rangan venkat.rangan@nashua.hp.com
Guenter Roeck roeck@conware.de
Dan Romascanu dan@lannet.com
Blair Sanders bbs@sanders.itg.ti.com
Michael Scanlon scanlon@ftp.com
Timon Sloane timon@timonware.com
Robert Snyder snyder@cisco.com
Ira Steckler isteckle@chipcom.com
Rudolph Sterner rudy.sterner@amd.com
Bob Stewart rlstewart@eng.xyplex.com
Richard Sweatt rsweatt@synoptics.com
William Wagner dpi@world.std.com
Steven Waldbusser swol@andrew.cmu.edu
Dick Wallace dick@concord.com
David Walters walters@wg.com
Glenn Waters gwaters@bnr.ca
Chris Wellens chrisw@netcom.com
Bert Wijnen wijnen@vnet.ibm.com
Peter Wilson peter_wilson@3mail.3com.com
Shian-Tung Wong shian@dcsd.sj.nec.com
Jeff Yarnell jeffya@protools.com
Kiho Yum kxy@nsd.3com.com
Dan Zerkle zerkle@cs.ucdavis.edu