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.