Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/rmonmib/rmonmib-minutes-95may.txt

Text File | 1995-10-18 | 27KB | 698 lines

INTERIM_MEETING_REPORT_

Reported by Robin Iddon/AXON Networks and Jeanne Haney/Bay Networks

Minutes of the Remote LAN Monitoring Working Group (RMONMIB)

An interim meeting of the RMONMIB Working Group was held in Santa Clara,
CA on 15-17 May.  The meeting was sponsored by cisco Systems.


Agenda

   o Protocol directory
   o Protocol distribution
   o Address mapping
   o Network layer host/matrix
   o Seven-layer host/matrix
   o Relative offset filtering
   o Time filter
   o Probe capabilities
   o Generic control table issues
      -  dropped packet counter
      -  lastActivationTime
      -  lastDeleteTime elimination
      -  tableSizeRequested/Granted
   o Seven-layer topN/history
   o RMON1 additions
   o User history
   o Probe config MIB
   o Dynamic protocol discovery
   o Channel as dataSource


The following notes are intended to provide a overview of the issues
discussed at the meeting.  Refer to the upcoming draft for detailed
changes.


Protocol Directory

Issues involving the protocol identifier format were discussed.
Concerns over OID tree data explosion led to a new ID format using an
OID to represent the protocol layering and an octet string to represent
the attributes or parameters associated with each protocol layer.

OID tree data explosion issues:

     (1) Reference document explodes.
     (2) protocolDirectoryTable grows by same factor.
     (3) Agent code grows potentially.
     (4a) The number of stats/host/matrix rows may grow also.
     (4b) The number of filter entries grows also.

Agreed to add some kind of protocolDirType to indicate whether or not
this node could be (user) extended.

Adopted proposal:


     protocolDirEntry
         protocolDirID -- OID { ip.udp.tftp }
         protocolDirOptions -- OCTET STRING, 8-bit per sub ID

     INDEX { protocolDirID, protocolDirOptions }


There must be exactly one 8-bit option per sub ID in protocolDirID. The
intent is that all protocol defs have exactly one option -- those that
need none use zero; those that need one or more must define how to
combine their values into a single 8-bit.

For WANs in particular, there is real concern that there is no way to
handle the multitude of link layer encapsulations.  Previously we hoped
to allow vendors to insert their own subtrees; we can still do the same
thing provided we identify the places where it will occur in advance and
provide for vendor-extension bit.

Agreed to remove protocolDirParentID pending further discussion.

Agreed to add an ``unknown network layer protocol enumeration'' which
handles all cases where absolutely nothing could be determined about a
packet (except, its mac addresses and length.)



Protocol Distribution


A proposal came up to add size distribution to this table.  Discussion
over the granularity of the buckets led to a proposal to use three
buckets:  < media-min, >= media-min, and > media-max.  Agreement could
not be reached and size distribution was dropped from consideration.

Proposal to use protocolDirIndex (aka local integer) in the
protocolDistTable INDEX { protocolDistControlIndex, protocolDirIndex }.
Agreed that if there was no other use for the protocolDirIndex then this
table will revert to its original use of protocolDirID.

Discussion of fragmentation and whether we are interested in monitoring
higher layer fragmentation (i.e., whether we want to try and provide
counters which instrument fragmentation at all layers) -- generally the
group appears not to be interested in directly counting fragmentation at
any layer.



Address Mapping

Much discussion was made of whether to include the addressMapIfIndex in
the INDEX (and hence to differentiate rows on different interfaces that
are otherwise the same).

There was discussion on how much effort it is for the NMS to utilize
this table.  Possible problems include:


   o How the NMS maps RMON1 host addresses through this table without
     totally uploading the table?

   o Whether the NMS uses the random access capability.

   o Should ifIndex be replaced by an OID to allow it to point to a
     repeater port?  Data source still tells you which network the data
     came from.


Include controlIndex instead of ifIndex as (a) ifIndex is being replaced
and (b) do not want to keep port histories (which would happen if a
device moved from one port to another and the OID was part of the
INDEX).

Agreed to INDEX { protocol, address, controlIndex }

Agreed to incorporate portOID into addressMapEntry -- intent to point at
point of origin of this device (best guess of agent).

After much discussion about NMS control of agent resource utilization it
was agreed that the protocolDirectory should contain a set of flags to
control usage of this protocol.  At a minimum this should control
whether or not a protocol is used in maintaining the address mapping
(hence it appears in this section of the agenda).  Ideally we would also
have a few more flags to enable usage in the protocolDistribution and
the host/matrix tables.



Network Layer Host/Matrix

Discussion of using an enumerated value vs.  protocol dir index led to
further discussion of protocol directory `counting' issues and the need
to control which protocols are counted in which tables:


   o One idea is to turn on/off a protocol via the protocol dir table.
     This means you collect the same protocols for all interfaces and
     all application tables.  This seems very restrictive.

   o The second idea is to define the protocol channel which defines a
     set of protocols that a control entry points to, to determine which
     protocols it is collecting.  The control tables would still have a
     separated data source value (i.e.  not tie with protocol channel,
     so protocol channel can be shared across several control tables).
     This serves two purposes.  It allows the NMS to give the agent help
     in conserving its resources.  It also makes the tables smaller to
     retrieve so it helps the NMS.

   o The final choice was to turn the protocol on/off on a per
     application (Net Map, Matrix, Host, etc.).  You cannot control it
     on a per interface basis.  You cannot control it on a per control
     table basis.  This is the one that most people voted for.


The counters within the nlHostTable were discussed:


   o nlHostOutErrors discussion -- agreed object removed.

   o nlHostOutMACNUCastPkts agreed to replace nlHostOutBroadcastPkts,
     nlHostOutMulticastPkts.

   o nlHostOutFragmentPkts agreed not to implement this class of
     counter.


nlHostEntry creation was discussed.  Certainly do not insert on MAC
error packets; do insert on new source address.  There was some
discussion on whether or not to insert on destination address.  It was
finally agreed to insert on good source and destination addresses but
that the agent may need to use an improved aging technique to eliminate
the host destination addresses generated by programs which ping
sequential addresses in an attempt to discover which hosts exist.

Agreed to drop hlMatrix[SDjDS]Errors.

Agreed to keep both DS and SD tables (despite their being good reasons
not to).  It was deemed (a) too complex to dismiss the NMS's inability
to easily know of some classes of uni-directional conversations and (b)
the overheads on the agent are not severe enough to make the pain of
pushing this through worth doing).

Agreed to not do subnet aggregation because there was no standardizable
proposal and no one volunteered to do one.



Seven-Layer Host/Matrix


Three models were discussed based on nl/sl host tables:


  1. Merge them

  2. Keep them separate but closely related so that the agent can be
     efficient

  3. Keep them totally independent


Long discussion over the product class<->mib group mapping followed.

Eventually the group came to a vote on:


  1. Single control table causing a nlHostTable and slHostTable to be
     constructed (related solution 1' recognizes that within the single
     control table entry will be parameters specific to the nl and sl
     tables, e.g., rm2HostControlNlMaxDesired and
     rm2HostControlSlMaxDesired).

  2. Merge both tables (voted out 1 for merge, 16 against).

  3. Split control tables but slHostControlTable depends on an instance
     of nlHostControlTable.  Notice that this is also the same functions
     as 1'.

  4. No sharing of data, hence duplicate memory requirements!
     (Deleted.)


Proposal 1' was accepted over 3.

Steve will add a straw proposal for the combined sl/nlHostControlTable
in the next draft.

slHostEntry will contain only inPkts/outPkts and inOctets/outOctets.
slHostEntry will not contain slHostAddress, instead INDEX will reference
nlHostAddress, and words will be added to ensure that for each
slHostEntry there must be an nlHostEntry with the same address and hence
deleting an nlHostEntry will cause deletion of the associated
slHostEntries.

Misconfiguring the protocolDirectory such that slHost function is
enabled for a protocol but nlHost function is not enabled for its
network layer protocol causes no data to be collected in either table
for this protocol (because there are no nlHostEntries to relate
slHostEntries to).

Proposal adopted:
INDEX { controlIndex, protDirIndex(addrType), nlHostAddress,
protDirIndex(protocolType) } and that the slHostTable contain neither an
address nor a MACNUCastPkts counter.

A proposal was adopted to include a bit/enum in the protocolDirectory to
indicate whether or not a network layer address is available for this
protocolDirectoryEntry (it would not make sense to set this bit for
ip.udp, for instance, but it could be set for both the ip entry and the
ip.udp.appleTalk entry; an agent would set the bit if it supports the
protocol as a network layer protocol and not if it supports it only as
an application protocol).  Ideally we would incorporate this into the
nodeType object.  This is not something to be placed in the parameters
object because it can only relate to the final protocol of the OID, not
all of them).

Proposal for slMatrix is:
INDEX { controlIndex, protDirIndex(addrType), sa, da, protDir(protType) }

Agreed to let Steve apply results of the nl/sl host table discussions to
the matrix and so avoid long discussions over basically the same
subject.

Agreed to move forward to the topN/history on host/matrix tables out of
order because we want to discuss it in the context of the host/matrix
tables.

Discussion of data table columns:


   o Issue of error counters.  What does it include?  Why count L2
     errors by protocol.  Errors can propagate up to this table.  It is
     too hard to make it meaningful to count network layer errors.
     Therefore we will leave it out.

   o Bcast and mcast?  Could there be permutation of bcast/mcast at the
     L2 level and bcast/mcast at the L3 level.  Is a broadcast to MAC
     addresses with a multicast IP address counted as bcast or mcast.
     Robin believes that the impact on the net is the fact that it is
     bcast, i.e., everyone received and processed it.  We decided that
     we are merging the bcast and mcast counts into one counter.  We are
     still counting L2 counters with an NLHostOutNUcastPkts (not
     unicast).  Get rid of Broadcast, Multicast, and Errors.

   o Robin proposes an OutFragment counter that only bumps up when
     fragments are detected from a particular SA. Most people abstained,
     so it is a closed issue.  Fragments are not counted.

   o We discussed not adding entries to the Host Table based on DA, so
     that the table does not get filled up with erroneous addresses from
     MIB sweeps, etc.  On the other hand there are L3 broadcast
     addresses in video multicast addresses that will never appear in
     the source.  Maybe we can use a different aging algorithm so
     entries without out pkts, get deleted sooner.  But then would you
     be deleting these interesting mcast and bcast pkt as frequently as
     these bogus sweep addresses.

   o Good packets for this table is defined as good MAC packets.

   o Drop the Matrix error counters, do not add the bcast counter, they
     can get them from the host table.  Remove nlMatrixSDAddressType.


Discussion of encapsulated network layers (e.g., IP in IP):


   o The problem of NL layer protocols being wrapped on other NL
     protocols, causes some problem in the how to count the pkt and what
     the NL address is.  How do you record both NL address.  Do you
     consider the encapsulated protocol to be application?  There is no
     place to save the encapsulated NL address.

   o Steve proposes an address structure that encode what the protocol
     is so that we can model both NL protocols and NL protocols
     encapsulated in other NL protocols.  Should we try to solve this
     problem?  (Vote:  8-2-5.)  Now the NL tables could have entries
     that count a pkt twice, since the NL table accounts for all NL
     protocols, not just the NL usage at this particular probe in the
     network.  Not all probes need to implement this, but all NMSs need
     to be aware of this anomaly.  I.e., if you take all the entries for
     a particular NL Host, they could total up to more than 100% of the
     Net utilization for that Host.  How does this affect the protocol
     distribution table.  There would be a protocol directory entry for
     AppleTalk with IP and it would be counted in the prot distribution.

   o The upshot of the vote to handle protocols that may be encapsulated
     within other protocols, how you might represent the addressing.
     Can we change the network address mapping table to record this
     information that we have learned from encapsulated NL protocols.
     Add pDir Index as last index to the slHostTable (and slMatrix) NL
     -- address object nonUnicasts, SL -- pDirIndex on end Add a
     bit/boolean to pDirTable that defines whether addresses are
     recognized for that protocol.



Relative Offset Filtering

There was a lot of discussion of various filtering related topics.  In
the end it was agreed to treat the channels as data source issue
elsewhere.

Agreed to pursue filterLogicTable and mod to filterChannelIndex
0..65535.  Robin to write up proposal (15 for, 0 against, 2 abstain).



Time Filter

After an example and some discussion it was agreed to implement time
filter as proposed (15 for, 0 against, 1 abstain).

It was also agreed that the timeMark goes in between the control index
and the rest of the index.


Probe Capabilities

We discussed probe classes and the nl/sl split.  We finally closed with
nl/sl remain different tables (7 for, 3 against, 3 abstain).

Next we voted on whether or not any kind of capabilities object was
needed; in favour (11 for, 1 against, 2 abstain).

Next we discussed per-interface vs.  per-device capabilities.  First
vote on scalar only (per-device) (7 for, 2 against, 4 abstain).  Scalar
adopted.


Generic Control Table Issues

  A) Dropped Packet Counter

     There was a lot of discussion about how the counters work and what
     they are (and are not) intended to do.  In the end it was agreed
     that these counters are not intended to enable the agent to do
     statistical sampling/scaling.  Indeed the notion of scaled data in
     the RMON2 tables is explicitly precluded (the group cannot define a
     scaling algorithm that is universally appropriate).  Finally there
     was debate over whether statistical sampling and scaling were
     really the only solution to the 10x media speed increases, and
     while there was no agreement the discussion polarized between those
     that felt that the current agent technology would enable 100MBit
     and those that did not.

     It was agreed that there would be one droppedFrame counter per
     control entry by default but that for some groups/functions we may
     decide to use a scalar should that prove more appropriate.

     It was agreed that the [etherjtokenRingP]StatsDropEvents would
     continue to exist in RMON2 agents and that its semantics would be
     unchanged.  The following rules define how the fooDropFrame counter
     (from the fooControlEntry) relates to the
     [etherjtokenRingP]StatsDropEvents counter and
     [etherjtokenRingP]StatsPkts counter for the same interface:

      1. For each time the agent recognizes that one or more packets
         have been missed without it knowing exactly how many were
         missed it must increment the dropEvents counter for that
         interface.  This is the only time that the dropEvents counter
         is incremented.

      2. Whenever the agent chooses not to update a table/data
         collection function based on the contents of a packet which it
         knows was present on the network it must increment the
         droppedFrames counter for that table/function.

      3. For all packets which are not lost in (1) above or dropped in
         (2) above the agent must update tables/data collection
         functions accurately.

     Two results of applying these rules are:

      1. The sum of all packet counters in a table or data collection
         function (e.g., the hostOutPkt counter) plus the associated
         droppedFrame counter should be exactly equal to the sum of the
         [etherjtokenRingP]StatsPkts and [etherjtokenRingP]DroppedFrames
         counters for the same data source.  Of course this assumes that
         the there are enough resources in the agent such that the table
         is not being LRU'd.

      2. For all agents where the dropEvent counter is zero the sum of
         the droppedFrame and Pkt counters in a given table or function
         on the same interface should be exactly equal to the number of
         packets that there were on the network.

     It was agreed that there should be strong recommendations for RMON2
     agents to utilize the droppedFrame counters as a means of
     accurately reporting the number of frames missed and that if at all
     possible the dropEvents counters should never be incremented -- in
     this way an NMS can use the data with much higher confidence.

  B) lastActivationTime

     Proposal to have this object set to sysUpTime at the point in time
     this control row's status transitioned from not active to active.
     This lets the NMS notice that another NMS restarted data collection
     (without picking a new control index) and so deltas will be
     invalid.  It also gives an indication of the age of the table (but
     may not be used to rate the first ever poll -- the data counters
     still do not have to start from zero and so you do not know the
     delta over the interval).

     Agreed to adopt proposal (13 for, 3 abstain, 0 against).  Notice
     that we will decide later which tables and functions to apply this
     to.

  C) lastDeleteTime Elimination

     Discussion -- it was agreed that lastDeleteTime was easy to
     implement, but it is also agreed that it was designed specifically
     for creationOrder which no longer exists.

     Proposal is to replace tableSize and lastDeleteTime with
     insertCount and deleteCount (where insertCount - deleteCount ==
     tableSize).

     Agreed unanimously to adopt.

  D) tableSizeRequested/Granted

     Proposal to implement a maxDesired (i.e., a ceiling) per
     controlEntry.  0 implies consume as much memory as is
     required/available.  > 0 instructs the agent to create at most this
     many data table entries associated with this control entry -- once
     this ceiling is reached the agent should delete old resources
     (associated with this control entry) in order to create new rows.

     Agreed to adopt proposal (16 for, 0 against, 1 abstain).

     Notice that we later had a discussion which suggested a valid use
     of zero would be for the new hostTable where the control entry
     creates both nlHostTable and slHostTable; a user who did not want
     an slHostTable on an interface might use 0 to indicate that.
     Perhaps we should use -1 to imply unlimited rather than zero.


Seven-Layer topN/history

Agreed to do any kind of topN in addition to the RMON1 stuff (8 for, 0
against, 7 abstain).

Agreed to do slMatrixTopN (7 for, 0 against, 0 abstain) Marginally
agreed to do nlMatrixTopN (5 for, 1 against, 5 abstain) Agreed to not do
slHostTopN and nlHostTopN (1 for, 5 against, 7 abstain and 0 for, 4
against, 7 abstain respectively).

Agreed not to support TopN by protocol (1 for, 10 against, 4 abstain).

A real proposal bringing together all the best ideas of how to do TopN
on the nl/sl matrix tables is needed -- Steve, Matt and Shay to get
together on producing this proposal.


RMON1 Additions

  1. netUtilization

     Etherstats gives you the number of octets seen.  Robin proposes
     that we provide a count of the number of bits and include interpkt
     gap and the preamble.  This gives you a better approximation of
     utilization.  Bytes seems like a better unit to use, then the
     counter will not wrap as readily.  It still is the same way another
     analyzer would calculate utilization.  We still run the risk that
     RMON gets compared with these analyzers and is not identical.  So
     the question is, is the esterStatsOctets value a good enough
     approximation to get utilization or do we want to provide a new
     object that counts more of the overhead.  People seem to favor just
     sticking with the original counter and obtaining an approximation
     to utilization for thresholding via Alarms.
     The group voted to use the octets approximation and not add any new
     bandwidth utilization indicators.

  2. filterDescr

     Proposal withdrawn without opposition.

  3. [filter changes]

     Robin to make proposal on the list based on what was discussed at
     the meeting (i.e.  the filterLogicTable with m:1 relation
     reversed).

  4. Control table additions

     The group considered four additions and how they applied to each
     control table:

     (a) insert, delete counters
     (b) maxDesired
     (c) activationTime
     (d) droppedFrames

     EtherStatsTable+TokenRingPStats+TokenRingMLStats
         activationTime, droppedFrames

     HistoryControlTable
         Nothing

     EtherHistoryTable+TokenRingPHistoryTable+TokenRingMLHistoryTable
         droppedFrames

     AlarmTable
         Nothing

     HostControlTable
         maxDesired, activationTime and droppedFrames
         (maxDesired needs note in implementors guide, apparently)

     HostTable/HostTimeTable
         Nothing

     HostTopNControlTable
         Nothing

     HostTopNTable
         Nothing

     MatrixControlTable
         Same as hostControlTable

     MatrixSD/DSTable
         Nothing

     FilterTable/ChannelTable/BufferTable
         Nothing

     EventControlEntry + LogTable
         Nothing

     RingStationControlTable
         activationTime, droppedFrames

     SourceRoutingStatsControlTable
         activationTime, droppedFrames

  5. Storage type

     Steve to propose an object which is per-control row and indicates
     what NVRAM processing an agent has performed on that row (ROM,
     will-write, wont-write, written).  (7 for, 0 against, 4 abstain).

  6. Alarms enhancements

     Make it robust when monitored OID disappears.

     It was agreed that Steve would produce a draft based on an
     alarmValueStatus object which defines whether the agent managed to
     get the value last interval, an alarmValueUnavailable event/trap,
     an alarmUnavailableEventPollThreshold (i.e.  the number of
     unavailable intervals before generating the event).

  7. WAN status bits

     It was agreed that bit6 will be supported in the pktStatus bitmask
     as the packet direction bit.  Further study of bit7 (other physical
     errors) will be done, but this bit needs to be more clearly defined
     before it can be adopted.


User History

Get rid of objectsGranted.  BucketsRequested cannot be changed after row
goes valid.  Otherwise it stands as is.


Probe Config MIB

In this section OK means that we accepted to do it -- there were no
votes as such, just a call for objections.


   o probeID, probeFirmwareRev, probeHardwareRev OK. Discussion on
     converting probeDateAndTime from ASCII into v2 DateAndTime TC
     (except we will do our own TC which is length 0 or 8 or 11 to allow
     optionality) OK.

   o probeResetControl OK.

   o probeDownloadFile, etc.  (5 for, 0 against, 7 abstain) OK.

   o serialConfigTable:  Agreed to keep serialIP and serialSubnet.

   o The agent might need to implement the two tables that contain line
     speed and flow control objects, but we will try to get away without
     doing it; should it be rejected elsewhere we will have to adopt
     usage of the appropriate serial MIBs instead (charPortTable and
     portTable).

   o Modify serialConfigProtocol slip(1), ppp(2), other(3).

   o Take all modem string DEFVALs and make them comments instead.

   o Rename serialTrapTimeout to serialDialoutTimeout OK.

   o netConfigIpAddress/netConfigSubnetMask OK. Remove netConfigIfSpeed
     and
     netConfigIfRingNumber.

   o trapDestIndex, trapDestCommunity, trapDestIpAddress, trapDestOwner,
     trapDestStatus OK (8 for, 0 against, 2 abstain).

   o serialConnect:  index, dest ip, connection type (direct, modem,
     switch, switch-and-modem), dial/connect strings, owner, status.
     OK.



Dynamic Protocol Discovery

Populate the prot directory that is sensible at startup.  Then the agent
could add some protocols that it discovers existing on the net.  The
assumption is that the agent was capable to decode those protocols all
along, but there is such large set of them and they may never appear on
the net.  It is OK that these added protocols grow more than a single
level, as originally thought.  It is up to the probe whether to turn it
on or not for collection.  How do we document these in the protocol
document and provide options for these fields?

Further discussion on the mailing list is needed.


Channel as dataSource

There was a vote on how many people violently object to using channel as
data source (2).

Those that wanted the standard to be changed to mandate that an agent
must allow channel as data source (3).

Those that want to leave the standard as is (and accept that there will
continue to be proprietary extensions) and that the behaviour of any
other kind of data source value is undefined (11).

We voted to modify the text that states ifIndex is the only recognized
dataSource that all should support, but that other values are not
illegal -- just considered out of scope.